RDFa in Ruby, a First Stab
2 Comments A new draft of RDFa [1] has been out for about a month now, and it got me to thinking about RDF again. This time, the geek in me saw the opportunity to use easily use RDF in my Atom based applications. Instead of using embedded micro formats in Atom Entries, I can create semantic relationship using preexisting ontologies (e.g. – DublinCore) in an easy to read format.
The XML generation side had near zero work thanks to Ruby On Rails’ rxml format. But I was lacking a parser to read in the RDF statements even though there were a few Ruby RDF Stores available. The only RDFa parser I found was written in Python– rdfadict.
So, I just set aside parts of the last two days and came up with my own super simple Ruby RDFa parser; I read and reread the RDFa Syntax draft document, which is still far from complete; I skipped implementation of parts of the spec: xml:base, reification, and nested CURIEs; and got something to just work. (Note: rdfadict uses XPath for its implementation. Instead, I used an iterative approach to traverse XML documents).
Basic parsing works; I also made it flexible enough for custom integration; I just need to spend time to write up the documentation and write up more test cases. I’ll move forward with it as the RDFa spec develops and when I get feedback from anyone that uses this library.
But for now, the code is hosted here: http://code.google.com/p/ruby-rdfa/.
Django and Dreamhost, Take 2
No Comments After installing my own custom Python build, I went back and tweaked how Django ran on my Dreamhost account. My previous Django installation experience is still mostly valid. I just figured I could “upgrade” the installation to take advantage of Python 2.5 and eggs.
I installed three eggs to get Django running
# For Django
python ez_setup.py MySQL-python
python ez_setup.py http://www.saddi.com/software/flup/dist/flup-r2030.tar.gz
python ez_setup.py http://www.djangoproject.com/download/0.95/tarball/
The first was mySQL support; second was for Django’s built-in fcgi support; and finally Django itself.
I had a second goal in this upgrade. I wanted to partition off the “/-/” subtree (For example, http://example.com/-/admin/) for Django, instead of using the full subdomain. I had to make a couple of changes to the project’s urls.py file (to handle the ‘-’) and to the .htaccess file:
# urls.py change example for the admin application.
(r’^-/admin/’, include(‘django.contrib.admin.urls’)),
The .htaccess file:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^-$ /-/ [R]
RewriteRule ^-/(.*)$ /_/mysite.fcgi/-/$1 [QSA,L]
</IfModule mod_rewrite.c>
And finally, a new mysite.fcgi script found in the /_/ directory (notice that it’s an underscore, not a dash):
#!/home/user/bin/python/bin/python
import sys, os# Switch to the directory of your project. (Optional.)
# os.chdir(“/home/user/myproject”)# Set the DJANGO_SETTINGS_MODULE environment variable.
os.environ['DJANGO_SETTINGS_MODULE'] = “myproject.settings”from django.core.servers.fastcgi import runfastcgi
runfastcgi(["method=threaded", "daemonize=false"])
Python, Eggs and Dreamhost
3 Comments Dreamhost, my web host, does not yet support Python2.5, and one can’t install Python eggs into Dreamhost’s own Python installations. The solution? I just installed a custom build of Python2.5 into my $HOME/opt directory. The following is the script I created to automate that process:
# Obtain Python2.5 and unpack
mkdir $HOME/downloads/
cd $HOME/downloads/
wget http://www.python.org/ftp/python/2.5/Python-2.5.tgz
tar -zxvf Python-2.5.tgz# Creating the location under which python (and other apps) are to be installed.
mkdir $HOME/opt# Go into the Python2.5 directory, make && make install the thing
cd Python-2.5
./configure –prefix=$HOME/opt –enable-unicode=ucs4
make && make install# Create a bin directory for Python, and link the bin to the real executable
mkdir -p $HOME/bin/python/bin
ln -s $HOME/opt/bin/python $HOME/bin/python/bin/python
After the installation, I edited the bash_profile file to add the bin path:
export PATH=$HOME/bin/python/bin:$HOME/opt/bin:$PATH
Now with a custom installation of Python, I can use eggs to manage my Django projects’ library dependencies.
I guess it’s not that bad
1 Comment Over the years, I had developed an absolute hatred in my heart when it came to Javascript and DOM programming. No one big specific reason, just all the little annoyances: browser incompatibilities, debugging sucked (was tedious), never found any javascript library helpful or easy to use (this includes prototype, MochiKit, and Dojo), etc. Let’s just say that I would have rather gotten teeth pulled using rusty pliers.
But I’ve come to rethink my position… I can now stand, even enjoy, Javascript programming. Wow, what could have possibly happened to me (a once huge Javascript hater) to actually like it now? I give you the three reasons why:
- I started to work the Javascript language as it were actually Scheme (or similar functional language), closures and all.
- I found the Firebug debugging plugin for Firefox. I will never have to use an alert() call ever again
. - And the biggest reason why I changed my mind: I found jQuery. This libary removed all the little pains I listed above, and released me in a way that I could focus on doing #1 above.
Take those three, and mix it up with with a Django powered backend… I am thoroughly confident that Javascript does not suck.
REST Quote of the Day
1 Comment A great quote:
Web services build upon HTTP, but they don’t build upon the Web. The Web uses HTTP as an application contract which enables the loosely coupled exchange of documents between applications, while Web services uses HTTP as a bit pipe – as a transport protocol. –Mark Baker
Coral Cache and htaccess
2 Comments A recent digg post showed off a WordPress plugin designed to help prevent a site’s server meltdown due to traffic overload (i.e.- Digg or Slashdot effect). The plugin redirects all incoming traffic from heavy sites (e.g. – digg.com) to the protected site’s equivalent Coral Cache page.
The cool part is that someone posted a sample Apache htaccess ruleset that does the same thing. Why is this better? It’s going to be way faster than using WordPress’ caching system in PHP.
My own modifications to the ruleset now:
- allows Googlebot direct access (no redirect);
- allows redirects from any subdomain of the high traffic sites, not just www;
- redirects the main page (“/”) too. The ^(.*)$ seemed to not redirect the “/” pages on some apache installations. I changed it to ^(.*)?$
Just copy & configure the following ruleset to the top of your WordPress’ .htaccess file (or the .htaccess file of any other site):
#
# Heavy Site Redirect to Coral Cache
# Links incoming from heavy sites are redirected to the Coral Cache
# Exception: Coral Cache Proxy Servers
# Exception: Googlebot crawler
#
# CONFIG: Replace “example.com” with your target domain name.
# CONFIG: Follow the HTTP_REFERER RewriteCond examples to add or remove
# domains to the list of redirected sites.
#
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !^Googlebot
RewriteCond %{HTTP_USER_AGENT} !^CoralWebPrx
RewriteCond %{QUERY_STRING} !(^|&)coral-no-serve$
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?digg\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?slashdot\.org [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?slashdot\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?fark\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?somethingawful\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?kuro5hin\.org [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?engadget\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?boingboing\.net [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?del\.icio\.us
RewriteRule ^(.*)?$ http://example.com.nyud.net:8080/$1 [R,L]
</ifmodule>