Comments on navindra's blog: kde.rb: Why You Should Use Ruby

http://wiki.rubyonrails.com/rails/show/ProductionE...

2005-03-17T13:43:00.000-05:00

http://wiki.rubyonrails.com/rails/show/ProductionEnvironments
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/133166

I think Lighttpd or Apache along with FastCGI is the way to go.

somekool, are you saying that webrick is not suita...

2005-03-07T20:01:00.000-05:00

somekool, are you saying that webrick is not suitable for production use? That would be a terrible inconvenience for me. Do you have any more details?

As for the rest, well I'm designing a website, it matters little to the user which technology I choose to use -- I'm free to choose my backend technology so that it actually suits me and my needs. It could be Lisp and they wouldn't even know. :-)

The dot's look or interface is mainly dictated by what URLs it exposes and what HTML it outputs. Also, how fast it works. :-)

Similarly, implementing my work as a generic framework so that all Rails users can benefit is much more work than I can afford right now. Maybe in the future.

Note that by not using Rails I also get to avoid fun like this; the alternative is to be stuck to an obsolete version and/or have to figure out how to fix Rails myself. I'm already familiar with the nightmares involved with that sort of thing. :-)

awesome to ear..... I'm really excited... for th...

2005-03-07T19:44:00.000-05:00

awesome to ear.....

I'm really excited...

for the platform I like webrick, I also use CGI for development, depending on the setup where apache is available or not, but webrick is faster.

for production, I think FastCGI is the only real choice. can't remember of the problem with mod_ruby but FastCGI is perfect.

for the perfomance hit with Rails.

> What I meant was that I don't understand the
> performance implications of Rails itself. That is,
> what performance hit I would experience in
> addition, if I use Rails instead of directly coding
> and optimising my stuff in Ruby.

look at it this way. would you ever want to write a KDE application without the KDE libs ? what kind of perfomance hit can you get by the extra stuff you dont really need ? well, you'll be agree that the work they put in the common libs are shared for the best of all user. the optimization you would place into your system if they are not already in rails, well, rails user would like to ear about them from you.

Thanks for the additional comments. I get comment...

2005-03-06T21:22:00.000-05:00

Thanks for the additional comments. I get comments mailed to me, I don't know if others can subscribe here or if there is any RSS feed available unfortunately.

What I meant was that I don't understand the performance implications of Rails itself. That is, what performance hit I would experience in addition, if I use Rails instead of directly coding and optimising my stuff in Ruby.

I am already using quite a lot of caching techniques including a dynamic cache table and most of my templates are partially pre-generated, as I might have mentioned. But I'll take a look at the libs in Rails for sure.

My stuff in Ruby is already working great although I haven't done any fancy benchmarks. I don't use CGI really, just Webrick.

Webrick provides the backend and all my articles are stored hierarchically on the filesystem. I had thought of using YAML for the article format, but that was more complex than necessary and I used a text format closer to the email header/body format instead.

It really is that simple and it works great so far because the dot articles are inherently organised and related to each other hierarchically. I wrote a bit about this in some of my previous blog entries, so you might find some further details there.

I can't tell you how much simpler it makes admin tasks to have all the data accessible from the filesystem with Unix tools and/or Ruby scripting.

I did already make a demo of dot.rb available internally. I can't currently risk a public demo for security reasons... I need to do a proper audit and look over the code; the server I was running it on was an important production machine -- it wasn't the dot server which is behind a firewall and blocks most of the ports.

Right now (and I've made some progress since I last posted this blog entry), everything to do with viewing and browsing is working except search. This includes Thread Threshold configuration (nesting/indexing) and so on.

Unfortunately I don't currently have time or plans to set up a demo or do more work, but it's all coming!

cannot blogger offer a damn RSS feed for this comm...

2005-03-06T20:54:00.000-05:00

cannot blogger offer a damn RSS feed for this comment thread ?

to complete what Alexander said about Rails Routin...

2005-03-06T20:52:00.000-05:00

to complete what Alexander said about Rails Routing....

when you are saying Alexander "Rails no longer has any idea of what the URL should look like." its actually not entirely true, "no longer" here its not quite right. Rails never ruled how your URL should look like. it was manage through .htaccess and mod_rewrite, which is not compatible with every web server and not as nice as ruby programming, thats why Routing has been implemented, not to fill a blank, but to improove a current existing functionnality.

just my 2 cents

...

Navindra, to answer your question about performance,... well, you simply want to use FastCGI as your server settings of choice. additionally Rails offer really advance and flexible caching. you gotta look into that. even if you dont want a use rails, you can use part of it, require a sublib or just use it as an example into your system. You'll love Rails caching and its perfectly appropriate for a site like TheDot

....

now, I have two question for you.
1- you dont use Relation DB, can I ask you what you are using ? you mention something like on the FileSystem... you made me curious...

2- can we see the current state of TheDot(ruby) ?

thanks !

Thanks for the info. It's interesting and informa...

2005-02-28T13:27:00.000-05:00

Thanks for the info. It's interesting and informative. Rails is changing every day and getting better and better. I just don't want to track it though. It's a work in progress.

As someone said, I could pick a version and stick to that, but this is exactly the current situation with the Dot and it really isn't pretty after a few years. :-)

Ruby upgrades I can handle.

Also, why would I want Rails/Routes to connect this and that action? I don't need a framework for that. Nice MVC and all, but I simply don't need that level of abstraction when a few lines of code already takes care of it.

I know MVC (Model View Controller) is a design pattern. So when you tell me Rails provides MVC, that's just a buzzword to me. I don't need Rails for MVC. Call me unfair...

That being said, I was already considering Rails for the non-visible non-public part of the project. I will take a closer look and see if it can be made to fit the needs of the rest of the project but I have my doubts it's worth the trouble.

Speed and performance are also a major concern. I'm not sure where Rails stands on that or what kind of new performance issues it introduces.

Also, I need the new site to be backwards compatib...

2005-02-28T11:40:00.000-05:00

Also, I need the new site to be backwards compatible with the old site. Rails has its own idea of what a URL should look like.Actually, starting with 0.10, Rails no longer has any idea of what the URL should look like. It no longer relies on Apache's mod_rewrite, and instead provides its own miniframework called Routes. For example:

map.connect ':id',
:controller => thread, :action => "view"
map.connect ':id/:action',
:controller => thread

This will map /1234 to the "thread" controller and the "view" action, and /1234/reply will be mapped to the "reply" action in the same controller. Routes even supports regular expressions.

While there's something to be said about learning the ropes by doing everything yourself, there's a lot of overlap between your project and what Rails aims to solve.

A nice feature of Rails is that it doesn't force every feature down your throat. You can easily ditch the database mapper (ActiveRecord) and use the file system to store your data. As for MVC, it's a design pattern, not a specific implementation; even in your homegrown solution you will want to apply a few strokes of MVC.

Yes, Rails provide a lot of capabilities I don't n...

2005-02-25T10:48:00.000-05:00

Yes, Rails provide a lot of capabilities I don't need (relational DB, MVC) and I'm not interested in. Also, I need the new site to be backwards compatible with the old site. Rails has its own idea of what a URL should look like. So it's simply not going to work out of the box here. It's great for other stuff.

I've had several MySQL corruptions over the years. We use this thing for heavy stuff here. Wiki uses it and is quite slow and process intensive without caching.

Have fun back at ya!

Rails is definitely worth looking at.... its grea...

2005-02-25T03:58:00.000-05:00

Rails is definitely worth looking at....

its great.

for upgrade, you gotta be careful for sure, but you dont really have to upgrade never ever. the thing is once your app it production, you lock your app to use a specific version of rails, and then, even if you upgrade rails on your server for future app, your apps on prod would not break,

I,m also talk already with David to make it care a little bit more about upgrade.... its a lot better now and rails gonna it 1.0 soon.

anyway, one of the biggest magic of rails, is activerecord, and if you dont use relational database, it would not be that usefull. the other one is the MVC but... anyway... whatever you are confortable with is just as good I am sure.

but dont think rails is a problem, its the solution, just like ruby ;) hehe.

as for mySQL, I never had any datacorruption in the last 10 years. and dont expect it to happen ever.

and these days, I am testing SQLite, working my Database model with kexi and my web frontend in rails....

have fun

No Rails. I'm just going to end up fighting it to...

2005-02-25T02:03:00.000-05:00

No Rails. I'm just going to end up fighting it to make it work the way I need it to. Just not interested that.

Also, I've already read reports about people having upgrade headaches from Rails version to version and that's exactly the kind of situation I want to avoid. I already have that with Squishdot/Zope/Python and I'm not really interested in tracking another framework.

As for MySQL, no way. Not interested in dealing with DB corruption or having to figure out why the performance is so bad. There are search implementations for Ruby anyway.

Thanks for the comments. :)

Of course, I don't know anything about how the dot...

2005-02-24T14:15:00.000-05:00

Of course, I don't know anything about how the dot works internally, but in case you happen to be using MySQL, it has a full-text search function that could be useful.

Oops.. I meant "web development can be actually _f...

2005-02-24T13:26:00.000-05:00

Oops.. I meant "web development can be actually _fun_"..

I admit, Ruby is awesome. Web development can be -...

2005-02-24T13:25:00.000-05:00

I admit, Ruby is awesome. Web development can be - I experienced this the first time with ruby.

But the real beaty only shows with Rails. Have you tried it? You should.

http://www.rubyonrails.org/

Well written. Congrats Navindra.

2005-02-24T08:08:00.000-05:00

Well written. Congrats Navindra.