addcn

Optic YC (S18)| Product Engineers | Fully Remote

We're building the GitHub for APIs by helping developers collaborate at scale on their APIs. Our open source tools make adopting OpenAPI and API-first practices simple. Developers use Optic to document their API changes, review each other’s API changes during code review, and catch breaking changes before they reach production. Snyk and a growing number of teams uses Optic to deliver a great experience

* Lead the design, implementation and maintenance of core product features coordinating with the rest of engineering as necessary.

* Help define Optic’s product direction and how we can make APIs more accessible to everyone.

* Drive engineering standards, tools, and practices on a quickly growing team

hiring page: https://useoptic.notion.site/Optic-is-hiring-9af73ddc8fd4477...

github: https://github.com/opticdev/optic

There are no causes, just dynamics.

And Facebook and society are in one together. Society functioned ‘better’ before Facebook, so I’d start looking at the Facebook end of dynamic first.

QED.

There are no causes, just dynamics.

And Facebook and society are in one together. Society functioned ‘better’ before Facebook, so I’d start looking at that end of dynamic first.

QED.

Hey! few quick thoughts on this.

No API is static, so over time expect to add or deprecate query parameters even if can't conceive of needing changes today, tomorrow, or next quarter. Change leads API providers to relax validation rules on inputs as part of avoiding regressions. It's very hard to get all the users of a public API to update their usages, so hard rules like not allowing extra parameters are likely to break folks over time.

If it's an internal API with a dozen or fewer consumers you control, then go ahead, add some rules :)

I'm working on a new feature for the Optic project [1] that can tell you if a proposed API change will break any of your consumers -- sort of like an automated consumer-driven-contract-test.

[1] https://github.com/opticdev/optic

I’d love to try this and give you more feedback but I’m getting 404 trying to install the GitHub app.

I think it’s all about workflow. The closer you bring feedback to the developer, the more likely they are to follow guidance.

Linters and prettiers are a perfect case study. Saying don’t do X doesn’t work. But preventing you from doing your work unless you do X (and helping you do it) works really well.

We need linters for architecture patterns — but of course this is really hard to do in practice.

Static analysis is great here — it’s definitely a constrained domain where it could shine w/o many of the issues that defined it a decade ago.

I bet you could take this a lot further by incorporating a runtime component as well. I mean it’s a container — it’s meant to be incrementally built up and destroyed.

By looking at the state of the container before and after a line you could do so much.

i.e. This innocent looking apt-get install has the side effect of making X directory writable.

How would you articulate "the protobuf problem" to a gRPC novice like me?

Also re http/rest docs -- check out my open source project -- it's sort of like Git but for Rest APIs https://github.com/opticdev/optic

This is true. Not the sentence I expected to give me hope on a Sunday night, but it did.

This argument doesn’t hold though because a single bad actor who figures out how to spoof the interface has tremendous leverage to hurt a lot of people at once. And it’s likely they could leave a device at night and trigger it days or weeks later. One instance of this could literally cause enough public fear to get AVs banned for years.

I agree with OP that each car managing its own cameras and radar makes the most sense. Cooperation by way of individual optimization is the cornerstone of modern society and something we should absolutely imbue our autonomous vehicles with.

When this happened to me I got a ton of advice (similar to what’s been written by other posters) and it was all great.

But to make any of it to stick I had to stop thinking of my productivity as some intellectual problem and myself as the master of my attention.

You’re not in control of most things. You’re trying to steer an elephant. Accept it, it’s easier and it’s true.

Then — with a slightly more realistic view of yourself set up processes and guardrails to keep your brain in line. Stimulus control sounds like a good first step. Check out StayFocused for Chrome and then delete all other browsers.

Add or remove one thing a week until you’re where you want to be. Good luck.

I really wish the relationship was inverted. So I had a dashboard of every recurring charge in one list and I could cancel at will. More designed around me pushing funds to vendors than vendors pulling them from me.

Someone should make a digital first credit card optimized for the subscription world.

I spend a lot of time in all the major cities and what strikes me about the Bay Area is how geographically constrained the suburbs are. You basically get degrees of freedom to the South and North (and some in the East Bay) but unlike NYC you can’t spread out in all directions.

I’ve never formally studied this in detail but my intuition says geography led to many of the Bay’s housing and transportation problem.

When viewed through that lens this superhighway of Caltrain makes sense.

Not rocket science but thought I’d share.

Before I started Optic I watched 20 developers code for 1 day each. I kept logs of what they were working on and asked people to rate how they felt throughout the process. The 15/hrs/wk is a rough estimate of what we could automate. Our most avid users over the last month self report a little less but I think once we add better support for a few more things we’ll catch up.

I never thought to publish those results. Sounds like something people would be interested in?

Hey, founder here, thanks for checking us out. The demo video is a couple months old and since then we've gotten much closer to figuring out the best use cases after talking to users. Do you have any suggestions on the use cases you'd like to see the 'interesting features' put towards?

This is definitely the kind of product that takes several iterations to get right so thank you for following our journey.

Hey -- thanks for checking us out!

You're definitely understanding the premise of our parser. It evaluates a regex-like set of rules on an AST tree to match different forms of code. These rules can be recursive as you can see in the first example of our home page [0]. In that example Optic matches an express js route and the headers, parameters and responses inside it. The result is a nice json object with shape {method, url, parameters: [], headers: [], responses" []}. OOTB the JS interpreter couldn't do this because it doesn't encounter the calls to req.query.param_name until that code runs.

