README.md in chaotic_job-0.1.0 vs README.md in chaotic_job-0.1.1

@@ -113,13 +113,13 @@
 > The `ChaoticJob::Journal` class is a simple class that you can use to log things happening. It is used here to track the behavior of the job. It's has a lean, but highly useful, interface:
 > |method|description|
 > |---|---|
 > | `Journal.log` | log simply that something happened within the default scope |
 > | `Journal.log(thing, scope: :special)` | log a particular value within a particular scope |
-> | `Journal.total` | get the total number of logs under the default scope |
-> | `Journal.total(scope: :special)` | get the total number of logs under a particular scope |
-> | `Journal.all` | get all of the logged values under the default scope |
-> | `Journal.all(scope: :special)` | get all of the logged values under a particular scope |
+> | `Journal.size` | get the total number of logs under the default scope |
+> | `Journal.size(scope: :special)` | get the total number of logs under a particular scope |
+> | `Journal.entries` | get all of the logged values under the default scope |
+> | `Journal.entries(scope: :special)` | get all of the logged values under a particular scope |
 
 In this example, the job being tested is defined within the test case. You can, of course, also test jobs defined in your application. The key detail is the `glitch` keyword argument. A "glitch" is simply a tuple that describes precisely where you would like the failure to occur. The first element of the tuple is the location of the glitch, which can be either *before* or *after*. The second element is the location of the code that will be affected by the glitch, defined by its file path and line number. What this example scenario does is inject a glitch before the `step_3` method is called, here:
 
 ```ruby
 def perform