Recently, I integrated OpenID into the latest revision of the Cub Scout BragVest site and I think it’s truly the wave of the future. But, as of yet, it’s a highly underutilized technology so I wanted to give a brief overview of it here.

What is it?

The OpenID site has a good description to start with:

OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords. With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password

So let’s unwrap this. In a nutshell, OpenID allows you to use your existing accounts at big sites (like Google, Yahoo, MySpace, Hotmail, Facebook and Twitter) to login to other sites. All without creating a new username and password.

You are simply redirected to the site of your choice to login and then securely redirected back to the original site with an authentication token. The original site never sees your password.

What Problem Does it Solve?

Imagine that you find a cool new site (like BragVest) and you want start tracking your cub scout achievements. But you don’t want to create yet another login and password. With OpenID you can login to that site using your existing account at Facebook or Google account. 

It also means that you instantly have an account at the new site. No need to go through a new account creation or email verification process. Pretty cool, huh?

How Do I Use It?

The simplest way to get started with OpenID is to use a widget like the one provided by RPX Now. It’s free for basic use and lets you choose up to six “providers” (Google, Yahoo, etc).

To get going, you just go to RPX now and create an account. Then they walk you through the following three steps:

1. Generate Widget Code: RPX provides you with the code for a simple iFrame that displays their widget inline on your page.  It’s used to let the user select their provider in a user-friendly format.
2. Receive Tokens: After the user has been authenticated on their favorite site, you will receive a token value. You use that token to make auth_info call and retrieve more data (email, username, etc) about the user. RPX provides you with sample code to do this in a variety of languages.
3. Choose Providers: On the RPX site, you can choose which providers (Yahoo, Facebook, Google, etc) that you’d like their widget to display.

After that, you’re done!  I’m hoping to see more sites start utilizing openID so I can stop having to remember so many usernames and passwords.

I’m a longtime ASP.NET developer, and indeed that’s how I’ve made my professional living for many years now, but I have to say there is a lot to love about Ruby on Rails.
There’s a simplicity and common sense approach that I really like.

I think other ASP.NET developers would enjoy certain aspects of Rails as well, so I put together a list of my 5 favorite things (in no particular order):

1) Migrations

If you’re like me, you really don’t like writing database change scripts in SQL. Wouldn’t it be nice if you could write the scripts in your favorite programming language rather than resorting to T-SQL? Well, with rails migrations you can!

You write your schema changes as a ruby class (or even generate them) and run it at the database to modify your schema. For example, to create a posts table, on the command line just type:

$ script/generate model Post name:string content:text

This will automatically generate the required class for you which looks like this:

class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|
      t.string :name
      t.string :title
      t.text :content

      t.timestamps
    end
  end

  def self.down
    drop_table :posts
  end
end

Then you just run “rake db:migrate” at the command line and your table is created. The framework even keeps track of which migrations have been run and versions them all so you can roll back to previous DB versions at any time.

2) Active Record

I love how active record does not force you to model out all your fields as properties. You simply build your table with migrations and then create a class of the same name that derives from ActiveRecord and Rails figures out the rest. No config files to set up or angle brackets to mess with.

It adds all the properties based on the table columns and a bunch of helper methods for finding records and working with the dataset, but your code is as simple as this:

class Post < ActiveRecord::Base
end

3) Opinionated

With Rails a lot of decisions are made for you and that’s a good thing! Instead of endlessly debating which of the 10 ORMs to use for your data layer, you just use Active Record because that’s what’s built-in out of the box and works for 90% of the cases.

Rails has a specific way of doing things, and if you buy into it, you can let the framework take care of a lot of the little details for you.

4) Lightweight

There’s something wonderful about not having to fire up a huge IDE to do development. Just launch your favorite text editor and start writing code. My personal preference for writing Rails code on windows is the E-TextEditor (which is modeled after TextMate), but I could just as easily use notepad++. 

This simply would not be possible with ASP.NET as there are just too many frameworks and libraries to deal with as well as just a lot of code to write that you almost need the IDE’s help to sort them all out. Not to mention, you need the IDE to compile your code (or the cmd line with hundreds of switches) which is not necessary in the the interpreted world of Ruby. The code and run cycle is almost instantaneous.

