Jump to content
php.lv forumi

F3llony

Reģistrētie lietotāji
 View Profile  See their activity

  • Posts

    1,353

  • Joined

  • Last visited

 Content Type 

Posts posted by F3llony

  1. uzdevums

    in Vispārēji

    Posted

    Uzdevums nav no vieglajiem, tāpēc tev tā šķiet. Nekas, tā nav bēda, ar laiku nāks tev pieredze un iemācīsies lasīt arī sarežģītāku kodu.

    Tas ir tāpat kā ne katrs spēj lasīt, piemēram, Kanta darbus. 

     

    Varbūt tev ar laiku nāks pieredze un jēga, ka koda lasāmībai ar koda sarežģītību pamatā ir nekāds līdz mazs sakars, un tas nekādā veidā neattaisno to, ka tavs koda gabals ir pretīgs savārstījums. Tas, ka algoritms ir sarežģīts nenozīmē, tas jāimplementē vemjot šīrīta pusdienas pa tiešo koda redaktorā. 

     

    Un atkal atgriežas agrākais "ponta" arguments - tu noimplementēji risinājumu kā kaut kādu nelasāmu, nejēdzīgu figņu, kas pamatā nevienam nekādu reālu labumu un skaidrību par izdarīto nedod, jo lai tajā iebrauktu ir jāsalauž smadzenes vismaz 2 reizes. Tātad taviem vārstījumiem, atkal, ir nulle vērtības, un kārtējo reizi tu postē tikai lai parādītu cik kruts tu esi. Thats all. 

     

    3/10, PR declined. 

  3. WRONG Digital - meklē programmētāju

    in Darbs

    Posted

    To būs izdarīt legāli diezgan grūti.

    Maksāt autoratlīdzību ir pilnīgi legāli. Pie tam nesamaksāta pārsvarā tiek soc. nodokļa daļa. Un te ir jautājums, vai tu māki pats labāk menidžēt savas sociālās garantijas, vai labāk to uztici Valstij.

     

    Atkarīgs, kurai valstij... 

  13. Mac un PHP dev

    in Netēma

    Posted

    Man interesi izraisa klaviatūra. Es, protams, nesaku, ka jāspēj drukāt 180 simbolus minūtē, bet kaut kā šķiet, ka Mac klaviatūras ir mazāk ergonomiskas par, piemēram, ThinkPad klaviatūrām. Vai tā ir?

    Depends. Man, piemēram, dikti ērtas liekas Dell Latitude / Precission klavieres, pat vairāk, kā ThinkPad. 

  14. git workflow

    in Vispārēji

    Posted

    @F3llony - paldies par detalizēto aprakstu.

     

    Mani arī interesētu DB versionēšana. Uz doto brīdi labākais variants, ko esmu atradis - visas DB struktūras izmaiņas tiek veidotas ar migrācijām un, laiku pa laikam, kad to paliek par daudz, tās tiek nodzēstas, un tekošais DB struktūras dumps tiek ielikts versiju kontrolē kā bāze, pārrakstot iepriekšējo.

    Vai nu tā, vai nu vienkārši ar migrācijām, nedzēšot. Parasti jau "par daudz" nemēdz būt, un ja tu seko rolling release augstāk, neizpildītās migrācijas pamatā ir tikai pāris. 

     

    Par testēšanu, tam var turēt integrācijas vidi - kaut kādu serveri vai virtuālmašīnu, kas ik pa brīdim sinhronizējas ar produkcijas DB un datiem, cik tas reāli iespējams. Tad tur arī deploy darbus, kas pabeigti un atrodas integrācijas branch, un tad var notestēt gandrīz kā produkcijas vidē. 

  15. Mac un PHP dev

    in Netēma

    Posted

    Tas izklausījās tā it kā elementary vai arch ir pieklājīgāki nekā citi linukši. Un ir arī kaut kāda "nepieklājīgo" linukšu kategorija? :D

     

    Man sanācis personīgi palietot arch, manjaro, ubuntu, lubuntu un crunchbangu.. Secinājums bija tāds ka daudz svarīgāk par distributīvu ir izmantot pareizo window menedžeri vai full desktop environmentu. Kas attiecas uz pašu linuxu apakšā - visi ļoti līdzīgi.. Nē?

     

    Es šeit atļāvos lietot window manager un linuksis savstarpēji aizvietojami, no jūzera perspektīvas. Man tā estētika tomēr, tīk nu ļoti. Tāpēc sēžu nu jau otro gadu uz Elementary. 

  16. Mac un PHP dev

    in Netēma

    Posted

    Humora pēc, provēšu, kas tur sanāks. Kazi, lasot interwebus liekas, ka ja nu galīgi nepatiks, būtu iespējams nonest osX un uzlikt kaut kādu pieklājīgu Linux, to pašu elementary vai arch. 

  20. git workflow

    in Vispārēji

    Posted

    Pievienoju fellony aprakstam smukus zīmējumus: http://nvie.com/posts/a-successful-git-branching-model/

     

    Šis ir redzēts, bet es esmu konkrēti pret "release" branchiem, hotfixes branchiem utml. izdarībām, kas vienkārši piesārņo workflowu. Rolling release un continuous integration FTW. Un tam, ka feature branchus taisa no "develop" brancha arī es nepiekrītu, jo faktiski tad sanāk bāzēt feature branchus uz integrācijas branchiem, bet integrācijas mērķis ir sinhronizēt visas izmaiņas pret master. Ja laikā, kad taisa feature branch integrācijā ir izmaiņas, izmaiņas jābāzē uz master, un pirms feature branch merge integrācijā jātaisa merge master=>feature, neturot integrācijā vienlaikus vairāk par pāris konkurējošiem aizvērtiem pull requestiem. Tas nodrošina nekonfliktējošu integrāciju un master nekad nelagos aiz integrācijas, therefore, CI un rolling release. Vienīgais izņēmums ir kad tiek strādāts pie kaut kāda milzīga feature, bet tad feature branch pats par sevi ir būs bāze citiem feature branchiem, kas strādās tā pat, kā feature promise. 

  21. git workflow

    in Vispārēji

    Posted

    Vispirms ir jāvienojas par GIT workflowu, jeb veidu, kā strādāsiet. Viens no vienkāršākajem flowiem ir šis:

     

    1. Ir master branch. Master branch izmaiņas pa tiešo nekad neveic;
    2. Ir integration branch - integration branch ir branch kurā tiek mergotas visas izmaiņas;
    3. Ir feature branchi - katrai atsevišķai funkcijai;

    Mēģinam šadi:

    1. Tiek izdomāts kaut kāds darbs, piemēram, pievienot pogu kaut kādā skatā;
    2. Cilvēks no master (!!!) branch izveido jaunu branch, sauksim par "add-view-button" branch. Šis būs mūsu feature branch;
    3. Code, code, code;
    4. Autors "add-view-branch" izveido pull request pret integration (!!!) branch;
    5. Kāds cits izlasa un pārbauda kodu, apstiprina pull request;
    6. Konkrēto pull request iemērdžo integration (!!!) branch;
    7. Atkārtojam pāris reizes;
    8. Kad integration iemērdžoti pāris branchi, viss ir notestēts, un kad ir juša, ka vajadzētu šo likt "produkcijā", integration branch iemērdžo master branch. Normāli ne retāk kā reizi dienā - keep it small;

     

    Par konfliktiem:

     

    Normālā gadījumā pat ar GIT ir jācenšas nebāzties vienam otra darbā - ar tevis minēto piemēru, viens pilsonis uztaisa datubāzes stuff, pēc tam otrs kaut kādus kontrolierus, trešais pēc tam kaut kādus viewus. Ir ļoti jācenšas izvairīties no tā, ka 2 cilvēki strādā pie viena un tā paša feature, kas vēl nemaz nav pabeigts. Ja tā darīs, tad būs diezgan lieli murgi, konflikti utml. Taču brīžos, kad tas nav iespējams piemēram es mēdzu strādāt ar mokiem, un strādā tas šādi:

     

    • Ir nepieciešams paralēli strādāt piemēram, pie prezentācijas un dba, utt;
    • Viens pilsonis izveido mocku - reāli nefunkcionējošu crap, piemēram, kontrolieri, kas atgriež mock datus viewam, kādi tie būs realitātē - tas ir jaizdomā un jāizplāno. Minimālas novirzes ir pieļaujamas. Tas saucas feature promise;
    • Feature promise liekam branch, kas izveidots no master;
    • Tālāk viens pilsonis uztaisa branch no feature promise brancha, sauksim, dba branch;
    • Otrs pilsonis uztaisa branch no feature promise, sauksim, view branch;
    • Kad abi pabeidz, abi uztaisa pull request un samērdžo abus branchus iekš feature promise branch;
    • Ja kaut kas nestrādā, salabo tieši promise branch;
    • feature promise branch iemērdžo integration;
    • etc.

  22. Foruma migrācija

    in Atsauksmes, ierosinājumi, lamu vārdi

    Posted

    No otras puses - latviešu (latviešu valodā runājošo) skaits sarūk, tie paši ēd viens otru bez sāls. "Modīgāk" ir pirkt/lietot kaut kādu ārzemju "širpotrebu",  nekā mēģināt atbalstīt kaut kādus vietējo centienus (arī IT tehnoloģijās). Uz vienas rokas saskaitāmie programmētāji emigrē un valsts (nākotnes) politika pa lielam ir indiešu imports. utt

     

    :( ...

×
×
  • Create New...