Jenže agregátory by neměly obsah jen triviálně seskupovat, ale také o něm přemýšlet. Kromě náznaků u Facebooku jsem neviděl žádný co by to uměl dobře. A to včetně agregátoru co provozuji. Předkládám tedy na pohled Weblogy.cz sice kritický, ale snad také konstruktivní.

Problém Weblogů před redesignem jsem neviděl ve vzhledu (i když ten nový je mi subjektivně příjemnější), ale v práci s obsahem, jeho rozlišování a třídění. Weblogům chybí editorský pohled člověka nebo alespoň chytrý algoritmus, který by takovou práci zčásti zastal. Změnil bych tři konkrétní věci:

1) Detailnější rozpoznávání kvality

Ano, je sice pravda, že systém Weblogů u každého zdroje umožňuje určit zda je kvalitní a jeho posty se pak odlišují. Jenže zvýraznit zajímavé posty v záplavě jiných tak jak jdou v čase za sebou není dobrý nápad. Když jsme si jistí, že obsah je kvalitní, neměl by za pár hodin zmizet z čelních pozic vytlačený nekvalitními zprávami, jež mají jedinou výhodu — byly vydány později.

A pak — je skutečně každý článek „kvalitního zdroje” kvalitní? Nemyslím, že by všechny články Vzhůru dolů kvalitní byly a naopak PHP triky do Weblogů neposlaly jediný výborný článek. Rozlišovací lupu je myslím potřeba zaměřit na konkrétní články, nikoliv celé zdroje.

2) Rozlišování typů článků

Typy obsahu, jež Weblogy.cz zobrazují bez odlišení vedle sebe, staví uživatele před těžké rozhodování. Třeba: Zdroják zde rozumně publikuje jen články, zatímco Intervalu na Weblogy.cz vychází každá přežvýkaná zprávička ze zahraničního webu. Vsadím se, že neexistuje čtenář, který by se uměl a chtěl rozhodovat, který článek Intervalu bude „zprávička” a který pak „článek”. Zřejmě pak bude tenhle zdroj ignorovat.

3) Třídění obsahu

Weblogy navštěvuje sice určitá konkrétní skupina lidí (web-geekové), ale ta se dále dělí do menších skupin, jejichž témata se překrývají jen částečně. Webové podnikatele, marketéry, programátory, grafiky … všechny zajímají trochu jiná témata.

Na zmiňovaném agregátoru jsem zkoušel automatické třídění obsahu do ručně vytvářených kategorií, které šlo dále kombinovat tak, že čtenář může odebírat jen obsah, který ho skutečně zajímá. Pokud by ji autoři Weblogů zvládli lépe, je to další zajímavá funkce, sice náročná ale dávající existenci agregátoru smysl.

Jsem přesvědčen, že vytvořit a spravovat dobrý agregátor lze, ale ne v nadšeneckých podmínkách nebo jako „bokovku”. Podobně jako u jiných „chytrých” webových služeb, potřebujete spoustu energie, dobrý vývojářský tým nebo editora s vizí a množstvím času. Weblogy.cz i po kosmetické změně tváře bohužel zůstávají na začátku cesty.

1. „IE6 je tak málo rozšířený, že jej mohu již nyní směle ignorovat.”
2. „Ladění webů pro IE6 vyžaduje nadlidské množství nepříjemné práce.”

Obávám se totiž, že jsou často produktem lidské liknavosti, která našla obhajobu ve většinově přijímaném názoru. Takže brousím modré „é”, sundávám brýle a vyrážím na pomoc drahému staříkovi…

V článku uvažujeme v intencích HTML/CSS vrstvy prezentačních webů, v případě aplikací a Javascriptu bude situace jiná.

Můžete ho nenávidět, ale ne ignorovat

