How I optimized meetings at work
I love working at Augury. Everyone is so colorful, friendly, intelligent, fun. Everything flow’s toward achieving impact together.
While working from home, virtual meeting with these kinda people are fantastic, healthy, stressless, and impactful but has the potential to drift to offtopic discussions and (sometimes) overflow meeting duration.
Solving this problem is easy in many ways. I chose the Maker way :)
and built a meeting progress bar 🚦
Using a Minion, I found in the trash the other day. I stuffed inside a microcontroller called ESP32-CAM and some LEDs. This ESP32-CAM connects to the WIFI, fetches my work’s calendar, and, If I’m currently in a meeting, turns the LEDs on one after the other as the meeting goes, finally, plays a song once the meeting is over.
This is a series of posts that contains
- a show-and-tell post [This one]
- a detailed how-I-did-it post [Comming soon]
A few months back, I’ve found this Minion in the trash.
This Minion has a button on his stomach that plays a lullaby.
Immediately I knew this was the sound want everyone to hear when a meeting was overflowed. I also knew that a good boy-scout-maker must add some addressable LEDs to it for awesomeness maximization. Immediately, I delved in:
First, to do this project, I had some catching up to do:
- How to use RESTful API and use google-calendar API?
- How to use Postman?
- What is a token, and how to refresh it?
google-calendar API
Google provides a RESTful API to create/delete/change/get information related to the calendar without using UI. Using this API is relatively easy — once it is understood, also it’s well documented. All I needed was my organization’s google-calendar and a “device_code” for generating & refreshing my tokens.
At first, I played with the provided Try-this-method box [At the right] on google calendar’s documentation site.
There I progressively learned how to get all today’s events. Once I accomplished that, I copied the generated URL from the Try-this-method to Postman. The generated URL is filled with filters and other flags that I need for getting the events I need, Here’s an exmample:
A list of must-have filters:
- q — a free-text filter that searches through all the characters in the calendar and compares to a given text
- fields — what fields to bring back as a result
- timeMin — Lower bound of event end-time
- timeMax — Upper bound of event start-time
One exciting thing I’ve learned:
When adding timeMin and timeMax to the URL, the query returns a slice from the calendar. Otherwise, it returns all events since the beginning of time.
Postman
An excellent, well-documented API platform for building and using APIs. Using this platform, I quickly understand how to work with google-calendar API outside the “Try-this-method.”
Another super-cool feature Postman has — generating from the API tab used for making API called an “API call script” in any language!
This helped me so much when I started writing the actual CPP code on the board.
Once I’ve learned how to correctly perform an API call without NOT-FOUND or UNSSUPORTED-URL error codes, I started to get 401-UNAUTHORIZED error code. This means I’m on the right track, according to google’s documentation:
Finally, after successfully generating a token, I got my calendar events:
Generating a token then requesting for today’s event was the hardest part. I never messed with RESTful APIs or token generations and authentications, nor did I ever use the google cloud console (GCP) to create my own “device” to enable the token generation.
The rest of the project was relatively easy.
- Parsing the requested bytes stream into a list of Event objects
- Finding out if I’m currently in an event
- Turning LED’s relative to event’s progress
- Finally, I soldered everything and stuffed the Minion with all the components.
For those who see the green balloon and wonder — I needed some isolating protection for a resistor & a capacitor that protects the GPIO pin that sends PWM to the speaker 😺
Bottom line
Although I work as an embedded Linux engineer, I develop and research using tons of data from various cloud-based databases. In the beginning, when the team told me to use Postman for getting some information, I blindly applied the instructions others gave me — No questions asked.
Tanks to this project, I learned Postman from 0 to 70%, which is more than enough for what I do, same with RESTful API and token generation.
Knowing these two in an IoT company is an advantage.
Working on these projects,
I confront challenges from real-life problems at work; I learn a lot and quickly become a go-to person in these areas. It’s rewardful.
Writing these posts,
I summarize everything I’ve learned. Put a stamp on it and move on.
Cheers,
Gal
