Vytvořit chytré hodinky se snaží hromada výrobců. Nekterým se to daří lépe a některým hůře. U Pebble na to šli trochu jinak. Hodinky jsou v podstatě pouze externí zobrazovací jednotkou pro mobilní telefon a navíc umějí zobrazovat kolik je aktuálně hodin. Nic víc, nic míň. Faktem zůstává, že ve chvíli, kdy výrobce konečně uvolní SDK hodinek a bude možné vytvářet vlastní aplikace, hodinky se možná stanou nečím více. Další věcí, kterou celý koncept hodinek trpí jsou různá softwarová omezení operačních systémů mobilních telefonů, které zážitek z používání hodinek trochu kazí. Ale pojďme se na ne podívat podrobněji.

Design

Design na první pohled působí levným a strohým dojmem, který se na první pohled neliší od jiných levných digitálních hodinek. Celoplastová konstrukce, která je z vnější strany lesklá je okamžitě plná otisků prstů a pokud své hodinky nebudete pravidelně čistit, budou působit upatlaným dojmem, což jim na exkluzivitě nepřidá. Gumový pásek hodinek exkluzivnímu vzhledu také moc nepřidá.

Hodinky mají zaoblený tvar, který je doplněn o čtveřici tlačítek, kterými je možné hodinky ovládat. Na levém boku je tlačítko Zpět, kterým je zároveň možné aktivovat podsvícení displeje. Na straně druhé jsou tlačítka tři. Horní a dolní slouží o posun textu, popř. pohyb v menu nebo přepnutí typu zobrazovaného číselníku hodinek. Prostřední tlačítko slouží pro vstup do menu. Tlačítka jsou velká s dobře hmatatelná i po slepu. Na levé straně se, kromě tlačítka zpět, nacházejí ještě magnetické kontakty pro dobíjení, podobně jako u Mac booků je konektor MagSafe. Zde bych si dovolil výtku k síle použitých magnetů, která je nedostatečná a nabíjecí konektor se i při sebemenším pohybu hodinek odpojí.

Displej je černobílý a dobře čitelný. Proklamace, že se jedná o e-Paper displej je poněkud matoucí. Může totiž vyolat dojem, že se jedná o displej, který používají elektronické čtečky knih (např. Amazon Kindle). V Pebble je použit transreflektivní LCD displej. Ten je také dobře čitelný na slunci a spotřebu má minimální. O proti eInk technologii navíc umožňuje animaci a není potřeba při překreslování obnovit celý displej.

Přijemnou vecí je vestavěný akcelerometr, který v současnosti slouží pouze k aktivování podsvícení displeje pohybem rukou nebo klepnutím na displej hodinek. Potěší i vybrační motorek, který signalizuje příchozí hovory, SMS a podobně. Jen by na můj vkus mohl být jemnější. Přeci jen, zápěstí je dostatečně citlivé a nepotřebuji při každé SMS mít pocit, že se mi někdo snaží utrhnout ruku.

Spolupráce s telefonem

Pebble se vůči telefonu tváří jako klasické Bluetooth zařízení. A v tom je také kámen úrazu. Nevím, jak to funguje na Androidích telefonech, ale u iPhonu je nastavování spolupráce hodinek s telefonem hromada omezení a workaroundů. Aplikace Pebble, kterou je nutné nainstalovat v neumí zatím nic jiného než instalovat nové ciferníky a aktualizovat software hodinek. Vše ostatní je nutno provést ručně a troufám sí říci, že laik by s tím nemusí umět poradit. Zejména i pro to, že některé chování je úplně nestandardní.

Faktem je, že ty standarní notifikace, jako je příjem hovorů, SMS nebo iMessage, vše funguje korektně a správně. Když vám někdo volá, pohledem na hodinky zjistite kdo a pomocí příslušného tlačítka na hodinkách hovor můžete odmítnout nebo přijnout. To samé je se zprávami, které si můžete číst přímo na displeji hodinek. Pěkné.

U ostatních aplikací je to jinak. A bohužel horší. Obecně nastavování notifikací na hodinkách je v případě iOS řešeno jistým workaroundem, a to, že musíte vypnout a zapnout zobrazování notifikací na zamčené obrazovce, když máte připojené hodinky přes bluetooth. Pak vše funguje tak, jak má. Jenže pokud se hodinkami vzdálíte od telefonu a spojení mezi telefonem se přeruší, musíte toto kolečno pro všechny aplikace absolvovat znovu a znovu, kdykoliv se spojení přeruší. Opruz, který mě přestal okamžitě bavit. Abych byl fér, je potřeba se v tomto zastat Pebble. Jedná se o omezení operačního systému telefonu a nejšíš tedy neřešitelný problém.

A když už jsme u notifikací, je to ještě jedna věc. A tou je diakritika. Znaky s háčkem nebo čáskou se na displeji hodinek zobrazují jako čtverečky. Ale na to si už našinec muse chtě nechtě zvyknout.

