Perl

Choose perl if you think that scripting is for quick-n-dirty tasks, and your language ought to look like it. Or if you like how it looks when Snoopy swears.

Ruby

Choose ruby if you think that perl is pretty cool, but it should be even more powerful.

Python

Choose python if you think naming your throwaway variables "spam" and "egg" is really witty. Or if you want to write really cool stuff. (No bias here, no sir!)

JavaScript

Choose javascript if you're cowboy hacker or a genius hacker (or both).

VBScript

Choose vbscript if there's no hope for you whatsoever.

Lua

Choose lua if you like squeezing into small spaces.

This is a huge advance for Windows GUI programming with WxPython. Now WxPython applications on Windows can host an IE window, and control the contents programmatically via the document property.

The WxPython team has been pretty quiet about it. The changes don't seem to have made it into the docs (although they're mentioned in the change log and the sample code has been updated).

Here's a simple example of a dialog box with an HTML window. The dialog intercepts clicks on the links, and uses them to set the color of the text by accessing its css property.

Here's the code (htmlwin.zip).

The method BeforeNavigate2 intercepts clicks on links, and uses the link information to get the desired color. Then it finds the element in the DOM with an id of "text", and sets that element's color to the link color.

The possibilities of this technique are huge. Although it has the disadvantage of tying you to Windows, if your application is going to be Windows-only anyway, it lets you write an application with many of the benefits of a Web app, and very few of the drawbacks.

Here's a screenshot of the above code in action:

As Delicious stagnated, an entire ecosystem of social bookmarking sites sprang up. Delicious squandered its huge lead in this space doing a rewrite, while it could have used that energy to keep innovating ahead of the me-too sites.

Let this be yet another lesson in avoiding the big rewrite. Even if the codebase you inherit is really bad, if you've got a working system (which del.icio.us most certainly was), it's best to keep the existing system and refactor.

The rewrite is a seductively attractive solution. Just looking at the code makes your brain hurt? Dump it and start over! I've gone through my share of rewrites. I re-wrote my application Felix from the ground up twice. The first rewrite was needed — I wrote the first version while simultaneously learning C++ and Win32 programming — but the second could and should have been avoided.

I'll use the delicious debacle as another reminder that no matter how attractive the rewrite options seems, it's almost always a bad idea.

Incidentally, it's been pointed out that Yahoo! rewrote the original perl codebase into php and C++ (!), because those are its "institutional" languages. It sounds like Yahoo!'s inflexibility caused it to make a huge blunder.

Here's how I created a custom function for fuzzy glossary searches, using SQLAlchemy for the ORM, with SQLite as the database engine. Assuming you've got your SessionClass object, create a session, and get a connection object:

Speedup

Just for fun, I compared the speed of (1) using custom functions in SQLite with (2) keeping the records as a Python array, and getting the matches in pure Python using a list comprehension. I found that the SQLAlchemy version is about 8 times faster. In the test, I created a glossary of 44,732 records using random word pairs, and got the fuzzy substrings for a query sentence.

Since the fuzzy-matching code and database code are written in C, the SQLAlchemy version is probably approaching near-C speeds, with the only slowdown being the overhead of calling them from Python (which is pretty minimal; most of the work is done elsewhere).

More importantly, the SQLAlchemy version easily meets my performance target of a 50,000-record search in 0.25 seconds, while the native Python version falls pretty far short.

Also interestingly, I found that psyco didn't speed up either version at all, and in fact made both slightly slower. Another demonstration that you should profile rather than applying psyco as a panacea.

Here's the code used for the test.

I recently created a server application to share Felix memories/glossaries over a local network. After a simple test application, I was confident that CherryPy would serve my needs, so I bought CherryPy Essentials (Sylvain Hellgegouarch) and started hacking.

The story of a website

The book uses a practical-minded, show-me-the-code style that I personally like. The book tells the story of a website, starting with an introduction to CherryPy, then walking us through the creation of a sophisticated Web 2.0 website, adding more elements as our understanding grows.

While I found the style of taking us through the development of a website useful, this approach has an obvious weakness: if you don't use the same components as the author, the book will be less relevant. For example, the author chooses Dejavu for his ORM, while I prefer SQLAlchemy; he chooses Kid for his templating engine, while I prefer Mako; and he chooses MochiKit for his JavaScript library, while I prefer jquery.

While this prevented me from using the book's code whole cloth, it did show me how to build a website the CherryPy way, using CherryPy's fantastic features and integrating them with the other technologies used in a modern Web application. In all I'm quite pleased with the value I got out of the book.

Contents

Chapter 1: Introduction to CherryPy
Chapter 2: Download and Install CherryPy
Chapter 3: Overview of CherryPy
Chapter 4: CherryPy in Depth
Chapter 5: A Photoblog Application
Chapter 6: Web Services
Chapter 7: The Presentation Layer
Chapter 8: Ajax
Chapter 9: Testing
Chapter 10: Deployment

Chapter 1: Introduction to CherryPy

This chapter provides some introduction to CherryPy's history and community. It can be safely skipped by the impatient.

Chapter 2: Download and Install CherryPy

Not too much of interest here either. If you can find the book, I'm sure you can find CherryPy.

Chapter 3: Overview of CherryPy

Here's where things start getting interesting. We start with a simple "shout" style application, then walk through the anatomy of a basic CherryPy application: configuration, static files, URL routing, and page handlers.

The author also provides a list of the built-in library modules, which I found to be fairly useless since he doesn't tell us how to use them or even really much about what they might be good for.

Chapter 4: CherryPy in Depth

True to its title, this chapter talks in depth about the various capabilities and tools provided with CherryPy, including material on extending and hooking the CherryPy engine. If you've got experience developing websites, chapters 3 and 4 are really all you need to get cracking on a cool website with all the fixings.

Chapter 5: A Photoblog Application

For the remainder of the book, we'll be building a photo blogging application, fully Web 2.0 buzzword compliant with web services, JavaScript, and AJAX goodness.

The chapter provides a high-level outline of the application we'll be building, and then discusses some of the various ORMs available for Python.

Chapter 6: Web Services

This cool chapter describes how to build Web services (including RESTful services) using CherryPy. This served as a major inspiration for creating the API to my server, although I decided not to use REST.

Chapter 7: The Presentation Layer

This chapter goes over templating libraries for Python (the only thing more numerous in Python than templating libraries are Web frameworks) and how to integrate them with CherryPy, then settles on Kid as the engine to use for the application.

Chapter 8: Ajax

Although the author uses MochiKit as his JavaScript library, he describes the AJAX communication process at a fairly low level, so it was easy to transfer the concepts over to jquery. After briefly describing JSON as the mechanism for transferring data between JavaScript and Python, the chapter goes on to describe how we'll be using AJAX in our photo blogging application.

Chapter 9: Testing

You've got to give props to a framework book that devotes a chapter to testing. As with other components, although I prefer nose and mechanize for unit/web testing to the author's unittest and webtest, the concepts were what mattered and I had no trouble following along.

I also appreciated the section on performance/load testing using FunkLoad, as well as function testing with Selenium, which I wasn't very familiar with.

Chapter 10: Deployment

This chapter is also pure gold in a framework book. It discusses the various deployment and configuration options, including deploying behind Apache and lighttpd. I found the section on supporting SSL to be particularly helpful, as my next step for my server will be hosting it myself via SSL.

Conclusion

This book is a great practical guide to building websites with CherryPy, using best practices for the framework and getting the most out of the huge array of functionality that it provides.

The Pakt Publishing Ebook

I bought this book as a PDF from Pakt Publishing. I prefer having programming books in electronic format, because I typically read them at my computer while experimenting with the code in the book. And since I live in Japan, the electronic format is also a great way to get my grubby hands on technical books quickly and cheaply.

Pakt ebooks, I found, have an annoying security feature: copy and paste is disabled, thwarting my preferred tactic of copying and pasting code snippets to run, and terms to google. Sure, the code samples are provided, but that adds a lot of hassle to what should be a simple operation.

I wish Pakt would discontinue this practice. It only hurts paying customers, since the pirates will no doubt have little trouble stripping out that protection and repackaging the book in any format they like.

Python is for people who want to program, not REAL WORLD programmers.

(Python encourages a sense of fun, and people on the comp.lang.python group tend to like to have fun taking the piss out of trolls.)

Not that "real world" programmers don't use Python — just that people who place a lot of value on being a "real world" programmer are probably using Java or C# or something. Meanwhile, people use Python because it's a great language and they love programming in it, not because it will make people think they're "real world" programmers.

This goes back to the Python Paradox described by Paul Graham: python programmers are generally good hires, not because Python is (necessarily) a better language than Java or C#, but because

…people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

This is becoming less of a sure thing as Python gains popularity and starts to look good on "real world" resumes, but I think it's still true that people use Python because they like it.

Apparently, "testosterone-fueled" men tend to write cryptic code without comments, while "touchy-feely and considerate" women tend to write lots of helpful comments and are just all-around nice people.

If you're going to make sweeping generalizations about how men and women code, I want to see some real studies, not the personal observations of some random female engineer.

The random engineer in question is Emma McGrattan, a high-up muckety-muck about Silicon Valley and the sole source quoted in the article, who

…boasts that 70% to 80% of the time, she can look at a chunk of computer code and tell if it was written by a man or a woman.

But that's not very impressive. 80% of the programmers at her company are men — she could guess "man" every time and have an 80% chance of being right. The ratio of men to women is even higher in the general programmer population (in the English speaking world, at least). So this means that the accuracy of her spidey senses is less than or equal to chance.

Even granting the premise that women add more comments to their code than men, I have my doubts about whether copious commenting is particularly helpful or even a good idea. That's why I'm not especially enthusiastic about her company's coding standards:

In an effort to make Ingres’s computer code more user-friendly and gender-neutral, McGrattan helped institute new coding standards at the company. They require programmers to include a detailed set of comments before each block of code explaining what the piece of code does and why; developers also must supply a detailed history of any changes they have made to the code. The rules apply to both Ingres employees and members of the open-source community who contribute code to Ingres’s products.

A detailed history of any changes they have made? In the comments? Isn't that what source control is for? Please don't tell me that this major company has replaced its source-control system with code comments. The alternative is that this standard breaks the DRY principle (don't repeat yourself) by duplicating source-control information in the comments.

That's not the only problem with this standard. The big problem with comments is that they lie. Code, on the other hand, never lies. It does what it says it does (albeit sometimes cryptically). It's very common for programmers to modify the code without bothering to modify the comments; the comments, therefore, get out of date.

It's much better, in my opinion, to document code in a way that can never get out of date: with unit tests. I know it's a cliché, but I believe that comments should tell you the why, and unit tests should tell you the what and the how of the code.

At any rate, this article still gave me a warm fuzzy because the draconian standards imposed by Emma give lie to the depressing stereotypes that the article espouses.

This seems to resonate with a lot of programmers, and not just because it makes us feel better about ourselves to believe that we're really creating art when we code our 83rd login page. I think it resonates because we get an intense feeling of creative accomplishment when we send our programs out into the world.

My mother works at an art institute in San Francisco. Once in a while the students there will sell some art at a gallery, or to my mom; when they make a sale, they look a lot like how I feel when someone buys my software or says nice things about it.

But my software isn't art:

Art refers to a diverse range of human activities, creations, and expressions that are appealing or attractive to the senses or have some significance to the mind of an individual.

Wikipedia

And that's not the purpose of my software. Just about all the software I write is intended to make things easier for translators and other people who work with text. So while I still think that what I do is creative, its main purpose is practical.

Some software is art, like games and such. Making those kinds of programs is making art. But that business data entry form you're coding isn't art, sorry (unless of course you're really into Kafka).

Indeed, most programming is less an artistic effort and more one of craftsmanship. I think that more programmers don't make this connection between programming and craftsmanship because in the developed world, the "crafts" have become so industrialized that they don't resemble what we do at all. While programming is a high-tech industry, it's definitely preindustrial. Programming isn't like 20 tables rolling off the assembly line every hour; it's more like you go into the cobbler's, and you can either get a pair of shoes that's a bit too small, or one that's a bit too large, or pay an exorbitant amount and wait a week for a custom pair to be made, which probably won't fit perfectly anyway. Heck, we programmers still have to make many of our own tools! Not very industrialized.

I once lived in central Ohio. In the next town over from us, there was an Amish furniture shop, where they made most of their furniture on the premises. I loved looking at and trying out the hand-made rocking chairs they had. I try to emulate those furniture makers in my programming: paying great attention to function, but making my programs pleasing to use as well. I think it's a more useful target to shoot for than Picasso.

After all, what would be the point of a cubist word processor?

Since the app was working fine without py2exe, I brilliantly deduced that maybe something was getting broken in the packaging process.

It turns out that I need to include "mako.cache" in my packages, as pointed out by this blog post.

So the relevant section of my setup dictionary now looks like this:

Everything's working now — lovely stuff!

Googling on this error failed to produce any hits, so I had to (gasp!) do some actual research to figure this out. Here's hoping that I can save the next poor soul from that horror.

In this post I want to pull that together with code to get a word count from an HTML file.

What needs counting

What needs counting depends to some extent on what you need the word count for, but here I'm going to be assuming that the word count is going to be used to count billable/localizable content.

In that scenario, you've got to count the text in the title tag, as well as the visible text in the body, and certain other localizable content: img alt attributes, a title attributes, and input value attributes (am I missing any?).

The Code

The code for counting the actual text is in the above link. Here we need code to extract the text from the HTML file, and to accumulate the counts for all the chunks we've extracted.

Here's the Segment class for accumulating counts:

Next, the code for extracting (segmenting) the text from an HTML file. For this, you'll need the excellent Beautiful Soup module.

And here's some code to get the actual wordcount:

Here are the docstats and htmlseg modules, and here is an online tool using the code for the HTML word counts.