Re: Writing a web message board from scratch

[Biker]

in reply to Writing a web message board from scratch

Sit down with paper and pen (and posibly a colleague of yours). Talk yourself through the usage of the future system. Go through everything that should be possible and how.

Whenever you pronounce a noun, put it down as a potential class. If you also hear yourself mentioning that the noun must be able to verb, then you write down this as a potential method of the class.

In Perl you're not forced to use objects and very often you will use procedural code to handle entities. These entities will become objects implemented in you class modules.

Implement the skeletons for the classes and repeat the verbal session. Ask yourself if your classes really represent the nouns you need in the system and if they are able to perform all the verbs that must be done. Redo. ;-)

Another thing to think about is a way to handle the numerous constant values and common Perl subs that must be shared by your (presumably) large number of Perl scripts.

Decide the strategy for a/the database backend.

---

Everything went worng, just as foreseen.

[tomazos]

Wow. Cool. What do you call this brain-storming procedure? Is there an official name for this area of knowledge? Are there books and/or web sites about this sort of thing?

I don't mean to sound like an idiot, but I am self-taught and don't know this sort of stuff.

[Biker]

There are probably hundreds of publications on the subject. (Booch comes to mind.) Search the web for OOD (Object Oriented Design) and you will find lot's of it.

The way I do it is a mix of reading many books about several methods mixed up with (too long a) time using it in real life.

"I don't mean to sound like an idiot..."

Not asking makes an idiot. ;-) The only stupid question is the question never asked. (OTOH, chosing the right fora for a question may be an art in it self.)

---

Everything went worng, just as foreseen.

[Saveth]

There are probably hundreds of publications on the subject. (Booch comes to mind.) Search the web for OOD (Object Oriented Design) and you will find lot's of it.

Booch, of course, being one of the authors of UML, the Unified Modelling Language. It's the industry standard for planning out projects and provides facilities for both broad-based planning and very narrow planning. Booch and a few friends came up with Rational Software, which produces a program called Rational Rose, the only Really Good (tm) UML design program.

Anyway, if you've got a week or so to do some research, you may want to look into UML and use it to design your project. Since it's for your company, rather than yourself, it may also help to use a standard design method, since the next guy that works on this project may not have a clue how to read your version.

Then again, the Perl code you'll be writing is job security, in itself, isn't it? :)

Just my dos centavos.

-Saveth

[mAsterdam]

Tomazos:

What do you call this brain-storming procedure?
Is there an official name for this area of knowledge?
Are there books and/or web sites about this sort of thing?

Just some keywords (& authors):

• Try story telling to elicit typical user/system interactions, i.e. use cases from your users.
• Find out about the important classes and their interdependencies:
  • Organize sessions with CRC cards: Class Responsibility Collaboration and
  • Do lexical analysis on business documents
• Prioritize requirements / use cases in a group with MoSCoW-rules: Must / Should have / Could have / Won't have this time around
• Schedule features / use cases in timeboxes

  Authors:

  • Ivar Jacobson
  • Martin Fowler (Very readable and small book: UML Distilled)
  • DSDM

  HTH

[agentv]

...this is great advice.

Determining what "things" will be in your system will guide you as you decide what needs to be built next.

Advice above that you carefully examine what there is in the world already is sound guidance. But don't believe that the task is difficult and insurmountable. Perl is designed to make things like this easier.

If you begin with a clear picture (it doesn't matter if it's a tree, an idea diagram, a flowchart, or a "Bacchus-Pinkus-Zeus standard compressed paranormal data continuum diagram," as long as it helps you clarify your thoughts about how the big picture fits together,) you're on the right track.

Plan to build something that you can see and test early on. Then each iteration of your coding operation will build upon a working foundation.

Good luck. This really isn't hard to do.

---v