├── .ruby-version ├── _plugins └── ext.rb ├── favicon.ico ├── apple-icon.png ├── images ├── box.png ├── banner.png ├── hover.png ├── linode.png ├── mug2022.jpg ├── logo-small.png ├── logo-square.png ├── rspec_book.jpg ├── posts │ ├── sad-mac.png │ ├── brakeman.png │ ├── hacker-cat.jpg │ ├── thumbs-up.jpg │ ├── atom-header.jpg │ ├── docker │ │ ├── boxes.jpg │ │ └── ruby-box.jpg │ ├── astoria-sunset.jpg │ ├── simplecov-header.jpg │ ├── git-log-header-large.jpg │ ├── legacy-intro-header.jpg │ └── pronto-github-actions.png ├── rspec-book-xl.jpg ├── rspec_book_large.jpg ├── rspec_book_med.jpg ├── rspec-book-2024-xl.jpg ├── left-of-the-dev-logo.png └── ccheart_black.svg ├── rspecbook ├── code.zip ├── everydayrailsrspec-5.1.zip └── index.markdown ├── img ├── glyphicons-halflings.png └── glyphicons-halflings-white.png ├── tailwind.config.js ├── .gitignore ├── missing.markdown ├── Gemfile ├── blm.markdown ├── _layouts ├── tags.html ├── main.html ├── default.html ├── post.html └── wide.html ├── config.rb ├── archives.html ├── postcss.config.js ├── js └── npm.js ├── thanks.html ├── _config.yml ├── index.html ├── _includes ├── book_cta.html ├── nav.html ├── footer.html ├── social.html ├── disqus.html ├── referrals.html ├── header.html └── sidebar.html ├── _posts ├── 2024-11-26-rspec-book-november-2024.markdown ├── 2024-10-10-rspec-book-october-2024-announcement.markdown ├── 2024-12-29-rspec-book-december-2024-announcement.markdown ├── 2014-02-08-everyday-rails-rspec-japanese.markdown ├── 2014-01-25-rspec-rails-3-2-edition-free-extra.markdown ├── 2013-09-09-rspec-book-chinese-translation.markdown ├── 2024-09-04-rspec-book-september-2024-announcement.markdown ├── 2018-07-18-ruby-podcasts.markdown ├── 2025-04-05-rspec-book-april-2025-announcement.md ├── 2010-06-19-rails-template-generator.markdown ├── 2014-10-05-rspec-3-book-update.markdown ├── 2018-08-22-rspec-book-updates-august-2018.markdown ├── 2024-07-21-rspec-book-july-2024-announcement.markdown ├── 2012-08-03-rspec-book-updates.markdown ├── 2013-11-15-i-wrote-a-view-spec.markdown ├── 2020-04-15-rspec-book-price-changes.markdown ├── 2011-06-16-rails-form-cancel-links.markdown ├── 2013-08-21-rspec-book-rails-4-final-release-notes.markdown ├── 2024-05-20-railsconf-book-discount-2024.markdown ├── 2017-01-23-your-rails-code-base.markdown ├── 2013-02-13-rspec-book-updates-capybara.markdown ├── 2011-03-11-rails-obfuscated-urls-friendly-id.markdown ├── 2012-11-14-rspec-book-news.markdown ├── 2025-05-18-happy-birthday.md ├── 2010-07-30-nifty-generators-rails-3.markdown ├── 2014-12-23-simple-data-dump-restore-yamldb.markdown ├── 2013-05-20-obfuscated-data-screenshots.markdown ├── 2015-08-27-atom-package-rspec.markdown ├── 2010-08-04-more-free-ruby-rails-books.markdown ├── 2017-06-20-rspec-book-2017-updates.markdown ├── 2021-04-05-rspec-tutorial-mimemagic-fix.markdown ├── 2018-04-21-rspec-book-status-spring-2018.markdown ├── 2025-09-16-rspec-book-rails-7.md ├── 2017-10-19-rspec-book-2017-complete.markdown ├── 2020-12-03-plausible-analytics.markdown ├── 2017-02-20-book-status-report-february-2017.markdown ├── 2015-01-27-rspec-switch-selenium-poltergeist.markdown ├── 2013-04-24-rspec-book-updates.markdown ├── 2010-05-22-bootstrapping-rails-template.markdown ├── 2010-11-16-rails-ancestry-tree.markdown ├── 2024-01-14-github-actions-devcontainer-ci.markdown ├── 2024-02-24-rails-just-commands.markdown ├── 2010-10-16-rails-documentation-tools.markdown ├── 2014-02-27-git-reset-clean.markdown ├── 2021-07-31-rails-custom-deprecation-warnings.markdown ├── 2010-06-03-ruby-toolbox.markdown ├── 2014-04-03-rspec-book-updates-spring-2014.markdown ├── 2012-06-13-rspec-book-complete.markdown ├── 2024-02-06-rspec-book-announcement-rails-7-1.markdown ├── 2025-03-09-dotfiles-gh-extensions.md ├── 2025-01-07-aider-ai-dev-container.markdown ├── 2020-08-24-deliberate-learning-1.markdown ├── 2011-05-08-rails-3.1-beta-rvm.markdown ├── 2011-04-03-simple-rails-project-backups.markdown ├── 2014-01-15-outside-in-example-ruby-tapas.markdown ├── 2020-05-25-newsletters-for-rails-developers.markdown ├── 2020-07-06-modular-rails-templates-rails-bytes.markdown ├── 2011-05-26-rails-smtp-development.markdown ├── 2010-06-16-authorization-restful-acl-1.markdown ├── 2024-05-04-rspec-book-status-may-2024.markdown ├── 2011-04-28-rails-try-method.markdown ├── 2010-07-18-understanding-rest-and-routes.markdown ├── 2011-01-25-passenger-3-rvm.markdown ├── 2012-09-11-bundler-rails-specify-versions.markdown ├── 2010-06-10-rails-footnotes.markdown ├── 2010-12-17-rails-admin-panel.markdown ├── 2013-07-16-july-2013-book-updates.markdown ├── 2012-05-07-everyday-rails-rspec-book-available.markdown ├── 2015-08-09-redesign-2015-notes.markdown └── 2023-12-07-rspec-resilient-matchers.markdown ├── atom.xml ├── package.json ├── justfile ├── _css └── tailwind.css ├── netlify.toml ├── README ├── contact.html ├── css └── tomorrow-night.css └── about.markdown /.ruby-version: -------------------------------------------------------------------------------- 1 | 3.4 2 | -------------------------------------------------------------------------------- /_plugins/ext.rb: -------------------------------------------------------------------------------- 1 | require "jekyll/tagging" 2 | -------------------------------------------------------------------------------- /favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/favicon.ico -------------------------------------------------------------------------------- /apple-icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/apple-icon.png -------------------------------------------------------------------------------- /images/box.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/box.png -------------------------------------------------------------------------------- /images/banner.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/banner.png -------------------------------------------------------------------------------- /images/hover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/hover.png -------------------------------------------------------------------------------- /images/linode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/linode.png -------------------------------------------------------------------------------- /images/mug2022.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/mug2022.jpg -------------------------------------------------------------------------------- /rspecbook/code.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/rspecbook/code.zip -------------------------------------------------------------------------------- /images/logo-small.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/logo-small.png -------------------------------------------------------------------------------- /images/logo-square.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/logo-square.png -------------------------------------------------------------------------------- /images/rspec_book.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/rspec_book.jpg -------------------------------------------------------------------------------- /images/posts/sad-mac.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/sad-mac.png -------------------------------------------------------------------------------- /images/rspec-book-xl.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/rspec-book-xl.jpg -------------------------------------------------------------------------------- /images/posts/brakeman.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/brakeman.png -------------------------------------------------------------------------------- /images/posts/hacker-cat.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/hacker-cat.jpg -------------------------------------------------------------------------------- /images/posts/thumbs-up.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/thumbs-up.jpg -------------------------------------------------------------------------------- /images/rspec_book_large.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/rspec_book_large.jpg -------------------------------------------------------------------------------- /images/rspec_book_med.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/rspec_book_med.jpg -------------------------------------------------------------------------------- /images/posts/atom-header.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/atom-header.jpg -------------------------------------------------------------------------------- /images/posts/docker/boxes.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/docker/boxes.jpg -------------------------------------------------------------------------------- /images/rspec-book-2024-xl.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/rspec-book-2024-xl.jpg -------------------------------------------------------------------------------- /img/glyphicons-halflings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/img/glyphicons-halflings.png -------------------------------------------------------------------------------- /images/left-of-the-dev-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/left-of-the-dev-logo.png -------------------------------------------------------------------------------- /images/posts/astoria-sunset.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/astoria-sunset.jpg -------------------------------------------------------------------------------- /images/posts/docker/ruby-box.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/docker/ruby-box.jpg -------------------------------------------------------------------------------- /images/posts/simplecov-header.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/simplecov-header.jpg -------------------------------------------------------------------------------- /img/glyphicons-halflings-white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/img/glyphicons-halflings-white.png -------------------------------------------------------------------------------- /images/posts/git-log-header-large.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/git-log-header-large.jpg -------------------------------------------------------------------------------- /images/posts/legacy-intro-header.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/legacy-intro-header.jpg -------------------------------------------------------------------------------- /rspecbook/everydayrailsrspec-5.1.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/rspecbook/everydayrailsrspec-5.1.zip -------------------------------------------------------------------------------- /images/posts/pronto-github-actions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/everydayrails/everyday-rails/HEAD/images/posts/pronto-github-actions.png -------------------------------------------------------------------------------- /tailwind.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | purge: [], 3 | theme: { 4 | extend: {}, 5 | }, 6 | variants: {}, 7 | plugins: [], 8 | } 9 | -------------------------------------------------------------------------------- /.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 | mise.local.toml 15 | -------------------------------------------------------------------------------- /missing.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Page not found 4 | excerpt: "A blog about using the Ruby on Rails web application framework to get stuff done as a web developer. New content a few times a week." 5 | --- 6 | 7 | Sorry, the page you're looking for isn't here. -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /blm.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Black Lives Matter 4 | excerpt: 5 | --- 6 | 7 | I stand with the Black community against systemic racism, police 8 | violence and brutality, intolerance, and hate in the United States 9 | and worldwide. We must all demand better from our leaders, and 10 | ourselves. Stop tolerating intolerance. 11 | -------------------------------------------------------------------------------- /_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 | -------------------------------------------------------------------------------- /config.rb: -------------------------------------------------------------------------------- 1 | # Require any additional compass plugins here. 2 | # Set this to the root of your project when deployed: 3 | http_path = "/" 4 | css_dir = "stylesheets" 5 | sass_dir = "src" 6 | images_dir = "images" 7 | javascripts_dir = "javascripts" 8 | # To enable relative paths to assets via compass helper functions. Uncomment: 9 | # relative_assets = true 10 | -------------------------------------------------------------------------------- /_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 | -------------------------------------------------------------------------------- /archives.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Archives 4 | excerpt: "A blog about using the Ruby on Rails web application framework to get stuff done as a web developer. New content every few weeks." 5 | --- 6 | 7 | {% for post in site.posts %} 8 |
9 |

{{ post.title }}

10 | 11 | {{ post.excerpt }} 12 | 13 | ({{ post.date | date: "%B %d, %Y" }}) 14 | 15 |
16 | {% endfor %} 17 | -------------------------------------------------------------------------------- /_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 | -------------------------------------------------------------------------------- /postcss.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | plugins: [ 3 | require("tailwindcss"), 4 | require("autoprefixer"), 5 | process.env.NODE_ENV === 'production' && require("@fullhuman/postcss-purgecss")({ 6 | content: [ 7 | "./_posts/*.markdown", 8 | "./_layouts/*.html", 9 | "./_includes/*.html", 10 | "./*.html", 11 | ], 12 | defaultExtractor: content => content.match(/[A-Za-z0-9-_:/]+/g) || [], 13 | whitelist: ["pre"] 14 | }), 15 | ] 16 | } -------------------------------------------------------------------------------- /js/npm.js: -------------------------------------------------------------------------------- 1 | // This file is autogenerated via the `commonjs` Grunt task. You can require() this file in a CommonJS environment. 2 | require('../../js/transition.js') 3 | require('../../js/alert.js') 4 | require('../../js/button.js') 5 | require('../../js/carousel.js') 6 | require('../../js/collapse.js') 7 | require('../../js/dropdown.js') 8 | require('../../js/modal.js') 9 | require('../../js/tooltip.js') 10 | require('../../js/popover.js') 11 | require('../../js/scrollspy.js') 12 | require('../../js/tab.js') 13 | require('../../js/affix.js') -------------------------------------------------------------------------------- /thanks.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Message sent 4 | excerpt: "A blog about using the Ruby on Rails web application framework to get stuff done as a web developer. New content a few times a week." 5 | --- 6 | 7 |

8 | Thanks, your message has been sent to my inbox! I'll get back to you as soon 9 | as I can. 10 |

11 | 12 |
13 | Back to Left of the Dev 14 |
15 | -------------------------------------------------------------------------------- /_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: https://leftofthe.dev/atom.xml 13 | exclude: 14 | [ 15 | node_modules, 16 | scss, 17 | tmp, 18 | .ruby-version, 19 | Gemfile, 20 | Gemfile.lock, 21 | drafts, 22 | public, 23 | src, 24 | mise.toml, 25 | ] 26 | tag_page_layout: tags 27 | tag_page_dir: tag 28 | plugins: [jekyll-gist] 29 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: main 3 | excerpt: "A blog about using the Ruby on Rails web application framework to get stuff done as a web developer. New content every few weeks." 4 | --- 5 | 6 | {% for post in site.posts limit:10 %} 7 |
8 |

{{ post.title }}

