<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-US">
    <title>imagining the future</title>
    <link rel="self" type="application/atom+xml" href="https://www.livinginthepast.org/atom.xml"/>
    <link rel="alternate" type="text/html" href="https://www.livinginthepast.org"/>
    <generator uri="https://www.getzola.org/">Zola</generator>
    <updated>2026-03-17T00:00:00+00:00</updated>
    <id>https://www.livinginthepast.org/atom.xml</id>
    <entry xml:lang="en-US">
        <title>No tea no shade</title>
        <published>2026-03-17T00:00:00+00:00</published>
        <updated>2026-03-17T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/no-tea-no-shade/"/>
        <id>https://www.livinginthepast.org/blog/no-tea-no-shade/</id>
        
        <summary type="html">&lt;div class=&quot;bevy-embed&quot; style=&quot;aspect-ratio: 2.35 &#x2F; 1; background: linear-gradient(rgba(255,255,255,0.85), rgba(255,255,255,0.85)), url(&#x27;&#x2F;2026&#x2F;hillside-980x.png&#x27;) center &#x2F; cover&quot;&gt;
  &lt;canvas id=&quot;hillside-canvas&quot; style=&quot;pointer-events: none;&quot;&gt;&lt;&#x2F;canvas&gt;
  &lt;div class=&quot;webgpu-warning&quot;&gt;
    &lt;p&gt;This visualization requires WebGPU.&lt;&#x2F;p&gt;
  &lt;&#x2F;div&gt;
