A Business in a Day: giveusaminute.com
Lately, my business partner and I have wanted to try some shorter ‘build days’. The idea of these are to start with a blank canvas and an idea, then deliver a working product by the end of the day. This is a very different approach to the months of effort that we generally invest to launch something.
Today we undertook our first build day and delivered Give Us A Minute, an iPad-targeted web app for managing wait lists:
It was a fun experience trying to achieve everything required in one day, but I think we did pretty well. We managed everything from domain name registration to deployment in just under 9 hours. One of the biggest unplanned tasks was actually building the website to advertise the app; we hadn’t even thought of factoring that in when we started the day. The photography also took up a bit of time, but we needed to do it to tell the story properly on the site. Also, it was nice to be required to go and find a beer garden with a tax-deductible beer each so we could get that bottom-left photo.
As part of staying focussed on the idea of a minimum viable product we dropped the idea of accounts very early on. At some point we’ll have to start charging for the text messages, but that then implies logins, registration, forgotten passwords, account balances and a whole host of other infrastructure pieces. In the mean time we’ll just absorb the cost of message delivery. If it starts to become prohibitive, it’ll be a pretty high quality problem to have.
The next step is to get this out on the road and into some businesses. We’ll start by approaching some businesses directly so we can be part of the on-boarding experience. Based on how that goes, we’ll start scaling out our marketing efforts.
We also need to get ourselves listed in the Apple App Store for the sake of discoverability. The ‘app’ is already designed with PhoneGap in mind, but we’re waiting on our Apple Developer enrolment to come through before we can finalise all of this.
iMissing iCal iCloud iInvites
A word of advice …
Scenario: I use Exchange for my personal calendaring. I only use iCloud for backups. Because of this, I have the iCloud calendars disabled on my iPhone.
Problem: Jason tried to invite some of us to an event last weekend and none of us saw the invite.
What Happened: He sent the invite from iCal to our personal email addresses. iCloud recognised the addresses as other iCloud users, so it didn’t even attempt to email us. Because we all had the iCloud calendars disabled, we never received the invite. (Hat tip to Aaron for working this out.)
How to fix it: Login to icloud.com. Turn Send me a copy of event invitations and updates to ON (it’s off by default). Turn Use iCloud for incoming invitations to OFF (it’s on by default).
Released: ReliabilityPatterns – a circuit breaker implementation for .NET
How to get it
Library: Install-Package ReliabilityPatterns (if you’re not using NuGet already, start today)
Source code: hg.tath.am/reliability-patterns
What it solves
In our homes, we use circuit breakers to quickly isolate an electrical circuit when there’s a known fault.
Michael T. Nygard introduces this concept as a programming pattern in his book Release It!: Design and Deploy Production-Ready Software.
The essence of the pattern is that when one of your dependencies stops responding, you need to stop calling it for a little while. A file system that has exhausted its operation queue is not going to recover while you keep hammering it with new requests. A remote web service is not going to come back any faster if you keep opening new TCP connections and mindlessly waiting for the 30 second timeout. Worse yet, if your application normally expects that web service to respond in 100ms, suddenly starting to block for 30s is likely to deteriorate the performance of your own application and trigger a cascading failure.
Electrical circuit breakers ‘trip’ when a high current condition occurs. They then need to be manually ‘reset’ to close the circuit again.
Our programmatic circuit breaker will trip after an operation has more consecutive failures than a predetermined threshold. While the circuit breaker is open, operations will fail immediately without even attempting to be executed. After a reset timeout has elapsed, the circuit breaker will enter a half-open state. In this state, only the next call will be allowed to execute. If it fails, the circuit breaker will go straight back to the open state and the reset timer will be restarted. Once the service has recovered, calls will start flowing normally again.
Writing all this extra management code would be painful. This library manages it for you instead.
How to use it
Taking advantage of the library is as simple as wrapping your outgoing service call with circuitBreaker.Execute:
// Note: you'll need to keep this instance around var breaker = new CircuitBreaker(); var client = new SmtpClient(); var message = new MailMessage(); breaker.Execute(() => client.SendEmail(message));
The only caveat is that you need to manage the lifetime of the circuit breaker(s). You should create one instance for each distinct dependency, then keep this instance around for the life of your application. Do not create different instances for different operations that occur on the same system.
(Managing multiple circuit breakers via a container can be a bit tricky. I’ve published a separate example for how to do it with Autofac.)
It’s generally safe to add this pattern to existing code because it will only throw an exception in a scenario where your existing code would anyway.
You can also take advantage of built-in retry logic:
breaker.ExecuteWithRetries(() => client.SendEmail(message), 10, TimeSpan.FromSeconds(20));
Why is the package named ReliabilityPatterns instead of CircuitBreaker?
Because I hope to add more useful patterns in the future.
This blog post in picture form
5 Minute Screencast: Stop helping your users. Help yourself.
A few weeks ago I spoke at Web Directions’ What Do You Know event. The event consisted of 10 speakers each doing a 5 minute presentation about some technique or idea that they find useful in web development.
Here’s my talk:
Ros Hodgekis won the night with her awesome email-related talk (all delivered with champagne glass still in hand):
.NET Rocks! #687: ‘Tatham Oddie Makes HTML 5 and Silverlight Play Nice Together’
I spoke to Carl + Richard on .NET Rocks! last week about using HTML5 and Silverlight together. We also covered a bit of Azure toward the end.
The episode is now live here:
http://www.dotnetrocks.com/default.aspx?showNum=687
JT – Sorry, I referred to you as “the other guy I presented with” and never intro-ed you. 
Everyone else – JT is awesome.
Peer Code Reviews in a Mercurial World
Mercurial, or Hg, is a brilliant DVCS (Distributed Version Control System). Personally I think it’s much better than Git, but that’s a whole religious war in itself. If you’re not familiar with at least one of these systems, do yourself a favour and take a read of hginit.com.
Massive disclaimer: This worked for our team. Your team is different. Be intelligent. Use what works for you.
The Need for Peer Code Reviews
I’ve previously worked in a number of environments which required peer code reviews before check-ins. For those not familiar, the principle is simple – get somebody else on the team to come and validate your work before you hit the check-in button. Now, before anybody jumps up and says this is too controlling, let me highlight that this was back in the unenlightened days of centralised VCSs like Subversion and TFS.
This technique is just another tool in the toolbox for finding problems early. The earlier you find them, the quicker and cheaper they are to fix.
- If you’ve completely misinterpreted the task, the reviewer is likely to pick up on this. If they’ve completely misinterpreted the task, it spurs a discussion between the two of you that’s likely to help them down the track.
- Smaller issues like typos can be found and fixed immediately, rather than being relegated to P4 bug status and left festering for months on end.
- Even if there aren’t any issues, it’s still useful as a way of sharing knowledge around the team about how various features have been implemented.
On my current project we’d started to encounter all three of these issues – we were reworking code to fit the originally intended task, letting small issues creep into our codebase and using techniques that not everybody understood. We identified these in our sprint retrospective and identified the introduction of peer code reviews as one of the techniques we’d use to counter them.
Peer Code Reviews in a DVCS World
One of the most frequently touted benefits for DVCS is that you can check-in anywhere, anytime, irrespective of network access. Whilst you definitely can, and this is pretty cool, it’s less applicable for collocated teams.
Instead, the biggest benefit I perceive is how frictionless commits enables smaller but more frequent commits. Smaller commits provide a clearer history trail, easier merging, easier reviews, and countless other benefits. That’s a story for a whole other post though. If you don’t already agree, just believe me that smaller commits are a good idea.
Introducing a requirement for peer review before each check-in would counteract these benefits by introducing friction back into the check-in process. This was definitely not an idea we were going to entertain.
The solution? We now perform peer reviews prior to pushing. Developers still experience frictionless commits, and can pull and merge as often as possible (also a good thing), yet we’ve been able to bring in the benefits of peer reviews. This approach has been working well for us for 3 weeks so far (1.5 sprints).
It’s a DVCS. Why Not Forks?
We’ve modelled our source control as a hub and spoke pattern. BitBucket has been nominated as our ‘central’ repository that is the source of truth. Generally, we all push and pull from this one central repository. Because our team is collocated, it’s easy enough to just grab the person next to you to perform the review before you push to the central repository.
Forks do have their place though. One team member worked from home this week to avoid infecting us all. He quickly spun up a private fork on BitBucket and started pushing to there instead. At regular intervals he’d ask one of us in the office for a review via Skype. Even just using the BitBucket website, it was trivial to review his pending changesets.
The forking approach could also be applied in the office. On the surface it looks like a nice idea because it means you’re not blocked waiting on a review. In practice though, it just becomes another queue of work which the other developer is unlikely to get to in as timely a manner. “Sure, I’ll take a look just after I finish this.” Two hours later, the code still hasn’t hit the central repository. The original developer has moved on to other tasks. By the time a CI build picks up any issues, ownership and focus has long since moved on. An out-of-band review also misses the ‘let’s sit and have a chat’ mentality and knowledge sharing we were looking for.
What We Tried
To kick things off, we started with hg out. The outgoing command lists all of the changesets that would be pushed if you ran hg push right now. By default it only lists the header detail of each changeset, so we’d then run though hg exp 1234, hg exp 1235, hg exp 1236, etc to review each one. The downsides to this approach were that we didn’t get colored diff outputs, we had to review them one at a time and it didn’t exclude things like merge changesets.
Next we tried hg out -p. This lists all of the outgoing changesets, in order, with their patches and full colouring. This is good progress, but we still wanted to filter out merges.
One of the cooler things about Mercurial is revsets. If you’re not familiar with them, it’d pay to take a look at hg help revsets. This allows us to use the hg log command, but pass in a query that describes which changesets we want to see listed: hg log -pr "outgoing() and not merge()".
Finally, we added a cls to the start of the command so that it was easy to just scroll back and see exactly what was in the review. This took the full command to cls && hg log -pr "outgoing() and not merge()". It’d be nice to be able to do hg log -pr "outgoing() and not merge()" | more but the more command drops the ANSI escape codes used for coloring.
What We Do Now
To save everybody from having to remember and type this command, we added a file called review.cmd to the root of our repository. It just contains this one command.
Whenever we want a review we just type review and press enter. Too easy!
One Final Tweak
When dealing with multiple repositories, you need to specify which path outgoing() applies to in the revset. We updated the contents of review.cmd to cls && hg log -pr "outgoing(%1) and not merge()". If review.cmd is called with an argument, %1 carries it through to the revset. That way we can run review or review myfork as required.
Released: SnowMaker – a unique id generator for Azure (or any other cloud hosting environment)
What it solves
Imagine you’re building an e-commerce site on Azure.
You need to generate order numbers, and they absolutely must be unique.
A few options come to mind initially:
- Let SQL Azure generate the numbers for you. The downside to this approach is that you’re now serializing all of your writes down to a single thread, and throwing away all of the possible benefits from something like a queuing architecture. (Sidenote: on my current project we’re using a NoSQL graph DB with eventual consistency between nodes, so this wouldn’t work for us anyway.)
- Use a GUID. These are far from human friendly. Seriously, can you imagine seeing an order form with a GUID on the top?
- Prefix numbers with some form of machine specific identifier. This now requires some way to uniquely identify each node, which isn’t very cloud-like.
As you can see, this gets complex quickly.
SnowMaker is here to help.
What it does
SnowMaker generates unique ids for you in a highly distributed and highly performant way.
- Ids are guaranteed to be unique, even if your web/worker role crashes.
- Ids are longs (and thus human readable).
- It requires absolutely no node-specific configuration.
- Most id generation doesn’t even require any off-box communication.
How to get it
Library: Install-Package SnowMaker
(if you’re not using NuGet already, start today)
Source code: hg.tath.am/snowmaker or github.com/tathamoddie/snowmaker
How to use it
var generator = new UniqueIdGenerator(cloudStorageAccount);
var orderNumber = generator.NextId("orderNumbers");
The only caveat not shown here is that you need to take responsibility for the lifecycle of the generator. You should only have one instance of the generator per app domain. This can easily be done via an IoC container or a basic singleton. (Multiple instances still won’t generate duplicates, you’ll just see wasted ids and reduced performance.) Don’t create a new instance every time you want an id.
Other interesting tidbits
The name is inspired by Twitter’s id generator, snowflake. (Theirs is more scalable because it is completely distributed, but in doing so it requires node-specific configuration.)
Typical id generation doesn’t even use any locks, let alone off-box communication. It will only lock and talk to blob storage when the id pool has been exhausted. You can control how often this happens by tweaking the batch size (a property on the generator). For example, if you are generating 200 order ids per server per second, set the batch size to 2000 and it’ll only lock every 10 seconds.
Node synchronisation is done via Azure blob storage. Other than that, it can run anywhere. You could quite easily use this library from AppHarbor or on premise hosting too, you’d just wear the cost of slightly higher latency when acquiring new ids batches.
The data persistence is swappable. Feel free to build your own against S3, Ninefold Storage, or any other blob storage API you can dream up.
The original architecture and code came from an excellent MSDN article by Josh Twist. We’ve brushed it off, packaged it up for NuGet and made it production ready.
Under the covers
SnowMaker allocates batches of ids to each running instance. Azure Blob Storage is used to coordinate these batches. It’s particularly good for this because it has optimistic concurrency checks supported via standard HTTP headers. At a persistence level, we just create a small text file for each id scope. (eg, the contents of /unique-ids/some-id-scope would just be “4”.)
One issue worth noting is that not all ids will always be used. Once a batch is checked out, none of the ids in it can ever be reallocated by SnowMaker. If a batch is checked out, only one id is used, then the process terminates, the remaining ids in that batch will be lost forever.
Here’s a sequence diagram for one client:
Here’s a more complex sequence diagram that shows two clients interacting with the store, each using a different batch size:
CSS Quiz
I love Dmitry Baranovskiy’s occasional #jsquiz challenges on Twitter.
Taking this idea and applying it to CSS, today I launched: cssquiz.com
You’ll get one question a week, open for 72 hours, then the full solution posted.
Of course, all feedback and question ideas welcome. (Best to send question ideas via email so we don’t spoil them.)
