Moderní vývoj aplikací

Publikováno 2.5.2013 | Autor: Ronnie

Následující článek popisuje způsob vývoje webových aplikací, který už nějakou dobu praktikuji a který mi připadá jako zdaleka nejlepší z těch, které jsem měl možnost vyzkoušet. Text je teoretickým shrnutím toho, co lze nalézt v mých seriálech na Zdrojáku. Jde zde proto, abych na něj mohl odkazovat ty, kteří seriály na Zdrojáku nečetli a číst kvůli jeho rozsahu ani nechtějí.

První faktor úspěchu: možnost rychlých a bezbolestných změn

Dle různých statistik končí až 80% (některé studie uvádějí i více než 90%) projektů neúspěchem. Za neúspěch se považuje nejčastěji nedodržení termínu, překročení ceny či chybějící funkčnost. Už se ví, že staré metodiky postaveném na vodopádovém modelu vůbec nefungují. Také je všeobecně známo, že je nezbytně nutné zahrnout budoucí uživatele do testování během vývoje. Je potřeba od nich získávat zpětnou vazbu a s ní dále pracovat.

Dříve jsem si myslel, že toho dosáhnu striktním oddělením požadavků (otázka CO to má umět) od návrhu (otázka JAK daný požadavek splnit). To funguje, ale velký problém je právě zjišťování a přesnost oněch požadavků. Existují samozřejmě různé způsoby, jak z klientů dostat, co vlastně vůbec potřebují. Problém je však v tom, že to často ani oni sami nevědí, a tak když podrobně zmapuji jednu část a uděláme ji, o měsíc později můžu zjistit, že vlastně danou věc potřebují udělat úplně jinak, což si uvědomí až tehdy, když poprvé nějaký výstup uvidí.

Tohle se dá různými způsoby minimalizovat. Třeba prototypováním. Zjistím, co vlastně klient chce a v nějakém šikovném programu podle toho navrhnu obrazovky UI, které pak konzultuji a měním. Prototypování tímto způsobem ale nemám rád z několika důvodů. Jednak že výsledná aplikace stejně pak často vypadá úplně jinak, protože mnoho požadavků přijde až s tím, jak si klient s appkou začne hrát, ale třeba také proto, že je to práce, která se poté zahodí a špatně se účtuje. A hlavně prototypování množství požadavků na změnu sice minimalizuje, ale definitivně nevyloučí.

Zkrátka neexistuje způsob, jak z klienta dostat všechny požadavky hned na začátku a dosáhnout toho, aby již žádné požadavky nepřichzely. To je útopie. Proto je pro mě klíčové dosáhnout minimálních nákladů na změny. Potřebuji, abych mohl aplikaci ukázat klientovi a když bude požadovat změnu, dokážu ji zahrnout třeba s 1/20 nákladů při klasickém způsobu vývoje. Místo mnoha hodin strávených nad návrhem raději něco vytvořím a okamžitě získám zpětnou vazbu (třeba i v denních iteracích) od těch, co to pak budou používat, zda to takto odpovídá jejich představám. Když chtějí změnu, hned ji provedu a opět se celé kolečko opakuje, dokud nejsou spokojeni všichni. Podstatné ale je, abych ukazoval reálnou aplikaci a ne pouze prototyp. Tím dosáhnu toho, že klient skutečně dostane to, s čím je 100% spokojen.

Podle mých zkušeností nejvíce času stojí změny, které jsou vynuceny úpravami databáze, nejhůře pak celé její struktury. Jak se tomu vyhnout je popsáno dále.

Druhý faktor úspěchu: respektování priority požadavků

Nerespektování priority požadavků je podle mě největší problém u drtivé většiny aplikací. Není-li stanovena priorita požadavků, programátoři budou dělat to, co je baví nejvíce (nejsem výjimka). Běžně se aplikace dělá tak, že se nejprve programuje administrace číselníků (jednoduché tabulky) a až na konci se dělá to, co je z těch číselníků sestaveno. Třeba v e-shopu nejspíš může někdo začít sekcí administrace druhů dopravy a platby, bude pokračovat parametry, definicí záručních dob atd., jako poslední nejspíš udělá sekci objednávek a pak začne dělat až uživatelskou část, kde jako poslední udělá objednávkový proces, protože ten spojuje všechno ostatní dohromady.

Tohle je ale úplně špatně. To nejdůležitější z celého e-shopu se tak dělá až úplně na konci. Tedy v době, kdy je často po deadline a je potřeba projekt bleskově dokončit, což zrovna kvalitě nepřidá. A ještě horší je, je-li stanoven pevný termín, kdy projekt musí být hotový (třeba je připravena reklamní kampaň na nějaké datum, stává se to). Když e-shop nemá objednávkový proces, je úplně k ničemu. Když však stihnu vše, ale některé části ještě v administraci nelze spravovat, dokážu alespoň zajistit brigádníky, kteří do do databáze data nasypou přes nějaký program. A až po spuštění projektu postupně dodělám v administraci ty části, které ještě nejsou. E-shop ale bude fungovat a vydělávat peníze.

Potřebuji tedy dělat ty nejdůležitější části co nejdříve a ty méně důležité až později. Způsob vývoje, který si vyberu, musí tyto dva požadavky respektovat. Jak tedy na to?

Single-page aplikace a AngularJS

Nejraději mám single-page aplikace (SPA), tedy většina aplikace je přesunuta do prohlížeče. Nejznámější (a možná i první) implementace tohoto vzoru je Gmail. Z velkého množství klientských MV* frameworků mi vyhovuje nejvíce AngularJS, který umožňuje drasticky snížit množství kódu, které je potřeba napsat. Díky parádní podpoře dependency injection umožňuje vytvářet znovupoužitelné, samostatné a výborně testovatelné komponenty.

REST API

Tento typ aplikací obsahují tedy logiku na straně klienta a se serverem komunikují pomocí REST API. Existují dohodnuté best practice, jak mají URL a GET/POST/PUT/DELETE požadavky vypadat. Pokud chci tedy třeba získat detail objednávky s ID 123, bude na adrese GET /orders/123, když budu chtít objednávku smazat, zavolám DELETE /orders/123 atd.

Všechny požadavky jdou přes jeden centrální bod. Např. chci pracovat se seznamem objednávek. Na jednom místě chci všechny objednávky, tak zavolám URL GET /orders. Na jiném místě chci prvních 50 objednávek uživatelů s cenou objednávky vyšší než 1000 Kč, tak zavolám URL GET /orders?filter=priceHigherThan:1000&limit=50. Parametr priceHigherThan není v databázi, je to nějaké pravidlo, které mám univerzálně definováno a když pro něj přijde požadavek, tak ho inicializuji (po automatickém ověření práv). Správu jednoho zdroje mám pak na jednom místě pro mnoho různých částí (tedy nikoliv x metod, které vybírají z databáze pokaždé trochu jiná data).

Apiary

Velký rozdíl oproti klasickému způsobu tvorby aplikací je zapojení Apiary. Zde si nadefinuji, jak má REST API vypadat a uvedu nějaké příklady. Z toho získám jednak skvělou dokumentaci, ale také testovací data. Především však Apiary umí definici REST API vložit do souboru apiary.apib a ten pak synchronizovat s repozitářem na Githubu. Když tedy udělám novou úpravu v Apiary, mám aktuální pravidla na Githubu. Když pak chci poslat git push do repozitáře, Git mě upozorní, že došlo k změně v REST API. Stáhnu si pomocí git pull daný soubor k sobě, ten se přeloží do klasického JavaScriptu pomocí nástroje Grunt a pravidla pro URL se načtou při vývoji přímo do aplikace. Díky tomu pak AngularJS neposílá požadavky přímo na server, ale místo toho pracuje pouze s mock daty. Klíčové je, že aplikace se chová úplně normálně, jako kdyby komunikovala opravdu se serverem.

Nejprve UI, databáze až na konec

To mi přináší jednu úžasnou výhodu. Můžu vyvíjet celou aplikaci pouze s AngularJS bez toho, abych napsal jediný řádek kódu na serveru. Všechny změny dělám jen na straně klienta a v Apiary definují nová pravidla nebo upravuji ty stávající. To drasticky zvyšuje rychlost vývoje. Když klient řekne, že chce takové a takové parametry u produktu v e-shopu, tak je nadefinuji jen jako JSON response u Apiary a s těmito daty pak připravím celou klientskou část. Později zjistí, že vlastně ty parametry mají být jinak a ještě později třeba přijde na to, že vlastně vůbec parametry nepotřebuje. V tom případě změním nebo smažu definici z Apiary a upravím jejich vykreslování v detailu produktu a je to.

