RSS

Monthly Archives: June 2010

Adding Twitter Search to Chrome

This article will show you how to add 2 new Search Engines (‘Twitter User’ and ‘Twitter Hashtag’) to Chrome in just a few minutes.

First, right click on the Chrome Omnibox and choose ‘Edit search engines…’. Alternatively, go to Chrome Options and click on the ‘Manage’ button in ‘Default search:’ area. Either way you should now be looking at the ‘Search Engines’ dialog…

Click the Add button to create the following search engine…

Name: Twitter User
Keyword: @
URL: http://twitter.com/@%s

Click OK.

Next, click the Add button again to create our second search engine like this…

Name: Twitter Hashtag
Keyword: #
URL: http://twitter.com/search?q=%23%s

Click OK and then close any remaining open dialog windows.

So now, whenever you start typing the @ symbol Chrome will activate the Twitter User search

and whenever you want to search for a hashtag just start typing with the #symbol…

 
Leave a comment

Posted by on June 18, 2010 in Technology

 

Tags: , ,

If Klingons Wrote Software

I like Star Trek. Not in a uniform-wearing, funny handshake, cross-to-the-other-side-of-the-street-to-avoid-me kind of way; but I like it and I do seem to be able to remember a lot of details from it. For instance: when Klingons go into battle they assume that they are already dead. If they survive it’s a bonus and if they do actually die then, well, it was expected so no surprise. This is the way we should be developing software and it has a name – “Lean Startup”.

I’ve written a lot of applications targeting all manner of media and platforms – but they all had the same sentiment: “If we only get this right, everyone will buy it”. I now think this is wrong. What we should be thinking is “This is a pile of crap and no-one’s gonna buy it”.

“What?! You mean we should actual aim to fail?”

No.

What I mean is this: if you assume that your software is probably worthless then this changes the way you write it. Your job now becomes “I’m probably gonna fail, so how do I fail quickly?”. Eric Ries talks about failing products not equating to failing companies.

So, your business plan becomes “I have a lot of ideas for products. One of them might succeed. How do I quickly discover which one that is without wasting time and money on those that no one is interested in?”

What does this mean in practice? Here’s a small sample list:

  1. Minimum Viable Product. Get it out there! It’ll be crap, but do it and do it quickly.
  2. Measure everything. How do you know which parts of your application people are interested in if you don’t capture that information?
  3. Smoke Tests. See how many people click on the fake ‘Buy It Now’ button. That tells you more than any theoretical pricing model or traditional market research.
  4. Pivot. You might have the basis of a great idea. Don’t be fixated on what you think it should do – listen to your users.

The Lean Startup movement has radically changed how I develop software and it’s not just for startups. Any project, even in the enterprise, that has a level of uncertainty will fit this model.

For more information check out Eric Ries’ blog.

 
Leave a comment

Posted by on June 8, 2010 in Lean Startups

 

Tags: , , ,

Introduction to Code Contracts

Firstly, to those who went to DDDSW last weekend. Apologies if this post just re-hashes what Barry Carr said during his Code Contracts talk. I didn’t see if myself although it was the existence of this item on the agenda that prompted me to investigate this topic.

Now, let me start by saying “I love Code Contracts”. They will save you time, code and headaches if you implement them correctly. Rather than just talk theory I thought it would be more informative to go through a worked example together…

The Bank Demo

We’ve been asked to add a simple feature to an existing banking application that allows transfers to be made from one account to another. Here are the, entirely sensible, starting classes we’ve created…

interface IAccount
{
  string Name { get; }
  double Balance { get; }
}
class BankAccount : IAccount
{
  string Name { get; set; }
  double Balance { get; set; }
}

static class TransferService
{
  public static void TransferMoney(IAccount from, IAccount to, double amount)
  {
    from.Balance -= amount;
    to.Balance += amount;
  }
}

Well, that would work – mostly; but we have no exception handling or validation. So, here’s how we would normally amend that…

Ugly Validation

interface IAccount
{
  string Name { get; }
  double Balance { get; set; }
}
class BankAccount : IAccount
{
  // Name is required, so add it to the constructor...
  public BankAccount(string name)
  {
    if (string.IsNullOrEmpty(name))
      throw new ArgumentNullException("name");

    Name = name;
  }
  public readonly string Name;
  public double Balance { get; set; }
}

static class TransferService
{
  public static void TransferMoney(IAccount from, IAccount to, double amount)
  {
    // None of the accounts can be null and the amount must be positive...
    if (from == null)
      throw new ArgumentNullException("from");
    if (to == null)
      throw new ArgumentNullException("to");
    if (from.Balance < amount)
      throw new ArgumentOutOfRangeException("from account does not have enough money to transfer");

    from.Balance -= amount;
    to.Balance += amount;
  }
}

Ok, so that’s better; but we’re starting to really muddy our previously clean classes with all the new validation code. The other problem is that the interface (IAccount) doesn’t define the full contract. What we actually want to enforce is ‘has a Name property’, ‘has a Balance property’ AND ‘the Name property cannot be empty’. Clearly there’s no mechanism in the language to specify our final requirement – but it’s important. To fix this we find ourselves leaking contract information into classes – in this case our BankAccount class. Now, we could solve this by creating an abstract Account class but then the TransferService would have to change as well and, to be honest, you may as well just get rid of the interface because you cannot use it without the abstract class.

Whilst we’ve been thinking about this the ‘boss’ reminds us that the Balance on any account can never be negative. OK, well that destroys our nice, clean auto-implemented property! The BankAccount class now needs to be amended to this…

class BankAccount : IAccount
{
  // Name is required, so add it to the constructor...
  public BankAccount(string name)
  {
    if (string.IsNullOrEmpty(name))
      throw new ArgumentNullException("name");
    Name = name;
  }
  public readonly string Name;

  private double _balance;

  public double Balance
  {
    get
    {
      return _balance;
    }
    set
    {
      if (value < 0)
        throw new ArgumentOutOfRangeException("Your Bank does not allow your account to be negative.");
      _balance = value;
    }
  }
}

I think I prefer the cleanness of our original BankAccount class – how do I get that back?

Well, wouldn’t it be the best thing you’d heard this month if you could define the whole of your contract just via the interface? 3rd party developers could then create their own account classes to use in your Transfer Service without you having to tell them about the extra Name or Balance validation. This is where Code Contracts come in.

Contract Requirements

The Contract class in the System.Diagnostics.Contracts namespace has a number of static methods that can be used in a similar way to assertions in unit tests. With them we can tidy up our validation code…

interface IAccount
{
  string Name { get; }
  double Balance { get; set; }
}
class BankAccount : IAccount
{
  // Name is required, so add it to the constructor...
  public BankAccount(string name)
  {
    Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(name));

    Name = name;
  }
  public readonly string Name;

  private double _balance;

  public double Balance
  {
    get
    {
      return _balance;
    }
    set
    {
      Contract.Requires<ArgumentNullException>(value >= 0, "Your Bank does not allow your account to be negative.");

      _balance = value;
    }
  }
}

static class TransferService
{
  public static void TransferMoney(IAccount from, IAccount to, double amount)
  {
    Contract.Requires<ArgumentNullException>(from != null, "from cannot be null");
    Contract.Requires<ArgumentNullException>(to != null, "to cannot be null");
    Contract.Requires<ArgumentNullException>(from.Balance >= amount, "'from' account does not have enough money to transfer");

    from.Balance -= amount;
    to.Balance += amount;
  }
}

So now you’re thinking “Well, that’s nice. My code is a little tidier, but I’ve effectively just changed syntax.”. And you’d be right – almost. The benefit to using the Contract methods is that they can be evaluated at compile time and during static analysis. However, in order to reach the tipping point where you might start thinking “OK, I’m going to use this!” we have to start using some of the Contract Attributes.

Contract Attributes

Contract Attributes allow you to move your validation to a separate class.

[ContractClass(typeof(AccountContract))]
interface IAccount
{
  string Name { get; }
  double Balance { get; set; }
}
[ContractClassFor(typeof(IAccount))]
class AccountContract : IAccount
{
  public string Name
  {
    get
    {
      return string.Empty;
    }
  }

  public double Balance
  {
    get
    {
      return 0;
    }
    set
    {
      Contract.Requires<ArgumentNullException>(value >= 0, "Your Bank does not allow your account to be negative.");
    }
  }
}

class BankAccount : IAccount
{
  public readonly string Name;
  public double Balance { get; set; }

  public BankAccount(string name)
  {
    Name = name;
  }
}

Now that’s much nicer. Now all my validation logic is in a separate class and, with the use of the ContractClass and ContractClassFor attributes, my interface now defines my entire contract.

Contract Invariance

Another very useful attribute is ContractInvariantMethod. This allows you to decorate one, and only one, method in your class that contains contract logic that will be validated every time a property changes on your class. You don’t even have to worry about calling it yourself! We could use that to tidy up our AccountContract class…

[ContractClassFor(typeof(IAccount))]
class AccountContract : IAccount
{
  public string Name;
  public double Balance { get; set; }

  [ContractInvariantMethod]
  private void ObjectInvariant()
  {
    Contract.Invariant(!string.IsNullOrEmpty(Name), "Name cannot be empty.");
    Contract.Invariant(Balance >= 0, "Balance cannot be negative.");
  }
}

In order to introduce another feature of the Contracts namespace I will change the IAccount interface so that Balance is only gettable. This, then, requires the addition of 2 new methods to withdraw and deposit money to the account…

[ContractClass(typeof(AccountContract))]
interface IAccount
{
  string Name { get; }
  double Balance { get; }
  void WithdrawMoney(double amount);
  void DepositMoney(double amount);
}

Change Awareness (OldValue)

So, what contract should we define for these new methods? In each case ‘amount’ needs to be non-negative but also the Balance needs to change by the correct amount. If I deposit £10 I expect my Balance to increase by the same amount. We can make good use of Contract.OldValue for this…

[ContractClassFor(typeof(IAccount))]
class AccountContract : IAccount
{
  public string Name { get; private set; }
  public double Balance { get; set; }

  [ContractInvariantMethod]
  private void ObjectInvariant()
  {
    Contract.Invariant(!string.IsNullOrEmpty(Name), "Name cannot be empty.");
    Contract.Invariant(Balance >= 0, "Balance cannot be negative.");
  }

  public void WithdrawMoney(double amount)
  {
    Contract.Requires<ArgumentNullException>(amount >= 0);

    Contract.Ensures(Balance == Contract.OldValue(Balance) - amount);
  }
  public void DepositMoney(double amount)
  {
    Contract.Requires<ArgumentNullException>(amount >= 0);

    Contract.Ensures(Balance == Contract.OldValue(Balance) + amount);
  }
}

Putting it all together

Finally, you’re going to need to download a Microsoft DevLabs addon to Visual Studio to make all this work. DevLabs: Code Contracts automatically changes your code during compilation to bind you contract classes referenced in your interfaces to you concrete classes.

Conclusions

Code Contracts simplify validation, complete your interface definitions and keep you code clean. It enhances Design Patterns, for instance the Adapter Pattern, by allowing your interface to express your entire intent. I haven’t covered anywhere near what this namespace can do for you, so go check out the rest yourselves!

 
Leave a comment

Posted by on June 8, 2010 in C#

 

Tags: