Looking at Google’s OpenID documentation, we note that certain parameters are required to send an authentication request to Google in order for the user to log in using the service. (Steps 5 and 6 below.)

One of the parameters required in the auth request URL is the  ”return_to” parameter. Importantly, note that this parameter is both required and needs to point to a currently valid domain.  What this means, is that if you’re doing development internally, setting the “return_to” parameter to testing, or localhost, or similar, will cause the request to fail with a sufficiently cryptic, “The page you requested is invalid.” Even attempting to have the return sent to a port other than 80, eg. http://my.valid.domain:8080, will also cause the request to fail.

Unfortunately, all these requirements seem to have been assumed, and not documented on Google’s site.

A trick!

One trick to get around this no-local-testing conundrum is to set the return_to parameter to a subdomain (or otherwise) of a valid domain, eg. http://testing.my.valid.domain, and then set that address in /etc/hosts to point to your testing server.

So recently ran into an issue with my new HP LCD monitor where Snow Leopard suddenly decided to make my fonts look all skinny and malnourished (that’s turning font smoothing off, apparently). Which was really annoying, since I was using Monaco on the Terminal and in my code editors and they looked really horrible after that.

Finally get fed up enough to Google around a bit for Mac OS X font tweaks and ran into the solution below.

And now my fonts are happy! Or at least I am.

Hope it helps someone too.

Reposting here just so it gets out on the web more:

There is a bug in Snow Leopard that disables LCD (sub-pixel) font smoothing on many third party LCD displays, including models from Dell, Samsung, LG, HP, EIZO, and Lenovo. Here are the details:

Snow Leopard introduces simplified Font Smoothing options under the Appearance pane in System Preferences. Prior to Snow Leopard, the available options were:

• Automatic – Best for Main Display
• Standard – Best for CRT
• Light
• Medium – Best for Flat Panel
• Strong

In Snow Leopard, you can only choose between Automatic and Standard CRT. Since few people use CRTs these days, most users now have only one option: Automatic. The problem with the Automatic option is that OS X incorrectly detects many third party LCD monitors as CRTs, and consequently, disables LCD font smoothing.

You can force OS X to use LCD font smoothing on all displays with this Terminal command:

defaults -currentHost write -globalDomain AppleFontSmoothing -int 2

The number 2 here corresponds to Medium – Best for Flat Panel. You may also use 1 for light smoothing, and 3 for strong smoothing, as per the original OS X font smoothing options.

DustJacket

A Python wrapper library for handling ebooks (only ePubs for now).

I’d been looking around for one of these in Python for a while but was unable to find one. It was really annoying being told, “Oh, an ePub is just a ZIP file, so you should be able to easily unzip it and read its contents.” Well, yeah. A car is essentially a platform on four wheels, but they’re much nicer than that now aren’t they?

isbndbpy

A Python API wrapper library for the ISBNdb.com API

Same scenario as above. Need the code, couldn’t find a decent one (especially not in Python!), so decided to scratch that itch and make one myself. So here you go.

isbndbpy‘s implementation of the API is still quite incomplete though, so you have been warned.

That said, if anyone finds these projects even mildly useful, leave a comment! (And even better, help contribute to the projects! Basic stuff like tests, docs and general completeness is still greatly needed!)

JSON is exceedingly common across the web, so imagine my surprise when I found that the default installation of Python on Mac OS X didn’t seem to include simplejson.

Resolving this is easy. The Python installation comes with a handy utility called easy_install, which, well, easily installs missing components:

$ sudo easy_install simplejson
Password:
Searching for simplejson
Reading http://pypi.python.org/simple/simplejson/
Reading http://undefined.org/python/#simplejson
Best match: simplejson 2.1.1
Downloading http://pypi.python.org/packages/source/s/simplejson/simplejson-2.1.1.tar.gz#md5=0bbe3a2e5e4cac040013733aca159d89
Processing simplejson-2.1.1.tar.gz
Running simplejson-2.1.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Ii_EU9/simplejson-2.1.1/egg-dist-tmp-79Fj1U
Adding simplejson 2.1.1 to easy-install.pth file
Installed /Library/Python/2.6/site-packages/simplejson-2.1.1-py2.6-macosx-10.6-universal.egg
Processing dependencies for simplejson
Finished processing dependencies for simplejson
$

