Java crumbs

Debugging

Lukáš Křečan — Tue, 27 Jul 2010 13:56:21 +0000

Mám tu pro vás další knihu ze seznamu doporučené literatury. Jedná se o Debugging, kterou napsal David J. Agans. Tato kniha obsahuje několik pravidel, kterými by se měl člověk řídit, pokud hledá chyby jak v software tak i v čemkoliv jiném. Ta pravidla jsou následující:

Pochopte systém – Přečtěte si manuál, zjistěte si jak se to má chovat, jak se mají chovat komponenty a podobně.
Nechte to selhat – Pokud chceme odstranit chybu, musíme se ji naučit reprodukovat. Bez toho nemáme moc šanci zjistit co je špatně, a ani to, jestli už jsme to opravili.
Přestaňte přemýšlet a začněte se dívat – Člověku se často stane, že uhodne důvod problému a pak už ignoruje všechny náznaky toho, že je chyba jinde. Tato rada nám připomíná, že máme přestat hádat a začít se pořádně koukat.
Rozděl a panuj – Klasika, prostě si systém rozdělíme a zkusíme zjistit v které části ta chyba je.
Měňte pouze jednu věc – Často se stane, že člověk zkusí udělat jednu opravu, ta nepomůže, tak udělá další a pak ještě další, až problém nakonec možná zmizí. Neúspěšné pokusy o opravu v systému nechá. To je chyba. Pokud oprava nepomohla, vraťte všechno zpět a až pak se pouštějte do dalších pokusů.
Držte si kontrolní záznam – Pokud narazíte na problém, je dobré si napsat všechny okolnosti, které se při něm vyskytovali. Pokud je chyba dost zákeřná, bude se vám to hodit při analýze příčin. U software se tento bod dobře mapuje na logování.
Zkontroluje zástrčku – Často je chyba v té nejsamozřejmější věci. V autě není benzín, počítač není v zásuvce, aplikace není spuštěna.
Získejte čerstvý pohled – Nevíte si s něčím rady? Zkuste se někoho zeptat. Možná vám to docvakne při vysvětlování, možná něco napadne toho druhého. Důležité je, neříkat mu svoje hypotézy, ať ho nezatáhnete do stejné slepé uličky v které už jste vy.
Pokus jste to neopravili, není to opraveno – Ano, pokud chyba zmizí sama od sebe, je pravděpodobné, že se znovu objeví. A to pravděpodobně v ten nejnevhodnější okamžik.

V knize jsou samozřejmě jednotlivé rady rozepsány do hloubky, ale největší přínos vidím právě v tom seznamu. Má potenciál člověka odpoutat od zákysu a donutit ho nezkoušet to samé pořád dokola. V knize je také hromada „válečných historek“, ale ty jsou většinou hardwarové. Něco ve stylu: „špatně se nám ukládala data v paměti, tak jsme mysleli, že to je způsobeno šumem na vodiči a ono to přitom bylo špatným signálem časovače. Ha ha ha.“ Pro člověka hardwarem nezasaženého jako jsem já zas tak zajímavé nebylo. I když, historku o tom, jak se někomu odmítalo rozjet auto, podle toho jakou si dal zmrzlinu jsem pochopil i já.

Takže abych to shrnul, kniha byla zajímavá, ale řekl bych, že se bez ní obejdete. Nejužitečnější je určitě ten seznam pravidel.

Dlouhý ocas

Lukáš Křečan — Fri, 16 Jul 2010 14:01:20 +0000

Už jsem tady tu knihu zmiňoval, ale teprve teď jsem se jí prokousal. Ano, mluvím o knize The Long Tail, kterou napsal Chris Anderson.

Celý obsah knihy se dá vyjádřit jediným obrázkem (ukradeno bez svolení autora).

Zobrazuje počet stažení jednotlivých titulů ze serveru Rhapsody. Samozřejmě kniha není jenom o muzice, tvrdí v ní, že podobné rozložení se týká v podstatě všeho. Od kuchyňských mixérů, přes filmy, knihy, webové stránky, hledané termíny v Google až po příchutě piva.

