-
Notifications
You must be signed in to change notification settings - Fork 0
/
abstracts.txt
115 lines (82 loc) · 6.67 KB
/
abstracts.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
BIO
===
Rafael is a Lead Developer at Budapest-based Emarsys and popular speaker in the Hungarian software community.
As a founding member of Emarsys CraftLab - the dedicated coaching team of Emarsys - he has taught university
courses and lectured at numerous conferences. His passion for short feedback loops drove him to create Lean Poker,
a workshop where developers have the opportunity to experiment with continuous delivery in an artificial environment.
Lean Poker
==========
Lean Poker is a day long coding challenge that's not only fun, but also provides a safe environment in which you can
practice continuous deployment and fast delivery of valuable software.
You and a small group of strangers are going to develop a bot in a language of your choice, that plays poker against other
bots. All you need to do is write a function that takes a data structure containing cards and bets your bot sees during the
game, and return a single number: the amount you are willing to bet at that point.
Now here is the catch: even before you start coding the bots play a round in a matter of seconds, and if your bot wins
you get points. If it comes second, you get less points. Otherwise you get nothing. The next minute another game plays,
and another one, and another one… that goes on all day long, while you and your friends are desperately hacking away on
the code, and keep deploying version after version.
During this pretty intense day you will sometimes be cheering for your bot to take over, you will be deploying
desperately to change the course of events when your bot keeps losing, but even more importantly you will learn how to
create as much value as you can in a short period of time, while you are mostly just having fun.
Please check out http://leanpoker.org for more information.
Clean persistence
=================
Separating the database layer from the rest of code has always been an important topic, yet more often than not
web applications end up looking like huge wrappers around the database. Keeping your database related code
nicely isolated is hard, and it's even harder with applications where most of the logic has to do with reading
and writing data. We will look at common mistakes, testing, design patterns and polyglot persistence.
How I learned to love legacy code, and why you should, too!
===========================================================
For a long time I thought that working on a green field project was the best thing that could happen to a developer.
I would look at the nightmarish company codebase blaming the incompetence of the people who had worked on it
previously. If only they read more books or had better mentors - I complained, but I was wrong. Not because if
something generates revenue, then it should be loved! No... that's not a real excuse for bad code. There is a lot more
disturbing truth about legacy code, and we need to face it. We need to learn why and how to embrace technical debt.
Learning to fall
================
When people talk about advantages of microservices, easy scaling and resilience comes up frequently. What they don't
usually tell you, is that robustness does not come for free. If you don't put extra effort into gracefully failing
when one of your dependencies is down, microservices will only make your system even more brittle.
In my presentation I will recount our journey from an unreliable monolith to a robust set of microservices with a
special focus on architectural patterns that helped us along the way.
=====
PLANS
=====
The joy of learning
===================
A good developer never stops learning. We read countless books and blogs, watch code casts hour after hour. All that
is important to keep up to date with new technologies since our entire industry is all about innovation. However
this is not the most important kind of learning we need to do as a developer. Good developers understand how to write
clean, well maintainable code, amazing developers also know what makes a great product. We learn that from our mistakes
and from customer feedback, and there is nothing more fulfilling than a happy user. So how can we get better at
learning?
A step beyond modules
=====================
The jury is in: breaking down your web monolith to microservices or feature services is a viable option to scale
an organization. Services add an extra abstraction layer beyond modules that is immensely useful in structuring
your codebase. Understanding the characteristics of this extra layer, finding the traps along the way, learning
the tools that come with it is necessary to take full advantage of this new abstraction. So let's explore what
clean code means in the microservices world!
Minimum viable team: testing your ideas alone
==============================================
So you have an idea for a great application, but not much money nor friends to help out. You already asked people
if they would be interested, and they were really supportive, but when it comes to coding you are all alone. For
a developer, who is used to working in a team, it can be really demanding to go through with even a moderately
sized project. You know how to be effective as a team, but the same practices seem to hold you back when you are alone.
In the last few years I started a number of projects alone and managed to build, deploy and validate (or invalidate)
them within weeks of starting the project, and all that as a hobby next to my day job. Taking a few of these projects
as examples, I will tell you what agile practices I hang on to and what I changed or replaced to boost my productivity.
SOLID microservices
===================
The SOLID principles of OOP are probably the most important guidelines we use in software design. We apply them at
both class level, and at component level. Lately microservces have been introduced as a new, even higher level
abstraction to decompose large system. Let's explore what implications SOLID principles may have on microservices.
Do these principles apply to them? Do microservices help you to stay SOLID at lower levels?
Free beer and immortality
=========================
If a politician promised free beer and immortality people would laugh at him. If he promises workplaces and cheap
natural gas for heating they applaud him. The ironic thing about this is that the "free" beer is way more realistic
than a workplace for everyone who wants to do manual labour. Immortality is not entirely impossible, but burning
fossil fuels mindlessly will definitely kill us pretty soon unless we stop. The key phrase here is "technological
singularity" and it's a lot closer then we care to believe. But how do we get there? How do we adapt our society?
Who is going to be the last person to work and what's going to be the last task he completes?