Tonight I ended up putting together a visual aid for the each and select array iterators in Ruby. I was thinking, how do you show what is happening when you have called each, or select, on a collection? Suppose you are new to programming, or respond more to visual or visceral example than text-based ones? Brief code is elegant and can be beautiful on the page, but there are times when that's not enough, or doesn't match a particular learning style. 

I've had a project like this in my head for a while -- doing an in-depth visual guide for each of the Ruby enumerables and array methods -- as a way of "owning" my own knowledge on each method (as well as getting better at information-design).

Translating shows where you mis-understand the original language, and finding metaphors helps you make connections that are strong and rooted in your own way of understanding. This was a quick sketch and it's rough, but it was pretty fun to do so I wanted to put it out there. We'll see if more comes out of this.  (P.S. The day I can do a good one for inject will be a good day, indeed!). Feedback welcome!

Click here to download:

selecting_squares.pdf (264 KB)

(download)

Click here to download:

selecting_squares.pdf (264 KB)

It's been a couple of weeks since I got back from the first annual Quantified Self conference, in Mountain View California.  This was a gathering of about 400 "quantters": people who self-track and self-experiment, whether by using hardware devices (like the zeo, or fitbit), software applications, or a computer and Excel. Corey and I attended since our web application, MercuryApp, is a life-tracking journal. We wanted to be a part of the weekend, present our work, and meet and learn more about the community. 

Of the 400 people who attended, approximately 100 presented work, led talks, or created a poster about their work. Because of the high ratio of participants, the community feels very alive -- people are actively making things, breaking things, making them again, and working with each other. The attendees were diverse: there were hardware programmers, health policy makers, visual artists, poets, software developers, PhDs and more, all drawn by some aspect of personal science, mood-, health- or life tracking. The diverse range of interests reminded me a bit of the interdisciplinary nature of ITP, where I went to graduate school, and the energy and interdisciplinary nature of the community bodes well for a new field that I imagine will be a household word in a few years. 

Read the rest of this post »

I spent last week at a  four-day-intensive studio on learning to program for the iphone. It was run by Pragmatic Programmers and I recommend it.  I chose to go because I want to learn iphone programming, but wanted guides for what I imagined would be a rocky takeoff, since I was struggling against my own instinctive, initial dislike of the language and platform. (It worked, btw. I'm excited now.)

During the week I learned a lot, and thought a lot about learning. How much initial learning is really just pattern recognition, making sense of a very blurry landscape.  I'm a kinesthetic / experiential learner, for better and for worse, and often my first responses -- be it to people, places, or codes -- are stronger viscerally than cognitively. After a time of looking at something (or being somewhere), things fall into place, but at the beginning it is very much an equal blur that needs to be processed experientially somehow.  

So while this "experiential brain" is poking around, how does the rest of the learning take place? How does it move through to the cognition phase? Being able to process what is meant by the symbols in front of me really doesn't happen until after a "getting familiar" phase, more akin to touching an elephant's leg than learning about his digestive system.  

Imaging that initial learning of a new language is like looking at code with syntax highlighting turned off --  not in your IDE, per se, but in your brain.  

Read the rest of this post »

Hey all, 

Last year I wrote a post about how much I liked standing up by myself.  I'm updating now b/c I lost the original image, and I've been asked about it since.

A couple years ago, I had a period of working from home, alone, and missed the camaraderie & mental organization of my daily group standup.  So I codified my practice and came up with a simple sheet that I would fill in every morning. It had: 

• Date
• Yesterday (what I did yesterday)
• Today Planned (what I plan to do today)
• Today Happened (what unexpected things crossed my path today... usually jot them down as they occur)

I'd then fill it in, stand up, and read it out loud. Oddly enough, it helped me focus, tremendously. 

I later added: 

• Float (a place to note things that need to happen soon, but don't necessarily fit on the top-5 to-do list)

I then went back into the public workplace and brought this with me, filling it out before our daily standup and bringing it with me to each one.  Other people had their own methods, but for me, the act of sitting, then writing WITH A PEN, got a mind-body-organize-and-get-centered thing going on that got me off on the right foot every day. Then I could plunk it on my desk and use it as a to-do list.  Each standup sheet complete's its life-cycle when it's used as input for the next one. 

I've contemplated making a simple web app that handles all this, but it hasn't floated to the top of my priority list yet. Besides, for me at least, brain to hand to pen is really nice circuit.

My printer is on the fritz but I'm attaching a PDF of what I use if you'd like to download it and give it a try. Also, bonus! You can see what I'm doing today as I've attached my standup for the 12th!  

Click here to download:

DailyStandup.pdf (30 KB)

(download)

Click here to download:

DailyStandup.pdf (30 KB)

About six weeks ago, I quit my job. I had a nice, steady, Rails gig here in Chicago that had been a challenge for a while but had gone stagnant. When I was hired, it was clear that their application needed a total overhaul: it had minimal test coverage (less than 20%), the content was difficult to find, and there were a slew of other usability issues from a development and end-user standpoint. They also did not have in-house processes in place for development, having outsourced all development before this time.  

It was a whirlwind year in which we re-allocated in-house resources to redesign the application based on research and need; implemented a daily stand-up meeting; built a development team; rewrote critical parts of the site and streamlined others, and whipped the site into shape, increasing the performance by 100% and the test coverage to 90%. It was a fun time, we had built a strong team, and the company was better for it as they now   have the in-house tools to grow their site as needed.  But, after this was over there wasn't that much left to do; it was rapidly becoming more of a maintenance job.

During this same time, in the summer and the fall, Corey Haines and I started working together to build MercuryApp.com -- an application I'd built a version of for personal reasons a few years back, then let languish.  In a nutshell, MercuryApp helps people make decisions by tracking their feelings over time. We got caught up in developing and got excited about the project.  I was able to go part time at work during the summer and we ended up spending many full days coding and planning. We learned that we work well together and were both excited about the potentials of MercuryApp. We could see a lot of possible uses. Talking to other people we found they would often suggest new ways to use MercuryApp to track different aspects of their lives.

Add these two things, and a few dollars we each had stashed away in savings, and suddenly the idea of working full time on MercuryApp seemed like a possibility. We tried a few avenues for additional funding to avoid hitting our savings, but found we were at too early a stage to attract interest.  It didn't feel like it mattered, though: filling out the applications and practicing "pitching" was helpful. We learned, fine-tuned our ideas about MercuryApp, and thickened our skins. It was fun! And it was fun because we knew that whatever happened, we would take the time to work on the project.

So as I sit here writing, I am entering 2011 from my beautiful home in Rogers Park where we have set up MercuryApp Central: a wonderfully warm and bright office where we work side by side, testing, coding, building, talking.  I feel a huge sense of excitement to be in a space focused on making things and writing code.  No matter what happens with the MercuryApp, I will be the better for it, as every day I am getting up and coding, and creating something I am passionate about. 

The other day we went to the Chicago Bootstrappers Breakfast and met a lot of folks in Chicago who are also on this path. It is invigorating to be around people who are taking small or large leaps to work on their ideas. There are so many developers who have ideas and the skills to implement them.  There was a lot of energy in the room as people shared their own experiences and ideas. I felt proud to be in their company.

For a long time I've been wanting to take a "sabbatical" -- a self-funded year to work on my own projects. This is not the shape of the sabbatical I envisioned -- for one, there's a lot less money saved up, and less time paid for -- but it's the sabbatical that's feasible right now. I'm looking forward to coding, building MercuryApp, growing stronger as a developer, and finding time to explore other aspects of life as well by taking walks, exploring Chicago, relaxing, and doing other types of side-learning (hint: I got an arduino for Christmas!).

I'm using this blog entry to mark where I am in time, and also to encourage people who feel stuck and/or passionate about something to find a way to start working on it. I think doing this will make life more fulfilling and more of an adventure.

Last year, I made my friend Andrew a cake for his birthday. This year, we're going behind the scenes to see how the cake was built.

(download)

Click here to download:

birthday-cake-jv8wnUwnjiTYiyPNWQso.zip (2.55 MB)

This post discusses easy ways to integrate Google Analytics Event Tracking in your website. Event Tracking is a tool that broadens your ability to track user interaction with your website. Prior to event tracking, using Google Analytics gave you rich information about your page views. With Event Tracking you now have a wealth of information about usage on your non-page reloading events such as AJAX calls, hover events, mouseovers -- anything you would like to define and track. (Just make sure you have an account first).

It's dead simple and, after setup, takes a one-line call to a JavaScript method supplied by Google:

pageTracker._trackEvent(category, action, opt_label, opt_value);

You just have to get the right arguments to that method, so you know what you're tracking. In the Google tutorial the example is predicated around sending the arguments to the _trackEvent method inline on an onclick event. Instead of doing that, which will create redundant script tags in our views, let's label our markup in such a way that we can grab a collection of trackable elements via JavaScript and submit them automatically, on a click (or other) event.

Read the rest of this post »

Often times when we use Cucumber and RSpec (and by 'we' I refer to Rails developers, sorry for the narrow focus here), we use them from within a Rails environment.

Here are some instructions on how to set up Cucumber and RSpec for a multi-file Ruby project in a non-Rails environment. Note: if you're here because you want to make your own gem, stop reading and check out jeweler instead. Jeweler will take care of it all for you with one command:

jeweler name_of_gem --cucumber --rspec

If you are not making a gem and just want to bootstrap your own project, here are instructions -- with explanations of what is what. Some may be obvious, but I find that when we are used to using generators it can be easy to overlook what they generate and why. It's the old "the gui made me dumb" syndrome. Therefore, I choose to both err on the side of verbosity in this post and include a link to a bash script that does it for you, at the bottom.

Read the rest of this post »

The process was pretty straightforward, though I went through it twice. I thought a quick write up might be helpful for someone else since there were a couple points that gave me pause.

I bought the Snow Leopard CD from Apple for $29. I decided to reformat my drive entirely rather than simply upgrade -- my mac is coming on three years old, why keep around all that cruft that's gathered over the years.

A few posts I read said you needed restart the computer while holding down "c" with the CD installed in order to reformat: I did not need to do this the first time (when I was still on Leopard). I did need to do this the second time, when I had already upgraded to Snow Leopard and wanted to repeat the process.

Read the rest of this post »

1. It has no story cards or to-dos attached to it -- it's just something you're "taking care of".
2. Alternately, it has one card -- with few or no details. The title of this one card could translate without too much trouble into "Write Big New Feature". If you were questioned about that card you would grudgingly admit that it could be an umbrella for ten or twenty other cards, including things like: figure out what this feature actually does, CRUD all the resources (once it becomes clear what the resources are), and design UI.
3. Other cards or to-dos are left open and unfinished while you "take care of this quick thing". Leaving them open supports the delusion that you're only gone for a second -- to the corner store, as it were, and not fleeing to Argentina to start a new life.

1. The fictional project deadline someone in your company insisted on having set in stone (that is conspicuously about half the time it will take to complete the project).
2. The unfinished tails of "completed" features, e.g., "Yeah, the widget is done! I mean, it doesn't work in Safari yet and the we're gonna change the background image from a gremlin to a frog, but essentially, it's done."
3. The chocolate bar that had no calories because you ate it standing up.