Pátek 23.9.2011

• Slides: http://www.slideshare.net/michal.taborsky/arcitektura-skalovatelnych-aplikaci

• architecture, scalability, systems
• Myšlenka dne: “Dřív byly krásné stránky, ale nebyl kdo by je aktualizoval, teď je to takhle a je pokoj.”
• V mnoha případech pro běžnou zátěž stačí jednoduchá architektura s zapojením cache serveru (squid, nginx, varnish ..)
• monitoring
• Statický obsah by se měl servírovat pokud možno vždy co nejjednodušeji, přímo skrz Apache, nebo jinak primitivní webserver.
• Nejjednodušší způsob, jak něco udělat, je často nic nedělat :)
• Jednorázová aktualizace cache je hloupý nápad, stejně jako měnit data jednou za určitý interval, který nekoresponduje s četností změny dat. Podnět k aktualizaci by měl přijít v době změn dat.
• Data na stránce mohou být rozdělena na části, které se mohou měnit s různou periodou.
• Je třeba se zabývat nejen tím, jak data budou zobrazena ale také jak se bude měnit.
• Říkal: spoustu věcí je možné uložit do cookies - Potenciální dotaz: není tady potenciální problém s přenosem velkého množství dat? (HTML5 offline storage?)
• Relační databáze mají stále svůj smysl. MySQL NENÍ moderní relační databáze :P
• Asynchronní zpracování potřebuje frontu. RabbitMQ , ZeroMQ
• Velké množství věcí je často nesprávně vykonáváno okamžitě, přestože to ničemu nepomáhá.
• Př: Odeslání objednávky vygeneruje jen ID, ale po zpracování fronty dochází k velkému množství akcí.

• Aplikaci stavět modulárně,
• zapouzdřovat,
• monitorovat vše,
•  automatizovat,
• statický obsah řešit jednoduše,
• chytře pracovat s cache,
• používat moderní databáze a využívat
• asynchronní řízení

• Dle mého povedená přednáška. Hlavně proto, že řekl spoustu věcí, které nejsou složité, ale jsou pravdivé a hodně rozšířené. Přitom ale není tak těžké je začít využívat.

zápis: @winsik a @radeksimko

• php, ruby, cfengine, chef, puppet, capistrano, deployment, configuration management
• Kolega vedle nasazuje i několik hodin.
• Stovky hodin se stráví deploymentem a firmě to nic nepřinese.
• Pokud je to možné, nechat deployment na jiných.
• heroku - server, který umí přes git push automaticky nasadit aplikaci a provést potřebné aplikace. velmi pokročilý cloud

• Většina facebookových aplikací v ruby běží na heroku. Je možné platit pouze za využívanou kapacitu, ze začátku je to často zcela zdarma.
• PHP - phpfog, pagodabox, relbit - běhové prostředí pro php. většina bohužel umožní jen pracovat se zdrojáky, neumí však pracovat s databází.
• Os specific nasazování - používají na centosu rpm balíčky pro nasazení php - měl přednášku na barcampu, jak to dělat. možnost také používat pear s vlastními kanály…
• Capistrano - ruby framework pro deployment
• při nasazování vytvoří obraz webu z repozitáře a poté změní symlink webu - nasazaní tak proběhne na jednou.
• Používají jenkins, a v něm jsou mimo scriptů pro build, scripty pro nasazení. vytváří rpm, a pak scriptem přihlásí přes ssh na stroj a přes url se nainstaluje.
• Pro automatizaci používají CFengine. Puppet - spíše pro operativu než pro programátory.
• Necomata cluster - 30 000 jader, pro nasazování byl používán chef.

• existují kvalitní nástroje - není třeba psát nic vlastního
• každý oprávněný uživatel má informaci o verzi aplikace a může nasadit kdykoli potřebuje
• automatizovat - ruční nasazení selhává
• uspořené náklady.
• Vyhýbají se modulárnímu systému, vytvářejí celistvou verzi aplikace, kterou nasadí a jen konfigurují služby.

• zápis: @winsik a ...

• automated deployment, phing, dbdeploy, subversion, php

