Hello there, I am basically a J2EE refugee fascinated with Rails. I have been using the Spring framework (a lightweight J2EE java framework with some special characteristics) but I am so impressed with RoR that I am porting over many applications. In order to "dive into Rails", of course the second thing to do was get myself an IDE, and since I''ve been using Eclipse for the past two years or so, well, RadRails <radrails.org> was a natural. I have found this great environment to make a great Ruby on Rails even greater and more appealing. Following the old, (somewhat unfair, to teachers, anyway) adage "them that know, do; ... the others, teach", I have documented my diving into Rails, and RadRails in an instiki Wiki on Site5, my hosting provider. I said the second thing to do was get myself an IDE. The first thing I did was to get myself a Bible! of course. So I dutifully purchased the PDF version of AWDWR<pragmaticprogrammer.com/titles/rails/index.html>and got cracking. I have documented (with graphics) everything I have been doing since, in the form of an illustrated tutorial of going through the Demo and the Depot apps from the AWDWR <pragmaticprogrammer.com/titles/rails/index.html>book, but with two extensions. The first, given my CMMI and RUP background, was to embellish a few of the tutorial sections (and parts of the resulting wiki) with rather a lot to say about ***Object Oriented Process<wiki.awebfactory.com.ar/awebfactory/published/ObjectOrientedProcess> *, which I believe is joined at the hip to Rails, given that it is a patterns oriented (MVC, and others too) framework. I do chide AWDWR<pragmaticprogrammer.com/titles/rails/index.html>a bit for its downplaying of process (Agile or otherwise), although I want to make it clear that I think it''s a wonderful Bible, and I do understand that it has to stick to the subject of Rails and the code, and present it in a pedagogic manner. The second "extension" to the book is that I try to show how to use the various aspects of RadRails <radrails.org> functionality (I illustrate this with graphics) as one works with a Rails project. I have peppered the examples with just a tad of UML diagrams to see things more clearly also. I am writing this mail In the hopes that all this may be of use or of interest to some folks. If so, here are the links: Starting from the top ( wiki.awebfactory.com.ar/awebfactory/published/RadRailsTutorials ): I. Installation of RadRails through Eclipse Update ( wiki.awebfactory.com.ar/awebfactory/published/InstallRadRails ) II. 3-part tutorial on the initial "demo" app from the book: ** - Demo app: *DemoAppPart1<wiki.awebfactory.com.ar/awebfactory/published/DemoAppPart1> * ("Hello, Rails!") wiki.awebfactory.com.ar/awebfactory/published/DemoAppPart1 - Demo app: *DemoAppPart2<wiki.awebfactory.com.ar/awebfactory/published/DemoAppPart2> * (SVN repository, commit changes) wiki.awebfactory.com.ar/awebfactory/published/DemoAppPart2 - Demo app: * DemoAppPart3<wiki.awebfactory.com.ar/awebfactory/published/DemoAppPart3> * (further develop and polish off demo) wiki.awebfactory.com.ar/awebfactory/published/DemoAppPart3 III. Then comes my own ranty *Thorough critique of Chapter 5<wiki.awebfactory.com.ar/awebfactory/published/Thorough+critique+of+Chapter+5> *wiki.awebfactory.com.ar/awebfactory/published/Thorough+critique+of+Chapter+5 IV. An approach to redressing some problems I found in this excellent book, in terms of *** Object Oriented Process<wiki.awebfactory.com.ar/awebfactory/published/ObjectOrientedProcess> * in which I attempt to present a ***DepotAppProcess<wiki.awebfactory.com.ar/awebfactory/published/DepotAppProcess> * ( wiki.awebfactory.com.ar/awebfactory/published/DepotAppProcess ). Of course, the book must perforce stick very closely to Rails itself, but I just felt it was overdoing the "DRY" philosophy a tad. V. An unfinished section (not started yet, actually) on hooking up this process to the actual depot app implementation as shown in the book (will be *** FittingDepotStoryboardsWithRails<wiki.awebfactory.com.ar/awebfactory/published/FittingDepotStoryboardsWithRails> * It may not be entirely apparent to many why parts III-V need to exist, but the thing is I feel that you can''t waltz into an MVC framework like Rails without ObjectOrientedProcess, I think the two things are joined at the hip, otherwise you just won''t have any idea of how to actually make use of any of this yourselves on your own projects. This is, of course, just my opinion. VI. What many are looking for, the actual nitty gritty of using many facets of RadRails with the Depot App itself, as developed in the book: *** Depot App With Rad Rails<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRails>( wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRails )* I have already finished a considerable portion of the book, out of 17 "iteratons", I have 11 tutorials, on which I really would like to get some feedback, including info on any errors I may have made, parts which are not clear, etc. Here is the table of contents of this part: Setup - *Depot App With Rad Rails Setup<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsSetup> * Chapter 6: Task A: Product Maintenance - 6.1 *Depot App With Rad Rails Iteration A1<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationA1> *: Get Something Running - 6.2 *Depot App With Rad Rails Iteration A2<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationA2> *: Add a Missing Column - 6.3 *Depot App With Rad Rails Iteration A3<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationA3> *: Validate! - 6.4 * Depot App With Rad Rails Iteration A4<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationA4> *: Prettier Listings Chapter 7: Task B: Catalog Display - 7.1 *Depot App With Rad Rails Iteration B1<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationB1> *: Create the Catalog Listing - 7.2 *Depot App With Rad Rails Iteration B2<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationB2> *: Add Page Decorations Chapter 8: Task C: Cart Creation - 8.1 Sessions - 8.2 More Tables, More Models - 8.3 *Depot App With Rad Rails Iteration C1 <wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationC1> *: Creating a Cart - 8.4 *Depot App With Rad Rails Iteration C2<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationC2> * : Handling Errors - 8.5 *Depot App With Rad Rails Iteration C3<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationC3> *: Finishing the Cart UML Chapter 9: Task D: Checkout! - 9.1 *Depot App With Rad Rails Iteration D1<wiki.awebfactory.com.ar/awebfactory/published/DepotAppWithRadRailsIterationD1> *: Capturing an Order ERD UML - 9.2 *Depot App With Rad Rails Iteration D2*: Show Cart Contents on Checkout (not done yet; coming real soon!). True to my character, I add a bit of UML in the last two parts! I am planning on doing another tutorial based somewhat on a project I will be doing this week. Wanted to get some feedback on these first. Cheers! Victor Kane awebfactory.com.ar -------------- next part -------------- An HTML attachment was scrubbed... URL: wrath.rubyonrails.org/pipermail/rails/attachments/20060315/580df12b/attachment.html
On 3/15/06, Victor Kane <victorkane@gmail.com> wrote:> Hello there, > The first, given my CMMI and RUP background, was to embellish a few of the > tutorial sections (and parts of the resulting wiki) with rather a lot to say > about Object Oriented Process, which I believe is joined at the hip to > Rails, given that it is a patterns oriented (MVC, and others too) framework.Speaking as someone who imbibes the OO kool-aid, who sometiems dreams in objects, and has participated in more than my fair share of heavyweight architecture-first design processes... there''s something wrong with the phrase "Object Oriented Process". Those terms do not belong together. Every project needs a process, however agile or heavyweight. And many projects benefit from Object-Oriented Design (we wouldn''t be using Ruby if we didn''t think so). But OO is just a tool in your development process. It is not the process. "Object Oriented Process" suggests an inflexible and ideological development philosophy in which the tools drive the architecture, rather than vice-versa. I find that troubling. Also, I have a little experience with CMMI and similar management fads*AHEM* methodologies, and I can pretty confidently say that they have nothing to do with OO. They require you to document your tools and techniques and learn from your mistakes; but they don''t specify what those tools and techniques should be. Just my $0.02. ~Avdi
You make quite a few good points, undeniably. Still, I stand by the term Object Oriente Process, since I am talking about object oriented software engineering, not OOD or OOP; it''s a paradigm shift with respect to the process itself, with respect to class discovery in component reuse within the process, and the whole question of per project process instantiation itself. So as a result, it has deep meaning for me, which I may or may not be successful in communicating to others. Rails, for example, is apparently born of such a paradigm in the context of process. Victor On 3/15/06, Avdi Grimm <avdi.grimm@gmail.com> wrote:> > On 3/15/06, Victor Kane <victorkane@gmail.com> wrote: > > Hello there, > > The first, given my CMMI and RUP background, was to embellish a few of > the > > tutorial sections (and parts of the resulting wiki) with rather a lot to > say > > about Object Oriented Process, which I believe is joined at the hip to > > Rails, given that it is a patterns oriented (MVC, and others too) > framework. > > Speaking as someone who imbibes the OO kool-aid, who sometiems dreams > in objects, and has participated in more than my fair share of > heavyweight architecture-first design processes... there''s something > wrong with the phrase "Object Oriented Process". Those terms do not > belong together. Every project needs a process, however agile or > heavyweight. And many projects benefit from Object-Oriented Design > (we wouldn''t be using Ruby if we didn''t think so). But OO is just a > tool in your development process. It is not the process. "Object > Oriented Process" suggests an inflexible and ideological development > philosophy in which the tools drive the architecture, rather than > vice-versa. I find that troubling. > > Also, I have a little experience with CMMI and similar management > fads*AHEM* methodologies, and I can pretty confidently say that they > have nothing to do with OO. They require you to document your tools > and techniques and learn from your mistakes; but they don''t specify > what those tools and techniques should be. > > Just my $0.02. > > ~Avdi > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: wrath.rubyonrails.org/pipermail/rails/attachments/20060315/990f986f/attachment.html
On 3/16/06, Victor Kane <victorkane@gmail.com> wrote:> Hello there,Hey, nice write-up Victor. Thanks. Although i''m using textmate but i like your UML and explanation. -- Dawn Taylor dawntayl (at) gmail (dot) com
Christophe Christophe
2006-Mar-23 11:57 UTC
[Rails] Re: New RadRails tutorial using AWDWR book
Victor Kane wrote:> Hello there, > > I am basically a J2EE refugee fascinated with Rails. > > I have been using the Spring framework (a lightweight J2EE java > framework > with some special characteristics) but I am so impressed with RoR that I > am > porting over many applications. >Hello Victor, I''m basically a PHP refugee (yuck !) definitely wanting to use ROR as a PHP replacement and looking for a Java counterpart... What do you mean by "lightweight" ? I''ve investigated several Java frameworks before putting my hands (happily) in RoR : struts, jsf, webwork (this one was the least worst) and I would appreciate your advice about Spring compared to RoR. May be little off topic but... -- Posted via ruby-forum.com.