The cakephp_2.0-dev branch was throwing the following error for me when trying to use the Twitter OAuth API.

The relevant changes are available in my cakephp_2.0.5 branch on Github.

Changelog

• Rename directories to match new conventions.
• Change createConsumer method to use $className rather than $fileName to fix ‘Consumer twitter_consumer.php not found!’ exception.
• Use App::uses instead of App::import to fix ‘Fatal error: Class ‘HttpSocket’ not found…’ error.

Get the code

https://github.com/Stanton/oauth-consumer-component/tree/cakephp_2.0.5

Multiple image sizes

We’ve traditionally been hampered by the fact that Jadu doesn’t yet have the ability to generate multiple image sizes from a single base image so if I wanted to have a large document level image, and a smaller thumbnail within a list view, I’d either have to resize with CSS which results in degraded image quality in some browsers, or have the editors upload multiple versions of each image to the CMS and figure some way to switch between these programatically. Neither of these options were desirable, so we built an image helper that, instead of inserting the element directly into the front end script, we pass the image name to the helper, along with the desired attributes such as a specific height and/or width, the helper then resizes the native image, and caches it for future use.

Take the UoL Press Releases news section, for example, we can now elegantly deliver multiple image sizes depending on our needs, without either the bandwidth overhead of resizing large images, or the administration headache of managing multiple images within the CMS, and the image helper can be used anywhere in our front end templates.

we can now elegantly deliver multiple image sizes depending on our needs, without either the bandwidth overhead of resizing large images, or the administration headache of managing multiple images within the CMS

Image attribution

The next issue I’ve been looking into recently is that of image attribution, again, Jadu doesn’t currently have any options within the multimedia gallery module to attach attribution data to multimedia items. If the UoL wants to use a Creative Commons licensed image, there’s no way, other than adding the attribution data into the body content. I figured there was a better way to do this.

The Multimedia Module within Jadu is the central place to manage all types of multimedia content, for this example I’ll focus on images. One of the core concepts of a CMS is that an image only needs to exist once, but can then be included in any other piece of content. The multimedia manager is a relatively recent addition to Jadu CMS, and as such, provides the bare minimum of features required so I needed to find a way to link attribution data to an image without modifying the core CMS code.

Enter machine tags

As we can apply tags to each image, this was a perfect place to use machine tags – a piece of text which contains machine-readable semantic information – to include the relevant licensing information. Machine tags are composed of three parts; a namespace, a predicate, and a value. For example:

Initially, I hit a brick wall in that the ‘tag’ column within the JaduMultimediaTags table was limited to varchar(50), a sensible default for most english word based tags but kills the chance of using machine tags which are typically longer. Frustrated, I moaned a bit on Twitter, and within minutes had an email from @ap49 at Jadu asking what they could do to help, and later that night they’d modified the Jadu trunk to change the tag column to varchar(255) which is much more useful, for me at least!

So, armed with our enlarged tag column, I set about writing a function which would parse an images’ tags for our license machine tag, extract the relevant components, and spit out some meaningful markup to the browser which we could style as needed. You can get the Image License function from GitHub, in case it’s of use to anyone.

For the University of Leeds’ corporate site, I wanted to include a small copyright, or creative commons symbol in the corner of the image, which would then expand to show the license detail when hovered over. I chose to use CSS for the hover animations rather than javascript and I’m quite pleased with the result. Modern browsers get a nicely animated transition and older browsers simply display the information on hover. The license function can be extended to provide the data in different formats depending on the content’s needs. For a homage widget like the one below, a subtle copyright icon works well, for images, illustrations or figures within a document we may prefer to list all of the attribution data at the foot of the document in a list of references.

Here’s the attribution implemented on our document image component:

Low impact development

Working in this way, we’re able to extend the functionality of the CMS without modifying the core product (which would complicate our upgrade cycle) because we’re making the assumption that these features will eventually be provided natively within the CMS. These functions enhance how we manage and use images, yet are lightweight enough to be stripped out and replaced by native functions if and when they become available.

Killer Course Finder from Jadu on Vimeo.

This is a presentation I delivered at CISG 2010 in Brighton, and Online Information 2010 in London late last year. This was my first foray into public speaking and I had an absolute blast and received some great feedback from the attendees. This session covers Coursefinder, probably the project I’m personally most proud of, and is about 50% what’s been done so far, and 50% what I’d love to do next. (I do go on a bit of a rant at 16 minutes in).

A university course finder is a phenomenally important tool, the internet makes it possible for a prospective student to evaluate courses from an array of Universities from the comfort of their bedroom, perhaps without ordering a printed prospectus
…perhaps without putting on trousers

Big thanks to the guys and girls at Jadu for the speaking opportunity and for producing the video.

I work for the University of Leeds as a generalist designer/developer, a recent project of mine has been upgrading our institutional Content Management System to the latest version of the software, a task which had an extremely tight timescale which was met by using a structured development process.

My toolbox

So let’s set the scene, I work within the Central IT Services’ Web Team and am the technical lead for the University of Leeds’ corporate website (www.leeds.ac.uk), this site runs on top of the Jadu Content Management System and was launched in September 2009. We have just performed a major upgrade of the core Jadu CMS which was turned around in a very short space of time, and it’s this upgrade project which is the basis for this post.

University of Leeds (www.leeds.ac.uk)

For those of you wanting to know which apps and tools I use, here’s a quick rundown:

• iMac 21.5″ 3.2GHz Intel Core i3
• Textmate
• Terminal
• MAMP (local Apache/MySQL server)
• GIT (Version Control System)
• Trac (Project Management and Issue Tracking)

Project management tools

There are a whole host of tools available which will allow you to manage your project, both free and paid-for. Within the Web Team, we use the Open Source ‘Trac’ Project, Trac may not be the prettiest piece of software ever written, but it’s extremely flexible through a plug-in architecture and being open source, we’ve moulded it to fit our exact needs as a team. The key features we use are issue tracking, milestones and source code management.

“There are a whole host of tools available which will allow you to manage your project, both free and paid-for.”

As well as using Trac internally within our team we have opened up access to a couple of teams within the institution who work with us on the corporate project. The Central Communications team (Comms), for example, have the ability to assign and manage tickets, see the commit history and timeline and read the wiki, but don’t have access to the source code repositories or source browsing facility through Trac.

local > staging > production (aka develop > debug > deploy)

There are three separate environments which I use to develop for leeds.ac.uk. Firstly, all of the code I write is done on a local server which runs a complete standalone version of the code and database. This allows me to mess around as much as I want without any risk to the live site and database which runs on the production server where the live version of leeds.ac.uk lives.

In between my local development server and the production server is the ’staging’ server, this is an identical environment to the production server (even running on the same physical hardware) and is accessed through a private URL. By running this staging server I can deploy code for the team to test, confident that this is identical to how the site will operate once deployed to the production server.

The deployment is handled through the GIT version control system which is tied to our Trac system where we maintain a central source code repository (even though it’s not strictly needed with GIT, we still maintain a central repo for ‘disaster planning’), code is pushed from Local to Trac, then from Trac to Staging and ultimately from Trac to Live.

How it all tied together

During the upgrade project I worked with our internal project co-ordinator and the Comms team to define a set of milestone dates for the project, such as ‘testing’, ‘pre-launch’, ‘launch’ and ‘post launch’.

We knew the date the site had to launch by was concrete, so worked backwards from there, with the pre-launch milestone set to the start of the week of launch, this contained any issues and tasks that needed to be completed before we could possibly go-live (such as a last minute content-freeze and migration from the currently live site to the upgraded site). Finally, the post-launch milestone allowed me to keep any tasks that weren’t directly related to the launch to be processed afterwards.

“We knew the date the site had to launch by was concrete,
so worked backwards from there”

We had a thorough round of testing in the weeks running up to launch, the task of testing was performed by Comms who were testing against a ‘release candidate’ build on the Staging server. They worked for a week going through every single page on the Release Candidate build and logged tickets for any bugs, whether they be for differences in layout or differences in content. This is a critical step and their eagle eyes spotted a wide range of issues, from missing/out of date content, to the fact that the breadcrumb trail was 2 pixels further to the right than it should be.

These issues were all classified against a simple priority scale:

1. Blocker (the site can’t possibly go live until this is fixed)
2. Critical (if this isn’t fixed, people may die)
3. Major (it’s a big problem, but no-one’s going to die)
4. Minor (this needs fixing at some point)
5. Trivial (no-one would probably notice except us)

“a ‘critical’ issue may be seen as one which would cause the institution to cause severe confusion or lose money”

If you were to take into account the business considerations, a ‘critical’ issue may be seen as one which would cause the institution to cause severe confusion or lose money (such as printing an incorrect emergency phone number). Not all content is created equal, so a content difference on the Press Releases page might be classed as ‘Major’ while a page buried in the bowels of the site with a spelling error might be classed as ‘Minor’ or ‘Trivial’. It’s worth sitting down with the people who are going to be creating most of your tickets and defining what your priorities are to make sure that everything is not logged as high-priority to try and get them finished quicker.

(Based on this project I may move to remove the Blocker priority, as nearly all critical issues could be considered blockers)

