CV/Mission de Développeur oracle service bus freelance

Exemple de missions de Sylvain,
Développeur oracle service bus habitant la Seine-Saint-Denis (93)

• Développeur

  Thales SIX
  Jan 2019 - Jan 2020

  Langages : C, C++, Perl, Bash
  Travail réalisé : Maintenance en conditions opérationnelles d’un des logiciels de paramétrage des modems satellites.
  
  Ajout de correctifs, et tests :
  Modification de la base de code (ancienne, et volumineuse – millions de lignes de code, en comptant le « socle » applicatif, partagé avec d’autres produits) pour corriger des bugs, ou répondre à des demandes client. Tests unitaires, et tests fonctionnels sur plateforme dédiée reflétant la configuration du client.
  Relation client, en anglais, tant pour obtenir les besoins (ou des détails sur les besoins exprimés), ou pour obtenir des détails sur les problèmes rencontrés. Réalisation de protocoles de tests à faire exécuter par le client quand les données (sensibles, car militaires) ne peuvent être envoyées pour permettre une réplication du problème sur nos systèmes.

• KERTIOS
  Jan 2018 - Jan 2019

  Développement applications Web en interne
  
  Langages : HTML, PHP, Javascript, SQL (MySql)
  Travail réalisé : Développement d’applications internet, tant à usage interne que pour des clients de la société KERTIOS.
  
  Conception et développement d’applications :
  Choix de l’architecture technique, et du modèle de données
  Création de la structure en base de données, ajout des contraintes, index, etc.
  Développement du code applicatif côté serveur (PHP) et client (Javascript, y compris AJAX), écriture des requêtes SQL
  Tests des fonctionnalités

• Développeur

  Evistel
  Jan 2016 - Jan 2018

  Langages : C, C++, Perl, Bash, SQL (sous Postgres), makefile
  Travail réalisé : Le but était de reprendre le développement d'une plate-forme logicielle complexe (Open Software Platform), afin d'y ajouter de nouvelles fonctionnalités. Cette plate-forme inclut de nombreux logiciels couplés plus ou moins fortement entre eux, et comprend un interpréteur pour un langage propriétaire développé en interne par Evistel.
  
  Etude et documentation de l’existant :
  Le code principal de la plate-forme avait été écrit rapidement, et sans tenir compte des bonnes pratiques usuelles (code copié-collé en de nombreux endroits, code mort laissé en place, absence de documentation des fonctions, certains cas limite non pris en compte, etc.) J’ai documenté au fur et à mesure que je déchiffrais les fonctions.
  Les sources n’avaient pas été versionnées proprement. Ou, plutôt, la dernière version n’avait pas été archivée correctement dans les dépôts CVS du projet, et il n’y avait pas de procédure d’installation clairement définie pour le projet. J’ai écrit un script pour automatiser la récupération des sources et des dépendences (bibliothèques et autres projets propriétaires utilisés par la plateforme), créer l’arborescence, les liens symboliques, etc. Désormais, le projet s’installe en une seule commande.
  
  Modification de l’existant, modularisation :
  La plateforme OSP est principalement un interpréteur pour le langage propriétaire OSPL, sur lequel sont greffés des « modules » spécifiques à tel ou tel protocole (envoi de SMS, facturation de tel ou tel service, etc). Ces modules étaient fortement couplés avec le système, dans l’ancienne version (compilés en dur, mentionnés dans les sources du programme principal, etc), et n’étaient donc pas réellement modulaires. Une grosse partie de mon travail a consisté en une modification de l’architecture du logiciel, pour permettre de charger les modules dynamiquement (plusieurs dizaines de milliers de lignes de code à modifier).
  
  Ajout d’un module SQL :
  Pour ajouter à la plateforme OSP la possibilité d’accéder à des bases de données SQL via le langage OSPL, j’ai réalisé un module fournissant une abstraction de haut niveau, générique, vers une base de données SQL. Seule l’implémentation de ce module pour Postgres a été réalisée, mais l’architecture choisie permettra d’ajouter facilement le support de MySql, Oracle, SQL Server, ou toute autre base de données SQL, si le besoin s’en fait sentir dans le futur.

