Founder @ https://airplane.dev here - putting in a shameless plug for Airplane, where you _do_ write code from scratch. :) I think it depends on the builder and use case, and it's not a fit for everything, but our users like / need to manage their tooling as code and are more productive for it.
It's interesting because we came to a different conclusion with Autopilot[0] - context and learning is incredibly important for result quality, and gpt4 doesn't (yet) support fine-tuning but will soon, and we'll definitely be taking advantage of that. Not just for quality, but also for speed (less time spent gathering context and processing input tokens).
My view is, everyone has access to chatgpt and github copilot, and so the idea is to provide value in excess of what chatgpt/copilot can do. Part of that is embedding it in the UI, but (especially for internal tools, which tend to be shorter) the improvement isn't huge over copy/paste or using copilot in vs code.
However, beyond UI integration, we can intelligently pull context on related files, connected DBs/resources, SDKs you're using, and so on. And that's something chatgpt can't do (for now). The quality of response, from what we saw, dramatically improved with the right docs and examples pulled in.
And yes, gpt4 does much better on JS (React specifically) and Python. It's just whatever it's trained on, and there's a ton more JS/Python code out there.
2 - correct, depending on the task type we still call through to node etc. But the CLI also provides a dev UI and other niceties specific to Airplane.
3 - correct, the code is built and pushed to us, similar to Heroku.
Our value prop ultimately is that 1) you can build tools like admin dashboards, data migration scripts, one off devops operations, etc, into production grade web apps and 2) you can do this using code!
cron is a popular starting point on Airplane! We see our users creating tasks that are semi automated, but then adding manual tasks later (but then automating those tasks as well). The nice property of Airplane is that it's very composeable and extensible over time.
(Appreciate the feedback! We clearly need to continue to improve how we explain the product. :))
It's probably easiest to explain in terms of what a developer does on Airplane:
1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.
2. Dev uses the `airplane` CLI locally to run and test the code
3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane
4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.
It's similar to GitHub actions in architecture (but for a different domain).
(I'm one of the founders at Airplane.) It started as a reference to "lightweight control plane[0] for your company" - but also the domains were loosely available.
Airplane is a platform for quickly building internal tools. We let you turn scripts of various types (Python, JS, shell, SQL, REST, ...) into lightweight internal apps for your support, operations, and other teams. Today, we provide UIs, notifications, permissions, approvals, audit logs, and more out of the box. In the future, we'll support increasingly more complicated workflows and interfaces.
I was previously CTO at Benchling (YC S12) and Ravi previously co-founded Heap (YC W13). Across our companies and many others we've talked to, we've seen various combinations of chatbots, scripts, and Jira tickets adding friction, interrupts, and errors to processes across the entire, well, company. We hope Airplane serves as a useful tool to tackle these problems.
We'd love to hear your feedback on Airplane! It's free to sign up and start using.
We currently use a mildly exotic "temporary bastion" approach, where upon request / approval a dev can get a container launched. The container is launched on ECS running an ssh server, pinned to the dev's individual public key, and that container has the appropriate security groups / IAM roles to access various production resources.
Right now, a dev will 1) VPN to get shallow network access and 2) SSH over VPN to get deeper network access through the bastion container. Something like a database is security group'd off so that you need to be on the bastion container to access.
My question - would Twingate be able to support an ephemeral use case like this? I'm thinking ideally it can be launched as a sidecar container, and a dev could SSH through the twingate container. A lot of solutions I see don't seem to handle ephemeral situations super well, so I was curious.
Benchling (YC S12 - https://www.benchling.com/careers/) is excited to attend! Stop by and chat with us if you're curious about applying software engineering to biology.
Hi there, thanks for the feedback! The 2 examples in the write-up are:
1) Molecular Weight: weighted sum across amino acid sequences, using amino acid weights defined in [1]
2) List Concatenation: aggregate lists of added resistances (like ['Ampicillin', 'Kanamycin']) across itself and all ancestors
These are simple, and can be expressed as formulas in Excel or functions. They take < 0.5 s.
A more complex biochemical property for antibodies that can't be as easily expressed in Excel is isoelectric point ([2], see example BioJava implementation at [3]). It requires a binary search, but the search space is constant so usually these calculations finish < 20 s.
Since our implementation is in Python, we can wrap the function in try/catch and, in the catch block, log the error and set the failed computation status.
Is anyone here running k8s in production with kops? Are there any missing pieces that require "manual" work, like rotating certificates? How feasible is it to run, say, 30 clusters out of the box with a 2-person team?
Benchling (YC S12) | Full-stack engineer | San Francisco, CA | ONSITE | Full-Time
Benchling builds software that powers life science research. Our customers include academia (MIT, Harvard, Stanford, UCSF, Berkeley, etc), biotech (startups and IPO), and large pharma - each improvement we make to our platform directly accelerates progress on cutting-edge CRISPR research, cancer therapeutics, synthetic biologics, and more.
We're looking for engineers who love building things and care about the impact on the future of research and, by extension, society. We've built: an IDE for DNA, a version of Google Docs for biology, and an API platform to power research automation. You'll build the next arc of our platform, as we expand into broader workflows, new science, and new ways of connecting machines and scientists with the Benchling platform.
Relatedly, if you're an engineer looking to build the software that powers CRISPR[0], Benchling (YC S12) is hiring!
Most of the major research organizations working with CRISPR leverage Benchling -- the Broad Institute, various labs at Berkeley, companies like Editas, etc.
I was wondering the same thing - my guess is that they added this hastily (maybe that's the wrong word; I"m sure it's not trivial to change) and haven't figured out how to remove all the sizes from the system.
If anyone else knows, that'd be helpful - I'm thinking of just buying a ton of *.smalls...
// Edit: Oops, maybe I misunderstood the parent. Sibling's right; you'd need 256 small RIs to make up for one 32xlarge RI. I'm wondering why we should ever buy 32xlarge RIs and lose granularity.
Hm, unless I'm misunderstanding, the bottleneck here isn't running regex over all the sequences - it's in filtering out a large % of sequences before running a regex over the remaining ones. You're storing trigrams (3-byte keys) in an inverted index - compressing them won't get you much other than space savings. Re: caching, we're using Elasticsearch's bitmap caching to speed things up. If you search for something twice, the second time it'll take the cached bitmap from the first search and use that instead.
We use fast languages when we need them. Python is just parsing a regex to generate constraints - for DNA search, parsing a 1000-char regex is super fast and rarely an issue.
In this case, we're already at sub 100ms searches (usually sub 50ms) so I don't see much benefit from playing around with L1 caches and JIT-ing when higher-level structure already gives the perf characteristics we need.
We use ES for the rest of benchling search already, so that was the main reason why we stuck with ES (ngram indexing is pretty standard there).
As for why we were using ES for the rest of search: we were using it for things like language stemming, matching terms with "slop", things like {'minimum_should_match': '3<67%'} (require exact matches if 3 or less terms, 67% if more than that), searching _all to match anything in the document, etc etc. I think a bunch of these (maybe even all) you can do in PG, but it was way easier to get going with ES.
ES is also distributed, which makes scaling up and doing maintenance a lot easier - a bunch of times we just threw new nodes at it and remove old nodes that had gone bad.
Insanely cool, thanks for sharing - this would be interesting to replace our final filter (if I'm interpreting correctly, a trigram index would still speed up the initial search)
And yeah, Python is a strict requirement since the rest of our code is in Python - figured it wasn't worth throwing in another language when a rough parser worked.
Posting on behalf of Hannah, since her new account is getting blocked from replying:
hi! resident scientist at Benchling here! searching near-exact sequence can be really useful! for example, sometimes i would like to find if any of my plasmid has a certain signal peptide, it would be so hard without this search algorithm because so many DNA sequences can be translated to the same signal peptide. it would be great if i could just paste the amino acids and i could identify which plasmids contain the signal peptide.
Has anyone used RLS in a standard web service? Are there any common use cases where this is handy? I'm thinking it won't work for your standard permissioning system since it seems clunky if you have any slightly sophisticated logic (X is in org Y and can see anything Y has read access to).
Maybe it'd be more useful if you're using a single DB for a multi-tenant setup, and you know each tenant's data is strictly isolated?
Yeah, I'm not too happy about how we're using regex inside a groovy script for the final matching - when we scale this to support larger matches we'll likely hit memory issues trying to parse the entire string at once, and I've been playing around with the idea of streaming the bases into a state machine. Is that similar to what you were referring to?
Do you have a way of generating state machines, or are they hand coded? Is it a perf optimization, or does it help integrating domain-specific logic?