Where does this class came from?

Today I have been debugging some nasty problem on Weblogic. The application worked on one version but did not work on an older one. Apparently some classes were not compatible. But it’s quite difficult to debug such problem. You need to find out from which JAR given class was taken from. It’s not trivial in enterprise environment. The class can be part of J2SE, application server and your EAR at the same time. Especially if the class has something to do with XML or web services. End if you have such class, you need some trick to determine which version was actually used.

The trick is simple yet not widely known. In fact I have encountered it in a Scala related article. You just call this code from JSP or some other suitable place.

YourClass.class.getProtectionDomain().getCodeSource().getLocation()

And that’s all, this command will return path to your mystery class JAR.

iWoz

Nevěřím, že cokoliv revolučního bylo kdy vymyšleno komisí. Komise by se na tom totiž nikdy nedohodla!
Steve Wozniak

Jenom chci upozornit na docela zajímavou knížku. Jmenuje se iWoz a je to autobiografie Steve Wozniaka, člověka, bez kterého by nevznikla firma Apple, člověka, který prý jako první sestrojil osobní počítač s klávesnicí a monitorem. Docela dobře se to čte, člověk se tam i dost věcí doví. Knížka mi hodně připomněla „To nemyslíte vážně, pane Feynmane!“, oni si oba pánové byli asi dost podobni. Takže pokud vás zajímá jak fungují a žijí géniové, tak doporučuji.

Docela mě zaujala myšlenka o tom, jak nic revolučního nikdy nebylo vymyšleno komisí. Přesně to samé psal i pan Brooks v knize, o které jsem psal minule. Ten tam měl i takovou pěknou tabulku, kde uváděl produkty, které mají zanícené fanoušky.

Fandové Normání
iPhone Mobil
Apple II PC
Rozhranní Macintoshe Windows
UNIX z/OS (MVS)
Pascal Algol
Fortran Cobol
Python Appletalk

Zajímavé je, že věci napravo vznikly pomocí formálního procesu, věci vlevo vznikaly mimo normální produktové procesy. Neznamená to, že by věci vpravo byly horší, jenom už nejsou tak originální a je méně časté, že by k nim lidi měli emocionální vztah. Mimochodem, právě Steve Wozniak, je autorem Apple II.

Návrh návrhu

Nejtěžší část návrhu je přijít na to, co vlastně navrhujeme.

Nakonec mi pomalu začalo docházet, že to nejužitečnější, co pro zákazníka dělám, je pomoc v rozhodování o tom co vlastně potřebuje.

Jakýkoliv pokus o formulaci všech možných požadavků na začátku projektu selže a způsobí podstatné zpoždění.
PAHL AND BEITZ, ENGINEERING DESIGN

Po delší době se mi do rukou dostala technická knih, který mě opravdu zaujala. Nespáchal ji nikdo jiný než Fredercik Brooks a jmenuje se The Design of Design: Essays from a Computer Scientist.

Pokud si nevybavujete, kdo je pan Brooks, tak vám připomenu, že to je člověk, který napsal v roce 1975 klasiku „The Mythical Man Month“, dělal projekťáka při konstukci IBM System/360, pomáhal americké armádě s projekty a podobně. Zkrátka je to člověk, který ví, o čem mluví.

Z té knihy je to vidět. Mluví v ní obecně o návrhu software, hardware, domů nebo i knih. Dost se v knize opírá do našeho oblíbeného vodopádového modelu. V zásadě říká, že vodopád nemůže efektivně fungovat, což mě od člověka takového formátu těší. Kniha by se dala číst jako chvála agilního vývoje, i když slova agilní jsem si všiml jenom jednou. Ale jinak tam prosazuje většinu agilních fint jako používání vlastní hlavy, používání iterací, důraz na talentované lidi nebo třeba častou komunikaci se zákazníkem. Staví se také proti používáni rigidních procesů, když chce člověk vymyslet něco inovativního.

V první části představuje racionální postup při návrhu. Něco ve stylu „dokud nejsou splněny všechny požadavky a návrh není dost dobrý, procházej všechny možnosti návrhu a hledej ty které maximalizují užitnou hodnotu.“ V dalších částech vysvětluje proč tento postup nejde použít. Například proto že možností návrhu je nesmírné množství, požadavky jsou nejisté a nestálé, užitná hodnota je vágně definovaná a podobně. Určitě to znáte sami, pan Brooks to ale pěkně systematizuje.

Zajímavá kapitola je o racionalizmu a empirizmu. Je to trochu filozofický problém, ale pro nás velmi důležitý. Točí se kolem otázky: „Dokáži jenom pomocí přemýšlení správně navrhnout složitý objekt?“ Racionalisté věří že ano, empirici věří že ně. Já se stejně jako autor řadím mezi empiriky, ale dovedu si představit, že někdo věří i v opak. Mám za to, že ho z toho praxe rychle vyléčí, ale je možné že ne. V knize se dozvíte více detailů i argumentů pro empirizmus.

V dalších kapitolách se zamýšlí, jak tedy ten návrh dělat, pokud na to není žádný recept. V zásadě tvrdí něco podobného jako agilisti: „Sežeňte si šikovné designéry a dejte jim prostor a prostředky k tomu, aby se mohli realizovat.“

Samozřejmě i na této knize najdete pár mušek. Třeba v kapitolách 17 a 18 navrhuje dokonalý systém pro domovní architekty. Musím se přiznat, že tyto části jsem přeskočil. Dobrý úlet je i část 16, kde popisují, jak se ještě s jedním spoluautorem pokoušeli zaznamenat rozhodnutí kolem návrhu. Kdyby se jim to povedlo, bylo by to užitečné. Často totiž potřebujete vědět, proč je daná věc navržená zrovna takto, z jakých požadavků rozhodnutí vycházelo, proč to není uděláno jinak a podobně. Bohužel narazili na problém, že struktura popisu odráží strukturu navrhovaného systému, no a když se mění struktura návrhu, musíte měnit i strukturu popisu a je v tom zmatek. Takže je to něco ve stylu průkopníci slepých uliček.

Ale jinak je to kniha hodně dobrá, takže dostává úžasných osm hvězdiček z deseti. No a protože jsem v poslední době okouzlen službami Amazonu, přikládám odkaz na místa, která si čtenáři v knize často zvýrazňují.