LornaJane

This post is the second in a series of three about organising and hosting events. If you're interested, you could also read the first post about event preparation.

As an organiser you should know exactly where you are going on the day and what you need. Namebadges (sticky labels and pen if nothing else) will be needed at registration, if you have tickets and need to tick people off then rope in lots of volunteers (it sounds like a lot but 3-5% of your total attendee count is ideal) and brief them, and spread out across as much space as you have so you can parallelise as much as possible - registration is always chaos because of course everyone shows up at once and causes a backlog!

Last week I was preparing a training course for a client, and I wanted to print the slides nicely for the attendees to refer to and make notes on etc. The slides were done, I'd talked to my friendly printers (Mailboxes etc in Leeds) and all I needed to do was generate the handouts. Which was fine until I googled for help with doing that from OpenOffice, only to find that although it has this awesome "Export to PDF" functionality for documents, slides, etc, it wasn't going to do it for handouts.

I'm an ubuntu user, and it turns out that there's a clever package called cups-pdf which installs a pretend printer, and anything you could print, you can turn into a PDF. Brilliant. I installed it with aptitude and instantly I had a printer named "PDF" which printed to a /home/lorna/PDF directory.

Did I mention I love ubuntu?

I also wanted to add a cover page to my document, before I sent the whole thing to the printers in a PDF file for them to print and bind. For this I simply created an OpenOffice document and used the usual export to PDF. By the magic of twitter, I got some great advice from EmmaJane and installed the package PDFShuffler which enabled me to combine the two documents and save the result as a PDF.



By the magic of open source, I have beautiful handouts :) Printing in Linux really has come a long way, I can't thank the developers and maintainers of all those libraries enough - all I did was install two packages!

I've been to a lot of events, mostly technical, software-related ones, and I've also helped organise a few as well. For people organising events for the first time there are definitely some pitfalls that might not be obvious until you actually, well, until you fall into them! I thought I'd capture my experiences into a series of blog posts, in case they can help any future organisers to avoid some of the traps. First up: what to do before your event starts.

People aren't very good at reading between the lines and doubt could mean they don't buy a ticket for your event. To combat this, put up a website well in advance and make it very easy to find out:

• 
  event location


• event date


• prices of tickets and how to get one


• schedule or structure, basically what to expect and why people should be there


• how to contact you

These are the absolute minimum. My recommendation is that you will also want to include (as early as this information can possibly be available) any extra items such as the dates and times of any social events (so people can include those in their travel plans), travel advice and/or directions, and for bonus points local knowledge such as where to stay, local facilities, etc. One year the PHP London conference did a full set of directions complete with photos - I can't find those now but I loved the idea and did something similar for PHPNW09.

Without this kind of information, people are much less likely to do the work to find it all out themselves, or may not feel confident enough to come along. I've also been bitten by events where the info was sketchy and the event turned out to be just as sketchy! Where the information is easily available, transport links are listed, and contact numbers given, the experience has been much smoother and more pleasant all round - this is especially relevant if you have speakers or attendees travelling internationally who may feel a bit lost when they are trying to make their way to the venue.

Make sure you also pick a hashtag for people to use when they are blogging or tagging tweets or photos, that way your attendees can start to make links with one another (and on a more negative note, you'll see when people are complaining and you can respond!). Already you are building the community that will make your event a success ... and if you've done all of the above then rest assured that you are absolutely on the right lines!

If you have any more tips, share them in the comments, I'm sure there are things I either missed or don't even know I should be doing!

This weekend I'm at froscon in Germany, giving two talks. One had no slides (but may have video, if I see it then I will post the link here) and the other was "Working with Web Services" which I gave this morning in the PHP room. My slides are here:



Thanks to the PHP room organisers for accepting me as a speaker and to Sebastian for twisting my arm in the first place - it's a fun event!

This is a trick I use when deploying websites so I thought I'd post it here for posterity. Actually, technically I stole it from someone else but for now let's pretend it's mine (thanks @__kb!)

When I deploy an application, which is almost invariably a PHP application, I like to put a whole new version of the code alongside the existing one that is in use, and when everything is in place, simply switch between the two. As an added bonus, if the sky falls in when the new version goes live, the previous version is uploaded and ready to be put back into service. In order to be able to do this, I have my document root pointing at a symlink, let's say it is called "current". (disclaimer: I have no knowledge of non-linux operating systems, this post is linux-specific)

When it is time to deploy, I place the new code onto the server, and create two new symlinks, one called "previous" which points to the same location as the "current" symlink does (bear with me) and one called "next" which points to the location of the new code. To deploy, all I need is this:

The f forces mv to overwrite the target if needs be, and the T directs mv to consider the second argument as a normal file, rather than as a directory to copy in to. The neat thing about doing it this way is that it happens in a single move, no weird results for people who manage to hit your site while you are typing the new symlink command or during the code updating. It is also just as simple to roll back from this, since you have a symlink pointing to the previously used code version.

I thought I'd share this snippet as it is a handy inclusion in deployment scripts/strategies. What are your tips for managing code deployment?

A couple of weeks ago I gave a lightning talk at the PHPNW user group entitled "Geeks Can Write" or "Can Geeks Write?" - basically shooting down the worst of the excuses for not writing that I've heard and asking everyone to give it a shot! If you are interested, then the slides are on slideshare. Happy writing :)