Proč přechod

VersionPress, nebo minimálně jeho části, budou v dohledné době komunitní projekt a nedá se svítit, vývojáři jsou dneska na GitHubu. Tím jdou v podstatě všechny ostatní argumenty stranou, čímž neříkám, že GitHub nemá další pro – např. je cloud-hostovaný, rozumně levný, s plným API apod. Ale komunita je to, co nás “nutí”.

Přejít z JIRY je radost, ne?

Nevím. JIRA má z mého pohledu jen dva nedostatky: je pomalá a je pomalá. Jinak je to jednoduchý systém, s kanban boardem, logickým uspořádáním, moc toho v základu nechybí ani nepřebývá, zkrátka o JIŘE tak trochu platí, že pokud jste si na ni udělali špatný názor před deseti lety, dneska byste se divili.

Spolu s Bitbucketem, který používáme na pull requesty a code reviews, je to harmonický celek, který nás celkem ničím (kromě pomalosti) neštve a funguje dobře.

GitHub

Příslibem a současně problém GitHubu je, že by měl zvládnout roli JIRY, Bitbucketu a možná i ještě něčeho dalšího (lidi to např. často berou jako support kanál, viz label “question” v GH Issues). To je obecně velká výzva a je celkem jasné, že ji GitHub může v plné šíři zvládnout jen těžko.

Mé postřehy jsou následující:

1) Issue tracker doplácí na klasické “jednoduché neznamená nutně dobře použitelné”. V podstatě jediným kategorizačním mechanismem jsou labely, což by i mohlo stačit, kdyby byly udělané dobře. Ale přejmenovat label znamená udělat si v trackeru bordel (labely nemají identitu, v historii ticketů zůstanou jen jako string odkazující se na stránku k ničemu), z toho plyne nutnost je dobře navrhnout už od začátku, ale jak to má člověk bez zkušeností udělat, že jo, apod. Tohle je zcela proti konceptu don’t make me think a znovu, stačilo by, aby labely byly udělané dobře, ve stylu polí v jiných issue trackerech. Ale nejsou.

Plus to kupu věcí neumí, například varovat uživatele, že vkládá issue, která už pravděpodobně existuje, nebo ukládat historii editů, nebo přikládat libovolné soubory (docela nově umějí vedle obrázků aspoň DOCX a PDF). Něco z toho jsou menší věci, ale některé podle mě docela zásadní.

2) Issues používají stejnou číselnou řadu jako pull requesty. To je obecně hrozně zajímavý koncept – ne ta čísla, ale že PRs jsou v podstatě issues. Není to tak dávno zpátky, co mi tohle dávalo velký smysl. U nás se totiž běžně stávalo, že se ticket založil v JIŘE, nějak se tam lehce podiskutovalo, ale jak se začal psát kód a otevřel se PR, tak se komunikace přesunula tam. Ale jen částečně – pořád ještě šly nějaké komentáře k issues. Takže to bylo zbytečně a otravně rozdvojené a říkal jsem si, jak by bylo fajn, kdyby celý issue tracker byl jeden PR za druhým. A asi si to řekli i v GitHubu.

Jenže to nefunguje. Přišli na to sami, když před časem zakázali konvertovat issues do pull requestů – přinášelo to víc zmatku než užitku. Chtě nechtě, issues a PRs jsou dvě různé věci, ač relativně úzce propojené, a mělo by to být v UI i v číselné řadě oddělené. Mimochodem, na JIŘE zpětně oceňuju, že projekt má svůj klíč a číslo issue vypadá např. VP-123. Jak vidím něco takového kdekoliv (ve wiki, v mailu, …), okamžitě vím, že se jedná o VersionPress issue. #123 mi bez kontextu neříká nic, a ani v rámci kontextu projektu nevím, jestli to je PR nebo ticket :) #cognitiveLoad

3) Pull requesty by měly být pýchou GitHubu, ale upřímně, Bitbucket je má zas tak nějak ošklivější, ale funkčnější. Tam založím PR, přidám své kolegy jako reviewery, oni mi buďto dají fajfku jako že vše OK, nebo napíšou komentář, a z jedné stránky přehledně vidím, jak jsou všechny PR na tom. Dead simple. Na GitHubu to jde nasimulovat palcema nahoru nebo kdovíjak všelijak, ale podobně jako u issues, tam, kde mě tool Atlassianu vede a po applovsku mi nedává moc šanci udělat chybu, na GitHubu musím být kreativní a po androidovsku si to tak nějak vykoumat. To je přísné hodnocení, co? Zvlášť když vizuálně GitHub vypadá tak jednoduchý a cool…

Nicméně…

Statisticky na GitHubu projektu prostě fungují v pohodě. Je tam Facebook, Microsoft, Automattic (WordPress company) a mnoho dalších. Půjde to i u nás, jen asi musíme rezignovat z “čistoty” současných postupů. Ono se to asi stejně stane, až nám do našeho “svatého” issue trackeru začnou lidi valit jednu duplicitu za druhou. Jak už to bývá, u issue #5 zamrzí, že je zabraná nějakým blbým pull requestem, ale u issue #2617 je to už úplně jedno.

Prosba – zkušenosti s OSS projekty

Na závěr bych vás moc rád požádal o jakékoliv tipy, které máte k provozování OSS projektů na GitHubu, hlavně z pohledu autora / maintainera. Pro nás to bude nová zkušenost, a pokud by se daly ušetřit nějaké starosti, určitě by to neuškodilo :) Díky a konec úvahy.

Důležitá poznámka: někdo Slack používá jako IRC / Gitter / Yammer nebo něco podobného, kde je vše OK. My ho ale používáme pro vnitrofiremní komunikaci, což je i víc v souladu s tím, jak se Slack prezentuje na své homepage.

Problém č. 1: notifikace

Když s někým komunikuji, potřebuji několik základních věcí:

1. Dozvědět se, že daný člověk zprávu obdržel
2. Pokud mi píše odpověď, chci vědět, že se tak děje
3. Když se zpráva pro mě relevantní doručí, potřebuji být notifikován

Dvojku má Slack pořešenou, jedničku vůbec a trojku špatně.

Že nemají implementovanou “fajfku přečteno” (bod č. 1) nechápu. Je to základ – pokud někomu pošlu zprávu, na kterou očekávám odpověď, hodí se vědět, jestli to ten dotyčný aspoň četl, abych se podle toho mohl zařídit (někdy se vyplatí počkat na odpověď, někdy switchnout kontext a pokračovat jinou prací). Asi to není potřeba moc vysvětlovat, read marker dnes umí Google Hangouts, Facebook nebo i blbé SMSky. Slack ne.

Co se trojky týče, Slack nějaké notifikace umí, a mohl bych sáhodlouze rozebírat, v jakých případech jsou dostatečné a kde nikoliv. Důležité je ale jen jedno – pravidelně se mi stává, že nedostanu notifikaci na zprávu, na kterou bych ji byl býval chtěl dostat. Záměrně to píšu takhle nekonkrétně, protože někdy by se dalo argumentovat, že mi kolega měl dát @mention a tedy udělal chybu on, nebo jsem si měl zapnout globální notifikace pro kanál a tedy jsem udělal chybu já, nebo blablabla. Pro mě je důležité jen jedno – náš tým více méně příčetných lidí není schopen najít nastavení, kde by všichni dostávali notifikace na zprávy pro ně důležité a nedostávali notifikace na zprávy pro ně irelevantní. Každý z nás občas mine něco, co by neměl, nebo naopak dostává otravné notifikace na věci, které se ho netýkají.

Což mě dostává do trochu filosofičtější roviny:

Slack používá špatný model světa

Ano, to si myslím. Připadá mi to, jako by Slack historicky vznikl jako reinkarnace IRC (tak ostatně hodně lidí Slack popisuje) a až pak je napadlo, že peníze jsou ve firmách, tak proč nezačít Slack tlačit jako nástroj vnitrofiremní komunikace. Je to jen spekulace, ale takhle by mi to docela dávalo smysl, a je to podle mě bohužel zdroj výše uvedených problémů.

Například, co je to “kanál”? Něco, kam se naladím a můžu poslouchat, co se v něm děje, zde tedy i s úpravou, že do něj sám můžu přispívat. Super pro OSS projekty a například Gitter se mi líbí moc (ten dokonce umí read markery s velmi povedeným UX, to by měl Slack zkopírovat), ale pro mnoho typů komunikací to není správný obraz toho, co se děje v reálném světě.

V reálném světě se totiž komunikace (ať už one-to-one nebo skupinová) točí kolem nějakého tématu. Tuhle půlhodinu řešíme, jak by mohl vypadat dialog XY. Za hodinu řešíme, jakou technologii zvolit pro YZ. Někdy se stane, že se člověk účastní víc konverzací najednou, což je trošku specialitka písemné konverzace, ale je to už desítky let zcela běžné ve světě emailů a stále relativně běžné ve světě IM. A Slack nemá o tématu nejmenší tušení, to je pro něj cizí koncept. Lze to nějak simulovat vytvořením nového kanálu pro každou konverzaci, nebo group chatů mimo kanály, ale to už se spíš hackuje nad platformou, které té koncept prostě chybí.

Přirozené jsou totiž *konverzace* (vlákna), nikoliv *kanály* (místnosti). Tady se krásně ukazuje, jak “objektový návrh” ovlivňuje reálnou použitelnost produktu. Konverzačně pojatá platforma totiž nemá nejmenší problém s notifikacemi. Vemte si například Facebook – dostáváte notifikace o nových komentářích jen u postů, kterých jste se aktivně zúčastnili, naopak je nedostáváte u ostatních. Totéž group chaty, kde dostáváte notifikace, dokud se debaty účastníte nebo ji sledujete, a přestanete je dostávat, když tak Facebooku řeknete. Vše zcela intuitivní a funkční.

Sečteno podtrženo, myslím, že celkem chápu, v jakých situacích je Slack dobrý, ale pro týmovou komunikaci má své otravnosti. Není to tak hrozné, abychom měli akutní potřebu někam prchnout, ale pokud byste někdo měl tip na podobnou službu, která se ale točí kolem konverzací, určitě rád mrknu.

Hned po ránu vyrážím do CEVRO Institutu na Tomáše Hálu z ACTIVE24, který tam od 13h povídá o projektu Fénix, bezpečné VLAN, která v případě DoS útoku umožní vybraným službám spolu komunikovat, ať se děje, co se děje. Ale to nám, obyčejným uživatelům webových prohlížečů je stejně k ničemu, protože do takové sítě přístup mít nebudeme a tak se na ty služby v době útoku stejně nepřipojíme.

Po malé přestávce se nechtěně probouzím na přednášce Petra Chytila z AVAST Software, ten zrovna popisuje techniky, pomocí kterých dostávají informace o virech do našich antivirů. Petr také prozrazuje, že tahle vlna “exekutorských e-mailů” byla už určitě poslední, protože od příště tyhle zprávy budou našejejich antiviry blokovat ještě dříve, než je váš oblíbený exekutor odešle.

Traffic v CEVRO Institutu i nadále skenuje AVAST, od Jakuba Janečka se dozvídám o masivně škálovatelných službách, o úplně nejvíc Web Scale databázi MongoDB se ale bohužel nemluví, takže si nenápadně odskakuji na toaletu a už se nevracím. Zapomenutou bundu mi žádný dobrák nepřinese. Večer na party je dostatečný klid, takže si do sluchátek pouštím podcast, ve kterém se právě o technologiích používaných v AVASTu mluví a já začínám litovat, že jsem nezůstal do konce.

Na toaletu samozřejmě nejdu, to ještě pár dní vydržím, místo toho se vydávám do Světozoru. Cestou ovšem zabloudím, kolem Václaváku nejsem místní, a omylem se zjevuji na Startup Stage, kde slyším pár vět a v nich, jako jeden z mála posluchačů, rozumím jen jednomu jedinému slovíčku – hacking. Tomu ale zase nerozumí ostatní návštěvníci. V tu chvíli se o slovo opět hlásí potřeba a já si vzpomínám, že jsem vlastně chtěl jít na záchod. Po technické přestávce se tedy konečně dostávám do Světozoru, kde Daniel Bagge povídá o evoluci hrozeb starších než on. Daniel pracuje v Národním bezpečnostním úřadu a já už jsem párkrát slyšel mluvit jeho nejvyššího, takže správně tipuji, že tou hrozbou, o které bude přednáška, je právě jeho šéf. Podle fotky starší je, takže to sedí.

Ve Světozoru zůstávám na přednášku Pera Thorsheima. Per založil konferenci Passwords, která se koná dvakrát ročně, jednou v Las Vegas, podruhé kdesi za severním polárním kruhem. Každým rokem se na této konferenci sjíždějí odborníci, kteří svá hesla zapomněli a Per jim je vždy připomene. Jsem moc rád, že se Per ukáže v Praze, od mého posledního výletu do Las Vegas už pár dní uplynulo, takže jsem zase několik hesel stihl zapomenout.

Nejsem sám, kdo zapomíná hesla, takže Perova přednáška se protahuje až do brzkých ranních hodin do míst, kde točí Plzeň. Všechna nová hesla všech účastníků Perovo prodloužené přednášky si hned zapisuji a díky tomu nestíhám workshop Jana Pavla od 10h ráno, ale co už, kyberzločincem již podle některých jsem, takže to zas tak nevadí. Pokud vy nejste a chtěli byste být, neváhejte, ale doma to děti raději nezkoušejte.

