DevOps

I remember back to when I first learned Python. It was a strange decision for a happily employed post-graduate to make, especially for a time when many were screaming for the death of the language with Guido's (outrageous?) grand reveal of Python 3.  The Ruby on Rails guys seemed to be doing just fine. Those were the days.

After weeks of sweating over a keyboard in the basement of an illegal BedStuy hostel, I had finally set out what I had hoped to achieve. It was the greatest credential any programmer could possibly strive for: yes ladies and gentlemen, none

So you've taken a leap and decided to host your VPS on Google Cloud: let me be the first to congratulate you on joining the clearly superior cloud platform of our modern era. I would apologize for being so openly opinionated, but so far I've only stated objective facts.

Now that you've joined the club, you may have found yourself asking the inevitable: "how do I connect to my damn instance?" If you're like me, you're probably not the kind of person who enjoys this as their main solution:

Luckily for us, there are a few

I've found that the strength of Google Cloud's services comes from consistently delivering across a few key metrics, namely reliability and performance. When dealing with SQL databases, it's hard to imagine any metrics more important than these two things, and Google's Cloud SQL delivers.

To become familiar with Cloud SQL, we're going to walk through the creation of a SQL database and explore the advantages Google Cloud offers us when compared to other solutions. We'll also be dipping into the Cloud SQL API to see how we might manage our SQL database programmatically.

Cloud SQL Versus Alternatives

There aren't many

Before we get into the specifics of how to sadistically abuse Tableau, let's clear the air: there's something about inaccessible, expensive, proprietary enterprise software that tends to put me in a touchy mood. As we know, B2B software pricing has nothing to do with code quality or even value-add, but rather the tendency of businesses to create time-based urgencies without warning; the kinds of urgencies which may be solved by, say, a tool of sorts.

My first interaction with Tableau actually took place after I had committed myself to the cult of Python's Pandas library and all that comes with

Let's say you're a Data Scientist. Well, maybe not a data scientist- I mean, those online data analysis courses were definitely worth it, and you'd made it this far without being quizzed on Bayesian linear regression. So maybe you're an analyst or something, but whatever:  you use Tableau, So you must be a Scientist™.

I've admitted a few times in the past to have purchased a personal Tableau Server license in my more ignorant years (aka a few months ago). While BI tools are great for understanding preexisting data, they don't allow us to go much further. This is is

I've been enamored with Google's cloud platform (aptly named Google Cloud Platform). GCP contains the things you might expect from a young player in the cloud provider space; a lot of existing AWS services already have an equivalent on GPC, but the comparison isn't always 1-to-1.

A seemingly prevalent philosophy behind GCP is prioritizing reliability and simplicity over features. It's a philosophy I agree with but occasionally comes up short from AWS's offering. GCP is the first contender to package enterprise cloud computing in a simple, satisfying way. Its clear GCP has assigned UI and Product Management resources to their

There comes a surreal moment in nearly every profession in which perspective violently forces itself into our self-awareness. People with cooler jobs probably have that moment when they save their first patient or launch their first rocket. For me, the idea of building an API was this moment in software development. All those past black boxes which spat out results your life depended on: we can make those now.

Feel free to remain unfazed by this as I'm sure most are... for those of us who can't remember how they became an "engineer" in the first place, API design feels

Last time we became familiar with the handiwork of setting up MySQL locally, navigating databases via command line, and exposing your database to external access. While badass, it has come to my attention that most people don't bother doing things this way. Unless you're getting deep into some heavy architecture, most people opt to use cloud services such as AWS to set up databases which are intended to be interacted with by multiple services.

A perfect example is one we ran into over the weekend while working on this very blog. We're running a Ghost instance, which is respectably complex

In the previous post, we got familiar with the basics of creating and navigating MySQL databases. This leads us to the next most logical thing to ask: how can I use this in any meaningful way?

MySQL installations default to refusing connections outside of the local machine's IP address, as we should expect. That said, relational databases aren't usually being used by a single person on a single machine forever (but if you do, we should hang out). It goes without saying that our MySQL instance should be focusing on uptime and accessibility, or in other terms, far away from

As frameworks and services evolve to remove us further away from boilerplate code, the first casualty of saved time is the fundamental understanding of what we're actually doing sometimes. This has good reason; one can only learn so much from repetitive command-line interactions with databases, thus making any service's one-click-deploy button all the more sensible.  If I  had to imagine the least sexy title for a post in software development, it would be something along the lines of How to Configure MySQL on a VPS, as opposed to like, a cloud-based solution, or Even a Docker Container, as Though we