Also, uvitam sanci pobavit se s kazdym, jak veci lip automatizovat a usnadnit, obzvlast kdo ma svoje osvedceny techniky - chodte na srazy :)
- snajpa
Sent from Windows Phone without swiping a credit card
Co rikas je jenom ze neovladas svoje pracovni prostredi dostatecne, abys mohl byt nasobne efektivnejsi :)
Je to vecny tradeoff mezi vlozenou casovou investici a beznou naslednou efektivitou, o cviku veci automatizovat a nebat se napsat si jednou skript nebo dat dohromady reseni a potom ho pouzivat. Vsichni profesionalove nakonec dospejou k rade vlastnich - podle personality ruzne obskurnich - procesnich automatizaci. Kdo tohle chape a obcas pouzije svuj cas, aby priste mohl venovat trochu min casu rutine a vic kreativni cinnosti, je efektivnejsi a potrebuje min casu na stejnou praci, nez ostatni.
Na konci jde vzdycky o vysledky, konkretni nastroje jsou jedno, dulezity je umet si predstavit neprijemnou rutinu, co delam porad a nebavi mne vcelku a vyhazet odtamtud bordel, ie. automatizovat. At uz sebe naucit bejt efektivnejsi, nebo si vyrobit vlastni tooling.
Napr. zminena situace s gitem je vlastne o tom, ze
a) ti vadi, ze nekdo uvidi, jak delas s gitem bordel - well, lidi uz prasili mnohem vic s horsima technologiema, git je super zpusob, jak distribuovat data mezi vice nodama (dev laptop, klidne nekolik testing verzi, jedna nebo vic - distributed - production nodes)... jde o to, ze mit data distribuovane ma svoje vyhody napr. v nezavislosti na siti pri praci lokalne, dulezita je sit jenom na sync.
b) nikdo poradne neozrejmil vyvojarum, ze neni problem si i na windowsech rozjet virtualni masinu, ktera na sobe bude mit prostredi, jak vypada production, ciste kvuli vyvoji. Tam potom neni problem vyvijet ve svem oblibenem editoru (tm) a treba ja si mountuju takhle data pres NFSv3, kazdy podle gusta :)
Pointa je, ze kdyz se clovek dostatecne technologicky zaridi, muze svoji praci delat z libovolny kavarnicky v Parizi, muze sedet (se spravnym operatorem) na Slovensku v Tatrach v kavarne J&T :D, whatever, sitova latence a latence devel prostredi nemusi byt problem odnikud.
Vypocetni vykon kazdeho normalniho notebooku staci na dev VM(s) 99% projektu, co jsem u nas kdy videl hostovat, jenom se tomu clovek nesmi bat dat sanci a pokusit se zmenit svoji workflow.
S dostatecnym zamyslenim dopredu clovek vyresi napriklad veci jako disaster recovery (notebook mi ukradnou nekde v bananistanu protoze vzivote nevideli hybajici se obrazky), ochranu proti vlastni blbosti (ku*a updatovat OS pri pripojeni s SLA 33.333% neni nejstastnejsi napad - snapshotovatelnost), spolupraci s ostatnima na projektu nebo jenom experimentovani - branching, atd.
Zalezi, jak seriozne se tomu clovek venuje s jakou koncentraci po jakou dobu, ale daji se delat divy, staci chtit, po netu se vali strasny mnozstvi vylepsovaku pro snad vsechny platformy.
Ve vpsFree je uz delsi dobu postupne snaha usnadnit vyvoj, pomalu se dostavame napr. k zajimavejsim nastrojum, nez jsou ted playgroundy - mam ideu, jak udelat syncovani VPS z vpsFree playgroundu do VM lokalne (VBox, KVM, ...), kde by mohl bezet lokalni vpsAdmin a na nem lokalni prostredi, jeste je par veci, co jsem v navrhu nevyresil a tak to jeste neprislo, ale je to v pipeline :) Pak by se dalo vyvijet lokalne a branchovat ve vpsAdminu a poslat to do vpsFree produkce kliknutim. Uplne jednoduchy ten proces asi nebude nikdy, porad bude potreba vedet, co to na pozadi dela, aby se tomu mohl clovek prizpusobit, jelikoz takovou fancy myslenku nejde uplne zuniverzalnit - napr. je potreba se zamyslet, ze IP nebude sedet, napsat navod, ktery takove veci obsahuje.
Automatizace je moje srdcovka a dokud se ze mne Aither a ostatni nezblazni, budem inovovat po svym, stejne jako v dalsich vecech, jako moznost to cele prostredi ovladat pres API/CLI/web/..., aneb propojme vpsFree s toustovacem.
Koukam, jsem se nechal unyst ;)
-snajpa
PS, dobrovolnici slehnuti dostatecne hrat si s Ruby API od Aithera (celkem fancy kod, co se pekne rozviji) a/nebo PHP kodem (ten pres vsechny moje snahy zabit to neprehlednosti uvodni implementace bohuzel preziva do dnes a je potreba to dovykuchat a prepsat do Ruby, do ty doby maintenance silenyho kodu muze taky nekoho bavit, kdybyste nemeli dost na co nadavat, muj mail znate).
Sent from your iPad
Já jsem git zkoušel už několikrát a vždycky mi to testování spíš zkomplikuje. Já nejsem moc na lokální testování. Takhle když mi nějaký uživatel nahlásí bug, tak ho metodou pokus omyl třeba na třetí pokus za pár minut společně opravíme. Lokálně bych 5-10 minut strávil jen tím, že bych se pokoušel přesně nasimulovat situaci, ve které se uživatel nachází. Když to budu pushovat do master větve, vyústí to třeba v několik commitů, které nic neřeší a to se mi nelíbí. Jo můžu to amendovat nebo to pak squashnout, ale to taky není moc čisté, když už se to děje ve veřejném repositáři. Mohl bych to commitovat do jiné větve a deployovat jinam, ale pak bych toho uživatele musel navést na jinou adresu a nutit ho se tam znovu přihlašovat, když to má přitom přímo před sebou. Tu testovací verzi o které jsem mluvil mám spíše na nové featury, kdy mám pár vybraných kolegů, kteří to tam otestují zepředu zezadu. Tam mi to dává smysl. Nevím jestli tohle debugování s krátkou feedback smyčkou má nějaké elegantní řešení. Možná mi povíte jak to děláte.