The Puerto Rican Rails Dude

Today I stumbled upon a site which shows how to create a ‘magical’ user registration form, using a little bit of CSS and jQuery magic. Go ahead, play around with it once. I’ll wait.

Are you finished? Good. Now please don’t ever do this in your own websites. Ever.

Have you ever been around other websites where you need to register, only to see a humongous form that needs to be filled out? Chances are, as soon as you saw that huge form, you clicked on the ‘Back’ button of your browser, never to return again.

Now, imagine the same site and it still requires you to fill out that huge form. However, instead of showing you upfront about the time you need to spend filling out that info, it only shows you two fields. You immediately think “Cool, I’ll be registered in no time at all!” Then you click on the ‘Registration’ button… And more fields pop up. Begrudgingly, you fill out these additional fields… Only to be shown more fields. Do you see where I’m going?

Don’t torture your users into filling out needless information. Unless you’re working with some government or financial entity, you really don’t need all that information, do you? Keep it as simple as you possibly can. For example, I loved Heroku’s sign up process, where just an email address is required. They send you a link through email, where you click and voilà, you are now a registered Heroku user. Simple and effective.

Another alternative is what’s called “Lazy Registration”, where you can actually use the main functionality of the site without registering. Only when you need to actually register for something (like to save the information for future use), the sign-up form will appear. By this time, the user will know how much value your site gives to them, so if they were happy with what they saw with the non-registration parts of your site, they will gladly register and continue to use your site in the future. Also simple and effective.

You ultimately decide what needs to be in your registration form. Just don’t be surprised when you find that your 5-step registration process isn’t gaining any new users to your site. We’re not really dying to use your site, you know.

Update: As soon as I posted this, Jason Fried from 37signals wrote a post about signup form redesigns for their products. I thought I would add it here, as 37signals is a company I respect and appreciate for writing these kind of posts.

One of the not-so-joyous moments of being a web developer is the fact that we still need to support browsers that are ancient (by technological standards). Specifically, I’m talking about Internet Explorer 6.0. A quick look at the site statistics of one of the major websites I’m currently working on says that 16.9% of users visited our site using Internet Explorer 6.0. That’s obviously not the majority – Internet Explorer 7.0 takes that honor with 38.4%, followed by Firefox 3.0 with 19.8%. But it’s still a large enough number for the higher-ups to decide not to ignore it.

Since I never, ever use Internet Explorer 6.0 for any regular browsing (and you shouldn’t, either – read why on sites like Browse Happy), this past week I decided to give the site a test run with Internet Explorer 6.0 (using IEs 4 Linux). Besides the frustration of finding some incompatibilities with standard CSS on this browser, everything else seemed to work well. I then triggered an error on purpose, just to make sure our error handling would be handled properly (display our custom 404 error page instead of a nasty -yet customized – 500 error page). To my surprise, Internet Explorer 6.0 decided to render its own friendly error page instead of our custom one.

Thinking one of my colleagues removed it for whatever reason, I fired up Firefox and triggered the same error. The custom 404 page appeared correctly. Heading over to a Windows laptop, I had the custom error page on all browsers, including Internet Explorer 7.0. This left me scratching my head for a while. Although I’m already used to Internet Explorer 6.0 to act in different ways, standards be damned, this act seemed to be stupefying.

I was about to give up, thinking that Internet Explorer 6.0 used to hijack everyone’s custom error page just to hawk their own, I did a search on 404 error pages. Lo and behold, Wikipedia came through with a response that I would have never guessed:

Internet Explorer (before Internet Explorer 7), however, will not display custom pages unless they are larger than 512 bytes, opting to instead display a “friendly” error page.

Wow. Who knew that size mattered? On a custom error page, of course.

Our custom 404 was basically just a regular HTML with the standard tags, and one image and it weighed less than 300 bytes. I couldn’t modify the design or anything, so I just padded the error page with a long, boring and senseless comment, explaining why said comment was there. After ‘fattening up’ the file to more than 512 bytes, the error page started appearing on Internet Explorer 6.0.

