11. December 2010

Cheat Sheet

Vývoj aplikácií je náročný. V dnešnej dobe je nutné čeliť rôznym API, prepájať heterogénne technológie a učiť sa nové prístupy.

Veľmi užitočnou pomôckou je stránka cheat-sheet.org.

Nájdete tu rôzne dokumenty pre technológie od výmyslu sveta. Z technológie je vždy vytiahnutá esencia, ktorá vám môže výrazne zjednodušiť vývoj a zlepšiť porozumenie implementovaným konceptom.

29. November 2010

Materiály z prednášky – Vývoj v C++

Aj tento rok som mal možnosť odprednášať jednu prednášku vrámci kurzu C++ na FI MUNI v Brne. Ďakujem Petrovi Švendovi za pozvanie.

Pribudlo niekoľko noviniek.

Predovšetkým kontinuálna integrácia, profiling a debugging. Zo zaujímavostí pribudlo Adobe Alchemy – kompilátor z C++ do ActionScript Virtual Machine2.

K dispozícii sú materiály z prednášky vo formáte PDF a ukážky vo formáte Tar.gz.

19. September 2010

Záznam z prednášky – Když něco rozeberem, tak leda debuggerem

Záznam z mojej minuloročnej prednášky z WebExpa 2009 – Když něco rozeberem, tak leda debuggerem. Ďakujem tímu WebExpa za spracovanie záznamu.

BTW: Nezabudnite sa zúčastniť aj WebExpa 2010, ktoré sa bude konať už za pár dní.

16. September 2010

Kde už Google App Enginu nestačí palivo

Google App Engine je kus zaujímavej oblačnej technológie. Hlavnou výhodou má byť “škálovateľnosť”. Či už na vašu aplikáciu pristupuje jeden človek alebo 10 000 naraz, App Engine by to mal ustáť.

Google App Engine podporuje Python a pred nejakým časom bola pridaná aj Java.

Nikto príliš nehovorí o cene, ktorú musíte za “škálovateľnosť” a voľný výpočetný výkon zaplatiť.

Veď App Engine je predsa free! Tak o akej cene tu píšem?

Jedná sa o cenu zaplatenú v architektúre aplikácie a možnostiach nasadenia.

Poďme sa pozrieť na jednotlivé obmedzenia.

1. We shall live in America. Aj keď vám to žiadny z oficiálnych zdrojov nepotvrdí, App Engine je hostovaný pravdepodobne zatiaľ len v USA. Doba reakcie a TTL tomu plne zodpovedá. Takže milí Európania, môžete si tak maximálne strúhať mrkvičku. Odozva bude vždy slabšia. Kolumbusovi trvalo predsa niekoľko mesiacov, než sa do Ameriky dostal. Paket to zvládne tam aj späť za veľmi krátky okamih. 🙂

2. Príliš malý traffic. Nepríjemná vec, ktorá sa vám stane pri vyložení Java aplikácie do Google cloudu je,  že na prvú odpoveď od aplikácie si chvíľku počkáte.  Bežne to znamená, že prvý požiadavok na aplikáciu bude obslúžený cca za 10-20 sekúnd. Pokiaľ je aplikácia neaktívna cca 2 minúty, stroje ju odstránia z pamäte. Ďalší návštevník musí čakať znova 10-20 sekúnd na odpoveď. Toto je veľmi nepríjemné hlavne pre tvorbu web aplikácie.

3. Len Google účty. Musíte použiť len Google účty a web API na overenie používateľov. Ostatné mechanizmy, ako napríklad security-constraint z BlazeDS, proste nefungujú. Takže nie je možné vytvoriť si vlastnú databázu používateľov.

4. Maily len pod identitou admina. Chcete v aplikácii rozosielať e-maily? Tak to je možné jedine tak, že ako odosielateľ je špecifikovaný e-mail administrátora aplikácie. Prípadne je ešte možné odoslať e-mail s identitou prihláseného používateľa.

5. Máme tvoj Google účet, máme všetky dáta. Na prácu na App Engine sa bežne používa Google účet. Čo inými slovami znamená, že pokiaľ niekto získa prístup k tomuto účtu, tak má prístup k údajom zo všetkých aplikácií.

