Introduction

The last two days of August there is a 2 day Erlang course in Amsterdam. One of the most incredible things, is that there is a low cost offer sponsored by Spil games that reduces the price to 55€ for both days; talk about a steal!!

First things first: why should you follow a camp on Erlang?

People who know me in person know that I am an avid fan of Erlang, even though I have only done some very small experiments with it.

Even if you are not planning on developing something in Erlang, you should at least try to grasp the basic concepts!!

You want to know why? Here is why:

Opinionated - but proven - architecture

Today's world of always connected web-apps, is much more similar to the telecom world then the web-apps from a few decades ago. People are currently continuously connected, and they expect almost-immediate responses.

As you can imagine, designing a proper software architecture for this takes a lot of time, but this is one of the parts where Erlang excels:

All the time you spend on building infrastructure for a well-designed application can be simply skipped. Erlang offers a very opinionated but proven tech stack that implements this for you out of the box, including things like messaging, local and distributed persistent storage, supervisor processes, ...

Next to this it also does not care on which machine a process runs;there is no extra implementation cost to run your process on multiple machines. (cloud anyone?)

The actor model

Actors are the "mode du jour" when it comes down to development buzzwords, but they happen to work pretty good in distributed environments. The whole Erlang infrastructure is built around processes communicating to each other with mailboxes per process, and they to offer selective receives and timeouts in a pretty straightforward way.

Because the VM is custom built for this platform, it has some extra things other VM's do not have, like soft-realtime processing and per-process garbage collection. The VM is optimized for the actor model.

Productivity

Erlang has a bit of a quirky syntax due to it's origins (Prolog), so it takes some getting used to the difference between ending a line with a semicolon, a comma or a dot. While this might seem odd, it comes naturally after a while, but it takes some persistence.

Next to this, Erlang has pattern matching (a little bit comparable to polymorphism in OO languages, but it even goes way further then that).

They even have something like generics using behavior.

More...

Introduction: what & how?

"Implementing Domain Driven Design" is a book written by Vaughn Vernon, and you can consider it a practical guide to the blue book - a lot of people consider the blue book to be used as a reference, but it takes some persistence to read it -. Vaughn tried to solve exactly that problem with his book...

"implementing domain driven design" by @vaughnvernon has arrived #YesYesYes #DDD #IDDD twitter.com/ToJans/status/…

— Tom Janssens (@ToJans) 13 februari 2013

A little while ago, Vaughn Vernon was tweeting about how had given a free course about his book "Implementing domain driven design" while visiting Bogota, Columbia. This course was given for free to help start-ups there.

My free one-day #IDDD Tutorial will be held in #Bogota #Colombia from 8:30am-6pm Monday Oct 8 at @hubbog Calle 98 # 18-71 Second Floor.

— Vaughn Vernon (@VaughnVernon) 5 oktober 2012

In the next few hours after this tweet, an idea emerged on twitter about a concept called the IDDDtour, where Vaughn would be teaching his book to larger classes and doing a tour through Europe, but at a fraction of the cost. As I am somebody who is more of a head first kind of guy, I decided to take ownership and figure out a way to make this a real thing...

More...

Introduction

As I was wide awake at 5am this morning, and it was the end of the month, I decided to do some invoicing (while the Mrs. & kids are still asleep ;) ).

Because I had some time left, I decided to take a look at my stats... This invoice app was built about 10 years ago in MsAccess in a few days, and has not really changed a lot since then (except for some adjustments to allow certain billing specific extents; things like non-EU or VAT-exclusive stuff, as well as some automated payment reminder letters).

Anyway, that is not the subject of this post, but as I was browsing some of my available graphs - it has been a few months since I did that - , I decided to write a small blog post about my findings.

I will start of with what most of you will probably consider quite a controversial thing; I will just post a *slightly censored* graph of my invoices cumul over my years as a company owner. ..

LOL, that looks odd...

There are a few things you might notice here:

• That is not a regular income at all.
• When I do have a good year, the line looks really steep (f.e. look at the yellow line from this year).
• Looks like I have a good year every n years.
• It looks like the steepness of your good years is increasing

About 3 days ago my internet connection with telenet started being really slow, and gave me corrupted downloads if files were larger then a few megabytes. Every file I tried to download gave me corrupt files.

As this problem appeared on 4 different PC's simultaneously, I knew the problem was not related to a specific PC configuration.

As one of my PC's was wired (through a router), and that one was not working either, I decided to shortcut the router, and connect directly to the telenet router (without my own router), and that seemed to work.

