trackler 2.2.1.86 → 2.2.1.87

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: ed4856a33354550c10dd3f5a784ad737040f67ae
-  data.tar.gz: 8f2cfa2607feca51f6966295583dd16c0de358d2
+  metadata.gz: e9831edbe740fe63ce68b6941ca2287b894679f2
+  data.tar.gz: f83171332fb232afefcf15ad51664fbf96e22dfd
 SHA512:
-  metadata.gz: 69c3e3e3ab293cd4aa6633a183fc7627e7577cb679848e662acc4ada1fadaa2b74a73516e86cba35813e02e57ea84aa563095fce8fefc910c9cb7a94f98fa399
-  data.tar.gz: 59a594afa02d044bfc351325fe106fd7895a96f551d6e7223005665db42927189164563fdd56b4fd5499b6beed1c13a34f885edb254b04b11f0e2158d8f90b96
+  metadata.gz: 7ffc257c14ace22234f3c4701c993a3c78a46f298e3a9044fd0e2535f0a667ac1e20251e9433e5470bd6c2ce0d808ecbb4baf51806e94e6e1d99e8f0d738c7e7
+  data.tar.gz: 44e076dcdb1bba7f3b13e5627942efac6225ced9ed4d7b4d204900ec0fb2f2ee646926727d96a5fcc78fd131a20fad7e81bbb5a86c0de8f6ff0d4d705e34f333

data/lib/trackler/version.rb

@@ -1,3 +1,3 @@
 module Trackler
-  VERSION = "2.2.1.86"
+  VERSION = "2.2.1.87"
 end

data/problem-specifications/exercises/reverse-string/metadata.yml

@@ -1,5 +1,4 @@
 ---
 blurb: "Reverse a string"
-title: "reverse-string"
 source: "Introductory challenge to reverse an input string"
 source_url: "https://medium.freecodecamp.org/how-to-reverse-a-string-in-javascript-in-3-different-ways-75e4763c68cb"

data/tracks/bash/CONTRIBUTING.md

@@ -1,18 +1,39 @@
 # Contributing to the Bash Track
 
