When developing the book, I didn't have any additional meters or sensors to cross reference measurements with so I can't comment on the accuracy unfortunately. But I did notice that the changes in measurements made sense when the environment changed. I.e when I would exhale on the sensor, the measurement would rise and fall.
To clarify, the OP said: "I have neither time nor workshop space to solder and assemble anything more trivial than "plug a sensor into an ESP32 and screw both into a box"."
The book is very much "plug in a sensor" style as everything is connected via Qwiic cables.
Hey there! My co-authors and I actually wrote a book on this topic earlier this year. It walks you though setting up a weather station with Elixir and Nerves using a Raspberry Pi and the following sensors:
After you set up the hardware side of things, you put together a very simple Elixir Phoenix REST API and persist the sensor data into Postgres (with the TimescaleDB extension).
And to wrap up the book, you learn how to create Grafana dashboards to visualize all your time-series data.
Everything is meant to be set up on your LAN and everything can be run either natively or in Docker (there is a Docker compose file in the repo).
Really appreciate the kind words and happy to hear that you are enjoying the book! Hugo Baraúna and I have really enjoyed putting this book together and feel that Livebook has become pivotal in explaining certain topics and really understanding how things work under the hood. I wrote a blog post about some of my thoughts around Livebook as a learning tool on the DashBit blog: https://dashbit.co/blog/livebook-as-an-educational-tool
I have been using LiveView for over a year now in production applications, and I must say...it has been a breath of fresh air when developing web applications. The amount of product that you can deliver per unit time is unmatchable (in my opinion of course). The ceiling for what you can accomplish with a single tech stack (Elixir in this case) has definitely been lifted considerably.
Demo applications such as this show exactly what is possible in this tech stack and should make you question whether you need to make that leap to an SPA. At some point you will possibly need to lean on an SPA tool like Vue or React, but I think that point is now further away with tools like LiveView (Elixir), Hotwire (Ruby), and Livewire (PHP).
For a lot of the LiveView applications that I write (which is actually quite a few these days), I will usually lean on something like AlpineJS for frontend specific interactions, and my LiveView state is for things that require backend state.
For example, if I have a flag to show/hide a modal to confirm a resource delete, the show/hide flag would live in AlpineJS, while the resource I was deleting would live in the state of my LiveView.
This way, there are no round trips to the server over websocket to toggle the modal. Hopefully that example makes sense :).
I personally don't miss statically typed languages having worked professionally with Java, C++, and Typescript in the past. But if static typing is your cup of tea and you want to run on the BEAM, be sure to check out the Gleam programming language https://gleam.run/
In my day to day work I don't write many GenServers either and I think that's a good thing. Like any tool, they can be overused and abused. It is best to stick to modules and pure functions until you really need to pull the stateful lever.
To that point, GenServers as an abstraction are super powerful and when applicable, are an amazing tool. For example, being able to control the initialization of a supervision trees using :ignore in the init callback can be handy to run DB migrations as part of the application startup. Or when used in combination with a registry it can be useful to hold on to user data in a GenServer and access it atomically across your cluster.
Author here. Glad you like the banner image and the zooming effect :).
Perhaps I miscommunicated what I took away from the StackOverflow survey. The point that I was trying to make was that in relation to other programming languages in the survey, Elixir ranked high with regards to how loved it is. The StackOverflow survey is just one data point in addition to the others that I bring up and like many surveys has it's own issues (like WebAssembly being a compilation target as opposed to a programming language the people program in).
That standalone HTTP server in PromEx can also be used to expose metrics in non-Phoenix applications. In the coming weeks you'll also be able to run GrafanaAgent in the PromEx supervision tree so you can push Prometheus metrics via remote_write. Stay tuned ;)!
As someone who has been programming with Elixir for my day job for the past few years, I find this aspect of the language to be super pragmatic and productive. It's a nice feeling to not have to chase new language features and syntax and focus more on the problem at hand. In addition, I've never felt limited by the language given that the underlying constructs are so powerful (message passing, immutability, pattern matching, etc). Glad that Jose made the decision that he did.
Another example was when I opened my window in my office. CO2 immediately dropped off (15:42 timestamp): https://twitter.com/akoutmos/status/1443233937015418891/phot...