Posts Tagged ‘Business’

Organic Search Engine Optimization

January 18, 2010

I don’t make my living as an search engine optimization expert, but I’ve been a web developer since 2000. I’ve watched with morbid curiosity as the SEO trainwreck has unfolded and evolved over the last decade. If that sounds boring, understand that shows like Desperate Housewives were not yet available for people who enjoy watching the self-indulgent suffering of others. I’ve gotten off-topic, slightly.

Bad Search Engine Optimization

A client recently brought in other contractors who professed to have the keys to SEO gold: keyword meta tags, and url redirecting. To be fair, they weren’t hired as SEO experts either – they’re good at their primary jobs, and were trying to help out with the information they had. Unfortunately, that information was about 10 years out of date.

I have good news and bad news. The bad news is that there are no shortcuts to effective search engine optimization. None of the big three search engines (Google, Yahoo, and MSN/Bing) use them, and they make up 93% of the search engine market share.1 Google2 and Yahoo3 have both stated that they stopped using them, and MSN never did.

Why? Because if you give people an easy way to tell you what their site is about, and how relevant it is, everybody is going to say their site is the source for a thousand different things. In fact, that’s exactly what happened, which is why keyword meta tags stopped being effective long before search engines officially pulled the plug.

Good Search Engine Optimization

Good SEO is organic. Most of it just happens naturally if you’re doing what a good site should – providing quality content that people would be interested in reading. It happens a little better if you’re aware of a few things first. If there are certain key phrases everyone is searching to get to sites like yours, you should mention those key phrases in your content. Don’t overdo it, because Google and visitors know the difference. Also, you do get a boost in rankings if other sites link to yours. Finally, search engines will list you higher if searchers actually click the link to your site in their search results.

Here is my cost-effective guide to good search engine rankings. I’m sure professional SEO experts (the rare good ones) have a few more tricks up their sleeves, but these basics will get you farther than you’d think, for free.

  1. Research. Signup for Google AdWords and build out a campaign as if you were going to advertise. When you pick the keywords you’d like to sponsor, they’ll show you how popular those terms are. You want to gear your site toward the most popular search terms that are relevant to your site.
  2. Description Meta Tags. Use the description meta tag. It won’t help your search engine ranking, but it will tell people why they should click your link after searching.
  3. Add Content. Make a regular habit of adding content to your site. Strive for 1-2 pages of relevant content per week. This is why blogs do so well in search engines – they’re constantly growing in relevant content. If you do nothing else, add to your site’s content frequently!
  4. Encourage Links to Your Site. You can ask the webmasters of other related (noncompeting) sites if they’d be interested in exchanging links to each other’s sites. This really only works between legitimate sites. “Link farms”, networks of sites setup just to link to each other, are ignored by search engines at best, and penalized at worst. Also, if your content is relevant and worthy, other sites will begin linking to you without asking.
  5. Be Creative. My client and I realized they’d been sitting on a goldmine of content. They’d built a 100+ page reference guide for their industry, but it was a members-only resource. Soon it will be public, drawing in people who would have never heard of their site otherwise.

That’s it. Nothing beats having a rich site, full of content people actually want to read. There are no shortcuts, because any “trick” is abused to the point of nullifying the effect. It’s organic search engine optimization, and it works.

References

  1. ComScore – reports on search engine market share
  2. Google Can’t Be Gamed – an article and video of a Google engineer explaining for the record that keyword meta tags don’t matter.
  3. Yahoo Search No Longer Uses Keywords Tag

Kansas City Ruby User Group’s January Meeting

January 17, 2010

Last Tuesday, the Kansas City Ruby User Group (KCRUG) had its monthly meeting. There were 15-20 of us in attendence, with Nate Bunnyfield checking in from the Lawrence on Rails group in nearby Lawrence, Kansas. I’ve been meaning to go to one of their meetings, which are every other Thursday.

Shashank Date gave the main presentation, about Ruby blocks, procs, and lambdas. His presentation is here:

Ryan Smith also presented his Decorator pattern for Rails:

We don’t have our video setup exactly as we’d like it yet, but we’re getting there. Thanks to the presenters, along with Wes Garrison who recorded and processed the video!

There Are No Cheap Ruby on Rails Experts

January 15, 2010

One of the most important factors in hiring a Rails developer is hourly rate. Within reason, you want to hire the highest priced developer you can afford.

We’re trained from youth to be bargain shoppers. This is largely because we live in a world of commodities. A commodity is something you can buy from multiple sources, and be fairly certain that the quality will be the same. A Ford Mustang will be exactly the same no matter what dealer you buy from. Even the cheapo espresso maker at Walmart ($30 and worth every penny) comes with a minimal expectation of quality, because you can return it otherwise.

The world of service is an entirely different ball game. Granted, some technology platforms are so saturated with developers and certifications (Microsoft, I’m looking at you) that you can often brow-beat a bottom dollar price out of a reasonably competent developer. Ruby on Rails works a little differently. The better the developer, the higher the demand for their services. And thus,

One of the most important factors in hiring a Rails developer is hourly rate. Within reason, you want to hire the highest priced developer you can afford.

What is a good rate? This can be a touchy subject, but I’ll give you my honest opinion. If you’re looking to hire a contract developer for anything less than $50 an hour, you’re not going to get your money’s worth. If you’re paying $25/hour or less, your developer is learning Rails on your dime. An exception would be someone who is already gainfully employed elsewhere, and wants extra work after hours. They’re less picky because it’s not their primary income, and they may even be trying to break into freelance with lower rates. If you’re willing to work around their schedule, you can sometimes get a good deal.

For the rest of us who need work done on a firmer schedule, and the ability to communicate during office hours, any developer charging less than $50/hour is usually struggling to get work in the door. Expert developers are typically in higher demand, and fetch rates up to, and above, $100/hour. Of course, all of us have lowered rates to fill up billable hours, but that’s not something you can count on when hiring a developer.

You can’t afford not to…seriously

I know it’s cliche, but it’s true. A good rails developer will pay for themselves. I’ve done more than one rescue project where the original developers were cheaper, but couldn’t get the job done. And typically, a well qualified developer will pay for their higher rate because they simply get the same work done in less time.

Price is definitely not the only consideration. But a low price should be a very low priority, while a higher rate is often a good indicator of a higher-caliber developer. Another is their expertise at Test Driven Development, and you can read my page about automated testing in rails to learn how to spot the pros. Finally, ask for the usual – code samples, recommendations, and examples of working sites.

In summary, price should definitely be a factor, but in both directions. Filter out the hourly rates you can’t afford, but also filter out developers with rates significantly lower. You’ll have a better product for a lower price as a result.

Announcement: Kansas City Ruby User Group Meeting

January 11, 2010

Every month, the Kansas City Ruby User group meets to discuss current events in the development world, and learn from each other. This month, Shashank Date will be offering a refresher of his talk from last year on Procs and lambdas. Often, Ruby on Rails developers can be strong on Rails, and light on Ruby.

This talk covers one of the most powerful Ruby features that is used all the time by the Rails framework itself. Newer developers, however, may not realize just how easy it is to harness the power of blocks, and by extension Proc and lambda calls, in methods. I might also stand up and give a brief rundown on binding, a closely related concept.

The Where and When

If you live in the Kansas City area, join us Tuesday January 11, 2010 at 6:30pm here:

Centriq Foss
8700 State Line Road
Leawood, KS 66206

Visit the meetup page for more info.

Preview

To give some background, here’s a code snippet that illustrates a block:

def do_for_each(array=[], &block)
   array.each{|element| block.call element}
 end

do_for_each([1,2,3]){|x| puts x}

A Ruby block is a chunk of code that can be passed to a method and run at will. This code prints each element of the array on its own line. If this looks familiar, that’s because it’s really a lamer version of the Array class’ map instance method.

When you pass a block to a method like this, you’re recreating a Proc object implicitly. You don’t have to do anything extra, and Ruby knows what to do with this extra code hanging off the method call. But what if, for instance, you needed to pass *two* blocks into a method? Here’s one way:

def custom_print(words, quiet, loud)
  words.each do |word|
    if word =~ /!$/
      puts loud.call(word)
    else
      puts quiet.call(word)
    end
  end
end

words = ['hello', 'world!', 'turkey']
custom_print(words, lambda{|w| w + '.'}, lambda{|w| w.upcase})

In this example, words are “loud” if they end in an exclamation point. I chose to end quiet words with a period, and to capitalize loud words. Please join us Tuesday for a much more detailed explanation.


Follow

Get every new post delivered to your Inbox.