Comments URL: https://news.ycombinator.com/item?id=47627527

Points: 206

# Comments: 36

I agree. There's so many cool things to do in this space, and so many unique ways to achieve them. We're excited to be here, and would love to chat sometime as well!

We also have support for open protocols such as MQTT and HTTP+SSE, but the Device SDKs enable us to provide a richer set of capabilities. Our SDKs actually speak a custom protocol we developed for higher efficiency. We're also going to add many more features such as automatic telemetry collection and tracing support, which is more feasible with a plug-and-play SDK.

Another big issue you pointed out is with documentation, a key part of Developer Experience is always great docs. A compelling model might be standalone open source tooling that works independently, with an integrated platform that ties it all together, creating a strong ecosystem.

I've been using Home Assistant with a bunch of Zigbee and Wifi devices at home, and it's been pretty stable. However, for an industrial context, there are already many other hurdles, having a platform handle a lot of the cloud infra and connectivity & monitoring is really helpful.

Fostrom is an IoT Cloud Platform designed for developers to make it really easy to get started and scale fleets. We have Device SDKs (in Python, JS, Elixir, more coming soon), Typed Schemas, Per-Device Mailboxes, Programmable Actions, 4 Global Regions for lower-latency connections, and much more.

We've built Fostrom to solve a real need we faced in our previous startup, building a fully automated indoor vertical farm. We spent more time figuring out IoT infrastructure than writing automation logic. Fostrom is the platform we wished existed back then.

Over the last few years we've experimented with a lot of interesting tech and architectures, and settled on an architecture that we believe is quite elegant. We wrote a Go<->Elixir bridge to execute JS code in WASM for Actions, implemented a DuckDB library for Elixir, and wrote a Device Agent in Rust that our SDKs run in the background (https://github.com/fostrom/devicekit).

The most interesting realization we had was about the data architecture. For years, we tried using distributed databases and built complex layers on top of them, but all approaches had significant limitations specifically around consistency and querying. We want to provide operational correctness, rich insights, and reliability. Finally, we came to the conclusion that to achieve this we really need a SQL database for fleet data. So we built a DuckDB-based replicated multi-tenant data layer. We're still improving it (hence the Technical Preview badge) but we're quite proud of this decision. It simplifies the rest of the codebase, while keeping operational complexity in just a few places.

Our vision is to make a powerful IoT platform that enables you to build correct, secure, and reliable connected systems without dealing with any of the plumbing or infrastructure.

Next up, we're gonna launch our CLI, add automatic device monitoring to our Device SDKs, and improve the debugging experience. We have some pretty cool ideas to make Fostrom and the experience of developing connected systems better. We're also going to write more about our architecture and journey soon.

We also published our launch blog post which goes into more detail about our vision, what we've built, and our future plans: https://fostrom.io/blog/introducing-fostrom

Would love for you to try out Fostrom and give us your feedback and thoughts.

Comments URL: https://news.ycombinator.com/item?id=47084431

Points: 13

# Comments: 8

Fostrom is an IoT Cloud Platform designed for developers to make it really easy to get started and scale fleets. We have Device SDKs (in Python, JS, Elixir, more coming soon), Typed Schemas, Per-Device Mailboxes, Programmable Actions, 4 Global Regions for lower-latency connections, and much more.

We've built Fostrom to solve a real need we faced in our previous startup, building a fully automated indoor vertical farm. We were spending more time figuring out IoT infrastructure than writing automation logic. Fostrom is the platform we wished existed back then.

Over the last few years we've experimented with a lot of interesting tech and architectures. Here's some of what we use today: Elixir and DuckDB power our infra, Actions execute JS code in a WebAssembly sandbox, and Device SDKs are powered by a tiny Device Agent written in Rust that speaks our custom protocol, running in the background.

Our vision is to make a powerful IoT platform that enables you to build correct, secure, and reliable connected systems without dealing with any of the plumbing or infrastructure.

Next up, we're gonna launch our CLI, add automatic device monitoring to our Device SDKs, and improve the debugging experience. We have some pretty cool ideas to make Fostrom and the experience of developing connected systems better.

We also published our launch blog post which goes into more detail about our vision, what we've built, and our future plans: https://fostrom.io/blog/introducing-fostrom

Would love for you to try out Fostrom and give us your feedback and thoughts.

Comments URL: https://news.ycombinator.com/item?id=47072401

Points: 3

# Comments: 0

I've always been unhappy with the way tasking/todo app (don't) work for me. I just started building a TUI in Zig (with the help of Codex) to manage my daily tasks. And since I'm building it just for me, the scope is mine to determine too.

