Perl as a 2nd language: Modules

This is part 2 of a series on Perl, intended for experienced software developers.

Re-learning Perl has not been easy.

Perl as a second language: Step 1

Why 2nd languages? With hello world, and readme.pl

I want to help other people kickstart new programming languages. As an experienced developer, you already what a loop is, or any other common feature: you just want to make it work. The goal of my “second language” posts is to provide that level of help.

Your Next Language

I have been re-learning Perl, for a maintenance project at work. If you don’t have a specific task like that, have more fun while learning, with something like a “joke” program that uses the Fibonacci series to display a list of all the characters Lady Gaga has played in her videos. Or the names of Rebecca Black’s songs. Or maybe something interesting instead.

Obvious

Good place to start. Lady Black deserves the best:

To buy “The Grand Tour”, look for “Amazon Prime”

We got a one-year subscription to two season’s of “The Grand Tour”, you know, the new version of “Top Gear” after the team left BBC?

Python as a Second Language

I am presenting a programming workshop at the Ottawa Python Authors Group meeting, 7:30pm, July 27, 2017, at Survey Monkey, 12 York Street, 3rd floor. More info:

• Meeting info on Meetup.com

From Build Engineering to DevOps

Executive Summary

This document is for Build Engineers, DevOps Developers, and the people who hire them: Software Development Manager, VP Software Development, Director of Software Development. The goal of this document is to show how to improve a software environment using modern tools, such as those used in a DevOps environment.

First is a description of Build Engineering, next, how Build Engineering can be modernized with today’s tools and processes, then a discussion of how DevOps relates to a modern Build Engineering system.

The conclusion is that much of DevOps tools and processes are required by modern Build Engineering and can be used to improve any software development environment.

Password security officially becomes easier

The NIST* has modernized the password rules for US Government Department, specifically the “minimum requirements for federal information systems”. This is supposedly where every IT department gets their rules from, so maybe these better rules will be used, “soonish”, in bank machines and corporate workplaces.
– (Yeah, I said “soonish”. In this case, “soonish=”probably years from now”.)

What the NIST said:

I will summarize and link to the parts of the draft Guidelines that make passwords easier.

“Draft NIST Special Publication, 800-63B – Digital Identity Guidelines”:

• Section 5, Authenticator and Verifier Requirements
  • Section 5.1.1.1 – Don’t make the password artificially hard to remember by requiring “complexity rules”: UPPER, lower, numeric, special characters. (Rationale in Appendix A)
• Appendix A, Strength of Memorized Secrets
  • Why complex passwords are bad: “analyses of breached password databases reveals that the benefit of such [complexity] rules is not nearly as significant as initially thought, although the impact on usability and memorability is severe.”
  • Services should disallow passwords found in a list of commonly used passwords, such as “Password1!”, and “123456”.

For a longer explanation, see Slava Gomzin’s article on Venture Beat.

*  NIST = National Institute of Standards and Technology – part of the U. S. Dept. of Commerce)