9 | 10 | {{ post.excerpt }} 11 | 12 | ({{ post.date | date: "%B %d, %Y" }}) 13 | 14 |
15 | {% endfor %} 16 | 17 |
18 | More in the archives 19 |
20 | -------------------------------------------------------------------------------- /_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/nav.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | Left of the Dev 10 |
11 | 19 |
20 | -------------------------------------------------------------------------------- /_includes/footer.html: -------------------------------------------------------------------------------- 1 | 19 | -------------------------------------------------------------------------------- /_posts/2024-11-26-rspec-book-november-2024.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for November 2024" 4 | excerpt: "More coverage of request specs, factory_bot, and debugging tests" 5 | tags: rspec-book 6 | --- 7 | 8 | A fresh update to the 2024 edition of [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec) is now available! This update continues the book's exploration of request specs. It also introduces abstracting away test data implementation details with factory_bot, and debugging tests with `binding.irb`. 9 | 10 | If you ever purchased a copy through Leanpub, you can download this one for free, along with all future updates. 11 | 12 | Thanks as always for your support! See you again soon with another batch of updates. 13 | -------------------------------------------------------------------------------- /_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 Left of the Dev, book picks, and other thoughts and ideas that didn't 20 | quite fit here. 21 |
22 | -------------------------------------------------------------------------------- /_includes/disqus.html: -------------------------------------------------------------------------------- 1 |
2 | 12 | 13 | blog comments powered by Disqus 14 | -------------------------------------------------------------------------------- /_posts/2024-10-10-rspec-book-october-2024-announcement.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for October 2024" 4 | excerpt: "Brand new chapter on testing controllers via request specs, and more!" 5 | tags: rspec-book 6 | --- 7 | 8 | 9 | 10 | I've just released another batch of progress on the 2024 edition of [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec). 11 | 12 | This release includes an overhauled chapter on testing controllers, using RSpec request specs. 13 | 14 | If you ever purchased a copy through Leanpub, you can download this one for free, along with all future updates. 15 | 16 | I appreciate your support! 17 | -------------------------------------------------------------------------------- /atom.xml: -------------------------------------------------------------------------------- 1 | --- 2 | layout: null 3 | --- 4 | 5 | 6 | 7 | Left of the Dev 8 | 9 | 10 | {{ site.time | date_to_xmlschema }} 11 | https://leftofthe.dev/ 12 | 13 | Aaron Sumner 14 | aaron@leftofthe.dev 15 | 16 | 17 | {% for post in site.posts limit:10 %} 18 | 19 | {{ post.title | xml_escape }} 20 | 21 | {{ post.date | date_to_xmlschema }} 22 | https://leftofthe.dev{{ post.id }} 23 | {{ post.excerpt | xml_escape }} 24 | 25 | {% endfor %} 26 | 27 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "left-of-the-dev", 3 | "version": "1.0.0", 4 | "description": "Left of the Dev is a blog about getting stuff done with Ruby on Rails. This is the source code for the blog, which is created with the Jekyll static site framework/generator.", 5 | "main": "gulpfile.js", 6 | "scripts": { 7 | "build": "postcss _css/tailwind.css -o css/tailwind.css" 8 | }, 9 | "repository": { 10 | "type": "git", 11 | "url": "git+https://github.com/everydayrails/everyday-rails.git" 12 | }, 13 | "keywords": [], 14 | "author": "", 15 | "license": "ISC", 16 | "bugs": { 17 | "url": "https://github.com/everydayrails/everyday-rails/issues" 18 | }, 19 | "homepage": "https://leftofthe.dev", 20 | "dependencies": { 21 | "@fullhuman/postcss-purgecss": "^2.3.0", 22 | "autoprefixer": "^9.8.6", 23 | "postcss-cli": "^7.1.2", 24 | "tailwindcss": "^1.8.6" 25 | } 26 | } 27 | -------------------------------------------------------------------------------- /_posts/2024-12-29-rspec-book-december-2024-announcement.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for December 2024" 4 | excerpt: "All-new coverage of system specs" 5 | tags: rspec-book 6 | --- 7 | 8 | Hello! I'm happy to share that I've updated [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec) with a new take on using RSpec and Capybara to test browser interactions via system specs. Long-time readers may recall that past editions of the book covered RSpec's _feature specs_, and included an appendix for migrating to system specs. 9 | 10 | If you're using Windows and have a chance to check out the new examples, I'd love to hear how they're working for you--especially if they _don't_ work. I've started a [Windows support discussion thread](https://github.com/orgs/everydayrails/discussions/4) for this topic. 11 | 12 | Thank you for your support, and have a wonderful new year! 13 | -------------------------------------------------------------------------------- /_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 | -------------------------------------------------------------------------------- /_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-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-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-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/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-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! -------------------------------------------------------------------------------- /_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 |
-------------------------------------------------------------------------------- /_posts/2024-09-04-rspec-book-september-2024-announcement.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for September 2024" 4 | excerpt: "Now with an updated take on DRY tests and creating test data with factory_bot!" 5 | tags: rspec-book 6 | --- 7 | 8 | 9 | 10 | I've just released a small batch of progress on the 2024 edition of [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec). 11 | 12 | This release includes the following: 13 | 14 | - A brand-new chapter 4, introducing RSpec's support for DRYer tests 15 | - An updated take on using factory_bot to create test data 16 | - Improvements to TasteDrivenDevelopment sample application 17 | - Sample recipes contributed from readers! 18 | 19 | If you ever purchased a copy through Leanpub, you can download this one for free, along with all future updates. 20 | 21 | I appreciate your support! 22 | -------------------------------------------------------------------------------- /justfile: -------------------------------------------------------------------------------- 1 | alias run := serve 2 | 3 | # List available recipes 4 | default: 5 | @just --list 6 | 7 | # Setup dependencies 8 | [group("development")] 9 | setup: 10 | bundle install 11 | 12 | # Serve site locally 13 | [group("development")] 14 | serve: 15 | bundle exec jekyll serve 16 | 17 | # Build site 18 | [group("maintenance")] 19 | build: 20 | npm run build 21 | bundle exec jekyll build 22 | 23 | # Clean up generated site files 24 | [group("maintenance")] 25 | clean: 26 | rm -rf _site 27 | 28 | # Create new post 29 | [group("content")] 30 | @create-post TITLE: 31 | touch "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 32 | 33 | echo "---" > "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 34 | echo "layout: post" >> "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 35 | echo "title: \"{{TITLE}}\"" >> "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 36 | echo "tags:" >> "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 37 | echo "---" >> "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 38 | echo "" >> "_posts/{{datetime('%Y-%m-%d')}}-{{kebabcase(lowercase(TITLE))}}.md" 39 | -------------------------------------------------------------------------------- /_includes/header.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | {% if page.title %} 11 | {{ page.title }} | 12 | {% endif %} 13 | Left of the Dev 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | -------------------------------------------------------------------------------- /rspecbook/index.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: "Everyday Rails Testing with RSpec sample code" 4 | excerpt: "A simple approach to cutting through the confusion and testing your Rails applications." 5 | --- 6 | 7 | ## Rails 7.1 edition (2024) 8 | 9 | ![Everyday Rails Testing with RSpec 2024 cover](/images/rspec-book-2024-xl.jpg){: .h-40 .float-right .border .ml-2 .mb-2 .shadow} 10 | 11 | The 2024 edition of *Everyday Rails Testing with RSpec* is the current, supported version. It's available for purchase via Leanpub, and is a free update for anyone who owns a license via Leanpub. Thank you for your support! 12 | 13 | - [Purchase Everyday Rails Testing with RSpec, Rails 7.1 edition on Leanpub](https://leanpub.com/everydayrailsrspec) 14 | - [Source code](./code.zip) (zip) 15 | - [Discussion](https://github.com/orgs/everydayrails/discussions) 16 | 17 | 18 | ## Rails 5.1 edition (2017) 19 | 20 | ![Everyday Rails Testing with RSpec 2017 cover](/images/rspec_book.jpg){: .h-40 .float-right .border .ml-2 .mb-2 .shadow} 21 | 22 | The 2017 edition of *Everyday Rails Testing with RSpec* is provided as-is as reference for older versions of Rails and RSpec. 23 | 24 | - [Book](./everydayrailsrspec-5.1.zip) (PDF/EPUB) 25 | - [Source code (GitHub)](https://github.com/everydayrails/everydayrails-rspec-2017) 26 | - [Discussion](https://github.com/everydayrails/everydayrails-rspec-2017/issues) 27 | -------------------------------------------------------------------------------- /_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 ml-6; 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 | -------------------------------------------------------------------------------- /netlify.toml: -------------------------------------------------------------------------------- 1 | # Netlify configuration for Left of the Dev 2 | # Migration from everydayrails.com to leftofthe.dev 3 | 4 | [build.environment] 5 | RUBY_VERSION = "3.4.3" 6 | NODE_ENV = "production" 7 | 8 | [build] 9 | command = "npm run build && bundle exec jekyll build" 10 | publish = "_site" 11 | 12 | # Redirect old domain to new domain with 301 (permanent redirect) 13 | # This preserves SEO rankings by telling search engines the site has permanently moved 14 | 15 | [[redirects]] 16 | from = "https://everydayrails.com/*" 17 | to = "https://leftofthe.dev/:splat" 18 | status = 301 19 | force = true 20 | 21 | [[redirects]] 22 | from = "http://everydayrails.com/*" 23 | to = "https://leftofthe.dev/:splat" 24 | status = 301 25 | force = true 26 | 27 | [[redirects]] 28 | from = "https://www.everydayrails.com/*" 29 | to = "https://leftofthe.dev/:splat" 30 | status = 301 31 | force = true 32 | 33 | [[redirects]] 34 | from = "http://www.everydayrails.com/*" 35 | to = "https://leftofthe.dev/:splat" 36 | status = 301 37 | force = true 38 | 39 | # Redirect www to non-www for new domain 40 | [[redirects]] 41 | from = "https://www.leftofthe.dev/*" 42 | to = "https://leftofthe.dev/:splat" 43 | status = 301 44 | force = true 45 | 46 | [[redirects]] 47 | from = "http://www.leftofthe.dev/*" 48 | to = "https://leftofthe.dev/:splat" 49 | status = 301 50 | force = true 51 | -------------------------------------------------------------------------------- /_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 | tags: site-news 6 | --- 7 | 8 | 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? 9 | 10 | ### [Ruby Rogues: Removing business logic from controllers](https://devchat.tv/ruby-rogues/rr-353-removing-business-logic-from-rails-controllers-with-aaron-sumner) 11 | 12 | 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. 13 | 14 | ### [The Ruby Testing Podcast](http://www.rubytestingpodcast.com/aaron-sumner) 15 | 16 | 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. 17 | -------------------------------------------------------------------------------- /_posts/2025-04-05-rspec-book-april-2025-announcement.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for April 2025" 4 | excerpt: "Fresh takes on all things mocking!" 5 | tags: rspec-book 6 | --- 7 | 8 | I just shipped a new chapter for the current edition of [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec). In this release, I've totally replaced my introduction to testing in isolation with mocks (and stubs, and fakes, and spies, and doubles, oh my). My beliefs on when and how to mock have changed a lot since the last major release of the book, and this updated chapter reflect my newer opinions. I hope you find it useful. 9 | 10 | I've also realized I forgot to mention an update from a few weeks ago that gets deeper into RSpec's tools for reducing duplication in tests, when to use them, and which ones to maybe avoid. 11 | 12 | Just a couple more chapters to update content-wise! I'm going to take a short break from writing after that, then do some quick updates for whatever's the latest version of Rails at that point. I haven't done a ton with Rails 8 yet, but I don't anticipate a lot of big changes in the book because of it. 13 | 14 | As always, this is a free update for anyone who's got a license for the book on Leanpub--and if you don't, you can [pick yours up starting at $19](https://leanpub.com/everydayrailsrspec). 15 | 16 | Happy testing, and thanks again for your support! 17 | -------------------------------------------------------------------------------- /_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/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-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/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/2024-07-21-rspec-book-july-2024-announcement.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for July 2024" 4 | excerpt: "Finally, here's the first release of my RSpec testing book, updated for the latest Rails stack!" 5 | tags: rspec-book 6 | --- 7 | 8 | 9 | 10 | I'm happy to share the first release of [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec), updated for 2024. If you ever purchased a copy through Leanpub, you can download this one for free, along with all future updates. 11 | 12 | This release includes the following: 13 | 14 | - Chapters 1-3 updated for the current Ruby on Rails stack (Rails 7.1 as of this writing) 15 | - An all-new chapter covering the basics of DRY tests 16 | - A fun new sample application 17 | 18 | I still have many chapters to update, along with some planned new content to cover testing concepts I didn't include in past versions, and augmenting test-driven development with generative AI. 19 | 20 | If you still need the complete (albeit very outdated) Rails 5.1 version, I've made the download freely available, along with sample source code for this version. See the [all-new book resource page](/rspecbook/) for details. 21 | 22 | Thank you as always for your support, patience, and kindness as I've worked on these updates. Watch for the next batch of updates in the coming weeks! 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-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/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 tdd 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 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /_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/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/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-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/2024-05-20-railsconf-book-discount-2024.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Calling all cooks: Share a recipe, get a free book!" 4 | excerpt: "Want a great deal on my RSpec book, or a free copy of my next project?" 5 | tags: rspec-book 6 | --- 7 | 8 | I want to say **thank you again for all the renewed interest** in my RSpec book, *Everyday Rails Testing with RSpec*. If you missed it, I wrote a post a couple of weeks ago explaining the delay and rough new timeline. I’m really sorry and appreciate your understanding! 9 | 10 | ## May book sale! 11 | 12 | In the meantime, I’ve got a coupon code going through May, in honor of Railsconf 2024. If you haven’t yet purchased the book, **this is your chance to [snag a copy of *Everyday Rails Testing with RSpec* for $9](https://leanpub.com/everydayrailsrspec/c/railsconf2024)**. Now that I’ve formally, officially moved to a free updates for life model, the price will go up as I get closer to the final release. Just saying. 13 | 14 | ## Want a free copy of my next book project? 15 | 16 | **I’m looking for some community support!** The updated book's sample app is a social recipe sharing site. I’m looking for some recipes to use as sample content, and would love to see your favorite dish included. If cooking’s your thing, [head over to my contact page and share](https://everydayrails.com/contact) the title of your recipe, a short description, a list of ingredients, and instructions. 17 | 18 | You’ll get a shout out in the book and sample source (unless you wish to remain anonymous!) and, as an extra thank you, **a free copy of a companion mini-book** I’ll start working on following the updated release of *Testing with RSpec*. Be sure to **use a real email address** in the contact form so I can send you an access code! 19 | 20 | I’m looking forward to seeing your culinary creations! 21 | -------------------------------------------------------------------------------- /_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/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-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/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/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-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/2025-05-18-happy-birthday.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails is 15 years old!" 4 | excerpt: A brief look back on the past five years, and a peek at what's ahead for Everyday Rails. 5 | tags: site-news 6 | --- 7 | 8 | May 19, 2025 marks Everyday Rails's fifteenth birthday! 9 | 10 | I shared the origin story five years ago, in a [tenth birthday post](/2020/05/18/everyday-rails-10th-birthday.html). Since then, I [redesigned the site](http://localhost:4000/2020/09/17/redesign-2020-notes.html) (I still like how it looks), and wrote a few posts that you seemed to like: 11 | 12 | - **[Rails architecture tips from route helpers](/2020/06/22/rails-routes-helpers-grammar.html)** (2020): I still love the attention to detail and developer delight that Ruby and Rails provide--in this case, a nudge toward better controller design. 13 | - **[2 ways to test Rails log messages with RSpec](/2020/08/10/rails-log-message-testing-rspec.html)** (2020): Surprisingly to me, this is my most popular post since I published it! 14 | - **[Old Ruby and Rails on new hardware with dev containers](/2025/04/15/old-ruby-rails-dev-container.html)** (2025): A new post from just last month--one I couldn't have written a few years earlier. But dev containers made the task _possible_, and generative AI made it possible _in a day_. 15 | 16 | I also announced a fully-updated version of the book spun from this site, **[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec/c/everyday-rails-15)**. The latest updates are almost done, and are free for anyone who's ever bought a copy through Leanpub. And through May, this link to the book gets you your _own_ lifetime copy for just $9. 17 | 18 | ## The future 19 | 20 | I've got plans for expanding Everyday Rails beyond the traditional blog format it's used since day one. I'm hoping to build and expand my mailing list (since that's the thing these days), but don't worry--it won't be yet another Substack. 21 | 22 | In the meantime, thank you for all of your support over the years. I appreciate you! 23 | -------------------------------------------------------------------------------- /_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 | -------------------------------------------------------------------------------- /_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/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 legacy-rails 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 | -------------------------------------------------------------------------------- /_includes/sidebar.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