6. Aj App Engine občas vypadne. S dostupnosťou App Enginu to nie je úplne slávne. Už niekoľko krát došlo k rozsiahlejším výpadkom App Enginu. Niekedy aj v rozsahu hodín. Dokonca pri jednom incidente došlo k strate “malého” objemu klientských dát. Prípady sú väčšinou zdokumentované v mailinglistoch k App Enginu.

7. Vlastný server? Zabudni. App Engine SDK obsahuje server, ktorý je možné spustiť lokálne. Je určený pre developerov, nie je možné ho nasadiť v produkčnom prostredí, hlavne pre nízke zabezpečenie a otvorené funkcie ako _ah/admin.

8. Vyloženie aplikácie môže trvať aj 15 minút. Občas sa proste App Enginu nechce pracovať. Niekedy trvá vyloženie aplikácie veľmi dlho. Tento prípad sa dá občas ošetriť pomocou použitia funkcie roll-back, ktorá odvolá aktuálne vykladanú verziu a skúsiť to znova.

9. Session ťa zožerie. Používanie session je proste veľmi zaujímavé a pokiaľ sa tomu nedokážete vyhnúť, zvážte použitie inej infraštruktúry, než je App Engine.

10. Až tak lacné to nie je. Výhodou App Enginu je to, že na začiatku nemusíte platiť nič za hosting a všetko funguje. Odporúčam si dopredu prepočítať cenu, ktorú zaplatíte za prekročenie “free” limitov aplikácie.

Inak je App Engine skvelý kus technológie. Pokiaľ vašej aplikácii nevadia predchádzajúce body, tak odporúčam App Engine a jeho komfortné prostredie.

6. September 2010

Indikátory pre softvérové projekty

Softvéru je kopec. Niektorý softvér prežíva a je udržiavaný len vďaka enormnému úsiliu a stratách na budgetoch. Iný softvér proste frčí jedna radosť.

Ako je možné zistiť nakoľko riskantné budú práce na softvérovom projekte? Zostavil som sadu indikátorov, ktoré umožňujú veľmi rýchlo zhodnotiť projekt. Pokiaľ je väčšina nasledujúcich indikátorov pre projekt pozitívna, malo by sa vedenie projektu zamyslieť (ak už nie je neskoro).

Indikátor 1. Tím nepoužíva version control. Toto je dnes už fatálny indikátor. Pokiaľ zistíte, že version control nie je na mieste, utekajte preč! Tak rýchlo ako sa len dá!

Indikátor 2. Tím kopíruje binárky a libky s programom priamo do version control. Toto indikuje typický zlý návyk a lenivosť ľudí. Zbytočné megabajty vo version control spomaľujú prácu a checkout projektu môže trvať aj 20 minút (v lepšom prípade). Pri snahe o drobnú opravu v kóde sa jednoducho strávi niekoľko hodín len checkoutovaním.

Indikátor 3. Tím builduje aplikácie pomocou IDE a nevie aplikáciu zbuildovať bez IDE. Silne sa obmedzujú možnosti nasadenia projektu.

Indikátor 4. Návod na deployment začína slovami: Skopírujeme tieto Jary/libky/rožky do adresára. Indikuje nezvládnutý alebo neexistujúci deployment postup. To je veľmi nebezpečné, v prípade poškodenia produkčného servera bude nahodenie trvať veľmi dlho, ak bude vôbec možné. Taktiež pridanie nového člena do tímu je veľmi drahé a časovo náročné.

Rozumným riešením použitie nástroja na automatizáciu, ako je napríklad Maven.

Indikátor 5. Tím nemá Wiki. Toto je veľmi zle, pretože znalosti sa strácajú. Nový člen tímu jednoducho nemá odkiaľ čerpať informácie, prečo je daný kus softvéru riešený tak ako je.

Indikátor 6. Tím nepoužíva softvér, ktorý vyvíja.

Indikátor 7. Tím alebo manažment považuje písanie testov len stratu času. Veľmi nebezpečné. Nesťažujte sa potom na straty na budgetoch.

Indikátor 8. Pred releasom nie je spustený ani unit-test, ani integračný test. Testuje sa na používateľovi, ktorý s tým ale vopred nesúhlasil.

Indikátor 9. Kontinuálna integrácia je pre tím cudzie slovo.

