Introduction

Spawnfest is a programming contest for the Erlang and associated languages. From the description:

SpawnFest is an annual 48 hour online software development contest in which teams from around the world get exactly one weekend to create the best BEAM-based applications they can.

My first participation in the contest was in 2017 (December 9-10). At the time, I used the weekend to kick start the espace project. This was an application that I had been intending to develop for a very long time. Following the contest, I continued developing and improving the application. The project is currently hosted on my GitHub account.

For the following year, 2018 (Nov. 24-25), I attempted the same plan for another project idea on my list, wfnet. But unfortunately, I was unable to spend any time on the project during the Saturday. With only the Sunday available to me, I didn’t have enough time to produce anything presentable, so I aborted my attempt.

Fast forward to 2023, I decided to have another attempt at the wfnet project. During the past five years I’ve had fresh ideas about how to go about implementing it. So, I was effectively starting the implementation from scratch.

At some point I will write a separate technical article about wfnet. In the meantime here is a short summary of the project:

wfnet provides a configuration based workflow enactment engine within an Erlang application.

Here, a workflow is an arrangement of tasks (activities) where each task is only activated when, depending on the task type, one or all of its predecessor(s) have [successfully] terminated.

The concept, and implementation, of workflows here follows those described on the Workflow patterns web site, more specifically the Basic Control Flow Patterns.

Below is an account of the weekend activities. But, since I left the writing of the article too late, and I didn’t keep a detailed, in fact any, diary of activities during the weekend, some of the recollections that follow are going to be vague and blurry :-(

Preparation

Before the start of the contest, [I thought] I had a fair idea of the overall architecture of the application, and I would have preferred to have experimented with one or two alternative designs. However, in order to comply with the rules of the contest, no code should be produced, and none was!

This created a challenging situation where I would have wanted to experiment with some implementation patterns, but I couldn’t do so without breaking the rules. So, as it had been the case with the previous years, I found myself experimenting with some design choices during the early part of the weekend.

With hindsight, I could have started with some experimental code before the contest. However, anything carried over to the submitted project would need to be clearly marked as pre-contest code, which can be achieved by attaching a tag to the last pre-contest git commit.

The start

For me, the contest started at 1am on Saturday, 00:00 UTC. Not being as energetic as my younger self, I decided not to start the weekend with an all-nighter.

I carried out some basic house keeping tasks, before retiring to bed at 2am-ish:

The empty repo on GitHub had already been created by the organisers.
Created the local repo and the corresponding remote branch.
Generated the basic set of skeleton files, rebar3 new ...
Added some basic text to the README file.
Updated the local repo and pushed it to GitHub.

Saturday October 28

I started at about 8:30 in the morning and worked through the day, stopping for the usual things such as cooking, eating and going for a walk, as well as making [almost endless] cups of coffee and tea ;-)

The initial coding activity included a couple of throwaway modules.

The original intention was to create the simplest workflow engine possible, with minimal feature set and without any of the usual OTP behaviours, basically a lightweight server. I would then move on to an additional more elaborate engine, i.e. gen_server+supervisor, based on the OTP Design Principles. Both designs have their own merits and use cases.

The justification for the simple engine is to cater for very short-lived workflows where the start up and shutdown of the supervisor/server processes would be relatively long compared to the entire workflow run. This is similar to the situations where, for example, we may maintain temporary key/value data in maps instead of an ETS table, or in an ETS table instead of opting for a full blown database server.

During the day I wasn’t happy with the way the simple engine was progressing, so I switched to experimenting with the gen_server based solution. Sometimes creating a simple and effective solution takes more effort than a more complex one, especially when the complex solution already has a stable foundation in place that is ready to be taken advantage of.

In the evening I went for a long walk, had dinner, then continued with more coding!

This was the last weekend of October, so, as is usual for UK and Europe, the clocks went back by one hour. I went to bed sometime before 2am, but I’m not sure if it was on the old time or the new one :-()

By the way, for anyone who considers 2am as late, they should have seen me in 2017, when I was sitting in bed with my laptop, well past 3am, and trying to get my head around the ETS matchspec expressions :-(

Sunday October 29

After a good night’s rest I was ready for some more coding in the morning.

Originally, I was going to submit both engine types and throughout the morning I continued going back and forth between the simple engine and the gen_server one.

It soon became clear that there was only enough time for one type, so I eventually settled for the gen_server. Simply because it already comes with the API for the workflow clients and the facilities for maintaining the application state.

Committing to the gen_server variant enabled me to focus better. It was then a matter of scribbling on the whiteboard and transcribing the pseudo code from the whiteboard into the emacs editor. Eventually, I got a working application – for some definition of working ;-)

During the last hour of the contest I switched my efforts to updating the documentation and the README file. Judging by the traffic on the Slack channel, the other contestants were also busy updating their project documentation!

The last commit was at 23:41 UTC. This was followed by a nice cool beer from the fridge, feet up, and watched the highlights of the F1 Mexico GP :-)

Post-Spawnfest

The wfnet project now has a new home in my personal repository.

For me, the Spawnfest weekend is an opportunity to kick start an idea that may have been sitting on a todo list for a while. The pressure of the deadline is a good incentive for putting all the nonessential distractions on hold for the duration of the weekend. It has helped me produce a good enough baseline application for further incremental development later, as and when time permits.

For anyone who has a project idea in need of a kick start, the Spawnfest weekend is a good opportunity to help them along. Of course, assuming the project is based on Erlang or one of the BEAM related languages.

The results of the contest are out. I was hoping to publish this article before the announcement, then follow it up with an update. My submission has been awarded the second place in the correctness category. This is a very pleasant surprise :-) I have also received very helpful comments from the judges, as has been the case on my previous attempts. When I get a chance I’ll post a short wrap up article.

Acknowledgements

It is very important to acknowledge the efforts of the organisers, Paulo F. Oliveira and Bryan Paxton, and the judges who have volunteered their time with no rewards, financial or otherwise, in return. They have done this on top of their normal daily work and family activity.

Just as importantly, the sponsors have always played a big role in supporting the contest. The first edition of the contest was in 2011 and, with the exception of 2013-2016, it has run every year since then. Throughout, there has always been support from the community in the form of sponsorship. You can see the list of the sponsors for each edition by following the relevant links for the corresponding years on the “about” page of the Spawnfest web site.