čtvrtek 26. února 2009

Efektivita buildovacích nástrojů rozhoduje

Po té co jsem si pročetl článek Maven or Ant, který raději vůbec nečtěte neboť je plný nesmyslů, jsem se rozhodl, že letmo nakouknu na Gradle, jestli třeba náhodou ten Maven... Hned na úvodní stránce jsem si přečetl, že je to v podstatě přes Groovy obalený Ant s dependency managementem řešeným přes Ivy či Maven. Abych to zkrátil, po letmém prolétnutí Gradle user guide jsem spokojeně zavřel prohlížeč a řekl si, že touto cestou opravdu ne.

Gradle bude určitě skvělý systém, ale bohužel nenaplňuje jednu fundamentální potřebu, alespoň tedy co se mojí maličkosti týká. Nevím jestli to máte jinak, ale já od buidlovacího systému (degradujme na tento termín nástroje - Ant, Maven, Gradle, Gant atd.) očekávám především efektivitu vyjádřenou poměrem mé snahy oproti tomu co na mě vypadne.

Tím chci říci, že množina mnou aplikovaných případů užití je redukována na vytvoření projektu, kompilaci, puštění testů, zbuildování vysledného package a natažení projektu do IDE. Tečka, nic víc. Jízlivá otázka, potřebujeme vůbec něco víc? Odpověď nechám na Vás. Čím jednodušeji budou splněny tyto případy užití z pohledu buildovacího systému, oproti tomu co budu muset udělat, tím větší efektivitu my ten systém přinese.

Maven mi zatím přináší nejvyšší efektivitu. Už jenom vytvoření projektu přes archetype je otázka půl minuty. A od toho se samozřejmě odvíjí i další případy užití. Oproti tomu systémy jako Gradle nebo Ant mě nutí k něčemu co je mi ze srdce odporné a to k programování vlastního buildu. Kdy už konečně autoři těchto systémů pochopí, že jejich uživatelé nechtějí řešit takové problémy, že je někde potřeba uvádět (programování je jenom forma zápisu) cosi ohledně kompilace, packagingu apod. oni prostě ten systém chtějí používat!

Proto mám tak rád Maven. Jeho autoři totiž pochopili, že pro běžné developerské použití by měla být námaha s tím spojená rovna pokud možno nule. Samozřejmě pokud pomineme čtení nějakoho howto či dokumentace, které nás čeká při začátku používání jakékoliv nové technologie.

středa 25. února 2009

Instantní IDE

Jak hodně je vzdálená myšlenka IDE, které poběží v prohlížeči? Když jsem se poprvé dozvěděl o tomto konceptu, tak jsem si neuměl představit, jak by to mohlo fungovat. Odpověď mi dal projekt Bespin, ke kterému vzniknul na Eclipse postaveny backend. Ta myšlenka je docela jednoduchá, v prohlížeči běží jenom vlastní editor, všechny úlohy jsou na pozadí nebo formou uživatelem zadaných příkazů posílány na server, kde se vykonají a zpět jsou poslány jejich výsledky.

Za tímto účelem Bespin definuje server API, které představuje bridge mezi klientskou a serverovou stranou. Bespin je standardně dodáván se serverovým backendem postaveným na Pythonu. Tento backend je ovšem jednoduše vyměnitelný.

The Eclipse IDE, as you know it, is an OSGi-based application, and is built entirely out of components (called plug-ins or bundles). Many of these components can run headless, on a server, such as the underlying resource model, the incremental Java compiler, etc. Using the headless components, it was very easy to implement the Bespin client-server API.

Chvíli jsem si zkoušel s Bespinem upraveným pro editováni Javy hrát a mám z toho dva silné dojmy. Ten první se dá jednoduše vyjádřit zvoláním funguje to! Například kompilační chyby jsou reportovány v editoru. Ten druhý se dá charakterizovat jako pěkné na efekt, ale prakticky nepoužitelné. Dlužno dodat zatím.

Komfort desktopového IDE je o světelnou glaaxii někde jinde. To je samozřejmě pochopitelné, protože desktopová IDE ušla pěkně dlouhou cestu a o Bespinu se nedá snad ani říci, že by byl v plenkách. Zkusme se na chvíli od tohoto faktu oprostit a zamyslet se nad tím, co by nám mohly IDE běžící v browseru přinést. Těch výhod oproti klasickému desktopovému IDE vidím několik.

Jako první věc člověka napadne, že výhodou bude přítomnost IDE všude tam kde máme webový prohlížeč. To sebou nese celou řadu ne tak docela patrných kladů. Nemusíme se tak starat na každém počítači kde pracujeme o setup IDE, checkout projektů, různé nastavení buildování atp. To vše leží nastaveno někdo na serveru a já jako vývojář se o to nemusím starat.

Díky tomu, že vše leží někde na serveru, nemusím zmiňovat maličkosti je zálohování. Bude například jednoduché udělat upgrade na novější verzi IDE. Kolikrát se vám stalo, že jste potřebovali rychle něco upravit, ale IDE se zrovna rozhodlo, že potřebuje uvolnit naalokovanou paměť a nebo, že vám na pozadí běžela úloha, která práci IDE zpomalovala. V případě na serveru běžících komponent to není problém a myšlenka využití cloud computingu se přímo nabízí. Na jednou nehrozí, že by bylo málo místa na disku, výpočetního výkonu a nebo paměti.

Předpřipravené prostředí je další výhodou webových IDE. Žádné stahování Eclipse, Javy, nastavení Mavenu či Antu. Prostě se jenom přihlásíte a je to. Něco jako instantní polévka, nasypete do hrníčku a zalijete horkou vodou. Někdo v souvislosti s webovými IDE často mluví o takzvaném kolaboračním případu užití. Například editujete soubor a váš kolega ve svém IDE vidí co přesně děláte. Osobně se mi nezdá zatím nijak zvlášť silný, ale třeba začnou sociální sítě pronikat i do této oblasti.

Webová IDE mají budoucnost, nedá se asi očekávat, že tu budeme mít v nejbližší budoucnosti IDE pro Javu či .NET, které bude konkurovat dnešním desktopovým IDE. Spíše se dá očekávat pozvolný nástup a to v oblasti dynamických jazyků a webových technologií jako Ruby nebo PHP, kde je vývoj o poznání jednodušší než v Jave.