Codesta Weblog

Basic Smartphone Support for your Ruby on Rails website

Building a maximum-compatability mobile website is a relatively large undertaking, and that's not what I'm talking about here. The latest smartphones have the ability to render HTML quite well, and just require a site design amenable to viewing on a small screen. This post is about one way to provide separate layouts based on the user-agent of the device hitting your website in Ruby on Rails. It is a rather simple approach intended to get you started as opposed to being a production ready example.

How to detect a mobile browser?

So, jumping right in... how do you detect a mobile browser?  I'm sure there a fair number of ways, but I chose to use the WURFL library (which you should download - the download link is the first one in the left column of the home page).  A quick Google search provided me with the WURFL-Lite gem which provides a thin layer on top of the WURFL data making it quick and easy to integrate it into our site. This is a "big-stick" approach as WURFL contains way more information about the device than we need at this point, but it would allow you to customize your site based on the capabilities of the device in the future. To add the gem to your project just add the following line to your Gemfile:

gem 'wurfl-lite'

Then run bundle install to install the gem on your system. Note that this gem does not store the data in a database, it reads it all into memory - depending on your needs this may or may not be the right approach.

Now that the gem is installed, open the application_controller.rb file - this is where we will be adding some helper methods that will be accessible to all of your controllers and views. First off, we need to load the WURFL data, which is going to take a while so we want to do it as few times as necessary. There are lots of different issues with trying to do this cleanly, so I'm going to start off with a simple approach; I'm going to store it as a class variable like so:

class ApplicationController < ActionController::Base
  @@wurfl_db = nil

  private

  def wurfl_db

    #Try getting the data from the cache, this

    #significantly speeds up performance in the

    #development environment.

    @@wurfl_db ||= Rails.cache.read('wurfl_db')

    if !@@wurfl_db
        @@wurfl_db = WURFL.new "#{Rails.root}/wurfl/wurfl.xml.gz"

        Rails.cache.write('wurfl_db', @@wurfl_db)

    end

    return @@wurfl_db
  end
end

To turn on caching add the following line to your environment.rb file:

ActionController::Base.cache_store = :memory_store

NOTE 1: In the development environment class variables are tossed between requests, meaning that we would have to load the WURFL data every time - which is quite slow. Using the rails memory store was a quick and easy solution, although there is still a small but noticeable decrease in responsiveness in the site. If you are trying to run some tests on your dev environment and the extra time taken to load the wurfl data is a problem, then I would suggest temporarily setting the config.cache_classes to true in your development.rb.

NOTE 2: If your web server uses multiple processes you will end up loading the wurfl database once for every process. Depending on how many processes you expect to run, that could be a lot of wasted memory. If that is the case then it might be worth investigating memcached or a similar caching store, or consider moving the data to the database.

Now that we have the WURFL data loaded into memory we can use it to identify the device browsing our site. Create a new helper method:

class ApplicationController < ActionController::Base
  @@wurfl_db = nil
  helper_method :is_mobile_request?

  private

  def wurfl_db

    #Try getting the data from the cache, this

    #significantly speeds up performance in the

    #development environment.

    @@wurfl_db ||= Rails.cache.read('wurfl_db')

    if !@@wurfl_db
        @@wurfl_db = WURFL.new "#{Rails.root}/wurfl/wurfl.xml.gz"

        Rails.cache.write('wurfl_db', @@wurfl_db)

    end

    return @@wurfl_db

  end

  def is_mobile_request?
    return !wurfl_db[request.user_agent].nil?
  end
end

Now you can call is_mobile_request? from any of your controllers or views to perform custom work for either mobile or desktop.  

Choosing your layout

As long as you have built your site using best practices (i.e. putting your styles into your appliction.css file instead of in-lining them in your html.erb files) then you can easily switch between layouts without having to make any changes to your views. You now have a choice, you can modify your existing layout to use the helper we created above or you can create separate layout files. I am going to go with the 2nd approach since I want a clean and obvious separation between my mobile and desktop versions of the site.  We can do this right in the application controller:

class ApplicationController < ActionController::Base
  @@wurfl_db = nil
  layout :determine_layout
  helper_method :is_mobile_request?

  private

  def wurfl_db

    #Try getting the data from the cache, this

    #significantly speeds up performance in the

    #development environment.

    @@wurfl_db ||= Rails.cache.read('wurfl_db')

    if !@@wurfl_db
        @@wurfl_db = WURFL.new "#{Rails.root}/wurfl/wurfl.xml.gz"

        Rails.cache.write('wurfl_db', @@wurfl_db)

    end

    return @@wurfl_db

  end

  def is_mobile_request?
    return !wurfl_db[request.user_agent].nil?
  end

  def determine_layout
    if is_mobile_request?
      return "mobile_application"
    else
      return "application"
    end

  end
end

Next you will need to create a couple of new files.  A public/stylesheets/mobile_application.css stylesheet, and an app/views/layouts/mobile_application.html.erb layout file. You can probably start with a copy of your application.css and application.html.erb.  There are a whole bunch of things that you might want to do in your mobile layout and styles that are beyond the scope of this article, but a couple of key items are:

• Load your new mobile_application.css style sheet instead of the application.css
• Add a <meta name="viewport" content="width=device-width, initial-scale=1.0" /> element to the <head> section.  This will set the width of your website to the width of the display.
• Update your mobile stylesheet so that clickable items have a fair bit of space between them or are otherwise large.  Touchscreen finger presses cover a relatively large area.
• Create icons for your site - this is unfortunately very phone specific, but you can add links to icons that phones will use to identify your site. e.g. <link rel="apple-touch-icon" media="screen and (resolution: 163dpi)" href="icon57x57.png" />
• You may also want to provide the option for overriding the layout choice so that a user can choose to view the mobile or desktop site in case the device detection fails.

Checking that it works

If you have a mobile phone handy then just hitting your website should give you an idea as to whether it is working or not. If you don't have one handy then you can use one of any number of browser add-ons/plug-ins. I use the Modify Headers add-on for Firefox and set a User-Agent header with the user agent string for whichever phone I want to emulate. This is especially useful if you are doing something specific for a particular set if phones but don't have them all on hand to test with. Another option is to set up an Android development environment and created a bunch of virtual devices with different screen sizes and use the emulator to test your site.

Thoughts on the failure of Google Wave