Používání

K dílenskému zpracování jsem se už vyjádřil. Teď ještě ke gumovému pásku, který jsem už zmiňoval. Prostě není dobrý. Ruka se pod mín potí. Navíc je řemínek tak krátký, že ho musím mít zapnutý na předposlední dírce. Přeska, která pak má držet konec pásku tak, aby netrčel a nepřekážel, přestává plnit svou funkci.

Co je však dokonalé je to, kvůli čemu hodinky vznikly. Zobrazování notifikací z telefonu. Celý zažitek je pak umocněn v kombinaci s hands-free, kdy hovor můžete zvednout pomocí hodinek, SMS jízdenku revizorovi ukázat na hodinkách. Můžete si pouštět, přepínat a zastavovat muziku (aktuálně přehrávaná písnička se zobrazuje na displeji hodinek). Telefon má autonomní budík, který budí vybracemi. Výhodou je vodotěsnost hodinek do pěti atmosfér. Na potápění to není, ale zaplavat si do bazénu klidně.  Fajn je také možnost měnit si ciferníky hodinek podle nálady a věřím, že až se uvolní SDK, spusta vývojářů (včetně mě) se pustí do vývoje aplikací, který umocní zážitek z používání hodinek. Potenciál ne nekonečný. Běžci, cyklisté, bruslaři. Ti všichni by ocenili mít aktuální informace o svém výkonu na svém zápěstí.

Výdrž baterií je podle výrobce týden. Já musel baterii nabíjet po čtyřech dnech. Výrobce však tvrdí, že se jedná o chybu ve firmware, a že ji opraví updatem. Kde jsem to jen už slyšel?

Závěrem

Na hodinky jsem si velice rychle zvykl a i přes některé omezení jsou skvělým doplňkem, díky kterému nebudete muset při každém zazvonění telefonu jej vytahovat z kapsy, ale jen pohledem na ruku zjistíte, jestli má smysl se v danou chvíli telefonem zabývat. Na škodu je jeho laciný vzhled (díky použítí lesklých plastů). Uvidíme, jak budou vypada barevné varialnty, ale obávám se, že lakovaný plast nebude o moc větší výhrou. Ovšem to, co se skrývá uvnitř plastového šasi, překoná veškeré nedostatky. Koupit, či nekoupit? Na tuhle otázku nelze jednoznačně odpovědět. Asi bych poradil počkat ještě pár měsící. Cena jistě půjde dolů, výrobce vychytá některé mouchy a začnou vznikat nové aplikace.

Pebble mají před sebou obrovský potenciál, ale i dlouhou cestu k dokonalosti. A já jsem rád, že jsem u toho díky Kickstarteru mohl být.

Vaše „žába“ je ten nejdůležitější a možná i nejkomplikovanější úkol, který musíte vyřešit. Jakmile se zbavíte tohoto úkolu, ty ostatní úkoly bude snadné dokončit. Stejně tak to můžete brát tak, že vaše dnešní práce už je hotová.Brian to celé staví do kontextu boje s prokrastinací. Já osobně jsem si tenhle přístup velmi oblíbil a úspěšně si navykl tuhle metodu využívat. Totiž začít úkolem, který bych s největší pravděpodobnosti odkládal, způsobí, že ty ostatní úkoly, bude jednoduché dokončit, protože v porovnání s tím prvním jsou snadné a jsou tak vlastně za odměnu.

A tuhle metodu můžeme posunout ještě na vyšší úroveň tím, že první věc, kterou bychom měli dělat je ta, která přiblíží k dokončení našeho velkého úkolu nebo dosažení cíle. Brian tento, řekněme rozšířený přístup, stručně ve své knize zmiňuje, ale ze zkušenosti vím, že tenhle přístup je mnohem více zaměřen na plnění úkolů než je jen boj s prokrastinací.

Návyk plnění nejdůležitějšího úkolu jako prvního

Jedná se o velmi jednoduchý návyk, který je však extrémně účinný, pokud jej aplikujete každý den. Pracováním na vašem největším úkolu každý den, nevyhnutelně vede k tomu, že  se dostaví úspěch. Obzvláště, pokud se zaměříte na ty nejdůležitější úkoly a dáte do nich veškerou energii. Ke splnění vašich cílů se pak dostanete mnohem rychleji než čekáte. Tenhle zvyk má totiž řada úspěšných lidí a podle mého názoru tohle je právě ta vlastnost, která je činí úspěšnými. A pracovat dopoledne je pro většinu lidí snadnější zejména z těchto úkolů:

• V této části dne máte nejvíc energie (zejména pokud jste se dobře vyspali)
• Jste mnohem méně vyrušováni
• Jste mnohem více koncentrován

