A little while ago I did a talk at a meetup about Hexagonal Architecture which is recorded, see the Youtube video below.
For all whom are interested, you can find the demo application at Github.
The slides are available for download here.
While using RabbitMQ I got in a situation that some code was failing since an external service was unreachable. To overcome this problem I wanted to re-queue some messages for later processing. I decided that I wanted to wait for X seconds before trying again.
My solution to this problem is using (two) dead-letter-exchanges.
By returning a Negative Acknowledgement (NACK) on the failure of the external service, RabbitMQ will deliver the message to a configured dead letter exchange. By configuring this exchange correctly it will publish the messages on a retry queue with the delay interval set as the messages time to live. The retry queue (in its turn) has the dead letter exchange set to the main queue. So when the time to live interval passes the retry queue publishes the message back on the main queue again causing my initial code to process it again.
In the sample a negative acknowlegdment is returned when a message with body “10” is received. This NACK puts the message on the dead letter exchange with a message TTL of 5 seconds. After 5 seconds it is placed back on the main queue.
You can find the code sample at Github
For the ELC (a radio controlled aviation club) I’ve recently built a “permission to fly” dashboard/web application. Since the model airport we’re flying at is military training ground, it’s necessary to check at a special phone number if there are activities planned for that day. In order to prevent duplicate calls to that phone number, we built this “permission to fly” system. This is how it works:
The idea is relatively simple: a user calls to the responsible Defense department to check if flying is permitted at the time. He/she hangs up and sends a text message to a special phone number. The text is received by an Arduino Mega with GSM shield (located at the model airport, powered by a solar panel) which makes a call to the web application providing a phone number, check value (to make sure the request is legitimate) and the texts message (‘approved’ or ‘forbidden’).
The web application first matches the check value against an internal calculated value based on a secret key, the data sent and a time stamp. If this is correct (meaning the secret key was correct, the data is not tampered with and the request is not too old – in order to prevent replay actions) the web application will check the database for a user attached to this phone number. If found, it will update the status in the database, changing a webpage and returning the status to the Arduino Mega through a JSON message specifying the current updated status.
The Arduino Mega has 3 LEDs attached to it; green (which means flying is permitted), red (flying forbidden) or blue (no status yet). Based on the response given by the web application the LEDs will blink in the corresponding color.
Another boundary for flying is sunset/sunrise: flying is only allowed between sunrise and sunset. The on-site system retrieves the sunset and sunrise times, so it can power down it’s GSM shield at sunset and power it up at sunrise. This is done to save energy. The web application retrieves the sunset/sunrise times from this API, based on the coordinates of the airport.
Currently the dashboard is only showing the current status, but in the near future it will be used to show the sunset/sunrise times to the visitors so they know if its still worth the drive to go flying. Other considered functionality is to display live sensor data from the field, for example wind speed and direction, temperature and maybe even live streams. More ideas? Let me know.
Contact me if you would like to know more about the Arduino software/hardware and I’ll pass the questions on to the right person!