Otaqui.Com

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

If you are developing a CakePHP application and you have the debug value set to anything greater than 0 in your config/core.php file, you will find that Ajax requests will also get the extra information appended to the output.

In order to circumvent this add this to your “app_controller.php” file (which sits directly inside the “app/” dir, rather than in “app/controllers”):

<?php
class AppController extends Controller {
  var $components = array('RequestHandler');
  var $helpers = array('Html','Form','Ajax');
  function beforeFilter() {
    if ( $this->RequestHandler->isAjax() ) {
      Configure::write('debug',0);
    }
  }
}
?>

Note that while this will disable the debugging output, it will also have other affects too (for the life of the Ajax Request) like extending the length of time that the “schema” is cached. This should make little or no difference, but is worth remembering.