Blinky

Fri, 26 Dec 2014 00:00:00 +0000

One of the first projects that I pursued to help teach me the basics of electronics and gizmo-making was a miniature TV-B-Gone. I liked it because it struck a good balance between not being overwhelming to build (it only uses about a dozen components) while still producing some fairly advanced functionality. When I was looking into starting up an electronics/hacker meetup at my school, it immediately came to mind as a great beginner project. I started looking into commercially available kits, and was put off by how they really don't provide a good stepping stone from kit building into DIY projects.

One of the things that has always bothered me about normal "learn electronics" kits is that they're typically very on-the-rails experiences that create a high barrier to entry to making your own stuff - it's a big jump from soldering pre-packaged parts onto a labeled, professionally fabricated PCB to designing and ordering your own similarly-professional hardware. To re-create the Adafruit TV-B-Gone kit from scratch, you'd have to learn how to use EAGLE to edit schematics and design PCBs, then either learn to etch your own PCBs or navigate the confusing landscape of small-run PCB manufacturing services.

I'm attempting to bridge that gap with a "kit" that's made entirely out of off the shelf parts, with no fancy custom-etched PCB or pre-programmed components. Just like a lot of my hobby designs, it's first assembled on a breadboard before being soldered with perfboard. The idea is that a beginner could easily put it together and produce a reasonably polished end result, and then use the same tools & techniques from the kit to start designing their own projects. I'm putting together a number of kits to bring to my school's "hack night" meetings for anyone interested in learning about electronics.

This post was made possible by a grant from the Lewis & Clark Center for Entreprenuership, was inspired in part by this instructable, and owes its existience to Lady Ada & Mitch Altman's open-source TV-B-Gone code and schematics.

The rest of this post will walk you through building the kit, which I've named "Blinky". In the end, you'll have a micro-sized TV-B-Gone clone that will fit inside an Altoids smalls tin and can turn off nearly any TV at a range of 15-20 feet.

Parts & Tools

To build a Blinky, you will need the following parts:

1 × ATtiny85 Microcontroller (link)
1 × 8-Pin Component Socket (link)
1 × CR2032 3v Coin Battery (link)
1 × Coin Battery Holder (link)
1 × 8MHz Ceramic Resonator (link)
2 × PN2222 NPN Transistors (link)
1 × 220µF Capacitor (link)
1 × Green Indicator LED (link)
1 × Wide-Angle IR LED (link)
1 × Narrow-Beam IR LED (link)
1 × Slim Tactile Switch (link)
4 × 150Ω resistors (link)
2 × 47Ω resistor (link)
1 × Small Mint Tin Sized Prototype Board (link)
1 × Altoids Smalls Mint Tin (link)

I've put together a BOM so you can order all of the electronic components in one go here.

You will also need the following tools:

Soldering Iron (with holder & wet sponge) (link, cheaper option)
Solder (link - you can also use lead-free solder, but it makes it a bit tricker)
Needle-Nosed Pliers (link, cheaper option)
Flush Cutters (link, cheaper option)
Multimeter (link, cheaper option)
Breadboard (link)
Assorted solid-core wire (22 gauge recommended)
Coin Cell Breadboard Breakout (link)
AVR Programmer (link)
AVR ISP Breadboard Adapter Kit (link)

The following items are optional, but helpful:

Wire Strippers (link)
Third Hand Tool (link)
Vise (link)

Programming Part 1: Wiring

If you're using a kit you got from me or at a Hack Night event, your ATtiny is pre-programmed. You can skip straight to the Building & Testing on a Breadboard section.

This project works by using a microcontroller to send out a whole bunch of TV "off" signals. However, the microcontroller you just bought is blank - it doesn't have any code or TV "off" signals programmed into it yet. We'll use the AVR programmer along with some open-source code to program the microcontroller to send out TV codes whenever it is reset.

The first step is to set up the circuit for programming. We'll do this using a solderless breadboard. If you've never encountered a breadboard before, now would be a good time to review SparkFun's excellent solderless breadboard tutorial. Go ahead, I'll wait.

The AVR ISP programmer cable has six connections on it. VCC and GND are used to provide power to the chip being programmed. The other 4 are used while programming the chip. We'll need to connect all six in order to set up our programmer. The pinout for these connectors can be found in Atmel AVR Application Note 042, and I've included it below. The Adafruit breakout we're using also happens to have each pin labeled, which is nice.

ISP 6-pin connector pinout

First, put the AVR programming adapter on the breadboard and connect the VCC and GND to the power rails of your breadboard. I like to keep my wiring as flush with the breadboard as possible - it helps with organization. Note the power jumpers at the bottom of the board - I often forget these and then get really confused when my circuit doesn't work because one power rail isn't connected to anything.

ISP power connections

Next, we'll add the ATtiny85 chip. The pinout for this chip can be found in its datasheet. On the physical chip, the top left of the chip (pin 1) will be marked with a small dot. If you plug the chip in backwards, it can fry the chip, so be careful and pay attention to the dot!

ATtiny85 pinout

