While I had my SOPA protest page up, I realized that a minimalistic color scheme actually looked pretty decent. Accordingly, and in recognition of the fact that SOPA and PIPA are still looming threats, I'm changing my whole site to a black and white color scheme until both bills are defeated. I might even keep the design after that, just for the fun of it.

If you're a repeat visitor, I suggest doing a hard refresh or clearing your browser cache entirely, so that you can see the updated stylesheets.

Last night I noticed that I've posted something on this site every day for 5 days in a row. In comparison to my usual pattern of posting maybe once every two or three weeks, this feels pretty good. It's nice to see my site looking "dynamic" or whatever.

As it happens, this streak coincides with the start of National Novel Writing Month, NaNoWriMo. The concept of NaNoWriMo is that you force yourself to write an entire novel between November 1 and November 30. (By the way, NaNoWriMo people: the idea is great, but you seriously picked the worst abbreviation I have ever seen.) Of course, I couldn't hope to write a novel in a month, but writing is writing, so I'm setting myself a goal of averaging one blog post per day for the entire month of November. National Blog Writing Month, I suppose. If nothing else, it'll be a good excuse to finish up some of the posts I've been meaning to make for ages. Let's see how this goes!

Just a quick update as to why this site has been messed up the past few days: I had some problems with Apache crashing after an update late last week, and since I'd been thinking about moving from Slicehost to Linode anyway, I decided to use this as an excuse to make that move. Of course, that meant I had to set up a new server almost from scratch and transfer everything over. I haven't quite transferred everything yet, but the important stuff should be running.

This site hasn't been very active recently, but I figured I could revitalize it a bit with a story of why I haven't been making blog posts: for one thing, I'm preparing to spend a week and a half at the CTEQ summer school in Madison. I'm also involved in preparing a paper for publication (wooo getting published), which has involved a fair amount of proofreading and checking references.

There have been a couple of neat Mythbusters episodes recently which I would have loved to write about, including the one about surviving an underwater explosion. Unfortunately I don't know enough about fluid dynamics and shockwave physics to say anything useful about it. (That may need to change) I'm also working on something about the older episode where they tested alternative solutions to a flat tire; there's some interesting physics there, but the details haven't been coming together as easily as I would have hoped.

And to top it off, I've been investing time in some other hobbies... which I should probably start writing about. So maybe that will provide some material to get this blog going again.

In the meantime, here's a neat July 4th physics analysis on Dot Physics to amuse you.

