Sprox 0.6.1 released

June 5th, 2009

Well, it’s been longer than I wanted since the last release.  (almost 4 months)  I was holding out because I wanted to get a few more features working, but I realized this week that there was a lot of new functionality, and so it was time to cut a new release.  It turns out, the codebase grew by almost 20% with this release.  I see this as a very stable release because I use almost every new feature at my day job.  Here’s a rundown on what is new.

* TableFiller can provide field_methods for customization of output.
* You can now customize the query TableFiller uses.
* TableBase now has __xml_field__ modifier that un-escapes the data provided by the given list of fields.
* There is a new tutorial for TableFiller: http://www.sprox.org/tutorials/table.html .
* Sqashed #8: Synonym Properties causing Tracebacks.
* Added Mako Templates for every sprox widget. (SPEED!)
* Fixed the way relation form fields render.
* Brandon Rhodes provided a fix for TableBase that allows fields to render with any Widget type.
* Teajay Bernard provided *experimental* support for Editable Dojo Grid.
* Test framework fixed to be more forgiving of XML.
* Declarative Validation overrides now work properly.
* Field Class added so that you may override both the Widget _and_ a Validator for a field (documentation pending).

Special thanks to Brandon Rhodes and Teajay Bernard for their contributions.

You can get sprox from pypi at: http://pypi.python.org/packages/source/s/sprox/sprox-0.6.1.tar.gz

Pycon 2009 Recap

April 3rd, 2009

It felt like this year Pycon was executed to near perfection. Many struggles I had with last years Pycon were addressed both by the organizers, and some creative thinking.
In this post I will recap everything that happened from my perspective.

WSGI House

I gathered a few close friends from the TG team and a couple of wildcards for perspective to share a house for the continuum of the conference.  Having a house gave us a place to go home to at night and meet with friends, often staying up late talking about issues surrounding our favorite software.  Having a focused group I feel is important because you spend less time off on wild tangents.  The first (and pretty much only) rule of the house was that you pay the same amount whether you stay one night or nine.  At least one of our members was encouraged by this rule to stay for the sprints which he hadn’t done before. Success!

Tutorials

For me, tutorials got off to a shaky start, but we seemed to recover nicely.  TurboGears has a lot of momentum right now, and it makes it hard to come up with a succinct tutorial when there is so much functionality to cover.  I think we were able to recover and that our students managed to soak in enough knowledge from our proverbial fire hose to create some useful applications.  I think we have a good start on a new book.

I was extremely impressed with the quality of students who were attending my ToscaWidgets tutorial.  Every single student finished every example.  I chose Pylons to give the tutorial, and although it is a little harder to integrate TW in the stream than does TurboGears2, it installed quickly and flawlessly.  Overall, I think the tutorial was a success.

Talks

This year I did not focus on attending the talks, but instead chose wisely based on speaker and topic and allowed my feet to do the walking if the talk became uninteresting.  I definitely missed some talks, but the AV team has done an incredible job putting the talks up on blip.tv so that I can review them later.

This year I did not miss Raymond Hettinger’s talk on AI in python and was enthralled by a speaker who could successfully put a page of code on the screen and keep my interest.  I showed up to support Philip Jenvey in his talk on Pylons on Jython but was impressed by his ability to provide a succinct example on where Jython really shines.  I am hoping that more people take a second look at this really well done presentation.

Now, I am a SQLAlchemy supporter through and through, but find the domain of database mapping an interesting echosystem.  While the ORM panel was littered by advertising chatter from one of the panelists who did not even write an ORM, an obvious dis-inclusion was Robert Brewer who wrote Dejavu, a very nice way to map persistent resources of different types for use in an “objecty” way.  Bob’s talk was especially interesting and makes me wonder if SQLAlchemy could leverage some of the work with AST that Bob beautifully displayed with some of the most amazing one-handed keyboarding I have ever seen.

Open Space

Well, I said I was going to give a talk at the Open Space, and ended up not doing so.  Part of the problem was the utter lack of projectors in the OS rooms, and part of it was a reluctance to break up the collaborative/discussive vibe that was going on in these sessions.  WSGIers hammered out a 2.0 spec, which involved a discussion I only monitored in passing.  I was disappointed by the lack of people who showed up for the GSoC BOF, but I think the economy held back a lot of students from attending Pycon.  It was also nice to allow my feet to walk around and see what was up in different projects.  I met one guy who took REST way to far and got to express some of my dissatisfaction with one of the available tools.  On a more positive note, the TG BOF was well-attended  and it was nice to see so many users wondering what was up in TG land.

