From: Suraj Kurapati Date: 2006-12-18T17:04:03+09:00 Subject: Re: does Ruby generate WINDOWS and dialog boxes? Richard wrote: > Disclaimer: All my assertions about Ruby, Rails, WEBrick and MySQL are > 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. > 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! -- Posted via http://www.ruby-forum.com/.