Surf Roots, Software Thoughts

Earlier today I wrote a post describing my difficulties with Aptana, which is an IDE for PHP, Ruby on Rails, and other things.  A few hours after I published my post I was contacted by means of a comment and an email by several people from the Aptana engineering team.  They wanted to know more about my troubles and offered personal assistance.  Are you kidding me?  This is perhaps the most exquisite customer service I’ve ever been witness to.  Not only is the Aptana team willing to help me for free, but they’re also actively searching for bloggers having trouble.  I’m speechless.

Customer service like this makes me want to run down the streets of Seattle skipping and screaming, “Aptana! Aptana!”  Seriously.  Once I get a response I’m going to give Aptana another chance as an environment for running Rails apps - currently I just use it for text editing.

Hats off to you guys, Aptana engineering team.

No comments

This Spring marks the second consecutive year that the Husky Snowboard Team president (me this year, Barry last year) has failed in getting the University of Washington to approve of an on-campus rail jam.  For those of you unfamiliar with rail jams, a rail jam is a type of snowboarding event where professional snowboarders and skiers slide down boxes and rails while spinning and pressing.  Here’s a photo from one of the other campus rail jams:

Last year Barry worked with the Student Activities Office (SAO) to try and get this event approved.  The event management company, Galvanic Designs, was low on funding at that time, so they weren’t able to provide financial support.  The SAO decided that there was not enough incentive for the club to throw this event, so they wouldn’t let us do it.  Fair enough.  “We’ll do it next year!” said Barry and I.  Yeah right …

My portion of this saga started earlier this fall on the second or third week of school.  I went into the SAO office with another officer; we were hoping to throw a jam in the fall.  Our SAO advisor told us to fill out a certain form and to wait for Risk Management to get back to us.  I filled out the form immediately and waited.  I was told that Risk Management usually took three weeks to respond, so I set the event date for a month after I submitted the form.  Three weeks later I get a response from the HUB saying that I filled out the wrong form.  Great.  I filled out the form I was told to fill out, and now it’s too late because Risk Management won’t have enough time to approve the event.  I submitted the right form and pushed the date back.

A few weeks pass, and I get a response saying that they need a contract outlining the responsibilities of the HST and Stevens Pass, the mountain that was planning to throw this event with us.  I draft a contract as best I can and send it off the next day.  I don’t hear anything back, so a week prior to the event date I ping the SAO advisors to see what’s going on.  I basically get a response along the lines of, “Sorry, nothing.”

I’m kinda frustrated at this point, because it’s now December.  I give up on throwing an event in the near future and start working with Galvanic Designs to get an event thrown May 1st.  Galvanic Designs has a great track record - they do campus rail jam tours at tons of other schools including University of Oregon, Oregon State, Washington State, Gonzaga, Colorado University, Denver University, etc.  The have a huge insurance plan, lots of contracts that have already been used by other schools, and in general good experience throwing events like this.  Immediately after requesting May 1st as our date, I send paperwork to the SAO that Galvanic gave me - the same paperwork that got the event passed at all the other schools.  I then take a few months off to let them look through the papers.

I head into the HUB at the start of April to see how things are going.  “Oh, we didn’t receive any documents from you.”  Duuuuude.  I give them another copy right away and give them a few days to look at it.  I ping them a few days later.  “Oh sorry, we haven’t looked at them yet.”  Alright, it’s time to go into overdrive.  Dan, the cofounder of Galvanic Designs, drives up from Oregon to meet me at the HUB.  The two of us drop off a printed and signed copy of the documents at the SAO and at the Risk Management office.  Oh by the way, up until this point, I had never heard from, seen, or knew anything at all about Risk Management.  I envisioned some group of lawyers piled into small cubicles, locked away at some strange corner of the university.  The SAO never let me speak directly to Risk Management, and Risk Management would never respond to me.  Read on …

From here on out, the story stays pretty consistent: I visit the SAO three times a week, ask them how things are going, and once I hear “Oh we haven’t read the documents yet,” I head to the Risk Management office.  Once I get to the Risk Management office, I pick up the phone in front of their locked door and try to speak to one of the officers.  I either get a voicemail and leave a message or I get a, “Sorry, she’s not in right now”  response.  A few weeks pass, and the SAO gives us a date when they’ll have a response for us.  The date comes, and I don’t get a response.  I call them at 4:00pm to see what’s up, and they quickly reply with a flat out “no.”

Now I don’t want to pass judgement on the SAO and the Risk Management office, but it seems to me that they didn’t put an ounce of work into this.  It seems to me that they didn’t want this event to happen, yet they let Dan and I continue to call and stop by, which now I realize was an utter waste of time.  I don’t know.  This frustrates me, but I suppose it’s just how it’s gotta be.  To give the SAO and Risk Management credit, this would have been a HUGE event with lots of responsibilities and lots of mayhem, so I somewhat understand where they’re coming from.  I would also like to point out that I’m not putting blame on any one individual at the SAO or Risk Management office.  I’m instead putting blame on the officers themselves and the processes that they choose to follow.

I tend to try my best to learn from my failures, but I don’t think there is much to learn here.  If anything I’ve learned that it’s important to look for bad signs and quit early, but I don’t like to quit.  Hopefully the president next year will get approval and throw this sucker; I just worry that he or she will waste as much time as I have and as Barry did before me.  Good luck, Husky Snowboard Team president ‘09.  Hopefully the University of Washington will loosen up a little and let the kids jam.

Photo credit: here.

5 comments

When I first launched Best Seattle Bars a few months back, I had worked only shortly on a pseudo PHP controller to support keyword-rich, pretty URLs. The controller also handled the case when a page wasn’t found. In this case, the controller would simply output a 404 message. I thought this was good enough.

About a week after our launch, I did a few Google queries to analyze our search engine performance. I noticed that the only pages indexed by Google were those of the previous version of the site, which was a terrifyingly bad set of informational pages generated by some sort of Yahoo page builder. I was curious why our performance was so poor, so I decided to take a look at Google Tools for Webmasters and ran their diagnostics report. Everything checked except for one thing – I was missing a 404 page. I first thought that Google was wrong – I had a 404 page! It displayed “404!” Then I quickly realized that Google isn’t going to recognize a 404 page by its contents but instead by its HTTP header information. I added the following line of PHP code to my 404 page, and my problems were solved.

<?php header("HTTP/1.0 404 Not Found"); ?>

Having a 404 page is essential for search engine performance, because it allows you to flush out the old pages and perform better with the new ones. Probably a day after I made this change, our search engine performance jumped and traffic was flowing. Usually you get a 404 page for free with Apache or any other web server, but my controller put the handling of 404 into my hands. Make sure you have a 404 page.

No comments

I just made a post on the Redfin Developers’ Blog talking about my 6-month-long effort to choose and implement Bricolage, an open-source content management system (CMS).  This is post one of two; the second post, written by Jason, discusses implementation specifics and will be published shortly.  Take a look at my post here if you’re interested.

No comments

Nearly 12 hours ago I documented the Husky Snowboard Team’s victory at Hope on the Slopes.  Read the post for the whole story, but in summary, 15 of us snowboarded for the majority of 24 hours and took home the title for the team with the most vertical.  We boarded a combined 1.5 million vertical feet.

Now what I didn’t mention was that I was slightly sick going into the competition; I just had a sore throat along with an occasional sniffle.  I fell asleep around 5:00pm yesterday, and here I am, at 3:30am, awake, feeling sick as a dog, and blogging.  I suppose I saw this coming.  Oh well :).

I have a feeling that a good reed is going to like this one.

1 comment

I made a post a week or so ago about how to make a viral site, and I wanted to add to my list of TODOs.

1. Make the registration process easy
   1. Either require as little information as possible or use a social framework like Facebook Platform or OpenSocial

This great blog post describes a usability study that looks at the registration frequency for different types of required information such as email, password, address, etc. Go take a look if you’re designing a registration process.

Update: more here.

2 comments

I spent the weekend at Whistler with 40 members of the Husky Snowboard Team, of which I am the president for. The weekend was absolute mayhem. The days consisted of awesome snowboarding - Matt, Koos, and I made some killer turns on Whistler on Saturday. Sunday was also a good day, but we nearly froze to death in the 20+ mph winds and ~10 degree Fahrenheit temperatures. Saturday night was fun - Matt and I had a night on the town and finished with some fun games at home. Sunday night was probably the most fun I’ve ever had at a bar. 30 of us stormed into the Amsterdam Cafe and took over their outdoor patio. We were all laughing, yelling, and cheers-ing all night. We would pick people out who were walking by the patio and just start yelling at them, “eyyyyyyy,” or “whose house? dawgs house!” or we would chant, “H.S.T. … H.S.T. …” It probably sounds like one of those belligerent, fraternity-esque drunk nights, but it wasn’t (I try not to have those). Everyone around us and all the people we yelled at were laughing and having a good time, and so were we. We took off Monday morning and made it back into the U.S.

You might be wondering why I didn’t say anything about Friday night. The answer is because I’m saving the best story for last. There were four of us in the car, one guy I knew, call him John, and two other guys that I met for the first time that day. I was driving John’s car because mine is in the shop, and we left the University of Washington at about 12:30pm. The car ride to the border was fine - we all got along and had a good time talking about this, that, and the other thing. We get to the Peach Arch at around 3:00pm, and the line to cross the border is pretty short. I ask for my passengers’ passports and get ready for a casual, easy encounter with the Canadian border patrol. Man was I wrong. The woman at the counter was drilling us. “Do you have any weapons?” “Where are you going?” “What are you doing?” “Do you have any alcohol?” “Do you have any weapons?” “Do you have any alcohol?” All of these questions were easy to answer, but she opened a can of worms with the last question, “Have any of you been arrested or convicted of anything lately?” I answer, “No.” John answers, “No.” One of the dudes that I just met answers, “No.” The other dude answers, “Yes.” The woman proceeds to ask him questions about his recent arrest, and through this interview I find out that this guy had been arrested for possession of marijuana about a year ago. The border patrol gets out a bright orange slip, writes some info on the card, and tells us to go inside.

There’s a pretty long line when we get inside, and the spirits of most people are definitely low. We wait in line until finally we get to the front and begin to get interrogated. The interrogation ends with the woman behind the desk asking me for the keys and requesting that we take a seat. We wait for a pretty long time until finally the border patrol personnel return. They asked us who the owner of the silver bag is, and the dude that got arrested a year ago responds. At this point, I’m thinking, “Shit. He brought weed.” I was right. The guy brought weed across the border and didn’t bother to tell us. Turns out no one got in trouble, not even him, but we had to wait at the Canadian border for three hours. After all of this waiting, they tell us that we have to go back in the U.S. and then back into Canada to proceed to Whistler. Shit.

We spend another 90 minutes waiting in line, getting our car searched again, and getting interrogated at the U.S. border. Luckily the wait to get back into Canada was only 30 minutes, though, making our total time at the beautiful Peace Arch park five hours. On our return back into the states, the border patrol officer knew that we had just been denied entry to Canada. He says to us, “Back so soon. What happened?” We tell him the truth and point to the guy that brought the weed in. The border patrol officer looks at the guy and says, “Why would you bring weed to Canada?! That’s like bringing sand to the beach!” Haha. Jokes on us.

The rest of the drive goes by just fine, and we arrive in Whistler at 11:30pm after leaving Seattle at 12:30pm. What a trip. Oh, and I also got pulled over in Whistler for drunk driving. I was driving slow because I thought the roads were icy, and apparently it looked like I was driving under the influence. I hadn’t had a sip of alcohol all day, so they let us go.

Lesson learned: if you’re driving across the border with people you don’t know, then make sure that they don’t have anything illegal on them. I told all of my passengers not to bring anything illegal, but apparently I wasn’t clear enough. I’m lucky that Canada is very lenient about drugs, otherwise I probably would have gotten arrested even though I don’t smoke weed and didn’t attempt to bring anything illegal into Canada. This was another addition to my bad luck lately, but it was followed by one of the best board trips I’ve ever been on. I’m happy to be back in Seattle.

1 comment

Disclaimer: I totally disagree with the post below, and I’ve written a response to it here.

I’ve published two serious websites: helpd.org and cellarspot.com. Each has a similar success story (there isn’t one), and they were both developed in very different ways. The code we wrote for Cellarspot is super scalable and robust, and the code Eric Fisher wrote for helpd is inline. I wanted to share my thoughts on which engineering approach I think is better and why.

Helpd
The code written for helpd is all inline PHP - the same, single PHP file has SQL queries, HTML, and AJAX request logic. There aren’t any classes, and there are only a few functions to simplify SQL queries. All the engineers out there are probably saying to themselves, “What are these dudes thinking? Idiots.” No. Eric wrote all of helpd in 90 minutes, which let us very easily and quickly test the helpd idea to see if it would take off. It didn’t, so only 90 minutes were wasted (we’re going to try to rework the site, so those minutes weren’t actually wasted). Inline PHP allowed us to throw something up insanely fast to see if the idea would work. Eric and I are both students making websites in our free time, so we want to get things shipped as fast as possible to see who they’ll do.

Cellarspot
The code written for Cellarspot is exquisite and is written in JSP using Spring MVC and Hibernate. We have a data access layer, a business layer, a search framework, and an index framework, etc (see the end of this post for references). We pursued Cellarspot in a software engineering class at the UW, so it was our job to write robust code. We definitely succeeded, but it took five of us three months to complete the site. Five people working an average of about 10 hours a week for three months adds up to 36,000 minutes. That doesn’t even include the first version of Cellarspot I worked on and the newest version I’ve been working on.

So what are the lessons learned here? First, I don’t regret spending so much time on Cellarspot, and the reason why is because I learned a whole lot about software engineering, design patterns, and teamwork by pushing for awesome code. I’m super glad that I learned these skills. However, I’m also super bummed that I invested so much time in Cellarspot only to see it not do well. I’ve thought up two different cases and what I would do in those cases if I were you:

Personal Project Startups
If you’re spending your free time on a project, then your time is valuable. If you’re looking to learn about engineering, then spend time writing awesome code. If you’re looking to create a website that could potentially make you millions, then write something quick and don’t worry about the code. Keep in mind that if your project turns into a 300+ person company and you chose to write shitty code, then the chances of having to rewrite most of your code is high. I suppose there are worse problems, though, like spending hours upon hours on a project that doesn’t go anywhere ;). I think you should also consider your future when deciding on how you’re going to engineer your code. If you’re planning on being an engineer in the future, then spend the time to learn how to write awesome code. If you’re planning on being a PM or someone else more business oriented, then write inline code so you can get your product off the ground quickly.

I think that I should also touch on programming languages. Languages like PHP and Ruby on Rails are great for getting a site up and running quickly. Languages like JSP are great for learning about engineering, but that’s not to say that PHP and Rails can’t be used for good engineering practices.

Funded Startups
If there are more than a few programmers at a funded startup, then write good code. Your peers will appreciate it, and the programmers that will use your code in the future will appreciate it even more. If there are only a few programmers at a funder startup, then you can probably get away with writing bad code, but be prepared to improve it later. I think that if you’re getting paid, then there is no reason why you shouldn’t spend a little extra time to write good, robust code.

I’ve spoken to a few Redfin engineers, and most of them are insanely frustrated and annoyed with the terrible code that was written by some contractors back when Redfin was first started. We’ve had to refactor over and over again at Redfin because of that shit-ass code. I’ll save contractor work for another post, though.

I think that I approached helpd and Cellarspot in the right ways. My first project taught me great programming practices, and my second project made me realize that you shouldn’t always write good code. It’s up to you to decide how you want to engineer your startup.

Software Engineer Resources

• Coding Horror
• Joel on Software
• The Pragmatic Programmer
• Ship It

Update: I removed the “disgusting” adjective from Eric’s inline code. I suppose that I view all inline code as disgusting, even though his inline code was beautiful. The other advantage to writing inline code is that you can avoid dealing with multiple files.  Eric also wanted me to be more precise and say that inline code is great for prototyping, which is exactly what we did with helpd. Sorry about that, Eric!

6 comments

I was driving up to Stevens Pass this Sunday and had an encounter with black ice. I was just driving along listening to music in two-wheel-drive, and I decided to change lanes. The road looked wet, but right when I started turning I lost control and started spinning. My car spun 90 degrees and started gaining traction, so we started heading for the snow bank. I slammed into the snow bank going about 25-30 mph at 90 degrees and went up on two wheels. At this point, I said to myself, “Shit we’re flipping.” I think I also yelled to my passengers, “Hang on!” Before I knew it we were back on four wheels and spinning. We stopped spinning to finish a perfect 360. Holy shit.

I asked my passengers if they were OK, and they said they were. We drove up a little ways to get off the road, and I got out to check the car. I slipped on the pavement while getting out of the car. My car had very little damage and drove away just fine. I have a new respect for Toyota Trucks, and the accident made me appreciate my car even more. I’m glad that my passengers are OK and my truck only sustained small damage, but the experience scared the crap out of me. We had an awesome day at Stevens and a safe drive back. I’m heading to Whistler this weekend, and I’m going to click on four-wheel-drive a little earlier this time ;).

Check these photos out:

4 comments

Check these pictures out. I was turning onto Valley St. from Fairview Ave. N. and got caught in a train track. Here’s the map. I fell so fast that I didn’t even have time to avoid it. I thought I was hitting the tracks at a good enough angle, but I guess I was wrong. I went down and luckily didn’t get run over by the cars behind and beside me. I messed up my handle bars, pedal, back axle, left elbow, and left chin, but me and my bike are fine. What doesn’t kill you makes you stronger, right?

This was definitely an eye-opener for me. I need to be more careful in traffic, and I need to avoid train tracks at all costs. I knew train tracks were bad prior to this accident, but now I understand their true wrath.

Bonus image thanks to Sierra:

2 comments