Díky tomu můžu začít těmi nejdůležitějšími částmi, třeba správou objednávek a objednávkovým procesem, protože nepracuji s databází, ale pravidla nadefinuji přímo v Apiary. Z toho pohledu je úplně jedno, kterou sekcí začnu, je to pro mě všude stejně jednoduché. U klasického způsobu, kdy nejprve navrhuji databázi je to jinak, tam se ten objekt bude skládat z dat z mnoha a mnoha tabulek, které musí obsahovat testovací data.

Celou aplikaci pak vývíjím v Twitter Bootstrapu (+ LESS) a dokážu v podstatě od druhého dne hned zapojit do uživatelského testování lidi, kteří ji pak budou používat. Funguje to skoro stejně rychle jako klasické prototypování. Ovšem s tím rozdílem, že zatímco prototyp se zahodí, tato aplikace je reálná a to také uživatele dostanou (jen s vylepšeným, unikátním designem). Udělám malou část a okamžitě chci zpětnou vazbu. Zobrazují se tato data správně? Je potřeba zobrazit ještě něco dalšího? Je to dostatečně intuitivní? Vše jde nesmírně rychle.

Jakmile celou aplikaci vyvinu s mock daty, s Apiary, v AngularJS a v Twitter Bootstrapu, mám již přesně specifikovánou strukturu dat, kterou opravdu potřebuji. Už vím, jak bude vypadat REST API. V tu chvíli pak předám požadavky na grafiku, protože už přesně vím, co a kde se má zobrazovat. Nestane se, že překrásný grafický návrh po implementaci vypadá příšerně. A začnu také dělat serverovou část, což je v podstatě jen překlopení HTTP požadavků na databázi. A vlastně až tady definuji strukturu databáze. A můžu se až tady rozhodnout, jakou databázi použiji, zda to zvládnu s NoSQL a nebo musím použít nějakou SQL databázi. To je přesně opačný způsob než ten, který mi třeba vnucovali na vysoké škole.

Node.js a TypeScript

Na straně serveru jednoznačně preferuji Node.js. Výhoda je třeba ve sdílení kódu mezi klientem a serverem (viz některé příklady v seriálu na Zdrojáku). Zásadní je ale výkon aplikace, což je u Node.js všeobecně známo (třeba příklad s LinkedIn). Minimální nároky na paměť a rychlost zpracování požadavku je pro single-page aplikaci důležitý faktor, protože nepoužiji-li nějakou fasádu, ze SPA budu posílat požadavky na server častěji (dotazuji se na různé zdroje). To je důvod, proč si myslím, že je pro tyto aplikace PHP zcela nevhodné, protože při každém požadavku budu muset neustále dokola načítat všechno znova, což stojí čas (a peníze). V případě Node.js je to pochopitelně jinak.

Protože v čistém JavaScriptu se neprogramuje zrovna jednoduše, používám rád různé jazyky, které se do JavaScriptu kompilují. Dříve jsem měl rád CoffeeScript, ale momentálně mi vyhovuje TypeScript. Kromě kontroly typů vypadá kód také velmi hezky a přehledně. Nicméně je hodně znát, že je to mladý projekt a třeba definice rozhraní v DefinitelyTyped jsou často chybové, i tak ale preferuji raději TypeScript nad CoffeeScriptem či jiným dialektem.

Další výhody

Výše uvedený způsob vývoje má řadu dalších výhod. Např. kešování v případě dotazování na jeden zdroj přes API je mnohem snazší než u klasické aplikace. Třeba onen e-shop, který se vytváří v rámci seriálu na Zdrojáku, bude při dotazech na API (z klientské části) dostávat kešované JSON soubory (budou-li k dispozici), což znamená, že požadavek nedojde ani k Node.js a do databáze už vůbec ne. Vlastně to bude pro drtivou většinu času statický HTML web.

Výborná je také týmová spolupráce, kdy programátor serverové části a klientské části komunikují pomocí Apiary. My máme někdy klienskou i serverovou část v samostatných repozitářích (na serveru se občas místo Node.js použije PHP se špičkovým frameworkem Symfony).

Nevýhody

Tento způsob vývoje se hodí především pro webové aplikace, pro jednoduché webové stránky typu firemní web vhodný není.

O něco složitější je indexace pro vyhledávače. Obvykle se to řeší tak, že v případě příchodu robota na web se pošle vyrenderovaný obsah stránky pomocí nástrojů typu PhantomJS. Single-page aplikace tedy pro vyhledávače přístupné jsou, ale je potřeba podniknout kroky navíc (existují NPM balíčky, které tohle řeší, takže implementace těžká není). Značná část aplikací ale má části, které indexovatelné být nemusí (nemají) a zde se programátor vůbec indexací zabývat nemusí. O klasických administracích, který má každý web, ani nemluvě. A kdyby to stále nevyhovovalo, je možné vytvořit pro vyhledávače pro důležitou část řešení, kdy se ještě na serveru dotazuji na API a výsledek pak pošlu jako kompletní HTML.

Další problém mohou představovat starší prohlížeče. Výše uvedený postup se obvykle praktikuje pro prohlížeče IE8+, podpora starších prohlížečů se nevyplatí.

Pro někoho může být také problém závislost na JavaScriptu. To podle mě ale již dávno problém není, JavaScriptové aplikace nepředstavují handicap a jsou stejně přístupné jako klasické weby.

A tak zbývají pouze uživatelé s úplně vypnutým JavaScriptem. To jsou ovšem uživatelé, kteří ho vypínají vědomě a budou mít problémy na mnoha dalších webech.

Často slyším názor, že aplikace, které nefungují bez JavaScriptu, jsou problematické. Pak následuje argument, že jestliže mám e-shop, tak budu raději, aby fungoval i pro ty, kteří nemají JavaScript, protože si zde pak mohou také nakoupit. S tím však nesouhlasím, protože zbylým 99% uživatelů nabídnu díky SPA mnohem vyšší komfort, rychlejší aplikaci, dosáhnu nižších nákladů na provoz i vývoj atd, což také povede k tomu, že si budou vybírat zboží u mě a nikoliv tam, kde budou na vykreslení stránky čekat několik vteřin.

Rubriky: AngularJS, JavaScript, Node.js | Napsat komentář

Rychlý úvod do TypeScriptu

Publikováno 12.4.2013 | Autor: Ronnie

TypeScript je nadstavba nad JavaScriptem. Přidává jednak vlastní doplňky (typy, rozhraní ap.), ale také umožňuje používat již nyní novinky z ECMAScriptu, které ještě dlouho nebude možné používat v rámci klasického JavaScriptu.

Kompilace

TypeScript píšete do souboru s koncovkou .ts. Následně pomocí Node.js balíčku typescript (instalace pomocí npm install -g typescript) přeložíte soubor v ts do klasického JavaScriptu:

tsc mujsoubor.ts

Soubory samozřejmě nebudete kompilovat ručně, ale bude to nejspíš za vás dělat buď IDE (podpora ve WebStorm či Sublime Text 2). nebo třeba nástroj grunt. V reálu tedy budete psát příkazy v TypeScriptu a o více se nestaráte.

Díky source map funguje výborně debugging, tj. když někde uděláte chybu, kompilátor vás upozorní, kde se nachází v daném souboru .ts a ne až v kompilovaném .js. To byl dříve problém u CoffeeScriptu, protože v případě chyby jste se dozvěděli číslo řádku až ve zkompilovaném js, takže bylo těžké hledat chybu v souboru s CoffeeScriptem. Tady vám to nehrozí, práce s TypeScriptem je pohodlná.

Třídy

Zápis vypadá stejně jako u většiny jiných jazyků.

Atributy i metody mohou mít určen modifikátor přístupu public nebo private. Public je výchozí a není potřeba ho psát. Protected TypeScript zatím nepodporuje, ale je v roadmap pro první verzi.

Metody se zapisují velmi jednoduše, prostě jen název + závorka (třeba oproti PHP, kde je pořád potřeba psát keyword function).

Konstruktor je v TypeScriptu pojmenován jako constructor.


class BankAccount {
  balance: number;
  constructor(initially: number) {
    this.balance = initially;
  }
  deposit(credit: number) {
    this.balance += credit;
    return this.balance;
  }
}

Dědičnost

TypeScript podporuje jednoduchou dědičnost. Potomek třídy se deklaruje pomocí keywordu extends. Z potomka se na rodiče odkazuje pomocí super.


class CheckingAccount extends BankAccount {
  constructor(balance: number) {
    super(balance);
  }
  writeCheck(debit: number) {
    this.balance -= debit;
  }
}

TypeScript podporuje statické atributy i metody přes klíčové slovo static. Hodnoty atributů je možné inicializovat už přímo při deklaraci atributu. Jestliže je uveden modifikátor přístupu rovnou u parametru v konstruktoru, vytvoří se z něj atribut.


class Point
{
  private abc: string;
  constructor(public x: number, public y: number) { }
  public distance(p: Point) {
    var dx = this.x - p.x;
    var dy = this.y - p.y;
    return Math.sqrt(dx * dx + dy * dy);
  }
  static origin = new Point(0, 0);
  static distance(p1: Point, p2: Point) {
    return p1.distance(p2);
  }
}

Accessory


class Person {
  private name: string;
  private surname: string;

  constructor(name, surname) {
    this.name = name;
    this.surname = surname;
  }		

  get fullname() {
    return this.name + ' ' + this.surname;
  }

  set fullname(fullname: string) {
    var split = fullname.split(' ');
    this.name = split[0];
    this.surname = split[1];
  }
}

var person = new Person('Jakub', 'Mrozek');
person.fullname //vypíše Jakub Mrozek
person.fullname = 'Jan Novák'; //nastaví name na Jan a surname na Novák.

Rozhraní


interface Mover {
  move(): void;
  getStatus(): { speed: number; };
}

interface Shaker {
  shake(): void;
  getStatus(): { frequency: number; };
}

interface MoverShaker extends Mover, Shaker {
  getStatus(): { speed: number; frequency: number; };
}

class Abc implements MoverShaker {
  //definice getStatus(), shake(), move()
}

Moduly


module A.B.C {
  import XYZ = X.Y.Z;
  export function ping(x: number) {
    if (x > 0) XYZ.pong(x – 1);
  }
}

//přístup přes A.B.C.ping(...)

Defaultní hodnoty parametrů


class Person {
  private name;
  constructor(name =’Jakub’) {
    this.name = name;
  }
}

Rest parametry


class Person {
  num: number;
  children(...boysAndGirls: string[]) {
    this.num = boysAndGirls.length;
  }
}

var person = new Person();
person.children('Jakub', 'Marketa', 'Maketa');
alert(person.num); //vypíše 3
Rubriky: Nezařazené | Napsat komentář

Pokračování seriál na Zdrojáku o Node.js/AngularJS/HTML5

Publikováno 25.3.2013 | Autor: Ronnie

Na konci září jsem pro Zdroják začal psát seriál o Node.js a na něj pak navazující seriál o tvorbě e-shopu v AngularJS/HTML5/Node.js/MongoDB. Pokud seriál sledujete, možná jste zaregistrovali, že poslední díl vyšel 1.3. a nyní nové díly nevycházejí. S výjimkou vánoční pauzy to bylo poprvé po 21 dílech. Proč?

Kdybyste si chtěli oba seriály vytisknout, potřebovali byste kolem 180 listů formátu A4. Když bychom to počítali na standardní A5 formát knih, připočetli nějaké stránky na obsah, úvod, do přílohy vložili všechny zdrojáky (hlavně první seriál byl téměř jen text), tak by z toho vznikla jedna docela tlustá kniha.

Každý díl mi zabral minimálně jeden celý den, některé i dva a více dní. Když jsem psal o nějakém modulu, musel jsem projít všechny ostatní z dané oblasti, abych měl jistotu, že to co píšu je správně. Pak samozřejmě přidat praktické příklady, vytvořit demoverze na Heroku, převést to do redakčního systému (psal jsem to v Google Docs), vymyslet perex, titulek, všechno naformátovat, nechat to někoho přečíst a případní připomínky zahrnout…a samozřejmě celý článek napsat.

Je to obrovské množství času, které tomu člověk musí obětovat a jakožto fulltime pracující člověk, student denního studia a aktuálně též tvůrce bakalářky ten den už zkrátka není možné najít. Seriál si dává krátkou pauzu přibližně do konce května, kdy mi končí semestr a kdy se zbavím bakalářky. Pak zase budu v psaní seriálu pokračovat, aktuálně plánuji ještě cca 8 dílů. Docela se na to těším, protože ten druhý seriál je pro mě mnohem zábavnější.

