Even given the current situation, part of my Developer Advocate job is to talk at (virtual) conferences. Sometimes, organizers invite me. Yet, most of the times, I need to take part in a CfP. With the sheer numbers of conferences I submit to, I need a tool to manage the status of each submission. Since I started, Trello has been my tool of choice. I’ve a dedicated board with several defined columns: backlog, abandoned, submitted, rejected, submitted and done. A conference is a card that I move around, depending on its status.
Trello is for my own use. Besides it, my company needs to have a consolidated view for all speakers. We have a Google Sheet document for everybody to write down their talks and their respective status: it lists each talk with some data about it e.g. the conference name, its website, its location, its start and end date, the name of the proposed talk, the talk’s status, etc. Finally, I also put every event into my shared Google Calendar.
So, every time I submit, I need to:
- Move the card from the backlog column to the submitted column
- Remove the CfP’s due date on the card
- Add the entry into my Google calendar, with the "Free" status
- Add one entry per talk in the Google Sheet
Likewise, when I receive an acceptance or a rejection notice, I need to update the data in Trello, Google Calendar and Google Sheets. Not only does it take a sizeable part of my time, it’s also boring, and there’s always a chance for mistakes. With a developer mindset decided, those conditions lead to automate those tasks.
In this post, I’ll describe the technology stack I used, and the reasons for my choice.
The tech stack
- Kotlin
-
Kotlin has been my language of choice for several years. Beside having the benefit of using a familiar JVM environment, it allows me to write smaller classes, and to put them all in the same file. While certainly possible in Java (one public class, several non-public ones), this is not something that’s taken for granted.
However, for me, the greatest advantage of Kotlin is extensions - properties and functions. Instead of creating for the umpteenth time a
StringUtilsclass with static methods - or slightly better, use an existing library e.g. Apache Commons Lang or Guava, just add the state or behavior you want on an existing type. This increases readability and improves the design IMHO. - Spring Boot
-
I’ve been using the Spring framework for more than a decade, and always found it helped a lot regarding the day-to-day work of developing applications. Spring Boot helped a lot with removing the bore out of declaring the same beans across different projects e.g.
InternalViewResolveris the poster child of repeating the same bean with the same configuration. Icing on the cake, the convention-over-configuration approach allows the Actuator Starter, which is a great tool to let developers know about operations. - Camunda BPM
-
In my first Java position, my job was to implement workflows using an old engine called Staffware. Surprisingly enough, I never used workflow/BPM engines afterwards. I even believed they were dead. IMHO, the biggest issue with BPM is that it contains two words that both frighten developers: business and process. Recently, I watched an interesting BPM use-case for microservices that made me think BPMN.
Hence, I decided to give it a try. Also, a really good thing about BPM is BPMN. With it, it’s possible to get a visual representation any standardized workflow. With code alone, it’s hard to get a picture of a workflow in one’s head when one is not familiar with the code base.
For example, the following diagram is the equivalent BPMN of the workflows described above:
Overview
The whole idea is based on the fact that each relevant change in Trello, such as moving the card from column to column, should trigger an event with the required data. Trello provides a way to listen to such event through webhooks.
- To being with, one needs to create the webhook, with the URL of the endpoint
- Trello will then work its magic, and send event data every time a change happens to the endpoint previously registered
Testing locally
Before writing any production-grade code, one should consider how to test it locally.
Most web applications are more or less self-contained:
they are developed within the scope of an IDE.
Then, it takes care of starting the application and exposing its endpoints.
The developer can then query 127.0.0.1 (or localhost).
Webhooks need a publicly accessible endpoint, which localhost is not.
The traditional way to handle that is to start a public proxy that logs HTTP payload, and make the webhook point to the proxy.
Then, one triggers the webhook:
it’s now possible to access the logs containing the payload.
It can then be used - and reused - in a self-contained environment for testing purposes.
Another way is to use a tunneling proxy from a public adress to the local machine. There are several such tools available that follow the same principles: ngrok, Localtunnel, Teleconsole, etc.
ngrok has been under my radar for some time, plus it ticked all my checkboxes, including a free tier that is enough for my needs.
- Install the binary:
homebrew install ngrok - Launch
ngrokwith the protocol (http/s,tcpandtls) and the port it needs to redirect to:ngrok http 8080 - Finally, if a firewall is managing the traffic between the Internet and the local machine, it needs to be configured to direct the traffic to the later.
Conclusion
While I’m not in a developer position right now, I still have a developer mindset: everything that can be automated and is done manually is a waste of my time.
In this post, I described the submission process I have to follow, the technology stack I want to set up and the how we could test a webhook on a local machine. In the next post, I’ll go into the details of development itself, and the hiccups I had to go trough. Spoiler: there are a lot of them!