in reply to Developing a module, how do you do it ?

You have to work harder so that you can make it easier.

Version control: Put it under Git or something similar. That way you can easily create branches for various ideas or development tracks.

Your test suite can drive new features. As you come up with a new idea to add to the module, add a test for it. Be sure to also add tests that test the various units that contribute to the new feature, as well as testing the normal use case you anticipate. And don't forget edge cases.

make (or dmake), then you can prove: prove -b -v t/10newfeat.t. ...although I find that sometimes prove jumbles the chronology of stderr output and stdout output, so while developing I usually just, perl -Mblib t/10newfeat.t.

Here's a brief example of the steps:

  1. New idea comes to you, and after doing the necessary research.... git checkout -b newidea <= This creates a new topic branch for your project.
  2. Create a new group of tests: t/10newfeat.t <= It doesn't matter if these will end up being "finished product" within your test suite. Just code up a few tests that drive the unwritten solution how you would like to be able to use it. Mark the test(s) "TODO".
  3. git commit -a -m "Created TODO tests to drive feature xyz."
  4. Work on your new feature.
  5. Anytime you want to see how your feature is progressing, either add another driver test to your test file, or invoke the existing ones: make; perl -Mblib t/10newfeat.t.
  6. Whenever you get to a point where you wouldn't want to have to recreate work, or where you are about to take a gamble of some sort, don't forget to git commit -a -m "Milestone: xyz does abc."
  7. Repeat the above coding, testing, committing steps as long as it takes.
  8. Set a version number (possibly a Developer's version number).
  9. Update 'Changes', MANIFEST.
  10. git commit -a -m "Feature XYZ implemented."
  11. git checkout master (or whatever branch you want to merge this new feature into).
  12. git merge newidea (and iron out any merge conflicts).
  13. make realclean, perl Makefile.PL, make, make distcheck, make test, make disttest, make install, then run your test suite against the installed version. <= All steps that will help to give you confidence that you didn't miss anything along the way.
  14. Either tidy up some more, or if everything's ready to go: git tag -a -m "v0.12 Added xyz feature" "v0.12" 12asdf (the MD5 of your final commit).

Now you can push it to your external repo, upload to CPAN, move it into integration testing, go live... whatever you do next with your work.

Your steps and workflow will differ; collaboration, additional testing, keeping topic branches out of the master until after some other milestones are reached... whatever. And no two projects are alike, but that's the general notion of what seems to be my pattern.


Dave

Replies are listed 'Best First'.
Re^2: Developing a module, how do you do it ?
by BrowserUk (Patriarch) on Feb 29, 2012 at 05:40 UTC

    Somewhere in the Home Counties circa. 1930.

    Lady Jane picks up the telephone receiver, "jiggles" -- she was assured that was the right term -- the contact "thingy" on the cradle -- she knew that wasn't the right term, but no one seemed to know what it was called -- a few times.

    Placing the receiver close to her ear, she waited. Presently, she heard the unfamiliar, but renowned, shrill squealed greeting of the County telephonic operator -- the Estate operator really; but since the Estate encompassed pretty much the entire county, they very much were one and the same thing.

    "Oper'ta. 'ho can I get for yur love?"
    "Good morning. Mrs Patterson. And how are you today?"

    she enquired. Civility & proprietary, hallmarks of her breeding, she thought.

    "Oh M'lady. I'm ... I'm very well. Thank you M'lady. Sorry, When your line rang I assumed it would be Tollerson calling, I ..."

    Cutting her off.

    "No matter, Mrs Patterson. I wonder if you would be so kind as to put me in touch with my husbands office."
    "Of course M'Lady. Right away. Won' be buta jiffy..."

    She could hear frantic activity and indiscernible snippets of hushed conversation at the other end.

    "Oh, and Mrs Patterson, since it is becoming the done thing to use the infernal contraptions oneself, and we are likely to be talking to each other on a more regular basis from now on, do drop the "M'lady". Call me Lady Jane. It it the 19030s all said and done".
    "Of course M'l.. I mean Lady Jane. Thank you M ... Um Lady Jane. Would ya mind 'olding for a few seconds, I need to talk to the receptionist at t'other end.
    "Certainly".

    A few seconds went by.

    "Okay Lady Jane, I'm putting you through to Miss Frobershire now. Go ahead caller."
    "Hello", Lady Jane enquired tentatively.
    "Hello, Lady Jane, Miss Frobershire here. How may I help you?"
    "I wonder if you could convey a message to my husband for me?"
    "Perhaps I could put you through to his secretary, Mrs Lyons?"
    "Oh yes. That's a very good idea. Please do."
    "Okay, please hold."
    "Oh and .."

    but the lne was dead. She waited and after a few moments she heard.

    "Mrs Lyons, I have Sir John's wife, Lady Jane on the line for you."
    "Hello? Lady Jane. Is something wrong?"
    Enquired Mrs Lyons.
    "No no. I just wanted to get a message to my husband. Nothing terribly urgent, but he told me that I really should make the effort to use this thing. We apparently pay quite a lot of money for the privilege of having it, and it sits here day and night mostly doing nothing."
    "I see Lady Jane, well Sir John is in a meeting with the PM right now, I don't think that I should interrupt him if it isn't urgent."
    "No, not urgent at all. Perhaps you could take a message and see he gets it?"
    "Of course Lady Jane. How would you like the message to read?"
    "Please ask him to swing by Fortnum & Masons and pick up a jar of their wonderful Potted Shrimps, only his mother is calling in for tea tomorrow and she does so love them."
    "Is that all Lady Jane?"
    "Yes... er. rather no. Could you also ask him not to be late home this evening as the Fothering-Smythes are coming for dinner and they are such a bore. I need him here to prevent me falling asleep in my soup course."
    "Certainly Lady Jane. Is that all?"
    "Yes. Thank you, Mrs Lyons. That's all. Goodbye."
    "Goodbye Lady Jane".

    The line went dead. "What do I do now?", she though. And settled upon replacing the receiver on its cradle.

    Leap forward 80 years to present day.

    Jane picked up her cellphone, swiped it unlocked and touched the contacts app. Swiped down until she found her boyfriends number, touched the txt icon and typed: "Pick up takeaway on your way home -- Chinese or Indian. XXX" and hit send.

    "I probably should have abbreviated some of that, but it always takes me longer to decide how to abbreviate it than to type it in full.", she thought smiling to herself. "How old fashioned I am.". And proceeded to the next task on her to-do list.


    We programmers have revolutionised and (in most cases) simplified the operating procedures of virtually every industry on earth. Except our own, which has gotten stuck somewhere in the 1970s, Same tools; same working procedures; same labour intensive, manual step 1; manual step 2; manual step 3, .... go to step 1; that we've being following for the last 30+ years. Except the list of steps has become longer.

    With Perl, we got rid of two steps (compile & link), but then introduced six more by way of compensation.

    There has to be a better way. There *is* a better way -- and no, I'm not talking about GUI-IDEs with code wizards. But certainly some of the functionality of the better ones would be a good start.

    • When I save a source file, it gets syntax checked immediately and automatically and moves the cursor in my editor directly to the line of the first error, if there are any.
    • When the compile is clean, it puts it straight into the CVS-equivalent and then invokes the test suite.
    • If a test fails, the test suite stops, and the appropriate test file is loaded directly into my editor at the failing line with the failing output displayed nearby.
    • When the test suite passes, it installs the module automatically into the development library.
    • We can now switch to the source buffer of the program that uses it and try it out.

    And pigs will fly, world hunger will end and all will be right with the world :)

      There *is* a better way...

      How'd you do that?

        How'd you do that?
        • I develop my modules located within the site/lib structure.
        • I embed the tests within the module after
          return if caller; package main; # tests here

          Thus, when run as a script: perl \perl\site\lib\my\module.pm, the tests are run.

          My editor has the facility to run the current file supplying the full pathname. The results are logged directly into another editor pane.

          Clicking an error message that contains a line number switches me to that pane/line number (loading the file first if it isn't already loaded).

        • I don't use perl Test::* packages or prove etc, because they:
          1. Steal my stdout/stderr output;
          2. and/or futz with it in ways that prevent me from seeing it in real time;

            For example, prevent me from using ^S to pause the program run whilst I check things: Memory usage, open file and other OS handles; file output; etc.

          3. Require me to force fit all my tests in dumb boolean ok/nok outcomes.
          4. Seem mostly concerned with producing a bunch of meaningless statistics I have no use whatsoever for.
          5. Generally interpose themselves between me and my code, forcing me into a most unnatural, clumsy and laborious way of working for the sake of a set of 'benefits' that I do not see the value of.

        • Finally, if and when I get a module to the state where I think it might be useful to others, then I will consider 'packaging' it.

          At which point I will do the absolute minimum required to allow it to be uploaded to CPAN and installed via that mechanism.

          Prior to that point, the whole archaic, ill-fitting blib structure, and make/test/install working practice is nothing more than a drag on my time. A pain to set up; a chore to maintain; and little more than make-work to operate.

        • I do not currently use source control software.

          I have set up several different flavours of it here over the past few years -- svn; mecurial; darcs -- but as I tend to prefer not to collaborate with others, I find their benefits minimal and far outweighed by the affect they have upon my working practices and productivity.

          One day someone will write the perfect source control package and I will use it. Instead of forcing me to work to its agenda, path structures etc. it will fit to mine. It will run on startup and sit in the background with an icon in the task area.

          When I want to have it control something, I will pop up an explorer dialog and click on one or more paths in my file system. And then I am done. From that point on, it will monitor all those directories and when a new file (or directory) appears or a file within them changes, it will do its thing. And each time they change, it will do its thing.

          No further action required from me. Until I want to revert a file, at which time I'll click the icon, locate the file or directory I wish to revert and then it will allow me to click back through the changes made until I reach the point I wish to revert to. Click doit, and it will be done.

          Maybe I'll write it one day :) (And pigs might fly, world hunger will end and all will be right with the world :)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?

      One of your best.   “++

Re^2: Developing a module, how do you do it ?
by BrowserUk (Patriarch) on Feb 29, 2012 at 03:59 UTC
    You have to work harder so that you can make it easier.

    That's easier? Ug! What a palava. :)


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?

      "You have to work harder so that you can make it easier."

      Pretending to be clever (palava) while simultaneously failing to read the spirit of the language is what keeps you in robot mode, robot boy. What davido surely meant was to merely strive to make your life easier. To focus efforts in a valuable way.

      You use too many words, BTW. Here's yer gold star.

        failing to read the spirit of the language is what keeps you in robot mode, robot boy.

        No robots here. I don't use any of that shit those 'tools' or 'procedures'. I leave them to diskheads like you.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?