Za pár dní si dokonce budete moci vyzkoušet nejen demo verzi, ale normální e-shop, který je na tom ze Zdrojáku postaven. To znamená, že opravdu nejde jen o nějakou primitivní todo aplikaci, ale o shop, který bude reálně fungovat (mimochodem, zhruba za ⅓ čas oproti odhadu v prvním díle http://www.zdrojak.cz/clanky/uvodni-analyza-pro-moderni-e-shop/).

Seriál jsem začínal psát v době, kdy u nás byly jen dva články v češtině o Node.js a o Node.js nikdo nemluvil. Dnes je situace o hodně jiná. Když jsem nedávno hledal novou práci, zjistil jsem, že počet firem, které u nás Node.js testují, se počítá na desítky. A pokud dnes už s Node.js umíte pracovat a chcete v něm vyvíjet, práci nejspíš seženete. Samozřejmě je nabídka nižší než třeba u PHP, ale za poslední dobu se to hodně zlepšilo a také díky TypeScriptu či CoffeeScriptu 2.0 nejspíš ještě jeho podpora hodně poroste.

Během psaní seriálu jsem dostal velmi mnoho pozitivních reakcí, kterých si vážím a které mě motivovaly/motivují k dalšímu pokračování seriálu. Za všechny zmíním dvě od člověka, kterého si asi všichni u nás vybaví jako první, když se řekne slovo “JavaScript”, Daniela Steigerwalda, a které mě potěsily asi nejvíce:

K seriálu o Node.js

K seriálu o Node.js

 

K seriálu o tvorbě e-shopu

Rubriky: Nezařazené | Napsat komentář

Yeoman pro AngularJS a TypeScript

Publikováno 6.3.2013 | Autor: Ronnie

Protože v Imatic Software budeme stavět nějaké pěkné projekty nad AngularJS a jsou poměrně rozsáhlé, tak jsme se rozhodli použít TypeScript, který doplňuje do JavaScriptu typy, rozhraní, třídy, moduly a mnoho dalších možností. Vzhledem k tomu, že budeme používat velké množství dalších doplňků, potřebovali jsme nějaký nástroj, pod kterým by se dal celý projekt spravovat snáze a rozhodl jsme se využít nástroj Yeoman.

Níže popsána je podpora skrze Yeomana pro tyto nástroje:

  • TypeScript jako hlavní programovací jazyk,
  • AngularJS jako MVVM framework,
  • Mocha pro jednotkové, popř. integrační testy,
  • Scenario Runner pro E2E testy,
  • Testacular pro spouštění testů pod různými prohlížeči,
  • Apiary.io pro práci s REST API,
  • LESS preprocesor pro CSS,
  • Twitter Bootstrap jako CSS framework,
  • Yeoman pro scaffolding,
  • Grunt pro úkoly související s deploymentem,
  • Bower pro správu javascriptových klientských knihoven,
  • WebStorm jako IDE.

Bohužel Yeoman nemá podporu pro TypeScript u generování šablon, takže jsem ji dnes do projektu doplnil, k dispozici je repozitář https://github.com/JakubMrozek/generator-angular-typescript, což je fork generátoru pro AngularJS od autorů Yeomana. Kromě toho jsem doplnil podporu pro všechny ostatní zmíněné nástroje a odstranil závislost na Ruby a opravil nějaké chyby, kvůli kterým to nefungovalo pod Windows, mělo by to jet tedy na všech platformách.

Všechna rozhraní definovaná pro AngularJS jsou z tohoto projektu: https://github.com/borisyankov/DefinitelyTyped/tree/master/angularjs. Kvůli lite verzi jQuery, která je uvnitř AngularJS, jsou zde i typy pro jQuery.

Nutno říct, že je to zatím pouze nástřel a nefunguje úplně vše, ale pokud chcete používat TypeScript s AngularJS, můžete se inspirovat. Kromě toho budeme velmi rádi za nějaký feedback, fork a opravy chyb ap. (je to výsledek jednodenní práce a ještě to není použito při ostrém vývoji, vím, že zatím nefunguje správně buildování a grunt test).

Instalace je poměrně triviální.

1. Potřebujete mít nainstalován nástroj Yeoman, Grunt a Bower.

npm install yo grunt-cli bower -g

2. Dále potřebujete nainstalovat balíček přímo z githubu (není to npm balíček).

npm install git://github.com/JakubMrozek/generator-angular-typescript.git

3. Dále je potřeba vygenerovat kostru projektu s typescriptem.

yo angular --typescript

4. Nakonec je potřeba nainstalovat všechny závislosti přes npm a bower.

npm install && bower install

A to je vše. Nyní když zadáte příkaz “grunt server”, měla by se vám objevit úvodní stránka nového projektu. Kdykoliv editujete LESS soubory, TypeScript ap, tak se změny hned zkompilují. Kromě toho je podporován live reload, takže změny by se měly hned dostat do prohlížeče bez nutnosti reloadu.

Dále je samozřejmě podporován standardní scaffolding, takže např.

yo angular:controller user --typescript

vygeneruje nový AngularJS controller User, a to vč. testů. Vše je podrobně popsáno na úvodní stránce v repu.

Feedback, nápady, bugy můžete psát jak do issues, tak mně na e-mail jakub.mrozek@gmail.com. Díky moc!

Rubriky: Nezařazené | Napsat komentář

HTML5 a co můžeme začít používat

Publikováno 13.2.2013 | Autor: Ronnie

Poslední rok jsem docela dost času trávil tím, že jsem si procházel všechny novinky v HTML5, JavaScriptu či CSS3 a sledoval jsem ty, kterým se třeba nedostává tolik publicity a které jsou už nyní podporované ve všech hlavních rohížečích (IE, FF, Chrome). Zde je nijak nesetřízený seznam některých mých poznámek.

  • Přes metodu document.querySelector()/element.querySelector() je možné používat CSS selectory k vyhledávání elementů na stránce podobně jako třeba v jQuery http://www.javascriptkit.com/dhtmltutors/css_selectors_api.shtml. Podpora je ve všech prohlížečích vč. IE od 8. verze. Zvažte, zda je skutečně nezbytně nutné vždy používat jQuery.
  • Podobně je k dispozici metoda document.getElementsByClassName(), která tedy vybere z dokumentu elementy podle jejich tříd. V IE je však podpora až od 9. verze.
  • IE od verze 10 přestává podporovat podmíněné komentáře. IE je už dnes rovnocenný prohlížeč podporující standardy, takže je to pochopitelné. Myslím si, že nástup Google Chrome a reakce Internet Exploreru je ukázkový příklad toho, co dělá konkurence a soutěž.
  • Element script má k dispozic atributy defer a async: http://www.w3schools.com/tags/att_script_defer.asp. Jestliže načítáme externí skript, prohlížeč zastaví zpracování stránky dokud skript nenačte a nevykoná. Pokud přidáme atribut defer, pak se tohle chování změní a skript bude vykonán až tehdy, jakmile dojde k načtení celé stránky. Atribut async umožňuje asynchronní zpracování, tedy skript se bude zpracovávat zatímco bude stránka nahrávaná. Defer je podporován všude už dlouho, async až od IE 10.
  • IE od verze 8 podporuje pro XHTML dokumenty Content-Type application/xhtml+xml.
  • K dispozici je také Navigation Timing API: https://developer.mozilla.org/en-US/docs/Navigation_timing. Umožňuje zjišťovat různé informace třeba o tom, jak dlouho trvalo prohlížeči zracovat DOM.
  • XMLHttpRequest level 2 přináší zajímavé novinky: http://www.html5rocks.com/en/tutorials/file/xhr2/. Třeba možnost přes AJAX posílat soubory či získávat průběžné informace o stavu nahrávání souboru. Podpora od IE10.
  • Docela dobrá podpora je už i pro SVG (IE od 9. verze). Základní srovnání canvas a svg např. zde: http://www.w3schools.com/html/html5_svg.asp. Canvas je podporován od IE8. Existuje také WebGL pro Canvas 3D grafiku, zde je však podpora pouze v Chrome.
  • Všechny prohlížeče bez problémů podporují contenteditable atribut, který umožňuje jakýkoliv HTML element udělat editovatelný. Ukázka například zde: http://html5demos.com/contenteditable.
  • Solidní podpora je i pro Drag&Drop přes HTML5: http://www.w3schools.com/html/html5_draganddrop.asp (IE už od verze 7, ovšem až od verze 10 je podpora plná). Pokud sledujete můj seriál o tvorbě moderního e-shppu na Zdrojáku, tak jste si možná všimli, že velmi rád tyhle novinky používám. Drag & drop nebude výjimkou, sekce Kategorie v administraci bude na tomto postavená.
  • Offline aplikace (pomocí cache manifest) jsou také podporovány všude, v IE od 10 verze. Přemýšlím, že jako offline aplikaci udělám právě administraci k vyvíjenému e-shopu, tam to má smysl. Info v češtině například zde: http://www.zdrojak.cz/clanky/html5-offline-webove-aplikace/.
  • HTML5 History API umožňující dynamicky měnit URL je také docela dobře podporováno, IE bohužel až od 10. verze. Nicméně třeba AngularJS má tohle docela hezky vyřešeno. Pokud prohlížeč History API podporuje, mění URL dynamicky. Pokud ho nepodporuje, přesměruje prohlížeč na URL ve tvaru example.com/#/stranka, takže programátor tohle v podstatě řešit nemusí, protože je událost hashchange podporována už od IE 8.
  • Hodně se mi líbí nové možnosti u formulářů. Těch je celá řada, především nové typy elementů (výběr data, slider ap.). Velmi užietečné jsou též atributy pro validaci, je možné formulářový prvek označit jako povinný a třeba dokonce určit jeho přesný formát pomocí regulárního výrazu. Validace jsou podporovány od IE 10, ostatní části jak kde, žádný prohlížeč neimplementuje 100%. Jak vypadá upozornění prohlížeče na chybně zadaný obsah pole je možné vidět v mém seriálu na Zdrojáku: http://www.zdrojak.cz/clanky/nakupni-kosik-pomoci-html5-web-storage/.
  • K odkazu je možné přidat nyní atribut download. Ten říká, že prohlížeč má obsah na daném odkazu rovnou stáhnout. Podpora ale jen u Chrome a Firefoxu.
  • HTML5 Web Storage pro ukládání dat do prohlížeče je možné bez obav používat už všude. V IE je podpora od 8. verze. HTML5 Web Storage používám i v seriálu na Zdrojáku.
  • Pod zkratkou CORS se rozumí možnost používat AJAX i pro dotazovaní na jiné domény. Podpora od IE8, úplná však až od IE10.
  • HTML5 Geolocation API pro zjišťování polohy, nadmořské výšky ap. je podporováno od IE8: https://developer.mozilla.org/en-US/docs/Using_geolocation.
  • Web Workers a Web Sockets je podporováno od IE 10.
  • Od IE 10 je také dostupná v prohlížečích NoSQL databáze IndexedDB: https://developer.mozilla.org/en-US/docs/IndexedDB/Using_IndexedDB.
  • NetBeans 7.3 přináší celou řadu inovací především pro ty, co chtějí stavět HTML5 aplikace: http://wiki.netbeans.org/NetBeans_73_NewAndNoteworthy.


Existuje pak celá řada dalších novinek, které však nejsou nejčastěji v IE podporovány. Obecně má zdaleka nejlepší podporu pro novinky v HTML5/CSS3/JS Google Chrome. Ze statistik vyplývá, že díky automatické aktualizaci prohlížečů mají uživatelé vždy aktuální Chrome či Firefox. Bohužel u IE je to jinak a největší podíl má IE8 (IE6 a IE7 jsou už vhodné do muzea), takže některé z výše uvedených novinek je možné používat třeba jen pro administraci, kde víme, že zde chodí jen několik uživatelů a s novými verzemi prohlížečů.

Rubriky: HTML5 | Napsat komentář

Proč by měl být Karel Schwarzenberg prezidentem ČR

Publikováno 29.12.2012 | Autor: Ronnie

Původně jsem tady na blogu nikdy nechtěl psát o ničem jiném než o programování, ale když je největším favoritem na prezidentský úřad někdo jako Jan Fischer…

Komunistická strana

Pokud náhodou nevíte, o jakou stranu jde, je to ideově stejná strana, která vládne v KLDR, tedy v zemi, kde jsou ještě dnes klasické koncentrační tábory (o životě v koncentračním táboře KLDR výborně vypovídá kniha Pchojngjangská akvária, vřele doporučuji). Pokud myslíte, že je hloupé srovnávat komunistickou stranu v KLDR a u nás a že jsou to dvě naprosto odlišné strany, pak vás možná mohl zaujmout dopis, který před rokem adresoval V. Filip, předseda KSČM, představitelům KLDR:

„Vážený soudruhu, s hlubokou lítostí jsem přijal smutnou zprávu, že Kim Čong-il, velký vůdce Vaší země, zesnul. Vážili jsme si jeho obětavé práce pro blaho korejského lidu, pro zajištění bezpečnosti KLDR a pro mírové sjednocení Korejského poloostrova. Komunistická strana Čech a Moravy pevně věří, že Korejská strana práce překoná nynější smutek a dál povede hrdinný boj korejského lidu za obranu socialismu ve Vaší zemi. Přijměte, prosím, můj soudružský pozdrav.“

Mimochodem tato strana, a je to opravdu těžké tomu uvěřit, nedávno fakticky vyhrála v krajských volbách u nás.

Proč NE Jan Fischer

Členem Komunistické strany Československa byl 10 let také nynější hlavní favorit na post prezidenta, Jan Fischer. Členem byl v době, kdy již existoval dostatek materiálů o zločinech, které komunisté spáchali a Jan Fischer dobře věděl, jakou stranu podporuje. I kdyby byl členem pod vidinou vlastního prospěchu a nikoliv přesvědčením, je to úplně jedno. Stranu podporoval minimálně tím, že v ní byl, a to dlouhých 10 let.
Pro mě osobně tento důvod dostačuje k tomu, abych o Janu Fischerovi vůbec dále neuvažoval.

Kromě jeho členství mi ale vadí i celá řada dalších věcí, především jsem nikdy neviděl rozhovor, ve kterém by se J. Fischer nevyhýbal kontroverzním otázkám s cílem neztratit popularitu.

Pravomoci prezidenta

Postavení prezidenta v našem právním řádu je výrazně odlišné od některých jiných zemí. Prezident ČR má velmi omezené pravomoci a fakticky funguje především jako reprezentant země. Může sice vetovat zákony, ale jeho veto je velmi slabé, stačí nadpoloviční většina poslanců a zákon je přijat (srovnejte s USA, kde je potřeba 2/3 kongresmenů). Jeho pozice se značně odlišuje třeba od pozice premiéra, kde musí být člověk fyzicky velmi zdatný a s dostatkem energie pro řízení země. Prezident je hlavně reprezentant a jsou na něj tedy kladeny jiné nároky.

Prezident musí být osoba, které si můžu vážit a která celý svůj život brání demokracii a svobodu a která je ve svých názorech konzistentní a nebojí se za ně. A taková osobnost v nynější volbě je.

Proč ANO Karel Schwarzenberg

V době, kdy J. Fischer „přestal“ být komunistou, Karel Schwarzenberg byl již 15 let předsedou Mezinárodního helsinského výboru pro lidská práva. Celý svůj život bránil myšlenky demokracie, podporoval československý disent a třeba vytvořil knihovnu, kde jsou shromážděny díla tehdy zakázaných autorů. Bojoval také proti korupci (vzpomeňte audit, který nechal vypracovat kvůli J. Čunkovi), byl prvním kancléřem prezidenta Havla. Je držitelem mnoha vyznamenání, třeba získal Cenu lidských práv Rady Evropy. Byť s ním v některých názorech nemusíme souhlasit, třeba na EU, je těžké zpochybnit Karla Schwarzenberga jako morální autoritu.

Podpořte Karla Schwarzenberga!

Pokud máte stejný názor jako já a myslíte si, že by měl být Karel Schwarzenberg prezidentem, nebuďte k volbě lhostejní a vyjadřujte mu veřejně podporu jako v poslední době celá řada známých osobností, což je třeba ve volbách v USA velmi důležité. I když Karel Schwarzenberg ve volebních průzkumech zaostává, z průzkumů také vyplývá, že je zde značné procento lidí, kteří k volbám půjdou, ale nejsou pro kandidáta ještě rozhodnuti. A s ohledem na sílící hlasy proti Janu Ficherovi a pro podporu K. Schwarzenberga je dost možné, že volba nemusí dopadnout tak, jak nechceme.

Vyjádřete mu svojí podporu na sociálních sítích, blozích a pokuste se přesvědčit lidi ve svém okolí, že mají podporovat osobnost, jakou je Karel Schwarzenberg.

Rubriky: Nezařazené | Napsat komentář

O TJ Holowaychukovi, jeho programátorské genialitě a o tom, jak mě ovlivnil

Publikováno 22.12.2012 | Autor: Ronnie

A o tom, jak jsem přešel od PHP k Node.js.

Genius TJ Holowaychuk

Když jsem připravoval tuším 10. díl pro seriál na Zdrojáku a procházel jsem různé balíčky, které bych v článku zmínil, narazil jsem během psaní dílu několikrát na modul, který buď TJ udělal sám, nebo se na něm výrazně podílel. A než jsem ten díl během několika hodin dokončil, TJ další balíček vytvořil a vydal ho Node.js komunitě. To se stalo vícekrát, ale tentokrát mi to už nedalo a musel jsem o něm do článku jeden kratší odstavec přidat.

TJ je autorem frameworku Connect a Express, které jsou základem snad každé webové aplikace v Node.js (v roce 2010 jich bylo přibližně 2000, o rok později něco málo přes 20 tis. a dnes na Node.js funguje více než 100 tis. aplikací – to pro ty, kteří si myslí, že Node.js je stále jen buzzword). Na Expressu je dokonce postavena i mobilní a tabletová verze sociální sítě LinkedIn.

TJ není autor jen těchto dvou modulů, vytvořil jich jen v Node.js více než 230. A nejde o žádné okrajové záležitosti, je autorem populárního CSS preprocesoru Stylus, šablonovacího systému Jade, dle mého názoru nejlepšího frameworku pro testování Mocha, modulu supertest pro extrémně jednoduché integrační testování, knihovny should.js pro asertace nebo balíčku component, přes který můžete instalovat stovky javascriptových komponent. A to jen v Node.js, další jazyky nepočítám. K tomu všemu si přičtěte správu těchto projektů, řešení bugů, tvorbu dokumentace ap. Na diskusních fórech je možné nalézt příspěvky, kde se lidé podivují nad tím, jak může být TJ tak neuvěřitelně produktivní a nazývají ho stejně jako třeba Dan Steigerwald v jedné své přednášce jako „hero“.

Proč o něm píšu. Jeho umění a genialita na mě zapůsobila tak, že jsem během roku úplně změnil svůj programátorský život.

Já a PHP

S PHP jsem strávil mnoho let. Myslím, že první skript jsem mohl napsat tak kolem roku 2002 a byl to guestbook k třídním stránkám (kdo takhle nezačínal?). V roce 2005 jsem dostal legendární knihu PHP5: Programujeme profesionálně, která mě velmi ovlivnila především v jedné věci. Narazil jsem v ní na pojem „Objektově orientované programování“. To bylo v době, kdy žádné frameworky jako Zend či Nette u nás nebyly a OOP v PHP byl naprosto neznámý pojem (v PHP4 objekty používal jen nějaký dgx).

Pamatuji si, že jsem v té době nemohl pochopit některé principy OOP zmíněné velmi zrychleně v dané knize, což vedlo k tomu, že jsem vytvořil web o OOP v PHP5, kde jsem přeložil texty z anglického materiálu. Když se pak v PHP komunitě začalo více o OOP mluvit, web se stával velmi populárním s denní návštěvností přes 100 unikátních návštěvníků, což je na pár krátkých článků na takto unikátní tématiku docela dost. Dokonce se stal materiálem pro studium webových technologií na některých vysokých školách. Později ho odkoupil Interval.cz za částku, která se obvykle platí autorům za celou knihu. Za týdenní práci to nebylo špatné.

Kolem roku 2006 jsem se věnoval OOP čím dál tím více, četl jsem hlavně materiály v češtině o návrhových vzorech a učil se je zpaměti. Všechny ty principy a teorie byly krásné, ale v PHP se těžko aplikovaly, pořád zde nebyly dnes známé frameworky a vedly se diskuse o tom, k čemu vlastně OOP je a zda je opravdu potřeba (dnes docela legrační, že?).

Já a Java

Vše se změnilo s příchodem na vysokou školu, kde jsem se seznámil s Javou a okamžitě jsem si ji zamiloval. Nikde neexistuje tolik materiálů, příkladů o objektech jako v Javě (rozhodně velmi doporučuji všem, aby se Javu naučili, i když ji třeba pak nebudou používat, každý nový programovací jazyk člověku rozšíří obzory a pro Javu to platí dvojnásob). U Javy jsem vydržel přibližně rok a můj poslední program v Javě byl generátor rozvrhu. Byl poslední, protože jsem si uvědomil, že jazyky jako Java nejsou pro mě. Tehdy jsem raději nejprve celý program napsal v PHP a pro zápočet ho přepsal do Javy, protože práce s HashMapy, HashSety ap. byla pro mě úděsná a byl jsem už dlouho zhýčkaný jednduchostí práce s poli v PHP. K Javě jsem se ještě na chvíli vrátil před pár měsíci kvůli jednomu programu pro Android, ale můj vztah k ní se nezměnil.

Já a Zend framework

Javu jsem opustil také z toho důvodu, že v té době vznikal Zend Framework. Pro mě to byla tehdy senzace, protože všechny ty OOP nádhery najednou šlo používat i v PHP, které se Javou velmi inspirovalo. Zend jsem si okamžitě zamiloval především kvůli tomu, že ze začátku dbal hodně na krásu. Na Zendu šlo najít implementaci celé řady návrhových vzorů a Zend se profiloval jako framework, který má demonstrovat, že i OOP v PHP už existuje. Začal jsem o něm psát na blogu a napsal jsem o něm tehdy docela čtený tutoriál.

O něco později u nás také začalo Nette, na které jsem se původně díval skrze prsty, protože jsem ho považoval jen za jeden z mnoha domácích frameworků a vážně obdivuji Davida, co s Nette dokázal. Dnes kdybych dělal něco v PHP, tak vůbec neváhám a je pro mě Nette jasná volba.

Já, ILIKETHIS! a W3W

Před 6 roky jsem začal pracovat pro W3W, což byla v té době moje 4. pracovní zkušenost a rozhodně zdaleka nejlepší. Zde jsem byl v podstatě od začátku,  a tak jsem si mohl zvolit cokoliv, co chci používat, což v té době znamenalo především Zend.

Tehdy to bylo úžasné, protože jsem přicházel z dnes už neexistující společnosti ILIKETHIS!, kde bylo ještě staré PHP4, stará databáze a vše nesmírně zastaralé a nefunkční. Nejvíce mi ale vadilo to, že jsem poznal, co to znamená rutina, tedy když někdo pracuje od 8 do 16 a nemá vůbec zájem o něco nového. Zde jsem vydržel přesně 5 měsíců navzdory tomu, že jsem 3x podával výpověď. Ale i když mi tehdy bylo 19 a věkový průměr byl 32, tak se mi podařilo přesvědčit ostatní, abychom přešli na PHP5, abychom začali používat Zend Framework, pětkovou MySQL ap., ale poznal jsem prostředí velké, neflexibilní společnosti a dnes už díky tomu vím, že bych v takovém prostředí nikdy pracovat nechtěl.

Ve W3W jsme dělali spoustu zajímavých projektů a pro poměrně velké klienty, třeba GE Money Bank nebo Roche. Ale hlavně jsem zde dělal první cca 2,5 roku e-commerce řešení Shopio, na kterém dnes funguje cca 100 e-shopů, včetně i některých docela známých jako SkutečnýDárek.cz, za který W3W dostalo i nějakou cenu.

Práce na Shopiu byla první rok úžasná a neskutečně jsem si ji užíval a ten první rok jsem na Shopiu pracoval snad každou chvíli. Především mě ohromně bavilo něco budovat, stavět s nějakou vizí prestižního, celosvětově známého systému. Bohužel jsme však po čase narazili na to, na co naráží všechny úspěšné IT firmy u nás: na nedostatek pracovních sil. A tak jsem spíše druhý rok řešil většinou samotné konkrétní klientské e-shopy, což se pro mě stávalo stereotypem a práce mě přestávala naplňovat. A tak jsem Shopio přenechal ostatním klukům ve firmě, kteří se o něj hezky starají dodnes a přešel jsem k jiným projektům.

Já a programátorská krize

V té době jsem se ale začal potýkat s tím, že jsem pomalu ztrácel o programování zájem a svojí budoucnost v IT jsem viděl čím dál tím více skeptičtěji. Přestávalo mě bavit programovat cokoliv a s čímkoliv. Zrušil jsem svůj blog s mnoha články, zrušil jsem svůj původní Twitter účet a mezi roky 2009 a 2011 jsem snad nepřečetl jediný technický článek. Myslím, že se tomu říká internetová sebevražda, kdy má člověk tendenci úplně vymizet z online světa a ztrácí zájem a o vše, co s tím souvisí.

Taky k tomu přispěl Zend Framework, protože jsem už pochopil, že je to jen akademická záležitost. Kdybyste chtěli dát do Zendu něco, co třeba všechny prohlížeče podporují a běžně se to používá, ale není to součástí nějakého standardu, tak se to tam nedostane, protože to prostě není součástí standardu. A tak si třeba danou část musíte přepsat, abyste ji vůbec mohli používat. Zend vůbec není napsaný pěkně, jak se o něm někdy tvrdí a poznal jsem to třeba na Zend Lucene. Kromě toho, že je to v praxi totálně nepoužitelná věc, tak je napsán tak, že se nesmírně těžko rozšiřuje a vedlo to až k tomu, že jsem si musel celou třídu zkopírovat a jen malou část kódu přepsat (OMG!). A Zend Framework 2 je kapitola sama pro sebe. Když Zend začínal, byla to jasná volba, ale dnes je to pro mě velké zklamání a rozhodně nikomu nedoporučuji o ZF2 ani uvažovat (běžte do Nette, vážně).

Já a Node.js

Až minulý rok jsme pozdě věčer na mailu s Ondrou Vysokým diskutovali o tom, co použijem pro jeden interní projekt a Ondra tehdy navrhl, ať se zkusím mrknout na ten Node.js, že to může být zajímavý, že o tom pak napíšem na blogu, jak jsme moderní. No a tak jsem se ještě před ulehnutím podíval, cože to ten Node.js vlastně je a šel jsem spát až asi o 6 hodin později. O pár dní později jsme ve W3W nakoupili asi 10 nejčtenějších knih o JavaScriptu ve světě vč. všech známých titulů a já je do konce února přečetl a kolegům jsem z nich udělal dokonce podrobné výpisky. A od té doby každý den trávím u JavaScriptu a Node.js několik hodin, v polovině roku jsem kvůi tomu i opustil W3W.

Proč Node.js

Mám rád JavaScript. Říká se, že JavaScript je nejvíce nepochopený jazyk. A já s tím naprosto souhlasím. Problém je především v tom, že málokdo přechází od JavaScriptu třeba k Javě, ale mnohem častější je, že má někdo již základy OOP třeba v Javě a pak musí používat i JavaScript. A protože JavaScript je postavený na jiných principech, byť je to objektově orientovaný jazyk, tak způsobuje frustrace těm, kteří ho chtějí používat jako Javu, což prostě nejde.

Když má člověk několik let silně zažité všechny principy, vzory, pravidla z jazyků jako Java či C#, je pro něj těžké dívat se na JavaScript jako na plnohodnotný jazyk. Je to problém i velmi zkušených a špičkových programátorů. Třeba kniha JavaScript Design Patterns věnuje jednu z prvních kapitol tvorbě rozhraní, jaká jsou třeba v Javě či PHP. Celá kapitola rozebírá různé možnosti, jak je simulovat v JavaScriptu a končí steskem, že to prostě v JS nejde. To je přesně ten případ, kdy se někdo snaží z JavaScriptu dělat něco, co není. JavaScript je jiný. Má prototypovou dědičnost a má closures, což jsou ohromně silné vlastnosti jazyka, které zase nejsou jinde.

Hrozně moc se mi líbí styl, jakým píše programy TJ. Je to genius minimalismu. Pro mě jsou jeho moduly krásně čitelné. Dokumentace je většinou nějaký příklad a zbytek si přečtu ze zdrojáku, které má dokumentované jako málokdo. A není jediný, programátorů, kteří vydali 100+ modulů je mnohem více. To je důkaz, že člověk může být v JavaScriptu extrémně produktivní. TJ a jeho styl psaní a programování byl důvod, proč mě programování zase začalo bavit. Snažím se ho kopírovat jak to jen jde.

Začínám se bát, že právě v PHP začíná být „přeobjektováno“. Že se mnoho lidí naučilo zpaměti různé poučky a principy a teď je slepě používají. Člověk si vytváří vzory pro různé situace, aby nemusel řešení vymýšlet pořád dokola. Bohužel se pak často stává jejich obětí a používá je i tam, kde je to vysoce neefektivní. Protože je to jednodušší, není potřeba myslet, pokud daná situace část příznaků splňuje, stačí daný pattern aplikovat. Vzorový příklad je ESCR plugin a řešení Jirky Knesla a Jakuba Vrány. Někdo se bude na Jakubovo řešení dívat skrze prosty, protože tam prostě nejsou ty třídy a je to jen blbá funkce. Co na tom, že je mnohem přehlednější, rychlejší, efektivnější atd.

Bohužel programování je mnohem složitější a každá situace je jiná. A to je přesně důvod, proč TJ označuji za génia. Protože on dokáže pro danou situaci najít to nejvhodnější řešení, někdy danou věc implementuje jako funkci, někdy jako třídu, někdy jako nějaký vzor atd., ale vždy se mi to výborně používá. Naprostý protiklad je Zend Framework 2, což je úžasná ukázka „přeobjektování“, kdy se framework stal po 5 letech vývoje v podstatě nepoužitelný a než v něm napíšete jeden modul v administraci, doběhne jeden mayský kalendář.

Další důvod, proč jsem od PHP odešel, je rychlost vývoje. Rozhodně nesouhlasím v tom, že se v PHP píše jednoduše a rychle. Příkladem je testování. Jedním příkazem nainstaluji v Node.js jeden z mnoha frameworků a třeba v CoffeeScriptu a ve frameworku Mocha napíšu test takto:

it 'popis testu', -> 'a'.should.eql 'a'

A to je vše! Díky tomu jsem se naučil v Node.js psát testy pro všechno, protože jejich vytvoření je pro mě otázka několika vteřin. V PHP jsem se o to pokoušel mnohokrát, ale nikdy jsem si k jednotkovým testům cestu nenašel, protože mě to stálo vždy mnoho času a sil. Když vidím, jak vypadají testy v PHPUnit, tak se moc nedivím, že testy v PHP příliš nezdomácněly. PHPUnit je strašně zastaralý, pro mě v podstatě nepoužitelný framework.

S tím souvisí i zbytek ekosystému v PHP. Chybí tady třeba nástroj pro integrační testování jako je v Node.js supertest, bez kterého si už nedokážu vůbec svoji práci představit.

Další věc, která je pro mě v Node.js důležitá je, npm, tedy balíčkovací systém, který má značný podíl na tom, že si Node.js získal takovou popularitu. Moje hobby je procházet tyhle balíčky když mám chvíli času. Pak když jsem psal Lingano, tak nic většího jsem nemusel programovat. Třeba přihlašování k FB, Twitteru a Google jsem měl během pár minut přes Passport.js. Všechno je na Githubu, všichni začali psát stejný způsob dokumentace, takže je dokážu začít používat nesmírně rychle. Mimochodem Github je největší revoluce v open source za posledních 10 let. Programy v Node.js píšou už všichni. Testacular od Vojty Jíny z Google, bower z Twitteru je taky Node.js program, atd. atd.

PHP sice má composer, ale to není totéž. Rozdíl je v architektuře. V Node.js se nemusím omezovat množstvím modulů, protože se načtou při první inicializaci programu. V PHP to neplatí, nemůžu si nasekat do programu kolik souborů chci, protože se budou při requestu načítat a musím s tím počítat. V Node.js ne (pravda, v Node.js musím hlídat asynchronní zpracování, takže v tomto ohledu také benevolentní být nemohu, ale to třeba pro mě problém není). V PHP musím řešit to, že se při každém requestu načítá celý framework, inicializuje se spojení s databází ap., což znamená řešit řadu problémů, které v Node.js řešit nemusím (byť to tak na první pohled vypadat nemusí).

Pak je samozřejmě mnoho různých dalších důvodů jako je jeden jazyk pro server a pro klienta. Socket.io pro real-timové weby. Tvorba API v Node.js a nástroje, které k tomu jsou. Úžasná komunita kolem Node.js je všeobecně známá věc. Ale především je to ta rychlost a jednoduchost, kterou mi Node.js přinesl.

To jsou ty hlavní důvody, proč jsem k Node.js přešel.

Rubriky: Node.js | Napsat komentář

Proč psát testy?

Publikováno 27.10.2012 | Autor: Ronnie

Pracujete v menší IT firmě, která právě dokončuje e-shop pro vašeho důležitého zákazníka. E-shop měl být původně spuštěn již v pondělí, bohužel se dokončování protáhlo do konce týdne (klasická situace) a e-shop musí být do konce týdne spuštěn, protože je připravena reklamní kampaň, která začíná právě v pondělí.

Je pátek odpoledne, e-shop je dokončen a jde se na nasazení do ostrého provozu. Vše proběhlo podle plánu. Na závěr ještě vyzkoušet proces objednávání a nové funkce. Bez nejmenších problémů vše běží. Začíná víkend a všichni odjíždí pryč. Tedy až na jednoho kolegu, který se obětoval pro dobro firmy a zůstane k dispozici pro případné rychlé opravy. Ten během víkendu párkrát e-shop zkontroluje, aby se ujistil, že je vše v pořádku.

Po víkendu v pondělí ráno v práci panuje nezvykle příjemná atmosféra, když vedoucímu projektu zazvoní telefón. Po prvních vteřinách hovoru přechází projekťák k notebooku, kde si prohlíží administraci e-shopu, a s chvějícím se hlasem do telefonu odpovídá, že vše prověří. Volal zákazník, který si stěžoval na to, že v systému není jediná nová objednávka od spuštění systému, ačkoliv je předvánoční doba a o víkendu mají v tuto dobu obvykle i 500 nových objednávek.

Projektový vedoucí zkouší zadat novou objednávku a vše bez problémů funguje. Jak je možné, že v databázi není žádná jiná objednávka?! Když si programátoři prohlédnou kód, najdou fatální chybu. Proces objednání funguje jen ve chvíli, kdy je uživatel přihlášen jako správce. Protože byly přidávány nové funkce do systému, vedoucí projektu byl přihlášen jako správce, aby mohl kontrolovat i funkce v adminstraci a nikdo objednávací proces po poslední úpravě netestoval jako běžný uživatel…

Nastává hororová situace. Potvrzení o objednávce je odesláno jen zákazníkovi. Byl tady i požadavek na kopii pro správce e-shopu, ale ten byl plánován jako méně prioritní až na příští období. Nikdo neví, kolik objednávek proběhlo. Někteří zákazníci za objednávku již zaplatili, jenže jediné, co se ví, je variabilní symbol a částka. Nevíte, komu objednávku poslat. A musíte to řešit rychle, je před Vánoci.

Co teď? Napsat o události na stránky e-shopu? Tam už ti zákazníci nepřijdou, nebudou o tom vědět. Napsat všem, co se přihlásili k newsletteru? Ke všem se to nedostane a o všechny ostatní zákazníky navždy přijdete. Situace je kritická. Začínají chodit dotazy, co se děje, proč zboží nebylo vyexpedováno. Začínají se objevovat negativní reference na e-shop. O pár dní později se objevuje televizní reportáž o nekalých praktikách e-shopu, který bral od zákazníků peníze a nic jim neposílal. Chyba dodavatele? A koho to zajímá? E-shop přišel zcela o důvěru. Sklady zboží jsou přeplněné, nikdo si už nic objednávat nechce. Konec podnikání.

Šlo tomu předejít? Stačil jednoduchý test v kritické části systému. Musel by selhat, pokud by ve zdrojácích zůstal kód, který tam nemá co dělat a fungoval jen tehdy, prováděl-li objednávku správce. Stačilo pár minut věnovaných napsání testu a nic se nemuselo stát.

Rubriky: Nezařazené | Štítky: | Napsat komentář

Seriál o Node.js na Zdrojáku

Publikováno 17.9.2012 | Autor: Ronnie

Od pátku (20.9.) se můžete těšit na seriál o Node.js na Zdrojáku. Rozhodl jsem se rovnou navázat na první díl od Jakuba Nešetřila, takže ostatní díly pak najdete zde: http://www.zdrojak.cz/serialy/node-js-s-javascriptem-na-serveru/.

Seriál bude vycházet každý pátek a aktuálně jsou 4 díly připraveny k vydání a 5. (resp. s prvním dílem od Jakuba 6.) se připravuje. Seriál to bude nejspíš docela dost dlouhý, ale myslím si, že bude stát za to, protože nevím o žádném jiném, který by Node.js popisoval jako ten, co bude na Zdrojáku (popíšu dále).

První díl jsem psal tak, aby hlavně návštěvníky zaujal a upozornil je na to, že tady existuje něco jako Node.js a že rozhodně stojí za pozornost. Další dva díly se pak věnují základům a od 4. dílu už začnu psát aplikaci. Každý další díl bude věnován dalším tématu kolem Node.js, které souvisí s aktuální vyvíjenou částí, takže tam bude určitě díl o frameworcích, o Socket.IO atd.

Teď to nejzajímavější. Přemýšlel jsem dlouho, jak ten seriál pojmout. Nikde jsem neviděl tutoriál o Node.js takový, aby dokázal ukázat tu pravou sílu Node.js. Tohle pokusím změnit, takže vyvíjená aplikace:

  • bude postavena jako single-page aplikace s frameworkem AngularJS, ukážu na ní obrovskou výhodu sdílení kódu mezi klientem a serverem vč. třeba stejného testovacího prostředí (bude SEO friendly),
  • bude postavena s RESTful API, které se velmi jednoduše testuje a umožňuje aplikaci snadno napojit třeba na mobilní verzi
  • bude mít prvky real-time aplikace

A co to bude? Bude to real-time e-shop. Ne žádný primitivní, bude to normální internetový obchod, který půjde ihned nasadit. Bude multijazyčný, bude umožňovat normálně zpracovávat objednávky, vše. Žádný Hello customer e-shop:-)

