jerrygarciuh has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,
I have been hired to code a calendar almost exactly like this one with the calendar data entered via whatever I design into a MySQL db. As it stands I plan to contemplate the most intuitive way to set up the dates as indices and maybe a limited array of topic headings for an alternate presentation of event by topics. Then I'll make the Perl to create and red the data as I envisioned it.

My question is how others go about relatively simple projects like this when they have more or less free rein? Which comes first data structure or code?


TIA
jg
_____________________________________________________
Think a race on a horse on a ball with a fish! TG

Replies are listed 'Best First'.
Re: OT: Data Structure First or Code First?
by dws (Chancellor) on Mar 29, 2002 at 21:12 UTC
    Which comes first data structure or code?

    Neither. Write a unit test first. I'm serious.

    Starting with a real client, even if it's just a test, forces you to focus on the interface. Once you've got the client interface thought through, work from interface into data structures.

    If you start from the data structures, you risk influencing the API from the data structures, rather than from a client perspective. Many unusable messes are made this way.

[reply]
      I'm looking around for what a unit test is...help me out? Are you suggesting that I develop the interface which will insert the data first?
      TIA
      jg
      _____________________________________________________
      Think a race on a horse on a ball with a fish! TG
[reply]
[d/l]
        A unit test exercises an API and verifies that it returns correct values for correct inputs, and handles incorrect inputs correctly. In your case, I'm guessing that your API will produce an HTML table given (at least) a date.

        A simple unit test might feed that API several dates, comparing the resulting HTML to known-good reference copies.

        To make this work will probably require that you get your data access abstraction right, so that you can pass a stubbed database in for testing purposes. Or, you can structure the calendar object such that it's populated by a separate agent. Use a dummy agent for populating with test data, and a real agent (which you write separate unit tests for) for accessing the database.

[reply]
Re: OT: Data Structure First or Code First?
by simon.proctor (Vicar) on Mar 29, 2002 at 21:22 UTC
    Well my first rule is a simple project never stays simple for long. You build it quickly, it works...sure some aspects are a bit dodgily written but what the hey. Then your client/boss (whatever) comes along and says 'Hey great...now can you add such and such to it please'.

    So you add and add until eventually you have a complete mess. Then you have to rewrite it or keep it in an unsupportable state and hand it off to someone like a ticking bomb.

    So what I do is always,always design before coding. Unless of course its one of those one-liner apps that takes 2 mins.

    In my opinion (and it is just my opinion) you can't code til you know what data the program will operate on. Then of course as you are defining the data you need to 'know' what that data will be. So the only way you can do that is with a design. In otherwords design code and database and then move on to the code itself.

    If you code last then the language you use is (mostly) immaterial as you have solved the problem first.

    Normally a free rein project just gives you more scope to shoot yourself in the foot. Do it as properly as you can in the time you are allotted and at least you can do some damage minimising.

    Just my two penneths worth :)
[reply]
Re: OT: Data Structure First or Code First?
by rbc (Curate) on Mar 29, 2002 at 21:44 UTC
    ChOas wrote a Meditation that might be relevant to your question 154781
    A lot of monks chimed in.
[reply]
Re: OT: Data Structure First or Code First?
by Maclir (Curate) on Mar 30, 2002 at 03:48 UTC
    Neither comes first. In any application more complex that a "hello world" exercise, the first stage - and the most important - is the analysis. Define what the application has to do. Make sure you have a limit on the overall scope.

    An important part of the design process is process modelling (or use case analysis if you are a troe object orientated person). This should identify the key data elements, and how they are used in all areas of your application. You may then want into somedata modelling - at a logical level first, then a physical data model. If you are using a relational database, this is often done using an E-R modelling tool - an Entity Relationship model.

    Finally, design the various code sections to implement your process model and to interface with your (physical) data model.

    As a rule of thumb, expect coding to take about 10% (the final 10% before testing) of the total project time.

[reply]
      Well, if anything this has once again humbled me with the fact of my ignorance. I will take this advice to heart as I can, but I have realized that I will probably have to get some CS coursework under my belt somewhere down the road 'cause every time I learn a little of something new, I find folks are talking a foreign tongue. I have registered from your responses the importance of analysis of task and data prior to beginning and that I will do.
      Thanks,
      jg
      _____________________________________________________
      Think a race on a horse on a ball with a fish! TG
[reply]
[d/l]

Back to Seekers of Perl Wisdom