Impressions about attending the CRAFT conference in Budapest (April 23-25) and video presentations
Just a month ago (April 23-25), a conference for CRAFT developers was held in the glorious city of Budapest. I was lucky to get on it and now I’ve got a hand to write a review about what I saw and heard.
The conference was lured to her not by the fact that it was possible to get to Europe at a corporate expense, but by a selection of invited authors, including Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. It is strange that there was no mention of it in Habré. Despite the fact that the conference was announced as a conference for developers, it was not about technology at all. There were several reports about the use of specific technologies, but most of the reports were about development in general.
The motto of the conference can be called the call "Adapt!". This thought sounded in very many reports. Maybe the organizers therefore did not give out notebooks in the package of participants - they wanted us to adapt? =) At the same time, they gave out pens and had to look for a notebook in the nearby stores.
')
Under the cut description and video reports that seemed to me the most interesting.
Paste the video directly into the article did not work, so the video is represented by links. If anyone helps with the insertion of the videos themselves, I will be grateful.
For myself, I singled out a few of the most useful and interesting reports, and arranged the rest in chronological order.
Video report
A very informative first report that set the tone for the entire conference. The basic idea: flexible approaches are applicable only where there is a changeable external world. If the outside world is static in relation to the system, then the scrum degenerates into waterSrumfall , which entails overhead without additional profit. If the outside world is not well known or is changing rapidly, then you need to be able to adapt. As an example, the author cites the experience of the Ducati team during their debut on the track of the superbike. In a critical situation, everything is flexible, because you need to adapt quickly, otherwise you will not survive.
As a way to adapt to the situation, the author offers user stories (User Stories).
The main idea: from user stories you need to compile and use a roadmap for its intended purpose: as a " road map ". The author says that most of the roadmap he saw were actually a tunnel , not a road map . The tunnel assumes movement in one direction only, and not a multitude of paths. As an example, the author gives a car navigator. It is ideal for planning and orientation on the ground, because it shows two main information blocks describing the current situation:
Then the author turned to the principles of Palchinsky from the book by Tim Harford Adapt: Why Success Always Starts with Failure : a link to a quote about the principles.
The author shows that user stories should be used to analyze what the customer actually wants, and then to adapt to the current situation of the project. Do not try to implement all the stories, because it can either be unnecessary or very expensive. Instead, user stories should be viewed as a set of alternatives (road maps) that can be selected when the situation around the project changes.
He said that he was preparing the book "50 quick ideas to improve your user stories".
Video report
Report from the category of "how is it that smart people do stupid things." It is worth looking to try to compare your behavior with examples. Examples are all vital with real projects. In the end, the author was even asked the question “have you ever worked on successful projects”. The report looks very easy because of the abundance of examples and interesting points that you can laugh at.
The author makes fun of architectural files - decisions that were made in different projects at different times, including by him. Describes how this decision was born, why the idea seemed cool and why the embodiment of the idea was terrible. Most of the systems he talks about are used in reality. The author makes concise conclusions about what should not be done or vice versa should be done to avoid such problems. Some basic theses (I didn’t write everything out - they will not be clear without context):
Video report - unfortunately the video starts from about the 10th minute. In the first part, Dan talks about how professionals in various fields practice their skills.
A report on how to travel to Mastery and what Mastery is in general. It is based on a story about folding origami "Jackstone", which the author could not fold for 15 years.
Basic definition: Mastery is an opportunity in context. It’s difficult to tell something about this report without retelling it completely. I recommend for viewing to anyone who is interested in the topic of improving their skills.
Video report
This report was the most anticipated for me - I wanted to hear first-hand about these three letters DDD. But, surprisingly, this report turned out to be one of the most boring reports at the conference. Maybe even because I already know quite a lot about this and heard little from the report. Evans talked completely without emotion, academic tone. Listening was hard, but the essence conveyed quite clearly.
The first part of the report is devoted to describing how important it is to select the aggregates and their roots and how this may affect the performance and survivability of the system in the future. The story was based on the example of the delivery of cargo containers across the oceans and the coordination of the delivery schedule. He showed how, depending on the choice of aggregates and their roots, the behavior of the system changes and what rakes are obtained in each of the cases. Key points: correctly formulate questions to the system and balance between normalization and denormalization.
The inconsistency between the states of the aggregates is normal and exists in any complex system. Therefore, it should be governed by agreements (SLA) that govern how long such inconsistency can exist in the system.
At the end of the report touched on a bit bounded context. Enevtual Consistencey must be used between contexts.
Video report
A good introductory report in the principles of reactive programming and event-oriented development. The author said that the main issue of reactive programming is a large entry threshold, but after overcoming this threshold, the approach becomes obvious and simple. Key points:
Video report
Nothing happens for free. For any architectural solution you have to pay, so there is no perfect abstract architecture. The flexibility of the architecture (as well as the system) is always relative and time dependent. Therefore, it is always necessary to explore and adapt.
Due to the different interests of different stakeholders, it is impossible to create one universal diagram. A set of diagrams should be considered as a set of maps of various scales, in which a set of abstractions is much more important than a set of notations. It is proposed to use the C4 model:
It is necessary to think in Components, and to implement in Classes. It is important to distinguish between these two points of view. And finally, a key message from the author of the report: return the architecture back to the developers !
Video report
A report on what the quality of the development process is about in general. Not just writing code, but generally the whole process. The report can be viewed if revenge 50 minutes of free time. in spite of the obviousness of the main theses, they are not used everywhere, which leads to poor results. KO broadcasts:
Video report
A report from a former saxophonist who became a developer. Introductory report of the second day of the conference, because it is about the world of development in general. About inspiration and courage when developing, about the quality of software, contradictions in the views and goals of developers and customers who produce low-quality solutions.
The author mentions the development process in the pledge of the story about Six Sigma , that the function is important for the customer, and the form for the developer. There is always a confrontation of internal and external quality. Here we must be able to balance, because internally quality determines, but not always, external. And this "not always" must be able to identify.
Video report
Soft - sucks. The rest of the report is an explanation of this thesis and a search for the reasons why this is so. main reasons:
Video report
Report on the benefits of the Event Sourcing approach over traditional normalized databases. Any DBMS sucks (Every database sucks!). But each settles its own unique and inimitable way. Therefore, it is necessary for each specific task to apply the appropriate tool for this task. Storing the flow of events instead of states allows you to achieve this. I did not manage to single out specific theses, because it was already the last report on the second day of the conference, but it’s worth a look.
Video report
For me, this report was one of the revelations of Captain Obvious: make auto-tests the most autonomous. The test should test a single particle of functionality at the desired level of abstraction. If the wrong level of abstraction is selected, then UI testing automation is impossible, because you need to look at the UI to evaluate its quality.
Video report
Strange report. A set of slides with statistics from Developer Productivity Report
Video report
I expected some sacred knowledge from the report on how to make really flexible databases, but everything turned out to be trivial:
The conference was lured to her not by the fact that it was possible to get to Europe at a corporate expense, but by a selection of invited authors, including Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. It is strange that there was no mention of it in Habré. Despite the fact that the conference was announced as a conference for developers, it was not about technology at all. There were several reports about the use of specific technologies, but most of the reports were about development in general.
The motto of the conference can be called the call "Adapt!". This thought sounded in very many reports. Maybe the organizers therefore did not give out notebooks in the package of participants - they wanted us to adapt? =) At the same time, they gave out pens and had to look for a notebook in the nearby stores.
')
Under the cut description and video reports that seemed to me the most interesting.
Paste the video directly into the article did not work, so the video is represented by links. If anyone helps with the insertion of the videos themselves, I will be grateful.
For myself, I singled out a few of the most useful and interesting reports, and arranged the rest in chronological order.
The most useful and / or interesting reports (I highly recommend for viewing)
How I Learned to Stop Worrying and Love Flexible Scope (Gojko Adzic)
Video report
A very informative first report that set the tone for the entire conference. The basic idea: flexible approaches are applicable only where there is a changeable external world. If the outside world is static in relation to the system, then the scrum degenerates into waterSrumfall , which entails overhead without additional profit. If the outside world is not well known or is changing rapidly, then you need to be able to adapt. As an example, the author cites the experience of the Ducati team during their debut on the track of the superbike. In a critical situation, everything is flexible, because you need to adapt quickly, otherwise you will not survive.
As a way to adapt to the situation, the author offers user stories (User Stories).
The main idea: from user stories you need to compile and use a roadmap for its intended purpose: as a " road map ". The author says that most of the roadmap he saw were actually a tunnel , not a road map . The tunnel assumes movement in one direction only, and not a multitude of paths. As an example, the author gives a car navigator. It is ideal for planning and orientation on the ground, because it shows two main information blocks describing the current situation:
- distance to the next turn;
- next turn direction.
Then the author turned to the principles of Palchinsky from the book by Tim Harford Adapt: Why Success Always Starts with Failure : a link to a quote about the principles.
The author shows that user stories should be used to analyze what the customer actually wants, and then to adapt to the current situation of the project. Do not try to implement all the stories, because it can either be unnecessary or very expensive. Instead, user stories should be viewed as a set of alternatives (road maps) that can be selected when the situation around the project changes.
He said that he was preparing the book "50 quick ideas to improve your user stories".
Architecture War Stories (Stefan Tilkov)
Video report
Report from the category of "how is it that smart people do stupid things." It is worth looking to try to compare your behavior with examples. Examples are all vital with real projects. In the end, the author was even asked the question “have you ever worked on successful projects”. The report looks very easy because of the abundance of examples and interesting points that you can laugh at.
The author makes fun of architectural files - decisions that were made in different projects at different times, including by him. Describes how this decision was born, why the idea seemed cool and why the embodiment of the idea was terrible. Most of the systems he talks about are used in reality. The author makes concise conclusions about what should not be done or vice versa should be done to avoid such problems. Some basic theses (I didn’t write everything out - they will not be clear without context):
- Don't cache the cache.
- Data should be free of code dependencies.
- Fight the madness.
Jackstones: the journey to mastery (Dan North)
Video report - unfortunately the video starts from about the 10th minute. In the first part, Dan talks about how professionals in various fields practice their skills.
A report on how to travel to Mastery and what Mastery is in general. It is based on a story about folding origami "Jackstone", which the author could not fold for 15 years.
Basic definition: Mastery is an opportunity in context. It’s difficult to tell something about this report without retelling it completely. I recommend for viewing to anyone who is interested in the topic of improving their skills.
Acknowledged CAP at the Root - in the Domain Model (Eric Evans)
Video report
This report was the most anticipated for me - I wanted to hear first-hand about these three letters DDD. But, surprisingly, this report turned out to be one of the most boring reports at the conference. Maybe even because I already know quite a lot about this and heard little from the report. Evans talked completely without emotion, academic tone. Listening was hard, but the essence conveyed quite clearly.
The first part of the report is devoted to describing how important it is to select the aggregates and their roots and how this may affect the performance and survivability of the system in the future. The story was based on the example of the delivery of cargo containers across the oceans and the coordination of the delivery schedule. He showed how, depending on the choice of aggregates and their roots, the behavior of the system changes and what rakes are obtained in each of the cases. Key points: correctly formulate questions to the system and balance between normalization and denormalization.
The inconsistency between the states of the aggregates is normal and exists in any complex system. Therefore, it should be governed by agreements (SLA) that govern how long such inconsistency can exist in the system.
At the end of the report touched on a bit bounded context. Enevtual Consistencey must be used between contexts.
Just nice and interesting reports in chronological order.
Going Reactive: Event-Driven, Scalable, Resilient & Responsive Systems (Jonas Bonér)
Video report
A good introductory report in the principles of reactive programming and event-oriented development. The author said that the main issue of reactive programming is a large entry threshold, but after overcoming this threshold, the approach becomes obvious and simple. Key points:
- you should always use weak binding;
- it is necessary to design so that there are never locks;
- it is necessary to design asynchronous interaction initially;
- actors communicate only through messaging;
- using Shared nothing architecture;
- location transparency;
Agility and Simon Brown
Video report
Nothing happens for free. For any architectural solution you have to pay, so there is no perfect abstract architecture. The flexibility of the architecture (as well as the system) is always relative and time dependent. Therefore, it is always necessary to explore and adapt.
Due to the different interests of different stakeholders, it is impossible to create one universal diagram. A set of diagrams should be considered as a set of maps of various scales, in which a set of abstractions is much more important than a set of notations. It is proposed to use the C4 model:
- System Context
- Container
- Components
- Classes
It is necessary to think in Components, and to implement in Classes. It is important to distinguish between these two points of view. And finally, a key message from the author of the report: return the architecture back to the developers !
What Makes a Good Development Process? (Bruce Eckel)
Video report
A report on what the quality of the development process is about in general. Not just writing code, but generally the whole process. The report can be viewed if revenge 50 minutes of free time. in spite of the obviousness of the main theses, they are not used everywhere, which leads to poor results. KO broadcasts:
- Using repositories for versioning, testing everything that can be tested and automating everything that is done more than 1 time, including tests.
- Communication, honesty and transparency throughout the project life cycle. First of all before the customer.
- To produce in the minimum valuable product (Minimum Valuable Product). But it is necessary to produce a product that is valuable for the customer, and not for the developer. Based on this, it is necessary to build priorities in solving specific problems.
- Automatic continuous delivery (Continuous Delivery), as a mechanism for continuous version update. This allows you to release the first version of MVP as early as possible and further develop on the most important functions.
- Mistakes are inevitable. They need to learn and adapt (again, "Adapt!").
- BrainStorming replaced by BrainWriting. During BrainWriting, participants express their opinions in writing, and then everyone gets together and discusses. This is better than BrainStorming, because everyone can speak out, not just the loudest.
- The most clear and supported solution is the best choice in most cases.
- It is necessary to do CodeReview.
McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight (Chad Fowler)
Video report
A report from a former saxophonist who became a developer. Introductory report of the second day of the conference, because it is about the world of development in general. About inspiration and courage when developing, about the quality of software, contradictions in the views and goals of developers and customers who produce low-quality solutions.
The author mentions the development process in the pledge of the story about Six Sigma , that the function is important for the customer, and the form for the developer. There is always a confrontation of internal and external quality. Here we must be able to balance, because internally quality determines, but not always, external. And this "not always" must be able to identify.
Responsibly maximizing craftsmanship in software engineering (Theo Schlossnagle)
Video report
Soft - sucks. The rest of the report is an explanation of this thesis and a search for the reasons why this is so. main reasons:
- Development of high-quality software is a very difficult task (practically not feasible).
- Engineers are subject to "tradition." It is so accepted here and it works, so do not touch it.
- Developers do not read academic literature and do not know the basics.
- Teams within a company or even a project do not share the groundwork.
- Engineers work perfectly autonomously (but in small projects), so problems arise in large projects.
- It is often easier to write from scratch than to refactor, but most prefer to refactor.
Polyglot Data (Greg Young)
Video report
Report on the benefits of the Event Sourcing approach over traditional normalized databases. Any DBMS sucks (Every database sucks!). But each settles its own unique and inimitable way. Therefore, it is necessary for each specific task to apply the appropriate tool for this task. Storing the flow of events instead of states allows you to achieve this. I did not manage to single out specific theses, because it was already the last report on the second day of the conference, but it’s worth a look.
Well, reports that do not waste your time
Abstraction Level for Your Tests (Gerard Meszaros)
Video report
For me, this report was one of the revelations of Captain Obvious: make auto-tests the most autonomous. The test should test a single particle of functionality at the desired level of abstraction. If the wrong level of abstraction is selected, then UI testing automation is impossible, because you need to look at the UI to evaluate its quality.
Data-Driven Software Engineering (Jevgeni Kabanov)
Video report
Strange report. A set of slides with statistics from Developer Productivity Report
Databases & Schemas in an Agile World (Andrew Godwin)
Video report
I expected some sacred knowledge from the report on how to make really flexible databases, but everything turned out to be trivial:
- use PostgreSQL, because it gives minimal time for idle time and locks when changing the scheme;
- the scheme should be modified only within the framework of the transaction;
- well, it proposes to use hybrid (part of the data in typed columns, and the rest in blob fields in the form of xml or something else) schemes for optimization between flexibility and speed.
Source: https://habr.com/ru/post/224295/
All Articles