My Third Coding Epiphany

My Third Coding Epiphany

I have been meaning to write this post for a while now and since I have spent most of this month back in the UK visiting friends and family I don’t have all that much to share technically so I thought it was about time I got this post done.

Over the course of my 23 years of coding I have had a number of what I call “Code Epiphanies”. These are moments in my coding career where fundamental changes in how I code have taken place.

Like most, I started my coding career writing simple scripts, for me it was the odd bit of HTML, JS, PHP and AS. It was simple imperative code, usually all contained in one file. “When this is clicked do this, then do this” etc.

This way of coding served me well. It took me all the way to University at which point I encountered Java and I started to write larger and larger programs. I now started to struggle as I noticed that I had many more classes and objects but no way to easily tie them together.

For a simple (contrived) example, suppose I have a “Player” object that wanted to let the “PlayerManger” object know when the player had died. I would do something like the following:

public class Player
{
    public PlayerManager manager;

	...

    private void Die()
    {
        manager.OnPlayerDie();
    }
}

The “manager” variable would be set from the outside by whoever created the Player. It looks simple but I found as I had more objects and managers I was getting horribly bogged down as I had to keep hold of references to PlayerManager in parts of the code which werent even remotely related. It was causing my code to become complex and hard to manage.

Thats when I had my first Code Epiphany, I discovered the Singleton. I no longer needed to pass my unrelated objects around, I could just access them directly within the player:

public class Player
{
    ...

    private void Die()
    {
        PlayerManger.GetInstance().OnPlayerDie();
    }
}

This was an incredible revelation to me as it opened my eyes to how important good architecture is as your program gets larger.

As the years went by however I started to notice issues with my Singleton based architecture. Although it was okay for quick projects that weren’t meant to last very long I noticed that as a program got bigger and bigger Singletons were becoming more and more of an issue. For example I found that I couldn’t easily swap out the PlayerManager for a different sort of PlayerManager without breaking a whole bunch of code, for example I couldn’t do the following:

public class Player
{
	...

    private void Die()
    {
        IPlayerManger.GetInstance().OnPlayerDie();
    }
}

Singletons I also found were making my code very rigid. I was finding it hard to abstract parts of my code out into separate reusable libraries that I could use in future projects. With Singleton references all over the place it was becoming a bit of a spaghetti nightmare.

It was around this time that Flash was starting to become really big and I found myself doing more and more AS code. It was also around this time that frameworks were starting to explode in the Flash world. I remember experimenting with a whole bunch of them: PureMVC, Cairngorn, Swiz etc, before I came across Robotlegs.

Robotlegs was (and still is) a great MVCS framework. It creates clear separation between the different layers of your application; Models, Views, Controllers and Services. One of the most important things for me was how it did this, by using a new concept (to me at least), Automatic Dependency Injection.

Automatic Dependency Injection (DI) was my second Coding Epiphany, it did away with my hard-coded Singletons and replaced them with neat little “Inject” tags. First you would define your dependency tree such as:

public class Context
{
    private void setup()
    {
        injector.mapSingleton(IPlayerManger, PlayerManager);
    }
}

You could then just write your Player like:

public class Player
{
	[Inject]
	public IPlayerManger playerManager;

	private void Die()
	{
		playerManager.OnPlayerDie();
	}
}

Then when you create a player using the injector, the IPlayerManager instance will be filled with a PlayerManager instance.

injector.createInstance(Player);

This was a revelation to me as it now meant I could create better isolation between may various classes. Player doesn’t care where PlayerManager comes from and it doesn’t even care what the implementation of it is, it just wants to have the OnPlayerDie() method.

This general concept was great. It applied to everything I did, be it Actionscript games, C# apps or Java backend code, it created nice separation of concerns for me but I was missing one major benefit of DI which led me to my third Code Epiphany.

About 12 months ago I joined The Broth here in Perth Australia. I joined as an Actionscript developer onto a team that had been working on a Facebook and Mobile game for over 3 years. This was my first time joining a team on a project that had already been in development for years and it was a real revelation to me.

Over the years the code had grown and evolved. It had in fact grown to the point where it was starting to get really hard to maintain. I was really afraid to make any changes as I didn’t have the years of experience to know what systems affected each other, whether deleting something over here would cause something over there to break.

So I did some googling and decided to invest in Michael Feather’s book Working Effectively with Legacy Code and Uncle Bob’s Clean Code videos.

