Jak píšu Palivovník?

Palivovník jsme si představili a teď je na čase napsat něco pro ty z vás kolegů vývojářů, kterým v hlavě zní ono slavné “v čem je to napsané?!” :)

První nápad napsat podobnou aplikaci se mi zrodil v hlavě asi před dvěma lety. Sice jsem už tehdy prakticky koketoval s Clojure, ale postavit na tom aplikaci jsem si netroufnul, takže první nástřel jsem začal psát s pomocí Neo4J, Springu a JSF 2. Z různých důvodů, z nichž si pamatuju asi jen svojí přirozenou “projektovou promiskuitu”, se tohle moc nerozvinulo — alespoň pokud můžu soudit podle toho, na co se teď koukám na disku :) Čas šel dál, dělal jsem všecho možné a na všem možném, ale ideu Palivovníku jsem měl pořád někde vzadu v hlavě. A tak jednoho dne, když už jsem byl dostatečně zamilován do Clojure a věděl jsem, že už můžu risknout v tom psát něco víc než malé podpůrné moduly, rozhodl jsem se projekt oživit. Než jsem se dostal do releasovatelné fáze, uběho samozřejmě hodně času, protože jsem se - jak je mým zvykem - věnoval všemu možnému. Pokusím se teď popsat stěžejní technologie, na kterých Palivovník běží — pěkně odspoda nahoru.

Neo4J

Vše kromě údajů o tankování je uloženo v grafové databázi Neo4J. Praktičnost, s jakou grafové databáze pomáhají vyjádřit (a pak opět číst) informace o propojeném světě, mě fascinuje. Uživatelé, auta, značky, motory… vše je spolu spojeno vztahy, které se dají nějak vyjádřit a pevně věřím, že pokud se projekt malinko rozjede, bude velmi zajímavé sledovat, co za síť se v tomto grafu uvaří.

MongoDB

Světem vývoje SW milovaná nebo nenáviděná. I vztah tohoto projektu a Monga byl z počátku docela turbulentní. Měl jsem totiž jakousi (z mého dnešního pohledu zcela špatnou) touhu projekt nepřekombinovat a použít pouze jednu databázi. Pořád jsem si říkal, že cpát tam více než jednu DB je neobhajitelné hračičkovství, ale čím dál jsem nad typy dat uvažoval, bylo mi jasné, že pokud si chci zachovat flexibilitu (hlavně co do budoucího dolování dat), nějaké kombinaci se prostě nevyhnu.

Mongo tedy ukládá všechna tankování a také odvádí část výpočtů potřebných pro statistiky (část je přímo v Clojure, kde je to nesrovnatelně příjemnější psát). Důvody, proč jsem ho použil:

  • hotová a zadarmózní podpora na OpenShiftu, kde aplikace běží
  • schopnost uložit tankování i s jednotlivými fázemi jako jeden dokument
  • schopný agregační framework a podpora MapReduce (to první již aktivně používám, druhé možná přijde vhod)
  • podpora pro geo data (u každého tankování lze zadat adresu)
  • kvalitní a prověřená knihovna pro Clojure od kluků z ClojureWerkz
  • velká komunita, dostupnost informací a znalostí

Asi by mě docela bavilo místo Monga nasadit můj oblíbený Riak, ale to už by skutečně hračičkovství bylo — minimálně v téhle fázi :)

Clojure

Celý server je napsán v jazyce Clojure, který asi netřeba nikomu představovat. Zkušenost s dlouhodobým vývojem v tomto jazyce lze asi nejlépe popsat anglickým slovem eyeopener. Způsob, jakým mi tenhle znovuzrozený funkcionální Lisp neleze do cesty, jak mě nechává soustředit se na problém místo na programovací jazyk, je bezprecedentní — tedy pro mě byl, když jsem se do toho ponořil. Prostě data-driven no-bullshit get-the-thing-done platforma. Zapomněl jsem na nějaký buzzword?

Konkrétněji jsou použity knihovny Compojure, lib-noir, Enlive, Monger, Neocons a Midje na testy. Je tam samozřejmě pár dalších drobků, ale všechno to vypisovat nemá smysl.

CoffeeScript

