I saw this today on djangosnippets and figured it’s useful enough for me to post! Sometimes when writing a webapp you need to debug the output of your e-mail sending. This can be quite hard as things have to, usually, go via an SMTP server. What you really want is a quick way to grab the output with all the headers that YOUR code is setting - you can, easily, with Python.

OSX/Unix/Linux

sudo /usr/lib/python2.5/smtpd.py \

    -n -c DebuggingServer localhost:25

(obviously on Solaris/OpenSolaris you want to use pfexec instead of sudo!)

Windows

c:\python25\python.exe c:\python25\lib\smtpd.py \

    -n -c DebuggingServer localhost:25

You then get an output in the terminal window you ran it in every time a message hits the server. Handy.

Well it’s been a very busy couple of months since I posted on here. We’ll skip through why I haven’t posted in a blink of an eye though.

I got promoted (yay), Wedding prep is going well and is on track, Work is extremely busy - leaving not much time for other pursuits.

Anyway… I’ve been playing with DTrace recently. For those that don’t know what DTrace is I sincerely suggest you check out the video of the Google Tech Talk by Bryan Cantrill on Google Video.

My favourite bit of the video is where he recounts his early weeks at Sun and talking that software is different.

“Software is different, software is unique. And we try and draw analogies between software and other things we build; those analogies always come apart”

And at 4:26: “This isn’t a thing! This doesn’t exist! We’re not seeing a manifestation! We’re seeing a representation of an abstraction. This doesn’t exist anymore than your name exists. Your name doesn’t exist. We made it up! Doesn’t this bother you?”

Now although Bryan then uses this as a starting point of the whole DTrace debugging method - he has another distinct point. A point which has come true at nearly every point in my career. You can’t design the design before the design.

So, back to DTrace.

I love it. No really, I do. The real power of it for me comes from monitoring the three main scripted languages: Python, PHP and Ruby (on and off Rails).

On my Solaris 10 box (yes, no fancy Developer Express on this testing). I now have Ruby 1.8.6 (with p111), Python 2.5.1 and PHP 5.2.0 working 100% with DTrace. That is - I can actually trace through what a running PHP script in Apache is doing.

That is immensely powerful.

Here’s the thing though. The PHP addon for DTrace doesn’t work. I have fixed it and sent the information on how to fix it back to it’s maintainer (hopefully an official fix will come out in a few days from him). Ruby 1.8.6, although there is a patch, doesn’t have the latest security fixes. Not overly useful? I have patched that locally (if anyone reads this and wants the patch - let me know).

Python 2.5.1? That doesn’t appear to exist at Sun. Although someone made a rough patch for it. It doesn’t compile, work or anything. Why release it if you haven’t even compiled it…? No matter. It took a couple of hours - but I got that working too in the end.  That one however is a ‘new’ patch. Again - if anyone wants this patch, let me know.