News for hackers. Stuff that matters.

marbemac

Re:AutoRest: OpenAPI Specification code generator on Friday October 06, 2017 @01:30PM (#15418562)
Hi there, I'm the founder of a company called Stoplight, and we have a purpose built solution for this very use case. You can read more about it here: https://stoplight.io/platform/scenarios.

Basically, you setup test cases for your API(s), and we automatically contract test the inputs/outputs of the requests against your OAS specification where possible. If anything does not validate against the schemas defined in your OAS specification, the test will fail with descriptive errors. If your OAS is ever updated, those changes will automatically work in the tests, since the tests are just referencing the OAS spec (not duplicating data from it).

A couple more things:

- You can create these tests with our visual UI, or write the underlying JSON that describes the tests by hand.

- You can run the tests inside of our UI, or install Prism (our command line runner) to run them completely outside of Stoplight (CI, terminal, etc).

- We plan to support OAS3 later in Q4 of this year.

We live and breathe API tooling and specifications. If you have any questions about process, our product, API strategy, etc, happy to chat - just shoot me an email at marc [at] stoplight.io!

Re:Show HN: Prism – The perfect OAS (Swagger 2) companion on Wednesday March 23, 2016 @07:25AM (#11343474)
Hi HN, we originally developed this for internal use over at StopLight, and realized that a lot of the tech could be re-purposed and re-packaged into a nice little complementary tool for anybody working with Swagger. Thanks for taking a look - happy to answer questions, and eager to hear any feedback!
Re:Show HN: Stoplight – Visual API Tooling on Thursday February 18, 2016 @12:17PM (#11127367)
Really great feedback, thanks! We've heard that the main navigation is confusing, and are working on improving it as I type this. Could you send me an email marc @ stoplight.io? I would love to bounce some of our ideas off of you, and hear what you think.
Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @03:28PM (#11112899)
Interesting, query params should be published - could you send me the link to the docs you published?

In the "settings" tab for each endpoint, you can mark which security schemes apply to the endpoint. It's kind of hidden, we're moving it to the general definition tab. Also, that info will be exposed in api-docs (which security schemes an endpoint requires/supports) in an update later this week!

Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @03:10PM (#11112784)
Astute catch! We're actually tracking this issue internally already. We'll be beefing up that generator to aggregate multiple values for the same property, when it's an array of objects. Look for that in an update in the next 2 weeks.
Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @02:40PM (#11112551)
Great question! We are considering adding first class support for Blueprint. In the meantime, we recommend converting first to OAI/Swagger with the awesome tool over at https://apitransformer.com
Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @02:36PM (#11112525)
You can invite team members to your workspace in the API Designer, and only they will have access (read or read/write) to the APIs in that workspace.

From the API Designer (which is private), you can optionally publish any of your API versions out to api-docs.io, for public consumption. You don't even need to publish your entire API definition out - you can mark which endpoints/models are private versus public. Only the parts of your internal docs marked as public will be published out :).

Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @02:26PM (#11112444)
It really is free, for individual use, forever :). Pricing starts at the team level - at $8/month/member. We're also introducing cheaper, annual pricing soon.

The hosted documentation integration is completely free - we have a paid option coming soon, that adds custom domains, theming, analytics, etc.

Eager to hear what you think - let us know!

Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @02:20PM (#11112396)
Awesome, let us know if you run into any issues, or have suggestions - we're here to help. You can reach me directly at [email protected].
Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @02:20PM (#11112392)
Hey there, nope! They are one of our beta customers though.

They blogged about their experience so far with our tools here: https://sendgrid.com/blog/using-a-prototype-as-an-api-produc...

Re:Show HN: Stoplight – Visual API Tooling on Tuesday February 16, 2016 @12:17PM (#11111402)
Hey! Marc MacLeod here - founder. Basically, you put Prism between your API consumer (mobile app, website, integration tests, library, curl request, whatever) and the API itself.

Prism processes the traffic that passes through it, and generates your spec code from that. It can identify dynamic parameters in the url, build json schemas, etc.

Here's a little post + video we put together: https://medium.com/oh-what-a-wonderful-web/how-to-generate-2...

And another, demonstrating a slightly different process of generating spec code from the Peach mobile app API traffic:

http://peach.api-docs.io/1.0/welcome

Amongst other things, it's about 1/4 the size, and sticks to plain JS for those not familiar with ClojureScript.
I believe the idiomatic way to use this library is to treat the tree as an immutable structure. When used this way, it supports the React Immutability Helpers, and the PureRenderMixin. If you treat it as immutable and use the PureRenderMixin, you won't run into the re-render multiple times issue described above.

See this issue for more details: https://github.com/Yomguithereal/baobab/pull/74

Re:Ask HN: What code do you frequently read? on Thursday March 05, 2015 @08:43PM (#9155095)
I beg to differ. For example, reading the Go source is extremely useful both to learn idiomatic Go, and for reference.
Re:Now available: auto-scaling PostgreSQL deployments on Monday January 05, 2015 @04:33PM (#8841332)
Ah I did not realize that it's not on EBS (aws announced SSD EBS last June so I thought perhaps you guys jumped on that opportunity). What's the max # of connections? Does it scale with storage as well?
Re:Now available: auto-scaling PostgreSQL deployments on Monday January 05, 2015 @04:11PM (#8841186)
First of all, this is great news - I use compose for Mongo and have been waiting for a PostgreSQL option. However, is the ram allotment similar to that given in the Mongo deployments - 1/10th storage? So, about $125/month for 1GB ram and 10GB storage. Making the obvious comparison to Heroku (which, granted, doesn't offer the autoscaling feature), Compose looks quite expensive. At a glance, it seems that on Heroku one gets the same amount of ram and 6 times the storage for less than half the cost of Compose.
Re:What is Meteor.js? on Monday December 22, 2014 @12:45PM (#8784086)
I've built several apps with Meteor, and so far it's been fantastic. Development is lightning fast, the interface is snappy enough, and it's easy to maintain. My latest Meteor app is online at http://stoplight.io.
Re:Thepiratebay site is up, but without search engine on Monday December 22, 2014 @11:21AM (#8783654)
What's over at thepiratebay.cr? Seems like new torrents are being added, works fine, and search is enabled.
Re:Show HN: DayJot – Another open-source alternative to OhLife on Wednesday November 26, 2014 @02:18AM (#8661404)
It does accept multiple emails per day, however it doesn't distinguish within a day. If you send it more than one email per day it will append the text of the email to the existing entry for that day.

Perhaps you could create an account with your work email, and one with your personal email? I hope I understood you correctly!

Re:Show HN: DayJot – Another open-source alternative to OhLife on Wednesday November 26, 2014 @12:13AM (#8661174)
You can choose which days of the week, and at what time each day, the service send you reminder emails. As for photos, that's next on the list of features!
Re:Show HN: DayJot – Another open-source alternative to OhLife on Tuesday November 25, 2014 @10:30PM (#8660985)
I'm open to anything you'd want to contribute, so long as it doesn't compromise the private nature of the service. Fork away! I'm available if you have any questions about the codebase, or need help getting started.
Re:Show HN: DayJot – Another open-source alternative to OhLife on Tuesday November 25, 2014 @07:19PM (#8660597)
Thanks! Looking forward to seeing what you put together. Are you working on the Rails side or the Ember side (or both)?
Re:AWS CodeDeploy on Wednesday November 12, 2014 @01:51PM (#8597380)
How does this compare to Deis? Does it serve the same use case, albeit locked into AWS?

Discussion on Deis from yesterday: https://news.ycombinator.com/item?id=8591209

Re:Show HN: Assembly – Help build a product, get a share of it on Thursday November 06, 2014 @02:25PM (#8569125)
Cool idea, but at this point it doesn't seem like a reasonable option for new developers coming into projects.

For example, I picked Coderwall, which is the 2nd project listed on the discover page. There are 11 tasks right now, with a total coin bounty of about 25k. Looking at the ownership, there are about 14.3 million coins allocated, owned primarily by one guy. SO, if I clear out ALL of the tasks for Coderwall, I will receive coins worth ~0.0017% of the project. If 100% of the stated $30k revenue is distributed to coin holders (which it won't be.. gotta pay for servers, etc), I will receive about $50/month for clearing out all of their tasks.. I understand that revenue might grow, but that's a very small amount nonetheless.

Maybe I'm missing something? Is that about how it works?

Re:Weekly Coding Interview Problems by Email on Wednesday November 05, 2014 @10:05PM (#8565592)
Typo in the first sentence..

"We collect the most popular real-world coding interview questions and carefully craft wrteups that are ridiculously easy to understand."

wrteups = write-ups.

In my app I close the connection when the app is backgrounded, and reconnect when the user resumes using the app. Meteor automatically deals with any changes that occurred while the connection was offline. In short, battery life has not been an issue.

Older »