Hi Suraj,
You think MySQL 5.0 server version is not good for multi-user
applications?
It is fine. However, my software engr. professor said PostgreSQL is
better because MySQL doesn’t handle concurrency issues very well.
Great to know. I’ll check that out before I go to production.
… Thus, I would just use “localhost” because it is more human
readable.
Cool!
Right now, I have MySQL 5.0 running on my development machine, and it
stores the data the data sub-directory of its installation directory.
I imagine it’s easy to configure it to store data wherever I wish to
target it.
Yes, that is fine.
Cool.
Yes, that is correct.
Excellent!
However, this brings up another issue. Since each user’s local copy of
your Rails app has write access to your central DB, you could lose all
your data on the central DB if a user runs
rake migrate VERSION=0
It’s kinda silly, but possible.
IMHO, not silly at all. It says to me that when I port the application
to client machines, I should arrange that Rake can only be run under an
Administrator account. Also, I should make sure that any dangerous
commands to the DBMS can only be run under the root ID. That should at
least plug up some of the security holes.
Thank you very much for all your observations and comments. I feel a
lot more confident that my development effort will be well received.
Best wishes,
Richard
On Dec 17, 11:17 pm, “Richard”
[email protected] wrote:
The app structure I outlined, Firefox+Ruby+Rails+WEBrick+MySQL, all
runs on the client’s machine (except for the database server). The
user machine(s) need not be connected to the Internet, though it/they
needs a LAN connection to a database server. So everything except the
data-store is “client-side”.
OK, I’ve been skimming this thread the last few days, and I’m surprised
no one else has asked the obvious question here (if someone did and I
missed it, I apologize)…
/Why/ in the world would you write a web app with RoR to be run locally
on several users’ machines that connects to one central database? I
hate to be blunt, but that’s just kinda dumb.
Considering you already need a central server to run the database on,
just run the web app from a central server as well. Then all these
questions about upgrading the app on the users’ machines, who should
run rake db:migrate, etc. kinda take care of themselves.
–
Regards,
John W.
Hi John,
/Why/ in the world would you write a web app with RoR to be run locally
on several users’ machines that connects to one central database? I
hate to be blunt, but that’s just kinda dumb.
Considering you already need a central server to run the database on,
just run the web app from a central server as well. Then all these
questions about upgrading the app on the users’ machines, who should
run rake db:migrate, etc. kinda take care of themselves.
[As I slap my forehead in astonishment, I say:] because I never
thought of that. It’s my first Rails application and this thread has
helped me see my way through a bunch of development issues. You just
added one more (much needed) clarification.
Thank you very much for weighing in with that observation.
Yours truly,
Richard
Hi David,
- broadcast a message to all users that the should update their version
of app by getting the latest and greatest version?
Mind the “should”. … you run the risk of someone with a version that’s not up-to-date
thrashing the data.
Good point. I’ll be able to force all users to shut down their
connection to DB. How about I put a ver. # in the DB (inaccessible to
users directly) and have the login screen check that the user’s version
matches the version requirement in the DB; mismatch will inhibit login
if anything’s amiss, just like a bad userid or password?
I think this process works this way: The
controller tells the model to cook up some data, suitably filtered and
ordered, and keep it available for access by the appropriate view. [snip]
Is my description of the process OK? Does “push” refer to the
“web-server to browser” step?
No. With a webapp, the process is always initiated by the web browser,
and it’s a pull.
Agreed. I omitted the steps where the user:
- starts a local copy or WEBrick
- directs his/her browser to localhost:3000, which defaults to the
logon screen
- provides his/her credentials (and the user’s app’s version is check
against the DB)
The produced HTML is the current state of the view for
a user, and if the user doesn’t poll for changes, it will go stale if a
relevant part of the model changes.
There will be no change to the model while any user is connected to the
DB, at least not on my watch.
The “hack” around this is …
So I’m saving the workaround suggestions, but not thinking about them
for a while.
Thanks for all your ideas. Your insights, along with Suraj’s, have
boosted my confidence that I’ll get my first Rails production system
running smoothly.
Best wishes,
Richard
Richard wrote:
Suraj wrote:
However, this brings up another issue. Since each user’s local copy of
your Rails app has write access to your central DB, you could lose all
your data on the central DB if a user runs
rake migrate VERSION=0
It’s kinda silly, but possible.
IMHO, not silly at all. It says to me that when I port the application
to client machines, I should arrange that Rake can only be run under an
Administrator account.
Maybe that is too restrictive – rake is used for other Ruby stuff as
well. An alternative approach is to override the migrate task in the
main Rakefile:
task :migrate do
exit # silently!
end
This way, you can still use rake for other projects.
Also, I should make sure that any dangerous
commands to the DBMS can only be run under the root ID. That should at
least plug up some of the security holes.
Precisely.
I don’t know much details about DB permissions, but I’m sure there is a
different set of permissions for DROP and CREATE tables. Those should
not be given to users. Instead, users should only have INSERT, UPDATE,
and DELETE permissions.
Other than that, making regular backups of your DB should cover any
remaining troubles – like a user deleting all rows/records from a DB
table or inserting lots of spam into a DB table.
Richard wrote:
Hi John,
/Why/ in the world would you write a web app with RoR to be run locally
on several users’ machines that connects to one central database? I
hate to be blunt, but that’s just kinda dumb.
Considering you already need a central server to run the database on,
just run the web app from a central server as well. Then all these
questions about upgrading the app on the users’ machines, who should
run rake db:migrate, etc. kinda take care of themselves.
[As I slap my forehead in astonishment, I say:] because I never
thought of that.
Shocking indeed! 
I too was only thinking within the scenario Richard had initially
posted. It never occurred to me to step back and look at the big
picture.
Good observation John. You are 100% correct.
John W. wrote:
/Why/ in the world would you write a web app with RoR to be run locally
on several users’ machines that connects to one central database? I
hate to be blunt, but that’s just kinda dumb.
Considering you already need a central server to run the database on,
just run the web app from a central server as well. Then all these
questions about upgrading the app on the users’ machines, who should
run rake db:migrate, etc. kinda take care of themselves.
Load distribution. The only thing you need to ever make scalable is the
database and the access to it, and can run it on a relatively
underpowered machine - and if you play it right, with less bandwidth
requirements too (you only ever transfer resources like images etc.
during a client update, which can be yet optimised by using something
like Jigsaw, or SVN as mentioned for text resources). It’s not a common
architecture, but not one without any sense to it whatsoever.
David V.
On Dec 20, 10:30 pm, David V. [email protected] wrote:
Load distribution. The only thing you need to ever make scalable is the
database and the access to it, and can run it on a relatively
underpowered machine - and if you play it right, with less bandwidth
requirements too (you only ever transfer resources like images etc.
during a client update, which can be yet optimised by using something
like Jigsaw, or SVN as mentioned for text resources). It’s not a common
architecture, but not one without any sense to it whatsoever.
We may have to agree to disagree here, but I’m going to say that there
is absolutely no benefit to this architecture, that can outweigh the
detriments of both the increased maintenance and the decreased
security.
If you really need to distribute load, a better route to take would be
a client/server architecture where you have an intelligent app server
– not just a database connection – that exposes services (perhaps
REST-style web services). You can do a lot of the heavy lifting on the
clients, but you can still manage security and client updates
intelligently from the server.
While Ruby/Rails may be a great choice for the server, I would probably
not use Ruby for the client in most situations. Not that I don’t love
Ruby, of course – I just wouldn’t want to have to deal with keeping
both Ruby, and library dependencies, and the client application up to
date on every machine that was using the program. Most likely, I would
go with something like Flex[1] for the client, since it’s relatively
painless to distribute upgrades that way. I’m currently using Flex for
the client end of a large workflow automation tool that we’re building
at work, and I have to say that I would never want to go back to using
HTML interfaces to create web-based /applications/ again.
[1] http://www.adobe.com/products/flex/ (note: Flex Builder costs
money, but all you really /need/ is the SDK which is free as in beer)
On 12/17/06, Michael T. Richter [email protected] wrote:
On Sun, 2006-17-12 at 10:09 +0900, Suraj K. wrote:
Tk is wonderful! It’s really simple to manipulate widgets and graphics
in the way you’d expect. IMHO, Tk is the Ruby of GUI toolkits.
I’m with David here. Tk isn’t the Ruby of GUI toolkits. But I diverge sharply from him after that. He says it’s the PHP of GUI toolkits. I say it’s the GWBASIC of them.
Tk-based GUIs are typically so fscking useless that I’d rather use the CLI and ed over an
app coded in Tk.
Apart from the TkCanvas, which is utterly brilliant. How many other
toolkits give you a vector-oriented canvas, in which you can draw
graphical objects that respond to click events, for free?
martin
Hi Suraj,
end
This way, you can still use rake for other projects.
Understood!
Thanks again for your insightful comments. I rated this post to be
“excellent” as a reflection of all your contributions to this thread.
I’m going to sign off this thread. I’ve got to spend some time
actually doing something I’m making a copy of all the essential
conclusions presented here, which I’ll review as my development efforts
proceed.
Best wishes,
Richard
Hi David,
during a client update, which can be yet optimised by using something
like Jigsaw, or SVN as mentioned for text resources). It’s not a common
architecture, but not one without any sense to it whatsoever.
Good additional ideas.
As I said to Suraj, thanks again for your insightful comments. I
rated this post to be “excellent” as a reflection of all your
contributions to this thread.
I’m going to sign off this thread. I’ve got to spend some time
actually doing something I’m making a copy of all the essential
conclusions presented here, which I’ll review as my development efforts
proceed.
Best wishes,
Richard
John W. wrote:
Most likely, I would
go with something like Flex[1] for the client, since it’s relatively
painless to distribute upgrades that way.
Mind you, this is what I said in my first reply to Richard in the first
place and then went along with the idea. I didn’t say the architecture
is an ideal one or one I would pick, just not without redeeming value of
-some sort-.
David V.
Martin DeMello wrote:
Apart from the TkCanvas, which is utterly brilliant. How many other
toolkits give you a vector-oriented canvas, in which you can draw
graphical objects that respond to click events, for free?
I agree. TkCanvas doesn’t do rotation or scaling as nicely as opengl,
but it’s very nice for schematic diagrams, user interaction, and simple
animation. It has saved me a lot of work lately.
Hi John,
intelligently from the server.
HTML interfaces to create web-based /applications/ again.
[1] http://www.adobe.com/products/flex/ (note: Flex Builder costs
money, but all you really /need/ is the SDK which is free as in beer)
Good additional ideas!
As I said to Suraj and David, thanks again for your insightful
comments. I rated this post to be “excellent” as a reflection of all
your contributions to this thread.
I’m going to sign off this thread. I’ve got to spend some time
actually doing something 
I’m making a copy of all the essential
conclusions presented here, which I’ll review as my development efforts
proceed.
Best wishes,
Richard
Hey David and John,
It was all my fault. My goal for my first Ruby/Rails project is really
an Accounts Receivable system for a client. The client has a small
business system written in 1980. It is based on 1980 versions of
FilePro and SCO . They asked me to make some minor change to it. The
code was so ugly (in my eyes; I had no interest in learning a dead
version of a 4GL language) that I offered to look into using Ruby and
Rails to build a piece of it that would import/export relevant data
from the SCO box.
So while trying to come up to speed on RoR I was envisioning the
simplest architecture I could get away with. In starting to write the
app, I had the thing starting to take shape on my machine. When I
posted my question about the architecture, I inadvertently glossed
over the fact that I ultimately had to have a data server.
So I apologize for having such muddled thinking. But despite my
sloppiness, you guys managed to see through my haze and pointed me in
the right direction. I’m on a roll now!
Best wishes,
Richard
Martin DeMello wrote:
Tk-based GUIs are typically so fscking useless that I’d rather use
the CLI and ed over an
app coded in Tk.
Apart from the TkCanvas, which is utterly brilliant. How many other
toolkits give you a vector-oriented canvas, in which you can draw
graphical objects that respond to click events, for free?
WPF?
I’ve been increasingly interested by what’s going on in Ruby.NET, for
exactly that reason.
On Dec 21, 2:46 pm, David V. [email protected] wrote:
John W. wrote:
Most likely, I would
go with something like Flex[1] for the client, since it’s relatively
painless to distribute upgrades that way.Mind you, this is what I said in my first reply to Richard in the first
place and then went along with the idea. I didn’t say the architecture
is an ideal one or one I would pick, just not without redeeming value of
-some sort-.
OK, I must have just missed that post. This thread has about two or
three topics in it, and I was only half following it when I decided to
speak up on that architecture. I went back and skimmed through it to
make sure I wasn’t saying something that was already said, but I didn’t
re-read every single post closely. Apologies if I offended.
Alex Y. schrieb:
I’ve been increasingly interested by what’s going on in Ruby.NET, for
exactly that reason.
I’m looking bout every few weeks on the site of the compiler, but there
doesn’t seem to happen anything more.
I’ve postet on their google group to ask for it, they told me, that they
are working on a Ruby-Implementation-Testing suite, to compare
“Vanilla”-Ruby, JRuby, and Ruby.NET on the way how they work or
something else… The last thing I heard were some discussions about
implementing a new Framework for this issue (last post there Sep. 2006)
Badly, there’s nothing going on - so i think its dead already.
Project Site: http://plas.fit.qut.edu.au/Ruby.NET/
Google Group (ruby.net): http://groups.google.com/group/RubyDOTNET
Google Group (RubyTest): http://groups.google.com/group/RubyTests