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

Comments

Popular posts from this blog

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: Readability

Readability, understandability, two key incredients of great code. Easier said than done, right? What one person finds easy to read and understand another one finds incomprehensible. This is especially true when programmers have different levels of understanding on various subjects e.g. object oriented vs. functional or Node.js vs. Java. Even though there are obvious differences between paradigms and programming ecosystems there are some common conventions and ways to lower the barrier. Different approaches It's natural that in programming things happen sequentally e.g. you can have a list of objects and you need to do various things to the list like filter some values out and count a sum of the remaining objects based on some property. With the given list const stories = [   {name: "authentication", points: 43},   {name: "profile page", points: 11},   {name: "shopping cart", points: 24},   {name: "shopping history", points: 15},   {name: &qu

Simple code: Unit tests

Unit tests are the developers number one safety net. Let that sink in. This is the number one reason for writing unit tests. Unit tests are written by developers for developers to ensure that the code works as expected and handles happy and sad paths correctly. With enough unit test coverage the tests enable a safe environment for refactoring and rewriting code. Unit test scope Unit test should test a single thing, a method or function call and it should test only one use case within. In other words a unit test should test a function with a single input. This is a important guideline to understand. When a unit test tests a function with single input it makes the test isolated, repeatable and predictable. Example of good tests: @Test fun findsAddress() {   val address = findAddress("Stevens street 35", "Southport", "Australia")   assertThat(address).isNotNull() } @Test fun doesNotFindAddress() {   val address = findAddress("Stevens street 697", &q