A number of people I know want to learn more about code. People see it as a useful skill, whether they’re dealing with functions and macros in Microsoft Excel, building tools in Ruby or PHP, or playing around with graphics in Processing. I had tea with a designer who’s learning how to code in the process of building a personal project. Since he was there and the code was there, I figured I’d help by answering any questions he had. By the time we wrapped up, he’d solved three of the things he was getting stuck on: limiting queries, working with inline PHP, and using AJAX to dynamically pull in data. Good stuff.

Helping people learn is so much fun. I loved teaching introductory computer science. Even though sometimes it was frustrating, it was such a thrill getting people to those "aha!" moments. I speed-read, so it’s easier for me to skim through Google results and documentation to spot just the right function. I’ve made lots of mistakes, so it’s easier for me to debug things than it is for people who are starting out. Sometimes all people need is a nudge in the right direction, a snippet of sample code, and then they’re off. I get such a kick out of it. It’s high-leverage – a little help can go a long way.

Problem decomposition is a key skill: breaking a challenge down into small, motivating steps, identifying the things you need to figure out first so that you can build on top of them. It’s hard when you’re new, and easier when you’ve solved lots of similar problems. I want to get super-good at this, which probably means doing this with more breadth and depth so that we have more building blocks to play with.

I’m figuring out what I like. I like one-on-one sessions and co-working chats more than group tutoring or teaching a class. I don’t mind looking at someone’s screen using Skype. I’m not an expert, but we can learn together, and I’ve been told that my enthusiasm is infectious.

What could this look like, if I folded this into my experimental life? Maybe it starts with informal coworking in a shared space, helping people while hanging out and doing my own work. (I might have a "Do Not Disturb" / "Open for Helping with …" sort of sign on my laptop.) I’m planning to join HackLab.to in March, after my current consulting gig winds up. (I hope the weather will be nicer by then!) More formally, people might book hour-long sessions in a cafe, coworking space, or library, like the way tutors meet with students. I’d get paid in cash (pay-what-you-can) and/or barter. I could offer virtual help, too – e-mail? Skype?

So there’s this idea of code coaching, for those questions that you can’t ask on Stack Overflow or on mailing lists, and for learning not just a specific thing but also the process of learning it. Shall we give it a try? I’m open to inquiries about Emacs Lisp, PHP, Ruby, Rails, JQuery, Excel functions and reporting tools, AutoHotkey, Bash scripting, and other things people might want to learn.

I’m a little anxious about the impostor syndrome, but I should just get over that. I confess up front: I’m not an expert in any of these frameworks, especially since most of them move faster than I can learn. <laugh> (You won’t believe the kinds of things people are building with Emacs Lisp these days!) I’m always going to be looking things up, because I switch between languages and don’t have all the syntax in my brain. I sometimes have to look up how to do basic control structures like a for loop. And I’ll tell you if I don’t have the foggiest idea how to solve something, but at least I can show you how I’d look for it.

This sort of mentoring is an expected part of teamwork. Who’s done this as an independent? Are there things I should watch out for? Will it hopelessly fragment my brain?

Who’s interested in exploring this with me? How would you value it, and how do we test whether it’s worth it for you and me? Jan/Feb’s busy with consulting, but maybe we’ll see what this looks like in March, or we’ll do low-key coaching for starters…

“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?

I’ve been fiddling with Quantified Awesome, this personal dashboard that I’m building so that I can keep track of what’s going on in my life and use that data to make it even more awesome. For example:

Tracking my time helps me make sure work doesn’t tempt me too much, and that I make time for both personal projects as well as connecting with other people. It also helps me improve my time estimates: How much time does it really take to walk to the subway station? How instant are instant noodles?

It turns out that other people are interested in this too. 21 people have signed up through my “I’ll e-mail you when I figure out how to get this ready for other people” page, and my mom wants to use it too. That’s awesome!

Now I have to go ahead and actually build it so that other people can use it. That’s scary.

And like the way I deal with other scary, intimidating, procrastination-inducing things, I’m going to list my excuses here, so that I can shine a light on those assumptions and watch them scurry away like the cockroaches they are and, if necessary, squishing them with a well-applied flipflop.

Excuse #1: Idiosyncrasy. The way I work might be really weird, and other people may not be able to figure out what to do.

What’s the worst-case scenario? “I have no idea how this works!” I end up with lots of crufty special cases because I can’t figure out how to reconcile different ways of working.

What’s the best case? I adapt the system to the way other people work, and I get inspired by what they do. I build a lovely, flexible web app and API.

Excuse #2: Risk. I’m fine with loading my own data into an experimental system, but if I mess up and delete other people’s data, I’ll feel terrible. Also, they might trigger bugs.

What’s the best case? Regular backups help me recover from any major mishaps, and careful coding avoids more common mistakes.

Excuse #3: Support. I’m going to spend more time handling bug reports and feature requests, and less time building little things that might be useful only for me.

What’s the worst-case scenario? People get annoyed and frustrated because I’m currently focused on other things, like my work.

What’s the best case? I get the system to become mostly usable for people, and I use my discretionary time to build more features. People’s requests inspire me to build more stuff and create more value.

Excuse #4: Documentation. I’ll need to write documentation, or at the very least online help. This means confronting the less-than-intuitive parts of the system. ;)

What’s the worst-case scenario? I describe what currently exists, get frustrated because I want to improve it, and end up cycling between updating documentation and improving the system.

What’s the best case? I describe what currently exists, and end up improving it along the way. I build online help into the system so that it’s easy to change. There’s a blog that helps people learn about updates, too.

Excuse #5: Offline access. A web-based time tracker might be of limited use if you don’t have web access often. I’ve been working on an offline HTML5 interface, but it’s still buggy.

What’s the worst-case scenario? Early testers try it out, but get frustrated because of the lack of offline access.

What’s the best case? I figure out the HTML5 offline thing. Someone else might be interested in building a native app, and we work together on fleshing out an API.

Excuse #6: Impatience. If I bring people on too early, they might get annoyed with a buggy system, and lose interest.

What’s the worst-case scenario? People give it a cursory try, and give up in annoyance.

What’s the best case? Early users are extraordinarily patient. We figure out a minimal viable product for each of them – the simplest thing that could possibly support what they want to do. Over time, things keep getting better and better. Also, I build a decent export interface, so even if people move on to a different system, they’ll still have their data.

Excuse #7: Privacy and control. A bug might accidentally expose people’s information, which is not fun. I also don’t want to have to police the system for objectionable content, considering the thumbnail uploads.

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.

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!

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!

My current project is so different from the others I’ve worked on. Instead of building logic, I’m doing front-end HTML/CSS/Javascript, working from Photoshop layers and design PDFs. I installed SASS so that I could gradually untangle the long strings of selectors my predecessor left me. Reading the code, I have a lot of sympathy for him. I imagine he felt like a fish out of water with both CSS and Drupal. I’m doing reasonably well. I’m not as fast as I am when working on Rails or Drupal back-ends, but I get stuff done. I don’t feel like I’m floundering in the land of “I don’t even know what I don’t know,” like it was when I was working with Microsoft SQL Server 2000 and IIS 5. This one I can handle. Who knows, we might even turn the project around.

I’m learning more about refactoring code, adding CSS3 styles, using Cufon for typography, and dealing with a large number of small changes. AutoHotkey scripts and Emacs macros have been amazing time-savers. On the AutoHotkey side, I’ve been taking advantage of tools like SmallMeasure and WhatColor.

Emacs makes editing lots of PHP files easy. The previous developer used dozens and dozens of node templates instead of using panels or block visibility, and there was a lot of copy-and-paste code. I started moving common parts to files that I could include, but I wanted to make sure that I didn’t accidentally overwrite something he had customized. I grepped the directory for the strings I was interested in. Then I used a keyboard macro to interactively go through each of the files and replace the common text. Win!

I’m looking forward to making my workflow even better. I’ve got a couple of weeks more in this project, and I might work on other CSS theming things in the future. (Good to encompass more of the development pipeline!) Here’s what I’m thinking of trying:

Use the monitor downstairs. Keep code on my laptop, and the browser/reference documents on the big screen.

Make my browser window translucent with WinWarden, and position it so that the browser window overlaps the reference. If I undock the Chrome developer console, that will make it even easier to work.

Deal with IE sooner rather than later, although IE 8 should be reasonably okay.