DevFest 2014: Responzivní obrázky tečka Dart [video]

devfest2014-publikum-jan-zalsky

Na letošní DevFest jsme z LMC vyrazili pouze v malém týmu tří lidí. Přednášek a workshopů navštívil každý z nás přibližně stejně; o podobě záchrany lidstva jsem však bojoval pouze já. (Palec nahoru organizátorům za zábavu při celodenní hře!)

Darrrt

Tématem, které rezonovalo celou konferencí, byl jazyk Dart – nepokrytě pak v sugestivně nazvané přednášce Jany Moudré Dart, Darrt, Darrrt. Mluvilo se o něm na mnoha dalších prezentacích a workshopech přímo zmiňující jeho jméno v názvu. To nebylo překvapivé. Kdo by ale odhadl, že při povídání o Polymer.js bude většina dotazů mířit na Polymer.dart; nebo že se o něj budou čile zajímat lidé, kteří nevyvíjí front-end a běžně píší v Javě nebo C#? Nejjistějším důkazem však byla moje konverzace s personalistkou, zajímající se nakolik je „znalost jazyka Dart výhodou“ výhodou.

Osobně jsem byl z Dartu velmi nadšený. Byl, když se poprvé objevil. Od té doby mé nadšení ochladlo a čekalo na znovunastartování do doby, než se virtuální stroj Dartu dostane do Chrome, a raketově vystřelí až se prosadí i jinde. Po diskuzi s Filipem Hráčkem o tom, jak pokrořila kompilace Dartu do JavaScriptu, si dokáži představit praktické použití již dnes. Stále to ale nestačí, abych pro Dart opravdově zahořel.

Diskuze s Filipem (a dalšími) proběhla u piva na večerní after party, kterou můžu s klidem označit za nejlepší z těch, které za poslední tři roky po pražských vývojářských konferencích proběhly.

Pokročilé responzivní obrázky

Já sám jsem v podvečer přednesl svou zatím nejúplnější prezentaci o responzivních obrázcích, kterým jsem tento rok věnoval mnoho pozornosti. Díky velkorysému prostoru – 45 minut – jsem měl možnost projít vše podstatné.

Začal jsem motivací a představil případy užití definované skupinou RICG. Dále jsem se snažil abstraktně popsat, který rozpor mezi prohlížečem a vývojářem je třeba vyřešit. Samozřejmě jsem vyložil syntaxi přijaté specifikace elementu picture a atributů srcset a sizes. Nakonec jsem ukázal, jaký algoritmus výběru toho správného obrázku používá Google Chrome.

Podívejte se na záznam, nebo si jen projděte – ilustrativně pojatou – prezentaci:

(Úvodní obrázek je výřez z fotografie Jana Žalského)

Tipy pro práci s Bowerem aneb pokročilý lemčík

Lemčík ve svém loubí

Lemčík je australský ptáček, který je známý tím, že jeho samec ze svého okolí vybírá větvičky a jiné rozličné předměty, ze kterých staví komplikované stavby zvané loubí (více na Wikipedii). Lemčík je anglicky nazývá bowerbird a loubí je anglicky bower. A ano, přesně takto přišel Bower – nástroj, který z okolí vybírá nástroje a jiné rozličné komponenty – ke svému názvu.

Pokud znáte základy Boweru, možná byste ocenili některé tipy k ulehčení tvorby vašeho loubí. Sepsal jsem ty, které považuji za nejužitečnější.

Lokální vývoj komponent

Typická situace: mám závislost, kterou potřebuji vyvíjet v rámci jiného projektu. Jak na to? Mohu každou změnu přidat do gitu, publikovat ji, stáhnout v projektu, případně použít buildovací nástroj a pak konečně otestovat. To je ta zdlouhavá a otravná varianta.

Bower nabízí přímý přístup pomocí volby link. Stačí v adresáři s komponentou zadat bower link a poté v adresáři projektu tuto komponentu vnitřně zaregistrovat spuštěním bower link nazev-komponenty. V projektu vznikne symlink, takže jakákoli úprava v komponentě bude ihned viditelná v projektu. Pro načtení verze z bower.json a přepsání symlinku stačí zadat v projektu bower update.

Definice balíčku

Jak boweru řeknete, který modul má stáhnout? No přeci jeho názvem: jquery, bootstrap, emerald atd.!

Jistě, to je pravda, ale jde to i jinak. Důležité je uvědomit si, že Bower pracuje s git repozitáři. Jako balíček ke stažení lze zadat libovolnou git adresu. Taková adresa může být dokonce privátní. Při zadání názvu se ve skutečnosti stane jen to, že se Bower podívá do své databáze, který git repozitář je pod tímto názvem zaregistrovaný.

Adresa repozitáře se zadává do bower.json na místo, kde se obvykle uvádí verze balíčku. Za ní může následovat znak # a označení tagu, název větve, nebo hash konkrétního commitu. Text na místě názvu balíčku bude odpovídat názvu adresáře v bower_components. Díky tomu umí Bower naistalovat dvě různé verze stejného balíčku.

Různé možnosti a kombinace jsou demonstrovány v této ukázce:

Podrobněji o tomto pojednává sekce install v dokumentaci.

Změna cílového adresáře

Často se vývojáři ptají, jestli a jak mohou změnit adresář, kam Bower instaluje komponenty z výchozí app/bower_components. To je velmi jednoduché, stačí do adresáře s bower.json přidat soubor .bowerrc s následujícím obsahem:

Tento soubor je samozřejmě nutné přidat do repozitáře, aby se tato změna projevila všem spolupracovníkům. Doporučuji .bowerrc vytvořit vždy, mezi jednotlivými verzemi Boweru se totiž cílový adresář mění z bower_components na app/bower_components.

Drobnost na závěr

Každý se občas potřebuje podívat do dokumentace balíčku, s kterým pracuje. Při zadání bower home nazev-balicku se v prohlížeči zobrazí domovská stránka daného balíčku bez pátrání mezi výsledky hledání.

(Úvodní obrázek je výřez z originálu a podléhá licenci CC BY-SA 2.0)