lol no they both read as permissive on the surface. apache 2 doesn't include a termination clause that broadly protects an entity against any litigation. this is incredibly broad and not community safe.
Strongly disagree with the article. Enums make gradual migrations impossible in both databases and API design with third party consumers. Even in the example they gave where they recommended a user “role” instead of an is_admin boolean they are creating huge problems. Am I supposed to tell all my downstream API consumers that they need to refactor their code because we’re introducing a new value to “role” that covers “billing_manager”? There are literally zero downstream issues with adding is_billing_manager, and you get the additional representation benefit that the booleans can _both be true_, so I am not trapped into an exclusive role paradigm.
> tell all my downstream API consumers that they need to refactor their code because we’re introducing a new value to “role” that covers “billing_manager”?
With non-exhaustive enums you don't need to do that? But also, you can match on a single variant ignoring others for the admin role check?
Awesome to see more people experimenting with AI-generated electronics. The main thing holding back physical world innovation is the labor cost of design- I’m always blown away that someone needs to raise $50m just to design a hardware AI-assistant or new robotics
Frameworks like atopile, tscircuit (disclaimer: I’m a tscircuit lead maintainer) and JITX are critical here because they enable the LLM to output the deep knowledge it already has. The author is missing a couple pieces to really get great output: 1) Context-friendly datasheets 2) DRC/Semantic review 3) LLM-compatible layout methods
The hardest to build is (3) and what I spend 90% of my time on. AI knows how do do spatial layout for things like flex or css grid but doesn’t have a layout method for PCBs. Our approach w/ tscircuit is to develop new layout systems that either match templates, new heuristic layouts (we are developing one called “pack”), or solve simple spatial constraints.
But tldr; it is only a matter of time before AI can output PCBs. It is not simple but we know what works with LLMs from witnessing the evolution of AI for website generation
There's a lot of potential for desktop rapid-prototyping with electronics. I think one of the things that is killing us is the tooling. One of the reasons I started building an autorouter was because I wanted to be able to have different "build targets"- e.g. a build target that is a PCB with no vias and only 0 ohm resistors (jumpers). If our EDA tooling supported different build outputs, then we could have earlier prototypes built with less-than-ideal equipment (e.g. conductive 3D printed filament, as the article suggests)
Hardware is becoming more accessible, so more software companies are going to release hardware products or build hardware products for internal purposes. The future of physical world innovation isn't going to come from legacy hardware corpos, but from software companies that run hardware experiments that become real hardware products. Hats off to Posthog for making it cool!
The reason hardware has sucked in the past is poor tooling. But now open-source solutions are getting pretty good, and AI is covering many knowledge gaps.
This is the truth - my recent work has dragged me into doing exactly this, building hardware "giveaways" to promote SaaS in niche industries, and enabling the backend devs to have an API they can understand to control it.
It has made me wonder why such things haven't been more popular attached to Grafana. For example, take a LED strip and use that as a gauge or similar. Many devs seem to fetishize screens and enjoy extra displays in their environments, while normies (at least the feedback from the recent work) have been telling me they actively want to get away from any screens. OTOH using LED strips rapidly turns anywhere into a vape shop.
These do exist but they're remarkably expensive and the infrastructure is apparently terrible. Several companies sell "smart led displays" that people use to show their follower counts while streaming. There's no reason you couldn't make one and have it subscribe to ntfy or something like that. But adoption seems ropey because the use cases are always clocks and $200 for a screen is a big ask for most people.
We had a "smart display" that was a wall-projector that someone was throwing out, a raspi zero and some python code that used SDL to display some numbers (in a huge font) from a requests fetch of a csv file. Once we moved out of incubator space and into a real office, we duplicated it so that it was visible in more places (at the time, terribly under-spec projectors were $150ish and melted/burned within a year of 24/7 operation; after a couple of iterations of that we'd grown enough to have an actual analytics team that got a big screen and a dashboard up in the kitchen - but noone really looked at it, the thing about the projector version was that it had One Big Number that Went Up and so it was easy to care about.)
Since it was widely visible it occasionally got augmented with "N days to <critical deadline>", usually conference appearances.
Also, originally it was unfunded (free raspis, trashpicked projectors) but when it first went away due to projector meltdown, the legendarily cheap CEO showed up with a replacement, because he really liked having The Number on display.
(Didn't have build status, but it did change from green to red on certain kinds of infrastructure failure, which wasn't as useful as it sounds.)
This is unsurprising. LED displays/arrays/strips involve using enough power that a software specialist is unlikely to manage it safely without getting decent at electronics. Conversely, the hardware people can throw just enough software together to make the happy path work, but not scale it up let alone reliably.
There are some people genuinely superb at both domains, but at some point they sucked at one or the other. The trick is to be ready to absorb information from both sides, but many will simply go "hey, it works on the happy path" and move on. My personal cutoff is whenever it goes over 12v or 500mA I know I'll be getting a second opinion.
I think it's the same reason why phones killed cameras and portable music players. It's neat to have dedicated devices that do one thing well. It's even neater to have one device that can do all the things. It's easier to transport, easier to store, easier to clean and so on. From a sustainability perspective it's probably also generating less waste, although I don't have enough knowledge in materials science to confirm that notion.
I sometimes wonder if this impulse is part of the appeal of LLMs for the people who use them for everything - not that they're actually better at anything, but just that they're kinda good enough at all of the things to make it easier to consult them than to consult dedicated sources of information.
For my phone, I'm happy, because it replaced about 6 things without losing much quality. I could get myself a better camera (my parents in fact have one). I in fact have a more compact and repairable MP3 player that runs off SD cards and batteries and it still works wonderfully. With the death of the 3.5mm audio port that thing can actually drive the good headphones better than my phone, heh. But that's just more stuff to lug around.
On the other hand, for my hobby music, I by now prefer single-purpose things. My audio interface has the job of digitalizing audio. These three pedals each have their own unique job and function, and I own them for that purpose. There is a bunch of very dedicated stuff around, a good tuner, a good metronome with googly eyes.
I'm kinda observing the same at work: Sometimes, I just want to get rid of a problem. Just throw a magic zero-config box at it and have it be gone. And in other contexts you want or need to have control over many parameters, and then having small, little single purpose things is very, very useful.
Some monitoring box very likely would want to err on the zero-config magic box I guess?
In the meantime we’ve lost pretty much any innovation in the physical space.
I have a great illustration with a simple product I cannot find : a _modern_ … alarm clock.
I’ve been searching for the ultimate alarm clock in a while with the following list of must have :
- FM/AM and DAB+
- Decent sound/speaker
- Nice ringtones (with decent sound) and not just beep beep beep or a radio station …
- A brightness suitable for an alarm clock (that’s something we aren’t able to make anymore it seems or nobody cares anymore)
- Physical buttons that you can use in the dark
- Good build quality
And that’s all.
It’s not an unreasonable list of features. In fact, most alarm clocks on the market have most of those features, nothing in this list is exceptional. Yet, I totally fail to find one that have it all.
It just feels like objects are all the same now and that nobody cares.
Sure, you can use your smartphone as an alarm clock. But even if you wanted (I don’t) it doesn’t check all those requirements.
At this point I'd settle for one where the button on top just lights up the numbers without playing awful compressed babbling brook sounds at full volume.
I like to use the TM1640 and RGB LEDs. It's cheap, works well, requires a minimum of external components, and can convey a fair amount of information. It can also drive a 16x8 LED matrix if I do want something screen-like.
Usually I'll control it with a Wi-Fi MCU like the ESP8266 or Pi Pico W. Total component cost, including board, sits around 5$ each with a minimum quantity of 5.
Could you elaborate on these hardware projects? They sound cool.
If your workflow lets you crank out hardware quickly and cheaply enough for just a marketing stunt, you must be using methodologies we could learn from.
I’m not convinced developers just like normal screens though, tactile/analogue widgets are always cool and welcome!
It's not my place to go into details as to what it is at this time, and there are other people involved on here!
The build is neither cheap nor fast, though the proof of concept was. If you are aiming at a dev/maker audience telling them to configure things with ESP Flasher will work. If it's for some random person then it won't, and the complexity explodes.
I would caution anyone going into this because almost everyone you speak to will radically underestimate the difference between the proof of concept and a shippable product, even a giveaway one, with the consequence that most people respond as if it's a high school science project and not real work.
> radically underestimate the difference between the proof of concept and a shippable product
LOL. I had my boss call me out on this once. I made an offhand comment about doing something "in a few days" while on a customer call (yeah, I should have known better), leaving him to patiently explain to the customer that I meant a basic PoC and that would actually take us quite a few weeks to productize after we got it working :-)
> you must be using methodologies we could learn from
Not necessarily. You usually just need to know where to/what to buy.
e.g., someone on Reddit posted about being able to automate taking a photograph every time someone walked by. Turns out that I had an unused Raspberry Pi and a cheap webcam AND a passive-IR sensor. Half an hour of research into Linux command line webcam control and an hour later I had a proof of concept. Just lucked out that I have a well-stocked junk box.
But for most quick hardware things I'd turn to Arduino. I'm a professional embedded systems engineer. Arduino makes prototyping stuff that would have taken weeks or months just 10 years ago, doable in hours.
If for some reason, Arduino wasn't around, then I could use the "dev boards" that all microcontroller manufacturers provide to let you learn about their systems. Generally, they're below a $20 price point and come with enough I/O to do something useful and tooling is free.
I could probably go on, but there's enough stuff here to google if you're really interested :-)
When someone mentions smart devices without screens, I’m always reminded of David Rose’s work on what he called “Enchanted Objects”. If you look on YouTube, you should be able to find some talks he did at TED and Google highlighting his work.
They're right too. "Let's install random drivers to get the USB serial to work" etc.
Working on it was one of the motivations for https://github.com/atomirex/umbrella where I'm basically trying to control more from the access point since I believe these devices need strict separation from everything else. (That code also is essentially a golang superset of the C++ on the device).
This really echos our own experience at BLINX [1].
Pr. Marc Feeley's lab develops codeBoot [2], an online IDE to teach students programming (and more!). We created BLINX as a hardware platform for students to go along with our IDE. The device acts as a data collector for various Grove sensors and publishes the data as an HTTP endpoint. You can program it directly from codeBoot.
BTW if anybody has any questions feel free to reach out!
the options for hobby electronics these days are incredible, you can get a microcontroller for under 20 bucks and attach it to almost any sensor, light, or display you can imagine — add a little beginner python and it's connected to your smart home
Your renderer looks awesome! I was surprised there wasn't an "off the shelf" SVG renderer in native TS/JS, it's a big deal to be able to create 3D models without a heavy engine for visual snapshot testing!
Circuit boards have holes, cutouts and import STL/OBJ components that we'll eventually support in this 3d renderer. Assuming we get that far I may have to rename it from "simple-3d-svg"!
I think you'll probably run into performance problems with SVG before you get too far. I can't imagine SVG will perform fluidly with complex circuit boards.
SVG elements are DOM elements after all, and too many DOM elements will cause browser performance issues. I know this the hard way, after adding a few hundred SVG <path> elements with a few hundred <div> elements in a React-based interactive web application, I ended up needing to move to a canvas solution instead, which works amazingly well.
I really hope you have all that figured out, because I don't think it's going to work well using SVG to render complex circuit boards. But maybe your product is only working with very simple circuit boards?
Because it’s only being used for power and doesn’t need a lot of power, it works for the simple board we rendered. In practice you would absolutely want to set the CC1 and CC2 configuration with resistors!
