Re: [rails-oceania] Rails is Not Your Application ...

[ben wiseley]

In a perfect world the business/sales guys are held back from complete
insanity by reason directed by developers.  In the real world this is seldom
the case, especially in larger companies (which is why I've tried very hard
to stick with start-ups).  Abstraction and layers buy you some wiggle room
when biz/sales wants a "small change" at zero hour.  I've found Rails is
almost more trouble than it's worth when dealing with companies that aren't
more development driven.  Rails (strict mvc) is a philosophy that, when not
followed, wages jihad against you in some very annoying ways.  Examples of
this are multiple databases, multiple apps against one database with
different permissions (engines sort of solve this), shared widgets
(partials) initiated by multiple controllers, mixing db/no-sql, etc.  Sure -
this is all possible and we've all done it, but, it's not Rails' strong suit
(although, now that I think of it, it's not really anything's strong suit,
it just sucks).

-ben


On Sun, Oct 23, 2011 at 4:56 PM, Mark Ratjens  wrote:

> "Last year I was involved in my most complex Ruby on Rails application to
> date that is now 23K lines of model code, 14K lines of controller code, and
> 4.5K lines of lib code."
>
> That many lines of code piques my suspicion that there's some pattern
> recognition/refactoring that need to happen. It's also likely that the
> resultant abstractions have nothing to do text book architecture.
>
> Caveat: I haven't seen the code ...
>
>
> On Sun, Oct 23, 2011 at 3:16 PM, Adam Boas  wrote:
>
>> A fairy dies every time a developer speaks the phrase 'Services Layer'.
>> Sometimes it feels like Object Oriented programmers just can't commit to OO
>> design. They constantly want to pull application logic up into services so
>> they can make it more procedural. If no-one has ever killed a fairy in their
>> presence then they stuff it all into the controller, but if someone has
>> spoken that fairy killing phrase in their presence then they righteously go
>> about writing services in roughly the same way they would have written fat
>> controllers and call it good design.
>>
>> It is hard to argue this stuff without concrete examples but in general I
>> don't see why logic not belonging to a persistent model makes it a candidate
>> for a service. I probably have stronger feelings than most about this having
>> done so many years of J2EE and having virtually never experienced the
>> imaginary reuse my services were supposed to have given me. I never even
>> found them to be a valuable abstraction as they constantly promote a
>> procedural approach. Developers just don't seem to believe that the normal
>> rules of cohesion should apply when working on a service.
>>
>> I do think that if every class in your domain is an ActiveRecord class
>> then you probably either have a reasonably trivial problem or a poorly
>> designed domain. By trivial, I don't mean insignificant or not hard but just
>> one that perfecly fits the CRUD paradigm that Rails so elegantly supports.
>>
>> Cheers,
>>
>> Adam
>>
>>
>>
>> On 23/10/2011, at 2:33 PM, Chris Berkhout wrote:
>>
>> My reading of this article:
>>
>> Your application may be more than just DB-backed models and REST-based
>> HTTP controllers.
>> Don't be afraid to introduce additional objects to better model your
>> domain.
>>
>> A services layer sits between your external interfaces (e.g.
>> controllers, and others) and your models. It can reduce duplication of
>> logic among interaces, and support complex interactions involving
>> transactions across multiple models and the coordination of multiple
>> responses.
>>
>> A services layer doesn't belong in /app/models or /app/controllers.
>> You can put in under /lib or even extract it to an external gem (which
>> you configure to access specific models in your application).
>>
>>
>> My response:
>>
>> If your application's only interface is REST controllers and the
>> operations your application provides are simple enough to be
>> encapsulated in individual models, then Rails is your application.
>> Otherwise, do introduce additional structures.
>>
>>
>> I'm interested to hear other's thoughts.
>>
>> Cheers,
>> Chris
>>
>>
>> On Sun, Oct 23, 2011 at 5:33 AM, jamesl  wrote:
>>
>> I found this article insightful and thought others might as well.
>>
>> http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Ruby or Rails Oceania" group.
>>
>> To post to this group, send email to rails-oceania@googlegroups.com.
>>
>> To unsubscribe from this group, send email to
>> rails-oceania+unsubscr...@googlegroups.com.
>>
>> For more options, visit this group at
>> http://groups.google.com/group/rails-oceania?hl=en.
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby or Rails Oceania" group.
>> To post to this group, send email to rails-oceania@googlegroups.com.
>> To

Re: [rails-oceania] Rails is Not Your Application ...

[Mark Ratjens]

"Last year I was involved in my most complex Ruby on Rails application to
date that is now 23K lines of model code, 14K lines of controller code, and
4.5K lines of lib code."

That many lines of code piques my suspicion that there's some pattern
recognition/refactoring that need to happen. It's also likely that the
resultant abstractions have nothing to do text book architecture.

Caveat: I haven't seen the code ...

