Loading ...
Sorry, an error occurred while loading the content.

Re: Declarative Logging (PED)

Expand Messages
  • MarvinToll.com
    The notion of Declarative Logging asserts that a well-designed framework must do more than report problems with exceptions. Or said another way, simply
    Message 1 of 9 , May 22, 2011
    • 0 Attachment
      The notion of "Declarative Logging" asserts that a well-designed framework must do more than report problems with exceptions. Or said another way, simply reporting problems with exceptions is a 30-year old paradigm that has limited the effectiveness of higher-order frameworks.

      A well-designed higher-order framework exposes a functional perspective to the developer during unit test creation. It anticipates the information desired (80/20 rule) without the verbosity of trace logging.

      This discussion is causing me to realize a different label for this capability is warranted:

      * Framework Functional Visibility
      * Functional Logging
      * Functional Declarative Logging
      * Visibility Logging
      * TDD Visibility Logging
      * Framework Functional Logging


      _Marvin
      PatternEnabled.com

      --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
      >
      A well-designed framework will report problems with exceptions.
    • Ron Jeffries
      Hello, MarvinToll.com. On Saturday, May 21, 2011, at 10:09:57 AM, ... I m not seeing how this is different from any other logging. Let s see if I understand
      Message 2 of 9 , May 22, 2011
      • 0 Attachment
        Hello, MarvinToll.com. On Saturday, May 21, 2011, at 10:09:57 AM,
        you wrote:

        > In other words, as we began thinking in 'sets of log statements'
        > (rather than levels) we have explored how the strategy can
        > compensate for that major objection in using advanced frameworks
        > that perform tasks historically coded in an application... that
        > is, they work great when everything works but I'm not always clear
        > what the framework is doing 'under the covers' when something breaks.

        > I'm curious... has anyone else been this deliberate in using this
        > technique? Have you been advantaged during unit testing?

        I'm not seeing how this is different from any other logging. Let's
        see if I understand the idea:

        There are various named sets of information that can be logged.

        Any of these sets can be turned on or off separately.

        I would imagine that this would be implemented by a set of (more or
        less) globally accessible logging flags, named by set name, and the
        code would be strewn with logging statements, each checking the
        appropriate set-name flag.

        Is that the case? Is there something else?

        Ron Jeffries
        www.XProgramming.com
        If another does not intend offense, it is wrong for me to seek it;
        if another does indeed intend offense, it is foolish for me to permit it.
        -- Kelly Easterley
      • MarvinToll.com
        Thanks for asking Is there something else to Framework Declarative Logging. a. If one studies the two examples provided an appreciation for the limited and
        Message 3 of 9 , May 23, 2011
        • 0 Attachment
          Thanks for asking "Is there something else" to Framework Declarative Logging.

          a. If one studies the two examples provided an appreciation for the limited and targetted type of information provided that is useful when implementing unit tests. This avoids "strewing" framework code with log statements - or having the console output strewn with the type of verbosity that occurs when trying to set log levels that are effective across multiple technologies.

          b. An unanticipated positive side effect has occurred. Our Global Java Community has a discussion board. We probably average at least 20 posts a day (many of which come from newer employees/contractors) that could be characterized as 'trouble-shooting'. Generally, if someone attaches their unit test and the console log with Framework Declarative Logging active there is a very good chance that someone in the community can quickly identitfy or postulate a solution. Since there is a consistent set of output across and within Frameworks the community gets accustomed to quick discernment. We continually mature the sets of declarative log statements so that they provide the key insight useful for writing unit tests.

          _Marvin
          PatternEnabled.com

          --- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
          >
          > Hello, MarvinToll.com. On Saturday, May 21, 2011, at 10:09:57 AM,
          > you wrote:
          >
          > > In other words, as we began thinking in 'sets of log statements'
          > > (rather than levels) we have explored how the strategy can
          > > compensate for that major objection in using advanced frameworks
          > > that perform tasks historically coded in an application... that
          > > is, they work great when everything works but I'm not always clear
          > > what the framework is doing 'under the covers' when something breaks.
          >
          > > I'm curious... has anyone else been this deliberate in using this
          > > technique? Have you been advantaged during unit testing?
          >
          > I'm not seeing how this is different from any other logging. Let's
          > see if I understand the idea:
          >
          > There are various named sets of information that can be logged.
          >
          > Any of these sets can be turned on or off separately.
          >
          > I would imagine that this would be implemented by a set of (more or
          > less) globally accessible logging flags, named by set name, and the
          > code would be strewn with logging statements, each checking the
          > appropriate set-name flag.
          >
          > Is that the case? Is there something else?
          >
          > Ron Jeffries
          > www.XProgramming.com
          > If another does not intend offense, it is wrong for me to seek it;
          > if another does indeed intend offense, it is foolish for me to permit it.
          > -- Kelly Easterley
          >
        • JeffGrigg
          ... I have reexamined your original post, which I assume contains the two examples you mention above:
          Message 4 of 9 , May 24, 2011
          • 0 Attachment
            --- "MarvinToll.com" <MarvinToll@...> wrote:
            > Thanks for asking "Is there something else" to Framework
            > Declarative Logging.
            >
            > a. If one studies the two examples provided an appreciation for
            > the limited and targetted type of information provided that
            > is useful when implementing unit tests. This avoids
            > "strewing" framework code with log statements - or having the
            > console output strewn with the type of verbosity that occurs
            > when trying to set log levels that are effective across
            > multiple technologies.

            I have reexamined your original post, which I assume contains the two examples you mention above:
            http://tech.groups.yahoo.com/group/extremeprogramming/message/156566

            However, I would assert that achieving this would require log statements (calls) in a number of places in the framework code. (Or strong AOP with tight coupling to the framework code's low level implementation details.) So I would side with Ron on that point.

            I do agree with you about your claim that your logging approach will avoid cluttering the console (or log files) with unwanted extraneous detail, while enabling extreme detail where wanted. But it still appears to me that this is a solution to the problem that your people don't really know how to use the existing logging frameworks properly. The most common logging frameworks already offer all of this functionality and more -- but only if you know how to configure and operate them effectively.



            > b. ... Generally, if someone attaches their unit test and the
            > console log with Framework Declarative Logging active there
            > is a very good chance that someone in the community can
            > quickly identify or postulate a solution.

            Yes. I would kind of expect that, at a minimum. That's how things work now out on the message boards with most frameworks and libraries now.


            > Since there is a consistent set of output across and within
            > Frameworks the community gets accustomed to quick discernment.
            > We continually mature the sets of declarative log statements
            > so that they provide the key insight useful for writing unit
            > tests.

            I see the above as evidence that you have good and useful corporate standards and norms, and that you're doing an effective job of responding to feedback and improving the usefulness of the libraries over time.

            But...
          • JeffGrigg
            ... When I try to imagine how this could help with TDD, I run into some problems: First, a well-done library to be used by others should have effective
            Message 5 of 9 , May 24, 2011
            • 0 Attachment
              > --- "MarvinToll.com" <MarvinToll@> wrote:
              >> Since there is a consistent set of output across and within
              >> Frameworks the community gets accustomed to quick discernment.
              >> We continually mature the sets of declarative log statements
              >> so that they provide the key insight useful for writing unit
              >> tests.

              --- "JeffGrigg" <jeffreytoddgrigg@...> wrote:
              > I see the above as evidence that you have good and useful
              > corporate standards and norms, and that you're doing an
              > effective job of responding to feedback and improving the
              > usefulness of the libraries over time.
              >
              > But...

              When I try to imagine how this could help with TDD, I run into some problems:

              First, a well-done library to be used by others should have effective documentation (probably including examples). It should be easy to figure out how to correctly use the library without having to run tests through it to find out how it really works. If a person has a problem using your library, and you can tell them how to correct their usage so that it works, but you can NOT point to published documentation or examples that show (the essence of) your correction, then your library is inadequately documented for 3rd party use.

              Second, if logging the parameters enables an expert to tell a beginner that the mysterious failure of the framework as caused by passing in an invalid set of parameter values, then I have to ask why the framework code did not throw an exception with a useful error message telling what combination of parameters is invalid.

              If the frameworks are failing in "mysterious" (to the new users) ways, given usage informed by documentation and examples, then I would suspect design problems in the frameworks, rather than a need for more logging and debugging tools.
            Your message has been successfully submitted and would be delivered to recipients shortly.