We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Topics covered are
The problem ,History ,Philosophy , Collaboration, Specification by example , Scenarios , Cucumber JVM ,Gherkins ,Testing strategy , Testing Iceberg, Feature injection ,When to embrace BDD?,BDD for maintenance projects , the “dEep” model , TDD vs BDD
Nessa apresentação, vamos falar sobre o uso de BDD, o que o criador do Cucumber recomenda, quando usar e quando não usar.
Canal QAOPS: https://videos.qa-ops.com/subscribe
This presentation demonstrates general guidelines how to create good test cases using Robot Framework. Both good practices and anti-patterns are presented.
The presentation is hosted on GitHub where you can find the original in ODP format: https://github.com/robotframework/DosDontsSlides
From the the teams struggling with DevOps to experienced professionals trying to make a shift to DevOps, this presentation helps in how understanding how DevOps makes Deliveries faster and accurate
The concept of “shifting testing left” in the software development lifecycle is not new. Shifting testing from manual to automated and then upstream into engineering is a driving factor in DevOps and agile software development. However, Michael Nauman wonders why test automation, DevOps, and agile software development still frequently fail to deliver on their promises? Aligning and hardening your DevOps and test automation—along with streamlining your agile processes—is critical to your project. Michael shares how AutoCAD’s shifting testing left enabled improvements within their engineering team. Learn how the team increased engineering reliability and velocity, and forced process changes upstream into design and research all the way through to product support. Leave knowing why the concept of separation of concerns with regards to quality is as fundamental as the separation of code quality from product quality. Learn how the AutoCAD web team used process dogma and ruthless prioritization to combat metric idolatry and the host of other evils that hold teams back from fully realizing their potential and going beyond agile.
“Quality at Speed” is Atlassian’s approach to QA, and we are constantly evolving what that means and how it translates to actual dev team processes. Our developers can confidently take on testing activities, while our QA Engineers tackle larger, harder, and bolder challenges. Teams can ship better features, faster, and reach ambitious quality improvement goals.
We'll talk about how our team has embraced this mindset, how this changes our role in dev teams, and the results we want to achieve. We'll cover the different ways that quality can be defined, the importance of fast deployments, and how we work with teams like DevOps, Growth and Customer Insights to help our dev teams and ultimately benefit our users.
Products covered:
JIRA Software, Bitbucket, Bamboo
Cloud adoption fails - 5 ways deployments go wrong and 5 solutionsYevgeniy Brikman
"All happy cloud deployments are alike; each unhappy cloud deployment is unhappy in its own way." — Leo Tolstoy, Site Reliability Engineer
At Gruntwork, I've had the chance to see the cloud adoption journeys of hundreds of companies, from tiny startups to Fortune 50 giants. I've seen those journeys go well. I've seen those journeys go poorly. In this talk, I discuss a few of the ways cloud adoption can go horribly wrong (massive cost overruns, endless death marches, security disasters), and more importantly, how you can get it right.
To help you get it right, we looked at the cloud journeys that were successful and extracted from them the patterns they had in common. We distilled all this experience down into something called the Gruntwork Production Framework, which defines five concrete steps you can follow to adopt the cloud at your own company—and hopefully, to end up with your very own happy cloud deployment.
Openshift has the mechanism for building and deploying applications and Jenkins is a tool use for continuous integration/delivery/deployment. If we combine these together we can create a CI/CD pipeline that will allow us to promote builds of applications and make them available in our OSE instance.
Video - https://youtu.be/IreIK-jICgY
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Learn how Acceptance Test Driven Development (ATDD) provides the process for capturing detailed requirements as acceptance criteria and turn them into as test cases before development begins using Behavior Driven Development (BDD). The BDD approach and Gherkin format is the language used to create easy to understand and actionable scenarios that map from the functional level to the components and units. We will discuss the different approaches to TDD including a realistic approach leveraging BDD to a purest standpoint where TDD use the tests to drive the design of the application. Finally understand how the tools in Visual Studio and Team foundation Server to support BDD such as SpecFlow (Cucumber in .NET), Refactoring tools, and Test Cases in MTM.
Shift left - find defects earlier through automated test and deploymentClaudia Ring
Do you know how much time it takes or how that translates into dollars lost every time you fix a defect in development, QA, or Production? The cost of application failures or errors increases exponentially the further into the delivery pipeline they are when found. If application defects are discovered by end users in Production, or errors cause a Production outage, the cost can be thousands per second, in addition to the intangible loss of reputation.
So how do you begin to identify defects earlier in software development and prevent them from becoming major, costly errors later on? Join Al Wagner, IBM Technical Evangelist, as he discusses how to "shift left" and;
Incorporate service virtualization and automated testing into development for a more thorough and accurate representation of application quality
Integrate deployment automation with continuous testing to remove wait times on application promotion
Adopt best practices that have proven successful for IBM customers who are currently shifting left
Topics covered are
The problem ,History ,Philosophy , Collaboration, Specification by example , Scenarios , Cucumber JVM ,Gherkins ,Testing strategy , Testing Iceberg, Feature injection ,When to embrace BDD?,BDD for maintenance projects , the “dEep” model , TDD vs BDD
Nessa apresentação, vamos falar sobre o uso de BDD, o que o criador do Cucumber recomenda, quando usar e quando não usar.
Canal QAOPS: https://videos.qa-ops.com/subscribe
This presentation demonstrates general guidelines how to create good test cases using Robot Framework. Both good practices and anti-patterns are presented.
The presentation is hosted on GitHub where you can find the original in ODP format: https://github.com/robotframework/DosDontsSlides
From the the teams struggling with DevOps to experienced professionals trying to make a shift to DevOps, this presentation helps in how understanding how DevOps makes Deliveries faster and accurate
The concept of “shifting testing left” in the software development lifecycle is not new. Shifting testing from manual to automated and then upstream into engineering is a driving factor in DevOps and agile software development. However, Michael Nauman wonders why test automation, DevOps, and agile software development still frequently fail to deliver on their promises? Aligning and hardening your DevOps and test automation—along with streamlining your agile processes—is critical to your project. Michael shares how AutoCAD’s shifting testing left enabled improvements within their engineering team. Learn how the team increased engineering reliability and velocity, and forced process changes upstream into design and research all the way through to product support. Leave knowing why the concept of separation of concerns with regards to quality is as fundamental as the separation of code quality from product quality. Learn how the AutoCAD web team used process dogma and ruthless prioritization to combat metric idolatry and the host of other evils that hold teams back from fully realizing their potential and going beyond agile.
“Quality at Speed” is Atlassian’s approach to QA, and we are constantly evolving what that means and how it translates to actual dev team processes. Our developers can confidently take on testing activities, while our QA Engineers tackle larger, harder, and bolder challenges. Teams can ship better features, faster, and reach ambitious quality improvement goals.
We'll talk about how our team has embraced this mindset, how this changes our role in dev teams, and the results we want to achieve. We'll cover the different ways that quality can be defined, the importance of fast deployments, and how we work with teams like DevOps, Growth and Customer Insights to help our dev teams and ultimately benefit our users.
Products covered:
JIRA Software, Bitbucket, Bamboo
Cloud adoption fails - 5 ways deployments go wrong and 5 solutionsYevgeniy Brikman
"All happy cloud deployments are alike; each unhappy cloud deployment is unhappy in its own way." — Leo Tolstoy, Site Reliability Engineer
At Gruntwork, I've had the chance to see the cloud adoption journeys of hundreds of companies, from tiny startups to Fortune 50 giants. I've seen those journeys go well. I've seen those journeys go poorly. In this talk, I discuss a few of the ways cloud adoption can go horribly wrong (massive cost overruns, endless death marches, security disasters), and more importantly, how you can get it right.
To help you get it right, we looked at the cloud journeys that were successful and extracted from them the patterns they had in common. We distilled all this experience down into something called the Gruntwork Production Framework, which defines five concrete steps you can follow to adopt the cloud at your own company—and hopefully, to end up with your very own happy cloud deployment.
Openshift has the mechanism for building and deploying applications and Jenkins is a tool use for continuous integration/delivery/deployment. If we combine these together we can create a CI/CD pipeline that will allow us to promote builds of applications and make them available in our OSE instance.
Video - https://youtu.be/IreIK-jICgY
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Learn how Acceptance Test Driven Development (ATDD) provides the process for capturing detailed requirements as acceptance criteria and turn them into as test cases before development begins using Behavior Driven Development (BDD). The BDD approach and Gherkin format is the language used to create easy to understand and actionable scenarios that map from the functional level to the components and units. We will discuss the different approaches to TDD including a realistic approach leveraging BDD to a purest standpoint where TDD use the tests to drive the design of the application. Finally understand how the tools in Visual Studio and Team foundation Server to support BDD such as SpecFlow (Cucumber in .NET), Refactoring tools, and Test Cases in MTM.
Shift left - find defects earlier through automated test and deploymentClaudia Ring
Do you know how much time it takes or how that translates into dollars lost every time you fix a defect in development, QA, or Production? The cost of application failures or errors increases exponentially the further into the delivery pipeline they are when found. If application defects are discovered by end users in Production, or errors cause a Production outage, the cost can be thousands per second, in addition to the intangible loss of reputation.
So how do you begin to identify defects earlier in software development and prevent them from becoming major, costly errors later on? Join Al Wagner, IBM Technical Evangelist, as he discusses how to "shift left" and;
Incorporate service virtualization and automated testing into development for a more thorough and accurate representation of application quality
Integrate deployment automation with continuous testing to remove wait times on application promotion
Adopt best practices that have proven successful for IBM customers who are currently shifting left
Institutional Repositories: What the Open Access agenda means for a modern in...Gaz Johnson
First and third parts of a lecture delivered to 2009/10 Library post graduates at Loughborough University (March 25th 2010). Covers general open access and the response from the University of Leicester.
Presentation delivered at the Winter 2010 UKCoRR meeting held at the University of Leicester, UK. Covers the activity and challenges faced by the local institutional repository.
This week our students have had the opportunity to be part of real-time current events. With the media circus buzzing around Kony2012, Invisible Children, and the LRA – I created a (fairly) student-friendly powerpoint that objectively explains the background of Kony and the LRA. I am not getting into the hype surrounding supporters and opponents of Invisible Children, but have included them as well as other organizations at the end of the presentation to give students options regarding how to get involved.
No matter what people feel about Invisible Children, it’s obvious that they have created a successful awareness raising campaign. My students have had a lot of questions about the whole situation, so I created this powerpoint that I am now sharing with you.
Leicester Research Archive (LRA): the work of a repository administratorGaz Johnson
Second part (of three) of a lecture delivered to post graduate library students at the University of Loughborough. Focusses on the role of the repository administrator, and the practical steps taken to populate the site. This section written and presented by Valérie Spezi.
Thank you for all video clips.
https://www.youtube.com/watch?v=HWZXinRwCaE (icbm)
https://www.youtube.com/watch?v=mE-q1IaPIUk (how missiles launch)
https://www.youtube.com/watch?v=SOXmVi3A_PI (satan R36)
https://www.youtube.com/watch?v=LvHlW1h_0XQ (LRASM)
Le Software Defined Storage, pour éliminer toutes les contraintes du stockageNoham MEDYOUNI
Un stockage qui s’adapte d’un clic aux contraintes des logiciels et des applications et qui n’est plus limité par des silos de baies de disques. Telle est la promesse du Software-Defined Storage SDS, ou stockage défini et contrôlé par logiciel.
In French: Talk given in French at the Loops network of scientific computing development and at the pyconfr conference.
Subject: rules of thumb for community-driven development
Vous ne manquez pas de tutoriels pour écrire un "Hello, world" avec n'importe quel framework. Mais que se passe-t-il quand, sur cette base, vous faites travailler une équipe de 4 développeurs pendant 6 mois ? Petit retour d'expérience sur l'architecture logicielle d'une application Symfony2 de taille moyenne, avec des visualisations inédites et des indices pour répondre à cette éternelle question : mais où je le mets ce code ?
Présentation effectuée au PHP Tour Lyon 2014
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 !
Slides de la présentation de Sonar 2.0 sur les 7 péchés capitaux au GenevaJUG le 23 février 2010.
La sortie de la version 2.0 de la plateforme Open Source Sonar est l'occasion de revenir et d'échanger sur l'un des plus jeunes métier du monde: Développeur logiciel. Après de nombreuses générations d'autodidactes, de passionnés, qu'est qu'être développeur professionnel aujourd'hui, quels sont nos responsabilités et nos défis ?
Le principal héritage légué par un développeur et plus globalement par une équipe de développement est son code source. La principale qualité attendue d'un code source est est sa capacité à permettre d'accueillir le changement à moindre coût. Quels sont donc les critères d'évaluation de cette qualité du code source ?
Présentation faite par Freddy Mallet
www.sonarsource.com
www.genevajug.ch
.Net pour le développeur Java - une source d'inspiration?Rui Carvalho
Pour se remettre dans le contexte, nous parlons ici de .Net présenté à une conférence Java.
Nous allons revoir un peu d'historique des débuts pré-.Net et des inspirations mutuelles des deux environnements. Puis nous parlerons fonctionnalités à travers un exemple illustrant notamment les points essentiels de C# aujourd'hui avec les lambdas qui arriveront avec Java 8.
Nous finirons enfin avec une partie communautaire.
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
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
Diaporama de ma présentation "Agilistes : n'oubliez pas la technique" le 25/04/2013 à Mix-IT 2013. N'hésitez pas à me faire des retours et me contacter !
Le Domain Driven Design (DDD) a la particularité d’être compliqué à expliquer. Ce sera donc exactement le but de cette conférence.
On a tendance à penser que le DDD est complexe, mais c’est au final beaucoup de bon sens. C’est la quantité de chose couverte par le DDD qui le rend difficile à appréhender au début.
Avec des retours d’expériences sur des pratiques concrètes du quotidien, que vous pourrez appliquer dès demain, nous verrons comment rendre votre projet plus centré sur le domaine. Nous verrons également quels principes sont respectés grâce à ces pratiques, et en quoi cela peut être bénéfique pour une équipe, donc pour une entreprise.
Présentation faite à LeanKanban France, dont le pitch était :
Quelque part au coeur du processus de création d'un projet, existe des gens qui lisent, écrivent et se bagarrent avec du code. Ces gens, appelés "programmeurs", ont une culture directement issue de cette bataille entre l'homme et la machine.
Qu'est-ce qui les frustre, les exalte, les freine ?
Quels sont les biais cognitifs avec lesquels ils travaillent ? Quel est l'environement et les processus qui permettent qu'ils donnent le meilleur d'eux même ?
Comprendre cette culture est un facteur clé de réussite d'un projet à court terme et d'une entreprise à moyen terme.
Comment j'ai remplacé 30% de mes développeurs en adoptant l'agilité... et aut...Jean-Laurent de Morlhon
Les approches agiles nous recommandent de mettre en place des équipes auto-organisées et pluridisciplinaires mais ne précisent pas grand chose sur
comment y parvenir à part d'inspecter et d'adapter. Hum...mais encore ? Autour d'un retour d'expérience dans la société Vidal, venez échanger sur des défis de la constitution d'équipe et les axes de réflexion que propose l'agilité, en discutant avec un utilisateur terrain et un coach agile.
20. En bref...
• Une définition commune
• Métaphores que l'on peut interpréter de
façon très différentes (art, guilde ...)
• Manifeste au points flous, lié au manifeste
agile
22. Scrum en 2011...
• Avec des post-its et des stand-
ups
• ... Sans itérations...
• ... Sans rétrospectives...
• ... Sans pratiques techniques...
• ... http://www.martinfowler.com/bliki/FlaccidScrum.html
30. Musique
Musicien Professeur de
Musiciens d’élite
professionnels musique
5 ans 2-3 h / Semaine 2-3 h / Semaine 2-3 h / Semaine
8 ans 6 h / Semaine 2-3 h / Semaine 2-3 h / Semaine
12 ans 8 h / Semaine 6 h / Semaine 4 h / Semaine
16 ans 22 h / Semaine 11 h / Semaine 7 h / Semaine
20 ans 30+ / Semaine 24 h / Semaine 12 h / Semaine
Nb heures
Accumulées : 10 000 heures 8 000 heures 4 000 heures
The Role of Deliberate Practice in the Acquisition of Expert Performance K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Romer; 1993
31.
32. En résumé
• Un mouvement.
• Agile *avec* les pratiques techniques
• Respect du rôle de l'ingénieur
• Apprentissage / Mentoring
45. Exercice
Q: Vous avez un jar exécutable qui démarre
du code que l'on veut lancer
régulièrement.
L'accès au logs passés est important.
Un novice doit pouvoir les visualiser.
1: Cron Job
2: Talend
3: Quartz Scheduler
4: Jenkins
5: Je code tout, Threads & Future FTW !