Veřejným tajemstvím letošního WebExpa je skutečnost, že AVAST tentokrát v rámci sponzorství místo finančního příspěvku poslal organizátorům na účet asi dvacet spíkrů, takže mě nepřekvapuje, že nestíhám ani přednášku dalšího avasťáka, .NET vývojáře Michala Augustýna, tentokrát o Postgresu, od 10:20. Jestli tam někdo půjdete, tak se hlavně neptejte, proč Michal nezvolil MSSQL, jinak se ostatní posluchači neprobudí ani na oběd, který letos vlastně ani není v ceně.

Vzpomínám si, že jsem chtěl slyšet i něco zajímavého ze světa databází, jenže před sedmi lety jsem přičuchnul k PostgreSQL a tak mě další varianta MySQL zas tak moc netankuje. V klidu tedy pokračuji v zapisování všech nových hesel a chvilkami mě mrzí, že jich mám tolik, že jsem nestihl Michala, ale do notýsku si k jeho heslu PasswordAvast3 píšu poznámku, že si mám na večer stáhnout další podcast, ze kterého se o PostgreSQL později dozvídám i něco nového.

Node.js, Azure a Skype je ďábelská kombinace, před pár lety skoro nepředstavitelná. Pokud pro Skype náhodou nepracujete a chtěli byste o téhle kombinaci něco slyšet, dostavte se od 11h do České Spořitelny, Catalin Ionut Fratila (to je jeden člověk), vám řekne, jak to ve Skype míchají. Podle mých informací jim to jde ještě lépe, než když jsme tam s Lukášem Hudečkem míchali rum s kolou, takže se máte se na co těšit.

Po pauze na oběd, která vlastně žádná není, se nějakým zázrakem probouzím v České Spořitelně na přednášce Matěje Kvocera s názvem Rent-a-hacker. V CEVRO Institutu probíhá souběžně přednáška Stanislava Hackera a já celou dobu přemýšlím, jakou dostanu cenu za to, že jsem tenhle easter egg pořadatelů objevil. Přednášku tím pádem moc nevnímám, ale mám na sobě tričko s číslem svého bankovního účtu, kdyby si mě někdo chtěl náhodou najmout.

Od 14h povídá Innovation evangelist České Spořitelny v České Spořitelně o API České Spořitelny. Za mě dobrý a palec nahoru organizátorům za výběr místa na tuhle přednášku. Já osobně bych ji dal do Era světa. Budete-li mi chtít v komentářích sdělit, kam jinam byste tu přednášku dali vy, nezapomeňte do textu uvést slovo kiwi, ať víme, že jste si můj sen přečetli celý.

Líbí se mi, že když se konečně z těch všech pojišťoven vzpamatuji, tak nemusím nikam přecházet. Michal Kubíček začíná mluvit o tom, jak si nenechat hacknout WordPress. WordPress sice nepoužívám a tak zkouším, jestli web pay4t.cz, za nímž stojí právě Michalova firma, stále ukládá hesla uživatelů pomocí algoritmu MD5 bez přidání soli. A co byste řekl, měl ho tam, pořád. Zbytek přednášky se tedy raději těším na jediného WordPress hackera, kterého znám osobně. Borek Bernard se snaží WordPress ohnout tak, aby uměl verzování všeho možného do Gitu a mě se moc líbí, že je možné publikovat obsah tak, že do Gitu jednoduše pushnu nový textový soubor.

Na konci víkendu mě trochu mrzí, že letošní WebExpo nemělo více vývojářských přednášek a že to byl spíše takový Marketing Festival říznutý Creative Mornings, nicméně už teď vím, že si to týden po WebExpu vynahradím několika dny školení (zvu vás) a návštěvou konference o PHP v Brně.

A co se zdálo dneska vám, hmm? A chci to vůbec vědět?

Trable s CMS

Nevím, jestli to máte stejně, ale hledání vhodného CMS mě provází v podstatě celý život. Blog, produktová stránka, různé mikrosajty, multi-uživatelský DevBlog, komunitní web pro kamarády, dokumentace k projektu atd. – pořád řeším, jak nějaký obsah publikovat a spravovat. Za svůj život jsem přešel mezi několika redakčními systémy a i si pár menších napsal, v čemž patrně nejsem výjimka (kdo nějaký aspoň maličký CMS nikdy nenapsal, ať hodí klávesnicí).

Ač mě o principech CMS baví přemýšlet a částečně je i realizovat, celkově vzato je to hrozná pruda. Mám obsah, chci s ním ven a typicky nechci strávit dny a týdny řešením (v horším případě rovnou programováním) CMS. Když jsem si po mnoha letech marných snah a prázdných pokusů uvědomil, že vyvinout a provozovat vlastní CMS není realistické, zakotvil jsem jako miliony dalších u WordPressu (viz například výběr CMS pro DevBlog). Byl to takový sňatek z rozumu – unešený jsem z WordPressu nebyl, ale na druhou stranu nad ním lze postavit celkem libovolný web, na všechno existuje plugin, UI je docela hezké, WordPress se aktivně vyvíjí, lze ho provozovat na mnoha různých hostinzích, s problémem pomůže řada uživatelských fór a tak dále. Můžete mít proti WordPressu mnoho námitek, ale asi nebude náhoda, že je s převahou nejrozšířenější CMS na světě.

Přesto se mi WordPress nikdy nevybíral snadno. Vím, že u něj budou problémy s kvalitou externích pluginů. Vím, že u něj budou problémy s aktualizacemi (rozbitý web poté, co jeden z deseti pluginů zrovna obsahuje chybu nebo nekompatibilitu s novou verzí WP). A že když aktualizace vypnu, velmi pravděpodobně můj web bude náchylný k nějakému bezpečnostnímu útoku. A že bude problematický staging. A že se to bude blbě verzovat v Gitu, když půlka pravdy o webu je na disku a druhá půlka v MySQL databázi. A tak dále, a tak dále.

Zkrátka WordPress je kompromis. Rozumný kompromis, ale kompromis.

A tam někde vznikla myšlenka na VersionPress.

Co je VersionPress

VersionPress je verzovací plugin pro WordPress. Jeho nejvýraznější vlastností je, že verzuje jak soubory, tak databázi, takže v repozitáři (na pozadí používáme Git) je v každém okamžiku kompletní informace o webu jako celku. To zcela mění způsob, jakým mohou administrátoři s WP webem pracovat – například lze rozbitý web opravit jedním kliknutím na “Undo” button, zálohy jsou mnohanásobně úspornější než typické MySQL dumpy, dokážeme synchronizovat testovací / staging / živé prostředí, projekt se dá snadno sdílet přes GitHub a tak dále. Je to zhruba stejný upgrade, jako když se v softwarových projektech zabydlely VCS – i bez nich se software dal nějak vyvíjet, ale pro mě je to třeba už dneska těžko představitelné.