A co znamená to real-time? Bude umožňovat správci e-shopu sledovat svého zákazníka, jak nakupuje, co má v košíku a také ho kontaktovat a třeba mu pomoci. Úplně stejně jako to dělají prodavači v normálním obchodě, takže může zákazníkovi poradit s nákupem ap.

Co dále bude v seriálu?

  • Všechny zdrojáky budou na githubu, každý nový díl bude mít vlastní tag, takže jednoduchým příkazem git checkout čtenář stáhne zdroják aktuálního dílu.
  • Hned v prvním díle s popisem aplikace rovnou zdrojáky pošleme do cloudu. Provedu vás vytvořením účtu na Heroku.com, veškerým nastavením a deploymentem, takže po každém díle můžete mít aplikaci okamžitě zveřejněnou. S Gitem se v tomto ohledu pracuje fantasticky rychle.
  • Jak už bylo řečeno, pro klientský JavaScript použiji AngularJS. Ten ale není úplně nejjednodušší a přeci jen seriál je hlavně o Node.js, takže se budu snažit používat jen to nejjednodušší z Angularu, ale vše potřebné vždy popíšu, aby tomu každý rozuměl.
  • Jako databázi použiji MongoDB. Píšu o ní bakalářku a pracuje se mi s ní fakt dobře a myslím si, že e-shop typ aplikace, která bude z NoSQL těžit. Zatím plánuji jen tuto databázi, ale možná v dalších dílech popíšu i napojení na Redis pro práci s cache a sessions a ElasticSearch pro vyhledávání. Ale to pravděpodobně až v dalších dílech.
  • Hodně bude aplikace pracovat s prvky HTML5. Web Sockets, History API, LocalStorage.
  • Aplikaci budu psát v CoffeeScriptu. Nicméně ne každému se CoffeeScript líbí, takže si bude moci skripty přeložit do JavaScriptu.
  • Aplikace bude obsahovat testy ve frameworku Jasmine, takže budu psát klasicky i unit testy (jak jsem psal, bude to normální aplikace se vším všudy).
  • Pro základní design použiji šablony z Twitter Bootstrap.

