Vývoj softvéru na NEzelenej l ú ke

1. Vývoj softvérunaNEzelenej lúke JozefMatula jozef.matula@iblsoft.com

2. Predvianočná rozprávka o tom • S čím sme sa popasovali pri vývoji softvéru v našej firme. • Ako sme sa vrátili k „nízkym“ formám programovania vo vyšších programovacích jazykoch. • A trochu o „bohatých sieťových aplikáciách“.

3. Všetko je jednoduché ak začíname... VÝVOJ na zelenej lúke

4. SW projekty na zelenej lúke • Projekt sa začne - vyberie sa riešenie. • Riešenie sa implementuje. • Projekt sa odovzdá a akceptuje. • Prémie a projektové ocenenia! • Kto zažil „Waterfall“ vývojový process, mal životné šťastie...

5. Vývoj na NEzelenej lúke • Vývoj projektu trvá roky. • Prirodzene dochádza k poznaniu, že okolnosti sa zmenili: • fundamentálne nové požiadavky, • na niečo sa nemyslelo, • pôvodná implementácia už nemá požadovaný výkon, • zmenili sa technologické štandardy! • V podstate hovoríme o „krabicovom softvéri“ resp. COTS (commercial off-the shelf), ktorý so sebou vždy nesie isté „historické dedičstvo“.

6. Softvérové dedičstvo u nás • Projekt 11 rokov, 2 MLOC Prvý zdrojový súbor v XSLT Prvý kódv C 32000 riadkov fyziky vo Fotran-e 1970 2009 1992 1998 2000 2006 Najstarší zdrojový súbor vo Fortrane Prvý zdrojový súbor Flex/Action Script Prvý zdrojový súbor v C++ Prvý zdrojový súbor v Python-e

7. Softvérový vývoj u nás • Od bitových formátov až po Web služby Web služby XML / XSLT GIS formáty 3D vizualizácie Paralelné výpočty Rastrové výstupy Automatické spracovanie na pozadí Vizualizácie v reálnom čase Transformácie Algoritmy Rasterizácia Interaktívne používateľské nástroje (Qt) Spracovanie vektorových dát Meteorologické formáty Správa množstva heterogénnych dát Bitovo orientované formáty Dekódovanie formátov

8. Čo sme vždy chceli • Nech je kód efektívny - algoritmicky - kde to má zmysel - a vždy technicky. • Nech je kód platformovo nezávislý (32bit vs. 64bit, Big vs. Little Endian, zarovnanie dát) • Využiť celý potenciál jazyka: • C++ - šablóny, parciálne špecializácie, výnimky, • Python - dynamické objekty, funkcionálne prvky (lambda funkcie). • Skĺbiť toto všetko aby vznikol elegantný kód i dizajn. • Myslieť vždy dopredu a teda netvoriť softvér len na jeho prvotný účel.

9. Všetko má svoje za a proti a sú... VECI KTORé SA NEHOVORIA

10. Problémy, s ktorými sme sa stretli • Version control systém nezaručuje, že sa dá projekt skompilovať (rôzne kompilátory, rôzne prostredia). • Podpora rôznych cieľových platforiem/OS - je zábava pokiaľ ich je menej ako 2  • Čím viac zdrojových súborov má projekt, tým viac: • čo by čakal každý: • Rastie čas kompilácie • čo by nečakal úplne každý: • Zväčšuje sa pomer času linkovania. • Vzniká výrazný rozdiel medzi rôznymi kompilátormi. • Viac a viac sa naráža na to, že sa celý projekt nedá spustiť len tak cez „F5“ alebo „make && ./run.sh”

11. Priebežná integrácia (Continous integration) • V podstate je to nekonečný cyklus zložený z: • kompilácie, • (ideálne) automatických testov, • (ideálne) rôznych analýz kódu. • Buzzword - „Integrácia“: • Nočné kompilácie • Kompilácie vyvolané zmenou kódu. • Doby kompilácie ovplyvňujú značne tento cyklus. • Existuje množstvo projektov, ktoré túto problematiku dnes riešia, ale každý z nich ma nejaké muchy.

