From e2c5a18f1d45a0e7d8480c9762cdad75154286e5 Mon Sep 17 00:00:00 2001 From: Adam Parkin Date: Tue, 16 Nov 2021 19:09:44 -0800 Subject: [PATCH] Adapt language to be more inclusive Inspired by https://polaris.shopify.com/content/accessible-and-inclusive-language Went through content and replaced some words with language that seemed more inclusive to me. --- content/book-review-clean-coder.md | 6 ++--- content/book-review-java-puzzlers.md | 4 ++-- content/book-review-the-software-craftsman.md | 9 ++++---- content/cool-link-of-the-day.md | 2 +- content/devopsdaysyyj.md | 14 ++++++------ content/django-pytest-runner.md | 6 ++--- content/embracing-change.md | 8 +++---- content/failure-bow-1-aws-lambda-goof.md | 7 +++--- content/iterm2-setup.md | 2 +- content/lotd-code-reviews-and-prs.md | 2 +- content/m1-initial-impressions.md | 4 ++-- content/polyglotconf-2012.md | 2 +- content/polyglotconf-2017.md | 2 +- content/polyglotconf-2018.md | 22 +++++++++---------- content/ptotd-asyncio-learnings.md | 6 ++--- content/ptotd-fstrings-are-fing-cool-2.md | 2 +- .../pylint-disabling-messages-and-vscode.md | 6 ++--- content/screencap-site-monitoring.md | 11 +++++----- ...serverless-microservices-with-python-p1.md | 4 ++-- ...serverless-microservices-with-python-p2.md | 6 ++--- content/setting-up-the-site-in-aws.md | 4 ++-- content/slow-bash-prompt.md | 4 ++-- content/starship.md | 4 ++-- content/stotd-bash-select-part-deux.md | 2 +- content/vscode_split_terminals.md | 4 ++-- .../why-not-exact-story-point-estimates.md | 2 +- 26 files changed, 74 insertions(+), 71 deletions(-) diff --git a/content/book-review-clean-coder.md b/content/book-review-clean-coder.md index 9668f7f..16d18ac 100644 --- 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 index c46410b..57ecc6b 100644 --- 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 index d38a4ac..249b8cf 100644 --- 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 index c4a8247..6e7ca79 100644 --- 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  +Ever wanted to coherence check your shell scripts?  Check out  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 index 140bae2..16ea55e 100644 --- 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 index c3a3e26..87c8e93 100644 --- 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 index b7c5572..521619c 100644 --- 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 index 456ac52..d9abf0e 100644 --- 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 index 27f2de9..3ad2627 100644 --- 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 index 8623294..c348893 100644 --- 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 index d5fa2df..01910d8 100644 --- 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 index 3c73d97..3fe8a36 100644 --- 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 index 993d981..76fc11a 100644 --- 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.... diff --git a/content/polyglotconf-2018.md b/content/polyglotconf-2018.md index fcd06b1..7e80774 100644 --- a/content/polyglotconf-2018.md +++ b/content/polyglotconf-2018.md @@ -76,9 +76,9 @@ number of technologies employed today is broader than ever, or just coincidence, ## One Simple Trick To Make You A Better Developer... Code Review This was a rather lively and deep discussion on the value of code review facilitated by -[John Boxall](https://twitter.com/johnboxall), in which he started with a short presentation -of his experience going from developer working in isolation to a team, and how looking at -other people's code forced him to learn a ton. Some of the insights he shared from stuff +[John Boxall](https://twitter.com/johnboxall), in which they started with a short presentation +of their experience going from developer working in isolation to a team, and how looking at +other people's code forced him to learn a ton. Some of the insights they shared from stuff they've done at [Mobify](https://www.mobify.com/) included: ### What Things Should Reviewers Look For @@ -205,10 +205,10 @@ stuff you can do with the Bash shell. Many of these things I'd never seen befor to see. For example, a neat trick is to use "bang dollar" to match the last argument -from the last executed command. Say for example, you're working in a Git repo and have -changed a file. You might do a `git diff` to see what's changed, and then having sanity -checked the diff, want to add that file to be committed. You'd do this with something -like: +from the last executed command. Say for example, you're working in a Git repo +and have changed a file. You might do a `git diff` to see what's changed, and +then having coherence checked the diff, want to add that file to be committed. +You'd do this with something like: ```bash git diff some/subdir/containing/somefile.txt @@ -247,10 +247,10 @@ State of the Union" discussion where the goal is to talk about all the newfangle popping up in the JS space. This year, they changed it up a bit, instead focussing on plain Javascript the language, rather than the sampling of the new shiny stuff. -One thing he noted was how it seemed odd that the famous +One thing they noted was how it seemed odd that the famous [Javascript the Good Parts book by Doug Crockford](https://www.amazon.ca/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742) is widely regarded as one of the best texts on the language, yet seems to be largely -ignored by many framework authors. With this in mind, he started talking about how his company is +ignored by many framework authors. With this in mind, they started talking about how their company is taking a step back and starting to use just plain Javascript like a real programming language, and to bring all the good software design and engineering principles (SOLID, DRY, reduce coupling, etc) to their JS work. @@ -260,7 +260,7 @@ to decompose units of computation down to tiny functions and use dependency inje to those functions to wire up functionality. This has all the happy benefits you'd expect: code that's easier to read, to compose, and to test. -As someone who's lived his life in the backend, programming language & software engineering side +As someone who's lived their life in the backend, programming language & software engineering side of things, this really resonated with me. One of the troubles I've had with trying to learn JS is just A) figuring out which framework to start with, B) figure out that framework, and then C) realize that by the time I've figured that out the framework's now obsolete and none of the @@ -269,7 +269,7 @@ focus on JS just as a plain C-derivative language and approach learning it from Good takeaway for me. Last gem was a book recommendation, JavaScript Allongé: -Sounded like it was a book that helped his team start on this journey towards stripping JS down +Sounded like it was a book that helped their team start on this journey towards stripping JS down to the bare essentials, so I'll definitely be checking it out. The discussion at this point moved more to a discussion around using Javascript for distributed diff --git a/content/ptotd-asyncio-learnings.md b/content/ptotd-asyncio-learnings.md index b402522..877b2cd 100644 --- a/content/ptotd-asyncio-learnings.md +++ b/content/ptotd-asyncio-learnings.md @@ -502,8 +502,8 @@ helpful/useful yet). I'll refer to you another post by [Miguel Grinberg](https://twitter.com/miguelgrinberg) on [Unit Testing AsyncIO Code](https://blog.miguelgrinberg.com/post/unit-testing-asyncio-code) where he -discusses some of the challenges and his approaches to solving them. Miguel's a -smart guy who's most known for his [Flask +discusses some of the challenges testing async code and approaches to solving them. +Miguel's a smart cookie who's most known for the [Flask Mega-Tutorial](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world) which is something of the defacto way to learn [Flask](http://flask.pocoo.org/). @@ -544,7 +544,7 @@ isolation. ## It Is a Complex Beast There's a now rather famous post by [Armin -Ronacher](http://lucumr.pocoo.org/about/) (the guy who created +Ronacher](http://lucumr.pocoo.org/about/) (the person who created [Flask](http://flask.pocoo.org/), [Jinja](http://jinja.pocoo.org/), and so many other seminal Python projects) talking about the complexities of `asyncio`. It's an extremely well-written and sobering post from someone who's been in at diff --git a/content/ptotd-fstrings-are-fing-cool-2.md b/content/ptotd-fstrings-are-fing-cool-2.md index 647896a..7140045 100644 --- a/content/ptotd-fstrings-are-fing-cool-2.md +++ b/content/ptotd-fstrings-are-fing-cool-2.md @@ -48,7 +48,7 @@ emitted: The value of myvariable=42 myothervariable=99 ``` -Super handy. What's really crazy is it works with expressions too: +Super handy. What's really amazing is it works with expressions too: ```python >>> myvariable = 42 diff --git a/content/pylint-disabling-messages-and-vscode.md b/content/pylint-disabling-messages-and-vscode.md index f0bffd5..6ca2cb9 100644 --- a/content/pylint-disabling-messages-and-vscode.md +++ b/content/pylint-disabling-messages-and-vscode.md @@ -34,17 +34,17 @@ def test_message_builder_generates_correct_bytestring_when_no_argument_supplied( ``` This will suppress code C0103 for the remainder of the scope (module or block), -or until it's re-enabled: +or until it's turned back on: ```python # pylint disable=C0103 def test_message_builder_generates_correct_bytestring_when_no_argument_supplied(): -# still disabled here... +# still turned off here... # pylint enable=C0103 -def but_not_disabled_here_so_this_name_will_get_flagged_by_pylint(): +def but_not_turned_off_here_so_this_name_will_get_flagged_by_pylint(): ``` You can also (and it's generally better practice) use the "verbose name" for a diff --git a/content/screencap-site-monitoring.md b/content/screencap-site-monitoring.md index f007adc..4299750 100644 --- a/content/screencap-site-monitoring.md +++ b/content/screencap-site-monitoring.md @@ -101,10 +101,11 @@ This produced an image of Google's homepage. Success! # Step 2 - Diffing two Images -This is seemingly the hard part: how do you compare two images and get a similarity score? I -had visions of having to dig into machine learning algorithms to try and figure this out, but -before breaking out the crazy ML I thought I'd see if someone else had already produced something -that met my needs. +This is seemingly the hard part: how do you compare two images and get a +similarity score? I had visions of having to dig into machine learning +algorithms to try and figure this out, but before breaking out the heavy ML I +thought I'd see if someone else had already produced something that met my +needs. Some false leads that didn't quite work ( [here](https://stackoverflow.com/questions/5132749/diff-an-image-using-imagemagick), @@ -159,7 +160,7 @@ need a command-line tool to do this. # Step 2a - ImageMagick to the Rescue In case you've never seen it before, [ImageMagick](https://www.imagemagick.org/script/index.php) -is a library for doing some crazy image +is a library for doing some amazing image manipulation stuff. And there's a CLI interface for it that's great for automating stuff. The full scope of IM is way beyond the scope of this post (there's a *ton* you can do with it), but cropping something is easy-peasy so let's get it installed: diff --git a/content/serverless-microservices-with-python-p1.md b/content/serverless-microservices-with-python-p1.md index 9b66106..caac53c 100644 --- a/content/serverless-microservices-with-python-p1.md +++ b/content/serverless-microservices-with-python-p1.md @@ -24,7 +24,7 @@ unit testing like you would with a regular Python project? Any differences? So, let's take this example and enhance it with a new requirement -- support [Bcrypt](https://en.wikipedia.org/wiki/Bcrypt) as a digest. -Now, there's a problem (ok, this is contrived, work with me here): normally before you start adding new functionality +Now, there's a problem (ok, this is contrived, work with me here): typically before you start adding new functionality you want to ensure you have a decent set of automated tests to ensure that you don't break existing behaviour. So, step 1: let's add some unit tests that enforce the existing requirements we have in our little Lambda function. I saw these as: @@ -156,7 +156,7 @@ def test_default_hash_is_sha1(self): ``` Ok, so now we have our tests which enforce current behaviour, a nice project structure, and at this point this is all -plain old normal Python development, nothing about Lambda here. At this point you could follow the same steps in the +plain old typical Python development, nothing about Lambda here. At this point you could follow the same steps in the tutorial and bundle it all up into a zip file, upload to Lambda and you're good. But I like automating some of the build stuff, so wrote a simple little Bash script to generate the zip file, and called diff --git a/content/serverless-microservices-with-python-p2.md b/content/serverless-microservices-with-python-p2.md index 743569e..6e17ee9 100644 --- a/content/serverless-microservices-with-python-p2.md +++ b/content/serverless-microservices-with-python-p2.md @@ -235,7 +235,7 @@ compiled dependencies -- it's not pure Python. I'm developing on a Macbook runni different environment than Amazon Linux (which is what a Lambda container runs in). So, this is where it gets interesting. I started off doing some googling, and found -[this guy](https://github.com/Miserlou/lambda-packages), which is some common Python libraries with compiled +[this one](https://github.com/Miserlou/lambda-packages), which is some common Python libraries with compiled dependencies built for Amazon Linux. Theoretically you should be able to specify that as a dependency in your `requirements.txt`, build it, and be good to go. So I tried this, and low and behold now my zip file is larger than the 50MB for uploading through the Lambda web interface. Throwing a zip file into an S3 bucket is simple enough, so I did @@ -261,7 +261,7 @@ and found that passlib actually supports [5 different bcrypt implementations (or * stdlib’s `crypt.crypt()`, if the host OS supports BCrypt (primarily BSD-derived systems). A pure-python implementation of BCrypt, built into Passlib. -And that last one is disabled by default as it's just too damn slow. For now though, we just want something that works, +And that last one is turned off by default as it's just too damn slow. For now though, we just want something that works, and is easy (we'll optimize later), so let's enable that backend. This is done by set the environmental variable `PASSLIB_BUILTIN_BCRYPT="enabled"` where you're running passlib. With Lambda, setting some env variables is easy, you can do this in the web interface: @@ -282,7 +282,7 @@ function on the Configuration tab under advanced items: ![Extending Lambda Timeout]({static}/static/imgs/screen-shot-2017-07-27-at-2-19-06-pm.png) It's worth noting this can increase your costs with Lambda, as pricing is execution-time related.  With that change in -place (50 seconds is crazy, but just trying to get it to work), I got a new error, this time from API Gateway: +place (50 seconds is way long, but just trying to get it to work), I got a new error, this time from API Gateway: ```javascript { diff --git a/content/setting-up-the-site-in-aws.md b/content/setting-up-the-site-in-aws.md index a7fabd0..36a9491 100644 --- a/content/setting-up-the-site-in-aws.md +++ b/content/setting-up-the-site-in-aws.md @@ -5,9 +5,9 @@ cover: static/imgs/default_page_imagev2.jpg So I was going to write a blog post outlining most of the stuff I did in getting this site up off the ground, but then a colleague went ahead and did the same and -wrote up his journey. :) +wrote up their journey. :) -So, in true CodependentCodr fashion, Imma going to stea...err borrow his content since +So, in true CodependentCodr fashion, Imma going to stea...err borrow that content since mine was largely the same steps (and he's better at AWS than I am). :p Go [here](https://ben.gnoinski.ca/how-this-site-came-to-be.html) for all the deets on getting diff --git a/content/slow-bash-prompt.md b/content/slow-bash-prompt.md index d43ca2c..1018094 100644 --- a/content/slow-bash-prompt.md +++ b/content/slow-bash-prompt.md @@ -34,7 +34,7 @@ built this version for you and installed as part of Xcode command-line tools” version. So, I installed git from Homebrew (`brew install git`), which gave be the same -normal version that anyone on any platform would get (just compiled for OSX), +version that anyone on any platform would get (just compiled for OSX), and also gave me a much newer version (2.30.0). Much faster. How much faster? Check it out: @@ -46,5 +46,5 @@ user 0m0.016s sys 0m0.026s ``` -From 1.7 seconds to 0.06 seconds. Crazy. Now my command prompt is nice and +From 1.7 seconds to 0.06 seconds. Wow. Now my command prompt is nice and snappy. diff --git a/content/starship.md b/content/starship.md index 1029dd6..1b1d4a5 100644 --- a/content/starship.md +++ b/content/starship.md @@ -11,7 +11,7 @@ Recently I had the good fortune of attending the and there was at least one talk that mentioned [Starship](https://starship.rs/) and at least one other where the presenter happened to be using it. For those not in the know, Starship is a cross-shell compatible terminal prompt -generator written in Rust that is crazy fast and crazy customizable. +generator written in Rust that is super fast and super customizable. I was intrigued, and decided to take my (reasonably sophisticated) Bash prompt and Starship-ify it. In this post I'll outline some of the things I went @@ -184,7 +184,7 @@ Let's explain this a little bit to give a feel: the number rediculously high so that it never truncated * `truncate_to_repo` is a special setting that controls if the directory is truncated to the root of the Git repo you are currently in. Again, I don't - like this (I want to see the full path), so disabled it + like this (I want to see the full path), so deactivated it * `style` is a common setting on (I believe) every module and controls the colour of the module when rendered. In this case saying "yellow" to match my old prompt. Styles are covered in depth in the diff --git a/content/stotd-bash-select-part-deux.md b/content/stotd-bash-select-part-deux.md index ebb8180..434d7bf 100644 --- a/content/stotd-bash-select-part-deux.md +++ b/content/stotd-bash-select-part-deux.md @@ -108,7 +108,7 @@ images: https://t.co/imJV5WA3cB Thanks fo -And he replied with a nice simplification of the clunky awk stuff: +And they replied with a nice simplification of the clunky awk stuff: ```shell select x in `docker images --format '{{.ID}}--{{.Repository}}/{{.Tag}}'` ; do diff --git a/content/vscode_split_terminals.md b/content/vscode_split_terminals.md index a8d7ec9..bc1cea5 100644 --- a/content/vscode_split_terminals.md +++ b/content/vscode_split_terminals.md @@ -16,7 +16,7 @@ write up about this and how I use tasks with VS Code, particularly as a Pythonis As a starting point, to give a basic idea of what tasks are, they're effectively little shortcuts to terminal commands that you can trigger from within VS Code. They're commonly used for things like triggering build tasks, or starting up a local dev server, etc. The thing that makes them nice is -that they can be triggered from the command pallette much like normal VS Code commands. For example, +that they can be triggered from the command pallette much like built-in VS Code commands. For example, when working on this blog, I'll use a task to fire up a local dev server to test out content before committing/pushing it. It looks something like this: @@ -120,7 +120,7 @@ that up, etc, etc, etc. }, ``` -Whenever possible I use [pytest](https://pytest.org/) for running my unit tests. Normally this is +Whenever possible I use [pytest](https://pytest.org/) for running my unit tests. Typically this is run from the command line as something like `pytest `. The problem though is that pytest gets installed to a virtual environment, so how do I give the full path to the virtual env without making the task machine specific? The answer is I run it as a diff --git a/content/why-not-exact-story-point-estimates.md b/content/why-not-exact-story-point-estimates.md index 27ec8ff..ea0e7f0 100644 --- a/content/why-not-exact-story-point-estimates.md +++ b/content/why-not-exact-story-point-estimates.md @@ -25,7 +25,7 @@ complete a task, but I can pretty much guarantee that it'll take the senior dev task). So if we estimate in time units then suddenly we have this problem of do you estimate to the level of the person who's really experienced, or to the junior person? A fibonacci style sequence of "bucket sizes" (like 0.25, 0.5, 1, 2, 5, etc) helps with this (if it takes the junior 9 hours, and a senior 5, then the SP estimate will likely be the same -- -1). (Mike Cohn, the Scrum Alliance guy, has a few blog posts on Story points to this effect, see +1). (Mike Cohn, the Scrum Alliance dude, has a few blog posts on Story points to this effect, see [this](https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points) and [this](https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours))