At the most recent AWS Re:invent, Amazon announced support for custom runtimes on AWS Lambda.

AWS has support for quite a few languages out of the box. NodeJS being the fastest, but not always the most readable one. You can edit Python from the AWS Console, while for Java, C# and Go you’ll have to upload binaries.

The odd thing, in my opinion, is that there are no functional languages in the list of supported languages¹. Although the service name would assume something in the area of functional programming. The working of a function itself is also pretty straightforward: an input events gets processed and an out put event is returned (emitted if you like).

Therefore it seemed a logical step to implement a runtime for a functional programming language. My language of choice is Elixir, a very readable functional programming language that runs on the BEAM, the Erlang VM.
Read more →

On many occasions when we come at a customer, we’re told the development team is doing TDD. Often, though, a team is writing unit tests, but it’s not doing TDD.

This is an important distinction. Unit tests are useful things. Unit testing though says nothing about how to create useful tests that can live alongside your code. On the other hand TDD is an essential practice for improving the design of your code. These are very different things.

Read more →

On the 15th and 16th of April CITCON Europe took place in Cluj-Napoca (Transylvania). CITCON is an open spaces conference. The agenda is made up by the people attending the conference. Because of this there are always a couple of nice takeaways.

This year Ivan Moore (@ivanrmoore) made a claim that you can not do CI without using monorepos. A monorepo is simply one repository where all source code ends up. This is contrary to a setup with (for example) Git source control where you have a single repository per module. The idea of having a single (big) repository with all code seems strange. After some thorough discussion the merits of monorepos were clear to me.

Read more →

We’re running a few (virtual) servers, nothing special. It is rather easy to turn those machines into snowflakes. To counter this we introduced Salt. Salt does a nice job in deploying software to servers and upgrading them when run regularly. But how do we counter issues when changing the Salt configuration itself? The solution is simple: Test!
Read more →

FitNesse has been around for a while. The tool has been created by Uncle Bob back in 2001. It’s centered around the idea of collaboration. Collaboration within a (software) engineering team and with your non-programmer stakeholders. FitNesse tries to achieve that by making it easy for the non-programmers to participate in the writing of specifications, examples and acceptance criteria. It can be launched as a wiki web server, which makes it accessible to basically everyone with a web browser.

Read more →

For a few years already, IntelliJ IDEA has been my IDE of choice. Recently I dove into the world of plugin development for IntelliJ IDEA and was unhappily surprised. Plugin development all relies on IDE features. It looked hard to create a build script to do the actual plugin compilation and packaging from a build script. The JetBrains folks simply have not catered for that. Unless you’re using TeamCity as your CI tool, you’re out of luck.

Read more →

On the 19th and 20th of September CITCON (pronounced “kit-con”) took place in Zagreb, Croatia. CITCON is dedicated to continuous integration and testing. It brings together some of the most interesting people of the European testing and continuous integration community. These people also determine the topics of the conference.

They can do this because CITCON is an Open Space conference. If you’re not familiar with the concept of Open Space, check out Wikipedia. On Friday evening, attendees can pitch their proposals. Through dot voting and (constant) shuffling of the schedule, the attendees create their conference program.

In this post we’ll wrap up a few topics that were discussed.

Read more →

In a software project dependency management is default practice. So what about dependency management in your FitNesse acceptance test suite?

In my previous post I explained how you can make FitNesse and Maven work together. If you’re not into Maven, but want to handle (Java) project dependencies in a convenient way, you’re probably using Ivy. Ivy is used by Gradle and SBT under the hood, but not packages with Ant by default. It’s a neat tool, it does dependency management very well. It is compatible with Maven’s POM files: it can read them as well as write them. In this post I’ll use Ant as a basis.

Read more →

As a software developer you’re using dependency management to handle dependencies on your project; include frameworks and libraries to your project. If you’re a Java developer you’re probably using Maven. When you’re not using Maven you’re probably using one of the more versatile build tools like Ant or Gradle, both can use Ivy for dependency management. Either way, you’re not putting binaries (jars) in your source control repository.

How about your FitNesse acceptance suite? Since it’s all software and all belongs to the project, you probably want to have the same standards when executing the acceptance test suite. It’s really not that different from executing your regular (unit) tests.

In this blog I’ll explain how to launch a FitNesse suite from Maven. I’ll also elaborate on how to get FitNesse to recognize the dependencies required to launch the application. A future post will be dedicated to the FitNesse/Ivy combo.

Read more →

I’ve found many people to care for a high unit test coverage. It tells you something about how well your code is tested. Or does it?

Unit tests typically test the smallest piece of code. It is an excellent strategy to write your tests in conjunction with the production code. The tests help you shape the interfaces and help explore the problem domain.

Big question is: does the business/product owner care? What do those tests tell him (or her) about the actual functionality delivered? Fairly little really, if any at all. This boils down to the next question: why care about unit test coverage then?

Read more →