Retour d'experience

J’ai décidé de partager avec vous mes pires (ou meilleures anecdotes suivant le point de vue) en tant que développeur, histoire de rigoler un petit peu.


Partagé par Axel Shaïta
il y a 2 mois
5

Derniers commentaires :
Corentin Leffy il y a 2 mois
Ces anecdotes sont géniales !
Force à toi pour le coup du boîtier GPS ! Tu as été vraiment patient et plein de ressources 👍
Malheureusement, le coup de la "fausse" démo qui doit être livré sous peu, tous les développeurs y ont droit un jour... 😔
Axel Shaïta il y a 2 mois
Merci ! Oui le coup du boîtier GPS j'ai beaucoup transpiré, mais avec du recul c'était une bonne (mauvaise) expérience qui m'a beaucoup apporté par la suite. La "fausse" démo c'est malheureusement un classique…
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
langage
rust

Rust a été élu, pour la cinquième année consécutive, le langage de programmation le plus apprécié par les développeurs selon le sondage annuel de StackOverflow. Il y a un véritable engouement autour de celui-ci, qui fait que de plus en plus d’entreprises s’y intéressent et n’hésitent pas à migrer leurs solutions vers celui-ci.


Partagé par Axel Shaïta
il y a 3 mois
6

Derniers commentaires :
Romain Fallet il y a 3 mois - modifié il y a 3 mois
Super intéressant ! C’est un langage bas niveau et pourtant, il a tout ce qu’ont les langages considérés comme haut niveau, ça donne envie d’essayer, merci
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
algorithme
entretien

Je ne suis pas forcément fan des entretiens techniques dans lesquels on pose des questions d'algorithmiques surtout lorsque celles-ci n'ont aucun rapport avec le poste en question. Malheureusement, c'est une réalité, de plus en plus d'entreprises font passer ce genre d'entretiens aux candidats et ce n'est plus exclusivement réservé aux FAANG. J'ai donc décidé pour cette année de commencer une série d'articles concernant les questions d'algorithmiques les plus fréquemment posées en entretien. C'est également une bonne occasion de (re)découvrir les bases de notre métier qu'est l'algorithmique et la résolution de problème. Pour ce premier article, j'ai décidé de commencer avec les listes chaînées qui sont l’une des structures de données linéaires les moins maîtrisées par les candidats contrairement aux tableaux.


Partagé par Axel Shaïta
il y a 3 mois
4

Derniers commentaires :
Anh-Vu Tran il y a 3 mois - modifié il y a 3 mois
Pas tout à fait d'accord, le but n'est pas de réimplémenter mais de comprendre pour savoir quand utiliser les bonnes structures de données.
De là en découle une complexité en temps et ou mémoire.
Cela permet de prévoir et prendre les bonnes décisions quand la volumétrie et/ou le nombre d'utilisateurs augmente.
Et quand ca déborde sur une architecture simple malgré les bonnes optimisations, on repense une archi plus complexe qui puisse répondre aux nouvelles contraintes.
C'est donc la base à maitriser pour aller plus loin.

EDIT: le temps que j'écrive, d'autres réponses ont popé ^^ Je répondais exactement à la même phrase que Benoît "il vaudrait mieux faire gagner du temps à tout le monde et poser des questions pertinentes pour le poste"
Jason Maréchal il y a 3 mois
@Benoit @Anh-Vu
Je partage votre point de vue. Je n'ai rien contre poser une question d'algorithmie, de complexité... si la question sert à un échange. Ce qui me gène plus c'est refuser des candidats sur le seul principe d'échouer à répondre à ces questions.
Bon pour la liste chaînée ayant été formé sur le C je suis biaisé et considère que ça fait parti du minimum culturel pour un dev. Mais mettons que ce ne soit pas le cas. Refuser un candidat parce qu’il ne réussi pas à implémenté une liste chaînée parce qu’il ne sait pas ce que c'est et n'en a jamais vu de telle implémentation c'est dommage. Discuter avec lui, l'aiguiller sur une piste et ce rendre compte qu'en reformulant le problème il arrive à implémenter une solution par liste chaînée, c'est mieux.
Après ça dépend de l'objectif de l'entretien aussi. Si on veut des gens très pointus sur tout ça fait un bon filtre.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
NodeJS
Optimisation

Deuxième article de cette série consacrée à l’analyse des performances des applications Node.js. Nous allons nous attaquer cette fois-ci à l’analyse de la mémoire.


Partagé par Axel Shaïta
il y a 4 mois
5

Derniers commentaires :
Anh-Vu Tran il y a 4 mois
Mais si c'est affectueux. C'est juste que c'est le moment où, dans le podcast, tu montres la pertinence d'aller voir le cursus 😉
Axel Shaïta il y a 4 mois
@Anh-Vu Tran Effectivement les fuites mémoires proviennent la plupart du temps d'un souci dans le design de notre code ou d'une librairie tierce mal conçu. C'est pourquoi j'explique les principales causes de ces fuites mémoires pour justement les éviter. Après il n'est pas toujours évident de s'en apercevoir d'où le fait de savoir comment diagnostiquer son application ;)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques
Git

Lorsque l’on utilise Git, surtout quand on est débutant, on ne sait pas toujours comment nommer correctement ses branches ou ses messages de commits. Pourtant il est primordial pour s’y retrouver dans un projet, de respecter une convention de nommage.


Partagé par Axel Shaïta
il y a 4 mois
4

Derniers commentaires :
Axel Shaïta il y a 4 mois
@Corentin Leffy J'ai pas mal utilisé cette convention que je trouve, comme tu dis, très visuelle. J'en fais d'ailleurs mention très brièvement dans mon article.

@Marc Bouvier C'est exactement cette convention ! Effectivement elle est de plus en plus suivie car pas mal d'outils se basent sur celle-ci pour automatiser la génération des changelogs ou le versionning (en se basant sur semver.org/lang/fr/)
Baptiste Pottier il y a 4 mois - modifié il y a 4 mois
@benoit Oui, nous l'utilisons depuis une année en mode "souple", c'est à dire que nous gardons une branch develop en plus de la master, là ou certain "extremistes" ne gardent que la master (et franchement on s'interroge à ne pas pousser jusque là tellement c'est pratique).
Les gains sont :
- l'obligation de travailler propre (il faut penser au copain)
- obligation de faire de petit commit
- incitation forte au feature flag
- Jamais de gros diff, jamais de branch qui se meurent ou qui durent des jours et des jours voir plus (sympa à merger ...)

On peut très bien savoir faire cela avec des branches, mais alors elles n'ont plus d’intérêt (si on merge toutes les heures, autant faire dans develop).
A chaque onboarding, le nouvel arrivant est dérangé mais très vite il adore (et on utilise les tags!) c'est queque chose qu'il faut pratiquer pour véritablement en comprendre l'avantage (comme le TDD sur ce point)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Artisan Développeur utilise des cookies afin de t'offrir les meilleurs services. En poursuivant ta navigation, tu acceptes l’utilisation de cookies. En savoir plus