This is the second article in a series I plan to write about my experience learning and using Kubernetes. In the previous post I talked about why I wanted to use Kubernetes. In this post I will go over the main concepts of Kubernetes.
Summary If you don’t have time to read the entire article, here are the most important things to know.
Key Components of Kubernetes:
Node: A machine (or VPS) in your cluster Pod: One or more containers that run together ReplicaSet: Manages multiple pods and controls concurrency/redundancy Deployment: Manages deploying new versions of pod by spinning ReplicaSets up and down Service: Routes communication between pods Ingress: Routes requests from the outside world into your cluster Secret: Manages secrets that are deployed to pods Important concepts:
In this post I explain how I converted three sites from PHP/MySQL into statically served sites. Each of these sites was converted using a different approach.
Intro I recently got interested in statically generated sites after hearing about Hugo. I started with moving this blog over from WordPress. Once I got that done and felt more comfortable with the idea, I decided two more of my sites would also be better run statically.
I’ve been using Docker for a couple of years now, but only for running local development environments. That on its own is a great way to use it. With a simple "docker run" or "docker-compose up" you can have a project running locally without installing any prerequisites on your machine. It’s amazing how quickly technology advances. A few years ago, I wouldn’t have believed that you could run a WordPress site locally without installing nginx, php and mariadb (or Xampp).
When I started playing with Kubernetes a few months ago, there was one question that didn’t seem to have a clear answer: Where do I store the images that will be running in Kubernetes?
Most of the documentation and examples are for deploying ready-made services like nginx or MariaDB. The services tend to be open source with images publicly available on Docker Hub. But sooner or later you’re going to want to build a custom image and deploy it.
Welcome to my redesigned blog! I started this site a few years ago using WordPress. It was the natural choice since I worked for a company built around that ecosystem.
A few weeks ago I decided to move my site away from WordPress. This new site is built using Hugo, which is a big change from WordPress.
Hugo vs WordPress Hugo is a static site generator (SSG). Similar to WordPress, you have a theme that defines the overall look of your site and content that gets embedded in that layout.
TL;DR Some simple practices to help you write reasonably clean code, even when you’re in a hurry:
Split your code into small and simple functions Avoid too much indentation Use good variable and function names Don’t repeat yourself Do the easy optimizations Practice your trade Background Writing clean and elegant code is not easy, especially when you’re under pressure to deliver on a deadline. Sometimes you have to cut corners and whip something up that just works.
I needed a quick way to measure performance and log errors in my Sift Science for WooCommerce plugin. I didn’t want to go back through all my code and embed logging and timing measurement statements, so I considered a more generic and lazy approach.
I decided to create a class that wraps the class I want to measure/monitor. Its constructor takes a class instance, it saves that instance. Then, for every function call to the wrapper class, the function in the underlying class is called and information is logged as needed.
I’ve been using a little PHP script for the past few months to host my own private podcast. So I decided to clean it up a little and share it on GitHub.
A little background: I had some audio files that I wanted to listen through with the ability to increase the speed and pause at any time to continue later. This is everything that most podcast apps do. So I decided to host my own private podcast channel containing the audio files.
“I have a fantastic startup idea.”
You’d be surprised how often I hear this. When I do, it’s often followed by “All I need is a developer. Let’s partner up!”.
Now don’t get me wrong, I think entrepreneurship is a great thing, and I often hear ideas that are genuinely interesting. However, a great idea isn’t enough to justify taking on such an endeavor.
Over the years, through trial and many, many errors, I’ve developed a few rules to help filter these pitches.
WordPress provides a large number of hooks that allow plugins to extend and modify its behavior. A few months ago, I was curious about which of these hooks are popular, and which of them are hardly ever used. I was also looking for an excuse to give Microsoft’s Data Lake Analytics a spin. U-SQL looked especially attractive as it brought back fond memories of petabyte-scale data crunching at Bing.
With that in mind, I set out to build some tools that would calculate the usage of WordPress’s hooks.