sacha chua living an awesome life

I’ve been thinking about getting an Android tablet so that I can draw more at conferences and around town. My laptop’s fantastic for drawing and writing, but it doesn’t have the battery life to get me through a day of conference sessions.

Before taking the plunge, though, I considered the different options. If the main thing I want is the assurance that I’ll be able to draw and write for a full day, there are a few ways to do that:

• Learn how to draw on paper. This is somewhat scary, but it’s useful, so I’ve bought myself another sketchbook for mindmaps, sketchnotes, and other sketches. I filled the last one over two years or so, and maybe I’ll fill this one faster!
• Get another battery for my Lenovo X220 tablet, and swap out batteries when needed.
• Get the extended battery slice for my X220 and enjoy way more battery life for some extra weight.

I decided to get the extended battery slice. More precisely, my business decided to get it, because I’m using it for sketchnotes, illustration (I do that professionally now, too!), writing, business correspondence, client meetings, and so on.

The battery slice is a large, flat battery that attaches to the bottom of the laptop. It extends my battery life by quite a bit, and is hot-pluggable so that I don’t have to interrupt my work. I haven’t tested its limits yet, but this power icon is pretty neat to see:

With this, I think I’ll be able to spend more time in libraries, cafes, parks, or conferences. Might be fun. =)

“Why is your window transparent?” a coworker asked me when she noticed my screen. I told her about how I do my CSS theming, and she pulled another coworker over and made me repeat the explanation. Since that seems like something other people might find handy, here it is.

Sass: Syntactically Awesome Sytlesheets

I rarely do CSS/front-end theming work, but when I do, I try to make it as fun and easy as back-end development. I use Sass (Syntactically Awesome Stylesheets) so that I can use nested selectors, variables, and mixins. This makes my code cleaner and easier to write. You’ll need Ruby in order to install Sass, but the tool will give you CSS that you can use on any web platform.

Browser-based tools

I prefer doing the initial tweaking in Google Chrome, because I like the way that the developer tools make it easy to modify the stylesheet. The Chrome CSS Reloader extension is handy, too. Most of the time, I make my CSS changes in the text editor, then use the CSS Reloader to reload the stylesheet without refreshing the page. This makes it easy to manually toggle the display of some elements while allowing me to refresh style rules. If I want to figure out the values for a few simple changes, I’ll sometimes make the changes directly in Chrome (you can use arrow keys to adjust values), then copy the values to my Sass source file.

Colors, sizes, and spaces

A second monitor is totally awesome and well worth it.

Designs rarely specify all the colours, sizes, and spacing needed. To quickly get the color of a pixel, I use WhatColor. This shows the hex code for colors, and allows me to quickly copy the code with the F12 shortcut key. If you want to change the shortcut key, the source is available as an AutoHotkey script.

To make it easier to match sizes and spaces, I use WinWarden to make my browser window 20% translucent. Then I carefully position it over my design reference until the important features match. Magnifixer makes it easier to line things up because it can magnify a fixed portion of the screen. By focusing Magnifixer on the part I’m working on, I can tweak CSS without straining my eyes.

When I know I’m going to be making a lot of changes, I use AutoHotkey to map a shortcut so that I can refresh the CSS with one keystroke instead of several. When I happen to have my USB foot pedal handy, I rig it up to refresh my stylesheet.

Regression testing

Sometimes my CSS changes modify other rules. Instead of laboriously checking each page after changes, I’ve figured out how to use Selenium WebDriver to write a Java program that loads the pages in Mozilla Firefox and Internet Explorer, capturing screenshots and numbering them according to the pages in my design reference. This means that I can run the program in the background or start it before taking a break, and then flip through all the screenshots when I get back.

Cross-browser testing

What’s CSS theming without the requirement of browser compatibility? Someday, when I need to deal with more browsers, I might look into Selenium RC. In the meantime, I develop in Chrome, my Selenium-based program makes it easier to test in Firefox and IE, and it’s easy enough to try the URLs in Safari as well. Virtual machines handle the rest of the requirements. 

So that’s how I’ve been doing CSS theming on this project. What are your favourite tips?

W- picked up the LEGO Indiana Jones game to round out our collection, and we’ve all been enjoying it. The puzzles sometimes take a while to figure out, but like all LEGO games we’ve played so far, they’re never frustrating and the little touches of humour make us laugh.