-There are a lot of great resources for contributing to Exercism in general already.  Check out the [docs](https://github.com/exercism/docs) repository for a larger overview and some more general purpose instructions.
+There are a lot of great resources for contributing to Exercism in general
+already.  Check out the [docs] repository for a larger overview and some more
+general purpose instructions.
 
-A great way to get started contributing is [porting an exercise from another track](#porting-an-exercise-from-another-language)!  It helps you get into the repository, learn your way around, and see how things are structured.
+[docs]: (https://github.com/exercism/docs)
+
+A great way to get started contributing is [porting an exercise] from another
+track!  It helps you get into the repository, learn your way around, and see
+how things are structured.
+
+[porting an exercise]: (#porting-an-exercise-from-another-language)
 
 ## Getting Set Up
 
-In order to run any of the test files (or examples, for that matter), you're going to need Bash.  If you're on OSX or Linux, this shouldn't be a problem for you.  Additionally, you'll need the Bash test runner that we're using: `bats`.  This can be installed via your package manager.  For more specifics, see the [tests page of this repository's docs](https://github.com/exercism/bash/blob/master/docs/TESTS.md).
+In order to run any of the test files (or examples, for that matter), you're
+going to need Bash.  If you're on OSX or Linux, this shouldn't be a problem for
+you.  Additionally, you'll need the Bash test runner that we're using: `bats`.
+This can be installed via your package manager.  For more specifics, see the
+[tests page] of this repositorys docs.
+
+[tests page]: https://github.com/exercism/bash/blob/master/docs/TESTS.md
 
 ## Porting an Exercise from Another Language
 
-Porting an exercise from another language is easy (ish)! [Problem specifications](www.github.com/exercism/problem-specifications) for [unimplemented exercises](www.exercism.io/languages/bash/todo) can be used to do this.
+Porting an exercise from another language is easy (ish)! [Problem
+specifications] for [unimplemented exercises] can be used to do this.
 
-The `_template` directory found in `exercism/bash` can be used to port exercises. Once an example submission, full test suite and README.md have been created, you just need to alter `config.json` to include the newly implemented exercise.
+[Problem specifications]: www.github.com/exercism/problem-specifications
+[unimplemented exercises]: www.exercism.io/languages/bash/todo
+
+The `_template` directory found in `exercism/bash` can be used to port
+exercises. Once an example submission, full test suite and README.md have been
+created, you just need to alter `config.json` to include the newly implemented
+exercise.
 
 ### Initial Setup
 
@@ -27,7 +48,17 @@ $ git clone https://github.com/<your-user-name>/bash.git
 $ cd bash
 ```
 
-Look through the [list of exercises not yet implemented in Bash](http://exercism.io/languages/bash/todo).  Once you've found one you like, make sure that someone's not already working on it by checking the [current open pull requests](https://github.com/exercism/bash/pulls).  Also double check that the exercise isn't in the list of exercises already implemented in your freshly cloned repository: `path/to/bash/exercises`.  Once you've selected an exercise you like, locate its *slug* (unique name) in [the master list of problem specifications](https://github.com/exercism/problem-specifications/tree/master/exercises).
+Look through the [list of exercises not yet implemented] in Bash.  Once you've
+found one you like, make sure that someone's not already working on it by
+checking the [current open pull requests].  Also double check that the exercise
+isn't in the list of exercises already implemented in your freshly cloned
+repository: `path/to/bash/exercises`.  Once you've selected an exercise you
+like, locate its *slug* (unique name) in the [master list] of problem
+specifications.
+
+[list of exercises not yet implemented]: http://exercism.io/languages/bash/todo
+[current open pull requests]: https://github.com/exercism/bash/pulls
+[master list]: https://github.com/exercism/problem-specifications/tree/master/exercises
 
 Create a directory in your local `exercises` folder with that same slug name.
 
@@ -38,7 +69,10 @@ $ git checkout -b <your-slug-here>
 $ mkdir exercises/<your-slug-here>
 ```
 
-At the very least, you're going to need to create a `README.md`, a test file (`your_exercise_test.sh`), and an example file which, by convention, you should name `example.sh` when you're done.  For ease of debugging, you can start by naming your file `your_exercise.sh`.
+At the very least, you're going to need to create a `README.md`, a test file
+(`your_exercise_test.sh`), and an example file which, by convention, you should
+name `example.sh` when you're done.  For ease of debugging, you can start by
+naming your file `your_exercise.sh`.
 
 ```bash
 $ touch README.md
@@ -52,15 +86,29 @@ Ensure that both of the shell script files are executeable.
 $ chmod a+x <your-exercise>_test.sh <your-exercise>.sh
 ```
 
-Many, if not all, of the current exercises have *canonical data* about them that is the same accross all languages.  This makes it so you don't have to come up with test cases or informative intro material yourself.  You're welcome!  Head over to your specific exercise page in the [master list](https://github.com/exercism/problem-specifications/tree/master/exercises) (same link as above).  Specifically right now, you're interested in `canonical_data.json`.
+Many, if not all, of the current exercises have *canonical data* about them
+that is the same accross all languages.  This makes it so you don't have to
+come up with test cases or informative intro material yourself.  You're
+welcome!  Head over to your specific exercise page in the [master list] (same
+link as above).  Specifically right now, you're interested in
+`canonical_data.json`.
 
 ![Canonical data example](img/canonical-data-example.png)
 
-Currently, you're interested in all of the `"cases"`.  Each of these is a test case that you'll have to implement in the specific vernacular of our test-runner, `bats`.  Check out [this repository's test documentation](https://github.com/exercism/bash/blob/master/docs/TESTS.md) if you missed the [Getting Set Up](#getting-set-up) section above.
+Currently, you're interested in all of the `"cases"`.  Each of these is a test
+case that you'll have to implement in the specific vernacular of our
+test-runner, `bats`.  Check out this repository's [test documentation] if you
+missed the [Getting Set Up] section above.
+
+[test documentation]: https://github.com/exercism/bash/blob/master/docs/TESTS.md
+[Getting Set Up]: #getting-set-up
 
 ### Generating the Tests
 
-Implement each of the test cases (along with any comments or explanations you think are necessary for people who aren't sure of themselves).  When in doubt, check out the other, already implemented exercises for an example.  Here's an example of implementing the test case shown above.
+Implement each of the test cases (along with any comments or explanations you
+think are necessary for people who aren't sure of themselves).  When in doubt,
+check out the other, already implemented exercises for an example.  Here's an
+example of implementing the test case shown above.
 
 ```bash
 #!/usr/bin/env bats
@@ -75,9 +123,22 @@ Implement each of the test cases (along with any comments or explanations you th
 # ... The rest of your tests
 ```
 
-For each test you create, you should use the `description` value for the test case description.  The `property` value is generally used by other languages to specify what the function to be run is called.  Use your best judgement and check out how other exercises handle this.  If there's just one property, you can just test the script as a whole.  If there's multiple properties, consider testing those as either subcommands or flags (e.g. an exercise with an encode and a decode property could be handled by `run bash cyper.sh encode <argument>` or by `run bash cypher.sh -e <argument>`).  You're the one writing the tests, so you decide.  You'll get feedback when you open your pull request anyways, so don't stress too much about it.
-
-For test cases that are expected to return `true` or `false` make sure you are expecting an output value. It is better to return `"true"` or `true`, to the console instead of just relying on the exit status in bash (0 for success, 1-255 for error). This will be consistent with the existing exercises and prevent possible issues in the future.
+For each test you create, you should use the `description` value for the test
+case description.  The `property` value is generally used by other languages to
+specify what the function to be run is called.  Use your best judgement and
+check out how other exercises handle this.  If there's just one property, you
+can just test the script as a whole.  If there's multiple properties, consider
+testing those as either subcommands or flags (e.g. an exercise with an encode
+and a decode property could be handled by `run bash cyper.sh encode <argument>`
+or by `run bash cypher.sh -e <argument>`).  You're the one writing the tests,
+so you decide.  You'll get feedback when you open your pull request anyways, so
+don't stress too much about it.
+
+For test cases that are expected to return `true` or `false` make sure you are
+expecting an output value. It is better to return `"true"` or `true`, to the
+console instead of just relying on the exit status in bash (0 for success,
+1-255 for error). This will be consistent with the existing exercises and
+prevent possible issues in the future.
 
 You can check to see if your example script works by running `bats`.
 
@@ -85,17 +146,37 @@ You can check to see if your example script works by running `bats`.
 $ bats hello_world_test.sh
 ```
 
+#### Bash Style Guide
+
+When creating the tests, the tests should follow the [bash style guide]
+to avoid having an inconsistent style.  The tests are delivered as a
+product, and should be as idiomatic as possible, and this will help
+maintain a certain level of consistency.
+
+[bash style guide]: https://google.github.io/styleguide/shell.xml
+
 ### Implementing an Example Solution
 
-If you've been following along so far, your tests should fail.  Go ahead and implement your solution in the `<your-exercise>.sh` file.  Make sure your file has `#!/usr/bin/env bash` ([shebang][shebang]) at the top.
+If you've been following along so far, your tests should fail.  Go ahead and
+implement your solution in the `<your-exercise>.sh` file.  Make sure your file
+has `#!/usr/bin/env bash` ([shebang]) at the top.
+
+[shebang]: https://en.wikipedia.org/wiki/Shebang_(Unix)
 
-Keep running your test file against it until your tests all pass.  This process should help ensure that both your tests *and* your example are ship shape!
+Keep running your test file against it until your tests all pass.  This process
+should help ensure that both your tests *and* your example are ship shape!
 
-Once your tests and example are complete, rename `<your-exercise>.sh` to `example.sh` to match all the other exercises.
+Once your tests and example are complete, rename `<your-exercise>.sh` to
+`example.sh` to match all the other exercises.
 
 ### Updating the Config
 
-Exercism makes heavy use of configuration files to automate things.  Now that you're done with your solution, you can add your problem to `bash/config.json`.  Check out the [configuration description](https://github.com/exercism/docs/blob/master/language-tracks/configuration/exercises.md) in the Exercism docs for more info on each item.
+Exercism makes heavy use of configuration files to automate things.  Now that
+you're done with your solution, you can add your problem to
+`bash/config.json`.  Check out the [configuration description] in the Exercism
+docs for more info on each item.
+
+[configuration description]: https://github.com/exercism/docs/blob/master/language-tracks/configuration/exercises.md
 
 ```javascript
 // config.json
@@ -118,21 +199,31 @@ Exercism makes heavy use of configuration files to automate things.  Now that yo
 }
 ```
 
-Possible topics that describe your exercise can come from the [topics master list](https://github.com/exercism/problem-specifications/blob/master/TOPICS.txt), but you're not limited to those.
+Possible topics that describe your exercise can come from the [topics master
+list], but you're not limited to those.
 
-In order to get the `uuid` and check your work, you'll need the configlet, which is a handy tool created to automate some of the more monotonous tasks involved with this.  See the [configlet documentation](https://github.com/exercism/configlet) for more info.  Make sure you have the most current configlet by running:
+[topics master list]: https://github.com/exercism/problem-specifications/blob/master/TOPICS.txt
+
+In order to get the `uuid` and check your work, you'll need the configlet,
+which is a handy tool created to automate some of the more monotonous tasks
+involved with this.  See the [configlet documentation] for more info.  Make
+sure you have the most current configlet by running:
+
+[configlet documentation]: (https://github.com/exercism/configlet)
 
 ```bash
 $ bin/fetch-configlet
 ```
 
-Each exercise *for each language* needs a unique ID number — a `uuid`.  The configley can help you generate one.
+Each exercise *for each language* needs a unique ID number — a `uuid`.  The
+configlet can help you generate one.
 
 ```bash
 $ bin/configlet uuid
 ```
 
-Copy/paste the generated value into the `uuid` field of your exercise.  Once you're done, it's time to check your work.  Run the configlet linter.
+Copy/paste the generated value into the `uuid` field of your exercise.  Once
+you're done, it's time to check your work.  Run the configlet linter.
 
 ```bash
 $ bin/configlet lint .
@@ -144,21 +235,29 @@ Hopefully it says everything is OK!
 
 ### Creating the README
 
-There are two ways to create the README: generate it via the configlet, or manually create it.  This guide covers them both.
+There are two ways to create the README: generate it via the configlet, or
+manually create it.  This guide covers them both.
 
 #### Using the Configlet
 
-The configlet has a generate command that uses Go templating and pulls from the repository's `config` directory as well as each exercise's `.meta` directory. For example, any necessary `hints.md` should be put in `.meta` so configlet may pull it in. Learn more in the [configlet docs](https://github.com/exercism/configlet).  You should just be able to run:
+The configlet has a generate command that uses Go templating and pulls from the
+repository's `config` directory as well as each exercise's `.meta` directory.
+For example, any necessary `hints.md` should be put in `.meta` so configlet may
+pull it in. Learn more in the [configlet docs].  You should just be able to run:
+
+[configlet docs]: https://github.com/exercism/configlet
 
 ```bash
 $ bin/configlet generate <your-exercise>
 ```
 
-This should auto-generate a nice README in your exercise directory.  If it gives you any issues, no worries!  You can always get it done by...
+This should auto-generate a nice README in your exercise directory.  If it
+gives you any issues, no worries!  You can always get it done by...
 
 #### Doing It Manually
 
-Use the `config/exercise_readme.go.tmpl` file as a guide.  The README should look something like this:
+Use the `config/exercise_readme.go.tmpl` file as a guide.  The README should
+look something like this:
 
 ```markdown
 # <Your Exercise Title>
@@ -175,12 +274,15 @@ Use the `config/exercise_readme.go.tmpl` file as a guide.  The README should loo
 
 ## Submitting Incomplete Solutions
 
-It's possible to submit an incomplete solution so you can see how others have completed the exercise.
+It's possible to submit an incomplete solution so you can see how others have
+completed the exercise.
 ```
 
 ### Cleaning Up
 
-If you've been practicing good version control throughout this process, you may have several commits.  At this point, you're almost ready to submit your pull request, but you should rebase against the most recent upstream master branch.
+If you've been practicing good version control throughout this process, you may
+have several commits.  At this point, you're almost ready to submit your pull
+request, but you should rebase against the most recent upstream master branch.
 
 ```bash
 # Assuming you've already 'git added' and 'git commited'
@@ -202,4 +304,3 @@ $ git push --force-with-lease origin <your-branch-name>
 
 Good luck, happy scripting, and thanks for your help!
 
-[shebang]: https://en.wikipedia.org/wiki/Shebang_(Unix)

data/tracks/bash/config/exercise_readme.go.tmpl

@@ -4,10 +4,16 @@
 {{- with .Hints }}
 {{ . }}
 {{ end }}
-{{- with .TrackInsert }}
-{{ . }}
-{{ end }}
-{{- with .Spec.Credits -}}
+
+Run the tests with:
+
+```bash
+bats {{ .Spec.SnakeCaseName }}_test.sh
+```
+
+After the first test(s) pass, continue by commenting out or removing the `skip` annotations prepending other tests.
+
+{{ with .Spec.Credits -}}
 ## Source
 
 {{ . }}

data/tracks/bash/exercises/acronym/README.md

@@ -4,24 +4,21 @@ Convert a phrase to its acronym.
 
 Techies love their TLA (Three Letter Acronyms)!
 
-Help generate some jargon by writing a program that converts a long name like Portable Network Graphics to its acronym (PNG).
+Help generate some jargon by writing a program that converts a long name
+like Portable Network Graphics to its acronym (PNG).
 
-Run the tests with:
-
-    bats acronym_tests.sh
-
-## Submitting Exercises
 
-Note that, when trying to submit an exercise, make sure the solution is in the `exercism/bash/<exerciseName>` directory.
+Run the tests with:
 
-For example, if you're submitting `bob.sh` for the Bob exercise, the submit command would be something like `exercism submit <path_to_exercism_dir>/bash/bob/bob.sh`.
+```bash
+bats acronym_test.sh
+```
 
-For more detailed information about running tests, code style and linting, please see the [help page](http://exercism.io/languages/bash).
+After the first test(s) pass, continue by commenting out or removing the `skip` annotations prepending other tests.
 
 ## Source
 
-Greg Horie [https://github.com/netserf](https://github.com/netserf)
+Julien Vanier [https://github.com/monkbroc](https://github.com/monkbroc)
 
 ## Submitting Incomplete Solutions
 It's possible to submit an incomplete solution so you can see how others have completed the exercise.
-

data/tracks/bash/exercises/anagram/README.md

@@ -6,9 +6,14 @@ Given `"listen"` and a list of candidates like `"enlists" "google"
 "inlets" "banana"` the program should return a list containing
 `"inlets"`.
 
+
 Run the tests with:
 
-    bats anagram_test.sh
+```bash
+bats anagram_test.sh
+```
+
+After the first test(s) pass, continue by commenting out or removing the `skip` annotations prepending other tests.
 
 ## Source
 

data/tracks/bash/exercises/anagram/anagram_test.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bats
 
-@test "no matches", {
+@test "no matches" {
     #skip
     run bash anagram.sh "diaper" "hello world zombies pants"
     [ "$status" -eq 0 ]

data/tracks/bash/exercises/armstrong-numbers/README.md

@@ -11,10 +11,18 @@ For example:
 
 Write some code to determine whether a number is an Armstrong number.
 
+
+Run the tests with:
+
+```bash
+bats armstrong_numbers_test.sh
+```
+
+After the first test(s) pass, continue by commenting out or removing the `skip` annotations prepending other tests.
+
 ## Source
 
-[Wikipedia](https://en.wikipedia.org/wiki/Narcissistic_number)
+Wikipedia [https://en.wikipedia.org/wiki/Narcissistic_number](https://en.wikipedia.org/wiki/Narcissistic_number)
 
 ## Submitting Incomplete Solutions
-
 It's possible to submit an incomplete solution so you can see how others have completed the exercise.

data/tracks/bash/exercises/atbash-cipher/README.md

@@ -9,7 +9,7 @@ letter, the second with the second-last, and so on.
 
 An Atbash cipher for the Latin alphabet would be as follows:
 
-```plain
+```text
 Plain:  abcdefghijklmnopqrstuvwxyz
 Cipher: zyxwvutsrqponmlkjihgfedcba
 ```
@@ -23,19 +23,19 @@ being 5 letters, and punctuation is excluded. This is to make it harder to guess
 things based on word boundaries.
 
 ## Examples
+
 - Encoding `test` gives `gvhg`
 - Decoding `gvhg` gives `test`
 - Decoding `gsvjf rxpyi ldmul cqfnk hlevi gsvoz abwlt` gives `thequickbrownfoxjumpsoverthelazydog`
 
 
-To run the tests:
+Run the tests with:
 
-```sh
-$ bats atbash_cipher_test.sh
+```bash
+bats atbash_cipher_test.sh
 ```
 
-For more detailed info about the Bash track see the [help page](http://exercism.io/languages/bash).
-
+After the first test(s) pass, continue by commenting out or removing the `skip` annotations prepending other tests.
 
 ## Source
 

data/tracks/bash/exercises/bob/README.md

@@ -6,14 +6,21 @@ Bob answers 'Sure.' if you ask him a question.
 
 He answers 'Whoa, chill out!' if you yell at him.
 
+He answers 'Calm down, I know what I'm doing!' if you yell a question at him.
+
 He says 'Fine. Be that way!' if you address him without actually saying
 anything.
 
 He answers 'Whatever.' to anything else.
 
+
 Run the tests with:
 
-    bats whatever_test.sh
+```bash
+bats bob_test.sh
+```
+
+After the first test(s) pass, continue by commenting out or removing the `skip` annotations prepending other tests.
 
 ## Source