Newsletter # 28 - Understanding the Swift Argument Parser and working with STDIN Jul 8 2020

Hello, and welcome to issue #28!

I've been working with computers for most of my life, and especially on *nix systems. It always surprises me how much there is to learn. It's always interesting to read about the history of some part of the OS that you thought you understood, and learn something new. That happened when I was reading the following article:

Tales From a Core File - Lessons from the Unix stdio ABI: 40 Years Later

There is a lot to take from that short post. But what I took to heart, is that building software that will be useful for years requires a lot of thought and care. The post is a little bit technical, but not so much that it becomes unintelligible. It talks about some tradeoffs taken on the design and implementation of the stdio (or Standard Input Output) library during its 40+ years of history. Have a look and let me know what you think.

In other news, something that didn't pass the test of time was the SHA-1 algorithm. Open SSH is finally dropping support for authenticating using an SHA-1 encrypted keys. So if you still have any SHA-1 keys, it is time to replace them. You can check an article here talking about it:

 OpenSSH to deprecate SHA-1 logins due to security risk - ZDNet

That was a public service of sorts, for people maintaining legacy systems. Which you know I'm fond of.

This week I have two podcast recommendations for you. I hope you like them.

First, this episode of the Software Engineering Radio talks about the methodology for building software as a service known as the twelve-factor App. If you are a developer, an operations engineer, or a project manager that works with software as a service, you might find it useful. There are many insightful points in the methodology. If you want to read the methodology instead of listening to the podcast here is the link:

https://12factor.net

But if you want to listen to the podcast episode here is the link to it:

SE Radio - Episode 409 - Joe Kutner on the Twelve-Factor App 

And the last recommendation of the week. It's a security podcast that I've been enjoying a lot lately. The episodes are short and feel like having a conversation with friends. I especially enjoyed the latest episode where they discuss some of Apple's security features. Here is the link to the newest episode:

Open Security Podcast - Episode 204 - What Would Apple Do?

Ok, I hope you enjoy the recommendations.

This week I posted an article discussing the new Swift Argument Parser open-sourced by Apple. As you know, I love the command-line, and I enjoy writing about building tools and applications for the command-line. I've written how to use other argument parsers before, but I think the Swift Argument Parser is my favourite. If you are interested here is the link to the latest post:

 Understanding the Swift Argument Parser and working with STDIN 

And if you would like to compare to other argument parsers, you might want to read the other posts I've written about building command-line tools:

Ok, that's it for this edition of the newsletter. If you find it useful, please share :).

Have a great rest of your week.

Derik

Tip of the week

Have you ever needed to create a temporary file or directory, and you didn't want to think about the name. Well, mktemp(1) comes to the rescue. This utility allows us to create files or directories with random unique names.

By default, it places the generated file or directory in the directory defined in the environment variable TMPDIR. In my case, it points to:

1
TMPDIR=/var/folders/0v/yd26b_nd1ls9wtn8t8tqx36r0770gn/T/

If you want to generate a name, you pass X for each character you want in the name. For example, to create a file with a four random character name on my Desktop, I'll use the following command:

1
$ mktemp ~/Desktop/XXXX

And I got:

1
~/Desktop/FbPt

Read the man page. You'll find something useful there.


** If you want to check what else I'm currently doing be sure to follow me on twitter @rderik or subscribe to the newsletter. If you want to send me a direct message you can send it to derik@rderik.com.