<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Essays on Aaron Norling</title>
    <link>https://aaronnorling.com/essays/</link>
    <description>Recent content in Essays on Aaron Norling</description>
    <generator>Hugo</generator>
    <language>en-US</language>
    <lastBuildDate>Tue, 17 Jun 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://aaronnorling.com/essays/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Simple GitHub Workflow For Spiker</title>
      <link>https://aaronnorling.com/essays/simple-github-workflow-for-spiker/</link>
      <pubDate>Tue, 17 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://aaronnorling.com/essays/simple-github-workflow-for-spiker/</guid>
      <description>&lt;h1 id=&#34;-simple-github-workflow-for-spiker&#34;&gt;🧪 Simple GitHub Workflow For Spiker&lt;/h1&gt;&#xA;&lt;p&gt;One of the things I love about the &lt;a href=&#34;https://github.com/norlinga/spiker&#34;&gt;Spiker gem&lt;/a&gt; is how easy it makes it to spin up a clean, isolated environment for trying out ideas. Whether I&amp;rsquo;m validating a concept, writing up a quick example for a coworker, or demonstrating technical proficiency, &lt;strong&gt;Spiker helps me get there faster&lt;/strong&gt;. ⚡&lt;/p&gt;&#xA;&lt;p&gt;And if you&amp;rsquo;re spiking with the intention of &lt;em&gt;sharing&lt;/em&gt; your spikes, one simple addition could transform your spikes from helpful to &lt;em&gt;impressive&lt;/em&gt;: &lt;strong&gt;a GitHub Actions workflow&lt;/strong&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Patterns in Reach</title>
      <link>https://aaronnorling.com/essays/patterns-in-reach/</link>
      <pubDate>Mon, 02 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://aaronnorling.com/essays/patterns-in-reach/</guid>
      <description>&lt;h1 id=&#34;patterns-in-reach&#34;&gt;Patterns in Reach&lt;/h1&gt;&#xA;&lt;p&gt;&lt;em&gt;A case for reflexive, lightweight abstractions in Ruby and Rails development&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve recently participated in a few conversations exploring how to strike a balance between simplicity and structure in software development.  Structure, in the context of these conversations, has become a sort of dirty word with structure or &amp;ldquo;patterns&amp;rdquo; being held synonymous with &amp;ldquo;complexity.&amp;rdquo;  A cohort of developers has been preaching an attractive, minimalistic gospel: &lt;em&gt;&amp;ldquo;You Aren&amp;rsquo;t Gonna Need It!&amp;rdquo;&lt;/em&gt;, &lt;em&gt;&amp;ldquo;Keep it simple, stupid!&amp;rdquo;&lt;/em&gt;, and so on.  These slogans have their place — they&amp;rsquo;re reminders to avoid premature optimization and needless complexity.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Teaching (and Assessing) With Spiker</title>
      <link>https://aaronnorling.com/essays/teaching-with-spiker/</link>
      <pubDate>Thu, 15 May 2025 00:00:00 +0000</pubDate>
      <guid>https://aaronnorling.com/essays/teaching-with-spiker/</guid>
      <description>&lt;h1 id=&#34;teaching-and-assessing-ruby-developers--on-their-own-terms&#34;&gt;Teaching and Assessing Ruby Developers — on Their Own Terms&lt;/h1&gt;&#xA;&lt;p&gt;I&amp;rsquo;m the author of &lt;a href=&#34;https://github.com/norlinga/spiker&#34;&gt;Spiker&lt;/a&gt;, a Ruby project scaffolding gem for test-driven exploration. I wrote Spiker in the conviction that the best way to &lt;em&gt;learn&lt;/em&gt; is to &lt;em&gt;build&lt;/em&gt;. Spiker helps Ruby developers get &lt;em&gt;building&lt;/em&gt; fast, with just enough structure to support clean iteration, testing, and discovery.&lt;/p&gt;&#xA;&lt;p&gt;Recently, I had a job interview where the format was to build code in response to a series of tests added by the interviewer. The idea was solid — test-driven interviewing — but the process was clunky. Tests were added manually. Screen sharing and control-passing slowed everything down. I couldn&amp;rsquo;t use the tools or editor I was most comfortable with.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A First Step in a Testing Journey</title>
      <link>https://aaronnorling.com/essays/a-first-step-in-a-testing-journey/</link>
      <pubDate>Wed, 23 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://aaronnorling.com/essays/a-first-step-in-a-testing-journey/</guid>
      <description>&lt;h1 id=&#34;a-first-step-in-a-testing-journey&#34;&gt;A First Step in a Testing Journey&lt;/h1&gt;&#xA;&lt;p&gt;I&amp;rsquo;m writing this essay to my past, testing-skeptical self.  This is the essay I wish I had read at the beginning of my Ruby career.&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;Dear Past Self,&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;em&gt;Trust me - I understand.  You had every reason to be annoyed by the perpetually broken test suites and the testing acolytes who couldn&amp;rsquo;t explain &amp;gt; themselves.  All you saw around you were wild eyed fanatics who spent their time arguing about matchers and tuning Rspec outputs to have better &amp;gt; colors&amp;hellip; but couldn&amp;rsquo;t explain what was wrong when anything broke in production.  You &amp;ldquo;tested&amp;rdquo; in IRB and you shipped code.  And you shipped it fast!  &amp;gt; Which is not to say that you were living a stress-free life.  New features were scary, and building new features was slow and getting slower all the &amp;gt; time.  Not great.&lt;/em&gt;&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
