Almad

8 ms·

31.
by Almad 6y ago
I do completely agree. In fact, when people asked me for JIRA, I've always said I am happy to do it since it's a software designed for me, the CTO. Yet I refuse to do it to them, the ICs.
32.
by Almad 6y ago
> I need to keep track of the number of defects found in order to somehow measure the quality of my software and of my testing and to improve it. I would love if you could expand on that. Do you really need it? Is this more important tha
33.
by Almad 6y ago
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 essent
34.
by Almad 6y ago
Oh cool, didn't knew about it and it looks like it may be the sweet spot.
35.
by Almad 6y ago
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 peopl
36.
There Are No Bugs, Just TODOs(almad.blog)
510 points by Almad 6y ago|198 comments
37.
How to Survive a Day in Remote Meetings(almad.blog)
1 points by Almad 6y ago|0 comments
38.
by Almad 12y ago
Thumbs up!
39.
by Almad 13y ago
Writing JSON Schema by hand and embedding it into Markdown sucks. MSON provides a Markdown-compatible way.
40.
by Almad 13y ago
The spec proposal is here: https://github.com/apiaryio/api-blueprint/tree/resource-blue...
41.
by Almad 13y ago
If Apiary would want to lock you in, we'd hardly open-source the parser Iglo is based on and endorse Iglo itself ;)
42.
by Almad 13y ago
Close, if you replace the Swagger's WADL/JSON with Markdown.
43.
by Almad 13y ago
> 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 co
44.
by Almad 13y ago
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
45.
by Almad 13y ago
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. .
46.
by Almad 13y ago
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, debug
47.
by Almad 13y ago
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 w
48.
by Almad 13y ago
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
49.
by Almad 13y ago
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 su
50.
by Almad 13y ago
Hi, Lukas from Apiary here. May I ask what your use case for response replay is? Testing or debugging?
51.
by Almad 14y ago
Thanks for this awesome work ;)