Další výhodou „jezení žáby“ každý den je to, že se prakticky okamžitě zbavíte stresu z nesplněných úkolů a váš mozek se nebude muset zabývat tím, co je nutno ještě během dne zvládnout. Jen si to představte, jak je stresující vědomí, že na konci dne nemáte hotové X, Y a Z, oproti tomu, když jste tyto úkoly splnili už ráno, kdy jste měli ještě spoustu energie a nikdo vás u toho nevyrušoval.

Největším problémem „jezení žády“ má většina lidí v tom, že neumí určit úkol, na který se zaměřit. Abyste to zvládli musíte se naučit definovat vaše cíle. Pár pěkných knížek k tomuto tématu je na amazonu (Goals! a The Power of Story). Já se tomuto tématu budu věnovat v některém z dalších článků. Pro začátek, pokud pracujete v běžné firmě, zkuste se zeptat svého nadřízeného na jaký úkol byste se měli zaměřit. Je důležité uvědomit si, co je vlastně produktivita a jak ji docílit. Produktivním se stanete ve chvíli, kdy svůj čas trávíte na úkolech, které vás posunují směrem ke splnění vámi stanovených cílů.Takže abyste byli produktivní, musíte pracovat na tom, co vede k jakémukoliv cíli v budoucnosti, ideálně v tak, abyste ke splnění cílů spotřebovali co možná nejméně času. Toho docílíte tím, že strávíte váš nejproduktivnější čas plněním právě nejdůležitějších úkolů.

Ráno nemám čas!

Chápu ten problém. Ráno se probudíte v sedm hodin a v devět dorazíte do práce. Kde najít čas na pracování na osobních projektech, které máte naplánovány, když je mám dělat ráno? Řešení je jednoduché, prostě vstávejte dříve. Hromada lidí díky tomu slaví úspěch, a to včetně mě. V jednom z mých připravovaných článků se zabývám ranním vstáváním detailněji. Teď jen v kostce. Ranní vstávání je zvyk stejně jako cokoliv jiného. Začátky bolí, ale když si na to zvyknete, bude to snadné. Uvědomte si, že pokud vstanete jen o hodinu dříve, váš den se okamžitě prodlouží o jednu hodinu, za kterou se dá zvládnout hromada věcí!

Uvědomte si, že vaše investice se ve výsledku násobí. Už Albert Einstein napsal, že „úrok z úroku je tu největší silou ve vesmíru.“ Začněte dne, vstávejte dříve a pracujte hned z rána na nejdůježitějších úkolech a zvládnete i ty největší cíle.

Jak už jsem uvedl, klíčem k tomu, abyste byli schopni vstávat dříve, je rozklíčovat náš spánkový režim. Kolik hodin spánku ve skutečnosti potřebujete? Potřebná doba spánku u dospělého člověka se pohybuje mezo 7-9 hodinami. Naplánujte si svůj čas v posteli podle toho. Řekněme, že chodíváte spát kolem půlnoci, vstáváte v sedm a v práci jste v devět. Zkuste vstát o hodinu dříve, tedy v šest. Aniž bychom snížili dobu našeho spánku, měli bychom být v posteli už v jedenáct. Hodina v noci vám stejně chybět nebude. Sáhněme si do svědomí, jak takový čas obyčejně trávíme. Nebudu daleko od pravdy, když budu hádat televizi, počítačové hry a podobně, že?

Uvedení do praxe

Myšlenka „jezení žáby“ může být aplikována nejen na vaše osobní projekty, ale zejména i práci. Hned, jak přijdete do práce, začněte pracovat na těch nejdůležitějších úkolech. Prostě, jakmile „sníte žáby svých osobních projektů“, je čas udělat to samé i v práci.

Osobně jsem zvyklý pracovat od v režimu 9:00-17:00 a vstávám ráno kolem šesté. V půl sedmé je čas pracovat na svých osobních projektech, večer jsem totiž moc unavený na nich pracovat, a kromě toho mi v tom brání i rodinné důvody, takže ráno, zatímco ostatní spí, já se věnuji svým soukromým projektům. Je to jedno z nejlepších rozhodnutí, které jsem kdy v životě udělal.

Ráno si můžu jít zaběhat, protože se chystám na maraton. To mi zabere tak 50 minut včetně sprchy. Pak se vrhnu na své další osobní aktivity. Může to být cokoliv. Zaplatit účty, zkontrolovat probíhající rekonstrukci domu a zahrady, uklidit garáž. A než dorazím do práce, mám skvělý pocit z toho, že jsem už zvládl udělat hromadu skvělé práce. A protože tento trend nechci pokazit rovnou se vrhám na své žáby v práci a během následujících dvou hodit se soustředím na své největší pracovní úkoly.

Mezitím se přiblíží poledne a s ním čas na oběd s kolegy. A teprve potom si pustím emailový klient a vyřeším kupu e-mailů, které se mi za dopoledne nahromadily. Určitě jste to už slyšeli, ale hlavně nekontrolujte svou e-mailovou schránku hned poté, co dorazíte do práce. Neexistuje lepší zabíječ produktivity než právě toto.

Jak začít

V následující části se podíváme na to, jak začít používat tuto techniku.

1. Sepište seznam úkolů, na které se chystáte během zítřka, a které vedou ke splnění vašich cílů (nejprve se pusťte do soukromých projektů a pak to samé udělejte i pro pracovní část svého života). Zkuste si položit následující otázky:

• Jaké aktivity mi přinášejí největší užitek?
• Co mohu udělat pouze já, a pokud to udělám správně, budu cítit velký rozdíl?
• S činnosti považujete za nejefektivněji strávený čas aby vás posunul nejruchleji k vašim aktuálním cílům?

2. Odpověď na poslední otázku je vaše největší žába. S tímhle úkolem začnete hned zítra ráno.

3. Připravte sami sebe na zítřejší plnění úkolu. Naplánujte si, jakým způsobem splníte tento úkol zítra ráno. Připravte si všechny potřebné nástroje a pomůcky.

Což pro některé úkoly to může znamenat, vstát dříve nebo dorazit do kanceláře o něco dříve. Uděljte to, pokud si myslíte, že se tím zvýší pravděpodobnost, že nebudete ničím a nikým rozptylováni a vy se budete moci plně soustředit na splnění úkolu.

4. Na konci pracovního dne, pokračujte opět od bodu 1. Každý (pracovní) den.

Celé tohle vám zabere maximálně pět minut, ale změní to dramaticky váš život. Zkuste to a dejte vědět, jak vám tahle jednoduchá technika pomohla zvýšit vaši produktivitu.

Ale i přesto bylo potřeba do této implementace doimplementovat několik požadavků. Rozhodl jsem se nejprve stávající implementaci pokrýt testy tak, abych tím, co tam doplním nerozbil to, co již funguje. A zde jsem trochu narazil. Implementace tohoto modulu je velice těsně spjata s JMS implementací Weblogicu a navíc tak, že se jedná o několik front, které jsou vzájemně propojeny a zpráva zkrze ně postupně „propadává“ podle definovaných pravidel.

Abych to celé byl tedy schopen spustit jako unit test, musel jsem vyřešit pár „drobností“, a to poskytovatele JNDI kontextu, transaction manager a vlastní implementaci JMS. Pro JNDI kontextu jsem jednoduše využil prostředků Springu. Pro transakční manager jsem využil Bitronix Transaction Manager a pro messagingové služby padlo rozhodnutí na Apache ActiveMQ.

JNDI kontext

Vytvoření vlastního JNDI kontextu je ve Springu triviální úloha. Já jsem si pro to napsal jednoduchou utilitku, která mi ji ještě více zjednodušuje:

package eu.kratochvil.utils.spring;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.mock.jndi.SimpleNamingContextBuilder;

import java.util.HashMap;
import java.util.Map;

/**
 * Simple implementation of JNDI context that should be used in unit-tests
 * within Spring context.
 * 

 * Basic usage is simple:
 * 
 * <bean id="jndiContext" class="cz.isvs.reg.ros.ws.repository.util.MockSpringJndiContext">
 *   <property name="jndiContext">
 *      <map>
 *          <entry key="ros.VstupniFronta" value-ref="destinationVstupniFronta"/>
 *          <entry key="ros.VystupniFronta" value-ref="destinationVystupniFronta"/>
 *          <entry key="weblogic.jms.XAConnectionFactory" value-ref="activeMQConnectionFactory"/>
 *      </map>
 *   </property>
 * </bean>
 *
 * There isn't needet to use something like jndi.properties because jndi context is define
 * directly inside spring context. 
 *
 * @author Jiri Kratochvil (jiri.kratochvil@jetminds.com)
 */
public class MockSpringJndiContext implements InitializingBean {

    public static final Logger logger = LoggerFactory.getLogger(MockSpringJndiContext.class);

    Map jndiContext = new HashMap();

    public void setJndiContext(Map jndiContext) {
        this.jndiContext = jndiContext;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        logger.info("Initializing JNDI context");
        SimpleNamingContextBuilder builder = SimpleNamingContextBuilder.emptyActivatedContextBuilder();
        for (Map.Entry entry : jndiContext.entrySet()) {
            logger.debug("Binding {} in JNDI context", entry.getKey().toString());
            builder.bind(entry.getKey().toString(), entry.getValue());
        }
    }
}

Použití je pak naprosto triviální:

Inicializací tohoto springového beanu se vytvoří JNDI kontext, který obsahuje dvě JMS fronty a ještě connection factory, o které budu mluvit dále. Pokud použijete Spring není potřeba dále definovat jak se k JNDI kontextu připojit, což se běžně dělá pomocí property souboru jndi.properties umístěném na classpath.

JMS server

