Archive for May 2009

Quodroid, an app just for me

I’ve spent a few days reading through the Android developer docs and trying to get Eclipse to cooperate with my outlook on software development. It took giving up on Eclipse to get any real coding done. It was a bit tricky, as I’m not the all-star Java programmer I once was, and I got bogged down on silly syntax errors and library issues. For example, I forgot that ‘new’ is a keyword in Java, and trying to instantiate a class without it results in errors that don’t say, “what do you think this is, Python?”.

The pet project I started is an extremely simple music remote control to interact with Quod Libet, my music player of choice, running on my laptop. So now if I have my phone at the couch I don’t have to get up and walk six steps to my desk to pause or skip to the next song.

The overall architecture is mildly embarrassing, but works well. I’ve got a very simple web.py server running on my laptop that accepts three urls — prevous, next, and play-pause. When one of these is received, it sends a control command to quod libet to perform the associated action. The android client simply displays three ultra-ugly buttons that send requests to a (hard-coded, no less) IP and Presto! I can skip tracks and pause my music!

It’s barely working yet and the design is atrocious, but I’ve posted the initial version to github for peer review and patches storage.

I really just wrote this for myself, the fact that I’m releasing it is mostly because a) I have a blog now and b) I have a github account now.

I’ve got several things on my to-do list, most importantly improving the client interface. I want to add volume control as well, and the ability to return the current song whenever an action is invoked. I might even add a polling feature to update the displayed song on the phone. I also need to do some config stuff, hard-coding the url may actually not be that flexible.

The Lost Art Of Proofreading

I am an amateur proofreader; I would like to be a professional proofreader. To date, however, all my work has been volunteer and includes several MSc theses, a few academic papers, numerous Arch Linux newsletters, and two unpublished novels. I enjoy the process of proofreading, of axing unnecessary words, of caressing, cajoling, or cursing the right sound into a written sentence. You see, proofreading is not just about grammar. Its about cadence, flow, style, and rhythm. Above all, its about communication.

And it’s a lost art. I estimate that at least 90 percent of articles on the Internet these days are posted without review or revision. While this is obvious in youtube comments and web forum postings, it also includes countless articles by professional journalists from well-known news agencies. Indeed, some of the worst writing I read each day arrives via Google news results. Independently authored blog articles may be better; they can range from quick thoughtless posts to elegantly crafted prose. Sadly, the majority of authors simply write their article and forget about it.

We are always in a hurry to get information to the masses. News isn’t news if its not new. Why proofread when the information you’re posting is going to be irrelevant in a few hours? First Post! McDonalds has taken over our writing. I want that burger in 43 seconds. Don’t worry about the taste, just serve it quicky. No no, I don’t care if its healthy, I don’t have time to think about that. I’m in a hurry, you see.

I have to get this article posted before my coffee cools down.

It’s a race, a race to provide new information or insights before anyone else. A race that ignores, discards, even condemns quality. A race that defines our society.

Have you ever read something and thought to yourself, “I love how that’s worded. It’s beautiful”? Possibly not — I could be peculiar that way. More often, though, I end up thinking, “What a lovely sentiment; too bad they butchered the wording.” There need to be more beautiful essays. Essays that are a joy to read, and not just a chore to understand.

Style matters.

In four posts to this blog, I have covered an introduction, a software concept, a technical article, and a social discussion. These articles have but one thing in common: I wrote and posted each one immediately. I didn’t proofread them. Sure I read through them once, maybe twice before clicking “Publish”, but that’s not proofreading. Proofreading involves letting the essay marinate for a few hours, maybe days, before posting, then carefully revising — from a reader’s perspective. I didn’t do that.

But this time I will. This post can wait a day or two to be consumed by the public. From now on, that ‘Save Draft’ button is going to get a lot more use.

If you’re not looking to hire a semi-professional proofreader/editor for your next written work, maybe you should think about it. If you think about it, think about me. I’m available and I’m sure we can agree on a rate.

Introducing Opterator

When I attended Pycon 2009, I saw a lightning talk on a neat little tool called Argparse. Its a python option parsing tool designed to be easier to use than optparse.

In the first few seconds of the talk, I thought to myself “I know where this is going. It’s brilliant.” I said so to the guy next to me. Then I took it back because while argparse is a pretty cool idea, its not the brilliant idea I thought it was.

See, I thought the tool would automatically introspect a script’s main method and use the docstring to provide any missing information. That’s what I thought would be brilliant.

Since it didn’t do that, I did it. Its certainly not full-featured yet, but it works for basic options and arguments. For 90% of scripts, that’s all you need. I called it opterator and put it on github:

http://github.com/buchuki/opterator/tree/master.

git clone git://github.com/buchuki/opterator.git

