úterý 18. srpna 2015

A case against polyglot programming

We have been doing polyglot programming at GoodData even before Micro services get traction and honestly it was probably one of the biggest mistake we ever did. At the beginning (2008) our platform was simple LAMP stack with REST interface and bunch of JavaScript. We have been adding more and more languages as we followed a golden rule use right tool for right job. We add Erlang because what language to use for a distributed system. We add C++ because what language to use for fine tuned computations. Since 2008 our stack was getting bigger and bigger - Perl, Java, JavaScript, Erlang, C++, Python, Ruby. In such heterogenous environment was critical to encapsulate every service/component with an API in order to keep interoperability. All our services expose a REST API so programming language is an implementation detail of them. Someone could appreciate such diversity, but from my 5 year experience it’s a nightmare.

First of all, once you start developing features spanning more than one service you need a team with experts in more than one or two languages. It’s absolutely ok to use one language for backend (pick your favorite) and one for fronted (JavaScript rule them all), but setup a team with Java, Perl, Erlang, JavaScript developers is complicated. You need more than one developer for every language because of redundancy. Those developers are mostly experts in one language meaning you can train them for other languages, but it takes a lot of time and money. Developers have to see the given language and not only language but also the whole ecosystem as a career opportunity. You not need a newbie who learn HelloWorld, but someone who is able produce production ready code. You can hire them if they are available and you have enough time goes through gazillion of CVs, interviews and not counting their boot time to domain problems your company tries to solve. It’s not a technical choice, but more a people/culture choice.

Second, what polyglot programming really offers? It’s worth to see 50 lines of Java code can be reduced 10 lines of Clojure code but for what. At least at the backend most of the code do nothing more than run few or more SQL queries, transform result to XML or JSON. Do we really need different programming languages for that? I doubt and you should too. Most of the programming tasks can be accomplished in single language without loosing any comfort and productivity because of existing frameworks, tools or libraries. I don’t think we should use one language for everything, but using different languages even sexy languages for very similar use cases is waste of time and resource.

pátek 14. srpna 2015

CZ Podcast 121 - Czechitas holčičí emancipace v IT

Do dalšího dílu jsme nepozvali jednoho hosta, ale hosty rovnou dva, Zuzanu Dostálovou a Ditu Přikrylovou z projektu Czechitas, který se velmi úspěšně snaží o ženskou emancipaci v IT. Povídání to bylo jako vždy zajímavé a plné energie a nám nezbývá než smeknout klobouk před tím co holky dělají a jak se jim daří. Sympaticky to působí i ve světle toho, že na to není potřeba evropských dotací z rozvojových fondů pro genderovou vyváženost a podobných nesmyslů.

úterý 11. srpna 2015

Proč je důležité dělat nedůležité

Hrajete počítačové hry? Všiml jsem si, že plno složitějších problémů nebo úkolů řeším, jako kdybych hrál počítačovou hru. Velmi mi to připomíná hraní her na hrdiny (RPG). Teď nemám na mysli to, že bych byl hrdina. Ostatně můžete kolikrát hrát za stranu padouchů a svůj herní charakter rozvinout jak kladně, tak i záporně. Při hraní RPG her, máte obvykle jeden hlavní úkol, ke kterému celé vaše snažení směřuje. Hru můžete odehrát tím způsobem, že plníte nejnutnější minimum, které je potřeba k splnění tohoto úkolu. Druhým způsobem, jak tyhle hry hrát, je prozkoumávání celého herního světa s tím, že plníte podružné úkoly nebo se jenom tak flákáte kolem a zkoumáte.

Já mám ten druhý způsob hraní hrozně rád. Nikdy nevíte, koho ve hře potkáte, co uděláte a kam vás to posune. Můžete narazit na lepší vybavení, vyrubat nějaké nepřátele a tím získat zkušenosti nebo rozplete kus příběhu, který vám pomůže lépe se zorientovat. Zkušenosti vaší postavy jsou důležité, protože díky nim můžete rozvíjet jednotlivé atributy herního charakteru (odolnost, zdraví, sílu, obratnost atd.)

