Great Scientific American Editorial
Posted by Curt Hibbs
Wed, 30 Mar 2005 08:00:00 GMT
Just to show that they are not all that stuffy, Scientific American published great April Fools editorial in which they apologise for being biased towards “Charles Drawin and his cronies” and for “shamefully mistreating” Creationists and Intelligent Design theorists.
I love it! Here’s a snippet to pique your interest, but use the link above to read the whole thing (read it soon, before Scientific American makes the poster remove it, as SciAm has a policy against this).
Okay, We Give Up
By The Editors
There’s no easy way to admit this. For years, helpful letter writers told us to stick to science. They pointed out that science and politics don’t mix. They said we should be more balanced in our presentation of such issues as creationism, missile defense and global warming. We resisted their advice and pretended not to be stung by the accusations that the magazine should be renamed Unscientific American, or Scientific Unamerican, or even Unscientific Unamerican. But spring is in the air, and all of nature is turning over a new leaf, so there’s no better time to say: you were right, and we were wrong.
In retrospect, this magazine’s coverage of so-called evolution has been hideously one-sided. For decades, we published articles in every issue that endorsed the ideas of Charles Darwin and his cronies. True, the theory of common descent through natural selection has been called the unifying concept for all of biology and one of the greatest scientific ideas of all time, but that was no excuse to be fanatics about it. Where were the answering articles presenting the powerful case for scientific creationism? Why were we so unwilling to suggest that dinosaurs lived 6,000 years ago or that a cataclysmic flood carved the Grand Canyon? Blame the scientists. They dazzled us with their fancy fossils, their radiocarbon dating and their tens of thousands of peer-reviewed journal articles. As editors, we had no business being persuaded by mountains of evidence….continued at Scientific American Digital
Posted in other | no comments
Posted by Curt Hibbs
Sun, 27 Mar 2005 08:00:00 GMT
Bowing to heavy pressure from the throngs of anxious Ruby on Rails users (and wanna-be Rails users), Dave Thomas has graciously agreed to make a pre-release version of Agile Web Development with Rails available. If you purchase you copy now, you get to download the pre-release version now as a PDF, and then the final version later when its ready (in August).
What are you waiting for? You know you want it . . .
Posted in rails | no comments
Posted by Curt Hibbs
Sat, 19 Mar 2005 08:00:00 GMT
I series of recent events just caused me see Ruby on Rails from a new perspective: how, in one small way, it helps to enable collaboration. There is a short cause-and-effect story here, so please bear with me…
A few days ago James Britt asked on the ruby-talk mailing list what people were using to replace Meetup.com now that they started charging outrageous prices. I offhandedly mentioned that John Long and Ryan Platte were planning to write a replacement for Meetup.com in Rails as their entry in the Rails Day competition (they are still looking for a third partner if you are interested).
I’m not planning to enter the competition myself. But I began to ponder about this: if I was going to join in and partner with John and Ryan, how would we divide up the work so that we could work effectively while being physically remote.
Now I realize that there is nothing earth-shattering or profound about my answer to myself—it’s really a small thing. I would quickly define a first-cut on the database schema, create the models and generate scaffolding for them… the easy stuff in Rails. Within minutes, we would have a live, functioning database and a skeleton webapp with CRUD operations on all of the tables.
This would be the starting point from which the team would begin separate development. Everyone on the team would have a fully functioning system on which to begin crafting their particular UI assignments.
I’ve always appreciated this aspect of Rails for individual development, but it hadn’t occurred to me how easily this also enables group development.
Posted in rails | no comments
Posted by Curt Hibbs
Fri, 11 Mar 2005 08:00:00 GMT
I got a lot of flack for what I wrote in my ONLamp.com article on Rails when I said you could get a 10x productivity increase using Rails vs. a typical Java framework. The funny thing is that I thought I was being conservative!
Anyway, I spent some time talking with Bruce Tate this weekend (author of Better, Faster, Lighter Java, Bitter Java and Bitter EJBs) and he was able to confirm that my claim is not out of line (he likes to say 5x to 10x increase). Obviously your mileage will vary depending on circumstances, but based on the details I got from Bruce, I still think that 10x is a good ballpark number.
Some of these details have been reported before (DHH even commented on some of this in his Rails blog), but if you dig a little below the surface I think it is even more telling, so please forgive me for re-telling the story…
Bruce Tate and his partner Justin Gehtland were engaged by a client to replace an web app that had originally taken the company a year to develop. Justin took 4 months to reimplement this web app using Spring and Hibernate. Bruce characterized Spring/Hibernate as among the most productive frameworks available in the Java space.
Recently, Justin decided to re-implement with Ruby on Rails. Bruce said that this took a total of 5 days (Justin’s weblog reported 4 days for 80% completion so, presumably, 5 days is for the whole thing)!
Now this was all widely reported, and so far there’s nothing new here. But consider this:
- Justin is a recognized expert in Spring and Hibernate.
- Spring/Hibernate are not your typical Java framework (i.e., not Struts), but are the current best-of-breed.
- Justin was a novice with Ruby and Rails and knew practically nothing about either one.
Despite being an expert in the best-of-breed Java frameworks and a novice in the Ruby on Rails frameworks, he still managed an 8x improvement in productivity—this is very compelling! I can easily see how the productivity increase would be even higher if compared with a Struts-based implementation written by a non-expert.
But there is more… the Rails implementation actually ran faster than the Java implementation! Now this, too, was previously reported. This had baffled me somewhat, but Bruce thinks he knows why. He thinks its primarily because Rails has fewer layers to go through than the java stack, and the fact that the ActiveRecord ORM layer is much less generalized than Hibernate and can, therefore, be implemented much more efficiently.
Anyway, it feels good to have my 10x claimed confirmed by an industry expert who stated that he, too, was skeptical… until he had first-hand experience.
Curt
PS
Bruce Tate and David Geary (author of Core Java Server Faces , Core JSTL , and more ) have signed with O’Reilly to write a “Rails Developer Notebook” (obviously one of O’Reilly’s new Developer Notebooks series).
UPDATE: Justin has posted his detailed measurements, and they are very interesting indeed!
Posted in rails | no comments
Posted by Curt Hibbs
Thu, 10 Mar 2005 08:00:00 GMT
Last Thursday night we had the first meeting of the Saint Louis Ruby Users Group. Dave Thomas was in town and agreed to come meet with us. We had a great time, even though most of it was spent talking about things other than Ruby.
Nine people came, and most were new to Ruby. So we decided that a good thing to do next time would be to dissect a small Ruby program to learn how it works.
Posted in ruby | no comments
Posted by Curt Hibbs
Tue, 25 Jan 2005 08:00:00 GMT
The development community that surrounds a programming language or major technology usually has a distinct culture. This has been discussed often with respect to Python and Ruby, who share as many similarities as differences.
Chad Fowler just commented on a
concrete example
of one such difference. Its a short, but interesting read.
Now my code works. The bug is fixed. The plugin contains essentially nothing but a file that “monkey patches” some of the Rails core classes, implementing the changed version of the code.
When the change is merged into the Rails trunk, I’ll just ‘script/plugin remove’ Jeremy’s plugin.
Posted in ruby | no comments
Posted by Curt Hibbs
Sun, 23 Jan 2005 08:00:00 GMT
I loved that quote (the title of this post) from Edd Dumbill’s recent blog post,
Why Rails?
Now I’ve been using Rails for a while, I find its attractions have changed for me. The thrill of not having to write basic functionality over and over again has given way to more select pleasures. Writing in Ruby itself is a rewarding experience, as its idioms become plainer over time.
Sure, you can write Java or Perl in any language, and that’s where I started off. But the subtle elegance of the Ruby idiom is a slowly appreciated and highly satisfying flavour. For developers who consider themselves as poets and artists too, I can’t think of a better language.
Posted in ruby | no comments
Posted by Curt Hibbs
Fri, 21 Jan 2005 08:00:00 GMT
Hot on the heals of yesterday’s
TurboGears vs. Ruby on Rails
posting, there is this interesting
Ruby vs. Lisp
post.
Posted in ruby | no comments
Posted by Curt Hibbs
Thu, 20 Jan 2005 08:00:00 GMT
Do you know how to use all of those advanced Google search commands (like looking up someone’s phone number with “phone:name-of-person“)? If you’re like me, you know a few (like the “site:” keyword), but you still have this nagging feeling that you’re missing out by not knowing more.
Well, fear no more—here’s
a nice summary
of the most useful Google search commands.
After reading this article, you might be thinking “well, I could probably find those results without remembering these advanced search terms”. Well, the truth is that you probably could. The reason you want to start to use these advanced search tips is because they will help you find what you’re looking for faster. They greatly help narrow down the results, and more often than not, the information you were looking for will be in the first two or three results.
Posted in other, technology | no comments
Posted by Curt Hibbs
Thu, 20 Jan 2005 08:00:00 GMT
I just read this
nice little comparison
of Python’s TurboGears with Ruby on Rails. I think its a fairly balanced comparison. The author prefers TurboGears, but if you value productivity through less code, then Rails still comes out on top:
The immediate first impression is that TurboGears is more verbose(or explicit, if you like) than Rails. For example:
RoR:
class NewsController
@articles = Article.find_all end
end
TG:
import cherrypy
import turbogears
from turbogears import controllers
import model
class News(controllers.Controller):
@turbogears.expose(template="news.templates.index")
def index(self, **kw):
return dict(articles = model.Article.select())
One thing to note is how you have to tell TG what methods to expose to the web, which template to use, and what data goes in the template. In RoR this is decided for you; every method by default is exposed, any data in the method goes in the template, and the name of the template is the same as that of the method (in this case, index.rhtml). You can override these, but a lot of assumptions are made on your behalf.
Posted in rails | no comments
