Re: Writing a web message board from scratch

[Molt]

Is there any reason you're intending to write this all from scratch? As you say, it's similar to what's here.. so why not use or adopt code from something that already exists?

This has the advantage that the code has been bashed upon repeatedly and the bits that were liable to fall off have fallen off and been replaced by more resilient bits. Security holes have been patched, lock-ups removed, code made more friendly and customisable.

If you want to really hit the O'Reilly then I'd recommend you have a look at 'Running Weblogs With Slash'. Slashcode may not be the friendliest thing to set up, but compared to coding your own replacement from scratch it's a walk in the proverbial park.

Or, if you're after something more akin to the Perlmonks site, why not have a look at the code it's run on?

Both of these are nice and free. Enjoy.

Don't reinvent, spend your time doing things more productive.

[tomazos]

For better or worse the decision has already been made to roll-our-own. There are a few details that we need control of for our specific application and I'm sure it would be easier to do it from scratch rather than adapting existing code to it.

Let's assume that for some reason you have to write it from scratch and re-using an existing "web message board" codebase is not an option - all you can use is well-tested CPAN modules like DBI and CGI.pm etc.

How do you do it?

[merlyn]

Let's assume that for some reason you have to write it from scratch and re-using an existing "web message board" codebase is not an option - all you can use is well-tested CPAN modules like DBI and CGI.pm etc.

Well, SlashCode and E2 are both in the same status as CPAN modules, and are both readily available for stealing parts or just seeing "how you do it". In particular, Slashcode runs http://www.slashdot.com (a high-traffic, high-visibility site), and is highly reconfigurable: enough that you wouldn't recognize the externals.

It's perfectly OK to "reinvent wheels", presuming you study existing art first. Please don't ask us to spoonfeed to you what these guys have already discovered. Check out prior art first!

-- Randal L. Schwartz, Perl hacker

[cascade_fx]

In particular, Slashcode runs http://www.slashdot.com (a high-traffic, high-visibility site), and is highly reconfigurable: enough that you wouldn't recognize the externals.

This is exactly the argument that I made with a colleague for an Intranet/Message Board/Knowledgebase. We are adapting Slash to this and it is working out quite nicely. In fact, we are eagerly anticipating the new release which will include an automated graphic upload so that our tutorials have a less kludged process for uploading screenshots. THAT and the new plugin architecture is rife with possibilities.... something not in Slash? No need to throw the baby out with the bathwater, just code a plugin to add the functionality and still keep all that is right with it. Great software package and development architecture.

As far as making the pitch to management. I wrote a proposal and did a walkthrough of some popular Slash sites (Slashdot.org, of course, as well as Plastic.com). The selling point had to be the University of Utah's Engineering labs computer site (http://www.cade.utah.edu/). They use Slash for very similar purposes to ours and have modified the heck out of it.

cascadefx

Update (4/19/2002 2:45pm EST): Added link to University of Utah's College of Engineering Computing Facility

[Kolyan]

I'm afraid that although it's extremely useful to study existing code, designing it by yourself is completely different by it's nature.

It seems what he's not talking about how to get the job done and not about the reinventing the wheels.

But, assuming that it's time to create your own, HOW do you design your programs?

[tomazos]

:)

I guess my question isn't as much to do with the specifics of writing a web message board as it has to do with the general process of beginning a project of about that size.

Let's supose I want to write a widget web application in perl. Noone has ever written a widget web application before so there is no existing code to study, only building blocks that are not immediately obvious how to combine.

I'm after general ideas about how to go about planning the implementation of a widget web application.

I hope I'm making sense. :(

[Molt]

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.

[tomazos]

Interesting. So essentially you are suggesting the best way to start would be to write a small and simple program and then build that up to the large program by adding on a bit at a time.

I've noticed that a lot of programmers disagree on this point. Some suggest the best way to do it is to work on the big picture "on paper" and then keeping refining that until the final code "falls out".

I've never seen that method actually in practice, but I have an open mind.

[hsmyers]

You said

For better or worse the decision has already been made to roll-our-own. There are a few details that we need control of for our specific application and I'm sure it would be easier to do it from scratch rather than adapting existing code to it.

Which makes me ask, if you haven't done this kind of thing before, just why are you sure that it would be easier to do from scratch rather than adapt? Particularly code that was written with adaption in mind as the already done modules were (ok, maybe not originally, but they are by now given the number of times they have been changed...)

What I'd suggest before anything else, is that you acquire the code from slash or from here on PM and research just what all would be required to implement the 'few details'. Along the way, take a look at what is required for such a project-- this would also help you begin your own design if it comes to that...

–hsm

"Never try to teach a pig to sing…it wastes your time and it annoys the pig."