<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>software on Me, thinking out loud</title>
    <link>https://blog.straughan.org/topics/software/</link>
    <description>Recent content in software on Me, thinking out loud</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-GB</language>
    <lastBuildDate>Sat, 26 Jan 2019 17:28:38 +0100</lastBuildDate>
    
	<atom:link href="https://blog.straughan.org/topics/software/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Finally catchup on ES6</title>
      <link>https://blog.straughan.org/post/finally-catch-up-on-es6/</link>
      <pubDate>Sat, 26 Jan 2019 17:28:38 +0100</pubDate>
      
      <guid>https://blog.straughan.org/post/finally-catch-up-on-es6/</guid>
      <description>&lt;h1 id=&#34;overview----omit-in-toc---&#34;&gt;Overview &lt;!-- raw HTML omitted --&gt;&lt;/h1&gt;
&lt;p&gt;I have managed to avoid most of the gnarly details of javascript beyond ES5 for many years. Unfortunately a side project has driven me to finally take it on board. These are my notes, gleaned mostly by reading &lt;a href=&#34;https://hacks.mozilla.org/category/es6-in-depth/page/2/&#34;&gt;ES6 In Depth&lt;/a&gt; from Jason Orendorff of Mozilla.&lt;/p&gt;
&lt;p&gt;I now know enough to be &lt;em&gt;more&lt;/em&gt; dangerous.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Behaviours not Errors</title>
      <link>https://blog.straughan.org/post/behaviours-not-errors/</link>
      <pubDate>Mon, 18 Sep 2017 21:53:01 +0100</pubDate>
      
      <guid>https://blog.straughan.org/post/behaviours-not-errors/</guid>
      <description>Overview Recently, I have been thinking about my preference for structured logging (details on this in to-be-written entry). A trivial but significant aspect of this, is that once you have switched to structured logging, markers like INFO, DEBUG, ERROR,&amp;hellip; don&#39;t help. Simply grouping such a wide range of code paths into these categories is insufficient for any kind of analysis.
What is an error? An error is a local failure scenario that you don&#39;t currently understand - our continuous improvement process for error handling aims to move all these anomalies in the system from unknown to known.</description>
    </item>
    
    <item>
      <title>There are Only 4 reasons to write software</title>
      <link>https://blog.straughan.org/post/4-reasons-to-write-code/</link>
      <pubDate>Tue, 23 May 2017 22:56:47 +0100</pubDate>
      
      <guid>https://blog.straughan.org/post/4-reasons-to-write-code/</guid>
      <description>&lt;h1 id=&#34;reasons-to-write-code&#34;&gt;Reasons to write code;&lt;/h1&gt;
&lt;ol&gt;
&lt;li&gt;Make money&lt;/li&gt;
&lt;li&gt;Save money&lt;/li&gt;
&lt;li&gt;Stay out of jail&lt;/li&gt;
&lt;li&gt;For fun&lt;/li&gt;
&lt;/ol&gt;</description>
    </item>
    
    <item>
      <title>It&#39;s called Software for a reason</title>
      <link>https://blog.straughan.org/post/its-called-software/</link>
      <pubDate>Tue, 02 Aug 2016 07:25:46 +0100</pubDate>
      
      <guid>https://blog.straughan.org/post/its-called-software/</guid>
      <description>&lt;h1 id=&#34;making-a-change&#34;&gt;Making a change&lt;/h1&gt;
&lt;p&gt;When making a change to an existing piece of software I think there are broadly 2 options;&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Get in and out, change as little as possible&lt;/li&gt;
&lt;li&gt;Restructure the code to fit the new requirement&lt;/li&gt;
&lt;/ol&gt;</description>
    </item>
    
  </channel>
</rss>