List of Figures
Figure 1.1. For our graph, we will build a simple domain model: products will have purchases, which belong to the stores where they happened.
Figure 1.2. Our finished graph: in about 40 lines of code, we pulled data from the database, processed it, and graphed it in a rather attractive fashion.
Figure 1.3. Some languages create a gulf between your ideas and working code.
Figure 1.4. Ideas can more closely match the resulting code if your expertise and perspective create an overlap between the framing of an idea and the real code that will execute it.
Figure 1.5. Ruby can be bent to your problem domain, making the overlap between your problem domain and real code significant.
Figure 2.1. Test-driven development is a five-step process: add, fail, code, test, refactor.
Figure 2.2. Test suites are composed of a collection of unit tests that are run one by one by a test runner.
Figure 2.3. The behavior-driven development process starts with specification, adds tests, and builds an implementation that matches the specification and passes the tests.
Figure 2.4. An HTML report showing successful, failing, and pending specifications
Figure 2.5. A stubbed class will seem to act like the real object but won’t actually behave like it. In this case, the stub doesn’t grab data from a remote service, but to the code consuming the API, it appears to.
Figure 2.6. The rcov tool presents its results as HTML or text; the HTML view has nice graphs that illustrate code coverage and individual pages for each file tested.
Figure 4.1. The output from our syntax highlighting library
Figure 5.1. Simple task manager service
Figure 10.1. A graphical representation of the calculator XML document. Element nodes are represented by rounded rectangles, attributes by squared rectangles, and text nodes by bubbles.
Figure 13.1. Ruport’s PDF output
Figure 13.2. The PDF output from our Purchase Notes renderer and formatter
Figure 13.3. Row-based PDF output