Dreamisle.net Blog

Java, Rails, Security and so many ...

Applications Rails en Production Avec Nginx Et Unicorn Et Déployée Avec Capistrano

| Comments

Un peu d’infra aujourd’hui! Tout d’abord un grand merci à Bertrand Paquet de m’avoir formé à ces outils.


Pour faire tourner une application rails en production, on utilise souvent le duo passenger/apache. Personnellement j’ai lâché apache depuis longtemps pour Nginx. On ne va pas rentrer dans le débat du pourquoi mais essentiellement car Nginx est plus léger et plus performant.

Du coup pour mes applications rails j’utilisais le module nginx passenger. Sauf que celui ci est plein de bugs et très gourmand en ressources. La solution : unicorn.

Unicorn est un serveur rails léger pouvant être en écoute sur une socket unix. L’idée est donc de faire en sorte que Nginx et Unicorn communiquent à travers une socket unix. Un autre avantage du duo unicorn/nginx est qu’il permet d’heberger des applications rails sur autre chose que la racine d’un nom de domaine (par exemple dreamisle.net/monappli), hors avec passenger c’est très compliqué à faire.

Mais voyons un peu un exemple, admettons que je souhaite héberger une application Rails sur /monappli dans sur l’url mesapplis.dreamisle.net.

Nginx

Voyons déjà la configuration Nginx

upstream unicorn_upstream {
        server      unix:/home/leakim/ruby/monappli/shared/unicorn.sock fail_timeout=0;
}

server {
        access_log  /var/log/nginx/rails-access.log;
        error_log  /var/log/nginx/rails-access.log;
        server_name mesapplis.dreamisle.net;
        root  /home/leakim/ruby/dl/shared/www;
        location /monappli {
                proxy_set_header Host $http_host;
                if (!-f $request_filename) {
                        proxy_pass http://unicorn_upstream;
                        break;
                }
        }

        error_page 401 403 /401.html;

        error_page 404 /404.html;
        error_page 500 501 502 503 504 505 /500.html;

}

La partie interessante se situe dans le location /monappli. L’idée ici est que si nginx ne trouve pas le fichier demandé, il forward la requête sur la socket unix. la déclaration de la socket unix en haut du fichier de configuration est tout ce qu’il y a de plus classique.

Unicorn

Site officiel d’unicorn :

Unicorn est en fait une commande shell pour lancer un serveur rails que l’on configure via un script ruby. Configurons maintenant Unicorn.

Script de configuration unicorn

Celui-ci se configure via un script ruby. Voici un exemple de configuration.

worker_processes 3

app_directory = '/home/leakim/ruby/monappli'

working_directory "#{app_directory}/current"

listen "unix:#{app_directory}/shared/unicorn.sock", :backlog => 2048

timeout 600

preload_app true

pid "#{app_directory}/shared/pids/unicorn.pid"

stderr_path "#{app_directory}/shared/log/unicorn.stderr.log"
stdout_path "#{app_directory}/shared/log/unicorn.stdout.log"

if GC.respond_to?(:copy_on_write_friendly=)
  GC.copy_on_write_friendly = true
end

before_fork do |server, worker|
  old_pid = "#{app_directory}/shared/pids/unicorn.pid.oldbin"
  if File.exists?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
  # the following is recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.connection.disconnect!
  end
end

after_fork do |server, worker|
  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.establish_connection
  end
end

Config.ru

Il vous faut aussi compléter le fichier config.ru à la racine de votre application avec quelque chose de similaire :

# This file is used by Rack-based servers to start the application.

require ::File.expand_path('../config/environment',  __FILE__)

map ActionController::Base.config.relative_url_root || "/" do
    run Monappli::Application
end

Script de lancement d’unicorn

Notez le RAILS_RELATIVE_ROOT_URL qui indique à unicorn l’url relative utilisée.

#! /bin/sh

### BEGIN INIT INFO
# Provides:          unicorn
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts unicorn web server
# Description:       starts unicorn web server
### END INIT INFO