Práce na nějakém složitějším problému je pro mě jako nová hra. Přirovnal bych to k průchodu nějakého dungeonu. Vidím vstup, vím kam se potřebuji dostat a jenom nevím přesně kudy a co tam na mě číhá. V tom dungeonu rád prozkoumávám jeho zákoutí, protože nevím, kde se dá co objevit a co mě posune dál. Mohl bych jít rovnou za nosem, ale nebyla by to taková zábava a dovedl by mě k cíli? Žádná cesta totiž není slepá dokud jí neprojdete. I v tom dungeonu děláte nebo lépe řečeno můžete dělat věci a plnit úkoly, které jsou nedůležité. Získáte tím zkušenosti, které se vám hodí při plnění hlavního úkolu.

Pokud zrovna programuji nebo navrhuji, nikdy nesleduji jenom hlavní úkol. Často dělám refaktoring, a snažím se kód dost zobecňovat, připravovat si různé nástroje a mikro frameworky, protože mám pocit, že se mi to bude v budoucnu hodit. Někdy se to skutečně hodí, ale dost často to prostě k ničemu není a já musím ten kód, nápad, návrh vyhodit nebo upravit, protože budoucnost je jiná než jsem si jí projektoval v hlavě. Je to způsob, kterým si ověřuji vlastní hypotézy a získávám další zkušenosti a lepší porozumění danému problému. Podobně jako bych v dungeonu vylepšoval sečné zbraně mojí postavy, abych posléze zjistil, že na nový typ nadpřirozených nepřátel jsou k ničemu.

Lidé jsou často svázaní představou, že by měli dělat jenom to důležité, co je dovede k řešení daného úkolu. Jenomže co je důležité? Dokážeme rozeznat důležité od nedůležitého? Retrospektivně viděno to dokážeme posoudit. Všechno co nás neposunulo ani o píď blíže k cíli bylo v uvozovkách zbytečné. Měli bychom si uvědomit, že podobně jako při hraní her je důležité dělat nedůležité a to přesně kvůli těm samým důvodům - jsou to zkušenosti, je to zábava a nikdy nevíte, jestli je cesta slepá dokud jí neprošlápnete. Vzpomeňte si na to, až si budete trápit mysl tím, že zrovna děláte něco nedůležitého.


úterý 4. srpna 2015

Neučme se z úspěchu

Deset rad, jak se z vás stane lepší programátor. Deset rad, jak vést firmu jako Steve Jobs. Deset rad, pomocí kterých zaručeně sbalíte holku. Deset rad, jak uspět s vaším startupem. Všechno s razítkem zaručené a nejlépe podpořené nějakou ikonickou značkou. Určitě jste narazili na přehršel podobných článků, které se vám snaží v kostce představit tu méně tu více osvědčené rady. Úspěšné příklady táhnou. Ve většině případů mají ovšem tyto rady malou cenu a já osobně takové články nečtu.

Nejde o to, že by se člověk neměl inspirovat úspěchem někoho jiného, ale bohužel to co vedlo k úspěchu jednomu, nebude s velkou pravděpodobností fungovat někomu jinému. Každý úspěch, respektive cesta k němu je unikátní, a pokud budete dělat totéž, nemáte rozhodně zaručeno, že dosáhnete stejného výsledku.

Problém rad postavených vydistilovaných z úspěšných příběhů spočívá v tom, že jsou vytržené z kontextu. Nebo lépe řečeno kontextově specifické. Když teď půjdete a založíte si internetový obchod se vším, těžko se z vás stane nový Amazon. A můžete si přečíst tisíc a jeden článek o tom, co děla Steve Bazos. Každý úspěšný příběh je zasazený do reálií, které bývají jedinečné. Možná se vám to nebude líbit, ale musím vás upozornit na to, že budete potřebovat i štěstí. Ať už si pod štěstím představíte cokoliv. Počínaje načasováním, kolegy, příznivou situací na burze atd. Štěstí hraje možná větší roli, než by se vám mohlo líbit.

Myslím, že jsem to poprvé četl v knize Why we fail, je důležité studovat úspěch, ale mnohem důležitější je studovat neúspěch, protože ten bývá méně kontextově závislý. Chyby jsou universálně přenosné a ve všech těch selháních a neúspěších člověk dokáže identifikovat společné vzory. Bohužel nebo bohudík jsme tak geneticky naprogramování, že se snažíme hledat vzory v tom co fungovalo. Úspěch táhne a motivuje, z neúspěchu se člověk učí.