5) Less Code

After porting an ASP.NET MVC app to rails I was amazed with how little code it took in rails. The rails version was only about 25% of the code that was required for the ASP.NET MVC version.So, how is that possible?

Much of this is due to Active Record and the fact that I didn’t have to write any DB connector code, but also Ruby’s terse syntax and lack of strong typing just means that the amount of code you write is much less.

For example, a typical controller method in Rails looks like this:

  def show
     @post = Post.find(params[:post_id])
  end

And then @post is automatically visible in the corresponding view. Nice and elegant – the way coding should be.

Lately I’ve been reading Seth Godin’s Linchpin. It’s an excellent book and the key point is that your work should be a platform for art:

Art [in this context] is a personal act of courage, something one human does that creates change in another. … I think it’s art when a great customer service person uses a conversation to convert an angry person into a raving fan. And it’s art when Craig Newmark invents a new business model that uses the Internet to revolutionize classifieds." …

Godin really expands the traditional definition of “art”; It doesn’t have to just be a painting that you hang on a wall, but it’s something that you create which directly impacts another in a dramatic and positive way.

Given that I’m a programmer, It makes me wonder in what ways programming and it’s output can be considered art– Is twitter art? What about facebook?

According to Godin, both of those sites would be art. They are unique and they have profoundly impacted people (as opposed to most software).

So a software product can be art, but what about an individual piece of code. Can that be art?

Obviously, O’Reilly thinks so given that they’ve published a book on the topic of beautiful code. I have to agree that some code and frameworks (eg - jQuery and Rails).are so elegant and  well-written that they are a true joy to work with.

It seems odd at first to be to lump programmers in with artists. Aren’t they two totally different types of people – one left-brained and the other right-brained? Yet, in many ways, they’re closer than you think.

Hackers and Painters

Paul Graham nailed this strange dichotomy in his classic essay entitled Hackers and Painters:

Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

At the end of the day, both are craftsman.

I can appreciate this more than most because I actually studied art and computer science in school. Both held great appeal for me and most likely for similar reasons:They both allow you to perform solitary acts of creation.

Software Craftsmanship

In fact, there’s a powerful new movement in software focusing on craftsmanship – they even have their own manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

This movement is largely a reaction to offshoring and businesses trying to treat software developers as replaceable cogs. The movement focuses more on individuals and their specific skills. These software craftsmen strive to create not just software that meets spec, but hand-crafted pieces of art.

Seth Godin would be proud.

The Battle Cry

There’s a new revolution brewing in the software industry, and it goes something like this…

For too long software developers have been oppressed by the tyranny of relational database! Are they really the right tool for every job? Should we really have to map our OO code to a relational DB?

Now the time has come to throw off those shackles and enter the free world of NoSQL! Who’s with me?…<sound of crickets chirping>

Ok. So maybe people aren’t quite ready to join the revolution yet, but let’s dig into this new movement and understand what it it.

What is it?

According to Wikipedia, NoSQL is:

an umbrella term for a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees. Data stores that fall under this term may not require fixed table schemas, and usually avoid join operations. The term was first popularised in early 2009.

In other words, it’s not: SQL Server, mySQL or Oracle — the leading relational database engines in the market.

By contrast, NoSql databases usually involve persisting objects to the database through key-value pairs, XML and/or JSON. They are often called document databases or object-oriented databases.

The benefits are primarily two-fold:

• Developer Efficiency: Because you don’t need to map your objects to database tables, the classic object-relational impedance mismatch is gone. This allows developers to simply focus on building their objects persisting them to the database as is.
• Database Performance: When you have a database that is nothing but key-value pair lookups it becomes lightning fast which is why NoSQL databases are used by the largest websites out there like: Facebook (Cassandra), Amazon (Dynamo) & Google (BigTable)

So if you’re convinced that NoSQL is the wave of the future, here’s how you get started.

How Do I Get Started?

The first choice you have to make is which NoSQL DB you’d like to use. From what I’ve read, here are the most common options:

• MongoDB: From the MongoDB site:”MongoDB (from "humongous") is a scalable, high-performance, open source, schema-free, document-oriented database. Written in C++”. MongoDB seems to be a good choice if you are working in rails because of a MongoMapper which makes it easy to plug rails code into a MongoDB. There are also a series of Tekpub screencasts for using MongoDB with Rails
• CouchDB: From the CouchDB site: “CouchDB is a document-oriented database…[that] provides a RESTful JSON API than can be accessed from any environment that allows HTTP requests.” It does seem like CouchDB is not ready for production yet and most people are just experimenting with it at this point.
• DB40: From the DB40 site: “db4o is the open source object-oriented database that enables Java and .NET developers to store and retrieve any application object with only one line of code, eliminating the need to predefine or maintain a separate, rigid data model.” DB40 does seem to be production ready (it even supports LINQ) and Rob Conery has a great series of articles on getting started with it in .NET

Does the NoSql movement have legs or is it just the most recent shiny object for developers to talk about?

I don’t know, but I like the idea of looking at new options for database engines, and plan to try them out in some test projects. I think we’re still at a point where we spend far to much time writing CRUD code. Maybe NoSql DBs can solve that?

There was an interesting debate on the Stack Overflow podcast regarding the value of software documentation. On one hand, organizations always think they need more of it. On the other hand, programmers typically hate writing it and usually think it’s worthless.

Who’s right?

The Problems with Docs

The real problems with software documentation for large internal applications is threefold:

• Small Audience: You may write the most beautifully detailed document in the world, but odds are it will only be skimmed and never actually read. As we all know from Steve Jobs famous quote “No one reads anymore”.  If people don’t read normal books by popular authors, are they really going to read your dry 20-page detailed software doc?
• Already Obsolete: When programmers start new projects, they typically don’t read the documents because they assume they are obsolete, and most of the time they’re correct. By the time the massive doc is finished, the software has often already changed by 20% and the screenshots need to redone.
• Great Programmer != Great Writer: Great programming and great writing do not necessarily go hand in hand. In fact, some people get into programming so that don’t have to communicate with anything other than a compiler. There’s nothing wrong with that, but don’t expect your programmer to write the clearest software documentation.

So, given that we’re up against all of this, is there any hope for software documentation?

The Bare Minimum

There are some types of documentation that add real value to a project. Let me list those and then talk about style:

• Scope Doc: In some form, you need to document what you’re going to build. Now, I’m not advocating a 200-page waterfall-style spec doc. But I’m saying that everyone has to be on the same page with what is being built and a scope doc is the best way to do that. Mockups using something like balsamiq are a nice touch in a scope doc as well. Spolsky has the canonical post on writing scope docs.
• Install Guide: The install guide has two functions: 1) It tells new developers what they need to install to get the project running, and begin development on it 2) It also helps the IT staff know how to rebuild the app if the server dies. This doc would typically include items like location of source control code and third party apps to install.
• User Guide Inline Help: Instead of a user guide that no one will read, implement some sort of inline help in your software application that appears right where the user needs it and helps them understand their specific problem.

For each of these docs, they need to be light: 5 pages or less, and heavy on bullet points, images and sub headings. The bottom line is that people don’t read anymore; they skim and software docs need to accommodate this fact.

Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong.  

–Eric S. Raymond

Recently, I’ve had the opportunity to actually begin using Microsoft’s LINQ (language-integrated query) in a few “real” projects. So I’ve tried to spend some time actually understanding it rather than just copying examples.

Throughout this process I’ve gleaned a few key concepts:

1. Determine which LINQ you will use

One of the confusing aspects of LINQ is that it comes in five flavors:

• LINQ to XML: Used to query XML documents. Can be used in place of XPath or DOM manipulation.
• LINQ to Objects: Used to query object collections. Can be used instead of looping through the collection.
• LINQ to SQL: Basically an ORM (Object-Relational Mapper) used to map classes to DB tables and query them in code. Can be used in place of another ORM.
• LINQ to Dataset: Used to query datasets. Can be used instead of looping through a dataset or using the filter method.
• LINQ to Entities: Used to query conceptual database models rather than the strict table to class model that LINQ to SQL uses. Based around Microsoft’s Entity Framework.

Once you know which one you’re after, it makes looking online for examples much easier.

2. It’s all Extension Methods on IEnumerable

Here is the key thing to know about LINQ. It’s primarily a set of extension methods to IEnumerable. Extension methods allow you to add new methods to existing classes.

So if you want to start using LINQ just add a reference to System.LINQ and look at the intellisense on an object that implements IEnumerable. You’ll see a bunch of new methods like: Where, Order By, and Select. These are the core LINQ methods.

3. Prefer the Method Syntax over the Query Syntax

LINQ let’s you write queries using two different methods – the method (or dot) syntax and the query syntax. Here is an example of both:

     //Query Syntax
       var queue = from q in dc.SomeTable
               where q.SomeDate <= DateTime.Now
               orderby (q.Priority, q.TimeCreated)
               select q;
   //Method Syntax
        var queue2 = dc.SomeTable
             .Where( q => q.SomeDate <= DateTime.Now)
             .OrderBy(q => q.Priority)
             .ThenBy(q => q.TimeCreated);

When starting out, I think it’s MUCH easier to begin with the method syntax. It just makes more sense to a seasoned .NET developer and it doesn’t get confused with long-held SQL knowledge.

At the end of the day, the query syntax gets compiled into the method syntax anyway.

4. Understand Deferred Execution

In LINQ query execution is usually deferred until you request the data. So, consider the following example from Patrick Steele:

  string firstLetter = "B";
   //Query NOT run here
   var query = from c in customers
               where c.Name.StartsWith(firstLetter)
               select c;

   firstLetter = "J";
   //Query actually executes here
   foreach (Customer c in query)
   {
       Console.WriteLine(c.Name);
   }

The query doesn’t get executed until it is actually used – in this case in the foreach. The implications are that the “J” filter is applied to the above code rather than the “B” filter.

5. Learn Lambda Syntax

You can’t get away from Lambdas if you use LINQ. Basically anytime you use the “Where” statement you will need to use a Lambda. A lambda is just a fancy name for an inline function with a specific syntax. You’ll know that you need to use a Lambda, if you see “Func” in intellisense. Here is an example of a lambda:

 .Where( q => q.SomeDate <= DateTime.Now && q.Locked != true )

This snippet says that q (which is just an arbitrary parameter) should be filtered by the SomeDate and Locked properties. It is equivalent to a function that takes a parameter called q and applies the filter. The only difference is that it’s all written inline.

I hope these five tips help you in your journey to use and understand LINQ!

One of the more frustrating aspects about switching to MonoDevelop on the Mac after many years of developing with Visual Studio on the PC is the key commands. We all know that programmers are typists first, and programmers second so I’ve spent a good amount of time learning to do everything with the keyboard rather than the mouse.

The problem is I’m now hardwired to hit certain commands (ctrl+shift+b) when developing and it’s tough to fight that muscle memory. When I started using MonoDevelop, I would unconsciously start hitting the same key commands only to see them fail in various crazy ways.

Let me be clear that many of these issues are due more to how the Mac works than anything that MonoDevelop is doing. With that caveat in mind, here are some tips to get MonoDevelop on the Mac to behave a little more like Visual Studio.

Take Command

The very first change you will want to make is map your keyboard control key to the mac command key. This will make simple actions like copy (ctrl+c) and paste (ctrl+v) work like a PC user expects. You can put it back to “normal” by using the following tip:

Tip: Go to System Preferences > Keyboard & Mouse > Keyboard > Modifier Keys > swap the Command and Option keys.

Go Home

In VS.NET, I am forever pressing Shift + End or Shift + Home to select entire lines. Not having the Home and End buttons working on the Mac is a cardinal sin in my depraved PC mind. This one took some research to solve because there is no built-in solution. Luckily, there is a third party program that can help:

