Skip to content

Korea Travelogue

By Nathan Yergler
— Saturday, April 28, 2012 at 7:55 pm

I arrived home in San Francisco five hours ago from my first ever trip to Asia. Somehow with all the traveling I did while working for CC, I never made it to Asia or Australia. So R and I decided to spend our vacation this spring in Seoul. Because I want to write some things down (and because I agreed to do this Iron Blogger thing but haven’t yet, and because my alternative is replacing my blog software, which I’m definitely too jet-lagged to do), here are three highlights of the trip.

The center of our week was a day spent in the DMZ. I have to start with this because I still feel the most uncertain about it. We arranged a day long tour of both the DMZ and the Joint Security Area (JSA). Going into it I had some trepidation: was it going to feel light and airy and unserious? Was the fact that two countries are basically at war going to be glossed over? What does it mean that I’m touring (literally, a tourist) a space set aside by an armistice agreement? I suspect the last question is something I’ll write about more at length, but here’s the high level: the JSA tour was terrifying (to me; R didn’t seem to have the psychological reaction quite to the degree I did). The ID checks, the barbed wire, and seeing the North Korean soldiers observing us with binoculars as we walked along the MDL was not light, was not airy, and definitely did not gloss over the fact two countries are at war. Part of this was Laura, our excellent guide for the morning. As we rode the bus north from Seoul, she sagely pointed out, “1,000,000 land mines! You stay with group today!” And then she looked directly at me. The afternoon tour of the “DMZ” — Dorasan Observatory, Dorasan Station, and the 3rd Infiltration Tunnel — was less compelling, perhaps because it was raining, but probably because we only had something like 20 minutes at each stop. It didn’t help that the afternoon guide, Justin, wasn’t operating at anywhere near Laura’s level. I should note that every stop on the tour has a gift shop. Some of them sell products cultivated in the DMZ (ginseng, rice, soy beans — chocolate covered and not), and some sell truly strange souvenirs (see: a plastic axe, which seems in questionable taste). The presence of gift shops did nothing to help me understand how I feel about touring a (theoretically) hostile line.

Another highlight for me was visiting the Bongeunsa Temple and Gyeongbokgung Palace. (R would insist I point out “gung” means “palace”, so I just wrote “Gyeongbok Palace Palace”, but the ticket says “Gyeongbokgung Palace”, so I’m sticking that.) These are two very different places; I’m grouping them together because they evoked similar feelings for me. Bongeunsa was an easy walk from our hotel (and the Samseong Station, if you’re going to check it out), and yielded some really relaxing time wandering the grounds, listening to the chanting, and smelling the trees. Gyeongbokgung, on the other hand, was closed the first time we tried to go, and when we finally went near closing time Thursday, there were lots of people wandering the grounds. Gyeongbokgung is actually like a park, with many buildings enclosed in it. You can look at the architecture, walk around a pond, or explore the nooks and crannies. Like the temple, this had a really meditative feel to me, and we took lots of interesting pictures.

The last day we hit up Dragon Hill Spa & Resort. Apparently the largest in Seoul (Korea?), I signed up for the “gold package” — body scrub, steam massage, oil acupressure, leg massage, muscle massage, facial massage, head acupressure, and, of course, shampoo. Quite possibly the best ₩110,000 I spent all week. The “scrub” felt like it used a scouring pad, but as I lay there afterward waiting for round two, my skin felt tingly and awake. The acupressure and “massage” were intense: every muscle in my body was pounded, slapped, pulled, and kneaded, and then for good measure the joints holding them together were stretched and twisted. I would say I walked away feeling renewed and refreshed, but I’m not sure I really “walked” so much as “oozed”. We went back to the hotel that evening and slept incredibly well. And when the soreness finally fade, I’m sure I’ll feel even better.

Other things we did, which I may write more about at a later date: Kimchi Field Museum (yes, really), Deoksugung Palace (to, ahem, further the “gung” discussion above, this one is really confusing: the ticket says “Deoksugung Palace”, which the brochure says “Deoksu Palace”), cat and dog cafes (cafes where you can play with cats or dogs while enjoying your beverage of choice), open air markets, random shopping, and great food.

No Comments

Categories: travel.

Tags: , ,

hieroglyph: Easy, Beautiful Slides with Restructured Text

By Nathan Yergler
— Tuesday, March 13, 2012 at 10:31 pm

I was happy to have my talk proposal accepted for PyCon this year, and happy with the feedback I received on my talk (Django Forms Deep Dive). But as I was putting my talk together the distracting question was not, “what should I say”, but “what should I say it with”. As a mentor once pointed out, “it’s more fun to write programs to help you write programs than it is to write programs.” The corollary I found over the past couple weeks: “it’s more fun to write programs to help you write slides than it is to write slides.”

I was putting together notes using reStructured Text and kept thinking that it’d be nice to generate both slides and longer written documentation from the same source. I’ve used docutils’ S5 generator in the past, but was looking for something a little more polished looking. Something like the HTML5 Slides.

So I wrote a hieroglyph, a Sphinx builder for generating HTML5 Slides. I presented hieroglyph at the Sunday morning lightning talks at PyCon: you can see the slides, the reStructured Text source, as well as the HTML documentation generated from the same source.

I’m really happy with the output — it looks great in the browser, projects well, and because I’m using the html5slides CSS, looks great on mobile devices, too. I’m even happier that I’m able to work on my content in plain text. You can find the source on github.

1 Comment

Categories: projects.

Tags: , , ,

The OOT Killer

By Nathan Yergler
— Sunday, December 4, 2011 at 9:43 pm

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.

No Comments

Categories: Uncategorized.

Tags: ,

Updating el-get and getelget.el

By Nathan Yergler
— Monday, September 26, 2011 at 9:59 am

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 .

;; add a hook listener for post-install el-get
(defun post-install-hook (pkg)
  ;; after installing el-get, load the local package list
  (if (string-equal pkg "el-get")
      (el-get 'sync
              (append el-get-packages
                      (mapcar 'el-get-source-name el-get-sources)))))
(add-hook 'el-get-post-install-hooks 'post-install-hook)

;; add the el-get directory to the load path
(add-to-list 'load-path
             (concat (file-name-as-directory user-emacs-directory)
                     (file-name-as-directory "el-get")
                     "el-get"))

;; try to require el-get
(if (eq (require 'el-get nil t) nil)

    ;; urp, need to bootstrap
    (url-retrieve
     "https://raw.github.com/dimitri/el-get/master/el-get-install.el"
     (lambda (s)
         (end-of-buffer)
         (eval-print-last-sexp)))

    ;; successfully required el-get, load the packages!
    (post-install-hook "el-get")

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.

5 Comments

Categories: development, tools.

Tags:

super(self.__class__, self) # end of the line for subclassing

By Nathan Yergler
— Monday, July 4, 2011 at 8:44 pm

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:

  1. enter B.__init__()
  2. call super on B and call __init__ on the proxy object
  3. enter A.__init__()
  4. call super on self.__class__ and call __init__ on the proxy object

The 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.

2 Comments

Categories: development, python.

Tags: ,