The CAN bus side of things starts at 8m05s
93 karma · joined August 17, 2019
The CAN bus side of things starts at 8m05s
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...
The book is very much "plug in a sensor" style as everything is connected via Qwiic cables.
- VEML6030 light sensor - BME680 environmental sensor - SGP30 air quality sensor
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).
Hope that helps!
GitHub Repo: https://github.com/akoutmos/nerves_weather_station Book: https://pragprog.com/titles/passweather/build-a-weather-stat...
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
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 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 :).
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.
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 ;)!
I have never used this product so just speculation. But I imagine there is some sort of auth token that valid agents send to tell Bearer that this is a valid/invalid request so that things can be trivially rejected to mitigate a DoS/DDoS to an extent.
As someone who has been developing on the BEAM for long time now, it usually sticks out like a sore thumb any time I see Elixir/Erlang paired with Redis. Not that there is anything wrong with Redis, but most of the time you can save yourself the additional Ops dependency and application network hop by bringing that state into your application (BEAM languages excel at writing stateful applications).
In the article you write that you were using Redis for rate limit checks. You could have very easily bundled that validation into the Elixir application and had for example a single GenServer running per customer that performs the rate limiting validation (I actually wrote a blog post on this using the leaky bucket and token bucket algorithms https://akoutmos.com/post/rate-limiting-with-genservers/). Pair this with hot code deployments, you would not lose rate limit values across application deployments.
I would be curious to see how much more mileage you could have gotten with that given that the Node application would not have to make network calls to the Elixir service and Redis.
Just wanted to share that little tidbit as it is something that I see quite often with people new to the BEAM :). Thanks again for sharing!
I started a blog the middle of last year and have written mostly about topics related to Elixir. But have also covered topics like RabbitMQ, Prometheus, Grafana, and PostGIS. I find my own blog very useful as I often reference the associated GitHub tutorial projects to remind myself how I did something :D.
Next week's post is about using Loki for structured logging!