12. Priebežná integrácia vo svete C++ • Kameňom úrazu je podpora rôznych cieľových platforiem: • znásobuje celkovú časovú náročnosť - krát počet podporovaných platforiem, • vyžaduje mať rôzne kompilátory pre rôzny platformy. • Prístupy: • mať osobitný počítač pre každú platformu, • použiť tzv. cross-kompilátory. • Vedľajší dôsledok: • ak chceme podporovať rôzne platformy, ako potom spúšťať testy? Continous deployment...

13. Platformová nezávislosť • Existujú len teoreticky platformovo nezávislé jazyky. • Keď zoberieme Javu ako asi najlepšieho kandidáta, tento kód: class HelloWorldApp {public static void main(String[] args) {System.out.println("Hello World!");}}na mobilnom telefóne nebude fungovať tak ako má. • Platformová nezávislosť závisí na knižniciach. • Vždy existuje problém s Endianmi u externých dát.

14. Cross-kompilácia • Umožňuje kompilovať kód pre „takmer“ ľubovoľnú platformu (CPU) na ľubovoľnej dostupnej platforme (hlavne vďaka GCC, čiastočne aj v MS Visual C++). Príklad: na i686, LinuxPC => kód pre SPARC64, Solaris • Netreba však zabudnúť: • kompiluje sa nielen pre cieľové CPU ale aj konkrétnu distribúciu a verziu OS! • kompilovaný kód sa nedá „lokálne“ spustiť - v praxi množstvo knižníc tento koncept priamo nepodporuje. • Dá sa kompilovať aj pre nedostupné platformy!

15. Ako na to alebo... Čo s tým teda robíME

16. Návrat ku skriptom • Skriptovanie sa považuje často za menejcenné programovanie. • Pôvodne Unix-ová organizácia kódu nás priviedla ku 100-kám dynamickým knižníc + 10 rozsiahlych aplikácií a 10-kam pomocných programov. • Pritom vždy existovali nejaké skripty (Bash, Perl, AWK) a preto sme chceli zjednotiť používaný jazyk: • Inštalačné skripty, upgrade procedúry, • Drobné pomocné nastroje.

17. Skriptovacie jazyky - všeobecne • Módne versus moderné. • Prepojenia na existujúce API (binding) je riešené dynamickými knižnicami, ktoré sa zavádzajú do pamäti v prípade potreby. • Prenášajú kompiláciu a linkovanie do času spustenia aplikácie avšak vďaka jednoduchému rozhraniu je tento časť veľmi malý. • V praxi umožňujú: • Prototypovanie a rapídny vývoj • Vytvorenie rozšírujúcich modulov používateľmi • Unit testovanie bez kompilácie

18. Skriptovacie jazyky - Ale pozor! • Výkon kódu môže byť rádovo 100 krát horší (napr. Python), preto treba dômyselne voliť, kde bude hranica medzi skriptom a skutočným kódom. • Vytvorenie rozhrania (binding) nie je triviálne, tento kód sa často generuje a pôvodné rozhranie sa takmer zduplikuje. • Zmeny v dizajne kódu môžu mať nečakané dôsledky. • ... a preto „Každý riadok kódu“ musí byť otestovaný (obzvlášť v jazykoch s dynamickým typovým systémom). • ... a preto v rozsiahlejších aplikáciách narastá problém s ich udržiavateľnosťou.

19. Prečo práve Python • Nebolo nám všetko jedno (JavaScript, Ruby, Python, Perl, Lua, vlastný jazyk!), nakoniec pragmatická voľba padla na Python.

20. Prepojenie naC++ cez Boost Python PythonModul hellomod >>> import hellomod >>> planet = hello.World() >>> planet.set('Hello World!') >>> planet.greet() 'Hello World!'

21. Prepojenie naC++ cez SIP • Binding na knižnicu Qt a KDE je vytvorený cez SIP SIP PythonModul C++

