Book Review: The Art of Community

This review has been in my drafts folder for 9 months, because I didn’t feel I was doing the book justice. It seems like I never will, so here it is – as it was written then, but hopefully still useful and relevant to someone

I bought this book last year when I was still working at Ibuildings, and my role changed a lot to include events and community representation. Before that I was doing entirely PHP development and it was around this time that I noticed myself saying “has everyone forgotten I’m actually a developer?” a lot! So I quickly decided that I needed a copy of The Art of Community, a book by Jono Bacon published by O’Reilly. Actually, I should thank O’Reilly at this point for publishing the book and even more so for sending Josette and her book stand to conferences – I was able to buy the book and it came with a pep talk :)
Continue reading

Indexes on Tables

Increasingly I find a very binary split between the professionals I come into contact with. One group of people are very database-aware and take the design of their storage quite seriously – with good results. The other group are more concerned with the functionality of their application, and have little regard for how it is stored other than considering it a keeping-place and making useful table and column names.

Too often though, they don’t think about how that data will be retrieved or what the implications are when it gets beyond the thousand records that were used for testing. This is where having an idea of how the data will be retrieved can really help application performance. (note: this article is aimed at users of traditional relational databases, and ignores all other possibilities). This post takes a look at the various index types and when to use them. Continue reading

Printable PDF Handouts from OpenOffice Impress

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.

DSCF2526.JPG

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!

One-Step Symlink Switch

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:

mv -fT next current

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?

Geeks Can Write

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 :)

3 Top Tips for Database Naming

Perhaps this is more of a rant than a post but I do keep running into issues with databases with names that are inconsistent – which makes them really difficult to work with. When designing a database, there are a few points to consider:

Singular and Plural

This goes for table names, and also for the names of join tables. If you call your tables “user” and “group” then you probably want your linking tables to be “user_group”. If you go for plurals (my personal favourite) then be consistent over whether the linking tables are called “user_groups” or “users_groups”.

ID Columns

I’ve seen two main variations on the column names for primary keys, one is to call them all simply “id”, and the other is to name them after their table name such as “user_id” or “group_id”. It doesn’t really matter but my recommendation is for the latter – that way, the user_id column in any other table clearly joins on to the user_id column in the users table, making it easy to read and understand.

Case and Capitalisation

Due to my EXtreme DOuble CApitalitis, I prefer everything to be lower case, but the key is consistency, so that it is easy for developers to get used to the patterns in the database setup and to develop against your schema without having to refer back to it all the time.

Consistency is Key

In general, I like database schemas which are predictable and well-laid-out. Although I have my own preferred conventions, I don’t mind what is used so long as it is predominantly in step with itself – this makes my life as a developer so much easier! What’s your top tip for sane database naming conventions? Leave a comment and let me know!

Migrating Github Contributors to an Organization

Recently, a github project that I contribute to, joind.in, moved from an ordinary github user account over to an organization. Getting contributors moved over is pretty straight forward, I have a fork of the main repo on github at http://github.com/lornajane/joind.in and that updated to show itself as being a fork of the organisation’s repo rather than the original user repo that it had been set up under.

In fact, all I had to do was update my upstream remote on my local repo – I set this up following the excellent github forking instructions when I first forked the repo. All I did then was to check my remotes:

git remote

This showed my remotes with the “upstream” pointing to the old repo. So I copied the URL of the organization repo, removed the old version and added a new upstream:

git remote rm upstream
git remote add upstream git://github.com/joindin/joind.in.git

Everything now behaves as before while handling the new central repo for the project – hopefully this helps others with projects moving from user accounts to organizations (or organisations, as I keep typing, British spellings as always!)

WordCamp

Last weekend I was at WorkCampUK in Manchester – it’s taken me this long to writ the blog post because I needed time to download my photos, however I’ve now done that and I didn’t get anything at all worth publishing, d’oh!

I am a wordpress user and even wrote a plugin once, but I’m an outsider in terms of community so I was looking forward to finding out more about the people involved with wordpress. I expected to meet some friendly folk and I was not disappointed at all – there was a wonderful range of people there, right from people wanting to start a blog to people making a living from wordpress development, and everyone in between. I attended talks on testing the internals of wordpress through to some case studies of sites built using it (thanks @simonwheatley) as well as sessions on plugins, business, and web technologies.

My biggest thankyou of the weekend goes to the Genius @pgibbs who took the time to reply to my tweet-appeal for someone to review my wordpress plugin and spent a good chunk of his afternoon wading through my newbie code – I got loads of great pointers, thanks Paul!

The event ended on a slightly contraversial note with some input from the Automattic people who had come over to attend the event – they’re putting a lot of work into improving the support for the communities running the WordCamps, which should have been good news, but one of the things that will change is that there’s a move away from having WordCamp naming to WordCamp to make space for more events. Suddenly the crowd I thought were so friendly turned a bit hostile, which I found odd. I hope they know that their frankly awesome event will be frankly awesome wherever it is and whatever it is called, I shall be looking out for the details for next year and hoping to see some of the crowd at events between now and then!

edit: I forgot to say I made a particular new friend, @apeei – you can see us here

Working with Branches in Git

Recently I’ve been doing more git than I ever intended to, working with the Joind.in codebase, contributing and managing contributions to that. I quickly realised that I needed to make changes on branches, and since I’m new to git, it took a while to figure some of this out. I’m pretty confident now* so I thought I’d share how I work with branches in git.

Available Branches and The Current Branch

This is the easy bit:

$ git branch
* api
  master
$

The entry with the star next to it is the current branch, so here you can see that I have branches “master” and “api” and I’m currently working on the “api” branch. If you only have one branch it will usually be called “master”.

Creating and Changing Branches

My experience is with Subversion until now, and branching is really different in git (because it actually has branches rather than just copies, this is definitely a feature, but it is a different approach from how I had used them before). So you can switch your working copy around to look at different branches, which threw me a bit to begin with. To change branches, just checkout the one you want:

$ git checkout master
Switched to branch 'master'
$

If you actually wanted a new branch simply name it and ask checkout to create it if it doesn’t exist, by using the -b switch:

$ git checkout -b demo
Switched to a new branch 'demo'
$

So now my branch command shows me this:

$ git branch
  api
* demo
  master
$

Pushing Branches

This is very much an optional step. Many of my branches are private branches – meaning that I branch on the development server, finish the feature at hand, and then merge the changes into my master branch without pushing the branch to anywhere else. To share changes with others though, I sometimes like to push my changes up to github – which is my “origin” remote on my repo. So to push the demo branch we just made, I would simply do:

$git push origin demo
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:lornajane/joind.in.git
 * [new branch]      demo -> demo
$

If you use “git push” on its own, it will push all branches which exist on both the local repo and the origin – but will not push any private branches unless you specify that it should.

Resources

The http://help.github.com site, Github’s own documentation, is actually brilliant and has really helped me to get up to speed with working with my own code and contributions from others.

* The only problem I’ve had with code on github recently is that I merged totally the wrong changeset into the main project root. Which really isn’t the fault of the source control system :)

Text Commands for Skype

I use Skype on linux and the client is quite limited in terms of buttons etc, which doesn’t bother me at all since I don’t use a mouse unless I must (answering skype calls forms a lot of the “must”!). In group chats however, its annoying to have the alerts popping up all the time and I don’t have a menu option to stop them. To disable them I discovered I can just use:

/alertsoff

The / lets skype know its a command – much like IRC! There’s a full list I found on Skype’s support site, very handy :)