Archives de catégorie : Technique

Article destiné aux technophiles

Technique

Packager son application AngularJS avec NPM & Browserify

Laisser un commentaire

 

Introduction

Aujourd’hui, pour développer une application web, il est difficile d’échapper à l’utilisation de frameworks MV* ou MVW (Model View Wathever) tels que AngularJS, Ember ou Backbone. En effet, ces derniers permettent une abstraction de la manipulation directe du DOM et apportent une meilleure organisation du code.

De plus, les nouveaux standards HTML5 (application cache, indexedDb etc.) nous offrent la possibilité de développer des applications web accessibles sans connexion internet. Cela nous amène à déplacer la logique métier de nos applications côté client.

Le code source côté client va ainsi être composé de nombreux fichiers (JS, CSS, HTML). Afin de nous éviter l’inclusion manuelle des références à ces fichiers dans notre « index.html », nous allons devoir packager (« rassembler ») ces derniers en un ou plusieurs fichiers. Pour cela nous allons passer par une phase de « pseudo-compilation » de nos sources.

Cependant, nous pouvons tirer partie de cette phase supplémentaire pour traduire notre code d’un langage à un autre. Cela nous permettra ainsi d’utiliser des langages ou de nouveaux standards pas forcément interprétables par le navigateur tels LESS et ES2015 par exemple.

Voyons donc aujourd’hui cette phase de « pseudo-compilation » permettant de « packager » une application AngularJS 1.5.x écrite en ES2015.

Continuer la lecture de Packager son application AngularJS avec NPM & Browserify →

Technique

Python, c’est bon

2 commentaires

Il y a quelques jours, au hasard d’un projet pro, j’ai eu l’occasion de revenir à mes premières amours, Python, et d’implémenter une petite librairie dans ce langage. J’avais oublié à quel point j’`adore` Python. C’est à la fois simple comme un jardin Zen et touffu comme la moustache de Nietzsche. Je vous propose un petit tour d’horizon de ce qui m’enchante dans le langage.

Continuer la lecture de Python, c’est bon →

Technique

Choisir sa tech stack

2 commentaires

Quand je démarre un nouveau projet, que ce soit à partir de zéro ou en reprenant une base existante, je me pose systématiquement la question de la technology stack à utiliser, c’est à dire l’ensemble des composants logiciels (et éventuellement matériels) à mettre en oeuvre. Ce sont les outils à disposition de l’ingénieur pour résoudre un ensemble de problèmes donnés.

C’est un choix important, qui doit être réfléchi, sans quoi le risque est de subir une stack inadaptée, que ça soit à cause de l’habitude (“on a toujours fait comme ça”) ou à cause de l’existant (“il y avait déjà deux briques logicielles écrites en Jython#.js”), avec les difficultés de développement, les limitations et les surcoûts qui vont avec.

Ce choix est d’autant plus important que les outils disponibles sont de plus en plus nombreux, et changent de plus en plus rapidement. Grâce à une simple connexion internet, je peux obtenir tous les éléments nécessaires pour faire tourner mon projet, et je peux également me former en ligne grâce à de la documentation, des guides de démarrage rapide, des projets open source dont je peux m’inspirer, ou des sites collaboratifs comme StackOverflow grâce auxquels des utilisateurs de tous les horizons pourront répondre à la moindre de mes questions techniques.

Continuer la lecture de Choisir sa tech stack →

Technique

MiddleMan, ou le retour des sites statiques

Laisser un commentaire

Le Net évolue très vite (nous sommes bien placés pour le savoir) et forcément notre site n’a pas pas échappé au vieillissement. Qu’à cela ne tienne, voici une belle occasion de le mettre au goût du jour en simplifiant son ergonomie et son accès : il est temps de revenir au Web 1.0 !

Fonctionnellement parlant et comme la plupart des vitrines, notre site n’est pas très riche. Il présente simplement notre travail et vous permet de nous contacter. Exit donc l’idée d’utiliser un CMS glouton : nous voulons quelque chose de nerveux et de robuste. « Un site statique, quoi ? » plaisantera quelqu’un. Exactement, c’est bien ce que nous allons choisir. Continuer la lecture de MiddleMan, ou le retour des sites statiques →

Technique

Introduction à une architecture orientée services

Laisser un commentaire

Capitaliser sur du code ; ça c’était avant

On ne le dira jamais assez : chaque projet informatique est unique. Il subsiste cependant des points communs d’un projet à l’autre. Des points que nous pouvons identifier pour anticiper les problématiques, et ainsi monter une solution qui bénéficie, de proche en proche, des expériences passées. On essaie donc de « capitaliser », comme les vils financiers, pour ne pas avoir à réinventer la roue.

Parmi les façons classiques de capitaliser, dans le monde du logiciel, il y a :
  • la reprise de composants logiciels existants. Soit par la reprise de binaires, soit par l’inclusion du code source existant au sein du projet. Il peut s’agir de l’utilisation de librairies existantes et éprouvées libres,… ou pas (jquery, winnovative pour la génération de rapports office, etc.)
  • la façon, la méthode d’assemblage de ces différents composants. Typiquement, sur une application web, nous allons identifier un front-end et un backend. On sait que l’on va devoir organiser le code   de façon à bien séparer les deux parties, on peut alors construire des « templates » de projet, afin de préparer en amont la future organisation du code. Aujourd’hui, de nombreux outils proposent de préconstruire  cette organisation (django en python, ou rails en ruby, par exemple).

Au final, le schéma d’une architecture d’application web se retrouve souvent sous la forme :
  • client JS + HTML
  • serveur web avec du code serveur type C#, Java, Python, Ruby, WhatElse,…
  • base de données PostRacle MySQLServer, EtTantD’autres…
Ensuite, il y a plein de façon de séparer les couches logiques : mais ça de nos jours, tout bon dev connaît ça par coeur   :  l’authentification (basic http, authentification par session/cookie, oauth, open id, etc.) , la méthode d’accès à la base, (direct ou orm) la génération de rapport, (office, csv, etc.). Tout ce joyeux monde est inclus comme un tout à l’éxecutable sous la forme de librairies internes. La partie runtime ne fait donc pas vraiment l’objet de séparation particulière, si ce n’est une organisation dans la façon de concevoir ces packages / namespaces, ou autre.

Bon, bien, bien. Et puis un jour, on se prend ça dans les dents.

Continuer la lecture de Introduction à une architecture orientée services →