WebExpo 2012 – Nepoužívejte Git jako SVN!

Na začátku tohoto týdne zde na DevBlogu Michal Špaček představil témata, která si přihlásil do letošního ročníku konference WebExpo a zároveň vyzval ostatní, aby zveřejnili ty své. Jak ale ukazuje hledání #webexpo #ukazprihlasku, tak se k iniciativě zatím zřejmě nikdo nepřihlásil.

Nechci v tom Michala nechat samotného, a tak jsem také přispěchal se svojí troškou do mlýna. Přijde mi, že se nám tu v poslední době rozmohl takový nešvar – za posledních několik let se stal Git velmi populárním, ale pozoruji, že ne každý si je jistý, jak tuto technologii uchopit. Pracovní název zmíněný v titulku tohoto článku je poněkud bulvární, SVNkem se ve své přednášce zabývat nebudu, budu povídat čistě jen o Gitu.

Moje přihláška není zdaleka tak zábavná, jako ta Michalova, ale doufám, že se mi v ní podařilo dobře zachytit mojí motivaci a připravované téma. Záleželo mi na tom dokonce natolik, že jsem přihlášku odeslal 2 dny (!) před deadline.


Čím se nyní zabývám?

Pracuji v Medio Interactive jako senior vývojář. Starám se především o kvalitu vývoje – jak z pohledu dodržování správných programátorských postupů, tak i určitého pracovního workflow. Dále se zabývám analýzami projektů, tvorbou wireframes a vedením projektů. V rámci Medio Akademie vedu školení Gitu a pokročilého vývoje a testování aplikací. Studuji magisterské studium na ČVUT FEL OI.

Čeho si z toho, co jsem dosud dosáhl, nejvíc vážím?

V Mediu jsem prakticky od vzniku firmy a už od začátku jsem začal prosazovat, abychom dělali věci “správně”, tak, aby se nám to z dlouhodobého hlediska vyplatilo. Myslím, že se mi to povedlo, protože nyní je u nás radost vyvíjet. Neřešíme problémy s programovacím jazykem jako takovým, ale můžeme se soustředit čistě na řešení projektu. Projekty, na kterých pracujeme, jsou relativně velké, ale díky našim postupům a zázemí není složité je udržovat.

Čeho bych chtěl dosáhnout?

Když jsem začínal, dělal jsem klasicky vše okolo webů – programování, kódování, “grafika” a spol. Poté jsem se začal specializovat čistě na programování, ale nyní se od něj zase trochu vzdaluji. Snažím se mít přehled a být otevřený novým technologiím a možnostem. Zároveň je ale posuzuji z kritického hlediska praktičnosti. Přehled se snažím mít obecně dost široký na úkor hluboké znalosti jednotlivých záležitostí. Jako každý samozřejmě do některých věcí “vidím” více a do některých méně.

Na co se na Webexpo těším?

Jako každý rok se na Webexpo těším především z pohledu networkingu, je to skvělá příležitost pro setkání s kamarády a “kolegy”, se kterými se člověk přes rok běžně nevidí. Letos se těším ještě více než jindy, protože jsem se bohužel loni zúčastnit nemohl kvůli zdravotním problémům, letos si to hodlám plně vynahradit!

Kvalitní přednášky pak už beru jako samozřejmost, slouží mi především k rozšíření obzorů a jako podnět, jaké zajímavé věci bych mohl dále zkoumat. Vítám také přednášky zahraničních speakerů, protože není tolik příležitostí si tyto lidi u nás poslechnout. Ještě zajímavější je pak možnost si s těmito lidmi osobně promluvit.


O čem to bude?

Chtěl bych promluvit o workflow vývoje projektů pro firmy, kde používají (nebo chtějí používat) Git. Spousta firem začala používat Git místo SVN nebo CVS, nové firmy sahají po Gitu (nebo Mercurialu) skoro automaticky, ale většinou nejsou úplně schopné využít všech jeho možností. Git díky svojí flexibilitě nikomu žádné konkrétní workflow nenutí, což je obrovská výhoda, ale je potřeba si nějaká pravidla stanovit samostatně. Během přednášky bych rád představil několik možných přístupů a srovnal jejich dopady na vývoj projektu. Představím jednak workflow, které jsme vymysleli cca před rokem v Mediu a od té doby prakticky beze změn velmi úspěšně používáme, tak některé jeho varianty, které mohou sedět lépe dalším firmám. Mezi tyto varianty určitě patří i Git-flow, které mohou někteří znát.

Co z toho návštěvníci získají?

Přehled o možnostech Gitu a různých přístupech k jeho využívání v rámci různých typů firem. Na začátku probereme určitě i best-practices pro práci s Gitem, protože to s workflow a jeho snadným udržováním velmi souvisí.

Ukážeme si tedy klasické problémy, které vznikají v různých fázích vývoje, a jak na ně vhodně reagovat. Tzn. jednak, jak kód integrovat a koordinovat práci v týmu, tak i části, které ovlivňují deployment.

Pro koho to je?

Pro návštěvníky z malých či středních firem, kde se řeší, jakým způsobem má spolupracovat více (2+) lidí na jednom projektu. Na toto téma se mě v poslední době ptá čím dál tím více lidí. Při přípravě přednášky budu vycházet z těchto otázek od konkrétních lidí a projektů – jsou si dost často velmi podobné.

Přednáška bude zajímavá jak pro vývojáře, jejichž denním chlebem by používání verzovarcího systému mělo být, tak i pro další členy týmu jako jsou kodéři a grafici. Pro vedoucí projektů může být přednáška určitě také zajímavá, protože odhalí možnosti Gitu, které napomohou řešení nebo v ideálnějším případě předcházení krizovým situacím.


Doufám, že vás toto téma alespoň trochu zaujalo, pokud ano, budu rád za jakýkoliv feedback. Podoba výsledné přednášky zdaleka není stanovená, takže vaše komentáře mi mohou pomoci ještě rozšířit spektrum problémů, které budu při přípravě prezentace uvažovat (nebo mi naopak dovolí koncentrovat se na několik skutečně nejčastějších případů).

WebExpo 2012 Call for Papers

Networ/king?Necelou minutu před deadline jsem odeslal přihlášku svých dvou příspěvků na WebExpo 2012. Potvrzující e-mail, který přišel zpět má čas 23:59:53 a samotného by mě zajímalo, kolik lidí přihlášku odeslalo po mě. Díky patří organizátorům WebExpa i Jeanne Trojan, za to, že mě zcela nezištně dokopali k tomu, abych aspoň jedno téma přihlásil. (Mimochodem, počet zlevněných vstupenek na WebExpo se blíží k nule, takže pokud doma nemáte miliony pod podlahou, tak neváhejte!)

Jaká témata jsem vybral pro tento rok? A jakým způsobem jsem je přihlásil? A co o mě ještě nevíte? Klid, klid, všechno vám to hezky povím. Přihláška řečníka na WebExpo obsahovala několik otázek na tělo řečníka a pak několik otázek na tělo příspěvku. Pro úplnost a jako odkaz budoucím generacím uvedu všechny své odpovědi. Třeba někdo z mých čtenářů vlastně ani neví, čím se zabývám. A vy ostatní mi snad prominete trochu nezvykle odlehčené téma. Continue reading

FPD aneb Full Path Disclosure

FPD je jedna z přibližně 17576 třípísmenných zkratek používaných na Internetu a jedna z mála, kde písmeno F neznamená, hmm, třeba friend. Význam zkratky, o kterém bych vám rád povyprávěl je však důležitý pro bezpečnost webových aplikací. FPD totiž v oblasti webové bezpečnosti znamená Full Path Disclosure, do češtiny přeloženo například jako odhalení, nebo raději lépe prozrazení úplné cesty. Cestou je myšlena cesta k souboru, k právě spuštěnému skriptu, ne cesta domů z vašeho oblíbeného baru.
Full Path Disclosure na rapidog.com
Pokud něco podobného uvidíte na vlastním webu, pak váš web neodolá útoku Full Path Disclosure a plnou cestu vyzradí. A to by rozhodně neměl. Už vidím, jak se vaše dlaň blíží k vašemu obličeji a jak si říkáte, že cestu ke svým souborům přece znáte a jak nechápavě kroutíte hlavou. Zobrazená informace je totiž důležitá nejen pro vás, ale i pro zlé hochy, kteří chtějí na váš web nějakým způsobem zaútočit Continue reading

Markdown a jeho využití při vývoji

V projektech bývá dobrým zvykem mít nějaké “README” nebo obecně informační soubory, a ty se pořád ještě často ukládají jako *.txt. Výhodou je, že takový soubor se otevře a zedituje kdekoliv, na druhou stranu je škoda používat soubory bez formátování, když se formátovaný text čte o tolik líp. Proto jsem viděl “README” soubory v RTF (fuj), v HTML (daleko lepší) nebo jiných formátech (radši pomlčet), ale pokud jste v poslední době navštívili nějaký projekt na GitHubu, mohli jste vidět něco takového:

github-markdown

Díky GitHubu (ač ten sám podporuje formátů víc) i několika dalším velkým webům (např. Stack Overflow) se zdá, že se de facto standardem stává Markdown. Pokud jste ještě nikdy Markdown neviděli, jakkoliv je to nepravděpodobné, vypadá takto:

Welcome to the psake project.
=============================

psake is a build automation tool written in PowerShell.
It avoids the angle-bracket tax associated with executable XML
by leveraging the PowerShell syntax in your build scripts...

## How to get started:

**Step 1:** Download and extract the project

...

Jedná se tedy pouze o drobně naformátovaný textový soubor, který má tu výhodu, že při zachování určitých pravidel ho lze převést na hezky naformátovaný, dobře čitelný výstup.

