My New Macbook Air

On Friday, I got myself a brand new Macbook Air, the fruit of my labor from writing over the last several months. I got the 13″ model, essentially the mid-range, which is fine for what I need. I’ve only had it about a day, but I love it. Two things I especially like are its light weight and its backlit keyboard.

Tomorrow, I head to L.A. for work, and I have a lot of work to do on the plane, some related to the day-job and some related to writing. So tomorrow I will get to test out the 12 hour battery life of this thing and see how well it really holds up.

Getting the laptop was setup was relatively trivial, thanks in part to a playbook I have for what to install on new computers, and in what order so that I can be efficient about it. Then, too, since most of my documents are in the cloud, there was no need to copy back and forth a lot of stuff.

At this point, everything is synced up nicely. All of my Git projects have been pulled over, all of my TextExpander snippets, and my Keyboard Maestro macros, so it is like working at my desktop computer. Except on a small screen. And I can take it with me wherever I go.

How I Use Google Docs for Writing

Since February 2013, I’ve used Google Docs for my writing. I’ve always been a fan of Scrivener, and I still use Scrivener to prepare submission drafts. But for a year and a half now, I use Google Docs exclusively for first, second, and final drafts. I was asked on Twitter recently if I had a post explaining how I used Google Docs for my writing. With nearly 6,000 posts, I’ve written on almost everything, but strangely, I did not have a post on how I use Google Docs for my writing. Now I do.

Why Google Docs?

Because I’m sure someone will ask why I use Google Docs, let me get that out of the way first. There are three main reasons.

1. Simplicity

Google Docs is simple. Unlike Microsoft Word, it doesn’t have every feature under the sun. But it has enough for me to easily produce clean copy in standard manuscript format, and that is really all that I require. Too many features weigh an application down, and provide distractions. Google Docs minimizes those things.

2. Accessibility

I work in all kinds of environments. In my home office, I have an iMac. In my work office, I have a Windows laptop. I have Google Chromebook as well. Sometimes, I write on other machines. Google Docs is available to me on all of these platforms. The same feature set, the same version, the same look-and-feel. This is important because it saves me time in having to learn specific ins-and-outs for different platforms.

Google Docs is also always available. Everything is stored in the cloud, and sycned to my computers. On those rare instances when I am offline–say, on a plane without Internet access–I can still access my documents offline.

3. Automation

I never have to remember to save. Google Docs saves as a I type. This has saved me on a couple of occasions when the power has gone out.

Moreover, Google Docs can be customized using Google App Scripting, essentially JavaScripting objects that allow you access to the Docs object model. I’ve created several tools through this automation that have allowed me to automate routine writing processes. That in turn allows me to spend more time writing.

Google Docs isn’t perfect. I’ve written before about what I consider to be the important elements of a word processor for writers. Google Docs has some of those elements, but not all of them. That said, I just like it. It fits me well.

Ingredients

To understand how I use Google Docs for writing, you have to first understand that I have built a small infrastructure within Google Drive to support my writing. The goal of this is to automate everything I can, so that the vast majority of my time is spent writing. I’ve been pretty successful with this. Here are the components to my Google Drive writing infrastructure.

1. My writing template

I have created a writing template that I use in Google Docs. This template contains some automated functions I’ve created. It is the jumping-off point for any new story or article. I have it bookmarked on my Chrome bookmark bar for easy access. Here is an annotated look at my Google Writing Template.

Google Docs Template
Click to enlarge

My “Project” menu allows me to quickly create new blank documents. It has other functions that automate processes for me, like preparing a document for Scrivener (where I do the submission manuscript).

My scripts automatically capture the start date and end date of a draft, as well as the type (fiction or nonfiction). This data gets fed into my Google Docs Writing Tracker.

My template has a deleted scenes section. While I am a strong proponent of cutting scenes and other stuff from my stories, I never throw anything away. In addition to being useful later, seeing what I cut helps me learn and improve.

Continue reading

For #TBT: The Grave of the Unknown Warrior, Westminster Abbey, July 2007

West entrance to Westminster Abbey
West entrance to Westminster Abbey, July 2007
Back in July 2007, I visited London for a week, after spending the two previous weeks in Italy, Greece, Turkey and Croatia. It was my first trip to London, and I loved the city. One of the more moving events of that trip was my visit to Westminster Abbey, where I stood among the graves of people like Isaac Newton, Charles Darwin, and Henry V (“Harry the King” from Shakespeare’s play.)

Upon leaving the Abbey, I came across the Grave of the Unknown Warrior. Having just finished the section on World War I in Manchester’s biography of Winston Churchill, I feel compelled to repeat it here:

Beneath this stone rest the body
Of a British warrior
Unknown by name or rank
Brought from France to lie among
The most illustrious of the land
And buried here on Armistice Day
11 Nov. 1920, in the presence of
His Majesty King George V
His ministers of state
The chiefs of his forces
And a vast concourse of the nation
Thus are commemorated the many
Multitudes who during the Great
War of 1914-1918 gave the most that
Man can give life itself
For God
For King and country
For loved ones home and Empire
For the sacred cause of justice and
The freedom of the world
They buried him among the kings
Because he
Had done good toward God and
Toward
His house

The Wiggly Tooth

The Little Man had some exciting news for us this morning when we woke up. He came into our room, unusually bright-eyed, and said, “You know what? I have  a wiggly tooth!”

So he does. And that marks a new milestone: the Little Man’s first loose tooth. It’s his lower left-center tooth, what a dentist would call, I think, 24d, or a central incisor. I have some vague memories of my first loose tooth, at roughly the same age as the Little Man, and I seem to recall being slightly terrified of the whole matter. Not the Little Man. He was eagerly enthusiastic, and it was catching. The Little Miss started checking her own teeth, on the off chance that she, too, might have a wiggly tooth.

In my Going Paperless posts, I’ve written about how one of the ways I use Evernote is to keep track of our kids’ milestones. I sometimes get questions about what those milestones might be, or what they look like in Evernote. Well, this is a good example of one of them, and here is what it looks like in Evernote (filed in my Timeline notebook and tagged with the Little Man’s name, and “milestone”):

Little Man Loose Tooth

Please Listen Carefully as the Menu Options Have Changed

Just a heads-up to let folks know that I’ve updated the menu bar for the site, and some of the options may be different/unfamiliar.

New Menus

The main changes are:

  • Consolidated the About/Contact menus. My Contact menu can now be found as a sub-menu on About/Contact.
  • Added a link to my Site Policies from the About/Contact menu.
  • Added the Open Analytics menu option, which takes you to open.jamierubin.net, my experimental site for publishing my real-time quantified self data. Right now, it’s just got my writing data.
  • Added the Software menu option, which takes you to my GitHub page, which is the authoritative source for all of the software I make.

There may be a few more tweaks here and there over the next few days, but this is the bulk of it.

Going Paperless: How I Use Playbooks with Evernote

My recent simplification of my notebooks and tags in Evernote provided me with a good opportunity to start using playbooks with Evernote, something I’ve been wanting to do for a while.

For those who aren’t familiar with them, playbooks are a set of notes that document a repeatable process. My general philosophy is that if I have to do something more than once, I try to automate it. Sometimes that isn’t possible, either due to technical limitations or time constraints. In those cases, I create a playbook that lists out the steps of the process so that it is easily repeatable for anyone tasked with doing it. Playbooks have several advantages for me:

  • They make it easy to recreate my steps for something, especially if it is something that I don’t do very often.
  • They make it easier to delegate tasks because I can simply shared the playbook with whoever needs it.
  • They provide a roadmap of possible future automation.

Format of my playbooks

I’ve just recently started creating playbooks in Evernote, and I’m trying to keep things simple with respect to their format. My number one rule is that they should be as clear as possible. To that end, I use a simple, clear title prefaced by the words PLAYBOOk to make it clear what it is. Here are some examples titles of playbooks I’ve created:

  • PLAYBOOK: Making a commit to GitHub
  • PLAYBOOK: Scheduling a Going Paperless post
  • PLAYBOOK: Transferring meeting reservations from one person to another

As far as the content goes, I keep that simple, too. There are 2 sections to each playbook:

  1. Use case(s): a list of the conditions under which the playbook would be useful.
  2. Steps to follow.

I try to make the steps as clear as possible, writing them with the thought that someone other than me will be trying to follow them. Where appropriate, I’ll include images, screen captures, etc. Here’s one for transferring meeting reservations:

Playbook

Organizing my playbooks

I don’t have a whole lot of playbooks in Evernote…yet. But I could imagine this growing pretty quickly. Since I’ve just gone through a simplification of all of my notebooks and tags, I’ve been very cautious about how I organize my playbooks.

One possibility would be to create a notebook for them. But really, that isn’t necessary. In my new notebook organization, I can simply file them in the appropriate existing notebook. I might add a new tag called “playbook” but so far I haven’t. There isn’t a need. I can find them easily enough. The reason is that my note title follows a very specific pattern:

PLAYBOOK: Process to repeat

A simple search like this:

intitle:PLAYBOOK

finds all of my playbooks no matter what notebook they are in, and no matter how they are tagged. Because of that, I have no need to add new notebooks or tags to accommodate my playbooks. Instead, I just created a saved search called “Playbooks” that uses the search criteria above.

Continue reading

Today’s Site Outage: My After-Action Report

Sometime around 4 pm today, this site had an outage. From what I can tell from my Google Analytics data, the outage started around 4 pm EDT and lasted for a little over an hour. I called the host to report the problem, and also pinged them on Twitter. It turned out to be an known issue, by 5:15, the site was up and running again.

Let me apologize for the outage. I get annoyed when I go to a site and it spins and spins and eventually spits out an error, and I imagine I’m not the only one who feels this way.

A brief review of outages on this site

The previous outage I had on the site was back on April 24, not that long ago, relatively speaking. That outage didn’t last as long as this one, somewhere around 25 minutes.

Prior to that, the last outage I had was on September 10, 2012, back when the host fell under a DDoS attack.  That one lasted 4 hours.

A total of 6 hours downtown over a span of more than three years is a pretty good track record, over all, well above the 99.9% uptime commitment my hosting service. This is far better than what I had with my previous hosting service, and makes me glad that I made the switch. Problems have been very few and far between.

A pet-peeve about how host support handles these issues

The one complaint I have about today’s outage is an IT pet-peeve I have in general. Keep in mind, that I’ve worked in IT in a variety of capacities for more than 20 years now. For the first 10 or so, I was intimately involved with running a service desk, so I know a little about how these things work.

When I called to report the problem, I had already done my homework. Mostly, I verified that while I could not get to my sites (503 errors), I could get to the server that hosts the files. This tells me that the issue is with the web server. I pointed this out right away to the very pleasant support person I spoke to.

But these folks have to follow a support tree. I hate support trees because they virtually eliminate any possibility of creative thinking on the part of the support person, and they end up wasting a lot of unnecessary time.

For instance, today, I pointed out that I could access the file server but not the web server, which told me that there was an issues with the web server. The support person told me that there were no known issues with the web server at this time: that’s the first problem with a support tree.

It’s quite possible that there were no known issues and that I, acting as a canary,  was the first to report the problem. Rather than running down a rabbit hole of steps that are almost certainly unrelated to what is wrong, it would have been prudent at this point to check the web server. Instead, I was asked when the site was last working, I had this information from Google Analytics. The next question was when the site was last changed. It had days. One look the modified dates on the files in my directory would have told the support person this. But it was irrelevant because when unchanged files that accessible through one protocol but not another, the likely culprit is the other protocol.

Next, I was asked to perform the rather ridiculous task of renaming my .htaccess files in case someone the permissions got messed up. Mind you, the modified dates on these files were from months and years ago. Again, no changes. This is what I call a “customer comfort” task. I feel like I’m doing something useful. But it was a complete and utter waste because it was completely unrelated to the problem.

Eventually, lots of people started reporting the problem on Twitter, and not long after that, the site was up and running again. It was the web server, no doubt, just as I had figured. It might have saved a lot of customers some negative moments of truth, if only the support staff weren’t chained to those useless support trees.

Writing Stats for July 2014

Is July already over? I ended July with almost exactly 27,000 words written, not as good as June, but altogether respectable. It also brings my total word count for the year-to-day to 190,000 words, not counting blogging.

With more nonfiction freelance work, I modified my Google Doc Writing Tracker to split my daily word counts into fiction and nonfiction. I didn’t start this until very late in July, so I don’t have a lot of useful data. But next month, I should be able to report on the actual breakdown. I’ve also automated capturing the time I spent doing my writing, taking advantage of the RescueTime API for that. Again, I didn’t start capturing this until late in July so August’s data should be much more interesting.

Normally, I’d post a chart showing my writing for the month, but thanks to the work I’ve done on my experimental analytics site, open.jamierubin.net, you can see live data of my writing for the month of July by heading over there. You can also see my writing since the beginning of the year. The site is growing increasingly interactive, and there should be some improvements to the look and feel in the coming weeks, but for now, I’m just glad I’ve automated the data reporting. It means I have more time to spent on the actual writing.

During July, I had two items published:

  1. The FitBit for Your Car,” The Daily Beast (July 8)
  2. Self-Tracking for N00Bz,” The Daily Beast (July 24)

I expect to see at least three things published in August, and of course, I’ll let you know when they are available.

Heading to Los Angeles Later this Month

Well, Santa Monica, actually. And it is a whirlwind trip. I’m flying out for work on Sunday, August 10, and then taking the 6 am flight back home on Wednesday morning, August 13. It’s my first work-related trip to L.A. since 2011. I used to go much more frequently, but I burned out on that kind of travel. A 5 hour flight across the country seems twice as long.

But, I always try to look for the silver lining. I’m attempting to finish up the first volume of Manchester’s biography of Winston Churchill before the flight, so that I can spend my 10 hours in the air making my way into the second volume of the biography.

As for my schedule in L.A., the roughly 48-hours that I’ll be in town are already booked solid, mostly with work-related stuff. On Sunday evening, at least, I’m having dinner with friends from high school that I don’t get to see very often.

I have a ton of day-job work leading up to the trip, and so my days of high productivity pulses courtesy of RescueTime will probably continue for a while. I’m guessing they will continue through mid-September. We’ll see.

Introducing open.jamierubin.net

With all of the data I collect about myself, I’ve been wanting to put together a kind of open dashboard that provides a window into the data through interesting visualizations. While my short term plans are nothing like the amazing things happening over at Aprilzero, I have put a very early prototype together of what I am calling open.jamierubin.net.

open.jamierubin.net

Right now, all the site does is make a live query to my Google Doc Writing Tracker spreadsheet, and renders the data in a chart on the site. Clicking on the links above the chart, you can see either the last 30 days of my writing data plotted out, or go back to the beginning of time (over 500 days).

For each visualization I publish, I plan to include a link to the “HOWTO” which will include the code I used and how I pulled the data I needed to make the visualization. That way, if others want to give it a try, there will be at least some documentation.

Eventually, I will come up with a framework for the site, and begin pulling in other data as well. For now, this is a quick-and-dirty prototype of what is possible with just a little bit of code. Take a peek at it and let me know what you think.

Open Beta of My Google Docs Writing Tracker Version 2

I have done a major refactoring of my Google Doc Writing Tracker. Several new features have been added, but the biggest change is that the scripts are not data-driven, making them much easier to setup and configure. If you are using the scripts today, or have been wanting to try them out, you are welcome to install the new beta version.

You can get the files from the beta-version-2 branch on GitHub.

Be sure to read the README as that has been updated to reflect the changes in the system.

New features

  • NEW: A new spreadsheet is available with all of the configuration information built into it. You just fill in the blanks on the Config tab, and the script takes care of the rest. This makes it easier to configure and customize without the need to go into the code.
  • NEW: Option to break down daily word counts into fiction/nonfiction.
  • NEW: Ability to run the scripts in test mode. Allows you to see the results of your configuration in the log without the changes being applied to your spreadsheet.
  • NEW: Ability to customize the order of the columns on the Writing tab.
  • NEW: Ability to customize the names of the tabs in the spreadsheet.
  • NEW: Ability to customize the location and names of the Sandbox and Snapshot (formerly “Earlier”) folders.
  • NEW: Ability to capture time spent writing by integrating with the RescueTime API (experimental).
  • NEW: Ability to generate Daily Almanac summary email that lists stats for the day, and identifies trends and records.
  • NEW: Improved logging in test mode.
  • NEW: Validation of configuration settings.

What I hope to accomplish with the beta

So far, these changes are working very well for me. But I can only really test in my own environment, and because I initially wrote the scripts for me, they may be inadvertently tailored to my environment. In this version, I’ve tried to generalize a lot of the code and make it more flexible and easier to use in other environments.

What I am looking for in this beta is to have people test the scripts in many environments in order to identify any problems, and iron them out before merging this code back into the master branch.

To that end, if you use the scripts I ask that you do 2 things:

  1. Log an issue if you find a problem. Understand that I don’t have a lot of time to work on these scripts. I set aside a chunk of time once a year or so to do a major refactoring like this, but that’s about all I can do. So while I will try to address all of the issues, it may take a while.
  2. If you see a way in which the documentation can be clarified, by all means let me know.

If I do have time, I will try to address the issues as quickly as I can, but that time isn’t guaranteed, and as I say in the README, while I’m making these scripts available to anyone who wants to use them, I don’t have time to support them. You use them at your own risk, so be sure to read the README.

The initial setup can be a little cumbersome and I’ve tried to clarify it in the documentation. Once it is setup, if all goes well, it should just run silently in the background and add to your spreadsheet each day.

If you use the scripts, let me know how they work for you. They work great for me, but of course, they were designed for me and my environment. With this revision, I’m hoping that they work equally well for anyone who chooses to use them.

Going Paperless: How I Simplified My Tag Organization in Evernote (Part 2)

Last time, I talked about how and why I simplified my notebook organization in Evernote. Today, I’ll discuss how I’ve simplified my tag organization. Both are still works in progress, but the tags more so than the notebooks.

To start, let me say that I’ve never been much of a tagger. There are several reasons for this:

  1. Evernote has a powerful search engine that usually allows me to find whatever I’m looking for in just a few seconds.
  2. With such a good search engine, adding tags is usually counterproductive for me, since it takes time to add them to a note, but I can find the note just as easily without them.
  3. Tags have a tendency to grow like weeds. I’d end up with a huge number, and when I look at them, I find that more than half my tags have less than 10 notes associated with them.
  4. With lots of tags, there is a tendency to forget how I’ve tagged something. In some places, it gets tagged “project” in others “projects.” This actually make searching by tags worse. If I search for everything tagged “projects” I don’t get the notes tagged “project” for instance.

That said, I do find value in tagging notes under certain circumstances. Regular readers will recall this diagram:

Evernote Search

I find tags very hand for describing the “who” part of a note. I assign family member names as tags to notes to denote who that note is related to. Tags can sometimes be helpful with the “what” as well, but in all cases, a solid taxonomy is important for preventing uncontrolled tag growth. I’ll talk about that in a moment. First, let me show you what my tags used to look like.

Continue reading