PHP Unconference Europe 2011: Part 1

This weekend saw the PHP Unconference Europe 2011 event in Manchester. The organisers were hoping that the rain would hold off for the weekend, and being true to form Manchester was wet and cold. Being an unconference the talks and discussions are mainly casual and dependent on what everyone decided to see on the day. The event ran across Saturday and Sunday with different talks on each day.

Saturday

Picture taken by Lorna Mitchell.

The event began with a small introduction and thanks to the organisers before we started to vote on the talks everyone wanted to see. This involved putting a bunch of sessions or interests up on the wall and then decided what we all wanted to see by putting little blue stickers on them. There were two tracks so I obviously can't comment on sessions I didn't go to, but Saturday started off with Lorna Mitchell talking about how to speak to developers.

How to speak to developers
Lorna Mitchell

Even though she created the content for the talk 5 minutes before hand it didn't really show. There were no slides for the talk, Lorna had just sketched some notes out into a spreadsheet so she could see what she wanted to talk about. Lorna has lots of experience in talking at conferences all over the world so I have a lot of respect for her and wanted to see what she would say. There were lots of little hints and tips from preparing slides to taking a bottle of water in with you so that you can take a drink every now and then.

When slides are in question it is important that you try to tell a story about a topic and not just show some slides off. Don't feel that you need to have beautiful slides, they only serve to distract the audience. Also important is not getting into the trap of talking to the slides, you should just have them there as a synopsis of your talk, not the main content.

Before the talk you need to rehearse. Obviously talk through the slides, but also find a technical audience and try out the talk on them. This will give you better feedback than your non-technical friends or family. Also get someone else to review the slides, some spelling and grammar fiends will get hung up on that and leave negative comments for only that reason. The number of slides you show is also important, you should remove slides that say nothing or serve only to distract the audience. You can have source code and things, but only if they serve the purpose of walking people through a complex process.

Before you begin the slides or anything else you should create a list of things that you want to talk about and devise a timing scheme for each item. This will help you keep track of what you want to talk about and for how long and can act as your notes in the talk itself.

On the day of the talk it is important to be prepared, you need to be sure of where you need to be and when, but also to test the setup before you set up for the talk, plug in a second monitor, see if your equipment can handle things. You should also backup your slides, in multiple formats, in multiple places. Take your laptop along with you, but make sure that your slides will work on other people's laptops. Getting a remote control for the slides is also important for big talks as it prevents you from walking across the stage just to advance the slides, this can be distracting and annoying.

Your best friend during the talk is a simple bottle of water. Talking for 20 minutes straight can give you a sore voice, but talking for longer can be nearly impossible without taking sips of water every now and then.

Where you stand on the stage, even the lighting conditions during the talk, can be important as it can prevent you or your slides from being seen properly. Try to stand in the light and not in front of the slides as you will get a face full of light.

Some venues will provide you with a microphone and it is important that you learn how to use one, where to hold it and even how to attach wireless ones. How you talk also affects how your talk is received so make sure you are aware of speaking too quickly or including words or phrases that non-english speakers might not understand. Don't be afraid of pausing and taking a break for a few seconds, this allows the audience to think about what you are talking about. Recording yourself, in both audio and video format before hand can reveal if you are talking too fast or are doing anything annoying like jumping about or any subconscious ticks.

After every talk (and sometimes in the middle) there will be some questions. Different audiences interact differently and European audiences tend to be a lot quieter than they are in the USA. Make sure, that when someone asks a question that you repeat it (or summarise it) before you answer it. Quite often, people who ask questions won't be heard by the rest of the audience or by any recording equipment so letting everyone know the question before answering it keeps everyone involved. If the audience calls for it (ie, they start talking amongst themselves) then just host the discussion.

Sometimes a single person will continue to ask questions over and over and it may be necessary to tell the person you will see them after. If they persist then get them to talk to you afterwards, and they still persist then simply ignore them and concentrate on other people.

