Archives pour la catégorie Uncategorized

C’est les vacances!

C’est du bus pour Beauvais que je rédige ce post. Je suis parti pour 1 semaine de vacances en Pologne. Comme d’habitude, il m’a été difficile de libérer du temps pour m’entraîner malgres le fait que je fus célibataire 1 semaine, Ola étant partie la semaine dernière. J’ai toit de même pris mes affaires pour courir, on ne sait jamais… 😉

Frameworks à suivre…

Hier soir, je suis allé à la présentation de GAElyk, un toolkit Groovy pour le Google App Engine. La présentation a été effectuée par Guillaume Laforge himself dans le cadre du Paris Groovy/Grails User Group.

Ce combo (GAE+Groovy) être vraiment hyper prometteur. Je recommande pour les personnes qui sont prêt à se restreindre à la plateforme de google. J’imagine avec à disposition tous les services disponibles sur l’app engine (messagerie, memcache, etc…) mais sur d’autres plateformes (Amazon, etc…) de façon aussi transparente (sous forme de plugin ?) et intégrée à Grails.

Pour la persistance sur le data store d’App Engine, l’API Objectify semble être la plus recommandable. De mon expérience récente sur grails et le plugin app engine, je déconseille la sur-couche JPA / JDO.

Autre framework tendance du coté scala: Lift framework web qui est utilisé sur Linkedin. Scala ayant remplacé Ruby chez twitter.

Je suis parti sur Groovy/Grails pour mon projet et j’en suis très satisfait malgrès les (très) mauvaises expériences avec certains plugins (appengine/oauth).

Pour le moment, je me dirige donc vers un hébergement sur Amazon EC2 via Cloud Foundry.

Opening up to OpenID with Spring Security

Article sur Spring Security et Open Id:

http://www.packtpub.com/article/opening-up-to-openid-with-spring-security

La plupart des sites sociaux (Google, Twitter, linkedin, Yahoo, facebook) permettent d’utiliser openid (http://openid.net) pour s’authentifier et OAuth pour l’habilitation (http://oauth.net).

http://code.google.com/intl/fr/apis/gdata/articles/oauth.html

http://googlecodesamples.com/oauth_playground/

Le tutorial qui m’a le plus aidé à le mettre en oeuvre:
http://code.google.com/intl/fr/apis/gdata/docs/auth/oauth.html

C’est loin d’être trivial…

Gmail: Import emails and contact

J’imagine que c’est une réponse à Facebook Messages mais google offre « enfin » la possibilité d’intégrer un compte email externe directement dans gmail. Et là c’est bonheur! La superbe interface gmail disponible pour mes autres comptes de messagerie, avec les tags, l’antispam et tout.Trop bon!

Le top c’est que ca me permet d’utiliser l application WP7 gmail pour tous mes mails. :) :) :)

Choix du framework (part 2)

Bon hier soir (la nuit dernière) j’ai un peu dérivé de mon objectif qui était de choisir le framework de développement.

Je voulais avoir une big picture de ce qui se fait actuellement sur les sites communautaires / réseaux sociaux / smartphone en terme d’API de communication. C’est sur qu’après 4 ans dans la finance, je n’avais pas trop suivi les grosses tendances de développement distribué (ca ne se fait plus le RMI, xml schema, le SOAP ou le XML/RPC ? :) Les grosses tendances semblent être REST / JSON / Atom / HttpRequest, OAuth, etc… Bon bref c’est pas très important tout ca mais ca m’a permis de voir ce qui se passer et modeler un peu mes besoins.

Retour aux frameworks de développement ce matin donc. Pour résumer pour l’instant j’ai Java et comme hébergement Google App Engine. J’ai passé pas mal d’années sur les framework web (struts, spring mvc, JSP, taglibs, freemarker + de la veille techno:  wicket, JSF, tapestry ) et persistance (jdbc / procedure, ibatis, hibernate, jdo) avec spring pour lier tout ca. Sur le dernier projet, j’ai mis en place une configuration basé sur les annotations (hibernate/spring) et c’était assez convaincant je dois dire (partie présentation avec swing).

Bon maintenant l’objectif est de pondre un truc super rapidement (prototype/crud) mais suffisamment sérieusement pour ne pas avoir à tout refaire quand l’application marchera (si jamais elle marche).

