[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?Christophe HERAL
Les principes SOLID font partie des bases de la programmation orientée objet. Cependant, qui n'est jamais intervenu sur un projet avec l'ensemble du code fortement couplé ? Avec de ce fait de grandes difficultés à le tester unitairement ? L'objectif de cette présentation est de démontrer sur un cas d'usage comment l'utilisation d'interfaces et l'injection de dépendances va nous permettre d'améliorer ce code et de le rendre testable.
Chia sẻ về Clean Code tại XPDay Vietnam 2016.
Clean Code là gì?
Tại sao phải Clean Code?
Clean Code có khó không?
Một số ví dụ thực tế về áp dụng Clean Code.
Frequently deploying to production puts bigger pressure than before on DevOps to make sure the good, qualified application is provisioned with no mistakes. This session will explore some common pitfalls with traditional Continuous-Integration that increase risk, introduce manual input and human error, and generally make DevOps cringe before hitting the “deploy” button.
We will then demonstrate automation techniques that overcome these issues using popular tools, like Maven, Gradle, your CI server, custom scripts and a Binary Repository. Whether you are building software for the cloud or in-house, this presentation will show you how to have completely automated production builds that release applications which are fully traceable, managed and ready to be provisioned with no fear!
This document discusses the principles of clean code based on Robert C. Martin's book "Clean Code". It covers topics like why clean code is important, guidelines for writing clean code like keeping methods small and using descriptive names, design principles like DRY and YAGNI, and code smells to avoid like long methods and duplicated code. The overall goal is to create code that is easy to read, understand and maintain over time.
Une usine logicielle est un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.
L’objectif est d’automatiser au maximum la production et la maintenance des applications afin d’améliorer leur qualité et le « time to market ».
This ppt is based on the book "Clean Code" written by Robert C Martin. It's a wonderful book and cover all the mistakes that we do while writing bad code. I am sharing few good practices shared in the book, hope you will like it
[Agile Tour Paris 2014] Comment rendre testable du code qui ne l'est pas ?Christophe HERAL
Les principes SOLID font partie des bases de la programmation orientée objet. Cependant, qui n'est jamais intervenu sur un projet avec l'ensemble du code fortement couplé ? Avec de ce fait de grandes difficultés à le tester unitairement ? L'objectif de cette présentation est de démontrer sur un cas d'usage comment l'utilisation d'interfaces et l'injection de dépendances va nous permettre d'améliorer ce code et de le rendre testable.
Chia sẻ về Clean Code tại XPDay Vietnam 2016.
Clean Code là gì?
Tại sao phải Clean Code?
Clean Code có khó không?
Một số ví dụ thực tế về áp dụng Clean Code.
Frequently deploying to production puts bigger pressure than before on DevOps to make sure the good, qualified application is provisioned with no mistakes. This session will explore some common pitfalls with traditional Continuous-Integration that increase risk, introduce manual input and human error, and generally make DevOps cringe before hitting the “deploy” button.
We will then demonstrate automation techniques that overcome these issues using popular tools, like Maven, Gradle, your CI server, custom scripts and a Binary Repository. Whether you are building software for the cloud or in-house, this presentation will show you how to have completely automated production builds that release applications which are fully traceable, managed and ready to be provisioned with no fear!
This document discusses the principles of clean code based on Robert C. Martin's book "Clean Code". It covers topics like why clean code is important, guidelines for writing clean code like keeping methods small and using descriptive names, design principles like DRY and YAGNI, and code smells to avoid like long methods and duplicated code. The overall goal is to create code that is easy to read, understand and maintain over time.
Une usine logicielle est un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.
L’objectif est d’automatiser au maximum la production et la maintenance des applications afin d’améliorer leur qualité et le « time to market ».
This ppt is based on the book "Clean Code" written by Robert C Martin. It's a wonderful book and cover all the mistakes that we do while writing bad code. I am sharing few good practices shared in the book, hope you will like it
O documento discute Domain-Driven Design (DDD), abordando conceitos como linguagem ubíqua, modelagem orientada a domínio, blocos de construção como entidades e objetos de valor. Exemplifica como esses conceitos podem ser aplicados na prática ao modelar uma camada de domínio com classes como Product, Currency e Money.
Présentation des différents designs applicatifs et de leur implémentation avec Symfony2.
Les exemples sont disponibles sur Github :
https://github.com/romainkuzniak
L5 SOLID - Five agile principles that should guide you every time you write code
Part:1. Laravel 5 NEW things - quick review
Part: 2. SOLID
- - -
S - Single Responsibility (SRP)
O - Open/Close
L - Liskov's Substitution
I - Interface Segregation
D - Dependency Inversion
Solution de collecte intelligente des déchets (Ecube Labs)Ecube Labs
Ecube Labs produit des solutions intelligentes de gestion des déchets qui aide les villes et l'industrie de la collecte des déchets à réduire les coûts d'exploitation pouvant atteindre jusqu'à 80 %. Notre gamme de produits intégrés comprend:
- Poubelle de compactage des déchets à alimentation solaire
- Capteur de niveau de remplissage ultrasonique sans fil
- Surveillance en temps réel et plate-forme d'analyse des données
http://ecubelabs.com/fr/
Models and Service Layers, Hemoglobin and HobgoblinsRoss Tuck
As presented at ZendCon 2014, AmsterdamPHP, PHPBenelux 2014, Sweetlake PHP and PHP Northwest 2013, an overview of some different patterns for integrating and managing logic throughout your application.
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
Presented at ACCU (24th April 2015)
It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation. Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay — the cause — than to simply focus on the code itself — the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity.
Nobody wants to work in a large ball of mud that becomes harder to manage as time goes on. Proven software architectures tells us to break the system into more manageable components that are isolated from each other.
Years back (before Composer) in symfony1 era we had a single SVN repository, that required a lot of discipline to keep our codebase decoupled and clean. After migrating to Symfony 2 we broke the project into more manageable components that were in separate Git repositories. Unfortunately it quickly became a huge overhead and nightmare to deal with.
We learned the hard why that all the benefits come from having isolated packages not breaking things into separate repositories.
Now we have a single Git repository, again. This isn't a bad idea; to my knowledge Facebook, Twitter, and Google all have a big monolithic source repos but we needed a solution that works for a lot smaller fish :)
With a little help, Composer made this possible for us - so you can have your cake and eat it too!
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
As presented at Dutch PHP Conference 2015, an introduction to command buses, how to implement your own in PHP and why they're both useful but unimportant.
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
The document discusses seven ineffective coding habits: noisy code with unnecessary comments, unsustainable spacing that reduces readability, underabstraction, lego naming conventions that are difficult to understand, unencapsulated state, getters and setters that expose implementation details, and uncohesive tests that do not clearly specify requirements. It provides examples of clearer, more effective alternatives for each habit.
Symfony: Your Next Microframework (SymfonyCon 2015)Ryan Weaver
Microservices are a huge trend, and microframeworks are perfect for them: put together just a few files, write some code, and your done!
But Symfony is a big framework, right? Wrong! Symfony can be as small as a single file!
In this talk, we'll learn how to use Symfony as a micro-framework for your next project. Your app will stay small and clear, but without needing to give up the features or third-party bundles that you love. And if the project grows, it can evolve naturally into a full Symfony project.
So yes, Symfony can also be a microframework. Tell the world!
The slides of my talk at PUGRoma.
Here, a complete sample code
https://github.com/leopro/trip-planner
Presentation is also here: http://t.co/5EK56yYBmQ
In building large scale web applications MVC seems like a good solution in the initial design phase. However after having built a few large apps that have multiple entry points (web, cli, api etc) you start to find that MVC breaks down. Start using Domain Driven Design.
Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.[1] The premise of domain-driven design is the following:
Placing the project's primary focus on the core domain and domain logic.
Basing complex designs on a model of the domain.
Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Have more questions?
Twitter: @wajrcs
Web: http://waqaralamgir.tk
Software Design Patterns in Laravel by Phill SparksPhill Sparks
Laravel makes use of quite a few well-established design patterns that promote reusable object-oriented code. Together, we will investigate the design patterns used in the core of Laravel 4 and discuss how they encourage reusable software.
Continuous Delivery with Jenkins Enterprise and IBM UrbanCode DeployIBM UrbanCode Products
Jenkins, the world’s leading open source continuous integration server, and IBM UrbanCode Deploy can be used together to automate the end-to-end continuous delivery process.
See how Jenkins passes builds to IBM UrbanCode Deploy to automate the deployment of applications, middleware configurations and database changes into development, test and production environments—delivering higher quality software in a repeatable fashion.
Presented by: Eric Minick, IBM DevOps Evangelist (and UrbanCode guy), and Kohsuke Kawaguchi, CTO of CloudBees.
Kanban pour maîtriser le développement incrémentalFabrice Aimetti
J'ai traduit cette présentation de Jeff Patton : Using Kanban Techniques to Control Incremental Development . J'ai ajouté le slide #5 après avoir trouvé et visionné les vidéos du jeu de construction d'avions en papier.
O documento discute Domain-Driven Design (DDD), abordando conceitos como linguagem ubíqua, modelagem orientada a domínio, blocos de construção como entidades e objetos de valor. Exemplifica como esses conceitos podem ser aplicados na prática ao modelar uma camada de domínio com classes como Product, Currency e Money.
Présentation des différents designs applicatifs et de leur implémentation avec Symfony2.
Les exemples sont disponibles sur Github :
https://github.com/romainkuzniak
L5 SOLID - Five agile principles that should guide you every time you write code
Part:1. Laravel 5 NEW things - quick review
Part: 2. SOLID
- - -
S - Single Responsibility (SRP)
O - Open/Close
L - Liskov's Substitution
I - Interface Segregation
D - Dependency Inversion
Solution de collecte intelligente des déchets (Ecube Labs)Ecube Labs
Ecube Labs produit des solutions intelligentes de gestion des déchets qui aide les villes et l'industrie de la collecte des déchets à réduire les coûts d'exploitation pouvant atteindre jusqu'à 80 %. Notre gamme de produits intégrés comprend:
- Poubelle de compactage des déchets à alimentation solaire
- Capteur de niveau de remplissage ultrasonique sans fil
- Surveillance en temps réel et plate-forme d'analyse des données
http://ecubelabs.com/fr/
Models and Service Layers, Hemoglobin and HobgoblinsRoss Tuck
As presented at ZendCon 2014, AmsterdamPHP, PHPBenelux 2014, Sweetlake PHP and PHP Northwest 2013, an overview of some different patterns for integrating and managing logic throughout your application.
Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...Kevlin Henney
Presented at ACCU (24th April 2015)
It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation. Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay — the cause — than to simply focus on the code itself — the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity.
Nobody wants to work in a large ball of mud that becomes harder to manage as time goes on. Proven software architectures tells us to break the system into more manageable components that are isolated from each other.
Years back (before Composer) in symfony1 era we had a single SVN repository, that required a lot of discipline to keep our codebase decoupled and clean. After migrating to Symfony 2 we broke the project into more manageable components that were in separate Git repositories. Unfortunately it quickly became a huge overhead and nightmare to deal with.
We learned the hard why that all the benefits come from having isolated packages not breaking things into separate repositories.
Now we have a single Git repository, again. This isn't a bad idea; to my knowledge Facebook, Twitter, and Google all have a big monolithic source repos but we needed a solution that works for a lot smaller fish :)
With a little help, Composer made this possible for us - so you can have your cake and eat it too!
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
As presented at Dutch PHP Conference 2015, an introduction to command buses, how to implement your own in PHP and why they're both useful but unimportant.
Seven Ineffective Coding Habits of Many ProgrammersKevlin Henney
The document discusses seven ineffective coding habits: noisy code with unnecessary comments, unsustainable spacing that reduces readability, underabstraction, lego naming conventions that are difficult to understand, unencapsulated state, getters and setters that expose implementation details, and uncohesive tests that do not clearly specify requirements. It provides examples of clearer, more effective alternatives for each habit.
Symfony: Your Next Microframework (SymfonyCon 2015)Ryan Weaver
Microservices are a huge trend, and microframeworks are perfect for them: put together just a few files, write some code, and your done!
But Symfony is a big framework, right? Wrong! Symfony can be as small as a single file!
In this talk, we'll learn how to use Symfony as a micro-framework for your next project. Your app will stay small and clear, but without needing to give up the features or third-party bundles that you love. And if the project grows, it can evolve naturally into a full Symfony project.
So yes, Symfony can also be a microframework. Tell the world!
The slides of my talk at PUGRoma.
Here, a complete sample code
https://github.com/leopro/trip-planner
Presentation is also here: http://t.co/5EK56yYBmQ
In building large scale web applications MVC seems like a good solution in the initial design phase. However after having built a few large apps that have multiple entry points (web, cli, api etc) you start to find that MVC breaks down. Start using Domain Driven Design.
Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.[1] The premise of domain-driven design is the following:
Placing the project's primary focus on the core domain and domain logic.
Basing complex designs on a model of the domain.
Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Have more questions?
Twitter: @wajrcs
Web: http://waqaralamgir.tk
Software Design Patterns in Laravel by Phill SparksPhill Sparks
Laravel makes use of quite a few well-established design patterns that promote reusable object-oriented code. Together, we will investigate the design patterns used in the core of Laravel 4 and discuss how they encourage reusable software.
Continuous Delivery with Jenkins Enterprise and IBM UrbanCode DeployIBM UrbanCode Products
Jenkins, the world’s leading open source continuous integration server, and IBM UrbanCode Deploy can be used together to automate the end-to-end continuous delivery process.
See how Jenkins passes builds to IBM UrbanCode Deploy to automate the deployment of applications, middleware configurations and database changes into development, test and production environments—delivering higher quality software in a repeatable fashion.
Presented by: Eric Minick, IBM DevOps Evangelist (and UrbanCode guy), and Kohsuke Kawaguchi, CTO of CloudBees.
Kanban pour maîtriser le développement incrémentalFabrice Aimetti
J'ai traduit cette présentation de Jeff Patton : Using Kanban Techniques to Control Incremental Development . J'ai ajouté le slide #5 après avoir trouvé et visionné les vidéos du jeu de construction d'avions en papier.
1. The document discusses the challenges of building software in a chaotic world, noting that building software is not a linear process and involves much uncertainty.
2. It emphasizes the importance of taking an iterative approach to reduce risks, having a strong user-centered vision rather than being user-led, and focusing on building the right product for the right customer.
3. The author advocates for viewing building software as a human activity involving technical and social complexity, and notes that processes, coordination across and within teams, and roles like product management are important for navigating this complex work.
The document discusses mutation testing and provides tips for implementing it. It explains different types of mutations like statement, value, and decision mutations. It also discusses how to calculate mutation score and challenges like cost. Examples are provided using tools like Pitest and Stryker. Advice is given around using mocks, refactoring complex code, and targeting tests to improve mutation testing.
This document discusses functional programming concepts. It explains that functional programming treats functions as first-class citizens and avoids side effects. Pure functions are easier to reason about because their outputs only depend on their inputs. The document also discusses avoiding null values and exceptions by using options and monads. Functional programming encourages immutability, referential transparency, and honesty in function signatures to make code more readable and easier to test.
This document provides an overview of domain-driven design (DDD) based on a feedback session in Amsterdam. It discusses:
1. What DDD is and is not - it is not a method, framework, or tool but has concepts like ubiquitous language, domain model, bounded contexts, and event sourcing.
2. Key DDD principles like having domain experts define the problem and solution, using a ubiquitous language, and designing bounded contexts to separate concerns while maintaining relationships.
3. Techniques for exploring a domain like event storming, user personas, acceptance tests, and distilling the core vs. support domains.
4. Architectural approaches like hexagonal/ports and adapters and
Que se passe t il avec l'Agilité en 2020. Crise de confiance? Manque d'évolutions? La crise du Covid19 a t elle permis de développer l'agilité dans les entreprises. Allons voir...
https://www.youtube.com/watch?v=URO7195UIdM&feature=youtu.be
Sous le feu des critiques: Trop moderne! Pas assez subversive aux yeux de certains! Pas créative! Un effet de mode passager pour les "djeunz"! Ou pire une musique de drogués!! Permettez moi au cours de cette session de vous éclairer sur cette culture et également sur les coulisses de la création des musiques assistées par ordinateur (MAO), et de voir ensemble les relations intéressantes que l'on peut tisser avec nos pratiques du développement logiciel (Software Craftsmanship).
On a pu lire quelques analogies entre pratique des musiques jazz, somme toute une musique très classique, et la pratique du développement logiciel tel que nous la concevons tous ici ("agile" diront certain). Pourtant il y a bien des façons de faire de la musique et en tant que spécialistes de la programmation j'ai été étonné de constater que peu d'entre nous s’intéressent à la musique dite "électronique". Pourtant, dans ces musiques aussi, nous nous servons d'outils logiciels au service de notre inspiration et notre créativité. On retrouve l'approche incrémentale, la technique imposée par les machines, des patterns évidemment, mais aussi de la pratique répétée, de l'amélioration continue et la coopération quand nous formons des groupes collaboratifs.
Au cours de cette session, après les généralités d'usage, je vous montrerai un DAW (digital audio workstation) logiciel, très couramment employé, et pas que pour la musique électronique, j'ai nommé "Live 9" d'Ableton avec sa surface de contrôle dédiée: Push (une sorte de clavier multi-fonctions pour la musique). Live est également extensible grâce à Max MSP, une API de programmation qui permet de scripter/patcher ce logiciel sous bien des formes.
J'espère vous montrer que création et programmation ne sont pas si éloignés que cela... et vous ferai partager mon expérience au sein de la Do It Yourself Music Academy
Collaboration avec le client plutôt que négociation de contrat » est certes l'un des 4 piliers du manifeste agile. Mais quel client, quel fournisseur seraient capables de démarrer un projet sans contrat? Cette présentation n'a pas pour objectif de vous donner la solution clés en main mais d'ouvrir le débat après avoir dépeint les solutions disponibles et donné des pistes de réflexion
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...Horgix
This is the slide deck of a talk by Alexis "Horgix" Chotard and Laurentiu Capatina presented at the MongoDB Paris User Group in June 2024 about the feedback on how PayFit move away from a monolithic hell of a self-hosted MongoDB cluster to managed alternatives. Pitch below.
March 15, 2023, 6:59 AM: a MongoDB cluster collapses. Tough luck, this cluster contains 95% of user data and is absolutely vital for even minimal operation of our application. To worsen matters, this cluster is 7 years behind on versions, is not scalable, and barely observable. Furthermore, even the data model would quickly raise eyebrows: applications communicating with each other by reading/writing in the same MongoDB documents, documents reaching the maximum limit of 16MiB with hundreds of levels of nesting, and so forth. The incident will last several days and result in the loss of many users. We've seen better scenarios.
Let's explore how PayFit found itself in this hellish situation and, more importantly, how we managed to overcome it!
On the agenda: technical stabilization, untangling data models, breaking apart a Single Point of Failure (SPOF) into several elements with a more restricted blast radius, transitioning to managed services, improving internal accesses, regaining control over risky operations, and ultimately, approaching a technical migration when it impacts all development teams.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
25. *
*Open Close Principle
*Ouvert aux extensions / Fermé aux modifications
*Interface Segregation Principle
*Un composant ne doit jamais être forcé de dépendre d’une interface (ou un
package) qu’il n’utilise pas
*Dependency Inversion Principle
*Les éléments de « haut » niveau ne doivent pas dépendre des
éléments de « bas » niveaux
*Les abstractions ne doivent pas dépendre des détails (implémentations)
29. *
*La granularité de la réutilisation est la
granularité de ce que est livré/livrable.
*Ne ré-utilisez rien qui ne soit livrable
indépendamment.
*Ré-utilisez si vous pouvez vous sentir comme
un simple consommateur d’un livrable.
31. *
*Si 2 classes changent ensemble alors elles
devraient se retrouver ensemble dans le même
package.
*Similaire à Open Close Principle
*Gain en maintenabilité.
33. *
*Stable Dependencies Principle (SDP)
*Moins un package est stable, moins il devrait y avoir de
dépendances vers lui (moins de couplage).
*Stable Abstractions Principle (SAP)
*Les packages ne contenant que des abstractions doivent être
les plus stables possibles.
*Forte Cohérence Interne / Faible Couplage Externe
34. Concepts
d'architecture
Concepts
d'implémentation
Détails
d'implémentation
Dépendances
Ne dépendent que
d'autres concepts
d'architecture
Peuvent dépendre
de concepts
d'architecture ou de
d'autres concepts
d'implémentation
Dépendent de
concepts
d'architecture et de
concepts
d'implémentation
Niveau
d'abstraction
Entièrement
abstraits
Mélange
d'abstraction et de
détails
Entièrement
composés de détails
Niveau de stabilité Stabilité maximale Partiellement stable
Change au moindre
changement dans le
logiciel
36. *
*A good architecture allows major decisions to be defered
*What and how to instanciate
*How display it
*How store it ….
*A good architecture maximes the number of decision not
made
37. *
*Independant of Frameworks
*Fully and Unit Testable… and very fast!
*Independant of UI
*Independant of Database
*Independant of any External Agency
38.
39. *
*A l’extérieur: l’infrastructure, les services externes
*la persistence, l’UI en font partie
*A l’intérieur: la description des comportements et
des entités
*Dépendances: de l’extérieur vers l’intérieur
seulement
40. *Les entités
*On en parle demain dans « TDD vs DBO »
*Uses cases
*Ce sont des « Application business rules »
*Jamais impacté par les changements externes (UI, DB, etc…)
*Interface Adapters
*Convertissent les entités vers des formats
adaptés aux infrastructures
*Frameworks & Drivers
*Fournissent des services (persistence,
présentation, quincaillerie en tous genre)