Skip to content

Instantly share code, notes, and snippets.

/** @jsx React.DOM */
var SVGComponent = React.createClass({
render: function() {
return this.transferPropsTo(
<svg>{this.props.children}</svg>
);
}
});
require 'rails_helper'
RSpec.describe TodosController, :type => :controller do
describe "GET #index" do
#describe "POST #create" do
#describe "GET #show" do
#describe "PATCH #update" do (or PUT #update)
#describe "DELETE #destroy" do
#describe "GET #new" do
@iCodeForBananas
iCodeForBananas / gulpfile.js
Created August 26, 2014 14:01
AngualrJS Gulpfile
//
// Module Dependencies
// ==================================================================
var gulp = require('gulp'),
concat = require('gulp-concat'),
uglify = require('gulp-uglify'),
plumber = require('gulp-plumber'),
sass = require('gulp-sass');
//
@evancz
evancz / Architecture.md
Last active December 21, 2022 14:28
Ideas and guidelines for architecting larger applications in Elm to be modular and extensible

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

  1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo
@theburningmonk
theburningmonk / elm_extend_records.elm
Last active December 24, 2023 17:16
Extending Elm records
-- Extensible Records
-- given a record
x = { age = 42, name = "Boke" }
-- you can clone and remove a field in the process
{ x - age } -- { name = "Boke" }
-- you can also add a field
{ x | species = "Jade Dragon" } -- { age = 42, name = "Boke", species = "Jade Dragon" }
@brgnepal
brgnepal / gist:80299aa64c1e20f0842c
Created June 25, 2014 03:24
Lambda and Proc Return Behavior
def lambda_test
lam = lambda { return }
lam.call
puts "Hello world"
end
puts "Lambda Test : #{lambda_test }"
def proc_test
proc = Proc.new { return }
@dhh
dhh / test_induced_design_damage.rb
Last active November 2, 2024 00:52
This is an extraction from Jim Weirich's "Decoupling from Rails" talk, which explained how to apply the hexagonal design pattern to make every layer of your application easily unit testable (without touching the database etc). It only seeks to extract a single method, the EmployeesController#create method, to illustrate the design damage that's …
# Original Rails controller and action
class EmployeesController < ApplicationController
def create
@employee = Employee.new(employee_params)
if @employee.save
redirect_to @employee, notice: "Employee #{@employee.name} created"
else
render :new
end
@teeparham
teeparham / rdoc2md.rb
Last active December 5, 2024 06:54
Convert rdoc to markdown
require 'rdoc'
converter = RDoc::Markup::ToMarkdown.new
rdoc = File.read(ARGV[0] || 'README.rdoc')
puts converter.convert(rdoc)
# ruby rdoc2md.rb > README.md
# ruby rdoc2md.rb ABC.rdoc > abc.md
@tsiege
tsiege / The Technical Interview Cheat Sheet.md
Last active April 11, 2025 17:09
This is my technical interview cheat sheet. Feel free to fork it or do whatever you want with it. PLEASE let me know if there are any errors or if anything crucial is missing. I will add more links soon.

ANNOUNCEMENT

I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!






\

@ppworks
ppworks / nokogiri-warning.md
Created April 17, 2014 00:18
Get rid of Nokogiri LibXML warning
WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.9.1

or

WARNING: Nokogiri was built against LibXML version 2.9.1, but has dynamically loaded 2.9.0