Thursday, July 02, 2015

Global Warming is a Year 2000 problem

Global Warming is a Year 2000 problem.

What I mean is not that Global Warming has been solved (far from the case) nor that it is a problem that we could only have solved 15 years ago (though that might be closer to the truth).

What I mean is that if we solve Global Warming, then people will think it was a hoax (or something we should not have worried about).

Think back to the glory days of the 1990s. Media was full of stories about how all the world's computer systems were going to fail because programmers tried to save space on their systems by dropping the first 2 digits off the year field. Power stations and ATMs would stop working. Global financial crises would ensue (well, that did happen, but for other reasons...). Basically we were going back into the stone age unless we chucked large amounts of money at software developers to fix our computer systems and by and large that did happen.

After we partied like it was 1999, apparently nothing happened. I am sure a couple of systems failed, but nothing major. We were all still alive and we still had electricity and we could still get money out of ATMs.

Post 2000, everyone now thinks the whole thing was just a bunch of hooey.

But maybe we did avert major disaster by all our hard work. We will never really know.

I hope to an extent the same thing does happen with Global Warming. There are differences of course. We have not got a set date where the planet will be uninhabitable. A date when we can look back and laugh at ourselves for being so silly.

Instead, we will look back at ourselves in shame for being so oblivious (and remember what things used to be like).

There's probably not much we can do on an individual level. We will need to elect people who are aware of the problem and reach consensus (easier said than done).

Let's just hope that in 7984 years we have a Year 10,000 problem to deal with ("Why on earth did they think they could save space by only allocating 4 digits to a year?").

Wednesday, June 17, 2015

Source Location, i.e. Where the heck is this method defined?

Just a short one for now.

Most of the time, if you are working on a well defined project, it's pretty easy to find where a function is if you want to change/tweak it. You can look in the class where it is defined and/or see if there are any mixins or decorators.

Sometimes, it can be downright impossible to tell.

Enter source_location

Fire up your rails console and put in the following (for a class method :search on User)


if you have an instance method

This should give you something like the following



This should at least give you some idea of what is going on...

Sunday, June 14, 2015

Mixins in ES6

I had been looking for a good way to do mixins in ES6.

Looks like I finally found one.


create the mixin as a const

Use Object.assign to add the properties to the Class

const BookCollector = {
  addToCollection (name) {
    return this;
  collection () {
    return this._collected_books || (this._collected_books = []);

class Person {
  constructor (first, last) {
    this.rename(first, last);
  fullName () {
    return this.firstName + " " + this.lastName;
  rename (first, last) {
    this.firstName = first;
    this.lastName = last;
    return this;

Object.assign(Person.prototype, BookCollector);
(I am copying and pasting this for personal reference in case the original site link goes down).

Thursday, May 28, 2015

The perils of over testing

Test Driven Development (TDD) is a great thing. It allows us to write code "safe" in the knowledge that if we accidentally break something in another part of the system, we will be alerted to it and can re-write or fix accordingly.

It's such a good thing that often in large teams people will insist on this idea of 100% code coverage (i.e. every piece of working code has a corresponding test). Also, some people are compelled to test every single permutation and variation of how someone will access their program/website.

TDD does have some costs however. Some are evident, but others not so.

Cost 1 - Tests take time to run
True, automated testing is faster than manual testing, but they do take time to run. This time means every time you make a change to the code, you need to wait for the suite to finish running in order to feel that your code is "safe" for deployment.

Most of this time is a necessary evil.

A lot of it is unnecessary...

Should you write a feature that checks to see that a form is disabled if a text box is not checked? Well, it depends...

If this is essential to the end user getting to a process, then possibly yes.

If this is just to check a possible error condition that has little or no bearing on the final result, then possibly no.

You could maybe write it as you are developing a feature and then remove it when you are done.

Or else you can write an Object Oriented JS component (FormDisabler) and then test its logic with Jasmine.

Bear in mind that testing JavaScript in a feature will bring up the whole stack which takes time. Time is valuable.

One analogy is that testing is like packing for a trip. You might think that you will need to bring everything you have to cover every possible situation, but really you probably only need an overnight bag with a couple of changes of clothes. The cost is that the more you bring, the more you have to carry.

Cost 2 - Brittleness
Over testing can lead to a very brittle code base where one small change can lead to many hours of fixing broken tests. In Agile development you will constantly make changes to the code base and often what is wanted in the end is not what is expressed in the beginning.

If you test every single possible scenario, then a small business change can lead to a domino effect of broken tests.

The key is to identify what aspects/methods of a feature are most important and to test those.

Classes should be made bulletproof, but not features.

Martin Fowler's Test Pyramid is a good guide.

At the end of the day, you have to use your brain and judgement to determine what tests are important and what tests are not. It is a subjective thing and can vary from team to team (and application to application). Back to the packing analogy, you should only pack what you need for the trip. If you are writing something mission critical that can never go down and the slightest mistake can lead to potential loss of human life, then by all means go for 100% test coverage. On the other hand, if a mistake in part of your app means a comment or review might not get posted, then test accordingly.

Sunday, April 12, 2015

ECMAScript 6

Today is a rather significant one for me as JavaScript/Rails programmer because Sprockets ( upgraded to version 3 meaning I can now use the Sprockets-es6 gem ( to transpile ES6 JavaScript to ES5.

Now to those that didn't understand the last paragraph, here's what it means...

The language we commonly call JavaScript is actually formally known as ECMAScript ( Since 2009 all the major browsers have been interpreting ECMAScript version 5. In fact they mostly still do.

Version 6 is due to be formalised any day now (well, June 2015) which means that a whole new slew of functionality is due to be added to the language (class constructors, formal inheritance, fat arrows, etc...). Browser makers will start implementing these new features once the spec is complete.

All of this sounds great, but for 2 things

1) I want to start using ES6 today
2) Even if the newly released browsers did come out today, people are not all going to upgrade their browsers as soon as the new ones come out. Typically there is about a year lag before a new feature (or set of features) has enough critical mass to be used with any confidence.

So what can we do?

Well thankfully there are transpilers which can take most of the features of ES6, and rewrite them as ES5. The 2 main ones are Babel ( and Traceur ( For various reasons, I chose to use Babel (because I found their resulting code more readable and because their gem, Sprockets-es6, seemed to have the easiest to add to our project flow). (Basically Traceur didn't work with Phantom which is what we use for testing and is actually running ES4!).

Unfortunately, sprockets-es6 had a dependency on sprockets 3 which was in beta up until this weekend.

And now it's out of beta!

As I write this I am just testing it out on our develop server and hopefully I will go live with it soon.

Happy days.

If you want an example of what can be done with ES6, you can mess around with it here.