Tip: DoubleCommand is a free program that you can download on your Mac which allows you to configure your Home and End keys by setting “PC Style Home and End keys” on the dialog.

Bind Your Own

One awesome feature of MonoDevelop 2.2 is that it allows you to set the key bindings to whatever you like. For example, I’ve set ctrl+L to delete a line like it does in VS.NET since I use that command all the time. By default it executes “Go to line” in MonoDevelop, but it’s a great feature to be able to set your own key commands.

Tip: Under the MonoDevelop->Preferences menu, go to Key Bindings and set the keys to whatever you’re most comfortable with.

The Nuclear Option

If it’s all just too overwhelming for you. There is a small faction of the MonoTouch community that is pioneering the ability to open MonoTouch solutions inside VS.NET on the PC.

ManniAT has even created a stand-alone converter that you can use to open MonoTouch projects in VS.NET. It’s not quite there yet because you can’t compile on the PC, but he’s getting there. I actually used this solution to do some simple MonoTouch dev on my PC and it worked pretty well.

Tip: Open MonoTouch projects in VS.NET by using ManniAT’s converter.

Nirvana

The ultimate solution would be for someone to put together some VS.NET-like key bindings in a file that you can import into MonoDevelop. I haven’t been able to find this yet, and I’m not even sure if you can import key bindings into MonoDevelop, but I’ll cross my fingers because you never know what the Mono team or community will come up with next!

“I was trying to figure out which is the most important computer science course a CS student could ever take, and eventually realized it’s Typing 101.

The really great engineers I know, the ones who build great things, they can type.”

- Steve Yegge

Google Chrome has reached a turning point. In the past, I’ve liked the speed and simplicity of Chrome, but never enough to discard my beloved Firefox. Why? Well, as everyone knows, it’s all about the extensions!

Extensions

I just couldn’t part with AdBlock Plus and Firebug for Firefox. But that’s all changed with the release of Google Chrome 4 Beta. Chrome now supports extensions, and out of the gate it has the ones I need:

• AdBlock: The web is a much different (and better) place without ads. Ad Block takes you to that happy web by obliterating nearly all inline, flashing and dreaded pop in-front ads.
• IE Tab: I frequently use Outlook Web Access (OWA) for checking email and it’s optimized for IE. The interface is totally different if you use any other browser so I like to have the ability to switch to IE rendering inline.

Developer Tools

Another requirement of any browser that I commit to is a developer toolbar such as Firebug for Firefox or the IE 8 Developer Tools. These tools let you trace CSS styles, debug JavaScript and generally make a web developers life much easier.

Chrome now supports its own built-in set of Developer tools. They are somewhat hidden, but can be summoned by pressing Ctrl+Shift+J. It looks similar to the developer toolsets built into the other browsers.

Blazing Speed

Finally, the best feature of Chrome is its speed. As Jeff Atwood often says, “Speed is a feature”:

Maybe I’m just impatient. However, there’s a lot of concrete data to support the theory that unless you make it load fast, nobody will stick around long enough to find out what you have to offer. For instance, a recent study found that most shoppers will only wait four seconds for a page to load before abandoning the site entirely.

To me Chrome feels faster than Firefox and IE in nearly every way – from cold startup to page browsing. It’s obvious that Google has been doing some heavy optimization.

I also like the sheer simplicity of Google Chrome (ie – one box for searching or typing URLs). Will it win out in the end? Who knows, but now that it has extensions I’m trying it as my main browser. What about you?

It’s getting to the point where I don’t even get prints of pictures anymore and just assume that I’ll store and share them digitally. So if a hard drive goes, there go all my memories…

So what’s a home user to do? Backups of course!

Once you decide that backups are a good idea, you have to decide which backup solution you’d like to use. Hopefully, I can help with that because it seems like I’ve tried them all….

The Brute Force Method

The simplest and cheapest option would just be to regularly burn DVDs or even better regularly copy the data to an external USB drive. This was the very first back method that I used back in the day.

The problem is that it is an extremely manual process and there’s a certain amount of weight that hangs over your head because you have to remember to do those annoying backups.