It turns out that older versions of Internet Explorer had a threshold value in the registry which decided whether to display their own error page or a custom one. Why? I have no idea. Thankfully that was fixed for recent versions. But for all of the unlucky ones who still have to support ancient technology, this is another special Internet Explorer 6.0 quirk that needs to be taken into consideration.

For more information, including the default size limitations for other error pages, read this site (aptly named ‘404-error-pages.com’) has all the information you need.

On a recent Rails project, I was asked to verify if the visiting user’s browser has cookies enabled, and display a message on top of the screen if they don’t. While I don’t want to get into the reasoning why, or get into a flame war whether the site should still be accessible regardless if the user’s browser has cookies, I still needed to implement it.

Since it’s a Rails project, I thought of checking if the session cookie that Rails sets in the Application controller was set. But Rails sets the session after the view is rendered the first time (I have a more detailed explanation somewhere but don’t have it with me, so maybe next time). This means the first time the user visits the site, it will incorrectly display the warning message. Subsequent views will test correctly, but this obviously won’t work.

So I decided to implement a redirect, thanks to ideas given by this blog post. It worked, but it left me with a parameter in my URL the first time the user visited the site. It didn’t seem clean, and the higher-ups didn’t like it either, so off it went.

Then I was given the idea to check it via JavaScript, and with some slight tinkering I think I got what I wanted:

Basically this uses JavaScript to set the cookie when the page is rendering and immediately checks for its availability using a regular expression. If it’s found, then the user has cookies enabled and we can safely delete the test cookie (provided the user has their system clock set after January 1, 2001). If the cookie isn’t set, that means the user doesn’t have cookies enabled in their browser, so we display the ‘cookies_disabled’ element with our message inside.

This function is called in our application layout, between the <head> tags, meaning it’s called for every single page that renders the default layout. I haven’t observed any type of performance issue this might have, but I might have missed something along the way. And there’s probably a better, more efficient way to handle this as well, so if you have any suggestions, feel free to dtop a comment and let me know.

Over the past week and a half, I’ve been busting my ass trying to learn the ropes of Behavior-Driven Development with RSpec. I had been interested in learning either Test-Driven Development or Behavior-Driven Development for quite a while, so I just jumped on one of the two and test the waters out for a while.

I’ve been reading a lot on TDD and BDD for the past couple of months, yet never took the time to implement it to my current projects. The main reason is because I thought it would take me too much time to learn and would bog me down too much, when all I wanted was a workable application running as soon as possible. But, an opportunity presented itself (more on that in the future), so I chose the development technique that seemed better for me: BDD.

Reading about RSpec through other blogs on the Internet, it just seemed so intuitive to use that for testing, I kinda thought it was too good to be true. So after installing RSpec and getting it running on my application, I realized it was true after all. It’s ridiculously easy to write your own tests with RSpec, and it’s almost plain English (just like good ol’ Ruby). It includes built-in stubs and mocks to simulate parts of code, so you can even drop fixtures if you want (although admittedly, a lot of the shortcomings fixtures had were fixed with Rails 2.0). In fact, here’s a simple controller test:

describe ProductsController do

  before(:each) do
    @product = mock_model(Product, :to_param => "1")
    Product.stub!(:find).and_return(@product)
  end

  it "should call the action successfully" do
    get :show, :id => "1"
    response.should be_success
  end

  it "should find the product" do
    Product.should_receive(:find).with("1").and_return(@product)
    get :show, :id => "1"
  end

  it "should assign the found product for the view" do
    get :show, :id => "1"
    assigns[:product].should eql(@product)
  end

end

This test actually works for testing the show action in a controller. I wrote this just to show how readable the code is. I never knew testing would be so readable! And like I said, once you wrap your head around mocks and stubs, it’s ridiculously easy to implement. As a great bonus, RSpec can also integrate with rcov, a tool that actually checks what parts of your code are tested. It’s a great tool for making sure you achieve 100% coverage of your code.

