Just drag this ZF Manual Index bookmark onto your browser bookmarks bar. Clicking the bookmark will add a contents index to the top of any Zend Framework manual page. Helpful links ahoy!

If you want to view the source code take a peek over here.

$front = $this->getFrontController();
$adminLayout = new My_Controller_Plugin_AdminLayout($this->_helper->layout());
$front->registerPlugin($adminLayout);

If you want to alter the plugin so it runs after any other local plugins you could specify a stack index of 10 as a second argument:

$front->registerPlugin($adminLayout, 10);

However, unless you know what the existing plugin stack indexes are it’s difficult to know what stack index you should be using. You can use this small code snippet to output the plugin name and its associated stack index, again via your controller.

foreach ($front->getPlugins() as $stackIndex => $plugin) {
    Zend_Debug::dump(get_class($plugin), $stackIndex);
}

The standard ZF plugin list should be something like:

99 string(36) "Zend_Layout_Controller_Plugin_Layout"
100 string(35) "Zend_Controller_Plugin_ErrorHandler"
999 string(33) "Zend_Wildfire_Channel_HttpHeaders"

Hope this helps shed light on a rather useful feature of ZF! You can find out more at this excellent Devzone article on Front Controller Plugins in Zend Framework.

Its main features are:

• Organise modules into sub-folders where you need to support a complex collection of controllers, views, models, etc
• Supports URLs in the format: /sub-module/module/controller/action
• Supports ID route: /sub-module/module/controller/action/id
• Registers controller folder to support above URLs
• Autoloads module resources (using Zend_Application_Module_Autoloader) in the format: submodulenameModulename_Resource (i.e. AdminUser_Form_Registration)

This supports URL routes such as:

www.domain.com/admin/user/ ->
application/admin-modules/user/controllers/IndexController.php

www.domain.com/cms/news ->
application/cms-modules/news/controllers/IndexController.php

It’s a bootstrap resource that can be enabled in your application.ini file as so:

; 'admin' key is the name of sub-module group = path to sub-modules directory
resources.subModules.admin.directory = APPLICATION_PATH "/admin-modules"

• Download S24_Application_Resource_Submodules
• View S24_Application_Resource_Submodules source code

The session was excellent, well worth attending, and dipped into many areas of ZF. Some of which I knew already, but there was certainly enough good tips on how to organise applications efficiently in ZF which I’ll be telling my team all about when I get back to the UK.

My notes from the tutorial day appear below, be warned they are rather long! You can also review the Zend Framework Workshop slides over at Slideshare.

Service layers

Think of the application as an onion layer. From the inside out:

• Data Access objects (inner layer)
• Data Mappers, Repositories, Transaction scripts
• Domain Models and Entities (plain old PHP objects)
• Service layer (outer layer: how will I interact with all this, the public API)

It’s better to have a rich domain model, validation in domain model.

• Start with a plain old PHP object
• Define schema based on objects you use
• Create objects first
• Create schema once models have been created and tested

Use mappers or transaction scripts to translate objects to data and back again.

Use Service Object to manipulate entities. Ie.

• fetchEntry()
• fetchComments()
• addComment(), etc

What’s in a Service Layer?

• Application specific logic
• Forms, validation, caching

All the bits and pieces of the app I don’t want to deal with when writing the front-end.

Q: Should we use services for everything?
A: Use for all parts of an app, easy to test

Rob added:

• he uses the form as the service layer
• uses a mapper class based on ZendDbTable
• compose the form in the service layer
• tend to put search indexing on mapper layer (postSave method)

ACL

ACL is roles, resources and rights (resource privileges). By default ACL operates as a whitelist (i.e. open up privileges to those you trust). Blacklisting is less secure, not recommended.

One approach is to extend Zend_Acl and set up roles and resources in constructor. Roles are simply text strings. Resources are much the same but have an array of privileges that can also be passed (i.e. read, write).

Suggested logic:

• Check ACL
• Check the role acting on a resource has a right to perform the action
• isAllowed() – checks role, resource, privilege

