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.
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.
It’s been two years since I left Microsoft, and they finally decided to cancel my free employee Azure account. It was fun while it lasted, but now I have to move my data to a regular paid account. I looked through the FAQs and contacted support for the easiest way to do this, and unfortunately there is no officially recommended solution for moving storage accounts between different subscriptions.
I found some Windows-only tools that may have done the job, but I wanted a solution that would run on any platform.
The Hadoop File System (HDFS) is a distributed and redundant file system that stores your data in chunks across multiple nodes. This allows for fault tolerant data storage (a node can die without the loss of data) as well as parallel data processing. If you want to store and analyze large amounts of data, Hadoop is a great option.
I recently read a great book called Data Analytics with Hadoop, and this post is based on what I learned there.
About a month ago, I got my Sift Science plugin added to the WordPress.org online store. To publish your plugin to the store, you’re required to use the SVN repository that they provide. Once you get that done correctly, users of WordPress can find and install your plugin through the built in store and they will also receive notifications whenever you publish a new version.
In this post, I describe how I manage releases of my Sift Science plugin.
A few weeks ago I learned an important lesson that I’d like to share: When building unit tests, never use a mock/stub unless it’s absolutely necessary. Let me explain with a little example.
Let’s say you’re working on a large project and you start developing Module A, which uses a MySQL database. To write a unit test for this module, you’re going to need to mock the MySQL queries. I have used sinon for this purpose and it’s worked great by the way.