Prosthetic Conscience

What a fascinating quote:

From: http://www.mindview.net/WebLog/wiki-0051 (a comment on Bruce Eckel’s weblog)

2004/03/12 10:02 EST (via web):

About the “directing” vs. “enabling” approach, you wrote: “Both approaches are reasonable and neither is wrong. I have been in both situations; for example, trying to prevent interns from ignoring or even actively circumventing coding style guidelines (where more “direction” was required), and on the other hand being frustrated by the loss of productivity that comes from being forced to conform to constraints that I wouldn’t have violated anyway […]?”.

It is interesting that you justified the “directing” approach with an example about directing others, and the “enabling” approach with an example about enabling yourself. Don’t take this as a negative critique - I did the same when I tried to come up with examples of directing/enabling.

I tend to think that others should be directed, and I should be enabled. I worked for teams whose job was developing software methodologies and the relative supporting tools for the rest of their Company. Except that, of course, they flat-out refused to apply the (directing, strict) methodologies that they were developing to their own methodology-building project. To me, that shows how much in software development is about our own relationships and fears. We still have an awful lot to learn from sociology and antropology - and maybe, oriental philosophies.

Paolo Perrotta Bologna, Italy

I prefer “enabling” approaches everywhere, and agree with the statement that if you have someone who can’t handle an enabling approach, they don’t need directing, they need training. But many people (especially in corporate IT) would argue that this places too high a bar on experience and education for programmers. Still, I’d rather see enabling done technologically, and where direction is needed, see it done socially.

[ Posted: 19:00] | [ Category: ] | Permalink | Comments: 0 ]

Stockphoto 0.2.1 released

I’ve just released stockphoto 0.2.1. This is a bugfix release and contains no new features relative to 0.2. I would like to thank many people for bug reports on the previous version; plese see the credits in the README file.

I’ll be opening development on stockphoto 0.3 once I decide the best way to host a public version control repository (Google code vs. Savannah, vs self-hosting). The pre-0.3 branch will include new features, some of which are listed as to-dos in the current README.

[ Posted: 15:11] | [ Category: /django] | Permalink | Comments: 0 ]

Hushmail: not so hushed, aktuly.

No original reporting or opinions here. Wired has a story on how Hushmail can and will turn over plaintext emails if they receive a Canadian court order. This means that while Hushmail provides good protection against on-the-wire snooping, it doesn’t protect Alice and Bob if Mallory is in law enforcement.

I’ve recommended Hushmail to friends and neighbors in the past, as a way of easing them into the idea of using encrypted email on a regular basis. When I read this news, I felt I had to email people that I had recommended it to, to let them know about the weakness. Hushmail could set up their systems so that they never store a passphrase except in volatile memory, and so that they never store plaintext of messages. But you’d have to trust them on that, and a court order could still mandate that they store them, and not tell you they were doing it.

The best thing would be for everyone to use GNU Privacy Guard on their own computer. But it can be hard to set up, especially for Windows users (though if you’re running Windows, you have bigger security problems), and your correspondents have to all be using GnuPG or OpenPGP, too. This is a big barrier to entry, and even though I’m set up to use it, very little of my total volume of email is routinely encrypted as I’d like it to be. There is also the problem of people without their own computers, who must use shared resources such as public library computers. Hushmail appeared to be the most viable option for them.

If you are interested in using GnuPG, you might look into the Enigmail plugin for Mozilla Thunderbird as a cross-platform solution. If you’re already using Linux, Evolution groupware provides easy-to-use GnuPG support. If you want to send me encrypted email, you can download my public key, the fingerprint of which is C046 0E26 8103 ABA1 68B1 D6E7 A991 E701 91DF 7DDD.

[ Posted: 20:16] | [ Category: ] | Permalink | Comments: 0 ]

Apple-induced Stockholm Syndrome

See here for the source of this well-turned phrase. It ought to replace “reality distortion field” in the Mac community’s lexicon.

