Brian Sullivan

I stumbled across Jason Dentler’s post on the problems he had upgrading his code to the Release Candidate of Fluent NHibernate today, specifically regarding subclasses.   I ran into some difficulties with subclasses when upgrading to the RC myself, but I was using a table-per-class-hierarchy structure rather than table-per-subclass, so I thought I’d post my problem and solution as well.

In the RC, rather than defining your class hierarchy entirely in the mapping of the parent class, you create a SubclassMap for each of your subclasses.  The wiki wasn’t quite clear about what needed to go into my subclass mappings since, like Jason, my subclasses didn’t have any extra properties, just redefined behavior. Turns out to be pretty simple, actually, and I think it ends up clearer than the old method.  Using the old way, I had the following in my parent class map:

DiscriminateSubClassesOnColumn<int>("intCampaignTypeID", -1)
                .SubClass<InspectionCampaign>(1, x => {} )
                .SubClass<OBPCampaign>(2, x=> { });

This is looks okay, but the empty lambdas are a bit confusing.  Using the new SubclassMap way of doing things, in the parent class map, I just call the following method in the constructor:

DiscriminateSubclassesOnColumn("MyDiscriminatorColumnName");

And in each subclass map, I call the following method in the constructor:

DiscriminatorValue("1");

Much easier to understand!  The signature for this method threw me off a bit, since my discriminator column is actually an integer, but the DiscriminatorValue method only accepts a string.  FNH seems to handle the conversion, though, because it worked just fine.

Hopefully this will be helpful to someone, at least until the wiki gets updated!

Recently, my employer has instituted a program called “Innovator of the Quarter”.  The idea is for employees to submit ideas, such as new product features, process improvements, or tools to increase productivity, to a committee.  The committee will then pick the idea it thinks has the most merit, and the person who submits the winning idea will get $500 and the chance to implement their idea, or at least build a proof-of-concept.

When this program was first announced, several ideas occurred to me, but the one I thought would result in the greatest benefit for the company (and, admittedly, the greatest reduction of development pain for me) was to use NHibernate for our data access instead of the hand-rolled DAL we currently use.  I put together a proof-of-concept project based on one of our smaller systems (which I unfortunately can’t share since it’s proprietary), and wrote up a short explanation of the benefits I thought adopting NHibernate would provide.

I wanted to post the contents of that entire document here (slightly sanitized for product and team names) so that readers could point out any glaring mistakes or make suggestions for additions.  So here it is:

The Case for NHibernate

One of the most fundamental parts of a system is its data-access strategy.  IT organizations building on the .NET platform have a multitude of options for addressing this part of their systems.  Many of these options are provided by Microsoft itself, while others have grown up out of the open-source community.  They range from thin wrappers over the ADO.NET API, such as the Enterprise Library Data Application Block, which provide similar functionality to plain ADO with an easier-to-use programming model, to full-fledged Object-Relational mapping (ORM) tools, such as the Entity Framework or LINQ to SQL.

On our team, data access has traditionally been implemented using tools that operate very close to the ADO “metal”, using stored procedures for much of the application logic.  The reasoning for adopting these tools and practices at the time our first system was created included both developer skillsets and performance benefits.  Not long ago, there was a substantial performance benefit to using stored procedures as opposed to “inline” SQL.  However, with the improvements made to SQL Server, these advantages have been eroded to the point that stored procedures no longer carry much performance advantage over parameterized SQL queries.

Since the performance differences between the two are now far less significant, other advantages of the various data-access strategies, and specifically those of ORMs, should be examined.  I will outline here the multiple advantages I believe using NHibernate would bring to our projects.  Examples will be taken from the proof-of-concept project stored in source control.

Development Time

CRUD

Chief among the advantages of using any ORM tool is the reduction in development time that is possible if the tool is used appropriately.  In particular, the standard Create, Read, Update, and Delete (CRUD) operations that commonly need to be performed on any business entity are easier to implement using an ORM tool.  Take, for example, the Contact entity from the proof of concept system, which looks something like this:

