Merge pull request #136 from justwriteclick/build

Remove t-shirt links, fix broken links; update content as needed

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:

_data/navigation.yml

@@ -14,6 +14,3 @@
 
 - title: Search
   url: /search/
-
-- title: T-shirt
-  url: https://just-write-click.myshopify.com/

_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/)

_learn/06-test-docs-as-code.md

@@ -146,5 +146,4 @@ Look for more inspiration beyond link checking in the additional resources secti
 * [Test the Docs](https://testthedocs.org/)
 * Pantheon docs examples
   * [Merge conflict test](https://github.com/pantheon-systems/documentation/blob/master/scripts/merge_conflicts.sh)
-  * [CircleCI example configuration](https://github.com/pantheon-systems/documentation/blob/master/circle.yml)
-* [How we spotted--and fixed--11 errors in our docs with our new markdown proofer](https://circleci.com/blog/markdown-proofer/)
+  * [How we spotted--and fixed--11 errors in our docs with our new markdown proofer](https://circleci.com/blog/markdown-proofer/)

_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)