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!
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?
I saw two talks, both of which were actually really good, which is pretty impressive when you’re going on stage to a rather fed up audience! Kudos to Kevin Prince and Joel Gascoigne for their talks. By this time we did get an announcement about what times the other talks would happen and I snuck out for lunch and cups of tea.
When I popped back (I assume there was a long lunch as I didn’t get there until almost 4 and still caught the last two talks) I saw Adam Griffiths and Phil Sturgeon round off the day with their talks, and I must admit that I think the talk content was spot on, although the speakers were mostly pretty inexperienced, they all had some great thoughts to share and I did get some technical content from it (and a list of new friends, thanks Phil!)
I had been looking forward to the conference social but after hanging about in a strange city on my own waiting for a promised tweet of time and location, I bailed. The people I met at cicon were a nice crowd and I’m sure it would have been fun but I got some other stuff done instead which was also useful.
In summary: nice people, useful content. worst event I think I’ve ever been to (sorry guys).
I tweeted about my disappointment and got a couple of people asking me what my advice is for events organisers. I’ve now done a few technical events and will wrap up my advice into a post (now I’ve outlined it, probably more than one post!) so look out for that over the next few weeks.
(as a total aside but kind of for the record, for an event with 40 ish people, I was disappointed to be the only woman there)
Meetings are the third Monday of the month, so the next one is 16th August where we’ll have Ben Waine speak about Xdebug. If you’re within commute of Leeds, then you should definitely head along there one month, look forward to seeing you!!
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”.
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.
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.
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!
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!)
They do house clearances and were even able to take the old gas bottles out of the garage, I was happy to know they would recycle stuff, and they just brought a truck and loaded it all up themselves, I only stopped working long enough to sign the paperwork and write the cheque :)
The talk is Teach A Man To Fish: Coaching Development Teams and really it’s about how a little investment of time or effort can build your existing team into something better – and how that team can then sustain its improvements and continue to raise its performance and the game of the individual team members. All in all I am pretty excited about this talk – as with most of my conference talks, it started life as a rant in a bar, and I’m now excited to be preparing it for a more formal setting!
The event itself is a must-see for anyone doing PHP or allied technologies that can get there (Manchester is pretty central and pretty cheap – if you’re in the UK, you have no excuses!). It’s a Saturday event, 9th October 2010 and tickets are on sale – the Early Bird prices are still available and we’ve held the prices as low as possible again, we don’t need frills, we just want lots of people to be able to join in! I hope to see quite a few of you there, let me know if you’re coming :)
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
edit: I forgot to say I made a particular new friend, @apeei – you can see us here