Tag Archives: programming

Broken Window Policy of Programming

Written by Richard. Filed under programming. Tagged , . No comments.

There comes a point in every software projects life where everything just feels wrong. No one wants to touch the code as it stinks and everyone working on the project just feels demotivated and would rather just go home then have to do anything more on it. On projects like this, when it comes to adding new features or bits of code, because everything else is such a mess, the changes are just hacked in rather than being properly thought out and coded up well.

We’ve all been there and the frustrating thing is that our opinion of the project, from good to bad, seems to happens over night. If you sit down and think back, you can probably pick out all the things that were just shoved in that eventually led to the project becoming a mess, but at the time we never chose to do anything about. It’s almost always a case of deferring better solutions or a round of refactoring to some point in the future. “I’ll knock this up now and come back to it later.”. The problem is that later never comes. This is the essence of technical debt. You may only go into debt by a fraction, but do it a few times and eventually all those fractions add up. Until one day when you go to check your balance, you find yourself swimming in the middle of the ocean with no land in sight.

Implementing a broken window policy can go a huge way towards keeping a project healthy. If there is a broken window (bad code) fix it as-soon-as-possible. It doesn’t have to be that instant (although if you can, you should), but fix it. Part of the policy also means trying not to break windows yourself. Write the best code you can, as often as you can. Set the benchmark of quality for the rest of the team, even if they don’t follow suit. The danger is that many people are very “me too” about things. “Well if such-and-such can do it like this, then so can I *hack* *hack* *hack*”.

Of course we all write crap from time to time. TBH most of the stuff I write is crap. But I honestly feel more motivated to work on code that’s been loved and looked after, rather than something that’s hanging together by a thread.

Essential reading for developers

Written by Richard. Filed under computing, programming. Tagged , . No comments.

I’ve been meaning to write up a list of what books I think every developer, aspiring or seasoned should read. So let’s cut to the chase, and in no particular order:

Code Complete
If there was ever a bible for coding, this is it. It’s even Bible sized. A nice size to chuck at those annoying developers who just have no clue.

Clean Code
I would consider this book the “Ten Commandments” of coding and compliments Code Complete very very very well. If Code Complete teaches you how to be a Christian, then Clean Code teaches you how to be Jesus.

Refactoring to Patterns
What I love about this book is that it you learn the fundamentals of refactoring at the same time as design patterns. The GoF Design Patterns book is quite heavy going. The examples aren’t well laid out and can be confusing especially if you’re not familiar with SmallTalk The examples in refactoring to patterns all take pretty familiar real world bits of code and walk you through the process of refactoring them into sensible patterns.

Three books? Is that it? Yup. In my mind those are the only three books that are essential reading, no matter what form of development you do. If you even remotely care about coding, then go to Amazon now and buy these books. Read them and take a good long hard look at your own code. If on the other hand you feel “You can’t be bothered” to read, learn and improve, then why are you doing something you don’t love or care about? You’re in the wrong industry if you’re not prepared to take time, all the time, to learn new things. Once you’ve read those, then you’re ready to move onto more specialised books. Here are some of my other favourite development books from over the years:

The Productive Programmer
The Art of Agile Development
Practices of an Agile Developer
Joel on Software
Unix Power Tools
Programming Perl
Essential Java
Well Grounded Rubyist
Design Patterns in Ruby
CSS Mastery
Prioritizing Web Usability

Don’t use PHPMyAdmin. SSH tunnel instead.

Written by Richard. Filed under computing. Tagged , . No comments.

If you’re still using phpMyAdmin to admin your remote database, then you’re doing it wrong. Don’t expose your database to the outside world like this, instead use an SSH tunnel. In your terminal simply create the tunnel:

  ssh -fNg -L 8888:127.0.0.1:3306 {your_username}@{yourdomain.com}

Then in your MySQL interface of choice just connect to 127.0.0.1 port 8888 and voila, you’ll be connected to your remote database.

Apps like Querious even let you setup the connection internally without having to tunnel through in Terminal.

Law of Demeter and the delegate method

Written by Richard. Filed under computing, rails. Tagged , , , . 7 Comments.

The Law of Demeter, or Principle of Least Knowledge is a fairly simple design pattern, which, simply put means that an object should only talk to it’s immediate “friends”

The law states that a method M of and object O may only invoke the methods of the following kind:

1. a method on O itself
2. any parameters passed to M
3. any objects instantiated within M
4. any direct components of O

The classic example coined by David Bock used a Paperboy (one object) delivering a paper, then extracting money from a Customer’s (another object) Wallet (and another):

  class Paperboy
    def get_payment(customer)
      self.money += customer.wallet.take_out(10)
    end
  end

In the “real world” the Paperboy would ask the customer for the money who would then take it out for them, rather then the Paperboy reaching into the customer’s back pocket and getting it for themself.

Really we want something as follows:

  class Paperboy
    def get_payment(customer)
      self.money += customer.get_payment(10)
    end
  end

  class Customer
    def get_payment(amount)
      wallet.take_out(10)
    end
  end

This may all seem trivial and a waste of time, but what happens if some Customers want to pay by cheque? Those decisions should have an impact on the Paperboy, otherwise we end up with:

  class Paperboy
    def get_payment(customer)
      if customer.pay_by_cash?
        self.money += customer.wallet.take_out(10)
      elsif customer.pay_by_cheque?
        self.money += customer.cheque_book.write_cheque(10)
      end
    end
  end

Where as it makes more sense for the change to be contained within the Customer:

  class Paperboy
    def get_payment(customer)
      self.money += customer.get_payment(10)
    end
  end

  class Customer
    def get_payment(amount)
      if pay_by_cash?
        wallet.take_out(10)
      elsif pay_by_cheque?
        cheque_book.write_cheque(10)
      end
    end
  end

So what does this have to do with Rails and the delegate method? The delegate method adds a quick and simple way of following the Law of Demeter without having to do very much at all.

  class Order
    belongs_to :customer
  end

  class Customer
    has_many :orders
    has_one :credit_card
    has_one :bank_account

    def payment_method
      if pay_by_card?
        credit_card
      elsif pay_by_account?
        bank_account
      end
    end
  end

  class CreditCard
    belongs_to :customer
  end

  class BankAccount
    belongs_to :customer
  end

This setup means to get an Order’s payment we would have to say:

  @order.customer.payment_method.withdraw(amount)

But if we simply change our objects as such:

  class Order
    belongs_to :customer
    delegate :withdraw_payment, :to => :customer
  end

  class Customer
    has_many :orders
    has_one :credit_card
    has_one :bank_account

    def withdraw_payment(amount)
      if pay_by_card?
        credit_card.withdraw(amount)
      elsif pay_by_account?
        bank_account.withdraw(amount)
      end
    end
  end

Now all we have to say is:

  @order.withdraw_payment(amount)

So at any time, the details of how a payment  is to be decided can be contained with the Customer. This is of course a simplistic example, but hopefully explains how you chould be using this handy feature.

From TextMate to Vim

Written by Richard. Filed under computing, programming. Tagged , , . 1 Comment.

I’ve finally done it. After months and months of on-off usage of Vim, I’m now finally using it 100% of the time. It’s been a long and hard road getting here, but let me tell you, it’s been well worth it. I now feel like I absolutely fly through my code. I’ve read many a time, people saying that watching someone using Vim is like watching something mystical, and I can see why. Looking at how I edit code in Vim now, makes me feel clumsy when I think back to using other editors like TextMate. Don’t get me wrong, TextMate is a wonderful editor, but there is just something about the speed and finesse of editing in Vim which I have just fallen in love with.

I wrote about trying MacVim before and how I just felt it lacked the spit and polish that TextMate does. But now, I can’t remember why I originally felt that way. There’s a simple elegance to the Vim, yet with this awesome power available to you. Switching wasn’t easy in the slightest. I would load Vim up for an hour, tinker around, get frustrated and go back to Textmate. Then a month later I’d try again, learn a new command, last two hours and go back to TextMate. A few more months and hours turned into a full day, then the full day turned into a couple of days, and then I never looked back.

One of the keys to hitting the ground running is having a good config. I originally used jferris’s vimfiles but moved to scrooloose’s files not long ago. It practically has every plugin you could ever need to make life in Vim sublime.

Some other handy references I’ve used along the way have been vimtutor, the Vim Recipies Cookbook, the Vim Tips Wiki. To aid my own memory of useful commands I’ve even started my own Vim tumblr.