Topic: A noob's desire to get it "right" the first time

Hi gals/guys,

I have recently seen the greener grass and come over from PHP-Land.
In the past, I have created web-apps and they have ended up a confused heap of code. Always, I was going to try better to make an organised system 'next time'.
I can see the opportunity in rails, along with ruby, to make a beautifully structured application (hey, it seems alot is done for you). What I want to make sure is that I make the most of what rails and ruby have to offer. I don't want to succumb to my past demons and sacrifice quality for silly desires.

So, my first project on rails has been born.

I am a member of a local boardriding club. We all ride surfboards and hold monthly competitions. Many people devote time to this club, I wanted to give something and I have started to build a website and system for the club. What a perfect opportunity to try out ruby & rails!

Below is my outline for the first phase of this project. I have put down the core of what I want to do in the hope that you (yes, you!) can help me a bit.
Can you (if you have the time - I commend you for reading this far) give me any helpful little bits of info?
Please, find faults in my ideas!

For the initial site I will be using users, news, divisions, events and scores.

Users - I will be getting the list of registered members for this year and filling a table with the data. Each year the registered users change, so an account will be either active or inactive (although this year, all will be active).
News - A bare-bones blog like thing - just crud on news posts. No comments. In the future I will give them the ability to link it to a specific event or member.
Divisions - The club is made up of different divisions, relating to the member's age and/or skill-level. A member's division will often change from year to year. I want to be able to track member's scores over the years, along with what division they were in.
Events - We run monthly competitions and hold other events such as parties. An event may span a varying length of time (a one day comp, a registration day for a few hours, a week's camping)
Scores - A score belongs to a member and an event (and through the event, a date). A member may have multiple scores for an event (I am in the process of learning how the club's scoring is done).

There are several different layers of security clearance for users.

Level 1, Public - Viewing data; editing personal info
Level 2 - Create and Update news items; Create and update events
Level 3 - Delete news; delete events; creating and deleting divisions, managing user->division relationships; ability to adjust clearance levels within levels 1 & 2, view user's private info (address, phone etc), editing user's personal info, marking users active/inactive, creating users; create, update and delete scores, manage the score's relationships between user and event
Level 4, Top Level - Make users level 3 and 4, delete users

I just read about single table inheritance which prompted me to see the above way of organising permissions. I am very confused in how it all works though. I don't understand what goes where.

A couple of things:
-Each year the club starts fresh
-I want to track members and events over years. A user may not be an active member one year and then they will the next, this I can handle at the beginning of each year by marking users active/inactive
-I need to design a very simple system for the scoring administration; the club currently tracks all scores over the year on paper and adds them up at the end. I want to make the switch to computer easy.
-I will be adding new features as time goes by

What is really important for me is that I can get this initial phase down in a correct manner. I want for the system to have a solid foundation from which I can extend and not need to change things later on.

So, what questions do I know to ask now?

1.    How do I organise this user/permission structure?
2.    How do I organise the different permission's abilities? For example - for news, is create, update and delete all within a news controller? Or are they split into different places according to the permissions required?

I started playing around with rails a week or two ago. I started to feel I understood how everything worked.
I feel like I have lost all understanding...

What is wrong with what I have planned above?

Thankyou very much for spending you time helping me.

Re: A noob's desire to get it "right" the first time

I think this is the most difficult stage in application development. Determining the initial database/model design sometimes feels like etching in stone because it can be difficult to turn back and refactor to some other design. I wish there was an easy answer.

As you can imagine, there are many ways to handle role based user permissions. See this post for one way I've done it. I've been able to implement this and extend it fairly well, and I've been impressed by the flexibility behind it. Storing all the permission handling in one spot (User and subclasses) just feels right to me. If you ever want to know if a user has permission to do something, just ask it.

As for the controllers, I recommend splitting them up based on their functionality and not how they are accessed and who accesses them. A good way to go is have each controller manage one model. This is what we call a RESTful design. There can be exceptions of course.

Railscasts - Free Ruby on Rails Screencasts

Re: A noob's desire to get it "right" the first time

Thankyou ryan
I like the look of your previous post, I believe it is the right way for my current situation.
I am relieved to hear the controllers should be split up based on functionality, I don't feel right about doing it otherwise. With regards to controllers managing models; models are the least understood component of this framework for me. I will have to read into them more to understand what they can/can't/should do. A restful design will be nice, but I am still yet to learn of its benefits - I have a bare understanding but I am unsure of the reason REST is so important.

I will definitely be posting again, I think I need to sketch an overview of the project on paper (although I have already done about 5!).

Thanks again.

Re: A noob's desire to get it "right" the first time

REST is difficult to grasp at first, but don't be concerned with the technical aspects of it - just try to get the concept of each controller handling the basic CRUD operations of a model (create/read/update/destroy).

I recommend sketching out the interface before working on the models. The interface determines the input and output - in other words, the information the user inputs and the information your app displays. If you look at the interface as a whole you can see little CRUD/RESTful patterns.

Wherever you are accepting data from a user (a form), you should probably be doing a create/update action on a model in the database. The interface will give you hints on how to design the database schema, models, and RESTful controllers.

Models are the backbone of any Rails app. Unfortunately many developers don't use them to their full potential. It's so easy to let the controllers take over the model's job. If you can move something from the controller into the model, you probably should. Just keep in mind: skinny controller, fat model.

Railscasts - Free Ruby on Rails Screencasts