Dále tedy potřebujeme vytvořit instanci embedovaného JMS serveru. Pro mé účely jsem zvolil Apache ActiveMQ, který jde snadno inicializovat pomocí Springu, kde to vypadá následovně:

Popis co a proč je použito v předchozím listingu jsou přímo v něm, tedy ve stručnosti. Vytvořili jsme si instanci message brokeru, který nám nahrazuje vlastní JMS server v aplikačním serveru, následně jsme zadefinovali jednotlivé fronty, které jsou použity ve vlastní implementaci business logiky a konečně connection factory, která nám umožní napojení vlastních listenerů JMS front a zároveň přes ni budeme posílat testovací zprávy z našit unit testů.

Nyní bych se ještě vrátil k tomu, proč jsem do JNDI kontextu umístil weblogic.jms.XAConnectionFactory. Důvod je takový, že aplikace, které využívají JMS ve Weblogiku by měli referenci na connection factory získávat právě z JNDI.

Transaction Manager

Poslední věc, kterou musíme vyřešit bez aplikačního serveru je transaction manager – tedy „něco“, co nám bude řídit vlastní transakce. Na to jsem použil Bitronix Transaction Manager což je celkem mocná implementace transakčního manažeru. Pro naše účely bude použití triviální:

Závěrem

Kouzlo tohoto použití je v tom, že nyní stačí spustit unit test, který inicializuje springový kontext a zároveň načte definici kontextu vlastní aplikace, která právě využívá JNDI pro získání referencí na fronty a vše by mělo fungovat stejně, jako kdybychom tuto implementaci měli deployovanou přímo na aplikačním serveru. Pro úplnost dodávám ukázku definice kontextu přímo v aplikaci:

Na celém tomto cvičení je pěkné to, že jednoduchou springovou konfigurací jsme schopni rozchodit určitou část aplikace, která za normálních okolností nelze bez aplikačního serveru spustit, a my si tak můžeme napsat testy, které lze snadno spouštět bez neustálého a otravného redeploymentu na aplikační server.

   ...
    
   ...
        
            javax.xml
            jaxws-api
            2.0EA3
            provided
        
        
            com.sun.xml
            jaxws-rt
            2.0EA3
            provided
        
   ...
    
 

Jako scope těchto knihoven uvedeme, že jsou provided, což v praxi znamená, že knihovny budou použity pro kompilaci, ale nezaintegrují se do výsledného balíku. To proto, že Weblogic má tyto knihovny vlastní a naším cílem je použít právě implementaci aplikačního serveru.

Implementace webových služeb

Nyní si vytvořime a vystavíme vlastní webové služby. Služby budou definovány svým rozhraním a implementací. Rozhraní webové služby pak může vypadat třeba takto:

package eu.kratochvil.clanky.ws;

import javax.jws.*;

@WebService(targetNamespace = "http://schema.kratochvil.eu", name = "TestService")
public interface TestService {

    @WebMethod
    String sayHello(@WebParam(name = "name") String name);

}

A ještě implementace vlastní „business logiky“:

package eu.kratochvil.clanky.ws;

import javax.jws.WebService;

@WebService(endpointInterface = "eu.kratochvil.clanky.ws.TestService")
public class TestServiceImpl implements TestService {

    @Override
    public String sayHello(String name) {
        return "Hello " + name + "!";
    }
}

Z implementace je zřejmé, co naše služba dělá a není potřeba nějak složitě popisovat. Důležité jsou anotace WebService a WebMethod, které nám popisují vlastní rozhraní webové služby. Další anotace, jako je například WebParam a podobně složí k přesnému popsání a definici kontraktu webové služby a v budoucnu o tom napíšu nějaký článek. Do té doby doporučuji použít dokumentaci.

Posledním krokem je konfigurace našeho webového archívu. K tomu slouží znamý web.xml, který je klasicky umístěn v adresáři WEB-INF naší aplikace a ještě sun-jaxws.xml.

Soubor _web.xml_ bude obsahovat následující:

    
        
            com.sun.xml.ws.transport.http.servlet.WSServletContextListener
        
    
    
        jaxws
        com.sun.xml.ws.transport.http.servlet.WSServlet
    
    
        jaxws
        /testService
    

