Tag: work

My First Year at Shopify

This week I completed a full year at Shopify and it has been GREAT! I don’t think it would be an exaggeration to say that Shopify is the best place I’ve worked. This isn’t meant to diminish other places I’ve worked; I’ve had a lot of fun, made some great friends, and had some fantastic bosses throughout my career. Shopify is also far from perfect. That said, I just feel home at Shopify. I feel appreciated, I enjoy what I do, and I work with some fantastic people. I can get behind our mission and how we’re accomplishing it.

I’m astonishingly lucky to work at a job I love. I’m proud and honored to be associated with Shopify. I can’t wait to see what amazing things I’ll be a part of over the next year and beyond!

Three Months at Shopify

I just recently hit the three-month mark in my new position at Shopify. It has been an amazing experience, for sure. While I’ve definitely had other jobs that I enjoyed, I’ve never worked anywhere quite like Shopify or on my team. I’m working with some of my favorite technologies (like lots of Rails on Kubernetes and doing exciting things with MySQL), but it isn’t just that. The culture, especially on my team, has been fantastic. I have some really exciting (and solvable) challenges on the horizon, and I believe in our mission. I’m not drowning in work but there’s plenty to do. I can confidently say that the company does a good job of actually caring about us and our mental well-being.

This wasn’t meant to be a glowing review of Shopify as much as it is an insight into this new chapter of my life. Work is a huge part of who I am, so having it improve so much seems worth sharing. I’m genuinely excited to see where things go from here.

My Thoughts on Meetings

Meetings can take up a lot of time and cost companies a fair amount of money. They often distract from real work, and fill up our day. When we have too many of them, it is difficult to remain enthusiastic about participating. Here, I’ll provide my thoughts on meetings. I’ll make the case for why we should seek to reduce the amount of time we spend them, and why we should make the time we do spend in them as productive as possible.

Continue reading My Thoughts on Meetings

Kubernetes Node Affinity and EBS Volumes

Occasionally, Kubernetes workloads require specialized nodes. Sometimes it’s for machine learning, or to save money through burstable node types, or maybe just to lock certain Pods to a dedicated subset of nodes. Thankfully, Kubernetes offers a few useful mechanisms to inform the scheduler how we’d like our workloads distributed: node-based or pod-based affinity rules along with taints and tolerations. I’ll go over how to use these briefly, but I use these frequently at work for numerous reasons. Recently, I realized something interesting about how Persistent Volume Claims (PVCs) work with dynamically provisioned storage like EBS volumes (meaning volumes that are created automatically by Kubernetes based on a StorageClass, rather than referencing existing volumes). The default behavior of a StorageClass is to immediately create a volume as soon as the PVC is created. This can have some consequences when trying to guide how Pods are scheduled.

Continue reading Kubernetes Node Affinity and EBS Volumes

RSpec Testing for Ruby AWS Lambda Functions

Recently, I wrote an AWS Lambda function at work in Ruby but I didn’t have a handy tool for creating a project skeleton like bundle gem does. That means nothing bootstrapped my testing for me. While copy+pasting code into pry proved that my simple function worked, that wasn’t quite good enough. What I really wanted was the ability to use RSpec with my Lambda code. After a cursory search of the Internet for some examples, I was left disappointed with how little I found. So, I rolled up my sleeves and figured it out.

Continue reading RSpec Testing for Ruby AWS Lambda Functions

Working During a Pandemic

We’re in very strange times, that’s for sure. The entirety of humankind is trying to social engineer a defense against a microscopic threat, yet here I am wanting to talk about working and how well it’s going in spite of the pandemic.

When I was first inspired to write this brief post, I decided against it because it felt too much like bragging. After all, not being able to work is clearly on the minds of MILLIONS of people right now. But really, this isn’t about me; it is a testament to how working on a phenomenal team makes it possible to be busy and happy with my job no matter what the rest of the world is up to.

