Monday, February 21, 2011

mysql rocks

No, I don't mean the MySQL server, about which my feelings are still very mixed. I'm still very keenly looking forward to moving to PostgreSQL. I mean mysql, the command-line client.

It's awesome! All those features that I've been gradually adding to sqlpython - at the cost of slow execution, and with my personal late-night bad quality control - most of them have been in mysql for years. Flexible output formats, easy interaction with the OS environment, and so forth. A fat toolbox of goodies.

So, how about this, Oracle? Oracle SQL*Plus has been neglected and underpowered for ages. It can't hold a candle to the mysql client for features. Why not assign a few programmers to extend the mysql client so that it works with Oracle as well as MySQL? Why should the world have to deal with a different client program for every database back-end? I can really imagine mysql evolving into the One True SQL Client.

Finally, I have to praise the MySQL Cookbook from O'Reilly. For somebody moving to MySQL from another database, it's the only way to fly. Almost all MySQL books I've seen assume that it's your first database, and spend 90% of the text explaining SQL fundamentals. Based on my happy experience with the Python Cookbook, I thought the MySQL Cookbook would do better, and I was right. It cuts straight to the stuff that isn't obvious but is very, very useful.

MySQL Cookbook cover
(Hi. Yes, I've been quiet. Yes, I love the new job. Yes, it's a lot of work, particularly during this learning-the-ropes phase.)

Wednesday, November 10, 2010

Have you seen the elephant?

In case you're wondering, my upcoming work for KACE doesn't imply that I'm leaving Dayton. Like most of my coworkers, I'll work for KACE by telecommute. It's enormously flattering to be offered a position when the competitors for the job are potentially anybody on the surface of the earth. (Anybody who's interested in a Dayton jelly or telecommuters' club, let me know.)

That's good, but honestly, it's not the aspect of the new job I'm most excited about. It's this.



