Starting the Public Beta

Getting ready to launch something big…

This highlight of this week was the first public beta release for Optic which came out on the 15th. You can go download it here.

This new version of Optic includes the following changes (all built this week):

  • Released documentation

  • Added Socket Events to send Project Status for Agents (Used to display loading page and error states)

  • Bumped supported optic-markdown to version 0.1.2

  • Fixed issue where Optic didn’t work if the App was located in a path with a space in it ie ‘Developer/My Apps’

  • Packaged Optic Markdown within .jar so it doesn’t need to be installed separately.

  • Optic checks if a valid version of Node is installed before starting

  • Optic Editor window loads faster and has correct title

Bug Fixes:

  • Data directories weren’t being created on first run causing most of Optic’s internal functionality to fail. This was missed because in testing we didn’t wipe all Optic files from our test devices.

  • Issue that prevented Optic servers from shutting down after the host Mac App closed has been resolved

Other Development:

HUGE THANKS to Scott Barstow, a beta user who helped virtually debug this issue over 35 emails.

  • Finalized designs for the more advanced transformation system that will appear in the next major version of Optic

What’s Next:

The next technical priority for Optic is finishing our advanced transformation system. What does that entail?

Well right now the Optic API can take any Schema & Lenses and generate code into your project. So a Rest Route + *Express JS Route *will yield the code for a route definition. This is powerful, but it doesn’t support stringing together Optic knowledge from multiple sources which really handicaps what Optic can do.

For instance, we should be able to transform a DB Model into a Create Route for that Model. The advanced transformation system will enable a fully functional Route to written with both validation and a query contained within it. These transformations will be generic and allow users to customize the way the code is rendered based on their architecture choices. So the query component in our example above would be rendered using Mongoose, DynamoDB, Sequelize, etc depending on what you’re using for your app.

tl;dr: Advanced transformations will be able to define generic patterns in code, independent of any particular language or framework. When users call upon these transformations, complex code will be rendered based on the conventions they’ve included in their project.

Create Route:

  • validation
  • An Insert Query: success -> Response(200, data) failure -> Response(4xx, error)

Input Wanted:

One of the challenges we’re currently facing is figuring out the right updating schedule/mechanism. Since Optic is not a web app we’re a little bit stuck in the past. Our dmgs are ~120MB today and it’s not practical to distribute builds of that size every day. That being said, we also want to move quickly and get great updates out to users ASAP.

What are some suggestions from the community? Any tools that might help?

How often would you be willing to update Optic?

We can patch changes (1–5mb in most cases) in the background without asking you. Is that cool?

Please respond by commenting on this post or reaching out to us on Twitter.

Again, thanks so much to all our Beta Testers. Good things are on the horizon.