I created a virtual voxel 64x32 app that emulates the 64x32 screen of my Tidbyt. Voxels are 2D SVGs building off David Aerne's delightful Heerich.js (https://meodai.github.io/heerich)
I realize this probably doesn't need to exist in this world but I've gotten a lot of job from it. My main current use is to create virtual displays on extra monitors that I can power from a pixlet apps (pixlet apps generate a 64x32 webp image this emulates).
It's now possible to leverage channels to create a simple HTTP server to wrap it. I created a agent http as a quick proof of concept to demonstrate this.
This mimics the API of Agent API (https://github.com/coder/agentapi) which has relied on clever terminal scraping to provide an http interface for claude code.
The TLDR is this enables you to run Claude Code in a headless way via API calls (perfect for AI code orchestration) while using your Anthropic subscription. To achieve this before you would need to use Anthropic's Agent SDK and API tokens.
I just created agent-http that leverages the channels feature to enable you to wrap claude code with a http api. This provides an identical API to Agent API (https://github.com/coder/agentapi) that relies on terminal scraping to achieve this. Now you can interact with claude code in a headless manner using your subscription. Previously I think you had to do this via the Agents SDK which relies on api token use.
One way to think of an incremental improvement is cutting a sharp edge of a process, solution or problem. A single improvement may not make a noticeable difference but in aggregate the changes can compound to transform a nascent idea to a viable solution. We think this particularly relevant when thinking about AI.
We created this little visualization to help demonstrate it.
Example - The compounding effect of incremental AI coding improvements has made it now possible to build something like this just to illustrate this example!
I've been an avid Mapbox user since getting alpha access to Tilemill. From my perspective, this is the most important contribution to the open mapping space since the introduction of vector tiles and Mapbox GL / Map GL. Mapbox in my opinion left the door open in how they approached tile baking with MTS. While powerful it was way to confusing and expensive. While you could always bake tiles with Tippecanoe you still had to struggle with vector tile hosting hosting. With PMTIles vector tile hosting is arguably easier, more convenient and an order of magnitude cheaper then going with Mapbox (especially if you don't need fancy projection / 3d support and are ok with MapLibre). Felt is one of the major services that I believe uses the PMTile approach behind the scenes and they won't be the last. (Notably: they have continued to invest in Tippecanoe which is awesome). With Mapbox focus shifting, it appears, to car navigation - it's great to see disruptive innovation coming from new places. Even more amazing that is has come from a one person team.
Also to note, the emergence of PMTiles coincides DuckDB spatial query support will unlock a lot of innovation. The ability to query and process large geoparquet files and quickly stream them into baked PMTiles unlocks a lot of really compelling use cases.
Mapbox is still the best choice where a polished suite of mapping APIs is a better fit for a project.
Mapbox is a venture-backed company with a SaaS business model, and has never been open source in total - it used to be open core with a FOSS frontend and proprietary backend. This SaaS model is absolutely the best way to fund huge companies and give investors a return. Mapbox has also done the bulk of innovation in open source web mapping over the past 10 years - the Protomaps project uses MapLibre (fork of Mapbox GL 1.0) and the MVT tile format. Both required teams of full-time developers - easily tens of millions in salaries and stock - and they have given away version 1.0 for free as a gift, even though 2.0 is not open source.
The ideal software economy is one in which innovators capture a good portion of the wealth they create. This is why it's important for Protomaps to focus on use cases underserved by SaaS, instead of just being a cheaper map API. The sibling comment on wildfire mapping https://news.ycombinator.com/item?id=37989059 is a good example of the applications I want the project to support.
> The ideal software economy is one in which innovators capture a good portion of the wealth they create.
Beg to differ, the ideal software economies maximally empowers end-users at the absolute minimal cost. Innovators can and should leave substantial cash on the table. They should see themselves as stewards of a public good.
Ideal software economy would be all free (as in freedom) software. The current economy is hugely wasteful with lots of redundant work and generally bad outcomes.
Private ownership economy doesn't work for zero marginal cost products even in theory. It's a huge waste of our resources and a big hinderance to progress.
Thanks. Another example, at first I thought barking 5 meant "less barking" because that's more desirable. But when I went to do further research on a breed I found it was the opposite!
Hi MedPlum team - congrats on the launch! We've been working on the FHIR space pretty heavily for the past two years. Our main focus is building native FHIR apps for Android currently.
I see a lot of value in some of the components you are adding from an ecosystem standpoint. Quick q - are you building a server or focusing on the components on top? I guess I'm trying to understand the value prop vs. a system like HAPI of Google Health API? How robust is your support for data extraction eg. with StructureMaps, etc?
Congrats on the launch! Look forward to digging in more and my reach out.
Our goal is to provide a comprehensive experience that spans both front end and back end. In practice, we're focusing on a rock solid server first. At present, our front end components are best used for rapid prototyping and internal tools. Developers who want to create highly custom and pixel perfect designs will probably opt to use their own front end stack.
We do not currently support the StructureMap $transform operation, but we are actively working on it to support conversion to/from CCDA and other FHIR versions.
We have the utmost respect for HAPI, Google Health API, and all other FHIR servers. We believe that they are all contributing to cleaner and more interoperable data.
One key difference between the Medplum server and other FHIR servers is that it is designed to be use as a complete backend, not just a data store. That includes supplemental API endpoints for end-user auth and account management, automation ("Bots" for "if this, then that" style automation). The goal is that a developer should be able to create a complete digital healthcare experience with only a statically hosted website -- no additional servers required. In our experience, HAPI and Google Health API are used more like a database, where you run additional servers in front. We believe that providing a more comprehensive server lowers the barrier to entry, and reduces the maintenance burden for digital health providers.
After having worked with Google's Health API & HAPI FHRI, I really appreciate the "other" features that are baked into this like auth and user management. We ended up proxying all of our FHIR requests through Rails to HAPI so that we could layer on some of the key features you mentioned like fine-grained auth and custom behavior before/after requests. This makes it much easier to pickup and use!
Mapbox has been pretty strategic about not being perceived to compete with it's developers. Besides creating an amazing stack remaining neutral I think is part of their appeal.
I realize this probably doesn't need to exist in this world but I've gotten a lot of job from it. My main current use is to create virtual displays on extra monitors that I can power from a pixlet apps (pixlet apps generate a 64x32 webp image this emulates).