Sur la route d'Oxiane digressions diverses

LeBlog OXiane

1 août
2011

Ma première Google App (ou la découverte de Google App Engine) !

Avant de commencer rappelons ce que sont les « Google Apps » :

On peut penser immédiatement aux applications « phares » de Google : gmail, agendas, google docs, etc.
Souvent, on confond « Google Apps » et « Google docs »
Pour plus d’infos sur les « Google Apps », voir la page d’accueil : http://www.google.com/apps.

On peut dire que Google Apps, c’est à la fois

  • - la plate-forme mutualisée « on the cloud » (dans les nuages) de Google,
  • - l’ensemble des services et applications fournis par Google fonctionnant sur cette plate-forme
  • - de nombreuses applications développées sur cette plate-forme par des éditeurs tiers (gratuit ou payant)
  • - ses propres applications développées avec ses petites mains et fonctionnant dans la Google App Engine (et c’est ce dernier cas qui va nous intéresser pour la suite de l’article)
  • Toutes ces « applications » peuvent être interconnectées, ce qui permet de construire un S.I. complet dans le « cloud » Google.

    Pour l’entreprise, comme Oxiane, c’est également la possibilité de déclarer un domaine Google Apps d’entreprise, et gérer de façon centralisée, les utilisateurs, les services et les applications installées.



    Je viens de découvrir Google Apps Engine (GAE) ou comment développer une application pour Google Apps

    .
    Il est possible de développer en Python ou en Java.

    Pour développer en Java, il vous faut :

  • - le JDK (5 ou 6)
  • - Eclipse (Helios ou Indigo, la dernière version)
  • - Le plugin GAE : (Helios Plugin 3.6, Indigo Plugin 3.7)
  • - Un compte utilisateur Google
  • Inutile d’en ajouter, le tutorial est super bien fait. Il se trouve ici :
    http://code.google.com/intl/fr/appengine/docs/whatisgoogleappengine.html.

    J’ai commencé par installer le plugin Google pour Eclipse.

    Notons que le plugin Google pour la dernière version d’Eclipse (Indigo) n’était pas mentionnée dans le tutorial mais il m’a suffit de modifier le lien vers l’update site : http://dl.google.com/eclipse/plugin/3.7 pour obtenir la dernière version !

    Après l’installation du plugin, j’ai suivi le tutorial qui montre comment en très peu de temps on développe et on déploie une application GAE.

    On crée sous Eclipse un projet (« New Web Application Project ») avec un exemple Hello world. Le plugin embarque tout ce qui est nécessaire (dont les différents SDK). On retrouve une architecture Java EE web Servlet/JSP.

     

    On peut tester son application localement (le SDK simule l’environnement google apps). Ensuite, le déploiement se fait en quelques clics une fois qu’on a obtenu de google un id unique pour son application, id à renseigner dans les paramètres de configuration du projet.

    Tout ceci est très simple : il m’a fallu environs 10 min pour développer, tester et déployer le premier exemple.

    Une phase peut mal se passer : la première fois que vous allez demander un ID pour créer votre application, Google va vérifier votre compte et la seule façon de le faire est l’envoi d’un code par SMS, sur votre portable. Il arrive que ça ne fonctionne pas, avec une erreur énigmatique : « The phone number has been sent too many messages or has already been used to confirm an account ».
    Si vous utilisez un compte utilisateur google appartenant à un domaine d’entreprise, il vaut mieux utiliser l’url d’accès http://appengine.google.com/a/yourdomain.com/ plutôt que celle par défaut : http://appengine.google.com/.
    Si ça ne change rien, le mieux est d’utiliser ce formulaire pour demander une assistance, celle-ci arrivera très vite par mail.

    OxTweets

    Cette première étape était pour se mettre en jambes puisque l’objet de mes travaux était surtout de réaliser une application que nous avons nommé OxTweets et qui correspondait à un besoin chez oxiane.

    Que fait cette application ?

    L’objectif d’OxTweets est de permettre à plusieurs utilisateurs (par exemple les employés d’une entreprise) de publier des tweets sur un compte unique (par exemple celui de l’entreprise).

    J’ai commencé par développer l’interface pour accéder à l’application. Comme je suis fan du monde Spring, j’ai utilisé Spring-MVC. J’ai fait une petite JSP avec un controller Spring.

    package com.oxiane.gae.tweets.controllers;
    
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Controller;
    import org.springframework.ui.ModelMap;
    import org.springframework.web.bind.annotation.ModelAttribute;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RequestMethod;
    import org.springframework.web.bind.annotation.SessionAttributes;
    
    import com.google.appengine.api.users.User;
    import com.google.appengine.api.users.UserService;
    import com.google.appengine.api.users.UserServiceFactory;
    import com.oxiane.gae.tweets.data.Tweet;
    import com.oxiane.gae.tweets.service.TweetService;
    
    @Controller
    @RequestMapping("/sendTweet.htm")
    @SessionAttributes("tweet")
    public class TweetController {
    
    	private TweetService tweetService;
    
    	@Autowired
    	public void setTweetService(TweetService tweetService) {
    		this.tweetService = tweetService;
    	}
    
    	@RequestMapping(method = RequestMethod.GET)
    	public String showUserForm(ModelMap model) {
    
               ........
    
             }
    
    .....
    }

    Ensuite j’ai effectué quelques recherches afin de trouver une API Java permettant d’accéder à un compte Twitter et pouvant être utilisée avec GAE. Cette dernière phrase est primordiale car on ne peut pas tout utiliser dans une application GAE notamment les Sockets.

    Après des recherches, je suis tombé sur plusieurs API :

    J’ai commencé par utiliser JTwitter. Son utilisation est assez simple mais lorsque j’ai voulu tester l’application sur ma machine, j’ai eu une erreur car GAE n’accepte pas l’utilisation des Socket :

    java.lang.NoClassDefFoundError: java.net.Socket is a restricted class. 
    Please see the Google App Engine developer's guide for more details.

    J’ai donc commencé à utiliser Twitter4J. Pour utiliser cette API, il faut tout d’abord enregistrer son application sur Twitter dev.twitter en utilisant l’identifiant du compte sur lequel on veut tweeter. Lors de l’enregistrement de l’application, il faut noter les informations suivantes :

    • - Consumer key
    • - Consumer secret
    • - Access token
    • - Access token secret

    Ces informations sont nécessaires pour la configuration de l’API Twitter4J. La configuration s’effectue soit à travers un fichier de propriété ou un programme Java. Personnellement, j’ai utilisé le bean de configuration de Spring :

    PropertyPlaceholderConfigurer
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN"
        "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
    <beans>
      		<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    			<property name="locations">
    				<list>
    					<value>/WEB-INF/oxconfig.properties</value>
    				</list>
    			</property>
     		</bean>
     		<bean id="tweetService" class="com.oxiane.gae.tweets.service.TweetServiceImpl" >
     			<property name="authAccessTokenSecret" value="${oauth.accessTokenSecret}" />
    			<property name="authConsumerKey" value="${oauth.consumerKey}" />
    			<property name="authConsumerSecret" value="${oauth.consumerSecret}" />
    			<property name="authAccessToken" value="${oauth.accessToken}" />
     		</bean>
    </beans>
    

    Pour envoyer un tweet, il suffit d’utiliser l’instance de la classe Twitter.

    		ConfigurationBuilder cb = new ConfigurationBuilder();
    		cb.setDebugEnabled(true).setOAuthConsumerKey(getAuthConsumerKey())
    				.setOAuthConsumerSecret(getAuthConsumerSecret())
    				.setOAuthAccessToken(getAuthAccessToken())
    				.setOAuthAccessTokenSecret(getAuthAccessTokenSecret());
    		TwitterFactory tf = new TwitterFactory(cb.build());
    		twitter = tf.getInstance();
    

    L’appel de la méthode updateStatus envoie automatiquement le tweet passé en paramètre.

    @RequestMapping(method = RequestMethod.POST)
    	public String onSubmit(@ModelAttribute("tweet") Tweet tweet) {
    		try {
    			tweetService.getTwitter().updateStatus(tweet.getBody());
    		} catch (Exception e) {
    			e.getStackTrace();
    			// TODO: handle exception
    		}
    		return "redirect:tweetSuccess.htm";
    	}
    

    L’objectif de départ était de limiter l’application aux utilisateurs du domaine oxiane. Il fallait donc gérer un service d’authentification. Le Kit de développement de GAE fournit de nombreux services, notamment l’accès aux utilisateurs (UserService). Ce service permet d’intégrer les comptes utilisateurs Google existants à votre application.

    On dispose donc de méthodes pour accéder aux informations de l’utilisateur connecté (son domaine, son mail, son nom, …). En utilisant ce service, j’ai eu des problèmes d’accès au domaine d’un utilisateur. En effet la méthode getDomain présente un comportement non trivial :
    Dans mon exemple mtoure@oxiane.com est un utilisateur du domaine google apps oxiane.com. On s’attendrait donc à ce que user.getDomain() retourne « oxiane.com » mais l’appel à cette méthode me retourne systématiquement « gmail.com »!.
    Pourtant, j’ai bien un user du domaine oxiane.com et j’ai créé l’application avec cet user.

    En fait, le domaine renvoyé par getDomain() semble correspondre au domaine pour lequel l’application aurait été restreinte lors de sa création (par un administrateur du domaine).

    Pour résoudre le problème de façon partielle, j’ai utilisé le mail pour accéder au domaine d’un utilisateur (xxxx@oxiane.com, le domaine de xxxx est oxiane.com.

     

    Voici l’interface principale :

    Le nom de l’utilisateur loggué est inscrit en haut à droite. Si un utilisateur n’est pas loggué ou n’appartient pas au domaine « oxiane.com », on ne lui présente pas le panneau de tweet. Sinon, un tweet apparaîtra sur le compte, directement :

    Pour conclure

    Je dirai que Google App Engine offre des services pour exécuter des applications web sur l’infrastructure Google, de façon très accessible au développeur Java. Il offre la possibilité de mettre vos applications à la disposition des internautes. L’utilisateur développe son application et la déploie en utilisant des scripts ou le plugin GAE eclipse.

    Pour aller plus loin avec notre POC (Proof Of Concept), nous allons devoir regarder la persistance sur GAE, mettre en place un petit modèle métier qui permettra à n’importe qui d’utiliser OxTweets avec un compte Twitter lui appartenant. Cet utilisateur, l’administrateur, pourra inviter d’autres personnes qui auront alors la possibilité d’émettre des tweets sur le compte Twitter ainsi partagé.
    Enfin, nous pourrons voir un autre volet de GAE : la publication de l’application sur le Google Apps Marketplace afin de la rendre utilisable par d’autres.
    La suite sans un prochain billet …

     

    mtoure

    26 juil
    2011

    Une journée de dev avec le framework PLAY!

    On entend souvent dire, de la bouche des développeurs eux-même, que Java EE c’est très puissant mais trop compliqué.

    Avec Java, « on développe bien plus lentement qu’avec PHP ou .Net » ou encore « Java, c’est bien, mais pour les très gros projets ».

    On rappellera tout de même que Java EE est une formidable plateforme d’intégration et que -contrairement à ses concurrents- elle se veut ouverte à différents acteurs logiciels (en clair, mon application Java web peut -sans avoir à en modifier le code- tourner sur un serveur Tomcat ou IBM ou JBoss, ou Oracle, … ou Oracle … ou Oracle aussi).

    Ceci étant dit, il faut bien avouer que même si les outils ont fait d’énormes progrès, le reproche sur la complexité n’est pas faux : il faut souvent plus d’une journée d’installation et de configuration à un développeur averti avant de commencer à écrire et à tester ses premières ligne de code en java !


    Lorsque nous avons entendu parler de play!, un framework java qui promet de tout simplifier et de nous laisser coder en Java, nous avons voulu voir de plus près.
    Le défi pour moi qui ne connait pas play! : installer un environnement complet de développement et de test, coder une petite application web (celle que nous dérivons généralement dans nos tp de formation) avec des écrans, de la persistance, etc … et écrire le présent article. Temps imparti : une journée.

    Le site, la documentation, le tutorial sont clairs. On commence avec l’installation : une archive binaire à télécharger et à extraire sur le disque et … c’est tout ! Ça commence plutôt pas mal.
    Après cette étape, on a un eclipse ouvert, la console play! et le serveur lancés. Quelques dizaines de minutes après avoir commencé, on code effectivement du java !

    Je découvre assez vite les avantages du framework qui font sa productivité :

    1. Corriger le bug et recharger dans la page :
      Tout comme avec les langages de script, play! permet de « sauter » les étapes de compilation du projet. Il suffit de modifier le code, puis de recharger le navigateur et les modifications sont prises en compte. Pour y arriver play! utilise une technique de compilation à chaud. Les erreurs de compilation sont affichées dans le navigateur web. Un rapport détaillé sur l’erreur est affiché dans la console de play!.

    2. Architecture MVC simplifiée sans état :
      Play! s’appuie sur une architecture MVC sans état. La séparation du modèle, du contrôleur et de la vue facilite grandement le développement, ça on le savait déjà. Mais ici, en plus, les variables sont passées d’un module à un autre de façon très intuitive.

    3. Moteur de template :
      Play! dispose d’un moteur de template très puissant basé sur Groovy. Avantage ou inconvénient ? : pour profiter pleinement de toute les potentialités offertes par ce moteur, la connaissance de la syntaxe Groovy est nécessaire. Ce point peut être gênant dans la prise en main du framework.

    4. Persistance :
      Play! utilise la couche de persistance JPA. Les annotations JPA sont utilisables dans les entités gérées par Play! . Le grand apport de Play! est le fait qu’il n’est pas nécessaire de configurer JPA. La seule chose à faire est d’indiquer la source de données dans le fichier de configuration de l’application, comme dans l’exemple ci-dessous :


    5. Test Driven Development (TDD) :
      Avec play!, il est possible de développer avec le concept du développement orienté tests. Avec la possibilité de tester directement dans le navigateur en utilisant la technologie Selenium.

    En première approche, play! me semble très adapté pour le développement de petits projets au même titre que des plateformes comme PHP. Je crois aussi que c’est une très bonne idée pour tout débutant Java EE de commencer avec play! : il ne sera pas rebuté par la tuyauterie habituelle et il mettra -mine de rien- le doigt dans le développement web avec java.

    Un exemple d’application : la Cave à Vin

    Dans cette partie nous allons développer une application appelée Cave à Vin qui permet la gestion des bouteilles de vin d’une cave. Les actions sur le site se limitent à lister les bouteilles de la cave, modifier ou supprimer une bouteille, en rajouter de nouvelles.

    Pour ce développement, le temps de prendre en main play! a été très rapide. En 2h j’avais tout installé, lu et fait tourner le tutorial Hello World.
    On peut ensuite s’atteler à développer sa propre application.

    On trouve dans notre application

    • un modèle :
      il contient les données c’est à dire les informations concernant les bouteilles dans notre exemple.

      Notons qu’à partir de ce modèle, la structure des tables de la base de donnée sont automatiquement générées par play!.

    • d’un contrôleur principal :
      sous forme d’une classe java Application qui contient les différentes fonctions de l’application :

      • - Index() pour afficher la page d’accueil ;

      • - List() pour lister les bouteilles



      • - Save() pour ajouter ou supprimer des bouteilles

      • - Form() pour la création ou modification des informations concernant une bouteilles.

    • de vues :
      les vues sont les rendus HTML de l’application. Un fichier par vue. Dans notre cas, trois fichiers :

      • - Index.html pour la page d’accueil ;

      • - List.html pour l’affichage des bouteilles de la cave


      • - Form.html pour générer la vue correspondant au le formulaire d’ajout ou de modification de bouteille



    Un exemple de consistance du code : le code (ou template) de la vue commence par #{form @save()} et fini par #{/form}. Ceci permet de faire le lien avec la méthode save() du contrôleur principal, la classe Application dont on a déjà parlé.

    La page d’accueil pointe sur la page d’affichage de la liste des bouteilles :

    La page d’affichage permet d’ajouter directement une bouteille au niveau de la dernière ligne du tableau :

    Le bouton + en bas à droite de la page permet d’enregistrer l’ajout.

    La flèche à droite permet la modification ou la suppression de bouteille.

    Un clic sur le bouton + en bas à droite nous emmène sur le formulaire de création de bouteille (le même que celui utilisé pour la modification mais avec des champs de saisie initialement vides).

    Comme on peut le voir sur ces copies d’écran, il a été assez facile de modifier le code HTML afin d ‘obtenir un rendu spécifique (couleurs, images, styles).
    Enfin, cela ne se voit pas mais cette petite application dispose également de la persistance en base de données.

    En conclusion

    La prise en main de play! est agréable et très rapide. Le développement de la partie métier et de sa persistance en base est grandement facilité par le framework. Le MVC est simple à utiliser et renforce la maintenabilité du code.
    Un apport appréciable est le fait de modifier et de voir le résultat juste après un rechargement de la page web, pas besoin de compiler ni de déployer manuellement. Cette méthode est très similaire au développement web avec les langages de script comme PHP.
    Seule petite ombre au tableau, pour utiliser play! de façon optimale il faut connaître Groovy pour coder les templates.

    liens et références

    http://www.playframework.org/ Play! framework home
    http://seleniumhq.org/ Selenium HQ : Web Application Testing System

    Issiaka Koné

    Issiaka Koné

    18 juil
    2011

    Liferay Marketplace

    Le but de cet  « App store » est de proposer une plateforme permettant de publier, partager, et de monétiser des solutions construites sur la plateforme Liferay.
    Une App est une application distribuable tel qu’une portlet, un hook, un theme, …
    Ce Marketplace est prévu pour la fin 2011.

     

    Plusieurs types de participations sont prévues :

    • Basic participation : gratuit
      Un profile pour publier des applications gratuites
      Un guide développeur
    • Developer Program : $99 par an
      Un profile pour publier des applications payantes certifiés EE (commision de 20% pour Liferay)
      Une licence d’un an pour développer pour Liferay Portal EE
      Une licence pour Liferay Developper Studio
      Un guide développeur
      Les équipes de Liferay vérifie alors la compatibilité des applications avec la version EE de Liferay.

    Liferay a déjà prévu différents modes de facturation : selon le nombre d’utilisateurs, selon le nombre de sessions utilisateurs, selon le nombre de serveurs, ou encore selon le nombre de CPU.

    Quelques liens complémentaires :
    – Vidéo de présentation

    – PDF de présentation

     

    Emmanuel Pavaux

    epavaux

    8 juil
    2011

    Installation de Liferay 6 sous WebLogic 10.3

    Pour installer Liferay la solution facile est d’installer le portail avec un bundle liferay-portal-tomcat-6.0.5.zip disponible sur Sourceforge http://sourceforge.net/projects/lportal/files/Liferay%20Portal/6.0.5/.

    C’est très bien pour développer mais bon dès que l’on veut installer en production une application avec Liferay, il est quand même plus facile de partir de l’installation hors bundle sous la forme du package liferay-portal-6.0.5.war.

    Alors voilà comment réaliser une installation WebLogic 10.3 + war Liferay 6.

    Les étapes à réaliser sont donc :
    1. Télécharger depuis http://sourceforge.net/projects/lportal/files/Liferay%20Portal/6.0.5/
    - liferay-portal-6.0.5.war
    - liferay-portal-dependencies-6.0.5.zip

    2. Créer un domaine weblogic 10.3
    Par exemple dans C:\blog\1-wls-liferay\liferay-domain
    Je ne donne pas le détail de l’installation du produit weblogic 10.3 et de la création d’un domaine mais en cherchant un peu sur le web, on peut voir à quel point c’est facile d’installer et d’utiliser WebLogic …

    3. Installer les librairies nécessaires à Liferay
    Depuis liferay-portal-dependencies-6.0.5.zip, copier hsql.jar (si utilisation de HSQL), portal-service.jar et portlet.jar dans liferay_domain\lib

    4. Configurer le domaine
    Il est fortement conseillé d’augmenter la mémoire de PermGen car elle est trop faible par défaut dans WLS 10 et notamment pour un portail gérant un grand nombre de classes

    Une petite modification dans C:\blog\1-wls-liferay\liferay-domain\bin\setDomainEnv.cmd
    set MEM_ARGS=-Xms512m -Xmx1024m
    rem avant : -Xms256m -Xmx512m
    set MEM_PERM_SIZE=-XX: PermSize=128m
    rem avant : 48m
    set MEM_MAX_PERM_SIZE=-XX:MaxPermSize=256m
    rem avant : 128m

    5. Installer liferay-portal-6.0.5.war
    Démarrer WebLogic avec C:\blog\1-wls-liferay\liferay-domain\bin\startWebLogic.cmd
    puis accèder à la console : http://localhost:7001/console

    Installer l’application à partir de l’onglet Deployments dans la console avec
    C:\blog\1-wls-liferay\liferay-portal-6.0.5.war

    Les répertoires C:\blog\1-wls-liferay\data et C:\blog\1-wls-liferay\deploy ont alors été créés automatiquement.

    6. Tester l’application
    Et là on peut alors utiliser http://localhost:7001/  (et pas 8080 !!!)

    Pour changer de base de données, il faut créer une datasource vers la base dans WebLogic et référencer ce datasource dans un fichier portal-ext.properties placé dans le classpath de WebLogic avec
    jdbc.default.jndi.name=jdbc/LiferayPool

    Un petit résumé de la recette :
    – Télécharger liferay-portal-6.0.5.war et liferay-portal-dependencies-6.0.5.zip
    – Placer les jar du liferay-portal-dependencies-6.0.5.zip dans DOMAINE/lib
    – Déployer
    – Savourer

     

    Emmanuel Pavaux

    epavaux

    29 juin
    2011

    Google Swiffy sur la route d’Adobe

    Comme nous avions parlé de Adobe Wallaby il y a peu, Google sort un outil de conversion simple de Flash vers HTML5 !
    Google Swiffy est parti, si l’on en croit les auteurs du blog, de l’idée maintenant assez courante de porter les animations flash sur des plateformes qui ne supportent pas cette techno (suivez mon regard de souris).

    Exactement comme Adobe le fait, cet outil permet pour l’instant de convertir une animation Flash simple en HTML5. A l’aide de JSON et de Javascript, on peut s’attendre à des animation à peine plus lourdes que leur original en SWF. Bien sûr, cela est rendu possible grâce à l’amélioration des moteurs javascript dans les navigateurs récents, et la meilleure prise en charge de l’accélération 2D.

    La FAQ du produit précise qu’Adobe est au minimum « content » de ce projet … on peut imaginer que l’expérience de Google sur le moteur Webkit ne peut qu’enrichir les travaux d’Adobe sur des produits comme Edge si ces deux là arrivent à s’entendre !

    Aujourd’hui il existe également un ouil appelé Gordon par Tobias Schneider qui a la même vocation. Ce qui est sûr, c’est que la mésentente entre Adobe et Apple n’a pas que des mauvais côtés !

    Et tant qu’on y est, on peut citer également ce projet : Jangaroo, qui permet de coder en ActionScript3 pour générer du Javascript, les applications d’un tel outil sont multiples :)

    Alain Boudard

    aboudard