Red/green bugfix

Red/green bugfixes are the best technique for communicating understanding of a bug and its solution, especially for asynchronous code reviews. A bug Say a new bug has been discovered in a backend service. If it’s found in production, the first instinct is to solve it as quickly as possible. While laudable, this kneejerk reaction can actually make the fix slower and harder for others to understand. Usual fixing procedure Reproduce the bug Using logs and/or reading the code, find where the issue is Fix the bug, make a pull request, let coworkers review it While this procedure is straightforward and can get a bug fix out quickly, there are downsides to this process:

Farewell to Rusoto

TL;DR: I’m not working on Rusoto any more. A history of Rusoto Anthony DiMarco and I started Rusoto in July of 2015. I knew we started the project shortly after Rust’s 1.0 release, but I didn’t realize we had our first commit less than two months after Rust 1.0 landed. Wow! Some early parts of Rusoto are similar to how Rusoto looks now, others are quite a bit different. Our first iteration of code generation used a Python2 script to parse the botocore service definitions and output Rust.

Advent of Code 2019, the wrong way (part one)

Per my tweet: doing Advent of Code 2019 the wrong way. 😁 Today we’re easing into #serverless. WHAT are we doing? Advent of Code! Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like. It’s an excuse to play around with smaller coding problems and enjoy some recreational coding. In this series of blog posts, we’re going to go about solving the problems the wrong way: as much serverless as possible.

Rust as anti lock brakes

Rust: a Language for the Next 40 Years put a seed of an idea on my head. I recommend watching the 55 minute video if you haven’t had a chance yet. The recent posts on the Microsoft Security Response Center blog helped the pieces click in my head. Rust is like anti lock brakes (ABS) for motorcycles. Wait, what? There are a lot of parallels here! Bringing a motorcycle to a stop as quickly as possible is a skill.

Taking a break, 2019

Like last year I’m taking a summer break from open source, including Rusoto. Outside time is good for me I’ll be spending more time outside and less time on a computer until September 2019. There won’t be a disappearing act but I’ll be significantly reducing the amount of time spent on computers for the next few months. Until then!

How much testing is enough?

Most software developers will tell you that tests are good. More tests are better. How much is enough? How can one recognize diminishing returns? What types of tests should be written? Here are some guidelines for determining what a team’s “enough” level of testing is. Definitions and goals unit test: tests a single unit of code. Think a single function or method. If there are more than one or three mocks being used, it’s probably not a unit test functional test: tests behavior of code, staying within a single process integration test: a test that crosses a process boundary.

Don't hot patch

A hot take on hot patching/fixing. Definitions A hot patch, or hot fix, is a method of fixing a critical bug found in production by following a branching strategy that’s outside the norm of software development. Specifically called out in Gitflow, this process is more complex and error prone than treating a critical bug as a regular bug or feature. When following Gitflow, a hot patch can get a fix to production faster by making the change off the master branch, which is then also applied to the release branch.

Chaining Rusoto Futures

Rusoto supports asynchronously running commands to AWS. While immediately making a blocking call to AWS is a common use case, one can create actions to run async and let the tokio runtime handle it. This opens up the ability to run multiple AWS calls concurrently.

If a project sets up infrastructure on AWS, the actions that don’t depend on others to finish can run concurrently. For example: creating an S3 bucket and an SQS queue. Instead of creating a bucket and waiting for the request to finish, then moving on to creating the queue, one can put the Rusoto Futures together and concurrently run them.

In this post we’ll explore to examples of using futures and the Rusoto DynamoDB client.

Repos for getting hired

I’m often involved in hiring. When GitHub links are on a resume, I look at pinned repos and source repos. Here’s a checklist of important items to have in a GitHub public repository to catch the eye of reviewers. Or at least my eye when hiring, and why it’s important. Your goal, my goal Yours: get hired. Mine: make an informed decision about hiring someone who can do the job.

Postgres over TLS with postgres and r2d2_postgres

“Dance like nobody’s watching. Encrypt like everybody is.” In this post we’ll go over how to get the postgres crate and r2d2_postgres working with openssl for connection pooling with TLS. Source code is available. Goal Modern web applications are built with resiliency and fault tolerance in mind. For our example, we’ll be examining parts of a web application backed by a Postgres database. When services launch, their database won’t always be available.