This week we were able to put out two more Beta releases.
Beta 4 came out on March 26th and enabled automatic updating for Optic. Users of version Beta 4 or later can click Optic -> Check for Updates to install the latest version or wait to be autoupdated automatically (checked once a day if app is running).
Beta 5 was finished April 1st. Within Beta 5 we released a debugger for Optic Markdown and some major performance enhancements. If you already downloaded Beta 4, the patch to Beta 5 is just 3.75MB, but it packs a lot of big changes.
The feedback loop for Optic Markdown development has been too long and many users asked for some sort of debugging tool that would allow them to develop their Optic Markdown faster.
We decided to use Optic’s powerful code analysis capabilities to bootstrap our own Optic Markdown debugger. As you edit markdown files, Optic will read them and generate a visual representation of the annotations in your code. Just like you’d expect from Optic, the annotation you are currently editing is the one that is displayed and changes are rendered in real time.
Right now the debugger supports lens definitions. Support for schemas, transformations and some other refinements are coming out over the next few weeks.
To try the debugger out for yourself go to the menu bar and click Tools -> Debugger or ⌘(Command) D.
Here’s the full change log (all built this week):
Incorporated Sparkle Project into Optic for automatic, patch based, updating
Added a pre-loader to the Optic Eye so people know when Optic is warming up/ready
Optic Markdown Debugger View (Tools -> Debugger)
Much faster realtime processing. We open sourced the custom Akka router and mailbox we used to achieve this.
Optic Markdown Migration support
Added Debugger Support to Agent-SDK
Right now Optic renders new code in the same file the user is currently editing. In the next week we’re going to make it possible for users to specify where they want their code to be generated. This capability brings some baggage with it, specifically importing/exporting different objects between files. At this point it’s unclear what expectations the first implementation of Location will be able to deliver on. Ideally we’d love all code to be fully executable upon generation, but some of these complications may make it difficult to deliver on that right away. We’ll strive to find a good balance between usability, predictability and complexity in our first iteration of this feature.
I’ve seen some really cool Optic use cases developed by our users but those experiences are hard to share. There’s been a lot of emailing Optic Markdown around between beta users and clearly its time to take the OPM Registry live. Right now the OPM (Optic Package Manager) only supports local providers. By the middle of April, it’ll be able to resolve any published package that is referenced in your optic.yaml file.
This is where our community starts. We can’t wait to see and share what everyone is working on!