Il y a pas mal de nouvelles technos intéressantes dans le monde java (scala, clojure, groovy) sans parler de ce qui se fait niveau web2 (jQuery, GWT), JRebel (développement à chaud) et la tendance No SQL.

Fred qui bosse dans le monde des jeux vidéos online est un big fan de scala. Par contre ca me semble être un peu un univers a part entière et j’ai un peu peur de la learning curve pour mon projet. A priori, Scala est supporté sur GAE. Bon c’est tentant mais on essaiera ca plus tard.

Pour le no sql, c’est un passage obligé puisque la persistance sur GAE se fait à travers BigTable. Le seul choix est donc JDO ou JPA coté persistance. Pour ceux qui ne savent pas, BigTable est une base de donnée hiérarchique. C’est sans trop de regret que je quitte le SQL ayant passé trop de temps dans les procédures stockées ces dernières années. Et puis j’ai un autre projet en tête que je verrais bien sur une base de données orientées colonnes.

Coté spring, j’ai vu des solutions intéressantes pour mobile (voir post précédent). Mon soucis est plutôt le cout en temps de la mise en place (note: j’aurais pu utiliser spring roo mais voir note en bas du post). Et puis c’est un framework que je connais trop bien, j’ai envie de passer à autre chose notamment tester un framework a la ruby on rails (convention plutôt que configuration)  et des langages dynamiques.

Le candidat est donc tout choisi (la recherche est terminée on pourrait dire): Grails. Réponse Java à RoR avec du Groovy inside. Ca semble pas mal. Initialement conçu pour tourner avec hibernate (qui lui ne tourne que sur des bases SQL), une couche d’abstraction a été ajoutée pour faire du JDO/JPA (GORM). J’ai fait quelques recherche, ca semble pas trop mal tourner sur Google App Engine (GAE) et même sur Amazon Web Services (AWS). Et ca s’est faire du REST et du GWT. Bonheur

Bon on va partir la dessus, on verra bien. Ci dessous quelques guides qui pourront m’être utile.

Next step installation de l’environnement de développement.

En écrivant la liste de site, je me suis dit et pourquoi pas spring roo ? Grosso modo roo est un générateur d’application spring. Il y a tout ce qui faut pour faire une application dans le cloud. Les grosses différences étant java vs groovy et configuration vs convention. Je reste donc sur grails…

Je suis tombé également sur quelques articles parlant de problème de performance avec GAE sur java. A priori, cela semble du à l’instanciation de nouvelle jvm ou le démarrage (warmup d’une application). Google vient de sortir la version 1.4 de GAE qui semble offrir des solutions à ses problèmes de performances.

Server side / Framework choice (part 1)

Comme vu dans le post précédent, le choix coté serveur s’est fait sur java avec comme contrainte un hébergement « In the Cloud ».

Je dis contrainte car pour plein de bonnes raison, Google App Engine limite ce qu’on peut faire dans l’application. Amazon Web Services semble plus ouvert puisqu’il nous donne accès à une machine complète (IaaS vs Paas). Par contre leur solution me semble un peu plus heavy weigh et le cout d’entrée un peu plus élevé. Je me donne comme première contrainte le fait de pouvoir switcher ma plateforme. Cela me semble difficile a première vue car les 2 plateformes offrent beaucoup de solution « clé en main » apportant de grande valeur ajouté (SimpleDB et EC2 pour Amazon Web Services, Système de stockage spécifique – BigTable – pour Google).

De façon plus ou moins arbitraire, je choisi AppEngine de Google. Cela me semble un peu plus rapide de développer quelque chose sur cette plateforme, il y a une une intégration avec les comptes google et peut être des API pour les autres applications google (calendar, docs) qui pourrait m’intéresser.

Pour le développement maintenant que le choix, et donc de ses contraintes, est fait, que prendre? N’oublions pas la cible: les smartphones en plus des navigateurs classiques. A ce moment, je ne sais pas exactement quel est le standard de communication entre un smartphone et une application cloud ? REST? SOAP ? JSON ? HTTP? Atom?

Bon je fais un petit tour des centres de développement de chaque plateforme:

Je me dis que je prends le problème un peu à l’envers. Quel est le standard actuel pour les applications web (google calendar, twitter, facebook, foursquare, live.com) et forcément je verrais quelle API ciblée (coté serveur ou client)

Site API

Phone API

Framework

Cloud / Mobile Development

Hello à tous,

Objectif: Développer une application accessible via un smart phone et/ou un navigateur web.

Je n’entre pas dans les détails « fonctionnels » de l’application. L’application doit avant tout être modulaire (ajout de fonctionnalité).

L’application devra être hébergé « in the cloud« . Le budget initial est approximativement le temps que je passe pour faire une 1ere version « utilisable » de application. Par utilisable, J’entends qui peut être diffusé à un premier groupe d’utilisateurs qui n’ont pas peur des petits bugs . La solution de publicité pour le financement (du projet) est envisagée mais pas souhaitée. L’objectif est plutôt de fournir une application dont la valeur ajoutée est suffisante pour que l’utilisateur accepte de payer pour son utilisation.

Comment restreindre au maximum le cout de l’infrastructure? La solution actuelle est les solutions « Cloud » d’Amazon Web Services, Google App Engine, Microsoft Azure, Rackspace Cloud, etc… L’intérêt de ces offres étant de payer à la consommation de ressource (bande passante, CPU, espace disque, etc…)

Le seul cout est donc le temps (libre!) que je passe à développer la plateforme. N’ayant pas une quantité infinie de temps libre puisque je suis actuellement sur une mission plus que prenante, une vie sociale, etc. il faut que les choix technologiques me permettent d’optimiser le temps à développer tout en prenant en compte les contraintes de la solution d’hébergement.

On écarte .net presque à regret puisque cette technologie semble connaitre un certain « momentum » dans le domaine de la finance ou j’exerce actuellement. Le langage semble cependant assez proche de java mais l’offre d’hébergement se limite à Azure qui est un peu plus cher que les concurrents. Pas de python, ruby non plus. Les quelques articles ou ligne de code que j’ai pu lire/modifier ne m’ont pas fait trop accrocher.

Ayant programmer sur Java pendant plus d’une dizaine d’années, le choix est à priori facile. De plus les offres de Google et d’Amazon ont semble t il choisi Java comme solution principale. Good.

Maintenant l’application a pour plateforme cible les smart phones et là ca se complique un peu. On pourrait penser qu’en 2010 le problème de la portabilité ne se poserait plus mais il n’en est rien. iOS (iPhone / Apple), Android (Google), Windows Phone 7 (Microsoft) chacun a développé sa propre solution et difficile de trouver une solution commune à part en développant une pure application web. La solution de webOS (Palm/HP) semble la plus ouverte puisque les applications se développent en HTML/javascript.

Bref c’est pas la joie. Je pensais que Java avait résolu ce problème il y a 10 ans… :( Seul Android a adopté cette plateforme. On a donc de l’objective C pour Apple. Ouch. De toute facon j’ai l’impression qu’il faut obligatoirement un mac pour pouvoir faire tourner le kit de développement iOS. Un moment d’espoir avec Mono Touch et Mono Droid qui auraient permis de développer en C# sur iphone, Android et bien sur WP7. Mais rebelote Mono Touch requiert un Mac et Mono Droid ne semble pas encore super mature. Point important, c’est payant! Bon solution suivante… Cela reste tout de même des solutions intéressantes pour ceux qui ont investi sur .net…

On cherche mais pas trop de solution à part la bonne vieille web app. On va partir la dessus dans un premier temps. Android propose un dev kit qui permet d’émuler un terminal, la part de marché importante de cette plateforme et le fait que l’on développe en java me permettraient de faire quelque chose rapidement.

J’ai acheté un WP7 il y a moins d’un mois. Je suis très très enthousiaste pour cette plateforme. C’est d’ailleurs cette première expérience avec ce mobile qui m’a poussé à me lancer dans l’aventure de ce projet. Je me mettrais à développer une application dédiée à cette plateforme rapidement.

iPhone a une part de marché énorme mais le cout d entrée est trop élevé pour moi. On verra quand on aura un peu de trésorerie si on peut faire quelque chose…

Bon je pense avoir fait le tour des grands choix techniques: hébergement in the cloud en java, web app pour le prototype mais on développe rapidement une application dédiée (Android ou wp7) pour une meilleure expérience.

La liste des fonctionnalités de la V1 est déjà faite. A présent je vais faire une rapide étude du choix des framework pour le développement du coté serveur.