pátek 16. března 2007

Dáte si džus? Máme Google Guice.

Pod křídly, která poskytla firma Google, vzniknul velice zajímavý projekt inversion of control frameworku postaveného na vlastnostech Javy 5 - anotacích a generikách. Framework nese název Guice, celým názvem Google Guice a vzniknul na základě potřeb aplikace AdWords. Další zajímavostí je, že se Guice hrdě hlásí k Spring frameworku.

V Google Guice IoC se vazby mezi objekty vyjadřují čistě pomocí kódu, slouží k tomu speciální API. Jeho prvním stavebním kamenem je takzvaný modul, ve kterém se popisuje základní mapování. Druhým kamenem je anotace @Inject pomocí, které se frameworku řekne, že má dojít k vložení závislosti.

Mějme třídu Car, která používá implementaci Engine, ta může být implementována různými typy motorů.

public class Car {
  public Engine engine;
  
  public void start(){
    engine.start();
  }
  
  @Inject
  public void setEngine(Engine engine) {
    this.engine = engine;
  }
}
public class BasicModule extends AbstractModule {
  @Override
  protected void configure() {
    bind(Engine.class).to(EngineHDi.class);
  }
}

Z pohledu Guice máme modul (potomek specifické Guice třídy - ), který umožňuje pomocí API definovat mapování mezi rozhraním Engine a jeho implementací. V našem případě EngineTDi. Car obsahuje anotaci @Inject, kterou v tomto případě říka Guice frameworku: Až budeš požádán o vytvoření třídy Car, vlož podle mapování danou Engine implementaci.

Aby mohl Guice fungovat musíme ho samozřejmě zinicializovat a pak požádat o danou třídu.

public class Main {

  public static void main(String[] args) {
    BasicModule module = new BasicModule();
    Injector injector = Guice.createInjector(module);
    Car car = injector.getInstance(Car.class);
    car.start();    
  }

}

Jak vidíte celé IoC se řídí čistě pomocí kódu, není nutné žádné XML. To má za výhodu, že není potřeba speciální vývojová rozšíření pro správu kódu. Díky tomu funguje v IDE například bezproblémově refaktorizace.

Nyní si představme situaci, že bychom chtěli mít pro Engine dvě různé implementace (EngineTDi a EngineHDi) a každou bychom chtěli vkládat podle nějakého klíče. Rozlišovací klíč může být v případě Guice anotace.

Pro rozlišení motorů jsem se rozhodl vyrobit si anotaci @Octavia.

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Octavia {

}

Nyní v mapování, které definuji v modulu, nastavím pro Engine implementaci EngineTDi rozlišenou anotací @Octavia.

public class BasicModule extends AbstractModule {
  @Override
  protected void configure() {
    bind(Engine.class).to(EngineHDi.class);
    bind(Engine.class).annotatedWith(Octavia.class).to(EngineTDi.class);    
  }
}

Pro ilustraci jsem vytvořil třídu Skoda, která je potomkem třídy Car. To důležité na kódu této třídy je použití anotace @Octavia, která říká ve spojitosti s anotací @Inject, že Guice má podle mapování vytvořit EngineTDi.

public class Skoda extends Car {
  private Color color;
  
  @Inject
  public void setEngine(@Octavia Engine engine) {
    this.engine = engine;
  }
}

Při volání Skoda skoda = injector.getInstance(Skoda.class); pak IoC framework skutečně nastaví EngineTDi.

Další vastností tohoto IoC frameworku je mapování konstant. Opět si budeme demonstrovat na našem příkladu s auty. Mějme vyčtový typ Color.

public enum Color {
  RED, BLUE, BLACK, WHITE;
}

Nyný si libovolnou barvu namapujeme jako konstantu a tuto konstantu necháme Guicem vložit. Pro rozlišení jednotlivých konstant použijeme anotaci (můžeme použít i typ konstanty).

public class BasicModule extends AbstractModule {
  @Override
  protected void configure() {
    bind(Engine.class).to(EngineHDi.class);
    bind(Engine.class).annotatedWith(Octavia.class).to(EngineTDi.class);
    bindConstant().annotatedWith(RedColor.class).to(Color.RED);
  }
}

