Episode 007: Gary, With Beer

….or “Make Your Own Episode Title, Since You’re So Clever; I’m Tired and Going to Sleep Because Codemash Starts in Seven Hours”

Broadcasting from high atop the basement of the Buckeye Beer Engine, regular voices Chris Miller, Mike Pirnat, David Stanek, Mike Crute, and Ben Smith are joined by Gary Bernhardt, renowned destroyer of software, for a conversational journey through what’s on our minds this week.  (Audiophiles beware–thar be strange acoustics ahead!)

First, we begin with an apology for not releasing an episode in six months; we make some excellent and terribly creative excuses, but still, we’re covered in a thick layer of fail.  Forgive us?

Getting down to business, we discuss WSGI2 and various issues around (what we perceive to be) the current community furor over its development.  Do you know your PEP-3333 from your PEP-444?  We try to sort it all out, and why we either like or don’t like bits of it, all the while haunted by the echoes of the room and the faint hints of bar music above.  (Is that David Bowie’s “Life on Mars” I hear?)

Next it’s time to beat on one of our favorite pet issues, Testing.  We battle our way out of the weeds of semantics and eventually come around to some more practical talk around tools like Cucumber and Lettuce and what it means for suits and geeks to collaborate to build functional specifications.  (Please note that if you’re driving a Ford Taurus, you might have left your lights on.)

From there, it’s a very quick descent into a passionate discussion of Python’s tendency to spawn an explosion of “us too!” implementations of any shiny things that we see in other languages and the resulting community fragmentation that ensues, design by committee, and related perils.  Dim memories of the dawn of WSGI are recalled, Armin Ronacher’s Logbook is called out for being new-instead-of-fixing, and snake-guice gets name checked.  Mike Crute implores erstwhile Python developers to look around for existing solutions (and how to improve them) instead of building their own.

It’s then a hop-skip-and-a-jump over to templating engines like Mako, Jinja, Genshi, and Django templates, and then the philosophical differences between various web frameworks.  Are we better pursuing unity of effort or diversity of ideas?  Why does Ruby outdo Python at “one and only one obvious way to do it” when it comes to major products?  This then spirals into ancient history of Rails and Python web frameworks and our aesthetic feelings and pet peeves about Ruby.

We bring things back around into more practical territory as Chris asks Mike Pirnat to expound fo a bit about Blogofile, a static site/blog generator that Mike has recently become enamored with.  (A few corrections here–since recording, version 0.7 has escaped, and Chris, who claims to be “chained to Wordpress” switched painlessly over to Blogofile in an evening’s time.)  We give a nice shout out to fellow Blogofile contributor Morgan Goose and his awesome Fabric kung-fu.

And that’s pretty much it.

Big thanks again to the Buckeye Beer Engine for being so hospitable with their space; they offer free wi-fi, a great selection of beers, and they have RSS feeds for their tap list and menu specials and other news.  How awesome is that?

Thanks for listening, and we’ll be back next month with another installment–we promise!

[shownotes by Mike Pirnat, for he is made of WIN]

One Response to “Episode 007: Gary, With Beer”

  1. The 100-continue is not really a limitation of WSGI itself. It is purely an implementation detail of the underlying hosting mechanism. Apache/mod_wsgi embedded mode works properly for 100-continue. This isn’t the case for example for mod_wsgi daemon mode, uWSGI, FASTCGI, SCGI, AJP or CGI because the implementations don’t implement end to end 100-continue across their respective protocols. Instead they immediately start proxying the request content across to back end process which triggers the sending of the 100-continue back to the HTTP client. For 100-continue to work, these implementations would need to delay proxying of request content until the backend process returns some sort of indicator that reading of request content had begun. None of the wire protocols for that proxy connection support such a concept, but that is an issue with those wire protocols and not WSGI itself.

Leave a Response