does Ruby generate WINDOWS and dialog boxes?
Ken Laninga
discussed but I see no mention of the actual windows and input/output
boxes/windows which it may or may not produce.
Does it make windows?
--
*************
http://www.sticksite.com/ Ken Laninga
David Vallner
> I just heard about Ruby and it looks fascinating. I see lots of code being
> discussed but I see no mention of the actual windows and input/output
> boxes/windows which it may or may not produce.
>
> Does it make windows?
>
Oi, this might get bloody.
Firstly, not all programming involves graphical user interfaces (windows
/ dialogs; I'll just use GUI onwards).
But, here goes. For Ruby (and most anything that isn't Visual Basic),
GUI is a thing that is handled in a library. (Mostly because Ruby aims
to be a crossplatform language, and trying to handle GUIs crossplatform
is finicky and would probably end in tragedy if tried.)
As far as I'm aware, Ruby doesn't include a GUI library in the standard
library.
However, such libraries are available. I'll audaciously presume your
background to be Windows. In this case, you can either do raw Win32 API
callouts (even if it might be slightly maddening.), which is part of the
standard Windows distribution.
Also, if you're using the One Click Installer (which you should, since
it's by far the Path Least Annoying), you will get both VisualuRuby (a
Windows-only higher-level wrapper around the GUI calls, aims to look
VB-like from the programming point of view in the vruby variant), and
FOX (a synthethic crossplatform toolkit with probably more bells and
whistles than VisualuRuby, but you have to bear with what I consider
ugly-looking results - YMMV).
If those don't work for you, there's always Gtk, so far the only GUI
library I can recall that comes with prebuilt Windows bindings mature
enough I would consider usable outside personal code. Gtk visual quality
and native veracity has improved from a sorry status recently, but is
still lacking in a few areas if you have pet peeves. (Like I do,
specifically non-native file choosers.) I do have hopes for the
wxWidgets binding maturing, and a prebuilt Qt4 one appearing though,
those two toolkits are the ones I prefer - wx for nigh-on-perfect native
veracity, Qt4 for Designer, Linguist, Assistant, and the whole shebang,
and the API style. (Which is very friendly to metaprogramming.) I
currently use the latter from its Python binding (both wx and Qt4 have
well-maintained and uptodate Python bindings), so if you want to get
something done, as opposed to poking around specifically Ruby, you might
try The Other Language.
David Vallner
Joel VanderWerf
..
> As far as I'm aware, Ruby doesn't include a GUI library in the standard
> library.
Tk is in the standard library. Don't laugh, it can be useful! :)
I'm using the Tk canvas for some easy-to-set-up animations that don't
really need opengl.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
David Vallner
> David Vallner wrote:
> ...
>> As far as I'm aware, Ruby doesn't include a GUI library in the standard
>> library.
>
> Tk is in the standard library. Don't laugh, it can be useful! :)
>
Wooer. I subconsciously ignore Tk by now. Go me. Or something.
/me puts on a dunce hat.
David Vallner
Suraj Kurapati
> David Vallner wrote:
> ...
>> library.
>
> Tk is in the standard library. Don't laugh, it can be useful! :)
>
> I'm using the Tk canvas for some easy-to-set-up animations that don't
> really need opengl.
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 don't know why people hate it so much. They seem to prefer "desktop
integration" and eye-candy instead of clean, functional interfaces.
Sigh. :-(
--
Posted via http://www.ruby-forum.com/.
zn...@cesmail.net
> 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 don't know why people hate it so much. They seem to prefer "desktop
> integration" and eye-candy instead of clean, functional interfaces.
> Sigh. :-(
I don't actually *hate* Tk -- I just never learned how to use it, and I think
its widgets are ugly relative to, say, Qt. Now Tcl, on the other hand -- that I
*do* hate. :-) It was the first scripting language, but I find Tcl code
virtually unreadable.
Richard
I'm planning to implement desk-top applications the same way I'm
implementing websites: use Ruby on Rails. That gives me essentially
one cross-platform application environment. Is there something wrong
with that plan?
---
Richard
David Vallner
> I don't know why people hate it so much. They seem to prefer "desktop
> integration" and eye-candy instead of clean, functional interfaces.
> Sigh. :-(
>
Some of us have to "sell" software, at least to managers - then it matters.
[Hide the women, children and livestock. This just got bloody as I
predicted.]
Also, you're missing the point. It's a GUI, noone really gives a damn if
the programmer had an easier time coding it if there's hundreds of users
that will feel constantly alienated by it because of some detail the
programmer didn't feel like bothering with.
User interface design isn't the same as programming a user interface.
Programmers, especially the lazy sort, tend to suck, suck-oh-so-horribly
at user interface design. Approaching user interface design with a
programmer's mindset can only end in pain, tragedy, and Tk.
Also, you're confusing internal UI consistency, and external UI
consistency. Internal UI consistency is when the features of the UI fit
together to make working with the software alone productive (your clean
and functional).
External consistency is when the UI incorporates features that make
working with that software in connection with other software on the
computer productive. This means panels will scroll when the mouse is
over them and won't require clicking on the buttons. This means that the
file chooser, on XP, will have a "My Documents" button as the third one
in a button sidepanel on the left. (I can't describe the rage I feel
when a toolkit opens a file chooser that doesn't even try to look alike
and leaves me flailing about trying to find my way back home.) I've seen
Tk interfaces fail at all the above when they're capabilities the damn
system below them gets right out of the box, and I've no doubt that's
barely the tip of the iceberg.
Both internal and external consistency are, for pretty much most
applications, factors that contribute to productivity. Having an
externally consistent program in no way excludes it being internally
consistent, so no point in setting up that straw man.
Any GUI toolkit will let you achieve internal consistency, and getting
really good usability from a GUI is 1% toolkit choice, 99% blood and
sweat. (My favourite GUI programs in terms of UI usability, and
consequently the ones I use most are firstly Opera, written in nothing
publically known for Windows, Qt3 for Linux, and IntelliJ IDEA, based on
the by-default-horrid Swing it makes sing and dance.) However, the
mindset of most Tk users seems to be to fight achieving external
consistency kicking and screaming and inventing nonarguments to prove
such patent nonsense as external consistence being undesirable. (That's
usually laziness, youthful zealotry, incompetence, or short time budget
speaking. Prove me wrong.)
Also, to set you right. People, or at least I (the only part of "people"
I can confidently speak for - for what part were you speaking and with
how much confidence when you used the words "people" and "they" again? -
obviously not yourself), don't just prefer eye candy. I want usable
interfaces that do what I need, do what I want, and do even what I
didn't know I wanted, and pay close attention now, that *also* look
good, look native-or-better (Java 6 giving me subpixel font AA on
Windows 2000 machines at work or under uncooperative Linux window
managers), act native-or-better (cf. some Windows programs that emulate
"scroll widget under cursor"). Both. And. No. Less. I am willing to and
have paid money to get that, and when forced to make a choice, there
will be something pissing me off with either alternative making me
wrestle lossage of some sort.
(PS: Just writing desktop integration in quotes doesn't make it of no
value. Refer to the missing the point by leagues bit above.)
Oh, and to make my position fully clear, I do hate Tk as a programmer
too. I find Qt linearly superior because of the object-oriented design,
MVC support, and the mixin architecture for separating UI and controller
logic, and QMetaObject::connectSlotsByName very reliably killing event
handler wireup boilerplate. And who really cares how you lay out the
widgets when there's Designer (the form designer that made me stop
hating form designers) to do that. Oh, and even with those features,
it's probably faster than Tk.
Tk isn't hardly the Ruby of GUI toolkits, with the massive advocating of
/ tolerance to mediocrity of results, it's the PHP of GUI toolkits.
David Vallner
No Way Someone Reads This Whole
Victor "Zverok" Shepelev
Sent: Sunday, December 17, 2006 5:56 AM
>Suraj Kurapati wrote:
>> I don't know why people hate it so much. They seem to prefer "desktop
>> integration" and eye-candy instead of clean, functional interfaces.
>> Sigh. :-(
>>
>
>Some of us have to "sell" software, at least to managers - then it matters.
>
>[Hide the women, children and livestock. This just got bloody as I
>predicted.]
>
>Also, you're missing the point. It's a GUI, noone really gives a damn if
>the programmer had an easier time coding it if there's hundreds of users
>that will feel constantly alienated by it because of some detail the
>programmer didn't feel like bothering with.
[...]
>David Vallner
>No Way Someone Reads This Whole
I had. And it was good words. Really worth to be remembered and quoted.
(I've been freelance UI designer and usability consultant during several
years, so I somewhat know, what it all about.)
V.
Michael T. Richter
No Way Someone Reads This Whole
|
-- Michael T. Richter Email: ttmri...@gmail.com, mtr...@hotpop.com MSN: ttmri...@hotmail.com, mtr...@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr...@jabber.cn "My paramount object in this struggle is to save the Union, and is not either to save or to destroy slavery." --Abraham Lincoln |
Richard
David Vallner wrote:
> How would that be a desktop application?
To us programmers it would be a web app with a local server, but to
the user it would be indistinguishable from, say, an application built
with Visual C++ and Microsoft Foundation Classes running on a Windows
OS.
Does that make sense to you?
---
Richard
Michael T. Richter
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.
Tk-based GUIs are typically so fscking useless that I'd rather use the CLI and ed over an app coded in Tk.
I don't know why people hate it so much. They seem to prefer "desktop integration" and eye-candy instead of clean, functional interfaces. Sigh. :-(
Suraj Kurapati
> Suraj Kurapati wrote:
>> I don't know why people hate it so much. They seem to prefer "desktop
>> integration" and eye-candy instead of clean, functional interfaces.
>> Sigh. :-(
>>
>
> Some of us have to "sell" software, at least to managers - then it
> matters.
Bingo! That's where we differ. I don't sell software so I haven't had to
deal with market pressures and bosses and customers, etc. Thus, my claim
might have more merit when viewed in the interest of programmer
productivity/laziness.
> Also, you're missing the point. It's a GUI, noone really gives a damn if
> the programmer had an easier time coding it if there's hundreds of users
> that will feel constantly alienated by it because of some detail the
> programmer didn't feel like bothering with.
Alas, what a world we live in. The same goes for movies where the stars
and director get a substantial chunk of the publicity/credit while the
back-end sound engineer is largely ignored.
[...]
> Approaching user interface design with a
> programmer's mindset can only end in pain, tragedy, and Tk.
LOL good one. :-)
> Also, you're confusing internal UI consistency, and external UI
> consistency. Internal UI consistency is when the features of the UI fit
> together to make working with the software alone productive (your clean
> and functional).
Interesting.
> External consistency is when the UI incorporates features that make
> working with that software in connection with other software on the
> computer productive. This means panels will scroll when the mouse is
> over them and won't require clicking on the buttons. This means that the
> file chooser, on XP, will have a "My Documents" button as the third one
> in a button sidepanel on the left.
I don't use windows, so I'm quite satisfied with Tk's horrendous
appearance and its lack of integration with "My documents".
Nevertheless, I can understand your point of view and I do sympathize.
[...]
> However, the
> mindset of most Tk users seems to be to fight achieving external
> consistency kicking and screaming and inventing nonarguments to prove
> such patent nonsense as external consistence being undesirable.
> (That's usually laziness, youthful zealotry,
Alright, you've caught me there :-)
> Also, to set you right. People, or at least I (the only part of "people"
> I can confidently speak for - for what part were you speaking and with
> how much confidence when you used the words "people" and "they" again? -
> obviously not yourself)
I do so with the confidence of uncertainty (probability = 0.5). When one
does not know the world, one naturally assumes the world is like one's
self. Alas, I am but a frog in a well.
[...]
> David Vallner
> No Way Someone Reads This Whole
Thanks for the lesson.
Suraj Kurapati
> On Sun, 2006-17-12 at 10:09 +0900, Suraj Kurapati 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.
>
>
>> I don't know why people hate it so much. They seem to prefer "desktop
>> integration" and eye-candy instead of clean, functional interfaces.
>> Sigh. :-(
>
>
> You may want to do some reading before you embarrass yourself further.
Why should I fear embarrassing or otherwise making an ass out of myself?
Such fear would prevent me from learning and keep me ignorant forever.
> Start with The Rise of Worse is Better
> (http://www.jwz.org/doc/worse-is-better.html). Then pick up a book on
> good UI design. Almost any book written on the topic in, say, the past
> 20 years will open your eyes to just how much effort and thought goes
> into a good user interface, GUI or otherwise. (Here's a hint: the vast
> majority of user interfaces suck bowling balls through garden hoses.)
Thanks for the link and suggestions.
Michael T. Richter
> You may want to do some reading before you embarrass yourself further.
Why should I fear embarrassing or otherwise making an ass out of myself? Such fear would prevent me from learning and keep me ignorant forever.
Being afraid of initial embarrassment is silly. Mistakes are a part of life and ignorance is the default condition. (I'd even, in my more cynical moments, extend "ignorance" to "stupidity" in the previous sentence -- yes, self included.) What you should be afraid of is repeated embarrassment: embarrassment on the same (or similar) points.
Being initially embarrassed is a sign of learning. Being further embarrassed on the same topic is a sign of not learning. See what I mean?
> Start with The Rise of Worse is Better > (http://www.jwz.org/doc/worse-is-better.html). Then pick up a book on > good UI design. Almost any book written on the topic in, say, the past > 20 years will open your eyes to just how much effort and thought goes > into a good user interface, GUI or otherwise. (Here's a hint: the vast > majority of user interfaces suck bowling balls through garden hoses.)
Thanks for the link and suggestions.
|
-- Michael T. Richter Email: ttmri...@gmail.com, mtr...@hotpop.com MSN: ttmri...@hotmail.com, mtr...@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr...@jabber.cn |
| "[Blacks] ... are inferior to the whites in the endowments both of body and mind." --Thomas Jefferson |
James Britt
> David Vallner wrote:
>> Suraj Kurapati wrote:
>>> I don't know why people hate it so much. They seem to prefer "desktop
>>> integration" and eye-candy instead of clean, functional interfaces.
>>> Sigh. :-(
>>>
>> Some of us have to "sell" software, at least to managers - then it
>> matters.
>
> Bingo! That's where we differ. I don't sell software so I haven't had to
> deal with market pressures and bosses and customers, etc. Thus, my claim
> might have more merit when viewed in the interest of programmer
> productivity/laziness.
I write most of my software for myself, and I'm fantastically lazy (to
point of borderline clinical death), but I'm with David. Tk hurts my
eyes. It annoys me in subtle ways that, over time, crawl under my skin
and gnaw at my tendons and bones. Ow!
Looks matter.
--
James Britt
"Inside every large system there's a small system trying to get out".
- Chet Hendrickson
Suraj Kurapati
> Being initially embarrassed is a sign of learning. Being further
> embarrassed on the same topic is a sign of not learning. See what I
> mean?
Understood.
>> > Start with The Rise of Worse is Better
>> > (http://www.jwz.org/doc/worse-is-better.html).
I strive to be in the worse-is-better camp. :-)
>> Then pick up a book on
>> > good UI design. Almost any book written on the topic in, say, the past
>> > 20 years will open your eyes to just how much effort and thought goes
>> > into a good user interface, GUI or otherwise. (Here's a hint: the vast
>> > majority of user interfaces suck bowling balls through garden hoses.)
Agreed. I'm familiar with a bit of Jakob Nielsen's work and Marc
Rettig's wonderful "paper prototyping" technique -- but that's about it.
> If you want to take this off-list, I might even
> be able to direct you to some decent books on HUI design (or at least
> some web pages with decent information).
If you don't mind, please post the web resources here, so that we may
all benefit from your guidance.
Thanks for your consideration.
Michael T. Richter
>>> Start with The Rise of Worse is Better >>> (http://www.jwz.org/doc/worse-is-better.html).
I strive to be in the worse-is-better camp. :-)
If you don't mind, please post the web resources here, so that we may all benefit from your guidance.
|
-- Michael T. Richter Email: ttmri...@gmail.com, mtr...@hotpop.com MSN: ttmri...@hotmail.com, mtr...@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr...@jabber.cn |
| "I think it is very beautiful for the poor to accept their lot [...]. I think the world is being much helped by the suffering of the poor people." --Mother Theresa |
David Vallner
> David Vallner wrote:
>> How would that be a desktop application?
>
> To us programmers it would be a web app with a local server, but to
> the user it would be indistinguishable from, say, an application built
> with Visual C++ and Microsoft Foundation Classes running on a Windows
> OS.
>
Now -that- I want to see. Really. Odds are it Just Won't unless you only
render in IE with high security privileges and abuse ActiveX with
reckless abandon.
> Does that make sense to you?
>
As I'm generally not a fan of the heinous crimes commited in the name of
Ajax, I'd have to see the result for that to happen. Most of the
in-browser desktop mockups make me ask why not use Java Web Start /
ClickOnce / Flex anyway? DHTML still doesn't work fully reliably even
amongst standards-compliant browsers due to the W3C being too busy
reinventing the world in angle brackets and trying to force the shiny
markup language of the day down the throats of the whole ten people that
understand and need it instead of properly addressing Ajax (that
undoubtedly impacts more web users right now than the joke that is
XForms). And the dependencies for the above technologies aren't rocket
science to fullfill.
David Vallner
David Vallner
>> Most of the
>> in-browser desktop mockups make me ask why not use Java Web Start /
>> ClickOnce / Flex anyway?
>
> apps. Java is, too my taste, a lousy C++, which I felt is the most
> elegant programming language ever. But I've come to see that Ruby is
> the most economical yet powerful (in terms of programmer effort)
> languages ever. Of course, I'm not really qualified to make such
> judgments, despite 40+ years of professional programming experience
> with IBM mainframe assembler, Fortran, and Cobol to desktop Visual C++.
>
For the client-side logic, you're still stuck to HTML and Javascript,
which are both flawed in their way. While web frameworks help with that,
it's still artificially shifting logic that could as well be done
client-side (validation which only requires checking against the data
the client is already operating on already, paginating content,
formatting data, etc.) I mentioned the above technologies because they
exist, while I'm not aware of any way to easily keep a Ruby-based client
program up-to-date conveniently, or even deliver it cross-platform
easily because of the dependency on native extensions.
I'm not very sure how Rails would be suitable to make desktop
applications, the framework doesn't seem to have a discernable core for
action processing that would be unaware of web idiosyncracies. I might
be wrong.
The namedropped (in a snarky way) experience is ad verecundiam, a
logical fallacy. To respond to it any more would be stooping down to the
same level.
> I see by your disdain of some aspects of the current state of affairs
> that you've thought a lot about some of these issues, so I'm
> interested in knowing whether you're more sanguine about the
> Ruby-Rails-WEBrick-MySQL environment.
>
Ruby is fine if you can juggle the complexity, but it requires more
programmer competence and dilligence for the software to be robust - a
quality that grows with importance the closer to end users you get.
I'm past my "Oooh, shiny!" Rails phase. Scaffolding is nice, yet in a
way just smoke and mirrors, ActiveRecord is just way too basic as an ORM
solution and not much simpler to use once enough of its assumptions on
the data model and physical DB schema don't hold. Convention over
configuration gets hairy in complex deployment scenarios - table names
changing (having to accomodate to a weird naming convention between
prototype and production) mean a recode, and generally the magic becomes
harmful if you need to separate the object model from the tables and
columns. I don't think this applies to your scenario though.
WEBrick is a development server. Probably Good Enough for a one server -
one user scenario, but I don't think it's meant to handle more.
As for MySQL, I more or less share the attitude of Austin Ziegler on it.
Most of MySQL users are mentally stuck with v3.x and make data schemas
that would make an onion cry. Mentioning "no security risks" if you let
arbitrary clients access your database is debatable though, I thought
you're supposed to keep production data storage behind a firewall.
Giving end-users write-access credentials sounds like way too much
potential for a malicious user to do damage to me, unless you only allow
write access through secured stored procedures, or bend your model
backwards for table-level restrictions to be sufficient. I'll have to
disclaim though that I'm far from a security expert, so the above are to
an extend half-educated guesses.
As for the whole environment, my work experience so far has been in
scenarios where that would blow up on data schema brittleness, or the
generations-of-maintaining-interns syndrome. As for any such solution
template, there are assumptions that must hold before the solution can
be an effective one. The "we have a hammer, now every problem is a nail"
approach is a very destructive self-delusion (to wit: J2EE's rap of
being overcomplex after hype led to it being used for the wrong range of
problems.) Since I don't know your problem, and the umpty other factors
that have to be considered when creating a software system's
architecture (the target audience, the deployment requirements, the
performance requirements, how well does the domain model map to being
handled over the web), I can't judge whether the approach you outlined
is a good fit. This is hugely digressing from the original topic though.
David Vallner
M. Edward (Ed) Borasky
> The namedropped (in a snarky way) experience is ad verecundiam, a
> logical fallacy. To respond to it any more would be stooping down to the
> same level.
>
experience that likes Ruby and is still spending some time every day
writing code. :)
> I'll have to
> disclaim though that I'm far from a security expert, so the above are to
> an extend half-educated guesses.
>
1. Trust nobody, even yourself. :)
2. Satisfy the Congress, the attorneys and accountants first, then your
business partners, then your customers. If you have anything left over,
satisfy your employees.. :)
3. Back everything up! And stress-test your disaster recovery mechanisms!
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
Michael T. Richter
IMHO, Ruby + Rails is a far superior way to build both desktop and web apps. Java is, too my taste, a lousy C++, which I felt is the most elegant programming language ever.
|
-- Michael T. Richter Email: ttmri...@gmail.com, mtr...@hotpop.com MSN: ttmri...@hotmail.com, mtr...@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr...@jabber.cn |
| "I have no purpose, directly or indirectly, to interfere with the institution of slavery in the States where it exists." --Abraham Lincoln |
Richard
based on a few months of experience with these products.
David Vallner wrote:
> For the client-side logic, you're still stuck to HTML and Javascript,
> which are both flawed in their way. While web frameworks help with that,
> it's still artificially shifting logic that could as well be done
> client-side (validation which only requires checking against the data
> the client is already operating on already, paginating content,
> formatting data, etc.) I
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". Do you agree?
Secondly, the kind of apps I've worked on (and plan to continue working
on) all need robust user interfaces. Raw HTML is no doubt inferior to,
say, Microsoft's MFC or Java's Swing. However, Rails code is run
through Extended Ruby (erb) which programmatically generates repetitive
HTML, so it's pretty nice to use even absent a drag-n-drop GUI
builder.
> I'm not aware of any way to easily keep a Ruby-based client
> program up-to-date conveniently
Ruby supports Test Driven Development in a very rich way (which I never
did before). Likewise, it supports automated programming
documentation in pretty convenient way (never did that either). Add
the fact that it supports database development with an abstraction that
offers independence from variations of SQL implementations. I'm
optimistic that maintenance will be easier on these projects than any
I've been on before.
> or even deliver it cross-platform
> easily because of the dependency on native extensions.
Rails is based on Ruby. Ruby is based on C. And C is widely viewed as
a hardware abstraction layer. So that stuff is already ported anywhere
I'm likely to want to go.
> I'm not very sure how Rails would be suitable to make desktop
> applications, the framework doesn't seem to have a discernable core for
> action processing
It implements an MVC architecture in a very neat way. The model
house/enforces the business logic. The views present data from the
models to the client, and pass back client actions as appropriate. The
controllers oversee the traffic between those layers. I haven't done
much of this yet, so it remains for me to see how well that works.
> that would be unaware of web idiosyncracies. I might
> be wrong.
That's a good point to consider. What sort of idiosynchrasies might
adversely affect this scheme, noting that we're planning for apps on
isolated machines (except for the dataset connection)?
> The namedropped (in a snarky way) experience is ad verecundiam, a
> logical fallacy.
I didn't intend to offend anyone. I forgot why I mentioned it.
(Unfortunately, I deleted my posted msg). I think I was making it
clear that I've had a lot of experience in a variety of software
development environments. I intended, but failed, to make it clear at
the outset that I was new to Ruby, Rails and web development. I can't
see that constitutes "the fallacy of making an illicit appeal to
authority". But, as you say, it's not worth pursuing.
> Ruby is fine if you can juggle the complexity, but it requires more
> programmer competence and diligence for the software to be robust - a
> quality that grows with importance the closer to end users you get.
Isn't that true regardless of the language?
> I'm past my "Oooh, shiny!" Rails phase. Scaffolding is nice, yet in a
> way just smoke and mirrors.
Any large application requires decisions about how the code should be
factored. Rails gives you one-liners that puts stuff in the "right"
place so it will be found by other pieces and by the developer.
Wouldn't you credit that as more than smoke and mirrors. Particularly
that they've built in this scheme of "helpers" that help
developer's factor their code that IMHO is a natural way.
> ActiveRecord is just way too basic as an ORM
> solution and not much simpler to use once enough of its assumptions on
> the data model and physical DB schema don't hold.
If you use Active Record Migration, the SQL database schema would
always be in synch, wouldn't it? And don't you value that Rails
automatically maintains a history of migrations so you can easily back
up to an earlier version if necessary; likewise for matching back up
with the program code so long as version control, e.g. Subversion that
Rubyists like.
> Convention over
> configuration gets hairy in complex deployment scenarios - table names
> changing (having to accommodate to a weird naming convention between
> prototype and production) mean a recode, and generally the magic becomes
> harmful if you need to separate the object model from the tables and
> columns. I don't think this applies to your scenario though.
As I understand it, only the database name changes between
development, test and production, not any of the table-names nor any
code except doe some external symbol indicating which one is targeted.
An important service Rails provides, and that I love, is in generating
single and two-way linkages for one-to-many and many-to-many
relationships with one-liners and simple column-name standards for
keys. I've only used one database system that might be an ORM:
Documentum. But all my database past and anticipated needs have been
and I expect will be satisfied E. F. Codd's style of database:
Oracle, SQL Server, DB2 and little old MySQL.
> WEBrick is a development server. Probably Good Enough for a one server -
> one user scenario, but I don't think it's meant to handle more.
Great: that fits my target scenario.
> As for MySQL, I more or less share the attitude of Austin Ziegler on it.
> Most of MySQL users are mentally stuck with v3.x and make data schemas
> that would make an onion cry.
I've been using ver. 5 and the schemas Rails generates from migrations
seem OK to me. I particularly like the fact that this version supports
transactions .. IMHO a "must" for app relying on database support.
> Mentioning "no security risks" if you let
> arbitrary clients access your database is debatable though, I thought
> you're supposed to keep production data storage behind a firewall.
> Giving end-users write-access credentials sounds like way too much
> potential for a malicious user to do damage to me, unless you only allow
> write access through secured stored procedures, or bend your model
> backwards for table-level restrictions to be sufficient. I'll have to
> disclaim though that I'm far from a security expert, so the above are to
> an extend half-educated guesses.
That's something I have to work on. My first thought is that the
MySQL server has to be on a machine whose physical security is
maintained. Then it needs network authentication for users and user
machines hitting on it. MySQL seems to support user security pretty
well with access levels and encrypted passwords. That encryption
scheme could be used on critically sensitive data if performance allows
it. If the LAN connecting the database to users has any Internet
connection, then the database server machine will need a firewall, too,
as you said.
It's been nice using this thread to think through some of these
issues and having the opportunity to try to "sell" my ideas and
consider the weaknesses they may suffer. So this exercise has been
good for me. Thanks for your enthusiastic participation.
Best wishes,
Richard
Richard
> Wow! Someone used the words "C++" and "elegant" in the same sentence
> without a negative in between and with no hint of irony.
I know you meant that in a light-hearted way. Yet, I wonder whether
you agree that there have been a lot of books sold on that topic? And
that most of those by people under no duress?
If you agree with the foregoing, you'll likely concede there are (or
at least, were) a good number of other that at least that the language
to be "good". And do you think it's possible a few them even would add
"elegant"?
Then I wonder whether you read Stroustrup's "The Design and Evolution
of C++"? It strikes me as a great engineering example. Do you agree.
(For that matter, do you think the development of C was great
engineering?)
Do you a good opinion of any of the high-level general-purpose
languages? Any that you find elegant?
How about Ruby? Rails? Do you find either of them elegant?
Is it all just a matter of taste?
Best wishes,
Richard
Suraj Kurapati
If I understand correctly:
>> WEBrick is a development server. Probably Good Enough for a one server -
>> one user scenario, but I don't think it's meant to handle more.
>
> Great: that fits my target scenario.
We have a one-user application...
> That's something I have to work on. My first thought is that the
> MySQL server has to be on a machine whose physical security is
> maintained. Then it needs network authentication for users and user
> machines hitting on it. MySQL seems to support user security pretty
> well with access levels and encrypted passwords.
And lots of baggage if we use a system for multi-user applications...
> That encryption
> scheme could be used on critically sensitive data if performance allows
> it. If the LAN connecting the database to users has any Internet
> connection, then the database server machine will need a firewall, too,
> as you said.
And security concerns about data leaking from the user's machine...
Might I suggest:
- use WEBrick on a firewalled port that is accessible only from the
local machine 0.0.0.0
- use the SQLite3 (http://wiki.rubyonrails.org/rails/pages/SQLite)
because it stores data in normal (binary) files on the machine it's
running on. For example, if your Rails app is located in /foo/bar, then
the DB files will be in /foo/bar/db/
- for concerns about upgrading (i.e. it's easier to update one central
server than updating many individual machines), you could have each user
check-out your whole rails app from a version control system. Then, when
you do maintainance updates to your DB schema and so on, the user would
simply update their check-out and run "rails migrate". Done!
Suraj Kurapati
message. :-(
Suraj Kurapati
> when
> you do maintainance updates to your DB schema and so on, the user would
> simply update their check-out and run "rails migrate". Done!
That should be "rake migrate" not "rails migrate".
Michael T. Richter
> Wow! Someone used the words "C++" and "elegant" in the same sentence > without a negative in between and with no hint of irony.
I know you meant that in a light-hearted way. Yet, I wonder whether you agree that there have been a lot of books sold on that topic? And that most of those by people under no duress?
Problem #1 with C++ (of several billion): it requires literally infinite lookahead to fully parse. This is not something I would ever consider even remotely elegant.
Then I wonder whether you read Stroustrup's "The Design and Evolution of C++"? It strikes me as a great engineering example. Do you agree. (For that matter, do you think the development of C was great engineering?)
C++ is a hack layered on this hack. Despite being designed for projects "in the large" it still has no support for automated memory management which, given its unnatural appetite for memory (in typical C++ programming), is really funny. Further, although an "object-oriented" language, things like iterators are an afterthought (and it shows!) added later on in the library interface instead of being a core part of the language. And it still sucks--despite the addition of namespaces, classes, etc.--at actually helping in modular programming. You have to recompile, for example, if the implementation of a class you're using changes. (I still shake my head at this.) It's not enough just to relink to a new object file/library/whatever. You have to recompile your source. (This is, of course, again because of that filthy #include thing.)
Then we have templates.... I'm not even going to begin that rant.
Do you a good opinion of any of the high-level general-purpose languages? Any that you find elegant?
I really liked Dylan. Which, sadly, died on the vine.
From the more classic line, I liked Modula-3 as well -- which also, sadly, died on the vine.
How about Ruby? Rails? Do you find either of them elegant?
I lack sufficient experience in Rails to call it elegant or not. I simply have no opinion. There are some things which at first glance appear very impressive to me, but C++ templates did once too until I had to use them extensively. (My first run-in with ">>" vs. "> >" pretty much ended my love affair with templates in a huge, bloody crash.)
Is it all just a matter of taste?
|
-- Michael T. Richter Email: ttmri...@gmail.com, mtr...@hotpop.com MSN: ttmri...@hotmail.com, mtr...@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr...@jabber.cn |
| "Sexual organs were created for reproduction between the male element and the female element -- and everything that deviates from that is not acceptable from a Buddhist point of view. Between a man and man, a woman and another woman, in the mouth, the anus, or even using a hand." --The Dalai Lama |
David Vallner
> This caught my eye: http://vruby.sourceforge.net/sample/traytest.rb
> It adds a system tray icon, modifies one, deletes the one created, among
> other things. There's a comment in there about the added task tray icon
> not
> automagically deleting itself upon the window closing. What I'm uncertain
> of, is how to go about fixing that. Some of the other programs I was able
> to make minor changes too in order to make it look how I wanted, but this
> problem eludes me. Can anyone suggest a way to modify the program in order
> to automagically check for task bar icons before closing the program?
Trap SIGINT in the UI setup? The closure should make this fairly
automagical if you don't mind the memory leak.
Also, no idea about vruby, but some other GUI toolkits I worked with
provide a window close hook. Search through the documentation for some
sort of "on close" event to handle on the main application window?
(Where you'd likely keep a reference to the tray icon.)
David Vallner
David Vallner
> 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". Do you agree?
>
Yes. However, there's still the HTTP request divisor in the middle, with
no / hacked push in the WEBrick -> Firefox direction. At least as far as
I know, prototype.js, the Javascript library Rails uses for Ajax
support, doesn't try to support any form of pub/sub messaging or
anything close to sane event support in the push direction. Of course,
it might be possible your application only needs to pull data.
> Secondly, the kind of apps I've worked on (and plan to continue working
> on) all need robust user interfaces. Raw HTML is no doubt inferior to,
> say, Microsoft's MFC or Java's Swing. However, Rails code is run
> through Extended Ruby (erb) which programmatically generates repetitive
> HTML, so it's pretty nice to use even absent a drag-n-drop GUI
> builder.
>
I don't actually find Swing superior to setup a UI, HTML, while flawed,
mirrors the UI layout in its structure, which is a good thing. However,
for me that is offset by having fine-grained data binding - for complex
UIs, it rubs me in a better way than bending my code to be essentially
request / (partial) response.
>> or even deliver it cross-platform
>> easily because of the dependency on native extensions.
>
> Rails is based on Ruby. Ruby is based on C. And C is widely viewed as
> a hardware abstraction layer. So that stuff is already ported anywhere
> I'm likely to want to go.
>
I didn't mean work in the first place. I meant keeping an up-to-date
version on all the users' machines. Last time there was a thread on the
subject of distributing whole applications with rubygems, I think there
were quite a few gotchas mentioned. But you might want to search the
archives for that to see if the approach is viable / what you'd have to
work around.
>> I'm not very sure how Rails would be suitable to make desktop
>> applications, the framework doesn't seem to have a discernable core for
>> action processing
>
> It implements an MVC architecture in a very neat way. The model
> house/enforces the business logic. The views present data from the
> models to the client, and pass back client actions as appropriate. The
> controllers oversee the traffic between those layers. I haven't done
> much of this yet, so it remains for me to see how well that works.
>
No / weak / coarse-grained push from the model to the view would be a
showstopper for me for the sort of problems where'd I use a rich GUI.
>> that would be unaware of web idiosyncracies. I might
>> be wrong.
>
> That's a good point to consider. What sort of idiosynchrasies might
> adversely affect this scheme, noting that we're planning for apps on
> isolated machines (except for the dataset connection)?
>
Nothing that's really a showstopper from this point of view, just the
request / response / sessions clutter that's not really essential to the
way I would model a rich GUI application. For me, it would involve
working around those, maybe you have an architectyre / model in mind
where the mapping is straightforward.
>> Ruby is fine if you can juggle the complexity, but it requires more
>> programmer competence and diligence for the software to be robust - a
>> quality that grows with importance the closer to end users you get.
>
> Isn't that true regardless of the language?
>
Not on a quantitative level. Easily accessible metaprogramming
facilities are a potential complexity explosion, and need competence and
/ or restraint to avoid abstraction leak between modules. (For example
introducing a method to a class at a scope where it clutters in modules
that probably won't use the functionality "because it's convenient that
way".)
>> ActiveRecord is just way too basic as an ORM
>> solution and not much simpler to use once enough of its assumptions on
>> the data model and physical DB schema don't hold.
>
> If you use Active Record Migration, the SQL database schema would
> always be in synch, wouldn't it? And don't you value that Rails
> automatically maintains a history of migrations so you can easily back
> up to an earlier version if necessary; likewise for matching back up
> with the program code so long as version control, e.g. Subversion that
> Rubyists like.
>
If creating a database schema from scratch, unless you hit some of the
more obscure deficiencies of AR (2PC and the like), in your scenario
it's probably fine.
While migrations are indeed sexy, using them means you pretty much
eschew the magic of AR, at which point it becomes only incrementally
more convenient as an ORM solution rather than revolutionary.
> An important service Rails provides, and that I love, is in generating
> single and two-way linkages for one-to-many and many-to-many
> relationships with one-liners and simple column-name standards for
> keys.
This I consider unforgivable brain-damage, AR should have supported
database metadata investigation and looking at foreign key constraints
out of the box. Same goes for migrations-generated schemas (I haven't
really seen those, I admit.).
>> As for MySQL, I more or less share the attitude of Austin Ziegler on it.
>> Most of MySQL users are mentally stuck with v3.x and make data schemas
>> that would make an onion cry.
>
> I've been using ver. 5 and the schemas Rails generates from migrations
> seem OK to me. I particularly like the fact that this version supports
> transactions .. IMHO a "must" for app relying on database support.
>
And only decades after all the competition. Currently, I don't see much
of a reason why not to use MySQL in a general scenario (before
concurrency handling considerations and load tests come into play),
however I also don't see much of a reason to do so - I'll stay with
religious opinions and stick to the featurefullness of Postgres.
David Vallner
Richard
Though I've bought and skimmed a few books on compiler design (because
I am a mathematician who likes that kind of stuff), I don't know
enough to dispute any of the internals that you discuss here concerning
computer-language design. I'll just respond with my perceptions born
out my experience mainly as an independent computer consultant in
business & gov't info systems.
> Point me to a single book that calls C++ "elegant" written by someone
> who, you know, designs languages. C++ is a hack built on a hack.
Stroustrup said: My initial aim for C++ was a language where I could
write programs that were as elegant as Simula programs, yet as
efficient as C programs [Java Report, July 2000]: Incidentally, he
held a doctorate in Math, I believe. And this may be a self-serving
statement; besides, he missed his goal in your eyes.
Herb Schildt (a prolific author on computer technology) in "STL
Programming From the Ground Up", 1999, wrote on p.5: "The combination
of Stroustrup's insight into OOP and Stepanov's vision for 'plug
compatible' software components yielded a powerful new software
paradigm." Maybe not "elegant", but "powerful". I'd say maybe its
just a semantic difference.
The authors of the Wikipedia article on "Template Metaprogramming"
extol C++ virtues in its ability to unroll recursive expressions, e.g.
transform a factorial definition to a number at compile time. They
didn't say "elegant", but I think they might agree if pressed on the
matter.
> Problem #1 with C++ (of several billion): it requires literally infinite
> lookahead to fully parse. This is not something I would ever consider
> even remotely elegant.
No doubt every compiler of a general purpose programming language is
susceptible of failure for some well formed programs. But I never had
a C++ compiler fail on anything I've written. Maybe I just haven't
been working very hard :-)
> C was not great engineering.
My main reason for lauding C's engineering is the insight that creating
ever more powerful languages with compilers that translate to machine
code is a poor strategy, e.g. Fortran, then Cobol, then PL/1. The
alternative K&R devised is a *small* language plus the creation of a
lot of tools to allow application programming at a higher level. If
nothing else, this allowed economical porting of the whole thing hither
and yon.
> It was a high level assembler
so what?
> full of quirks based on its first implementation platform (PDP-11) --
> quirks that kill (sometimes literally) to this very day.
That flies in the face of the fact that that it's probably the widely
ported of any programming language ever.
> It is
> acceptable (barely) as a systems programming tool provided it is used
> under intensely-inspected environments.
What's wrong with that? I'd expect anything built for use (directly or
indirectly) by a mass of people to be monitored for extreme quality
control.
>Its use in applications verges
> on the criminal culpability side of things.
Well, I've certainly got war stories to testify to the problems of app
development with C. But who does that anymore? C is very big for
programming in the embedded world. The many organizations that take
that route can't all be run by idiots.
> The list of useful (and
> some necessary) features that C lacks for application programming
> includes ...
I concede that (though I don't know much about those details). But
they can be handled at a higher level written in C, just as K&R
conceived it. Case in point: the original C++ was built on C and
certainly has been widely adopted and no doubt address some of things
that are not in C natively.
> C++ is a hack layered on this hack. Despite being designed for projects
> "in the large" it still has no support for automated memory management
> which, given its unnatural appetite for memory (in typical C++
> programming), is really funny.
Check out "Accelerated C++", Koenig & Moo, , 2000, pp. 182, 203, 223,
262; "Effective STL", Scott Meyers, 2001, pp. 173-175
> Further, although an "object-oriented"
> language, things like iterators are an afterthought (and it shows!)
> added later on in the library interface instead of being a core part of
> the language.
So what? Lots of stuff in most languages is added to languages as they
evolve. IMHO, C++ is no different than Ruby in this respect.
> And it still sucks--despite the addition of namespaces,
> classes, etc.--at actually helping in modular programming. You have to
> recompile, for example, if the implementation of a class you're using
> changes. (I still shake my head at this.) It's not enough just to
> relink to a new object file/library/whatever. You have to recompile
> your source. (This is, of course, again because of that filthy #include
> thing.)
Well, I can't see why recompilation is an important issue. I've
always treated recompilation time as coffee-break time.
> Then we have templates.... I'm not even going to begin that rant.
I loved their introduction. I mentioned them above as a virtue. If
you decry them in C++, you've also got to carp about 'parameterized
types', known as 'generics', in Ada, Eiffel, Java, and C# (according
to Wikipedia's article on "Generic Programming").
> > Do you a good opinion of any of the high-level general-purpose
> > languages? Any that you find elegant?
> ...Haskell and dead ones: Dylan, Modula-3
I just took a fast peek at Haskell. I noticed Guards, and that
brought back memories of trying to achieve provably correct programs.
As I recall, there some proof that no system can be built to proved
the logical correctness of every program. (Just a side note.)
But I've never heard of it. I can't imagine any client allowing me do
develop an information system that neither of us ever heard of. Have
you been able to use it inside any large organization?
> I would not call Ruby "elegant" but I will call it a joy to program in.
I'm with you on that!
> If it didn't have Perl's magic variables, et
> al. I'd be more inclined to call it elegant even.
Here, here! I refuse to use any Perlisms. I think there a Ruby Way
for all of them.
> I lack sufficient experience in Rails to call it elegant or not. I
Rails is what won me over. I think it's brilliant, though I'm still
struggling to master a bunch of major issues in it and Ruby.
> There are some things which at first glance
> appear very impressive to me, but C++ templates did once too until I had
> to use them extensively. (My first run-in with ">>" vs. "> >" pretty
> much ended my love affair with templates in a huge, bloody crash.)
Ouch! Did you consider some abstraction that was a more palatable way
to employ templates. Heck, Stroustup's early compilers were "merely"
preprocessors to the C compiler. I wonder if something like that would
have ameliorated the risky syntax.
> > Is it all just a matter of taste?
> Yes. Bad taste and my taste. ;)
Well, you've got me there! :-)
Best wishes,
Richard
Richard
David Vallner wrote:
> Suraj Kurapati wrote:
> locally.
Right on David. But Suraj's comments make me wonder: if I create a
new migration on the MySQL server, wouldn't I almost surely make some
changes in the Rails app? Otherwise, what would be the point?
That leads me to thing that the machine housing the MySQL server should
be my development machine. There I make my changes targeting the test
db, run all my tests (including new ones specifically to cover the
changes), put all the Rails-app changes into version control.
Finally, I broadcast to all users to update their local copy of the
Rails app.
Make sense?
Regards,
Richard
Richard
Thanks for responding.
> > That's something I have to work on. My first thought is that the
> > MySQL server has to be on a machine whose physical security is
> > maintained. Then it needs network authentication for users and user
> > machines hitting on it. MySQL seems to support user security pretty
> > well with access levels and encrypted passwords.
>
> And lots of baggage if we use a system for multi-user applications...
You think MySQL 5.0 server version is not good for multi-user
applications?
> And security concerns about data leaking from the user's machine...
>
> Might I suggest:
>
> - use WEBrick on a firewalled port that is accessible only from the
> local machine 0.0.0.0
I'm planning to use WEBrick server on each user's machine, as well as
on the database server/development machine/version-control repository.
Everybody will access their own copy of the web-server at
localhost:3000. where localhost=127.0.0.1. Is 0.0.0.0 superior to
that, and why?
> - use the SQLite3 (http://wiki.rubyonrails.org/rails/pages/SQLite)
> because it stores data in normal (binary) files on the machine it's
> running on. For example, if your Rails app is located in /foo/bar, then
> the DB files will be in /foo/bar/db/
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.
> - for concerns about upgrading (i.e. it's easier to update one central
> server than updating many individual machines), you could have each user
> check-out your whole rails app from a version control system. Then, when
> you do maintainance updates to your DB schema and so on, the user would
> simply update their check-out and run "rails migrate". Done!
(I noted your "rake migrate" correction)
If confused about one thing here. Since the databases and development
environment are on one machine, shouldn't I:
- run "rake migrate" only on this machine
- update the Rails app to relating to the changes in the database
- update my test suite to test those changes (or write the tests first
to satisfy some purists)
- run my entire test suite until all tests pass
- submit my Rails app to the version control system
- broadcast a message to all users that the should update their version
of app by getting the latest and greatest version?
Regards,
Richard
Richard
I think we're converging to a solution.
> > The app structure I outlined ... Do you agree?
>
> Yes. However, there's still the HTTP request divisor in the middle, with
> no / hacked push in the WEBrick -> Firefox direction. ...Of course,
> it might be possible your application only needs to pull data.
OK, we'll have to wait and see on that, 'cause I don't know.
> > Secondly, the kind of apps I've worked on (and plan to continue working
> > on) all need robust user interfaces. ...
>
> ... However,
> for me that is offset by having fine-grained data binding - for complex
> UIs, it rubs me in a better way than bending my code to be essentially
> request / (partial) response.
OK, another thing to wait on.
> > ... So that stuff is already ported anywhere
> > I'm likely to want to go.
> I didn't mean work in the first place. I meant keeping an up-to-date
> version on all the users' machines. Last time there was a thread on the
> subject of distributing whole applications with rubygems, I think there
> were quite a few gotchas mentioned. But you might want to search the
> archives for that to see if the approach is viable / what you'd have to
> work around.
Gotcha. I just posed the question about handling upgrades to the app.
I didn't think about Ruby gems. I thought I'd make the database server
machine server as the developer machine as well as the config. mgmt
machine. So when a database schema change is required, I thought I'd
shutdown access to users and:
- run "rake migrate" only on this machine
- update the Rails app to relating to the changes in the database
- update my test suite to test those changes (or write the tests first
to satisfy some purists)
- run my entire test suite until all tests pass
- submit my Rails app to the version control system
- broadcast a message to all users that the should update their version
of app by getting the latest and greatest version?
What do you think of that?
> ... weak / coarse-grained push from the model to the view would be a
> showstopper for me for the sort of problems where'd I use a rich GUI.
I don't understand. 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.
Then the contoller tells the appropriate view to do its thing with the
data, namely produce HTML with the data suitable tagged plus embedded
Ruby and send that amalgam to the web-server. The web-server invokes
Extended Ruby to process the "enriched" HTML and send the resulting
vanilla HTML to the browser.
Is my description of the process OK? Does "push" refer to the
"web-server to browser" step?
> > That's a good point to consider. What sort of idiosynchrasies might
> > adversely affect this scheme ...
> Nothing that's really a showstopper from this point of view, just the
> request / response / sessions clutter that's not really essential to the
> way I would model a rich GUI application.
Gotcha. But all the request/response stuff is on a single box, so the
processing time should be a few milliseconds, don't you think?
> For me, it would involve
> working around those, maybe you have an architectyre / model in mind
> where the mapping is straightforward.
I've anticipating a dozen, maybe two dozen, tables with lots of
one-to-many and many-to-many relations, somewhat complex updates which
would be unpleasant to program were it not for transaction service for
the DBMS. However, the amount of data in any transaction will be
small. And the data transfers for display will be small, too, because
all tables will be paged.
> >> Ruby is fine if you can juggle the complexity ...
> > Isn't that true regardless of the language?
> Not on a quantitative level. Easily accessible metaprogramming
> facilities are a potential complexity explosion, and need competence and
> / or restraint to avoid abstraction leak between modules. (For example
> introducing a method to a class at a scope where it clutters in modules
> that probably won't use the functionality "because it's convenient that
> way".)
I don't plan to intoduce that kind of complexity myself. I'm sure
Rails itself employs some metaprogramming, but I'm confident that
works well, requiring no meddling by me.
> >> ActiveRecord is just way too basic as an ORM ...
> > If you use Active Record Migration, the SQL database schema would
> > always be in synch, wouldn't it? ...
> If creating a database schema from scratch, unless you hit some of the
> more obscure deficiencies of AR (2PC and the like), in your scenario
> it's probably fine.
Cool!
> While migrations are indeed sexy, using them means you pretty much
> eschew the magic of AR, at which point it becomes only incrementally
> more convenient as an ORM solution rather than revolutionary.
I plan to use mostly generated screens funtil I've got concept approval
from clients. So I can use AR to painlessly regenerate any of them
affected by DB changes. However, I also anticipate a number of
screens with one or more tables with column-by-column table-sorting and
filtering functionality. But most of that involves passing parameters
in links that invoke a package that produces the required effect. I've
got a demo of that working -- I just need to figure out how to package
it.
> > An important service Rails provides, and that I love, is in generating
> > single and two-way linkages for one-to-many and many-to-many
> > relationships with one-liners and simple column-name standards for
> > keys.
> This I consider unforgivable brain-damage, AR should have supported
> database metadata investigation and looking at foreign key constraints
> out of the box.
Yea, but its only a few lines here and there. To me, it's really
painless, especially considering what I've had to do with Oracle and
SQL Sever using VC++.
> > I've been using ver. 5 and the schemas Rails generates from migrations
> > seem OK to me. ...
> And only decades after all the competition. Currently, I don't see much
> of a reason why not to use MySQL in a general scenario (before
> concurrency handling considerations and load tests come into play),
> however I also don't see much of a reason to do so - I'll stay with
> religious opinions and stick to the featurefullness of Postgres.
I'm planning to look into the final choice of DBMS in the final stage
of my current project. Concurrency handling and response times are
certainly issues I'll want to address.
Thanks for your ideas.
Best wishes,
Richard
Suraj Kurapati
>> If I understand correctly:
>>>> WEBrick is a development server. Probably Good Enough for a one server -
>>>> one user scenario, but I don't think it's meant to handle more.
>>>
>>> Great: that fits my target scenario.
>> We have a one-user application...
So, whatever I wrote below, it was under the assumption that only one
user would access the database (i.e. each user has their own DB).
Richard wrote:
>> > That's something I have to work on. My first thought is that the
>> > MySQL server has to be on a machine whose physical security is
>> > maintained. Then it needs network authentication for users and user
>> > machines hitting on it. MySQL seems to support user security pretty
>> > well with access levels and encrypted passwords.
>>
>> And lots of baggage if we use a system for multi-user applications...
>
> 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.
>> And security concerns about data leaking from the user's machine...
>>
>> Might I suggest:
>>
>> - use WEBrick on a firewalled port that is accessible only from the
>> local machine 0.0.0.0
>
> I'm planning to use WEBrick server on each user's machine, as well as
> on the database server/development machine/version-control repository.
> Everybody will access their own copy of the web-server at
> localhost:3000. where localhost=127.0.0.1.
>
> Is 0.0.0.0 superior to that, and why?
I used to think 0.0.0.0 was better (somebody told me so, long ago), but
I've just read up on it again and there really doesn't seem to be any
difference. Thus, I would just use "localhost" because it is more human
readable.
>> - use the SQLite3 (http://wiki.rubyonrails.org/rails/pages/SQLite)
>> because it stores data in normal (binary) files on the machine it's
>> running on. For example, if your Rails app is located in /foo/bar, then
>> the DB files will be in /foo/bar/db/
>
> 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.
>> - for concerns about upgrading (i.e. it's easier to update one central
>> server than updating many individual machines), you could have each user
>> check-out your whole rails app from a version control system. Then, when
>> you do maintainance updates to your DB schema and so on, the user would
>> simply update their check-out and run "rails migrate". Done!
>
> (I noted your "rake migrate" correction)
>
> If confused about one thing here. Since the databases and development
> environment are on one machine, shouldn't I:
> - run "rake migrate" only on this machine
> - update the Rails app to relating to the changes in the database
> - update my test suite to test those changes (or write the tests first
> to satisfy some purists)
> - run my entire test suite until all tests pass
> - submit my Rails app to the version control system
> - broadcast a message to all users that the should update their version
> of app by getting the latest and greatest version?
Yes, that is correct.
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.
Good luck.
David Vallner
> - broadcast a message to all users that the should update their version
> of app by getting the latest and greatest version?
>
Mind the "should". It's a bit too late at night for me to try to go over
such scenarios in my head, but there's always users that can't be
bothered (me, on any occasion I can get away with it, for instance), and
you run the risk of someone with a version that's not up-to-date
thrashing the data. Somehow. Just a point to watch out for. Either keep
more stringent checks on the DB-side, or make sure that updates to users
happen automatically, transparently, and preferrably fast - depending on
how controlled your user base is, you might or might not get away with
the app "calling home".
Of course, odds are that's just me being paranoic and that wouldn't
really happen with a proper data model design in the first place.
> 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.
> Then the contoller tells the appropriate view to do its thing with the
> data, namely produce HTML with the data suitable tagged plus embedded
> Ruby and send that amalgam to the web-server. The web-server invokes
> Extended Ruby to process the "enriched" HTML and send the resulting
> vanilla HTML to the browser.
>
> 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. 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. The "hack" around this is having the
browser regularly poll for updates (in a JS loop), and more or less cook
your own event loop using Ajax, as-known-from-GUIs. (Which you do if, in
fact, you expect asynchronous changes rendering someone's view state
obsolete and that is an undesirable thing.) The one problem there is
lag, HTTP has bad performance characteristics for this - otherwise it's
semantically the same you do in GUIs, except you have to implement it
yourself (or look into an Ajax support library for help). So I'd take
frequency of necessary updates and the connection quality into account
too, if you need either more "realtime" behaviour, or you want to
service sluggish connections, you might want to do something against it.
Comet comes to mind if that's the case.
[http://alex.dojotoolkit.org/?p=545]. I'm not sure if Rails /
Prototype.js support that though, so you might end up having to use
Dojo, which Rails didn't have special support for last time I checked.
>> Nothing that's really a showstopper from this point of view, just the
>> request / response / sessions clutter that's not really essential to the
>> way I would model a rich GUI application.
>
> Gotcha. But all the request/response stuff is on a single box, so the
> processing time should be a few milliseconds, don't you think?
>
Yes. It's just clutter from the elegance point of view, not a
performance one.
[Stuff I didn't have anything to add to snipped.]
David Vallner
Richard
> > 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.
> > I'm confused about one thing here. Since the databases and development
> > environment are on one machine, shouldn't I:
> > - run "rake migrate" only on this machine
> > - update the Rails app to relating to the changes in the database
> > - update my test suite to test those changes (or write the tests first
> > to satisfy some purists)
> > - run my entire test suite until all tests pass
> > - submit my Rails app to the version control system
> > - broadcast a message to all users that the should update their version
> > of app by getting the latest and greatest version?
>
> 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
John Wilger
<RichardDummyMailbox58...@USComputerGurus.com> 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 Wilger
http://johnwilger.com
Richard
> > - 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
> /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
David Vallner
> /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 Vallner
Suraj Kurapati
> 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.
Suraj Kurapati
> 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 Wilger
> 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)
Martin DeMello
>
> On Sun, 2006-17-12 at 10:09 +0900, Suraj Kurapati 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
Richard
> > 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.
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
Richard
> > 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.
Good additional ideas.
As I said to Suraj, thanks again for your insightful comments. I
Richard
> [snip] 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)
Good additional ideas!
As I said to Suraj and David, thanks again for your insightful
David Vallner
> 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 Vallner
Joel VanderWerf
> 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.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
John Wilger
> John Wilger wrote:
> > Most likely, I would
> > go with something like Flex[1] for the client, since it's relatively
> 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.
Richard
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
Alex Young
I've been increasingly interested by what's going on in Ruby.NET, for
exactly that reason.
--
Alex
Gregor Kopp
>
> 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