Hi Railsers, How do you design your applications? Do you start coding HTML? Start with the controllers/models? Start in a program like photoshop/gimp/illustrator/inkscape? I start in inkscape, it''s a SVG editor. I sketch all the views of my application, and then I create the views that belong to one controller in RHTML. After that, I do the models/controller, and move on to the next set of views. How do you do create your applications? Jules -- Posted via http://www.ruby-forum.com/.
On 14.1.2006, at 14.53, Jules Jacobs wrote:> Hi Railsers, > > How do you design your applications? Do you start coding HTML? Start > with the controllers/models? Start in a program like > photoshop/gimp/illustrator/inkscape? > > I start in inkscape, it''s a SVG editor. I sketch all the views of my > application, and then I create the views that belong to one controller > in RHTML. After that, I do the models/controller, and move on to the > next set of views.Hey Jules, That''s a perfectly valid order and promoted by 37signals, too. Maybe put writing the tests after your views are ready and you''ll be ?bercool, doing both test driven [1] and sketch first [2] development ;-) //jarkko [1] http://www.43things.com/things/view/7384 [2] http://www.43things.com/things/view/35612 -- Jarkko Laine http://jlaine.net http://odesign.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060114/3096057e/smime.bin
On Sat, Jan 14, 2006 at 01:53:05PM +0100, Jules Jacobs wrote: } Hi Railsers, } } How do you design your applications? Do you start coding HTML? Start } with the controllers/models? Start in a program like } photoshop/gimp/illustrator/inkscape? } } I start in inkscape, it''s a SVG editor. I sketch all the views of my } application, and then I create the views that belong to one controller } in RHTML. After that, I do the models/controller, and move on to the } next set of views. } } How do you do create your applications? I design the database first, sometimes with an ER diagram and sometimes with straight SQL DDL. I''m a firm believer in getting the data model right (or very close to right) before coding on top of it. I''m also a firm believer in using the right tool for the job, so I make a point of using the database schema for what RDBMSs do best (i.e. data integrity such as foreign key constraints). I''ll generally set up a separate rails test app with just scaffolding to test and play with the schema. Once I''m moderately confident of my schema, I use rails to create the models. I don''t use the scaffolding for a real app, since I find that it''s pretty pointless to have one controller per model and with some regularity there is a need for a controller or two that has nothing to do with a single model. I''ll use rails to generate my controllers, then add stub action methods by hand. (This assumes that I''ve already figured out roughly what operations, a.k.a. controller actions, the user will need.) I then start adding business logic to the model classes. If I had the discipline for TDD, I''d also be writing tests for the business logic. There is sometimes value to creating standalone business object classes that deal with one or more models, but my needs are usually met by putting the business logic directly in the model. Once I feel like all of the business logic for some action is implemented, I''ll write the respective controller method. Again, if I had the discipline for TDD, I''d be writing tests for the actions as well. I''ll work on a rough draft of the action''s view at this point as well, with the intention of making it pretty later. When I speak of a rough draft of a view, that doesn''t mean sloppy HTML. It means simple, concise HTML with essentially no formatting elements (divs, spans, class attributes, styles, etc.). Non-AJAX JavaScript is also saved for later. Once I''m done with the functionality, the views get my full attention, including a single, app-wide stylesheet and occasional controller-specific stylesheets. If possible, I try to use the same layout for the entire app. When I draw stuff for design, it tends to be on a whiteboard. If it is intended to become documentation, however, I''ll manually copy from the board into xfig. } Jules --Greg
Gregory Seidman wrote:> > I design the database first, sometimes with an ER diagram and sometimes > with straight SQL DDL. I''m a firm believer in getting the data model right > (or very close to right) before coding on top of it.Interesting. Unless the data model is, in essence, the application (e.g., the typical "show my catalog of stuff on the web" sort of thing) I prefer to start with behavior and class responsibility, and have that drive what data are needed, and where, and how/what data need to be stored. And that process usually starts with use cases and the UI. But everything tends to evolve based on user feedback and the friction between what looked reasonable in the abstract and how well it works when actual humans are poking around. James Britt -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools
I have often found that regardless of the technology it is important to work on the design by getting a good understanding of the use cases and then start creating the database model and laying that out. Getting the database normalized is eventually an incremental process that changes and grows as the needs of your application changes (ie different use cases being added or removed etc). My two cents on this is to work on this incrementally from both sides (the two sides being the persistence layer and the view layer). James Britt wrote:> Gregory Seidman wrote: > >> >> I design the database first, sometimes with an ER diagram and sometimes >> with straight SQL DDL. I''m a firm believer in getting the data model >> right >> (or very close to right) before coding on top of it. > > > > Interesting. Unless the data model is, in essence, the application > (e.g., the typical "show my catalog of stuff on the web" sort of > thing) I prefer to start with behavior and class responsibility, and > have that drive what data are needed, and where, and how/what data > need to be stored. > > And that process usually starts with use cases and the UI. > > But everything tends to evolve based on user feedback and the friction > between what looked reasonable in the abstract and how well it works > when actual humans are poking around. > > > James Britt >
On 1/16/06, Mufaddal Khumri <mkhumri@allegromedical.com> wrote:> I have often found that regardless of the technology it is important to > work on the design by getting a good understanding of the use cases and > then start creating the database model and laying that out. Getting the > database normalized is eventually an incremental process that changes > and grows as the needs of your application changes (ie different use > cases being added or removed etc). > > My two cents on this is to work on this incrementally from both sides > (the two sides being the persistence layer and the view layer).I''m working on a project now where I''m trying out a completely new approach (for me anyway). It''s based loosely on the some of the ideas presented in Joe Gregorio''s column on how to develop a REST-ful API (http://www.xml.com/pub/a/2004/12/01/restful-web.html) The hope is that by designing my application with a similar process, it will help to make it much easier to expose it via a web service or REST api. First, I started with the domain model. I know fairly well what the schema should look like, and what the relationships should be. So, I create models using ./script/generate model Thingy And I start writing tests for the model to ensure that I''ve got the relationships correct, etc. For the controllers, I have an OmniOutliner document (but you could do it with plain text just as easily) with 4 columns - this is where I''m stealing from the REST ideas. Action: This is something like "Create a new thingy" or "Get all widgets associated with thingy" Representation: This is the URI for the Action, e.g. /thingy/show/[id] Tested: A checkbox, checked if an Action has been written and tested Method: GET, POST, DELETE or PUT Then I create a controller (by hand as opposed to generating it, but I suppose I could do either), and a controller test and I start doing TDD. I walk through the outline, and for each action in the outline I write a test, and implement the action. For the views, at this point, I don''t care what they look like at all. I just know that on the "Get thingy" action I need a div that represents the thingy, so I test for this: <div class=''thingy'' id=''thingy_<%= @project.id %>''> ... </div> With something like this: assert_tag(:tag => ''div'', :attributes => { :class => ''thingy'', :id => ''thingyt_'' + thingys(:first).id.to_s}) If I get to a controller action which requires something I haven''t implemented or considered in my domain model, I go back to that and start writing unit tests. It seems to be going OK so far. I''m a little worried that I''m not doing enough "assert_tag" assertions, so I might be missing something. But as a process it seems to be working. Lance -- Lance Ball http://lance.langwell-ball.com
I like to start with a database layout too, but I go for the minimalist approach here as well. Agile development demands that you do only what is necessary to make the current test pass. If that means having a cusomer table with just an "id" and "name" field, so be it. With TDD its easy to flush out the db design as work progresses. There will be time to add address, phone, and bra size later. The idea is to hold off making structure decisions until the last possible minute. Once a data schema is set, it tends to be very inflexible. I want to always leave the maximum amount of flexibility in place. Example - does the "first name", "last name" fields go in the customer table, or the credit card table, or both? I''ve built apps all three ways, and untill you''ve gotten a lot of use cases, flushed out those cases, and even rewritten them with the user, it can be difficult to know which one is proper. On 1/16/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:> > On Sat, Jan 14, 2006 at 01:53:05PM +0100, Jules Jacobs wrote: > } Hi Railsers, > } > } How do you design your applications? Do you start coding HTML? Start > } with the controllers/models? Start in a program like > } photoshop/gimp/illustrator/inkscape? > } > } I start in inkscape, it''s a SVG editor. I sketch all the views of my > } application, and then I create the views that belong to one controller > } in RHTML. After that, I do the models/controller, and move on to the > } next set of views. > } > } How do you do create your applications? > > I design the database first, sometimes with an ER diagram and sometimes > with straight SQL DDL. I''m a firm believer in getting the data model right > (or very close to right) before coding on top of it. I''m also a firm > believer in using the right tool for the job, so I make a point of using > the database schema for what RDBMSs do best (i.e. data integrity such as > foreign key constraints). I''ll generally set up a separate rails test app > with just scaffolding to test and play with the schema. > > Once I''m moderately confident of my schema, I use rails to create the > models. I don''t use the scaffolding for a real app, since I find that it''s > pretty pointless to have one controller per model and with some regularity > there is a need for a controller or two that has nothing to do with a > single model. I''ll use rails to generate my controllers, then add stub > action methods by hand. (This assumes that I''ve already figured out > roughly > what operations, a.k.a. controller actions, the user will need.) > > I then start adding business logic to the model classes. If I had the > discipline for TDD, I''d also be writing tests for the business logic. > There > is sometimes value to creating standalone business object classes that > deal > with one or more models, but my needs are usually met by putting the > business logic directly in the model. Once I feel like all of the business > logic for some action is implemented, I''ll write the respective controller > method. Again, if I had the discipline for TDD, I''d be writing tests for > the actions as well. I''ll work on a rough draft of the action''s view at > this point as well, with the intention of making it pretty later. > > When I speak of a rough draft of a view, that doesn''t mean sloppy HTML. It > means simple, concise HTML with essentially no formatting elements (divs, > spans, class attributes, styles, etc.). Non-AJAX JavaScript is also saved > for later. Once I''m done with the functionality, the views get my full > attention, including a single, app-wide stylesheet and occasional > controller-specific stylesheets. If possible, I try to use the same layout > for the entire app. > > When I draw stuff for design, it tends to be on a whiteboard. If it is > intended to become documentation, however, I''ll manually copy from the > board into xfig. > > } Jules > --Greg > > _______________________________________________ > 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/20060116/d158ed1b/attachment-0001.html
37signals have written some good articles about application design. And I''ve heard they use Rails ;-) http://getreal.37signals.com/ There are actually a lot more posts on the topic that aren''t linked to on that page. Their blog doesn''t appear to have a search field, but you can go to the archives http://www.37signals.com/svn/archives.php and search the page for "getting real".