September 19, 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í.

September 16, 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.

September 6, 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í.

August 18, 2010

Užitočný príkaz: sl

Príkaz ls vypíše zoznam súborov. Nič prekvapivého. No, až na tú lokomotívu.

Každý správny administrátor na server nainštaluje balík sl 🙂

Používatelia sa potom nestíhajú čudovať, koľko lokomotív im behá po termináloch. Dokonca niektoré aj lietajú.


Aké parametre podporuje sl?

-a – stala sa nehoda, ľudia vo vlaku volajú o pomoc

-l – malá lokomotíva

-F – lietajúca lokomotíva

-e – povolí prerušenie pomocou CTRL+C

Autorom programu sl je Toyoda Masashi.

Za odkaz na tento skvelý príkaz ďakujem Weslymu.

August 13, 2010

Viacriadkový príkaz v baťáku

Pokiaľ človek potrebuje rozdeliť jeden dlhý riadok s príkazom na viac menších, tak sa dá použiť znak ^. Znak striešky sa uvedie na konci riadku. Za týmto znakom už nič nenasleduje a pokračuje sa na ďalšom riadku.

Príklad kompilácie AIR aplikácie pomocou bat súboru vo Windows:

amxmlc -output build/build.swf ^
-locale en_US -library-path+=libs ^
-include-libraries+=e:\automation\automation.swc ^
-include-libraries+=libs\automation_monkey.swc ^
-- src/Main.mxml

Znalci shell skriptov zase vedia, že v shell skriptoch sa na rovnaký účel používa znak: \

August 11, 2010

Google App Engine – prístup k lokálnemu datastore

Ako sa dostať k obsahu dátového úložiska pri vývoji aplikácie pre Google App Engine?

Jednoducho:

http://localhost:8080/_ah/admin

Zobrazí sa vám lokálna verzia vývojárskej konzoly.

Zdroj: http://stackoverflow.com

Júl 27, 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

Jún 24, 2010

Zváračský kurz pre web technológie bude aj na BarCampe

Radostná správa! 26.6. budem prednášať na BarCampe na FI v Brne.

Príďte povzbudzovať 😉

A ako je dobrým zvykom, pre verných čitateľov blogu je nachystaný drobný bonus. Po prednáške sa za mnou zastavte s heslom: “Když něco rozeberem, tak leda debuggerem.” 🙂

Jún 24, 2010

Neviditeľnosť softvéru je závažný problém

Už ste si skúsili postaviť vlastný hadrónový urýchľovač? Takú stavbu si aspoň niekto všimne.

V softvérarskom svete sme na tom horšie. Môžete postaviť kompletné vesmírne stredisko a nikto si toho ani nevšimne. Ľudia vidia zo softvéru len jeho rozhranie. V tom bežnejšom prípade si ho všimnú iba keď nefunguje. Prípadne vtedy, keď im zlé zaoukrúhľovanie zožerie polku výplaty.

Skúsme sa na to pozrieť inak. Poznáte také mestá ako Košice (234 000 obyvateľov), Brno (383 000 obyvateľov), Považská (42 000 obyvateľov)? Prípadne dedinky ako Šanghaj (9 000 000 obyvateľov)?

Mesto má svoju štruktúru. Sú v ňom budovy s architektúrou, ale aj bez architektúry. Mesto rastie a mení sa. Tu ľudia niečo zbúrajú, tu niečo postavia.

A tak je to aj so softvérom. Vývojári zistia, že 10 rokov starý kód nevyhovuje požiadavkam, tak sa ho rozhodnú odstrániť. Musia postupovať opatrne. Celý proces je zložitý, pretože na tom kóde žije niekoľko stoviek klientských aplikácií. Jednoducho si nemôžu dovoliť len tak prísť a zdemolovať kus centra. Teda môžu, ale bude to mať svoje dôsledky a cenu.

Softvér so sebou nesie jeden veľký problém a tým je práve jeho neviditeľnosť. Ľudia si ho nedokážu predstaviť tak jednoducho ako mesto. Mestom sa stačí prejsť a človek získa aspoň chabý pocit, že sa tam vyzná.

Koľko vývojárskych hodín sa stratilo v uliciach systémov, pretože nikto nenechal prichádzajúcim turistom/vývojárom mapu? Veľa, veľmi veľa. Pritom každé väčšie mesto má nejakú tú turistickú kanceláriu 😉

Tak ako mesto je živé, len pokiaľ sú tam ľudia, tak aj softvér žije, keď sa oň niekto stará. Existujú aj softvérové mestá duchov. Nič netušiaci okoloidúci vývojár do nich vlezie, pretože videl ceduľu: “Navštívte naše Sedmikráskovo, mesto kde zabudnete na pomalé web services.” Nadšený prísľubom lepších zajtrajškov vlezie do mesta. Scéna ako z westernu. Prázdne bloky modulov sa týčia okolo cesty. Napravo stojí rozpadnutý a hrdzavý message bus, ktorý už určite nikam nepôjde. Ľadový vietor si kotúľa po ceste kus balíka so slamou z XMLouvníku.

Vývojár nesmelo zavolá: “Hello world!” a najbližší blok modulov sa rozsype a zrúti sa strašným zadunením stack tracu. Strhne so sebou aj kus starého koloniálu s vývesným štítom: “Vedma G11 (TM), viem všetko aj o vašich skrytých dátach.”

Takto nejako by vyzeralo veľa softvérových produktov.

Dávnejšie som písal o jednej vizualizačnej metóde pomocou CodeCity. Zaujímalo by ma, či náhodou niekto nevie o nejakej ďalšej metóde. Myslím si, že keby bolo možné lepšie zviditeľniť softvér do obrazov reálneho sveta, tak by sa ľahšie odhadovala pracnosť a nebezpečnosť zmien.

Jún 22, 2010

Ako zastaviť Google App Engine vo Windows na príkazovom riadku?

Testovací Google App engine server je možné naštartovať pomocou:

dev_appserver adresár

Ako ho ale zastaviť?

CTRL+C nefunguje, aplikácia zostane bežať.

Je potrebné použiť kombináciu CTRL+Break (Pause).