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 🙂
For various reasons, I released Paver 0.7.3 on Friday and Paver 0.8 yesterday. I have an idea of what the coming 1.0’s zc.buildout integration will be like, and I think it will be quite cool and useful.
In the meantime, though, I’ve got some new features that set the stage for things I need to do in 1.0. Specifically, you can now pass in a dictionary in your options search ordering. So, you can pull options from any source you’ve got at the time the task is running and stick them at the front of the line. I expect to use this in buildout options handling.
A nice new feature is the ability to set options on the command line. You can do something like:
paver some.option=hello task1 some.option=goodbye task2
Doing that, paver will set some.option to hello, run task1 and then change the option to goodbye before running task2.
The new cog.include_markers and cog.delete_code options allow you to remove Cog’s markers from the output and instead put a nicer bit of text to say where the snippet of code came from. Letting the user know where a sample code snippet came from is quite valuable, so I want to make it possible to do so in as pleasing a way as possible.
For Paver’s Getting Started Guide, I ended up not using the new include_markers feature and instead just changed the Cog delimiters. I did this because Paver runs shell commands in addition to including file sections when generating the docs. I wanted those shell commands to be included. I think the new markers are more pleasant to look at, and I’ll be curious to get feedback since I heard from more than one person that the Cog delimiters looked like they were left in by mistake.
Paver is starting to get some traction as it has picked up its first patches from outsiders, and I’ve started to get some feedback on breakage from Windows users (fixed in 0.8). Mark let me put Paver into TurboGears 2, and I think it will help out there, so that will introduce quite a number more people to the project. As always, come and join us on the mailing list if you have any questions or problems!
I have recorded a screencast of my PyCon 2008 talk and put the code for the demo app online. Check it out on the SitePen Blog Â» Rich UI Webapps with TurboGears 2 and Dojo Screencast.
TurboGears has been accepted as a Google Summer of Code organization. Chris Arndt has put together a page at docs.turbogears.org to pull together all of the TG Summer of Code information. Congrats to Chris and the others for pulling together this year’s Summer of Code effort for TG!
Next week is signup time for students (March 24-31), so if you’re interested in getting paid to work on TurboGears this summer, check out the TG SoC info page.
Back when I was in the thick of my involvement with TurboGears, I remember seeing an email from someone complaining that, unlike with PHP apps, TurboGears apps cuoldn’t be hosted on $1 per month hosting accounts. While I was always interested in seeing TG apps on inexpensive shared hosts, I had no expectation that people could host TG apps for $1 per month. And, frankly, I don’t think I care about that.
Software development is full of tradeoffs. As Ian Bicking points out, PHP’s deployment model has some good aspects. As long as you stick to the constructs provided by PHP, it’s fast and the programming model is very simple and side-effect free. Now, however, PHP users want the productivity goodness that you get from higher-level OO frameworks like TG, Django and Rails. To create frameworks like those in PHP means optimizing the framework so that it loads the minimal amount of code in any given request. This is a constraint that TG, Django and Rails don’t have to consider at all, since the code is loaded once and kept resident (in any sane deployment).
The DreamHost blog recently lamented the pain of Rails deployment in their shared hosting environment. I’m frankly not too sympathetic. WebFaction seems to be able to manage shared deployments of modern frameworks quite nicely, and I assume they’re making a profit at it. WestHost provides quite inexpensive VPSes for folks who want to do it all themselves. I like DreamHost, and I’m a satisfied customer, but if others can figure out reasonably priced ways to host Rails and TG, DreamHost should be able to as well. (Full disclosure: those links are the same affiliate links that I have in my sidebar. I mention them here because they are relevant to the topic at hand, but it’s worth mentioning that following those links and buying services there does give me some money.)
Maybe DreamHost shouldn’t be looking at it like “how can I get Rails into an existing $10/month package” but rather what kind of good Rails hosting setup can i do for $15/month. Rails seems like a fine value-add… and if there are others undercutting them, then they can figure out how to compete on price.
All of this is not to say that we shouldn’t try it make deployment easier or frameworks better. It’s just not likely to be worth making the tradeoffs required to match PHP’s deployment in an effort to shave a couple bucks a month off of low-end hosting.
I’ve just received notice that my proposed talk for PyCon 2008 has been accepted!
People who were at my PyCon 2006 “Effective Ajax with TurboGears” talk might remember that I talked about sprinkling Ajax throughout a webapp as appropriate. A lot has changed in the nearly two years since. We can now move a lot more presentation logic to the browser, and the server side becomes much more of a web services layer.
I’m going to focus on what the server side looks like (this is PyCon, after all!), using Dojo to easily implement the client side. I’m also going to talk about how you can integrate Comet (where the server sends messages back to the client) into a TurboGears 2 app.
The ideas will work in any web framework, and the code samples will also work with very little change in Pylons.
I’m looking forward to this talk, and I hope to see you there! (And don’t forget to say ‘hi’ if you’re at CodeMash next month!)
Update: Wow! Check out the PyCon 2008 list of talks. This will be my third PyCon, and I must say that that is the most impressive list of talks of the three.
TGWebServices is a package that I created earlier this year to provide a simple and powerful multi-protocol web services layer for TurboGears users. TGWebServices now has a new home at code.google.com, which will be easier to maintain. Clearly, that site needs some work and a new release needs to be made to point there, but that will happen all in good time.
TGWebServices now also has its own mailing list for the first time. Since this is a low-volume project, svn commit emails will go to this list, in addition to discussion about TGWebServices.
Justin Davis from Arbor Networks will be taking over the ownership of TGWebServices. Florent Aide, the TurboGears 1.x maintainer, has also signed on as a committer on the project.
TGWS is stable and has a decent feature set, so I don’t expect to see a lot of activity. Unless we manage to get the time together to merge TGWS and soaplib, which is still a good idea.
Thanks to Justin and Florent for the continued support of TGWS!
Though it was publicly displayed a couple of days before, I announced the release of TurboGears on September 17, 2005: Blue Sky On Mars Â» Blog Archive Â» Announcing TurboGears web megaframework (Python).
Thanks again to everyone who has made TurboGears a successful and fun open source project!
About a month ago, I mentioned that the TurboGears Ultimate DVD and my other TG merchandise (MarbleGears and the toolboxes) were on clearance. I’ve reduced the prices a little more and set Monday as the last day for sales of the goods. Now is your last chance! The stuff is cheap, and I’d be happy if my fulfillment company has less stuff to send back to me 🙂