V Coffee se mi píše docela dobře, je to takové trochu zenovější psaní než v JS. Jeho třídnímu objektovému modelu se vyhýbám a používám CS spíš jen jako syntaktický cukr, abych se z JS nezcvoknul a aby se na to dalo koukat :)

AngularJS

Vím, teď je nejvíc kůl React (a je!), ale když jsem s projektem začínal, tak fakt nebyl :) Angular je dobrá konzervativní volba pro trošku komplexnější věci na klientovi, kde nestačí to pobastlit v jQuery. Doplňuje ho tedy jQuery, Promise.js a Moment.js na práci s datumy a časy.

Graf na dashboardu dělá C3.js, což je moc povedená knihovna hotových grafů nad slavnou dé trojkou. Je dost možné, že v budoucnu se nevynu práci přímo s D3 — na to jsem zvědav.

Víc už mě asi nenapadá. Pokud vás zajímá něco víc, ptejte se!

Chtěl bych vám představit Palivovník

If you are not embarrassed by the first version of your product, you’ve launched too late.

S tímto citátem Reida Hoffmana (spoluzakladatel sítě LinkedIn) na rtech bych vám chtěl představit jednu malou aplikaci: Palivovník.

Není to žádný pokus o startup, je to prostě něco, co mi chybělo a tak jsem si to napsal. Jde o aplikaci na zaznamenávání tankování paliva do vašeho auta a sledování vývoje průměrné spotřeby a dalších statistik.

Jak se Palivovník liší od ostatních služeb na trhu?

  1. Hlavní důvod, proč jsem se rozhodl si takovou aplikaci napsat sám, byla potřeba vést záznamy o tankováních, při nichž šel do nádrže více než jeden druh paliva - typicky benzín a E85. Už mě nebavilo si nejdřív něco počítat na kalkulačce a pak to zadávat někde na webu jako jedno palivo — přirozeně se ztrátou informace. Palivovník tedy umožňuje ke každému tankování zadat libovolný počet fází. To v budoucnu umožní hlavně výpočty statistik závislých třeba na podílu konkrétního paliva na provozu auta.

  2. Chtěl jsem něco, co bude vizuálně a graficky absolutně primitivní a čisté. Nejsem grafik ani “UXák”, takže nečekejte nějaké minimalistické grafické orgie — prostě jsem se snažil, aby aplikace dělala co má a nelezla do cesty. U konkurenčních webů jsem vždy měl jakýsi pocit přeplácanosti.

  3. Chtěl bych něco, co se do budoucna bude chovat trochu jako sociální síť. Nějaké nápady mám a Twitter nebo Fejsbůk z toho určitě dělat nechci :)

  4. Potřeboval jsem se jako programátor vyblbnout :) Jak konkrétně? Čtěte v blogpostu nazvaném Jak píšu Palivovník?.

Pokud je tohle něco, co byste rádi používali, buďte vítáni. Teď ze začátku je pro mě hlavně důležitá zpětná vazba — co nefunguje, co nedává smysl, co vám chybí, co je tam navíc… jakákoliv konstruktivní kritika mě zajímá. Můžete využít buď ikonku otazníku v pravém dolním rohu na každé stránce Palivovníku a nebo přímo zde.

On Clojure High Performance Programming

So I was going through the book Clojure High Performance Programming and I thought I might share a line or two about why I think this book is a good read.

First, this really isn’t just a book of recipes for writing faster Clojure programs by only exploiting what the standard library or 3rd party libraries have to offer. What I like about this book in general is the back-to-the-basics approach. You don’t start with Clojure internals, you don’t even start with JVM internals. Not even the OS. You start with bare metal. Getting to know (or refreshing the knowledge of) how CPUs work, how they interact with the RAM, where are the usual bottlenecks. Well, these things actually aren’t covered right at the beginning of the book (which baffled me a bit) but you start getting the global picture once you go through them.

Other than that the book offers a good intro into the performance characteristics of persistent data structures in Clojure (yes, all the big-O stuff included) or how numerics in Clojure work and what is their relationship to the underlying Java implementations. A lot of interesting snippets showing not-that-well-known or darker corners of the Clojure language. Very important part of the book is the one on Clojure concurrency primitives - atoms, agents, refs - as these can be real bottlenecks when used improperly. You also get to know Clojure’s explicit parallelization features, like parallel mapping or reducers and all that stuff.