Budeme všichni jistě rádi, až si budeme moci dovolit uživatele s IE6 zařadit do nepočetné skupiny „zoufalci používající starý šrot” vedle uživatelů IE5 a Netscape 4.7. Ta situace u velké části webů ještě ale nenastala a dlouho nenastane. Víme jak je šestka zažraná v korporátních systémech a jen tušíme jakou ty mají setrvačnost. (Dožití systémových administrátorů? :-)) Pokud neděláte geekovské weby nebo prostě nemáte štěstí, budete ještě dlouho muset uvažovat s podílem lidí vybavených IE6 na návštěvnosti vašich stránek nad hranicí 5 %.

Průběžné ladění v IE6 — nebolí to

Přátelé, třeba se budete divit, ale i dnes mám skoro u každého webu v sadě testovaných prohlížečů otevřený Microsoft Internet Explorer verze 6. Proč to dělám v případě prohlížeče, který považován za softwarovou verzi ďábla?

Hlavně proto, že to je daleko příjemnější a časově úspornější, než rozšířená metoda „odladím všechny moderní prohlížeče a pak na web mrknu v IE6”. Ta musí zákonitě končit nahromaděním nepříjemné práce, frustrací kodéra, vymýšlením speciálních zjednodušených verzí pro IE6 a následně často nespokojeností uživatelů.

Daleko snazší je uvažovat už při návrhu technického řešení konkrétních prvků stránky v intencích současného stavu rozšíření prohlížečů mezi lidmi. Většina zásadních problémů s IE6 je dobře známých a zdokumentovaných — hasLayout, nepodpora fixního pozicování, PNG alfaprůhlednosti nebo některých CSS selektorů. Naše znalosti promítneme do hledání řešení, které bude fungovat i v IE6.

Pozor, metoda průběžného ladění také v IE6 nespočívá v tom, že moderním prohlížečům nedopřejete jejich CSS3 vlastnosti a že budeme ignorovat technický pokrok. Cílem je prostě mít v kapse základní skupinu ověřených postupů, které fungují ve všech moderních prohlížečích a v IE6. A u toho konkrétního prvku stránky, kde si budeme jistí, že nás IE6 už trochu moc brzdí, zvážíme zda jej prostě neignorovat.

Je dokonalý kód smyslem práce kodéra?

Ano, váš kód nebude nejčistší. V HTML se občas vyskytnou nějaké ty mazací divy atd. Ale položte si otázku, jaký je smysl toho být kodérem: čistota kódu nebo zlepšení uživatelského prožitku technickými prostředky pro co nejširší skupinu lidí?

Patřím k těm co v čistotě kódu ten pravý smysl vývojařiny nevidí. A patřím k těm, kteří se nebojí udělat práci navíc, i když ji ocení jen pár lidí. Začíná to poctivě vyplněnými alt parametry, končí hojným využíváním mikroformátů. Proto například v IE6 obvykle nahradím všechny poloprůhledné PNGéčka pomocí GIFů, protože web pak vypadá výrazně lépe než když to neudělám a načítá se rychleji než když bych nasadil některý z javascriptových fixů pro PNG alfaprůhlednost. I na středně velkém webu je to celkově operace na pár minut, zlepšený uživatelský prožitek lidí s IE6 za to stojí.

Mimochodem, druhý důvod, proč mívám IE6 větší část pracovního dne puštěný a nemám přitom potřebu namazat si každé ráno klávesnici česnekem je tento: S vědomím výjimek lze říct, že co se správně zobrazuje v IE6, bude fungovat v IE7. Proto je šestka spolu s IE8, Firefoxem, Chrome v základní čtyřce prohlížečů, ve kterých šablony ladím průběžně. IE7 pouštím jen jednou za čas — třeba pro závěrečný test šablony.

Vstřícnost vůči IE6 musí být časově obhajitelná

Kolega Kahi při nedávné mailové diskuzi zmiňoval, že se snaží netrávit s laděním pro IE6 větší podíl času na celkovém rozpočtu než je jeho aktuální podíl na návštěvnosti v daném segmentu. Nemůžu než souhlasit a tvrdím, že postupem průběžného ladění je časový podíl rozhodně ještě menší.