Matthew added:

• I like to throw a specific exception for failed ACLs so I can detect it
• I can then check for another exception case in the ErrorController to display a Not Authorised page (nice approach)

Paginators

• Return paginators from your domain models
• Consumers can specify offset and limit
• Zend_Paginator implements IteratorAggregate and toJson()
• Paginators have efficient, lazy loading

I.e. fetchAll() in domain model returns paginator

Zend_Application

• For common configuration & per-environment configuration
• Resource injection so you can use bootstrap as resource repository
• Resources: in bootstrap class or as a re-usable plugin resource
• Reusing for a service endpoint (i.e. set environment = jsonrpc)
• Dependency tracking
• Accessing resources via controller
• Module bootstrapping. Not particularly good at present. Runs all module bootstraps if exists. Order of running module/main app boostraps ambigious. Don’t mix resource names/application.ini key names in main app + module. Kathryn Reeve wrote a nice module bootstrapping solution.

Routing clinic

As an aside throughout the day Matthew and Rob have been using the syntax use Zend_Long_Class_Name as ShortName – nice way to alias class names in PHP 5.3

• Basics: Name the route, specify the path, specify default values and optional validation
• RegexRoute can support: 'blog/(?<id>[^.]*\+)\.(?<format>xml|json)'
• That regex route stores first param as ‘id’, 2nd as ‘format’ (that’s the handy ?<name> format)
• Regex routes are very fast, even more so in PHP 5.3
• Touched on hostname routing which you then need to chain with a normal route
• RESTful routes Zend via Zend_Rest_Route
• Can specify as default route, or add it for all controllers in a module
• Or set REST routes for specific module / controller / actions
• Controller then needs to extend ZendRestController (listAction, postAction, etc)
• ID is accessed via getParam(’id’)

Layout View Helpers

• You should always run output via the $this->escape() view helper! In ZF2 it will be default when you echo content
• Layout helpers: Set metadata, aggregate content, rendered in layout
• If you have CSS/JS related to a particular layout put it in your view script. Really important for maintenance.
• doctype() affects rendering of other view helpers, i.e. forms. Ideally needs to be set in bootstrap: resources.view.doctype = XHTML1_STRICT
• Head view helpers – can append and prepend content.
  • headMeta(), headTitle(), headScript(), headStyle(), headLink()
  • inlineStyle() – usually at top of body
  • inlineScript() – usually at bottom of body
• Use a layout helper if your functionality is shared across multiple view scripts to set all this common stuff
• Append and prepend helps give an order to things like how CSS files are loaded
• echo $this->baseUrl('path/to/file') will return BASE_URL . ‘path/to/file’ which is handy

Zend_Navigation

• Helps manage trees of pointers to web pages
• Supports HTML header links (i.e. next, previous, alt formats)
• Can generate XML Sitemaps (used by Google)
• Translate link text
• Conditionally display links based on ACL
• Two main concepts are pages and containers
• Page types: MVC (router based URLs), URI (static URLs)
• $page = Zend_Navigation_Page::factory(array('uri' => '/uri'))
• Containers implements RecursiveInterator (iterate entire tree) & Countable
• Pages are also a container, you can have trees of pages
• Add pages with $container->addPage()
• Can add multiple pages via addPages()
• You can remove pages based on index or order number
• Visibility and active page properties affect whether a page is rendered to the page
• Can find pages via methods like findOneBy(), findAllBy(), findOneByLabel()
• You can define your own metadata for pages. For example if you have a ‘tag’ property, find method for nav is findAllBy(’tag’, ‘value’) or findAllByTag(’value’)

• Rendering on the page:

  foreach ($container as $page) {
      echo $page->label;
  }

Cache your definitions

• On first request build programmatically and cache via toArray()
• On subsequent requests load from cached array
• Only use when you need it (i.e. not when doing JSON requests, service calls, etc)

Navigation view helpers

• $view->navigation()->setAcl($acl);
• $view->navigation()->setRole($role);
• Can set default ACL and default roles in your bootstrap. I’d suggest passing ACL from your controller into your view.
• Check for ACLs with hasAcl() & hasRole()
• echo $this->navigation()->htmlify($page);
• Renders link, uses label as title attribute

• Conditionally echo link

  if ($this->navigation()->accept($page)) {
      $this->navigation()->htmlify($page);
  }

• Note that other Nav view helpers are ACL-aware. I.e. echo $this->navigation()->sitemap()

• Sitemap specific metadata: lastmod, changefreq, priority
• Set priority of news list pages lower than news pages themselves, so Google deeplinks to article pages rather than news list pages
• Render breadcrumbs via $this->navigation()->breadcrumb()
• Useful configuration is setMaxDepth($depth) to avoid very long breadcrumbs
• echo $view->navigation()->menu()->renderSubMenu() – current active tree only
• Gotcha with breadcrumbs. If current page is hidden it won’t render breadcrumb

Caching

• Principle: Request from browser, is it cached? If so serve from cache, if not generate and save in cache
• Adapter based system. Front-end = what to cache, Back-end = where to cache
• Front-end options: set lifetime = null to cache forever (you then control when you empty the cache)
• Manually initialise cache in bootstrap. I.e. _initCache()

• Don’t do it that way! There is a better way! Use Zend_Cache_Manager (manage multiple caches)

  • Lazy loads on demand
  • Contains preconfigured caches
  • Application resource
  • Can use action helper to access it

resources.cachemanager.default.frontend.options.lifetime = "..."
backend.options.cachedir = APPLICATIONPATH ".."

‘default’ is name of cache. Make sure you use different keys for multiple caches.

Controller:

protected function _getCache()
{
   $bootstrap = $this->getInvokeArg('boostrap');
   return $bootstrap->getResource('cachemanager')->getCache('default');
}

// Helper
$cache = $this->_helper->getHelper('Cache')->getManager()->getCache('default');

• Zend_Cache_Page = full page caching – skip entire MVC stack
• Implement in index.php before config loading
• frontend options: ‘regexps’states which pages to enable page caching for. Not usually what you want for all pages on a site (i.e. dynamic content, forms for error validation, shopping baskets, etc)
• You can state cache everything apart from exceptions with regex rules

Some numbers to think about

• No caching: 12 trans/sec, cache DB: 29 trans/sec, cache page: 359 trans/sec

• With APC enabled: no caching: 19 trans/secs, cache db: 289 trans/sec, cache page: 3251 trans/sec

• Static page cache exists to store cache of HTML files to local document root. Amazing performance.

Context Switching

• Context switching is the act of providing different output based on criteria from the request
• I.e. XMLHttpRequest, REST, Mobile device
• WRFL – list of all mobile platforms and browser detection strings & capabilities
• Works via a ‘format’ parameter request. This can be set via:
  – Query param
  – Special route
  – Chained routes (’xml’, chain with a ‘.’ – i.e. controller/action.xml)
  – HTTP headers (Accept header)
• ContextSwitch action helper determines whether action has context matching the format
• Additional view suffix is added (i.e. viewscript.json.phtml, viewscript.xml.phtml)
• Keeps things explicit so you know where your code/views are

Add context switching to controller:

$contextSwitch = $this->_helper->getHelper('contextSwitch');
$contextSwitch->addActionContext('action', 'format')
              ->initContext();

Sitemaps and robots.txt

A neat example of context switching from Rob.

• Two static routes sitemap.xml & robots.txt
• Format values of ‘xml’ and ‘txt’
• Have to manually add context for txt (sets the correct Content-type header)
• View = sitemap.xml.phtml & robots.txt.phtml
• Can support HTML version of sitemap in sitemap.phtml
• So context switching changes Content-type and view script and uses same controller action
• Can do other stuff by getting param ‘format’

Header detection

• setHeader(’Vary’, ‘Accept’) – tells browser not to cache Accept header. Important!
• Set format based on accept header
• getHeader(’Accept’): application/json or application/xml
• To be honest I got lost around here. Will check out slides & Matthew’s blog later

