Otaqui.Com

It’s pretty straightforward to set a custom user agent with mechanize if you’re using it directly, KickAssLabs has a good example.

If you’re using Mechanize through Webrat though, things are a little different. The nice thing though, is that you can do this in a step definition – allowing features to be based on different browser scenarios (this is great if you’re developing across devices).

First off there are two accessors of interest in mechanize, “user_agent” and “user_agent_alias”. The former is fairly self evident and lets you define the user agent at will, the latter gives you shortcut access to a list of common user agents baked into mechanize. You can see that list in the mechanize.rb source. It contains some desktop browsers, the iPhone and the default Mechanize UA strings.

If you’re happy with the default alias list, you can just write a step definition like this:

Given /^I am using the "(.*)" browser$/ do |browser|
  webrat.adapter.mechanize.user_agent_alias = browser
end

And then you can use this in your features:

Given I am using the "iPhone" browser
When I visit the home page
Then I should see "You are using an iPhone!"

If you want to be able to specify your own UA strings, and as I said this is especially likely if you are developing cross-device applications where capabilities are important, then you can just use your own hash instead, and set “user_agent” rather than “user_agent_alias”:

Given /^I am using the "(.*)" browser$/ do |browser|
  UA_ALIASES = {
    "Nokia N95" => "Mozilla/5.0 (SymbianOS/9.2; .....",
    "Palm Pre" => "Mozilla/5.0 (webOS/1.0; ....."
  }
  webrat.adapter.mechanize.user_agent = UA_ALIASES[browser]
end

With a little tweaking you could use both the included list and, if the string from your feature isn’t there, look in a custom list too.

Google Chrome has quite a lot of special URLs. Some of these are covered over at Lifehacker in their post on Chrome’s about pages, but the meta “about:” protocol isn’t the only one that Chrome uses.

Waha, a user on the chromeplugins.org site posted a much more complete list of URL schemes that Chrome uses. Waha was looking at the url_constants.cc source file, along with some other stuff, to work this list out.

I’ve ignored the virtually universal set of protocols that are in just about every browser: http, https, ftp, file, data, feed and javascript, and also the URLs that cannot be entered into the address bar (not using Chrome 5 on OS X Snow Leopard anyway).

Without further ado, here’s the list:

• about:blank – the empty page
• about:cache – disk and memory cache information
• about:net-internals – network information including Proxy, HostResolver, URLRequest, HTTPCache and SocketStream
• about:crash – the page shown when a tab process crashes
• about:credits – list of libraries and other code used in Chrome, with links
• about:hang – this seems to kill a tab for me (I haven’t linked for that reason – use at your own risk)
• about:memory – memory usage of the various processes
• about:shorthang – see about:hang above
• about:terms – Google Chrome Terms of Service
• about:inducebrowsercrashforrealz – not many lolz here
• chrome://extensions/ – installed extensions
• chrome://history/ – your browsing history
• chrome://newtab – the new tab page
• chrome://thumb/http://www.google.com/ – thumbnail for a page you’ve visited
• chrome://favicon/http://www.google.com/ – favicon for a page you’ve visited
• view-source:http://otaqui.com/blog/539/complete-list-of-special-google-chrome-urls – view the source of a web page

Thanks to some brilliant tidying up of my work by my good friend Patrick, there is now a bbc_standards ruby gem which you can use to validate pages against some of the BBC Technical Guidelines (more specifically the “Semantic Mark-up” and “XHTML Integrity” standards).

This gem was originally designed to work with Cucumber, and initially was intended to just validate pages against the XHTML Strict doctype that BBC pages are usually required to use. Since it uses Nokogiri for validation – against the XML Schema rather than the Doctype for what it’s worth – the testing is a) strict and b) *fast*. There are no external webservice calls, so it is fine to test all page loads within Cucumber, even testing the same URI many times over (since the bottleneck will almost certainly be your app by some margin.

I’m currently working on a post about using the gem for the BBC Web Developer blog, but I thought I’d point any interested parties at the code here and now.

CakePHP doesn’t just come with its own console applications for baking code, managing ACL, inspecting classes, manipulating the schema, internationalisation and running the testsuite (whew!) it also lets you write your own console applications.

[NB: I always have an external cake core directory, for easy swapping. The code examples all assume you have done this, or at least created an alias in your terminal to point to the core cake directory with something like: alias cake='../cake/console/cake'

First off, to find out about the current console applications you are running jump into a terminal and cd to your app directory, then simple run the “cake” command to see what you have available:

app_dir $ cake

This will output a list of available shells in the core cake library and the two “vendors” directories.

So how do you go about creating your own? The CakePHP documentation on creating Shells & Tasks is a good place to start.

An application I’ve needed to automate with a cron-job, and also have available as an in-app, on-demand function is the sending of emails. I’m not talking about writing a mass mailer here, but rather just sending out course information to users who are booked to attend – and doing so both automatically and on-demand when an administrator decides it is necessary. This is an obvious instance where you don’t want to duplicate the code in the controller and the shell.

In my case, I have several kinds of email I want to send, so I set up a generalised Task, used by several different Shells. The advantage of doing things this way around is that any other Shells can also make use of the emailer Task in the fututre.

Here’s some simplified code from one of the Shells, a “booking reminder” for delegates:

// file app/vendors/shells/booking_reminder.php
<?php
class BookingReminderShell extends Shell {
  var $uses = array("Booking","User","Course");
  var $tasks = array("Emailer");
  public function main() {
    // use $this->Booking etc as if we were in a controller
    // use $this->Emailer for the task
  }
}

And then we have the Task:

// file app/vendors/shells/tasks/emailer.php
<?php
class Emailer extends Shell {
  public function execute() {
    // this method is called when the task is instantiated,
    // gives you a chance to setup
  }
  public function send($to,$from,$subject,$message,$attachments=null) {
    // called from shell with: $this->Emailer->send();
  }
}

Note how both Shells and tasks extend from the base “Shell” class. Also note how Shells use a method called “main()” when they are run, whereas Tasks use “execute()” when they are created.

If you’re writing Cucumber tests using Webrat and Mechanize to test a site, and you are behind a proxy server, you can do something like this to tell mechanize about it in your webrat_steps.rb file:


When /^I am on (.+)$/ do |page_name|
webrat.adapter.mechanize.set_proxy('proxy.host.com',8080)
visit path_to(page_name)
end


I’m sure there’s a tidier way to do this, but it’s quick and it works with the following gem versions:

Cucumber 0.3.11
Webrat 0.5.3
Mechanize 0.9.3