pzelnip · pzelnip · Nov 17, 2021 · Nov 17, 2021
diff --git a/content/book-review-clean-coder.md b/content/book-review-clean-coder.md
@@ -26,11 +26,11 @@ his/herself.  How should we as professional developers act?  What is the differe
 What are our responsibilities?  When can we say no & how do we do it?  When are we obligated to say yes?  How do we get
 better at what we do?
 
-Martin tries to distill his nearly 40 years of experience into some hard fought lessons.  While it is very much
+Martin tries to distill their nearly 40 years of experience into some hard fought lessons.  While it is very much
 appreciated to hear "tales from the trenches", the book does have a fairly heavy-handed "do as I say" tone.  Don't do
 TDD?  Well then you're not a professional.  Do you create ambitious estimates?  Well then, you're not a professional.
 From a rhetorical point of view, the book does rely on this "proof by appeal to professionalism" approach, rather than
-give solid evidence and data to back up many of the arguments he makes.  For example, the TDD chapter has the passage:
+give solid evidence and data to back up many of the arguments made.  For example, the TDD chapter has the passage:
 
 > Yes there have been lots of controversial blogs and articles written about TDD over the years and there still are.
 In the early days they were serious attempts at critique and understanding.  Nowadays, however, they are just rants.
@@ -40,7 +40,7 @@ I feel like the paragraph should have ended with
 "QED".  Hardly a conclusive argument in favour of TDD, and the off-hand dismissal of any critiques of the practice
 really does hurt the point he's making.
 
-Having said all this, it is certainly clear that much of what he offers is good advice, and represents an open challenge
+Having said all this, it is certainly clear that much of what is offered is good advice, and represents an open challenge
 to developers to be better.  If you put aside the "if you don't do this you're not professional" rhetoric, at its core
 this book is a call for developers to live up to the responsibility of the job they have been hired to do.  Oftentimes
 we as developers like to silo ourselves off, focus on our narrowly defined technical tasks, and that is simply