I think NetNewsWire is a great example of what software should strive for: a useful set of features, while being fast and smooth.

It is of course your responsibility, but the maintainer may also want to change their review approach when dealing with AI generated code. And currently, as the AI Usage Policy also states, because of bad actors sending pull requests without reviewing or taking the responsibility themselves, this acts as a filter to separate your PR which you have taken the responsibility for.

Covers most of the points I'm sure many of us have experienced here while developing with AI. Most importantly, AI generated code does not substitute human thinking, testing, and clean up/rewrite.

On that last point, whenever I've gotten Codex to generate a substantial feature, usually I've had to rewrite a lot of the code to make it more compact even if it is correct. Adding indirection where it does not make sense is a big issue I've noticed LLMs make.

We just launched Fostrom [1], an IoT Cloud Platform designed for developers. I was wondering what else have others found effective in this space to do sales and outreach?

[1] https://fostrom.io

I wanted to support RISC-V boards too, so I went with the Milk-V Duo S as the test device. I have managed to get Tailscale working, and our Device SDK works too, with the bundled Python.

The experience of using the Milk-V Duo is definitely not as straightforward as the Pi Zero, but it does work, and is easily available in most places, unlike some of their other products. The Linux distro they provide is quite barebones, and I wasn't able to get Debian working. The docs for the device are pretty decent. I hope we get better support for Debian/Alpine/Arch for these kinds of boards soon.

In Fostrom, devices connect via our SDKs or standard protocols such as MQTT and HTTP, and send and receive structured, typed data, through pre-defined Packet Schemas. Each device gets its own sequential mailbox for messages. You can trigger webhooks or broadcast messages to other devices based on incoming data, powered by programmable actions (written in JS).

We entered Technical Preview recently. Since then, we've been working on:

- Major upgrades to Actions: making it easier to write action code, along with testing before deploying, and more docs on how to write good actions. Coming this week.

- We're in the process of releasing Device SDKs in multiple languages, including JS, Python, and Elixir soon. The SDKs are powered by an underlying lightweight Device Agent written in Rust.

- A new data explorer to view and analyze your fleet's datapoints, which will be available in a few weeks.

Happy to answer questions and appreciate any feedback.

Any feedback or suggestions on what you would like to see?

It is written as a novel that teaches PostgreSQL by exploring the dataset of the Cassini orbiter around Enceladus, Saturn's moon. Highly recommended and fun read.

[0] https://sales.bigmachine.io/curious-moon

We're building an IoT Cloud Platform, Fostrom[1] where we're using Javy to power our Actions infrastructure. But instead of compiling each Action's JS code to a Javy WASM module, I figured out a simpler way by creating a single WASM module with our wrapper code (which contains some further isolation and helpful functions), and we provide the user code as an input while executing the single pre-compiled WASM module.

[0] https://github.com/bytecodealliance/javy

[1] https://fostrom.io

A developer-focused IoT Cloud Platform. The idea stems from pain points experienced while automating an indoor farm a few years ago where I had to spend way too much time building the data collection and analysis infrastructure instead of focusing on the actual automation.

Devices connect via secure MQTT, HTTP, or WebSockets and send structured, typed data. Each device gets its own sequential mailbox for messages. You can trigger webhooks or broadcast messages to other devices based on incoming data, powered by programmable actions.

Just deployed to production. Currently working on Device SDKs (coming very soon) and time-series analytics. Check out the platform, we're in technical preview now. Happy to answer questions and appreciate any feedback.

That being said, if you do decide to use spaces, I want to point out a MacOS setup that would help you to keep apps on different spaces and have an experience (slightly) closer to i3wm and other window managers.

First, you should create 10 spaces. Then go to Settings -> Keyboard -> Keyboard Shortcuts -> Mission Control -> Expand the Mission Control dropdown. You'll see options to set keyboard shortcuts for each workspace there. I've set it to Option+{1-9, 0 for 10}.

Then just open some of the permanent apps you use, and right click on their Dock icon -> Options -> Assign to this desktop. I keep the browser in workspace 1, and messaging app in workspace 10.

I know this isn't the best solution, but behind crazy-hidden settings, it is possible to get a pretty decent solution for window management on macOS. Ohh also, I use Amethyst sometimes, for i3wm-like window layouts, and it allows you to set shortcuts to move apps from one workspace.

This makes the train effect go away, but there is still another very slight fade-away effect when switching desktops, albeit much less annoying.

Comments URL: https://news.ycombinator.com/item?id=30278356

Points: 2

# Comments: 0