jrasanen

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1442911835000",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [

jrasanen

#!/bin/bash

if [ -f /usr/local/bin/virtualenv ];
then
    virtualenv --no-site-packages --distribute -- $1
elif [ -f /usr/bin/virtualenv ];
then
    virtualenv --no-site-packages --distribute -- $1
else
    echo "No virtualenv found. Please install setuptools & virtualenv. :("

jbmyid

module PayPal::SDK
  module REST
    module DataTypes
      Payer.class_eval do
        object_of :merchant_id, String
      end

      class ChargeModel < Base
        object_of :id, String
        object_of :type, String

ChuckJHardy

'use strict';

var express = require('express'),
    app = express(),
    http = require('http'),
    server = http.createServer(app),
    path = require('path'),
    io = require('socket.io').listen(server),
    fs = require('fs'),
    zmq  = require('zmq'),

kgrz

# This is a modification of the blogpost on how to use Mongoid and Sinatra.
# Here is the original blogpost http://www.garrensmith.com/2010/09/11/Mongoid-sinatra.html
# The modification lets you use Mongoid 3.0 with the new Moped driver

# The new Moped driver uses the Sessions component to define the MongoDB connection rather
# than the Mongo::Connection.new that is used in the case of the default Ruby driver.
# Moped::Session.new vs Mongo::Connection.new

# Mongoid.load!(yaml_config.yml) is used to build the config hash. Alternatively, the hash can
# be built manually by using Mongoid.config {|config| ...} syntax. The config.sessions hash 

zethon

In CMake, add/link the Carbon library to the executable

    FIND_LIBRARY(CARBON_LIBRARY Carbon)
    set(EXTRA_LIBS
        ${CARBON_LIBRARY}

Make sure to add ${CARBON_LIBRARY} in the TARGET_LINK_LIBRARIES call for the executable.

Then create a file to hold the Object-C code, in this case changetitlebarcolor.mm

madwork

class Attachment < ActiveRecord::Base
  mount_uploader :attachment, AttachmentUploader

  # Associations

  belongs_to :attached_item, polymorphic: true

  # Validations

  validates_presence_of :attachment

voter101

'use strict'

var gulp, sass, babelify, browserify, watchify, source, util;

gulp       = require('gulp');
sass       = require('gulp-sass');
babelify   = require('babelify')
browserify = require('browserify');
watchify   = require('watchify');
source     = require('vinyl-source-stream');

randrews

require 'point'

function love.load()
   math.randomseed(os.time())
   love.physics.setMeter(32)
   love.graphics.setBackgroundColor(64, 120, 64)

   world = love.physics.newWorld(0, 0)
   crates = { makeCrate(world, 5, 5),
              makeCrate(world, 5, 6) }

roman01la

ClojureScript REPL Workflow

Short write up on using REPL when developing UIs in ClojureScript.

Hot-reload on save or Eval in REPL?

Everyone's standard approach to hot-reloading is to use a tool (Figwheel or shadow-cljs) that reloads changed namespaces automatically. This works really well: you change the code, the tool picks up changed files, compiles namespaces and dependants, notifies REPL client which then pulls in compiled changes, and re-runs a function that re-renders UI.

The other approach is to use ClojureScript's REPL directly and rely only on eval from the editor. This more or less matches Clojure style workflow. This approach might be useful when you don't want tools overhead or hot-reloading becomes slow for you or you just used to this style of interactions. Also changing code doesn't always mean that you want to reload all the changes. On the other hand it is very easy to change a couple of top-level forms and forget to eval one of them.