- TDD by its own CANNOT leads to good design, obviously
- TDD as a mechanism to help us to learn more about good design
- Software is "Soft" just because it can be changed, it is not meant to be settled in the stone
- Test-first programming can help the team to reduce defects but it will not lead to good design
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
- Does the design expect failures to happen regularly and handle them gracefully?
- Have we kept things as simple as possible?
Goal of this Document / Gist is to layout the resources and challenges to writing a complete modern web app with Phoenix and Elixir as the state of the projects are starting on June 2015
- [Why Phoenix and not Rails or Node.js?](#Why Phoenix and not Rails or Node.js?)
- Main Resources
- Common Application Requirements
- Authentication
grep -h "<testcase" `find . -iname "TEST-*.xml"` | sed 's/<testcase name="\(.*\)" classname="\(.*\)" time="\(.*\)".*/\3\t\2.\1/' | sort -rn | head
Continuous Integration (CI) is an important practice every team should adopt in order to detect defects and errors early and solve integration problems easily. Roughly speaking we may say that CI is a practice that allows the growth of solid software by giving greater confidence to the developers and better products to the final customers.
The concept behind CI is fairly simple: the codebase is owned by several developers that continuously integrate their changes to a common version control system. For each integration the system runs a predefined set of tasks automatically; these tasks may vary from running all the tests to building all the components.