Python, c’est bon

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

Choisir sa tech stack

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

MiddleMan, ou le retour des sites statiques

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

Le développement logiciel, un art atemporel ?

 

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.

ND_Amiens_gargouilles_17
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…

TimSoft vous souhaite de joyeuses fêtes de fin d’année !

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.

Tous nos vœux et à très vite, l’équipe TimSoft.

Télécharger la carte de voeux.
Télécharger la carte de voeux pour les fêtes.
Télécharger la carte de vœux pour la nouvelle année.
Télécharger la carte de vœux pour la nouvelle année.

Mais pourquoi un nouveau site TimSoft?

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!

Les principes retenus pour le nouveau site :

  • Responsive design quelque soit le support,
  • 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.

Pour les nostalgiques de l’ancien site : http://www.timsoft.fr/ ou http://www.timsoft.eu/.

Introduction à une architecture orientée services

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

Bienvenue sur le tout nouveau blog TimSoft

Enfin : TimSoft met en ligne son Blog !

Soyez les bienvenus sur ce qui va devenir notre plateforme publique d’expression et de partage.

Qui sommes nous ?

Depuis près de 20 ans, TimSoft conçoit, réalise et met en œuvre des logiciels spécifiques,  intégrant très souvent  tout ou partie du cœur de  métier de ses Clients.

L’expertise de TimSoft en architecture logicielle, en outils de développement, en infrastructure d’hébergement et en conduite de projets,  permet d’adresser des problématiques fonctionnelles très variées.

La R&D de TimSoft contribue pleinement à l’élaboration de solutions pérennes, à la maîtrise des délais et en définitive à l’optimisation des budgets.

Plus que jamais, le savoir-faire de TimSoft permet de répondre à la nécessaire transformation digitale des entreprises.

Pour en savoir plus : www.timsoft.com.

Cela étant dit, nous embauchons, alors n’hésitez pas à nous contacter, de même si un projet vous trotte dans la tête.

Où sommes nous ?SquareDOrleans

Après avoir connu Asnières, Gennevilliers et Levallois-Perret, nous avons eu l’opportunité d’emménager au milieu de l’histoire de Paris, au 80 rue Taitbout dans le 9ième arrondissement.

Non loin de la gare St Lazare, le Square d’Orléans où nous avons pris nos quartiers a également accueilli des noms prestigieux tels que George Sand, Frédéric Chopin ou Alexandre Dumas Père.

C’est surtout un environnement de travail serein et propice à nos activités de développement logiciel.

Quel contenu pour ce blog ?

TimSoft s’est depuis longtemps doté d’un espace d’échanges et de partage, réservé à la communication interne. Nous avons pensé que certains sujets abordés pouvaient être utiles à d’autres, d’où la décision de les publier sur ce blog.

Les contributions seront à dominante technique, mais pourront avoir trait à la gestion de projet, à l’évolution des DSI et de leurs enjeux, à l’ingénierie informatique au sens large.

Vous nous suivez?

Si vous avez des questions et remarques, n’hésitez pas à nous contacter via le formulaire. Si vous souhaitez nous suivre dans nos échanges , vous pouvez vous abonner à notre page Facebook  ou plus simplement, inscrivez vous à la newsletter dont vous trouverez le formulaire ci-contre. Bien entendu, nous garderons vos coordonnées pour nous.

 

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.

Close