stephenminded

I originally wrote this on my employer’s blog, shift+control. I’m cross posting here because I don’t blog enough

---

It’s pretty common to tweak your website assets from time to time. This may be an update to a stylesheet, some javascript, a logo or any other file. When doing this, you may notice that you don’t see the changes right away. You might have to refresh the page a few times or clear your browser cache in order to get the new version of the file. There are a few reasons this can happen:

1. When your browser requests a file, Apache may report that the file hasn’t changed. You can see this with a tool like firebug, any files that come back with a “304 Not Modified” header will not be re-downloaded by your browser.

2. When you first requested the file sometime in the past, Apache may have sent an expires header with the file. This means that until a specified date, your browser will never re-download the file. Unlike the #1 above, it doesn’t even ask Apache if it should re-download the file.

Note: I’m sure I missed a few ways a file can find it’s way into the cache, but that’s not the point of this post.

All this caching is great for the performance of your website, but it sucks when you actually want your users to download the new version of the file. Putting up “our site has changed, please clear your browser cache” is obviously out of the question. So, what can we do?

When your browser encounters a file that it hasn’t seen before it will always go ask Apache for the file. So, one option is to add a version number to the filename and update your source to point at the new file. This works, but adds a maintenance overhead because you have to make sure you maintain the version number of the file and deploy it with the proper filename. So, style.css could become style-20090109.css.

The problem with the above is that you have to maintain the file version in two places, once in your source html and again when you update the css file. We can get around this using htaccess by pointing all reguests to style*.css to style.css. So, when a request is made for style-20090109.css you get the updated contents of style.css and since the filename is unique you get around the cache issues. Yes, you still have to maintain the reference to the stylesheet in your html source, but you don’t have to worry about how to name the file. Anyway, here’s how you go about doing this.

Create a .htaccess file in the directory where your style.css file lives. In it put the following:

RewriteEngine On
RewriteRule ^style(.*).css$ style.css [QSA,L]

Now, when you request style-20090109.css or style-monkey.css you’ll always get the contents of style.css. There are other solutions, but I find that this works best for us. Hope someone will find it useful.

I originally wrote this on my employer’s blog, shift+control. I’m cross posting here because I don’t blog enough

---

Like a lot of developers, we use SVN on a day to day basis. I can’t imagine working without it. We’ve been using it for over a year now. Svnlook on revision 1 give me this:

[steve@76design ~]$ svnlook info /svn -r 1
steve
2007-08-23 18:23:03 -0400 (Thu, 23 Aug 2007)
23
Created folder remotely

And svnlook youngest gives me this:

[steve@76design ~]$ svnlook youngest /svn
6567

In a year we have over 6500 commits and many projects contained in that (now not so little) repository. Given that there are so many commits going on, we thought it would be useful to have a feed of commits happening in real time. If we had that, we could get a good feel for the activity in the office over the day. One obvious choice for a feed is RSS, and we have that too, but we thought it could be fun to have a twitter stream of our commits.

I did some quick googling and came across a Google code project called twitvn. Unfortunately, due to hosting restrictions, I was unable to get it installed on our svn server. So, like any developer would do, I wrote my own

SVN provides you with some interesting ways to interact with it pre and post commit. I wanted to hook in on post-commit and fire off a twitter message with some details about the commit. Turns out it’s fairly simple to do.

After every commit, if a script is available at [svn path]/hooks/post-commit, SVN will run that script. Two arguments are provided, the svn path and the revision number of the commit. Using these two pieces of info, you can then pull out whatever details you want about that particular commit and choose to do what you want with it. Knowing that, here is the approach I took:

1. Get the particulars about the commit using ’svnlook info’
2. Get the modified files using ’svnlook changed’
3. Determine the author and the project that was being committed
4. Create a twitter message and send it using Curl

I decided to write it using PHP, mostly because it’s what I know and I wanted to get it done quickly. In order to determine the project, I assumed that the top level folder of the first modified file is the project (this will depend on your repository layout so your mileage may vary here).

The final script is called tweeter.php, grab it here.

In order to run it, drop your twitter account details into CMD_CURL_TWITTER and add this line to your post-commit file:

[path-to-php5-cli] [path-to-tweeter.php] “${REPOS}” “${REV}”

Let me know if you get some use out of it!