<?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 Adam Koszek - Personal Website</title>
    <link>https://www.koszek.com/tags/programming/</link>
    <description>Recent content in Programming on Adam Koszek - Personal Website</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>adam@koszek.com (Adam Koszek)</managingEditor>
    <webMaster>adam@koszek.com (Adam Koszek)</webMaster>
    <lastBuildDate>Sun, 04 Oct 2015 00:00:00 +0000</lastBuildDate><atom:link href="https://www.koszek.com/tags/programming/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>wget in 9 lines of Python For Hostile Environments</title>
      <link>https://www.koszek.com/blog/2015/10/04/wget-in-9-lines-of-python-for-hostile-environments/</link>
      <pubDate>Sun, 04 Oct 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/10/04/wget-in-9-lines-of-python-for-hostile-environments/</guid>
      <description>&lt;p&gt;HTTPS seems to be everywhere these days, including GitHub. It’s great to
see the security of the Web improved, but sometimes this comes at a
cost. Recently I wanted to actually fetch and test my own repository for
bootstrapping my storage box from Synology:&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/wkoszek/synology&#34;&gt;https://github.com/wkoszek/synology&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;The DS214play model which I have comes with the &lt;code&gt;wget&lt;/code&gt; program without
HTTPS, so doing a command line bootstrapping is difficult. This is one
of this weird chicken-and-egg problems we sometimes experience, and to
test my software releases published on GitHub, I wrote this simple
thing, which lets me fetch the release and do further bootstrapping and
testing:&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Do You Have a Favorite Shell Trick?</title>
      <link>https://www.koszek.com/blog/2015/09/28/do-you-have-a-favorite-shell-trick/</link>
      <pubDate>Mon, 28 Sep 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/09/28/do-you-have-a-favorite-shell-trick/</guid>
      <description>&lt;p&gt;The very first scripting programming language I learned was Perl. It was
circa 2000; Python wasn’t that popular back then, and my choice leaned
towards Perl since I could get a decent books about it in Polish. I
remember squeezing $20 and getting something that seemed like &lt;a href=&#34;https://amzn.to/1VhXyEb&#34;&gt;the
thickest book ever&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Several years later I came back to Perl because Xilinx was using it too,
and since then I’ve had the chance to come back and polish some of my
Perl chops. We had a very nice build system written in Perl which let
you check out files selectively. You would check out a file to a clean
directory, hit “build”, and it’d build a project for you from vanilla
sources. Then you’d check out a file you wanted to modify and keep
hacking on it. Next you’d hit “build” again, but this time the system
would use the modified file instead of the plain file from the
repository. All the junk files from C and Verilog compiler would be put
in the obj/ directory for you, so you never had to see them. I liked it,
since my workspace was really neat and tidy (two to three source code
files plus some log files).&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>(Probably) the single biggest collection of Ruby scripts</title>
      <link>https://www.koszek.com/blog/2015/09/01/the-single-biggest-collection-of-ruby-scripts/</link>
      <pubDate>Tue, 01 Sep 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/09/01/the-single-biggest-collection-of-ruby-scripts/</guid>
      <description>&lt;h2 id=&#34;quickstart&#34;&gt;Quickstart&lt;/h2&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/wkoszek/book-programming-ruby&#34;&gt;https://github.com/wkoszek/book-programming-ruby&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;explanation&#34;&gt;Explanation&lt;/h2&gt;
&lt;p&gt;To evaluate the feasibility of different Ruby interpreters I wanted to
investigate how any of Ruby 1.8, 1.9, 2.x and Rubinius will deal with
subsets of scripts fed to them. I did it because I&amp;rsquo;ve noticed
&lt;a href=&#34;https://github.com/rubinius/rubinius/issues/3456&#34;&gt;regressions with Rubinius&lt;/a&gt;
in the past, and I wanted to understand whether this situation is similar for a
larger code base and basically how serious these issues are.&lt;/p&gt;
&lt;p&gt;On the separate now, for learning Ruby I used couple of books, and one of
them was:&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>I wish Ruby and Python stopped changing so much</title>
      <link>https://www.koszek.com/blog/2015/08/17/i-wish-ruby-and-python-stopped-changing-so-much/</link>
      <pubDate>Mon, 17 Aug 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/08/17/i-wish-ruby-and-python-stopped-changing-so-much/</guid>
      <description>&lt;p&gt;In &lt;a href=&#34;https://www.koszek.com/blog/2015/07/22/why-the-go-wont-be-successful/&#34;&gt;my article on Go&lt;/a&gt;,