51H6SHy6g2L._SX374_BO1,204,203,200_

Both Michael Feathers and Uncle Bob both based most of their discussions around automated testing. Infact Michael Feathers defined legacy code as any code that doesn’t have test coverage. I had heard about Unit Testing and knew that it was something I should be doing but never actually tried it.

Working on this 3 year old project was the perfect opportunity to get to grips with unit tests. As Michael Feathers describes in his book, once you have your code under test, that is you can be sure that its doing what it should be doing, you are then free to refactor the code so long as it passes the tests.

One thing I learnt very quick was that to make your code testable you have to be very careful how you structure your code. Your tests can get hard to write and maintain if your classes get too big or take on too many dependencies.

This to me was my third Code Epiphany. By keeping my classes small with minimal dependencies it made things easier to test. A side benefit was that it made the code much easier to read and reason about.

Going back to my contrived example. I would now structure my Player like:

public class Player
{
	private IPlayerManger _playerManager;
	
	public Player(IPlayerManager playerManager)
	{
		_playerManager = playerManager;
	}

	public void Die()
	{
		_playerManager.OnPlayerDie();
	}
}

I have removed the need for the [Inject] tag as now all my dependencies are just passed in the constructor.

I could then easily test like:

public class PlayerTests
{
	[Test]
	public void WhenPlayerDies_PlayerManagerInformed()
	{
		var mock = new MockPlayerManager();
		var player = new Player(mock);
		player.Die();
		Assert.IsTrue(mock.OnPlayerDieWasCalled();
	}
}

Unit Testing has forced me to write better, simpler to read code purely by the fact it would be hard to test if it wasn’t the case. As Martin Fowler says:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Well thats where im at these days. Trying to write easy to understand and testable code. I don’t know what my fourth Epiphany could possibly be but im excited to keep learning and improving.

New Tab Chrome Experiments – A new Chrome Extension

New Tab Chrome Experiments – A new Chrome Extension

I really enjoy making Chrome Extension, I love how fast it is to go from idea to implementation then availability on the store.

My latest extension is called “New Tab Chrome Experiments” was only conceived of on Sunday evening. I then spent yesterday coding it up and now its up and available todownload on the store.

As the name implies its an extension that replaces the “New Tab” page in chrome. I have always been a fan of the ChromeExperiments.com website and thought wouldnt it be cool if you could view one of those experiments each time a new tab is opened.

screenshot02

The extension works by first downloading the entire catalog of Chrome Experiments from the site. At first I thought I was going to have to scrape but then I went digging through the network traffic of ChromeExperiments.com and found that they are using an un-published but nice API: “https://chromeexperiments-dat.appspot.com/_ah/api/experiments/v1/experiments”.

screenshot01

With that data I could then randomly pick one experiment and load its URL in an iFrame each time a new tab is opened. I also present a little info box on the left hand side which tells you about what experiment you are looking at and provides a link to its page and its author.

screenshot03

I wrote the whole thing in Typescript using React and various other libs. I open-sourced it incase you were interested: https://github.com/mikecann/new-tab-chrome-experiments

You can download the extension from the Chrome Webstore here: https://chrome.google.com/webstore/detail/new-tab-chrome-experiment/ooopblodejpcihjoaepffbkkhfeeofhp

Anyways it was a fun little experiment, I hope people enjoy it as much as I do!

Post To Tumblr – v6.16 – Templated Variables

Post To Tumblr – v6.16 – Templated Variables

Its been a while since I have posted about Post To Tumblr so I thought I would do a quick update seeings as I am still definitely working on it.

The latest update (v6.16) added an excellent community suggested feature “Templated Variables”.

chrome_2016-06-26_15-11-24

Templated variables is accessible from the one-click options and allows users to specify special keywords which get replaced when Post To Tumblr is run:

chrome_2016-06-26_15-15-13

chrome_2016-06-26_15-16-46

This allows users to customize things with much greater freedom than was possible before.

I also added the ability to paste in your clipboard which was another user-requested feature:

chrome_2016-06-26_15-18-27

As of version 6.17 this variable is hidden behind an “optional permission” as it was causing a quite scary permissions dialog when people initially installed or updated the extension which several users were kind enough to contact me about.

So thats the update, I hope you all like it, as usual email me: mike.cann@gmail.com if you have suggestions for other improvements.

You can download the extension here: https://chrome.google.com/webstore/detail/post-to-tumblr/dbpicbbcpanckagpdjflgojlknomoiah