IDEA vs. Eclipse - je někdo vůbec lepší?

Tento článek bude dalším příspěvkem do nekonečné diskuze, které to IDE je vlastně nejlepší. Nedělám si nároky, že by se mi to podařilo nějak vyřešit, ale cítím potřebu o tom napsat, hlavně abych si to sám srovnal.

Hlavním důvodem k napsání tohoto článku byla skutečnost, že jsem nyní po přibližně 4 letech přešel z Eclipse na IntelliJ IDEA. S Ideou jsem před tím již dělal, bylo to moje vůbec první IDE v Javě, tehdy ve verzi 4 (možná 3, teď již přesně nevím). Pamatuji si, že jsem tehdy za žádnou cenu nechtěl přejít na Eclipse, byl jsem s Ideou maximálně spokojený. Teď jsem změnu z Eclipse na Ideu celkem uvítal, byl jsem zvědavý si vyzkoušet zase něco jiného.

Zde jsou mé osobní pocity a postřehy z obou IDE.

Eclipse 3.3 (resp. MyEclipse 6.5)

• + automatická kompilace kódu při uložení včetně stálého přehledu chyb a varování v celém projektu mi přišlo něco tak samozřejmého, že jsem byl překvapen, že to tak Idea třeba nemá. Auto-kompilaci při uložení jsem si nastavil, s těmi chybami nevím - ukazují se mi jen v rámci daného souboru a nebo při překladu celého projektu, pokud chci znát všechny problémy.
  
• + pluginy, pluginy a pluginy - není žádné IDE, které by mělo takovou komunitu a takové množství pluginů. Ve srovnání s Ideou to může být ale i trochu nevýhoda - spoustu věcí si člověk musí doinstalovat sám, nejsou automaticky součástí. Toto už dneska asi moc problém není - já využívám MyEclipse (obsahuje cca 200 předinstalovaných pluginů) a nebo samotný Eclipse vychází v různých edicích, např. edice pro webový vývoj apod.
  
• + Eclipse platforma se často používá jako základ pro vývoj dalších IDE, jako např. Websphere nástroje. Pak člověk ocení, že se nemusí učit od základu nové IDE, ale že to základní už vlastně zná.
  
• - nejednotný přístup v různých typech souborů. Když chci vybrat slovo, tak bych očekával, že se to stejně bude chovat v Java, HTML, JSP, TXT souborech. Bohužel ne - někde se vyznačí celý výraz, někde jen slovo. Není to prostě jednotné jako třeba v Idee. Asi je to tím, že různé formáty souborů jsou podporovány různými pluginy, mezi kterými není úplná jednotnost.
  
• - slabší podpora webových stránek. Dost často jsem psal JSP nebo JSF stránky a nebylo to úplně špatné, ale při přechodu na Ideu jsem zjistil, že to slabší bylo.
  

IntelliJ IDEA 7

+ klávesové zkratky - pokud někdo v oblibě klávesové zkratky, tak Idea je jasná volba. Myslím, že to mají "vychytaný" :).

• + podpora Springu - SpringSource snad oficiálně vytváří plugin jen pro Eclipse, ale i přes to je v Idee podpora o dost dále (propojení beanů s Java kódem je prostě super).
  
• + all-in-one - nainstaluji a můžu fungovat na 100%. Někdo namítá, že Idea už toho obsahuje až moc - je pravda, že většinu nevyužívám a již dříve ve verzi 4 jsem měl pocit, že to IDE nic více umět ani nemůže.
  
• + podpora Java kódování - již ve 4. verzi Idei jsem byl nadšený z možností refactoringu, nápovědy a podobných věcí, které člověk využije, když programuje čistou Javu. Od té doby Eclipse hodně zamakal a dohnal náskok Idei, ale prostě pořád mi přijde, že Idea je v tomto směru nejdále - takové možnosti refactoringu, takové možnosti analýzy kódu, takové možnosti debuggingu prostě v Eclipse nejsou. Jeden příklad za všechny: provedu analýzu kódu na duplicity. Hned s ukázkou duplicitních částí mám možnost refactorovat - extrahovat duplicitu do jedné metody.
  
• + kombinace s TeamCity a verzovacím systémem nemá chybu. Moc jsem si oblíbil tzv. Remote run - místo samotného "comitu" se nejdříve provede spuštění na TeamCity a pokud vše projde (kompilace, testy), tak pak se teprve provede commit.
  
• - cena. Co k tomu napsat více? Eclipse nestojí nic, MyEclipse začíná na 32 dolarech za rok a Idea začíná na 225 eurech.
  

Závěr

Po přečtení možná budete mít pocit, že jsem velký fanda Idee. Tak to úplně není, dnes už tak netrvám na tom, že musím dělat v tom daném IDE a v ničem jiném. Nadšení z Idei je také určitě dané změnou - dělal jsem dlouho s Eclipsem a teď jsem nadšený z každé nové "fíčurky", kterou objevím.

Sám jsem přemýšlel, zda mohu napsat, že nějaké IDE je lepší než jiné - napsat to nemohu, protože každé má svoje a záleží na každém, co přesně preferuje. Já sám za sebe mám radši Ideu, ale koupil jsem si MyEclipse ...

Proč pořád webové služby?

K dnešnímu článku mě inspiroval můj bývalý kolega, který se jednou naučil webové služby a od té doby je používal úplně všude - bez ohledu na to, že by se mnohdy dalo použít lepší (rozuměj jednodušší, efektivnější) řešení.

Napadá mě zde analogie s EJB. Mnoho lidí se naučí EJB a od té doby je používají bez ohledu na to, zda skutečně EJB kontejner v aplikaci potřebují. Podobné je to i s webovými službami. Webové služby jsou nezastupitelné v komunikaci mezi různými platformami. Jinak řečeno, pokud nemáme všechny komunikující systémy pod kontrolou, tak vždy bude asi nejlepší používat webové služby. Existují i jiné "multiplatformí" protokoly jako např. binární Hessian nebo textový Burlap, ale určitě nejsou tak rozšířené jako webové služby. Co se ale týče jednoduchosti použití a hlavně rychlosti komunikace, tak zde webové služby hodně ztrácejí oproti jiným řešením.

Pokud ovšem máme komunikující systémy pod kontrolou a navíc se jedná o Java aplikace, tak bych webové služby nevolil. V těchto případech většinou nejde o vystavení nějaké trvalé služby, ale o vzdálené volání metod. Pro tyto případy nejvíce ocením jednoduchost použití (tj. jednoduchost při nastavení řešení plus pracnost spojená s úpravou objektů pro přenos) a rychlost komunikace.

Pro tyto případy mám výborné zkušenosti s řešením od Springu - Spring remoting. Osobní zkušenosti mám s použitím HttpInvokeru - víceméně řešení postavené na Java serializaci s přenosem po HTTP. S tímto řešením jsem neměl jediné problémy, fungovalo suprově. Jen jsem musel dořešit jednu věc - kromě vlastních objektů se přenášely i objekty knihoven třetích stran, které občas obsahovaly neserializované objekty (většinou se jednalo o výjimky). V tomto případě jsem si pomohl AOP - vytvořil jsem si AOP vrstvu nad vzdálenými službami, která kontrolovala, zda všechny přenášená data jsou opravdu serializovatelná.

Na posledním projektu používáme Hessian z důvodu požadavku na co největší výkon resp. na přenos co nejmenšího množství dat. Tuto volbu jsme provedli (lépe řečeno mojí kolegové) na základě vlastních měření a ze zkušeností uvedených v tomto článku. S Hessianem pracuji zatím velice krátce, ale již se mi podařilo narazit na problémy s přenosem dat (až budu znát přesné příčiny a řešení, tak to uvedu v komentáři k tomuto článku).

U Spring remotingu se mi také libí, že je to postavené nad DispatcherServletem (stejně jako třeba Spring MVC), takže mohu využívat spoustu společných věcí, zejména Spring security pro zabezpečení.

Pokud nevíte, který protokol vybrat pro vaše řešení, tak si přečtěte výše uvedený článek (zejména závěrečné shrnutí) a nebo doporučení uvedené v dokumentaci Springu.

Jaké dynamické jazyky využíváte? - výsledky

Opět skončila další minianketka, tentokrát mě zajímalo využití dynamických jazyků. Zde jsou výsledky:

1. Žádné (41%)
   
2. Něco jiného (25%)
   
3. Groovy (20%)
   
4. Jython (12%)
   
5. jRuby (2%)
   
6. Scala (2%)
   
7. Rhino (1%)
   

Hlasovalo celkem 62 lidí.

Co k tomu říci? Výsledky mě nepřekvapily, jen by mě zajímalo, jaké dynamické jazyky se skrývají pod položkou "Něco jiného". Když jsem vybíral jazyky do ankety, tak jsem vycházel z tohoto seznamu a snažil jsem se vybrat ty nejpopulárnější, ale asi se mi to moc nepodařilo.

Asi před rokem jsem o dynamických jazycích psal a od té doby se můj váhavý postoj nijak nezměnil. Pořád jsem na tom stejně - pořád nevím, kde bych je mohl sám využít, kde mi přinesou tu tíženou výhodu při vývoji aplikací oproti standardní Javě.

Asi je nebudu využívat přímo, ale přes nějaký aplikační framework jako jsou třeba Grails nebo ZK framework. Jsem hodně zvědavý s čím novým přijde Spring ve spojení s Groovy, když nedávno koupili firmu G2One, které stojí za frameworkem Grails a jazykem Groovy.

S uvedených jazyků jsem používal pouze Groovy a to ve spojení s nástrojem SoapUI. Díky Groovy jsem si mohl napsat vlastní testovací případy a to se mi líbilo.

Také jsem skeptický na větší využití dynamických jazyků s ohledem na většinu (dle mého názoru ano, na většinu) programátorů, kteří se vlastně ani nic nového učit nechtějí - naučí se Javu a pár věcí okolo a myslí si, že jim to bude stačit. Znám to - stačí abych přišel s nějakou myšlenkou využití nové knihovny (natož s použitím nějakého dynamického jazyka) a už vidím tu nutnost přemlouvání, vysvětlování apod.

Spring AOP: Dynamic Proxies vs. CGLib proxies

Pokud jste se někdy více ponořily do AOP resp. vytváření AOP proxy objektů ve Springu, tak jste určitě museli řešit, jaký přístup vlastně zvolit - zda vytvářet proxy objekty pomocí knihovny cglib nebo pomocí JDK.

Oba přístupy mají svoje specifika resp. výhody nebo nevýhody - zde je odkaz na článek, který to celé pěkně shrnuje.


Pokud všechny objekty inicializuje Spring kontejner, tak pak je vytváření AOP proxy objektů zcela automatické (např. pro řízení transakcí) a programátor se víceméně nemusí o nic starat. Někdy je ale potřeba mít vytvořené AOP proxy kolem objektů, které Spring nemá pod kontrolou, např. doménové objekty, které vytváří ORM knihovna nebo nějaké vlastní struktury, kde používáte new.

Spring nabízí následující dvě možnosti řešení:

• vytvářet AOP proxy objekty programově pomocí ProxyFactory.
  
• použít anotaci @Configurable.
  

Více o obou možnostech je uvedeno v dokumentaci ke Springu - Programmatic creation of @AspectJ Proxies a Using AspectJ to dependency inject domain objects with Spring.

Spring certifikace

Mám to! :)

Tento týden jsem napsal testy a získal certifikaci "SpringSource Certified Professional".

Rád bych se s vámi podělil o nějaké mé postřehy či zkušenosti z přípravy a samotného testu.

Člověk musí nejdříve získat "povolení", aby vůbec mohl dělat testy. Povolení lze získat buď tím, že budete absolvovat jejich kurzy na Core Spring a nebo, že prokážete vaší zkušenost se Springem. Já jsem se vydal tou druhou cestou - přišel mi ze SpringSource formulář k vyplnění, na jehož základě mi pak poslali číslo kupónu, které jsem následně použil u certifikační agentury. V dotazníku se mě například ptali na mé dosavadní zkušenosti se Springem na projektech (musel jsem uvést nějaké referenční osoby jak z mé firmy, tak od zákazníka, pro jakého zákazníka to bylo, jaké části Springu jsem využil, jaké jiné open-source knihovny jsem použil), zda nějak přispívám do Spring komunity, zda nějak pomáhám v osvětě Springu apod. Celkově jsem z toho měl pocit, že si tak nějak dělají přehled o tom, na co se vlastně Spring používá, pro jak velké zákazníky a kdo vlastně žádá o tu certifikaci. Nemám žádnou zpětnou vazbu, že by byl někdo z mnou uvedených lidí kontaktován za účelem ověření informací. Doposud jsem dělal pouze certifikace u Sunu, proto mě toto celkem zaskočilo, nicméně jsem prošel a mohl jsem na zkoušku.

Ukázkové testy jsem nenašel žádné (ani na černém trhu :) ) a musel jsem si vlastně vystačit jen s dokumentací od Springu - JavaDoc a referenční dokumentace. SpringSource nabízí přehled oblastí k certifikaci a nějaké ukázkové otázky z testu - sice tam nejsou stejné odpovědi jako v reálném testu, ale otázky tak nějak sedí, bohužel jen tak ze třech oblastí. Ještě jsem našel nějaké podklady zde, ale to je spíše přehled nějakých základních termínů.

Samotný test má 50 otázek, je na to 90 minut. Každá oblast má pět otázek, což aspoň pro mě nebylo zrovna příjemné, protože o Spring Core nebo o Spring MVC toho vím hodně, ale takové JMX nebo JMS jsem nikdy moc (bohužel) nepoužíval. Vše ale mělo stejnou váhu. Také jsem se dost bál všech těch názvů tříd a rozhraní, které Spring má. Teď již vím, že jsem se spoustu věcí učil zbytečně, je opravdu potřeba znát jen ty hlavní, jako např. JdbcTemplate, HibernateDaoSupport, JmsTemplate atd. Otázky byly hodně zaměřeny na obecné znalosti spojení Springu a dané technologie (např. v čem všem mi může pomoci Spring ORM modul při práci s Hibernate), na často používané termíny (např. definice advice nebo aspektu) a někdy i na samotné technologie (např. jaké komunikační protokoly jsou definovány ve specifikaci JSR-160 pro JMX?). Je pravda, že někdy jsem se musel podívat i do jiné dokumentace než od Springu.

Kdo už někdy psal nějaké podobné testy, tak ví, že je potřeba si dát pozor na každé slovíčko, jak v otázce, tak v odpovědích. Každá otázka měla žádnou, jednu nebo všechny správné odpovědi.


PS: Někde jsem našel, že letos přibudou ještě další certifikáty:

• SpringSource Web Technologies Professional
  
• SpringSource Advanced Methodologies Professional
  
• SpringSource Integration Professional
  
• SpringSource Application Management Professional