There is a lot of things this book goes over, sometimes only glossing over. Some might (or actually do) think that this is the biggest drawback of the book. But to me this isn’t a problem - on the contrary. All the things motivate me to fire up Google and start studying more on what might not be exactly a deep dive in right in the book.

A few days after starting with this book I actually found myself having it open next to my Clojure dev setup and consulting it when doing real Clojure development. Not because it is an exhaustive text on Clojure performance (it isn’t, of course - and doesn’t aim to be). Simply just because it’s a good “catapult” for exploring more on all the important performance themes in the Clojure programming story.

Jak bylo na EuroClojure 2013 (den 2)

[první díl zde]

Druhý den začal pravděpodobně nejlepší přednáškou celé konference, resp. určitě to byla přednáška s nejlepším potenciálem dostat lidi do varu.

Keynote: Narcissistic Design - Stuart Halloway

Stu je jeden z hlavních lidí kolem Clojure. Je zakladatelem (spolu s Richem H.) firmy Relevance (dnes Cognitect), která vyvíjí databázi Datomic a poskytuje k ní i k Clojure profesionální support.
Narcissistic design je sada best practicess, kterou by se měl řídit každý programátor, který se nechce nikdy strachovat o práci. Sebestřednost a vysoce infekční komplexita (samozřejmě ta accidental) jsou perfektní pojistky toho, že vás bude firma nadosmrti potřebovat, abyste se o vyvinutý SW starali… Aneb: It’s all about me!
Tento talk už byl jednou nahrán na Reaktor Dev Day ve Finsku a i kdybyste neměli čas koukat na přednášky, tahle je must see (i když na EuroClojure padlo pár perel navíc, jelikož Stu věděl, že ho nikdo nenahrává - tuším, že se k tomu i přiznal ;). Zmíním tedy jen pár neocenitelných rad, které odteď sídlí v mém zlatém fondu vývoje SW (je to mix toho, co Stu přímo říkal a toho, jak si to já interpretuju - po shlédnutí videa uvidíte, co vám bude dávat smysl a co třeba ne):

  • Hodně objektového programování, hodně stavu a hlavně - settery! Těch není nikdy dost. Ať je trocha adrenalinu. Život začíná po třicítce …eee, po konstruktoru.
  • Kašlete na komunikaci skrze data, vystavujte API - nuťte lidi používat váš jazyk! 
  • Žádná asynchronicita a hlavně žádné fronty! Těsná vazba je váš kamarád, tvrdě synchronní komunikace třešnička na dortu!
  • Proboha, hlavně žádné obyčejné datové struktury, které může každý zpracovat jak se mu líbí! To by tak hrálo! Odteď objekty! VŠUDE! CustomerBean, CustomerDto. Na každou blbost udělejte DTOčko. Vždycky. A ty settery, nezapomeňte…
  • Hodně statického typování a to hlavně napříč subsystémy. V souvislosti s tím je dobré i používat věci jako Java RMI, CORBA apod. Dynamické jazyky jsou hračky pro malé děti a nic velkého v nich napsat nejde.
    Infikujte a svažte svými typy úplně všechno kolem.
  • Pište unit testy, zneužívejte je prakticky pro cokoliv a nahraďte jimi …všechno. Hlavně veškerou dokumentaci.
  • Unit testy jsou v kombinaci se statickým typováním taky pěkný způsob, jak řešit triviální bugy. Že se dá mnoha bugům předejít použitím neměnných datových struktur, funkcí bez postranních efektů apod.? Blah! Nejsme včerejší!
  • Nepoužívejte perzistentní a neměnné datové struktury. Ty jsou pro světy, kde se pamět měří v megabytech nebo dokonce gigabytech (to prý existuje!) a HW není drahý. My přece máme jen pár kilobytů a těmi není radno plýtvat! A ty sálové počítače si taky člověk domu nekoupí.

Asi chápete :) I kdyby člověk s některými kontroverznějšími tvrzeními nesouhlasil, většina z nich je celkem trefných.

Using Clojure to Serve The Internet of Things

Příběh firmy Xively, jako ze žurnálu. Začli s Ruby on Rails, jakmile získali první zákazníky, šlo to do kolen. Přešli na JVM a Clojure, obrovský nárůst prostupnosti dat.
Business téhle firmy je vůbec zajímavý. S rozmachem fenoménu “internetu věcí”, bude po podobných konsolidačních platformách hlad a není se čemu divit.
Součástí talku byla i ukázka barevného diodového “teploměru”, který v reálném čase reagoval na frekvenci výskytu daných hashtagů v tweetech.

Newspaper Massacre

Jeden z nejpůsobivějších příběhů ze zákopů. Daily Mail jsou největší internetové noviny na světě. Původní verze jejich front-endu, který dodává naprosto nezbytné a informačně hodnotné bulvární články čtenářům? 

Uspořádali soutěž o to, kdo bude schopen přijít s nejlepším způsobem, jak to celé  dát dokupy (prostě udělalo se pár proof of conceptů, místo aby si manažeři sedli do meetingovky a pak nadiktovali ostatním, jak se to napíše).

Kompletní rewrity nefungují? Tak určitě.

(into reduce transient) - Michał Marczyk

Jeden z hlavních přispěvatelů do ClojureScriptu rozebíral teoretické i praktické základy datových struktur v Clojure. Jak je řešena persistentnost (záměrně nepíšu “persistence”; nemá nic společného s databází) a jak na to, chceme-li implementovat vlastní sadu datových struktur, které perfektně zapadnou do stávajících abstrakcí, které Clojure používá. Asi nejvíce computer science talk celé konference, jak radostně podotkla Bodil Stokke ;)

Megarefs - Christophe Grand

Christophe je (mimo jiné) autorem mého nejoblíbenějšího šablonovacího enginu pro Clojure - Enlive. Tato přednáška však byla o něčem zcela jiném.
Clojure má softwarovou transakční paměť, díky které je možné měnit hodnoty transakčních referencí a mít garantováno, že se v daném bloku provede buď vše nebo nic (velmi stručně řečeno). V tomto talku byly představeny tzv. megarefs, které umožňují mít v refu jednu velkou datovou strukturu, která uvnitř sebe opět umožňuje za pomoci refů kontrolovat granularitu atomicity změn v celém tom “světě”. Rozhodně zajímavá rozcvička a když to Christophe píše, asi pro to má i využití :)

Sada tří Lightning talků

  • Literate programming - programování s použitím přirozeného jazyka mě nikdy příliš nezajímalo, takže tenhle počin jsem bral vyloženě jako kuriozitu. Osobně si neumím představit, že bych to nějak využil v praxi. Ale takových věcí už bylo…
  • Lithium - Lisp ve stylu Clojure, který běží přímo na x86 HW. Velká škoda, že Daniel neukázal live demo, ale každopádně klobouk dolů, vyblbnout se musel asi solidně :)
  • Templatování v Clojure - rychlý přehled templatovacích enginů

Meta-eX: How to live code your own band - Sam Aaron

Další multimediální přednáška od jednoho z tvůrců enginu Overtone. Těžko popisovat slovy Samův enthusiasmus pro experimentování se zvukem a skládání hudby… A už vůbec nemá smysl popisovat, jak hraje kapela, jejímž hlavním hudebním nástrojem je live editování kódu v Emacsu. Bohužel, žádné rozumné video z EC není a tak tu nechám alespoň tohle.   

Poslední dva talky (Enterprise integration with Clojure a A Perfect Storm for Legacy Migration) byly v podstatě příběhy firem, které nasazovaly Clojure a relativně detailní popis toho, jak zapadá do jejich infrastruktury.

Toť vše z mé strany. Pokud jsem k něčemu nenapsal dost, další informace najdete na Lanyrdu.

Suma sumárum, jel bych klidně zas! Doufejme, že příští ročník bude opět v relativně dostupné lokaci a že se posune návštěvností i šťavnatostí přednášek zase o kus dál.

Blog.

twitter.com/dkvasnickajr

view archive



Ask me anything