[CSD] Connected System Developer

mercredi 20 octobre 2010 07:28 JeremyJeanson

[CSD] Connected System Developer

Je me lance aujourd'hui dans une nouvelle ligne d'articles un peu particuliers. Je rassure tout le monde, je reste dans la lignée de ce que j'ai commencé, mais j'ajoute une corde à mon blog avec la catégorie "Connected System Developer".

Pourquoi ce titre?

Je n'ai pas cherché très loin le titre, j'avoue, c'est le nom de mon expertise MVP. Merci donc au programme MVP pour l'inspiration. On parlera donc de choses que je pratique chaque les jours et qui font qu'un code sur un dispositif connecté, n'est pas toujours un code comme les autres.

Alors pourquoi ces articles?

Développant depuis déjà un beau paquet d'années sur des outils interconnectés avec WCF/WF, remoting, Winsock, LDAP, etc. mon travail a souvent lieu avec des dispositifs peu familiers de développeurs. Ceci va de pair couvant avec la méconnaissance d'un certain nombre de contraintes liées au système, à l'infrastructure et à mes grands amis les serveurs.

Dans cette série d'articles, je vais donc avoir à relier deux mondes qui bien souvent ne se comprennent pas : Aministrateurs / IT et architectes / développeurs. J'ai bien conscience que ces articles risques d'éborgner les développeurs plus que les administrateurs, ou du moins certain le prendrons comme tel. L'idée n'est pas là.

Parmi la pléthore de bonnes pratiques qui existes de nos jours en matière de développement, il y en a un certain nombre qui nous viennent des besoins des OS Serveurs et de feux NT4. Je devrais donc en théorie enfoncer des portes grandes ouvertes. Mais mon travail de tous les jours me dit le contraire et me convint de l'utilité de ces articles.

Histoire d'annoncer la couleur, voici quelques articles que j'ai déjà prévu :

• Les bases du chois d'un "compte" pour les services infra ou autre (WCF, pool IIS... etc)
• Un compte Windows sur un service WCF, c'est une responsabilité!
• Multipe bindings des services dans le monde réel (aider vos admin svp et stop le httpbinding en localhost!)
• Versionning, repository de sources sans administration des backup.... arg quand ça plante!
• Développeur restez humble s.v.p., vous n'êtes pas les dieux du système... ni de l'open space!
• Contrôler les dépendances de vos projets (applications tierces non compatibles avec les produits serveurs... tu as déjà vue Outlook sur nu server Exchange toi?!)
• Le firewall est un ami, pas l'ennemi du service.
• Service et gestion de fichiers... il y a des règles...
• L'AD n'est pas une poubelles!