Update http to https where available in links; add link checker

Author: annegentle

Gemfile

@@ -1,4 +1,4 @@
 source "https://rubygems.org"
 
 gem "jekyll-theme-so-simple"
-
+gem "html-proofer"

Gemfile.lock

@@ -9,10 +9,13 @@ GEM
     addressable (2.5.2)
       public_suffix (>= 2.0.2, < 4.0)
     colorator (1.1.0)
+    colorize (0.8.1)
     concurrent-ruby (1.1.4)
     em-websocket (0.5.1)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0.6.0)
+    ethon (0.12.0)
+      ffi (>= 1.3.0)
     eventmachine (1.2.7)
     faraday (0.15.4)
       multipart-post (>= 1.2, < 3)
@@ -22,6 +25,15 @@ GEM
     html-pipeline (2.10.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
+    html-proofer (3.10.2)
+      activesupport (>= 4.2, < 6.0)
+      addressable (~> 2.3)
+      colorize (~> 0.8)
+      mercenary (~> 0.3.2)
+      nokogiri (~> 1.9)
+      parallel (~> 1.3)
+      typhoeus (~> 1.3)
+      yell (~> 2.0)
     http_parser.rb (0.6.0)
     i18n (0.9.5)
       concurrent-ruby (~> 1.0)
@@ -80,6 +92,7 @@ GEM
       mini_portile2 (~> 2.4.0)
     octokit (4.13.0)
       sawyer (~> 0.8.0, >= 0.5.3)
+    parallel (1.17.0)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.0.3)
@@ -98,14 +111,18 @@ GEM
       addressable (>= 2.3.5, < 2.6)
       faraday (~> 0.8, < 1.0)
     thread_safe (0.3.6)
+    typhoeus (1.3.1)
+      ethon (>= 0.9.0)
     tzinfo (1.2.5)
       thread_safe (~> 0.1)
+    yell (2.1.0)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
+  html-proofer
   jekyll-theme-so-simple
 
 BUNDLED WITH
-   1.16.3
+   2.0.1

_data/authors.yml

@@ -16,7 +16,7 @@ jennifer_rondeau:
 
 leon_barnard:
   name: Leon Barnard
-  picture: https://pbs.twimg.com/profile_images/855131146195042304/isNkZpYS.jpg
+  picture: https://media.balsamiq.com/img/company/team/2017/bio/leon.jpg
   github: //github.com/balsamiqLeon
   twitter: leonbarnard
   bio: "Designer and Writer"
@@ -46,7 +46,7 @@ tom_johnson:
   name: Tom Johnson
   picture: https://docslikecode.com/images/tom-johnson.jpg
   github: //github.com/tomjoht
-  twitter: http://twitter.com/tomjohnson
+  twitter: https://twitter.com/tomjohnson
   bio: "Technical Writer"
 
 ben_mansheim:

_learn/01-sphinx-python-rtd.md

