My wife and I love board games. So it’s only natural that our kids will love them as well. And that’s awesome. But since all of our kids are under nine years old playing games with them can be a bit of a headache, because they don’t really have a sense of how losing one tiny little piece can ruin a sixty dollar game, and pieces are really small and easily lost.

Enter the iPad. I bought the tablet version of SmallWorld back when I had a 1st Gen iPad, and while it’s fun, at the time my wife and I only used it to pass time when we were waiting for a table at a restauraunt or whatever. Since then I have also picked up Ticket to Ride and Forbidden Island, and my kids and I spent most of this weekend playing all three games over and over and over again, as kids are wont to do.

And it was a pretty amazing experience. I still love my “real” board games, for a number of reasons: the artwork is bigger, you get a tactile sense of what you’re doing, the experience is more immersive, and you can see the board from more than two feet away, etc. etc.

But when you’re playing with a passel of excitable kiddos there’s a lot to be said for keeping the iPad firmly in my hands as they all take their turns, get excited by the (usually quite minimal) resulting animations, and go dance around the room for a while. When the game is over I just close the cover and the game is packed up, no cleanup required.

A quick note about animations: If you’re doing a straight up port of your board game don’t try to make it a full-on video game. Take a look at Ticket to Ride by Days of Wonder and stick to that level: make your graphics and chrome beautiful, but let’s keep it a board game.

The other advantage is price. Since all I’m getting is a pile o’ bytes I don’t have to pay for a bunch of die cut custom printed cardboard pieces, which usually translates into around a 75% savings or better. The companies usually have a lot of high-quality assets all ready for the games, since you can and should use the same art for the digital and analog versions, so the R&D costs are apparently low enough to make it worth doing.

Of course, in my situation this generally means I’m buying a game 1.25 times instead of 2 times, but hey, it’s still a savings.

Edward Snowden basically only verified what we had all already feared: The government is getting information about all of us behind our backs. The problem is that all this time Google has been promising that they’re doing a nice, open, transparent operation, letting us all know what they’re being asked for and what they’re actually giving, and now…well, I have a hard time believing them.

But it’s more than that. The old wisdom about eggs and numbers of baskets used to store them rings very true these days. Regardless of government requests¹, regardless of anything else, I’ve gradually become uncomfortable letting google moderate all aspects of my online life.

So I’m trying to move away from services that I’ve been using for years. And the sad fact is that the alternatives just aren’t as good as the Google offerings. There’s no getting around it. But here’s what I’m using in my attempt at going Google-free:

Firefox

Back to the fox. Firefox was once a shining star of the future of the web and now it’s kind of like Safari: At least it’s not Internet Explorer. But it has plugins like AdBlock Plus ² and Do Not Track Me, both of which make it easier to keep anybody from following me around on the internet. Again, if they want to know where I go all day every day they can just ask me (or look at my Pinboard), but I’d like them to have the decency to ask.

DuckDuckGo

DDG is a great search engine for people who don’t want to be tracked. It stores exactly nothing about you, meaning your searches aren’t tailored or customized based on your past search history. They have a great summary of why this is a good thing linked to their home page.

The downside is that, well, you’re not getting customized results, which means that sometimes you have to dig a few pages down to get the content you really want. But the results are quite good and getting better daily.

Gmail…

This is the one that’s going to be difficult. Gmail is the king of free email, bar none. To get anywhere close to the feature set that gmail provides is going to require paying for email, and if I’m going to do that I’d like to pay for really really secure email. So I’m still looking for a good replacement.

At first I was put off by the really small quotas most email providers give you. I mean, Gmail is up to 15GB free! A lot of them charge you for anything over 1GB! GASP!!

But then I looked at my actual usage. I’ve had my gmail account for around 7 years, and I’ve used about .56GB. Yep. Half a gig.³ So I’m probably okay on that front. Based on that I’m looking at a few options:

-Lavabit is an email provider who values security, security, security. For $8 a year you get 1GB of storage ⁴ and totally encrypted email. The price is good, and as I’ve said, I think I can swing a single gigabyte. - Hushmail Gives you PGP signed email…if you are sending to people who know how to open PGP encrypted email. They charge $34.99/year for 1GB of storage, but if you want to use a desktop email client via POP/IMAP you will have to go up to $49.98/year for some reason. - FastMail is owned by Opera and is somewhere between Lavabit and Hushmail: it’s $19.95/year for 1GB, no mention of encryption on the server, but fully secure communication between client and server, and no (known) agreement with the NSA.

DuckDuckGo XMPP

Apparently Google is ending support for the XMPP protocol for Gtalk, which makes it a much less useful chat system. Which is a shame, because a lot of my coworkers use it almost exclusively.

But DuckDuckGo is there for you in this arena as well. They provide an XMPP server that is much less Stalker-ish than GTalk, and also isn’t being deprecated in favor of closed protocols.

Conclusion

Google has done a good job of making themselves incredibly useful, and they make some very good apps. In the end it’s a question of how much you’re willing to give them in exchange for those services. I’d still like to believe that Google hasn’t totally abandoned their “Don’t Be Evil” mantra, but it’s still a good idea to check out the competition.

Working on Painless Vim has been an education for me, and not just about vim. I’ve been working on developing a writing/editing loop that is more sustainable than NaNoWriMo’s joyous abandon, so that I’ll actually do some editing. While I enjoy working quickly and just getting things out there in front of people, there’s a problem with that model: not only am I terrible typist, I also write some terrible first drafts.

Anne Lamott would say that’s okay; and I agree with her. But the problem is that I’m also really bad at revising. Part of my problem is that I’m a very good speed reader, which really just means that I’m good at skimming over what I consider to be fluff and finding what I consider to be the point of the text in front of me. Good for getting through things quickly, bad for finding mistakes in my own text.

So I needed a way to force myself to slow down and actually look at the words. Not surprisingly it was Brett Terpstra that clued me into this simple little “one thing well” app. With Slicereader I just paste whatever chapter I’m working on into the app, and it converts all of my Markdown into nicely formatted text¹ and only shows me one paragraph at a time. Meaning I have to actually read that paragraph all by itself. Meaning I have to view it as a single entity, without resting on what came before or after it. Meaning I end up editing every paragraph instantly and repeatedly, reloading the text and seeing how my new changes stand up.

Slicereader is almost disturbingly focused on what it sets out to do: there are no fancy options to twiddle, no settings, no font pickers. You can choose daytime or nighttime mode. But when I need some help focusing on my editing, having all those choices taken from me is definitely a good thing.

And yes, I’ve run this article through Slicereader as well.

So, I recently put a coupon up on Twitter and App.net offering ten people the opportunity to get a free copy of my book Painless Vim, which is still very much in alpha. But I figured attracting a few extra readers couldn’t do anything but help.

And in next to no time all ten free copies were gone, which is awesome. I’m not so much about the money on this one, I’m just enjoying writing it and really want to see it published and hopefully help a few people.

Anyway, it occurred to me that I hadn’t offered free copies to any of my faithful blog followers! So, here’s the deal: here’s another coupon code, also good for the first 10, nah, let’s say 20 people, but the condition is that I really would like any feedback you have about the book, even in this early state. Okay, ready? Here’s the skinny:

1. Go to https://leanpub.com/painless_vim
2. buy the book using the coupon code Blog20. ¹
3. Give me some awesome and useful feedback on the book either through the Leanpub site, as a comment on this site. Or ping me on Twitter/App.net with the hashtag #PainlessVim. However you get the feedback to me I will definitely take it into consideration and use it to improve the book.

I’m working on Painless Vim in Scrivener, because I love its organizational capabilities ¹ …or have I mentioned my love of Scrivener before? (yes)

The problem arises when I want to push my text to Leanpub. Scrivener has two very good ways to get your text out of Scriv into the world: you can export each text as a file, or you can compile it into a single document ready to send off to a printer. They’ve both got their pros and cons, but to really understand them we need a brief detour into how publishing on Leanpub works:

Brief Detour Into How Publishing on Leanpub Works

to publish your text on Leanpub you put all your chapters or whatever into individual .txt files, which you put into a special Dropbox folder called something like ~/Dropbox/name_of_book/manuscript/. then you include a file called Book.txt to tell Leanpub what order the text files should be in when the book is put together. You can also create a Sample.txt file that tells Leanpub which text files to put into a free sample that potential buyers can download, and a Preview.txt file that lets you just render a specific part of the book to make sure the formatting looks the way you want it. Okay, that’s your brief tutorial on Leanpub.

So, back to getting text out of Scrivener into this folder.

The compile option seems like a great choice at first: it creates a single text file made up of all the text in your document, formatted however you like, and once you’ve created your compile settings it’s a single click operation.

The problem is with the Sample and Preview options. Since your text is all in a single file you can’t pick and choose individual parts of the text to give away for free. You could have two separate compile settings, but that seems very labor intensive.

So, the “export” option is the way to go, right? Every text section in your Scrivener project is exported as a single text file, just like Leanpub wants, you can create Sample.txt and Preview.txt files and everything is good.

Well, one problem. Let’s say you’ve got your book laid out in Folders instead of as just a list of text files in Scrivener. When it exports your book it creates the full file structure:

Painless Vim
| 
+- Part I
|	|
|	+- Chapter 1.txt
|	+- Chapter2.txt
+- Part II
	|
	+- Chapter 3.txt	 

And so forth. You get the picture. This is a problem because Leanpub doesn’t do subfolders; you need all the files to be in the root of the manuscript/ directory. So, after doing an export from Scrivener I needed a way to flatten out the file system.

Enter Automator

Here’s the fun part. I could have written a ruby script to go through the exported file and copy all the .txt files to the manuscript folder. But that would have taken minutes. Like, dozens of them. So I decided to once again let Automator have a crack at it.

And it was easy. Automator has gotten a lot more useful since last I played with it², with things like variables and other things you’d expect from a real scripting environment. What’s more, I was able to set up my workflow as a “folder action”, watching the ~/Documents/Painless/ folder which I created specifically for this purpose. Now I just tell Scrivener to export into that directory and Automator takes it from there.

The Automator workflow I set up is dead simple:

1. Save the name of whatever just appeared in Painless in a variable called New Folder ³ .
2. Get everything in the new folder, recursively
3. Filter that list by file extension (in this case, we only want .txt files)
4. Copy all those text files to ~/Dropbox/painless_vim/manuscript/, overwriting any existing files.
5. Delete whatever is stored in incoming.

And there you have it. The last step is just to make the export from Scrivener one step shorter, because it doesn’t have to ask if you want to overwrite your last export.

There are a lot of advantages to this setup. I can now export a single text file or folder instead of the entire project, and just that file will get overwritten. For single file exports this is nearly instantaneous, opposed to the three whole seconds it takes to export my entire project. I can also have all my files, including my Book.txt, Sample.txt and Preview.txt managed in Scrivener, which I couldn’t do if I were doing the Compile option.

Over all I’m very pleased with this workflow. It’s taken one of the pain points out of writing Painless Vim.

I’m excited to announce the availability of Painless Vim, my new (indeed, still in progress) book on the ever powerful vim editor! While the book is still in progress, you can pick up a copy at Leanpub right now and make suggestions to help guide the development of this book. I’m very impressed by the Leanpub system, allowing authors to write their books out in the open and get feedback along the way.

Why Another Vim Tutorial?

I started thinking about writing this book when I realized I wasn’t the only developer who has tried to use vim and was put off by the vast majority of vim training available. Vim is really very developer friendly, but a lot of the teaching resources for vim are anything but. My goal is to take the best of what I have picked up in my journey to vim and present it in a way that helps other people get over the initial hurdle and into the good parts of the editor.

I’ll be writing quite a bit about the development process of the book and the workflow involved. Watch this space!

NOTE: I’m presenting this as a movie plot, not actual science. I’m a programmer, not a physicist. I’m fully aware that I have no idea how physics works and that everything below is probably complete nonsense. Which is why it would be perfect for Hollywood. Okay, carry on.

So, here’s the premise: Light moves at, well, light speed. The closer you get to moving at light speed, the slower subjective time moves. Which means that for light, time doesn’t move at all. Which is probably part of why it’s both photons (particles) and light waves (energy); if there’s no time there is no significant difference between the two.¹

Okay, so here’s the sci-fi movie upshot of all this, using a lot of tech wizardry that makes very little sense: A scientist discovers a way to entangle photons, so that when you send a concentrated beam of photons out the state of each emitted photon is mirrored in a trapped photon. (Remember: this is movie science, not real science) the kicker is that the state of the emitted photon is identical to the trapped photon until it hits something, which is when it starts experiencing non-light-speed time again, and is also useful because light, moving at light speed doesn’t experience subjective time at all, so the moment when it strikes something, even if that is far in the (observer’s subjective) future, is reflected in the trapped photon instantly. By reading the state of your trapped photons, you can observe events in more-or-less real time by using a really powerful computer, probably with code scrolling across its screen at all times.

Now we mix in the science magic that non-scientific people call “quantum” and we assume that you can interpolate details about the surroundings of the emitted photon from its state when it strikes something and viola! You’ve invented a way to look forward in time. By bouncing the photon off of things at various distances from the earth (reflection doesn’t cause the photon to resolve its state because shut up) you can observe future conditions at various points in the future. And thus quasi-scientific movie magic is born.

From here you can do various things with explorations of the deterministic nature of the universe, either saying that everything remains the same no matter what you try to do to change them (essentially turning light into a sci-fi version of the Oracle at Delphi) or you can have the light beams show that individual changes can alter the course of history. Or for even more fun you can throw some vaguely understood concepts about the act of observation changing that which is observed and say that us spying on the future is itself changing the future. The fact that we’re also changing that future’s past only serves to further complicate the relationship between the two events.

And then, as the final twist (or material for the sequel) you can reveal that the future is using the same light beams to spy on us.

Any major movie studios wishing to do a plot treatment can leave a comment below. I’m reasonable.

I’ve been using Tmuxinator for a while now to put together tmux sessions that I can run quickly and easily from the command line. I’ve even set up an AKA shortcut, abbreviating tmuxinator to tor, making it much easier to create new scripted sessions. But recently I discovered an odd thing when I detached from a session created by tmuxinator: they don’t show up in my list of sessions when I run tmux ls.

So I played with it a bit more. I could run tor config1 and get a session laid out according to configuration 1. I’d then detach and create a session by hand, and do the following:

$ tmux new -s bar -d
$ tmux ls
bar: 1 windows (created Thu May 9 07:35:02) [160x39]

Well that’s odd. So I’d try

tmux attach -t config1

and it would say it can’t find the session. Out of curiosity (did I kill the session instead of just detaching?) I’d run

tor config1

again, and I would be back in my already-running session.

Okay, most of you have already gotten here ahead of me. When you run Tmuxinator it’s issuing commands from ruby, not from your user session. The tmux process that ruby uses is a child process of ruby, not of your shell. This is fine if you create all your sessions from Tmuxinator, but if you start standing up impromptu sessions just because, or if you have decided to have tmux start whenever your terminal opens it means that your Tmuxinator sessions and your non-Tmuxinator sessions are on totally different servers, so you can’t use <prefix>) to switch between them.

So I decided to bite the bullet and move my Tmuxinator sessions over to independently executable scripts. It’s more steps, not quite as pretty, but the commands are all sensible, and now sessions I create using my scripts are visible on my “main” tmux server. And I’m free of one more external dependency, which is nice.

I have a Timbuk2 bag that I purchased six years ago, when I got my first MacBook. Even though I only had a 13” black plastic MacBook at the time, I got the 15” messenger bag because I figured the odds were pretty good that someday I would have a 15” MacBook Pro.

The 13” MacBook is gone, one 15” MBP has come and gone and a new one now lives in the same pocket of the same messenger bag I picked up all those years ago. That bag has been through airports, camping trips, freezing terrible outdoor IT jobs in the dead of winter and hot terrible outdoor IT jobs in the dog days of summer. Now it’s pretty much relegated to hauling my computer back and forth to and from the office because I’ve left my IT days behind me. But other than a bit of dirt the bag still looks pretty much as good as it did when I bought it. The seams are still tight and solid, the velcro still works, the material is still without any frayed or torn spots. The bag cost more than I could afford at the time¹, but I’ve never regretted the decision. I got something that was well made, and I’m grateful.

So, not a big post, or a deep important mystery of life this time around, sorry. Not even a cool new tech toy to play with. My only real point is that if you do some research and find something worth investing in² you will be rewarded for it.

While I usually work plugged into power and a monitor and all that good stuff, there are times where my MacBook Pro and I need to go off the grid for a while. During those times I’ve found that it’s easiest to have a terminal window fullscreen and do everything via the command line. That way I don’t really need a mouse at all and I can keep my hands on the keyboard doing whatever it is I’m doing that day. If I need any of my GUI apps Alfred is always right there to help me out, again, without using the trackpad.

The one ¹ problem is that when an app is full screen you can’t see your battery percentage, and it’s possible to actually run yourself out of power without really knowing how close you are. Okay, I admit that it’s a minor problem, and highly unlikely. So let’s be honest: This entire project came about simply because I wanted to add some graphics to tmux. Ever since I learned you can use Apple’s Color Emoji set in terminal windows I’ve been looking for even a semi-useful way to do so.

What inspired me was a little section at the end of Brian Hogan’s tmux book about adding battery status to your status bar at the bottom of tmux windows. He links to a script that works cross platform, but that’s not really what I wanted. As Steve Jobs once said, if you’re working cross platform, you’re not getting the most out of your specific platform². So I decided to write my own script.

doing a little bit of searching revealed this lovely command that appears to be OSX specific:

pmset -g batt

running this will give you a result like this:

Currently drawing from 'Battery Power'
  -InternalBattery-0     100%; discharging; 6:44 remaining

As you can see, this string is just begging to be pulled apart via regular expressions. So that’s exactly what I did. The first line is super easy to parse; there are only two possible strings (as near as I can tell) that go between the single quotes:

• Battery Power
• AC Power

So grabbing that string gives us a simple way to know where our energy is coming from. I didn’t want to just say “Battery” or “AC”, though, so I’m using the emoji for battery and lightning respectively³.

On the second line there are three things we want to know: how charged the battery is, if it’s charging or discharging (or charged) and how long until it’s done doing what it’s doing. I decided to represent the charge level of the battery using five stars, because that fits nicely and a 5-star system makes sense to people. I didn’t even need emoji for full or hollow stars, they’re part of UTF-8, so that was even easier. After a little thought I decided (for now) not to represent the charging/discharging/charged state specifically. I’m still capturing it, I’m just not displaying it.

So a few minutes of ruby hacking later and I have a script that gets me all the info I need and displays it using pretty pictures. Now all I need to do is get it into tmux. Fortunately that was also very simple. This line:

1

set -g status-right "#[fg=colour155]#(pmset -g batt | ~/bin/battinfo.rb) | #[fg=colour45]%d %b %R"

runs the pmset command and my script and gives me a nice green row of stars and a cyan-ish date, like so:

And like so:

It shows one star empty the moment the battery level falls below 100%, because of math, but I’m fine with that.

So: about an hour’s worth of work for something that will technically save me no time at all, ever. According to XKCD’s chart, it wasn’t worth the time, but I’m still perfectly happy with it. I’m considering updating the script to be more tmux-specific, perhaps even coloring the output based on the charging state, but for now this is good and isn’t terribly distracting.

Anyway, the battinfo.rb script is below, my .tmux.conf file is on github with all my other dot files.