With over 25 years of experience in the Java ecosystem, I specialize in building high-scale, real-time recommendation engines and distributed data platforms.
I am currently 6 months out from launching a new venture in the Machine Learning and Cloud Services space, focusing on low-latency decision intelligence.
In my first post, I wrote about why I spent my first week writing zero business logic and instead built rig - our lightweight, POSIX-compliant local provisioning tool. It was my way of rejecting “wiki-ops” and applying Infrastructure-as-Code (IaC) discipline to our local environments so that a hardware failure means minutes of downtime, not a week.
But as I transitioned into Week Two, I was hit by a different kind of operational reality check.
Being made redundant from a position where I defined patterns and practices for a high-performance team, I decided to take the leap to create my own startup. As I write now, this has felt like a violent acceleration of the clock. One day you feel the safety of an established enterprise; the next, there I am, standing on a clean slate. When I finally received my new laptop last week, I felt the sudden urge to rush, install the software I needed, and start churning out lines of code.
Through this article, we’re going to explore the GitLab CLI (glab) to help us query compute minutes consumed and remaining.
I created this helper script as I was iteratively making a lot of mistakes on my GitLab runners which was eating into my free 400 minutes that’s given when you sign up. I will now periodically run this to see how close I am and if I need to purchase additional credits.
Creating our own tools and helpers not only save us time in the long-run, but they do way more than that, they teach us more than we would have ever known about what’s available and give us incrementally acquired knowledge on many auxiliary tools and languages that we can flex throughout our careers.