VersionPress proto vnímám jako mnohem víc než malé verzovátko pro WordPress. Je to snaha vzít populární publikační platformu a vyměnit její relativně křehký podvozek za něco řádově spolehlivějšího. Nezmizí tím sice automaticky problémy, ke kterým je WordPress náchylný (stejně jako Git nepomůže vyřešit záludnosti programovacího jazyka X nebo Y), ale když už nastane problém, cesta zpět je rychlá a bezbolestná. Rovněž, důležitá věc je synchronizace více prostředí (test / staging / live), což je u WordPressu historicky problematické a s čímž VersionPress nesmírně pomáhá. Takže zatímco dnes mnoho lidí “testuje” v produkci, s VersionPressem to lze dělat lépe.

Jednoduše řečeno, VersionPress je snaha spojit populární, uživatelsky orientovaný WordPress s technikami, které jsou běžné v “seriózních” softwarových projektech, to vše formou, kterou zvládne běžný Franta uživatel. Nikdy se mi nepodařilo vytvořit CMS zcela podle mých ideálů, ale VersionPress je něco, co WordPress v mých očích posouvá výrazně blíž redakčnímu systému, který si vyberu relativně bez váhání.

Potřebujeme vaši pomoc

Při realizaci VersionPressu jsme měli dvě cesty – buďto to zkusit celé vyvinout potichu, nebo jít s kůží na trh brzo a zkusit získat nějaké zdroje financování ve stylu Kickstarteru. Zvolili jsme druhou cestu (ač přímo na Kickstarteru kvůli jeho pravidlům být nemůžeme), především proto, že VersionPress je technicky hodně ambiciózní a jeho implementace je běh na dlouhou trať. Verzování databáze je obecně těžký problém a další velkou výzvou budou různé externí pluginy, které v databázi dělají různé “zajímavé” věci, potřebujeme rozchodit Git na běžném LAMP hostingu a tak dále. Práce je zkrátka moře a není realistické plně realizovat VersionPress po večerech.

Proto jsme dnes spustili crowd-funding kampaň, která poběží v průběhu června. Pokud děláte s WordPressem a náš projekt by pro vás mohl být užitečný, prosím podpořte ho, ať už finančně nebo třeba tím, že nás zmíníte na svém blogu / FB / Twitteru. Pokud byste nás chtěli podpořit finančně, můžete použít kód CZSK při checkoutu pro získání 50% slevy.

Díky, a snad o trochu posuneme stojaté vody jednoho malého CMSka :)

P.S. VersionPress můžete sledovat na Twitteru nebo lajkovat na Facebooku

P.P.S. Pokud máte otázky nebo zpětnou vazbu, pište prosím do komentářů nebo na můj mail. Rád na cokoliv odpovím.

Na jednu stranu, a to o nástrojích JetBrains platilo vždy, jejich IDE je velmi inteligentní a dobře rozumí kódu. Flash Builder v tomto taky není úplně špatný a o vztahu různých symbolů v projektu má slušnou představu, ale IDEA je určitě dál. V praktické rovině je například daleko pohodlnější se z deklarace rozhraní prokliknout na jednotlivé implementace (ve Flash Builderu nutno neohrabaně přes Find References), lze udělat rychlý diagram závislostí mezi projekty atd. atd. Tohle je, hádám, hlavní důvod, proč tolik (nejen Flex-) vývojářů IDEU vynáší do nebes a fakt je příjemné v tom kódit, pokud všechno ostatní funguje.

Jenže v tom je ten háček. Už u JavaScriptového vývoje ve WebStormu u mě zhruba platilo, že co hodina práce v IDE, to jeden reportovaný bug. Trochu jsem doufal, že u silně typového Flexu, kde kompilátory i debugger jsou odladěnou součástí Flex SDK a IDE je tak vlastně jen malou slupkou nad nimi, to bude lepší, ale už jen import našeho projektu do IDEY byl docela dílem a dokonce se muselo čekat na opravný setinkový release, aby náš projekt vůbec bez změny kódu fungoval. A potom mám ohromný problém s použitelností toho IDE – ne se vzhledem, ale s fundamentální použitelností na mnoha místech.Uvedu tři příklady, každý na poněkud jiné úrovni.

1) Tooltipy (tohle je z kategorie obecného GUI; zdánlivě blbost, nicméně pokud je tam takovýchto problémů na každém kroku deset, prostě to otravuje). Defaultně se tooltipy zobrazují za nesmyslných 1200ms, a když přejíždím myší z tlačítka na tlačítko, tak se tento delay aplikuje znovu a znovu. Hrozně by mě zajímalo, jak takovéto chování vzniklo. Jestli v JetBrains nějakému programátorovi jen zadali “udělej podporu pro tooltipy” a nechali to na něm, nebo jestli se nad tím někdo přes UI skutečně zamyslel a výstupem bylo ignorovat běžné konvence a udělat zkoumání funkcí tlačítek záměrně nepříjemné. (Nemyslím to jako zesměšňování, u IDE si teoreticky dokážu představit, že to mohl být záměr.)

Do této kategorie problémů by toho z mého pohledu spadlo mnoho, od nekonzistentní terminologie, přes nepozornost k formátování, používání barev a tak dále a tak dále. Často je to skoro podprahové – dělám něco, co ve Flash Builderu bylo z nějakého důvodu příjemnější, a nedokážu hned říct, čím to je. Tak si ten samý projekt otevřu tam a pak mi to dojde – například formulář používá fieldsety, speciální značky v kódu jsou jinou barvou nebo nějaká podobná drobnost. Protože autorům Eclipse / FB na použitelnosti záleželo.

2) Zadávání cest. V týmových projektech je téměř vždy potřeba se vyhnout absolutním cestám a používat nějaké proměnné, například PROJECT_ROOT apod. IDEA toto podporuje skrze tzv. path variables, ale kromě toho, že někde v settings máte tyto proměnné nastavené, se IDEA tváří, že všude používáte absolutní cesty (při uložení a načtení projektu se tyto absolutní cesty na pozadí převedou na path variables a zpět). Technicky není co vyčítat, ale z pohledu GUI je to hrozně neintuitivní. Vy víte, že jste si nadeklarovali proměnnou PROJECT_ROOT, ale nemůžete tuto proměnnou nikde nijak použít. Ať zadáváte cestu kdekoliv, je to přes poměrně hloupý file system browser, který nemá žádnou “přidanou hodnotu” – prostě jen umí procházet FS a pracovat s absolutními cestami (a ještě se načítá dlouho). Pro srovnání, jak to funguje v Eclipse: jednak jde cesta vždy zadat bez otevírání otravného stromu filesystému, druhak Eclipse ví o path variables, které jste si nadefinovali, a nejen že vám je dovolí zadat, i je k dispozici autocomplete. Je to nejen uživatelsky přívětivé, ale hlavně to odpovídá realitě: v projektových souborech bude jak v Eclipse, tak v IDEE něco jako dependency=$PROJECT_ROOT/libs/xyz, rozdíl je v tom, že Eclipse tuto realitu reflektuje v GUI, zatímco IDEA to zakrývá.