Osobně nemám Markdown příliš v lásce, některé věci v syntaxi chybí, jiné by mohly být elegantnější a třeba odsazování bloku kódu čtyřmi mezerami mi vyloženě vadí, přesto se zdá, že tento formát “vyhrál”. Podporují ho velké weby, existují pro něj editační nástroje, převaděče v celkem libovolném jazyce apod. Ačkoliv se mi tedy třeba syntaxe Texy! líbí stokrát víc, Markdown je dnes, zdá se, nejpraktičtější volbou.

Co se nástrojů týče, Markdown je tak jednoduchý, že se dá v pohodě psát ručně, přesto bych na pár zajímavých pomocníků rád upozornil.

markdownpad

Předně doporučuji MarkdownPad – jedná se o malou Windows aplikaci, kde vlevo píšete Markdown a vpravo se rovnou zobrazuje výsledek. Fungují tam všechny obvyklé klávesové zkratky (Ctrl+I, Ctrl+B apod.), výsledek se dá snadno vyexportovat do HTML souboru a předně je možno s MarkdownPadem asociovat přípony *.md, *.markdown apod., což značně usnadní editování lokálních Markdown souborů.

vs-markdown-plugin

Podobná věc existuje i jako plugin do Visual Studia, která je navíc zajímavá tím, že zvýrazňuje strukturu už na úrovni zdrojového souboru (nadpisy tak stále obsahují formátovací znaky, ale jsou vyrenderovány větším písmem, nebo třeba odkazy jsou zvýrazněny jinou barvou apod.).

Editory existují i na webu, např. Online Markdown Editor nebo prostě začněte psát text do nějaké textarey, která Markdown podporuje, např. na Stack Overflow. Koneckonců, i tento blog v komentářích Markdown podporuje…

Zkrátka pokud děláte softwarový vývoj, může se Markdown stát sice malým, ale milým společníkem.

Proč PowerShell

Pokud vyvíjíte na Windows a skripty stále píšete jako BAT / CMD soubory, hodně si dlužíte. Sám jsem takovým dlužníkem dlouho byl, ale jelikož to na současném projektu myslíme s automatizací vážně a nějakou skriptovací technologii jsem se stejně chtěl naučit, PowerShell pomalu poznávám a je to poměrně příjemná zkušenost. Pokud jste se zatím pro přechod neodhodlali, třeba vás trochu tímto článkem nahlodám.

Vše, co budu popisovat, popisuji pohledem začátečníka. Myslím, že mám docela dobrou představu o tom, jak PowerShell funguje, ale pokud budu někde technicky ne zcela přesný, tak mi to prosím odpusťte, případně mě vy zkušenější v komentářích opravte.

Proč PowerShell a ne X, Y nebo Z

PowerShell není zdaleka jedinou volbou pro skriptování na Windows. Velmi obecně bych řekl, že se ke skriptování dá použít celkem cokoliv, co je aspoň trochu dynamické, takže validními možnostmi jsou jazyky typu PHP (skrze PHP CLI), Python nebo Ruby, a zajímavou možností je i JavaScript + Node.js (dost jsem to zvažoval; no nevypadal bych pak víc cool? :) ).

PowerShell má ale podle mého názoru jednu zásadní výhodu: jedná se o “oficiální” Windows technologii. Tím teď nemyslím jen to, že je předinstalován jak na klientském, tak serverovém operačním systému, ale např. všechno na Windows 8 Serveru by mělo fungovat bez GUI a správa aplikací bude probíhat přes PowerShell. Řada produktů od Microsoftu tak již funguje, např. klikací administrace Exchange Serveru je nadstavbou nad PowerShellem, cmdlety (příkazy) existují i pro IIS, SQL Server a tak dále. I vývojářské věci se čím dál častěji spoléhají na PowerShell, například NuGet nebo migrace Entity Frameworku.

Pokud tedy ve svém deployment skriptu potřebujete aktualizovat databázi, vytvořit novou webovou stránku, případně ji aktualizovat, nastavit něco v IIS a podobně, je PowerShell přirozenou volbou. Plus samozřejmě umí běžné věci jako procházení adresářů, hledání obsahu, třídění, má slušný dynamický jazyk atd.

PowerShell je hezký

Nebudu zastírat, že jsem člověk, který zrovna dvakrát příkazovou řádku nemiluje. Pokud k něčemu existuje GUI, téměř automaticky jdu do něj, ale když už je příkazová řádka nezbytností, dokážu ocenit její eleganci. Takže zatímco např. v Gitu / Bashi jsem poměrně ztracený a utíkám do TortoiseGitu vždy, když je to jen trochu možné, PowerShell se mi kupodivu líbí. Zde jsou věci, které mě jako začátečníka zaujaly nejvíc:

  • PowerShell pracuje s objekty. Když uděláte dir, výstupem je sice nějaký výpis na obrazovku, ale to je jakoby druhořadé – především dostáváte sadu objektů, které přes pipu můžete předat dalšímu příkazu, ten je může nějak transformovat a předat dál jako další sadu objektů, vyexportovat do CSV, udělat nad nimi introspekci (reflexi) atd. atd. Jednotlivé cmdlety si tak mezi sebou dokáží předávat hodně obecné množiny dat a celé to dohromady funguje až trochu magicky (sortování, projekce, import, export atd. celkem nad čímkoliv, fakt je to hezky navržené).
  • Pokud znáte .NET, získá pro vás PowerShell úplně novou dimenzi. Zavolat lze libovolnou metodu z libovolné assembly, takže např. místo dir můžete zavolat nějakou metodu na třídě DirectoryInfo, a výstup je přitom pořád jen nějaká PowerShell množina, se kterou lze standardními prostředky pracovat dál. I vestavěné datové typu jsou .NET typy, takže třeba na řetězci můžete udělat vše, co lze v .NETu se Stringem. Tohle je naprosto boží.
  • Shell má dobré doplňování kódu. Doplňuje nejen názvy cmdletů (příkazů), ale i jejich parametrů. Protože je toto systémová věc, můžou nad PowerShellem vzniknout inteligentní editory, ve kterých funguje Ctrl+mezerník apod. (doporučuji např. PowerGUI).
  • Všechno je dobře zdokumentované, a pro dokumentaci se používá standardizovaný formát, takže i případné knihovny třetích stran mívají dobrou dokumentaci. Společně s předchozím bodem to vede k tomu, že PowerShell má dobrou “discoverability”, tj. nemusíte tak často na Google, zkušený PowerShellista většinu věcí zjistí z helpu nebo z vestavěné reflexe (gm, Get-Member).
  • Celé prostředí je konzistentní. Cmdlety jsou pojmenované podle konvence Verb-Noun, např. Get-ChildItem, takže pokud zhruba tušíte, co chcete udělat, zadáte sloveso a mačkáte Tab (současně, pokud už příkazy znáte, pro většinu věcí existují aliasy, takže např. Get-ChildItem lze zapsat jako dir, ls nebo gci – vybere si každý). Další krásnou ukázkou konzistence jsou takzvaní PowerShell poskytovatelé – pokud jednou umíte vylistovat obsah adresáře pomocí dir, tak umíte vylistovat i seznam proměnných prostředí (dir env:), registrů (dir HKCU:), dostupných funkcí (dir function:) atd. – všechno to jsou jen virtuální “disky”, na kterých můžete dělat běžné operace jako dir, cd, del apod. Tento koncept se mi moc líbí.

Problematické části PowerShellu

Nečekali jste ode mě, že bych byl nekritický, že? Takže, tady je pár věcí, které myslím, že od PowerShellu můžou trochu odrazovat:

  • Spouštění je problematické. Bohužel, napsat PowerShell skript pro někoho cizího znamená, že ten někdo bude mít víc práce než poklepat na *.bat, možná si skript ani v extrémním případě nespustí (pokud není na PC administrátor a skripty jsou zakázané). Pro použití na našem projektu toto není problém, protože v PowerShellu píšeme interní skripty, ale určitý zádrhel to je.
  • Když jsem někdy potřeboval rychle sesmolit nějaký BAT skript, většinou jsem řešení našel na Googlu a byl jsem rychle hotový. S PowerShellem jsem brzy poznal, že bez znalosti základních konceptů jsem dost ztracený – často jsem nevěděl, co nějaká vygooglená řádka kódu dělá a jak je možné, že vůbec funguje. Naučení se konceptů a získání určité základní praxe s PowerShellem pár dní trvalo, ale zase to vnímám jako velmi dobrou investici. V blízké době blognu seznam zdrojů, které mi s učením pomohly.
  • Jak je znalost .NETu výhodou, tak je jeho neznalost určitou nevýhodou. Základní i docela pokročilejší věci sice uděláte s vestavěnými příkazy, ze kterých .NET nijak nečouhá, ale pro využití skutečného potenciálu může znalost .NETu trochu chybět, ač ne moc.

Jiné větší problémy ale zatím nevidím.

Celkově PowerShell považuji za velmi důstojnou a vydařenou skriptovací technologii pro Windows. Mrkněte na ni.

Pit of Success a spouštění skriptů v PowerShellu

Pokud bych si měl vybrat jeden jediný princip návrhu prakticky čehokoliv (uživatelského rozhraní, programátorského API atd.), kterým bych doporučil se řídit, byl by to dost možná The Pit of Success. Kupodivu, podle Googlu se zdá, že tento princip není pod tímto jménem moc známý – každá blbost má dneska stránku na Wikipedii, ale toto ne, a dotaz “pit of success ux” dokonce nevrací žádný relevantní dotaz (UXáři, vy tento pojem nepoužíváte?). Můžete si tak počíst hlavně na dvou starších blog postech od Brada Abramse a Jeffa Atwooda, ale v zásadě je velmi jednoduchý.

Co je tedy onen Pit of Success neboli “jáma úspěchu”? Zhruba toto:

pit-of-success

Místo abyste se museli snažit o dosažení úspěchu, to něco (uživatelské rozhraní, API, golfová jamka) je navrženo tak, abyste do úspěchu “spadli” skoro i proti své vůli. V praxi to znamená, že nad úkoly nemusíte moc přemýšlet, prostě uděláte první, co vás napadne, a ono to většinou bude správně.