Unfortunately, I didn’t actually do any BDD this time around, as I already had a good chunk of my application up and running already. But now that I have discovered the joys of RSpec, all my upcoming products will be fully done using BDD techniques: I won’t write a line of code until I write the behavioural test before.

A couple of ceveats, though. Hey, nothing’s perfect! First off, if you use different types of plugins for your application, you’ll find some parts of it difficult to test in RSpec. Most plugins use the Ruby’s own Test::Unit testing framework to test their own functionality, but parts in your code where you use these plugins can get you the first time around. Also, if you’re like me, and already have written code for your app, you’ll start finding different ways to fix your code to conform to RSpec testing. This isn’t necessarily a bad thing, as this is most likely a warning sign that you need to refactor that piece of your code anyway. But it’s takes a bit of your time away, so be prepared for this.

In short, RSpec is so easy to use, I don’t see why people shouldn’t use it in their own projects. I suggest every Rails developer should look into RSpec (or any other testing method, really) and stop being lazy. I know I was, but never more!

RSpec References

Ryan Bates from Railscasts has a great screencast that can serve as an intro to testing controllers. And the best part is that it’s free!

* Testing Controllers – http://railscasts.com/episodes/71

Geoffrey Grosenbach over at PeepCode has an excellent three-part series on RSpec, with about three hours of RSpec goodness! No, they’re not free, but the $9.00 per episode is truly worth it. This was my secret weapon in learning RSpec in less than two weeks – The best 27 bucks I’ve spent in my software development career!

* RSpec Basics – http://peepcode.com/products/rspec-basics
* RSpec Mocks and Models – http://peepcode.com/products/rspec-mocks-and-models
* RSpec Controllers and Tools – http://peepcode.com/products/rspec-controllers-and-tools

The past two weeks I’ve been totally separated from all of my learning and reading processes I’ve established to myself, and I felt terrible for doing that. It’s not like I’ve been totally disconnected from everything. I’ve still read all my favorite programming-related blogs, as usual. Still, I haven’t just sat down to absorb everything or practice.

These past two days I decided to get back on track. However, I found myself with the same problem I’ve had for a while now. Whenever I sit down to learn something, I want to learn everything. I don’t mean “learn everything of something“. It’s more like “learn something from everything“.

For the past months, I’ve had a hundred different interests. I’m interested in learning Adobe AIR. Microsoft Silverlight sounds like something I could use in the future. I was sold on Test-Driven Development and ever started to adopt its practices to my daily usage, yet recently I’m liking the sound of Behavior-Driven Development more and more and would like to test that road. I want to learn other web frameworks in different programming languages, like Django and CakePHP. And of course, I’m still totally into Ruby and Rails.

I know a lot of people who don’t mind knowing about everything. But the deal is that by learning (or having the desire to learn) about so many things, you don’t fully learn it all. You only learn a bit about each thing, but never a whole lot. There simply isn’t enough time in the world to do so, especially with a full-time schedule. So to say it’s frustrating is an understatement to me.

One technique I’m finding useful to juggle these interests is to create a necessary project in your mind to learn along the way. This should keep your interests level high during the learning process, while making you stay focused with one or two things at a time. For example, my next project is a web application, where I’ll strictly try to use the practices of Behavior-Driven Development while learning to use RSpec. This way, I’ll be learning a lot of different, yet related, subjects at the same time. After this project is done, I’ll see where Adobe AIR has headed, since it’s still in Beta. If it still piques my interest, I’ll create a new project for one of my current needs, and learn from there.

Being in this world of programming and technology, where it seems like time is always on fast-forward, it can be tough to keep up with what you like. But at the same time, it’s just fun. Even though I get frustrated at times, I’m having a ball learning these things. I guess it all boils down to that for now.

You Americans (and British, Australians and any other English speakers) have it easy. When you need to create a web application, all you need to use for your text is the basic English alphabet, only 26 different characters and 10 digits. The rest of the world, myself included, aren’t so lucky. Our languages are damn complicated, with additional letters, along with such grammatical ‘features’ such as accents to see where the pronunciation is at its strongest.

