“L’ergonomie n’est plus négociable aujourd’hui”. OCTO Technology

L’aspect incontournable de la performance

Il existe une conviction partagée chez les grands du Web : la performance perçue par l’utilisateur est critique. Cette performance a en effet un impact direct sur l’adoption du service et son utilisation dans la durée. Et le ressenti utilisateur est directement lié à la rapidité d’affichage des interfaces.

Le grand public se moque bien de l’architecture logicielle, de la puissance des serveurs, de la latence réseau provoquée par l’appel à des Web services… Tout ce qui lui importe, c’est l’impression de fluidité dans l’usage.

(Lire la suite…)

Quel « business model » pour les opérateurs de télécommunications grand public ? Orange, Bouygues Télécom et SFR se veulent fournisseurs de services, voire de contenus, et donc ne veulent pas être de simples fournisseurs de tuyaux. La 4G, les « pure players » internet, les nouveaux usages, les réglementations de l’Arcep et autres remettent en cause cette vision. Ce billet est l’occasion de partager quelques réflexions autour de cette question : quel « business model » pour les opérateurs grand public ?

(Lire la suite…)

Dans tout système d’information, les données sont un actif important qu’il faut capturer, conserver et traiter de façon fiable et efficace. Là où un serveur central joue très souvent le rôle de gardien des données, la majorité des grands du web ont opté pour une autre stratégie : le « sharding » ou distribution des données [1].

Le sharding décrit ainsi un ensemble de techniques qui permet de répartir les données sur plusieurs machines pour assurer la scalabilité de l’architecture.

(Lire la suite…)

À ChooseYourBoss on développe une appli web tout ce qu’il y a de plus classique : HTML5, JS, CSS3 + quelques API (Linkedn, Viadeo, Google Maps, Google Analytics, etc). Côté serveur on est en Rails sur Heroku. Bref, rien d’exceptionnel quoi.

Puis un jour, on a jeté un œil sur le graphe de temps de chargement de notre appli – merci Google Analytics. Et là le drame : une moyenne de plus de 5 secondes pour la page d’accueil, et je ne vous parle pas sur mobile. On se dépêche alors d’aller faire un petit tour sur Google Pagespeed, notre score : 44/100 (bof bof).

On décide d’investiguer point par point nos hypothèses, en voici un résumé.
(Lire la suite…)

La mise en place d’un cache HTTP devant des serveurs web est un bon moyen d’en améliorer les performances. Ce billet a deux objectifs :

• Présenter les bases du caching HTTP
• Présenter les nouvelles fonctionnalités que j’ai implémentées dans le module Nginx Memcached pour faciliter le caching HTTP sur les serveurs

(Lire la suite…)

Dans son introduction au Complex Event Processing (CEP), Mathieu avait annoncé une série d’articles sur les solutions de CEP. Nous l’inaugurons avec cet article sur Esper.

Esper, édité par EsperTech, est une plateforme Java dédiée au CEP et au traitement de flux d’événements (ESP – event stream processing). C’est une collection de frameworks et d’outils servant à construire et intégrer des applications orientées événements.

Les 3 packages de la suite Esper couvrent la plupart du socle technique de telles applications. EsperTech s’y réfère en tant que 3 « éditions », mais ce sont en fait des groupes d’outils complémentaires.

La construction d’une application orientée événement avec Esper implique :

• le développement de la logique applicative au moyen d’instructions de traitement d’événements, instructions comprises par le coeur algorithmique de la suite, le moteur Esper Event Stream and Complex Event Processing (ou, en plus court, Esper Engine). Le moteur est distribué en open source sous licence GPLv2
• le packaging, l’intégration et le déploiement de l’application – Esper Enterprise Edition (EsperEE) peut assurer ce rôle
• si nécessaire, la sécurisation du traitement des événements avec EsperHA, qui ajoute des fonctions de persistance pour les scénarios de haute disponibilité et de reprise sur erreur

L’article complet, en anglais, offre un tour d’horizon de la plateforme CEP constituée par cet écosystème Esper. Le discours s’appuie sur la version 4.5.0 de la suite (à ce jour, la dernière version est la 4.6.0).

Les principes de l’Infrastructure agile

Au cours de la vie d’un logiciel, beaucoup de temps est consacré à son déploiement sur différentes plates-formes (recette, preprod, prod…). Bien souvent, nous réalisons des sous-projets de création d’environnements pour les logiciels nouvellement développés. Ce type de sous-projet est rarement capitalisé techniquement et peu contributeur à la valeur métier. Être capable de composer,  monter et démonter des environnements à la demande offrirait une flexibilité appréciable. Pour cela, il est efficace de standardiser les ressources d’infrastructure pour les utiliser comme des composants combinables. C’est ce que propose le cloud computing en offrant des capacités de production industrialisées sur Internet. (Lire la suite…)

Une démarche naïve de réalisation de tests de performance est d’effectuer des améliorations successives sur un système donné, donc d’avoir un processus pseudo-itératif. Donc, pourquoi ne pas se baser sur les processus développés dans les méthogologie Agiles, voir même d’utiliser les cycles d’améliorations continues issue du Lean.

En effet, on peut très facilement se rapprocher de la roue de Deming, appelée plus communément la démarche PDCA : Plan, Do, Check, Act.

Le but des tests de charge est de trouver les points faibles d’une architecture dans le but de l’améliorer : performance, stabilité sous charge, coût, etc. On rapproche donc les étapes du PDCA avec un processus de tests de charge :

• Le P (ou plan) a pour but d’établir, préparer et de planifier un plan d’action. Que doivent mesurer, améliorer nos tests pour cette itération.
• Le D (ou do) est la phase de faire, celle où on effectue les tests à proprement parler.
• Le C (ou check) est le moment où l’on vérifie les résultats renvoyés par nos tests. C’est aussi dans cette phase que l’on se préoccupe du rapprochement et de l’agrégation des métriques recueillies dans la phase précédente.
• Le A (ou act) sert à améliorer le système que l’on test. C’est la phase d’optimisation.

(Lire la suite…)

En septembre dernier, Amazon annonce la disponibilité de l’offre ElastiCache. Bien nommé, il propose un service de cache distribué ‘in-memory’. Quels sont les intérêts et limitations de cette offre ? C’est ce que nous verrons après l’avoir détaillée.

(Lire la suite…)

Au travers de multiples exemples, et dans la continuité des articles traitant de l’apprentissage automatique, nous allons explorer le domaine de l’apprentissage par renforcement. Ces méthodes inspirées du vivant permettent aujourd’hui de faire faire à des agents automatisés d’étonnantes tâches dans un cadre de programmation très générique.

Nous allons notamment voir et analyser :

1. un robot qui adapte sa façon de marcher en fonction de l’état du sol,
2. un groupe d’ascenseur qui cherche à satisfaire au mieux les utilisateurs,
3. un robot qui apprend à maintenir un bâton en équilibre instable, un autre qui retourne les pancakes
4. un exemple d’application d’apprentissage par renforcement pour les SI

Ces exemples spectaculaires d’applications de l’apprentissage par renforcement me poussent à croire qu’il est parfois possible de piloter un système complexe par des règles simples. En utilisant un modèle suffisamment riche et des algorithmes implémentant ces méthodes de renforcement, nous pouvons fabriquer des agents adaptatifs qui masquent la complexité de leur environnement …

(Lire la suite…)