Indikátor 10. Neporiadok na stoloch a pracovisku. Tento nesoftvérový indikátor môže až prekvapivo dobre kopírovať stav serverových aplikácií.

27. July 2010

Zrýchlenie práce s Eclipse

Pokiaľ používate Eclipse, napríklad v kombinácii s Flash Builderom, určite sa pozrite na článok na blogu DevGirl. Nájdete tam veľa užitočných rád, ako zrýchliť prácu s IDE.

Pokiaľ máte čas, určite si pozrite nasledujúce video z konferencie Max 2009 – Flash Builder 4 Advanced Tips and Tricks

19. May 2010

Štartuje Firefox čoraz pomalšie?

Typickým problémom pri štarte Firefoxu je jeho pomalší a pomalší štart.

Kde je problém? Nevedia vývojári vyvíjať?

Vývojári vyvíjajú dobre. Aspoň jadro prehliadača má porovnateľnú efektivitu ako u susedných prehliadačov. Problém prinášajú rôzne rozširujúce doplnky. Nie všetky sú úplne ideálne vytvorené. Naviac pri štarte Firefoxu sa postupne inicializujú. Stačí niekoľko chybných alokácii a než sa Firefox spustí, máte 200 MB pamäte preč.

Autorov modulov by som rád požiadal, aby si občas prečítali nejaké to odporúčanie. Tiež je vhodné požiadať o review kódu. Často stačí drobná úprava a modul má mnohonásobne menšiu pamäťovú stopu.

Ako zrýchliť štart Firefoxu z pohľadu používateľa? Skúste vypnúť moduly a sledujte, čo sa deje. Typicky jeden z modulov je nenásytný a stačí ho výpnúť.

28. April 2010

Softvérová archeológia

Na SE-Radiu som narazil na jeden veľmi dobrý diel podcastu – Software Archeology s Daveom Thomasom, hovoril o softvérovej archeológii. Tento diel je podľa mňa esenciálny a softvérová archeológia by mala byť súčasťou vývojárskych kurzov.

Dave rozdelil softvérovú archeológiu na dve skupiny. Prvá skupina sa zaoberá výhradne len čítaním a snahám porozumieť dávno zaniknutým vývojárskym civilizáciam. Vyžaduje to trpezlivosť, znalosť jazykov a technológii.  Druhá skupina zahŕňa už aktívny prístup ku kódu a jeho modifikácie.

Softvérová archeológia je celkom nešťastne zamieňaná za prístup Indiana Jonesa, teda zahrabať sa do kódu a víťazoslávne z neho vytiahnuť artefakty. Artefakty sú dôležité. Avšak tak ako v archológii, to podstatné spočíva v snahe porozumieť kontextu a pochopiť kultúru.

Dave spomínal jednu zaujímavú techniku: zobrať zdrojový kód, otvoriť ho v editore a zmenšiť písmo na 2px. Stratí sa síce čitateľnosť, ale na povrch vypláva štruktúra kódu. Dokonca je ľahko odpozorovateľné, ktorý kód bol skopírovaný. Pri tak malom písme začnú byť zjavné opakujúce sa vzory v štruktúre kódu.

Dobrá bola aj jeho poznámka k písaniu dokumentácie. Pri archeologickej výprave je dôležité si uvedomiť, že dokumentácia klame. Často sa stane, že po zmene kódu už nie je aktualizovaná. Siahodlhé litánie v docstringu funkcie sú absolútne zbytočné, pretože sa nikto neunavuje to opravovať.

A teraz jeden veľmi zlomový postreh k písaniu dokumentácie v kóde: Pokiaľ dokumentujete ČO funkcia robí, tak je to zbytočné, tieto informácie odvodíte z kódu a z parametrov. Samozrejme krátky náčrt sa hodí, ale nemá význam popisovať všetko a podrobne. Dôležité je dokumentovať PREČO funkcia robí, to čo robí. Relatívne malý rozdiel v písaní textu, kompletné mení jeho kvalitu.

Pokiaľ neviete napísať PREČO funkcia má vôbec niečo robiť, nie je náhodou zbytočná? Nemáte náhodou nejasné zadania? Viete vôbec prečo to celé píšete? Tento prístup veľmi pripomína knihu od Simona Sineka – Start with Why.

Podľa Davida sú veľmi dôležité testy. Pretože testy, na rozdiel od dokumentácie, tak výrazne neklamú.

Pokiaľ sa niekto vydáte na púť archeológa, jednoznačne musíte byť vyzbrojený grepom. Asi najdôležitejší parameter grepu je pre archeológa -v, ktorý neguje výsledok vyhľadávania.

grep -r artefakt * | grep -v Indiana

Uvedený príklad vám pomôže násť všetky riadky so slovom artefakt, pričom tam nebude slovo Indiana.

Pokiaľ aktívne modifikujete kód, tak ako správny archeológ si najskôr nachystáte svoje prostredie a dáte kód do version control (napríklad Git).

Teraz sa môžete pustiť do modifikácii a testovania. Pokiaľ softvér vyžaduje veľa závislostí, uistite sa, že máte bootstrap skript, ktorý vám umožní OPAKOVANE vytvoriť prostredie pre archeologické pokusy. Ak takýto skript neexistuje, je vašou úlohou ho zostaviť. Vývojár/archeológ, ktorý príde po vás, vám nechá vyrobiť minimálne sochu na vašu počesť.

Kód je síce digitálny, ale hnije. Pokiaľ necháte rok stáť kód bez údržby, tak vám proste zhrdzavie.  Je veľmi dôležité si tento fakt uvedomiť. Rozbehnutie zhrdzaveného a zhnitého kódu môže stáť niekoľko dní práce. Dokonca v prípade, že neexistuje bootstrap skript, tú starú herku ani nerozbehnete.

Dave odporučil začínajúcim arechológom, aby si prešli kód interpretera pre jazyku, v ktorom píšu. Napríklad Perl, Python, Ruby alebo PHP. Takáto znalosť umožní lepšie pochopiť fungovanie a štrukturovanie kódu.

Z podcastu som vypichol tie body, ktoré ma najviac zaujali. Určite odporúčam, aby ste si vypočuli tento diel o Softvérovej arecheológii. Ušetrí vám to hodiny frustrácií z nezrozumiteľného kódu.

Niekedy to v archeológii môže dopadnúť aj takto – utekajúci developer opúšťa na svojom prskolete rútiace sa dátové centrum.

25. January 2010

Kompletný ebook – Vymyslite svoju vlastnú hru s Pythonom

Ani to nie je tak dávno, čo som tu písal o dôležitosti počítačových hier pre developerov a čuduj sa svete. Na internete je k dispozícii plná verzia elektronickej knihy Invent Your Own Computer Game with Python.

Kniha vás prevedie rôznymi oblasťami, ako napríklad detekcia kolízie objektov, sonar, grafika, animácia a zvuky. Je prehľadne spracovaná a zrozumiteľná pre laika. Je publikovaná pod licenciou Creative Commons.

Prajem príjemnú zábavu. Ak vytvoríte nejakú hru, nezabudnite poslať na ňu odkaz 😉

23. December 2009

Flixel vytvorte si hru pomocou Flexu

Flex je pekná technológia. Naprogramujete aplikáciu a funguje na všetkých bežných operačných systémoch. Dokonca pomocou Adobe AIR môžete aplikáciu preniesť na desktop.

Dlho mi chýbala nejaká rozumná jednoduchá knižnica, ktorá by sa dala použiť pri tvorbe jednoduchých hier. Niečo ako Allegro pre C++ alebo PyGame pre Python. Už som sa vzdával nádeje a tu zrazu..

Tu sa objavil Flixel. Malá knižnica, možno lepšie povedané sada zdrojových kódov. Flixel rieši všetky bežné veci, s ktorými sa vývojár stretne. Napríklad detekcia kolízie objektov, prepínanie medzi herným menu a hrou alebo animácie postavičiek.

K dispozícii je aj podrobný tutoriál, ako si postaviť hru. Jediný problém je, že je trošku zastaralý a tak záujemcom odporúčam sledovať GIT repository.

Naviac pre vývojárov hier je tu ďalšia novinka. Adobe spustilo oficiálne Flash Platform Game Technology Center.

Ak máte nejakú zaujímavú Flash/Flex hru, dajte o nej vedieť 😉

  • Where’s the fish?

  • Translations

  • Further info

  • Twitter

    Follow @jurajmichalek on twitter.

  • Comments

  • Tags

  • Topics