Blue Sky On Mars

Paver is the Python-based build tool that I released several months ago. It uses a Rake-like approach; you create a .py file that is filled with “tasks” which are basically just functions that can be invoked from the command line. Paver has largely been focused on automating Python projects.

Last week, I got together with Marshall and Matt from Zattoo. They’ve been working on a tool called pytoss which is focused on deployment. There are two parts to pytoss: the library and the “tool”. The library is being broken out into a new project called CloudControl, and it provides all kinds of high-level, handy deployment goodies on top of Paramiko. And it’s liberally licensed.

There’s a lot of overlap between pytoss’ tool component and Paver. So, we got together to see what we can do about that. The two approaches were already quite similar. There are a handful of small differences, and I like some of the pytoss approach. At a high-level, here’s what’s going to happen:

• the pytoss tool part will go away
• Paver will become less Python project-specific (but won’t lose the Python project-specific features it has)
• the small bit of magic that Paver has will go away
• Paver will add some optional support for CloudControl for deployment
• Paver will also inherit some nice features like the easy ability to run sub-builds (build other Paver-based projects)

These are just the changes that are in store based on the pytoss integration. There are some other cool features that I have in mind.

I have also decided to move Paver from Launchpad to Googlecode. I find Launchpad to be far more confusing, especially for a small project like Paver. Additionally, bzr’s svn plugin appears to make it so easy to sync with a central server that there’s no reason to make everyone use bzr. Those who want to, can. And those that are used to svn can use svn.

Paver’s official homepage is unchanged, there’s just a new project page, bug tracker and source control URL.

A big thanks to Matt, Marshall and Jonathan for CloudControl and for helping out with Paver!

Python Paver

Short form: I’m looking for a job. Are you doing something interesting? And hiring? Send me email! kid @at@ blazingthings.com.

I’ve opened up my LinkedIn profile to make it easier to get a quick rundown.

I bring a lot to the table: 20 years of experience in product management, management and software development. Some of my work in Python is out there and well-known. In September 2005, I released TurboGears, which led to an interesting and fun flurry of activity for me (talks at PyCon 3 years running, plus talks at EuroPython, CodeMash and the upcoming PyWorks conference, the Prentice-Hall book with Mark Ramm, the self-produced and published DVD, etc). At Arbor Networks, I applied Python (and others) in many parts of their security product, and even convinced them to release TGWebServices, an open source library that takes the pain out of SOAP. And, this year at SitePen I released the Paver build tool.

Most recently, at SitePen, I was the Product Manager in an otherwise custom services company. I oversaw the launch of SitePen’s growing Support service, and the Dojo Toolbox, created in collaboration with Adobe.

Throughout my career, I’ve been taking collections of raw materials and turning out packages that customers can really use. In the earliest part of my career, I created insurance company billing software for doctors’ offices. The people using that software were decided non-technical. I had to quickly learn to speak their language, figure out what they needed to accomplish and then make it happen. I also had to help spark their interest in our product.

And, I’ve been doing that all along. My audiences have varied and my role has varied (sometimes I’ve been a manager with people reporting to me, other times I’ve been a developer on the team), but the product management aspect has been there all along. I’ve also spent a couple of years doing enterprise sales and have been involved in marketing along the way.

Of course, I’m also a very technical person. I did a lot of the software development on the SitePen products I was involved with. I have a ton of experience in Python (going back to 1995), plus solid experience in JavaScript, Java and Perl. I’ve been using relational and other styles of databases forever. I’ve been using some variety of *nix since the early 1990s.

I’m located in Ann Arbor, Michigan and I’m willing to telecommute (and have done so for 4 of the past 10 years).

There are many jobs out there listed on the various jobs sites, but I also know that there are plenty of great opportunities that are not listed on those sites. If you happen to know of one, let me know!

Python, Random

I just got a mysterious package in the mail from Pearson. It felt like it contained a book… and, indeed, inside there were two copies of Rapid Web Applications with TurboGears in Simplified Chinese:

I can only assume that Benjamin T. Hamilton, who is prominently quoted on the front cover, is saying good things about TurboGears and Python

Python, TurboGears

A month ago, Bruce Eckel wrote about wanting to remove the explicit self parameter from function argument lists in Python. Personally, I don’t mind the explicit self. To me, it makes it feel like all function objects are equal, even those that happen to be methods on classes. That said, Guido wrote an in-depth response, and I certainly recommend that you check that out if you’ve ever considered getting rid of the explicit self.

After reading Guido’s response, I assumed that there must still be some way to eliminate the need for self in Python. Python is an amazingly flexible language. Further, I assumed that somebody had already done it. And sure enough, Michael Foord wrote an article that includes a metaclass called Selfless. As I suspected, this metaclass had to resort to bytecode manipulation. You really can’t change a lot about code objects in Python. I have no intention of using Selfless myself, but the Byteplay library that Michael links to seems neat and interesting.

Python

We are excited to announce the keynote speakers for this year’s php|works and PyWorks conference to be held in Atlanta, Georgia in November.

In the opening keynote, Kevin Dangoor, the founder of the TurboGears Python web framework project and, more recently, the Paver Python build tool project, will be speaking about growing your open source community.

[From php|works/PyWorks Keynotes Announced ]

Though it’s been on the schedule for a couple of weeks, Elizabeth Naramore has officially announced that I will be giving the opening keynote at the first PyWorks conference (I’m not sure how many years php|works has been going). This is a cool, combined conference, and I wanted to pick a topic that I think is fun and will be useful to both Python users and PHP users.

If you’re looking for screenfuls of code, this is not the talk for you (my other three talks are more code-filled). But this is going to be a very practical talk filled with things you can do right now to bring more people into your open source projects.

Python pyworks

The Detroit Java Users Group is meeting out at ePrize tomorrow for a talk about DWR and Dojo. I’ve been wanting to learn more about DWR, so this is a good chance. I’ll be heading out there to the meeting and SitePen has provided me with some Dojo goodies to give away (t-shirts, books and stickers).

I hope to see you there!

Java

At PyCon in March, I spoke about how applications can be browser-driven. For the past few months, I’ve been involved with a browser-driven app. Remarkably, some of the same kinds of problems crop up when making a browser-driven app as when you’re making a traditional server-driven webapp. So, today I introduced something called Reinhardt, a client-side web framework. Using Dojo’s Django Template Engine implementation (dojox.dtl), Dojo’s data model (dojo.data) and Reinhardt’s new Django-inspired URL dispatcher you get something that approximates a server-side web framework all on the client side.

JavaScript, Software Development dojo, reinhardt