Posted by Jan Vermeir in the early evening: November 12th, 2011
Getting the Java out of your Scala, part 2
I’m still trying to get rid of old habits, to shake of my winter hide, so to speak, and create some real Scala in stead of ScaVa (i.e. Java with a Scala syntax). If you’re interested you can bear witness to my struggle on GitHub (ShoppingList on GitHub). This story came about because I asked some colleagues for help. We ended up rewriting loops in several ways.
What I’ll show you is some alternatives to classic loops over collections.
(more…)
Posted by Jan Vermeir in the early evening: September 13th, 2011
With everybody going mobile, we could not stay behind. This meant we had to create an Android application, because we (Bram Neijt, Arno den Hond and your chronicler) do not own one of them fancy iPhones.
Also, Android is way cooler.
(more…)
Posted by Jan Vermeir mid-afternoon: April 3rd, 2011
To get some grip on the configuration of the Weblogic domains and servers at my current client, I created a tool that reads domain config files and translates them in a graph. I decided to solve this problem in Scala, mainly because I read about its powerful native XML parsing capabilities. Parsing XML turned out to be a total no-brainer, but I managed to learn something about how to solve problems the Scala way, so this is a story about Scala rather than parsing XML in Scala.
(more…)
Posted by Jan Vermeir at around evening time: February 8th, 2011
We’ve been busy for a couple of weeks now refactoring a fairly complex code base of just under 500 classes. None of us really knew all the details about this part of the system, but we didn’t let that stop us of course. After some regrouping/-shuffling/-factoring/*ing, the whole thing built OK and all unit tests were green again. All that was left to do was fix the Fitnesse tests. I remember thinking this should be easy since we had all those green unit test.
Evil laughter sounds.
(more…)
Posted by Jan Vermeir in the early morning: November 16th, 2010
Software vendors have hijacked a potentially useful concept by pushing heavy weight complex tools like ESBs. The goal of this article is to find out which of those tools we really need so we can stay away from unnecessary complexity. I’ll do that by describing the infrastructure services we really need and how these services can be implemented in the simplest possible way.
Software depends on other software because we don’t want to build systems from scratch. Each piece of software your code depends on may:
- change the address or name by which it is known
- change the technology it is implemented in
- be unavailable when you need it
- live on a different server or in the same process
- be connected through infrastructure that cannot be trusted
- speak a different language
(more…)
Posted by Jan Vermeir in the early evening: October 7th, 2010
Most IT careers start with a programming job: you write code in one of the popular programming languages as part of a team. As your experience grows you start to get bored with software: you’ve been working with more or less the same technology and tool set for a couple of years and you need something new to keep yourself going. That’s the point where you have several options like becoming a project manager, coach, analyst or middleware expert. This story is about another option: becoming an architect.
(more…)
Posted by Jan Vermeir mid-afternoon: July 22nd, 2010
In an attempt to better understand the ideas behind ‘Life Beyond Distributed Transactions, an Apostate’s Opion.’ by Pat Helland, I’m going to try to explain how the concept would work out for a time-honored example: the good old transfer of money from one account to the other, the archetype of all distributed transactions because we want to make absolutely sure we don’t lose money.
(more…)
Posted by Jan Vermeir around lunchtime: April 27th, 2010
Knowledge of the past allows us to predict the future, at least, for certain areas of human enterprise. I’m convinced that software development is one such area. The theme of this blog is ‘to measure = to know and to know = to predict’, so by the transitivity of equals we can state ‘to measure = to predict’.
But what should we measure? I suggest you at least measure the following and will try to explain why below: trends in burn down, trends in bugs, trends in test coverage and trends in complexity.
Posted by Jan Vermeir in the early morning: April 27th, 2010
Development teams or even development organizations, are not always the well balanced, smooth operations we’d like them to be. In our software quality audit practice we have had the privilege to investigate many different types of organizations and found many different ways quality and productivity can suffer from a problem known as the Prima Donna Syndrome: a single individual exercises a disproportionate influence on the team causing problems like stagnation and unnecessary complexity.
(more…)
Posted by Jan Vermeir in the late afternoon: October 21st, 2009
In my efforts to teach myself Scala, I tried solving a problem I’ve tackled in various languages, 6510 assembly code (didn’t get far…), pl/sql, Java (with and without Drools) and Groovy among them. Usually I get bogged down in some detail of the language so I never get to reap any actual benefits of my efforts in daily life. The plus side of this never ending task is that by now I don’t have to spend effort on defining a problem but instead can start coding right away.
So this story is about how to parse text in Scala and is part of THE software package that will automagically generate a menu for a week and the shopping list for that menu together with whatever else my family will need that week and send it to www.albert.nl and have the groceries delivered to my door.
(more…)