The bottom line is that I would not recommend this approach any more as there are many better options. Computers are supposed to automate this stuff. Right?

Where’s my Time Machine?

If you are lucky enough to have a Mac, backup is relatively easy and built-in. You just plug in a USB drive and all the sudden this nifty program called Time Machine just starts using it to regularly backup your machine.

The best aspect of time machine is that it’s built-in to OS X and it’s all very seamless. You just don’t have to think about it.

This is a great option if you have a Mac. For example, we have Macs and PCs at home, but we copy all of our photos to the Mac and let time machine back them up to an external USB drive.

Frankly, I wish the PC had an option as simple and intuitive as Time Machine, but sadly it does not so If you’re a PC user, read on…

Trapped in Carbonite!

Carbonite is probably the best-known online home backup system. The way it works is you install an application on your machine that runs in the background and backs up your system to their online data storage.

They have plans for around $50/year so it’s affordable for the average home user. In theory this is great idea because you can set it and forget it. And you get the added benefit of having your data backed up offsite, so if your house burns down your priceless family photos are still safe. What could go wrong?

After using Carbonite myself for about six months, I have two problems with the service. The first is that backing up lots of large files over the internet can be very slow. Now your mileage may vary depending on your internet speed and the amount of stuff you want to backup and this is true of any online backup.

But, by far, the biggest issue I had with Carbonite was that when a machine did fail, I wasn’t able to get my data back from Carbonite. I tried all of their restore options and their program just kept crashing. I even installed their program on fresh machine and logged into my account to no avail. It just kept crashing.

After trying to call them and waiting on hold forever, I finally gave up. My data was essentially trapped in Carbonite!

This illustrates an important point of backup solutions. If you can’t restore your data, then the backup is worthless!

iDrive (no it’s not an Apple product)

iDrive works much like Carbonite in that it’s an online backup system with a monthly cost of roughly $50/year, but that’s where the similarities end.

First off, iDrive has a totally free version that lets you backup 2GB of data. This is a nice solution for folks who don’t have a ton of pictures to back up.

Secondly, iDrive has a great web interface for restoring files whereas Carbonite forces you to install their software before you can restore. This makes it MUCH easier to your data back.

Carbonite needed me to install their software before I could get my data back, and when their software kept crashing I was stuck. With iDrive, you can simply login to their site and grab the files you like — right from your browser.

That combination of easy “set it and forget it” along with simple restore options have me sold on iDrive. It’s what I currently use for my PCs.

Others

The above are the solutions that I’ve had personal experience with. I’ve also heard good things about Windows Home Server, but have yet to try it myself. Mainly because it requires a dedicated machine. It’s hard to pull the trigger on a $400 machine dedicated to backup. I think it’s probably overkill for the average home user.

Acronis True Image or even the built in Vista and Windows 7 imaging are also good options to consider. My only problem with these is that imaging often is beyond the average home user, and I typically end up buying a new machine when one crashes. An image requires the exact same hardware to be restored, so it doesn’t work if you end up buying a new machine.

Conclusion

If you have a Mac, the built-in Time Machine is an excellent solution for the regular home user. It’s extremely intuitive, and for the cost of a USB drive you are all set. Just remember that it requires a blank USB drive and provides no offsite protection.

For the PC, my choice is iDrive. It provides inexpensive, offsite backup and because it has a web interface, you can always get your files back from nearly anywhere.

Because Objective-C sometimes makes me want to poke out my eyes with sharp sticks, I’m relieved to see that there are finally other options. Now let me be clear. I think objective-C would be a fine language if it was something that I used day in and day out, but given that I only tinker in it and spend the majority of my time in .NET, I can’t help but see MonoTouch as a godsend.

MonoTouch is a framework, created by the brilliant mono team at Novell, that allows developers to use C# for coding iPhone apps. Not only have they ported the .NET framework to run on the iPhone, but they’ve bound it to the iPhone API. In addition, they provide a first class develop environment in the form of MonoDevelop on the Mac.

This brings up an important point. You still need a Mac to develop C# on the iPhone using MonoTouch. Luckily, I have my trusty Mac mini so I thought I’d take MonoTouch for a spin by porting my existing Objective-C app to MonoTouch.

Background

I developed an iPhone app in Objective-C over the summer and it was approved by Apple. It’s called BragVest and allows Cub Scouts to track their progress toward ranks. It’s currently live in the app store and getting some great feedback from users. I have a lot of ideas for new features, but implementing them is a different story.

When coding in Objective-C, I spend too much time just looking up how to do simple operations. What’s the best way to load a plist? How should I best concatenate that string? Operations that should be simple and probably are to a Mac developer or someone who spends a lot of time with the language.

It’s a simple case of focusing on your strengths. I’m a professional .NET programmer and have been for a long time. I can crank out .NET code in my sleep, but programming in objective-C sometimes feels like I’m pushing a boulder up a hill. It just takes a lot longer to get a feature implemented and I spend a lot of time just looking up language features.

So, in theory, MonoTouch would be a great fit for me. I’ve already mostly learned a lot of the iPhone API, and now I get to use a language I know and love — C#.

At this point, I’m about 75% through porting my app to MonoTouch, and here’s what I’ve learned.

The Good

There’s a lot to enjoy about working with MonoTouch:

• MonoDevelop: MonoDevelop feels much more like Visual Studio.NET (my native development environment) than XCode does. I spent many months in XCode and it just takes a different approach to development. MonoDevelop seems like it was modeled after VS.NET so I felt productive almost immediately.
• C# language: It’s great to have access to the C# language. It feels much more natural to me than Objective-C. I’m sure this is just a matter of experience, but the bulk of my experience is with C#. Also, I’m glad not to have to deal with memory management so I can focus on developing new features and not writing plumbing code.
• .NET Framework: Being able to access the .NET framework is huge, and probably one of the biggest selling points of MonoTouch. Need to parse a plist? No longer do you have to resort to NSArrays and NSDictionaries. Just fire up LINQ to XML! Need to do some fancy string parsing? Don’t use NSString. Just use the standard .NET string type. They also put a lot of thought into translating between the Apple and .NET APIs so it’s mostly seamless. If you need to see how a particular class or API was translated, check out the MonoTouch Rosetta Stone.

The Bad

Most of the issues that I ran into have to do with the fact that this is still a very new platform:

• Lack of Samples/Docs/Community: This was the hardest part of developing with MonoTouch. When I was working with the apple tools, if I wanted to know how to do something in Objective-C, I could generally google for it and quickly find an example. The blogs and docs are just starting to pop-up for MonoTouch so it can be much harder to find real-world examples.
• Stability: One of the most frustrating parts of developing in MonoTouch was that the IDE  (MonoDevelop) would crash on me or throw strange exceptions periodically. It seems to mostly be related to the subversion integration so maybe if I disabled that I’d have more stability. That said, I have not seen any stability issues when the code is running on the phone so that’s what’s important.
• Not Fully Implemented: Every now and then, I would want to do something with MonoTouch and get a “Not Implemented Exception” (such as some LINQ features) or I couldn’t figure out how it was translated (such as NSMutableDictionary).

Some people would also mention cost ($399), but I don’t think that’s fair. The mono team have put in an amazing amount of work that provides real value to developers. It’s only natural, that they should be compensated for it.

I also think the increased file size of MonoTouch app is small price to pay for all the features and frameworks you get.

Verdict

In my opinion, there is more than enough good to outweigh the bad in MonoTouch. I’m also hoping that much of the bad will disappear as the platform matures.

For an experienced .NET developer, it will give you a huge head start in iPhone development especially if C and memory management make you squeamish. That said, there is still a heavy learning curve with getting used to the Mac, the iPhone API, and Interface Builder. And MonoTouch does not eliminate the need to learn how to make a iPhone app that fits Apple’s design guidelines (which you will have to do to get it approved).

Overall, I’m planning to invest in it, and if you are an experienced .NET developer wanting to develop apps on an iPhone I would recommend you take a look as well.