Form Decorators

• Renders elements & forms
• Decorators stack from inside to outside
• The order of your decorators is the most important thing

Standard element decorators:

1. Zend_Form_Decorator_ViewHelper – renders input field
2. Zend_Form_Decorator_Errors – UL list of errors
3. Zend_Form_Decorator_Description – P description
4. Zend_Form_Decorator_HtmlTag – DL/DL tags

5. Zend_Form_Decorator_Label – field label

• The above happens in Zend_Form_Element::loadDefaultDecorators()
• Decorator itself states whether it wraps other elements or not
• Change this with: element->placement->prepend() – puts in front

Standard form decorators:

1. Zend_Form_Decorator_FormElements – form elements
2. Zend_Form_Decorator_HtmlTag – DL tag
3. Zend_Form_Decorator_Form – FORM tag

Common use cases to customise decorators:

• Change form element HTML (i.e. ul instead of dl)
  • Clear decorators and re-add them as you want them
• Change HTML outputted, i.e. parse form description using markdown
  • Extend Description decorator and alter output of description HTML

If you use your own decorator classes:

$form->addPrefixPath() – for Form class
$form->addElementPrefixPath() – for Form element & Validate classes

• Write your own decorators. Implement a render() method to return HTML. Extends Zend_Form_Decorator_Abstract
• render($content) accepts previously rendered content. You need to return the content you get in so you can wrap / append / prepend content – (that bit never made sense to me before!)
• Good idea to check the user defined separator & placement and alter output accordingly (otherwise you may break expected functionality)
• Sidenote: Rob uses simple App_ namespace for client website specific library files. Nice and straightforward
• Rob displays errors on form, not element. He removes errors on each element and puts a list at the top. This is achieved via a custom decorator called Form_Errors

Testing

• What do I test?
  • Domain models
  • Service layer objects
  • Integration testing (does your MVC generate the content you’re expecting?)

Testing MVC pages

• Extend Zend_Test_PHPUnit_ControllerTestCase
• setup() creates instance of Zend_Application
• assertions to match content. Uses CSS selectors aka jQuery (nice)
• also supports XPath expressions to match content
• redirect assertions
• response assertions (response codes, matching header content)
• request assertions (matching module, controller, action, route)

I.e. Assert a H1 heading exists: $this->assertQuery('#content h1')

Q&A

I quizzed Rob in the break on CMS style routing where all page URLs are stored in a database. He expanded on this in the Q&A session.

• MS_Controller_RouterRoutePostSlug (a slug = a URL fragment in good old WordPress terminology)
• implements Zend_Controller_Router_Route_Interface
• $router->addRoute(’postSlug’, new MSControllerRouterRoutePostSlug)
• Must implement 3 methods:
  • getInstance() – not used in Rob’s example, return new self(); neatly disables it
  • match() – must return array of module, controller, action. (This is totally undocumented in code or manual! Nice to see an example)
  • asemble() – creates a URL via url view helper. Usage may pass menu ID to create URL

match($path)

• method argument $path = URL path
• if return false, router falls through to next route
• Get slugs/URL fragments from DB in bootstrap & cache it for speed
• $slugs = array(URL => array(’module’, ‘controller’, ‘action’, ‘navigaton object’, ‘menu_id’) )
• custom keys accessed via $request->getParam(’menu_id’)

assemble($data = array(), etc)

• For normal routes you pass the module, controller, action, etc in via the $data array
• In this example you can put the following into the $data array: full url, page, menuId
• Returns URL string: output URL string . $this->_assembleRemainingParameters($data)
• That last bit is important if any custom params have been passed to assemble by the user

We all finished off with a stirring debate on how awful WSYIWYG editors are when someone asked how Rob convinces clients to use markdown.

• Rob just doesn’t give them a choice, doesn’t get many problems most clients OK (he is tech director so he can also decide within his company)
• Rob uses Markdown for clients (exactly what I used to markup all these notes!)
• If you allow HTML input from the user then don’t try to sanitize with ZendFilterStriptags. Use HTML Purifier instead which can be used to create whitelists. Pádraic Brady has blogged a lot about HTML Purifier

domain.com/user/register -> app/modules/user/RegisterController.php

While useful when we need to expand our URLs (and organisation of code) beyond one set of controllers, there are a few things they don’t currently solve which I think would make them first-class citizens within ZF.

I quite frequently find myself wanting some form of sub-modules, usually in admin systems where one “admin” module just doesn’t cut it for larger sites. Without modules we’re stuck with an AdminController.php which obviously gets very messy, very quickly. With modules, we can have an “admin” module with as many controllers as we wish. This is fine, until a site needs to manage lots of discrete elements.

For example, imagine a site with a CMS, user management system and a custom system to search for wines. While you could have a CmsController, UserController and WinesController in your “admin” module, it’s likely Cms and User would benefit from splitting out into multiple controllers of their own.

There’s also the issue of modularity. If I design a user management app which I want to re-use, it’s easier if I can install this into a folder (or SVN external it). If reusable components are mixed in the same folder they become harder to maintain and keep up to date.

In one attempt to solve this I created an Admin Modules bootstrap resource, which hijacks the domain.com/admin route and enables you to add admin modules to this URL.

To enable an admin module simply create a folder in your application folder called admin-modules. Within here simply place each module. Mapping works as follows:

domain.com/admin/
-> application/admin-modules/default/controllers/IndexController.php

domain.com/admin/user/
-> application/admin-modules/user/controllers/IndexController.php

Within each admin module the normal ZF rules for URL routing applies. For convenience my bootstrap resource also sets up an ID route:

domain.com/admin/user/groups/view/4
-> application/admin-modules/user/controllers/GroupsController.php / viewAction
passing a param called “id” with a value of 4.

The filesystem structure works as so:

application/
            admin-modules/
                          default/
                                  controllers/
                                  etc..
                          user/
                               controllers/
                               etc..

So admin-modules basically works like a copy of the main modules folder. Just for admin-only modules.

To enable this simply add the following line to your Zend_Application application.ini config file:

; Register a custom Bootstrap resource path (needs to be in your include path)
pluginPaths.S24_Application_Resource = "S24/Application/Resource"

; Enable admin modules
resources.adminModules.enable = []

Note: Please now see the sub-modules system for an improved way to implement this.

When things go wrong

You might see characters like  or ¿½ popping up over your text. This indicates the web browser is having problems interpreting the characters. The usual cause is a mismatch of the character encoding between how it is stored (by the filesystem or database) and how it is displayed (by the browser).

One common issue is to store a UK price with the pound sign in UTF-8 and display it as Latin-1. If you do that, you’ll get the rather catchy: £5.99

You might also spot the pretty black diamond question mark character: �

This is the Unicode replacement character and is displayed if the browser can’t output the correct symbol. Again, this is usually a mismatch of encodings, for example storing the content in Latin-1 and displaying as UTF-8.

UTF-what?

UTF-8 is a popular character encoding for Unicode, the current standard for storing text on computer systems. Unicode has over 107,000 characters and is intended to support all languages. Compare this with the catchy ISO-8859-1, also known as Latin-1, which contains only 192 characters. And doesn’t fully support French.

How to make your website Unicode friendly

Basically you need to store, transfer and display content as UTF-8 to ensure reliable Unicode character support. Some tips on a few common areas where character encoding affects the web appear below.

Files

The most obvious place to start is your files, i.e. HTML, CSS, JavaScript and any scripting languages such as PHP. If you have any special characters in a file (i.e. content in a web page or in a template) then you need to ensure you save those files as UTF-8.

The simplest thing is to just ensure all your files are saved as UTF-8. This is usually possible in a modern text editor. See below for tips on some common editors:

• In TextMate just go to Preferences > Advanced to set the default character encoding
• In Coda it’s Preferences > Editor
• In Eclipse, or Zend Studio, it’s in Preferences > General > Workspace

You can usually tell if you have a decent text editor or IDE if when you select Save As you get an option to change character encoding.

