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:
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.
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
class 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.
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.
is 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.
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:
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
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
Webhooks need a publicly accessible endpoint, which
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.
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.
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!
Originally published at A Java Geek on May 10, 2020