1. Vývoj softvéru na NEzelenej lúke
Jozef Matula

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ód v C
32000 riadkov fyziky vo Fotran-e
1970
1992
1998
2000
2006
2009
Najstarší zdrojový súbor vo Fortrane
Prvý zdrojový súbor v C++
Prvý zdrojový súbor v Python-e
Prvý zdrojový súbor Flex/Action Script

7. Transformácie Algoritmy Softvérový vývoj u nás
Od bitových formátov až po Web služby
Web služby
XML / XSLT
3D vizualizácie
GIS formáty
Paralelné výpočty
Rastrové výstupy
Automatické spracovanie na pozadí
Vizualizácie v reálnom čase
Algoritmy
Transformácie
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. VECI KTORé SA NEHOVORIA
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, Linux PC => 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. Za
Proti
Možnosť komfortného naviazania na C++ vrátane podpory pre OOP
Štandarná knižnica je len tenká vrstva nad C knižnicami, naviac bez jednotného dizajnu.
Prepojenie na Qt UI knižnicu
Syntaktická nečistota spôsobená vývojom jazyka a posunom v paradigmách (mix procedurálnych, objektových a funkcionálnych aspektov)
Veľká používateľská komunita a rozsiahla základná knižnica

20. Prepojenie na C++ cez Boost Python
struct World {
void set(std::string msg)
{ this->msg = msg; }
std::string greet()
{ return msg; }
std::string msg; };
#include <boost/python.hpp>
using namespace boost::python;
BOOST_PYTHON_MODULE(hellomod)
class_<World>("World")
.def("set", &World::set)
.def("greet", &World::greet) ; }
Python Modul
hellomod
>>> import hellomod
>>> planet = hello.World()
>>> planet.set('Hello World!')
>>> planet.greet()
'Hello World!'

21. Prepojenie na C++ cez SIP
Binding na knižnicu Qt a KDE je vytvorený cez SIP
struct World {
void set(std::string msg)
{ this->msg = msg; }
std::string greet()
{ return msg; }
std::string msg; };
%Module hellomod 0
class World
%TypeHeaderCode
#include <world.h>
%End
public:
World();
void set(std::string msg);
std::string greet();
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 nedalo by sa to všetko spraviť cez weB?
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?