mislav

Jim Weirich:

This is how I explain it… Ruby has Procs and Lambdas. Procs are created with Proc.new { }, lambdas are created with lambda {} and ->() {}.

In Ruby 1.8, proc {} creates lambda, and Ruby 1.9 it creates procs (don't ask).

Lambdas use method semantics when handling parameters, procs use assignment semantics when handling parameters.

This means lambdas, like methods, will raise an ArgumentError when called with fewer arguments than they were defined with. Procs will simply assign nil to variables for arguments that were not passed in.

mattconnolly

module AuthHelper
  def http_login
    user = 'username'
    pw = 'password'
    request.env['HTTP_AUTHORIZATION'] = ActionController::HttpAuthentication::Basic.encode_credentials(user,pw)
  end
end

module AuthRequestHelper
  #

malarkey

When times get tough and people get nasty, you’ll need more than a killer smile. You’ll need a killer contract.

Used by 1000s of designers and developers Clarify what’s expected on both sides Helps build great relationships between you and your clients Plain and simple, no legal jargon Customisable to suit your business Used on countless web projects since 2008

…………………………

cookrn

Couldn't find the text of this for a while...

• Original (404'ed) -- https://plus.google.com/115094562986465477143/posts/Di6RwCNKCrf
• Fakeout -- http://www.dzone.com/links/rss/ryan_dahl_i_hate_almost_all_software.html
• Repost -- https://plus.google.com/116904230181415286707/posts/DnAMAN5sUR8

patbenatar

# link_to path
user_omniauth_authorize_path(:facebook, origin: request.fullpath)

# in ApplicationController
def after_sign_in_path_for(resource)
  stored_location_for(resource) || request.env['omniauth.origin'] || root_path
end

headius

Too much for teh twitterz :)

JVM + invokedynamic is in a completely different class than CLR + DLR, for the same reasons that JVM is in a different class than CLR to begin with.

CLR can only do its optimization up-front, before executing code. This is a large part of the reason why C# is designed the way it is: methods are non-virtual by default so they can be statically inlined, types can be specified as value-based so their allocation can be elided, and so on. But even with those language features CLR simply cannot optimize code to the level of a good, warmed-up JVM.

The JVM, on the other hand, optimizes and reoptimizes code while it runs. Regardless of whether methods are virtual/interface-dispatched, whether objects are transient, whether exception-handling is used heavily...the JVM sees through the surface and optimizes code appropriate for how it actually runs. This gives it optimization opportunities that CLR will never have without adding a comparable profiling JIT.

So how does this affect dynamic

pelgrim

#!/usr/bin/env ruby

# A Ruby script to delete files older than X days in a given directory. Pretty simple.
# Like this: file_control.rb /User/pelgrim/Documents '*.pdf' 7
# The command above you remove ALL your pdfs inside Documents older than SEVEN DAYS.
# Quickly written by pelgrim < guskald at gmail dot com >

unless ARGV.size == 3
  puts "Usage: file_control <directory> <filename pattern> <max age>"
  exit 1

waffle2k

#!/usr/bin/python
''' Not my script, found on the Internet, and rediscovered on my hard drive
'''
import sys

def cidr_to_regex(cidr):
    ip, prefix = cidr.split('/')

    base = 0
    for val in map(int, ip.split('.')):

coreyhaines

--colour
-I app

burke

ruby-1.9.3-p327 cumulative performance patch for rbenv

This installs a patched ruby 1.9.3-p327 with various performance improvements and a backported COW-friendly GC, all courtesy of funny-falcon.

Requirements

• rbenv
• ruby-build

You will also need a C Compiler. If you're on Linux, you probably already have one or know how to install one. On OS X, you should install XCode, and brew install autoconf using homebrew.