Máme tedy stále používaný prohlížeč, kterým web v průměru navštěvuje v průměru dvacetina lidí. Máme také způsob jakým můžeme lidem s tímhle prohlížečem s odpovídajícím vypětím sil nabídnout srovnatelný uživatelský prožitek jako těm ostatním. Co nám tedy brání tu práci udělat? Image vývojářského drsňáka? ;-)

Předně — je chybou oba porovnávat jako aplikace pro stejné použití. Tumblr se skvěle hodí pro lidi, kteří chějí publikovat tumblelog, tedy něco mezi blogem a mikroblogem s velkým množstvím multimediálního obsahu. Posterous je čistě blogovací systém, tedy konkurence spíše pro Wordpress nebo dnes už přežitý Blogger.

Posterous je proto nabitý funkcemi, Tumblr jich má myslím trošku méně, ale zato (nebo proto) má výrazně lépe zvládnuté rozhraní. Je to krásně vidět na dashboardu, kde se v případě Posterous dostavuje známý pocit pohledu na řídící panel Temelína, ale „nástěnce” Tumbleru hned rozumíte.

Tumblr tak na první pohled bude srozumitelnější — promiňte to spojení — „obyčejným lidem”. Geeky, kteří se chtějí chlubit počtem zatržítek zatržených během dne, osloví Posterous. :-)

Tumblr mě proto připadá daleko lepší pro ty, co s publikování začínají nebo od blogovací aplikace očekávají hlavně jednoduchost. Tady se opravdu nebudete muset moc učit.

Pokud vám Tumblr začne být malý, nebudete mít problém k Posterous přejít. Ten totiž umí obsah vašeho tumblelogu kompletně importovat a to včetně šablon, pokud je máte vyrobené na míru.

Několik vzájemně nesouvisejících poznámek…

Dirk zmiňuje také nevýhody resetovacích CSS: Meyerova a YUI. Dá se souhlasit s tím, že reset, který mění nativní způsob zobrazování prvků (neboldový nebo seznamy zbavené odrážek) nám trošku přidává práci.

Ostatně, nic takového mě neťuklo, což bude tím, že všechny CSS frameworky, které jsem dosud použil, tyto vyresetované vlastnosti vracely zase zpět. Taky zde slyšíte absurdno a humor?

Neměl jsem tušení, že jeho YAML využívají takhle velké německé weby — Stern, ZDF … To je slušný úlovek! Ale při proklikání webu jeho frameworku vám to dojde — je zde uplatněna zásada, že nikoliv zdrojový kód, ale dokumentace a informační ekosystém dělí technologie na úspěšné a neúspěšné.

Závěrečný výkřik k prezentaci zní: Forma! Vážně — dělal ji člověk, který ví, že forma a obsah se nesmí rozcházet a z každé slídy je patrná (až se chce klišovitě říct německá) preciznost a hlavně úcta a empatie vůči publiku a jeho tužbě nikoliv jen vzdělávací ale také emocionální. Tuzemští prezentující, zamyslete se nad tím. .-)

Jednoduchost technologie špatný kód neospravedlňuje

„Ach, kdyby jen specifikace CSS obsahovala proměnné!” a další geekovské povzdechy si můžeme odpustit, protože a) právě teď nic takového CSS neobsahuje a b) není jisté, že by to CSS bordelářům skutečně pomohlo. Myslím si, že jednoduchost je velmi dobrá vlastnost jakékoliv technologie, CSS nevyjímaje.

Hezky to dříve popsal Honza Sládek, takže pro argumenty zajděte k němu. My můžeme pokračovat směrem k návrhu řešení palčivé otázky.

Jak z jednotlivých opakujících se pravidel extrahovat informaci o typech písem, barvách či layoutu obecně používaném na webu tak, aby stylopisy splňovaly alespoň základní parametr udržovatelnosti — že jim bude rozumět sám autor, když se ke své práci za tři měsíce vrátí?

Jelikož se snažím se upřednostňovat jednoduchá řešení a vyhýbat se vrstvení technologií, z našich úvah vyřazuji CSS preprocesory jako LESS, čímž ale neříkám, že pro ně nevidím uplatnění.

Poněkud tupý, přesně takový jaký jej chceme — manuál stylopisu

Po mnoha pokusech se mi nakonec obrovsky osvědčila úplně nejtupější varianta — manuál v externím souboru. V adresáři se stylopisy u každého svého projektu najdu soubor README.txt, ve kterém všechny potřebné informace jsou. Kdykoliv pak na webu vytvářím nový prvek, podívám se sem a zjistím jaké by měl mít vlastnosti.

Obsah manuálu

Pojďme se podívat co takový manuál stylopisu může obsahovat.

• Kontakty na autora
• Seznam souborů a jejich obsah
• Písma a jejich varianty 
• Index z-indexů
• Barvy a jejich varianty
• Rozměry opakujících se prvků laoyutu
  

Než plýtvat detaily, odkážu vás na tři své manuály stylopisu, které jsou součástí projektů vyrobených v Shortcat studiu.

BioOKO Pražské jaro Hipposdesign.com

Jedna část manuálu tedy nahrazuje velmi málo se vyskytující manuály designu a také vizuální identity. Další část supluje nedokonalost CSS jako technologie — například pro varianty barev  budeme moci brzy začít široce využívat RGBa. Index z-indexů a varianty písem zase sjednocují na jedno místo informace, které bývají rozptýlené po různých pravidlech ve stylopisu.

Manuál stylopisu v žádném případě nenahradí dobře organizovaný, komentovaný a srozumitelně psaný CSS kód. Přidává vrstvu abstrakce, kterou kaskádové styly neumožňují.

Milí čtenáři, více než jindy zde ocením váš feedback a vlastní zkušenosti se správou CSS.

Jednoduchost technologie špatný kód neospravedlňuje

„Ach, kdyby jen specifikace CSS obsahovala proměnné!” a další geekovské povzdechy si můžeme odpustit, protože a) právě teď nic takového CSS neobsahuje a b) není jisté, že by to CSS bordelářům skutečně pomohlo. Myslím si, že jednoduchost je velmi dobrá vlastnost jakékoliv technologie, CSS nevyjímaje.

Hezky to dříve popsal Honza Sládek, takže pro argumenty zajděte k němu. My můžeme pokračovat směrem k návrhu řešení palčivé otázky.

Jak z jednotlivých opakujících se pravidel extrahovat informaci o typech písem, barvách či layoutu obecně používaném na webu tak, aby stylopisy splňovaly alespoň základní parametr udržovatelnosti — že jim bude rozumět sám autor, když se ke své práci za tři měsíce vrátí?

Jelikož se snažím se upřednostňovat jednoduchá řešení a vyhýbat se vrstvení technologií, z našich úvah vyřazuji CSS preprocesory jako LESS, čímž ale neříkám, že pro ně nevidím uplatnění.

Poněkud tupý, přesně takový jaký jej chceme — manuál stylopisu

Po mnoha pokusech se mi nakonec obrovsky osvědčila úplně nejtupější varianta — manuál v externím souboru. V adresáři se stylopisy u každého svého projektu najdu soubor README.txt, ve kterém všechny potřebné informace jsou. Kdykoliv pak na webu vytvářím nový prvek, podívám se sem a zjistím jaké by měl mít vlastnosti.

Obsah manuálu

Pojďme se podívat co takový manuál stylopisu může obsahovat.

• Kontakty na autora
• Seznam souborů a jejich obsah
• Písma a jejich varianty 
• Index z-indexů
• Barvy a jejich varianty
• Rozměry opakujících se prvků laoyutu
  

Než plýtvat detaily, odkážu vás na tři své manuály stylopisu, které jsou součástí projektů vyrobených v Shortcat studiu.

BioOKO Pražské jaro Hipposdesign.com

Jedna část manuálu tedy nahrazuje velmi málo se vyskytující manuály designu a také vizuální identity. Další část supluje nedokonalost CSS jako technologie — například pro varianty barev  budeme moci brzy začít široce využívat RGBa. Index z-indexů a varianty písem zase sjednocují na jedno místo informace, které bývají rozptýlené po různých pravidlech ve stylopisu.

Manuál stylopisu v žádném případě nenahradí dobře organizovaný, komentovaný a srozumitelně psaný CSS kód. Přidává vrstvu abstrakce, kterou kaskádové styly neumožňují.

Milí čtenáři, více než jindy zde ocením váš feedback a vlastní zkušenosti se správou CSS.

sIFR díky komplikovanému nastavování a velmi špatné rychlosti při načítání stránky postupně nahrazujeme jeho současnějšími sourozenci. Oba používají k náhradě canvas, respektive VML v Internet Explorerech a vypadají velmi podobně.

Který z nich zvolit? Na základě dostupných informací se rozhoduje jen těžce. Rozhodl jsem se pro vlastní hloubkový průzkum.

Ovládnout Typeface.js je snadné jako složit skříň z IKEA. Ale kdo by to chtěl dělat bez návodu?

Do dneška čistě intuitivně na všechny projekty používám Cufón. Dnes, při cíleném podrobném prozkoumávání Typeface.js jsem dospěl k tomu, že intuice byla v tomto případě jen synonymem pro dokumentaci.

Typeface.js můžete mít jako vývojáři na první pohled jen těžko rádi. Neexistuje pro něj prakticky žádný podrobnější manuál (na rozdíl od velmi slušně popsaného Cufónu.) Jako vývojářské rozhraní Typeface.js používá Launchpad, což je něco jako Github, kde sídlí Cufón. Ovšem Github z roku 2005.

Tady se znovu ukazuje, že chcete-li uspět jako geek, nestačí vám k tomu technické znalosti. Autoři Typeface.js svým přístupem k dokumentaci a absencí efektivního dialogu s komunitou svůj software dobrovolně degradovali do pozice hříčky, kterou berou vážně jen nadšenci do webové typografie.

Už v tuhle chvíli bychom mohli říct co je a co není dobrý software. Vyhrál by Cufón. Dejme ale Typeface.js ještě šanci.

Typeface.js: Pozor na licenční podmínky

Na webu Typeface.js si písmo vygenerujete poměrně snadno. Původně uměl jen TrueType formát, ten je teď doplněný o OpenType, který je výrazně rozšířenější u písmolijen. Formulář generátoru písma pro Cufón je naproti tomu složitější a zpočátku z něj budete asi docela na větvi.

Jedna z věcí, kterou Cufón ale umožňuje nastavit, je velmi užitečná — jde o omezení funkčnosti písma na určitou doménu. Náhradou písem pomocí sIFR nebo Cufón jste totiž obvykle na hraně licenčních podmínek většiny písmolijen i když vlastní licenci koupenou máte. Omezení na konkrétní doménu písmo alespoň trochu chrání před hromadným zneužíváním a s menšími písmolijnami se na něm určitě domluvíte.

Pokud písmo nahrazujete pomocí Typeface.js, buďte na pozoru. Omezení na určitou doménu nastavit nelze a tak budete pravděpodobně za hranicí toho, co bude vaše písmolijna ochotná překousnout. Raději se ptejte, protože někteří informovanější typografové užití písma pomocí Typeface.js dokonce vyloženě zakazují.

Implementace, rychlost — remíza

Výhodou Typeface.js je o fous snadnější implementace — k prvku, který chcete nahradit prostě přidáte class="typeface-js" a vše důležité si pak nastavíte ve vlastním stylopisu včetně řezu písma. CSS pravidlo pak může vypadat moc hezky i s dopřednou kompatibilitou: font-family: 'Můj řez písma', Arial, sans-serif.

Rychlost obou je v běžných případech srovnatelná. Javascript Typeface je pomalejší, když nahrazujete větší množství nadpisů. Testoval jsem 100 nadpisů na stránce, kde si vzal výkon Firefoxu na dobu o pár vteřin delší než Cufón a z pohledu uživatele byl jistý „zásek” znát.

Je ještě pár drobných rozdílů, které ovšem zrovna na vašem projektu mohou být zásadní:

Jelikož mám od Cufónu daleko dostupnější informace, budu dále standardně používat jej. Typeface.js ovšem nezahazuju a v případech kdy potřeba označit text myší bude zásadní a zároveň nebudu narážet na problém s licencováním, sáhnu po něm.

Důležité je, že oba dobře přebírají CSS vlastnosti nahrazovaných písem a jsou tedy vzájemně poměrně snadno nahraditelné. Nemusíte se tedy bát, že vás případný přechod na jinou technologii bude nějak zvlášť otravovat jako to mohlo být v případě sIFRu.

Kterou technologii používáte vy a jaký pro to máte důvod? Rád uslyším váš názor v komentářích nebo na Twitteru.

Cituji z článku Roberta Nymana o objektovém CSS:

As you might be aware of, using good semantics is very important to me, and when it comes to both elements being used as well as the naming of CSS classes, I believe it should contain a meaning for what it will contain. OOCSS contains class names like .leftCol, .rightCol, .body, .h1, .h2 etc. And to me, and what I believe is to be in line with the notion of the semantic web, is that one of the fundamentals with CSS class names is to not use class names which describes the actual presentation/layout, but rather what it will contain.

…

But, I suggested using other names that would have more meaning and be easy to understand at the same time, like .main-heading, .complementary etc. The reply I got was that she had tried it, but “It was too hard for people to remember it”. And that I’m mot just buying. Sure, .rightCol might be a tad easier to remember, but just going the easiest route time doesn’t always make it right.

Všimněme si, že autoři se při argumentaci k používání obsahově popisných názvů tříd zaštiťují správností a odkazem na sématických web. Ale co je správné, pro koho a v jaké situaci, že?

Myšlenka sémantického webu — jako světa kde stejný typ informací je stejným způsobem označen — je samozřejmě ve velkém množství situací užitečná. Musí ale usnadňovat orientaci v kódu za účelem pochopení obsahu nejen strojům, ale především lidem.

Nicolle Sullivan, autorka OOCSS, se rozhodla, že názvy tříd v jejím CSS frameworku budou blíže vizuálnímu vnímání (říká hezky „vizuální sémantika”) než klasicky vnímané sémantice obsahové. Tedy .leftCol raději než .complementary.

Být autorem CSS frameworku — tedy technologie jejíž použití vnímám nikoliv univerzálně, ale velmi specificky — rozhodnu se stejně.

Argumentem mi bude právě čitelnost a zapamatovatelnost. Vždyť jak jinak bych chtěl svůj framework rozšířit mezi lidi! Jak jinak bych chtěl, aby jej bez manuálu v knižním vydání a vyfintěných PDF-taháků na populárních webdesignérských serverech používal také někdo jiný než autor sám?

V HTML/CSS kódu psaném na míru obsahu dávám vždy přednost pojmenování tříd takovému, aby co nejvíce odpovídaly významu obsahu, ale v konkrétních případech je lepší dát přednost popisu vizuální prezentace.

Nedělejme ze sémantiky univerzálně platné náboženství. Žádné takové neexistuje ani ve webdesignu.

Krásně se sice nabízí čerstvá modla webových typografů, @font-face, ale zdá se, že pro tisk vlastních fontů má tahle technologie má nejlepší léta ještě před sebou.

Udělal jsem dneska komplexnejší test na OpenType.info demostránce. Vše na Windows XP:

• Firefox 3.5.5 — vlastní fonty tisknout nelze a asi ještě chvíli nepůjde (viz Martinův tweet) namísto fontu definovaného ve @font-face tiskne systémový
• Opera 10.01 — tiskne stejně hezky jako zobrazuje
• Safari 4.0.4 — na místě, kde mají být @font-face písma, netiskne vůbec nic!
• Chrome 3.0 — @font-face zatím vůbec neumí

Na této testovací stránce pak můžeme vyzkoušet jak jsou na tom v Redmondu:

• IE 7 + 8 — fonty vkládáné jejich technologií EOT tiskne krásně

