Comparing OOP and Component Based Design

In this article I’d like to discuss two concepts that you might not immediately think to compare. I’ve written previously on keeping your stylesheets modular and also on boundaries in object oriented design, so today I bring the two loosely together.

Testing without QA

We have an almost continual dialogue on how to improve the quality of the software that we’re involved in delivering. One of the conscious decisions that we’ve made is that we don’t make use of a dedicated QA or test role.

Componentisation and the Single Responsibility Principle

Keeping a good separation of concerns means writing code that only handles as much as it needs to. It’s a concept that should affect every piece of code you write, from class definitions to database tables. Only store the data which is relevant. Only encapsulate the logic which is covered by the responsibility of your class. My colleague wrote about this recently when discussing Inheritance and Composition.

Pull requests and Continuous Integration

A few months ago at Made Tech the Finery team switched to GitHub. Before the move we pushed commits directly into the master branch. Commit notifications with links to the diffs would then come up on the Finery channel on our HipChat server, and members of the team could review the commits at their own leisure. There was no commitment to code review.

All looking rather Dashing

At Made we collect a lot of metrics. From projects, to servers, to support, to admin. All of these are stored in various services and it’s not that easy to get quick and simple visibility of these.

Rules for Stylesheet Modularity

Keeping applications organised takes a lot of work. Furious bursts of development where deadlines are tight can lead to poorer design decisions. The frontend in particular for me is harder to get right when the pressure is on. I’m writing this post in order to clarify my hard and fast rules for writing modular stylesheets in a rush.

Cross Browser Testing in IE7

We’re getting ever closer to the point where we can finally stop supporting certain legacy browsers; IE6 is officially dead, and the support Microsoft provides for clients running IE7 is extremely limited, but it’s still not particularly uncommon to meet a client that requires support for IE7.

Javascript of the Future

The history of Javascript, formally known as ECMAScript and originally Mocha, is a strange one. Originally developed by Brendan Eich at Netscape in ten days with the intention of creating a scripting language for the Web which could be picked up by new programmers, it has been praised and maligned in every corner of the Internet, by the same people in equal measure. The little language that could, or could at least try its hardest, has now spread past the browser to runtime environments like Node.js, game engines like Unity and “hybrid” mobile apps. This ubiquity is forcing the language to grow in scope and style dramatically.