I expressed my frustration on trying to make
&lt;a href=&#34;https://github.com/prasmussen/gdrive&#34;&gt;&lt;em&gt;gdrive&lt;/em&gt;&lt;/a&gt; work in no time.
Unfortunately, I failed to do so in a predicted time back then. Many users
commented on wrong title and problems with the content.
While I still believe tools that just
don’t work are likely to drive users away, I must say that one of the
reader’s comments on my article expressed a point of view, which I can
identify with:&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Command Line Interface to GoDaddy.com</title>
      <link>https://www.koszek.com/blog/2015/08/03/command-line-interface-to-godaddy/</link>
      <pubDate>Mon, 03 Aug 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/08/03/command-line-interface-to-godaddy/</guid>
      <description>&lt;p&gt;For quite some time now I’ve been a user of
&lt;a href=&#34;https://www.godaddy.com/&#34;&gt;&lt;em&gt;GoDaddy&lt;/em&gt;&lt;/a&gt;. I remember my frustration with
&lt;a href=&#34;https://www.nazwa.pl/&#34;&gt;&lt;em&gt;the Polish registrar&lt;/em&gt;&lt;/a&gt; holding some of my
&lt;code&gt;.pl&lt;/code&gt; domains: their user interface was terrible, since after logging
to your account all you could see was an advertisement:&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;2015-08-03-command-line-interface-to-godaddy/image01.jpg&#34; alt=&#34;&#34;&gt;&lt;/p&gt;
&lt;p&gt;The website with an ad always loaded very quickly. Then you had to
switch to “Control Panel”, which was always very slow. I could complain
more about the amount of time I have spent trying to do basic things
there, but I’ll leave it as a topic for &lt;a href=&#34;https://www.barelyusable.com&#34;&gt;&lt;em&gt;my usability
website&lt;/em&gt;&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Why the Go Language Won&#39;t Be Successful</title>
      <link>https://www.koszek.com/blog/2015/07/22/why-the-go-wont-be-successful/</link>
      <pubDate>Wed, 22 Jul 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/07/22/why-the-go-wont-be-successful/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;Since I wrote this post two years ago, I changed my mind:
Go is OK.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;The other day I stumbled upon a &lt;a href=&#34;https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fprasmussen%2Fgdrive&amp;amp;sa=D&amp;amp;sntz=1&amp;amp;usg=AFQjCNGAiYDSR3UBgK6bT9wAoUSUPQrd-A&#34;&gt;Google Drive command line client&lt;/a&gt;. It’s a software project written in the Go language. It lets you access Google Drive from the command line. I felt it was a great project, and I wanted to give it a shot, so I started reading. Unfortunately, the program is distributed in binary form, and given several problems that GitHub has had over the past 2 years or so, I’d rather not run binaries from GitHub on my machine. Makes sense, right?&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Source Code from &#34;Programmer Guide to NCurses&#34; by Dan Gookin</title>
      <link>https://www.koszek.com/blog/2015/07/08/programmers-guide-to-ncurses/</link>
      <pubDate>Wed, 08 Jul 2015 00:00:00 +0000</pubDate>
      <author>adam@koszek.com (Adam Koszek)</author>
      <guid>https://www.koszek.com/blog/2015/07/08/programmers-guide-to-ncurses/</guid>
      <description>&lt;p&gt;Even though I&amp;rsquo;ve never read Gookin&amp;rsquo;s book, I&amp;rsquo;ve noticed that his website
tarball with C sources is quite useful, as it contains small self-contained
programs. To the sources I&amp;rsquo;ve added a &lt;code&gt;makefile&lt;/code&gt; to make build automated and
I&amp;rsquo;ve fixed programs which weren&amp;rsquo;t compiling.&lt;/p&gt;
&lt;h2 id=&#34;dependencies&#34;&gt;Dependencies&lt;/h2&gt;
&lt;p&gt;For MacOSX I didn&amp;rsquo;t need anything. For Ubuntu you&amp;rsquo;ll probably have to type:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-terminal&#34; data-lang=&#34;terminal&#34;&gt;apt-get install libncurses5-dev libncurses5
&lt;/code&gt;&lt;/pre&gt;&lt;h2 id=&#34;how-to-build&#34;&gt;How to build?&lt;/h2&gt;
&lt;p&gt;Fetch the source, enter its folder and type make:&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