Tímto donutíme weblogic, aby vystavil servlet, který bude handlovat naše webové služby. Samozřejmě je možné použít v definici patternu znaky wildcard například takto:

    
        jaxws
        /ws/*
    

Pak budou servletem pro webové služby zpracován jakýkoliv požadavek, podle zadané masky (například /ws/users nebo /ws/loans).

Poslední konfigurační soubor, který musíme vytvořit, aby nám začaly korektně fungovat webové služby je sun-jaxws.xml, který je také umístěn v adresáři WEB-INF naší aplikace. Jeho podoba je následující:

Zabezpečení webové služby

Nyní se konečně dostáváme k tomu, jak zabezpečit webové služby pomocí standardních prostředků aplikačního serveru Weblogic. Nejprve se přihlásíme do konzole aplikačního serveru, kde se proklikáme na správu uživatelů přes menu pomocí položky Security Realms. Následně vybereme konkrétní realm (defaultně myrealm). Na záložce Users and Groups si založíme uživatele, kterým se chceme autentizovat pro využívání našich webových služeb.

V našem případě jsme si vytvořili uživatele test, kterého zařadíme do nějaké, námi vytvořené skupiny (například TestGroup).

Tímto máme základní konfiguraci aplikačního serveru hotovou a dalším krokem bude nastavení naší aplikace. Úplně nejjednodušší cestou je přidání následujících několika řádků do souboru web.xml:

    
        Security for WS
        
            WSPOST
            
            
            /testService
            POST
        
        
            TestGroup
        
    
    
        BASIC
        myrealm
    
    
        TestGroup
    

Zde definujeme, co chceme zabezpečit, jaká skupina uživatelů je oprávněna používat naše služby apod. Pokud náš projekt nyní zkompilujeme a nasadíme na aplikační server, měli bychom být dotázání na heslo ve chvíli, kdy se pokusíme zavolat naši webovou službu, což si můžete vyzkoušet například pomocí skvělého nástroje SoapUI.

V článku jsem záměrně nepoužíval nic jiného než jen JAX-WS, tedy žádný Spring Security ani nic podobného. Výhodou je, že se vám tímto přístupem zjednoduší deployment a hlavně získáte skvělé možnosti, jak vaší aplikaci zaintegrovat do firemní infrastruktury, bez složitého nastavování. Weblogic vám totiž nastaví admin serveru, který Vám zároveň vytvoří i nějakou roli, kterou pak následně budete ve své aplikaci využívat. No a správa uživatelů a hesel pro aplikace, které vaše služby budou využívat je také věc administrátora. Navíc lze samozřejmě aplikační server klientské aplikace nastavit tak, aby autentizaci prováděl pro aplikaci transparentně, takže odpadá složitá správa hesel na obou stranách, ale o tom zase někdy příště.

At first we have to create a keystore with a server certificate:

keytool-genkey-alias-jetty6 keyalg RSA-keystore target / jetty-ssl.keystore-storepass changeit-keypass changeit-DNAME "CN = Your Domain Name"

Then modify the configuration of the Maven pom.xml:

    org.mortbay.jetty
    maven-jetty-plugin
    
        /context
        5
        
            
                8080
                60000
            
            
                8443
                60000
                ${project.build.directory}/jetty-ssl.keystore
                changeit
                changeit
            
        
    

In the previous configuration, we defined the connection on port 8080 and port 8443 for SSL connections.

If we did not want to manually generate a server certificate, you can use other Maven plugin as shown below.

    org.codehaus.mojo
    keytool-maven-plugin
    
        
            generate-resources
            clean
            
                clean
            
        
        
            generate-resources
            genkey
            
                genkey
            
        
    
    
        ${project.build.directory}/jetty-ssl.keystore
        cn=localhost
        changeit
        changeit
        jetty6
        RSA
    

Now, when we invoke mvn jetty: run command, plug-in automatically creates a certificate that is then used in Jetty.

In this article we will create a self-signed certificate and then configure Tomcat to use the certificate. This configuration is enough for development.

For creating a server certificate, we will use keytool utility of the JDK.

On Windows

%JAVA_HOME%binkeytool-genkey-alias tomcat-keyalg RSA

On Linux

$JAVA_HOME/bin/keytool-genkey-alias tomcat-keyalg RSA

Then uncomment the file server. (XML configuration file of Tomcat) this section:

And thats all. Your server supports both in SLL and non-SSL connections.

Forcing SSL

In case you need to make all connections to your application has been secured with SSL, and even when a user enters the address only as http you can use the following.

Edit the web.xml file of your application by adding the following element:

        AppOverSSL
        
            
                ResourceName
            
            /
            POST
            GET
        
        
            CONFIDENTIAL
        
    

Don’t forget to define right port number for SSL in your server.xml file in attribute redirectPort of element that is defined your unsecured connection:

Now when users use non-secured connection is redirected on HTTPS connection.

So what was the problem? Once I tried to deploy to Tomcat, I got this error message:

java.lang.ClassNotFoundException: [Ljava.lang.String;
at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java: 1645)
at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java: 1491)
at com.sun.faces.config.ConfigureListener.configure (ConfigureListener.java: 635)
at com.sun.faces.config.ConfigureListener.configure (ConfigureListener.java: 422)
        ...

I tried various queries, but I was not successful. When I lost hope, I found the following link, which is described bug in JDK .

Before I come across this error, because the last one was a web application to JDK 1.5, where everything works fine. So if anybody knows this bug, I offer the „official workaround.

Just pass the JVM startup parameter:

-Dsun.lang.ClassLoader.allowArraySyntax = true

import ...

@WebService(targetNamespace = "http://schemas/wsdl")
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
public interface Documentation {

    @WebMethod
    @WebResult(name = "receiveDocument")
    @XmlMimeType("application/octet-stream")
    DataHandler getDocument(
            @WebParam(name = "documentId",
                    targetNamespace = "http://schemas/wsdl",
                    mode = WebParam.Mode.IN) Integer documentId);
}

a následná implementace:

import ...

@WebService(serviceName = "Documentation", endpointInterface = "Documentation")
@SchemaValidation
public class DocumentationImpl  implements Documentation {

    @Override
    public DataHandler getDocument(Integer documentId) {
        return getService().getDocument(documentId);
    }
}

Pokud chceme používat SOAP attachmentů, můžeme využít implementace od SUNu (vlastně teď Oraclu). Souhrnně se této technice říká Message Transmission Optimization Mechanism (zkráceně MTOM) a právě SUN nabízí pro tyto účely implementaci pro JAX-WS (upozorňuji, že třeba v AXISu to funguje úplně jinak).

Vše se tváří naprosto triviálně – stačí jako jeden výstupní parametr použít s typem javax.activation.DataHandler, nastavit u tohoto parametru pomocí javax.xml.bind.annotation.XmlMimeType správný content type a celou třídu oanotovat pomocí @MTOM. Vše by mělo zázračně začít fungovat. Jenže ono to nefunguje.

Ač o tom není v dokumentaci ani zmínka záleží na tom, kde se anotace umístí. Tato anotace se totiž neumisťuje do interface, kde bych to očekával, ale přímo do třídy, která implementuje naše rozhraní této webové služby. Abychom nám začali fungovat attachmenty, upravíme příklad, který jsem uvedl na začátku tohoto článku:

import ...

@MTOM
@StreamingAttachment(parseEagerly = true, memoryThreshold = 40000L)
@WebService(serviceName = "Documentation", endpointInterface = "Documentation")
@SchemaValidation
public class DocumentationImpl  implements Documentation {

    @Override
    public DataHandler getDocument(Integer documentId) {
        return getService().getDocument(documentId);
    }
}

Přidal jsem dvě anotace: @MTOM a @StreamingAttachment(...). Ta první aktivuje tuto funkčnost a od nyní se všechny atributy typu DataHandler budou přenášet jako SOAP attachment. Anotaci @StreamingAttachment(...) využijeme v případě, že budeme přenášet skutečně velké soubory a posílání souboru nám bere moc paměti. A ještě jedna chytrá věc-v anotaci @MTOM je parametr threshold, který říká, od jaké velikosti se daný element pošle jako SOAP attachment a kdy se pošle přímo v elementu samotné zprávy.

Na závěr ještě ukázku, jak pak vypadají data ze služby:

HTTP/1.1 200 OK
Date: Sat, 06 Feb 2010 07:46:28 GMT
Transfer-Encoding: chunked
Content-Type: multipart/related;start="";type="application/xop+xml";boundary="uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e";start-info="text/xml"
X-Powered-By: Servlet/2.5 JSP/2.1

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e
Content-Id: 
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Content-Transfer-Encoding: binary



  
    
      
        
      
    
  

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e
Content-Id: <383e4726-8e85-4a46-a917-23811ec4ef3e@example.jaxws.sun.com>
Content-Type: application/pdf
Content-Transfer-Encoding: binary

%PDF-1.4
.
.
.
%%EOF

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e-

Nejprve trochu terminologie. Samotný termín Scrum je odvozen od názvu tzv. mlýnu, který sportovní fanoušci mohou znát z rugby. Pro nesportovce (jako jsem třeba já)- jedná se o takový útvar, kdy se hráči postaví do zástupu a rozehrávají hru tím, že se mezi ně hodí míč a oni se o něj poperou. Dalšími termíny jsou pigs (prasata) a chickens (kuřata). Pigs jsou programátoři a chicken ti nad nimi (projekťáci, architekti, sponzoři projektu…).

Celý proces vývoje se dělí na tzv. sprinty, což jsou období dlouhá několik týdnů (obyčejně tři až čtyři, ale může to být i delší). Pro tento sprint existuje plán úkolů, který se připraví do tzv. backlogu. V rámci sprintu si programátoři berou jeden úkol za druhým a postupně je realizují. Důležité je, aby doba realizace jednotlivých úkolů trvala ideálně jeden den. Navíc programátoři mohou do backlogu přidávat další úkoly, které je nutné realizovat během vývoje.

Jak to celé funguje?

Na počátku každého sprintu/etapy se svolá plánovací schůzka. Výsledkem této schůzky je plán pro příští sprint v takové formě, že s ním souhlasí každý člen týmu. Tento plánovací meeting je naplánován na celý den a povinně se účastní všichni „pigs“. Mohou být pozváni i zástupci z řad „chicken“, ti však nejsou oprávněni diskutovat. Je také vhodné pozvat zástupce z řad „business vlastníka“ (zadavatel nebo analytik)

Tento meeting může být rozdělen do dvou částí. V první části se prochází jeden úkol backlogu za druhým a diskutuje se o tom, jak jej implementovat, co to má vlastně dělat apod. Jak bylo již uvedeno, právě pro tuto fázi je ideální, aby se této části meetingu zúčastnili i zástupci z business analytiků. Ti jsou tak však pouze od toho, aby zodpovídali dotazy.

V druhé části se jednotlivé úkoly ohodnocují body podle náročnosti. K tomuto účelu jsme s výhodou využili klasických hracích karet, kdy každý z členů měl k dispozici karty v hodnotě A, 2, 3, 5, 8 a K. Karty (kromě K) značí bodovou hodnotu, Král znamená „nelze realizovat“. Členové týmu u každého požadavku naráz ukáží kartu s jejich předpokladem (naráz proto, aby se nemohli ovlivňovat). Tuto „hru“ můžeme nazvat třeba „hodnotící poker“. Důležité je, aby ve výsledku všichni členové týmu souhlasili s výslednou bodovou hodnotou. Tyto hodnoty se zapisují ke každému požadavku a stávají se závaznými. V našem týmu jsme tyto dvě etapy sloučili do jedné a přišlo mi to efektivnější.

Při hodnocení je důležité určit si převodní jednotku – tedy to, co vlastně znamená právě jeden bod. U nás je problém, že se nám nepodařilo úkoly rozdělit na tak atomické úkoly, že by měl jeden zabrat maximálně jeden den. Stanovili jsme tedy, že jeden bod znamená 0,5MD.

Dalším důležitým krokem určení tzv. velocity, což je zjednodušeně řečeno výkonnost týmu. Ta se počítá v různých jednotkách. V našem případě ji přepočítáváme na body, které reflektují pracnost úkolu, kterou jsme si určili na plánovacím meetingu pomocí hodnotícího pokeru. Vlastní velocita pak říká, kolik těchto bodů jsme schopni zrealizovat během jedné iterace (sprintu).

Během vlastní iterace(sprintu) se každý den uspořádá schůzka, které se říká scrum a vede ji Scrummaster. Délka této schůzky je striktně omezena na 15 minut. Během této schůzky každý vývojář odpoví na tři otázky:

• Co jsi udělal od poslední schůzky?
• Co plánuješ udělat dnes?
• Vyskytly se nějaké překážky, které bránily dokončení Tvého předhozího úkolu?

Důležité je, že na této schůzce se případné problémy pouze identifikují, jejich řešení probíhá mimo scrum. Důvod je logický – nebudeme zdržovat ostatní členy týmu záležitostmi, které se jich přímo nedotýkají. A poslední věc: Scrumy je potřeba provádět ve stoje. Důvod je jednoduchý, relativně snadno se tím zabrání tomu, aby se účastníci scrumu rozpovídali (pokud nezabírá pořádat scrum ve stoje, pořádejte ho třeba v ruštině-uvidíte, že všichni budou rázem stručnější). Pokud je více týmů/scrumů, pořádá se ještě tzv. Scrum of Scrum. Na této schůzce Scrummasteři reportují problémy a status ze „svých“ scrumů. A ještě jedna důležitá věc ke scrumům. Scrumy jsou určeny pouze pro členy týmů-projekťáci, sponzoři apod. se zúčastnít mohou, ale nesmí do schůzky nikterak zasahovat.

Na konci sprintu se pak uspořádá schůzka, kde se zhodnotí uplynulá iterace a diskutují se problémy, které se vyskytly během právě uplynulé iterace a hledá se jejich řešení.

Výhodou této metodiky je to, že zapojíme programátory přímo do procesu vývoje, navíc programátoři získají část zodpovědnosti za realizaci díla, termíny a kvalitu. Díky tomu nemají pocit, že by byli jen cvičenými opicemi. Další celkem důležitou záležitostí je fakt, že manažeři projektu ztratí část pravomocí, které se deleguje přímo na projektový tým. Manager pak má pouze funkci kontrolní, což ne vždy může být pro projektového manažera akceptovatelné. S tím se pojí nejdůležitější věc na celém procesu zavedení této metodiky. Vedení projektu musí plně důvěřovat vývojovému týmu, tomuto procesu vývoje a nesnažit se zavádět do této metodiky postupy, které znají ze své běžné praxe.

Uvidíme na konci projektu, jestli nám tato metodika pomohla lépe a s větší efektivitou zvládnout tu obrovskou horu práce, kterou realizujeme-určitě pak podám report. A co Vy? Používáte nějaké agilní metodiky vývoje (nebo i konzervativní)? Pokud ano, jaké s nimi máte zkušenosti?