-
Simple Caching For Akka Actors
•
Recently I needed to cache some lightweight data into actor’s local memory to not make unnecessary calls to third party service over the internet. I think what I came up with is a pretty simple implementation (hence I named the article simple caching in akka). But the idea can be expended with small changes if any to use it to cache actor messages. Let’s imagine the word of actors where we have one actor per user and we send messages to user actors to get some info back. Now when we say each user (actor) is responsible to cache it’s own data it means each actor will use even more memory so at some point we’ll need to scale out because we’ll run out of memory (not that we didn’t have that problem without cache at first place). But it’s a good thing that we know we need to scale out from the beginning because I didn’t mention about high availability yet, so we at least need two boxes.
read more -
Testing styles in ScalaTest
•
Over time different libraries brought different testing styles, jUnit, xUnit, Rspec, ert. Nowadays since many people have different backgrounds and different taste when it comes to writing unit tests, most test libraries offer many testing styles and ScalaTest isn’t an exception. To me there are three groups of testing styles. One would the traditional jUnit, xUnit style where you define a test class and unit tests are methods in that test class, you also define setUp and tearDown methods that must be called before and after each unit test. Of course there are also setUp and tearDown versions that run once per test suit but I don’t want to talk more about it here. I must admit that this isn’t my favorite style and here is why. I like to unit test aggressively without skipping any business cases instead of just relying on code coverage and saying my other test already is hitting those lines. If I have a class with many methods I write many unit tests for each method, an example would be when a method takes a parameter and based on different values for those parameters it does different things, of course we want to have multiple unit tests for that method to cover all business cases for that method. So this alone groups unit tests in a test class by functions, another thing is that most likely unit tests for function A will share some setup logic. This testing style forces as to put setup code for all unit tests for function A in setup method, and when we have like 10 such functions, setup method will have the setup code for all those function which will make it long, hard to read, also it will be extremely hard to tell which setup code is for which unit test. Another option is to define setup code in each unit test with isn’t really a good idea since one we’ll have duplicated code and unit tests now will be longer than they need to be and hard to understand. I see some people like to solve this problem by moving this common code into private methods. Although this solves code duplication problem, also makes unit tests shorter but it introduced another big problem. When I read a unit test I want to know what the method is doing in 2 seconds, unit tests are documentations right. Now you come across this private method call, you have to find it’s implementation, read the ugly code there and jump back to continue reading what that unit test is trying to test. It’s a nightmare to me, I call that unit test anything but readable and I sure don’t want to be one maintain that code. Before I moved to next type of unit tests, I must mention what styles ScalaTest is offering here. FunSuite and FlatSpec, you can read more about those in ScalaTest documentation. Both are flat as mentioned, one is more like jUnit, other is more like xUnit.
read more -
Running Akka Applications
•
With akka becoming more and more popular, akka kernel being deprecated, docker rocking the word, Typesafe releasing ConductR and more folks getting to scala, I wanted to write a post about how to run akka applications. Akka applications aren’t servlet applications java developers are used to, normally those are main class applications in a jar file and have other jars as dependencies. So it’s no-brainer that we can just use java command and no container like tomcat or jetty is need. I will cover how to run in development while iterating on a task. How to run it in development and tunnel the port and let others point to your code before you even go to production or pre production environment and how to run it inside a docker container in production and pre production environments. Unforunatly I didn’t get hold of ConductR to try it myself, so I won’t be writing about it in this post. Btw, most of this should be to relevant other scala/java main class applications not only akka and akka http applications.
read more