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.
Č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ľ 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.
Dobrá správa pre priaznivcov agilných metodík. 22. 6. o 18:30 sa bude konať v Brne stretnutie Agília. Na stretnutí sa diskutuje o úspechoch a úskaliach implementácie metodík ako je SCRUM.
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úť.
Podstatnou črtou MDD prístupu je presun zamerania z písania kódu na tvorbu modelov. Všeobecným problémom pri napájaní klientských technológii (napríklad je Flex) na serverové technológie, je veľké množstvo duplicitnej práce, ktoré je nutné spraviť. Typicky je nutné reimplementovať na strane klienta dátové objekty a naimplementovať kvantá prístupov k operáciam. Pri rozsiahlom API je toto veľmi náročné. Naviac táto duplicita silne spomaľuje a komplikuje zmeny v API. Vývojár musí často preniesť zmeny ručne zo servera na klienta.
Model driven development sa zameriava práve na zníženie pracnosti písania kódu. Pokiaľ máme k dispozícii model, je možné z neho vygenerovať veľkú časť kódu. Časť vývojárov prestala čítať tento článok pri slovnom spojení “vygenerovať kód”. A dobre im tak.
Teraz príde jeden trik a z cteného čitateľa, ktorý vydržal slovné spojenie “vygenerovať kód”, spravím cteného diváka.
Vážený ctený divák, nájdi si hodinku času a pozri si nasledujúce video. Nenechaj sa odradiť možno nudnejším, ale veľmi podstatným začiatkom. Pozeraj. Skutočná akcia a mágia začne keď Christopher Coenraets zapne Flash Builder a napojí ho na LiveCycle.
Upozornenie pre vývojárov a projektových manažérov: netrhajte si vlasy, stačí zastaviť video, vydýchať sa, prípadne si zabehnuť nejaký ten kilometer.
Video záznam je z konferencie Adobe Max 2009. Za link video ďakujem Tomovi Krchovi.
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