In programming, we often need to swap (exchange) the contents of two variables, say x and y. This is normally achieved using a temporary variable, say t, as follows:

t := x
x := y
y := t

The XOR swap technique achieves the above for binary values without using a third variable, here \(\oplus\) is the XOR operation:

• (1) \(x := x \oplus y\)
• (2) \(y := x \oplus y\)
• (3) \(x := x \oplus y\)

I first came across the algorithm (technique) in the mid 80s, and set about convincing myself how and why it works. My first attempt was to use a truth table, shown below. The second was to use simple algebra, which is described in the Wikipedia article, so I won’t cover it here. Many years later I discovered that the technique can be explained graphically using a triangle.

The Wikipedia page for XOR swap is very extensive and covers a lot of ground. Here, I will cover a couple of additional explanations that are not included on the Wikipedia page.

Using a truth table

Interestingly, the Wikipedia page, while extensive, does not include an explanation using a truth table, so here’s my version:

In the above, the columns \(x\) and \(y\) represent the initial values of the two variables, and columns (1), (2) and (3) represent the values of the left hand sides of the three assignments after each of the respective operations. So, column (2) shows the final value of \(y\), which matches the original column for \(x\), and, column (3) shows the final value of \(x\), which matches the original column for \(y\).

The truth table above applies to single bit values, however, since the application of the XOR operation to larger integers is performed bit-wise, the XOR-swap is valid for integers of any size. Basically, the same truth table applies to each pair of bits independently.

The triangle

The XOR operation can be visualized as a triangle with the two operands at two of the vertices and their exclusive-or at the third. That is, if \(A\) and \(B\) are two arbitrary binary values at two of the vertices, then \((A \oplus B)\) will be at the third vertex.

The most interesting, and useful, property of XOR is that from the values at any two vertices we can derive the third by applying the XOR operation to the two values at those vertices. So,

\(A = B \oplus (A \oplus B)\), and

\(B = A \oplus (A \oplus B)\).

Now, let’s say \(x\) and \(y\) have the values \(A\) and \(B\), respectively, then the three assignments will move the two variables around the triangle one vertex at a time, which will result in \(x\) and \(y\) containing the new values \(B\) and \(A\), respectively.

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.

A few weeks ago I came across an article on the BBC news web site. It describes the Christmas challenge set by the UK Government Communications Headquarters (GCHQ) during the run up to Christmas 2023. The challenge was for school children aged 11-18 years.

The complete details can be found on the GCHQ’s challenge page.

The fourth puzzle (of seven) caught my eye, since it involves numbers. So I thought I’ll have a go, even though I don’t fit the age range ;-)

The challenge

Here is the fourth puzzle:

Where, Each letter represents a different digit. We are asked to find a one-word answer which can follow Christmas.

An example solution

What follows is the tidied up version of my scribbles on the whiteboard. Of course, there are other ways of solving the puzzle.

From the second equation we can see that \(2 \times TI = RA\), so \(RA\) is an even number, and hence \(A \in \{ 0,2,4,6,8 \}\)

The third equation can be rewritten as follows:

rearranging the above, with each of the pairs of \(O\)s and \(I\)s cancelling themselves, we end up with the following equation:

so, \(E=0\), and hence \(A\) is reduced to the set \(\{2,4,6,8\}\).

Now, back to the first equation, the one that I could have started with!

So, \(MAA\) is a 3-digit square number with repeated digits on the right. This restricts the \(MI\) to the range \([10 .. 31]\), so we have four possibilities: 100, 144, 400 and 900.

We can exclude \(100\), \(400\) and \(900\), since they would imply that \(A=0\), but \(0\) already belongs to \(E\).

This leaves us with \(MI=12\) and \(MAA=144\).

We now have \(E=0\), \(M=1\), \(I=2\) and \(A=4\).

The second equation can now be written as \(T2+T2=R4\), so \(2T=R\), making \(R\) an even number, and hence \(R\in\{6,8\}\). This leads to \(T\in\{3,4\}\), but \(4\) belongs to \(A\), and so \(T=3\), and \(R=6\).

