Helvetica is the Neue Thing

Web font selection is terrible. So terrible it’s frustrating. This site was previously all typeset in Trebuchet MS, which is a very interesting typeface. It’s a humanist typeface and it can convey modernity with a hint of playfulness. The reason why the entire site was typeset in a single face was that nothing really blends well with it. However, a single typeface hinders readability, so I decided to find new fonts.

A modern trend in web typography is to set the body text in a small-sized Verdana and headlines in Georgia. So this, naturally, was my first choice. Almost immediately it became clear to me that a serif font does not fit the design aesthetics of the site: it’s too formal. However, as my palette was limited, I decided I would try some other serif fonts. To get around the limitations of the web, I wrote a PHP script that received a string of text as a GET parameter and would take in a font and use the GD functions to return a PNG image that could be used on a page. I tried this with a variety of fonts, and while it did work, I was unsatisfied with load times and the anti-aliasing quality (plus it only confirmed that serif fonts did not work with the site).

I then started playing around again with the few web safe fonts I have access to and I settled on an interesting combination: Verdana for the headlines and (hopefully) Helvetica Neue for the body text. Unfortunately, not all people have the Helvetica Neue so it will have to degrade to Helvetica, or worse yet, it’s knock-off cousin, Arial. But this font combination works well. Verdana is a blocky (when used large) font that has large, strong, open letter forms. Helvetica on the other hand, is a narrow, rounded, and light font. So while the two fonts are both sans serif, they generate enough contrast that mitigates this similarity.

This marks only the second “major” change to the site’s design in over a year. I’ve decided to take a new approach with the site: instead of drastically changing the site every few months, incrementially make subtle changes where necessary. This font change I do think was necessary and should increase readability. The previous change was reducing the size of the header and lightening the page background, both of which also increased readability. (See a common theme here?). This approach forces you to think about your site in a different way, and instead of trying to tear down all your previous work, it helps build upon it, only tinkering with the portions that need fixing.

Apart from that, some of the sites internals have changed. Namely, the download system has been rewritten (it used to generate ZIP and TAR packages on the fly, but I have changed it to now just stream pre-made packages to reduce server load and so that I can ensure the quality of the packages). Also, I added a section to the site on source repositories, and I cleaned up the contact form.

Git Public push-ing Woes Resolved

Over the last few days I’ve been experimenting with distributed version control. I’ve finally settled on git. My large projects (Bugdar, namely) will remain in Subversion for the foreseeable future because I don’t want the hassle of converting. However, one of the drawbacks of SVN is the fact that it needs a dedicated svnserve or Apache2 DAV. Most web hosts offer neither of these, which will make it impossible for me to publish my smaller works. In a few months when my current Subversion server will be taken offline forever (because I will no longer maintain it at college) this will cause problems. This left me with two options: create Sourceforge.net projects for each small project (which I didn’t want to do as some may die very quickly, others are too small and not worth it, etc.), or find a new version control system that didn’t require special servers. Hence, I went shopping for a version control system that works over plain old HTTP.

First, I tried Bazaar. It was okay. Nothing spectacular, however. And it seemed rather immature. SVK sounded interesting but it still relied on the SVN repository layer so it was done before it got started. I then thought about creating a Ruby-based CGI WebDav implementation and then adding a layer on top of that with the SVN SWIG bindings. However, I ultimately decided against this because it sounds like a total pain in the a$$ to maintain the SVN part of the equation (though I still may write the WebDav Ruby CGI as it sounds like a fun challenge).

So I was back at square 0. Then I decided to look at git. I briefly glanced at git in my searchings before but I was turned off by the command set. But I finally went back and had a thorough look. And I’m now using it to manage a new project I’m working on (more on that in another post).

Using git is straightforward (for most things). The only feature I wish I had was the ability to do the equivalent of “svn revert” on specific files instead of “git reset –hard” on the entire working copy. I also miss incremental revision numbers. But I’ll live. Because git is fast, and doesn’t get in your way at all. It makes perfect sense.

