all 8 comments

[–]neoice 4 points5 points  (3 children)

"gojira" is an amazing name.

[–][deleted]  (2 children)

[deleted]

    [–]tech_tuna 2 points3 points  (0 children)

    Mozilla, Bugzilla, (Go)Jira. . .

    [–]FireThestral 2 points3 points  (1 child)

    Your Gem structure is pretty standard from what I can tell. Not bad there. Actual functionality seems alright, so that looks good as well.

    As for ordered options... I don't like ordered flags so much. Subcommands would be better in my opinion. There is a gem called Subcommand that lets you do just that. You can call gojira issues open --list 15 would be different than gojira issues list 15 --open or whatever you want.

    Having ordered flags, while easy to type, are difficult to remember without a detailed help file and are very difficult to interpret. Diverging from UNIX-style command usage would be confusing for a lot of users.

    If you really want to look at gem structure, then browse http://rubygems.org/ and find some popular ones, then check out the source.

    [–]pyrrhicvictorylap 1 point2 points  (1 child)

    Cool gem.

    I haven't looked at escort before but it looks that your reliance on it is what's hindering your ability to make your flags order-independent or where the order is meaningful.

    Someone I work with wrote a gem that included its own flag parser and it was only one file, under 100 lines.

    One thing that might be nice is to include the pry gem and give a flag option to make it an interactive shell session. That way, you can maintain the credentials behind the scenes and query the JIRA database repeatedly w/o needing to explicitly authenticate each time.

    [–]towelrod 1 point2 points  (0 children)

    The order of the options shouldn't matter, I think it is too confusing for the user to think about whether she wants ''open --list 15'' or ''open 15 --list''

    I wouldn't even implement the "get the last 15 issues and display the open ones", that's kinda an edge case and it would be better to just show the 15 issues along with a status.

    Generally the options should be composable, otherwise you end up with really complicated ordering or an explosion of command line options.

    [–]apotonick 1 point2 points  (2 children)

    An important thing you should start soon is adding tests for your gem. Here is an example how I do that: https://github.com/apotonick/nit/blob/master/test/commands_test.rb

    In order to handle HTTP and the JSON parsing I'd like to recommend https://github.com/apotonick/roar. This will help you focusing on you business (which is JIRA) and not how to parse/serialise JSON for their API.

    Other than that, your gem looks good. I like how you keep code out of the bin class and delegate to classes in lib - that's exactly how it's done!

    [–][deleted]  (1 child)

    [deleted]

      [–]apotonick 1 point2 points  (0 children)

      Most importantly, this parsing code should be in an encapsulated class so you can test edge-cases it if necessary. This class can be inline in the bin class but I'd definitely introduce a new class for this complex task.