So how do you build a KitchenPC anyhoo?

One thing I’ve been dealing with, as has every dot-com startup, is deciding what technology to use for implementing my web site.  There’s soooo much out there, be it trendy new things like Ruby on Rails, or proven platforms like PHP, perhaps Java if you’re into that sort of thing, or .NET if you’re a fan of the Microsoft stack.  They’re all good, and they’ve all been proven, and they all have their strengths and weaknesses as well as fans and critics.

Early on, I decided as a poor startup, I needed to make use of open-source projects.  I simply didn’t have the time to invent everything myself, or the money to purchase commercial platforms.  Open-source projects not only offered the advantage of being free, they provided the ability to be modified if I ran into some annoying bug or limitation.  I also didn’t want to limit myself to a certain operating system or web server, as I haven’t made the decision yet on where KitchenPC will be hosted; be it a cloud environment like Amazon EC2, or a single dedicated server with a company like Rackspace.

This post will give a brief overview of the technology stack employed at KitchenPC currently.  I’m not saying it’s the best choice, or that none of it will change, just what I’ve learned so far.

So I’ve been using .NET since about 2000, before it was even called .NET.  I know C# better than any other language, and feel comfortable building scalable, enterprise level software on the .NET platform.  On the Windows Server platform, I don’t think anything runs better than .NET.  Though I’d love to check out things like Ruby on Rails or go learn Java (which wouldn’t be too much of a stretch), I felt to get something up on the web quickly I needed to stick with a language and platform I knew like the back of my hand.  One project I’ve been extremely interested in is the Mono project sponsored by Novell.  Mono (I believe pronounced with a long o, like Spanish for “monkey”, and not the disease,) is an open source implementation of the .NET framework and compilers.  I’ve been following this one for quite a while, as it would provide the ability to run on an open-source operating system such as Linux.  Down the road, this could save me quite a bit of money on software costs and would actually make KitchenPC a complete open-source shop.  Mono has progressed leaps and bounds over the last couple years, and is almost to the point where I’d consider it for production use.  But I just can’t say it’s there yet.  MonoDevelop, their development environment, is making huge progress, especially with the recent release of 2.4, but the debugger is still clunky and doesn’t allow me to really do what I want.  It doesn’t integrate seamlessly in with script code running within the web browser and lacks the raw power of Visual Studio.  Also, I fail to trust the scalability of the Mono runtime.  They still yet to have a modern garbage collector that’s compacting and generational (though 2.8 should have this!) and I don’t think the platform has really been proven in any “real” production environment.  At this point, I’d rather pay for Visual Studio and lease Windows servers to run on.  However, I still have hope that Mono will someday present itself as a viable choice to run KitchenPC off of.

For a database server, I’ve had better luck.  Most of my experience has been with Microsoft SQL Server, as I’ve been using that since SQL Server 7.0.  Of course, that sucker’s insanely expensive.  Well, ok not Oracle expensive but still.  The main two choices for open source relational database systems are mySQL and PostgreSQL.  mySQL is probably more well known, but is definitely not for everybody.  mySQL and Postgres have two radically different philosophies when it comes to the role of a database.  mySQL seems to believe databases should be dirt simple, like a file system.  Until fairly recently, mySQL didn’t really have the concept of foreign keys or transactions or stored functions/procedures.  This was all up to the business layer to take care of.  One of the main drawbacks of mySQL, for me anyway, is there was no native support for a uuid datatype.  I have no idea if this is the still the case, but I’m a strong believer that keys should be generated outside the database and passed in.  This makes transactions simpler, replication less error prone, and plus you instantly know the key in code and can do other things with it programmatically.  Sure, mySQL could just use a string to store a uuid, but this could of course have performance impacts as now you’re looking up a row by a string value instead of just a 128-bit number.  So that was annoying.  When I found Postgres, I immediately fell in love with it.  In fact, to this date I believe it’s probably my favorite open source project of all times.  Postgres is more aligned with my own feelings on database design, and is considered by some to by an open source implementation of Oracle.  It has a single table engine that everyone works on and supports everything.  It’s insanely extensible, I’ve even heard of people writing their own index types for it.  One of the things that really sold me on it was the fact that is has a native “array” type.  If I have a list of recipes I need to load into memory, I can pass in an array of uuids into a function and return only those rows.  This was something that was a complete pain to do even in Microsoft SQL.  You would have to pass in a comma delimited list, parse that in a stored procedure, create a temp table, and JOIN on that.  No thanks!  Data types in Postgres are just designed in a way that makes sense to me from the ground up.  I can create my own data types, I can create enums, and every function must return one of these data types, or a complete row matching a table schema, or define exactly what data it returns.  Nothing is “loosely typed” as is the case in other database systems I’ve used.  Another thing that sold me on Postgres was the awesome technical support offered through their mailing lists.  I remember I once had a question on why an index was not being used when, to me, it obviously should be.  I think my email was even a little bit rude, as if Postgres was flawed.  Tom Lane, one of the main contributors who also works on performance, replied within ten minutes with a very friendly and very detailed response on why Postgres was not using the index.  In this case, it wasn’t being used since it knew based on the table statistics that most rows would be returned anyway, so it might as well just do a sequential scan.  Tom was right.  I was wrong.  I’ve also seen someone post a question about how to get something working in mySQL!  The arch rival of Postgres!  Surely this was a troll, but someone actually took the time to come up with a detailed answer and was still very friendly and professional.  To this day, every time I have a Postgres question I get a detailed and helpful response.  I don’t have to pay any money for this support, these guys just want their platform to be the best.  Postgres has also proven itself in production environments.  Skype is backed by Postgres, as is IMDB.  Yahoo! has some multiple petabyte database with a modified version of Postgres.  I’m definitely sold on Postgres and think it’s the right choice for KitchenPC, and I’ve been able to really take advantage of some of its features for a database design I’m really proud of.  I could probably start a blog about how much I love Postgres.  Oh and man I can’t wait until 9.0, it’s gonna have streaming replication and all sorts of cool new stuff!

Another open source project I’m quite fond of is Castle ActiveRecord.  It’s an implementation of the Active Record pattern built on NHibernate (a .NET port of Java’s Hibernate.)  ActiveRecord makes representing your database in code very easy and almost fun.  You have a class that represents a table.  An instance of that class represents a row in that table.  The class has static methods to find rows, delete rows, etc.  If you want to add a new row, you just new up an instance of your class, set whatever properties you want (which map to columns), and call the Create method.  All the mapping between the class and table is extremely flexible.  I’ve even gotten Postgres enums to map seamlessly over to .NET enumerated data types.  The drawback I’ve found is it presents the possibility of not very efficient queries being generated.  If you’re crafting queries by hand, you can finely tune them to be as fast as possible for your database design.  Due to NHibernate’s flexibility, it’s possible to work around these limitations with enough custom code, but so far I’ve ran into many hurtles in this area.  Never the less, I’m a fan of this project and it’s saved me a ton of time not having to write my own database interfaces or use ADO.NET.

Finally, on the client I’ve decided to employ Yahoo!’s “YUI” toolkit.  I insist that it shall be pronounced “Yooey” similar to “GUI”, but Yahoo! disagrees, though they admit this pronunciation is popular outside Yahoo!.  YUI is a framework for creating web UI.  It does stuff for you such as popup divs, autocomplete text boxes, tab controls, animations, etc.  It also abstracts the DOM to hide a lot of those cross-browser annoyances (which I’m sure I will blog about frequently).  The thing I like most about it is it’s 100% Javascript files.  It doesn’t care what backend you use (unlike Microsoft’s framework) or what web server you’re on (you don’t even need to have a web server), it just works.  It’s also very well documented, has support groups, has a unit testing framework, and has been tested at length in production.  It’s also obvious from the design that these guys really know the Javascript language and have written this platform from the ground up to really take advantage of Javascript’s “functional” roots.  Data is usually passed is as object maps, many parameters take references to functions, etc.  The API is also nicely organized into namespaces which make sense.  It’s componentized, so you only include the Javascript files for the features you want to use.  All the UI is skinnable so your site doesn’t have to look like Yahoo!’s web apps (which aren’t too visually appealing in my opinion), and it’s easy to override behavior if you don’t like something.

YUI has saved me a ton of time, except I do have to admit I decided not to use their rich text editor.  After dealing with limitations like the inability to accurately detect when the editor becomes dirty, and the inability to control how HTML gets generated (I want XHTML 1.0 with no inline styles!), I decided to switch to TinyMCE.  TinyMCE is the rich text editor I’m using right now to type this post, as it’s the RTE of choice for WordPress.  It’s extremely flexible, extremely powerful, and just seems to work the way I want.  I replaced YUI’s text editor in no time, and wrote a few lines of code to describe exactly how I wanted the output to be formatted.  I’m definitely a fan.

For “process” type stuff, I’m using the normal arsenal.  I use Subversion for all change tracking, NUnit for unit testing and NAnt for build scripts.  For bug tracking, I was using Bugzilla until I got annoyed by it and switched to Mantis, as per the advice of a friend.  I’m not 100% in love with Mantis, but haven’t found anything better yet.  I’m using using TWiki to help manage content, and LimeSurvey for my survey software, both which I host myself.

Time is sparse right now, but there’s a whole list of projects I’ve been meaning to check out.  Memcache is one of them (I don’t really have any caching story right now, besides what Postgres offers out of the box) and Lucene to improve recipe searches.  There’s also more Castle stuff to check out.  Perhaps one of these days.

The open source community is definitely a wealth of resources for small companies just starting out like myself.  I find the quality good on most of the major projects, and help fairly easy to come by.  I’m hoping some day, I’ll have the resources to give back to these projects by contributing features, fixing bugs, and perhaps even open-sourcing some of the KitchenPC framework itself.

Mike