David Berube

author
+ Follow
since Jun 18, 2007
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by David Berube

IMHO, it's easier to deploy a Rails app than a CakePHP app. Recent builds may have improved, but last time I had to deploy a CakePHP app significant and nonobvious mod_rewrite'age had to happen before it would work. (It worked fine on my test server, of course.)

Going along with what Nick said, for any non trivial application, you're going to eventually have to deal with automating deployments, db migration, scalability to multiple app servers, etc, and Capistrano is *great* at that.

Take it easy,

David Berube
[ September 04, 2008: Message edited by: David Berube ]
15 years ago
Ulf Dittmer: Ruby is a great way to make programming problems easier by writing code that writes code - metaprogramming. If you'd prefer to work with a unchanging environment, Ruby loses much of it's flair. (Rails gives you some free metaprogramming, of course.)

Lisp does this as well, of course, but Ruby has much better community support, a bigger base of active developers, and more up-to-date libraries.

Jasper Young: Static vs dynamic typing is a hot issue for a lot of people, and the question of which is superior is not going to be answered here and now. For what it's worth, Many people use Ruby for mission critical applications, and many people use Ruby for applications that have to scale. (Twitter, for example, has scaled significantly.)

Take it easy,

David Berube
15 years ago
Like Nick said, it completely depends on your application, but Restful Auth and Exception Notifier are a good start.

Take it easy,

David Berube
15 years ago
GVim with Ruby support and Rails.vim is awesome. (There's a reason why Timothy Pope, author of Rails.vim, is in the acknowledgments for my book.)

Take it easy,

David Berube
15 years ago
Gems are Ruby libraries; they are the subject of my earlier book,Practical Ruby Gems. Rails itself is packaged as a gem, and so are a variety of other Ruby software packages: fasterCSV is an optimized CSV library packaged as a gem, hpricot is an HTML parser library packaged as a gem, and so forth.

Plugins are specifically designed to extend Rails; they are placed inside a Rails application and are automatically loaded by Rails. Unlike Gems, they are unique to an application: if five of your apps use the Attachment Fu plugin, all five will contain a separate copy.

However, the two types are not completely inseparable: you can, for example, copy a particular gem to your Rails plugin directory; this causes that particular version of the gem to be "frozen," so that your application will always use that version instead of whatever version is most recent.

Additionally, Rails 2.1+ supports packaging plugins as gems; as a result, the essential difference between gems and plugins becomes whether your Rails application is going to load the code from your system or from it's own local copy.

Take it easy,

David Berube
15 years ago
Typically, not much. The plugin architecture itself has very little overhead.

On the other hand, the plugin implementation may be slow. In most cases, though, plugins are a repackaged version of the same kind of code you'd write for your own application.

Take it easy,

David Berube
15 years ago
PHP scripts are easier to deploy then Rails apps, at least at the moment; for small stuff - "contact us" forms - I wouldn't bother creating a Rails application. For larger apps, in my opinion, you'll have quicker development and easier maintainability by switching to Ruby on Rails.

That being said, realize that Rails is a *very* opinionated environment - Rails wants you to use artificial primary keys, validate in your models (vs database), singular models and plural tables, etc. Working within Rails constraints can be a joy; bumping up against them all the time is painful. (This is deliberate - a more flexible system would require more typing and more configuration. The assumptions Rails make speeds up your development significantly.)

Of course, note that Ruby itself isn't opinionated; there are a number of promising web frameworks which differ from Rails and different approaches. (Mack, merb, etc.)

Take it easy,

David Berube
15 years ago
I should note that a few of the examples use 2.0 style filenames, but, IIRC, almost no 2.0 style features - you should be able to convert by changing .html.erb to .rhtml.

Take it easy,
David Berube
16 years ago
There are, however, more advanced scaffolding plugins, such as ActiveScaffold, which is useful for administrative interfaces and can be created with almost no work.

Take it easy,
David Berube
16 years ago
At least half of the examples don't even require Rails, although you can certainly use the techniques with Rails. Of the remaining examples, some are 2.0 and some are the older style. Note that almost none of the techniques are Rails 2.0 specific, save for one particularly RESTful example.

Take it easy,
David Berube
16 years ago
Ruby is definitely a more flexible language than Java. This may or may not be desirable depending on your preference. Note that Ruby is not especially good at protecting you from stupidity, so if you're saddled with incompetent developers on your team, Java will protect you from them to a greater degree. (Ultimately, incompetent programmers will be a problem irrespective of programming language, of course.)

For example, you can also reopen a previously defined class and add new code to it. You can even use a method_missing definition to provide special handling for undefined methods: this lets you, for example, create "patterns" of methods, rather than having to create all of your methods by hand. Rails does this for finder methods, so your DB models can have calls like find_by_first_name_and_last_name without any code explicitly defining them.

Take it easy,
David Berube
16 years ago
I'd also strongly suggest that a purely vertical definition is dangerous - if you think of yourself as a ".net programmer", "Java programmer," or "Ruby programmer", you're limiting yourself. It's much better to think of yourself as someone who creates software or solves problems - or, even better, as an artist or craftsman. The tools are just a means to an end, and you should not let them limit you.

In fact, the less likely a particular connection is, the more likely it is to give you an edge over the competition. If you use an uncommon combination of tools, you can likely accomplish something other people can't.

Take it easy,
David Berube
16 years ago
Alaa is right - my book talks specifically about using Ruby for business reporting. It covers extracting data, analyzing it, and then displaying it. For example, it shows how to use ActiveRecord and various graph libraries to represent data in a ton of different ways: in a PDF, as a desktop application, as part of a web application, and more.

Take it easy,
David Berube
16 years ago
Actually, Practical Reporting with Ruby and Rails is an intermediate level book: it assumes some knowledge of both Ruby and Ruby on Rails. The parts of Rails particularly relevant to reporting - aggregate functions, for example - are covered, but the basics of setting up Ruby and Rails - or, for that matter, MySQL - is not.

However, I can recommend Beginning Ruby - another Apress title - for anyone wishing to learn Ruby on Rails.

Take it easy,

David Berube
16 years ago
Hi Greg,

Good questions. I think Ruby is a bit slicker than either; not everyone agrees with me, of course. In particular, I feel that Ruby has a very powerful metaprogramming and reflection techniques; in fact, that's what attracted me to Ruby in the first place. (I wrote an article on Dynamic Databases with Ruby back in '04; it appeared in Dr Dobb's Journal, and you can read it here: URL=http://www.ddj.com/dept/database/184405925]http://www.ddj.com/dept/database/184405925[/url])

As for the second question, to quote Tim Hunter's slashdot
"As far as deciding which gems, ...I tried to look at things that had
practical applications - as well as things where I could give it an
interesting angle. Above all, I tried to cover different material in a
different way - I wanted to get people to think "wow, that's great." Of
course, not everything was completely off the beaten path - Rails, for
example, was covered, and that' easily the most popular gem, and RMagick
isn't exactly unpopular either, but I tried to show gems which could
make very difficult, less covered problems - like programatically using
zip files as a container, writing PDFs, or automating SSH tasks - into
easy problems...The biggest thing for me is that I wanted to make people
say 'You can do that with Ruby?'"

Take it easy,

Dave
16 years ago