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.
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.
Flash Builder Burrito obsahuje skutočne zaujímavé vylepšenie pra vývojárov.
Andrew Shorten v krátkom videu priblíži pár vylepšení.
Ďalšie novinky a Flash Builder nájdete na labs.adobe.com.
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í.
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.
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í.
Piotr Walczyszyn zverejnil užitočnú aplikáciu – as3term.
Jedná sa o jednoduchý terminál. Do aplikácie je možné vložiť kód v ActionScripte a pozrieť si jej výsledok. Skompilovanie a spustenie kódu sa aktivuje pomocou Shift+Enter.
Na správne fungovanie aplikácie potrebujete kompilátor z Flex SDK.
Na nasledujúcom videu Piotr ukazuje ako celá vec funguje.
Marti Malý napísal vynikajúcu glosu, ktorú by si mala väčšina softvéristov zavesiť nad počítač.
Odporúčam! Glosu nájdete na stránkach zdrojak.cz: Uživatelé nejsou programátoři!
Článok zachytáva jednu veľmi podstatnú vec: Softvér je určený pre niekoho a autor nemusí vôbec patriť do cieľovej skupiny.
Zoberte si marketing. Marketér/obchodník musí hneď na začiatku vedieť akej skupine chce produkt predať. Podľa toho vyrobí kampaň a zvolí štýl komunikácie. V softverárčine to vôbec nie je samozrejmé. Veľké množstvo aplikácii a programov vôbec nemá definovanú cieľovú skupinu. Prípadne cieli na informatikov. A výsledok?
Fatal total error. Uživatel NULL provedl neplatnou operaci #1241.
Update: Ďalšia dobrá reakcia na túto tému je na blogu Schidlo.cz.
ItemRenderer je jeden z kľúčových konceptov potrebných na vytvorenie tabuľky, ktorá obsahuje okrem bežných údajov aj obrázky.
ItemRenderer funguje tak, že tabuľka/zoznam si pre každú viditeľnú položku vytvorí inštanciu itemRenderera. ItemRenderer je vizuálna komponenta, ktorá obsahuje napríklad políčko s textom. Tejto inštancii je potom predaný objekt reprezentujúci riadok tabuľky/zoznamu. Pri posune v tabuľke je itemRenderer zrecyklovaný a sú mu nastavené nové údaje, ktoré ma vyrendrovať. Recykláciou sa šetrí veľké množstvo procesného výkonu.
Ukážka:
Každý ItemRenderer vyzerá rovnako. Ako je možné zabezpečiť, aby každý itemRenderer vyzeral trochu inak na základe svojho obsahu. Napríklad chceme, aby sa zobrazil text, ak má rendrovaný objekt nastavený atribút content. Ďalej chceme, aby sa zobrazil obrázok, ak má objekt nastavený atribút image. Výsledok by mal vyzerať takto:
Ako na to? Odpoveď je prekvapivo jednoduchá. Aj pre itemRenderer je možné využiť mechanizmus stavov. Medzi jednotlivými zobrazeniami sa dá jednoducho prepínať tak, že ItemRendereru nastavíte jeho hodnotu currentState. O zbytok sa už postará Flex.
Pekne je táto problematika spracovaná v článku Understanding Flex itemRenderers – Part 4. od Petra Enta. Poznámka k Petrovmu článku: pre ďalšie stránky článku je nutné ťuknúť na šipku nad komentármi.
Pokiaľ chceme na Linuxe pracovať s AIRom cez príkazový riadok, je možné použiť adl. Ak sa však pokúsime adl spustiť, dostaneme nasledujúcu chybu:
adl: cannot execute binary file
Pomocou príkazu file zistíme, čo je to adl za súbor, dostanete:
adl: Mach-O executable i386
Adl zjavne nie je linuxový súbor. Kde je problém?
SDK získane z opensource.adobe.com neobsahuje totiž linuxovú verziu pre adl.
Oprava? Stačí prevziať Adobe AIR SDK pre Linux. Rozbalíme ho priamo do adresára s SDK a prepíšeme adl.
Na stránkach ideas.adobe.com je dokonca hlasovanie za opravu tohoto problému.
