Rick Hurst Web Developer in Bristol, UK

Menu

Month: June 2009

7 ways to make me unfollow you on twitter

(this is all a bit tongue in cheek, don’t take too seriously!)

  1. Tweeting a link to anything that begins with “x ways to..”
  2. Posting any bit.ly link without at least a vague explanation of what i’m going to get if I click it.
  3. Posting the same thing more than once (intentionally).
  4. Mentioning how many “followers” you’ve got. Have you actually checked what percentage are spam followers? Have you noticed that twitter acounts with lots of followers attract spam followers exponentially? “Ooh – i’ve got loads of spam in my email today, I must be popular!”
  5. Tweeting everything you hear/ see at a conference i’m not at/ interested in (in reality this is probably temporary, so i’ll likely just move you to the “noisy” group in tweetdeck for a bit)
  6. You are/ become a popular celebrity with a gazillion followers. Unless I feel like i’m having a conversation with you, or you are incredibly funny like @davegorman you are out.
  7. You are really, really noisy (see note about noisy group in tweetdeck)

archived comments

/unfollows @rickhurst

mikek 2009-06-10 11:47:29

@mikek yeah, I know – my 24hr twitter unfollow monitor just went off – the dogs have been released!

Rick 2009-06-10 12:36:49

Nice post, Rick. I agree with most of those – I would also add 8) Auto-tweeting/link-dumping or simply acting like a computer rather than a human… that really bugs me, esp. when sin 2) is committed too.

iamkeir 2009-06-10 12:52:22

Oy! I didn’t want a smiley face?! I wanted the number 8 followed by a closing bracket!

iamkeir 2009-06-10 12:55:18

I would add – people who only tweet on the subject of twitter

Iain 2009-06-10 15:26:20

Oh and people who auto-tweet their blog posts about shiny bathroom porn… uh – hang on..! 😉

Iain 2009-06-10 15:27:50

Deploying and maintaining a website using svn

I use svn (subversion code version control) in a very simple way, but it has become an essential tool for how I build, deploy and manage websites. If you aren’t using some sort of source control, you should be. If you are, but you are using it only as a source code backup, you might be interested to see one of the ways it can be used as an integral part of the workflow for building, deploying and managing website updates. I’m not going to go into svn commands, this is more of an overview of the process.

This is my typical workflow, based on a php/mysql website build, but the process is relevant to most technologies:-

Create a new project in your svn repo
This basically consists of making a new directory in the root of the repo. At this stage, an experienced svn user might suggest you create sub-directories for “trunk” and “branches”, but I don’t bother (yet). I have my svn repo hosted on a web server so it can be accessed over https, by any machine with web access and an svn client installed.

Check it out to your local machine
I always develop on my local machine, I will jump through hoops to make sure I have a portable, standalone development environment for what i’m working on. It’s ok to develop on a remote server, as long as you have your own “sandbox” to work in, where you won’t be treading on anyone’s toes or vice versa. I always set up local hostnames and virtual hosts on my machine, e.g. myproject.macbook.local to allow me to easily work on multiple sites on the same port no. on my laptop. Check the project out and set the working copy folder as the root of your local website. When i’ve subcontracted work in the past, I have insisted that freelancers set up a local development environment and work with svn, even if we aren’t collaborating – there’s no way that i’m going to accept the work as a zip file over email! Working this way means that I can periodically check out the project to my machine to see how they are getting on, rather than having to ask them.

Build your site
As you add files to the site, add and commit them to svn. If you need to rename or delete a file, use svn to do it, to stop it getting out of sync. If you are collaborating with someone else, do an svn update and commit frequently (in that order). This way if you get any conflicts you can resolve them more easily than if you leave it till the end of the day. I find in that scenario it often becomes a “race” to commit stuff frequently, so that the other person is more likely to have to resolve conflicts if any turn up!

Contextual config file
I want to be able to deploy an identical code base to the live (and test) server environment, so I use some “if” statements that look at the host name to selectively load variables such as database config and anything else site/server specific, depending on which environment the site is running on.

Checkout the project on the live/ test server
Firstly, this scenario will only work for you if you have terminal/ ssh/ remote desktop access to your server. If you only have ftp or sftp available, this technique won’t work for you. If that is the case then you may have to resort to uploading the files individually or in bulk – which is a massive pain compared to being able to run an svn checkout/ export/ update on the live server.

There is also some debate about whether deploying or managing the live codebase as an svn working copy is a good idea. I think it is for the following reasons:-

  1. Occasionally you may need to debug something on the live/ test server. e.g. if something behaves differently to your local environment, or some other edge case. In this scenario if you fix the bug on the live server you can commit it back to the repo and do an update on your local copy.
  2. If you are managing user contributed uploads and want to keep them in svn. You can then log in to the server occasionally and add/ commit these back to the repo.
  3. Keeping an eye on things. A while back I spotted that an old wordpress site I was hosting had been hacked. Simply by doing an svn stat on the root of the site, I could see that some files had been modified – that’s an edge case, but it’s a useful tool for getting quick feedback if anything has changed on the live server that you weren’t expecting.

One thing you will want to do if you manage the live site as a working copy is make sure your web server is configured not to serve up the .svn folders, or any other folders not part of the live site.

Database changes
I always keep a mysql dump in the svn repo. This may or may not include data, depending on the size of the database, or the need to keep config data in the database. Once again this should be in a directory that is not served up by your webserver. For a first deployment, I will use a checkout of the mysql on the live server to create and populate the database. Thereafter, I use numbered migration scripts to manage any (structural) changes to the database, such as adding or altering tables. These are added/ commited to svn, then checked out on the live server to run and apply the changes to the live site.

Getting started with svn
If you are reading this and thinking “sounds good, but i’ve never used svn”. A good place to start would be to sign up for a free hosted svn repo with someone like beanstalk, and then try one of the many GUI svn clients. Rapid SVN is a good free one for most platforms, but there are tons out there. It will help to learn the basic commands, and be essential if you only have ssh access on your server. I said I wouldn’t go into commands here, but to put things in perspective, I get by with very few: svn co (checkout a project), svn add (add file(s) to project), svn commit (commit changes to file(s)), svn update (update the working copy with latest changes), svn resolved (mark a conflict as resolved), svn mv (rename a file and tell svn to sync on next commit), svn rm (delete a file and tell svn to sync on next commit) and finally svn revert (go back to the last revision, or a specified revision).

There’s more (but I don’t know it)
I’m fully aware that there are more sophisticated ways to use svn to manage and deploy projects, involving branches, merging, switching, externals and a whole load of other clever stuff that I have yet to become familiar with. However a simple project with checkouts/ commits and updates on local and live server works well for me, and is a good starting point to get stuck in and start to feel comfortable with it. Also, apparently all the cool kids have abandoned svn for git, which works in a similar, but different way, so that might be worth a look too, if you aren’t already familiar with svn.

You’ll never go back
I’ve been working this way for a few years now, but occasionally i’ll do some work for a company that don’t or won’t work use version control, or don’t use it as an integral part of the workflow (i.e. they just use it as a backup). Without version control as an integral part of the workflow, I have often had to resort to pen and paper to remember what files have changed, so I know what to upload, i’ve accidentally overwritten new code with old versions and mysteriously lost days of work when someone else does an update from their non-versioned working copy. The learning curve is worth it, and so is getting your head round how to resolve conflicts (usually the first thing that scares people away from svn).

archived comments

Nice post Rick.. I’m interested to find out a bit more about how you manage which files are served up by your webserver?

That’s the bit I’m a little lost on at the moment.. I use SVN a lot more now thanks to VersionsApp (http://versionsapp.com)

Nik 2009-06-04 10:20:09

I’ve been using SVN for a while now, but you’ve pointed out some uses/applications that should be pretty useful – thanks. I can recommend tortoise svn as a client.

I’m sure there is more that can be done with DB version control, but as you say there is a ton to learn.

Joel Hughes 2009-06-04 10:21:45

@Nik in my virtual host config I have something like the following:-

RedirectMatch 404 /\.svn(/|$)

(There should only be one backslash in front of .svn – need to update the blog software to do a stripslashes!
This stops svn stuff being served up. (I did write some other stuff to help with hiding other directories, but comment formatting messed it up, so removing!

@Joel +1 for tortoise svn on windows. I like the feature that you can commit a directory and it gives you the option to add any unadded files, and select which other files should/ shouldn’t be committed at the same time. A nice time saver

Rick 2009-06-04 10:58:16

Weighing in on the whole “working copy” debate (which you probably don’t want to get into!)… I really have never heard even a slightly valid argument for using an export rather than a checkout.

One thing I would say, though, is as well as denying access to .svn (a must), also make sure that your SVN credentials (passwords, and so forth) are NOT stored on the webserver. When you do an update/checkout, your SVN username and password will probably be stored (by default) in ~/.subversion/auth.

Instead, you can set the “store-passwords = no” and “store-auth-creds = no” in your ~/.subversion/config file. This is a bit of a chore as you have to type the password each time you update.

The alternative is to make sure the SVN user is read-only, but even that gives a hacker access to historical (and future) release info.

Tom 2009-06-04 11:10:11

Good post Rick. I’m going to point my SVN shy housemate at it later.

Not wanting to sound condescending, as I sometimes run my own personal projects as you describe i.e. just using the trunk, but when working on bigger, more complicated sites you should really considering creating a tag (just a svn cp of trunk) and deploying that so you can rollback in case of error.

Creating a SQL patch to the tag and one from the tag (i.e. one to add the new column and one to remove it helps when deploying sites that need to say up)

Andy Gale 2009-06-08 13:39:04

@Andy – yep absolutely – I just haven’t got round to trying it out so that I feel comfortable with it. Do you have a way of running sql patches automatically?

Rick 2009-06-08 13:55:35

Not yet… sometimes it counts which order the patches are run… but it would be fairly easy to automate it if you worked out a naming convention. That’s my plan for our next major project as it would help to auto-update each development environments as well the live site.

Andy Gale 2009-06-10 11:44:17