3) Chybějící Problems view. Pro mě asi největší šok, ale IDEA nemá společný panel problémů, něco jako Problems view v Eclipse nebo Error List ve Visual Studiu. Chyby detekované kompilátorem se zobrazují v panelu Messages, který je spíš takovou chytřejší konzolí (jsou tam zbytečně zobrazené info messages, je to strom místo listu, občas panel Messages vůbec není přístupný atd.) a především zobrazuje až chyby zjištěné samotných kompilátorem, ne IDEOU samotnou. Pokud chce člověk zobrazit problémy vzešlé z live analýzy kódu, může zkusit třeba v Project exploreru přepnout na filtr Problems, ale i to má své problémy: zaprvé se tím schová strom projektu, dále se pak opět jedná o otravný strom namísto listu, no a potom se zde zobrazují jen chyby v otevřených souborech, ne všechny chyby v projektu. Pak je v IDEE ještě jakýsi panel výsledků statické analýzy, kterou je ale potřeba spustit explicitně, a pro Javovské projekty jsem viděl ještě jakýsi jiný panel, který už jako Error List vypadá, ale pro Flexové projekty není ničím naplněný.

Není to absurdní? IDEA ví o mém kódu hrozně moc, ale nemá rozumné GUI, ve kterém by mi to zobrazila. Má jen kupu různě více nebo méně vhodných panelů, přitom řešení je tak hrozně prosté: mít tabulku ale Eclipse nebo Visual Studio, kam se sypou všechny errory a warningy. Není mi jasné, proč se vyhýbají řešení, které nejen že je všude jinde obvyklé, ale navíc je velmi jednoduché na implementaci a uživatelsky intuitivní.

Při vývoji v IDEE jsem tedy na každém kroku narážel na různé nedomyšlenosti. Jak je to možné? Dovolím si zaspekulovat.

Když mám s IDEOU problém, jdu jim to hned nahlásit do bug trackeru. (Tady jde JetBrains hodně k plusu, že vůbec něco takového mají a že se člověk zaručeně dočká reakce v řádu hodin.) Píšu tam klidně i obecné usability věci, jako že ty path variables / absolutní cesty se chovají neintuitivně, kde mi to způsobilo problémy a jak bych si představoval řešení. Takový ticket je většinou přiřazen na někoho, kdo, tipuji, je rovnou vývojář, ne žádný project manažer nebo něco takového. To je na jednu krásně přímočaré a agilní, a nejednou se mi stalo, že nějakou drobnost ten člověk hnedka fixnul a za pár dní byla nová verze na světě (to je u jiných IDE skoro nemyslitelné), na druhou stranu pokud máte problém s něčím, co je IDEOU prolezlé a potřebovalo by koncepční změnu, dá se celkem spolehnout na to, že běžný-franta-JetBrains-vývojář to uzavře jako wontfix nebo prostě na implementaci nikdy nedojde. Současně, pokud vám skutečně jde o to, aby IDEA byla lepším nástrojem (děláte to konec konců kvůli sobě, že jo), je trochu frustrující s lidmi s JetBrains v bug trackeru diskutovat – je tam hodně cítit vývojářský mindset, který se na problém dívá pohledem “půjde to nějak rychle udělat?”, resp. “dokud má bug nějaký workaround, není to bug”. O nějakých větších změnách není moc ochota diskutovat.

IDEA je jako vlak v módu “nezastavujeme, máme zpoždění”, který neskutečným tempem valí nové verze, fičury, podporu nových jazyků, testovacích frameworků atd. atd., ale nikdy není čas zastavit a opravit něco na podvozku, co se kdysi dávno nenavrhlo úplně dobře. IDEA působí jako nástroj, na kterém maká tlupa vývojářů, kteří procházejí YouTrack a fixují jednotlivé bugy / tasky. Koncepčnost toho IDE není cítit, stejně jako bych si tipnul, že nemají moc velké QA – prostě verzi vydají, a když tam je nějaký problém, v příští setinkové verzi to bude fixnuté. Toto má své ohromné výhody i nevýhody, a tipnul bych si, že se to JetBrains vyplácí, ale občas tím teda docela trpím. Ve Flash Builderu když Adobe řeklo, že tam je nějaká fičura, tak ta věc prostě fungovala. V IDEE je to spíš takový příslib, který je naplněn, když má člověk štěstí. Když ho nemá, musí doufat, že je jeho problém dostatečně malý na to, aby byl fixnut v příštím (brzkém) releasu.

Ve výsledku jsem tak přešel zpět na Flash Builder, respektive používám ho na takové to běžné programování, zatímco IDEU startuji ve chvíli, kdy mám na stole nový projekt plný “zajímavého” (špatného) kódu a potřebuji se v něm vyznat. IDEA je chytrá, ale na mě moc kovbojská.

Na konci pohovoru pak ale nemáte dost informací o tom, jestli se vám v práci bude líbit a projekty vás budou bavit. Kolik znáte vývojářů nebo dizajnérů, kteří někde pracovali méně než rok? Méně než 9 měsíců? Vsadím se, že jich bude dost.

Připravil jsem pro vás několik otázek, které byste se měli zeptat předtím, než se rozhodnete zavázat podstatnou část vašeho života některé firmě.

1) Jak vyvíjíte software? Říkáte o sobě, že jste “lean”, “agile” nebo “scrum”?

Tohle může samo o sobě rozhodnout o přijetí nebo odmítnutí nabídky. Pokud pracovní procesy ještě nebyly alespoň trochu formalizované, tak se může stát, že nastoupíte na pozici, kde vaším hlavním úkolem bude řízení chaosu. To, že si společnost myslí, že dělají “lean” nebo “agile”, může znamenat že vkročíte do rozumně nastaveného procesu. Taky to ale může znamenat, že strávíte polovinu vašeho času na schůzích, kde se pomocí balíčků karet přiřazují problémům náhodné odhady časové náročnosti.

Není tedy důležité, co přesně vám odpoví. Jde o to, aby už bylo učiněno vědomé rozhodnutí, jak má být vývoj organizovaný, a aby vám tento vybraný způsob přišel smysluplný. Pokud při popisu zní příliš mnoho buzzwords, tak zvyšte ostražitost.

2) Jak spolupracují dizajnéři s vývojáři?

Hážou dizajnéři návrhy stránek a obrazovek přes zeď jako nařízení, co a jak musí vypadat, nebo existuje prostor pro spolupráci a iterování? Má váš budoucí zaměstnavatel vůbec nějaké dizajnéry?

Vývojáři navrhující uživatelské rozhraní jsou téměř určitě znamením, že uživatelská přítulnost není pro firmu důležitá a většina produktů je nejspíš k ničemu. Pokud narazíte na hodně dobrého produkťáka se smyslem pro dizajn, tak můžete mít štěstí, ale jinak většinou každý střílí od boku a na výsledném produktu to je znát.

3) Jakou úroveň má automatizované testování? Průběžná integrace (Continuous Integration)?

