amazing! it seems like much of the innovation on the flight deck is happening in iPad apps.
i'm curious, in the beginning, before you had so many users of the app, how did you convince pilots/airlines to install SkyPath before it had enough user-generated turbulence data for its ML model? it almost feels like a chicken-and-the-egg problem: you need enough reports before it's useful around the world at all imaginable air routes, or maybe there's enough air/wind data. interesting stuff!
We had to give incentives for the first airline partners and give the product for free for a long trial period at the early years to be able to have initial installs. It was a long ride including Covid which came in the middle and didn't help. In the last years since we have several big airline partners this is less of a problem.
The effect on the route is immediate. There is no installation or integration so the moment you deploy (with a reasonable fleet size) you have data. Those that where quick to understand the concept embraced technology very fast even without initial data set in the route
thanks for making this. i've spent 5 minutes on this, but haven't been able to get it to work yet, the extension popup's Parse and Extract buttons are grayed out. do i need a sub to try it out?
a few general remarks:
the landing page above-the-fold is just ugly, the color gradient is horrendous, and the top screenshot of a video is... blank. at first i tried to click the play button, but nothing happened. then i realized it's more of an abstract illustration of what you app does. makes sense, but a real video or animation would be even straight to the point. please, wow me!
what is mining? at first, i thought you've created a cryptocurrency. i see it's explained later down the page.
after login, the grammar page doesn't respect the light mode theme. more examples for grammar would be helpful. in fact, what i want is, extract relevant grammar from the CC of YouTube videos in Korean, and then link me to the EXACT TIMESTAMP, so i can hear it in actual use. i would pay for this.
Hey thanks for the awesome comment! Yeah you do need a sub (a free trial to be manually activated, big mistake on my end there, I should have made that flow better, lesson learned with this post.)
I get the frustration with the landing page and I think you are right. I was not exactly perfectly happy with this above the fold section either. I just made what I could do the best for now. 100% this will be changed in the future once I can get a full fledged trailer.
As for the remaining points, they're are all good points, all noted. Thanks again for the feedback.
Thanks for the feedback! You're right, there are many assumptions in my head about what the product is intending to be, and looks like I need to be more explicit in the marketing materials :)
Right, it'll be tricky to compete with other SaaS that offer code execution, since they have free tiers and a lot of mindshare already. Other feedback is also hinting that I should focus more on workflows/process automation for non-developer users, rather than code actions. This is the direction I want to go anyway, but I decided to launch with what I have already.
The project term is a bit premature, since I haven't fully finished. Essentially, a separate collection of workflows/jobs, meant for team accounts that can have multiple users.
There's no free tier, but there's free credit on signup so you can try it out without any payment or credit card. Maybe I should have a free tier? My overthinking brain is worried about abuse, but maybe I shouldn't care at this point if nobody is using it yet... :)
The main difference is that ExecAPI is intended for running periodic or triggered background tasks, and you're not limited to JavaScript or Wasm code running on just V8. You can run any Docker container as a background job; mix and match Bash, Python, and Node.js if you like. I would say ExecAPI is closer to a combo of Cloudflare Workers Durable Objects and Queues products, than meant to handle/filter HTTP requests traveling to your origin server.
Code ("actions") run in a Docker container using the gVisor runtime. I'm also toying with using firecracker-containerd, which uses Firecracker microVMs underneath.
It's funny you mention that. A previous "iteration" of this project was an edge function runtime, which would take Docker images and convert them to Firecracker VMs, prebooting them, and taking a snapshot at the right moment using some VSOCK magic. It was similar to Fly.io, Lambda@Edge, etc. and ultimately I decided to go another direction because most people don't care about low-latency compute on the edge.
I never enable push notifications for any websites I visit, but I think, as a developer, it would be interesting to easily add push notifications for internal apps. i.e., stuff that one would use a Slack hook for, I'd rather have a homescreen web "app" that can send pushes natively (albeit via a third-party push broker) rather than having to either build your own native app or use a messaging platform.
Many of these vim distros (haven’t used AstroNvim specifically) with plug-in managers automatically download and execute random code on your system anytime you start the editor or open a new file type. I just want my own secure config that doesn’t do random network calls when I’m trying to open local files.
Piping shit to bash and running npx whatever has really normalized this and it sucks. Your editor should be a safe haven.
You can turn autoscan (fetch from git repos) off, update should normally be opt-in already. You can use a lockfile and only update on demand. That's a more sane option. But yes, auditing 50+ git repos is not something I've attempted.
Random node packages processes truly sounds horrible for both security and performance, but you do want at least one LSP process spawned per filetype, right?
Separating out the LSP process from the editor is a good idea. One sure hopes the blast radius is small enough if there’s a vulnerability. My beef is really with the auto-update culture. If I can specify lock files for plugins, it helps, but no way most people are going to have the time or expertise to audit editor plugins.
I guess it’s the classic security vs. UX compromise!
I'm working on ExecAPI - https://execapi.com - a code execution as a service platform, starting with WebAssembly nanoservices, deployed a bit like CGI scripts, but running on the edge, so comparable latency to Cloudflare Workers and Lambda@Edge. Currently thinking about ideas around HTTP-triggered workers, long-running services, web hook handlers, etc. and how we can bring cloud costs down to the bare minimum.
It's more of a fun project right now, but hoping to unearth some marketable use cases and ideas as I go along. I'll do a proper launch in a month or two.
Manually replicating writes to all nodes seems pretty fragile. At some point you're going to run into classic distributed systems issues, like netsplits, and reconciling the latest count. Maybe a CRDT implementation would avoid these issues alltogether?
But it sounds like LiteFS (with a single writer?) might be a pretty nice setup if it handles replication for you, as you probably don't want to build a Raft or Paxos system yourself.
Litestream is different from LiteFS: same author, different projects.
LiteFS provides replication with the ability to serve read traffic from those replicas. Litestream provides disaster recovery by streaming a constant backup to an S3 bucket (or similar).
i'm curious, in the beginning, before you had so many users of the app, how did you convince pilots/airlines to install SkyPath before it had enough user-generated turbulence data for its ML model? it almost feels like a chicken-and-the-egg problem: you need enough reports before it's useful around the world at all imaginable air routes, or maybe there's enough air/wind data. interesting stuff!