Web apps should be a thin, easily replacable front to your business logic. It should be modular and composable. I have written about this before. But how do you — in practice — decouple the business logic from the web frontend?

I like to use a simple rule, which states that a web app has three (and only three) responsibilities: It must validate, delegate and respond, and nothing else.

It validates the input gotten from users through HTTP requests, and ensures that it lives up to the requirements presented by the business logic.

Then it delegates, passing the arguments on to the business logic. The web app basically lets go of the input at this point, and never touches it again. There might be some slight transformation needed, but if your business logic has an appropriate interface this should be minimal.

Finally, when the business logic returns the web app responds, either...

My apartment comes with an attic room. While the small, cold room three floors above me is all mine, the hall that connects to it is shared with the other inhabitants of the building. They too have their own attic rooms to get to.

The attic room is locked with a key only I have, and the attic hall is locked with a key we all share.

The other day, when I was putting some stuff in my small, cold room, the door to the hall was open and unlocked. As I walked out and down, I left it that way. I hadn’t unlocked the door. I wasn’t sure whether it was supposed to be locked or not, so I left it as it was.

The more I thought about this, the more I realized that it probably had to be locked. Most of the other times I had been to the attic the door had been locked. If it wasn’t supposed to be locked, why would there be a lock at all?

Apartment buildings like the one I live in are prone to...

Javascript has a triumvirat of function-amending methods: bind, call, and apply. They all modify a function, by setting its internal call property (this-reference) and deciding the arguments that are given to it. These three functions, as it happens, provide a pretty bad interface for doing just that.

I care a lot about interfaces in code. I believe that interfaces should work for the user, hide away complexity. I am willing to accept more complex code in exchange for a simpler and more easily usable interface.

Javascript has a long history, and faces a challenge that no other languages face: it has to stay backwards compatible. This means that if one new version introduces some bad syntax (or bad naming), it sticks.

For example, the name of XMLHttpRequest hasn’t changed, despite its highly inconsistent capitalization (all-caps “XML”, and camel cased “Http”).

A fun fact about bind...

Today, I would like to introduce you to a principle I call Do Unto Yourself.

At first, I had thought to call it Eat Your Own Shit, but that was unnecessarily crass. My reasoning was that crass sentences often stick more easily in the mind than more generic ones, and that Subject Yourself to That Which You Subject Others To would be less memorable.

Then I thought of the above-mentioned, and, you know, paraphrasing The Most Read Book™ will probably result in something at least somewhat memorable. So: Do Unto Yourself As You Would Do To Others.

The principle is one I first stumbled upon in Kent Beck’s Extreme Programming Explained on page 76, where he talks about Architects in The Whole XP Team:

Making big architectural changes in small, safe steps is one of the challenges for an XP team. The principle of the alignment of authority and responsibility suggests that it is a bad idea to...

You want to write readable code. Readable code has short functions and is easy to get an overview of. Being able to follow a single path of execution until the end before starting the next is easier than having multiple possible paths in mind.

if/else is a very common occurrence in code. It can look something like this:

if(expiryDate) {
    doSomething(expiryDate);
}
else {
    doSomethingElse();
}

This adds two different paths that must be understood mentally: okay, either we do something with the expiry date, or we do something else. These are two statements that must be evaluated for their sanity together rather than one at a time.

Of course, it gets much worse: many nested if/else statements are much longer and more complex.

As an alternative, I would recommend using if-return:

if(expiryDate) {
    return doSomething(expiryDate);
}
doSomethingElse();

The advantage of using...

Last week, I learned a valuable lesson or two about communication.

I was working remotely that Monday, specifying a new feature. I was defining a fairly advanced interface for sending graph-like data between an app and a server, and I thought that I was doing pretty well: I had specified desired capabilities, split the feature into steps, and decided to use a DOT-based syntax. DOT is a language specifically for describing graphs — exactly what I needed.

I was connected to the rest of my team via our chat (we use Slack) and had some good back-and-forths about the interface design. All the feedback was positive.

When I came in to work the next day, I gave a quick presentation of my proposed design. I thought it was pretty clever.

“But,” a comment from a co-worker, “it will be really hard to make the app serialize to DOT. There aren’t any good serializers, like there are for JSON.”

At...

In The Clean Coder, Robert C Martin writes about being in the Zone:

Let me be clear about this. You will write more code in the Zone. If you are practicing TDD, you will go around the red/green/refactor loop more quickly. And you will feel a mild euphoria or a sense of conquest. The problem is that you lose some of the big picture while you are in the Zone, so you will likely make decisions that you will later have to go back and reverse. Code written in the Zone may come out faster, but you’ll be going back to visit it more.

The Zone is known by many other names in many other contexts. The most general term for this state is Flow. There is quite a big body of research surrounding Flow. Flow can be reached when certain criteria are fulfilled:

• The difficulty of the challenges faced fit the competences of the actor: the programmer is challenged, but not excessively so.
• There are...

A Step Towards Efficiently Rendering Web Views

Quite a while ago, I wrote about different ways to render^[1] web views, and the efficiency of each way. I concluded that the most efficient and generally useful (and strangely absent) framework would be one that serves static files, all the while allowing the files to change after deployment, enabling dynamic content in static files.

As a step in the right direction, I built a simple blogging site that follows this principle: static-page-blog.^[2]

The outwards interface of the project is split in two distinct parts: the pages and an API. Pages are static files that are quickly derved. These files contain Javascript, which will communicate with the API. Changes to files happens by POSTing to the API, which then does two things: it updates the data store, and it re-renders views that have been affected by the data changes.

A clear...

Last week, I wrote about routing in web frameworks, specifically arguing for decentralized routing over centralized routing. Through writing that blog post, I stumbled upon a more general point, which I will try to explore here.

The spark for this discussion comes from Robert C Martin’s concept of being Framework Bound. Martin says that you are framework bound if you cannot easily change your framework; you are framework bound if your business logic is mixed in with your web logic. This makes a statement about where the web belongs: as a thin, exchangeable layer outside of your business logic.

I am going to take this a step further, and in doing so, I will assume that you write code that does not leave you framework bound,^[1] or at least that you understand the concept.

The Web in Software With Simple Components

A good software design is cohesive and has clean interfaces. It is...

Routing is the act of describing possible URLs and the components of an app that should handle requests to these URLs.

Centralized routing

In Ruby on Rails, which is probably the most influential web framework of the present,^[citation] the different URLs accessible in an app are described in a single file, called routes.rb.

A simple example of a route setup could look like this:

SampleApp::Application.routes.draw do
  match "/posts", to: "postsindex", via: "get"
  match "/posts/:id", to: "postsshow", via: "get"
  match "/posts/:id/like", to: "postslike", via: "post"

  resources :users

  root to: "postsindex"
end

This example only uses a few of the possible ways to define routes:

• match takes a string that describes the exact URL to request. The to argument describes the "controlleraction" to be taken when the page is requested. And variable defined in the URL (prefixed with :...