Posted by Jeremy Voorhis Sun, 28 Aug 2005 20:24:19 GMT
Railsume is a simple resume building tool written with Ruby on Rails.
This project began on Friday evening 26 Aug 05, and it emailed its first resume this morning. We’ll see where further development leads us…
Railsume is pronounced “rails-sue-me”.
Posted by Jeremy Voorhis Thu, 25 Aug 2005 18:04:19 GMT
*eriberri* wanna hear something funny? *eriberri* i had bad, stuck-record dreams last night... about... ERC> /msg eriberri uh oh *eriberri* carnivorous flamingos *eriberri* :) ERC> /msg eriberri ahahahaha ERC> /msg eriberri that definitely tops my pygmy giraffe dream
Posted by Jeremy Voorhis Wed, 24 Aug 2005 04:53:57 GMT
Although I found you can specify an alternate config to settings/main.py, the novelty of this quickly wore off when I remembered that sometimes I have to update that file. Simply copying it duplicates data which quickly gets out of sync. I’ll likely try to find a programmatic solution to this. Please do comment if you have any thoughts on it.
Posted by Jeremy Voorhis Wed, 24 Aug 2005 00:18:50 GMT
I am experimenting with creating a test environment in Django. So far, it is easy
Next step is learning how to pound my apps with unittest.
Posted by Jeremy Voorhis Thu, 18 Aug 2005 18:28:00 GMT
After completing the Django tutorial and tooling around with it, I got a better idea what it’s all about. Django’s big win is by far is its powerful dynamic admin. Look what I got for free!.
Ok. Not quite free – I had to add a little bit of code to my models, but this added up to about 4 or 5 lines. I quite envy Django’s many-to-many selector widget, and I’ve begun making one with Rails, but using drag’n’drop instead of the buttons. Nice thing about the buttons, though, is that you can highlight multiple items on the left (without holding ctrl) and select them all with one click. Nice. And that template in the screenshot is just waiting for me to override it with Django’s template language.
Another powerful thing in Django is the way it exploits the __repr__ method. Look at the screenshot again. It is not the best example, but you might get an idea of how adept Django can be in organizing data – if there were indeed multiple artists, the selector would group albums by artist, and then display the albums in chronological order. As you might guess, I could easily change that behaviour in one line. The __repr__ method of the Album model is what makes an album display itself as “Artist name: Album title” rather than just the album title.
Another nicety of Django is that certain field types have certain implicit behaviours. A meta.FileField will automatically render itself as a file upload field in the dynamic admin. But that’s not all – it also encapsulates the functionality to upload a file to the directory specified by the application’s MEDIA_PREFIX setting. The downside? I could not delete the file once it was uploaded. Optimistically, I filed a ticket requesting this functionality.
One of Django’s most controversial features is SQL generation. Initially, I found it worked quite well and there was no chance of my models being out of sync with the database. The pluggable applications manage their own tables, so when you drop an application into your Django project, you can run django-admin.py install <app> and you’re good to go. The big downfall? Change becomes cumbersome. Upon changing a model whose data is not expendable, you must alter the table manually. Otherwise, you may run django-admin.py sqlreset <app> and pipe the output into your database like so: django-admin.py sqlreset monkey | mysql -u root --database=monkey. Rick Bradley has posted a well-written article to the Rails mailing list that treats this subject in more depth. It is also available at his blog
Django also has what I would deem to be a major shortcoming in its template system – urls have to reference the prefix at which the application is installed. For example, in the tutorial the base url for the polls application is /polls. Templates within the polls application are required to be aware that they lived at /polls. This means if I wanted to install the application at another location, I would have to find and replace every instance of /polls in my templates. Rails solves this problem with its routing system, but routes can be difficult to use beyond a certain threshold of complexity. Django’s facilities for regular expression-based url design allow you to create urls of any complexity, but I have not yet seen a solution to decouple the templates from their urls.
As I expected, I have to clarify a few things from the last article. First of all, Django’s does have a capable equivalent of helpers – custom tags and filters. You can define custom tag libraries and include them in your project to accomplish similar sorts of tasks one would use helpers for in Rails. Another retraction: as Adrian commented in my first Django post, Django is hardly like Rails at all. In terms of its goals, it is more like OpenACS.
My experience Django was positive. I finally got around to learning Python, and I got to weigh for myself the benefits and pitfalls of Rails’ and Django’s techniques to implementing software patterns, such as object-relational mapping and URL routing. I can see how Django would be a good fit with the “newsroom environment” it was created for, and I left with the impression that Django is much more of a specialist than Rails. It does not strive to be an all things to all people framework, but rather an excellent starting point for implementing common website functionality.
Finally, another big win for Django is its active community. The guys in #django are very friendly and the lead developer is accessible, open-minded and willing to discuss things. Thanks, Jacob!
Posted by Jeremy Voorhis Mon, 15 Aug 2005 22:49:00 GMT
Apparently CalendarHelper was used in a ThoughtWorks project. Neat.
I’ve refactored it a little bit and I plan to do a proper release of it with gemmification and all. In the meanwhile, I’m glad it helped someone.
Posted by Jeremy Voorhis Mon, 15 Aug 2005 17:58:00 GMT
Disclaimer:
I have been developing with Rails for a few months now. I like it. I’m familiar with it – I even like to think I know my way around the class library quite well. That’s expertise, something I don’t have when evaluating a new framework. I am also getting to know Ruby very well, from structuring applications intelligently to metaprogramming. Conversely, I’m a total Python newb. I also interact with the Rails developer community on a regular basis, while having no experience with Django’s community in any way. In short, there’s no need to accuse me of being biased – I know I am :)
I also did not complete the Django tutorial last night. I got through part three and decided to leave the rest for tonight, but I’m reporting what I’ve found thus far.
Django is an interesting creature. It simultaneously provides a lot more and a lot less than Rails for different tasks. It also has some key differences in its philosophy that yield some interesting results. I will try my best to compare and contrast the two frameworks.
login_generator (with salt), an ACL, and acts_as_versioned out of the box.The first few minutes spent in the Django tutorial were really rewarding. Specifically, the dynamic admin thing is cool. It demonstrates some attention to detail and from what I’ve seen so far, it’s the sort of thing I would feel comfortable giving to a client.
As soon as I left admin-land, however, I began to miss Rails. Views (Django-speak for actions in Rails) aren’t automagically associated with templates (Django-speak for views in Rails). Instead, you write the code to glue them together for each view, passing the output to an HttpResponse object. The template system also lacks one feature I couldn’t imagine using Rails without – helper methods. Instead, you get “filters” which you pipe your data into with, well, the pipe character. Filters seem useful for formatting data, but they don’t appear to be intended for complicated tasks. On the whole, Django’s templates remind me of Smarty more than ERb.
The directory structure for a Django application is smushed – in the tutorial, models are all written in one file. I could see this becoming a nuisance if I accumulated a lot of model code. Another thing I have seen no mention of thus far is unit testing. I would be surprised if there was no unit testing framework available in Python, though, so I’m assuming it shouldn’t be an issue if you want to test your models yourself. Unfortunately, Django has no concept of distinct environments, so it may take some additional hacking to get the isolation of the test environment that I enjoy in Rails.
One thing I am liking about the framework is the pluggable applications concept. A Django project has many applications, and there are project-wide configuration files – one for routing and another that is like environment.rb. These files are Python and are governed by a similar philosophy to Rails’ Ruby configuration files. Within these files, you can provide some global settings such as a database connection, and delegate other settings to the individual apps. For example, you can chomp the first part of a url and pass the remainder of it to the appropriate app, which then manages its own routes. This should make applications very portable between projects.
Tonight I plan to finish the tutorial, and then kick Django around some – specifically, I’d like to see how the dynamic admin and the sql generation can cope with more complicated domain models.
Posted by Jeremy Voorhis Mon, 15 Aug 2005 04:10:00 GMT
Django is the web framework for perfectionists with deadlines. They have a site that shamelessly plunders the 37 Signals aesthetic, and unoriginally makes some of the same claims as Rails, but verbatim! It’s also written in Python.
So why do I care? Well, for starters it seems to have a different intent than Rails – rather than provide you with a framework for doing things, it provides a framework that does things. Huh? Upon running django-admin.py init, it created 15 database tables. Instead of scaffolding, it provides a “production ready dynamic admin”. It’s heavily influenced by Rails, but it functions at an even higher level.
I just started the tutorial and I will blog my impressions about it later, probably tonight.
Some concerns: