esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <markus.koh...@gmail.com>
Subject Re: We are down to 4.6 Mbyte
Date Mon, 30 Nov 2009 09:44:00 GMT
Hi all,
I forgot to mention that we are still better than before.
I think with the textile formatter, we would be still at 90Mbyte, wouldn't
we?

Markus
"The best way to predict the future is to invent it" -- Alan Kay


On Sun, Nov 29, 2009 at 6:26 PM, Vassil Dichev <vdichev@apache.org> wrote:

> > I am sorry you feel embarrassed.  While bugs happen, your effective code
> to
> > bug ratio is quite excellent... and this is the kind of bug we like to
> have:
>
> Thanks for the kind words. I feel relieved we found the bug as well,
> of course, but the first reaction was mild annoyance that I caused
> some lost time debugging, including for myself. I just wanted to
> correct the others that "making ESME 5000 times better" is not the
> complete picture ;-) I didn't change the design or make significant
> refactoring, for example.
>
> I also wanted to tell my story as a learning experience for others-
> things don't always seem so straightforward as they seem. It's exactly
> as you said- people are often prone to jump to conclusions about
> Scala, Lift, REST, databases, cache, sessions, etc. It happens every
> day.
>
> It just occurred to me that we can add another point to our design
> philosophy page- measure and test extensively before making
> conclusions about the merit of a certain technology or pattern.
>
> > So, in the future, we definitely need more tests (both as part of the
> > development process and integration/performance tests).  We also need to
> > work together to address the results of the tests.  Results of a single
> test
> > should not be viewed as a repudiation of a design.  Tests should be
> > invitations to either fix a bug (as in this case) or in the event that a
> bug
> > cannot be fixed without significant refactoring, a reasoned discussion of
> > the merits and likely performance implications of another design.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message