So the problem had to be located within my router. After checking the logs and upgrading the firmware, the issue still remained, so I started looking around on the net.

After some browsing I found the cause of my connection problems; apparently telenet lowered the MTU? UPDATE: lowering my MTU might work...

What's MTU?

This would bring us down to networking, and layer 2, the data layer, but I assume wikipedia can explain it way better (here).

What it comes down to is that large packages on the network fail, so you need to find out how large your packages can be when you send them over the network.

How can you do this?

First of all you have to find out your MTU setting of your router; it's probably at 1500 for cable or 1492 for DSL. Next you have to find the size that works with your provider. For now I settled on a size of 1200.

You can find out this size by doing the following (min is at 500-something AFAIK):

start a command window and start pinging with a packet that can not be separated (IPv4 only, BTW):

You get the picture I presume.

After finding the matching packet size, you should set the MTU in your router to your value; problem solved...

Update: 

While my big downloads now are fixed, @dvaneven mentioned his internet with the same provider still worked on MTU 1500, so I think I probably might need to replace my router.

@tojans @telenet Why would they lower the MTU?

— Dave Van Even (@dvaneven) 17 maart 2013

For now my workaround works, but I will buy another router ASAP.

Update 2:

I installed another router... problem solved !!

Introduction

There has been a lot of buzz lately about a post of Uncle Bob Martin, who claims that skipping Test-driven design is the worst mistake you can make when in a startup. This generated a lot of yay-and-nays on the twitter sphere, with mostly black and white opinions. I think they might all be right, but miss one important distinction: you always need to formalize what you are working on...

"So what" - Miles Davis

In my opinion, you need something to drive your behavior of your app, or as you put it in the context of startups, you need something to drive your search for a market fit. So while TDD might provide you "better" code in the end, it is not the code that matters, it is the behavior of the code that is all important. TDD for a startup should help you to reason about that behavior, i.e. what exactly are you trying to achieve.

Defining in an explicit way what (and even why) you are going to do something before you do it, allows you to:

• focus on your task
• define scope
• reason about it in a strategic way

If you are able to reason about what you are about to do in another way, please feel free. I can think of at least 5 ways to define what you are doing:

• An explicit analysis document
• Literate programming
• TDD
• BDD (behavior- and business-)
• Interface-driven design, the top down approach (although this is probably one of the lesser approaches)
• ...

Conclusion

So in the end, what it all comes down to, is that you need a formal/explicit spec about what you are working on, whether that is a design doc, some unit tests or something else, does not really mather; just find out whatever fits your methods best.

Dear Mr. Murphy,

Pssssssssssssssssssssssssssshhhhhhhhhhhhhhhhhhhhhhhhtt !!!!

... That was exactly the sound I was hearing when I got up early this Saturday morning (6.30AM'ish).

In the last months I have been billing on average about 9 to 10 hours per day for my customer, and those hours do not include my 30 to 60 minute lunchbreaks and my 3 to 5 hours spent on commuting when I decide not to sleep over, so you can imagine my time for doing things on the side is rather scarse at this moment.

During the weekends, I am usually at one/both of my son's soccer matches, or getting back on track with my family and some friends, which I do not see during the week.

I still have 2 books to finish and review/write a blog post about it, and have not been able to do this just yet.

Today is Saturday, and I need to be at my parent's by 8.00AM where we meetup to disassemble, transport and temporarily store my brother's new kitchen they will use after their renovation. This will probably take the whole day, so I decided to get up at 6.30AM, because I wanted to answer some mails today. (Knowing myself, I will probably not be any the mood for this tonight anyway, as we will probably have a night out with the "kitchen disassembling crew".)

So I got up at 6.30AM, ready to get started on these mails, as I heard a slightly disturbing sound... "PSSSSSSSSSSSSSSSSSSSSSSSSSSHHHHHHHHHHHHT"; a continuous hiss.

As we do not have any gas plumbing in the house, I was not exactly afraid of explosions, but it was slightly disturbing nevertheless, so I went searching for the source of the sound.

As I arrived in the cellar - all in my nightwear, for people with a lot of imagination -, I noticed our pression vessel from our rain water pump contained a very small dot of rust where water was streaming out at high pressure.

So I opened up some faucets to release the pressure, and started mobbing away, as we also store our heating pellets in our cellar - luckily I did not put them directly at the floor, otherwise the first few bags would have been ruined as well.

So, instead of answering my emails, I decided to get my priorities straight, and take the explicit time to thank you and send you my regards, Mr. Murphy, as you apparently also went the extra mile to surprise me with this great morning gift ....

Kind regards

Tom

Your Humble Servant

Introduction

Sometimes you get lucky, and find a way where you can truely do the things you like in work... But why does luck always seem to be distributed unevenly, and does it always land with the same people...

Here is a message for you: it does not! You can get lucky once by accident, but getting lucky multiple times seems to be quite impossible (not considering statistical anomylies).

So I decided to write a post with some lessons learned from my personal experience...

Be more receptive to luck

Let us begin with the first quote

“If opportunity doesn't knock, build a door” - Milton Berle

Simple, is it not; the reason some people are more lucky then others, is because they are willing to see the opportunities....

I will give you 3 more quotes to tickle your motivation on changing life, work, and all other things related to carbon-based lifeforms:

“The journey of a thousand miles begins with one step.”
"If you do not change direction, you may end up where you are heading."
“When I let go of what I am, I become what I might be”

- Lao Tzu

Here is the thing: people always want something, but are afraid to get out of their current comfort zone. If you really want it: stop making excuses and just do it! Ask yourself: what is the worst thing that could happen? Usually things are not that bad, and you can almost always find a plan B...

Millions of opportunities might fly by, but people tend to always find an excuse and somehow assume the worst-case scenario will happen so they talk themselves out of it...

This brings us to the next part... More...

Introduction

As one does typically develop features in parallel, and some features can not be released while others can, a lot of software teams seem to have problems with their source control.

In this post I will describe Simplified Feature Branching usable with git or any other DVCS.

This model is not rocket science, and is a further simplification of Adam Dymitruk's post on feature branching.

It assumes you use proper release cycles and versioning during the software development lifecycle.

Whenever I mention "feature" in this post, I actually mean "feature" or "bugfix", but I am a lazy b*d.

The main idea: simplification

Make everything as simple as possible, but not simpler - Albert Einstein

Whenever things start to get complicated, we should attempt to simplify them by breaking it up into smaller parts. This is exactly what Simplified Feature Branching does. We make the distinction between branching and integration.

More...

Introduction

During one of my more recent interviews I got an assesment from two different persons. While I still have no idea about the definitive outcome, the different types of questions they both asked triggered me to think about what kind of personality type they would be, so I started wondering how personality types are related to development....

First things first: MBTI

Before we can determine the effect of your personality on your development, we will start by defining MBTI, so let us begin with the wikipedia definition:

The Myers-Briggs Type Indicator (MBTI) assessment is a psychometric questionnaire designed to measure psychological preferences in how people perceive the world and make decisions.

They do this by categorizing your personality in four dimensions; your gradation in every dimension is not a boolean, but rather a range (i.e. -1 to +1).

I will describe each of the four dimensions in detail, and explain how they impact your development:

#1 Attitude: "Extraversion" versus "Intraversion" (E vs I)

Attitude is about the way evolve an idea and get inspired: some get inspired by doing and experimenting, while others get inspired by thinking about things.

• Development by people with high "Extraversion" is driven by
  • experimenting with code
  • evolving ideas in small incremental steps by talking with other people
  • doing things right
• Development by people with high "Intraversion" is driven by
  • an internal thought process
  • thinking ideas through before talking about it with other people
  • doing the right thing

On a sidenote, "extraversion" is not a typo; it is the way you spell this word in MBTI terms.

More...

Note: I would like to thank @gbarrs for reviewing my blog post almost instantly, and also the offer of @GraemeF, @MarkRendle, @swaggerdmangene and @moldyseaswimmer to be a reviewer. Without them, there would be a lot more Dunglish in this post...

Why I like my job.

I have been hooked into computers ever since I wrote my first few lines of Basic on my mothers' brand new TRS-80 Model 3 with 64Kb of ram and 2 - yes 2 !!! - diskdrives of a whopping 178Kb. (Actually, I did not write the code, but I copied it character by character from a textbook that might have looked like this, but in my defense, I was about 7 years old).

The first program probably looked like this:

10 PRINT "HI, WHAT IS YOUR NAME?"

20 INPUT N$

30 PRINT "HELLO, ",N$

Exciting, is it not? In the five years that followed, I learned almost every in and out of this machine, where to peek and poke in memory, how to set pixels on the screen (monochrome, 128x48 resolution, imagine that), which ASCII codes to send to my dot matrix printer to switch control modes, ...

When I was about twelve years old, I had written a drawing application, complete with circles, boxes, Bresenham lines, and even the possibility to print the graphics on the (very noisy) dot matrix printer (remember those printers which had to print on chained paper?).

More...