F3llony

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.

Vēl pretīgāku, haotiskāku un nelasāmāku kodu neesmu redzējis.

Atkarīgs, kurai valstij...

Nav runa individuāli, bet kā kompānijas politika.

Da kas tu vispār par programmētāju esi... Ne fotošopa, ne indizaina, ne korela, ne siebel...

Ja zem galda, 0% nodokļos. Jo nodokļus maksāt ir stulbi, vai ne?

mīnus kaut kādi 40% nodokļos... Labāk kā vidēji ir, bet...

http://twodaymanifesto.com Domas?

WYSIWYG... Ok. Nu labi, kaut kādam corporate single page varbūt ar...

Producteev ir okei, ja ir maz darbu :D JIRA Agile otherwise. Kodu hostēt - bitbucket, saziņai - viennozīmīgi Slack. Par dokumentāciju - vai nu rakstiet wiki, vai nu izmanto PHPdocmd + phpdoc, vai vislabāk - behat.

Not bad. P.S. nolāpītais macbook nejēdz rādīties uz mana ārējā moņa - HP 23xi caur HDMI nedarbojas. Jāprovē būs tb uz dvi. :<

Nu ja - docks, pie ārējā moņa/iem, klavieres un aidā. Maciem gan nav doku. Which kind of sucks, ņemot vērā auditoriju.

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

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ē.

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.

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.

Veel viens jautajums ir maintenance. Nebus saapiigi turet php stack un visu parejo up to date? Tas homebrew ir usable more or less?

Es neteicu konkreti problemas, es prasiju vai ir kas tads, kas man butu jazina. Neko vairak, ka lurejis memes uz osx neesmu since Roma veel bija impeerija, so...

Kāds ikdienā lieto Mac strādājot pie PHP? Ir kas tāds, kas man būtu jāzina, ko man nepateiks Google?

Š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.

Vispirms ir jāvienojas par GIT workflowu, jeb veidu, kā strādāsiet. Viens no vienkāršākajem flowiem ir šis: Ir master branch. Master branch izmaiņas pa tiešo nekad neveic; Ir integration branch - integration branch ir branch kurā tiek mergotas visas izmaiņas; Ir feature branchi - katrai atsevišķai funkcijai; Mēģinam šadi: Tiek izdomāts kaut kāds darbs, piemēram, pievienot pogu kaut kādā skatā; Cilvēks no master (!!!) branch izveido jaunu branch, sauksim par "add-view-button" branch. Šis būs mūsu feature branch; Code, code, code; Autors "add-view-branch" izveido pull request pret integration (!!!) branch; Kāds cits izlasa un pārbauda kodu, apstiprina pull request; Konkrēto pull request iemērdžo integration (!!!) branch; Atkārtojam pāris reizes; 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.

:( ...

http://en.wikipedia.org/wiki/Toyota_Production_System + google

> Verifying DMI pool data .......................... > Pool rather pleasant

:D