Boomer Gallery

I started watching Bubblegum Crisis: Tokyo 2040. It has robots and androids, collectively known as "boomers". "Boomer" already has a meaning, so funny double meaning scenes were unavoidable. So, I decided to take a screenshot every time someone says "boomer".

For this task, I first extracted the subs in VOBSub format with MKVtoolNix, then converted them to SRT (text) with FFMES. I then made a Python script that uses the srt library to look for occurences of a word and return the time codes when it appears. Use it like

./rip.py subs3.srt boomer| tail -n+2 | cut -d " " -f 7 > k3.txt

I was going to use FFMPEG to extract the screenshots, but turns out, it's easier with mpv Here's line I used: 

mpv --quiet --no-audio --vo=image --start=0:03:02.309000 --frames=1 --vf=sub 01\ Can\'t\ Buy\ a\ Thrill.mkv

I made another script that gets the shots at the specified times.

Daily Dharma

To pass on the gift of Dharma, I developed a Twitter bot that tweets one verse from the Dhammapada Dharma Store each day. The source code is on Github.
Effective awk Programming was a great help while I developed my first awk program, to weed out verses too long to be tweets.
Dhammapada is available for free on Project Gutenberg, or on Amazon.
Whatever way you discover Dharma, it is like finding priceless jewels on your path.

BookMooch Android app, with Android Scripting Environment

Inspired by this LibraryThing script, I made a python script for  Android Scripting Environment that reads ISBN codes from bar codes and adds books to my BookMooch. Basically, ASE lets you access Android APIs in many scripting languages (supported interpreters include Lua, BeanShell, Python, Perl, JRuby, Tcl, JavaScript, Ruby, etc). What makes this experiment, and ASE, interesting, is the possibility for rapid development of impromptu apps like this (the script is 6 lines long). Best of all, it's entirely possible to put a hack together directly on the device - ASE comes with an integrated API browser to better facilitate this.

As Matt Katz, author of the LibraryDroid script, put it:

That’s the openness I’m talking about. No approvals, because the phone is mine, not Google’s or Apple’s. I love it.

Now contrast this with

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).