Jak už název napovídá, kniha se zaměřuje hlavně na ten dlouhý ocas, tzn. na tu část grafu, která se nachází vpravo. Proč? Protože tu část vlevo všichni známe, tam jsou úspěšné hity, věci které se dají koupit v obchodě, věci které uvidíte v kině nebo televizi. Ale kromě nich existuje spousta dalších. Dokonce těch věcí, které nejsou takto středněproudé je mnohem, mnohem víc. (Proč graf vypadá tak jak vypadá se můžete dočíst v „V Pavučine Sítí“)

Schválně zkuste hádat. Kolik knih z prvních 100 000 titulů prodávaných na Amazonu se prodá alespoň jednou za čtvrt roku? Troufnete s tipnout? Nebojte, já jsem byl taky úplně mimo. Tak kolik? Prý je to 98%. Jinými slovy, Amazon prodá alespoň jeden výtisk z 98 000 titulů! Odhaduji, že na celém Václaváku mají k dispozici tak čtvrtinu, nemluvě o tom kolik z toho prodají. To je ostatně hlavní ponaučení z toho obrázku. Tam se pohybujeme v pomyslném žebříčku hitů na miliontém místě a přeci nejsme na nule. I tak hluboko se občas něco prodá!

Jiný z pohledů, kterým se na obrázek můžeme dívat je, že budeme ignorovat konkrétní data a budeme se na něj dívat jako na ideální křivku poptávky. Hodně lidí touží po hitech, proto máme tu špičku vlevo. Každý z nás má ale svoje zvláštní choutky, svoji niku (niche), která je pro něj specifická. Tato vlastnost formuje poptávku vpravo.

V dávné době kamenných o fyzického zboží, ale bylo fyzicky nutné omezit nabídku. Náklady na výrobu, skladování, prodej a dopravu zboží jednoduše na grafu nakreslí čáru, za kterou se prostě nevyplatí dané zboží prodávat.

Dnes ale žijeme ve století ovocného netopýra a existuje spousta produktů, která se dá vyprodukovat a prodat skoro zadarmo. Dlouhý ocas se nás tedy dotýká mnohem a mnohem více. V zásadě se spojily tři faktory, které umožňují realitě, aby dostihla tuto ideální křivku poptávky. První z nich je demokratizace výrobních prostředků. Ano dávný Marxův sen je konečně tu. V podstatě každý (na té šťastnější polokouli) má prostředky a dost času produkovat svoji hudbu, filmy, knihy, víno, obrazy... prostě (téměř) cokoliv. Tento faktor protahuje ocas doprava. Pak tu máme demokratizaci distribuce. Jinými slovy internet. Ten umožňuje komukoliv své výtvory distribuovat. Tento faktor dlouhý ocas zesiluje. No a nakonec tu máme propojení poptávky s nabídkou. Je to hlavně Google ale i různá doporučení na internetu od iTunes, přes Amazon až po blogy nebo Facebook. Tento faktor přesouvá lidi od hitů směrem doprava.

Jaké jsou důsledky? Například údajně stále méně lidí kouká na televizi. Proč? Protože mají volbu, můžou koukat na to co chtějí, ne na to co jim někdo vybere. Zeptejte se velkých hráčů zábavního průmyslu jaké to mělo důsledky pro ně. I když vlastně za jejich problémy můžou piráti, já zapomněl.

Samozřejmě jsou tu i pozitivní důsledky. Pokud proti tomuto trendu nebojujete, ale přimete ho za svůj, můžete na něm i vydělat. Protože pokud vás napadne spočítat si plochu toho ocasu, zjistíte, že je skoro stejně velká jako ta část vlevo! Takže pokud se vám ho podaří tuto poptávku nasytit, můžete na ní vydělat stejně nebo i víc než na hitech (ještě se tam projevuje marže, ale do takových detailů zabíhat nebudu). Pokud se vám tedy podaří za podstatě nulových nákladů prodávat velké množství knih, muziky nebo třeba inzerátů, máte na důchod vystaráno.

Tedy pokud jste ve správné části toho kolotoče. V doslovu posledního vydání se totiž dočtete jednu zásadní informaci. Na celé té mašinérii se podílí tři typy hráčů. Spotřebitelé, výrobci a agregátoři (viz. tři faktory výše). Spotřebitelé získávají možnost volby, výrobci si najdou těch svých pár spotřebitelů, ale ti hlavní kdo na tom vydělávají jsou agregátoři. To je ten Google, Apple, Amazon a eBay. Ti nic neprodukují, jenom spojují nabídku s poptávkou. Takže vlastně nic nového.

Ještě si neodpustím povzdechnutí, proč to u nás sakra nefunguje u videa a určité míry i hudby. Proč si nemůžu za rozumný peníz legálně stáhnout z internetu co chci. Proč se těch málo internetových obchodů co tu funguje chová jako kamenný obchod a mají v nabídce hrstku titulů? To se mi nějak nedaří pochopit. Ještě, že alespoň ty pivovary to u nás pochopily.

Já tvořím aneb od nápadu k realizaci za jeden den

Lukáš Křečan — Tue, 13 Jul 2010 08:58:40 +0000

Právě čtu knihu The Long Tail, která je o tom, jak jsou zajímavé trhy na chvostu poptávky, jak je zajímavé to, že čím dál tím víc lidí aktivně tvoří, místo toho aby jen pasivně čuměli na televizi. Taky jsem tak nějak trochu záviděl všem těm, co se pokoušejí rozjet vlastní internetové podnikání, nemluvě o těch, kterým se to povedlo.

Měl jsem několik nápadů, ale postupně jsem je zavrhl nebo selhali při realizaci. Až mě nakonec napadlo udělat komunitní web pro amatérské výtvarníky. Něco jako Flickr, ale pro lidi, kteří kreslí, malují, dělají si vlastní náušnice a podobně. Originální, že? No abych se přeci jen trochu odlišil, tak se chci zaměřit hlavně na český trh. Proč? Pro tuto cílovou skupinu je důležitá lokalizace do jejich jazyka. Často jsou to lidé, kteří si s počítačem nebo angličtinou moc nerozumí. Nedivil bych se, kdyby byla klasickou zástupkyní ne už mladá žena, která si s počítačem zas tak úplně nerozumí a Facebook zná jen z televize. Ale to je jen odhad, je pravděpodobné, že se pletu. Na druhou stranu lidé, kteří něco dělají rukama jsou ideální cílová skupina. Prostě se chtějí pochlubit a to nejlépe lidem, kteří mají podobné zájmy. Znám to z vlastní zkušenosti. Není nic horšího než se chlubit lidem, které to nezajímá. Navíc tu může docela fungovat šeptanda mezi kamarádkami. Prostě to znělo docela zajímavě.

Nápad ve mně uzrál včera ráno, tak jsem strávil nějakou hodinku na internetu hledáním, jestli něco podobného už neexistuje. A nic takového se mi nepodařilo najít! Alespoň ne v ČR. Pak přišla ta nejtěžší a nejdůležitější fáze. Vymyslet jméno. Nejlépe takové s volnou CZ doménou. Další hodina přemýšlení a hlavně zkoušení. Nakonec vyhrálo „Já tvořím!“. Jméno nic moc, ale lepší mě prostě nenapadlo. Postupně si na něj začínám i zvykat.

Takže máme jméno, teď už zbývá jen ta realizace. Původně jsem si chtěl vyzkoušet Scalu, Google App engine, Amazon S3 a podobně. Nakonec ale asi převážili zkušenosti a odolal jsem pokušení zavřít se na měsíc do sklepa a kódovat. Nejdřív jsem se podíval na internet, jestli bych nemohl využít nějaký existující projekt. Strávil jsem další hodinku na Google a SourceForge a našel jsem pár vhodných kandidátů. Pak jsem si ale vzpomněl, že existuje projekt Ning, v kterém už to všechno je, včetně hostingu. Stačí to jen naklikat. Což popravdě řečeno byla záležitost na půl hodinky. S výsledkem se můžete seznámit sami zde.

Velikou výhodou Ningu je lokalizace. Češtinu už tam prostě mají. Sice bylo a bude potřeba některé překlady upravit, ale to jde snadno přes administrátorské rozhraní. Ning má samozřejmě i své nevýhody. Hlavní nevýhodou je, že od 20. července nebude zadarmo. Verze, které by mi stačila stojí $20 za měsíc. Ale to je cena, kterou jsem ochoten platit. Popravdě řečeno, kdybych si měl jako programátorovi platit komerční cenu, tak jeden můj člověkoden vydá alespoň na rok provozu.