jQuery, the Javascript framework, is like the ecstasy of web development: everybody's doin' it these days. (Well actually ecstasy was big in the 80's, but a few months is like 25 in internet years. Just go with it.) When no two browsers seem to implement Javascript the same way, a framework is practically a necessity. But for a long time I held out and insisted on writing my own Javascript.

Why? Well, for starters, most of this site didn't even use much Javascript, and the parts that did were only really important to one person: me. I used Konqueror as my main web browser, and its admittedly crappy JS support didn't handle frameworks like jQuery correctly, so if I wanted the pages to work for myself, I had to write my own scripts. Besides, I wanted to support W3C standards. A simple way to do that is just to write code that conforms to the standard — at least, as well as anyone can tell what it means — so if you came to my site with a non-standard-compliant browser (*cough* IE *cough*) and it didn't work, tough. Maybe it'd convince someone to use a better browser.

But over the past year and a half or so, all of those reasons have pretty much evaporated. I rewrote TextWriter with a new AJAX interface, and within several days, I already had someone pointing out a pretty significant (though not quite critical) bug when using it in Internet Explorer. Also, with the advent of KHTML 4, Konqueror's support of Javascript frameworks improved by leaps and bounds. Stack Overflow is actually usable in Konqueror now.

And then there's the standards issue. Although Microsoft still is a bit hardheaded when it comes to web standards, they do seem to have realized that they can't completely ignore what the rest of the internet is doing. So I think we can expect better standards compliance from IE in the future.

There was one more thing that bothered me about the possibility of switching to jQuery. The core jQuery script alone is 24 KB, minified and compressed. A lot of people seem to think that's nothing, but I've always been a fan of clean HTML, and so my pages are pretty small, file-size-wise. The jQuery script, and remember this is with every unnecessary character stripped out, is literally almost 4 times as large as the HTML page for TextWriter (7 KB for the latter). It seems silly to add a 24 KB script to a 7 KB page.

However, after some thought I don't think that's such a big deal, mainly because of browser caching. One advantage of jQuery's popularity is that it's everywhere. It lives all over the internet, and it's available from several major content delivery networks. Probably 99% of anyone who uses a Javascript-capable browser has the script cached, and by using one of those CDNs instead of hosting the script myself, I can make use of those cached copies. So using jQuery won't actually add much of any additional download time to the page.

What about the effect on page processing time? Sure, it takes a while to parse and execute all those 24 KB of code. I guess that could still be an issue, but I doubt that jQuery would have gotten so popular if it significantly slowed down page processing for a lot of people. This is one effect to keep an eye on, and I may revert to my custom scripts if it becomes serious.

The bottom line? Once I started trying to fix the aforementioned bug, I realized the one eternal truth of web page scripting: writing functional scripts for Internet Explorer will, in fact, drive you insane. Better let someone else worry about that.

Since the beginning of version control, people have been using VCSs to manage websites. It works pretty well, because the process of web development is similar to the process of programming. Heck, with the advent of dynamic websites these days, often half of web development is programming. But web developers have one peculiar requirement that most other programmers do not: they have to maintain one particular copy of the site which gets continuously updated, but not always with the latest changes.

Typically, when you set up a version control system to handle your website, it works like this: you have a working copy on your computer, a repository on your server, and another "live" working copy on the web server which is the actual website content. Whenever you want to update the website, you push (or commit) changes from your computer to the repository, and have a hook script set up that makes the VCS update the live working copy with the latest changes. That's the approach I found described in a couple of websites: http://danielmiessler.com/blog/using-git-to-maintain-your-website and http://toroid.org/ams/git-website-howto.

But once your site turns into a moderately complicated system, this doesn't work so well. Professional websites that need to be reliably available usually have a staging server where the webmaster can test out a new version before changing the live site. And there may be a team of developers who all contribute to creating the website — or even if there's only one webmaster, he or she might be using multiple computers.

For instance, I usually work on this website on my desktop at home, but I also have a couple of laptops that I can use to edit the site when I'm traveling. When I want to put up a new version, I first collect all the changes on my desktop and test them there, then copy them to a staging server (actually a virtual machine that runs on my home computer), which I've set up as a copy of my real web server so that I can test changes to the site before they go live. If they work there, I copy them to the web server itself. As you might guess, it's not exactly straightforward to automate that process with git.

It is possible, though. The key to making this work is that git can push changes anywhere, not just to a central repository. So I could configure git on my desktop to update the staging server, and configure it on the staging server to update the live server.

But wait, it gets better! Each clone of a git repository can be set up to automatically track the contents of other clones by adding them as remotes. So I can add the staging server and the live web server as remotes in my desktop repository, and I get to control the entire process from my desktop! Since the desktop repository keeps track of what the most current revision is on both the staging and live servers, I can tell it to copy "staging" to "live" without ever having to log in to the staging server.

Preparation

Without further ado, here's how to set it up. Say you have a staging server at dev.example.com and a live web server at www.example.com. On both servers, you want the directory /srv/www to contain your website. (The git metadata directory would then be /srv/www/.git) Let's also say that you have a server git.example.com which contains your central git repositories, and the one for your website is in /srv/git/website.git. You might set this up with gitosis, for example.

You should be able to connect to each of these servers over SSH, preferably using public-key authentication (so that you don't have to type a password).

The first step is to make sure that you have a clone of the website repository on each computer: one on your development computer (like my desktop), one on your staging server, and one on your live server. Optionally you can have a bare clone on your git server. The way you set up these clones depends on your current situation, and there's no way I can cover all the possibilities here. Just as an example, if you made the transition from Subversion to git, you might have a bare git repository on the git server git.example.com, with a clone of it on your home computer, where you do your work. In that case, to get started, you'd just clone the bare repository to your staging server and your web server (note that you may have to temporarily take your main site offline while you do this).

home$ ssh dev.example.com
dev$ git clone ssh://git.example.com/srv/git/website.git /srv/www
dev$ exit
home$ ssh www.example.com
www$ mv /srv/www /srv/www-backup
www$ git clone ssh://git.example.com/srv/git/website.git /srv/www
www$ exit

(In each line the part before the $ tells you which computer to run the command on, and the part after it is the actual command to run — fairly standard.)

The website can go back up now. If you made a backup copy of your web directory using the mv command above, don't forget to come back and delete it later, once you're convinced that everything is working.

The Procedure

Anyway, let's say that however you did it, you've gotten those three clones of the same git repository set up. Back on your home computer, you first need to configure git to track the staging server and live server as remotes. It's quickest to do this by editing the .git/config file with your favorite text editor. Add the following contents at the bottom of the file:

[remote "staging"]
        url = ssh://dev.example.com/srv/www
        fetch = +refs/heads/master:refs/remotes/staging/master
        pushurl = ssh://dev.example.com/srv/www
        push = refs/heads/master:refs/heads/master
[remote "livewww"]
        url = ssh://www.example.com/srv/www
        fetch = +refs/heads/master:refs/remotes/livewww/master
        pushurl = ssh://www.example.com/srv/www
        push = refs/remotes/staging/master:refs/heads/master

Now stop and do not run any git commands (!) until I explain what's going on. These lines add the staging and live servers as remotes to the home git repository. You'll recognize the URLs of the two servers, of course. The line fetch = +refs/heads/master:refs/remotes/staging/master tells git that when it pulls changes from the staging server, it should copy them from the remote branch master to the local branch master, but leave other branches alone.

The interesting part is the push configuration. For the staging remote, it's refs/heads/master:refs/heads/master, which tells git to copy commits directly from the master branch on your home computer to the master branch on the staging server. The absence of the leading + tells git to perform fast-forward updates only; in other words, if there are any commits on the staging server which aren't in your home repository, the push will fail (evidently somebody's been playing around with the staging server behind your back). And for the live remote, refs/remotes/staging/master:refs/heads/master tells git to copy from the master branch on the staging remote to the master branch on the live server. Essentially, this takes the commits from your home computer's record of what the staging server contains, and sends them off to the actual live server. Again, the + is absent, which means that if there's anything on the live server that wasn't already on the staging server, git will fail. This is a good thing because you want every piece of your site to go through the staging server first.

Anyway, now back to running git commands. The way we've configured the home repository, pushes to either server go into the master branch, which is the same one that's going to be checked out. Git normally complains about this. You can configure it not to do this by setting the configuration property receive.denycurrentbranch to ignore:

home$ ssh dev.example.com
dev$ cd /srv/www
dev$ git config receive.denycurrentbranch ignore

Git still won't automatically update the checked-out copy of the files, though. When it receives a push, it only changes its repository, in the .git directory. To actually update the files checked out on the filesystem, we need to create a hook script.

dev$ echo 'git --work-tree=.. checkout -f' >>.git/hooks/post-receive
dev$ chmod a+x .git/hooks/post-receive

Finally, delete the origin remote, because you don't want this repository to be able to automatically receive changes from anywhere except your home computer.

dev$ git remote rm origin
dev$ exit

You need to do the same thing for the live web server:

home$ ssh www.example.com
www$ cd /srv/www
www$ git config receive.denycurrentbranch ignore
www$ echo 'git --work-tree=.. checkout -f' >>.git/hooks/post-receive
www$ chmod a+x .git/hooks/post-receive
www$ git remote rm origin
www$ exit

Now try pushing changes for the first time:

home$ git push staging
Everything up-to-date
home$ git push livewww
Everything up-to-date

If you get an error instead of the message about everything being up to date, something's wrong with your configuration. Otherwise, you're all set! Try making a change to the site and pushing it out.

Every time you want to update the staging server with the latest changes, you run

home$ git push staging

and once you've tested those changes on the staging server and want to push them out to the live web server, run

home$ git push livewww

Variations

Depending on your needs, you might want to adjust this procedure a bit. Let's say you only want to push changes to the staging server from the bare repository on git.example.com, not from your home computer directly. You can do this by altering the remote.staging.push configuration option to read refs/remotes/origin/master:refs/heads/master instead of refs/heads/master:refs/heads/master. This might be useful if you have multiple developers who need to be able to push to the staging server.

Another common thing to want to do is reload the server each time the site is changed. You can do this in the hook script, just add the command to reload the server. For Apache, you can run

dev$ echo 'git --work-tree=.. checkout -f' >>.git/hooks/post-receive
dev$ echo 'sudo /etc/init.d/apache2 reload' >>.git/hooks/post-receive

after the echo 'git --work-tree=.. checkout... line. Or open .git/hooks/post-receive yourself and add the line with your favorite text editor. You'll need to make sure that sudo can run the reload command without a password, because you won't be able to enter one. (Although that could be arranged if you really needed it)

It may be the case that the server only needs to be reloaded when certain files change; for example, I use a line like this

awk '{system("git diff " $1 ".." $2 " --name-only")}' | egrep '.py$' >/dev/null && sudo /etc/init.d/apache2 reload

to reload Apache only when a Python file (whose name ends in .py) has changed.

My little post about how much data weighs has been getting a lot of attention ever since I posted it in a Slashdot comment. Well, not really a lot of attention, but it's gotten over 100 hits this month, which puts it up in the top 5 pages on the site. In the course of investigating where all this traffic is coming from, I noticed a lot of requests in the logs for /blog/addcomment. Now, perhaps a lot of those are spam, but I figured I've held off on anonymous commenting long enough. Since there's no way I'll be able to do it properly anytime soon, I put in a bit of a hack that lets people post comments without authentication. This probably means I'll have to go through the comment table to weed out spam posts, but whatever, at least it should be interesting...

I've been working on this for a while now, and finally my blog has a functional RSS feed. It's the super-ghetto RSS2 format, rather than the newer, slicker (and more complex) Atom, though, so nice things like, I don't know, HTML(!!) are a no-go, and it's not even W3C standard compliant, but it works with my RSS reader which is good enough to start with. Use at your own risk.

And not to worry, someday I'll do this properly and set up an Atom feed.

Last week — at least I think it was last week — I made a really huge functional change to the website, probably the most significant change since I changed all the code from PHP to Python in the first place. But although that change, the new chained handler architecture, made the behind-the-scenes work significantly easier for me, it really didn't look any different on the surface; in fact, you would be forgiven for thinking that the overall look of the site was dark and gloomy and frankly, rather unattractive (I certainly did). And from a visitor's perspective, an attractive website is a good website.

So today I present the long-overdue cosmetic companion to last week's functional update. I've actually been planning this theme upgrade for well over a month, and originally I was going to make more drastic changes, but after spending the past couple of weeks thinking about it I realized that most of the site design wasn't actually that bad. After all, I'd already made a nice textured background for the site and introduced the nifty rounded rectangle borders for blog posts, and reducing the area taken up by the announcements (at the top of the page) definitely helped the look. That was my main complaint, actually, that the "banner information" which is common to several different pages was taking up most of the viewable area, crowding out the content. Google has long been considered the acme of web page UI design and they are relentless about clarity and open space. So I decided to take a good hard look at where I could rearrange things to use the available space more effectively.

To that end, I replaced the old solid black banner at the top of each page with the nifty new blue banner you see above — it's better on three counts, (1) more colorful (2) more curves (3) smaller/less intrusive. It also makes room for the menu to move up to the right, so that doesn't get in the way. Also, on the program pages, I did basically the same thing by moving the current version indicator and the program page navigation links ("Home", "Access", "Development", etc.) up to the right of the logo.

Part of my goal for this redesign was to integrate the TextWriter page with the rest of the site, not only by making it look the same but by making it use the same templates and common data structures, so, for example, announcements would show up on the TextWriter page as well as on every other page. TextWriter currently exists as a Java web application served by Tomcat; it's a completely separate system from the rest of the site, and that makes integration pretty difficult. Sure, it can integrate with itself pretty well (that's how the submission form could change itself to always display the latest image you created), but once I started recoding parts of the application, it would be difficult to hook them together without using AJAX. Which is great, because I was thinking about doing that anyway (repeat after me: AJAX = Chocolate = Happiness). So I created a new TextWriter web page, complete with an asynchronously-updating nicely-laid-out form-in-a-table, and since I'd have to rewrite a lot of the Java code anyway, I dropped it completely in favor of the fantastic and very powerful ImageMagick tool suite. This allows a lot more room for expansion and addition of new features in the future, with much less work on my part. This can only be a good thing.

Anyway, enjoy the new look! Comments, if you have any, can be attached to this post, or emailed to me at contact@ellipsix.net.

P.S. Almost forgot: the change in name from "Ellipsix Programming" to "Ellipsix Informatics". This simply reflects the fact that there's going to be less software distribution and more assorted . . . stuff from now on.

Regular visitors (yeah right, as if I have any) may have noticed that I've updated the site with a new, or at least pseudo-new theme. This grew out of an effort to procrastinate doing real work: I was bored with both the physics problems I was supposed to be working on and the endless Python coding and sysadmin-type-stuff that this web server is needing to become truly production-ready, whatever that means. (Warning: the rest of this is quite possibly boring, I'm mostly writing to test out the new features and so that I can remember what I did)

So I pulled up Inkscape and the GIMP and went to work creating new images. Most notably, I've gotten rid of that ugly blue/green aura that used to surround the blog posts and replaced it with a clean blue and gold border with pure white on the inside. And in order to make that contrast with the page background, I've got a papery texture created with the GIMP's airbrush tool (that, by the way, was all too easy).

Also, in the way of changes to the CSS, some of the blog post details have been reduced to a smaller font size and moved over to the right side. I've also condensed the layout of the announcements section. This actually works really well with the nifty Javascript slider I'm using in that section (which I promise to write up as a tutorial at some point).

I welcome feedback on the new look; you should be able to register and leave a comment on this post, or if that doesn't work, send an email to contact@ellipsix.net. (Please digitally sign messages if possible, it'll help get you through the spam filters)