Pour cette fois, le JUG Montpellier délaisse Java et tout ce qui tourne autour (Android, Spring, Liferay, SOA ou WebLogic par exemple) pour s'ouvrir à d'autres horizons : les interfaces web en 2011.
La soirée de la semaine dernière était décomposée en 2 parties.
Une première montrait les évolutions des interfaces utilisateurs, en faisant un rappel des grands principes d'ergonomie, de graphisme, ou d'expérience utilisateur.
J'ai bien apprécié l'évolution technologique du web
- dans les années 1990, on a fait du HTML + CSS + JAVASCRIPT et l'on appelait cela du DHTML,
- dans les années 2000, on a fait du HTML + CSS + JAVASCRIPT et l'on appelait cela de l'AJAX,
- dans les années 2010, on va faire du HTML + CSS + JAVASCRIPT et l'on va appeler cela de l'HTML 5.
C'est un peu carricatural et réducteur mais comme dirait l'autre "C'est pas faux".
Une autre évolution est aussi liée à la diversité des écrans, euh des plateformes : mobile, tablette, netbooks, ...
La deuxième partie était consacrée à l'accesibilité des interfaces web
La présentation a commencé par une démonstration qui nous montre sur des sites grands publics ce que "voit" un aveugle aidé par une assistance vocale et là c'est le drame ...
Des sites constitués en grande majorité d'images sans texte ou de liens associés, et l'on se retrouve tel une personne en fauteuil roulant dans les couloirs du métro : impossible d'aller bien loin.
Ceci à permis de nous sensibiliser et de démontrer l'intérêt de l'accessibilité pour toutes les personnes en situtation d'handicap.
Les avantages de rendre son site accessible sont multiples :
- un meilleur référencement par les moteurs de recherche,
- une meilleure ergonomie,
- et une conformité avec la loi sur l'handicap de 2005 qui "obligent" tous les sites web publics à être accessibles.
Mais accessible cela veut dire quoi concrètement ?
On peut déjà parler qu'il y a différents niveaux et atteindre le niveau bronze constitue déjà une gageure, surtout lorsque l'on décide de vouloir atteindre ce niveau après la réalisation du site. Eh oui, connaitre les règles du jeu après avoir jouer rend plus difficile la gagne.
On peut décomposer les règles à respecter en 13 thématiques :
- images
- frames
- couleurs (contraste, la couleur ne doit pas être le seul moyen de porter l'information, ...)
- multimédia (pouvoir contrôler une piste audio ou vidéo : pause, stop, ...)
- tableau
- liens (pas de lien vide, ...)
- scripts
- sémantique des balises
- balises titres
- css (pied, em, % sont les seules valables)
- form (bouton "ok" c'est beau mais cela manque d'informations)
- navigation
- le reste (clignotement autorisé si l'on peut l'éteindre)
Ces règles sont nombreuses (plus de 300) et à réaliser sur chaque page du site ...
Un logiciel libre Tanaguru (.com) peut nous aider sur certaines règles automatisables mais elles ne le sont pas toutes, loin de là.
Voilà un critère de plus à prendre en compte dans nos applications si "on" veut bien y mettre un minimum de budget.
lundi 12 décembre 2011
vendredi 7 octobre 2011
JUG Montpellier : session sur Google Application Engine
Comme vous savez, Oxiane Méditerranée sponsorise le JUG Montpellier et donc il est intéressant pour moi de faire un retour sur la dernière session du JUG Montpellier sur Google Application Engine présentée la semaine dernière.
Cette session a été présentée par Martin Delemotte, co fondateur de Kazelys et créateur du site http://www.vadequa.com.
"Vadequa est un site de rencontre entre particuliers et entreprises."
C'est un site web du type Meetic Affinity entre particuliers et entreprises pour connaître le degré d’adéquation d’un candidat à une entreprise.
Le gros intérêt pour le sujet du jour est que ce site a été créé sur la plate-forme GAE avec plus d'un an de développement.
Ce que je retiens de cette soirée,
Un petit rappel sur GAE :
Google Application Engine est une PAAS (Plate-forme As A Service) visant à être scalable
ou dit autrement un service d'hébergement d'applications web dans les nuages visant avant tout à répondre à de nombreux clients simultanés sans dégradation de performance
Cette plate-forme possède un certain nombre de contraintes notamment pour assurer cette scalabilité
Pour assurer la persistance de ses données, GAE s'appuie sur un datastore qui est implémentée par une BigTable Google, du pur NOSQL.
Une BigTable peut être vue comme une hashtable géante distribuée contenant des entités java.
Elle ne comporte pas de schéma.
Les données peuvent être répliquées sur plusieurs DataCenters.
Il y a 2 grands types de réplications :
Dans ce cas, l'instance slave devient Master et une nouvelle instance slave est utilisée.
Ce mode de réplication devrait être abandonnée à terme par Google pour des problèmes sur la disponibilité et la latence des données.
Ce mode de replication permet d'avoir une haute disponibilité et fiabilité des données.
Mais il coûte plus cher que l'option maître / esclave.
Plus d'infos sur http://code.google.com/intl/fr/appengine/docs/python/datastore/hr.
En tout cas cette problématique de réplication me rappel très fortement les tests que j'ai effectué sur la haute disponibilité des données avec Oracle Database en mode Dataguard ou en mode RAC.
Pour accéder au datastore, il est possible d'utiliser JDO ou JPA possible mais avec quelques spécificités ...
et souhaitable d'utiliser par exemple Objectify, qui est un framework permettant de simplifier la persistance de données et leurs manipulations dans Google App Engine, il rajoute une couche d’abstraction facilitant énormément les différentes interactions (par rapport à l'API bas niveau Google App Engine/J).
Il est possible de faire directement des requêtes GQL mais attention pas de join, de filtre, de like, ...
Pour les transactions, il n'est pas possible de faire des transactions entre entités sauf au sein d'un Entity Group.
Un Entity Group est une entité hiérarchisée localisées sur le même noeud d'un datastore (très important dans le cas du High Replication Datastore).
Ce qui amène ici à des points essentiels dans l'utilisation de Google App Engine, c'est qu'il faut penser à son modèle pour qu'il soit scalable dès la conception et notamment à ses notions d'Entity Group.
Un petit exercice donné par Martin : soit une entité Candidature, doit-elle être dans le même Entity Group que l'entité Candidat ou que l'entité Entreprise ou que l'entité racine ?
Quelques secondes de réflexion ...
La première réponse est la bonne, en effet le nombre de candidatures va être directement lié au nombre de candidats donc pour pouvoir assurer la montée en charge, il faut les regrouper dans un même Entity Group.
La scalabilité est le but à atteindre et ceci se fait au détriment de la performance, par exemple le datastore est lent (25-100ms) pour un get, (50-160) pour un put.
Alors comment réduire le temps de réponse ?
En utilisant par exemple Memcache qui est un cache distribué (une seule instance) mais attention les données y sont volatiles et peuvent y être enlevées n'importe quand. Le rechargement de ces données doit donc être prévue.
Ce cache n'est bien sur pas transactionnel (sauf putIfUntouched de manière atomique, je vous laisse encore une fois voir pour les détails) ou d'utiliser le "cache" JVM par des données static mais attention il est très volatile car le changement d'instance est fréquente. De toute façon je déconseille toujours de mettre des données en static non maîtrisées si l'on veut éviter les fuites mémoires (dans GAE cela sera a priori peu probable).
D'autres techniques sont possibles : grouper en parallèle les requêtes au datastore, gérer par des tâches de fond en asynchrones, ou encore dé-normaliser en créant des entités intermédiaires et les re-synchroniser par des taskqueue
Exemple : candidature liés à 3 entités candidat, dossier, ... et on ne va manipuler que ses entités intermédiaires.
Pour en revenir à la vraie vie, il faut savoir que le taux d'erreur quotidien est plus élevé que sur un serveur individuel, d'où la phrase "Chaque seconde, une machine meurt dans le Cloud" et son implication : le code doit prévoir les interruptions de services (taskqueue, memcache) ... et là je vous laisse imaginer au cas pas cas les solutions ...
Quelques mots sur le support et les prix :
Le support est réalisé par les équipes SRE (Site Reliability Enginneer) mais il faut compter 500$/mois pour un compte premium.
La version gratuite qui a fait débat il y a quelque temps lié au resserrement important sur les quotas. En effet avant, une application avec un trafic de 5 millions de pages pouvait être gratuite maintenant les quotas en gratuit suffisent juste pour une application avec un faible traffic.
Et donc on arrive à la formule payant à partir de 9$/mois min et plus en fonction des quotas. Pour tout savoir : http://www.google.com/enterprise/appengine/appengine_pricing.html
La Roadmap pour ce qui est du plus important : le SSL et le Like dans les requêtes (ouf).
Pour conclure, c'est une plate-forme scalable mais dès la conception / développement il faut avoir en tête les différentes contraintes.
Et à la question, malgré les difficultés rencontrées, est-ce que ta prochaine application sera réalisée avec GAE, Martin a répondu oui, d'autant qu'il sait maintenant comment éviter les quelques pièges de la plate-forme. Comme quoi l'expertise à un coût !!!
Cette session a été présentée par Martin Delemotte, co fondateur de Kazelys et créateur du site http://www.vadequa.com.
"Vadequa est un site de rencontre entre particuliers et entreprises."
C'est un site web du type Meetic Affinity entre particuliers et entreprises pour connaître le degré d’adéquation d’un candidat à une entreprise.
Le gros intérêt pour le sujet du jour est que ce site a été créé sur la plate-forme GAE avec plus d'un an de développement.
Ce que je retiens de cette soirée,
- un certain nombre de bonnes pratiques sont à mettre en place s'il l'on ne veut pas se casser les dents,
- une explication claire mais forcément rapide des grands composants de la plate-forme,
- la phrase de Martin qui restera sûrement à la postérité "Chaque seconde, une machine meurt dans le Cloud", et nous allons voir que ce n'est pas sans incidents ...
Un petit rappel sur GAE :
Google Application Engine est une PAAS (Plate-forme As A Service) visant à être scalable
ou dit autrement un service d'hébergement d'applications web dans les nuages visant avant tout à répondre à de nombreux clients simultanés sans dégradation de performance
Cette plate-forme possède un certain nombre de contraintes notamment pour assurer cette scalabilité
- sur les threads, les API Java, les accès file systèm et les accès réseau,
- des requête de 30s maximum, avec 1 seule écriture par seconde et par entité est garantie (la réalité est plutôt de l'ordre de 10 écritures par seconde),
- les caractéristiques des instances sont inconnues, mais c'est vrai ce n'est justement pas notre problème
Pour assurer la persistance de ses données, GAE s'appuie sur un datastore qui est implémentée par une BigTable Google, du pur NOSQL.
Une BigTable peut être vue comme une hashtable géante distribuée contenant des entités java.
Elle ne comporte pas de schéma.
Les données peuvent être répliquées sur plusieurs DataCenters.
Il y a 2 grands types de réplications :
- Master slave Datastore
Dans ce cas, l'instance slave devient Master et une nouvelle instance slave est utilisée.
Ce mode de réplication devrait être abandonnée à terme par Google pour des problèmes sur la disponibilité et la latence des données.
- High Replication Datastore
Ce mode de replication permet d'avoir une haute disponibilité et fiabilité des données.
Mais il coûte plus cher que l'option maître / esclave.
Plus d'infos sur http://code.google.com/intl/fr/appengine/docs/python/datastore/hr.
En tout cas cette problématique de réplication me rappel très fortement les tests que j'ai effectué sur la haute disponibilité des données avec Oracle Database en mode Dataguard ou en mode RAC.
Pour accéder au datastore, il est possible d'utiliser JDO ou JPA possible mais avec quelques spécificités ...
et souhaitable d'utiliser par exemple Objectify, qui est un framework permettant de simplifier la persistance de données et leurs manipulations dans Google App Engine, il rajoute une couche d’abstraction facilitant énormément les différentes interactions (par rapport à l'API bas niveau Google App Engine/J).
Il est possible de faire directement des requêtes GQL mais attention pas de join, de filtre, de like, ...
Pour les transactions, il n'est pas possible de faire des transactions entre entités sauf au sein d'un Entity Group.
Un Entity Group est une entité hiérarchisée localisées sur le même noeud d'un datastore (très important dans le cas du High Replication Datastore).
Ce qui amène ici à des points essentiels dans l'utilisation de Google App Engine, c'est qu'il faut penser à son modèle pour qu'il soit scalable dès la conception et notamment à ses notions d'Entity Group.
Un petit exercice donné par Martin : soit une entité Candidature, doit-elle être dans le même Entity Group que l'entité Candidat ou que l'entité Entreprise ou que l'entité racine ?
Quelques secondes de réflexion ...
La première réponse est la bonne, en effet le nombre de candidatures va être directement lié au nombre de candidats donc pour pouvoir assurer la montée en charge, il faut les regrouper dans un même Entity Group.
La scalabilité est le but à atteindre et ceci se fait au détriment de la performance, par exemple le datastore est lent (25-100ms) pour un get, (50-160) pour un put.
Alors comment réduire le temps de réponse ?
En utilisant par exemple Memcache qui est un cache distribué (une seule instance) mais attention les données y sont volatiles et peuvent y être enlevées n'importe quand. Le rechargement de ces données doit donc être prévue.
Ce cache n'est bien sur pas transactionnel (sauf putIfUntouched de manière atomique, je vous laisse encore une fois voir pour les détails) ou d'utiliser le "cache" JVM par des données static mais attention il est très volatile car le changement d'instance est fréquente. De toute façon je déconseille toujours de mettre des données en static non maîtrisées si l'on veut éviter les fuites mémoires (dans GAE cela sera a priori peu probable).
D'autres techniques sont possibles : grouper en parallèle les requêtes au datastore, gérer par des tâches de fond en asynchrones, ou encore dé-normaliser en créant des entités intermédiaires et les re-synchroniser par des taskqueue
Exemple : candidature liés à 3 entités candidat, dossier, ... et on ne va manipuler que ses entités intermédiaires.
Pour en revenir à la vraie vie, il faut savoir que le taux d'erreur quotidien est plus élevé que sur un serveur individuel, d'où la phrase "Chaque seconde, une machine meurt dans le Cloud" et son implication : le code doit prévoir les interruptions de services (taskqueue, memcache) ... et là je vous laisse imaginer au cas pas cas les solutions ...
Quelques mots sur le support et les prix :
Le support est réalisé par les équipes SRE (Site Reliability Enginneer) mais il faut compter 500$/mois pour un compte premium.
La version gratuite qui a fait débat il y a quelque temps lié au resserrement important sur les quotas. En effet avant, une application avec un trafic de 5 millions de pages pouvait être gratuite maintenant les quotas en gratuit suffisent juste pour une application avec un faible traffic.
Et donc on arrive à la formule payant à partir de 9$/mois min et plus en fonction des quotas. Pour tout savoir : http://www.google.com/enterprise/appengine/appengine_pricing.html
La Roadmap pour ce qui est du plus important : le SSL et le Like dans les requêtes (ouf).
Pour conclure, c'est une plate-forme scalable mais dès la conception / développement il faut avoir en tête les différentes contraintes.
Et à la question, malgré les difficultés rencontrées, est-ce que ta prochaine application sera réalisée avec GAE, Martin a répondu oui, d'autant qu'il sait maintenant comment éviter les quelques pièges de la plate-forme. Comme quoi l'expertise à un coût !!!
dimanche 17 juillet 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 :
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
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
samedi 25 juin 2011
Installation de Liferay 6 sous WebLogic 10.3
Quoi de mieux pour commencer mon premier billet que de parler du déploiement de Liferay avec WebLogic.
En effet, 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
En effet, 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
Inscription à :
Articles (Atom)