Running a business is nothing if not a learning experience. Every day presents a situation that you haven’t encountered before, and you have to be ready to shift your perspective and learn quickly in order to adapt. Here are a few tidbits of information that I’ve learned (sometimes the hard way) so far as we’ve been running Zen.

Save more information than you think you’ll need.

Disk space is cheap, and it’s much more difficult to migrate (or generate) missing data after-the-fact than it is to collect it when something happens. At a minimum, you should have a transaction table that captures everything that happens in your system. That way, you can always use this table as a last resort to create new data if you need to in the future. Be sure to listen when your conscience says YAGNI, but never trade off knowledge for extra disk space.

Soft-delete everything.

Instead of actually deleting information from your database, just flag it with a “tombstone” and leave the record there. Not only does that allow you to recover data if a user accidentally deletes it, but maintaining the relationships between entities makes managing the data much simpler. Sure, you end up with stale data in your database, but you can always prune it after a certain period of time to clean things up – and since this pruning operation takes place out-of-band, if it doesn’t work perfectly your users aren’t bothered by it.

Don’t underestimate the cost of meta-work.

Not everything that is necessary is customer-facing, or even directly related to the product. I refer to work that’s important, but not quite value-adding, as meta-work. For example, one of the most complex parts of the Zen codebase is actually the billing system – customers don’t interact with it directly, but they would definitely be upset if Zen randomly billed their credit card! The most important parts of your product are usually the parts that no one knows exist – that is, until they don’t work the way they should. :)

Don’t skimp on administrative software.

Information is power, so make sure your system tells you when things happen. Write reporting and management screens. Make your software send you emails when things happen. Balance this against the previous point, but just because something isn’t customer-facing doesn’t make it wasteful – if an administrative screen or report helps you to serve your customers better, it adds real value. Don’t do too much up front; instead, wait until you recognize opportunities to improve your operations, and pick the low-hanging fruit.

Just a few random thoughts. :)

I had originally left off the name of the person I was talking about because this post isn’t intended to make him sound like a bad guy. However, he felt I wasn’t being conversational, so the person that triggered this post is Sebastien Lambla, author of OpenRasta. Read his response here.

I caught some flak on Twitter today for releasing Siesta as open source. It was the same song that I heard when I wrote Ninject, which was: why are you reinventing the wheel? Normally I shake that sort of thing off, but once I found out that the person complaining was the author of a “competing” REST framework, it ruffled my feathers a little bit.

Siesta originated as part of Zen. Implementing REST is not a difficult problem, and I’ve done it before. (Most of the difficulty is in mapping HTTP requests to method calls, which ASP.NET MVC handles for you.) Since I knew exactly how I wanted it to work, and had a reasonable idea of how to implement it myself, I just sat down and wrote it.

Could I have used an existing open-source framework? Sure, but I’d never heard of any other than WCF REST, which I already knew didn’t match my mindset. I searched for a little while on Google to find other libraries, but didn’t find anything. I’d also argue that REST is so low-level that it would be very difficult to come up with a clean drop-in solution – that’s why I suggested that Siesta is more an example of how to write a REST system than it is a reusable framework.

I believe very strongly in not falling prey to the Not Invented Here syndrome. Like I said in my previous post, Zen uses a myriad of open source libraries:

• Argotic
• DynamicProxy
• ELMAH
• Fluent NHibernate
• LinqToTwitter
• log4net
• jabber-net
• JSON.NET
• Markdown.NET
• Migrator.NET
• Moq
• NHibernate
• Ninject
• NUnit
• Quartz.NET
• Spark

I’m all about standing on the shoulders of giants. :) However, rolling your own is not always waste. The bits that became Siesta took me about a total of 4-5 hours to implement end-to-end. That’s much less time than it would have taken me to find a framework, understand how to use it, evaluate whether it would work for what I needed, and integrate it into Zen.

Like I said, I’ve written several RESTful systems before, using MonoRail and raw IHttpHandlers – but none of them belonged to me, so I couldn’t open source them. Because I already understood the problem well, it was actually less expensive for me to write my own implementation.

