diff --git a/README.md b/README.md index 27e64a6..70b66da 100644 --- a/README.md +++ b/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 diff --git a/cards/apis-are-forever.md b/cards/apis-are-forever.md index 7228503..30bab5c 100644 --- a/cards/apis-are-forever.md +++ b/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 ->
Joshua Bloch
+> - 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 +>
Joshua Bloch
--- @@ -25,44 +23,44 @@ 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 @@ -70,10 +68,10 @@ 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) diff --git a/cards/assertions.md b/cards/assertions.md index 060a6cf..6f16fb5 100644 --- a/cards/assertions.md +++ b/cards/assertions.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Assert against improper behaviour @@ -10,6 +8,7 @@ Assert against improper behaviour --- > If it can't happen, use assertions to assure it won't. +> >
Andrew Hunt, David Thomas
--- @@ -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 => -* The rule tells you to put an assertion in => -* You start to consider if your assumption actually holds in all circumstances => -* You might alter your code based on the conclusion => -* You put in an assertion +- You think you're sure something will never happen => +- The rule tells you to put an assertion in => +- You start to consider if your assumption actually holds in all circumstances => +- You might alter your code based on the conclusion => +- 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, http://www.artima.com/intv/defense.html +1. _Programming Defensively_ Interview with Andy Hunt and Dave Thomas, https://www.artima.com/intv/defense.html diff --git a/cards/code-review.md b/cards/code-review.md index b7c3d0f..4da0dbf 100644 --- a/cards/code-review.md +++ b/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. diff --git a/cards/comment-with-care.md b/cards/comment-with-care.md index 1168f55..a4cbb61 100644 --- a/cards/comment-with-care.md +++ b/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. - - diff --git a/cards/composition-over-inheritance.md b/cards/composition-over-inheritance.md index c0a2dc6..68c2073 100644 --- a/cards/composition-over-inheritance.md +++ b/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) diff --git a/cards/context-over-habit.md b/cards/context-over-habit.md index 49c3b03..0b14c35 100644 --- a/cards/context-over-habit.md +++ b/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. diff --git a/cards/curiosity.md b/cards/curiosity.md index 09fcdb3..7c81712 100644 --- a/cards/curiosity.md +++ b/cards/curiosity.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- Be curious @@ -10,6 +8,7 @@ Be curious --- > Curiouser and curiouser! +> >
Alice in Wonderland
Curiosity is one of the main sources of creativity. @@ -21,15 +20,19 @@ Curiosity is one of the main sources of creativity. Four reasons why curiosity is important: #### It makes your mind active instead of passive + Curious people always ask questions and search for answers in their minds. Their minds are always active. Since the mind is like a muscle which becomes stronger through continual exercise, the mental exercise caused by curiosity makes your mind stronger and stronger. #### It makes your mind observant of new ideas + When you are curious about something, your mind expects and anticipates new ideas related to it. When the ideas come they will soon be recognized. Without curiosity, the ideas may pass right in front of you and yet you miss them because your mind is not prepared to recognize them. Just think, how many great ideas may have lost due to lack of curiosity? #### It opens up new worlds and possibilities + By being curious you will be able to see new worlds and possibilities which are normally not visible. They are hidden behind the surface of normal life, and it takes a curious mind to look beneath the surface and discover these new worlds and possibilities. #### It brings excitement into your life + The life of curious people is far from boring. It's neither dull nor routine. There are always new things that attract their attention, there are always new 'toys' to play with. Instead of being bored, curious people have an adventurous life. ### Applicability @@ -38,27 +41,27 @@ Applies to every aspect of your work. ### Application -*1. Keep an open mind* +_1. Keep an open mind_ This is essential if you are to have a curious mind. Be open to learn, unlearn, and relearn. Some things you know and believe might be wrong, and you should be prepared to accept this possibility and change your mind. -*2. Don't take things as granted* +_2. Don't take things as granted_ If you just accept the world as it is without trying to dig deeper, you will certainly lose the 'holy curiosity'. Never take things as granted. Try to dig deeper beneath the surface of what is around you. -*3. Ask questions relentlessly* +_3. Ask questions relentlessly_ A sure way to dig deeper beneath the surface is asking questions: What is that? Why is it made that way? When was it made? Who invented it? Where does it come from? How does it work? What, why when who where and how are the best friends of curious people. -*4. Don't label something as boring* +_4. Don't label something as boring_ Whenever you label something as boring, you close one more door of possibilities. Curious people are unlikely to call something as boring. Instead, they always see it as a door to an exciting new world. Even if they don't yet have time to explore it, they will leave the door open to be visited another time. -*5. See learning as something fun* +_5. See learning as something fun_ If you see learning as a burden, there's no way you will want to dig deeper into anything. That will just make the burden heavier. But if you think of learning as something fun, you will naturally want to dig deeper. So look at life through the glasses of fun and excitement and enjoy the learning process.. -*6. Read diverse kinds of reading* +_6. Read diverse kinds of reading_ Don't spend too much time on just one world; take a look at another worlds. It will introduce you to the possibilities and excitement of the other worlds which may spark your interest to explore them further. One easy way to do this is through reading diverse kinds of reading. Try to pick a book or magazine on a new subject and let it feed your mind with the excitement of a new world. @@ -70,5 +73,4 @@ Curiosity feeds creativity and inspiration. It makes you a better problem solver ### References -1. 4 Reasons Why Curiosity is Important, Donald Latumahina, [http://www.lifehack.org/articles/productivity/4-reasons-why-curiosity-is-important-and-how-to-develop-it.html](http://www.lifehack.org/articles/productivity/4-reasons-why-curiosity-is-important-and-how-to-develop-it.html) - +1. 4 Reasons Why Curiosity is Important, Donald Latumahina, [https://www.lifehack.org/articles/productivity/4-reasons-why-curiosity-is-important-and-how-to-develop-it.html](https://www.lifehack.org/articles/productivity/4-reasons-why-curiosity-is-important-and-how-to-develop-it.html) diff --git a/cards/dare-to-say-no.md b/cards/dare-to-say-no.md index 317ca41..e3d222b 100644 --- a/cards/dare-to-say-no.md +++ b/cards/dare-to-say-no.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- Dare to say no @@ -37,6 +35,5 @@ Software engineers pride themselves on solving problems and "doing the impossibl ###References -* [Manifesto for Software Craftsmanship](http://manifesto.softwarecraftsmanship.org/) -* [Craftsmanship and Ethics, Robert C. Martin](http://www.infoq.com/presentations/craftsmanship-ethics) - +- [Manifesto for Software Craftsmanship](https://manifesto.softwarecraftsmanship.org/) +- [Craftsmanship and Ethics, Robert C. Martin](https://www.infoq.com/presentations/craftsmanship-ethics) diff --git a/cards/definition-of-ready.md b/cards/definition-of-ready.md index 09fe809..b30a438 100644 --- a/cards/definition-of-ready.md +++ b/cards/definition-of-ready.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- Work on stories when they're ready @@ -11,11 +9,11 @@ Work on stories when they're ready Have a Definition of READY to judge whether a user story is fit to go into a sprint. -* Do the team members understand the story? -* Is the story sized correctly? -* Have the acceptance criteria been defined? -* Are the external dependencies in place? -* How will the demo look? +- Do the team members understand the story? +- Is the story sized correctly? +- Have the acceptance criteria been defined? +- Are the external dependencies in place? +- How will the demo look? --- @@ -31,9 +29,9 @@ Definition of Ready is an important tool that can be used by a scrum team to jud While planning a sprint, a User Story must pass the following criteria in order to become eligible for inclusion in a sprint. -* A User Story must define an acceptance criteria which is testable. -* A User Story must also share information on why is it required, giving the team a bigger context on the importance of the story. -* Team should be able to estimate it; In other words there should be a loose implementation strategy associated with it. +- A User Story must define an acceptance criteria which is testable. +- A User Story must also share information on why is it required, giving the team a bigger context on the importance of the story. +- Team should be able to estimate it; In other words there should be a loose implementation strategy associated with it. ### Consequences @@ -41,5 +39,5 @@ By including a story in the sprint that is not READY, the team risks building so ### References -* Serge's Blog: [http://blog.xebia.com/2009/06/19/the-definition-of-ready/](http://blog.xebia.com/2009/06/19/the-definition-of-ready/) -* [Another Interesting Blog From a Scrum Coach on DOR](http://www.nomad8.com/files/0787c369f92e9581d8ccf145ec62181b-15.php) +- Serge's Blog: [https://blog.xebia.com/2009/06/19/the-definition-of-ready/](https://blog.xebia.com/2009/06/19/the-definition-of-ready/) +- [Another Interesting Blog From a Scrum Coach on DOR](https://www.nomad8.com/files/0787c369f92e9581d8ccf145ec62181b-15.php) diff --git a/cards/dry-principle.md b/cards/dry-principle.md index e954127..989e8b7 100644 --- a/cards/dry-principle.md +++ b/cards/dry-principle.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- Don't Repeat Yourself @@ -10,14 +8,15 @@ Don't Repeat Yourself --- > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. +> >
Andy Hunt and Dave Thomas
--- ### Also known as -* The DIE Principle: Duplication Is Evil -* SPOT: Single Point Of Truth +- The DIE Principle: Duplication Is Evil +- SPOT: Single Point Of Truth ### Motivation @@ -44,5 +43,5 @@ Stories from the trenches? Horror stories? Source code? Customer references? Sam ### References -* [Orthogonality and the DRY principle](http://www.artima.com/intv/dryP.html) -* [DRY Principle not applied to Unit Test](http://codebetter.com/blogs/karlseguin/archive/2009/09/12/unit-testing-do-repeat-yourself.aspx) +- [Orthogonality and the DRY principle](https://www.artima.com/intv/dryP.html) +- [DRY Principle not applied to Unit Test](https://codebetter.com/blogs/karlseguin/archive/2009/09/12/unit-testing-do-repeat-yourself.aspx) diff --git a/cards/eliminate-waste.md b/cards/eliminate-waste.md index 1e7a74d..9ad57de 100644 --- a/cards/eliminate-waste.md +++ b/cards/eliminate-waste.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- Eliminate waste @@ -11,13 +9,13 @@ Eliminate waste Sources of waste in software development include: -* Partially done work -* Extra features -* Relearning -* Task switching -* Hand-offs -* Delays -* Defects +- Partially done work +- Extra features +- Relearning +- Task switching +- Hand-offs +- Delays +- Defects --- @@ -45,13 +43,13 @@ Value stream mapping is one particular tool that can be used by a team or organi There is a lot of value in reducing waste: -* Frustration ↘ -* Productivity ↗ -* Creativity ↗ -* Speed ↗ -* Delivery of value ↗ -* Reduce defects ↗ +- Frustration ↘ +- Productivity ↗ +- Creativity ↗ +- Speed ↗ +- Delivery of value ↗ +- Reduce defects ↗ ### References -1. [Eliminate Waste](http://www.agileadvice.com/archives/2005/04/eliminate_waste.html) +1. [Eliminate Waste](https://www.agileadvice.com/archives/2005/04/eliminate_waste.html) diff --git a/cards/exploratory-testing.md b/cards/exploratory-testing.md index 439d433..2eece6c 100644 --- a/cards/exploratory-testing.md +++ b/cards/exploratory-testing.md @@ -1,15 +1,13 @@ --- - layout: card category: testing - --- Make room for exploratory testing --- -Following a test script means you're consistent, but predictable. Exploratory +Following a test script means you're consistent, but predictable. Exploratory testing reveals the things you hadn't thought to script. Be curious, go outside the beaten path. @@ -48,6 +46,4 @@ Information: What kind of information are you hoping to find? e.g. Can an user a ### References -[http://pragprog.com/book/ehxta/explore-it](http://pragprog.com/book/ehxta/explore-it) - - +[https://pragprog.com/book/ehxta/explore-it](https://pragprog.com/book/ehxta/explore-it) diff --git a/cards/fallacies-distributed-computing.md b/cards/fallacies-distributed-computing.md index 8a57fb4..c3fb116 100644 --- a/cards/fallacies-distributed-computing.md +++ b/cards/fallacies-distributed-computing.md @@ -1,23 +1,21 @@ --- - layout: card category: realisation - --- Remember the fallacies of distributed computing --- -> * The network is reliable -> * Latency is zero -> * Bandwidth is infinite -> * The network is secure -> * Topology doesn't change -> * There is one administrator -> * Transport cost is zero -> * The network is homogeneous ->
Peter Deutsch
+> - The network is reliable +> - Latency is zero +> - Bandwidth is infinite +> - The network is secure +> - Topology doesn't change +> - There is one administrator +> - Transport cost is zero +> - The network is homogeneous +>
Peter Deutsch
--- @@ -32,11 +30,11 @@ More often than not, we at Xebia work on distributed systems. In our industry, i 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. -3. The network is secure. -4. Topology doesn't change. -5. There is one administrator. -6. Transport cost is zero. -7. The network is homogeneous. +4. The network is secure. +5. Topology doesn't change. +6. There is one administrator. +7. Transport cost is zero. +8. The network is homogeneous. Ignoring these properties will lead to brittle systems. We don't want to create brittle systems; we want to create robust systems. Systems that survive network failure. Systems that do not need the constant presence of a network administrator in order to survive. Systems that are resilient to changes to the network topology. @@ -56,7 +54,6 @@ Now, question is if your solutions always need to have the same properties as Ji ### References -* [Wikipedia](http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing) - -[jini]: http://en.wikipedia.org/wiki/Jini +- [Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing) +[jini]: https://en.wikipedia.org/wiki/Jini diff --git a/cards/focused-interfaces.md b/cards/focused-interfaces.md index e8ffa96..8de0ba7 100644 --- a/cards/focused-interfaces.md +++ b/cards/focused-interfaces.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Write small and focused interfaces @@ -36,8 +34,8 @@ Like every principle, Interface Segregation Principle requires additional time a This principle is important because it encourages two very important ingredients of a good software design: -* High cohesion - Keep all related methods together -* Low coupling - Keep dependence of one another to the bare minimum +- High cohesion - Keep all related methods together +- Low coupling - Keep dependence of one another to the bare minimum Changes to fat interfaces tend to cause a ripple affect to classes who shouldn't have been affected in the first place. @@ -47,6 +45,5 @@ Java Collection API is a good example on interface segregation. Classes can depe ### References -* [http://www.objectmentor.com/resources/articles/isp.pdf](http://www.objectmentor.com/resources/articles/isp.pdf) -* The [LCOM4 metric in Sonar](http://www.sonarsource.org/clean-up-design-at-class-level-with-sonar/) can help reveal violations of this principle in an existing code base. - +- [https://www.objectmentor.com/resources/articles/isp.pdf](https://www.objectmentor.com/resources/articles/isp.pdf) +- The [LCOM4 metric in Sonar](https://www.sonarsource.org/clean-up-design-at-class-level-with-sonar/) can help reveal violations of this principle in an existing code base. diff --git a/cards/hurt-often.md b/cards/hurt-often.md index 15d362f..09decc2 100644 --- a/cards/hurt-often.md +++ b/cards/hurt-often.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- If it hurts, do it more often @@ -32,6 +30,6 @@ Shortening your time to production increases your ability to respond to change a ### References -* Related Cards: [Three Strikes and you Automate](three-strikes), [Integrate Early](integrate-early), [Run Tests Automatically](run-tests-automatically) -* [Deploying at GitHub](https://github.com/blog/1241-deploying-at-github) -* [Continuous Delivery](http://martinfowler.com/books/continuousDelivery.html) +- Related Cards: [Three Strikes and you Automate](three-strikes), [Integrate Early](integrate-early), [Run Tests Automatically](run-tests-automatically) +- [Deploying at GitHub](https://github.com/blog/1241-deploying-at-github) +- [Continuous Delivery](https://martinfowler.com/books/continuousDelivery.html) diff --git a/cards/improve-continuously.md b/cards/improve-continuously.md index 979676c..d963ddf 100644 --- a/cards/improve-continuously.md +++ b/cards/improve-continuously.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- Favor continuous improvement over delayed perfection @@ -15,6 +13,7 @@ If you don't get better, you get worse. > Continuous improvement is about removing the things that get in the way of your > work. The headaches, the things that slow you down, that’s what > continuous improvement is all about. +> >
Bruce Hamilton
--- @@ -43,8 +42,7 @@ Continuous improvement requires dedication, and dedication required dedicated ti ### References -1. The Programmer's Bill of Rights, Jeff Atwood, [http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html](http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html) +1. The Programmer's Bill of Rights, Jeff Atwood, [https://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html](https://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html) 2. The Productive Programmer, Neal Ford 3. The Pragmatic Programmer; from Journeyman to Master, Andrew Hunt and David Thomas -4. Kaizen, [http://en.wikipedia.org/wiki/Kaizen](http://en.wikipedia.org/wiki/Kaizen) - +4. Kaizen, [https://en.wikipedia.org/wiki/Kaizen](https://en.wikipedia.org/wiki/Kaizen) diff --git a/cards/index.md b/cards/index.md index 3c85321..661c34d 100644 --- a/cards/index.md +++ b/cards/index.md @@ -14,9 +14,9 @@ Good software does not come about just like that; by mere coincidence. Inside a Inside our organization, many of these patterns were applied either consciously or subconsciously. We felt the need to bring these patterns forward from under lock and key into the clear light of day for everyone's awareness. -After months of gathering, slicing, dicing and eventual distilling, we arrived at what we consider to be the 'Essentials', distributed as a pack of flash cards, found in the Xebia Bookstore (sold out). +After months of gathering, slicing, dicing and eventual distilling, we arrived at what we consider to be the 'Essentials', distributed as a pack of flash cards, found in the Xebia Bookstore (sold out). -[![Photo of a deck of Xebia Essentials cards.](/images/XebiaEssentialsDeck-2nd-ed.jpg)](http://xebia.com/books/xebia-essentials) +[![Photo of a deck of Xebia Essentials cards.](/images/XebiaEssentialsDeck-2nd-ed.jpg)](https://xebia.com/books/xebia-essentials) In many cases it involves ideas, or the expression of those ideas, for which we cannot take credit ourselves. In those cases, we have strived to grant credit to the originators, being fully aware that greatness can only be achieved by standing on the shoulders of giants. @@ -28,4 +28,4 @@ We are convinced, it's many of these ideas that make our people into the craftsm If you'd like a beautiful box of printed Xebia Essentials cards for your team, you can get your own deck of Essentials cards in the Xebia store (sold out). -Buy Now +Buy Now diff --git a/cards/kiss.md b/cards/kiss.md index 923d9ef..51ed054 100644 --- a/cards/kiss.md +++ b/cards/kiss.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Your solution should not be more complicated than the problem @@ -11,19 +9,19 @@ Your solution should not be more complicated than the problem Also known as: -* The simplest thing that could possibly work -* Keep It Simple, Stupid (KISS) -* Less is more -* You Ain't Gonna Need It (YAGNI) +- The simplest thing that could possibly work +- Keep It Simple, Stupid (KISS) +- Less is more +- You Ain't Gonna Need It (YAGNI) --- ### Also known as -* The simplest thing that could possibly work -* Keep It Simple, Stupid (KISS) -* Less is more -* You Ain't Gonna Need It (YAGNI) +- The simplest thing that could possibly work +- Keep It Simple, Stupid (KISS) +- Less is more +- You Ain't Gonna Need It (YAGNI) ### Motivation @@ -51,7 +49,5 @@ Every project has examples of overcomplicating matters. It often starts with the ### References -* [http://en.wikipedia.org/wiki/KISS_principle](http://en.wikipedia.org/wiki/KISS_principle) -* [http://people.apache.org/~fhanik/kiss.html](http://people.apache.org/~fhanik/kiss.html) - - +- [https://en.wikipedia.org/wiki/KISS_principle](https://en.wikipedia.org/wiki/KISS_principle) +- [https://people.apache.org/~fhanik/kiss.html](https://people.apache.org/~fhanik/kiss.html) diff --git a/cards/make-it-visible.md b/cards/make-it-visible.md index fd5238e..56505bf 100644 --- a/cards/make-it-visible.md +++ b/cards/make-it-visible.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- Make it visible @@ -30,10 +28,10 @@ A burndown chart is the perfect example of a visualization that allows you to un Visualization is a tool that comes in handy in all sorts of circumstances. Dan Roam cuts the problem solving process into four phases, and suggests visualization techniques to help you through each of these phases: -* Looking = Collecting and screening -* Seeing = Selecting and clumping -* Imagining = Seeing what isn't there -* Showing = Making it all clear +- Looking = Collecting and screening +- Seeing = Selecting and clumping +- Imagining = Seeing what isn't there +- Showing = Making it all clear ### Application @@ -61,18 +59,18 @@ And last but not least, collective design efforts result in hand-drawn, informal Here are some of the tools we use: -* Omnigraffle: informal but pretty. -* Graphviz: not that pretty, but extremely convenient in taking care of the heavy-lifting. -* Google Visualization API: pretty decent, again very convenient for preventing you from having to manually draw the same diagram over and over again. -* Protovis: if you are into automating things, then Protovis draws awesome pictures, but it might be a little harder to use than - say - Google visualizations. -* Raphael: if neither Google nor Protovis support the kind of diagrams you want to generate, Raphael is your next best option. +- Omnigraffle: informal but pretty. +- Graphviz: not that pretty, but extremely convenient in taking care of the heavy-lifting. +- Google Visualization API: pretty decent, again very convenient for preventing you from having to manually draw the same diagram over and over again. +- Protovis: if you are into automating things, then Protovis draws awesome pictures, but it might be a little harder to use than - say - Google visualizations. +- Raphael: if neither Google nor Protovis support the kind of diagrams you want to generate, Raphael is your next best option. ### References 1. The Back of a Napkin, Dan Roam -2. Gapminder, [http://www.gapminder.org/](http://www.gapminder.org/) +2. Gapminder, [https://www.gapminder.org/](https://www.gapminder.org/) 3. Notation and Representation in Collaborative Object-Oriented Design, Uri Dekel and Herbsleb -4. Protovis, [http://vis.stanford.edu/protovis/](http://vis.stanford.edu/protovis/) -5. Google Visualization API, [http://code.google.com/apis/charttools/index.html](http://code.google.com/apis/charttools/index.html) -6. Raphaël, [http://raphaeljs.com/](http://raphaeljs.com/) -7. The Visual Thinking Codex_, Dan Roam, [http://www.thebackofthenapkin.com/pdf/TBOTN_codex.pdf](http://www.thebackofthenapkin.com/pdf/TBOTN_codex.pdf) +4. Protovis, [https://vis.stanford.edu/protovis/](https://vis.stanford.edu/protovis/) +5. Google Visualization API, [https://code.google.com/apis/charttools/index.html](https://code.google.com/apis/charttools/index.html) +6. Raphaël, [https://raphaeljs.com/](https://raphaeljs.com/) +7. The Visual Thinking Codex\_, Dan Roam, [https://www.thebackofthenapkin.com/pdf/TBOTN_codex.pdf](https://www.thebackofthenapkin.com/pdf/TBOTN_codex.pdf) diff --git a/cards/master-your-tools.md b/cards/master-your-tools.md index e46c8f2..cde9c8e 100644 --- a/cards/master-your-tools.md +++ b/cards/master-your-tools.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- Master your tools @@ -11,10 +9,10 @@ Master your tools Expect unprecedented productivity gain when investing time in mastering your tools. Tools will help you to: -* Accelerate -* Focus -* Avoid repetitive tasks -* Eliminate duplication +- Accelerate +- Focus +- Avoid repetitive tasks +- Eliminate duplication Tools include your IDE, commandline tools, desktop tools, editors, etc. @@ -40,13 +38,11 @@ A huge increase in productivity, fewer keystrokes, colleagues who gasp and stamm ### Samples -* Learn the keystrokes for your language IDE by heart. Twice. Master its search and navigation functions. Optimize the syntax highlighting to your preferences. -* As an example of the latter: Eclipse JDT defaults to using italic font for static members and no highlighting for abstract members. Bring these in line with UML and underline your statics, italicize your abstracts. Now you can see an abstract method invocation and know not to press F3 (which uselessly takes you to the declaration), but CTRL-T to take you to an implementation. -* Learn to use at least one command shell and its scripting language for every platform your frequently use. Learn a text editor for that shell. Unix is traditionally stronger than Windows in this area, although Windows PowerShell should not be underestimated. You can mix and match! Bash, vim, wget and xmllint are all avaiable on Microsoft Windows and work perfectly fine. By installing these your can focus your effort on just one type of shell. -* Learn to use SSH login by a private key protected with a passphrase instead of a password entered at shell login. Manage private keys on your workstation using ssh-agent (or pageant). +- Learn the keystrokes for your language IDE by heart. Twice. Master its search and navigation functions. Optimize the syntax highlighting to your preferences. +- As an example of the latter: Eclipse JDT defaults to using italic font for static members and no highlighting for abstract members. Bring these in line with UML and underline your statics, italicize your abstracts. Now you can see an abstract method invocation and know not to press F3 (which uselessly takes you to the declaration), but CTRL-T to take you to an implementation. +- Learn to use at least one command shell and its scripting language for every platform your frequently use. Learn a text editor for that shell. Unix is traditionally stronger than Windows in this area, although Windows PowerShell should not be underestimated. You can mix and match! Bash, vim, wget and xmllint are all avaiable on Microsoft Windows and work perfectly fine. By installing these your can focus your effort on just one type of shell. +- Learn to use SSH login by a private key protected with a passphrase instead of a password entered at shell login. Manage private keys on your workstation using ssh-agent (or pageant). ### References -If you're into vi (a unix text editor), try http://vimgolf.com. - - +If you're into vi (a unix text editor), try https://vimgolf.com. diff --git a/cards/no-anemic-domain-model.md b/cards/no-anemic-domain-model.md index 7fb348a..cf38cd3 100644 --- a/cards/no-anemic-domain-model.md +++ b/cards/no-anemic-domain-model.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Beware of anemic domain models @@ -21,8 +19,6 @@ In **Object Oriented Programming**, an Anemic Domain Model is a program design c It must be noted that "structs and procedures" is itself a perfectly valid software design. It's just not a very good fit for Object Oriented programming languages. -One of the core ideas of the Object Oriented model is to bring code and data together. [Domain-Driven Design](http://en.wikipedia.org/wiki/Domain-driven_design) (a technique described by Eric Evans in [a book](http://www.bol.com/nl/p/domain-driven-design/1001004001984629) of the same name) is a technique that fully embraces this idea. Systems modeled in this way naturally follow the SOLID principles and naturally avoid code duplication. They make the most of the object oriented model. +One of the core ideas of the Object Oriented model is to bring code and data together. [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design) (a technique described by Eric Evans in [a book](https://www.bol.com/nl/p/domain-driven-design/1001004001984629) of the same name) is a technique that fully embraces this idea. Systems modeled in this way naturally follow the SOLID principles and naturally avoid code duplication. They make the most of the object oriented model. There's a middle ground between the two, where an anemic domain model system is improved by bringing some of the behaviour into the domain model. The easiest place to begin is all those utility functions, starting with simple things like validations and formatting rules. Taking these out of the utility classes and pushing them into the model classes makes them easier to find (avoiding accidental duplication) and improves code cohesion. This approach can be a good fit for request processing systems, such as web apps, where embracing a full object oriented domain model might make things harder to parallelize. - - diff --git a/cards/no-broken-windows.md b/cards/no-broken-windows.md index fe09160..0366a77 100644 --- a/cards/no-broken-windows.md +++ b/cards/no-broken-windows.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- No broken windows @@ -46,4 +44,4 @@ Everyone has worked on projects in the past where the technical standard was not ### References -[http://en.wikipedia.org/wiki/Broken_window_theory](http://en.wikipedia.org/wiki/Broken_window_theory) +[https://en.wikipedia.org/wiki/Broken_window_theory](https://en.wikipedia.org/wiki/Broken_window_theory) diff --git a/cards/no-multitasking.md b/cards/no-multitasking.md index 595601a..d436180 100644 --- a/cards/no-multitasking.md +++ b/cards/no-multitasking.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- No multitasking @@ -36,9 +34,6 @@ By focusing your attention on a single task at a time, you'll get more work done ### References -* [The Multitasking Myth (CodingHorror.com)](http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html) -* [Multitasking is impossible (TheTruthYouAlwaysKnew.com)](http://thetruthyoualwaysknew.com/2013/04/21/multitasking-is-impossible-focus-deeply-on-the-task-at-hand/) -* [Why multitasking doesn't work (Forbes.com)](http://www.forbes.com/sites/douglasmerrill/2012/08/17/why-multitasking-doesnt-work/) - - - +- [The Multitasking Myth (CodingHorror.com)](https://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html) +- [Multitasking is impossible (TheTruthYouAlwaysKnew.com)](https://thetruthyoualwaysknew.com/2013/04/21/multitasking-is-impossible-focus-deeply-on-the-task-at-hand/) +- [Why multitasking doesn't work (Forbes.com)](https://www.forbes.com/sites/douglasmerrill/2012/08/17/why-multitasking-doesnt-work/) diff --git a/cards/no-test-no-bugfix.md b/cards/no-test-no-bugfix.md index ee38404..5c9e4c8 100644 --- a/cards/no-test-no-bugfix.md +++ b/cards/no-test-no-bugfix.md @@ -1,17 +1,15 @@ --- - layout: card category: craftsmanship - --- No change without a failing test --- -* Don't fix a bug before you have a broken test -* A feature is only considered done once you have tests for it -* Don't refactor before you have sufficient test coverage +- Don't fix a bug before you have a broken test +- A feature is only considered done once you have tests for it +- Don't refactor before you have sufficient test coverage --- @@ -37,6 +35,6 @@ In a large code base of a longer running project a bug was logged on some parsin ### References -* [On the Effectiveness of Test-first Approach to Programming][oetap] Hakan Erdogmus, National Research Council Canada. +- [On the Effectiveness of Test-first Approach to Programming][oetap] Hakan Erdogmus, National Research Council Canada. -[oetap]: http://www.researchgate.net/publication/3188484_On_the_effectiveness_of_the_test-first_approach_to_programming +[oetap]: https://www.researchgate.net/publication/3188484_On_the_effectiveness_of_the_test-first_approach_to_programming diff --git a/cards/non-functionals.md b/cards/non-functionals.md index 8807061..56b9a4e 100644 --- a/cards/non-functionals.md +++ b/cards/non-functionals.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Deal with non-functionals @@ -39,5 +37,4 @@ Spending time on working out the quality requirements with your product owner is ### References -* [Competitive Engineering](http://books.google.nl/books?id=ejxQF60xVV0C&dq=competitive+engineering&printsec=frontcover&source=bn&hl=nl&ei=UMSATPmeF4L_Ocq-rNIJ&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDAQ6AEwAw#v=onepage&q&f=false), Tom Gilb, 2005 - +- [Competitive Engineering](https://books.google.nl/books?id=ejxQF60xVV0C&dq=competitive+engineering&printsec=frontcover&source=bn&hl=nl&ei=UMSATPmeF4L_Ocq-rNIJ&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDAQ6AEwAw#v=onepage&q&f=false), Tom Gilb, 2005 diff --git a/cards/one-feature-at-a-time.md b/cards/one-feature-at-a-time.md index 0a82c51..6395ec6 100644 --- a/cards/one-feature-at-a-time.md +++ b/cards/one-feature-at-a-time.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- One feature at a time @@ -41,5 +39,5 @@ Instead of having teams that focus on particular architectural layers and tiers, #### References -1. Software by Numbers, Mark Denne and Jane Cleland-Huang, [http://www.softwarebynumbers.org/](http://www.softwarebynumbers.org/) -2. Service Integration at the Presentation Layer, Wilfred Springer, [http://blog.xebia.com/2010/07/21/service-integration-at-the-presentation-layer/](http://blog.xebia.com/2010/07/21/service-integration-at-the-presentation-layer/) +1. Software by Numbers, Mark Denne and Jane Cleland-Huang, [https://www.softwarebynumbers.org/](https://www.softwarebynumbers.org/) +2. Service Integration at the Presentation Layer, Wilfred Springer, [https://blog.xebia.com/2010/07/21/service-integration-at-the-presentation-layer/](https://blog.xebia.com/2010/07/21/service-integration-at-the-presentation-layer/) diff --git a/cards/pair-programming.md b/cards/pair-programming.md index 3772cfb..620bee2 100644 --- a/cards/pair-programming.md +++ b/cards/pair-programming.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- Pair programming @@ -19,22 +17,22 @@ group discussions, documentation and reviews. Let's be honest. Over engineered solutions are strangely attractive. We developers are drawn into it like bugs into a bugzapper. We end up spending way too much time on things we don't even need. That's just wrong. We need somebody to get us back on track. And that's exactly what pair programming is going to give you. > When you pair, one person codes---the driver. The other person is the navigator, whose job is to think. As navigator, sometimes you think about what the driver is typing. (Don't rush to point out missing semicolons, though. That's annoying.) Sometimes you think about what tasks to work on next and sometimes you think about how your work best fits into the overall design. -> This arrangement leaves the driver free to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and it gives the navigator the opportunity to consider strategic issues without being distracted by the details of coding. Together, the driver and navigator create higher-quality work more quickly than either could produce on their own.[1](http://jamesshore.com/Agile-Book/pair_programming.html) +> This arrangement leaves the driver free to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and it gives the navigator the opportunity to consider strategic issues without being distracted by the details of coding. Together, the driver and navigator create higher-quality work more quickly than either could produce on their own.[1](https://jamesshore.com/Agile-Book/pair_programming.html) ### Applicability Okay, there might be a few situations when you need some time alone. But, really, in all other cases, pair programming is applicable. That doesn't mean it's easy though. In fact, for most people, it turns out to be quite painful to say goodbye to their time spent in isolation, as evidenced by the type of response you will get when suggesting pair programming to die-hard alone coders: -* I'm faster on my own -* Can't pair with that colleague, I get nervous -* Pair programming is too tiring -* We've split up the work and we'll get it done faster if we use two keyboards -* There's too much background noise -* I'm just slowing her down +- I'm faster on my own +- Can't pair with that colleague, I get nervous +- Pair programming is too tiring +- We've split up the work and we'll get it done faster if we use two keyboards +- There's too much background noise +- I'm just slowing her down Iwein Fuld wrote a great article on the subject a in 2010, and this is what he said: -> Some of this might sound plausible, so let me axe that down first. No you're not faster on your own, you're just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you'll turn into a better programmer. Or maybe you can teach him something and he'll stop getting on your nerves. If your code is so simple that you can split up the work in advance you're writing it on too low an abstraction level, or you need to work on this in two pairs. If you're slowing the other guy down, that's a good thing. That will prevent him from writing code that you cannot maintain. If you don't feel worthy of your colleagues code, get over it, or get off the team.[2](http://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/) +> Some of this might sound plausible, so let me axe that down first. No you're not faster on your own, you're just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you'll turn into a better programmer. Or maybe you can teach him something and he'll stop getting on your nerves. If your code is so simple that you can split up the work in advance you're writing it on too low an abstraction level, or you need to work on this in two pairs. If you're slowing the other guy down, that's a good thing. That will prevent him from writing code that you cannot maintain. If you don't feel worthy of your colleagues code, get over it, or get off the team.[2](https://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/) In some situations pair programming is not a good fit. Be sure to understand the need for [alone time](alone-time) @@ -42,9 +40,9 @@ In some situations pair programming is not a good fit. Be sure to understand the First of all, you optimize the conditions for pair programming. That could include many things, such as: -* Noise cancellation: if there's too much noise in your environment, if people are bothering you for the wrong things, if there are things that would prevent you from being focused even if you would be working on your own, then you need to fix it. -* Pair programming ergonomics: if you can't pair comfortably, then it's not going to fly. If your navigator is unable to read your screen, then it will fail. Getting another monitor might help. If - in order for the navigator to see the screen - the driver needs to work in a cramped position, it will fail as well. There are certain type of desks that just don't support pair programming at all. Rearrange the office floor to fix it. Make yourself comfortable. -* Pick a style. Iwein lists a number of styles in his article^2^. Pick the right one for the task at hand. +- Noise cancellation: if there's too much noise in your environment, if people are bothering you for the wrong things, if there are things that would prevent you from being focused even if you would be working on your own, then you need to fix it. +- Pair programming ergonomics: if you can't pair comfortably, then it's not going to fly. If your navigator is unable to read your screen, then it will fail. Getting another monitor might help. If - in order for the navigator to see the screen - the driver needs to work in a cramped position, it will fail as well. There are certain type of desks that just don't support pair programming at all. Rearrange the office floor to fix it. Make yourself comfortable. +- Pick a style. Iwein lists a number of styles in his article^2^. Pick the right one for the task at hand. ### Consequences @@ -52,6 +50,5 @@ Pair programming helps you to stay focused on your task and it grows collective ### References -1. James Shore, The Art of Agile Development, 2010, [http://jamesshore.com/Agile-Book/pair_programming.html](http://jamesshore.com/Agile-Book/pair_programming.html) -2. Iwein Fuld, Practical Styles of Pair Programming, 2010, [http://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/](http://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/) - +1. James Shore, The Art of Agile Development, 2010, [https://jamesshore.com/Agile-Book/pair_programming.html](https://jamesshore.com/Agile-Book/pair_programming.html) +2. Iwein Fuld, Practical Styles of Pair Programming, 2010, [https://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/](https://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/) diff --git a/cards/readable-code.md b/cards/readable-code.md index d5ee108..70ac400 100644 --- a/cards/readable-code.md +++ b/cards/readable-code.md @@ -1,8 +1,6 @@ --- - layout: card category: craftsmanship - --- Write code that humans can easily understand @@ -10,9 +8,10 @@ Write code that humans can easily understand --- > Any fool can write code that a computer can understand. Good programmers write -> code that humans can understand. A simple, readable implementation is head and -> shoulders above a clever-but-confusing, look-at-me implementation. Things to +> code that humans can understand. A simple, readable implementation is head and +> shoulders above a clever-but-confusing, look-at-me implementation. Things to > keep in mind are readability, maintainability and speed of development. +> >
Martin Fowler
--- @@ -52,10 +51,9 @@ The overall speed of the development of the project gradually increases if every ### References Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- [Martin Fowler](http://www.softwarequotes.com/showquotes.aspx?id=573&name=Fowler,Martin), Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, don Roberts, ISBN: 0201485672 -Beauty of style and harmony and grace and good rhythm depends on simplicity. — Plato - -[Implementation Patterns](http://www.informit.com/title/0321413091) by Kent Beck +- [Martin Fowler](https://www.softwarequotes.com/showquotes.aspx?id=573&name=Fowler,Martin), Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, don Roberts, ISBN: 0201485672 +Beauty of style and harmony and grace and good rhythm depends on simplicity. — Plato +[Implementation Patterns](https://www.informit.com/title/0321413091) by Kent Beck diff --git a/cards/secure-development.md b/cards/secure-development.md index ea2d80c..0310313 100644 --- a/cards/secure-development.md +++ b/cards/secure-development.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Develop for security @@ -28,4 +26,4 @@ Security is not something that can be bolted on after release, nor is it somethi ### References -There is an enormous amount of literature, tools and online documentation on this subject. The [OWASP project](https://www.owasp.org/index.php/Main_Page) has extensive, free resources and is a good place to start looking. The [Security Development Lifecycle](http://www.microsoft.com/security/sdl/default.aspx) is a system that Microsoft adopted in the mid-2000's to address these concerns at every stage. +There is an enormous amount of literature, tools and online documentation on this subject. The [OWASP project](https://www.owasp.org/index.php/Main_Page) has extensive, free resources and is a good place to start looking. The [Security Development Lifecycle](https://www.microsoft.com/security/sdl/default.aspx) is a system that Microsoft adopted in the mid-2000's to address these concerns at every stage. diff --git a/cards/separation-of-concerns.md b/cards/separation-of-concerns.md index 39c0b27..5841d94 100644 --- a/cards/separation-of-concerns.md +++ b/cards/separation-of-concerns.md @@ -1,8 +1,6 @@ --- - layout: card category: realisation - --- Separation of concerns @@ -10,6 +8,7 @@ Separation of concerns --- > Separate a program into non-overlapping concerns. +> >
Edsger W. Dijkstra
--- @@ -26,7 +25,6 @@ Secondly, when concerns are cleanly separated it's easier to reason about the ap # See also -* [TDD Shapes Design](tdd-shapes-design) -* [Maximize Cohesion, Minimize Coupling](maximize-cohesion-minimize-coupling) -* A [List of Pioneers in Computer Science](http://en.wikipedia.org/wiki/List_of_pioneers_in_computer_science) on Wikipedia. - +- [TDD Shapes Design](tdd-shapes-design) +- [Maximize Cohesion, Minimize Coupling](maximize-cohesion-minimize-coupling) +- A [List of Pioneers in Computer Science](https://en.wikipedia.org/wiki/List_of_pioneers_in_computer_science) on Wikipedia. diff --git a/cards/tdd-shapes-design.md b/cards/tdd-shapes-design.md index 795e906..f30aa01 100644 --- a/cards/tdd-shapes-design.md +++ b/cards/tdd-shapes-design.md @@ -1,8 +1,6 @@ --- - layout: card category: testing - --- Test Driven Development shapes design @@ -34,7 +32,6 @@ This is extremely useful when it comes to writing applications. By performing th 2. Implement the actual (production) code. Only to the extend that the test passes. While writing code you might come up more cases to test. Write those down (e.g. on a piece of paper), we're focused on making the test at hand pass. 3. Tidy up. Make sure your code is ready for the next cycle. Is the code self-descriptive? - ### Application Whenever you're writing an application this approach is applicable. @@ -47,4 +44,4 @@ You'll find out that you have to write less tests and code in general. Since all ### References -[Freeman, Price: Growing Object-Oriented Software, Guided by Tests](http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/) +[Freeman, Price: Growing Object-Oriented Software, Guided by Tests](https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/) diff --git a/cards/test-code-one.md b/cards/test-code-one.md index 11ffea8..ab6e321 100644 --- a/cards/test-code-one.md +++ b/cards/test-code-one.md @@ -1,8 +1,6 @@ --- - layout: card category: testing - --- Think of code and test as one @@ -12,6 +10,7 @@ Think of code and test as one > When writing the code, think of the test. > When writing the test, think of the code. > When you think of code and test as one, testing is easy and code is beautiful. +> >
Testivus
--- @@ -38,4 +37,4 @@ Circling around between test and code might make it harder to define a stop crit ### References -The Way of Testivus - Unit Testing Wisdom From An Ancient Software Start-up, Albert Savoia, [http://www.agitar.com/downloads/TheWayOfTestivus.pdf](http://www.agitar.com/downloads/TheWayOfTestivus.pdf), 2007 +The Way of Testivus - Unit Testing Wisdom From An Ancient Software Start-up, Albert Savoia, [https://www.agitar.com/downloads/TheWayOfTestivus.pdf](https://www.agitar.com/downloads/TheWayOfTestivus.pdf), 2007 diff --git a/cards/tests-are-specs.md b/cards/tests-are-specs.md index 93cbb4f..eb5f815 100644 --- a/cards/tests-are-specs.md +++ b/cards/tests-are-specs.md @@ -1,8 +1,6 @@ --- - layout: card category: testing - --- Tests are Specifications @@ -38,6 +36,4 @@ Your process probably no longer has separate 'waterfall' phases for specificatio ### References -http://www.specificationbyexample.com - - +https://www.specificationbyexample.com diff --git a/cards/the-zone.md b/cards/the-zone.md index fbf173c..e8e0b49 100644 --- a/cards/the-zone.md +++ b/cards/the-zone.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- Respect the zone @@ -39,14 +37,12 @@ The most important thing is to let developers be in a bubble that is not often p Team moral will go up when an atmosphere is created where zoning in is allowed and encouraged. Productivity will go up. When team zoning happens problems are much less often discarded as unsolvable. Symptoms that can be seen on the outside are: -* constant soft chatter between developers -* people moving around from desk to desk -* more joking and laughter -* increased use of non digital tooling (whiteboards, paper, gesturing, role play) +- constant soft chatter between developers +- people moving around from desk to desk +- more joking and laughter +- increased use of non digital tooling (whiteboards, paper, gesturing, role play) ### References -* [Pair Programming](pair-programming) -* [Google Scholar: Csíkszentmihályi flow](http://scholar.google.com/scholar?hl=en&q=Cs%C3%ADkszentmih%C3%A1lyi+flow&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0) - - +- [Pair Programming](pair-programming) +- [Google Scholar: Csíkszentmihályi flow](https://scholar.google.com/scholar?hl=en&q=Cs%C3%ADkszentmih%C3%A1lyi+flow&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0) diff --git a/cards/what-you-measure.md b/cards/what-you-measure.md index ce957dc..7457e1b 100644 --- a/cards/what-you-measure.md +++ b/cards/what-you-measure.md @@ -1,8 +1,6 @@ --- - layout: card category: collaboration - --- You get what you measure @@ -15,13 +13,13 @@ This effect is magnified when the carrot or the stick is involved, such as a tar --- -Whenever you introduce some sort of [visible metric](make-it-visible), like Code Coverage Analysis or a [Sonar](http://sonarqube.org/) violations count, you introduce a pressure to improve that metric. You can multiply the effect by setting a goal or KPI or cash bonus on achieving some sort of target value. Worse still, you can set a penalty on not reaching that target value. Goals and target values are pretty arbitrary anyway. Sure, 80% coverage is better than 78%, but why not aim for 82? +Whenever you introduce some sort of [visible metric](make-it-visible), like Code Coverage Analysis or a [Sonar](https://sonarqube.org/) violations count, you introduce a pressure to improve that metric. You can multiply the effect by setting a goal or KPI or cash bonus on achieving some sort of target value. Worse still, you can set a penalty on not reaching that target value. Goals and target values are pretty arbitrary anyway. Sure, 80% coverage is better than 78%, but why not aim for 82? The greater you make this pressure, the more you run the risk of (a) people gaming the system and (b) people over-optimizing to the detriment of aspects unmeasured. Your metric may end up doing more harm than good. All this notwithstanding, metrics and measurement are generally good things. They're a useful tool for [improving](improve-continuously) your software development practice, or indeed any other. To avoid these pitfalls: -* pick a range of complementary metrics, to avoid too narrow a focus -* be honest about whether any metrics improvement is of actual benefit or just window-dressing -* periodically reevaluate whether you're still measuring the right things -* aim for an improving trend in all metrics, rather than specific threshold values. +- pick a range of complementary metrics, to avoid too narrow a focus +- be honest about whether any metrics improvement is of actual benefit or just window-dressing +- periodically reevaluate whether you're still measuring the right things +- aim for an improving trend in all metrics, rather than specific threshold values. diff --git a/src/layouts/Banner.vue b/src/layouts/Banner.vue index 41c8a0f..066d02b 100644 --- a/src/layouts/Banner.vue +++ b/src/layouts/Banner.vue @@ -6,7 +6,7 @@ Software Development Done Right. You can get your own deck of Essentials cards in the Xebia store (sold out).

Buy Now