I'll migrate an important MySQL database to PostgreSQL and become its caretaker. I don't expect to use Oracle at all in the new job (though I'll stay active in the local Oracle community, and do some personal Oracle projects just for fun). Basically, I'll be a full-fledged PostgreSQL DBA.

Oracle has been practically a part of my identity for years, but those who have paid close attention have noticed me sighing in longing for PostgreSQL for years, too; I've said more than once that I'd drop everything to work full-time with PostgreSQL. I didn't think it would ever happen, since Dayton's main employer (the Air Force) has a strong prejudice for proprietary software. But, thanks to KACE, the impossible finally happened.

It's a funny coincidence - but yes, a coincidence - that this happens during a downswing in relations between Oracle and open-source communities; many F/OSS lovers are upset about Oracle's decisions since acquiring Sun. For me, though, it's not a matter of techie politics; PostgreSQL is simply a wonderfully-written database and a joy to work with.

As my relationship with PostgreSQL matures from a clandestine affair conducted at night to a full-time committed relationship, I'm sure we'll get past the honeymoon period and have some arguments, like any couple. Even the best software is still software, after all, and human-software relationships always have their difficult moments. Still, I'm enormously excited to begin this new phase in my love of free software.

Hmm. "PyOraGeek" might not be the most accurate subtitle anymore, but "PyPostgreSQL geek" violates uniqueness constraints in a big way. The rebranding is the hardest part...

sqlpython 1.7.2

sqlpython 1.7.2 has been released! Install it, pretend that your Oracle/PostgreSQL/MySQL database is a UNIX filesystem, and have a blast.

This release doesn't really add any new features. However, it does clean up the sluggishness in metadata operations (like ls and desc) and the major outright bugs that were making sqlpython frankly unusable for an embarrassing number of months.

Sorry for the wait! Hope you'll find the new sqlpython worth it. Functionality for PostgreSQL and MySQL are now fully-fledged, with some relatively minor exceptions (like image BLOB displays). Furthermore, my upcoming position guarantees that the sqlpython/PostgreSQL will get lots of love in coming months.

Monday, November 08, 2010

Moving to KACE

For almost ten years, I've worked for IntelliTech on contract at Wright-Patterson Air Force base. IntelliTech has been a very supportive employer, and my government boss at WPAFB (Ralph Ranard) has been an absolutely amazing supervisor; that's why I've been there so long.

This month, though, an opportunity has come up that I absolutely can't resist. I met Mike Gray and Tyler Gingrich of Dell KACE at Columbus Code Camp, which KACE sponsored partially to make contact with potential employees. (This, incidentally, shows excellent management right there. If you want skilled and passionate geeks, do you hire a recruiter to try to read the tea leaves of the self-promoting buzzwords of a huge stack of resumes? Or do you go to where the most passionate geeks congregate all on their own?)

Everything I've seen about KACE delights me so far. It's a subsidiary of Dell that has intentionally retained its startup spirit since its acquisition. Technical decisions are made by technical people for technical reasons - in other words, people are allowed to use the expertise they were hired for. (I know, that shouldn't be exceptional.) It's got a developer-centered culture that is a huge breath of fresh air. It's friendly to newer technologies and very friendly to open source. For example, I'll be taking over an important database currently in MySQL and migrating it to PostgreSQL. (Getting somebody to pay me for working with PostgreSQL has been a dream of mine for years...) And of course I'll be using Python. I'd wait tables before taking a job with no Python.

During my entire process of interviewing with KACE, it never felt like "job interviews" - those nerve-wracking, superficial, semi-adversarial dances described so depressingly in career publications. Rather, it felt like some long conference-hallway conversations between geeks - very real and very techie.

So... hello KACE! I'm delighted to join you!

Monday, October 18, 2010

Camping in Ohio

This Saturday was the Columbus Code Camp, and I have to say I was really impressed. The quality of the talks - and the audiences - was excellent, and it was a nice broad set of interesting topics. Mike Reed and the other organizers should feel great about putting together such a good event, especially for its maiden voyage. I look forward to it as a regular event.

My talk slides and materials are the same as the Ohio LinuxFest versions. Thanks to my audience for the great questions!

Next weekend comes the Southwest Ohio GiveCamp, a big hackfest to rapidly produce software for area nonprofits. I've never been to a GiveCamp before, and I'm really looking forward to it; I've heard great things from people who have participated before. Python folks, step forward - I want to make sure there are enough of us to form at least one strong team writing Python-based software.

Scheduling of tech events is an interesting topic. If it's held on a weekend, you know you're getting genuinely passionate professionals, people who want to spend their own time learning new things and improving their skills. If it's held on a weekday, you know you're getting people who work for smart companies that value their employees' skill and know that user-driven events are a great (and cheap) form of training... as well as a few attendees who are so hard-core that they'll actually take their own vacation time for learning. Either way, it reveals a lot about which people and employers are really dedicated to being and staying sharp.

Monday, September 13, 2010

pdb with Sikuli

As I mentioned in my last post, the big barrier to debugging a Sikuli script with pdb is that, when you enter a debugging command like "next", "continue", etc. that is supposed to allow program flow to continue, you are in the debugging console window, and your Sikuli script will send the keyclicks and mouse actions into the debugging console window instead of the application your script was supposed to be driving.

Here's a minor modification to pdb that can change that by using Alt-TAB to switch back to the application window every time program flow moves from the debugger to the application. Save this code as sikpdb.py in the Lib directory that you unzipped Sikuli into, for example, ~/Sikuli-IDE/Lib. (/Lib is not created by default, but it is the first item in sys.path.)

#! /usr/bin/env python

"""A Python debugger.

A slight modification of ``pdb``; attempts to switch
screen focus back to the invoking app before running commands
in the program being debugged. This should prevent Sikuli
commands from being "typed" or "clicked" into the debugger
window when they should go into the window of the app being
debugged."""
# catherinedevlin.blogspot.com
# (See pdb.doc for documentation.)

import pdb
import sys

class Pdb(pdb.Pdb):
def _to_running_window(self):
"""Moves focus to the window a Sikuli script was running
before the debugger was invoked, so that subsequent commands
will act in the app instead of the debugger."""
self.onecmd("SCREEN.type(Key.TAB, KEY_ALT)")

def do_step(self, arg):
self._to_running_window()
return pdb.Pdb.do_step(self, arg)
do_s = do_step

def do_next(self, arg):
self._to_running_window()
return pdb.Pdb.do_next(self, arg)
do_n = do_next

def do_return(self, arg):
self._to_running_window()
return pdb.Pdb.do_return(self, arg)
do_r = do_return

def do_continue(self, arg):
self._to_running_window()
return pdb.Pdb.do_continue(self, arg)
do_c = do_cont = do_continue

def set_trace():
Pdb().set_trace(sys._getframe().f_back)

Now, at the point in your Sikuli script where you want to enter the debugger, insert
import sikpdb; sikpdb.set_trace()

Also remember that you need to add -Dsikuli.console=false to your .sh or .bat script in order to allow pdb input/output to appear in the console window you used to invoke Sikuli. Otherwise, Sikuli will just hang when you attempt to enter the debugger (it's waiting for your input - in some nonexistant interactive session). For instance:
$ cat sikuli-ide.sh
#!/bin/sh
DIR=`dirname $0`
java -Xms64M -Dsikuli.console=false -Xmx512M -Dfile.encoding=UTF-8 -jar $DIR/sikuli-ide.jar $*


The remaining problem is that sikpdb.py depends on the notion that ALT-TAB will reliably return you to the application's window. This is true, but only if you do not browse around among your open windows while in the debugger; if you do, you'll change the z-ordering of the windows. It would be more reliable to call switchApp() with the title of the application's window, but I don't know of a cross-platform way to automatically detect it - the best I can think of would be to manually pass it as an argument to set_trace, have set_trace store it in an instance variable like self._application_window_title, then call self.onecmd("switchApp('%s')" % self._application_window_title) in place of self.onecmd("SCREEN.type(Key.TAB, KEY_ALT)") . It's more complex to use, but more reliable... feel free to use that approach if you prefer it.

Sunday, September 12, 2010

Sikuli talk follow-up

Thanks to everybody who made time in a busy Ohio LinuxFest schedule to make it to my talk on Project Sikuli! I appreciated your attention and your questions.

You can browse my slides at http://catherinedevlin.pythoneers.com/presentations/sikuli/sikuli.html, and/or download a tarball with all the code demonstrated at http://catherinedevlin.pythoneers.com/presentations/sikuli.tar.gz

I promised to follow up on the questions that stumped me, so here are the first couple answers...

- I mentioned how debugging with pdb is difficult because switching to the command-line window to interact with pdb interrupts the program flow, and when you issue a "continue" in the debugger, your Sikuli script will barrel along in the command-line window with the debugger instead of in the application you wanted Sikuli to drive. A couple people suggested debugging the script from a remote machine, connecting with pdb and attaching the debug process to the Sikuli process. I still don't know whether that's possible - definitely maybe - but I realized that there's a very simple remedy that I feel silly for not suggesting before.

In your Sikuli script at the point you want to enter the interactive debugger, instead of simply inserting import pdb; pdb.set_trace(), insert import pdb; pdb.set_trace(); switchApp('Window Title Of The App I Am Debugging') - that should put the script you're debugging back on track.

EDIT: WAIT - I got this wrong - this doesn't make sense. You do need to switchApp() back to the window your script was running in, but not immediately after invoking pdb.set_trace(); rather, it needs to be invoked just before running pdb.next, pdb.continue, etc. I think the right way to do this is to subclass pdb; give me a bit to produce and test something like that.

- I confirmed that there isn't yet a "Recording" mode, or anything to automatically translate your actions into Sikuli commands. Really, though, I'm not sure how much that would help - writing the Sikuli commands is actually the easy part of the automation. The hard part is figuring out precisely which actions to take to get the effects you want most reliably.

OLF was really good this year. I especially enjoyed the hallway track - met lots of really interesting people that I need to follow through with on some neat ideas. The exhibit hall was a great place for PyOhio folks to meet new people and connect them with the Python community - thanks so much for all the PyOhio crew who came out to staff the booth! Thanks to the organizers for all their work!

Thursday, September 09, 2010

Quran troll

Ian Bicking hit it right on the nose: this Quran-burning pastor is a troll, no more.

Arguably, I shouldn't even be posting this. Trolls should be ignored. The trouble is, even internet-savvy people have trouble living up to that prescription. The world as a whole definitely doesn't know what to do about trolls. There are already people in Afghanistan holding demonstrations because of this troll... so I feel like "just ignore it" maybe isn't enough right now.
John Shimek: The best suggestion I have heard it to ignore it and donate towards the Pakistan flood relief.
Very good. But I'm wondering if one step further would be a good idea: an explicit linkage. You know, "I pledge a $x donation for Pakistan flood relief for every copy of the Quran burned." Isn't there a webservice out there that facilitates making this sort of pledge? Help me out, lazyweb - this should happen fast if it's going to happen.

Granted, Pakistan flood relief shouldn't be an issue of the victims' religion one way or the other, so there's something a little odd about using it as an anti-bigotry statement. And maybe this does amount to feeding the troll. But at least it would feed some real-live human beings at the same time. It's the only way I can think of to turn this stupidity into something good.

And, if you can permit me just one little troll-foodish comment...

To be an a**hole is one thing. (I really struggled to find another word here. This time, though, it really is the only word.) But to say, "It's not me - it's God who's the a**hole, and I'm just obeying him"... I don't understand how anybody can say that without being 100% flat-out certain that there is no God. Why would anybody take the slightest chance of ever standing before God and having Him say, "Could you repeat that to My face, please?"

Saturday, August 21, 2010

Setting the turtle free with Sikuli

Have you played with turtle graphics? I enjoyed Logo ages and ages ago. Nowadays there's a turtle module in Python's standard library, plus several other implementations.

But all the implementations I know of keep the poor little turtle stuck inside a dull little window. Last night I realized that, with Sikuli, I can set the turtle free! It can roam freely beyond one little window and have adventures in the big, wide world. Here it is marching right past the edge of TuxPaint and onto GNU Paint.

Note that this is an invisible turtle. But you can see its effects.

For the new free-range turtle, "penDown" and "penUp" are actually "mouse button down" and "mouse button up". If it's walking across a drawing program with a paintbrush turned on, it will paint a line like a traditional Logo turtle. Otherwise, it will click and drag its way across your desktop and your other applications. This turtle can be mischievous!

What really pleased me was just how easy it was to implement with Sikuli. Here's the code in an .skl bundle - it's a zipfile that Sikuli can use directly.

import math

class Turtle(object):
def __init__(self):
self.heading = 0
self.penDown()
self.loc = Env.getMouseLocation()
def forward(self, distance):
sin = math.sin(math.radians(self.heading))
cos = math.cos(math.radians(self.heading))
endpoint = (int(self.loc.x + cos * distance),
int(self.loc.y + sin * distance))
if self.down:
dragDrop(self.loc, endpoint)
else:
mouseMove(endpoint)
self.loc = Location(*endpoint)
def backward(self, distance):
self.forward(distance * -1)
def right(self, degrees):
self.heading = (self.heading + degrees) % 360
def left(self, degrees):
self.right(-1 * degrees)
def penUp(self):
self.down = False
def penDown(self):
self.down = True
def circle(self, radius, extent=360., steps=20):
circ = 2 * math.pi * radius
fraction = extent / 360.
step_length = (circ * fraction) / steps
for i in range(steps):
self.forward(step_length)
self.left(360. * fraction / steps)

def zigzag(startHeading, size, angle, steps):
t = Turtle()
t.heading = startHeading
t.left(angle * 0.5)
for i in range(steps):
t.forward(size)
t.right(angle)
t.forward(size)
t.left(angle)

Tuesday, August 17, 2010

gmail filter appender with Sikuli

Gmail filters are great, but I've got some filters that apply to a hundred different senders - and I'm always adding new senders to them. I've wished for an automated way to add the sender of the message I'm currently viewing to one of my filters.

I'm sure this could be done in Greasemonkey, Selenium, etc., but Sikuli is my tool of interest for the moment - and, after some fumbling, I'm really happy with it.

A partial screenshot, just to give you the idea:

View the Sikuli code, or download it and run it with /path/to/your/sikuli-ide.sh spammy.skl - except you'll probably want to edit the keywords identifying your filter, and possibly recreate the graphics to match your own Firefox theme. Mostly, it's there as an example to learn from.

I'm learning plenty that will go into my Ohio LinuxFest talk, but the big lesson for today is to rely on keyboard-based and text-based techniques rather than picture-finding whenever they're available. For instance, how should I click a button that might have scrolled off the bottom of the screen? There are lots of ways - I could embed find() in a loop with type(Key.PAGE_DOWN), for example - but it's more reliable to piggyback off Firefox's "Find" to zoom in on the text on (or near) the button and then find it.

Wednesday, August 11, 2010

Sikuli at Ohio LinuxFest

And now, for my next trick, one month from today, I shall demonstrate how to script virtually any program with a GUI... without touching an API! (audience gasps)

If You Can See It, You Can Automate It: Sikuli
Your computer should save you from doing tedious and repetitive tasks yourself, but automation programming has been too difficult for casual uses. MIT's Project Sikuli changes that. It fuses traditional text-base scripts with actual screenshots of targets on your screen, making programming simple, versatile, and useful. If you've ever told a friend, "Go here, now click on this, then on that", you know enough to start using Sikuli. Let Project Sikuli shake up your notions of what programming is like.

I'll be spending most of this month using Sikuli to build a test suite for a complex GUI app at work, recording the pain points as I go. I'd also appreciate your questions and comments about Sikuli - I may be able to work them into my talk (or at least be prepared when they're asked from the audience.)

Ohio Linux Fest, Sep. 10 - 12.

Sunday, August 08, 2010

"Many Eyeballs" - HA!

Oh, yes, I feel I should record this little incident from PyOhio 2010, for the sake of evidence during Nick's trial.

I used PyOhio's Lightning Talks to give away our swag prizes; and, in the spirit of open-source, I put the code on the projector for everyone to see.

import csv
import random

regfile = open('registrations.csv')
reader = csv.DictReader(regfile)
registrants = list(reader)

def pick():
winner = random.choice(registrants)
return '%s %s' % (winner['First Name'],
winner['Last Name'])

Then I realized that I didn't have the Lightning Talk sign-up board, so I went out into the hall to get it. I was gone maybe 60 seconds. When I got back, I called pick() and got... Nick Bastin!

The room giggled. Nick said, "Wow, that's the first time I've written bug-free code on the first try!" I didn't get it, so he said, "Why don't you pick another winner?"

Nick Bastin!

The nice thing is, my code was intact. However, this was lurking in my directory.

$ cat random.py
def choice(foo):
return {"First Name" : "Nick", "Last Name" : "Bastin"}

The lesson here is: Many eyeballs can help protect you from malicious code... unless they're all in on it!

PyOhio 2010 review

My own PyOhio 2010 wrap-up post is highly suspect, because I'm probably not one to deliver an unbiased opinion. So, when I say that

IT WAS AWESOME

you can be forgiven for being a little skeptical. In fact, one of my few regrets is that I didn't collect firm, objective data on just how awesome it was. I don't have accurate numbers on attendance yet - our sign in sheets are, um, somewhere around here. We had 179 pre-registrations; subtract some no-shows, add some walk-ins, and you get... I don't know. But the place was bustling!

The talks were good, and more importantly, they stimulated some excellent informal activity. The Open Space activity was stronger than ever this year; some of them packed our Open Space rooms to the walls. There were a fair number of Python newcomers there - yay! - and I was glad that we had a good Beginners' Track for them. An After-Hours Board helped people coordinate some evening fun together. Overall, it was not at all just "a place to see talks", but a full immersion in the awesomeness of Python people. Of course, the sprints were the big after-hours event, but they deserve their own post (soon to follow).

OSU's new Ohio Union was a great locale. It helps a lot that it has a design and a staff specialized in holding meetings and conferences, and it's just fantastic that the OSU Open Source club was able to provide the space at incredibly good rates. We look forward to using virtually the same space next year, with just some minor tweaks.

And, for everybody who wondered how we put on a great show at no charge... thank our sponsors!
  • Microsoft
  • Intellovations
  • AGInteractive
  • Dayton Microcomputer Association
Anyway, I'm delighted. I had fun and learned a ton. I hope you did, too! Thanks so much to everybody who took part!

Here are a couple other wrap-up posts I've happened across. Let me know about others you find.

Alex Gaynor
William Chambers
Richard Harding

Wednesday, July 28, 2010

PyOhio: photos plz

We have 138 PyOhio registrants so far - that's greater than the total number of attendees last year. I'm excited!

Is there a shutterbug in the house? I'm always envious of the photos taken at some conferences, like this one of Python core sprinters at EuroPython. (Hi, guys! Our contribu-palooza-ers will be joining you soon!) I want to join the fun. Our PyOhio attendees are just as pretty as any of them!

So if you enjoy taking pictures, and you're coming to PyOhio (and who wouldn't?), please don't forget your camera! Get some group shots, and let me know about them afterward. Thanks!

See you Saturday!

Friday, July 16, 2010

PyOhio

PyOhio staff badge
We are 15 days from the third PyOhio, and I am so excited... My first hope for PyOhio was that it would become a little slice of PyCon-ish goodness in our region... we've definitely accomplished that. This year we're adding on some very serious sprinting that, I think, will make PyOhio an important part of the Python scene not just here, but worldwide.
  • The Android Scripting Workshop has the potential to make Python-lovers of a whole new class of people who wouldn't even call themselves programmers (yet)... people who love their powerful Android phones and will love them even more once they learn the power of scripting on them. One question I'd like your advice on: how do we let these people know about the workshop? They're not reading my blog, after all...
  • The Contribu-palooza is a set of linked events (a classic talk, a "Teach Me" talk, and a big fat sprint) designed to make you into a contributor to the Python language, starting from nothing - we supply the motivation, the skills, and then the hands-on practice. I'd like to see this produce both an immediate new set of Python contributors (including me) and a new way of bringing contributors in.

I hope to see you there!

Friday, July 02, 2010

talking with women

A man at a conference I was at a couple months ago approached me to talk about databases.

It was, in all ways, a good and appropriate conversation, and an example of the reason I go to conferences like that in the first place. But he later confessed to me that he'd been very hesitant to speak to me because he was afraid it would come across as cover for some kind of flirtation. It seemed ridiculous, because he was so far from anything inappropriate, but his uncertainty came a hair's breadth from actually diminishing the conference's benefit to both of us.

You see the big fat irony. Avoiding sexualizing a woman's professional environment is an absolutely appropriate and important goal. But sidelining women from a professional community's social aspects is genuinely harmful.

Most men can easily judge for themselves the difference between friendly and creepy, but geekdom is infamous for its high proportion of the awkward.* I'd love it if there were a really clear and well-known rule of thumb that would assure even the most shy and awkward guys about where "the line" is. The hard part is that men differ so widely in their judgements and self-judgements. Some will be critical or suspicious of themselves at virtually anything, and some find excuses for even the most egregious of their own behavior. It's hard to know how to encourage the former but not the latter.

My first thoughts -
  • Imagine that she were a man. Would you still do or say what you're doing or saying now, or would it feel too awkward?**
  • If you're genuinely worried about it, you're probably not a problem guy in the first place.
What are your thoughts?

* - Understand that, when I say this, it's with affection. I love the socially awkward! I find communities where everybody adheres smoothly to a single social standard to be boring and uncreative. I hope geekdom will always be a haven for the awkward.
** - Obviously not a very useful standard for bisexual people.

Thursday, June 10, 2010

Dayton Dynamic Languages User Group

In Dayton, we don't have a dedicated Python user group; instead, we have the Dynamic Languages User Group. I always struggle to explain why I enjoy this group so much, because a quick description doesn't sound that impressive. Each meeting is 5-10 people scattered across the entire dynamic language landscape: Python, Ruby, Perl, JavaScript, PHP... now and then somebody will throw in some LISP or whatnot. There's only occasionally a formal presentation.

Instead, there are people who are very open about sharing both what they know (which is impressive) and what they don't know (which is more important). I've never been in a group where people are more uninhibited about saying, "Wait -- I don't get it." As a result, everything we do gets enriched by some extremely good discussion.

When we don't have a formal presentation, we sometimes walk through a code project somebody's working on, or research a programming topic together (like dependency injection). Recently we've started publishing a simple programming problem and asking the members to bring a solution in their favorite language - reviewing the various solutions is a nice exercise in both language details and programming approaches.

Come see us sometime. We meet the second Wednesday of the month at 7:00 PM at the Dayton Chess Club.

Wednesday, June 09, 2010

On the error message soapbox again

Q. What's wrong with this message?

Database Configuration Assistant: Info - There is an error in creating the following process: /data/ora/oracle/product/11.2.0/dbhome_1/bin/sqlplus -s -N /NOLOG  The error is: /data/ora/oracle/product/11.2.0/dbhome_1/bin/sqlplus: error while loading shared libraries: /data/ora/oracle/product/11.2.0/dbhome_1/lib/libclntsh.so.11.1: cannot restore segment prot after reloc: Permission denied
A. The window that it pops up in doesn't support copy-and-paste (on Fedora 13, at least). If you want to websearch for this message, you have to type it in by hand.

Hey, Oracle - fix it, please? It's the sort of usability problem that I wouldn't nag you about if you were a little FOSS project or a mom-and-pop software shop, but you're a big company with fifty bazillion programmers and entire committees on usability, so I know you can do it.

I'm sure that's the fault of whatever Java GUI library underlies your graphical tools like dbca... so go on and fix the library, and the whole world will benefit!

Also, in keeping with my fixation with good error messages, I implore you to think about error message usability ahead of time. I suspect that error messages get the short end of developer attention because they never appear in sales presentations. Well, actually, they do appear in sales presentations, they're just not supposed to... (although, frankly, watching somebody work through an error is a million times more interesting than watching a polished sales pitch)

Q. What else is wrong?

A. The workaround to this error is to disable SELinux. For the ultimate bestest securest database EVAR, doesn't that seem a little cheesy?

Q. Anything else?

A. Until you actually achieve SELinux compatibility, how about trapping the error with a message that describes the workaround? Failing that, mentioning in the Installation Guide that SELinux should be turned off is a next-best solution... no, come to think of it, forget I said that. "It's on page 732 of the docs" is actually a terrible excuse for leaving a bug unfixed. I don't know how "document it" became an acceptable alternative to "fix it".

Q. Are you finished yet?

A. Almost. After more than 10 years of DBA work, I actually don't know what the proper channel is for making suggestions to Oracle Corp. I end up ranting about it on my blog, approximately the equivalent of wandering into the street and yelling about it. Is that silly or what?

I'm Catherine Devlin, and I approved this message.

Thursday, May 27, 2010

templating engine cookoff updated

Ian wished for loop syntax examples in the Templating Engine Cookoff, so I just added them.

And none of you Django programmers have given me code to include Django templates in the cookoff. You can't throw an exception in this town without hitting a Django programmer, so what's up? C'mon, it's easy - I just need something analogous to this:

The answer to the Ultimate
Question is ${everything['universe'].answer}.

Among our weapons are:
% for weapon in weapons:
${weapon}
% endfor

import mako
import mako.template
class MakoDemo(Demo):
name = 'mako'
version = mako.__version__
def demo(self, vars):
self.template_name = 'mako.txt'
template = mako.template.Template(filename=self.template_name)
return template.render(**vars)


[EDIT: Well done, Django folks! Django is in the cookoff now. Except... hmm... it reacts to missing variables by leaving blanks instead of throwing an exception... so I need a new trick if I want to actually see the Django error stack.]

Tuesday, May 25, 2010

dbapiext.py

Richard Jones alerted me to Martin Blais' dbapiext.py, and I like it very much.

Richard's post focuses on the improvements to bind variable handling. I love dbapiext.py for another reason: it provides query results as namedtuples, a class so perfect for database resultsets that they make me sob with relief.

>>> import cx_Oracle, dbapiext
>>> connection = cx_Oracle.connect('username/password@SID')
>>> results = dbapiext.execute_obj(connection, 'SELECT * FROM crew')
>>> row = results.next()
>>> row
Row(ID=1, NAME='Kaylee Frye', ROLE='Mechanic')
>>> row[1]
'Kaylee Frye'
>>> row.ROLE
'Mechanic'

When memory isn't an issue, I like to transform the result into a list and tack on a simple equality filter method for convenience.

class Filterable(list):
def filter(self, **kw):
for itm in self:
for k in kw:
if not (getattr(itm, k) == kw[k]):
break
else:
yield itm
yield StopIteration


>>> result = Filterable(dbapiext.execute_obj(connection, 'SELECT * FROM crew'))
>>> result.filter(NAME='Jayne Cobb').next()
Row(ID=5, NAME='Jayne Cobb', ROLE='Public Relations')

It is, of course, no SQLAlchemy, and isn't meant to be. It's meant to be a roadmap toward a less awful DB-API for Python. (I still wake up in the middle of the night, gasping, "Five incompatible bind variable formats! It's heresy!") In the meantime, dbapiext.py is a nice lightweight layer for times when SQLAlchemy is too much. For instance, I write lots of database administration tools that poke around in lots of different views of Oracle's data dictionary, and setting up SQLAlchemy mappings for each of them is a pain. dbapiext.py is perfect for that. Thanks, Martin!