• Développeur

  Ingenico
  Jan 2016 - Jan 2016

  Langages : C, Perl, Bash, PL SQL (sous Postgres)
  Travail réalisé : Le but était d’analyser des codes de réplication de transactions, écrits en C, et de fournir un code équivalent, sous forme de modules Perl, compatibles avec un “moteur” écrit en Perl. En effet, les codes écrits en C n’avaient pas été pensés pour les volumétries actuellement rencontrées, et, au final, étaient bien moins performants que les modules Perl écrits en remplacement.
  
  Etude et documentation de l’existant :
  Un “moteur” en Perl, et des plugins pour certaines applications (Carte Bleue, American Express, etc. - les plus forts volumes, en transactions/jours) étaient déjà écrits, mais aucune documentation n’était fournie. J’ai donc dû analyser le code, et documenter les fonctions, ainsi que déterminer les entrées-sorties attendues pour les plugins.
  Le code C n’était pas non plus documenté, il a donc fallu comprendre de quelle manière il agissait, surtout que chaque développeur avait son propre style, ses propres “standards” de livraison, etc (méthodes d’installation très différentes, au cas par cas, et ne marchant généralement pas du premier coup)
  
  Réalisation des plugins :
  Ecriture des plugins, en optimisant autant que possible, pour ne pas ralentir tout le processus.
  Amélioration du moteur, que ce soit par ajout de fonctionnalités, ou en factorisant le code, créant des bibliothèques, etc.
  
  Assurance Qualité :
  Ecriture d’outils de tests: Comme nous n’avions pas de jeu de test extensif (les tests sont normalement réalisés par une équipe dédiée, chez Ingenico), écriture d’outils prenant les flux de production, et en faisant une copie vers l’environnement testé, afin de comparer les résultats de la réplication “en production” (version en C) et de la réplication en Perl (que nous testions).
  
  Magillem 3 mois 02/2017 -> 04/2017
  Développeur
  
  Langages : Perl, Java, Shell Windows (CMD), Apache Ant, Lexer “JFlex”
  Travail réalisé : Le but premier était l’adaptation d’un script Perl, qui convertissait des spécifications électroniques, écrites selon un format spécifique à ST Microelectronics (dans des fichiers Word, Excel, ou Adobe FrameMaker (MIF)), vers le format XML « IP-XACT », qui est un standard industriel ; afin de réaliser les mêmes tâches en Java.
  
  Au final, l’essentiel du travail a tourné autour de la réalisation d’une API permettant de lire et écrire le format MIF (Maker Interchange Format), utilisé par Adobe FrameMaker, afin de pouvoir inclure ce format dans le modèle Java préexistant, et le rendre interopérable avec les autres formats gérés par l’application Magillem.
  
  Analyse des besoins, et des spécifications :
  Recherche de documentation sur le format MIF, réalisation de tests et de « retro-engineering » quand cela était nécessaire (par exemple, parce que la documentation officielle ne permettait pas de savoir réellement ce que faisait le logiciel dans tel ou tel cas).
  Analyse des scripts Perl existants, pour voir de quelle manière certaines informations étaient gérées.
  
  Conception d’API :
  Mise en place d’une structure arborescente, proche du DOM, pour représenter les fichiers MIF.
  Extension de ces classes et interfaces, pour coller au plus près des balises du format MIF, avec une philosophie « extensible » : Ce qui n’est pas encore implémenté apparaît de manière générique, mais l’ajout de classes permettant de le reconnaître, plus tard, ne casse pas l’existant, il facilite simplement l’ajout de nouvelles fonctionnalités.
  Utilisation intensive des concepts objets avancés (interfaces, héritage, généricité) pour réduire la quantité de code nécessaire, augmenter la robustesse, et la réutilisabilité du code produit.
  Optimisation du code (ajout de systèmes de gestion de cache complexes, pour réduire les coûts des nombreux parcours d’arbre successifs)
  
  Assurance Qualité :
  Ecriture de tests unitaires et fonctionnels.
  Mesure de performances (vitesses de traitement, selon divers algorithmes).
  Rédaction de documentation :
  Documentation complète de l’API générée, y compris exemples de code.
  
  Automatisation de la livraison
  Génération de livrables via l’écriture de fichiers ANT.
  Ecriture de scripts BATCH (.BAT) pour le shell Windows.
  
  » Ingenico Durée : 3 mois
  Langages : C, Perl, Bash, PL SQL (sous Postgres)
  La société Ingenico est une grande entreprise Française (6000 employés), à rayonnement mondial (présence dans 170 pays). Elle développe des terminaux de paiement (matériel ET logiciel), et entretient une importante infrastructure informatique, en interne, pour servir d’intermédiaire entre les clients et les différents réseaux bancaires ou assimilés. Sa part de marché mondiale, pour les terminaux de paiement, était estimée à 45% en 2014.
  Travail réalisé : Le but était d’analyser des codes de réplication de transactions, écrits en C, et de fournir un code équivalent, sous forme de modules Perl, compatibles avec un “moteur” écrit en Perl. En effet, les codes écrits en C n’avaient pas été pensés pour les volumétries actuellement rencontrées, et, au final, étaient bien moins performants que les modules Perl écrits en remplacement.
  
  Etude et documentation de l’existant :
  ● Un “moteur” en Perl, et des plugins pour certaines applications (Carte Bleue, American Express, etc. - les plus forts volumes, en transactions/jours) étaient déjà écrits, mais aucune documentation n’était fournie. J’ai donc dû analyser le code, et documenter les fonctions, ainsi que déterminer les entrées-sorties attendues pour les plugins.
  ● Le code C n’était pas non plus documenté, il a donc fallu comprendre de quelle manière il agissait, surtout que chaque développeur avait son propre style, ses propres “standards” de livraison, etc (méthodes d’installation très différentes, au cas par cas, et ne marchant généralement pas du premier coup)
  Réalisation des plugins :
  ● Ecriture des plugins, en optimisant autant que possible, pour ne pas ralentir tout le processus.
  ● Amélioration du moteur, que ce soit par ajout de fonctionnalités, ou en factorisant le code, créant des bibliothèques, etc.
  Assurance Qualité :
  ● Ecriture d’outils de tests: Comme nous n’avions pas de jeu de test extensif (les tests sont normalement réalisés par une équipe dédiée, chez Ingenico), écriture d’outils prenant les flux de production, et en faisant une copie vers l’environnement testé, afin de comparer les résultats de la réplication “en production” (version en C) et de la réplication en Perl (que nous testions).

