chore: remove typos from the posts

Author: vidalvasconcelos

posts/2018-06-23-AN-YEAR-WORK-ON-B2RENT.md

@@ -3,38 +3,38 @@
 - Date: 2018, Jul 23
 
 About a year and many cups of coffee ago, I was invited to work on a project in 
-Fortaleza. That was what finally made me move to a new city—something I had 
+Fortaleza. That was what finally made me move to a new city, something I had 
 been postponing for two years, insisting on staying in Sobral.
 
 The project was incredible: working on a Laravel 5.1 application aimed at helping 
 companies manage rentals. Initially, I was going to be the sole developer leading 
-this endeavor, with B2rent being just one of the products of Pilps GP.
+this effort, with B2rent being just one of the products of Pilps GP.
 
 I felt like the perfect developer for the job. Working with legacy code in a 
 startup environment had become almost second nature over the past two years. That 
-period—working as a freelancer or building my own startup—was one of the best 
-times of my life up to that point. I met many people who helped me and radically 
-changed my worldview. 
+period, working as a freelancer or building my own startup, was one of the best 
+times of my life up to that point. I met many people who helped me and changed 
+the way I see things. 
 
-That energy of creating new things and learning every second is an intrinsic 
+That energy of creating new things and learning every second is a core
 part of who I am today. The challenge was to expand the project's functionalities 
-while streamlining the codebase—a Herculean task, to say the least. 
+while streamlining the codebase, a Herculean task. 
 
 A prime example of this is that, even a year later, there are still Controllers 
 I have never touched. The reason for the bloated codebase was the number of 
 developers who had worked on it before me, implementing isolated features 
-without considering maintainability—each with a different vision of what the 
+without considering maintainability. Each had a different vision of what the 
 project should be.
 
-Most tasks always came with extensive refactoring of the codebase: removing 
-business logic from Controllers, optimizing massive queries, extracting 
-useless code, and, more often than not, negotiating scope adjustments. Through 
+Nearly every task came with extensive refactoring of the codebase: removing
+business logic from Controllers, optimizing massive queries, removing
+dead code, and, more often than not, negotiating scope adjustments. Through 
 this, I learned that much of what makes software complex is the lack of 
 structured processes on the client’s end. 
 
 The result of this work can be seen in the following graph, which shows the 
 number of lines added and removed in my contributions to B2rent. These numbers 
-aren’t what truly matter—the key takeaway is that, even as the product gained 
+aren’t what truly matter. The point is that, even as the product gained 
 more features, we managed to keep the codebase as lean as possible.
 
 | Commits | Lines Added | Lines Removed |
@@ -44,13 +44,13 @@ more features, we managed to keep the codebase as lean as possible.
 The frontend was another challenge. Laravel comes with a built-in structure for 
 Vue.js 1.0, but that setup had been completely removed at the project's start. 
 
-Since I was particularly a fan of the library, one of my first tasks was to recreate 
-its setup. Although Vue 2.0 had already been announced at the time, bringing some 
-incompatibilities, we built most of our components with the new version’s requirements 
+Since I was a big fan of the library, one of my first tasks was to recreate 
+its setup. Although Vue 2.0 had already been announced at the time, which introduced 
+some breaking changes, we built most of our components with the new version’s requirements 
 in mind.
 
 The goal was to reduce the percentage of jQuery and plain HTML while increasing 
-Vue’s presence by creating components of various parts of the application. We also aimed 
+Vue’s presence by creating components for various parts of the application. We also aimed 
 to remove AdminLTE from our app. I have nothing against templates like that, but 
 if you don’t want to give the impression that you’re just another generic app, 
 don’t use them. 

posts/2025-10-10-COMPOSE-SORTING-RULES.md

@@ -17,7 +17,7 @@ ad-hoc sorting logic scattered all over the place, reproduced multiple times, fu
 statements. Things get gnarly the moment complex, nested rules arrive, and maintaining or extending that code quickly
 becomes a nightmare.
 
-Enough "lero-lero", let's see how this works in practice. First, let's lock down our acceptance criteria:
+Enough talk, let's see how this works in practice. First, let's lock down our acceptance criteria:
 
 ```markdown
 **0001: Products must be ordered according to these rules:**
@@ -27,7 +27,7 @@ Enough "lero-lero", let's see how this works in practice. First, let's lock down
 3. Product categories must be ordered alphabetically by their `name`.
 ```
 
-With that in mind we can start modeling the problem we want to solve. We face two entities: Product and Category. In
+With that in mind we can start modeling the problem we want to solve. We have two entities: Product and Category. In
 this example the relationship is 1:1. We'll introduce them with interfaces, which lets us reuse them freely while
 abstracting away any concrete implementation details that do not matter right now.
 
@@ -74,8 +74,8 @@ const ordCategoriesAlphabetically: Ord.Ord<Category> = pipe(
 ```
 
 Now we have an `Ord<Category>` (and, by extension, an `Ord<Product>`) that partially solves criteria 1 and 3. Next we
-have to handle criteria 2, which we can rephrase as: "Products must be ordered by category." Once again we face the same
-shape of problem, we want a type to follow the ordering of one of its internal attributes. So we can reuse the exact
+have to handle criteria 2, which we can rephrase as: "Products must be ordered by category." Once again we're looking at the same
+kind of problem, we want a type to follow the ordering of one of its internal attributes. So we can reuse the exact
 same
 strategy:
 
@@ -98,13 +98,13 @@ const ordProductsAlphabeticallyByCategory: Ord.Ord<Product> = pipe(
 )
 ```
 
-Although we've addressed each requirement individually, and in a reusable way that extends beyond the original problem.
+Although we've addressed each requirement individually, and in a reusable way that extends beyond the original problem,
 we
-still need a mechanism to combine these rules so they deliver the result we actually want. This is where a remarkably
-powerful tool steps in: the Monoid[^3].
+still need a way to combine these rules so they deliver the result we actually want. This is where the Monoid[^3]
+steps in.
 
-Yes, the name sounds odd, but there's no reason to panic. Think of Monoids as pressure cookers: surprisingly easy to
-operate and capable of making your life a lot simpler.
+Yes, the name sounds odd, but there's no reason to panic. Think of Monoids as pressure cookers: easy to
+operate and they make your life a lot simpler.
 
 ```ts
 import * as M from 'fp-ts/Monoid'
@@ -128,7 +128,7 @@ const ordProducts: Ord.Ord<Product> = combineMultipleOrds([
 ])
 ```
 
-The result is still an `Ord<Product>`, but now each criteria lives in isolation, making maintenance equally isolated.
+The result is still an `Ord<Product>`, but now each rule lives in isolation, making maintenance equally isolated.
 The implementation also becomes a semantic entry point for understanding the sorting rules. By combining them in a list
 we get a ranking view where we can quickly see which rule takes precedence. We can toggle them on or off with nothing
 more than a comment.
@@ -162,7 +162,7 @@ const ordProducts: Ord.Ord<Product> = M.concatAll(Ord.getMonoid())([
 ])
 ```
 
-Stop the machines! The users started complaining, the unavailable products buried the items they actually wanted to see.
+Stop the presses! The users started complaining, the unavailable products buried the items they actually wanted to see.
 A new requirement pops
 up:
 

posts/2025-10-23-A-BIT-MORE-CONTRAMAP.md

@@ -34,7 +34,7 @@ alphabetically without changing the original `Ord<string>`. The same pattern sho
 module [^3] is a good example because it helps you model rules, filters, and guards that capture your business logic.
 These tiny pieces feel simple, but they can be used to build complex logic.
 
-Let us turn that into requirements and code.
+Let's turn that into requirements and code.
 
 ```markdown
 0001: As a user, I want to see products as unavailable when the category is disabled.
@@ -43,7 +43,7 @@ Let us turn that into requirements and code.
 2. The products with disabled categories must be considered unavailable.
 ```
 
-Let us model these requirements with types:
+Let's model these requirements with types:
 
 ```ts
 interface Category {
@@ -110,7 +110,7 @@ const isReviewInactive: P.Predicate<Review> = pipe(
 )
 ```
 
-For teaching purposes, we can inline every step so this bridge's behavior becomes crystal clear:
+For teaching purposes, we can inline every step so the full chain becomes crystal clear:
 
 ```ts
 // Review module
@@ -132,7 +132,7 @@ const isReviewInactive: P.Predicate<Review> = pipe(
 Conclusion
 
 `contramap` works like that universal adapter you carry when you travel. It bridges shapes that don’t naturally fit,
-keeping what already works untouched. The trick is simple but powerful: instead of changing your logic, you adapt
+keeping what already works untouched. The trick is small: instead of changing your logic, you adapt
 the data to match it. Once you start thinking this way, composition stops being an abstract principle and becomes
 a habit. You spend less time rewriting and more time connecting the pieces that are already there.