Even if you have lots of questions you need to leave in time for the other speakers to setup as they will be nervous about speaking and need to make sure of their own equipment.

Go to the loo before the session, before they put the microphone on you. Also never attend the session before hand, make sure you get some mental space and prepare yourself for your talk; go over notes and make sure everything works correctly.

When on the stage, don't trip over stuff, and don't stand on gaffer tape, you'll get stuck to the floor. If things do go wrong, don't share that, just pause and get on with things; the audience don't know what is meant to happen so you'll get away with quite a bit.

Lorna finished by talking about why you should speak. Don't speak because you want to be standing there, that shouldn't be the motivation, speak about what you care about. If you can easily fill a session with something you care about then you should talk about it.

Template-Based DOCX, DOC & PDF Generation with Zend Framework
Jonathan Maron

Picture taken by Rob_L.

Jonathan's session was a bit of a sales pitch, but the concept was solid and the results were pretty interesting. He first looked at the traditional approach of PDF document creation in PHP, which tends to be complicated, unreliable or reliant on third party libraries that change over time. The two main methods of PDF generation are to create a HTML document and then convert it into PDF or to programmatically create a PDF document. The main issue with HTML to PDF generation is that PHP can easily create a HTML document, but HTML is a flow document and PDF is a page document so there is a paradigm shift for most developers. Programmatically creating a PDF document is not something that can be easily unit tested (if at all) and is very fiddly, no matter what library is used.

The LiveDocx is a SOAP service that is wrapped in the Zend Framework class Zend_Service_LiveDocx. There is a free service available, but there are also more reliable paid services.

LiveDocx works by using the basic idea behind mail merge. You create a template in Word (or similar) with the needed text fields in place, and then send it over to the service. The merged document is then sent back. Iterating over data is also possible with bookmarks, which are found in Word, but no-one could think of an alternative in OpenOffice.

Images can also be retrieved from the LiveDocx service, useful if you want a thumbnail of the document.

There are lots of formats of templates, outputs and images available, not just the usual Word to PDF with PNG images.

There was a quick discussion about security concerns over the data. Some users in the room were concerned that they were sending over client data to a remote location. This was a valid point as even though all transmissions can be sent over SSL (via HTTPS) the actual documents generated are stored on the remote server for a few seconds until they are garbage collected.

If security is a real concern then the server software can be downloaded and installed locally.

This was an interesting idea and I think I will be recommending the approach to clients in the future, but only if they have PDF generation needs that are very strict, or have money to spend. For some sites it might be useful to charge the users a little bit extra for this service if they opt in for it.

I must also make a note to look at Apache Zeta Components, which apparently does something similar to this.

Clean Code: Stop wasting my time
Volker Dusch

This session was a lot of fun to watch. Volker is obviously a man who has encountered a lot of useless comments in his time as a programmer and wanted to let people know why it annoys him. His talk was full of examples and lots of enthusiasm for the subject matter.

The essential, take home, message from this talk was that good documentation means writing less documentation and that bad code is easy to document. The first example that he gave was of a class with a constructor.

class MyClass {
	
	/**
	 * Constructor
	 */
	pubic function __construct() {
	}
}