diff --git a/content/book-review-java-puzzlers.md b/content/book-review-java-puzzlers.md
@@ -21,8 +21,8 @@ cover: static/imgs/default_page_imagev2.jpg
 
 Java Puzzlers is not so much a book, but a collection of obscure corner cases in the Java programming language.  The
 author (Joshua Bloch) is well known as the author of [Effective Java](http://www.amazon.ca/Effective-Java-2nd-Edition-Programming-ebook/dp/B000WJOUPA/ref=pd_sim_kinc_2)
-which is widely regarded as the premier text for the language, and furthermore he is one the designers and authors of
-the Java Collections Framework.  So to say the least, he knows his stuff.
+which is widely regarded as the premier text for the language, and furthermore they are one the designers and authors of
+the Java Collections Framework.  So to say the least, they know their stuff.
 
 Each chapter of the book features a collection of "puzzlers" centered around a particular section of the language
 (examples include loops, strings, exceptions, classes, etc).  Each "puzzler" is formulated where a puzzle (typically in

diff --git a/content/book-review-the-software-craftsman.md b/content/book-review-the-software-craftsman.md
@@ -20,14 +20,15 @@ cover: static/imgs/default_page_imagev2.jpg
 ## Summary Of Content Read
 
 This book frustrated me. I once had the fortune of seeing Sandro give a talk at the Software Craftsmanship North America
-(SCNA) conference in 2013, and found his talk uplifting, and inspirational. As a result of that, when I saw this book
+(SCNA) conference in 2013, and found that talk uplifting, and inspirational. As a result of that, when I saw this book
 had been released it was an "instant buy" for me.
 
 Ultimately though I was incredibly disappointed by this book.
 
 I wanted to like this book. Rather I wanted to love this book. And honestly, much of what Sandro espouses in this book
-I agree with and believe. But, this book is poorly written and filled with anecdotal "evidence" to support his claims.
-This is a shame, as there is much well documented, well-researched evidence to support much of what he argues for. See,
+I agree with and believe. But, this book is poorly written and filled with anecdotal "evidence" to support their claims.
+This is a shame, as there is much well documented, well-researched evidence to support much of what is argued for in this
+book. See,
 the thing is when you make empirical claims (ie - if you do TDD you will reduce bugs and therefore reduce costs, or if
 you pair with other developers you will create a culture of learning which will improve productivity, or if you hire
 craftsmen your company will be better off), you need to back that up with empirical evidence, not just "I had this job
@@ -57,7 +58,7 @@ thing and want to know more? For the Bob Martin's of the world? It's so inconsis
 audience who's only vaguely familiar with the craftsmanship movement, and other parts feel like unless you've been
 writing code for decades you'll have trouble relating.
 
-I'm being overly harsh, there are nuggets of really good insights in this book and he certainly knows the craftsmanship
+I'm being overly harsh, there are nuggets of really good insights in this book and Sandro certainly knows the craftsmanship
 movement. The thing is though there's nothing you won't get from simply reading the blogs or books of some of the people
 in the craftsmanship community. If you've read Clean Coder by Bob Martin, there's no reason to read this book.
 

diff --git a/content/cool-link-of-the-day.md b/content/cool-link-of-the-day.md
@@ -3,7 +3,7 @@ Date: 2017-03-25 22:14
 tags: shell
 cover: static/imgs/default_page_imagev2.jpg
 
-Ever wanted to sanity check your shell scripts?  Check out <https://www.shellcheck.net/>
+Ever wanted to coherence check your shell scripts?  Check out <https://www.shellcheck.net/>
 
 Provides a basic REPL that checks your shell scripts for common issues.  Kinda neat, and admittedly I learned a thing or
 two while playing with it.

diff --git a/content/devopsdaysyyj.md b/content/devopsdaysyyj.md
@@ -42,9 +42,9 @@ Anubhav works for [Hashicorp](https://www.hashicorp.com), well known for many to
 space such as Vagrant, Terraform, Vault, and others.
 
 The talk started with a bit of a history lesson on how operations work has evolved over the last
-10 years or so, going from physical servers to virtualization, to the cloud, etc.  He then dove
+10 years or so, going from physical servers to virtualization, to the cloud, etc.  They then dove
 in to an overview of [Terraform](https://www.terraform.io/) which is a really great tool for provisioning
-infrastructure via code.  He then concluded with a quick demo of using Terraform to provision a
+infrastructure via code.  They then concluded with a quick demo of using Terraform to provision a
 webserver in Google Cloud with a DNS entry provisioned in AWS via Route 53.  Simple, but really
 was a nice little overview of the kind of stuff that's possible with Terraform.
 
@@ -57,7 +57,7 @@ the expense of the latter.
 
 I think this is why I really enjoyed Eduardo's talk.  Eduardo works for
 [Daitan Group](https://www.daitangroup.com)
-and he gave a description of their company's journey through DevOps transformation, not from
+and they gave a description of their company's journey through DevOps transformation, not from
 a tools & automation perspective, but on the perspective of the human focus.  Discussions of
 the importance of empathy and communication, the challenges of collaborating with people from
 very different cultures, and some of the lessons learned along the way.  Really inspiring,
@@ -66,7 +66,7 @@ and I enjoyed it a great deal.
 ## Distributed Brute Force Login Attack - Peter Locke
 
 Peter, like Jeff who did the Serverless talk earlier in the day, also works at
-[Giftbit](https://www.giftbit.com).  In this talk he delved into how they've had to deal with
+[Giftbit](https://www.giftbit.com).  In this talk they delved into how they've had to deal with
 distributed brute force login attacks where distributed botnets try to attack a login page
 with leaked credentials trying to compromise accounts on their service.
 
@@ -81,7 +81,7 @@ could potentially be used was had.
 ## Bitrot: A Story of Maintenance Failure - Will Whittaker
 
 This talk was just funny.  Will's been in the industry for some time, and told the story
-of a project he was a part of that started in the early 2000's, that he left, and came back
+of a project they were a part of that started in the early 2000's, that they left, and came back
 to and saw how the project had devolved in that time.  Lots of humourous, cynical anecdotes
 about the horrors of maintaining a system for a long time.
 
@@ -94,8 +94,8 @@ applications will likely become a maintenance nightmare years from now.  Interes
 This again was one of the "human-side" talks of the day.  Unfortunately the schedule doesn't
 have the speaker's name, and I didn't make a note of it, but the presenter told the story of
 how while working at a company as the head of the ops team, was in the hospital for the birth
-of his third son when he got a phone call from the CTO telling him that everything was on
-fire and he needed to fix it.  Inspiring story of the cost of siloing from a human perspective.
+of their third son when they got a phone call from the CTO telling him that everything was on
+fire and they needed to fix it.  Inspiring story of the cost of siloing from a human perspective.
 Lots of discussion on techniques they employed to help improve their culture & process over
 time (blameless post-mortems, release planning, etc).
 

diff --git a/content/django-pytest-runner.md b/content/django-pytest-runner.md
@@ -17,7 +17,7 @@ video](https://www.youtube.com/watch?v=7it7JFPInX0) showing the process.
 
 That's all fine and good, but one of the complaints I've heard from
 Django-ista's (is that a term?  Djangoites?  Django Devotees?) is that it means
-now the good old normal `python manage.py test` no longer works (well, I suppose
+now the good old plain `python manage.py test` no longer works (well, I suppose
 technically it still works, but doesn't use Pytest).
 
 So challenge accepted, as one can certainly create [custom manage.py
@@ -27,7 +27,7 @@ Pytest instead of the default built-in runner.
 
 ## Python Manage.py pytest
 
-So first challenge is "how do we run pytest from Python?" as normally you run
+So first challenge is "how do we run pytest from Python?" as typically you run
 Pytest as a command line tool.  As it turns out there's [docs on how to do this
 on Pytest's site](https://docs.pytest.org/en/latest/usage.html#calling-pytest-from-python-code).
 
@@ -58,7 +58,7 @@ class Command(BaseCommand):
 This works, in that now I can do `python manage.py pytest` and it'll run Pytest
 as if I just ran the `pytest` executable in the current directory.
 
-Cool, but how do I start passing arguments?  Normally in a custom Django
+Cool, but how do I start passing arguments?  Typically in a custom Django
 management command you define a `add_arguments` function and use the `argparse`
 module to define the expected arguments for your custom command.  In this case
 though, I essentially want the interface to Pytest, which would be non-trivial

diff --git a/content/embracing-change.md b/content/embracing-change.md
@@ -5,11 +5,11 @@ cover: static/imgs/default_page_imagev2.jpg
 
 I recently listened to a recording of a webinar put on through the ACM titled
 ["Agile Methods: Agile Methods: The Good, the Hype and the Ugly"](https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp&eventid=937091&sessionid=1&key=5B3C11566E06BE6564E638C6DFE0F413&sourcepage=register)
-where Bertrand Meyer (the Eiffel/Design by Contract guy) gave his interpretation of the agile software movement, and how
-we may tweak agile thinking.
+where Bertrand Meyer (the Eiffel/Design by Contract person) gave their interpretation of the agile software movement,
+and how we may tweak agile thinking.
 
-A point in particular caught my attention.  He talked about a rephrasing of some of the agile principles as stated in
-the manifesto, and in particular he talked about rather than "embracing" change, one should "accept" change.  While this
+A point in particular caught my attention.  They talked about a rephrasing of some of the agile principles as stated in
+the manifesto, and in particular they talked about rather than "embracing" change, one should "accept" change.  While this
 might seem like splitting hairs, I think it an important distinction, and one I completely disagree with.  I'd like to
 elaborate why I feel the distinction matters.
 

diff --git a/content/failure-bow-1-aws-lambda-goof.md b/content/failure-bow-1-aws-lambda-goof.md
@@ -85,8 +85,9 @@ million Lambda requests:
 But that's nothing:the real problem was that each one of those lambda calls represented
 a PUT to a S3 bucket.
 PUT's with S3 are actually one of the more expensive operations.  For the `ca-central-1`
-region where I host my stuff, it's currently $0.0055 per 1,000 of them.  This sounds crazy
-cheap, and it is, but when you're doing about 1.1 million of them, well, that adds up:
+region where I host my stuff, it's currently $0.0055 per 1,000 of them.  This
+sounds unbelievably cheap, and it is, but when you're doing about 1.1 million of
+them, well, that adds up:
 
 ![The S3 PUT count & costs]({static}/static/imgs/s3_costs-fs8.png)
 
@@ -95,7 +96,7 @@ Queue the Iron Maiden -- 6, 6, 6, THE NUMBER OF THE BEAST!
 To give some context: this site usually costs me well under $0.50 a month, the biggest portion of
 which is Cloudfront which clocks in around $0.24.  Everything else is misc stuff: data
 transfer, S3 storage costs, S3 request costs, I have some old data in Glacier, etc.  So to
-see ~$7 accrued in a day felt, well, crazy.
+see ~$7 accrued in a day felt, well, excessive.
 
 What really bugged me was how *dumb* I felt, such a silly mistake.  What's kinda scary is
 that had I not gotten that email from AWS indicating I was close to the free tier limit,

diff --git a/content/iterm2-setup.md b/content/iterm2-setup.md
@@ -63,7 +63,7 @@ piece of text at all times in the top right corner of the terminal window.  It's
 handy for displaying things like what branch you're currently on or similar
 "contextual" items.  For me because I do a lot of Python work and I'm constantly
 switching between various Python virtual environments I have my badge display
-the current Python version that's enabled.  To set this up, I have the following
+the current Python version that's active.  To set this up, I have the following
 in my `.bashrc` file:
 
 ```shell

diff --git a/content/lotd-code-reviews-and-prs.md b/content/lotd-code-reviews-and-prs.md
@@ -36,7 +36,7 @@ included) can unfortunately bring to code reviews and have them turn adversarial
 than collaborative.  One of the things I love about Sandya's article is that it shines a
 light on bad habits that are common, particularly amongst experienced developers.  I've
 definitely been guilty of passing off opinion as fact as well as bombarding a review with
-an avalanche of comments.  As well, she also not only points out some of the "bad" (or
+an avalanche of comments.  As well, they also not only points out some of the "bad" (or
 toxic) behaviours but offers constructive practices.  Really, really good stuff.
 
 The last one I have is more lightweight:

diff --git a/content/m1-initial-impressions.md b/content/m1-initial-impressions.md
@@ -20,7 +20,7 @@ experienced through the lens of a developer.
 
 Everything I've run through Rosetta has been flawless from a functionality
 perspective.  Having said that though: anything run through Rosetta does seem to
-suck battery life.  And not just apps that are normally CPU intensive.  For
+suck battery life.  And not just apps that are typically CPU intensive.  For
 example: I found that having Dropbox (which doesn't support M1), Itsycal, and
 Spectacle constantly running in my menu bar all seemed to have a significant
 drain on battery life.  I've since switched from
@@ -130,7 +130,7 @@ if I had my way I'd have Catalina instead of Big Sur on this machine
 
 ## In Summary
 
-This machine is awesome.  It's expensive (as all Macs are), but is crazy
+This machine is awesome.  It's expensive (as all Macs are), but is super
 fast, and (once you get rid of all your Intel apps) sips battery very
 lightly.
 

diff --git a/content/polyglotconf-2012.md b/content/polyglotconf-2012.md
@@ -76,7 +76,7 @@ started with the facilitator soliciting people in the audience to share their ex
 were actually fairly small, anecdotal discussions about the difficulties of working with larger amounts of data with
 traditional RDBMS systems.  Partway through an attendee (who is an employee of Amazon) chimed in and gave an intro on
 some of the concepts behind true big data (ie Amazon S3) systems.  This was good and bad, while it was great to see
-someone with expert knowledge step in and share his insights, it did feel as though the talk moved from "how can we do
+someone with expert knowledge step in and share their insights, it did feel as though the talk moved from "how can we do
 big data, what are the challenges associated with it" to "if you need to do big data, you can use Amazon S3 for the backend".
 
 # R and Python

diff --git a/content/polyglotconf-2017.md b/content/polyglotconf-2017.md
@@ -35,7 +35,7 @@ true at this event, but it seemed particularly diverse to me this year than in p
 Union" discussion which has happened in prior years at the unconference. Unsurprisingly [React](https://github.com/reactjs)
 was a technology mentioned a fair bit in this session, as was [Vue.js](https://vuejs.org/).
 
-I'm not a front-end guy, so this was definitely not my forte, but themes I took away from this session was the continued
+I'm not a front-end dev, so this was definitely not my forte, but themes I took away from this session was the continued
 explosion of the sheer number of JS frameworks out there. I didn't stick around for the entire session, instead following
 the law of two feet to switch to....