Au début du mois de février, suite à ma décision de quitter Teamlog (actuellement OPEN), j’avais commencé à chercher une entreprise qui pourrait répondre à mes attentes professionnelles : faire des produits de haute qualité, utiliser les technologies modernes, être proche des communautés OpenSource et travailler avec les gens passionnés par l’informatique.
Dans ce post je voudrais partager les résultats de mes recherches des « bonnes » SSII dans la région parisienne. Les « bonnes » cela veut dire les sociétés intéressantes tout d’abord du point de vue technique.
J’ai vu en tout 7 entreprises (SSII).
Voilà la liste des SSII qui me semble être très attractifs pour les gens techniques :
1. SFEIR
2. Ideo Technologies
SFEIR – bien sûr, acteur très marquant dans le monde Java à Paris. Partenaire de Google, SpringSource et Microsoft, sponsor de JUG Paris – évènement incontournable pour les passionnés Java. SFEIR est certifié ISO 9001, utilise les approches d’industrialisation des développements. Ils participent aux phases de beta-testing de différents frameworks OpenSource(comme GWT pour Google). Et finalement, Didier GIRARD, le CTO de SFEIR - l’évangéliste technique connu dans le monde de geeks à Paris, attire beaucoup de personnes à rejoindre SFEIR.
IdeoTechnologies - une petite SSII qui m’a impressionnée. Ils étaient très professionnels lors de notre communication. Je sentais le respect vers les « techos » en discutant avec les différents gens d’Ideo.
CTO – passionné par la technique. Lors de mon entretien technique nous avons parlé de l’héritage en Hibernate, j’ai appris qu’on peut générer le PDF à partir de JavaScript. Ca fait plaisir de voir les directeurs qui gardent les mains dans le code, qui parlent avec passion de différences entre les modèles Java et JavaScript !
Ideo a une activité R&D assez intéressante. Ils sont des commiteurs principales de la bibliothèque SweetDEV™ RIA
Cette bibliothèque des composant AJAX est utilisée par leurs clients dans le secteur financière. Un modèle business très intelligent. Les clients utilisent le produit, investissent dans son évolution. Le produit devient mature et attirent des nouveaux utilisateurs/clients qui contribuent aux développements du produit à leur tour. Et ainsi de suite.
Si vous connaissez d'autres SSII qui ont le même d'état d'esprit, vous pouvez les rajouter dans les commentaires.
samedi 10 avril 2010
vendredi 9 avril 2010
DropBox : disque dur intelligent à distance
DropBox est une application qui permet de partager et synchroniser le contenu numérique.
Pout tous ceux qui travaillent sur plusieurs ordinateurs l’application DropBox pourra bien simplifier la vie.
Un cas d’utilisation classique d’utilisation de DropBox. Vous avez commencé la rédaction d’un rapport sur votre PC Windows à bureau. Vous voulez continuer votre travail chez vous. Avant de partir un simple « glisser-deposer » dans le répertoire DropBox et votre document va apparaître sur votre Apple Mac OS à la maison. Plus besoin des clés USB ou d’envoie par mail.
DropBox a une fonctionnalité de Public Folder et Public Link. Vous pouvez rendre un fichier dans votre répertoire Public de DropBox accessible via le protocole http à tout le monde ! Et tout cela, en un seul clique !
Très efficace et très pratique. Gratuit et fiable. DropBox est devenu presque un standard de-facto de synchronisation et de partage des fichiers.
Par contre, le contenu hyper sensible il faut mieux garder ailleurs.
Pout tous ceux qui travaillent sur plusieurs ordinateurs l’application DropBox pourra bien simplifier la vie.
Un cas d’utilisation classique d’utilisation de DropBox. Vous avez commencé la rédaction d’un rapport sur votre PC Windows à bureau. Vous voulez continuer votre travail chez vous. Avant de partir un simple « glisser-deposer » dans le répertoire DropBox et votre document va apparaître sur votre Apple Mac OS à la maison. Plus besoin des clés USB ou d’envoie par mail.
DropBox a une fonctionnalité de Public Folder et Public Link. Vous pouvez rendre un fichier dans votre répertoire Public de DropBox accessible via le protocole http à tout le monde ! Et tout cela, en un seul clique !
Très efficace et très pratique. Gratuit et fiable. DropBox est devenu presque un standard de-facto de synchronisation et de partage des fichiers.
Par contre, le contenu hyper sensible il faut mieux garder ailleurs.
lundi 1 mars 2010
Interviews techniques. Best practices pour les candidats
Suite à mon expérience avec le monde des SSII parisiennes, j’ai accumulé un certain nombre des idées et de remarques sur les entretiens techniques.
J’ai eu de la chance d’être présent sur les deux côtés des barricades : en tant que candidat cherchant des nouvelles missions et en tant que « conducteur » représentant l’entreprise qui voulait embaucher des spécialistes techniques.
Dans cet article je vais présenter mon expérience en tant que candidat.
Alors, vous êtes un candidat, l'ingénieur en informatique cherchant une nouvelle mission/poste.
Je vais laisser à côté le premier test technique que vous avez éventuellement passé avec le RH. Dans la plupart des cas, ce test est un QCM classique (la syntaxe du langage, possibilité du plateforme, les questions sur les bases de OOP). Ce test est nécessaire pour faire la première « brute » estimation de vos compétences. Ce test permettra d’éviter à l’entreprise de solliciter l’un de ces référents techniques ou architecte pour évaluer le niveau des connaissances de base du candidat.
Tout d’abord, pour réussir l’entretien technique il faut adapter une idée qu’une interview c’est un jeu. Pour vous ce jeu doit avoir 2 objectifs : répondre correctement aux questions et profiter de l’occasion pour parler avec une personne forte techniquement. En effet, les conducteurs des entretiens ce sont des personnes avec un bon niveau technique qui peuvent vous apporter beaucoup d’information nouvelle et intéressante. Notez toutes les questions sur lesquelles vous n’avez pas de réponse, n’hésiter pas à posez des questions à l’interwieur si le contexte est favorable (pas de contraintes de temps, par exemple). Cela montre que vous êtes toujours prêt à apprendre et curieux par rapport aux nouvelles technologies.
Si on vous pose la question et vous ne savez pas exactement la bonne réponse. Pas de panique. Essayez de réfléchir à la voix haute. Faites quelques hypothèses. Peut-être en cours de cette réflexion vous allez trouver la réponse ou la personne en face de vous pourrait vous indiquer la bonne direction. Mais, n’hésitez pas à dire fermement : « Je ne sais pas », si vous ne savez pas du tout où chercher la bonne réponse.
Très souvent on vous posera des questions pièges. Par exemple, « Quelle type de relations entre les objets préférez-vous : héritage ou agrégation/composition ? » Il n’y a pas une seule réponse correcte. Tout dépend du contexte particulier. Vous devez expliquer cela pour chaque type de relation en donnant un exemple.
Lors de vos réponses essayez de montrer votre culture technique, en s’appuyant sur les ouvrages, livres ou blogs des différents experts dans votre domaine.
N’hésitez pas à schématiser vos réponses ou vos réflexions. Les diagrammes UML simples ou juste des carrés avec des cercles suffiront. Les architectes adorent les schémas. :)
Après chaque entretien, faites des rétrospectives. Analysez vous-même vos réponses et le résultat de l’entretien. Notez bien les points que vous ne maîtrisez pas et réfléchissez comment vous pouvez les améliorer. Chaque entretien c'est un miroir qui reflète vos faiblesses. Oui, uniquement, les faiblesses. En informatique, il n y a pas une personne qui sait tout !
PS : L’article a été posté avec le support du café www.lacantochepaname.com, rue Réaumur.
J’ai eu de la chance d’être présent sur les deux côtés des barricades : en tant que candidat cherchant des nouvelles missions et en tant que « conducteur » représentant l’entreprise qui voulait embaucher des spécialistes techniques.
Dans cet article je vais présenter mon expérience en tant que candidat.
Alors, vous êtes un candidat, l'ingénieur en informatique cherchant une nouvelle mission/poste.
Je vais laisser à côté le premier test technique que vous avez éventuellement passé avec le RH. Dans la plupart des cas, ce test est un QCM classique (la syntaxe du langage, possibilité du plateforme, les questions sur les bases de OOP). Ce test est nécessaire pour faire la première « brute » estimation de vos compétences. Ce test permettra d’éviter à l’entreprise de solliciter l’un de ces référents techniques ou architecte pour évaluer le niveau des connaissances de base du candidat.
Tout d’abord, pour réussir l’entretien technique il faut adapter une idée qu’une interview c’est un jeu. Pour vous ce jeu doit avoir 2 objectifs : répondre correctement aux questions et profiter de l’occasion pour parler avec une personne forte techniquement. En effet, les conducteurs des entretiens ce sont des personnes avec un bon niveau technique qui peuvent vous apporter beaucoup d’information nouvelle et intéressante. Notez toutes les questions sur lesquelles vous n’avez pas de réponse, n’hésiter pas à posez des questions à l’interwieur si le contexte est favorable (pas de contraintes de temps, par exemple). Cela montre que vous êtes toujours prêt à apprendre et curieux par rapport aux nouvelles technologies.
Si on vous pose la question et vous ne savez pas exactement la bonne réponse. Pas de panique. Essayez de réfléchir à la voix haute. Faites quelques hypothèses. Peut-être en cours de cette réflexion vous allez trouver la réponse ou la personne en face de vous pourrait vous indiquer la bonne direction. Mais, n’hésitez pas à dire fermement : « Je ne sais pas », si vous ne savez pas du tout où chercher la bonne réponse.
Très souvent on vous posera des questions pièges. Par exemple, « Quelle type de relations entre les objets préférez-vous : héritage ou agrégation/composition ? » Il n’y a pas une seule réponse correcte. Tout dépend du contexte particulier. Vous devez expliquer cela pour chaque type de relation en donnant un exemple.
Lors de vos réponses essayez de montrer votre culture technique, en s’appuyant sur les ouvrages, livres ou blogs des différents experts dans votre domaine.
N’hésitez pas à schématiser vos réponses ou vos réflexions. Les diagrammes UML simples ou juste des carrés avec des cercles suffiront. Les architectes adorent les schémas. :)
Après chaque entretien, faites des rétrospectives. Analysez vous-même vos réponses et le résultat de l’entretien. Notez bien les points que vous ne maîtrisez pas et réfléchissez comment vous pouvez les améliorer. Chaque entretien c'est un miroir qui reflète vos faiblesses. Oui, uniquement, les faiblesses. En informatique, il n y a pas une personne qui sait tout !
PS : L’article a été posté avec le support du café www.lacantochepaname.com, rue Réaumur.
lundi 18 janvier 2010
Podcasts pour les développeurs
Si vous êtes passionné par l’informatique et vous êtes prêt de rester « avec l’informatique » en dehors du travail, les podcasts peuvent vous aider à diversifier votre façon de faire la veille technologique. Personnelement, pour moi les podcasts est une meilleure solution pour profiter du temps que je passe en transport en commun.
Je voudrais mentionner dans cet article quelques podcasts informatiques que j’écoute régulièrement.
- http://lescastcodeurs.com/ - un podcast en français sur le monde Java. Les auteurs sont 4 Français très connus dans la communauté Java.
- http://se-radio.net/ - un podcast en anglais sur le génie de logiciel. Je vous le recommande. Très enrichissant. Il y a des interviews avec des personnes remarquables, comme par exemple avec E. Gamma.
- http://www.computer.org/portal/web/computingnow/onarchitecture - architecture de logiciel par le guru d’UML et la programmation orientée objet Grady Booch. (anglais)
- http://radio-t.com/ - pour ceux qui parlent le russe un podcast sur l’IT. Très riche en contenu et avec de l’humour.
Si vous connaissez des autres podcasts intéressants, vous pouvez les rajouter dans les commentaires de cet article.
dimanche 17 janvier 2010
TeamCity - Intégration continue (IC)
La suite des articles sur l’industrialisation de développement.
Cet article est consacré au serveur d’intégration continue TeamCity. Ca fait déjà presque 2 ans que j’utilise ce serveur. Très stable, facile à mettre en place et facile à utiliser.
Quelques liens utiles:
- Télécharger TeamCity: ici
- Documentation et video tour des fonctionnalités : ici
- Blog de TeamCity : ici
Cet outil est développé par JetBrains, un éditeur de logiciel très connu dans le monde Java pour son IDE Intellij Idea et dans le monde .NET pour son plugin Resharper.
Ecran principal de TeamCity donne une image instantanée des états des différents builds qui sont présents sur le serveur :
Pour utiliser TeamCity (ou n’importe quel autre serveur d’intégration continue) vous aurez besoin de deux choses : le système de contrôle des versions (CVS, SVN, et à partir de la version 5.0 TeamCity supporte Git et Mercurial– les vcs distribués très à la mode en ce moment) et un outil des builds automatiques (Ant, Maven, MsBuild, etc).
Une particularité de l’architecture TeamCity est l’utilisation des agents – machines physiques qui se sont regroupés ensemble pour permettre l’exécution de plusieurs builds en même temps. Cette fonctionnalité est disponible uniquement dans la version payante.
TeamCity supporte 2 plateformes Java et .NET. Cet argument peut être très intéressants car TeamCity permet dans ce cas là de capitaliser les connaissances sur le processus d’intégration continue pour différents projets. Les meilleures pratiques et astuces du monde d’IC de Java peuvent être réutilisées pour .NET et vice versa.
samedi 16 janvier 2010
Mac in our life
Chez Mozilla, on programme avec le Mac :
Pour comprendre pourquoi Google c’est génial, regarder dans quelles conditions travaillent ces « pauvres gars » :
Plus de photos de Google à Stockholm, Sweden, ici.
La puissance de VmWare in action sur mon portable MacBook Pro - Mac Leopard Snow, Windows XP et Ubuntu sont ensemble:
vendredi 15 janvier 2010
Industrialisation de développement de logiciel (.NET)
Dans cet article je voudrais présenter mon expérience dans l’industrialisation de développement de logiciel. Je vais me concentrer sur les aspects purement techniques.
Je pense que l’automatisation est l’une des caractéristiques principales de l’industrialisation. La première chose à automatiser est un processus de build de votre logiciel. Le strict minimum d’un build automatique :
- Compilation des sources
- Packaging (création des *.dll, *.exe ou archive Web, par exemple)
Aujourd’hui, les bons projets rajoutent encore quelques étapes supplémentaires pour assurer la qualité :
- Tout d’abord, la récupération de la version du système de gestion de version (CVS, SVN, Git, etc).
- 2 étapes décrit précédemment
- Lancement des tests automatisés (NUnit+DbUnit.NET)
- Génération de la documentation (Doxygen - générateur avancé de la documentation technique à partir du code source, les langages supportés - C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C# )
- Génération des métriques sur le code (FxCop - signale des problèmes (règle de nommage, performance, architecture(design), sécurité, etc) dans le code, NCover - détermine la couverture du code par les tests, NDepend - analyse les dépendances).
- Déploiement pour l’équipe de QA si nécessaires.
- Envoie des notifications à l’équipe de développement sur les résultats des builds (mail, SMS, feed RSS, etc).
Dans le monde .NET, nous avons outil MSBuild (équivalent de Ant en Java) qui permet de faire ces builds. L’exemple du script MsBuild pour compiler une classe C#:
MsBuild contient un certain nombre de tâches (target) prédéfinis. Toutes les 7 étapes que j’ai listé peuvent être réalisées facilement avec les targets standards de MsBuild.
Dans le prochain article je décrirai le serveur d’intégration continue TeamCity qui s’intègre dans la politique d’industrialisation des grands projets.
samedi 13 septembre 2008
Audit des logiciels
Je me prépare à l’audit externe de quelques applications lundi prochain.
Pour ceux qui cela intéresse il y a la norme ISO 9126 consacrée à l’évaluation de la qualité de logiciel. Pour plus de détails : http://en.wikipedia.org/wiki/ISO_9126
Une représentation très compréhensive en français est ici.
Parmi les logiciels qui permettent de sortir certaines métriques sur le code, je peux vous recommander :
Cet audit semble être très intéressant. On devra évaluer une dizaine de l’application pendant quelques heures. J’espère ce sera très enrichissant !
Bon, c’était mon dernier post pour ce week-end ;)
Pour ceux qui cela intéresse il y a la norme ISO 9126 consacrée à l’évaluation de la qualité de logiciel. Pour plus de détails : http://en.wikipedia.org/wiki/ISO_9126
Une représentation très compréhensive en français est ici.
Parmi les logiciels qui permettent de sortir certaines métriques sur le code, je peux vous recommander :
- Source Monitor. Support de plusieurs langages: Java, C++, C#, C, Delphi, Visual Basic et même HTML. Un outil puissant, facile à utiliser et à installer. OpenSource. http://www.campwoodsw.com/sourcemonitor.html.
Merci à Aurélien qui m'a montré cet outil. - Metrics pour Eclipse. Que pour le monde Java. Un plagin très sympathique et puissant qui s’intègre à Eclipse et qui calcule les métriques à la volée. http://metrics.sourceforge.net/
Cet audit semble être très intéressant. On devra évaluer une dizaine de l’application pendant quelques heures. J’espère ce sera très enrichissant !
Bon, c’était mon dernier post pour ce week-end ;)
Web Developer Toolbar
Pour ceux qui travaillent beaucoup avec des technologies Web (HTML, CSS, JavaScript). Un addon magique pour FireFox qui facilite grandement le déboguage et l’analyse de pages web.
Les fonctionnalités que j’utilise le plus souvent sont les suivantes :
1. Affichage des erreurs JavaScript (les messages d’erreurs sont très parlants, ce que n’est pas le cas chez IE).
2. Désactivation rapide de tous les JavaScript sur la page (avez-vous testé comment se comportent vos pages sana JavaScrip activé ?)
3. «Display form details » - affiche les détails sur les inputs (noms, id), valeurs des attributs action des balises form
Installation facile à partir de : https://addons.mozilla.org/en-US/firefox/addon/60
Des espaces à la fin des noms. Version Windows et Linux
Bonjour,
Est-ce que vous savez que les règles du nommage des fichiers sont très dépendantes du système d’exploitation. Voilà un exemple qui m’a coûté quelques jours d’investigation pour un projet sur lequel je travaille.
Sous Windows le nom du fichier ne peut pas contenir des espaces à la fin! Pour Windows les fichies :
1. ‘toto.txt’
2. ‘toto.txt ’ (un espace à la fin)
3. ‘toto.txt ‘ (deux espaces à la fin)
sont identiques et seront représentez par UN SEUL fichier sur votre disque ! Windows va tronquer les espaces à la fin.
Dans les OS comme Linux RedHat ce n’est pas le cas. Pour ce système, ces trois fichiers sont les fichiers différents. Donc, pour Linux l’espace à la fin du nom de fichier est tout à fait légitime.
Cette différence subtile m’a coûté 2 jours pour réussir à reproduire une anomalie. Vu que notre plateforme de développement est sous Windows et les serveurs de production sont sous Linux, je ne pouvais pas avoir le même comportement de l'application que nos clients.
Conclusion. La reproduction des anomalies, les tests de régression, les tests unitaires doivent être exécutés dans l’environnement le plus proche possible de votre environnement de production. C’est une règle de-facto de développement que je n’ai pas respecté. Mais, l’anomalie est reproduite et sera corrigé et moi, j’ai appris quelque-chose de nouveau et c’est ça qui compte !
Est-ce que vous savez que les règles du nommage des fichiers sont très dépendantes du système d’exploitation. Voilà un exemple qui m’a coûté quelques jours d’investigation pour un projet sur lequel je travaille.
Sous Windows le nom du fichier ne peut pas contenir des espaces à la fin! Pour Windows les fichies :
1. ‘toto.txt’
2. ‘toto.txt ’ (un espace à la fin)
3. ‘toto.txt ‘ (deux espaces à la fin)
sont identiques et seront représentez par UN SEUL fichier sur votre disque ! Windows va tronquer les espaces à la fin.
Dans les OS comme Linux RedHat ce n’est pas le cas. Pour ce système, ces trois fichiers sont les fichiers différents. Donc, pour Linux l’espace à la fin du nom de fichier est tout à fait légitime.
Cette différence subtile m’a coûté 2 jours pour réussir à reproduire une anomalie. Vu que notre plateforme de développement est sous Windows et les serveurs de production sont sous Linux, je ne pouvais pas avoir le même comportement de l'application que nos clients.
Conclusion. La reproduction des anomalies, les tests de régression, les tests unitaires doivent être exécutés dans l’environnement le plus proche possible de votre environnement de production. C’est une règle de-facto de développement que je n’ai pas respecté. Mais, l’anomalie est reproduite et sera corrigé et moi, j’ai appris quelque-chose de nouveau et c’est ça qui compte !
Inscription à :
Articles (Atom)
Articles
