středa 8. dubna 2009

Micro-blogging jako nástroj pro zlepšení týmové komunikace

Některé myšlenky začínají opravdu kouzelně. Včera za mnou přišel jeden z kolegů pozeptat se, jestli náhodou nemám nabíječku na jeho typ mobilního telefonu. Při té příležitosti utrousil otázku, co si jako zasloužilý bloger, myslím o využití formátu micro-blogging pro zlepšení komunikace mezi týmy. Nejdřív jsem nechápal na co se mě pta, ale pak mi vysvětlil, že micro-blogging je například Twitter, který právě vidí na displeji mého notebooku.

Pokud o Twitteru nic nevíte, doporučuji seriál, z kterého jsem si dovolil použít následující popis:

Twitter je instant messaging (nástroj pro výměnu okamžitých sdělení) dostupný z webové stránky. Na Twitteru můžete publikovat svoje příspěvky (takzvané Tweety) o délce maximálně 140 znaků. Když na Twitteru někoho následujete (following), můžete číst jeho příspěvky, sdělení. Když oni (followers) následují vás, mohou číst vaše příspěvky.

Pokud pracujete ve větším týmu, třeba jako já, je občas problém udělat nějaké krátké sdělení a o něco zajímavého se podělit s vašimi kolegy. Můžete najít užitečný nástroj, zajímavý článek, chystáte se udělat nějaký větší zásah a nejste si jistí jeho vedlejšími efekty, či něco podobného. V takovém případě máte dilema, můžete to poslat na společný mail, ale zase to muže být informace, která nezajímá všechny. Jinými slovy, ředitele našeho centra asi nebude zajímat, že vyšla nová verze Mavenu. Vytvářet kvůli tomu příspěvek do blogu je zase moc pracné a navíc to většinou předávaná informace nemá hlubší charakter.

Micro-blogging je právě úžasným kompromisem mezi mailem a regulérním příspěvkem pro blog, někde jsem viděl přirovnání SMS přes internet. Zprávu vidí všichni kdo vás následují a vy tak neotravujete další spoustu lidí, které pravděpodobně o vaše komentáře nemají zájem.

V našem případě by se systém alá Twitter dal integrovat s vývojářskými nástroji. Občas se stane, že rozbijete build. V takovém případě je na build serveru vidět kdo to rozbil, ale už není vidět, jestli na tom ten člověk pracuje. Ta informace jestli na tom člověk pracuje, či jestli vůbec ví o tom co způsobil, by se dala integrovat právě přes systém alá Twitter. U rozbitého buildu by bylo tlačítko, které by po kliknutí vytvořilo automaticky tweet. Na build serveru by se zase naopak reverzně k zbořeným buildum asociaovaly tweety.

Já osobně jsem myšlence zapojení micro-bloggingu jako součásti mezi týmové komunikace velice nakloněn. Stejně jako na Twitteru se při použití za zavřenými dveřmi uvnitř firmy najdou hvězdy, které bude sledovat většina a také pasivní uživatelé, které nebude sledovat skoro nikdo. Díky tomu bude zaručena přirozená rovnováha mezi tím, že podstatné informace od lidí, co mají co říci, proudí ke všem a ty méně podstatné míří pouze k několika málo zainteresovaným.

neděle 5. dubna 2009

Tranzitivní závislosti v Mavenu z pohledu návrhu modulu

Tranzitivní závislosti v Mavenu neodpouštějí chyby v návrhu struktury modulů. Pojďme se podívat na to s čím je potřeba počítat. Mějme modul Foo. Tento modul je použit jednak v kontextu serveru, jako součást webové aplikace, a jednak v lokálním kontextu jako součást command line nástroje. Modul Foo má pro svojí řadu několik závislostí. Řekněme jednu společnou pro obě prostředí a potom dvě rozdílné množiny, každou pro jedno prostředí, jak je znázorněno na následujícím obrázku.

Mechanismus tranzitivních závislostí v Mavenu způsobí, že pokud modul Foo přidáme do WARu, dostanou se nám tam všechny závislosti a to včetně těch lokálních (žluté krabičky). A naopak, pokud si necháme vygenerovat například classpath pro lokální použití, dostanou se nám tam závislosti nutné pouze pro prostředí serveru. V případě, že by šlo pouze o malé množství závislostí, asi by to nevadilo, ale v případě, že se jedná o větší množství, musíme se tím začít zaobírat.

První a nejlepší způsob je udělat refaktor modulu Foo a ten rozdělit na tři části. Na modul obsahující logiku pro server Foo server, modul obsahující logiky pro lokální použití Foo local a modul obsahující logiku společnou pro obě části Foo common. Tento poslední modul vznikne pouze za předpokladu, že existuje sdílená logika. Zároveň s rozčleněním do těchto modulů roztrhneme i závislosti původního Foo modulu. Ideální stav zobrazuje následující obrázek.

No nežijeme v ideálním světě a tak se může ukázat, že modul Foo půjde refaktorovat velice složitě, pokud vůbec, neboť se může jednat o dědictví z minulosti. V takovém případě máme dvě možnosti. Tam kde modul Foo chceme použít, uděláme nechtěným závislostem přítrž jejich explicitním vynecháním. Toto řešení má tu nevýhodu, že na každém místě použití modulu Foo musíme tento manuální krok zopakovat. Pokud nám v budoucnu nastane situace, že modul Foo bude potřebovat novou závislost, řekněme kolizní závislost, ať již pro serverové či lokální prostředí, budeme muset opravit manuální odstranění o další závislost.

Druhou možností je využití takzvaných volitelných (optional) závislostí, které mají tu vlastnost, že nejsou součástí tranzitivního uzávěru. Na dalším obrázku jsou volitelné závislosti vyznačeny čárkovaně. Díky tomu, že nejsou součástí tranzitivního uzávěru, tak je sice moduly, které je používají "nenakoupí", ale zároveň to znamená, že je budou muset opět explicitně uvést tam kde budou potřeba. To ilustruje následující obrázek, kdy si WAR explicitně přidává volitelné závislosti.

I toto řešení má stejnou nevýhodu v podobě manuálního opakovaní všech volitelných závislostí na každém místě použití a s tím spojený problém budoucího rozšíření. Pro eliminaci této nevýhody lze použít následujícího triku. Zavedeme si speciální moduly pro obě prostředí, které nám poslouží pouze k seskupení závislostí. Díky tomu budeme mít management závislostí pro dané prostředí centralizovaný pouze do jednoho místa. Tyto ad hoc moduly je pak možné použít namísto původního modulu Foo.

Tento seskupovací workaround lze použít v podstatě na úpravu jakýchkoliv nevyhovujících závislostí a lze jej vhodně kombinovat s explicitním vynecháním závislostí. Je škoda, že Maven nenabízí podobný mechanismus urovnání závislostí nějakým lepším způsobem. Na druhou stranu na to lze koukat i tak,že Maven vynucuje správné rozčlenění modulů a schválně nenabízí prostředky pro jejich obcházení.