Search Engine Optimization: Devil or Saint? Science or Art?

Written on 10:35:00 PM by S. Potter

To many website operators, especially websites operated by individuals, small to medium-size businesses and non-profit organizations, Search Engine Optimization (SEO) techniques are black magic that have no rules. Others see SEO techniques as a sure-fire cure-all. While Google clouds its search algorithms in enigma to outsiders, there are cornerstones to implementing effective SEO campaigns. In this posting I wish to demystify the core building blocks websites should be basing their SEO strategies on. Recently while working on software and web development projects remotely for two clients I have also had the opportunity to work on four SEO projects of various scale since the beginning of this year. I have been aware of many SEO techniques (some of them I would term tricks), but prior to January I had only put them into practice on small personal web endeavors. In my experiences thus far I have found some fairly simple, yet very effective foundations to build SEO efforts on top of, namely:

  • Provide useful, well written content on your site. It does not need to be mountains of content, but it does need to be somewhat sensible and useful content. One way that you can promote content generation (depending on the type of website you have) without crafting it all yourself is to open up forums for users/customers/clients to discuss their experiences. However, in some cases, this could be a nightmare for smaller organizations or individuals that need to create a family friendly environment (in terms of moderating spam or inappropriate comments), but has been used to great effect on many well known websites including, of course, I should also note that technology (like CAPTCHA image validation) can minimize spamming.
  • Clean HTML documents that you would like indexed by search engines to contain the minimal amount of markup, styling and javascript code as possible. This is second only to the above cornerstone. As a software engineer with, most recently, a web development focus, I find too many websites that clients give me to optimize, need client and server code to be refactored in in a serious way. The idea is to reduce non-content code to the appropriate size that can improve keyword and search phrase ratios that most search engines most likely use to rank pages. I should note that we do not know exactly what ratios are used by search engines, but I have seen statistical evidence to strongly support the fact that certain ratios (or formulas that are proportional to these ratios) yield higher positions in web page rankings. If your web developer spends too much time learning the latest Javascript tricks or CSS hacks and not enough time writing more consice (but readable), more organized code, you should question whether they should be kept on for production work. Prototyping websites might be a better skill fit for them.
  • Know your audience [and keywords]. Three out of the four SEO projects I have recently worked on this year had highly flawed initial keyword/phrase targets, set forth by our clients. I was asked to promote these three websites on keywords very few people actually use to search for these business services. There are some commercial, free and internally developed tools and scripts that can help in analyzing the suitability of keywords. Making a list of not only the A-list keywords/phrases (the ideal candidates) for your website, but also popular B-list keywords/phrases, common typos and misspellings is essential to implementing an effective SEO campaign. Not only should you know your audience and relevant keywords and phrases to promote your website on, but you should be realistic about potential ranks for extremely popular keywords that larger players will, most likely, dominate for the first 3-5 pages of results. In these cases you should consider your options and evaluate if going after a 54th spot for a major buzz/keyword is worth the time and effort to get your site to that position when you could be getting first page hits with other more specific keywords and phrases.
  • Support search engine-friendly URLs on your website. If your website is dynamic in nature, choose web server technology that supports easily readable URLs. For example, most search engines will not index a web resource at a URL like the following: A website that has more than 1 dynamic HTTP parameter set in its URL is taking a risk that most search engines will not index it as search engines may assume it contains highly perishable information in the page. I have been able to translate unfriendly URLs to friendly URLs without asking the original web developers to touch the server code, although not all website URLs can be translated using URL rewriting engines such as Apache's mod_rewrite! Another gotcha is when web developers use the POST HTTP method when submitting HTTP parameter data using the GET HTTP method is far more appropriate. Since I am a software engineer with web development and SEO experience now I can advise clients on how to approach this and discuss best practice approaches. There are also other issues related to supporting search engine friendly URLs that would probably require a whole book let alone a long blog posting to fully treat the subject.
  • Do not blatantly violate the spirit of the search engines' code of ethics. There are some techniques that are various shades of grey, but you should stay clear of all techniques that are darker than 50% grey. If the search engines do not notice, your competitors might and they will be sure to notify search engines if you are stealing their thunder using questionable techniques. In theory, Google does not believe in blacklisting individual sites and prefer to optimize their algorithms such that the website drops in rank significantly or is no longer listed. However, Google will blacklist when websites are blatantly violating the spirit of their rules. Most recently Google has removed BMW's German website from search results on certain key words as they overstepped the mark in SEO creativity:
As you have probably figured out from my ramblings above, there is no clear winner. SEO techniques are neither black magic riddled with negative consequences nor sure-fire cure-all solutions. All I suggest is treading carefully using tried and tested techniques with room for some experimentation of your own to determine your own conclusions if you are going to undertake this task yourself. Alternatively, if you hire an SEO consultant make sure they are neither extreme.

IlliPy - C-U's Python User Group

Written on 11:06:00 AM by S. Potter

For those of you that don't know, I live in Champaign-Urbana (yes, birthplace to both Jennie Garth [90210] and Roger Ebert [film critic]) and have yet to meet enough techies. So my mission currently is to start a Python User Group for C-U. I have named it IlliPy, for reasons that should be blatantly obvious to the avid Python freak living in C-U. While I would like the group to have a monthly or quarterly (depending on number of people interested) tech talk/presentation and perhaps a book club, I also wanted to initiate some open source projects with other group memebers. These open source projects do not need to be purely Python only, but need to be related. Another angle I wanted to pursue is to also include a couple of talks on Ruby vs. Python, because there is a lot of overlap plus a lot of significant differences too. In fact, Python incorporated a Ruby feature into 2.4 because it worked so nicely in Ruby. If you are not a Python freak, but would like to get involved, fear not! Please come along to find more out about Python. I should also state for the record that you do not need to be a programmer by profession to participate. There seems to be a number of non-professional Python programmers out there (see this podcast for a Python fan that is not a programmer). Our first kickoff meeting is scheduled for Wednesday April 26, 2006 @ 7pm at Giuliani's (where the old Green Street Coffee Shop used to be and next to Murphy's Pub). To be informed of updates to the kickoff meeting or other events, please feel free to subscribe to the announcement-only mailing list.

Iron Python

Written on 4:10:00 PM by S. Potter

I just wanted to post the link to IronPython's download page since I keep mislaying the link and I revert to visiting the old website, which is totally unmaintained presently. Iron Python Download Site

Tax Day, Psychology & Pragmatic Tools

Written on 12:25:00 PM by S. Potter

Since I moved to the US I have always been struck by how wonderful the weather is on Tax Day. Since 2000 I have procrastinated doing my taxes until the VERY last minute (or at least last two days). I have traveled from coast to coast and lived in the midwest all since 2000 and every place I have been on Tax Day is a beautiful sunny, not too hot, not too windy, simply beautiful day! This year the regular Tax Day (April 15) landed on a Saturday so the IRS generously gave us until the following business day to e-file or mail our returns. Technically I finished filling in my tax forms on Sunday (April 16, 2006), but I only mailed the returns and added the extra $1,000 to my Roth IRA for 2005 this morning. Did you know that the limit is $4,000 this 2005 and 2006? Hurry you still have time to make the contribution. Perhaps the reason that the weather is so beautiful on Tax Day is that we appreciate it more knowing we have another 365 days until we need to do it all over again. Is it all psychological? I have been wondering this with respect to my work recently too. Over the last 2 years I have been increasingly more a Python head and less a Java head. Now I have started a medium scale website in Ruby on Rails and am having a great time doing so. The reason I have slowly been withdrawing from Java towards Python and Ruby is that I have found myself actually enjoying my work again on a low-level. It is honestly a pleasure to write Python and Ruby. Don't get me wrong I still need to fix some Java code in older projects that I still look after, and I am not saying Java is a bad language. In fact, compared to C++ (one of the languages I used on my first three jobs) it provides many productivity enhancements to writing servers in J2EE and even GUIs in Swing/JFC (as compared with MFC not comparing .NET here). C++'s Boost libraries are great if you are still a C++ head, but I think they arrived way too late in the game. For me Python and Ruby provide me with tools that psychologically enhance my state of mind while writing code. For example, I do not need to wait for byte compilation the same way I need to wait for a Java project of a similar size to compile. This means I don't loose my train of thought between writing the code and running the tests while checking my emails or getting a refreshment in the meantime. It also means that it simply takes less time to complete. The more time I have for writing and running tests the better in my opinion. I felt in Java and C++ that waiting for the compilation process (especially C++;) made me loose some of my gusto and determination for writing more tests. By providing pragmatic tools that enable me to write more tests without negative consequences, Python and Ruby promote more test writing and result in me having a large collection of test cases to run on a continuous or regular interval. One of the other major benefits of using Python and/or Ruby is their advanced interactive shells (ipython and irb respectively) that neither Java nor C++ possess in a serious fashion (e.g. Groovy, Jython, JRuby, etc. are not truly interactive Java shells in the same way). These two interactive language shells are huge time savers and promote true prototyping in the shell. Prototyping in this fashion makes sure that prototype code is truly thrown away except for the lines of code you have made the extra effort to cut n paste (i.e. the lines that worked the way you needed) and thought about which to keep. Again by using these pragmatic tools we are psychologically driven to doing the *right* thing for the project and learning the APIs more quickly. The third major benefit, and in my opinion the most overlooked (albeit quite new) attribute of these two pragmatic language environments (Python and Ruby), is package management with version/dependency management and discovery mechanisms built-in. In Java you have Maven, which attempts to do this for you in a round about way (and do not get me wrong Maven is very good for the Java world), but this is not a standard, either defacto or otherwise. Sure Python's Eggs (and the associated setuptools module) aren't true Python standards yet, but they soon will be and are very widely used both in open source and corporate worlds. Both Ruby's Gems and Python's Eggs provide developers, development teams and system administrators as a whole an easy way to manage multiple versions of code packages and components without worrying about setting environment variables and/or server container arguments appropriately, which might be out of the developer's control. The less time developers need to spend time on configuring their environment the better. Eggs and Gems streamline much of the configuration processes significantly as compared to Java's JARs limited functionality. While my personal experiences catalogued above isn't necessarily applicable to all developers, overall I think one of the keys to boosting development productivity in a language is understanding on a psychological level what developers NEED to work smarter!


Written on 12:13:00 PM by S. Potter

Kai-zen. What a fantastic word! A recent addition (ok, I am behind the times - more like 2 years ago) to English dictionaries is 'kaizen'. For years the Japanese have been using this wonderful word, which simply put means 'continuous and incremental improvement' or 'change for the better'. How wonderful to have one word to describe something that can be so layered in meaning? If you read the wikipedia entry you will find kaizen is about attaining the following goals:

  • eliminating waste*
  • just-in-time delivery
  • standardizing work
  • using only appropriate equipment
  • leveling load
  • plus others...
(* waste is defined as "activities that add cost but do not add value") In fact, kaizen is about taking a process, system, product or service apart and putting it back together again with the sole purpose of improving it. Kaizen is a whole philosophy that does not only encompass mechanical or purely business principles, but also humanizes processes and promotes respect for people. Without this basic respect honored there will be no continuous improvement at all. Taken directly from the wikipedia...
Importantly, kaizen must operate with three principles in place: process and results (not results-only); systemic thinking (i.e. big picture, not solely the narrow view); and non judgmental, non-blaming (because blaming is wasteful).
Hopefully now, you will understand why I fell in love with this word almost immediately. I am surprised that developers haven't started using this word, such as 'kaizen programming' or 'kaizen development'. I do think that Agile development methods and practices are moving very close to the essence of the meaning of kaizen. Perhaps now we should take these processes apart and reassemble with the purpose of improving them, ad infinitum. Unfortunately due to human error and nature we will never find the perfect methodology, but we can use common principles we all believe in to move us closer to our utopia, whatever our poison is (in my case software development). Taking a fresh look at CMM and Six Sigma, I wonder if this is where both processes originated from. If so, over the decades both have devolved and moved away from their founding principles. I am not attacking the CMM approach or Six Sigma methology at its roots, but pointing out that in industry today, their implementations (in my experience) have lacked any notion of humanizing the process. I have found the contrary true, they both try to dehumanize processes, which contradicts kaizen fundamentally. Today I decided to marry my former favorite word, mojo, with kaizen and registered Not completely sure what will be on this site, but I do have some software development productivity tools that need a home, so this might just be the perfect place. So continue improving...