Chatteren

Here's what I ended up putting in an .htaccess file for each of the various sites I run/own/manage to participate in the SOPA/PIPA protest today:

RewriteEngine On
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0459
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1701
RewriteCond %{TIME_YEAR}%{TIME_MON}%{TIME_DAY} =20120118
RewriteRule ^(.*)$ http://sopastrike.com/strike/ [R=307,NC,L]

Learn something new every day. *g*

This forwarded each site to the protest page for a certain time frame (the length of the protest, adjusted for the server's time). You could use something like that to put a site in maintenance mode, for example. Just be sure to add a RewriteCond that checks for your IP so you can get to the site to test it. ;)

Here are the solutions to a few annoying things that caused issues when I was installing Python, Django, and MySQL on a new Windows 7 64-bit laptop.

1. Be sure to set your PYTHONPATH variable.

After I installed ActiveState Python, it didn't set up the environmental variable. I added it and restarted the command window, and voilà. (I don't remember having to set that up manually on my XP machine, but I could be mistaken since it's been a very long since I installed everything on that machine. Regardless, it's a good thing to check. *g* Also check your PATH variable, to make sure that Python, Django, and MySQL are all in there.)

2. Assign the read_default_file setting in the database dictionary.

I was getting "Error 2003: Can't connect to MySQL server on 'localhost' (10061)." It wasn't the firewall blocking the port, because mysql is running on a socket. (Though I could be wrong, as I just switched over to Codomo from ZoneAlarm, which had issues with Win7 64-bit and Filezilla, and I haven't learned all of Codomo's quirks yet, so who knows?) Even though I've got the admin service set up to execute "C:\progs\mysql\bin\mysqld" --defaults-file="C:\progs\mysql\my.ini" MySQL, it still wasn't finding the ini file for some reason. Weirdly, telling Django which my.ini file to run MySQL with fixed it. In your settings.py, in the database section, you'll add the OPTIONS entry:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'database_name',
        'USER': 'username',
        'PASSWORD': 'password',
        'HOST': '',
        'PORT': '',
        'OPTIONS': {
            'read_default_file': 'c:\path\to\your\my.ini',
        },
    }
}

Say you need the full URL of the current page you're displaying that you need to use on the template of that page, for example, to add links to Facebook, Delicious, etc., and you don't want to have additional JavaScript that you didn't write on your pages. (Why yes, I'm a control freak, shush. :P) Also say that you don't want to use the sites framework to hack it together. The permalink decorator won't work, either, because that just gives you the relative link.

Thankfully, there's a new request object that's been added to 1.0 that will do it.

To use it, include the bolded bit in your views.py file, as part of each view where you want to have the variable available:

return render_to_response('dir/template.html', {'object': obj, 'link': request.build_absolute_uri()}, RequestContext(request))

Then you can use the link variable on the template where you need the URL:

<a href="http://www.facebook.com/sharer.php?u={{ link|urlencode }}&t={{ title|urlencode }}">

I have yet to figure out how to get it to work with generic views, so feel free to holler if you know how. *vbg*

What's so bad about liking SQL? About enjoying the beauty of a really damned well-written and concise query? Seriously, I just don't get the hype about ORMs versus writing the queries yourself.

Don't give me the "but it makes everything portable!" argument. How many times have you designed something, only to have to switch to a different RBDMS partway through? Or had to switch to a new one after the project's done? *snort* Yeah, that's what I thought. If you're that worried about this elusive and inchoate thing called "portability," design the system so all the queries can be put in one directory or file, and provide a way to swap out the optimized queries for each database-specific version. You know, kinda like we already provide language translations.

Please explain to me how a system that takes hours (eight and counting) to debug and runs a separate query for each fucking result is superior to the single optimized query I can write in less than thirty seconds and which produces the exact results that I need and no more, with none of the tearing out of hair and hours of frustration?

Also, if you're going to write a framework that alleges that the ORM can be easily decoupled from the framework so that you can write your own SQL? An easy and—most importantly—well-documented way to get the damned results into the format the rest of the framework expects would be really nice. (The crap that makes up 99% of all documentation for programs—open source or commercial—is a rant for another day.)

This is the code for a Django template tag I adapted (also posted here). It was based on this snippet, adapted to split a list into n number of sublists, e.g. split a list of results into three evenly-divided sublists to enable display of the results in three columns on one page with CSS.
Continue reading 'Django snippet — Template tag: split list to n sublists' »