Princip je to velmi jednoduchý, přesto pořád narážím na software, jehož autoři evidentně na Pit of Success nemysleli nebo pro ně minimálně nebyl prioritou. Jedním takovým příkladem je PowerShell, respektive způsob, jakým se v něm spouštějí skripty.

Jakožto začátečník jsem si otevřel tutoriál na webu Microsoftu, který se v odkazovaném dílu věnuje spouštění skriptů. Už trochu zarážející je, že pro tak základní věc musí existovat samostatný článek v jinak velmi letmé sérii tutoriálů, ale budiž. Abyste stránku nemuseli číst, vytáhnu z ní občas drobné, ale v souhrnu důležité informace:

  • Na výchozí instalaci PowerShellu / Windows nejdou skripty (soubory s příponou *.ps1) spustit vůbec.
  • Abyste si spustili svůj první skript, musíte nastavit ExecutionPolicy. Buďto slepě na nějakou uvedenou hodnotu, nebo si můžete počíst v tématu nápovědy About_Signing.
  • Skript nejde spustit poklepáním v průzkumníku jako třeba BAT soubory. Poklepání na PowerShell skript otevře Notepad nebo podobný editor.
  • Ani když jste v konzoli PowerShellu ve správném adresáři, napsání "MyScript.ps1" nepovede k jeho spuštění.
  • Musíte zadat .\MyScript.ps1, ale bacha, tečka není aktuální adresář, spustí vyhledávání ve všech adresářích, které máte v systémové proměnné PATH. Vypadá to, že spustit skript z aktuálního adresáře nejde jinak, než zapsáním jeho celé, absolutní cesty (C:\...).
  • Pokud cesta ke skriptu obsahuje mezeru, musíte ji uzavřít do uvozovek. Současně ale v tomto případě musíte před cestu napsat speciální znak &, jinak spuštění opět nezafunguje.
  • Pokud spouštíte skript mimo konzoli PowerShellu pomocí powershell.exe c:\scripts\test.ps1, můžete přidat parametr -noexit, aby zůstalo okno otevřené. Ale pozor, tento parametr musí být hned za voláním powershell.exe, jinak bude ignorováno.
  • Pokud chcete PowerShell skripty spouštět třeba po přihlášení do Windows, musíte si vytvořit VBScript soubor a teprve z něj zavolat powershell.exe atd.

Příkazová řádka sice není můj svět, ale pokud si pamatuji, v žádném jiném shellu, ani na Windows, ani při letmém kontaktu s Linuxem, jsem nezažil, aby se o spouštění skriptů napsalo tolik textu nebo že by kolem toho existovalo tolik podrobností. Jinými slovy, PowerShell mi na první pohled připadá jako skriptovací technologie, kde se autoři vážně snažili, aby bylo spouštění skriptů co nejtěžší.

Zcela nepochybně pro každý z bodů existuje nějaký racionální důvod (tak se koneckonců software v Microsoftu dělá) a řadu těch důvodů si dokážu domyslet (bezpečnost apod.), ale i tak mám pocit, že někdo při návrhu spouštění skriptů v PowerShellu zanedbal důležitý pohled koncového uživatele. Pokud 99% lidí udělá to, že po spuštění PowerShellu jde na Google, najde rychle něco o ExecutionPolicy a nastaví ji na Unrestricted, tak je něco špatně.

Nechci, aby článek vypadal jako nějaká debata nad detaily implementace PowerShellu, nejsem k tomu povolaný a ani to není pointou článku. PowerShell se mi ve skutečnosti moc líbí a v mnoha věcech ho považuji za nejpokročilejší shell současnosti, jen je potřeba sžít se s jeho přístupem ke spouštění skriptů, a věci, které používám nejraději, žádnou takovou sžívací fázi nepotřebují. Navíc, a to už není prkotina, pokud se něco elementárního dělá u libovolného software nesnadno, může to odradit od jeho používání, a v případě PowerShellu mám pocit, že k tomu dochází – většina OSS projektů používá init.bat nebo build.bat namísto init|build.ps1. Možná je to proto, že BAT spustí každý, zatímco spuštění PowerShell skriptu je, řekněme, netriviální.

Proto, když něco dělám, vždycky se snažím “jámu úspěchu” vybagrovat tak velkou, jak jen to jde.

Mass Assignment v PHP

Počátkem března se Rails komunitou prohnal hurikán jménem @homakov. Škod naštěstí nenapáchal mnoho, jenom se lehce otřel o GitHub a odnesl střechu a plot. Mohl si vzít cokoliv, ale asi by to neunesl (a to asi ani psychicky).

O co přesně šlo? V seznamu návrhových vzorů, které Ruby on Rails implementují najdeme i Active Record, s nímž nám Rails ulehčují práci pomocí přístupu, který se volá Mass Assignment – hromadné přiřazení. Díky standardnímu nastavení Rails bylo možné nastavit jakýkoliv atribut, ne jenom ty povolené – whitelistované. A toho právě Egor Homakov využil. Nechci zde opakovat detaily, ty jsou dobře rozebrány v článku o hacku GitHubu na Zdrojáku, ale přijde mi, že článek trochu nešťastně naznačuje, že nic podobného by se v PHP stát nemohlo. Jasně, že mohlo, úplně v pohodě, zkusím naznačit jak. Continue reading

