DEV Community: Mel Kaulfuss

Applying SRE Principles to CI/CD

Mel Kaulfuss — Mon, 27 Nov 2023 03:36:59 +0000

The software landscape in 2023 is complex. Actually, it’s always been, but we’re really feeling it this year. We work in distributed teams, have monolithic codebases, gargantuan test suites, and microservices that stretch as far as the eye can see. Not to mention our teams are becoming leaner and leaner.

One thing working in our favor is that we have Continuous Integration and Continuous Deployment (CI/CD) at the heart of our software delivery lifecycles. CI/CD allows us to ship code easily and frequently, with a high level of trust that our end users won’t be impacted by bugs (or at least that’s what CI/CD promises to deliver). Sometimes though, our ability to ship without friction is hampered by flaky unreliable test suites, very slow builds, or even simply waiting around for builds to start running. We end up lacking confidence in the system, whose number one job is to provide it.

The pain of flaky tests

A flaky test is a test that passes most of the time but sometimes fails for no immediately obvious reason. Flaky tests are caused by many things, including:

Test ordering
Missing elements in integration specs
Dates, time, and timezones

I began digging into the problem more to understand exactly how painful flaky tests were. Turns out that in one month, Buildkite users spent a cumulative 9,413 days retrying failed steps. That’s 59.24 days wasted every day that month.

To put those numbers into context, you can get to Mars and back 17 times in 9,413 days. Suppose you also factor in time wasted across all CI/CD platforms (and especially ones that make you re-run the entire build for each failure rather than an individual failed step). In that case, we’ve suddenly got time to explore strange new worlds and seek out new life and civilizations at the very edge of our galaxy.

Back when I was a junior developer, there was a smoke test in our pipeline that never passed. I recall asking, “Why is this test failing?” The Senior Developer I was pairing with answered, “Ohhh, that one, yeah it hardly ever passes.” From that moment on, every time I saw a CI failure, I wondered: “Is this a flaky test, or a genuine failure?”

The additional overhead of lost flow (and focus) is real–we become distracted and potentially occupy ourselves with Twitter, X, Bluesky scrolls and Slack messages. According to a Harvard Business Review article, it takes over 23 minutes to get back on task after an interruption. So if we’re playing whack-a-mole with flaky tests while battling mega-slow builds, we’re in a very bad place.

Developers need to be able to rely on the systems and tools they use to get the job done–our CI/CD systems need to provide fast, reliable feedback about the software we’re delivering. When that doesn’t happen, we’ve got some problems, and so do the end users of our software.

SRE principles to the rescue

Regardless of whether you can literally deploy on a Friday or not, asking, “Can I deploy on a Friday afternoon?” is an awesome way to gauge a team’s sentiment about how reliable their pipeline-to-production workflows are. We should all be able to say yes when asked the question, and if we can’t, we have some work to do to restore trust.

It turns out Site Reliability Engineers (SREs) know a thing or two about ensuring our systems are reliable (as the name suggests), so let’s look at some of the principles they use to guide their efforts.

Google’s book Site Reliability Engineering - How Google Runs Production Systems compares DevOps to SRE:

"The term “DevOps” emerged in industry in late 2008…Its core principles—involvement of the IT function in each phase of a system’s design and development, heavy reliance on automation versus human effort, the application of engineering practices and tools to operations tasks—are consistent with many of SRE’s principles and practices."
Site Reliability Engineering – How Google Runs Production Systems

It goes on to say that DevOps could be viewed as a generalization of several core SRE principles to a wider organizational context. And that SRE could be viewed as a specific implementation of DevOps with some idiosyncratic extensions.

DevOps thinking encourages us to see accidents as a normal part of software delivery. We saw blameless culture evolve because of this principle, and also that tooling, human systems, and culture are interrelated. DevOps is a way of thinking and working focused on bringing people together (from Development and Operations), improving collaboration, and leveraging automation and tooling to further improve how we deliver software. SRE, on the other hand, is a little more focused on the practical: improving operational practices, efficiency, and as the name suggests, the reliability of our core systems.

Only as reliable as strictly necessary

"...it is difficult to do your job well without clearly defining well. SLOs provide the language we need to define well."
– Theo Schlossnagle Circonus, Seeking SRE

Common principles in both DevOps and SRE involve measurement, observability, and information about the health of systems and services. Whilst SRE works to ensure systems are reliable, 100% reliability is never the goal. SRE seeks to ensure systems are only as reliable as strictly necessary.