Seeing that I was born in Chicago, my first language is English. Although my parents are both from Puerto Rico, they never enforced the usage of Spanish upon me. When I moved to Puerto Rico when I was 8 years old, the only word in Spanish I knew was “Gracias”. Unfortunately, I didn’t have Dora The Explorer to help me learn the language when I was a boy. It’s taken years, but I finally consider myself fully bilingual in both English and Spanish, and am usually very careful as far as spelling and grammar go.

However, I’ve been wracking my brain for a long time now when making web applications in Spanish. Sometimes the additional characters, like the letter “ñ“, or words like “presentación” are a pain to get working immediately. It’s like I have to jump through hoops to get those characters working right.

In case anyone else shares my pain (or in case I forget in the next couple of months), I’ve compiled a short list with the things you should first look for when these Unicode characters are appearing incorrectly.

Don’t forget the <meta> tag

One common mistake web developers make is forgetting to set the default character set of the page they’re working on. Without this tag, the browser will automatically set the character set to the browser’s default, usually ISO-8859-1, which does not show Unicode characters. To set the character set of the page to UTF-8, which correctly displays Unicode characters, you simply need to add the following meta tag as the first line in the <head> section:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

This should enforce your browser to use UTF-8 when displaying the page’s characters. Remember to set this first, before any other tags in the head section, or else it won’t work at all.

Check your web server configuration

I remember once working with a PHP application, and pulling my hair out because the characters simply wouldn’t display correctly, no matter what I did. After hours of searching through Google, I found out my problem. The Apache Web Server, which was responsible for serving the website, had its default character set set to ISO-8859-1. If you control your own server and can change Apache’s configuration, just go to the configuration file named httpd.conf (this name can vary, depending on your Linux distribution) and make sure the AddDefaultCharset option is correctly set:

AddDefaultCharset UTF-8

After reloading the Apache Web Server, your pages should be displaying Unicode characters correctly. With the Lighttpd Web Server, which I’m using now, I haven’t had to set any option for correct Unicode support. However, in case someone needs it, just go to your Lighttpd configuration file, go to the mimetype.assign section, search for the .html assignment, and add the following at the end:

".html" => "text/html; charset=utf-8"

Another file to verify, although not necessary in most cases, is the PHP configuration file, named php.ini. PHP is responsible enough to use the encoding set in the page by the meta tag mentioned above, but sometimes some joker decides to change the default character set in the configuration file. In this case, simply comment out the default_charset option, and reload your web server.

The database has data too, you know…

With those two fixes above, your static text should be displaying correctly. However, you notice all Unicode characters stored and retrieved from the database are still being incorrectly displayed. This is due to your database character set not being set to UTF-8. In my app, I’m using MySQL, and the database server’s default character set is set to latin1_general_cl, which apparently doesn’t display Unicode at all. If you don’t explicitly indicate which character set you want to use for your database, the default will be used for not only the database, but the rest of the tables (unless explicitly defined, as well). What we want is the utf8_bin character set, which will display the Unicode correctly.

There are different ways to change this default behavior, from starting the database server with an option to change the default character set, to recompiling the entire program (providing it’s Open Source). But I find it much easier to just remember to make your database use the correct character set. In the MySQL prompt on the command line, it’s as simple as this:

CREATE DATABASE database_name CHARACTER SET utf8;

If you have an existing database not using the UTF-8 character set, the easiest way is to use a program like PHPMyAdmin for MySQL, or your preferred GUI for your database server, and change it there. You can also do it through the command line, but I won’t go into those details here. Search Google and you’ll get a ton of information.

Your text editor has a hand in this too

Don’t forget the tool you’re using to create your web pages. They could be the ones giving you major headaches. In my case, I’m testing out Intype, which is still in alpha, but very usable. Intype has the nasty habit (which I wish is fixed soon) to automatically set the file’s character set to ANSI by default. Once you save the file with this character set, it stays that way, wreaking havoc on what you want to see.