NIH v praxi – syntax highlighter pro WordPress

Když jsem nedávno psal o syndromu Not Invented Here, netušil jsem, že tak brzo pocítím “zářný” příklad na vlastní kůži. Potřeboval jsem pro tento blog sehnat syntax highlighter, na který jsem měl skutečně velmi základní požadavky:

  1. V bloku kódu obarvit klíčová slova
  2. Nějak rozumně spolupracovat s Windows Live Writerem

Nic dalšího jsem nepotřeboval. K počítači jsem sedal v jedenáct večer s tím, že do půl hodiny mám hotovo a jdu spát. Používám přece WordPress, na kterém běží tuna vývojářských blogů a syntax highlighting je dávno vyřešená věc.

I zadal jsem do Googlu první dotaz, co mě napadl, a dostal se na stránku Posting Source Code na webu wordpress.com (služba pohánějící miliony blogů). Perfektní, říkal jsem si, kód půjde zadat pomocí syntaxe [sourcecode language="xyz"], existuje pro to plugin do Live Writeru, a když se jedná o “oficiální” řešení na wordpress.com, určitě s tím nebude žádný problém.

Nainstaloval jsem tedy plugin SyntaxHighlighter Evolved, který je odkazován z článku, a celý blog se mi rozes..ypal. Místo zvýrazněné syntaxe se zobrazovaly nesmyslné HTML značky, útržek kódu obsahující otevírací PHP značku zadaný přes Live Writer se do databáze uložil tak divně, že po dalším načtení se různé kusy kódu ztratily, atd.

Bylo půl dvanácté a já začínal tušit, že noc teprve začíná.

Následovalo zběsilé hledání chyb, při kterém se ukázalo, že si SyntaxHighlighter Evolved nerozumí s pluginem pro podporu Markdownu v komentářích, že plugin pro Live Writer obsahuje svou samostatnou chybu, která speciální HTML znaky pošle špatně zakódované a ty se po roundtripu do databáze ztratí atd. A že i když se to všechno jakž takž rozchodí, tak používaná JavaScriptová knihovna (SyntaxHighlighter od Alexe Gorbatcheva) má pro mé potřeby dost nepoužitelný výstup (chci jen obarvit klíčová slova, ne definovat background všem řádkům, přidat ke kódu toolbar, čísla řádků a kde co).

Byla jedna.

V tuto chvíli byl čas rezignovat na oficiální plugin a kouknout se po alternativách. Nejdřív jsem zkusil lovit mezi desítkami pluginů pro zvýrazňování syntaxe v oficiálním repozitáři na wordpress.org, ale to bylo dost zoufalé.

wordpress-syntax-highlighting-plugins

Nastal tedy čas si zanadávat, trochu se uklidnit a podívat se na problém znovu.

Základem bylo zvolit, jakou knihovnou vlastně ve výsledku kód obarvovat. Měl jsem jasno, že to má dělat JavaScript (serverové obarvování má IMO víc nevýhod než výhod a Gisty mají zase nevýhodu, že se nezobrazí v GReaderu), a jako nejméně intruzivní a relativně nejvíc rozšířená mi přišla knihovna Prettify od Googlu (mimochodem, krásné porovnání JS knihoven je zde). Používá ji Stack Overflow, na tomto webu plugin pro komentáře a navíc má výhodu, že není potřeba určovat jazyk kódu – Prettify nějak umí obarvit cokoliv, ačkoliv přesně nechápu, jak to vlastně funguje. Kvůli jednoduchosti syntaxe (v podstatě se jen elementu

 přidá class="prettyprint") je zásadně jednodušší (a funkční) i plugin pro Live Writer a rovněž přidání do stránky je snadné.

Byly dvě ráno.

Cítil jsem se jako vítěz, měl jsem jasno v JavaScriptové knihovně a pro její přidání jsem na wordpress.org našel několik pětihvězdičkových pluginů, takže no problem. Ale asi jsem nepoučitelný. Pluginy jsem vyzkoušel čtyři a dva z nich generovaly PHP warningy, jeden kolem kódu přidával nějaký nesmyslný rámeček a poslední nefungoval vůbec. Zkoušet další jsem už neměl nervy.

Bylo půl třetí a měl jsem toho dost.

Otevřel jsem editor, v druhém okně dokumentaci Prettify a WordPressu a za dvacet minut jsem měl funkční plugin pro zvýrazňování syntaxe.

Zastřelte mě, pokud ho někdy budu chtít vystavit na wordpress.org.

Tisíc pohledů na TDD

TDD (Test-Driven Development) je hype. Každý opravdový vývojář dneska dělá “TDD”, a kdo ho nedělá, je začátečník nebo naopak patří do starého železa, to je snad nad slunce jasné. Jenže co je vlastně TDD? Je to něco přesně definovaného nebo se tímto pojmem vývojáři ohání jen proto, že je dneska cool?

hype

Texy.js

K zamyšlení v tomto článku mě přivedl projekt Texy.js, reimplementace Texy! v JavaScriptu od Aleše Roubíčka, který podle Alešových slov TDD používá. Byl jsem nadšený, když jsem se o projektu dozvěděl, protože jednak stojím o Texy.js samotné, a pak jsem taky chtěl konečně vidět, jak bude TDD vypadat na projektu, který je pro testování jak stvořený, a od vývojáře, který TDD dlouhodobě praktikuje a propaguje. Kód je navíc (zatím) jednoduchý a relativně přímočarý, takže se jedná o skutečně skvělý studijní materiál.

Jak jsem začal koukat na zdrojové kódy Texy.js, něco mě zarazilo (kromě neznámých obratů v JavaScriptu, detailů zpracování textu atd.). Takhle nějak vypadala naše GTalk konverzace s Alešem pár minut poté:

BB: Ty Texy.js neděláš pomocí TDD, viď?
AR: Samozřejmě že dělám, proč myslíš, že ne?

Proč jsem myslel, že ne? Protože v commitu 4dbb4e4 se objevilo jakési UTF-8 kódování a dekódování a tato změna přitom nebyla diktována žádným testem. Podle Alešových slov byl tento commit přidán omylem a měl jít ruku v ruce s commitem následujícím (7b496fc), který si údajně kódování UTF-8 vynucuje, ale zaprvé si to nemyslím (test lze uspokojit jednodušším způsobem než zavedením UTF-8 knihovny) a zadruhé mám spíš pocit, že ten pozdější commit 7b496fc jen fixuje test, který byl předtím napsaný špatně a po změně produkčního kódu padal (stringy v JavaScriptu jsou UTF-16 a test na zalamovací pomlčku ji z nějakého důvodu zapisoval v UTF-8). Až později Aleš na svém blogu vysvětlil, jaká byla motivace k některým obratům, a tam jsem si právě uvědomil, že každý pod TDD možná vidíme něco jiného.

Můj pohled na TDD

Například můj pohled je ten, že odlišujícím faktorem TDD a “prostého” test-first development je právě ten, že testy by v TDD měly posouvat produkční kód kupředu, měly by být jeho řídícím faktorem, hnací silou. Testy v TDD by IMO měly dávat tvar produkčnímu kódu a proto se taky TDD někdy (podle mého názoru správně) označuje za technika agilního designu.

Možná si ale různí lidé pod TDD představují různé věci nebo je to také o tom, že hodně záleží na konkrétním projektu. Pokud se vrátíme k Texy.js, tak veřejné API této knihovny je tak primitivní (jedna metoda process() se stringem na vstupu a jiným na výstupu), že tady o nějakém přínosu TDD na úrovni designu těžko může být řeč. (Naopak bychom mohli diskutovat o tom, co pro API znamená, že se kvůli testování musela zpřístupnit jinak interní metoda normalize(), ale zaprvé je to IMO OK a zadruhé by to bylo na jinou debatu.)

Jindy se zase paušálně říká, že TDD vede k “čistšímu kódu” (správnější je říkat k “čistému návrhu”, ale zůstaňme na okamžik u tohoto zjednodušení). Znovu na příkladu Texy.js, podle mého názoru jsou v kódu jak věci hezké, např. použití funkcí map / reduce pro aplikování filtrů, tak věci trochu kontroverzní, např. interní kódování do UTF-8 nebo použití regulárních výrazů na zpracování neregulárního jazyka. Souvisí nějak tyto věci s tím, jestli se kód psal stylem test-first, test-after, TDD, BDD nebo jakýmkoliv jiným? Podle mě ne.

Pragmatický přístup k vývoji

Jestli mě léta strávená s Flexem něco naučila, tak to, že se nikdy nic nedá hodnotit paušálně, a zatímco např. testy nepokrytý kód v .NETu znamená v agilních kruzích téměř smrtelný hřích, GUI ve Flexu se automatizovanými testy nepokrývá téměř nikdy a obecně se to považuje za racionálnější přístup, než se o to pokoušet. K řadě věcí tak přistupuji s otevřeným hledím a snažím se koukat, jaký konkrétní přístup by se hodil pro daný konkrétní problém.

Jak bych k vývoji Texy.js přistoupoval já?

  1. Rozhodně bych kód intenzivně testoval, jako Aleš. Dokážu si představit jen málo typů projektů, kde by se testy hodily víc než u konvertovátka textu nebo obecně čehokoliv.
  2. Patrně bych tomu neříkal TDD a dost možná bych se TDD ani nesnažil přiblížit.
  3. Ohledně interní implementace bych před samotným psaním produkčního kódu strávil dost času výzkumem. Zpracování gramatik je matematický problém, nepochybně důkladně prozkoumaný a “vyřešený”. Doufat, že přijdu s implementací blížící se té “optimální”, mi připadá nerealistické. Tak trochu NIH, mohu-li si popíchnout :)

