Do yourself a favor and put one of these in your machine.
| require 'rubygems' | |
| require 'backports' # aliases Proc#=== to Proc#call | |
| rs = (0..10000).to_a.sample(30) | |
| rs.each do |r| | |
| case r | |
| when lambda { |n| n.zero? } then puts "#{r} is zero" | |
| when lambda { |n| (n % 5).zero? } then puts "#{r} is fiven" | |
| when lambda { |n| (n % 4).zero? } then puts "#{r} is fourven" |
The Rails REST implementation dictates the default seven actions for your controllers, but frequently we want to share functionality across multiple actions or even across controllers. Controller filters are the easiest way to do that.
There are three types of filters implemented in Rails:
- a
before_filterruns before the controller action - an
after_filterruns after the controller action
Data integrity is an underrated part of proper application architecture. Many of the bugs in production systems are triggered by missing or malformed user data. If a user can possibly screw it up or screw with it, they will. Validations in the model can help!
Before we begin, let's talk about syntax. There are two primary syntaxes for writing validations in Rails 3:
validates_presence_of :priceNot every application starts from scratch, sometime you have to deal with a legacy database. Walking the Rails golden path makes life easy, and there's a perception that stepping off that path is incredibly painful.
It's not true. If your database is well designed and but doesn't follow the Rails naming conventions, it's easy to make them play nicely together. However, if your database structure is crap to begin with, then there's only so much Rails can do for you. ActiveRecord is a mapper between the database and objects, but it's not a DBA-in-a-Box.
In a green-field app, ActiveRecord and the Database fit right together:
The following document is a written account of the Code School screencasting framework. It should be used as a reference of the accompanying screencast on the topic.
You're probably aren't going to take the time to read this document if you're not interested, but there are a lot of nice side effects caused by learning how to create quality screencasts.
- Communicating more effectively - At Envy Labs we produce screencasts for our clients all the time. Whether it's demoing a new feature or for a presentation for an invester, they're often much more effective and pleasent than a phone call or screen sharing.
| # Add correct content-type for fonts | |
| AddType application/vnd.ms-fontobject .eot | |
| AddType font/ttf .ttf | |
| AddType font/otf .otf | |
| AddType font/x-woff .woff | |
| AddType image/svg+xml .svg | |
| # Compress compressible fonts | |
| AddOutputFilterByType DEFLATE font/ttf font/otf image/svg+xml |
| # ~/.tmux.conf | |
| # | |
| # See the following files: | |
| # | |
| # /opt/local/share/doc/tmux/t-williams.conf | |
| # /opt/local/share/doc/tmux/screen-keys.conf | |
| # /opt/local/share/doc/tmux/vim-keys.conf | |
| # | |
| # URLs to read: | |
| # |
| # RSpec 2.0 syntax Cheet Sheet by http://ApproachE.com | |
| # defining spec within a module will automatically pick Player::MovieList as a 'subject' (see below) | |
| module Player | |
| describe MovieList, "with optional description" do | |
| it "is pending example, so that you can write ones quickly" | |
| it "is already working example that we want to suspend from failing temporarily" do | |
| pending("working on another feature that temporarily breaks this one") |
| =Navigating= | |
| visit('/projects') | |
| visit(post_comments_path(post)) | |
| =Clicking links and buttons= | |
| click_link('id-of-link') | |
| click_link('Link Text') | |
| click_button('Save') | |
| click('Link Text') # Click either a link or a button | |
| click('Button Value') |