|XP is just a number|
Re: Re: Re: Writing a web message board from scratchby Molt (Chaplain)
|on Apr 19, 2002 at 14:12 UTC||Need Help??|
In this case it's rapidly becoming a matter of having difficulty answering this in any way it's going to be at all useful for you as how I probably doesn't resemble one bit of how you would do it.
I'd first of all make absolutely certain there's no way on Earth that I can't adopt another solution. If I adopt I know what needs changing, I know my tasts. If I don't adopt I have to solve problems that I don't even know about- How do I stop cross-site scripting attacks? How do I authenticate users and handle sessions? How do I prevent someone from knocking up a two minute Perl script to hammer out slightly-different offensive messages to all posts on the board at a ridiculous rate?
Never assume the worst won't happen, especially with any kind of communication forum where emotions can run high. Expect to be attacked from every point, expect your servers to fall over regularly.
Now it'd come to programming. Personally I'd approach it the same as I approach any other large project, but as I said you will vary. To start I'd build a list of features, and user-stories, going through it all in my head and on paper. From this I'd make a list of components such as in this case session-management, templating, database access, authentication, possibly XML parsing, input validation, email handling, and I'd try and match them up with CPAN modules. Almost certainly I'd end up with modules I'd not used before so I'd try and learn a bit about them and write a few test programs to get to grips.
Now I'd try and think about where I expect problems and try and make sure I don't hit dead-ends there. User-abuse, how's it dealt with? Bad data gets into the database, what happens?
Now I'd try and build a small and simple program with the core functionality, essentially post a couple of messages unauthenticated and recall them. I'd now build round it, adding all the features I've listed in an order that makes sense to me, using unit testing to make sure it all hangs together. Eventually I'd hope to work towards a working solution.
Now, for you. From the way you phrased your question I'd actually think you'd not done too many large projects, if this is true then expect to walk across hot coals in order to get something this complex working, and even then expect to spend a good long time fixing problems. Save time by doing your homework, read up on software engineering methodologies and actually try and use one, I personally tend to use the test-early-test-often, do-the-minimum approach from Extreme Programming, but I don't use the peer programming and few diagrams. You need to find what works for you, however.
I do wish you luck in this, but I also have the horrible feeling you'll need it.