22. Čo nám Python priniesol a prináša • Počas vývoja: • tvorbu jednoduchých aplikácii bez potreby linkovania. • vytváranie regresných unit-testov bez potreby ich kompilácie a linkovania. • Počas inštalácie a po inštalácii: • možnosť prispôsobenia aplikácie u zákazníka bez potreby meniť „skutočný“ kód, • možnosť pre zákazníka vyvinúť si vlastné aplikácie s použitím dostupnej funkcionality - výhoda voči konkurencii  . • Spomalenie kompilácie kvôli Python modulom.

23. A jedného dňa sa nás spýtali zákazníci ... A nedalo by sa to všetko spraviť cez weB?

24. ...a my sme zosmutneli... • Všetko sa dá spraviť! • Avšak máme aplikáciu, ktorá: • Je rozsiahla a náročná na 2D grafiku • Je výrazne interaktívna (okamžitá odozva) • Interaktívny “Web 2.0” vytyčuje 2 implemetačné cesty: • W3C - JavaScript/AJAX - interaktívny obsah • RIA - Adobe Flash&Flex, MS Silverlight, JavaFX- ešte viac interaktívny obsah.

25. Čo je Java Script  a GWT • (ďalej JS) De-facto jediný skriptovací jazyk pre dynamický HTML (počuli ste niekedy o VB Scripte? ) • Nočná mora každého Web programátora. • GWT = Google Web Toolkit je dôkaz, že pri použití JS pre rozsiahlejšiu aplikáciu sa nemusíte zblázniť: • Píšete objektový kód v Java-e • GWT podľa dostupnosti Java-y v prehliadači buď spustí Java applet „host-mode“ alebo preloží všetko do JS podporované službami AJAX. • Brilantné príklady využitia: • Google Mail, Google Wave

26. Adobe Flex • Flex je knižnica pre tvorbu používateľského rozhrania (dialógy, tlačítka) pre Flash, pričom štýlovanie je možné cez CSS. • Programovací jazyk je Action Script 3.0 (kvázi Java Script mixovaný s XML!), tento sa prekladá do pseudokódu Flash VM. • Flex je orientovaný na spracovanie dát (hlavne XML) z web služieb. • Tam kde zlyhávali Java Applet-y vyhráva Flex. • Adobe Air je odvodená technológia pre tvorbu skutočných aplikácií (bežiacich mimo prehliadača)

27. MS Silverlight a Java FX • Snaha firiem Microsoft a Java dobehnúť Adobe  • „Základom“ všetkého sú komponenty, ktoré sa animovane presúvajú a zväčšujú... • Každý z nich vyžaduje špeciálne rozšírenie prehliadača. • Výhodou je však možnosť písania kódu v „známom“ jazyku (C#, Java) • Vďaka aplikáciám pre šírenie videa cez Internet ako napr. YouTube, má Adobe jednoznačnú prevahu. • Pozor, rýchly vývoj v tejto oblasti spôsobuje, že nik nevie, ktorá technológia tu bude o 3 roky.

28. JavaScript & GWT verzus RIA* • Zvoľte si JavaScript/AJAX/GWT keď: • máte možnosť meniť/tvoriť web služby • aby Vaša aplikácie bežala „úplne“ všade, ale pozor s čistým JS to nie je také ľahké. • Zvoľte si RIA keď: • chcete vizuálne vyvíjať aplikáciu s „pekným“ výsledkom, • chcete ľahko krokovať Váš kód, • chcete extenzívne používať grafiku (efekty,animácie).

29. Prečo sme si vybrali Flex? • Ľahký vývoj - kvalitné IDE prostredie - komerčné, no ponúka debugger a časový i pamäťový profiler. • Bezproblémový beh na rôznych prehliadačoch (Linux, Windows). A tak sme aj my opäť na zelenej lúke.

30. https://ogcie.iblsoft.com/FlexiWeather/demo/

31. Ďakujem za pozornosť!Šťastné a veselé Vianoce!Otázky?