Další nevýhodou je, že nemám tu svobodu, kterou bych měl, kdybych si to napsal sám. Přizpůsobivost hotové platformy má své meze. Na druhou stranu je pravděpodobné, že kdybych to měl všechno programovat, tak bych to asi stejně nedokončil.

Největší nevýhoda ale je, že to samé může klidně udělat kdokoliv jiný (opovažte se!). Jenže to by mohl, i kdybych se na ten měsíc do sklepa zavřel. V dnešní době se člověk musí odlišit na jiné úrovni než technologické.

A jsme u největšího oříšku, kde sehnat lidi? Na tom to celé stojí a padá. Komunitní web bez komunity nemůže fungovat. Jedna věc je šeptanda, ale na tu člověk potřebuje určitou kritickou masu. Dokud jí nedosáhne, tak nemá kdo šeptat. Včera jsem cvičně hodil dvě věty na Facebook a už tam nejsem sám, přidaly se dvě kamarádky. Mám ještě jeden nápad, který by mohl být úspěšnější, ale je ještě v plenkách, tak mi určitě prominete, že si ho nechám pro sebe. Alespoň se pocvičím v marketingu.

Takže proč to vlastně dělám. No jo, proč vlastně? Určitě nečekám, že mě to bude živit. Popravdě řečeno, počítám s tím, že to bude naopak. Taky se na tom evidentně nenaučím programování. Možné se ale naučím spoustu dalších věcí. Hlavní je ale to, že mě to baví. Je to neuvěřitelný zážitek, když vás ráno něco napadne a odpoledne máte prvního uživatele. To za to stojí. Člověk si připadá, že opravdu něco tvoří.

Samozřejmě, pokud ve vás dříme umělec, neváhejte se přidat. Horší než já být nemůžete.

Writing fluent API

Lukáš Křečan — Sat, 10 Jul 2010 13:12:19 +0000

In recent weeks I have been working with Arjen Poutsma on a brand new testing support for Spring Web Services. At least Arjen has been working, I have been just generating crazy ideas and he kept explaining me why we can't use them.

But it was quite interesting experience and I have learned a lot about fluent API design. Since it was my first fluent API and I am not an API expert, please take everything I mention here with grain of salt.

The task is simple. We need a way how to configure a mock. This mock has to validate that requests generated by our application are correct and after that the mock has to return some response. We want to write something like this:

Computer, when someone is trying to send a request, verify that the request contains value “a”, has header “header” and then respond with value “b”.

The requirements for the API are following:

It has to be simple for users. Mainly it has to be friendly to GUI addicts like me, that rely on code-completion all the time.
The library itself has to be simple
The API should be as fluent as possible
It has to be extensible

In the next part, I will try to describe several variants of the solution, each of them fulfilling the requirements differently. Please keep in mind that the code is simplified, it focuses solely on the API, not on the implementation. Moreover, the classes have been renamed to show what their main purpose is.

All characters appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

Interface based version

code
The first variant is based mainly on interfaces. The test itself looks like this

	@Test
	public void testMock()
	{
		Mock mock = new Mock();
		mock.whenConnecting().expectValue("a").and().expectHeader("header").andRespondWithValue("b");

		//test code

		mock.verify();
	}

There is one entry point, class Mock

public class Mock {

	public RequestExpectations whenConnecting()
	{
		return new MockInternal();
	}

	public void verify()
	{
		//do something
	}
}

It just returns an internal class that implements RequestExpectations interface.

public interface RequestExpectations {

    ResponseActions expectValue(String value);

    ResponseActions expectHeader(String name);
}

All methods of this interface return ResponseActions interface

public interface ResponseActions {

	RequestExpectations and();

	void andRespondWithValue(String value);

	void andRespondWithError();

}

Please note that and() method allows chaining of request expectation.

This API is really IDE friendly. Code completion works like a charm. It's quite simple both from outside and inside. But this API has one big flaw. It's not extensible. Imagine that we would like to add an expectation that verifies a digital signature. We would have to add a method to the RequestExpectations interface. It is not possible neither for third parties nor for us, since this change would break backward compatibility.

Static factory

code
We can split the functionality and allow others to provide their own validators and response generators. We just have to change the interfaces

public interface RequestExpectations {

    ResponseActions expect(RequestMatcher matcher);
}

and

public interface ResponseActions {

	RequestExpectations and();

	void andRespond(ResponseCallback callback);
}

Now we have made the API extensible, but we have to provide an easy way how to create RequestMatchers and ResponseCallbacks. One way how to do it is a statically imported static factory.

public class StaticFactory {
	public static RequestMatcher value(String value)
	{
		return new RequestMatcher() {
			public void match(Object someParams) {
				//do something
			}
		};
	}
	public static ResponseCallback withValue(String value)
	{
		return new ResponseCallback() {
			public void doWithResponse(Object someParams) {
				//do something
			}
		};
	}
}

The test then can look like this.

import static net.javacrumbs.fluentapi2.StaticFactory.*;

public class MockTest {

	@Test
	public void testMock()
	{
		Mock mock = new Mock();
		mock.whenConnecting().expect(value("a")).and().expect(header("header")).andRespond(withValue("b"));

		//test code

		mock.verify();
	}
}

Such API is also fluent. It even resembles EasyMock API. The issue here is that code completion does not work as well as before. In Eclipse you have to type first letter of the method name before Ctrl+Space starts working. In Idea you have to press Ctrl+Shift+Space. But the advantage is that everyone can provide their own factory and extend the library seamlessly and consistently.

Super-static variant

code
We can go event further. We can get rid of RequestExpectations interface, remove Mock class and do statically most of the stuff. The test can look like this

import static net.javacrumbs.fluentapi3.StaticFactory.*;

public class MockTest {

	@Test
	public void testMock()
	{
		expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));

		//test code

		verify();
	}
}

It's simple and elegant. We even got rid of the strange and() method. The downside is that we usually have to use some ThreadLocals internally. But it looks almost like EasyMock. Cool.

Inheritance

code
Some people (like me) do not like static methods. It does not feel right, it's not object oriented programming. Can we do something similar, but dynamic? Yes, we can.

We just have to use inheritance. Just delete static keywords from the methods in StaticFactory class. We will also rename the class itself because it's not static any more.

We get

public class MockTest extends MockFactory{

	@Test
	public void testMock()
	{
		expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));

		//test code

		verify();
	}
}

The downside is, that we have to extend our class from MockFactory. Sometimes it's not possible. No problem, we can use a trick I have seen in Apache Camel DSL.

public class MockTest{
	@Test
	public void testMock()
	{
		MockFactory mockFactory = new MockFactory()
		{
			protected void configure() {
				expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));
			};
		};

		//test code

		mockFactory.verify();
	}
}

It's not as elegant as the direct inheritance, but it works. If we are brave enough, we can even use a closure.

public class MockTest extends MockFactory{
	@Test
	public void testMockClosure()
	{
		MockFactory mockFactory = new MockFactory()
		{{
				expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));
		}};

		//test code

		mockFactory.verify();
	}
}

(I bet you did not know that Java has closures already).

So I have shown you four variants, which one is the best? I do not know, each of them has it's pros and cons. I personally like the last one the most. But the super static variant is not bad neither. Or the static? Or some mix between them? Some other? You have to make your own opinion.

References:
http://martinfowler.com/bliki/FluentInterface.html
http://martinfowler.com/dslwip/InternalOverview.html
http://camel.apache.org/routes.html
http://easymock.org/

jOpenSpace – doporučená literatura

Lukáš Křečan — Mon, 28 Jun 2010 13:50:50 +0000

Snad se na mě Satai nebude zlobit, ale ocituji jím doporučenou literaturu z letošního jOpenSpace. Pokud mě moje zápisky neklamou byly to:

Petr Hamerník ještě doporučil V pavučině sítí*. Mezi řečí jsem pochytil doporučení na Krach * a The Long Tail.

Zatím jsem četl ty z hvězdičkou a všechny mohu jen doporučit.

Když už jsme u knih, ještě doporučuji knihkupectví The Book Depository, knihy jsou tam sice dražší než na Amazonu, ale mají dopravu zdarma, takže to ve finále vyjde levněji. Navíc člověk nemusí čekat, až se mu toho nakupí víc.

Vášnivý programátor

Lukáš Křečan — Mon, 28 Jun 2010 10:41:30 +0000

Zrovna procházím seznam doporučené literatury z jOpenSpacu. Dostal jsem se tedy i ke knize Passionate Programmer, kterou napsal Chad Fowler. Nebojte se, nejde o růžovou knihovnu, to jsem jen neodolal pokušení při překladu. Vhodnější by asi bylo použít slovo náruživý.

Kniha má podtitul, který přesně vyjadřuje její obsah: „vytváříme pozoruhodnou kariéru ve vývoji software“. Je prostě o tom, jak dělat práci, která člověka baví a jak v tom být dobrý. Jde o druhé, upravené vydání, první se jmenovalo „My Job Went to India: 52 Ways to Save Your Job“. V druhém vydání se změnil nejenom název, kniha prý byla předělána aby kladla důraz právě na tu „pozoruhodnost“ vaší kariéry.

Jde o takový mix ne příliš navazujících kapitol, které se dívají na práci vývojáře z různých stran. Dočtete se, jak se stát špičkovými programátory, jak o tom dát vědět nadřízeným, jak se neustále zlepšovat, jak si vybrat zaměření a jak se stát slavným. Krása, škoda že už slavný jsem.

Ani moc nevím co bych víc napsal, je potřeba si tu knížku přečíst. Pokud obsah knihy shrnu, tak bychom si měli správně vybrat obor, stát se v něm nejlepší, dát to všem vědět a zajímavá kariéra nás nemine. Zní to sice samozřejmě, ale snadné to není. V knížce se právě dočtete dost triků a tipů jak toho všeho dosáhnout. Doporučuji.

Spring WS Security on both client and server

Lukáš Křečan — Mon, 07 Jun 2010 11:17:13 +0000

Recently, I have been playing with Spring WS with WS-Security. I just want to write down how it works. Do not except anything special, just simple example of basic security operations.

The example

We want to implement both client and server side. The client will sign the message, encrypt some part of it and add a timestamp. To make it more complex and real-life like we will sign the message using private key with alias “client” and encrypt the message using public key called “server”. Server will validate that the request is valid and will just sign the response using his key called “server”. Please note that I have picked Wss4j implementation because the configuration seemed to be easier than Xws.

Client

It's easy to do configure client interceptor like this (full configuration).

...

As you can see, there is nothing special. We just define which actions to take and properties. The only confusing part is, that key alias is defined as “securementUsername”.

Whit this configuration we will get following SOAP message.


	
		
			
				
				
					
						
							
								CN=Test Server,OU=Test
								1275904530
							
						
					
				
				
					fwFM7ShJ1xd7dTGrkh0410sTmW92OPB1q1fpzB21XFIe36siDDJWGgbw5B94yjmGK2YaPOWLb7cpVTYPzc9VUDs7Jc42CtrhT2H6eZ7CDiA60Ugz+qi2UyyfMDK6Vrdj9J68rij5P12AiBeTnd2wlhI29+71XbUpD5weHDHjMtQ=
					
				
				
					
				
			
			
				
					
					
					
						
							
						
						
						AU9utUgz5RylYCRDUAO0JWM48kM=
					
				
				
					NHjjgpb9/alUOq50CqPKLcdYrp7edYdKJDNvIhh+2OAhYdDvZmD1qGsVKd1H9oKPF17uaF2Sv3aY
					0le6BrvzVx3n2+nYYlHwAWlzBk7wsBt4vLll6q6juLCP+siupTIb1PeZDf3WrAbHUQh5oqjD6cZB
					Sc89pDspWRABQ8wPxYE=

				
					
						
							
								CN=Lukas Krecan,OU=Test
								1275900789
							
						
					
				
			
			
				2010-06-07T11:03:35.749Z
				2010-06-07T11:08:35.749Z
			
		
	
	
		
			
				
					
					
						
							
						
					
					
						81TEtUhHXo6iZeAmYrtYlm2ObAqOBpjfzf2VOVUg4Hs=
						
					
				
			
			2

Server config

To configure server, you have to define Spring WS server interceptor like this (full example).

No surprise here neither. The response will look like this.


	
		
			
				
					
					
					
						
							
						
						
						hEdDfxM6Nfs62Jxe8EOsELCDtUk=
					
					
						
							
						
						
						TTSRri5KJqXeMJfjzXyVmUewPxc=
					
				
				
					V5by3bOoGQNajfs7i9xQ+cbAqIkI0NS9N9FQlLb/dAuQfguE7jKRP9iypOeRLHCPr7g3BNg+NCrX
					6YcgDQ0TfXNhdL00AmoEfDmWSNvIVNE49kZEn3Ji/RW4VtdEiV79VD7Vuay0YAYGo9DSQvzq3FP6
					YEhfzfMqvfbWMdEKcO8=

				
					
						
							
								CN=Test Server,OU=Test
								1275904530
							
						
					
				
			
			
		
	
	
		
			3

As we have seen it's possible to configure WS-Security without much hassle. To learn more, visit the official Spring WS reference. You can download full example here.

GeeCON – část poslední

Lukáš Křečan — Mon, 17 May 2010 06:55:57 +0000

Původně jsem chtěl o GeeCONu referovat víc rovnou na místě, ale nějak jsem to nezvládl. Byl jsem tak trochu přehlcen vstupy, takže se to pokusím dohnat teď. O spoustě věcí už psal otec Fura, já se tady pokusím vypíchnout jen to, co mě zaujalo nejvíce.

Let it crash
Jonas Boner

Přednáška bylo o knihovně/frameworku Akka. Zase jsem si připomněl jak funguji aktoři a podobné záležitosti. Vypadá to hodně pěkně a použitelně.

Jelikož jsem mastodont, tak mi to hodně připomnělo vychytanější JMS, ale to se není čemu divit. Celý ten asynchronní přístup je pořád o tom samém.

Hodně se mi líbila softwarová transakční paměť (STM). S tím bych si chtěl pohrát. Možná to zatím není moc užitečné, možná to dokonce podporuje špatné návyky, ale rozhodně to vypadá jako pěkné hračka.
Z přednášky samé mě zaujala následující fakta a hlášky:

Na stroji s 4GB paměti může najednou žít 6,5 milionu aktorů.

V Erlangu umějí dosáhnout spolehlivosti na úrovni 9 devítek (99,999 999 9% dostupnosti)

Teď k vám přednáším a tím měním stav ve vašem mozku. Nedělám to tak, že bych vyndal mozek z vaší hlavy, nezměnil jeho stav a vrátil ho zpátky. (pěkné vysvětlení aktorů)

Java 7 Update
Dalibor Topic

Zajímavé povídání o Javě 7. Ale už si pomalu začínám zvykat. Rozdílem oproti obdobné přednášce na Devoxu 2008 bylo to, že některé věci už mají naimplementovány. Ale nevím, jestli mám věřit tomu, že Java 7 někdy spatří světlo světa. Uvidíme jak se k tomu postaví Oracle.
Po přednášce jsem si odchytil řečníka a snažil jsem se zjistit, jak to bude s tím modulárním systémem, který mi dost nahání hrůzu. Moc mě neuklidnil. Když jsem se ho zeptal, jak to budu dělat, když si budu chtít zvolit JDBC ovladač a nebudu mít classpath, tak mi moc neodpověděl. A to je prosím člověk, který se podílí na části implementace toho modulárního systému! Nezbývá mi, než si stáhnout OpenJDK a vyzkoušet na vlastní pěst.

Squeezing Java Performance: When you need a little more
Thomas Enebo

Hodně zajímavé, ale už to popsal otec Fura. Já jsem se tam dozvěděl, že dlouhé metody nejsou špatné jen z důvodu čitelnosti, ale že s nimi má problém i JVM. Takže tady má dobrý návrh bod k dobru. Bohužel jsem se taky dozvěděl, že za určitých okolností JVMku nedělá dobře polymorfismus, ale to mě neodradí od toho ho používat. (Slyšel jste někdo někdy o tzv. „megamorphic“ stavu? Já poprvé až na GeeCONu).

Apache Camel as a DSL for system integration
Roman Kalukiewicz

Camel mě docela překvapil. Původě jsem myslel, že to je jeden z mnoha dalších ESB nástrojů, ale nakonec jsem zjistil, že je to umí něco navíc. Přednáška se točila kolem jejich DSL, který umožňuje celý ten proces elegantně popsat. Například:

from("jms:aQueue")
  .filter().xpath("/person[@name='Jon']")
  .to("file:c:\tmp");

Snad ani nebudu vysvětlovat, co to dělá, je to samopopisné. Největší legrace je, že mi stačí napsat podobných pár řádků a už se to dá spustit z main metody. Samozřejmě se to dá i zaintegrovat do vašeho oblíbeného serveru. Další věc na kterou se chci podívat.

Abych to shrnul, GeeCON příjemně překvapil. Sice tam nabylo tolik špičkovách řečníků jako třeba na Devoxxu, ale i tak se tam člověk dozvěděl neuvěřitelné množství věcí. Už mám seznam věcí, na které se chci rozhodně podívat. Je vidět, že v oblasti Javy se docela inovuje, i když souhlasím s Dagim, že Jazyk samotný nám tak trochu stagnuje.

GeeCON – cast prvni

Lukáš Křečan — Thu, 13 May 2010 11:22:49 +0000

Tento zapisek pisi z me obstarozni G1, takze cekejte vic chyb nez obvykle a necekejte diakritiku. Pokusim se tu zapsat sve postrehy z GeeCONu - konference, na kterou se mi podarilo vetrit.

Keynote

Keynote byla docela zajimava, tocila se kolem Oraclich planu ohledne Javy.

Vypada to optimisticky, Oracle udajne chce do Javy hodne investovat. A to nejen na serveru, ale pry i na jinych zarizenich.

Velky Lary si dokonce pry hral s JavaFX, libilo se mu to a tak to budou dal rozvijet.

Prezentator byl super, musim se s vami podelit o par jeho hlasek:

Harry Ellison je geek jako vy nebo ja. Jenom ma o trochu vic penez. A lodi. A ma krasnou zenu. Ale jinak je to normalni geek.

Geeks do not have friends, geeks have peers.

There are 300 language implementation runnig on Java. Half of them are Lisps

Co se tyce novinek zaujaly me hlavne tyto dve. Prvni je o tom, ze se chystaji sloucit Hotspot an JRockit. Pokud by se jim to povedlo, tak by to mohlo byt zajimave.

Druha je take potesuji. Snazi se napravit cele to divadlo kolem JCP. Hura

Pak take tvrdil, ze se rozhodne nechystaji zabit ani Glassfish, ani NetBeans a dokonce ani JDeveloper.

Apache Aries

Dalsi prezentace byla o Apache Aries. Mela ji Holly Cummins, ale nejak nebyla ve sve kuzi. Asi to bylo tim, ze uz nema modre vlasy. Nebo tim, ze nepovidala o performance.

Jak jsem pochopil, tak Aries je pokus o pouziti OSGi v Java EE. Neco mezi Spring DM serverem, Felixem a Springem. Je to postavene na nejakem standardu a vypada to docela nadejne. Vic jsem nepochytil. Ale chystam se na to mrknout podrobneji.

Spring Roo
Pak jsem se byl podivat na Spring Roo. Prezentator hodne spatny, demem to trochu vylepsil. Roo je neco jako Grails nebo Rails, ale pro Javu a Spring. Jeste nevim jestli se mi to libi nebo ne, na prototypy by se to ale urcite hodilo. To je zatim vse.

More than 16,000 connections in Tomcat

Lukáš Křečan — Thu, 06 May 2010 12:19:27 +0000

This is just a short update. Last time, I have reached around 13,000 concurrent connections in Tomcat. Based on some comments (thanks IA), I have updated the test.

The most important change is that HttpClient is used instead of standard HTTP connection. Moreover the servlet address is hard-coded, so a new String is not created every time. I do not believe that this change has big impact but the code generates less garbage so GC has easier job.

With this small enhancements, I was able to get more than 16,000 connections running

...
Servlet no. 16354 called.
Servlet no. 16355 called.
Servlet no. 16356 called.
Servlet no. 16357 called.
May 6, 2010 1:21:54 PM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
INFO: I/O exception (java.net.SocketException) caught when processing request: Too many open files
May 6, 2010 1:21:54 PM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry

Again, we get "To many open files". The limit is 32768 and we have two open connections per thread (incoming/outgoing). Theoretically, we could get even higher, but the heap was still filling really fast, so GC was quite slow. And again, threads are not the main issue, the problem is still somewhere else.

The source code is available here.