21. února 2009

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 ...

10. února 2009

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.