Missing menubar icons in OSX 10.6.2

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

A whole load of menubar icons disappeared after installing 10.6.2. Seems it’s a problem related to me doing a small hack in the past to disable Spotlight. Steven Seeger’s fix restored the menubar to it’s full glory.

  sudo mv /System/Library/CoreServices/Search.{bundle,bak}
  killall SystemUIServer

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

What’s your business hook?

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

I was doing some reading on usability stuff and thought I’d check out our homepage. Pretending that I know nothing about what we do and then reading all the text on the front page, I asked myself: How does a user use us? Is it an online service or is this a marketing site for a manual service that we provide via phone/email whatever? After reading it a couple of times, there is no way of ever knowing. Yes, there is the take a tour, but that’s already one click away from the homepage, and most people don’t scroll or go a level deeper then the homepage unless they already know what they are looking at is of interest to them. One can argue that the front page is a “teaser”, or a hook to gain a persons interest, but looking at the studies done, people don’t browse like that. The hook is not “Could this be of interest to me? I should find out more” but “This is of interest to me. Show me more.”

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.