I've been working on an Android program which uses 2D graphics over the past few days, and since it's always nice to have sample code to start from, I dug up my old Android starfield simulation.

I wrote this thing back in 2008, not that long after Android first came out, as an introduction to doing 2D graphics. I've written starfields before, first in C (and modeX) back in 1996, then in Flash's ActionScript around 2002.

I just compiled the Android version, and discovered that nothing has changed in the API since 2008 - a very good thing. I did speed up the animation a little and add more stars, since modern phones are a lot faster, and there were odd gaps in the animation.

You can find all of these versions, with source code, right over here.

Naturally, all source is copyright (c) me, and released under the Creative Commons by-nc-sa license.

Add this to your .Xresources:

URxvt.selection.pattern-0: ^(sftp://[^ ]+)

Note that there's a space at the end of the line.

I was reading an article today, a comparison of application life-cycles in Windows Phone 7 and Android, and while the article is for the most part correct, many of the statements are made in a slightly misleading manner. After a bit of pondering, I realized why this is.

Imagine that we have two children, Alice and Bob, who have a bag of 100 LEGO blocks. They're building small houses.

Logical process

Initially, Alice and Bob each take half of the blocks and build a house. A bit later, Alice decides to rebuild her house with half as many, so now she has 25 blocks in her house, and in a spare pile. No problems so far.

Bob discovers he needs a bit more blocks, so he asks mom to help him out. Mom notices that Alice has 25 spare blocks, so she puts them back into the group pool. Bob then takes another 10 blocks and finishes his house.

A Windows user's perspective

Okay, let's restart. Alice and Bob build houses of 50 blocks each, then Bob takes his apart, and rebuilds with 25. He now has 25 in his spare pile.

This is where a Windows user would say to Bob, "Hey! You aren't using those! Put them back!" Have you noticed this happen? Even though Bob wasn't using the blocks, they're still in his pool. But this isn't a problem, since so far, nobody else has asked for more blocks.

The average Windows user immediately complains when they don't have "free memory." But if you think about this, "free memory" is really just "wasted memory" because it's not in use. Why did you pay for that extra gigabyte anyway?

Android

A common "complaint" about Android, usually from users of other phones is that you can't close applications in Android. For the most part, this is correct, there's no simple way to "close" an application - but why did you want to? Unless the application is specifically written to run things in the background, once it's no longer the foreground application, it's not running. "But wait!" you say. "It's still using up memory!" Yes, yes it is - but until you need that memory, why do you care what else is using it? Android will happily shoot that other app in the head and steal its memory for you - but only if you actually need it.

But if you don't, and you want to switch back to that previous application, you don't have to restart it from the beginning, it'll just pick up where it left off. This is GOOD, it's an advantage.

I've just made a commit to webob, a Python library which "provides wrappers around the WSGI request environment, and an object to create WSGI responses" (according to the webob website).

I admit that this is based solely on wanting to return "I'm a teapot" from a Pyramid application, but it does make sense to support arbitrary HTTP response codes as well.

I've been messing with building REST APIs in Pyramid, and one thing that lacking was the ability to send HTTP error messages to the client as JSON objects. Pyramid only had support for HTML or plain text, neither of which is easy to parse when you're writing a JavaScript client.

So.... this commit to the Pyramid project ought to take care of things nicely.

Hopefully they'll accept my pull request. If not, I can always just maintain my own fork.

Today there's a new Google Reader upgrade, and (probably due to popular demand) they've included the "display density" options that they put in Gmail. I approve, obviously, since if you've read my previous post on this topic, you'll notice that this looks a lot like the stylesheet I created.

But since the size tweaks are no longer necessary, I've updated the stylesheet to just include my color and border tweaks.

You can get it here.

As you can see, the right column of this page is actually full of stuff again. I decided to just deal with the Google Plus API as is, and instead of using their image URLs, I'm just locally caching all of the images (and thumbnails) and hosting them here, rather than linking to broken links.

It works decently, I suppose. Though I noticed that Plus is weird about what it considers to be the "title" of a given post - most of these don't actually have titles, it's just guessing. So they're a little weird sometimes.

Better than nothing though.

I just discovered this. So cool!

1
2
3

import readline
import rlcompleter
readline.parse_and_bind("tab: complete")

Put that in a startup file you use with $PYTHONSTARTUP.

The problem

Google has been revamping all of their user interfaces lately. Lots of people are not happy with this, myself included. I've got a whole bunch of complaints:

• Far, far too much white, the lack of contrasts and heading/section colors makes it hard for your eye to pick out logical divisions
• Lack of easy-to-see separators, which does the same thing
• In the case of Google Reader, WAY too much use of whitespace
• Scrollbars (in Chrome at least) are way too skinny, which makes those of us who don't use a scroll wheel (that's a separate rant) have trouble grabbing the scrollbar and moving it.
• In Gmail, the use of transparency on buttons makes them very hard to see when one uses one of their "HD Themes" which has an image in the background
• In Docs, the menu bar is no longer clearly a menu bar. I'm not sure why there's this trend of screwing with menu bars lately (I'm lookin' at you, Microsoft), but the Common User Access guidelines are a GOOD thing.
• Various UI elements don't show up until you mouse-over them, or do some other action. I understand why they're doing that, but it makes things a bit awkward when you want to say, delete an email, but don't realize that you have to select it before the delete button shows up.

The fix

I've started making some custom stylesheets for all of the Google tools I use. So far, I have the following:

• Google Mail
• Google Reader
• Google Docs

You'll need a tool that lets you apply user stylesheets to sites, such as Stylish for Firefox or Stylish for Chrome.

If you do a better job than me, let me know. Thanks to Rachyl for some of the styles.

So now there's a Google Plus API for Python. You will notice I've added +1 buttons.

However, the sidebar on the right is gone for the moment, because there's a rather major bug in either the Plus API, or the image resizer Google use for the thumbnail images. So right now I can't actually pull thumbnails from Plus, I'd have to pull them down myself.

I'm pondering that, sure, but it seems the wrong way to do it.

Anyway, here's the bug I've submitted to the Plus bug tracker. I suspect that'll languish there for a year or so in the 'new' state, and by that time, I'll have stopped caring.

You know, like most of the Android bugs I've cared about.