Automatizované testování může být super. Já sám používám automatizované jednotkové/integrační/akceptační testy pro všechny produkty, které vyvíjím. Tyto testy tvarují rozhraní a dělají kód udržovatelným v dlouhodobém horizontu. Můžete však narazit na extrémisty z obou protipólů.

1. My nemáme testy.

   Odejděte. Jinak vás čeká ošklivé setkání s miliónem řádků kódu, kde jenom původní autoři měli šanci dělat změny a nerozbít při tom produkt. Vina za zavlečení chyb však padne na vás.

2. Náš kód má 100% pokrytí testy

   Kecy. Anebo většina testů kontroluje volání privátních metod, nic neověřuje, případně aplikuje jiné fígle na dosažení 100% pokrytí testy. Pokus o libovolnou změnu v aplikaci buďto rozbije všechny testy anebo nerozbije nic. Oba výsledky jsou nebezpečné. A vina za rozbití testů padne samozřejmě na vás.

4) Na čem *přesně* budu pracovat? Jaký je váš tech stack?

Pracovní nabídky jsou notoricky známé tím, že neříkají pravdu, aby přitáhli zájem vývojářů. Často se stává, že ve firmě je jeden člověk, který má jako koníček technologii X, takže ji uvede v popisu pozice i když s ní vůbec nesouvisí. Například:

“Požadujeme zkušenosti s Ruby on Rails, vývojem pro iOS, HTML5 a Node.js…, znalost Perlu je výhodou.”

Ve skutečnosti to znamená:

“Většinu času budete udržovat serverovou aplikaci o dvou miliónech řádků Perlu. Chci to všechno přepsat do Rails a líbí se mi iOS, ale to vlastně nikdy nebudeme dělat.”

5) Jakou velikost mají vaše týmy? Jak velký bude můj tým?

Horu Fuji se vám nepovede přesunout, ať jste sebevíc chytřejší. Pokud jsou velikosti týmů malé a počet týmů není vysoký, tak je poměrně velká šance, že můžete přednést rozumné argumenty a opravit problémy v organizaci vývoje nebo uvnitř týmu. Ve velké organizaci narazíte na struktury optimalizované pro blokování změn. Změny jsou děsivé a doteď jsme byli svým způsobem úspěšní i se současným procesem a 100/200/1000 lidmi. Proč bychom měli potřebovat cokoliv měnit? Vy jste jediný, kdo vybočuje z normálu, takže tím problémem jste vy sám. V menším týmu nemůžete výrazně vybočovat z normálu, protože normál je z velké části definován taky vámi.

6) Je možnost pracovat vzdáleně (z domu)?

Nemusíte ani chtít pracovat vzdáleně, nebo pracovat vzdáleně podstatnou část času. Přesto tuto otázku položte.

Proč? Tohle je přímý ukazatel toho, jestli zaměstnavatel požaduje pracovní výsledky nebo živé těla na židlích. Doopravdy chcete pracovat tam, kde zaměstnanec trávící v kanceláři deset hodin denně (většinou brouzdáním internetu a zbytečným schůzováním) je ceněn více, než člověk produkující 2-10x víc než on? Jasně že ne. Některé odvětví mají podivné legislativní důvody pro to, aby vyžadovali přítomnost všech na pracovišti, takže to je jedno z možných ospravedlnění pro zákaz práce na dálku. Ve velké většině případů však platí, “každý musí být v kanceláři” === “záleží nám víc na přítomnosti v práci než na výsledcích”.

7) Máte základní pracovní dobu?

Pokud je pozice ze po všech stránkách perfektní, ale nenechává vám prosto vyzvednout děti, zajít si do posilovny nebo navštěvovat každý týden čtenářský kroužek, bude to pro vás fungovat? Pravděpodobně ne. Pokud jednáte se zákazníky, potřeba pokrýt určitý časový úsek není nepřiměřená, ale pořád je možné mít pružné pravidla pro základní pracovní dobu. Přísné lpění na základní pracovní době může znamenat, že většina pracovních procesů je synchronních (místo asynchronních), což striktně omezí vaši schopnost udělat vaši práci. Zkuste tady víc vyzvídat a zjistěte si, proč přesně firma vyžaduje základní pracovní dobu a co to o ní vypovídá.

8) Proč nabíráte nové lidi? Jedná se o nový produkt? Růst? Náhradu za někoho, kdo nedávno odešel?

Vysoká fluktuací poukazuje na to, že v organizaci je něco špatně. Může to být špatné finanční ohodnocení, nerovnováha mezi pracovním a soukromým životem, jedovatá firemní kultura, atd. Jestli někdo odešel, zjistěte proč. Pokud společnost roste, tak se vám můžete stát, že nastoupíte do firmy se sto zaměstnanci, o které jste si mysleli, že jich má jenom dvacet.

9) Jakou nejzajímavější věc jste tady vy osobně vytvořil(a)?

Rád pracuji na produktech, které se dostanou k zákazníkům. Některé společnosti ne. Zjistěte si, jaký byl poslední úspěšný produkt, na kterém pracoval člověk vedoucí pohovor, a kdy se dostal do rukou zákazníkům. Řekne vám to, jestli firma dodává po malých přírůstcích nebo alokuje obrovské rozpočty na projekty, které selžou. Na kolika projektech, které se nikdy nedostali k zákazníkům, jste pracovali vy? Jak jste se cítili, když byl projekt ukončen?

Dotazem na nejzajímavější věc se dozvíte, jestli jsou zaměstnanci hrdí na svoji práci. Programátor nebo dizajnér se rád rozpovídá, pokud vytvořil něco alespoň trochu zajímavého, co se líbilo zákazníkovi. Ten samý pocit hrdosti chcete nejspíš prožívat taky.

Dejte si pozor na “Napsal jsem interní nástroj, který…” nebo “Přepsal jsem open-source nástroj, protože…”. Někteří vývojáři si rádi honí ego znovu-vynalézaním kola a mrháním firemních peněz na projekty, které nejsou úplně potřebné nebo užitečné pro firmu jako celek. Pokud má někdo pocit, že potřebuje přepsat kompilátor, tak je pravděpodobně blázen a téměř určitě na omylu.

10) Co byste si přál vědět o vašem zaměstnavateli předtím, než jste sem nastoupil? Jaké jsou nejhorší stránky této práce?

Žádná organizace není ideální, všude jsou nějaké problémy. Přestaňte si nalhávat, že existuje dokonalý zaměstnavatel — neexistuje.

V dobré společnosti se lidi vedoucí pohovor nebudou bát být úpřimný a mluvit o špatných stránkách. Když se někdo nebojí poukázat na problém, pak tento problém může být vyřešen. Žádný vztah, společnost nebo produkt není dokonalý. Přístup k řešení problémů definuje, jestli vás chození do práce bude ubíjet nebo povzbuzovat. “Dnes se musím zase zabývat X. Posraný život.” nebo “Dnes můžu zkusit opravit X. Dnes je den, kdy tento problém vyřešíme navždy.”

