Samsung Intercept

I'm notoriously frugal, which is why when I read from Robert Cringely's prediction of the demise of Feature phones, I thought he was overly optimistic. When someone disdains monthly cell phone plans, what other options are there for a cell phone but a feature phone?

Well, it turns out, there are a few options out there. In fall of last year, Virgin Mobile started offering the Samsung Intercept, a phone with Android 2.1. The initial price was steep ($250!), but it was a fully loaded smart phone, on a pre-paid plan! Of course, if you wanted data, you're better off with a monthly plan, but these plans are ridiculously priced. For $25 a month, one can get unlimited data, texting, and 300 minutes.

It all sounds good on paper, especially if you were to compare phone and data plans with other carriers. The reduced monthly price (at expense for higher hardware costs) pays for itself in about a year.

Needless to say, I eventually bought the phone (on sale after Christmas for $180) and have been using it for 5 months. I honestly can say I don't know how I operated without this device. Prior to this, I had a cheap phone for calls, an MP3 player to listen to music at work, an old Pocket PC for reading and writing, a Tom Tom GPS in the car for directions. This device has replaced them all and then some.

I use the sliding Qwerty keyboard all the time to write notes, search the web, or even write blog posts. The on screen keyboard is a little cramped, but is handy with the auto-sense.

I have better success with navigation on the phone vs. Tom Tom. This is largely because the GPS device's maps are a few years out of date and map updates cost so much, I might as well buy a new device.

I have a lot more storage on the phone as compared to my MP3 player, so I can keep a much larger music collection on hand. And if I get bored of that, there's always YouTube and Pandora.

With Amazon's Kindle application, reading is much easier on my phone compared to my old Pocket PC. I've finished a few books on the device, plus read hundreds of articles using the InstaFetch application that synchronizes with my InstaPaper account.

Finally, I've taken many more pictures with the phone's camera thanks to it always being in my pocket. Uploading to Facebook can be a bit difficult (as it doesn't always recognize orientation), but I've installed the application PicSay to handle this when the native application fails.

All told, I'm still loving my Droid phone. It was upgraded to Droid 2.2 about a month ago. The only downside here is that during the upgrade, the note application, which I had saved a dozen notes in, was removed and I lost all of the notes. This warning was clearly stated, but unfortunately, I did not heed the warning.

.NET Decompile Tools

For many needing a tool to decompile a .NET assembly, the tool of choice has been Red Gate's Reflector. This tool is one of the fastest tools out there and the decompiled code it displays is often somewhat intelligible (of course, THAT depends on the underlying quality of the code). But, recent changes to the licensing of Reflector have left many .NET developers scrambling for their wallets or for an alternative. Here's a few alternatives to .NET Reflector.

JetBrains DotPeek

This is my favorite replacement for .NET Reflector. It feels a little slower than Reflector, but the code it decompiles is very readable. Each variable that the decompiler has to name, it attempts to find a somewhat sensible name.

This tool will decompile the AssemblyInfo.cs as well, so any assembly properties will be available.

DotPeek requires .NET 4.0 but does not require registration.

Telerik JustDecompile

JustDecompile is comparable to DotPeek in many ways, but in the early build I tried, it did not decompile the AssemblyInfo.cs. While the variable names were also reasonably named, since it can't decompile the AssemblyInfo.cs file, JustDecompile is an incomplete replacement for Reflector.

JustDecompile does require free registration.

Conclusion

There are still other tools to decompile .NET code, but Reflector, DotPeek, and JustDecompile are all powerful tools that are supported by major vendors in the .NET ecosystem. As such, they bring a lot of clout to these solutions and have the support team in place to maintain such a tool. At the end of the day, JustDecompile lacks the ability to decompile the AssemblyInfo.cs. If this is important to you as it is to me, you will want to look at DotPeek instead.

How rake db:migrate works

When I first started developing Rails applications, the Database migrations with ActiveRecord seemed so much more advanced then anything I've worked with in .NET (and I've used ADO.NET, LINQ-to-SQL, and Nhibernate). The migrations seemed so intuitive, powerful, and magically. Unfortunately, when the magic doesn't work, you need an understanding of the underlying architecture to fix it.

The Problem

The other day I rolled out a Production update for Kanban for Developers. In it were 2 migrations that added a new integer column to 2 different tables and a bit column to a third table. The migration passed local validation, but when I went to deploy it to production, I issued the command:

rake db:migrate RAILS_ENV=”PRODUCTION”

But running this command gave me an error stating that it couldn't add a duplicate index. The migration name provided was created in the middle of last summer. There have been numerable migrations since then, so for some reason, the system thought this migration had been skipped.

Now, there's a couple of ways to fix the problem. The first, and easiest would have been to remove the index from the database and re-run the command. However, I wanted to learn how db:migrate operated, so I began to look around for something to indicate the migrations that had been executed on the database.

Schema.rb

The first place I began to look was within the folder structure of the web application itself. The db folder would be the logical place to store this kind of information. In this folder is the schema.rb folder, and as one might guess, it contains the schema information for the database.

The file in production had all of the latest additions, though the database itself didn't. Why? Because in my rush to move code to production, I had copied the entire db folder instead of just the migration folder or just the latest migration file. With the power of source control, I reverted the old file and re-ran rake db:migrate. At this point, I received the same error message.

schema_migrations

And the reason for this is because the migration information is stored within the database, and not a file, which of course makes much more sense. Databases are locked down much more then the file system, generally, and provide a much more logically place to store this information. For Rails, this information is stored in a simple table named 'schema_migrations' which contains a single column, the name of the migrations that have been applied.

Resolution

In the end, after ensuring the the index and all of the database changes from the missing migration had indeed been applied, I simply wrote an insert statement to add a record for the missing migration. After this, I was able to proceed with the new migrations and complete the build.

And the schema.rb file? It actually was updated to include the latest changes after I ran rake db:migrate. So while this file isn't how rake db:migrate determines whether a migration has been executed, it does document what database changes have been made in a location separate from the database.