Basically, I’m amazed by iPhone users’ collective reaction to the bricking of their phones the same way I’m amazed by the reaction on Daily Kos to the Andrew Meyers tasing. In both cases, the affected community is mostly reacting with “hurt us more! We deserve it!”.

Contrast the OpenMoko project. Install whatever you want across a whole range of supported phones. Switch phones keeping the software you installed.

How are you going to hack your life if you can’t even hack your gizmos?

[ Posted: 09:03] | [ Category: ] | Permalink | Comments: 0 ]

Quoted for truth

Eclipse is emacs for stupid people ;-)
— John J. Lee-2 on python-list

[ Posted: 13:11] | [ Category: ] | Permalink | Comments: 0 ]

Yikes! Stockphoto on Django status update!

The last couple of days I have been seeing a renewed interest in Stockphoto, my basic, minimalist photo gallery application for Django. At the time, I wondered why, since I haven’t updated Stockphoto in the last year, nor made any announcements associated with it. Then, I saw that it had been mentioned in the Django status update on July 22.

This is just a little notice on stockphoto’s status. Stockphoto 0.2 has quite a few known bugs. I have to-do items for all of them in my personal organization system, most of them with contributed patches. I’ve just been too busy in my life to integrate all of these fixes and package them into a release. I want to do better and get two releases out the door soonish.

So here’s the release plan:

1. Stockphoto 0.2.1, soonish. Will fix all outstanding bugs that I know about.
2. Stockphoto 0.3, later. Will include changes to the models to allow slug-based rather than id-based URLs, and some conveniences for template designers.

Please bear with me – if you are in desperate need of a full-featured Django photogallery in the very near future, you will probably want to write it yourself, possibly looking at stockphoto’s code for examples if you are not familiar with Django’s file/image upload handling or with PIL.

Thanks for your patience.

[ Posted: 07:30] | [ Category: /django] | Permalink | Comments: 0 ]

Web templating systems: be opinionated enough, but no more.

There’s some current discussion in the Django community on templating systems on Jacob Kaplan-Moss’s website and elsewhere.

I agree with the general argument. There is a rather fine line between putting too much power into the templating language, so that it either becomes a programming language in its own right, or simply a means of embedding primary-language code in the templates, and putting in too little, so that you can’t do more than variable substitution. That’s not a big insight in and of itself. I think almost everyone knows this by now.

What I think is significant is this:

1. Django’s templating system hits the sweet spot for web templating. Through a combination of good taste and (probably) luck, the Django developers have produced a templating system that strongly encourages web developers to put their controller logic and their view logic in the right place.
2. Django’s templating system is just tightly coupled enough to make people think twice before using something else. You certainly can use other view technologies, and it’s not really hard to do so (just do everything your other template system to produce a string or a file-like object representing the content of the response, and pass it as an argument to the Django response object you’re going to return).

   But neither the documentation nor the code for Django imply anywhere that other templating systems are just as good, just as suitable, or just as well-integrated into Django. The documentation mentions that you can use them, but only gives examples of the Django templating system. The code contains many shortcuts for using the Django templating system (e.g. render_to_response()) that can’t be used with other systems.

I think the latter point should really be emphasized more. The core Django developers like to talk a lot about how Django is loosely-coupled. And that’s sort-of true, and it’s a good thing. You don’t have to buy into everything to use Django. Django applications are just plain python code; they’re written not a special mini-language. But, Django is tightly coupled enough that there is only one obvious way to do it.

Here’s what I mean by that. In my work life, I’ve been learning a more corporate-friendly web development platform, the Spring framework for Java. Mostly Spring is a good thing. It manages to drag corporate web development halfway from J2EE-hell to Django in the same way that Java dragged corporate programmers halfway from C++ to Lisp. Once you get past the Enterprise Architecture Astronautics (not as bad in Spring as in other Java frameworks, because of the extensive use of interfaces rather than inheritance) and reams of XML configuration files (apparently significantly reduced in Spring relative to other Java frameworks!) it’s actually not bad, and developing for Spring MVC is very much like developing for Django while wearing mittens – you use the same patterns, but it takes twice as long to write.