I’m glad to work with friends, to have tons of work to do, and to see my projects succeeding. As a person that already works from home, this whole situation hasn’t been much of a change for me, but it has been fantastic to see how well the rest of the team has been doing with it. It really matters how companies handle situations like these; we all gain some solid insight into what a company values and how much it can adapt. My group has certainly adapted and after a week or so, I think we’re back in the groove. We’re not slowing down — we’re picking up! I’m grateful that work is the last of my worries (which is precisely how it should be during a pandemic).

Some tips for companies:

  • Let people work from home if they can!
  • Make sure your employees aren’t worried about taking sick time or personal time to figure out family situations.
  • Lead by example: if CEOs or leadership video conferences from a home desk just like everyone else, people are less nervous.
  • Be transparent.
  • Be understanding.

Tips for individuals:

  • Develop a healthy morning routine.
  • Take breaks and go for a walk outside.
  • Establish rules for disruptions during work (when my door is closed, I’m in a meeting).
  • Communicate often in the chat.
  • Leave room between meetings for personal time like getting water, checking in on kids, grabbing a snack, etc.

Stay healthy, everyone!

Distributing CLI Tools via Docker

Throughout my career, I’ve seen a couple recurring patterns related to the tools I write: I write a lot of small CLI tools and I like to share them with my coworkers (and whenever possible, the rest of the world).

This has led to several iterations of solving the problem How do I make this tool easy to run? since I don’t want to burden people with understanding the intricacies of all my tools’ dependencies. These tend to be Ruby, some number of gems, and possibly some other common unix utilities. The solutions I’ve come up with have included a lengthy README with detailed instructions, Bundler with Rake tasks to do all the heavy lifting for non-Ruby things, fpm, and even “curl bash piping” (yes, I’m horrible).

Recently I decided to use Docker to solve this problem, since I’m using it so much anyway. Using Docker has some huge benefits for sharing applications of all types: the dependencies list gets whittled down to just Docker, things work on more platforms, testing gets simpler, and it is the new hotness which makes people say “whoa” and that’s fun. That said, the downsides can be frustrating: working with files on your machine gets messy, more typing with the extra Docker-related preamble, things are less straightforward and clear, simple mistakes can lead to lots of images and containers to clean up, and the executable gets significantly larger (since the Docker image is a whole, albeit lightweight, OS userland to run the app). After weighing these pros and cons, I’ve found that telling a coworker to docker pull registry.url/my/app and run it with --help is so much more convenient than the alternatives.

Continue reading Distributing CLI Tools via Docker

Check for locked out Active Directory user via Ruby

At work, I’ve been working on a lot of automation lately and I ran into a seemingly simple problem that ended up being a bit more complicated than I had first imagined. I have been collaborating on a project that we’re using for auditing Active Directory users and groups and tracking changes to those groups via some simple automation. While that project is interesting in its own right, my boss and I agreed that tackling another helpful automation problem would help our entire IT team: determining if user accounts are locked. I’ve been pushing #ChatOps hard at work through Lita, so adding a plugin for our bot to work with Active Directory seemed only logical.

Context out of the way, making Ruby work with LDAP is a solved problem, many times over. Thankfully, Active Directory exposes most everything you’d want via LDAP, so with a few helper methods, building a few objects tailored to this task was easy work. We quickly discovered that each Active Directory user has a handy attribute called lockoutTime, and even some helpful hints via the interwebs that we just need to check if that value is 0 (meaning the user isn’t locked out) or any other value (indicating, naturally, that they are locked out). Well, this would be a pretty crappy blog post if that was the end, but it wasn’t.
Continue reading Check for locked out Active Directory user via Ruby

Checking In

I started a new job last week in San Diego! I’ve been really busy coordinating the move, learning what’s necessary to do my job, and struggling to keep up with my crazy life. I certainly haven’t forgotten about my blog, and I’m working on a few (hopefully interesting) posts little by little. I’ll be updating LinkedIn with my new job’s details soon, so check there for more details.