In order to implement persistence for an entity like this using stored procedures, we would need a minimum of four procedures, one each for INSERT, UPDATE, SELECT and DELETE.  Also, application code must also be written to put the data into the appropriate properties of a .NET object when retrieved from the database, and from the .NET object properties to stored procedure parameters when saving back to the database.  This sort of “right-hand, left-hand” code is tedious and time-consuming to write, and is really just specifying the same idea four or five times over.  The CRUD procedures for the Contact object in the project the proof-of-concept was based on are about 350 lines of T-SQL put together, and the .NET code to move the properties and parameters back and forth is about 180 lines.

On the other hand, using NHibernate mappings, we specify the relationships between our object properties and database table columns in only one place.  Through the use of conventions provided by Fluent NHibernate, these mappings can be specified concisely and clearly.  In the case of the Contact entity, the mapping can be specified in about 30 lines of C# (you can see this in the file ContactMap.cs in the proof of concept project).

Once these mappings have been specified, CRUD operations can be executed in the application.  For example, to retrieve a particular Contact from the database, we can simply write:

Contact con = session.Get<Contact>(contactID);

Where “contactID”  is the primary key value for the contact we want to retrieve.  The “session” object here is a key part of the NHibernate infrastructure; all interactions with the database are executed within a session.  The other 3 CRUD operations are similarly simple.  Examples of each can be seen in the ContactsUC.ascx.cs control in the proof of concept project.

Delete

Update

Create

Searches

Besides simple retrieval and modification by primary key, the main way that we interact with persistent data is retrieval by a set of more complex criteria.  This is exemplified by the numerous search pages in our systems.  Currently, these searches are accomplished using dynamic SQL generated within a stored procedure.  As anyone who’s ever worked on a search page can attest, these SPs (along with the pages themselves) can get very large very quickly.  This approach necessitates the use of significant conditional logic within the T-SQL code, which can make the procedure quite confusing due to the limited methods of encapsulation provided by the language and environment.

There are a couple of options for doing these complex searches using NHibernate:  the Criteria API and the new LINQ provider.  Both of these have their strong points, but it’s what they have in common that’s most important.  They provide a way to execute dynamic queries using only application code without resorting to inline SQL.

There are a couple of advantages to using C# to specify searches rather than in T-SQL stored procedures.   The first is in the kinds of tools we have available for achieving logical separation.  Using both native language constructs and refactoring tools, we can break search logic down into much more easily understandable pieces, rather than having to navigate through a sea of IF blocks in T-SQL.  The second advantage is a reduction of duplication.  In our current search implementations, checking search values for nulls, empty strings, etc. occurs in both application and database code.  Using NHibernate, we cut down the number of these checks by half, since we only need to interrogate those values in the application.

An example of how a search page might be implemented can be seen in the proof of concept project in Search.aspx.cs.  Note that this page would certainly benefit from additional refactoring, but it should give the reader a general idea of how better separation of concerns and elimination of duplication can be achieved using this method.

Performance Concerns

As was stated earlier, one of the primary motivations for the data access strategy used by our systems currently was performance, particularly in the area of search.  In order to consider adoption of a new data access strategy, it must be shown that it performs comparably to the current strategy.  Fortunately, SQL Profiler can help us determine the performance impact by showing us the resulting queries produced both by the stored procedures and by NHibernate and the time they take to execute.

Though nowhere near exhaustive, the tests I performed showed that the queries produced by NHibernate, when not nearly textually identical to the ones produced by the stored procedures, executed with time differences that were essentially statistically insignificant.  (E.g., 1885 ms vs. 1886 ms)  In fact, in several instances, the NHibernate queries actually performed better than their stored-procedure-produced counterparts.

It would be prudent to note, however, that this is only one search page.  Different entity relationships may give rise to situations where SQL hints provided by a developer would have a significant impact on query performance, but this would have to be approached on a case-by-case basis to determine if such optimization is worthwhile.  If such a case does present itself, nothing would prevent us from using a stored procedure to perform that particular operation.  While it is best to be consistent with the data-access methods used in a project, using NHibernate is certainly not an all-or-nothing proposition.

When it comes right down to it, NHibernate is an abstraction on top of ADO.NET.  Abstractions are created to increase productivity, not performance.  It may be that in certain cases, the delegation of responsibility to the abstraction layer may result in greater performance due to the elimination of human error or ignorance.  However, a determined developer with intimate knowledge of the underlying technology will often be able to write code that outperforms the abstraction.  In other words, there is no question that an abstraction comes at a price.  The challenge is not to eliminate all abstractions that can be outperformed by hand-tuned code in order to eke out the absolute best performance, but to weigh the benefits and costs of each abstraction to determine if it is, overall, beneficial to the project.

The software development industry as a whole is becoming more and more willing to adopt the ORM abstraction.  This can be seen on a number of different platforms, from Ruby on Rails’ ActiveRecord to the Java Hibernate project (upon which NHibernate was originally based).  Microsoft itself has acknowledged the benefits this kind of technology provides, evidenced by their offering of not one, but two ORM solutions:  LINQ to SQL and the Entity Framework.

Alternatives

NHibernate is hardly the only player in the .NET Object-Relational Mapping space.  Microsoft has two different offerings, LINQ to SQL and the Entity Framework, and there are multiple other commercial and open-source frameworks that offer similar functionality.  So why use NHibernate over these other technologies?

LINQ to SQL

As Microsoft’s first foray into ORM, LINQ to SQL is a fairly lightweight framework for turning your database tables into entities usable by your application.  For example, if you had a table named “Contact”, you could simply drag that table from the Server Explorer in Visual Studio onto the LINQ to SQL design surface to create a persistent “Contact” class.  This works well for simple scenarios, but LINQ to SQL has several significant limitations.  Among these are only supporting one-to-one mapping between classes and tables, limited support for inherited classes, and a less than stellar workflow for modification of mappings.  In short, LINQ to SQL is likely not a good fit for our existing systems.

Entity Framework

The ADO.NET Entity Framework is Microsoft’s full-fledged ORM solution.  While it boasts a larger set of features than LINQ to SQL, it also has a number of shortcomings.    Rather than allowing the user to map tables to an existing set of entity classes, EF generates its own new classes that must be used in order to persist data.  Also, lazy-loading of associated entities (e.g. waiting to load a set of Contacts belonging to a Location until and only if they are needed) is poorly supported.  In addition to these and other problems, the XML mapping files themselves are tremendously complex, and consequently are very difficult to modify when needed.  While there is hope that some of the problems with EF may be addressed in the upcoming version, its release is tied to Visual Studio 2010, which it still a while off.

Other Third-Party ORMs

There are a multitude of ORM options for the .NET platform other than the ones already discussed, including SubSonic, LLBLGen, and Telerik’s OpenAccess among others.  Their feature sets vary widely, and while each has its merits, they all share a disadvantage against NHibernate:  the size of their user-base.  Due to its widespread adoption, there are simply more resources for learning about and troubleshooting NHibernate than any other .NET ORM.  When faced with a technical challenge, the availability of online resources can be the difference between solving the problem in a matter of minutes or a matter of days.

Conclusion

Bottom line, adding the capabilities of NHibernate to our projects will mean increased productivity.  Less time will be spent on repetitive tasks, leaving more time to focus on the problem domain and the needs of our clients.

Any feedback you’d like to provide in the comments is welcome!

UPDATE: Chris Benard suggested that posting the CRUD operations and the mapping would be helpful to people without access to the codebase, and wouldn’t expose any IP.  I agree, so now it’s there, in the form of GitHub gists.  Hopefully that’s an improvement!

I wrote the other day about how conventions in Fluent NHibernate can make your life easier by decreasing the amount of code you have to write to map your objects to their relational representations.  Well, if you’re willing to go along with even more convention, you can even do away with some of your mapping files entirely.

When setting up your NHibernate configuration via FNH, normally you specify where to find your mappings by using something similar to the following:

.Mappings(m => m.FluentMappings.AddFromAssemblyOf<Entity>())

Notice the “FluentMappings” property being used here.  This will look for any mappings you have explicitly specified in classes that derive from ClassMap, a base class provided by FNH.  However, if we change that to use the “AutoMappings” property instead, like so:

.Mappings(m => m.AutoMappings.Add(AutoPersistenceModel.MapEntitiesFromAssemblyOf<Entity>()))

FNH will determine the mappings all by itself based on conventions, and you don’t have to write a single ClassMap class.

Used in conjunction with NHibernate’s SchemaUpdate feature, this becomes really powerful.  You can simply add a property to an entity class contained in an assembly for which you are using auto mapping.  When you run SchemaUpdate, either at the start of your application, or maybe in a separate console app, your database schema will be updated to include a new column to store that property value.  To illustrate, I’ll show you a simple example.  

I’ve got a small entity named “Course” that represents a college course.

    public class Course
    {
        public virtual int Id { get; private set; }
        public virtual string Name { get; set; }
        public virtual string CatalogNumber { get; set; }
    }

And the database table it maps to looks like this:

Say that I wanted to add a property to my Course entity to tell how many credits the course was worth.  I just add the property to the class:

    public class Course
    {
        public virtual int Id { get; private set; }
        public virtual string Name { get; set; }
        public virtual string CatalogNumber { get; set; }
        public virtual int NumberOfCredits { get; set; }
    }

And run SchemaUpdate through a simple console app that looks like this:

    class Program
    {
        static void Main(string[] args)
        {
            Fluently.Configure()
            .Database(MsSqlConfiguration.MsSql2005
                .ConnectionString(c =>
                    c.Is(ConfigurationManager.ConnectionStrings["SQLServerConnString"].ConnectionString)))
            .Mappings(m =>
                  m.AutoMappings.Add(AutoPersistenceModel.MapEntitiesFromAssemblyOf()))
            .ExposeConfiguration(BuildSchema)
            .BuildConfiguration();
        }

        private static void BuildSchema(Configuration config)
        {
            new SchemaUpdate(config).Execute(true, true);
        }
    }

I’ll see the script being used to update the schema in the console window:

And my database table will be updated with a new column for the new property:

Having not used this feature of Fluent NHibernate in anything close to a production capacity, I can’t speak to how well it scales.  However, I think this has a lot of potential for rapid prototyping, especially when you pair it with ASP.NET MVC and the templated controllers and views that you can generate.  A little alteration of the T4 templates used for the controllers could do some default persistence via NHibernate, and then we’d be quite a bit closer to the ease of protoyping provided by Rails.

Again, hats off to the Fluent NHibernate team!

I’m still not ready for the blog post on Fluent NHibernate’s Auto Persistence Model that I’ve wanted to write for a couple of days, so I thought I’d share a few of my impressions about Miguel Castro’s interview on DNR on Thursday.

First, no ORM proponent (to my knowledge) has ever said that using an ORM means that you don’t have to know anything about databases or SQL.  It’s still essential, when using an ORM, to understand how relational databases work.  At the end of the day, that’s how your data is being stored.  And you also need to understand SQL, not even so much to try to decide if your  ORM is producing sub-optimal queries so you can step in and write them manually yourself, but to clue you in that you may be using your ORM incorrectly.  I don’t know of anyone in the ORM camp, as I said, who has indicated otherwise.

Second, I may just not run in the right circles, but the whole OO-vs-SOA argument seemed kind of ridiculous.  Is anyone actually fighting about those things in an either-or way?  Maybe it was just a CSLA thing (which would explain why I’d never heard anything about it), because I don’t know of anyone who’s suggesting that service-oriented-architecture is even the same category of thing as object orientation.  I mean, unless you’re writing your services in F# or Erlang or something, chances are you’re going to be consuming them from a OO environment.  Sounds like a made-up fight to me.

And last, does anyone really need to drag out the C#-vs-VB thing again?  Is anyone really still arguing about which one is better?  Aside from a few notable exceptions (XML literals come to mind), there’s not a dime’s worth of difference between the two languages.  Again, sounds like more of a manufactured fight than anything.

There were several more things that he brought up that were in more or less the same vein.   He’s a smart guy, I think, but he probably could have made a better contribution to the .NET community by discussing a subject he was knowledgeable in and sharing some of that knowledge with us.  In the end, it just sounded like he was trying to find “controversial” subjects to “make some people mad” over, and it ended up falling kind of flat.

At work, we are preparing to institute an “Innovation Idea of the Quarter” program.  I say “Innovation Idea” and not “Innovator” because the idea doesn’t necessarily need to end up being implemented for the person who came up with it to win.  I think this is great, because it really encourages people to think outside of the box from the way we normally develop, and not to just propose things they know for sure would be “safe” enough to actually go into the product.

As you can probably tell from the title of this post, I’ve already decided what my initial submission is going to be.  A few months back, when we were first floating the idea of the innovation program, I started trying to prototype using NHibernate in one of our smaller systems as a proof-of-concept.  I eventually got one of search pages working, but it took a lot of trial and error with the “hbm.xml” mapping files, since I didn’t know until I ran the program when I had misspelled something.  Since the innovation program still in incubation when I finished, I set my proof-of-concept aside.

