Qui nous sommes

Une équipe de R&D qui produit des applications métiers. Ces applications sont généralement destinées à un publique professionnel mais non technique. Ces applications sont des applications web pour faciliter un accès universel.

Nous sommes des Pythonistes convaincus. Nous utilisons et produisons du logiciel libre. Nous utilisons le plus possible des standards et formats interopérables.

Nos besoins

Scalabilité

Un projet comme Postaleo nécessite de traiter :

  • de gros volumes de données (documents lourds, nombre de courriers importants)
  • de fortes charges ponctuelles (envois de masse)

D'autres projets gèrent de forte volumétrie de documents.

Maîtrise des composants

La particularité des applications métier est en général un besoin de forte personnalisation. Avec des solutions trop génériques ou spécialisées, on se retrouve à dé-construire le logiciel. La déconstruction est souvent bien plus coûteuse que la construction du code adéquat.

La maîtrise des composants permet également de faire des choix pertinents en fonctions de contraintes légales ou de performances, etc… Parfois, trouver une solutions technique implique de trouver un compromis en s'appuyant sur des spécificités du modèle.

Choisir également la technologie la mieux adapté à une tâche : base SQL, No-SQL, indexation solr, utilisation direct du filesystem, etc…

Il y a un outil adapté à chaque problème, il ne s'agit pas d'adapter le problème au logiciel mais bien le contraire.

Maîtrise des dépendances

Nous cherchons à ne payer que pour ce que l'application consomme.

La maîtrise des dépendances, le fait de conserver une pile logicielle de la taille nécessaire.

éviter de tirer une batterie d'outils non impliqués dans notre besoin. On évite ainsi des parasitages : noyer le développeur, enregistrer des composants qui vont rendre la personnalisation du code plus complexe, ainsi que la découverte d'anomalies plus laborieuse.

WSGI

WSGI est un standard du monde Python. Il permet notamment une agrégation d'intergiciels.

ZTK offre un compatibilité WSGI mais n'est pas vraiment construit sur ce standard et ne peut se situer qu'en bout de scène. Il n'y a notamment pas d'extensibilité sur la méthode de publication des objets. De même des projets comme Django ont leur propre concepts et API de middleware.

Nous voulons pouvoir utiliser tous les serveurs wsgi, bénéficier des composants développés dans la communauté Python et contribuer nos composants. Comme le font Turbogears et Pyramid.

Le code est la glue

En tant que développeur il nous semble que l'expressivité d'un langage comme python ne sera jamais égalée par un langage de configuration.

C'est le programme qui assemble les différents éléments, qui réalise l'intégration des composants provenant des différents paquets.

Des design patterns simples, basés sur les outils qu'offre Python : context manager. des itérateurs, la gestion des namespaces.

Tout en essayant de fournir des configurations par défaut utiles, elles ne sont parfois fournit qu'à titre d'exemple. Il ne sert à rien de réutiliser des méthodes de quelques lignes.

Une boite à outil pas un cadriciel

Notre besoin de maîtrise des composants porte à réaliser une boite à outil plus qu'un cadriciel.

Un cadriciel va proposer un cadre de démarrage et une série de fonctionnalités pré-disponible ce qui veut dire qu'une série de choix est déjà fait (le fameux cadre). On peut sortir du cadre mais au prix d'une déconstruction coùteuse (cf. maitrise des composants).

Nous sommes un équipe de "spécialistes"