Skip to main content

JFokus 2013: Second confrence day

On the second day I didn't make as much notes as I did on the first. That doesn't mean that the session weren't interesting I just focused more on listening. I attended eight session on the second day where the last one was the most memorable one by Dan North but I'll go through them chronologically. Some of the text is word to word notes from the presentations and some are my view of how I understud and processed the topic in my mind.

Building scalable, highly concurrent and fault-tolerant systems: Lessons learned

Jonas BonĂ©r told what makes systems slow and what kind of solutions can be used to speed them up or at least speed up the response to the user. 

First lesson to learn is There are no free lunches. If you use some approach it affects to something else. Some might use the phrase There are no silver bullets which means the same thing or at least that's how I undestud it.

Second topic was about concurrency. Mutables and threads isn't a good a combination. Using threads and mutables means you have to use locks in your code and you can't create generic locks that could used in every situation so that leads to more code, more maintaining which leads to more possible points where your program can fail. There are ways to use concurrency and possibly avoid problems with threads and locks etc., here's a few keywords that I picked up: Dataflow concurrency, actors, STM, agents. I've used akka framework and actors in one project and they are a easy way to bring concurrency to programs.
Blocking is also the enemy of scalability and a way to get around this is to use async calls and because every confirmation of sent and received messages is expensive in network time another way is to use ACK responses. 

Last notes I have are about Big Data. When and where Big Data is used functional programming should also be the choise of programming paradigm because it fits like a glove, think about MapReduce. Some acronyms related to NoSQL and Big Data worth a look are CAP and BASE and ACID vs. BASE.

Patterns fo key-value stores

On this I didn't make many notes just a few things to remember with KV stores. Most of this session talked about RIAK and Redis KV stores so the topic was a bit misleading.
  • Value can be a reference to a key
  • Consistent hashing
    • Data shared among servers
  • RIAK has support for REST, JavaScript and Erlang
  • Redis has some sort of transaction managent and could be a good choise as cache in front of a RDBMS
  • Two important things to remember with KV stores are naming the key and having a good data model
    • personal note: even though KV stores are schemaless you always need to have a data model

Real-Time delivery architecture at Twitter

This was interesting actually so interesting that I only managed to make three notes because I was concentrated on listening.
  • Twitter uses Redis as a cache on all reads
  • Statistical backend is Hadoop
  • Read, write and search are all separated in their own paths

Continuous delivery patterns for large software stacks

Hans Dockter introduced commonly used delivery patterns. There's no way I could explain these better than he did in his presentation material and these can propably be found from the internet so I'll just list the patterns here.
  • Binary snapshots
  • Branching
  • Single build
  • Water gater

Stop doing retrospective and start your Toyota kata

This presentation talked about the principles of Toyota kata. So Toyota kata is a way to constantly improve and it's about experimenting. 
First thing to know is that 50% experiments has a different end result than expected. So when your experimenting things don't always go as you expected.
As I mentioned Toyota kata is about constant improvement and that means that all the time there's some experiment going on in the background.

Toyota kata is actually two katas improvement kata and coaching kata. 

In the improvement kata you set a concrete vision, something that can be measured. To get to that vision you set challenges on the way to the vision think of them like check points on the way to the big finish.

The coaching kata is about team leader supporting the team, pointing them to right direction.

My last note about this was something like this: To improve you must experiment.

Rocking the Gradle

Hans Dockter introduced Gradle build tool e.g. to replace maven. I didn't make any notes because he was talking so fast and demonstrating so many different possibilities of what you can do with it. Gradle is something I'm going to investigate at some point in the future even though I've heard it has some performance problems compared to maven.

Simplicity: the way of the unusual architect

This was the end keynote by Dan North. Firstly he presented some history and how everything in software development repeats itself in some way e.g. CORBA, JMS, SOAP, REST same basic idea in all of them just a different implementation. He made great points about software development but he presented them in a non-serious way so that the audience was concentrated on listening him. This was a great way to end the confrence. Here's a few notes I made during his session.
  • Three ages of everything
    • explore
      • maximize discovery
    • stabilize
      • minimize variance
    • commoditize
      • minimize cost
  • People make things complex when things should be simplified
  • Observe complexicity
    • e.g. What is this meant for, is it doing more than it should be

Popular posts from this blog

Sharing to help myself

It's been a while since my last post but I have a good excuse. I've been in a new customer project (well new for me) for two months now and have absorbed a lot of new information on the technology stack and the project itself. This time I'll be sharing a short post about sharing code and how it can help the one who's sharing the code. I'll be giving a real life example of how it happened to me. My story Back when I was implementing first version of my simple-todo REST-service I used Scala and Play framework for the service and specs2 for testing the implementation. Since then I've done a few other implementations of the service but I've continued to use specs2 as a testing framework. I wrote about my implementation and shared the post through various services and as a result someone forked my work and gave me some pointers on how I could improve my tests. That someone was Eric Torreborre  the man behind specs2 framework. I didn't take his ref

Simple code: Immutability

Immutability is a special thing that in my mind deserves a short explanation and praise. If you're familiar with functional programming you surely recognice the concept of immutability because it's a key ingredient of the paradigm. In the world of object oriented programming it's not as used and as easy to use approach but there are ways to incorporate immutability to parts of the code and I strongly suggest you to do so. Quick intro to immutablity The basic idea of immutability is unchangeable data.  Lets take a example. We have a need to modify a object's property but because the object is immutable we can't just change value but instead we make a copy of the object and while making the copy we provide the new value for the copy. In code it looks something like this. val pencil = Product(name = "Pencil", category = "Office supply") val blackMarker = pencil.copy(name = "Black marker") The same idea can be applied in functions and metho

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does