MySQL

Ensure all your database tables use UTF-8 encoding: utf8_general_ci. This can easily be achieved by simply choosing this encoding when creating tables.

Whenever you connect to MySQL make sure you run the following SQL. This ensures MySQL selects and inserts data as UTF-8.

SET NAMES utf-8

Bear in mind before MySQL 4.1 UTF-8 wasn’t fully supported and the default character encoding was latin1_swedish_ci. If you want to convert your data to UTF-8 take a look at this O’Reilly article on converting data from Latin-1 to UTF-8 or a Drupal guide on migrating from MySQL 4.0 to 4.1.

Apache

You can check the default encoding of your webserver by publishing a blank HTML page and using the Firefox Web Developer toolbar plugin to view the page response headers (Information > View Response Headers). You should see a line like:

Content-Type: text/html; charset=ISO-8859-1

A lot of webservers serve Latin-1 by default (just like the above example). If you don’t see a charset entry in there most web browsers also default to Latin-1. If this is the case ideally you need to change the character encoding HTML files are served as.

If you can change your Apache settings then open up your httpd.conf file, look for a line starting AddDefaultCharset and ensure it reads as so:

AddDefaultCharset UTF-8

Make sure you remove any comment character (#) from the start of the line to enable this declaration. You’ll need to configtest Apache and gracefully restart it to make the changes appear. If you don’t know how to do that you really shouldn’t be editing the server’s httpd.conf file ;-)

If you’re on a shared server, or you don’t want to set a default for all websites on Apache, you can set UTF-8 encoding for just one website via the VirtualHost declaration.

<Directory /path/to/document-root>
  AddCharset UTF-8 .html .php .js .css
</Directory>

Just add all the file extensions you want outputted at UTF-8.

This can also be done via an .htaccess file in the document root of your website (while flexible it will be slightly slower):

AddCharset UTF-8 .html .php .js .css

If all else fails and you’re using PHP to output your web pages, you can force it in PHP with:

header('Content-Type: text/html; charset=utf-8');

HTML

You should always state the character encoding in your HTML document.

In HTML 4 use:

<meta http-equiv="Content-Type"  content="text/html; charset=utf-8">

For XHTML (served as HTML) add the closing slash:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

And HTML5 the far more elegant:

<meta charset="utf-8" />

Keep this tag at the top of your element (i.e. before the title tag or any other element). According to the HTML5 spec it’s supposed to be within the first 512 bytes of your document, which for most of us means you have about 250 spare characters if you are serving an XHTML page with a valid doctype. If you’re using the more spartan HTML5 you’ll have more like 400 characters to play with.

Email

Finally, when sending out emails make sure you specify the encoding in the email header:

Content-Type: text/plain; charset="UTF-8"

This can be done in PHP as so:

// $to, $subject and $messageBody omitted for brevity
$headers = 'From: name@domain.com' . "\r\n" .
    'Reply-To: name@domain.com' . "\r\n" .
    'Content-Type: text/plain; charset="UTF-8"';
mail($to, $subject, $messageBody, $headers);

Though I’d recommend you use an email library such as Zend Framework’s excellent Zend_Mail to avoid things like nasty email header injection!

And if all else fails

If you’re managing an old site with data stuck with Latin-1 content all over the place, perhaps it’s easier to just serve that site as Latin-1. So if you have a webserver-wide default encoding of UTF-8 consider switching that for Latin-1 just for that website. You can always upgrade next time the client wants a site redesign!

Find out more

• Joel Spolsky on Unicode
• Character encodings in HTML and CSS

The questions themselves were things like “Print designers cannot automatically design for the web” and “Developers think they are web designers” which we both broadly agreed on. “Developers take too long to finish projects” was a little more contentious. My argument was that websites are complex and quite reasonably take time. Though there is often a misguided impression from clients once a design’s done the rest of it is easy.

There was one question that dealt with “Designers who don’t understand technology can’t design for the web”. To us devs that’s the one question of the evening that rings most true. Traditional print design is controlled and static, the web is flexible and interactive.

In the various points raised from people I clean forgot to point out the whole design in the browser thing. At Studio 24 we don’t expect our designers to craft each individual page lovingly in Photoshop. Instead we may start in Photoshop and once we’ve got an agreed look and feel we move into HTML/CSS and the designer continues there, designing straight in the browser. Design in the browser from scratch may not be for everyone, but the designer can only gain from being able to polish and realise their design directly in the browser where a web page acts like a web page and links are links. Personally I don’t see how a professional web designer can avoid using HTML and CSS in this day and age. The old “waterfall” technique of a designer handing over a PSD file to a developer for building is fast disappearing.

There were also various opinions from the floor. The copywriters quite rightly dug in highlighting the lack of attention they get in web projects. Dominick also pointed out the important role usablity and prototyping plays at Red Gate before a designer starts to put mouse to screen.

There are obviously a lot of topics that basically cover the gamut of the professional web design process. Something which CamCreative organiser Paul Smith touched on at the end saying he may try to run a longer day of talks on this topic if there’s interest.

I guess in summary it wasn’t really a debate as such, more a discussion on a set of topics. The evening highlighted good communication as key between the two camps, and for me I think both sides could learn a bit to understand the other. For developers its things like negative space and the grid. Go read Designing for the Web by Mark Boulton for more.

For designers unaccustomed to HTML and CSS go buy Zeldman’s Designing with Web Standards and start your journey into really designing for the web there. It’ll save you time and money, I promise

My talk was in one of the first slots on Brain Games, BBC and Facebook Fun. The theory being to jump in at the deep end and just get stuck in! The talk seemed to go well and was well attended by a probably very tired bunch of people early in the morning. The slides are now up on Slideshare, you can also check out the Cambridge Brain Sciences website and try out the most entertaining brain games!

It was good to meet new people and chat away to those I hadn’t seen for a while. The general atmosphere was fun, especially Saturday evening when Doctor Who took over a couple of the rooms along with beer and pizza. And the games. I watched, and partially understood, Settlers of Catan. Played a few rounds of Family Business, lost of course! Couldn’t stay until the early hours, but popped my head into a Werewolf game just as they took their first casualty.

The talks were of high quality. A mix of planned talks and impromptu stuff by people who obviously knew their stuff covering a diverse range of subjects from tech, science, japanese, photography and sleeping. Half the problem was working out which one to listen to!

Highlights included Mat Clayton’s talk on increasing users via Twitter and Facebook, by fair means and foul cunning. A real eye opener to what techniques really work. Michael Brunton-Spall had a good couple of talks, the first on Twitter @Anywhere, the second a joint one with Triest on Test Driven Design which expanded into a discussion on the merits of pair programming.

Gareth Rushgrove’s talk on Dev/Ops was also interesting on bridging the gap between developers and sysadmins. Other good stuff included open street data for CycleStreets, an agile technique from Toyota called Kanban, how to make a good screencast, an intro to Git, a detailed look at message queues and a nice diversion from tech with tips on how to take good macro photography.

My web agency Studio 24 were also very happy to sponsor the event, looking forward to Barcamb 4.

In this day and age you’d think standards was the assumed approach for all web agencies. From my experience, hardly so. Only last week I encountered two appalling coded sites via potential clients. One using tables for layout with no meaningful ALT text for images, the other a single image in a page with no text behind it (a 100% wide image too, which technically would work on an iPhone or iPad but be pretty much unreadable to everyone!). Both of which were from companies who claim to build websites as part of their professional services.

After following tweets from what sounded like an excellent An Event Apart, I heard about Eric Meyer’s talk on using media queries to deliver specific CSS depending on the device width or orientation. This means it’s possible to create flexible layouts for desktop and mobile simply with CSS (i.e. switching between a three column layout for desktop and a one column for mobile). Another great reason for using standards when developing for mobile or the iPad.

You can find out more about device orientation on Peter-Paul Koch’s site. There’s a summary of Eric’s talk over at Luke Wroblewski’s blog.