Friday, January 26, 2007

The Internet is Lossy

To the email and RSS subscribers to my programming blog, my apologies for this interruption.  Unfortunately, this is the ONLY way I can reach certain of my readers with the following message:

If you've been reading my non-programming articles via the Unofficial Planet Python, please click here to find out what you missed in the last week due to the "lossy internets", and how you can stop missing your articles in future, without needing any of that RSS/feed reader mumbo jumbo.

Again, to my direct email and RSS subscribers, my apologies for the interruption.  We now resume our regularly scheduled, uh, programming.

Thursday, January 25, 2007

Dreaming In Code

In a spontaneous fit of self-referentiality, I'm now going to mention a book, in this blog, that mentions this blog, in the book.  :)

Scott Rosenberg's new book Dreaming In Code, which is mostly about the Chandler project I work on for OSAF, mentions a couple of my blog posts here about the project, mainly to describe them as, uh, "indelicate".

One of the posts, Python is Not Java, remains highly popular to this day.  But Rosenberg bizarrely interprets this post as "publicly exposing the OSAF team's goofs", despite the fact that the code was available for anybody on the internet to download and see for themselves!

Plenty of them did -- and some Pythonistas critiqued it far more harshly than I did.  I was the only person who attempted to write something educational about what should be done instead, rather than writing the project off as a joke.  That post will continue to be a useful article for people migrating from Java to Python, long after its relationship to Chandler is forgotten.

(Not that most people know the relationship in the first place -- you'd have to have examined the Chandler code base yourself, or read somewhere else that the post was related, despite Rosenberg's claim that it was "pretty clear who [I] was talking about".  Clear to whom?)

Strangely, the two mentions of my blog in the book don't seem to go anywhere; they're almost a sidetrack, as though there was going to be a subplot about the work I was doing, that faded out because it got too technical or something.  (My first big OSAF project was ripping out all the XML schema/UI specification and replacing it with a faster, more maintainable Python API -- not exactly mainstream bestseller stuff.)

Honestly, if I were editing the book, I'd probably have cut my three pages out entirely, because it's a tangent of little interest that goes nowhere.  (Heck, for all I know, an editor might have actually cut those three pages out of the final version, because I'm just reading a preview version that's been circulating amongst OSAF staff.)  It seems that the only purpose was to show how great OSAF is because they were able to look past my "indelicate" nature and still "adapt good ideas" from my work.

But that bizarre conclusion springs from Rosenberg's misunderstanding of the purpose of Spike.  The problem I was experiencing at OSAF initially was that nobody was taking my refactoring proposals seriously, because they couldn't conceive of what the end result would look like.  It was just too foreign a concept at that point, and therefore the perceived risk of my initial proposals was too high.  Essentially, people were arguing that what I proposed was impossible, because they didn't see how it could be done.

So the idea of Spike was to provide a concrete example to point to of "see, this is how something written Pythonically could work", and to demonstrate that something of that sort could in fact be implemented both quickly and robustly, while providing an easy-to-use and understand API.

In other words, the point was never to be an actual replacement for Chandler's architecture, but rather to provide a prototype of what it could be like.  So, the whole point of the exercise was to "adapt good ideas" from it!  That's also why it was done as quickly as possible and in as minimalist a style as possible -- its purpose was to sell ideas to management and developers, not to deliver a replacement architecture.

Spike's purpose, in short, was to raise OSAF expectations about what could be done in Python (mirroring the theme of the blog posts Rosenberg cites) and to make a shift in thinking from ruling things out as "not possible", to asking, "what should we do, and how can we do it?"

In short, Rosenberg's narrative creates a dramatic tension that didn't actually exist in the situation, while ignoring the ones that actually did exist in the situation.  Which makes me wonder how much more of the book (which is mostly about stuff that happened "before my time" at OSAF) actually reflects what was really going on in the rest of the project.

Oh well.  One person at OSAF explained it to me this way: Rosenberg wasn't really writing about the Chandler project, he was writing about software projects in general, using Chandler as an example to illustrate the principles of software development that he already wanted to write about!  So, if what you really want to know about is what actually happened on the Chandler project, this may not be the book for you.

On the other hand, if you want lyrical rhapsodies about how "public static void" can be read as a kind of machine poetry, and how the gap between zero and one is the gap between man and machine, by all means have a go at it.  (Those parts of the book are actually interesting and fun, I find.)  Just don't make any assumptions about how these abstractions map back to the real people and real tasks of the real project used to illustrate them.

Friday, January 05, 2007

Zope Haters Prove My Point About Women in IT

Yesterday, I posted an article that was the foreword to Philipp von Weitershausen's new edition of Web Component Development with Zope 3, in which I had some good things to say about Zope.

I expected the article to be a bit controversial, but I was surpised to find that it was even more controversial than my series of articles about women in IT.  The amount of flaming hatred, profanity, and sheer vitriol leveled against both Zope and me was such that I soon found it prudent to remove the comment thread altogether.

