This week I upgraded to the not-quite-released emacs 22. One of the big changes (for me at least) is the new default implementation of the python major mode, python.el. Some observations:
python.el does not seem to have the same kinds of problems with syntax highlighting of triple-quoted strings that python-mode did. This alone is worth the upgrade in my mind.
In python-mode.el the RET key was bound to py-newline-and-indent. When you typed ‘if condition:RET’ this would automatically indent the next line within the ‘if’ block. In python.el this functionality is bound to “C-j” instead of RET. You can get the old behavior (which I prefer) by putting this in your .emacs:
(add-hook 'python-mode-hook
(lambda ()
(define-key python-mode-map "\C-m" 'newline-and-indent)))
Thanks to johan for the suggestion to do this in a hook.
Turn on transient-mark-mode. This is necessary for certain features like region (un)comment region (M-;) to work. In emacs 21 transient-mark-mode didn’t play well with python-mode, (e.g. py-mark-block didn’t work) so I turned it off. That doesn’t seem to be a problem anymore.
I’m sure there are many more changes but those are what I’ve noticed after bit of use. Overall I’m happy with the new implementation.
My next task will be to get Guido’s xreload to work from emacs.
Posted in Emacs, Python
|
For my birthday celebration last year I did something a little different: a Birthday
Challenge. What is a Birthday Challenge?
… a birthday challenge is essentially a goal,
generally in the form of physical achievement, to make your birthday
more memorable than the last. Usually the number of your years lends
itself to the base of your challenge.
– from http://www.birthdaychallenge.com/whatis.html
Last year’s challenge (my first) consisted of a 26Km run, 26 pullups and 2.6L of beer. For this year’s challenge I’ve
decided to run a marathon, which has been a long-term goal of mine. I’ve signed up for the San Francisco Marathon this July 29th. This is great for a few reasons: this distance aligns with my age (26.2 miles vs 27 years), the date almost falls on my birthday, and I’ll by living in the Bay Area this summer.
I haven’t yet decided what all of the events will be for this year but it will probably include another physical challenge and some kind of eating or drinking. Wish me luck!
One of a software engineer’s most critical skills is the ability to
read code. In my experience developers spend far more time and
effort reading code than writing it. Others agree (Joel On
Software,
Jeff Atwood).
It stands to reason that this is a skill that should be looked for
during the interview process. I’ve found that code critiques can be a
valuable tool in this regard.
They answer questions such as: Can this person see bugs? Can they
comprehend an unfamiliar piece of code? Are they opinionated about
what good code should look like?
For this purpose I came up with a stack-like class that fits on a
single sheet of paper. This class has a variety of flaws ranging from
the painfully obvious to the subtle. The candidate takes a few minutes
to look over the sheet and then we spend 10-15 minutes talking about
code. The issues include:
- Poor method naming (“doIt“)
- Poor time complexity (O(n) when O(1) would do).
- Duplicated code
- Handling of error cases (does a pop on an empty stack corrupt the
datastructure?)
- Memory leaks
- (Java-specific) Misimplemented Object#equals method
- Input validation (does pushing a null onto the stack cause later failures in the contains method?)
- Inconsistent and/or non-existent comments
What I like about this process is that it give a very fine-grained
scale to understand how someone thinks. If they don’t mention
something you can start a conversation on that topic. “So what do you
think the time complexity of pushing N items would be? Could it be
better?” “What happens if multiple threads use the class at once?”
So far I’ve tried this on a small sample of candidates and it has been
a reliable discriminator. One person failed miserably, one person
more or less aced it, and a few more landed somewhere in the middle.
With more time and experience I hope to refine the process further. I
would love to hear from others who have thoughts or experience with
this technique.
Update:The CSE team has included this functionality directly into Coop-search, so this code isn’t necessary anymore.
I’ve been playing around with the Google Custom Search Engine (CSE) feature recently. CSE lets anyone create a search engine that indexes a user-defined set of URL patterns. I thought it would useful to create a CSE based on links in RSS feeds. The motivating example was programming.reddit.com. Pages linked there are submitted and voted on by the users, and the top-ranked items are consistently interesting and relevent. A CSE derived from sites like this is useful for a few reasons:
- Answering the question, “What was that page I saw on reddit 2 weeks ago about that thing?” I’m often trying to track down a page I remember seeing on reddit a long time ago, and a standard web search isn’t useful in this case.
- Building search engines that take advantage of the filtering done by human editors. CSE can search a set of URL patterns exclusively, or can augment a full web search by emphasizing selected URLs.
I’ve written a set of python scripts that can turn an RSS feed into a CSE annotations file and then upload the annotation list automatically. Here is an example of the resulting search engine. At the time of writing this CSE searches 1,323 web pages collected from the programming.reddit.com RSS feed over the last month. The set of links is updated once a day by a cron job.
More information on how to run the scripts yourself is in the README file. The code is distributed under the PSF licence and can be retrieved with a subversion client from here. Any feedback is of course appreciated.
Note: According to my reading of the CSE TOS this is a legitimate usage. I asked on the group and had no response. If anyone knows otherwise please let me know.
Hello! I’m a software engineer living in Chapel Hill, NC. You can find out more about me here. I’ll be writing about the projects I’m working on (mostly software) and anything else I find exciting.
The name of the blog is inspired by this quote:
In the long run, every program becomes rococo, and then rubble.
– Alan Perlis