Sprints

This year I refused to let the noobs get me down and actually wrote some code.  I am sorry if I did not act as a good host of the TG project, but we have some important milestones coming up and I just wanted to get work done on that.  Sprinting remains a cornerstone of our development process and I will see if we can’t get our monthly
sprints happening again in 2009.  I was however able to completely re-engineer our dispatch system, and while it is not currently 100% complete, it should be finished in a matter of days.  RestController now supports variable arguments for get_one, delete, and put, as well as supporting lookup and default.  Anyone can actually now create their own dispatch mechanism, since this functionality has been generalized.  Simply subclass Dispatcher, override _dispatch() and go to town.  I look forward
to seeing what kind of crazy code this brings to TG land.  A lot of discussion has been had on how to make “plugins” or “extensions” for TG, and you can rest assured that we will have this functionality soon.

Thanks

Thanks to all of my house mates who put up with my “mothering”.  Thanks to all of you who tolerated my “um”s at my talk on Sphinx, and especially to Georg Brandl who answered some questions.  Thanks to the organizers, volunteers and staff that came together to create what has been my best Pycon to date.

Pycon 2009

February 4th, 2009

So, Pycon registration has been up for a few days, I will be speaking both on and off-podium (read: open space) and providing assistance to and presenting tutorials.  Here is a run down of what I am planning in case you wanted a little bit more in-depth information.

Tutorials:

Turbogears2 Beginner and Intermediate:

I will be assisting Mark Ramm by giving individuals help installing and using the new TurboGears2 framework.  Mark is an experienced tutorial presenter, an expert in the technology, and in general a fun character to spend a few hours with.  When you leave his tutorials you should expect to have a working version of TG2 on your machine, along with an understanding of Model, View, and Controller paradigms.  Middleware, Forms, and REST will also be covered.  One note, if you are getting started with TG2, it’s best to have it installed and running if you plan to attend only the Intermediate Section.  We will not be going over installation in the second-half.

 Toscawidgets: Test Driven Modular Ajax:

I am presenting this tutorial which will describe how to use the valuable Toscawidgets package to create web content.  If you are currently use WSGI technology, and are interested in creating reusable, modular web content, this is a perfect way to get started.  I will show you how to configure TW middleware to work with pylons (which is applicable to other frameworks like repoze.bfg, paste, or even plone/Grok).  I will then describe how you might use this middleware to generate web forms.  The last few hours of class will be devoted to using the JavaScript utilities of TW to create an Ajaxified website, and test it using YUITest.

The Big F’ing Tutorial: Development Using the repoze.bfg Web Framework

I will assist/present with Chris McDonough about this up-and-coming framework who’s goals are to utilize bits of the zope 3 framework, wsgi, and new technologies to make a lighting-fast web server.  Those of you who are familiar with Zope technologies may be interested to find how nicely some of the familiar bits of zope are integrated with wsgi with repoze.bfg.

 Presentations:

Using Sphinx and Doctests to provide Robust Documentation

This is a 1/2 hour slot which describes how you can integrate tested documentation with your source code… with sanity!  I go over a quick install of Sphinx, and use some screencasts to demenstrate how to add, run, and display doctests using it.

Open Space:Agile Development with SQLAlchemy and Python Testing Tools

I really enjoy giving this talk, and even though it was not accepted as a formal talk, I will find a venue by way of Open Space to express my knowledge of Testing, SA, and Nose.  I have given this talk a few times now, and it’s fairly polished.  My presentation, while on some dry topics, won’t put you to sleep.  Carefully prepared screencasts and photograph-punctuated slides makes the 45 minutes breeze by.  Questioneers/Hecklers welcome!

 Sprint Topics

I want to spend some time with the Dispatch of TG2, and probably push Sprox further a bit.  If you are just starting with TG, please feel free to contribute.  Sprinting is a great way to learn a lot from the experts in the domain.  We usually do a meet-greet-install the night before the sprints.  Oh, and I’ve been known to provide refreshments to all of our sprinting hordes (read: FREE BEER).

