This is a really cool project that I would perhaps like to try myself one day! A home weather station has been on my list for several years.
Now I will say something negative. It's a nit, but I think it needs to be said.
I've seen a lot of these "In which I write a (perhaps series of) essays on building X using all kinds of cool tech you'd probably like to play with when you could get the same result with less than ten bucks, maybe an hour or two, and just a handful of code, if any"
I'm okay with and completely love "Let's do something cool and learn!" I'm not okay with "I have this problem, so let me by implication teach you how you should architect problems when you run across them" We need to clearly differentiate. You should not, and you should never, start with an important project and begin speculating on what cool tech you could play with.
Playing and learning are great. Yay! Adding structure and complexity where none is needed is an antipattern if you're doing anything of value for yourself or somebody else. This stack might end up being necessary. Absolutely. Make the problem "prove" that it's necessary. You should have a clear and unambiguous process for choosing a stack; do it by necessity. Never even accidentally teach that you do it by "hey, that's cool!" People end up doing that, and somebody ends up having to clean it up.
tl;dr Love fun projects like this. Keep 'em coming. Just please be sure you're clear to the reader that they're learning/fun projects.
* Perfectly fine to add a tech or two to a new project in order to learn-as-you-work, it should just be done with the upmost care and a close eye to how much team bandwidth it's using versus the value being provided and how you'd back it out if you had to.
Hi Daniel. Thanks a lot for the comment. This makes sense. We all should choose right tools for the right job and architect our solutions according to the requirements and restrictions we have.
One of my original goals was to make the financial entry-barrier as low as possible. Another — to provide educational context for covering a full-stack IoT development from firmware to backend to frontend. This means using cheap hardware and open-source software. In fact, I spent around 9$ on everything that was needed for this project.
I wouldn't say that this project is over-engineered with cool tech. I tried to keep the setup as minimal as possible, sticking to industry-standard data exchange protocols and frameworks.
Of course, all of the software part could be written using ANSI C or C++, but from my point of view, it wouldn't make the project simpler, because there are more specialized tools that are better suited for the particular task, be it backend, frontend or firmware (Rust, HTML5+JS and C in case of this project). I have outlined rationalization behind this particular technology stack under the "Choosing the technology stack" heading.
You are right that in a commercial setting, there might be myriad more inputs that constrain the technology choice like team experience, your company's recommended technology stack and etc. Of course, we can't take into consideration all these hypothetical requirements, as they depend on the environment you are working in and the commercial goals of the project.
To make your comment complete, could you share your ideas on how to architect this alternatively to get the same result with less than ten bucks, maybe an hour or two, and just a handful of code, if any? If it is a viable alternative I'll consider adding it into the post as an alternative tech stack, so people reading it will see more alternative options on how to build this project.
Thank you for taking my comment in the spirit it was intended. I'm happy to oblige you.
If your goal is to play and learn about stuff, whatever you're doing is fine.
If your goal is to get basic weather information, buy a used weather station with usb access, plug it up to whatever hobby computer you already have (I have a pi, so I'd use that). Then write a cron to read from the station and write it out to some publicly-available spreadsheet or database. There are a bunch: Google, Airtable, and so on. Most all of these can be written by one POST.
Then you can figure out how you'd like to see the data. Add in a station ID for more fun and a distributed system. I'm seeing Ebay new weather stations as low as 24 bucks or so. That'd be the only cost I know of, and I think with some searching for used gear you could get it under $10.
There's a _huge_ difference between focusing on the problem and focusing on the tech. If you're preparing yourself for a world of corporate coding? Please keep learning about message queues and so forth! You'll need those skills. If, however, you just want to know the weather in various places with your own setup? Do that. Just don't do one of those things while pretending you're doing both. Each project has vastly-different parameters.
To drive this home, if I've decided I want a coder to come to my office and make a cool little way of telling the weather outside? I want the project that just does that. Code for an hour or two, then leave. If you come and start deploying a kubernetes cloud-based auto-scaling megasytem, you're coding for yourself instead of my problem. My only point was that since there is such a huge gap, when you teach people you should be clear about the hidden lessons of what you're teaching.
* Now traditionally programmers throw out a lot of "what if"s here. What if we needed split-second reports? What if we're dealing with an offline situation or a saturated net? All of those are great considerations. Also, all of those were not included in the spec I read back to you. Don't go inventing what-ifs where none existed. It's a good way to build unmaintable monsters. Hopefully you got the point. It was a minor point and not directed at you, just a comment on cool-tech articles in general. (Also, I'd love to demo actually building it, but it would probably be quite less dramatic and interesting than your version, for the reasons I explain above)
Keep up the good writing! Looking forward to reading you again.
Now I will say something negative. It's a nit, but I think it needs to be said.
I've seen a lot of these "In which I write a (perhaps series of) essays on building X using all kinds of cool tech you'd probably like to play with when you could get the same result with less than ten bucks, maybe an hour or two, and just a handful of code, if any"
I'm okay with and completely love "Let's do something cool and learn!" I'm not okay with "I have this problem, so let me by implication teach you how you should architect problems when you run across them" We need to clearly differentiate. You should not, and you should never, start with an important project and begin speculating on what cool tech you could play with.
Playing and learning are great. Yay! Adding structure and complexity where none is needed is an antipattern if you're doing anything of value for yourself or somebody else. This stack might end up being necessary. Absolutely. Make the problem "prove" that it's necessary. You should have a clear and unambiguous process for choosing a stack; do it by necessity. Never even accidentally teach that you do it by "hey, that's cool!" People end up doing that, and somebody ends up having to clean it up.
tl;dr Love fun projects like this. Keep 'em coming. Just please be sure you're clear to the reader that they're learning/fun projects.
* Perfectly fine to add a tech or two to a new project in order to learn-as-you-work, it should just be done with the upmost care and a close eye to how much team bandwidth it's using versus the value being provided and how you'd back it out if you had to.