When Google Wave was first announced I was among the many people who were very excited about the potential.

I realized at the end of July that my Google Wave account had no activity since March and started thinking about why that was. I started writing this article with the intent of describing why I thought Wave hadn't taken off when the cancellation announcement was made. So, after revamping, this is why I believe Wave failed as a product.

It fixes email: Why we were excited in the first place

The only reason the failure of Google Wave is interesting is because of how much excitement it generated when announced. When I first saw the Wave video it demonstrated what seemed like viable solutions to some of the major problems with email:

1. I can fix typos, mistakes and even factual errors after a message is sent.
2. There is excellent threading and management of replies. 
3. People can join the conversation and stay joined. People can be added that were inadvertently left off the original invite list and immediately join the conversation.
4. Attachments are only sent once and then are always available. No digging through my archive for the original message and attachments.
5. Email can't switch to real-time. Wave is real-time. I often leave email and IM somebody when the emails are flying fast.

The promise of improving email was an elixir and we all waited to drink with bated breath.

It's not email: Why it failed

It solves some of the problems with email by eliminating email, but then introduced a whole new set of problems which broke a whole bunch of things that email fixes!

My Head Hurts

One of the coolest superhero powers is mind reading. It's also one of those superhero powers that would never work in real life. Having this power would make simple things like going to the mall a hell on earth; the thought noise of hundreds of insipid teenage shoppers, bored store clerks, shoplifters, flirting couples, etc. would drive you mad.

This is Wave in a nutshell. If it did replace email and IM, my inbox would be a non-stop cacophony of line noise; PM's composing emails, proposals being written, the first half of a note from my wife about plans for tonight, job applicants responding, friends arranging events, urban legends from my Mom ...

And this noise couldn't be ignored like twitter. Half of those responses would be information I was waiting on.

HR Hates Me Now

Depending upon your communication style Wave could be disastrous. I tend to type messages and then edit them; or think better of some ill advised comment and delete them entirely. In Wave I'd be either inadvertently insulting or look like a moron until I corrected my messages.

Like laws and sausages; nobody should see how my email and IM messages are made.

Why Am I Using this Again?

My entire dev team created accounts and we played with it for a couple of days but then haven't used it in a couple of months. We are heavy users of IM, Yammer and Email but couldn't really see a use for Wave.

Communication tends to take two forms: quick comments/questions with a quick follow-up or deliberately worded communications. We have IM and Yammer for the first and email for the second. Wave is a poor substitute for IM and is, if you don't need real-time email, a closed network email system.

Real-time collaboration is something you do rarely and it's almost always a document, a design or code. Wave doesn't help with design (mostly a white board activity) or code (mostly a pair programming activity). We have Google Docs for real-time document collaboration now.

Wave promised to merge IM and Email but that didn't really pan out. You still need IM after all.

Spam

As somebody who worked in the Anti-Virus/Anti-Spam industry for years my first thought was "Cool, an entirely new vector for spam and viruses." Sure enough, a Spam button appeared soon after. In a closed environment.

All Those Technical Problems

The slow, uneven roll out meant that whenever you finally got access to Wave, your friends were either bored with it already or were stuck waiting on Beta invites. Contrast this with Gmail where I got an early beta and then immediately got five invites that also worked immediately. Also, with Gmail, I was able to test it using other email services. I applied for developer preview access which I didn't get, then had 2 beta invites sent to me that never arrived and finally got access on the 3rd beta invite in February of this year. That's not the way to build ground swell support.

There are a large number of user interface issues that exist in Wave that make it unsuitable for it's primary purpose of real-time communications. The way everything jumps around if more than one person is editing at a time, selecting the section you want to edit is error prone and you will often miss; it's more like a game of TF2 than an editor. The new versions of the UI were better but it's kind of moot now.

The versioning system is terrible; rollback is not a viable versioning mechanism.

It's a closed system. The only use I could see for Wave is taking an email Exchange "real-time". Since it's not email this feature is not even available.

No data import or export. I've just collaborated with a co-worker and come up with a great new idea; now how do I get that stream of data into a Word document to send to a VC to make us all rich? I can't.

Out with IE6, Please In with the New

Sometimes we come across articles that are so near and dear to our hearts we feel we just to need to share them again. One such topic is Microsoft's Internet Explorer 6. Many times we're asked why development efforts cost extra, or worse "so much more", when clients include IE6. It's always a hard question to answer, but we try, often with mixed results. Similarly Tom Conlon, writer for Popular Science, remarks:

"...Those unfamiliar with the Internet Explorer 6 saga might wonder what the big deal is."

It's for this reason that we had to read Tom's article "Inside the Excruciatingly Slow Death of Internet Explorer 6" published March 1st, 2010 on popsci.com. In his article, Tom shares key reasons for why the industry has been so slow to move off IE6, including:

1. It's estimated that 20% of Internet users are still using the browser! Wow, considering it's almost 10 years old.
2. IT Drag - Enterprise IT departments, particularly those in slow moving industries like Pharmaceuticals and Medicine, are hesitant to install new clients and invest in new development efforts to make existing systems just work.

Tom, and many others, theorize that there are other drivers extending IE6's lifespan. Regardless, IE6 remains a standards non-compliant browser (no CSS support for instance) and a headache for developers worldwide. Unfortunately, this headache is going to last a while with Microsoft officially supporting Windows XP, including IE6, through April 8th, 2014.

Tips and Tricks with Visual Studio

Visual Studio Setup and Deployment Project Tips and Tricks

Setup and deployment projects were a welcome addition to the Visual Studio project templates. They have allowed many a developer an easy way to quickly produce installers for their applications. However, as with most of Microsoft's offerings, you only get so far out of the box and most real-world use cases require one to delve a little further into the workings. So, let us delve!

Having recently created an installer for a web application using the Setup and Deployment project template and after spending much time on Google searching for ways to do certain things, I thought it might be helpful to collect some of my findings together so that others may benefit (and so I have somewhere central to find these answers again next time!).

There are two main areas with respect with respect to deployment projects that I would like to focus on - the use of Custom Actions and Bootstrapping. For an introduction to and basic information regarding Setup and Deployment projects, you can take a look here and here.

1. Custom Actions

Briefly, custom actions allow you to hook into the installation pipeline of the Microsoft Installer. They allow developers to add customized logic (such as creating a database) as part of the installation process and it is through them that you will enhance your installer. Through custom actions, you can add custom logic to any or all of the following phases of installation:

• Install
• Commit
• Rollback
• Uninstall

Each phase corresponds to a public method you can override in your custom actions class and insert required logic. See this for information on creating custom actions and adding to your Setup and Deployment project.

Now that we understand that custom actions are the means by which we can extend Setup and Deployment projects and add additional actions to be performed during installation, let's take a look at some of the basic tasks I have needed to do within an installer that were enabled through custom actions:

1. Creating a database
2. Importing data
3. Adding a desktop shortcut
4. Updating web.config
5. Adding ASP.NET services
6. Handling errors
7. Debugging your custom actions

1. Creating a Database

   While creating a SQL Server database does not require large amounts of math, here I mainly wanted to highlight the awesomeness of the SqlConnectionStringBuilder class. The existence of www.connectionstrings.com proves that I'm not the only one who draws a blank sometimes on proper connection string format! The SqlConnectionStringBuilder class builds it for you (surprise!) which can be very helpful (especially for SQL Express databases). Note the creation of a Trusted connection (connStrBuilder.IntegratedSecurity = true;)

    private void CreateDB(string dbServer, string dbName)
    {
     SqlConnectionStringBuilder connStrBuilder = new SqlConnectionStringBuilder();
     connStrBuilder.InitialCatalog = "master";
     connStrBuilder.DataSource = dbServer;
     connStrBuilder.ConnectTimeout = 5;
     connStrBuilder.IntegratedSecurity = true;
   
     string sql = string.Format("CREATE DATABASE {0}", dbName);
     SqlCommand cmd = new SqlCommand(sql, conn);
   
     //Init connection, open and set db
     conn.ConnectionString = connStrBuilder.ConnectionString;
     cmd.Connection.Open();
     try
     {
     cmd.ExecuteNonQuery();
     }
     catch (Exception ex)
     {
     throw ex;
     }
     finally
     {
     cmd.Connection.Close();
     }
    }
   						

   You would call the CreateDB from the Install method as follows:

    public override void Install(IDictionary stateSaver)
    {
     serverName = this.Context.Parameters["dbServer"];
     databaseName = this.Context.Parameters["dbName"];
   
     CreateDB(serverName, databaseName);
    }
   
   						

   You'll note the references to Context.Parameters - the Parameters collection is how information collected by the installer is made available to you in your custom actions. In this example, I had added a custom dialog box to the installer with two textboxes for gathering the names of the database server and database to create. On the Custom Actions view of my Setup and Deployment project, I have set the CustomActionData property to indicate that I want the value from textbox CUSTOMTEXTA1 to be available as dbServer and the value from textbox CUSTOMTEXTA2 to be available as dbName. I have also set the selected target virtual directory name as TGTVDIR. These values are then made available to me in Context.Parameters in my custom action.

   
   

   	/dbServer=[CUSTOMTEXTA1] /dbName=[CUSTOMTEXTA2] /TGTVDIR=[TARGETVDIR]
   						

2. Importing Data

   Any developer who has experience with MySQL, specifically with backing up (bless you, mysqldump) and restoring a database, simply cannot understand why the task is not as smooth with SQL Server. One will quite often wish to create a database and fill it with data as part of the installation process, which with MySQL is dead simple.

   As a solution, Microsoft now has their Database Publishing Wizard, which makes things much easier - here at last is an easy way to script a database. However, I ran into an issue in using (finding) the tool and in my search engine travels I noticed I wasn't the only one so I'll call out the obvious now. The original Database Publishing Wizard was introduced as an easily found and downloadable add-on to SQL Server 2005. Since the introduction of SQL Server 2008, the downloadable version was apparently done away with and the functionality is now an included feature. Thus you will find many Microsoft blogs/articles etc. insisting that Database Publishing Wizard should show up as a context menu item in both Visual Studio 2008 and within SQL Management Studio when you right-click on a database node - it does not. At least not for myself and a host of other developers with access to google (see here for an example). However, right-clicking on a database node and selecting Tasks->Generate Scripts will give you the payoff you're looking for. I never did find out why the discrepancy and I lost interest after I found the indicated solution.

   My main reason for wanting to talk about importing data is due to an issue I encountered with running my database install script. It seems to be specific to SQL Server 2008, but I am not 100% certain of that. The problem I encountered is that SQL Server would run out of memory while running my import script! The exact error I was getting is "There is insufficient system memory in resource pool 'internal' to run this query". I was trying to execute the script in one go using the ExecuteNonQuery() method of SqlCommand class and even though it wasn't a particularly long script, I kept encountering the problem (there appears to be some known issue with SQL Server in this regard - see this article for more information). Suffice it to say that my interest lay (and lies) not in tracking down or even understanding SQL Server issues but in writing code so I needed a solution that didn't involve me tinkering with or reading any more about SQL Server 2008. The long and short of it is that in order to run the data import script, I had to break my script into individual commands and run them one by one (oh, and restarting the SQL Server service is also helpful). The code snippet below shows this process:

    private void ExecuteSql(string dbServer, string dbName, string sql)
    {
     SqlConnectionStringBuilder connStrBuilder = new SqlConnectionStringBuilder();
     connStrBuilder.UserID = "MyDBUserId";
     connStrBuilder.Password = "MyDBUserPassword";
     connStrBuilder.InitialCatalog = "master";
     connStrBuilder.DataSource = dbServer;
     connStrBuilder.ConnectTimeout = 5;
   
     SqlCommand cmd = new SqlCommand(sql, conn);
   
     //Init connection, open and set db
     conn.ConnectionString = connStrBuilder.ConnectionString;
     cmd.Connection.Open();
     cmd.Connection.ChangeDatabase(dbName);
     try
     {
     string[] commands = sql.Split(new string[] { "GO\r\n", "GO", "GO\t" }, StringSplitOptions.RemoveEmptyEntries);
     foreach (string c in commands)
     {
      cmd.CommandText = c;
      cmd.ExecuteNonQuery();
     }
     }
     catch (Exception ex)
     {
     throw ex;
     }
     finally
     {
     cmd.Connection.Close();
     }
    }
   						

   Hope this is helpful to someone.

3. Adding a Desktop Shortcut

   For desktop applications, creating a shortcut using the Setup and Deployment project template is quite simple. However, to create a shortcut to a web application is a little more involved (or can be). For a recently developed web application, I created an installer that allowed the user to set the web server and the virtual directory into which to install the application. I then needed to dynamically create a shortcut to the application using the user-set values. I accomplished this through a custom action as shown below.

    private void CreateShortcut()
    {
     string vdirPath = this.Context.Parameters["TGTVDIR"];
     System.Configuration.Configuration config = WebConfigurationManager.OpenWebConfiguration(string.Format(@"/{0}", vdirPath));
     string path = config.FilePath.Replace("web.config","");
     string shortcutFileName = string.Format(@"{0}\MyWebApplication.lnk", Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory));
   			
     WshShellClass shell = new WshShellClass();
     IWshRuntimeLibrary.IWshShortcut shortcut = (IWshRuntimeLibrary.IWshShortcut)shell.CreateShortcut(shortcutFileName);
     shortcut.TargetPath = string.Format("http://localhost/{0}", vdirPath);
     shortcut.Description = "Launch MyWebApplication";
     shortcut.IconLocation = string.Format(@"{0}MyWebApplication.ico",path);
   			
     shortcut.Save();
    }
   						

   NOTE: In order to use the WshShellClass class, you will need to add a reference to the Windows Script Host Object Model COM object.

   
   

4. Updating web.config

   Sometime you want to update the web.config your application ships with to reflect the user's environment without having the users edit the file themselves. For example, after asking the user for the name of the database server/database and creating the database, you will want to then update the web.config with new connection string information. How/where should this be done? You guessed it! In a custom action:

   	private void UpdateWebConfig(string connectionString)
   	{
   		//virtual directory passed in from installer in CustomActionData
   		string vdirPath = this.Context.Parameters["TGTVDIR"];
   
   		try
   		{
   			//open the web.config
   			System.Configuration.Configuration config = WebConfigurationManager.OpenWebConfiguration(string.Format(@"/{0}", vdirPath));
   
   			//change the connectionString for the DB
   			config.ConnectionStrings.ConnectionStrings["MyAppsConnectionStrings"].ConnectionString = connectionString;
   			config.Save();
   		}
   		catch (Exception ex)
   		{
   			throw ex;
   		}
   	}
   						

5. Adding ASP.NET Services

   Adding ASP.NET services (membership, profiles etc.) to your SQL Server database is normally accomplished using the aspnet_reqsql.exe command line tool, but you can also accomplish this programmatically within your custom action. Instead of trying to execute the actual aspnet_regsql.exe using System.Diagnostics.Process.Start(), there is an easier way built into the .NET framework:

   	//Add ASP.NET membership service
   	SqlConnectionStringBuilder connStrBuilder = new SqlConnectionStringBuilder();
   	connStrBuilder.InitialCatalog = "master";
   	connStrBuilder.DataSource = serverName;
   	connStrBuilder.IntegratedSecurity = true;
   	SqlServices.Install(dbName, SqlFeatures.All, connStrBuilder.ConnectionString);
   						

   Where the SqlFeatures enum has the following values:

   • None
   • Membership
   • Profile
   • RoleManager
   • Personalization
   • SqlWebEventProvider
   • All

6. Handling Errors

   When something unexpected goes wrong during the installation process, the installer automatically rolls back any changes it has made during the incomplete installation. However, this does not extend to any custom actions performed by you. If there are any changes that your custom action code performed that should be undone, you must undo them yourself by hooking into the installer's Rollback phase. To hook into the Rollback phase, you must override and implement the Rollback method in your custom actions. For example, the following custom action Rollback code deletes the database that was created in the Install method:

    public override void Rollback(IDictionary savedState)
    {
     base.Rollback(savedState);
     //Remove database if we are rolling back for
     //any reason other than because the selected 
     //DB exists (if it does, we don't want to delete an existing DB -
     //it might have useful data
     if (!((bool)savedState["dbExists"]))
     {
     SqlConnection.ClearAllPools();
     Server server = new Server((string)savedState["serverName"]);
     try
     {
      server.Databases[(string)savedState["dbName"]].Drop();
     }
     catch (Exception ex)
     {
      MessageBox.Show(ex.Message);
     }
     }
    }
   						

7. Debugging Your Custom Actions

   Before we leave our discussion of useful tasks to perform in a Custom Action, you may want to know how you go about debugging your custom actions (remember, your custom action code is executing within the context of Microsoft Installer, so you can't simply press F5 in Visual Studio and start debugging). Like debugging any other external code, you can attach directly to the running installer process using the 'Attach to Process' command from the Visual Studio Debug menu, or (simpler) you can force a debugger break in your custom action code which will invoke the debugger and start debugging from the point of the break. See below:

    public override void Install(IDictionary stateSaver)
    {
     System.Diagnostics.Debugger.Break();
   
     //Custom action code...
    }
   
   						

So there you have it - hopefully the explanation of some of these common installation activities that can be performed using custom actions has been useful for you. Now let's talk a little about installer prerequisites.

2. Prerequisites and Bootstrapping

Most applications developed with Visual Studio will have some sort of dependency upon one component or another and will require that said components are installed on the machine before the application will run/install (e.g. a particular version of the .NET framework, Crystal Reports, Sql Server etc.). Setup and Deployment projects allow you to install other components as part of the installation of your application (a process known as 'bootstrapping'). Visual Studio comes with several components to get you going and, with a little effort you can create your own bootstrap packages for components not included with Visual Studio. Visual Studio 2008 comes with the following prerequisites:

• .NET Framework 2.0
• Visual C++ Runtime Libraries
• Windows Installer 3.1
• .NET Framework Client Profile
• .NET Framework 3.0
• .NET Framework 3.5
• Crystal Reports Basic for Visual Studio 2008
• Microsoft Office 2007 Primary Interop Assemblies
• Microsoft Visual Studio 2008 Report Viewer
• Sql Server Compact 3.5
• Microsoft Visual Basic PowerPacks 1.2
• Visual Studio Tools for the Office system 3.0 Runtime Service Pack 1
• SQL Server 2005 Express Edition SP2

All the required information for the various Bootstrapper packages are defined using xml files that Visual Studio consumes to find and understand everything about a package (what files are included, any related products or prerequisites, what to do on install error etc.).

1. Specifying Prerequisites

   To specify prerequisites for your application, select Properties for your Setup and Deployment project and click the "Prerequisites" button.

   
   

   This will bring up a list of available bootstrapper packages on your machine.

   
   

   Note the section for specifying install location. If you wish to include the prerequisite binaries as part of your installer instead of the user needing to download them as needed (e.g. think of an installation that must be accomplished without internet access), then you can tell Visual Studio to download them from the same location as your application, which will package the prerequisite with your installer (and potentially bloat the size tremendously - e.g. the .NET Framework 3.5 SP1 package adds 191MB to the installer!).

2. Custom Prerequisites

   It is possible for a developer to create their own bootstrap packages that will be detected by Visual Studio and thereafter added as a prerequisite to a Setup and Deployment project. The list of boostrapper packages available to Visual Studio is generated based upon available packages in the \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\ directory.

   
   

   In order to make new prerequisites available to your Setup and Deployment projects, you must create your own bootstrapper packages and deploy them into this directory. While it is possible to create the requisite xml describing the package by hand, you will make your life so much easier if you make use of a Microsoft tool called the Bootstrapper Manifest Generator (BMG), available here. The BMG tool guides you through various options for your package using an easy GUI and once you have made various selections regarding your package, it will then compile the results for you into xml files (product.xml and package.xml). See the included help file for more information. Oh, by the way make sure you explicitly set the exit code for success - I had a package that kept failing with the message "Installation successful" (very confusing, that!). It turns out it was because relying on the default treatment of system exit codes was not sufficient and I had to explicitly set exit code 0 as a success code.

   As an example, here is the product.xml and package.xml code for a bootstrapper package I created for the ASP.NET MVC runtime:
   

   product.xml:

   ?<?xml version="1.0" encoding="utf-8"?>
   <Product ProductCode="ASP.NET.MVC" xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper">
    <RelatedProducts>
   	<DependsOnProduct Code="Microsoft.Net.Framework.3.5.SP1" />
   	<DependsOnProduct Code="Microsoft.Windows.Installer.3.1" />
    </RelatedProducts>
   						

   
   package.xml:

   ?<?xml version="1.0" encoding="utf-8"?>
   <Package Name="DisplayName" Culture="Culture" xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper">
    <PackageFiles CopyAllPackageFiles="false">
    <PackageFile Name="aspnetmvc1.msi" HomeSite="http://www.asp.net/mVC/download/" PublicKey="3082010A0282010100BD72B489E71C9F85C774B8605C03363D9CFD997A9A294622B0A78753EDEE463AC75B050B57A8B7CA05CCD34C77477085B3E5CBDF67E7A3FD742793679FD78A034430C6F7C9BAC93A1D0856444F17080DF9B41968AA241CFB055785E9C54E072137A7EBCE2C2FB642CD2105A7D6E6D32857C71B7ACE293607CD9E55CCBBF122EBA823A40D29C2FBD0C35A3E633DC72C490B7B7985F088EF71BD435AE3A3B30DF355FB25E0E220D3E79A5E94A5332D287F571B556A0C3244EF666C6FF0389CEF02AD9AA1DD9807100E3C1869E2794E4614E0B98CD0756D9CAC009C2D42F551B85AF4784583E92E7C2BBB5DCD196128AD94430AC56A42FFB532AEA42922DE16E8D30203010001" />
    </PackageFiles>
    <Commands Reboot="Defer">
    <Command PackageFile="aspnetmvc1.msi" EstimatedInstallSeconds="30">
    <ExitCodes>
    <ExitCode Value="0" Result="Success" />
    <DefaultExitCode Result="Fail" String="Anunexpectedexitcodewasr" FormatMessageFromSystem="true" />
    </ExitCodes>
    </Command>
    </Commands>
    <Strings>
    <String Name="Culture">en</String>
    <String Name="DisplayName">ASP.NET MVC 1.0</String>
    <String Name="Anunexpectedexitcodewasr">An unexpected exit code was returned from the installer. The installation failed.</String>
    </Strings>
   </Package>
   						

   This article showing how to include the .NET Framework 3.5 SP1 as a prerequisite is a good reference for the process.

I hope these tips will be helpful for you in extending the usefulness of Setup and Deployment Projects and the breadth of available prerequisite packages.

Seven iPhone Development Rules of Thumb

I've been an Apple developer since it was called NeXT and found the following rules of thumb helpful when introducing new people to Apple development.

1. Read the introductory documentation.  Build a simple application.  Read the documentation again.

The Apple development environment is very different from other application development environments. There is going to be some ramp up time. This isn't like learning .NET after you learned Java.

Expect to throw away your first couple of applications.

2. Don't buck the system.

This is a general theme in the Apple world. If you do things the Apple way, life is pretty easy. If you try to do things the MFC/.NET/Java way... it will be very hard.

Apple heavily uses the delegate pattern. Don't fight it. Apple's view of MVC is a little odd. Adapt.

3. If it seems hard, you're probably doing it wrong.

The Apple developer forums are full of people tracking down difficult problems that are solved by simply doing it in a slightly different way. Not all of these are cases of RTFM, sometimes it's just a trick that all the experienced developers know and you just need to ask.

If something seems harder than it should, head for Google or Bing sooner rather than later!

4. Respect "Apple doesn't want you to do this".

Apple makes customization of most things easy and customization of things it doesn't really want you mucking with very hard. This has been the case since Mac OS X was NeXTStep and cell phones were the size of a brick.

Apple has stringent rules on iPhone apps. Apple wants you to do things a certain way, so just go with the program. Or develop for Android/Blackberry/Pre.

5. Understand retain, copy, release and autorelease.

Really, really understand them. You need to know at a visceral level when to retain or copy, when to release and when to autorelease.

If you run into a retain/release imbalance, stop and think about it until you understand where you went wrong. Don't just start inserting retains and releases until the problem goes away. If you really think about these every time it won't be too long before you never create them again.

6. Learn the difference between should, will and did methods.

Create a simple delegate example and log when every method is called. Read the documentation before and after you think you understand how this all works.

7. Don't ignore warnings.

Warnings are often telling you that your code doesn't do what you think it is  doing. Or that things don't work the way you think they do. 

Beyond Pathauto

The Pathauto module is the Drupal supplied solution to automatically create URL aliases based on the title of a node. You can adjust this in the Pathauto configuration following some basic patterns, but sometimes this is not enough.

Drupal has another mechanism with which you can create custom URL’s for each node. One just has to edit the node, find the “URL path settings” fieldset, and add an alias to that node. If you have a website that publishes a lot of content, doing this manually will become tedious, error prone, and even impractical.

We had a requirement on a recent project where there were Drupal nodes that had to be accessible from a URL that was not possible to automatically generate with the Pathauto module. Our custom content type stored data for a media review that was one of several types: a video game review, movie review, book review and so on. For SEO purposes, we needed to generate a URL based on the review type and its title, for example a game would have the URL games/game-title, a movie would have movies/movie-title. The problem with the Pathauto module was that it could only categorize a content type with one type of URL pattern so all reviews could be stored in games/game-title or movies/movie-title, but not both. Using a custom Drupal module allows you the flexibility to create different URL alias patterns based on your own rules and data. Here is how:

Step 1: Configure Pathauto

• Go to the Pathauto configuration page at "/admin/settings/pathauto".
• Click on the "Node Path Settings" field set.
• Find the Label "Pattern for all Page", then set the "pattern" for that content type.
• For now we just need to add the "[title]" pattern in the text box. 

Step 2: Create a Module:

We need to create a module that is the same name as the CCK content type you have existing in your system. In our case we would create a module named Review.module. (Please see Drupal documentation for how to add modules).

Step 3: Override the Hook Nodeapi:

What we will do in the module is hijack this pattern and add what we want to it.
In the review.info module you will need to add a dependency with the AutoPath module to ensure that it is turned on for this to work (Please see Drupal documentation for how to add module dependencies).

Next edit the review.module file and add the following code.

// This allows us to use the functions defined in the
// autopath module.
require_once '../modules/contrib/pathauto/pathauto.module';

//Now all we need to do is to overload the node_api hook

function review_nodeapi (&$node, $op, $a3 = NULL, $a4 = NULL){

  $is_inserting = FALSE;
  if ($node->type == 'review') {
if ($op ==  'insert'){
  $is_inserting = TRUE;
}

// Preparing the array for the URL alias insertion   
$placeholders = pathauto_get_placeholders('node', $node);

// Detect what type it is, and modify the title
// the Pathauto module must be enabled for this to work.
// $node->node_type stores the type of review
//  (‘game’,’music’, ‘movie’)
$node_type = $node->node_type;

// pathauto_cleanstring removes all spaces and special
// characters from the title in preparation of url format.
$cleantitle = pathauto_cleanstring($node->title, FALSE);

// The url that will be created: 
$cleantitle = ‘reviews/’ . $node_type . '/'. $cleantitle;

// Place it in the array in the 15, 16 position
// (this indicates it is a alias for a node)
$placeholders['values'][15] = $cleantitle;
$placeholders['values'][16] = $cleantitle;
if ($is_inserting) {
  pathauto_create_alias('node', 'insert', $placeholders,
"node/" .$node->nid,  $node->nid, $node->type);
} else  {
  pathauto_create_alias('node', 'update', $placeholders,
"node/" .$node->nid,  $node->nid, $node->type);
}
  } // end if node->type = ‘review’
} // end node_api hook

Now any time you add a review it will have a url alias that consists of www.yoursite.com/reviews/[review-type]/[title-of-review]’

Drupal: Easing Content Type Proliferation

In this blog post we will show you how to allow content editors to edit similar but different "pages" in Drupal, all based on a shared content type without confusion, by hiding the unnecessary form elements.

There can be times when you wish to create several similar content types that only differ slightly from one another (perhaps by a field or two). Let’s take a website that posts environmental warnings on different types of pollution as an example. The site could report air pollution, water pollution and ground pollution warnings. One option is to create 3 separate content types, one for each type of pollution. Air pollution may have an air quality index field, while ground pollution may have a field that shows how it affects the property value of nearby buildings. The point here is that most of the fields for all 3 content types are the same. Discovery Date, Detail Review, Severity, and so on. An alternative implementation is to use one content type called Pollution and a field in that content type named ‘Pollution_type’. This field in the content type would allow us the flexibility to know what type of pollution we are dealing with.

The problem comes when an environmental investigator wishes to add a new air pollution warning. They will see a Drupal form with a ground pollution area field, land value field and all the other fields which are not related to the air pollution type. This can make the user interface crowded with unrelated fields, and unusable. So how can we have one content type and one form which adapts to the type of pollution a user has selected? 

Simple.

By overriding the node_form.tpl file in the themes directory for the ‘pollution’ node type, we can take full control of the appearance of our form. We can then add some JavaScript, or better yet JQuery, which will hide and show elements based on which review type the user has chosen.

Step 1: Set Up CCK Fields

To set this example up we need a simple CCK content type with the following fields (please see Drupal documentation about how to create CCK fields):

Review_ type : drop down with default fields: ( 1 – air, 2 – ground, 3 – water)
hazard_time (text box)
area_affected (text box)
warning_date (date)
warning_details (text area)

etc ...

Step 2: Override the Node Form for the Review Content Type

To do so you need to create a function in the template.php file (which will be found in your themes directory). The name of the function will need to take on the following form:

phptemplate_[content_type]_node_form() and in our case the function will look like the following:

function phptemplate_pollution_node_form($form) {
    drupal_add_js('sites/all/modules/js/pollution.js');  

    // Add JQuery to act on the form
    // load the review_node_form.tpl.php file to render this 
    //form.   
    return _phptemplate_callback('pollution_node_form',
    array('form' => $form));  
}

The reason why this works is because when Drupal processes the form for a particular node that has been queued up to render, it will search through the template.php file for a function in the form of phtemplate_[content_type]_node_form: If it finds one it will then load and render the form returned by this function.

Step 3: Render a Custom Form

In the themes directory you need to create the form theme function that is returned by the function in the template.php function. In our example this would be pollution_node_form.tpl.php

Now in the pollution_node_form.tpl.php file we create the HTML and attributes we need to render the form. This includes any tags and classes that will help us when we use JQuery to hide and show the form.

<?php>

<legend> Type And Title </legend>
<?php echo drupal_render($form['field_pollution_type']); ?>
    <?php echo drupal_render($form['title']); ?>
<div id=’warning’>
    <?php echo drupal_render($form['field_warning]); ?>
</div>
<div id= 'land_pollute_field’>
    <?php echo drupal_render($form['field_land_area_affected
]); ?>
</div>
<div id= ‘air_pollute_field’>
    <?php echo drupal_render($form['field_direction_of_
movement]); ?>
</div>
// render other field from the CCK content type ..
<?php>
    // Unset form elements that you don’t want rendered
        unset($form['attachments']);
        unset($form['menu']);
    …
     // Render the rest of the form …
        echo drupal_render($form);
?>

Now to get the JQuery to connect with the HTML id’s of each separate div we add the following JQuery file to the JavaScipt file referred to in Step 2. In our example the file should be named warning.js and be in the /themes/yourtheme/js directory.

$(document).ready( function() {
    // Need to initialize on page load which fields are shown on the page.
    $("#land_pollute_field").css("display","block");
    $("#water_pollute_field").css("display","none");
    $("#air_pollute_field").css("display","none");

    var choice = $("#edit-field-pollution-type").val();  
// You will need to find the ‘id’ of the dropdown list 
    switch(choice) {
        case “land":
            $("#land_pollute_field").css("display","block");
            $("#water_pollute_field").css("display","none");
            $("#air_pollute_field").css("display","none");

        break;
        case "air": 
            
            $("#water_pollute_field").css("display","none");
            $("#land_pollute_field").css("display","none");
            $("#air_pollute_field").css("display","block");

        break;
        case "water":
            $("#land_pollute_field").css("display","none");
            $("#water_pollute_field").css("display","block");
            $("#air_pollute_field").css("display","none");
        break;
});

From here its easy to expand the form and manipulate the layout as needed.

Canada 3.0 - Defining Canada's Digital Future

A few months ago at Communitech's Techworking breakfast, I had the opportunity to see Tom Jenkins, Executive Chairman, and CSO of Open Text share a little about Open Text's Enterprise Content Management Solutions, and how they are working with clients to manage their digital assets. 

Jenkins also discussed the Canada 3.0 Forum that will be held in Stratford, Ontario on June 8th & 9th.  My initial reaction was "3.0?  Really?". Many are still trying to figure out 2.0 as others have moved on and begun to argue 3.0... Is 3.0 the semantic web, a mobile web, or digital media? While others argue that technology is moving so quickly right now it is impossible to wrap up in a tidy little box and name it. Regardless of where you stand, Richard McManus' post provides some great insight with additional thoughts on 3.0. 

Independent of which direction 3.0 goes, Canada cannot afford to sit by and wait for its definition. We must find a way to ensure that digital innovation continues, accelerates, and succeeds in our country.  Canada 3.0 is an opportunity to bring the public and private sector together to discuss the future of the web and act now to help shape Canada's digital media strategy.

With speakers from the private sector such as RIM Co-CEO's Mike Lazaridis & Jim Balsillie, Tom Jenkins, Ian Wilson, Konrad W. von Finckenstein of the CRTC, and the Honourable Dalton McGuinty, in additon to stream speakers Austin Hill of Akoha, Anthony Lacavera of Globalive, Mark Relph of Microsoft, Sara Diamond of OCAD, and Alrene Dickinson of Venture Communications and Dragon's Den fame, Canada 3.0 will have a strong cross-representation from government, industry, and education all together.

Codesta is proud to sponsor Canada 3.0 to help foster this discussion and help act on its ideas for the future of the web.

SEO: A Lesson in Website Updates

Codesta recently updated its website and we wanted to share some of our experiences from the process. One of the major reasons we endeavoured to update our website was to increase the breadth of our Search Engine Optimization (SEO) reach. Too often SEO is an after-thought of many projects, and this can prove costly over the short and long term. We've spoken with companies who have undertaken huge and costly website upgrades only to experience significant declines in their online traffic. What's worse, the new site is not "bad" or unfriendly, usually it's quite the opposite. They have done extensive user testing, tweaked their interface to make it that little bit better and wham. Traffic drops. Why? Most often we find it's because they had no previous understanding of their website reach. Their audience is linking to articles deep within their site, and their site visitors are from all over the place. This deep linking drives important search results relevance with Google, the major source of traffic for most websites. If a company upgrades or wholesale changes its site without understanding the impact, it's no small amount of work to fix the damage. To elaborate, I'll use our website and what we did to ensure this didn't happen to us, as an example.

Before upgrading we endeavoured to make sure we didn't "hurt" ourselves as part of the process. A major component of this was understanding how Google currently indexes our site and drives traffic to www.codesta.com. As mentioned in other articles, Codesta is an Agile driven organization, so we included a spike in our first website upgrade sprint, to understand our relationship with Google. What we found surprised us. Our oldest articles on our original website from 2002 still had valid links to it from remote destinations on the Internet. Though a little dusty, these links were still important as linking drives relevancy, and that drives search results traffic. Our first lesson... keep the old articles around.

The second learning through the spike was that Google continues to offer great tools for webmasters to understand their place in the Google Index. A quick visit to Google Webmaster Tools showed us the last time Google had visited our site, all the errors their web crawlers were finding, our index statistics, webpages with the highest Page Rank and much more. It was a full day of leveraging their Diagnostic tools and site linking reports for us to understand what we needed to do. Through everything we found on their site we were able to develop a clear plan to smoothly transition to our new website instance.

Our third learning was the value of a sitemap. Most websites maintain a sitemap somewhere on their site, but the days of end users navigating directly to it are long since over (am I dating myself?). Though sitemaps still have their place in helping with page ranking and end user navigation, they pale in comparison to the value offered by a sitemap.xml file submitted to Google. Google's Googlebot is a much happier camper when provided with an xml file it can digest. Further, the xml sitemap provides a webmaster with the opportunity to explicitly tell Google what pages are a priority to the site operators. Without these values Google assigns each page the same priority which could inadvertently direct traffic to less important areas of your site. We also found that the presence of the sitemap.xml consistently accelerated the Google verification and crawling process. If a sitemap.xml existed we always found we were visited the same day and able to make changes very quickly.

Our last key learning was from our analysis of our Google Analytics (GA) Reporting. We have been GA users for the last 2+ years and have been very happy with the information we've gathered. We've been happy to learn that our blog has been productively generating traffic since we launched it 2 years ago. We also knew that we wanted to lower our Bounce Rate to provide visitors with a better experience. One nifty new tool we were happy to play with was the Google Website Optimizer. It was a critical tool that helped us understand how people were navigating our site. It enables you to develop scenarios, called Experiments, where you can test where you place content and how users respond to it. We found one key learning from this process. We had WAY too much content on our old homepage. Visitors weren't staying to read everything we shared. The new site is borderline sparse, but we like it that way. We were pleasantly surprised to see users frequently navigating to our Contact Us page, a positive reinforcement of our call to action.

Once our Google-centric tinkering was done, we wanted to perform one last validation step. We wanted to make sure that we weren't just Google friendly, but had implemented a web friendly site for all users. There are great resources and examples on the Internet of sites that have spent considerable time and energy making sure their site works for all users. Mobile devices, the visually impaired, or individual preferences on font sizes require consideration and we wanted to make sure we were doing our best. A personal favourite of mine for benchmarking our deployment is the Canadian National Institute for the Blind (cnib.ca). A quick look at their page header reveals they've considered many aspects of their user base. From contrast levels to screen readers they need to carefully consider their users. Codesta's long term goal is to provide the same level of access to our site, and our latest site release is a first step in that direction. To meet this goal we leveraged some well known SEO testing tools to ensure we'd done our job. Some of the tools we used (and liked) include:

1. Electrum's SortSite SEO Testing Tool - SortSite does an excellent job providing a robust evaluation tool which makes you want to upgrade to their full version after just one use! Their tools provide information on coding errors, accessibility issues and compatibility with major search engines. The level of detail they provide is excellent and the interface makes clicking through to detailed data very easy.
2. Aaron Wall's SEOBook and SEO Toolbar for Firefox - Built right into your browser, the SEO Toolbar does a great job of providing data while you review a site.
3. W3C Markup Validation Service - Not to be outdone, the W3C has provided many free tools you can use to test your site. 
4. SEOmoz - Lots of useful info, and plenty of data and tools to digest.
5. Yahoo UI Library - Last, but definitely not least, Yahoo maintains a large UI library for developers to maintain. It's a great resource for all UI developers out there, and contains many practical tools to help develop a great, SEO friendly website.

Launch! Finally...

Away we go... We're relieved and happy with the results of our learning exercise. Much of what I've shared is very well known, documented and free on the Internet. Despite that fact, we felt we really needed to share because there are still so many people doing it wrong. We understand no one is perfect, and we really hope this article helps. With that, one last piece of advice...

Continue using the SEO tools we've described and the Google Webmaster resources to check-in on your site after launch. This is particularly true for Google immediately after launch, and roughly a week or so afterwards. In that timeframe Google will have visited your site, indexed results and started sharing that information with the world. You can consume all of this reporting via the Google Webmaster tools, and help them do a better job of promoting your website. This is your window of opportunity to "limit the damage" and catch errors before they're widely distributed across the Internet. Don't delay, and you'll save yourself one more headache.

Drupal 5 vs Drupal 6 - Head to Head Comparison

    Drupal 6 has been in the wild for about a year now, and Drupal 7 is on the way. This article will take a look at Drupal 6 from the point of view of a Drupal 5 user, especially with regards to whether it makes sense to update your Drupal 5 site to Drupal 6.

    First, we can take a look at the new features that have been included in the Drupal 6 release. One of the major features is a new installer to aid the technically challenged in setting up their Drupal website, which could be a difficult task with Drupal 5. The installer can now check for “Clean Url” support (which the vast majority of website administers will want to take advantage of), and enable this feature if the support is available. The installer also sets the “Files” directory during installation, and multi-language support is available from the outset.

    Another improvement is the drag-and-drop administration that has taken the place of the unwieldy weighting system that was used throughout Drupal 5. This interface is available for menu items, forums, taxonomy terms, uploaded files, input formats, profile fields and more.

    Other improvements include an updated theming system to improve the ease of custom theming, password strength checking, granular permissions and other small changes.

    Drupal 6 also boasts several new core modules, including OpenID, Update Status and Actions plus Triggers. All of these, however, are contributed modules that were available for Drupal 5, so this is not a major improvement.

    One of the features touted in the release notes for Drupal 6 is optimized code that “improves performance for both authenticated and anonymous users”. However, several benchmark tests have concluded that Drupal 5 is consistently faster that Drupal 6, using core modules only. This may be a strong consideration for those considering upgrading to Drupal 6, especially since Drupal 5 is not the most efficient beast itself.

2bits.com Drupal 5 vs. 6 Comparison
Vision Media Benchmark Testing
2bits.com Drupal Getting Slower Article

Upgrade Considerations

    Now that we have taken a look at the new features of Drupal 6, let’s look at whether it makes sense to update your Drupal 5.x website to Drupal 6. This choice will depend entirely upon what sort of website you are running with Drupal 5. If you have a simple website with a small number of contributed modules, then upgrading may be an easy task. If you have a more complex website with a larger number of contributed modules and customizations then upgrading starts to become more daunting.

    Not only will you have to update Drupal core, you will also need to update each of the contributed modules that you are using. This task is made more difficult by the fact that there may not be a Drupal 6 compatible version of each of your web site's modules. Even if the module has a 6.x compatible version, that version may not be as stable as the 5.x version. This necessitates the extra step of checking the issue queue on Drupal.org for the 6.x version of each module to ensure that people aren’t having problems with the module on the 6.x branch.

    Given that updating your Drupal 5 site may prove to be difficult, does the new feature set necessitate an upgrade? From the point of view of a Drupal 5 user (myself), there are no “must-have” features in the Drupal 6 release that would balance out the difficulty of an upgrade. The drag-and-drop interface is the one feature that sticks out as an important, probably due to the fact that the old weighting system was so cumbersome.

Conclusions

    Drupal 6 is an incremental improvement over Drupal 5. Although the new feature set is fairly large, the difficulty of upgrading your Drupal 5 site overwhelms any small improvements that you may get by performing the update. In addition, if you have a Drupal 5 site with a custom theme you may want to take a very close look at the theming changes before even considering an upgrade.

    If you don’t currently have a Drupal 5 website, then you will want to start with Drupal 6, as it does seem to be an improvement over the previous version. The only reason not to use Drupal 6 for a brand new website would be if a module you need exists for Drupal 5 only, and has not been ported to 6. This issue may well occur – there are 75 pages of contributed modules for Drupal 5, and only 46 for Drupal 6.