So, I hope to see all of you there!  If you see me in the hall, feel free to introduce yourself and tell me what you are using Python for!

Coding Binge

January 27th, 2009

I haven’t written to the blog in a while.  Quite frankly, I’ve been busy.  In the last 30 days, I have released 3 software new packages, updated 1, deprecated 1, participated in a sprint that lasted a virtual 2 weeks, closed countless tickets, and pushed forward TG2 functionality.

TG2b4 was released last Saturday.  This was mostly a bug-fix release, but b3 is where the new functionality really came into the scene.  TG2b3 is the first build to include Sprox, a new library for schema-generated widget generation.  Sprox is the offspring of DBSprockets.  I decided I liked the declarative part of DBSprockets so much I wanted to spin it off as it’s own entity.  Sprox looses DBSprocket’s table-based dependency, utilizing the mapping provided by SQLAlchemy.  I realized that much of DBSprocket’s code was doing precisely what SQLSoup was designed to do, and decided to focus my efforts on making and extremely configurable widget base.  The result was a considerable removal of the cruft that was associated with DBSprockets.  Sprox releases with an excellent documentation base provided by Sphinx.

There has been a bit of resistance to Sprox, people were/are confused/upset about my providing yet more options for schema based widget generation.  The fact is I have yet to find anything that performs as well as Sprox from a developer/speed standpoint, and I needed to provide our TurboGears user base with a better way to administrate their site, and also allow them to use that tool component-wise in their system.  I think this method for developing widgets is well done in other frameworks, and we need a solid answer to this problem.  Sprox is just that.

The next step was to re-work Catwalk to use Sprox.  This took a little effort, and I put in RESTful URLs while I was at it, but struggled with making the URLs work within TG2’s dispatch system.  The result was as close to REST as you can get without conforming to a set standard.

The result of hacking REST into Catwalk got me thinking, and I decided to implement content-type dispatch as well as RESTful dipatch in TG2.  I went back for another round on Catwalk, and converted it over to the standard.

I’ve also been toying around with Dojo at NREL.  I’m pretty much done with ExtJS due to licensing issues, a not-so-hot codebase, and weak support from IRC.  It’s bad when you go on to ask a question on the channel as a 6 month-user of a software project and end up spending all your time answering everyone else’s questions (as the most experienced person in the room).  Something must be said for an organization that does not push paid consulting as a primary focus on their website…  #dojo has been an exceptional resource for getting my work done.  Those guys know their software, and lend a great hand to help you with it.

Back to the topic at hand… I was able to shoe-horn Dojo into Sprox with little effort, and implemented DojoCatwalk, which worked, but was ultimately not what I wanted.  What I really wanted was configurability.  I started work on tgext.admin, which was supposed to provide enough functionality to replace tgcrud, a command to auto-create crud in your own TG application.  To support tgext.admin, I created a new package called tgext.crud, which provided a CrudRestController, which is a simple way of providing crud for any object in your model.  AdminController combines this functionality with that of Mark’s lookup code to provide a fast, configurable set of tables/forms/etc for all objects in your model.  AdminController takes a declarative AdminConfig as input which provides a consistent way to create your administrative toolset.  Did I mention it does Dojo tables with ajax loading?  Yeah.

I’m not done with this binge yet.  Catwalk is going to mutate one more time before I’m through with it.  It is going to become a default-configured AdminController specifically designed to work within the context of a quickstarted TG2 application.  I had one blocker ticket which was solved last weekend, so it’s time to get Catwalk good and finished.

DBSprockets is back, Baby!

December 12th, 2008

So I have had a pretty long hiatus from working on dbsprockets, but I’m back… with a vengeance.  So, I worked hard to get Rum working in TG2, but struggled my ass off and got nowhere.  Left tangled in a web of peak-rules that I did not want to decipher, I began to think about dbsprockets again.  I mean, were we really that far off from what RUM is offering?

The answer turned out to be no.  All I needed to do was to replace the dbsprockets primitives with a class structure.  This turned out to be about an 8 hour job.  Not bad for a day’s work.  And now you can do things like:

from dbsprockets.declaratives import FormBase
from myWebapp.model import User
...
class RegistrationForm(FormBase):
    __model__ = User
    __limit_fields__ = 'user_name', 'email_address', 'display_name', 'password', 'verify'
    __required_fields__ = 'user_name', 'email_address', 'display_name', 'password', 'verify'
    email_address = TextField
    verify = PasswordField('verify')
    __base_validator__ =  Schema(chained_validators=(FieldsMatch('password',
                                                        'verify',
                                                        messages={'invalidNoMatch':
                                                                  "Passwords do not match"}),))
registration_form = RegistrationForm()
class ATurboGearsController(BaseController):
    @validate(form=registration_form.__widget__)
    @expose('genshi:sproxtest.templates.register')
    def register(self, **kw):
        pylons.c.widget = registration_form
        return dict(value={})

This turns out to be a much simpler way of handling forms, because now you can subclass to your heart’s content (for instance, make one base user form which you subclass for admin, registration, profile and login), or even come up with your own wacky WidgetSelector that chooses widgets for you and subclass as you desire. Here is initial documentation, which I will express in more detail at a later date when I have more time to do it the right way.

The simple fact is that you can customize form widgets with ease, limit fields to a set of fields, drop a few fields, basically anything you can think of to change how the database schema actually displays on the page.  The same is true of field validators.  Simply define an attribute of the class that has a validator, widget instance, or widget type, and dbsprockets will do the right thing.  If you want to override both the field and the validator, all you must do is create a widget wit the validator attribute populated.  The greatest thing is that your forms (and tables!) will change with you as your database schema migrates.

Right now I am keeping the primitives way of getting the values from the provider to populate the tables/forms.   This is likely to change in the future.  The primitive way of doing forms is now deprecated.  I will be adding deprecation warnings to the code.  Hooray!

Look for ajax support in the near future on both the view and data side of things.  I have a clear understanding of ExtJS (2.0.1), JSON, and LGPL now and I am not affraid to use it.  In the mean time, a dev version of dbsprockets 0.5 is up at pypi.

CTS solution, a new keyboard?

December 8th, 2008

http://www.flickr.com/photos/finpix/2804562484/

Any of you who know me know that I have been struggling with carpal tunnel syndrome for the last year or so.  A combination of working with a laptop in an ergonomically undesirable position, frequent days longer than 12 hours coding, and my personal winter vocation (ice climbing) put me in pretty consistent pain.   The problem with ice climbing is as you reach to place your tool into the ice, your wrist bends at an acute angle.  Then, to move your feet up, you must weight the bent wrists.  The pain got to the point last February where I had to completely stop climbing ice, despite having a trip planned for Ouray.  Even rock climbing had to stop, relegating me to short day trips to the Flat Irons (mostly footwork climbing) until things improved.

The pain lessened long after the ice was melted, and I was able to return to  a pretty regular climbing schedule, but often pressures from my clients would cause the wrist pain to flare up.  I used wrist braces to help keep my wrists in correct position, but I was simply unable to maintain my usual pace without going to bed at night with aching wrists.

West Gully of Black Lake, RMNPWith ice season approaching, I had to find a solution to this problem, as I really love climbing ice, it brings you to some pretty spectacular places.  At Plonecon this year, I saw two people with the same unusual keyboard, a Kinesis Advantage.  I asked them about it, and everyone gave it good reviews, saying that it really helped them.  When I got back from Plonecon I plunked down $250 for a refurbished keyboard at home, and started carting it back and forth to work.

This keyboard is not one who’s transition you can take lightly.  As you can see, it has an unusual physical layout, but if you have been using a Microsoft Natural Keyboard, the transition may not be too bad.   One think that took a while to get used to is that the keys are aligned vertically.  This creates a lot less strain, but is quite unusal at first. After a month or so of use, I can say that my typing skills have returned to what they once were, even in a programming environment, where you have to use weird symbols, and the arrow keys a lot.

The keyboard has helped me reduce the amount of pain in my wrists enough that I can resume ice climbing.  However, the change comes about not only because the keyboard offers better ergonomics, but it has changed the way I type, equalizing the work that both hands do.  If your keyboard is more than 6, months old, pick it up, and hold it at an angle so you can see which keys have a glossy shine, and which ones are still opaque.  You can learn a lot about a way a person types by examining their keyboard.  Do you use both shift keys?  Which  thumb do you use to hit the spacebar?