Vidíme tedy, že mimo Operu a Internet Explorer jsou minimálně na Windows prohlížeče zatím neschopné tisknout jinými než v lokálním operačním systému instalovanými fonty.

Kdo máte možnost vyzkoušet prohlížeče na Macu, napište prosím do komentářů.

Legrace, že obecně se má za to, že s @font-face lze vlastními fonty tisknout krásně. Kromě nevyhlazování písem na systémech bez antialiasingu se zdá, že se jedná o druhý výrazný nedostatek téhle výborné ale zatím k masovému nasazení nezralé technologie.

Železničářské Ministerstvo propagandy v časech recese šetří a tak nezbyly dotace na další nadšenecký článek o Rails. Radosti se místy nelze ubránit i tak, nicméně čekejte i chvíle dojemného zklamání. Článek je určen všem, kteří si myslí, že programovat weby nedokáží, ale povědomí o technologiích mají. Skuteční programátoři, ušetřete si nervy a běžte jinam.

Ostatně, mé startovací znalosti nebyly úplně mimo mísu. S Ruby on Rails (RoR) kódem přicházím pasivně do styku už přes dva roky, znalosti HTML a CSS mě živí až trapně dlouho. Věděl jsem co je to MVC, dokážu použít if a (Rubysté, ruku na klobouk) také unless. Tyhle znalosti nejsou ale tak podstatné, rozhoduje angličtina a schopnost správně se zeptat Googlu. Komunita kolem Rails je nadšená, sdílná a umí učit.

Ačkoliv o prospěšnosti RoR pro webdesign dlouhodobě nepochybuji, dost jsem nevěřil své šanci vyrobit web sám a hlavně o čase, ve kterém jsem schopen se to naučit.

Podívejte se, jak jsem postupoval a jaké problémy přitom řešil.

Začínáme s prací na projektu

Jde o primitivní eshop. Jednotlivé produkty jsou tříděny do kategorií. Pomocí jednokrokového formuláře lze objednat právě jeden produkt.

Z pohledu technického má práce na webu takovýto postup:

1. Znalost obsahu a vztahů mezi jeho typy 
2. Správa obsahu 
3. Výpis obsahu do uživatelského rozhraní webu 

První krok: definice typů obsahu a vztahů mezi nimi

Ať už jste programátor nebo designér, nejdříve se musíte důkladně seznámit s obsahem, se kterým pracujete. Jeden typ obsahu je v našem případě jeden Model. V tomto konkrétním projektu máme tři základní Modely: kategorii, produkt a objednávku.

Musíte znát vazby mezi Modely. V našem případě: Jeden produkt má právě jednu kategorii. Jedna objednávka obsahuje jeden produkt.

Máte? Jako uživatel Windows bych si teď představoval, že mi pokročilá technologie pro tvorbu webu poskytne nějaký klikací nástroj, kde si typy obsahu a vazby mezi nimi nadefinuji. Ani v RoR tomu tak není. Rails mají  blíž k Linuxovému uživatelskému rozhraní, použijeme tedy příkazovou řádku a pomocí generátoru vytvořím Modely. Vazby mezi nimi si pak nadefinujeme ve vygenerováném kódu. Je to sice horší než klikání, ale vůbec to nebolelo.

Záměrně tady nemluvím o databázi, natož abych zmiňoval MySQL nebo jiné standardy. Výšeuvedeným postupem jsme vlastně databázi nadefinovali, ale Rails se o databázi starají jaksi samovolně. První věc, nad kterou jsem radostně výskal. 

Mám tedy jednoduchý nástroj pro definici typů obsahu, data se mi nějak budou ukládat, ale já se nemusím trápit se znalostmi MySQL, SQLLite nebo čehokoliv jiného. To je hned o jednu úroveň technického myšlení a řešení problémů během práce na celém projektu méně. Místo toho můžu ženě uvařit čaj nebo podrbat naši kočku. Wow.

Druhý krok: Správa obsahu

Strukturu obsahu máme. Teď budeme potřeboval jednoduché rozhraní administrace, kde chceme samotný obsah přidávat, upravovat a mazat.

Administrační rozhraní na jedno kliknutí? Mám smůlu

Moje představa: ve chvíli kdy v klikacím rozhraní „vyrábím” Modely, hledal bych zatržítko „Vygeneruj z nich jednoduché správcovské rozhraní”. Naivní? V Rails zatím ano.

Zatržítko neexistuje, nemám dokonce ani snadnou možnost jak správcovské rozhraní oddělit (do obligátního /admin nebo jinam) od rozhraní pro zobrazování dat. Rails totiž generují kostru (říká se tomu scaffolding) uživatelského rozhraní v jednom celku. Oddělit správu jinam samozřejmě lze, ale je to mravenční práce.

Tady jsem se myslím poprvé a naposledy ocitl na hranici svých schopností a nebýt pánů Karla Minaříka a Vlada Suchého, zřejme bych v tomto levelu hry ztratil všechny životy. Zdály se mi tady sny o Djangu, které sice neznám ani tak špatně jako Rails, ale které má generování správcovského rozhraní vyřešeno na pohled docela hezky. Ani v případě Rails ovšem nevěřím, že by komunita nechala administrace-chtivé kodéry dlouho na holičkách.

Trochu krve a potu a nakonec tedy jednoduché správcovské rozhraní máme.

Třetí krok: výpis obsahu do uživatelského rozhraní webu

Výpis samotných dat v šablonách (tedy Views) je něco kvůli čemu jsme celou tu věc dělali a jste-li kodérem, budete se tady cítit jako doma. Téma Rails a šťastný kodér je ale na úplně jiný článek. Tady se bavíme o problémech nešťastného začínajícího programátora.

Hodně mi zpočátku vadilo, že bych měl pro HTML prvky využívat Rails metody (například image_tag namísto ). Takové programátorštiny s divnou syntaxí v mém krásném HTML! Jenže porovnejte dva kusy kódu:

<% unless @product.image.blank? %>

<% end %>

a

<%= image_tag(@product.image) unless @product.image.blank? %>

Ten kdo vybere druhý případ není jen programátor, ale také člověk, který chce svůj kód zanechat čitelný a snadno pochopitelný. 

Migrace: olej do soukolí databáze, ale rozhraní nikoliv

Dobrá, máme nějaká data, máme jejich správu, máme výpis těch dat do uživatelského rozhraní webu. Jsme relativně šťastní, dokud… Dokud nepřijde zlý klient a neřekne, že do každého produktu by potřeboval přidat ještě anotaci a další obrázek.

Máme však výhodu, že myslíme agilně a Rails nás v tom podporují. On klient není zlý a jeho požadavek je zcela na místě. V Rails to jde samo — vytvoříme si migraci, kde ty dvě, tři pložky do databáze přidáme.

Jenže jak je přidáme do hotového rozhraní a administrace? Bohužel tušíte správně. Ručně. Svět není tak daleko, abyste se nepříjené práce nezbavili úplně. Docela by mě zajímalo, zda zrovna téhle prudy umí některá ze současných technologií zbavit.

Shrnutí: sami to určitě zkoušejte

Už dlouho se mi nestalo, že bych při adopci nějaké technologie propadal takovému jásotu nad vlastním pokrokem. Zkoušku Rails doporučuji všem kodérům, projektovým vedoucím, ale i techničtějším designérům nebo marketérům. Hlavně všem, kteří si při pohledu do PHP zdrojových kódu řekli, že „ne, to programování opravdu není pro mě”.

Berte mou chválu samozřejmě s rezervou, pokrok proběhl i jinde. Máme Django, CakePHP nebo Nette. Se všemi jsem přišel alespoň letmo do styku, leccos na nich oceňuji, ale nemám dostatečné znalosti abych byl schopen porovnání.

Soudě podle této zkušenosti s Rails, vyvíjet weby na míru bez hlubších technických znalostí zatím moc nejde, chcete-li se je ale naučit programovat, s Rails vám to může jít překvapivě snadno.