The vCard 3.0 validator is ten years old. The standard has moved on, Python has moved on, and I’d like to think I’ve learned a thing or two as a developer. But I’m not working on any vCard validators, and probably won’t be for the foreseeable future.
Maybe I’m suffering from second-system syndrome, but I’ve tried to reboot the project at least three times now. The Python code isn’t very elegant, fast or well tested. I set up skeletons in Java version and Rust, both excellent languages. I tried defining an ANTLR grammar. But I’ve got nothing to show for any of that. The main problem is motivation: vCard 3, 4 and jCard are incredibly out of date, to the point where writing a parser is equal parts painful and boring.
And now, because the Internet needs more opinions (and standards): a human friendly address card format is possible. vCard/jCard is not it. When someone brave and tenacious enough to take this on comes around, I really hope they take at least the following into account:
Use a popular, existing serialization format. JSON won in this space. It’s not perfect, but it’s here to stay and it’s a good compromise between human and machine readable.
Don’t create another jCard. If you were developing the world’s first address card format, what would users and developers want to see?
Conversely, vCard did many things right. UTF-8, base64 and ISO dates are definitely good things.
All caps is hard to read. Don’t shout.
Don’t limit (or even recommend) a line length or line splitting scheme. Address cards shouldn’t be inlined into emails or documents any more than CSV files.
Dictionaries (as in associated key/value pairs) are useful. Use them.
Lists are useful. Use them.
Preferred name should probably be the only required name field.
Time zones are not UTC offsets. I do not live in time zone “+12:00”, because that offset changes twice per year. I live in time zone “Pacific/Auckland”. This can be the difference between being on time and wasting everybody’s time.
Allow linking to photos. Sure URLs are ephemeral, but so is basically everything in an address card.
Any property not in the standard should simply be ignored, as long as the entire document is still a valid instance of the serialization format.
Internationalization and localization are complex but important.
What will such a standard look like? Maybe something like this will be possible:
I have bought many useful tools in your shop, and got very good service every time. But today I got a nasty surprise. I bought a Fuller Revolving Punch 200mm in order to punch some holes in some nylon fabric. Maybe the cutting tubes are made of “strong carbon steel” as you advertise, but the rest of the tool seems to be made of wet paper. I was able to bend it out of shape, squeezing the handles together until the metal bulged at the joint. On the very first go. With one hand. And I’m a software developer, not a body builder. The tool was unusable after literally 10 seconds.
Anyway, I was very annoyed at the quality, and wanted to post a review. And this was where I got really very annoyed, for two reasons:
Your review form displays a warning to “disable any ad blockers, which can prevent successful review submission.” No, that’s not how computers work. And if for some bizarre reason you’re submitting reviews through one of your ad providers you probably want to review your review code. And as warned, yes, indeed, I was not able to submit my one star review.
Most free and open source projects these days have plenty of documentation for producing a good bug report. This is really helpful, and we should continue improving our reporting tools and documentation. There’s a special warm feeling following the submission of a bug report with exact version numbers (of course the most recent stable), idiot-proof steps to reproduce, anything relevant from /etc, /proc and env and maybe even a core dump. Many projects will answer these quickly and either repair the defect or explain where you went wrong in assuming how the program should work. FOSS at its finest, and respect all round.
There is a different sort of warm feeling when you slowly realize that the hours you spent figuring out how to reproduce, collecting all the relevant data, and writing the bug report were wasted. Because nobody is ever going to fix it except by accident, and you are left with the choice between a) spending days, weeks or months accumulating enough context to fix it yourself, b) spending days, weeks or months replacing it with something different which has other, unknown, trade-offs or c) give up and do something else.
It’s important that we as a community come up with ways around this. Respect needs to go both ways – if you expect your users to follow procedure, don’t waste their time when they do. If bug reports are left unanswered, please let users know why before they waste time.
Nobody is interested in the printing subsystem? Ask for someone to take over, and let people know when reporting that such and such issues are unlikely to be solved any time soon. You’ve moved on and don’t actually want to work on the project anymore? Mark it as abandoned. You’re overworked? Recruit some help. Or if none of these sound attractive, you could charge for support or simply close the reporting system. Really. A strong community will find a way, but having a communications black hole is a recipe for a lot of bad blood and unnecessary negativity to enter into it.
Other than this, what can we do? Some automation might help. Bug reporting tools can easily produce statistics about the mean time before getting an answer, for example. Some tools encourage feedback about whether the answer was useful. How about displaying a summary of the responses? In what other ways could we save everybody time when handling bug reports?
| 1. List files |
| 2. Show the current time |
| 3. Show Top |
| 4. Quit |
Enter your selection:
Even if you are a banker, travel agent or a medical doctor I would argue never. These groups are unfortunate enough to still have to use arcane command line interfaces to do unspeakably complex things like recording last week’s hours or reserve a ticket to your home town. But none of these systems are razor thin wrappers for simple shell tools – they are that way because they are really hard to replace. And more importantly, no employer is ever going to ask anyone to make a menu based command line UI for their shell script. It just doesn’t happen anymore. It is not a valuable skill. ASCII art is recreation, not work. So the time spent fiddling with echo and read is wasted, and could be put to better use.
There are many generally applicable skills you can teach shell newbies:
The Unix philosophy: writing programs that do one thing, that work with other programs, and that handle text streams. An hour of cobbling together a pipeline of grep, cut and a light sprinkling of sed can save days or weeks of data processing which might take a week to write in Python or six months in a spreadsheet.
On the flip side, they should know the limitations of the shell. Why while read is several orders of magnitude slower than other language equivalents. Why writing secure shell scripts is basically impossible. Or why big shell scripts are a maintenance nightmare compared to other languages.
Which tools are available to do what. There are so many useful tools you could probably spend a week full time just touching briefly on each of them. Check out for example BusyBox for a set of generally available tools.