Spyced

If you work in the web development area, or even dabble in it as a hobbyist, sooner or later you're going to write code for a project that needs authentication. Probably sooner than later. For a feature that gets used so frequently, it's remarkable to me that nobody has really done this right. Here are some basic principles for a good solution: A minimum of customization to work out-of-the-box Gentle complexity slope when more sophisticated behavior is needed Play nice with others Don't try to solve world hunger The first two are, I hope, no-brainers. The second two bear more explanation. Play nice with others: not everyone wants to authenticate against a Users table in a relational database. (Fairly common alternatives are LDAP or Unix logins.) If you bake in assumptions like this too deep, it causes problems. It might be worth the problems if it were impossible to provide both generality and ease of use, but such is not the case. Don't try to solve wo...

Most frameworks today have pretty good support for code/markup reuse towards providing a common look to a site without the "include a header, include a footer" clunkers you used to see. (Spyce uses "parent tags," which are as elegant as any and more powerful than most.) But what I want to talk about today is code/markup reuse in the small, at a level that corresponds to functions or methods in Python. Most frameworks today still suck at this. Approaches vary, but the important thing they have in common is not letting you use the same techniques you use in the rest of the framework as well as generally being clunky. For instance, with Rails, you define functions which you can then use from your views/templates/presentation layer, but within those functions you're back in 1996, stringing HTML together manually. Something like def faq_html(question, answers) html = ''' <table class="faq"> <thead> <tr...

Traditional view-oriented frameworks (such as PHP, or Spyce 1.3) do not handle control logic well. Today I'll show how Spyce 2 solves this problem with "active handlers," and tomorrow I'll show how this lets Spyce provide much more elegant code-reuse tools than either other view-oriented frameworks or MVC frameworks like Turbogears and Django. Control logic is the code that decides what happens next in response to a user action. Say we have a simple form to create new to-do lists, like this: <form> <input type=text name=name value=""> <input type=submit> </form> In a traditional view-oriented framework (like Spyce 1.3), you would process this form with code that looks something like this: [[name = request['name'] db.todo_lists.insert(name=name) api.db.flush() ]] That wasn't too bad. (Especially since I cheated and used the modern Spyce db api, AKA SqlSoup from SQLAlchemy.) But even with a simple, one-element for...

The revamed Spyce website announces "Spyce will not waste your time." Most web frameworks today waste your time with busywork at least some of the time. This is unacceptable; boilerplate code is tedious to write, an obstacle to good maintenance, and a distraction from real productivity. All the development of Spyce 2.0 and 2.1 has been towards eliminating common sources of busywork in web development. Today I'll give a couple concrete examples of how this applies to creating forms for user input. Let's say you want to have a select box that remembers what the user's last selection was. Pretty much any form these days needs logic like this when giving feedback inline. Many frameworks make you write this code out by hand; if you've ever developed in one of these, you know how quickly this gets old. Here's what you'd have to write in Spyce 2.1, given a list of options named options : <f:select name="foo" data="options...

Just some bug fixes this time: fix support for threadless python builds fix using compiled tags within other tags fix f:textarea fix spyceUtil.extractValue for incomplete dict work-alikes fix session1 backwards compatibility

This morning I read about the new Amazone Elastic Compute Cloud service. It's basically a cluster of Xen VPSes, done right. At least that's what I thought until I actually tried to use it. Let's see: Sign up for AWS Sign up for S3 Create certs Download tools Export 3 EC2 environment variables Oh, hell. Tools are in java. Switch to windows box since I don't have the patience to figure out installing Java 1.5 on debian right now. Repeat steps 4-5 Export JAVA_HOME Run ec2-describe-images Exception in thread "main" java.lang.NoClassDefFoundError: com/amazon/aes/webservices/client/cmd/DescribeImages Looks like I get to try to fix the classpath for them. How retro-cool can you get? It's just like 1999! Bah. Next time, use Python, guys. update: : Apparently they didn't even bother testing on windows and their script was just plain broken. Way to go.

For the first time, codejam 2006 features Python as a language option. I don't follow topcoder closely enough to know if this is the first contest they've done with Python or not, but this smells of Google influence to me. I was about resigned to not bothering with this year's code jam, with my C# even rustier than last year , but now I'm totally stoked. Go Python! (Oh yeah, link to main code jam page .) Update: for the curious, topcoder added Python support about 10 days ago

Check out What's new : Login tags SQLAlchemy integration Validation in handlers More powerful form tags Improved handler integration Pauli Virtanen has contributed debian scripts, so we'll have a .deb to go with the rpm and sourceball releases pretty soon.

I have a pg database that just suffered through a multiple-hour vacuum of one of its tables. It was pretty painful. Autovacuum is configured to run every 12 hours, but for whatever reason it didn't see fit to vacuum this very busy table for substantially longer than that. (Not sure exactly how long. Over a week is my guess.) The problem is that one size does not fit all. On smaller tables, the default autovacuum_vacuum_scale_factor of 0.4 is just fine. On this table waiting that long is unacceptable.