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

Getting Things Done (mais Done Done) – S02E01

Il y a 8 mois, nous avions ouvert une de nos sessions de formation au format BBL sur GTD (Getting Things Done) à 5 participants externes.

Bilan : vous étiez 10 à venir nous rendre visite. Merci à vous !

Re-re-belote, nous la rejouons le lundi 30 septembre 2013 de 12h30 à 13h30. Même présentateur, même format, même ambiance de folie, mais avec des petits chatons !

Toujours ouvert à 5 personnes externes, les premiers seront les premiers ! Envoyez votre mail de motivation sans langage SMS à dalia@octo.com.

Tout le détail a déjà été décrit sur cet article de blog.

Pour les plus fainéants, les plus récalcitrants ou les plus numériques d’entre vous, vous pourrez suivre cette présentation en direct live sur tv.octo.com.

A bientôt !

 

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

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

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

Applications mobiles multi-plateformes: les approches PhoneGap et Titanium Mobile

Introduction

Le développement d’applications pour terminaux mobiles (iPhone, iPad, Android, Blackberry, Windows Phone, Nokia Symbian, Samsung Bada…) se heurte à la fragmentation des technologies de développements: environnement iOS/Objective-C pour l’iPhone et l’iPad, SDK Java spécifique pour Android, J2ME pour Symbian, etc.

Deux approches possibles lorsque l’on débute un projet d’application ciblant plusieurs de ces plateformes sont de développer une application pour chacune d’elle, ou de développer un site Web compatible.

Dans le premier cas, l’inconvénient concerne bien évidemment le coût des développements. Dans le deuxième, on sera limité en richesse de l’application par les possibilités du Web.

Ce fut l’objet d’un précédent article sur notre blog: http://blog.octo.com/debat-web-apps-vs-natif/.

Entre ces deux approches se situe une offre assez fournie de solutions de développement multi-plateforme, proposées par des éditeurs proposant leurs propres plateformes d’exécution et leurs outils de développement.

Parmi celles-ci, nous nous sommes concentrés dans cet article sur PhoneGap et Titanium Mobile, qui sont aujourd’hui parmi les plus abouties et sont représentatives des deux principales approches de développement multi-plateforme: l’utilisation des moteurs de rendus Web pour PhoneGap, et la translation de code source vers la plateforme cible pour Titanium.
Lire la suite

J’ai l’impression d’écrire mes tests en double !

En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci:

- Pourquoi écrire ces tests FitNesse/GreenPepper alors que j’ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ?

JUnit vs FitNesse

La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO…

Lire la suite

Du TDD pour Silverlight aussi !

A moins de s’être limité à dessiner des ronds et des carrés avec Silverlight, vous avez sans doute déjà tenté d’utiliser un des templates de projets du Silverlight Toolkit permettant de faire des tests unitaires pour vos applications RIA! Plein de bonne volonté, vous vous êtes heurtés aux multiples inconvénients de cette solution :

  • Framework de tests spécifique à Silverlight
  • Obligation de lancer une application « conteneur » pour lancer vos tests
  • Usabilité plus que discutable de cette même application
  • Impossibilité d’utiliser une métrique comme la couverture de code
  • et j’en passe…

N’abandonnez pas encore ! Je vous proposer ici une solution pour venir à bout de ces limitations… plus d’ excuses, vous pourrez tout tester …

la suite par ici en anglais

 

Un workspace Eclipse standardisé

Uniformiser vos environnements de développement – Gagner en productivité

Marre des merges galères pour cause de formateurs différents ?

  • Marre qu’un membre de l’équipe commit en UTF-8, l’autre en ISO-8859-1 ?
  • Marre de reconfigurer la JDK, Checkstyle, PMD, le repo SVN, le proxy de la boite, et des millions de paramètres à chaque création d’un nouveau workspace ?

Ce tip & trick est pour vous !