• Magillem
  aujourd'hui

  Langages : Perl, Java, Shell Windows (CMD), Apache Ant, Lexer “JFlex”
  La société Magillem est une PME (environ 50 salariés) qui édite une solution de gestion documentaire, ciblant principalement l’industrie électronique, et le monde juridique. Elle compte dans ses clients de très grands comptes, comme Intel, ou ST Microelectronics, par exemple.
  Travail réalisé : Le but premier était l’adaptation d’un script Perl, qui convertissait des spécifications électroniques, écrites selon un format spécifique à ST Microelectronics (dans des fichiers Word, Excel, ou Adobe FrameMaker (MIF)), vers le format XML « IP-XACT », qui est un standard industriel ; afin de réaliser les mêmes tâches en Java.
  Au final, l’essentiel du travail a tourné autour de la réalisation d’une API permettant de lire et écrire le format MIF (Maker Interchange Format), utilisé par Adobe FrameMaker, afin de pouvoir inclure ce format dans le modèle Java préexistant, et le rendre interopérable avec les autres formats gérés par l’application Magillem.
  • Analyse des besoins, et des spécifications :
  • Recherche de documentation sur le format MIF, réalisation de tests et de « retro-engineering » quand cela était nécessaire (par exemple, parce que la documentation officielle ne permettait pas de savoir réellement ce que faisait le logiciel dans tel ou tel cas).
  • Analyse des scripts Perl existants, pour voir de quelle manière certaines informations étaient gérées.
  • Conception d’API :
  • Mise en place d’une structure arborescente, proche du DOM, pour représenter les fichiers MIF.
  • Extension de ces classes et interfaces, pour coller au plus près des balises du format MIF, avec une philosophie « extensible » : Ce qui n’est pas encore implémenté apparaît de manière générique, mais l’ajout de classes permettant de le reconnaître, plus tard, ne casse pas l’existant, il facilite simplement l’ajout de nouvelles fonctionnalités.
  • Utilisation intensive des concepts objets avancés (interfaces, héritage, généricité) pour réduire la quantité de code nécessaire, augmenter la robustesse, et la réutilisabilité du code produit.
  • Optimisation du code (ajout de systèmes de gestion de cache complexes, pour réduire les coûts des nombreux parcours d’arbre successifs)
  • Assurance Qualité :
  • Écriture de tests unitaires et fonctionnels.
  • Mesure de performances (vitesses de traitement, selon divers algorithmes).
  • Rédaction de documentation :
  • Documentation complète de l’API générée, y compris exemples de code.
  • Automatisation de la livraison
  • Génération de livrables via l’écriture de fichiers ANT.
  • Écriture de scripts BATCH (.BAT) pour le shell Windows.