A mixin for writing @font-face rules in SCSS.
_maxin.scss Code Source
@mixin font-face($style-name, $file, $family, $category:"") {
$filepath: "fonts/" + $family + "/" + $file;
@font-face {
A mixin for writing @font-face rules in SCSS.
@mixin font-face($style-name, $file, $family, $category:"") {
$filepath: "fonts/" + $family + "/" + $file;
@font-face {
/** | |
* Page layout, reused across multiple Page components | |
* @jsx React.DOM | |
*/ | |
var React = require('react'); | |
var ExecutionEnvironment = require('react/lib/ExecutionEnvironment'); | |
var Navigation = require('../components/Navigation.jsx'); | |
var DefaultLayout = React.createClass({ |
Add gem 'delayed_job', '2.1.4'
to your Gemfile
Run bundle install
Run rails g migration create_delayed_jobs
Edit the created migration to contain:
class CreateDelayedJobs < ActiveRecord::Migration
def self.up
create_table :delayed_jobs, :force => true do |table|
table.integer :priority, :default => 0 # jobs can jump to the front of
table.integer :attempts, :default => 0 # retries, but still fail eventually
At the 2004 Ruby Conference, Jamis Buck had the unenviable task to explain Dependency Injection to a bunch of Ruby developers. First of all, Dependency Injection (DI) and Inversion of Control (IoC) is hard to explain, the benefits are subtle and the dynamic nature of Ruby make those benefits even more marginal. Furthermore examples using DI/IoC are either too simple (and don’t convey the usefulness) or too complex (and difficult to explain in the space of an article or presentation). I once attempted to explain DI/IoC to a room of Java programmers (see onestepback.org/articles/dependencyinjection/), so I can’t pass up trying to explain it to Ruby developers.
Thanks goes to Jamis Buck (the author of the Copland DI/IoC framework) who took the time to review this article and provide feedback.
There are many (old) clients available:
All are abandoned and you should not use them. The Google Analytics API is at v3 and they are all using an earlier version.
Use https://github.com/google/google-api-ruby-client (Google supported).
There are many (old) clients available:
The Google Analytics API is at v3 (at time of writing).
This example uses Google's Ruby API client to access Analytics. Use https://github.com/google/google-api-ruby-client (Google supported).
require 'sinatra' | |
require 'oauth2' | |
require 'dotenv' | |
Dotenv.load | |
require 'pry' | |
require 'json' | |
module Trelloizer2 | |
class App2 < Sinatra::Application | |
configure do |
If you're writing web applications with Ruby there comes a time when you might need something a lot simpler, or even faster, than Ruby on Rails or the Sinatra micro-framework. Enter Rack.
Rack describes itself as follows:
Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.
Before Rack came along Ruby web frameworks all implemented their own interfaces, which made it incredibly difficult to write web servers for them, or to share code between two different frameworks. Now almost all Ruby web frameworks implement Rack, including Rails and Sinatra, meaning that these applications can now behave in a similar fashion to one another.
At it's core Rack provides a great set of tools to allow you to build the most simple web application or interface you can. Rack applications can be written in a single line of code. But we're getting ahead of ourselves a bit.
# Application | |
class App < Sinatra::Base | |
set :hi, "Hello" | |
configure :test do | |
set :hi, "Hello There!" | |
end | |
end | |
# Registering a extention |
##Introduction
One definition of unit testing is the process of taking the smallest piece of testable code in an application, isolating it from the remainder of your codebase and determining if it behaves exactly as expected. In this section, we'll be taking a look at how to unit test Backbone applications using a popular JavaScript testing framework called Jasmine from Pivotal Labs.
For an application to be considered 'well'-tested, distinct functionality should ideally have its own separate unit tests where it's tested against the different conditions you expect it to work under. All tests must pass before functionality is considered 'complete'. This allows developers to both modify a unit of code and it's dependencies with a level of confidence about whether these changes have caused any breakage.
As a basic example of unit testing is where a developer may wish to assert whether passing specific values through to a sum function results in the correct output being re