I'm cool with that -- we're friendly with most of the other groupware projects out there.
Anyway, as some of you might know, pretty much every piece of non-Microsoft calendar software in existence makes use of libical, an open source library that exposes a set of data types and serialization/deserialization for the industry-standard iCalendar format. A few years ago, we got tired of seeing the proliferation of libical forks resulting from the original authors' lack of interest in maintaining it, so we asked if we could take over the project.
They agreed, and we've been un-forking it ever since. KDE (Kontact) finished first, Novell (Evolution) is just finishing up, Mozilla is on the way, Nokia and other organizations are now mainline contributors, and others have dropped their forks and gone back to the upstream. Our official build now ships with several major Linux distributions.
Ok, so that's a good example of an open source success story in its own right, but that's not what I'm here to talk about. I'm here to talk about Gren Elliot, who as far as I'm concerned is the best bug reporter I've ever had the pleasure to deal with.
On any given day someone is reporting a bug in an open source program somewhere.
My experience has been that the worst offenders just couldn't be bothered to RTFM and are simply unfamiliar with the basic operation of the software.
Then there are the bug reports that are actual bugs. If you're lucky, the reporter is courteous and complete (like fleeb) and writes up the report in the format of -- software version being used -- steps required to duplicate -- expected result -- actual result.
A really sharp bug reporter, if he/she happens to be a developer and has access to the source code, might also submit a patch that fixes the bug.
Gren did all of the above, and... AND... included a test program that demonstrates the bug. Run the test program, see the bug, apply the included patch, run the test program again, see the bug gone.
And he did all of this for several different bugs. Bless your heart, Gren.
You made my day.
Test programs are awesome, and they're used more than twice.
They're used every single time you make a change in that area of the code, to help with regression testing.
Of course, if you're only ever going to make two changes in that area of the code, well...
(Unfortunately, I don't think libical's regression suite has *ever* run 100% clean.)
But I hope you've added the two new ones?
Fr Aug 21 2009 07:53:20 EDT von IGnatius T Foobar @ UncensoredIf you have a regression suite then you can just add the test program to it. (Unfortunately, I don't think libical's regression suite has *ever* run 100% clean.)
Like the 2Megs static ram trick ;-)
Usually things like 'now that this is configurable, I better make a UI so somebody other than me can configure it.
-.- ashamed to admit that I do the same with the basic websites I build... my wife's company website is pretty-much band-aided together using iframe's and ../ file references...
Stephen D King
The Kings Photography
Usually things like 'now that this is configurable, I better make a
UI so somebody other than me can configure it.
You are very kind. Most people these days seem to be content with "it's configurable by changing this XML file"
You are very kind. Most people these days seem to be content with
"it's configurable by changing this XML file"
My years of experience has taught me not to write software that is fast, not to write software that is scalable, not to write software that is stable.
My goal is to write software that yields the fewest number of phone calls.
My goal is to write software that yields the fewest number of phone
That's a good idea. Let's discuss it during a conference call. I'll give you the bridge number and we'll pull in all of the stakeholders to coordinate the writing of software.
... and draw up a list of requirements, none of which make sense.
I shit thee not.
while we did lots of function pointers, theres just one place where I would compare them to virtual functions: the readloop. In all the other places I don't see how to do it with virtual functions or better with C++ language features.
The bugs we had with the readloop rework wouldn't have been there in C++ since you wouldn't be able to use the function of the object elsewhere, as we did in the summary and the smtpqueue.
All other function pointers are due to resolving a string from a table to an action to take.
Sep 10 2009 2:41am from dothebart @uncnsrd
while we did lots of function pointers, theres just one place where I would
compare them to virtual functions: the readloop. In all the other placesI
Ok, then you haven't started doing unit testing on a large scale yet, and you haven't gotten to the point where you are building mock implementations of core features (like the DB layer)
When you design for performance, you are basically writing assembler
code except it's in a high-level language.
But when you write testable code, you are writing exquisitely modular
code that makes very few assumptions about what it's interfacing with.
YES YES YES!
Now if people would only stop doing that. :-)
orientation and can optimize it for you. If you're using OO concepts,
it's really better to use a language that can express those concepts as
a first-class language construct and does not relegate them to the
... Like Objective C. <snicker> :-)