SRE uses:

Service Level Objectives (SLO) to define what level of reliability is guaranteed.
Service Level Indicators (SLI) to measure how things are tracking against the SLO.
Error budgets to reflect how much, or for how long, a service can fail to meet the SLO without consequence.

"SLIs/SLOs shift the mindset from ‘I’m responsible for X service in a very complex, vague backend environment way’ to 'If I don’t meet this SLO my customer is going to be unhappy.'"
– Lucia Craciun & Dave Sanders, Putting Customers first with SLIs and SLOs, The Telegraph (Engineering)

We need solid metrics as an objective foundation for conversations in our teams and with leadership, and we need to agree that these metrics represent an accurate picture of reality. If we rely on data to actualize the cost associated with developer pain, it’s no longer about feelings and is far easier to mitigate. SLOs, SLIs, and Error Budgets provide a framework to prioritize the upkeep and maintenance of key systems, which can often be the hardest thing to make time for. SREs generally apply these to production services and systems, but there’s no reason we can’t apply them to CI/CD.

Getting started with SLOs

First, you start with understanding what everyone involved expects from the system, and then you should focus on building a shared understanding.

Ask some questions:

What is the system in question?
- Is it CI, CD, or both?
- Are you limiting the scope to an application’s test suite?
What about the test suite? Speed? Reliability?
- Who are the system’s different stakeholders?
- Who relies on the system?
- Who maintains the system?
- What is important to everyone?
- What’s currently working?
- What isn’t working?
- What needs to improve?

Once you have built this shared understanding, it’s time to agree on some SLOs, SLIs, and reasonable error budgets.

For example, if you want to reduce the time developers need to wait for a build to kick off, a good SLO could be:

SLO: Builds should start running within one minute.
SLI: Total wait time for a build to start.
Error budget: 33 builds that take more than 1 minute to start running in a four-week period.

Another example might involve the need to have speedy feedback loops:

SLO: Developers have commits tested and notified in five minutes.
SLI: Total build run time.
Error budget: 33 builds that finish in more than five minutes in a four-week period.

Or you might want to mitigate the problems associated with flaky tests:

SLO: Test suite reliability should be greater than 87%.
SLI: Test suite reliability score.
Error budget: 77 test runs with a reliability score of less than 87% in a four-week period.

Your SLOs will naturally evolve from understanding what everyone expects from the system. How you get your SLIs will vary depending on what CI/CD platform you use and what metrics you need to collect. For SLIs like build wait time and total build run time, they should be metrics that are available via your CI/CD platform. Buildkite has OpenTelelemetry tracing built into the agent that allows you to send build agent health and performance metrics to an OpenTelemetry collector, a CLI tool to request and build runtime metrics from the API, to be collected and visualized as you need. And for test suite reliability, Buildkite has tooling to detect and manage flaky tests, with a suite reliability percentage score for test suites. Honeycomb and Datadog also have products to integrate with CI tools to gain valuable metrics and insights.

Using error budgets to maintain focus

"SLOs are a powerful weapon to wield against micromanagers, meddlers and feature-hungry PMs. They are an API for your engineering team."
–– Charity Majors, SLOs Are the API for Your Engineering Team

Let’s look at the error budget in our test suite reliability-related SLO above:

SLO: Test suite reliability should be greater than 87%.
SLI: Test suite reliability score.
Error budget: 77 test runs with a reliability score of less than 87% in a four-week period.

While we are “within budget,” we can maintain momentum and focus on the work we’re already doing, ignoring any issues that may distract us. However, once that budget is spent, and we’ve had more than 77 test suite executions with a reliability score of under 87% in four weeks, we’ll need to have brokered an agreement on what happens. Ideally, your teams would shift focus to the work required to get your SLI back to meeting your SLO.

The perception of grinding to a halt to fix things in a system once an error budget isn’t met can be a huge point of contention when implementing SLOs and SLIs. Since everyone has agreed on what’s important to track, you’ll have SLI metrics in place, so the discussions are centered around hard facts and the visible monetary cost associated with developer pain.

Besides being able to remain focused on our work, in her blog post SLOs Are the API for Your Engineering Team Honeycomb CTO Charity Majors says, “SLOs give you the ability to push back when demands from other parties exceed your capacity to deliver what the business has deemed most important.” This sounds like the kind of thing we need to be able to lean on from time to time.

Conclusion

If you’re not sure how to get started, start small! With one SLO. For that SLO, guarantee to maintain the level of reliability the system currently performs at. That’s a great first step, and you can commit to a better percentage when you’re further along in your SRE practices.

It’s important to remember that SLOs, SLIs, and Error budgets are a journey, there may be dragons, but change is fine, and revising these agreements can happen until they work for everyone. Understand and define expectations, set some SLOs, and prioritize mitigating developer pain to rebuild trust in your system—because everyone should be able to deploy on a Friday afternoon (even if they can’t).

If you’ve tried this approach, let me know what’s worked for you on ~~Twitter~~ X.

This post is based on my talk of the same title: Applying SRE Principles to CI/CD, and was originally published on the Buildkite blog.

Extending Buildkite with plugins: HashiCorp Vault

Mel Kaulfuss — Tue, 05 Sep 2023 02:37:06 +0000

In this post, I'll cover what Buildkite plugins are, how they work in Buildkite and use the Vault secrets plugin as my example. The Vault plugin is the recommended way to integrate with HashiCorp Vault and is a great option for managing and protecting your secrets.

What's a plugin?

Buildkite's CI/CD pipelines support extensibility in so many ways, and plugins play a big role in this composability.

Plugins are small self-contained pieces of functionality that can be included in pipelines so you can customize Buildkite to your specific requirements. You might already be familiar with Jenkins plugins, or CircleCI Orbs, Buildkite plugins are very similar, but are even more flexible.

They can be used to modify the behavior of jobs in your pipeline using one or more of Buildkite's ten job lifecycle hooks. Each hook modifies a different part of the job lifecycle, for example:

Setting up the environment.
Checking out the code.
Running commands.
Handling artifacts.
Cleaning up the environment.

Plugins can be open source and available for anyone to use or private and kept in a repository only your organization and agents can access. If you keep them private, they can be in a centralized place or the same repository as your source code.

Using plugins

If you're familiar with Jenkins, you'll be familiar with having a central or web-based plugin management system. Like many other CI/CD tools, Buildkite lets you manage plugins directly in your pipeline definitions. The advantage of this is that they're decentralized, more easily version controlled, and only included in the pipelines that really need them.

You use plugins in pipeline command steps to access a library of commands or to perform actions. To add a plugin to a command step, use the plugins attribute in your pipeline definition. The plugins attribute accepts an array so you can add multiple plugins to the same step.

For example, the following pipeline:

runs a test.sh script
if needed, it logs into Docker using the Docker Login plugin
It then runs the test.sh script inside an app service container using the Docker Compose plugin

steps:
  - command: test.sh
    plugins:
      - docker-login#v1.2.3:
          username: mello
      - docker-compose#v4.14.0: 
          run: app
          image-repository: index.docker.io

Which is the equivalent to running:

docker-compose run app test.sh

Securing your secrets with the Vault secrets plugin

Buildkite is an extremely secure CI/CD tool, you don't store any secrets in Buildkite, we don't have (or want) access to them. Because build agents (aka runners in other CI tools) run on your infrastructure, secrets are only accessed within the boundaries of your environment.

A secret in CI/CD is anything you want to tightly control access to, such as API keys, passwords, and certificates. HashiCorp Vault is an identity-based secrets and encryption management system. Along with securely storing secrets and granting access, it also allows you to create ephemeral/short-lived tokens, and because it's centrally managed it makes revoking and rotating tokens extremely simple should the need arise. You can use Vault in your pipelines to manage your secrets securely.

The Vault secrets plugin is developed and maintained by Buildkite as the recommended way to use Vault in your pipelines. It aims to provide a general solution most teams can use to integrate with Vault.

The plugin allows build agents to authenticate to Vault and acquire pipeline secrets while running a job. It also enables you to create more granular policies for access by agents and pipelines, making it easier to have a better security posture.

The plugin wraps Vault's CLI and allows you to configure multiple authentication methods to acquire a token, including AppRole, AWS, and JWT.

For example, the following pipeline accesses Vault using AppRole authentication:

steps:
  - command: ./run_build.sh
    plugins:
      - vault-secrets#v1.1.0:
          server: "https://my-vault-server"
          path: secret/buildkite
          auth:
            method: "approle"
            role-id: "my-role-id"
            secret-env: "VAULT_SECRET_ID"