And git has some amazing features. The first of which is a compile-instantly and an install-without-being-root installation. Then there’s the whole notion of the “index” (or a staging area for commits). I like this a lot as it forces me to be more careful with what I commit. Also, the two built-in GUI commands (gitk and git-gui), while unattractive, are very useful and it’s great they come out-of-the-box without any work. But my favorite thing is definitely the ability to go back and edit the last commit! It’s fantastic to be able to fix a mistake without having to make a whole separate revision.

So I’ve been using git locally for a few days now, and I decided it would be a good idea to try push-ing it to bluestatic.org to make sure that public repositories will actually work! After many, many failed attempts all I could get was this cryptic message:

bash: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly
error: failed to push to [removed]

And then, by chance, and after a good 20 minutes of searching, I found this perfect answer on Google:

Many installations of sshd do not invoke your shell as the login shell when you directly run programs; what this means is that if your login shell is bash, only .bashrc is read and not .bash_profile. As a workaround, make sure .bashrc sets up $PATH so that you can run git-receive-pack program.

So I solved this error by simply creating a .bashrc file with this in it:

export PATH=${PATH}:~/bin

I thought I’d just write about this in hopes of helping others out.

Bugdar 1.2.0 and the Future

Now that Bugar 1.2.0 is out in its final version (you can go grab it from the Bugdar page), it’s time to start thinking about the next major release of Bugdar.

Major releases of Bugdar have been happening about every 9 months: 1.0.0 was released 17 January 2006, 1.1.0 was released 1 October 2006, and 1.2.0 was released 14 July 2007. I have been wanting to use some OOP features in PHP5 for a while in Bugdar (namely the ISSO3 framework) but because I don’t want to cut down on the userbase, I have been wary of doing so. However, with the GoPHP5 project roughly 9 months away, it seems like the perfect opportunity to switch to PHP5.

I do think the next release will be 2.0 as I don’t think there’s enough semi-major features to warrant a 1.3 release. I have some ideas as to what should be in 2.0 and I think it will be an amazing release. You can see just a few of the features that are likely coming in 2.0 here. Unless there is opposition to doing so, I think the next version of Bugdar will be 2.0 and will be PHP5 only. Moving to 5.2+ would mean a lot of legacy code can go away and I can move into much more advanced OOP programing, which would make Bugdar more robust and would help reduce the number of bugs, as well as increase testability.

And a side note: I’ve started moving all my open source SVN projects to be at Sourceforge as a way of consolidating my servers as I won’t have the resources to maintain as many next year in college! You can find Bugdar’s page here.

Getting PHP mail() to Work on OS X Tiger

I recently (as in this week) got my brand new MacBook Pro. It’s shiny and I love it and for the past few days I’ve been transitioning my life from desktop to laptop. One of the things I had to do was to get PHP installed and working, which as usual, was straight forward. However, on Mac OS X, I couldn’t figure out why PHP wasn’t properly sending out email. The answer lies in the fact that, by default, Mac OS X does not start Postfix (which is what is used to send email). I searched the web for numerous tutorials on how to get this to work, but all of it conflicted. Ultimately I just read the man pages on launchd (the thing that makes OS X start) to get it to work after comparing my laptop’s configuration to my desktop’s.

So this will get the Mac OS X mail server working on 10.4.10 (and most likely all of 10.4.x):

Edit, as root, /etc/hostconfig and add this line (presuming there are no other lines for “MAILSERVER”, and if there are, simply change it to be this):

MAILSERVER=-AUTOMATIC-

And then run this command in the Terminal:

sudo launchctl load /System/Library/LaunchDaemons/org.postfix.master.plist

Next time you reboot, Mac OS X’s mail server will be working hunky-dory. Note: this will not create a persistent SMTP server, but instead will start when an email is sent and then will automatically close when it’s done (so Postfix will not run in the background when you don’t need it).

Bugdar 1.2.0 Last-Call

Bugdar 1.2.0 is almost ready for it’s final/debut release. There are just two outstanding issues that I would like to close before releasing. If you are in a position to do so, please help by submitting as much information as possible about these two bugs:

• #86 – Issue with marking bugs “hiden” that I cannot reproduce
• #82 – RTL/Hebrew emails are showing corrupted characters

Any help would be appreciated in order to move 1.2.0 out the door.