One of the best resources I’ve found so far are the defaults files in the Rails source code.

https://github.com/rails/rails/blob/master/activemodel/lib/active_model/locale/en.yml
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/locale/en.yml

That gives you a full list of the attribute names to use for different validators.  For example, if you’re using a validates_format_of validator, you can quickly see that you need to use the invalid YAML attribute.  Good luck guessing that one!

The looking at the source trick can also be very useful for gems.  I’ve spent ages Googling for the correct YAML attribute to use for the validates_email_format_of gem with absolutely no luck whatsoever.  30 seconds on Github and I find the source file which tells me the attribute for an invalid email address is invalid_email_address

Before

The Magical Pretty Print Button

After

1. Open your gemfile and replace gem ‘rails’, ’3.0.0′ with  gem ‘rails’, ’3.1.3′.  3.1.3 being the latest build at the time of writing.
2. If you want to use the new asset pipeline hotness in 3.1 (and why wouldn’t you?) you need to add a new section at the bottom of the file:

   group :assets do
     gem 'sass-rails', "  ~> 3.1.0"
     gem 'coffee-rails', "~> 3.1.0"
     gem 'uglifier'
   end

3. Now open up your command line and run a bundle install. You may need to delete gemfile.lock.
4. The next step is to run rake rails:update.  The first time I did this I got the error “uninitialized constant ActionView::Helpers::JavaScriptProxy”.  To resolve this I removed jrails from my gemfile as Rails 3.1 uses jQuery anyway.  I then re-ran the rake command.
5. The Rails update will generate a bunch of conflicts.  I did the following (make sure you use the diff option to check for yourself!):
   • boot.rb – overwrite.
   • routes.rb – do not overwrite.
   • application.rb – do not overwrite. We’ll patch this up manually next.
   • development.rb – do not overwrite. You might be able to get away with overwriting this, but I have settings I need in here.
   • production.rb – do no overwrite. Again, I have settings I need in here.
   • test.rb – overwrite. I didn’t have any special settings here, but use the diff to check yours!
   • secret_token.rb – overwrite.
   • session_store.rb – overwrite.
   • en.yml – do not overwrite.
6. Now we need to make a few changes that would have been made if we let Rails overwrite our files. Open up config/application.rb and add the following:

   # Enable the asset pipeline
   config.assets.enabled = true
   
   # Version of your assets, change this if you want to expire all your assets
   config.assets.version = '1.0'

7. Open up config/environments/development.rb, remove “config.action_view.debug_rjs = true”and add the following:

   # Do not compress assets
   config.assets.compress = false
   
   # Expands the lines which load the assets
   config.assets.debug = true

8. Open up config/environments/production.rb and add:

   # Compress JavaScripts and CSS
   config.assets.compress = true
   
   # Don't fallback to assets pipeline if a precompiled asset is missed
   config.assets.compile = false
   
   # Generate digests for assets URLs
   config.assets.digest = true

9. Create a new assets folder in app and then add images, javascripts and stylesheets and sub-directories.  Move your CSS, JS and image files into these directories.
10. You’ll have to do some work to cleanup your assets and how they are included in your layouts – but that’s very much an exercise for the reader :)

The enhancements to CSS that are found in SASS and LESS are simply brilliant and save a massive amount of time.  Variables, nested selectors and mixins are just a few of my personal favourites.  CoffeeScript puts a wonderfully expressive veneer on top of JavaScript, removing lots of the grunt work and making your code much cleaner.

Using these improvements to the everyday languages has become second-nature and I’d be reluctant to go back.  Think about how much of a difference jQuery made to JavaScript DOM manipulation and animaton – you just wouldn’t want to go back to how it used to be!

However, my time is split between the Ruby on Rails world and the ASP.NET MVC world.  .NET doesn’t have native support for these new languages yet.  What’s a dev to do?

Thankfully, the lovely people of Mindscape have released a free Visual Studio plugin to take our pain away! The plugin handles CoffeeScript, LESS and SASS files, compiling them to native code every time you save your file.

It also adds new project items types to the ‘Add Item’ dialog and provides syntax highlighting within .coffee, .less and .sass files.

Simple and brilliant.  You can still link to your CSS and JavaScript files as you always have in HTML, or, as I do, use a NuGet package like Combres to combine and minify your files to reduce page load time.

You can grab the code for this demo from GitHub.

There’s not a lot to say that the demo doesn’t show, it’s all terribly easy to set up.  A minimal example requires a droppable area, e.g. a <div> tag to be on the page with the following JavaScript.

$("#dropbox").html5Uploader({
    name: "myfile",
    postUrl: "/Home/Upload"
}

The options specify the name of the form field when it’s POSTed and the URL of the script to POST to. From there you can extend the funkyness by listening for the wide range of events that get bubbled up.  These let you show previews of the files you’re uploading, show progress bars, let people know when the upload is complete or provide helpful errors when things go wrong.

All in all, it’s super sexy and really easy to get started with!

We used the following mod_rewrite rule:

RewriteEngine on
RewriteCond %{REQUEST_URI}!^/test/
RewriteCond %{REQUEST_URI}!^/my-folder/
RewriteRule (.*) http://www.newdomain.com/$1 [R=301,L]

This redirects (permanently with a 301 redirect) all traffic to the site to http://www.newdomain.com, except requests to resources in the /test and /my-folder directories.  We transfer the user to the exact resource they requested by using the (.*) capture group and then including $1 in the new URL.

All you have to do is create a file called app_offline.htm in the root of the website.  Bam!  Your site is down for maintenance.  This provides a super convenient way to take your website offline while you make changes to it.  You can put arbitrary HTML in the file, so your offline page can be as pretty (or otherwise) as you like – with a caveat discussed later.

When ASP.NET sees the app_offline.htm, it will shut down the AppDomain for the application and instead return the  app_offline.htm file in response to all new HTTP requests.  When you’ve finished deploying your new version, fixing the problem or replacing the hardware, just delete the file and the site will come back online.

Images, CSS and JavaScript

When you have an app_offline.htm file it will be returned for EVERY request.  That includes static assets like images, CSS files and JavaScript files.  So, if you want you offline page to be pretty, CSS and JavaScript will have to be inlined.  Images are a bit more tricky but are possible.  You’ll have to Base-64 encode the image and include it using a data URI.

Avoiding friendly HTTP errors

Some browsers like to be helpful to their users and display their own custom error pages for HTTP errors like 404 and 500.  These errors are triggered when the page returned by the server is very short, typically less than 512 bytes.  If you just put the words ‘Application Offline’ in your app_offline.htm file then the browser will override it and the user will just think your site is broken.  So, always make sure you page is at least 512 bytes by adding filler tags or hidden text.

And finally…

You could automate the addition and removal of the file as part of your automated deployment script.  You do have an automated deployment script, right?  No?  Remember: automate all of the things!

2011 has been a year of many new things and we’ve seen our fair share of error messages.  Some of which were just a little bit more…. special…than others.  We’d like to share these with you, so that when you’re writing your next library, toolkit, plugin or whatever, you take time to think about the error messages the mere mortals using your code will see!

“You don’t exist.  Go away.”

Paul received this error from SSH whilst trying to push a Git commit.  It turned out that a sector of his hard drive had gone rogue and completely borked his terminal session and the rest of OS X’s authentication.  A restart fixed the problem – but only after a lot of head scratching and complete bewilderment!

“m.”

This error was displayed by TortoiseGit after an error occurred pushing to a Git repo.  I can only assume that a bug in the software truncated the error message.  I have absolutely no idea what the error actually was.

“The server is unwilling to process your request”

“WELL TRY HARDER!!” could often be heard coming from my desk as Active Directory returned one of the worst error messages ever written.  The beauty of this error is that is returned for, as far as I can tell, hundreds of different reasons.  From validation errors, to typos in queries, to non-existent attribute names.  I mean really, could somebody at Microsoft not have put just a tiny bit more effort in and returned something slightly more meaningful?

“Unknown COM error”

My favourite and most often seen error in 2011 as I battled my way through Active Directory.  This takes the prize for least helpful error message of the year.  As with the server being a lazy shit, this error can be returned for hundreds of different reasons.  However, unlike the previous error, this message is paired with a hex code, for example 0×8000500, which when Googled often yielded useful information about the cause of the error – so not exactly ‘Unknown’ then!!!  Could they have not have included that information in the error?!

Did you encounter any cretinous errors in 2011?  We’d love to hear about them!

ELMAH makes sending email alerts really quite simple.  Open up your web.config file and add an errorMail section definition and corresponding errorMail entry as follows:

<configSections>
	<sectionGroup name="elmah">
		<section name="errorLog"
                               requirePermission="false"
                               type="Elmah.ErrorLogSectionHandler, Elmah"/>
		<section name="errorMail"
                                requirePermission="false"
                                type="Elmah.ErrorMailSectionHandler, Elmah"/>
	</sectionGroup>
</configSections>

<elmah>
	<errorLog type="Elmah.SQLiteErrorLog, Elmah" connectionStringName="..."/>
	<errorMail from="error@mysite.co.uk" to="bug-report@developer.com"/>
</elmah>

You’ll also need to add a reference to the Elmah.ErrorMailModule in your httpModules section.

<system.web>
	<httpModules>
		<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
		<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
	</httpModules>
</system.web>

You will then need to configure an SMTP server for error@mysite.co.uk in your web.config.  You can do this in two ways: inline on the errorMail definition, or in a system.net mailSettings section. Examples of both are shown below. Personally, I prefer to use a mailSettings section as I use the SMTP details elsewhere in my applications.

<system.net>
    <mailSettings>
		<smtp deliveryMethod="network">
			<network host="..." port="25" userName="..." password="..." />
		</smtp>
    </mailSettings>
</system.net>

or

<errorMail from="..." to="..."  async="true" smtpServer="..." smtpPort="25" userName="..." password="..." />

If you want to send your error emails using GMail’s SMTP server you will have to change a couple of bits in your configuration. GMail requires SSL to be enabled. We cannot specify this through the system.net section so we need to add the useSsl parameter to the errorMail tag. We also need to specify port 587. If you don’t specify a port on your errorMail tag, ELMAH will use port 25 by defualt. To tell it to use the port we have defined in the system.net section, set smtpPort="0". [Thanks to Scott Mitchell for this tip]

<elmah>
	<errorMail from="..." to="..." async="true" smtpPort="0" useSsl="true" />
</elmah>

<system.net>
	<mailSettings>
		<smtp deliveryMethod="network">
			<network host="smtp.gmail.com"
				 port="587"
				 userName="..."
				 password="..." />
		</stmp>
	</mailSettings>
</system.net>

That’s all you need.  I suggest creating a page with a deliberate error on to check that everything is set up correctly.

What Next?  Well, if you have a team of developers working on a site then you probably have bug tracking software keeping track of problems that need working on.  Most popular bug tracking packages allow you to post issues by email – why not pipe your error report emails straight into your bug tracker, after all problems that are happening now should be top of your todo list (See Jeff Atwood’s Exception-Driven Development).

Caution: If you experience email issues (maybe a password changes, or an SMTP relay is misconfigured) then you will not receive emails alerting you to the problem (or any other problems).  This is a catch-22 that has caught me out a few times.   If this becomes a problem for you, ELMAH also provides an RSS feed of errors which you could subscribe to, it can also Tweet your errors to you!

By default, ELMAH is configured to deny access to the error log it produces unless you are accessing it from the server the site is hosted on. To safely access our logs remotely we need to do two things. First, we need to enable remote access. Second, we need to add authentication so that random users and people of ill-intent cannot access our error reports and see sensitive details of the inner workings of our application.

Enabling Remote Access to ELMAH

To enable remote access we need to add the security section to ELMAH and set allowRemoteAccess="yes".

<configSections>
	<sectionGroup name="elmah">
		<section name="errorLog"
				 requirePermission="false"
				 type="Elmah.ErrorLogSectionHandler, Elmah"/>
		<section name="security"
				 requirePermission="false"
				 type="Elmah.SecuritySectionHandler, Elmah"/>
	</sectionGroup>
</configSections>

<elmah>
	<errorLog type="Elmah.SQLiteErrorLog, Elmah" connectionStringName="..." />
	<security allowRemoteAccess="yes" />
</elmah>

With those definitions added anybody can navigate to /elmah.axd and browse through the exceptions that have been logged.  This is clearly a Bad Thing™ as our error logs contain details of how our application works and may even expose usernames and passwords.  So, we need to prevent unauthorized access.

Add Authentication to ELMAH Error Logs

Using ASP.NET’s Membership Provider and in-built authorization system we can deny anonymous access by adding the following definition to our web.config file. It can go anywhere inside the root configuration element.

<location path="elmah.axd">
	<system.web>
		<authorization>
			<deny users="?" />
		</authorization>
	</system.web>
</location>

This will allow any authenticated user to view the error log. If you only want a select group of people to be able to view the log, you could put those users into a ‘Developers’ role and use something like:

<authorization>
	<allow roles="Developers" />
	<deny users="*" />
</authorization>

If you are unfamiliar with ASP.NET’s authentication and authorization features, you might find this Microsoft KB article helpful.

That’s all there is to it.  By now you should’ve set up automated error logging, secure access to the reports and configured email alerts which pipe straight into your bug tracking software and it’s probably taken less than an hour – how awesome is that!