Almad

This analytical approach is exactly what I disagree with.

> A good practice is to fix defects before adding new features, as far as possible

This is the approach I describe as "bug is a proxy for priority", where you are essentially saying it's "highest". It is a good approach in theory, but just ignores business realities.

It also means people will try to disguise feature requests as bugs in order to get a priority.

> Assigning a priority makes sense because it helps setting the ticket's position in a queue

Except if it's numerical, then over time, you can safely ignore everything that's not P1 and you have few dozens/hundreds of unprioritized tickets.

> Severity is not the same as priority.

I know. Why is it important to make the distinction though?

> The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.

Agreed.

> You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.

Well, if dev is a factory worker turning inbound tickets into outbound features, yeah, cool, this works.

I am yet to see this in practice. Team (or at least team lead) is taking active role in the managing cycle and this is exactly what renders a lot of your points at least duplicit.

(But you have a lot of good points about assumptions about team organization that should be mentioned)

Oh cool, didn't knew about it and it looks like it may be the sweet spot.

In my experience, the relative queue _is_ helping with that since you can be explicit. If SEMIEB is really more important than SIEB, it's fair to switch—but it should be done as a relative comparison / override. I mostly saw people pushing SEMIEB without being aware what they are pushing down.

Although I would agree that if you have to reshift on hourly basis, this sounds more like oncall than normal dev work :)

Agreed on "on the top" not always being viable / feeling like it, but it helps when you go top-to-bottom consciously as opposed to randomly.

Thumbs up!

Writing JSON Schema by hand and embedding it into Markdown sucks. MSON provides a Markdown-compatible way.

The spec proposal is here: https://github.com/apiaryio/api-blueprint/tree/resource-blue...

If Apiary would want to lock you in, we'd hardly open-source the parser Iglo is based on and endorse Iglo itself ;)

Close, if you replace the Swagger's WADL/JSON with Markdown.

> Your developers suck if they can't debug the freakin' API they are supposed to be building. You're doing it very very wrong if you need wireshark or HTTP proxies to debug your code.

And what if I am using a library to connect to a 3rd party service (i.e. github) and I'd like to debug my API calls?

Hi, there are some 3rd party works in progress and we will promote them. We are leaving this to community though, as respective languages/frameworks are best supported by people that use them.

And as said -- Apiary is more about design than documentation and writing blueprint should take place before writing code. A lot of things is lost when it's the other way around.

I do believe we'll be providing on-premise instances as Github does in the future.

However, as github hasn't provided this from year one, so are we. Choosing priorities is hard in startup and on-premise takes a lot of resources.

...which is what seed is for ;)

Meanwhile, you can still use our format separately from Apiary SaaS. Please take a look: http://apiblueprint.org/

Hi,

thanks!

Yes, it is both and yes, you can add it to your source tree through our github integration.

Our idea is to have a human-readable, human-writeable DSL to describe your API. From there, we generate both documentation, mocks, debugging proxy and tests.

You can use it to describe your existing APIs, but in my mind, our biggest value lies in conversation around API design that happens before you start implementing.

Hope this helps!

We do have some prototypes, but we are yet to venture beyond scaffolding..and honestly, we are more focused to provide basic, universal tooling and let respective communities to handle their-favorite-language/framework bindings.

From what I tried, it is fairly easy to get "almost there", but the remaining 10% is dealbreaker. If too much editing constraints are placed on resulting application, it feels odd and it's easy to break them and thus diverge from original blueprint.

One possible approach is to maintain original blueprint, then say "Let us implement" and completely blueprint as "primary data source" into scaffolded application -- into module/method docstrings and start generating blueprint back from there.

However, we are yet to find something that feels unobstrusive and natural during whole development cycle. Suggestions certainly welcome.

Disclaimer: I work for Apiary

I'd say that just for getting started, hosted solution works better ;)

Anyways; we love OSS and we are gradually open-sourcing more and more from our toolbelt. Parser is completely open-source (current one https://github.com/apiaryio/blueprint-parser as well as the upcoming version https://github.com/apiaryio/snowcrash ).

More is coming soon ;)

(But yes, if you prefer writing JSON over Markdown...)

This is available as closed alpha, but we working hard on extending this functionality to be actually usable (read: scenarios, because you usually need to do at least some sort of "setUp").

If you are interested in this, please subscribe to http://support.apiary.io/forums/120125-general/suggestions/3... and we'll let you know once it will be available for testing.

It's now one of our three running projects and you're gonna love it ;)

Hi, Lukas from Apiary here.

May I ask what your use case for response replay is? Testing or debugging?

Thanks for this awesome work ;)