SnowCamp 2022

Pourquoi est-ce que nos chiffrages sont si souvent à côté de la plaque?
Pourquoi le besoin métier est-il à ce point systématiquement mal cerné?
Est-ce vraiment pertinent d'écrire des tests avant de coder?
Autant de questions dont la réponse peut se trouver dans l'étude de nos biais cognitifs!
J'aurais d'ailleurs pu pompeusement titrer ce talk: "Que nous apprennent les neurosciences au sujet de la vie des projets?".
Mais on ne parlera pas ici de neurosciences, juste de quelques bases de psychologie sociale ou cognitive adaptée au monde du développement logiciel.
En prime, et en toute gratuité, vous repartirez avec des armes, des outils concrets pour mieux combattre des travers que nous avons tous!

J'ai commencé le développement par passion vers 9 - 10 ans, pour en faire mes études et mon métier. Mais voilà : hasard ou modèle classique de carrière en France, les développeurs de plus de 40 ans ne sont pas légion : les évolutions de carrière proposées nous orientent vers de l'encadrement, toujours plus de réunions, .... et toujours moins de code !

De mon coté, au fil du temps, je suis devenu architecte. Ce métier est passionnant: il me permet de suivre les évolutions du monde informatique pour choisir les meilleurs solutions mais mécaniquement, il diminue ma part de développement.

La flamme du développeur n'étant pas éteinte (et accessoirement, pour moi, me permet de faire mieux mon métier d'architecte) j'ai cherché comment continuer à développer (et suivre les dernières nouveautés).

Après de (trop) nombreux side projets abandonnés, je me suis naturellement tourné vers l'Open Source.

Durant ce talk, je reviendrai sur le pourquoi de ce choix et ce qu'il m'a apporté. La participation à des projets Open Source peut vite être impressionnante, voir décourageante pour plein de (mauvaises) raisons : syndrome de l'imposteur, sentiment d'être perdu face à l’immensité de projets, ....

Ce talk sera aussi l'occasion de partager mes trucs et astuces, mes erreurs mais aussi les points de vigilance pour débuter.

Si à la fin, j'ai pu donner envie aux participants de se lancer ou d'oser se poser la question, alors le pari est gagné !

Have you ever imagined that your task as a User Interface Developer would one day become that complex? We had to support responsive design, and it was already difficult at some point. Truth is it was only the smallest of our daemons.
It's 2021. We still have to address devices with very non-homogeneous screen sizes, but also very diverse SoC, performance variations, users prefs-based themes, network issues from Edge to 5G or WiFi. And the list will go on growing.
Facing this, we can't continue to handle interfaces the way we did for the last years. We need to shift left, and burn into our Design Systems how to address configurations depending on the context. By moving the responsibility to the components level, we would be able to test, adapt, and deploy at scale complex interfaces without having to fear unexpected issues on some configurations.
Here's how to proceed to build context-proof UI as an Interface Developer in 2021.

🧑‍💻  En tant que dev Java, C# ou encore TypeScript nous sommes habitués à avoir dans notre IDE préféré toutes sortes d'informations sur les librairies que l'on utilise : signature des méthodes, documentation, code highlight, autocomplétion etc 🙃   Mais lorsque l'on ouvre un template HTML l'expérience n'est plus la même, on a bien quelques infos si on utilise des balises standards ou un framework UI très populaire mais plus rien dès qu'on s'en écarte un petit peu. Et s'il y avait un moyen pour que les lib UI embarquent et partagent toutes les informations nécessaires afin de fournir la meilleure DX possible ? Et ce de la même façon pour une lib Angular, Vue, React, Web Components voire des choses plus exotiques comme htmx ou les classes CSS `fa-` de Font Awesome.

🦸   C'est la promesse faite par les `web-types`, un standard open-source de documentation de composant web présenté il y a quelques mois. Je vous propose de découvrir ensemble ce qu'apportent les Web-types, se pencher sur leurs fonctionnements et voir comment ajouter des types a un de ses propres composants.

Il est possible d’écrire des opérateurs en utilisant à peu près n’importe quel langage de programmation pour peu que l’on puisse faire des requêtes REST…
Force est de constater, néanmoins, que Go est le langage que la plupart des développeurs choisissent quand ils doivent créer un opérateur. Pourtant, au vu de la dominance de Java dans le monde de l’entreprise, il serait intéressant de pouvoir utiliser cette abondance de développeurs Java pour pouvoir écrire des opérateurs sans devoir apprendre un autre langage.
D’autre part, en suivant la philosophie DevOps dans laquelle les développeurs sont aussi chargés de l’opération de leurs applications en production, pouvoir utiliser le même langage pour créer les applications et contrôler leur parfaite opération procure un bénéfice évident. Pour autant, Java n’avait, jusqu’à récemment en tout cas, pas une bonne réputation pour le développement d’applications Kubernetes…
Alors, qu’est-ce qui a changé pour rendre Java plus attractif pour développer des opérateurs?

Cette présentation présentera le projet Java Operator SDK pour montrer comment il est maintenant non seulement possible mais même presque plaisant d’écrire des opérateurs en Java.
-------------------------
It's always been possible to write operators using pretty much any programming languages. That said, Go has traditionally been the go-to language to write Kubernetes operators. However, with Java's dominance in the enterprise world, it makes a lot of sense to want to capitalize on that wealth of Java knowledge to write operators without having to learn another language. It also follows the DevOps philosophy that, developers being in charge of deploying and maintaining their applications in production, they might want to be able to do so using the language they are the most comfortable with. So far, though, Java has been quite ill-suited to write Kubernetes applications for multiple reasons: some intrinsic, some external to the language itself.
This talk will explain why this situation has changed in recent years and will introduce the Java Operator SDK project which aims at making it simpler to write operators in Java.

Live coding démo d'une application Micro Frontend rassemblant des modules en [Angular](https://angular.io/), [AngularJS](https://angularjs.org/), [VueJS](https://vuejs.org/) et [React](https://reactjs.org/) en utilisant le plugin Module Federation de [Webpack 5](https://webpack.js.org/).

Le terme Micro-Frontends est apparu pour la première fois dans [ThoughtWorks Technology Radar](https://www.thoughtworks.com/radar) à la fin de 2016. Il étend les concepts de micro-services au monde du FrontEnd (désigne les éléments que l’on voit à l’écran et avec lesquels on peut interagir).

Le Micro-Frontend est donc une architecture particulière pour une application frontend qui a pour but d'assembler plusieurs modules d'applications différentes pour former ensemble une seule et même application.

L’idée derrière Micro-Frontends est de penser à un site web ou une application web comme une composition de fonctionnalités qui appartiennent à des équipes indépendantes. Chaque équipe a un domaine d’activité ou une mission qui lui est propre et dans lequel elle se spécialise. Une équipe est interfonctionnelle et développe ses fonctionnalités de bout en bout, de la base de données à l’interface utilisateur.

[Webpack](https://webpack.js.org/) est un modules bundler open source. Son objectif principal est de regrouper des fichiers JavaScript pour les utiliser dans un navigateur. Cet outil est également capable de transformer, regrouper ou empaqueter à peu près n’importe quelle ressource.

Dans sa version 5, Webpack apporte un nouveau plugin appelé [Module Federation](https://webpack.js.org/concepts/module-federation/), celui-ci permet d'assembler des fichiers et modules "distants", est-à-dire exposés sur une autre machine.

Ce plugin ouvre les porte d'une nouvelle façon de réaliser des applications Micro-FrontEnds et c'est ce que je vous propose de découvrir.

Aujourd'hui la dans la plupart des articles, des conférences et des exemples qu'on peut voir à propos de WebAssembly (Wasm) sont principalement basées sur l'utilisation de WebAssembly dans le browser. Le browser possède un runtime capable d'exécuter du wasm mais c'est loin d'être la seule possibilité. De plus en plus de cas d'usages côté back-end font leur apparition, par exemple si on veut avoir un équivalent de function as a service capable d'exécuter du wasm on va pouvoir ouvrir les portes à différents langages capable de compiler vers du WebAssembly. Il y a même l'apparition d'unikernel écrit pour exécuter du wasm, on a aussi krustlet qui nous permet de lancer un morceaux de wasm au lieu d'un container dans kubernetes, beaucoup de cas d'usages dans la blockchain sont notamment réalisés. Cet écosystème est en plein effervescence et nous en sommes au début. Faisons ensemble un tour de ce qui est faisable aujourd'hui grace à cette spec et les outils mis à disposition pour nous aider à l'utiliser dans nos propres cas d'usages autre que celui du frontend.

Docker, Kubernetes, Terraform, Helm ... Ces outils vous disent peut etre quelque chose, vous les utilisez peut être au quotidien, mais saviez vous qu'ils étaient fait en Go ? En effet, le langage Go est un langage qui a le vent en poupe depuis ces dernières années, utilisés pour faire des microservices, de la cross-compilation, par des entreprises exigeant des performances élevées et de la résilience.
C'est un langage pratique, facile à prendre en main, typé et possédant un écosystème riche.
Et c'est vrai, créer un serveur HTTP ou encore une application CLI en Go ne prends que quelques minutes. C'est parfait ... ou presque !
Il est également facile de faire des erreurs dans ce langage ;-).
Nous allons voir dans ce talk, sous fond de ReX et de vécu, des tips et les erreurs courantes, leurs solutions et comment les éviter.

Depuis quelques années, on ne compte plus le nombre d'entreprises s'étant fait dérober des données sensibles. Il est intéressant de noter que les failles utilisées sont généralement toujours les mêmes : XSS, SQLi, RCE, etc.

Pour un néophyte, ces termes peuvent paraître difficile à comprendre, mais en tant que développeurs, vous savez probablement ce qui se cache derrière (ou au moins en partie).

Mais connaissez-vous vraiment les risques encourus ?
Savez-vous réellement comment exploiter ce type de faille ?

Dans ce talk, nous reviendrons sur des cas concrets (comprendre : des failles que l'on a identifié et reporté sur des "vrais" sites et peut-être même des applications que vous utilisez tous les jours).

A chaque fois, nous vous proposerons :
- Une mise en situation en reproduisant la faille rencontrée sur une application test.
- Nous montrerons les outils que nous avons utilisé pour identifier le souci et le POC mis en place pour le report.
- Nous reviendrons sur les conséquences possible si cette faille avait été identifié par une personne malveillante.
- La correction de la faille.

Pour avoir une meilleure vision de la menace qui pèse sur votre application, il est devenu quasiment indispensable de connaître les outils utilisés par les pentesters / hackers.

Aujourd'hui, nous vous proposons de vous partager nos astuces / nos outils mais aussi notre vision de développeurs passionnés de sécurité afin d'avoir une meilleure vision des menaces qui pèsent sur votre application !

Cela fait une dizaine d'années que nous essayons d'appliquer les principes du DevOps pour livrer plus vite en production. Sur le chemin de l'unification des devs et des ops, la sécurité est encore un frein. Alors faut-il ignorer la sécurité et attendre la fuite de données ou bien agir maintenant, s'organiser, et automatiser.

Le DevSecOps nous promet d'intégrer la sécurité dans nos pipelines CI / CD mais aussi dans notre processus de développement pour que la sécurité fasse partie intégrante de notre culture et ne soit pas un goulot d'étranglement.