I left the team alone for a week to perform their testing, only stepping in to fix any Blocker/Critical issues which would hamper their testing efforts and being on hand to answer any questions they had, after they were satisfied the entire site had been tested, their access to staging was revoked while I worked through all of the tickets assigned to the ‘Testing’ milestone. This process took 3 days for a couple of hundred issues, once the reported issue had been resolved the ticket was re-assigned to the owner for them to recheck the issue, and for them to close the ticket if it was fixed, or fail if it was still present.

Make your tools work for you

I am lucky to work with some extremely talented people, including a colleague who installed and maintains our Trac instance and implements some of the weird and wonderful ideas we have to make it more useful for us. One of the most used tweaks was to use the post-receive hooks of GIT to allow us to modify tickets based on the commit message.

For example, I accept Ticket #356 which requires a code change to resolve. I make the required change to the code and commit this to my local repository with the following command:

When I next push my changes to Trac, the post-receive hook recognises the ‘Fixes #356′ part of the commit message, adds a comment to the ticket linking to the specific changeset and diff showing exactly what changed, and sets the ticket to ‘testing’ status, which then fires off an email to the ticket owner prompting them to test the fix and close the ticket if it’s resolved.

I also communicated the progress of the project with the testing team by highlighting which version of the code the staging server was currently running:

Code version

This linked through to a summary changelog, which gave an outline of what had changed from version to version, clicking through would list precisely what had changed in the code and which tickets were fixed:

Trac changelog

We projected the Trac roadmap screen in our office with an auto-refresh which let us watch the testing milestone gradually reach 100% completion as the Comms team signed off the fixed tickets (I’m a sucker for visualising the size and progress of the task). All of this communication regarding the process of the project was passive, it was only available if and when anyone needed to see it.

Projection of project progress

In conclusion

It doesn’t matter what tools or software you use as long as you’re able to make them fit around the way you work. If a piece of software gets in the way of how you work then you should seriously consider either changing it, or (if possible) changing the way it works to better suit your needs. If you’re working with other people on a project, communication is essential. By keeping everyone involved up-to date you can reduce the amount of time needed for meetings and reach that magical milestone, getting sign off.

if..endif syntax

We’ll start with a simple example of a ‘regular’ statement which includes a foreach and an if statement which is extremely common among PHP scripts.

Now, just for funzies, let’s make this a tiny bit more complex and mix in some HTML markup in there for good measure, just like you’d see in, say, a WordPress template where we’re jumping back and forth between HTML and PHP mode.

See the closing braces on lines 9 & 10? With a relatively small example like this you can scan back through the code to see wether they close the if or the elseif. Now imagine a much larger statement, the only way to find out what the closing brace actually closes is to either pay attention to the tab levels (providing the tab levels have been maintained properly), or to read back through the whole statement and match them up. There is an alternate syntax which makes life a little easier.

Alternate syntax

By using the alternate if..elseif syntax we can replace those closing braces with something a little more useful.

This alternate syntax is expecially useful when mixing PHP and HTML and works for if/while/for control structures.

Ternary operator

For simple evaluations you can use the ternary operator which is a slimline version of an if/else statement, for example, the following statement which pluralises a string based on an integer variable.

Alternate syntax

Using the ternary operator this can be condensed to a single line:

Have a try!

By learning and adopting these alternate syntaxes you will ensure that your code remains readable and maintainable, especially if you’re writing code to be used by other people. Give them a try!

The Cake paginator helper works fine if you’re using basic anchor links to trigger sort options, but I wanted to use a dropdown select element so that the user can choose how to order the moblogs.

So I know this is most likely a horrible solution to the problem and certainly not very ‘cakey’, but it’s quick, dirty, and it works for what I need it to do.

In the view we need a valid form element, even though the javascript hijacks the onChange event and doesn’t actually post the result. At the moment this does mean that this doesn’t work without javascript but I plan on improving this soon by only using $paginator->sort links in the view, and replacing them with the form completely in javascript.

in the view:

In the jQuery we take whichever value was selected on change, build the relevant ‘paginator compatible’ url which the helper will use to return the required data on page load and then redirect the browser.

jQuery:

In this particular example, I’m using a random order also, which needs to be an ‘order’ param instead of a ‘sort’, so in the controller I’m checking which params are being used, and setting a consistant order variable which is used in the view to maintain the selected state of the select element.

in the index method in the controller

If any Cake ninjas are reading this and have any suggestions, or better methods, please do leave a comment!

Deliciously Timed Tweets (or DTT for short) is a collection of API’s which allow you to bookmark links in Delicious, and then automatically tweet them at a specified time interval.

What’s the point?

Delicious does already allow you to tweet your bookmarked links, the only problem is that this can result in Twitter spam if you bookmark lots of links in quick succession. DTT queues up your recent bookmarks, and allows you to specify a rate (say, every 60 minutes) for them to be tweeted at.

DTT powers the @boaglinks twitter feed.

What do I need?

• PHP 4+ with cURL support
• MySQL
• Access to cron
• A Delicious account and some bookmarks.

How do I get it?

Git : git clone http://coffeepowered.co.uk/labs/dtt/.git

Zip : http://coffeepowered.co.uk/labs/dtt/dtt.zip

Tar : http://coffeepowered.co.uk/labs/dtt/dtt.tar

How do I install it?

1. Grab the source from any of the locations above and extract/upload it to a location on your own server
2. Modify config.php with your own details
3. CHMOD install.php to 755
4. Visit the install.php file in your browser (http://yoursite.com/path/to/file/install.php)

The default setting is for DTT to sync with delicious every hour, and new bookmarks will be tweeted out at a an rate of 1 per hour.

Support?

Officially, this is provided “as is” and is an unsupported script, however I’ll endeavour to provide support for anyone who does have problems but I can’t promise anything!

When it comes to embedding a company logo into a page, quite often the logo won’t be suitable for print. For example, the website may be dark and the logo might be light and while this works fine when the site is viewed on-screen, it can look out of place when used in a print stylesheet or if the site is viewed with CSS disabled.

While building the new University of Leeds corporate website we got to the stage where we needed to build our print stylesheet, the page header has a white logo on a dark background.

Originally, the logo was inserted into the design using a standard CSS image-replacement technique:

Light logo on dark header

When you’re using a CSS image replacement, the image doesn’t exist in the markup, it’s applied as a background image and only the h2 text is displayed. We toyed with the idea of using the same image replacement technique in our print.css, replacing the logo with the black-on-white variant. This quickly fell on it’s arse, as most browsers are set by default to not print background images as seen below.

Image replacement with CSS disabled

Putting the image back into the markup

In order to get around this, we decided to stop using image replacement and go back to having the image in the markup. Initially I was curious as to the effect of this from an SEO standpoint and had a quick chat with an SEO friend about the disadvantage of not having our corporate logo as a heading. He pointed out that there would be no disadvantage to us as we’re not trying to rank on the ‘University of Leeds’ as a keyword and that as it’s mentioned everywhere else in the thousands of pages we manage, it’s not going to make a difference. (Your mileage may vary and this might not be suitable for everyone)

Doing it bass-ackwards

Once we’d put the image back into the markup, it showed up as expected in our print stylesheet, however our white-on-black logo wasn’t really suited.

Same logo with CSS disabled

We already knew that we couldn’t use CSS to replace this with the black-on-white logo in our print.css, so we decided to do it the other way round. Rather than the have the white-on-black logo as default, we changed to having the black-on white as the default meaning that our no-css and print.css got the correct logo. We used a “hidden” class so we could hide the default image and a CSS overlay on the anchor tag to bring back our white-on-black logo to fit in with the rest of the design.

CSS enabled

CSS disabled / print stylesheet

Conclusion

Because most browsers disable background images when printing by default, you need to be aware that any important images that are using image-replacement techniques may not work. Working around these limitations is possible with a bit of planning.

It’s handover time for Überproject and as we’re wrapping up our development I’ve been taking stock of the last 12 months and thinking along the lines of “If we had to do this all over again, what would we do differently?” aka “What gave us grief, and how can we avoid doing it again”.

Meaningful milestones

One particular aspect of Überproject was a large section of bespoke functionality which was, in effect, a project within a project which I’ll refer to as #up1 for the purposes of this blog (It’s not gone public yet, so I can’t name it specifically).

Early on, we attached two milestones to key stages in the project, a testing milestone, and a go-live milestone.

The testing milestone was defined as a date when functionality was to be delivered to our development environment ready to be put through it’s paces where any bugs would be logged as tickets in Trac (our project management / source control platform) and we would then work through any outstanding tickets before the go-live milestone date.

#up1 was given milestones consistent with the rest of the project with a couple of months between testing and go-live, the development of the back end was going well and the front end development would be taken care of later with the rest of the front-end build (which had it’s own milestone).

About a week before the testing milestone was due for #up1 I was hit with a bombshell. The definition of ‘testing’ in this instance meant that the back-end had to be fully functional and production-ready for the end-users to start populating the module with data. This meant that the back-end should have entered testing weeks ago and had bugs ironed out before the end-users ever got close. The back-end needed be go-live ready.

Fortunately, a week’s worth of frantic coding meant that I got #up1 fully functional before the users were allowed in and this was only done on a limited basis, users were aware that we were still in development and we turned the situation to our favour by deputizing them as bug testers by asking for and encouraging feedback.

The moral of the story?

Going forward, we will need to be absolutely clear of what’s expected to be delivered at each milestone and avoiding vague terms like ‘testing’, as we’ve seen, the definition of testing can vary wildly between different aspects of the same project.