KillerSites Blog

Ruby

Writing a standlone, threaded application using Ruby On Rails

January 20, 2007

ruby language logo

Hi,

A little while back I asked my brother (a big Java nerd) to explore using Ruby to rewrite a threaded Java web application – a site monitor.

The results have been really cool so far. So cool in fact that I asked him to write an article on his experience.

NERD ALERT: This article is written for programmers.



Writing a standlone, threaded application using Ruby On Rails

By Richard Mischook

Awhile back I wrote a Java application designed to monitor web sites to ensure they are up and running. The Site Monitor service is hosted on the web and allows a user to sign up and add a site to a database that is routinely monitored by the engine.

When the engine finds that a site is down, a log entry is made and the owner is sent an email letting them know that they might want to look into it; if and when the site is back up, another log entry is made and once again the owner is emailed.

The development of the application took a little longer than expected and alas, has had a number of teething pains. On more than a few occasions we have asked ourselves if another set of implementation choices might have been better, such as a technology other than Java.

In addition, rather than delivering the tool as a hosted service, would it make sense to deliver some sort of standalone application that a user could download and run on their own desktop?

Around the same time I had been messing around with Ruby On Rails which as many of you will know, is a web application framework build on the Ruby scripting language. One of the central promises of Rails is a framework that allows the delivery of powerful results quickly.

The questions then:

  • Could the Site Monitor be delivered using Rails and if so;
  • How long would it take and would it be better than the existing solution?

Requirements

The Java version of Site Monitor is actually reasonably sophisticated and supports a range of features which I will not exhaustively list here.

Instead lets look at the main features we wanted to see in the Rails version:

  • Support for multiple sites checked concurrently, with sites double or tripple checked to make sure they were really down.
  • Support for multiple control sites to verify that the internet connection to the outside world is up
  • Support for multiple notification email addresses and mobile phone numbers (for SMS notification)
  • Configurable by the user with the choices saved to a file that is loaded when the engine is re-started
  • An Ajax-based user interface allowing the user to a) configure the engine and b) capable of displaying engine activity
  • An easy to install application suitable for Microsoft Windows users.

An example of the user interface can be seen in the screen shots. The web interface leverages the Ajax support built into Rails and allowed me to deliver a richer user interface than normally found in traditional web applications

site monitor control panel

In fact as I’ll show later, some limitations in the Ruby threading model made it necessary for me to use the Ajax support in a way that I had not originally anticipated.

The hardest requirements to fulfill were going to be the first and the last:

i) support for concurrent checking and ii) an easy to install application.

Most of this paper will be about how I tried to address the first requirement, but I will discuss the second as well.

site monitor control panel

Concurrency in Ruby

In the original Java version of the application, a timer ran from time to time (say once a minute) and invoked a method to load a list of sites to check from a database. A Java thread was retrieved from a thread pool for each site that required checking; this meant that more than one site could be checked at a time.

This was important because it might take awhile to finish checking a site since we were actually double or tripple checking sites that did not respond (in order to avoid false positives). Without threads, it would take significantly longer to check a stack of sites as each site would be required to wait in line (so to speak) to be checked.

The good news was that Ruby has a threading model and it seemed very easy to implement. The check_sites method below (which is abbreviated for clarity) illustrates the main logic which is essentially:

  • for each site (line 2), spawn a thread (line 3) and execute the block of code from lines 3-17
  • check the site (line 5)
  • if the site does not respond (line 7) and we have verified count number of times that the site is down, let the user know (line 11)

-

1 def check_sites(sites)
2 sites.each do |site|
3 threads < < Thread.new(site) { |mySite| 4 begin 5 ping_site(mySite) # actually ping the site 6 handle_up(mySite, ...) # site is up so let user know IF site was down before 7 rescue ConnectException => c #if here then no response
8 count = count - 1 #count is set to some value above (not shown)
9
10 if count == 0 #log it and send mail
11 handle_down(mySite, ...) #another method that logs and sends email not shown here
12 break;
13 else
14 #check control sites [not shown]
15 end
16 end
17 }
18 end
19 threads.each { |aThread| aThread.join }
20 end

-

Note that there are few key bits missing from the above so don’t expect it to run by itself. That said the principle is sound and means that given an array of sites to check, processing will happen concurrently. But there is an issue that I did not anticipate: any code calling this method will block until all the child threads created in check_sites are done. This is a problem because what I had planned was to define a method like the following:

1 def start_engine
2 # load some sites ...
3 while(true)
4 sites = ... #not shown - code to load sites
5 threads = []
6 threads < < Thread.new(sites) { |mySites| 7 check_sites(mySites) 8 } 9 threads.each {|t| t.join} 10 sleep(30) #sleep for 30 seconds 11 end #end of while loop 12 end

The start_engine method starts a loop that:

  • Loads a list of sites to check (line 4)
  • Creates a new thread and calls the check_sites method with the sites (lines 6 and 7)
  • Goes to sleep for 30 seconds (line 10)

The plan was for the sleep() call to happen immediately after calling check_sites but before all the checking was done, i.e. not block. Unfortunately Ruby doesn't work that way; in fact what actually happens is that the call to sleep() only happens after all the threads in check_sites have finished executing.

The other really big problem is that since the while loop is always running, the Rails server (e.g Webrick or Mongrel) is always blocked meaning it cannot serve any further requests - such as my web browser Ajax call to find out the current status. All of this meaning that I needed another way to do the job done by start_engine, i.e. another way of periodically calling check_sites.

You may be wondering why I wanted to run this in a Rails server at all? One answer is that I wanted to do the user interface as an Ajax-enabled web page but also wanted the user to be able to start the server and have the engine running in the background. Alas this was not going to work.

ruby site monitor interface

I thought for a second that I might need to think about spawning some seperate processes (rather than relying on Ruby threads), but that looked like a lot of work. I did look at using the backgroundrb library (a Ruby library for simplifying distributed, interprocess communication) but it is not supported on Windows (crappy toy operationg system *&&^%$). Instead I decided a compromise was in order.

Using Ajax to Run the Engine

The problem then: how do I replace the start_engine method such that I can get the server code to periodically check my sites (while allowing other stuff to work)? Well the answer simply enough was to embed a Rails periodically_call_remote tag in my index.rhtml page; the tag sends an Ajax request every so often to the server that gets it to call check_sites. In fact I also embedded a second periodically_call_remote tag that refreshes the user interface console so the user sees what is going on.

There is still a problem though: check_sites can still take some time if you are checking more than one or two sites and any fail to respond. While this is happening (the checking), the Rails server will be unable to answer any UI refresh calls (coming from the second periodically_call_remote tag). Still, not the end of the world as this version is meant for a single user checking a very small number of sites. On the other hand frankly, this is not the most elegant solution and one I would like to change.

In fact I did look at trying to spawn the Monitor in a seperate process using a fork call. Unfortunately the implementation on Windows is broken (anyone see a theme developing here?) In fact the Programming Ruby book's section on processes does suggest that support for forking is limited, which is better than the API documentation's thunderous silence on the matter.

Lesson then: Ruby is Unix-centric by default - live with it.

I did try and get around it by installing a set of gems associated with the Win32 Utils project - specifically win32-process. I did have some luck with this but not enough (the main issue having to do with class loading woes).

I do think that there is some potential in this route, but it would require me to spend a bit more time making sure the Monitor code is free of any Rails dependencies. In the meantime my next little project may be to start playing with win32-process to see if I can get it to work the way I think it should work.

Packaging Up the Whole Thing

I mentioned earlier that one of my other requirements was to try and package this thing up in such a way that I could distribute it as a single, easy-to-use windows exe or equivalent. What I was in fact hoping for was the ability of users to download the whole thing without having to install Ruby or Rails or any of the gems used by the application.

Now admitedly this was something of a tall order; but I was led to believe that it was worth looking at given an article entitled Distributing Rails Apps: A Tutorial.

Unfortunately my attempts have not met with any success; in fact when running the various tools I'm not really getting any feedback that indicates what, if anything went wrong, other than the fact that things just are not working (to be fair I only spent about 15 minutes on this). So I have added this to my list of things to look into; in fact it's top of the list since not getting this working will make distribution that much harder. I'll post a follow up if I have any luck on this front.

Conclusions

The application I re-built in Ruby actually works pretty well and the Ajax user interface does what I hoped it would do - even if it doesn't win any beauty contests. But Ruby threading, while easy to implement, suffers from a few limitations such as:

  • When spawning new child threads, the parent thread needs to block waiting for all the little kiddy threads to do their thing.
  • This is made even more of a pain by the fact that the main Rails runners, Mongrel and Webrick, can only handle one request at a time - period. It would be nice if someone could write an easy-to-use proxy that wraps a couple of Webrick/Mongrels so that you can have a single container that supports concurrent requests (yes I know you can do this with Apache but that requires that I do some work when all I want is a development environment that can support say - 2 concurrent requests).

Which brings me to another issue with Rails in general that has nagged at me: its reliance on process-based request handling. Each request has to be handled by a dedicated process which would seem to have the potential for limiting the scalibility of a Rails application.

Now I know that this debate has been raging elsewhere on the Interweb and I must confess I have not looked into it in great detail. At the very least it would suggest to me that anyone designing a Rails application really does need to keep that in mind, especially with regard to managing connections to databases. While that's a side issue, I invite any comments (and pointers) on the matter.

One last thing - my main interest in Rails has been fueled by my ever increasing lack of patience. Not so very long ago I was happy to spend days trying to understand some new API or product that promissed to be the next cool thing. This, some might say, was a prerequisite for becoming a Java J2EE developer.

These days, I have a wife and a baby, TV shows I want to watch, books I want to read - in other words - lots of other things I want to do. I want to get my work done NOW. I want to work with tools that are enablers - rather than impediments.

We're not there yet and truth be told, Rails is very good for developing data-driven green field web applications; but there are limits to what it can do and one wonders if it can (or indeed should) grow beyond these.

References

Programming Ruby: The Pragmatic Programmers' Guide, Dave Thomas

read more

Ruby on Rails RailsConf Europe 2006: a report.

October 1, 2006

RailsConf Europe 2006: a report.

by: Richard Mischook. www.killersites.com, www.killerajax.com

On September 14 and 15th I was at the RailsConf event in London. I don’t have the exact numbers but I’m guessing that there were somewhere between 500 and 1000 attendees. The age range included the expected contingent of 20-something geek types but perhaps surprisingly a large number of obviously older folks were also in attendance (the latter category sadly including me).

I say surprisingly because Rails is a relatively young technology that I think is still in its ‘early-days’ phase, albeit with a rapidly growing mind share. Despite this a number of maneger-types were on hand and presenting; this was particularly interesting to me as I am very interested in the issues surrounding using Ruby and Rails in the enterprise.

Before diving into a look at some of the details of the conference I will say that my overall impression is very good. I was reminded of the JavaOne conferences I attended in the late 1990s where the enthusiasm in the room was almost overwhelming.

Clearly the folk doing Rails are converts (often from Java) and believe that Ruby and Rails are better tools than much of what is out there.

Rails is fun

Rails developers are having fun: this is good because happy developers are productive developers; they are having fun because they are getting things done faster and spending far less time wrestling with the sorts of plumbing issues that kill creativity and make development a chore rather than a joy.

This fun flows from two things: the beauty of the Ruby language and the Rails framework. The Ruby language provides some very nice syntactic features that mean writing less code than would otherwise be the case with other languages.

Rails provides a variety of elements that make it fast and easy to deliver working code; some of the key features include the use of conventions rather than configuration (still allowing though for the overriding of those conventions), a number of great APIs for handling many web-application needs, the most prominent being perhaps an easy to use Object-Relational Mapping API (ActiveRecord).

Rails in the Enterprise

Rails is being introduced into the enterprise in the same way that Java was back in the late 1990; that is, by enthusiastic developers ‘sneaking’ it in. I heard a number of stories but one that certainly stuck goes like this:

(i) developer does quick prototype
(ii) developer shows prototype to manager who says it looks great
(iii) developer tells manager that he/she is ready to develop it in Java but it will take two or five or X time as long
(iv) manager says – but what’s wrong with this
(v) developer smiles.

Any new technology is bound to face reluctance from risk-adverse enterprise technology decision makers. This is (in my opinion) perfectly understandable; some good news though is that Sun has hired the main guys behind the JRuby project (allowing Ruby code to run in a Java Virtual Machine).

Currently JRuby will support running most Rails applications in a JVM. The roadmap for JRuby include a number of things including compilation of Ruby code to Java byte code. Speed of JRuby is currently not up to CRuby but this is the goal. For me the existence of JRuby signals Sun’s realization that the Java web frameworks are declining in popularity; for those of us in the (Java) enterprise, JRuby represents a possible risk mitigator if/when proposing Rails as a piece of a solution.

Performance and Scalability

Rails suffers from the same sort of performance and scalability issues as other frameworks but the approach to fixing these is pretty much the same as with other frameworks, e.g. tune your database queries, implement a caching framework, profile your code.

The flip side though is that delivering a result in Rails does appear to be significantly faster and involve writing less code. In addition Rails seems to strongly facilitate an iterative approach to development that is very attractive to those who accept the key tenets of the Agile school of thought.

Rails is Growing

Rails is growing fast: there are now some 300+ open source pluggins for Rails supporting a wide range of functions and APIs (for example messaging systems). The new Active Resource API supports treating a URL as a vehicle for doing CRUD using XML – web services without the overhead associated with SOAP.

Rails Development Tools

Tools support is growing: the next version of the RadRails Eclipse-based IDE will include support for refactoring; I asked the main developers about code-completion support (e.g. method completion) while acknowledging in my question the issues associated with doing this for a dynamic language. I was told that there was some work going on in this area and they hoped to be able to support it to some extent in the future.

Final Thoughts

Rails is an exciting framework for doing web application development that is I think in the early stages of a rapidly accellerating curve. The next year will I think be telling and it will be interesting to see to what extent Rails captures mind share and resources from other comparable frameworks.

read more

Is Ruby slow compared to php?

September 15, 2006

Like any good nerd, we’ve been experimenting with a little Ruby and Rails development – it is always good to try new things …

One thing we have noticed is that simple Ruby web apps (running on the same server,) are noticeably slower than PHP.

We installed fastcgi with apache 1.3 (took an hour to do) and are running simple web applications.

I will get into more detail in other post / articles.

read more

Java web hosting is still brittle.

August 24, 2006

It has been a couple of years since I moved (from in-house hosting) my Java based web applications to using an outside company.

When I was hosting my little apps from my Windows 2000 server (using Caucho Resin,) on a DSL connection, I never had a problem … probably because it was so small.

Since growing and moving to Tomcat on Linux, I’ve found that Java is not the most stable thing … it is not uncommon for Tomcat to lock up.

Contrast this to my PHP based applications (WordPress for example) and I have yet to experience a problem.

THE JAVA FACADE

The Java community loves design patterns (they need them with that overly engineered Frankenstein of a language …) so I’m sure they’ll understand this -> Java is heavy, whenever you start a Java process it like putting on 50 pounds – it slows you down.

The Java facade is the claim that Java is a light nimble thing … the JVM that is. It is not anymore. It once was say back in 1997.

I always wondered why Sun (a billion dollar company) could not get Java Applets to work whereas the relatively tiny company Macromedia, could with the Flash player?

… I’m ranting, so sorry.

CPANEL IS SCARED OF JAVA

Funny, when you activate Tomcat to work with a domain on CPANEL, it gives you a warning about how much juice Java swallows up … and warns against enabling too many Java based websites. It doesn’t say jack about PHP …

JAVA’S FUTURE IS IN LEGACY

It seems a contradiction, but I think that’s where it’s at. Java will become (strictly) a technology of the Enterprise (and legacy integration) while nimble languages like PHP and Ruby will be used to create the new innovative software.

Why?

PHP and Ruby programmers can (and do) code circles around Java developers. You can’t blame the Java developers: the Titanic couldn’t turn on a dime either!

Zing!

read more

3 Categories of Programming Languages

August 2, 2006

I wrote my first script back in 1996 – some really simple JavaScript that validated HTML forms and presented users with ugly ‘alert’ boxes when errors occurred.

I always wondered why on Windows, ‘alert’ boxes looked so ugly?

… they probably looked good on Macs though.

Since then, I’ve written software for business purposes in perhaps 8-9 languages. Over the years, I’ve come across many ways in which people classify languages:

  • Object Oriented vs. Procedural vs. Prototype
  • Scripting vs. Programming
  • Compiled vs. dynamic

… and many more.

Recently a more practical way of classifying languages has come to my attention – classifying languages by problem-domain or in other words, context.

  • System Languages
  • Architectural Languages
  • Application Languages

I like this list, because it really conveys a sense of practical use for a language. I’ve hammered out the details below:

System Languages

… best used to build operating systems, hardware drivers etc. Fast and gives you low level (close to the core) access to the computer. These languages are used when speed is critical.

These languages include:

  • C
  • C++
  • Assembler

Architectural Languages

… best used to build frameworks that support (make easy) application building. Not as fast (at run-time) as system level languages, but they provide a higher level of abstraction that makes writing software quicker and more productive.

These languages include:

  • Java
  • C#

Application Languages

… best used to build the actual business applications like web shopping carts/stores, connecting to databases and creating the screens for users to interact with the database.

These languages include:

  • PHP
  • Ruby
  • Perl
  • Python

These language all allow for extremely fast development.

Programmers are freed from the low-level details that you have to contend with when working with architectural and system level languages.

The fact that they’re all scripting languages (that don’t need to be compiled,) adds to the ease of use and speed of development.

MY POINT

It makes for an interesting way to look at languages … and our choice of what language(s) to use for a given project.

Stefan Mischook

read more

Book Review: Programming Ruby

July 25, 2006

The Pragmatic Programmers’ Guide

This is the famous ‘PickAxe’ book that Ruby nerds talk about. A very well written book that is concise and to the point.

A COUPLE OF COMMENTS:

This is one of those books that reads very well. I had a hard time putting it down even though the coverage was deep – you’ll learn a lot about Ruby and maybe more about programming in general.

I never give the TOC of a book (that you can easily look up,) but I should mention 2 major divisions:

  1. Part 1 is a tutorial that leads you through the core Ruby language.
  2. Part 2 goes into the Ruby environment – the tools that you have available with Ruby. There’s a lot and they work well.

There is much more (advance Ruby concepts, Ruby reference) but I will leave that for you to look into.

FINAL COMMENTS:

What can I say … if you are using Ruby or you want to learn Ruby, you need to get this book.

read more

Book Review: Beyond Java

June 23, 2006

A small book that takes a critical look at Java and other languages (Ruby, PHP, ) at a moment in time.

I say ‘at a moment in time’ because this book will lose relevance very quickly – even more quickly than the typical nerd book.

In a nutshell:

  • You get a brief history lesson on languages and their problems.
  • You get a perspective of the problems that Java developers face.
  • You get perspective on the subject from interviews with several big-wig names in the field.
  • You get an overview of Ruby and Rails.

My complaints:

  • The author likes to introduce his chapters with kayaking stories that are suppose to reflect what he is about to talk about … I would just skip those parts because I am not into kayaking.
  • Question of accuracy: he mentions (page 174) that PHP does not have enough structure. This is a silly statement given that there are SEVERAL PHP frameworks out there that provide the exact same structure as Rails – some even copy Rails.

Conclusion:

I liked the book and it was a worthwhile read. It has a few problems but it does open your eyes to things.

That said, the title of the book should have been: ‘Beyond Java and why I love Ruby’.

read more

Book Review: Ruby For Rails

June 23, 2006

Ruby For Rails connects the dots between Ruby and Rails.

In a nutshell:

This book looks at how Rails uses Ruby, and in so doing, you learn a heck of a lot about Ruby programming.

Ruby For Rails goes into detail about basic Ruby, enough so that I think someone new to Ruby, could learn enough about the language to be able to build web applications. But, the book is not a comprehensive Ruby reference – there are things that are not talked about.

The thing I really liked about the book, is the way the author introduces a concept and then shows you how Ruby or Rails implements that concept in a practical application.

For example:

You are introduced to a Ruby construct called a ‘module’*.

  • You learn what a module is.
  • Why Ruby has modules.
  • How Rails uses modules and why.

I am glad to have this book and think anyone interested in learning Ruby and /or Rails, should get it.

* Ruby modules are programmatic constructs that are like classes (they have methods and constants,) but they are not directly instantiated like a true class.

Instead, modules are created to be inserted into to classes or objects to give the host class or object the extra functionality. Often modules are referred to as ‘mix-ins’ because modules are mixed in to classes.

read more

PHP vs. Ruby

May 9, 2006

With all the buzz about Ruby these days (because of the web application framework ‘Ruby on Rails’) Zend (the people who manage PHP) are feeling the pressure.

Nerd Note: a ‘web application framework’ makes creating databased driven websites much easier because the framework takes care of a lot of the ‘dirty’ work that you would normally have to build yourself.

As far as Zend is concerned, PHP is not getting its’ fair share of attention even though PHP is:

  • Much more available than Ruby – in terms of hosting.
  • PHP is a widely used and a proven language with big sites like Yahoo, Digg and Flickr using it.
  • PHP is easy to use and easy to learn.

As I mentioned above, Ruby’s recent rise has been largely due to the web application framework ‘Ruby on Rails’. So in response to this, Zend has developed their own framework called: Zend Framework.

Along with the Zend Framework, comes a nifty new web site. From the press release:

Future of Web Application Design Is Here and Looking Good

Varien, a web design and development firm, has redesigned the Web site for Zend Technologies’ PHP framework. Varien completed the redesign as part of an effort to reposition PHP as the cleanest and most simple programming language.

Los Angeles, CA—April 20, 2006—Varien has completed redesigning the Zend Technologies’ new PHP Framework Web site in an effort to make the Framework more accessible. The Framework is a powerful new tool for Web developers, providing a simple, standardized way to create powerful web applications using PHP.

The redesign was part of a broader effort to reposition PHP, which included designing a new logo for the Framework. By repositioning PHP Zend hopes to make the Framework and PHP more appealing to current Web developers and less intimidating to those looking to get into Web development.

“Here you have PHP, a programming language that runs Flickr, Wikipedia, Digg, and even Yahoo, and yet Ruby has become synonymous with the new Web,” said Ben Blumenfeld, the Design Director at Varien. “Hopefully this redesign makes Web designers and entrepreneurs take another look at PHP. With Zend’s Framework, PHP is now simpler, faster and more powerful than it has ever been.”

PHP usage has grown tremendously since PHP4 was released in 2000. However, PHP has recently lost some of its mindshare to the heavily touted Ruby on Rails, despite a huge gap in actual usage. (TIOBE programming community index)

The Zend Framework aims to provide a high-quality, commercial-friendly and open-source based solution for programming in PHP. Zend is excited about the Framework’s usability and knows the site redesign will help developers get the most out of the new technology.

“The coolness fact is also important in initially attracting Web developers and is complementary to the technology. The new look of our Web site enables us to build a more appealing perception of the Zend Framework,” said Andi Gutmans, the vice president of technology at Zend.

The Framework can be found at framework.zend.com. The redesign allows users to download the framework from the front page and highlights projects created using PHP in a section on the front page.

WILL RUBY CONTINUE TO EAT AWAY AT PHP’S MIND SHARE?

This is the $64 000 question. But we have to consider one point: Ruby has capability that is widely used in Rails that PHP simply does not have; so can a PHP framework be as effective as Rails?

Nerd-minds want to know!

Stefan Mischook

read more

GoDaddy.com Supports Ruby

May 1, 2006

I have had two major problems with Ruby and Ruby on Rails:

  1. Hard to find Ruby/Rails hosting.
  2. Not too many clients looking for Ruby programmers.

One thing has changed:

A major hosting company (GoDaddy.com,) has stepped up and now supports Ruby on Rails hosting – there goes my first argument against learning Ruby!

Quote from GoDaddy:

Our customers are finding Ruby on Rails to be incredibly valuable in shaping their online presence,” said Bob Parsons, GoDaddy.com CEO and Founder. “We are pleased to be able to offer support for a framework that increases the utility of the sites we host.

With GoDaddy.com jumping in, this will force/influence other hosting companies to adopt Ruby and as such, I believe over the next year, Ruby hosting will become more and more common.

BUT EVERYTHING IS NOT PERFECT WITH RUBY… YET.

Even though it looks as though the hosting thing is resolving itself, we still have the issue of the number of Ruby gigs/jobs floating around … not that many yet.

There is still so much PHP out there (hosting, frameworks, products) that I think for next few years, PHP will continue to dominate with regards to small to medium size projects.

That said, I think that Ruby will be a player for a few reasons … most important, is the strong acceptance of Ruby (and Rails) by the Java community.

Another problem with Ruby and Rails, is the stability of the fastcgi plug-in that works with Apache 2.x.

Basically, there are still some lingering issues with how Ruby ‘talks’ to Apache. This is major, but there are many high profile, high traffic websites that seem to be running fine anyway … ?

CONCLUSION

Despite the aforementioned issues with Ruby and Rails, I am actually involved with putting together a major project with Rails … I know, I know, I’m a bit of a hypocrite!

My reasons?

  1. Ruby and Rails are compelling – there’s some good stuff in there that should make the project much easier to build.
  2. I wanted to explore Ruby and Rails with a real project – I’m just a ‘Curious George’ I suppose …

I plan to come back to you and give you my impressions as to how easy (and useful) it would be for web designers (not programmers) to learn at Ruby vs. say PHP.

Stefan

read more