Rails - Sep 2007 - How do you design your RoR web applications?

Here is my question: how do you design your RoR web application?

 - Do you use an OOAD approach? data model/ class diagram, use cases?
 - Do you desing your web pages first?
 - Do you start coding without desinging first?
 - Do you use other tools such as Dreamweaver to create your pages, and
from there convert them in rhtml code?
 - Do you use any quality assurance and quality control process?
 - Which other practical tips would you share that facilitate working
with RoR?

Regards
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi

I can''t speak for anybody else, but this is how I do it.

Design the model that reflects the requirements - generate either DDL or a
migration file, create database tables.

Generate the app and the scaffold.

Populate the development database with test data, check CRUD functionality and
connections.

Create view(s) - .rhtml from the scaffold pages in the view directory - test to
ensure functionality

Replace the scaffold created actions with actions that suit the job better.
These iterative cycles are moved around depending upon customer requirements and
what makes sense at the time.

In the main, I use either VI (for small applications) or Komodo/Aptana for
larger ones. rhtml files are just normal html with some ruby code embedded, much
like PHP/ASP/JSP/Perl generate templates.

Quality assurance and control is created by using the built in testing framework
that is generated by the Generators - these tests can be made to suit the
application.

The only other tips that I can give are get hold of Agile Web Development with
Rails (2nd ed) by The Pragmatic Programmers, try it out for yourself and have
fun.

The book goes through a fairly comprehensive example that you can easily
complete in a day, with the rest of the book going into a great amount of detail
on all the features of the framework, including migrations, AJAX helper and form
helpers, it is an indispensable reference for this development platform.

HTH

Clive
---- Jose Pepe
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> 
> Here is my question: how do you design your RoR web application?
> 
>  - Do you use an OOAD approach? data model/ class diagram, use cases?
>  - Do you desing your web pages first?
>  - Do you start coding without desinging first?
>  - Do you use other tools such as Dreamweaver to create your pages, and
> from there convert them in rhtml code?
>  - Do you use any quality assurance and quality control process?
>  - Which other practical tips would you share that facilitate working
> with RoR?
> 
> Regards
> -- 
> Posted via http://www.ruby-forum.com/.
> 
> > 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 9/18/07, Jose Pepe
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Here is my question: how do you design your RoR web application?
>
>  - Do you use an OOAD approach? data model/ class diagram, use cases?
>  - Do you desing your web pages first?
>  - Do you start coding without desinging first?
>  - Do you use other tools such as Dreamweaver to create your pages, and
> from there convert them in rhtml code?
>  - Do you use any quality assurance and quality control process?
>  - Which other practical tips would you share that facilitate working
> with RoR?
Here are two articles that are very interesting:

http://martinfowler.com/articles/designDead.html
http://wiki.pragmatus.com/index.php?title=Test_Driven_Development_with_Ruby

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> Here is my question: how do you design your RoR web application?
>
Someone asked: "how do you design your RoR web application?"


To be honest, there''s no right or wrong way to create a new app. Some
people starts from DB tables, some starts with html, and others starts
with user cases. Whatever works for you is the best way. Here are some
pointers.

===Coding

    * keep your design modular. If things can be broken into small
pieces, do so. make them into plugin, gems. because doing so those
building blocks can be reused later. if everything is big and chunky,
less likely they''ll be reused.
    * tests is the other half of the code, code without test is not
complete. you should always write code with test code side by side.
Some people even advocate write test first.


If you just keep in mind of 2 principles above, you''ll be doing very
ok.

===Development lifecycle - Iterative
Break big apps into iterations, each iteration with requirements from
most critical down to nice to have. People call this agile
development. In my example, my final goal for groups.wuyaSea.com is to
create a full featured social network site. First release only have
most essential features, user can discuss in forum, and write
articles, and make friends. that''s it. No search (outsourced to google
search), no photo sharing, no private messaging, not even tagging (now
does). With capistrano, it''s easy to keeps on pushing out releases, I
often push out new builds like 5 times a day.

Major reasons for doing iteration is to minimize risk, cuz bean
counters like that.

    * each release requires shorter timeline, less coding effort, and
more predictable in time and money.
    * after you give each release to user acceptance testing, you''ll
find out what features users use most of time, and what features users
rarely touch. It''s known that in any app, 20% of code does 80% of
work, so why write 80% of code nobody uses? In my case, the web is my
user acceptance test.
    * so release early, release often. In venture capital world, it''s
called startup fast, fail fast. Think your startup will be the next
facebook or youtube? think again, for every successful startup,
there''re dozens failed ones you never heard of, so why waste 1 year to
learn the truth if you can do it in 3 months?
    * one side effect by releasing early is you get to earn that
fabulous adsense dollars right away (although i haven''t earned a dime
yet). Cash flow is always important for anyone who bootstraps.

Maximize your effort. User requirement changes, site traffic changes,
life sucks, blah blah. there''s no one design that satisfy all the
requirements. Changes are unavoidable, eventually rewrite may be the
best solution. The best design is one that satisfy the most
requirements with least cost, don''t over engineer something.

===Failing is learning
I can tell you what i''ve done. When I was creating groups.wuyaSea.com,
i went through 2 prototypes, after a few months, each one becomes too
rigid and unmaintainable, then throw it away, and start over. Current
site is my 3rd implementation. Making webapp is like doing everything
else in life, you learn by just doing it. keep cranking, if it fails,
keep trying again.

hope that helps.


copy of this is also available at
http://groups.wuyasea.com/b1ogs/8/articles/9/how-do-you-design-your-ror-web-application

Person who asked this question may also like
http://groups.wuyasea.com/group/ruby-on-rails

Dorren
Dorren_was_here_cuz_goog_keeps_losing_my_favorites


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi ALL, thanks for posting the tips and I''m sure that others will be
able to
benefit from the information.

-Conrad

On 9/18/07, Dorren <dorrenchen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
>
> > Here is my question: how do you design your RoR web application?
> >
> Someone asked: "how do you design your RoR web application?"
>
>
> To be honest, there''s no right or wrong way to create a new app.
Some
> people starts from DB tables, some starts with html, and others starts
> with user cases. Whatever works for you is the best way. Here are some
> pointers.
>
> ===Coding
>
>     * keep your design modular. If things can be broken into small
> pieces, do so. make them into plugin, gems. because doing so those
> building blocks can be reused later. if everything is big and chunky,
> less likely they''ll be reused.
>     * tests is the other half of the code, code without test is not
> complete. you should always write code with test code side by side.
> Some people even advocate write test first.
>
>
> If you just keep in mind of 2 principles above, you''ll be doing
very
> ok.
>
> ===Development lifecycle - Iterative
> Break big apps into iterations, each iteration with requirements from
> most critical down to nice to have. People call this agile
> development. In my example, my final goal for groups.wuyaSea.com is to
> create a full featured social network site. First release only have
> most essential features, user can discuss in forum, and write
> articles, and make friends. that''s it. No search (outsourced to
google
> search), no photo sharing, no private messaging, not even tagging (now
> does). With capistrano, it''s easy to keeps on pushing out
releases, I
> often push out new builds like 5 times a day.
>
> Major reasons for doing iteration is to minimize risk, cuz bean
> counters like that.
>
>     * each release requires shorter timeline, less coding effort, and
> more predictable in time and money.
>     * after you give each release to user acceptance testing,
you''ll
> find out what features users use most of time, and what features users
> rarely touch. It''s known that in any app, 20% of code does 80% of
> work, so why write 80% of code nobody uses? In my case, the web is my
> user acceptance test.
>     * so release early, release often. In venture capital world,
it''s
> called startup fast, fail fast. Think your startup will be the next
> facebook or youtube? think again, for every successful startup,
> there''re dozens failed ones you never heard of, so why waste 1
year to
> learn the truth if you can do it in 3 months?
>     * one side effect by releasing early is you get to earn that
> fabulous adsense dollars right away (although i haven''t earned a
dime
> yet). Cash flow is always important for anyone who bootstraps.
>
> Maximize your effort. User requirement changes, site traffic changes,
> life sucks, blah blah. there''s no one design that satisfy all the
> requirements. Changes are unavoidable, eventually rewrite may be the
> best solution. The best design is one that satisfy the most
> requirements with least cost, don''t over engineer something.
>
> ===Failing is learning
> I can tell you what i''ve done. When I was creating
groups.wuyaSea.com,
> i went through 2 prototypes, after a few months, each one becomes too
> rigid and unmaintainable, then throw it away, and start over. Current
> site is my 3rd implementation. Making webapp is like doing everything
> else in life, you learn by just doing it. keep cranking, if it fails,
> keep trying again.
>
> hope that helps.
>
>
> copy of this is also available at
>
>
http://groups.wuyasea.com/b1ogs/8/articles/9/how-do-you-design-your-ror-web-application
>
> Person who asked this question may also like
> http://groups.wuyasea.com/group/ruby-on-rails
>
> Dorren
> Dorren_was_here_cuz_goog_keeps_losing_my_favorites
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Excellent comments Dorren, you are applying the agile life cycle based 
on iteractions.


-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jose Pepe wrote:
> Here is my question: how do you design your RoR web application?
The best way to design is concurrent with delivering features. We
start by asking our customers (in our specific case the marketing
department) what the most important features are. We implement these
quickly, using unit tests to avoid debugging.

That''s a big step towards a good design, because making code testable
invariably decouples it and improves its design.
>  - Do you use an OOAD approach? data model/ class diagram, use cases?
No, because we can go from simple to complex incrementally, in between
delivering features.
>  - Do you desing your web pages first?
No, because if we start with business user stories, we must implement
a little of a web page, implement a little code, and deploy, in small
cycles. So the web pages grow features incrementally.
>  - Do you start coding without desinging first?
Abso-freakin-lutely.
>  - Do you use other tools such as Dreamweaver to create your pages, and
> from there convert them in rhtml code?
Our graphics department does that. The important part, for
programmers, is the interactive features, and there are only so many
of those.
>  - Do you use any quality assurance and quality control process?
We use the unit tests to gate every commit, and we commit every 10 or
15 minutes or so to Subversion. If the tests don''t pass, we
don''t
commit.
>  - Which other practical tips would you share that facilitate working
> with RoR?
We also use pair programming, including dual keyboards and such. We
are "allowed" to solo, but the more important the feature, the more
likely we are to pair.

The less important the feature, the less likely we are to do it!

--
  Phlip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip,

I do not understand  how do you manage unit tests to avoid debugging 
when you say "We implement these <features > quickly, using unit
tests
to avoid debugging".

could you please explain how do you write code testable? do you first 
create the tests and then code?

thanks





 wrote:
> Jose Pepe wrote:
> 
>> Here is my question: how do you design your RoR web application?
> 
> The best way to design is concurrent with delivering features. We
> start by asking our customers (in our specific case the marketing
> department) what the most important features are. We implement these
> quickly, using unit tests to avoid debugging.
> 
> That''s a big step towards a good design, because making code
testable
> invariably decouples it and improves its design.
> 
>>  - Do you use an OOAD approach? data model/ class diagram, use cases?
> 
> No, because we can go from simple to complex incrementally, in between
> delivering features.
> 
>>  - Do you desing your web pages first?
> 
> No, because if we start with business user stories, we must implement
> a little of a web page, implement a little code, and deploy, in small
> cycles. So the web pages grow features incrementally.
> 
>>  - Do you start coding without desinging first?
> 
> Abso-freakin-lutely.
> 
>>  - Do you use other tools such as Dreamweaver to create your pages, and
>> from there convert them in rhtml code?
> 
> Our graphics department does that. The important part, for
> programmers, is the interactive features, and there are only so many
> of those.
> 
>>  - Do you use any quality assurance and quality control process?
> 
> We use the unit tests to gate every commit, and we commit every 10 or
> 15 minutes or so to Subversion. If the tests don''t pass, we
don''t
> commit.
> 
>>  - Which other practical tips would you share that facilitate working
>> with RoR?
> 
> We also use pair programming, including dual keyboards and such. We
> are "allowed" to solo, but the more important the feature, the
more
> likely we are to pair.
> 
> The less important the feature, the less likely we are to do it!
> 
> --
>   Phlip
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---