We started with the episodes for Indiana Jones and the Kingdom of the Crystal Skull. It hadn’t stuck in our memory as much as the previous films, so the game episodes were a little mystifying (although still lots of fun). To help clear things up, I requested the movie from the library. It was a lot more fun than I’d remembered it to be, possibly because of all the jokes we’d remembered from the game. The movie by itself, I don’t know… The movie and the game, yay. =)

We like the LEGO games. The puzzles are easy to solve, but still contain plenty of jokes. Looking forward to getting LEGO Batman 2 when it comes out (and rewatching the movies!).

I spent most of the holiday weekend organizing and backing up my files. I used VisiPics to delete duplicates and lower-resolution copies. I went through the rest to get rid of blurry pictures, and rated the pictures so that I could easily find highlights.

Although hard drive storage is relatively inexpensive, attention costs more, so I was more ruthless when it came to weeding things out. I figured that since we’ve survived thus far without a complete pictorial record of our lives, I’ll be okay even if decades down the line, I wish I’d kept this or that blurry picture of Neko sleeping under the blanket on the couch. No sense in stressing out over storage, or in overloading my ability to organize by insisting on keeping everything.

I burned my archives for 2011 and 2010 onto DVDs so that I could restore the data even if something happened to my hard disk. I also backed up my data to network storage.

With the basics out of the way, it’s time to think about what I want from my archives and how to structure things to make it even easier to work. I care the most about the following categories:

• Blog posts and notes: I want to be able to review my experiences, decisions, and lessons learned.
• Pictures: I want to trigger memories, particularly as I help write family stories. I want to index the pictures by person, so that I can search for combinations of people.
• Drawings, sketchnotes, and mindmaps: I want to trigger memories and lessons learned using sketches. I also want to track my progress, which means chronologically ordering my sketches as well.
• Book notes: I want to be able to review my book notes by topic and annotate them with questions, actions, and follow-up items. I want to slow down and take more notes while reading books, translating them into ways I can improve my life.

Archives are good for recovering data, but I wonder how I can structure things so that I can use the past to make the future even better.

Some ideas for what usefulness might look like:

• A photograph encourages me to write a story, fleshing out the memory more; it might also get me to write that person
• A blog post prompts me to revisit an idea and build on it.
• A decision review leads to better decisions
• Book notes nudge me to follow up on how I’m applying what I’ve learned, and I might reach out to people and tell them about the book

We use Bibble 5 to organize our photos. Bibble has a mode slideshow that can go through more than one slide a second, which is great for rapid review. That might be good for reviewing photographs and drawings to see if any of them trigger a quick memory or feeling. Rotating my desktop background through chosen highlights can also give me a peripheral awareness of faraway family and friends.

For blog posts and decision reviews, my monthly-ish and annual reviews are good for revisiting recent posts. Now that I’ve loaded my archives onto the Kindle, I can also flip through them while waiting.

My scanned mindmaps aren’t as useful for quick recall/addition as I’d hope. This could be because my paper-drawn mindmaps sometimes have text written sideways or upside down (yay for rotating), which is harder to read when I’m flipping through everything in the same orientation. If I stick to writing horizontally and I use bigger, more visual concepts, I can get more of an impression during a quick review. I’ve also used computer-based mindmaps like Freemind. They feel a little different, and I still have to figure out a better way to build mindmapping into my workflow.

Sketchnote-wise, I’ve learned that although OneNote’s infinite scroll of paper is nifty, I like the limits and easy review of a single screen with layers. That’s why I’ve switched to using Autodesk Sketchbook Pro for most of my sketchnotes. They’re much easier to flip through, and I can add them to presentations and yearly reviews easily.

For book notes, slowing down and using a template will help me take better notes from books. It’s not about quantity, it’s about quality. It’s not how much I read, it’s how much I keep (and act on!).

It looks like the key things I can do are:

• Export picture highlights and set them as my desktop background. Print them for extra backup/flipping fun.
• Import my sketchnotes into Bibble and organize them using keywords. Figure out how to set up a slideshow shortcut to review them. I’ll organize them by year, then use metadata to pull different topics together.
• Use Picasa to tag faces in all of my pictures.
• Slow down and take more book notes. Translate books into actions.

How do you get more out of your archives?

I’m working on the stylesheets for a site, which means lots of fiddly little changes.

I decided to make all of my styling changes to my Sass source files instead of editing the attributes in Google Chrome because I found myself forgetting to copy attribute values back from Chrome. Editing the source files directly meant that the changes would be persistent – a slightly slower workflow, but a more reliable one.

I used Chrome to set selected divs to show up with display: block. This meant that I didn’t have to keep triggering hover behaviours myself. Then I used CSS Reloader to reload the stylesheet. Chrome kept my manual attribute changes, like display: block, while applying the new styles. Awesome!

I wanted a quick way to update my browser windows after I saved the file. Saving would automatically trigger Compass’ conversion of the Sass files into CSS, but the browser still used the old stylesheet until I trigged CSS Reloader with F9 or the context menu. I didn’t want to refresh the entire page because that would lose the display: block I’d manually set.

AutoHotkey to the rescue! I wrote a function that saved the current file, waited for Compass to convert the Sass file into CSS, and then used the CSS Reloader shortcut key on all open Chrome windows. This meant that I could have a translucent browser window superimposed on the design PDF for easy comparison (thanks, WinWarden), and an opaque browser window for inspection and navigation.

RefreshStylesheets() {
  Send, ^x^s
  Sleep, 2000
  SetTitleMatchMode, 2
  WinGet, id, list, Chrome
  current := WinExist("A")
  Loop, %id%
  {
    StringTrimRight, this_id, id%a_index%, 0
    WinActivate, ahk_id %this_id%
    WinWaitActive, ahk_id %this_id%,,2
    Send {F9}
  }
  WinActivate, ahk_id %current%
}

Then I mapped it to my foot pedal, just because I could. I didn’t need to take advantage of the 3-way switch, so I mapped all 6 possible functions to RefreshStylesheets.

+F1::RefreshStylesheets()
+F2::RefreshStylesheets()
+F3::RefreshStylesheets()
+F4::Send, +F1
+F5::Send, +F2
+F6::Send, +F3

To make it even easier to fine-tune tiny differences, I installed Magnifixer. I used the “Fixed” mode to magnify the translucent portion I was working on, and I moved the display next to my code. That meant that I could avoid turning my head all the time. I could simply tweak my code, nudge the pedal with my toes, glance at the display (or use peripheral vision!), get it right, and then check the overall view.

Foot pedals are fun. More fun than mapping the shortcut to something like F9 or F12, which would involve taking my fingers off home row and finding a small key. You can literally stamp out bugs.

All this put me in such a good humour that I ended up getting the homepage almost pixel-matched to the specs, except for the limitations on letter-spacing and the adjustments I made for the inconsistencies in the spec layout.

Whee! I can’t wait to use this idea when developing backend code. I’ve played around with Autotest on a Rails project, and it should be a simple matter to write a shell script running selected tests on any project. Fun!

Foot pedal + second monitor = awesome squared.

Yesterday’s coding session with CSS was fantastic. I used WinWarden to make my browser translucent, and I overlaid it on my reference documents. This made it a breeze to check alignment, because I didn’t have to use any measuring tools. I used Chrome’s developer tools to manually adjust the stylesheets until things looked right, adding display: block to the parts I was working with. Then I copied the numbers into my SASS file so that it could generate the CSS.

I also found a GIMP script for exporting all layers as separate images. I had to rename a few layers, but the results made it much easier to flip through images instead of toggling visibility trying to find the logos I needed. (It turned out that the logos were not included, so I’ve asked the design firm to send them to me.)

I converted the complex front page into a Drupal panel layout, getting rid of thirteen regions that were cluttering up the main block management screen. This also makes it much easier to update the content, yay! I’m looking forward to converting other pages. The previous developer used multiple regions instead of controlling visibility through configuration, so there are a lot of templates and regions.

Dual-screen worked out great, too, although I still need to fiddle a little with my ergonomics to make sure everything works out.

I’m looking forward to making this even better. I’ve only got a few more weeks on this project, but I might take on more styling in the future if it turns out I can deal with the headaches associated with cross-browser styling.

After I get the rest of the basic requirements in place, I want to automate testing and screenshots, particularly for regression-checking and for cross-browser compatibility. Selenium and WebDriver look like the way to go if I want to simulate hover events. If I can’t figure out how to use WebDriver within the time I’ll set aside for learning this, I can use JQuery to fake toggling the classes. Automated screenshots + PDF Split and Merge + ImageMagick for compositing (maybe 50% opacity?) will make it easy to spot glaring errors.

That will have to wait for next week. In the meantime, there’s a three-day weekend ahead, so I’m going to make lots of progress on Quantified Awesome. Yay!

Rails is awesome. We built a workflow/reporting system for ~120 users using Rails 3. My part of the project came to about 468 hours, or roughly 60 workdays (~ 3 months), and I worked with another developer who also put in around the same number of hours. We worked with a graphic designer, a CSS/HTML developer, a tester, a project manager, and the client, and we put together a surprisingly large set of functionality.

