In a personal project of mine, I regularly fetched data collected by bicycle counting stations scattered around Cologne, Germany, and stored the data in a public GitHub repository. I ran the Python script which was fetching, appending, and uploading the data to GitHub manually for a while, but since I (am lazy and) wanted to always offer the latest data, I thought about how I could automate this process. Here’s how I accomplished running the reoccurring process with GitHub Actions.
At first, I thought about using the popular Oban library written in Elixir to run a reoccurring job, but every time the job would have been run, I would have to clone the repository, fetch the data, commit the changes and push everything to GitHub using a personal access token. Since I could not use
git commands directly from Elixir, I would also have to use a wrapper library like Xgit. This seemed way too complicated and the friendly Elixir community pointed me towards using
scheduled GitHub Actions. …
My team at Studitemps and I ran into the problem that we had multiple services, which needed to be served from the same URL. We had one service running the Elixir + Phoenix stack that we considered our “main service”. This service should be accessible under an URL like
https://example.com. We also had another service serving our content, which we wanted to integrate into the navigation bar of our main service. We wanted the content service to be accessible under e.g.
We decided on using AWS CloudFront to route the requests to the appropriate services. In order to do that, we first needed to create 2 Origins, one forwarding any request to our main service and one to the content service. These were our settings for the Origin of our main service. The settings for the content service where exactly the same except for the Origin Domain Name and Origin ID. …
Here at Studitemps, we have to comply with many rules and regulations that we have to be certain are followed by our software as well. These business requirements have to be poured into production code 1-to-1. Otherwise, we risk losing our students, customers, and at worst, our license.
Therefore, we have to make sure that our software behaves in certain ways. We have developed a process of extracting and implementing business requirements and to make sure that our software will always operate as needed, even when we develop our software further.
Before we can implement business requirements, we have to understand exactly what they are. For that, we interview our stakeholders about their needs. Talks like this tend to start with a concrete solution idea with which the stakeholder comes into the meeting. The goal of the interview is however to first understand the problem that we need to solve and only then are we brainstorming about potential solution ideas. …
Writing code is fun, but nothing tops seeing your code moving things in the real world. That’s why I tested out the Nerves library and used $20 of Raspberry Pi utensils to let software wave a flag for me.
For this project, I used the following hardware:
Here’s an overview of how to connect the ULN2003 to the Raspberry Pi.
After you connect the ULN2003 Board to the Pi, connect the Stepper Motor to the ULN2003 and the Pi to your Computer. IMPORTANT: Connect the Pi to your Computer using the USB port and not the PWR port. Otherwise, you will not be able to transfer or execute code from your Computer on the Pi. …
With Phoenix LiveView, adding interactivity and displaying state changes without reloading the page becomes trivial. The complexity and loss of productivity due to context switching decreases significantly by eliminating the split between the backend and frontend code. …