The above example is something I have been guilty of in the past (I'm sure of it) but his point was that we don't need to say that this is a constructor as we can already see this. Other programmers might write out full PHPDoc comments here to say what the constructor does, which is even more pointless as anyone reading the code should be aware of what a constructor does. Volker's point in this example was that putting a blank constructor in here is quite pointless in itself, regardless of the quality of comments involved.

Adding all of these comments will scale both in terms of file size and of time taken to read them, rather than read the code itself. Trivial comments, like the one below, are annoying and serve only to waste the time of anyone reading it.

$i++; // incrememt $i by one

Writing comments should only be to describe things that aren't immediately obvious when looking at the code. So one way of writing less comments is to write self-docmenting code. Writing properly named functions and variables makes it easy to see what is going on in a function and what any one variable contains.

One last point about comments is to write out all the words in full. Making unnecessary abbreviations means that your code is not self-documenting as it contains hidden messages. Take the word "user" as an example, this is commonly written out as "usr", which is a throwback to the old days of programming where every character counted. Nowadays, not writing out the name in full doesn't have much of a performance gain (especially in these days of HipHop and Varnish) and so is pointless. Of course, some other words, like "Absolute" are a pain to write out, but what does that matter if you are using a good IDE?

The last part of the talk concentrated on commit messages. These tell us what the user did and why they did it, an important consideration as what they did might not always be the best thing. They might be a new programmer on the project who has changed something that introduces a bug elsewhere and has been done before by another programmer. Writing things like "changed stuff" helps no-one, but writing things like "Added OAuth to Authentication" or even "Fixed bug #12356" are fine as the information is at least available elsewhere.

In Volker's opinion, git made this problem worse. Commit messages are generally smaller and done more often and so tracking down exactly when a problem was introduced and by who can be a real chore.

After this there was a lunch break with free food provided by the venue.

Running a project with github
Lorna Mitchell

Despite what sounded like a playschool being downstairs Lorna was able to shout over it all and talk about her experiences with using github whilst developing Joind.in. The talk wasn't solely about github, but also looked at how to run an open source project through a group of developers all over the world. One thing that Lorna said was that life gets in the way of open source, and I can agree with that.

Version control exists to allow lots of developers to keep pace with each other, to have the most recent version of the code and to look at the history of the project. Normal version control uses a central repository where each user checks out and commits to the same repository, whereas distributed version control allows each user to have their own repository which can be merged with the core repository.

Github allows control of the "distributedness" of the system, but other systems like Sorceforge, bitbucket, codebasehq also exist and are alternatives. Github provides the tools to track what is going on in the project, these are things like who is working on the project, viewing differences and change-sets as well writing documentation.

Joind.in has only recently moved to Github and Lorna told about some of the experiences she has found. Github comes with a built in wiki, which it is very basic, but uses markdown which a lot of developers like using. Apart from the wiki everything else is done outside of Gihub. The bug tracking system on Github is apparently very primitive so all bug tracking for the project is done on JIRA. All communication between project members is done through mailing lists and irc, which is a good way of keeping in touch with lots of different people in lots of different timezones. The irc channel for Joind.in is #joind.in on freenode. Almost all of the communication for the project is done with openness in mind so that anyone can get involved and see what is going on.

Lorna finished by saying that having the tools is different from using them. Having projects on Github provides a great central resource, but Github is a maturing tool; it is not quite finished, but is mature enough to be useful. The technology is not the whole answer though, having the tools and using them are different things. The good thing about Gihub is that a lot of people already use it, so the chances are getting new developers working on a project are quite high.

PHPDox - an alternative to PHPDocumentor
Arne Blankerts

This talk looked at an alternative to PHPDocumentor, which is starting to show it's age and there is plenty of interest in the blogosphere to replace it. The idea behind this PHP based project was that it goes over the source code in the same kind of way, but then creates XML documents that store the information found. The advantage of this is that when the program is run a second time it will only look at the original file if the timestamp differs from that recorded in the XML. This means that the memory usage of the script is quite low (at least after the first run) and that generating the documentation can be done quickly and to whatever format is needed.

Another upshot of this project is that because it produces XML files it can be integrated into other projects including continuous integration environments.

This looks like an interesting project. Although it is clearly still in development I think it will be a nice alternative to PHPdocumentor. The project is available on Github so if you are interested then go along and take a look.

One thing that was demonstrated during the talk was a little linux command that I didn't know existed. This is xmllint and it can be used to reformat XML documents if used in the following way.

xmllint --format file.xml

Evening Social

For the evening social we went to the bar upstairs, where we were given dinner and 3 free drinks vouchers to allow us all to have a drink and talk about the day. I had a great time talking to all sorts of people about all sorts of subjects and the free beer helped a little.

Read Part 2 of this post here.