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

Proč se mi iOS používá hůř než Android

V září loňského roku jsem si kvůli testování pořídil iPod Touch 4G (v podstatě iPhone 4, jen neumí volat a není to taková cihla) a byl jsem zvědavý, jak se ovládá ikona v oblasti UI / UX, průkopník všech dobře použitelných smartfounů. Snažil jsem se iOS používat asi 14 dní a v tomto zápisku bych chtěl shrnout, co se mi na tom nelíbilo a proč jsem daleko spokojenější s Androidem.

Vím, že tento článek bude bodnutím do vosího hnízda, protože většina majitelů nedá na svůj iPhone dopustit (a platí to samozřejmě i pro další zapálené vlastníkyjiných OS, mě nevyjímaje), ale hlavní motivací bylo právě to – o iOS se mluví v podstatě jen pozitivně a tolik výhrad pohromadě budete jinde hledat jen stěží :) Pokud rádi přemýšlíte o UX, možná v článku najdete pár námětů k zamyšlení nezávisle na tom, jakému mobilnímu systému fandíte. 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.

Snadnější editování souboru “hosts” při zapnutém UAC

Při webovém vývoji se často hodí přesměrovávat doménu služby na localhost nebo jiný vývojový server, např. touto úpravou v souboru hosts:

127.0.0.1 mysite.com

Jediné trochu otravné je, že pokud pracujete na Windows se zapnutým UAC, tak vám tento soubor nepůjde v běžně spuštěném textovém editoru uložit (standardní uživatel nemá právo zápisu do C:\Windows). Pokud jste navíc zvyklí pracovat v nějakém textovém editoru s více záložkami (Notepad++, Sublime Text, PSPad apod.), tak nejhorší možný postup může vypadat následovně:

  1. Zavřít editor se všemi záložkami, případně pořešit ty rozeditované
  2. Otevřít jako Administrátor
  3. Ctrl+O a najít soubor hosts (osobně navíc nerad klasický open dialog používám a radši soubory do aplikace tahám z nějakého file manažeru, což mezi aplikací spuštěnou ve standardním a administrátorském módu nefunguje)
  4. Upravit soubor, zavřít editor
  5. Otevřít editor jako běžný uživatel a obnovit předchozí soubory

Toto je samozřejmě extrém, možná máte pod administrátorským účtem spuštěný Total Commander a editujete z něj apod., ale pokud ne, může se hodit následující tip:

Předně k editaci použijte Notepad, protože, přiznejte si to, na nic jiného se stejně nehodí. A za druhé si někde, třeba na ploše, vytvořte zástupce takto:

  1. Do dialogu pro nového zástupce zadejte C:\Windows\System32\notepad.exe C:\WINDOWS\system32\drivers\etc\hosts
  2. V pokročilých nastaveních zástupce zaškrtněte “Spustit jako administrátor”

Nyní stačí zástupce otevřít, Windows se automaticky zeptají na zvýšení pravomocí a soubor hosts nebo podobný lze snadno upravovat.