As the owner of a startup, I have to justify the value of everything that I do to ensure that I’ll get a decent return on investment. In order for me to consider using an external framework, I have to be relatively certain that I’ll save time by using it in the long term. This leads me to my point:

It’s not my fault if I don’t know about your product. It’s your fault.

If you don’t market your product well enough for me to know about it, and I can’t even find it when I’m looking for it, it’s never going to get on my radar. It doesn’t matter if your product is free and open source or costs thousands – if I even don’t know it exists, how in the world am I supposed to make the difficult decision to use it?

That’s my first problem with the complaints about Siesta. My second problem is this: I spent my time and money to develop the part of Zen that became Siesta, and because other people have previously asked me for help on the topic, I’m happy to share it with anyone that’s interested, free of charge.

It’s my code, and I’ll do what I damn well please with it.

I haven’t always thought this way, but these days I don’t care much about mindshare or competition in the open source space. I spend enough time competing on my commercial endeavors, which have the distinction of putting food on my table. Open source is something I do because I want to help.

Siesta’s not perfect and it’s not the only solution, but it represents the way I think a REST system should be implemented. If you don’t like it, don’t use it. Even better, tell me what you don’t like about it so I can learn from your perspective just as you can learn from mine.

The goal of open source is not to develop a single solution that can be used in all situations. In fact, it’s the opposite: open source thrives on competition. If you feel threatened because someone else releases something that you perceive as competition, maybe you should rethink why you’re working on open source in the first place.

Related posts:

1. Microsoft Supports Open-Source Software
2. Siesta: Painless REST via ASP.NET MVC
3. Open Source, and Passionate Developers

Zen uses quite a few open source libraries, and I feel a sense of responsibility to contribute back where I can. To that end, I’m releasing the basic infrastructure that powers the Zen API under the name Siesta.

Siesta is a simple and flexible REST system driven by ASP.NET MVC. While you can take the Siesta bits and use them directly in your app, it’s intended more as an example of how to implement your own system.

The basic idea behind Siesta is to communicate only using models within your application, and allow the infrastructure to handle the serialization and de-serialization, similar to how a view engine manipulates ViewModels or ViewData. Models are just POCOs, and serialization is controlled the [DataContract] and [DataMember] attributes in System.Runtime.Serialization (so yes, this requires .NET 3.5).

Siesta also uses the (sweet-with-extra-awesomesauce) JSON.NET library from James Newton-King. There’s a DataContractJsonSerializer in the BCL now, but as far as I could tell, it doesn’t support indentation. JSON.NET supports both, so it’s a great fit. I’ve also been using it forever, so I’m just used to it – if you deal with JSON formatting, it’s definitely worth a look.

The wire (serialization) format is based on MIME types, and Siesta comes with XML and JSON built-in. However, it’s also extensible by implementing a new IModelSerializer. Speaking of which, if someone wants to implement one for YAML, it would be greatly appreciated. ;)

As described in the Zen API documentation, the wire format is determined by the Content-Type and Accept headers. Content-Type is preferred for incoming data, and Accept is preferred for outgoing data. If a header is missing, the system will fail over to the other one.

Here’s an example of an entity that can be serialized via REST:

[DataContract(Name = "user", Namespace = "")]
public class User : IEntity
{
  [DataMember(Name = "id")]
  public int Id { get; set; }

  [DataMember(Name = "username")]
  public string UserName { get; set; }

  [DataMember(Name = "name")]
  public string Name { get; set; }

  [DataMember(Name = "email")]
  public string Email { get; set; }
}

And its matching controller:

public class UserController : SiestaControllerBase
{
  public IRepository<User> UserRepository { get; private set; }

  public UserController(IRepository<User> userRepository)
  {
    UserRepository = userRepository;
  }

  public ModelResult<User> Get(GetRequest request)
  {
    User user = UserRepository.Get(request.Id);

    if (user == null)
      throw NotFound();

    return Model(user, request.Formatting);
  }

  //...
}

Don’t worry, SiestaControllerBase is just a simple base controller which provides the Model() method shortcut. This (and the IEntity interface you might have noticed on User) are entirely optional, and are actually part of the Siesta.Example assembly rather than the main Siesta assembly. As long as the types you want to communicate with are serializable, they’ll work with Siesta.

