Archive for the ‘Uncategorized’ category

Pipeline Update 1

Two months ago I gave an update on my entire timeline of projects. This will just be a quick rundown of the projects and their status.

mkrcpt: Shelved, probably indefinitely. It turned out to just not be that useful. I’ll push the git repository in the near future, however. But this will not be officially released or supported.

MacGDBp: The icon is done as is the line numbering in the source view. I’m now just fixing some bugs and finishing off the breakpoint manager. This should be out the door by the end of May! As this comes near completion, I’ll hopefully start drumming up interest in it. Stay tuned for more information.

CMS: This is almost done as well. There are a few more modules I need to write, but the architecture that I’ve already written will make that quite simple.

All the other projects are at the state detailed in the last pipeline update. But this is progress, at least!

On Pipelines, Expansive

It’s time to talk pipelines. Initially, I was going to talk timelines. But timelines have the problem of addressing time, which is very difficult when you have 40+ hours of activities and school to do during the week. So, pipelines.

I’d like to start by announcing the completion of ISSO3. I’ll go into the details of why it took so incredibly long to finish in a future post, but you should know that it is finally done. What does the completion of ISSO3 mean? It means that all PHP projects can now resume development and use this framework. ISSO3 also requires PHP 5.2, which means that any future major releases of PHP projects will require PHP5.

That’s one less thing in the pipeline!

But what else is in this (expansive) pipeline? (Note: This is roughly in order of when the items will be finished. I very may well skip around and work on various projects when I feel like it, but this order is based on how much work is done versus how much has to be done).

mkrcpt

I compile a lot of open source projects myself rather than using ports or fink. Many people are familiar with the make; make install process. One of the problems with make, though, is that there’s no uninstaller. This to me is a problem. So I decided to solve said problem. Enter two very small C programs: mkrcpt and unrcpt. Instead of typing make install, you would invoke mkrcpt. What mkrcpt does is it index all of the items in the installation path by last modified date, then runs make install for you, and reruns the index algorithm. It then stores all the changed files in a receipt file. If you ever want to uninstall a program, just run unrcpt.

What’s left: Testing and a few fixes to the receipt file format.

MacGDBp

PHP developers have access to a really cool extension called Xdebug that has remote debugging functionality via a protocol called GDBp. Both Windows and Linux have GUI clients for this protocol, but the Mac does not. The lack of a client irked me because the functionality is quite helpful.

What’s left : The basic functionality is all done, but there’s still a bit left to do to make it useable. Those items are: adding line numbers to source views, adding breakpoints (currently you use the xdebug_break() function in your code), and making an icon.

CMS

No, I’m not writing another CMS solution to compete with Joomla, ExpressionEngine, etc.. This is a private project for my university’s TV station. The website is going to be completely redone to allow for modular content blocks and dynamic templates. The project looks fairly straightforward, so it shouldn’t block things in the pipeline.

What’s left: I haven’t started writing a single line of code yet, but it’s completely planned out.

Bugdar 2

I am very excited about working on Bugdar 2, but as you can see, there are a lot of things in the pipeline. I’ll post more about this as the pipeline start’s clearing up and work begins.

What’s left: Everything.

NewzGrab

This is another Mac app that will take in Newzbin (.nzb) files and download them from your favorite NNTP server. I’ve only mapped out the classes and hand-drawn a mockup interface. More on this will be posted as work commences.

What’s left: Everything.

MyWishlist

A while ago I had a project called MyWishlist that allowed you to setup a wishlist site for you and your friends/family. I won’t go into the details here, but I’m rewriting it to be a hosted application as opposed to a downloaded one. Don’t expect it anytime soon because it’s a very low-priority item.

What’s left: Deciding what language to write it in. Ruby? PHP? Python? Who knows?!

WebFreeChart

This is a PHP5 OOP charting library. It’s boring to work on. But I need it. It’ll happen… eventually.

What’s left: Almost everything.

So, the above is a list of all the projects I’m juggling. It’s a lot. There is no timeline as to when things will be done. I wish I could give one, but with the amount of Real Life ™ things I have to do, I just work when I’m not tired, I’m in the mood, and I have free time. If those three stars align, progress gets made. I’ll keep you guys updated on any major developments. Your patience is appreciated.

WebKit Cron Downloader

I’ve recently been doing some work on WebKit and I want to run the latest nightly builds of Safari/WebKit so I’m no longer plagued by a bug I patched. I don’t want to have to manually download the most recent nightly build and place it in my Applications folder, I want it done for me.

According to the WebKit FAQ, there’s software to do this for you, but it didn’t work for me when I downloaded it (I don’t think the symlink to the latest build works, which is what it relied on). So, I wrote my own cron script to do it.

The script is written in Ruby and I have my cronjob set up like such:

30 21 * * * ~/Library/Shell/webkit-download.rb

Basic operation of the script:

1. Grab the contents of nightly.webkit.org
2. Find the path to the latest DMG
3. Download and mount the DMG
4. Move the old /Applications/WebKit.app to the trash and date-stamp it
5. Copy the latest WebKit.app from the DMG and then umount

If you’re interested, you can get the script here:

webkit-download.rb (~1.4 KB)

MySQL in Leopard

Many people have been reporting issues with MySQL under Leopard with this error:

mysqld: Can't create/write to file '/var/folders/2F/2FtguLeuG1ibx1X9tbDS0E+++TI/-Tmp-/ibYWBjEU' (Errcode: 13)
071204 11:15:48  InnoDB: Error: unable to create temporary file; errno: 13

I have discovered a fix for this particular issue. First, in the Terminal, go into your MySQL root directory (mine is /usr/local/mysql). Then type these commands:

sudo mkdir tmp
sudo chown _mysql:wheel tmp
sudo chmod 755 tmp

This will create a temporary directory that MySQL will use. Now we have to make sure MySQL knows about this new location for temporary information, so open up your my.cnf and add this line:

tmpdir=/usr/local/mysql/tmp

(Where the path after the equals sign is the path to your tmp directory).

After this, restart MySQL and all should run fine.

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.

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).

Forum Open

After many requests for a forum, I have decided to put one up. I chose to use Vanilla as the forum software because I think it is a far superior solution for what I want. I do not want a whole bunch of staunchly-defined categories delineating discussions, because then the number of topics in each would be few and sparse. With Vanilla, everything can appear in the same category (though you are not limited to this) which makes discussions flow. It may be slightly unconventional, but I think it will work the best.

The style for the forum is not yet done (let alone started), but one day it will match the rest of the Blue Static website. I just wanted to get it open so people are free to use it.

And please do not report any bugs or formal feature requests in the forum, please use the bug tracker for that.

Without any further adieu, this is the forum.

New Type of Redesign

When I normally think of redesigning a site, new color schemes and layouts are usually the first things that come to my mind. However, when I decided to spruce up the Blue Static website about a week ago, I wanted to pose myself a design challenge: I did not want to use anything but existing design elements to create my refreshed design.

To accomplish this redesign, the first thing I did was I found and isolated the elements and colors that I liked the most. Some people say that a good design starts out in black and white and then colors are added so that it’s color-agnostic. However, I find that when I’m designing–both for print and the web–if I don’t have a vague idea of the final color scheme, the design just won’t work. So I picked a few elements (namely the striped background and the navbar) to reuse all over the place. I then went to work on a design on paper.

Any good designer will start out on paper just to get a rough idea of how things should look. I have paper designs for Bugdar, Kalens (the demoed calendar product), and this website and the paper looks almost identical to the web version. Designing on paper is important because it allows you to visualize your design without having to write any code. Can you imagine creating an entire website and then scrapping it because you don’t like the way it looks?

I feel that whenever you are _re_designing something, you’re doing it because you did something wrong with the current design. Therefore, before I finalized the paper design, I decided to go through the old website and pick out elements I didn’t like and I made sure I addressed them in the final design. What didn’t I like about the old design? The navigation bar was far too large, so the new design cuts out about 80px of it; many of the banner images had a greenish color which really jarred with the blue, so now the images have all been hued to a more bluish tint; the text was too low-contrast, and so I changed the background to be white.

And when you look at the final design, those are really the only major changes. Everything else has just been ever-so-slightly lightened to make the design more welcoming (darker designs are generally harsher too look at).

Here’s the before-and-after shot: bluwww-redesign-dec06.png (172 KB)

So what’s to learn from this redesign?

1. Keep your design goals clear.

2. Do your layouts on paper first.

3. Don’t change things that don’t need to be changed.

On a side note, Bugdar 1.2.0 is coming along steadily as is ISSO3. I hope to have both of those finished by late April or early June.

No Time to Waste!

If my quick review of NewsFire in my list of “Amazing Mac Software” didn’t convince you to buy NewsFire, this definitely should:

For the next two days, if you buy NewsFire, you also get Inquisitor for free. For those of you who don’t know, Inquisitor is a very cool plugin for Safari that takes over the Google search field. When you start typing, it instantly brings up the results (it can also be programmed so that shortcuts search different sites). This is very handy if you already know what you’re looking for and just can’t remember the URL.

So, if you haven’t already, go pick up NewsFire and get Inquisitor for free. Both of them are great applications!

Sidenote: today Bugdar 1.1 sound a round of bug fixes and testing. Beta 2 is due out soon–probably Monday or Tuesday. More about that later.