Mon premier site, je l’ai fait en 2003 avec Microsoft Frontpage. Ca a été une découverte très progressive, en cliquant partout, en expérimentant, en essayant chacune des fonctionnalités… Peu de temps après, j’ai acheté mon premier livre d’informatique, pour apprendre à faire des sites dynamiques… Le bouquin s’appelait « PHP et MySQL ». Je l’ai lu religieusement, de A à Z, en mettant en pratique chacun des exercices du livre, puis j’ai patiemment mis en œuvre les principes appris dans le livre, avec un simple éditeur de texte et un compte gratuit chez Free, en créant un système de blog de zéro.
De plus en plus présents sur les réseaux sociaux, après Facebook nous envahissons Twitter et LinkedIn.
Notre compte Twitter relaiera essentiellement nos articles mais nous serons davantage présents sur LinkedIn où nous publierons aussi notre actualité professionnelle et les propositions d’emplois et de stages. Quant à Facebook, il reste notre mode de diffusion privilégié si vous voulez savoir ce qui se passe dans nos murs.
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.
Aujourd’hui, je vous propose un rapide compte rendu sur Agora CMS, « le » rassemblement des acteurs de la scène CMS française qui s’est déroulé le 1er avril dernier à Paris.
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.
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.
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→
En navigant sur le net, il vous est sans doute arrivé de tomber nez à nez avec un lien qui ne pointe plus vers son contenu. Une page d’erreur 404 ou bien même aucune page d’erreur du tout, comme si le site entier s’était lui-même volatilisé. On dit souvent entre nous, « tiens, ce lien est « mort »… ». Un lien à jour est vivant, un lien obsolète est mort. Et si c’était la même chose pour les logiciels ?
Lorsqu’un projet de développement débute, c’est en général l’effervescence ; les chefs de projets sont tout excités à l’idée de découvrir le métier du client et répondre à son besoin, les développeurs-euses sont excité-es à l’idée de « créer » un nouveau logiciel avec de nouvelles technos toutes neuves et ainsi expérimenter de nouveaux paradigmes et architectures (chacun son truc, comme on dit..). La joie de l’ouverture des cadeaux de Nowël, en somme. Le logiciel est alors en phase de gestation.
A la première livraison, c’est l’accouchement. Vous êtes fiers de votre nouveau bébé. Vous y avez mis tout votre cœur, avec du code tout beau tout propre. Vous le mettez au bain à coup de refactoring tous les jours. Les commentaires ont du sens, les nouvelles technos sont « super-sympas », même si vous avez pu à cette occasion y découvrir des inconvénients majeurs. C’est pas grave, on fait avec. Et le clou du spectacle, il y a même des tests unitaires qui garantissent la non régression des fonctionnalités de base.
Puis le projet grandit. Votre bébé est devenu grand. Au départ, vous ne saviez pas trop ce qu’il allait devenir. D’autres développeurs ont rejoint l’équipe et lui ont appris à faire de nouvelles choses. A bien y regarder, il a aussi pris de l’embonpoint. Il ne fait pas encore le café, mais il n’en est pas loin. Les technos (plus toutes jeunes) utilisées sont agréables, mais leurs inconvénients vous font de plus en plus râler. Ce n’est pas grave, il fonctionne toujours bien, il est en production, et les mises à jours et les évolutions sont nombreuses.
crédit image : wikipedia
Puis les années passent. Le bébé a disparu pour laisser la place à une cathédrale. Non pas que l’architecture était mauvaise, non. Pris dans son contexte, celui des débuts, tout fait sens, mais les besoins ont évolué. Les règles métier se sont étoffées, les usages également. Les utilisateurs, toujours plus nombreux, toujours plus exigeants, ont fait évoluer le logiciel, ce qui n’est pas un mal, car cela prouve que le projet est bel et bien vivant.
Mais les technos utilisées vous semblent bien loin de ce que l’on fait de nos jours ; très très loin. A bien y réfléchir, avec ce qui existe maintenant, nous pourrions imaginer faire mieux. Beaucoup mieux. Beaucoup plus efficace. A la fois pour les développeurs, mais aussi pour les utilisateurs, qui ressentent bien un décalage entre ce monument, et le monde tel qu’il est aujourd’hui. Et puis il y a toutes ces petites briques faites main, toutes ces petites gargouilles magnifiques qui ornent l’ouvrage, et sur lesquelles vous avez passé tant d’heures avec vos collègues pour le rendre plus beau, plus riche, plus attrayant. Oui. L’air de rien, 15 ans se sont écoulés entre les débuts du projet et ce stade, une éternité dans le domaine de l’informatique. Et vous vous demandez bien comment le faire évoluer pour qu’il ne devienne pas un de ces monuments que l’on admire, mais sans jamais ou rarement y rentrer… comment le garder en vie ? … sans le détruire complètement et construire un gratte ciel à la place ?
Bien sûr, un projet logiciel n’est pas un organisme vivant. Il ne ‘vit’ que par l’activité que lui donnent ses participants, ses utilisateurs, et surtout ses développeurs. A mon sens, il y a deux morts pour un logiciel. La première (pas forcément la 1ère dans le temps), c’est l’équipe de développeurs qui la lui donne. Plus de mises à jour majeures. Plus d’évolution. Parfois, même, plus de maintenance. L’éditeur peut faire ce choix délibérément (cf. Windows XP), ou pas (cf. Open Office suite au rachat du projet par Sun). L’autre mort, bien plus définitive, est celle qui est donnée par les utilisateurs. Parfois un logiciel est même mort-né, car ce dernier n’est pas encore livré qu’il est délaissé par les gens censés s’en servir (Windows Millenium, si tu nous entends..).
Les solutions à un tel problème sont loin d’être évidentes, mais il existe plusieurs pistes :
dans le cadre d’une licence propriétaire, cadrer dès le départ du projet les conditions de « fin de cycle » et anticiper un renouvellement des développements à long terme. Ce dernier peut prendre plusieurs formes, comme par exemple une réécriture par partie, si tant est que ce soit techniquement possible de séparer des morceaux de l’ouvrage pour le faire évoluer au moins partiellement. Il s’agit dans ces cas là d’un investissement sur le long terme, mais comme chacun sait, personne n’est prophète en son pays …
dans le cadre d’une licence libre, c’est un peu plus ouvert (par définition ;)) ), sans toutefois apporter de solution évidente au problème. La continuité de l’activité au sein du projet peut émaner d’autres sources comme des bénévoles, d’autres entités professionnelles, qui peuvent repartir de la base existante pour faire ressusciter le logiciel. Le cas d’Open Office est très intéressant ; le rachat du projet par Sun a provoqué le départ d’une grande partie des contributeurs d’Open Office qui n’ont pas voulu continuer de faire vivre le projet « dans de telles conditions ». Ce dernier a donc été « fourché » (fork) pour renaître sous la forme de LibreOffice. OpenOffice est donc mort dans la bataille, mais LibreOffice a continué d’avancer et d’évoluer.
Bref, n’est pas immortel qui veut. Dans tous les cas, un gros projet, qu’il soit logiciel ou pas, amène avec lui son histoire. Bien qu’il soit toujours tentant de la réécrire et d’y porter un jugement facile, il convient toujours de ne pas l’oublier et d’en tirer les leçons, et ainsi éviter que certaines erreurs du passé ne se répètent…
Nous vous souhaitons à toutes et à tous de passer d’excellentes fêtes de fin d’année 2015 et de revenir en forme pour attaquer la nouvelle année avec nous.
Le site de TimSoft datait de 2011, refondu à l’occasion du déménagement de Levallois à Paris…
Malgré son design relativement épuré, agrémenté de quelques animations vidéo légères et de bon aloi, sa fréquentation a baissé de manière très significative depuis quelques mois, bien que toujours très bien référencé dans les moteurs de recherche : cherchez « développement logiciel Paris » ou quelques termes approchants et vous obtiendrez en effet une honorable 1ere page.
Alors, pourquoi un nouveau design de site? Tout simplement parce que le nombre de contacts entrants qualifiés a fortement chuté, le nombre de pages consultées après la 1ere page s avérant de plus en plus limité. Autre signe : le nombre de candidatures aux postes en recrutement ou de stages tangente vers zéro!
Bref, malgré son excellent niveau de référencement, le site devenait de fait peu attractif/lisible/désirable ! Alors que nos compétences sur la mobilité notamment s’agrémentaient de références sérieuses, tangibles et éprouvées, notre site dénotait un « responsive design » très limité! Une visibilité dispersée au travers de menus multiples, et une map finalement confuse!
Une lisibilité accrue / défilement au doigt et à l’œil,
Moins de textes,
Un design un peu décalé, un peu vintage, un brin de second degré.
Bien évidemment nous allons suivre avec attention son niveau de référencement et les contacts entrants.
Côté techno, pas de cms (la ligne éditoriale évoluant pour nos activités finalement assez peu) mais un choix d’html à plat pour des raisons de réactivité. Les choix retenus feront l’objet d’un article plus fourni.
En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. plus d'informations...
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
