Bonjour à tous et à toutes.
Bonjour à tous et à toutes.
Bienvenue à l'Unhandled Exception podcast.
Je suis Dan Clark, et aujourd'hui je suis venu par Patrick Smachia
pour une chute tout à l'heure en dépenant.
Et je crois que Patrick nous a allé tous les jours
de l'Isle de Mauritius.
Donc, bienvenue au show Patrick. Merci pour les joueurs.
Bonjour Dan, merci pour l'opportunité d'en parler ici.
Je suis très bienvenue, j'en suis vraiment en train de vous dire.
Alors, could you give us a quick intro into your background?
Et est-ce que vous êtes en train de penser que vous avez aussi écrit un livre?
Oui, je suis Patrick Smachia, je vous jure que vous l'avez déjà compris
que je suis de France.
Oui.
Ok, donc je suis 45 ans, mais j'ai commencé à coudiner quand j'étais 10.
Donc c'est plus que 3 décennies, je suis en cours.
Donc j'ai fait beaucoup de proches de C++ professionnelles.
Et puis, quand DotNet arriva dans 2002, en 2002,
j'ai eu l'opportunité de faire un livre
sur l'arrivée de DotNet pour Aurélie,
l'édition Aurélie,
qui était assez successeuse.
C'était vraiment une grande opportunité
de apprendre sur les goûts que vous pouvez avoir dans la plateforme
parce que DotNet est très spécial,
parce que pas seulement au début,
il a eu beaucoup de goûts,
mais pour presque deux décennies maintenant,
il n'a jamais pu s'improver et s'improver et s'improver.
Même la prochaine version, DotNet 6,
sera absolument incroyable.
Il y a beaucoup de nouvelles choses,
surtout sur les performances.
Donc c'est vraiment une joie
d'être un expert de DotNet,
et je dois dire que,
peut-être que je n'ai pas d'exception,
mais je dois dire que

je dois dire que Dan Marcosov
n'a jamais dévoilé
sur l'évolution et le progrès de DotNet.
Et c'est ça, c'est bien.
Après le livre,
ce qui s'est passé,
c'est que mon nom était un peu fameux
en termes d'expertise de DotNet.
Il y a beaucoup de grandes entreprises,
comme les banques,
et des grandes entreprises
avec des tonnes de légacies,
qui ont commencé à m'assurer
comme consultant
pour les apprendre
de dotnet.
Mais aussi pour analyser
les codes,
pour assurer les codes qu'ils ont,
ce qu'ils peuvent faire pour s'improver.
Donc, ce qui s'est passé,
c'est que
j'ai commencé à écrire un outil,
qui en fait était indépendant
depuis le début,
en 2004.
Et c'était un outil très petit,
un outil d'opération,
et il était
base dans le principe Robert Cecil Martin.
Je ne sais pas si vous l'avez entendu,
mais Robert Cecil Martin,
aussi connu comme le grand-mère Bob,
est très fameux
pour avoir connu
beaucoup de bons concepts,
tous les principes solides,
mais aussi un autre concept
de ce qu'est le component
et comment le component est connu.
Il faut interrompre
et
d'inverse et tout comme ça.
Robert Cecil Martin a beaucoup d'abus
sur ce point.
Et de toute cette écrire,
vous pouvez faire des codes métriques,
pour obtenir des numéros
pour analyser des codes.
Et puis, de quelques numéros,
vous pouvez assurer
si la base de code est bonne
ou pas, et ce qui peut être improvisé.
Ok,
je suis très intéressé
à tous ces codes métriques
et les codes de qualité.
C'est pourquoi j'ai commencé
Ndipen.
Juste pour avoir un outil
pour que je puisse aller à mon client,
juste pour obtenir leur legacy
et pour obtenir des trucs
automatiquement intéressants,
pour faire sure que je puisse
donner autant de valeur
possible de mon temps de consultation.
Et
ce qui s'est passé,
Ndipen, en source d'open
c'était
beaucoup, je peux voir
que beaucoup de gens ont
déloyé ça.
Il y avait
beaucoup d'interesse sur ça.
Et après
quelques années, j'ai vu l'opportunité
de faire un commercial.
Et c'est comme ça que Ndipen
devient le tool que nous savons maintenant,
qui est maintenant un
très solide tool,
avec beaucoup de features
et beaucoup d'activistes
en word-wide.
C'est comme ça que ça a commencé.
C'est une grande histoire
où vous êtes un consultant et vous avez vu un problème
et vous avez construit quelque chose pour vous-même
et puis, ça a en fait été créé
plutôt que d'être une opportunité business,
vous avez commencé par
juste de solider un problème que vous avez
et puis ça a été créé et vous avez vu
l'interesse. C'est vraiment
très bien. Et je suis travaillé
avec beaucoup de companies maintenant
et beaucoup de elles,
quand le sujet de analyser le code source
et de regarder la complexité,
Ndipen semble avoir un grand nombre
et c'est une des choses
qui sont assez embarrassantes
parce que, à savoir moi, c'est le type
de tool que je serais vraiment
utilisé assez profondement dans le passé.
Et je ne sais pas, j'ai honte que je n'ai pas
parce que, comme je disais, des entreprises passées,
il y a toujours été le company qui a été
un expert Ndipen
et qui a été créé
ces maris d'experience.
Normalement, c'est quelque chose que je serais
en train de faire. Je ne sais pas pourquoi je n'ai pas.
Donc, cette semaine, parce que c'est évidemment que nous nous faisons
le podcast, j'ai déployé le trial,
j'ai joué avec un de mes projets,
donc c'est vraiment bien de avoir
beaucoup de suggestions.
Je suis embarrassé à combien de suggestions
il y a dans mon code, mais c'est bien de
voir tous ceux et de tous les diagrams.
Donc, c'est vraiment quelque chose que je vais
faire en regardant les projets de mon projet.
Oui, donc, comme vous l'avez dit, Ndipen
peut donner beaucoup de suggestions
dans beaucoup de façon,
donc, comme je l'ai mentionné
plus avant, il y a des métriques
où vous pouvez avoir beaucoup de numéros
de Ndipen, comme le size de votre code
ou la complexité de votre code.
Et il y a aussi le système de rouleau.
Donc, de la système de rouleau,
vous pouvez avoir des issues.
Ok, et puis,
des issues, vous pouvez décider
si c'est le plus dur de fixer ou pas.
Et aussi, Ndipen peut avoir
plusieurs diagrams.
Donc, il y a
plusieurs manières pour visualiser
votre code, comme le graph de la
classique dépendance, qui, je crois,
est plus powerful
en Ndipen, plus détaillé, parce que
c'est vraiment un de ses
features core. Vous avez aussi
des métriques de dépendance et
des métriques de code,
visualisation de la map de coloris.
Et aussi,
c'est un tool de reporting
qui peut produire
des rapports de votre
CCD-BIL
et aussi
de votre Azure DevOps
système.
Donc, très concrètement, Ndipen
vient avec trois flavors,
qui sont la première
extension de l'extérieur de la visualisation.
Ndipen peut se tourner dans le studio
et peut provider tous les boudis
dans le studio.
C'est le
developer SKU.
Le developer SKU aussi supporte
toutes les features que vous avez
dans la extension de la visualisation.
Tentez de la visualisation Ndipen.exe
comme un standalone.
Donc, si vous êtes très, très
attentionnés pour votre performance de
visualisation studio,
qui en fait Ndipen n'est pas
une performance de visualisation studio
comme d'autres extensions
que je vais nommer.
Mais je comprends
si certains gars préfèrent
avoir des extra features
au-delà de l'ED.
Donc, Ndipen est possible.
Donc, c'est le developer SKU.
Ensuite, vous avez la machine BIL
qui vous laisse
invoquer Ndipen.console,
qui est un console classique
avec un argument command line.
Et là, vous pouvez générer des rapports
que vous pouvez partager
avec la team.
Inclué avec la SKU, il y a
aussi un API
que vous pouvez targeter avec votre
programme CCHA.
Donc, vous pouvez automatiser
tout en Ndipen grâce au API.
Et enfin, il y a
la third SKU, qui est la extension Azure
Develop, où c'est très
convenient pour avoir aussi
beaucoup d'informations
aussi dans votre app Azure
Develop,
l'app Azure Develop.
Donc, tous les 3 SKUs,
bien sûr, interagent
ensemble. Et c'est vraiment
très intéressant pour vous.
C'est vraiment intéressant, parce que nous avons
beaucoup de clients qui préfèrent
les extensions Azure, et puis, nous avons
beaucoup d'autres qui sont très satisfaits
en rapportant. Et enfin, il y a
des autres qui sont satisfaits
avec l'extension Azure Develop.
Donc, c'est vraiment très intéressant pour vous
comment vous voulez
travailler avec la qualité de la code,
et tout Ndipen peut
vous donner.
Oui, c'est cool
qu'il y a un command line 1 aussi.
Je vois que je suis en train de
regarder mon installation de Ndipen,
Ndipen.console, Ndipen.powerTools,
et puis le studio visual
installer, et puis
VisualNdipen.exe.
Oui.
J'ai l'impression que c'est le standard.
Oui, absolument.
Alors, comme exemple, je personnellement
n'ai pas l'idée.
Alors, est-ce que je serais
utilisé le standard.on.tool, et puis
juste switch entre les deux?
Est-ce que c'est le workflow
et le studio non visual?
Oui.
Donc, nous n'avons pas encore une extension
de rider, en fait,
intéressant.
Nous parlons avec le jetbrain
d'ingénieur pour voir comment nous
pouvons faire ça, parce que non-tour
n'est pas assez populaire
entre les développeurs.
Ce n'est pas facile, mais
à la prochaine iteration,
nous voulons travailler
sur ceci, et ça ne sera pas facile.
Pour sûr, nous avons déjà un petit prototype,
mais parce que le
le quai est que le rider est un
swing-based UI,
et tout le monde
s'intérite.
En fait, Ndipen est un WPF
informé, Windows UI.
Donc, il y a
une possibilité de l'intégrer
avec WPF,
et de l'informer UI.
Pourquoi nous avons aussi des plans
pour migrer
le WPF, pour quelque chose
qui peut travailler sur le système multi-opératif?
Donc, le point est que nous n'avons pas décidé
de ce qui pourrait être
le parfait framework.
Peut-il être Moe?
Que nous voulons venir à la prochaine?
Ou peut-on utiliser quelque chose
plus bas, plus plus plus mature?
Nous ne savons pas encore.
Mais
quelque chose qui est très intéressant
est la prochaine version,
qui sera
publiée en octobre.
Donc, en mois ou en mois,
nous allons évoquer tout le
stuff de l'exploitation,
sur Linux et macOS.
Oh, bien sûr.
C'était quelque chose qui
était attendu par l'utilisateur.
Et c'est très intéressant,
la migration du monde,
la migration que nous avons fait.
Parce que maintenant, je peux dire que nous avons fait
ça parce que maintenant, nous sommes à la fin.
Et en fait,
le métier que nous avons,
nous travaillons très bien
sur Linux.
Donc, basiquement,
nous avons cette
massive legacy
qui était basée sur le framework
sur le framework.
Avec Winform et WPF.
Et
ce que nous avons fait,
c'est que nous avons converti
la plupart des codes non-nul,
les codes UI, la plupart des codes non-nul,
les codes 2,
des standards dotnet,
les assemblages 2.0.
Donc,
le standard dotnet est comme le dénominateur
commun
entre le framework dotnet
et le nouveau dotnet
qui s'appelle dotnetco,
et qui s'appelle dotnet5
et dotnet6.
Donc, maintenant, nous avons plus de 70%
de notre base code
qui est dotnetstandard.
C'est très intéressant parce que
ça signifie que
pas à la évolution du dotnet
et maintenant, nous savons que ça devrait être
dotnet6 et dotnet7, mais
mais ça peut aussi être un blazo
et tout comme ça.
Et tout ce nouveau flavor
du dotnet est supportant du dotnetstandard.
Et ce que nous voulons
achever est de ne pas être
un trappage comme nous avons
maintenant. Comme, hey, nous avons
un grand dotnetframerc legacy
et tout de suite, le nouveau
stuff est en train de régler
les Linux et MacOS, c'est le nouveau
dotnetco stuff. Donc, nous avons
appris le son et maintenant, la plupart de nos codes
sont déjà en train
de régler le standard dotnet
et plus de nos codes
vont être réunis au standard dotnet
après que nous migrions
les UIs. Donc,
ce que nous avons appris, c'est le pass
de la large migration
parce que nous en parlons de
quelque chose de 4000 classes
migrées.
Donc, c'est un grand projet.
Donc, en fait, nous avons utilisé
l'avis de l'indépendance.
Comme nous l'avons fait depuis le début,
depuis le début, avec DOGFOOD & DEPEND,
c'est très réagissant
d'être le premier utilisateur de
ce seul produit. C'est vraiment intéressant.
Vous avez utilisé l'indépendance
contre votre projet d'indépendance, non?
Absolument, depuis le début.
Et en fait, nous avons
beaucoup de
très strictes définitions de dons
qui sont quelque chose
très important pour moi. Quand vous considérez
que c'est don
et l'indépendance peut aider beaucoup
selon nous et selon la définition
de dons. Donc, l'indépendance,
parce que c'est un outil
qui basiquement scanne
votre code.
Il scanne votre code et il tente
d'inférer beaucoup de propriétés
de la ligne et de la diagramme
et de la qualité de la carte et tout comme ça.
Ce que j'aime vraiment est que c'est
objectif.
Typiquement, quand vous faites
une meeting de qualité de code
dans votre compagnie de la Legacy,
tout le monde est objectif.
C'est pas mon code, donc
c'est pas bon. Parce que
ceci est mon code, c'est bon. Non, non.
Vous avez besoin d'un objectif dans le milieu
de votre équipe qui dit
que ça satisfait les critères qu'on veut.
Donc, pour exemple, un bon critère
est
« Laissez-vous être 100% couvert
par tests » ou
« Laissez-vous être pas complexe
comparé à la compétition
de la compétition de la compétition psychologique. »
Ou « Laissez-vous faire sure que cette classe
n'est pas si grande. »
Il y a beaucoup de règles comme ça.
Ou « Laissez-vous faire sure que le UI
n'est pas directement targeté par le DBE. »
Ou « Il y a vraiment
d'autres règles comme ça. »
Des règles différentes que vous pouvez
simplement customiser.
Je l'ai dégracé un peu, mais le but
est de ne pas en mettre un peu beaucoup.
Et une chose que je réalise
dans le blog poste, je pense que c'était
deux ans plus tard, est que
l'indépendance est très bonne pour vous
dire que quelle de vos codes
n'est pas standard.
Ou quelles de vos codes ne l'abandonnent pas
par ce...
Vous vous donnez un code
et une libraire
que vous voulez compliquer.
Par exemple, il peut être netstandard.dln
et l'indépendance peut vous dire
« Hey, cette classe
utilise ce méthode
qui n'est pas internetstandard. »
Il peut dire ce genre de choses.
Et ce
ce que je peux dire, c'était
un feature accidentel.
Il n'était pas plané
depuis le début, mais
l'indépendance est très configurable
et flexible.
En fait, c'est possible
d'avoir ce genre de feature.
Ça nous aide beaucoup
à
migrer nos codes.
Par exemple, nous avons un code UI
intervier avec un code non UI
qui nous aide
à dire « Hey, cette code
vous allez mettre ça derrière une interface,
puis vous allez utiliser un genre de
dépendance d'injection,
pour invoquer ces trucs.
Et maintenant, je peux dire que nous avons 70%
de notre code qui est Internetstandard
et 70%
c'est un Mijo.
Comme je l'ai dit avant, l'indépendance est très basée
sur Mijo, sur l'objectivité de votre code.
Donc c'est très intéressant
d'être capable de dire
« Hey, 70% de notre code
n'est pas internetstandard,
80% de notre code est converti par test,
80%
de notre code, depuis que le code base
est satisfait
d'avoir des critères,
pas de critères critiques,
pas de test de covêtement,
pas de code de mort, etc.
Donc ici, je vous ai mentionné
un feature très important dans l'indépendance
qui est la capacité base de la ligne.
Je vous le montre
et les gens qui l'ont écouté
nous ont déjà utilisé beaucoup de tools
pour scanner leur code,
comme un réchaper
ou un certaine analyser d'hospérité.
Et ce que l'indépendance
a, il y a plusieurs choses,
mais une chose qui est très intéressante
est que avec l'indépendance, vous avez cette notion
de base-line.
Donc l'indépendance comprend, vous pouvez dire
que la dernière, typiquement la dernière
relance que vous avez faite est la base-line.
Et l'indépendance
va surtout focusser
sur les nouveaux trucs que vous faites
depuis la base-line.
Des classes nouvelles, des classes refactores
méthodes, etc.
Donc l'indépendance peut focusser
sur ces nouveaux trucs.
Et ce qui est très intéressant
est que, à la première fois, vous avez dit
quelque chose que l'indépendance était
exhaustive, parce que vous avez des milliers
d'issues et que vous ne savez pas
ce que vous pouvez vraiment faire.
Et c'est là où la base-line vient de jouer
en lieu de avoir des milliers
d'issues, vous avez
juste des issues sur le travail
que vous faites maintenant.
Donc vous pouvez dire quelque chose
comme, depuis maintenant,
on veut satisfaire
le principe de bonne politique.
Et ces sont très concrets,
comme je peux l'expliquer plus tard.
Et c'est très important, parce que
c'est la seule façon que vous pouvez vraiment
l'improver. Parce que,
les targets réels, professionnels,
qui ont des legacies,
qui ont des dozeons,
ou des milliers de milliers de plus,
avec une large légacité, vous ne pouvez pas
dire, hey, on va arrêter tout,
on va le savoir
dans un grand fil, donc on va
prendre beaucoup de mois, refactorer
tout et satisfaire
tout le principe de bonne politique.
Ce n'est pas possible.
La seule bonne approche, c'est
de dire que, depuis maintenant,
le code que nous allons faire, ou refactor,
va être
bien fait, avec le principe de la droite,
on va faire le test,
on va faire sure que ce n'est pas trop complexe.
Et c'est là que
les features baselines peuvent vraiment
beaucoup aider, comparé à d'autres
tools qui sont extrêmement utiles,
comme Rich Harper et Roselyne, etc.
Mais ça dépend de la façon
où vous pouvez
mériter votre progrès, et
surtout, vous pouvez mériter le tout
dans les nouveaux trucs que vous faites.
À l'interesse avec le baseline, comment
est-ce que cela persiste les dernières?
Par exemple, si vous vous rassurez,
dans Azure DevOps, vous pourrez avoir
plusieurs agents de bataille, mais où est-ce
que l'histoire des précédents échecs
se dévouent?
Depuis le début, en fait, l'indépendance
ne fonctionne pas avec un DB,
comme le service Grale,
etc. Il fonctionne
avec un système de 5.
Parce que depuis le début, personnellement,
je pense que c'est beaucoup plus facile
de faire, et c'est aussi beaucoup plus facile
pour le développement, parce que puis ils peuvent
modifier très facilement
leur système de 5,
si ils ne veulent pas, par exemple,
des résultats de analyses,
etc. Donc c'est très facile de modifier.
Donc, comme vous l'avez compris, l'indépendance
fait un snapshot de votre base de code,
donc vous vous inscrivez des projets,
des solutions,
ou des assemblages, et puis l'indépendance
qui vous mettraient
concrètement des résultats d'indépendance
qui ressemble à
un format binary
de format 5,
dot enda. Donc, nous ne voulons pas
les utilisateurs pour mettre le déend
parce que c'est très optimisé,
et c'est comme si vous vous inscrivez
un SQL Server 5,
bien sûr, ce n'est pas possible.
Donc,
juste un approach de 5 systèmes,
et puis on utilise des artefacts Azure
devape.
En fait, je ne suis pas le manager de product Azure devape,
mais je sais qu'ils utilisent des artefacts Azure
avec ça, et ils justent
très bien.
Cool, cool.
Je pense juste sur les autres manières
de faire la CICD, donc, évidemment,
on a mentionné Azure DevOps, mais il y a
d'autres providers aussi, et puis
souvent, maintenant, Docker est devenu
assez populaire.
Donc, on peut se tourner en Docker,
pour ne pas installer, par exemple,
l'endependance, ou tout ce que c'est,
sur des agents de construction,
ça a l'air de supporter tout ça?
Oui, c'est aussi ici, c'est plus
sur le système de licence,
et oui, nous avons un très flexible
in-house licensing capability,
donc
tous ces scénarios
peuvent être adressés,
et certains de eux
ont besoin de l'utilisateur
pour nous remettre en compte, donc nous pouvons
faire leur licence en accord avec ce qu'ils veulent.
Mais oui, ça fonctionne, nous avons aussi
une extension de Team City,
en addition
de l'extension Azure devape, parce que la team city est
assez populaire. Nous avons aussi une extension de SonarCube,
dans le sens que
vous pouvez importer toutes les issues
et le débat technique de
l'endependance à SonarCube.
Donc, le SonarCube est un moyen
d'assurer le débat technique,
puis vous pouvez ajouter et débarter
dans le service.
C'est aussi quelque chose qui a été
réquesté par plusieurs
utilisateurs.
Une des difficultés de l'endependance
est que les choses se sont évoluées
constantement. Par exemple,
maintenant, les gens sont en train de débarter
les actions sub-sens,
qui sont très populaires.
Nous travaillons sur ça, mais nous n'avons pas
encore là.
Mais c'est quelque chose que j'espère qu'on aura
pour 2022.
Une des difficultés
est la pluralité
de tous ces systèmes de la CICD.
Et maintenant,
ce n'est pas seulement la CICD, mais aussi
l'IDE, parce que maintenant, nous sommes
les rideurs, le Visual Studio,
le Visual Studio for Mac, le Visual Studio Code
et tout comme ça.
Ce n'est pas facile,
mais nous travaillons assez hard.
Je peux imaginer, il y a
beaucoup de différentes manières
que vous pouvez avoir pour votre setup de développement.
Parce que, maintenant,
souvent, vous pouvez mélanger beaucoup
de façon ou forme.
Donc, si vous êtes un rideur, Visual Studio,
Visual Studio, VS Code, ou tout ça,
Vim, tout ça, vous avez des
différents pipelines de CICD,
vous avez des systèmes de different opérations,
vous avez des gens qui veulent faire des choses
sur la command line VS
en utilisant un GUI.
Il y a beaucoup de différentes combinations. Je ne peux pas imaginer
toutes les différentes
features de requestes que vous avez en train.
Et même comme vous avez mentionné
l'extension de rideurs et
l'extension de Visual Studio,
ce n'est pas seulement la fonctionnalité
que vous avez en train de faire, c'est que le GUI
est capable d'intégrer à l'IDE.
Ça semble juste un grand nombre de travail.
Oui, ce n'est pas facile,
mais c'est très froid.
C'est un très bon moyen de penser
sur ce que j'aime.
Oui, c'est
bon d'avoir un challenge
et aussi
il y a une façon
d'être un peu différent
sur des autres outils.
Donc, oui, un point
qui est en train de déplaner
est que nous essayons d'être extrêmement vite
en faisant tout, analysant,
compétissant le diagramme,
en déclenchant les règles et tout comme ça.
Ce n'est pas seulement parce que c'est bon
pour les utilisateurs,
c'est ce que les utilisateurs veulent.
Ce n'est pas que ce jour, ils ne veulent pas attendre
et nous pouvons voir les rambles
sur Visual Studio,
qui parfois s'y s'arrêtent
et nous les apprenons,
qui s'y s'arrêtent beaucoup aussi.
Nous pouvons voir tout ce qui s'appuie
à l'advipteur.
Depuis le début,
nous avons été très attentionnés
à avoir un outil très rapide
et tout est fait en matière de secondes.
Même analysant
une très grande base code,
par exemple, on peut analyser le .NET 5,
l'entière .NET 5
dans moins de 15 secondes.
Wow, wow.
Quand j'ai essayé mon propre projet,
qui est évidemment beaucoup plus petit que ça,
j'étais impressionné par la vitesse,
mais à 15 secondes pour tout de .NET.
C'est très impressionnant.
Oui, c'est quelque chose,
des types 16K,
comme des classes,
peut-être pas seulement classes,
mais aussi structure et animation.
C'est un des trucs préférés
en programmant,
c'est d'avoir un code très efficace.
Et je pense que ça reflète
dans 20 pensées.
Et aussi,
ce qui est intéressant,
c'est que pour un projet plus petit,
c'est très bon pour avoir tout ce qui fonctionne très rapidement.
Mais aussi, nous avons beaucoup de clients,
beaucoup d'un grand équipe,
avec une très grande législation.
Je parle d'un projet
avec des centaines et des milliers
de components.
Et .NET 5, pour exemple,
a un component 165,
je veux dire assemblées,
ou un projet,
en fonction de ce que vous voyez.
Nous avons vraiment des clients
avec, pour exemple,
des clients qui ont plus de 2000 components.
Et ce code .NET
est dans le scanner
quand vous allez au hospital.
Vous avez le scanner
et il y a un
massive software derrière.
Il y a des tonnes de matinite,
il y a des tonnes de stuff,
pour obtenir des images médicales.
Ceci,
c'est en fait un SCEM,
les gens de SCEM,
ils utilisent les indépendants
depuis le début.
Et nous travaillons très bien avec eux,
parce qu'ils sont un des plus
détenus de code .NET,
vous pouvez l'imaginer.
C'est très intéressant
d'être
le seul tool qui peut travailler
avec un code large,
comme ils ont besoin d'une solution
de plusieurs studios,
car le studio ne peut pas
l'opérer,
et aussi le Sharper ne peut pas le travailler,
mais l'indépendant peut travailler
dans un processus 64 bits,
et peut-être il en reste quelques minutes
pour analyser tout,
mais ils peuvent commencer à avoir
des données significatives
sur leur legacy super large.
Et pour nous, c'est très réel
d'avoir un base d'utilisateur
qui, je ne sais pas si en anglais,
en français,
ils ont besoin de le meilleur
parce qu'ils ont un
problème massive,
et c'est réel
d'être capable de satisfaire ces gens.
Merci beaucoup.
Je pense que
que le code médical est
aussi important pour les médicaux,
donc pour avoir un outil qui
m'assure et qui vous aiment
ce que vous avez fait,
vous vous en avez fait un Roslyn
pour cette analyse ?
Vous avez commencé
avant que Roslyn fasse un grand
truc ?
Oui, absolument.
En 2004,
et je pense que Roslyn
était RTM
dans Visual Studio 2015,
donc c'était plus que un décès avant.
Donc, par maintenant,
Ndipend n'est pas basé en Roslyn,
donc on a notre propre code analyser,
et nous n'avons pas encore utilisé
Roslyn, mais nous ne pourrons pas
changer notre code analyser
qui fonctionne bien et qui est extrêmement rapide,
mais dans le futur, on plane
d'avoir un bruit entre notre
modèle de code et le modèle de code rosin.
Donc, de cette façon, on peut proposer
plus d'interaction
de l'EDE,
on peut faire plus de choses
plus tard. Mais le truc est que Roslyn
a un grand différence, et encore,
il est en relation à la performance,
un grand différence entre Ndipend et Roslyn
c'est que Roslyn, elle fait tout.
100%
d'une seule caractère
dans votre source file,
n'est pas important pour Roslyn, parce qu'elle peut changer tout.
Alors, Ndipend est plus
plus focussé sur
ce que l'on veut.
Il ne regarde pas tout,
mais il
n'a pas besoin de
l'analyse, et parce que
il n'a pas beaucoup moins de données,
il n'a pas besoin de plein de données
que tu as dans Roslyn, c'est pourquoi il peut
être plus rapide.
Par exemple, tu peux comparer la performance
du réchaper, du visuel studio
et du diagramme de dépendance,
et tu peux voir que Ndipend peut être
10 à 100 fois plus rapide,
par exemple, parce que
de cette sorte de raison,
Ndipend ne tient pas
d'understand tout dans votre code.
Donc concrètement, Ndipend est intéressé
dans la dépendance,
parce que son nom est
Ndipend, et je crois que la dépendance
est vraiment à la cote
de la base de la base
de la base de la base,
c'est pourquoi il dit
que le code spaghettier, quand la dépendance
n'est pas bien managée
quand le code est entanglé.
Donc, il peut extraire
toute la dépendance, tu peux avoir un nouveau code,
et puis tout le mijot,
tu peux avoir un nouveau code, comme la complexité,
le nombre de méthodes, le nombre de fields, etc.
Il peut intégrer
aussi
des données de code coverage.
Ndipend n'est pas un tool de code coverage,
mais
il peut importe le data de code coverage
de la plus populaire, comme
dot cover,
like end crunch,
like visual studio coverage, etc.
Open cover, etc.