Fast forward a few months, and I had noticed that the Fluent NHibernate project had come a long way.  They’ve now got  a significant amount of documentation on their wiki site (http://fluentnhibernate.org/), pre-built binary packages, and a pretty active mailing list (http://groups.google.com/group/fluent-nhibernate).  After perusing the site a bit, and determining that, based on the amount of activity I saw, Fluent NHibernate probably did have some legs and wouldn’t just be a flash in the pan, I decided to convert proof-of-concept over to using Fluent NHibernate.

I was not disappointed.  One of the key benefits of using FNH is that you get compile-time checking of your object property names, since you use lambda expressions to specify your mappings.  You also don’t have to use the verbose type name syntax (e.g. “My.Really.Long.Chain.Of.Namespaces, ClassName”) when creating relationships between entities.  But the thing I liked the most was the ability to define conventions for just about everything.

The team I work on has an… ahem… interesting pattern for column naming:  basically, Hungarian notation for columns.  If a column is an integer column in the database, it will have an “int” prefix on the column name.  If it’s a char or varchar column, it will have a “str” prefix, and so on.  While I may not agree with this “coding standard”, the team has at least been consistent about it, so I was able to take advantage of conventions.  

In FNH, you define a convention by creating a class that implements one of the convention interfaces provided by FNH, such as IPropertyConvention (you can see the entire list of available interfaces here).  That interface requires you to implement two methods, Accept and Apply.  

The Accept method lets you define what kinds of properties or classes will be affected by the convention.  You get full access to all of the information about the property, such as the name, the data type, and so on, to let you determine if the convention ought to apply to the property.  For example, the Accept method for the string column convention I mentioned earlier looks like this:

public bool Accept(IProperty target)
{   
    return target.PropertyType == typeof (string);
}

The Apply method lets you perform mapping actions on the property or class just as you would in a ClassMap<T> class, which is where mappings are defined in FNH (each one of those classes would correspond to a “hbm.xml” file used by NHibernate when not using FNH).  This is easier shown than explained, so here’s the Apply method for that string column convention:

public void Apply(IProperty target)
{
    target.ColumnNames.Add("str" + target.Property.Name);
}

So, with that convention in place, all I have to do to define a mapping between an entity property named Address and a column named strAddress is:

Map(x => x.Address);

You can, of course, override the conventions you define at any point that you system deviates, so you’re never painting youself into a corner by defining conventions. You’re just taking care of the majority case, and eliminating a lot of code (and magic strings) in the process.  

Since I had conventions and Intellisense working for me, I was able to convert all the hbm.xml mappings I had defined the first time to FNH mappings in a single evening.  If you’re using NHibernate in your application, you should take a serious look at Fluent NHibernate.  Not just for the reasons I’ve covered here, but also for the help it provides with refactoring (property names in mappings are affected by refactoring tools) and the ability to test your mappings.  Kudos to James Gregory,  Paul Batum, Andrew Stewart, Chad Myers, Jeremy Miller, et al. for providing a way for the rest of us to improve our NHibernate experience.

Tonight my friend Zac Kleinpeter gave a great presentation CouchDB, a schema-less document-oriented database from the Apache Software Foundation.  I have to admit that I don’t completely grok it yet, but the schema-less model does seem to be catching on in platforms designed for high scalability, such as Google’s BigTable, Amazon’s SimpleDB, and Microsoft’s SQL Data Services (at least the first available incarnation of it).  

Since it’s mostly popular with the Ruby and Python crowds, there isn’t a whole lot of effort being put into .NET libraries, but they do exist.  The SharpCouch library, part of the couchbrowse project on Google Code, is the main one that I’m aware of, but I believe there are others.

Definitely something that merits more investigation.  I’ll just squeeze it in alongside my experimentation with Mono, NHibernate, Rails, and the myriad of other goofy things that I continue to fill my free time with.

When I was up in Bentonville, AR speaking at the Northwest Arkansas Code Camp, I came across an issue of ASP.NET Pro magazine with the title “The LAMA Stack” (short for Linux, Apache, MySQL, and ASP.NET).  The article inside turned out not to be that interesting, but the idea of using ASP.NET with an otherwise completely open-source stack certainly is.  

One of the things that is said to deter many startups or other small shops from using the Microsoft platform is the licensing cost of its products, particularly SQL Server.  But since Mono allows us to run .NET code on Linux, all of those costs can be eliminated.  Also, since the ASP.NET MVC framework was released as MS-PL (Microsoft’s most permissive open-source license), the Mono team was able to quickly integrate that into their framework as well.  

Since I want to start my own business one day, it ocurred to me that this could be a great way to leverage my existing skills, but use a modern web framework (MVC) and not have to put up a huge upfront investment.  And yes, I know about BizSpark, the program that gives startups free Microsoft software, but that deal “expires” after 3 years.  And if your business isn’t exactly booming at that point, then you may be stuck with an application that you can’t afford the licenses for.

So I decided to start experimenting with Mono to see if it was easy enough to work with that it would even be a viable option for me.  I’m not the most Linux-savvy guy in the world (as you may already be aware from reading some of my previous posts), and there was a distinct possibility that it would simply be too much of a headache for it to be worth it.  

I started out with the  VMWare image that’s available on the Mono project site (www.mono-project.com), and tried some basic “Hello, World” stuff, and that worked just fine.  Even getting an app running under Apache rather than the MonoDevelop IDE was really easy with the AutoConfiguration feature they’ve implemented.  The problem started when I tried to run an MVC app under Apache.  Because AutoConfiguration depends on the ASP.NET file extensions (“.aspx” et al.) to work, and MVC apps avoid those extensions, they can’t be used together, so I had to delve into defining an Apache virtual host for the MVC app.  Thankfully, the Mono team has provided a great tool for generating most of the boilerplate configuration for a Mono ASP.NET app on the project site (http://go-mono.com/config-mod-mono/).  

The next problem was that the version of Mono that supports MVC (v. 2.4) wasn’t available yet on the Linux distribution that I run, Ubuntu, which only has a package published for version 2.2.  That meant that I would need to compile Mono and several other tools from source, which is a somewhat daunting proposition for someone not very experienced with compilation on a Linux system.  I found a great resource for this, though, on the blog of a BlogEngine.NET team member named Russell (couldn’t find his last name) here: http://blog.ruski.co.za/page/Install-Mono-on-Ubuntu.aspx.  This post gives step-by-step instructions on getting Mono 2.4 running on Ubuntu, and without it, I would probably still be banging my head against the wall.

After much trial and error, I finally achieved my desired result.  I was able to run an ASP.NET application that was created and compiled in Visual Studio on Windows, copied over to a Linux machine and executed under Mono.  It wasn’t the most frictionless experience in the world, by any means, but after having done it once, I think subsequent apps will be easy enough to set up.  I’ll be doing the setup process at least one more time in the near future; I’d like to get Mono apps running on the servers we have set up for the new open-source shared interest group that I’ve recently joined with several other Praeses employees, which we’ve decided to call Samurai Delicatessen .  If I can manage to do the setup remotely over SSH, I think I can safely say it’s a stack that I’ll be able to handle using in the future.

Last Monday (yeah, I know, I’m a week behind), the Shreveport .NET User Group for the first time this year.  I have to say, I think it went much better than last time.  Not only did we have an experienced speaker in David Penton, but we actuall had pizza, too!  Seriously, Brandy at Software and Services did a great job coordinating the food and drinks, and things went off without a hitch.

Everyone seemed to enjoy David’s talk on HttpRuntime.Cache Management.  All 8s and higher on the evaluations!  If you’d like to see his presentation slides and sample code, check it out here, or you can download it from the SDNUG site here.

Next month, we’re going to have another Microsoft MVP (and newly minted INETA speaker), Tim Rayburn come out and speak about parallelism features in .NET 4.0, which ought to be really interesting.  Come out and join us on February 16th at Centenary College!

On Dec. 2nd, I passed my second Microsoft exam, 70-536 – Application Development Foundation.  The test was honestly more difficult than I expected it to be.  When I started studying for it I thought, “Foundation… well, I’ve been programming in .NET for about 2-3 years, so I figure I’m probably good on the ‘foundation.’”  Well, it turns out, “foundation” didn’t really mean what I thought.  Based on the subject matters covered on the exam, I have deduced that foundation in this case means “APIs that you’ve never used before professionally and may never have occasion to, but ones that we feel are important enough for you to know down to parameter order.”  A large part of the exam covered Code Access Security, which honestly still confuses me, and for which I continue to try to find a reasonable use case.  I’m sure one is out there, and it may have greater usefulness in the desktop realm, but for me right now in ASP.NET land, it seemed like an odd choice of emphasis.

I didn’t do nearly as well on the test as I would have liked, but, hey, a pass is a pass, right?  I think my initial thoughts about how difficult the test would be caused me to study a bit less than I should have.

But I did pass, and so afterward, I got myself a new toy.  That’s right folks, I am the proud owner of a new iPhone 3G (16Gb).  I’ve been wanting a smartphone for a while, and my account was finally eligible for a phone upgrade.  My old phone, a Motorola L6… well, let’s just say if the iPhone is “smart”, the L6 would be on the mobile phone short-bus.

Having never owned a smartphone before, I didn’t come into things with the expectations or priorities of a veteran WinMo user, and I have to say, I’m quite satisfied.  The three things I wanted out of my new phone were: 1. mobile access to email, 2. mobile web browsing, and 3. ability to hold all my music and podcasts so I can eliminate a separate device from my life. The iPhone does all three of those things to my complete satisfaction.  Everything else is just a bonus, really.  One of the things I was pleasantly surprised about is how well I’m now able to keep up with my RSS feed reading.  I don’t have to actually be sitting down at a PC to keep that “Unread” total to a manageable number.

The one thing that I had reservations about was the ability to program the device.  Since I’m a developer, I’m used to being able to write small tools for myself if I can’t find something out there that fits my needs, but it’s not quite as easy to do this for the iPhone as it would be if I had gotten a Windows Mobile device.  The only Mac I have is currently hooked up to my TV as a media server, and programming over VNC is not really the best experience.  Plus, I’d have to learn Objective C and the Cocoa Touch library, and that’s just one more thing that I probably don’t have time for.  I’m excited to see what Miguel de Icaza and the Mono team are doing to get .NET code running on the iPhone, and I’m looking forward to being able to write in a language that’s familiar to me at some point.  They’re doing it in a legit way, don’t worry.  They get around the “no JITed code” device restriction by using a static linker (I believe that’s the correct term), so that the code that’s executed is 100% native instructions.

Once I’ve had the device a bit longer, I may have some more comments, and be able to list of my favorite apps.  Right now, though, I have to get my two newest WoW characters to level 60 before the account link runs out!

As I’ve posted before, I’ve been trying to help my pastor with a church management system written in Rails, but I’ve been hitting some roadblocks.  First, I tried developing on my Mac Mini, since Macs are what all the cool kids use to develop for Rails.  Well, that Mini ended up being a media machine, and developing using a television as a monitor was not very pleasant. It’s not an HDTV, and so only capable of 800×600, but even at that resolution, the screen is practically unreadable. 

The most convenient thing for me to do would be to develop on my laptop, since I can take it with me and work with Lowell (my pastor) up at the church on the system when I have problems.  So, I started trying to get the app set up on my Windows machine.  This actually worked fine for a while, but then Lowell ended up adding a couple of gems called “starling” and “workling” that basically create a task queue that you can farm out long-running tasks to.  It works great on Lowell’s Mac and in the production environment.  However, I soon discovered that starling uses “fork()” to achieve its ends, which meant a no-go for me on my Windows machine.

Since I can’t exactly install OSX on my laptop, the only option left was Linux.  As I’ve written about before, at one point I had Ubuntu installed on a partition on my laptop, so I’d been down that road before.  However, I had actually recently removed the Linux install, since I really wasn’t doing anything with it, so I had to go through the install process again (which is actually not all that bad on Ubuntu, for what it’s worth).  I installed Ubuntu version 8.10 (Intrepid Ibex) on a 15 Gb partition and began the environment setup process.

The very next day at work, a coworker happened to mention a virtualization tool he was using called VirtualBox.  I can’t believe I hadn’t heard about this thing before.  I knew about Virtual PC, which Microsoft now gives away for free, but that obviously only allows Windows guest OSes.  VMWare does have a free VM “player” that supports different kinds of guests that they give away, but as far as I know the tools you have to use to create a VM cost money. VirtualBox, developed by Sun, is completely free and allows for a whole slew of both host and guest OSes.  Anywho, I gave it a try, and I was very impressed.  It’s quite performant, and has support for just about everything I think I’d want (networking, USB devices, etc).  Another nice feature is that the virtual disk file can be set up to grow dynamically so that the VM is only taking up the space it needs; no more, no less.

It then became obvious that the 15 Gb partition I was using for my Ubuntu install was kind of a waste of space.  So I started the process of removing the partition I had added just days before.  I want to record what I did to achieve this, mostly as a record for myself in case I need to do it again later.  I used a free tool called GParted, which comes as a bootable CD image, to delete the partition Ubuntu was installed on and resize the main partition to take up the newly freed space.  After that comes the part that I usually forget, which is fix the master boot record.  When you install Ubuntu, you get this thing called GRUB, which is a boot loader that will let you choose which OS to boot up when you turn on your machine.  When you delete the partition with Linux on it, GRUB freaks out and won’t load up an OS.  To fix this, you need your Windows install CD.  Boot from the CD, then (depending on your version of Windows) either start a Recovery Console (XP), or choose “Repair Computer” and then open a console (Vista).  On XP, type “fixmbr” (no quotes), and on Vista, type “bootrec /FixMbr” (again, no quotes).  This will repair your master boot record, and you should be all set after a restart.

Since I’ve been having all this fun the past couple of evenings, I have not gotten as much sleep as I need.  I’m greatly looking forward to the two holidays off work I’ve got coming, as I’m sure you all are.  I hope everyone has a happy Thanksgiving!