We, here at the lab, appreciate the value of letting the user hack out their own solutions to problems that they may have stumbled upon that don't fit our vision. There's barely a day goes by that you won't hear Mark suggest a rubbish new feature, get instantly shot down, and then insist that he'll write a Greasemonkey script for that functionality anyway.
With this in mind, the fixx team have always maintained that there will be a fixx API, so that developers may adapt fixx to meet their bug tracking needs. While still in relatively early stages, that API is coming together and you can check out the progress in the beta by going to any issues screen and appending .xml or .json to the URI (/issues.json, for example). This was still mostly unusable (unless you want to jump through some pretty hefty hoops), until recently when Sarat committed a change to allow basic HTTP authentication. This change is not available to the masses yet, however, to show off its potential usefulness, I've put together a quick shell one-liner to get the number of issues assigned to me:
curl -u user:password http://SERVER/issues.xml?qAssignedTo=19 | xmlstarlet sel -t -v "count(//issue)"
Which when fed into conky, an ace Linux desktop text rendering app, leaves you with a widget that looks a bit like this:
Useless? yes. Limited? Of course. But if this divvy can use it, you won't have any trouble whatsoever.
Since joining The Lab, I have had the pleasure of working with Django a whole lot more. In this time, I’ve noticed a couple of tricks / niceties that make development run a lot smoother, here are a couple…
Evolution of debugging
Web development is full of little debug tricks, usually involving variations on variable inspection. Django provides lots of such useful methods, and I have found myself progressing through more powerful solutions as I discover them.
return HttpResponse({variable to inspect})
As far as I am aware, this is the most basic form of debugging. Just stick that string at the point in your view where you wish to examine the state and it will short circuit the view code with the variable result. It’s the Django equivalent of alert(). In a lot of development, this will suffice, however this is limited to the scope of view code.
print {variable to inspect}
Usable in any Django Python code running on the Django development server, lob this in and it will publish the result to the console. I usually put some \n’s around it to easier spot it amongst the response codes. For me, the limitation of only being able to use it in the dev server isn’t a big one, because that’s where I do most of my development. The only real issue is when I realise that I want a different variable, change the code and restart the server. Some debug context (solved by the next method) would be nice.
(#5677 suggests that this is bad form and could cause troubles when using over mod_python, depending on your set-up.)
raise Exception({variable to inspect})
I realised this beaut through the most excellent Django wiki. By raising the exception (with debug = True in your settings.py), you force the lovely Django debug page to display - chocked full with helpful info, tracebacks and context - along with your inspected variable at the top.
import pdb; pdb.set_trace()
This is my personal favourite. It activates the Python Debugger and allows you to step through your code and interactively check each variable.
Type “help” for a list of commands, “args” prints the arguments sent into the currently running function, “next” executes the next line, p {variable to inspect} prints a variable, pp {variable} pretty-prints a variable and continue tells pdb to run the rest of your code (unless we hit another breakpoint).
My google-fu has recently revealed django-logging, a Django middleware component which provides the ability to spit out variables in your view and based upon the Python Logging module. I am yet to try this, but it looks like another ace string in your Django debugging bow.
In addition to these, there is always the incredibly helpful <% debug %> tag, to spit out your context variables while template coding.
IPython
IPython has spoiled me rotten. It is an enhanced Python REPL environment with a lot of extra bells and whistles. First off, the code completion is fab. django-admin.py recognises that you have IPython installed, so typing “./manage.py shell” allows you to import your models and inspect them with a quick “.<TAB>”.
IPython makes reading code / docstrings a breeze - you don’t know what django.models.cheesypuff is? type “django.models.cheesypuff?” to get information and documentation about the object / method printed to your screen. That doesn’t help? then try “django.models.cheesypuff??” to get documentation AND source code. It’s brilliant.
The best bit about IPython (apart from the above and it also having access to your system shell) is that it is scriptable (in Python, of course). So all sorts of nice little tricks can be used to make life easier, one of my favourites is this little snippet. It tells IPython to automatically import any model associated with your current Django project, I’ve edited mine slightly to print the names as they’re imported so I have a nice index of the models available to me without having to traverse lots of models.py files.
In short, IPython is a fantastic tool - any work I do on querysets or databases I interactively run through in that shell first - it makes it easier to quickly catch gaps in my logic. IPython also stores all of your history (type “%history”), so you can easily copy and paste that into your editor of choice. There’s plenty I haven’t discussed (if you paste in doctests, it strips out the >>>’s allowing you to run them with a quick ctrl+v), but I’ll leave you to have a play.
“SIMON! Introduce yourself!”
No way!
“Introduce yourself…”
Ok! …I’m Si! …the new guy! …be nice to me cos I’m shy!
Erm, yeah..anyway. “People” have been nudging me to get on the ol’ blogaroonie to say “Hi”, but apparently, that modern masterpiece above wasn’t enough / could be considered slightly creepy.
As you may have gathered, I’m Simon… or Si… or the douchemeister general, and I too am a new hedgehog lab employee. My official title is, “Director, Research & Development”, but that’s only cos “Code Playboy” was taken. By Sarat. It essentially means that I get to dabble with different technologies and tell people about them. Just to give some context of what I mean by “different technologies”: I’m a huge fan of Python and the Django framework, I think that XMPP has a lot of potential with regards to APIs, and I believe that data portability is going to be huge.
A couple more important (and somewhat religious) tidbits: I’m a Linux guy myself (they’ve already got me setting up Ubuntu servers up here), and my editor of choice is VIM (not double jointed enough for that OTHER one).
I have joined from a larger company, where I worked as a front-end developer of sorts for about 18 months. Being at hedgehog lab is a completely different ball game: in a smaller company you contribute to pretty much every area, whether that’s saying “good idea, let’s go with it!”, suggesting an alternative, setting up a Ubuntu server, configuring software, fixing a bug, or playing with some wireframes, I have done it. All in the space of a month.
That has its good points and its bad (primarily that there’s always work to be done!), but it gives me the impression of having more input, and the lack of any major approval hierarchy (beyond, “Sarat am I ok to try this…?”) sees a very quick turnaround in getting stuff from idea stage to reality.
Needless to say, it’s great at the lab. I hope to bring you a new entry (hopefully with more substance) in the near future.
