About Arthur

My name is Arthur Arts and I love creating great software and making customers happy by delivering value. I'm an avid student of all things concerning Agile Development and Lean Thinking. I love the pragmatism and common sense that lies beneath it.

Scala Snippet: How to filter a list in Scala

In Scala, filtering and processing collections is easy and elegant. There are many filtermethods available, but the most used will probably the basic filter method.

Here’s a code example of some filtering on my (ex)camera collection.
The filter method will not only work on Lists, but on any Scala collection.

Running this example will give you the following result:

original article

Scala Snippet: multiline statements in the Scala REPL console

One of the coolest things a standard Scala install will give you, is the Scala interpreter.
Technically speaking, this is not an interpreter. In the background, each statement is quickly compiled into bytecode and executed on the jvm.
Therefore, most people refer to it as the Scala REPL: Read-Evaluate-Print-Loop.

You can access it by starting a command shell on your system and typing in ‘scala‘.
Do make sure your either run it from the place where scala is installed or have scala on your environment PATH.

By using the repl, you can quickly experiment and test out different statements. Once you press ENTER it will evaluate the statement and display the result.

Frequently you want to execute multi-line statements and luckily the repl has a solution for that.

Simply type in :paste and the repl will accept multiline statements.
To exit this mode and evaluate your code, simply type CTRL+D.

Example:

original article

Bruce Lee’s Top 5 Agile Coaching Tips

bruce-lee-agile-master

When I was a kid, I was a big Bruce Lee fan. I walked around the playground rubbing my nose with my thumb. When I had a piece of rope, I had to do my version of the nunchaku routine from Way of the Dragon and made cat-like noises. Looking back at Lee, I find it quite striking how many of the principles of his fighting style Jeet Kun Do apply to agile practices.

Check out these descriptions of the fighting style:

  • “Jeet Kune Do is not fixed or patterned, and is a philosophy with guiding thoughts.”
  • “Jeet Kune Do practitioners believe in minimal movements with maximum effects and extreme speed.”
  • “The system works by using different “tools” for different situations, where the situations are divided into ranges, which is kicking, punching, trapping, and grappling, where martial artists use techniques to flow smoothly between them. “
  • “Through his studies Lee came to believe that styles had become too rigid and unrealistic. He called martial art competitions of the day “dry land swimming”. He believed that combat was spontaneous, and that a martial artist cannot predict it, only react to it, and that a good martial artist should “be like water” and move fluidly without hesitation.”

JKD is a reactive style that responds to changes in in situations and applies the best “tool” for getting the job done in the fastest way possible in that situation. JKD does not care about styles or forms for the sake of it.

Ofcourse this philosophy resonates highly with an agile mindset.

So just for fun, here are my Top 5 Bruce Lee Agile Coaching Tips

Continue reading

Scala Snippet: Object, Companion Object and Static Methods

If you are a Java developer moving to Scala, one notable difference in terminology that can cause confusion is the term ‘object’.
In Java an object is always an instance of a class, created by calling a constructor.

Object

In Scala an object is used for defining a single instance of a class with the features you want.

In practice this means you will use it:

  • to keep utility/helper methods and constants in one place
  • to have a single immutable instance to share across a system
  • to implement the singleton design pattern to coordinate actions across a system

An object can have the same features as a class. You can extend other classes or traits. The only notable difference is that an object cannot have constructor parameters.

Companion Object

In Java there might be occassions where you want to use static methods.

In Scala you define these methods inside a ‘companion object’, which has to be defined in the same source file as the class.
The class and object can access each others private methods and variables, but you have to do it as you would call a out of scope static method in Java.

Checkout this example in the repl:

As you can see, I’ve used the “static” method from the companion object to update the shuttercount when calling the makePicture method on my canon Camera.

Finally, a singleton object that does not share the same name with a companion class is called a standalone object.

original article

Scala Snippet: Case Class vs plain ordinary Class

In Scala there exist the construct of a ‘case class’. According to Martin Odersky this supports you to write a “regular, non-encapsulated data structure”. It always seems to be associated with pattern matching.

So when to use a case class and when to use a ‘plain’ class?

I found this nice explanation stating:

“Case classes can be seen as plain and immutable data-holding objects that should exclusively depend on their constructor arguments.

This functional concept allows us to

  • use a compact initialisation syntax (Node(1, Leaf(2), None)))
  • decompose them using pattern matching
  • have equality comparisons implicitly defined

In combination with inheritance, case classes are used to mimic algebraic datatypes.

If an object performs stateful computations on the inside or exhibits other kinds of complex behaviour, it should be an ordinary class.

Defining a case class gives you a lot of boilerplate code for free:

  • Getters are generated for the constructor parameters. Setters are only generated when the parameters are declared as var. They are val by default.
  • A nice toString method is generated.
  • An equals and hashCode methods are generated.
  • A copy method is generated to clone an object.
  • An apply method is generated, removing the need to use the new keyword when creating a new instance of the class.
  • An unapply method is generated.

Test it out by starting the Scala repl in a terminal:

If you type in the name of your object with a ‘.’ and press tab, the repl will display some of the available methods that are generated.

Final note
Alvin Alexander writes that case classes are primarily intended to create “immutable records” that you can easily use in pattern matching expressions.
So while you can define the constructor parameters as var, they are intended to be val.

original article

Scrum Master Tip: Make it transparent!

I am frequently asked by colleagues for advice on how to be a good Scrum Master. I will discuss some of the tips I share in a couple of blog posts.

First of all I do like to state that I believe it’s best to have a Scrum Master that is able to get his hands dirty in the activities of the team (i.e. coding, analyzing, designing, testing etc.). It will enable him/her to engage and coach at more levels than just overall process.

In my opinion one of the most important things a Scrum Master has to do is to make things transparant for the whole team.

Now this seems like very simple advice, and it is. However, when you are in the middle of a sprint and all kinds of (potential) impediments are making successfully reaching the sprint goal harder and harder, the danger of losing transparency always pops up.

Here are three practical tips: Continue reading

Tasty Test Tip: Matching generic typed classes in Mockito

Say you have a arbitrary class under test, which is dependent on a class DataProcessor which has a method with the following signature:

you might want to stub it with Mockito 1.9.5 in the following way to match the generic typed class:

However running this, gives the following error:

This is caused by the generic typed MulitvaluedMap.

Solution:

Run the test and it will pass (these lines at least :-)!

Original Post

Mock a superclass method with Mockito

Say you want to test a method from class which extends some kind of superclass. Sometimes you can be dependent on code in the superclass, which is undesirable in a test.

Now actually, the first thing you should consider is to refactor your code, because it’s violating the Single Responsibility design principle:
there is more than one reason why your class is subject to change. Another advice is to favor composition over inheritence. In this way you can mock the code you are collaborating with.

Having said that, sometimes you run into legacy code you just have to work with and aren’t able to refactor due to circumstances. Here’s a trick I found on Stackoverflow to “mock” a superclass method to do nothing with mockito. Continue reading

The Quick & Dirty Fraud

If you have a car, then every once in a while, you probably have your vehicle checked to see if it’s still up to safety and environmental standards.

So you take your car to the garage and have it checked. Now, the garage will do some tests and eventually you’ll get a nice paper showing what kind of maintenance they have done.

Nowadays, cars are complex, computerized machines. (The days of dad lying under the car to do some fixing with some elemental tools are all but gone.) This means that as a customer, you will have to rely on the professional capabilities and integrity of the garage. You’ll have to trust that if the garage says the car is fixed and okay, it really is fixed and okay.

Now imagine that you went to the garage, received the paper that your car is okay, go on the road, and your car breaks down. What would be your reaction? You’d probably hold the garage responsible for this, as they are the experts and you paid them to do a good job. What would your reaction be if they told you that they didn’t have time to correctly solve your cars problems and did a ‘quick fix’, without them telling you?

In software development I frequently come across similar situations. Companies hire in IT solution providers, to help them solve their IT related problems and deliver high quality solutions for their business. Now software products and projects tend to be very complex and therefore, customers will, one way or another, have to rely on the professional capabilities and integrity of the solutions provider (or the solutions provider, checking the solutions provider).

How then would we label deliberate quick ‘n dirty fixes by developers, just to get the project ‘done’, leaving the customer with piles of technical debt?

It is the responsibility of solutions providers and professional developers, to point out the consequences of quick ‘n dirt fixes. A good solutions provider therefore will, out of professional honor and integrity, have the courage to point out the severe consequences and even refuse quick ‘n dirty fixes, knowing that in the end, low quality won’t pay off.

Quality isn’t negotiable and long after the ‘quick’ has been forgotten, the ‘dirty’ will probably still be there.

Original article

The Lean-Agile Connection

Most people working in professional IT-driven companies, have heard about Agile, most people in professional companies have heard about Lean. Those who are interested in the subject, have found out that these two very popular phrases are actually closely related. So what is the relation between lean and agile? I’ll try to briefly answer this question and will start with a little history.
Continue reading