I love static websites. And that love has only grown over time. I started my career building dynamic websites with database backends and those are great, but they require a lot more mental energy to build and secure. Static website, on the other hand, require very little effort and are very resilient to being attacked. So this article explains how I build static websites these days. It may not be what you use and that’s fine, we can both celebrate our differences. ...
I recently tweeted about how people new to programming, or companies that look for candidates and give them programming tests, don’t understand that the first code one writes is just a draft. It can take several edits (so-called “refactors”) to tease out a good, workable, testable, and ultimately simple solution. So here’s a story of how I recently refactored my code 3 times before arriving at a final solution. This happened over the span of a day as I thought about and shaped the code into a format that can be easily tested and understood by others. The code is from a private project, so I am only presenting snippets here and some of the package names and variables have been changed for privacy. ...
I have been writing a lot of code in Go lately and recently I was asked by someone why I write in Go. Being put on the spot, I didn’t really have an answer, but it did get me thinking about why I like this language over the other languages I work with (Java, Ruby, Python, JavaScript). So without any further ado, here are some things I like about working with Go. ...
A common pattern I see used by Engineering teams when I provide security consulting is them creating Lambda function and hosting their code in their own S3 buckets. This S3 bucket means the Engineering team needs to secure the bucket, which means the following controls are active and maintained: no public S3 access (bucket or object) access logging (logs are sent to yet another bucket!) default encryption of all objects access control and monitoring backups failover region segregation of code written by different departments …and that’s just the start. All of that is tedious and creates security busy-work, not to mention you are still responsible for those code assets. Since AWS is hosting my Lambda function, they can host my code too. Here’s how you do it. ...
If you program in Go and use it to access AWS resources, you’ll notice that each of the services in the SDK require a region to be explicitly specified. This is because AWS constructs an API endpoint that is region-specific and some company resources may exist in a specific region (not necessarily where the code is being run). If the code is knowingly trying to access AWS resources in the same region, it can be annoying to hardcode a region into the code. It makes the code rigid and brittle (non-portable). There is a way to have your code automatically determine its region. ...
During beer o’clock at work, I happened upon Roman, who is a software developer on our API and Integrations team. He asked for my opinion on creating a sort-of “contract” between teams when setting up SNS topics and subscribing them to SQS queues. Now, this is how conversations with me often start. I’m a software developer by trade, but I have my feet in cloud infrastructure and security as well so, at the very least, I’m a good sounding board for people’s architecture ideas. I pushed a bit deeper and he finally relented and stated that he doesn’t want to think about the infrastructure, only the contract between teams and, really, he wants to emit an event and have it consumed by someone else… if they care enough to consume it. ...
Gitlab CI is amazing. I love how well it works… when you finally get it setup correctly. With Go, some of the articles on the Web state that you need to install the entire Go environment. These articles are out of date. Getting everything working made the YAML file messy and convoluted. With recent updates to Gitlab, just use the golang docker image from DockerHub (it’s an official image, so it’s safe). My gitlab-ci.yml file now looks like this: ...
For the past few years in the software development world, there has been a push to break-up monolithic applications into microservices. These smaller pieces of code perform one task and contain a small amount of code. Often, these microservices are contained within Docker images and reside on shared infrastructure. At first, it seems that there isn’t much of a place for infrastructure in a microservices environment. But I want to introduce the concept of nanoservices to everyone. These are even smaller than microservices and contain basic logic that infrastructure teams manage on a daily basis. ...
At Unbounce, we have recently started using Terraform for creating our AWS infrastructure. It is working well for our needs but it does have some sharp edges, which is expected as it is a young project. The other configuration tooling we use is Cloudformation, and we provide its templates to the software development teams to use because its commands are fairly simple (and documentation is plentiful). Until our team can come up with a good user experience when working with Terraform, we will keep it for our internal infrastructure projects. That being said, we have put together some best practices for working with Terraform and keeping its scripts organized. ...
I’ll state my bias up front: I do not like interview take-home projects. I do not like them, Sam I am. They are exploitative, they lack any ability to show realistic software development, and they shift the cost from the employer to the candidate. Recently I interviewed at a friend’s startup. I went through 2 phone screens and everything was going well. It was the kind of interviewing that I like, where the process is treated as a discussion. Then I was asked if I would mind doing a small project for them. Instead of giving a resounding “yes”, I said “maybe, what kind of project” as a terrible way of weaseling out of me saying no 1. It’s hard being put on the spot during an interview. Honestly, I should have had the guts to say no, but we don’t all act ourselves when in these situations (interviews are already an unnatural setting). I was told the project was intended to take “1 day” to implement and the assignment details were emailed to me a few hours after the phone screen. ...