Test with confidence!

4 |
5 | 11 |

12 | If you liked my series on practical advice for adding reliable 13 | tests to your Rails apps, check out the expanded ebook version. 14 | Lots of additional, exclusive content and a complete sample 15 | Rails application. 16 |

17 |
18 | Start testing now 23 |
24 |
25 |
26 | 27 |
28 |

Newsletter

29 |
30 |

31 | Software development news and tips, and other ideas and 32 | surprises from Aaron at Left of the Dev. Delivered to your inbox 33 | on no particular set schedule. 34 |

35 |
36 | Subscribe now for free 41 |
42 |
43 |
44 | 45 |
46 |

Tags

47 |
{{ site | tag_cloud }}
48 |
49 |
50 | -------------------------------------------------------------------------------- /_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/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/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/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-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/2021-04-05-rspec-tutorial-mimemagic-fix.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Working around the mimemagic issue in my RSpec testing book" 4 | excerpt: "The book's sample source no longer installs due to a dependency change. Here's how to fix it." 5 | tags: rspec-book 6 | --- 7 | 8 | As you may have heard, the Rails community has a brief moment of panic and drama a few weeks ago, when the _mimemagic_ gem’s version number was bumped while addressing a licensing concern. Previous versions of the gem with an incorrect license were yanked and no longer downloadable. 9 | 10 | This change affected thousands of Rails applications—even tiny ones like the sample source for my introductory book about Rails testing, _[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)_. The subject matter of the book itself doesn’t depend on mimemagic, but I used the Paperclip gem to add file upload support in order to demonstrate how to test such functionality--and Paperclip (at least the version I used) depends on mimemagic. 11 | 12 | Due to the structure of the book’s sample code, I do not plan on updating it at this time to address the version change. Each chapter builds upon the previous one. In the sample code, this is handled by a long-running git branch for each chapter. Making a change to the core application requires a change to the first chapter’s branch; then, I merge the changes on up through each subsequent branch. Since many chapters’ branches make changes to the project’s _Gemfile_ and _Gemfile.lock_, this approach is prone to error. And I would rather spend my time thinking about what a version of the tutorial might look like for a more modern version of Rails. 13 | 14 | 15 | ## Working around the problem 16 | 17 | Junichi Ito, who leads the team responsible for the Japanese translation of the book, has [reported a workaround](https://images-na.ssl-images-amazon.com/images/I/51LfqgkrQRL._SX382_BO1,204,203,200_.jpg): Instead of running `bundle install` to set up the initial application, run `bundle update mimemagic` instead. This will pull down a version of mimemagic with its updated license, so you can complete the exercises in the book. 18 | 19 | Thank you very much to Junichi for his diligence on this matter, and sharing the solution. I apologize for the confusion and frustration this no doubt caused many of you, and appreciate your support. 20 | -------------------------------------------------------------------------------- /_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-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 | -------------------------------------------------------------------------------- /contact.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Contact 4 | excerpt: "A blog about using the Ruby on Rails web application framework to get stuff done as a web developer. New content a few times a week." 5 | --- 6 | 7 |

8 | If you've got a question or comment about something 9 | you read here, please use the form below to send me an email. Please fill in 10 | all the fields—I just need it to be able to reply, not to sell or market. 11 | I do my best to reply in a reasonable amount of time, but please 12 | understand that it can sometimes take me a little while to get back to you. 13 |

14 | 15 |

16 | If you have a question about something from 17 | Everyday Rails Testing with RSpec, please direct it to the 18 | GitHub issues page for that project. 19 |

20 | 21 |

22 | Heads up, I will probably not respond to the following: 23 |

24 | 25 |
    26 |
  1. 27 | Offers to translate my book: I'm flattered, but I am not interested in 28 | adding translations at this time. 29 |
    2. 30 |
  2. 31 | Requests to write guest posts on Left of the Dev: Sorry, this site is a 32 | purely personal venture. 33 |
    3. 34 |
  3. 35 | Requests to post to your company or personal project: If it's interesting 36 | to me, and solves a need I have, I may write something up about it. 37 |
    4. 38 |
  4. 39 | Offers to improve my SEO, or write any software for hire. 40 |
    5. 41 |
42 | 43 |

44 | Thanks! 45 |

46 | 47 |
48 |
49 | 50 | 51 |
52 |
53 | 54 | 55 |
56 |
57 | 58 | 59 |
60 | 61 | 62 |
63 | -------------------------------------------------------------------------------- /_posts/2025-09-16-rspec-book-rails-7.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Testing with RSpec book updates for September 2025" 4 | excerpt: New content on top-down testing and covering your app's supporting features. 5 | tags: rspec-book 6 | --- 7 | 8 | 9 | 10 | Hello! I'm happy to share that, after a tough summer but _very_ productive flight earlier this week, **the latest edition of [Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec) is finished and available now on Leanpub**. As always, if you've ever owned a copy of the book, this is a free update. 11 | 12 | **I overhauled almost everything in the book**--way more than I expected when I started in spring of 2024. So it took almost a year and a half to complete, but in return, it reflects my current testing approaches and philosophies. I also restructured it to be more sustainable for me to keep up-to-date every year or two, or as long as there's demand. 13 | 14 | New to my work? For a limited time, **get your copy of [Everyday Rails Testing with RSpec for $9](https://leanpub.com/everydayrailsrspec/c/ItsAlive)** (regularly $19). Or if that's too much for your situation, [send me an email for a free lifetime license](/contact.html), no questions asked. 15 | 16 | ## What's new since 2017 (last major release) 17 | 18 | **For the most part, everything.** The sample application is all new. Some content is reorganized to reflect modern Rails application and test suite structures. But the core message is still there: Start simple and build up to more complex tests, with a focus on pragmatism. 19 | 20 | ## What's new since April 21 | 22 | - Rewrote the chapter on "testing the rest" to discuss **testing file uploads, email delivery, background jobs, and coverage measurement** (new to this edition) 23 | - Rewrote the "toward test-driven development" chapter to work through **top-down TDD on a new feature** to the sample application 24 | - Added **on-your-own exercises** to all chapters 25 | 26 | ## What's next 27 | 28 | Now that the book and its sample code are more sustainable for me, I would love to have everything updated for the forthcoming Rails 8.1 by early 2026. I've got some other side projects that need attention first. 29 | 30 | In the meantime, thank you as always for your support! 31 | -------------------------------------------------------------------------------- /_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 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/2020-12-03-plausible-analytics.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Everyday Rails now uses Plausible for analytics" 4 | excerpt: "Why I've moved to the simple, privacy-focused Plausible for my visitor analytics needs." 5 | tags: site-news 6 | --- 7 | 8 | After years of wrangling with Google Analytics to try to understand which content of mine was useful (or at least popular), I recently started using [Plausible] for web analytics on several projects, including Everyday Rails. If you're an independent tech author or software developer, or have the influence within your company to make the switch, Plausible's worth checking out. 9 | 10 | I've got no affiliation with Plausible. I'm just a paying customer who's really happy with the service, and want to help spread the word about it. If nothing else, I wanted to let you know what I'm doing to help protect your privacy online. 11 | 12 | [Plausible]: https://plausible.io 13 | 14 | ## Why switch? 15 | 16 | When checking my sites' analytics, all I care about are high-level metrics--like, which articles are popular, and which sites generally drive visitors my way. I don't need the mountains of data offered up by Google Analytics--and if I did, I'd have no idea how to find the good bits in its increasingly cumbersome user interface! Plausible's dashboard is super-simple. It shows trends over time, traffic source, countries, top pages, and device types. As an independent content producer, that's all I need! 17 | 18 | And to be honest, from a privacy standpoint, I've felt pretty gross about using Google Analytics for some time. Again, my needs are pretty simple. I don't need to know what my individual visitor had for breakfast--and, frankly, neither does Google. Plausible's built for privacy, and for a modern world with laws designed to help protect it. Major selling point, in my book. 19 | 20 | Also! Plausible is open source and written with cool tools like Phoenix, Tailwind, and React. I appreciate that they've chosen to share their work and develop in the open. 21 | 22 | Sure, unlike Google Analytics, Plausible is a paid service. But I'm all for paying software developers (like me! and you!) for their work, instead of selling out my sites' visitors and their privacy. And I find Plausible's pricing structure to be super-reasonable. 23 | 24 | I hope you'll consider [Plausible] for your analytics needs, too. Thanks for supporting independent software developers and technical authors! 25 | -------------------------------------------------------------------------------- /_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-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/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/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-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/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-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/2024-01-14-github-actions-devcontainer-ci.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Using devcontainers in GitHub Actions CI workflows" 4 | excerpt: "It's simpler than ever to wire CI pipelines, thanks to devcontainers. Here's how I run Rails test suites these days in GitHub workflows." 5 | tags: docker developer-experience 6 | --- 7 | 8 | I'm a big fan of [GitHub Actions](https://github.com/features/actions), especially the robust ecosystem of actions that can be included into continuous integration pipelines with just a few lines of configuration code. And thanks to the [devcontainers/ci](https://github.com/devcontainers/ci) action, using an existing development container setup could make running a test suite or other common CI processes much, much simpler than it might have been in the past. 9 | 10 | First off, this assumes you've already got your application set up to support devcontainer-based development, with a test suite that runs from within the container. If you don't, this is as good a time as any to set one up. 11 | 12 | Once that's in place, create a file in _.github/workflows_ to add the workflow. Name it something like _ci.yml_. Here's what mine looks like: 13 | 14 | ```yaml 15 | name: CI 16 | 17 | on: 18 | push: 19 | branches: 20 | - main 21 | - staging 22 | pull_request: 23 | branches: 24 | - main 25 | - staging 26 | 27 | jobs: 28 | tests: 29 | name: Run test suite 30 | runs-on: ubuntu-latest 31 | 32 | steps: 33 | - name: Check out code 34 | uses: actions/checkout@v3 35 | 36 | - name: "Create environment files" 37 | run: | 38 | cp config/database-ci.yml config/database.yml 39 | cp .sample.env .env 40 | 41 | - name: run tests 42 | uses: devcontainers/ci@v0.3 43 | with: 44 | runCmd: bin/rspec --format documentation 45 | ``` 46 | 47 | Let's break this down. I've set up the workflow to run any time a push is made to the _main_ or _staging_ branch, or a pull request is opened against either of those branches. 48 | 49 | I've defined a _job_ to run tests. The job is broken into three steps: 50 | 51 | - Check out the source code. 52 | - Copy necessary configuration files for CI to work. This may not be necessary for your application, or you may need to copy additional files. 53 | - Build the devcontainer, then use it to run my RSpec test suite. 54 | 55 | That's it! It may take some trial and error to work end-to-end. Approach it scientifically—change one thing, let it run, course-correct, and try again. When I'm creating a new GitHub Actions-based workflow, or updating an existing one, I usually create a draft pull request and make incremental changes to it, sneaking up gradually on the final solution. 56 | -------------------------------------------------------------------------------- /_posts/2024-02-24-rails-just-commands.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Why I’ve started using justfiles in my Rails apps" 4 | excerpt: "Boost your developer experience with consistent command line interfaces. Here's how." 5 | tags: developer-experience 6 | --- 7 | 8 | I love that the notion of the “developer experience” is having its day. Of course, thanks to Matz, we Rubyists have embraced “developer happiness” since day one! And with Rails, we also get great, out-of-the-box support for pretty much any common command line task we need to run regularly, generally via the `rake` and `rails` command line utilities. 9 | 10 | As apps grow and mature, though, these tasks can and will deviate from the defaults. If you work on multiple apps, you may find yourself forgetting which ones use RSpec versus Minitest, `foreman start` versus `rails server` versus `bin/dev`, and so on. And if you’re like me, you’ve also got systems written in entirely different languages and frameworks, with varying degrees of attention to the developer experience. It’s no fun having to root around documentation just to run a test suite. 11 | 12 | That’s where a consistent user interface for applications proves beneficial. I’ve taken to using the [`just` command runner](https://github.com/casey/just) for this. In my rails apps, `rails/server`, `bin/dev`, and `foreman start` are all standardized to `just run`. Test suites kick off with `just test`. And so on. Here's a representative example of a `justfile` for a Rails application: 13 | 14 | ``` 15 | # List available commands when no command provided 16 | default: 17 | @just --list 18 | 19 | # Run the application and background processes 20 | run: 21 | ./bin/run 22 | 23 | # Open an interactive Rails console 24 | shell: 25 | ./bin/rails console 26 | 27 | # Open an interactive database console 28 | db-shell: 29 | ./bin/rails dbconsole 30 | 31 | # Set up environment for development 32 | setup: 33 | ./bin/setup 34 | 35 | # Run the full test suite 36 | test-all: 37 | ./bin/rspec 38 | 39 | # Run a specific test 40 | test TEST: 41 | ./bin/rspec {{TEST}} 42 | 43 | # Start the documentation server 44 | docs: 45 | yard server -r 46 | ``` 47 | 48 | Since `just` isn’t specific to Ruby, I also create just files for other languages. I can never remember the syntax to run a Go test suite with coverage reporting, but now it’s just `just test`. This (along with [adopting dev containers as default development environments](/2023/09/05/dev-containers-best-practices)) has greatly streamlined the process for any developer on my team to pick up a ticket, regardless of the code base it touches. 49 | 50 | `just` has a low learning curve but is quite powerful. I found a [just cheat sheet](https://cheatography.com/linux-china/cheat-sheets/justfile/) I lean on for my work with it. It may simplify your workflows, too. 51 | -------------------------------------------------------------------------------- /_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. -------------------------------------------------------------------------------- /images/ccheart_black.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /_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/2021-07-31-rails-custom-deprecation-warnings.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Deprecating code in a Rails application" 4 | excerpt: "Here's how to add good deprecation warnings to your Rails applications, and why it might be a good idea." 5 | tags: legacy rails-upgrades 6 | --- 7 | 8 | When upgrading a Rails application to a newer version of the framework, you'll often see deprecation warnings pop up in your application logs and test suite output. Deprecation warnings give you time to fix an issue before it becomes an outright error. _Good_ deprecation warnings also give you a hint on _where_ and _how_ to address them. 9 | 10 | Rails makes it pretty simple to add _good_ deprecation warnings to your actual application code, too. Let's first look at how to do this, then talk for a moment about when it might be a good idea. 11 | 12 | ## Adding the deprecation 13 | 14 | Inside the method you want to deprecate, use `ActiveSupport::Deprecation.warn`, with a string to describe what's been deprecated, and how developers should work around the deprecation going forward. 15 | 16 | {% highlight ruby %} 17 | def process_widget 18 | ActiveSupport::Deprecation.warn( 19 | "#process_widget is deprecated. " \ 20 | "Use #send_widget_to_processor instead." 21 | ) 22 | 23 | # other code ... 24 | 25 | end 26 | {% endhighlight %} 27 | 28 | Then, in your application logs (or even better, your test suite's output), you'll see: 29 | 30 | {% highlight ruby %} 31 | DEPRECATION WARNING: #process_widget is deprecated. Use 32 | #send_widget_to_processor instead. (called from create at /path/to/ 33 | my_app/app/controllers/widgets_controller.rb:55) 34 | {% endhighlight %} 35 | 36 | The deprecation warning clearly marks _where_ in your application you're still using outdated code. If you _don't_ see the deprecation in your test output, and you're confident in your test coverage, then it's safe to remove the outdated code! 37 | 38 | ## Why you might deprecate your code 39 | 40 | Why deprecate code when you could, you know, just fix it in the first place? Asking a few questions can help make that decision: 41 | 42 | - How long will switching to the newer code take? An hour? A day? A week? Longer? 43 | - Can your team work on switching now, or are higher priority projects more pressing? 44 | - Do you need to communicate the deprecation across multiple teams? 45 | 46 | The longer it'll take to stop using the deprecated code, or the more people who need to be aware of it, the more beneficial an explicit deprecation warning will be. 47 | 48 | And personally, I like deprecation warnings because they're too noisy for me to ignore too long, and they're coupled to to code itself rather than something like Jira or Trello. Like any tool, though, it's up to you and your team to decide whether to use them in your code. 49 | 50 | I hope you found this small tip helpful. Thanks as always for reading! 51 | -------------------------------------------------------------------------------- /_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/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-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/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-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/2024-02-06-rspec-book-announcement-rails-7-1.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "New version of Testing with RSpec book for 2024!" 4 | excerpt: "A new edition is in the works, with coverage on the latest versions of Rails, Ruby, and RSpec, and more." 5 | tags: rspec-book 6 | --- 7 | 8 | Let’s cut to the chase. 9 | 10 | I’m excited to announce that I’ve started work on the first major update to *[Everyday Rails Testing with RSpec](https://leanpub.com/everydayrailsrspec)* in nearly seven years! 11 | 12 | So much has changed in the world since 2017, but two things remain steady: I still love writing software with Ruby on Rails, RSpec is still my test framework of choice, and test-driven software design leads to quality, sustainable code. 13 | 14 | That said, nothing is ever really constant in software. Even though I still believe in the concepts presented in my book, newer versions of Rails have made it impossible to even install the sample code from the book. And, I mean, in the era of generative AI that can just write all of our tests (and code) for us, does test-driven development still matter? 15 | 16 | You bet it does. Tests are our closest, most repeatable interfaces to the code our clients, customers, and coworkers rely on daily. Well-written tests lead to well-written code, and vice versa. We humans still matter in software development! The fundamentals are still the fundamentals, but advancements in the developer experience have made it easier to practice those fundamentals without the overhead we dealt with in the past. In other words, it’s never been a better time to learn test-driven development in Rails. And if you’ve been practicing TDD for awhile, there may be a new trick or two to learn. I know I’ve picked up some new ideas since the last edition. 17 | 18 | In that spirit, that’s what I’m working on for the new version of *Everyday Rails Testing with RSpec*. Rails 7.1? Check. Ruby 3.3? You know it. Built-in Rails support for file uploads and background jobs? No question. But also, I’ll share my opinions on the right way to keep tests well-factored and maintainable. And, of course, how to use generative coding tools as a resource, and not at adversary. 19 | 20 | That’s a lot of work. Here’s how it’ll break down. Short version, I’m hoping to have content in your hands by RailsConf in May! 21 | 22 | Some details: 23 | 24 | - First and foremost, if you ever purchased a copy of the book through Leanpub, you’ll have access to this version and all future versions, for as long as I’m doing them. 25 | - If you’ve got a copy purchased through Amazon, send me an email and I’ll send you a license. No questions asked. 26 | - Again, this release will target Rails 7.1 and Ruby 3.3. Expect a roughly yearly cadence going forward. 27 | - Since [it's on Leanpub](https://leanpub.com/everydayrailsrspec), you can expect to get an early look at the book once the first few chapters are more or less fleshed out. 28 | 29 | I'm looking forward to this project, and hope you'll join me for the ride. Thanks as always for your support! 30 | -------------------------------------------------------------------------------- /_posts/2025-03-09-dotfiles-gh-extensions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Newly open-sourced development setup tools" 4 | excerpt: "Recover from laptop disasters a little faster through automation!" 5 | tags: developer-experience 6 | image: "/images/posts/sad-mac.png" 7 | --- 8 | 9 | Last month, I literally dunked my work laptop in coffee. (Check your bag for standing liquid before dropping your laptop in it, kids!) I took this opportunity to tune up my workstation setup process--first with the loaner, then with the repaired laptop when it returned a couple of weeks later. (Aside: I almost always set up new workstations from scratch instead of restoring from backup images.) 10 | 11 | Here are the results of my work, which I'm happy to have open sourced last week. 12 | 13 | - **[ruralocity/dotfiles]:** I've had my dotfiles stored in a private repository for years, and have found chezmoi the best solution for me for managing them. I am still guilty of letting my dotfiles get out of sync across computers, but that's my fault, not chezmoi's. Anyway, I found it's a lot simpler to set up a new workstation from a chezmoi repository if that repo's public, and there wasn't really a reason for me to keep mine private. So here you go, world. 14 | 15 | My dotfiles are still a little messy, and in some places Mac-specific, but they're out there now for reference. If you take nothing else away from them, I strongly suggest installing all the things you can via a `Brewfile`--even apps you'd typically install via the Mac app store. 16 | 17 | - **[ruralocity/gh-clone-team-repos]:** At my team, we use [GitHub Teams] to help organize our organization's many repositories. On top of that, my team in particular is responsible for up to ten times more repositories than other, more focused teams. I wanted a way to pull down a bunch of repositories without all the manual `git clone`s that would've otherwise been involved. So I spun up an extension for the [GitHub CLI] to help me with this. It's a little ugly, but it works! My first iteration was in Ruby; I rewrote it in Bash for better portability. 18 | 19 | Someday I want to look at another rewrite in the [Bubble Tea] TUI framework for Go, just for fun. In the meantime, it does exactly what I needed, and could be useful for onboarding to others. 20 | 21 | - One more broad change--most of our code bases at work use dev containers, but I did begin using **[mise-en-place]** to manage my Rubies, Nodes, and even environment configurations. I've been really happy with it so far. 22 | 23 | I know these aren't Ruby-specific tools, but I hope some of you find them helpful or inspirational! 24 | 25 | [ruralocity/dotfiles]:https://github.com/ruralocity/dotfiles 26 | [chezmoi]:https://github.com/twpayne/chezmoi 27 | [ruralocity/gh-clone-team-repos]:https://github.com/ruralocity/gh-clone-team-repos 28 | [GitHub Teams]:https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams 29 | [GitHub CLI]:https://cli.github.com 30 | [Bubble Tea]:https://github.com/charmbracelet/bubbletea 31 | [mise-en-place]:https://mise.jdx.dev 32 | -------------------------------------------------------------------------------- /_posts/2025-01-07-aider-ai-dev-container.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Notes on pair programming with Aider when Python isn't readily available" 4 | excerpt: "Here's how I'm using Aider as an AI pair programming buddy in dev containers, without dealing with Python" 5 | tags: artificial-intelligence developer-experience 6 | --- 7 | 8 | I'm getting good returns lately from [Aider](https://aider.chat), an open source, terminal-based AI pair programming utility. Consider it an alternative to GitHub Copilot Chat. 9 | 10 | ## Wait, what's Aider? 11 | 12 | Aider builds a map of your application's git repository, then uses that map to reference code and context within the overall codebase when making suggestions. It can also add and edit files (with your permission), removing the copy-paste tedium of other chat-based AI coding tools. I've mainly used Aider to date for small feature creation and test augmentation, and have found it far more reliable than Copilot. (I've tested with GPT-4o and Claude 3.5 Sonnet; it also works with some free and local models.) Finally, I appreciate that it notes how much each response costs in terms of tokens and money, so I can stay mindful of spending. 13 | 14 | ## Setting up Aider (without Python, sort of) 15 | 16 | Aider is a Python application, and can be installed via `pip` as is usual for Python-based tools. But since I tend to use development containers, there's a decent chance I won't have Python available in my environment—especially when working in Ruby. I've always bristled at Python's package installation tooling. Luckily, the Python ecosystem has gone through a recent package and version management renaissance, with the Rust-based [uv](https://docs.astral.sh/uv/) emerging as a strong candidate. Aider's maintainers have taken advantage of uv to make Aider installation a one-line process: 17 | 18 | ```shell 19 | curl -LsSf https://aider.chat/install.sh | sh 20 | ``` 21 | 22 | Once Aider's installed, add your API key (I keep it in a git-ignored `.env` file), then launch `aider` from within the container to get going! 23 | 24 | Of course, if you're working in an environment with Python 3.8 or newer, you _can_ use traditional Python tooling to install Aider. It's also available via package managers like Homebrew. But I'd still suggest using uv to install it, either from the one-liner above or by breaking up uv and Aider installation (as I did before realizing the one-line option existed): 25 | 26 | ```shell 27 | # First, install uv ... 28 | curl -LsSf https://astral.sh/uv/install.sh | sh 29 | # Then use it to install Aider ... 30 | uv tool install aider-install 31 | aider-install 32 | ``` 33 | 34 | If Aider fails to update files, you may need to [configure git to treat your working directory as safe](https://stackoverflow.com/a/75666957). From inside the container, run: 35 | 36 | ```shell 37 | git config --global --add safe.directory /path/to/your/directory 38 | ``` 39 | 40 | I plan to write more soon about how I'm using Aider for Rails specifically, but wanted to get this out for anyone who might find it useful in the meantime. 41 | -------------------------------------------------------------------------------- /_posts/2020-08-24-deliberate-learning-1.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Start with what you know" 4 | excerpt: "Learning something brand new? Think again, it's probably got 5 | some overlap to skills you already have. Here's one way I approach 6 | learning to make it a more effective, intentional process." 7 | tags: learning 8 | --- 9 | 10 |
11 | This post isn't directly or exclusively about Rails. It's from a 12 | writing idea I had a few months ago, to share more general thoughts 13 | on being a good software developer, teammate, and communicator. I 14 | abandoned the project, but liked this piece, and wanted to share it. 15 | Expect a few more similar to this in the future. I hope you find it 16 | useful! 17 |
18 | 19 | The next time you need to learn something new, start with what you know. 20 | Then apply that to learning the new thing. 21 | 22 | Let’s take the approach I took to learn test-driven development on 23 | Rails. At the time, TDD was still a new concept to me, but I’d written 24 | and released a handful of Rails apps, and manually tested each one 25 | through the browser. More importantly, these were real apps with real 26 | users. If something was broken, I’d hear about it fast! 27 | 28 | But manual testing and releasing software into the wild without a safety 29 | net don’t scale, and I knew that. So I took what I had—reasonably sound 30 | software that I trusted—and applied it to what I needed to learn. 31 | 32 | Starting small, I focused on simple, tiny tests that covered 33 | functionality that obviously worked in my applications: data entry 34 | validations, relations across different classes of objects, string 35 | manipulations. If the tests failed, I could be reasonably certain that 36 | it wasn’t the application’s fault; it was the test. And if I wasn’t so 37 | certain, double-checking my work was as simple as loading an object into 38 | the Rails console and experimenting with it. 39 | 40 | Once I’d mastered these simple tests, I gradually moved to more complex 41 | examples that took inputs from different sources, requiring several 42 | objects to play nice together, and eventually full-stack tests 43 | interacting not just with Rails, but with front-end code, external APIs, 44 | and the rest of what’s considered a full web stack. 45 | 46 | As an added bonus, as I mastered each layer of testing, I improved my 47 | apps’ test coverage. Again, these were real, production apps, not toys 48 | never intended for public consumption. I delivered value as I learned. 49 | 50 | It's not just for testing--I'm using this approach now, as I need to 51 | get more comfortable with modern front-end development after a few 52 | years focusing more on the back-end. Tools like Webpack and Tailwind 53 | CSS are new to me, but they're just different, more efficient ways to 54 | accomplish things I already know how to do. 55 | 56 | Technology moves quickly, but don’t discount what you already know. 57 | Look for ways to apply that knowledge to what you need to learn next, 58 | and build new skills on top of it, deliberately. 59 | -------------------------------------------------------------------------------- /_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-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/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 tdd 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/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=