But, the frustrating thing about Spring is that it is completely non-opinionated. How shall you do database access? They don’t care, and not only do they provide wrappers for the top 10 ORM systems as they’ll as plain JDBC, they support multiple completely different styles of using one of them, which require different layers of proxy objects and (of course) different XML configuration. And view technologies? They don’t much care which of those you use, either – pick one and use it. All this may make sense in an environment where the ORM layer and view layer can be mandated by corporate policy, but it’s no way to build a framework developers can be passionate about.

(Side note: for the templating language to use with Spring, I’ve settled on Apache Velocity. It is much like the Django templating language in scope, in that it interpolates variables and their properties, offers conditional constructs and iteration over collections, and so forth, but does not constitute an entire embedded programming language, or make it too easy to drop into the implementation language. Like Django’s templating language, it is a plain text language that is not tied to generating XML output. It doesn’t have two of the nicest features of Django’s template language, template inheritance and block substitution, but these are very easy to implement yourself by following certain conventions. Velocity is much closer to the templating sweet spot than JSP/JSTL.)

Django has been accused by passionate users of other Python web application frameworks of suffering from NIH Syndrome; or to put it another way, of being too opinionated. But the NIH components of Django (the ORM and the template system) provide very good implementations of that functionality for most of the target audience. If your needs are complex enough that you have to use something else, then you probably also have the skills to deal with the consequences (for example, SQLAlchemy can map existing databases that Django’s Models can’t – but if you use it, your app doesn’t get Django’s admin functionality, and probably can’t use generic views). So it goes. But the risks of being not opinionated enough are worse:

• The framework is harder to learn, because the documentation of different components may be spread across multiple projects, and new developers may have to learn multiple components in the same category in order to choose which best suits their project, instead of just diving in with a well-designed default.
• Different projects using the same framework will tend to be written in different dialects or subsets of the framework (e.g. Hibernate-Spring-Velocity vs. JPA-Spring-JSF).

So it’s not just that Django’s templating system hits the big bulgy middle of the bell curve, but that the project as a whole does. Opinionated, but not too opinionated. Enough salt to bring out the flavors, not enough to overwhelm them.

[ Posted: 09:56] | [ Category: /django] | Permalink | Comments: 3 ]

An older, more primitive world

So, does anyone else have the feeling, upon running ‘cmd.exe’ from a cygwin bash shell, that “you enter what seems to be an older, more primitive world”?

[ Posted: 19:21] | [ Category: ] | Permalink | Comments: 0 ]

Zenburn color schemes for Windows, Gnome

I like the Zenburn color theme for the one true editor, GNU Emacs. However, once you’re using it in one thing, you kind of want to have it everywhere. Here are a couple of simple Zenburn-like color schemes for MS-Windows (which I must use at work) and for Gnome (which I am proud to use at home).

It’s a low-contrast, dark theme for working in low-light conditions to avoid eyestrain. It’s not for everyone, and it’s not for all the time, but there are times when I need it.

[ Posted: 07:30] | [ Category: ] | Permalink | Comments: 0 ]

Installing Django as CGI

When Django was first released, it was only straightforwardly possible to deploy it using mod_python, for which it was designed. However, it also soon included an adapter for WSGI, the Python standard for web application servers to interface with web servers. The WSGI interface was combined with a WSGI-fastcgi gateway called flup to make it possible to host Django applications on FastCGI, and this support eventually became fully integrated with Django. FastCGI is as fast as mod_python, and is somewhat more commonly deployed, especially on commodity shared web-hosting providers.

It is also capable of running the Django app under a different user identity from the web server, either through a suexec wrapper, or by being explicitly started as a server process by another user.

