¶   Splitter, yet another fun physics-based game.

¶  Typealyzer, an automatic Myers-Briggs analyzer for blog content. Also, GenderAnalyzer to determine if the author is male or female.

We discovered a particular feed would cause a particular regular expression in the code to spin endlessly. The regex was intended to determine if a style attribute is valid CSS:

if not re.match("^(\s*[-\w]+\s*:\s*[^:;]*(;|$))*$", style):
    return ''

Breaking this out into verbose regex syntax shows how it matches valid CSS:

"""(?x)             # use verbose regex syntax
    ^(
                    # A single CSS clause is:
    \s*             #   leading whitespace
    [-\w]+          #   a dash-word, the property name
    \s*:\s*         #   space, colon, space
    [^:;]*          #   anything but :;, the value
    (;|$)           #   ends with a semi or the end of the string
    
    )*              # Valid CSS is any number of clauses
    $
"""

And here's the snippet discovered in the feed that spun us hard (with whitespace added for readability):

<var style="COLOR: #fffafe; coming: ; basket: ; philologist: ; gradually: ;
encyclic: ; whitechapel: ; left: ; albino: ; lamelliform: ; foment: ;
adjuvant: ; Room:  ; Milk:  ; buynow: ; wheelwork: ; unseal: ; reasons: ;
socalled: ; dazed: ; Brain:  ; Kaleidoscope:  ; hardheaded: ; asthenic: ;
preferred: ;  Barbecue:  ; Comet:  ; Nail:  ; lubberly: ; School:  ;
Mist:  ; undercurrent: ; intwine: ; isotonic: ; Chief:  ; miscellaneous: ;
Book:  ; Shoes:  ; Chocolates:  ; deuced: ; you: ; Man:  ; federalize: ;
Rainbow:  ; Satellite:  ; Printer:  ; amicus: ; tautophony: ; taking: ;
regrater: ; waggon: ; prescient: ; God:  ; prosing: ; Bank:  ; hariolation: ;
patriarchs: ; Pyramid:  ; Data Base:  ; PaintBrush:  ; ingenu: ; Rope:  ;
parenchyma: ; price: ; Alphabet:  ; Circle:  ; seeks: ; frankhearted: ;
vituperate: ; dysmeromorph: ; Shop:  ; firm: ;  imperforation: ; lane: ;
Gemstone:  ; slatternly: ; Fire:  ; impudence: ; Carrot:  ; Fan:  ;
inoccupation: ; uncover: ; Liquid:  ; drawee: ; Pocket:  ;barbacan: ;
fornicatress: ; chimes: ; Crystal:  ;innovation: ; years: ; untiring: ;
Freeway:  ;desertful: ; unreined: ; Compass:  ; Hose:  ;prelusive: ;
impenetrability: ; Fruit:  ; direct: ; "></var>

(yes, it's garbage, and yes, spam sucks.)

It's hard to see the problem here, but this is not valid CSS because they used "Data Base" as a property name about half-way through and spaces aren't allowed in property names.

The CPU spins because when the regex encounters the failure to match "Data Base", it backtracks to reconsider previous matches in the hopes that it can still make the regex work. In fact, it isn't in an infinite loop, just a very very very long one. Eventually this regex will finish and decide that the string doesn't match.

But we don't need it to backtrack: going back to re-match previous CSS clauses isn't going to help.

Some regex libraries offer solutions to this problem. Possessive quantifiers let you use *+ to mean, match as many as possible, and once matched, don't try matching fewer during backtracking. They're called possessive because once the operator claims part of the string, it won't give it back for other operators to match later.

But Python doesn't offer possessive quantifiers (yet yet). So we have to choose a different technique than trying to match the whole string in one large regex. In this case, since we don't need the match data, we're just checking that the whole string matches, so we can use re.sub to remove matching clauses and then check that there's nothing left over:

if re.sub("\s*[-\w]+\s*:\s*[^:;]*;?\s*", '', style):
    return ''

Because re.sub grabs matches, performs the replacement, and moves on, there's no needless backtracking to throw a wrench in the works. Now our crazy CSS spam is speedily dispatched as invalid.

As an interesting side effect, if the string is not empty, what remains is the invalid part of the string.

I want a way to author and show slides, and then a way to export them for use in a web page. I've got a goal of putting the presentations online not just as a deck of images, but as a text transcript, illustrated with slides. I've never been able to watch other people's presentations online because I don't have the patience to watch an hour-long video in real time, and a slide deck with none of the actual talk behind it is pretty spare.

S5 (A Simple Standards-Based Slide Show System) is all HTML, CSS, and Javascript, runs in the browser, and was created by Eric Meyer, a very nice pedigree. Remarkably, the thing I like least about it is that when I display the slides in a full-screen Firefox, they look horrible. The text is either too small or too large, and the line-spacing too tight, while the slide title overlaps the text in the wrong way, exposing some of the structure of the divs.

I would have hoped that a CSS-based slideshow by the king of CSS would be a shining example of how information could be cleanly authored and then sparklingly displayed. S5 seems to miss this mark, especially since there don't seem to be many themes available for it, another surprise given how CSS should have made it accessible to lots of designers. Also, although (or perhaps because) the format is native to the web, it's not possible to get the slides as illustrations.

I tried OpenOffice Impress, and was initially impressed. It's got a lot of presentation features, notably all sorts of animations. When I started using it, though, I ran into some problems: there's no way to create a text style, so any code samples have to be tediously formatted by hand. Although there are tons of slide animations, a bullet list that reveals one bullet at a time is not among them. I briefly considered the scripting capability, but it seems arcane and under-documented.

Also, I have to say that OpenOffice's themes are cheesy, and though I found one that looked good, when I installed it, it didn't work.

I briely tried 280 Slides again, and it is very impressive, but too slow to run in my browser.

So I may be using PowerPoint...

Tabblo.com is a fairly large site, but since being acquired by Hewlett-Packard, we've built a number of other sites running on the same code base. We'll be talking about some of the things we've had to do to keep flexible and light on our feet while building and maintaining our web experiences.

If you're interested, drop in.

In one of the shots, I am walking on the pool deck, holding my hand above Nat while he swims the back stroke. This is a swim coach hack I invented to try to get him to lower his head into the water. He naturally swims with his head held up out of the water, as if he's trying to see his feet. To get him to put his head back, I tried walking the deck ahead of him, telling him to look at my hand. It worked for a little while, until he realized there was nothing very interesting about my hand!

This is one of the interesting things about raising a special needs child: you come up with your own techniques, because even the specialists will need to invent stuff specially for each child, and you know yours better than anyone, so you've got a good shot of coming up with the successful tricks.

And then you realize that this is true of all your children!

I don't know if that is possible, since it will require effort from everyone, including the people. Reining in an overwhelmingly Democrat congress may be difficult, but it is crucial. Of all the reasons Obama won, the most important may be that people were punishing the Republicans for their excesses when they controlled all of government. If the Democrats are smart, they will learn from that. If they do not, we may just see another whipsaw election next time around.

Many have said that Obama will have a very hard time leading, given the economic crisis, and the war to deal with one way or another, and that is very true. I hope that he can do more than just run the ball a few yards down the field, I hope that he can genuinely lead.

I want one of these!

Nakamura's site is unfortunately all Japanese, and doesn't offer instructions. It does have photos of other fascinating work, though...

The part that interests me about it, though, are the social dynamics. They've done a clever job with their reputation system: users on the site earn reputation points based on their participation, for example, based on how other community members vote up or down on answers. The points don't mean anything, you can't cash them in, but having them displayed next to your name everywhere on the site is a powerful motivator, especially for quantitative engineer-types.

In addition to reputation points, there's a large collection of badges you can earn, for example by asking a popular question, or doing a lot of re-tagging.

Put together, reputation and badges are powerful motivators. They turn the site into a game, where being useful members of the community gives you tangible (though virtual) points. Questions are answered within seconds of being asked, as eager developers try to pounce and be the first with the correct answer. Questions with widely-known answers frequently have a half-dozen correct responses within minutes.

I don't see much on the site that will engender a real community, though. In fact, the questions are strictly policed to be about programming, and any off-topic discussion is quickly curtailed. This might be a mistake: off-topic threads are an important part of building a larger sense of place. On the other hand, ensuring all discussion is "useful" will make the site much more appealing to new people who aren't won't get the in-jokes.

The primary goal of stackoverflow is to be a useful repository of answers to programming questions, and I think it will succeed at that. Time will tell if it goes in other directions and becomes something larger.

BTW, one other dynamic: since Jeff and Joel are Windows developers, their readership is very Windows-heavy, and as a result, the stackoverflow crowd is heavily tilted in that direction as well.

It's fascinating to realize that the work we do every day with web servers, which seems like a recent modern technology, was predated by guys like Erlang working with early phone switches over 100 years ago. Phone switches were the first servers: central machines connected to a large number of potential clients. In building these switches, the early engineers had to figure out from scratch how to anticipate the possible work load, so they could build switches large enough but not too large. The whole of queueing theory springs from the theories worked out by telephone switch engineers.

And they were clever guys, even adjusting the UI to lighten the load on the switches. When dialing a rotary phone, the particular digits determined how long the switch was engaged before the call could be routed. So when they allocated area codes,

the biggest population areas [got] the numbers that took the shortest time to dial on rotary phones. That is why New York City was given 212, Los Angeles given 213, Chicago 312, and Detroit 313, while Vermont received 802 (a total of 20 clicks, 8+10+2). Four areas received the then-maximum number of 21 clicks: South Dakota (605), North Carolina (704), South Carolina (803), and Nova Scotia/Prince Edward Island in the Canadian Maritimes (902).