Whose Responsibility is Your Career?

There are 10 types of people in the world: Those who understand binary, and those who don’t.

I guess we’ve all seen this geek witticism, its a little piece of the fabric of the culture. Personally I split people into two groups along other lines: those that look out for their own professional interests, and those who don’t. I’m an optimist, so lets start out looking at those who do.

These people are self-starters. They have read relevant texts on their subject and depending on the type of industry they are from they either have blogs, news and syndication sites on their feed reader, or they subscribe to the relevant periodicals. You’ll see them at some of the events, sometimes a long way from home, and always “off their own bat”. They’ll be asking questions about how different technologies go together, about who they could approach with a particular question, and so on. If you mention web resources, they’ll go there and read what’s available. They might come back with follow-up questions. And they will be the first to also help another along his way, passing along the gifts that they have been given from those who went before and helped them to this point.

Then there’s the other kind of people. The kind that doesn’t have books of its own, that doesn’t interact with communities outside of work, and that “can’t” go to events because their employers don’t send them. I understand that money and time are both something that can be in short supply, yet I still have little patience with people who have this attitude. None of us can be everywhere that would be useful, but one event a year is do-able for most people, and in my opinion career development shouldn’t be free and effortless.

So – which kind of person are you? If its the first kind, what do you do to ensure you keep learning and keep growing? Post your stories in the comments!

PUTting data fields with PHP cURL

This is a little post about how to PUT multiple data fields using the PHP cURL extension. Why I wanted to do this in the first place is beyond the scope of this post, since its quite a long story. The curl command line allows data fields to be sent with a PUT request, and I wanted to do the same from PHP. Here is a snippet of code to show how I did it.

        $data = array("a" => $a);
        $ch = curl_init($this->_serviceUrl . $id);

        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
        curl_setopt($ch, CURLOPT_POSTFIELDS,http_build_query($data));

        $response = curl_exec($ch);
        if(!$response) {
            return false;
        }

I’m putting this here so I remember for next time – if it helps you as well then even better :)

New Bedroom Curtains

This weekend I took some time to make some curtains for the bedroom. Since we bought the house we’ve had some rather unattractive and slightly broken metal blinds. The room was otherwise OK though and we just kind of moved into it and worked on the rest of the house. I bought the fabric for the curtains soon after we moved in but I needed some help from my mum to actually make them as I wanted to do 2 layers and wasn’t sure how to proceed.

Window 1, before Window 2, before

Kevin’s mum Kath was visiting this week and while explaining to her why I couldn’t do this task myself, we kind of talked me round. Curtains are just straight lines after all so I dug out some crafty books and considered the task (thanks Kath!)

I had two layers of fabric, one plain sheeting and one floaty gauze – the idea of having floaty curtains but which do actually block the window. I measured the window and found that both were 74 inches high and were 56 and 44 inches across respectively. I do mean inches, our ceilings are 8 and a half feet high so most of our windows are taller than me! This of course makes curtains quite an undertaking, with 60 inch wide fabric and two curtains on the bigger window and one on the other, I had two 60 inch by 80 inch curtains and one 90 inch by 80 inch. By the time you have seamed edges and top, and attached curtain tape, that’s more than 30 yards of sewing and you need a LOT of floor to cut things out on. The wrestling was quite worth it though:

Finished Curtain 1 Finished Curtain 2

For reference, the curtains were quite easy to make (although they’re still unhemmed). The recipe goes something like:

  • cut fabric, lay out with right sides together
  • for the wider curtain, I joined half a width with a full width to get the size I needed
  • pin and then stitch down outer edges
  • pin and then stitch along the top
  • turn right side out (like a duvet cover!)
  • pin and then stitch corded curtain tape 5cm from top of curtain, along back
  • hang curtains
  • admire
  • Wonder how long til I get around to hemming them? My excuse is that curtains are supposed to hang for a while, to allow them to “drop” to their eventual length!

Presenting with a Netbook

I’ve been giving a few talks in the last few months and I’m increasingly realising that although I love my thinkpad, its overkill for anything where I don’t really need the hardware, or where I don’t want to be carrying a full-size laptop all day. So I’m increasingly taking just my netbook, which is an acer aspire one with 512 MB of RAM, and using that along with some xrandr skills and my much-loved Kensington Slimblade Presenter Mouse (its the multimedia version, has extra controls on the underneath).

Presenting Setup

The netbook is easily up to this job – it happily runs the open office presenter program, I don’t have the presenter view plugin installed on it yet but just use the screens mirrored and use the netbook screen to see the current slide rather than having to look at the screen. This saves me either having to look away from my audience or from being completely floored by slides WAY too big for me to read when I’m standing in front of them (I presented at the FOWA roadshow, great venue but slides so big I didn’t dare look round at them!). The netbook screen is small but font sizes on slides should be quite big and I’m kind of long sighted so I can read the text at a distance of 6 to 8 feet without an issue.

The presenter mouse has a little USB dongle and then controls for controlling the presentation, with a laser pointer and a button to turn slides to black – once I begin I don’t need to be back within reach of the computer at any point. Which is really useful if you get one of those awkward spaces where the dock for the laptop is in a corner you don’t want to be standing in (I see this a lot at the informal geek events). Just start it going and get into position – and present from there. Of course this relies on knowing the presentation well enough to not need your slides or notes or having a paper copy you can refer to.

Don’t be fooled that you need great hardware or particular equipment to give a talk – anything with a monitor socket to talk to the projector is good enough, and if you can get a remote of some kind then all the better. Other accessories that might help is a stop watch (or use the timer on your phone and put it somewhere you can see it), so you know how you are doing for time, and some notes on index cards that you can easily hold without rustling. Above all, take a step away from your computer and look your audience in the eye – they’re here to see and hear you.

PHPNW: Site, Tickets and CfP

The date for PHPNW was announced a few weeks ago as Saturday 10th October 2009, and now we’ve got all the official bits and bobs to go with it! In outline:

The website: http://conference.phpnw.org.uk

Tickets: http://conference.phpnw.org.uk/register. Early bird pricing until September 11th, student tickets available – look on the website for instructions on getting student tickets.

Call for Papers: http://conference.phpnw.org.uk/callforpapers. Speakers wanted! If you have something to share and you think you can do that coherently – then submit to us please, we’re always looking for new people, new talks, as well as the talks and speakers you’d expect to see at the bigger PHP conferences. If you’re not sure if something fits, feel free to contact us.

This is officially a one-day Saturday event, with a full day with two tracks of talks and an attendance of 200+ people. In reality its a whole weekend of geeking out in Manchester – with a pre-conference social on Friday night, the main event on Saturday, a conference social running on Saturday night and an informal set of sessions on Sunday morning for anyone with the energy to keep on going before everyone makes tracks to their homes.

If you’re going, thinking of going, went last year, or wishing you could be there – add a comment! I’m looking forward to meeting many of you at the event :)

Status Codes for Web Services

This the last entry in a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web services, saving state in web services and using version parameters with web services.

Unlike the other posts in this series, this one is quite specific to one type of service – REST – since it deals with status codes, specifically HTTP ones. The ideas are transferrable however and other types of service can return statuses in a similar way.

There’s a few key things to think about when returning status codes. In earlier posts in this series these was discussion of using existing application framework to serve pages and changing the output mechanism accordingly. Usually a web page will return a status 200 for OK or also 302 for found, so this is fine when things are working normally. But when things aren’t going quite so well, its useful to give alternative feedback that can be easily picked up by a client application.

When things go wrong there are a couple of different schools of thought of how the service should respond. One is that if, for example, the user supplies data which fails validation, the service could provide the OK response and a message to the user to let them know what needs validating – exactly as we’d return information messages to a user filling in a form. To be considered restful however, the service should more correctly return one of the “400” status codes, which means that the client made an error. Interesting and useful codes* in this series are:

  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 408 Request Timeout
  • 417 Expectation Failed
  • 418 I’m a teapot

* I didn’t say they were both useful and interesting

Using descriptive status codes allows the client to get the headline of the problem without having to parse a whole request to find out whether it is good or not. HTTP already has this feature built-in, and so we make use of it (HTTP is pretty cool really, makes a great protocol for services!).

Where an error occurs on the server side – it is usual to return a 500 error or another in the 500 series. This lets the client know there is a problem outside of their control; it is useful to include information about whether the client should retry and when. Having a defined protocol for retries helps avoid the situation where a system comes back up only to fall over again with all the traffic from people retrying every minute (or other interval) – this is a real concern for systems that are under heavy load.

Status codes are like a headline to the calling entity about what happened, and are a valuable tool in the web service toolkit. For bonus points, leave me a comment and tell me which is your favourite status code :)

Version Parameters for Web Services

This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web services and saving state in web services.

When designing a service API, there are lots of things you can do right, and plenty of pitfalls. Most of both of these are completely specific to the situation you are designing for but I have one tip that has helped me out in a number of scenarios: Include a version parameter with every method call.

This is invaluable, not just in development where you can increment when you change the API (which could be quite often!) but also in production. For example if you want to extend or alter an existing service, you can identify which version of the API the client thinks it is accessing and behave accordingly – either letting them know there’s a new version, or preserving previous behaviours. Its never ideal to change the API of an existing service but sometimes it makes more sense to do so, especially if its just to include an additional parameter or something else quite minor, but which does cause an API change.

When you publish your shiny new service which does everything you need (including the hoovering), it might seem a bit redundant to require a field which is always set to the string “1.0” … but in 18 months time, you’ll be patting yourself on the back.

Saving State in a Web Service

This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services and auth mechanisms for web services.

Web services, by their very natures, are stateless, and this is no different to any other web application with a frontend. Its often helpful to keep track of the sequence of events something experiences. Similarly we might want to store the details a particular piece of data encounters on its lifetime in the system. When it was created, when it was changed, where in a given process it is up to, and so on.

A good example of this is a service I run for a few friends which accepts a URL, requests it and takes a screenshot, then turns that into a thumbnail and makes it available. There’s a few definite states in that sequence and its better to store which it is than try to guess from which fields have dates in or something. So the states are something like “new”, “error”, “in progress”, “ready” and “expired”. I can look at any of the jobs that come in, at any time, and know exactly where that item is up to.

When Things Go Wrong

It’s also pretty to have a strategy for failure. I already talked about giving users sensible feedback from a service, but the service also needs to keep track of what’s happening. There are decisions to make which depend entirely on the application under consideration but for example whether a failure is terminal, or whether the system should keep trying is quite an important thing to consider. Perhaps you just want to flag records that failed, so you can check on them later. Or you might want to retry – a set number of times? Or at decreasing intervals? An undesirable outcome would be to have the same record submitted every minute (or whatever) forever, so its worth planning to avoid this eventuality. Think also about the likely causes for failure – a split-second glitch or a likely human error which might take a day or two to be noticed and rectified?

Logging

Logging is something which is ideally of zero value. If nothing ever went wrong, you’d never care to look at an individual record and dig into its journey. However in the real world, we do need to be able to debug systems, sometimes under pressure. With logging there are a few different choices – whether to log to file or database, and whether to log continuously, or only at given times. Times when you might want to enable or increase logging are in development and when tracing a bug. However having some background amount of logging (and a way to stop the archives becoming too large) is recommended to keep track of who did what and when. Bear it in mind for a service just as you would for a web application.

Memcache Follow-Up Article on Techportal

Today techportal published a new article of mine on their site – New Memcached Extension for PHP. Its a sequel to the article I wrote for them earlier in the year entitled Getting Started with Memcache. At the same time I wrote that first article, Andrei Zmievski released a new extension for PHP to make use of the functionality in the libmemcached library – so I wrote the new article to give some information about it.

Fixing Broken Serendipity Category

I migrated this blog to serendipity almost two years ago, and there have been a few things about it which have always driven me a bit mad. Many of these improved when I upgraded to version 1.4.1 of s9y but a few have persisted, including having two of my sidebar categories not display correctly. Where most of the categories behave as expected, two of of them just didn’t apply any filter at all and all my posts were visible on these pages.

I finally sat down today to diagnose the problem and discovered I was missing a record from the serendipity_permalinks table which was stopping s9y from being able to look up the id of the category. It was my craft category which is id 7 – all I had to do was run the following against mysql:

insert into serendipity_permalinks set permalink = "category/craft", entry_id=7, type="category";

So now my craft category works fine. If anyone knows how to stop my feeds from showing old articles as new when I edit them but don’t update the publication date, I’d be grateful! A bunch of imported posts are still missing their images, would be nice to be able to fix these without polluting my feed.