Order of operations:

Authenticate to Vault to get a token that is scoped to the appropriate policies using the configured authentication method.
Check Vault for any secrets using different paths:
- env
- environment
- private_ssh_key
- id_rsa_github
- git-credentials
Download the secrets and add them to the job environment.

You can use this demo repository to quickly get a local Vault environment running.

Plug'n play

It's best to extract and wrap commonly used or repeated functionality into a plugin, not only will this simplify its inclusion in pipelines, it reduces repetitive code, and makes updating versions or removing and changing plugins across multiple pipelines much simpler.

Many common problems or workflows already have dedicated plugins from Buildkite or the Buildkite community. Check the Plugins directory to look for an existing solution.

If you can't find an existing plugin that does what you need, check out the documentation to write your own. Buildkite plugins are written in Bash and loosely coupled with Buildkite, making them more maintainable and less prone to compatibility issues than in other CI/CD tools.

✨ Rekindling Community ✨

Mel Kaulfuss — Thu, 25 Feb 2021 01:53:00 +0000

2020 really took its toll on our company culture as I'm sure it did for many of you.

It's not like we weren't already a flexible, remote friendly delivery team. It's just that being forced 100% remote meant that we suddenly became what felt like, a company full of 1 person silos.

Collaborating and pairing are my happiest places to be, but as our work pivoted to meet the demands placed on it as an airline during a pandemic, the pressures of delivery meant our team was fractured – people were head down, under pressure, delivering in isolation.

Where did the fun and laughter go?

Fun is often an overlooked yet valuable ingredient in delivery teams that produce exceptional output (both in terms of quality and speed). As a Dev team, that's always been a very important part of who we are and why people choose to work with us. Moving our Dev team rituals to Google Meet wasn't as successful as we'd have hoped. The silence and lack of frivolity was jarring and instead of fun it was, do the business, get the thing over with and get out of there. These once enjoyable routines fast became chores, and engagement waned. Work no longer felt like the fun place it once was and that meant showing up was hard.

Bringing back the energy

Last week we had our first Hack week for nearly 2 years. I'm trying to put my finger on why it was the most successful we've ever had, and if I was to choose one reason why, I think it was that everyone was all too familiar with the pain of feeling disconnected.

I can't speak to how it was organised, because I wasn't involved this time round, but I can talk about how it felt from a participants perspective - a perspective that was shared across the teams.

Here's how it happened:

Call for ideas/proposals
Tech Leadership group review
Choose your own team/idea
Clear instructions/expectations communicated
Organic/teams have full autonomy
No winners/losers

Of course there's no magic in any of this. It's worth mentioning though that there is a palpable amount of psychological safety and trust in our 30+ delivery team. This is both remarkable, and also key to things running so well.

Call for ideas/proposals

A spreadsheet was circulated to gather any and all ideas, along with what types of skills would be needed to get the job done. There were no bounds imposed at this stage. Anything and everything was valid.

Tech Leadership group review

The tech leads reviewed the ideas to weed out proposals that were deemed:

Too BAU (ideas that were snuck into the list to get business as usual work further along the delivery roadmap)
Not really achievable (in some way)

These ensured the ideas that remained were exciting, fun and within reach.

Choose your own team/idea

Some teams were big, some were small, UX/design peeps were shared across teams. We were free to choose to work on anything that resonated with us personally in some way.

Clear instructions/expectations communicated

The tone of all communications were friendly, light, and lacked the usual hackathon competitive tone. I felt informed, knew what to expect, had the opportunity for Q&A. All ducks in row.

A few days before the event we were given a high level running sheet. There was no anxiety, nothing left to chance, everyone felt included and heard.

Organic/teams have full autonomy

Whilst there were a few optional checkpoints during the week, the week's organisation was loose and teams free to self organise.

The checkins:

Monday (AM):
Google Meet Kick off - welcome and overview of what to expect during the week.

Tuesday (AM):
Engineering Manager check-in with participants to see how things are going (informal and via DM), light touch, mainly to collect ammunition for jokes in hindsight.

Teams presented logo/name and general idea/approach via Google Meet. Loaded with jokes/joviality.

Friday (PM):
Team presentations/awards

Throughout the week:
Regular updates in #delivery slack.

Getting the band back together

What was remarkable to me, was seeing the energy rekindled. Our enthusiasm for building smart, customer centric, value imbued products! Every team produced amazingly innovative results and in just 5 days.

I'm not sure exactly how it was possible, but I'm certain, that the open, friendly, trusting, and optimistic energy that was part of the inception of ideas and communication style permeated through the entire event. In stark contrast to our Google Meets of late there was also a focus on being silly, irreverent, and laughing A LOT.

The challenge of running a remote hack-a-thon unexpectedly didn't seem to be a thing. It all just worked. Slack/google-meet and pairing via VSCode Liveshare meant for a very easy week and our trust in and ability to converse online firmly established.

Final presentations were given via team slides and live-demos in Google Meet. Remarkably, all of the teams approached their presentation in the same way (without consultation). Each of the team members took their turn to present a component of the work they did. No-one was left behind. The teamwork and collaboration and community was back.

I'm sure the execs were aware that this wasn't a cheap investment. But the outcomes were far greater than simply the products that were built (or not built). Harmony, cross team collaboration and communication are the backbone of getting shit done efficiently. A 5 day investment in fun and innovation produces something that money just can't buy.

It feels like we're on track to being back baby!

Enumerable#tally in Ruby 2.7

Mel Kaulfuss — Tue, 27 Oct 2020 22:43:41 +0000

The tally method has been added to Enumerable in Ruby 2.7

It's a simple little method and as the name suggests, it tallys things for us! It affords us a much simpler way to group items and count their occurrence.

We could always count the size of an array.

fruit_bowl = ["apple", "pear", "pear", "banana", "apple"]

fruit_bowl.count 
=> 4

We could count how many of each item an array contained.

fruit_bowl.each.count("apple") 
=> 2

Now we can easily take stock of our array items with tally which will return us a list of items with their respective counts.

fruit_bowl = ["apple", "pear", "pear", "banana", "apple"]

sorted_fruit = fruit_bowl.tally
=> {"apple"=>2, "pear"=>2, "banana"=>1}

sorted_fruit["apple"]
=> 2

Sweet as 🍓😋

Opening a window on codesmells 💩💨

Mel Kaulfuss — Tue, 15 Sep 2020 07:46:00 +0000

Codesmell sure is a great word, it was first introduced by Kent Beck in the 1990s and later popularised in the book Refactoring: Improving the Design of Existing Code written by Martin Fowler in 1999. Just like the name suggests it's a pong or stank that emanates from code. Suffice to say, the code in question is less than ideal.

Over a series of small posts I'm going to a uncover a few of the easier to identify codesmells and give you some tools to fix them.

Sandi Metz, my favorite technical speaker and writer, has written and spoken about these topics extensively. I thoroughly recommend checking these resources:

Trust your gut

❌ test fails: 🤔 "why isn't this working?"
✅ test passes: 🤔 "why is this working?"

Familiar scenario? As a complete n00b literally everything was baffling. I considered it a huge win if I even began to understand the code I was reading. If things were tough, I'd hear a little voice:

"You've read over this class or method a million times, why can't you understand it? Adding a new spec shouldn't be that difficult, what's wrong with you?".

What if it wasn't you but it was the code (don't bother git blameing - it was probably you last month 😅)? Complex code isn't good code. Learning to trust your intuition only comes with confidence but it's important to remember that if something doesn't feel right, often it isn't!

Any fool can write code that a computer can understand, good programmers write code that every human can understand.
-- Martin Fowler

Start off small 👀

A couple of relatively easy to spot issues:

Conditional complexity in the form of way too many ifs, elsifs and elses
The length of Classes, Modules and Methods

Let's take a look at these things in a little more detail.

Conditional complexity

You're working on adding a small feature or fix and need to add a simple expectation or two to an existing unit spec to cover this case. How hard can that be?

Upon opening that my_thing_spec.rb file (because you practice TDD of course 😉) you discover that can be pretty hard. The spec is overly complex, the set up alone fills your screen, and scrolling down the file your your enthusiasm starts to wane.

A tonne of nested contexts is most likely a hint that something isn't quite right.

describe '#my_understanding'
 context 'when i see this'
  context 'when it looks like this'
  context 'when it looks like that'
  context 'when it looks like something unrelated'
  context 'when it arrrghhhhhhhh'

If your unit spec feels difficult to work with, it's highly likely you're looking at an opportunity to banish a codesmell 👉🚪.

