Merge pull request #56 from xebia/https-links

Use HTTPs in URLs everywhere

README.md

@@ -1,18 +1,18 @@
 ![Xebia Essentials](https://raw.githubusercontent.com/xebia/essentials/master/img/XebiaEssentialsCards.jpg?token=3891755__eyJzY29wZSI6IlJhd0Jsb2I6eGViaWEvZXNzZW50aWFscy9tYXN0ZXIvaW1nL1hlYmlhRXNzZW50aWFsc0NhcmRzLmpwZyIsImV4cGlyZXMiOjE0MDI4NjA4MDZ9--390a00c227c472015e94b6b0e613cc1785ef4bb0)
 
-[Website](http://essentials.xebia.com) |
-[Api](http://essentials.xebia.com/api.json) |
+[Website](https://essentials.xebia.com) |
+[Api](https://essentials.xebia.com/api.json) |
 [iOS source](https://github.com/xebia/ios-essentials) |
 [Android source](https://github.com/xebia/android-essentials) |
-[Xebia](http://www.xebia.com) |
-[Blog](http://blog.xebia.com)
+[Xebia](https://www.xebia.com) |
+[Blog](https://blog.xebia.com)
 
 [![Build Status](https://travis-ci.org/xebia/essentials.svg?branch=master)](https://travis-ci.org/xebia/essentials)
 [![Stories in Ready](https://badge.waffle.io/xebia/essentials.png?label=ready)](https://waffle.io/xebia/essentials)
 
 # Xebia Essentials static site generator
 
-This repository contains the static site generator for the [Xebia Essentials](http://essentials.xebia.com), along with all the cards' content and metadata. Each page contains [YAML](http://www.yaml.org/) [front matter](https://gridsome.org/docs/data-store-api/#preprocessing-markdown-frontmatter), two optional [markdown](http://daringfireball.net/projects/markdown) sections for the front and backsites of the [printed cards](http://xebia.com/books/xebia-essentials?utm_source=readme&utm_medium=web&utm_campaign=essentials) followed by a final markdown section that will be converted into the corresponding web page.
+This repository contains the static site generator for the [Xebia Essentials](https://essentials.xebia.com), along with all the cards' content and metadata. Each page contains [YAML](https://www.yaml.org/) [front matter](https://gridsome.org/docs/data-store-api/#preprocessing-markdown-frontmatter), two optional [markdown](https://daringfireball.net/projects/markdown) sections for the front and backsites of the [printed cards](https://xebia.com/books/xebia-essentials?utm_source=readme&utm_medium=web&utm_campaign=essentials) followed by a final markdown section that will be converted into the corresponding web page.
 
 This results in the following layout:
 
@@ -31,7 +31,7 @@ Configuration is done through Gridsome's `gridsome.config.js` and `gridsome.serv
 
 ## Licence
 
-![CC-BY-NC](http://i.creativecommons.org/l/by-nc/3.0/88x31.png)
+![CC-BY-NC](https://i.creativecommons.org/l/by-nc/3.0/88x31.png)
 
 The content is lienced under [CC BY-NC 4.0](https://creativecommons.org/licenses/by-nc/4.0/), with the exception of
 the images and text-content of the cards for which the copyright is maintained.
@@ -50,14 +50,14 @@ npm install
 
 ### Build & Serve
 
-To locally serve the statically generated site at `http://localhost:8080`, and automatically rebuild when
+To locally serve the statically generated site at `https://localhost:8080`, and automatically rebuild when
 any file is changed, run from the project root directory:
 
 ```bash
 npm run develop
 ```
 
-GraphQL Playground is at `http://localhost:8080/___explore`.
+GraphQL Playground is at `https://localhost:8080/___explore`.
 
 Build the static site using
 

cards/apis-are-forever.md

@@ -1,8 +1,6 @@
 ---
-
 layout: card
 category: realisation
-
 ---
 
 APIs, like diamonds, are forever
@@ -11,11 +9,11 @@ APIs, like diamonds, are forever
 
 So craft them carefully:
 
-> * APIs should be self-documenting
-> * Obey the principle of least astonishment
-> * Use consistent parameter ordering across methods
-> * APIs should be easy to use, and hard to misuse
-> <div class="attribution">Joshua Bloch</div>
+> - APIs should be self-documenting
+> - Obey the principle of least astonishment
+> - Use consistent parameter ordering across methods
+> - APIs should be easy to use, and hard to misuse
+>   <div class="attribution">Joshua Bloch</div>
 
 ---
 
@@ -25,55 +23,55 @@ You want to be careful crafting your API. If you don't, then you might end up wi
 
 Joshua Bloch presented his ideas on API design in a talk named 'How to Design a Good API and Why it Matters' at OOPSLA 2006. It comprises a set of criteria that are fairly easy to remember, as they are all small enough to fit on a bumper sticker:
 
-* All programmers are API designers
-* APIs can be among your greatest assets or liabilities
-* Public APIs, like diamonds, are forever
-* APIs should be easy to use and hard to misuse
-* APIs should be self-documenting
-* When designing an API, first gather requirements - with a healthy degree of skepticism
-* Structure requirements as use-cases
-* Early drafts of APIs should be short
-* Code the use-cases against your API before you implement it
-* Maintain the code for use-cases as the API evolves
-* Example code should be exemplary
-* You can't please everyone so aim to displease everyone equally
-* Expect API-design mistakes due to failures of your imagination
-* API design is not a solitary activity
-* Avoid fixed limits on input sizes
-* Names matter
-* If it's hard to find good names, go back to the drawing board
-* When in doubt leave it out
-* Keep APIs free of implementation details
-* Minimize mutability
-* Documentation matters
-* Consider the performance of consequences of an API design decisions, but don't warp an API to achieve performance gains
-* When in Rome, do as the Romans do
-* Minimize accessibility
-* Subclass only if you can say with a straight face that every instance of the subclass is an instance of the superclass
-* Design and document for inheritance or else prohibit it
-* Don't make the client do anything the library could do
-* Obey the principle of the last astonishment
-* Fail fast
-* Provide programmatic access to all data available in string form
-* Overload with care
-* Use the right data type for the job
-* Use consistent parameter ordering across methods
-* Avoid long parameter names
-* Avoid return values that demand exceptional processing
-* Throw exceptions only to indicate exceptional conditions
-* Throw unchecked exceptions unless clients can realistically recover from the failure
-* API design is an art, not a science
+- All programmers are API designers
+- APIs can be among your greatest assets or liabilities
+- Public APIs, like diamonds, are forever
+- APIs should be easy to use and hard to misuse
+- APIs should be self-documenting
+- When designing an API, first gather requirements - with a healthy degree of skepticism
+- Structure requirements as use-cases
+- Early drafts of APIs should be short
+- Code the use-cases against your API before you implement it
+- Maintain the code for use-cases as the API evolves
+- Example code should be exemplary
+- You can't please everyone so aim to displease everyone equally
+- Expect API-design mistakes due to failures of your imagination
+- API design is not a solitary activity
+- Avoid fixed limits on input sizes
+- Names matter
+- If it's hard to find good names, go back to the drawing board
+- When in doubt leave it out
+- Keep APIs free of implementation details
+- Minimize mutability
+- Documentation matters
+- Consider the performance of consequences of an API design decisions, but don't warp an API to achieve performance gains
+- When in Rome, do as the Romans do
+- Minimize accessibility
+- Subclass only if you can say with a straight face that every instance of the subclass is an instance of the superclass
+- Design and document for inheritance or else prohibit it
+- Don't make the client do anything the library could do
+- Obey the principle of the last astonishment
+- Fail fast
+- Provide programmatic access to all data available in string form
+- Overload with care
+- Use the right data type for the job
+- Use consistent parameter ordering across methods
+- Avoid long parameter names
+- Avoid return values that demand exceptional processing
+- Throw exceptions only to indicate exceptional conditions
+- Throw unchecked exceptions unless clients can realistically recover from the failure
+- API design is an art, not a science
 
 ### Applicability
 
 Always.
 
 ### Application
 
-* Use it while designing the API
-* Use it while coding
-* Use it while reviewing code
-* Use it while pair programming
+- Use it while designing the API
+- Use it while coding
+- Use it while reviewing code
+- Use it while pair programming
 
 It might be good idea to read the list before you go off to design something significant, or always have a printed version of the list close to where you are.
 
@@ -91,9 +89,7 @@ Less than great API design samples, often serving in examples in Joshua Bloch's
 
 ### References
 
-* [InfoQ Article](http://www.infoq.com/articles/API-Design-Joshua-Bloch)
-* [Video recorded at JavaPolis](http://www.infoq.com/presentations/effective-api-design)
-* [code-review](code-review)
-* [comment-with-care](comment-with-care)
-
-
+- [InfoQ Article](https://www.infoq.com/articles/API-Design-Joshua-Bloch)
+- [Video recorded at JavaPolis](https://www.infoq.com/presentations/effective-api-design)
+- [code-review](code-review)
+- [comment-with-care](comment-with-care)

cards/assertions.md

@@ -1,15 +1,14 @@
 ---
-
 layout: card
 category: realisation
-
 ---
 
 Assert against improper behaviour
 
 ---
 
 > If it can't happen, use assertions to assure it won't.
+>
 > <div class="attribution">Andrew Hunt, David Thomas</div>
 
 ---
@@ -20,11 +19,11 @@ Ideally, the compiler would be able to verify all of your assumptions. In realit
 
 This is where assertions come to the rescue. Assertions allow you to validate pre- and postconditions and can help you to assure your invariants hold. Putting in assertions will make sure your code fails early before causing anymore damage. It also works as a mental flag.
 
-* You think you're sure something will never happen =&gt;
-* The rule tells you to put an assertion in =&gt;
-* You start to consider if your assumption actually holds in all circumstances =&gt;
-* You might alter your code based on the conclusion =&gt;
-* You put in an assertion
+- You think you're sure something will never happen =&gt;
+- The rule tells you to put an assertion in =&gt;
+- You start to consider if your assumption actually holds in all circumstances =&gt;
+- You might alter your code based on the conclusion =&gt;
+- You put in an assertion
 
 ### Applicability
 
@@ -46,7 +45,7 @@ Spring Assert class:
 
 Disadvantage: no isolated jar; you pull in a significant number of classes.
 
-Guava [Preconditions](http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html) class:
+Guava [Preconditions](https://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html) class:
 
     Preconditions.checkArgument(x > 3)
 
@@ -56,4 +55,4 @@ If you put in assertions, then your code will fail if the assertions are violate
 
 ### References
 
-1. *Programming Defensively* Interview with Andy Hunt and Dave Thomas, <a href="http://www.artima.com/intv/defense.html">http://www.artima.com/intv/defense.html</a>
+1. _Programming Defensively_ Interview with Andy Hunt and Dave Thomas, <a href="https://www.artima.com/intv/defense.html">https://www.artima.com/intv/defense.html</a>

cards/code-review.md

@@ -1,8 +1,6 @@
 ---
-
 layout: card
 category: collaboration
-
 ---
 
 Review code
@@ -30,7 +28,7 @@ Reviewing can be done in several ways. First there is the old fashioned way: jus
 
 Then there is the per commit reviewing style, that allows the reviewer to review changes rather than the end result. This is perfect for quick feedback on developer behaviour, rather than the result of the behaviour. It takes more time and discipline to review all commits.
 
-A great way of code reviewing is by using Pull Requests. Pull requests are a feature of most DVCS hosting tools. If your project is on a distributed version control system (DVCS) like Git or Mercurial, you can use such a system. It's basically a pending merge from one branch into another, accompanied by a commenting system. The great thing about pull requests is that they're asynchronous (you don't have to interrupt a colleague in their work), persistent (the reviewing comments are archived), up-to-date (the scope of the code review automatically updates as further commits are made on the development branch) and public (pull requests are visible to the entire team, anyone can chip in). At GitHub, it's not uncommon for a pull request to live for months before being merged. There's a great talk about how they use them: [How GitHub uses GitHub to build GitHub](http://zachholman.com/talk/how-github-uses-github-to-build-github/).
+A great way of code reviewing is by using Pull Requests. Pull requests are a feature of most DVCS hosting tools. If your project is on a distributed version control system (DVCS) like Git or Mercurial, you can use such a system. It's basically a pending merge from one branch into another, accompanied by a commenting system. The great thing about pull requests is that they're asynchronous (you don't have to interrupt a colleague in their work), persistent (the reviewing comments are archived), up-to-date (the scope of the code review automatically updates as further commits are made on the development branch) and public (pull requests are visible to the entire team, anyone can chip in). At GitHub, it's not uncommon for a pull request to live for months before being merged. There's a great talk about how they use them: [How GitHub uses GitHub to build GitHub](https://zachholman.com/talk/how-github-uses-github-to-build-github/).
 
 Note that Code Reviewing and [Pair Programming](pair-programming) are not interchangeable, because they serve different goals.
 

cards/comment-with-care.md

@@ -1,18 +1,16 @@
 ---
-
 layout: card
 category: craftsmanship
-
 ---
 
 Comment with care
 
 ---
 
-* Don't document bad code – rewrite it
-* Don't repeat the code – clarify its intent
-* Document surprises and workarounds
-* Make every comment count
+- Don't document bad code – rewrite it
+- Don't repeat the code – clarify its intent
+- Document surprises and workarounds
+- Make every comment count
 
 ---
 
@@ -28,9 +26,9 @@ Every modern programming language I'm aware of supports source code comments.
 
 ### Application
 
-* In an object-oriented language such as Java (1), it's fair to demand a type-level JavaDoc header that describes the intent and responsibility of the class or interface on every public or protected type.
-* On APIs intended for use by others, every public method and field should be appropriately documented.
-* Use the standard documentation system for the platform. In Python, that's doc strings. In Java, that's JavaDoc. The standard documentation system is not only familiar to humans, most IDEs and some editors know how to read it too. As obvious as this may seem, I more than once had the displeasure of using a closed-source API documented using a proprietary HTML layout not in any way resembling standard JavaDoc. It was painful.
+- In an object-oriented language such as Java (1), it's fair to demand a type-level JavaDoc header that describes the intent and responsibility of the class or interface on every public or protected type.
+- On APIs intended for use by others, every public method and field should be appropriately documented.
+- Use the standard documentation system for the platform. In Python, that's doc strings. In Java, that's JavaDoc. The standard documentation system is not only familiar to humans, most IDEs and some editors know how to read it too. As obvious as this may seem, I more than once had the displeasure of using a closed-source API documented using a proprietary HTML layout not in any way resembling standard JavaDoc. It was painful.
 
 Guidelines aside, whenever you find yourself wondering: "I wonder whether this'll make sense to me later", you know it's time for a comment. Ensure the comment contains information that cannot be obtained by simply reading the code itself.
 
@@ -44,7 +42,7 @@ Effective use of source code comments improves the maintainability of program co
 
 # Don't document bad code - rewrite it.
 
-The [Wikipedia article on commenting](http://en.wikipedia.org/wiki/Comment_%28computer_programming%29) ascribes this aphorism to The Elements of Programming Style [3]. It's a good general guideline, but it may not always be feasible, especially in maintenance projects.
+The [Wikipedia article on commenting](https://en.wikipedia.org/wiki/Comment_%28computer_programming%29) ascribes this aphorism to The Elements of Programming Style [3]. It's a good general guideline, but it may not always be feasible, especially in maintenance projects.
 
 # Don't repeat the code - clarify its intent.
 
@@ -72,7 +70,7 @@ Maybe the intent can be clarified just as much without a comment:
 
 An example of this is when I found out that a Java 1.5 ThreadPoolExecutor with a corePoolSize of 0, a maxPoolSize of 50 and an unbounded task queue does not idle at 0 threads and execute at 50, but rather, starts 0 threads and executes nothing at all. When I dug into this, I found out that Java 1.5 has no way to make a ThreadPoolExecutor idle at 0 threads (Java 1.6 does) and that in both versions maxPoolSize is meaningless with an unbounded queue. I put a short note above the variable declaration to benefit any maintenance programmer that needs to adjust the pool sizes.
 
-A special case of this is where source code analysis tools report a false positive. A great example of this is the [Debian OpenSSL](http://digitaloffense.net/tools/debian-openssl/) fiasco of a few years back. The random number generator contained what appears to be bad use of uninitialized memory (and was reported as such by code analysis tools), but which was essential to seeding the random number generator. Someone removed the line in a clean-up effort and the result was two years' worth of SSL certificates each of which could be brute-forced in at most 32768 attempts.
+A special case of this is where source code analysis tools report a false positive. A great example of this is the [Debian OpenSSL](https://digitaloffense.net/tools/debian-openssl/) fiasco of a few years back. The random number generator contained what appears to be bad use of uninitialized memory (and was reported as such by code analysis tools), but which was essential to seeding the random number generator. Someone removed the line in a clean-up effort and the result was two years' worth of SSL certificates each of which could be brute-forced in at most 32768 attempts.
 
 # Make every comment count.
 
@@ -129,5 +127,3 @@ The xsd:dateTime has a resolution in seconds (optionally milliseconds) and an op
 ### Footnotes
 
 1. Some argue Java isn't an object oriented language. It's close enough for the purposes of this article.
-
-

cards/composition-over-inheritance.md

@@ -1,8 +1,6 @@
 ---
-
 layout: card
 category: realisation
-
 ---
 
 Favor composition over inheritance
@@ -86,6 +84,4 @@ If you have different devices that use the same software and only differ in the
 
 ### References
 
-[Composite Reuse Principle](http://www.cs.sjsu.edu/~pearce/cs251b/principles/crp.htm)
-
-
+[Composite Reuse Principle](https://www.cs.sjsu.edu/~pearce/cs251b/principles/crp.htm)

cards/context-over-habit.md

@@ -1,8 +1,6 @@
 ---
-
 layout: card
 category: craftsmanship
-
 ---
 
 Improve practices, don't just follow the recipe
@@ -21,5 +19,4 @@ The appropriate solution may of course be a common Best Practice. They're called
 
 ### References
 
-* [There is no such thing as best practices](http://blogs.tedneward.com/2005/08/26/There+Is+No+Such+Thing+As+Best+Practices+Context+Matters.aspx), Ted Neward's blog.
-
+- [There is no such thing as best practices](https://blogs.tedneward.com/2005/08/26/There+Is+No+Such+Thing+As+Best+Practices+Context+Matters.aspx), Ted Neward's blog.