NAME="unicorn"
USER="leakim"
DAEMON="/home/$USER/.rvm/bin/rvm-shell"
APP_DIRECTORY="/home/leakim/ruby/monappli"
PID_FILE="$APP_DIRECTORY/shared/pids/unicorn.pid"
CONFIG_FILE="$APP_DIRECTORY/shared/unicorn.conf.rb"
UNICORN_CMD="unicorn_rails"

export RAILS_RELATIVE_URL_ROOT="/monappli"

test -x $DAEMON || exit 4
test -d "$APP_DIRECTORY/current" || exit 5
test -f $CONFIG_FILE || exit 6

CMD="cd $APP_DIRECTORY/current && source .rvmrc && bundle exec $UNICORN_CMD -E production -D -c $CONFIG_FILE"

set -e

. /lib/lsb/init-functions

kill_unicorn() {
  SIGNAL=$1

    if [ ! "$PID_FILE" = "" ]; then
        if [ -f $PID_FILE ]; then
            kill $SIGNAL `cat $PID_FILE` || true
       fi
    fi
}

case "$1" in
   start)
    echo -n "Starting $NAME: "
    start-stop-daemon -c $USER --start --exec $DAEMON -- -c "$CMD" || exit 1
    echo "$NAME."
    ;;
  stop)
    echo -n "Stopping $NAME: "
    kill_unicorn
    echo "$NAME."
    ;;
  graceful_restart)
    echo -n "Graceful restarting $DESC: "
    kill_unicorn "-USR2"
    echo "$NAME."
    ;;
  restart)
    echo -n "Restarting $NAME: "
    kill_unicorn
    sleep 1
  start-stop-daemon -c $USER --start --exec $DAEMON -- -c "$CMD" || exit 1
    echo "$NAME."
    ;;
  status)
    status_of_proc -p $PID_FILE $UNICORN_CMD $UNICORN_CMD && exit 0 || exit $?
    ;;
  *)
    echo "Usage: $NAME {start|stop|restart|status|graceful_restart}" >&2
    exit 1
    ;;
esac

exit 0

Capistrano

Capistrano est un outil de gestion de déploiement distribué. L’idée est de pouvoir depuis son poste local, taper “cap deploy” pour deployer l’application en production. Capistrano peut aussi être utilisé en mode multistage pour utiliser plusieurs serveurs/environnements différents pour déployer. Je vous invite à découvrir l’outil ici : Capistrano. Ce fichier nommé deploy.rb doit être placé dans le repertoire config/ de votre application rails. Il vous permettra une fois la gem install (gem install capistrano), de lancer en local “cap deploy” pour déployer.

Si vous n’utilisez pas RVM il faut bien entendu supprimer tous les appels à celui-ci.

set :ssh_options, { :forward_agent => true } # utilise la clef ssh local et utilise l'option ssh forward agent, ce qui permet par exemple à git de cloner avec votre clef local
set :default_shell, "PATH=$HOME/.rvm/bin:$PATH bash"

set :user, 'leakim'
set :rails_relative_url_root, "/monappli"
set :deploy_to, "/home/leakim/ruby/monappli/"
set :use_sudo, false

server "monserver.net", :web, :app, :db

set :scm, :git
set :application, "monappli"
set :repository,  "git@github.com:user/repo.git"
set :deploy_via, :remote_cache

set :branch, 'master'

namespace :deploy do
  
  task :start do
    run "/etc/init.d/unicorn start"
  end
  
  task :stop do
    run "/etc/init.d/unicorn stop"
  end
  
  task :restart, :roles => :app do
    run "/etc/init.d/unicorn restart"
  end

end

after 'deploy:finalize_update', 'rvm', 'bundle', 'db_config', 'db_migrate', 'precompile_assets'

task :rvm, :roles => :app do
  run "cd #{release_path} && source .rvmrc"
end

task :bundle, :roles => :app do
  run "cd #{release_path} && source .rvmrc && bundle --without development"
end

task :precompile_assets, :roles => :app do
  prefix = rails_relative_url_root && rails_relative_url_root.size > 0 ? "RAILS_RELATIVE_URL_ROOT=#{rails_relative_url_root}" : ""
  run "cd #{release_path} && source .rvmrc && #{prefix} RAILS_ENV=production rake assets:precompile --trace"
end

task :db_config, :roles => :app do
  run "cd #{release_path} && ln -s #{shared_path}/database.yml config/database.yml && ln -s #{shared_path}/configuration.yml config/configuration.yml"
end

task :db_migrate, :roles => :db do
  run "cd #{release_path} && source .rvmrc && RAILS_ENV=production rake db:migrate --trace"
end

Ruby Et RVM Sous Mac Os Lion

| Comments

Mac OS X et les galères de ruby

Sous Snow Leopard je n’arrivais pas à faire tourner ruby 1.9.2 avec RVM, la compilation échouait systématiquement malgré de nombreux tutoriaux du net suivis.

Passé à Lion magie ruby 1.9.2 puis plus tard 1.9.3 fonctionnent ! Mais la magie s’arrête là car les applications en ruby 1.8.7 ou avec REE (ruby enterprise edition) ne voulaient plus marcher. En effet, impossible d’installer ree sous Lion. Suivant divers liens et posts Stackoverflow j’ai trouvé qu’il fallait faire un export CC=/usr/bin/gcc-4.2 pour utiliser le gcc standard et non le gcc-llvm (low level virtual machine) fourni par les developpeurs tools de XCode 4.2 (la version pour Lion).

Néanmoins pas moyen de trouver l’exitence de ce gcc-4.2. Il semblerait que la solution réside dans l’installation de XCode 4.1 à la place de 4.2.

Pour le télécharger c’est ici :

XCode 4.1 pour Lion

Les étapes :

  1. Supprimer les install xcode present dans /Applications
  2. Desinstaller votre version d’XCode : /Developper/Library/uninstall-devtools –mode=all
  3. Installer le InstallXcode.pkg présent dans le dmg téléchargé avec le lien ci dessus
  4. Installer “Install XCode” que le package ajoute dans /Applications
  5. Reinstaller rvm : rvm implode puis bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
  6. Tester d’installer ree : CC=/usr/bin/gcc-4.2 rvm install ree

Puis on peut reinstaller les autres versions de ruby : rvm install 1.9.2, rvm install 1.9.3 avec le gcc-llvm ça marche sans problèmes!

Hope that’s will help someone else!

Mise à Jour Du Blog

| Comments

Octopress

Le blog dans son ancienne version était fait avec Jekyll un générateur de site fait en ruby. Je suis maintenant passé à Octopress qui est en fait une intégration de Jekyll dans un outil plus simple à utiliser avec tout un outillage de scripts très utiles. Je n’ai pas encore eu le temps de refaire le design du site mais ça viendra rapidement.

Bon je reconnais que j’ai rien publié depuis un an… pourquoi ?

  • J’ai publié sur le blog OCTO, je vous invite d’ailleurs à visiter le lien dans la barre de menu ci-dessus pour voir mes derniers articles du blog OCTO.
  • J’ai joué avec pas mal d’outils que je vous présente à la fin de cet article
  • J’ai contribué et co-géré la refonte du middleware d’une grande banque en ligne, ce n’est pas une mince affaire :)
  • j’ai été à Devoxx et derrière j’avais envie d’essayer tout ce que j’ai vu… dur d’être un geek :)
  • La vie suit son cours et des fois on laisse un peu son blog de côté …

Quelques trucs de geek avec les quels j’ai joué récemment et que je vous conseilles de fouiller

Coté dev :

  • Git : plus besoin de présenter ce superbe DVCS qui a changé ma vie de développeur mais aussi d’admin sys.
  • Starteam : le plus mauvais VCS que j’ai jamais utilisé. Je crois que je préférerais CVS ou même un répertoire partagé sur un disque réseau …
  • CXF : un superbe framework pour JAX WS 2.0 / SOAP. La documentation est très bien pour les bases, pour l’approfondissement et faire des trucs un peu “sioux” il ne faut pas hésiter à fouilleur leur code qui est truffé d’astuces en tout genre
  • Spring 3 : Trop connu pour que j’ai besoin d’exprimer mon avis dessus
  • Ruby on Rails : c’est juste génial, j’en suis à quelques applis dont certaines professionnelles faites avec et je suis bluffé par la rapidité de développement et les possibilités de ce langage et de ce framework. Mélé à Capistrano et Unicorn pour le déploiement c’est juste magique. On développe vite, et on déploie vite. Quelques gems utiles :
    • Haml : permet de réduire la verbosité du HTML que vous écrivez en utilisant des tags et l’indentation.
    • ruby-openid : pour mettre en place openid sur votre application rails
    • rvc : permet de piloter des ESX à distance via des scripts ruby

Coté infra :

  • Nginx : Apache devient vite une usine à gaz, Nginx est beaucoup plus performant de part son modèle de programmation (orienté acteur). Petit regret il est beaucoup plus compliqué qu’apache à utiliser/administrer.
  • Unicorn : un serveur rails très performant. Comme nginx il est un peu compliqué à prendre en main Prochainement je compte écrire un article sur comment configurer Nginx et Unicorn pour qu’ils fonctionnent ensemble.
  • Capistrano : un gestionnaire de déploiement automatisé pour les applicationss rails mais qui peut s’adapter à
  • JBoss 7 : Hallucinant de rapidité de démarrage et de déploiement. Entièrement scriptable et ça c’est génial pour ceux qui font du devops. Truffé de nouvelles fonctionnalités fort utiles pour les applications Java/JEE.
  • OpenShift : JBoss 7 dans le cloud, le pendant RedHat de SpringSource CloudFoundry en quelque sortes. votre cloud gérable depuis eclipse ou depuis la ligne de commande, et un cluster de jboss qui se met en place très facilement. Votre application devient donc scalable simplement.

Côté outils :

  • Gollum : un systeme de wiki basé sur git : vous redigiez vos pages en textile/markdown… vous les versionnez avec git. Gollum n’affiche que ce qui est présent dans l’index (commité).
  • Redmine : un très bon systme de gestion d’issues
  • Bitbucket : un concurrent à github ou pas vraiment. Chez github les repository gratuit sont public. Chez bitbucket on peut avoir des repos privé gratuitement.
  • Octopress qui propulse ce blog

Mettre à Jour Un Sonar Existant

| Comments

Tout d’abord voici un peu listing de nouveautés entre Sonar 1.11.1 et Sonar 2.4.1 (qui représente mon saut de mise à jour)
  • Correction de bugs
  • Supports de nombreux plugins (gwt …)
  • Importante hausse des performances
  • Intégration de WebServices pour interroger sonar à distances
  • Ajout d’une gestion complète des utilisateurs + possibilité de le brancher à un référentiel externe (à étudier dans une prochaine évolution du Sonar OCTO)
  • Coloration syntaxique du code
  • Dashboard customizables
  • Mise en place d’un Update Center pour les plugins
Mes recherches sur la toile ne m’ont pas donné de réponse à comment faire une migration d’une version majeure de sonar à une autre je rédige donc un court article de blog à ce sujet en espérant qu’il aidera.

Si vous êtes amenés à mettre à jour un sonar déjà installé (en version war déployé dans mon cas) vous pourriez vous dire comme moi que changer le war sera suffisant.

Néanmoins ce n’est pas le cas, entre chaque versions la structure des tables de la base de données sonar change.
Dans mon cas il s’agissait de passer de la version 1.11.1 à la version 2.4.1 : une montée de version majeure.
Une première tentative avec le war de la 2.4.1 fut un échec.
Aussi bien en essayant de le faire partir sur une base de donnée existante qu’en tentant de le lancer sur une base vide puis d’insérer les données après.

La démarche est donc bête est méchante : il faut passer progressivement toutes les versions entre votre actuelle et celle que vous voulez atteindre.

En fait chaque version dispose de son propre script de mise à jour de la base de données (fait en rails d’ailleurs donc n’oubliez pas de l’installer sudo apt-get install rails sur un ubuntu/debian).
A chaque nouvelle version déployée appelez l’url : http://votreserveur/sonar/setup et suivez les instructions.
Sachez toutefois que les version 2.3 et 2.4 ne sont pas nécessaires car elles sont buggées, passez directement aux 2.3.1 et 2.4.1.