Here’s an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
from opterator import opterate
@opterate
def main(filename1, filename2, recursive=False, backup=False,
        suffix='~', *other_filenames):
    '''An example copy script with some example parameters that might
    be used in a copy command.
 
    @param recursive store_true -r --recursive copy directories
        recursively
    @param backup store_true -b --backup backup any files you copy over
    @param suffix store -S --suffix override the usual backup
        suffix '''
    filenames = [filename1, filename2] + list(other_filenames)
    destination = filenames.pop()
 
    print "You asked to move %s to %s" % (filenames, destination)
    if recursive:
        print "You asked to copy directories recursively."
    if backup:
        print "You asked to backup any overwritten files."
        print "You would use the suffix %s" % suffix
 
if __name__ == '__main__':
    main()

Obviously, that only parses the options, its not doing the actual copying because implementing that would do nothing to illustrate how opterator is working. Here’s one run of it:

dusty:opterator $ python copy.pyc -b a b c d -r
You asked to move ['a', 'b', 'c'] to d
You asked to copy directories recursively.
You asked to backup any overwritten files.
You would use the suffix ~

Here’s the automatically generated help:

dusty:opterator $ python copy.py -h
Usage: copy.py [options] filename1 filename2 [other_filenames]

An example copy script with some example parameters that might
    be used in a copy command.

Options:
  -h, --help            show this help message and exit
  -r, --recursive       copy directories recursively
  -b, --backup          backup any files you copy over
  -S SUFFIX, --suffix=SUFFIX
                        override the usual backup suffix

I named it opterator because I wanted a name that didn’t have ‘parse’ in it. I was going to go for operator but I realized if you heard about this app called operator and searched google for ‘python operator’ you’d get swamped. ‘opterator’ is unique and highlights the option part of the task. Plus it allowed me to invent a new verb: ‘opterate’. Days when I get to invent new verbs are always good days.

I used py.test for testing (another gem I discovered at pycon). You don’t need to run the tests, but the tests are useful examples to see what opterator can do, so have a look.

So I hope somebody finds this useful or even awesome and contributes some patches to make it more of the above. Enjoy!

Todo List

I’ve spent a lot of time thinking about the proper way to design a calendar and to-do list application.  The irony: I never got around to putting ‘write to-do list application’ on my to-do list.

The best to-do list I’ve seen was designed by Kim Hoyer with input from myself and another developer. Its part of Kim’s proprietary Pursuits XRM System, a comprehensive sales and company management system. Oprius also has a terrific to-do and appointment management system. Google’s Calendar, on the other hand, seems to have done everything all wrong, by my standards.

I’ve read about several of the web-based options and discarded them for various reasons, usually too much complexity. Remember The Milk is a notable exception in that its complexities can be easily ignored. However, its still due-date based, and that’s not the way I work.

Stephen Covey’s well-known ‘The Seven Habits of Highly Effective People’ describes a slightly over-engineered, but otherwise workable paper-based to-do system that really jives with the way I think.

I’ve tried numerous solutions and always fall back to writing stuff on a scrap of paper. I’ve been actively monitoring exactly how I really do things (instead of trying to imagine how I should do things) in the 5.5 months since getting a day-book for Christmas. I’m ready to design a to-do list. I’d probably have sat down and started coding by now if I didn’t have this blog thingy to lay out some ideas. Just a little groundwork.

Day-oriented, not due-date oriented

When I plan what I want to do, its always about what I want to do today. I don’t care that the due date of a task is in two weeks, I care only about choosing whether I am or am not working on that task today. When I’m done working on the task today, I cross it off my todo list, even if the task isn’t complete. If its not complete, I add a NEW task for the next day. Its good to break big tasks into bite-sized sub-tasks, but often I just write the same task down for each day that I work on it.

Only plan a few days in advance

I need to be able to add, reorder, and move tasks between all days, but typically I won’t have tasks listed for something more than a week in advance. Unless I’m specifically meeting someone or planning a vacation, I don’t have stuff filled out for two months from now.

Area for planned but scheduled tasks

I currently add tasks I intend to do in the future for other days and then ‘move’ them by crossing out and rewriting under another day. This is suboptimal. I want a separate section for tasks that I don’t want to forget. It needs to be easy to move them into a specific day.

Recurring Tasks Suck

Most of the tasks I do on a recurring basis don’t happen at the same date and time each week. I just know I need to do them once a week. Having them auto occur makes me easily ignore them.

Instead, I need an area (possibly same area from previous point) to store tasks that I do repeatedly. These would be generic tasks and whenever I need to put one on a specific date I can just select it and add a date.

Super minimalist

I don’t need to attach much info to a task. I don’t need priorities, descriptions, notes, durations, locations, contacts. This shit clogs up the interface and the task name itself usually helps me recall all I need to remember about this stuff. Maybe if I was a sales person with 90 contacts per day that I can’t remember their names and faces I’d need those details, but in my life, its just extra cruft.

Task Ordering

On any given day, I want the completed tasks at the bottom of the list. Uncompleted tasks are at the top in a semi-ordered fashion. Currently when I sit down at my daybook, I cross out the last item I did and pick another one based on my current priorities. Sometimes I draw numbers beside them to note the next three things I’m going to do. In software, I want to use either drag and drop or tap-to-raise to easily order the next few things I plan to do. When I finish one, I want it to be easy to change my mind about what I’m doing next. Keep it agile!

My Phone

I expect I would make this a web app in the long run so I can access it anywhere, but I definitely need to be able to access it on my phone (Android Dev Phone). Since I want to play with the android APIs anyway, my first attempt is going to be for Android. Later I’ll tie it up to a mobile-oriented webapp similar to Choncho.

Hello blog

So apparently this is my first post. Actually, I’m editing the auto-generated first post.

I’ve been meaning to set up a blog on my domain (archlinux.ca) for a while, but never got around to it, likely due to the fact that it seems pretty unimportant. Also, I am in strong agreement with a 2002 article on the topic: http://mama.indstate.edu/users/bones/WhyIHateWebLogs.html That link is bloody hard to find these days. But while searching for it, I came across this 2006 gem, which happens to explain why that link is hard to find: http://teddygross.blogspot.com/2006/06/why-i-hate-blogs.html

The truth is, the internet landscape has changed, as usual, and I haven’t, as usual. I’m still a minimalist. I don’t need this fancy wysiwyg editor, I could just upload articles to a website somewhere and update them as needed. That’s what ESR does (http://catb.org/~esr/) and it works. But my articles would never be discovered.

So when Dave Crouse, Arch Linux user and all round good guy (http://www.archlinux.us, http://www.archlinux.biz, http://www.archlinux.me, and several other domains…) offered me a blog here on archlinux.me with the only work required being ‘change your password and e-mail address’, I just did it.

Judd Vinet (http://www.zeroflux.org/) has been suggesting I set up a blog for a while too. I should listen to him, as he’s the only famous person (He created Arch Linux – http://www.archlinux.org/) I am on an exchange e-mails basis (The modern equivalent of a First Name basis, of course) with. He says a few useful tech posts can go a long way to securing contracting positions. Since I still solicit the occasional contract, I might do just that.

I still have a few issue with blogs. They’re too chronological — by design. Often people post something and then a few weeks or months later post a new entry, an ‘update’ that cites results or new information in some way. They tie these together by editing the original post and linking to the new one. To me it would make sense to have only one article and update it to ensure it has the most complete and accurate information. Current blogging platforms (they’re just a CMS, really) don’t make it easy to do that. Tagging is, I think, supposed to alleviate this problem, but I have a feeling it doesn’t meet my standards.

Another issue is dates. In today’s world, information becomes obsolete within a year. In my field, it often becomes obsolete within a month.  (This morning I was searching for information on running Adobe Flash on the Android platform. The only info I can find is from November, 2008, its useless). When I’m searching for a solution to a problem, I often ignore any search results more than a few weeks old. Therefore the FIRST thing I look for on any article, web page, or blog post is the date. But its hard to find. I actually ranted about this a few months back (so the info is stale). I’d have put it on my blog if I had one, so here’s a link: http://bbs.archlinux.org/viewtopic.php?id=63014

Next, I despise the way blog interlinking works. Its been said before (I’m in too much of a hurry to be doing other things to find a citation) that 90% of the info in the blogosphere is recycled content. Too many blog posts are “I found this solution and here’s the link.” Half the time the link is a link to somebody else who linked to the solution. Finding the information is a pain. Search engine page ranking is supposed to solve this by putting the most linked posts at the top of search results but it must fail or I wouldn’t have anything to complain about.

Finally, there was a book I read once (The Gospel according to Larry) which had a terrific quote I identified with. I can’t remember the exact wording, but the paraphrase was something like “(personally, I think if 50 thousand people are doing something that’s a good enough reason not to do it)”.  I’m very leery of bandwagon following.  I tried Facebook and the whole social network thing, but it didn’t suit me. I never tried twitter because I don’t WANT the world to know my every thought. But blogging isn’t like that anymore, its turned into a semi-interactive communication medium. It generally has more interesting, accurate, and useful information than standard broadcast mediums (news stations, sites, papers and the like). Plus, I’ve got ideas that need voicing, so lets try this.

This post indicates it also takes up a lot of time. Better be careful on that front.

BTW, if you’re wondering what topics I’ll cover here, Arch Linux and Python will be primaries, partially because that’s what I do best, but mostly because Crouse gave me a blog on the archlinux.me domain. Other topics that interest me and I feel I have enough authority to comment on include martial arts (Chinese, for the most part), web development, Hockey, dogs, Android, humour, and English grammar.

I imagine I’ll also post random useless information about random useless topics. I’ve had something on involuntary racism bouncing around in the back of my head just waiting to be authored.