And there you go!

The problem I ran into upon attempting to install the Android Eclipse ADT was, as such:

• Following the installations Android SDK site and adding the repository site for the ADT,
• I get the following error about  org.eclipse.wst.sse.ui not being found
• Which meant that the dependency checking for ADT failed, and I couldn’t get it installed.

The only tip Google could provide was that the default eclipse-platform package that Fedora 10 provided was lacking in the particular Eclipse component that the Android ADT needed, ie. org.eclipse.wst.sse.ui (and friends, presumably).

So here’s how to get around that:

• Add the Eclipse Ganymede updates repository in Help -> Software updates.. -> Available Software.. (details).
• You’ll get a new menu item in your Available Software tab: “Ganymede Update Site“
• In the search box, enter “WST Common UI“, and hit Install.

That would’ve brought in the necessary Eclipse components that the ADT requires. From there, follow the usual ADT installation instructions, and you’re done!

I’m running Debian Sid, and I simply apt-get installed the newer version of Trac.

Upon restarting Apache, and trying to access my Trac page again, I get the message that I need to manually perform the upgrade of the Trac files. Ok, so I do:

trac-admin /path/to/projenv upgrade

as recommended. That seemed to bring my Trac back, so I was happy.

However, when I wanted to write a new wiki page, I realised that the nifty formatting toolbar that used to appear over the textarea had now gone missing. Much Googling didn’t help, and unfortunately neither did the IRC channel. Looking back again at the TracUpgrade page included as part of the Trac wiki, I noticed another command that I had yet to run, the one to upgrade the wiki.

trac-admin /path/to/projenv wiki upgrade

I didn’t figure that this might help bring back my formatting toolbar. I only thought that it might be a good thing to run in the meantime, while I googled a little more.

I ran it, and lo and behold, it brought my formatting toolbar back! Unfortunately, this is not very intuitive, upgrading the wiki (implying information/data) to restore parts of the UI (presentation).

Anyway, hope this helps someone!

I wanted to set up a local LAMP development for a project I was working on, so I set up an Apache VHost on a testing directory to serve files out of it. Having done this quite a number of times before, I assumed this to be a routine set up and went through the motions accordingly.

Listen directive? Check. <Directory> directive? Check. Allow, deny? Check. File system permissions? 755, check.

Looking good, I browsed my local URL.

And got greeted with a 403 (Forbidden) error.

Ok, so maybe I missed something out. But no.. all permissions seemed to be in order. I made the test directory’s group same as the apache user. No cigar. Gave the group elevated privileges. Nope. In desperation I have the entire test directory tree 777 permissions. And still got the 403 error.

Diving in to the logs, I was greeted with the following message:

(13)Permission denied: file permissions deny server access: /home/ruiwen/Project/tests/test.html

File permissions deny access? Surely not? They were open to the world!

Next, I figured that the errors might have been caused by Leopard’s new ACLs, since the directory where the files were hosted were on a HFS+ drive. Apparently Leopard sets ACLs on a few select directories to prevent them from being (accidentally?) deleted (eg. Pictures, Documents, Applications and similarly ‘important’ directories). Up to this point, I’d been developing in my newly installed Fedora 10 (dual-booted, and sharing a home partition with Leopard Mac OS X). So I rebooted into Leopard to attempt to discover where the fault lay.

The only problem was that the project directory simply had no ACLs nor extended attributes set on it.

File serving using the Apache within Leopard worked fine though, using the user-specific directory, ~/Sites.

Frustrated, I went back to Fedora to try again. In a stroke of inspiration, I checked out the SELinux settings.

And BINGO!

SELinux -- Allow http to read user home directories

It was SELinux that was restricting Apache’s access to the file all along!

