Date puzzle

I like surprises, I like puzzles, therefore I like Java Date and Calendar library. I already thought that there is nothing it could surprise me with. And I was wrong. Today it got me again. Consider the following code snippet.

		Calendar calendar = Calendar.getInstance();
		calendar.clear();
		calendar.set(Calendar.YEAR, 1970);
		calendar.set(Calendar.MONTH, 0);//month is zero based
		calendar.set(Calendar.DAY_OF_MONTH, 1);
		Date date = calendar.getTime();
		System.out.println(date);
		System.out.println(date.getTime());

The command on the line 07 prints out “Thu Jan 01 00:00:00 GMT 1970“, the question is what does the command on the line 08 prints? If you are such looser and you do not remember the JavaDoc of java.util.Date class, here is the description of getTime() method.

Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.

So to reformulate the question, what is the number of milliseconds between January 1, 1970, 00:00:00 GMT and Thu Jan 01 00:00:00 GMT 1970?

What are your guesses? Make yourself famous by adding a comment with correct explanation. And do not worry, if you do not find the solution until tomorrow evening, I will post it here.

Webové služby à la Spring

V poslední době docela často používal knihovnu Spring WS. Chtěl bych se s vámi podělit o zkušenosti, které jsem s tímto modulem udělal. Nejdřív bych měl ale upozornit, že nejsem expert na webové služby. O tom co je to port nebo binding mám jen mlhavou představu. Na druhou stranu jsem to nikdy vědět nepotřeboval. Nečekejte také žádný návod jak to používat. Původně jsem ho sice chtěl napsat, ale pak mi došlo, že bych jen kopíroval existující dokumentaci.
Než se ale pustíme do Spring-WS, začnu trochu zeširoka. Na webové služby se můžeme dívat ze dvou úhlů. Můžeme je vnímat jako trochu lepší vzdálené volání metod (RPC). Prostě označím metodu vhodně zvolenou anotací a nějaký framework se mi postará o to, aby tato metoda byla vzdáleně volatelná. Nijak zvlášť mě nezajímá to, jak bude komunikace probíhat. Prostě beru webové služby jako takovou trochu modernější Corbu nebo RMI.
Druhý přístup se na webové služby dívá z druhé strany. Bere je jako trochu vylepšený způsob výměny XML dokumentů. Při tomto přístupu je pro mě důležitý formát výměny dat, od něj se pak odvíjí způsob volání.
Samozřejmě oba přístupy nakonec skončí obdobně, liší se jen tím, co je pro mě důležitější. Spousta lidí se shoduje v tom, že druhý přístup dává větší smysl. Obvykle se dočtete, že při návrhu webové služby by se mělo začít u definice XML dokumentů, které budou sloužit pro výměnu dat (contract first). Dává to smysl. Definice dat je to, kde se budeme střetávat s konzumenty naší webové služby, XSD je to, co vidí a proti čemu programují. Nikoho nezajímá, jakou signaturu má naše metoda, konzumenty zajímá co všechno nám musí poslat a co my jim na oplátku pošleme jako odpověď.
Spring WS je postaven právě kolem contract-first přístupu. A musím přiznat, že je postaven docela dobře. Nečekejte super kvalitu, na kterou jste zvyklí od Springu. Spring WS je psán jinou partou lidí a občas člověk narazí na místa, která by šla udělat lépe. Nicméně i tak je to kvalitní knihovna a pokud jste zvyklí na Spring, konfigurace Spring WS vám přijde přímočará.
Než se vrhnu do popisu toho, jako co všechno Spring WS umí, zamysleme se nad tím, co si od takové knihovny představujeme. Já od ní chci několik věcí. Chci, abych se nemusel starat o mydlinky kolem SOAPu, chci se zabývat pouze zpracováním nákladu (payloadu), který mi v těch mýdlových bublinách přišel. Takže od WS knihovny chci, aby mi zpracovala SOAP, vybalila náklad a předala mi ho k zpracování. Protože nerad pracuji s XML, chci, aby mi pomohla s převodem z XML do objektů. U odpovědi chci aby udělala to samé, ale pozpátku. Pak by se také hodilo, aby mi pomohla s vygenerováním WSDL a pokud je to nutné s WS-Security. Když se na tyto požadavky podívám, zjistím, že už to všechno je vyřešeno. Zpracování SOAPu umí SAAJ, na serializaci XML máme taky hromadu frameworků. Stačí to všechno jenom pospojovat. A přesně to dělá Spring WS.
Co se mi na něm líbí je jednoduchá konfigurovatelnost. Nestalo se mi, že bych narazil na něco, co bych neuměl nakonfigurovat. Všechno je možné nastavit, snadno přeprogramovat a podobně.
Samozřejmostí je volba způsobu serializace z a do XML. Máte na výběr JAXB2, Castor, XStream, moje oblíbené XMLBeans a několik dalších. Vytvoření vlastního způsobu serializace je jen otázkou implementace dvou rozhraní.
Pokud potřebujete něco pokročilejšího, můžete použít interceptory. Ty fungují obdobně jako filtry u HTTP requestu, jsou ale spouštěny na úrovni SOAP dotazu a odpovědi. Spring WS obsahuje interceptor pro logování dotazů a odpovědí, který je docela užitečný. Navíc obsahuje interceptor, který umí spustit XSLT transformaci nad příchozím dotazem. To je super, pokud potřebujete upravovat formát dat. Například přidáte element do odpovědi. Ale v mezidobí, než všichni vaši klienti přejdou na novou verzi, musíte některým z nich vracet odpověď bez tohoto elementu. Není nic snazšího než napsat příslušnou XSLT šablonu, která ho z odpovědi vyhodí. To vám ušetří starosti s údržbou několika verzí té samé služby.
Interceptory navíc nabízejí skvělé místo pro úpravy jak dotazu tak odpovědi. Narazil jsem na následující problém, SAAJ negeneroval XML deklaraci na začátku XML dokumentu. Takové to <?xml version="1.0"?>. Bohužel jeden klient se toho dožadoval. Po půlhodině strávené výzkumem toho kde je chyba, jsem přišel na to, že z neznámého důvodu SAAJ implicitně XML deklaraci negeneruje. Všechno vyřešil trojřádkový interceptor, který nastavil správnou property tak, aby ji používal.
Co mě také potěšilo je generování WSDL. Člověk by si řekl, že je to samozřejmost. Nicméně například XFire měl s generováním WSDL z existujících XSD souborů pěkné problémy. Zamotal se v několikanásobných importech stejného XSD souboru a vracel mi nevalidní WSDL. To byl jeden z důvodů proč jsme přešli na Spring WS. (Druhý důvod byl, že už jeho vývoj skončil, teď se jmenuje CXF a konfigurace rozhodně není kompatibilní). Spring WS se stejným schématem neměl nejmenší problém, naopak potěšil takovou maličkostí jako je automatická změna URL webové služby ve WSDL podle toho, kde je nasazen.
Takže abych to shrnul, pokud děláte webové služby stylem contract-first a jste zvyklí na Spring, pak je Spring WS rozhodně dobrá volba. Jeho nevýhodou je, že vám nedá nic zadarmo. Chcete generovat WSDL? Musíte si to nakonfigurovat. Chcete validovat dotazy pomocí XSD? Musíte nastavit správný interceptor. Trochu nešikovné je, že pro integraci s frameworkem musíte implementovat jeho rozhraní nebo rozšířit jeho třídu. Nicméně pokud nemáte stovky různých webových služeb, tak vás pár obalovacích piditříd nezabije. Pokud je i malá obalovací třída pro vás moc, pak můžete použít anotace. Ty jsem ale nezkoušel, takže nemohu sloužit.
Mezi nevýhody Spring WS patří, že nepodporuje anotaci @WebMethod. Autoři tvrdí, že je to záměrně, že prý lidi nabádá ke škodlivému pohledu na webové služby jako na vzdálené volání metod. Nevím, jejich anotace @Endpoint mi nepřipadá o moc lepší. Ale i přes tyto nevýhody mi Spring WS připadá jako dobrá volba. Dává vám svobodu volby a to je podle mě docela užitečná věc.