&lt;&#x2F;div&gt;
&lt;script type=&quot;module&quot;&gt;
if (!navigator.gpu) {
  document.querySelector(&quot;.webgpu-warning&quot;).style.display = &quot;flex&quot;;
} else {
  document.querySelector(&quot;.webgpu-warning&quot;).style.display = &quot;none&quot;;
  const init = (await import(&quot;&#x2F;2026&#x2F;hillside.js&quot;)).default;
  await init(&quot;&#x2F;2026&#x2F;hillside_bg.wasm&quot;);
}
&lt;&#x2F;script&gt;
&lt;p&gt;I&#x27;ve been playing around with the &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;bevy.org&#x2F;&quot;&gt;Bevy&lt;&#x2F;a&gt; game engine off and on since
I was first introduced to it. My experiences over the years have been both extremely
positive and extremely frustrating, in equal measure, but in past attempts I&#x27;ve gotten
bogged down in problems (of my own design) such that I was not able to get very far into
development of actual game play.&lt;&#x2F;p&gt;
&lt;p&gt;This time around, I&#x27;m tackling a much more ambitious game scope, but with less ambiguous
game mechanics. This post won&#x27;t go too deeply into the technical details, or even the
game itself, but will be an overview of my experiences as well as why it&#x27;s going better
this time around.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Agentic software is just software</title>
        <published>2025-06-04T00:00:00+00:00</published>
        <updated>2025-06-04T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/agents/"/>
        <id>https://www.livinginthepast.org/blog/agents/</id>
        
        <summary type="html">&lt;p&gt;Friends of mine hear a bit of snark from me when it comes to the recent explosion of hype
regarding AI, how it will solve all of the world&#x27;s problems (while &lt;em&gt;definitely&lt;&#x2F;em&gt;
not causing any new ones), and how it&#x27;s revolutionizing software development. This post is
an attempt at something other than snark; it&#x27;s an attempt to get to the heart of the
snark, to a thing that has been clear to me whenever anyone talks about the next wave
of AI: agentic AI.&lt;&#x2F;p&gt;
&lt;p&gt;Agentic AI is not new. Agentic software is just a new term to describe an old concept
that we used to call: software.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Fast FreeBSD with ZFS on Vultr</title>
        <published>2025-05-29T00:00:00+00:00</published>
        <updated>2025-05-29T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/vultr-freebsd-bootstrap/"/>
        <id>https://www.livinginthepast.org/blog/vultr-freebsd-bootstrap/</id>
        
        <summary type="html">&lt;p&gt;For the past year I&#x27;ve been running several Postgres databases in FreeBSD VPS&#x27;s hosted in
&lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;www.vultr.com&quot;&gt;Vultr&lt;&#x2F;a&gt;. I run Postgres in jails, FreeBSD&#x27;s abstraction for OS-level
virtualization. Jails work very well when paired with ZFS, so I prefer to run my hosts
using ZFS for the root file system.&lt;&#x2F;p&gt;
&lt;p&gt;Unfortunately, although Vultr provides FreeBSD images, those images use UFS on root instead
of ZFS. Because of that, I&#x27;ve been setting up my VPS&#x27;s by creating them from a custom bootonly
ISO, and then installing FreeBSD from scratch. This has worked relatively well, except for the
fact that for some reason the boot process would pause for about 30-60 seconds. When creating
a VPS from Vultr&#x27;s FreeBSD images, the boot was fast.&lt;&#x2F;p&gt;
&lt;p&gt;This made me very concerned about rebooting my hosts. No more! Today I discovered the problem.&lt;&#x2F;p&gt;
&lt;p&gt;&lt;em&gt;tldr; Create your VPS from the Vultr-provided FreeBSD image, then attach a bootonly ISO and
reinstall the OS from scatch.&lt;&#x2F;em&gt;&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Acceptable Upgrades</title>
        <published>2025-03-10T00:00:00+00:00</published>
        <updated>2025-03-10T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/acceptable-upgrades/"/>
        <id>https://www.livinginthepast.org/blog/acceptable-upgrades/</id>
        
        <summary type="html">&lt;p&gt;Last week I had the opportunity to speak at Code BEAM America 2025 in San Francisco. I find Code BEAM to be
one of the best conferences for connecting with people in my industry working in Elixir and Erlang—not only
socially, but in terms of the cutting edge.&lt;&#x2F;p&gt;
&lt;p&gt;I spoke about introducing tests to an application with an existing and challenging database schema. 25
minutes is challenging when putting together a talk—on the project that inspired this talk, I learned a
lot about using Ecto for legacy schemas that just couldn&#x27;t fit into time. That said, the challenge
caused me to distill some code organization rules that I like to use into what the core principles behind
them. I believe that applying these rules will result in faster development and fewer bugs, but even if
you don&#x27;t want to apply them directly, perhaps the thinking behind them will be useful to you!&lt;&#x2F;p&gt;
&lt;p&gt;Take a look at the slides below.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Test Your Seeds</title>
        <published>2024-05-17T00:00:00+00:00</published>
        <updated>2024-05-17T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/test-your-seeds/"/>
        <id>https://www.livinginthepast.org/blog/test-your-seeds/</id>
        
        <summary type="html">&lt;p&gt;When building products with &lt;code&gt;Phoenix&lt;&#x2F;code&gt; and &lt;code&gt;Ecto&lt;&#x2F;code&gt;, a common practice is to include
development seeds in a file named &lt;code&gt;priv&#x2F;repo&#x2F;seeds.exs&lt;&#x2F;code&gt;. By default, it&#x27;s expected
that this file will include a list of actions to run procedurally upon loading the
file. With a few changes, we can instead make a testable module, so that we will know
when our refactors will break the seeds for ourselves and for others.&lt;&#x2F;p&gt;
&lt;img src=&#x27;&#x2F;2024&#x2F;lukasz-rawa-NDro8tjU4e0-unsplash.jpg&#x27; alt=&#x27;Łukasz Rawa @ Unsplash : https:&#x2F;&#x2F;unsplash.com&#x2F;photos&#x2F;brown-and-black-dried-leaves-NDro8tjU4e0&#x27; &#x2F;&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>I did a thing! aka Test Reflector</title>
        <published>2024-04-29T00:00:00+00:00</published>
        <updated>2024-04-29T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/test-reflector/"/>
        <id>https://www.livinginthepast.org/blog/test-reflector/</id>
        
        <summary type="html">&lt;p&gt;tldr; &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;www.testreflector.app&quot;&gt;Test Reflector&lt;&#x2F;a&gt;.&lt;&#x2F;p&gt;
&lt;p&gt;Over the past two years I&#x27;ve written or helped to write
&lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;github.com&#x2F;synchronal&quot;&gt;a lot of open source software&lt;&#x2F;a&gt;. I would say that
the last two years have been the most productive in my life, in terms of sheer
amount of productive and useful lines of code that I have created. While I don&#x27;t
believe that lines of code are necessarily the best success metric, in terms of
that code being useful to me, helping me to develop applications
faster, and having confidence in the quality of code that I have shipped in
production apps over that time… the last two years have been pretty good.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Gogalixir</title>
        <published>2024-02-20T00:00:00+00:00</published>
        <updated>2024-02-20T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/gogalixir-intro/"/>
        <id>https://www.livinginthepast.org/blog/gogalixir-intro/</id>
        
        <summary type="html">&lt;p&gt;For a long time I&#x27;ve wanted there to be a single-track conference in the Bay Area
focused on Elixir and Erlang, in the vein of &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;github.com&#x2F;gogaruco&quot;&gt;gogaruco&lt;&#x2F;a&gt;.
I love &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;codebeamamerica.com&quot;&gt;Code BEAM&lt;&#x2F;a&gt; (and am attending this year!), but
there&#x27;s something to be said for smaller, locally-organized conferences where you
get to meet people in your regional programming community—where you don&#x27;t have to
decide between conference talks, but have a single shared experience among all
attendees.&lt;&#x2F;p&gt;
&lt;p&gt;My friend and business partner &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;eahanson.com&quot;&gt;Erik Hanson&lt;&#x2F;a&gt; and I have been
talking about this conference for years. We were excited enough about it that we
even &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;gogalixir.com&quot;&gt;bought a domain&lt;&#x2F;a&gt;. What we didn&#x27;t have was any experience
in planning or organizing a large event.&lt;&#x2F;p&gt;
&lt;p&gt;This winter, we decided that we could solve the problem of not knowing what we&#x27;re
doing by starting smaller. Thus was the &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;gogalixir.com&quot;&gt;Golden Gate Elixir Meetup&lt;&#x2F;a&gt;
born.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Migrating Databases with Ecto</title>
        <published>2022-11-25T00:00:00+00:00</published>
        <updated>2022-11-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/migrating-data-with-ecto/"/>
        <id>https://www.livinginthepast.org/blog/migrating-data-with-ecto/</id>
        
        <summary type="html">&lt;p&gt;On a new project I&#x27;m working to migrate data between Azure SQL (aka MSSQL) and
PostgreSQL, and to migrate a business&#x27;s software from Visual Basic and C# to Elixir.
In the first few weeks of development I&#x27;ve discovered some features of Ecto that
I was previously unaware of. Combining these features will allow us to ship a resilient,
well-tested application while constraining the possibility of accidentally
altering data in production.&lt;&#x2F;p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #E6EDF3; background-color: #0D1117;&quot;&gt;&lt;code data-lang=&quot;elixir&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;defmodule&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;Integration&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;CrossRepoTransactions&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt; do&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;  use&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;DataCase&lt;&#x2F;span&gt;&lt;span&gt;,&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; async: true&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;  test &lt;&#x2F;span&gt;&lt;span style=&quot;color: #A5D6FF;&quot;&gt;&amp;quot;sharing database connections&amp;quot;&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt; do&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;    {&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;:ok&lt;&#x2F;span&gt;&lt;span&gt;, alice}&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt; =&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;        Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Fixtures&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;azure_person&lt;&#x2F;span&gt;&lt;span&gt;(&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;:alice&lt;&#x2F;span&gt;&lt;span&gt;)&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;        |&amp;gt;&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Azure&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Person&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;changeset&lt;&#x2F;span&gt;&lt;span&gt;()&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;        |&amp;gt;&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Azure&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;WriteableRepo&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;insert!&lt;&#x2F;span&gt;&lt;span&gt;()&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;    assert {&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;:ok&lt;&#x2F;span&gt;&lt;span&gt;,&lt;&#x2F;span&gt;&lt;span style=&quot;color: #8B949E;&quot;&gt; _&lt;&#x2F;span&gt;&lt;span&gt;}&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt; =&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Azure&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;ReadOnlyRepo&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;get&lt;&#x2F;span&gt;&lt;span&gt;(&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Azure&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Person&lt;&#x2F;span&gt;&lt;span&gt;, alice.id)&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;  end&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;end&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>ExUnit Patterns for Ease of Mind</title>
        <published>2022-09-12T00:00:00+00:00</published>
        <updated>2022-09-12T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/exunit-tags-test-setup/"/>
        <id>https://www.livinginthepast.org/blog/exunit-tags-test-setup/</id>
        
        <summary type="html">&lt;p&gt;In recent months I have been working on a number of projects with my primary collaborator
of recent years, &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;github.com&#x2F;eahanson&quot;&gt;Erik Hanson&lt;&#x2F;a&gt;. Some of those projects
have led to a number of &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;github.com&#x2F;synchronal&quot;&gt;open source Elixir libraries&lt;&#x2F;a&gt;.
Others may be eventually be open sourced, but are currently private.&lt;&#x2F;p&gt;
&lt;p&gt;In this post, I&#x27;d like to share a set of patterns that work together to ease test setup
and organization. The examples shown will be for &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;hexdocs.pm&#x2F;ex_unit&#x2F;ExUnit.html&quot;&gt;ExUnit&lt;&#x2F;a&gt;
and &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;phoenixframework.org&quot;&gt;Phoenix&lt;&#x2F;a&gt;, but could be adapted to other languages and
frameworks.&lt;&#x2F;p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #E6EDF3; background-color: #0D1117;&quot;&gt;&lt;code data-lang=&quot;elixir&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;defmodule&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; Web&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;ProfileLiveTest&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt; do&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;  use&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;ConnCase&lt;&#x2F;span&gt;&lt;span&gt;,&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; async: true&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;  @tag&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; page: :alice&lt;&#x2F;span&gt;&lt;span&gt;,&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; profile:&lt;&#x2F;span&gt;&lt;span&gt; [&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;:alice&lt;&#x2F;span&gt;&lt;span&gt;]&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;  test &lt;&#x2F;span&gt;&lt;span style=&quot;color: #A5D6FF;&quot;&gt;&amp;quot;shows profile info&amp;quot;&lt;&#x2F;span&gt;&lt;span&gt;, %{&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;pages:&lt;&#x2F;span&gt;&lt;span&gt; %{&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;alice:&lt;&#x2F;span&gt;&lt;span&gt; page},&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt; profiles:&lt;&#x2F;span&gt;&lt;span&gt; %{&lt;&#x2F;span&gt;&lt;span style=&quot;color: #79C0FF;&quot;&gt;alice:&lt;&#x2F;span&gt;&lt;span&gt; alice}}&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt; do&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;    page&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;    |&amp;gt;&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Pages&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;ProfilePage&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;visit&lt;&#x2F;span&gt;&lt;span&gt;()&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;    |&amp;gt;&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Pages&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;ProfilePage&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;assert_here&lt;&#x2F;span&gt;&lt;span&gt;()&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;    |&amp;gt;&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt; Test&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;Pages&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #FFA657;&quot;&gt;ProfilePage&lt;&#x2F;span&gt;&lt;span&gt;.&lt;&#x2F;span&gt;&lt;span style=&quot;color: #D2A8FF;&quot;&gt;assert_profile_info&lt;&#x2F;span&gt;&lt;span&gt;(alice.name, alice.email)&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;  end&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span style=&quot;color: #FF7B72;&quot;&gt;end&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>CodeBEAM V America 2021</title>
        <published>2021-06-21T00:00:00+00:00</published>
        <updated>2021-06-21T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/codebeam-v-america-2021/"/>
        <id>https://www.livinginthepast.org/blog/codebeam-v-america-2021/</id>
        
        <summary type="html">&lt;p&gt;Back in March I gave a talk at &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;codesync.global&#x2F;conferences&#x2F;code-beam-v-america-2021&#x2F;&quot;&gt;CodeBEAM V America&lt;&#x2F;a&gt;
about some of the work that I did at Geometer in 2020. I started work at Geometer
the same week that the SF Bay Area began its lockdown for Covid-19—while the purpose
of Geometer was to be a startup incubator, on my first day there was an all-hands where
Rob, the founder, said that for the forseeable future we would devote our efforts to
pandemic relief.&lt;&#x2F;p&gt;
&lt;p&gt;While working on these projects, I saw parts of the US health system that I knew
existed, but had no idea just how discouraging they would be. I also met (virtually)
health care workers and departments of health officials who were throwing themselves
into work to help save lives, sometimes in spite of the technology that should have
been solving their problems, but instead caused other greater problems.&lt;&#x2F;p&gt;
&lt;h3 id=&quot;tldr&quot;&gt;TLDR;&lt;&#x2F;h3&gt;
&lt;ul&gt;
&lt;li&gt;Before deploying a &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;hexdocs.pm&#x2F;broadway&#x2F;Broadway.html&quot;&gt;Broadway&lt;&#x2F;a&gt; pipeline
to production, really try to understand &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;hexdocs.pm&#x2F;gen_stage&#x2F;GenStage.html&quot;&gt;GenStage&lt;&#x2F;a&gt;.&lt;&#x2F;li&gt;
&lt;li&gt;AWS promotes Lambda as a general purpose data processing tool for high scale
workloads. I found Lambda to be incredibly difficult to monitor or debug, with
quirks in the runtime that were only testable through trial and error.&lt;&#x2F;li&gt;
&lt;li&gt;Broadway&#x2F;Oban&#x2F;Flow could easily handle much greater scale than we were solving
for, in a resilient runtime that was much easier to inspect and debug.&lt;&#x2F;li&gt;
&lt;li&gt;Be thoughtful about naming.
&lt;ul&gt;
&lt;li&gt;I started by grouping data pipelines into high-level domains specific to ETL.
Pipelines pulling data into our system were grouped into &lt;code&gt;Extract&lt;&#x2F;code&gt;.
Pipelines putting data into an external system were grouped into &lt;code&gt;Load&lt;&#x2F;code&gt;. While
technically true, this was the opposite of what new teammates expected when
seeing the word “load.”&lt;&#x2F;li&gt;
&lt;li&gt;A more clear vocabulary might have been that used by
&lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;www.membraneframework.org&quot;&gt;Membrane Framework&lt;&#x2F;a&gt;, ie &lt;code&gt;source&lt;&#x2F;code&gt;, &lt;code&gt;filter&lt;&#x2F;code&gt;,
and &lt;code&gt;sink&lt;&#x2F;code&gt;.&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Freshening Up</title>
        <published>2021-06-17T00:00:00+00:00</published>
        <updated>2021-06-17T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/freshening-up/"/>
        <id>https://www.livinginthepast.org/blog/freshening-up/</id>
        
        <summary type="html">&lt;p&gt;It being 2021, I have decided to air out the website and tune it up. With a working development
and deployment pipeline, my intention is to start doing regular updates.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;Site updates&lt;&#x2F;li&gt;
&lt;li&gt;What&#x27;s been going on?&lt;&#x2F;li&gt;
&lt;li&gt;Elixir&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Decoupling Ruby with RabbitMQ at SF.rb</title>
        <published>2016-04-30T00:00:00+00:00</published>
        <updated>2016-04-30T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/sf-dot-rb-rabbitmq/"/>
        <id>https://www.livinginthepast.org/blog/sf-dot-rb-rabbitmq/</id>
        
        <summary type="html">&lt;p&gt;On Tuesday I spoke at the SF.rb meetup at InstaCart HQ in San Francisco. Here are the slides that I presented from:&lt;&#x2F;p&gt;
&lt;div class=&quot;embed&quot;&gt;
&lt;script async class=&quot;speakerdeck-embed&quot; data-id=&quot;73ef21f416d642d6a2a4d130921b72e8&quot; data-ratio=&quot;1.77777777777778&quot; src=&quot;&#x2F;&#x2F;speakerdeck.com&#x2F;assets&#x2F;embed.js&quot;&gt;&lt;&#x2F;script&gt;
&lt;&#x2F;div&gt;
&lt;p&gt;Other great talks were from Pam Nangan about the technology gap faced by nonprofit organizations, and by Lillie Chilen on the benefits of having a well-run
internship program (and stories of good and bad experiences leading to a well-run program). This is a fantastic meetup, with a focus on diversity of speaker
backgrounds and experience. Thank you so much for having me talk!&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Sharding into big integers</title>
        <published>2016-02-24T00:00:00+00:00</published>
        <updated>2016-02-24T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/sharding-into-bigints/"/>
        <id>https://www.livinginthepast.org/blog/sharding-into-bigints/</id>
        
        <summary type="html">&lt;p&gt;One day you wake up, you grab your laptop, you open your email, you see a strange alert, and you open up your exception tracking service. There you see the following text.&lt;&#x2F;p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #E6EDF3; background-color: #0D1117;&quot;&gt;&lt;code data-lang=&quot;plain&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;ActiveRecord::StatementInvalid: PG::NumericValueOutOfRange:&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;ERROR: integer out of range&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;You then close your laptop and climb back into bed. If anyone asks later, you never saw that message. What even is computer?&lt;&#x2F;p&gt;
&lt;p&gt;By default when Rails migrations create id columns in Postgres, it uses the &lt;code&gt;serial primary field&lt;&#x2F;code&gt; native type, an &lt;code&gt;integer&lt;&#x2F;code&gt;. When reference columns are specified, Rails uses an &lt;code&gt;integer&lt;&#x2F;code&gt;. The range of numbers covered by the integer numeric type in Postgres is:&lt;&#x2F;p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #E6EDF3; background-color: #0D1117;&quot;&gt;&lt;code data-lang=&quot;plain&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;-2147483648 to +2147483647&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;The range of numbers for bigints is:&lt;&#x2F;p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #E6EDF3; background-color: #0D1117;&quot;&gt;&lt;code data-lang=&quot;plain&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;-9223372036854775808 to 9223372036854775807&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;For most datasets, integers are more than enough for the id space of most tables. In the lifetime of a company, the upper bound of integers might never be reached in any database. Unfortunately (or fortunately), we have run into this problem several times now. The first was caused by a bug, where data synchronized between two of our applications unintentionally deleted and recreated the data on a daily basis. A moderate-sized dataset of a few hundred million rows had overflowed the integer space of its ids. Whoops!&lt;&#x2F;p&gt;
&lt;p&gt;This turned out to be a very insidious and unexpected bug, which was particularly interesting to me because of where we have &lt;strong&gt;not&lt;&#x2F;strong&gt; run into integer overflows in the past. We have services with more than three billion records in a single table space. In those applications we have sharded the data heavily, using thousands of Postgres schemas as logical shards across a set of database zones. Because of the nature of that data, however, we were able to generate unique identifiers for each row based on the data in the row, in the form of base62 encoded strings. Doing so allowed us to shard data without having to worry about unique identifier generation—as a side effect, it completely obviated the possibility of integer overflow errors.&lt;&#x2F;p&gt;
&lt;p&gt;The second case where we have had to migrate from integers to bigints was another scalability project. In order to scale writes to one of our internal Rails applications, we decided to split the entire database into multiple shards. The upside was that this was quite easy to do using the Multidb gem; Multidb does not natively do everything we need, but the code is extremely simple, readable, and the missing bits were easy for us to fill in ourselves. The downside was that in order to do this sharding, we needed to generate unique ids across shards.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Decoupling Distributed Ruby applications with RabbitMQ</title>
        <published>2016-02-16T00:00:00+00:00</published>
        <updated>2016-02-16T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/decoupling-distributed-ruby-applications-with-rabbitmq/"/>
        <id>https://www.livinginthepast.org/blog/decoupling-distributed-ruby-applications-with-rabbitmq/</id>
        
        <summary type="html">&lt;p&gt;&lt;strong&gt;Note that this is a repost of an article written for the &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;building.wanelo.com&quot;&gt;Wanelo blog&lt;&#x2F;a&gt;. Take a look there
for other great content.&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;A lot of people might be surprised to hear how long it took us to stand up our message bus infrastructure at Wanelo.
One of the downsides of focusing on iteration is that fundamental architecture changes can seem extremely intimidating.
Embracing iteration means embracing the philosophy that features should be developed with small changes released in small
deployments. The idea of spinning up unfamiliar technology, with its necessary Chef code, changing our applications to
communicate in a new way, then production-izing the deployment through all the attendant failures and misunderstandings
seems... dangerous.&lt;&#x2F;p&gt;
&lt;p&gt;Fortunately &quot;Danger&quot; is our middle name at Wanelo. (Actually, our middle name is &quot;Action.&quot; Wanelo Action Jackson).
Having now developed using a messaging infrastructure for almost a year and a half, I would no longer develop
applications in any other way.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Code for replication delay</title>
        <published>2014-06-11T00:00:00+00:00</published>
        <updated>2014-06-11T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/code-for-replication-delay/"/>
        <id>https://www.livinginthepast.org/blog/code-for-replication-delay/</id>
        
        <summary type="html">&lt;p&gt;&lt;strong&gt;Note that this is a repost of an article written for the &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;building.wanelo.com&quot;&gt;Wanelo blog&lt;&#x2F;a&gt;. Take a look there
for other great content.&lt;&#x2F;strong&gt;&lt;&#x2F;p&gt;
&lt;p&gt;After some recent changes to autovacuum settings on our main PostgreSQL databases, we’ve encountered regular significant replication delay on our four streaming replicas. Why this is happening is an interesting subject for another blog post, but it reminded me of some assumptions built into our codebase, as well as some interesting complications of API design.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>One SMF to Rule Them All</title>
        <published>2013-11-27T00:00:00+00:00</published>
        <updated>2013-11-27T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/one-smf-to-rule-them-all/"/>
        <id>https://www.livinginthepast.org/blog/one-smf-to-rule-them-all/</id>
        
        <summary type="html">&lt;p&gt;Over the past few years I&#x27;ve become a big fan of
&lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;smartos.org&quot;&gt;SmartOS&lt;&#x2F;a&gt;, a distribution of
&lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;wiki.illumos.org&#x2F;display&#x2F;illumos&#x2F;illumos+Home&quot;&gt;Illumos&lt;&#x2F;a&gt; built
specifically with cloud IaaS in mind. One of the features it
inherits from Solaris is the &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Service_Management_Facility&quot;&gt;Service Management
Facility&lt;&#x2F;a&gt;,
SMF. For various reasons, SMF is my service management framework of
choice—one reason we prefer deployment on SmartOS at
&lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;wanelo.com&quot;&gt;Wanelo&lt;&#x2F;a&gt; is the feature-richness and stability of
daemon management under SMF.&lt;&#x2F;p&gt;
&lt;p&gt;One complaint that we had was the management of service families,
however. Recently, we started using service dependencies to help manage
groups of services, particularly in emergency situations when we need to
stop or restart many services at once.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Threads in a GIL</title>
        <published>2013-11-25T00:00:00+00:00</published>
        <updated>2013-11-25T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/threads-in-a-gil/"/>
        <id>https://www.livinginthepast.org/blog/threads-in-a-gil/</id>
        
        <summary type="html">&lt;p&gt;MRI Ruby has a &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Global_Interpreter_Lock&quot;&gt;global interpreter
lock&lt;&#x2F;a&gt; (GIL),
meaning that even when writing multi-threaded Ruby only a single thread
can be on-CPU at any given point in time. Other distributions of Ruby
have done away with the GIL, but even in MRI threads can be useful. The
Sidekiq background worker gem takes advantage of this, running multiple
workers in separate threads within a single process.&lt;&#x2F;p&gt;
&lt;p&gt;If the workload of a job blocks on I&#x2F;O, Ruby can context-switch to other
threads and do other work until the I&#x2F;O finishes. This could happen when
the workload reaches out to an external API, shells out to another command,
or is accessing the file system. Depending on how a job is written, writes
to external storage like an NFS server could block on I&#x2F;O.&lt;&#x2F;p&gt;
&lt;p&gt;If the workload of a process does not block on I&#x2F;O, it will not benefit
from thread switching under a GIL, as it will be, instead, CPU-bound. In
this case, multiple processes will be more efficient, and will be able to
take better advantage of multi-core systems.&lt;&#x2F;p&gt;
&lt;p&gt;So… why not skip threads and just deal with processes? A number of
reasons.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>Today we went to the bad place…</title>
        <published>2013-11-24T00:00:00+00:00</published>
        <updated>2013-11-24T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/today-we-went-to-the-bad-place/"/>
        <id>https://www.livinginthepast.org/blog/today-we-went-to-the-bad-place/</id>
        
        <summary type="html">&lt;p&gt;You know the Bad Place. It starts with the words “How hard could it be?”
and ends with me in the shower, fully clothed under a stream of hot
water, crying. You think you’re in for a nice, quick, pleasant plane
ride, but suddenly Brian Blessed is dressed like this and waving a
pointy stick at you and you can never go home again…&lt;&#x2F;p&gt;
&lt;img src=&#x27;&#x2F;2013&#x2F;brian-blessed-is-fucking-awesome.jpg&#x27; alt=&#x27;I think this is how Brian Blessed dresses every day&#x27; &#x2F;&gt;
&lt;p&gt;This Bad Place involved the migration from Selenium running via Capybara
in Minitest to capybara-webkit running in RSpec. We have various reasons
for preferring this at my work, many of them subjective and based on the
collected positive experiences of several people working in this
codebase. We believe that the end result will make us happier in the
long run.&lt;&#x2F;p&gt;
&lt;p&gt;We’re not yet all the way to the other side, but I thought I would share
some learnings. Some of them were more obvious than others, but
hopefully others can learn from today’s strange coding journey.&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;We will run javascript specs and unit tests in the same spec runner.
The database cleaning configuration required to make this work and run
quickly is non-obvious.&lt;&#x2F;li&gt;
&lt;li&gt;Some of our testing gems have not been updated since the launch of
this project. Some gems conflict with newer versions of other testing
gems, blocking upgrade.&lt;&#x2F;li&gt;
&lt;li&gt;Some of our Selenium tests do not require Javascript execution or CSS
rendering in order to pass&lt;&#x2F;li&gt;
&lt;li&gt;Some of our Selenium tests depend on stubbing at the server&lt;&#x2F;li&gt;
&lt;li&gt;We over-use &lt;code&gt;Thing.any_instance.stub&lt;&#x2F;code&gt;&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>New Job at Wanelo</title>
        <published>2012-09-20T00:00:00+00:00</published>
        <updated>2012-09-20T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/new-job-at-wanelo/"/>
        <id>https://www.livinginthepast.org/blog/new-job-at-wanelo/</id>
        
        <summary type="html">&lt;p&gt;I have made the move. Starting Monday I&#x27;m going to be working at
&lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;wanelo.com&quot;&gt;Wanelo&lt;&#x2F;a&gt;,
a social media startup working on connecting people with e-commerce.
It&#x27;s an interesting change for me, as two years ago I promised myself I
would never work for a social network company. A lot has changed in the
last two years, however, and I thought I would take some time to put it
down in words (for my own benefit as well as yours, illustrious reader).&lt;&#x2F;p&gt;
&lt;p&gt;For the past two years I have worked at
&lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;www.modcloth.com&quot;&gt;ModCloth&lt;&#x2F;a&gt;,
an e-commerce fashion
company that works with small-medium sized fashion designers to sell
vintage-inspired clothing. In the course of my time there, I worked on
various features including Be the Buyer, a program to crowd-source
product acquisition and merchandizing. I led a team to re-architect the
product categories to be based on search indexes, not only making the
process by which new products appear on the site more automated
and robust (before, every product was manually added and sorted in
every category by hand), but allowing us to implement faceted drill-down
on almost every category—customers can easily find in-stock dresses that
are their color, size and price range. In the end, I worked on systems
automation to build new servers in an automated and quick fashion. Hopefully
I had some influence in the long term strategy of organizing code into
separate applications and services.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en-US">
        <title>New Blog</title>
        <published>2012-09-18T00:00:00+00:00</published>
        <updated>2012-09-18T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Eric Saxby
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://www.livinginthepast.org/blog/new-blog/"/>
        <id>https://www.livinginthepast.org/blog/new-blog/</id>
        
        <content type="html" xml:base="https://www.livinginthepast.org/blog/new-blog/">&lt;p&gt;Well, it&#x27;s time. While the old blog had some relevant data (at least to me),
it&#x27;s time to shuck off the old and begin with the new. As such, I&#x27;m
going to rely on the &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20110201094856&#x2F;http:&#x2F;&#x2F;ericsaxby.com&#x2F;blog&#x2F;&quot;&gt;Internet Archive&lt;&#x2F;a&gt;
to provide historical content.&lt;&#x2F;p&gt;
&lt;p&gt;The analytics of my previous blog and the random connections it would attract
were interesting, but there are a few deciding factors to guide this
along:&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;I have not updated it in about 2 1&#x2F;2 years&lt;&#x2F;li&gt;
&lt;li&gt;Most of the content is technologically dated&lt;&#x2F;li&gt;
&lt;li&gt;Since last writing, I have switched jobs twice (more on that in a
later post)&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</content>
        
    </entry>
</feed>
