July 07, 2008 | Comments: (0)
I've seen several blogs and comments in news stories recently that boil down to the observation that programmers gravitate either to Python or Ruby for scripting, but not both. I guess I'm the exception that proves the rule: I've done Web templating projects using Python, and Web site projects using Ruby on Rails. For that matter, I've also done Web site projects in plain HTML, Perl, classic ASP and ASP.NET.
In my lab test of Rails IDEs I covered 9, count 'em 9 products. What was I thinking? I can't believe I did that. It was way more work than I'd planned on.
I started out proposing a review of Ruby in Steel Developer 1.2 on the strength of its unique Visual Rails Workbench, but reviewing that by itself didn't make sense to me. Then I thought I'd review Ruby in Steel against other Rails IDEs, but there turned out to be quite a few of those. And then I realized that I was leaving out TextMate and its clones. So, like Topsy, this review "just grow'd." I drew the line at editors that only know about Ruby and lack any Rails-specific features, but as I mentioned in the introduction to the article, you can make those work as well.
In Eric Knorr's Editor's Blog this week, he mentions the claims that Ruby on Rails scales poorly and lacks a security model. As far as I'm concerned, if good scaling and low latency are critical to your site, perhaps Rails isn't the right technology for you. On the other hand, Rails might be one of the fastest ways to develop a prototype site that you can throw away later. I wonder whether Twitter was supposed to be a throwaway prototype. But if that's the case, why haven't they rewritten the Twitter service so that it'll scale better?
Speaking of Ruby and scaling, Tim Bray knowingly used a naive Ruby script as the strawman benchmark for his Wide Finder 2 project. 78 lines of Ruby code analyzed 45 GB of Web logs in 25 hours. The strawman used only one of 32 possible hardware threads. If you look at the project results so far, you'll see scripts in Python, C++, Perl, Scala, Fan, Java, Groovy, OCaml, and gmake+sh+awk+C. The current champion is written in OCaml, a dialect of ML, and runs in 5 minutes using 31 worker threads.
Some of the speed difference certainly has to do with algorithms and threading. But some of the speed difference probably has to do with the slowness of the Ruby interpreter and libraries. If 5 minutes is roughly the I/O-bound time for this task using 31 worker threads, then a naive script running in one thread shouldn't take more than 160 minutes, or 2.67 hours. There's another factor of 9 to account for: is that because of Ruby?
Caveat coder.
Posted by Martin Heller on July 7, 2008 08:33 AM
June 12, 2008 | Comments: (0)
While working on a roundup review of Rails IDEs and editors, I tried to draw on my large stack of Rails books, only to find that they're all at least a little out of date. For example, Agile Web Development with Rails: Second Edition basically covers Rails 1.2. Agile Web Development with Rails, Third Edition covers Rails 2, but it's still only available as a beta e-book. That may be a good thing, as the authors will have a chance to add the updates for Rails 2.1. I don't know if they'll actually do that, though.
The Rails Way covers Rails 2.0, but not the changes in 2.1. Advanced Rails Recipes is for Rails 2.0.2.
Can books keep up with the changes to new software? Not just Rails: any new software.
There are ways to handle change. For example, Essential Silverlight 2 Up-to-Date is a combination of a loose-leaf book and Web updates. It was written for Silverlight 2 beta 1; beta 2 has now come out. Update 1 to the book came out in May covering the TextBox control and data binding, but no update for beta 2 has yet appeared.
The necessity for that scheme, and the decreasing sales of computer books, raises an even more disturbing question: Are computing books as a category becoming obsolete?
What do you think?
Posted by Martin Heller on June 12, 2008 09:08 AM
June 04, 2008 | Comments: (0)
Those of you who are open source developers have probably already figured out that I'm going to talk about Git, the version control system, and that no, I don't actually mean "Git going" for most of you. If you're already using Git, then do git going: there's probably nothing new for you to see here, unless you have something to add.
The short summary is that Git is the version control system that Linus Torvalds wrote for managing the Linux Kernel development. It's a distributed version control system focused on speed, effectiveness and real-world usability on large projects, and one of its strongest points for open source projects is that it has an easy way to send patches by e-mail, which vastly simplifies projects with many submitters and few committers.
Aside: At one point in my caving career I was with a college-age group from Pennsylvania about to rappel into an unexplored pit in West Virginia. A yellow lab had been following us, and we Yankees were concerned that it would try to descend with us and be hurt.
"Go home!" had no effect, no matter how loudly we shouted. It finally occurred to me that this was a Dixie dog. Time to switch to his native language.
"Git on home! Git!"
That did the trick. He got.
It came as a surprise to me in the past couple of months when the Ruby on Rails (RoR) repositories moved from Subversion to Git. They're now at http://github.com/rails/rails. Shortly thereafter, the RoR tracking system moved from trac to http://rails.lighthouseapp.com/dashboard. Let me concentrate on Git for now: Lighthouse is another story.
As the RoR blog said in April:
GitHub has now officially launched and Rails is right there at the premiere. The Rails repository now lives at rails/rails and you can check it out with:
git clone git://github.com/rails/rails.git
If you don’t have git, or don’t enjoy running it on your platform, you need not fear. We’ve set up an automated task to produce a zip file of Rails Edge that’ll be kept up to date all the time: http://dev.rubyonrails.org/archives/rails_edge.zip. This is also what we’ve made the new rake rails:freeze:edge use.
When Rails 2.1 was finally released on June 1, the blog posting included these instructions:
As always, you can install with:
gem install rails
...or you can use the Git tag for 2.1.0.
I was able to download and install msysGit for Windows from http://code.google.com/p/msysgit/downloads/list. I installed only the Git bash shell, to avoid any interference with my C Shell and the standard Windows command-line utilities.
To learn Git, I'd recommend one or more of the Git Crash Courses: Git for everyone, Maintaining external patches, and Git for SVN users. Using Git effectively requires a slightly different way of thinking than using Subversion effectively, so be prepared for some temporary disorientation: I'm told it'll pass.
Posted by Martin Heller on June 4, 2008 11:53 AM
May 20, 2008 | Comments: (0)
I'm gearing up to write a comparative, multi-platform review of Rails IDEs. Before I freeze the list, I'd like to know what other people are using themselves to develop Rails sites.
Currently I'm considering these 8:
- Ruby in Steel
- Aptana RadRails
- Komodo
- 3rdRail
- NetBeans
- SciTE
- TextMate
- jEdit with Ruby plugin
Do you have experience with any of these you'd like to share?
Do you use something else for Rails development?
What are the strengths and weaknesses of the Rails IDEs you use yourself?
Posted by Martin Heller on May 20, 2008 11:16 AM
May 07, 2008 | Comments: (0)
Joyent has changed for the better, VP says
When I wrote about the Morph Application Platform on Tuesday, I carelessly tossed off a reference to my mixed experience with Rails hosting at TextDrive, now called Joyent. Kristie Wells of Joyent asked me to clarify my experience privately, and has since given me permission to post our exchange.
Here's my clarification:
Kristie, you asked about my TextDrive hosting experience. It was for [name removed], in 2006. My name didn't appear on the account, but I supervised the software development. I'm no longer associated with those thieves.
The deployment was successful, but lengthy and painful. I realize that the hosting account was dirt cheap, but we had to fight multiple issues: needing a lighttpd instance and port for Rails, needing to integrate that with Apache, needing to set up the user control mechanisms, needing to set up secure developer access. The fact that my background was heavily slanted towards Windows didn't help. TextDrive support was ultimately helpful, but not exactly super-responsive at the time.
Kristie responded:
Hi Martin,
Thank you for clarifying. The post made your experience sound current, which concerned me greatly.
Joyent has changed, a lot, over the last two years. We recently launched a new shared hosting environment on our Accelerators as we are moving away from the BSD servers that were far from happy. Things have been streaming along nicely since that change took place. You know, just FYI, in case you ever wanted to give us a lookie again.
Thank you again for your response.
Be well.
Cheers,
Kristie Wells
VP, Customer Advocacy
Posted by Martin Heller on May 7, 2008 11:55 AM
May 06, 2008 | Comments: (0)
Rails, and now Java, in the cloud
I had a conversation today with David Abramowski, CEO of Morph Labs. We were supposed to talk about how Morph Application Platform, which uses Amazon EC2 and S3 for on-demand cloud computing and storage along with its own routing and provisioning infrastructure, compares with Google App Engine, which uses Google's own cloud infrastructure. That part of the conversation was short, though, because beyond the fact that they're both on-demand cloud computing platforms, the two have nothing in common. I was put in mind of Shakespeare sonnet 130, My mistress' eyes are nothing like the sun.
Google App Engine, as I've discussed previously, currently supports only Python for an implementation language and BigTable for a (join-less) database, with Django and a simpler Python Web framework developed at Google both on offer to structure a Web application. I can't yet speak to what deployment is like on Google App Engine, as I signed up too late to get into the beta.
Morph currently uses Ruby on Rails as its framework, and PostgreSQL as its database. Today's announcement at JavaOne was for a beta release of Morph Application Platform for Java, developed in collaboration with Webtide. Abramowski expects the beta to fill up in a couple of days.
I was actually more interested in the Ruby version of the Morph Application Platform than the Java beta for my own projects. I've signed up for a free developer account. I've run into a snag subscribing to the DevCenter service that will let me access an "AppSpace," but I imagine that will be fixed before long, and I'll be able to say something about the service first-hand. It almost has to be better than the Rails hosting experience I had at TextDrive, now called Joyent.
Meanwhile, two user quotes from the Morph Web site:
"Morph is a great service. Deployment is simple. I give them lots of points for ease of deployment. They can help you scale as they are using Amazon's services on the back end."
- Justin Ball from www.justinball.com
"Morph AppSpace is the best experience we've ever had for Rails deployment. We can scale to as many app servers as we want in minutes, and then scale back as demand changes. We are also happy about the effortless deployment and the amazing client support. The Morph guys were helpful before, during, and after. From now on, we'll be using Morph AppSpace in releasing all our new applications."
-Jim James, www.mytripscrapbook.com
Posted by Martin Heller on May 6, 2008 01:03 PM
December 10, 2007 | Comments: (0)
Installing Rails 2.0 on Windows XP
In response to Friday's news story that Ruby on Rails 2.0 had been released, I decided that it was time to update my installation. I opened a C-Shell on the Windows box I use for Rails development, typed "gem update", and promptly ran into trouble. I'm not sure why, but some of the updates failed. Maybe it's because the different packages that make up Rails all list each other as dependencies. I tried again with "gem update rails", but ran into more trouble and finally gave up.
I decided to start fresh, so I downloaded the latest version of the Ruby One-Click Installer from RubyForge, uninstalled my old Ruby version (1.8.5, which should have been good enough for Rails 2.0), and installed the new version, 1.8.6. I opened a C-Shell, typed "gem install rails --include-dependencies", and was told that no "gem" application was found.
Gems was part of the One-Click Installer, but I downloaded the latest Ruby Gems package from RubyForge anyway, unpacked it, and ran setup.rb. It removed the version that was part of the One-Click Installer, which was one revision back, and installed itself.
I opened a C-Shell, scrolled up to "gem install rails --include-dependencies", and was again told that no "gem" application was found. I tried the All Programs|Ruby-186-26|RubyGems|RubyGems Package Manager menu item, and got the Gems quick help, so Gems was there. I tried "gem install rails --include-dependencies" yet again, and yet again was told it wasn't there. By this point I was starting to suspect a path issue, so I tried "c:\ruby\bin\gem" instead of "gem". This started to run, but failed to perform the installation.
I opened My Computer|Properties, went to the Advanced tab, opened the Environment Variables box, and checked the two Path variables. As I suspected by that time, Ruby wasn't there: the uninstall had removed it, and the reinstall had not added it back. I added ";c:\ruby\bin" to the end of my User path, closed the dialog, and once again opened a C-Shell. Finally Rails installed properly, at version 2.0.1. While I was thinking about it, I also installed the Rake Gem.
Nothing is ever easy.
Posted by Martin Heller on December 10, 2007 08:35 AM
July 30, 2007 | Comments: (0)
A few weeks ago I mentioned Aptana RadRails and noted that, although I was able to download and install Aptana, I was unable to install the RadRails plugin on Windows XP SP2. I reported this directly to Aptana support, and they initially didn't know what could be wrong: the Aptana error log was not helpful.
About once a week, I updated Aptana and tried to install RadRails. Last week, finally, it worked.
My initial impression is that Aptana RadRails retains all the strengths that RadRails had in its previous incarnation, and is stronger still because of the JavaScript support provided by Aptana. I have to admit, however, that I'm not actively working on a Rails site right now: the Rails site I worked on last summer is in production with growing content, but it's stable and we're not adding features or changing the code.
I'd be interested in what other Rails developers think of Aptana RadRails. Leave a comment here, or email me at martin_heller@infoworld.com.
Posted by Martin Heller on July 30, 2007 08:25 AM
June 27, 2007 | Comments: (0)
Ruby on Rails IDEs: More Free Options
The comments to my posting about Ruby on Rails IDEs on Monday have reminded me about other free options for Ruby on Rails development. First, there's NetBeans 6.0. I didn't really think about that when I was writing, because the current version of NetBeans, 5.5.1, doesn't have Ruby support. NetBeans 6.0 is at Milestone 9; the Full version (not the Basic or Standard versions) has Ruby support.
NetBeans is free and Open Source. I haven't tried NetBeans 6.0 M9 myself: I've been waiting for the release version. I'd love to hear what others think, however.
Second, Paul Colton would like you to know that
"RadRails is now officially called 'Aptana RadRails' and it is open source and free and will remain that way. Aptana RadRails also fully supports debugging."
I have been able to download and install Aptana myself, but when I try to install the Ruby on Rails support I get an exception. I'll be working through this problem with the Aptana people.
Third, Ruby In Steel has a free Personal Edition available. The differences between the free Personal Edition and the Developer Edition are listed here. The biggest differences in my mind are two features in the Developer Edition: the fast debugger, and the IntelliSense support.
Finally, even though no one has reminded me, I should mention that the Komodo IDE also has a free sibling, Komodo Edit. The differences between Komodo Edit and Komodo IDE are listed here.
Posted by Martin Heller on June 27, 2007 07:29 AM
June 25, 2007 | Comments: (0)
As you might expect, the Rails IDE market is continuing to evolve quickly. RadRails, which I reviewed last August, has been taken over by Aptana. What's Aptana? It's Paul Colton's new company. Paul was the founder of Live Software, and the creator of JRun. Aptana's major product, still in beta, is the Aptana IDE:
"The Aptana IDE is a free, open-source, cross-platform, JavaScript-focused development environment for building Ajax applications. It features code assist on JavaScript, HTML, and CSS languages, FTP/SFTP support and a JavaScript debugger to troubleshoot your code."
RadRails has become Aptana IDE + Rails. To install the current RadRails, you download and install Aptana, then add the Rails development feature from within Aptana. You can also download and install the Aptana and Rails plug-ins for Eclipse 3.2 or later.
Meanwhile, Ruby in Steel, the Ruby and Rails add-in for Visual Studio 2005, is up to version 1.1. This is a minor release, which includes the thread-safe debugger. I'm looking forward to the 1.2 release, planned for the end of the summer, which will include a Visual Web Page Designer for Rails. As I mentioned when I reviewed Ruby in Steel 1.0 in February, the product has fast debugging and great IntelliSense support.
Finally, ActiveState Komodo is up to version 4.1.1. Version 4.1 added Ruby on Rails support to the many other dynamic languages supported by Komodo. (I reviewed a beta of Komodo 4.0 in January.) ActiveState claims that it now has "the most advanced Ruby and Rails support in any IDE," and claims that its "lightning-fast Ruby debugging" is "now 60 times faster!"
While this may sound just a little like hype, I can say that Komodo really is very good. Have I compared the Komodo Ruby debugger with the "Cylon" debugger in Ruby in Steel? No, I haven't. At least not yet.
Stay tuned. Meanwhile, Komodo and Ruby in Steel are both available for timed free trials, and the Aptana IDE + Rails, which is in beta, is still free.
Posted by Martin Heller on June 25, 2007 07:02 AM
February 14, 2007 | Comments: (0)
On January 24, I discussed a not-very-focused book on Ajax, and mentioned its diversion to a discussion of Rails:
"Near the end of the journey, we detour to Ruby on Rails, and finally get to its Ajax support; I'm not completely sure why Woychowsky bothered with that particular side trip."
And now for something completely different: a pleasant surprise. Scott Raymond's new book Ajax on Rails (O'Reilly, 2007, 336 pp., $39.99, ISBN 0-596-52744-6) discusses Ajax and Ruby on Rails, focusing on the Ajax support in Ruby on Rails in just about the right depth for most developers, and offering some valuable insight without going too far afield.
Scott is a Rails insider: he's one of the developers of the framework. His book has the unmistakable ring of experience, and it is well-organized and well-written. The chapter on RJS (Ruby-generated JavaScript) is especially welcome, but his chapter on debugging and testing Rails is quite valuable, and his chapters on Rails security and performance will help people lock down and tune up their applications.
I'm not sure how much value the extensive references to the Prototype and script.aculo.us JavaScript libraries will have for Rails developers. Is this just dross to get the page count up, or is it useful? I've done enough JavaScript development that I might come down on the "merest dross" side of the argument, but there may well be Ruby developers for whom JavaScript is enough of a mystery to justify the space spent on this reference material.
Posted by Martin Heller on February 14, 2007 06:00 AM
January 29, 2007 | Comments: (0)
REST and CRUD: the Impedance Mismatch
As you probably know, CRUD is, among other less savory things, the most common acronym for the four basic functions of persistent storage: create, retrieve, update and delete. As we discussed on January 26th, RESTful architectures apply these four basic functions in a regular way to a set of resources. If the RESTful architecture is a Web site, then the CRUD operations create, retrieve, update and delete map to the HTTP methods GET, PUT, POST, and DELETE.
What's wrong with this picture? The HTTP 1.1 standard defines eight methods (or verbs): HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, and CONNECT. Web service clients sometimes use all eight. Web browsers, however, typically only issue GET, HEAD, POST, and sometimes PUT requests. Most browsers are not currently capable of issuing HTTP DELETE requests.
Tilt!
So how does Ruby on Rails 1.2 implement a RESTful interface for the delete action without getting an HTTP DELETE request? Simple: it cheats.
Actually, this gets ugly. To cause a delete action, when implementing the :method => :delete option in link_to, Rails uses JavaScript to generate a dynamic form with a hidden field named _method, and sets the value of the field to delete. When a Rails application receives a form with a _method parameter, it causes the parameter value to override the real HTTP method verb.
I thought I understood the benefits of RESTful architecture, but this implementation leaves something to be desired.
Posted by Martin Heller on January 29, 2007 06:00 AM
January 26, 2007 | Comments: (0)
The much-anticipated Ruby on Rails 1.2 update has shipped, as has the second edition of Agile Web Development with Rails. As our earlier news item mentioned, a major feature of Rails 1.2 is REST (Representational State Transfer) functionality.
I have updated my own Rails installation to version 1.2.1 and have run a full set of tests on local copies of the Rails applications in which I have been involved. I got pages of warnings and feature deprecations. I'm in no hurry to upgrade the production sites, which are running just fine on Rails 1.1, thank you, but I'm planning to use Rails 1.2 for my future Rails sites.
Unless you've been following the Rails evolution or REST itself, REST is probably a new term for you. The term is about 6 years old; it originated in a thesis by Roy Fielding. The following figure from the thesis summarizes how the constraints of Representational State Transfer derive from other architectural styles:
Fielding's thesis is a bit daunting; fortunately, several people have jumped into the breach to explain REST to mere mortals. Many of these articles are listed on the REST Wiki; one of my favorites is REST In Plain English. That article explains how a uniform interface and statelessness look in the real world, or at least in the real Web.
An even better discussion of REST, one that relates directly to Rails 1.2, appears in Chapter 20 of Agile Web Development with Rails. The section from Chapter 12 on creating a REST interface is also quite good, and is available here.
Basically, what Dave Thomas has to say about REST in Chapter 20 is that
"in REST, we use a simple set of verbs to operate on a rich set of nouns. If we're using HTTP, the verbs correspond to HTTP methods (GET, PUT, POST, and DELETE, typically). The nouns are the resources in our application. We name those resources using URLs."
So, the difference between the old way of writing Rails actions and the REST way is that we don't invent a lot of actions with verb phrases as names. Instead, we use standard verbs, and take advantage of Rails' new resource routing facility, embodied in the map.resources keyword to ActionController::Routing::Routes.
Posted by Martin Heller on January 26, 2007 06:00 AM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Solution for Open Virtualization Provides Server Consolidation
- Help Simplify Virtualization