Rubriky: Node.js | Napsat komentář

Nastavení stejného testovacího prostředí pro klientský i serverový JavaScript během 5 minut

Publikováno 7.9.2012 | Autor: Ronnie

V článku se dozvíte, jak lze jednoduše nastavit jedno testovací prostředí pro jednotkové testování tak, aby bylo možné spuštět klientský i serverový JavaScript (přes Node.js) najednou. Navíc se testy budou spouštět automaticky při každé změně jednotkového testu.

Používám dva nástroje pro testování. Jednotlivé části jako třídy, metody ap. testuji přes klasické unit testy. Aplikaci z globálního pohledu pak přes AngularJS scenario runner (end-to-end testy). Tento článek se zabývá jednotkovým testováním.

Pro jednotkové testování pod Windows používám jasmine-node, což je testovací framework Jasmine přizpůsobený pro Node.js. Ze všech testovacích frameworků mi vyhovuje nejvíce, navíc snad jako jediný bez nejmenších problémů funguje i pod Windows. Balíček nainstalujete přes příkaz npm install jasmine-node -g.

Jak klientské, tak serverové skripty píšu v CoffeeScriptu, obvykle jednu třídu do jednoho souboru. V obou případě striktně dodržuji vzor dependency injection. Třídy v klientském JavaScriptu nikdy nepracují s ničím jiným než s tím, co dostávají přes parametry metod zvenčí. To platí také pro globální JS objekty jako windows, document ap. Takto jsou třídy zcela nezávislé a velmi snadno se testují.

Abych mohl s třídami klientského i serverového JavaScriptu zacházet stejným způsobem a testovat je přes Node.js, potřebuji je ze souboru vyexportovat. V Node.js k tomu slouží proměnná exports, která v klientském JavaScriptu není, nicméně lze to snadno obejít tím, že vytvořím globální proměnnou exports, který bude odkazovat na objekt window. Takže jako první JS příkaz prohlížeč spustí

var exports = window;

Díky tomu pak zacházím úplně stejně se všemi třídami bez ohledu na to, zda jsou určeny pro klienta nebo pro Node.js. Příklad třídy pro klientský JavaScript může vypadat takto:


# trida je v /public/js/lib/Trida.js překompilovaná z coffeescriptu

class Trida
  metoda: -> 3

exports.Trida = Trida

Třídu takto už můžu snadno testovat i přes Node.js. Vytvořím si v rootu projektu adresář test/, kde budu vytvářet testy. V Jasmine musí být všechny třídy s koncovkou .spec.coffee nebo spec.js, takže si vytvořím testovací třídu Trida.spec.coffee, která bude testovat, zda metoda() vraci hodnotu 3.


Trida = require(process.cwd() + '/public/js/lib/Trida').Trida

describe 'Trida', ()->
  it 'metoda() vraci hodnotu 3’', ->
    trida = new Trida
    expect(trida.metoda()).toEqual 3

Testy pak spustím přes jasmine-node test z rootu projektu.

Tohle je fajn, ale bylo by super, kdyby to bylo celé zatomatizované a já se nemusel o spouštění testů vůbec starat. K tomu je dostupná volba –autotest, takže příkaz trochu pozměníme:

jasmine-node test  --autotest

Kdykoliv uděláte a uložíte změnu v souboru z adresáře /test, testy se automaticky spustí. Pokud používáte NetBeans, můžete si v panelu otevřít konzoli (Window -> Output -> Terminal) a vše spustit tam. V druhé konzoli si pak spustíte node třeba přes balíčky nodeman či supervisor. Tím docílíte toho, že můžete v klidu psát kód a okamžitě vidíte, zda vše funguje.

Rubriky: Node.js | Napsat komentář