Náš tým hledá novou programátorskou posilu! Pokud umíte C#, baví vás dělat webové aplikace a chcete pracovat pro nejlepší IT firmu v Hradci Králové a okolí, neváhejte a pošlete nám životopis. Oficiální inzerát naleznete zde.
Spike aneb ověření, jestli to vůbec půjde
Po instalaci Linuxu jsem potřeboval vyzkoušet, zda fungují klíčové technologie, na které se bude můj projekt spoléhat. Při té příležitosti si také trochu ošahám MonoDevelop (a zjistím jestli je vůbec použitelné). V programátorštině se tomu řiká spike, neboli malý prográmek, který jako tenký hřebík projde všechny vrstvy aplikace a ověří, že navržené řešení není totální pitomost. Po dokončení se takový projekt nemilosrdně smaže, protože při jeho tvorbě nejsou uplatňovány principy trvale udržitelného programování.
Jak jsem přešel na Linux a MonoDevelop
Má trpělivost se smrtící kombinací Vista+Visual Studio+ReSharper byla vyčerpána. Mám pocit, že neustále čekám alespoň na jeden prvek z této trojice. Můj upgrade na Windows7 je přitom minimálně tři měsíce daleko, a navíc si nejsem úplně jistý, že to přinese zásadní zrychlení. Rozhodl jsem se proto vyzkoušet Linux+MonoDevelop, pro začátek na nějakém malém testovacím projektíku.
...a jeden navrch
Kolega mi včera na chvíli půjčil ještě úplně nové HTC HD2. No a musím říct, že je to povedený kousek.
Čtyři smartfouni
Leží mi na stole čtyři smartfouni. Díky tomu, že děláme mobilní verzi našeho produktu, máme příležitost vyzkoušet, jak vypadá web v různých telefonech, a taky si je pěkně ošahat. Máme tu iPhone 3GS, T-Mobile G1, Sony Xperia X1 a BlackBerry 9000.
Co by měl každý programátor vědět
Občas mě zarazí, že i lidi, které považuju za dobré programátory, neznají základy programovacího jazyka, ve kterém píšou 95% kódu. Například nedávno v naší kanceláři proběhla debata, proč si StyleCop stěžuje na to, že jsou v kódu nadbytečné závorky. Šlo o složenou podmínku v příkazu if, kde si dotyčný pomáhal závorkami, protože si nebyl 100% jistý s prioritou operátorů && a ||. Co na to říct?
Podle mého jsou určité základy, které musí každý programátor o svém jazyce vědět. Priorita operátorů podle mně patří mezi ně. Argument, že v jazyce XX nebo YY to bylo jinak, je podle mně zcestný. Programovací jazyky jsou natolik jednoduché, že programátor nemůže mít problém si těch pár věcí zapamatovat. Netvrdím, že musíte z hlavy vědět vše o nějakém obskurním jazyku, který používáte jednou za uherský rok, ale pokud se někdo už několik let živí psaním kódu v C#, musí takové věci znát bez zaváhání.
Co všechno by jste tedy měli vědět o svém hlavním programovacím jazyku?
Tento seznam určitě není kompletní, pokud vás napadne něco dalšího, napište to do komentářů.
Pokud tyto základní věci neovládáte, riskujete dva velké problémy: Budete se pomalu orientovat v kódu ("jakého typu je var a = new[] { 1, 10, 100, 1000 };?"), a při psaní budete používat zbytečné ornamenty (if(((age>60)||(disabled==true))&&(balance>limit))). Druhý problém je o dost horší než první, protože při čtení zpomalujete jen sami sebe. Pokud ale kvůli své neznalosti použijete o 8 závorek navíc, ztěžujete práci ostatním, protože znepřehledňujete kód. Je sice pravda, že ostatní pak nemusí používat svn blame, protože už znají váš styl:-) Být poznat podle stylu kódu ale není nic o co by jste měli stát. A taky budete hodně nadávat na StyleCop:-)))
Pokud neovládáte ani naprosto základní věci, jak chcete přesvědčit ostatní o tom, že jste dobří programátoři?
Podle mého jsou určité základy, které musí každý programátor o svém jazyce vědět. Priorita operátorů podle mně patří mezi ně. Argument, že v jazyce XX nebo YY to bylo jinak, je podle mně zcestný. Programovací jazyky jsou natolik jednoduché, že programátor nemůže mít problém si těch pár věcí zapamatovat. Netvrdím, že musíte z hlavy vědět vše o nějakém obskurním jazyku, který používáte jednou za uherský rok, ale pokud se někdo už několik let živí psaním kódu v C#, musí takové věci znát bez zaváhání.
Co všechno by jste tedy měli vědět o svém hlavním programovacím jazyku?
- Priorita operátorů (!, ++, ||, &&, ?:)
- Jak zapsat hodnotu různých datových typů (0xAF, 123 a 123L, 0.12M a 0.12D)
- Základní konverze na string a zpět (například donedávna jsem považoval za samozřejmost, že každý ví jak konvertovat "FFEEDD" na int, ale byl jsem vyveden z omylu)
- Speciální jazykové konstrukce jako anonymní delegáti a lambda funkce
Tento seznam určitě není kompletní, pokud vás napadne něco dalšího, napište to do komentářů.
Pokud tyto základní věci neovládáte, riskujete dva velké problémy: Budete se pomalu orientovat v kódu ("jakého typu je var a = new[] { 1, 10, 100, 1000 };?"), a při psaní budete používat zbytečné ornamenty (if(((age>60)||(disabled==true))&&(balance>limit))). Druhý problém je o dost horší než první, protože při čtení zpomalujete jen sami sebe. Pokud ale kvůli své neznalosti použijete o 8 závorek navíc, ztěžujete práci ostatním, protože znepřehledňujete kód. Je sice pravda, že ostatní pak nemusí používat svn blame, protože už znají váš styl:-) Být poznat podle stylu kódu ale není nic o co by jste měli stát. A taky budete hodně nadávat na StyleCop:-)))
Pokud neovládáte ani naprosto základní věci, jak chcete přesvědčit ostatní o tom, že jste dobří programátoři?
Co všechno musíte vyřešit při psaní WPF aplikace
WPF je kůl, o tom žádná. Proti Windows Forms je to opravdu obrovský skok kupředu. Ale to ještě neznamená, že při tvorbě aplikace založené na WPF nemůžete dostat osypky a že vás nečekají bezesné noci. V tomto příspěvku se pokusím shrnout hlavní problémy, ke kterým je třeba se postavit čelem, bez nároku na nalezení konečného řešení:
Aby View vědělo kdy se má updatovat, je nutné u všech ViewModel objektů implementovat rozhraní INotifyPropertyChanged. Naštěstí je velmi jednoduché, ale budete muset psát spoustu opakovaného kódu:
Vyhnout se mu můžete buď generováním kostry ViewModelu pomocí DSL jazyka, nebo pomocí AOP (kolegové používají PostSharp), kde stejná property může vypadat takto:
Existuje několik přístupů k lokalizaci WPF aplikace, které se liší způsobem uložení resource stringů, možností výběru lokalizovaných vlastností a možností přepínat jazyk "za běhu", bez nutnosti restartu aplikace. Řešení které doporučuje Microsoft (přes binární XAML, neboli BAML) potřebuje externí nástroj LocBaml.exe, editovat jazykové verze musíte v CSV a při přepnutí jazyka za běhu se nelokalizují již otevřená okna. Které vlastnosti budou lokalizované se dá určit až při lokalizaci, takže překladatel se může rozhodnout, že např. sloupec v tabulce bude mít jinou velikost nebo label se zarovná na jinou stranu. To může být výhoda i problém, záleží na vašich potřebách. Další dva způsoby naleznete v článku Localizing WPF Applications using Locbaml, oba ale neumožňují přepínat jazyk za běhu.
Zajímavé řešení je popsáno v WPF Localization - On-the-fly Language Selection. To už umožňuje skutečné přepnutí jazyka bez nutnosti restartu aplikace. Je založené na vlastním Converteru, který provádí lokalizaci, díky čemuž lze používat poziční parametry v resource stringu ("{0}") a jejich hodnoty dokonce bindovat. Trik umožňující okamžité přepnutí jazyka spočívá v nahrazení lokalizovaných hodnot MultiBinding objektem, kde první vazba je na LanguageContext.Instance.Dictionary, která při změně jazyka posílá událost PropertyChanged. To způsobí znovunačtení všech hodnot. Tomuto řešení bych vytknul pouze způsob uložení resourců (vlastní XML), ale velmi lehce si můžete napsat vlastní LanguageDictionary a číst hodnoty např. z resx souborů.
Při prvním pohledu na WPF se zdá, že validace je vyřešená věc, ale pokud chcete použít vzor MVVM, není to tak jednoduché. Ve ViewModelu tedy implementujeme IDataErrorInfo a projdeme všechny deklarace Binding v XAMLu a přidáme ValidatesOnDataErrors=true.
Jenže kromě business validací je nutné také validovat vstup od uživatele. To jsou opravdu dvě různé věci: Mějme třídu Person s property Age typu int. "Business" validace je, že Age nesmí být záporné a musí být menší než 150. Když je hodnota mimo tento rozsah, vrátíme přes IDataErrorInfo chybovou hlášku. Jenže co když uživatel zadá "qweqweqwr"? Výchozí chování Bindingu je výjimku prostě spolknout. Můžeme nastavit ValidatesOnExceptions na true, ale jednak nemůžeme změnit validační hlášku, a také nechceme žádné výjimky. Výjimky jsou pro výjimečné případy, např. když je vyhlášen výjimečný stav. Spoléhání na výjimky může aplikaci znatelně přibrzdit.
WPF Binding zpracovává vstup přes řetěz validátor - konvertér - property setter. Možným řešením by bylo vkládat vlastní validátory do deklarace Bindingů. To ale odporuje našemu cíli, dostat všechnu logiku do ViewModelu. Navíc až budeme objekt ukládat (uživatel zmáčkne Ctrl+S), nedozvěděli bychom se, že na formuláři jsou nevalidní data. Informaci o validitě si přece chceme přečíst z ViewModelu. Nejen kvůli tomu odpadá i další možnost: generovat validátory podle metadat ViewModelu. Ani to nezkoušejte, nejde to. Jak zjistil Miro, Binding je jen MarkupExtension, který vytvoří BindingExpression, který se teprve stará o update hodnot, jenže většina jeho důležitých vlastností je internal.
Jediným mně známým řešením je proto deklarovat ve ViewModelu property Age jako string a provádět konverzi až tam. Když se konverze povede, zapíšete property do Modelu, kde už je typu int a kde se provede business validace. Je to víc práce ale zase má ViewModel informaci o tom, jestli je formulář validní. Implementace je popsaná v článku Using a ViewModel to Provide Meaningful Validation Error Messages.
Aby to nebylo tak lehké, představte si že chcete z ViewModelu vrátit hlášku "Věk musí být mezi {0} a {1}". Obstarožní interface IDataErrorInfo umožňuje vracet pouze string, takže ve ViewModelu provedeme String.Format a vrátíme už hotový text. Jenže to komplikuje lokalizaci. Kvůli přepnutí jazyka za běhu bychom potřebovali vracet klíč do resourců a pole parametrů, aby lokalizátor mohl aktualizovat hlášku. Ideální by tedy bylo napsat si vlastní interface, lepší a hezčí než IDataErrorInfo (to by věru nebylo těžké), protože do ValidationError objektu můžeme ukládat daleko více informací než jen string. Pomocí Reflectoru kolega Miro zjistil, že Binding při nastavení ValidatesOnDataErrors=true vkládá do pole validátorů objekt DataErrorValidationRule. Kdybychom tedy napsali vlastní ValidationRule, mohli bychom přečíst errory pomocí vlastního interface a vytvořit takový ValidationError objekt, který by byl lokalizátor schopen za běhu překládat. Jenže opět narážíme na to, že property BindingExpression.ItemSource, která obsahuje zdroj data bindingu (ViewModel), je internal! Zbývá nám tedy buď oželit okamžitou lokalizaci validačních hlášek, přinutit všechny BindingExpression objekty provést refresh, nebo si do stringu serializovat template s parametry a v lokalizátoru je deserializovat, vše mi přijde ošklivé.
WPF má sice vestavěnou podporu pro undo/redo v TextBoxu, ale to nám samozřejmě nestačí, potřebujeme undo/redo v celé aplikaci (nebo lépe, v celém editovaném projektu, který tvoří undo scope - projektů můžeme mít otevřených víc naráz). Zde se nabízí klasické řešení pomocí UndoItem objektu a undo a redo stacku, popsané třeba zde. Je ovšem nutné vyřešit otázku jak nalézt undo scope (projekt), když naše ViewModel objekty tvoří košatě rozvětvený strom.
Také musíme implementovat undo transakce. Kvůli tomu, aby bylo uživatelské rozhraní živější, jsme totiž ve všech Binding deklaracích nastavili UpdateSourceTrigger=PropertyChanged. Díky tomu je uživatelův vstup okamžitě validován, ale protože se přes ViewModel posílá každý jednotlivý znak který uživatel zadá do TextBoxu, bylo by undo dost nepoužitelné. Potřebujeme tedy zahájit undo transakci při vstupu do TextBoxu a ukončit ji při jeho opuštění (nebo stisku enter). To nás nejen odsuzuje k handlování událostí nebo vlastnímu TextBoxu, ale má to i jeden háček: Při kliknutí myší do menu nebo na toolbar TextBox neztratí focus. Tím pádem se při Save/Load neukončí undo transakce a nezahájí se nová, na což je potřeba myslet a modelovat root undo scope (projekt) tak, aby ho bylo možné při Load celý zahodit a vytvořit nový (i pak si ale TextBox drží focus a nezahájí novou transakci).
Jak je vidět, komplexitu dobré aplikace není radno podceňovat ani s tak vyspělým frameworkem, jako je WPF. Pokud narazíte na další problémy nebo na jiná řešení, dejte vědět.
- INotifyPropertyChanged
- Validace
- Lokalizace
- Undo/Redo
INotifyPropertyChanged
Aby View vědělo kdy se má updatovat, je nutné u všech ViewModel objektů implementovat rozhraní INotifyPropertyChanged. Naštěstí je velmi jednoduché, ale budete muset psát spoustu opakovaného kódu:
string _name;
public string Name
{
get { return _name; }
set
{
_name = value;
OnPropertyChanged("Name);
}
}
Vyhnout se mu můžete buď generováním kostry ViewModelu pomocí DSL jazyka, nebo pomocí AOP (kolegové používají PostSharp), kde stejná property může vypadat takto:
[Notify]
public string Name { get; set; }
Lokalizace
Existuje několik přístupů k lokalizaci WPF aplikace, které se liší způsobem uložení resource stringů, možností výběru lokalizovaných vlastností a možností přepínat jazyk "za běhu", bez nutnosti restartu aplikace. Řešení které doporučuje Microsoft (přes binární XAML, neboli BAML) potřebuje externí nástroj LocBaml.exe, editovat jazykové verze musíte v CSV a při přepnutí jazyka za běhu se nelokalizují již otevřená okna. Které vlastnosti budou lokalizované se dá určit až při lokalizaci, takže překladatel se může rozhodnout, že např. sloupec v tabulce bude mít jinou velikost nebo label se zarovná na jinou stranu. To může být výhoda i problém, záleží na vašich potřebách. Další dva způsoby naleznete v článku Localizing WPF Applications using Locbaml, oba ale neumožňují přepínat jazyk za běhu.
Zajímavé řešení je popsáno v WPF Localization - On-the-fly Language Selection. To už umožňuje skutečné přepnutí jazyka bez nutnosti restartu aplikace. Je založené na vlastním Converteru, který provádí lokalizaci, díky čemuž lze používat poziční parametry v resource stringu ("{0}") a jejich hodnoty dokonce bindovat. Trik umožňující okamžité přepnutí jazyka spočívá v nahrazení lokalizovaných hodnot MultiBinding objektem, kde první vazba je na LanguageContext.Instance.Dictionary, která při změně jazyka posílá událost PropertyChanged. To způsobí znovunačtení všech hodnot. Tomuto řešení bych vytknul pouze způsob uložení resourců (vlastní XML), ale velmi lehce si můžete napsat vlastní LanguageDictionary a číst hodnoty např. z resx souborů.
Validace
Při prvním pohledu na WPF se zdá, že validace je vyřešená věc, ale pokud chcete použít vzor MVVM, není to tak jednoduché. Ve ViewModelu tedy implementujeme IDataErrorInfo a projdeme všechny deklarace Binding v XAMLu a přidáme ValidatesOnDataErrors=true.
Jenže kromě business validací je nutné také validovat vstup od uživatele. To jsou opravdu dvě různé věci: Mějme třídu Person s property Age typu int. "Business" validace je, že Age nesmí být záporné a musí být menší než 150. Když je hodnota mimo tento rozsah, vrátíme přes IDataErrorInfo chybovou hlášku. Jenže co když uživatel zadá "qweqweqwr"? Výchozí chování Bindingu je výjimku prostě spolknout. Můžeme nastavit ValidatesOnExceptions na true, ale jednak nemůžeme změnit validační hlášku, a také nechceme žádné výjimky. Výjimky jsou pro výjimečné případy, např. když je vyhlášen výjimečný stav. Spoléhání na výjimky může aplikaci znatelně přibrzdit.
WPF Binding zpracovává vstup přes řetěz validátor - konvertér - property setter. Možným řešením by bylo vkládat vlastní validátory do deklarace Bindingů. To ale odporuje našemu cíli, dostat všechnu logiku do ViewModelu. Navíc až budeme objekt ukládat (uživatel zmáčkne Ctrl+S), nedozvěděli bychom se, že na formuláři jsou nevalidní data. Informaci o validitě si přece chceme přečíst z ViewModelu. Nejen kvůli tomu odpadá i další možnost: generovat validátory podle metadat ViewModelu. Ani to nezkoušejte, nejde to. Jak zjistil Miro, Binding je jen MarkupExtension, který vytvoří BindingExpression, který se teprve stará o update hodnot, jenže většina jeho důležitých vlastností je internal.
Jediným mně známým řešením je proto deklarovat ve ViewModelu property Age jako string a provádět konverzi až tam. Když se konverze povede, zapíšete property do Modelu, kde už je typu int a kde se provede business validace. Je to víc práce ale zase má ViewModel informaci o tom, jestli je formulář validní. Implementace je popsaná v článku Using a ViewModel to Provide Meaningful Validation Error Messages.
Aby to nebylo tak lehké, představte si že chcete z ViewModelu vrátit hlášku "Věk musí být mezi {0} a {1}". Obstarožní interface IDataErrorInfo umožňuje vracet pouze string, takže ve ViewModelu provedeme String.Format a vrátíme už hotový text. Jenže to komplikuje lokalizaci. Kvůli přepnutí jazyka za běhu bychom potřebovali vracet klíč do resourců a pole parametrů, aby lokalizátor mohl aktualizovat hlášku. Ideální by tedy bylo napsat si vlastní interface, lepší a hezčí než IDataErrorInfo (to by věru nebylo těžké), protože do ValidationError objektu můžeme ukládat daleko více informací než jen string. Pomocí Reflectoru kolega Miro zjistil, že Binding při nastavení ValidatesOnDataErrors=true vkládá do pole validátorů objekt DataErrorValidationRule. Kdybychom tedy napsali vlastní ValidationRule, mohli bychom přečíst errory pomocí vlastního interface a vytvořit takový ValidationError objekt, který by byl lokalizátor schopen za běhu překládat. Jenže opět narážíme na to, že property BindingExpression.ItemSource, která obsahuje zdroj data bindingu (ViewModel), je internal! Zbývá nám tedy buď oželit okamžitou lokalizaci validačních hlášek, přinutit všechny BindingExpression objekty provést refresh, nebo si do stringu serializovat template s parametry a v lokalizátoru je deserializovat, vše mi přijde ošklivé.
Undo/Redo
WPF má sice vestavěnou podporu pro undo/redo v TextBoxu, ale to nám samozřejmě nestačí, potřebujeme undo/redo v celé aplikaci (nebo lépe, v celém editovaném projektu, který tvoří undo scope - projektů můžeme mít otevřených víc naráz). Zde se nabízí klasické řešení pomocí UndoItem objektu a undo a redo stacku, popsané třeba zde. Je ovšem nutné vyřešit otázku jak nalézt undo scope (projekt), když naše ViewModel objekty tvoří košatě rozvětvený strom.
Také musíme implementovat undo transakce. Kvůli tomu, aby bylo uživatelské rozhraní živější, jsme totiž ve všech Binding deklaracích nastavili UpdateSourceTrigger=PropertyChanged. Díky tomu je uživatelův vstup okamžitě validován, ale protože se přes ViewModel posílá každý jednotlivý znak který uživatel zadá do TextBoxu, bylo by undo dost nepoužitelné. Potřebujeme tedy zahájit undo transakci při vstupu do TextBoxu a ukončit ji při jeho opuštění (nebo stisku enter). To nás nejen odsuzuje k handlování událostí nebo vlastnímu TextBoxu, ale má to i jeden háček: Při kliknutí myší do menu nebo na toolbar TextBox neztratí focus. Tím pádem se při Save/Load neukončí undo transakce a nezahájí se nová, na což je potřeba myslet a modelovat root undo scope (projekt) tak, aby ho bylo možné při Load celý zahodit a vytvořit nový (i pak si ale TextBox drží focus a nezahájí novou transakci).
Závěr
Jak je vidět, komplexitu dobré aplikace není radno podceňovat ani s tak vyspělým frameworkem, jako je WPF. Pokud narazíte na další problémy nebo na jiná řešení, dejte vědět.
Architektura Ginger
Ginger je náš framework pro webové aplikace. Tvoří ho knihovny s infrastrukturním kódem a sada doporučení (nebo spíš přikázání:-))), jak rozdělit aplikaci na vrstvy a které projekty umístit do které vrstvy. Je určen pro webovou vícevrstvou škálovatelnou aplikaci, která ukládá data do databáze.
Trochu teorie kolem DSL
Doufám, že vás v mém posledním postu moc nevystrašilo slovní spojení "Domain-Specific Language". Je to jen další buzzword: zní to sofistikovaně, ale ve skutečnosti to není nic nového. Laskavý čtenář, kterému rostou víc vousy než vlasy, si možná vzpomene na minijazyky v unixu, což není nic jiného než DSL - malý jazyk vymyšlený pro konkrétní účel.
Model Driven Development v praxi
Kolem modelování v software už byla napsána a řečena spousta vznešených slov (třeba zde). Podívejme se proto na jednoduchý způsob, jak ho implementovat v praxi.
O čem bych chtěl psát ale nemám na to čas
Od mého posledního ublognutí uplynulo mnoho LOC. Není to tím že bych neměl o čem psát, ale nějak se mi nedostává času. Tak alespoň ve stručnosti, na čem pracuju a o čem bych si v budoucnu chtěl ublognout:
- Codename Ginger: Aplikační framework pro tvorbu distribuovaných (nejen) webových aplikací. Řeší architektonický základ takové aplikace: rozdělení do vrstev a vrstev (v češtině se dost špatně rozlišuje layer a tier), jazyk pro modelování domény vytvořený pomocí DSL Tools, generování různých artefaktů jako skriptů pro vytvoření databáze, mapovacích souborů, doménových a DTO objektů přímo z modelu pomocí T4. Není to žádná chiméra, máme reálně fungující a solidně protestovanou verzi a vyvíjíme v tom komerční aplikace. Na webové vrstvě používáme ASP.NET MVC, na datové NHibernate a trochu jsme to okořenili Spring.Net (ale jen s citem). Velkou inspirací pro nás je NServiceBus a pak samozřejmě bible enterprise aplikací Patterns of EAA od Martina Fowlera.
- WPF: Celkem dlouho jsem tuto technologii ignoroval, protože jsem někde četl že v ní není DataGrid. Hrozná chyba! Příliš mnoho času jsem strávil ve Windows Forms, takže jsem si nedokázal představit, jak flexibilní může být UI framework. Teď si to vynahrazuju. Jsem nadšen ze stylování, data bindingu a content modelu. Kromě toho, že v tom nejdou kloudně zobrazovat bitmapy, je to naprosté programátorské blaho.
- Scrum: Snažím se v práci prosadit, abychom v příští verzi našeho produktu nasadili tuto metodologii. Máme trochu problém s plánováním, termíny a komunikací, a od Scrumu si slibuju, že budeme mít přesnější představu jak na tom jsme, zpřesníme plánování, díky projektovým tymům usnadníme komunikaci, vývojáři se budou moct lépe soustředit na výsledek a díky tomu také zvedneme kvalitu našeho kódu. Nehledě na to, že nás to bude víc bavit:-) Teorie je na webu dost, ale našel jsem super knížku, která se věnuje praktické realizaci. Je zdarma, tak neváhejte a stahujte, je opravdu dobrá. Doufám že to vyjde a že budu moct časem ublognout jak nám to jde.
Tak to je ve zkratce všechno, mám v hlavě sice daleko víc nápadů, ale den má jen 24 hodin:-)
Jak programovat bez ega
Přestože mnozí věří, že programování je exaktní věda, ve skutečnosti má blíž k literatuře. Program se nedá vypočítat, program se musí napsat. Programátor musí, stejně jako spisovatel, psát jazykem kterému rozumí ostatní programátoři a dodržovat určitá stylistická pravidla. Počítačové jazyky totiž existují kvůli lidem a ne kvůli počítačům, ty by se spokojily s nulami a jedničkami. Větší pozornost je sice nutné věnovat kritickým (napínavým) úsekům, ale pokud autor ztratí ze zřetele soudržnost celku, výsledkem bude škvár, který sice možná bude sdělovat příběh, ale prokousat se jím bude peklo.
Na rozdíl od spisovatelů jsou však programátoři nuceni pracovat v týmech. Mají tak problémy, kteří spisovatelé vůbec neznají. Některé jsou technického rázu a jdou celkem uspokojivě vyřešit, např. jak spojovat kusy napsané různými autory do jednoho celku (VCS). Horší vznikají tím, že programátoři jsou lidi. Lidská interakce je nesmírně složitá a ke strojové přesnosti a neutrálnosti má na hony daleko. Představte si to, kvůli mezilidským vztahům dokonce vzniklo několik vědních oborů (sociologie, psychologie, psychiatrie, politologie, ekonomie atd.)! Manažeři programátorů se navíc často domnívají, že se pohybují ve výhradně technické oblasti, a tak mohou problémy druhého typu v klidu nepovšimnuty bujet a stávat se patologickými. Ale to je jiná kapitola.
Dnes se chci věnovat jedné vlastnosti, kterou mají programátoři se spisovateli společnou. Každý autor, ať už píše cokoliv, se se svým dílkem ztotožňuje. Je to naprosto přirozené: Trávíte s ním spoustu času, stojí vás mnoho úsilí a chcete aby se mu dařilo co nejlépe. Když pak přijde kritika, ať už oprávněná nebo ne, je těžké ji přijmout s chladnou hlavou. U spisovatelů to vede k úsměvným historkám ve společenských časopisech, u programátorů k frustraci a nepřátelství. A protože se programátoři potkávají v práci každý den, je to pro ně daleko horší problém než pro spisovatele. Pak je ale těžké napsat dobrý program.
Jak tedy programovat bez ega? V první řadě musí člověk přijmout fakt, že se může mýlit. Vždy se najde někdo, kdo o daném problému ví víc než vy. Zvlášť když strávíte se svým produktem delší dobu, je těžké najít odstup a snadno pak přehlédnete i očividné chyby. Pravdu naopak mohou mít i lidé, od nichž by to člověk vůbec nečekal. A tak nezbývá než věnovat pozornost každé výtce, ať už pochází z jakéhokoliv zdroje.
A opačně, pokud kritizujeme, snažme se nedotknout se osobnosti autora kódu. Kritizujte kód, ne jeho autora. Snažte se navrhovat, jakým způsobem lze kód vylepšit. Pokud je to možné, opřete se o fakta (standardy, měření, literatura, články na webu, dohodnuté konvence atd.). Destruktivní kritika typu "seš snad úplně blbej" nebo "všechno stojí za hovno" nikam nevede, jen šíří pocity zoufalství. Zkuste odhadnout, kolik toho ten druhý "skousne" a buďte hodní na kolegy, kteří nemají takové sebevědomí. To, že má někdo méně zkušeností nebo znalostí neznamená, že je horší než vy. Navíc za rok může být situace klidně opačná. Pokud tým funguje, jeho členové jsou schopni se navzájem učit a mají ze spolupráce dobrý pocit.
Aby se programátoři nestyděli zeptat se kolegy o radu, musí v týmu panovat přesvědčení, že mýlit se je lidské a že víc hlav víc ví. Každý má občas špatný den a jediné co se s tím dá dělat, je umožnit, aby se na chyby přišlo co nejdříve. Dobrou pomůckou mohou být techniky z extrémního programování, jako párové programování, code review, kolektivní vlastnictví kódu a stand-up meetingy (také známé jako scrum). Mám ale obavu, že prvotní je dobrý výběr lidí; nehledět při náboru pouze na technické znalosti, ale i na to, zda je přijímaný člověk týmový hráč. Pokud máte tým složený ze samých "hyper-senzitivních code-machines", žádné metodologie vám asi nepomůžou.
Já sám osobně mám pocit, že už dokážu obstojně snášet kritiku kódu, který jsem napsal. Kritizovat kód kolegů mně ale stále nejde tak, jak bych si představoval. Je těžké vybrat správná slova, aby druhý pochopil, že ho nechci urazit ani snížit jeho zásluhy. Někdy mě zradí jazyk, někdy se moc rozohním, někdy toho mám prostě dost a někdy zafunguje ponorková nemoc, protože pracuju ve firmě, kde jsou trvalé týmy - roky sedíte v kanceláři se stejnými lidmi. Tímto se proto omlouvám každému, koho jsem kdy mohl urazit a chci aby jste věděli, že kašlu na to kdo je autorem, zajímá mě pouze kód a aby byl dobrý.
Ještě poznámka na závěr: Zajímavá je souvislost s jiným principem efektivního programování: Ukazuje se totiž, že programovat bez ega znamená napsat pouze tolik, kolik situace vyžaduje - ne méně a ne více. Nemá prostě cenu vymýšlet všechny varianty, které by po nás mohl uživatel teoreticky chtít, a potom napsat nějaké úžasně univerzální über-řešení; lepší je napsat program, který řeší pouze aktuální problém, a pokud bude potřeba, bude se průběžně doplňovat a zesložiťovat. Je to staré pravidlo YAGNI (You Ain't Gonna Need It), které jinými slovy říká, že i když jste bůhvíjak dobří programátoři, nesmíte se bát obyčejných jednoduchých řešení - není to ostuda.
Egoless Programming
Ten Commandments of Egoless Programming
Na rozdíl od spisovatelů jsou však programátoři nuceni pracovat v týmech. Mají tak problémy, kteří spisovatelé vůbec neznají. Některé jsou technického rázu a jdou celkem uspokojivě vyřešit, např. jak spojovat kusy napsané různými autory do jednoho celku (VCS). Horší vznikají tím, že programátoři jsou lidi. Lidská interakce je nesmírně složitá a ke strojové přesnosti a neutrálnosti má na hony daleko. Představte si to, kvůli mezilidským vztahům dokonce vzniklo několik vědních oborů (sociologie, psychologie, psychiatrie, politologie, ekonomie atd.)! Manažeři programátorů se navíc často domnívají, že se pohybují ve výhradně technické oblasti, a tak mohou problémy druhého typu v klidu nepovšimnuty bujet a stávat se patologickými. Ale to je jiná kapitola.
Dnes se chci věnovat jedné vlastnosti, kterou mají programátoři se spisovateli společnou. Každý autor, ať už píše cokoliv, se se svým dílkem ztotožňuje. Je to naprosto přirozené: Trávíte s ním spoustu času, stojí vás mnoho úsilí a chcete aby se mu dařilo co nejlépe. Když pak přijde kritika, ať už oprávněná nebo ne, je těžké ji přijmout s chladnou hlavou. U spisovatelů to vede k úsměvným historkám ve společenských časopisech, u programátorů k frustraci a nepřátelství. A protože se programátoři potkávají v práci každý den, je to pro ně daleko horší problém než pro spisovatele. Pak je ale těžké napsat dobrý program.
Jak tedy programovat bez ega? V první řadě musí člověk přijmout fakt, že se může mýlit. Vždy se najde někdo, kdo o daném problému ví víc než vy. Zvlášť když strávíte se svým produktem delší dobu, je těžké najít odstup a snadno pak přehlédnete i očividné chyby. Pravdu naopak mohou mít i lidé, od nichž by to člověk vůbec nečekal. A tak nezbývá než věnovat pozornost každé výtce, ať už pochází z jakéhokoliv zdroje.
A opačně, pokud kritizujeme, snažme se nedotknout se osobnosti autora kódu. Kritizujte kód, ne jeho autora. Snažte se navrhovat, jakým způsobem lze kód vylepšit. Pokud je to možné, opřete se o fakta (standardy, měření, literatura, články na webu, dohodnuté konvence atd.). Destruktivní kritika typu "seš snad úplně blbej" nebo "všechno stojí za hovno" nikam nevede, jen šíří pocity zoufalství. Zkuste odhadnout, kolik toho ten druhý "skousne" a buďte hodní na kolegy, kteří nemají takové sebevědomí. To, že má někdo méně zkušeností nebo znalostí neznamená, že je horší než vy. Navíc za rok může být situace klidně opačná. Pokud tým funguje, jeho členové jsou schopni se navzájem učit a mají ze spolupráce dobrý pocit.
Aby se programátoři nestyděli zeptat se kolegy o radu, musí v týmu panovat přesvědčení, že mýlit se je lidské a že víc hlav víc ví. Každý má občas špatný den a jediné co se s tím dá dělat, je umožnit, aby se na chyby přišlo co nejdříve. Dobrou pomůckou mohou být techniky z extrémního programování, jako párové programování, code review, kolektivní vlastnictví kódu a stand-up meetingy (také známé jako scrum). Mám ale obavu, že prvotní je dobrý výběr lidí; nehledět při náboru pouze na technické znalosti, ale i na to, zda je přijímaný člověk týmový hráč. Pokud máte tým složený ze samých "hyper-senzitivních code-machines", žádné metodologie vám asi nepomůžou.
Já sám osobně mám pocit, že už dokážu obstojně snášet kritiku kódu, který jsem napsal. Kritizovat kód kolegů mně ale stále nejde tak, jak bych si představoval. Je těžké vybrat správná slova, aby druhý pochopil, že ho nechci urazit ani snížit jeho zásluhy. Někdy mě zradí jazyk, někdy se moc rozohním, někdy toho mám prostě dost a někdy zafunguje ponorková nemoc, protože pracuju ve firmě, kde jsou trvalé týmy - roky sedíte v kanceláři se stejnými lidmi. Tímto se proto omlouvám každému, koho jsem kdy mohl urazit a chci aby jste věděli, že kašlu na to kdo je autorem, zajímá mě pouze kód a aby byl dobrý.
Ještě poznámka na závěr: Zajímavá je souvislost s jiným principem efektivního programování: Ukazuje se totiž, že programovat bez ega znamená napsat pouze tolik, kolik situace vyžaduje - ne méně a ne více. Nemá prostě cenu vymýšlet všechny varianty, které by po nás mohl uživatel teoreticky chtít, a potom napsat nějaké úžasně univerzální über-řešení; lepší je napsat program, který řeší pouze aktuální problém, a pokud bude potřeba, bude se průběžně doplňovat a zesložiťovat. Je to staré pravidlo YAGNI (You Ain't Gonna Need It), které jinými slovy říká, že i když jste bůhvíjak dobří programátoři, nesmíte se bát obyčejných jednoduchých řešení - není to ostuda.
Egoless Programming
Ten Commandments of Egoless Programming
Ornament a kód
Ornament je zločin, vytanula mi na mysl slova Adolfa Loose, když jsem brousil starou olouhovanou skříň. Má totiž několik ozdobných vlnek, které bylo potřeba pracně ručně obrušovat každou zvlášť. A pak mě napadlo, že to vlastně platí víc v programování než v architektuře.
Nejdřív mi dovolte stručné vysvětlení úvodního citátu (čtenáři s humanitním vzděláním laskavě prominou):
Moderní architekti prohlásili dům za stroj na bydlení (*1). Architektura podle nich není umění, ale věda o bydlení, která má upravit hmotné prostředí potřebám lidského živočicha. Nenávist k ornamentu je logickým důsledkem tohoto názoru - vždyť k čemu jsou lidem propracované ozdobičky, když vše co potřebují je čerstvý vzduch, dostatek slunce, teplo a bydlení v obytné zóně bez továren? "Less is more" (Mies van der Rohe) se stalo heslem několika generací architektů. Le Corbusier řekl: „Dekorace je smyslné a primitivní povahy, stejně jako barva, a hodí se toliko pro nižší třídy, sedláky a divochy.“
copyright Jeffery Howe
Adolf Loos i Le Corbusier sice zapomněli že lidé v domech nejen bydlí, ale také chodí kolem, přesto však udělali se svým názorem díru do světa. Podařilo se jim přesvědčit ostatní o své pravdě a nadlouho ovlivnili myšlení architektů a urbanistů na celém světě. Důsledky známe i u nás v podobě uniformních panelových sídlišť, které přímo vycházejí z jejich ideálů - i když s jejich provedením by asi Le Corbusier nesouhlasil. Konec dominance funkcionalistické architektury znamenal až nástup postmoderny v šedesátých letech a "less is more" nahradil Robert Venturi heslem "less is bore".
copyright tato grasso
A jak to souvisí s programováním? Každý, kdo někdy četl cizí kód, si hned všimne nezvyklých konstrukcí a způsobu formátování kódu. Někdy zaujme precizní tabulární formátování, někdy tvrdošíjná maďarská notace, jindy zas poznámky ve kterých vede programátor dialog sám se sebou. To vše odvádí pozornost čtenáře od funkce k formě. Nejsou to snad ornamenty?
Zdálo by se že tu ornamenty hájím, protože vnášejí krásu do všednosti, vítané potěšení znavenému duchu. Jenže mezi programováním a architekturou je jeden podstatný rozdíl. Architekt musí počítat s tím, že kolem jeho děl budou chodit i laici, kteří o zločinnosti ornamentu nemají nejmenšího tušení. Architekt by měl prostředí ušít na míru všem, nejen kolegům z branže a odborné kritice. Vhodně zvolený ornament pak může sloužit jako vodítko i (z architektova hlediska) nevzdělanému tupci, který by jinak jeho střízlivý obytný dům mohl považovat za vězení.
Kolem vašeho kódu ale laici chodit nebudou. Váš kód se dostane do ruky úzké skupině lidí s (někdy až příliš) specializovaným výcvikem, kteří budou mít za úkol se v něm zorientovat a provést potřebné změny. Pro ně je jakýkoliv ornament zdržením. Nejčitelnější kód je takový, který se striktně drží stanovených konvencí. Kód by měl vypadat tak, jako kdyby ho napsal jeden programátor během jednoho sezení.
Ornament v kódu je jakékoliv porušení stanovených konvencí. Napíšete-li kus kódu jinak, než je ve vašem týmu obvyklé, nutíte kolegy aby při čtení této části kódu přemýšleli ne o tom, co kód dělá, ale o jeho formátování - proč je zapsán tímto neobvyklým způsobem? Je za tím nějaká myšlenka, která mi uniká? Něco na co chtěl autor upozornit? Bohužel, většinou se jedná jen o neznalost konvencí, okamžitý nápad jak kód napsat "lépe" (v lepším případě), nebo o přesvědčení autora že jeho konvence jsou lepší a ostatní by je měli přijmout.
Jak mají vypadat konvence psaní kódu je sice sporná věc, ale jakmile se na nějakých shodnete, je nutné je dodržovat. Osobně preferuju držet se výchozích nastavení Visual Studia a ReSharperu. Proč pracně přenastavovat něco, co používají tisíce programátorů na celém světě? Tím odpadne mnoho diskusí ohledně formátování závorek a mezer kolem operátorů. Mnoho dalších věcí za vás nástroje nevyřeší (jmenné konvence, pořadí prvků atd.), ale na internetu je spoustu zdrojů a vzorových "code conventions" dokumentů i pro váš programovací jazyk.
Kód odpovídá strukturálním a technickým stránkám budovy. Je to nosný systém, vodotěsné zastřešení, rozvody energie a vody, výtahy. Pokud chcete postavit dobrý dům, je bezpodmínečně nutné udělat tyto základní věci dobře a umožnit údržbářům snadný přístup ke všem důležitým bodům. Na stavbě si nemůžete vymyslet svůj vlastní a zcela nový systém elektrických rozvodů a pojistek, nedělejte to ani v kódu. Na Grand Prix Obce architektů to sice nestačí, ale bez dobrého základu nepostavíte ani kůlnu. Dodržování konvencí zdaleka není všechno, ale usnadní život vašim kolegům (a také vám, až se budete za rok divit proč jste to tenkrát takhle napsali). Nechte si ornamenty do uživatelského rozhraní, ve stylistické úpravě kódu platí "bore is more".
*1 Le Corbusier ([1923] 1952): Towards a New Architecture. London
*2 http://cs.wikipedia.org/wiki/Funkcionalismus
UPDATED: 2008-07-26 Přidány citáty Mies van der Rohe a Roberta Venturiho.
Nejdřív mi dovolte stručné vysvětlení úvodního citátu (čtenáři s humanitním vzděláním laskavě prominou):
Moderní architekti prohlásili dům za stroj na bydlení (*1). Architektura podle nich není umění, ale věda o bydlení, která má upravit hmotné prostředí potřebám lidského živočicha. Nenávist k ornamentu je logickým důsledkem tohoto názoru - vždyť k čemu jsou lidem propracované ozdobičky, když vše co potřebují je čerstvý vzduch, dostatek slunce, teplo a bydlení v obytné zóně bez továren? "Less is more" (Mies van der Rohe) se stalo heslem několika generací architektů. Le Corbusier řekl: „Dekorace je smyslné a primitivní povahy, stejně jako barva, a hodí se toliko pro nižší třídy, sedláky a divochy.“
copyright Jeffery Howe
Adolf Loos i Le Corbusier sice zapomněli že lidé v domech nejen bydlí, ale také chodí kolem, přesto však udělali se svým názorem díru do světa. Podařilo se jim přesvědčit ostatní o své pravdě a nadlouho ovlivnili myšlení architektů a urbanistů na celém světě. Důsledky známe i u nás v podobě uniformních panelových sídlišť, které přímo vycházejí z jejich ideálů - i když s jejich provedením by asi Le Corbusier nesouhlasil. Konec dominance funkcionalistické architektury znamenal až nástup postmoderny v šedesátých letech a "less is more" nahradil Robert Venturi heslem "less is bore".
copyright tato grasso
A jak to souvisí s programováním? Každý, kdo někdy četl cizí kód, si hned všimne nezvyklých konstrukcí a způsobu formátování kódu. Někdy zaujme precizní tabulární formátování, někdy tvrdošíjná maďarská notace, jindy zas poznámky ve kterých vede programátor dialog sám se sebou. To vše odvádí pozornost čtenáře od funkce k formě. Nejsou to snad ornamenty?
Zdálo by se že tu ornamenty hájím, protože vnášejí krásu do všednosti, vítané potěšení znavenému duchu. Jenže mezi programováním a architekturou je jeden podstatný rozdíl. Architekt musí počítat s tím, že kolem jeho děl budou chodit i laici, kteří o zločinnosti ornamentu nemají nejmenšího tušení. Architekt by měl prostředí ušít na míru všem, nejen kolegům z branže a odborné kritice. Vhodně zvolený ornament pak může sloužit jako vodítko i (z architektova hlediska) nevzdělanému tupci, který by jinak jeho střízlivý obytný dům mohl považovat za vězení.
Kolem vašeho kódu ale laici chodit nebudou. Váš kód se dostane do ruky úzké skupině lidí s (někdy až příliš) specializovaným výcvikem, kteří budou mít za úkol se v něm zorientovat a provést potřebné změny. Pro ně je jakýkoliv ornament zdržením. Nejčitelnější kód je takový, který se striktně drží stanovených konvencí. Kód by měl vypadat tak, jako kdyby ho napsal jeden programátor během jednoho sezení.
Ornament v kódu je jakékoliv porušení stanovených konvencí. Napíšete-li kus kódu jinak, než je ve vašem týmu obvyklé, nutíte kolegy aby při čtení této části kódu přemýšleli ne o tom, co kód dělá, ale o jeho formátování - proč je zapsán tímto neobvyklým způsobem? Je za tím nějaká myšlenka, která mi uniká? Něco na co chtěl autor upozornit? Bohužel, většinou se jedná jen o neznalost konvencí, okamžitý nápad jak kód napsat "lépe" (v lepším případě), nebo o přesvědčení autora že jeho konvence jsou lepší a ostatní by je měli přijmout.
Jak mají vypadat konvence psaní kódu je sice sporná věc, ale jakmile se na nějakých shodnete, je nutné je dodržovat. Osobně preferuju držet se výchozích nastavení Visual Studia a ReSharperu. Proč pracně přenastavovat něco, co používají tisíce programátorů na celém světě? Tím odpadne mnoho diskusí ohledně formátování závorek a mezer kolem operátorů. Mnoho dalších věcí za vás nástroje nevyřeší (jmenné konvence, pořadí prvků atd.), ale na internetu je spoustu zdrojů a vzorových "code conventions" dokumentů i pro váš programovací jazyk.
Kód odpovídá strukturálním a technickým stránkám budovy. Je to nosný systém, vodotěsné zastřešení, rozvody energie a vody, výtahy. Pokud chcete postavit dobrý dům, je bezpodmínečně nutné udělat tyto základní věci dobře a umožnit údržbářům snadný přístup ke všem důležitým bodům. Na stavbě si nemůžete vymyslet svůj vlastní a zcela nový systém elektrických rozvodů a pojistek, nedělejte to ani v kódu. Na Grand Prix Obce architektů to sice nestačí, ale bez dobrého základu nepostavíte ani kůlnu. Dodržování konvencí zdaleka není všechno, ale usnadní život vašim kolegům (a také vám, až se budete za rok divit proč jste to tenkrát takhle napsali). Nechte si ornamenty do uživatelského rozhraní, ve stylistické úpravě kódu platí "bore is more".
*1 Le Corbusier ([1923] 1952): Towards a New Architecture. London
*2 http://cs.wikipedia.org/wiki/Funkcionalismus
UPDATED: 2008-07-26 Přidány citáty Mies van der Rohe a Roberta Venturiho.
Přednáška o CruiseControl.Net a MSBuild
Dneska jsem dělal interní přednášku pro kolegy ve firmě o průběžné integraci s pomocí CruiseControl.Net a MSBuild, a o našem build systému postaveném na těchto technologiích. PowerPointovou prezentaci si díky laskavému svolení mého zaměstnavatele můžete stáhnout zde.
Jediné co nám chybí k dokonalému build systému je Big Visible Cruise nebo The Orb. Ale až budu mít trochu času, chtěl bych nějakou takovou hračku pořídit;)
Jediné co nám chybí k dokonalému build systému je Big Visible Cruise nebo The Orb. Ale až budu mít trochu času, chtěl bych nějakou takovou hračku pořídit;)
Jak udělat espresso
Protože mně Nikdo předal štafetu, tady je moje oblíbené video: Jak správně na espresso. Mimochodem, mají tam nádhernou mašinku. Jednou bych chtěl takovou doma:-)
Kafe které tam používají (Ethiopia Sidamo) se dá sehnat i u nás, např. já ho kupuju v Mama Coffee kde ho mají v super kvalitě a za rozumnou cenu.
Kafe které tam používají (Ethiopia Sidamo) se dá sehnat i u nás, např. já ho kupuju v Mama Coffee kde ho mají v super kvalitě a za rozumnou cenu.