• Klasický problém v php - ruční nasazování. Deployment nedává přidanou hodnotu a nikoho to nebaví.
• Častý případ - zapomenutí commitu do repozitáře. FTP se často odporoučí a je třeba začít znovu, nutno upravovat ručně databázi, případně n opakování :) Poté by se mělo alespoň informovat tým...
• Jedná se o zdlouhavý proces.

• V ideálním případě by mohla jít úprava na integrační server a poté automaticky na ostrý.
• DBDeploy pro migraci databáze používají přímo SQL definici databáze/tabulek, kam píšou schémata “CREATE TABLE …” Rozdílové scripty (ALTER TABLE ***) se vytvářejí automaticky
• Při commitu se na integračním serveru aktualizují zdrojové soubory i databáze.  Poté je možno jednoduše deploynout na ostrý.
• Při rollbacku neřeší databázi.
• Přenášet by se měly jen změněné soubory, migrace databáze přes různé verze, linkování externích knihoven, automatické odstranění cache, informování kompetentních osob.
• Login informace nahrazují až při deploymentu (prostřednictvím proměnných ##promenna## v config scriptech). - Eliminuje lidský faktor a nutnost znalosti hesel.
• Po buildu se můžou poslat email notifikace na všechna potřebná místa (ostatní vývojáři, zbytek firmy, zákazník). Zákazníkovi by asi neměl jít stejný mail, jako firmě uvnitř.

Potřebné nástroje:

• verzovací systém
• phing - automatizace kroků, podobný ant, psaný v php, má připravené tasky pro php aplikace, minimizace js souborů, kombinace css
• spouštění pomocí deployment aplikace

• Root apache vede na current, který je symlinkem na některý z releasů uložených v adresáři releases.

Jak začít:

1. nainstalovat phing
2. první build script
3. přidat úkoly pro deploy target
4. zautomatizovat spuštění phing deployem

• Php fog - dobrá věc pro provoz aplikací, deployment ale umí jen aktualizovat soubory,

Souhrn

• i v případě php je možno automatizovat
• existují nástroje které je možno využít.

• Mají adresář se všemi verzemi frameworků a pak je jen symlinkují z různých projektů.

• zápis: @winsik a ...

• coffeescript,javascript,tdd,unit testing

• coffeescript

• méně upovídaný než JS
• důležité mezery (jako Python)
• místo function se píše jen šipka “->”
• třídy, nejen prototypování
• automaticky doplňuje returny

Když má aplikace tři roky, tak dokumentace je stará 5 let :)

• proč testovat?

• test je spustitelná dokumentace

• zjistíte, že je zastaralá, když testy začnou failovat

• nastavíte měřítka kvality

• jinak to vývojář někdy otestuje pečlivě, někdy ne

• Qunit - testovací framework jQuery - na client side velmi používaný, velké množství dokumentace.
• Qunit spouští testy postupně, mohou tak běžet paralelně přes sebe - metoda Test. asyncTest - čeká na další test, na zavolání start().
• Nejjednodušší jak mít plně pokrytý objekt testy je psát jej pomocí TDD.
• Pouštět testy před psaním kódu je důležité hlavně v rámci velkých systémů, aby se nenapsal zbytečný test. Jsou také vidět chybové hlášky. Důvěra v test, který umí failnout.

Proces TDD:

1. Napíšu testy, aby selhaly.
2. Napíšu kod aby testy prošly.

Po úspěchu testů následuje commit do repozitáře

3. poté můžeme refaktorovat.

• Když píšeme nejprve testy, navrhujeme metody tak, aby se dobře testovaly/používaly. Pokud píšeme nejprve kód, píšeme ho tak, aby se dobře programoval.

• http://ukazka.knesl.com

Testovatelný kód

• výjimky místo ukončení kódu
• Dependency injection

• Doporučení Knížka: čistý kód, dealing with legacy code (Údržba kódu převzatých programů)
• testy qunit je možné pouštět na integračním serveru

• zápis: @winsik a @milanlempera a ...

• js, ttd, data binding

