Programming is passion made real
Working on Banjo Blog, nearly the only thing remaining before my initial release is a trackback/pingback system.
Oddly enough, there isn’t any django trackback app in the wild, at least not any I could find. So, I looked around and found only half-written stuff, hacky garbage and tblib, which is too old, not Django aware, and GPL. Banjo is BSD and it is going to stay that way, thank you.
So, I wrote my own.
I’m nearing release 0.1 for Banjo, a blog app written in Python on the Django framework. If you look at the mailing list, you’ll see plenty of people asking about a blog app, and the standard reply is that it is just so easy, almost trivial, to write your own that there is not much call for such a package.
I really don’t agree with that logic although I do understand it. Blogs look simple, and stripped of everything else, they really are simple. Basically they are just reverse chronological posting of text on a page. No biggie, at least at first or second glance.
But the trick is in the phrase “stripped of everything else.” Once you start considering the features commonly available in blog apps, it gets quite a bit more complex:
At the request of people on the satchmo-users mailing list, here’s my step-by-step guide to installing Satchmo on a Debian server.
Debian is a wonderful base for Satchmo, much easier to set up and maintain than RedHat in my opinion. The magic is in the “apt” packaging system, it simply eliminates most of the ugly tracking-down of the right versions of software and their dependencies.
This is a step-by-step, not a full discussion. To read more about “why”, please see the excellent article Creating my Dream Server for Django, which I heavily borrowed from.
Look at that hit rate! That isn’t unusual, a 75% hit rate for cached elements in a well designed system. That cache page is copied from an e-commerce site undergoing testing for a couple hours, by the way. Most of the caching is from presentation stuff, such as menuing and page widgets.
I think that the incredible hit rate goes to prove that for most any real application, you should be thinking about caching sooner rather than later. Build it in. It is not “premature optimization” to design it up front.
For my Django apps, I use a cache manager application I wrote in a brainstorm fugue state a couple months ago. I really needed it for my still-in-testing InvisibleCastle gaming site rewrite, since I do so many lookups and repetitive viewing of the same information.
Once I’d written and debugged it — which took longer than I’d have liked, of course — I started using it as a matter of course in all my client projects. Then last week I had another brainstorm and actually wrote a quick set of management pages for it. Now I can observe the cache in operation, clear it, or even a subsection of it. It has been invaluable, and I can see the vast increases in speed it affords my apps by simply comparing the performance with and without the cache running. I haven’t run formal trials, but it feels at least twice as fast, probably more.
[tags]django,caching[/tags]
I searched all over the place last night and I couldn’t find anything that could import passwords into Yojimbo for me. I did see a lot of complaining about the lack of ability to do so, however.
Since I really like the app in most ways except for its lame import capabilities, I whipped one up to import my 250+ password entries from a different program.
Get the program: Yojimbo Importer 1
Read on for discussion of how to use it, or else just look at the instructions provided in the download.
The latest Django revisions have removed the shortcut handlers "auto_now" and "auto_now_add". This didn’t look like a very big deal to replace. I simply did what was suggested in a django-users thread.
The problem was that after I did that, my live code seemed to work fine, but my test cases had several repeatable errors that I just couldn’t reproduce on the live server or at the command line.
Whew. I spent quite a bit more time debugging this problem than it really should have taken. Django just wasn’t playing nice with the latest Lighttpd pre-release.
Don’t use the prerelease, use the most recent 1.4.x stable. Save yourself hours of cursing and trace-debugging.
Lighttpd had the following problems:
[tags]lighhtpd,django,python[/tags]
I keep needing to do this, darn it! I leave a project for a few months, possibly push it live, and then I go back to fire up the dev server but I simply cannot remember the password I used for admin during development.
Why don’t I use my stupid-development-password? I don’t know, but this seems to happen with some regularity.
Luckily, it is trivial to fix with a few lines at the python commandline:
Deep:/opt/webapps/invisible bruce$ ./manage.py shell
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: from django.contrib.auth.models import User
In [2]: users = User.objects.all()
In [3]: users
Out[3]: [<User: admin>]
In [4]: users[0].set_password('whatever');
In [5]: users[0].save()
That’s it, fire up the dev server again and your new password will get you in.
[tags]django,python,commandline,auth,login,password[/tags]
Note: This article is out of date. Since I wrote it, I’ve become a core developer on the Satchmo project, and Satchmo is usable by default as an App (or rather a collection of apps) rather than as the whole project.
I’m going to be using Satchmo to power the backend of a highly customized store that I’m building for a new client. This is an early-stage, yet strong Python ecommerce framework, which gets much of its power by being built on Django.
Of course, anyone reading my site can clearly see that I am strong in favor of that choice.
I ran into one little issue when I was first setting it up according to the directions. I was told to modify files in the Satchmo directory itself. No! I won’t do it! Not on an actively developed application like that. How would I keep my modified branch in sync with the development branch?
In general, you never want to modify something that is a moving target. Even if it is a hassle, you should set things up so that the thing-which-will-be-getting-updated is isolated from your own code. Otherwise you’ll certainly have to face that most annoying of development tasks, merging someone else’s code.
Well, luckily it wasn’t so hard to set up Satchmo for use as an App, rather than as the base site.
[Read more...]
I really like Django’s newest module for forms, “newforms”. Despite its currently lacking documentation, it is well worth learning.
It feels much more “Pythonic” than the old manipulator-based method. Less magic is going on, and less constant reference to the manual is needed. However, I found myself beating my head against one undocumented, and also lacking any test case feature.
I’ll spare you the trials, tribulations and shrewd guessing, here’s the answer. Put the value in the widget attributes, not the form field.
Recent Comments