Java crumbs

Let me introduce you another of my pet projects. It's called JsonUnit and it's something like XmlUnit only for JSON (well it's much, much more simple). Basically it's able to compare two JSON documents and if they do not match, it prints out the differences. For example the following test

import static net.javacrumbs.jsonunit.JsonAssert.assertJsonEquals;

...

assertJsonEquals("{\n" +
			"   \"test\":[\n" +
			"      1,\n" +
			"      2,\n" +
			"      {\n" +
			"         \"child\":{\n" +
			"            \"value1\":1,\n" +
			"            \"value2\":true,\n" +
			"            \"value3\":\"test\",\n" +
			"            \"value4\":{\n" +
			"               \"leaf\":5\n" +
			"            }\n" +
			"         }\n" +
			"      }\n" +
			"   ],\n" +
			"   \"root2\":false,\n" +
			"   \"root3\":1\n" +
			"}",
			"{\n" +
			"   \"test\":[\n" +
			"      5,\n" +
			"      false,\n" +
			"      {\n" +
			"         \"child\":{\n" +
			"            \"value1\":5,\n" +
			"            \"value2\":\"true\",\n" +
			"            \"value3\":\"test\",\n" +
			"            \"value4\":{\n" +
			"               \"leaf2\":5\n" +
			"            }\n" +
			"         },\n" +
			"         \"child2\":{\n" +
			"\n" +
			"         }\n" +
			"      }\n" +
			"   ],\n" +
			"   \"root4\":\"bar\"\n" +
			"}");

will result in

java.lang.AssertionError: JSON documents are different:
Different keys found in node "". Expected [root2, root3, test], got [root4, test].
Different value found in node "test[0]". Expected 1, got 5.
Different types found in node "test[1]". Expected NUMBER, got BOOLEAN.
Different keys found in node "test[2]". Expected [child], got [child, child2].
Different value found in node "test[2].child.value1". Expected 1, got 5.
Different types found in node "test[2].child.value2". Expected BOOLEAN, got STRING.
Different keys found in node "test[2].child.value4". Expected [leaf], got [leaf2].

Neat, isn't it?

Je pátek ráno. Mám hotovou implementaci a zbývá už jen zprovoznit integrační testy. První test. Drobný refaktoring a už běží. Jejda je tu ještě jeden. A padá. K čemu sakra je? Nemám potuchy. Kdo ho napsal? Franta? Ale ten už tu nepracuje! Vždyť to sakra musí fungovat. Zkusím změnit toto. Nepomáhá. Co zkusit tamto. Taky nic. Cože to už je oběd? Předělám integrační test na unit test. Sláva teď se to dá debuggovat. Cože, takhle se to přeci chovat nemůže. File.isDirectory vrací false a File.getAbsoluteFile().isDirectory() vrací true. To není možné. V tom počítači snad straší, vždyť to musí jet. Sakra musím na schůzi. Dvě hodiny v čudu. Musím udělat pár pokusů, jestli to není SecurityManagerem. Není. Cože, to už je pět? Mám pravidlo, že v pět odcházím. Ještě ho chvíli porušuji. Kašlu na to, jdu domů. Musí to počkat na pondělí. V noci ve dvě ráno se probudím, otevřu oči a znám řešení. Vždyť je to tak jednoduché!

Předpokládám, že se vám něco podobného také někdy stalo. Řešení zapeklitých problémů často člověka napadá, když na nich nepracuje. Při jízdě autem, ve sprše, při cvičení, na záchodě a i ve spánku. Někomu údajně přicházejí nápady ve snech, mě se obvykle zjevují hned po probuzení. Jednu dobu jsem se dokonce bál, že mě kolegové budou podezírat z toho, že nejsem tak neskonale geniální jak ve skutečnosti jsem. Že si budou myslet, že mám doma poradce, který mi všechno poradí. Večer nikdy nic nevím a ráno mám řešení. Podezřelé, není-liž pravda?

Samozřejmě nejsem první, kdo si toho jevu všiml, takže to tu nebudu moc rozebírat. V zásadě jsem si tu jen chtěl zaznamenat tuto radu.

Nemůžeš na to přijít? Tak vypadni od toho počítače a jdi dělat něco jiného.

Ideálně něco, u čeho se nedá myslet na programování. U mě je to těžké, na programování dokážu myslet skoro u všeho. Ale je pár věcí u kterých to nedovedu. Třeba kreslení. Nebo spánek. Někdo dokonce tancuje, ale tak špatně jsem na tom ještě nikdy nebyl.

A jsou to právě ty činnosti, které nás donutí to pustit z hlavy a po kterých nás to prostě napadne. Nevím čím to je. Psychologové si myslí, že to vědí, ale moc bych jim nevěřil. Pokud by vás snad zajímali detaily, tak si přečtěte Pragmatic Thinking and Learning, tam je to rozpitvané dost. Kdo nerad čte může si pustit video o Hammock Driven Developmentu.

Já už budu končit, musím vypadnout od počítače a vymyslet, jak přesvědčit šéfa, aby mě platil i za čas kdy spím.

Minule jsem nenechal na Not Invented Here syndromu nit suchou. Člověk holt musí být kontroverzní, aby zaujal. To se mi snad povedlo, ale musel jsem obětovat objektivitu. Teď se to pokusím napravit.

Pokud je to jádro vašeho podnikání, dělejte to sami bez ohledu na cokoliv

Ano, Joel to jako obvykle věděl už deset let zpátky. Pokud máte něco, čím se odlišujete od konkurence, je NIH nezbytností. Takže, pokud se od konkurence odlišujete vychytaným UI, nemůžete na to použít stejné komponenty jako má konkurence. Pokud se chlubíte bleskovou rychlostí, občas vám nezbyde nic jiného, než si připravit vlastní Linuxovou distribuci. Pokud prodáváte databáze, musíte si kupodivu napsat vlastní databázi. Pokud jste Apple, tak si myslíte, že jste byli seslání shůry a pověřeni výrobou naprosto dokonalých věcí a musíte si dělat sami úplně všechno. A v tom je ten problém. Zatímco Apple si může dovolit navrhovat vlastní procesory, vy si to dovolit nemůžete.

NIH je neuvěřitelně drahý

Cokoliv si totiž vyvíjíte sami, je neuvěřitelně drahé. Opravdu neuvěřitelně. Fakt hodně. Představte si obrovitánské číslo. NIH je ještě mnohem dražší.

To nám je jako programátorům obvykle jedno, ale našim zákazník a zaměstnavatelům by to jedno být nemělo. Začíná to vývojem. Nejdřív vám to přijde jednoduché. Pak narazíte na pár hraničních případů, které jsou opravdu hnusné. No a nakonec vás dorazí změna požadavků, která vás donutí to přepsat. Jako všude jinde vývoje SW platí, že to jak to mělo vypadat, víme až když už je pozdě.

Vývojem to samozřejmě nekončí. Máme tu ještě dokumentaci a testování. Infrastrukturní kód se hrozně blbě testuje. Případy užití jsou obvykle špatně definovatelné, je tam spousta možností pro nečekané stavy a podobně. Často to nedokáže testovat nikdo jiný než programátor a programátoři jsou velmi špatní testeři.

Dále tu máme zaučování nových kolegů. Každý kdo chce u vás začít pracovat, se to musí naučit používat za vaše peníze. Když použijete existující technologii, máte velkou šanci najít někoho, kdo se to naučil za peníze vaší konkurence.

V neposlední řadě je tu údržba. Přicházejí stále nové a nové požadavky a vy pořád musíte platit někoho, kdo se o ten NIH musí starat. Často je to váš nejšikovnější člověk, kterého už dávno potřebujete na něco jiného.

Aby se všechno toto vyplatilo, musíte si být hodně jisti, že to opravdu nezbytně nutně potřebujete. Vyplatí se investovat hodně času a úsilí, a zjistit, jestli by se vám přeci jen něco existujícího nehodilo.

Hlavní je, opravdu se snažit najít něco, co by nám mohlo vyhovovat. I za cenu obětování některých požadavků. I když víme, že to není dokonalé. I když se bojíme, že nám to za pár let nebude stačit. I tak je velká šance, že existující technologie sice nebude super, ale bude vám prostě stačit. Jak říkají latiníci, bude good enough.

Dvakrát měž, jednou řež

Míval jsem kolegu, který říkával: "Každý, kdo se rozhodne napsat si vlastní knihovnu, by měl před tím desetkrát oběhnout barák, aby si to dobře rozmyslel." Takže ano, NIH je často nezbytný. Ale aby se vám vyplatil, musíte si být sakra jistí, že chápete kolik vás to bude stát a kolik vám to přinese.

Ještě jsem měl připravených pár historek o tom, jak i já, ač jinak dokonalý, k NIHu pravidelně nevědomky sklouznu. Ale tím bych ten článek jen zbytečně natahoval a zkazil bych si pointu. Teď slibuji, že už se o NIHu nebudu nějaký čas vyjadřovat.