Personnellement je suis un peu déçu qu’un outil aussi bien fait que Sonar ne dispose pas d’un système de mise à jour plus évolué que ça. Ou bien au moins d’une doc expliquant de quelle version à quelle version il est possible d’upgrader.
Enfin ça ne m’empêchera pas de continuer d’utiliser ce formidable outil de qualimétrie de code qui est devenu indispensable dans mes développements aujourd’hui.

La Gestion Des Exceptions en Java

| Comments

La gestion des exceptions, un sujet brulant dans beaucoup d’applications. Après quelques audits chez des clients d’Octo je me suis dit qu’un petit article rappelant quelques notions serait utile à tous. Voici donc mon dernier article pour le blog d’Octo :

L’article sur le blog

Nouveau Blog Et Nouveau Design

| Comments

Ces derniers temps j’en avais marre des mises à jours incessantes de Wordpress. Qui plus est je commençais à trouver ce CMS de plus en plus usine à gaz. Comme quelques aficionados j’ai donc décidé de migrer sur Jekyll.

Jekyll

Jekyll est un générateur de site static, c’est à dire que j’écris mes posts à partir d’un langage de template avec une syntaxe style wiki, que je lance mon générateur et que je récupère un site en html au bout. Alors vous allez me dire pour un blog c’est pas pratique ! Et bien figurez que vous que si. Je versionne les fichiers des posts (markdown) et l’ensemble du site, ainsi que le site généré avec git et lorsque j’écris un post je n’ai qu’à faire un git push :) Ainsi je peux rédiger mes posts avec un vrai éditeur (vim ou textmate dans mon cas) et pas avec une textarea tentant d’imiter un traitement de texte et au final me prenant plus de temps pour la mise en page que la rédaction. Comme vous pouvez le voir la coloration syntaxique est aussi active sur les posts ayant du code. Quant aux commentaires j’ai tout migré sur disqus, ainsi ils sont hebergés sur un provider externe et chargés sur les pages en javascript.

Voilà, si vous avez vous aussi un blog je vous conseille de regarder ce système qui après un peu de travail vous facilitera grandement la vie et vous préviendra de tous les problèmes de sécurité des applications types wordpress qu’il faut mettre à jour plusieurs fois par semaine des fois (quand on a un certain nombre de plugin).

Ah oui, je me suis pas mal mis au ruby ces derniers temps et Jekyll est fait en ruby :)

Je vous renvoi à l’article d’un collègue d’Octo sur le sujet : http://david.rousselie.name/2009/11/09/migration-wordpress-jekyll/

L’ancien blog est toujours en ligne à cette adresse : http://dreamisle.net/wordpress/

La Fédération D’identité en Entreprise

| Comments

La gestion des identités est un domaine qui reviens à grand pas dans les sujets chauds du moment en grande partie grâce à l’avénement du cloud Computing. Suite à mon stage sur la fédération d’identité chez Octo Technology et à mon embauche dans l’entreprise j’ai rédigié un article sur le blog Octo sur le sujet, je vous invite donc à le lire.

Désormais j’alternerais les publications entre le blog Octo et celui-ci mais je mettrais des liens sur ce blog en cas de publication chez Octo.

Bonne lecture à vous !

L’article : http://blog.octo.com/la-federation-d%E2%80%99identite-en-entreprise/

PicketLink, Fédération D’identité Et SSO

| Comments

Comme vous avez pu le voir j’ai peu publié ces derniers temps pour la simple raison que j’avais explicité précédemment : je travaille actuellement sur un domaine un peu transverse la fédération d’identité.

Je publierais prochainement des articles sur le fonctionnement et les grands principes de la fédération d’identité  mais en attendant pour ceux qui ont déjà des notions de fédération ou de SSO je voulais vous présenter un projet de JBoss que j’approfondie en ce moment : PicketLink.

Voici une brêve présentation de PicketLink :

Le site officiel de PicketLink

PicketLink est un projet libre soutenu par JBoss qui a pour but d’englober différentes problématiques de gestion d’identité communes :

  • Security Token Service : WebService fournisseur de Token, basé sur la spec WS-Trust
  • SAML : API permettant de communiquer en SAML avec un identity ou service provider compatible.
  • Identity Manager : Vous permet d’implémenter votre propre Identity Manager interconnectable en SAML en vous fournissant un cadre architectural et de développement.
  • XACML : API vous permettant d’avoir une gestion des autorisations fines et distribuée un peu à la manière de SAML mais complètement orientée autorisation (XACML 2.0 ici).
  • Negociation : Fournit un négociateur Kerberos/SPNego pour le SSO orienté desktop.

Grosso modo il vous permet de résoudre dans votre application les problématique de SSO et de fédération d’identité.

Il s’agit plus d’une grosse API et d’un ensemble de classes à appeler/configurer qui sont prêtes à l’emploi que d’un progiciel ou d’un logiciel de fédération d’identité.

A l’heure ou ces lignes sont écrites PicketLink est encore en release candidate mais j’ai pu réaliser quelques PoC tout à fait fonctionnels et efficaces.

PicketLink profite de l’avantage de la communauté JBoss : celle ci est large et très réactive (j’ai eu des réponses à mes questions sur les forums parfois dans la journée même du post avec même une release faite le lendemain d’un de mes signalements de bug), les documentations sont complètes et claires, la communauté aide beaucoup.

PicketLink propose un ensemble de projets d’exemples des possibilités de l’API qu’il suffit de déployer et de tester.

Il est prévu pour fonctionner avec JBoss et Tomcat.

Là ou Picketlink concerne plus particulièrement ce blog, c’est dans le fait qu’il apporte aussi un module Seam pour intégrer dans une application Seam les possibilités de

  • SSO
  • Communication SAML
  • Externalisation de l’authentification et Interconnection avec un IDP SAML
  • Externalisation de l’authentification et Interconnection avec un IDP OpenId

Grâce à ce module et l’API de sécurité de Seam il est donc possible de sécuriser :

  • Les pages
  • Les ressources
  • Les webservices
  • L’appel de méthode/d’objets

Quelques tutoriaux interessant sur PicketLink  :

Sortie De JEE 6, Qu’en Est Il De L’avenir De Seam?

| Comments

Avec la sortie de java EE 6 on peut se demander quel est l’avenir de Seam. J’écris cet article car j’ai eu cette discussion avec quelques personnes et j’aimerais exprimer mon opinion la dessus. En effet une bonne partie des éléments pouvant amener à utiliser Seam tels que l’injection de dépendance, le nommage de Pojo via une annotation (@Name) etc … Mais aussi toutes les améliorations apportées à JSF 1.2.

Si vous avez suivi les apports de la Spec JEE 6, on a un équivalent au @Name : le @Named. Pour ce qui est de l’injection de dépendance (@In) elle est présente et aussi simple que celle de Seam grâce à Weld (ou CDI). Enfin, l’arrivée de JSF 2.0 nous amène un JSF encore plus simplifié qu’un JSF amélioré par Seam.

On peut donc se demander si on doit garder Seam ou tout passer en JEE 6 ?

Déjà, il ne faut pas oublier une chose cruciale : c’est bien les concepteurs et développeurs de Seam qui ont contribué aux nouvelles spécifications de JEE6 qui font le plus parler d’elle : à savoir CDI (implémenté par Weld), l’injection de dépendances, et JSF 2. Mais aussi la suppression de la couche intermédiaire entre JSF et EJB. De mémoire Seam a aussi contribué aux améliorations faites sur la norme EJB. Donc Seam est derrière les nouveautés majeures de JEE 6!

En fait pour moi, il est évident, si on suit la volonté initiale de Seam, qu’il faut coller le plus possible aux standards. Contrairement à Spring qui part du principe que la spec JEE n’est pas bien/efficace Seam est parti du principe qu’on pouvait l’améliorer et la faciliter tout en respectant les normes et standards apportés par celle-ci.

Mais limiter Seam à ce rôle est bien réducteur.

L’intégration simplifiée de nombreux frameworks et outils est pour moi un des éléments clefs du framework. Si vous l’utilisez vous avez du être aussi bluffé que moi lorsque vous chercher à intégrer Hibernate Search, iText ou encore Quartz et jPBM et j’en passe. Tous ces éléments sont nécessaire à de nombreuses d’applications, et pourquoi se compliquer la vie quand il suffit d’ajouter une à quelques lignes dans un fichier components.xml pour les intégrer ?

Voilà grosso modo pour moi la direction que devrait prendre Seam dans l’avenir, c’est à servir de sandbox à framework pour les intégrer dans une appli JEE6 standard.  Mais aussi apporter ses outils : génération excel, seam mail, seam pdf, Seam Remoting,intégration simplifiée d’Hibernate et Hibernate Search … et n’oublions pas nos composants Seam nous apportant quasiment autant que les EJB sans nécessiter de conteneur lourd.

Bref si les développeurs de Seam continuent à améliorer tout cela, on risque d’avoir dans les mois à venir un framework vraiment complet, et une vraie boite à outil archi complète pour JEE6.

Donc un bel avenir bien prometteur, aidé par la standardisation dans la spec JEE des idées innovante apportées initialement par Seam, qui va permettre aux développeurs de Seam de se concentrer sur le côté boite à outil :)

java-duke-guitar_m

Evolutions Du Blog, à Propos De L’auteur …

| Comments

Si vous avez lu un peu la section a propos, vous avez déjà une petite idée de qui je suis.

Pour parler un peu de moi et de ou j’en suis, je fini bientôt mes cours à l’UTC (le 18 janvier) et à partir du 1er février je ferais mon stage de fin d’études (6 mois), chez Octo Technology.

octo_logo-35c73

Je pense que je vais énormément apprendre chez Octo qui est à mes yeux une des meilleures entreprises Française aussi bien au niveau JEE qu’au niveau méthodes agiles. Je vous conseille d’ailleurs leur blog très instructif et complet, mais aussi les livres blancs qu’ils ont publié.

Octo est à la pointe de la technologie et est en constante veille sur tout ce qui tourne autour de l’architecture logicielle et de JEE mais aussi des méthodes agiles, vu mon cursus et mes passions j’ai donc tout fait pour entrer la bas et ce fut avec succès. Les architectes d’Octo Technology contribuent d’ailleurs beaucoup à l’Open Source, et participent à de nombreuses conférences (Jug, Devoxx …) et sont souvent très enclins à transmettre leurs compétences. Octo organise aussi l’USI, l’université du système d’information, une fois par an (Voir ici).  Il faut savoir qu’un consultant ou architecte chez Octo passe entre 10 et 15% de son temps de travail en formation/veille, ce qui explique leur haut niveau. Personnellement après les entretiens que j’ai passé et discussion avec des connaissances qui ont des contacts chez Octo,  ça me laisse rêveur  :)

Mon sujet de stage est plutôt orienté sécurité applicative je pense donc que j’écrirais donc des articles à ce propos très rapidement, je vais plus précisément  travailler sur la fédération d’identité.  En effet en dehors de mes loisirs et travails temporaire sur JEE ma formation à l’UTC est plutôt orienté Système / Réseau / sécurité. Je vais donc pouvoir méler ma passion pour JEE et l’architecture à mon intérêt pour le système et la sécurité.

Maintenant concernant le blog,  finissant mon école d’ingénieur j’ai énormément de travail sur divers projets (certains en Seam, d’autre pas). Et comme je travaille aussi pour une entreprise à temps partiel comme ingénieur JEE en plus de l’école, j’ai été carrément débordé ces derniers temps.  Je commence aussi à m’ouvrir un peu aux autres frameworks et à regarder un peu ce qui se fait ailleurs, comme par exemple GWT ou plus récemment le framework Play! Je travaille aussi pas mal sur tout ce qui est sécurité informatique (réseau, système et applicative) pour mes cours.

Bref tout cela explique aussi la faible régularité de publication sur le blog depuis 2 ou 3 mois.

Toujours est il que je réfléchi à diversifier un peu le thème de ce blog car je découvre souvent des choses que je pense qu’il serait bien de faire partager à tout le monde … Donc pourquoi parler un peu de Java EE6 quand j’aurais le temps de m’y mettre à fond, mais aussi d’autres frameworks java, voir même de sécurité applicative ?

Bref à voir, n’hésitez pas à me laisser vos commentaires si ces sujets vous intéressent (ou pas).