Ve špatné společnosti vám řeknou “Mojí největší slabostí je příliš silný perfekcionizmus”. Tohle jsou možnosti:

1. Člověk, který vede pohovor, vám lže, aby vás navnadil přijmout nabídku. Vědí, že změna práce je velice nákladná a nepříjemná, takže počítají s tím, že u nich po nástupu uvíznete.
2. Člověk, který vede pohovor, se bojí být úpřimný. Našli jste kulturu mlčení, a měli byste být radši připraveni sklonit hlavu a ignorovat problémy.
3. Poslední možností je ta, že dotyčný uvěřil hezkému obrázku prezentovaného firmou. Je to stejně špatné jako lhaní, jenom si neuvědomují, že lžou. Jestliže povinný 80-hodinový pracovní týden nepřijde nikomu jako problém, tak radši odejděte. Jinak se sami stanete obětí vymývaní mozků, anebo budete spolupracovat s lidmi, kteří si neuvědomují problémy kolem sebe.

Ne všechny společnosti jsou špatné, je však důležité vědět, do čeho jdete. Náš čas na této planetě je omezený, a vy ho nechcete promrhat kopáním jámy se skloněnou hlavou.

Závěrem

Jaké jsou vaše oblíbené otázky při hledání práce? Podělte se o ně v komentářích.

Pokud vás zajímá problematika hledání práce, přečtěte si taky jak si najít práci v zahraničí.

Tento příspěvek je volným překladem z anglického originálu 10 questions to ask your potential employer, který publikoval Stefan Kendall.

SSL, TLS, HTTPS

Na úvod začněme stručnou rekapitulací protokolů pro zabezpečení spojení mezi klientem a serverem.

• SSL je zkratkou pro Secure Socket Layer. Protokol byl vytvořený v polovině devadesátých let společností Netscape, poměrně brzo byl nahrazený TLS.
• TLS označuje Transport Security Layer. Jedná se o standard udržovaný organizací IETF, který odstraňuje nedostatky a bezpečnostní slabiny protokolu SSL.
• Oba protokoly SSL a TLS fungují na úrovni TCP sockets, poskytují prostředky k převedení otevřeného toku (plaintext stream) na plně šifrovaný kanál.
• HTTS, nebo-li HTTP Secure, je kombinací HTTP protokolu komunikujícím přes SSL nebo TLS kanál.

Znovupoužití TLS Session

Založení nového zabezpečeného kanálu vyžaduje dvě kolečka mezi klientem a serverem. Navíc klient i server musí vykonat výpočetně náročné kryptografické operace, které jsou potřebné pro vytvoření sdíleného tajného klíče, který se dál používá pro šifrování dat.

Znovupoužití session funguje na principu opětovného využití stejné konfigurace, která byla použita pro předchozí spojení. Ušetří nám jedno kolečko a umožní vynechat drahou přípravu kryptografických parametrů. Tento mechanizmus je jedním z nejdůležitějších způsobů jak zvýšit výkonnost SSL/TLS komunikace.

Poznámka: pozor na záměnu pojmu TLS session se session používanou ve webových aplikacích pro zachování stavu mezi dotazy. Jedná se o dva různé a nesouvisející koncepty.

Jsou dva způsoby jak znovu použít TLS session:

• Identifikátor session (Session Identifier) je součástí SSL i TLS standardů a měl by být podporován všemi implementacemi. Od TLS serveru se vyžaduje, aby si udržoval seznam všech platných session, a pak na základě identifikátoru prezentovaném klientem byl schopen nastavit (obnovit) příslušné parametry spojení. Jak uvidíme později, tento požadavek znamená pro Node.js servery práci navíc.
• Session lístek (Session Ticket) je rozšířením protokolu TLS, které umožňuje zakódovat všechny potřebné údaje do jednoho lístku (ticketu), čímž řeší problém sdílení platných session mezi servery v distribuovaném prostředí. Když se klient představí serveru se správným lístkem, server dokáže obnovit session aniž by se musel podívat do externí keše platných session. Toto rozšíření zatím není implementováno ve všech TLS klientech. Klienti podporující session tickets jsou prohlížeče Google Chrome a Mozilla Firefox, knihovny openssl and gnutls. Prohlížeče Internet Explorer a Safari tuto funkcionalitu zatím nepodporují.

Podrobnější informace lze nalézt ve výborném článku (v angličtině).

Konfigurace Node.js serveru pro znovupoužití session

Znovupoužití session přes session ticket funguje samo, implementace je z pohledu vašeho kódu úplně transparentní a při běhu v jednom procesu funguje bezvadně. Když dojde na nativní cluster, chyba #5871 ve verzi v0.10 znamená, že procesy v clusteru neakceptují lístky vydané sousedními procesy. Protože však rozdělení požadavků mezi procesy není ve verzi v0.10 rovnoměrné (většina spojení skončí u jednoho nebo dvou nejvytíženějších procesů), dopad tohoto problému by neměl být příliš velký. Chyba je opravena ve verzi v0.11.

Znovupoužití session přes session identifikátory vyžaduje, aby vaše aplikace implementovala úložiště platných session (session store) a obsloužila události newSession a resumeSession. Následující kód demonstruje možnou implementaci pro TLS server běžící v jednom procesu. Poznamenejme, že HTTPS server je potomkem TLS serveru, takže stejný mechanizmus lze použít pro nastavení HTTP serveru.

var tls = require('tls');

var tlsSessionStore = {};
// TODO - implement removal of expired sessions

var opts = { /* configure certificates, etc. */ };
var server = tls.createServer(opts, tlsConnectionHandler);

server.on('newSession', function(id, data) {
  tlsSessionStore[id] = data;
});
server.on('resumeSession', function(id, cb) {
  cb(null, tlsSessionStore[id] || null);
});

server.listen(4433);

Když provozujeme cluster z vícero procesů, potřebujeme sdílet úložiště session mezi všemi procesy. Nejjednodušší řešení je použít balíček strong-cluster-tls-store, který je postavený nad posíláním zpráv mezi hlavním procesem a pracovními procesy a nevyžaduje tak žádné externí služby typu Redis. Podívejme se, jak nakonfigurovat HTTPS v Express aplikaci bežící v clusteru.

var https = require('https');
var express = require('express');
var shareTlsSessions = require('strong-cluster-tls-store');

if (cluster.isMaster) {
  // Setup your master and fork workers.
} else {
  // Start the server and configure TLS sessions sharing

  var app = express();
  // configure the app

  var httpsOpts = { /* configure certificates, etc. */ }
  var server = https.createServer(httpsOpts, app);
  shareTlsSessions(server);

  server.listen(port);
  // etc.
}

Tož to bylo jednoduché, že?

