Hot on the heels of the FamSpam launch only a few short months ago, Chris Wanstrath, Tom Preston-Werner, and I launched GitHub.
I know I speak for the rest of the team that we’re all really excited to see it open to the public after a rewarding beta period that garnered some awesome feedback.
For those wondering what I’m even talking about, GitHub is a hosted code repository made specifically for the Git version control system.
Hosted code isn’t anything new, but we think we’ve created an environment that fosters open source collaboration like never before. You’re also welcome to keep your code private if you’d like.
‘Course you don’t have to take my word for it, have a look at what other people are saying about GitHub
...is for companies that know neither how the internet works nor how to build an interesting product.
(gleaned from personal experience)
I know most of my audience is compromised of web developers so please pay attention:
Unless you’re building a financial application, please do not require me to have a password of more than 4 characters and/or some ridiculous combination of letters and numbers.
Why is the information that you’re storing on your site so valuable that you need to inconvenience me?
Ok, maybe we launched a couple of weeks ago, but we decided to wait until after the holidays to make the official announcement.
Chris and I decided that although Err Free was making decent money, we realized that we weren’t having enough fun, so we built our first product, FamSpam!
In the simplest sense, it lets my mom email all of her children by just having to remember one email: hyett@famspam.com. Each family also gets their own site where they can browse photos and search through conversations, but its main goal is to keep families talking.
FamSpam’s first success story is my own, because I haven’t received an angry phone call from my mom wondering why I haven’t spoken to her in two weeks since we started to use it :-)
We also just launched Dynamite, the Err Free blog, where we’ll be talking about the stuff we’ve learned running a consultancy/startup over the past year. That also includes some interesting code discussions that don’t really belong on Err the Blog.
It’s gonna be a good year.
Sometimes it’s to my chagrin to admit to my Ruby on Rails colleagues that I actually bothered to get my computer science degree. Majoring in linguistics or dropping out halfway through is much more fashionable these days. That feeling isn’t completely unfounded, though. These days, the technologies and concepts that I’m using are things I’ve learned on my own.
That said, I recently stumbled upon a coding practice that I thought was a revelation until I remembered that it was something I was taught in CS101.
I give, what is it?
Write your program on paper first, using the terminal to only regurgitate what you’ve already written.
The computer is a huge distraction, something that should be avoided when you’re brainstorming over important code.
When I’m in front of the screen, I find myself too concerned with getting the program running, getting the feature built, having something pretty to look at, than actually bothering to think if what I’m writing is actually a good idea.
Here’s what happened
The Powerbook I’m currently using has terrible battery life, two hours on a good day. On a five hour flight, that leaves me with a fair amount of downtime. Two hours I could be reading a book, but I’ve always found flights to be incredibly productive because there are no distractions in the air.
On the last flight home, instead of immediately running the laptop’s battery dry, I whipped out my notepad and started jotting bits of code for solving some problems with FamSpam.
<plug>Go sign up for the launch annoucement if you’re terrible like I am with keeping in touch with your family, it’s launching just in time for the holidays!</plug>
A couple of hours later I had rewritten chunks of code three to four times until I was really happy with the solution, one that I know I wouldn’t have come up with had I just been banging away at the keys.
Once I had finally opened up my laptop, I needed only about 30 minutes to have my solution written and fully-tested.
Final thoughts
Again, what I really think it boils down to are those moments of reflection that not being in front of the screen provides you.
Sure, you can sit back and ponder while on the computer, but I find myself constantly saying, “well, what if I just try this.” Applying band-aids to a large gash instead of getting it stitched it up.
Next time you’re heading to the cafe, instead of bringing your laptop, bring your notepad and see what happens. Walking up to the computer with the solution already in hand is an awesome feeling.
See, that CS degree wasn’t complete bullshit.
Programmers are arguably some of the smartest people in the world. We solve complex problems all day, every day, and we’re always hungry for more. We strive to find simplicity in even the most complicated situations. If Eistein were alive today, he’d probably be hacking the Linux Kernel along side Alan Cox during his lunch break.
The issue arises when you take those minds, throw in the impersonality of the internet, and mix in a whole bunch of ego.
Case in point: Vlad the Deployer. It was written as a Capistrano replacement to handle application deployment simpler than the aforementioned project. Make no mistake, the library rocks; I’m using it in production already.
Capistrano certainly became the victim of its own success. It needed to be everything to everyone in the Rails community, because it was the only thing out there that handled deployment with any sort of ease.
Futhermore, its author, Jamis Buck, recently said that its dependencies were written at a different time and place than he’s in now and has been working on rewriting them to remove unnecessary complexity. It takes a big person to admit that his hugely successful application needs a lot of work.
It doesn’t take a big person to rip on an open-source app that has been one of the most useful libraries for Rails since the framework’s inception. Vlad’s authors, the Ruby Hit Squad, have made it some bizarre mission of theirs to insult Capistrano in an attempt to promote their replacement. I have no idea what they’re accomplishing with their tactics (see image above for an example) other than alienating someone that dedicates a portion of his time contributing to a framework that allows them to make their livelihood programming in Ruby.
I’m picking on Vlad, but I’ve seen this time and time again with open-source projects and find the attitude unbelievably off-putting as it reflects poorly on the open-source community as a whole. I’m certainly not immune to bad-mouthing projects that I’m not excited about, but I’d like to think that as the years progress that I’m learning to control the emotions that ran rampant when I was 16.
As the saying goes, “Speak softly and carry a big stick, you will go far.” Let others know about your alternative, but allow the code do most of the talking for itself.
If you need to hone your Ruby chops prior to heading to Berlin for RailsConf Europe check out the Lone Star Ruby Conference in Austin, TX September 7-8. I was digging the city hard after visiting for SXSW and can’t wait to get back there.
Chris and I will be representing Err Free at the conference with talks entitled On Your Best Behavior: BDD in Ruby and I Built this Killer Rails site, Now What?, respectively.
I promise mine will be entertaining, with the large caveat that it’s the first talk on Saturday after what will surely have been a long night of drinking on Friday.
There’s an early-bird registration ending tomorrow night, so if you were at all interested in attending, I’d recommend doing so soon.
While I was at CNET, traffic was growing steadily on our sites, but we had a rude awakening one particular day.
The “Oh Shit” moment
I remember the morning when my boss said to me:
We’re having a conference call in a few minutes with CNET’s SEO dude, we lost half of our uniques starting last Thursday, why don’t you join in.
The first thing I did is wonder what the hell I did wrong, because in the back of my mind, this problem was inevitably engineering’s fault.
The realization that Google owns you
Chowhound was getting 85% of its traffic from Google. It has around 500k topics, averaging 4.5 posts per topic, each an opportunity to become indexed by Google.
This particular week, Google decided to purge its index of stale data, and in doing so, eliminated the majority of the pages Chowhound had indexed, thus slashing our uniques in half. An interesting side-note was that our pageviews didn’t drop nearly as much, because the core users that were still visiting the site had a much higher pageview per visit ratio than the Google visitors.
What we did wrong
The solution was actually quite simple. On every board, we originally used ‘Next’ and ‘Previous’ links that would paginate you to the corresponding page of topics. Straightforward, but horrible for Google’s bots. They’d click a few of the Next links and say the hell with this and move on.
To give you an idea, the Manhattan board alone has over 800 pages of topics, and when Google is only looking at the first three pages, you have a massive problem.
How we fixed it
Simply put, I wrote the will_paginate plugin. Instead of just having ‘Next’ and ‘Previous’, it also displays a window of page numbers that allows bots the ability to navigate hundreds more pages within one click. Now we’re getting somewhere.
Eureka!
As the traffic began to come back in a serious way, well beyond where it was before the dip, the notion of SEO became quite clear to me. Given a site with tons of great content, instead of building more features, you should be trying to leverage what you already have.
This also makes a lot of sense from a financial standpoint. How long would it take your team to build a new feature for 10k more uniques a day, how long would it take them to add meta tags and a sitemap for 10k more uniques a day. There’s no comparison.
The Checklist
SEO isn’t rocket science (unless you’re trying to push the envelope), you just have to be aware of a few guidelines.
Page-specific
- Unique title tag
- Unique meta description (Yahoo is the only one using meta keywords anymore)
- One h1 tag (the text used in your h2-h4 tags is still very important, though)
Site-wide
- Allow only quality outbound links (eg.
rel="nofollow" on all user-generated links)
- Block duplicate content from being indexed with robots.txt
- Structure your CSS so the content can go first
- Consistent navigation that allows bots to get to any page on your site within 2 or 3 clicks
Piece of cake. This discussion can go far deeper than these points, but if you do the stuff above, you’re 90% of the way there. The last 10% is the most time-consuming, so I leave that to you to decide if it’s worth your time.
I know a lot of people think of SEO as a dirty word, and that it conjures up negatives connotations of link-baiting and spam, but that really couldn’t be further from the truth. I’m just going to start calling it FT…Free Traffic.
Speaking of Which
Err Free does more than just Rails, we’d be happy to apply what we’ve learned about SEO to your site. Who doesn’t love Free Traffic?
The Err Free team will be accepting beers at RailsConf for anyone interested, come find us.
Chris will be talking about his acts_as_cached plugin on Saturday. He promised me it’s gonna be good and he’s not one to disappoint.
Also, if you’re going to be in the Bay area after RailsConf, there’s a three hour session on the 22nd concerning whether Rails can scale.
It’s $15, has smart people talking, and there’s an open bar afterwards…need I say more? Check it out.
With all of this talk of the future, I’d be remiss not to mention the other website that I’m apart of that’s been chugging along for almost two years now:
Wayfaring! With the team working at CNET last year we haven’t been able to give it much love, but we did manage to upgrade the Google Maps API to version 2 and even built a version for Land Rover.
Some quick stats:
- 29k users
- 35k maps
- 101k waypoints
It has a very loyal following and its design is still fresh, have a look.
It’s time to put my money where my mouth is based upon what I wrote a month ago regarding optimal ad placement.
The first thing I should mention is I’ve actually reduced the amount of ads since then. There are now only two posts that contain ads. They account for 85% of all incoming traffic, so I see no reason to bother visitors looking at any of my other posts.
Furthermore, I originally had placed two large ads at the top, but I’ve cut it down to just one and floated it to the left. The net effect of these changes is fewer page impressions, but no loss in revenue.
Observant viewers may have also noticed that I’ve added Kontera links to those two posts as well, which has been good for another $15 this month on top of my Adsense revenue.
12,781 pages divided by 27 days is around 473 page impressions per day. Perfect for paying for hosting, but tack on a couple of zeros to that number and suddenly you might just be able to quit your day job based upon how well you can monetize the traffic.
As a forewarning, I’ve been researching and experimenting with all things Adsense, Adwords, and Domaining, so you may see more posts of this nature. If you just want to read about Ruby and Rails, head over to Err the Blog.
Working for a corporation this past year was an invaluable lesson, but there’s only so long I can write things like this:
I can’t begin to express how much that this area fosters entrepreneurship and excitement in all things web. #
and not wonder why I’m still sitting in a cubicle. There was definitely something exciting about using a new technology (Ruby on Rails) inside of a company over 2000 strong, but there’s an extent to how far you can push it and we met our limit.
Chris Wanstrath and I felt compelled to strike out on our own, so we did just that. Err Free is our consultancy where we’re happy to fix all of the things you don’t like about your Rails site. We’re pretty good at what we do, so you may want to take a look.
More importantly, we now have the time and freedom to build sites we’re interested in building and helping improve the open-source projects we love.
Stay tuned for an exciting year and be sure to stop by Err The Blog as always. Better yet, buy me a beer if you’re ever in North Beach.
I run across bizarre IE bugs from time to time, but this one was obscure enough that it bears repeating.
We created a beta site for Chow at beta.chow.com to test out new features and wanted our login cookies to work across both domains, so we changed the existing code to:
cookies[:pk] = { :value => 'foo', :domain => '.chow.com' }
Pretty simple, but we ran into a couple of problems.
The first is that cookies.delete(:pk) won’t work, because you can’t pass options to it which is problem when you’ve set the domain manually.
You can get around this by setting the same cookie with :expire => Time.at(0). Chris wrote a patch to fix this a year ago, but I digress.
A much worse problem is when you’ve set different cookies with a ‘www.chow.com’ domain and a ’.chow.com’ domain.
Firefox and Safari handle each cookie correctly, but IE will use the domain from the cookie it read in last.
This meant any user trying to access the beta site couldn’t get in because IE was using the www.chow.com cookie. This hasn’t been fixed in IE 7 either.
If your curious how something like this would happen in the first place, we set a timezone cookie via javascript (using my Zoned Rails plugin) and set the rest of the cookies within our application code.
I had updated the app code to use the ’.chow.com’ domain, but neglected the javascript thus causing the issue.
I don’t remember the origin, but there’s a quote that has a tendency to pop into my head during situations like the one I encountered this past week. It goes roughly:
I was able to turn my 20 lines of PHP into 2 lines of Ruby in 30 minutes, but then I wasted the next week trying to make it just one line.
I was tasked to build a fairly complex system on
Chowhound. The problem could have been solved just by throwing a lot of code at it. Conditional after conditional, case statement after case statement, easily becoming a mess of code due to its complexity.
Goal-Oriented to Beauty-Oriented
For better or worse, Ruby has moved me away from just accomplishing a goal to accomplishing the goal beautifully. It forces me to accomplish my task in a way that is not just complete, but also simple and elegant.
That doesn’t sound so bad, right? Well, the problem lies in the quote above. When you’re working with extremely talented people, there’s a fair bit of pride/ego involved. Who can write the clearest, most concise code in the least amount of time. It becomes a game you play.
It’s also part of the reason I enjoy what I do. A friend said to me years ago:
Programming is fun, because I get to solve puzzles every day.
I didn’t really believe that at the time during my CS program, but he was spot on.
The problems start when you’re putting in the extra hours for no real benefit. At the end of the day, the site visitor just wants to use the product and they don’t care how it’s built.
Having said that, if you do your best to make your code the best, you’re making it that much easier for the next developer that comes along to understand how it works in the least amount of time.
I’ll leave it up to you how to strike that balance, I’m still trying to figure it out.
Here’s a simple technique I’ve been using since December for huge gains:
I put two large ads on my top 5 pages and I’m now averaging $50/month with only 600 ad impressions a day.
The obtrusiveness of this technique doesn’t particularly bother me, because they aren’t annoying my loyal readers. The majority of my traffic comes from Google and those visitors normally stick around, so I have no problem making money off of them.