Re:Show HN: ppl - The Command Line Address Book
by contingencies on Thursday December 20, 2012 @11:29AM
(#4948499)
Things I like are codename-per-contact and the fact that there's a command line tool supplied with exit codes.
I don't like almost everything else, including the syntax ('ppl phone alice 12345' feels icky and against-the-grain to me), the use of (slow?, and) dependency-heavy git, the redefinition of on-disk format, the lack of formal data-description, the lack of customization for such, trying to do more than one thing well (versioning/diffing/merging/branching = git's job, not yours... keep that out of scope), the lack of meaningful, nontrivial use cases. (What problem does this solve, in the real world, except your itch? If you'd included GPG key, included autopopulation support based on directory lookups or some mature script system, helped people migrate contacts off Gmail and in to private git-based cloud hosting with hooks to preload their FirefoxOS beta with privacy-enhanced contact solution, I would have been more impressed)
Why not do something different like 'ppl alice --phone=12345' (set) and 'ppl alice --phone' or 'ppl phone <alice' or 'ppl -f %phone <alice' (get). In general taking input via pipes is better than adding mandatory arguments.
Better yet, stuff the command line syntax thinking entirely for the moment and focus on JSON. Spec the JSON Schema instead of the interface to it, focusing on data, and how it might differ in different use cases / environments (eg. countries). Some argue that if you get your understanding of the data right, the program is right.
By way of contrast, right now I suspect a lot of the hassle of such a program is going to be things like (0) trying to do too many things, succeeding at none of them (1) yet another definition of what a phone number, address, etc. is that is not going to work for everyone (2) some developer second-guessing what i, the user, want or have to accept in terms of duplicate input, normalization, whitespace significance, etc. (3) non-i18n interface (4) let me smoke my unixpipe, dammit!
I dunno, I'm just playing devil's advocate, but there's probably some value in that rant.
I don't like almost everything else, including the syntax ('ppl phone alice 12345' feels icky and against-the-grain to me), the use of (slow?, and) dependency-heavy git, the redefinition of on-disk format, the lack of formal data-description, the lack of customization for such, trying to do more than one thing well (versioning/diffing/merging/branching = git's job, not yours... keep that out of scope), the lack of meaningful, nontrivial use cases. (What problem does this solve, in the real world, except your itch? If you'd included GPG key, included autopopulation support based on directory lookups or some mature script system, helped people migrate contacts off Gmail and in to private git-based cloud hosting with hooks to preload their FirefoxOS beta with privacy-enhanced contact solution, I would have been more impressed)
Why not do something different like 'ppl alice --phone=12345' (set) and 'ppl alice --phone' or 'ppl phone <alice' or 'ppl -f %phone <alice' (get). In general taking input via pipes is better than adding mandatory arguments.
Better yet, stuff the command line syntax thinking entirely for the moment and focus on JSON. Spec the JSON Schema instead of the interface to it, focusing on data, and how it might differ in different use cases / environments (eg. countries). Some argue that if you get your understanding of the data right, the program is right.
By way of contrast, right now I suspect a lot of the hassle of such a program is going to be things like (0) trying to do too many things, succeeding at none of them (1) yet another definition of what a phone number, address, etc. is that is not going to work for everyone (2) some developer second-guessing what i, the user, want or have to accept in terms of duplicate input, normalization, whitespace significance, etc. (3) non-i18n interface (4) let me smoke my unixpipe, dammit!
I dunno, I'm just playing devil's advocate, but there's probably some value in that rant.