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

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

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.

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...

Introduction

“Almost all quality improvement comes via simplification of design, manufacturing... layout, processes, and procedures.” - Tom Peters

As I was tinkering around with Erlang/OTP and some other stuff, I suddenly experienced yet another "aha-erlebnis": there is a huge difference between something that is simple and something that is easy, but a lot of people tend to miss this rather important distinction.

More...

All things are difficult before they are easy - Thomas Fuller

After spending quite some time trying to get an erlang/nitrogen instance running in windows, I finally managed to do it, and it turns out to be really simple once you know how to do it.

In fact, it is so simple, one can explain it in a single tweet:

Windows Erlang/Nitrogen in a tweet: install erlang.org/download/otp_w… in "c:\program files\erl7.5.7", unzip ….nitrogenproject.com.s3.amazonaws.com/win/nitrogen-2… & run start.cmd

— Tom * suǝssuɐſ (@ToJans) September 14, 2012

Conclusion

When considering how simple it is, and looking back at my live blog post, my actions look a bit ridiculous, but not all is lost, as my discovery process somewhat helped me to get more acquainted with the whole Erlang story...

Note

This is an experiment where I try "live blogging": I blog as I get along further in the process... Feel free to comment/tweet during the process...

Trying a new concept: "Live blogging: getting started with Erlang and Nitrogen" - feel free to comment during the post corebvba.be/blog/post/Live…

— Tom * suǝssuɐſ (@ToJans) September 13, 2012

Introduction

As I had yet another idea for a startup, I fired up Visual Studio and started implementing a small demo...

Flexing my idea muscle; trying to build a POC for another startup idea #startup10 #ElliottWave twitter.com/ToJans/status/…

— Tom * suǝssuɐſ (@ToJans) September 6, 2012

However, the main feature that would elevate my example requires a lot of interaction, and quite frankly, interaction is a pain in web apps IMO, as there is still a mental shift between frontend and backend. For this particular thing I needed the distance to be as small as possible, so I started searching and found Erlang...

One more last video before I go to bed vimeo.com/8258045 #erlang #nitrogen #riak

— Tom * suǝssuɐſ (@ToJans) September 12, 2012

I will not go into the details why this looks like a perfect match, because I would like to build an MVP first, but I can tell you that it resembles the bee's knees at this current moment to me... So how do I get started? This is a walkthrough where I will post my progress... This post will evolve as I manage to get further....

More...