Wow.  I am so glad I had a policy of not hiring a**holes when I had Python jobs available, or I might have accidentally hired one of these dimwits!  (Nobody sane wants to work in a toxic mental environment, and women are slightly more likely to be sane than men.)

Meanwhile, remember: Zope is a tool.  Like any other tool, it has its good and bad points.  But if you can't do anything but spew hatred at someone who has the temerity to find praiseworthy things in a tool you dislike, you are not learning anything.

Everything in life has pros and cons.  Everything.  You can waste your time ranting about what's wrong with something, or you can learn something from it and move on.

If you don't, then you're being a dimwit.  If you then also proceed to rag on those of your betters who chose to learn something instead, then you are also being an a**hole.

So, again, if you want more women in IT, don't hire a**holes.  And although I never used it as an interview test question before, I would now have a new weapon in my arsenal for screening out a**holes quickly...

Specifically, I'll want to ask a candidate to describe the development tool they had the worst possible problems with, and get them to attack it with a vengeance.  Then, I'll either find things to praise in the tool (if I'm familiar with it), or ask them to now describe what positives they got out of working with the tool, or ask them to sell me on its good points.  If they can't do those things, then I'll know that their personal preferences are more important to them than the results -- and that's a "No Hire".

And there's probably no point in mentioning this, because the people who will listen to this already know it, and the people who don't know will probably never learn.  Nonetheless it bears repeating.

If I'd had only bad experiences with Zope, and no good ones, but a bright light in the Python community said, "You know, Python has gained a lot of things from Zope," and gave examples, you know what my response would've been?

I would have asked for some more information, so I could learn too.  Just like when the Rubyista Python-haters rag on Python, and I ask, sincerely, what advantages Ruby actually has over Python.  (Not many, actually; see my DSLs in Python post.)

Because that's what professionals do.  They are always learning.  Always.

Because nothing you learn about what's "the best" or "the worst" stays the same forever.  And if you don't keep up, you're just falling behind.

Of course, those of you who realize that, didn't need me to tell it to you.  And those of you who don't, are too busy crafting your next flame, to pay any attention at all.

Thursday, January 04, 2007

Where Zope Leads, Python Follows

A few months ago, Philipp von Weitershausen asked me to write a foreword for the new edition of Web Component Development with Zope 3, which is about to become available in the US.  The following is what I wrote.

Where Zope leads, Python follows.

So it has been for a decade, and the trend doesn't show any signs of stopping.  Whatever the latest buzzword -- be it RESTful web programming, standardized interfaces, pluggable components, or practical restricted-execution environments, Zope has quietly led the way, delivering the goods years ahead of anyone else.  Not just as technology concepts, but shipped and working in paying clients' offices.

And yet, strangely, Zope's role in the ongoing development of Python is little-known and little-appreciated among Python developers.  It is frequently the case that some new and much-touted development in the Python community -- especially in the web application and object security arenas -- is something that Zope has already been doing for many years.

I'm somewhat baffled by this peculiar blind spot in the Python community.  Even when I tell people that Zope's already done something that they're working on, the response is usually a blank look, or no response at all.  It's almost as if the innovations of Zope don't really exist until somebody else reinvents them.  In fact, the pattern has led me coin this little saying:

Those who do not study Zope, are condemned to reinvent it.

And it doesn't matter if you don't plan to actually use Zope.  Frankly, I haven't used Zope in years.  But the lessons I learned from Zope, I use constantly.  Studying Zope -- Zope 3 in particular -- will make you a better programmer, without question.

Of course, "better programmer" begs the question: better how?  Better at achieving what?

Zope was created so that the Zope Corporation (originally Digital Creations, LLC) could do contracting business more efficiently.  It allows them to keep an ever-growing toolkit of reusable solutions for their clients, reducing the costs of development and maintenance of these applications.  Its purpose is to let you "write once, use many": a multiplier of economic effectiveness.

If this is the path your career is taking, you can only benefit from studying how this has been achieved in Zope, whether you actually use Zope for this purpose or not.

If you are developing any new or cutting-edge technology for Python, you can only benefit by asking, "Does Zope already have this, or something like it?  And if not, how would Zope use this?"  These are the questions I asked when developing Python Eggs, setuptools, and even the WSGI (Python Web Server Gateway Interface) specification.  The success of these projects is a direct reflection of me asking WWZD: What Would Zope Do (with this idea)?

That's because what's good for Zope, is usually good for Python.  Not in the language sense -- Python's "Benevolent Dictator" and the "Zope Pope" often disagree quite strenuously on how the language should change.

What I mean is, tools that make Zope a better platform, make Python a better platform.  And if you study Zope diligently, you may begin to understand why.

And maybe, just maybe, you'll begin to find yourself a little bit ahead of other programmers, especially when it comes to new ideas...  but hopefully, not so far ahead, that they begin to act as though you don't exist, either!

Good luck!