@@ -172,5 +172,5 @@ You can also get familiar with [ReStructured text](http://docutils.sourceforge.n
 
 ## Additional references
 
-* [Sphinx Python Documentation Generator](http://www.sphinx-doc.org/en/stable/)
+* [Sphinx Python Documentation Generator](https://www.sphinx-doc.org/en/stable/)
 * [ReStructured text documentation](http://docutils.sourceforge.net/rst.html)

_learn/02-jekyll-ruby-gh-pages.md

@@ -7,7 +7,7 @@ image:
   caption: "Screenshot using Minimal Mistakes theme"
 ---
 
-Jekyll is a Static Site Generator that typically accepts [Markdown](http://commonmark.org/help/) for authoring. [Jekyll](https://jekyllrb.com/) has its own documentation site and a [Quickstart](https://jekyllrb.com/docs/). To prepare your environment to build Jekyll sites locally, follow the instructions for either Windows or MacOS.
+Jekyll is a Static Site Generator that typically accepts [Markdown](https://commonmark.org/help/) for authoring. [Jekyll](https://jekyllrb.com/) has its own documentation site and a [Quickstart](https://jekyllrb.com/docs/). To prepare your environment to build Jekyll sites locally, follow the instructions for either Windows or MacOS.
 
 ## Set up Ruby and Jekyll on Windows with Docker
 
@@ -193,7 +193,7 @@ Once you've prepared your environment, you can build locally and review the site
 
 ## Additional references
 
-* [Markdown reference](http://commonmark.org/help/)
+* [Markdown reference](https://commonmark.org/help/)
 * [Documentation Theme for Jekyll](https://idratherbewriting.com/documentation-theme-jekyll/)
 * [Lynda.com Web foundations, GitHub Pages](https://www.lynda.com/Web-Development-tutorials/GitHub-pages/609031/654613-4.html)
 * [Jekyll documentation about GitHub Pages](https://jekyllrb.com/docs/github-pages/)

_posts/00-github-for-docs-files.md

@@ -108,7 +108,7 @@ The terms sound confusing at first. Here's a list of vocabulary words to help yo
   <dt>push</dt>
   <dd>
     <p>
-      Move your local committed changes to a remote location, such as <a href="http://www.github.com">GitHub.com</a>, so that other people can access them.
+      Move your local committed changes to a remote location, such as <a href="https://www.github.com">GitHub.com</a>, so that other people can access them.
     </p>
   </dd>
   <dt>remote</dt>

_posts/articles/2017-03-18-pantheon-case-study.md

@@ -61,7 +61,7 @@ It depends. We migrated a lot of content because it didn’t make sense to start
 
 Pantheon uses CircleCI for continuous integration which builds all commits pushed to GitHub then tests and deploys changes to either a staging environment or to production. Deployments to production occur via rsync after tests have run successfully. If any test fails (broken link, performance regression, etc.) The build will fail on CircleCI and the deployment to production is skipped until a passing build occurs. Branches other than our default branch get deployed to isolated cloud development environments for staging with unique and publicly accessible URLs. Deployments to staging environments happen before the test suite is run to help debug issues and/or failures. Once builds have been deployed to a staging environment, a comment is created on the commit in GitHub with a link to the changes for quick and easy peer review. Once a feature branch has been merged into the default, the associated staging environment is automatically deleted along with the branch. The automation procedures are scripted in Bash and configured in the `circle.yml` file within the project’s root directory. The staging environments are created using Pantheon’s command line tool, [Terminus](https://pantheon.io/docs/terminus/), and our [Multidev](https://pantheon.io/features/multidev-cloud-environments) feature.
 
-This workflow is not available to forks for security reasons. For details, see CircleCI’s documentation: [Security Implications of Running Builds for Pull Requests from Forks](https://circleci.com/docs/fork-pr-builds/#security-implications-of-running-builds-for-pull-requests-from-forks).
+As of March 2017, this workflow was not available to forks for security reasons. As of May 2019, [CircleCI’s documentation](https://circleci.com/docs/2.0/gh-bb-integration/) indicates there's a setting for PRs created from forked repos.
 
 #### Are there any questions you wish you had asked before using GitHub for docs?
 

_posts/articles/2017-04-04-balsamiq-case-study-part-1.md

@@ -23,11 +23,11 @@ The three parts cover documenting multiple product versions, [adding play and pa
 
 ## Background
 
-A year and a half ago [we ditched our flaky content management system](https://blog.balsamiq.com/new-documentation-site/) and converted our documentation site over to a "docs like code" system using [Hugo](http://gohugo.io/), [Gulp](http://gulpjs.com/), and [GitHub](https://github.com/), with content written in Markdown. It was a long process and we were happy just to see it up and running.
+A year and a half ago [we ditched our flaky content management system](https://blog.balsamiq.com/new-documentation-site/) and converted our documentation site over to a "docs like code" system using [Hugo](https://gohugo.io/), [Gulp](https://gulpjs.com/), and [GitHub](https://github.com/), with content written in Markdown. It was a long process and we were happy just to see it up and running.
 
 After the dust settled, we started imagining what we wanted for the next version, and realized that the system we had built had limitations that we would have to overcome. This is a story of three challenges and how we solved them.
 
-***Note:*** *The code in this article is specific to [Hugo](http://gohugo.io/), the static site generator we use, but should be adaptable to other static site generators.*
+***Note:*** *The code in this article is specific to [Hugo](https://gohugo.io/), the static site generator we use, but should be adaptable to other static site generators.*
 
 ## Challenge #1: Documenting multiple product versions
 
@@ -41,7 +41,7 @@ The majority of our documentation is how to use one of the two core wireframe ed
 
 For historical reasons, most of the common documentation is in the Desktop version docs. If you used our product on a different platform, you had to know to go to the Desktop docs.
 
-This is what the content folder in our [GitHub repo](https://github.com/balsamiq/docs.balsamiq.com) looked like, which meant that a lot of customers had this experience:
+This is what the content folder in our GitHub repo looked like, which meant that a lot of customers had this experience:
 
 ![Concept confusion]({{ site.url }}/images/balsamiq/structure2.png)
 

_posts/articles/2017-04-09-balsamiq-case-study-part-2.md

@@ -19,7 +19,7 @@ After learning about [documenting multiple product versions with a static site g
 
 ## Background
 
-[Balsamiq set up a new documentation site](https://blog.balsamiq.com/new-documentation-site/) about a year and a half ago. We converted our old, flaky documentation system over to a "docs like code" system using [Hugo](http://gohugo.io/), [Gulp](http://gulpjs.com/), and [GitHub](https://github.com/), with content written in Markdown. The conversion took a while, so in the end we were pleased simply to get working.
+[Balsamiq set up a new documentation site](https://blog.balsamiq.com/new-documentation-site/) about a year and a half ago. We converted our old, flaky documentation system over to a "docs like code" system using [Hugo](https://gohugo.io/), [Gulp](https://gulpjs.com/), and [GitHub](https://github.com/), with content written in Markdown. The conversion took a while, so in the end we were pleased simply to get working.
 
 Once it was part of our daily workflow, and we could begin to look to the future, we started envisioning the next version. In doing so, we recognized the limitations and looked for solutions that kept writers writing and readers reading. This series tells the tale of three of these problem areas and how we solved the challenges.
 

_posts/articles/2017-06-05-free-open-source-api-doc-tools.md

@@ -121,7 +121,7 @@ Besides the ones detailed above, there are plenty of different open source API d
 -   [Slate](https://github.com/lord/slate): Slate helps you create responsive API documentation with a clean, intuitive design. Although it’s built in Ruby, when you write docs with Slate, you're just writing Markdown, which makes it simple to edit and understand. By default, your Slate-generated documentation is hosted in a public Github repository, which makes it simple for other developers to make pull requests to your docs if they find typos or other problems. Of course, if you don't want to use GitHub, you can also host your docs elsewhere.
 -   [Whiteboard](https://github.com/mpociot/whiteboard): A NodeJS based project started from Slate.
 -   [apiDoc](http://apidocjs.com/): Inline documentation for RESTful web APIs, that creates a documentation from API annotations in your source code.
--   [CUUBEZ API Visualizer](http://apivisualizer.cuubez.com/): Java based API solution to visualize the documentation of RESTful web APIs. This API visualizing framework supports all JAXRS based java REST frameworks and non-JAXRS java based REST frameworks that are currently available in the industry.
+-   [CUUBEZ API Visualizer](https://github.com/cuubez/api-visualizer): Java based API solution to visualize the documentation of RESTful web APIs. This API visualizing framework supports all JAXRS based java REST frameworks and non-JAXRS java based REST frameworks that are currently available in the industry.
 -   [Apidox](http://apidox.net/): XML powered live interactive API documentation and browsing for RESTful APIs.
 -   [Carte](https://github.com/Wiredcraft/carte): A simple Jekyll based documentation website for APIs. Designed as a boilerplate to build your own documentation, heavily inspired by Swagger and I/O docs.
 -   [Docbox](https://github.com/tmcw/docbox): A responsive website generated from Markdown documentation content. It’s dynamically updated with React.
@@ -137,9 +137,11 @@ Although very handy, API documentation generators are not the only way to render
 
 A couple of documentation tools you can check out:
 
+<!-- No longer available as of May 2019.
 -   [Dexy](http://www.dexy.it/): Dexy is a multi-purpose project automation tool with lots of features designed to work with documents. It does the repetitive parts for you, and thus makes it easier to create technical documents. Many developers use it to document APIs, because combined with other open source tools, Dexy is able to run your example code, save the results, fetch data from an API, and post your docs to a blog or a wiki.
+-->
 -   [Docco](https://jashkenas.github.io/docco/): Docco is a quick-and-dirty documentation generator. It produces an HTML document that displays your comments intermingled with your code.
--   [Doxygen](http://www.stack.nl/~dimitri/doxygen/): Doxygen is the de facto standard tool for generating documentation from annotated C++ sources, but it also supports other popular programming languages such as C, Objective-C, C\#, PHP, Java, Python, IDL, Fortran, VHDL, Tcl, and to some extent D. To document your API, generate an online HTML documentation browser or an offline reference manual, and configure Doxygen to extract the code structure from your source files.
+-   [Doxygen](http://doxygen.nl/): Doxygen is the de facto standard tool for generating documentation from annotated C++ sources, but it also supports other popular programming languages such as C, Objective-C, C\#, PHP, Java, Python, IDL, Fortran, VHDL, Tcl, and to some extent D. To document your API, generate an online HTML documentation browser or an offline reference manual, and configure Doxygen to extract the code structure from your source files.
 
 We mentioned these tools to give you an idea of how you can use general documentation tools for API documentation, but there are many more to choose from, if you’d like to follow this approach.
 
@@ -241,7 +243,7 @@ Markdown (Ruby)</td>
 <td>Whiteboard</td>
 <td>NodeJS based Slate alternative</td>
 <td>NodeJS</td>
-<td><a href="https://wifidistribution.com/docs/">Whiteboard demo</a></td>
+<td>Whiteboard demo was from wifidistribution.com/docs, no longer available as of May 2019</td>
 </tr>
 <tr class="odd">
 <td>apiDoc</td>
@@ -253,7 +255,7 @@ Markdown (Ruby)</td>
 <td>CuuBEZ API Visualizer</td>
 <td>Visualize the documentation of RESTful web APIs</td>
 <td>Java</td>
-<td><a href="http://apivisualizerold.cuubez.com/demo.html">CuuBEZ API Visualizer demo</a></td>
+<td><a href="https://github.com/cuubez/api-visualizer">CuuBEZ API Visualizer repo</a></td>
 </tr>
 <tr class="odd">
 <td>Apidox</td>