Spyced

I said that it would be possible to build a django-style admin interface for Pylons using FormAlchemy . (That is, generate a UI for basic CRUD operations for all your models, with no further configuration necessary.) I have a proof of concept in FA svn; it's missing some obvious features like internationalization so there is no official release yet. But the basics are there, so in the meantime, if you'd like to kick the tires , just install FA from svn and give it a try. Here are some screenshots from a pylons app incorporating models from the FA test suite. (The admin controller is fully customizable using standard FA (and Pylons) techniques, but these are what you'd see out-of-the-box.) Index: Order page: Creating a new Order: Deleting an Order: The User page: Editing a User instance: Documentation on using and customizing the pylons admin app is here .

A little background: a few months ago, I went looking for a web framework that was good at automating CRUD (create/retrieve/update/delete) against an existing database schema. I tried django but its database introspection abilities are beyond feeble, and django-sqlalchemy was not mature enough. I tried dbmechanic but its dozen-plus dependencies, most of which were alpha-quality, gave me pause; so did its basic architecture on top of toscawidgets, which I think is The Wrong Way to build web apps. (I understand that the former problem has since been reduced; the latter has not.) So, I went back to option #3, FormAlchemy . I knew SQLAlchemy could reflect very hairy schemas indeed, and what it could not reflect, it could certainly represent with a little manual help. And FormAlchemy was a decent start to automating CRUD with SA models. I added the ability to represent relations, automatic syncing of form input back to SA objects, Grid support, and a test suite. Then Gael came alo...

Feature50 is winding down now that CEO Ben Galbraith has accepted a job offer elsewhere.  So, I'm interested in exploring my options, specifically, opportunities to build out the technology for a start-up working in concert with a strong business CEO. I've done this twice now. Technical ability I am a senior developer specializing in back-end technologies.  At Mozy , where I was employee #2, I wrote a distributed file repository that stores petabytes of data, an amount comparable to Amazon's S3.  I have 8 years of experience with PostgreSQL. I know how to design for scale, and how to find and remove bottlenecks.  I am not afraid of diving into a new code base; I took over as maintainer of the Spyce web framework and the FormAlchemy toolkit, and I have contributed features or patches to SQLAlchemy, Pylons, and Jython, among others.   Soft skills I enjoy building and working with a team.  At Feature50 I am responsible for technical interviews, and personally recruited fiv...

As with many things in the blogging echo chamber, blog day takes itself a little too seriously. But it's impossible not to love an excuse to talk about some of my favorite blogs that don't seem to have as much exposure as I think they deserve: Theo Schlossnagle , CEO of OmniTI, a scalability and performance consulting company. His best posts deal with scalability at the ops level . His book is good, too. Greg Linden , ex-Amazon engineer, ex-Findory founder, current MS Live Labs employee. He likes to post analyses of interesting CS talks and papers, particularly in the area of collective intelligence. Greg stays very on-topic so the most recent posts are about as representative as any. Chris Siebenmann writes about life as a professional sysadmin . He also sometimes blogs about python . Josh Berkus , PostgreSQL core team member, mostly blogs about current events in the database world, but every once in a while he writes a must-read post about database design . Google th...

Having been eyeball deep in App Engine for a while, evaluating it for a project at work and putting together a presentation for the utah open source conference, I've reluctantly concluded that I don't like it.  I want to like it, since it's a great poster child for Python.  And there are some bright spots, like the dirt-simple integration with google accounts.  But it's so very very primitive in so many ways.  Not just the missing features , or the "you can use any web framework you like, as long as it's django" attitude, but primarily a lot of the existing API is just so very primitive.   The DataStore in particular feels like a giant step backwards from using a traditional database with a sophisticated ORM .  Sure, it can scale if you use it right, but do you really know what that entails? Take the example of simple counting of objects .  There's a count() method, but in practice, it's so slow you can't use it.  Denormalize with a .count pr...

My App Engine 101 slides and code are up now. Bad news: my macbook pro did not work with the projector, period. Good news: I have seen it do this before (in a room with several mac experts -- it was not user error) and brought a backup laptop. Bad news: I forgot to include the django beta1 framework in my code upload, so I told people to just download it. But beta2 was out, and didn't work with the version of App Engine Helper I had. (It looks like r58 fixes this.) Manual poking about the django download site ensued until I got a new zip uploaded. Good news: the conference organizers liked it anyway and asked me to present a second time later in the day. Everything just worked the second time around.

App Engine is probably the biggest thing to happen to Python this year, so of course I volunteered to give a presentation on it at at the Utah Open Source Conference . (I'm scheduled for Friday, Aug 29, at 10:00 AM.) Last year's conference was a big success, so I'm looking forward to an even better experience this year. Here's the abstract I submitted, before they blew away my paragraph breaks: Google launched the App Engine service earlier this year to immense interest from the web development community. App Engine allows running applications on Google infrastructure, including BigTable, Google's non-relational, massively scalable database. App Engine is appealing both at the low end, where small shops don't want to have to deal with hardware procurement and systems administration, and at the high end, where the kind of "instant scaling" App Engine promises to deal with bursty traffic is the holy grail of infrastructure planning. This tutorial will ...

Now that I've been doing Python full time again for a while it's easy to forget how magical it can be. Last night I got an IM from a friend of a friend asking for (a) a recommendation for a Python book and (b) advice on writing a screen scraper. I pointed him to Dive Into Python and BeautifulSoup . Just now he IMed me again, "Hey, thanks for the tip. I ended up writing a screen scraper that I hadn't completed in 2 days in Groovy in about 20 minutes last night in Python with BeautifulSoup. So thanks, you got another python convert." I love my job.

I'm gave sqlalchemy-migrate a try today. I like it, and I'm going to keep using it. The one downside is that it's a bit hard to find "the least you need to know" in the documentation, especially if you lean old-school like me and prefer to write your upgrade scripts in raw sql. So here's my stab at it. Create a "repository" for upgrade scripts: migrate create path/to/upgradescripts "comment" Create your manage script. If you have development/production dbs with different connection urls, create two scripts with the same repository but different urls: migrate manage dbmanage.py --repository=path/to/upgradescripts --url=db-connection-url For each database, create the Migrate metadata (a migrate_version table): ./dbmanage.py version_control Create an upgrade script. This will create a script [next version number]-[database type]-upgrade.sql in the "versions" subdirectory of your "repository." That's a...

You're successful when someone tries to get a cheap clone of your site done on a cheap-labor code monkey site. I'm flattered , I think.  (Although I'd be  more flattered if it were a  good code monkey site.)

I ended up buying four pieces of equipment to help deal with being temporarily one-handed : the Matias half keyboard , the X-keys foot pedal (cheaper than the Kinesis pedals, which got lukewarm reviews on Amazon), the Keyspan PR-US2 Presentation Remote , and the Pacific Outdoors 17-LC100 Folding Recliner . The good: I'm very pleased with the recliner and modestly happy with the remote.  I got the recliner to take naps in; the brace on my arm didn't really accomodate lying down.  This $80 recliner compares well with zero gravity recliners costing over 10x as much.  (I've used two of the expensive variety; a BackSaver and one whose brand I don't recall.)  The only downside is you can either sit up, or recline fully; there is supposedly a way to adjust the recline angle, but it doesn't really work.  Expensive zero gravity recliners can all reliably lock at any angle you like. The remote mostly worked as a mouse substitute that I could use with my immobilized right han...

I separated my right shoulder so that arm is going to be out of commission for a while.  (I am right-handed.)  I'm managing about 25 wpm with one hand, or about 1/4 my normal speed.  This is frustrating.  The Handkey Twiddler has been out of production for a while.  The BAT is not OS X compatible. Anyone tried the Half Qwerty keyboard?  Are there other good options for under, say, $300?  (I found several very niche products for significantly more.) I do plan to try voice recognition for email and IM but I can't see that working very well for code.

I've been getting back into the Jython codebase this last week. The last time I submitted a Jython patch was in the beginning of 2004, so it's been a while. Things have changed... Jython is finally requiring Java 5 for the next release, which means the usual improvements, but especially good use of annotations. Here's some notes from my puttering around (mostly dragging Jython's set module up to compatibility with CPython 2.5's): Expect Eclipse to be slightly confused. (Lots of "errors.") This is normal. Use ant to build. ant regrtest is handy. run it before you start making changes so you know what's already broken in trunk. (At least between releases, jython does not appear to be religious about "no tests shall fail." But as a new developer you should make "no additional tests should fail" your motto.) Subjective impression: Jython re performace is a bit slow. Jython uses its own re implementation predating the Java re...

Currently, Jython ships with the pdb debugger module from Python 2.3. Unfortunately the 2.3 pdb is primitive even by command-line debugger standards. (For instance, if the program you are debugging throws an exception, it will take pdb down with it. Seriously. Did anyone actually use this thing?) Fortunately all you have to do to get a much better experience is grab pdb.py, bdb.py, and cmd.py (for good measure) from a 2.5 CPython installation and run against that instead. I've only tested this with Jython trunk but I think it should Just Work with the 2.2 release, too.

Last night the Utah Python User Group held an editor/IDE smackdown. I'm not going to write an exhaustive summary, but here are some highlights: ViM's OmniComplete is actually pretty decent. Calltip support in the GUI is also good. (GUI? ViM? Yeah, weird.) Emacs completion, from Rope, is also good. Emacs's refusal to make any concession to GUIs though keeps things clunky. Not that it isn't great that Everything Works over plain ssh; that's fine, but going through classic Emacs buffers for docstrings or completion means everything takes more keystrokes than it should while being less useful than having that information Always On. Rope also gives Emacs refactoring support that works surprisingly well. PyDev still sees a big win from the Eclipse platform. Specifically, even though Subclipse and Subversive are a bit weak compared to the gold standard (that would be TortoiseSVN), they are much better than what you get with Komodo or Wing. Now that I am on OS X (...

Don't communicate with them Treat them like they owe you something Google is off to a good (bad?) start with both of these in its management of the App Engine release. Of the 120+ issues logged by beta testers, a few have been closed as wontfix or duplicate; most have no response at all from the App Engine team. I can't think of any other company that I've filed an issue with that took that long to get back to me. The good ones get back within hours. The one exception I have seen is for the urllib issue , where gu...@python.org, presumably Guido, wrote Providing a urllib replacement implemented on top of urlfetch shouldn't be particularly hard. If someone is willing to produce one, I'd be happy to review it and, if it passes muster, try to get it added. Paraphrased: "maybe if you do our work for us we'll consider it." WTF! This isn't OSS, where "if you want something, do it yourself" is at least a semi-valid response. Ap...

App Engine sure has caused a stir . Some of the competition is already scared , with reason. But who is App Engine's real competition? In a lot of ways, App Engine is in a class by itself. It competes on the high end with Amazon Web Services . But it also competes on the low end with every shared host out there. And thanks to the integration of Google authentication and the application directory you could also make a case that in an orthogonal way it competes with Facebook's application API. At the low end, App Engine is a big deal for Python developers and anyone else who is allergic to PHP. Historically, you've really had to look hard for low end hosting that offered anything else. And as everyone who has given products away to colleges knows, Free is a fantastic hook to get developers to try out your platform. Once it's open for all, App Engine is going to become the preferred option for developers with the itch to write a toy or proof of concept and show...

Just for fun, here's the number of stars (interested people) for the different language-support feature requests for Google App Engine: Perl: 85 Java: 69 Ruby: 67 PHP: 23 C#: 11 jvm, not just java: 7 Common Lisp: 5 Update: Perl is stuffing the ballot box :)

Over three years ago (!), I wrote a screen scraper to turn the Python Job Board into an RSS feed. It didn't make it across one of several server moves since then, but now I've ported it to Google's App Engine: the new unofficial python job board feed . I'll be making a separate post on the Google App Engine business model and when it makes sense to consider the App Engine for a product. Here I'm going to talk about my technical impressions. First, here's the source . Nothing fancy. The only App Engine-specific API used is urlfetch. Unfortunately, even something this simple bumps up against some pretty rough edges in App Engine. It's going to be a while before this is ready for production use. The big one is scheduled background tasks . (If you think this is important, star the issue rather than posting a "me too" comment.) Related is a task queue that would allow those scheduled tasks to easily be split into bite-size pieces, which i...

I have been lucky to be able to fill our recent open positions with people who know Python as well as Java so now we are up to half the (6 person) company in that category and preferring Python, and 2 of the others have played with Python and liked it at least well enough to not object. So the boss has conceded that it makes sense to go the Python route for our next project. We're going to be doing a web, "next gen" version of our existing client-server project, which is mostly simple CRUD but does have 1000+ tables in its current incarnation. So we really need something that can autogenerate 90+% of the CRUD or we will go insane. The trouble is, I still don't really like any of the Python web options 100%. (I like the web options in other languages less, but I'm a perfectionist.) Django is well documented, its admin app is something everyone else envies, and newforms looks decent, but the ORM blows and I'm not fond of the template engine either. (...