The Irrelevancy of SEO

A couple of months ago, George Boone wrote an interesting piece on the Irrelevancy of SEO. I just read it, and it has made me think a bit. I think I may try the same tack he mentioned in his article with this blog. I am not going to worry about search engine traffic. I am just going to work with links, word of mouth, and other tactics, to see what kind of traffic I get.

Anyone interested in SEO, marketing, and traffic building should read that article - it’s one of the better ones I’ve read in a while.

edit: I didn’t see that article on digg anywhere, so I went to submit it. I got a message back: URL is on the ban list. I wonder why?

Applications are Built by Good Developers, Not Technologies

I’m taking on a bit more of Chris Shiflett’s post Ruby on Rails Fans. Following a list of the best Web 2.0 applications (Digg, del.icio.us, Wikipedia etc.), he tells how these kick-ass sites are written in PHP. He then reviews the best Ruby applications. Following this he writes:

I think a larger point is that good applications are built by good developers, not technologies. Did you know what all of these applications were written in? Did you care? Be honest.”

Oh, I know, I know. The point is quite obvious. But it is a good reminder. A good programmer doesn’t necessarily need the best language. If he/she is a good programmer, they can make the best of whatever language they want. To get right down to it, you should somehow be able to create any type of site that currently exists, using any Turing-complete language. It may take more, or less work in some. Creating a web application would be a lot more work in assembly, than Ruby on Rails, for an extreme example. But language choice should not be blamed for the failure of a project, if the choice was reasonable to begin with. That is more of a fault on the part of the programmer.

Ruby on Rails is a Niche Technology!

Here is a little piece written by Chris Shiflett in his Ruby on Rails Fans post:

“Ruby on Rails is a niche technology, and although all signs indicate that its popularity is growing rapidly, it’s a bit premature to be thinking that it will dethrone existing technologies.”

Alex Bunardzic writes in a recent post concerning this:

“The problem with the above statement is that it assumes that there are technologies which are not niche. But there really aren’t.

Even far-reaching technologies, such as web, are niche. Each technology has its niche, and there is no such thing as a general purpose technology.”

Alex, I have to disagree with you, somewhat. Your idea that every technology is a niche is somewhat flawed. Taking the word niche to it’s straightest definition:

Niche (noun): A niche is a special place within the scheme of things. It sometimes denotes the function or position of a thing within a structure.

Now, if you take niche to mean as defined above, then you are completely correct. If we were to use only that interpretation of niche, then there is nothing that is not filling a niche. The world and society are somewhat well-organized. Everything has a purpose to fill, or else it wouldn’t exist.

Common usage of the word niche, however, indicates something different. For something to be ‘niche’ within a group of other items or subjects typically indicates that it has a higher level of specialization than the norm. Taking this definition, calling Ruby on Rails a niche technology, is somewhat valid, especially if compared to COBOL, or C/C++, Java, etc. Ruby on Rails is meant to tackle a single, major problem - that of quickly constructing a viable web-based application, providing frameworks to assist along the way.

Therefore, I think it is fair to argue that Ruby on Rails is a niche technology.

In another point, Bunardzic writes:

“But if we look around, we’ll see that no technology ever goes away. Even though we live in the age of supersonic traveling, there is still plenty of trains, even horse carriages going around. These technologies will never go away.

Same is with high-tech. Mainframes running COBOL programs are here to stay. They will never get replaced by Ruby on Rails based software.”

I also disagree. how many 8-tracks do you still see, used seriously? Sure, vinyl is around, but what about the phonograph, or wax cylinders recordings?

Yes, COBOL systems are still used in some businesses, but they are on their way out. In 10 years, they will be gone. It is only a matter of time until the migration process is cheaper than the cost of maintaining inefficient legacy code. And every technology reaches that point at some time, even if it is 10 or 15 years overdue.

I am sure that there will always be hobbyists who will use these technologies. But they will be completely supplanted in common use. It cannot happen any other way.

I am open to a response, guys!

IBM Notes to Run Natively on Linux

According to CIO, IBM is preparing to announce that their IBM Lotus Notes software will at long last be ported to Linux. This is an important move as businesses move more and more towards the Linux open source operating System. Previously, users who wished to use IBM Lotus Notes on Linux were required to do so through the use of web clients or emulation software.

According to Arthur Fontaine, Lotus Notes for Linux will be available for users to download as of July 24th, 2006. This will be the first piece of enterprise software offered on the Linux desktop by the blue giant.

In creating Lotus Notes on Linux, IBM has used the Eclipse Rich Client Platform, a component of the Eclipse Foundation. This is the same component that IBM is using extensively in ‘Hannover’, the next major Lotus notes release, due to be released sometime in 2008. Due to it’s Java backbone, Hannover will be able to run across Windows, Linux, Mac, and any other machine which supports a Java Virtual Machine.

assert_select Plugin Allows you to Run Funtional Tests on your .rhtml

assert_select picture

Ruby Inside just posted an interesting tidbit about the assert_select plugin written by Assaf Arkin. This is a cool little plugin which allows you to run functional tests on your .rhtml pages.

I wasn’t aware of a previous method to run functionjal tests on HTML elements, but I guess that *should* be a valuable part of our testing cycle.

Anyways, this is a cool little plugin. I think it will soon be added into some of my personal projects. Here are some code examples for it:

def test_login_form_has_all_fields
get :login
assert_select "form[action=http://myapp/login] input" do |inputs|
assert_equal 3, inputs.size
assert_select inputs[0], "input[type=name][name=username]"
assert_select inputs[1], "input[type=password][name=password]"
assert_select inputs[2], "input[type=submit][value=Login]"
end
end

And another one….

# Form includes four input fields
assert_select "form input", 4

# Page does not have any forms in it.
assert_select "form", false, "Page must contain no forms"

# Page has one link back to user's page.
assert_select "a[href=?]", url_for(:controller=>"user", :id=>user_id),
:count=>1, :text=>"Back to page"

19 Rails Tricks Most Rails Coders Don’t Know

I just came across this on Digg… There are alot fo great suggestions for anyone who codes with Rails. There are about 20 tips here, most of which I thought were good to know, especially as I hadn’t come across them, read, or even thought of them before….

This is a must-read for any serious rails coder!

read more | digg story

MVC: The Most Vexing Conundrum

Elementary explanation of the Model/View/Controller design pattern, particularly as it applies to Ruby on Rails. Extremely concise explanation that should be everyone’s first stop in understanding Rails (or any other MVC based framework). I wish I had found this a month ago.

Anyone who writes any Rails code should have a solid understanding of MVC, since it is the basis of just about everything you do in rails. To provide a bit of a preview to what you find in the article, MVC, which stands for ‘Model-View-Controller’ is a design pattern commonly used by Web apps. A Design pattern is an architecture for writing software. Common design patterns such as MVC have evolved over time as developers find better ways of doing things.

The MVC essentially advocates dividing your program into three somewhat seperate parts. The Model, which handles your data records, the Controller, which handles what operations can be performed on the data, and the View, which governs how the results of Controller operations are displayed.

If you are new to Ruby on Rails, or haven’t heard of the MVC pattern before, I would really recommend you read the article!

MVC: The Most Vexing Conundrum

read more | digg story

« Previous Page — Next Page »