RoR Project I have :o
I was wondering if you all could help me. I am in high school you see, and my teacher has this idea for a student management system with goals and such. Anyway, I came here for advice, so that is what I will ask. I have built a couple of simple RoR Aplications, such as a todo list, and a shout box but I have not yet tackled anything of this magnitude. Basically, there will be a database containing name, pictures, skills, goals, parent names, emails and such displayed individually for each student. Also, there will be a Project summary and info section for each student, that could be updated by them. Along with the project, it will shows skills that they have developed. The skills will be rated on Good, bad and So-so, represented by filled, half-filled and blank circles. Anyway, my question is this, starting up with a such a big project, I'm a little hazy as to where I should start. I was wondering if there are any applications such as the one I will be creating out there that could help me. Also, is there any advice on how to acutall create what I'll be creating? Thank you in advance. - Jeff
Oh, and Happy Valentines DAY. :avalentine:
I usually get a basic idea of what each page will look like and how the pages will interact with each other--I draw a picture. From there I can figure out what models I need. Then I start out with bare bones functionality, then add fancy/more complicated stuff after the basic things are working.
If you haven't read Agile Web Development with Rails, you should.:loveblush:
As with any database driven application the first step should be the database. Just make sure it's modeled correctly and your hard work should be done.
Thank you for the advice. I havn't yet read the agile development boook, even thouhg I bought a copy. I will soon. Anyway, I was searching sourceforge for projects similar to mine but couldn't find any. Does anyone have any suggestions?
Generally, when I develop apps, I tend to go down the route of drafting some rough specs on paper, along with ideas for a UI as some scribbles. While it seems an odd way to do things, I like to throw some mock UI interface + Design up in Photoshop so I have a clear cut idea of the main UI. This makes you think about how the site will work from a user's perspective. This is important as it needs to be simple and easy to use for them. A picture is worth 100 words as they say, so this does help implictly make you draw up the initial bit of the spec. Once you have an idea of how the system works froma UI perpective, you can consider drafting a spec based on some mock screen shot and user stories (i.e. typical short passages that explain how the site should work from a user perspective. These should be writen from a end user's / client perpective, and therefore not really have any programming lingo).
Make a tight bullet point specification. It's worth spending time making a decent spec here. It should outline exactly what your system does. Nothing more, nothing less. This is whee many go wrong. Some spend too long making a huge spec because they include features and other crap that is not needed by the user, or in most cases the spec is not detailed enough. A good spec is important in a more business orientated environment. You can use it to estimate exactly how long each component will take to develop, which in turn allows you to put a price on each part of the system if you are developing a project to earn some cash. In larger projects I like to prioritise things in the spec in a way that allows the most important features to be developed first. That way the client can start using /testing your project sooner. On big projects break up things into short iterations of a week or two if needed.
A good spec will also allow you to identify where you need to write unit test if you want to go down the test driven development route. I lot of people rave on about TDD. I'm not the best one for writing things like unit tests. I found from a personal perspective for my own projects I only bother with unit tests for items in the system that are hard to test manually (i.e. I needed to write a saved search system that emails periodically like eBay's system does, this was hard to test as it was time sensitive and complex), or are very critical to the system (i.e. invoicing systems).
Unit tests are important to ensure your system is running soundly. I tend not to bother going over the top, because things like functional tests to me are a bit of a waste. This is because personally I think changes to the controller and views need manual testing as functional tests can't do things like test if a page is broken on a given browser due to CSS issues etc. As a result I think most functional testing can be a waste of effort when you need to manually check these elements. The amount of testing is down to you. As I say, I tend to just do enough to cover myself. Other people will probably will disagree with me here and spend more time writing tests. Ideally you should write tests before you write code if you follow TDD strictly. Personally I tend to not always do this (however I normally think about what tests I should use before writing the app if I end up writing them after the app, mainly because things like tests allow you to identify flaws in your spec).
I will back people here, buy a copy of the Agile rails book. It's worth it. Also look at a good ruby reference. Spend some time looking at using things like script/console / irb and other debug tools like breakpoint, and the debug view helper (to raise yaml versions of objects). Once you have a good strategy for debugging it makes development a lot quicker and easier as you don't get held up.
Hope this helps you. I've kinda put this down from a business perpective (i.e. use you spec to help create prices). Obviously, you cut out some stages according to needs. On simple projects you don't need to spend time planning detailed specs. At the beginning of each day it's good to make a short todo list of what you want to achieve for the day as well. Having targets will ensure you don't hold yourself back. Between writing a spec and writing code, you might wanna look at making "spike solutions" (quick test / mock-up code). These can help if you are unsure how you will go about implementing things as you can find out what approach will be best, and tackle those tricky design decisions early on so you don't get held back when you get to coding things.