Olivier Bergeret Guest

npolive Apple is organizing a new event this jan 27. Nothing official, but for sure it may concern the already famous new tablet (internet codename iSlate). It should be expensive (1.000 $ ?) On a previous article we were asking question about ebook strategy on this device at apple ; support for ebooks, newspaper, etc ? Will it be [...]

npolive Amazon is opening today its platform to new languages. Yes, you can (or may soo) buy Books written in English, German and French (no spanish ?). The device is still american-only (english keyboard, english interface, american power plug). Buying it in Europa is subject to importation law… Being european is hard with amazon . You can have [...]

npolive DEMATERIALIZATION OF BOOKS Books were maybe one of the first plain old media object to be de dematerialized… Startingthe 20th century, new media were appearing (1st half radio, 2nd half tv), and there were the ideal way of broadcasting books… Yes audio-books were created. As mentionned, at the beginning it was as radio broadcast, then as [...]

npolive This blog will present a point of view concerning the very big process currenly occuring in the media area : the dematerialization All the media and all the (media) industries are experiencing this big change. You buy your music on iTunes, your games on Steam, book your cinema with your phone, organize a meeting with google calendar, [...]

Olivier Bergeret

Voci un petit panorama des solutions de cloud (grand public) et gratuite (ou à peu près) dédiée à JAVA et prêtes à l'emploi.

Google app engine - http://code.google.com/intl/fr/appengine/

La solution phare est sans conteste Google App Engine ; outre des capacités Python, cette solution propose une solution Java basée avec intégration de memcache, le datastore bigtable (via datanucleus, pour une utilisation via JDP ou JPA), et des services google.

C‘est bien, c‘est gratuit, mais c‘est limité : classpath limité, absence de RDBMS, contraintes fortes à de débit et de volumes sur toutes les fonctionnalités.

Mor.ph - http://panel.mor.ph/

Solution de cloud pour PHP/JAVA et ROR, basée sur un stockage S3 et proposant MYSQL ou POSTGRESQL en base de données.

Des limitations cohérentes pour la version gratuite développeur (une heap de 128 mo).

Le scaling se fait à la demande avec un système de cubes.

C‘est gratuit (pour la version de base) avec RDBMS, semble fiable, mais cela n‘est pas très connu.

STAX.net - http://www.stax.net/

Solution de cloud pour JAVA (JSP/STRUTS/WICKET/GWT).

La version beta propose une instance à 256 mo de heap.

A terme la plateforme supportera S3.

C‘est gratuit, un peu limité, mais profondément en travaux. Je ne sais pas si cela peut raisonnablement être durablement utilisé.

CLOUDFOUNDRY - http://www.cloudfoundry.com/

Tout java (apache tomcat mysql) proposé sur un support S3. Annoncé comme supportant parfaitement grails, spring and co.

Testable uniquement avec un compte S3, pas de stockage propre. Des fonctionnalités avancées d‘adaptation au traffic.

A suivre !

Olivier Bergeret

Google app engine supporte officiellement java !

On retrouve le périmètre fonctionnel précédemment déployé avec Python ; c'est à dire :
- memcache
- les librairies google de manipulation d'image, d'envoi de mail et d'accès distant http
plus (+) :
- une implémentation de JPA, JDO

Techniquement c'est du java 6, et le classpath bien que réduit (à l'aide d'une whitelist référence ic : http://code.google.com/intl/fr/appengine/docs/java/jrewhitelist.html) est plutôt complet.

De ce fait beaucoup de framework (dont Spring) et meta-langages (dont groovy) tournent dessus. (référene ici : http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine)

Cependant n'espérez pas faire tourner dessus (pour l'instant) des web-app grails.

Incidemment vous pourrez vous rendre compte que le conteneur de servlet est un jetty.

Pour l'instant on est pas encore en beta, il s'agit d'un 'early look' et cela marche sur invitation ; pour obtenir la votre ici : http://appengine.google.com/promo/java_runtime

Je teste plus avant et vous en dit rapidement d'avantage.

Cette annonce tombe par ailleurs bien, étant en train de travailler sur un mini-panorama de solutions d'hébergements java orientées cloud à venir très bientôt sur ce blog.

Olivier Bergeret

Un développement d'application multimedia se fait toujours sur des pré-supposés en terme de cible d'exécution, pour des questions de performance, de fonctionnalité et de compatibilité.

Le développement d'application pour les téléphones portables à la norme MIDP n'échappe pas à cette règle.

Pour rappel et en résumé une implémentation java mobile sur un téléphone portable se décompose en :
- un coeur CLDC (Connected Limited Device Configuration) en version 1.0 ou 1.1 apportant VM, un socle de librairie java
- un profil MIDP (Mobile Information Device Profile) en version 1.0 ou 2.0 apportant les librairies nécessaires aux fonctionnements des applications mobiles (socle de base, connectivité internet, graphisme, stockage).
- des extensions diverses variées (appelées génériquement JSR) fournies par le constructeur pour le multimedia, l'envoi de SMS/MMS, l'accès au système de fichier, au PIM etc

Différentes choses à noter :
- l'ensemble CLDC/MIDP/JSR(s) est statique et ne peut être modifié par le client final (l'utilisateur du mobile).
- chaque constructeur créé une combinaison d'un ensemble CLDS/MIDP/JSR(s) pour chaque modèle (donc segmente le marché)
- le comportement des implémentations CLDC/MIDP/des JSR peut s'avérer différent d'une marque ou d'un modèle à l'autre

Donc de facto il est important :
- de bien connaître techniquement sa cible
- d'adopter sur le développement soit une approche défensive (un code générique) ou soit une approche ciblée (un code par modèle spécifique)

L'approche défensive repose :
- sur une compétence forte en terme de développement
- un testing fort au cours du développement et avant release
- une cible un peu plus réduite et des limitations fonctionnelles induites

L'approche ciblée repose :
- sur des framework / pré-compilateur (c'est une analogie) opensource comme J2ME-POLISH (http://www.j2mepolish.org/cms/) ou payant comme MOBILE DISTILLERY (http://www.mobile-distillery.com/home.htm)
- sur l'efficacité et le consistance en nombre du code proposé par la solution

Donc, au final il faut :
- identifier la cible de votre application mobile (étudiez les parts de marché par fabricant ou device avec http://stats.getjar.com/statistics/ par exemple)
- par fonctionnalité identifier les modèles compatibles avec par exemple http://devices.j2mepolish.org/interactivedb/welcome.faces
- choisir votre approche défensive ou ciblée

Olivier Bergeret

Voici ce que je préconise aujourd'hui de raisonnable et efficace dans le domaine du testing pour le WEB JAVA.

Deux couches de tests.
- des tests unitaires
- des tests d'intégration

Pour ce qui est des tests unitaires :
- Des tests de couches java développés avec JUNIT : http://www.junit.org/
- Des tests de Web-services développés avec HTTPUNIT : http://httpunit.sourceforge.net/ (on m'a conseillé HTMLUNIT récemment mais pas encore testé : http://htmlunit.sourceforge.net/)
- Des tests d'UI web développés avec WEBDRIVER : http://code.google.com/p/webdriver/.

Evidemment les tests unitaires doivent :
- être développés durant la phase de dev
- être inclus dans le code source

Pour ce qui est des tests d'intégration :
- des tests manuels basés sur des cahiers de test ; obligatoire selon moi
- des tests d'interfaces web et de parcours basés sur Selenium : http://seleniumhq.org/
- des tests 'systèmes' (charge, concurrence etc) basés sur JMETER : http://jakarta.apache.org/jmeter/

Pour bien faire ensuite, envisagez un serveur d'intégration continue (TeamCity, Hudson, Cruise Control) pour générer vos projets à intervalles réguliers et surtout passer les tests unitaires régulièrement. Mais cela fera l'objet d'un projet article.

Mais attention votre enchainement de tests unitaires n'est qu'un outil de dev ; votre application ne sera validée qu'une fois les tests d'intégration passés.