In my previous installations of Fedora, I’d always deactivated SELinux to prevent it from tripping me up. But with this installation of Fedora 10, I’d installed from the Live CD, and I don’t remember that ever giving me a dialogue to do that. Besides, once the system was running, I didn’t seem to run into any problems (until now), with SELinux, so I left it on. Well, guess I know better.. SELinux’s still on though, but at least now I know where I’ll look first in the future.

Well.. it took me 2 days of Googling without useful results. Hopefully this will cut somebody else’s search time short.

I recently set up a LAMP environment on my laptop, intending to do local development for one of our sites.

I did the usual setup of Apache VHosts and all.. only to find that the site had decided to stopped working. This was pretty strange since I’d just checked out a fresh copy from SVN, and the working copy on the dev server was.. well.. working.

Delving through the logs, I saw Apache trying to do something seemingly strange. It was trying to access files as if they were directories, looking into each of them for .htaccess files.

Like this:

[Sat Jun 28 17:14:36 2008] [crit] [client 127.0.0.1] (13)Permission denied: /home/ruiwen/Projects/app/webroot/favicon.ico/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Last I checked, favicon.ico wasn’t a directory.

Some Googling turned up this page, which hinted that this behaviour stemmed from the fact the HFS+ might have been presenting the files as directories.

In some cases, this error can also be caused by special file-systems that return unexpected errors on attempted directory access. For example, some file-systems allow files to be treated as directories in certain cases. If httpd believes that a file is actually a directory, it will try to look inside for an .htaccess file. If it gets a permission denied error in return, it will deny access. This type of situation is usually a faulty file-system behavior and cannot be fixed within Apache. In this case your only choice is to turn off .htaccess processing as in the first solution above.

Turning off .htaccess processing wasn’t exactly ideal since the site needed the functionality.

However, setting more relaxed permissions on the site directory as recommended in the second solution on the page seemed to work.

Currently my permissions for the files are

-rwxrwxr-x 1 ruiwen www-data 3322 2008-06-28 16:39 index.php

This seems to work fine for now. Not sure why the relaxed permissions helped the problem though, and will be glad for any insight into this.

Traditionally, the problem with the Fn-keys of the Feb ’08 edition of the MBPs was that they simply didn’t work. Not even with pommed.

The issue seemed to be an erroneous hardware ID listing in hid-quirks.c, under drivers/hid/usbhid/, where the Device ID for the keyboard was listed as 0x021b instead of the proper 0×0230, as shown when doing an lsusb. (More details in this bug report.)

The fix in the forum post describes how to dynamically load the usbhid module, with the proper Device ID passed to it as a parameter.

Thanks loads to _alex_ and his wonderfully elegant solution, described below:

The fix described is for an Ubuntu system, but there’s no reason why the concept wouldn’t work on any other distro.

1. Edit /etc/modprobe.d/options
2. Add the line below at the end of the file:

options usbhid quirks=0x05ac:0x0230:0x00000800,0x05ac:0x0231:0x00004800,0x05ac:0x0232:0x00000800

3. For Macbook Air users, _alex_ recommends this line:

options usbhid quirks=0x05ac:0x0223:0x00000800,0x05ac:0x0224:0x00004800,0x05ac:0x0225:0x00000800

Following the changes, you should be able to restart your machine and have your Fn-keys working, no additional configuration required. On Ubuntu, the screen brightness keys (F1 and F2) and the volume keys (F10, F11 and F12) and the Eject key (beside F12) work fine.

Ever wondered what the type was about? Yeah? So did I.

Anyways, had the luck of chancing upon a few blogs that, with a few tweaks, allows you to jostle gEdit into behaving somewhat like TextMate (especially in the context of Ruby on Rails). Not all the features though, but close enough.

Check out

• http://robzon.aenima.pl/2007/10/ubuntu-710-rails-gedit-and.html
• http://grigio.org/textmate_gedit_few_steps

And other useful links

• x-rhtml.xml (RHTML mime type definition)
• rhtml.lang (RHTML language definition for gtksourceview-2.0) (Updated link – 19 Aug)
• rhtml-snippets

The 3 files above allowed me to get up and running with RHTML syntax highlighting and snippets