contact me
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. —Robert A. Heinlein
-
Sun Dec 7 11:21 pm, 2008
I had a few days off, which was pretty amazing. Although I was sick much of it (great timing!). But I did get to leisurely do SitePoke which is an old monitoring script I rewrote and created a front end for in Django. While I've got a decent amount of Django experience under my belt, it was on a long term project, so doing something small in a couple days was actually pretty fulfilling -- and reminds me that yes, as a framework, Django does kick some ass. In fact, I think I spent longer trying to get xml structured for some pretty flash graphics than the rest of it. So, the site's open if you want to give it a try, given any more time I'll add some functionality to it, particularly the difflib data I'm doing on returned pages (how much has a page changed, and what has changed over the last few pokes, etc.). Oh, and I did the whole thing on my Eeepc ;)
-
Wed Dec 3 11:56 pm, 2008
Python 3.0 (a.k.a. "Python 3000" or "Py3k") is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places. Have I ever been excited about a backwards breaking release before? Just goes to show that as a language Python tends to get it right, I hope it continues -- here's what's changing.
-
Mon Sep 8 5:30 pm, 2008
Djangocon was a lot of fun. Held at building 40 in the Googleplex this past weekend, they limited the con to 200 people. And I think the majority of those 200 people each made the following joke at some point:
* a PHP scaling joke
* a Zope usability joke
* how long it took Django to get to 1.0
The few who did not make these obligatory jokes were forced to rewrite Lawrence Journal World in Extreme Programming Perl and are no longer allowed to wear t-shirts with the Pownce logo.
There were a couple fantastic talks (Flickr's Cal Henderson for instance), a few decent ones, some really well done lightning talks, and what felt like several (one explicit) "I want a pony" sessions where everyone asked for what they'd like in Django. Team Onion's requests were for a real object cache with proper validation/invalidation, singleton, a killer set of debug tools. Most of which we and others are already working on. Perhaps the most popular overall request was for multi-database support.
Everyone was blown away by GeoDjango, which does a fairly amazing and complex set of geo-calculation, utils, and packaging of disparate geo libraries into a really usable system.
I got to meet all the folks I'd seen committing, and arguing about code, and a few more who were all really nice and excited about Python and Django. The level of intelligence in the room was overwhelming.
I don't know if Django is still flying under the radar, I mean Google is using it, but it still feels like it's flying under the radar -- and that is a good thing I think. It's a relatively small group of folks, and there wasn't much of the kind of discussion you would've seen at a Linuxcon in the late 90's when suddenly it was 'discovered' and hence, 'monetized' by companies and labeled 'enterprise'. While we would like a high performance Django group, it's not what you'd associate with business 'enterprise' software. I'm all for keeping the enthusiast element as long as possible before business concerns move in. And I wonder if part of that security about being community driven rather than business driven is actually due to Google, at least this last year, sheltering Django from the less desirable elements or circling sharks. But, also, Django made itself into a foundation in June, and the core is under a simple BSD license, so once again they're being super smart.
As an aside, I also realized quite demonstrably -- and I really need to put pretty radius graphics up on Google maps around my continually updated geolocation to visualize this -- that I am the only person who has visited Mountain View or San Francisco who does not own an iPhone. Do you know what it's like being surrounded by a couple hundred people all on iPhones? It's like watching kids gorge themselves on candy at Halloween. How did they let me in? Did I sneak by the iPhone checkpoint somehow? Shrug. "Think Different". -
Fri Aug 22 8:30 am, 2008
Techworld talks to Guido in their "The A-Z of Programming Languages" series. He's always good in an interview I think, but every single interviewer apparently asks whether he uses tabs or spaces, or at least questions the Python indentation style. Without a doubt, when you say you work with Python to other developers it's one of the first things they mention: either with a confused slightly derogatory shake of the head, or, with a sigh of relief. I fall in the sigh of relief camp, since I haven't had a bracing style argument in about a year. That using Python requires a certain visual structure seems to me a pro rather than a con, since it removes a particular distraction potential. Ever have a two day conference just about coding style? Yeah, not fun. I wasn't building anything those two days, needless to say. Now, you can still get your geek on and argue tabs or spaces (I'm back to spaces after a brief sojourn to the dark side of tabs), but you've got to indent properly for Python to work, end of story, and hence sigh of relief.
-
Thou Shall Not Monkey Patch OR Duck Punch
Fri Jul 18 9:00 am, 2008
The older I get the less I want to re-write code, particularly other peoples' code, whereas I used to do this with zeal. I'm certainly not going to OCD on retabbing it, and I'm even less inclined to monkey patch something core for sake of cleverness and impatience. I don't want to prove anything, I just want to make code that works in the most stable, least interesting ("interesting" code tends to be a pain in the ass but that's another post), most readable manner I can. I don't want to create my own language, and I don't want to redo yours, especially at the highest, least visible level. Here are some excellent comments on monkeypatching from one of my favorite sites, CodingHorror (and yes I did just CamelCase your site name).
Application-level plugging ala Rails is good. Language-level plugging in Gems, no matter how well-documented, is usually bad.
I have enough trouble debugging my own crappy code without trying to debug someone elses if they've changed some of the fundamentals of the language!
That "monkey-patching" is a more perjorative term to Pythonistas than to Rubyists has a lot to do with the culture surrounding the languages, obviously. But, I've noticed an interesting coincidence.
Black-magic metaprogramming in Python produces code with lots of __dict__'s and __class__'s, dunders and quoted identifiers in it. Its appearance just screams "I am rewiring my microwave and voiding the warranty," and is just generally quite visually distinct.
On the other hand, Ruby metaprogramming code just looks like any other Ruby code, unless you're paying particular attention to what methods it's calling. It doesn't "look" out of the ordinary.
I wouldn't be surprised if one didn't have something to do with the other :)
most monkeypatching done is made out of sheer demonstration that they know metaprogramming (especially for ruby). i find it less smart to instantly resolve to monkeypatching the language itself rather than extending it within the application or its library.
-
Thu Jul 10 10:56 pm, 2008
So I wanted to get the request object into the django model system so that I could create a model manager that would automatically use a get_query_set to filter a model based on request conditions. Thinking that yes, I could do it in one place, rather than in all views do a:
class SomeModelManager(models.Manager):
def get_query_set(self):
return super(SomeModelManager, self).get_query_set().filter(somefield=some_conditional_request_data)
Wasn't it django-esque to attempt this? Yes and no. It may have been django-esque to think I could easily change the application in one place, but it sort of goes against the django model to think that anything having to do with a view, an HttpRequest, would feed into and conditionally change the model (not just use filters on an instance model but the actual model itself). And I respect this sort of curmudgeonly refusal to easily mutilate oneself -- in looking around all I found was this. Which is definitely not something I want to have in a large application. So really the answer is better planning, plan to process the request properly and deal with a call to the model with filters within the view, and keep Poppa model all nice and pristine and untouched by the outside world. -
Wed Jul 9 6:50 pm, 2008
How many times have you had to sanitize some html? Or write something that scraped data from html? Or tidy given an absurd number of cases? Or parse and strip, replace or introspect some html? It's an extremely unsexy task guaranteed to be overlooked in favor for some javascript or flashy whizbang that gets clients or bosses all excited. But it is, IMHO, precisely the sort of basic plumbing task that has to be done, and done properly. I'm gonna start a show, and that show will be called "Dirty Jobs: Programming". Hey, nobody's interested enough to follow along, so you can get it done anyway you like, BeautifulSoup will, in so many words, save your ass. It's these sort of real base line tools that will save you time -- rewriting these kinds of tasks over and over again just becomes mind numbing and unproductive, so when you find one that does the job, pass the word along.
-
Wed Jul 2 11:14 pm, 2008
I've heard and felt the laments often of dealing with complex time issues, Python aside. But if you are dealing with time in Python there are modules to help you, python-dateutil and/or pytz, and if at all possible start with and store UTC. UTC is your friend. The comparison to a local timezone afterwards will be easy, and you won't have to worry about issues like DLST. Understand that you will need to create a datetime object with a proper timezone if you want to do anything complex with time and time comparison.
-
Thu Jun 19 7:00 pm, 2008
The last few years my day to day experience has been Subversion, but I keep getting glimpses of Bazaar and how Bazaar is to Subversion as Subversion was to CVS. (Jesus, who uses CVS anymore?) MySQL, apparently, has moved to Bazaar.
-
Wed Jun 18 7:30 pm, 2008
So I guess the headline should really be: "REDDIT Goes Open Source! Must See PICS! (NSFW)". Looks like they're basing their code on Pylons. Which certainly isn't a terrible framwork -- I personally had trouble with setup when I was trying it about a year ago, I'm assuming they've made progress. I like the general idea, although I'm still for Django (although insert my general custom form creating gripe here) -- perhaps I should give Pylons a second look. The fact that more folks out there are using python for web work, and without the overblown hype that RRails gets is encouraging to me.
-
Tue Jun 17 6:40 pm, 2008
Django 1.0 is slated for Sept 2. Although I'm on Django every day, I'm less excited about this than I was about the queryset refactor merge. This is about stating a big round number, the majority of pieces seem to already be in place. For all that is good about Django (and there is much) sometimes newforms makes me want to tear my hair out -- and in particular having more control over admin forms will be nice. Looks like Django is now a foundation as well.