November 2014

Weekly review: Week ending October 31, 2014

November 1, 2014 - Categories: review, weekly

I signed a new consulting contract, so there’s going to be web development and social business consulting (analytics, etc.) in my near future. I’m planning to work fewer hours, though, so that should free up more time for writing, cooking, and other forms of improvement. =)

Along those lines, I’ve been investing time into improving my development tools and workflow. Yay Emacs! I think I’m getting the hang of working with skewer-mode now. expand-region is probably next on my list of things to get used to.

Next week, I’m looking forward to tweaking my workflow further, and sketching out some plans for the kind of functionality that might be good to build over the next year. We have a developer ramping up, so if I spend more time on the design phase for both prototypes and reporting, that should help her get going faster. I’m also looking forward to experimenting with Emacs hangouts and spending some time working on Quantified Awesome.

In other news, it snowed today in Toronto. Very light snow and still bike-able, but officially snow. And I also finished my first pass reading The Art of Slow Writing – plenty of notes to take from this book, I think. Onwards!

Blog posts

Sketches

Link round-up

Focus areas and time review

  • Business (57.0h – 33%)
    • Earn (33.8h – 59% of Business)
      • E1: Update analytics
      • E1: Wrap up neatly
      • E1: Brainstorm prototypes I want to propose
      • Earn: E1: 2.5-3.5 days of consulting
    • Build (19.3h – 33% of Business)
      • Drawing (0.0h)
      • Delegation (0.0h)
        • Plan business and delegation for this phase
      • Packaging (0.0h)
      • Paperwork (0.0h)
        • Hire accountant and assemble information
        • Send trial balance and general ledger to accountant
        • Sort out invoice/deposit thing
    • Connect (3.8h – 6% of Business)
      • Attend QS meetup
      • Prepare for Hacklab open house
      • Coach Lucas on programming
      • Organize Emacs Hangout
      • Process Quantified Self videos
  • Relationships (2.4h – 1%)
  • Discretionary – Productive (10.5h – 6%)
    • Emacs (7.4h – 4% of all)
      • Emacs: Evaluating Javascript and CSS in Chrome using Skewer Mode
      • Emacs: Limiting Magit status to a directory
      • How we keep (financial) score
      • Publishing WordPress thumbnail images using Emacs and Org2Blog
    • Quantified Awesome
      • Fix forms and bootstrap 3
      • Fix token authentication
      • I can add an item
      • I can organize items by aisle/category
      • Items have a price history
      • Start working on kitchen organizer
      • Update to Bootstrap 3
      • Upgrade Rails 3 to Rails 4
      • We can cross items off
      • Update to Rails 4.1
    • Bike to work
    • Get passport pictures
    • Draw a cat
    • Pick up exercise ladder again for three straight days
    • Writing (2.7h)
      • Organize a journal section in my notes
  • Discretionary – Play (6.6h – 3%)
  • Personal routines (21.7h – 12%)
  • Unpaid work (12.4h – 7%)
  • Sleep (57.4h – 34% – average of 8.2 per day)

Monthly review: October 2014

November 3, 2014 - Categories: monthly, review

I wrote last month that in October, I was planning to:

  • Help with the last big milestone for my consulting client
  • Turn over all of my responsibilities and document things I’ve learned
  • Cook at the new Hacklab and explore more recipes at home
  • Do my corporate books: this year, I added dividends and HST quick method!

Big milestone successfully passed, hooray! There are still a few minor hiccups that the team’s working through, but that’s normal. In other news, I signed a new contract, and we have a new team member too. That means I don’t actually have to disappear abruptly, and I can gradually document and transfer what I know.

I’ve been having a lot of fun cooking at the new Hacklab. We invested a lot in kitting out the new kitchen, and that’s really paid off. It’s more comfortable cooking with all those tools and all that counter space. Whee! You can check out our notes in the public wiki.

I’m waiting to hear back from the bookkeeper I hired through oDesk before submitting my corporate tax return and my HST return this year, but even if I have to do it on my own, I feel reasonably confident about my numbers.

In November, I plan to:

  • Get team members up to speed with prototype designs and reporting tips
  • Experiment with Emacs hangouts and learn more about functionality
  • File my corporate tax returns
  • Dust off my delegation processes

Blog posts:

  • Business
  • Tech
  • Learning
  • Blogging
  • Cooking
  • Life
  • Reviews
  • Sketches:

    1. 2014.10.06 Sometimes – often – I don’t feel like making conversation
    2. 2014.10.11 Considering winter coats
    3. 2014.10.21 Exploring my current motives
    4. 2014.10.21 Reflecting on my primary motives
    5. 2014.10.22 On Hell Yeah and other approaches
    6. 2014.10.22 People who follow similar motivations well
    7. 2014.10.22 What kinds of activities do I want to fully enjoy
    8. 2014.10.22 What would I like to be able to do with sustained motivation
    9. 2014.10.31 How do I want to become a better developer
    10. 2014.10.31 What do I want from this phase of my experiment
    11. 2014.10.31 What do I want the rhythm to feel like

    Emacs, coaching, and unknowns: Figuring out what I want to learn

    November 4, 2014 - Categories: emacs

    I’ve been playing around with the idea of hiring an Emacs coach, since Steve Purcell, Christopher Wellons, and Bastien Guerry all offer this service. It helps to go in with a clear idea of what I want to learn, though, so let me figure this stuff out.

    Here are some general topics, sketching out an order for learning the subtopics:

    • Thinking syntactically, so that I can work faster and more reliably
      1. Expand-region: Faster selection.
      2. Smartparens: Logical manipulation. This is probably the biggest chunk.
      3. Erefactor, redshank: Other tools for working with Lisp.
      4. Magit: Thinking of changes in terms of commits; low priority because I rarely need to coordinate with others, although I can bump this up if working on community code
      5. In general, working with larger chunks – so also projectile and other cool tools
    • Web development workflow, so I can work more professionally and handle more complexity. Focusing on Rails, NodeJS, and AngularJS
      • Rails workflow
        1. Testing
        2. Constant testing with guard, better interaction with browsers, etc.
        3. Navigating between files in a project with Rinari or Projectile
        4. Code navigation and documentation lookup with Robe
        5. Working with things like HAML, Sass/Less, CoffeeScript
        6. Refactoring Ruby code
      • Javascript workflow
        1. Testing frameworks, running tests
        2. Getting autocomplete sorted out
        3. Integrating Skewer into the way I work
        4. Working with things like HAML, Sass/Less, CoffeeScript
        5. Rapid prototyping: Grunt, Yeoman, etc.
      • General-purpose tools
        1. Folding/overview, imenu?
        2. Jumping to specific points quickly – ace-window, ace-jump, helm-swoop
    • Integration, so that I can take advantage of Emacs in more parts of my life
      1. Organizing my journal
      2. Trying out Elnode so that I can expose Emacs information to Javascript
      3. Getting back to doing mail in Gnus
      4. Using MobileOrg to review Org on the go?
    • Internals, debugging, and contributing to the community so that I can help out, and so that I can customize and debug more extensively
      • Emacs core, Org internals, syntax, font-locking, indentation, macros, Helm, …

    Coaches are also good for pointing out what you don’t even know you don’t know, which is a lot when it comes to Emacs. That’s another nice benefit of having someone look over your shoulder – they can catch you doing something in a round-about way even if you don’t even know that a more efficient way exists. But even with the stuff I know I don’t know (and that I have a reasonable plan for learning), there’s plenty to keep me occupied for the next few years. =) Besides, helping out on IRC and in mailing lists/newsgroups will expose me to stuff I don’t know too.

    So instead of turning up on one of these people’s (virtual) doorstops and asking, “Can you teach me all the stuff I don’t know?”, maybe this is what I can do instead:

    • Lay the groundwork by writing about and demonstrating the things I do know, so that I explore my limits, help other people learn, possibly get suggestions from random passers-by, and help potential mentors/coaches quickly get a sense of what I might be missing
    • Double-check my plans for learning different things with more experienced people who can give me feedback on sequence, exercises, and things I should include
    • Develop plans for deliberate practice of different components; slow down and notice opportunities to try things out
    • Share what I’m learning and my plans for what to learn next
    • Touch base once in a while

    So much to learn! =)

    Cooking at Hacklab: Coconut barfi

    November 5, 2014 - Categories: cooking

    It took me an hour to get from downtown to Hacklab on a stop-and-go Queen streetcar. Next time, I should probably take the King streetcar instead, or even go all the way north to Bloor and then south on the Dufferin bus. Anyway, I’d given myself enough of a buffer to not feel horribly guilty about being late meeting people who were expecting me there around 6-ish anyway, and that was when I made it. Max was already there when I arrived, and Gabriel joined us when we were at the supermarket picking up groceries.

    Chris and Alaina were busy making two courses (korma and hot-and-sour soup), so I figured we’d go with an Indian vegan dessert to accompany the korma. Some rapid Googling turned up this Coconut Barfi recipe from Diwali Sweets (by way of Veg Recipes of India’s review). We made a triple batch of the following recipe:

    • 1/2 cup semolina flour (we used medium, but this might be better with fine)
    • 1/2 cup dry coconut flakes (we used shredded)
    • 1 tablespoon coconut oil
    • 2 tablespoons chopped cashew pieces (got roasted cashews from the bulk bin so that we could snack on them while cooking)
    • pinch of salt

    For the sugar syrup:

    • 1/2 cup ground raw sugar (we used turbinado sugar, couldn’t find anything raw)
    • 3 tablespoons water
    • 1/8 to 1/4 teaspoon cardamom powder (we ended up grinding our own, since the nearby supermarket doesn’t stock powdered cardamom)

    It took longer to make the sugar syrup than expected, but then again, I’m pretty new to syrup making, so I wasn’t quite sure what “one thread consistency” meant. Anyway, it still turned out as nicely cardamom-scented nibble, crunchy without being jaw-breaking.

    Gabriel generously remarked that the amount of salt I added made it remind him of salted caramels. I think perhaps a smaller pinch would do next time.

    It was lots of fun cooking with both old friends and new acquaintances, and the kitchen at Hacklab supports having multiple people quite nicely (aside from a bit of stove coordination when we had three things on the go). Yay cooking!

    Coconut Barfi recipe

    Experimental Emacs Hangout 2014-11-05

    November 6, 2014 - Categories: emacs

    Event page has some comments: https://plus.google.com/events/cib5nqidkg6mpurtfuq60i2quik

    YouTube page: http://www.youtube.com/watch?v=rmGTNzfit2A

    Links:

    Apologies for the recording weirdness – I was experimenting with the feature that lets you occasionally focus the video feed on a specific person instead of letting it switch based on volume, and sometimes I forgot that I had that on while other people were talking. Also, I was having screensharing weirdness. And I was writing down notes on a Post-It somewhere in order to minimize typing noises, but I seem to have made the note vanish (yay nerves). But hey, zeroth episode, and we’ll keep on making it better! =) If you want to add notes/highlights in the comments for this blog post, that would be awesome.

    Next one Nov 19 Wed 1-3 PM EST – I’ll redirect http://sach.ac/live to it, so you should be able to find it there at that time. =)

    Rethinking delegation

    November 7, 2014 - Categories: delegation

    I’ve been distracted for the past two months, since I’ve been focusing on consulting more than on my personal projects. Now that things are stable again, I’d like to see if I can make better use of delegation as a way to expand my capabilities, learn more, and spread the opportunities. There are so many people with talents and skills out there, and there must be a way that I can get the hang of this.

    The purpose of going into business is to get free of a job so you can create jobs for other people.

    Michael E. Gerber, The E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It (1995)

    What’s getting in my way?

    Mostly it’s that I haven’t sat down and thought about:

    • The projects I’m willing to invest money into, in addition to time – although maybe I should just treat my time as fungible and delegation as a skill that’s worth learning anyway, so I should open up all my personal projects for consideration
    • Specific processes that I want to delegate, although I do have a decent-sized process library that I even share publicly
    • How I can reduce my involvement in things that are tied to me personally, and focus more on things where I can bring in other people

    I also have some guilt about the distinction between tasks I can definitely defend as being business-related, and tasks that are much more personal. For example:

    • Reviewing my accounting records and draft tax return – Definitely business.
    • Transcribing Emacs Chat sessions and recorded presentations – Well… Technically, people sometimes pay me for Emacs-related things and I’m working on packaging some things up as pay-what-you-can guides, so that’s okay, I guess?
    • Filling in recipes from Hacklab cooking nights – Definitely personal

    The main benefit of claiming things as a business expense is saving roughly 15% in tax, but if that’s mentally getting in the way of my just taking advantage of this, I should totally switch the contracts over to my personal credit card and just go for it until I’ve gotten the hang of this again. I’m nowhere close to my target of fully replacing the hours I’ve spent earning during this experiment (2829.6 hours worked, 486.8 hours delegated through oDesk, plus more through Paypal). But on the flipside, I don’t want to assign makework that I really should just automate or eliminate. Although maybe I should challenge myself to find something useful, since that gives people an opportunity to work and to improve their skills.

    Anyway.

    wpid-2014-11-01-More-thoughts-on-delegation.png

    Stuff I don’t particularly enjoy doing, but that could help:

    • Setting up events, coordinating with people, etc.
    • Comparison-shopping
    • Data entry
    • Organizing

    What would “getting the hang of this” look like? Future Sacha would:

    • Have these beautifully documented step-by-step processes for consistently getting stuff done, with enough volume and throughput that things happen consistently
    • Work with people who are also improving their skills and doing well

    Hmm. One of the things I’m looking forward to learning at work is the ability to sketch out a design or give some tips on how to do a report (which tables, what existing report to build on, etc.) and have someone else learn by doing it.

    Maybe what I need is something like that for my personal projects, too. If I get better at sketching out what I want, then I or someone else can make it happen. For example, with Emacs Chats and Emacs Hangouts, I’d like to eventually get to the point of:

    • Having a list of questions or topics I’m working my through
    • Having a page where people can see the things I’m curious about and volunteer to chat with me about them
    • Coordinating with those people about when we’re both available
    • Sharing a calendar and events where people can see upcoming entries
    • Getting everything recorded, processed, summarized, transcribed, and blogged about
    • Harvesting interesting snippets for a guide

    And for Quantified Self Toronto:

    • Picture of sign-up whiteboard + copy of videos = processed videos uploaded and blogged about

    For Hacklab and cooking:

    • Picture of food + links to recipe = blog post draft with recipe ingredients, photo, links to recipes = updated wiki page

    And a few experiments with Fiverr and other micro-outsourcing sites, too, just because.

    You know, even if I don’t end up feeling comfortable with calling those business expenses, I’m fine with it being a personal donation, since the communities are awesome. And it’s stuff I would probably end up doing anyway because it’s the Right Thing to Do.

    Although it might be interesting to someday build a business around helping developers become even better… Hmm.

    Weekly review: Week ending November 7, 2014

    November 9, 2014 - Categories: review, weekly

    This week was about getting back into the swing of several projects: Emacs, Japanese, Quantified Awesome and one of the personal projects I’m working on. Also, we picked up the LEGO Movie videogame, which is turning out to be lots of fun. =) I’m taking it pretty easy at the moment because there’s lots of stuff on the go.

    … Oh. Now that I look at all the things I’ve crossed off, it deosn’t seem like I’ve been taking it easy. Funny how that works. Thank goodness for TODO lists!

    Blog posts

    Sketches

    Link round-up

    Focus areas and time review

    • Business (38.5h – 22%)
      • Earn (15.3h – 39% of Business)
        • E1: Brainstorm prototypes I want to propose
        • Earn: E1: 2.5-3.5 days of consulting
      • Build (20.5h – 53% of Business)
        • Drawing (0.9h)
        • Delegation (0.0h)
        • Packaging (0.0h)
        • Paperwork (2.8h)
          • Apply updates from bookkeeper
          • Send trial balance and general ledger to accountant
          • Sort out invoice/deposit thing
        • Plan business and delegation for this phase
        • Set up Guard again
        • Set up Skewer
      • Connect (2.8h – 7% of Business)
        • Plan for office hours
        • Process Quantified Self videos
    • Relationships (3.9h – 2%)
      • File insurance paperwork
      • Coach Lucas on programming
    • Discretionary – Productive (23.4h – 13%)
      • Emacs (5.6h – 3% of all)
        • Figure out how Michael’s smartparens is showing rainbow colours for the blocks
        • Get the hang of smartparens
        • Log editing inefficiencies, keep track of annoyances. Then you can go through them when you have time.
        • Organize Emacs Hangout
        • Pick a different keychord instead of hs for seeking to seconds, or maybe turn it on only when transcribing
        • Quick clocking in on a task, or jumping and clocking task
        • Quick way to capture little thing to experiment with in Emacs
        • Rebind other-window
        • Set up and get the hang of Skewer
        • Set up and get the hang of autocompletion
        • expand-region
      • Japanese
        • Added counters to my Anki decks
        • Find a good resources for learning about Japanese counters
        • Minna no Nihongo Chapter 10
        • Minna no Nihongo Chapter 11: Counters
        • Minna no Nihongo Chapter 12
        • Minna no Nihongo Chapter 13
      • Quantified Awesome
        • Fix login form
        • Fix pagination
        • Fix sparklines
        • I can give someone access to my grocery list
        • Make list entry closer to my design
        • Update to Rails 4.1
        • Upgrade localhost to next version of Ubuntu
        • Wireframe design for groceries
        • Work on Angular interface for grocery list
      • Other
        • Organize a journal section in my notes
        • Trim my organizer.org file
        • Split up book notes into individual files
      • Apply for passport
      • Ask two guarantors for passport
      • Get passport pictures
      • Move my dentist appointment
      • Pick up cultural access pass from Front and Parliament
      • Writing (6.8h)
    • Discretionary – Play (9.7h – 5%)
    • Personal routines (24.1h – 14%)
    • Unpaid work (15.7h – 9%)
    • Sleep (53.9h – 32% – average of 7.7 per day)

    Planning little improvements

    November 10, 2014 - Categories: kaizen, learning, plans

    I like re-planning when things are a little bit clearer and when things change. It’s nice to take a look at where I am, where I might get to, and maybe what I can do with more reinvestment.

    wpid-2014-11-01-Baselines-and-possible-improvements-part-1.png wpid-2014-11-01-Baselines-and-possible-improvements-part-2.png

    A year still feels a little abstract. A 12-week span might be interesting for concrete goal-setting and momentum; maybe something to experiment. In any case, here’s a small achievement list I can work towards…

    1. Development
      • Propose a calendar of prototypes with business-value descriptions
      • Design prototype and help team members write it instead of coding it myself
      • Think syntactically
    2. Reporting
      • Make Tableau reports snappy
      • Identify business questions for a valuable regular report
      • Analyze my own data in R
    3. Writing: Put together the intermediate Emacs config guide
    4. Drawing: Sketch people quickly
    5. Cooking: Map the families of recipes I want to try, and try them
    6. Learning: Map the things I know and what I want to learn, and maybe find a coach
    7. Tracking: Do grocery tracking in Quantified Awesome
    8. Making: Sew those box cushion covers
    9. Organizing house stuff
      • Simplify wardrobe
      • Tile floor
    10. Biking: Maybe bike in winter
    11. Pet care: Get Luke used to the toothbrush
    12. Exercise: Do the exercise ladder for twelve weeks
    13. Relationship: Work on more projects together
    14. Community:
      • Set up Emacs hangout experiment
      • Hang out at Hacklab during winter

    Emacs: Evaluating Javascript and CSS in Chrome using Skewer Mode

    November 11, 2014 - Categories: emacs, geek

    I build a lot of quick prototypes, using Javascript and CSS to build little tools on top of the Jive social business platform. Since Javascript syntax errors could prevent the proper loading of the overview page customization screen and require me to reset the overview page through the admin console, my previous Javascript workflow involved copying and pasting code into Google Chrome’s developer console. Most of the time, I used narrow-to-region to focus on just the specific script block or set of functions I was working on, and I used js2-mode to handle syntax highlighting and indentation. Once the Javascript was sorted out, I’d widen to get back to the full HTML, JS, and CSS file, using web-mode for indentation.

    Copying code between Javascript buffers and the developer console was a bit of a hassle. I’d use C-x h (mark-whole-buffer) to select the buffer, then C-w to copy it, change over to the Chrome window (possibly wading through a number of tabs and windows to find the right one), find the developer console, click in it, paste the code, and run it. My first step was to define a custom function that copied the whole buffer:

    (defun sacha/copy-buffer ()
      "Copy buffer contents to kill ring."
      (interactive)
      (kill-new (buffer-substring-no-properties (point-min) (point-max))))
    (global-set-key (kbd "C-c w") 'sacha/copy-buffer)
    

    I still had to find the Chrome window and paste the code in, though.

    My CSS workflow had its own challenges. I used Inspect Elements to look at CSS properties, and then I modified them on the fly. When I was happy with the rules I added or changed, I wrote the corresponding CSS code in my local file. Because I often ended up modifying several elements, it was hard to remember all the changes I needed to make, apply different sets of changes, or apply the changes after reloading the page. I used Stylish to make some of my changes persistent, but that still involved going back and forth between screens.

    Since I’ll continue to work on web development over the next year (at least!), I thought I’d invest some time into improving my workflow. I’d seen several demos of Skewer Mode for Emacs, and I’d even given it a try a few times before. I hadn’t integrated it into my workflow yet, but it looked like it was definitely worth a try. Skewer allows you to interact with Google Chrome from Emacs. You can send HTML, CSS, and Javascript fragments to your browser.

    If you use the included Greasemonkey-compatible script, you can even use this interactive capability on any website. I used the Tampermonkey extension for Google Chrome to run the script. When I tried it on the site I was working on, though, the https/http mismatch resulted in a content security error. It turns out that you need to run chrome --allow-running-insecure-content in order to let Chrome inject HTTPS sites with the scripts from the local HTTP server that Skewer Mode runs inside Emacs. If you had other Chrome sessions open, you’ll want to close them before starting up Chrome with that option. Once I sorted that out, it was easy to run skewer-setup, open a JS file, and start sending code to my browser.

    I quickly became a fan of how C-c C-k (skewer-load-buffer in JS, skewer-css-eval-buffer in CSS) let me send my buffer to my browser. I narrowed my buffer to the parts I was working on, wrote some tests using console.assert(...), and kept the console visible as I coded. I periodically loaded the buffer to check whether my tests passed. I also liked having a proper file identifier and correct line numbers for errors. (It’s amazing how small things matter!)

    Then to top it all off, I wanted a function that would prepare the source code for easy pasting into an HTML widget:

    <script type="text/javascript">
    // filename
    </script>
    

    Since Emacs is Emacs, you can do that. =)

    (defvar sacha/javascript-test-regexp (concat (regexp-quote "/** Testing **/") "\\(.*\n\\)*")
      "Regular expression matching testing-related code to remove.
    See `sacha/copy-javascript-region-or-buffer'.")
    
    (defun sacha/copy-javascript-region-or-buffer (beg end)
      "Copy the active region or the buffer, wrapping it in script tags.
    Add a comment with the current filename and skip test-related
    code. See `sacha/javascript-test-regexp' to change the way
    test-related code is detected."
      (interactive "r")
      (unless (region-active-p)
        (setq beg (point-min) end (point-max)))
      (kill-new
       (concat
        "<script type=\"text/javascript\">\n"
        (if (buffer-file-name) (concat "// " (file-name-nondirectory (buffer-file-name)) "\n") "")
        (replace-regexp-in-string
         sacha/javascript-test-regexp
         ""
         (buffer-substring (point-min) (point-max))
         nil)
        "\n</script>")))
    
    (define-key js2-mode-map (kbd "C-c w") 'sacha/copy-javascript-region-or-buffer)
    

    So now I can fiddle around with Javascript and CSS, send it to my browser with C-c C-k, and then use C-c w to wrap the Javascript in script tags and prepare it for copying.

    Emacs!

    Dealing with uncertainty one step at a time

    November 12, 2014 - Categories: life

    Sometimes it’s hard to plan ahead because there are just too many factors to consider, too many things I don’t know, too many divergent paths. I can come up with different scenarios, but I can’t figure out a lot of things that would make sense in all the likely scenarios. Some of the scenarios are exciting, but some of them are also scary. They’re hard to hold in my mind. They fight my imagination. I can’t plan straight for these. I can’t come up with step 1, step 2, step 3. At best, I can come up with if-then-elses, but I still have to wait and see how things turn out.

    Sometimes it’s easier to take life one day at a time, because if I think about too large a chunk, I start getting lost. Sometimes it’s better to not focus on everything that’s needed, just what’s needed right now.

    wpid-2014-11-11-Dealing-with-uncertainty-one-step-at-a-time.png

    It rattles me a little bit because I’m more used to seeing clearer paths. Or do I only think that I’m used to that?

    Let me try to remember when I felt that sense of clarity and certainty. I was certain about taking computer science; I loved programming even as a kid. I was certain about teaching after graduation; I loved helping people learn. I was certain about taking a technical internship in Japan; it was an interesting thing to do. I was certain about taking my master’s degree; it was a logical next step, necessary for teaching, and the research was interesting.

    I was not certain about being in Canada, and I was often homesick during my studies. But I was certain about W-, and now this place also feels like home. I was certain about IBM and about the people and ideas I wanted to work with. I was certain about saving up an opportunity fund so that I could explore other things someday. I was certain about starting this 5-year experiment with semi-retirement.

    So I’m familiar with what it’s like to plan for a chunk of certainty – half a year, four years, decades. It feels good when a plan comes together, when I can see how each step leads to a future I’ve already lived in my head.

    I am certain, now, that I’m going in roughly the right direction. I don’t know exactly how it will work out, but I know that it will be interesting.

    Ah! There it is, I think, the thing I’m trying to grasp. The future Sacha of this five-year experiment is fuzzy in my head. That evaluation point is only two years away now, and I should be able to imagine her more clearly. But aside from a few abstract characteristics (future Sacha is a better developer and writer, future Sacha continues to be happy, future Sacha gets to work on what she wants), I don’t have a good sense of her yet – not with the same solidity of past futures. I’m not sure what to put on that Conveyor Belt of Time (as Mr. Money Mustache puts it) aside from generically-useful gifts to my future self: decent finances, relationships, skills.

    Circling back to the metaphor that emerged while I was drawing and writing my way through this question, I suppose this is like the difference between hiking along a trail with a view – or even unmarked ground, but with landmarks for orienting yourself – versus exploring the woods. Not that I know much of the latter; I’ve never been lost in the woods before, never strayed from the safety of a trail or the sight of a road. (Well, except maybe that one time we were hiking along the Bruce Trail and got turned around a little bit, and we ended up scrambling up a slope to find the trail we really wanted to be on.)

    I can learn to enjoy exploring, knowing that in the worst-case scenario, I’ve got the figurative equivalent of supplies, a GPS, emergency contacts, backup batteries and so on. I can learn to enjoy observing the world, turning questions and ideas over, noticing what’s interesting about them, perhaps cracking things open in order to learn more. I can learn to take notes, make maps, tidy up trails, and leave other gifts for people who happen to wander by that way.

    Ah. That might be it. Let’s give that a try.

    The Google Chrome extensions I use

    November 13, 2014 - Categories: geek

    Richard wanted to know which Google Chrome extensions I use. Here’s the list:

    • AdBlock: I still see ads, but I probably see fewer ads than before.
    • AngularJS Batarang: Great for debugging AngularJS applications.
    • Any.do Extension: I use this on my phone. Still thinking about how I can get something working with Org Mode and my phone. Might replace this with MobileOrg.
    • Application Launcher for Drive (by Google): I hardly use this, but it seems like a good idea.
    • Boomerang Calendar: Recognizes dates in e-mails and makes it easy to create appointments. Might not need it after Google improves its interface some more.
    • Boomerang for Gmail: Great for delaying replies, following up in case of non-response, or getting things to turn up in your inbox after a specified delay.
    • Capture Webpage Screenshot – FireShot: Can come in handy for full-page screenshots.
    • CSS Reloader: Handy during development.
    • Don’t track me Google: I use this mainly to remove the annoying Google redirection that happens when you copy links from search results without clicking through them. This way, I can copy and paste cleaner URLs.
    • Dragon Web Extension: Theoretically allows me to use speech recognition to control Chrome. I still haven’t gotten Dragon Naturally Speaking to be part of my workflow.
    • Evernote Web Clipper: Evernote is a great way to stash things I may want to refer to later.
    • Feedly: The extension lets me quickly subscribe to blogs. I prefer reading them on my phone, though.
    • Google Docs: Handy for sharing documents and editing them online.
    • Hangouts: I use this for video chats.
    • LastPass: Free Password Manager: Handy for storing and sharing passwords.
    • RescueTime for Chrome & ChromeOS: Tracks the sites I visit. I’m not doing anything with this data yet.
    • Rikaikun: Helps me learn Japanese when I hover over kanji.
    • RSS Subscription Extension (by Google): Displays a feed icon in the address bar if the site has alternate links to feeds. This way, I don’t have to hunt around for the right link.
    • Send from Gmail (by Google): Makes Gmail the default handler for e-mail addresses.
    • Tampermonkey: For injecting the Javascript that Skewer needs so that I can interact with webpages from Emacs. Could probably get away with using a bookmarklet instead. This tends to slow down Chrome, so I enable it only when I’m planning to develop.

    What extensions do you use?

    What could I do if I showed up in a bigger way?

    November 14, 2014 - Categories: experiment, plans

    I’m reading Ben Arment’s Dream Year: Make the Leap From a Job You Hate to a Life You Love (2014), and there’s a reminder in here about the choice between the fear of failure and the fear of insignificance. “Choose the fear of insignificance,” the author says. And I think: Hmm, actually, I’m okay with insignificance (or minor minor minor significance, in any case). Stoicism reminds us that after thousands of years, very little of this will matter. But maybe I should care a little bit. Since I’ve done all this work to minimize the fear of failure anyway. I might as well play on that side of the equation.

    I’ve been thinking about this recently because I’m wondering whether I should take this experience in social business and make something bigger out of it. I could probably negotiate something with my main consulting clients so that we could get ideas or even code out in the wider world, or I could independently develop something that they and other people would be welcome to use. I haven’t quite sorted out what that would be like yet, but I imagine it would start off as open source components, then possibly consulting and product development once I’ve established a reputation in that community.

    Of social business, Emacs, and blogging, though, I like Emacs the most. There’s something about it. I like the community a lot: interesting people doing interesting things, and a remarkably flexible platform that has kept me curious and fascinated for years. If I were to show up in a bigger way, I suppose that would involve writing more guides, and maybe understanding enough of the core of complex things like Org and Emacs itself so that I could contribute to the codebase. I tend to focus on workflow more than bugfixes or new features, though… I think there’s something interesting in how people use the same things in such different ways. Maybe I’ll write more about my evolving workflow, using that and personal projects as excuses to keep tweaking.

    As for blogging, there are bucketloads of people who are happy to give other people advice on what to do and how to do it. I’m interested in keeping it unintimidating and useful for personal learning, but I’m more excited about and curious about those other two causes. Still, I can show by example, and I can offer advice and encouragement when people ask.

    What are the differences between this slightly bigger life and my current one? I think part of it is related to the way that I’ve been minimizing my commitments during this 5-year experiment, being very careful about what I say yes to and what I promise my time towards. Part of it is taking the initiative instead of waiting for requests or sparks of inspiration. Part of it is working more deliberately towards a goal. It’s not going to be a big big life, but it might be interesting to experiment with.

    Weekly review: Week ending November 14, 2014

    November 15, 2014 - Categories: review, weekly

    I’m going to be out of commission for the next little while, probably resurfacing sometime late December. I’ve scheduled lots of posts in advance (I learned a lot over the past two weeks!), so you’ll still keep reading stuff, but I might be even slower to respond to things and I’ll probably stay close to home. Nothing to worry about, just something I have to take care of. Good thing there’s enough slack in my life for stuff like this.

    Blog posts

    Sketches

    Focus areas and time review

    • Business (23.2h – 13%)
      • Earn (9.3h – 39% of Business)
        • E1: Plan how I can work from home for the next few weeks
        • Earn: E1: 1-2 days of consulting
      • Build (8.4h – 36% of Business)
        • Set up faster searching with ace-jump, isearch, helm-swoop
        • Drawing (1.4h)
        • Delegation (0.0h)
        • Packaging (0.0h)
        • Paperwork (1.5h)
          • Review bookkeeper feedback for tax return
      • Connect (5.5h – 23% of Business)
        • Coach Lucas on programming
    • Relationships (16.4h – 9%)
      • Follow up on insurance paperwork
    • Discretionary – Productive (15.9h – 9%)
      • Emacs (0.3h – 0% of all)
      • Quantified Awesome
        • Add want interface for groceries
        • Fix edit screen
        • I can restore an item
        • I can clear all crossed-off items
        • I can see when it was last synchronized
        • Our lists are synchronized
      • ER for I2
      • Cancel GICs
      • File insurance claims
      • Find a Japanese plain past tense practice tool
      • Find a Tableau e-book and put it on my laptop/tablet
      • Find an e-book for learning Japanese and put it on my laptop & tablet
      • Go through a Jasmine tutorial
      • Go through a QUnit tutorial
      • Minna no Nihongo Chapter 13-16
      • Move my dentist appointment
      • Set up folder synchronization for my tablet
      • Write about beginner steps for testing
      • Writing (7.5h)
    • Discretionary – Play (12.9h – 7%)
    • Personal routines (24.5h – 14%)
    • Unpaid work (4.5h – 2%)
    • Sleep (70.7h – 42% – average of 10.1 per day)

    My current book workflow

    November 17, 2014 - Categories: reading

    I pick up a lot of information from books. We have an amazing public library system, and I’m at the library at least once a week. Here’s my current workflow for reading and taking notes on books.

    Finding books to read: I check the library’s new releases for interesting titles. I have a Ruby script that extracts the information and puts it into a text file. I delete anything that doesn’t interest me, and then I copy the IDs into another Ruby on Rails system that requests all the books for me. Sometimes I search for books by topic or get recommendations from other people.

    Reading books: I’ve successfully weaned myself off the bad habit of folding over the corners of book pages (dogearing). Instead, I use book darts to point to the passages that I want to copy into my notes. I have only one tin of them, so that encourages me to harvest the notes from books before moving on to other books. If I don’t have my book darts handy, I use strips of paper, but they’re not as awesome.

    I also keep paper and pen handy (index cards, or the small notebook I always have in my vest) so that I can take notes on ideas, questions, and other things that aren’t directly in the text of the book.

    I mostly read non-fiction, so that’s easy to skim for interesting bits. I usually check the table of contents to get an overview of the book. I have no qualms about jumping straight to specific chapters and then wandering around a bit, or even picking just a few pages out of a book. I rarely use the index (and most books don’t have a good one anyway), although maybe I should check that more often.

    Taking notes: I keep individual text files named after the title of the book (and sometimes authors as well). I usually include the ISBN so that I can easily look up a book later. The text files contain quotes, ideas, TODOs, and other notes.

    If no one else is around and I feel like patiently dealing with speech recognition, I open Dragon Naturally Speaking and dictate the passages from the books. This helps me train Dragon’s speech model as well, which might be handy someday. If other people are around, though, I’ll just type in the segments from the book.

    I usually type in my paper notes so that they’re more coherent (since I tend to write keywords instead of full thoughts). If I want to scan my index cards or notebook pages, I pop those into my Fujitsu Scansnap ix500 and scan them as JPG. I convert the JPGs to PNG and rename them with the date and title, and then I move them to a folder that gets automatically imported into Evernote. Evernote lets me search for text, and it also tries to find text even in scans of handwriting. It’s not perfect, but it’s decent, and I’ve learned to write more clearly because of that.

    Looking things up: Since most of my notes are text, I can use grep to search through them.

    Sharing what I know: I sometimes include excerpts or ideas in my blog posts. When I do, I link to the blog post from my text notes as well, so I can see what I’ve digested further and shared. If I’m reading a book that I know I’ll want to share with other people later (or if the authors have asked me nicely =) ), I sometimes visually summarize the book.

    Following up on ideas: I add TODOs to my Org Mode agenda. I can also schedule reminders for things. I’m a little hesitant to add my books directory to the org-agenda-files list that Org Mode checks for TODO items (I have hundreds of book notes now!), so I’ve defined a custom agenda command that looks at just the book directory instead. Alternatively, it’s easy enough to grep the TODO keyword.

    Planned improvements: I’m curious about the idea of a syntopicon, which I picked up from Adler and van Doren’s How to Read a Book. A syntopicon is a map of ideas across multiple books. With Org Mode’s support for indexing and links, I should be able to make something like it. I’m also looking forward to writing more about what I do with what I’m learning from books. This helps me challenge myself to learn actively instead of just letting a book flow through my brain.

    Mmm, books!

    If you’re curious, you can read about my past workflows:

    Emacs: Limiting Magit status to a directory

    November 18, 2014 - Categories: emacs

    I’m probably using Git the wrong way. In addition to the nice neat repositories I have for various projects, I also sometimes have a big grab-bag repository that has random stuff in it, just so that I can locally version-control individual files without fussing about with Emacs’ numbered version systems. Sometimes I even remember to organize those files into directories.

    When you have a Git repository that’s not one logical project but many little prototypes, using Magit status to work across the entire project can sometimes mean running into lots of distracting work in progress. I wanted a way to limit the scope of Magit status to a specific directory.

    Here’s the experimental code I came up with:

          (defvar sacha/magit-limit-to-directory nil "Limit magit status to a specific directory.")
          (defun sacha/magit-status-in-directory (directory)
            "Displays magit status limited to DIRECTORY.
    Uses the current `default-directory', or prompts for a directory
    if called with a prefix argument. Sets `sacha/magit-limit-to-directory'
    so that it's still active even after you stage a change. Very experimental."
            (interactive (list (expand-file-name
                                (if current-prefix-arg
                                    (read-directory-name "Directory: ")
                                  default-directory))))
            (setq sacha/magit-limit-to-directory directory)
            (magit-status directory))
    
          (defadvice magit-insert-untracked-files (around sacha activate)
            (if sacha/magit-limit-to-directory
                (magit-with-section (section untracked 'untracked "Untracked files:" t)
                  (let ((files (cl-mapcan
                                (lambda (f)
                                  (when (eq (aref f 0) ??) (list f)))
                                (magit-git-lines
                                 "status" "--porcelain" "--" sacha/magit-limit-to-directory))))
                    (if (not files)
                        (setq section nil)
                      (dolist (file files)
                        (setq file (magit-decode-git-path (substring file 3)))
                        (magit-with-section (section file file)
                          (insert "\t" file "\n")))
                      (insert "\n"))))
              ad-do-it))
    
          (defadvice magit-insert-unstaged-changes (around sacha activate)
            (if sacha/magit-limit-to-directory
                (let ((magit-current-diff-range (cons 'index 'working))
                      (magit-diff-options (copy-sequence magit-diff-options)))
                  (magit-git-insert-section (unstaged "Unstaged changes:")
                      #'magit-wash-raw-diffs
                    "diff-files"
                    "--" sacha/magit-limit-to-directory
                    ))
              ad-do-it))
    
          (defadvice magit-insert-staged-changes (around sacha activate)
            "Limit to `sacha/magit-limit-to-directory' if specified."
            (if sacha/magit-limit-to-directory
                (let ((no-commit (not (magit-git-success "log" "-1" "HEAD"))))
                  (when (or no-commit (magit-anything-staged-p))
                    (let ((magit-current-diff-range (cons "HEAD" 'index))
                          (base (if no-commit
                                    (magit-git-string "mktree")
                                  "HEAD"))
                          (magit-diff-options (append '("--cached") magit-diff-options)))
                      (magit-git-insert-section (staged "Staged changes:")
                          (apply-partially #'magit-wash-raw-diffs t)
                        "diff-index" "--cached" base "--" sacha/magit-limit-to-directory))))
              ad-do-it)))
    

    Now I can bind C-x v C-d to sacha/magit-status-in-directory and get something that lets me focus on one directory tree at a time. You can see my config in context at http://sachachua.com/dotemacs#magit

    It feels like I’m probably trying to do things the Wrong Way and I should probably just break things out into separate repositories. Even though I realized this early on, though, I ended up digging into how to implement it just for the sheer heck of seeing if Emacs would let me do it. =) I don’t know how often I’ll use this function, but it was a good excuse to learn more about the way Magit works.

    It took me an hour to find my way around magit.el, but that’s more my fault than the code’s. At first I tried to override magit-diff-options, but I eventually remembered that the paths need to come at the end of the command line arguments. (I had a cold! My brain was fuzzy!) It was fun poking around, though. Looking forward to learning even more about Magit!

    First steps towards Javascript testing

    November 19, 2014 - Categories: development, geek

    I know, I know, it’s about time I got the hang of this. Better late than never, right? =) Anyway, I spent some time going through tutorials for QUnit and Jasmine. For QUnit, I followed this Smashing Magazine tutorial on Javascript unit testing. I modified the code a little bit to add the Z timezone to the test data, since my tests initially didn’t pass.

    test.html

    <!DOCTYPE html>
    <html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>Refactored date examples</title>
        <link rel="stylesheet" href="http://code.jquery.com/qunit/qunit-1.15.0.css" />
        <script src="http://code.jquery.com/qunit/qunit-1.15.0.js"></script>
        <script src="prettydate.js"></script>
        <script>
         test("prettydate.format", function() {
           function date(then, expected) {
             equal(prettyDate.format('2008/01/28 22:25:00Z', then), expected);
           }
           date("2008/01/28 22:24:30Z", "just now");
           date("2008/01/28 22:23:30Z", "1 minute ago");
           date("2008/01/28 21:23:30Z", "1 hour ago");
           date("2008/01/27 22:23:30Z", "Yesterday");
           date("2008/01/26 22:23:30Z", "2 days ago");
           date("2007/01/26 22:23:30Z", undefined);
         });
         function domtest(name, now, first, second) {
           test(name, function() {
             var links = document.getElementById('qunit-fixture').getElementsByTagName('a');
             equal(links[0].innerHTML, 'January 28th, 2008');
             equal(links[2].innerHTML, 'January 27th, 2008');
             prettyDate.update(now);
             equal(links[0].innerHTML, first);
             equal(links[2].innerHTML, second);
           });
         }
    
         domtest("prettyDate.update", '2008-01-28T22:25:00Z', '2 hours ago', 'Yesterday');
         domtest("prettyDate.update, one day later", '2008-01-29T22:25:00Z', 'Yesterday', '2 days ago');
        </script>
    </head>
    <body>
      <div id="qunit"></div>
      <div id="qunit-fixture">
        <ul>
          <li class="entry" id="post57">
            <p>blah blah blah…</p>
            <small class="extra">
              Posted <span class="time"><a href="/2008/01/blah/57/" title="2008-01-28T20:24:17Z">January 28th, 2008</a></span>
              by <span class="author"><a href="/john/">John Resig</a></span>
            </small>
          </li>
          <li class="entry" id="post57">
            <p>blah blah blah…</p>
            <small class="extra">
              Posted <span class="time"><a href="/2008/01/blah/57/" title="2008-01-27T22:24:17Z">January 27th, 2008</a></span>
              by <span class="author"><a href="/john/">John Resig</a></span>
            </small>
          </li>
        </ul>
      </div>
    </body>
    </html>
    

    For practice, I converted the QUnit tests to Jasmine. The first part of the test was easy, but I wanted a clean way to do the HTML fixture-based tests for prettydate.update too. Jasmine-JQuery gives you a handy way to have HTML fixtures. Here’s what my code ended up as:

    spec/DateSpec.js

    describe("PrettyDate.format", function() {
        function checkDate(name, then, expected) {
            it(name, function() {
                expect(prettyDate.format('2008/01/28 22:25:00Z', then)).toEqual(expected);
            });
        }
        checkDate("should display recent times", '2008/01/28 22:24:30Z', 'just now');
        checkDate("should display times within a minute", '2008/01/28 22:23:30Z', '1 minute ago');
        checkDate("should display times within an hour", '2008/01/28 21:23:30Z', '1 hour ago');
        checkDate("should display times within a day", '2008/01/27 22:23:30Z', 'Yesterday');
        checkDate("should display times within two days", '2008/01/26 22:23:30Z', '2 days ago');
    });
    describe("PrettyDate.update", function() {
        function domtest(name, now, first, second) {
           it(name, function() {
               loadFixtures('test_fixture.html');
               var links = document.getElementById('qunit-fixture').getElementsByTagName('a');
               expect(links[0].innerHTML).toEqual('January 28th, 2008');
               expect(links[2].innerHTML).toEqual('January 27th, 2008');
               prettyDate.update(now);
               expect(links[0].innerHTML).toEqual(first);
               expect(links[2].innerHTML).toEqual(second);
           });
        }
        domtest("prettyDate.update", '2008-01-28T22:25:00Z', '2 hours ago', 'Yesterday');
        domtest("prettyDate.update, one day later", '2008-01-29T22:25:00Z', 'Yesterday', '2 days ago');
    });
    

    jasmine.html

    <!DOCTYPE HTML>
    <html>
    <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <title>Jasmine Spec Runner v2.0.2</title>
    
      <link rel="shortcut icon" type="image/png" href="lib/jasmine-2.0.2/jasmine_favicon.png">
      <link rel="stylesheet" type="text/css" href="lib/jasmine-2.0.2/jasmine.css">
    
      <script type="text/javascript" src="https://code.jquery.com/jquery-2.1.1.min.js"></script>
      <script type="text/javascript" src="lib/jasmine-2.0.2/jasmine.js"></script>
      <script type="text/javascript" src="lib/jasmine-2.0.2/jasmine-html.js"></script>
      <script type="text/javascript" src="lib/jasmine-2.0.2/boot.js"></script>
      <script type="text/javascript" src="jasmine-jquery.js"></script>
    
      <!-- include source files here... -->
      <script type="text/javascript" src="prettydate.js"></script>
    
      <!-- include spec files here... -->
      <script type="text/javascript" src="spec/DateSpec.js"></script>
    
    </head>
    
    <body>
    </body>
    </html>
    

    I’m looking forward to learning how to use Jasmine to test Angular applications, since behaviour-driven testing seems to be common practice there. Little steps! =)

    Beginner web dev tip: Use Inspect Element to learn more about HTML and CSS on a page

    November 20, 2014 - Categories: geek

    One of the neat things about learning web development is that the Web is full of examples you can learn from. You can use your browser’s View Page Source or View Source command (available from the right-click menu in Google Chrome, Mozilla Firefox, or Internet Explorer). An even better way to explore, though, is to use the Inspect Element action from the right-click menu in those browsers. If you right-click on the item you want to learn more about, you’ll be able to see the HTML and the current CSS applied to the page.

    I use Google Chrome most of the time, so I’ll show you Inspect Element screen in that browser. Here we’re looking at the button on CSS-Tricks.com:

    2014-11-10 15_37_06-CSS-Tricks.png

    You’ll see the HTML on the left side and the CSS on the right. You can check or uncheck different CSS rules, and you can double-click on things to edit them. Check out the right-click menus for even more options.

    Sometimes you may need to click on a different element in order to see the CSS rules that are relevant to what you’re curious about. As you hover over different elements, you’ll see them highlighted on the page.

    If you click on the Console tab, you can experiment with Javascript too. If you want to view both the inspect element information and the Javascript console at the same time, click on the icon that looks like a > on the right side. This is particularly handy if you have a large screen.

    Hope that helps!

    Keeping a process journal

    November 21, 2014 - Categories: learning, writing

    I post a lot of notes on my blog, and I keep more snippets in my personal files so that I can learn from them and turn them into blog posts later. There’s something still missing here, though, something I can tweak. Reading Louise DeSalvo’s The Art of Slow Writing (2014), I recognized part of what was missing in her description of process journals. Here’s a relevant excerpt:

    p82. In Steinbeck’s April 9, 1951, entry, written as he composed East of Eden, he evaluates his desk’s new surface, determines how to keep his pencil drafts from smudging, figures when it’s best to do his laundry, plans his week’s work, determines to try to write somewhat more, assesses his energy level, discusses his fear of interruptions derailing his work, pledges maintaining his focus to complete the work by managing his work in his journal.

    … Here we see Steinbeck deliberately managing his work before he begins the labor of writing. He evaluates his tools–his desk and pencils–shapes his day, sketches the new scene, deals with his emotions, summarizes and evaluates his progress, and figures how to move his work forward. And Steinbeck engaged in this process each day.

    (Oh! I love writers Have Thought About Stuff. It’s like the way programmers also tend to apply tools and systems to more than just programming… Come to think of it, I wonder how geeks of other persuasions end up applying their geekdoms to the rest of life!)

    Anyway: a place to clear your thoughts, a deliberate reflection on processes and practices, and perhaps a way to browse through those entries in chronological order or based on context… My blog is a little like that, but there’s so much more stuff than I publish on it and it will continue to be like that if I insist on keeping to my mostly-one-post-a-day limit and scheduling things in advance.

    I’ve been keeping a small journal–just a few keywords per day, scribbled into a paper notebook shortly before going to bed–for the past three months. It’s amazing how that’s enough to help me get back to those days, remembering more details than I could without them.

    Org Mode for Emacs has built-in support for quickly capturing notes and organizing them in an outline by date. I think I’ll use that for at least quick memories, since those make sense in a timeline, and then I’ll keep the larger notes in a topic-focused outline. Technically, I’m using a computer, so I should be able to organize things both ways: using tags and links to connect items by topic, and using Org’s log view to view things by date.

    It would be good to start with this kind of deliberate, constant improvement in a few areas of my life:

    • Web development: I’d like to learn more about design, and also developing better code
    • Writing: I can pay more attention to the questions I formulate and how I explore them
    • Cooking: Hmm, more notes on how we make the recipes and what the cooking process is like?

    If I make Fridays the days I focus on harvesting my notes from the previous week and plan some ideas for the next one, that would fit in nicely with reviewing this process journal and seeing what I can build on the next week. (I’m still going to post random snippets during the week, probably… =) )

    Weekly review: Week ending November 21, 2014

    November 22, 2014 - Categories: review, weekly

    Wow, did I ever get a lot of sleep last week. Fortunately, I’ve been able to turn over all my responsibilities, and I’ve given myself permission to take it easy. I’m rarely under the weather like this, and it’s an interesting learning opportunity for dealing with variable energy and short attention spans. The blog has been coasting thanks to the posts that I wrote a week or two ago, but since I still do manage to learn something here and there, I’ll see how many posts I can squeeze in to remind me of stuff that I may want to think about later or that other people might find useful. =)

    I still managed to do a little bit of consulting here and there, thanks to the wonders of working from home. =) This week, I discovered that recursive queries in PostgreSQL (WITH RECURSIVE) are actually a pretty fast way of traversing an organizational chart described as an adjacency list. I also wireframed a prototype so that one of the other developers can work on it, but she’ll probably need a little more help before she’s ready to take that on. I’m getting better at asking people to do things instead of giving into the temptation to have all the fun myself!

    We’ll keep things loose. I’ll try to take notes along the way. =)

    Blog posts

    Link round-up

    Focus areas and time review

    • Business (14.4h – 8%)
      • E1: Plan how I can work from home for the next few weeks
      • Read AngularJS documentation
      • Review bookkeeper feedback for tax return
      • Earn: E1: 1-2 days of consulting
      • Earn (6.8h – 46% of Business)
      • Build (7.6h – 53% of Business)
        • Drawing (2.3h)
        • Delegation (0.0h)
        • Packaging (0.0h)
        • Paperwork (2.4h)
      • Connect (0.0h – 0% of Business)
    • Relationships (20.2h – 12%)
      • Work on E
      • Follow up on insurance paperwork
      • Work on E
    • Discretionary – Productive (2.6h – 1%)
      • Emacs (0.0h – 0% of all)
      • Writing (0.0h)
    • Discretionary – Play (15.6h – 9%)
    • Personal routines (26.8h – 15%)
    • Unpaid work (4.8h – 2%)
    • Sleep (83.6h – 50% – average of 11.9 per day)

    Thinking about word counts and chunks

    November 24, 2014 - Categories: blogging

    I was talking to Frank Chen about blogging, and he mentioned that he’s experimenting with word count goals. That made me realize that I don’t pay much attention to word count when I write, and that I tend to write shorter posts. I think in terms of chunks of ideas. I write each post so that it covers one idea, either something I want to share or something I want to learn. Sometimes I cover a little more ground, if I can chunk the sub-ideas enough to hold them in my brain at the same time. Sketches help me a lot when it comes to developing thoughts further.

    I rarely write larger posts that bring lots of things together. I guess it’s because I tend to write about:

    • things I’ve just learned: publishing small chunks helps me get my notes out faster
    • things I’m figuring out: nibbling away at questions helps me make sense of them
    • answers to specific questions: small chunks and clear titles makes it easier for me to find things and share links later

    What are some examples of longer posts and resources I’ve worked on?

    • There’s How to Read Lisp and Tweak Emacs, which I published as a four-part weekly series and also as a single file.
    • There’s the No Excuses Guide to Blogging, which I published as a PDF/EPUB/MOBI. I linked the source blog posts into a series so that people coming across the posts in the archives can still navigate between them.
    • I post presentations like The Shy Connector as slides and a full blog post. That said, I usually try to keep my presentations to about 10-15 minutes anyway, so the resulting posts are not enormous.
    • Interviews or videos with transcripts can get really long because I talk quickly. For example, this Emacs Chat with John Wiegley is pretty long. I’ve experimented with breaking transcripts up into logical segments, but keeping the entire transcript together seems to make more sense to me.

    What would it be like to experiment with longer posts that cover more ground? Based on the blogs I like reading, I think it might mean writing more thorough guides like the ones on Mastering Emacs – things that people would bookmark and refer to a few times.

    Organized guides help beginners a lot because they don’t get lost trying to figure out the next step. They can keep scrolling down. On the flip side, it might take a bit more work to make long guides friendlier for intermediate and advanced users: a table of contents, links to alternative paths or related content, closer and more coherent discussion…

    Hmm. I feel a little odd about drafting a long resource (takes time to write and takes time to read), and deep-linking into part of a blog post can be a little difficult.

    I think I like working with short chunks that I can link to or assemble into different pieces. Maybe I’ll spend a little more time planning outlines and series of related posts so that I can link posts together and fill in the gaps. For now, I’ll leave the ultimate-guide-writing to other people who are better at linear organization (or to future Sacha when she writes books).

    Onward to better writing and sharing!

    Using Org Mode to keep a process journal

    November 25, 2014 - Categories: emacs, org

    I (re)started keeping a journal in Org Mode – chronologically-ordered snippets on what I’m doing, how I’m doing things, and how I’m thinking of improving. I’d mentioned the idea previously on my blog. In this post, I want to share the workflow and configuration that makes it easier for me to log entries.

    When I’m on my personal computer, I use Org Mode’s org-capture command to quickly capture notes. I’ve bound org-capture to C-c r, a remnant from the way I still think of it as related to the even older org-remember and remember functions. Anyway, org-capture allows you to define several org-capture-templates, and it will display these templates in a menu so that you can choose from them when creating your note.

    Here’s the template I’ve been using for my captures:

    (setq org-capture-templates
          '(;; other entries
            ("j" "Journal entry" plain
             (file+datetree+prompt "~/personal/journal.org")
             "%K - %a\n%i\n%?\n")
            ;; other entries
            ))
    

    This stores a link to the currently-clocked task and to whatever context I was looking at when I started the journal entry. It also copies the active region (if any), then positions my cursor after that text. Unlike the default template, this template does not include an Org heading. That way, I don’t have to think of a headline, and I can also just clear the buffer and close the window without adding lots of half-filled-in entries in my journal.

    The file+datetree+prompt keyword means that the entries will be stored in ~/personal/journal.org in an outline corresponding to the year, month, and day that I specify. This makes it easy to write an entry for today or for any particular date. For example, I often find myself adding more notes for the previous day (-1) because of something I remembered.

    I’m thinking of making Fridays my day for reviewing what I’ve learned and writing up more notes. With the date-tree structure, it’s easy to review my notes by day and look for little things to harvest.

    If I know I want to revisit something, I can also add a TODO right in the journal entries using the regular Org syntax or as a keyword that I can search for. If it’s a separate heading (ex: *** TODO Take over the world), I can use org-refile to move it to its proper project.

    When I want to flesh out those rough notes into a blog post, I can copy the entry to my blog post outline, fill in the details, and then use org2blog/wp-post-subtree to post it to WordPress. Alternatively, I might edit my rough notes in-place to make them ready to post, and then post them directly from that buffer (possibly changing the heading).

    Since I’m not always on my personal computer, I need to be able to pull in notes from elsewhere. I can add quick notes to Evernote on my phone. So far, I’ve been okay with copying snippets manually. If I find that I’m creating lots of notes, though, I might look into reusing the code that I have for building my weekly review list from Evernote notes.

    Time-wise, I find that spending 15-30 minutes at the end of the day helps me braindump the key points. If I take little writing breaks throughout the day, that helps me capture more details (especially in terms of development or technical troubleshooting). Re-reading my notes is part of my regular weekly review process, so it’s pretty quick (plus a little more time if I’m writing longer blog posts).

    That’s how Org Mode helps me keep a process journal. It’s great to be able to quickly write notes in the same thing you use to do everything else, and to tweak your workflow. Whee!

    Figuring out how my temporary sleep schedule interacts with programming, writing, and drawing

    November 26, 2014 - Categories: kaizen, productivity

    I was thinking about how I can use these snippets of time to improve in programming, writing, and drawing. I realized that although I can easily imagine how other people can write or draw using fragmented time (writers scribbling in notebooks on top of washing machines, artists doodling on the subway), programming seems a lot less tractable. It doesn’t feel like you can break it up and squeeze it into different parts of your day as much.

    It is generally accepted that context switching is evil when it comes to programming. So I’ve been carrying around this idea that Real Programmers are people who can pull all-nighters hacking on tough problems, holding elaborate structures in their heads. Your standard hero programmer stereotype, with the pinnacle being someone either building complex, cool stuff, possibly maintaining large and useful open source software.

    Hence this little mental disconnect. I’m pretty certain I can get there someday if I really want to, but probably not if I extrapolate from current circumstances. Even maintaining a tiny piece of software sounds like more commitment than I want at the moment. (Heck, I might go a few weeks without responding to e-mail.)

    Fortunately, I spent my first few working years in a corporate environment, where mentors showed me that it’s totally possible to be an Awesome Geek while still working a roughly 9-to-5 job, having families and hobbies, and getting plenty of sleep. Thank goodness. So I have this alternate model in my head, not of a Hero Programmer, but rather of solid contributors who keep making gradual progress, help teams of people become more productive, and who enjoy solving interesting challenges and expanding their skills.

    So let’s say that I want to play with my assumption that programming is the sort of thing that’s hard to squeeze into the nooks and crannies of one’s day, at least not the way writing and drawing can. I know that I can go through technical documentation and design resources even if my mind isn’t completely awake, and I can still pick up useful things.

    What is it about writing and drawing that make them suitable even in small doses, and how can I tweak programming? Writers can think about stuff during other activities. I can reflect on ideas while walking or cooking, for example. When I program, I still need more of that back-and-forth with a computer and an Internet connection, but maybe I’ll need less of that as I develop more experience. I can set pen to paper during any spare moment, sketching a quick line and seeing where it takes me from there. I might not be able to do that with implementation, but I can use that same playfulness to explore design. Behavior-driven development makes it easier to break projects down into tiny, clear steps, and have a way of verifying progress (without too much backsliding!). Getting deeper into frameworks and tools will help me do more with less effort when I do sit down at a computer.

    Okay. I can do this. Worst-case scenario, I just move slowly until I get past this particular phase. I’ve seen role models who’ve pulled that off well, so that’s totally cool. Best-case scenario, I figure out how to hack around some of my current cognitive limitations, and maybe that might help other people who find themselves in the same situation too.

    This could work.

    Keeping (financial) score with Ledger

    November 27, 2014 - Categories: finance

    I’ve used Ledger CLI to keep track of my finances since 2005, when I moved to Canada. I like the plain-text approach, and its support for virtual envelopes means that I can reconcile both my bank account balances and my virtual allocations to different categories. Here’s how we use those virtual envelopes to manage our finances separately.

    Every month, I have an entry that moves things from my buffer of living expenses to various categories, including an allocation for household expenses. W- doesn’t ask for a lot, so I take care to be frugal with the difference between that and the cost of, say, living on my own. The way we handle it is that I cover a fixed amount, and this is credited by whatever I pay for groceries. Since our grocery total is usually less than the amount I budget for household expenses, any difference just stays on the tab. I used to write him cheques to even it out, but lately I just pay for the occasional additional large expense.

    Here’s a sample envelope allocation:

    2014.10.01 * Budget
      [Envelopes:Living]  
      [Envelopes:Household]  $500
      ;; More lines go here
    

    Here’s one of the envelope rules set up. This one encourages me to classify expenses properly. All expenses are taken out of my “Play” envelope.

    = /^Expenses/ 
      (Envelopes:Play)  -1.0
    

    This one reimburses the “Play” envelope for household expenses, moving the amount from the “Household” envelope into the “Play” one.

    = /^Expenses:House$/
      (Envelopes:Play)   1.0
      (Envelopes:Household)  -1.0
    

    I have a regular set of expenses that simulate the household expenses coming out of my budget. For example, here’s the one for October.

    2014.10.1 * House
      Expenses:House
      Assets:Household  $-500
    

    And this is what a grocery transaction looks like:

    2014.09.28 * No Frills
      Assets:Household:Groceries  $70.45
      Liabilities:MBNA:September  $-70.45
    

    Then ledger bal Assets:Household will tell me if I owe him money (negative balance) or not. If I pay for something large (ex: plane tickets, plumbing), the regular household expense budget gradually reduces that balance.

    I picked up the trick of adding a month label to my credit card transactions from W-, who also uses Ledger to track his transactions. It lets me doublecheck the balance of a statement and see if the previous statement has been properly cleared.

    It’s a bit of a weird use of the assets category, but it works out for me mentally.

    Using Ledger to track it in this way lets me keep track of our grocery expenses and the difference between what I’ve actually paid and what I’ve budgeted for. If I end up spending more than I expected, I can move virtual money from more discretionary envelopes, so my budget always stays balanced.

    Ledger’s a powerful tool. Pretty geeky, but maybe more descriptions of workflow might help people who are figuring things out!

    Figuring out my own path to awesomeness

    November 28, 2014 - Categories: purpose

    Following up on a previous reflection about working within my current constraints, I was thinking about multiple models of awesomeness.

    • There’s the 10X Hero Programmer idea of someone who can brilliantly cut through the clutter and write just the code that’s needed to solve the problem you didn’t know you had. Awesomeness might involve being able to perceive the true need, bring together different components, and create something solid.
    • There are architects and team enablers who can work within organizations (both formal and informal) to make bigger things happen. Awesomeness might involve balancing multiple trade-offs, keeping track of complex structures, and using soft skills to get stuff done.
    • There are people who envision products and services, bringing them to the people who need them. They might create things themselves, or they might invest in forming a team to create things.
    • There are people who create bridges for other people so that they can get started or they can develop their skills. Awesomeness might involve presenting things in a clear, logical, inspiring, and useful manner. Plenty of role models doing cool stuff in this area, and lots of ways to grow.

    Oh, that’s interesting. That makes sense to me. I can see myself growing into that last one. It fits the things that tickle my brain.

    I don’t have to worry about doing Clever Things or Big Things. As I get better at doing what I already enjoy doing, sharing what I’m learning and helping other people along the way, I’ll find my own path to awesomeness.

    Weekly review: Week ending November 28, 2014

    November 30, 2014 - Categories: review, weekly

    Okay! My brain is slowly returning to normal, I think. =) I might even be able to drop by my consulting clients again, go to meetings, and do other things like that. We’ll see.

    Lots of writing time, a fair bit of coding (both for work and for personal projects), and family time too. Some geeking around with W-. It felt like I got a lot done even though I still spent about 40% of the week asleep (average of 10 hours). Yay!

    Blog posts

    Sketches

    Link round-up

    Focus areas and time review

    • Business (22.0h – 13%)
      • Earn (14.7h – 66% of Business)
        • Earn: E1: 1-2 days of consulting
        • Earn: E1: 1-2 days of consulting
      • Build (4.0h – 18% of Business)
        • Drawing (2.5h)
        • Delegation (0.0h)
        • Packaging (0.0h)
        • Paperwork (0.0h)
        • Quantified Awesome
          • Add deletes back
          • Deploy kitchen branch
          • Doublecheck that I can add note fields to a record category
          • Fix bug in saving notes
          • Investigate library renewal error
          • Fix Quantified Awesome registration process
        • Upgrade WordPress to 4.0.1
      • Connect (3.3h – 14% of Business)
        • Emacs Chat: Karl Voit
    • Relationships (5.3h – 3%)
      • Work on E
      • Set up file sharing on router
      • Go to Hacklab general meeting?
    • Discretionary – Productive (18.7h – 11%)
      • Emacs (0.0h – 0% of all)
        • Learn about edebugging macros
      • Writing (17.8h)
    • Discretionary – Play (26.1h – 15%)
    • Personal routines (20.2h – 12%)
    • Unpaid work (4.1h – 2%)
    • Sleep (71.6h – 42% – average of 10.2 per day)