Ekoz Technology
Un des travers que j’ai le plus souvent remarqué tout au long de ma carrière dans différentes organisations de développement, est le manque de vision à long terme des développeurs, et parfois même, des architectes logiciels eux-mêmes. Ce manque de vision se traduit par un phénomène courant: un programme ou un bout de code conçu à une date donnée se comporte de manière désastreuse deux ou trois ans plus tard. La faute à qui? La faute aux utilisateurs, bien sûr! Et bien souvent, cependant, à l’explosion combinatoire que le développeur n’a pas su anticiper.
Hervé Kabla, ancien patron d’agence de comm’, consultant très digital et cofondateur de la série des livres expliqués à mon boss.
Crédits photo : Yann Gourvennec
Bonjour Herve,
Ce projet semble extrêmement intéressant et prometteur. Ces derniers temps je me suis heurter à plusieurs reprises sur le problème que tu décris avec des DB relationnelles. Cependant pour l’instant j’ai toujours réussi à atteindre des temps de réponses acceptables en optimisant les index ou la structure de table ou de la requête.
Quel type de licence et de business model pour « EKOZ »?
Bravo pour la qualité et la diversité de tes billets.
Yann
J’ai fait quelques interviews d’embauche ces derniers temps et s’il y a une boite qui a une obsession de la complexité des algorithmes, c’est bien Google.
Je me suis aperçu que le souci de la performance des algorithmes et structures de données est le propre : 1) des vieux informaticiens comme moi (44) et 2) des jeunes des pays de l’Est, d’Asie et du Tiers-Monde, il y en a plein à Google Zürich (qui recrute entre autres via http://www.topcoder.com) . La raison ? on avait de vieille moulinettes ou chaque octet et chaque instruction comptait. Ca forme des ingénieurs « CS » pour Computer Science, dont chaque ligne de code est en or massif, au figuré et au propre.
Les utilisateurs des bases de données actuelles sont des spécialistes de l’ « IT » comme ils disent : ils te pondent un datawarehouse multisite en UML en suivant les business process élaborés par des consultants SAP ou Oracle. Performance ? Scalabilité ? aucune idée, mais yaka faire des benchmarks, ou, plus simple encore, acheter la même chose que le voisin.
Mes 2 cents : il y a 20 ans mon prof de bases de données annonçait la mort du modèle relationnel et de SQL. Il s’est planté : c’est un standard incontournable. Si ce n’est pas déjà fait, rendez EKOZ compatible avec ce langage archaïque idolâtré par les « IT ».
Et faites vous voir chez Google.
Et dites moi si je peux vous aider 😉
C’est typiquement le domaine qui m’attire d’un point de vue personnel !
Totalement d’accord avec l’analyse: les russes font partie des meilleurs parce qu’on ne leur a pas livré de Mo gratuits. La moyenne d’age chez Ekoz est d’ailleurs superieure a 40 ans.
Ekoz est totalement compatible avec la syntaxe SQL. D’ailleurs les benchs realises le sont sur les memes requetes sur les deux systemes.
Une introduction chez Google: oui, ca peut m’intéresser.
Qu’entends tu par temps de reponse acceptable? Et sur quelle cardinalité? Au prix de combiens d’efforts de tuning? Et avec quelle assurance qu’un jour ton systeme ne sera pas plombé par une requete fatale?
Passe me voir, on oeut en discuter.
Dans les 2 cas que j’ai en tête une performance accépetable est inférieure à une minute. Il s’agissait d’une requête de type « JOIN » entre plusieurs tables contenant plusieurs millions d’enregistrements. L’effort de tunning est de 2 types : temps — plusieurs jour de test/optimisation, dégâts collatéraux — modification du format du résultat pour répondre au plus juste du besoin et abandon de l’ORM pour utiliser du SQL.
Pour ce qui est de la dernière question : aucune.