The biggest struggle for me with the new keyboard whttp://farm1.static.flickr.com/127/321996427_ae5fb8fa54.jpg?v=0as the fact that the “b” key is on the left hand.  I’ve been typing that one with the right hand for as long as I can remember.  When I look at how I used to hold my hands over the keyboard, I can see that the left hand is bent a little, which makes hitting the “b” key a little more difficult, which is why I probably did that with the right hand.  Also, I used the left shift key exclusively.  I still struggle with that, but I am getting a better about using the right one as well, you just have to take a little more time when typing capitals to be able to use both.  (This would really suck if I was a JavaProgrammer)

Besides helping improving my typing prowess, the keyboard offloads a lot of work to the thumbs, eliminating the wrist-snapping alt-tab combination that caused the majority of my problems… In fact, ctrl-c, ctrl-v, ctrl-x, where I spend a lot of my time is now a two-handed affair.  This takes a lot of the stress off my left hand, which had much worse pain than the right.  Lastly, the arrow keys are moved to below the left and right hands, and while this is a little weird to get used to, it is nice not having to move my right hand to get to those keys.  It also forces me to use both shift keys more, since you must use them to highlight text the way you need for cutting and pasting.

While the Kinesis keyboard is pretty unusual, and a bit hard to get used to, the keyboard comes with a set of exercises which really helped me get used to it.  The first day, the exercises probably took > 2 hours, but after a week of doing them, I had that down to < 25 minutes.  In between I used my old keyboard, because I just had to get work done, but I used the Kinesis more and more over time, and after a month, it is now full time, and I really don’t like using standard keyboards, but the transition going between the two is not too bad.

This is kind of a long post, but if you are having RSI, and aren’t sure that spending $250+ dollars is going to be worth it, perhaps this blog post will help you decide.   My refurbished keyboard at home is not discernibly different from the brand new one my work purchased for me, and both have worked for a month rock-solid.  The one thing I noticed was that the Kinesis had a somewhat higher energy profile, requiring me to replace my 4 port usb hub with a powered one.  I might add that I had the mouse and old keyboard plugged into the Kinesis, so it was in fact drawing the power of 2 keyboards, if you have the ability to simply replace your old keyboard, you may not see this problem.  Lastly, you are able to re-map the keys on the keyboard, which I did with the up/down keys.  This opens up the posibility for a dvorak layout, but the home keys are different from the other keys, so it might be worth it to invest in the more expensive version that comes with special keys designed specifically for this layout if that is what you prefer.

SQLAlchemy Migrate Process Hiccups

December 5th, 2008

So, I’ve done migration processes for two medium-large database schemas (50-100 tables) and I have found what I believe to be a disconnect in the process of migrating and a database and developing a database application.


The Problem
——————-
Here is the problem in general.  I am sorry it is so long winded, but it’s hard to see what is going on without this full expression.

You create a schema, and use that schema to create a database.  Maybe
you are using Pylons, and using setup-app to create the schema. Everyone is happy in schema land, and then someone realizes you need to make a change, and maybe even more changes in the future.  You decide to use migrate, because hell, migrate will make things easier. So, you write the migration, modify your model code and everything is honky dory.  Clients are happy, your developer feels like he has a maintainable codebase.  Your project begins to grow.  Awesome.

Not Awesome.  Your second developer needs a development environment. You give them your model, they setup-app it and they are ready to go. While they are plugging along, you realize you need a new migrate, so you create it, and upgrade your development version of the database, which is now at migration 2.  The production also goes off without a hitch, it’s now on 2.

What about your new development buddy?  When he ran migrate_version, he set his database up to version 0.  So, migrate will try to do 0->1 and then 1->2, but 0->1 will fail because his database is already at version 1 even though his version table says its 0.  Now he is in pain, and re-creates his entire database to get moving, and the whole cycle starts over again, although he can work… until you do the next migration.

This is not ideal, and I have been struggling with it at one of my clients.  In that situation, I am the developer buddy, bopping in from time to time to lend a hand.  I spend probably 5% of my time getting up and running, where if their migration system was somehow linked to their database model, I could be synchronized, and actually use it for a development tool, rather than a dusty old production tool.

Solution 1
—————
So, I came up with my own solution, and have talked to a close friend about an alternative solution.  I’d like to discuss both of them as they pertain to migrate, in the hopes that we can improve migrate, and  re-connect the development environment with the production one.

