Rake is a build language, similar in purpose to make and
ant. Like make and ant it's a Domain Specific Language, unlike those
two it's an internal DSL programmed in the Ruby language. In this
article I introduce rake and describe some interesting things that
came out of my use of rake to build this web site: dependency models,
synthesized tasks, custom build routines and debugging the build
script.

At goto Aarhus 2014, the
keynotes by myself, Erik Dörnenburg, and Tim Bray spent a
good bit of time considering the issue of privacy on the internet.
Afterwards Ola Bini got together with us to discuss this issue,
the current state of affairs, and what we developers should be
doing about it.

The Ruby Rogues is a popular podcast on programming in the Ruby
world. They invited me back to discuss the Ruby edition of Refactoring. We talked about the
definition of refactoring, why we find we don't use debuggers
much, what might be done to modernize the book, the role of
refactoring tools, whether comments can be used for good, the
trade-off between refactoring and rewriting, modularity and
microservices, and how the software industry has changed over the
last twenty years.

In our keynote for goto 2014, Erik and I consider our
responsibilities as software professionals towards combatting the
growing tide of mass surveillance. We talk about how software
professionals should take a greater role in deciding what software
to build, which requires us to have a greater knowledge of the
domain and responsibility towards our users and the greater society.
We say why privacy is important, both as a human need and for
the maintenance of a democratic society. We use the example of email
to explore the importance of an open, collaborative development
approach for key infrastructure, and argue our freedoms require a
greater level of encryption for all of us together with move to
decentralize. We finish with a brief mention of "Pixelated", a
project ThoughtWorks is doing to increase the use of encrypted email
and why its challenges are much more about UX than the details of cryptography.

We build many websites with rich content, often using
popular Content Management Systems (CMS). A recent project
involved a marketing website for a global manufacturer which
demanded complex interactive content with high availability
and traffic needs.
Our response was to apply the editing-publishing separation
pattern and build two distinct stacks of software for content
creation and delivery. In this deck you can see an overview of
this architecture and our response to the issues of integration
between the stacks, providing a secure preview of the live
site, and handling the evolution and scaling of the system.

I recently deleted a note on my Notes app on my apple laptop.
As someone who is a paranoid keeper of backups, and usually
commits all my work to a repository like git, I don't worry much
about accidental deletion. But Apple's notes app doesn't have any
form of version control, and it's all too easy to delete something
by accident. I have a daily rsync backup and run time machine, but
googling couldn't uncover a simple way of getting the note back.
So in case someone else needs to do this, here's what I did.

A maturity model is a tool that helps people assess the current
effectiveness of a person or group and supports figuring out what
capabilities they need to acquire next in order to improve their
performance. In many circles maturity models have gained a bad
reputation, but although they can easily be misused, in proper hands
they can be helpful.

A couple of videos of a conversation between me and my colleague
Badri about hexagonal architecture and its role in a Rails
application. In the first video we talk about what Hexagonal
Architecture means and how this leads into
the choice between the Active Record and Data
Mapper patterns for a persistance framework. In the second we move
more broadly into the architectural role Rails should play in an
application - should you see it as a platform, or a suite of
components.

Making a change to an interface that impacts all its consumers requires two thinking modes:
implementing the change itself, and then updating all its usages. This can be hard when you
try to do both at the same time, especially if the change is on a PublishedInterface
with multiple or external clients.

Parallel change, also known as expand and contract, is a pattern to
implement backward-incompatible changes to an interface in a safe manner, by breaking the
change into three distinct phases: expand, migrate, and contract.

Unit testing is often talked about in software development, and
is a term that I've been familiar with during my whole time writing
programs. Like most software development terminology, however, it's
very ill-defined, and I see confusion can often occur when people
think that it's more tightly defined than it actually is.

The term "Microservice Architecture" has sprung up over the
last few years to describe a particular way of designing software
applications as suites of independently deployable services. While
there is no precise definition of this architectural style, there
are certain common characteristics around organization around
business capability, automated deployment, intelligence in the
endpoints, and decentralized control of languages and data.

