<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Programming on A Nickel&#39;s Worth</title>
    <link>/tags/programming/</link>
    <description>Recent content in Programming on A Nickel&#39;s Worth</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Fri, 20 Dec 2019 00:00:00 +0000</lastBuildDate>
    <atom:link href="/tags/programming/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Avoiding fallback in distributed systems</title>
      <link>/posts/avoiding-fallback-in-distributed-systems/</link>
      <pubDate>Fri, 20 Dec 2019 00:00:00 +0000</pubDate>
      <guid>/posts/avoiding-fallback-in-distributed-systems/</guid>
      <description>As previously mentioned, I was recently able to contribute to the Amazon Builders&amp;rsquo; Library. I&amp;rsquo;d also like to share another post that I wrote for the series, entitled Avoiding fallback in distributed systems. I&amp;rsquo;m especially excited to be able to publish it, as it&amp;rsquo;s based on an internal Amazon document I wrote in 2006 entitled Modes Considered Harmful. It provoked a lot of interesting discussions over the years, so I&amp;rsquo;m happy to be able to share a (hopefully slightly better written) version of it publicly.</description>
    </item>
    <item>
      <title>Challenges with distributed systems</title>
      <link>/posts/challenges-with-distributed-systems/</link>
      <pubDate>Fri, 20 Dec 2019 00:00:00 +0000</pubDate>
      <guid>/posts/challenges-with-distributed-systems/</guid>
      <description>I was recently invited to contribute to the Amazon Builders&amp;rsquo; Library. One article I&amp;rsquo;d been wanting to publish publicly is about how bizarre distributed systems are, and what&amp;rsquo;s been the biggest challenge building them, in my experience.&#xA;Please check out the article and here&amp;rsquo;s a quick abstract:&#xA;Developing distributed utility computing services, such as reliable long-distance telephone networks, or Amazon Web Services (AWS) services, is hard. Distributed computing is also weirder and less intuitive than other forms of computing because of two interrelated problems.</description>
    </item>
    <item>
      <title>Six Audacious Goals for Your System</title>
      <link>/posts/six-audacious-goals-for-your-system/</link>
      <pubDate>Tue, 28 Apr 2009 00:00:00 +0000</pubDate>
      <guid>/posts/six-audacious-goals-for-your-system/</guid>
      <description>With apologies to the authors of the futurist programming notes, here is a set of audacious goals for your system (by which I mean your collection of web sites, webservices, databases, and so on):&#xA;Make your entire system runnable (for debugging/development) on a single machine, via a single command, &amp;hellip;without manual configuration, &amp;hellip;without an Internet connection. Demonstrate that your system works flawlessly even when you permanently and unexpectedly unplug the power cable from any one machine (even your most precious database).</description>
    </item>
    <item>
      <title>Ulrich Drepper&#39;s Memory Paper and CL</title>
      <link>/posts/ulrich-dreppers-memory-paper-and-cl/</link>
      <pubDate>Thu, 22 May 2008 00:00:00 +0000</pubDate>
      <guid>/posts/ulrich-dreppers-memory-paper-and-cl/</guid>
      <description>I recently came across Ulrich Drepper&amp;rsquo;s excellent paper, What Every Programmer Should Know About Memory. There is a lot of fascinating stuff in there about an important class of things you sometimes need to do to achieve excellent performance. While the paper concentrates on C, I was wondering if some of the same effects could be observed in a high-level language like CL (for the record, I think CL is both high- and low-level, but whatever&amp;hellip;) I did a quick experiment which suggests that at least one of Ulrich&amp;rsquo;s optimizations works in CL.</description>
    </item>
    <item>
      <title>The Icarus Ultimatum</title>
      <link>/posts/the-icarus-ultimatum/</link>
      <pubDate>Sun, 02 Sep 2007 00:00:00 +0000</pubDate>
      <guid>/posts/the-icarus-ultimatum/</guid>
      <description>It is unlikely that every programmer is familiar with Icarus, but I bet that almost all programmers have something in common with him. Programmers are saturated with advice not to do things, similar to the advice Icarus&amp;rsquo; dad gave him about aviation. Don&amp;rsquo;t use threads unless you really know what you&amp;rsquo;re doing (and then don&amp;rsquo;t use them anyway.) Don&amp;rsquo;t use new language features (they&amp;rsquo;re too dangerous.) Use the &amp;ldquo;right tool for the right job&amp;rdquo; (i.</description>
    </item>
    <item>
      <title>Proactive Optimization</title>
      <link>/posts/proactive-optimization/</link>
      <pubDate>Sat, 25 Aug 2007 00:00:00 +0000</pubDate>
      <guid>/posts/proactive-optimization/</guid>
      <description>In the programming world, one of the most widely repeated maxims is, &amp;ldquo;Premature optimization is the root of all evil.&amp;rdquo; Having found this to be one of the most well-intended yet misunderstood pieces of advice in the history of the Universe, I was all set to write a blog about why. Unfortunately, for me, a quick trip to Wikipedia led me to this article: The Fallacy of Premature Optimization, by Randall Hyde, which said everything I intended to say, and more, and did so more eloquently that I could ever hoped to have (although I might have put in some better jokes).</description>
    </item>
  </channel>
</rss>