Now, \(RE=60\), which leads to the answer as follows:

So, TREE is the one-word answer which can follow Christmas.

Carrying on …

The puzzle is solved, but I’m on a roll, so let’s solve for the rest of the letters.

So far we have \(E=0\), \(M=1\), \(I=2\), \(T=3\), \(A=4\) and \(R=6\).

From the simplified version of the third equation:

From the list of unassigned digits, \(D,S \in \{ 5, 7, 8, 9 \}\), and the only pair of digits satisfying the above equation are \(5\) and \(9\), i.e.

But, what about \(O\)? Well, we can start with \(O\in\{7,8\}\). However, since \(O\) is only mentioned in the third equation, in a self-cancelling manner, and with only 9 letters incorporated in the puzzle, we cannot narrow it down any further!

Have a successful and enjoyable 2024 :-)

For some time now GitHub have started requiring account owners to use two factor authentication (2FA) when signing in to the GitHub web site using a browser.

A few weeks ago I received notification from GitHub that I should enable two factor authintication (2FA) for my account. This meant that, in addition to the usual username/password, I will also need a second method of authentication.

The GitHub help page on Configuring two-factor authentication provides various options for configuring the second source of the 2FA authentication. These include installing an app on my phone, use the SMS on my mobile phone, or use a third party authenticator.

I was not keen on installing yet another mobile app on my phone, or rely on the SMS service. While the SMS option works fine most of the time, it does not work if there are roaming issues when away from home! GitHub does not offer the option of email as the second authentication method, which is often offered by others as an alternative for, or in addition to, SMS based authentication.

After searching around, I came across a number of web-based and/or GUI alternatives, such as Authy and KeePassXC.

However, since my first preference in such situations is always a CLI based solution, I searched further and eventually came across the OATH Toolkit, which provides exactly what GitHub requires - Time-based One Time Password (TOTP).

The CLI based solution

The OATH Toolkit can be obtained from the Download page. It is also available as a package on various Linux distros. Once installed, you will have the main command available to you – oathtool.

When enabling the 2FA, the GitHub page will display a QR code that you are expected to scan using your mobile app. As an alternative to the QR code, there is also a setup key link near the QR code that will show a 16 character code. This is a base-32 representation of the secret information needed for the generation of the TOTP specific to your GitHub account. Copy the code and keep it in a very safe place!

When asked by GitHub, use the following command to generate the TOTP:

oathtool -b --totp KEY
123456

This will print a 6 digit number, e.g. 123456, that should be typed in the entry box.

BEWARE: If you are running the above command on a shared host, the KEY will be momentarily visible to others. To be safe, you can ask oathtool to read the KEY from the standard input:

oathtool -b --totp -
KEY
ctrl-D
123456

You will also be asked to download and save the recovery codes, copy these codes and keep them in a safe and secure place! Once you confirm that you have saved the recovery codes, your account will have 2FA enabled.

From now on in addition to the username/password you will also be asked for the 2FA key, which you can generate using the oathtool command above.

Using password-store

For those using the pass command to manage their passwords, there is a companion extension command (pass-otp) that will enable you to keep the GitHub secret key (the 16 character key) in the password store along with your other passwords.

To start using pass-otp, add your GitHub secret key to the password store:

pass otp insert -s --issuer GitHub
Enter secret for this token:
...

This will create a password-store entry and print the PASSWORD-NAME.

To obtain the TOTP during sign-in, use:

pass otp PASSWORD-NAME
123456

and type, or copy-paste, the 6 digit number in the entry box on the GitHub web page.

Or, to have it copied to the clipboard for you, use:

pass otp -c PASSWORD-NAME
Copied OTP code for PASSWORD-NAME to clipboard. Will clear in 45 seconds.

Now, it’s just a matter of pasting the code in the browser entry box.

To read further

In addition to the descriptions on the GitHub help page on Configuring two-factor authentication, you can learn further about the OATH and TOTP from the section under External Resources and Applications on the OATH Toolkit web site. It lists the relevant RFCs describing OATH and TOTP.

Epilogue

I have described above the minimal steps needed to enable 2FA for my own use. This should probably be sufficient for most use cases.

This solution works for me because I access my GitHub account via the browser on my laptop/PC, and never on a phone or tablet. It has worked fine so far :-)

About the Erlang documentation system

The Erlang library has a set of modules, edoc, for extracting the documentation from the module source files and converting them to a set of html files. It was inspired by Javadoc.

For applications that use rebar3 the documentation can be generated easily using the rebar3 edoc command, which produces the entire set of html pages and stores them in the doc/ directory. This is pretty common in most erlang projects. All that one needs to do is to point the web browser to the index page, doc/index.html. While this is simple for those working on the project, it is very tedious for anyone who may want to inspect the documentation without having to download the source code.

Some projects use https://hex.pm/ for packaging and publishing their applications. Hex, in addition to hosting the source code, also caters for publishing the documentation, and provides links for browsing the documentation. These can be found at https://hexdocs.pm/.

This is fine for the versions of the packages that have been published on hex, but not for the latest versions under development, say, on github.

What I wanted to have was the automatic generation of the docs for the latest version of the application, so that anyone curious about the project can inspect the latest docs online.

And this is where github pages comes in.

With a bit of configuration, which involved some initial trial and error activity, I was able to have the module docs auto-generated with every push to the github repo.

The per-repo github pages

Each project repository hosted on github can have its own set of web pages – github pages.

This can be configured using the settings pages. The instructions can be found here: Creating your site.

The above link, as well as https://pages.github.com/, should be sufficient for anyone wishing to have manually maintained web pages. However, for the module docs we need to (re)generate the online pages automatically as and when the source code is modified. For this I needed some additional configuration.

The additional workflow tasks

My additional configuration can be summed up as follows:

1. Logged in to github and followed the link to the repository.
2. From the Settings page followed the Pages link on the left of the page.
3. Under Build and deployment and Source selected Github Actions.
4. Selected the Configure button, this showed an editor with a basic workflow file loaded. This acted as a template, which saved me from having to create one from scratch.
5. The above YAML file, .github/workflow/pages.yml, was saved and then used as the starting point for my own configuration.

The main changes from the default file supplied by github are as follows:

• The source directory for the main github pages is ./gh_pages. This is used as container for any front matter for the module docs. Currently it contains the file index.md, which in turn contains links to the module docs.

• The jekyl pages are generated in a container that is run as user root, while everything else is executed as user runner. I added a task to change the owner of the jekyll generated files in the _site directory to user runner, so that we can drop our own files in the _site directory:

- name: take ownership of the site files
  run: sudo chown -R runner _site

• Two tasks contain the commands to generate the module docs and copy them to the _site directory. I generate two sets of docs, one for the exported (public) functions:

- name: generate the public edoc
  run: rebar3 edoc
- name: copy the doc files
  run: cp -r ./doc ./_site/edoc

and, the other covering ALL the functions, public and private:

- name: generate the full edoc
  run: rebar3 as dev edoc
- name: copy the doc files
  run: cp -r ./doc ./_site/edoc_dev

Once the modified workflow file was pushed to github the web pages were generated automatically. And, from there on each git push kicked off a new edoc run.

For an example see the espace project. The main files of interest are gh_pages/index.md and .github/workflows/pages.yml. The auto-generated web pages can be seen here.

One last addition to the workflow file was to stop yamllint complaining about the on: keyword not being a truthy value. This was fixed by replacing the on: line with

on: # yamllint disable-line rule:truthy

It is not a tutorial on the subject, but rather a list of what I did, and why.

At first the intention was to have a set of simple pages summarising some of my projects. The usual github based address https://fredyouhanaie.github.io was sufficient. However, once I took a closer look at the features provided by github pages and jekyll, it was clear that this combination would also be suitable for publishing blog posts.

The github documentation provides instructions on various scenarios for creating a web site, depending on one’s needs. This article shows one particular path that covers the following personal requirements:

• It should cater for use of plain text for all content, so that they can be version controlled.

• It should allow use of own domain name with https access.

• It should be possible to preview the rendered pages locally before deployment to github.

About github pages and jekyll

• The contents of the web site (github pages) are kept in a git repository that is hosted on github.

• Github uses jekyll to generate the static web pages.

• The static web pages are generated from text files (YAML+markdown) that follow a specific format, see https://jekyllrb.com/docs/front-matter/.

• The html files are generated automatically, through github actions, whenever new changes are pushed to the repository.

Creation and the initial setup of the github pages

This was the first step. It was pretty straightforward. I just followed the instructions here.

After the set up and creation of a simple index.html file, the web site was up and running.

Installing jekyll on a local host (laptop)

jekyll, a ruby based application (a gem), is needed so that we can update and preview the web pages locally. The github docs for installing and configuring jekyll can be found here

I already had ruby installed, so it was just a matter of installing jekyll:

gem install jekyll

I ran the above command as a non-root user (there is no need for root here), this resulted in the files being installed in:

$HOME/.local/share/gem/ruby/3.0.0/gems/jekyll-4.2.2

Rather than adding yet another directory to my $PATH for the jekyll command, I used a symlink as follows:

cd $HOME/.local/bin
ln -sv ../share/gem/ruby/3.0.0/bin/jekyll jekyll

Creation of the basic web pages

Once jekyll was installed, the site scaffold was created within the local repo of the github pages:

jekyll new --skip-bundle .

Next, the Gemfile needed customization, as per the github docs, which consisted of the following two changes:

• comment out the gem "jekyll" ... line
• uncomment the gem "github-pages" line, and add the version

Once updated, all the necessary packages were installed by running the bundler, the ruby package/dependency manager:

bundle config set --local path 'vendor/bundle'
bundle install

The bundle config ... command is to force the downloaded gems to be installed locally, rather than in the system directories. The command is what was suggested by the bundler when bundle install was run as a non-root user. The vendor/ directory is not tracked by git – a .gitignore file was generated when jekyll new ... was run.

Normally, we would run bundle exec jekyll serve to generate and preview the web pages, however, since I am using ruby 3.0.x, I also needed an additional package:

bundle add webrick

The above added another entry, gem "webrick" ..., to the Gemfile. Bundler was run again for the new gem:

bundle install

Local preview of the web site

We are now ready to preview the, currently empty, web site:

bundle exec jekyll serve

While the server is running, the web site can be viewed at http://localhost:4000. If we modify any of the contents, such as index.markdown, the modification will be reflected in the web page, of course the browser tab will need a refresh/reload.

Customization

The main configuration of the web site is kept in the _config.yml file. Some of the initial settings are sample site title and author names and email. These needed to be changed.

I configured my own title, name, email etc, followed by a restart of the server.

It should be noted that changes to _config.yml will only take effect when the server is restarted.

Blog posts

Once the web site was operational, the initial base pages, index.markdown and about.markdown, were personalized.

Next, it was just a matter of creating the blog posts in the _posts directory.

Setting up my own hostname and https

I wanted the web site to be accessed through my own domain name, anydata.uk. Again, this was achieved on the github web site, following the instructions here

It required creating two ANAME records, anydata.uk and www.anydata.uk, through my domain name service provider. Both ANAME and CNAME records serve the same purpose, an explanation of the differences can be found on Wikipedia.

When configuring the hostname on Github, a new file, CNAME, was created and committed to the repo by github. Withih the github settings page the box for https was also selected. Naturally, there was a delay before the complete https based web site was available.

The web site is still accessible through the original github address, https://fredyouhanaie.github.io.

Other domain names

I also needed my old hostnames, anydata.co.uk and www.anydata.co.uk, to point to the new web site. However, since github only allows one CNAME per web site, this could only be achieved with an html redirection on the original server.

The _drafts directory and the drafts git branch

Jekyll expects the blog articles to be files in the _posts directory. It will also check for articles in the _drafts directory, provided that the web pages are generated with the --drafts command line option, for example:

bundle exec jekyll serve --drafts

This feature combined with a local/private git branch called drafts (actually any name would suffice here) has enabled me to adopt the following process:

1. Take new blog ideas (good or bad) and write them in files in the _drafts folder
2. Track the changes/revisions made to the files with git (drafts branch)
3. Review the rendered pages locally, edit/update as necessary
4. Repeat the above until something worth publishing emerges
5. Copy (not move) the finished article to the _posts directory, ready for publication

The last step involves creating a new file on the main branch, and pushing the changes to github.

Epilogue

For anyone considering a similar project, the supporting documentation provided by Github and Jekyll are pretty good, even for the impatient! The occasional internet search also helps ;-)

So, what’s the point of this article? Well, it provides one specific scenario for anyone in a similar position. And, more specifically, it has allowed me to aquaint myself with the toolset :-)

Learning MCollective
Jo Rhett
O'Reilly Media
ISBN: 978-1-491-94567-4
264pp.
£25.99
Published: August 2014

MCollective (M for Marionette, as in puppet!) is a Ruby based software framework from Puppet Labs for orchestrating configuration changes across Puppet or Chef based groups of servers.

MCollective communicates with the servers under its control through a message broker, currently only ActiveMQ and RabbitMQ are supported. The main text along with the examples only covers ActiveMQ, however, those who prefer RabbitMQ are provided with guidance in the appendix.

The book is divided into four parts that take the reader from initial installation of the base software to writing custom plugins.

Part I, Getting Started, takes the reader through the basic installation and configuration of the software, MCollective and ActiveMQ. It then proceeds to introduce, with examples, the main command line interface, mco. Although, there are web clients for the software, we are urged to stay with the command line.

Moving along, we are introduced to the basic workings of MCollective plugins and agents, as well as brief tips on system level maintenance, such as time sync, log files, monitoring etc. We are then shown how to configure MCollective with puppet and chef, yes it does sound like a chicken and egg situation, but the modules are there for us to use.

Those with a large enterprise installation are catered for in part II, Complex Installations. The message broker plays a very critical role in an MCollective based environment. In the next five chapters the reader is given guidance on how to create broker networks to aid scalability and resilience, as well as using certificates to make the message broker(s) more secure. Admittedly, I only skimmed over this part, but I am planning on a more through read at a later date.

As one can expect with any framework these days, MCollective comes equipped with the ability to create and use plugins. Part III, Custom Plugins, provides various examples of plugins and walks the reader through creating and deploying them.

Finally part IV, Putting It All Together, sums up the preceding chapters, provides a set of best practices and gives guidance on expanding the MCollective deployment.

I had a play with the command line examples on a Vagrant/VirtualBox based demo environment that is provided by Puppet Labs, all good fun, and no surprises there. The example codes and related data files used in the book have been made available on Rhett’s github repository.

Throughout the book, there are numerous hyperlinks for additional material, however, they are all Bit.ly shortcuts, which means the reader of the paper copy of the book will need to type in the links manually. It would be nice if the author could include these on a web page, or somewhere on the book’s github repository.

Overall, this book covers a lot of ground, going beyond a mere introduction to the basics of the framework. Although, its main focus is on Puppet and ActiveMQ, those who prefer Chef and/or RabbitMQ can still benefit from the text.

Functional Thinking
Neal Ford
O'Reilly Media
ISBN: 978-1-449-36551-6
164pp.
£25.99
Published: July 2014

The preface starts with a history of the book. The author tells us how his learning process culminated into a series of talks and articles, which now form the basis of the chapters of the book. Ford also tells us that his “… goal in the talk, the article series, and this book is to present the core ideas of functional programming in a way that is accessible to developers steeped in imperative, object-oriented languages.”

Throughout the book we are treated to many examples of functional code snippets, written in the three JVM (Java Virtual Machine) based languages, Clojure, Groovy and Scala.

Chapter 1, Why, gently sets the scene for the functional programming concepts that are to follow. It introduces the virtues of functional programming by showing some long Java code snippets for solving simple problems, these will suit the developers steeped in imperative, object-oriented languages.

Chapter 2, Shift, shows us how to shift our thinking from imperative programming to functional programming. Ford demonstrates this by means of a simple case study, number classification, deciding if a given integer is a perfect number not. We are first introduced to a solution in Java (not Java 8), followed by a much shorter one written in Java 8. We are then introduced to a few common building blocks that are “ubiquitous” in functional programming. These “Useful things” are filter, map and fold/reduce, and they are demonstrated using numerous examples in Clojure, Groovy and Scala.

