(Updated March 23, 2014)

An annual exercise challenge rolled around again at my workplace, so naturally I found a project in it: Wondering if I could hook Runkeeper up to my Day One journal. The result: The Runkeeper plugin for Slogger

Getting up and running with the Runkeeper API was tricky; I never quite got the hang of passing parameters to it, which still puzzles me. When I figured it out, I put together a quick walkthrough for the API startup and posted it as a gist (Also embedded at the bottom of the post). The gist provides some instructions, but users new to Slogger plugins and working with API authentication may also want to check out Sven’s writeup that uses this method and includes a couple of additional screenshots.¹

{:id: .center}

One note about configuring your Runkeeper application: The Runkeeper folks don’t want to appear to endorse any applications or have them potentially be confused for official Runkeeper services, so avoid identifying your app with anything that uses “Runkeeper” or “Health Graph” in its name or description to save yourself from receiving a polite email requesting you to make a change.

I built the Runkeeper plugin for Slogger with a fun option to save its data additionally to a text file. I plan to do some stats or plots or something with that data, perhaps akin to my fitbit visualization, one of these days.

Enjoy!

The future is extremely hard to see through the lens of the present. It’s very easy to unconsciously dismiss the first versions of something as frivolous or useless. Or as stupid ideas.

Eighties bombast soundtrack reclaimed as moody southwest indie rock. I love Calexico, and this is fun.

Fun and interesting conversation on Generational about blog platforms and static blog systems. Discusses hosts, editing and practically solving some of the “how-do-I” problems writers may face.

I know I’m going on and on, but I’m enthused. I use Slogger to save entries from twitter, last.fm, app.net and fitbit activity to Day One. Just as with the build tool for my blog here, mover.io helps remove the laptop from the workflow. See, I don’t have have a dedicated old machine to run as a server for my Mac stuff, so the standard method of running slogger via a daily scheduled task doesn’t work so well for me. I set a reminder.

The #NowPlaying pane gets to the heart of what’s really wrong with the app and, may I suggest, Twitter circa 2013. In order for this 25% of the app to be useful, the people I trust and follow must also auto-tweet what they’re listening to, complete with hashtag detritus (or trolls). Perhaps I’m just too far past what Twitter considers cool, but a stream littered with #NowPlaying refuse (or Vines or Foursqure check-ins, for that matter) is a sign that I need to spend some quality time with the unfollow button. Twitter has built an app that requires users to abuse their timelines and followers with machine tags without any meaningful way of tuning out that noise.

I use Rdio and I think they’ve got social done pretty well — it’s external to existing social networks but easily connects to them, so I can choose to engage with it when I want and otherwise keep it out of the way. (So it’s interesting/odd that Rdio now also hooks to Twitter Music.)

It was a lot of fun to port my static blog workflow to a server-based build tool that relies on the mover.io API. Since then I’ve been tinkering with more general-purpose tools to play with mover. As an exercise, I put together a ruby-based widget I could use at the command line to simply finding and getting things from a connector attached to my mover.io account.

The gist is embedded below. This is intended for command line use; the script I’ve integrated with my blog build tool uses many of these mechanics but does a bit more work to diff the remote (Dropbox) directory with the local one and then cycle through downloads of the new files to my server, where the builder can do its business and publish to my dev and then public web locations. I’ll post the rest of that as soon as the code is a little bit less embarrassing.

The possibilities posed by this kind of integration are really cool, and I’ve had lots of fun developing this capability so far.

MG Siegler Recommends 30-minutes:

30-minute meetings are so much sweeter. As long as you make the length clear at the beginning of the meeting, I find that everyone (again, myself included) gets right to the point and cuts out a lot of the filler and padding that makes up a ridiculous amount of every conversation.

I know that may sound a bit crass. But pay attention to the next conversation you have — how much of it is filled with things that really don’t need to be said? A lot.

My workplace is a pretty meeting-heavy one, too, and also very social, but I’ve gotten better at getting through meetings without using the calendar-application-default of an hour. Shared expectations are key, and so is an agenda, so that all participants can see exactly when the conversation is done.

Time was, I took a lot of photos. I spent a lot of time in Lightroom working them up, tuning them, cataloguing them. I found great delight in learning more, improving my technique and exploring my creativity. There was nerdery, too, like an annual year in Lightroom stats blog post that was lots of fun. Along the way I made myself a collection of handsome prime lenses and used them almost exclusively. (At the time, nobody had a cool set of pancake primes like Pentax; to date, some of my favorite photos are with the little 21mm.)

As my son got older, the amount of time I could spend working up shots in LR started to approach zero, and I used the big DSLR less and less often, replacing it with snaps from my phone – photos that I could tweak, upload and share without the multi-step process of transferring and working up on the laptop. This trend intensified until recently, when our now-toddler got a little more independent and a little more routine. So I find myself getting that itch, to spend a little more time with my photography again – and with equipment that may still lighten the post-processing load.

With a fast-moving toddler, I also want something that autofocuses quickly and performs well with relatively low light, and on this score both the workhorse Pentax and the iPhone tend to fall short. Again, post-processing can make a lot of difference – Lightroom 4’s noise reduction in particular is fantastic – but it adds to the mental overhead of just using the photos that I made.

I’m not sure where to start looking for this fun new camera. I’m pretty sure the big DSLR isn’t my bag anymore, as much as I don’t want to leave behind this nice stack of glass. So where does one start these days? Mirrorless 4/3 cameras are intriguing (e.g. Shawn Blanc’s review of the E-PL5); for the price, both the E-PL5 and NEX-6 look pretty hot, though there’s something about a really good non-interchangeable lense that I find appealing: No race to accumulate different focal lengths, just a single frame to get really tight with.

And now that I start to read around a little, I see things like Zack Arias’ review of the Fuji X100s. My, but that’s a pretty beast.

At the less flushed-cheeks end of things, but still attractive, are high-quality zooms like the Fuji X20 or Pentax MX1 (I do admit I still have a Pentax soft spot; my very first digital camera was an EI-200, and my second was a Fuji F10, so I feel like I could be keeping it in the family either way). For a grundle less cash something like these might fit the sweet spot for toddler-tracking, portability, and image quality that could feed my latent creativity.

{:id: .center}

I do have the benefit of not really being in a hurry — mostly; my boy does keep growing and doing more wonderful things most days — while the options just keep getting better.

So I built this little hobby blog engine and had a good time with it, but one of its limitations as a writing tool was that it required me to sit down with the laptop to actually publish: Although the whole thing lives in a Dropbox folder, I needed my trusty MacBook Pro to run the Ruby to build and then deploy the site to my web server. I could write at the coffee shop on my iPad or iPhone with my favorite Dropbox-compatible tools (like iA Writer), but couldn’t publish directly from iOS.

Until now. A couple of weeks ago I tested out the Ruby engine itself on my server at TextDrive and found that it worked with just a couple of small modifications. But my content still lived in Dropbox. How would I bridge the Dropbox-server divide?

Enter mover.io, my new favorite technology crush. Its API lets me download from Dropbox directly to my server. I repeat, it’s awesome. So here’s the toolchain: Write in iOS, hop into Prompt to run the deploy script on the server, and boom, published blog goodness.

I started and finished this very post, zapped it to my server and ran the build, checked its rendering and then deployed to production – sounds fancy, right? – all from my iPhone. It’s pretty much the new hotness for me.

I’ll write up some of the technical details later. This was lots of fun to learn, and I have more cool ideas for putting mover.io to use.