├── .gitignore ├── .ruby-version ├── Gemfile ├── Gemfile.lock ├── README ├── _config.yml ├── _css └── tailwind.css ├── _includes ├── book_cta.html ├── disqus.html ├── footer.html ├── header.html ├── nav.html ├── referrals.html ├── sidebar.html └── social.html ├── _layouts ├── default.html ├── main.html ├── post.html ├── tags.html └── wide.html ├── _plugins └── ext.rb ├── _posts ├── 2010-05-19-bootstrapping-a-rails-app.markdown ├── 2010-05-22-bootstrapping-rails-template.markdown ├── 2010-05-25-nifty-generators.markdown ├── 2010-05-27-nifty-config.markdown ├── 2010-06-01-nifty-scaffold.markdown ├── 2010-06-03-ruby-toolbox.markdown ├── 2010-06-06-rails-authentication-options.markdown ├── 2010-06-08-hacking-restful-authentication.markdown ├── 2010-06-10-rails-footnotes.markdown ├── 2010-06-16-authorization-restful-acl-1.markdown ├── 2010-06-19-rails-template-generator.markdown ├── 2010-06-21-authorization-restful-acl-2.markdown ├── 2010-06-24-authorization-restful-acl-3.markdown ├── 2010-06-28-rvm-gemsets-rails3.markdown ├── 2010-07-05-intermediate-rails-steps.markdown ├── 2010-07-08-authenticated-attachments-paperclip-rails.markdown ├── 2010-07-13-nested-routes-controllers.markdown ├── 2010-07-18-understanding-rest-and-routes.markdown ├── 2010-07-23-rails-command-line.markdown ├── 2010-07-28-free-ruby-rails-books.markdown ├── 2010-07-30-nifty-generators-rails-3.markdown ├── 2010-08-04-more-free-ruby-rails-books.markdown ├── 2010-08-11-ruby-date-time-parsing-chronic.markdown ├── 2010-08-22-mobile-rails-1.markdown ├── 2010-08-29-mobile-rails-2.markdown ├── 2010-09-13-rvm-project-gemsets.markdown ├── 2010-09-27-rails-refactoring-tools.markdown ├── 2010-10-16-rails-documentation-tools.markdown ├── 2010-11-09-jquery-mobile-rails-devise.markdown ├── 2010-11-16-rails-ancestry-tree.markdown ├── 2010-12-07-clean-urls-seo-rails.markdown ├── 2010-12-17-rails-admin-panel.markdown ├── 2011-01-11-beginning-rails-testing.markdown ├── 2011-01-19-learning-ruby-rails.markdown ├── 2011-01-25-passenger-3-rvm.markdown ├── 2011-02-28-rails-3-application-templates.markdown ├── 2011-03-11-rails-obfuscated-urls-friendly-id.markdown ├── 2011-04-03-simple-rails-project-backups.markdown ├── 2011-04-28-rails-try-method.markdown ├── 2011-05-08-rails-3.1-beta-rvm.markdown ├── 2011-05-26-rails-smtp-development.markdown ├── 2011-06-16-rails-form-cancel-links.markdown ├── 2011-09-07-rails-contact-form.markdown ├── 2011-09-16-rails-legacy-data-migration-trucker.markdown ├── 2011-09-21-rails-authentication.markdown ├── 2011-10-06-rails-authorization.markdown ├── 2011-11-11-active-admin.markdown ├── 2011-12-11-legacy-data-migrations-rails.markdown ├── 2012-03-12-testing-series-intro.markdown ├── 2012-03-12-testing-series-rspec-setup.markdown ├── 2012-03-19-testing-series-rspec-models-factory-girl.markdown ├── 2012-04-07-testing-series-rspec-controllers.markdown ├── 2012-04-24-testing-series-rspec-requests.markdown ├── 2012-05-07-everyday-rails-rspec-book-available.markdown ├── 2012-05-15-rspec-book-update.markdown ├── 2012-06-13-rspec-book-complete.markdown ├── 2012-07-31-rails-admin-panel-from-scratch.markdown ├── 2012-08-03-rspec-book-updates.markdown ├── 2012-08-07-rails-admin-panel-from-scratch-2.markdown ├── 2012-08-19-rails-admin-panel-from-scratch-3.markdown.markdown ├── 2012-09-11-bundler-rails-specify-versions.markdown ├── 2012-11-14-rspec-book-news.markdown ├── 2013-02-13-rspec-book-updates-capybara.markdown ├── 2013-03-21-rails-rescue-1-setup.markdown ├── 2013-04-16-rails-rescue-2-testing.markdown ├── 2013-04-24-rspec-book-updates.markdown ├── 2013-05-20-obfuscated-data-screenshots.markdown ├── 2013-07-16-july-2013-book-updates.markdown ├── 2013-08-21-rspec-book-rails-4-final-release-notes.markdown ├── 2013-09-09-rspec-book-chinese-translation.markdown ├── 2013-11-15-i-wrote-a-view-spec.markdown ├── 2014-01-15-outside-in-example-ruby-tapas.markdown ├── 2014-01-25-rspec-rails-3-2-edition-free-extra.markdown ├── 2014-02-08-everyday-rails-rspec-japanese.markdown ├── 2014-02-27-git-reset-clean.markdown ├── 2014-04-03-rspec-book-updates-spring-2014.markdown ├── 2014-10-05-rspec-3-book-update.markdown ├── 2014-12-23-simple-data-dump-restore-yamldb.markdown ├── 2015-01-27-rspec-switch-selenium-poltergeist.markdown ├── 2015-02-17-pronto-ruby-code-review.markdown ├── 2015-04-05-rspec-assigns-rails-testing.markdown ├── 2015-07-29-deep-cloning.markdown ├── 2015-08-09-redesign-2015-notes.markdown ├── 2015-08-27-atom-package-rspec.markdown ├── 2016-01-23-clearance-rails-authentication.markdown ├── 2016-04-18-rails-documentation-practices.markdown ├── 2016-08-29-replace-rspec-controller-tests.markdown ├── 2016-09-05-replace-rspec-controller-tests.markdown ├── 2016-12-05-rspec-book-rails-5.markdown ├── 2016-12-12-rails-security-essentials.markdown ├── 2017-01-02-git-command-line-log-search.markdown ├── 2017-01-09-rails-https-only-lets-encrypt-ssl.markdown ├── 2017-01-16-code-review-mindset.markdown ├── 2017-01-23-your-rails-code-base.markdown ├── 2017-02-20-book-status-report-february-2017.markdown ├── 2017-03-01-rails-5-app-documentation.markdown ├── 2017-06-20-rspec-book-2017-updates.markdown ├── 2017-10-19-rspec-book-2017-complete.markdown ├── 2017-11-20-replace-rspec-controller-tests.markdown ├── 2017-12-18-ruby-upgrade-guide-for-rails.markdown ├── 2018-01-08-rspec-3.7-system-tests.markdown ├── 2018-03-23-rails-spec-coverage-simplecov.markdown ├── 2018-04-21-rspec-book-status-spring-2018.markdown ├── 2018-06-11-bundler-shortcuts.markdown ├── 2018-07-18-ruby-podcasts.markdown ├── 2018-08-22-rspec-book-updates-august-2018.markdown ├── 2019-02-18-rails-sql-requirements.markdown ├── 2019-04-09-chromedriver-helper-webdrivers.markdown ├── 2019-07-09-when-tdd-is-hard.markdown ├── 2020-04-15-rspec-book-price-changes.markdown ├── 2020-05-11-working-with-legacy-rails-application.markdown ├── 2020-05-18-everyday-rails-10th-birthday.markdown ├── 2020-05-25-newsletters-for-rails-developers.markdown ├── 2020-06-08-rspec-retry-intermittent-failures.markdown ├── 2020-06-22-rails-routes-helpers-grammar.markdown ├── 2020-07-06-modular-rails-templates-rails-bytes.markdown ├── 2020-08-10-rails-log-message-testing-rspec.markdown ├── 2020-08-24-deliberate-learning-1.markdown ├── 2020-09-17-redesign-2020-notes.markdown ├── 2020-09-20-command-line-alternatives.markdown ├── 2020-12-03-plausible-analytics.markdown ├── 2021-02-14-docker-devcontainer-series-intro.markdown ├── 2021-02-21-docker-devcontainer-series-setup.markdown ├── 2021-02-28-rails-db-setup-persist-data.markdown ├── 2021-03-07-docker-devcontainer-series-database-sqlite.markdown ├── 2021-03-14-docker-devcontainer-series-docker-compose.markdown ├── 2021-04-05-rspec-tutorial-mimemagic-fix.markdown ├── 2021-05-29-pronto-github-actions-code-quality.markdown ├── 2021-07-31-rails-custom-deprecation-warnings.markdown ├── 2023-06-26-rails-tdd-copilot-chatgpt.markdown ├── 2023-09-05-dev-containers-best-practices.markdown ├── 2023-12-07-rspec-resilient-matchers.markdown ├── 2024-01-14-github-actions-devcontainer-ci.markdown ├── 2024-02-06-rspec-book-announcement-rails-7-1.markdown ├── 2024-02-24-rails-just-commands.markdown ├── 2024-03-13-migrate-minitest-to-rspec-copilot.markdown ├── 2024-05-04-rspec-book-status-may-2024.markdown ├── 2024-05-20-railsconf-book-discount-2024.markdown ├── 2024-06-01-replacing-system-tests-with-unit-tests.markdown ├── 2024-07-21-rspec-book-july-2024-announcement.markdown ├── 2024-09-04-rspec-book-september-2024-announcement.markdown ├── 2024-10-10-rspec-book-october-2024-announcement.markdown ├── 2024-11-26-rspec-book-november-2024.markdown ├── 2024-12-29-rspec-book-december-2024-announcement.markdown ├── 2025-01-07-aider-ai-dev-container.markdown ├── 2025-03-09-dotfiles-gh-extensions.md ├── 2025-04-05-rspec-book-april-2025-announcement.md ├── 2025-04-15-old-ruby-rails-dev-container.md └── 2025-05-18-happy-birthday.md ├── about.markdown ├── apple-icon-114x114-precomposed.png ├── apple-icon-144x144-precomposed.png ├── apple-icon-57x57-precomposed.png ├── apple-icon-72x72-precomposed.png ├── archives.html ├── atom.xml ├── blm.markdown ├── config.rb ├── contact.html ├── css └── tomorrow-night.css ├── images ├── banner.png ├── box.png ├── ccheart_black.svg ├── hover.png ├── linode.png ├── logo-2020.svg ├── logo-small.png ├── logo-square.png ├── mug2022.jpg ├── posts │ ├── astoria-sunset.jpg │ ├── atom-header.jpg │ ├── brakeman.png │ ├── docker │ │ ├── boxes.jpg │ │ └── ruby-box.jpg │ ├── git-log-header-large.jpg │ ├── hacker-cat.jpg │ ├── legacy-intro-header.jpg │ ├── letsencrypt-logo-horizontal.svg │ ├── pronto-github-actions.png │ ├── sad-mac.png │ ├── simplecov-header.jpg │ └── thumbs-up.jpg ├── rspec-book-2024-xl.jpg ├── rspec-book-xl.jpg ├── rspec_book.jpg ├── rspec_book_large.jpg └── rspec_book_med.jpg ├── img ├── glyphicons-halflings-white.png └── glyphicons-halflings.png ├── index.html ├── js ├── bootstrap.js ├── bootstrap.min.js ├── jquery.min.js └── npm.js ├── justfile ├── mise.toml ├── missing.markdown ├── package-lock.json ├── package.json ├── postcss.config.js ├── rspecbook ├── code.zip ├── everydayrailsrspec-5.1.zip └── index.markdown ├── tailwind.config.js └── thanks.html /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | _site/* 3 | .sass-cache/* 4 | .rvmrc 5 | _tasks/deploy 6 | .rvmrc 7 | googlehostedservice.html 8 | ads.html 9 | bottom_ads.html 10 | _drafts/* 11 | node_modules/* 12 | tmp/* 13 | css/tailwind.css 14 | -------------------------------------------------------------------------------- /.ruby-version: -------------------------------------------------------------------------------- 1 | ruby-3.1.6 2 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | gem "jekyll", "~> 4.4" 4 | gem "rouge" 5 | gem "kramdown-parser-gfm" 6 | gem "webrick" 7 | 8 | group :jekyll_plugins do 9 | gem "jekyll-tagging", 10 | git: "https://github.com/everydayrails/jekyll-tagging", 11 | branch: "allow-posts-with-no-tags" 12 | gem "jekyll-gist" 13 | end 14 | -------------------------------------------------------------------------------- /Gemfile.lock: -------------------------------------------------------------------------------- 1 | GIT 2 | remote: https://github.com/everydayrails/jekyll-tagging 3 | revision: 46dd035ae0c6bfa4cd2b123e139db9fe04a10721 4 | branch: allow-posts-with-no-tags 5 | specs: 6 | jekyll-tagging (1.1.0) 7 | nuggets 8 | 9 | GEM 10 | remote: https://rubygems.org/ 11 | specs: 12 | addressable (2.5.2) 13 | public_suffix (>= 2.0.2, < 4.0) 14 | base64 (0.2.0) 15 | bigdecimal (3.1.9) 16 | colorator (1.1.0) 17 | concurrent-ruby (1.3.5) 18 | csv (3.3.2) 19 | em-websocket (0.5.3) 20 | eventmachine (>= 0.12.9) 21 | http_parser.rb (~> 0) 22 | eventmachine (1.2.7) 23 | faraday (0.17.6) 24 | multipart-post (>= 1.2, < 3) 25 | ffi (1.17.1) 26 | forwardable-extended (2.6.0) 27 | google-protobuf (4.29.3) 28 | bigdecimal 29 | rake (>= 13) 30 | http_parser.rb (0.8.0) 31 | i18n (1.14.7) 32 | concurrent-ruby (~> 1.0) 33 | jekyll (4.4.1) 34 | addressable (~> 2.4) 35 | base64 (~> 0.2) 36 | colorator (~> 1.0) 37 | csv (~> 3.0) 38 | em-websocket (~> 0.5) 39 | i18n (~> 1.0) 40 | jekyll-sass-converter (>= 2.0, < 4.0) 41 | jekyll-watch (~> 2.0) 42 | json (~> 2.6) 43 | kramdown (~> 2.3, >= 2.3.1) 44 | kramdown-parser-gfm (~> 1.0) 45 | liquid (~> 4.0) 46 | mercenary (~> 0.3, >= 0.3.6) 47 | pathutil (~> 0.9) 48 | rouge (>= 3.0, < 5.0) 49 | safe_yaml (~> 1.0) 50 | terminal-table (>= 1.8, < 4.0) 51 | webrick (~> 1.7) 52 | jekyll-gist (1.5.0) 53 | octokit (~> 4.2) 54 | jekyll-sass-converter (3.1.0) 55 | sass-embedded (~> 1.75) 56 | jekyll-watch (2.2.1) 57 | listen (~> 3.0) 58 | json (2.9.1) 59 | kramdown (2.3.1) 60 | rexml 61 | kramdown-parser-gfm (1.1.0) 62 | kramdown (~> 2.0) 63 | liquid (4.0.4) 64 | listen (3.9.0) 65 | rb-fsevent (~> 0.10, >= 0.10.3) 66 | rb-inotify (~> 0.9, >= 0.9.10) 67 | mercenary (0.4.0) 68 | multipart-post (2.3.0) 69 | nuggets (1.6.0) 70 | octokit (4.9.0) 71 | sawyer (~> 0.8.0, >= 0.5.3) 72 | pathutil (0.16.2) 73 | forwardable-extended (~> 2.6) 74 | public_suffix (3.1.1) 75 | rake (13.2.1) 76 | rb-fsevent (0.11.2) 77 | rb-inotify (0.11.1) 78 | ffi (~> 1.0) 79 | rexml (3.2.5) 80 | rouge (3.27.0) 81 | safe_yaml (1.0.5) 82 | sass-embedded (1.83.4) 83 | google-protobuf (~> 4.29) 84 | rake (>= 13) 85 | sawyer (0.8.1) 86 | addressable (>= 2.3.5, < 2.6) 87 | faraday (~> 0.8, < 1.0) 88 | terminal-table (3.0.2) 89 | unicode-display_width (>= 1.1.1, < 3) 90 | unicode-display_width (2.6.0) 91 | webrick (1.8.1) 92 | 93 | PLATFORMS 94 | ruby 95 | 96 | DEPENDENCIES 97 | jekyll (~> 4.4) 98 | jekyll-gist 99 | jekyll-tagging! 100 | kramdown-parser-gfm 101 | rouge 102 | webrick 103 | 104 | BUNDLED WITH 105 | 2.2.33 106 | -------------------------------------------------------------------------------- /README: -------------------------------------------------------------------------------- 1 | Everyday Rails is a blog about getting stuff done with Ruby on Rails. This 2 | is the source code for the blog, which is created with the Jekyll static 3 | site framework/generator. 4 | 5 | ## CSS 6 | 7 | CSS is build using Tailwind CSS, with some overriding layers to handle tags 8 | generated by the Jekyll CMS layer outlined in `tailwind.config.js`. Rebuild 9 | CSS after editing Tailwind configs by running 10 | 11 | ``` 12 | npm run build 13 | ``` 14 | 15 | In production, unused Tailwind styles are purged as part of the Netlify build 16 | process (`NODE_ENV=production npm run build && jekyll build`). 17 | 18 | Copyright (c) 2010 Aaron Sumner 19 | 20 | Permission is hereby granted, free of charge, to any person obtaining a copy 21 | of this software and associated documentation files (the "Software"), to deal 22 | in the Software without restriction, including without limitation the rights 23 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 24 | copies of the Software, and to permit persons to whom the Software is 25 | furnished to do so, subject to the following conditions: 26 | 27 | The above copyright notice and this permission notice shall be included in 28 | all copies or substantial portions of the Software. 29 | 30 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 31 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 32 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 33 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 34 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 35 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 36 | THE SOFTWARE. 37 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | destination: ./_site 2 | lsi: false 3 | port: 4000 4 | markdown: kramdown 5 | highlighter: rouge 6 | kramdown: 7 | input: GFM 8 | syntax_highlighter_opts: 9 | default_lang: html 10 | css_class: "highlight" 11 | permalink: date 12 | feed: http://feeds.feedburner.com/EverydayRails 13 | twitter: http://twitter.com/everydayrails 14 | facebook: http://facebook.com/everydayrails 15 | exclude: 16 | [ 17 | node_modules, 18 | scss, 19 | tmp, 20 | .ruby-version, 21 | Gemfile, 22 | Gemfile.lock, 23 | drafts, 24 | public, 25 | src, 26 | mise.toml, 27 | ] 28 | tag_page_layout: tags 29 | tag_page_dir: tag 30 | plugins: [jekyll-gist] 31 | -------------------------------------------------------------------------------- /_css/tailwind.css: -------------------------------------------------------------------------------- 1 | @tailwind base; 2 | @tailwind components; 3 | @tailwind utilities; 4 | 5 | @layer base { 6 | h1 { 7 | @apply text-4xl font-semibold mt-10; 8 | } 9 | 10 | h2 { 11 | @apply text-xl font-semibold mt-10; 12 | } 13 | 14 | h3 { 15 | @apply text-lg font-semibold mt-10; 16 | } 17 | 18 | h4 { 19 | @apply font-semibold; 20 | } 21 | 22 | p { 23 | @apply mt-5; 24 | } 25 | 26 | a { 27 | @apply text-red-900 underline; 28 | } 29 | 30 | pre { 31 | @apply my-5 p-3 bg-gray-800 text-gray-200 rounded overflow-scroll; 32 | } 33 | 34 | ul { 35 | @apply list-disc my-5; 36 | } 37 | 38 | ol { 39 | @apply list-decimal my-5; 40 | } 41 | 42 | li { 43 | @apply my-2 ml-5; 44 | } 45 | 46 | blockquote { 47 | @apply p-5 text-gray-800 mt-3 mb-3; 48 | } 49 | 50 | #tags a { 51 | @apply pr-3; 52 | } 53 | 54 | .decoration { 55 | @apply float-right; 56 | } 57 | 58 | .alert { 59 | @apply mt-5 p-5 rounded-lg; 60 | } 61 | 62 | .alert p:first-child { 63 | @apply mt-0; 64 | } 65 | 66 | .alert ul:last-child { 67 | @apply mt-0; 68 | } 69 | 70 | .alert-info { 71 | @apply bg-green-200 text-green-800; 72 | } 73 | 74 | .alert-danger { 75 | @apply bg-red-200 text-red-800; 76 | } 77 | 78 | .alert-warning { 79 | @apply bg-orange-100 text-orange-800; 80 | } 81 | } 82 | -------------------------------------------------------------------------------- /_includes/book_cta.html: -------------------------------------------------------------------------------- 1 |
2 | 3 |

Rails testing made simple

4 |

5 | Learn to test Rails apps the way 6 | I learned, building up tests step-by-step, in 7 | Everyday Rails Testing 8 | with RSpec. 9 | Expanded to include exclusive content and a complete sample Rails application. 10 | 11 | Learn more » 12 |

13 |
-------------------------------------------------------------------------------- /_includes/disqus.html: -------------------------------------------------------------------------------- 1 |
2 | 12 | 13 | blog comments powered by Disqus 14 | -------------------------------------------------------------------------------- /_includes/footer.html: -------------------------------------------------------------------------------- 1 | 19 | -------------------------------------------------------------------------------- /_includes/header.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | {% if page.title %} 11 | {{ page.title }} | 12 | {% endif %} 13 | Everyday Rails 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | -------------------------------------------------------------------------------- /_includes/nav.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | Everyday Rails 4 |
5 | 13 |
14 | -------------------------------------------------------------------------------- /_includes/referrals.html: -------------------------------------------------------------------------------- 1 |
2 |

Affiliate links

3 | 4 |

5 | Do me a favor and support these great companies. Sign up through these 6 | links to help keep Everyday Rails going. Thanks for your support. 7 |

8 | 9 |

10 | 11 | Linode 12 | is my preferred cloud hosting provider for Everyday Rails and other 13 | projects. Fast, SSD-based servers, great uptime, and awesome tooling and 14 | support. 15 |

16 | 17 |

18 | 19 | I use Hover for my 20 | domain name registry and DNS management. They're simple, affordable, 21 | reliable, and ethical. 22 |

23 |
-------------------------------------------------------------------------------- /_includes/sidebar.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

Test with confidence!

4 |
5 | 6 |

7 | If you liked my series on practical advice for adding reliable tests to 8 | your Rails apps, check out the expanded ebook version. Lots of 9 | additional, exclusive content and a complete sample Rails application. 10 |

11 |
12 | Start testing now 13 |
14 |
15 |
16 | 17 |
18 |

Newsletter

19 |
20 |

21 | Ruby on Rails news and tips, and other ideas and surprises from Aaron at 22 | Everyday Rails. Delivered to your inbox on no particular set schedule. 23 |

24 |
25 | Subscribe now for free 26 |
27 |
28 |
29 | 30 |
31 |

Tags

32 |
33 | {{ site | tag_cloud }} 34 |
35 |
36 |
37 | -------------------------------------------------------------------------------- /_includes/social.html: -------------------------------------------------------------------------------- 1 |

Discussion

2 | 3 | 12 | 13 |
14 | Follow along on on 15 | Mastodon or 16 | Bluesky 17 | to keep up-to-date with my latest posts. Better yet, 18 | subscribe to my newsletter for updates 19 | from Everyday Rails, book picks, and other thoughts and ideas that didn't 20 | quite fit here. 21 |
22 | -------------------------------------------------------------------------------- /_layouts/default.html: -------------------------------------------------------------------------------- 1 | {% include header.html %} 2 | 3 | 4 | {% include nav.html %} 5 | 6 |
7 |
8 |
9 |

{{ page.title }}

10 | 11 | {{ content }} 12 |
13 | {% include sidebar.html %} 14 |
15 | {% include footer.html %} 16 |
17 | 18 | 19 | -------------------------------------------------------------------------------- /_layouts/main.html: -------------------------------------------------------------------------------- 1 | {% include header.html %} 2 | 3 | 4 | {% include nav.html %} 5 | 6 |
7 |
8 |
9 | {{ content }} 10 |
11 | {% include sidebar.html %} 12 |
13 | {% include footer.html %} 14 |
15 | 16 | 17 | -------------------------------------------------------------------------------- /_layouts/post.html: -------------------------------------------------------------------------------- 1 | {% include header.html %} 2 | 3 | 4 | {% include nav.html %} 5 | 6 |
7 |
8 |
9 | {% if page.image %} 10 |
11 | 12 |
13 | {% endif %} 14 | 15 |

{{ page.title }}

16 | 17 |
18 | By Aaron Sumner, 19 | {{ page.date | date: "%B %d, %Y" }}. 20 | {% assign t = page | tags %} 21 | {% if t.size > 0 %} 22 | File under: {{ page | tags }}. 23 | {% endif %} 24 |
25 | 26 | {{ content }} 27 | 28 | {% include social.html %} 29 |
30 | {% include sidebar.html %} 31 |
32 | {% include footer.html %} 33 |
34 | 35 | 36 | -------------------------------------------------------------------------------- /_layouts/tags.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 |

Articles tagged {{ page.tag }}

5 | 6 | {% for post in page.posts %} 7 |
8 |

{{ post.title }}

9 | 10 | {{ post.excerpt }} 11 | 12 | ({{ post.date | date: "%B %d, %Y" }}) 13 | 14 |
15 | {% endfor %} 16 | 17 | -------------------------------------------------------------------------------- /_layouts/wide.html: -------------------------------------------------------------------------------- 1 | {% include header.html %} 2 | 3 |
4 |
5 |
6 |
7 |

A practical guide to testing in Rails

8 |

9 | If you've checked out other books and resources on testing in 10 | Rails, but still haven't made testing a regular habit as you code, 11 | Everyday Rails Testing with RSpec might be the book for you. 12 | Now updated for Now updated for Rails 4.0, 13 | Capybara 2.1, Factory Girl 4.2, and RSpec 2.14! 14 |

15 | 16 |

17 | Buy now » 18 |

19 | 20 |
21 | Already purchased? Sign into Leanpub and download the latest version for free. 22 |
23 |
24 |
25 | 26 |
27 |
28 |
29 | 30 |
31 |
32 | {{ content }} 33 |
34 | 35 |
36 |

37 | Buy the book now » 38 |

39 |
40 |
41 |
42 | 55 | 56 | 57 | -------------------------------------------------------------------------------- /_plugins/ext.rb: -------------------------------------------------------------------------------- 1 | require "jekyll/tagging" 2 | -------------------------------------------------------------------------------- /_posts/2010-05-22-bootstrapping-rails-template.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: Bootstrapping Rails with an app template 4 | excerpt: "Now that you've seen how I configure my Rails applications out of the gate, here's a way to do the same thing with one command." 5 | --- 6 | 7 | In my first post I walked through [the steps I take when creating a Rails application from scratch](/2010/05/19/bootstrapping-a-rails-app.html). I should clarify that those are the steps I _would_ take if it weren't for app templates, a very useful feature introduced in Rails 2.3. Simply put, create a Ruby file like the following and put it somewhere you can access it--in this example I'll just keep it in my Home folder on my Mac, and call it `rails_template.rb`: 8 | 9 | {% highlight ruby %} 10 | # rails_template.rb 11 | 12 | # set up the databases 13 | rake "db:create", :env => 'development' 14 | rake "db:create", :env => 'test' 15 | 16 | # install required gems 17 | gem "haml" 18 | rake "gems:install" 19 | run "haml --rails ." 20 | 21 | # run nifty generators 22 | generate :nifty_layout, "--haml" 23 | generate :nifty_config 24 | 25 | # remove unneeded files from public directory 26 | run "rm public/index.html" 27 | run "rm public/images/rails.png" 28 | 29 | # set up git 30 | file ".gitignore", <<-END 31 | .DS_Store 32 | log/*.log 33 | tmp/**/* 34 | config/database.yml 35 | db/*.sqlite3 36 | END 37 | 38 | run "touch tmp/.gitignore log/.gitignore vendor/.gitignore" 39 | run "cp config/database.yml config/database.example" 40 | 41 | git :init 42 | git :add => "." 43 | git :commit => "-a -m 'create initial application'" 44 | {% endhighlight %} 45 | 46 | Now, to use it, create your new Rails app with the following command: 47 | 48 | {% highlight bash %} 49 | $ rails -d mysql mygreatapp -m ~/rails_template.rb 50 | {% endhighlight %} 51 | 52 | and watch the magic happen. 53 | 54 | This is a very basic app template, but given their recipe-like nature, lots of templates are available on GitHub and elsewhere to help get your Rails applications off the ground. In particular, check out Mike Gunderloy's [BigOldRailsTemplate](http://github.com/ffmike/BigOldRailsTemplate), which includes an authentication system, pagination, database options (instead of my MySQL-only example above), testing, and other services. 55 | 56 | My advice is to start with a basic app template, then expand it as you build a collection of go-to gems and plugins. A great place to get started is by checking out the [Railscasts episode on app templates](http://railscasts.com/episodes/148-app-templates-in-rails-2-3), as well as Ryan Bates' [repository of sample templates](http://github.com/ryanb/rails-templates) on GitHub. -------------------------------------------------------------------------------- /_posts/2010-06-03-ruby-toolbox.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Finding the best time-saving gems for your Rails app with Ruby Toolbox" 4 | excerpt: "How do you find the best gems to add features to your applications? Save a lot of search time with a new-ish index of Ruby gems." 5 | --- 6 | 7 | Rails developers of all skill levels take advantage of a good gem or plugin (or two, or three, or five) to add critical features to apps. There's no shame in taking advantage of the generosity of others--maybe in addition to DRY we should have DRTWOO (don't repeat the work of others). In the past, my method of finding the right add-ons consisted of a combination of Google and GitHub's basic keyword search, then reviewing the candidate projects' activity history (when was the last commit?) and popularity (how many people are watching it?) to help assess whether it will be a good fit in my application. (It also helps if Ryan Bates has talked about it in [Railscasts](http://railscasts.com/)). Come to find out, there's a site that takes care of the GitHub part of the search for you. 8 | 9 | [Ruby Toolbox](http://www.ruby-toolbox.com/) has been around for more than a year, but somehow I missed it until last week when I was interested in current best practices for adding tagging functionality to an application. I've implemented tags several times, but figured how I'd done things in the past might be dated. 10 | 11 | My Google search found a page that ranked [four tagging projects](http://www.ruby-toolbox.com/categories/rails_tagging.html) by a score based on their respective GitHub watchers and forks. Each project's last commit, total downloads, and downloads of the current version are also listed to help you judge whether a project is solid enough to include alongside your own work. 12 | 13 | Ruby Toolbox has also helped me find gems to solve problems I had but didn't realize I had. For example, I have an app that relies heavily on [recurring events](http://www.ruby-toolbox.com/categories/recurring_events.html). At the moment I have basic code for writing and duplicating events in a calendar-like application (I tell people it's not a calendar; it's a data collection system that looks like a calendar). The next time I put my app through a round of updates I've got several options to consider for (hopefully) cleaning up my code. Take a look at the [list of gem categories](http://www.ruby-toolbox.com/) to get a top-level view of add-ons for your application--this is a great way to find tools to help get uncommon tasks (say, not authentication or tagging) into your app and out of the way. 14 | 15 |
16 | Thanks again to those of you who are following _Everyday Rails_ on Twitter or left feedback since I shared a link to the site on [RubyFlow](http://www.rubyflow.com/). New content is coming next week--look for a series on how I do authentication and authorization in Rails apps to begin. 17 |
-------------------------------------------------------------------------------- /_posts/2010-06-10-rails-footnotes.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Debugging Rails apps with Rails Footnotes" 4 | excerpt: "Rails Footnotes is a must-have gem for Rails developers of all skill levels. Here's how to get started with this invaluable debugging tool." 5 | --- 6 | 7 | I live in Lawrence, Kansas; home of the Django web framework. I'm sticking with Ruby on Rails for my own work, though I'll admit there are features in Django that would make Rails a better development experience. In particular, the first time I saw the Django Debug Toolbar I couldn't figure out why Rails didn't have such a utility--then I learned that we Rails developers have our own debugging tool called [Rails Footnotes](http://github.com/josevalim/rails-footnotes). You just have to install it separately. 8 | 9 | Instructions in the gem's [README](http://wiki.github.com/josevalim/rails-footnotes/) file are a little misleading. Here's what I've done to get up and running in a few Rails applications. 10 | 11 | To start, the line for installing the gem isn't quite current--I added the following to my `config/environments/development.rb` file: 12 | 13 | {% highlight ruby %} 14 | config.gem "rails-footnotes", :source => "http://rubygems.org" 15 | {% endhighlight %} 16 | 17 | Then install the gem: 18 | 19 | {% highlight bash %} 20 | $ rake gems:install 21 | {% endhighlight %} 22 | 23 | Reboot your app, and you're good to go. Out of the box (or fresh from the command line; which is it?) Rails Footnotes gives you convenient access to session variables, cookie values, param values, a complete list of environment variables, the database queries involved in rendering your view, the tail of your environment's log file, and other potentially useful information to help troubleshoot and optimize your Rails application. 24 | 25 | As noted, you can add your own custom footnotes. The example note, to display information about the currently logged-in user, is useful relative to the current theme at _Everyday Rails_ about authentication systems. The sample code is 99 percent useful as-is; however, there are a couple of issues if you're new to Ruby and/or Rails that may throw you for a loop. Specifically: 26 | 27 | 1. **Where does the custom note code go?** Create a file in your app's `lib/` directory. I just called mine `footnotes.rb`. 28 | 2. **Why do I get an error stating `uninitialized constant Footnotes::Notes::AbstractNote` when I try restarting my app?** You need to add `require 'rails-footnotes'` to the top of your `footnotes.rb` file (this is not included in the example code). 29 | 30 | Now, with that said, here's why you might want to add custom notes with caution. I don't know why this happens, but when I add a custom note to my configuration, Queries/DB note and the Log note both fail to yield any information. The Queries/DB note is particularly useful as it can help diagnose database bottlenecks. I'm unclear on why this is, but my workaround is to enable or disable my custom notes as needed by commenting or uncommenting the line to append your custom notes to the notes array (in the example code, this is `Footnotes::Filter.notes += [:current_user]`). In other words, only load your custom notes when you need them. 31 | 32 | One final issue: As of right now, it looks like [Rails Footnotes is not compatible with Rails 3](http://www.railsplugins.org/plugins/19-rails-footnotes). However, the project is being actively maintained on GitHub, so hopefully a Rails 3-ready version will be ready soon. 33 | 34 | These problems aside, Rails Footnotes are very handy and I recommend checking them out. The issues I mentioned above could well be due to something I'm doing; if I find out what it is I'll update this post as needed. -------------------------------------------------------------------------------- /_posts/2010-06-16-authorization-restful-acl-1.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Adding authorization to your Rails app with RESTful_ACL, part 1: Setup" 4 | excerpt: "Need easy-to-use authorization in your application? Check out this useful alternative to other, better known options." 5 | --- 6 | 7 | Rails authorization systems like [CanCan](http://github.com/ryanb/cancan), [Declarative Authorization](http://github.com/stffn/declarative_authorization) and [role_requirement](http://github.com/timcharper/role_requirement) get most of the attention, but they are by no means your only options for adding permission systems to your applications. My current favorite is none of these (in fact, it's not even listed in the [list of authorization options in Ruby Toolbox](http://www.ruby-toolbox.com/categories/rails_authorization.html)). I've been using [RESTful_ACL](http://github.com/mdarby/restful_acl) by Matt Darby. Its approach to an access control layer is different than other solutions. 8 | 9 | In particular, ACL settings center more around your application's models than they do the notion of roles. For me, this works out well for one main reason: At the top level I like to keep my apps' user options pretty basic--you're either an administrator, or a user, or a guest (not logged in). I don't have authors, editors, moderators, well-wishers, and so on, so I don't need a separate table to keep track of all these different roles. It's also worth noting that unlike other authorization systems, which put your application's authorization settings in a single configuration file, RESTful_ACL's authorization settings for each model are included in the model file itself. (As I get more exposure to the likes of Declarative Authorization and CanCan I think I like the central file idea better.) 10 | 11 | In the next series of posts on _Everyday Rails_ I'll cover the use of RESTful_ACL in application authorization, staring with a couple of tips for configuring your application to use the gem. To begin, follow the instructions provided in [RESTful_ACL's repository](http://github.com/mdarby/restful_acl) to add it to your app. It's assumed you've got some sort of authentication system in place (Devise, Restful Authentication, Authlogic, etc.). For my apps, I also have an `is_admin` boolean value set up in my User model, giving some users the ability to do anything within the app (see [Hacking Restful Authentication](/2010/06/08/hacking-restful-authentication.html)). If your application requires more roles for users, you can either create your own `roles` mechanism or look into one of the many role-supporting gems or plugins available. 12 | 13 | The `config.gem` part should be straightforward. You'll also need to add a route to redirect to when a user tries to do something he's not authorized to do. I usually put this in the sessions controller created by Restful Authentication: 14 | 15 | {% highlight ruby %} 16 | map.denied 'denied', :controller => 'sessions_controller', :action => 'denied' 17 | {% endhighlight %} 18 | 19 | Don't forget to add a `denied` method to your sessions controller and a corresponding view file. Your code is now ready to use RESTful_ACL for validating that users may perform functions within your application. 20 | 21 |
22 | Next time I'll apply RESTful_ACL to a basic Rails application, showing how to add ACL settings to a parent and child model and give different people different levels of access depending on whether they're logged in or are application administrators. 23 |
-------------------------------------------------------------------------------- /_posts/2010-06-19-rails-template-generator.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Even faster application bootstrapping with You've Got Rails" 4 | excerpt: "Build a full-featured template for your Rails applications with a few mouse clicks." 5 | --- 6 | 7 | I'm still working on my series on [adding ACL to Rails apps](http://everydayrails.com/2010/06/16/authorization-restful-acl-1.html) but ran across a site pertinent to an earlier discussion. My first two posts in _Everyday Rails_ were about getting Rails apps off the ground; first with a [step by step walkthrough of the process](http://everydayrails.com/2010/05/19/bootstrapping-a-rails-app.html) and then by [created an application template](http://everydayrails.com/2010/05/22/bootstrapping-rails-template.html) to do the heavy lifting for us. Turns out there's an even faster way--visit [You've Got Rails](http://www.youvegotrails.com/) (created by [Justin Briteen](http://twitter.com/jbritten)), check the boxes for the features you need in your app, download the template, and use it to create your app. 8 | 9 | Now, if you do go this route, don't get lazy--rather, use it as a learning opportunity. Take a look at the contents of the template to see what's going on. It will help you get more familiar with the general functionality of application templates so as you grow as a Rails developer you'll be able to create templates that do exactly what you need them to do, rather than relying on someone else to do the work for you. -------------------------------------------------------------------------------- /_posts/2010-07-18-understanding-rest-and-routes.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Understanding REST and routes" 4 | excerpt: "These four tutorials will get you up to speed quickly on the ins and outs of RESTful routing in Rails." 5 | --- 6 | 7 | In conversations I have with folks who are working to improve their Rails chops, as well as in comments I've received in the short time I've been writing this blog, it seems that RESTful routing still causes some grief. With that in mind, I thought I'd provide a list of resources that may help anybody still scratching their heads over the contents of `routes.rb`, the output of `rake routes`, or view code that looks like `form_for([@item.parent,@item])`. 8 | 9 | ### RESTful Rails tutorial 10 | 11 | As someone who never studied computer science or seriously use a framework prior to Rails, I'll admit that when REST and its effects on routing hit the scene with version 1.2 (and took center stage in version 2.0) I was confused. I fumbled around for a little while before finding the English translation of the RESTful Rails Tutorial by Ralf Wirdemann and Thomas Baustert. After reading through this 38-page PDF, I got it. If you're looking for a primer on the concept of REST and the cool things it lets you do with routing, it's a good start. 12 | 13 | Disclaimer: This tutorial is really old. I debated including it in this list, but for an explanation of REST, nested routes, and member routes, the narrative still works pretty well. Just note that some of the code doesn't apply in Rails 2.3 or Rails 3 (technically, most of it _will_ work with Rails 2.3, but some things have been refined), but I think overall it's still a good introduction to the concept. 14 | 15 | You can download the RESTful Rails tutorial PDF in English, German, and Spanish. 16 | 17 | ### Rails Routing from the Outside In 18 | 19 | Next, read the more or less official guide to Rails Routing, _Rails Routing from the Outside In_. There are two versions that cover routing in Rails 2.3 and routing in Rails 3. You might want to read them both, even if you're focusing on Rails 3 at this point—the 2.3 version provides some background knowledge that I think might be assumed for the Rails 3 version. 20 | 21 | ### Nested Resources Railscast 22 | 23 | At this point you should have a decent handle on how routing in Rails works. This Railscasts episode on nested routes demonstrates a very important facet of routing. Nested routes let you do things like convert a URL from something like `/business/653?employee_id=4349` to something much cleaner like `/business/653/employee/4349`, while simplifying your views and controllers in the process. This episode also covers another useful feature called _shallow_ routes, which would add `/employee/4349` to the mix for actions that don't require a `business_id` to them (e.g., `:show`, `:edit`, `:destroy`). 24 | 25 | ### Routing in Rails 3 Railscast 26 | 27 | To wrap things up, let's look at a more recent episode of Railscasts that focuses on the changes to routing in Rails 3 (also available in ASCIIcast format). Things are different, both above and below the surface, but not so much that you'll get confused if you need to work day-to-day with Rails 2.3.x and tinker with Rails 3 at night. -------------------------------------------------------------------------------- /_posts/2010-07-30-nifty-generators-rails-3.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Use Nifty Generators in Rails 3" 4 | excerpt: "The very handy Nifty Generators gem works in Rails 3 with a few minor usage changes." 5 | --- 6 | 7 | I've talked a lot about the Nifty Generators gem, created by Ryan Bates of Railscasts (see my introductions to [nifty_layout](http://everydayrails.com/2010/05/25/nifty-generators.html), [nifty_config](http://everydayrails.com/2010/05/27/nifty-config.html), and [nifty_scaffold](http://everydayrails.com/2010/06/01/nifty-scaffold.html)). When I began experimenting with Rails 3 I noticed that the gem was [not yet Rails 3 compatible](http://www.railsplugins.org/plugins/154-nifty-generators) according to RailsPlugins.org, but I'm happy to report (along with RailsPlugins.org users eggie5 and dgerton) that it's working fine—you just need to change a few things about how you use it. Here's what you need to do to get rolling: 8 | 9 | ### 1. Include Nifty Generators in your Gemfile 10 | 11 | Unlike apps written in previous versions of Rails, your Rails 3 app needs to know you're using Nifty Generators. Easy enough: Add the following line to your Gemfile: 12 | 13 | {% highlight ruby %} 14 | gem 'nifty-generators', '>= 0.4.0' 15 | {% endhighlight %} 16 | 17 | then install it if necessary, using Bundler: 18 | 19 | {% highlight bash %} 20 | $ bundle install 21 | {% endhighlight %} 22 | 23 | ### 2. Know the command line changes 24 | 25 | This is the biggest difference, and it's actually pretty minor. Replace the underscore in the old way of using the generator with a colon. So the old way of generating a scaffold, like 26 | 27 | {% highlight bash %} 28 | $ script/generate nifty_scaffold book title:string author_id:integer description:text 29 | {% endhighlight %} 30 | 31 | becomes 32 | 33 | {% highlight bash %} 34 | $ rails generate nifty:scaffold book title:string author_id:integer description:text 35 | {% endhighlight %} 36 | 37 | For a list of all four Nifty Generators' new syntax, just type 38 | 39 | {% highlight bash %} 40 | $ rails generate -h 41 | {% endhighlight %} 42 | -------------------------------------------------------------------------------- /_posts/2010-08-04-more-free-ruby-rails-books.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "More free Ruby and Rails books" 4 | excerpt: "Looking for more free books to get better at Ruby and Rails? Here are six more titles for your digital bookshelf." 5 | --- 6 | 7 | Thank you to everyone who commented on [my post about free Ruby and Rails books](http://everydayrails.com/2010/07/28/free-ruby-rails-books.html) last week. I learned there are even more good, free books available for download or reading online. 8 | 9 | ### Ruby on Rails (HTML, German) 10 | 11 | I admit I can't read German, but reader David Osterreicher recommends [Ruby on Rails 2](http://openbook.galileocomputing.de/ruby_on_rails/) as a good, example-filled introduction to Rails. 12 | 13 | ### Ruby Best Practices (PDF) 14 | 15 | I don't know how I missed this! Gregory Bowen's book [Ruby Best Practices](http://sandal.github.com/rbp-book/pdfs/rbp_1-0.pdf) is released as open source, or you can purchase the book from O'Reilly. [Read more about the book](http://rubybestpractices.com/). Thanks to Mike, AGarren, skim, and sardukar_siet for the recommendation—I'm looking forward to looking at this one. 16 | 17 | ### The Little Book of Ruby (PDF) 18 | 19 | Huw Collingbourne's [The Little Book of Ruby](http://www.sapphiresteel.com/The-Little-Book-Of-Ruby) is an 87-page introduction to Ruby, recommended by skim and and mikewoodhouse. 20 | 21 | ### The Book of Ruby (PDF) 22 | 23 | Collingbourne has also written [The Book of Ruby](http://www.sapphiresteel.com/The-Book-Of-Ruby), much larger at 425 pages. Thanks to mikewoodhouse for the recommendation. 24 | 25 | ### Rails 3 in a Nutshell (HTML) 26 | 27 | [Rails 3 in a Nutshell](http://rails-nutshell.labs.oreilly.com/) by Cody Fauser, James MacAulay, Edward Ocampo-Gooding, and John Guenin is currently under development and available in O'Reilly's Open Feedback Publishing System. It looks like the final version will be available through Creative Commons, too. 28 | 29 | ### Official Ruby and Rails documentation (HTML) 30 | 31 | I've referred to [Rails Guides](http://guides.rubyonrails.org/) in Everyday Rails before, and reader Mike points them out as a good reference as well. Don't forget about [RDoc](http://www.ruby-doc.org/), too, as recommended by Indigo Casson. 32 | -------------------------------------------------------------------------------- /_posts/2010-10-16-rails-documentation-tools.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "3 Rails documentation tools" 4 | excerpt: "Even in Rails, documenting your code is important. It's also pretty easy with these tools." 5 | tags: documentation 6 | --- 7 | 8 | If you've been using [Reek](http://github.com/kevinrutherford/reek/wiki) to help in [refactoring your Rails applications](/2010/09/27/rails-refactoring-tools.html), you might run across warnings of _Irresponsible Modules_— that is, code with no comments to help explain what it does. A common knock on the Rails community is that we don't document our code. I hate to admit it, but it's fair. My own Rails project folders are full of uncommented methods and mysterious model attributes. If I can't remember specifics about my code, how can I expect someone else to pick it up? 9 | 10 | The good news is there are quite a few documentation tools out there. Here are three you can get started with quickly to bring your application's code documentation up to speed. 11 | 12 | ### annotate-models 13 | 14 | The first tool is an oldie, but still works great: The [annotate-models](http://annotate-models.rubyforge.org/) gem refers to your database schema and adds field details in the comments of the corresponding model. Install the gem, `cd` into your Rails project directory, and type `annotate` to add this documentation to your models. You can also document your tests, specs, and factories—see the [GitHub repository](http://github.com/ctran/annotate_models) for more details. 15 | 16 | ### RDoc 17 | 18 | Now that you've got your models annotated (and have added some descriptive comments to your controllers, right?) you can turn it into browser-friendly HTML using the following built-in Rake task: 19 | 20 | {% highlight bash %} 21 | $ rake doc:app 22 | {% endhighlight %} 23 | 24 | Be sure to also edit the file `doc/READ_ME_FOR_APP`; that's what the Rake task uses for your documentation's starter file. Open `doc/app/index.html` in your browser to access your app's documentation. 25 | 26 | ### Rails ERD 27 | 28 | Finally, how about some visual documentation of how your models relate to one another? Check out [Rails ERD](http://rails-erd.rubyforge.org/) a new gem that creates nice PDF entity-relationship diagrams for your apps. It's easy to install, customizable, and very well documented. Take a look at the [gallery of ERD examples from popular open source Rails projects](http://rails-erd.rubyforge.org/gallery.html) to get a feel for how it works. The rendered PDF saves to your application root by default—I check this into my source control for other developers (not to mention for my own reference). 29 | 30 | ### Other tools 31 | 32 | This list is by no means exhaustive. Refer to Ruby Toolbox's [list of Ruby documentation tools](http://ruby-toolbox.com/categories/documentation_tools.html) for more options. -------------------------------------------------------------------------------- /_posts/2010-11-16-rails-ancestry-tree.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Trees and taxonomies with Ancestry" 4 | excerpt: "Ancestry is a new gem for adding tree structures to content in your Rails applications." 5 | --- 6 | 7 | [Ancestry](https://github.com/stefankroes/ancestry) is a handy gem for building tree structures or taxonomies in your Rails applications. It's similar to the likes of the [acts_as_tree](https://github.com/rails/acts_as_tree) plugin (see the [Railscasts tutorial](http://railscasts.com/episodes/162-tree-based-navigation)). The [project wiki](https://github.com/stefankroes/ancestry/wiki) has several ideas for ways to put Ancestry to use; in this post I'll cover a couple of basic uses to get you rolling with some common applications of the gem. 8 | 9 | ### Installation 10 | 11 | Follow the instructions provided in Ancestry's README to add it to your application. It's very straightforward: Install the gem, generate and run a migration, and add `has_ancestry` to any model you'd like to turn into a tree. For example, you might have a hierarchy of categories; once you've installed Ancestry this can be created with 12 | 13 | {% highlight ruby %} 14 | # app/models/category.rb 15 | 16 | class Category < ActiveRecord::Base 17 | has_ancestry 18 | 19 | # rest of model 20 | end 21 | {% endhighlight %} 22 | 23 | ### Built-in functionality 24 | 25 | The nice thing about Ancestry is how easy it makes it to work with a given object in your tree, its parents, and its children. It does this through more than 20 useful instance methods and several scopes. Among the ones you may want to start with: 26 | 27 | * **Roots:** To get a collection of the Category taxonomy's top-level nodes, just call `Category.roots`. 28 | * **Children:** Pretty straightforward; `@category.children` gives you a collection of a given category's subcategories. 29 | * **Ancestors:** A category's ancestry—its parent, grandparent, and on back—is accessible with `@category.ancestors`. 30 | * **Parent:** You've probably guessed it; `@category.parent` will give you the category's parent category. Useful if you want to include a back link in your view. 31 | 32 | ### Breadcrumbs 33 | 34 | A practical use of Ancestry is to help visitors navigate your site through breadcrumbs. This is easy to add to your view: 35 | 36 | {% highlight haml %} 37 | # app/views/category.show.haml 38 | 39 | %div#breadcrumbs 40 | = link_to 'Home', categories_url 41 | > 42 | - @category.ancestors.each do |a| 43 | = link_to a.name, a 44 | > 45 | {% endhighlight %} 46 | 47 | That's all there is to it to help your site visitors navigate your content more easily. -------------------------------------------------------------------------------- /_posts/2010-12-17-rails-admin-panel.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Turnkey administration interface for your Rails apps" 4 | excerpt: "RailsAdmin gives you a rich, web-based interface to your Rails 3 application's data in minutes. Here's how to get started." 5 | --- 6 | 7 | One benefit Python web framework Django has had over Rails is the [admin interface](http://www.djangobook.com/en/2.0/chapter06/), an easy-to-use, web-based interface for website administrators to access and manipulate data. Similar interfaces are not complicated to build in Rails, particularly if you're using scaffolds, but the process to date hasn't been as relatively turnkey as is setting up a Django admin interface. A recently released engine called [RailsAdmin](https://github.com/sferik/rails_admin) adds similar functionality to Rails 3 applications in a matter of minutes. 8 | 9 | Three things you should be aware of before you get started: 10 | 11 | 1. RailsAdmin only works with Rails 3 applications—3.0.3 or newer, to be precise. 12 | 2. It recommends that you use Devise for authentication in your application, in order to provide a layer of protection to your data (users must be logged in to access the admin interface). I recommend this, too. 13 | 3. You'll probably also want to do some additional locking down if your app has multiple roles or user levels (that is, you'll probably want to restrict access to the admin panel to your site's admins). 14 | 15 | With those conditions addressed, RailsAdmin is really easy to install. The [documentation](https://github.com/sferik/rails_admin/blob/master/README.mkd) is well-done and will walk you through the initial steps of adding the engine to your application. Once you've followed the initial setup steps, fire up your application's server and load up `/admin` to poke around. 16 | 17 | ### Authorization 18 | 19 | As I mentioned, if your application has multiple users of varying roles, you'll probably want to apply an authorization layer to RailsAdmin. The documentation outlines how to do this using Declarative Authorization, but ultimately how you configure authorization will be up to you and how your app is set up. In my application I used to try out RailsAdmin, using CanCan and a very basic roles system (just an `is_admin` boolean in my User model), I set up the initializer like this: 20 | 21 | {% highlight ruby %} 22 | # config/initializers/rails_admin.rb 23 | 24 | require "rails_admin/application_controller" 25 | 26 | module RailsAdmin 27 | class ApplicationController < ::ApplicationController 28 | before_filter :can_admin? 29 | 30 | private 31 | 32 | def can_admin? 33 | raise CanCan::AccessDenied unless current_user.is_admin? 34 | end 35 | end 36 | end 37 | {% endhighlight %} 38 | 39 | ### Limitations 40 | 41 | RailsAdmin is a work in progress, and you'll note in the project's [issues on GitHub](https://github.com/sferik/rails_admin/issues) that several features are pending. One particular gotcha to be aware of: If you're already using the `admin` namespace in your app, you'll need to do some code juggling since RailsAdmin uses the same namespace and does not currently have a way to customize this. There are also some model relations that aren't yet supported, such as polymorphic and `has_many :through`. The Devise dependency will keep some from being able to use RailsAdmin. The good news is RailsAdmin is in very active development right now, particularly with an eye toward Rails 3.1, so many of these issues will hopefully get addressed in a timely fashion. 42 | 43 | All in all, RailsAdmin has great potential to save you time when developing Rails software, and even more time when managing the data your software contains. -------------------------------------------------------------------------------- /_posts/2011-01-25-passenger-3-rvm.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Passenger 3, RVM, and Apache; quick and easy" 4 | excerpt: "If, like me, you've been dragging your feet about upgrading to Passenger 3, stop waiting. In this post I'll quickly walk through using it with RVM for Rails development." 5 | --- 6 | 7 | [Passenger 3](http://www.modrails.com/) has been out since last October, so for most folks this will all be very, very old news. For those of you who haven't upgraded yet, version 3 touts faster, more stable performance over version 2. It's also very easy to set up on your development computer so you can have multiple Rails projects running in development simultaneously. For my setup I'm also using [RVM](http://rvm.beginrescueend.com/) to manage project-specific gemsets ([read more about why I think this is a great idea](http://everydayrails.com/2010/09/13/rvm-project-gemsets.html)), but standardizing on one Ruby version. 8 | 9 | To start, it probably wouldn't hurt to make sure you've got the latest version of RVM on your computer. At this writing, that's version 1.2.4. The following should take care of the upgrade: 10 | 11 | {% highlight bash %} 12 | $ rvm update 13 | $ rvm reload 14 | {% endhighlight %} 15 | 16 | Next, install the new Passenger gem (at 3.0.2 as I write this). This is [very well documented on the RVM website](http://rvm.beginrescueend.com/integration/passenger/), if you need more detail. I keep the Passenger gem in my @global RVM gemset. 17 | 18 | {% highlight bash %} 19 | $ gem install passenger 20 | {% endhighlight %} 21 | 22 | Now run the Passenger module installer: 23 | 24 | {% highlight bash %} 25 | $ rvm passenger-install-apache2-module 26 | {% endhighlight %} 27 | 28 | (Note: Earlier I'd incorrectly listed the above command as `rvmsudo`. This isn't necessary. Thank you to Oldřich Vetešník for pointing this out.) 29 | 30 | Follow the instructions, including making sure you copy the Apache configuration directives provided into your own Apache config files. The good news here is these lines already point to your RVM-specified Ruby (the Ruby you were using when you installed the Passenger gem), so Apache is all set. 31 | 32 | Also note the suggested virtual host configuration provided; you may need it later depending on whether you've been using Passenger before or are using any supporting utilities for Passenger. 33 | 34 |
35 | **Potential gotcha with Apache 2 in Mac OS X 10.6.6:** When I rebooted Apache following the Passenger module installer, I was greeted with an error in the `apachectl` script. The suggestion in [this post](http://articles.itecsoftware.com/shell-scripting/fix-for-mac-os-10-6-5-apachectl-line-82-ulimit) solved the issue for me. 36 |
37 | 38 | From here, it's just a matter of preparing your Rails applications to take advantage of RVM's gemsets feature. Again, I'll refer you to [an earlier post about adding a `setup_load_paths.rb` file](http://everydayrails.com/2010/09/13/rvm-project-gemsets.html) to each new app's `config` directory. You'll also need to set up a virtual host for each new app. If you were using Passenger 2.2.x before, your existing virtual hosts should work fine. (The [OS X Passenger Preference Pane](http://www.fngtps.com/passenger-preference-pane), while still only 32-bit, is still working for me on my setup.) 39 | 40 | ### What about multiple Rubies? 41 | 42 | I haven't done this myself, but if you need to use this general setup with multiple versions of Ruby, refer to [this post on Phusion's blog about using proxies with Passenger and RVM](http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/) -------------------------------------------------------------------------------- /_posts/2011-03-11-rails-obfuscated-urls-friendly-id.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Obfuscated URLs with the FriendlyId gem" 4 | excerpt: "SEO-friendly URLs are great, but what if you want to obfuscate things a bit? Here's a proof of concept of one way to get the job done with the FriendlyId gem." 5 | tags: security 6 | --- 7 | 8 | As I've mentioned in the past, [I'm a big fan of the FriendlyId gem](http://everydayrails.com/2010/12/07/clean-urls-seo-rails.html) for easily creating human-readable, search engine-friendly URLs. But what if you want to make something that's _not_ so human or search engine friendly? Here's one simple way to get something up and running. 9 | 10 | For this demonstration, I'll be using the [FriendlyId](https://github.com/norman/friendly_id) gem's ability to [use a custom method for a slug](http://norman.github.com/friendly_id/file.Guide.html#using_a_custom_method_to_generate_the_slug_text). (I'm assuming you've installed and configured FriendlyId as dictated by the gem's instructions.) What I'm doing here is creating a SHA1 hash of a _secret's_ `name` field. You could, of course, use any unique field that's not going to change (though FriendlyId should remember old slugs, if necessary), or use your own encryption technique. 11 | 12 | {% highlight ruby %} 13 | # app/models/secret.rb; this would go in the model you want to obfuscate 14 | class Secret < ActiveRecord::Base 15 | has_friendly_id :code, :use_slug => true 16 | 17 | validates :name, :uniqueness => true 18 | 19 | def code 20 | Digest::SHA1.hexdigest self.name 21 | end 22 | end 23 | 24 | {% endhighlight %} 25 | 26 | Like I said, it's simple. If your security needs are serious you'd probably want something a little more complex (not to mention more layered than a basic obfuscation technique), but I wanted to share an out-of-the-box way to use a gem that already exists (and may even be in use in your app already). -------------------------------------------------------------------------------- /_posts/2011-04-03-simple-rails-project-backups.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Simple Rails site backups" 4 | excerpt: "How do you back up production data for your Rails projects? A new gem called Backup may be all you need." 5 | --- 6 | 7 | Today's post won't be specifically about Rails, but it will be about an important component of deploying productional Rails applications: Backing up your application's data. Regardless of whether you've already got a system in place or if you're hoping your hosting provider has your back, here's an elegant way to gain some peace of mind and have data that are easy to recover should the unthinkable happen. 8 | 9 | A little about my server setup: I've got several Linux-based virtual private servers running at work; each one with one to five Rails applications being served from it. I like to have data backups of each application (both database data and any file uploads an app may have) in addition to traditional server backups, just in case. In my situation, it would be faster to redeploy an application on a new virtual server than it would be to recover an existing virtual server, especially if I only need to recover data from one of the apps. 10 | 11 | Traditionally, I've used a hodgepodge set of bash scripts to dump MySQL databases and copy data directories over to another server, but with the [Backup](https://github.com/meskyanichi/backup) gem by Michael van Rooijen my setup is a little less hodgepodge and a lot more elegant. Here's a quick look at how to get things set up. 12 | 13 |
14 | As mentioned in the README, Backup won't work on Windows computers. 15 |
16 | 17 | The Backup gem is incredibly easy to install, assuming you've got shell access to your server (I haven't tried this on the likes of Heroku or Engine Yard). Follow the instructions in the [README](https://github.com/meskyanichi/backup/blob/develop/README.md) and the [project wiki](https://github.com/meskyanichi/backup/wiki) to get going; assuming you've got data to back up and somewhere to back it up to you'll be up and running in no more than 15 minutes. My only problem: I selected scp as a file transfer option, since I have an existing backup server, and had to install a couple of extra dependencies to get things to work. The good news is the Backup gem does a nice job reporting missing dependencies and setting you on the right path (and I like that it doesn't install a bunch of gems I wouldn't have otherwise used). Afterward I noticed there's a convenient way to see what your configuration's dependencies will be: 18 | 19 | {% highlight bash %} 20 | $ backup dependencies --list 21 | {% endhighlight %} 22 | 23 | ### Next steps 24 | 25 | * You'll probably want to set up automated execution of your new backup system. Van Rooijen and I both recommend using the handy [Whenever](https://github.com/javan/whenever) gem to create cron jobs for this purpose. 26 | * You can set up notification via e-mail, Twitter, or Campfire. See [the project wiki's page on notifications](https://github.com/meskyanichi/backup/wiki/Notifiers) for details. 27 | * Replace your current Rails backup solution (the one that possibly involves duct tape and baling wire) with Backup. OK, maybe that's just a next step for _me_. -------------------------------------------------------------------------------- /_posts/2011-04-28-rails-try-method.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "try(), try() again in Rails" 4 | excerpt: "The very convenient try() method has been available to Rails developers since version 2.3, but it's easy to forget if you're not in the habit of using it. Here's a brief primer." 5 | --- 6 | 7 | In Rails, `try()` lets you call methods on an object without having to worry about the possibility of that object being `nil` and thus raising an exception. I know I sometimes forget about it, and I've looked at enough code from other developers to know that I'm not the only one. So today I'd like to give you a brief introduction to the method (and hopefully ingrain it a little deeper into my own brain). Let's look at some very simple code from a Rails view. 8 | 9 |
10 | **Disclaimer:** While handy, this technique is not a replacement for good techniques like validations and default database values. Don't get lazy. 11 |
12 | 13 | ### Before 14 | 15 | Here's a simple example of code you might replace with `try()`. Say you've got a (rather contrived) `Product` model in your project. A `Product` may or may not have a known manufacturer, and some links you only want to display if a user is logged in _and_ has administrator rights: 16 | 17 | {% highlight erb %} 18 | 19 |

<%= @product.name %>

20 | 21 | <% unless @product.manufacturer.nil? %> 22 | <%= @product.manufacturer.name %> 23 | <% end %> 24 | 25 | <% if current_user && current_user.is_admin? %> 26 | <%= link_to 'Edit', edit_product_path(@product) %> 27 | <% end %> 28 | {% endhighlight %} 29 | 30 | Like I said, it's contrived, but it should give you the idea. `try()` can help us in a couple of places here: 31 | 32 | {% highlight erb %} 33 | 34 |

<%= @product.name %>

35 | 36 | <%= @product.manufacturer.try(:name) %> 37 | 38 | <% if current_user.try(:is_admin?) %> 39 | <%= link_to 'Edit', edit_product_path(@product) %> 40 | <% end %> 41 | {% endhighlight %} 42 | 43 | ### With arguments and blocks 44 | 45 | You can pass arguments and blocks to `try():` 46 | 47 | {% highlight ruby %} 48 | 49 | > @manufacturer.products.first.try(:enough_in_stock?, 32) 50 | # => "Yes" 51 | 52 | > @manufacturer.products.try(:collect) { |p| p.name } 53 | # => ["3DS", "Wii"] 54 | 55 | {% endhighlight %} 56 | 57 | ### Chaining 58 | 59 | You can chain multiple `try()` methods together. In another contrived example, say you've got a method in your `Manufacturer` model that sends the manufacturer a message whenever called. 60 | 61 | {% highlight ruby %} 62 | class Manufacturer < ActiveRecord::Base 63 | has_many :products 64 | 65 | def contact 66 | "Manufacturer has been contacted." 67 | end 68 | end 69 | 70 | Product.first.try(:manufacturer).try(:contact) 71 | #=> nil 72 | Product.last.try(:manufacturer).try(:contact) 73 | #=> "Manufacturer has been contacted." 74 | {% endhighlight %} 75 | 76 | ### Further reading 77 | 78 | You can start with [the Rails docs on try()](http://api.rubyonrails.org/classes/Object.html#method-i-try). Rails' inclusion of `try()` was inspired by [Chris Wanstrath's post about adding try() to Ruby](http://ozmm.org/posts/try.html). Raymond Law at Intridea has [a clever way to chain multiple calls to try()](http://intridea.com/2010/11/2/calling-methods-on-potential-nil-objects-in-rails?blog=company). And Scott Harvey has shared [a more practical example of try()](http://blog.scottharvey.co/blog/2010/7/5/ruby-on-rails-try-method.html). -------------------------------------------------------------------------------- /_posts/2011-05-08-rails-3.1-beta-rvm.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Install Rails 3.1 beta with RVM gemsets (a public service announcement)" 4 | excerpt: "Don't forget, RVM gemsets are great for trying out pre-release versions of Rails without interfering with other work. Here's a reminder on how to set that up." 5 | --- 6 | 7 | Last summer, as the early releases of Rails 3.0 began rolling out, I shared [how to use RVM to create sandboxes for experimenting with new versions of gems](http://everydayrails.com/2010/06/28/rvm-gemsets-rails3.html). Fast forward to now—Rails 3.1 is coming our way soon, with some major changes under the hood. These changes are well documented and debated elsewhere, so I won't get into them here. Once again, there's no need to wait until 3.1 goes final to see what's different. Here's a quick rundown of how to install your own Rails 3.1 sandbox. 8 | 9 | First, if you haven't updated RVM in awhile, it doesn't hurt to do so now. 10 | 11 | {% highlight bash %} 12 | $ rvm update 13 | {% endhighlight %} 14 | 15 | At this writing, RVM is at version 1.6.5. Don't forget, you'll need to open a new terminal window to begin using the new version. 16 | 17 | Create a gemset for the beta software: 18 | 19 | {% highlight bash %} 20 | $ rvm gemset create rails31beta 21 | {% endhighlight %} 22 | 23 | Switch to the newly-minted gemset with 24 | 25 | {% highlight bash %} 26 | $ rvm use @rails31beta 27 | {% endhighlight %} 28 | 29 | Now install Rails 3.1 beta: 30 | 31 | {% highlight bash %} 32 | $ gem install rails --pre 33 | {% endhighlight %} 34 | 35 | and create a test application: 36 | 37 | {% highlight bash %} 38 | $ rails new mytestapp 39 | {% endhighlight %} 40 | 41 | We're almost done. Next create a `.rvmrc` file to tell RVM which gemset to use in the new application. Note that I'm using Ruby 1.9.2, which I believe is now a requirement in Rails 3.1. 42 | 43 | {% highlight bash %} 44 | $ echo "rvm use 192@rails31beta" > mytestapp/.rvmrc 45 | {% endhighlight %} 46 | 47 | Open the application's directory, run `bundle` to install the default gems, and you're off to the races. 48 | 49 | {% highlight bash %} 50 | $ cd mytestapp 51 | $ bundle 52 | {% endhighlight %} 53 | 54 | As you look around the application structure, take a look at your `Gemfile` and the new `assets` directory inside `app/`. This is where most of the new features that will affect Rails developers at all levels are located. 55 | 56 | ### Where to go from here? 57 | 58 | * There are plenty of jQuery tutorials out there; I don't have one in particular I recommend over others. This will really only affect you if you use the Prototype/scriptaculous Javascript framework in your Rails apps. 59 | * The [Sass tutorial](http://sass-lang.com/tutorial.html) should get you up and running with replacing your CSS. I've been using Sass for awhile now and love it—if you haven't checked it out yet, you owe it to yourself to do so. 60 | * Charles Max Wood at [Teach Me To Code](http://teachmetocode.com/screencasts/) has been showing the basics of CoffeeScript in his screencasts. I will admit to being kind of green in this area, but am looking forward to getting Javascript functionality in my apps without having to deal with old-school RJS. 61 | -------------------------------------------------------------------------------- /_posts/2011-05-26-rails-smtp-development.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Better SMTP handling in Rails application development" 4 | excerpt: "You don't need to send out e-mail messages to real addresses during development with these two easy-to-use options for SMTP handling." 5 | --- 6 | 7 | When adding mailers during Rails application development, you don't need to connect to productional SMTP servers or use every GMail, Hotmail, and Yahoo! address you've ever created to make sure your mailers' views are rendering the way you'd like. Here are two very handy SMTP development utilities you can have up and running in minutes. 8 | 9 | ### Mailcatcher 10 | 11 | [MailCatcher](https://github.com/sj26/mailcatcher) is a Ruby gem from Samuel Cochran that fires up a basic SMTP server for development purposes, and a nice little web interface for looking at the results. Install the gem as you normally would: 12 | 13 | {% highlight bash %} 14 | $ gem install mailcatcher 15 | {% endhighlight %} 16 | 17 | Then fire up the server: 18 | 19 | {% highlight bash %} 20 | $mailcatcher 21 | Starting MailCatcher 22 | ==> smtp://127.0.0.1:1025 23 | ==> http://127.0.0.1:1080 24 | {% endhighlight %} 25 | 26 | To configure your app to use MailCatcher in development, you'll need to add your SMTP details (served from `localhost`, port 1025). For simplicity's sake I'm just adding this to my `config/environments/development.rb` file here; when implementing in real apps I've created an initializer that configures my SMTP settings depending on environment (MailCatcher in development; generally GMail in production). 27 | 28 | {% highlight ruby %} 29 | # config/environments/development.rb 30 | 31 | ActionMailer::Base.delivery_method = :smtp 32 | ActionMailer::Base.smtp_settings = { 33 | :address => "localhost", 34 | :port => 1025, 35 | :domain => "everydayrails.com" } 36 | {% endhighlight %} 37 | 38 | Now, whenever you trigger a mailer, the message will be caught by MailCatcher. Fire up the web console at `http://127.0.0.1:1080` to have a look at the message in HTML, plain text, or raw source. 39 | 40 | ### MockSMTP 41 | 42 | If you're a Mac-based Rails developer, and you have about $30 to throw at a development SMTP server, check out [MockSMTP](http://mocksmtpapp.com/) (also available in the Mac App Store). MockSMTP does the same thing as DreamCatcher, except via a native Mac interface. Fire up MockSMTP and configure your Rails application the exact same way. 43 | 44 | For most projects I would imagine that DreamCatcher is just as good, but you may have cases in which you'd want to separate outgoing mail by sender—MockSMTP's interface makes this quite easy. You can also tell MockSMTP to deliver messages once you've looked at them, which can be handy if you want to check how a message looks in specific mail clients. 45 | 46 | ### What about Windows? 47 | 48 | Windows-based Rails developers might want to check out [Papercut](http://papercut.codeplex.com/), or search around. I know nothing about these apps myself. 49 | 50 | ### What if I _do_ just want to send out mail? 51 | 52 | If you want to use your regular SMTP server during development, I recommend referring to the Railscast on [ActionMailer in Rails 3](http://railscasts.com/episodes/206-action-mailer-in-rails-3). In particular, watch the part on setting up a mail interceptor. Doing so will catch outgoing messages and deliver them all to a single inbox of your choosing, so you don't have to check multiple accounts for your mailers' deliveries. 53 | -------------------------------------------------------------------------------- /_posts/2011-06-16-rails-form-cancel-links.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Simple, user-friendly cancel links for your Rails forms" 4 | excerpt: "Let your users opt out of a form and return to the page they came from with this simple helper." 5 | --- 6 | 7 | The default Rails view generator includes _back_ links on form-related view templates, so if users change their mind they can easily get out of the form and on to something else. However, these links are static. What do you do if you allow users to access the form from multiple views (say, an index and a show). 8 | 9 | Here's a simple but effective solution I came up with: Instead of passing a static URL, I pass the HTTP referrer environment variable as the location. That way users are taken back to the page from which they opened the form to begin with. 10 | 11 | Here's how it works. Most of the code resides in the `application_helper.rb` file: 12 | 13 | {% highlight ruby %} 14 | module ApplicationHelper 15 | include Rails.application.routes.url_helpers 16 | 17 | def cancel_link 18 | return link_to 'Cancel', request.env["HTTP_REFERER"], 19 | :class => 'cancel', 20 | :confirm => 'Are you sure? Any changes will be lost.' 21 | end 22 | end 23 | {% endhighlight %} 24 | 25 | You'll need to include `Rails.application.routes.url_helpers` in order to access `link_to` from a helper method. Then you add the helper method itself, which does nothing more than return a cancel link. Mine uses an old-style `:confirm` message; you can spruce it up with some less obtrusive if you'd like. 26 | 27 | If I need a cancel link in a view, I just add 28 | 29 | {% highlight erb %} 30 | <%= cancel_link %> 31 | {% endhighlight %} 32 | 33 | The result: a flexible, reusable cancel option that's much more user-friendly. Not bad for just a few lines of code. -------------------------------------------------------------------------------- /_posts/2012-05-07-everyday-rails-rspec-book-available.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec: Get advance access to my new book now" 4 | excerpt: "I'm happy to announce that the extended, DRM-free ebook version of my RSpec series is now available for purchase through Leanpub. Here's a rundown of what's there now and what's to come." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | ![book cover](/images/rspec_book_large.jpg){: .decoration} 9 | When I concluded my series on [learning RSpec](http://everydayrails.com/2012/04/24/testing-series-rspec-requests.html) a couple of weeks ago, I mentioned I've been working on an ebook version of the series with additional content and a complete code sample. I'm happy to announce that my first book, _[Everyday Rails Testing with RSpec: A Practical Approach to Test-driven Development](http://leanpub.com/everydayrailsrspec)_ is now available for advance access through Leanpub! 10 | 11 | What do I mean by _advance access_? I mean it's not done yet, but I wanted to go ahead and get the book out there for people to start reading. (If you've ever purchased a beta book from Pragmatic Programmers you know what I'm talking about.) I've got updated versions of the original RSpec articles from this blog in place, along with a few other pieces. The remainder will be in place within the next few weeks, with some editing to be done after that along with the completed sample code. In addition, I'll keep code samples current through Rails 4.0. 12 | 13 | Here's a rundown of what's done and what I'm working on: 14 | 15 | 1. Introduction: **available now** 16 | 2. Setting up RSpec: **available now** 17 | 3. Model specs: **available now** 18 | 4. More on factories (exclusive): **in progress** 19 | 5. Controller specs: **available now** 20 | 6. Request specs: **available now** 21 | 7. Testing logins (exclusive): **in progress** 22 | 8. Improving specs (exclusive): **in progress** 23 | 9. Toward test-driven development (exclusive): **in progress** 24 | 10. Parting advice (updated content): **available now** 25 | 11. More testing resources for Rails (exclusive): **available now** 26 | 27 | I may throw in another chapter or two before it's done. When finished the book will be 100-ish pages and, as I mentioned, include a complete, downloadable Rails application with sample tests in RSpec. 28 | 29 | I should mention that this book isn't your typical, type-along tutorial. We're not going to build an application together--I'm going to show you the process I went through as I made RSpec part of my development toolkit, and give you techniques and patterns to follow when testing your own applications. I'll also take you through a lot of foundational stuff early on that will get cleaned up later. If you're familiar with Zed Shaw's [Learn Code the Hard Way](http://learncodethehardway.org/) series you may get the general idea--it's not an apples-to-apples comparison, but his technique did inspire my thinking behind this series. So did the Railscasts episode [How I Test](http://railscasts.com/episodes/275-how-i-test). 30 | 31 | Finally, I'm not giving this book away for free--it's taken a lot of time to conceptualize and write, and I've been working hard to make it worth a little bit of your money. That said, I'm keeping it reasonably priced, especially for those of you gracious enough to buy an early copy. And it's DRM-free. You can [get your copy today for only $12 US](http://leanpub.com/everydayrailsrspec). I'll keep it at $9 for the Rails 3 releases, and reserve the right to raise the price later. 32 | 33 | If you're not ready to buy right away, please sign up for the mailing list to keep current on the book's status. I won't use the list to spam you--just to keep you notified as I progress through the remainder of the book. 34 | 35 | Thanks very much for keeping up with Everyday Rails over the last couple of years. I hope you'll check out _Everyday Rails Testing with RSpec_ and give me your feedback. -------------------------------------------------------------------------------- /_posts/2012-06-13-rspec-book-complete.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec: The Book is complete" 4 | excerpt: "The expanded version of my series on learning to test is ready for non-early adopters. Here's more information on the Rails 3.2 version of the book, and what's to come later." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | On Monday I posted the final, edited version of _[Everyday Rails Testing with RSpec](http://leanpub.com/everydayrailsrspec)_, available now on Leanpub for $12 US. 9 | 10 | First, let me again thank everyone who purchased the early access, beta version of the book. I appreciate the support and all the feedback. As I shared on the Leanpub mailing list yesterday, releasing the book so early in its development cycle perhaps frustrated a couple of readers, but it resulted in a very different (and in my opinion, better) book than I'd originally set out to write. I'm planning to write a more complete retrospective in [my personal blog](http://www.aaronsumner.com/) later this week, for anyone interested in the lean publishing approach. 11 | 12 | Next, let me remind you what's in the book as it now stands: 115 pages (as the PDF is formatted), 12 chapters (and a short appendix), and a code sample that iterates from chapter to chapter. The content is more or less a retelling of how I learned to test (specifically, with RSpec). It's not for people who've never worked with Rails. It's not for people who have developed good testing habits and patterns for themselves already. It is for people who are still trying to build those habits and patterns. I'm not saying my way is _the_ way, but hopefully I've shared enough in the book to help you get comfortable with testing and improve your coverage. 13 | 14 | If you're still on the fence, check out the [preview available through Leanpub](http://leanpub.com/everydayrailsrspec), or refer to the [testing series on this blog](http://everydayrails.com/2012/03/12/testing-series-intro.html) that started the whole thing. 15 | 16 | ### Update for Rails 4.0 17 | 18 | Once Rails 4.0 begins hitting the release candidate phase, I'm going to revisit the content of the book and the libraries shared within it, with the hope that an updated version of the book can be available within a month of Rails 4's final release. This version will be a free update to anyone who's purchased the book. I'm doing that because I know how quickly software books can become obsolete, and that Rails 4 is going to hit sooner rather than later. 19 | 20 | ### Availability outside of Leanpub 21 | 22 | I know that the book isn't available right now in countries Paypal doesn't support. I know also that there are people who just don't like Paypal and don't want to use it. This is a limitation placed by Leanpub, not me. My intention is to make the book available elsewhere as soon as possible, but I want to talk to the folks at Leanpub to determine the best way to go about it. More news as I get it. 23 | -------------------------------------------------------------------------------- /_posts/2012-08-03-rspec-book-updates.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "August 2012 updates for Everyday Rails Testing with RSpec" 4 | excerpt: "Anyone who's purchased my book should head over to Leanpub to download the latest version. Here's a list of what's new." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | For anyone who either doesn't subscribe to updates from Leanpub, or is still on the fence about buying [my book about learning Rails testing through RSpec](http://leanpub.com/everydayrailsrspec), I just wanted to pass along that I pushed an update this evening with the following updates: 9 | 10 | * Added the change log back to the book. 11 | * Replaced usage of `==` to `eq` throughout the book to mirror best practice in RSpec expectations. 12 | * Added clarification that you need to re-clone your development database to test *every* time you make a database change (chapter 3). 13 | * Added a note on the great factory debate of 2012 (chapter 3). 14 | * Added a section about the new RSpec `expect()` syntax (chapter 3). 15 | * Fixed incomplete specs for the #edit method (chapter 5). 16 | * Added an example of testing a non-CRUD method in a controller (chapter 5). 17 | * Added tips on testing non-HTML output (chapter 5). 18 | * Fixed a typo in the `:message` factory (chapter 5). 19 | * Fixed typo in spelling of *transactions* (chapter 8). 20 | * Added a simple technique for testing Rake tasks (chapter 10). 21 | 22 | In addition, Leanpub is now accepting credit card transactions--so those of you who in the past couldn't use PayPal can now buy a copy. Still only nine American bucks. -------------------------------------------------------------------------------- /_posts/2012-09-11-bundler-rails-specify-versions.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Bundler tip: Always specify gem versions" 4 | excerpt: "Don't make future developers (or future you) guess your application's dependencies. Tell Bundler how to load the right gems every time." 5 | --- 6 | 7 | I recently picked up a brownfield project. It involves some cleanup and a few new features. It's built in Rails 3.0 and has several external gem dependencies. I can deal with it being Rails 3.0 versus a newer release, but the problem is the Gemfile. Can you spot the potential problem here? 8 | 9 | {% highlight ruby %} 10 | source 'http://rubygems.org' 11 | 12 | gem 'rails', '3.0.6' 13 | 14 | gem 'mysql2' 15 | gem 'fastercsv' 16 | gem 'paperclip' 17 | gem 'devise' 18 | gem 'cancan' 19 | {% endhighlight %} 20 | 21 | The Rails ecosystem moves quickly--too quickly, some might say--and as a result a given library's API from just a few months ago may be deprecated today--or worse, it may just no longer work. Running `bundle install` with the Gemfile as-is, I could get gem versions that are no longer compatible with a legacy version of Rails. Or potentially worse, I could get gem versions with drastically rewritten APIs--*very* difficult to debug without a solid suite of tests. (The codebase in question lacks test coverage, too, but that's a different subject.) 22 | 23 | It's good practice to be more forthright about your applications' external dependencies, whether it's to communicate them to other developers or to yourself in the future. Don't beat yourself up if you've not been doing this--to be fair, I see a lot of Rails tutorials that ignore dependency versions. 24 | 25 | Luckily for me, the previous developer had checked in the application's `Gemfile.lock` file, so I was able to read through it and apply the correct versions: 26 | 27 | {% highlight ruby %} 28 | source 'http://rubygems.org' 29 | 30 | gem 'rails', '3.0.6' 31 | 32 | gem 'mysql2', '~> 0.2.7' 33 | gem 'fastercsv', '~> 1.5.4' 34 | gem 'paperclip', '~> 2.3.8' 35 | gem 'devise', '~> 1.3.4' 36 | gem 'cancan', '~> 1.6.4' 37 | {% endhighlight %} 38 | 39 | So how do you keep your dependencies in line? The best way is to make a habit of including version numbers as you add dependencies. My preferred method is to first locate them gem on [Rubygems.org](http://rubygems.org) and use the convenient clipboard utility to grab the version number. Alternatively you could run `bundle install` with no version number, then check to see which version was installed with `gem list` and apply that version. 40 | 41 | As a reminder, Bundler uses this simple syntax to help with versioning: 42 | 43 | * `'1.0.3'` will install version 1.0.3 and *only* version 1.0.3 of a given gem. 44 | * `'~> 1.0.3'` will install the latest version of the 1.0.x branch of the gem, from 1.0.3 on. This is generally the route I take, as acceptable newer versions should not alter the gem's API. If they do, I'll fall back to requiring a specific version. 45 | * `'>= 1.0.3'` will install *any* version of the gem from 1.0.3 on, including significant updates--and, potentially, significant API changes. 46 | 47 | It's worth the time to [read the Bundler documentation on Gemfile setup](http://gembundler.com/gemfile.html), as you can get a little fancier than what I've shown if you'd like. However, I've found that sticking to these three rules can go a long way toward keeping your dependencies in check. 48 | 49 | I'm sorry if this post is a little basic for some folks, but honestly, I've seen even some pretty experienced Rails developers fall into this trap. Including version numbers in your Gemfiles only takes a moment and is a good habit to build. -------------------------------------------------------------------------------- /_posts/2012-11-14-rspec-book-news.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec: News and update plans" 4 | excerpt: "Updates to the Rails testing toolkit I use in the book are on the way (or here already). Here's my plan for addressing these changes." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | It's been some time since I've been able to post something new here, so you may be wondering where things are relative to updates to [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec). First, let me thank all of you who've purchased the book. I'm happy to share that yesterday morning I surpassed 1,000 readers. I greatly appreciate your support. 9 | 10 | As I've mentioned previously, I will write a second edition to be released as soon as possible after Rails 4.0 final is out. This edition will be a free update for anyone who's bought the book, with updated content starting when release candidates start appearing. I plan to provide the book as a hybrid of the current edition and new content during the transition, to give you as early access to the new material as possible. 11 | 12 | Of course, Rails isn't the only moving target in the stack: 13 | 14 | - [Capybara 2.0.0](http://rubygems.org/gems/capybara) is now available, and [it is not backward-compatible](http://alindeman.github.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html). I haven't had a chance to play with the new version yet, but acknowledge that quite a bit of what I show in the book is not applicable to the new version. I will address this in the updated edition. 15 | - RSpec 3.0 will be available sooner or later, at which time I plan to cover [the new expectation syntax](http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax) in more detail than I do in the current edition. 16 | 17 | That's the plan. As things get closer I'll also get some sort of system set up for you to share found errata and other suggestions. Of course, in the meantime feel free to send me an email with your thoughts. 18 | 19 | -------------------------------------------------------------------------------- /_posts/2013-02-13-rspec-book-updates-capybara.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec, the book now covers Capybara 2.0, RSpec's new syntax, and more" 4 | excerpt: "The next round of updates to my introduction to testing in Rails is here!" 5 | tags: rspec rspec-book 6 | --- 7 | 8 | Hey everyone, thanks again to all of you who have purchased [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec). I hope it's gotten you on your way to better-tested apps. Sales have been chugging right along--Leanpub reports I now have more than 1,400 readers. I appreciate each and every one. I've gotten lots of great feedback in the few months since the last large update, and have been busy working to address your suggestions. 9 | 10 | I know the tools have changed some since the last version was released, so I'm happy to share that an updated version is now available. Some big changes this time around: 11 | 12 | - I've replaced use of `should` with the now-preferred `expect()` syntax throughout most of the book (chapters 9 and 10 excepted; see below). 13 | - The new Capybara 2.0 DSL is now covered; chapter 8 now covers feature specs instead of request specs. 14 | - Per suggestion, I've reworked the initial specs from chapter 3 to skip factories and focus on already available methods. Chapter 4 is now dedicated to factories. 15 | - Copy edits throughout. 16 | 17 | Code samples have been updated as well. 18 | 19 | Please note that chapter 9 (Speeding Up Specs) and chapter 10 (Testing the Rest) have not been edited yet. I'll get them addressed in the coming weeks. Rails 4.0-related updates will get underway when release candidates start coming out. Those updates will all be free to you to download. 20 | 21 | [Head on over to Leanpub](https://leanpub.com/everydayrailsrspec), download the latest version, and let me know what you think. 22 | -------------------------------------------------------------------------------- /_posts/2013-04-24-rspec-book-updates.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec: Updates for April, 2013" 4 | excerpt: "Wrapping up Rails 3.2 and looking ahead to Rails 4.0." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | Last week I released another round of updates to [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec), and subsequently released a couple of minor updates since. For those of you who may have missed it: 9 | 10 | **This is it, the final update built on Rails 3.2**. I'm now working on a major update for Rails 4.0. I wanted to let you know about a few things. 11 | 12 | First, I'm happy to share that I've **open sourced the sample code** and [posted it to GitHub](https://github.com/ruralocity/everyday_rails_rspec_rails_3_2). You can now browse the source there, or grab it for yourself and follow along each chapter's tagged branch. 13 | 14 | Along those lines, I'm **moving [errata tracking and code discussions](https://github.com/ruralocity/everyday_rails_rspec_rails_3_2/issues)** away from my own site and the Leanpub product page over to GitHub. It's better for sharing code and will hopefully involve other readers in the conversation. 15 | 16 | You may find a bug or typo or something else that doesn't make sense. I still find things I want to change, even after working on this book for more than a year. If you find something, please [post it in the issues](https://github.com/ruralocity/everyday_rails_rspec_rails_3_2/issues) on the GitHub project. I can't promise it will be fixed in the 3.2 version, but if it makes sense I'll be sure to address it in the Rails 4.0 edition. 17 | 18 | Otherwise, the biggest changes in this version are in chapters 8, 9, and 10. For the most part these aren't huge changes--mostly an attempt to bring old content up-to-speed with the current codebase. They'll be works in progress moving forward. 19 | 20 | Finally, I want to talk a bit about what I've got in mind for the next version. It hopefully goes without saying, but the sample application will be built on Rails 4.0. It'll also be a new application! Over the past year I've come to realize that our little address book is limited in terms of what I can demonstrate with it, especially when it comes to feature specs. I don't know what I'll replace it with just yet, but whatever it is will hopefully be more flexible. There will be other changes throughout, culminating in a chapter of actually test-driving a new feature instead of adding after-the-fact specs. Of course, these updates will continue to be free to everyone who's [purchased the book](https://leanpub.com/everydayrailsrspec). 21 | -------------------------------------------------------------------------------- /_posts/2013-05-20-obfuscated-data-screenshots.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Obfuscating data in Rails applications for screenshots and demonstrations" 4 | excerpt: "Faker isn't just for testing; here's how I used it to use real data in demonstrations (without revealing anything sensitive)." 5 | --- 6 | 7 | I recently had a need to demonstrate a data-heavy application to potential customers. Demonstrating the application with bogus numbers is one thing, but everything looks much more realistic when I'm using *real* data. I can't reveal any real information, though, so I needed a quick way to obfuscate real names. [Faker](http://rubygems.org/gems/faker) to the rescue! 8 | 9 | In the past I've shown [how to use Faker in tests](http://everydayrails.com/2012/03/19/testing-series-rspec-models-factory-girl.html), but it's got other uses as well. In this case, I used it to change the names of the innocent in my application, while keeping the interesting numbers intact. The result: No way to identify anything to a given user or group, but a realistic demonstration of the data all the same. 10 | 11 | To pull this off, I copied production data over to my development setup, then built some simple Rake tasks to obfuscate my data in development. Check it out: 12 | 13 | 14 | 15 | Here, I only obfuscate non-admin users (so I can continue to sign in with my usual credentials), and since I'm working with schools I augment Faker's returned results with some of my own. I also show a couple of ways you could make sure the tasks aren't errantly run in production, because that would be bad. 16 | 17 | And obviously, this won't apply to every situation--you may not have access to production data, or your data might not be as easily obfuscatable. It would also need some tweaking to make work in any situation besides mine, since I'm working directly with my Rails models in the rake tasks. 18 | 19 | But it's a fast way to get realistic data for demos and screenshots. If you don't care about using real data, you can also try [this approach for populating a database with lots of test data](http://railscasts.com/episodes/126-populating-a-database). It's a few years old but still applicable. 20 | -------------------------------------------------------------------------------- /_posts/2013-07-16-july-2013-book-updates.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec: Where are the Rails 4.0 updates?" 4 | excerpt: "Updated development schedule for all who've purchased my RSpec book. Short answer: They're coming!" 5 | tags: rspec rspec-book 6 | --- 7 | 8 | Last month I tweeted that I'd have the promised Rails 4.0-based version of *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)* out and ready for you to read within a week or so of the Rails 4 release. Obviously, I've missed that target. I apologize, and I'd also like to explain what's taking so long. 9 | 10 | First, let me get some excuses out of the way. Last month I left my job of eight years (with a history twice that long) to take a position with O'Reilly Media. As you might imagine, trying to get things wrapped up neatly after such a long tenure was not easy. It involved a lot of late hours and time taken from writing and editing. Getting ready for a new job and different ways of doing things I've been doing the same way for years has also reduced the time and energy I have to work on the book. 11 | 12 | Again, I'm sorry about the bad timing, but a good opportunity arose, and I had to take it. 13 | 14 | Let's talk about better news (for you) now: 15 | 16 | - **Chapters 1 through 7 are updated for Rails 4.0 and Ruby 2.0.0.** And by "updated," I mean that I wrote the code from scratch and have picked through it to update things that have been bothering me, from poor grammar to poor examples of what I've been trying to explain. I rewrote major parts of a couple of chapters so that they flow better. In particular, chapter 5 (basic controller specs) works with actual code from the sample application instead of hypotheticals, and I think the changes I've made to chapter 8 (feature specs) work a little better within the grand scheme of the demo. 17 | - **I'm still committed to replacing chapter 11 with an example of test-driving a feature, using the techniques from the book.** This, along with updates to chapter 9 (speeding up specs), represent the bulk of the coding-related work I still have to do for the book. The rest should mostly be minor edits. 18 | - **I'm aiming to have an initial beta release available to you by the end of July, 2013.** There may be some rough edges here and there, but I think overall the meat of the book will be complete. I'll look forward to hearing your feedback. **And I want your feedback!** Any input you can provide will help me put the wraps on the book so we can all move on to other things. 19 | 20 | Next, a couple of other notes upon which I'd appreciate your feedback: 21 | 22 | - **I'm looking into print options.** I've received a few requests for a print version, and I'd like at least one vanity copy for myself. At this point I'm planning on going the self-published, on-demand route. If you're interested in a print version, please [let me know](/contact.html)! I'd also appreciate hearing from anyone who's had experience with the self-published printed route. 23 | - **I'm also looking into other formats.** Specifically, what would you think about a screencast version of the book? Again, [let me know](/contact.html). 24 | 25 | Finally, and I should have mentioned this earlier in this message: Thank you to everyone who's purchased the book, sent a nice email or tweet, said hello at a conference, or [offered suggestions](https://github.com/ruralocity/everyday_rails_rspec_rails_3_2/issues?state=open) on the Rails 3.2 version. As of a couple of days ago more than 2,300 copies of *Everyday Rails Testing with RSpec* have been sold--or, in simpler terms, about 2,300 more copies than I thought would sell when I first started publishing it on Leanpub. You've helped me make new friends, get a great new job, and put a few extra bucks in my pocket. 26 | 27 | Thanks again! -------------------------------------------------------------------------------- /_posts/2013-08-21-rspec-book-rails-4-final-release-notes.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec for Rails 4 is done" 4 | excerpt: "Information on the final release, and a note on what's up next." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | As I type this, Leanpub's robots are busily formatting *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec/)* into PDF, EPUB and MOBI for your digital reading convenience. Below are my release notes, sent to many of you already by email: 9 | 10 | > Hi everyone, I've just released a final update for the new, Rails 4.0-based edition of *Everyday Rails with RSpec*. I did a round of editing on chapters 6 through 12, and updated the stubbing examples in chapter 9 to use RSpec's new `allow()` syntax. 11 | > 12 | > ## Please report errata! 13 | > 14 | > I'm not planning on any more major updates to the book, at least not for awhile. However, if you find issues or just have a question or suggestion, please report them in the [sample project's issues tracker on GitHub](https://github.com/everydayrails/rspec_rails_4/issues). That way other readers can benefit from your report, and I can release minor updates as needed. 15 | > 16 | > ## Print version? 17 | > 18 | > A few people have shown interest in a printed copy of the book. My next step is to look into on-demand printing options that (1) won't require me to sign over rights to the work; and (2) aren't seen as competitors with my employer. If you have suggestions please let me know. 19 | 20 | Thanks again to all of you who've supported this project over the last 16 months! The book has come a long way since the initial handful of chapters I first released in early May, 2012. I'm looking forward to taking a little break from writing about testing and RSpec so I can focus on other aspects of Rails and software development. -------------------------------------------------------------------------------- /_posts/2013-09-09-rspec-book-chinese-translation.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Chinese translation of Everyday Rails Testing in RSpec now available" 4 | excerpt: "A Chinese version of my testing book is now for sale on Leanpub." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | I'm excited to share with you a new [Chinese version of *Everyday Rails Testing with RSpec*](https://leanpub.com/everydayrailsrspec-cn), translated by Andor Chen and available now on Leanpub. Andor contacted me several months back about this project; I asked him to hold off on translating until the Rails 4.0-related updates were complete since I knew there would be a lot of changes. Andor worked hard to make the translation available within weeks of the updated English version, and also pointed out a few corrections to make in the original while he was at it. 9 | 10 | All royalties for the [Chinese translation](https://leanpub.com/everydayrailsrspec-cn) will go to Andor--I'm happy he offered to help make the book available to Chinese speakers. Thanks Andor! -------------------------------------------------------------------------------- /_posts/2013-11-15-i-wrote-a-view-spec.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "I wrote a view spec" 4 | excerpt: "When is it beneficial to include a view spec in your Rails app's test suite? Here's one example." 5 | tags: rspec 6 | --- 7 | 8 | For almost two years now, I've been telling people I never write view specs for my Rails applications. They're hard to write and harder to manage over time. I don't even talk about them in *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)*--as a general rule, I try to either test view-related matters in my feature specs, or better yet, extract the stuff that needs testing into more testable layers of my application. 9 | 10 | So why did I write a view spec the other day? 11 | 12 | In this case, I needed to test-drive some inline JavaScript (inline because it injects server-side environment variables into a larger JavaScript library, but not enough to warrant a more thorough solution like [gon](https://github.com/gazay/gon)). It's kind of difficult to test the end result of doing this in a feature spec, at least without massively slowing down the test suite. View specs to the rescue? 13 | 14 | Here's the general idea: 15 | 16 | {% gist 7490444 %} 17 | 18 | In this case, the environment variables are loaded into Rails via [dotenv](https://github.com/bkeepers/dotenv). If a developer (or continuous integration tool) doesn't have these variables set, the test will fail. It also served as a guide as I wrote the actual code to make it pass. All this in a spec that took about two minutes to write, and runs in an instant. 19 | 20 | I'm still not advocating trying to cover every view with a view spec. All the same, they can serve a purpose and belong in your RSpec toolbox. 21 | -------------------------------------------------------------------------------- /_posts/2014-01-15-outside-in-example-ruby-tapas.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "A great example of outside-in testing from Ruby Tapas" 4 | excerpt: "How do you turn testing knowledge into a testing habit? Learn from an expert." 5 | tags: rspec 6 | --- 7 | 8 | **Update: Avdi has generously made the Outside-In episode of Ruby Tapas embeddable for this post--see below. Thanks, Avdi!** 9 | 10 | Once you know the basic mechanics of testing, how do you bring it all together into a consistent testing habit or routine? I get asked this a lot by people who've recently finished *[Everday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)* or are generally still getting comfortable with this facet of development. While there are a number of approaches, I like to go *outside-in* by starting with a high-level spec, using it to drive the desired behavior of my software, and dropping down to unit tests to suss out the finer details of a feature. It's an organic process, to be sure, and one that can take some practice before becoming second nature. 11 | 12 | Lately I've been catching up on [Ruby Tapas](http://rubytapas.com/), Avdi Grimm's excellent series of bite-sized videos on Ruby. If you're not already a subscriber, I highly recommend checking it out. $9 a month gives you access to a large library of videos, growing at a rate of two per week. If you need additional motivation, episode 120, [Outside-In](http://www.rubytapas.com/episodes/120-Outside-In), is a wonderful demonstration of the outside-in testing process in action, and a great example of an approach I try to follow, myself. 13 | 14 | 15 | 16 | A few observations: 17 | 18 | - Watch how Avdi goes about writing a test--starting with a very high-level outline and working out the details as his understanding of the problem increases. 19 | - Along these same lines, note that he doesn't start out writing a ton of specs at the outset. He focuses on one issue at a time, refining his test suite as he proceeds. Again, it's *organic*. 20 | - Finally, did you notice what Avdi said about *when* to add a test? It's a sense you'll hone as you continue to practice test-first software development. So keep practicing! 21 | 22 | This isn't the only Ruby Tapas episode dedicated to writing tests--and even episodes not focused on testing show how your test suite is an integral part of growing and refactoring your code base. Again, I can't suggest [checking it out](http://rubytapas.com/) enough. And, though I've mentioned it before, I suggest checking out [How I Test](http://railscasts.com/episodes/275-how-i-test) on Railscasts. It's a few years old now, and some of the syntax has changed a bit, but it's still a wonderful demonstration of this same approach to testing. In fact, this video is what inspired me to write my book in the first place. It's a free clip, so if you haven't watched it yet, please take 15 minutes to do so. 23 | -------------------------------------------------------------------------------- /_posts/2014-01-25-rspec-rails-3-2-edition-free-extra.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Looking for the Rails 3.2 edition of Everyday Rails Testing with RSpec?" 4 | excerpt: "The previous edition of my book is now a free extra with all purchases of the current edition." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | I've had a few requests for the Rails 3.2-based version of *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)*, the last version of which was released in summer of 2013. I've decided to make it available as a free extra download with all purchases of the book. In a nutshell: Buy the current (Rails 4.0-based) version of the book, get the previous edition free. If you already bought the book, sign into your Leanpub account to access the download. 9 | 10 | The zip file includes PDF, EPUB, and MOBI formats of the book and are provided as-is for anyone who may still be working with an earlier version of Rails, RSpec, Capybara, and Factory Girl. 11 | 12 | I hope you find this useful! 13 | -------------------------------------------------------------------------------- /_posts/2014-02-08-everyday-rails-rspec-japanese.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Japanese translation of Everyday Rails Testing with RSpec" 4 | excerpt: "A Japanese version of my testing book is now for sale on Leanpub." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | I'm happy to tell you that *Everyday Rails Testing with RSpec* has been [translated to Japanese](https://leanpub.com/everydayrailsrspec-jp) and is now available on Leanpub. The team of translators has worked hard over the past several weeks to not only deliver this edition for Japanese-reading audiences, but also help me make the English version better by making several suggestions. For their efforts, they will receive 100% of the book royalties for the Japanese version. 9 | 10 | *Everyday Rails Testing with RSpec* is my practical guide to learning to test your Rails application using RSpec, Capybara, and Factory Girl. It's also available in [Chinese](https://leanpub.com/everydayrailsrspec-cn) and [English](https://leanpub.com/everydayrailsrspec). 11 | -------------------------------------------------------------------------------- /_posts/2014-02-27-git-reset-clean.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Git: Clean up and start over" 4 | excerpt: "Git makes it easy to experiment with ideas before committing them for posterity. Here's one way to get rid of those experiments when they go bad." 5 | tags: git 6 | --- 7 | 8 | Yes, this is still a Rails blog--but being productive in Rails means a lot more than just knowing Ruby and the framework. You also need to know your way around a version control system. That (hopefully) means Git. There are lots of excellent introductions to Git already available. If there's interest I can put together a list of some of my favorites. In the meantime, I thought I'd share some other Git workflows I use on a regular basis. Today, I want to share my process for those times when I've spiked some code I don't care to keep--or just made such a mess I want to back up and start over. 9 | 10 | This short workflow assumes you're already tracking a project with Git. It uses the following Git commands: 11 | 12 | - `git diff` 13 | - `git reset` 14 | - `git clean` 15 | 16 | This process will wipe out all uncommitted work. To hold onto this work for future reference, I like to save out a diff file: 17 | 18 | $ git diff > ~/Desktop/spike-cool-new-feature.diff 19 | 20 | Don't forget, `git diff` won't include new, untracked files unless you've staged them with `git add` first. 21 | 22 | To start cleaning, remove changes to files you're already tracking in your repository: 23 | 24 | $ git reset --hard HEAD 25 | 26 | This resets the contents of your project to their state at your most recent commit (`HEAD`). Again, the `--hard` flag is destructive--if you don't have a backup of your work-in-progress, it's gone! 27 | 28 | If you haven't added any new, untracked files since the previous commit, you're done. If you have, you can remove them all at once with 29 | 30 | $ git clean -fd 31 | 32 | The `-f` flag forces the clean; the `-d` tag applies it to untracked directories, too. These flags do not clean up files you're ignoring in your `.gitignore` file; you can add those with 33 | 34 | $ git clean -fdx 35 | 36 | **Take caution with the `-x` flag to `git clean`!** It's handy for cleaning out junk like temp files and old development logs, but it will also delete any other file you've specified Git to ignore. For example, your Rails project's *database.yml* file could get wiped out if you're not careful. I almost always find `git clean -fd` does what I need. 37 | 38 | After `git clean`, your workspace is as fresh as it was following your most recent commit: 39 | 40 | $ git status 41 | # On branch add-cool-new-feature 42 | nothing to commit, working directory clean 43 | 44 | I hope this little Git productivity boost has been helpful. If you have a different way to accomplish this task, I'd love to hear about it in the comments. Thanks for reading! 45 | -------------------------------------------------------------------------------- /_posts/2014-04-03-rspec-book-updates-spring-2014.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec: Upcoming updates for 2014" 4 | excerpt: "It's getting time for the book's annual-ish update. Here's a look at what's planned for the next version." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | Big changes are afoot for Rails and RSpec, which means it's almost time for another update to *Everyday Rails Testing with RSpec.* Here's a list of things I'm planning to address in this release. 9 | 10 | Don't forget, you can [buy the current version now](https://leanpub.com/everydayrailsrspec) and get these updates for free when they're released. 11 | 12 | ### Rails 4.1 13 | 14 | In all likelihood, Rails 4.1 will be released within the next few weeks. Of note, this update includes Spring, a Rails application preloader to speed up your tests' runs. In an effort to minimize extra dependencies, **Spring will replace Spork in the next version of the book.** 15 | 16 | ### RSpec 2.99 and 3.0 17 | 18 | The next releases of RSpec are still in beta, and their APIs are still shifting a bit. Once RSpec 3.0 goes final, I'll start the heaviest work of rewriting the code samples and updating content in the book to correspond with it. In the meantime, I'm going to **add a chapter on upgrading the existing sample application to RSpec 2.99** and preparing for RSpec 3.0. This will be included in an update in the next week or two. 19 | 20 | ### Capybara and Factory Girl 21 | 22 | Capybara and Factory Girl have been relatively stable since the last version, but chapters focusing on them will be updated and expanded as needed. 23 | 24 | ### New content 25 | 26 | I received some well-deserved criticism a little while back that I defer too frequently to Railscasts in some sections. That's fair, especially since Railscasts haven't been updated in nearly a year and some of the episodes I refer to are significantly older than that. With that in mind, I'm going to add content on the following topics: 27 | 28 | - Setting up Guard 29 | - Testing email 30 | - Testing integration with external web services 31 | 32 | I've also gotten a lot of questions and requests about testing your own application's API, so I'll be adding coverage of that as well. 33 | 34 | ### Timeline 35 | 36 | Unfortunately, I don't have a hard-set timeline for this work. Much of it depends on when RSpec 3.0's API is stable enough to begin my writing process. I'm also doubtful that the simple sample application presently used in the book can carry the weight of some of these new features, so there's a chance I may scrap it for a totally new example. I haven't decided yet. 37 | 38 | In the meantime, please [give the book a try](https://leanpub.com/everydayrailsrspec) if you haven't already. If you have thoughts on what you'd like to see change (or stay the same) in the next version, leave a comment below. I can't promise I'll be able to address every concern, but I'll do my best. 39 | -------------------------------------------------------------------------------- /_posts/2014-10-05-rspec-3-book-update.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec now updated for RSpec 3" 4 | excerpt: "RSpec 3.1, Rails 4.1 (and beyond), testing services, and more: Here's what's new." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | After a long summer, I'm happy to announce that *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)* has been updated for RSpec 3 and Rails 4.1 (and beyond). If you've already purchased the book, head over to Leanpub to download the latest edition for free. If you're new to the book, I hope you'll check it out. 9 | 10 | The book has evolved a lot since I first wrote those blog posts here, more than three years ago. However, the core message and approach are the same: You need to learn to test your Rails applications, and a great way to learn is by testing code you've already written. 11 | 12 | Here's a brief rundown of what's new: 13 | 14 | - Coverage of RSpec 3--RSpec 3.1 is used in this edition's examples. 15 | - Support for Rails 4.1 (and newer)--specifically, built-in support for Spring. 16 | - A bunch of new content around "testing the rest"--testing your app's API, use of external APIs, etc. I'm really happy with how this turned out, and hope you are, too. 17 | - New formatting, just in case I decide to do a print version. (That's still a big if.) I've opted for dimensions more like you'd see from books by mainstream technical publishers. 18 | 19 | Thanks as always for your support! 20 | -------------------------------------------------------------------------------- /_posts/2014-12-23-simple-data-dump-restore-yamldb.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Simple data transfer with YamlDB" 4 | excerpt: "Ever need to transfer data from one database to another? Here's a solution that worked for me." 5 | tags: data-migration 6 | --- 7 | 8 | I've got a very small side project going. So far, it's only been for my benefit--but last night I decided I'd like to go ahead and deploy it at some point soon, so I'd need to switch out the simple SQLite database with something more robust. I also had test data I wanted to migrate over, though. What was the simplest way to get data out of my preliminary SQLite database and into something I could eventually move up to my production server? 9 | 10 | Luckily, I'm not the first Ruby developer to run into this problem. And, there's already a nice Ruby library to handle this use case. Within a few minutes, I'd found [YamlDB](https://github.com/yamldb/yaml_db), exported my initial dataset, and restored it into a new database. 11 | 12 | I'd write up the process, but to be honest, there's not much to write. The YamlDB README pretty much covers the whole procedure. In my case: 13 | 14 | 1. I added `yaml_db` to my Gemfile. 15 | 2. I ran the `db:data:dump` Rake task. 16 | 3. I replaced `sqlite3` with my production database adapter (in this case, `mysql2`), and updated my *database.yml* file as needed. 17 | 4. I ran `rake db:create` to create my new development database. 18 | 5. I ran `rake db:migrate` to build out my new database and update the schema for a different ORM. 19 | 6. I ran the `db:data:load` Rake task to copy the exported data into the new database. 20 | 7. I removed `yaml_db` from my Gemfile, ran `bundle check` to clean up *Gemfile.lock*, and committed the changes (omitting the *data.yml* file created by the process). 21 | 22 | The whole process took less than five minutes. Now, this project is admittedly simple, with just a few data models and a couple thousand records at this point. I'll try it again in the future when I need to migrate a larger dataset, but in the meantime I was pleased enough with my initial results that I wanted to pass it along. 23 | -------------------------------------------------------------------------------- /_posts/2015-01-27-rspec-switch-selenium-poltergeist.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Switching from Selenium to Poltergeist in RSpec feature specs" 4 | excerpt: "A quick one, for readers of my RSpec book: Moving to a headless driver for faster JavaScript testing with Capybara." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | I was recently asked about how I test JavaScript-dependent features in RSpec. In [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec), I demonstrate using Selenium for this type of test. As I note there, though, and as you've no doubt found for yourself, spawning a browser window each time is slow. It's also not compatible with continuous integration services like Jenkins or Travis CI. That's where headless drivers like Poltergeist and capybara-webkit come into play. They're capable of running JavaScript, like Selenium, but don't require an external browser. 9 | 10 | In my own work, I use [Poltergeist](https://github.com/teampoltergeist/poltergeist) for these tests. Poltergeist is a Ruby wrapper for the [PhantomJS headless browser](http://phantomjs.org), so you'll have to install PhantomJS first. I recommend using your operating system's built-in package manager to do this, when possible. On my Mac, I use [Homebrew](http://brew.sh) (`brew install phantomjs`). If you're on Windows, or just not sure, [download and run the installer](http://phantomjs.org). 11 | 12 | With installation out of the way, you can now install Poltergeist and configure it to be your test suite's driver for JavaScript-dependent tests. First, add it to your *Gemfile*: 13 | 14 | group :test do 15 | # Other testing gems ... 16 | gem 'poltergeist' 17 | # Go ahead and remove selenium-webdriver, if needed 18 | end 19 | 20 | Run `bundle install` to install the gem. 21 | 22 | Next, configure RSpec to use it. Add the following to your *spec/rails_helper.rb* file. (If you're still using RSpec 2.x, you'll add this to *spec/spec_helper.rb*): 23 | 24 | require 'capybara/poltergeist' 25 | Capybara.javascript_driver = :poltergeist 26 | 27 | Now, run your test suite--or at least run your feature specs, or your feature specs that require JavaScript. If everything is set up correctly, you should see them run in your terminal, but not in a Firefox window. 28 | 29 | In addition to speeding up your test runs, Poltergeist provides some advanced features. I don't use these often, but they are handy from time to time, particularly for debugging tests. I encourage you to refer to [Poltergeist's README](https://github.com/teampoltergeist/poltergeist) to learn more. 30 | -------------------------------------------------------------------------------- /_posts/2015-08-09-redesign-2015-notes.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails redesign for 2015: Initial notes and reflections" 4 | excerpt: "A behind-the-scenes look at the tools and decisions that led to the first major redesign of Everyday Rails in three years." 5 | --- 6 | 7 | I know you're not supposed to do Friday night deploys, but two nights ago I couldn't resist running my little script that builds this Jekyll site and rsyncs it to my server. And with that, the first major redesign of Everyday Rails in more than three years went live. Even though it's not a Rails project, I wanted to share a few reflections on the tools I used and decisions I made. 8 | 9 | ## Tools 10 | 11 | - **Bootstrap 3:** I stuck with Bootstrap for the redesign, upgrading from version 2 to 3 and taking advantage of some of its mobile-first features. I like CSS frameworks for the same reason I like good frameworks in general—people much smarter than I have taken the time to make sure things look nice and work as they should across a variety of browsers and devices. And of the front-end frameworks out there, I still think that Bootstrap provides the best out-of-box experience and look. 12 | - **Gulp:** On any new project, I try to apply something new (or new to me). On this, I decided to try out JavaScript-based tooling for front-end matters like compiling Sass and (eventually) minifying and generally optimizing some files. I'm still feeling my way around some of that. There are a lot of tutorials out there for it, but they often contradict one another. 13 | 14 | ## Decisions 15 | 16 | - **Sticking with Jekyll:** When I first decided that Everyday Rails needed a facelift, I planned to switch out Jekyll for the Middleman static site generator. Nothing against Jekyll, but I like Middleman's tooling. I've used it for a few years on my personal blog now. In the end, I decided that Jekyll does what I need for Everyday Rails. 17 | - **Dropping the hero:** The previous redesign sort of coincided with the release of *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)*, so of course I wanted to feature it prominently. In 2012, Bootstrap's hero element was *the* way to do things like that. But that element was arguably the most dated part of the old site, and I always cringed a bit at how much real estate it took up (especially on mobile). 18 | 19 | I like the sticky sidebar solution better--it allows me to keep some visibility on the book, but not as obtrusively. It's functionally still a work-in-progress (still tweaking pixel widths) but overall I'm happy with how it turned out. 20 | - **No more comments:** I struggled with this one for a bit, but decided to remove comments functionality from Everyday Rails. This has less to do with the bad reputation that Internet comments sections have earned themselves, and more to do with reducing page clutter. I understand that Disqus needs to make money, and I was using their services for free, but I wasn't happy with add-ons they started applying a year ago or so. And it was one more thing to try to style correctly. So I pulled it. I've re-enabled comments, per several requests. 21 | 22 | It's not that I don't want to hear from you, though. I do. My contact information is in the navigation bar, and I'm generally findable online. 23 | 24 | ## Still to come 25 | 26 | - **Optimization:** As mentioned earlier, I have some work to do around asset optimization and general front-end performance matters. It's been a little while since I've done much front-end work, so I'm learning and re-learning some things and will roll them out as I go. 27 | - **Accessibility:** I'm also keenly aware that some of the decisions I've made may not lend themselves to accessibility tools such as screen readers. It's not because I don't care; it's because I'm admittedly ignorant about the best practices for making modern web sites work well with these devices. Things have come a long way since just making sure things look nice in Lynx. I'm learning, and appreciate your understanding. 28 | 29 | In the meantime, I hope you enjoy the new look. Now I need to get better at putting more new content into it! 30 | -------------------------------------------------------------------------------- /_posts/2015-08-27-atom-package-rspec.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Using RSpec in Atom" 4 | excerpt: "I love how extensible GitHub's Atom editor is. Here are some useful packages for using it to edit and run RSpec tests." 5 | image: "/images/posts/atom-header.jpg" 6 | tags: rspec 7 | --- 8 | 9 | I've been using [Atom](http://atom.io) as my primary code editor since June. My favorite feature is how easy it is to customize the editing environment with tools we know as web developers, then share those customizations with others through Atom's packages system. My first contribution to the Atom ecosystem is [atom-everydayrails-rspec](https://atom.io/packages/atom-everydayrails-rspec), a collection of snippets for writing RSpec tests--specifically, some shortcuts for spec organization, Capybara, expectations, and some Factory Girl. If you've read [my book on Rails testing](https://leanpub.com/everydayrailsrspec), these should all look familiar. 10 | 11 | The package is intentionally light on features. I've been adding snippets as I've needed them--so if a snippet is missing, it may just be that I haven't written a spec lately that needed it. I also still prefer to run specs in a terminal window, though there are other Atom packages for those who'd prefer to stay inside the editor. 12 | 13 | If you check it out, please let me know what you think. If you've got an idea for a snippet, pull requests are welcome! 14 | 15 | ## Other RSpec packages for Atom 16 | 17 | If you *are* interested in running your specs from inside Atom, I suggest checking out Felipe Coury's [atom-rspec](https://atom.io/packages/rspec) package. It's a simple runner that lets you choose from running all specs in a file, only the spec at the editor's current line, or your entire suite. 18 | 19 | Finally, there's [language-rspec](https://atom.io/packages/language-rspec), a port of TextMate's extensive RSpec plugin, and [capybara-snippets](https://atom.io/packages/capybara-snippets), which at present has some snippets that the Everyday Rails package is missing. 20 | 21 | What are your favorite Atom packages and hacks? Please share by adding a comment. 22 | 23 | *Photo: Cropped version of [cyclotron by Robert Couse-Baker](https://www.flickr.com/photos/29233640@N07/6781174568/).* -------------------------------------------------------------------------------- /_posts/2017-01-23-your-rails-code-base.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Ask the reader: What versions of Rails do your apps currently use?" 4 | excerpt: "An experiment! This week, let's have an open floor discussion about Rails versions in production, and what keeps us from upgrading sooner." 5 | --- 6 | 7 | I had to travel this weekend, and the twelve hours or so I spent driving over the last couple of days meant I didn't have time to write a new post for the week. So I thought it would be a good opportunity to try a different format I've been thinking about, to learn more about people who read this blog. I want to hear your stories! 8 | 9 | **I'm really curious about which version of Rails people use these days.** Are your apps built on the latest and greatest version of the framework? (At the time of this writing, that'd be 5.0.1.) If so, and you didn't start at the latest, how difficult was it to upgrade? And if not, which version of Rails are you using? What's holding you back from upgrading to the latest version? 10 | 11 | **If you'd like to share your story, please leave a comment below.** I'll prime the discussion: I currently maintain three applications in production environments, excluding personal projects. Two are on the current patch level for Rails 4.2. One of those was upgraded from 3.2 last summer, and I intend to upgrade them to 5.0 in the next few months (possibly in time for 5.1 to arrive). The other is at Rails 3.2, and is actively being updated to 4.2. The main challenge with getting it upgraded is complexity: It's an older app, and many techniques it employs have been deprecated along the way. My hope is that the changes being made now will help make future Rails upgrades easier. 12 | 13 | **Thanks in advance for your participation.** If this goes well, I may do this again from time to time, with different questions. 14 | -------------------------------------------------------------------------------- /_posts/2017-02-20-book-status-report-february-2017.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Status report: Everyday Rails Testing with RSpec for RSpec 3.5 and Rails 5" 4 | excerpt: "A progress report on the latest version of my Rails testing book." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | Hello friends, I wanted to give you a brief update on my progress updating *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)* for RSpec 3.5 and Rails 5. When I [announced the updates in December](/2016/12/05/rspec-book-rails-5.html), I estimated that I'd have a rough version ready for download by mid-February. Unfortunately, I'm behind on that schedule, but I think the book and I are both better off for the slower pace. 9 | 10 | The biggest reason for the delay is **I've been rewriting more content from scratch than I originally planned**. Throughout the process, I've been carefully evaluating each section. Is it still relevant? Is it still something I use in my own tests on a regular basis? Is there a better way to explain it? 11 | 12 | As a result, I've **added some new material, heavily altered some, and completely removed some concepts from the book**. The chapter on Factory Girl was a total rewrite. The three chapters on controller testing have been collapsed into one, with a focus on where controller specs are still relevant in Rails 5. And chapters like the one on feature testing are a mix of old concepts and new. 13 | 14 | There's still a lot to do, but I'm happy with what's been finished so far. I work on it every day, though as with many writing and coding projects, some of those days are less typing and more research and thinking. My new goal is to have **something to share with you around the time of Railsconf**. I know that's a couple of months later than planned, but it's turning out to be more realistic. 15 | 16 | As a reminder, **this release will still be a free upgrade for everyone**. Whether you bought it five years ago or five minutes ago, you'll be able to download the new version from Leanpub when it's available. For the early adopters, I hope you'll appreciate **my slightly opinionated take on testing Rails apps in 2017**. For new readers, I'm confident that *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)* is still the best way to get up and running with tests in your own apps. 17 | 18 | Thanks again for your support and patience. If you have any questions, please leave a comment below. 19 | -------------------------------------------------------------------------------- /_posts/2017-06-20-rspec-book-2017-updates.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updated for 2017" 4 | excerpt: "I've released the first seven chapters (plus one) of an all new edition of my popular introduction to RSpec for Rails. Here's what's new, and what to expect next." 5 | tags: rspec rspec-book 6 | --- 7 | 8 | I'm happy and excited to let you know that a new release of _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_ is now available. Unlike earlier updates, this is a **major rewrite** of the book. Some of the highlights include: 9 | 10 | - Coverage of **RSpec 3.6** and **Rails 5.1** 11 | - An all-new sample application 12 | - Overhauled coverage of controller testing 13 | - Expanded coverage of API testing 14 | 15 | Perhaps more importantly than specific RSpec or Rails features, though, this new edition also reflects my **evolving opinions on testing, and how to teach others how to test**. So even if you've read the book in the past, you may enjoy giving it another skim. Oh yeah, this is a **free update** for everyone who's ever purchased a copy in the past, as a thank you for your support. Head over to your [Leanpub library](https://leanpub.com/user_dashboard/library) to get the latest copy, if you haven't already. 16 | 17 | In the spirit of lean publishing, I've made the **first seven chapters available**. Over the next few weeks, I'll be wrapping up and releasing the remaining chapters. Here's what to expect soon: 18 | 19 | - A new chapter on the DRY principle as it applies to tests 20 | - A new chapter on testing in isolation 21 | - An updated chapter on testing the rest, including external API integration, email, file uploads, and more 22 | - A step-by-step walk through a test-first coding session 23 | 24 | In the meantime, if you notice anything that needs correction, please let me know by adding an issue on the [sample code's GitHub repository](https://github.com/everydayrails/everydayrails-rspec-2017/issues). 25 | 26 | Finally, if you don't mind, I'd greatly appreciate it if you could **help me spread the word** about this new release. I'm closing in on 6,000 total sales of the book, and would love to cross that threshold by the time the final chapter of this edition is released! 27 | 28 | Thanks again for your support, and I hope you enjoy this new edition of the book. 29 | -------------------------------------------------------------------------------- /_posts/2017-10-19-rspec-book-2017-complete.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "2017 edition of Everyday Rails Testing with RSpec is content-complete!" 4 | excerpt: "The final chapter of my Rails testing book is now available for download. Here's what's new, and what's coming next." 5 | tags: rspec-book rspec 6 | --- 7 | 8 | I'm happy to announce that chapter 11 of my book, _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_, is available for download. This chapter, "Toward test-driven development," was the final chapter of the book I needed to update for 2017. In it, I take you through step-by-step development of a feature, TDD-style, with commentary on outside-in testing and the red-green-refactor cycle. 9 | 10 | If you were waiting for a content-complete version of the book to be available, now's a great time to check it out. Of course, if you already own a copy, this is a free update. [Head over to your Leanpub library](https://leanpub.com/user_dashboard/library) to download your copy. 11 | 12 | ## What's next 13 | 14 | I'm very proud of this version of the book. It took more time than I'd anticipated to do, but it honestly reflects my approach to testing Rails applications in 2017. I hope you find the new content informative. Going forward, I've got a few more pieces planned: 15 | 16 | - I'm currently working on fixing [a few issues](https://github.com/everydayrails/everydayrails-rspec-2017/issues) that readers have reported. A maintenance release will contain these fixes in the next week or so. If you've found something confusing or incorrect, please let me know by [posting an issue on the book's GitHub repository](https://github.com/everydayrails/everydayrails-rspec-2017/issues). 17 | - I've already been asked when the book will be updated for RSpec 3.7, which was released earlier this week. I'm not ready to make this update just yet, but I do plan on writing a bit on upgrading a project to the new version and its support for Rails 5.1-style system tests. I'll share this as a blog post, and possibly an appendix to the book. In the meantime, everything I cover in the new edition of the book still applies to RSpec 3.7, and will continue to do so for the foreseeable future. 18 | - I've also been involved in some lively conversations related to other aspects of testing. Look for posts in the coming weeks about measuring test coverage, writing testable code, and keeping feature specs organized. 19 | -------------------------------------------------------------------------------- /_posts/2018-04-21-rspec-book-status-spring-2018.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Status report: Everyday Rails Testing with RSpec updates for spring 2018" 4 | excerpt: "A progress report on the latest round of updates to my Rails testing book." 5 | tags: rspec rspec-book 6 | image: "/images/posts/astoria-sunset.jpg" 7 | --- 8 | 9 | As you may have seen on social media or GitHub, I've been working on addressing feedback provided by the wonderful team who translate _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_ to Japanese readers. I thank them for their help in making the book useful to all readers. 10 | 11 | It's been a slower process than usual, due to a recent death in my immediate family, and preparation for my upcoming move of roughly 2,000 miles from Kansas to Oregon. Do I know anyone in or around Astoria? What tech events should I start checking out in the Pacific Northwest? 12 | 13 | Anyway, the rest of my family is already in our new home--including our five cats, who spent more than two days in a van with a professional pet mover (I recently learned there are professional pet movers). I spend pretty much all of my time right now packing and getting our old house ready to sell. I've not had time to address all the suggestions made on GitHub, but if you look at ones tagged _pending release_, you can see ones that have been addressed. 14 | 15 | I'll get through the remaining issues, though, and release an update when I'm done. I'm still really happy with this edition of the book, and the concepts I wrote in for last year still apply to the current Rails testing landscape. 16 | 17 | As usual, this will be a free update to all readers. People who [purchase through Leanpub](https://leanpub.com/everydayrailsrspec) will get the updates first, then I'll figure out how to update the book on Amazon. 18 | 19 | Thanks for your patience! And remember, if you notice something confusing, outdated, or incorrect in the book, the best thing to do is [check the known issues on the sample source's GitHub project](https://github.com/everydayrails/everydayrails-rspec-2017/issues), and open a new one if necessary. That not only helps me, it helps other readers who may have the same confusion. And a lot of times, another reader may be able to answer questions before I'm able to get to it. 20 | 21 | Thanks again, and I look forward to my next post here coming to you from Astoria! 22 | -------------------------------------------------------------------------------- /_posts/2018-07-18-ruby-podcasts.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "My recent appearances on Ruby podcasts" 4 | excerpt: "In case you missed it, I've guested on a couple of podcasts in 2018." 5 | --- 6 | 7 | I've been a guest on a couple of podcasts over the past few months, and I can't tell you how weird it is to be refreshing your podcast feed, and see your name pop up in the new episodes to download. I hope you'll give these shows a listen. Are there other podcasts I should try to appear on? 8 | 9 | ### [Ruby Rogues: Removing business logic from controllers](https://devchat.tv/ruby-rogues/rr-353-removing-business-logic-from-rails-controllers-with-aaron-sumner) 10 | 11 | I joined Charles Max Wood and David Richards for this episode of the long-running Ruby Rogues podcast, released March 13, 2018. Our conversation centered around my blog posts on rewriting controllers to make them easier to test. We talked about the pros and cons of various approaches to this, gradual code improvement, and more. 12 | 13 | ### [The Ruby Testing Podcast](http://www.rubytestingpodcast.com/aaron-sumner) 14 | 15 | I was honored to be guest number three on Jason Swett's brand-new, testing-centric podcast. If you ever wanted to hear more detail about how I used deliberate practice to learn testing, RSpec, and test-driven development, please check it out. I also encourage you to give the earlier two episodes a listen. 16 | -------------------------------------------------------------------------------- /_posts/2018-08-22-rspec-book-updates-august-2018.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec book updates for August 2018" 4 | excerpt: "A new version of my book, featuring a migration to system specs and a couple of major errata fixes, is ready for download from Leanpub!" 5 | tags: rspec-book 6 | --- 7 | 8 | I've got a new version of _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_ ready for download from Leanpub. I originally wasn't planning to do any further updates to this version, but changes in the Devise and Geocoder gems broke sample tests. I've fixed those issues, along with some others that have been reported by readers. 9 | 10 | As an added bonus, I've added an appendix to guide the transition to system specs. It's based on [a post I shared here earlier this year](https://everydayrails.com/2018/01/08/rspec-3.7-system-tests.html), but updated slightly for RSpec 3.8. System specs were added to RSpec within days of my last major release, and an overhaul of chapter 6 is out-of-scope for this release. But hopefully this new appendix will help you learn more about the new, recommended approach to testing your apps' browser integration. 11 | 12 | Finally, I have a favor to ask. I've been offering free updates to this book since its original release more than six years ago. If you've found it useful, please recommend it to your friends and colleagues. Your tweets, toots, and shares are much appreciated. 13 | 14 | Thanks as always for your support! 15 | -------------------------------------------------------------------------------- /_posts/2020-04-15-rspec-book-price-changes.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails Testing with RSpec book price changes" 4 | excerpt: "Want a legit copy of my Rails testing book for free, or heavily discounted?" 5 | tags: rspec-book 6 | --- 7 | 8 | Hello, I apologize for not posting here in almost a year, but I wanted to let you know about some pricing changes to my Rails testing book, _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_. 9 | 10 | I know many software developers have lost their jobs in the current global health and economic crisis. If you or someone you know has been affected, I'm offering the book to you for free, no questions asked, for the foreseeable future via a [coupon code](http://leanpub.com/everydayrailsrspec/c/stayathome). If it helps you learn a skill that lands you your next job, please let me know! 11 | 12 | If you're like me and lucky enough to still have a job, but you're interested in getting started with sound software testing practices in Rails, I'd love it if you check out _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_ to start learning! You'll learn how to write a complete test suite for your Rails applications, using the same approach I did when I learned, myself. 13 | 14 | Sales of the book do help augment my salary a bit, and allow me to save for rainy days. I've lowered the minimum price to $10 USD to help more people get started. 15 | 16 | And to everyone who's supported my work over the years, thank you very much! I'm hoping to write more here soon as I begin working in more new (to me) code bases than I have for the past several years. I'm a big believer in sharing what I learn. I was hoping to hang out with some of you at Railsconf this year, but perhaps another time. 17 | -------------------------------------------------------------------------------- /_posts/2020-05-25-newsletters-for-rails-developers.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "5 great newsletters for the productive Rails developer" 4 | excerpt: "Here are my favorite subscriptions for keeping up with Rails, Ruby, and my world of software development." 5 | --- 6 | 7 | We're in a golden era of email newsletters, especially curated collections of links to useful information for software developers. I love that newsletters--especially those published by ethical, trusted sources--let me keep up-to-date on what I need to know, without dealing with the data overload and inherent toxicity of social media or online discussion boards. 8 | 9 | My advice: Subscribe to lots of newsletters pertaining to your field of interest, and its periphery. Don't feel the need to click every link--but if you notice a particular item shared in multiple lists, maybe it's worth checking out. 10 | 11 | Here are my favorite subscriptions for keeping up with Rails, Ruby, and my world of software development. Oh, and you'd like a good way to keep up with Everyday Rails, I've got a [newsletter] of my own, too! 12 | 13 | [newsletter]: http://eepurl.com/nRW0z 14 | 15 | 16 | ## Ruby Weekly 17 | 18 | Peter Cooper's [Ruby Weekly] helped kick off the popularity of newsletters, and as I write this recently celebrated its 500th issue! This is a must-subscribe for all Ruby developers, and I always look forward to spending some of my time each Thursday perusing it. 19 | 20 | [Cooperpress] publishes a number of other newsletters, too, on Javascript, front-end-development, databases, mobile development, and more. 21 | 22 | [Ruby Weekly]: https://rubyweekly.com 23 | [Cooperpress]: https://cooperpress.com/publications/ 24 | 25 | 26 | ## Hacker Newsletter 27 | 28 | Kale Davis finds the best content from Hacker News and shares it in [Hacker Newsletter]. While still heavily tech-heavy and software-focused, Hacker Newsletter also shares ideas about career growth, learning, society, and design. I typically spend time each weekend with this list, and always learn something from it. 29 | 30 | [Hacker Newsletter]: https://hackernewsletter.com 31 | 32 | 33 | ## DEV newsletter 34 | 35 | When you sign up for an account with the [DEV] online developers community, you'll be invited to subscribe to their weekly newsletter. Do it! The DEV Newsletter highlights community-created content, and helps spread the knowledge of independent tech writers. 36 | 37 | [DEV]: https://dev.to 38 | 39 | 40 | ## Changelog Weekly 41 | 42 | You may be familiar with the Changelog podcast, but did you know they also have newsletters? Changelog Weekly includes links to the latest episodes of the many podcasts currently in their stable, as well as curated links and editorial commentary on the latest open source and software development news. 43 | 44 | [Changelog]: https://changelog.com 45 | [Changelog Weekly]: https://changelog.com/weekly 46 | 47 | 48 | ## Changelog Nightly 49 | 50 | Unlike the other newsletters in this list, [Changelog Nightly] is published--wait for it--on a nightly basis. It's also not human-curated, but based on GitHub's public event data to share trending open source repositories. I give it a quick skim each morning, and often learn about my new favorite command line tool or library a week or two before it hits other newsletters. 51 | 52 | [Changelog Nightly]: https://changelog.com/nightly 53 | -------------------------------------------------------------------------------- /_posts/2020-07-06-modular-rails-templates-rails-bytes.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Rails application templates made even easier with Rails Bytes" 4 | excerpt: "Application templates aren't just for new Rails apps! Stop copy-pasting configurations and get back to productivity with modular templates from this promising new service." 5 | --- 6 | 7 | It's no secret that **I love Rails application templates**. The [second post I ever wrote here], ten years ago, was about application templates, and I wrote an update for [app templates in Rails 3] a year later, when Thor was introduced as the DSL of choice for templates. It's what's still used today with Rails 6. 8 | 9 | **What's an application template?** Think of the gems you often add to your Rails applications. Gems like RSpec, or Devise, or Active Admin (to name only a few I've recently installed myself) don't just require a `bundle install` to add; you may also need to add initializers, tweak configurations, or run migrations. That's where application templates come in--instead of copy and pasting code and commands from a README, the template scripts these steps, so you can get back to Rails productivity mode even more quickly. Convention over configuration, for the win. And it's built into Rails. 10 | 11 | Here's something I didn't know about until recently, though: **Application templates aren't just for new Rails apps!** For some reason, I had assumed a template was an all or nothing deal, and have been guilty of creating a few overly complex, _one-template-to-rule-them-all_ templates to try to cover all my various application needs. These have proven hard to maintain, and require a lot of up-front decisions about a new Rails application to be at all effective. 12 | 13 | But it turns out, you can run `rails app:template LOCATION=