Následuje rozšířený kód třidy Skoda o barvu. Guice se opět dozví o nutnosti přiřazení závislosti pomoci anotace @Inject. Kód ilustruje, že Guice nemusí pro vkládání závislostí používat pouze metody se setter konvenci, ale libovolné metody. Lze anotovat i jednotlivé proměnné, tomu Guice samozřejmě také rozumí.

public class Skoda extends Car {
  private Color color;
  
  @Inject
  public void setEngine(@Octavia Engine engine) {
    this.engine = engine;
  }
  
  @Inject
  public void color(@RedColor Color color){
    this.color = color;
  }
  
  public Color getColor(){
    return color;
  }
}

Guice IoC má další vlastnosti, některé z nich zmíním pouze bodově.

  • scopes - pro každé mapování můžeme určit, jestli bude objekt z pohledu frameworku Singleton (jedna instance pro všechna volání) nebo Prototyp (kolik volání tolik instancí)
  • providers - umožňuje delegovat vytvoření daného obektu na konkrétní třídu (factory). To se hodí v případě kódu, do kterého nemůžeme dodat anotace např. knihovny třetích stran.
  • lazy inicializace - inicializace objektů je odložena na první požadavek
  • interceptory - umožňuje namapovat třídu (interceptor) na volání metody, která má danou anotaci

Google Guice o sobě hrdě prohlašuje, že se jedna o "lehkotonážní" IoC framework a má pravdu. Práce s ním je opravdu velice jednoduchá a přímočará. Pokud hledáte srovnání se Spring IoC, tak mohu sloužit následujícím linkem do Guice wiki SpringComparison.

Z mého osobního pohledu přináši Guice svěží vítr, nicméně konfiguraci pomocí anotací i pomocí kódu Spring zvládá taktéž viz má prezentace na CZJUG. Jednou z užitečných vlastností, které Spring nabízí navíc jsou takzvané BeanPostProcessory, které umožňují modifikovat danou beanu, před tím, než jí kontejner vystaví. Samozřejmě v budoucnosti zde budou (možná již jsou) řešení, která umožní Spring a Guice používat dohromady.

Pokud hledáte pouze IoC framework pak Guice stojí za otestování a prozkoumání všech jeho možnosti. Další pohled na Guice nabízí oživený Jablok rukou Pavla Kolesnikova v článku s příznačným názvem Google Guice.

Můžete si stáhnout zdrojový kód výše uvedených příkladů.

Související články

úterý 13. března 2007

Cenová politika Microsofu: výsměch nebo políček do tváře?

Aktualizace: tímto se Microsoftu omlouvám, zdá se, že tento upgrade je opravdu za minimální peníz viz Windows Vista Alternate Media.

Před týdnem jsem si koupil nový počítač a samozřejmě, že jsem nainstaloval operační systém Windows Vista. Říkal jsme si, zkusím to a uvidím, pokud budu spokojený, jsem ochoten si Visty koupit. Spokojený jsem, ale když jsem viděl cenovou politiku firmy Microsoft, nevěděl jsem, jestli je to výsměch a nebo jestli my chtěli vlepit facku, abych se probral.

Nebudu zde polemizovat o částce za samotný operační systém. To, co mě doslova poslalo do kolen, je nemožnost upgradování v rámci Visty za výhodnou cenu. Mám 64 bitový procesor nicméně nainstalovanou mám 32 bitový verzi operačního systému. Volbu 32 bitové verze za mě udělala nedostupnost ovladačů a programů, které bych na 64 bitové verzi nomohl rozběhnout.

Selským rozumem jsem očekával, že upgrade z 32 bitové verze na 64 bitovou bude buďto zdarma a nebo za mírný poplatek. Vykládal jsem si to tak, že to bude vstřícný krok Microsofru k uživateli: Teď používej 32 bit a za rok, až budou k dispozici drivery plus programy a všechno si sedne, budeš moci levně přemigrovat na 64 bitovou verzi, která využije potenciál tvého hardwaru.

To jsem se přepočítal, nic takového Microsoft nenabízí. Peníze utracené za "neperspektivní" 32 bitovou verzi bych vyhodil oknem, protože bych při přechodu na 64 bitovou verzi neměl žádnou výhodu. Tento přístup mi přijde přesně podle pořekadla:krávu je třeba dojit, dokud mléko dává. To už ani nemluvim o OEM verzi, které je svázaná se základní deskou a při upgradu máte prostě smůlu.

