Comments on: I Thought Rails Was Meant To Be Productive… http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/ Living in a state of accord. Tue, 07 Feb 2012 01:07:58 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Ola Binihttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-32360 Ola Bini Sat, 16 Sep 2006 16:40:57 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-32360 Hi, Just wanted to give you an heads-up that you now can use Apache Derby (or HSQLDB) in Rails, if you run under JRuby. Hi,

Just wanted to give you an heads-up that you now can use Apache Derby (or HSQLDB) in Rails, if you run under JRuby.

]]> By: DHHhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-31258 DHH Tue, 05 Sep 2006 03:58:44 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-31258 It obviously depends on how you bundle it. Before I even released Rails, I released a no-step-three wiki called Instiki. You can still download it. I think its available both as an .exe and as an .app file. It shipped everything in the box. 0 dependencies. Ruby didn't even have to be installed (it came with the bundle). In any case, you must of course use what you feel comfortable with. It obviously depends on how you bundle it. Before I even released Rails, I released a no-step-three wiki called Instiki. You can still download it. I think its available both as an .exe and as an .app file. It shipped everything in the box. 0 dependencies. Ruby didn’t even have to be installed (it came with the bundle).

In any case, you must of course use what you feel comfortable with.

]]> By: Adrian Suttonhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-31061 Adrian Sutton Sun, 03 Sep 2006 20:40:56 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-31061 It's not the configuration side that is the centre of my complaint - having to configure a MySQL username and password is unavoidable when using MySQL and Rails does make that easy. The centre of the complaint is that getting the integration to work with MySQL in the first place is too difficult. On OS X I had to go searching for what parameters to pass in to specify the MySQL header files location and then had to tell rails where the ruby header files were (something I'd not seen before). On Windows the install was fine, but rake migrate gave an error about missing the "each" method. After uninstalling everything and attempting a different path I got an error about a missing DLL, and so on. Each of these problems is almost certainly something particularly unusual about my setup and on OS X I've gotten it working now. My problem is that I want to be able to send the application out to end clients so they can run it on their systems. I really need it to be as simple as double-clicking a file to get it started and right now unfortunately Rails doesn't seem up to that. In terms of which system I can do that with - Java. There are actually a lot of apps being distributed this way very successfully today. With Apache Derby there is no problem with database logins or connectivity issues and bundling in a Tomcat server is simple to do. Plus a huge number of sysadmins already have experience deploying Java applications, whereas few have experience with rails deployment so far. That's not to say that Rails doesn't show a lot of promise, doesn't have huge benefits when you are running it from your own servers or that Rails won't be double-click deployable in the future, it's just not quite there yet. It’s not the configuration side that is the centre of my complaint – having to configure a MySQL username and password is unavoidable when using MySQL and Rails does make that easy. The centre of the complaint is that getting the integration to work with MySQL in the first place is too difficult. On OS X I had to go searching for what parameters to pass in to specify the MySQL header files location and then had to tell rails where the ruby header files were (something I’d not seen before). On Windows the install was fine, but rake migrate gave an error about missing the “each” method. After uninstalling everything and attempting a different path I got an error about a missing DLL, and so on.

Each of these problems is almost certainly something particularly unusual about my setup and on OS X I’ve gotten it working now. My problem is that I want to be able to send the application out to end clients so they can run it on their systems. I really need it to be as simple as double-clicking a file to get it started and right now unfortunately Rails doesn’t seem up to that.

In terms of which system I can do that with – Java. There are actually a lot of apps being distributed this way very successfully today. With Apache Derby there is no problem with database logins or connectivity issues and bundling in a Tomcat server is simple to do. Plus a huge number of sysadmins already have experience deploying Java applications, whereas few have experience with rails deployment so far.

That’s not to say that Rails doesn’t show a lot of promise, doesn’t have huge benefits when you are running it from your own servers or that Rails won’t be double-click deployable in the future, it’s just not quite there yet.

]]> By: DHHhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-31057 DHH Sun, 03 Sep 2006 18:43:35 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-31057 BTW, to install the C-bindings for MySQL, you do "gem install mysql". To install the C-bindings for SQLite, you do "gem install sqlite-ruby". I'd file that under "easier than most". BTW, to install the C-bindings for MySQL, you do “gem install mysql”. To install the C-bindings for SQLite, you do “gem install sqlite-ruby”. I’d file that under “easier than most”.

]]> By: DHHhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-31056 DHH Sun, 03 Sep 2006 18:40:59 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-31056 Adrian, which environment do you work in where database connectors doesn't need to be installed and they don't need to be configured? In any case, please do get specific and we can help you solve the problem. What's the error message you're seeing and what's the setup you're running on? Rails automatically configures for SQLite, and any other database we support, by using the --db option when you create a new application. We can't, however, guess your user name and password. Although we actually try (by default its root/nothing for MySQL, which is what its out of the box for that database). Adrian, which environment do you work in where database connectors doesn’t need to be installed and they don’t need to be configured? In any case, please do get specific and we can help you solve the problem. What’s the error message you’re seeing and what’s the setup you’re running on?

Rails automatically configures for SQLite, and any other database we support, by using the –db option when you create a new application. We can’t, however, guess your user name and password. Although we actually try (by default its root/nothing for MySQL, which is what its out of the box for that database).

]]> By: Adrian Suttonhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-30828 Adrian Sutton Sat, 02 Sep 2006 23:14:44 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-30828 DHH, Then why doesn't it work consistently, reliably, everywhere, first time? Maybe it's something simple but the error messages are completely useless. Either way I've wasted far too much time on this - if I can't get it working I can't expect anyone else to so for now Rails isn't a good solution for this project. I need something that I can give to clients and know that they'll be able to get it up and running on their system in a couple of clicks. Rails I'm sure will get to the point where it can do that, but it's not there yet. Great to hear that rails automatically configures SQLite though. It still has the downside of needing to get the integration with SQLite working - if that's seemless then great, but I don't hold very high hopes considering my past experiences with anything and SQLite and Rails and MySQL. DHH,
Then why doesn’t it work consistently, reliably, everywhere, first time? Maybe it’s something simple but the error messages are completely useless. Either way I’ve wasted far too much time on this – if I can’t get it working I can’t expect anyone else to so for now Rails isn’t a good solution for this project. I need something that I can give to clients and know that they’ll be able to get it up and running on their system in a couple of clicks. Rails I’m sure will get to the point where it can do that, but it’s not there yet.

Great to hear that rails automatically configures SQLite though. It still has the downside of needing to get the integration with SQLite working – if that’s seemless then great, but I don’t hold very high hopes considering my past experiences with anything and SQLite and Rails and MySQL.

]]> By: DHHhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-30799 DHH Sat, 02 Sep 2006 22:17:45 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-30799 Adrian, Rails actually ships with a Ruby-based MySQL adapter. You don't need the C-based one, except for speed. Also, you don't have to configure three databases. You can start out just configuring the development one. Then once you need the other environments, you can configure those. With SQLite, the creation of the three databases is all handled automatically, though. Just create a new rails app with "rails --db sqlite2 myapp" and its even configured for you as well. Adrian, Rails actually ships with a Ruby-based MySQL adapter. You don’t need the C-based one, except for speed. Also, you don’t have to configure three databases. You can start out just configuring the development one. Then once you need the other environments, you can configure those.

With SQLite, the creation of the three databases is all handled automatically, though. Just create a new rails app with “rails –db sqlite2 myapp” and its even configured for you as well.

]]> By: Adrian Suttonhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-30797 Adrian Sutton Sat, 02 Sep 2006 22:12:34 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-30797 Matt, SQLite has the same problems as MySQL - you have to get past all the Ruby to C interface stuff. Setting up the MySQL server itself is trivial, getting Rails to talk to it is exceptionally frustrating - just look at all the blog posts and wiki pages asking for help with it. A pure Ruby database would avoid this because it wouldn't have a native component that has to be tailored for each system. Having a default embedded database also has the advantage of eliminating the need for configuration before you start developing. Also, the distinction between databases is good, the fact that I have to configure three different databases is bad. With an embedded database Rails would just create the three separate databases for me with no configuration required. You'd still have the ability to configure it to use MySQL if you knew your app required that, but by default it would just work. Matt,
SQLite has the same problems as MySQL – you have to get past all the Ruby to C interface stuff. Setting up the MySQL server itself is trivial, getting Rails to talk to it is exceptionally frustrating – just look at all the blog posts and wiki pages asking for help with it. A pure Ruby database would avoid this because it wouldn’t have a native component that has to be tailored for each system. Having a default embedded database also has the advantage of eliminating the need for configuration before you start developing.

Also, the distinction between databases is good, the fact that I have to configure three different databases is bad. With an embedded database Rails would just create the three separate databases for me with no configuration required. You’d still have the ability to configure it to use MySQL if you knew your app required that, but by default it would just work.

]]> By: Matt Palmerhttp://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/comment-page-1/#comment-30691 Matt Palmer Sat, 02 Sep 2006 05:53:09 +0000 http://www.symphonious.net/2006/09/02/i-thought-rails-was-meant-to-be-productive/#comment-30691 The Rails guys probably didn't want to write a pure-Ruby embedded database because there's a reasonable altrenative already -- SQLite (http://www.sqlite.org/). Bindings available as gems or in your (or at least my) favourite distro's package repositories. Trivial to setup. As long as you stick to migrations and ActiveRecord for all your database interfacing, it's perfectly fine to use -- it's "dialect" of SQL is a bit more limited than MySQL's, so if you're executing queries directly against the DB it's unlikely to be too healthy. As for having to setup separate dev/test/prod databases, I think the separation of concerns in Rails' environments concept is an amazingly powerful one, and if Rails' only lasting legacy was the universal adoption of such a concept, I'd almost be satisfied. If you really want minimal-time config, though, you can just define one environment and then tell the others to "inherit" from that, like so: development: adapter: sqlite3 dbfile: db/devel test: development production: development The Rails guys probably didn’t want to write a pure-Ruby embedded database because there’s a reasonable altrenative already — SQLite (http://www.sqlite.org/). Bindings available as gems or in your (or at least my) favourite distro’s package repositories. Trivial to setup. As long as you stick to migrations and ActiveRecord for all your database interfacing, it’s perfectly fine to use — it’s “dialect” of SQL is a bit more limited than MySQL’s, so if you’re executing queries directly against the DB it’s unlikely to be too healthy.

As for having to setup separate dev/test/prod databases, I think the separation of concerns in Rails’ environments concept is an amazingly powerful one, and if Rails’ only lasting legacy was the universal adoption of such a concept, I’d almost be satisfied. If you really want minimal-time config, though, you can just define one environment and then tell the others to “inherit” from that, like so:

development:
adapter: sqlite3
dbfile: db/devel

test: development

production: development

]]>