describe '#error_message' do

   context "with an 'error' response" do
     it 'has an error describing the error' do

     end
   end

   context "with a 'refused' response" do
    end  

    context "without a response present" do
      context "and a status code" do
         ...
       end
     end

     context "and no status code" do
       ...
     end
   end
  end
end

In the above (semi-fabricated and overly simplified) example we're testing an error_message method that clearly has a few different return values depending on the context.

Looking at the corresponding method that we're testing, it's no surprise there are a few conditionals.

def error_message
  if error_response?
    "#{response["errorCode"]} #{response["errorType"]}: #{response["message"]}"
  elsif payment_result == 'refused'
    "Payment refused: #{response["refusalReason"]}"
  elsif status_code.present?
    "#{status_code} status received"
  else
    "Payment connection failed"
  end
end

In fact we've got all the if, else and elsif bases covered and more.

Asking myself - What does the "error_message" method do?

Wellllll if it's an error response it builds an error message and if the request was refused we bubble that reason up and if we don't get an error or a reason but there's a status code we put that in the error and if all else fails, we just state that the request failed.

11 lines of code
3 ands.

What would Sandi Metz do? I do know what she'd says:
Methods should be no longer than 5 lines of code.

Now I'll admit, I do break that rule (maybe a little more than sometimes). But the and rule is a good one to stick to. If you have to say AND when describing it's function it's doing too much! So, we've identified a conditional complexity codesmell and an opportunity for a refactor.

Zooming out to the class level now:

module Clients
  class PaymentResult
  attr_reader :result, :api_version

    def initialize(result:, api_version:)
      @result = result
      @api_version = api_version
    end

    def response
      result[:response]
    end

    def payment_result
     response["resultCode"]&.downcase unless response.nil?
    end     

   def success?
    status == 200 && response == 'authorised'
   end

  def failure?
    status == 200 && ['error', 'refused'].include?(result)
  end

  def error_response?
   response.has_key?("errorCode") unless response.nil?
  end       

  def error_message
    # you've already seen me :)
  end

  def insufficient_funds?
    response["refusalReasonCode"] == "5"
  end

  def card_expired?
    response["refusalReasonCode"] == "2"
  end

 def declined?
   ["7", "9"].include?(response["refusalReasonCode"])
  end

 end
end

We can ask ourselves a similar question –– What is this class doing?

Wellll, it handles/parses the response from the external third party payment provider AND if there are errors it then formats the error according to the type of resultMessage received"

It's a relatively small class (doesn't exceed Sandi's 100 line limit for Classes rule). There is another codesmell lurking in there: primative obsession. But I'll park that one for another post (or justification) soon. There was an and in our class explanation – and a sign that the class is doing more than it needs to.

We have green tests and our existing code works so that means we can refactor with confidence 🙌

Just a simple refactor?

Pragmatism and discretion are always an essential ingredients in our work as Software Engineers. There are never absolutes, only trade offs that can be lived with or not. Refactoring isn't always the answer but it usually is. Investing more time than is necessary isn't always called for, it's up for to you to decide what's appropriate for the given circumstances.

Ask yourself a couple of things before embarking:

Is this code likely to ever need to change?

If it's unlikely to be revisited it's okay to leave it. Honestly, bad code isn't necessarily bad if it was cheap and is robust and does it's thing without needing to change. You don't get paid to be perfect. You get paid to build the right tool for the job at the right time.

Is a refactor going to help the next person who will inevitably need to touch this code?

If the answer is hell yeah - then why not leave things in a better state than what they were when you arrived. Investing in clean code can take time but saves it in the long run.

Accidentally Destructuring in Ruby

Mel Kaulfuss — Thu, 10 Sep 2020 13:07:17 +0000

The funniest thing happened to me yesterday. Funny now I guess. At the time it was distinctly unfunny. I struggled for hours on the simplest unit spec that was failing.

The response I was expecting to see in my test:

{:response=>{
   "pspReference"=>"883598242852329J", 
   "resultCode"=>"Authorised", 
   "amount"=>{"currency"=>"AUD", "value"=>1000}
   },
 :header=>{ "Sandwich"=>"Eggplant-Parma-Sanga"},
 :status=>200}

The failure message, less than helpful:

TypeError:
  no implicit conversion of Symbol into Integer

Staring at the code.
Staring at the spec.
Thinking I'd done something stupid in my before block.

A binding.pry in my code shows me the Hash I'm expecting to be able to access with a :response key is coming back inside an Array?!

