AgentM wrote: > Hi Ed, > > I spent a couple of hours trying Rails and here are my critiques: > > a) Rails forces and enforces a specific database design- objects are > mapped to one table, etc. > -why is the middle-layer defining the database backend? The Rails > object-relational model is overly simplistic (but admittedly "good > enough" for smaller tasks)
Although your criticism here is valid, I found it was more than adequate for most tasks. It does take a bit of getting used to. Also, while you can code outside the conventions, that does detract from the simplicity. One thing I would not do (at my current level of understanding,) is to apply ActiveRecord to a pre-existing legacy DB schema. > -this always blows up when the programmer hits the wall of > battling the framework for database features which Rails doesn't support > -Rails really does prefer MySQL. > Or PostgreSQL or sqlite. I got the impression the first Rails app and some tutorials were based around Postgres. > b) The "scaffolding" feature was neat for about 5 minutes until I > realized that inevitably, I have to replace it with my own template- > still OK for prototyping, I guess. > Yes, I don't use the scaffolding for real stuff I deploy. Once you grok ActiveRecord it is easy enough to do your own thing. > c) The documentation is pretty much an empty wiki with some "tips" > for specific problems and one-liner method descriptions. > I did mention this at the end. The docs really do suck, but get the books, they are essential, IMO. I suspect this will improve over time. The videos and tutorials on the rubyonrails.org website are good enough to get started. Still, I am not sure if Scott would still recommend Rails to his students. Scott, you should check out the level of docs and decide for yourself. When I post my tutorial, there will be a fairly complete list of web sites I have bookmarked for Ruby and Rails info. > Furthermore, I wouldn't use it as an introduction to web programming > for the following reasons: > > a) Rails is new. > -The API and feature-set is still expanding and changing. > I don't believe this is really an impediment to to learning Rails. I think the target is not that fast a moving one. However, early on it might have been. I read that in some really early posts. > b) The documentation is bad. > -This implies plenty of dead-ends for newbies. > Agreed. Hopefully this will change and anything I or Craig can do to help StL RubyNubys out with this don't hesitate to ask. Also, I agree you should have mighty Google-Fu before getting stated on Rails w/o having the book. But given our tech-savvy college kids these days, who doesn't? Get involved with the local Ruby group and join up with the mailing lists. > c) The database "cover" is overly simplistic. > -People have been increasingly excited about hiding SQL under the > covers. All programmers can benefit from learning relational algebra. > But do you really want to just to get a website going? A lot of times, thinking about how to persist your objects gets in the way of actually dealing with the business side of things. A lot of old-timers often have this complaint when it comes to DBs and their various wrappers (ORM, Hibernate, Entity Beans, etc.) But a recent trend is to defer that decision till as late a responsibly possible. Some systems are turning away from RDBMS altogether. Instiki - a Ruby based wiki doesn't use one. Also, my 35 min Rails tutorial (another Wiki) doesn't need one either. Although this is a simplistic example and not one I would employ in a typical e-commerce web site, for example. > d) Ruby hides the details. > -For many, this is a bonus, but nothing was more important for me > to learn than how the script interacts with the web server and how > the data gets to the client. > At first I thought this as well. But then I started getting how it was interacting with the client. The book was a great help and the Rails API web site has "show source" for all methods. I no longer feel this way. > To start someone on the path of learning to program, skip the web > stuff altogether and start with a simple scripting language (Ruby > even) to show how input and output work. Classic example: > > What is your name? John > Hello, John. > Agreed. There is no substitute for learning how to program properly. I am not a typical case, but I learned Ruby by extending my Rails app. But then, a programmer, am I already.. > A web interface requires a different understanding of sessionless I/O. > It does. If you have some prior experience with server side coding ( CGI ) you should pick it up though. So maybe Rails is not the best next step for a fledgling new programmer, but the questions was was it better than PHP, Perl, Python and the rest. I still maintain that it is better than those for the reasons I mentioned. (Proper attention to the correct details. Understanding how to combat security threats. Simplification of the Model layer and correct separation of concerns (MVC).) I still feel that if you take the trouble to create your first real web app with Rails, you will be a lot farther along to writing good stuff in other languages. > In any case, I hope I was able to offer you some insight. > Cheers, > M > Thanks for your input, it was very insightful. Ed -- Ed Howland WDT Solutions, LLC. [EMAIL PROTECTED] (314) 962-0766 _______________________________________________ CWE-LUG mailing list [email protected] http://www.cwelug.org/ http://www.cwelug.org/archives/ http://www.cwelug.org/mailinglist/