Potrestán odměnami

Zrovna čtu zajímavou knížku. No a protože si potřebuji urovnat myšlenky, tak vám o ní píšu i když ji ještě nemám dočtenou. Kniha se jmenuje Punished by Rewards a napsal ji Alfie Kohn. Jak název napovídá, není to o počítačích, ale o lidech. Je to souhrn výzkumů o motivaci a docela těžko se to čte. Částečně proto, že je to na můj vkus psáno trochu suchopárně, až vědecky. Ale hlavně proto, že to o čem se tam píše se člověku těžko vstřebává.
Jak už název napovídá, je to kniha o škodlivosti odměn. A to jak při výchově dětí doma, ve škole, ale i při motivaci lidí v práci. Celé je to o tom, že existují dva druhy motivace, vnitřní a vnější.
Vnitřní motivace znamená, že něco dělat chci, protože mě to baví, nacházím v tom uspokojení a podobně. Vnější motivaci přichází z venku a to buď ve formě odměny nebo trestu. Většinou protože po mě někdo chce abych něco udělal.
No a celá kniha je o tom, jak vnější motivace nefunguje. Prostě, když mi někdo nabídne spoustu peněz, tak mě to nepřinutí pracovat lépe. Když mě někdo bude něčím hrozit, nestanu se tvořivějším a šikovnějším. Když to člověk takhle napíše tak to zní jako pitomost. Vždyť se s odměnami setkáváme celý život, proč by je lidi používali, když nefungují?
Ono se nedá říci, že by tak úplně nefungovaly. Odměny jsou super, když chci někoho donutit aby dělal to co mu řeknu. Bohužel ho ale nedokáží donutit k tomu aby dělal to co chci. V tom je docela rozdíl.
Hodně zajímavý je vztah mezi odměnami a výkonností. Odměnou mohu zvýšit výkonnost u jednoduchých opakujících se činností. A to jen krátkodobě. Výzkumem bylo naopak dokázáno, že u činností vyžadujících kreativitu jsou odměny dokonce škodlivé. Krátkodobě zvýší kvantitu na úkor kvality, ale ani to zvýšení kvantity netrvá moc dlouho. Když se nad tím člověk tak zamyslí tak to docela dává smysl. Představte si, že by se česká Java komunita rozhodla mi za mé skvělé články platit. K čemu by to vedlo. Pokud by ta odměna byla hodně zajímavá, tak bych psal víc článků. Ale jelikož jsem vykuk, tak bych je psal samozřejmě kratší. Po nějaké době by mi došla inspirace, tak bych tak něco psal, abych dostal odměnu. Po nějaké době by mě to začalo asi dost nudit a kvalita i kvantita by šla ještě víc dolů. To je samozřejmě jenom smyšlený příklad, v knize můžete najít výsledky desítek výzkumů, které pozorují podobné důsledky.
Nejen to. Bylo pozorováno, že když někoho za něco odměním, tak mu to znechutím. Nejvíc mě zaujal výzkum, kdy jedné skupině dětí slíbili, že když budou chvíli kreslit voskovkami, tak si za odměnu budou moci kreslit fixami. Druhé skupině naopak slíbili, že když budou chvíli kreslit fixami, tak budou moci za odměnu kreslit voskovkami. I po dlouhé době první skupina radši kreslila fixami a druhá voskovkami. No taky zkoušeli dětem slíbit, že když teď snědí zmrzlinu, tak si za odměnu budou moci dát kyselé rybičky, ale tomu se jen smály a na zmrzlinu nezanevřely.
Samozřejmě je tu také negativní dopad odměn na ty, kteří ji nedostali, je tu negativní vliv na spolupráci a podobně. Zajímavý je i fakt, že odměny ignorují příčiny. Když moji zaměstnanci špatně pracují, tak jim mohu zkusit před nosem zamávat odměnou. Ale nebylo by lepší přijít na to proč špatně pracují? Třeba to má objektivní příčiny, které by se daly odstranit.
To mě přivádí k tomu, co používat, když jsou odměny tak špatné? Jak lidi motivovat? Odpověď zní lakonicky: „Nemotivujte je“. Prostě se snažte zařídit, aby se zajímali o to co dělají, aby je to bavilo a uspokojovalo. Pak to budou dělat dobře a kvalitně. Zařídit aby lidi bavilo to co po nich chceme je hodně těžké, v knize se dočtete jak tomu pomoci. Docela pěkně se to překrývá s triky, které používají agilní metodiky. Znáte to, nechte lidi vybírat si a řídit svoji práci, nechte je spolupracovat a podobně.
Samozřejmě to neznamená, že bych měl pracovat zadarmo. Na to zapomeňte. Autor ale klade důraz na to, aby se odměna co nejvíce oddělila od úkolu. Zjednodušeně řečeno, aby lidi dostávali plat, ale aby to bylo co nejvíce odděleno od toho co dělají.
Což mě vede k tomu, s čím mám v knize největší problém. Autor mě přesvědčil, že mávat lidem odměnou před nosem nevede k lepším výsledkům. Spíše naopak. Ale kdyby to byla pravda tak by to znamenalo, že komunismus nebyl zas tak špatný nápad. A to jak z historie víme, pravda není. V realitě lidi prostě chtějí mít víc něž soused, chtějí být pochváleni před nastoupenou jednotkou, chtějí dokázat světu, že jsou nejlepší. Tak nevím. Je lepší odměňovat lidi podle zásluh nebo všechny stejně? Ale abych nekončil tak rozpačitě tak provedu důkaz anekdotou (hodně volně přeloženo z knihy):

Byl jednou jeden dědek. Bydlel nedaleko od školy a každé odpoledne na něj kolemjdoucí školáci hulákali a nadávali mu. Jednoho dne dědek vyhlásil, že každý, kdo mu zítra přijde nadávat, dostane dvacet korun. Druhý den přišla hromada dětí, nadávali mu a on jim každému vyplatil dvacet korun. Potom co jim zaplatil, vyhlásil, že kdo přijde další den, dostane deset korun. No deset korun taky není k zahození, tak mu i další den přišla spousta dětí nadávat. Dědek vyhlásil, že kdo mu přijde nadávat zítra, dostane korunu. Děti na sebe nevěřícně koukali a říkali, „Na to zapomeň, za blbou korunu ti nikdo nadávat nebude.“