2013

Flashing a Nexus device with Ubuntu Touch from Mac OS X

I've been working with Ubuntu Touch recently, using VirtualBox to run Ubuntu Saucy as a guest on my Mac, and while it does work to connect to the device once it's installed, the process of reflashing is difficult. The manual steps on the Ubuntu Wiki Touch/Install page work for the old way, via phablet-flash cdimage-touch, with the caveat that you may have to manually reboot the device and/or re-connect the USB in between steps.

However, as of this email last week, the official way to flash phones is using the system images via phablet-flash ubuntu-system, which has a different set of files.

Instead of just muddling through and updating the manual instructions, I decided to see if phablet-flash would run natively on the Mac. After a bit of python dependency resolution, it does. Here's what I did:

  1. Download the Android SDK tools. You only really need the "SDK Tools", not the whole ADT Bundle, so I clicked on "Use an existing IDE" at the bottom of that page, to get the smaller installer.
  2. Unpack the archive and run ./android. Install the platform-tools (and nothing else).
  3. Add the platform-tools/ directory to your $PATH for convenience.

  4. (Optional) create a virtualenv for the python dependencies, and activate it.

  5. pip install each of configobj pyxdg, and pyliblzma
  6. get bazaar if you don't already have it.
  7. branch phablet-tools: bzr branch lp:phablet-tools
  8. cd phablet-tools && python setup.py build
  9. At this point, phablet-flash ubuntu-system should work smoothly, with all transfers and reboots and timeouts going as expected.

The only minor hiccup is that it apparently doesn't get ~/Downloads/ from pyxdg, but it just means that you'll get the images saved to ~/phablet-flash instead of ~/Downloads/phablet-flash. No big deal.

Links: Simulation, Programming, Crab Cakes and Hockey Player Usage Charts

  • DYNAMO Someone has rewritten one of the earliest simulation systems in JavaScript (the fate of all interesting software). Also includes a link to an article about the history of simulation software that sounds very interesting.
  • The Food Lab: The Crabbiest Crab Cakes I love crab cakes, but I'm not sure I really want to try to make them at home. If I do, I'll use these tips. The Food Lab is fun stuff.
  • Debug It! A review of a book on debugging, which is a topic that I think should be taught right alongside programming. See also "Why Programs Fail"
  • GiveDirectly: introducing a radical new way to give! | GiveDirectly Send cash straight to poor people. If their assertions are true, it's a really interesting idea, and I can't believe it hasn't been done before. It also seems transparently better than microloans.
  • ContinuumIO/Bokeh · GitHub Something to look out for -- a Python ggplot that works with HTML5 is a great idea. "Bokeh (pronounced boh-Kay) is an implementation of Grammar of Graphics for Python, that also supports the customized rendering flexibility of Protovis and d3. Although it is a Python library, its primary output backend is HTML5 Canvas. There are many excellent plotting packages for Python, but they generally do not optimize for the particular needs of statistical plotting (easy faceting, bulk application of aesthetic and visual parameters across categorical variables, pleasing default color palettes for categorical data, etc.). The goal of Bokeh is to provide a compelling Python equivalent of ggplot in R."
  • FitDesk X1 Level up from a standing desk? I'd love to try this for a day.
  • Concurrent Revisions DVCS-like concurrent programming. Interesting sounding research - I haven't read it yet...
  • Many thanks to @robvollmannhl and the good folks at Hockey Abstract for these great interactive Player Usage Charts: hockeyabstract.com/playerusagecha… Player Usage Charts are fascinating, but I can never figure out why people always change the axes so that the dots fill the space. It makes it impossible to compare two charts, and it's not obvious, so you end up comparing charts without realizing that it's meaningless.

Mock nested properties with python-mock

Python's mock library (part of stdlib in 3.3+) is a great tool for writing concise tests. Its documentation is very good, and rewards multiple reads - but I found one thing that wasn't totally clear, even after looking through a few times. I wanted to use PropertyMock to mock nested Properties. Specifically, I had patched the python Gnome-introspection wrapper for libsoup at the top level Soup objcet, and I also wanted to replace one of its nested constant properties, Soup.MemoryUse.COPY with a sentinel that I controlled, for later comparison.

The idiom for PropertyMock is to assign a PropertyMock to the type object of the Mock object whose property you want control of. What I found is that because Mocks auto-create properties, it's possible to do nested mocking in one line, like this:

import mock
m = mock.Mock()
type(m.a.b.c).d = mock.PropertyMock(return_value = mock.sentinel.my_value)
assert(m.a.b.c.d == mock.sentinel.my_value)

So my soup example looks roughly like this (mixing testing and tested code, and repeating literals for brevity):

json_body = "{}"
with patch(gi.repository.Soup) as mock_soup:
    from gi.repository import Soup
    type(mock_soup.MemoryUse).COPY = mock.PropertyMock(return_value=mock.sentinel.COPY)

    # tested code:
    message = Soup.Message.new("POST", "http://fake.com/api")
    message.set_request('application/json', Soup.MemoryUse.COPY, json_body, len(json_body))

    # checking:
    assert(mock_soup.mock_calls == [mock.call.Message.new("POST", "http://fake.com/api"), 
                                    mock.call.Message.new().set_request('application/json', 
                                                                        sentinel.COPY # <--- this was the point
                                                                        "{}", 2)])

It's often possible to think of a shorter, clearer use of the mock library after revisiting a problem, but so far this still seems good. Let me know in the comments if you have a suggestion for improvements.

Don't Snooze

Mailbox is a new iPhone email app that grabbed a lot of attention recently, partly because of their waiting list for using it. It's a gmail-only system that stores copies of your email on Mailbox's servers, so they can do new features beyond the standard mail client. Even though I got through the waiting list a week ago, I haven't tried it myself, because I wasn't

I have a few religious beliefs about email. One is that processing incoming email is different from

that you should only process a message once - when you first see it, you should decide what to do next with it, even if that's "read it again later",

I call it a religion because I believe it, but I don't always practice it. I have an inbox full of things I've looked at once and am procrastinating on, partly because it's hard to move things to the todo list that I use from Gmail. It annoys me every time I look at my email, and I've forgotten important things that I left sitting there. This is exactly why I think it's important that our tools encourage good habits, instead of encoding bad ones.