We've all seen View Controllers consisting of hundred or even thousands of lines of code. One popular strategy of reducing view controller complexity is using the Model-View-ViewModel (MVVM) design pattern. But that's not the only way to separate the view controllers into smaller, easier to understand components. This post will explore using small Presentation Control classes to achieve a similar effect. They can even be used together with MVVM components.
Last week, the first TestWorks Conf was held in Amsterdam. This hands-on conference featured a plethora of test automation tools and allowed the participants to gain practical experience with them. Since we feel and expect that all participants will take next steps towards improving their test automation practices, we decided to take a glance into the future and discuss the future of testing and automation together with Alan Richardson.
In a series of blogposts, we would like to share parts of our vision on testing and automation in the near future. First stop will be: the role of the tester in 2020.
In several previous posts we've been using Babel to actually run our (transpiled) code. But how far can we get if we only use natively supported features? Let's dig in the stable features of Node.js 4 and see how much of our code can be written without a transpiler dependency.
The idea of this post came from another blogpost which compared the performance of a little benchmark in C, Go and Python. The surprising result in that blog was, that the Go implementation performed much better than the C version.
The benchmark was a simple program took one command line argument and computed the sum of all integers up until the argument.
I wanted to see what was going on so I tried to run it locally and indeed, when invoked with a parameter 100,000,000 it took 0.259 seconds for the C implementation to finish and only 0.140 seconds for the Go version.
As a consultant I am doing a lot of things, so to keep up I have always used some form of a TODO list. The reason why I did this is because it helped me break down my tasks in to smaller ones and keep focusing, but also because I kept remembering the quote I once heard “smart people write things down, dumb people try to remember it”.
Years ago I read the books “Seven habits of highly effective people” and “Switch”, in my research in to how to become more effective I came in to contact with GTD and decided to try it out. In this post I want to show people who have heard about GTD how I use it and how it helps me.
In this post I will implement the union-find algorithm in Scala, first in an impure way and then in a purely functional manner, so without any state or side effects. Then we can check both implementations and compare the code and also the performance.
The reason I chose union-find for this blog is that it is relatively simple. It is a classic algorithm that is used to solve the following problem: suppose we have a set of objects. Each of them can be connected to zero or more others. And connections are transitive: if A is connected to B and B is connected to C, then A is connected to C as well. Now we take two objects from the set, and we want to know: are they connected or not?
This problem comes up in a number of area's, such as in social networks (are two people connected via friends or not), or in image processing (are pixels connected or separated).
Because the total number of objects and connections in the set might be huge, the performance of the algorithm is important.
At my work we have a long running service that's using the Akka-Spray stack. Recently it crashed and we wanted to check its logfile to find some clue about the cause. But there was nothing there to help us.
Eventually we did find the cause, it had been an OutOfMemoryError which was thrown in one of the actors, and because this wasn't caught anywhere (and it shouldn't), it terminated the entire actor system.
It would have saved us some time if this error had been logged somewhere, so that is what this blog will be about.
One of the new features of ECMAScript 2015 is the WeakMap. It has several uses, but one of the most promoted is to store properties that can only be retrieved by an object reference, essentially creating private properties. We'll show several different implementation approaches and compare it in terms of memory usage and performance with a 'public' properties variant.
The android-test-support library has ditched the ActivityInstrumentationTestCase2 base class for a cleaner approach using JUnit4 rules. This is nice and clean, but te documentation is currently lacking on how to proceed if your Activity requires Intent extras to run. This post demonstrates how to make that work.