On Ubuntu 8.10, I ran into a bit of prob­lem. The Apache web server was work­ing fine, but the fol­low­ing commands:

sudo apt-get install php5 libapache-mod-php5
sudo /etc/init.d/apache2 restart

failed to work after cre­at­ing a phpinfo.php file in the /var/www/ root folder. Fire­fox com­plained, “You have cho­sen to open phpinfo.php which is a: PHP file.” Apache was not using the PHP pre­proces­sor for some rea­son. A bunch of forum posts and blogs said to edit either /etc/apache2/httpd.conf or /etc/apache2/apache2.conf in order to asso­ciate the PHP mime type with the file exten­sion. That wouldn’t work because I had also installed php­myad­min which has an apache.conf file that already has an AddType direc­tive. So, after some dig­ging around, it turns out the mod­ule wasn’t even being loaded, even though that’s what you’d expect the pack­age man­ager to han­dle when you tell it to install the mod­ule. Any how, to fix the prob­lem, just cre­ate sym­bolic links to the php5.load and php5.conf files in the /etc/apache2/mods-enabled/ folder.

sudo ln -s /etc/apache2/mods-available/php5.load /etc/apache2/mods-enabled/php5.load
sudo ln -s /etc/apache2/mods-available/php5.conf /etc/apache2/mods-enabled/php5.conf
sudo /etc/init.d/apache2 restart

Update: Debian-based installs of Apache2 have some handy com­mand line utils for man­ag­ing the web server. So to enable a mod, which auto­mates the above, do this instead:

sudo a2enmod php5

a2dismod is the com­mand for dis­abling a mod. For sites, there is also a2ensite and a2dissite.

I like Ruby, but I don’t like its per­for­mance, so I’m really antic­i­pat­ing Ruby 2.0. Mean­while, I’ve been dab­bling in Python. Learn­ing a new lan­guage and com­par­ing and con­trast­ing them, really helps with deter­min­ing each language’s strengths and weak­nesses. For exam­ple, you can eas­ily update all your Ruby gems. Unfor­tu­nately, python doesn’t have a direct way of doing this using easy_install. Very odd. I tried using the shell script method, but for what­ever rea­son it just didn’t work as adver­tised. So I wrote a bash alias to take care of it.

(more…)

After many false starts, I decided that I really needed to wrap my head around unit test­ing when writ­ing Rails appli­ca­tions. I more or less com­pleted a Rails 1.2.3 appli­ca­tion with­out any for­mal tests, and I would like to upgrade it to 2.0.2 and make it REST­ful in the process. At the same time, I’ve moved from a Win­dows devel­op­ment envi­ron­ment to a *nix one after installing Xubuntu on my lap­top (an old Com­paq Pre­sario). I’ve also switched from Cream to Emacs. Despite my Win­dows desk­top being more than twice as fast as my lap­top, I just could not stand not being in a true *nix envi­ron­ment. Too much of the Win­dows idio­syn­crasies got on my nerves. And my switch from Cream to Emacs was because I just didn’t like the insta­bil­ity of the hacks required to make Vim less of a modal edi­tor. If I tire of Emacs, I may try pure Vim instead, but I remem­ber installing Cream sim­ply because I didn’t like pure Vim to start with. So with these var­i­ous changes going on with my Rails pro­gram­ming envi­ron­ment, I fig­ured it was an ideal time to learn to for­mally test my appli­ca­tions. Of course the first part is set­ting up the test­ing envi­ron­ment so that it is easy to use, stays out of your way, and is informative.

(more…)

The last cou­ple of week­ends I tin­kered with the gOS 2.0 beta. It def­i­nitely looks bet­ter than the pre­vi­ous iter­a­tion. The gianor­mous icons were just way too big for a res­o­lu­tion of 1024×768. This will def­i­nitely make a more appeal­ing inter­net appli­ance for my guests than my pre­vi­ous box. To make it login auto­mat­i­cally as a guest user took a bit of work, though, since this capa­bil­ity was not part of the ini­tial install.

(more…)