May 19, 2013

Posts Comments

You are here: Home / Archives for January 2006

Another win for Django

January 31, 2006 By Bruce Kroeze 2 Comments

thumbs up Another win for DjangoOne nice thing about Django is that unlike many frameworks, you do not have to “grok” the whole thing to be productive. In my case, I hadn’t read a lot of the documentation other than the tutorial and the details of a few of the features I need for my first app.

Surprise!

Imagine my happy surprise when I found the very nicely implemented “documentation” link in the automatically generated admin site. I’d assumed it was a link to the static documentation or some such thing, like it is in most systems. Nope. It is much more.

It has details and documentation on everything I’ve done on the site. I habitually put in docstrings, so they are formatted for me and presented on the detail pages for my model objects. Wow. This is automatic, and a big incentive to keep doing that documentation! Every view is similarly detailed. In fact, there are auto-generated pages for Tags, Filters, Models, and Views. In each case, the documentation only shows things valid for the application. If you’ve added custom tags, they are there, along with all the built-in ones.

I hate to rave, but this level of detail and usefulness is unprecedented in my professional experience. Especially in a free and open programming framework.

[tags]Django,documentation,raves,python[/tags]

Filed Under: Django, Python

Top ten reasons to use Django for your web framework

January 27, 2006 By Bruce Kroeze 5 Comments

guitar Top ten reasons to use Django for your web frameworkDjango is pulling ahead of every other web framework I’ve tried. For reference, that includes such recent heavy-hitters as: Jakarta Struts/Tiles, Spring, PHP Smarty, Zope, and Plone.

I’d been thinking about why that was so, why I’ve become so fond of Django so quickly, when I ran across a post at Jacobian.org, titled Why you should use Django. I’ll take his top ten points and add my own observations:

1. Django works — right now

It really does. The example tutorial works correctly the first time. That is something hard to find in the online world. Better, there is no outstanding wart which is holding up adoption, and which will be fixed “real soon now”.

2. Deployment is a breeze

I know that I will be able to deploy on DreamHost, which is the most important part to me as a user at this time. As a developer, it was amazingly simple to set up and run my development system. This took literally hours less time than setting up an equivalent Java system.

3. Your site won’t go down

That’s one of Django’s big claims, and is part of the reason I was initially attracted to the framework. It speaks of quality to me.

4. Django is fast

It is faster by far than Kid, and Cheetah. If it beats those, then it literally blows Zope out of the water. PHP should eat its dust as well. But that is all beside the point to me at this point. I care about “fast to develop for”, and that is where it truly shines for me.

5. Django scales

Not qualified to judge.

6. Django’s admin will blow your mind

I hate writing admin interfaces. Django removes almost all the pain for me. In fact, they are almost free, which is a wonderful and deeply appreciated thing. How many times have I released a half-ass admin interface “for trained users only” to justify the fact that using it might cripple the site if the wrong button were clicked? More times than I like to think. Django won’t prevent all of that, but it gives me back so much time that I can then use to put in better logic-checking and validation.

7. You don’t need to go whole-hog

I am preparing to port Invisible Castle to Django, and I’ll report back about my progress. I expect it to be fairly easy, actually.

8. Django plays well with designers

I’m not qualified to judge, I think he’s probably right

9. Django comes from the Real World

I love the fact that they don’t add functionality just because it looks fun. The best projects/software in the world were built to solve real problems, and more importantly had real users right from the get-go. Django was built exactly that way, with immediate feedback and guidance from their sponsor, and it has clearly benefited from that.

10. We’re here to help

My post about logging in frameworks which referenced Django was picked-up and responded to within a day. That’s amazing. What’s more, the result is that they may very well adopt what I am suggesting. It wasn’t a flame-fest, despite my initial harsh tone. The professionalism and openness both surprised and pleased me.

[tags]python,django,webframeworks,web frameworks[/tags]

Filed Under: Django, Python

WordPress title suffix plugin

January 24, 2006 By Bruce Kroeze 29 Comments

adapter Wordpress title suffix pluginI read some research recently which seems to show that keywords matter to search engines in your site’s “title” tag. Not only that, but position matters. Preferably your page title should precede your site title.

Unfortunately WordPress is coded to make that sort of ugly. If you simply reverse the wp_title and wp_bloginfo(‘name’) calls, you get ugliness in two ways. If what you want is “keyword – sitename”, then you have to live with the default title for your site looking like “- sitename”. Ugly. Then if you are on a titled page, you get “» keyword – sitename”. I don’t know about you, but I think that’s ugly too.

So, enjoy my tiny little WordPress plugin. It will strip out the leading “»” and will not put the dash in unless there is something preceding it. I’m no PHP god, but that was both easy and fun, due to the “hook” system WordPress implements so nicely. You’ll still have to reorder your themes to have “wp_title” listed before the sitename, but at least it will look prettier now.

Download: wp-title-suffix.zip

[tags]wordpress2,wordpress,plugins,seo[/tags]

Related posts

Filed Under: Downloads, Plugins, Wordpress

How to install Cheetah on Dreamhost

January 23, 2006 By Bruce Kroeze 3 Comments

cheetah How to install Cheetah on DreamhostInstalling Cheetah on Dreamhost’s shared servers is actually a snap, if you have access to a Linux development system. All you have to realize is that the servers are Intel-based Linux systems, Python setup utilities know how to build “dumb” distribution, and that python doesn’t care if you use symlinks to trick it.

Building Cheetah

  1. Skip this step, if you like, by downloading my precompiled Dreamhost-friendly version.
    Download: Cheetah-1.0.linux-i686.tar.gz
    (MD5 Signature: 5e64240ae6dd7eb0ffe92fdde61fe5ea)
  2. To build, go to a Linux computer, preferably Debian, with Python 2.3 installed.
  3. Download Cheetah. I’ve tested this with 1.0. I don’t know about 2.0, probably the same steps would work.
  4. Unpack Cheetah in a temp dir.
    tar xzf Cheetah-1.0.tar.gz
  5. Compile a “dumb distribution”
    cd Cheetah-1.0
    python setup.py bdist_dumb --relative
  6. Copy the compiled distribution to Dreamhost. You’ll find it at “dist/Cheetah-1.0.linux-i686.tar.gz”

Installing Cheetah

  1. Unpack the compiled Cheetah package in some directory. I’ll assume you are going to unpack it in your home directory.
    tar xzf Cheetah-1.0.linux-i686.tar.gz
  2. It will unpack into two directories.
    • lib/python2.3/site-packages/Cheetah — the compiled site packages
    • bin — Cheetah compiler binary
  3. Now, you need to edit your ~/.bash_profile and add a couple lines:
    PATH=$PATH:$HOME/bin
    PYTHONPATH=$PYTHONPATH:$HOME/lib/python2.3/site-packages
    export PATH PYTHONPATH
  4. Now, add the environment variables to your current session.
    source /.bash_profile
  5. At this point, Cheetah should work! Congratulations!
  6. If it compiles all right, but doesn’t work via the web, then you need to make sure your Cheetah dir is available from your web-context pythonpath. The easiest, hackiest, fastest way to do this is to simply make a symlink to Cheetah. This fools Python into seeing the “Cheetah” module in the same place it sees your project files. My domain has its Python cgi files right in the root, so I just did it like this:
    cd ~/mydomain.com
    ln -s ~/lib/python2.3/site-packages/Cheetah .

Please let me know how this works for you, I’ll attempt to help you out if you run into problems.

[tags]python,dreamhost,cheetah,cheetahtemplates,howto[/tags]

Filed Under: Libraries, Python

Prototype modification to fvlogger

January 20, 2006 By Bruce Kroeze 2 Comments

logger Prototype modification to fvloggerfvlogger.js is a fine logging system for Javascript, but when you are already using Prototype.js, it unnecessarily duplicates a lot of functionality. I’ve forked the original code to “fvlogger 1.0.proto”, removing this duplication. In addition, I’ve added a sweet “add the logger to the page” function to the script. The end result is much smaller and cleaner looking than the original, I think.

This script is based on fvlogger 1.0, available from Five Volt Logic. It requires prototype, and if you want to use its auto-insertion features, it requires Behaviour.js as well. If you aren’t already using the Behaviour library, you should. It will revolutionize your use of Javascript, fully separating user interaction from markup. Most times I use it, I never have to use a single line of inline javascript at all. That is incredibly liberating!

If you want to use Prototype 1.3.x, you will also need to load a few functions borrowed from “the future”, which I’ve helpfully included as “prototype_future.js”. Just look at the test page in the zip, and all should be clear.

Download protologger-1.0.zip and let me know what you think.

[tags]javascript,libraries,prototype,logging,fvlogger,behaviour[/tags]

Filed Under: CSS, Downloads, Javascript, Libraries, Open Source

Logging is good for frameworks too

January 19, 2006 By Bruce Kroeze

log Logging is good for frameworks tooOne thing I just don’t understand is why more people, especially framework designers, omit or skip logging. Django appears to, which is incredibly annoying to me. It is a complex framework, which makes all kinds of assumptions and relies on convention to infer a lot of functionality. That’s great, but being able to “turn up” the log-level and see some discussion about what decisions it is making, based on what criteria it is using would be incredibly valuable to me. Not only to me, I wager, but to everyone who is learning the framework, or who is teasing out a difficult bug. Yet going in and adding framework-level logging is almost impossible, even on an open-source project, since your changes will not be accepted and will quickly become a merge nightmare.

Don’t believe me about changes “not being accepted”? Here’s proof. (That’s not my bug, by the way, just proof). The developers closed the ticket saying they “fail to see what this gains Django”. Foolish and shortsighted.

Logging is preferred by most senior programmers over line-by-line code stepping. It is both more efficient, and allows for post-mortem analysis of problems in a way that debuggers never will. Yet many act as if it is a nice-to-have, or worse an irrelevant distraction.

Shortsightedness is deadly

I once worked on a team with a programmer who refused to add any logging to a super-awesome-framework he’d written for Java. Evidently the framework was the solution to everything we needed. I challenged him in a team-meeting about his refusal, talking about the numerous benefits of good logging throughout a system. He replied “I don’t write bugs, so I don’t need to waste time logging to find them”. I had him fired, and good riddance, within a week. Attitudes like that have no place on a software team. It was his foolish assertion that he didn’t write bugs that was the final nail, but his refusal to see the benefits of logging certainly didn’t help his case any.

Logging is built-in to Python, and is a commonly available module for Java. It is high time to make this practice part of generally accepted programming standards for frameworks. Don’t want a log? Turn it off. But you should always be able to get one. Always.
[tags]logging,java,python,django,rants[/tags]

Filed Under: Best Practices, Django, Python, Rants

On Closures

January 11, 2006 By Bruce Kroeze Leave a Comment

Recently, I’ve been something of a language evangelist at work. I’ve been promoting the power and utility of Python and Javascript to both coworkers and management. One thing I’ve found difficult to get across to them is the concept of "Closures", and why the lack of Closures in many mainstream languages (such as Java) is an irritating, slowing, nuisance.

I use them all the time, yet it is not so simple to explain why they are, to phrase it the way my son would, "So Sweet". I would go so far as to say that if you aren’t using closures all over the place in Javascript you probably dislike Javascript and think it is a toy suitable only for web designers. Seriously, closures are what turned me into a Javascript fan, that and the incredible Prototype library. In Python, closures are natural, yet frightening for so many who come from a Java or C++ background.

This article won’t teach you everything about Closures, and it is written using Ruby as an example, but it may show you why you would want to try them. Thanks, Tom Moertel, and Reddit.

link: Closures and the Professional Programmer

Filed Under: Javascript, Python

Reconsider that XML Language

January 11, 2006 By Bruce Kroeze Leave a Comment

I’ve long agreed with the point made over at ongoing about the XML Languages. Most are poorly considered ideas, entered into without understanding the enormous scope of the task. Most duplicate functionality rather than extending or utilizing something already existing and understood by millions of people and programs.

It is the famous Not Invented Here problem, I think. A programmer sees that some schema doesn’t appear to manage something that they consider absolutely important. So, rather than do any real research, they leap in and try to “do it better”. In most cases, they just won’t succeed.

Quoting the article:

The Big Five · Suppose you’ve got an application where a markup language would be handy, and you’re wisely resisting the temptation to build your own. What are you going to do, then?

The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom.

Wise advice.

link: No New XML Languages
[tags]xml[/tags]

Filed Under: Tips, XML

Website Usability Guidelines

January 10, 2006 By Bruce Kroeze Leave a Comment

Smart Money Daily points out a great resource for website usability guidelines. Created by the US national cancer institute, it gives more than simple “give img tags ‘alt’ attributes’. Instead, it goes into why you should do so, and even more importantly, what evidence there is that this is an important guideline for you to follow.
[tags]usability, accessibility, section 508[/tags]

Filed Under: Design

Helpful Django utilities and links

January 9, 2006 By Bruce Kroeze 1 Comment

Two simple links which have been very helpful in doing my inital Django project.

1) The Dreamhost installation guide on the DH wiki.
2) The Django project template utility, which sets up new projects and all the assorted config files to a much greater degree than the built-in django-admin.py utility. I’ve added a couple more templated items, such as an ipython script which starts ipython with Django properly in the search path and loads the app model for you.

[tags]Django, python[/tags]

Filed Under: Django, Python
« Older Posts