To create a Ruby on Rails app, does back-end need to occur before front-end?

To create a Ruby on Rails app, does back-end need to occur before
front-end? Or can front-end be completed in HTML/CSS before back-end is
started? OR…must they be worked on concurrently?

Basically, I’m working with a front-end dev, Matt, and a back-end RoR
developer, Sam.

Matt and Sam have never met nor worked with each other. They don’t even
know each other exists. Can my web app project be completed with Matt
completing front-end and sending the completed HTML/CSS templates to Sam
(who would then go on to implement back-end)?

On May 22, 2014, at 10:00 AM, Jordan C. wrote:

(who would then go on to implement back-end)?

This can work, although it’s not optimal. It’s going to put more burden
on Sam to figure out how to pull things apart and put them in the
appropriate partials and templates. It’s also going to assume that Matt
knows all the levels of CRUD and that he needs to provide interfaces for
every possible state that the application might find itself in.

A better way to try this is to let Sam scaffold the whole thing (I mean
that metaphorically, not literally) and show a working prototype to
Matt, who can then decorate that working prototype. If Sam is even
remotely skilled, he will be adding classnames and IDs to things that
need them as he works, and the resulting HTML will be easily decorated
(because there are enough handles to grab on to with CSS).

There may need to be a little back-and-forth after the initial
decoration, say if Matt wants a block to move above another, or to have
an additional level of nesting for some nefarious purpose or another.
But I would imagine that this would be the fastest way to get this done,
rather than trying to cram a designer’s well-intended opinion of how the
application should work into the opinionated structure of a Rails
project.

Of course, if Matt has built or worked on a few Rails projects already,
then this advice may not be appropriate. But given a designer who knows
how things ought to look, and a developer who knows how they have to
work, I think it’s going to be fastest to start with the developer’s
constraints rather than the designer’s wishes.

I say all this as a designer/developer “unicorn”, so I’m not preferring
one over the other arbitrarily.

Walter

Thanks for the advice, Walter. Makes a lot of sense!

Should I get Sam to take a look at the UI PSDs, have him create the
foundation / architecture in RoR for the web app, and from there, he can
request which HTML/CSS snippets and parts are needed? Could that work?

One thing I should’ve also noted is that Matt doesn’t have any knowledge
in Rails or Ruby. He’s strictly a front-end, HTML5/CSS3/Bootstrap guy.
In this respect, I don’t think he’d be able to decorate a working
prototype. He could only ‘supply’ HTML/CSS files, so to speak. Would
that be an issue?

Jordan

Let Matt to do just a frontend and send complete HTML/CSS to Sam.
I’m ROR developer. I have such experience, and i like it, because i know
how better to compose views and partials and i hate when non-ROR
developers
doing non-ROR things in my views :slight_smile:
Just let the ROR developer make html “live”.

Четвер, 22 травня 2014 р. 17:23:27 UTC+3 користувач Ruby-Forum.com User
написав:

Thanks for your opinion, Michael. I would also think that a RoR
developer with HTML/CSS knowledge should be able to pull things apart
from completed HTML/CSS files.

Any other input?

On Thu, May 22, 2014 at 7:00 AM, Jordan C. [email protected]
wrote:

Matt and Sam have never met nor worked with each other. They don’t even
know each other exists. Can my web app project be completed with Matt
completing front-end and sending the completed HTML/CSS templates to Sam
(who would then go on to implement back-end)?

Sounds like classic waterfall development.

Can it be completed? Sure. Will it be as good as if the involved
parties were developing it cooperatively and iteratively? Almost
certainly not.

Why would you want to do this?


Hassan S. ------------------------ [email protected]

twitter: @hassan

I’ve handled projects both ways, If your Front end developer is not
familiar with rails then I would have them create interactive mocks (all
the interactions, etc but with static html) It’s very easy for a
developer to copy over the front end code and make the modifications so
that it works properly with the actual app.

Hassan S. wrote in post #1146832:

On Thu, May 22, 2014 at 7:00 AM, Jordan C. [email protected]
wrote:

Matt and Sam have never met nor worked with each other. They don’t even
know each other exists. Can my web app project be completed with Matt
completing front-end and sending the completed HTML/CSS templates to Sam
(who would then go on to implement back-end)?

Sounds like classic waterfall development.

Can it be completed? Sure. Will it be as good as if the involved
parties were developing it cooperatively and iteratively? Almost
certainly not.

Why would you want to do this?


Hassan S. ------------------------ [email protected]
Hassan Schroeder | about.me
twitter: @hassan

I wouldn’t say it’s completely waterfall development. I think only the
initial phase would be considered waterfall- that is, until version 1 of
the product is complete. From there, we’d continue evolving the product
and reiterating after constant feedback and information from users.

On Fri, May 23, 2014 at 2:25 PM, Jordan C. [email protected]
wrote:

I wouldn’t say it’s completely waterfall development. I think only the
initial phase would be considered waterfall- that is, until version 1 of
the product is complete. From there, we’d continue evolving the product
and reiterating after constant feedback and information from users.

For me, absolutely the best is full collaboration between them, and
whoever is setting requirements, the whole way. Isolation and
specialization is what leads to misunderstandings, incompatibilities,
requires many re-dos and such. Treating the developers as complete black
boxes that have no communication except their outputs is a recipe for a
crappy product, unhappy developers, really unhappy customers, and
probably
your last management gig. (okay, that’s overblown, but you get the
point?)