My solution is to connect the model base code to the migration version.  The way I accomplish this is to add a version.py file at the root of my model code, which has, incredibly, the version of the migration changeset that matches this model definition.  I also have a custom database creation script which creates a migrate_version table and fills it with a record of the correct version number.  Now I can svn up, and migrate up and everyone is happy. The problem with this method is that I have to maintain a damn file with the version number, and not go insane doing it.  Since my model contains 3 different database schemas in it, that means I have to maintain 3 variables in my version.py .  Personally, I don’t mind this, but I had to write more documentation than the amount in this post to make certain that my predecessors (or me in 6 months) can figure out what the heck is going on.

Solution 2
————–
The second solution, which Mark came up with, is to preserve the initial model.  Then, you do all of the migrations to bring you up to the current codebase.  This does not require any version file tracking, and if your migrations add boilerplate entries, you don’t have to record them in a second place. I think solution 2 is reasonable, but could be more time consuming to execute (which is probably not really a problem with everyone’s 2ghz machines these days).  The problems I see are that the boilerplate entries you make for production may a not be the same as you make for development.  This makes testing a bit harder if they differ. I also feel that solution 2 is more prone to problems, simply because there are a lot more cranks to turn to get a development database.

How can migrate help
—————————–
The way to provide solution 1 to the problem in migrate would be to allow the developer to connect his migrations to his model code, and allow migrate some level of control over the “versions” module in the model code.  So, when you do a migrate commit, you are also saying that the model code supports this version of migration.  It will probably only take me  a few hours to make this happen.  We then create an easy way to create the migrate_version table by importing something.  This way you can have a custom createdb script that also creates the migrate_version table.  Perhaps we could even provide a reasonable createdb template.

Solution 2 only requires us to provide a custom creation script.  For this we will have to preserve the initial schema (schema 0) and then upgrade.  We could probably also include a template instead of a script so that you can manage boilerplate on your own.

My own conclusions
—————————-
I lean more towards solution 1, mostly because I feel that it will provide for easier boilerplating, because you will have access to your whole model at once, instead of bits and pieces of your model as it moves from one version the next.  I also think the boilerplate for dev. is likely to be a lot different than that of prod for most folks, and I feel like solution 1 offers an easier way of handling it.  It also seems like solution 1 is much more efficient, because you don’t have to go and re-do all of that migration work, you have already arrived at the correct-for-now solution.

If you made it this far congratulations!  Now, go grab a cup of coffee, stretch your arms, come back and tell me what you think.

Barcode Meme

November 24th, 2008

A few months ago at Ploneconf I met Manabu Terada from Japan who had a 2d barcode on his business card.percious's information  This was intriguing to me, and he showed me how his Nokia phone could read in his card, and store his contact information for later use.  Since that time I spent a little bit of time figuring out how my own iPhone could do the same thing, but I had been turned off by the poor image quality the iPhone has, with it’s lack of macro mode.  Well, Grifin has solved that problem.  And Nokia has provided us all with an online version of a barcode generator.  To round out the suite, there is free software available for the iPhone.  So, above you see the barcode for my contact information.  Perhaps you could provide your own barcode with some cheaky message?

Google Summer of Code Mentor Summit Recap

October 29th, 2008

I spent last weekend in Sunnyvale, CA at the GSoC mentor summit.  This was a great opportunity to rub elbows with a number of experts in various OSS projects.  It was great to make connections with people in and out of the Python community.  First off, I just want to thank Google, and Leslie Hawthorne for having us. Google was an excellent host, and I would jump at the chance to attend a Google-hosted event again.  Google is using GSoC to promote the open source community.  By providing funding for students to work for a summer on software instead of flipping burgers, they hope to save the world, one open source project at a time.  I have my own take on what Google’s true intentions are, but I don’t really want to discuss that in this blog entry.  That is to say, I don’t think Google’s intentions are in any way evil, but they are definitely self-serving.  In any event, it is remarkable the amount of time, energy, and money that goes into this project, which is at this time one of a kind.  Here’s hoping that other companies will consider the not-so-small buy in for sponsorship which could lead to even more OSS development.   

As for the summit itself, there were lots of talks.  Since it was run like an open-space conference, it took a little while to work up some speed the first day, but I never found myself want of something to do.  I was not surprised that the talk on monetizing your OSS project was wildly successful.  I was surprised at how easy it was for sessions to get off on tangents, but it was interesting to see how people in similar fields were solving projects.  I attended a session on Scientific Computing (since I work for NREL) and it seemed that the biggest problem the room faced was packaging/deployment of software.  I appears this problem cross-cuts platforms, language, and even hardware barriers.  It also seems that you either have a choice to make: stick with old software that is stable, or upgrade to new stuff that almost always breaks other things.  Sound familiar?  I wonder how long it will be before everyone runs isolated virtual machine images for each of their projects… I bet some already are.  

By day two I was pretty exhausted of participating in sessions, and I just wanted to hack with some like-minded folks.  It turned out that at least 8 people at the summit were hacking on making their application run on Python 2.6, so we all got together and shared the good vibe while we solved our individual problems.  The main barrier for TurboGears 2 running on Python 2.6 was ToscaWidgets and TurboJson.  First off, peak-rules needed some minor tweaking to get a few of the bugs fixed.  Thanks to Philip Eby for implementing my patch (in a slightly different way) and making it all work.  ToscaWidgets was also breaking with the SimpleJson trunk, but this turned out to be an implementation error, and I think I have it mostly sorted out.  

Yesterday evening Mark and I finished up packaging the !first beta! of Turbogears2.  I put a few custom eggs in the index from my GSoC hacking, and suddenly we have a Python 2.6 compatible release.  Also, of interesting note Gustavo Narea cranked out tgext.authorization which handles most of the security for TurboGears2.  Now I just need to get cranking and fix DBSprockets Primitives to work with Rum, and then fix silverplate to support Rum also.  (Perhaps this is my way of telling people to move in the Rum direction).  

Mark and I will be attending PyWorks in November, and doing a sprint then.  So, if you are in town, or interested in sprinting remotely, please don’t hesitate to sign up.  I will be speaking at PyWorks on using PasteScript, Virtualenv, SQLAlchemy, and Nosetests to create robust database applications. Do you think there is anything else I could cram in a 45 minute talk?  I will also be helping Mark out at his TG2 tutorial, so if you aren’t signed up for PyWorks, get crackin’ !

Plonecon Recap

October 13th, 2008

Last week I attended Plonecon in Washington D.C.  We use Plone quite a bit at NREL, and I  wanted toploneconf come up to speed on the state of the art, and see if I could find some folks to collaborate with on the Scientific Data Management front.   I was not only surprised by the number of people in attendance, but also by the progress being made in forefront of Plone development.

Of course, one of the big news items was what is known in the community as the “Plone tax”, which is a reference to the 30+ seconds it takes to start Plone.  It was announced that this has been reduced to 6 seconds, which in my mind is still too much, but I am glad they are making progress in this area.  [edit] I believe the speedups were achieved in the trunk of plone, not for 3.2.   Plone 3.2 is supposed to be all eggs, which I think is a great benefit to the community.  I have already been using Plone in this manner with Repoze, which packaged Plone as an egg a few months ago.

I was impressed by the changes to the user interface which were proposed by Alexander Limi in his talk on the future of Plone’s user experience.  It looks like portlet/viewlet terminology is being supplanted with the term “widget” which I think is more standard in the web design world. I think the new user interface is more intuitive, simplifying the page down to those components which will be most important, while still making available all of the functionality of Plone.

I was also impressed with Kapil Thangavelu’s content mirror.  While I don’t think his project which takes Plone content and injects it into an sql database will be immediately useful to me, I think it offers a nice path for someone who wants to convert their Zope/Plone site over to an relational-database based site.  It also provides a nice bridge for someone who wants to use existing relational database tools to mine data penned up within a zope database.

Coming from a TG background,  I was of course interested in Repoze.  Chris McDonough gave a compelling talk on repoze, specifically repoze.bfg and what is motivation was for creating yet another framework. We ran a BOF together, and had quite a bit of response.  I demo’d using Toscawidgets within Plone (running on repoze.plone).

Craig Swank and I also demo’d one of our repoze.plone application for a group of people interested in laboratory informatics systems.  I started up a google group for this, and I sincerely hope that our small community can find a way to collaborate efforts in order to increase our productivity in a way only OSS can.