Nájdete tu rôzne dokumenty pre technológieodvýmyslusveta. 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.
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.
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é.
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.
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.
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úť.
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.
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 😉
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.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.