May 21, 2012

Oohgabooga launched

oohga logo Oohgabooga launchedMy premiere e-commerce client, Oohgabooga Island Traders launched yesterday. After doing a little dance of happiness, I sat down to think through all that went into it.

I used the Satchmo e-commerce framework for Django to build it. Of course I did, because I am a core developer on Satchmo, and a peripheral contributor to Django. They’re my absolute favorite frameworks for actually getting web apps done without going crazy.

To get Oohgabooga done, I had to add tons to Satchmo. I added an entire settings management system, a modular payment system, newsletter management, and a custom-order workflow/product-type. The great thing about doing all that was that the framework let me. It didn’t force me to do it “their way” or no way at all like some systems (CubeCart). And it didn’t make me hate having to work with ugly ugly hacks (ZenCart). Best of all, it isn’t PHP.

At the moment I’ve got three more Satchmo clients. It is rapidly becoming the core of my consultancy, which is no surprise for me. The world needed a strong framework for people who need a beautiful, fast, customizable, extensible cart.

[tags]satchmo,django,e-commerce[/tags]

Setting up Satchmo on a Debian Server

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.

[Read more...]

Why you should use Caching in your webapp.

cache manager Why you should use Caching in your webapp.

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.

The background of that screenshot

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]

Django and Lighttpd init script and config for SSL.

I’ve gotten a lot of interest from my article about my SSL configuration for Django/Lighttpd. To make things even simpler for you, I’m posting a zip file with my raw config files and init script.

The init script is intended for use on a Redhat-style system, since that is what most VPS solutions are going to give you. It actually works, and I’ve never seen any other examples of working Django init scripts. Drop it in, edit the config files, run “chkconfig –add yourapp” and you should have a django setup which autostarts, and a Lighty config which is ready to serve it.

Enjoy, and please let me know if you see a way to improve the scripts.

tribe.zip version 1

Django and Lighttpd configuration for smooth SSL

I use and prefer Lighttpd for serving my Django applications. Tonight I worked out a nearly perfect configuration which allows me to serve the app through fastcgi in both http, and SSL-enabled https. The media files are directly served by Lighty, without hitting the django backend at all, for maximum speed.

Better yet, this configuration allows me to directly serve the media files through ssl without having to get a separate certificate for the web server. Lastly, it serves both “www” and “non-www” versions of the domain, automatically redirecting “www” traffic.

[Read more...]

Pushing toward a Satchmo Release

surgical tools Pushing toward a Satchmo Release
I’ve been enjoying being a core developer on the Satchmo e-commerce engine built on the Django framework. Finally, we’re pushing toward our first major release, tentatively numbered 0.5.

My major contribution to this release is the payment module system. The idea is to allow for flexible development of payment modules for most any style of payment backend. I converted the existing PayPal and Authorize.net modules to use the system, and I’m working on a Google checkout module as well. Also, I hope to finish the Gift Certificate module before 0.5, but that may need to wait until 0.6.

I also wrote a nice little interface module, allowing the system to manage subscriptions to a store newsletter using a Gnu Mailman backend. I think that is the best of both worlds, an excellent store, leveraging a heavily tested and feature-full mailing list manager.

On a personal note, being a core developer of an e-commerce engine is a good business move. I’ve already gotten three gigs simply by my association with the project. Nice. It certainly spurs me to remain active with the project!

[tags]satchmo,django,e-commerce,open-source[/tags]

New record, three patches accepted in one week.

I have this wonderful client who hired me to build a world-class e-commerce site for him. He gave me carte blanche to use whatever framework I wished, so I chose Satchmo, an ecommerce app for Django.

This was a bit gutsy, as I don’t think there are any live Satchmo stores in the wild just yet, but I’m confident it was a good choice. Every existing system I’ve explored has been either wild spaghetti code (looking at you OsCommerce) or else inflexible in ways that would be unacceptable to my client.

So, I’ve been working flat-out on his site, and in so doing I’ve been doing my best to help the framework along. Just this last week, I set a personal record for contributions to an Open Source app, with three distinct patchsets. All were accepted, woohoo!

[tags]Satchmo,Django,python,e-commerce[/tags]

Django auto_now Removal Gotcha

classical guitar Django auto now Removal GotchaThe latest Django revisions have removed the shortcut handlers "auto_now&quot 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.

[Read more...]

Lighttpd 1.5 prerelease doesn't like Django

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.

Long story short

Don’t use the prerelease, use the most recent 1.4.x stable. Save yourself hours of cursing and trace-debugging.

Analysis

Lighttpd had the following problems:

  • No request PATH_INFO. Django hates that. I hacked my testing version of Django to get past that, but no luck because.
  • Lighttpd just wouldn’t accept the response. I put in trace logs and found that my app was sending a perfect response, but Lighty just wouldn’t listen to it.

[tags]lighhtpd,django,python[/tags]

Howto Reset The Admin Password in Django

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]