Le selfie, créateur d'attention par excellence.

Je me suis récemment posé la question, qu'est-ce-que réellement le selfie, d'où vient-il, quel est son avenir?

Le selfie, pour self-portrait (autoportrait en anglais), est un procédé par lequel le sujet de la photo qui est en partie son créateur, se met en scène par l'image, dans des contextes particuliers.
Si la pratique ne date pas d'hier (le premier selfie étant né en 1839 avec le chimiste Robert Cornelius http://www.7sur7.be/7s7/fr/1531/Culture/article/detail/1746042/2013/11/24/Le-premier-selfie-de-l-histoire-date-de-1839.dhtml), le terme selfie apparaît en 2002 sur un forum et a été intronisé en 2013 par le célèbre dictionnaire d'Oxford.

Il est aussi primordial de noter que, bien avant l'apparition et la généralisation du premier appareil photo portatif en 1888 (Brownie de Kodak), certains peintres tels que Van Gogh, Goya, réalisaient déjà des autoportraits comme moyen de s'identifier.

Ainsi, depuis les années 2000, la pratique s'est étendue par simplification avec l'avènement des smartphones et, notamment de ceux avec caméra frontale.
Donc, le selfie n'étant qu'un procédé, il a des caractéristiques polymorphes, et peut par définition, se décliner sous plusieurs formes, à l'infini:
- Belfie "photographier ses fesses"
- Boobfie "photographier ses seins"
- Felfie (farmerselfie) "poser en photo avec un animal"
- Healthie "se prendre en photo en étant malade"
- Selfie at funerals "se prendre en photo lors d'un enterrement"
- Duck face
- Sparrow face
Etc... Les déclinaisons sont infinies.

Jadis, l'image était déjà un moyen de communication, mais depuis peu, elle est devenu un moyen d'expression sociale servant à attirer l'attention.
Parce qu'un selfie, n'est rien d'autre que le récit d'une partie de son histoire personnelle.

Comment exploiter le selfie?

Faire un selfie simplement parce qu'il faut le faire, lorsque celui-ci n'exprime aucun besoin de cohésion sociale, n'a aucune utilité applicative.

Comme cet internaute se prenant en photo devant auschwitz le pouce levé, et qui s'est par la suite excusé publiquement, expliquant l'ignorance de son geste par un effet de mode (http://www.theguardian.com/commentisfree/2013/aug/29/selfies-holocaust-memorial).

Le secret du selfie réside donc dans l'expression immédiate d'une utilité de cohésion, par l'identification à une communauté.

Le futur du selfie, l'entreprise!

Ceci est mon interprétation personnelle sur le futur du selfie.

Aujourd'hui toutes les entreprises ou presque, utilisent des supports textes ou visuels (commerciaux) pour communiquer sur les réseaux sociaux, mais ceci pose souvent un problème d'authenticité dans lequel de moins en moins de consommateurs s'identifient, moi y compris.

En revanche, si chaque entreprise offrait à ses collaborateurs un outil universel de selfie (cabine photo par exemple), les mettant en scène sous divers contextes au sein même de l'entreprise, cela offrirait une magnifique base de données d'images permettant de communiquer plus efficacement sur divers sujets tels que:
- La parité hommes/femmes au sein de l'entreprise
- La mixité culturelle
- L'attention portée à chacun des collaborateurs par l'expression
- L'indice de bonheur des collaborateurs
- La gestion de carrière des collaborateurs
...

Les déclinaisons seraient multiples, pourvues d'authenticité et d'humanisme.
Les marques communiqueraient désormais à travers leurs collaborateurs, replaçant ainsi l'humain au centre de la stratégie d'entreprise.

Et pour accompagner cette tendance, il faudrait un réseau social professionnel précurseur, qui regrouperait cette gigantesque base de données d'images à la Instagram, un réseau social professionnel d'un nouveau genre, se démarquant de très loin de Linkedin ou Viadeo.

Qui portera cette tendance si elle répond à un réel besoin? L'avenir nous le dira.

Arrêtons de croire que le candidat est toujours seul fautif des expériences passées!

Pour la plupart d'entre vous qui êtes en recherche d'emploi ou de candidats (je me centre sur ces derniers), vous avez sans doute dû faire l'expérience d'une mécanique fortement encrée dans les traditions qui est, la prise de contact avec les anciens employeurs.

Cette démarche, issue du principe de causalité, affirme que dans les mêmes conditions, les mêmes causes produisent les mêmes effets, c'est la théorie du déterminisme.

Ainsi, dans le respect de cette tradition, l'identification des causes des précédentes ruptures de contrat d'un candidat, voulues ou pas, est soumis à l'identification obligatoire des conditions réelles ayant menées à ces causes.

Donc, sans une cartographie des conditions exactes des précédentes ruptures de contrat, il est impossible d'avoir une cartographie réaliste du passé d'un candidat, pour ainsi se débarasser soit même de la croyance selon laquelle un candidat est toujours seul fautif des ruptures passées.

Il existera toujours des infinités de conditions à une rupture, comme, mépris ciblé et acharné d'un collègue avec plus de pouvoir, dirigeant instaurant un régime de terreur conduisant à un fort taux de turnover, dirigeant peu informé sur le métier mais imposant des impératifs peu réalistes, candidat peu compétent, peu social, trop extraverti ou introverti, dirigeant ayant racheté une boite juste pour se servir de sa trésorerie au détriment des salariés... les causes sont nombreuses, mais la responsabilité toujours partagée, il n'y a jamais un seul et unique responsable, même un employeur qui l'affirmerait serait dans le mensonge.

Par conséquent, la perfection n'appartient à aucun parcours professionnel, et, l'histoire nous prouve que c'est parfois du chaos que naissent des parcours et des destins d'excellence, pour ceux qui s'accrochent et évoluent.

Quel est le meilleur moyen de procéder à cette démarche?

Il est d'abord nécessaire de demander l'autorisation au candidat. Vous n'aimeriez pas que l'on fasse une intrusion dans votre passé ou vie privée, ou même sur votre historique financier, et ce, pour quelque raisons que ce soit, sans avoir à vous justifier.
Faites de même si vous souhaitez vous renseigner sur le passé d'un candidat, demandez-lui la permission, c'est le minimum de respect à avoir dans une collaboration humaine, que d'instaurer un dialogue et d'ouvrir le débat.

Ensuite, sachez que si une expérience s'est mal passée (souvent avec courtoisie), ce qui sera le cas dans la majorité des ruptures pour x ou y raisons, vous n'obtiendrez que très rarement des conditions objectives dans lesquelles l'ancien employeur avouera lui même, une part de responsabilité, hors, il est nécessaire de demander à l'ancien employeur de vous donner sa part de responsabilité.
Si il n'en avoue aucune, il est fort probable que votre renseignement vous soit inutile, surtout si votre candidat a évolué humainement depuis.

Enfin, la décision finale vous revient, souvent au ressenti, mais, il est nécessaire avant celà, de vous libérer des croyances qui n'ont rien à faire en milieu professionnel, et, surtout de ne pas douter de vos propres capacités à développer une atmosphère propice à la stabilité et l'équilibre de vos collaborateurs au sein de votre propre entreprise.

What is CABIN principle?

CABIN principle, created by Edouard Kombo, means Concrete ABstract INterface, it is the foundation of The Troll Inception framework. 

This principle comes from a personal understanding about the notion of an object in web developement.

We strongly believe that an object is only an interface implemented by an abstracted shape we can concretely use, nothing else, nothing more.
 
That means, a class that doesn't extends an abstracted class that implements itself an interface can't be considered as an object, you can call it a trait, a ghost, a shape or like anything you want, but not as an object.                    

What is RSSPOCOM?

RSSPOCOM is a contract defined by interfaces within the InterfaceFactory package developed by Edouard Kombo.
 
Based from the CABIN principle, it is a collection of generics and specifics interfaces that incorporate specifics and generics actions that can be used actually in every applications and projects.
 
The principle is that, each of these interfaces must be implemented once and only once in all of your abstracted files.
 
It helps working more friendly with DRY, SOLID and GRASP principles.
These are the generic actions behind RSSPOCOM principle:

1. Read/Write                        
2. Security
3. Set/Get
4. Pipo (PullIn/PullOut)
5. Open/Close
6. Communication
7. Origination
8. Movement

Présentéîsme professionnel, une fausse bonne idée.

La raison pour laquelle j'écris ces quelque lignes, est quelque peu personnelle, mais servira je l'espère, à révolutionner les mentalités.

Cet après-midi, ma compagne excédée par un sentiment de solitude me lance quelque reproches: "tu es tout le temps sur ton ordinateur, ta tablette, on communique de moins en moins, je suis d'accord que s'impliquer dans son avenir professionnel est primordial, mais la famille, ta femme, elle existe et je veux que l'on partage un peu plus de temps à deux. Je ne demande pas la lune, juste ta présence.".

Ce cri d'alarme résonna dans ma tête, m'amenant à une auto-réflexion par une vraie remise en question.
J'ai pris ma voiture et ai conduit une bonne heure, comme pour chercher l'évasion au coucher du soleil, avec les champs à perte de vue.
Ca faisait longtemps, je suis revenu plus frais, léger, humble, en équilibre mental, réalisant à ce moment là que je m'étais crée une bulle pleine de croyances que je confondais à l'adoption d'un caractère responsable et travailleur.

Mais alors, l'efficacité est-elle en partie une question d'équilibre?

Si en accordant un peu plus de temps à ce qui compte et dont j'ai besoin, je retrouve mon équilibre, alors cela veut dire que L'équilibre dépend d'une bonne gestion de ses ressources mentales dans le temps.
Ainsi, par définition, l'efficacité est la résultante d'un effort mental dans un temps imparti.

Par conséquent, l'overtime continu créerait donc un déséquilibre mental dans nos vies.
Ainsi, le présentéisme dans le sens où, il est caractérisé par une présence soutenue en milieu professionnel, au delà des heures prévues, doit être utilisé avec précaution.
Il ne s'agit pas de compter ses heures à la minute près, cette attitude serait anti-productive et presque associable.
Il s'agirait plutôt de savoir gérer son temps de manière intelligente pour ne pas créer un déséquilibre à retardement dans le futur.

Pourquoi?

1. Parce que vous n'embaucherez et n'accepterez jamais de collaborer en âme et conscience avec un déséquilibré à moins d'en être un vous même.

2. Parce qu'un collaborateur déséquilibré nuit au travail d'équipe et communique moins efficacement.

3. Parce que contribuer à l'équilibre de vos collaborateurs vous assure des collaborateurs plus sains, positifs, épanouis, fidèles, donc efficaces et surtout moins chers.

Pourquoi faire autrement?

Ok, peut-être êtes-vous un puriste assimilant avec vigueur le non dépassement d'horaires à un travail de fonctionnaire fainéant, n'ayant aucun intérêt pour son travail?
C'est peut être vrai, mais c'est peut être faux aussi, et cette particularité est le propre de la croyance.

Les croyances divisent, n'ont pas et ne doivent pas avoir leur place en milieu professionnel.

Le management de la montre, oui, mais avec précaution.

Le management dit de la montre consiste à exercer une pression psychologique sur le collaborateur, suscitant en lui la crainte de l'exclusion, et, l'incitant ainsi à s'investir plus longtemps au sein de l'entreprise.

Ce management est nécessaire, voir obligatoire, lorsque la livraison de résultats dans les temps impacte directement la santé économique de l'entreprise.
Toutefois, lorsque aucune urgence ou obligation ne se présente, la persistance de ce type de management peut conduire à créer un déséquilibre à retardement dans la vie des collaborateurs.


Enfin, je terminerais par deux citations personnelles.

Parce que l'efficacité ne peut se mesurer autrement que par le résultat d'une gestion du temps réfléchie, il n'y a ni sagesse, ni gloire à créer un déséquilibre de nos capacités mentales, et à aimer cela.
Cela s'appelle de la folie et la folie est une maladie mentale.

ILN (Intuitive Language Notation) configuration language

I really like YAML language for object configuration, but I was thinking about something more basic, something simpler, easy accessible without have to take some hours to completely learn a syntax.

I thought about a file extension, ILN for Intuitive Language notation.
The principle is simple, very simple for now.

When you have something inside a ILN config file:

db.driver: \TTI\DbUtil\PdoDriver
    __construct:
        hostname: localhost
        username: root
        password:
        database: test
        port: 3603

The first instruction is the alias of the namespace.
The second instruction separated by 4 spaces is mandatory the name of a method.
The other instructions separated by 4 spaces too, are the arguments of the method they're in, specified in the same order as in the real class.

If you have to comment some configurations, you just have to write like this:

#cache.driver: \TTI\CacheUtil\MemCache
#    __construct:
#        cache_hostname: xxxxx
#        cache_port: xxxx

You can add multiple dependencies for a driver:

db.driver: \TTI\DbUtil\PdoDriver
    __construct:
        hostname: localhost
        username: root
        password:
        database: test
        port: 3603
    setTable:
        name: blog

You can also include aliases like this:

db.driver: \TTI\DbUtil\PdoDriver
    setTable:
        name: %cache.driver%

You can also add type to variables like this:

db.driver: \TTI\DbUtil\PdoDriver
    setTable:
        name: array| 'table' => 'blog'

 
That's all for the moment.

But at this point, it is fully clear and easily reachable.
You are able to do some dependency injection, and use a service container in your application.

You can concretely use it with ILN Parser, you can download via composer:

require: "edouardkombo/parser-strategy": "1.0.0.*@dev"

I was thinking about adding some instructions later to handle Observer design pattern for events handling. It will come soon.

It is just a beginning, always in the spirit of having fun by coding our applications.

Thanks.

The Troll Inception - Objective Reality Php Framework

The Troll Inception is an objective reality php "solution" NOT A FRAMEWORK, based over the CSS (Code Similar Situations) principle, and a strict personal notion of object, all thought by Edouard Kombo.

Because you don't have to learn a framework, but only good development practices, TTI is not a framework, but a concentration of good practices made extremely intuitive and playful!

The initiative behind TTI was to rethink the notion of object based from the CABIN principle (http://le-code-vulgarise.blogspot.fr/2014/01/principe-cabin-pour-la-construction-d.html).
We truly believe a true object is only an interface, implemented by an abstracted shape you can concretely use. That's all!
That means, a concrete class that doesn't have a contract with an abstract class and an interface, can't be considered as real object, but rather as a trait, or "lost son", or anything else, but not as an object.

Based from this notion, we developed two powerfull collection of generic classes that is a standard base for true objects, and, that can be used in any of your projects to fully respect SOLID and GRASP principles.

"InterfaceFactory" and "AbstractFactory" collection of classes, are the heart of The Troll Inception solution.
AbstractFactory is a collection of abstracted classes that have very single responsibilities implemented by specifics and generic interfaces grouped in the InterfaceFactory.

Together, they offer powerfull possibilities and constraints for better closed development practices in your applications development.

Coupled with the CSS principle (http://le-code-vulgarise.blogspot.fr/2014/01/what-is-css-principle.html) and the Objective Reality (http://le-code-vulgarise.blogspot.fr/2014/01/what-is-objective-reality-design-pattern.html), TTI offers you a new generation of framework that can involve agile development.


The Troll Inception STORY (CSS and Objective Reality implementation)

You play Roar, a troll cave, lost in the Breeze forest by his stupidity. To survive, he has to conquer and dominate this forest.
Roar has several tools at its disposal, like a torch, a map, an eagle that will guide him to the best routes he can teleport to, via the magical portal, an ancestral passort...
The goal is to reach all routes and respond, to affirm your territory.
When Roar responds, he may beat the asian forest spirit, "Foucking Law".
Foucking Law has one powerful wild beast, CodeCeption, which will test Roar as many possible times, like a ghost.
Everytime Roar responds successfully to Foucking Law, he wins 5 Chicken points.

These points will help you estimate more precisely the technical debt a project will introduce.


How is it applicable?
 
You start to play with objective reality in the heart of your application, just by renaming variables as living objects or characters of the story telling.
This way, all the application you are designing, is easily printable in your subconscious mind.
You are playing with it, and it is now easier for other developers to play with it too.


How to download the Troll Inception Project?

Go on Github, just here: https://github.com/edouardkombo/TheTrollInception

What is CSS principle?

Before introducing you the CSS principle, it is extremely important not to confuse the CSS (Cascading Style Sheet) language, with CSS (Code Similar Situations) principle.


What is CSS Principle?

CSS principle means Code Similar Situations.
This principle has been introduced by Edouard Kombo, starting from the need to bring more creativity in applications code.

The theory is, if we can connect the code and the developer by its creativity, then we will no more learn, we will start playing with the code forever.


Why do CSS principe useful?
 
Because it is hard in very short development process to understand how to apply all necessary design patterns.

Because it is hard to fully capture in seconds, a complex code from someone else, or even from ourself, some weeks or months later.

Because too much complex code doesn't connect you with your passion, and makes you code bad.

Because it is hard for beginners and more experienced developers to intuitively appropriate themselves a complex architecture.

Because it is funnier to code something you can play with, and that will be easier for others, to intuitively understand and play with it too.


What do CSS principle recommend?
 
It recommends to URA (Understand, retain, apply) something, by inspiring yourself from a similar situation we've already seen or lived in real life (story telling, concrete experience, game, cartoon, movie...).


How do CSS principle can solve those problems?

Instead of simply coding instructions and objects, when you play with them, then you emotionnaly connect with your application and your job gets funnier, more pleasant and intuitively accessible by other developpers.

What is Objective Reality design pattern?

Objective Reality is the fact of coding real and funny situations, in an objective and professional goal.
It is a design pattern based over the CSS (Code Similar Situations) principle, that has also been thought by Edouard Kombo.


Concrete Example

Before, to open a file and send it by mail, you were coding like this:

$parser = new Parser();
$mail = new Mailer();

$file = $parser->open($file);
$mail->send($file);

Now, with Objective Reality design pattern, you should imagine a story and code like this:

$torch = new Parser();
$boomerang = new Mailer();

$file = $torch->open($file);
$boomerang->send($file);

Explanation

In the second example, you added a little bit of creativity in your code, that implies a story-telling creation.
That's it, with a story telling, you are now able to play with your code, and help other developers understand more easily the purpose of your instructions.

The structure of your program doesn't have to change, just rename the variables to begin openning a universe that could revolutionnate the way you develop applications and master it.


Advantages

When you play, you except to win something and earn a reward.

By example, you can establish within your team a reward board for every classes tested and developed that will help you estimate more precisely the technical debt of a project.

In all cases, developers will have the illusion to play with something, rather than building a complex architecture.


What kind of story telling to apply?

The goal of Objective Reality is not to apply fancy things to variables names.
There are rules to make it efficient.

The first and unique rule is to apply CSS (Code Similar Situations) principle.
It could be a movie you liked, a cartoon, a real life experience, it could be anything you imagine, but only a situation the largest number of people may have lived.

This will significantly facilitate code reuse of your applications.


To learn more about CSS principle, click here http://le-code-vulgarise.blogspot.fr/2014/01/what-is-css-principle.html.

Pourquoi les diplômes et l'expérience dans le web sont des pièges pour recruteurs old school?

Je vais essayer d'expliquer cet article assez simplement.

Pour savoir sur quelles bases recruter un profil dans le web, il faut avoir compris deux facteurs incontournables:

1. Le monde du web ne cesse d'évoluer et ce, très vite.

2. Le savoir nécessaire est disponible parmi des millions de sites web, et il ne cesse de se multiplier (le savoir).

Une fois ces principes compris, passons à table.

Des fois, je rigole lorsque des recruteurs disent "vous avez 10 ans d'expérience, mais pas bac+8, donc salaire de débutant, 32k€".

C'est imagé, mais révélateur d'un profond malaise et d'une exploitation maladroite et très risquée des compétences dans le milieu. 

Pourquoi?

Tout simplement, parce que:

1. L'expérience signifie uniquement qu'un candidat a su survivre et durer dans le métier, elle ne garantit absolument pas que le savoir acquis correspond aux besoins actuels du marché.

2. Le diplôme lui, atteste de connaissances théoriques à un temps t dans un monde à t+5, au sein d'écoles dans lesquelles, on conditionne souvent les élèves avec une doctrine "au bout de 3 ans, si vous n'êtes pas chef de projet, vous raterez votre vie".

Cette doctrine, assimilée au web est d'une débilité profonde et ne crée surtout pas des passionnés, qui eux contribuent à l'évolution de ce métier.

3. Le diplômé et l'expérimenté arriveront à un moment donné, si ils survivent, au même stade, apprendre les techniques modernes pour rester à jour.

Ce troisième point ammène à la solution finale, quel est le candidat web idéal?

Un candidat qui fait de la veille permanente et, qui est passionné, doit être la base de tout développeur, c'est le moteur de l'évolution.

Si ce candidat a de l'expérience professionnelle, c'est bien, cela garanti juste que le candidat s'est adapté aux enjeux des entreprises concernées, mais peut-être pas aux vôtres.

Si il utilise des frameworks, c'est mieux.

Si il s'exerce à côté, c'est encore mieux, c'est même excellent, cela prouve qu'il sort des sentiers battus et parfait ses connaissances en permanence.

Donc, il faudra le plus souvent prendre des risques avec des profils atypiques qui en veulent le plus, et comprennent mieux, plutôt que des profils qui ne font que ce qui est nécessaire sans contribuer autrement au métier, et à l'évolution de votre entreprise.

Le choix vous appartient.

Enfin, sur quoi baser les "prétentions salariales"?

Bon, cette question mérite un sujet à part, car lourde de sens.
J'ai crée un sujet qui en parle longuement ici http://le-code-vulgarise.blogspot.fr/2014/01/quelles-sont-vos-pretentions-salariales.html.
Mais, dans le monde du web, il est inutile de baser des rémunérations salariales sur les diplômes, au mieux, sur des certifications, car elles sont plus actuelles.

La prochaine fois, que vous recruterez dans le web, libérez-vous du poids des traditions, elles ne favorisent pas, dans la majorité des cas, une réflexion saine et juste.

Le marché des frameworks php est mort!

C'est vrai, le titre peut sembler assez terrifiant, mais il me semble, est terriblement vrai à l'heure où j'écris ces lignes.

Je ne dispose pas de chiffres officiels pour étayer mes propos, mais je tire ma thèse de faits que je constate.

Dans la sphère des frameworks, il y a deux leaders, Symfony et Zend, puis, des challengers (cakePhp, Laravel, Yii...), et puis il y a des espoirs, caractérisés par des centaines, voir des milliers de frameworks persos.

Mais pourquoi autant de frameworks disponibles?

Tout d'abord, il est primordial de redéfinir la notion de framework.
Un framework est littéralement une base qui propose des outils de travail, on peut l'apparenter à une malette. Cette malette permet, à plusieurs développeurs n'importe où dans le monde, de partager des outils commun, ce qui facilite la reprise de projets et l'adoption de bonnes pratiques de développement.

Cependant, si la seule utilisation des frameworks conçus par un petit nombre est la norme, aujourd'hui, de plus en plus d'alternatives se créent laissant émerger une nouvelle tendance... la création de son propre framework perso, qui répondrait à des problématiques plus personnelles, que les solutions existantes ne peuvent résoudre dans l'immédiat pour diverses raisons.

Comment se rendre compte de cette tendance? Une simple recherche google vous laissera découvrir des centaines, voir des milliers de frameworks déjà existant, et de nouveaux qui se créent chaque jour.

Nous observons ainsi, le signe de l'existence de développeurs créatifs à travers le monde, qui sont des détenteurs de problèmes, quels qu'ils soient, et, qui vont aujourd'hui penser par eux-mêmes, afin de trouver des solutions aux problèmes spécifiques qu'ils rencontrent.

Cette tendance multiplie les outils de travail, adaptés à la propre personnalité des détenteurs de problèmes, et sature le marché des frameworks php en particulier.

Pour preuve, au sein des entreprises, aucun framework ne remporte l'unanimité, chaque équipe choisit un framework en fonction de sa sensibilité, ce qui peut compliquer l'accessibilité à l'emploi de certains profils pour qui, il nécessiterait un investissement en temps de formation et d'apprentissage.

A mon avis, toute cette masse ne constitue pas une aide au métier, mais il est important de comprendre ce véritable appel à l'unité.
Plutôt que d'apprendre aujourd'hui un framework, il est devenu indispensable d'apprendre uniquement des bonnes pratiques communes, et, le faire de la manière la plus ludique possible, pour que le maximum de ces esprits créatifs puissent se retrouver dans ce nouvel outil commun et le partager plus aisément.

Ainsi, une nouvelle génération de framework est devenue incontournable, une génération caractérisée par une solution suffisamment fédératrice de ces énergies détentrices de problèmes particuliers pour harmoniser le marché.

C'est dans ce but que j'ai crée The Troll Inception, http://www.breezeframework.com.

Le but est de réunir toute cette énergie créatrice, tous ces détenteurs de problèmes, autour d'un principe simple, CSS (Code Similar Situations), et du design pattern Objective Reality, afin de réfléchir ensembles à l'avenir, sur comment faire d'une solution unique, un divertissement ludique.

Enfin, cette nouvelle génération de framework, serait, à mon sens, ni plus, ni moins, qu'une communauté de réflexion composée du maximum d'esprits créatifs.

Facebook veut-il concurrencer Git avec Mercurial?

Alors, pourquoi écrire ce sujet sur facebook et git?
Simplement, parce que je pense que c'est une actualité qui vaut son pesant d'or pour des passionnés de veille comme moi.

Jusque il y a deux ans, facebook, déjà présent sur Github, utilisait subersion comme CVS (Control Versioning System).
Mais voilà, avec une base de données ultra volumineuse de fichiers sources, à peu près 17 millions de lignes de code pour 44000 fichiers vérifiés, modifiés toutes les semaines, facebook avait besoin d'un cvs beaucoup plus puissant que Subversion.

Le choix, Git ou Mercurial?
Sachant qu'aucun de ces deux outils n'a la puissance nécessaire pour tenir de tels builds, le choix s'est tout de même porté sur Mercurial.
Les raisons sont encore inconnues, mais nos amis de chez facebook, ont beaucoup contribué à son amélioration.

Les stratégies?

1. Améliorer le système de reconnaissance d'update de fichiers.
Au lieu de parcourir tous les fichiers d'un repository afin de détecter les mises à jour de fichiers, ce calcul est réservé à un outil de monitoring, appelé watchman, qui est spécialement chargé de sauvegarder et stocker les modifications sur fichiers.
Cela engendre un gain en performance signifiant surtout sur des bases de données Big data, de la qualité de facebook.

2. La seconde solution d'optimisation consiste à la réduire le volume des données lors des opérations de clonage et de récupération, en n'utilisant que les dernières versions de build.
Les développeurs désirant récupérer des fichiers d'anciennes versions seront invités à les télécharger depuis le RFL (Remotefilelog), conçu également par facebook.

3. La dernière optimisation est plus subtile.
Le principal avantage d'un cvs, est de ne pas avoir recours à un serveur distant. Les fichiers de commit sont mis en cache grâce à remotefilelog, outil de mise en cache des commits crée par facebook.  De plus, facebook utilise sa distribution MemCache en frontal du serveur Mercurial, ce qui permet un backup immédiat en cas de chute de la plateforme.

Alors, l'avenir appartient-il à Mercurial, ou Github gardera t'il son monopole?

Quelles sont vos prétentions salariales? Ou comment manipuler maladroitement un candidat!

Ceci est un sujet qui me tient beaucoup à coeur car il concerne tout le monde, toutes professions confondues.

Personne ou presque, au cours d'un entretien d'embauche n'échappe à cette question fatale: "quelles sont vos prétentions salariales?".

La plupart des candidats, même les plus aguerris, répondent sans chercher à analyser plus profondément cette question, ils regardent la plupart des articles sur comment se tenir en entretien d'embauche, sans penser à être eux-mêmes et à penser par eux-mêmes.

Ils se mettent à jouer un rôle, qu'ils estiment souvent obligatoire, et tombent dans un piège, dans lequel, même le recruteur ne prend pas souvent conscience, car c'est une question encrée dans une tradition.

Maintenant, poussons la réflexion plus longuement.

Dans chaque métier, il existe des grilles salariales de référence en fonction de l'expérience d'un candidat. Les recruteurs, lorsque la nécessité d'une embauche est ressentie, réfléchissent à un budget à allouer à cette création de poste, et, ils ne l'estiment pas au hasard, ils étudient cette grille.

Ainsi, lorsqu'un recruteur demande à un candidat, quelles sont ses prétentions salariales, il a en fait le désir de collecter les espérances de vie de chaque candidat reçu en entretien, les catégoriser, pour ensuite procéder après étude, à l'enchère qualitative la plus basse à sa disposition (dans la grande majorité des situations).

Oui, vous me direz que çà a toujours été le cas, oui, vous me direz que c'est normal, que c'est le jeu, ne cherchons pas à compliquer ce qui est simple.

Je réponds non, ce n'est pas parce que c'est une tradition, que c'est parfaitement logique et acceptable.

Lorsqu'un jeu peut porter atteinte à la dignité humaine, il est habile et sage de savoir s'en sortir.

Parce que cette question en période de crise économique et crise humaine, contribue non seulement à la chute des rémunérations dans l'ensemble du métier concerné, et elle y contribue grâce à l'auto-dévaluation des candidats par la peur.

Tout d'abord, demander au candidat ses prétentions salariales sous-entend, qu'on le veuille ou pas, que ce candidat est prétentieux, par conséquent, cette question peut inciter le candidat à adopter une attitude non humble sans même s'en rendre compte. 

le fait est que, une prétention ne se demande, elle se clame !
On ne peut jamais donner une prétention, on la clame suite à une croyance personnelle, donc on ne réfléchit pas suffisamment.

Ainsi, ce jeu si il n'est pas compris, peut créer de l'humilition, parfois, sans même que le recruteur ne s'en rende compte, je le souligne.

Ainsi, il ne s'agit pas de demander au candidat une prétention salariale, mais plutôt de lui demander le résultat clair et précis d'une auto-estimation basée sur des faits concrets.

Mais pour s'auto-estimer, il faut des repères, un repère conjoncturel, combien je vaux par rapport au marché actuel, puis, le repère du pouvoir financier de l'entreprise, parce que toutes les entreprises n'ont pas les mêmes moyens, combien peut-elle offrir pour ce poste?

On ne peut donc clairement s'auto-estimer que si on connait la valeur de notre profil sur le marché, par rapport à la capacité financière de l'entreprise sur ce poste.

La vraie réponse, loin des conneries que l'on vous bassine sur des sites qui vous formattent à comment répondre en entretien d'embauche, la vraie réponse est de penser par vous même et de successivement:

1. Estimer clairement votre valeur par rapport à votre expérience et aux grilles pré-établies.

2. Demander à l'entreprise quelle fourchette a été prévue pour la création de ce poste, afin d'avoir une base plus réaliste et concrète de négociation.

Par ce biais, vous démontrez au recruteur en face de vous, que vous avez une réelle capacité de réflexion, qui n'est pas là forcément pour lui plaire, mais pour remettre les choses en ordre, dans le respect des deux parties.

Si il ne souhaite pas vous donner la fourchette prévue pour la création de ce poste, ce que je doute, c'est qu'il se place dans une possible position d'exploitation de vos ressources pour vous inciter à vous auto-dévaluer.

C'est un jeu, certes, mais chaque jeu a ses règles et les limites attenant à la dignité humaine, ne doivent et ne peuvent pas être franchies.

Le respect, l'humilité et la capacité de réflexion, sont des valeurs sûres à préserver en tout temps.

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.