nedeľa 17. decembra 2017

Oci, môžem...?

Každý vie, že táto vec je úplná bomba a preto hľadáme, kde by sa dala na našom projekte použiť tak, aby aspoň trochu dávala zmysel. Niekedy treba viac prižmúriť oči, alebo zabudnúť na nástrahy argumentačných klamov a zrazu ostane už len jedna prekážka -  technický líder. Ak ste to vy, prosím, čítajte ďalej.

Nie

Vieme, že dobrý vývojár sa neustále zdokonaľuje a posúva vo svojom remesle. Ako sa to však deje? Čítaním knižiek a počúvaním podcastov? Navštevovaním meetupov a konferencií? Samotným programovaním? Tým všetkým, a mnohým ďalším, u každého však v individuálnom pomere. A kedy sa to deje? Vo voľnom čase? V spánku? V práci? Opäť je to u každého rôzne. Niektorí vývojári dokážu aj po celom pracovnom dni ešte po večeroch robiť na vedľajších projektoch. Veľa iných však nie - či už kvôli ďalším záujmom, rodine alebo jednoducho potrebujú vypnúť. Pre túto druhú skupinu je často veľkou motiváciou dostať sa vrámci každodennej práce k novým veciam, to nie je žiadne tajomstvo. No vy sa snažíte projekt uchrániť pred blúdením v spleti uličiek, z ktorých mnohé sú slepé. Takže nie, nič nové, ide sa ďalej tak, ako doteraz. Skúsme sa ale zamyslieť nad tým, o čo môžete prichádzať.

Áno

V prvom rade je to zlepšenie výkonnosti a koncentrácie. Iste, možno sa hneď nezlepší výkon tímu z hľadiska priameho dopadu na produkt, ale zainteresovaní členovia budú znova makať na 200% - tak, ako keď projekt ešte len začínal a bolo treba všetko vymyslieť. Možno budete dokonca musieť niektorých upozorniť, aby nerobili toľko nadčasov. A aj keby to nakoniec nevyšlo, takáto skúsenosť posunie všetkých, tím aj jednotlivcov, o riadny kus vpred. Zvyšuje to motiváciu zostať s tímom dlhšie a stavím sa, že to radi vytiahnete pred kandidátmi počas hľadania nových ľudí.

Pri diskusii o zavádzaní noviniek by ste nemali dávať prehnané požiadavky na výsledok, skôr sa snažte čo najpresnejšie zistiť, aké konkrétne prínosy navrhovatelia očakávajú. Mali by ste im pomôcť zvalidovať ich návrh. Nie je správne striktne vyžadovať prísľub, že daná vec napríklad skráti čas potrebný na vývoj ďalších požiadaviek o polovicu. Áno, môže to byť cieľ, ale v prvej fáze aj tak nikto nevie presne odhadnúť výsledok. Radšej sa ich popýtajte, čo plánujú robiť v prípade, že sa cieľ nepodarí dosiahnuť.

Ak sa rozhodnete dať návrhu šancu, poskytnite adekvátne zdroje na jeho realizáciu. Keď sa implementácia dlho naťahuje, počiatočné nadšenie vyprchá, celé to pôjde do stratena a ľahko sa zaseje semienko vzájomnej nedôvery. Vy totiž môžete nadobudnúť pocit, že vývojári nevedia odhadnúť, čo zvládnu, oni zas, že ich dostatočne nepodporujete.

Ak viete, že máte naozaj dobrý tím, nemusíte sa obávať toho, ako sa zachovajú, keď ich navrhované riešenie prinesie nové problémy. Skôr či neskôr sa tak isto stane. Ak vedeli riešiť doterajšie, budú vedieť riešiť aj tieto nové. Kto to robí teraz? Myslíte si, že sa na ne vykašle, ak budú spôsobené tým čo sám presadzoval? Nie. A je veľká šanca, že sa do toho pustí s väčšou vervou.

Každá sranda niečo stojí

Musí byť dostatočne zrejmé, že hoci ste novým veciam otvorený, ich prijímanie nie je samozrejmosť. Nie vždy sa to dá a zakaždým o to treba zabojovať odznova. V ideálnom prípade tím sám cíti, či sa to v danom prípade skutočne oplatí a kedy je na to z hľadiska projektu vhodná doba. Snáď málokto by chcel pri niekoľkoročnom projekte robiť zásadné zmeny každý mesiac.

A čo riziká? Áno je ich dosť a vy si ich určite uvedomujete. Najmä v prípade neskúseného tímu sa veci môžu ľahko vymknúť z pod kontroly, takže dvojnásobná opatrnosť je na mieste. Ak ste dostali do rúk zodpovednosť za technické smerovanie projektu, znamená to, že vám ľudia veria a viete robiť dobré rozhodnutia. Dúfam, že vám tento článok ukázal zopár dôvodov, prečo sa niekedy oplatí odpovedať "áno".

sobota 4. februára 2017

Oplatí sa začať s React Native?

Naši obchodníci predali zákazníkovi mobilnú aplikáciu a ako to už býva, nespýtali sa ľudí z developmentu, dokedy ju môžeme dodať, lež si povedali, že bude hotová o necelý mesiac. Pre Android a iOS. Interne sme nikdy mobilné aplikácie nevyvýjali, ale padlo rozhodnutie, že to spravíme sami. Potešil som sa, že táto úloha pripadla ma mňa.

Ak nerátam preklikanie krátkeho tutoriálu k vývoju pre Android, nemal som predchádzajúce skúsenosti s programovaním pre mobilné zariadenia. Zato som ostatné mesiace dosť robil s Reactom pre web, takže ma prirodzene lákalo použiť React Native. V ňom viete spraviť mobilnú aplikáciu, ktorá používa natívne komponenty, pričom vy ju píšete v JavaScripte a Reacte. Trochu som si o tom prečítal a skúsil spraviť maličký proof-of-concept: išlo to naozaj jednoducho. Ešte som pohľadal články so skúsenosťami z reálneho nasadenia a porovnania s inými frameworkami a povedal som si, že do toho idem.

Learn Once, Write Anywhere

Keďže React Native nevznikal naraz pre obe hlavné mobilné platformy, veľa komponentov je spravených špeciálne pre jednu z nich. Prínosom je, že aplikáciu píšete veľmi podobne pre obe z nich - zväčša iba použijete iný komponent. Môžete dokonca v kóde "if-ovať" bloky v závislosti od platformy, na ktorej aplikácia práve beží, alebo jednoducho zmenou prípony zdrojového súboru poviete, pre ktorú platformu sa má použiť. Tým pádom môžete naozaj vyťažiť maximum z komponentov špecifických pre konkrétny operačný systém.

Čo som si ale všimol, tak veľa nových komponentov je robených tak, aby sa dali použiť pre obe platformy. To je samozrejme pohodlné a keďže naša aplikácia nevyžadovala nejaké extrémne veci, vždy som sa snažil vyberať práve takéto komponenty. Dokonca existujú aj také, ktoré zoberú dva iné komponenty a vytvoria pre ne jednotné API. Po pridaní nového komponentu odporúčam aplikáciu pretestovať na rôznych systémoch, pretože sa mi stalo, že hoci je API rovnaké, na jednom systéme sa predsa len môže správať trochu inak. Stalo sa aj to, že pre Android som musel zadať komponentu iné parametre ako pre iOS.

Aj keď píšete aplikáciu iba pre jednu platformu, oplatí sa vám React Native použiť - špeciálne ak už máte skúsenosti s JavaScriptom, resp. priamo s Reactom. Môžete tak využiť znalosť jazyka, hot reloading kódu počas vývoja či jednoduchú tvorbu layoutov podobne ako s flex-box v CSS, pričom na spodu vám bežia skutočné natívne komponenty danej platformy. Zaujímavé možnosti prináša nasadenie novej verzie pomocou CodePush - toto som ale zatiaľ neskúšal.

Trochu šarapaty, najmä pre autorov knižníc, robilo vydávanie nových verzií React Native každé dva týždne. Od Decembra 2016 sa frekvencia zmenila na mesačnú, navyše pribudol nástroj na jednoduchšiu migráciu na novšiu verziu.

Knižnice, ktoré sa osvedčili

Na uchovávanie stavu aplikácie som zvolil Redux. Táto knižnica nie je iba pre React, avšak práve spolu s ním sa častou používa. Veľa sa diskutuje, či sa ho v menších aplikáciách oplatí mať alebo nie. Ja ho používam, pretože ten stav aj tak niekde musím držať a ak niekto iný potrebuje robiť zmeny v mojom kóde, stačí, keď si naštuduje Redux a bude sa vedieť zorientovať. Navyše okolo neho existuje niekoľko užitočných nástrojov, ktorými môžete sledovať stav vašej aplikácie a jeho zmeny (napr. Logger for Redux, Remote Redux DevTools). Mimochodom, veľmi pekné vysvetlenie princípu priamo od autora Reduxu si môžete pozrieť na egghead.

