PHP London Conference: In Review
Friday, March 5. 2010
I'm really late with this post, but I wanted to write about the PHP London Conference which was held in London last Friday. The event was in a great venue and had hoards of people - this was my fourth year in attendance!! They do, however, have the longest twitter tag in history #phpuk2010!
This year I had the privilege of speaking at this event, although I was concerned that I had to stay coherent and alert right through to the graveyard slot at 4:30pm (conference organisers take note: I really am much sparklier in the mornings!). I kept myself awake by attending what I affectionately refer to as the "Ibuildings track" - with 4 speakers at the event, it did feel like a bit of an invasion by myself and my colleagues. In our defence I can only say that we are a pretty big local PHP employer and, as a developer, I'm happy to be working for someone who sends all their developers to these events, and even happier to be in the company of those other excellent speakers as colleagues!
My talk was entitled "Best Practices in Web Service Design" although perhaps "Things I Wish Web Service Creators Would Consider Before Writing Unclear and Unstable Useless And Frustrating Services" would have been a better title! I talked about web services in general, a bit about HTTP and the various service types, and also gave some general tips and tricks for writing good, stable services. In a bit of a break with geeky tradition, I then talked about services as a whole package, and how to deliver and document them in a way that helps users help themselves. If you are interested the slides are here:
http://www.slideshare.net/lornajane/best-practices-in-web-service-design
The experience was overall very positive for me, I haven't spoken at this conference before and I was very pleased to be included. My talk went quite smoothly, with my nerves nicely hidden away (I've had issues with this lately), and I also avoided falling over either the curtain or the piece of screen that was carefully placed to trip unwary speakers! I'd like to thank everyone who came and asked questions afterwards, and all those who saw my talk and left comments for me on my joind.in talk page - it all helps me to do better next time, thanks and I'll see you all next year!
This year I had the privilege of speaking at this event, although I was concerned that I had to stay coherent and alert right through to the graveyard slot at 4:30pm (conference organisers take note: I really am much sparklier in the mornings!). I kept myself awake by attending what I affectionately refer to as the "Ibuildings track" - with 4 speakers at the event, it did feel like a bit of an invasion by myself and my colleagues. In our defence I can only say that we are a pretty big local PHP employer and, as a developer, I'm happy to be working for someone who sends all their developers to these events, and even happier to be in the company of those other excellent speakers as colleagues!
My talk was entitled "Best Practices in Web Service Design" although perhaps "Things I Wish Web Service Creators Would Consider Before Writing Unclear and Unstable Useless And Frustrating Services" would have been a better title! I talked about web services in general, a bit about HTTP and the various service types, and also gave some general tips and tricks for writing good, stable services. In a bit of a break with geeky tradition, I then talked about services as a whole package, and how to deliver and document them in a way that helps users help themselves. If you are interested the slides are here:
http://www.slideshare.net/lornajane/best-practices-in-web-service-design
The experience was overall very positive for me, I haven't spoken at this conference before and I was very pleased to be included. My talk went quite smoothly, with my nerves nicely hidden away (I've had issues with this lately), and I also avoided falling over either the curtain or the piece of screen that was carefully placed to trip unwary speakers! I'd like to thank everyone who came and asked questions afterwards, and all those who saw my talk and left comments for me on my joind.in talk page - it all helps me to do better next time, thanks and I'll see you all next year!
Simple Database Patching Strategy
Monday, March 1. 2010
One problem that seems to need solving too often is how to keep databases in sync across different platforms, different developers working on a project, and deploying database changes along with code changes. There are lots of ways of approaching this, none of them are really excellent however and personally I tend to err on the side of simple being better. Fewer dependencies means a solution more likely to work on every platform (and no additional complications for the live platform). Usually this means patch files of some kind - here's an outline of my usual approach. For the impatient:
Naming is completely changeable but mine looks something like this:
CREATE TABLE `meta_data` (entry varchar(255) PRIMARY KEY, value varchar(255));
INSERT INTO `meta_data` SET entry="version", value="0";
This new row will hold information about what patch version the database is up to. Every patch that is created will update this number so that it is possible to tell which patches have and have not been applied.
Firstly create a database directory for all these files to live in. This should be outside your web root but inside your source control project.
Take your database and dump just the structure of the tables using the --no-data switch to mysqldump like this:
mysqldump -u <username> -p <database> --no-data > create.sql
You will also want to populate tables which hold things like lookup values, country lists, that sort of thing, so that these are set up. People starting to develop with this project, or if the application needs to be deployed to somewhere new, can use this file as a starting point.
This is where the discipline element comes in - no direct edits on the database are allowed! Instead, write the SQL for your change and place it in the patch file, then run it against the database. If that sounds too much like hard work then copy/paste the SQL you use to make changes, or the SQL generated by whatever SQL tool you use, and place it in the file.
Every file must have its own incrementing version number in its file name, e.g. patch-1.sql, patch-2.sql etc. Within the file the version must also be updated to match, with a statement like:
UPDATE `meta_data` SET value="1" WHERE entry = "version";
Here are a few pointers on getting the most out of something like this:
I'm sure there are many improvements and variations on this theme of simple database patching, leave a comment and let me know what works for you and why!
- add a table for meta data to the database, set a database version parameter to 0
- export structure and any essential data (lookup tables, etc) into an sql file
- for any changes, create a numbered patch file e.g. patch-1.sql, including the change and an update statement to bring the version meta data to match the patch file
- store all of the above in source control
- for bonus points, create another sql file with some nice sample data
Give the Database Some Version Awareness
Naming is completely changeable but mine looks something like this:
CREATE TABLE `meta_data` (entry varchar(255) PRIMARY KEY, value varchar(255));
INSERT INTO `meta_data` SET entry="version", value="0";
This new row will hold information about what patch version the database is up to. Every patch that is created will update this number so that it is possible to tell which patches have and have not been applied.
Create an Initial Data Structure
Firstly create a database directory for all these files to live in. This should be outside your web root but inside your source control project.
Take your database and dump just the structure of the tables using the --no-data switch to mysqldump like this:
mysqldump -u <username> -p <database> --no-data > create.sql
You will also want to populate tables which hold things like lookup values, country lists, that sort of thing, so that these are set up. People starting to develop with this project, or if the application needs to be deployed to somewhere new, can use this file as a starting point.
Create Patches for Changes
This is where the discipline element comes in - no direct edits on the database are allowed! Instead, write the SQL for your change and place it in the patch file, then run it against the database. If that sounds too much like hard work then copy/paste the SQL you use to make changes, or the SQL generated by whatever SQL tool you use, and place it in the file.
Every file must have its own incrementing version number in its file name, e.g. patch-1.sql, patch-2.sql etc. Within the file the version must also be updated to match, with a statement like:
UPDATE `meta_data` SET value="1" WHERE entry = "version";
Recommended Practice
Here are a few pointers on getting the most out of something like this:
- Under no circumstances is it acceptable to edit a patch file that has been committed to source control. Someone might have run it already and you'll confuse everyone completely.
- Having matching undo scripts alongside the patches can be really useful in case a change gets deployed and needs to be undone.
- Make a script to look up the database settings in the config file of your application, query the database for what version it is at, and run any outstanding scripts. This makes life much easier especially if you have large numbers of scripts (I've seen the patch numbers hit the hundreds)
- A possible adaptation of this approach is to create patch files for use for updating a database, but to also update the install.sql file to make it correct at any point in time, this means a much shorter and easier setup time for new deployements/developers. The version awareness works in the same way regardless
- Creating a sample database which creates a few records in each table can really help for development purposes - its quicker for people to get set up and attain a working system that they can make progress with.
I'm sure there are many improvements and variations on this theme of simple database patching, leave a comment and let me know what works for you and why!
Supermondays: Recap
Tuesday, February 23. 2010
Last night I travelled to the northeast of England to speak to a thriving technical community up there called Supermondays. They contacted me some time ago asking if I could get there to speak one Monday, and last night was the night! It was a very civilised gathering, with sandwiches and cups of tea, and using a lecture theatre at the university for space. As a speaker the best thing about this is that its a space designed for addressing people in, unlike most user groups (and indeed conferences!) where two steps away from the lectern sees you standing in the dark, falling off the stage, or getting projected on to. Last night was a different story with lots of space to wander, slides projected well above me on the wall so everyone could see clearly, and relatively good acoustics despite no amplification.
My talk was entitled "PHP and Web Services: Perfect Partners" - the slides are on slideshare if you want to take a look. There was also a talk about android development by Alex Reid, including a live coding demo which went surprisingly well! Judging by the various events that were plugged and discussed on the night, at the main event and in the pub afterwards, this is a diverse and vibrant technical community - so if you are in the northeast, get along to Supermondays!
My talk was entitled "PHP and Web Services: Perfect Partners" - the slides are on slideshare if you want to take a look. There was also a talk about android development by Alex Reid, including a live coding demo which went surprisingly well! Judging by the various events that were plugged and discussed on the night, at the main event and in the pub afterwards, this is a diverse and vibrant technical community - so if you are in the northeast, get along to Supermondays!
Open Office Presenter Console
Friday, February 19. 2010
I've been having issues with the presenter console on both my ubuntu machines since upgrading to Karmic (9.10). One is a Thinkpad T400 running kubuntu and the other is an aspireone netbook running ubuntu netbook remix. Neither wanted had a working installation after upgrade and I couldn't get the plugin installed using the open office plugin manager.
I discovered that this plugin is now available through apitude - simply install the package openoffice.org-presenter-console and it should all work splendidly! I use the presenter console when I am speaking (which is quite often) to show the time and the upcoming slide, its a great tool.
I discovered that this plugin is now available through apitude - simply install the package openoffice.org-presenter-console and it should all work splendidly! I use the presenter console when I am speaking (which is quite often) to show the time and the upcoming slide, its a great tool.
An iPhone App for Joind.in
Monday, February 15. 2010
Recently I've been doing some bits and pieces with the open sourced event feedback site joind.in, including some work on its API to facilitate development of an iphone app. As a conference attendee, speaker and organiser, I use this site a lot for the various events that I am involved with and its a great asset.
My boyfriend Kevin was thinking of developing an iphone app, mostly to find out more about the technology, and I suggested he take a look at the API for joind.in and consider building something on that. The joind.in project belongs to enygma, a.k.a. Chris Cornutt from phpdeveloper.org and he has the code available on github - so we grabbed it. The API wasn't previously used by much so we were able to tidy it up a bit and then consume it from the iphone to suit our needs. Chris has accepted my alterations to his existing project with grace - even when I've totally broken the live site with them!!
The joind.in site is a classic MVC setup and the API already existed within the application. It is implemented with a separate set of controllers for the various actions supported by the API, which all inherit from a controller which handles the output formats etc for the XML and JSON responses. It isn't the world's best API but its perfectly sufficient for the task at hand - I intend to write some examples for using it but until then you can read this post from Derick about how he used the joind.in API to pull in comments on his talks onto his own site.
The app itself has the core functionality of joind.in that an attendee would want in his pocket at an event. The events and their details are there, along with the talks at each event. Attendees can leave comments on the various talks and socials, and these can be browsed in the app as well. To give you a little taste of the app, here are some screenshots:

If you have an iphone or ipod touch and you're attending an event any time soon, then download the app - its under "utilities" in the app store. Comments, suggestions, bug reports and feature requests are all gratefully received (no promises about fixing/implementing them but we'll do our best!). Our app went from submission to approved in 3 days which is very fast - thanks apple!
My boyfriend Kevin was thinking of developing an iphone app, mostly to find out more about the technology, and I suggested he take a look at the API for joind.in and consider building something on that. The joind.in project belongs to enygma, a.k.a. Chris Cornutt from phpdeveloper.org and he has the code available on github - so we grabbed it. The API wasn't previously used by much so we were able to tidy it up a bit and then consume it from the iphone to suit our needs. Chris has accepted my alterations to his existing project with grace - even when I've totally broken the live site with them!!
The joind.in site is a classic MVC setup and the API already existed within the application. It is implemented with a separate set of controllers for the various actions supported by the API, which all inherit from a controller which handles the output formats etc for the XML and JSON responses. It isn't the world's best API but its perfectly sufficient for the task at hand - I intend to write some examples for using it but until then you can read this post from Derick about how he used the joind.in API to pull in comments on his talks onto his own site.
The app itself has the core functionality of joind.in that an attendee would want in his pocket at an event. The events and their details are there, along with the talks at each event. Attendees can leave comments on the various talks and socials, and these can be browsed in the app as well. To give you a little taste of the app, here are some screenshots:

If you have an iphone or ipod touch and you're attending an event any time soon, then download the app - its under "utilities" in the app store. Comments, suggestions, bug reports and feature requests are all gratefully received (no promises about fixing/implementing them but we'll do our best!). Our app went from submission to approved in 3 days which is very fast - thanks apple!
PHP and JSON
Wednesday, February 10. 2010
This is a quick outline on working with JSON from PHP, which is actually pretty simple to do. This post has some examples on how to do it and what the results should look like. JSON stands for JavaScript Object Notation, and is widely used in many languages (not just JavaScript) for serialisation. It is particularly popular for use in web services.
Imagine we have a multidimensional array in PHP that looks something like this:
$menu['starter'] = array( "prawn cocktail",
"soup of the day");
$menu['main course'] = array( "roast chicken",
"fish 'n' chips",
"macaroni cheese");
$menu['pudding'] = array( "cheesecake",
"treacle sponge");
echo json_encode($menu);
The output of this script looks like this:
{"starter":["prawn cocktail","soup of the day"],"main course":["roast chicken","fish 'n' chips","macaroni cheese"],"pudding":["cheesecake","treacle sponge"]}
This is pretty typical of a JSON output string - you can see the curly brackets to enclose the whole thing, then some square brackets to show the nesting levels within the key/value formats. JSON is an ideal format for many applications because it is easy to understand and debug, its quite concise, and many languages have built-in support just like PHP.
Once we've serialised the string, we might want to unserialise it again - and the PHP code for that is every bit as simple as the previous example, except that we use the function json_decode() instead of json_encode(). I've set the output of the previous script as the input to this one:
$json = '{"starter":["prawn cocktail","soup of the day"],"main course":["roast chicken","fish \'n\' chips","macaroni cheese"],"pudding":["cheesecake","treacle sponge"]}';
print_r(json_decode($json));
This decodes the string and then dumps it using print_r() - the output of my script looked like this:
Note that the data isn't identical to how it looked when it went in - JSON can't distinguish between arrays and objects, and doesn't retain information about data types. So its perfect for a web service where we just want to convey the information, but may be too loose for other applications.
The examples here were taken from a talk I give about consuming web services - you can see all the slides on slideshare. If you have any additions or alternatives, leave a comment!
Writing JSON From PHP
Imagine we have a multidimensional array in PHP that looks something like this:
$menu['starter'] = array( "prawn cocktail",
"soup of the day");
$menu['main course'] = array( "roast chicken",
"fish 'n' chips",
"macaroni cheese");
$menu['pudding'] = array( "cheesecake",
"treacle sponge");
echo json_encode($menu);
The output of this script looks like this:
{"starter":["prawn cocktail","soup of the day"],"main course":["roast chicken","fish 'n' chips","macaroni cheese"],"pudding":["cheesecake","treacle sponge"]}
This is pretty typical of a JSON output string - you can see the curly brackets to enclose the whole thing, then some square brackets to show the nesting levels within the key/value formats. JSON is an ideal format for many applications because it is easy to understand and debug, its quite concise, and many languages have built-in support just like PHP.
Reading JSON Data From PHP
Once we've serialised the string, we might want to unserialise it again - and the PHP code for that is every bit as simple as the previous example, except that we use the function json_decode() instead of json_encode(). I've set the output of the previous script as the input to this one:
$json = '{"starter":["prawn cocktail","soup of the day"],"main course":["roast chicken","fish \'n\' chips","macaroni cheese"],"pudding":["cheesecake","treacle sponge"]}';
print_r(json_decode($json));
This decodes the string and then dumps it using print_r() - the output of my script looked like this:
stdClass Object
(
[starter] => Array
(
[0] => prawn cocktail
[1] => soup of the day
)
[main course] => Array
(
[0] => roast chicken
[1] => fish 'n' chips
[2] => macaroni cheese
)
[pudding] => Array
(
[0] => cheesecake
[1] => treacle sponge
)
)
Note that the data isn't identical to how it looked when it went in - JSON can't distinguish between arrays and objects, and doesn't retain information about data types. So its perfect for a web service where we just want to convey the information, but may be too loose for other applications.
The examples here were taken from a talk I give about consuming web services - you can see all the slides on slideshare. If you have any additions or alternatives, leave a comment!
(Page 1 of 89, totaling 533 entries)
» next page



Comments