Les nouvelles architectures front Web et leur impact sur la DSI – partie 2

Dans la partie 1 de cet article, nous avons traité des nouvelles architectures front-end basées sur des applications Web massivement Javascript appelant des API offertes par un serveur back-end : les nouvelles architectures front Web et leur impact sur les DSI – Partie 1.

Nous avons vu qu’elles sont apparues ces dernières années grâce à l’augmentation des performances des navigateurs et à l’amélioration des outils d’industrialisation des développements Javascript.

Dans cette seconde partie, nous nous intéresserons aux raisons pour lesquelles on devrait choisir ces nouvelles architectures, aux opportunités qu’elles offrent, et aux conséquences sur les organisations des directions informatiques.

(Lire la suite…)

Les nouvelles architectures front Web et leur impact sur les DSI – Partie 1

Les applications Web évoluent. Depuis les premiers sites en HTML statique jusqu’aux applications AJAX de ces dernières années, en passant par les multiples technologies de sites Web dynamiques (PHP, ASP, Java, Rails…), les architectures applicatives et les outils pour les mettre en place connaissent régulièrement des avancées majeures et des points de ruptures.

Depuis deux ans, nous voyons venir une nouvelle vague technologique qui submerge le paysage des applications Web. Celle-ci n’a pas encore de nom bien défini comme ont pu l’avoir les RIA ou AJAX. Nous les appellerons les « architectures MV* côté client ».

Elles se constituent principalement de ce principe d’architecture : le serveur ne doit plus gérer l’affichage mais seulement envoyer des données brutes à afficher, et toute la génération des écrans et la gestion des interactions avec l’utilisateur doivent être géré côté client, c’est-à-dire dans le navigateur.

Dans ce billet, nous préciserons cette architecture et expliquer les raisons de son émergence. Dans un second billet, nous verrons pourquoi il est pertinent de les mettre en place dès aujourd’hui, les opportunités qu’elles offrent, et quels sont les impacts à prévoir pour les DSI.

(Lire la suite…)

Lettre ouverte à Xavier Niel et l’équipe pédagogique de 42.fr

Le 26 mars dernier, vous lanciez l’école 42 en grande pompe et chez OCTO, nous avons accueilli cette nouvelle avec un enthousiasme sincère. Enthousiasme sur le fond : votre ambition de former les développeurs de demain, productifs immédiatement, inscrits dans une démarche collective de travail en équipe. Enthousiasme sur la forme : une école gratuite, ouverte à tous sans qualification requise, une émulation saine, reprenant notamment le concept de la « piscine » cher aux écoles EPIT*, révélateur de vocations.

Merci à vous de casser les codes et d’introduire une rupture dans l’éducation traditionnelle des futurs professionnels de l’informatique.

Depuis deux semaines, le format et le contenu pédagogique ont été révélés, nous laissant cette fois dans l’expectative. Toujours rien à redire sur la forme : c’est clair, c’est complet. Pourtant, sur le fond, nous sommes frustrés.

(Lire la suite…)

Reprise de données lors d’une refonte IT agile

Les données sont au cœur de votre business. Susceptible de reporter la mise en production de votre nouvelle application, il faut considérer la reprise de données comme une étape importante de votre processus de refonte.

La reprise de données est un aspect technique particulier de la refonte qui doit être pris en charge par une équipe dédiée (il suffit d’un développeur et d’un PO pour former une équipe) dès le début du projet afin d’anticiper la complexité des règles de reprise, de vérifier le bon fonctionnement de l’application (et oui !) et d’éviter des choix de conception logicielle pouvant bloquer la reprise.

Si vous comptez vous lancer dans cet exercice périlleux, voici quelques retours d’expériences issus d’un projet de refonte d’une application client lourd vers une architecture cible classique (web, java, hibernate, …), mené en agile, avec en parallèle et sur le même rythme agile, le projet de reprise de données.

(Lire la suite…)

Design Patterns : Saison 2

 

Design Patterns are signs of weakness in programming languages
– Mark Dominus

Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily
– Design Patterns, Gang Of Four

Face aux lacunes de chaque langage, les programmeurs ont inventé des mécanismes réutilisables pour faire face à un certain nombre de problèmes récurrents. Au travers de plusieurs exemples concrets, cet article va montrer comment un programmeur peut rendre son code plus compact en choisissant un langage de programmation qui ne souffre pas des mêmes problèmes.

(Lire la suite…)

