Monday, September 7, 2009
Thursday, April 23, 2009
On localpolitics.in
Being the social progressives that we are at Hashrocket, we were excited when Obama announced the Martin Luther King Jr Day of Service. Then, when we found out that Sunlight Labs was holding a contest called Apps for America, it was quickly decided that we'd honor the Day of Service and have a hack day to create an app. With a design from local firm Thought & Theory, a number of local tech folks joined us in the orbiting Hashrocket HQ to lay the foundations for localpolitics.in.
Over the course of the next two months, many small tweaks and enhancements were made and a second hack day was held. The final result was submitted to Sunlight Labs on the day of the deadline. On Sunday, we were notified that we had taken an honorable mention for our efforts. All of the sites created were well thought out and executed; I was really excited to see the quality of the work done by other contestants.
Thanks to everyone who helped work on the project. They are:
Wednesday, March 25, 2009
On local radio stations
Today I got followed by @chumley1073, and employee of a local new rock station called Planet Radio (107.3 FM in Jacksonville, Florida).
You see, until recently if you wanted to listen to any new rock in jax, you had to listen to Planet. What changed that fact was the arrival of X 102.9. What was previously an 80s pop station suddenly became the one thing I never expected: a competitor to Planet.
I'm not a very big fan of Planet; the reasons seem like they should go in an unordered list:
Shortly thereafter, I heard their request line announcement. In order to request a song, you must text the song title to them. They apparently don't have a phone line. And then they announced their twitter username (@x1029jax)... followed by their facebook page. Last week they announced a contest you could win by becoming friends on Facebook, and today they asked listeners to friend them on twitter.
All of it makes me think of some random dude sitting in a window-less concrete-walled room recording sound bytes and checking texts, facebook, and twitter... just the type of super-lean operation that can build off of larger Planet's existing ad network. Sure you could advertise on Planet, but why not use those ads they helped you develop on our station for much less?
You can see Planet reacting already to the existence of X 102.9. I heard a kick-ass song, "Sex on Fire" by Kings of Leon, on X 102.9. About a week later I heard it on Planet. It's not the type of music I expect to hear from them. Planet has shot back at X 102.9 with an ad that suggests a puppy dies each time a listener switches to another radio station. And now, an employee of Planet has followed me on twitter. I didn't follow him back; it feels like Planet is just trying to play catch-up.
All in all, it's an interesting play that X 102.9 has made, and I'll be listening to see how it all turns out.
You see, until recently if you wanted to listen to any new rock in jax, you had to listen to Planet. What changed that fact was the arrival of X 102.9. What was previously an 80s pop station suddenly became the one thing I never expected: a competitor to Planet.
I'm not a very big fan of Planet; the reasons seem like they should go in an unordered list:
- Lex & Terry, morning shock-jocks and relationship advisors, prevent me from rocking out in the morning
- The music played was new rock, but it wasn't exactly what I wanted to hear. I like to hear songs that are more frenetic than heavy.
- Commercials. Planet played a lot of commercials.
Shortly thereafter, I heard their request line announcement. In order to request a song, you must text the song title to them. They apparently don't have a phone line. And then they announced their twitter username (@x1029jax)... followed by their facebook page. Last week they announced a contest you could win by becoming friends on Facebook, and today they asked listeners to friend them on twitter.
All of it makes me think of some random dude sitting in a window-less concrete-walled room recording sound bytes and checking texts, facebook, and twitter... just the type of super-lean operation that can build off of larger Planet's existing ad network. Sure you could advertise on Planet, but why not use those ads they helped you develop on our station for much less?
You can see Planet reacting already to the existence of X 102.9. I heard a kick-ass song, "Sex on Fire" by Kings of Leon, on X 102.9. About a week later I heard it on Planet. It's not the type of music I expect to hear from them. Planet has shot back at X 102.9 with an ad that suggests a puppy dies each time a listener switches to another radio station. And now, an employee of Planet has followed me on twitter. I didn't follow him back; it feels like Planet is just trying to play catch-up.
All in all, it's an interesting play that X 102.9 has made, and I'll be listening to see how it all turns out.
Saturday, March 21, 2009
On vim targets
It must be noted that my first experience at Hashrocket with vim was a few weeks pairing with Tim Pope (the dude who wrote the rails.vim plugin you should be using) on a rescue mission. I didn't touch the keyboard for three days - that's how many hours of watching the man operate it took me to absorb the ridiculously awesome things he was doing. Credit for nearly all of my vim knowledge goes to him. The rest goes to the other Rocketeers who put up with my continual discussions about how to more quickly achieve line edits.
I thought I might sit down and document some key ways that I interact with vim, and then I realized that would take a couple hours and way more thought than I want to put into a drunken Saturday night. So I decided to talk only about targets instead.
In vim are the concepts of actions and targets. Actions are pretty straightforward and are really only useful when combined with targets. Some actions in vim are listed below for reference.
I thought I might sit down and document some key ways that I interact with vim, and then I realized that would take a couple hours and way more thought than I want to put into a drunken Saturday night. So I decided to talk only about targets instead.
In vim are the concepts of actions and targets. Actions are pretty straightforward and are really only useful when combined with targets. Some actions in vim are listed below for reference.
- d: delete
- y: yank (copy)
- c: change
- v: select
- iw: in word
- t: to the character before the next character entered
- f: to the next character entered
- $: to end of line
- ciw: change in word. Whatever the word under the cursor, remove it entirely and put me in insert mode.
- diw: delete in word. Delete the entire word currently under the cursor.
- ct.: change to the next period. Helpful for changing the name of an object, but not the method called on it.
- ct(: change to the next open paren. Helpful for changing the name of a method.
- df): delete to next close paren. Helpful for deleting entire method calls.
- yiw: yank in word. Yank the entire word under the cursor.
- d$ or D: delete to end of line
- c$ or C: change to end of line
- y$: yank to end of line
Saturday, March 14, 2009
On my first tattoo
Some people have asked why I've got a Hashrocket tattoo on my calf. The reasons are pretty biographical; 'ware ye the history contained herein. Credit for the photo goes to Travis Schmeisser.
Each Wednesday Hashrocket has a midweek get-together called Hashrocket Hot Hackers Hump Day Happy Hour (or 6H). It was a chilly January evening and there were almost a dozen rocketeers milling about at the local martini bar when Sal casually asked if I wanted to go get a Hashrocket tattoo with him.
Of course, inebriated as I was, there wasn't much chance I was going to turn down the idea of getting a Hashrocket tattoo.
Yet, there was a time when I considered tattoos silly things that a person gets to show how edgy he or she is, or to indicate an extreme level of I-will-kick-your-ass. Now I've got one. So why choose to get a Hashrocket tattoo?
I've become quite enamored of Hashrocket since I arrived in Atlantic Beach at the end of March in 2008. I was still a recovering burn-out when I came down here, and somehow Hashrocket refilled my spiritual-coding cup. That sounds extreme, but it's just the way things are.
I spent five years at a county-level government IT shop as a web programmer. I serviced sixteen department websites and also wrote an intranet from the ground up that served 1700 employees while I was there. My boss was lost on anything past FrontPage and for help I had only a string of limited-engagement, part-time assistants of varying levels of skill.
I burned out. Totally and completely. I threw away all of my computer gear and went back to auditing hotels overnight and contemplatively staring at the moon. After about a year, I had the realization that software is what I do, and no matter how burned I felt or how much I wished otherwise, it seemed that was the value I would provide to society.
I began the slow road back to development by working as a part-time webmaster at a non-profit. Then Tiger turned me on to Ruby on Rails, and things started to happen inside of me. A strange sensation that, after experiencing a few times I was able to place: happiness. I was happy writing ruby code. I was happy using the rails framework. Just typing out each line of code somehow made me feel good.
That's how I came to be a Rails consultant in Madison, Wisconsin. My first paid site was completed in November, 2007, and I've never looked back.
When Tiger invited me to come down and see how Hashrocket does things in March of 2008, I was excited to see the magic sauce that had both he and Lark raving about the company. I didn't expect to be offered a job, but I was, and it's been the best thing that's happened to me.
In many of the same ways that ruby and rails took away the pain of coding for me, Hashrocket has taken away the pain of work and replaced it with happiness. Pair programming has made me a more effective and efficient programmer. Communicating all the time has taken away all the bad conversations, because nothing has time to fester. Test-driven development gives me a level of confidence in my code that makes me unafraid to change even systems I haven't looked at in ages. I feel encouraged to excel as an individual rockstar within the community, even on the Hashrocket clock. As Les Hill (in the photo, on the right) is wont to remind us in his blog posts, working at Hashrocket is like attending an ongoing seminar.
All of these reasons, from my discovery of Ruby on Rails through joining Hashrocket and even becoming a presenter at local user groups, this is why I have a Hashrocket tattoo on my calf. If I never have another experience that I want to commemorate with a tattoo, I'm glad I've had this one.
Wednesday, August 27, 2008
On presenting
In high school I was well-known for public speaking. I took a speech class my sophomore year in which we did nothing but present speeches. We held three contests that year, and I took first place in all three contests. That was a dozen or so years ago, though, and I haven't spoken in front of anyone for at least a decade.
As a member of Hashrocket, I've continually been espousing the view that, as leaders in our field, we should be constantly presenting. How can anyone in the field take us seriously if we don't show up in force at conferences, have well-attended talks, and share as much knowledge as possible? Well, this last weekend I had the opportunity to eat my own words and speak at Jax Code Camp, a mostly .Net conference that is looking for some diversity. My co-worker, Rein Henrichs, did me a solid and stepped in for my missing scheduled pair.
In so doing I was able to re-live some rookie mistakes in presenting. Luckily, I also remembered a few skills that saved my ass.
First lesson: keep a local copy of your slides. I didn't have a lot of slides, but the purpose of them was to keep the audience looking at something other than me and to provide the occasional comic relief. I got to the conference and was able to view my Google Docs slides just fine; it was only after I had to switch rooms due to projector issues that I realized my new location didn't have internet access, thus leaving me slide-less in front of a large group of strangers.
My saving grace in this situation? I had created a card with important talking points for each slide I had created. I created a short hand in high school that allowed me to keep key sentence fragments in my head and remember the surrounding sentences easily. With 10 minutes of slides suddenly gone, those cards were the only thing that saved me.
Second lesson: you're going to panic anyway. I spent somewhere between 12 and 16 hours preparing for 20 minutes of talking and 30 minutes of live coding. What did that preparation ultimately net me? 20 minutes of panicking at the beginning of the talk. My hands shook, my voice was querulous, and my eyes darted around frantically without meeting anyone's eyes.
My saving grace in this situation? My cards, again. So long as I was able to focus on putting one word in front of another, I was somehow able to keep from running out of the room screaming. I also asked the group to laugh at me right away, which may or may not have helped settle me down.
Third lesson: bring water! Two very kind souls gave me water during my talk; without them things would have been even rougher (even though I did manage to choke on said water halfway through the talk). The more nervous you get and the more you need to talk, the more crucial water becomes.
The real takeaway from this weekend's code camp wasn't that it was a series of failures; rather it was that despite a series of failures, a success was achieved. Rein Henrichs and I presented the topic together. We ran over the alotted time. We engrossed many people; our talk was standing room only. We extended the Hashrocket brand. We probably convinced some people to use git in their daily development, and we may have even convinced a couple to check out Ruby on Rails.
Now that my decade-long presenting cherry has been broken, look for much more from me.
As a member of Hashrocket, I've continually been espousing the view that, as leaders in our field, we should be constantly presenting. How can anyone in the field take us seriously if we don't show up in force at conferences, have well-attended talks, and share as much knowledge as possible? Well, this last weekend I had the opportunity to eat my own words and speak at Jax Code Camp, a mostly .Net conference that is looking for some diversity. My co-worker, Rein Henrichs, did me a solid and stepped in for my missing scheduled pair.
In so doing I was able to re-live some rookie mistakes in presenting. Luckily, I also remembered a few skills that saved my ass.
First lesson: keep a local copy of your slides. I didn't have a lot of slides, but the purpose of them was to keep the audience looking at something other than me and to provide the occasional comic relief. I got to the conference and was able to view my Google Docs slides just fine; it was only after I had to switch rooms due to projector issues that I realized my new location didn't have internet access, thus leaving me slide-less in front of a large group of strangers.
My saving grace in this situation? I had created a card with important talking points for each slide I had created. I created a short hand in high school that allowed me to keep key sentence fragments in my head and remember the surrounding sentences easily. With 10 minutes of slides suddenly gone, those cards were the only thing that saved me.
Second lesson: you're going to panic anyway. I spent somewhere between 12 and 16 hours preparing for 20 minutes of talking and 30 minutes of live coding. What did that preparation ultimately net me? 20 minutes of panicking at the beginning of the talk. My hands shook, my voice was querulous, and my eyes darted around frantically without meeting anyone's eyes.
My saving grace in this situation? My cards, again. So long as I was able to focus on putting one word in front of another, I was somehow able to keep from running out of the room screaming. I also asked the group to laugh at me right away, which may or may not have helped settle me down.
Third lesson: bring water! Two very kind souls gave me water during my talk; without them things would have been even rougher (even though I did manage to choke on said water halfway through the talk). The more nervous you get and the more you need to talk, the more crucial water becomes.
The real takeaway from this weekend's code camp wasn't that it was a series of failures; rather it was that despite a series of failures, a success was achieved. Rein Henrichs and I presented the topic together. We ran over the alotted time. We engrossed many people; our talk was standing room only. We extended the Hashrocket brand. We probably convinced some people to use git in their daily development, and we may have even convinced a couple to check out Ruby on Rails.
Now that my decade-long presenting cherry has been broken, look for much more from me.
Monday, August 11, 2008
Pairing as a way of life
Hashrocket has a few core philosphies that are essentially required for team members. Agile development processes, an adherence to ruby and rails best practices and idioms, and a firm belief in pair programming are three of the biggies. Of these three, pair programming is the technique that has changed me most, and required the most change in my thinking. And not surprisingly, pair programming has proven the most critical to my success at Hashrocket.
I knew of pair programming before I came down to check out the Hashrocket way. And I even knew some people who personally advocated pairing. But I was that guy. You know, the one who does his best work in the morning with his headphones on and drinking an obscenely large coffee. The guy who types madly for a few select hours a day and, during those few hours, produces as much as regular-speed developers do over the course of a day.
There was definitely a transition period when I would only have a pair for half a day here and there where I was still that guy even though I was with Hashrocket. But ultimately, I have come to realize three distinct situations in which pairing is far superior to working solo that have cemented my belief that pair programming is superior to solo programming.
First, a big part of coding is constantly seeing the big picture. I can't tell you how many times I've sat down to solve a problem and been blind-sided by a particularly difficult routine to write, or maybe a supremely complex data model. Or maybe I find that I have to monkey-patch some existing code. These situations inevitably make me sit and spin my wheels for a minute... sometimes they even made me get up out of my desk and waste some time thinking about solutions. Occasionally I would give up and leave early for the day. With a pair sitting next to me, however, a simple discussion of the situation typically leads to a more obvious solution. In worst case scenarios, we are still more productive by keeping different parts of the solution in each of our heads.
Other times, that obscenely large coffee is just a bit too much and I get going a little too fast. I make simple typos or logic mistakes that I don't catch until I've already started running tests, and then I end up wasting 30 seconds waiting for tests to tell me that I've entered a period instead of a comma. As an over-caffeinated developer, I can't tell you how frustrating these little typos and large amounts of wasted time become. With a pair by my side, it's very rare thing that I get to the end of any line of code without one of us noticing a typo.
The last situation that I've noticed an improvement in development speed while with a pair is after lunch. I don't know about anyone else, but I get very yawny after lunch. So instead of spinning my gears alone and staring off into space, my pair and I typically find myself getting into more code discussions, or letting my pair drive while I keep an eye out for typos. Either way, I'm way more productive than I would be while browsing digg.com.
For all of these reasons, I've become a huge believer in pair programming. And since becoming a believer in pairing, I've found myself extending the idea of pairing to other areas of my life: I pair at the gym with my gym buddy, I have a haircut buddy, and I typically line up my schedules for things like DMV runs with other folks.
But the real reason I wanted to talk about pairing today was my latest pair adventure: presenting. I'll be honest; I think I'm a terrible presenter. There was a time in High School when I won awards for giving speeches. That was almost a decade ago, though, and I'm a little more than frightened about getting in front of a large group of people.
Being at Hashrocket, it's no surprise that I'm surrounded by people way smarter than me. In this situation, having a more senior pair is quite possibly the best thing I could have asked for in my career. And also, being part of a brain trust such as we are, it's only natural that all of us Rocketeers should be presenting at a few conferences a year. And let me tell you, I'm not the only Rocketeer terrified of getting up in front of a crowd.
So my solution: present two topics at once in a stream-lined talk about two different topics. Jax CodeCamp is coming up, and I'm hoping to present a talk discussing distributed development with git and rapid web application development with rails. As a side effect we'll also be discussing pair programming, but that should be in a mostly meta sense. The idea is for one of us to create an application and commit it to a git repo and from then on to ping-pong back and forth, making incremental application improvments and highlighting the uses of git in distributed development while we do so.
The benefits of doing so should be two-fold: first, to show how awesome ruby on rails and git can be, and second to decrease the likelihood that either me or the other speaker will run out of the room screaming.
Wish me luck?
I knew of pair programming before I came down to check out the Hashrocket way. And I even knew some people who personally advocated pairing. But I was that guy. You know, the one who does his best work in the morning with his headphones on and drinking an obscenely large coffee. The guy who types madly for a few select hours a day and, during those few hours, produces as much as regular-speed developers do over the course of a day.
There was definitely a transition period when I would only have a pair for half a day here and there where I was still that guy even though I was with Hashrocket. But ultimately, I have come to realize three distinct situations in which pairing is far superior to working solo that have cemented my belief that pair programming is superior to solo programming.
First, a big part of coding is constantly seeing the big picture. I can't tell you how many times I've sat down to solve a problem and been blind-sided by a particularly difficult routine to write, or maybe a supremely complex data model. Or maybe I find that I have to monkey-patch some existing code. These situations inevitably make me sit and spin my wheels for a minute... sometimes they even made me get up out of my desk and waste some time thinking about solutions. Occasionally I would give up and leave early for the day. With a pair sitting next to me, however, a simple discussion of the situation typically leads to a more obvious solution. In worst case scenarios, we are still more productive by keeping different parts of the solution in each of our heads.
Other times, that obscenely large coffee is just a bit too much and I get going a little too fast. I make simple typos or logic mistakes that I don't catch until I've already started running tests, and then I end up wasting 30 seconds waiting for tests to tell me that I've entered a period instead of a comma. As an over-caffeinated developer, I can't tell you how frustrating these little typos and large amounts of wasted time become. With a pair by my side, it's very rare thing that I get to the end of any line of code without one of us noticing a typo.
The last situation that I've noticed an improvement in development speed while with a pair is after lunch. I don't know about anyone else, but I get very yawny after lunch. So instead of spinning my gears alone and staring off into space, my pair and I typically find myself getting into more code discussions, or letting my pair drive while I keep an eye out for typos. Either way, I'm way more productive than I would be while browsing digg.com.
For all of these reasons, I've become a huge believer in pair programming. And since becoming a believer in pairing, I've found myself extending the idea of pairing to other areas of my life: I pair at the gym with my gym buddy, I have a haircut buddy, and I typically line up my schedules for things like DMV runs with other folks.
But the real reason I wanted to talk about pairing today was my latest pair adventure: presenting. I'll be honest; I think I'm a terrible presenter. There was a time in High School when I won awards for giving speeches. That was almost a decade ago, though, and I'm a little more than frightened about getting in front of a large group of people.
Being at Hashrocket, it's no surprise that I'm surrounded by people way smarter than me. In this situation, having a more senior pair is quite possibly the best thing I could have asked for in my career. And also, being part of a brain trust such as we are, it's only natural that all of us Rocketeers should be presenting at a few conferences a year. And let me tell you, I'm not the only Rocketeer terrified of getting up in front of a crowd.
So my solution: present two topics at once in a stream-lined talk about two different topics. Jax CodeCamp is coming up, and I'm hoping to present a talk discussing distributed development with git and rapid web application development with rails. As a side effect we'll also be discussing pair programming, but that should be in a mostly meta sense. The idea is for one of us to create an application and commit it to a git repo and from then on to ping-pong back and forth, making incremental application improvments and highlighting the uses of git in distributed development while we do so.
The benefits of doing so should be two-fold: first, to show how awesome ruby on rails and git can be, and second to decrease the likelihood that either me or the other speaker will run out of the room screaming.
Wish me luck?
Subscribe to:
Posts (Atom)