Na HTTP requesty používam knižnicu axios, ktorá má promise-based API, takže podporuje async/await, čo sprehľadňuje zdrojové texty.
Čítanie QR kódu zvláda react-native-camera (pozor pri zadávaní typu, ak to ešte neopravili, pre iOS: 'org.iso.QRCode', pre Android: 'QR_CODE').
Navigáciu robím pomocou React Native Router. S tým som musel trochu zabojovať, keď som pridával bočné menu.
Pekné naštýlované komponenty nájdete v react-native-elements.

Na jednej obrazovke som potreboval kresliť vlastný graf (resp. niečo, čo by sa tak dalo nazvať). Našťastie existuje knižnica react-native-svg, pomocou ktorej si kreslíte v SVG. Opäť super pohodlné, keďže s SVG som už viackrát robil veci pre web. Dokonca nad objetkami fungujú udalosti, takže ľahko spravíte aj interaktívne obrázky.

Koľko toho treba vedieť o natívnych platformách

Zo začiatku potrebujete vedieť hlavne ako dostať aplikáciu do mobilu koncového používateľa. Väčšina tutoriálov o React Native túto časť nerozoberala, takže som si musel popozerať veci priamo z dokumentácie k tej-ktorej platforme (čo je pochopiteľné). Produkčný build pre Android viete spraviť z príkazového riadku, pre iOS otváram XCode. Stránky Google aj Apple mi pripadali trochu ťažkopádne, ale zvykol som si. Aj tu odporúčam si to vyskúšať hneď na začiatku vývoja aplikácie a nečakať, kým "to bude hotové". Ja mám všeobecne rád, keď mám pokryté všetko od písania kódu až po nasadenie a viem, že môžem dodať novú veriu do produkcie, keď treba. Na beta testovanie sa nevyžaduje review aplikácie (ok, u Apple je to obmedzené iba na interné testovanie). Nové knižnice už používajú react-native link na pridanie natívnych závislostí, bez potreby ručne upravovať konfiguračné súbory.

Ak ste typ, ktorý chce hneď začať vo veľkom, pozrite sa na Ignite, ktorý má pripravenú solídnu kostru pre vašu aplikáciu.

Zhodnotenie

Ako so všetkým novým, s čím prichádzam do styku, aj tu mi chvíľu trvalo, kým som sa poriadne zorientoval. Hoci jednotlivé knižnice majú v sebe bugy a "badžíky", na ktoré si treba zvyknúť, považujem React Native za vhodný do ostrého nasadenia. A pokiaľ nerobíte naozaj hardcore aplikáciu, ktorá potrebuje operačný systém vyžmýchať do poslednej kvapky, s React Native budete veľmi produktívny. Navyše sa okolo neho stále veľa deje a každú chvíľu pribúdajú nové užitočné veci.

Ups...

Jeden zo zákazníkov chcel aplikáciu používať s MobileIron na Androide. Keď ju skúsili zawrapovať, po spustení sa ihneď vypla. Podľa logov to vyzeralo, že k samotnému štartu našej aplikácie ani nestihlo prísť. Niekde v inicializačnom kóde wrapperu sa to zastavilo. Hlásili to tvorcom MobileIron, tí im po niekoľkých dňoch odpísali, že react-native aplikácie nepodporujú. Zákazník ani my sme to ďalej neriešili, lebo sa rozhodli nakoniec aplikáciu používať mimo MobileIron. Možno by to predsa len nejako išlo - ak s tým máte skúsenosti, dúfam, že sa podelíte.

Užitočné odkazy

https://facebook.github.io/react-native/ - prvý odkaz z Google pre React Native :)
https://medium.com/@dabit3 - blog Nadera Dabita, ktorý sa venuje React Native
https://devchat.tv/react-native-radio - podcast o React Native
https://www.gieson.com/Library/projects/utilities/icon_slayer/ - nástroj na tvorbu ikon so správnou veľkosťou pre iOS aj Android z vami nahratého obrázku

nedeľa 29. januára 2017

Z Javy do Javascriptu? (2) Komunita

V predošlom článku som v krátkosti načrtol moje skúsenosti s Javou a Javascriptom. V tomto opíšem môj pohľad na komunitu, ktorá ich obklopuje. Táto téma je veľmi široká, ja z nej vyberiem iba tie časti, ktoré vnímam najsilnejšie.

Široká a ustálená komunita okolo Javy


Komunita okolo Javy mi vždy pripadala v poriadku. Open-source knižníc je neúrekom a aj veľký hráči takto zverejňujú svoje projekty. Je možné nájsť dostatok informácií na blogoch a Stack Overflow. Z problémov, ktoré sa tam riešia vidno veľkú rôznorodosť ľudí z komunity. Celkovo vo mne budí pocit takej mravčej práce, kde ludia-mravčeky majú svoj cieľ a vidia cestu, ako ho dosiahnuť.

Častokrát to zvonka vyzerá, že sa vlastne v tej Jave toho už veľa nedeje, ale ja si nemyslím, že je to tak. Pod povrchom sa vždy vynárajú zaujímavé prístupy, ktoré menia veci vo veľkom, hoci Java platforma ostáva rovnaká. Spomeniem napríklad vlny okolo DevOps, Micro Services, problematika okolo distribuovaných systémov a Eventual Consistency. Áno, nie sú to témy, ktoré by sa týkali výlučne alebo prišli iba z Javy, ale ako sa ukazuje, platforma je dostatočne robustná na to, aby sa dali riešiť bez veľkých zásahov do nej. Preto si myslím, že pri posudzovaní, čo nové sa okolo Javy deje treba brať väčší ohľad práve aj na to, čo sa deje okolo takýchto tém.

Nadšená JavaScriptová komunita

JavaScript má úžasnú kominitu. Je z nej cítil veľmi veľká energia a celkové nadšenie mi pripadá omnoho väčšie oproti Jave. Ale nemôžem si pomôcť, veľakrát mi to pripomína takú úprimnú detskú radosť nad novou hračkou. Príde nejaká nová utilitka, knižnica UI komponentov alebo vylepšenie balíkovacieho systému a na Twittery, blogoch a podcastoch čítate a počujete, ako sa z toho ľudia tešia. Samozrejme, je to nákazlivé a to je dobré. Len potom zistíte, že buď nemáte čas sa so všetkymi tými hračkami pohrať, alebo naopak, nerobíte nič iné iba sa hráte - našťastie, voľba je na vás.

Materiálov je na internete veľa, avšak veľmi rýchlo sa stávajú neaktuálnymi, pretože veci, ktoré popisujú sa rapídne menia. Toto sa týka aj kníh, veď na niektoré nové frameworky je ťažké vôbec nejakú dobrú nájsť a keď aj nejaká vyšla pred rokom-dvoma, je treba dobre zvážiť, či sa do nej oplatí investovať. Hľadať v takýchto knihách best practices je na pováženie, pretože tie sa tiež rýchlo menia. Avšak nie je to úplne zbytočné, najmä ak sa potrebujete zorientovať v niečom s čím ste ešte nerobili - po čase si budete na ich základe vedieť odvodiť vlastné best practices pre nové veci.

Je možné identifikovať spoločnosti a jednotlivcov, ktorý majú na ďalšie smerovanie výrazný vply. Je potešujúce, že sú to naozaj šikovný ľudia, ktorý sa dostali do popredia svojou prácou a že sú schopný navzájom sa dopĺňať a inšpirovať a zdá sa mi, že voči sebe majú taký zdravý rešpekt.

Veľa ľudí je uchvátených tým, na akých všemožných zariadeniach a platformách sa dá JavaScript spustiť. Komunita si užíva, že sa z neho stáva univerzálny jazyk (resp. platforma), ktorým možno pokryť celé spektrum use casov. Uvidíme, či toto súčasné momentum vydrží, ak áno, tak sa teším na prvý request, keď budem mať naprogramovať niečo pre žiarovku.

Konferenčný paradox

Obe komunity sú dostatočne veľké na to, aby sme sa ani v jednom prípade nemuseli obávať, že v tom ostaneme sami. A tiež sú schopné naplniť "konferenčný paradok", ktorý znamená, že ak ste na konferencii, kde sa rieši jedna z týchto platforiem, máte pocit, že sa okolo nej točí všetko a že všetci ju už používajú alebo sa na ňu chystajú prejsť a tá druhá je len "tá druhá". Ak si radšej prehlbujete znalosti do hĺbky než do šírky, možno bude pre vašu psychickú pohodu lepšie, ak tomu podľahnete.

Pokračovanie nabudúce...

Na tento článok by som chcel neskôr nadviazať, aby by som priblížil ďalšie témy, ktoré sa mi pri porovnávaní Javy a JavaScriptu vynárajú.