Archive for February, 2009
February 27th, 2009 by Mark Ramm
TurboGears 2.0 beta 6 comes with lots of fixes, and a total feature freeze in preparation for the first Release Candidate. From here on out to 2.0, we’ll only be doing bugfixes and improving our Docs. Speaking of Docs, Beta 6 comes on the heals of this last weekend’s doc sprint, so it already comes with new and improved documentation.
One thing which you should be aware of in Beta 6 is that after you install tg.devtools and quickstart a new application you have to do python setup.py develop on your quickstarted app because some of the dependencies for the app are not installed until that time. This allows you to remove optional dependencies from your application if you’re not using them.
Jorge Vargas has completely rewritten the Install doc. Anita has done great work on the Wiki 20 doc, which is providing an ever improving introduction to TG2.
Christoph Zwerschke has update the ToscaWidgets forms doc, Chris Perkins has documented the new RestController stuff which simplifies common Create, Read, Update, and Delete operations. And I created an overview of the TurboGears 2 stack. There are also new docs on the alternative template engines.
And of course there were also many, many smaller updates spread across the TG2 docs.
We are nowhere near where we want to be with the TG2 docs, but they are shaping up quite nicely. And we’re getting very close to the final release.
It’s been a great ride, and I’m already looking forward to some of the great things in store for 2.1.
February 20th, 2009 by Mark Ramm
We’ve declared a final feature-freeze on TurboGears in the runnup to the 2.0 release.
But that doesn’t mean that there’s not still lots of work to do. We’re working on a updates to the TG website, radically improved documentation, and better marketing materials. So, we’re having another TG2 sprint this weekend, but this sprint will be focused on infrastructure documentation, and will be the most newbie friendly sprint ever since one of the primary tasks is to make sure that the docs make good sense to new users.
Documentation is hard because the people who write it generally are experts, and have forgotten what’s complicated/confusing to new users. So we really, really need fresh eyes and fresh perspectives.
And one of the most useful things you can do is read and comment on our docs:
If you have a few hours, please join us in #turbogears on IRC on freenode (see this tutorial if you’re new to IRC) and sign up for the sprint here:
February 12th, 2009 by Mark Ramm
Interesting stuff here. This came up again at my new job, and I remembered that I’d forgotten to blog about it when I first saw this blog-post.
NGINX is an amazingly fast lightweight web server, and Server Side Includes (SSI) seem to be making a comeback as “composed” pages become more popular and traffic levels go up.
This is interesting because it lets NGINX provide super-fast and easy to use access to memcachd cached pages, and with SSI you can restrict the dynamic portions that have to be handled by python to the smallest possible portion of the page. If the pattern fits your application really well, you can see very significant increases in the number of requests-per-second you can achieve this way.
I’ve been fooling around with SSI+nginx too for another project, but and have been meaning to blog about it but haven’t had time to get anything ready to publish. I do intend to write a detailed tutorial on this setup someday, but for know this is a great if super-high velocity introduction to the how of SSI+Memcached+Pylons. And of course you can use TG2 with this in exactly the same way.
February 11th, 2009 by Mark Ramm
This year at PyCon we’ll be using turbogears 2.0 final in the beginning and intermediate TG tutorials, and there’s lots of great stuff to cover:
* A new “admin” system
* New REST support in controllers
* Improved automatic form generation via sprox
* Built in user/groups/permissions system
This year’s tutorial will be much more interactive than last, and will be focused on TurboGears more narrowly than last year when we did TG2+Pylons. We’ll be covering lots of stuff that can be used in Pylons, but since TG2 configures all this for us, we’ll be doing it the TG2 way.
In addition to the beginning and intermediate TG tutorials, there will also be a full day of SQLAlchemy tutorials, and a ToscaWidgets tutorial.
If you really want to maximize your learning experience, I’d recommend this list of tutorials:
If you haven’t used SQLAlchemy before and want more introduction than the TG tutorials provide, you might want to switch out the ToscaWidgets tutorial for the Introduction to SQLAlchemy.
And if you really want to maximize your TG experience, there will be a couple of TG experts that will work with you on some open source TurboGears applications at the sprints after the conference. I think working with the core TG team on real application code is a great way to round out the Tutorials and maximizing your learning.
This is an incredibly great two day learning experience at an incredible price. I’m really excited about how much PyCon in general and the tutorials specifically have to offer TurboGears users this year. I think the two full days TG related tutorial, opens up the possibility go go into much greater depth, and when coupled with the sprints, provides a great way to learn more about turbogears.
February 9th, 2009 by Mark Ramm
SQLAlchemy Migrate 0.5 was released last week, and it got me thinking about how important it is.
Evolutionary Database design and data schema refactoring critical to most projects these days, and pretty much everywhere I’ve worked over the past 10 years, we’ve handled database upgrades via a set of sql upgrade and downgrade scripts, a db version number in the db, and a upgrader/downgrader python thingamabober.
A few years ago I did a couple projects in Rails, and Rails Migrations made this easier, by providing a standard API. There were limitations, and worries about lost data, and sometimes it wasn’t clear what SQL would be generated — but it was good enough, and worked well enough, that everybody used it.
But what I don’t like about ActiveRecord, and other ORMs like it is that every object-property change ultimately requires an underlying database change. On large projects I really want the flexiblity of a data-mapper to insulate some of my OO code and OO design decisions from the need for database level changes. I think this is incredibly important on very complex projects where the “data model” needs to change quite frequently, but the underlying database schema needs to change less frequently. SQLAlchemy on the other hand provides a clear, simple, elegant solution to that problem by decoupling the Objects from the Relations by providing an explicit Mapper.
But even with the flexibility of a Data Mapper based ORM, you still need to update your database schema sometimes. And that’s where SQLAlchemy-Migrate comes in. I think it or something like it is an indispensable tool in the SA user’s toolkit.
TG2 ships with both SQLALchemy and SQLALchemy-Migrate. And provides a little bit of help to make migration development even easier.
There’s more we can do to integrate Migrations into TG2, mainly by documenting it better, and setting it up a bit more in quickstart. I know there’s a trade-off there too, because for a lot of smaller applications migrations are too much overhead at the beginning, you can more easily wipe and recreate your database as you make changes, and we should support that way of working — so nothing we do should make that harder.
With that said, I’ll know we have arrived at the right place when we’ve made evolutionary database development or database schema refactoring easy enough that it feels natural and easy, and not doing it feels uncomfortable.