If you really want to write really performant java code, the word "spring" should not even be mentioned. Same thing for Jackson, write you own lazy json library if the data is bigger than a few 100k.
The code will not look pretty but it will be very fast.
A huge mistake, I've seen a lot of code where clearly the author thought that just adding "synchronized" would have solved any concurrency issue. And no one even talks about how synchronized is implemented, basically a monitor on the object.
The point of view is usually also wrong, they focus on the method call flow while they should think about protecting access to shared data.
Sadly it's not maintained anymore and even the intellijidea-derived decompilers are better nowadays (used to be horrible until a few years ago).
In addition to the limitation to classfiles built for Java8, it sadly has a hard time decompiling new language features even if compiled for a Java8 target. And then there is the well known bug that decompiling full jars in bulk does not get you the same output you see in the UI but orders of magnitude worse... jd was great until it lasted, helped me solve a lot of issues with verdors over the years.
In my opinion, you shouldn't expose it to a browser, it's not what is good at, build something custom that converts to json. Like using REST to talk between backend services, makes no sense using a human readable protocol/api especially if there are performance requirements (not a call every now and then with a small amount of data returned).
As someone that used it for years with the same problems he describes... spot on analysis, the library does too much for you (e.g. reconnection handling) and handling even basic recovery is a bit a nuisance for newbies. And yes, when you get random failures good luck figuring out that maybe is just a router in the middle of the path dropping packets because their http2 filtering is full of bugs.
I like a lot of things about it and used it extensively instead of the inferior REST alternative, but I recommend to be aware of the limitations/nuisances. Not all issues will be simply solved looking at stackoverflow.
AKA Bit banging PWM, never seen it working with this kind of displays, nice project, it can be done even with higher frequency signals too (requires an oscilloscope and a few tries to get a smooth signal).
Haven't checked Fuchsia in a while, very glad to see that they have extended the documentation.
Did they improve the initial steps to get up and running too?
(I remember it took hours to clone all the subprojects and most of the times something failed along the way, even worse than downloading the Android sources)
Can confirm that the internal pull up/down are there and most libraries can enable them (alternatively this can be done manually via terminal after each restart).
After recommending it for years on every HN book thread I could find I'm happy to see it's not forgotten yet, really, Egan could have written at least 3 separate books with the content of Permutation City.
The people from the blog he links (that I'm in the process of reading) wrote an application for macOS that reminds me of notational velocity in spirit but that has been made specifically for Zettelkasten and should be able to handle even huge amounts of notes (stored in plain text, the best format in my opinion, portable and all that): https://zettelkasten.de/the-archive/
Just FYI, since I've implemented something similar in Swift, using the PWM you would have had to implement more or less the same algorithm, i.e. changing the duty cycle of an high frequency signal to generate these "slot-based" patterns that identify the 0s and 1s of the WS281x (there are minimal timing differences between the variants) protocol.
Note: God bless the Oscilloscope, essential for these projects.
If you've never done embedded development before I highly recommend the two parts MOOC "Embedded Systems - Shape The World"[1].
The course is well structured, teaching the basics you'll need for those boards that doesn't usually have an OS and requires a ~40$ components kit that include a Texas Instruments board.
Quite fun if you follow along and do all the exercises.
> The only sensor in the scale is a weight sensor.
? Why not add a RFID reader (relatively cheap) to the scale and then add tags on the coffee bags to be able to log the consumption for multiple types?
You could even be able to identify the weight of multiple objects (tracking what's on the scale and how the weight changes when it's removed and when it's put back) on a bigger(longer?) scale.
And you could sell kits with tags that people could slap on their own containers and register multiple custom items.
I agree, "autonomous dash button" is a nice way to present it, but if it was capable of detecting what's on it, it would become more or less a "sentient dash button", way better ;)