Coming to Android development with a background as a web developer, I found the learning curve to be steeper than I’d expected. I didn’t start completely cold, as I had taken a brief look back when 2.2 was the newest set of APIs, but the combination of eclipse + XML scared me off that time. This time around, at least basic platform concepts such as Activities and Intents, the application lifecycle, and the standard file hierarchy weren’t totally new, but I hadn’t actually done anything beyond “Hello World”.

Project idea (non-Android tangent #1)

I’ve always found it helpful to have a project in mind when picking up a new toolset. This time around I got the idea of writing an N-back training program. The promise of N-back training protocols is more or less that they make you smarter. Figuring out how plausible that might be could quickly become its own PhD project, so after skimming the above FAQ and a few Wikipedia pages, I figured that the area was at least interesting enough to use for the purposes of learning to write an app.

As with every product idea I have ever imagined, there are already a number of N-back apps in the Play market. I identified the following non-existent combination of features to aim for:

• single N-back, which may be as effective as dual N-back, and is less of a PITA.
• ad-free. Ads can be quite distracting for this sort of task.
• an opinionated experience. The other apps tend to have a bunch of options which only make sense to someone already versed in the N-back concepts.

Some initial takeaways

• Obvious point number one: you write your apps in Java. The language mostly came back to me, after about 10 years off, but I don’t find myself any more fond of the verbosity or the minimal nature of the standard library. I know that other JVM-languages-on-Android efforts exist, but a quick survey suggested that none of them are being used widely, which scared me off.
• Getting layouts to work seems pretty fiddly compared to, say, building an HTML UI using Bootstrap, as does testing on various devices and form factors. The same could be said for web apps as well, but somehow the expectations for mobile apps feel different. For example, even if an Android app itself doesn’t need any particular artistry, a decent icon seems important. Also, with so many free apps, the bar to releasing a paid app feels pretty high.
• I didn’t initially have much luck finding open source Android apps that seemed worth investing the time to learn from. I did find a site listing open source Android apps, which I probably have not spent enough time combing through – when I gave it a look I was focusing on puzzle-type games since that seemed closest to my app idea. It has since come to my attention that at least one app I regularly use is open source, and I’ve been looking into submitting some tweaks to it.

Metalearning (non-Android tangent #2)

I happened to pick up Tim Ferriss’ Four Hour Chef early on in my Android learning process, and was intrigued by the book’s first section, which is on metalearning. Despite working in a profession that demands constant learning, reading about Tim’s learning practices made me realize that I’ve never stopped to examine, much less optimize, my own learning process in any detail.

Surprise surprise, I can see that I have room for improvement. Enthusiastically diving into topics is easy for me, but focusing my attention on the right aspect of a subject at any given time is often a challenge. This project was no exception; if anything, the breadth and complexity of the Android ecosystem encourages wheel spinning. Some questions I found myself getting stuck on:

• Which IDE to use? Eclipse is the default, but it has issues. Some people use other Java IDEs, and some barbarians use text editors.
• Which version(s) of the Android SDK to focus on? If more than one, how much effort to spend on the various APIs & their conventions?
• What display densities and screen formats to think about? Most devices in the wild are phones, but there’s huge variety in phone displays. Tablets are becoming more popular, of course.
• These things are changing pretty steadily. Are there authoritative sources for figuring out what the current wisdom is?
• What do the Play Store pages for successful apps look like?

So, did Tim’s learning tactics from FHC offer anything to help with these sorts of problems and questions? For some, yes. Example: Tim is a huge proponent of the 80/20 rule. Most of the above questions can be helpfully addressed by asking “what’s the essential 20% of this to start with?”. I’m a huge fan of YAGNI when coding, so this isn’t a big stretch; it’s mostly a matter of remembering to apply the principle in different domains.

I can see how Tim’s techniques would be helpful for natural language study, one of his main hobbies. Unfortunately, I didn’t find enough correspondences to learning a development ecosystem. For example, Tim’s strategy of reducing a subject down to key patterns would be great if I could identify those patterns, but in the Android context that task feels synonymous with “learn the Android platform”.

Another tactic from FHC that did prove helpful was “begin with the end in mind”. While it can be educational to fire up the IDE and noodle around, I found it motivating to spend some time on the Play store looking at successful projects, then sketching out how my project might appear. As with so many of these sorts of tips and tricks, it sounds obvious, but being reminded of the right obvious thing at the right time remains valuable.

20% answers to the above questions

• IDE-wise, I went with Eclipse as it is the most commonly used, and thus hopefully best supported. Thank god yet again for stack overflow, because its answers to my searches for eclipse [obscure error] have been real sanity preservers.
• As for the API, the 2.x & 4.x branches look to be the only ones worth considering. The obvious options today seem to be 1) 2.x only 2) 4.x only 3) both. While most devices are currently running 2.x, that will obviously change, so option #3 seems pretty reasonable, if you aren’t doing anything fancy. I’d guess that apps that want to really take advantage of new 4.x stuff must have hard decisions re: investment in backwards compatability.
• Screen sizes and densities, much like the API question, become clearer when you look at the data on what people are using. I got my hands on a Nexus 7 during this process, which helped motivate me to support the tablet form factor.
• The official Android docs are OK. They made more sense as I spent more time with the platform, so it’s a little hard to judge. Later on in the learning process, I picked up a copy of O’Reilly’s Programming Android, which has been so-so.

Project icon (semi-Android tangent)

The Android design guidelines have some strong opinions about what your app’s launcher icon should look like. Apparently, many developers have been successful using Inkscape to come up with decent vector icons, which can then be exported to the various required formats. Not having used Inkscape before, I invested enough time following tutorials to determine that I would probably be better served paying someone else to do this for me.

So, where’s the app?

Sitting in my copy of Eclipse. I’ve demoed the current prototype to a few people and watched them give it a try, and I do still think there’s potential. Another week or two of effort might get it polished enough to be worth putting in the store.

Just realized that the links to my blog feed from the Wordpress days weren’t being properly redirected. Unlike most of the old links, which were of the form index.php?something=another, feed readers were just asking for blog/?feed=atom.

Today’s lessons about NGINX configuration:

1. the ‘rewrite’ config statement ignores parameters, but you can target them by checking the $args variable.
2. by default, URL parameters are passed on in redirects. They can be dropped by adding a trailing ‘?’.

So, we now have:

location /blog {
  . . .
  if ($args ~ feed=atom) {
    rewrite ^ http://slagwerks.com/blog/atom.xml? permanent;
  }
}

The irony of it all is that I haven’t been writing anything on the blog, rendering the purpose of a functioning feed moot, but such is life sometimes.

New year, new VPS, new blog software. I was going to follow the path of least resistance and just get wordpress set up here, since that’s what I used to use, but somewhere in the thick of nginx+FastCGI PHP configuration I just got sick of it all.

So, for something a little different, I’m giving Octopress a try. Ruby-powered static publishing – what’s not to like?

Beware; there is a lot of enterprisey phraseology thrown around this space. In my more cynical moments I wonder if there’s a there there, or just a bunch of selling. One challenge is that it is often unclear what people mean when they use a phrase such as “Digital Asset Management”, “Enterprise Content Management”, or even good ol’ “Content Management”. Wikipedia’s ECM page seems like a good overview of what I take to be the bigger problem space.

I do tend to wonder how many of these /(asset|content) management/ problems could be solved with free accounts at tumblr or wordpress.

One minor surprise is the meagre availablity of wicked old books in this area. Does nobody want to write about this topic, or is there no market for it, or what?

If you are using the phrase “Digital Asset Management” in its more tightly defined sense, there are a plethora of existing software solutions, many of which are open source. Of the latter, most tend to be written in XML java, with some php options too. Pardon me while I stifle my enthusiasm.

Poking around did reveal one python-based option: NotreDAM. The sense of humor is appreciated in this space. It doesn’t look like the project is super established yet but it looks promising.

Disclaimer: this may be completely obvious to front end wizards, of which I am not.

I ran into an elusive AJAX gotcha the other day: whenever I hit the ‘back’ button after completing a certain task on a current project, rather than see the page I’d just been on, I got a raw JSON payload that had been requested by that page. After some trial and error I think I’ve figured out what was going on:

As I gather, when a given URL (let’s say /foo) is requested normally by the browser and then via JSON, the browser decides to remember the last version it saw, which happens to be the JSON payload. This might happen in a Rails application if you had a controller method behaving differently based on request.xhr? So when you click ‘back’, rather than your finely crafted HTML and CSS, the browser returns tag soup. Not cool. I guess I’ve never run into this before since I’ve never before had an app with the sequence of GET /foo, GET /foo (the latter asking for JSON rather than HTML).

If you’re requesting the JSON via jQuery, a solution is straightforward. Setting the cache argument to false prevents the browser from overwriting the full HTML version of the page in its history. See http://api.jquery.com/jQuery.ajax/ for more.

The Refinery CMS is apparently the most used chunk of CMS code in the rails ecosystem. Version 1.0 came out recently, and one of the recent changes involved the authentication system. Previously, Refinery had bundled authlogic; now it’s using Devise.

If you’re not doing anything worth testing on the admin side, the authlogic / Devise switch doesn’t make a difference. Still, there is one snag to overcome even in functional tests of your public code: a Refinery installation will direct all requests to a screen for creating the initial user, until said superuser is created. This applies as much to your empty test database as to a newly created Refinery site.

Public-facing URLs

An admin user needs to exist, but doesn’t have to be logged in. The default admin has roles ‘Refinery’ and ‘Superuser’, so I create such a user via factory_girl ¹:

Then within functional classes, we simply need to create that user:

def setup
  admin = Factory.create(:user)
end

Admin URLs

If you want to check admin-side code in functional tests, the admin user needs to be logged in. I had a solution under the old setup, but had to make a few changes after the move to Devise. Here’s what’s working now:

1: well, factory_girl_rails is needed for rails 3, and it includes factory_girl. The stable version of factory_girl, which has a different syntax than the master code you’d see at the factory_girl github page. Confusing!

I’ve been working with a sizable open source project hosted on subversion lately, and cringing at how long it took to just run svn status or svn diff to verify my local changes. Also not enjoying the need to do stuff like

diff -Nrc -x '.svn' -x target v1.6 local_16/ > ../local_changes.diff

Better late than never, I spent a few minutes this week getting the project mirrored on GitHub, thanks to pointers from the following two resources. I’d say it’s already paid off in time saved in just the two days since.

• http://jonathanrobson.me/2010/11/how-to-mirror-a-subversion-repository-on-github
• http://www.dmo.ca/blog/20070608113513/

True, there is a vim plugin that provides JSON syntax highlighting, but why not just use the existing javascript rules? Respect to Christopher Sexton.

Twitter followers, you may have noticed that I’ve been reading Gary Taubes’ Good Calories, Bad Calories over the last few weeks. It may be the most mind-blowing thing I’ve ever read, certainly in the last few years, if not decades. But I think I’m going to recommend reading another book instead.

GCBC is the result of five years of reasearch on Taubes’ part (he’s a science journalist by trade), and weighs in at 460 pages, plus 113 pages of footnotes. It covers the last 100 years of medical and scientific thinking on the connections between food and health, focusing particularly on what aspects of diet may lead to overweight, diabetes, and heart disease.

I despair a bit at summarizing these 460 pages of reasonably technical science history (very readable, I will add). As a teaser, I will say that one major surprise is the all but complete lack of evidence behind the low-fat diets commonly advocated. Another shocker is Taubes’ dismantling of the “calories in, calories out” equation, eg. “you lose weight if you burn more calories than you consume, and vice versa”. I’d always been a firm believer in that equation, but not any more.

While I seem to have been blessed with a genetic makeup that resists putting on extra weight (thanks mom & dad!), having my beliefs about the connections between food and health upended is still quite an experience, and it’s one that other naturally lean folks would benefit from too. If nothing else, my sympathy and understanding for people who do wrestle with the “diseases of civilization” is much greater now.

If you are a public health professional, endocrinologist, or the like, GCBC is well worth the effort, because it would be important for you to see all the gory details where your profession went wrong, and what the evidence actually says. But for everyone else, I’m guessing there’s more profit to be had by checking out Taubes’ newer, shorter book Why We Get Fat: And What to Do About It which seems to be the core of GCBC, with some of the more confusing parts explained more clearly, and more prescriptive material for what and how to actually eat.

Say you’re hosting a refinerycms site on Heroku, and would like to rewrite all admin access to use Heroku’s free piggyback SSL.

Say also that you have a few different environments, accessible via your own domain (http://mysite-dev.mydomain.com). The following in your application controller seems to do the trick: