TL;DR
ZJ has been run through the JSON Test Suite at the recommendation of Michał Muskała, patched for compliance to all the cases required (and many optional behaviors), and now updated to v1.0.1. Complete results on this ZJ wiki page.
Story
When I wrote ZJ my intention was only to scratch my own little itch: I needed a tiny, portable, single module JSON encoder/decoder for use on a relatively restricted set of data. I wanted a particular mapping between types, and writing it to work the way I wanted was easy.
I announced it when I felt meaningfully “done” because I thought someone else might like it. Some did. Some had suggestions. Some folks wondered where the tests were or if I was going to include any. I didn’t give these things much thought because it did what I wanted it to do already.
But then Oleg Tarasenko — someone I know well, have worked with in the past and respect very much — made a public query. In short, “Hey, what’s the plan with this? I want to use it, too.” Well crap. I don’t really have the time — or rather, I have other things I’d rather spend my time on but it’s Oleg and so I suddenly care again. So now I’m roped into something — maybe not hand-writing a bunch of tests or cranking up PropEr (which I’ve never been good at teaching how to create structured string input like JSON), but since the wonderful JSON Test Suite project already exists I can at least validate it as a JSON decoder using its pre-built example data.
With everything fresh in my mind it only took a few hours to clean everything up to the point that ZJ is actually now fully compliant with all the “must” features, many of the implementation specific features, and a few extensions that are technically illegal but occur frequently in practice.
That’s the sort of thing that happens when you share you work. It starts off as a “works for me” tool, and then your friends get a hold of it. Because you’ve known them a while and trust them you care a lot about what they have to say — even when they are just making gentle recommendations (or maybe especially when they are making gentle recommendations). The thing is, your friends are your friends because they have your best interests at heart, and in a software community just as in a neighborhood community very often your best interests are also their best interests. In fact, having another option for JSON parsing is better for everyone because there really is no One True Mapping, and it is especially good for everyone if a core piece of generic infrastructure has as permissible a license as possible (thanks, Marc) and the project can verify its claims to correctness — or at least vet its level of wrongness.
Zj is a tiny project, but even such a small project demonstrates the positive dynamic that exists among people within a community. So thanks Oleg Tarasenko, MichaÅ‚ MuskaÅ‚a, Loïc Hoguin, and others who took the time to discuss the vagaries of JSON and prod me a little to clean things up a bit more. I’m much happier with v1.0.1 than v1.0.0 (and will like v1.0.2 even more because of this and that).
Appeal to New Coders
Joe Armstrong convinced me about two years ago that it was better to release half-grown ideas to let them germinate and grow in the light of the sun than rot and be forgotten in the darkness of obscurity and personal temerity. Once again his position is validated. If you’re just getting into FOSS for the first time, release stuff. Don’t pester folks about it, but do announce your work so that eyes other than yours can get on it. Nothing but good comes of that (but sometimes it can be embarrassing — because you’ll occasionally be wrong, or lazy, or wrong because you were lazy…).