README.md in gush-0.1.2 vs README.md in gush-0.2.0

- old
+ new

@@ -61,11 +61,11 @@ #### Passing parameters to jobs You can pass any primitive arguments into jobs while defining your workflow: ```ruby -# workflows/sample_workflow.rb +# app/workflows/sample_workflow.rb class SampleWorkflow < Gush::Workflow def configure run FetchJob1, params: { url: "http://some.com/url" } end end @@ -76,11 +76,12 @@ #### Defining jobs Jobs are classes inheriting from `Gush::Job`: ```ruby -class FetchJob1 < Gush::Job +# app/jobs/fetch_job.rb +class FetchJob < Gush::Job def work # do some fetching from remote APIs params #=> {url: "http://some.com/url"} end @@ -95,11 +96,11 @@ `configure` method. Here's an example of a workflow responsible for publishing a book: ```ruby -# workflows/sample_workflow.rb +# app/workflows/sample_workflow.rb class PublishBookWorkflow < Gush::Workflow def configure(url, isbn) run FetchBook, params: { url: url } run PublishBook, params: { book_isbn: isbn } end @@ -180,11 +181,11 @@ ``` `payloads` is a hash containing outputs from all parent jobs, where job class names are the keys. **Note:** `payloads` will only contain outputs of the job's ancestors. So if job `A` depends on `B` and `C`, -the `paylods` hash will look like this: +the `payloads` hash will look like this: ```ruby { "B" => (...), "C" => (...) @@ -197,11 +198,11 @@ #### In Ruby: ```ruby flow.reload flow.status -#=> :running|:pending|:finished|:failed +#=> :running|:finished|:failed ``` `reload` is needed to see the latest status, since workflows are updated asynchronously. #### Via CLI: @@ -237,10 +238,10 @@ - [Mateusz Lenik](https://github.com/mlen) - [Michał Krzyżanowski](https://github.com/krzyzak) ## Contributing -1. Fork it ( http://github.com/pokonski/gush/fork ) +1. Fork it ( http://github.com/chaps-io/gush/fork ) 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create new Pull Request