• http://vojtajina.github.com/ng-slides/2011-09-23-web-expo/
• AngularJs je open source, zdrojáky na GitHub.
• Existuje tutorial, kde je dobře vidět jak použití AngularJs, tak psaní testů v JS.
• AngularJs není náhrada jQuery, je navržen tak, aby s ním spolupracoval.
• Funguje na principu two-way databinding.
• nevýhody one-Way data bindingu:

• kvůli jednomu údaji je třeba aktualizovat celou šablonu

• AngularJs zajišťuje propojení view a modelu, což umožňuje psát méně kódu, ale hlavně umožní oddělení logiky od prezentace.

Testování

• všichni ví, že testování je fajn, ale většinou moc nevíme, jak na to.

K testování jsou potřeba 2 věci:

1. Environment

• unit testy
• … testy (testy - klikni na tlačítko a zkontroluj výsledek)

• vytvořit prostředí není jednoduché, ale pokud ho máme, psaní testů je hračka
• v AngularJs je testovací prostředí připraveno

2. Testable code

• Podpora v prohlížečích:

• donedávna podporován IE6, nyní už se na netestuje.

@milanlempera a ...

• nokia, maps, api, canvas, implementation, howto, javascript, html5, fast, reliable, mobile
• mají asi 60 mil

• kartografie, mapy
• Když lidi hledají na mapách, mají tendenci být mnohem kritičtější.
• Existují ulice, které se jmenují Obec :)
• Jediné mapy, které aktualizují url, které je možné jednoduše zkopírovat.
• Mapové portály poskytují velcí softwarový giganti. Neprovozují je ale kartografické firmy, přestože se zabývají velkým množstvý mapových nuancí. Není však možné použít jejich know how v softwarovém světě
• Primární motivace provozu mapy.cz není zisk.
• Mapy.cz se věnuje cca 10 lidí.
• 250GB gigabitů, 108 000 000 ks dlaždic s mapovými podklady. Ve špičce dá 1000 dlaždic za vteřinu.
• search mixer - komunikace s různými součástmi, první ale osloví region server - snaha dekomponovat dotaz na subdotazy, které dodají informace různého druhu, které dají co nejlepší výsledek vzhledem ke kontextu chápaného uživatelem.
• použity jsou pouze opensourcové technologie.
• PostGis, součást db postgres - práce s geometriema.
• mapnik - renderování map z vektorové databáze
• Příklon k vektorovým mapám - uživatelé chtějí vědět co je v mapě co. V současné době nejsou mapové podklady ještě složené jako databáze objektů, která by logicky dávala smysl jako celek.

• Co na to číňan? Zatím nevíme jak to dělají, ale my na to přijdeme a pak se těšte :) http://www.edushi.com/

útržkové zápisky: @winsik

Sobota 24.9.2011

• https://my.appcelerator.com

• Flex - technologie kompilovaná do flash, actionscript vychází z javascriptu, obohacen o objektový přístup. Napůl statický, napůl dynamický. Stylování flexu je možné pomocí css.

• Pomocí flex možno vytvořit také mobilní aplikaci, skompilováním pro konkrétní platformu případně zařízení. Možno nastavit na škálování DPI, z důvodu rozdílné jemnosti displaye.
• Flash builder - nástroj postavený na eclipse. Možno využívat interní debuger. Emulace zařízení. Flash je silně typový jazyk, flex builder umí doplňování, prolinkování souborů. Při importu dat je možné opět vytvoořit z dat objekty se silně typovanými atributy.
• Má funkční gui builder protože flex se renderuje všude jednotně.
• Je možné spouštět přímo na fyzickém zařízení. Možno debugovat přímo v zařízení.
• pomocí css mediaqueries je možné řídit, co se na jakém zařízení zobrazí.
• Flex dělá množství věcí za nás, je možné programovat proti API platformy air v případě potřeby vyššího výkonu.
• Nová verze flex 4.6 bude mít podporu tabletů. Bude možné přibalit Air, nebude pro uživatele nutné ho instalovat. Nativní rozšíření, přístup k nativním api.
• Výkon by se měl blížit nativní platformě. Omezení na od Adobe podporované platformy.
• Aplikace se dá přímo deploynout do applestore a jiných

• zápis: @winsik