Tag Archives: tools

Vacation Toolbox: Eyefi Card

Eyefi is a really cool idea, add a wifi chip into a standard SD card, so that when you walk into your house, turn on your camera, all your photos are synced to the cloud. During this trip I finally also got the mobile link mode working, where your phone acts as a relay, which meant from Halifax on I was posting pictures up to friends on facebook during the trip.

It does this by starting up a wifi hotspot after the camera has been on for 30 seconds (and hasn’t found a wifi network it knows). You set up that hotspot on your phone, and because the devices are so close, it’s the dominant signal, and your phone auto jumps to it. It pulls down all the photos yet synced, then the AP goes silent, and your phone goes back to normal. Next time you wander onto a wifi network, your phone then relays those up to your chosen cloud sync point (many are supported, including google, facebook, smugmug, flickr, or your own gallery 3 installation).

If you have a camera, you should get an eyefi card. I really can’t imagine going back to having to sync photos through a PC any more.

Tools vs. Process

From Rafe Colburn’s post on Seven signs of dysfunctional engineering teams:

Preference for process over tools. As engineering teams grow, there are many approaches to coordinating people’s work. Most of them are some combination of process and tools. Git is a tool that enables multiple people to work on the same code base efficiently (most of the time). A team may also design a process around Git — avoiding the use of remote branches, only pushing code that’s ready to deploy to the master branch, or requiring people to use local branches for all of their development. Healthy teams generally try to address their scaling problems with tools, not additional process. Processes are hard to turn into habits, hard to teach to new team members, and often evolve too slowly to keep pace with changing circumstances.

You can think of it another way, tools encode behavior in a way that takes away choices. Which is great, because then you don’t have to worry about making the wrong choice. Then you can focus your mental energies on real problems.

Productivity Tip: Learn your tools

At the web design meetup the other day there was a bit of chat about editors afterwards which turned into a normal geek fest of poking fun at each other for our choices. One new truth that came out of this a good editor doesn’t make someone more productive, but it does allow them to become more productive.

Vim vs Emacs

As an emacs guy, that can navigate around in vi reasonably, I’ve was always somewhat surprised that people actually use vi to program. But there are plenty of folks that hold that position, and are as equally surprised that I use emacs. Over the years I tried to look for some common thread. What makes someone choose one or the other, and hold to that choice so firmly. A few years ago I came around to the best predictor. With probably ~ 90% accuracy you can predict which editor a person will use based on what editor their mentor used when they first got serious about computers. People pick up the tools of their ancestors. What looks like free will is basically dictated by heredity.

So, that’s how you figure out which one people use. So, which one is better? The answer to that is simple, whichever one you know the best.

Tools Require Skill

There is this naive assumption that using a “better” editor will make you more productive. The answer is, maybe, but don’t stop there. If you aren’t willing to put in the time to learn how your editor is configured, take time every month to learn a new trick with your editor, give up on either vim or emacs, and go back to gedit. Learning an editor well is going to mean learning how to do very complex activities with complex key strokes. There just aren’t enough keys on the keyboard to be able to do what you want to do without combining them together.

Every couple of months I spend a bit of time to learn a few more emacs tricks. It’s hard for me to even enumerate what these are, because they are just part of my normal workflow, like water. Buffer changing, remote editing, multi language buffers, integrated source management. I am also aware of other things I could be doing, which include interactive debugger control, which don’t warrant the time and skill for me to set them up yet. But I know they are there, and I even know how I would get started in configuring them if I needed to.

Which also brings another point, if your tools themselves aren’t extensible, you will be limited in your growth. I have never met a system that I like 100%, though I’ve met many which did 98% or 99% of what I wanted. This is one of the reasons I’m a really big fan of open source. Couple 98% complete with an easy way to extend it, plus open source so you can really understand what it is doing behind the scenes, and you’ve got a winning combination.

Become Better

tldr; – If you want to be a better programmer, spend a lot of time getting to know your editor.

If you are not already deeply invested in an editor, I’d heartily recommend emacs, fire it up, then hit “F1 t” or from the menus, Help -> Tutorial. It will walk you through an interactive tutorial of basic key commands, including detecting if your local installation has changed any of the keybindings and alerting you appropriately.

If you are already invested in an editor, commit to yourself that you’ll take 1/2 a day a month, for the rest of 2011, and spend that time reading and learning about other capabilities of the editor you are using now. You’ll be a better programmer for it by far by the end of the year.