Starting an app from scratch

[Rafael George]

Hi guys, 

I've been studying everything I found regarding OOP and good practices with Rails in particular and with software development in particular. I was wondering how do you guys manage to work on new apps; do you follow the object on rails approach ? Or do you go ahead with the Rails way and then do some refactor? I ask this because lately I'm just searching for small apps to develop and practice some techniques but some times I just got stuck on deciding how to start and how to go along with the entire app. 

I've been going on the service record wrapper treadmill that Gary Benhardr suggests on his sucks-rock series which is quite good after you already have the application build and just want to separate concerns and have a faster specs; imho. But for others application like this one http://symfony.com/legacy/doc/askeet/1_0/en/1 which is the one I'm trying to replicate for education purpose not so good. Just want to know some hints regarding how to bootstrap an app with the good practices or if you guys just go ahead and start it on the Rails way and then refactor?

Thanks in advance for the info.  

[Tim Morton]

Hi Rafael,

When starting from scratch on a production app, my personal philosophy is "just code it" - that is, get some kind of real functionality before worrying about "proper OO design."  I find it too easy to get tied up in knots with design decision before getting something functional.  

Building things "clean from the start" like Avdi does in the OOR book is a great learning exercise.  I think as you get more experienced, even the "just code it" stage will produce better code, because the patterns become things that you reach for naturally.  But most of the time, nothing beats quick feedback, and nothing is better feedback than real working functionality, even if that functionality is just "hello world" on a page.  

- Tim

--
You received this message because you are subscribed to the Google Groups "Objects on Rails" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alexandre de Oliveira]

I disagree that doing OO will make you go slower or deny you from quick feedback, unless you're inexperienced in the matter. At most a few seconds when creating a new class, but that's not enough to say you're going slower.

​

Agree? 

—Alexandre
Sent from my iPhone

[Charles Hoffman]

I think you're misunderstanding Tim. He just means that one can easily get so bogged down in trying to get the "right" or "best" OO design (according to the dominating opinions of the day) from the get-go, and waste a lot of time in the early stages. A good OO design can just as well (better, perhaps) grow/evolve _informed by_ quick feedback but for that you have to start with something.

--
[chuck hoffman]
[sounds, words, and code]
[what else is there?]
[http://hoff2.com]

[Matt Wynne]

Anything you're new to is going to take longer than doing it the way you already know. The question is whether you think it's a valuable use of your time to learn something different.

My experience says that refactoring out of The Rails Way is hard. Better to try to build your domain model isolated from the framework from the beginning.

cheers,

Matt

--
http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com

[Kris Leech]

Charles Hoffman wrote:

I think you're misunderstanding Tim. He just means that one can easily get so bogged down in trying to get the "right" or "best" OO design (according to the dominating opinions of the day) from the get-go, and waste a lot of time in the early stages. A good OO design can just as well (better, perhaps) grow/evolve _informed by_ quick feedback but for that you have to start with something.
  

In my experience this is true. I think it depends on how much freedom you have in terms of time/budget. Have you got the opportunity to experiment? It will cost more (in the short term) than doing it the way you know how, but in the long term it will probably pay dividends if you get it right. Taking a Rails codebase and refactoring in a new technique is difficult (in my experience) mainly due to the high levels of coupling which means its hard to refactor incrementally. Starting with something lightweight like Hexagonal Rails [1] style callbacks is a nice way to remove the need for ActiveRecord callbacks which are often the cause of much coupling which should make refactoring to some other technique later easier, e.g using service objects to orchestrate interactions between objects.

[1] http://www.youtube.com/watch?v=CGN4RFkhH2M

--
[chuck hoffman]
[sounds, words, and code]
[what else is there?]
[http://hoff2.com]

On Jul 4, 2013, at 11:38 AM, Alexandre de Oliveira wrote:

  

I disagree that doing OO will make you go slower or deny you from quick feedback, unless you're inexperienced in the matter. At most a few seconds when creating a new class, but that's not enough to say you're going slower.
Agree? 
�Alexandre
Sent from my iPhone


On Thu, Jul 4, 2013 at 10:34 AM, Tim Morton <t...@timothymorton.com> wrote:

Hi Rafael,

When starting from scratch on a production app, my personal philosophy is "just code it" - that is, get some kind of real functionality before worrying about "proper OO design."  I find it too easy to get tied up in knots with design decision before getting something functional.  

Building things "clean from the start" like Avdi does in the OOR book is a great learning exercise.  I think as you get more experienced, even the "just code it" stage will produce better code, because the patterns become things that you reach for naturally.  But most of the time, nothing beats quick feedback, and nothing is better feedback than real working functionality, even if that functionality is just "hello world" on a page.  

- Tim



On Tue, Jul 2, 2013 at 3:28 PM, Rafael George <george...@gmail.com> wrote:
Hi guys, 

I've been studying everything I found regarding OOP and good practices with Rails in particular and with software development in particular. I was wondering how do you guys manage to work on new apps; do you follow the object on rails approach ? Or do you go ahead with the Rails way and then do some refactor? I ask this because lately I'm just searching for small apps to develop and practice some techniques but some times I just got stuck on deciding how to start and how to go along with the entire app. 

I've been going on the service record wrapper treadmill that Gary Benhardr suggests on his sucks-rock series which is quite good after you already have the application build and just want to separate concerns and have a faster specs; imho. But for others application like this one http://symfony.com/legacy/doc/askeet/1_0/en/1 which is the one I'm trying to replicate for education purpose not so good. Just want to know some hints regarding how to bootstrap an app with the good practices or if you guys just go ahead and start it on the Rails way and then refactor?

Thanks in advance for the info.  

-- 
You received this message because you are subscribed to the Google Groups "Objects on Rails" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 


-- 
You received this message because you are subscribed to the Google Groups "Objects on Rails" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 


-- 
You received this message because you are subscribed to the Google Groups "Objects on Rails" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
    

--
===========================================================
I welcome VSRE emails. Learn more at http://vsre.info
===========================================================

[Daniel Barlow]

On 2 July 2013 20:28, Rafael George <george...@gmail.com> wrote:

Hi guys, 

I've been studying everything I found regarding OOP and good practices with Rails in particular and with software development in particular. I was wondering how do you guys manage to work on new apps; do you follow the object on rails approach ? Or do you go ahead with the Rails way and then do some refactor?

tl;dr : It depends

longer: I make a judgment based on the criteria I "which are the bits that are risky and/or poorly understood" and "what can I do that delivers end-user value".  If it looks like there is going to be complicated domain logic, I'll start there and code something that can run standalone with no Rails dependencies - maybe even just calling it from test cases or from irb.  If I can solve an important-looking problem with CRUD screens (even with scaffolds) I'll start there.  The only difference, I suppose, is that in the latter case I'm far less 'attached' to the code and much more likely to throw it away instead of refactoring it as future requirements come down the pipe.

Fiddling around with a complete deployable "hello world" app^Wspike is sometimes also a really good way of unblocking analysis paralysis or crystallising requirements where it wasn't obvious what they were.


-dan

--
d...@telent.net
http://ww.telent.net

[Arne Brasseur]

My two cents on this.

I came back to Rails last year after being gone for several years. I have always been sceptical of the Rails "convention driven" straight jacket, and all the behind the scenes magic involved, so I did a lot of reading and watching talks (like Objects on Rails, Hexagonal Rails) to find some inspiration on how to do things better/differently.

When I eventually tried to build an app from scratch I spent so much time thinking about these thinks, restructuring, refactoring. Add to that learning about the libraries of the day and comparing their tradeoffs and weeks just flew by and I still didn't have anything to show.

In hindsight it was valuable time cause I was learning and practicing and becoming very thoughtful of how I approached things, but if I got to that position again I would probably try to move faster and worry less about getting it absolutely right the first time.

[Rafael George]

Agree,

I'm trying to follow the hexagonal way of doing things. I watched "Functional Rails", "Suck Rocks", "Build a Rails app with Corey Haines"; just two of them were to build something from scratch, but I did not catch very clearly "That's why I'm watching all over again" from where to start. Also I've been reading and trying to replicate the code from OOR but it's seems there are some stuffs that doesn't work from the examples and that's kinda frustrating.

I'll start to read GOOS as Matt suggest in his talk and will try to replicate this approach on every Rails app I build from now on.

Thanks again for all the responses.

[Rafael George]

Agree,

I'm trying to follow the hexagonal way of doing things. I watched "Functional Rails", "Suck Rocks", "Build a Rails app with Corey Haines"; just two of them were to build something from scratch, but I did not catch very clearly "That's why I'm watching all over again" from where to start. Also I've been reading and trying to replicate the code from OOR but it's seems there are some stuffs that doesn't work from the examples and that's kinda frustrating.

I'll start to read GOOS as Matt suggest in his talk and will try to replicate this approach on every Rails app I build from now on.

Thanks again for all the responses.

On Thursday, July 4, 2013 3:13:11 PM UTC-4, Matt Wynne wrote: