Rails - Dec 2005 - App access privileges

Hi all,

I''m about to go wild on my new application under Rails. I''ve
got a hosting
company and want to build a complete administration app. Are there any 
pitfals to avoid, when for instance in the future I want a seperate account 
(or group) for managing contact details etc, and a seperate acount (or group) 
for managing prices. I do not have clear yet what I want seperated (or 
hidden) based on accounts in the future. Should I just start and see where it 
leads me (good practice btw), or are there thing to already consider.

Thanx!

Gerard


-- 
"Who cares if it doesn''t do anything?  It was made with our new
Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."

My $Grtz =~ Gerard;
~
:wq!

Gerard,

Well you can''t do everything with ''boeren verstand'',
sometimes you just
need to sit down and write a couple of scenarios you think you will be 
facing, what you are really expect in the feature (so not thing that 
could you expecting). Its usually a bad way of building software, by 
making all kind of options that could be used in the feature or things 
that you could need.

Just design the application  based on the present requirements (and try 
to be flexible with your database design). And then make the 
application. When changes occur (and most of the time the changes you 
expect don''t occur) just adjust the application. It just depends on
your
needs, sometimes you are dealing with companies that have much (money) 
to loose if changes can''t be done fast or rely on the database by using
it from other applications. But based on what I see you offer on your 
website, you should just start making and adjust when things need to be 
changed.

Veel s6,

Abdur-Rahman

Gerard wrote:
> Hi all,
>
> I''m about to go wild on my new application under Rails.
I''ve got a hosting
> company and want to build a complete administration app. Are there any 
> pitfals to avoid, when for instance in the future I want a seperate account
> (or group) for managing contact details etc, and a seperate acount (or
group)
> for managing prices. I do not have clear yet what I want seperated (or 
> hidden) based on accounts in the future. Should I just start and see where
it
> leads me (good practice btw), or are there thing to already consider.
>
> Thanx!
>
> Gerard
>
>
>

Abdur,

I must say I totally agree. The scope should be the demands I have now.

Thanx for the push.

Regards,

Gerard.

P.S. I wonder how many people on this list understand the term ''boeren 
verstand'' .. :-)



On Sunday 25 December 2005 15:48, Abdur-Rahman Advany tried to type something 
like:
> Gerard,
>
> Well you can''t do everything with ''boeren
verstand'', sometimes you just
> need to sit down and write a couple of scenarios you think you will be
> facing, what you are really expect in the feature (so not thing that
> could you expecting). Its usually a bad way of building software, by
> making all kind of options that could be used in the feature or things
> that you could need.
>
> Just design the application  based on the present requirements (and try
> to be flexible with your database design). And then make the
> application. When changes occur (and most of the time the changes you
> expect don''t occur) just adjust the application. It just depends
on your
> needs, sometimes you are dealing with companies that have much (money)
> to loose if changes can''t be done fast or rely on the database by
using
> it from other applications. But based on what I see you offer on your
> website, you should just start making and adjust when things need to be
> changed.
>
> Veel s6,
>
> Abdur-Rahman
>
> Gerard wrote:
> > Hi all,
> >
> > I''m about to go wild on my new application under Rails.
I''ve got a
> > hosting company and want to build a complete administration app. Are
> > there any pitfals to avoid, when for instance in the future I want a
> > seperate account (or group) for managing contact details etc, and a
> > seperate acount (or group) for managing prices. I do not have clear
yet
> > what I want seperated (or hidden) based on accounts in the future.
Should
> > I just start and see where it leads me (good practice btw), or are
there
> > thing to already consider.
> >
> > Thanx!
> >
> > Gerard
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-- 
"Who cares if it doesn''t do anything?  It was made with our new
Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."

My $Grtz =~ Gerard;
~
:wq!