In chapter 3, Cede, we are shown how to cede control of the low level details (such as author’s least favourite, garbage-collection) to the underlying run-time system. We are introduced to five ways of ceding control so that we can spend more time thinking about the main problems. These methods are higher order functions; closures; currying and partial applications; recursion and streams. For each of these we are treated to a number of concise examples using the familiar trio of languages.

As we move through the chapters, Ford delves deeper into the functional programming paradigm. In chapter 4, Smarter, Not Harder, we learn about memoization (caching) and lazy evaluation. As usual, there are plenty of examples to help us work smarter.

Chapter 5, Evolve, demonstrates how one can bend the language so that it fits the problem being solved, rather than the converse. The main topics covered are operator overloading and functional data structure. The latter includes pattern matching and Either/Options classes.

The main theme of chapter 6, Advance, is design patterns. Here we learn more advanced techniques when programming in functional languages.

In chapter 7, Practical Thinking, Ford covers Java 8, the latest version of Java that understands concepts of functional programming, as well as some real world examples such as web frameworks and databases, although not in detail.

The book is concluded with chapter 8, Polyglot and Polyparadigm, where the author discusses functional programming within the wider world of languages and programming paradigms.

Overall the book is well written and worth a read for anyone interested in learning the underlying concepts of functional programming. The presence of Java examples does suggest that the book is aimed at Java programmers, however, the non-Java developer should still be able to understand the main message of the book – “Paradigm over Syntax”. Additionally, one also gets a fair exposure to the trio of the JVM functional languages used in the text.

Becoming Functional
Joshua Backfield
O'Reilly Media
ISBN: 978-1-449-36817-3
134pp.
£19.50
Published: July 2014

The subtitle of the book is “steps for transforming into a functional programmer”, however, from the start one realises that the object of this transformation is “a Java programmer”.

The entire book is based on an example which is the legacy Java code of a fictional company named XXY, and the reader is gradually introduced to the elements of functional programming by way of transforming the Java code into the Scala and/or Groovy equivalents.

Chapter 1 gives an overview of functional programming in terms of the seven concepts: First-Class Functions; Pure Functions; Recursion; Immutable Variables; Strict and Nonstrict Evaluation; Statements; Pattern Matching. These concepts are then described, using Java examples, in the seven chapters that follow the overview.

In chapters 2 and 3, first-class and pure functions are introduced by means of transforming Java examples into more functional looking variants. In chapter 2 we learn about lambdas and closures, while chapter 3 demonstrates how to avoid side effects in order to create Pure Functions. Here, we encounter some Groovy (the language) examples.

Chapter 4 demonstrates how immutable variables can be implemented using a series of transformations of the standard example Java codes. This is followed by a chapter on recursion. Tail recursion, an important concept in functional programming, is also covered here. This is the chapter where we start learning about Scala.

Chapter 6 is about strict and non-strict (lazy) evaluation. The concepts are explained using examples in Groovy and Scala. The advantages and disadvantages of each of the methods is also covered.

In chapters 7 (Statements) and 8 (Pattern Matching) we are treated to more Scala code. Chapter 7 shows how one can obtain a more concise code since every statement in a functional language returns some value. This is demonstrated by means of transforming the example Java code to its Scala equivalent. This leads nicely to the chapter on pattern matching, which contains plenty of example codes in Scala (and no Java!)

In chapter 9, Functional OOP, we are treated to more examples in Scala and shown how we can got about taking advantage of both worlds.

The book is short and concise. The text is well written and the structure makes it easy to get the gist of the contents. Most of the chapters have a conclusion section that sums up what has been covered in the chapter, including the “Conclusion” chapter, but the recursion stops there!

If you are a Java programmer and have not had any exposure to functional programming, then you can benefit from this book. On the other hand, if you have had some exposure to functional programming, but programming in Java is not second nature to you, then you may find the Java examples rather distracting.