-
ONLamp.com: A Holiday Gantry Web Application
You may not know that Django isn’t the only open source web application framework developed at The Lawrence Journal-World. No, a completely different unit from ours built Gantry, a Perl-based framework that is start to make quite a name for itself within Perl circles. If you’re a Perl fan, check it out. It’s actually the culmination of over 10 years of web apps coming out of that division — it’s actually older than Django.
Who would have guessed two best-of-class open source web app frameworks would come out of a small newspaper company in Kansas?
Visit -
The B-List: Hypothetical framework choices
James has a nice post about choosing a web development framework, and especially about switching from J2EE to a dynamic language and framework like Ruby/Rails or Python/Django.
Visit -
Jacob highlights some recent cool Django apps
I was actually in the process of writing almost this exact same blog entry when Jacob’s post showed up in my feed reader. Frustrating! Not entirely unexpected, though, as he and I were just talking at lunch yesterday about how rich the pool of pluggable apps for DJango is becoming.
Jacob mentions django-openid, django-voting, django-tagging, and django-registration. I’d add django-discussion to the list. And don’t forget that Django already includes app for admin interfaces, comments, feeds, and more. It’s becoming a “just bring your own data model” situation.
Seriously, if you can write a model for some type of data (which takes a max of like 30 minutes for things likes blog posts, bookmarks, photos, recipes, reviews, whatever), and then pull in third party apps to let users register and sign in via OpenID, and then more third-party app to tag, vote on, and discuss your data — haven’t you pretty much covered what 90% of the web apps in the world do?
Visit -
Presentations: RailsConf 2007
A bunch of great presentation slides from this year’s conferences are available at the RailsConf website. Even though I’m not a Rails guy, per se, most of this stuff is equally applicable to development with other LAMP-ish agile development frameworks.
Visit -
Joyent Connector to be Open Sourced
Wow, definitely didn’t expect this. Connector is an amazing web app that I’d definitely love to be able to run a local version of and extend for myself. Awesome news. Huge boon to the Ruby and Rails communities.
Visit -
Interview with Twitter Developer Alex Payne
Alex has a lot to say about Twitter, Rails, and scaling. Not to Rails-bash, but it’s hard to ignore these quotes:
Running on Rails has forced us to deal with scaling issues — issues that any growing site eventually contends with — far sooner than I think we would on another framework.
And…
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.
And…
It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.
Props to Alex for being upfront and forward and not sticking to the Rails party line of “it’s fast enough.” Alex is obviously in a unique situation, as Twitter is the biggest Rails app on the web. Rails, which is a great framework in so many ways, will probably work great for your site, which is almost certainly not as intensive as Twitter.
But until the performance can scale to a huge site, people are always going to be a bit scared to use it for a startup they perceive as “the next big thing.”
Visit -
Python web development and frameworks in 2007
A very fair and complete look at the various Python web application frameworks available today. Gives Django a mostly positive review, and some good constructive criticism. I would respond to just this one part:
I would really like to see Django focus on modularization. The easier it is to use Django’s components with other frameworks (such as the URL dispatcher, the templating system, the ORM), the more people will end up using them, and more bugs will be spotted and more functionality added (like more tags and filters for the templating system). If this were the case, time spent duplicating functionality to be easily used outside of Django, such as Jinja could instead be used to work on what already exists. This is a win for everyone involved. In addition I’d like to see it made easier to use components from outside Django inside Django itself. For example TurboGears and Pylons both allow you to change a few lines of code to use a different templating system. Integrating that and functionality like this into Django would be very powerful and would alleviate the issues some people (myself included) have with specific Django components.
I wouldn’t dare speak for the Django lead developers, but as someone who sits next to a few of them every day, I’d suggest that this is not something that will be high on their priority list. Why? Simple — they don’t need it. The Django lead developers — and, in fact, most of the Django community — use the entire Django stack, top to bottom. That doesn’t bode well for interoperability with other components being high on the priority list.
Of course, that doesn’t mean it won’t happen. What it means is that people — like jp here — who “would like to see” this functionality improved should get to work on patches to implement it. It’s open source, after all.
That’s the beauty of open source. The fact that there hasn’t been much development effort in this area is a pure and true indicator that maybe it’s not as “needed” as some would like to believe. If it were really “needed,” someone would be working on it.
Bottom line: interoperability with other components is, in theory, a useful thing. In practice, almost no one really wants it, because they use the entire Django stack and simply don’t need it. If you really do need it, then go work on it. Use the source, Luke. :)
Visit -
Django .96 is available
New version of Django is out. Now includes all new forms library and testing framework. Also, note that many Dreamhost servers have older versions of mySQL, so you’ll need to change your database setting to “mysql_old” for Django .96, which now expects newer versions.
Visit -
PyCon 2007: Web frameworks panel
James Bennett is live-blogging the web frameworks panel from PyCon. So far, it’s quite good.
Visit -
The B-List: Python framework design
James Bennett has another great piece on frameworks, this time discussing the difference between the full-stack (i.e. Django) approach and the glue (i.e. TurboGears, Pylons) approach to design. The key take away point (with apologies to Malcom Gladwell) is that there is no perfect framework, only perfect frameworks.
Visit -
Performance test of 6 leading frameworks
In choosing a framework, a web developer does a exhaustive series of performance tests, comparing Django, Ruby on Rails, TurboGears, CodeIgniter, Symfony, and Catalyst — and publishes the results. As with all benchmarks I’ve seen, Django is the clear winner.
Visit -
Jon Udell: Django gymnastics
Another major figure in the industry gives Django a try and comes away very impressed. He also laments the lack of hosting service that currently provide easy Django support — which, no doubt, is an issue that needs some attention.
Visit -
Curse Gaming moves to Django
Curse is apparently a very popular gaming website (I’m not a gamer, so I didn’t know it) that pushes over 500k visits an hour — and they’ve just moved their entire site to Django. Congrats, guys!
Visit -
Bright-Green.com: Rails vs Django Paper and Slides
Probably the best comparison of these two popular web app frameworks I’ve seen. These guys wrote the same app twice — once in each Django and Rails — and analyzed the results. They provide no clear winner — but do outline several “choosing points” that will help you pick between them. For example: Already know Ruby? Choose Rails. Need super-simple AJAX? Choose Rails. Does your team include non-programming web designers? Choose Django. Need automatic admin pages for editing your content? Choose Django. Both the slides are paper are terrific. Check ‘em out.
Visit -
Mondrian: Code Review On The Web
Python creator Guido Van Rossum shows off Mondrian, the web-based code review application he built for Google. It uses Django (especially the template language) throughout. Every day, every single engineer at Google is using Django. Now that’s pretty cool.
Visit -
Constructive reasons to use Django instead of Rails
“I quickly found that if I couldn’t express something with the template system, I was doing something wrong, and it led me to think a little more about the structure of my app.” This can be repeated enough. Almost every time I’ve ever said to myself, “Man, I wish I could do x in the Django template language,” my next thought was, “Except that would be stupid, because that should really be done at the view level.” Much of Django is designed the way it is in order to encourage best practices. It’s actually hard to be sloppy with Django.
Visit -
Why Django kicks Ruby on Rails’ collective ass.
A lot of good points in here — wish he wouldn’t have been so flame-bait about it, though.
Visit -
Django AMF
“Django AMF is a Middleware for Django web framework written in Python. It enables Flash/Flex applications to invoke Django’s view functions using AMF(Action Message Format).” Sweet.
Visit -
Kyle On Everything » Automagic Sitemaps with Django
“It turns out that, despite receiving less fanfare than Rails, Django has all that and then some (It’s not even 1.0, but feels like Rails 2.0).”
Visit -
Django tips: get the most out of generic views
James Bennett continues his series of Django tips with a great piece on getting the most out of generic views. Generic views, while useful to real programmers like James, are absolutely essential to designers like me who want to do cool things while writing as little “real” code as possible. James shows how to “wrap ” generic views in a few lines of simple Python to extend their functionality.
Visit -
Gantry: perl web application framework
Gantry is a web app framework developed in perl by another division within The World Company (the parent company of World Online, which developed Django). So now our small Midwest media company has two major open source web app frameworks. :) I’ve not used Gantry, but I can definitely say that the folks behind it are damn smart and really “get” open source — so if perl is your thing, give it a look.
Visit -
Catalyst vs Rails vs Django cook-off
Django soundly trounces the competition in these performance benchmarks.
Visit -
The Django Book: now online
Jacob and Adrian have put up the first couple of chapters of The Django Book, their upcoming reference on the web framework. Apress will be publishing the book in print, but it’s free online. While you’re there, check out the commenting system — totally badass.
Visit -
A comparison between Django and Turbogears
Nicely written showcase of the commonalities and differences between the two popular “Railalike” (his word, not mine!) web frameworks written in Python. In the end, he prefers Django — but a cursory read through his finding indicate there are more similarities than there are differences, which seems to be the common conclusion I get from most of these comparisons. Whether you’re doing Rails, Django, TurboGears, CakePHP, or some other MVC-style framework, the important thing is that they all seem to encourage best practices, let you get shit done faster, and generally make your life a better place to be. Get on the damn bandwagon, yo! :)
Visit -
Switching from Rails to Django
Nathan Borror on his recent switch from Ruby and Rails to Python and Django. Nathan is a designer first and programmer second, and he cites the automatic admin interfaces and more reliable performance as features of Django that allow him to focus on design rather than on making things work.
Visit -
Why so many Python web frameworks?
Because it’s pretty damn easy to create one, that’s why.
Visit -
Joel on Software: Language Wars
Even as someone who only dabbles in programming and has never used Ruby, I’ve always had reservations about it simply because I perceive it as a small player and I can’t point to any large-scale, mission-critical, high-traffic web apps built with it. That’s not to say you can’t build this type of app with Ruby — I’m just not aware of it being done. Joel seems to have similar reservations: “For Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I’m really not sure that you won’t hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot. I for one am scared of Ruby because (1) it displays a stunning antipathy towards Unicode and (2) it’s known to be slow, so if you become The Next MySpace, you’ll be buying 5 times as many boxes as the .NET guy down the hall.” Joel considers C#, Java, and PHP to be “safe” choices for web applications, and says that Python is “on the border, about to cross the line from an ‘interesting’ choice to a ‘safe’ choice.”
Visit -
Top 20 Ruby on Rails Content Management Systems
People sometimes ask me if there are any good freely available Django CMS or blogging apps. There aren’t, really, and I think the big reason is that Django’s built-in admin interface, generic views, and template language make it almost as easy to roll your own as to download, install, and customize a pre-exisiting app.
Visit -
Django and ORM: The best of all worlds
James Bennett notes that a new branch has been created for Django development — one that add SQLAlchemy as an ORM option for Django (i.e. the existing Django ORM will still be included, and still default). This is great news, as many Python programmers already know and love SQLAlchemy.
Visit -
Frameworks are passing
A blogger wonders if your favorite pet framework will be gone by the time you get around to your next project. Adrian points out that having several large media companies depending on Django (many via Ellington) means there are people whose jobs involve maintaining Django. This should help give it more stability than many open source software projects.
Visit -
Zen and the art of Ruby programming: Django is great
“Python has a few nice web frameworks, but I’ve fallen in love for Django.” and “The template system allows designers to define the UI without having to know how to program in Python.” Yup.
Visit -
Of snakes and rubies; Or why I chose Python over Ruby
Nice blog post from a former Rails developer who has switched to Python. He outlines various reasons, but the two biggest are performance (Ruby is slow) and library support (Python has a lot more).
Visit -
Riding Rails: Taking admins beyond scaffolding
One commenter at the Rails blog has the best solution yet for an auto-admin interface for Rails: just use Django’s. Just as you can easily use Django’s admin interface for your php app, so can you use it for your Rails app. Or Java app. Or CakePHP app. Or whatever.
Visit -
It’s official: Django is *the* web framework
Straight form the mouth of the Benevolent Dictator For Life at SciPy ‘06, “Django is the web framework (for Python)”. I’ve not tried any of the others, so I won’t argue with him. But it’s comforting to know a tool I use has been “blessed” by the creator of it’s language. Here’s to a long and prosperous life for Django.
Visit -
Streamlined: Django admin for Rails (but not really)
The Streamlined project, an attempt at creating an “automatic” admin interface for Rails recently released a screencast which I just checked out. I know it’s going to sound like sour grapes since I’m a Django user, but I am simply not impressed at all. To start with, the majority of Streamlined is not dynamic — it’s a code generator. Anyone’s who’s been there and done that can attest to the fact that code generation is just asking for trouble. Having to re-generate my admin site after any changes I make to my models? No thanks. Not getting updates to the Streamlined application in fear of overwriting my customizations to the generated code with the new generated code? No thanks. On top of that, the user interface is simultaneously an obvious rip-off of the Django admin interface and terrifyingly ugly (I know it’s an early beta, so perhaps I should cut them some slack). I’ll never understand how you can rip something beautiful and return something ugly — but Microsoft does it all the time, so I guess it’s possible. Bottom line: there’s no way I’d be comfortable telling my clients they can manage their site with an admin tool that looks and works like Streamlined does. I respect the attempt and I think Rails does need something like this if it wants to match Django’s feature set — but Streamlined has a very, very long way to go to be the Django admin for Rails.
Visit -
CakePHP, Django and Ruby on Rails
A blogger cites less SQL, the admin interface, less files to manage, and performance as reasons why he preferred Django over RoR and Cake.
Visit -
The B-List: Let’s talk about frameworks, security edition
James Bennett brings back the “Let’s talk about frameworks” series in light of the recent Rails venerability, which kicked off quite a discussion about the security of web application frameworks and the applications built with them.
Visit -
Gutata Blog: Django and Ruby On Rails
What the difference between Rails and Django, perception-wise? More importantly, what’s causing the difference? Gutata has some thoughts.
Visit -
Rapid prototyping tools should NOT generate code
There’s no question that code generation is a bad idea in many ways, and it’s nice to see people talking about it. My understanding is that Django (before it was called Django) went through a phase than included code generation. Glad it’s since moved on. :)
Visit -
Next-Gen App Frameworks
A Rails user take a cursory look at Django and Symfony and compares them to Rails. He says a lot of really nice things about both (even if a few points about Django are inaccurate…comments have corrected him). Still, he concludes that the two are “playing cathup” to Rails.
Visit
