Review: Single Page Applications with ClojureScript and Om

I have just finished Eric Norman's interactive programming course called "Single Page Applications with ClojureScript and Om," and I have to say I am very pleased with the course. The pacing is good, the examples are clear, and the hands-on exercises are both helpful and doable. The one complaint I had was that I had trouble reading the lighter font against the light background, but since the course is made of locally-stored HTML files, it was easy to get in and tweak the CSS to improve the contrast.

Users and Roles (Part 3)

In Part 2, I talked about how an almost trivial data simplification can turn a difficult-to-maintain system into a system with a surprising amount of power and flexibility. In this third and final post, I want to discuss a design principle that could help us to design simple, flexible systems without having to go throw a painful, labor-intensive set of iterations first.

Users and Roles (Part 2)

In Part 1 I described the kind of situation you get into with a naive access control system based on tying everything to a user ID: it starts out easy, but then gets harder and harder to change as the business needs evolve.

In Part 2, I want to look at how we can create a more robust and flexible system by "de-complecting" the separate ideas of user identity and access control.

Users and Roles (Part 1)

In my last post, I pointed out that complexity is the reason why good programmers sometimes write bad code. Complexity, however, can be difficult to recognize at the time you are creating it. Let me give you an example from my own experience as someone who has written code they later regretted.

Why do good programmers write bad code?

One of the things that annoys me the most about programming is bad code, especially if I'm the one that wrote it. And I know I'm not alone, because I work with other programmers, good programmers, and I hear them say, "Who wrote that crap?" knowing good and well they wrote it themselves.

It happens to all of us. If we write a lot of code, sooner or later, we're going to write code that embarrasses us because we know better than to do what we just did. And I don't believe it's simply a matter of being rushed, or being tired, or just having a bad day. I think there's a fundamental problem that makes bad code difficult to avoid unless and until we address it.

Over-engineering

One of the lessons I've learned all too well over the years is the cost of over-engineering. It's an easy trap to fall into, because once we start to get into a particular problem, and start breaking it down into smaller tasks, it's easy to see other problems that could also be solved using the same tools. Complication ensues, because we try to write code that covers every possible use case. This violates the agile programming rule of YAGNI (you ain't gonna need it), which is a good rule for avoiding over-engineering. But there's an even broader principle that also applies here, and that's the principle of doing more by doing less.

Microservices and DRY code

We're talking architecture at work, specifically monoliths versus microservices. Martin Fowler has been posting some articles that we're talking about, including Start With A Monolith, no Don't Start With A Monolith, and Microservices Have Trade-offs. It's thought provoking, and good for hours of discussion, but in the end, all we really want is a good way to build performant, reliable, maintainable systems. And the key to all this is separation: we need to structure our code so that every moving part has all the pieces it needs, without creating any accidental and obstructive coupling between pieces that aren't intrinsically connected.

What programming language should I learn?

If you're a beginning programmer thinking of making a career out of software engineering, congratulations! Now is a great time to learn computer programming, because there are so many to choose from, and so many exciting developments in the more modern languages. With all those possibilities, however, you may be wondering which language or languages you ought to learn. And the answer is: that depends on what you want to do.