It’s amazing how quickly the site came together. I built a simple prototype to help the other developer get started with Rails, and we fleshed it out with the client’s input while waiting for the creative design. I started with web_app_theme so that we could have a decent-looking interface for starters. When the client approved the graphic design, another developer sliced it up into HTML, CSS, and images for us. I took those, converted them into HAML and ERB, and we were off and running. Every weekly sprint meant a chance to show off useful functionality and get feedback. It was awesome.

We were initially worried that building all the UIs from scratch in Ruby on Rails would mean taking up more time because we couldn’t use CCK or Views to quickly throw everything together. It turned out that HAML, partials, and semantic_form_for made the forms and reports easy to do. Filtering reports was straightforward with ActiveRecord and scopes. Because we built the screens ourselves, we didn’t have to fight with Views or CCK for the last 20% of tweaking, and I didn’t have to kludge any SQL queries (yay, no views_pre_execute!).

I was working on a Drupal project shortly before this, and I spent some time supporting the Drupal project during this one. Rails made my brain much happier. I felt that I could organize my code more cleanly, and I could test it more thoroughly, too. I didn’t have to fight so much with other people’s modules or themes. I like Drupal, and I’m still looking forward to doing more projects with it. But I wouldn’t mind working on more Rails projects, and I’m glad I’ve got Quantified Awesome as a personal project.

Drupal does many things better than Rails. Drupal modules tend to be more mature and better-documented, and it seems like there’s been more work on scaling Drupal. Internationalization is also more straightforward in Drupal, although Rails I18n is easy to use once you’ve gotten the hang of it. Drupal module dependencies seem a little easier to sort out, too. But Rails is fun!

Tests will keep you sane. This was the first project where we invested in developing a large suite of automated tests. We used Cucumber for high-level tests and RSpec for everything else. The tests caught many regression errors we might have otherwise missed. Test-driven development was fun, too, because the tests gave us tangible progress and simplified checking.

There were times when I gave in to the temptation to commit without running the tests, and I almost always regretted them. (Particularly after friendly finger-wagging from the other developer!)

Issue-tracking rocks. We’ve liked using Rational Team Concert in the past. Getting an externally-accessible instance was complicated, so I set up a Redmine issue tracker as soon as we started the project. We used Redmine to plan work, track bugs, and even collect feedback from the client. As of the time of writing, we had created 766 items and closed 683 of them (89%).

We started with story points, but didn’t end up continuing with them for the rest of the tasks. When we needed to prioritize, we estimated the hours required for each task in order to help the client decide. That worked out quite well. I haven’t tracked item-level time spent, but that seemed to be roughly around my estimates.

I now estimate more time than I used to, because I’ve started factoring in both writing and running tests. It’s a little strange being the pessimistic estimator instead of the optimistic one, but it’s good for the project.

Selenium is great for screenshots, too. Not only is Selenium good for automated browser-based testing of web pages, but it’s also a handy way to capture screenshots for documentation or demos.

Lotus Symphony and Microsoft Word don’t get along. We wasted a few hours trying to update the user guide with the new screenshots, only to find out that the PDF still got screwed up because I didn’t have the fonts the client used. Those fonts were part of Microsoft Office and weren’t on my system. The client took care of updating the user guide so that she could format it the way she wanted, and we focused on code.

Plan with the end in mind. Short projects mean that milestones can sneak up on you before you notice. Half-way through the project, we realized that the project end date was coming Really Soon Now, and we scrambled to put together a launch plan. We wanted to launch a few weeks before the end of the project, to give people time for feedback and updates. That meant that we needed to send pre-launch e-mails one week and two weeks before the launch, which meant… that we needed to start sending those e-mails within a week. Fortunately, the client, IBM PR, and everyone involved managed to get it all sorted out, and we launched.

I like launching. I would like to do more of it. We don’t do it nearly enough on short projects, but these projects are much more likely to launch if we’re around to help with the transition than if only the client is there.

On a related note, I get antsy about adding new functionality before the end of a project. This makes sense, of course. I don’t mind adding new reports and other reading-related functionality, but workflow tweaks are scary. When we’re planning future projects, we can consider similar risks for late-project tasks.

Things I want to improve for future projects:

• More Rails! More!
• More automated tests
• Track time estimates and actual time in order to improve estimation accuracy
• More launch planning
• More blog posts about what I’m learning
• Optimization

Things I want to reduce on future projects:

• Avoid documentation formatting problems – I guess that means Microsoft Office when working with clients who use it
• Must not give in to temptation to skip tests