Add GitHub Pages deployment and clean up pandoc artifacts

- Add GitHub Actions workflow for Hugo build and Pages deployment
- Enable footnote support in Goldmark markdown config
- Fix pandoc fenced div artifacts (:::) in no-estimates post
- Fix pandoc code block syntax ({.ruby}, {.bash .code})
- Fix pandoc span class artifacts ({.s1}) in team-values
- Fix footnote syntax to Hugo format ([^1]) in one-percent and
  write-comments-for-yourself posts
- Clean escaped $, @, and numbered list artifacts across posts

AI-Generated-By: Claude Opus 4.6 (claude-opus-4-6) via Claude Code (2.1.89)

Author: booch

.github/workflows/hugo.yml

@@ -0,0 +1,63 @@
+name: Deploy Hugo site to Pages
+
+on:
+  push:
+    branches: ["main"]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+defaults:
+  run:
+    shell: bash
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    env:
+      HUGO_VERSION: 0.160.0
+    steps:
+      - name: Install Hugo CLI
+        run: |
+          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
+          && sudo dpkg -i ${{ runner.temp }}/hugo.deb
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+          fetch-depth: 0
+      - name: Setup Pages
+        id: pages
+        uses: actions/configure-pages@v5
+      - name: Build with Hugo
+        env:
+          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
+          HUGO_ENVIRONMENT: production
+          TZ: America/Chicago
+        run: |
+          hugo \
+            --gc \
+            --minify \
+            --baseURL "${{ steps.pages.outputs.base_url }}/"
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: ./public
+
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

content/posts/agile-estimation.md

@@ -38,19 +38,19 @@ What if there's more than 1 thing that's most important? Then you've failed. You
 
 # Arguments
 
-1\. Why can't you just tell us how long it will really take?
+1. Why can't you just tell us how long it will really take?
 
 Because we don't know. Because we **can't** know. This is the first time we've ever implemented the functionality you've asked for. If we'd done it before, we'd just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on [Software Engineering](http://www.infoq.com/presentations/Software-Engineering), we're not building software, we're architecting it.
 
-2\. But we have to tell our customers what to expect.
+2. But we have to tell our customers what to expect.
 
 Why? Is the product so bad that you can't keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
 
-3\. But we have to have messaging about new features.
+3. But we have to have messaging about new features.
 
 OK. Then send out that messaging once the feature has made it to Staging. Or even after it's been rolled out to Production.
 
-4\. But we've promised these new features to the customers by this date.
+4. But we've promised these new features to the customers by this date.
 
 Ah, so you've made promises to the customer that you don't have control over. Have you ever heard of "under-promise and over-deliver"? That's how you create happy customers. Yet you've done just the opposite, haven't you? And then you want to blame someone else.
 
@@ -75,7 +75,7 @@ Teams should question what the manager actually needs, rather than blindly expos
 
 ### Olena — 2014-10-07
 
-2\. But we have to tell our customers what to expect.\
+2. But we have to tell our customers what to expect.\
 Why? Is the product so bad that you can't keep customers around without leading them on with future enhancements? And why do customers need exact dates?
 
 A lot of cases when you have to make brand new feature faster than your competitor or you have to meet deadline with other external things (like releasing iOS8, whatever). Or just an example when you are expecting a house will be done before winter comes so you can live in there, but workers didn't finish it in time. Would you like to have no promises on deadline and make a decisions on each day of life? I don't think so. Agile is for business, and if doesn't make a things enhancing income -- it doesn't work.

content/posts/bulk-rename-in-bash.md

@@ -12,7 +12,7 @@ Here's a relatively simple way to rename a bunch of files from the command line.
 
 In this example, we're renaming files that start with "ABC" to start with "XYZ" instead:
 
-``` {.bash .code}
+```bash
   for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
 ```
 

content/posts/grenade-debugging-pattern.md

@@ -51,14 +51,15 @@ end\
 I'm sure we could wrap that in some more semantic sugar, even going as far as\
 making it look something like this:
 
-\
-`class Xyz`{.ruby}\
-`...`{.ruby}\
-`def xyz`{.ruby}\
-`object_under_investigation.blow_up_when_method_called(:method_under_investigation)`{.ruby}\
-`end`{.ruby}\
-`...`{.ruby}\
-`end`{.ruby}\
+```ruby
+class Xyz
+  ...
+  def xyz
+    object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+  end
+  ...
+end
+```
 
 I'm not sure that would really be worth it though, unless we were to add it to\
 some sort of library.

content/posts/introspective.md

@@ -86,7 +86,7 @@ trust to be your facilitator.
 I've decided to call this thing an introspective. A retrospective is\
 about looking back. This is about looking inward. I'd be interested to\
 find out who is doing this kind of thing. Does it have a commonly accepted\
-name? How does it work? What techniques work best? If you've got any answers or ideas, please comment below, or tweet me \@CraigBuchek.
+name? How does it work? What techniques work best? If you've got any answers or ideas, please comment below, or tweet me @CraigBuchek.
 
 So thank you to that anonymous person. Your way of addressing this was\
 probably more effective than you could have imagined that it might be.\

content/posts/my-thoughts-on-python-vs-ruby.md

@@ -16,8 +16,8 @@ So while I still prefer Ruby, and will likely use Ruby more in the future than P
 Where Python Sucks (As Compared to Ruby)
 
 - Have to explicitly include **self** in **EVERY** method declaration.
-  - Including **\@classmethod** declarations (although people usually use the name **cls** instead of **self** there).
-  - Except **\@staticmethod** declarations.
+  - Including **@classmethod** declarations (although people usually use the name **cls** instead of **self** there).
+  - Except **@staticmethod** declarations.
 - Have to use **self** everywhere to reference an object's own attributes.
 - Inconsistency of things like the **len()** function, when everything else is a method.
 - Inconsistency of having some built-in classes with lower-case names.
@@ -37,7 +37,7 @@ Where Python Sucks (As Compared to Ruby)
   - Have to often resort to creating an initial list and adding to it in a **for** loop.
 - I don't understand why r'regex_string' doesn't just create an actual regular expression object.
 - I miss Ruby's method-call-or-property-getter syntax.
-  - Nice that I can get it by adding **\@property** to method definitions, but that's a bit messy.
+  - Nice that I can get it by adding **@property** to method definitions, but that's a bit messy.
 - I don't understand why lists don't have a **join()** method; it seems backwards to call **join** on the string used to connect the list elements.
 - I miss **unless**; seems like with all the keywords, Python would have added that.
 - I really miss **\|\|=** to memoize.

content/posts/no-estimates.md

@@ -5,8 +5,6 @@ slug: no-estimates
 draft: false
 ---
 
-:::: {#fhbody-76784315}
-::: {#text-76784315}
 I'm a big proponent of Agile (mostly XP; I'm mostly anti-Scrum) and I've contributed some to the #noestimates "movement".
 
 I don't really mean that nobody should ever estimate anything. I mean that I've never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I've seen frequently:
@@ -29,8 +27,3 @@ Another way to mitigate the risk of throwing money at something that's not going
 At a fine-grained level, if you're using story points, I'd ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I'd still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size --- with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you're looking for?)
 
 And don't forget Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
-:::
-::::
-
-::: {}
-:::

content/posts/one-percent.md

@@ -15,13 +15,13 @@ That may seem like a lot of time "wasted". But I think I can justify the cost of
 
 The purpose of spending time on team or self-improvement --- the whole point --- is to increase our performance and our efficiency. How much improvement can we expect? Can we improve by 1% each week? That doesn't sound too unreasonable. I think that's an achievable goal for almost any team, at least on average.
 
-Spending 20% of your time to gain 1% doesn't seem like it's worth it --- until you consider the long term. With compound interest, you'll be 67% more efficient by the end of a year.^[1](#1)^ At that point, you'll be able to get things done in 59% of the time --- saving 41% of the time required at the beginning of the year.^[2](#2)^ The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
+Spending 20% of your time to gain 1% doesn't seem like it's worth it --- until you consider the long term. With compound interest, you'll be 67% more efficient by the end of a year.[^1] At that point, you'll be able to get things done in 59% of the time --- saving 41% of the time required at the beginning of the year.[^2] The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
 
 So there's a pretty good return on investment, even with a small amount of improvement each week. You'll be significantly more efficient.
 
 But efficiency isn't really what you should aim for. You should aim for effectiveness. You can be efficient in creating the wrong thing. Part of improving should be ensuring that you're not just building things right, but that you're building the right things. Build what the customer really needs. Find ways to ask the right questions.
 
 Most importantly, find ways to keep improving. It would be a waste of time not to.
 
-[1]{#1}: (1.01 \^ 52) -- 1\
-[2]{#2}: (0.99 \^ 52)
+[^1]: (1.01 ^ 52) - 1
+[^2]: (0.99 ^ 52)

content/posts/team-values.md

@@ -22,10 +22,8 @@ After everyone put their values up on the board, we read them off. Then I asked
 
 I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense --- they're not as intimately involved in the process of building the product.
 
-We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: [Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that's a pretty decent list.]{.s1}
-
-[As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we'd probably come up with other answers if asked again, just due to randomness of the way we think about these things.]{.s1}
-
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: [Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that's a pretty decent list.]
+[As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we'd probably come up with other answers if asked again, just due to randomness of the way we think about these things.]
 But I don't think I'd do this activity a second time with the team. It was really about understanding our motivations --- both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
 
 There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn't work if people weren't honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don't think that was an issue with this group, but it's something to keep in mind.

content/posts/write-comments-for-yourself-2.md

@@ -15,10 +15,10 @@ I agree with that, to a point. First off, it's not necessary to write perfect c
 
 After our argument, I came up with a good rule of thumb (or "pattern"):
 
-> Write comments for your (future) self.^[1](#footnote_1)^
+> Write comments for your (future) self.[^1]
 
 In other words, if your comment will help you to understand the code more quickly when you look at it in the future, then it's a valid comment. It also means that you can assume that the reader has about as much general programming knowledge as you currently do. (Your future self will have more general knowledge, but possibly less specific knowledge of the lines of code in question. And because of this, your current solution might not make as much sense in the future. You might know of a better solution in the future, but you'll have to know all the constraints that you had when you originally wrote the code.)
 
 This is not to say that you should not write comments in clear English, that others can understand. The comment is written for a future maintainer. That may be you (which is why the rule works well), or it may be someone else. The rule is more about when to write a comment, and what level of competence you should assume of the reader.
 
-^1^ Perhaps it should be "Write comments TO your (future) self".
+[^1]: Perhaps it should be "Write comments TO your (future) self".