Pokud bych měl použít příměr z reálného života, tak Microsoft se chová jako obchodník, který mi prodává auto, jehož motor jezdí pouze na nízkooktanový benzín. Pokud bych chtěl v budoucnu přejít na víceoktanový benzín, tak bych si musel koupit uplně nové auto, místo toho, abych si například zaplatil pouze za upgrade motoru.

Z mého pohledu je cenová politika firmy Microsoft ohledně operačního systému Windows Vista velkým zklamáním. Jestli jsem dříve uvažoval o tom, že bych si Visty zakoupil, tak teď už jsem rezignoval. Nehoráznost v podobě ceny při přechodu z 32 na 64 bitů mě slušně řečeno naštvala. Já osobně dojnou krávu Microsoftu dělat nebudu, nechám doběhnout zkušební dobu a pak přejdu na Ubuntu.

pondělí 12. března 2007

Eclipse Jazz

Pro příznivce hudby předesílám, že Eclipse Jazz není festival jižanských hudebníku s afro americkými rysy pořádaný při nejbližším zatmění slunce. Eclipse je vývojová platforma a to po čertech dobrá platforma, nicméně i Eclipse potřebuje inovaci. Proto se v laboratořích IBM začalo pracovat nad řešením, které Eclipse rozšíří z vývojové platformy do collaboration platformy s názvem Jazz.

Pokud se ptáte jaký je rozdíl mezi vývojovou platformou a collaboration platformou (zkuste mi dát český ekvivalent), tak zkusím nabídnout svojí definici. Vývojová platforma je spíše zaměřená na samotný vývoj na úrovni kódování/ladění. Oproti tomu collaboration platoforma je orientovaná na proces vývoje jako celek a snaží se o zefektivnění práce v týmu.

Proces vývoje se skládá z různých etap (fází): analýza, design, prototyp, implementace, testovaní. Jazz má za cíl integraci nástrojů, které softwárové tými používájí v rámci procesu vývoje a zároveň od nich sbírá data nazpět a tím nabízí možnost celý proces efektivně sledovat a řídit.

Here is an example: A build breaks due to a JUnit test failure. With Jazz you create a bug to track this failure; Jazz links the bug to both the build and the failed test. The bug is assigned to a developer and the developer eventually delivers the fixes to the team. The change set corresponding to the fix is linked to the bug. When the change set is built, another link is established between the build and the change sets. You now have traceability from a failed test to the corresponding source changes and builds. This is achieved without turning team members into bookkeepers. Finally, all these events can be observed using RSS feeds. All the information is available to everyone.

Výše uvedená citace je z rozhovoru Evolving Eclipse to Jazz, an Interview with Erich Gamma, kde najdete další informace o tomto zajímavém projektu.

Celá myšlenka platformy umožňující kompletní spolupráci, sledování a řízení softwárového projektu mi přijde otřepaná. Netuším jestli se o to někdo pokusil v minulosti, ale protože o ničem takovém není moc slyšet, tak bych hádal, že to moc úspěšné nebylo. Právě Eclipse má potenciál na to, aby ukázal, že myšlenka collaboration platformy má budoucnost.

Jsem přesvědčený o tom, že IDE tj. vývojové platformy, jak je známe dnes, tu budou ve stejné podobě dále. Na druhou stranu mi přijde, že vývoj směrem k nástrojům umožňujícím obsáhnout celý vývojový proces má smysl. Uvidíme jestli se Jazzu podaří být stejně otevřeným řešením, co domožnosti rozšíření, jako je Eclipse platforma.

Související články

neděle 11. března 2007

Záznam přednášky o Spring 2.0

Pokud jste nebyli na mojí prezentaci o Spring 2.0, kterou jsem měl v rámci lednového setkání CZJUG a máte zájem se něco o Springu dozvědět, tak si můžete prohlédnout/poslechnout video/audio záznam. K dispozici je samozřejmě i vlastní prezentace (PDF). Samotný záznam obsahuje rovněž prezentaci Martina Krajčího o JPA. Obě prezentace jsou vhodné pokud si chcete udělat celkový obrázek o těchto dvou technologiích.