I've created some pretty powerful bookmarks in Firefox to speed up my browsing workflow:
Mozilla Developer Network
Search jQuery Docs
Google - From Within Last Year
Google Cache of Current Page
Search Current Site
Instapaper - Read Later
The bookmarks with URLs as locations just hit those URLs with whatever else you've typed as the
With the "keywords" field, I can execute these bookmarks with keyboard commands (typing into the URL bar). Since new tabs open with focus in the URL bar with Control T, this makes for some pretty zippy workflows. Searching the jQuery docs: Control T, jq [search term] [enter]. Looking up synonyms: Control T, thes [word] [enter].
The keywords are even pretty convenient when I have to involve the mouse. Adding the current URL to my Instapaper list: click into the URL bar and ip [enter]. Pulling up Google's cached version of the current page: click into the URL bar and gcache [enter].
I made this paperweight during an April Blow Your Own event at Art By Fire in 2010. If you've ever wanted to try glassblowing, a quick "blow your own" or mini-class is a great way to test the waters: a professional will walk you through the entire creation of your own "shape of the month" in about 15 minutes. The next day or so, after it's cooled down, you get to take your new glass artwork home!
My goal with this piece was to put a lot of bubbles into it, and I still love the effect. The egg-like shape of the piece was done with an oval shaped block, as opposed to the more common round blocks.
As always, thanks to the husband for the photography.
There have been a few recurring themes of CascadiaJS:
- An important part of the conference has been held up at border. Last year it was the hoodies.
- Food trucks for lunch. Mmmm!
- The conference venue has been in sketchiest location in city. Beware of sketchy dudes!
Sass is cool. It's a CSS compiler adds a ton of "real code" features into your CSS writing workflow. Take a gander at this:
Play with this gist on SassMeister.
This creates a mixin (consider it an object in this case) called
quotenote and then the
blockquote element inherits the default styling from that mixin. The classes
.note also use
quotenote, but also have an argument to add a background image specification. This means changing code only in one place when you want to update the style of several related elements on a site. Here's a Gist and a Meist.
Last year, I completed a job search (which lasted roughly a year) by scoring an awesome new job. Here are some things that I didn't have to do to get a new job:
- Wear make-up or high heels. I did wear a nice business shirt and slacks, and of course I covered the expected grooming. But it's just not necessary for a web developer to dress like a super-model.
- Compromise on salary.
- "Homework" coding samples.
- Redesign my portfolio from scratch. My blog update and résumé content were sufficiently awesome.
One could argue that there was a signaling effect at play here. For example, perhaps I self-selected myself out of opportunities where it was important for the web developer to wear heels. I'm more than OK with that.
Here are some useful
git diff commands:
git diff --name-only
- Show names of files that are different between the index (your watched files) and your last commit. Or, pass in two hashes to compare files from those two hashes.
git diff master --name-only
- Show all files changed between master and your current working directory. This is great for reviewing changes you'll be making when you merge to master.
git show --name-only [sha]
- Show the commit log, and which files have changed in a given hash.
git diff master [filename]
- Show the differences between the working directory and master for the file specified.
I suck at whiteboard interviews. I've been in quite a few interviews in the last few years, and for every time there wasn't a whiteboard session, I got a job offer.
When I was an interviewer, I didn't see a lot of value in a blank whiteboard and a bunch of computer science questions. I wasn't looking for the vaguely useful smart people; I was looking for specialists - people who had done the work I need done before. Thus I would ask how the candidate would solve a given problem, and we'd have a discussion about the answer. This discussion allowed us to cover quite a bit more ground in the same timeframe.
As a candidate, I did discover a few strategies for surviving a whiteboard interview:
- Talk through your thought process as you're working. Sometimes it's more about process and communication than about the solution.
- Use your interviewer as a substitute for Google or Stack Overflow. You know that's exactly what you do when you don't know the answer anyway, and it's exactly what the interviewer does too. Demonstrate that you can find out what you don't know, and engage the interviewer at the same time.
- Find out how the problem you've been given represents what the job will actually entail. This will give you an idea of how much you're actually expected to do on the whiteboard.
- Don't worry about syntax errors; there's no such thing as a whiteboard compiler.
- Start with some pseudo-code, and see if the interviewer wants you to expand it out into something more formal. You'll get a lot more done in the available time.