Because eventually I'll be right. Theoretically.
Recently I have been suffering from the delusion that making more commitments will make me more able to achieve them.
My first reaction to reading Asheeh’s reflections on commitments: “Yes, and I wish I’d learned that about ten years earlier than I did.” And then I remember that it’s not something you learn once; tending to your committments — and making them with care — is a life-long practice. Practicing is hard, but it’s preferrable to encountering the OOT killer.
Categories: Uncategorized.
Last week one of my Emacs using colleagues asked me how I managed my Emacs packages and configuration. Naturally I pointed him to el-get and my getelget.el bootstrap script. I’ve been happily managing my Emacs installation over the past five months using el-get and a private git repository for my configuration. However when I tried to square my .emacs.d/init.el with the current el-get documentation, I got a little confused; el-get is now better at bootstrapping itself from within your Emacs configuration. When my colleague read this and asked why he might want getelget.el, my response was… well, lackluster; this is an attempt to document that a littler better.)
Last night I decided to do a little clean-up on my Emacs configuration, and see if I could get rid of getelget.el. The documentation for el-get is great, so I started there. What I quickly realized is that the included el-get bootstrap mechanism is great if you want to ensure el-get is installed and then use el-get-install, el-get-remove, etc to manage your packages. But if you define your package list in you config file, it’s not quite enough. Specifically, when you first bootstrap your configuration, you want to defer calling (elget 'sync) until you’ve bootstrapped el-get. And on future runs, you want to go ahead and install any new packages that have been added to your list.
Luckily el-get has added support for hooks, which makes life a little easier. The new getelget.el (available here) looks something like this:
;; getelget - el-get boostrap script
;;
;; Checks to see if el-get has been checked out, and bootstraps it if
;; it has not. After bootstrapping, calls el-get to load specified
;; packages.
;;
;; el-get-packages should be defined before including this file. Any
;; definitions from el-get-sources will be appended to el-get-packages.
;;
;; Written in 2011 by Nathan R. Yergler
;;
;; To the extent possible under law, the person who associated CC0 with
;; getelget has waived all copyright and related or neighboring rights
;; to getelget.
;;
;; You should have received a copy of the CC0 legalcode along with this
;; work. If not, see el-get also recommends splitting your package definitions from your local source recipes (which can themselves extend an included recipe). So getelget.el now expects you’ve defined two lists: el-get-packages, a list of packages to install from recipes, and el-get-sources, your local source list.
For example, I define a local recipe for magit that binds a key to magit-status and enables spell checking and fill mode for commit message editing:
(setq el-get-sources
'((:name magit
:after (lambda ()
(global-set-key "\C-x\r\r" 'magit-status)
;; Enable spell checking, fill for log editing
(add-hook 'magit-log-edit-mode-hook
(lambda()
(auto-fill-mode 1)
(flyspell-mode 1)))))
))
And my el-get-packages list is just a list of packages I’m installing from the included el-get recipes.
(setq el-get-packages
'(el-get
google-maps
color-theme
python-mode
virtualenv
php-mode-improved
xml-rpc-el
js2-mode
org2blog))
Everything listed in both lists will be installed.
YMMV, FWIW, ZOMG, BBQ, etc.
Categories: development, tools.
I’ve learned (and remembered) a lot in the past two months as I’ve gotten back to coding as my primary job. One thing that I guess I never quite internalized before is how super works. I have been bitten by code that looks something like the following a few times in the past month:
class A(object):
def __init__(self):
super(self.__class__, self).__init__()
class B(A):
def __init__(self):
super(B, self).__init__()
The surprise comes when I try to use my sub-class, B. Instantiating B() blows up the stack with:
RuntimeError: maximum recursion depth exceeded while calling a Python object.
What?
According to the Python 2.7.2 standard library documentation, super “return[s] a proxy object that delegates method calls to a parent or sibling class of type.” So in the case of single inheritance, it delegates access to the super class, it does not return an instance of the super class. In the example above, this means that when you instantiate B, the follow happens:
B.__init__()super on B and call __init__ on the proxy objectA.__init__()super on self.__class__ and call __init__ on the proxy objectThe problem is that when we get to step four, self still refers to our instance of B, so calling super points back to A again. In technical terms: Ka-bloom.
TL;DR: super(self.__class__, self) may look like a neat trick, but it’s the end of the line for sub-classing.
Further reading: Raymond Hettinger’s excellent blog post on super provides a great overview of super and shows off the improved Python 3 syntax, which removes the need to write the class name as part of the super statement. I was really pleased to find the Python standard library documentation links directly to it.
Categories: development, python.
I’ve been taking print making classes this year, and have really enjoyed exploring something new. What’s been particularly interesting for me is seeing parallels between what I think of as a creative hobby – print making – and what I think of as creative work – writing software.
I showed my work publicly for the first time two weeks ago. The day after the show I had booked time in the studio. I showed up after work that day with my tools, anxious to get back to printing. It had been a couple weeks since I’d been in the studio, and last time I was there had been very productive: I’d spent the entire day working with the same image, producing six unique prints as I tried to add more texture and depth to the precise lines of the stencils I’d been creating. The result was a set of prints which were somewhat uneven in quality, but which showed a progression of control and vision. With each one I tried something a little different, until I felt like I had a good understanding of what I really wanted. Going into the studio that evening, I had about three hours of printing time, and hoped to bring that same exploration to another image.
I did wind up with five prints that evening, but none of them resonated for me like the Golden Gate Bridge prints did. As I pulled each print, I’d look at it, realize it wasn’t what I’d had in mind, and try to think about what to do next. Time in the studio usually passes quickly, and I feel like I’m racing the clock to do everthing that comes to mind. But that evening felt disjointed and choppy, and when it came time to clean up, I was ready to go home. I’d tried serious, whimsical, and abstract, and none of them felt like they worked for me that night. As I rode home from the studio, I felt disappointment. The experience wasn’t the effortless expression of creativity I was used to, and the work I had produced didn’t speak to me as I hoped and had come to expect.
The next morning I looked over the pieces again, and I realized that in each case there was one or two things that I didn’t like, which overwhelmed the rest of the piece. In one case I made a choice about negative space that turned out to be the wrong one. In another I tried to do too much at once, and my vision hadn’t translated well onto paper. As I stood there looking at each piece, I thought to myself, “Why didn’t you just do this exact same image again, but change the aspect you didn’t like?” Somehow I’d forgotten that it was OK to repeat yourself, to try again if the result wasn’t what I was looking for. I’d fallen into the trap that creativity is all about the flash, the spark, and that it just magically happens.
If I think about writing software, I’m well aware that getting the result I want is real work: we have test suites, debuggers, and continuous integration tools for a reason. We often don’t get it right on the first try. Just because the “test suite” for print making is personal and subjective doesn’t make iteration any less important.
I had my first linocut class Wednesday evening. Linocut involves carving a linoleum plate with an image, which you can then use to make a print. Our instructor asked us to bring a simple image to use for our first plate, and to get some experience with carving. I spent some time searching for the “perfect” image to use, something that I would be new and different and push the boundaries of my print making. In the end I wound up taking one of my monotype stencils and generated a scaled down version of it. And I couldn’t be happier with how it turned out.
Yes, it’s the same cat that I’ve been working with for the past couple months. But that doesn’t mean I’m not expanding my skill set, trying different techniques, and iterating. I have plenty of time to try new images out, and if I spend the time now, debugging my technique and learning how to iterate (just like I do with software), I think my ability to tackle more complex and involved work will grow, just like it has with software.
Update (20 April 2011): I’ve now tried this on my old MacBook running OS X 10.5. The bootstrap script initially threw an error, which I tracked down to an outdated version of git. Once I upgraded git and installed bzr (used by the python-mode recipe), I started Emacs and was rewarded with a fully functioning installation, complete with the extensions I want.
I’m on vacation for two weeks between jobs, so of course this means it’s time to sharpen the tools (because writing programs to help you write programs is almost always more fun than actually writing programs). I’ve been an Emacs user for many years, and of course I’ve customized my installation with additional modes and extensions. Previously I would check out code that I needed into a vendor directory, and then load it manually in init.el. And this worked fine, but that doesn’t mean I can’t won’t spend a chunk of my day making it better.
A friend mentioned el-get to me, and I decided to give it a try. I like the combination of recipes for installing common things, and the fact that your list of packages is very explicit in init.el (so if I need to dig into one of them, I know exactly where to begin). Additionally, since I’ll have a new computer issued for the new job, I also wanted to get things into shape so that I could easily replicate my preferred editing environment. I wound up creating a small bootstrap file to help things along, getelget.el.
getelget.el checks to see if el-get has been previously bootstrapped, and if not, performs the lazy installation procedure. After it makes sure el-get is available, it loads and executes el-get. So if you need to get a new machine up and going with Emacs and any extensions, you can drop in your init.el and getelget.el, and Emacs will take care of the rest.
To use getelget, define your el-get-sources like you normally would in init.el:
(setq el-get-sources
'(el-get
python-mode
;; etc...
)
)
Then load getelget (the following assumes you have getelget.el in your user emacs directory along with init.el):
;; getelget -- bootstrap el-get if necessary and load the specified packages
(load-file
(concat (file-name-as-directory user-emacs-directory) "getelget.el"))
getelget will handle bootstrapping, loading, and executing el-get.
getelget is pretty trivial; you can download it here, and I’ve waived any rights I may hold on the code using the CC0 Public Domain Dedication.
Categories: development, tools.