Jak jsem už mnohokrát naznačil, nejde mi o nějakou polemiku s Texy.js. Aleš může mít různé motivace k psaní Texy.js způsobem, jakým to dělá, a lidi s jiným pohledem na TDD navíc můžou stoprocentně souhlasit. Je to ale IMO krásný příklad toho, že TDD pro jednoho nemusí vždy znamenat TDD pro druhého.

Nutné P.S. na závěr: Pohledů na TDD samozřejmě není tisíc, ale zní to líp než osm :)

Not Invented Here

Cestou do práce jsem tuhle poslouchal díl Hanselminutes, který se věnuje provařeným “anti-patternům” jako Copy Paste Programming, Iceberg Class, Copy Folder Versioning atd. – v podstatě je celý díl komentářem k tomuto motivačnímu kalendáři.

Jedním z probíraných antipatternů je i Reinventing the Wheel, který úzce souvisí se syndromem NIH, Not Invented Here. Ten je zhruba o tom, že některé týmy a priori odmítají cizí software s tím, že “nebyl vynalezen zde” a přinesl by víc potíží než užitku. Takové uvažování je zvlášť v agilní komunitě považováno za špatné, za “anti-pattern” a nálepka NIH má náležitě pejorativní nádech. Ale víte co? Čím jsem starší, tím víc NIH chápu.

Software se totiž dělí do dvou skupin – ten z první skupiny funguje dobře a ten z druhé ne. Hranice mezi těmito skupinami je bohužel tenká a často subjektivní a problémem cizího software je, že málokdy lze dopředu odhadnout, do které vlastně patří. Už se mi tak mnohokrát stalo, že jsem si řekl “nebudu programovat nic vlastního, prostě použiju nějaké stávající řešení”, a pak následovalo zhruba tohle:

  • Vygooglil jsem si několik řešení pro můj problém
  • Zkontroloval licence
  • Strávil čas hledáním ohlasů na jednotlivá řešení, abych vyloučil outsidery nebo naopak objevil “hvězdy”
  • Zkontroloval další metriky, které mě obvykle zajímají, např. jaká je komunita okolo projektu, jestli je aktivně vyvíjen, jestli se fixují bugy apod.

Nakonec jsem nějaké řešení vybral, nasadil a… a byl zklamán, protože software aplikován na můj konkrétní případ s mými konkrétními požadavky měl nějaký problém. Takže znovu – zkusit dalšího kandidáta, strávit s ním další čas, zjistit, jestli vyhovuje atd. Někdy navíc ani není možné během krátké zkušební doby zjistit, jestli software 100% vyhovuje, což pak může vést ke scénáři, který bych nikomu nepřál, ale který jste patrně všichni někdy zažili. Ke scénáři zvanému noční můra.

Noční můra je, když se ze začátku cizí software tváří schopně, a až časem, velmi postupně, zjišťujete, že řešení vlastně moc nevyhovuje. Ne, nevyhovuje je slabé slovo, po čase zjistíte, že původní řešení z duše nenávidíte. Stalo se mi to u několika zásadních věcí, jako je třeba zvolené CMS pro web, zvolený mikro-framework pro zákaznickou aplikaci, jeden interní systém apod. Ve všech těchto případech nastalo řekněme po roce používání nepříjemné dilema – trpět dál s cizím systémem, zkoušet ho upravit, pokud to vůbec jde, nebo s relativně vysokými náklady migrovat někam jinam? Ale kam? Na “NIH” nebo “IH” řešení?

Čím víc podobných zkušeností jsem udělal, tím víc NIH chápu. Ano, jsou věci, kde NIH považuji za jasný syndrom, např. bych v .NETu rozhodně nezvažoval psát vlastní unit testing framework, ale ani u těchto věcí nikdy neříkej nikdy – třeba Jakub Vrána teď napsal “yet another” minifikátor JavaScriptu, a přesto k tomu měl dobré důvody:

  • JSMin měl problematickou licenci
  • Dal si tu práci, vyzkoušel několik stávajících řešení, a řada z nich kupodivu obsahovala chyby (viz článek a komentáře)

Ostatně, zkušenost s cizím SW popisuje Jakub takto:

Přiznám se, že cizí knihovny nepoužívám moc ochotně. Nejdřív strávím spoustu času hledáním té, která by mi vyhovovala. Pak často zjistím, že mi stejně něčím nevyhovuje. Když to opravím, pošlu změnu autorovi a on ji přijme, tak čekám na vydání nové verze. Když vyjde, tak musím otestovat, jestli se neporouchalo něco jiného. Cizí knihovny taky často mají závislosti (např. na Javě), které já vyžadovat nechci.

Takže asi tak. Osobně se stále snažím hledat existující software, který by můj problém řešil, a často je to pragmatické – přeci jen třeba naprogramovat celé CMS je tak velká práce, že je výhodnější se občas zavztekat nad WordPressem. Přesto jsem během posledních let svůj vztah k NIH přehodnotil – docela tento syndrom chápu. Software is hard.