To fix this problem, just make sure your text editor, whether it’s Intype, e, Textmate, Vim or any other text editor in vogue right now, is saving your file using the adequate character set. In my case, I’m using UTF-8 Plain with Intype, and my characters are showing up correctly.

These tips should save you a ton of headaches down the road if you’re doing web development for a non-English audience. If you have any to add, feel free to do so.

Note: This site has changed a lot over the last year. I’m not using Rails anymore on the site, so there’s no place where I’m currently using the Digg API. However, I’ll leave this post intact, as it might help others with something similar.

If any of you readers have come in through my main site lately, you should notice that I added a little something on the sidebar. One of my favorite time-wasting activities of the day is browsing Digg. I tell you, there should be some sort of “Diggers Anonymous” for us simple-minded folk who can’t stop from visiting the site for stories many times a day!

Anyway, they recently announced the release of the Digg API, to allow any user to access the stories on the site in any way, shape or form we desire. Now, I must say that I have no real use for this. Of course, being the geek I am, I just wanted to try it out and see how I could use a simple API using Ruby, for use on my Rails site (this one). This is also made in case anyone else wants to do the same. One note, however: I’m only a Ruby / Rails beginner. I’m sure there are much better and efficient ways to do this. Since I haven’t dabbled in this too much, and “it works on my machine“, I’ll leave it as it is for now.

Just for the record, the testing and development for this code was made on my computer running Ubuntu 7.04, along with Ruby 1.8.6 (compiled by myself, not downloaded from the Ubuntu repos), RubyGems 0.9.2 and Rails 1.2.3. It should work correctly with any fairly recent version of the software mentioned above.

The Digg API is rather simplistic right now. All you need is a simple request using a URL like this:

http://services.digg.com/stories?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5

In the example above, the API is called to the ‘http://services.digg.com’ server. The parameters afterwards (in this case, ‘/stories‘) is the request. You can add more parameters for a finer-grained search.

Once the request URL is complete, you need some additional actions to add as well. The ‘appkey‘ is required, but can be anything for now. Digg isn’t generating application keys (a la eBay or other external API’s), but an appkey is required for ’statistical purposes’, according to the documentation. The ‘type‘ is how the data is going to be returned to the app, and it can be either XML, Javascript, JSON or PHP. I use good ol’ XML for now, until I can actually play around further with the other response types. Finally, the ‘count’ action is to limit how many stories are returned. I’m only going over these options quickly, as the API documentation has much more information.

Once you figure out which request you want to make (using Mozilla Firefox can help greatly, as the XML response is nicely formatted), it’s a matter of getting that data into your Ruby or Rails app. Going back to the ol’ trusty Pickaxe book, I found a nice little module integrated in Ruby called open-uri. This module allows the Ruby application to open a URL (either http, https or ftp) and get the returned contents. To use this module, a simple line of code is needed:

require 'open-uri'

That should load your module correctly. Now it’s just a matter of having Ruby open the API connection and store its XML response in a variable:

response = open('http://services.digg.com/stories/popular?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5').read

The ‘open‘ function, well, opens the connection to the API, while the ‘read‘ method gets the data that’s returned from the URL. Like I said, rather simple.

However, I was getting timeout errors when calling the ‘open’ function. Strangely enough, the function worked fine when using any other URL. Upon further reading of the API documentation, I found this little tidbit:

“All API requests must include a User-Agent HTTP Header. A request without this header will receive no response.”

So, after that small mistake, I edited the request like so:

response = open('http://services.digg.com/stories/popular?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5', 'User-Agent' => 'Ruby/1.8.6').read

The ‘User-Agent‘ parameter can be anything. I just decided to use the Ruby version I have. Once I added that, I had my nice XML with the five most recent Digg stories that have been promoted to the front page.

After that, I needed to parse that XML. I searched around the Internet, and found a great little module called ‘XmlSimple‘. This module reads and writes XML, and formats it according to whatever’s needed. In my case, I needed to read the XML response. Just like the ‘open-url’ module previously, you need to load the ‘XmlSimple’ module as well, once installed (“gem install xml-simple“):

require 'xmlsimple'

I did run into some minor problems when loading this module. The Ruby interpreter cried out loud, saying it couldn’t load the module. How come? I verified that the gem was installed correctly, and it was. Then I realized that since this is a gem, I need to have ‘RubyGems‘ loaded before loading ‘xmlsimple’:

require 'rubygems'

I believe that Rails already loads the module for you. But if you’re testing this out on Ruby and not on Rails, you’ll need it.

Okay, once I did that, I was able to load the ‘xmlsimple’ module. Now I need it to parse the XML response that I stored in the aptly-named ‘response‘ variable. A simple line of code can convert the XML into a hash:

XmlSimple.xml_in(response)

That takes the entire XML string and puts it into a neatly organized hash. I really don’t need everything in the hash, just the story title, link and how many diggs the story has. So I just access those particular keys:

digg_hash = XmlSimple.xml_in(response)
story_title = digg_hash['story'][0]['title']
story_link = digg_hash['story'][0]['link']
story_diggs = digg_hash['story'][0]['diggs']

In the example above, the ‘story_title‘ variable has the most recent story title, the ‘story_link‘ is the link that takes you directly to the story, and the ‘story_diggs‘ has the current amount of diggs that story has. The number zero used in the array is the story number. If you want to get more than one, you’ll need to loop through the array and get the other stories.

The code I’m using on the main site right now is the following:

<%
  require 'open-uri'
  require 'rubygems'
  require 'xmlsimple'

  response = open('http://services.digg.com/stories/popular?appkey=http%3A%2F%2Fdennmart.com&type=xml&count=5', 'User-Agent' => 'Ruby/1.8.6').read
  articles = 0
  while articles < 5
%>
<%= XmlSimple.xml_in(response)['story'][articles]['title'] %>
(Dugg <%= XmlSimple.xml_in(response)['story'][articles]['diggs'] %> times)


<%
  articles += 1
  end
%>

In all, this was rather simple, and I’m sure there will be a much more creative use for the Digg API soon. But for those who want to learn how to use it, or those who need a very simple approach, this works just fine. I’m interested in listening on how other people have put this to use. Hope this helps someone!

I’ve been learning Rails with great success these past two weeks. I’ve learned so many things during this period, much more than I’ve learned in a similar time frame for other languages / technologies. While there is still much, much more to learn (and memorize), I’m very happy in the time I’m investing in Rails, and don’t mind spending most of my free time reading and coding.

However, something that has happened to me a couple of times is that I get confused with certain things. For example, last week, I was really confused when reading about how forms work in Rails, and how to save and edit records in a database. Basically, it all came down to its simplicity confusing the hell out of me. For example, to save a new user, the only line of code needed in the controller was User.new(params[:user]). After watching this work nicely, I was amazed, but at the same time confused. How did Rails know what to save and in which fields? Where’s the SQL code? After reading a bit more about the form_for and form element helpers, as well as reading the logs, I found out how Rails does this automatically. Really great stuff.

However, some further confusion happened while reading about the form helpers. There were similar tags for the same thing. For example, there’s a form_for helper, as well as a form_tag helper, which create the form in the web page. Same with the elements. The text_field and text_field_tag apparently did the same thing, albeit each had different parameters. So that caused a bit of confusion early on.

So, maybe my mind was just fatigued because of the week I had at work, or I didn’t read my book well, but this caused me to look around to better understand these tags and what each one did, and why two (or more) similar helpers did different things. Thankfully, I’m the type of person who needs to know how things work. I’m never satisfied if I use something and if it works, I never question it. It may be the inner hacker in me.

Last year, after a friend of mine lent me here Macbook for a week (I want one for myself so bad!), I discovered the most amazing programming software I had ever found, called TextMate. I’m sure many of you have heard about this program. In fact, if you have watched any of the Ruby On Rails screencasts, you know what software I’m talking about. I think it strikes a balance between simplicity and power that’s rarely seen, and that I never even thought was possible. I tell you, once you get used to their snippets function, you’ll never want to try another IDE again.

So I went off, searching for a nice alternative for Windows that would work similarly. Shockingly enough, there wasn’t any program out there that was even similar to TextMate. I thought that was pretty weird. But after doing enough searching, I found a place where some people were making a program for Windows that would basically be a TextMate-like clone for Windows. Unfortunately, the program was only in its initial phase, with no alpha released yet. Sadly, I thought this program would just die out like many other software projects I’ve seen before, never to see the light of day.

But early this year, I received an E-Mail, stating that the very first Alpha release was available for download! Giddy, I went to their site, and lo-and-behold, there it was. I would finally get to use the program known as Intype. I rarely get excited for a software release, but this was an exception.

So I tried out the program, and it worked fine. Of course, as all alpha software, it had its fair share of bugs, and most of the functionality found in other text editors was missing (more noticeably, an Undo / Redo function). Still, it showed lots of promise, and many other people in their forums shared the same excitement as I did.

After a couple of more releases, there is finally a very usable Alpha version – one with an Undo function – available right now. I’ve been using it while I’m learning Rails, and it’s helped greatly, in terms of writing code much faster. I won’t dive into specifics, as there are already a couple of reviews out there in the wild. Even though it’s an Alpha release, it’s coming along really nicely. If the project continues forward, and all the proposed features are added, this will truly be a blessing for the developers – like myself – that are stuck at work with a Windows environment.

If you have a chance, download the most recent version and give it a spin. Besides helping with bug reports, you’ll probably be pleasantly surprised at the current state of the project, and you’ll certainly be excited as to where it’s headed. Be ready.

When I started to work on this site, I wanted this site to completely follow the web standards set by the World Wide Web Consortium. The real reason for doing this was personal, as I want to adopt the philosophy of “If you’re going to do something, do it the right way”, which is how I really strive to do everything in general. But as I read more and more about why these standards exist in the first place, now it’s become because I want my site to work as I intend it to be. For now, it’s all working well. Go ahead, click on the W3 button at the footer of the site to validate the page. I’ll wait a moment.

Okay, so this entire post started from the fact that the Wordpress software I use to run this blog has always advocated being standards-compliant, which is why I chose to use this software instead of a different one. So it came to my surprise that when I found out recently that some sections of this blog we failing the validation tests. It turns out it was because of the template I’m using. I’ve fixed the problems that I have noticed, and I vow it will never, ever happen again on any website I develop.

However, it bugs me a little when I see that most large and popular websites fail the simple validation tests. Microsoft’s website fails validation, mostly due to the fact that Internet Explorer is recommended to browse the site and that piece of software seems to follow their own web standards. YouTube fails as well, maybe because of all those Flash-based movie players scattered around. I won’t even bother to talk about MySpace and the really messy pages of most of its users. Even Google’s very simple main page doesn’t have a valid DOCTYPE in its code. Why do these large companies fail to address this? I mean, it’s not difficult to follow web standards at all. If a simple, lone programmer like myself can do it, certainly those large corporations with their fleet of programming gurus can work it out, right? It seems they don’t.

I had read a very interesting blog post that talks about the importance of web standards, and tries to reach out to those people. But day after day, these developers just don’t seem to care at all. I see no valid reason why web developers can’t write the code to their site using simple and proven web standards. It sort of boggles the mind.

Granted, there are some websites that fail validation due to non-validating ads on their pages. This is a touchy subject, since those ads sometimes help pay the bills of running the website, so removing them it out of the question. I have not yet implemented a site that has ads running on it, so I wouldn’t know how to work around this. But I would at least try to give the companies running those ads a hard time to shape up and fix their ads.

Alas, there still is hope around. Many sites around the Internet are gracious enough to follow web standards in their wildly popular and frequently visited pages. Sites like Digg and Craigslist follow web standards correctly, and I applaud them for that. Unfortunately, I can’t say the same for the rest of the top websites of the universe.

Even though I’m a simple programmer just trying to make a personal website, I will continue to work with web standards, even if I’m part of a very small part of those who actually do so as well.