In contrast to the Siesta example, in Zen, we actually have separate models (which act as DTOs, and are serialized to/from a wire format) and entities (which are persisted to the database). The example doesn’t show this because it requires a whole separate mapping step, which can get tricky. I would highly recommend that if you use this in a real-world app, you create a separate type hierarchy and map between them.

Anyhow, you can grab the Siesta bits on GitHub, including the full version of this (simple) example. If you have feedback, by all means let me know! There’s actually quite a bit of stuff in Zen that I’d like to release as OSS – it’s just a matter of getting the time to split the code off the product and wrap it up.

Related posts:

1. Functional Magic
2. Open Source is not a Zero-Sum Game
3. Frameworks and the Break-Even Point

Earlier this week, the UPS delivery guy surprised me with a copy of Beginning ASP.NET MVC 1.0 by Simone Chiaretta and Keyvan Nayyeri. I haven’t had a chance to read much more than just a brief skim of it so far, but I had an opportunity to review some of the content before it was published. What I’ve seen looks great, and I don’t just say that because it talks about Ninject. ;) I plan to dig into it further when I can scrounge a few minutes.

Congratulations to Simone and Keyvan for finishing the book and getting it published! It looks like a great resource for aspiring ASP.NET MVC developers.

If you want to learn more, you can check out Simone and Keyvan’s posts.

Related posts:

1. Reboot!

In addition to working hard to improve Zen, I’ve also been talking about it to anyone that will listen. :) I’ve been fortunate enough to be featured on a few podcasts over the past few weeks to discuss lean, kanban, and Zen:

First, Scott Hanselman had me on Hanselminutes in mid-July. This conversation was a quick introduction about lean and kanban, with a few tidbits about Zen sprinkled in. I already mentioned this before, but the post was a 30-second-hurry-up-and-publish-and-then-get-back-to-grinding-out-code, so I figured I’d do it a bit more justice. :)

Then, the guys at Herding Code had me on to talk about the technology behind Zen, and the process of launching a company. This turned into a great conversation, although I wasn’t quite lucid by the end. (I’m not sure you can tell by listening, but I’d put in 16 hours that day and by the end of recording, it was 1:30AM EST!)

Last, but certainly not least, I was featured on .NET Rocks, where I talked with Carl and Richard about the idea behind Zen and my best understanding of lean and kanban. This was the first time I was on .NET Rocks, and I think it turned into a great conversation.

That’s all the podcasts that I’ve recorded so far, and without something new to talk about, I’m not sure I want to do too many more. I’m sure the audiences of the podcasts overlap, and by now I must be starting to annoy people. If so, sorry about that! :)

Anyhow, a huge thanks to the hosts of the podcasts, and everyone that listened. I’m obviously excited about this stuff, and I hope after listening to me ramble, others get excited about it too.

Related posts:

1. Hanselminutes

As you’ve probably noticed (well, unless you’re reading the RSS feed), I’ve rebooted my blog. It was a long time coming, really. I’ve always preferred clean user interfaces and good user experience, and well, the old design didn’t quite fit the bill. :) I’ve been wanting to fix things up for a long time, but I could never quite get it to a high enough priority.

Today, I was finally able to scrounge some time to clean up old posts and customize a new theme. This involved going back and ripping out the crappy HTML generated by whatever code snippet plugin I was using for Windows Live Writer back in 2007…ugh. Going back through my old posts was sort of like going through a bizarro time machine. It’s amazing how much my mindset has shifted since I first started blogging.

So, what do you think of the new look? There’s still some things that need tweaked here and there, but overall I’m really liking it. Let me know if you see anything off kilter.

In case you missed it yesterday, Scott Hanselman was nice enough to have me on Hanselminutes to talk about lean, kanban, and Zen. I think it turned into a pretty good conversation, so go have a listen!

Related posts:

1. The Media Blitz Continues

It’s been about a year since the ideas for Zen started to gel in my mind. After more long nights and working weekends than I can count, I’m proud to announce that Zen is open to the public! I’d like to thank everyone for their support, especially those that tinkered with the product during the beta process – your feedback was absolutely invaluable.