PG wrote about building the language/abstraction to fit your problem [1]. In an ideal world we all would do this, but in practice there's always a gap between our program and the abstraction we describe it in. Today that gap is only bridged by a human understanding the code. Until now...Optic is allowing us to programmatically deal with these implicit abstractions.

We believe most of the dev tools created over the next decade will be built on top of your code in a way that allows them to collaborate with real developers. To realize this world we need a programatic interface to read, generate and mutate code so we created Optic.

[0] https://useoptic.com [1] http://www.paulgraham.com/progbot.html

This is a perfect use case for async video. Nice work!

What’s the follow up look like? Can I comment on videos to ask questions or do you imagine that being done through existing channels?

Congrats! I feel like this is a modern approach to fulfilling the unrealized promise of the semantic web.

I've worked with a bunch of big companies and they have dozens or often hundreds of individual APIs and micro-services. Would it be feasible to deploy OneGraph in a closed environment like that? I can't think of a big IT department who wouldn't want to interconnect their internal services like that.

Congrats on all the new products! Somehow I missed a year of your releases -- my loss. I remember how transformative auto-layout was for my team when it came out. For the first time designers could, for themselves, grapple with the tradeoffs of different layout / resizing rules pre handoff. I think the unrecognized impact of tools like yours is that they give designers a playground to think about some problems in a more developer-like way. Regardless of how much of the code makes it into production I think that's a win for designers and their teams. Looks like timeline has the potential to do the same thing for interactions and animations.

You guys helped invent this space not too long ago and I'm curious where you all see things going long term?

Thanks for your kind works. I think I just heard someone whisper "memento mori".

If I'm understanding your idea, it sounds like you want to use a compiler to a) collect all the useful/best control flows into some kind of library that you then b) use to generate code when compiling any other language. Like an ouroboros of compilers. Then you want to have some simpler programming interface on top of that which can be expanded into great code?

In my notebook I've been calling Optic an up-piler because it turns raw code from multiple languages into the same higher level abstractions. So on a spectrum of processor instructions -> ideas it's further to the right than the host AST. Sounds kind of similar to what you've been working on for part A.

What confuses me about your idea is how I as a developer would benefit from it? Are you a drop-in compiler that will compile my code into something 'better'? Can you just take some code I wrote and refactor it into a better format that does the same thing as before? Will the way a project compiles change over time? I'm not sure if I want the nails in my log cabin going form 20mm to 30mm overnight. Shouldn't break anything but you never know...

Happy to chat offline sometime aidan@useoptic.com Think we'd have some fun convos

Thanks for your feedback. When we ship a scriptable version Docker seems like a great choice for wrapping it. I'll add an env variable for ya :)

The JVM is somewhat allergy inducing, but I think Graal may solve a lot of these issues. Optic is written in Scala because a) it's a great functional language and b) the JVM is super portable. If we can get Graal working nicely in our builds, binary sizes should drop markably and performance should improve.

I agree, two-way crud is the best starting point.

Optic React / JS for all its GUIs. We’re planning to have microeditors that pop up and help you work with specific kinds of code so this might just run from within Optic somehow.

All fun ideas to brainstorm. Let’s take it offline. Email me at aidan@useoptic.com

Excited to chat / collaborate

One of my personal favorites was episode 11 about how React was created. The dawn of a new abstraction is always a good story. http://futureofcoding.org/episodes/11-how-reactjs-was-create...

Got it. We’re using Gatsby and there’s a rewrite rule on our CDN. I’ll take a look tonight and see if I can fix the issue.

Do you mind emailing me at aidan@useoptic.com with the name of your town and a trace route to useoptic.com

It’s working here so not sure what could be causing this besides an issue with our CDN

Hey thank you for sharing your first take. We definately are iterating on our messaging trying to make all your main points clearer.

We have plans to release on windows and Linux later this year. Currently investigating cross platform kits for the GUI.

The engine should run anywhere a JVM does but I haven’t written any docs on that yet. Is a scriptable version of interest to you?

Your initiation is basically right. Optic is a code generator with templates. What’s special about it is that it uses your existing code as input so there’s no manual specification done. You can also manually update the generated code and it still works with Optic. All this combined allows you to “sync” different parts of your code that are related as you said.

You have to specify the skills by hand or import them from our registry. https://useoptic.com/docs/authoring/writing-skills

Thank you for contributing our first outside code! Let's talk about some use cases that might help you as a solo frontend engineer. I'm sure we can figure out a few things to make your life easier.

Thanks for sharing all these awesome ideas. I can't say I know enough about NLP to evaluate how feasible some of your speech to code ideas are, but I do think Optic is a great base to any project trying to do meta-coding.

I'd love to see a 2-way code generator built on Optic for a simple crud builder like you describe. It could let people choose the libraries they want to use from the list and design their schemas, routes and queries at some higher level of abstraction. Unlike the current generator tool you could actually make changes to the high level models and get Optic to update the underlying code for you even after you make changes.

That whole field could be huge and I think Optic's major contribution will be abstracting away all the dirtiness of code gen. People who build this next generation of tools could interact purely with Swagger-like-JSON.

Is this something you'd be interested in collaborating on?

Yep it's all right there. You can use your Optic account credentials https://useoptic.com/docs/authoring/publishing

  npm install optic-markdown -g
  opticmd adduser

Thanks for sharing this. Steve Krouse is one of the best thinkers right now when it comes to novel approaches to programming. I encourage everyone interested in this space to check out his work.