diff --git a/content/posts/tiny-binaries-rust.md b/content/posts/tiny-binaries-rust.md
index dbeed3d..fd3de3f 100644
--- a/content/posts/tiny-binaries-rust.md
+++ b/content/posts/tiny-binaries-rust.md
@@ -183,7 +183,7 @@ The first thing I noticed was that I got some new warnings when compiling, all o
 Next up, I added cargo-bloat to my flake. This tool can show you which functions take up most of the space in your binary.
 The invocation is similar to building - `cargo bloat --example announce --profile=size-optimized` resulted in the following output:
 
-```
+```text
 File  .text     Size        Crate Name
  1.0%   5.5%  21.0KiB clap_builder clap_builder::parser::parser::Parser::get_matches_with
  0.9%   5.3%  20.5KiB          std std::backtrace_rs::symbolize::gimli::Cache::with_global
@@ -224,9 +224,9 @@ Let's cover those points in order.
 
 Using `GNU size`, we can check the size per section in the ELF binary.
 Using `-G` or `-B` output formats does not work for this, as it will only show the `.text` and `.data` section, which in this case only make up around 500KB.
-Thus the command I used was ` size -A --common target/size-optimized/examples/announce`, giving the following result:
+Thus the command I used was `size -A --common target/size-optimized/examples/announce`, giving the following result:
 
-```
+```text
 section                size     addr
 .dynsym                1680      856
 .dynstr                1198     3500
@@ -260,7 +260,8 @@ While clap is super handy, it looks like the code needed to parse two simple arg
 As the C program I was comparing against had all the parameters hard-coded, I just ripped out the dependency and hard-coded the values I needed.
 
 The result is the first version of `tiny_announce`, as I did not want to change the existing example.
-```
+
+```rust
 //! An example for how to send text to the display.
 
 use servicepoint::{
@@ -308,7 +309,7 @@ This produces a binary that is now only 30.992 bytes!
 
 The remaining top 3 functions were:
 
-```
+```text
  File  .text    Size         Crate Name
  4.4%  11.0%  2.0KiB           std <&T as std::net::socket_addr::ToSocketAddrs>::to_socket_addrs
  3.8%   9.4%  1.7KiB tiny_announce tiny_announce::main
diff --git a/content/posts/why-i-do-not-use-flake-utils.md b/content/posts/why-i-do-not-use-flake-utils.md
index 6bc7ab2..6f79f2c 100644
--- a/content/posts/why-i-do-not-use-flake-utils.md
+++ b/content/posts/why-i-do-not-use-flake-utils.md
@@ -102,7 +102,7 @@ This is useful, for example, if the target environment you're developing for can
 
 For me, the trade-offs are worth it, as they provide greater transparency and control over the flake configuration.
 
-That being said, I fully acknowledge that `flake-utils` can still be a great choice for many people. 
+That being said, I fully acknowledge that `flake-utils` can still be a great choice for many people.
 It simplifies things and reduces the need to write boilerplate code, which can be a plus depending on your needs and workflow.
 Ultimately, it's also matter of personal preference.