[{:response=>{"pspReference"=>"883598242852329J", "resultCode"=>"Authorised", "amount"=>{"currency"=>"AUD", "value"=>1000}},
  :header=>{"Sandwich"=>"Eggplant-Parma-Sanga"},
  :status=>200}, “api_version”]

You wot m8!

It took a second pair of eyes to help spot the error.

def initialize(result:, api_version:)
  @result = result,    # <-------- this stray comma
  @api_version = api_version
end

As soon as that silly stray comma was pointed out I laughed out loud.

I was accidentally Destructuring in Ruby and I'm chalking up the fact I knew that's what was happening as my win here! And also that I'd been meaning to write about Destructuring in Ruby earlier, so, win win I guess 🤷‍♀️

Destructuring is described in Common Lisp the Language, 2nd Edition as the ability to "bind a set of variables to a corresponding set of values anywhere that you can normally bind a value to a single variable".

In Ruby we assign values to a single variable like this

my_choice_sandwich = "eggplant parma"

# irb(main):001:0> my_choice_sandwich
# => "eggplant parma"

Destructuring allows us to do multiple assignments with a simple comma separating the multiple values like so

my_choice_sandwich = "crumbed eggplant", "sugo sauce", "mozzerella"

# irb(main):001:0> my_choice_sandwich
# => ["crumbed eggplant", "sugo sauce", "mozzerella"]

Above we see the Object on the left (the "variable") is an Array because we are passing in multiple values on the right.

You can set multiple variables (on the right) with corresponding values (on the left).

sandwich, pizzas = "salad", {vege: "mushrooms", meat: "aussie"}

# irb(main):001:0> sandwich
# => "salad"

# irb(main):001:0> pizzas
# => {:vege=>"mushrooms", :meat=>"aussie"}

Above you'll see:
sandwich returns a String because only one value is being assigned on the right.

pizzas returns a Hash as that was the corresponding value on the right.

Isn't learning fun!

Bogged down by Blogging

Mel Kaulfuss — Fri, 14 Aug 2020 12:46:25 +0000

What is it about us software engineers?

On the one hand we're the good kind of lazy, we love optimisation and efficiency. We automate the most menial tasks so we don't need to waste time on them ever again. If you've a product mindset, you're no stranger to the concept of Minimum Viable Product. You're always asking the why's, using TDD to drive design evolution, and only reaching for abstraction when there's a need. Yet, when it comes to our own private projects - we're all in on the over engineering.

We love a good meaty problem, the curlier the more intriguing. And there's nothing wrong with over engineering if your goal is experimentation, learning and fun right? But what about when that's a form of procrastination?

For five years my sad old blog has lay in that dusty, dark corner of the internet where all neglected blogs lie, never a visitor, unloved. I have dreamed of resurrecting it. You'd be forgiven for thinking, when I say "resurrect", that I wrote more than a "hello world" post and a follow up. You'd be wrong, it's a vacuous collection of broken CSS, despite being lovingly composed with the best of intentions.

It was 2015 (the good old days) I hadn't learned to code yet, this was my first foray into learning to code as a hobby. Fresh faced, innocent (some might say naive), eyes glittering, I rolled up my sleeves to get started. Finally I was practicing what I (had myself) preached in many presentations to junior developers on how to break into the industry.

"Focus on the three Ps; Practice, Persistence and Presence."

I needed a blog for that last P, I needed Presence and pronto!

Without hesitation, I reached for Jekyll, it's a fantastic and simple open source static site generator, not complex when you have some experience under your belt.

I learned a lot as I experimented and broke things. About CSS and the feels associated with cascading down into those pits of despair. About infrastructure and how much I loved understanding how the internet evened. I served my blog from AWS s3, configured route53 for my DNS, and to this day it's up (with minimal costs associated). So it was a success of types.

What I didn't do was continue to blog and that's because my choice of tool didn't serve my needs. I was hung up on a particular solution rather than asking "what are you trying to achieve?".

I wanted to practice writing about technical subject matter, to sharpen and hone my skills, to share and help others who were struggling with similar issues.

After an inspirational conversation with @KaslinFields and laughing at my failure I'm heeding her advice of "Do it!" with a renewed vigor and a more fitting tool for my needs. Use whatever tool is right for you, there's no need to over complicate things.

Always be the right kind of lazy (and smart)!