I realize this subject is redundant for this community, but I''m hoping the Rails community can provide me with some additional ammunition to help push a rails project I''m pitching over the proverbial tipping point at my company. The Situation: I''m the lead architect at a large bay area retailer. My team and I are currently suffering through the process of paying for the j2ee (swing/ejb 2.0 apps) sins of a large software vendor and and equally large consulting firm while trying to cope with complex business requirements that come on a daily basis. I ported one small transactional app to Rails as a proof of concept and am now pushing to rewrite one of the larger crud applications. Unfortunately, the proof of concept has proven to not be enough for mgmt, nor has the countless articles and blogs I''ve read, copied, passed on and paraphrased discussing the ability of Rails to scale and handle various web apps. I''m also not surprisingly encountering alot of resistance from our large consulting firm "partners" who don''t have alot of vested interest in seeing our expensive j2ee apps go away anytime soon to be replaced by something simpler and more sensible. I believe Rails is the right solution for us and so do alot of other people here. We''re at the edge of succeeding. Can anyone out there provide me with additional convincing facts, anecdotes or suggestions to help me push Rails through? Thanks very much, matt -- Posted via http://www.ruby-forum.com/.
I have a similar situation but included a fairly crude [but effective] development log on the front page of my prototype that displayed what I did and exactly how long it took [in minutes].. The numbers spoke for themselves. Matthew Carlson wrote:> I realize this subject is redundant for this community, but I''m hoping > the Rails community can provide me with some additional ammunition to > help push a rails project I''m pitching over the proverbial tipping point > at my company. > > The Situation: > I''m the lead architect at a large bay area retailer. My team and I are > currently suffering through the process of paying for the j2ee > (swing/ejb 2.0 apps) sins of a large software vendor and and equally > large consulting firm while trying to cope with complex business > requirements that come on a daily basis. I ported one small > transactional app to Rails as a proof of concept and am now pushing to > rewrite one of the larger crud applications. Unfortunately, the proof > of concept has proven to not be enough for mgmt, nor has the countless > articles and blogs I''ve read, copied, passed on and paraphrased > discussing the ability of Rails to scale and handle various web apps. > I''m also not surprisingly encountering alot of resistance from our large > consulting firm "partners" who don''t have alot of vested interest in > seeing our expensive j2ee apps go away anytime soon to be replaced by > something simpler and more sensible. > > I believe Rails is the right solution for us and so do alot of other > people here. We''re at the edge of succeeding. Can anyone out there > provide me with additional convincing facts, anecdotes or suggestions to > help me push Rails through? > > Thanks very much, > matt > >
John Bresnik wrote:> I have a similar situation but included a fairly crude [but effective] > development log on the front page of my prototype that displayed what I > did and exactly how long it took [in minutes].. The numbers spoke for > themselves.John, can you share some more details about your numbers and the applications you built? How long did it take, how many lines of code, what does the app do, how long did it take in another platform? -- Posted via http://www.ruby-forum.com/.
Yea sorry I didn''t mean to imply that there was a port of an existing application - but I could definitely estimate how long it would''ve taken in our usual architecture [EJB/Struts/etc]. The app is essentially a task manager, i.e. create / assign to both people and milestones / edit tasks /etc for a group of 7 developers [We''re technically supposed to be using ClearQuest but the UI is reminiscent of a 747 cockpit and the web module is up and down like some bipolar lunatic, but.. ]. I started with a somewhat simplistic database [i.e. not very well normalized,etc] - generated the scaffolds and then edited them to get my own look and feel [sorry it''s not available outside the firewall]. My initial operating capability [entering tasks, assigning, viewing, etc] was 120 minutes - this is definitely the number that most people are impressed by, i.e. up and running from scratch [with own look and feel] in a very short amount of time - same task in Struts/EJB/Hibernate would''ve taken at least a week if not two. Actual lines of code are minimal. I edited the layout, the scaffold generation provided the bulk of the controllers and of course I had to specifiy the has_many / belongs_to relationships in my generated models. I also spent 90 minutes experimenting with DTOs [Data Transfer Objects] - DTOs are very common in the EJB world and are essentially lightweight, *view-specific, objects for transferring data from the model to the view and vice versa - rails doesn''t have the concept [as far as I know], you could argue than an ActiveRecord provides all the functionality you need but as you''ll find in larger and larger apps your views won''t always mimic your object model [or models in this case]. Also DTOs are designed with ''going across the wire'' in mind [i.e. marshaling] - which isn''t applicable in rails [yet?!] .. I also spent about 30 minutes putting together the development log itself, which again was generated / edited scaffolds. The last thing I did [it''s still a work in progress] was add a specific view for summary of open tasks as requested by one of the developers [tasks are usually shown by milestone] [also a good example of when to use a DTO since the Task Summary view was a significant subset of my Task ActiveRecord] - that took about 15 minutes, from generated scaffold , DTO class [which ended up being a regular Ruby class declared in the controller where they appear [there''s probably a better way to do that]], and edit to the controller. Overall - I got a running / usuable app [we''re using it now] in under 5 hours. Peter Fredrick wrote:> John Bresnik wrote: > >> I have a similar situation but included a fairly crude [but effective] >> development log on the front page of my prototype that displayed what I >> did and exactly how long it took [in minutes].. The numbers spoke for >> themselves. >> > > > John, can you share some more details about your numbers and the > applications you built? How long did it take, how many lines of code, > what does the app do, how long did it take in another platform? > >
Matthew Carlson
2006-Mar-24 19:24 UTC
[Rails] Re: Re: Is Rails Appropriate for our Project?
John Bresnik wrote:> Yea sorry I didn''t mean to imply that there was a port of an existing > application - but I could definitely estimate how long it would''ve taken > in our usual architecture [EJB/Struts/etc]. The app is essentially a > task manager, i.e. create / assign to both people and milestones / edit > tasks /etc for a group of 7 developers [We''re technically supposed to be > using ClearQuest but the UI is reminiscent of a 747 cockpit and the web > module is up and down like some bipolar lunatic, but.. ]. I started with > a somewhat simplistic database [i.e. not very well normalized,etc] - > generated the scaffolds and then edited them to get my own look and feel > [sorry it''s not available outside the firewall]. My initial operating > capability [entering tasks, assigning, viewing, etc] was 120 minutes - > this is definitely the number that most people are impressed by, i.e. up > and running from scratch [with own look and feel] in a very short amount > of time - same task in Struts/EJB/Hibernate would''ve taken at least a > week if not two......Thanks for the overview John. Outside of productivity numbers, did you find yourself pushed on performance, maintainability, overall talent pool etc? Are your fellow developers on board as well, or are they having a tough time making the mental shift from j2ee? -- Posted via http://www.ruby-forum.com/.
John Bresnik wrote:> Yea sorry I didn''t mean to imply that ... > > Actual lines of code are minimal. I edited the layout, the scaffold > generation provided the bulk of the controllers and of course I had to > specifiy the has_many / belongs_to relationships in my generated models. > I also spent 90 minutes experimenting with DTOs [Data Transfer Objects] > - DTOs are very common in the EJB world and are essentially lightweight, > *view-specific, objects for transferring data from the model to the view > and vice versa - rails doesn''t have the concept [as far as I know], you > could argue than an ActiveRecord provides all the functionality you need > but as you''ll find in larger and larger apps your views won''t always > mimic your object model [or models in this case]. Also DTOs are designed > with ''going across the wire'' in mind [i.e. marshaling] - which isn''t > applicable in rails [yet?!] ...Thanks for sharing your experience and work, John. I am still very new to rails and one of many things I have been pondering upon is the modeling complexity rails can handle. You have an interesting point here with the use of Data Transfer Objects (or Value Objects). Although one of the big wins rails provides is model driven development, it should not prevent modeling like that. In large apps, views request business logic that is way too big to put into model classes. I wonder what the best approaches are. Is "components" directory for this? -- Posted via http://www.ruby-forum.com/.
> > > Thanks for the overview John. Outside of productivity numbers, did you > find yourself pushed on performance, maintainability, overall talent > pool etc? Are your fellow developers on board as well, or are they > having a tough time making the mental shift from j2ee? > >Maintainability is an interesting question and of definite value [in my opinion] - Mostly what I like abt rails is the fact that there is a strict/enforced architecture [that alone will do wonders for maintainability] My big criticism of Struts [1] is that it''s too easy to hack around the architecture [arguably its not the role of Struts to enforce its proper use, i.e. not fault of Struts itself] - hacking around architecture is what leads to poor maintainability [other than not having an architecture in the first place anyway]. It''s definitely been embraced by some of the developers [of course, I''m their boss ;)] - Our shop has been very strict MVC so the shift hasn''t been difficult - as far your average EJB session facade developer though, it really depends on their attitude toward new things. Invariably, ''convention over configuration'' is going to change how we all do business [c.f. EJB 3.0 spec uses Java 1.5 annotations instead of the litany of ''descriptors'' i.e. configuration files [3]].. one interesting note re. that is Cocoon [2] [the very successful apache publishing framework] is now looking to rails for ideas on simplifying itself: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112869422207312&w=2 But yea, transition is moving very smoothly - honestly haven''t seen any [legit] resistance. We''re starting our first large scale app in rails here in the coming months - as far as talent pools, I haven''t had any luck finding rails developers - but have found a couple python developers that are interested. The key is really to look at people''s attitudes, if they like learning new things, they''ll figure it out pretty fast - if not, then find em a cubicle in the basement. [1] http://struts.apache.org/ [2] http://cocoon.apache.org/ [3] http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html
John Bresnik wrote:> The key is really to look at people''s > attitudes, if they like learning new things, they''ll figure it out > pretty fast - if not, then find em a cubicle in the basement.I couldn''t agree with you more, John. I''d rather take a decently good Java programmer who wants to learn Ruby than a genius whiz who doesn''t fully believe in looking beyond java. Peter -- Posted via http://www.ruby-forum.com/.
Jin Zhu wrote:> John Bresnik wrote: >>Actual lines of code are minimal. I edited the layout, the scaffold >>generation provided the bulk of the controllers and of course I had to >>specifiy the has_many / belongs_to relationships in my generated models. >>I also spent 90 minutes experimenting with DTOs [Data Transfer Objects] >>- DTOs are very common in the EJB world and are essentially lightweight, >>*view-specific, objects for transferring data from the model to the view >>and vice versa - rails doesn''t have the concept [as far as I know], you >>could argue than an ActiveRecord provides all the functionality you need >>but as you''ll find in larger and larger apps your views won''t always >>mimic your object model [or models in this case]. Also DTOs are designed >>with ''going across the wire'' in mind [i.e. marshaling] - which isn''t >>applicable in rails [yet?!] ... > > > Thanks for sharing your experience and work, John. > > I am still very new to rails and one of many things I have been > pondering upon is the modeling complexity rails can handle. You have an > interesting point here with the use of Data Transfer Objects (or Value > Objects). Although one of the big wins rails provides is model driven > development, it should not prevent modeling like that. In large apps, > views request business logic that is way too big to put into model > classes. I wonder what the best approaches are. Is "components" > directory for this?What does "business logic that is way too big to put into model classes" mean? I believe a true OOP system should have all objects doing their own work, and, in cases where a business rule depends on multiple models, you create a "collaboration" or "orchestration" model with the collaborators as children. These are somewhat similar to services in the java world, but they only exist to handle collaborations rather than making rote services for every model. That''s one of the things I like about rails... that you say Client.find(:all) rather than ClientService.find(). The former is sending a message to an actor in the domain while the latter, well, isn''t terrible or anything... it just doesn''t seem as direct. b PS: I consider the DTO one of the most overused and thoroughly abused patterns in java...
John Bresnik
2006-Mar-25 09:01 UTC
[Rails] Re: Re: Re: Is Rails Appropriate for our Project?
Ben Munat wrote:> PS: I consider the DTO one of the most overused and thoroughly abused > patterns in java...Definitly the most misunderstood pattern, that''s for sure. DTOs are historically rooted in RMI, CORBA, etc. and usually endup becoming utility objects [c.f. helpers in rails] instead of their original purpose - which is a major abuse of them. The worst abuse I''ve seen [a lot] is making a Base DTO with a 10-15 odd ''common functionalities'' i.e. you marshall/demarshall this mess with every transaction. I like your collaboration idea - but aren''t these models ActiveRecords? if so does it make sense to have an ActiveRecord object that *isn''t backed up by an actual table in a database? -- Posted via http://www.ruby-forum.com/.
John Bresnik wrote:> Ben Munat wrote: >>PS: I consider the DTO one of the most overused and thoroughly abused >>patterns in java... > > Definitly the most misunderstood pattern, that''s for sure. DTOs are > historically rooted in RMI, CORBA, etc. and usually endup becoming > utility objects [c.f. helpers in rails] instead of their original > purpose - which is a major abuse of them. The worst abuse I''ve seen [a > lot] is making a Base DTO with a 10-15 odd ''common functionalities'' i.e. > you marshall/demarshall this mess with every transaction. > > I like your collaboration idea - but aren''t these models ActiveRecords? > if so does it make sense to have an ActiveRecord object that *isn''t > backed up by an actual table in a database? >I say yes! Actually, I''d go further than that and say this: While ActiveRecord is a great, useful tool, it is also a potential anti-pattern. It promotes -- as you just demonstrated -- thinking of your model in terms of db tables. This leads one to think of "groupings of data" instead of object representations of the world. A big chunk of the benefit of OOP is that we are modeling *behavior*, not just grouping properties. This means that there almost certainly must be pure-behavior objects. And actually, I''d argue that that is the ONLY benefit of OOP... encapsulation and polymorphism are just the "how". I''ve previously questioned why we inherit from ActiveRecord rather than mix it in (and I still haven''t gotten a satisfactory answer, I don''t think). This makes sense because persistence is an orthogonal concern. We should have been building our models and just using a (nearly) black box service to persist them a long time ago. b PS: By the way, as you can see, I love discussing the theoretical purity of all this, but as for the feasibility of having non-AR orchestration model classes that handle validation on behalf of collaborators..... um, well, I''m sure it could be done somehow... you can do anything in Ruby, right? :-)
It seems like the h() function is getting called on data that is saved into my database using ActiveRecord. Is there a way to supress this? e.g. If I save "<html>" it gets to the database as "<html>:. Tony
Wilson Bilkovich
2006-Mar-25 20:44 UTC
[Rails] Re: Re: Re: Is Rails Appropriate for our Project?
On 3/25/06, Ben Munat <bent@munat.com> wrote:> John Bresnik wrote: > > Ben Munat wrote: > >>PS: I consider the DTO one of the most overused and thoroughly abused > >>patterns in java... > > > > Definitly the most misunderstood pattern, that''s for sure. DTOs are > > historically rooted in RMI, CORBA, etc. and usually endup becoming > > utility objects [c.f. helpers in rails] instead of their original > > purpose - which is a major abuse of them. The worst abuse I''ve seen [a > > lot] is making a Base DTO with a 10-15 odd ''common functionalities'' i.e. > > you marshall/demarshall this mess with every transaction. > > > > I like your collaboration idea - but aren''t these models ActiveRecords? > > if so does it make sense to have an ActiveRecord object that *isn''t > > backed up by an actual table in a database? > > > > I say yes! > > Actually, I''d go further than that and say this: While ActiveRecord is a great, useful > tool, it is also a potential anti-pattern. It promotes -- as you just demonstrated -- > thinking of your model in terms of db tables. This leads one to think of "groupings of > data" instead of object representations of the world. > > A big chunk of the benefit of OOP is that we are modeling *behavior*, not just grouping > properties. This means that there almost certainly must be pure-behavior objects. And > actually, I''d argue that that is the ONLY benefit of OOP... encapsulation and polymorphism > are just the "how". > > I''ve previously questioned why we inherit from ActiveRecord rather than mix it in (and I > still haven''t gotten a satisfactory answer, I don''t think). This makes sense because > persistence is an orthogonal concern. We should have been building our models and just > using a (nearly) black box service to persist them a long time ago. > > b > > PS: By the way, as you can see, I love discussing the theoretical purity of all this, but > as for the feasibility of having non-AR orchestration model classes that handle validation > on behalf of collaborators..... um, well, I''m sure it could be done somehow... you can do > anything in Ruby, right? :-) >While I of course agree with your description of what OOP is about, it''s also true that relational databases have proven to be very good at what they do. ActiveRecord''s position seems to be that there''s no point hiding/abstracting the fact that you''re going to be talking to a relational DBMS when you know in advance that this is what you''ll be doing. Rails is a pragmatic framework, and if you''re going to be persisting your objects to a relational database 99% of the time, extra layers of unused abstraction just make things more complicated. Are there scenarios that call for a different approach? Yes. Would those approaches work as well as ActiveRecord for the 99% case? Probably not. My experience with object databases has been pretty much uniformly horrible, but maybe that''s just me. Once they are as scalable, usable and installable as Postgres or MySQL, I''ll cast my vote on the side of further abstraction.
Bah! This was my bad. RSS feeds encode the html tags this way. The real question is, has someone written the inverse-of-h() funcion yet? I started to write it, however, I realized that it''s non-trivial because you would need to detect every valid html tag. Since most RSS feeds are html, it could probably disregard XHTML and custom DTDs. Tony On Sat, 25 Mar 2006, Tony Perrie wrote:> It seems like the h() function is getting called on data that is saved into > my database using ActiveRecord. Is there a way to supress this? > > e.g. > > If I save "<html>" it gets to the database as "<html>:. > > Tony >
That, and you infact may not want to reverse everything! What if someone wants to put a > in there feeds somewhere? You cant decode that or else it will get all screwy. On 3/27/06, Tony Perrie <tony@involution.com> wrote:> Bah! This was my bad. RSS feeds encode the html tags this way. The real > question is, has someone written the inverse-of-h() funcion yet? > > I started to write it, however, I realized that it''s non-trivial because > you would need to detect every valid html tag. Since most RSS feeds are > html, it could probably disregard XHTML and custom DTDs. > > Tony > > On Sat, 25 Mar 2006, Tony Perrie wrote: > > > It seems like the h() function is getting called on data that is saved into > > my database using ActiveRecord. Is there a way to supress this? > > > > e.g. > > > > If I save "<html>" it gets to the database as "<html>:. > > > > Tony > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
In RSS 0.91 and 1.0, ''<'' and ''>'' seem to be invalid. In RSS2, they are enclosed in wacky <![CDATA[ .. ] ]> containers. However, it is possible to write this function by only converting valid html ampersand-delimited containers back to <> from <>. Tony On 3/27/06, Nick Stuart <nicholas.stuart@gmail.com> wrote:> > That, and you infact may not want to reverse everything! What if > someone wants to put a > in there feeds somewhere? You cant decode > that or else it will get all screwy. > > On 3/27/06, Tony Perrie <tony@involution.com> wrote: > > Bah! This was my bad. RSS feeds encode the html tags this way. The > real > > question is, has someone written the inverse-of-h() funcion yet? > > > > I started to write it, however, I realized that it''s non-trivial because > > you would need to detect every valid html tag. Since most RSS feeds are > > html, it could probably disregard XHTML and custom DTDs. > > > > Tony > > > > On Sat, 25 Mar 2006, Tony Perrie wrote: > > > > > It seems like the h() function is getting called on data that is saved > into > > > my database using ActiveRecord. Is there a way to supress this? > > > > > > e.g. > > > > > > If I save "<html>" it gets to the database as "<html>:. > > > > > > Tony > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060328/d2e85934/attachment.html