akoutmos

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.

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...

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:

- 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...

Co-author of Elixir Patterns here :).

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).

Thanks for the kind words :)

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.

Testing with the database has to be one of the things I love the most about Ecto. No need to mock anything, no need to have special branching logic for test versus prod. Just use the database like you normally do. It gives you a degree of confidence that is on another level. Check out https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html for more info!

While there is no automatic way of doing it (as far as I know), I have been using Tailwind's @apply directive for things that are used site wide and that has worked out well. Really excited to use the latest 1.7 version that makes this process even easier given you don't need to split up pseudo classes https://github.com/tailwindlabs/tailwindcss/pull/2159.

That is definitely a valid route to go so long as your rate limiting is not dependent on much business logic. If rate limiting is per user or per user per instance/service, I would personally bring that kind of concern into the application where it is closer to the persistence layer where those things are defined (and again handling the business logic inside per customer GenServers).

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.

Great article and thanks for sharing! There are a couple of things that stand out at me as possible architecture smells (hopefully this comes across as positive constructive criticism :)).

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 would be very interested in working together on a publication...unfortunately the last couple times I submitted a proposal I never heard back. Is the write-with-us form page working properly, or was my proposal that bad :P ?

https://akoutmos.com/

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!

In this post I cover how to leverage RabbitMQ along side Broadway to process data from the HackerNews Firebase API. I also leverage Prometheus and Grafana to monitor the application and ensure that the pipeline is performing as expected.

That's the approach that I take as well most of the time. Makes it pretty seamless to then take that container and run it in your cloud provider of choice. I put together a blog post outlining the use of Docker + Mix Releases for a Phoenix app https://akoutmos.com/post/multipart-docker-and-elixir-1.9-re... to help people get started.

Great post and thanks for sharing! I've been seeing quite a bit of Render these days. Does anyone have any production experience with it and what are your thoughts? Also for those interested in using Elixir 1.9 releases along with Docker, I wrote a blog post a couple months ago: https://akoutmos.com/post/multipart-docker-and-elixir-1.9-re...