AT Marseille 2011 - Réduisons les gaspillagesJérôme Avoustin
Session donnée lors de l'Agile Tour Marseille, le 13 octobre 2011, sur la réduction des gaspillages
Pour lutter contre les facteurs de coûts, deux grandes tendances ont émergé du monde de l’industrie : le taylorisme et le lean. Dans le premier cas, on cherche à réduire le cout de main d’oeuvre de la tache, en s’intéressant au TJM le plus bas. Dans l’apporche Lean, on recherche d’abord à réduire les gaspillages tells que la surproduction, l'attente, les pertes de temps dans les tâches sans valeur ajoutée, les développements mal faits, les défauts, et le plus intéressant d'entre eux, les stocks.
Nous voyons donc lors de cette conference en quoi ces gaspillages se retrouvent dans le monde de l’informatique, et comment les démarches et pratiques agiles permettent de les réduire.
AT Marseille 2011 - Réduisons les gaspillagesJérôme Avoustin
Session donnée lors de l'Agile Tour Marseille, le 13 octobre 2011, sur la réduction des gaspillages
Pour lutter contre les facteurs de coûts, deux grandes tendances ont émergé du monde de l’industrie : le taylorisme et le lean. Dans le premier cas, on cherche à réduire le cout de main d’oeuvre de la tache, en s’intéressant au TJM le plus bas. Dans l’apporche Lean, on recherche d’abord à réduire les gaspillages tells que la surproduction, l'attente, les pertes de temps dans les tâches sans valeur ajoutée, les développements mal faits, les défauts, et le plus intéressant d'entre eux, les stocks.
Nous voyons donc lors de cette conference en quoi ces gaspillages se retrouvent dans le monde de l’informatique, et comment les démarches et pratiques agiles permettent de les réduire.
Formation Extreme Programming, Tests unitaires, travail collaboratifkemenaran
Cette formation développe les méthodes de l'Extreme Programming, introduit les tests unitaires et le Test Driven Developpement sous différents frameworks (dont CakePHP), et présente différents outils de travail collaboratif : SVN, Make, Trac, etc.
Présentation de Sonar 2.0 et plus généralement de l'évolution du métier de développeur au JUG Genève. Bonne ambiance, bonne participation, bon feedback !
Session donnée à Agile Tour Montréal, 29 Octobre 2011 et Confoo.ca, 1er Mars 2012.
S'adonner au développement itératif et incrémental sans automatiser les tests, c'est s'engager sur la voie du Scrum Flasque (Flaccid Scrum pour reprendre l'expression de Martin Fowler). C'est voir petit à petit la vélocité de l'équipe diminuer, la dette technique s'accumuler, la livraison de valeur d'affaires cesser. La base de code devient progressivement intravaillable. Bref, la qualité se détériore et les coûts de maintenance de l'application explosent. L'automatisation des tests à tous les niveaux est essentielle pour livrer itération après itération du logiciel de qualité qui enchantera vos clients. Plus facile à dire qu'à faire, à priori. Et quelle couverture de code devrait-on viser ? Seulement le chemin nominal ? 70% ? ... ou bien 100% ! Certains diront déjà, 100% c'est irréaliste ! Au contraire, cette session vous présentera comment viser ... et atteindre une couverture de test de 100% en tirant profit des différents types de tests et en construisant vos propres outils de tests.
Bien que l'AOP apporte plusieurs bénéfices architecturaux et techniques aux équipes qui en font usage, l'AOP vient également avec son lot de pièges. Pour ces raisons, plusieurs délaissent l'AOP à cause de la complexité indue qui pourrait toutefois être réduite en suivant de simples bonnes pratiques et en préparant adéquatement son intégration.
Cette présentation a pour but d'aider une équipe à embrasser l'AOP tout en évitant les pièges. On y traitera de diverses bonnes et mauvaises pratiques avec l'AOP (architecture, IDE, refactorisation, tests...). L'accent sera placé sur des conseils pratiques comme le choix de frameworks (ex.: AspectJ ou Spring-AOP), du mode de tissage approprié à votre contexte, des conflits avec d'autres technologies Java, etc.
Présentation donnée en septembre 2009 à un acteur informatique à Bordeaux. J'explique ma vision de l'agilité, des tests et de l'industrialisation au travers de l'exemple PHP.
Un banc de test est un système physique permettant de mettre un produit en conditions d'utilisation paramétrables et contrôlées afin d'observer et mesurer son comportement. Le banc de test est largement utilisé dans l'industrie, au point de représenter une part importante du budget de développement d'un produit.
Le test, qu'il soit unitaire ou fonctionnel, est à la mode dans le monde du développement logiciel, suite entre autre à la mise en œuvre croissante des méthodes agiles et notamment de l'intégration continue ou des méthodes de développement telles que le TDD, le BDD ou la programmation par contrat. Récemment, ce phénomène a encore été amplifié au sein de la communauté PHP par l'apparition aux côtés de l'incontournable PHPUnit d'outils plus originaux tels que Behat, Praspel ou atoum qui permettent au développeur de rédiger des tests plus simplement. Pourtant, nous constatons tous les jours que le test conserve une grande part de mystère pour la plupart des développeurs, Bien souvent, ces derniers ne savent pas quoi tester, et encore moins comment écrire un test efficace ou mettre en place une politique de test pertinente. Certains s'interrogent par exemple sur la pertinence de leurs tests, se demandent s'il faut absolument tout tester, d'autres s'il est possible de tester la création d'un fichier, voir même s'il est intéressant de le faire, tandis que d'autres se demandent où se situe la frontière entre le test unitaire et le test fonctionnel ou s'il est nécessaire de tester toutes les méthodes d'une classe, alors que d'autres encore ne savent tout simplement pas par où commencer. Durant cette conférence, nous allons tenter, à l'aide de nos expériences respectives de créateur de framework de tests et de doctorat en informatique spécialisé dans le test, de répondre aux questions récurrentes que se pose une personne confrontée à la mise en place d'une politique de qualité logicielle en général et à l'écriture d'un test logiciel en particulier. À l'issue de cette foire aux questions didactique et interactive, vous devriez être capable d'aborder le test, indépendamment de sa nature, de manière plus sereine et efficace et produire ainsi un logiciel de la qualité que vous désirez.
El documento describe las diferentes fuentes de energía y minerales. Se divide las fuentes de energía en renovables y no renovables, mencionando ejemplos de cada categoría como la energía solar, eólica, hidráulica frente a los combustibles fósiles y la energía nuclear. También habla sobre los recursos minerales, las menas y los impactos de la explotación minera en la cantera, gravera y mina a cielo abierto y subterránea. Finalmente, presenta algunas medidas preventivas y correctoras para mitigar los efectos de la
Formation Extreme Programming, Tests unitaires, travail collaboratifkemenaran
Cette formation développe les méthodes de l'Extreme Programming, introduit les tests unitaires et le Test Driven Developpement sous différents frameworks (dont CakePHP), et présente différents outils de travail collaboratif : SVN, Make, Trac, etc.
Présentation de Sonar 2.0 et plus généralement de l'évolution du métier de développeur au JUG Genève. Bonne ambiance, bonne participation, bon feedback !
Session donnée à Agile Tour Montréal, 29 Octobre 2011 et Confoo.ca, 1er Mars 2012.
S'adonner au développement itératif et incrémental sans automatiser les tests, c'est s'engager sur la voie du Scrum Flasque (Flaccid Scrum pour reprendre l'expression de Martin Fowler). C'est voir petit à petit la vélocité de l'équipe diminuer, la dette technique s'accumuler, la livraison de valeur d'affaires cesser. La base de code devient progressivement intravaillable. Bref, la qualité se détériore et les coûts de maintenance de l'application explosent. L'automatisation des tests à tous les niveaux est essentielle pour livrer itération après itération du logiciel de qualité qui enchantera vos clients. Plus facile à dire qu'à faire, à priori. Et quelle couverture de code devrait-on viser ? Seulement le chemin nominal ? 70% ? ... ou bien 100% ! Certains diront déjà, 100% c'est irréaliste ! Au contraire, cette session vous présentera comment viser ... et atteindre une couverture de test de 100% en tirant profit des différents types de tests et en construisant vos propres outils de tests.
Bien que l'AOP apporte plusieurs bénéfices architecturaux et techniques aux équipes qui en font usage, l'AOP vient également avec son lot de pièges. Pour ces raisons, plusieurs délaissent l'AOP à cause de la complexité indue qui pourrait toutefois être réduite en suivant de simples bonnes pratiques et en préparant adéquatement son intégration.
Cette présentation a pour but d'aider une équipe à embrasser l'AOP tout en évitant les pièges. On y traitera de diverses bonnes et mauvaises pratiques avec l'AOP (architecture, IDE, refactorisation, tests...). L'accent sera placé sur des conseils pratiques comme le choix de frameworks (ex.: AspectJ ou Spring-AOP), du mode de tissage approprié à votre contexte, des conflits avec d'autres technologies Java, etc.
Présentation donnée en septembre 2009 à un acteur informatique à Bordeaux. J'explique ma vision de l'agilité, des tests et de l'industrialisation au travers de l'exemple PHP.
Un banc de test est un système physique permettant de mettre un produit en conditions d'utilisation paramétrables et contrôlées afin d'observer et mesurer son comportement. Le banc de test est largement utilisé dans l'industrie, au point de représenter une part importante du budget de développement d'un produit.
Le test, qu'il soit unitaire ou fonctionnel, est à la mode dans le monde du développement logiciel, suite entre autre à la mise en œuvre croissante des méthodes agiles et notamment de l'intégration continue ou des méthodes de développement telles que le TDD, le BDD ou la programmation par contrat. Récemment, ce phénomène a encore été amplifié au sein de la communauté PHP par l'apparition aux côtés de l'incontournable PHPUnit d'outils plus originaux tels que Behat, Praspel ou atoum qui permettent au développeur de rédiger des tests plus simplement. Pourtant, nous constatons tous les jours que le test conserve une grande part de mystère pour la plupart des développeurs, Bien souvent, ces derniers ne savent pas quoi tester, et encore moins comment écrire un test efficace ou mettre en place une politique de test pertinente. Certains s'interrogent par exemple sur la pertinence de leurs tests, se demandent s'il faut absolument tout tester, d'autres s'il est possible de tester la création d'un fichier, voir même s'il est intéressant de le faire, tandis que d'autres se demandent où se situe la frontière entre le test unitaire et le test fonctionnel ou s'il est nécessaire de tester toutes les méthodes d'une classe, alors que d'autres encore ne savent tout simplement pas par où commencer. Durant cette conférence, nous allons tenter, à l'aide de nos expériences respectives de créateur de framework de tests et de doctorat en informatique spécialisé dans le test, de répondre aux questions récurrentes que se pose une personne confrontée à la mise en place d'une politique de qualité logicielle en général et à l'écriture d'un test logiciel en particulier. À l'issue de cette foire aux questions didactique et interactive, vous devriez être capable d'aborder le test, indépendamment de sa nature, de manière plus sereine et efficace et produire ainsi un logiciel de la qualité que vous désirez.
El documento describe las diferentes fuentes de energía y minerales. Se divide las fuentes de energía en renovables y no renovables, mencionando ejemplos de cada categoría como la energía solar, eólica, hidráulica frente a los combustibles fósiles y la energía nuclear. También habla sobre los recursos minerales, las menas y los impactos de la explotación minera en la cantera, gravera y mina a cielo abierto y subterránea. Finalmente, presenta algunas medidas preventivas y correctoras para mitigar los efectos de la
Este documento presenta un proyecto textual sobre la demolición realizado por un grupo de estudiantes. El proyecto busca dar a conocer más sobre la demolición, mostrar sus consecuencias, y aprender sobre el primer edificio demolido. El grupo investigó sobre la demolición y sus efectos para profundizar en el tema.
El documento define el deporte como una actividad que requiere esfuerzo físico, está institucionalizada con reglas y competición, y cuyo resultado depende de la capacidad física o habilidades del competidor. Menciona que los deportes existían ya en la antigua China, Egipto y Persia e incluían gimnasia, natación, lanzamiento de jabalina y lucha. También señala que el deporte actual se ha profesionalizado y comercializado, priorizando en ocasiones el dinero y la fama sobre los valores
éL Le Ha Escondido Con Un PropóSito—Usted EsIRMA CHAVEZ
El documento es un poema que describe la experiencia de sentirse olvidado por Dios y estar esperando un cambio prometido por Dios. El poema compara esta experiencia con ser una oruga en un capullo, escondida y sin saber quién es realmente. Aunque es incómodo esperar el cambio, la persona sabe que Dios terminará su obra y que algún día "volará" como una mariposa. Al final, el documento explica que así como Dios convierte las feas orugas en hermosas mariposas, Él puede convertir las cosas feas del pasado en
Este documento presenta un método de estudio llamado ECADE (Examinar, Cuestionar, Aplicar, Desarrollar, Evaluar) creado por Diego Alexander Alvarado Alvarado. El método consiste en examinar rápidamente el tema, cuestionarse a sí mismo para encontrar soluciones, aplicar las herramientas encontradas para desarrollar el problema, y evaluar los errores cometidos. El objetivo es proveer una forma rápida y eficaz de estudiar problemas de cualquier ciencia.
El documento presenta a Concept Marketing, una agencia de marketing que ofrece servicios de asesoramiento estratégico, desarrollo de planes de marketing, diseño de imagen corporativa, comunicaciones integradas, marketing de experiencia y capacitación. La agencia se enfoca en crear soluciones personalizadas para aumentar el valor de las marcas de sus clientes en diferentes industrias.
El documento describe la 7a Misa, Romería y Procesión de la Virgen del Rocío que se llevará a cabo en Santos Lugares, Buenos Aires el 31 de mayo. Incluirá una misa en el Santuario de Nuestra Señora de Lourdes, luego una procesión por las calles hasta la sede social del Centro Cultural Andalucía, donde habrá bailes y comidas típicas.
Este documento describe el impacto de la informática y las nuevas tecnologías en la educación. Explica cómo estas tecnologías han permitido acceder a más personas y acortar distancias geográficas a través de modalidades como la educación a distancia. También analiza conceptos como informática educativa y nuevas tecnologías de la información, y cómo están transformando los procesos de enseñanza y aprendizaje.
Tommy era un estudiante ateo en la clase de Teología de la Fe del profesor. Años más tarde, Tommy fue diagnosticado con cáncer terminal y buscó al profesor para contarle que finalmente había encontrado a Dios antes de morir. Tommy compartió que dejó de buscar a Dios activamente y en su lugar se enfocó en expresar su amor a sus seres queridos. Fue entonces cuando sintió la presencia de Dios. El profesor quedó conmovido por la historia de Tommy y cómo este había encontrado a Dios a través
El documento resume la estructura y temas centrales de la novela "El Pianista" de Manuel Vázquez Montalbán. La obra se estructura en tres partes que tienen lugar en 1983, 1946 y 1936 respectivamente. Los temas principales son la recuperación de la memoria histórica española y el compromiso ético del artista. Cada parte describe la época, los personajes y la trama central relacionada con la búsqueda de un piano.
D1 - Un développeur est-il un numéro, un coût journalier ou un artiste ?XP Day CH
Le métier et le rôle du développeur ont fortement évolués au cours des 10 dernières années du fait notamment de l'adoption massive des méthodologies agiles. De manière ludique, cette session mettra en lumière cette évolution et ces enjeux.
Freddy Mallet
Votre boss doute de la pertinence des revues de code ? Vous avez essayé mais ça n'a pas marché ?
Joffrey et Nicolas vous donneront les clés pour comprendre comment conduire des revues de codes efficaces et pertinentes.
Ils parleront de leurs expériences au sein de leurs équipes ainsi que des pièges à éviter.
Si les revues de code attisent votre curiosité, cette conférence est faite pour vous !
Pourquoi vous ne pouvez pas tester votre codeRémi Lesieur
"Non mais nous, on ne peut pas tester"
Vous avez déjà entendu cette phrase ? Parce que moi, oui, très souvent.
Il y a toujours au moins une bonne raison évoquée. Et si on en parlait ?
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
Valtech - Quel ROI pour ma transformation Agile ?Valtech
Quel ROI pour ma transformation Agile ?
PARTIE 1 : Un retour aux principes fondamentaux
Valérie Wagoner, Agile Coach, Valtech France
valerie.wagoner@valtech.fr
Agile Day 2012
Valtech
Une conférence de 2h30 (aka université) faites à Devoxx France en 2021 avec Maxime Gellé. On y fait un tour d'horizon des tests logiciels: TDD, Test unitaire vs Test d'integration, l'apport de l'archi hexagonale, Contract testing, property based testing, UI testing ... mais aussi comment "tester en production" !
Chaque industrie possède un élément clé dans son modèle économique. Dans l'industrie du développement, le facteur de succès est sans conteste le capital humain. Savoir recruter les meilleurs développeurs est une chose difficile mais les amener à réaliser leur plein potentiel l'est tout autant. En ouvrant le code à d'autres développeurs, les revues de code permettent de rompre l'isolement et de partager les connaissances afin de créer des émulations positives au sein des équipes. Nous verrons les gains qu'on peut attendre de cette pratique, les différentes formes (formelles, itératives, pair programming, etc.) qu'elle peut prendre ainsi que les écueils à éviter pour en tirer pleinement parti.
[Agile Testing Day] Techniques avancées de testsCellenza
Soyons honnête : nous aimerions tous tester nos plateformes, nos codes, mais personne ne le fait vraiment bien. Heureusement, ce n’est pas une fatalité, et il n’est jamais trop tard pour tester ! La vraie question est : comment tester ? Derrière toute stratégie de tests efficace, il y a une connaissance de tous les types de tests disponibles, de leurs coûts et de leurs utilités. Tout au long de cette journée, nous allons vous détailler les différents types de tests, du test unitaire au test de charge, afin que vous puissiez évaluer la pertinence de chacun dans votre propre contexte.
Pourquoi et comment nous relisons ensemble tout le code que nous produisons - retour d'expérience du WebCenter AXA sur la revue de code, accompagnés par Octo.
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ? Christophe HERAL
Microsoft nous propose une nouvelle version de son outil d'ALM en cette fin 2012.
Nombre de fonctionnalités ont été rajoutées ou améliorées dans cette mouture, notamment pour mieux prendre en compte les besoins des agilistes.
Mais cette version va-t-elle satisfaire les plus réticents à l'utilisation d'un outil ou a-t-on affaire à une arnaque agile ?
DIY: Analyse statique en Java par Nicolas Peru et Michael Gumowski
Trouver des bugs dans votre code java sans avoir à l’exécuter ? C'est possible. Découvrez de quelle manière l'analyse statique est un moyen de trouver des bugs en comprenant le fonctionnement de l'analyseur Java de SonarQube. Quelles sont les difficultés pour comprendre le langage Java ? Qu'est-ce que l'analyse syntaxique, l'analyse sémantique et l’exécution symbolique ? Et comment, en se basant sur le code source, il est possible de trouver des problèmes dans votre code sans avoir à l’exécuter ? Répondre à toutes ces questions vous permettra d'écrire vos propres règles d'analyse statique !
Slides d'introduction à la session de décembre 2015 du LyonJUG. Sujet principal : Jenkins Workflow par Jean Detoeuf. Lightning talk : CDI par Thomas Jouannot.
This document provides an overview of integration testing. It discusses the differences between unit and integration testing, challenges of integration testing like brittle tests and external dependencies, and techniques for integration testing like using fakes for resources and testing code within its container. It also provides examples of integration testing Spring applications, web services, and Java EE applications.
1) Java middleware offerings like Java EE 6 are well-suited for mobile and cloud applications today due to advances that provide enterprise capabilities needed for all but trivial apps.
2) While new mobile and cloud frameworks may be developed, it is inefficient and time-consuming to rebuild middleware capabilities from scratch in each new environment rather than leveraging existing open standards like Java EE 6.
3) For Java and other JVM languages to be successfully adopted on mobile and cloud, they need access to proven enterprise middleware capabilities like those in Java EE 6 in a lightweight manner suited for various environments.
This document provides an overview of NoSQL databases. It begins with an assessment of relational databases, noting their advantages like normalization but also limitations like handling data changes. It then discusses the rise of NoSQL databases, noting some points of convergence but also significant disparities between products. It focuses on Redis, Cassandra, MongoDB, and Neo4j, describing their data models, querying capabilities, and additional features like replication. The conclusion is that not all problems require a relational solution.
The document discusses using Lombok and Guava annotations and utilities to simplify Java code by automatically generating boilerplate code like getters, setters, toString methods. It provides an example of how Lombok reduces a Dog class from 210 lines to just 12 lines by adding annotations, and shows how Guava provides cleaner implementations of common methods like toString and equals.
Arnaud vous propose de découvrir le framework Spring Batch: du Hello World! jusqu'à l'exécution multi-threadée de batch, en passant par la lecture de fichiers CSV et la reprise sur erreur. Les techniques qu'utilise le framework pour lire et écrire efficacement de grands volumes de données e vous seront pas non plus épargnées ! La présentation se base sur une approche problème/solution, avec de nombreux exemples de code et des démos. A la suite de cette présentation, vous saurez si Spring Batch convient à vos problématiques et aurez toutes les cartes en mains pour l'intégrer à vos applications batch.
Arnaud vous propose de découvrir le framework Spring Batch: du Hello World! jusqu'à l'exécution multi-threadée de batch, en passant par la lecture de fichiers CSV et la reprise sur erreur. Les techniques qu'utilise le framework pour lire et écrire efficacement de grands volumes de données e vous seront pas non plus épargnées ! La présentation se base sur une approche problème/solution, avec de nombreux exemples de code et des démos. A la suite de cette présentation, vous saurez si Spring Batch convient à vos problématiques et aurez toutes les cartes en mains pour l'intégrer à vos applications batch.
Engagement des sociétés d'Ingénierie dans la contribution open source : un ce...lyonjug
LyonJUG du mardi 21 février 2012 (1° partie - présentée par Jérôme Petit)
http://www.lyonjug.org/evenements/ssii--open-source
Lors de cette présentation, Jérôme explique comment l'investissement dans la contribution à des projets Open Source crée un cercle vertueux pour l'entreprise.
Il donne un retour d'expérience sur les différents modèles de contribution en place à Serli, l'impact sur l'organisation, les affaires et les aspects humains.
GlassFish, Application versioning et rolling upgrade en haute disponibilitélyonjug
LyonJUG du mardi 21 février 2012 (2° partie)
http://www.lyonjug.org/evenements/ssii--open-source
Une fois qu'une application est en production, réaliser une montée de version sans perte de service est délicat et peut rapidement vous donner la migraine. Il faut en général le faire manuellement en montant un cluster, en répliquant l'application et ses sessions, et en jonglant avec le répartiteur de charge et les instances de serveur à chaque montée en version.
La fonctionnalité de versioning présente dans GlassFish, combinée avec le rolling upgrade (en early preview) permet de réaliser cette montée en version sans perte de service sur une instance stand-alone de GlassFish.
Dans cette session, Marian présente ces fonctionnalités et comment les utiliser pour réaliser une montée en version d'application en production sans perte de service, en utilisant exclusivement les services offerts par GlassFish.
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.
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO Technology
En cette année 2024 qui s’annonce sous le signe de la complexité, avec :
- L’explosion de la Gen AI
-Un contexte socio-économique sous tensions
- De forts enjeux sur le Sustainable et la régulation IT
- Une archipélisation des lieux de travail post-Covid
Découvrez les Tech trends incontournables pour délivrer vos produits stratégiques.
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 :
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...OCTO Technology
par Claude Camus (Coach agile d'organisation @OCTO Technology) et Gilles Masy (Organizational Coach @OCTO Technology)
Les équipes infrastructure, sécurité, production, ou cloud, doivent consacrer du temps à la modernisation de leurs outils (automatisation, cloud, etc) et de leurs pratiques (DevOps, SRE, etc). Dans le même temps, elles doivent répondre à une avalanche croissante de demandes, tout en maintenant un niveau de qualité de service optimal.
Habitué des environnements développeurs, les transformations agiles négligent les particularités des équipes OPS. Lors de ce comptoir, nous vous partagerons notre proposition de valeur de l'agilité@OPS, qui embarquera vos équipes OPS en Classe Business (Agility), et leur fera dire : "nous ne reviendrons pas en arrière".
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!
3. LE CYCLE EN V…
Exigences Tests fonctionnels
Analyse Tests d’intégration
Conception Tests unitaires
Implémentation
mar avr mai jui juil aou sep oct nov dec jan
3
4. ET CA FONCTIONNE ?
Bien sûr, si on a des spécifications
impeccables, limpides et lisibles…
4
6. ET CA FONCTIONNE ?
Et une équipe de développeurs en béton
qui respectent les délais
6
7. ET DANS LA VRAIE VIE ?
Les spécifications arrivent en retard…
Sont retouchées…
Le développement a été refait 18 fois !
Pour tenir à peu près les délais, on rogne
un peu sur les tests…
Puis beaucoup…
On recette sur une version bêta
Puis on croise les doigts à chaque livraison
7
8. DEVELOPMENT HELL
Augmentation
de la pression
Baisse de la Moins de temps pour
productivité écrire les tests
Code moins
stable
8
9. EN PLUS…
Ce n’est la faute de personne
Expression des besoins
Spécifications
Codage
Cahier de tests
BUG !
Tests
9
10. EN PLUS…
Ce n’est la faute de personne
Expression des besoins
Spécifications
C’est leur faute !
Codage
Cahier de tests
Tests
10
11. EN PLUS…
Ce n’est la faute de personne
Expression des besoins
C’est mal spécifié !
Spécifications
Codage
Cahier de tests
Tests
11
12. EN PLUS…
Si, c’est celle du client !
Expression des besoins
C’est mal exprimé !
Spécifications
Codage
Cahier de tests
Voici le règne des avenants !
Tests
12
15. LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS
On écrit les tests AVANT le code
Déroulement :
Ecriture du test
Vérification de l'échec du test (puisque le code
n'existe pas encore)
Ecriture du code
Vérification du test
Refactoring (amélioration en gardant les
mêmes fonctionnalités) : javadoc,
commentaires…
15
16. LE DÉVELOPPEMENT PILOTÉ PAR LES TESTS
Codage du test
Refactor Compilation
Lancement du test Correction des
Jusqu’à ce qu’il passe erreurs de compilation
Lancement du test
Ecriture du code
échec
16
17. INTÉRÊT
Précisent les spécifications
Force à réfléchir très tôt aux jeux de test
Permet d'arrêter le travail au bon moment
(quand les tests passent)
Par conséquent, la conception est
meilleure
17
18. INTÉRÊT
Le code produit est testable
Test de composants en couche sans avoir besoin des
couches de présentation
Automatisation et non-régression
Refactoring aisé
Confiance dans le code
18
20. DANS LES PROJETS INFORMATIQUES…
On rencontre principalement 3 types
d'intervenants
Ceux qui « spécifient »
Ceux qui « codent »
Ceux qui « testent »
Mais, la plupart du temps…
Ils ne parlent pas le même langage
Ils ne travaillent pas ensemble
Ils ne se connaissent parfois même pas
20
21. QUE FAIRE ?
Il faut les aider…
à travailler ensemble
à rendre le travail de chacun utile
à se sentir ensemble dans cette aventure
21
22. QUE FAIRE ?
Spécifier les comportements avec des
exemples
Lier les spécifications au code de
production
Ecrire des tests avant le code
Echanger des idées en écrivant des tests
Partager un résultat attendu avant de
coder
22
23. QUE FAIRE ?
Faire des tests les vedettes de votre projet
Se mettre d'accord sur ce que l'on veut puis
coder
Capitaliser les conversations dans des tests
Documenter l'utilisation d'un code dans
des tests
23
24. BONNES PRATIQUES
Tests Petits
Tests Isolés
Fonctionnant sous n'importe quel environnement
Tests Complets
Tests Répétables
Tests Automatiques
Tests Clairs pour tout le monde
Concevoir les tests comme des spécifications, pas
comme des vérifications
24
26. LE CODE EXISTANT…
Il n’y a pas de test
Ce code n’a pas été conçu pour qu’on puisse
écrire simplement des tests
Par où je commence ?
26
27. ON ÉCRIT LE TEST POUR TOUT LE CODE ?
Le projet est gros, il faut donc passer les 6
prochains mois à écrire des tests
Evidemment, ce n’est pas réaliste !
Commençons petit !
27
28. ON COMMENCE PAR 1 TEST !
Cherchez une portion de code testable (classe,
méthode, fonction…)
Ecrivez un test qui porte sur cette portion
Lancez-le : il doit réussir
(enfin, normalement ☺)
Ecrivez un test par jour…
28
29. TESTEZ À CHAQUE MODIFICATION DU CODE
La prochaine fois que vous devez corriger
un bug, écrivez un test qui permet de
reproduire ce problème…
Et qui échoue !
Si la portion de code n’est pas testable,
modifier le code pour l’isoler et la tester !
29
30. LANCEZ VOS TESTS !
Quand vous avez écrit vos tests, vous devez
les lancer !
Si vous ne le faites pas, ils sont inutiles…
Et c’est mieux si vous les faites exécuter
automatiquement…
30
31. LES DÉFAUTS DE L’APPROCHE TDD
Coûteux en temps
Parfois complexe à
concevoir
Peut sembler peu utile
car le développeur doit
envisager tous les cas de
figure, même ceux a
priori inutiles
31