Les Patterns des Grands du Web – Contribution au Logiciel Libre

Mais pourquoi Facebook, Google et autre Twitter contribuent-ils autant à l’open source ?

L’avance technologique est un atout important dans la conquête du Web. Que ce soit pour se démarquer de la concurrence en lançant de nouveaux services (pensez à la sortie de Gmail et de son large stockage à l’époque de l’hégémonie Hotmail), ou plus pragmatiquement pour faire face aux contraintes qui leur sont propres comme le défit de croissance lié à leurs bases utilisateurs, nous allons voir que les Géants du Web ont su à plusieurs reprises inventer de nouvelles technologies.

Alors que l’on pourrait penser que cette maitrise technologique, cet actif que représente le code, devraient tout deux être secrètement conservés, voilà qu’un pattern largement répandu nous interpelle : les Géants du Web ne sont pas seulement de grands consommateurs de technologies open-source, ils en sont aussi les principaux contributeurs.

(Lire la suite…)

D’un site mobile à une véritable application Web

La navigation mobile (smartphone ou tablette) s’est sans conteste accaparée une partie non négligeable du trafic Internet, et son augmentation ne fait pas de doute. Pour répondre à l’arrivée de ce nouveau support de consultation, nombres de sites ont commencé par adapter leur présentation pour une lecture agréable. Aujourd’hui, le mobile fait l’objet d’une véritable stratégie d’entreprise et ce sur de nombreux fronts : organisationnel, marketing et technologique notamment.

Ce dernier point amorce aujourd’hui un virage naturel mais peu évident à négocier, tiré par la démocratisation des usages et donc d’attentes plus élevées de l’utilisateur : il ne cherche plus seulement une déclinaison mobile d’un site web, mais une véritable expérience comme attendue dans une application native.

(Lire la suite…)

Vers une Usine de Développement 2.0

En repartant de l’usine de développement tel que nous la connaissons aujourd’hui, nous allons tenter de vous initier à notre vision de l’UDD (Usine de développement) de demain.

En effet, en interne chez OCTO nous travaillons activement sur ce sujet de recherche. Pourtant, avant de rentrer dans les séduisants concepts qu’il pourrait apporter, revenons sur les principes et limites de ce que l’on considère comme une UDD 1.0.

 

Mais c’est quoi une UDD ?

C’est une usine logicielle, contenant des outils pour le développement et permettant d’automatiser tout ce qui peut l’être et ce dans le processus de construction logiciel de bout en bout. Elle joue un rôle important dans l’industrialisation des développements : c’est la clé de voûte de l’intégration continue. Elle permet aussi de construire les livrables sous forme de versions de/des applications.

En effet, le développement logiciel actuel (à l’état de l’art) suit un processus centré sur l’usine de développement. Cela permet de mieux contrôler la qualité des développements et de fournir des indicateurs sur leurs progressions. Nous allons voir comment par la suite. Cette usine de développement se doit aussi d’intégrer tous les outils nécessaires au développement: la documentation, le wiki et le gestionnaire de sources en fait donc partie. Comprenez là qu’il ne s’agit pas d’un logiciel central (type Jenkins), mais d’un ensemble de logiciels branchés entre eux pour faciliter le processus de construction d’applications, depuis le développement jusqu’à la mise en production.

Pour avoir une vision concrète d’une UDD, nous proposons de la représenter schématiquement comme ceci :
(Lire la suite…)

Thrift et Protocol Buffers : compacité du message sérialisé dans le monde Java

Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.
(Lire la suite…)

Sérialisation : Thrift et Protocol Buffers, principes et aperçu

La sérialisation est une des bases de la transmission de données entre systèmes. Certains langages proposent d’ailleurs une méthode de sérialisation en standard, qui leur est souvent propre.

L’interopérabilité entre systèmes hétérogènes nécessite que le format de sérialisation soit compréhensible par différents langages et plates-formes. De nombreux standards utilisent le mécanisme d’IDL (Interface Description Language) pour répondre à ce besoin : ASN.1, CORBA ou encore SOAP.

Depuis quelques années, de nouveaux frameworks basés sur un IDL ont vu le jour pour l’interopérabilité de technologies hétérogènes dans une optique d’économie de bande passante. Parmi eux, on trouve Thrift et Protocol Buffers. Ce premier article présente les deux frameworks sous l’angle de la sérialisation des messages et détaille leur utilisation en Java.
(Lire la suite…)