Pew Pew Laser Blog

Code. Glass art. Games. Baking. Cats. From Seattle, Washington and various sundry satellite locations.

Johnny-Five on tinylab.

8.17.2016

I got my tinylab last week; it's a nifty little prototyping board with an Arduino Leonardo and a bunch of embedded components that was funded on IndieGoGo. So naturally I wanted to get Johnny-Five working and start fiddling with the tinylab as soon as possible. Unfortunately, it seems like the hardest part of every hardware project is the grand upgrading of the softwares that must proceed fiddling. Here's the process that worked for me.

  1. Re-install Node. My Node installation was a few versions old, and somehow npm was missing. So I went ahead and installed Node.js from https://nodejs.org/en/download/. I decided to live dangerously and install the "Current" version rather than the Stable one.
  2. Upgrade Arduino.app. My Arduino install was older than the Leonardo, so I needed to upgrade it too. I got version 1.6.10 from https://www.arduino.cc/en/Main/Software.
  3. Upgrade npm packages. npm outdated showed that several packages (including Johnny Five) were out of date. This required a few rounds of npm update.
  4. Write the Johnny Five code. I checked the excellent Johnny Five docs and wrote this code for the first LED on the tinylab.
    var five = require("johnny-five");
    var board = new five.Board();
    
    board.on("ready", function(){
      var led = new five.Led(13);
      led.pulse(1000);
    });
    This should make LED1 (on pin D13) pulse on an off. At first I tried using "D13" to address the LED (since that's what's silk-screened on the board) but it was just 13 that worked.

Success!

Here is some tinylab documentation that might come in handy next time:

Interviewing a Front-End Developer.

7.28.2016

A while ago, I interviewed for a job with a company that I was absolutely in-love with. I'd been excited to see that they were looking for a front-end developer and I applied right away.

A front-end developer is a highly specialized skill set, and it's pretty different than the skill sets of other types of developers. An experienced front-end developer (I've been doing this for 10 years) is deeply familiar with current HTML, CSS, JavaScript, as well as current browser support and debugging techniques. I know about image compression and optimization, accessibility, content management systems, and even a little about design and SEO. It's a role akin to the kicker or keeper on a football team.

Back to the interview, we'd gone though a few basic questions and the interviewer had moved on to the algorithm questions. It was a little more complicated than Fizz Buzz, but it wasn't too tricky. But I flailed around for a while trying to both understand what the interviewer was asking, as well as trying to logic out the solution. I didn't solve the algorithm easily enough, and I didn't get any further in the interview process.

Why evaluate a front-end developer based on a algorithm? It's such a very small part of the job, and especially over a video conference after a full day of work, and it's the wrong test to get the front-end developer to demonstrate their best. It's like evaluating an NFL kicker based on their tackling skills - sure, they need to do it sometimes, but a proper blocker will always be more skilled at tackles.

How a Code of Conduct Works.

6.29.2016

Bottom line - your events (from meetup to conference) and even your open source projects need a code of conduct. What is a code of conduct?

Let me tell you precisely how a code of conduct works to change interactions during an event.

Last year, I attended a conference as a workshop volunteer. After the workshop, a speaker from the previous day wanted to ask me some follow-up questions about the workshop. While he spoke a little English, he wanted me to step outside to the plaza where his translator was. I agreed.

Let's review the power dynamic here: me = unimportant volunteer, him = very important speaker.

He was from a country where (I suppose), it's common for men to escort women by leading them by the elbow. While we were walking outside, he put his hand on my elbow, and I (being perfectly capable of finding the doors outside) removed it. He again put his hand on my elbow and tried to lead me towards the door. I again removed it, and looked him directly in the eyes and said "no". I then stomped through the doors and found the translator. With the help of the translator, the speaker apologized if he had offended me. I said that I was fine and I answered his questions from the workshop.

Here is how the conference's code of conduct worked: I knew that - regardless of any power imbalance - the conference had my back. I was empowered to enforce my own boundaries and I did so. I was a bit irritated by the incident, but I took care of it myself. Situation resolved, no escalation, no problem. That's how a code of conduct works.

What I'm Looking For in a Talk Proposal.

5.22.2016

I'm curating CSS Day at CascadiaFest, and earlier this month we finished our speaker selection process. Since I've evaluated hundreds and hundreds of proposals for CascadiaFest, I thought I'd share what I'm looking for when I evaluate a talk proposal. At CascadiaFest, our selection process is masked; we do most of the evaluation before revealing the identity of the person who wrote the proposal. Naturally these thoughts are only about my process, and do not represent any other curators or selection committee members.

Setting Up User Styles in Firefox

4.24.2016

While reviewing talks for CascadiaFest, I wanted to find a way to hide comments from other reviewers until after I'd formed my opinion of the talk. I figured this would be pretty easy to do with user styles - the browser's base set of CSS rules that are followed for every site. In Firefox, these styles are stored in userContent.css in your profile folder.

Doing so proved a little more complicated than I anticipated, because Google's search results seem to interpret "userContent.css" as "userChrome.css". As you can imagine, this made it a little difficult to find information on userContent.css. Here are the two references that I did manage to find:

Here is what went into my user styles:

@-moz-document domain(speak.cascadiafest.org) {
  ul.comment-list { opacity: 0 !important; }
  ul.comment-list:hover { opacity: 1 !important; }
}

The @-moz-document domain "selector" allows me to limit these styles to pages delivered from a certain subdomain. I then hid the elements using opacity, and showed them when they were hovered over. Opacity isn't always the best way to hide things with CSS; but in this case I did want the elements to take up space on the page, and for their children to also be invisible. And a user stylesheet is a fine place for !important; I always want that style to apply, even if a higher specificity selector would override it.

After editing userContent.css, you have to restart Firefox for the changes to take effect.

Who to Send to Conferences.

3.22.2016

If you're trying to hire software developers (and who isn't?), then local developer conferences (and even meetups) can be really great recruiting opportunities for you. Mozilla, npm and IBM have done pretty well for themselves at CascadiaFest and JSConf in the last year.

To a degree, this depends on who you send to the event. At a developer conference, attendees probably aren't particularly keen on talking to another recruiter; but many would be open to hearing front line stories about your deployment process or upcoming projects. Send members of your technical teams to developer conferences.

Don't send jerks or dudebros. A few months ago, I was at a SeattleJS meetup and happened to be sitting near two fellows from a large and well-respected company. One of them (who really had enough salt in his hair that he ought to have known better) was fooling around with his skateboard in the office meeting space. He insisted that his colleague "video my kick flips"; and inevitably smacked other peoples' chairs when he lost control of his skateboard. Don't send that person. Send your outgoing and thoughtful developers, who can talk in detail about your organization's work without insulting other technology choices.

Do remember to compensate your people with time off if these events fall outside normal working hours. Your developers shouldn't have to do free recruiting work in their off-hours.

Git Tips - Diff.

2.22.2016

Let's talk about how to refer to previous commits absolutely using a hash/sha; or relative to your working directory, master, or previous commits.

Here's quick reference on some cool things you can do with Git's diff command:

git diff
The standard form of git diff will show all differences between your current working directory and the index (the files that Git is watching and has staged for your next commit).
git diff --cached
Just the differences that you've staged (files added to the index); what you would be committing if you run "git commit" without "-a" option.
git diff --name-only
Show just the names of files that are different between your working directory and the index (last commit). Or, pass in two hashes to compare files from those two commits.
git diff master --name-only
Show all files changed between master and your current working directory. This is great for reviewing what changed files you're actually going to commit.
git diff HEAD
Both staged and unstaged changes in your repo; what you would be committing if you run git commit -all.
git diff HEAD~1
Compare current files to the ones from the previous commit. Also git diff HEAD^ HEAD.
git diff HEAD master [file]
Show differences between the working directory and master for one file.
git diff [hash]
Diff between current and previous commit.

Note that hash is that long string which identifies a commit if you do git log.