| # Adapted for Rails 4 from http://trevorturk.com/2008/09/20/validating-your-fixtures/ | |
| # I put this in test/models/. Trevor put his in test/integration/. | |
| require 'test_helper' | |
| class FixtureValidationTest < ActiveSupport::TestCase | |
| test "fixtures should be valid" do | |
| models = ActiveRecord::FixtureSet.all_loaded_fixtures.keys | |
| models.each do |model| |
| source :rubygems | |
| # We are not loading Active Record, nor Active Resources etc. | |
| # We can do this in any app by simply replacing the rails gem | |
| # by the parts we want to use. | |
| gem "actionpack", "~> 4.0" | |
| gem "railties", "~> 4.0" | |
| gem "tzinfo" | |
| # Let's use thin |
There are many different provisioning tools out there, the most popular of which are Chef and Puppet. Chef uses Ruby, Puppet uses a DSL (Domain Specific Language), there are others that use simple bash too, but today we're going to focus on Chef Solo.
To get Chef working properly on your local machine you need a few things.
Make sure you use Ruby 1.9.x and not Ruby 2.x as you will get errors with the json 1.6.1 gem on 2.x. Use rbenv or RVM to manage several different Rubies on the one machine.
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
| # Touch tmp/caching.txt to turn on caching | |
| if Rails.root.join('tmp/caching.txt').exist? | |
| config.action_controller.perform_caching = true | |
| config.cache_store = :mem_cache_store | |
| else | |
| config.action_controller.perform_caching = false | |
| config.cache_store = :null_store | |
| end | |
| # Touch tmp/precompile.txt to test with asset precompiles. Run |
| # remove any bad refs | |
| git remote prune origin | |
| # pipe into bash and auto-delete any branches that have been merged into master! | |
| git log master --pretty=format:'%d' | grep '^ (origin' | tr -d ' ()' | sed 's/origin\//git push origin :/' |
| #!/usr/bin/env bash | |
| # | |
| # Wraps curl with a custom-drawn progress bar. Use it just like curl: | |
| # | |
| # $ curl-progress -O http://example.com/file.tar.gz | |
| # $ curl-progress http://example.com/file.tar.gz > file.tar.gz | |
| # | |
| # All arguments to the program are passed directly to curl. Define your | |
| # custom progress bar in the `print_progress` function. | |
| # |
| Capybara.add_selector :record do | |
| xpath { |record| XPath.css("#" + ActionController::RecordIdentifier.dom_id(record)) } | |
| match { |record| record.is_a?(ActiveRecord::Base) } | |
| end |
We've seen lots of Ruby feature requests about converting an Enumerable to a Hash: to_h, map_hash, map_to, each_with_hash, etc. Let's look at one common, simple case of this.
Building a key/value mapping from a collection of keys is awkward. We commonly see Hash[*collection.map { |element| [element, calculate(element)] }] or collection.each_with_object({}) { |element, hash| hash[element] = calculate(element) }. Both are verbose. They require boilerplate code that's not relevant to the programmer's intent: to associate an enumerable of keys with calculated values.
Ruby has the idea of an association already: a key and value paired together. It's used by Array#assoc to look up a value from a list of pairs and by Hash#assoc to return a key/value pair. Building up a mapping of key/value pairs is associating keys with values.
So! Consider Enumerable#associate which builds a mapping by associating keys with values:
# Associate filenames with URLs. Before: