DRYing our project

[fabianoalmeida]

Creating a helper method to build the navigation links using twitter bootstrap and related to each type of controller. So, I removed all useless HTML page. :sparkles:

[fraga]

We need to assign a "merger", who will be responsible of merging pull requests =)

Or since we all collaborate, each one create the pull request and then merge your own code...

[fabianoalmeida]

@fraga the idea behind pull requests is you show your code to solves something however opened to hear suggestions, critics or simply ignored it by someone. As we know, this is the collaborative way to build software.

So, I don't agree with your suggestion that the "merger" could be the pull request creator.

For example, imagine that you created a solution but you forgot that a little piece of code will broke all tests or another piece of code.

As your code is usually you can't see it with ease, mainly when the project has a lot of lines of code. Nevertheless, this could be easy to me identify it, you know?

So, I think the pull request creator should be only submit and wait to argument / "fight" for your idea / solution.

I hope this explanation helped you to understand my point of view. However, I'm opened to hear your idea.

On Tuesday, March 5, 2013, Rodrigo Fraga wrote:

We need to assign a "merger", who will be responsible of merging pull requests =)

Or since we all collaborate, each one create the pull request and then merge your own code...

— Reply to this email directly or view it on GitHubhttps://github.com/seixasfelipe/cleaners-panamby/pull/14#issuecomment-14466086 .

Fabiano Almeida http://about.me/fabianoalmeida

[seixasfelipe]

I disagree some at some parts in this commit. I would stay with all .html files inside public folder because our system is not complete, so this is a way to our customer navigate through it and see what he would expect us to do.

What do you think about it?

[fraga]

@fabianoalmeida moved that discussion to #20 =)

[fabianoalmeida]

@seixasfelipe your disagreement point is about detail pages? If the answer is yes, I'll add it and up to date my pull request. I removed it but we haven't this information or link in index view. :confused:

[fabianoalmeida]

@seixasfelipe could you take a look? Is it better now or you want to maintain the HTML pages in menu partial?

[fraga]

what if we had a mock controller that would fill those requests on the mocked pages? Then http://website/mock/customer/new would map to the fixed html => customer.new.html

This would be for demonstrations purpose, is it too hard to do?

[fabianoalmeida]

I guess this is useless. We will do it and after that delete it. We need programming it as soon as possible to remove the HTML pages. If we want demonstrate we could put this HTML as a link on the programmed Ruby view until we solve it programmatically.

[seixasfelipe]

I prefer let those links pointing to html pages. Another option would be show our HTML page only, that already points to others HTML pages eheheh.

What do you think? Try access public/layout/index.html and you could navigate through html pages without even knowing that we are doing the system for real.

Le jeudi 7 mars 2013, Fabiano Almeida a écrit :

I guess this useless. We will do it and after that deleted. We need programming it as soon as possible to remove the HTML pages. If we want demonstrate we could put this HTML as a link on the programmed Ruby view until we solve it programmatically.

— Reply to this email directly or view it on GitHubhttps://github.com/seixasfelipe/cleaners-panamby/pull/14#issuecomment-14596957 .

[fraga]

I don't think it's a good practice to have mock items mixed up with real items (in this case a menu pointing to a specific html page) on the same webpage. System wise it's confusing for us. However, sales team could be using that to present customers where the system is aiming at. That's why I suggested creating an "area", a mockup area, totally isolated from the system itself. I cannot say much because I'm not into web development, but in big systems like ERP we have different "installations" to mockup specific scenarios or even to present (demo) something that's being developed... We can also use git branches - mockup branch that all links are hard links to static html pages...there's a lot of ways to solve that! =)

[fabianoalmeida]

@fraga I agree. However, when the sales team are presenting the system for our customers it's really important that we have a system actually and not HTML pages. It's common use this mentality to present websites too, installing in sales team notebook or create a copy from production to a "stage" area, on the world wide, to demonstrate the functionalities. In other words, I think that we need "program" the application first, creating the features listed by @seixasfelipe in the milestones, fixing some errors etc and after that we could do something like you suggested.

[seixasfelipe]

I agree partially with you @fabianoalmeida and also with @fraga. The points are:

1) we must have a mockup (just HTML pages) to present what the system would be able to do when its completed. 1.1) we can do those mockups without referencing our real system, that why I suggested a public folder with HTML only pages that is "navigable".

2) I would like to send an email to our probable first customer and get a feedback of the mockup to see if he would be happy to have this system 2.1) I would continue to do the system even he wouldn't want to buy it, I'm doing it to sell to someone (of course) but to learn more about RoR, Web Development, etc!

[fabianoalmeida]

Great guys! Now I understood the idea behind the mockup. So, what do you think to ignore this pull request? Or do you have other idea about this PR? If you want I can maintain HTML links and remove navigation_links from menu partial.

[seixasfelipe]

@fabianoalmeida I think this PR is fine, just let those .HTML be there (do not remove them) and remove from navigation bar those links that are leading to .HTML pages, that's it! =D

[fabianoalmeida]

Ok. I got it.

[fabianoalmeida]

Done! I tried to rebase the commits but resulted in a lot of commits however could be merged automatically without problem. :smiley: