DEV Community: Xavier Dubois 🇫🇷

How to create a MVP ?

Xavier Dubois 🇫🇷 — Wed, 07 Jun 2023 10:16:33 +0000

I made a small infographic to help startup and new comers to create an MVP.
Please tell me what you think about it !

How can I help you ?

Xavier Dubois 🇫🇷 — Wed, 31 May 2023 08:00:16 +0000

Hello dear beginners !

I want to get back to my previous love: helping you learning, make the good choices and grow as a healthy dev !

But I wonder HOW can I help you the best ?
Do you need articles ? Videos ? a newsletter with weekly tips and advices ?

Please, tell me what you think is the most valuable thing a 15+ XP dev/CTO/architect can do to help you !

A CMS with Stackbit, Netlify and NextJS

Xavier Dubois 🇫🇷 — Fri, 21 Apr 2023 13:46:55 +0000

French version:

Un CMS avec Stackbit, Netlify et NextJS

Xavier Dubois 🇫🇷 ・ Apr 21 ・ 5 min read

#tutorial #jamstack #cms #nextjs

Creating, hosting, and maintaining a CMS is not always an easy task.
We have a wide range of alternatives, each with its strengths and weaknesses.

Over the years and through various projects, I have implemented many of them: Wordpress, 100% custom CMS, Headless CMS with Contentful, Strapi... but I have never managed to meet all the criteria I was looking for:

Simplicity
Quick setup
Low hosting cost (or even none, completely free!)
Performant
100% customizable (there's nothing more frustrating than not being able to break free from the framework, right?)
With a custom domain
Retaining ownership of my data (hello Contentful!)
GDPR compliant
Easily integrating lambdas for form processing
I know, it seems demanding, but I'm used to custom development and I like offering my clients a no-compromise solution.

I quickly became interested in JamStack, as it seemed that many of my criteria were met, but I hadn't yet figured out how to manage it professionally.

Understanding JamStack Architecture

The term "Jamstack" is an acronym for JavaScript, APIs, and Markup.
The main advantage of this architecture is that it eliminates the need for servers, which provides us with more security, performance, and easier content updates.

Thanks to static content generation, we don't even have to manage a database. Everything is versioned by Git, simplifying backup and history strategies, and even allowing us to precisely identify who made a change.

Stackbit

Stackbit is a SaaS service that facilitates the rapid creation of Jamstack sites, directly versioned on our Git repository.

The major asset of this service lies in its content management interface. The Stackbit Studio offers the ability to build a user interface intuitively while providing deep customization of elements. This allows editorial teams to manage content autonomously.

In addition, it offers a lot of customization, directly from the IDE and allows for easy tailoring.

Netlify

By default, Stackbit is capable of hosting the CMS, either with a custom domain or via a Stackbit subdomain.
However, I find their pricing too high ($90/month at the time of writing this article), and you must subscribe to the paid plan to benefit from a custom domain (among other things).

I also needed to have control over certain Netlify elements, such as functions.

Stackbit allows, in the site configuration, to choose whether it should manage hosting or not.
I configured my project on Netlify to automatically publish any commits to the "main" branch of my CMS.
And, since Netlify allows for a free custom domain, I was able to change the APEX of my site in seconds.

Setting up the stack

Creating the NextJS project is extremely simple and fast. I chose to let Stackbit do it.
I just had to choose the technology I wanted to use and a base theme.
Stackbit stored the project on my GitHub and automatically deployed the site to one of its Netlify instances.

In a matter of seconds, I had the following stack:

A NextJS project
A static site with my pages and data stored in Markdown
A content editing interface directly on Stackbit
A versioned project
A site visible online on a Netlify subdomain

Configuring Netlify

As I want to host the site on a Netlify that I have complete control over, I added the project to my Netlify account and configured it.
Here too, it's really fast!
So, from the Netlify interface:

Import an existing project from a Git repository
Connect to your Git provider
Choose your project
Configure it as follows:
Add the NETLIFY_NEXT_PLUGIN_SKIP environment variable set to true
Deploy
Configure a custom domain if necessary
Configure Stackbit not to manage hosting directly in the Studio settings

Customization

Now that we have an initialized and hosted project, we need to be able to customize it to check all the boxes.

For this, Stackbit, once again, makes it easy for us.
The site structure is based on pages composed of sections (blocks).
Each page is based on a layout (a predefined set of sections).

We will focus on creating a Section, more specifically creating the error section.

In the CMS, I need to give the editorial team control over the text on the 404 page.
The module, very simple, thus allows to define:

The page title
The H1
The H2
The descriptive text

For this, we first need to create the YAML configuration file, .stackbit/models/ErrorSection.yaml:

type: object
label: Error Section
name: ErrorSection
extends:
  - Section
groups:
  - sectionComponent
fields:
  - type: string
    name: title
    label: Title
    required: true
  - type: string
    name: subtitle
    label: Subtitle
    required: true
  - type: string
    name: text
    label: text
    required: true

Then we create the NextJS component (simplified here to its maximum):
src/components/sections/ErrorSection/index.tsx:

import * as React from 'react';
import Picto from "../../atoms/Picto/Picto";

export default function ErrorSection(props) {
    return (
        <div className="container p-64 flex flex-col md:flex-row items-center justify-center px-5 text-gray-700">
            <div className="max-w-md">
                <div className="text-5xl font-dark font-bold">{ props.title }</div>
                <p
                    className="text-2xl md:text-3xl font-light leading-normal"> { props.subtitle }</p>
                <p className="mb-8">{ props.text}</p>
            </div>
            <div className="max-w-lg">
                <Picto
                    className={"cat"}
                    icon="cat"
                />
            </div>
        </div>
    );
}

Finally, we need to add the section to the components registry:
src/components/components-registry.ts:

const components = {
    // ...

    'ErrorSection': dynamic(() => import('./sections/ErrorSection'))
};

And that's it, our section is now visible in our sections library:

Create a page

We will now create the "not found" page from the Stackbit interface and add our section. The following file will be generated.

content/pages/page-not-found.md:

---
layout: PageLayout
title: "Not Found"
sections:
  - type: ErrorSection
    title: '404'
    subtitle: '...Page not found'
    button: 'Home'
    text: 'We are sorry, it seems you are trying to access a page that does not exist or is no longer available'
---

Since we have created a 404 page, we might as well tell Netlify to use it.
To do this, add the following block to the netlify.toml file:

[[redirects]]
   from = "/*"
   to = "/page-not-found"
   status = 404

Going further****

And since we're using the NextJS framework, we can do pretty much anything we want.
If you want to have internationalization, install the next-i18next or react-intl packages (even though I believe Stackbit has a simpler built-in approach).

Un CMS avec Stackbit, Netlify et NextJS

Xavier Dubois 🇫🇷 — Fri, 21 Apr 2023 13:12:35 +0000

English version

A CMS with Stackbit, Netlify and NextJS

Xavier Dubois 🇫🇷 ・ Apr 21 ・ 5 min read

#tutorial #cms #nextjs #jamstack

Créer, héberger et maintenir un CMS n'est pas toujours une chose facile.
Nous avons à notre disposition un grand nombre d'alternatives avec leurs points forts et leurs points faibles.

J'ai, au fil des années et des projets, implémenté pas mal d'entre eux. Wordpress, CMS 100% custom, Headless CMS avec Contentful, Strapi ... mais je n'ai jamais réussi à réunir tous les critères que je cherchais :

Simplicité
Rapidité de mise en place
Faible coût d'hébergement (voire aucun, totalement gratuit !)
Performant
100% personnalisable (il n'y a rien de plus frustrant que de ne pas pouvoir sortir du cadre, non ?)
Avec un domaine personnalisé
En gardant la propriété de mes données (coucou Contentful !)
Respectant le RGPD
Pouvant intégrer facilement des lambdas pour traiter les formulaires
Je sais, cela semble exigeant, mais je suis habitué au développement sur-mesure, et j'aime offrir à mes clients une solution sans concessions.

Très rapidement, je me suis intéressé à la JamStack, il me semblait que beaucoup de mes critères étaient respectés, mais je n'avais pas encore trouvé comment gérer cela de manière professionnelle.

Comprendre l'architecture JamStack

Le terme "Jamstack" est un acronyme pour JavaScript, APIs et Markup.
Le gros avantage de cette architecture est de se passer de serveurs, ce qui nous offre davantage de sécurité, de performance et facilite la mise à jour du contenu.

Grâce à la génération de contenu statique, nous n'avons même pas de base de données à gérer. Tout est versionné par Git, simplifiant aussi la stratégie de backup, d'historique et nous permet même d'identifier précisément qui est à l'origine d'une modification.

Stackbit

Stackbit est un service SaaS qui facilite la création rapide de sites Jamstack, directement versionnés sur notre dépôt Git.

L'atout majeur de ce service réside dans son interface de gestion de contenu. Le Studio Stackbit offre la possibilité de construire une interface utilisateur de manière intuitive, tout en offrant une personnalisation approfondie des éléments. Cela permet aux équipes de rédaction de gérer le contenu en toute autonomie.

En outre, il offre énormément de personnalisation, directement depuis l'IDE et permet d'aller vers le sur-mesure très facilement.

Netlify

Par défaut, Stackbit est capable d'héberger le CMS, que ce soit avec un nom de domaine personnalisé ou via un sous-domaine stackbit.
Néanmoins, je trouve leur tarification bien trop élevée (90 $/mois à l'heure où j'écris cet article) et il faut souscrire à l'offre payante pour bénéficier d'un nom de domaine personnalisé (entre autres).

Aussi, j'avais besoin d'avoir la main sur certains éléments Netlify, comme les fonctions.

Stackbit permet, dans la configuration du site, de choisir s'il doit gérer, ou non, l'hébergement.
J'ai donc configuré mon projet sur Netlify pour qu'il publie automatiquement tout commit sur la branche "main" de mon CMS.
Et, comme Netlify permet d'avoir un domaine personnalisé gratuitement, j'ai pu modifier l'APEX de mon site en quelques secondes.

Mise en place de la stack

La création du projet NextJS est ultra simple et rapide. J'ai fait le choix de laisser Stackbit le faire.
J'ai juste eu à choisir la techno que je souhaitais utiliser ainsi qu'un thème de base.
Stackbit a stocké le projet sur mon GitHub et a déployé automatiquement le site sur une de ses instances Netlify.

En quelques secondes, je me retrouve avec la stack suivante :

Un projet NextJS
Un site statique avec mes pages et données stockées en Markdown
Une interface d'édition de contenu directement sur Stackbit
Un projet versionné
Un site visible en ligne sur un sous domaine netlify

Configuration de Netlify

Comme je souhaite héberger le site sur un Netlify sur lequel j'ai totalement la main, j'ai ajouté le projet sur mon compte Netlify et je l'ai configuré.
Ici aussi, c'est vraiment rapide !
Ainsi, depuis l'interface Netlify:

Importez un projet existant à partir d'un dépôt Git
Connectez-vous à votre fournisseur Git
Choisissez votre projet
Configurez-le comme ci-dessous:
Ajoutez la variable d'environnement NETLIFY_NEXT_PLUGIN_SKIP définie sur true
Déployez
Configurez un nom de domaine personnalisé si nécessaire
Configurez Stackbit pour ne pas gérer l'hébergement directement dans les paramètres du Studio

Personnalisation

Maintenant que nous avons un projet initialisé et hébergé, nous devons être en mesure de le personnaliser pour cocher toutes les cases.

Pour cela, Stackbit, encore une fois, nous rend la chose aisée.
La structure du site repose sur des pages constituées de sections (blocs).
Chaque page est basée sur un layout (un ensemble de sections prédéfini).

Nous allons ici nous intéresser à la création de Section, plus précisément à la création de la section d'erreur.

Dans le cadre du CMS, j'ai besoin de donner la main à l'équipe de rédaction sur le texte de la page 404.
Le module, très simple, permet donc de définir :

Le titre de la page
Le H1
Le H2
Le texte déscriptif

Pour cela, nous devons d'abord créer le fichier YAML de configuration, .stackbit/models/ErrorSection.yaml:

type: object
label: Error Section
name: ErrorSection
extends:
  - Section
groups:
  - sectionComponent
fields:
  - type: string
    name: title
    label: Title
    required: true
  - type: string
    name: subtitle
    label: Subtitle
    required: true
  - type: string
    name: text
    label: text
    required: true

Puis nous créons le component NextJS (simplifié ici à son maximum):
src/components/sections/ErrorSection/index.tsx:

import * as React from 'react';
import Picto from "../../atoms/Picto/Picto";

export default function ErrorSection(props) {
    return (
        <div className="container p-64 flex flex-col md:flex-row items-center justify-center px-5 text-gray-700">
            <div className="max-w-md">
                <div className="text-5xl font-dark font-bold">{ props.title }</div>
                <p
                    className="text-2xl md:text-3xl font-light leading-normal"> { props.subtitle }</p>
                <p className="mb-8">{ props.text}</p>
            </div>
            <div className="max-w-lg">
                <Picto
                    className={"cat"}
                    icon="cat"
                />
            </div>
        </div>
    );
}

Enfin, nous devons ajouter la section au registre de composants:
src/components/components-registry.ts:

const components = {
    // ...

    'ErrorSection': dynamic(() => import('./sections/ErrorSection'))
};

Et c'est fait, notre section est maintenant visible dans notre bibliothèque de sections :

Créer une page

Nous allons maintenant créer la page "not found" depuis l'interface Stackbit et y ajouter notre section. Le fichier suivant sera généré.

content/pages/page-not-found.md:

---
layout: PageLayout
title: "Not Found"
sections:
  - type: ErrorSection
    title: '404'
    subtitle: '...Page non trouvée'
    button: 'Accueil'
    text: 'Nous sommes désolé, apparement vous essayez de consulter une page qui n’existe pas ou n’est plus disponible'
---

Puisque nous avons créé une page 404, autant indiquer à Netlify de l'utiliser.
Pour cela, il faut ajouter le bloc suivant au fichier netlify.toml:

[[redirects]]
   from = "/*"
   to = "/page-not-found"
   status = 404

Aller plus loin

Et comme nous utilisons le framework NextJS, nous pouvons faire à peu près tout ce que nous voulons.
Si vous souhaitez avoir de l'internationalisation, installez les packages next-i18next ou react-intl (même si je crois que Stackbit a une approche plus simple built-in).

Benevolent code review

Xavier Dubois 🇫🇷 — Wed, 09 Mar 2022 23:45:09 +0000

Doing a code review is an exercise that seems fairly uncomplicated at first glance. After all, it's just reading code and pointing out anything we think isn't right, right?

But we often forget that very often we find ourselves on the other side of the mirror and that it is our code that is being audited. It is the fruit of our labor that is the center of attention of our peers.
And, depending on the level of benevolence of our colleagues, the exercise can suddenly become much less comfortable!

The word is out (well, you already had it in the title of the article!): we are of course going to talk about benevolence, mainly in the field of code review.
Why mainly? Quite simply because in my opinion benevolence should be the basis of any interaction with our colleagues on a daily basis, regardless of the context!

Let's start by listing our personas, they will be our guinea pigs throughout this article.
We have:
Junior, our junior who has 2 years of XP in the code. He has just left school and is very very motivated
Chrichri, our lead dev, an old timer with 15 years of XP
Our senior dev team, the no-names. The brute force of our team

Captain Obvious

We are going to start by pointing out what should be obvious, what should be one of the first things that our engineering schools teach us.
This evidence is a truth that must be accepted as quickly as possible in order to successfully experience the exercise of code review.

Come on, enough suspense: “We are not our code”.

It may sound silly, but it's true. If so yes.
Our code is the result of a combination of circumstances, it depends on (and this is a non-exhaustive list!):
Our knowledge at the time T when we wrote it
Context (Was the environment noisy? Did we have a 3-year-old child in our legs because we have all been confined for months?)
The time we had to allocate to this feature (we see you project managers)
From the existing codebase
The quality of the coffee at our disposal (or tea, or beer)

There is also another argument that I find essential in favor of the dissociation of the man and the artist (well, of the coder and his code what): we are much more thing in life than a simple piece of code, and even if having the stamp of our colleagues is a real pleasure for the ego, it is important to keep a distance and put things into perspective.

I am a benevolent reviewer

Take into account the level of XP
The code written by our friend Junior should not be evaluated under the same spectrum as that written by Chrichri. We cannot have the same level of requirement simply because they do not have the same technical background.

Our comments must therefore reflect this distinction.
Be careful, I'm not saying that on the pretext that a junior dev wrote the code so you have to let everything pass. No, I'm saying we can approach things differently.

Chrichri will undoubtedly be able to welcome a comment that is straightforward, with little context, and that goes straight to the point, like the example below. This does not prevent precision and benevolence, just we can afford to develop the message less.

On the other hand, when Junior wrote the same code then we can surely take the time to detail our approach. Explain to him the interest of using a translation file for his character strings, for example.

The imperative you shall not use

You have seen it on the examples above I used the conditional to express my comments.
The reason is that 90% of the time my comments are suggestions, not orders.
Of course, if I see a bug then I would use a different wording to clearly convey the imperative side of the change, but this is the only case where I will allow myself that.

The comment that we put is above all there to help our valiant developer to initiate a reflection, even a discussion, and I am absolutely convinced that it is impossible if we give orders!

And then, I don't know about you, but I will very very quickly be annoyed if my dev friends spend their time telling me what to do and how to do it ;-)

Source?

Let's put ourselves in situations:
Junior, our beloved junior, submitted a PR regarding a feature that generates statistics for a country on the 1st of every month.
He wrote a “getStatsForPastMonth” method which takes the ID of a country and a date as parameters.
The prototype is therefore the following (sorry for the less technical among you):
public function getStatsForPastMonth(int $countryId, DateTime $fromDate)

In the review, of course Chrichri will ask him why he felt the need to integrate the second parameter, since the business specification indicates that we work on a fixed date.

Junior replies that he did this to make it possible to write unit and functional tests that are repeatable regardless of the day the test is run (let's all take a moment to congratulate Junior for integrating tests and thinking about their reproducibility!).

Chrichri therefore finds himself here with a choice. He can respond to the choice:

“You shouldn't change your method to make testing easier. You have to remove the $fromDate parameter and mock the date instead”
“You shouldn't change your method to make testing easier, that's really not good practice. You should use a mock instead. Here is a link to the library I have in mind and an example I have already written on such a project. On the other hand, you will have to modify the way in which you instantiate such a variable because it will not be compatible”

In your opinion, which choice will allow Junior to improve his skills and correct his code with the least amount of back and forth possible?
The question was quickly answered, especially since it took Chrichri a few more minutes at most, and saved Junior hours of migraine!

I have voluntarily taken the example of Junior here because it is easier, but nothing prevents us from having this kind of feedback with all the developers of course. The goal of a code review is to help others progress and not just to ensure the quality of the code base.

Don't be so negative!

It's harder to compliment than to criticize, and that's a shame.
This paragraph will be very short. It boils down to telling you that I love you. And that you shouldn't hesitate to tell your colleagues, especially during a code review.

Let him know that you find his implementation super cool or that you learned something. It boosts the ego and it is as good for the one who wrote the comment as for the one who will read it.

Love yourself, damn it!

I'm a happy developer

Now let's try to ask ourselves how, as developers, we can better experience code reviews.

We are never better served than by ourselves!

I have a reputation for being lacking in rigor. Not necessarily in my code, but often in the sidelines (document, swagger annotations, typos …) and that made me dread code reviews.
Then I was given a great piece of advice: take the time to do my own code review.

I take about ten minutes to read my code, but not in my IDE, no, directly on Github or Gitlab. It allows me to change perspective and spot mistakes much more easily.
And, generally, this proofreading allows me to save a lot of time that I would have lost processing feedback (and feeding my impostor syndrome to the detriment of my ego).

Make life easier for the reviewer

There's nothing like being in a bad mood starting a code review than having no idea what it's about, having to look up the ticket on Jira and then having to figure out how to make that damn piece of code work on your own. !

Always take the time when writing a PR to think about how our peers will be able to work effectively.
So take the time to include a description containing the essentials to understand the business and be able to test the code functionally.
It's not about order
I know, I've said it before. And no, I'm not rambling.

The reviewer has made a lot of feedback, preferably with a benevolent tone (but he may not have read this article!) and you tell yourself that, indeed, a lot of his feedback is well-founded.
But, and we all know it, the life of a developer is not only governed by our desire to do well. There is a reality of projects, deadlines, ticket estimates… in short, we don't always have time to do everything.
Or maybe you think not, his comment telling you that you should rather name your variable $foo when $bar suits you perfectly is not justified.

If you are in this situation then I have a very, very important thing to tell you. This is a secret that has been too well kept until now.
You have the right to say no. Yes yes, you read correctly. It is completely ok to say no to a return on a PR.

Of course, I do not advise you to answer a "no" as an answer but on the contrary to accept this invitation to the discussion by explaining, briefly, why you think that it is a mistake, or why you think your way is better.

On the other hand, if your only argument is the time that the fix will take you, then you have to be careful. Putting it off often means never fixing it. I can only advise you too much to talk to your project manager to find the time you need. After all, project managers are empathetic, benevolent beings who only think about your well-being and your happiness, so everything should be fine. But that is a topic!

Ask for help

Whether you are a junior or not, you have to know how to ask for help, and this applies perfectly to benevolent code review.
If the return seems insurmountable to you or you have no idea how to do what you are asked to do, then do not hesitate to ask for help. It can be a point for the person who gave you the feedback to explain to you what he has in mind or downright a pair-programming session to help you implement it.

You can also request that the review be done directly in pair-programming. Very often, this saves a lot of time and makes the exercise much more humane.

I want to end this love-filled article by inviting you to remember that we all do our best. Whether it's the proofreader or the proofreader, we all make mistakes and we always will.
Let's be indulgent and kind with others, of course, but especially with ourselves

ESN, agence, client final: comment choisir ?

Xavier Dubois 🇫🇷 — Mon, 08 Feb 2021 14:10:12 +0000

This post will only exist in French since this topic is only relevant for French developers on the French job market ;-)

Nous, les devs, nous avons énormément de chance: nous avons le choix.
Nous avons le choix de la techno, de travailler en présentiel ou en remote mais aussi du type d'entreprise pour lequel nous travaillons.
Ce n'est pas donné à tout le monde d'avoir autant de liberté quant à sa carrière et l'orientation que nous lui donnons.

Mais, comme Oncle Ben le dit si bien:

Il n'est pas toujours simple de s'y retrouver dans l'informatique, les technos évoluent très vite et le marché de l'emploi est un panier de crabe; il y a presque autant de recruteur IT que d'offre d'emploi, et ils ne sont pas tous de bon conseillers.

Le monde du développement se découpe en 3 secteurs:

Les ~~SSII~~ ESN (Entreprise de Service du Numérique)
Les clients finaux
Les agences (digitales, WEB, marketing ...)

Chaque secteur offre une expérience bien différente du métier de dev, autant par le quotidien que l'on y trouve que par les rémunérations ou l'ambiance générale.

Je précise dès maintenant que cet article est basé sur mon expérience personnelle et sur celles de mes connaissances.
Bien sûr, cela n'est pas vrai pour toutes les entreprises du secteur (et encore heureux !) et tu peux toi même avoir vécu une expérience totalement différente ! Je t'invite à venir en discuter en commentaire si c'est le cas.

Les ESN (Entreprise de Service du Numérique)

Je commence par le secteur le plus controversé par mes paires; le monde impitoyable de l'ESN (ou SSII, si t'es ~~vieux~~ vrai).
Les ESN externalisent leurs compétences en expertise informatique en envoyant (majoritairement) leurs devs en missions, plus ou moins temporaire, chez des clients.

Le but du jeu pour le client c'est d'avoir une ressource opérationnelle immédiatement sans avoir à assumer le coût à long terme de la dite ressource.

Double XP

Le plus gros avantage de l'ESN c'est l'expérience.
L'essence même des entreprises de service est de proposer des missions courtes (de quelques mois à quelques années max), ce qui fait que tu vas avoir l'opportunité de travailler avec de nombreux clients différents.
Et chaque client possède sa propre stack technique, son propre métier et ses propres contraintes.

Tu dois donc, à chaque changement de mission, te réapproprier le projet et donc apprendre de nouvelles choses.

Alors, bien sûr, l'ESN, dont le principal but est la rentabilité maximum, va essayer de capitaliser sur tes expériences précédente (si tu as fait du bancaire, tu risque fort de continuer à en faire) mais préfèrera tu proposer une mission totalement différente que de te laisser en inter-contrat.

Rémunération

L'ESN est réputée pour mal payer ses devs (cf objectif rentabilité), mais ce n'est pas la dernière du classement pour autant.
La rémunération est calculée en fonction des diplômes, des compétences et de l'expérience.
De mon expérience, il ne faut pas trop compter sur les primes annexes (participation & co) pour faire monter sa rémunération, et la négociation annuelle demande énormément de préparation pour aboutir à une augmentation substantielle. Pourquoi ? Car pour continuer à être rentable l'ESN doit répercuter ton augmentation aux clients. Et ça, c'est pas toujours simple !

Les recruteurs tentent d'attirer les devs (surtout les plus juniors) avec les "à côtés".
Comprendre que, comme il s'agit de boite brassant pas mal d'argent et ayant en générale d'autres activités lucratives, ils ont des locaux assez moderne et sympa.
Et comme tu risque de passer un peu de temps sur le "plateau" (en mission ou inter-contrat dans les locaux de l'ESN directement et pas dans ceux du client).

Alors oui, c'est cool d'avoir un babyfoot, une cafétéria, des massages, une conciergerie, un open space ultra moderne, des trotinettes en libre service dans les locaux ou encore des meet-up dans tes propres bureaux (ok, ça c'est vraiment cool !), mais ... ça ne permet pas de mettre du pain sur la table !

Évolution

C'est compliqué, toujours à cause de cette satanée rentabilité !
Former un employé, peu importe son secteur, c'est accepter d'investir dans l'employé et d'avoir une période où cet employé ne rapporte pas d'argent, vu qu'il est en formation.
Et, même une fois formé, il faut un temps de montée en compétence avant d'espérer un retour sur investissement.

Seulement, l'ESN a davantage intérêt à te garder en mission le plus souvent possible, c'est son seul moyen de faire de l'argent.
Et si on ajoute à ça le turnover important en ESN, il n'y a pas vraiment d'avantage à offrir des formations (sauf si c'est pour signer une mission et ... te vendre en tant qu'expert sur la techno que tu ne connais pas encore, bien sûr !)

It's a trap !

Oui, l'ESN c'est Double XP, mais il faut être prudent.
Il y a loup, une bête du Gévaudan, un piège !

Tous (ou presque) la redoute, et, une fois attrapé il est difficile d'y échapper !

Je veux parler de la TMA (Tierce Maintenance Applicative) !
Késako ? De la maintenance évolutive (ou pas), souvent pour de très très grosses boites (SNCF, Orange, EDF ...) qui ont des parcs applicatifs aussi vieux qu'énorme.

Le problème c'est qu'une fois qu'on est montée en compétence sur ces applications (legacy ou non) il est difficile de faire autre chose, car le principe même de la TMA est d'avoir des ressources opérationnelles disponible en tout temps pour réagir dans le délai imparti en cas de problème en prod.

Et, trouver un nouveau CDI après avoir stagner pendant des années sur des applications legacy, ça peut vite devenir compliqué !

Client final

Un client final est appelé comme ça car il s'agit du client des ESN. C'est lui qui va payer ces boites pour avoir des devs de manière ponctuelle (ou pas).
Mais certains préfèrent avoir une équipe en interne, soit car ils ont une croissance exponentielle et payer une ESN ne serait pas viable, soit car ils ont compris qu'internaliser son métier n'était pas une si mauvaise idée.

Tu as 3 catégories de client final:

La startup
L'éditeur
l'entreprise classique

Chacune de ces catégorie peut offrir une expérience légèrement différente (surtout la startup), mais, dans l'ensemble les avantages et inconvénients sont assez semblable.

Maitre Jedi

Autant en ESN tu risque de rester un Padawan sur plein de sujet car tu n'a pas le temps de devenir un expert sur un techno en particulier, autant tu va vite devenir un Maitre Jedi chez le client final.

En effet, si le CTO de la boite est compétent, il est fort à parier qu'il capitalise sur les techno déjà implémentées pendant quelques années, au moins le temps d'avoir un bon retour sur investissement.
Ce qui signifie que tu va avoir le temps d'apprendre les tenants et aboutissants de la stack technique.

Bien sûr, tu peux te dire qu'au bout d'un moment, travailler sur le même projet peut devenir rébarbatif, hein ?
Et tu aurais raison, même si cela n'est pas toujours vrai et dépend grandement du client.

Si tu rejoins une boite en pleine croissance, il y a fort à parier qu'une refonte soit à l'ordre du jour pour suivre la croissance.
Dans le cas d'une startup, selon quand tu rejoins l'équipe, tu peux avoir à gérer un changement de pivot, ou une levée de fond et, par conséquent un séisme technologique !

Rémunération

Contrairement à l'ESN le client final investi dans son équipe. Son but, c'est de te conserver dans ses effectifs pour ne pas avoir à perdre du temps (et de l'argent) dans la formation d'un newbie, avec la perte obligatoire de compétence entre les deux devs.

Du coup, même si le salaire de base n'est pas forcément importante, c'est un sujet qui peut vite évoluer, et la discussion est généralement assez ouverte sur le sujet.

Il n'est pas rare dans une boite en pleine croissance de prendre 10% par an, ce qui n'est pas négligeable !

Évolution

C'est peut être le meilleur des mondes pour évoluer, tant que tu es compétent.
Chez le client final il y aura de gros challenge techniques à relever. Souvent.
A la clé, il y a la possibilité d'évoluer dans l'organigramme.

Si la croissance de l'entreprise est à deux chiffre, il y a fort à parier que l'équipe va grandir. C'est l'occasion de décrocher une place de Lead dev, de Product Owner ou même de CTO si tu rejoins l'entreprise assez tôt dans son développement.

It's (still) a trap !

Bin oui. C'est pas le monde parfait non plus !

Chez le client final, il y a aussi des pièges à éviter, et en plus, ils peuvent se déguiser en avantage, alors il faut vraiment être prudent !

Oui, on peut facilement gratter une très bonne rémunération, mais ce n'est pas toujours le meilleur plan.
Déjà, une trop grosse rémunération peut cacher une impossibilité d'évoluer dans l'entreprise. "On sait que tu es compétent, on le reconnais via ton salaire, mais nous ne pouvons rien t'offrir de plus".
Et, si ce constat devait t'arriver, un second écueil apparaitra: comment se vendre au même prix chez une autre entreprise, sachant que tes compétences ne seront pas forcément aussi utiles et reconnues ?

Un autre piège c'est de s'enfermer dans une techno sans voire que celle ci est en train de mourir.
Elle peut être le coeur de métier pour ton entreprise, mais si cette dernière n'a pas pris le virage technologique, et que, toi, pris dans le confort du quotidien tu n'as pas continuer ta veille quotidienne, alors tu peux te retrouver à faire du COBOL dans un monde régit par Javascript et son armée de frameworks !

Les agences

Je dois confesser avoir une (petite) préférence pour les agences.

C'est un peu de meilleur des deux mondes, un savant mélange entre ESN et client final.

Enfin, ça, c'est la théorie, dans les faits la réalité n'est pas toujours aussi rose !

Comme pour les clients finaux il y a plusieurs catégories d'agences:

Les agences de communication (ou "digitales", c'est à la mode)
Les agences WEB
Les ESN qui s'assument pas

Je ne vais pas parler de la dernière catégorie, elle est assez facile à détecter lors du premier entretien: 90% des missions sont en régie chez le client !.
Non, je vais me concentrer sur les 2 premières.

Agence Marketing / de communication/ digitale

Les agences de communications sont très centrés sur des projets avec assez peu de technique et de problématique métiers.
L'objectif de l'équipe IT d'une agence de communication est d'offrir une offre complète: une expertise marketing et une mise une expertise opérationnelle.

Le plus gros avantage est qu'on y travail souvent avec des clients prestigieux (et je parles des mastodontes SNCF, EDF et Orange comme le ferait un recruteur, mais de clients à forte réputation, comme Dior, Nike ou l’Élysée).
On apprend donc forcément énormément et les projets demandent souvent une grande rigueur, car il en va de l'image de la marque.

L'inconvénient c'est qu'il s'agit souvent de site vitrine ou événementiel. Parfois un peu de e-commerce, mais c'est pas si répandue.
Du coup, on peut vite s'ennuyer techniquement, mais c'est une expérience intéressant et très formatrice.
La qualité WEB est un acquis qui te différenciera de la concurrence !

Les Agences Web

Le mélange parfait entre client final et ESN !
Une (grosse) dose d'expérience et de clients différents et une aussi grosse dose de valorisation de la part de ton employeur !

L'agence WEB est, comme son nom l'indique, spécialisée dans le monde du WEB (mais, soyons honnête, mis à part l'embarqué, presque tout est "web" aujourd'hui) et a un fonctionnement très proche de celui d'une ESN: elle intervient ponctuellement pour répondre à un besoin.
La différence ? L'agence WEB garde ses compétences en interne (majoritairement) et mise sur un turnover réduit.

En effet les agences WEB ont tendance à essayer de faire "grandir" ses équipes et d'investir dedans afin d'agrandir son catalogue des possibles.

Formation

Forcément, qui dit investir dans ses équipes signifie qu'il est possible d'obtenir des formations assez facilement.
La rentabilité et les journées non facturées sont ici aussi des enjeux stratégique, mais la volonté d'obtenir plus d'investissement et de compétences d'un employé prends souvent le dessus.

Qui plus est, l'attrait de devenir un organisme de formation certifié encourage pas mal d'agence à faire profiter leurs employés de nombreuses formations afin de pouvoir capitaliser doublement dessus.

Rémunération

Ici on retrouve pour moi les mêmes avantages que pour les clients finaux. Le salaire de base n'est pas forcément fou, mais il est possible de faire évoluer sa rémunération au fil des années.
Néanmoins, le fait d'avoir un fonctionnement aussi proche de l'ESN remet sur la table un inconvénient de taille: toute augmentation doit être répercutée chez les clients pour espérer être rentable.

Il faut donc avoir des nouvelles compétences à proposer pour convaincre !

Évolution

Cela dépend grandement des agences.
Celles qui privilégie l'intraprenariat peuvent offrir un éventail d'évolution infini et réunissent tous les éléments nécessaire pour t'emmener très loin.

Mis à part cela, il y a très peu d'évolution interne, mis à part pour des rôles de lead ou d'archi. Par contre, d'un point de vue expérience l'agence est aussi riche que l'ESN !

Is it still a trap ?

Il y a forcément des pièges.
Le plus important, et cela est aussi vrai pour les ESN par ailleurs, c'est l'investissement que l'on te demande.
Les deadlines sont importantes et les sprint souvent chargés et il faut souvent du temps pour réussir à façonner tes chefs de projets pour que les estimations de tâches soit réalistes.

Du coup, les 35 heures sont pas évidentes à respecter et on peut avoir du mal à trouver un équilibre vie pro/vie perso.

Conclusion

Je dirais que toutes les expériences se valent, mais qu'il faut choisir prudemment.
Je conseillerais les yeux fermés les ESN à des juniors en sorti d'école. On y apprend énormément de choses, et même si l'ascension hiérarchique n'est pas assurée, c'est une très bonne opportunité pour se construire un CV digne de ce nom.

Mis à part ça, je vous encourage tous, amis devs à réaliser la chance que nous avons et à en profiter.
Je ne dis pas de changer de boulot tous les ans, mais nous avons la possibilité d'être des "Divas" et de trouver un nouvel emploi très facilement. Il n'y a donc presque aucune raison d'aller travailler tous les jours à reculons, en se plaignant toute la journée en se disant qu'on pourrait faire tellement mieux.
Le job de vos rêves est quelque part dans cette jungle à vous attendre !

How to write bad-ass technical tests for your interviews ?

Xavier Dubois 🇫🇷 — Thu, 29 Aug 2019 21:20:57 +0000

I don't know how it works in other countries, but, in France, during interviews, it usual to have a technical test.
Sometimes you can do it from home, sometimes it's in live during the interview.

There is a lot of posts about the second one, so I won't speak about it. Let's focus on the "homework technical test".
I do code review on those for a while now, here is what I'm looking for.

Make it works

My first concern is that the code works.
I don't really care if the developer (especially if he is a junior) cover all the scope. I mean, it's better, but I prefer having an unfinished user story than a bugged one.

Clean code

We always have room for improvements, and, a lot of experienced developers don't have the cleanest code. I get it.
But, technical tests are like a resume, I except at least to understand easily what you have done.

If you are coding in PHP, I except PHPDoc for example,but also meaningful variable names, correct indentation and comments if needed.

Don't do more

If a scope is given, respect it. Don't over do.
You may think that's a bonus and the reviewer will see how implicated you are, but it send another message: You don't know how to respect the scope of a user story.

Git

Usually a Git repository is provided, and we except you to commit your code.
It's alright if you don't master Git yet, but you have to be careful about some little things:

Do little commits, with explicit title/messages
Don't hesitate to provide a Read me, explaining how you proceed and what you tried to do
We'll check your GitHub.

Ask for help

Not all companies does it, but I always stay available for the recruits (and I provide a way to get in touch).
That mean I except you to contact me if something is bothering you or if you are stuck.

Google is good, but we are looking for team player, and that's a good skill to be able to ask for help.

Write your own code

I love copying a piece of the provided code, and look for it on Google.
It's amazing how effective it is to disqualify a candidate.

You can search for technical solutions or tutorials on the net, that's what a developer do for a living, but don't just copy/past the code.
I am already sure that you know how to do that.

Write your own code

Don't take too long

We know you have a life, maybe kids, surely a full time job. That's ok.
But don't take too much time to get back to the company, it send the wrong signal.

You can't do it within the week ? No problems, but explain it, I'm sure it will be all good !

KISS

Keep It Stupid Simple

You have been asked for an API implementation. It is simple, right ?
Let's your code reflect that.

If you have been asked for 2 endpoints, on Symfony, I don't want to see any Interfaces, or complex paradigms.
Just a controller, with as many object as requested and some tests.
That's all folks.

Tests

Not everybody know how to write unit or functional tests. But I always ask at least for unit tests.
Try to do it, even if you are not sure. It shows implication and learning capacities.

Don't get crazy with technologies

90% of the time, a technology will be imposed. Well, it's because it will certainly be the technology you will be working with if you join the team.

Recruiter ask for a Laravel implementation with Api Platform ? Don't use GraphQl !

Do your homework

If the company have public repository, take a look. You may find some tips on how things are done by the team.
It's always nice to see that the candidate will try to fit in (even if fresh ideas and mindset are always welcome)

Do it alone

If you cheat, people will notice. And it's like lying on your resume, you can be fire for that. And you will.

I hope this few advice will help you.
Please share you advice in the comment section, I'll edit this post to add all the good ideas !

Enhanced your functional tests with Symfony (API context)

Xavier Dubois 🇫🇷 — Fri, 16 Aug 2019 09:52:17 +0000

My team and I have a lot of micro services to develop and maintain, and, since the key of success for this kind of architecture is performance, it is our main concern while coding.

Unfortunalty, Symfony does not provide a simple way for monitoring performances metrics other than the Profiler.

TL;DR:

We wanted to be able to perform automatic checks on our performances:

Number of database queries
Execution time (and not only the response time, which include too much variables)
Memory used

How to be fast ?

That's not the subject of this post, but I'll do a quick reminder about few requirements for a fast API, in a Symfony context:

Have as less database queries as possible
Don't have too much injected services
Use as less as memory as possible
Disable/remove all unused extra Symfony packages
If possible, don't use Listeners
...

But, how'd you check that ?

Symfony provides a very handfull tool to check some of the previous bullet points.
It allows you to:

Know the number of database queries
Know how much memory your app is using
Have information about performances

Amazing, right ?

When I'm coding or doing a code review, it's one of the first thing I check.
It's easy when you have a route to get all rows of a table, with a OneToMany relation to have an impressive number of queries, and that should not go to production !

What about functional tests ?

Well, your code is OK on your machine, you have the right number of queries, you know your route don't consume too much memory and that it's fast enough.

But I'm a paranoid developer, I don't trust code, not even mine. That's why I write unit tests, functional tests and integration tests.
And none of this tests allow me to assert that my route has less than 5 database queries, and that the execution time (which if different than response time) is fast enough.

I looked over, and I didn't find any easy way to do so. BlackFire.io do it, but it's expensive and a little bit too much for me.
But, hey, I'm a developer, so let's do it myself, that'll be fun !

First, where do I want to have access to this data ?

During unit tests ?

Nah, I don't want to do database calls during thoses tests, and, I prefer not have to boot the kernel

During integration tests ?

That might do the trick, but for now we don't go through CI before commiting, so that'll be triggered only before being push on production

During functional tests ?

Yes ! That'd be perfect.

We do that using Postman (and its CLI tool "newman").
I love this tool because it provide a way to test your work in progress and, when you're done, you just write tests in Javascript.

We are used to run the postman tests before commiting, during the code review (it's part of it), and, of course, before any push on production.

Accessing the data

Ok, I know when I want to have access to the metrics, I still have to figure how.
Postman cannot access the profiler, since it'd require a secondary HTTP call, and to crawl the HTTP response. So we had to figure out another way.

Why not pushing those metrics in the response header ?

Postman can read them and perform some tests on it
We can access them with ease, even from Chrome dev tool
It's pretty sexy, let's admit it !

We decided that we want to have:

The name of the controller and method called by the router
Have the number of database query
The memory used
The execution time

Execution-Controller → App\Controller\MyController -> myMethod
Execution-Doctrine-Queries → 8
Execution-Max-Memory → 4194304 bytes
Execution-Time → 206 ms

How it works ?

Well, it's really simple.

A StopWatch is started when any Controller is triggered using the onKernelController event, then stoped on KernelResponse. This StopWatch give us the Execution-Time AND the Max-Memory
We use the DoctrineDataCollector (as the Profiler does) to count the number of queries

Add it to the headers, and that's it !

Write some tests in Postman or whatever tool you are using, and you can assert that your route is using less than 2mb of memory and require less than 5 database queries !

laboutiqueofficielle / MonitHeaderBundle

Add monitoring data in the response's header

MonitHeaderBundle

This Symfony 3 Bundle add some extra informations to the response's header

Installation

Simple add this line to AppKernel.php

 public function registerBundles()
    {
        $bundles = array_merge($this->servicesBundles($this->getEnvironment(), $this), [
            [...]
            new Lbo\Bundle\MonitHeaderBundle\MonitHeaderBundle(),

Usage

Then, inspect your headers with, for example, Postman

Execution-Controller →App\Controller\MyController -> myMethod
Execution-Doctrine-Queries →8
Execution-Max-Memory →4194304 bytes
Execution-Time →206 ms

View on GitHub

Entities properties : public, protected or private ?

Xavier Dubois 🇫🇷 — Wed, 14 Aug 2019 10:33:54 +0000

We all write a lot of models and entities, specially when we are working with frameworks like Symfony.

But, when you code them, you have to make a choice for the properties. Should they be public, protected or private ?

Symfony made a choice: private.
Laravel chose public.

My coworkers, inside our Symfony projects code them either protected or private, with a bunch of accessors.

I prefer the Laravel's way, and always code them with a public visibility.

I made that choice because most of the time (like 99% of the time), accessors are useless, they don't transform the data. I prefer access them with object->property instead of object->getProperty()

And you, what visibility is your default choice, and why ?

Do you even unit test, bro ?

Xavier Dubois 🇫🇷 — Tue, 13 Aug 2019 21:44:12 +0000

Unit test is rocket science

A lot a coders don't write any unit tests. The main reason if that they don't understand why the should spend time on this. It's just a waste of time, right ?

I was exactly like that, then my code start crashing in production. On big and visible projects. So, I looked for a way to be more confident about my code, about my commits.

Unit test was the first answer, but it took me time before writing them correctly.

What is a good unit test ?

To write a good, rock solid and trusty unit test, you need to:

Understand what you are testing. That may sound stupid or obvious, but it's not. Read the method, understand what it does, how and why. How can you test it if you don't know what it should or shouldn't do ?
Avoid the "over mocking" syndrom. Mocking make writing test easy, but it's not a good practice. Only mock if you don't have any other choice, like for an API call. And, please, don't stub the class you are testing !
SEAT. Setup, Exercises, Assert, Teardown. And repeat for each tests.
I/O. Focus on data transformation. Defined a start state, run the test, assert on the output. What happened during the process, or how it happened is not your concern.
Decide a scope. Stick to it. A method can have as many tests as you want, but try to separates tests in use case scenarios.
You want to assert that a method transform an array to json, but also throw an exception ? Alright, make it 2 independant tests !

Does code coverage really matter ?

TL;DR: No. It does not.

I've heard a LOT of people saying that you should aim for 100% code coverage. But that's a bad idea.
Don't get me wrong, the higher code coverage you have, the better. But it should not be your main concern, neither your objective.

I ask myself a few questions before writting a test for a method:

Does the method transform the data ?
Can I write this test without mocking what the method will output ?
Does the method returns something at all ?
Can I make an assertion on the result ?

If any of this questions is anwsered by a no, it is likely I'll not write any test.

It's not because you have 100% code coverage that your code is tested properly.

You shall not pass !

Code is composed by public methods, yes, but also by private and protected ones.
Should we test them ?

Of course not. But also yes !

They usually contains the business logic, so, yeah, test them. But, unlike public methods, the are not worth a specific test.
The purpose of a private method it's to be called by a public method of the same class. Let's apply the same logic inside our tests. Private and protected methods should be test through public method's tests.

Always be F.I.R.S.T

I am used to write tests following the FIRST principles, but other methods exists, like AAC for example.
I assume that, as a developper, you know how to use Google to find them if FIRST is not a good fit for you !

Fast: A test should be light fast. If not, I'll discouraged you or your team from running it. Big project may have thousands of tests and assertations.
Setup, test and tears down should not take more than a few milliseconds
Independent: Tests must not depends on each other, or on the state of a previous test.
All data needed should be created for the current test, and destroy afterward.
If you need the same data for many tests, just create it during setup.
Repeatable: Tests should be repeatable over and over. Time, date or zone should not affect them.
Yes. You can be a Time Lord and mock Time (unless it's a fix point in time, of course ;-) )
Remember, if a test failed, the only valid reason should be that the method is not working as expected. Or that the test is wrong. But that's all folks !
Self-validating: No manual inspection required to check whether the test has passed or failed.
Thorough: Don't be lazy. Unit testing should take time to write, sometime even more than writing the method itself.
- Test every use case scenario
- Don't limitate yourself for simple values. Go for edge values
- If the methods can process bulk data, test if with a large data set
- Tests for exceptions and errors
- Don't only test for success. You can assert a faillure, and you should !

Conclusion

Keep your tests simple, limit them to a specific scope and focus on the output of the method.

Unit test is just the first step for a complete test cycle. Take a look on the pyramid bellow.

Using Laravel's Collection into Symfony

Xavier Dubois 🇫🇷 — Thu, 01 Aug 2019 21:43:20 +0000

What is Collections ?

With PHP, we are all used to works with Arrays. And it's great for simple things, but it can become tricky pretty fast !

I mean, who has never struggle to make a Slice, an array_map or even an array_walker with the built in methods ?

Personally, I always have to check the doc to get it right.

Collections provides an alternative. Laravel documentation describes it like this :

The Illuminate\Support\Collection class provides a fluent, convenient wrapper for working with arrays of data

In other words, it provides a bunch of methods and helpers to access, transform and use arrays of data.
For example, you have a API endpoint that is in charge of sending emails. You get an array of Email object in input, but you have to check first if they passed some assertion before trying to send them.

    $emails->reject(function (Email $email) {
        return null === $email->subject;
    })->each(function (Email $email) {
        $this->send($email)
    });

Pretty neat, right ?
Yes, it's a really simple code, you might say it could have been done with a foreach and a if, but when you start to have serious business logic and a LOT of data to filter, it provides lisibility.

Symfony and the Collections

Before, I was talking about Laravel's implementation of collections.
It has a lot of methods and helpers to make your life easier.

But, profesionally I have to work with Symfony. Which is great, don't get me wrong, but its collection implementation is really basic.

ArrayCollection (it's his little name), provided by Doctrine allows you to filter, access and map array of data, and that's it.
Laravel, in the other hand, provides advanced method, like "first", "sum" or "toJson".

How can we get Laravel's Collection into Symfony ?

Well, that should be simple right ? Because, since Composer exist, all we have to do is

composer require laravel/collection

right ?

But, hey, life is not that easy all the time !
Actually, Collections are part of the Laravel Framework, so, if you want it, you'll have to extract it, copy it on your own repo, and watch Laravel changes to stay up to date.
No thanks !

1st attempt

At first, I got cocky. Why not write my own implementation ?

I mean, nothing complicated to do. Just a bunch of methods ... easy.
ExtendedArrayCollection was born. The name says it all. I based my project on Doctrine's ArrayCollection to minimise the job to do, but also to make sure it will works everywhere in Symfony.

And it did for a while. Until it didn't anymore. To obtain something as good as Laravel does, it demands a huge amount of time, and, I don't have it ...

So, why not use Laravel's Collection ?

Back to Google, looking for a guy with more bravour than me, with more time, maybe.
I found a package, made by Matt Stauffer (Tighten Co.), which is an export of Laravel's Collection.

This was PERFECT. Well, almost perfect.

Laravel's entities are a little bit different thant Symfony's ones.
In Laravel, properties are declared public where, in Symfony, they usually are private or protected, with a bunch of getters and setters.

As you can imagine, it was a problem since, in Laravel's Collection, object data is access like this:

    elseif (is_object($target) && isset($target->{$segment})) {
        target = $target->{$segment};
    }

Annnnd yup. That cannot works with a protected properties, since you have to use $taget->getSegment() to access the value.

Well, since I really hate ArrayCollection, I decided to not give up.
So, I created a fork from Tightenco/collect package to make some tweaks that allows me to use Laravel's Collection into Symfony.

Code modification

Alright, then all I needed to do was to find a way of accessing data no matter their visibility.

I had a few options:

Assert that "getSegment" method exist, and, if not, trying to access value with ->segment.
Always assume that since I'm in Symfony, getter will always be set
Use ReflectionObject

I chose to use the third option, with ReflectionObject because it provides a more secure way to do it.
The code became:

    elseif (is_object($target)) {
        $reflectedObject = new \ReflectionObject($target);

        // Use Reflection class to check if property even exist, otherwhise let's use default value

        if (!$reflectedObject->hasProperty($segment)) {
            return value($default);
        }

        $p = $reflectedObject->getProperty($segment);
        // If property is public, no need to get all the way down
        if ($p->isPublic() && isset($target->{$segment})) {

            $target = $target->{$segment};
        } else {
            // Make the property accessible before geting its value
            $p->setAccessible(true);
            $target = $p->getValue($target);
    }

And, that's it folks. I just have to make a Collection class on my own namespace, extend TightenCo version, and my Symfony is ready to use the amazing Laravel's Collection !

What's next ?

That is already pretty cool and handy, but I want more.
Next steps:

Override Doctrine to make it use Collection instead of ArrayCollection
Make a proper repository with documentation, example
Find a way to simplify the namespace management
make unit tests !

If any of you is interested by the package:

Juyn / collect

collect

Add support for Symfony on Laravel's awesome Collection

View on GitHub