Un bon manager devrait consacrer 30% de son temps à coder.

J'avais déja traité ici même d'un sujet sur la véritable fonction de chef de projet (http://le-code-vulgarise.blogspot.fr/2014/01/le-chef-de-projet-web-n-pas.html). 
Un chef de projet comme on l'appelle, exerce en réalité une fonction de manager d'équipes, déléguant la responsabilité de chef de projet technique aux responsables techniques (lead dev, directeur technique).

Ok garçon, mais alors pourquoi nous dis-tu qu'un manager (chef de projet traditionnel) doit consacrer 30% de son temps à coder?

C'est simple, pour le comprendre, posons-nous une simple question:
Qu'est-ce-qui unit, un manager, une équipe technique et la direction?
La réponse est...? Le code.

Dans un métier qui ne cesse d'évoluer, pour qu'un manager puisse réaliser efficacement son boulot, et, le déléguer à l'équipe technique, il doit créer une connexion avec cette équipe et le meilleur moyen de se connecter, est de partager la connaissance du code que l'on délègue.

Oui, mais un manager n'a t'il pas déjà suffisamment à gérer pour rajouter un peu de technique à sa charge?
Il est légitime de penser celà, mais on peut aussi se poser ces questions:
- Une maman donne t' elle du lait chaud à son enfant sans le goûter elle même d'abord?
- Un développeur a t'il jamais contribué à la conception d'un cahier des charges, ou à l'estimation de deadlines?
- Un chef cuisinier passionné délègue t' il sans jamais se mettre lui même aux fourneaux?

A moins d'être totalement désintéressé par le projet, ou complètement overbooké, ou même, à moins de fuir les capacités mentales nécessaires à déployer pour, écrire quelque lignes d'instructions dans un nouveau langage, un bon manager se doit de montrer l'exemple à ses collaborateurs.

Quels sont les bénéfices à retirer d'un tel investissement?
- Gain du respect de l'équipe technique, favorisant ainsi la cohésion par la solidarité.
- Meilleure compréhension et estimation de la charge de travail imputée à l'équipe technique.
- Meilleure communication avec les différents pôles de l'entreprise sur la nature des projets.
- Meilleure compréhension des enjeux de chaque profession.

Il n'y a que des avantages.

Evidemment, il ne s'agit pas de le faire au quotidien, mais 30% de son temps mensuel ou annuel, pour comprendre et apprendre ce que l'on délègue est un premier pas vers une cohésion d'équipe plus forte, et des projets mieux aboutis, juste parce que le métier évolue si vite.

Merci.

Esquisse... principe CSS

Me revoilà donc, sur un principe que je décide d'appeler CSS pour Code Similar Situations.
Principe que j'avais déjà annoncé ici: http://le-code-vulgarise.blogspot.fr/2014/01/comment-je-me-sens-quand-je-code.html
 

Qu'est-ce-que c'est?

Le principe CSS trouve son fondement dans l'idée que tout programme informatique ou tout évènement, trouve une analogie dans la vie courante.

Expliquer une situation complexe par analogie permet de la simplifier aux interlocuteurs, mais aussi à soit même, en s'assurant ainsi d'avoir maîtriser notre sujet, et d'avoir bien su le vendre.

Ex: Un astéroide gros comme un continent s'approche de la terre et, vous et votre équipe d'ingénieurs devez trouver une solution pour empêcher qu'il s'y écrase dans 12 jours et ne mette fin à toute forme de vie sur terre.
Un de vos ingénieurs a une solution et propose:
- Nous pourrions créer des panneaux solaires géants, qui se fixeront comme çà, une fois envoyés dans l'espace, ils émettront un rayon laser qui, on l'espère fera dévier l'astéroide et peut être l'exploser.
Et votre réponse:
- Oui, autant tirer contre un train de marchandises au pistolet à grenailles.

Voilà, d'une proposition complexe à imaginer dans l'immédiat, vous avez su trouver une analogie qui simplifie et éclaire immédiatement la situation, bravo, vous êtes pragmatique, vous venez d'utiliser le pattern CSS (en quelque sortes).

Evidemment, si vous sembliez être séduit par la proposition de l'ingénieur hyper diplômé, charismatique, leader d'opinion, qui a les neurones pour résoudre la solution, trouver une analogie vous a permis de vous rendre compte du ridicule (mauvais choix) de la proposition, mais a aussi automatiquement convaincu votre auditoire, maintenant en recherche de solutions trouvant fondement dans une analogie courante.

C'est ce que préconise le principe CSS (Code Similar Situations).
En l'implémentant dans vos développements web, il vous assurera de vraiment savoir ce que vous codez, et, que ceux qui vous suivront comprendront aisément sans trop d'efforts votre algorythme, votre architecture, votre méthode, vos instructions.

Le principe CSS est à l'origine de mon futur framework php, The Troll Inception, qui me prend énormément de temps et d'énergie.

Merci du temps que vous accordez à cet article, et merci de me faire part de votre opinion sur ce principe.

Etat mental lors de la création d'un programme

Au fil des années et des expériences, ma compréhension du métier a grandi et j'ai appris à cultiver de l'humilité tant j'ai encore énormément à apprendre de mon métier, de la vie et de la relation aux autres.

Mais en ce moment précis, je pense avoir atteint un summum dans mes capacités, que j'ai hâte de repousser, pourvu que j'apprenne encore.
Je commence à jouer mentalement avec les lignes de code, démonte, remonte le code qui a été fait par les autres, pour découvrir leur état d'esprit au moment où ils l'ont codé, et, quand le besoin se fait sentir, je me crée le code qui me correspondrait le mieux.

Il existe ce besoin de personnalisation, de se reconnaître dans l'image d'un programme, comme le besoin de se voir dans une photo de classe.

Je peux ainsi passer des heures entières à réaliser des projections mentales, puis les couchersur papier, les retravailler encore et encore.

L'objectif est d'atteindre cet équilibre entre vécu et code, porté par notre propre énergie créatrice.
Par cet équilibre, le code produit reflète, une partie de notre expérience, l'analogie devient parfaite, car tout programme informatique trouve une analogie dans la vie courante.

Casque sur les oreilles, l'esprit conscient se met en veille, le subconscient projette les lignes d'instruction qui ont générées en nous des émotions et, l'esprit conscient reprend le relais pour jouer avec le code et apporter des améliorations.

Coder est beaucoup plus artistique et moins technique que ce que l'on pense communément.
Et quand on crée quelque chose crée en nous de l'excitation, c'est que nous sommes sur la bonne voie.

Cet état, que nous ne sommes pas beaucoup à partager, est issu d'une pratique que je me suis inculqué en créant l'architecture de mon framework php, The Troll inception, que j'espère vous présenter très vite:
Coder des situations similaires à la vie réelle.

Cela fera l'objet d'un autre topic, principe CSS.

Principe CABIN pour la construction d'objets

J'avais déjà écrit un article ici même, sur ce qu'était un bon code objet.
Avec plus d'expérience et de créativité, j'ai une opinion plus tranchée que j'implémente dans mes applications et, qui je le souligne ne concerne que ma propre opinion.

Passons à table! Qu'est ce qu'un objet?

Un objet pour moi, n'est rien de plus qu'une interface avec laquelle on interragit avec une forme concrète appartenant à une famille abstraite de conteneurs.

Exemple, lorsque j'utilise mon smartphone, j'utilise une interface téléphonique implémentée dans un conteneur au design concret par lequel je peux jouir de l'objet.

Ce qui veut dire que pour être un véritable objet, une classe concrète doit étendre une classe abstraite qui doit implémenter une seule interface générique qui remplit un seul rôle.

Toute classe concrète ne suivant pas ce principe, ne peut être qualifiée d'objet, mais peut-être de trait, ou de tout, mais pas d'objet.

Cela me parait évident, mais je ne l'ai que rarement vu en action dans les codes sources disponibles au sein des frameworks, ou librement sur le net.

Pourtant, ce serait là un excellent moyen de mettre en pratique plus aisément les différents design patterns, mais surtout les principes SOLID et GRASP.

J'ai donc décidé de définir un code object par un principe simple.

CABIN pour Concrete ABstract INterfaces.

J'ai hâte de pouvoir en discuter un peu plus ultérieurement.

Tout ce à quoi un bon développeur doit pouvoir répondre.

Q: Qu'est-ce-que T_PAAMAYIM_NEKUDOTAYIM?
R: C'est l'opérateut de scope de résolution (double colonne), ex: $bread::buy();

Q: Quelle est la cause de cet avertissement: 'Warning: Cannot modify header information - headers already sent', and what is a good practice to prevent it?
R: Un corps de message (body) a été envoyé avec ses headers pendant que d'autres headers étaient envoyés.
Solution: Envoyer les headers avant tout autre code, en s'assurant que aucun espace ou autres caractères aient été envoyés.

Q: Qu'est ce qui ne va pas dans cette requête: "SELECT * FROM table WHERE id = $_POST[ 'id' ]"?
R: 1. Cette requête est vulnérable aux injonctions sql. Il faut protéger d'abord les variables, en utilisant si possible des requêtes préparées (PDO).

2. Ne jamais récupérer l'intégralité des colonnes d'une table comme ceci (*), mais spécifier manuellement chaque colonne nécessaire pour des soucis de performance.

Q: Qu'est ce qui ne va pas dans cette condition: if( !strpos( $haystack, $needle ) ...?
R: strpos retourne la position de l'index trouvée dans $needle, qui peut être 0. 0 équivaut à false, il convient de faire une condition aussi sur le typage comme ceci: if( false !== strpos( $haystack, $needle )...

Q: Quel est la meilleure façon d'écrire cette condition, et pourquoi?
if( 5 == $someVar ) or if( $someVar == 5 )
R: la première, car la seconde comporte des risques d'attriburt 5 à $ someVar, ce qui génèrerait une erreur.

Q: Prenons le code suivant:

function doSomething( &$arg )
{
    $return = $arg;
    $arg += 1;
    return $return;
}

$a = 3;
$b = doSomething( $a );
...Quelle est la valeur de $a et $b à la fin du programme, et pourquoi?
R: $a vaut 4 et $b vaut 3. Le premier parce que $a est passé en référence, le seconf parce que $b n'est qu'une copie de $a, pas de sa référence.

Q: quelle est la différence entre public, protected et private dans la définition d'une classe?
R: public rend les embres d'une classe accessibles "partout", protected rend les membres d'une classe accessible à la classe elle même et aux classes qui l'implémentent, private n'autorise l'accès aux membres d'une classe qu'à la classe elle même.

Q: Quelle est la différence entre include et require?
R: include renverra un warning si un fichier n'existe pas, require renverra une erreure fatale. De plusn require ne permet d'inclure que des fichiers php.

Q: Qu'est ce qui ne va pas avec ce code?:

class SomeClass
{
    protected $_someMember;

    public function __construct()
    {
        $this->_someMember = 1;
    }

    public static function getSomethingStatic()
    {
        return $this->_someMember * 5; // here's the catch
    }
}
R: Les méthodes statiques n'ont simplement pas accès à $this, car une méthode statique peut être appelée sans avoir besoin d'instancier une classe.

Q: Quelle est la différence entre une interface et une classe abstraite?
R: Une interface et une classe abstraite sont tous les deux des contrats d'exécution, à la différence qu'une interface ne définit pas de comportement et impose l'héritage des ses méthodes, quand la classe abstraite permet de définir un comportement aux méthodes sans rendre obligatoire leur héritage.

Q: Comment fonctionne le protocole HTTP?
R: Le protocole Http utilise le protocole TCP/IP pour ses communications. Le client se connecte au serveur qui répond, ensuite le client demande un fichier au serveur qui le lui renvoie en réponse.

Q: Quelle est la différence entre == et === ?
R: '==' vérifie l'égalité, tandis que '===' vérifie l'égalité et le typage des deux variables.

Q: Expliquez pourquoi le code suivant affichera 2.5 plutôt que 3:
$a = 012;
echo $a / 4;
R: En php, quand un nombre est précédé de 0, le nombre et traité comme un nombre octal, donc sur base 8. En outre, le nombre octal 012 vaut 10 en décimal.

Q: Pourquoi faut-il désactiver la fonction register_globals?
R: Quand register_globals est à on, chaque variable transitant à travers les vatiables superglobales $_GET et $_POST sont disponibles comme des variables globales dans toute l'application.

Q  Que signifie ce symbole en php "$$"?
R: $$ signifie la variable d'une variable, exemple:
<?php
$message="This is a string<br>";
echo $message; //affichera "This is a string"

$message="variable";
$variable="This is the second string";
echo $$message; //affichera "This is the second string"
?>
Ici, le parser cherche la valeur de $message, qui est "variable", il cherche donc la variable "$variable" et affiche sa valeur.

Q: Qu'est-ce-qu'un index en mysql?
R: Un index en mysql est identique à l'index d'un livre. Dans un livre sans index ou table des matières, vous devez parcourir les pages du livre une à une pour trouver l'information souhaitée, ce qui est épuisant. En revanche, retrouver une page spécifique à partir d'un index devient plus rapide, c'est le même principe.

Q: Qu'est-ce-que les contraintes mysql?
R: Je définis les contraintes comme une liste d'opérateurs servant à limiter les insertions dans une table.
Voici une liste de contrainted:
NOT NULL
UNIQUE
PRIMARY KEY
FOREIGN KEY
ENUM
SET

Le chef de projet web n'existe pas.

Dans le monde professionnel du web, il est traditionnellement admis qu'il y a un chef de projet et une équipe technique composée de développeurs, d'un lead dev et/ou directeur technique.

Mais concrètement, nous allons le voir, la fonction de chef de projet s'apparente plus à celle d'un manager, déléguant la responsabilité du projet, sur le fond comme sur la forme, à l'équipe technique.

Du calme, il ne s'agit pas de dénigrer la fonction de chef de projet, au contraire, il s'agit de la revaloriser en constatant quelque faits.

Pourquoi?
J'ai pour habitude de dire que pour exercer le métier de développeur web, il faut une passion véritable, car ce métier demande la mobilisation de beaucoup de ressources humaines, créatives et intellectuelles, qui ne se développent qu'avec l'expérience.

Ainsi, un développeur en chef (lead ou directeur technique) doit être en mesure au minimum de pouvoir:
- évaluer sa charge dev/tu
- s'assurer de la qualité du code
- écrire des tests (fonctionnels, unitaires, acceptances...)
- estimer son code coverage en fonction du délai imparti
- construire une architecture bdd
- apprendre chaque jour car le métier est en constante évolution
- débuguer des applications
- utiliser des outils frameworks ou cms
- connaître 3 languages de programmation
- savoir estimer le niveau de sa dette technique
- schématiser et s'approprier l'architecture interne du projet
- segmenter et déléguer suivant des méthodes (agile...)

Nous observons alors qu'un développeur est totalement responsable de la réalisation technique d'un projet, parce qu'il se doit de connaitre le projet de A à Z, tant sur la forme (cahier des charges), que sur le fond (architecture du code initial et final, lignes de code produites).
Ou sinon, comment un architecte ne peut-il pas maîtriser les plans de la maison à construire?

De ce fait, le projet étant essentiellement technique, la responsabilité technique du projet revient entièrement au lead dev ou directeur technique s'il y en un.
Et, parce que le chef de projet, n'a pas de vision sur la finalité des lignes d'instruction produites, et ne sait peut-être pas l'interpréter pour le valider, il a en réalité, la charge de gérer une équipe composée d'hommes et de femmes.

Le chef de projet est un manager, le vrai chef de projet est technique.

Il n'existe pas d'évolution de développeur à chef de projet, un développeur en chef est déjà LE chef de projet, géré par UN ou plusieurs managers d'équipe.

Merci :) !

Ce qu'il faut pour être un bon développeur web

Je viens de faire ma veille technique, et j'ai été pas mal inspiré par ce sujet.

Avant de devenir développeur web, j'avais une idée classique du métier, qui est celle de l'écriture d'une succession de logiques dans un langage.

On n'a pas tendance à y intégrer la difficulté et le facteur évolutif du secteur.

Hors, nous sommes dans un métier, dans lequel il est indispensable de se former aux perpétuelles nouveautés et bonnes pratiques, pour sortir de sa zone de confort et subsister.

Il faut se familiariser avec les différents outils pour atteindre un niveau de qualité toujours plus exigeant. C'est comme cela que l'on est reconnu et que l'on grandit au sein d'une entreprise.

Mais, surtout, et le plus important, il faut pouvoir vendre les requis, pré-requis et impératifs de ce métier à tous les collaborateurs, avec lesquels on est liés au quotidien.

C'est ce dernier point le plus important, car beaucoup de développeurs ont tendance à le négliger, mais il est souvent le point de départ d'un cycle de turnover regrettable.

Pourquoi? 

Parce que face à des impératifs financiers et de temps, la méconnaissance de ce qu'il faut pour livrer un produit qualitatif dans les temps peut emmener la direction à vous guider dans un mauvais courant.

Et c'est dans l'action de ce type de situations qu'il se peut que certains dirigeants ne voient simplement pas, ou n'aient pas la disposition suffisante pour adopter une attitude d'humilité nécessaire, pour réfléchir à une solution de compromis, quand à une livraison qualitative, dans un temps correct.

A partir de ce moment, la chaîne de responsabilités devient verticale, et chacun des salariés y a une part, qu'elle soit assumée ou pas.

En conclusion, pour être un bon développeur, il faut être avide de connaissances, mais surtout, il faut savoir communiquer avant toute chose sur les processus de développement d'une application auxquels on est soumis.