n'importe quel code coverage
process,
tu peux importer
de Ndipend le data,
et puis Ndipend
peut avoir des très intéressés règles,
parce que il sait
de la complexité, il sait de la coverage,
il sait de la base de la base.
Donc, typiquement,
tu peux demander, pour exemple,
de nouvelles méthodes
comparées à la base de base,
qui ne sont pas 100% covers, pour exemple.
Donc, tu peux avoir
cette ruelle, ou tu peux avoir un roul,
comme, dis-moi,
quelle classique est-ce que c'est 100% covers,
mais ce n'est pas encore 100% covers.
Ok, donc,
c'est assez intéressant de mixer
toutes ces choses.
C'est très important, je n'ai pas mentionné
encore dans le toul, c'est que
tout est basé
sur une clé de clé de c-sharp,
ok?
Donc, sur l'un de l'autre, tu as un modèle de code,
ce qui est le résultat de l'analyse,
le snapshot,
où tu as une modélisation de assemblées,
des spaces nommés,
classes, méthodes, fields, etc.
et de numération, etc.
Donc, tu as beaucoup de informations,
comme la dépendance, la complexité, etc.
Et puis, tu peux targeter
ce modèle avec des queries de c-sharp,
avec des API très effluents
qui ont été designées.
C'est un API indépendant.
Et tout est basé
sur l'indépendant.
Par exemple, toutes les rues,
les rues indépendantes
sont en fait des queries de c-sharp,
avec la description
en commun.
Ok?
Et par exemple, les rues, comme
je ne veux pas que
la nouvelle méthode
soit trop complexe,
peut être comme 1, si elle n'est pas correcte,
ce qui est un prefix non c-sharp.
Et puis, tout après le prefix,
le prefix est juste ici
pour dire que c'est une rue et on ne veut pas
plus de queries,
parce que plus de queries
sera un problème.
Donc, le prefix peut être
1, si elle n'est pas correcte, et puis
tu as un typique query,
comme de
m'application méthode,
où m.complexity
est plus que 30,
ok?
Et
m.wasAdded
qui veut dire
que c'est added depuis la base line,
tu as choisi
m.complexity,
m.coverage, etc.

