Update notes for 2017-02-20

content/post/2017-02.md

@@ -175,3 +175,16 @@ dspace=# update metadatavalue set text_value = regexp_replace(text_value, 'http:
 - Fix label of CCAFS subjects in Atmire Listings and Reports module
 - Help Sisay with SQL commands
 - Help Paola from CCAFS with the Atmire Listings and Reports module
+- Testing the `fix-metadata-values.py` script on macOS and it seems like we don't need to use `.encode('utf-8')` anymore when printing strings to the screen
+- It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string "Entwicklung & Ländlicher Raum" without the `encode()` call, but print it as a bytes when it *is* used:
+
+```
+$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+```
+
+- So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really *was* a temporary problem, perhaps due to macOS or the Python build I was using.

public/2017-02/index.html

@@ -92,7 +92,7 @@ Looks like we’ll be using cg.identifier.ccafsprojectpii as the field name
   
   "headline": "February, 2017",
   "url": "https://alanorth.github.io/cgspace-notes/2017-02/",
-  "wordCount": "1211",
+  "wordCount": "1347",
   
   
   "datePublished": "2017-02-07T07:04:52-08:00",
@@ -371,6 +371,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/agro
 <li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
 <li>Help Sisay with SQL commands</li>
 <li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don&rsquo;t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string &ldquo;Entwicklung &amp; Ländlicher Raum&rdquo; without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+&gt;&gt;&gt; print('Entwicklung &amp; Ländlicher Raum')
+Entwicklung &amp; Ländlicher Raum
+&gt;&gt;&gt; print('Entwicklung &amp; Ländlicher Raum'.encode())
+b'Entwicklung &amp; L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
 </ul>
 
   

public/index.xml

@@ -219,6 +219,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/
 <li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
 <li>Help Sisay with SQL commands</li>
 <li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don’t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
 &lt;/ul&gt;</description>
     </item>
     

public/post/index.xml

@@ -219,6 +219,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/
 <li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
 <li>Help Sisay with SQL commands</li>
 <li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don’t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
 &lt;/ul&gt;</description>
     </item>
     

public/tags/notes/index.xml

@@ -218,6 +218,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/
 <li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
 <li>Help Sisay with SQL commands</li>
 <li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don’t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
 &lt;/ul&gt;</description>
     </item>