You sure that's AMQP 1.0 or 0.9? I say that b/c ActiveMQ is AMQP 1.0 (http://activemq.apache.org/amqp.html) and RabbitMQ is probably running 0.9 unless you are using the experimental 1.0 plugin.
Nearly all the libraries working with AMQP 0.9 will not function when targeting an AMQP 1.0 service.
So, get in your car at 7 am to get to work by 9 for your daily stand up. You then work your 9 - 10 hrs., because it's a good day and no major deadline looming. Then you get in your car at 6 pm (you skipped lunch or ate on the run) for your 2 hr drive. Instead of going home you go to the gym for a much needed workout, but sadly when you leave it's now 9:30 pm. Hopefully, you'll be able to grab some fast food b/c you have no time for a real meal. Finally, you get home at roughly 10:15. You are just in time to catch a show, set the alarm, climb into bed and get some zzz's before starting the grind tomorrow.
Disclaimer: I'm not for or against the use of cucumber.
The second claim against cucumber / gherkin is not it's fault, it's the toolset's fault. Using grep to find your step definition is not very effective.
If you use a tool like Rubymine, you can jump directly to the applicable step definition through one key combination.
In practice, you'll find grep is in the toolkit of far more Ruby programmers than the IDE Rubymine. And with good reason!
The real problem is step definitions with regex in them. You don't need to do this. Steak was written to avoid this problem: https://github.com/cavalle/steak
But the underlying issue described in this post is still valid - Cucumber is an unnecessary layer because it adds no value that you don't get with Capybara and your favourite testing framework.
Thank you for the heads up about ruby devs liking *nix tools and not ide's.
The fact of the matter is grep is a poor tool to try to find your step definitions. There are tools out there that are much better for such things, vim with http://www.vim.org/scripts/script.php?script_id=2973, or an ide or <your favorite tool>.
You could make the claim that any abstraction is unnecessary if you see no value in it. It doesn't mean others will not find value in it.
Personally, I find it quite easy to understand and convey to non-devs the stories told through gherkin. That is part of the value prop for me.
If no one is reading them but the devs, I'd rather use something other than gherkin.
I still get a kick out of seeing apps running in the browser. It blows my mind. Oh, quick link if you want to try a few https://www.cisimple.com/featured_apps.
This is really starting to sound like what java / .net were doing with wsdl code generators via soap.
Devs that integrate with multiple apis know there is a problem with the wide range of implementations, from authentication to communication patterns. This makes it a pain to integration with multiple service providers. Without some form a standardization you must have an intermediary library to provide an abstraction.
Are we doing it right?? The community has recognized the problem of non-standard lightweight services to be widespread enough to create a tool to standardize communication with them.
I think separating the documentation step (machine-readable or not) from the actual development process is what makes the entire process painful. It means you have to have parallel development or things get out of sync pretty easily.
I've sketched out some work on using OPTIONS and having the code introspect itself to describe how to interact with the API. Basically with good validation, error messages, and solid/consistent naming conventions, you can take it a long way before you have to step out of the development that you're already doing.
There's plenty that API providers can do to make things saner for all of us, and themselves. Problem is, many (if not most) of them don't seem to care enough. As users of APIs we are their customers, and we outnumber them. Let's find a way to show them the benefits of making our lives easier.
This is a good point that we discussed, too. While Hal, like HATEOAS is very interesting and definitely a simplification that's necessary to make our lives better, we're aiming at something different: we're trying to describe existing (ReST) APIs in a way that a single library using a Factory Pattern can turn into connections that you as a developer can use to work with that API.
We settled for the swagger format, because its very flexible, human-readable and honestly can be turned into very nice looking documentation pages.
I'm not knocking what you are doing. I love the effort, and I think it will improve developer experience for the most part. I'm just raising the questions of "Should we have to do this?" and "Didn't we go down this path before?".
The thing that the library is doing, is now replacing a wsdl with an expert that develops a swagger document. This to me sounds problematic. The wsdl had some idea of versioning of the contract, and was dependent on the developer of the service to update the wsdl with updates of their service.
I imagine, and correct me if I'm wrong, but the swagger doc will have to updated by the expert per release of the service (obviously, pending any implementation changes of the service). This actually puts the consumers of the framework at risk of incompatibility via 1., the developer changing the service, and 2., the expert not updating the swagger definition upon 1. Is this accurate?
Please don't take this as me saying that I'd like to go back to wsdls. That is certainly not at all what I'm advocating.
We do intend to version the swagger docs, so that a specific description will point to a matching version of the service. A new version of the doc will have to be created whenever the service is updated. Our goal is to get a large developer community involved, at which point the API owners will find it worthwhile to do this themselves.
MVC may not be a solid pattern for a client side framework. It makes sense to contain some semblance of state with in the presentation layer on the client side, rather than working with a stateless MVC pattern.
IMO MVC on the client side is just a carry over from people who were experienced in writing web apps who wanted something that felt familiar on the client side. It's a leaky abstraction at best.
I agree with this. I'm not particularly interested in client-side MVC frameworks because it wrongly trivializes the server component, and technically speaking any javascript running on the client is part of the view.
I'm not sure what the right answer is, but I certainly feel like the race for rich client-side apps had too many frameworks settle on MVC without thinking about the bigger picture.
Nearly all the libraries working with AMQP 0.9 will not function when targeting an AMQP 1.0 service.