Uncle Bob discusses how an application should be structured in order ton convey information about its purpose
Keeping ifs at the boundary of your code, making it simpler. Why composition is way better than inheritance. NullPattern is the shit. This is in that conf.
CQRS and Event Sourcing - Greg Young - 1h04min
A cool introduction on CQRS pattern and Event Sourcing.
8 lines of Code - Greg Young - 45min
Greg Young discusses eight lines of very common code finding in them massive numbers of dependencies and difficulties, looking for ways to get rid of them.
How functional principles can help OO code be simpler, better, harder, faster, stronger.
Hot reloading with React and time travelling within application state.
Using a event log as a way to communicate between all your subsystems.
Bret Victor looks back at the history of software development in order to imagine what the futur will be
Making tools that enable people to learn, experiment and understand.
A tool for drawing dynamic visualizations of dataset in realtime, manipulating both the image and data.
Ross Tuck delights the audience with a fun and interesting talk about the HTTP protocol, strategies for versioning APIs, etags and much more
First part of Sandro's demonstration of outside-in TDD Part2 - 36min Part3 - 24min
After over ten years since the Agile summit, software projects are still failing and developers are still behaving and being treated as factory workers. The software development industry is still very amateur when compared to other professions. How can we change this? Why Agile was not sufficient? Why so many clients are unhappy with their software projects? Why is it so difficult to find good developers? Our industry needs more professionalism and that's what Software Craftsmanship brings to the table. In this talk Sandro will be explaining: what Software Craftsmanship really is, the value of technical practices, what it means to be a professional software developer and what to do to satisfy our customers.
Refactoring untested legacy code to a code following SOLID principles.
Refactoring legacy code - Sandro Mancuso - 1h17min
Sandro explains how to test untestable legacy code containing static calls, service locator and so on.
Introduction to ES in PHP. In french.
This talk is an effort to analyze the most common reasons that teams become disillusioned with their tests, and offer some targeted advice to help teams prevent these problems from ever materiaizing by tweaking their tools, workflow, and perspective.
Is it possible to make a REST API on top of an applying DDD technicals patterns ? Yup !
What is our responsability toward our users as people building software. Should we do everything we can do because it's fun, interesting, or should we say no sometimes when a feature can hurt someone ?
Declan Whelan covers DDD technical patterns, introduces bounded context and hexagonal architecture. This talk is not about microservices, whatever the title pretends.
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features?
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing.
By iteratively modifying the project structure to better model the product requirements, he has come up with a design style that helps developers create maintainable and domai n-oriented software.
Uncle Bob talks about the past, present and future of programming
How to write simple tests.
Writing good OOP, removing if conditionals.
On software cost
Getting out of the legacy system
Introduction to Event Storming
Introduction to the Cynefin framework
Introduction to DDD by Eric Evans
Greg Young looks back at the ten past years in the DDD community and try to foresee the futur years
Venkat Subramaniam on good design
Cost analysis, unecessary feature, happy path, accidental complexity...
Intro do domain modelling in PHP
The other part of DDD : understanding business needs with some tools
A talk about Buffer’s culture. Sunil talks about how the deal with being a distributed team, with their full internal and external transparency (salaries, dealing with crisis), how they deal with culture fit…
A good introduction to Prolog.
Aaratee Rao discusses some practical and real world examples of how some well-known hyper growth companies accumulated and managed technical debt. Rao covers tools on how to properly identify different forms of technical debt, track it and factors to consider when deciding to repay so that the entire team can reap its benefits.
Seb Rose discusses BDD, what it is good for and what tools can help, common BDD anti-patterns and myths, as well as advice for starting with it.
We love our silver bullets don’t we? Constantly chasing the dream that the next big thing will solve all our past problems. It doesn’t matter if it’s a language, framework, platform or library, we’re out there chasing it. Why? Well because it’s going to solve our needs, it’s going to solve the business needs. Well supposedly it will. And how much is it going to cost? Not that much, especially if we’re not the ones paying the bills.
It’s about time we look at the hard facts and ask those difficult questions. Are we really looking for a silver bullet? Why are we constantly riding the technology bandwagon? Where is the churn going to take us? And at what cost?
Camille Fournier talks about why rewriting a piece of software and what you should know before starting that journey.
##No Excuse, User Research - Lily Dart - 40min Three simples methodologies to gather data and to stop relying on subjective data to drive product design.
##Getting out of end-to-end testing jail - Konstantin Kudryashov Like specification by example but from the point of view of test perf
##Rock Stars, Builders, and Janitors: You're doing it wrong - Alice Goldfuss Building a team where people don't always deal with other peoples' shit
How Slack Works - Keith Adams - 50min
Learn how slack works: how they deal with lots of teams, realtime, double master mysql
Aral Balkan talks about privacy issues in a world runned by corporations.
About diversity and inclusion in tech companies.
What is a micro service, where do they come from, is it the only way to achieve isolation, which level of isolation by the way, should we use one database per micro service, ... ?
Danielle Leong talks about how to apply a "consent filter" to product decisions to make a safer user experience and to help protect GitHub’s most vulnerable users from harm.
Velocity gives us motion in one direction. We want to work faster -- and more, we want to do the most useful work. We need acceleration: deliberate changes in speed and direction.
How? The same way we accelerate our customers' work: automation!
We already automate our work: from CI to our favorite editors to command-line aliases, we smooth our workflow. We can take this farther -- but should we? Where is the balance between racing forward, and tweaking our racecar?
To achieve this, first look closely at our own work. A few observations give us data on what's really slowing us down. It may not be the technical debt you think it is: what hurts us is different from what we dislike.
Next consider automation: it changes more than our speed. Jessica suggests more powerful justifications, up to generating contributions larger than our own productivity.
Let's find the sticking points in our work, and then apply our superpowers of automation to change our own world, so that we can change our users' worlds, faster.
Les quelques 300 ingénieurs de GitHub déploient en production 80 fois par jour en moyenne. Je vous propose de découvrir notre organisation, nos méthodes de travail et les outils que nous utilisons. Vous découvrirez comment une ligne de code peut passer en prod moins de cinq minutes après avoir été écrite, même si elle induit un changement de structure de la base de données.