To get the chip to fit in the breadboard, you'll need to bend the leads a little bit. Use a table or other flat surface to gently bend the leads inward on each side:

Gently bend the ATtiny leads

Plug the chip into the breadboard, paying careful attention to its polarity (the dot in the top left corner), and connect it to the power rails:

Chip with power connections

Next, connect the MISO, MOSI, SCK, and RESET signals to their respective pins on the chip:

Chip with programmer signals

Finally, add the external resonator. This part is used to keep the chip's timing accurate, and we'll need it connected during programming. The resonator has three leads - the outer two need to be connected to the chip's XTAL1 and XTAL2 pins and the inner lead needs to be connected to ground. The orientation of the resonator doesn't matter. With a little bit of sneaky placement, you can accomplish this with a single jumper wire:

The resonator looks like this

Resonator in place

Finally, plug the programmer into the breadboard. Make sure that the red wire is at the top (this shows the polarity of the programming cable).

Ready to program

Programming Part 2: Software

Now that your chip is all wired up and ready to program, it's time to get the programming environment setup on your computer. This will allow your computer to download instructions to the chip via the programmer.

The first thing you'll need to do is install avrdude, an open-source utility for programming AVR chips. On OSX, I do this by installing homebrew, then running brew install avrdude in the terminal. Most Linux distributions also have avrdude available from their package managers. For Windows, you can follow this tutorial to install WinAVR which includes avrdude.

Once you've got avrdude installed, you should be able to run avrdude in your terminal and get a list of all the options that avrdude supports. If you get a "command not found" message instead, go back and troubleshoot/reinstall avrdude.

The next thing you'll need is version 1.1b of the TV-B-Gone microcontroller software. Download it here. (I got it from Adafruit's site).

Unzip the tvbgone11b.zip file you just downloaded somewhere convenient. Inside the directory there are a bunch of files, but the one we care about is tvbgone.hex. This is the compiled version of software, ready to be downloaded to the chip using AVRdude.

Now we'll be actually programming the board. Make sure that your programmer is plugged into your computer and that your breadboard is plugged into your programmer in the correct orientation with the red wire at the top. Then run this command in your terminal:

avrdude -c usbtiny -p attiny85 -U lfuse:w:0xfe:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

This sets the chip to use the external oscillator for timing. You should see a line of output that looks like this:

avrdude: safemode: Fuses OK (E:FF, H:DF, L:FE)

Next, flash the tvbgone.hex file by running this command (make sure to change /Users/qrohlf/Downloads/ to wherever you extracted the folder to):

avrdude -B 1 -c usbtiny -p attiny85 -U flash:w:/Users/qrohlf/Downloads/tvbgone11b/tvbgone.hex

You should see some progress bars and finally some lines of output that look like this:

avrdude: verifying ...
avrdude: 8188 bytes of flash verified

If you see that, you've successfully programmed your ATtiny85 with the TV-B-Gone software and you're ready to start building the TV-B-Gone circuit!

Building & Testing on a Breadboard

Now it's time to wire up our TV-killer circuit. Circuits often come in the form of schematics. A circuit schematic is basically a map of how each part in a circuit gets connected together. Just like street maps, they're a simplified version of reality, and usually don't look much like the physical circuit at all. Here's the schematic for the circuit we're going to build:

The schematic. Click for a larger image.

If you don't understand it right now, don't worry - this page will walk you through building it a step at a time.

We'll be building this circuit on a breadboard first to test it out, then transferring the working design to a prototype PCB. If you skipped the programming section and haven't used a breadboard before, take a moment to read this solderless breadboard tutorial.

If you're continuing from the programming section, remove the ISP header and all of the wires coming from it, leaving only the ATtiny85, power connections, and oscillator. If you skipped the programming section, follow the instructions above to plug the chip into the breadboard and wire it up to the power rails and oscillator. Ignore the MISO, MOSI, SCK, and RESET wires. You should end up with something that looks like this, with pins 4 and 8 connected to power and pins 2 and 3 connected to the ceramic oscillator:

Basic connections

Next, add the battery. Slot the CR2032 coin battery into the breadboard coin cell breakout and plug it in at the bottom of the breadboard. Make sure the switch on the breakout is in the "off" position and wire the pins labeled "Gnd" and "Sw" to the ground and positive power rails on the breadboard:

When the battery breakout is switched on, the battery's positive and ground terminals will be connected to breadboard power rails.

The circuit we are making uses a small green LED to indicate when it's sending out TV codes. Because our circuit is running at 3v and the LED is designed for 2.5v, we'll use a small 47Ω resistor (the one with the yellow-purple-black-gold band pattern) to step the power down (the Ω symbol means "Ohm", a unit used to measure electrical resistance). If you're interested in learning about the calculation I used to get this value, Sparkfun has a pretty good tutorial about LEDs and Ohm's law. LEDs have two leads - one longer and one shorter. For an LED to light up, the shorter negative lead needs to be connected to ground, and the longer positive lead needs to be connected to the positive terminal of the battery.

We'll connect the LED to pin 7 on our microcontroller, since that's where the code we programmed it with expects the indicator LED to be connected. As a reminder, here's the pinout for our microcontroller:

ATtiny85 pinout

When the microcontroller wants to light up the LED, it will connect pin 7 to ground, so we'll connect the negative lead of the led to the pin and the positive lead to the positive power rail. The resistor we're using can either go between the negative lead and the microcontroller, or between the positive lead and the power rail. Since the schematic shows it between the negative lead and the microcontroller, that's where I'm going to put it.

LED and resistor

To make things a bit more breadboard-friendly, I like to put a kink in the positive lead of LEDs with needle-nose pliers, then trim the leads so they're about a centimeter long. This makes the components sit closer to the breadboard, keeping them out of the way while I'm working with other parts of the circuit.

Trimmed leads

Here's the breadboard with the LED and resistor added. Notice how I've re-used the same row that the chip's positive power pin is on to power the LED - this has the same effect as wiring the LED's positive pin to power separately would have, but it uses less space on the breadboard and keeps things a little bit tidier.

Circuit with indicator LED

Next, we'll add the reset switch. This will go between the reset pin (pin 1) on the microcontroller and ground. When it's pressed, the microcontroller will reset and start spitting out TV codes. These switches come with kinked leads - it helps to flatten them out with pliers before trying to plug the switch into the breadboard. Here's what the circuit looks like with the switch installed on pin 1 of the microcontroller and connected to ground:

Circuit with switch

We are now ready to do a basic test of the circuit! Double-check that the ATtiny is plugged in in the correct orientation (with the dot in the upper left corner) and switch on the power from the battery. Then press the switch (just press it, don't hold it down). If you've wired everything correctly, the green indicator LED should start to blink. This means that the microcontroller is ready to send out codes!

If you don't see the indicator LED blinking, double check all of your connections and make sure your battery isn't dead and that it's connected properly by checking the voltage on your breadboard's power rails with your multimeter.

Once you've verified that your circuit works by getting the indicator LED to blink when the reset button is clicked, it's time to add the infrared transmitter. This part of the circuit will send out powerful infrared signals based on input from the microcontroller, turning off any TV nearby by cycling through a bunch of different TV manufacturer on/off codes.

The actual infrared emitters are LEDs like the one we just installed as an indicator light. However, these LEDs emit light in the infrared part of the spectrum that TV remotes use (940nm). They're also a lot more powerful, and unlike the little green LED our microcontroller can't actually handle switching all of the power that they need to activate. Instead, we'll be using the microcontroller to control another more powerful switch called a transistor.

Transistors. I've bent the leads with pliers to help them fit in the breadboard.

Our transistor has three pins, the emitter, the base, and the collector. Like LEDs, the direction of power matters to a transistor. We're going to connect the negative lead of the infrared LED to the collector of the transistor. The transistor base will be connected to the microcontroller, and the emitter will be connected to ground. When the microcontroller tells the transistor to "turn on" by supplying voltage to the base, the transistor will act like a switch and conduct electricity between the collector and emitter. This lets us control a lot more power than we could with just the microcontroller alone.

PN2222 transistor pinout

Pins 5 & 6 on the microcontroller will be controlling our transistors. Connect both pins together with a small wire jumper. Put the transistors in the breadboard and connect each emitter to ground and use a 150Ω resistor to connect each base to pin 6 on the microcontroller. (The resistor performs a similar function to the resistor on the LED, limiting how much power the transistors draw.)

Transistor wiring

The final step is to wire up our infrared LEDs to our transistors. We want our LEDs to point forwards so we don't have to hold our device sideways to point it at a TV. Take your pliers and bend the long (positive) lead of both IR LEDs straight down. Then bend the shorter (negative) lead at a slightly farther distance, so that it parallels the positive lead with about an 0.1" gap between the two leads.

lead-bending is an art

Make a mental note which lead is which and cut the leads even so that you can install the LEDs into the breadboard. Leave the leads fairly long, since this will make soldering easier later on. Connect the positive leads to the positive power rail on the breadboard, and the negative leads to the transistor collectors.

LED wiring

Finally, add the capacitor across the power rails. This will help provide consistent power to the LEDs while they're pulsing at very fast rates. The capacitor has a positive and a negative side, the negative side has a shorter lead and a stripe down it. Connect the negative lead of the capacitor to the negative side of the power rails and the positive side to positive. Again, leave the leads fairly long to help with soldering later.

Power capacitor

You should now be ready to test out your TV-killing "Blinky" gizmo. Find a handy nearby TV (it's got to be the kind of TV that has a remote - a computer monitor or projector won't work), make sure your battery switch is turned on, point the IR LEDs at the TV, and press the button. Within sixty seconds or so, you should see the TV turn off! When it does, you're ready to go on to the next step.

If you're having trouble getting your device to work, you can check and see if your IR LEDs are firing with a digital camera. Point the camera at the IR LEDs and watch the screen while activating the device. You should see rapid-fire pulses of light from the IR LEDS in the camera screen. If you're not seeing these, go back and double-check your wiring. (Note that this won't work with newer iPhones or any other camera that has an IR filter.)

Final Assembly

Coming soon!

Trianglify

Sun, 26 Oct 2014 11:24:00 +0000

Last spring, I wrote my first JavaScript library. In fact, this was probably the first time I'd written anything in JS longer than 30 lines of code, and definitely the first time I'd done it without JQuery. It was called Trianglify, and it generated geometric patterns that looked like this:

It was a small project, and I wrote the initial version in its entirety over the course of a single Thursday. Within two days, it was the most popular piece of code I'd ever written.

While seeing my project go from "one-off-experiment" to trending on GitHub, Hacker News, Twitter, and Reddit was fun, the most exciting thing for me was what happened after the initial surge of traffic wore off. People stopped playing with the demo and they starting using it. There was a version that expanded on my simple demo with more sliders and color control, a remix that pulled in new color palettes from colourlovers, even a fork that used images to get the color mappings. I'd graduated from 'package creator' to 'package maintainer'.

For most people, that's probably not a very exciting transition. If building out new ideas in code is like a sprint, maintaining them is like an marathon with no spectators that never ends. My experience in software development to this point had been as an intern, student, and freelancer - I've never maintained a codebase for more than a few weeks at a time. Now I was doing it in an unfamiliar language, on a project with 3,000+ stars on GitHub.

There's a whole set of skills that are orthogonal to academic coding, but incredibly useful in software development. My users wanted to use Trianglify in Node.js; so I learned about npm, semver, tagging releases in git, and how to write code that would run both on the server and in the browser. I dealt with pull requests and learned how to give good feedback on code contributions. I had to make decisions about browser compatiblity vs. new features. Right now, I'm exploring how to do unit testing properly in Javascript. Overall, I'm certain that I learned more from simply maintaining Trianglify than I did from writing it in the first place.

That's the takeaway here. Maintaining the things that you build is an exercise that can broaden your skill set as a software developer dramatically. That lesson has found its way into my approach to picking side projects, the advice I give to my peers, and the cirriculum for the class I teach.

Portland Startup Weekend: Takeaways

Mon, 28 Apr 2014 09:26:00 +0000

Portland Startup Weekend is an idea that sounds good at first, but when you really think about it is completely insane. Pitching, building, and presenting a business in 54 hours isn't just challenging, it's sheer lunacy. Fortunately, there seem to be quite a few talented entrepreneurs out there who are willing to sacrifice their weekend, their sleep, and their sanity to participate in the madhouse that is Startup Weekend.

This year marked my second time as a Startup Weekend participant. Last year I was a developer on the LivFly team, building a platform for people to find running partners online. I learned a ton from that experience, and this year I pitched Spoke.coffee, a service to deliver local and fresh coffee and other goods straight to customers via bicycle. LivFly received top honors last year as the overall PDXSW 2013 winner, and this year Spoke.coffee took home the award for best customer validation.

To me, Startup Weekend isn't really about the business ideas or even the apps and websites that we build. It's about the experience, and the huge learning opportunity that experience represents. Even if Spoke.coffee doesn't continue past today, I'm 100% satisfied with what it accomplished. Our development team got to experience the process of building a web app from start to finish. Our analysis people cut through all the unknowns to figure out how to model our business and translate those models into strategy-changing insights. Our designers worked on challenging projects with absurdly short turnarounds. And as the team leader, I can unequivocally say that I learned more about how to organize and direct a group with diverse talents in a single weekend than I have learned in three years of traditional college education.

Startup Weekend is about making mistakes and learning from them.

Here are some of the lessons that I've learned after two years of participation.

1. Come prepared

Startup Weekend discourages projects that are already partially implemented, and for good reason - starting from scratch is the best way to learn as much as possible in a single weekend. However, that doesn't mean you can't prepare by planning out what tools your team is going to use to collaborate and build your business.

At LivFly in 2013, we spent the first day and a half trying to find the right tools to build and launch our idea, so this year I researched collaboration and development tools before giving my pitch. From day one, our team was able to build and collaborate smoothly with Google Drive and GroupMe, and start building and shipping our MVP immediately with Sinatra, ActiveRecord, Bootstrap, Stripe, and Heroku. Having that robust stack of tools and technologies pre-selected meant we were able to skip the boilerplate involved in getting a modern team up and running and jump straight to the startup-building action.

2. Front-load the work

Building a business is exhausting, and people do their best work when they're fresh. Last year the whole team at LivFly was exhausted when it came time to hammer out a business model and perfect our presentation - We'd been working late on both Friday and Saturday night, and Sunday were all had short tempers and weren't operating at 100%.

This year, I pushed myself and my team to do as much as possible on Friday night. We stayed up until 3am building our product, and managed to get it finished. Although we were pretty tired when Saturday morning rolled around, having everything built on day 1 meant that we could spend Saturday morning and afternoon doing customer validation, and then go home early and get a good night's rest for Sunday - arguably the most important day of Startup Weekend since it's when teams actually ship their products and present to the judging panel.

This is an extreme example - building a business in two and a half days is never going to happen in the real world. However, I think that the strategy of front-loading the work carries over into any kind of project - it's far easier to finish something well if most of the hard work is finished early in a project's lifetime.

3. Doing is better than talking

This is the mantra of Startup Weekend – so why am I repeating it here? The answer is that Startup Weekend doesn't always follow its own advice, and it's worth remembering that doing is more important than talking when the fifth volunteer mentor comes by to give your team advice and expects you to drop what you're working on and listen. The Startup Weekend mentors are a great resource, but just like every other resource in a business there is a time and a place for listening to mentors. It's important to remember that the best way to learn is to learn by doing, and the next time a mentor comes by your table wanting to give you more advice it's okay to tell them that you're busy.

We had a problem at LivFly where we listened to every mentor, volunteer, and random person that walked in the door. This had mixed, even contradictory results - even though we had a solid idea of our business model from the beginning, we ended it rewriting it two or three times after being prompted by mentors who often would contradict the previous advice we had just gotten.

The takeaway here is that it's good to have a clear idea of what you're trying to accomplish, and to put as much time and effort into doing that thing while minimizing distractions.

Startup Weekend is dumb - but go do it anyways!

Startup Weekend is a completely unrealistic scenario. 3 days is not enough time to build a sustainable product and business model. The judging pool is typically way skewed towards a certain type of business or enterprise, and the prize packages for the winners are a joke (at least at PDXSW they are).

So, would I recommend participating in Startup Weekend to a friend? Yes, absolutely! It's a great way to learn by experience, and a very rewarding thing to do – long as you go into it with the goal of learning as opposed to winning or starting a real business.

Happy April First

Tue, 01 Apr 2014 00:00:00 +0000

Mischief is an important human tendency. From Arthur C. Clarke's fictional utopia of Diaspar to the royal courts of medieval times, pranksters have always played an important role in society. I myself firmly believe that April Fools' day is an excellent time to tap into some creativity and to come up with ways to make people laugh. In that spirit, I'd like to share a couple of my own creations:

1. Git Push It

inspired by this tweet

Sometimes, you have a coworker whose git commit messages are just missing that extra something. Here's the fix:

In your colleague's git repo, create a commit-msg hook in .git/hooks/commit-msg with the following contents:

#!/bin/sh
echo "http://www.youtube.com/watch?v=vCadcBR95oU" >> "$1"

Now all you need to do is chmod +x .git/hooks/commit-msg and enjoy the fun.

2. Remote-Activated ASCII Star Wars

Say you want to watch Star Wars... but you're doing some important work on your machine. Why not use your coworker's mac to watch it?

The following conditions need to be true for this to work:

The target machine must be running OSX
A user account must be logged in on the target machine
you must be able to ssh into the target machine as the currently logged-in user

To pull it off, ssh into the target and create a starwars.applescript file somewhere with the following contents:

tell application "Terminal" to activate

tell application "System Events"
    keystroke "telnet"
    keystroke space
    keystroke "towel.blinkenlights.nl"
    keystroke return
end tell

Then simply run the script with:

osascript starwars.applescript

May the force be with you!

Atom Initial Impressions

Sat, 01 Mar 2014 09:28:00 +0000

So, Github has a fancy new text editor, Atom. I was lucky enough to get in on the beta, and I've been using it for all of my programming for the last two days. So far, I really like it. The UI is very similar to Sublime Text and uses many of the same key bindings, so it was pretty easy for me to get my bearings. With that said, there were definitely a few annoyances present in Atom in its out-of-the-box state, so I took those as an opportunity to see just how "modern, approachable, and hackable to the core" Atom really is.

Here's the breakdown:

1. Color Scheme

I use the excellent Soda theme for Sublime Text with the Monokai Soda TextMate theme for syntax highlighting. The default syntax highlighting scheme that ships with Atom is, in my opinion, far inferior to Monokai Soda, so the first order of business was to get that installed.

Atom default theme

Monokai soda theme

I was happy to find that Atom supports TextMate themes and provides a utility to convert them into LESS files for use as native Atom themes. This is pretty sweet. So, to install Monokai Soda in Atom, I downloaded the Monokai Soda TextMate theme, pointed my terminal to the directory I extracted it to, and converted it with

apm init --theme ~/.atom/packages/monokai-soda --convert Monokai\ Soda.tmTheme

After that, I popped open Atom's preferences and activated the new syntax theme on the Themes panel. It's worth noting that Atom has graphical preferences in addition to json configuration files for various settings and key bindings. I'm not entirely sure how I feel about this, and I'm interested to see whether community plugins will tend towards using the preferences GUI or letting users specify their preferences in json.

2. Fonts and Font Size

The default font size on Atom is HUGE, and I'm a big fan of Adobe's Source Code Pro for code editing. Fixing both the font size and font family was pretty painless with styles.less:

.tree-view {
  font-size: 11px;
}

.editor {
  font-family: 'Source Code Pro', sans-serif;
  font-size: 11px;
}

3. Cursor Blinking

One of the first things that bothered me when I started using Atom was that the cursor blinks at a slightly faster rate than every other app on my system. It ruined the whole "native app" feel and set me on edge.

The cursor blink period is controlled by a hard-coded value in 'Resources/app/src/cursor-view.js' inside the app package (right click Atom.app, 'Show Package Contents').

The culprit is on line 27:

CursorView.blinkPeriod = 800;

This sets the cursor to complete a full blink cycle every 800ms. The OSX default blink period is 1000ms. Apparently that .2s difference is just enough to drive me absolutely crazy.

As of this writing, I haven't found a good way to configure this value without editing the app's source. Atom has a nice Sublime-esque JSON configuration file, but according to the documentation, there isn't a key to control the cursor blink rate yet. For now, I've just edited cursor-view.js to set the blinkPeriod to 1000ms. This will get overwritten by any updates, but for now there doesn't seem to be a better way to modify the blink behavior.

I also added the following snippet to my styles.less file for a slight fade transition on the cursor (just like Sublime):

.editor.is-focused .cursor {
  transition: opacity .2s;
  &.blink-off {
      visibility: visible;
      opacity: 0;
  }
}

4. Tab Close Icons

The last thing that bugged me about the default theme in Atom was the tab close buttons for modified & unsaved files. They show up as an electric blue outlined circle, which kinda ruins the whole subdued monochromatic thing the theme has going.

Atom default modified close button

My edit

I opted to change them to filled-in circles which match the tab title text color, (again, similar to Sublime). Here's the styles.less snippet:

.tab-bar .tab.modified:not(:hover) .close-icon {
  border: 4px solid #AAA;
  border-radius: 12px;
}

.tab-bar .tab.modified:hover .close-icon {
  color: inherit;
}

Conclusion

As of right now, I'm very impressed with Atom. It's the most polished HTML/CSS/JS desktop app that I've ever used, and it's fantastically hackable. As a web developer who does a lot of front-end work, being able to use LESS and Javascript to hack on my text editor is something of a dream come true, and as someone who uses git for all of my projects the git/GitHub integration is really nice to have.

There's definitely some room for improvement (Atom's soft line wrapping bugged out while I was writing this post, for example), but overall I think that Atom just might become my new favorite editor.

Learn C, Then Learn Computer Science

Sun, 09 Feb 2014 00:00:00 +0000

I'm an undergraduate studying computer science. It's great to get to sink my teeth into interesting, high-level problems like machine learning algorithms and graph theory, but I feel like my formal CS education isn't touching on some of the fundamentals of how computers work and how to write good code.

In his post "Learning to Code vs. Learning Computer Science", Terence Eden raises some excellent points about the importance of learning the algorithms and intellectual principles behind programming. However, while I agree that "no conversation about teaching coding in schools is complete without a theoretical understanding of the science behind the code", I also think that it's important to talk about students' understanding of the mechanics behind the code.

I'm a 3rd-year computer science student with more experience than most. I learned to program in middle school, writing tic-tac-toe programs in TI-BASIC on a graphing calculator. I've also spent three years as an engineering intern at a local computer vision and signal processing company. This puts me in the interesting position of being able to compare what my college computer science/software engineering courses are teaching me versus what my personal explorations and work experience have taught me.

As a first-year CS student at the University of Southern California's school of engineering, my CS-101 professor spent a week or two making sure everyone understood the basics of control structures and C syntax, then jumped straight into a detailed and thorough course on the underlying mechanics of code. All our work was done in C, and we went over how memory was addressed and structured, heap memory vs stack memory, the functions of the preprocessor, compiler, and linker, and fundamental data structures like linked lists. While most of this was review for me, some of it wasn't - as an intern, I had never bothered to think about exactly how pointers functioned at a hardware level, and I'd never implemented any of my own data structures, since they were always provided by a library. I appreciated the chance to re-learn coding from the ground up - but balked when I realized that USC's program would have me grinding on the same kind of relatively low-level mechanics for the first 3 years of my degree. It was a program that would have made me a great coder, but one which would have failed me as a student of computer science.

I ended up transferring to a new computer science program at a small liberal arts school in Portland, OR. I was pleased to find that programming courses at Lewis & Clark were heavy on theory and high-level concepts. I wouldn't have to wait until the second semester of my senior year to take an AI course or study programming language design. But in my classes, I started to notice something odd. In the few courses that were taught using C rather than Java, my classmates would find my code hard to grasp. I got lots of questions about basic C features like structs. This semester I used function pointers in an assignment and later heard them described as "Quinn's magic C voodoo".

This was confusing - my classmates were juniors and seniors who were 3+ years into a computer science degree, yet many of them didn't seem to have an understanding of how computers worked. They could write high-level code and analyze algorithms, but had never used malloc.

It turned out the the two required intro CS courses at my new school only dealt with the very basics of control structures and boolean logic before jumping into high-level object oriented programming in Java. Students writing code in C were told never to use malloc, and didn't have an understanding of the difference between stack and heap variables.

This is the problem with emphasizing computer science over learning to code. Without an understanding of what's happening at a low level, my peers ran into issues like C segfaults and Java NPEs and had no idea what to do to debug them. This is a problem that stems from teaching people computer science but not teaching them how to code. Learning to code isn't just teaching people how to spell - it's teaching people the meaning behind the words. That's why I think "learning to code" is just as important as computer science to teach - and teach well - at an undergraduate level.

404 Page

Mon, 03 Feb 2014 00:00:00 +0000

I decided today that it was past time for me to put together a nice custom 404 page. Here it is:

thrilling.

5 Examples of Great Minimal Jekyll Blog Designs

Sat, 16 Nov 2013 00:00:00 +0000

Whenever I’m embarking on a new design project, I typically start by surfing around to see some examples of how similar sites were designed. It’s a great way to get inspired as well as to inform yourself so that you can make sure your design is unique and memorable when compared to what’s already out there.

A lot has been said already about the merits of Jekyll as a minimalist publishing platform, but for a lot of Jekyll bloggers that minimalism extends to design as well. The handcrafted layouts I ran into while I was designing my own blog were some of the strongest examples of minimal, content-centric design that I’ve seen on the web. The 5 sites below are ones that I keep coming back to for inspiration when I’m working with a text-heavy project and a minimalist aesthetic.

1. Warpspire, by @neath

Warpspire is a great example of how a well-chosen and contrasting color palette combined with good vertical rhythm and typography can make a design pop without images or bright colors. Kyle Neath also has some great posts on design, making Warpspire a great place to get inspiration of all kinds.

2. Sparanoid, by @tunghsiao

Sparanoid makes great use of hover attributes and a high contrast black-and-white aesthetic to create a spacious feel for the site homepage. Each of the posts is customized with a unique background color and heading icon (some examples), adding personality and playfulness to the design while still keeping a very professional and tight layout.

3. Zach Holman, by @holman

Zach Holman's website has a really nice layout that makes the most of large images in the header while still letting the content shine. Zach is another GitHubber, and if you haven't seen any of his talks before you should go check that section of his site out. Not only are his talks interesting and informative, but his slides are great design examples in and of themselves

4. Alex Cican, by @alexcican

Alex Cican's portfolio is a little bit rough around the edges in places, but it makes up for it with great use of images and a creative navigation system that mimics a restaurant menu (click the button in the upper right hand corner). It's a good example of how clean design can still convey a lot of personality.

5. Minimal Mistakes Theme, by @mmistakes

Minimal Mistakes is actually an open source Jekyll theme released by Michael Rose. It's similar in some ways to Zach Holman's site, but the thing that I like about it is how it includes a business card-like section of contact information and a photo next to every page on the site. Not only does the extra column help balance the content on the right, but it also adds a call-to-action to each page - if you like the author's work, a way to contact them is only a click away.

Jekyll is a great blogging platform because of its minimalism - it's simple enough to be convenient to use as well as not get in the way when you're trying to use it slightly differently than it was intended. These 5 examples show how simple software paired with stripped-down design can accomplish great things.

Ruby Whitespace Shenanigans, Hello World Edition

Sat, 19 Oct 2013 00:00:00 +0000

I recently came across this article, which highlights an interesting side effect of how ruby supports Unicode special characters. Ruby treats the Unicode non-breaking space (U+00A0) like any other Unicode special character, meaning it can be used for variable and method names. The article illustrates this with the following code snippet:

def  (  )
      *2
end
 =4
puts

This code outputs 8 when run. It does this by defining a method called nbsp (where nbsp is actually an instance of U+00A0) which takes an argument nbspnbsp and returns nbspnbsp*2. It then defines a variable called nbsp equal to 4 and prints the result of applying the nbsp method to it.

Further Investigation

The author of the above post ends it with a dire warning:

Please don't use this in production code or the Ruby gods will come and haunt you in your sleep.

However, I believe that there is a time and a place for shenanigans, and that it is here and now.

I decided to take the insanity a bit further and write 'Hello World' using U+00A0 and int-to-char casting:

      = 1
      =  + 
      =   *  + 
      =    *  
      = 
      [      *(   +  )+  , 
             =     *    + , 
             =     *    +    -  , 
            , 
            =        +    ,
        *  +    +  , 
        *    -  *    +   +  , 
           , 
           + +  , 
            , 
        *    ,     + +  , 
        ]
puts      .map(&:chr).join

That code snippet will output Hello World if you save it with utf-8 encoding and run it.

(Since your web browser may or may not want to let you copy and paste this into a text editor with the Unicode intact, I suggest downloading a copy from this gist if you'd like to try running it for yourself).

This isn't anything ground-breaking. You can see a non-whitespace version of the program here. I define a variable one as the integer literal 1, then define two, five, and ten using one. The program then creates an array of the ASCII integer values representing the characters of "Hello World", expressed mathematically using the variables one, two, five, and ten. It uses variable definitions inside the array definition to shorten the process. The final line casts the integer ASCII values of the 'hw' array to ASCII characters, then joins them into a string and prints the string to Stdout.

This is, of course, a very quick-and-dirty proof of concept. I'm sure you could optimize this further with some math to find the greatest common divisors of all the decimal representations of the characters of "Hello World" and reduce the number of arithmetic operators needed to create the array. For now, I'm satisfied to leave it as-is, but if you have a better implementation I'd love to see it. My contact info is in the footer.

But Wait - There's More!

U+00A0 isn't the only unusual and invisible character in Unicode. Other notables include text control characters, as well as a whole host of other non-standard whitespace characters in the U+0080 to U+00A0 range. I think I've done enough damage for now and will leave the exploration of what can (but probably shouldn't) be done with these characters for another time.

However, I couldn't resist a quick parting gift:

puts "‮dlroW olleH‭"

is also valid Ruby and will output "Hello World". Here's a gist if you're having trouble running it.

My Personal Project Recipe

Sat, 27 Jul 2013 00:00:00 +0000

It's been a while since I took on a development project purely for personal reasons. My last big effort was excellentresume, a PHP-based system for generating interactive HTML resumes from an XML-based format. It was a fun project that taught me a lot, however I wouldn't really categorize it as a success. I lost interest in the project before I was satisfied with the end result, and I didn't learn as much as I'd hoped about creating RESTful APIs because I never got around to building one for the app. I'd tried too hard to make it reusable and useful for other people, and in the process I sacrificed a lot of simplicity as well as the personality that a resume should have.

With my latest project, Lisst, I set out to build a great self-hosted list writing app. It would use best practices, look amazing, and have a target audience of exactly one person: me. I wanted to avoid the mistakes that had led to me losing interest in excellentresume, so I decided to build it as an iteration of "Where's Quinn", an existing project that I had created a year ago and had been using continuously since I'd finished it.

The old "Where's Quinn" site

"Where's Quinn" was just a static website with a table of all my adventures, written in html & css and updated by hand. I used it to let my family keep track of when I was off the grid, and as a trip log that I could show to people when they asked what I'd been up to lately. This approach was simple, but it had a big drawback: editing the site required an FTP client and a decent text editor, plus I had to type <tr> and <td> a half-dozen times just to add one row to the table.

I had three goals in mind when I started writing Lisst. First, I wanted to dip my toe into web development with Ruby. Second, I wanted to replace "Where's Quinn" with something that I could update easily, from anything with a web browser. Finally, I wanted to challenge myself to build something that was intuitively simple in the same vein as an Apple product or Hemingway novel. This final goal was probably the most ambitious of the three.

"Where's Quinn", now using Lisst

The result of these goals was a project that I found interesting and rewarding. I had the unfamiliarity of a new language to keep me on my toes and shake up some of my old habits, the challenge of trying to build a web application with as little extraneous code as possible, and the motivation of wanting a replacement for "Where's Quinn" to push me through the development snags. While there were definitely some problems with my original goals - I spent three days trying to use a markdown file as a data store because I thought that a database wouldn't be "simple" enough - I credit the success of the project to those three basic goals. They created the right mix of learning, motivation, and creative opportunity to keep me interested in the project, and the direction that they lent to my work led to a useful end-result.

I consider Lisst to be my most successful personal project, and I've spent some time thinking about how to translate that success to future endeavors. While it helped that my goals for Lisst were specific, that specificity also makes them hard to apply to other plans. So, I've come up with another set of three goals to use when I plan a side project, to make sure that it will be interesting, useful, and fun:

1. Have a use, not a use case.

One of the problems that I had with excellentresume was that I had a general idea of what I wanted it to be used for (an online resume for someone applying to jobs in multiple sectors), but I didn't really need that myself, as I was applying exclusively to jobs in the software industry while I was building it. With Lisst, I had a specific site that I used on a weekly basis that I wanted to upgrade with a better, more functional system. This gave me more motivation, more focus, and it helped me differentiate between necessary and extraneous features.

2. Pick a new language/system.

I built excellentresume with PHP because I wanted to get experience building web APIs and thought that using a language that was familiar would make learning easier. Instead, it made working on my project feel a lot like the drudgery I was used to doing with PHP, and didn't end up teaching me very much. Using Ruby for the first time for Lisst felt new and exciting, and I got to discover cool features of the language throughout the project. I got to learn an entirely new language, discover a new ecosystem, and build something useful. I like Ruby enough that I'd consider using it for my next side project, but even if I do I'll be using a framework other than Sinatra because I think a lot of my motivation for side projects comes from the desire to explore and learn about new things.

3. Be ambitious.

While it may not seem like a simple list webapp like Lisst is a particularly ambitious project, it was for me largely because of the goal of simplicity. To that end, I had to implement things I'd never done before like save-as-you-type, a RESTful web interface, and a live demo without a login. Lisst was fun because it was a challenge to build the best list webapp I was capable of, and I like challenges. Being ambitious with my goals for the project helped me push myself and learn more in the process. It kept things interesting.

Now that I have a recipe for making sure my side projects are interesting, useful, and informative, I look forward to trying it out on the next one. If you have any interesting goals or ideas that you incorporate when you're planning a personal project, I'd love to hear about them (you can reach me via @qrohlf or qr@qrohlf.com).