It's common for software systems to make remote calls to software
running in different processes, probably on different machines
across a network. One of the big differences between in-memory calls
and remote calls is that remote calls can fail, or hang without a
response until some timeout limit is reached. What's worse if you
have many callers on a unresponsive supplier, then you can run out
of critical resources leading to cascading failures across multiple
systems. In his excellent book Release
It, Michael Nygard popularized the Circuit Breaker pattern to
prevent this kind of catastrophic cascade.

The basic idea behind the circuit breaker is very simple. You
wrap a protected function call in a circuit breaker object, which monitors for
failures. Once the failures reach a certain threshold, the circuit
breaker trips, and all further calls to the circuit breaker return
with an error, without the protected call being made at all. Usually
you'll also want some kind of monitor alert if the circuit breaker
trips.

This is the second part of my keynote at OOP 2014 in
Munich and is a tricky talk to describe. Usually I like a title
and abstract to describe what the talk is about - but this talk is a
journey, and I don't want to tell you where I'm going, but instead
to explore the ground with me. I will say that it starts with my
biggest problem with most adoption of agile software development -
the nature of the interaction between users, analysts, and
programmers. It goes on to explore these roles, raising questions
about the relationship of programmers to users, our responsibilities
to them, and finally the Two Great Challenges that I think
programmers need to face up to.

Single-page web applications often turn into jQuery soup, where
application logic, DOM manipulation, and server access are all mixed
together. This mixing of concerns makes such applications harder to
understand and test than they ought to be. Segregated DOM is a modularization
tactic that separates all manipulation of the DOM into dedicated
JavaScript objects.

Refactoring has grown into a well-known technique, and
most software development teams at least claim to be doing
refactoring regularly. Many teams, however, don't appreciate the
different workflows that refactoring can be used in, and thus
miss opportunities to effectively incorporate refactoring into
their development activities. In this deck I explore various different workflows.
I hope it will encourage teams to integrate refactoring more
deeply into their work, resulting in a better designed
code-bases that will make it quicker and easier to add new
features.

Not long ago, a GPS unit (I rather like the British word
"satnav") that you carry around when hiking, was a geeky item for
gadget freaks. These days, most fairly well-off people carry a
smart phone with that capability and take it for granted, so much
so that it's reasonable to wonder if there's any value left in a
dedicated handheld satnav. I still rather like having one, I use
it either when hiking, or mounted on my handlebars when cycling. I
prefer it because it's more rugged in poor weather, and also using
the GPS won't drain my phone battery. For the last few years I've
used the Garmin 60CSx. It's a
nice unit, but my device has a worsening fault with it freezing on
startup.

So I fancied getting something new, and I settled on the
Garmin
Oregon 600. So far I haven't had a chance to use it on the bike,
and the winter means I won't get such a chance for several more
months. But I did take it for a few days hiking in Switzerland,
and thought I'd share my experiences.

There has been a shift in service based architectures over the last few
years towards smaller, more focussed "micro" services. There are many
benefits with this approach such as the ability to independently
deploy, scale and maintain each component and
parallelize development across multiple teams. However,
once these additional network partitions have been introduced, the
testing strategies that applied for monolithic in process applications
need to be reconsidered.
Here, we plan to discuss a number of approaches for managing
the additional testing complexity of multiple independently
deployable components as well as how to have tests and the application
remain correct despite having multiple teams each acting as guardians for
different services.

Morrisons OrderPad is a tablet web-application that helps staff in supermarkets
place orders for new stock as they walk around the store. The
resulting application makes a good expositional
architecture for a tablet web application backed by a
lightweight java server application. We highlight the separation
of application control and DOM interaction on the client, using
small, focused frameworks on the server, the broad-stack testing
environment, and the use of a pilot project to understand what
features were needed.

You're sitting in a meeting, contemplating the code that your
team has been working on for the last couple of years. You've come
to the decision that the best thing you can do now is to throw away
all that code, and rebuild on a totally new architecture. How does that
make you feel about that doomed code, about the time you spent
working on it, about the decisions you made all that time ago?

Software professionals should take responsibility for how our
software affects society. One of the primary concerns at the
moment is privacy, which is being undermined by mass surveillance.
Email is currently problematic because the movement of email to
services has led to a concentration of email provision that makes
it easier to monitor. We need to improve privacy by working to
widen the use of encryption for email, so that the cost of mass
surveillance becomes prohibitive. The challenge for this is
primarily a challenge of user-experience and software packaging,
not something that requires great understanding of cryptography.

