lucks

Get creative and make a game for the One Laptop Per Child platform. Most of the focus is on Python with Pygame or PyGTK. The window manager called Sugar (http://wiki.laptop.org/go/Sugar) has a lot of emphasis on collaboration and is very different from the window managers we are used to. Should be lots of fun. Registration extended to May 15.

It looks like there might not be database migrations for Turbogears based on this post: http://news.ycombinator.com/comments?id=2397 . (Note that the post specifically refers to SQLAlchemy, which will be used in future versions of TurboGears.)

The screencast you posted was very nice, and very similar to the Turbogears screencast in spirit. In fact both frameworks look very very similar from the screencasts, with the only differences being URL mapping, the syntax of the methods in the controller, and the templating language. All of those I can adapt to.

What I am really curious about is a few features of Rails that were just stunning and made our life so much easier when making our prototype. They were:

1.) Easy database migrations.

2.) The :AsTree and related specifiers in ActiveRecord that automatically creates utility methods for the object model (such as searching over parents/children of a record)

3.) Easy handling of session data

I haven't found any mention of these features in either Django or TurboGears and I haven't snooped enough yet to find them. If you know if they are there, and how they are done, please let me know!

I have not tried Django, but all of the discussions I have read have hinted that the built-in admin interface to Django is awesome, but it seems it is the only real benefit over Turbogears. The consensus was to actually learn both, and use Django when you needed a great admin interface, and Turbogears otherwise. My specific project is more on the otherwise end of things.

Another common theme is that Django is great for projects that don't have user-created content, but instead release a lot of content (I am guessing along the lines of the original Django newspaper app). If you don't have that type of project, people seem to advise using Turbogears.

But I guess the best way is to try both, so I will certainly look at the screencast you posted. Thanks!

Perhaps some of the 12 tests/tips are. But I think there is some good stuff in there for solo or small-team projects. I myself have never used a bug tracker, but I sure have spent a lot of time coming up with some sort of solution for that problem. These solutions get pretty hodge-podge after a while (wiki's, email, white boards, notes, etc.), and I am never satisfied. His argument for a good bug-tracker is compelling and it seems like it would benefit any project.

Well here is another feature request then - make the Feature Request, and edit links more noticeable. But thanks for the tip.

I have a couple of feature requests:

1.) I just posted a comment with a typo, but I could not correct it, so an edit feature, or at least a preview feature before you submit the comment would be helpful.

2.) A bigger box to write these comments! I find these one line comment discussions very confusing, and I wonder if they would be limited if there was a bigger comment box (I am already getting a scrollbar with a comment this long).

3.) Some way to see posts that have drifted off the top and new pages. Someone told me about a post that apparently just got knocked off one of these pages and I can't get it. This is a complicated feature request because I really do like only having to look through a couple of pages to see what is new (a real plus on the simplicity side). But not being able to find a good post that someone sent you is not good.

4.) A 'track-this-discussion' feature. I am sure you have something like this in the admin console for the site. If there is a really long discussion that is a few days old, and someone posts a reply to my comment, odds are I am not going to see this reply unless I am very vigilant on that page. I think some sort of tracking or alert system (of course optional) would be nice so that you will be alerted (emailed or possibly some sort of user message in the top right corner when you log in). Se mediawiki's 'Watch This Page' feature.

The reason why I posted this link is to promote a discussion of python-based web application stacks. We have been using Rails for about a year now, and really enjoyed it from the very start because it did so much for us. Well we have prototyped the idea and would like to start building it for real, and we kept getting caught by Rails when we tried to go against the grain.

So we started to look into other web application frameworks, and turned up a lot of comparison between two python-based frameworks, Django and Turbogears, with Rails. Although they were all very outdated, they all boiled down to using a python-based framework if you want more of the internals exposed (because you have include a lot more code to explicitly specify what you want to do), and use Rails if you don't want these details exposed. To be fair, you can always dive into the rails code itself to look at the internals, so it is more of a question of how you want your application code to look.

As I don't have too much Turbogears experience at this point, I would gladly welcome a re-analysis of the comparison from someone who does. And I hope that just by posting the link to the Turbogears tutorial video that someone realizes there are more webb application frameworks out there besides Rails.

It is interesting to point out that Reddit already tried this platform for comments on scientific papers. arxiv.org has long been acknowledged as a forerunner to scientific e-publishing and is in fact a one-stop-shop for many subfields of physics, computer science, and almost all of mathematics. We thought it would be the perfect place to try to do something like what you suggested: to use a Reddit-like interface to collect comments and discussions on scientific literature. So Reddit set it up at arxiv.reddit.org.

As you can see, there is not much happening. In fact, the main lesson learned here was not that a reddit-like platform is not ideal to this type of knowledge pooling, but that the scientific community is in general skeptical about this type of information sharing. We did not require email address validation for logins (hence the spam you can see up there), but we did talk about it with a lot of people and there were good arguments on both sides. I talked with physicists, biologists and mathematicians about using this type of site, and the replies were mostly those of insecurity about sharing incomplete ideas: both because they might be wrong (and not many scientists like that), and because if they were right, they would rather keep it to themselves and publish it.

Actually Paul Ginsparg, the creator of arxiv.org, kind of warned us before we launched that it would take mostly a huge grass-roots effort to get scientists going on something like this. He was right, and from listening to some of his stories about how he started arxiv.org, it apparently took him over 5 years of grass-roots convincing before it took off, despite being clearly a very good idea.

If you are interested in scientific knowledge sharing, with an eye towards collaboration, check out openwetware.org, which uses the mediawiki wiki platform. Note that they actually do require account authentication, so have a lot less spam issues at this point. It seems like a wiki platform is more easily adopted for scientists (although still hesitantly), as the subreddit oww.reddit.com, which we tried to push to the openwetware community, has not taken off (this time because of concerns that Reddit is a company.)