I’d also like to extend a special thanks to James Avery, Mike Eaton, Jayme Davis, and Sean Chambers. They not only used the application since the days of the first alpha, but also through their constant heckling, convinced me to work on it in the first place, and helped me through the dip to get the product to launch.

Finally, I’d like to thank my beautiful and brilliant wife, Nicole, for signing up to ride this rollercoaster with me. I couldn’t do it without you.

So what are you waiting for? Go sign up for Zen! :)

July 1st came with a great surprise, as I was named a Microsoft C# MVP for 2009! If you’re not familiar with the award, here’s a blurb from their website:

Microsoft Most Valuable Professionals (MVPs) are exceptional technical community leaders from around the world who are awarded for voluntarily sharing their high quality, real world expertise in offline and online technical communities. Microsoft MVPs are a highly select group of experts that represents the technical community’s best and brightest, and they share a deep commitment to community and a willingness to help others.

Although it’s overshadowed a bit by my excitement about the imminent launch of Zen, I’m thrilled to receive the award. Thank you to all the existing MVPs that nominated me, and congratulations to those who were renewed and other freshman MVPs, including Mike Eaton, John Stockton, and Sarah Dutkiewicz.

(And yes, the title is a joke. Totally kidding.)

Related posts:

1. Microsoft Supports Open-Source Software
2. IronRuby and a Paradigm Shift at Microsoft

One of the most often-overlooked and easy to fix things encountered when developing a hosted software application is the management of local time. First and foremost, you should be storing timestamps in your database in UTC. I don’t care if your users are all in the same time zone now, or your app is just a local deployment, or whatever other excuse you have for storing time as local time. Always store timestamps in UTC. Do it now, and pat yourself on the back a year from now when you realize whatever reason you had for storing it as local time was irrelevant or has changed. :)

Okay, so once you’ve got your timestamps stored in UTC, you need to localize them for each individual user, which means you need their offset from UTC. For example, Eastern Standard Time, my time zone, is UTC-5. The most common thing that I’ve seen is to provide users with a massive dropdown of a bajillion time zones, and ask them to pick which one they’re in.

Maybe it’s just a pet peeve, but I hate it when sites ask me to pick my time zone. What about users who travel often? What about daylight savings time? Do I make my users go in and change their time zones when DST starts and stops? Do I write extra code to figure out if it’s DST in the user’s time zone? That’s pretty much impossible, at least in the US, because it’s not recognized in Hawaii, Arizona (except in the Navajo Nation), and some counties in middle America.

While I was building Zen, I was determined to avoid making users have to choose their time zone if I could avoid it. I realized that the client computer knows what time it is, and what time zone they’re in, so it’s pretty simple to read it with Javascript. Here’s how you can grab the client computer’s UTC offset:

new Date().getTimezoneOffset() / -60

Now, all that remains is to push that information back to the server and make sure that it’s updated often. Zen’s login form has a hidden input called timezoneOffset, which is set using jQuery when the page is displayed:

$(document).ready(function() {
  $("#timezoneOffset").val(new Date().getTimezoneOffset() / -60);
});

Now, when the form is posted, I read the UTC offset from the hidden input, and store it in the user’s record in the database. This means that each time the user logs in, their time zone information is updated to be current. This helps not only with the daylight savings time problem, but also ensures that Zen will respond to changes in the user’s computer clock. If a user travels from EST to PST, for example, and they change their computer clock, Zen will recognize the change and update the timestamps appropriately.

Then, each time I need to display a timestamp to a user, I call a method on my TimeHelper (a custom ASP.NET MVC view helper, like the built-in HtmlHelper and UrlHelper):

public TimeHelper
{
  public User User { get; private set; }

  public TimeHelper(User user)
  {
    User = user;
  }

  public DateTime GetLocalTime(DateTime utc)
  {
    DateTime local = utc.AddHours(User.TimezoneOffset);
    return new DateTime(local.Ticks, DateTimeKind.Local);
  }
}

Just another trick to keep in your bag. :)

Related posts:

1. Functional Programming and Database Access