Some notes from my experiences in setting up a Vagrant VM
to help collaborators use my web publishing toolchain. I used Chef
to provision the VM and rbenv to install and control the right
version of ruby.

As I talk to people about using a microservices architectural
style I hear a lot of optimism. Developers enjoy working with
smaller units and have expectations of better modularity than with
monoliths. But as with any architectural decision there are
trade-offs. In particular with microservices there are serious
consequences for operations, who now have to handle an ecosystem of
small services rather than a single, well-defined monolith.
Consequently if you don't have certain baseline competencies, you
shouldn't consider using the microservice style.

Shu-Ha-Ri is a way of thinking about how you learn a
technique. The name comes from Japanese martial arts (particularly Aikido), and Alistair Cockburn
introduced it as a way of thinking about learning techniques and
methodologies for software development.

Canary release is a technique to reduce the risk of
introducing a new software version in production by slowly rolling out the
change to a small subset of users before rolling it out to the entire
infrastructure and making it available to everybody.

Two computer security flaws were discovered in early 2014: Apple’s “goto
fail” bug and OpenSSL’s “Heartbleed” bug. Both had the potential for
widespread and severe security failures, the full extent of which we may
never know. Given their severity, it is important for the software
development profession to reflect on how they could have been detected so
we can improve our ability to prevent these kinds of defects in the
future. This article considers the role unit testing could play, showing
how unit tests, and more importantly a unit testing culture, could have
identified these particular bugs. It goes on to look at the costs and
benefits of such a culture and describes how such a culture was instilled
at Google.

David Heinemeier
Hansson, the creator of Ruby on Rails, gave a keynote at RailsConf
where he declared that TDD is Dead. This caused a predictably large
amount of controversy in both the Rails and wider software
development community. It also led to some interesting conversations
between David, Kent, and myself. We decided that these conversations
were interesting enough that others might like to watch them too, so
recorded a series of video hangouts where we discuss the role of TDD
in software development.

Self-Testing Code is the name I used in Refactoring to refer to the practice
of writing comprehensive automated tests in conjunction with the
functional software. When done well this allows you to invoke a
single command that executes the tests - and you are confident that
these tests will illuminate any bugs hiding in your code.

Most EnterpriseApplications store persistent data with a
database. This database supports operational updates of the
application's state, and also various reports used for decision
support and analysis. The operational needs and the reporting needs
are, however, often quite different - with different requirements
from a schema and different data access patterns. When this happens
it's often a wise idea to separate the reporting needs into a
reporting database, which takes a copy of the essential operational data but
represents it in a different schema.

In the early part of this century, I worked on my book Patterns
of Enterprise Application Architecture. One of the problems I
had when writing the book was how to title it, or rather what to
call the kinds of software systems that I was writing about. I've
always been conscious that my experience of software development has
always been focused on one particular form of software - things like
health care records, foreign exchange trading, payroll, and lease
accounting. These are very different to embedded software inside
printers, games, flight control software, or telephone switches. I
needed a name to describe these kinds of systems and settled on the
term "enterprise application".

There are many factors that lead to the troubling
DiversityImbalance that we find in the software
community. Some of these, like the problems in teenage education
that discourages girls from STEM subjects is a long term problem
where our profession can't play a central role in fixing . But one factor that comes down directly to us is
the alienating atmosphere that hangs over the tech community.

Over the last decade or so, Refactoring has become a
widely used technique to keep a high internal quality for a
codebase. However most teams don't make enough use of refactoring
because they aren't aware of the various workflows in which you can
use it. In this keynote talk from OOP 2014 in Munich, I explore some
of these workflows: such as Litter-Pickup Refactoring, Comprehension
Refactoring, and Preparatory Refactoring. I also remind people why
common justifications for refactoring will sabotage your best
efforts. (This talk also has a treatment as an infodeck.)

Bounded Context is a central pattern in Domain-Driven Design. It
is the focus of DDD's strategic design section which is all about
dealing with large models and teams. DDD deals with large models by
dividing them into different Bounded Contexts and being explicit
about their interrelationships.