You might ask, why did I stop writing feedbacks on Craft Conference sessions?
It’s just because I post them on my company’s blog! :-)
Here there are: Abridged feedbacks.
By the way, as a foreign Craft Conference ticket winner, the guys at Prezi (one of the organizer company) asked me if I was ok to do an interview with them. The fact is that it changed a bit and it moved to I had to film myself during the conference.
It was real fun and here’s the result:
Jonas is CTO of TypeSafe a company that provides a Reactive Platform which helps to deliver responsive, resilient and event-driven applications. Typesafe spearheaded the Reactive Manifesto which defines a common vocabulary for reactive applications.
Unsurprisingly, Jonas presentation was about why and how to build a reactive application!
We’re entering a new era. When building an application we now often have to deal with mobile devices, cloud computing, distributed components. We need to build softwares that are real-time, responsive…
As Jonas said, our applications now have to react to:
In one word, they need to be reactive!
First of all, we need to go async! (see Amdahl’s law). We do need to avoid blocking processes (which kills scalability). An event-driven system makes use of asynchronous message passing which gives lower latency, better throughput and bring more loosely coupled components.
Our applications need to be scalable, meaning being able to be expanded on demand. Better scalability comes with systems that are built of isolated components that share nothing with loose coupling and that communicate asynchronously. We need to minimize contention and maximize locality of reference. One thing that need to be kept in mind while dealing with distributed computing is the 8 fallacies of Peter Deutsch: the network is inherently unreliable!
We also need to build resilient systems that are capable of recovering quickly in case of problems. We need to avoid defensive programming where errors are mixed with business logic and disseminated everywhere in the code. Our clients should only deal with validation errors, not with applications’ ones. Our services should be built both with a dedicated supervisor which role would be to handle things in case of issues. It should be up to the supervisor to decide what to do (kill, suspend, resume, …) and so business logic and error handling are decoupled!
Last but not least: responsiveness! We need to keep the latency consistent. We need to make asynchronous and non blocking requests and responses and switch from pull to push so that our UI’s are interactive and always synchronized!
Links:
First of all, I’m a big fan of Gojko’s work. I’m constantly trying to contaminate people around me and ask them to read Impact Mapping which I think might be a super duper solution to lesser the gap between IT and business people (and this is just one advantage amongst others! Just read it
This presentation was not (only) about Impact Mapping, though, but more on how to write better User Stories. Gojko showed us how by spending 10 minutes more on writing user stories, they could be 10.000 times better :-)
The fact: our systems lack on flexibility. And that’s pretty strange, because this is always something people are searching for. Most of the time they’re even OK to pay more for flexibility (think about train of flight tickets that are much more expensive with some flexible options).
Systems are often built with a lack of flexibility and when their limits are reached people get into a crisis situation where the only possible option to keep the business alive is to Think & Redesign the whole system (and Measure if they’ve built it the right way this time!). But why wait for a crisis or chaos to do things the right way? Wouldn’t it be simpler to do it from the beginning? Make sense, uh? Jez Humble wrote about “Does Systemic Change Require a Crisis?” in his Lean Enterprise book. He quoted “The Corporate Culture Survival Guide” book by Edgar Schein
Ok, so we should think about flexibility sooner. But keep in mind that trying to have a flexible scope is impossible without having a big picture of the goal to reach. User Stories are often disconnected from real business needs. Why? Because business people like to write what they would like to have on Power Point slides, not by saying things like “as a user I want this or that”.
Tim Hartford wrote the Adapt book
So, how to take those dimensions into account? Think about:
We somehow have to create a GPS for our apps! And as a GPS system would do, replan in case of problems! User Stories should somehow include the “excepted time for arrival” information!
How could we apply the 3 dimensions above in our User Stories? Here’s Gojko’s advice:
”: create options during what he calls a divergent phase and then make choices during the convergent phase.
© Tim Brown
More links:
Bodil is a well-known conference speaker that works as a developer at Future Ad Labs, a London based company.
If you’re used to read her tweets, you should know that she has a pretty good sense of humor. That one she tweeted about 2h before her keynote was quite funny:
…and gave the right tone before she talks :-)
What I have to say is that I was not disappointed. Some of her slides (My Littlle Pony, cats’ videos …) and the way she ran her presentation, were hilarious. She also piqued my curiosity: now I want to know more about Dijkstra!
Well, being funny is one thing, but more important, Bodil made also a pretty smart presentation.
After spending some time describing computer history she ended up with this question: Would processes or good project management bring great code? Is being Agile the answer? Well even with the picture of Bob Martin Showing The Way with Extreme Programming like Moses raising the 10 commandments, the answer is no! Simply because people are different! Some people love doing pair programming while shier ones would prefer being concentrated on TDD. Do code review everything would be a silver bullet? Sure no….
But wait, why is there so much bad code? Is that a matter of what language you’re using? No way! The reason is simple: complexity! There is too much complexity in our software. Would testing save us, then? Would it be the way to deal with complexity? Obviously not, it’s almost impossible to tests every case. You’ll always find a use case that is not covered by tests and thus subject to bugs. Bodil quoted Dijkstra, what he said about testing was one of my favorite: “Testing is hopelessly inadequate… it can be used very efficiently to show the presence of bugs but never to show their absence”
The cause is that we’re trying to manage a code with way too much possible sates, our code deals with way too much mutable objects that can have their state changed by any kind of unexpected side effects behaviors.
So, what would help up? Are we doomed forever? Sure not ;-). First of all, have a look at “Out of the tar pit” paper by Ben Moseley & Peter Marks where they explain why complexity causes so much trouble in our software and what would be the right way to deal with it.
Well, it might be time to look at functional programming language or at least adapt a functional way of programming in our code! How? There are some good recipes, think about that one: if you think your object or any class member should be immutable, just put a sealed (or final) keyword in front of it! It will also help in a multithreaded environment where no lock will be needed anymore as share object can never change!
Nouhoum Traore said this one time: “functional programming style is a programming style that has style” :-) We can do nothing but agree!
Links:
It’s almost an impossible task to relate every single thing I’d like to, when trying to recap such an incredible conference.
The quality of the speakers and the talks were so great that the best solution would be for me to ask you to watch all the webcasts ;-) Ok; I know you might not do it, so I’ll try to summarize the best as I can.
First of all, I’d like to say that the place itself and the overall organization were perfect. Simply have a look at the tags every attendee received and you’ll understand!
We had all the useful information in our hands: Wifi code, official twitter #hashtag, the schedule, conference map, city map, a little Hungarian language guide and even 4 free beers tickets for the party!
Oh, one last thing before telling you about the sessions: I was lucky enough to have a free entrance! Craft Conference organized a quiz on twitter, I participated and guess what? Yep, I won one of the 3 tickets!
Well, it’s been some time since I wanted to create my own blog.
Even if I do already write on my company’s blog, this format doesn’t allow me to put some personal thoughts that much…
I wanted a place where I could dump things when I had the feeling I’d had to. Freely.
I went to the Craft Conference 2014 this week and it was so inspiring that it sounds clearly the right time to do so!
First blog post will obviously be about the Craft Conference but I hope you’ll find some other interesting readings (or not) pretty soon.
Thanks for reading!
one.hundred.acorns 