The letdown
The other side of my absorption in programming iswhat I call 'the letdown'. The letdown is what happens when I reach theend of the project, when I emerge from my trance and realize that theprogram is basically finished. Oh, there's polishing and refinement andcleanup and documentation, but I'm done the building. I've successfullyput together what I imagined at the start, turned my dreaming and ideasand fancies into something concrete.
I've succeeded, and now I don
Using Django forms with HTTP GETs
All of the Django form examples anddocumentation that I've seen on the Django website (and in casualreading elsewhere) talks about using them for POST-based requests. Thisis the usual way to use forms in general, especially complicateddata-driven forms, and anyways the whole REST style prefers puttingthings in the actual URL instead of in GET query parameters. Butsometimes you really want to use GET-based forms; my case today waschanging the sort order of a table of data.
(I
On flow (a digression)
Recently I saw a blog entry ( via HackerNews ) from a developer whohad turned off the digital clock in his machine's menu bar; he advocateddoing this so as to reduce the potential of distraction from looking atit. What I took away from his entry, though, is the sure knowledge thatpeople are very different, because what he described doesn't apply to meat all.
You see, when I'm focused on something, when I am in a state offlow, the
Thinking realistically about SQL database field sizes
There is a certain sort of SQL database designer who cares a lot aboutthe micro-efficiency of their schema fields, and as part of this has adeep concern with minimum field sizes. These people want to know theexact size requirements of everything and specify the field sizes asthe minimum possible. If you have a table with graduate student numbersand graduate student numbers happen to be ten digits or less, they willspecify that field as ten characters. Period.
(They will probably make it a TEXT CHAR instead
My brute force email archive
Years ago, I had a brainwave about archiving my email. The brainwavewas simple: 'disk is cheap'. So I changed my .forward to save a copyof all of my email to a file, in addition to the other filtering I wasdoing with it. I don't point a mail client at the file or otherwise useit for anything in my regular email setup; it is purely a backup andcompletely separate from my regular email client.
(To be honest, it might have evolved
Dear Unix mailers: please allow more forgery
Here is a peculiar irritation I have with Unix mailers (the combinationof both MTAs and MUAs): I wish they made it easier for people to forgetheir outgoing email address, the address that appears as the From: and in the envelope sender and so on.
Unix mailers generally make it at least possible and sometimes easy todo a half-assed job of forgery. You can put in your own From: andmany mailers will leave it alone, but they'll then also add a Sender: header
A side note on Google Chrome and the future of HTML
In light of my earlier grump about the lesson of XHTML ,it's struck me that there is an interesting way to look at GoogleChrome. With lots of disclaimers, it goes like this:
If major browsers are the only people who really get a 'vote' onthe future of HTML (broadly construed), then one of the things thatdeveloping Chrome has done for Google is that it has bought it a seat atthe table of the future of HTML. No one can argue that Chrome is not
Why people put NFS mounts in subdirectories
One of the little pieces of Unix wisdom is that you should put NFSmounts (well, their mount points) in their own subdirectory. You don'tmount NFS filesystems directly in / , you don't mount them in adirectory with local subdirectories that you care about, and ideally youdon't mix filesystems from different servers in the same subdirectory.
(In other words, an ideal mount point is, say, ' What is Let's say it plainly: XHTML is a failure. It is broadly unsupported,barely used for real, and further standards work has been abandoned. (Yes, yes, there are lots of people with XHTML badges on their webpages. Many of them fail XHTML validation, and of those that validatealmost none are being served as XHTML. See here .) The real lesson that people learned from XHTML and its failure issimple: web standards are ultimately created by what major browservendors are willing to implement A commentator on my recent entry about learning from my Djangoschema design experience wrote,about me abandoning explicit primary keys: I'm not sure your data will be best served by giving up the databaseschema you want in deference to the conventions and limitations of the(Django ORM) framework. I want to clarify something: the issues in my schema that are drivingme away from using explicit primary keys and to surrogate keys are not Django specific. I've now designed two database schemas, one purely in SQL /nfs/
The real lesson of XHTML
My issues with primary keys are not Django specific
Menu