Malé upozornění: současná stabilní verze Node (v0.10) obsahuje chybu, kdy server vyvolá událost resumeSession i v případě, kdy session bude obnovena ze session lístku (#5872). To znamená, že zavedení sdíleného úložiště nejspíš zpomalí proces obnovení session. V závislosti na tom, jak velká část vašich klientů podporuje a nepodporuje TLS session lístky, se může stát, že lepším řešením bude vůbec nepoužívat sdílené úložiště.

Doporučuji, abyste sledovali výkon vaší aplikace a zjistili sami, jestli použití sdíleného úložiště pro TLS sessions přinese zrychlení. Pokud hledáte šikovný monitorovací nástroj, můžete vyzkoušet StrongOps (donedávna NodeFly).

Ověření konfigurace

Když máme správně nakonfigurovanou aplikaci, pojďme ověřit, že server skutečně umožní znovupoužití té samé session. Použijeme k tomu nástroj z balíčku openssl, který je součástí Mac OS X a taky většiny Linuxových distribucí. Ukázky předpokládají, že TLS nebo HTTPS server běží a poslouchá na portu 3000.

Poznámka: verze openssl dodávána s Mac OS X je snad ještě z minulého století a nefunguje moc dobře s verzí používanou v Node. Před provedením následujícího testu by bylo vhodné povýšit na aktuální verzi, například nainstalováním balíčku z homebrew.

1. Zkontrolujte verzi openssl, potřebujeme alespoň 1.0

   $ openssl version
   OpenSSL 1.0.1e 11 Feb 2013
   

2. Navážeme několik spojení se znovupoužitím té samé TLS session. Test ukončíme klávesovou zkratkou Ctrl+C.

   $ openssl s_client  -reconnect -port 3000 2>&1 \
   | grep "^\(New\|Reused\)"
   New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   ^C
   

3. Zopakujeme ten samý test, ale zakážeme klientovi používat TLS session ticket.

   $ openssl s_client  -reconnect -port 3000 2>&1 -no_ticket \
   | grep "^\(New\|Reused\)"
   New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   Reused, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
   ^C
   

Z obou výstupů je vidět, že první spojení vytvořilo novou session a následujících pět spojení tuto session znovu použilo.

Závěrem

Tento článek je překladem anglického originálu, který vyšel na firemním blogu StrongLoop. Podívejte se taky na infografiku o stavu Node.js nebo video Node.js je tady!, ve kterém dva hlavní vývojáři Node.js vysvětlují naši misi zjednodušit vývoj mobilních aplikací pro Enterprise.

Pokud jste o IdeaPaintu nikdy neslyšeli, je to speciální barva, kterou natřete na zeď, a až zaschne, má se podle výrobce chovat jako běžná bílá tabule. Na natřený povrch (který ani nemusí být nutně zdí) lze psát lihovými fixkami, mazat vše hadrem, neměly by zůstávat žádné “stíny” a podobně. Tolik teorie, dokonce mi výrobce poslal vzorek (brožurku), kde je barva natřená na jednom silnějším listu papíru, aby si člověk všechno mohl vyzkoušet nanečisto před koupí. Barva mě nadchla a IdeaPaint jsem objednal (objednává se z Dánska, v ČR zatím distribuce není).

Takhle nějak vypadá balení IdeaPaintu. Pojmenování plechovek “THIS” and “THAT” následované instrukcí “put THIS into THAT” je milé, ostatně není špatná strategie zákazníka před samotnou prací trochu poveselit, viz dále.

O několik dní později. IdeaPaint na stěně pracovny.

A teď ta realita.

Jelikož je IdeaPaint barva, musí se natřít (thxcaptobvious). Na instruktážním videu to vypadá jednoduše, ale v reálu to byl docela porod. Jasně, je potřeba říct, že jsem jeden z manuálně nejnešikovnějších lidí, jaké můžete potkat, ale ten proces fakt nebyla sranda. IdeaPaint jsem aplikoval na stěnu, která je v základu sádrokartonová a tedy poměrně dost hladká, přesto je potřeba takovou stěnu:

1. Obrousit
2. Natřít základovou barvou
3. Natřít IdeaPaintem
4. Nechat uschnout

Každý z těch bodů je nějakým způsobem nepohodlný – broušení v už vybavené pracovně znamenalo prach úplně všude (přes různé igelity), pokud nejste zkušený malíř bytů, u natírání budete pokaždé váhat, jestli tam náhodou nemáte barvy málo (nezakryje drobné nerovnosti) nebo naopak moc (v příliš tlusté vrstvě se vytvoří nerovnosti nové), dodaný váleček navíc neseděl na české násady, takže jsem to dělal nějakým koupeným v OBI, který možná neměl správnou “jemnost”. Konečný nátěr IdeaPaintu pak opravdu hodně smrdí, takže se v místnosti nedá minimálně den až dva vůbec být. A nic si nepostříkejte – ta barva je z principu velmi, velmi odolná, moje dveře a podlaha mají vzpomínku doposud.

Proces nátěru tedy na menší dovolenou, ale dalo by se to přežít, kdyby aspoň výsledek byl nějak unikátní. V mém případě to ale nedopadlo nic moc – stěna sice účel plní, ale povrch je plný drobných pórů, které komplikují psaní a hlavně pak následné stírání. Je to nejspíš moje chyba, možná jsem nenanášel různé vrstvy dobře, možná vadil český váleček místo originálního, možná jsou některé větší “póry” důsledkem nedobrého zasádrování zdi sádrokartonářema, kdo ví. Každopádně já už bych do IdeaPaintu nešel, resp. výsledek si cením tak na třetinu až polovinu ceny, za kterou jsem IdeaPaint koupil (včetně poštovného to bylo, tuším, nějakých 6-7 tisíc Kč za o něco víc než 2 metry čtvereční). Respektive bych asi bral, kdyby to stálo stejně, ale v ceně byla i “instalace”, tj. že by mi to přijeli natřít a výsledek by byl perfektní. V ČR dnes bohužel nereálné.

Jaké jsou alternativy? Pokud máte dost místa na zdi a taky dost peněz, velké bílé tabule jsou podle mého stále tím nejlepším, co se dá pořídit. Pokud holdujete kutilství, můžete ještě zkusit tabule nahradit jinými podobnými materiály, prý např. dobře fungují bílé pláty, ze kterých se dělají vany nebo sprchové kouty, nebo plexisklo a podobně.

Já ale kutím nerad, tak jsem pořídil Magic Whiteboard a jsem s tím dost spokojený. Za zhruba tisícovku máte mnoho metrů čtverečních plochy, které si můžete dát v podstatě kamkoliv (na zeď, na dveře, na okno, …), instalace je hračka, mazat se to dá (ač šmouhy trochu zůstávají) a celkově to za ty peníze odvede ohromnou službu.

Magic whiteboard. O dost horší povrch, ale zato výrazně levnější a instalace o galaxie jednodušší. Nám v Agiliu stačí.

Pokud tedy potřebujete nějakou vertikální čmárací plochu a máte ji jen jako občas používaný doplněk, IdeaPaint a podobné věci mi připadají trochu jako předčasná optimalizace. Začněte levným magickým papírem a uvidíte, přejít na lepší se dá vždycky.