The scope of shell history
One of the little divides in Unix is the one between people who set up their shell to have a per-shell command history (a local history) and the people who set their shell up to use a global history.
While I know perfectly sane and sensible people who are in the global history camp, I am firmly on the local history side, because to me my shell history is contextual. When I hit cursor up or tell a shell to redo the last command, I want it to do redo the command that is right there in that window; I do not want it to redo the last command I did anywhere. (In fact, I doubt I could keep track of the last command I did.)
I suspect that a lot of sysadmins will fall into the local history side. Sysadmins operate in so many different contexts, some of which are split apart by necessity and cannot be joined, so it's very hard to have a truly global history that covers every command, on every machine, as every user. My guess is that once people start working with only semi-global history that they will prefer to go whole hog to local history.
Although I don't know if any shell supports it, there is an intermediate option: maintain both a local history and a common global history, but only look at the global history if the local history is exhausted. That way you keep local context but also get to pull back that neat ad-hoc pipeline you came up with two days ago in a window that you have long since closed down.
(Before you tell me about it, this is not quite what bash does; it freezes the 'global' history the moment you start it. Bash uses its own hybrid model that makes my head hurt.)
Using WSGI for performance tuning
Doing profiling and performance tuning on a web application is normally a big pain. It's hard to profile things when processes (or threads) are always coming and going, and the typical web environment has so many sources of random delays that it is difficult to do fine-grained performance comparisons between two bits of code.
With WSGI, you can get out of this. Your WSGI application doesn't deal with the web directly, so you can write a WSGI frontend that is just a timing and profiling harness: it mocks up WSGI requests, fires them into your application, and discards the results. Unless your WSGI application itself forks or is threaded, profiling is easy, and in any case you can now time just your application instead of the entire system.
(This works in reverse, too; you can make up a 'null WSGI application' for when you are doing performance tuning on your WSGI frontend.)
The potential fly in this ointment is that your frontend needs to initialize your application somehow. Hopefully this is something you can extract from your usual WSGI framework.
My tuning frontend for DWiki is done this way; it's a command line program that I give a URL and how many requests to make, and it either profiles the run or tells me the time per request. It's quite convenient and easy to use, which makes it more likely that I'll bother to check the performance effects of code changes.
(Opinions may differ on whether this is a good thing; premature worrying about optimization is one of the roots of evil.)