joshma

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.

[0] https://www.airplane.dev/autopilot

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).

[0] https://docs.airplane.dev/getting-started/views

[1] https://docs.airplane.dev/self-hosting/agents

(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.

[0] https://www.cloudflare.com/learning/network-layer/what-is-th...

Hey folks! We're Josh and Ravi, co-founders of Airplane (https://www.airplane.dev/).

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.

(Posting on behalf of Somak)

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.

[1] https://www.promega.com/-/media/files/resources/technical-re... [2] https://en.wikipedia.org/wiki/Isoelectric_point [3] http://biojava.org/docs/api1.9.1/src-html/org/biojava/bio/pr...

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.

Apply: http://grnh.se/ocnhd0

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.

Shoot me an email: josh at benchling dot com

[0] https://benchling.com/crispr

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?

We care about reducing memory usage because it gives us greater flexibility in our infrastructure. We're offering this to hundreds of scientists a day - not huge numbers in the grand scheme of things, but usage is bursty and by paying customers. This means we can mix in CRISPR work with our other processing infrastructure, and we can choose between many servers with low memory vs a few servers with high memory.

Maybe genomics doesn't have to be so memory hungry. 8)

Haha, Vineet appreciates the compliment, I think...

I mentioned it in a comment below, but our constraints are a bit different once you start supporting multiple genomes - we could've been clearer about that in the post for sure.

Yep, GPUs were the first thing we looked at. :) (And to be fair, our current approach is pretty close to a brute-force search!)

The main reasons we decided against a GPU-based approach were cost and scalability:

- We support a dozen+ reference genomes (eg for difference species), and plan to support a lot more (including eventually supporting custom genomes that users provide). Assuming we want to support a few concurrent searches against the same genome, we'd need a few GPUs per genome, and this gets expensive pretty quickly on AWS.

- Our fleet is now non-homogeneous, and now if machine X fails we need to restore machine X' with the same set of genomes.

- If certain genomes are more popular than others, we'll likely have GPUs spun up that aren't being used much (only one lab might be investigating a certain genome, for example). I suppose you could swap genomes in and out of memory as they're accessed, but again it's more complex to manage resources.

- Our current approach allows us to add genomes ad-hoc - hypothetically, you could point us to your own genome on S3 and we'd be able to work with it.

We hint at it towards the end, but we're actually switching to AWS Lambda soon - based on early calculations, it could cost us as little as $50 a month to run everything!

Could you elaborate on why there'd be a smaller number of dead tuples? Are you just taking into account the autovacuuming that can take place as you continue through the iterations?

You can also get a nice tabular view for the domain you're on by going to "Resources" from dev tools and navigating to the "Cookies" subsection.

Is there any way to use the tooling independently of web starter kit? Wasn't able to find a link on the site, are they just warnings you see once you start developing? Can the tooling account for JS changes and navigation between pages?

Sorry for the barrage of questions, just really hoping to find a decent tool to clean up CSS...

Any thoughts/justifications for pricing? The only thing holding us back is that Slack costs 4x as much ($8 instead of $2). While this isn't a big spend at the end of the day, we're sort of anchored at $2. There's nothing terribly wrong with hipchat, seems to address all our (simple) chat needs, and switching to slack doesn't seem to give us 4x as much value.

So far the best reasoning I have is that we're a mostly-dev team, and that there's something for non-devs that is appealing in Slack, but surely it's not a prettier interface? I'm genuinely curious, as I'd like to justify switching to the prettier product. :)

Have you looked at JSX[1] yet? Because I feel it was invented exactly to address your tl;dr - you're writing something that is very close to HTML inside your Javascript, so it definitely seems easier than writing JS snippets in XML.

Also, although I've found that ReactJS tends to encourage a more modular component structure (which I'm personally a fan of), there's nothing stopping you from laying out large chunks of a template instead of small snippets.

[1] http://facebook.github.io/react/jsx-compiler.html

From what I see, it was an investigation into gender-based discrimination/harassment claims, and the result of the investigation was that, well, no evidence of gender-based discrimination was found. Does that not provide very useful information to the reader? It would be irresponsible for the report to claim that no harassment of any form exists at GitHub, and irresponsible of us to accuse (or "wonder", which is just a wiggly way of accusing) the worst given its omission.

> This doesn't mean there isn't any evidence--it just means that their internal investigation didn't find any.

Of course the results of the investigation tells us nothing about things outside the investigation. Is that not assumed? How many 3rd parties does it take before this is not true?

Apologies if I sound irate, it's just disappointing that accusations that seem to have little basis (huge disclaimer, purely based on news coverage and this published report) can cause a founder to leave his company.

In my opinion it's focusing on the wrong part. Between the two trends (IE11 growing or IE10 vs IE9) the former is more likely to continue and the latter is likely to end as more machines reach end of life.