However, while FastCGI is widely deployed, it is not universally deployed, and many hosting providers that support it do so poorly. This article explains how to use the Django WSGI adapter to run Django as a pure CGI application. Performance with this method is terrible, but it might still be suitable for low volume sites on commodity hosting, and especially given adequate caching. It is also a convenient harness for testing, especially for sites to be deployed as FastCGI, and it provides the same separation of privileges from the web server that Fast CGI provides.

Installing a Django project as CGI is very similar to installing it as FastCGI. These instructions presume the use of Apache 2.x. Put this script in your cgi-bin directory. It is derived from the example cgi-wsgi gateway in PEP 333. There’s a similar implementation in Django’s ticket # 2407, but I didn’t know about this when I started writing this note. (I don’t claim any great originality for this method; I just threw together existing components and banged on them until they worked.) Adjust the paths to match where you have installed your project (outside your document root, hopefully!).

Then, you install an htaccess file like this into your DocumentRoot:

This will redirect all requests under your DocumentRoot except for cgi-bin, media, and files that actually already exist, to your django cgi script. Again, you will probably have to adjust these paths for your own circumstances, and you may even have to add a RewriteBase directive or something as well.

Now test your admin app. Everything should work correctly, but slowly.

[ Posted: 19:30] | [ Category: /django] | Permalink | Comments: 2 ]

Lame Blog

Lame Blog is an under-powered, static content, C# and rsync based blog system. I don’t know much about it, as I’m semi-happy with PyBlosxom, and dislike C#, but it seems like a reasonable entry into the simple blogging software realm.

[ Posted: 14:05] | [ Category: ] | Permalink | Comments: 0 ]

NSA involved in Windows Vista

For those of you that still need a reason to switch away from Windows, the NSA, better known for warrantless wiretapping, was involved in the development of Windows Vista. NSA’s security expertise is supposed to make us feel more confident in Windows’ security, but, of course, their worrisome involvement in domestic surveillance is liable to make most of us feel the opposite. For those of you not wearing your tinfoil hats, you should immediately suppose that any security facilities in Windows have backdoors installed for NSA surveillance purposes.

(Via Bruce Schneier)

This comes on the heels of a cost analysis of Windows Vista content protection, which describes Vista’s CRAP (Cancellation, Restriction, and Punishment) system as “the longest suicide note in history.” Basically, Microsoft put Hollywood’s interests above those of its customers in a way that promises to be very, very intrusive.

If you want your computer to be working for you, rather than the NSA or Hollywood, you need to be using Free Software. There is no serious alternative. The easiest way for most people to start using Free Software throughout their computer is to download or mail-order Ubuntu Linux. Ubuntu is a user-friendly Linux distribution and will easily replace everything you currently use Windows and other non-free software for.

[ Posted: 20:18] | [ Category: ] | Permalink | Comments: 0 ]

SELECT … LIMIT n in Oracle

How to do the equivalent of PostgreSQL or MySQL’s SELECT … LIMIT clause in Oracle:

SELECT * FROM
  (SELECT ROWNUM AS limit, t.* FROM
      (SELECT my actual query with ORDER_BY) t)
WHERE limit <= 10;

No, it’s not very obvious. It should be pretty clear from that example how to do offsets, too.

[ Posted: 08:53] | [ Category: ] | Permalink | Comments: 0 ]

Clever Spammers

Had some interesting spam in my inbox that didn’t get automatically filtered today. The contents were pretty basic pump-n-dump stock spam (which seems to account for the majority of the spam I receive these days, filtered or unfiltered). The pump-and-dump spammers have been pretty sophisticated for a while about including chaff to get past Bayesian filters; it hasn’t worked very well, in general, but they’ve been working hard at it. The interesting spam today had the subject lines “troops should be”, and “Bush emphasized that”; the contents were their regular pump-and-dump pitch in mostly unobfuscated plain text. It looks like they may be counting on the flood of political mailing lists in this election season (and maybe just in the current political culture to provide camouflage to get them through filters. Or it could just be chance, and that was what got them through my filters. Anyway, it seemed clever, and I thought I would mention it.

[ Posted: 09:24] | [ Category: ] | Permalink | Comments: 0 ]

Stockphoto 0.2 released

I got impatient and decided to go ahead and release version 0.2 of stockphoto. This version introduces no new features, but it works with Django version 0.95 and other post-Magic-Removal versions. It also should be a little more tolerant of variation in settings variables, and so easier to install. Special thanks goes to William McVey for the initial work on porting stockphoto to MR, which I have finished and polished up for this release.

[ Posted: 15:00] | [ Category: /django] | Permalink | Comments: 0 ]

Blog upgrades

I’ve upgraded my blogging software to the newest version of PyBlosxom. This broke the comment plugin, so comments are not working for now. On the positive side, I now have my blog running on FastCGI like it should be. Hurrah! On another negative, I’ve had to disable the pager (doesn’t work under fastcgi). So, we’ll see.

Eventually I want to move over to a Django-based blog, but I need to be able to import all of my old entries, and I’d like to keep it filesystem-based rather than in a database. Hmm…

Update: Comments are fixed. Pager still broken. Trackbacks broken, but I’m not sure they ever worked anyway.

[ Posted: 09:09] | [ Category: ] | Permalink | Comments: 2 ]

FC5 packges for Quod Libet

Quod Libet is a very good music player, written in Python. I was having trouble with Rhythmbox (on startup it would hang and start consuming memory until it OOMed). I tried Banshee, but it doesn’t yet have support for internet radio, or for podcasts. Quod Libet is more complete than Banshee, and more stable than Rhythmbox.

It is also a very capable tag editor, and makes fixing inconsistencies in your music collection’s tags very straightforward. It is extensible with plugins in Python, though I haven’t looked into this very much yet. The one feature I am missing would be to write mp3 cds, which Banshee does, and which would be terribly handy for my cheap-ass mp3 player. Apparently there used to be a QL plugin for this, but it needs to be updated.

I have built rpms for Quod Libet and its dependencies for Fedora Core 5. They are in my yum repository. You will almost certainly also want gstreamer-plugins-good, gstreamer-plugins-bad, and gstreamer-plugins-ugly and their dependencies from freshrpms.

[ Posted: 08:15] | [ Category: ] | Permalink | Comments: 0 ]

Stockphoto 0.1 released

I’ve decided to release version 0.1 of stockphoto under the GPL. Stockphoto is a simple photo gallery application for django. There are better django photogalleries out there, so this is something of a wheel reinvention, but stockphoto is designed to be simple to understand and to install, with as few prerequisites as possible. Full instructions are included in the readme file.

[ Posted: 21:06] | [ Category: /django] | Permalink | Comments: 1 ]

Some django gotchas

These are some django details I’ve found while working on my django demonstration site, things that are useful for making an integrated Django-powered site, but under-documented.

Make “View on site” work

If you give your model a “get_absolute_url” method, the admin view for each object in that model will have a “View on site” link. However, and this is the clever bit, that link will not work. I’m not exactly sure why, but instead of linking to what’s returned by “get_absolute_url”, it links to something starting with “/r/”. However, by adding this to your site’s urls.py, Django will redirect to the correct location.

    (r'^r/', include('django.conf.urls.shortcut')),

Use the admin app’s javascript widgets on your site

The admin app has a lot of neat convenience features, such as magical calendar links after each DateField. Here’s how you get those in your app.

Put this in your urls.py:

    (r'^jsi18n/$', 'django.views.i18n.javascript_catalog',
                   {'packages': 'django.conf'}), 

And put this in your base template, in the <head> section:

    <script type="text/javascript" src="/jsi18n/"></script> 
    <script type="text/javascript"
            src="/media/admin/js/core.js"></script><script
            type="text/javascript"
            src="/media/admin/js/admin/RelatedObjectLookups.js"></script><script
            type="text/javascript"
            src="/media/admin/js/calendar.js"></script><script
            type="text/javascript"
            src="/media/admin/js/admin/DateTimeShortcuts.js">
    </script>

You’ll need to add some CSS styles to make things look nice; look in the admin media css folder to find what you need.

Generic views for login and logout

The Django authentication documentation is good enough to allow you to write login and logout views for your site. But in fact, there are already generic views for this purpose, which are not discussed in the generic views documentation.

Add to your urls.py:

    (r'^accounts/login/', 'django.views.auth.login.login'),
    (r'^accounts/logout/', 'django.views.auth.login.logout'),

And write templates. Mine look like this:

[Template Dir]/registration/login.html:

{% extends "base" %}
{% block title %}Site : login{% endblock %}


{% block content %}
<h1>Login</h1>
<form action="/accounts/login/?next={{ request.GET.next }}"
      method="post">

  <p>
      {%if form.username.errors %}
      <span style="color: red;">
        {{ form.username.errors|join:", " }}
      </span><br/>
      {% endif %}

    <label class="fortextinput" for="id\_username">
      Username:
    </label>
    {{ form.username }}<br/>

    {%if form.password.errors %}
    <span style="color: red;">
      {{ form.password.errors|join:", " }}
      </span><br/>
    {% endif %}

    <label class="fortextinput" for="id\_password">
      Password:
    </label>
    {{ form.password }}<br/>

    <input type="submit" value="Login"/>
  </p>

and [Template Dir]/registration/logged_out.html :

{% extends "base" %}
{% block title %}site: logged out{% endblock %}


{% block content %}

<h1>Logged out</h1>
<p>You have logged out successfully.  This makes you special!</p>
{% endblock %}

This, with login/logout links (wrapped with if user.is_anonymous) in your templates, is enough to do basic login/logout for your entire site. Staff users will be able to use this login to get to the admin pages, as well.

[ Posted: 08:35] | [ Category: /django] | Permalink | Comments: 1 ]

Getting the best font rendering possible on Fedora Core 5

Every time I upgrade between FC versions, the freetype library gets updated. Because Fedora doesn’t ship freetype with the bytecode interpreter enabled (for patent reasons), getting the best out of your fonts may require some changes. This time, rather than just recompiling the freetype RPM, I messed around a bit more with font rendering, and came to some conclusions.

If all your apps use XFT/Fontconfig

There are three hinting methods available in Fontconfig: none, bytecode interpreter, and auto-hinter. The bytecode interpreter would normally be the default, but Fedora compiles it out. However, the autohinter does a very good job, as long as your fonts are antialiased. Most people will use antialiased fonts whenever they can, and there are relatively few apps still in wide use that do not support antialiased fonts. If this is the case for you, you don’t need to install a new freetype library. Just turn on autohinting by adding this to /etc/fonts/local.conf:

<!–
  Use the Autohinter
–>
<match target="pattern">
<edit name="autohint" mode="assign">
<bool>true</bool>
</edit>
</match>
 

If some of your apps use X core fonts

The above isn’t good enough for me, unfortunately, because I still use some apps that use X core fonts (not antialiased). Well, only one, actually — GNU Emacs. While the auto-hinter is plenty good for antialiased fonts, it doesn’t provide the pixel-perfect hinting that you really need to work with non-antialiased fonts. Straightforward to do:

• Download the freetype SRPM from your local Fedora mirror.
• Install it, and change the first line in the spec file from
  %define withoutbytecodeinterpreter 1
  to %define withoutbytecodeinterpreter 0
• Rebuild from the spec file, and install the new RPMs.

Then you’ll need to restart xfs, and possibly restart X (‘xset fp rehash’ may or may not allow your programs to work).

Now make sure your core-font-using programs are using programs with good hinting, such as the Vera fonts or the MS Web Fonts. You should now have properly shaped, minimally jaggy non-antialiased fonts.

[ Posted: 20:12] | [ Category: ] | Permalink | Comments: 0 ]