Donc, c'est tout le système de rues
qui fonctionne.
Et je dois avoir
200 rues et queries
par default.
Ça veut dire que c'est un peu comme
l'ingpad, peut-être que tu utilises
l'ingpad, qui est un cool tool.
Tu peux targeter
d'autres modélisations,
c'est d'un DBE
ou un XML file,
et puis tu peux commencer à
faire des queries sur l'ingpad.
Et l'ingpad est un peu comme ça,
d'excepter que le modèle est de la qualité de code,
et la compréhension de code,
et tout ce qui se passe
dans ton base code.
Par exemple, tu peux mettre un métier
pour une query.
Par exemple, tu peux
avoir une query qui demande
des questions critiques,
ou des nouvelles questions
depuis la base line qui sont critiques.
Et là,
les résultats seront un liste
de questions critiques, et là,
tu peux obtenir un scala,
qui est le nombre d'issues.
Et puis, là, tu peux commencer
à plodrer
ce type de scala,
avec des temps. Donc avec des temps, tu peux avoir
beaucoup de charts, donc c'est un outil
de l'ingpad où tu peux plodrer
les temps, et voir si tu peux progresser
contre le default
de mesures.
Mais aussi, parce que c'est juste un
charpel, c'est très facile de write
les règles, et c'est très facile de
write ce qu'on appelle la métrique de train,
comme la métrique scala de ta base

Et nous avons un autre moyen, un autre
type de métrique qui est très utile,
qui est appelé la qualité de la gaitre.
Donc, encore une query de code
qui a été rétellée, une liste
avec un compte, ou juste un scala.
Et
de ce nombre,
qui est le compte ou le scala,
tu peux dire, comme, si
par exemple, le ratio de code de coverage
est sous 80%, par exemple,
ou un, si le nombre
de issues politiques
est sur 30%,
par exemple, ou tu as aussi
la quantification de la déptation technique
qui le management a beaucoup aimé.
Donc, basiquement, la déptation technique
est l'amant de travail pour fixer
les issues founds.
Donc, Indipent est très strict sur ça, et il y a
beaucoup de smart estimation
sur le détail technique.
Donc, tu peux avoir des politiques, mais
je ne veux pas que, comparé
à la base, nous introduisons
plus de 10 jours humains
de la déptation technique.
Ok? Donc,
c'est intéressant, parce que, pas seulement
depuis le début, Indipent
a beaucoup de queries et de rues
et des politiques, etc.
Mais ils sont extrêmement
facile à customiser,
parce que c'est juste une query
de charge. Donc, basiquement, tu as juste
ouvert l'éditor Indipent, tu les édites,
tu as les résultats en temps réel, parce que c'est très rapide.
Et puis, quand tu satisfais, tu te cliques
« Save » et puis, tu peux
vraiment paramétrer tout le
que tu veux.
Tout ce qui t'intéresse
à toi, tu as vraiment
la définition de « Done ».
Ok? Tu peux paramétrer
ça et puis tu as un outil
qui est totalement adapté à tout ce que tu veux
travailler et comment tu veux
faire de choses.
Cool! Donc, on a covering
beaucoup de choses là, mais en revanche
tu as parlé de la
link, tu as dit que tout est écrit en link,
donc, si tu as un rule custom
où tu as des links, est-ce
que tu as stored dans ton projet
qui peut mettre en charge le contrôle
au-delà de ton projet?
Oui, absolument. Ce qui est intéressant
c'est que c'est textuel
donc, il n'y a pas de projet,
pas d'assemblée
de dealing with.
Il n'y a pas de question d'indipent,
il est capable de prendre ton textuel
pour compilére et renner.
Ou si tu as un erreur de compilation,
il te le dirait.
Si tu as des warnings, il te le dirait,
bien sûr. Mais c'est
seulement textuel.
C'est normal que tu puisses
store-t-es tes règles dans ton projet
et tu peux attacher ton projet,
je veux dire ton projet d'indipent
qui est n°n-d-proche
qui est juste xm-aile
avec des données formatées
à l'intérieur, donc c'est très facile
d'évaluer les règles d'indipent
avec un source file
avec Veeam, Notepad
ou tout. Et aussi, tu peux
avoir des règles de rues
que tu peux partager entre les projets.
Donc, nous avons beaucoup d'useurs
qui ont beaucoup de projets,
encore, je referai de discuter
avec des legacies massives
et les legacies purées.
Je ne fais pas que les legacies, mais beaucoup.
Ils veulent avoir des contraintes
d'entreprises, de règles
de rues, donc tu peux partager
entre les règles.
C'est un truc très intéressant
et, encore, c'est très facile
pour vous donner une idée,
il peut compiler les 200 règles
en moins d'un second
et, en large enough
de codebase, les règles
vont prendre moins de 5 secondes
pour passer
toutes les règles, donc tu peux avoir
tous les problèmes, tous les nouveaux
problèmes comparés à codebase
et tous les règles de codebase
de la estimation technique
aussi,
tous ces règles, tu peux avoir
dans le studio visual
ou dans le standalone
en juste quelques secondes.
Comparing avec le autre truc
qui est très bien analysé
et qui est très bien édité
qui est absolument bien édité
mais si tu veux
un plus de 100 feet de view
de choses, ça va prendre très de temps.
Par exemple, dans le resharp, tu as un mode
où tu peux avoir tous les problèmes
mais la chose, si tu fais ça
et que ça dépend, il en a plus de 1 heure
pour aller tout à l'heure
et essayer de vous donner
quelque chose. Je crois
que c'est important de être fast
avec ce genre de approche.
C'est le tout developer
cycle, n'est-ce pas?
Tu veux vraiment de très vite le feed-back
comme tu es codé?
C'est très important, et plus important
pour le tâneur.
C'est intéressant de te dire
que tu as mentionné le link pad
parce que tu as mentionné quand tu parles
de l'indépendance en créant le link.
Je pense que c'est un peu de tâneur
quand j'ai utilisé le code
c'est à dire Ctrl Shift F
pour trouver quelque chose dans tous mes scripts.
Et ça a créé un nouveau query
qui était le link
pour faire le fine.
Ça ressemble à ce que tu fais
où le utilisateur de l'indépendance
modifie le link que tu génére.
Oui, et
les tools ont créé
à la même time
en
2007
quelque chose comme ça.
En fait, le link était en 2008.
Le link était en 2010
en 2010.
Le link a juste été
après le link.
Mais à un point que Microsoft a dit
maintenant que tout le query est linked
et en fait, à ce moment,
nous avons déjà notre propre
langage query qui a semblé
un SQL.
Mais c'était beaucoup moins powerful
que le link.
Bien sûr, qui peut être
plus powerful ? Vous ne pouvez pas faire quelque chose
plus powerful que le link.
Maintenant, c'est intéressant parce que le link est
plus powerful que...
Et tous nos utilisateurs, qui sont un developer
typiquement des knowings,
ils peuvent jouer avec les tools.
Mais nous avons aussi créé beaucoup de queries.
Juste pour vous donner un exemple,
vous avez Independent to your Visual Studio.
Vous avez ce large project
que vous voulez regarder à l'architecture
à l'intérieur, parce que c'est comme
Antanglène,
comme le grand large project, en fait.
Donc, vous allez juste aller au solution
Explorer, vous cliquez sur le projet.
Et puis avec Independent, vous avez
la menu qui montre moi
le graph de la dépendance.
Donc, vous cliquez juste là. Et ce qui s'est passé
dans la mode, c'est que Independent
va générer une query code
pour former tout ce qui est intéressant
que vous avez dans votre projet,
tous les spaces de nom, toutes les classes, tout ça.
Ce qui est le plus délicieux
que vous avez été montré.
Il édite la query, la compagnie de query
et on le met en place.
Et puis Independent, vous cliquez sur le résultat
et vous le printez
sur le graph. Et tout ce que je dis,
c'est typiquement plus ou moins que un second.
Ok, donc c'est très rapide.
Mais pas seulement vous avez un graph
de exactement ce que vous voulez,
mais aussi
sur votre côté, vous avez un code query
que vous pouvez éditer
et refiner.
Donc, peut-être que vous voulez
juste regarder quelques spaces de nom
dans vos assemblées. C'est très facile
de aller au query et refiner
et ensuite exporter les résultats
sur le graph, pour
voir exactement ce que vous avez
intéressant.
Merci beaucoup.
Oui, bien sûr.
Donc, c'est la
actionnabilité.
Donc, de ce que nous savons,
comme on l'a compris, nous travaillons très
très vite sur la vitesse
et sur le UI.
Mais Independent, cela a beaucoup de concepts
qui ne sont pas nécessairement
plus facile pour
les gens.



Donc, vous pouvez
voir les résultats
sur lesquels vous avez
des résultats.
Et vous pouvez voir
les résultats sur lesquels

Et vous pouvez voir
les résultats sur lesquels


les résultats sur lesquels
vous avez des résultats.

Donc, je vous ai dit que
les résultats sur lesquels vous avez
des résultats sur lesquels vous avez

des résultats sur lesquels vous avez
des résultats sur lesquels vous avez



des résultats sur lesquels vous avez


des résultats sur lesquels vous avez
des résultats sur lesquels vous avez
des résultats.
Nous avons essayé de
sur mutually
contre la digamos



partage,
des résultats
sont beaucoup jeżeli,
mais les des résultats
Makraz

classes,
des désisc?]
de
unürdigé
que l'on trouve comme component ou module.
Vous avez les assemblées, les assemblées sont les files physiques.
Ensuite, vous avez les espèces de nom dans les assemblées.
Les espèces de nom, c'est un moyen logique de organiser votre téléphone.
Ils peuvent être utilisées en bothant comme présentation de l'appli
pour agir votre appli dans plusieurs espèces de nom.
Mais les espèces de nom peuvent aussi être utilisées
comme un moyen de avoir des components logiques dans votre assemblée
car je ne vous dis pas considérer les assemblées comme component.
C'est mieux d'avoir un grand assemblée
avec un espèce de nom bien organisé.
Et ensuite, vous avez le classe.
Et typiquement, un classe est trop petit et trop chaleur
pour être un component ou un module.
Typiquement, vous avez un groupe de classe
d'interfaces de numération
pour mettre dans leur espèce de nom.
Vous dites que ce espèce de nom est mon component.
Parce que chaque classe a une responsabilité
dans le component ou chaque interface.
Et ici, on est typiquement dans le concept solide.
Et ensuite, vous packz tout dans un espèce de nom.
Et ensuite, vous avez votre assemblée
avec des centaines ou des centaines de espèces
qui interagent ensemble.
Et c'est comme ça, dans ma opinion,
vous pouvez avoir une bonne software
et une bonne compréhension.
Donc, quand vous ouvrez le diagramme de dépendance
de quelques applications,
typiquement, vous avez plusieurs projets.
Et dans chaque projet, vous avez un assemblée.
Donc, le bon chose est que ce ne peuvent pas être
le cycle de dépendance entre projets.
Le studio visuel prévient ça
et le salle de MS Build prévient ça.
Donc, vous avez toujours un projet de niveau bas
et un projet de niveau haut.
Et un projet de niveau très haut.
Et typiquement, le projet de niveau bas
est fait d'interface.
Si vous êtes bien, vous êtes dans le principe solide.
Donc, de cette façon, vous ne vous partagez pas
entre projets, mais vous partagez des abstractures.
Et puis typiquement, vous avez un domaine
sur lequel, un ou plusieurs domaines.
Et puis, sur les domaines, vous avez un environnement
qui peut être un web server,
qui peut être un UI, qui peut être un DB,
ou quelque chose d'autre.
Donc typiquement, les projets sont liés à un truc comme ça.
Donc, le premier que vous devez faire
est parce que maintenant, vous avez le sens
de visualiser tout.
Vous avez un bon graphisme de dépendance.
Tout d'abord, vous pouvez vérifier avec vos yeux
dans le graphisme de dépendance
que vous avez cette sorte d'architecture.
Aujourd'hui, il y a des gens qui sont
en train de faire un graphisme de clef,
qui est une des choses qui sont très intéressantes.
Le mouvement, c'est encore,
c'est Mr. Ankelbob qui a coigné.
Vous avez besoin de lire ce livre.
Donc typiquement, vous voulez avoir l'interface plus bas,
puis vous voulez avoir votre domaine.
Et votre domaine, c'est très important
que ce soit seulement un objectif de Poco.
Poco, c'est un objectif de plein de célébrations,
ce qui veut dire que vous pouvez dépendre
des choses comme les pièces, les intégres,
et des propres tips primaires comme ça.
Mais vous n'êtes pas supposés de faire votre domaine
de file access, de DB access, de web access,
de UI access,
de tout ce qui est appelé infrastructure.
Donc vous pouvez vérifier que votre domaine d'assemblée
n'est pas accessé à toutes ces choses.
Et en fait, avec l'indépendance,
c'est très facile de lire ce genre de règles.
Vous pouvez très facilement lire les mots.
Ici est mon domaine, je ne veux pas mon domaine.
Et puis, vous pouvez utiliser quelque chose
comme, par exemple, système.io,
ou système.inform, ou webform, ou quoi-même.
Ispeed.co, ou quoi-même.
Donc c'est très facile de avoir des règles.
Pour premièrement, visualiser que votre domaine,
vous avez une architecture clean,
et second, c'est facile de renforcer
ce que vous voyez ou ce que vous voulez.
Et vous pouvez aussi lire des règles,
et puis votre custom rule pour ça.
Et puis, vous avez sixe tous les issues
que vous avez dans cette règle,
jusqu'à que vous êtes très satisfaits
avec votre architecture.
OK?
Un autre point que vous voulez utiliser,
l'indépendance de diagrammes 4,
est de désentangler votre base de code.
Donc ici, ce que vous allez faire,
c'est que vous allez avoir une vue
sur les components qui sont dépendants
entre eux.
Typiquement, vous voulez un diagramme de la ligne de la carte.
Donc, l'indépendance peut vous aider
parce que ça a un système de couleur.
Et quand tout dépend de tout,
il y a plusieurs features pour vous dire ça.
Par exemple, vous avez un bouton de cycles.
Donc si vous cliquez sur ce bouton,
une autre code query est édite.
Et cette code query est listée
dans tous vos assemblages.
Et dans chaque assemblage,
elle est listée dans tous les cycles de dépendance
entre les spécifiques.
Et puis vous pouvez exporter chaque cycle
au diagramme.
Et vous pouvez immédiatement identifier
ce que la code est très désentanglée
et ce que vous pouvez faire
pour désentanger parce que
dans la même query dite,
vous avez des conseils
sur ce que vous pouvez faire pour désentanger.
Donc, ce sont des usages
du graph de dépendance.
Et puis, il y a des usages
durant vos développements,
typiquement, quand vous êtes,
par exemple, touchant des classes de très haut niveau,
vous voulez une interface,
vous voulez savoir tout ce qui dépend de cela
dans un diagramme de col.
Donc, avec un dépendance,
vous pouvez obtenir un diagramme de ce type de cliquet.
Vous avez beaucoup de diagrams
comme celui-ci.
Donc, par exemple, vous avez deux projets
et vous voulez savoir
que l'I est en train de utiliser l'D
et vous voulez savoir
que l'I est en train de utiliser l'I de l'D,
par exemple.
Donc, encore une fois,
l'I est en train de utiliser l'I,
vous pouvez voir cela sur le graph
comme un edge,
vous avez juste double-clique l'edge
et immédiatement,
vous avez tout de l'I
qui est en train de utiliser l'I de l'D
et vous pouvez obtenir un diagramme de cela.
Donc, il y a beaucoup de usages
du graph de dépendance,
parce que, comme je l'ai dit,
quelque chose d'important
dans le code base
dans le développement de la software.
Je ne l'ai pas imaginé.
C'était un tool
pour un team qui fait une session de mab
où vous avez un team en s'en train de se faire
en regardant ces usages
et en justifisant des questions,
pourquoi est-ce que ce component
parle à ce component?
Je vais vraiment essayer de discuter
à avoir ces diagrams
pour ouvrir la discussion
entre les teams.
Je peux imaginer que ça a été
tellement fort.
Oui, et aussi, par exemple,
parce que tout est quantifié,
comme le concept technique
et la complexité,
le code coverage, etc.
Tout est quantifié et courriable.
Vous pouvez commencer à penser
de ce que l'on a fait dans ce component.
Et parce que c'est objectif,
on peut proposer à notre manager
que vous devez regarder tout ce débit.
Pour longtemps,
nous avons dit que ce component
était un grand problème pour nous.
Et je pense que c'est une situation
très vraie pour
beaucoup de teams.
Et puis, vous pouvez aller à votre manager
et dire que maintenant,
nous voulons avoir le temps
parce que regardez ça
et considérez-le,
ça n'est vraiment pas bon
et nous voulons changer.
Donc, c'est un outil pour
le manager, le team leader
ou pour le développeur
qui veut être convaincu
de faire le développeur ou le manager.
Donc, c'est aussi possible.
Une des features que j'ai
sur votre site,
dans la liste de utilisations,
c'est de détecter les changements
des API.
Ce qui semble vraiment intéressant.
Donc, est-ce que ça automatique
que vous faites
que ça va affecter
l'interface du côté du côté
comme les réquestions, les détections responsables,
la route en fait,
le URL,
quelque chose comme ça,
ça va vous dire
que quelque chose,
vous avez changé l'outil,
l'interface publique.
Oui, quand l'indépendance
a commencé,
comme plus de décennies auparavant,
c'était ce genre de
trois features accidentales.
Nous avons...
Ce n'est pas un feature
qu'on ne doit pas penser.
Mais, suddenly, on se sent
que nous avons tout,
nous avons besoin de faire
quelques règles
et nous avons les features.
Donc, un lot of features,
what was very tough
was the analyzing system,
the code modern,
the link stuff.
But then,
then from there,
this is why Independ
can do so many things
because it has everything.
It knows very well
your code base
and also your code base
evolution since the baseline,
just since the baseline.
So, typically, what happened
at that time,
look at that.
We know which class used to be,
for example, public
or which interface used to be
public, which method used to be
public.
And because we have a diff
since the baseline,
we are able to know
if a public class become
internal or private, for example.
Or we can say, hey, this interface
used to have 10 meters
and now it have only 8 meters,
which means that if some of your clients
are implementing it,
they got broken.
Okay.
So, because we get all this
detailed data,
it was very easy actually
to write some rules,
some default rules
that you get out of the box.

It was very easy to write this kind of rules
to detect, typically, the API breaking changes.
And again, for example,
I was referring to the CEMEN team
with tons of legacy.
And I can say they are very strict.
There are so many developers
that they have to be extremely strict
in terms of contracts,
in terms of API,
because they really need to
modularise things,
because the legacy is so big.
So, I can say that one of their major interests
is to make sure that they are not breaking
the API they are using
to talk between each other,
because that's very important for them.
I love hearing stories
of accidental features
that tend into big features, just because...
Yeah.
Just because of the way it was built in the first place.
So, if N depends does detect
that you've made a breaking change,
can that be hooked into
however you do versioning?
So, for example, maybe using
Git version to do your versioning
and semantic versioning.
Can N depends then tell that
to increment the major version, for example?
Or would it always just be a failure?
Something's broken, so the build's going to fail.
Is that how it would work?
For now, unfortunately, we are not Git integrating,
as I said earlier.
So, for now, it works side by side
with Git, but you can manage
very easily your versioning
and depending on your own.
Because it's just a file system,
so it's very easy to share
with your developer,
it's very easy to adapt
to exactly what you want.
One thing compared to Git
is that N depends understand
more about your code in the sense
that because the primary source
of analysis
is your compiled code,
okay, but also N depends
on analysis code, code coverage, etc.
N depends can distinguish
in changes
when it does this
into our model,
because we have a model for code base,
but we also have a model for the diff.
And into the model for the diff
in the baseline, N depends can make
a difference between a code
behavior change.
For example, you have a method
and you're changing its body,
then it's a change.
It can differ that with a
format change,
for example, you introduce
subspace, or you're re-formatting
your code. So, for Git,
it's a change, format change,
or behavior change is the same.
Or maybe you can add some comments
so N depends can detect it's a comment
change and not a behavior change.
And this is very practical because then
you can change some formatting
or some comments, but N depends
will still see that the behavior
is the same. And the behavior
is king, right? It's very important.
So you can treat differently
a behavior change
with just a formatting change,
which I believe is very important
because typically, if a method didn't change
since it's in production,
since the last release,
if it's working well in this release,
you can add comment or
change it, etc. But then in the next release
it will work well also
because it actually didn't change
the behavior, it's still exactly the same.
So this is one interesting thing.
Some other changes you can
spot is visibility change,
for example, a public method
became private, for example,
or documentation change
and stuff like that.
So yeah, we not yet
that we are totally integrated
with Git, but on the other side
you can have some interesting
stuff to do. And it has also
this trending database
that it maintain, which again
is just a file, actually, physically.
But the trending, as you remember,
is just plotting.
You have some special query that are here
to put put a scalar, and then you can
do some charting to follow
the evolution of your code base,
for example, the evolution of your code coverage
or the number of classes,
the number of defects, etc.
So earlier you were mentioning
the build failure,
which is something very important
because nowadays everybody
has a CCD.
And everyone wants to be
a worm when something
is going wrong.
So TP, this is why you are writing a unit test.
This is why you want them to fail
when there is a regression
or a new bug or stuff like that.
And NDPen works the same, like it have
all these rules, and
you want to
fail upon some condition.
The condition is not necessarily, I don't want
any issue or any new issue.
NDPen can be much smarter than that
thanks to the notion of quality gates.
So as I explained earlier,
quality gates is just a C-sharp link query.
On a particular aspect
of your code base, it can be code coverage,
it can be number of issues
or severity of issues.
It can be technical debt, amount of technical debt.
And again, everything can be
restricted against the baseline.
So typically you can write
I don't want more than
10 new one days of work
of technical debt since the baseline.
And it's very easy
to take the existing quality gate
and to adapt them.
And this way you can really
define your own definition of dawn.
Personally, I like to be
dawn when all my
class is 100% covered
except when the UI class
that are very hard to cover.
But upon that,
86% of the all NDPen code base
is covered by tests.
And this is very important
with all the assertions also.
We put assertions everywhere
not only in tests but also in code.
When we run our test
in 26 minutes
there are more than 16 millions
of assertions that are executed.
So that's a lot of assertions
both in tests and in code
that can really verify
that we don't introduce new bug
and new regression.
And then you can have some quality gates
about all those stuff
that can tell you
we are not good here
and we are not dawn
because of your very own reason.
So I think it's important
to let the user
customize
it's a definition of dawn because
from what I've seen we all have a different way
to consider dawn
some typically it's very shallow
like ok the code works
we don't we can release
but if you are serious
you don't want any regression
you want to have all your tests
and coverage and stuff like that
so 20 minutes can be very good
at 8 minutes.
Yeah we could have a whole episode
on definition of dawn
and what should be in it because
I've seen all ranges from
as long as you push to get
then even before CIC
de deploys, right we're going to mark
this Jira ticket as done
and it's like no you can actually test it
before you do anything at least
but yeah that could be a whole episode
so shall we do dev tips?
Oh yeah sure
yeah yeah I have a few
so one thing
so I mentioned earlier
that the NDPEN will run
on linux and macOS
because most of our code is
.NET Stenar which means that the exact same binary
can work
into a .NET framework process
or into a .NET 5
or 6 process
which is very cool.
Something that helps a lot
to develop that
and to test that was to use
the Windows of System Linux
WSL
which is now in version 2
which is already quite mature
and it was extremely
convenient
to because
simply because it avoid
having to switch back and forth
like a visual virtual machine
or linux virtual machine
or maybe another machine
or whatever.
Actually with WSL
you really have
a full Linux
as an application
into your Windows system
ok so that's
already pretty cool
but what is even cooler
is that Visual Studio is aware
of WSL
which means that
when you hit the F5
debug button
it's gonna debug into linux
your application
so it's really marvelous to test
all your application into linux
it's extremely
productive and it was really
really helpful for us
so it's not
so easy to get started with
it's not at all very complex
but
what I do when I spend time
on a technology like this one
until I really fully master it
to get the most of it
I write a blog post with all the
cavets I got from it
for example one cavet I can say
is that UPDV file
must be compiled as portable
ok because if they are not portable
they are not gonna work on linux
so you must first ensure that UPDV file is
available. So there are many
warnings and advices
to work with WSL
like this one
so I put them all into a recent
blog post on the independent
on the independent website
and I like also to share that with
me later and also with the team
so everyone is on the same page
ok so I write
a detailed post
about that and
it was a few weeks ago and I think
it received a lot of
views and people were quite happy
with it because it contains
a lot of advices on it
so if you are careful about
migrating or working with linux
and dotnet in linux
maybe and you still like your windows
developing on mac
for example then you can
develop WSL and get all the tips
from the blog post
Yeah WSL too
it's really really nice now we actually had
on episode 7 Stuart Leakes
joining us talking about WSL
and dev containers
so all this kind of thing where you can just
use VS code and spin up all your dev
environment and shared config
like you're describing just within
containers and it's not
really a workflow that I've properly played
with yet but I would really
want to start playing around with dev containers
and all this kind of stuff. I used
WSL too from time to time
but mostly it's just for docker stuff
rather than dev containers and all that kind
of stuff but yeah it's definitely
really interesting seeing the interaction
between windows and linux
like linux now with WSL too
so my dev tip is
it's just a quick productivity tip
about using virtual desktops
this is just something I've started doing more recently
to separate out what I'm working on
from other stuff
so it just helps me keep focused
and less distracted so it's the old
out of sight out of mind thing where
I'm keeping things like email, twitter
just like whatever just completely
in another virtual desktop so it's just
I can't see it now obviously I could close
those things too but
I just find using virtual desktops is a nice
way of not having to close everything
but keeping things separate and hiding them away
it just helps me keep more focused
on what I should be working on.
To be in the flow
which is the most precious
asset a developer
can have is
to have a routine
to end up in flow
for an hour and two and be super
projective during that flow
and this is why performance matters
much because if your compilation process
is taking 15 seconds
during that 15 second
you want to flip on the social media
or prepare a coffee or whatever
and you just break your flow
and that's why the speed is extremely important.
Yeah exactly
you mentioned at the start all the cool things
that are coming to .NET 6
in novembre.
One I'm really looking forward to is the hot reload functionality
where as soon as you save something
if it's a like a website you're doing
or a mobile app or whatever it is
boom it's just updated straight away
and just cutting down that developer flow
so as you say even 15 seconds is enough
to make you your brain wander
off to social media or something.
Yeah absolutely
oh yes 15 seconds is really bad
you have personally
because no indepence is
as soon as you do this is a quite large project
so what we do
is that we have some
smaller solutions
when we want to just work on the domain
on the core, on the query system, on the what
so just to have a less project
much less progress project
so this way the compilation is
normally if it's a tutorial it's supposed to understand
when it doesn't have to compile an assembly
but it doesn't work as good as I would like
so it's important to focus
on a very few
projects to just make sure
that you get the best performance
and that you don't lose your time
because that's at the end of the day
that's really
what makes a difference if you want to go to have a jogging
or spend some time with your kids
or whatever
at the end of the day that can make a large difference
to have this to be very careful
with your development environment
and to make it show it will be as fast
as possible.
Yeah definitely time is a resource
you can't get back once you've spent it
Yeah, absolutely
So, before we wrap up
what's the best way for our listeners to get in touch with you
if they have any questions or anything
Yeah sure, just Patrick
with a CK
at arobas at independent.com
and that's my direct mail address
and
if you want to play with the product
just go to independent.com
you have a download
3 trial
Full Faturade
14 days
extra 14 days
ok, so you can
in 5 minutes, typically in 5 minutes
you can have an NDPen
Installed already that already analyzed
your code
and that already try to give you some
advices about it
try to shed light some stuff
so typically in 5 minutes there is no complex installation
just a zip file
you just un zip it somewhere
there is no registry
or complex installation
or even have to go to an administrator
or whatever
so it's very straightforward
it's just exactly like I want to run your own assemblies
ok, just you just speed it somewhere
and you hard drive
just run it
and typically in a few minutes
it's very lightweight
it's only 18 megabytes
and the next version will be only 14 megabytes
we'd like to do more with this
and typically
the community call it
the Swiss Army Knife for Developer
so as you understood there are many features
so you can just imagine
which feature you need to improve
and certainly you will find it in NDPen
and you can refer to our use case page
and you have like 20 use case
to see which one switch your best
to get started
and then make the tool actionable
from the beginning
and make the most of it
fantastic
ok, so a big massive
thank you for joining us
it's been really great having you on
and I really need to go where and play a bit more with NDPen
now and just like run it on more projects
and then start crying
as I see how bad my code actually is
thanks very much
for the podcast
it was a very good moment
no problem
and thank you everyone for listening
a quick reminder that this podcast is sponsored by Everstack
which is my own company
providing software development and consultation services
for more information visit
Everstack.com
and if you enjoy the podcast please do help me spread the word
on social media
I normally use the hashtag onhungled exception
and I can be found on twitter at drakan
d-r-a-c-a-n
and my d-n's are open
and my blog danclock.com has links to all my socials too
and of course we will include links
to all the things we've mentioned today
in the show notes
which can be found on
unhungledexceptionpodcast.com