TurboGears and Pylons finally merging

This has been a long time coming, and fans of both projects have been eagerly waiting for it, but it's finally happened. Not sure if you've seen the announcements from Kevin Dangoor, Mark Ramm and Ben Bangert on their projects' mailing lists, but basically they boil down to "we feel like after the sprints at PyCon we made enough progress so that we can pull the trigger on merging the source code from the 2 projects in one common trunk." They make it sound like it was purely a technological problem, but I have my doubts about that. I think it was driven in part by the increasing popularity of Django. Unifying TurboGears and Pylons is a somewhat desperate measure to chip away at the Django market share. We'll see if it works or not. Check out the brand new page of the TurboPylons project.

Comments

Anonymous said…
An April's Fools joke is only good if it outrageous

this actually would make sense to do
Tuesday, April 1, 2008 at 8:41:00 AM PDT
kumar said…
but... it does increase the fool factor ;) Had me going for a few mins. Nice one.
Tuesday, April 1, 2008 at 10:43:00 AM PDT
ash said…
Oh dear, a bad case of TurboPiles - sounds painful.
Tuesday, April 1, 2008 at 11:17:00 AM PDT
alex said…
It is about time that Python fractured market to crystalize
Thursday, April 17, 2008 at 3:31:00 AM PDT
Post a Comment

Popular posts from this blog

Performance vs. load vs. stress testing

Here's a good interview question for a tester: how do you define performance/load/stress testing? Many times people use these terms interchangeably, but they have in fact quite different meanings. This post is a quick review of these concepts, based on my own experience, but also using definitions from testing literature -- in particular: "Testing computer software" by Kaner et al, "Software testing techniques" by Loveland et al, and "Testing applications on the Web" by Nguyen et al.

Update July 7th, 2005

From the referrer logs I see that this post comes up fairly often in Google searches. I'm updating it with a link to a later post I wrote called 'More on performance vs. load testing'.

Performance testing

The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing. To conduct performance testing is to engage in a carefully controlled process of measurement and analys…
Keep reading

Dynamic DNS updates with nsupdate and BIND 9

I first saw nsupdate mentioned on the devops-toolchain mailing list as a tool for dynamically updating DNS zone files from the command line. Since this definitely beats manual editing of zone files, I'd thought I'd give it a try. My setup is BIND 9 on Ubuntu 10.04. I won't go into the details of setting up BIND 9 on Ubuntu -- see a good article about this here.

It took me a while to get nsupdate to work. There are lots of resources out there, but as usual it's hard to separate the grain from the chaff. When everything was said and done, the solution was relatively simple. Here it is.

Generate TSIG keys

# dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST myzone.com


This generates 2 files of the form:
-rw-------   1 root bind   122 2012-03-21 15:47 Kmyzone.com.+157+02058.key
-rw-------   1 root bind   229 2012-03-21 15:47 Kmyzone.com.+157+02058.private
Note that I specified /dev/urandom as the source of randomness, which may not meet your security requirements. When I d…
Keep reading

Running Gatling load tests in Docker containers via Jenkins

Image
Gatling is a modern load testing tool written in Scala. As part of the Jenkins setup I am in charge of, I wanted to run load tests using Gatling against a collection of pages for a given website. Here are my notes on how I managed to do this.

Running Gatling as a Docker container locally

There is a Docker image already available on DockerHub, so you can simply pull down the image locally:


$ docker pull denvazh/gatling:2.2.2
Instructions on how to run a container based on this image are available on GitHub:
$ docker run -it --rm -v /home/core/gatling/conf:/opt/gatling/conf \ -v /home/core/gatling/user-files:/opt/gatling/user-files \ -v /home/core/gatling/results:/opt/gatling/results \ denvazh/gatling:2.2.2
Based on these instructions, I created a local directory called gatling, and under it I created 3 sub-directories: conf, results and user-files. I left the conf and results directories empty, and under user-files I created a simulations directory containing a Gatling load test scenario writ…
Keep reading