Caydel’s SEO Blog

I was just recently reading an article on the Sztywny Blog where the author sent a number a questions to a variety of today’s famous and great programmers. While he did not get replies from all the people he asked, he did get responses from

• Linus Torvalds - Linux Kernel
• Dave Thomas - Author of Pragmattic Programming, other great books
• David Heinemeier Hansson - creator of Rails
• Steve Yegge - Author of Wyvern, has a great programming blog
• Peter Norvig - Research Director at Google
• Guido Van Rossum - Creator of Python
• James Gosling - Java language creator
• Tim Bray - author of the Atom and XML specifications, as well as a blogger.

Many questions are asked, including where these guys learned programming, important skills, the value of math and physics with regards to programming, the future of programming, their favourite technology, their favourite tools, books and much more - a great read!

One thing that does come across while reading the article is that David Heinemeier Hansson is a very different breed of programmer from the rest of the people interviewed. At least, it seems to me that his answers stand out from the rest. He seems to be less of an academic, as a practicing programmer. That may not be the most accurate way to state the difference, but it is the best I can do.

Regardless, these are some of the top minds in the business, and there is a lot of interesting points they make. Very good reading for any programmer or Computer Science student. If nothing else, read the section where they describe their favourite tools - You may find a better environment than what you currently use!

Share This

First, before you read this article, I would suggest you read my first post on the subject, and this article.

So now you know what MVC is. You know why it is important when designing web apps, and why is is considered essential in Rails coding.

Rails disciplines you into using MVC. I have been programming with Rails for about 2 weeks. Through the process, and being forced into using MVC, I have also begun to think in MVC terms. In fact, the Model-View-Controller design pattern has become almost second nature to me. I can’t think of a clearer way to design a web application.

This is amazing to me, because I used to be, and in many ways still am, a sloppy programmer. I ran by the seat of my pants, without much over-arching architecture, and little true design. My code always worked, and well too, but was a nightmare of a tangle to read and maintain. I am amazed at the clarity and simplicity that is presented when using Ruby on Rails. I can actually make sensible UML diagrams of my work, without it looking like Medusa’s hair.

That is why I would push for every programmer to build at least one project in Ruby on Rails. Not only will you find that your coding time is cut down, due to the quick nature of Ruby on Rails, but you will also be forced into using good style. Well, maybe not, but you will be forced into using design patterns. That is a great advantage in the long run.

Share This

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.

Share This

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!

Share This

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"

Share This

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

Share This

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

Share This