Sam Schillace: Budoucnost přeje online aplikacím

Dnes vyšel na Lupě rozhovor se Samem Schillacem. Zaujala mne zde jedna pasáž, která odpovídá i tomu co si myslím já. JavaScript je otevřená platforma a dnes, kdy se začínají pro JavaScript používat JIT stroje, začíná být i velmi výkonný.

Mohl byste srovnat výhody AJAXu, Flashe a Silverlightu?

Mám javascript v prohlížeči velmi rád, protože je to přístupná a otevřená platforma. Existuje zajímavý text z MIT Press o důvodech, proč některé technologie uspějí a některé ne. A jakýmsi pravidlem je, že „horší je lepší“. A já bych řekl, že AJAX je přesně v té míře špatný, aby uspěl. Myslím, že jednoduchost a přístupnost jsou opravdu důležité věci, nemusíte nic instalovat atd. Google podporuje zlepšování možností prohlížeče, proto jsme vytvořili Google Gears, OpenSocial apod. Naší reakcí je podpora otevřených platforem. Flash je z mého pohledu v zásadě javascript doplněný o jisté grafické nástroje. A proprietární, a tedy z mého pohledu méně atraktivní. Silverlight umožňuje trochu bohatší věci, ale je také dosti uzavřeným systémem. O otázce, jestli bychom neměli používat jiné technologie, často přemýšlím, ale nyní pro to nevidím důvod. Například na iPhonu není vůbec žádný flash. A my jsme hned od začátku jeho prodeje mohli na Spreadsheets demonstrovat, co mobilní prohlížeč dokáže.

Co si myslíte o Adobe AIR či Mozilla Prism? Když člověk odstraní všechny ty lišty prohlížeče, působí webové aplikace jako Spreadsheets až překvapivě podobně těm desktopovým.

To, co dělá Adobe, je určitě zajímavé a vypadá smysluplně. Ale opět – otevřená platforma je v této oblasti lepší přístup, proto máme o něco takto proprietárního menší zájem.

Pozvánka: Přednáška o Grails

Chtěl bych vás všechny pozvat na zítřejší přednášku o Grails. Přednáška se koná 4. září od 16:00 u nás ve firmě na adrese Lochotínská 18, Plzeň (nad Kauflandem). Pozvání přijal Pavel Petřek a jeho přednáška bude jistě zajímavá.

Následně bude i návštěva místní hospůdky, kde se můžete zeptat na další Pavlovo specialitu Google Android. Dorazit by měl i Michal Šrajer a tak následná diskuse bude jistě zajímavá.

Přednáška je otevřená pro veřejnost. Nicméně nás o své případné návštěvě, prosím, informujte na e-mailu pferschmann (zavináč) softeu.com. Umožníte nám tak správně upravit kapacitu přednáškové místnosti.

Již je k dispozici i záznam.

Jak na tichou instalaci Javy (JRE)

Představte si situaci, kdy máte desktopovou aplikaci napsanou v Javě a rádi byste ji formou instalačního balíčku pro Windows distribuovali. V takovém případě potřebujete mimo jiné zajistit, aby se korektně doinstalovalo JRE v případě, kdy dosud v systému není nainstalováno (či je ve špatné verzi). Uplynulý měsíc jsme řešili obdobný problém.

V našem případě se jednalo o instalační program napsaný v Nullsoft Installeru, který po detekci nainstalovaného JRE umožňoval případnou instalaci Javy. Instalační balíček JRE podporuje několik parametrů spuštění, které umožní tichou instalaci Javy, což je řešení, které se hodí v řadě případů. Problémem u tiché instalace Javy v klasickém instalátoru pro Windows je ten, že uživatel nemá viditelnou odezvu a než se Java tiše nainstaluje, může nabýt dojmu, že instalační program tzv. zamrzl. Pro tyto případy je lepší spustit instalaci s parametrem /passive, při které se zobrazí pouze okno s průběhem instalace JRE a ze strany uživatele není nutná žádná interakce.

Maven a závislost na WARu

Pokud vytváříte projekt typu WAR a chcete jej sdílet několika webovými projekty v Mavenu (tedy také projekty typu WAR) , lze udělat přímo závislost na war:

                <dependency>
                        <groupid>cz.softeu.pokus</groupid>
                        <artifactid>pokus-war</artifactid>
                        <version>1.0</version>
                        <type>war</type>
                        <scope>runtime</scope>
                </dependency>

Tento příkaz instruuje maven-war-plugin, aby vzal všechny wary na kterém tento projekt závisí a rozbalil je do výsledného waru. Přičemž platí, že se nejdříve zkopírují závislé wary a pak až náš projekt (tj. naše soubory přepisují soubory ze závislostí).

Nevýhodou tohoto řešení je, že pak nelze použít přímo mvn tomcat:run, ale je nutné použít pomalejší mvn tomcat:run-war.

Lokalizace stránky projektu v Mavenu

Před časem jsme provedli překlad stránky projektu v Mavenu do češtiny. Tento překlad je nyní již součástí vydané verze.

Jak tedy přeložit stránku do češtiny? Návod najdete v Guide Site.

Zkráceně prostě přidáte do pom.xml toto (např. ve vašem celofiremním rodičovském projektu):

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <inherited>true</inherited>
    <configuration>
        <locales>cs,en</locales>
    </configuration>
</plugin>

Poznámka: jsou zde uvedeny cs a následně en pro takové pluginy, které ještě nejsou přeloženy do češtiny.

Build time vs. render time

Chtěl bych vám doporučit hezký článek Build time vs. render time ze serveru Wokring with JSF and Facelets.

Chtěl bych vypíchnout odstaveček:

It is very important to remember that you cannot have components „re-appear“ on post back of a JSF form. This is because a JSF component tree should never be altered between having its state saved and when its state is restored. This is very important, so let me say again, a JSF component tree should never be altered between having its state saved and when its state is restored. The reason is that this would violate the JSF specification/design.

Dobré vědět dříve, než člověk začne psát JSF stránky.

Problémy s adopcí agile přístupů

Jelikož čím dál častěji narážím na spoustu dezinterpretací, chybných názorů a různých chytrostí ohledně agile přístupů, rozhodl jsem se napsat tento článek a podělit se tak o své zkušenosti nabyté několikaletou praxí, tj. používáním a zaváděním agile praktik a životního cyklu v projektech vývoje a údržby software. Zmíněné poznámky snad mohou pomoci ostatním při závádění agile praktik a vyvarovat se tak chyb, které již prožili jiní.

Stejně tak jako války a konflikty plynou často z neznalosti, strachu z nového či hájení starých postupů (např. vodopádu) a pravd (ano, země je opravdu kulatá :-), tak i nové přístupy k vývoji software nemají na růžích ustláno, i když jsou podpořeny fakty a argumenty ve formě úspěšných projektů.
Pokračování textu Problémy s adopcí agile přístupů