On Sun, Oct 23, 2011 at 3:16 PM, Adam Boas  wrote:

> A fairy dies every time a developer speaks the phrase 'Services Layer'.
> Sometimes it feels like Object Oriented programmers just can't commit to OO
> design. They constantly want to pull application logic up into services so
> they can make it more procedural. If no-one has ever killed a fairy in their
> presence then they stuff it all into the controller, but if someone has
> spoken that fairy killing phrase in their presence then they righteously go
> about writing services in roughly the same way they would have written fat
> controllers and call it good design.
>
> It is hard to argue this stuff without concrete examples but in general I
> don't see why logic not belonging to a persistent model makes it a candidate
> for a service. I probably have stronger feelings than most about this having
> done so many years of J2EE and having virtually never experienced the
> imaginary reuse my services were supposed to have given me. I never even
> found them to be a valuable abstraction as they constantly promote a
> procedural approach. Developers just don't seem to believe that the normal
> rules of cohesion should apply when working on a service.
>
> I do think that if every class in your domain is an ActiveRecord class then
> you probably either have a reasonably trivial problem or a poorly designed
> domain. By trivial, I don't mean insignificant or not hard but just one that
> perfecly fits the CRUD paradigm that Rails so elegantly supports.
>
> Cheers,
>
> Adam
>
>
>
> On 23/10/2011, at 2:33 PM, Chris Berkhout wrote:
>
> My reading of this article:
>
> Your application may be more than just DB-backed models and REST-based
> HTTP controllers.
> Don't be afraid to introduce additional objects to better model your
> domain.
>
> A services layer sits between your external interfaces (e.g.
> controllers, and others) and your models. It can reduce duplication of
> logic among interaces, and support complex interactions involving
> transactions across multiple models and the coordination of multiple
> responses.
>
> A services layer doesn't belong in /app/models or /app/controllers.
> You can put in under /lib or even extract it to an external gem (which
> you configure to access specific models in your application).
>
>
> My response:
>
> If your application's only interface is REST controllers and the
> operations your application provides are simple enough to be
> encapsulated in individual models, then Rails is your application.
> Otherwise, do introduce additional structures.
>
>
> I'm interested to hear other's thoughts.
>
> Cheers,
> Chris
>
>
> On Sun, Oct 23, 2011 at 5:33 AM, jamesl  wrote:
>
> I found this article insightful and thought others might as well.
>
> http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
>
> To post to this group, send email to rails-oceania@googlegroups.com.
>
> To unsubscribe from this group, send email to
> rails-oceania+unsubscr...@googlegroups.com.
>
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-oceania@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceania+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-oceania@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceania+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to 
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Re: [rails-oceania] Rails is Not Your Application ...

[Adam Boas]

A fairy dies every time a developer speaks the phrase 'Services Layer'. 
Sometimes it feels like Object Oriented programmers just can't commit to OO 
design. They constantly want to pull application logic up into services so they 
can make it more procedural. If no-one has ever killed a fairy in their 
presence then they stuff it all into the controller, but if someone has spoken 
that fairy killing phrase in their presence then they righteously go about 
writing services in roughly the same way they would have written fat 
controllers and call it good design.

It is hard to argue this stuff without concrete examples but in general I don't 
see why logic not belonging to a persistent model makes it a candidate for a 
service. I probably have stronger feelings than most about this having done so 
many years of J2EE and having virtually never experienced the imaginary reuse 
my services were supposed to have given me. I never even found them to be a 
valuable abstraction as they constantly promote a procedural approach. 
Developers just don't seem to believe that the normal rules of cohesion should 
apply when working on a service.

I do think that if every class in your domain is an ActiveRecord class then you 
probably either have a reasonably trivial problem or a poorly designed domain. 
By trivial, I don't mean insignificant or not hard but just one that perfecly 
fits the CRUD paradigm that Rails so elegantly supports.

Cheers,

Adam


On 23/10/2011, at 2:33 PM, Chris Berkhout wrote:

> My reading of this article:
> 
> Your application may be more than just DB-backed models and REST-based
> HTTP controllers.
> Don't be afraid to introduce additional objects to better model your domain.
> 
> A services layer sits between your external interfaces (e.g.
> controllers, and others) and your models. It can reduce duplication of
> logic among interaces, and support complex interactions involving
> transactions across multiple models and the coordination of multiple
> responses.
> 
> A services layer doesn't belong in /app/models or /app/controllers.
> You can put in under /lib or even extract it to an external gem (which
> you configure to access specific models in your application).
> 
> 
> My response:
> 
> If your application's only interface is REST controllers and the
> operations your application provides are simple enough to be
> encapsulated in individual models, then Rails is your application.
> Otherwise, do introduce additional structures.
> 
> 
> I'm interested to hear other's thoughts.
> 
> Cheers,
> Chris
> 
> 
> On Sun, Oct 23, 2011 at 5:33 AM, jamesl  wrote:
>> I found this article insightful and thought others might as well.
>> http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby or Rails Oceania" group.
>> To post to this group, send email to rails-oceania@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> rails-oceania+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/rails-oceania?hl=en.
>> 
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-oceania@googlegroups.com.
> To unsubscribe from this group, send email to 
> rails-oceania+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rails-oceania?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to 
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Re: [rails-oceania] Rails is Not Your Application ...

[Gregory McIntyre]

I put non-ORM classes - or "services layer" classes - in app/models,
not lib. To me, lib seems like the place to put library (i.e. generic,
or not application specific) Ruby files that don't happen to be
packaged as gems. To me, the directory 'app' implies 'application
specific'. In the example linked, pay roll models seem very
application specific so if it were me, I'd put them inside the app
directory somewhere.

Am I wrong? What is the best practice with regards to app/models versus lib?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to 
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Re: [rails-oceania] Rails is Not Your Application ...

[Chris Berkhout]

My reading of this article:

Your application may be more than just DB-backed models and REST-based
HTTP controllers.
Don't be afraid to introduce additional objects to better model your domain.

A services layer sits between your external interfaces (e.g.
controllers, and others) and your models. It can reduce duplication of
logic among interaces, and support complex interactions involving
transactions across multiple models and the coordination of multiple
responses.

A services layer doesn't belong in /app/models or /app/controllers.
You can put in under /lib or even extract it to an external gem (which
you configure to access specific models in your application).


My response:

If your application's only interface is REST controllers and the
operations your application provides are simple enough to be
encapsulated in individual models, then Rails is your application.
Otherwise, do introduce additional structures.


I'm interested to hear other's thoughts.

Cheers,
Chris


On Sun, Oct 23, 2011 at 5:33 AM, jamesl  wrote:
> I found this article insightful and thought others might as well.
> http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-oceania@googlegroups.com.
> To unsubscribe from this group, send email to 
> rails-oceania+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rails-oceania?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to 
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

[rails-oceania] Rails is Not Your Application ...

[jamesl]

I found this article insightful and thought others might as well.
http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to 
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Re: [rails-oceania] Digest for rails-oceania@googlegroups.com - 3 Messages in 1 Topic

[Ben Turner]

Might have posted my question in haste without checking the location of the
hackathon. As a Melbourne developer I might struggle to join you after all!
Thanks for the replies though, hope it's a good one.

Cheers,
Ben
On Oct 22, 2011 9:51 PM,  wrote:

>   Today's Topic Summary
>
> Group: http://groups.google.com/group/rails-oceania/topics
>
>- Hack Night: Wed 26th Oct <#1332b41d2d0c8fce_group_thread_0> [3
>Updates]
>
>   Hack Night: Wed 26th 
> Oct
>
>Ben Turner  Oct 21 04:40AM -0700
>
>Hi Josh / All,
>
>This looks like an awesome idea, similar to a few code kata / TDD
>sessions I've done in Java before.
>
>Not 100% if I'm free that night just yet, but was a bit unsure anyway
>about attendance as my ruby is, well, sketchy at best (mainly learnt
>in fragments through rails hacking). So worried my pair-sessions might
>become my "learning some basic points of Ruby" sessions, which might
>detract from what my partner is there for!
>
>So is this something ideally targeting at quite experienced developers
>only ? Or are they open to all abilities ?
>
>Regards,
>Ben
>
>
>
>
>
>"freshto...@gmail.com"  Oct 21 10:57PM +1100
>
>Hi Ben,
>
>This is not an experts-only event! All levels of experience and ability
>are
>welcome, and it's also language agnostic. Granted, most of the people
>there
>will be Ruby/Javascript/CoffeeScript web developers, but don't let that
>put
>you off :)
>
>Don't worry too much about whether or not you're able to attend - put
>your
>name on the list anyway - if you can't make it at the last minute there
>will
>be someone waiting to fill the spot so it won't be like a space is
>wasted or
>anything.
>
>And most of all, come to meet some members of the Sydney developer
>community
>and have fun!
>
>Regards,
>
>Jame.
>
>
>--
>James
>
>
>
>
>Josh Price  Oct 21 11:05PM +1100
>
>Hi Ben,
>
>I probably should have mentioned that the new format is perfectly
>suited for beginners. Since we swap pairs around fairly quickly you'll get 
> a
>chance to learn from a couple more experienced rubyists.
>
>So if you can make it, please do come along.
>
>Hope to see you there!
>
>Cheers,
>Josh
>
>
>
>
>
>  You received this message because you are subscribed to the Google Group
> rails-oceania.
> You can post via email .
> To unsubscribe from this group, 
> sendan empty message.
> For more options, 
> visitthis group.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-oceania@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceania+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to 
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.