Anh-Vu Tran

TDD

Que l'on aime ou pas, ça à la mérite d'exister et de formaliser l'idée.


Partagé par Blaise
il y a 3 mois
2

Derniers commentaires :
Anh-Vu Tran il y a 3 mois
la partie "What is NOT TDD?" est au moins aussi importante que "Values of TDD"
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Culture
DDD
Design Pattern
Programmation fonctionnelle

Qui a dit que le DDD et le logiciel en général ne pouvait être composé que de classes, d’héritage, et qu’une modélisation sans comportement était forcément un modèle anémique, un anti-pattern par définition ?


Partagé par Romain Fallet
il y a 9 mois
6

Derniers commentaires :
Benoit GANTAUME il y a 9 mois
@Charles Dimitri : qu'est-ce que tu en as retiré ?
Pourquoi devrais-je l'étudier selon toi ?
Anh-Vu Tran il y a 9 mois
Toutes les vidéos de Scott Wlaschin sont excellentes ! La première vidéo que j'ai vue de lui m'a donné envie de voir toutes les autres qui sont mentionnées sur son site.
En plus d'être très bon dans son domaine (no pun intended !), c'est un super pédagogue qui sait expliquer simplement des concepts compliqués sans les vulgariser/dénaturer.
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 10 mois
4

Derniers commentaires :
Anh-Vu Tran il y a 9 mois - modifié il y a 9 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 9 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 10 mois
5

Derniers commentaires :
Anh-Vu Tran il y a 10 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 10 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.
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 10 mois
5

Derniers commentaires :
Anh-Vu Tran il y a 10 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 10 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.
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