View gist:7295057
Crepes with veggies:
Corn cakes, if there is still any corn tomorrow:
Stuffed peppers:
Chili mac and cheese;
View tap_with_each.rb
# do this opposed to each_with_object or inject
# from
by_id = {}.tap{ |h| items.each{ |item| h[] = item } }
View logstash config for util server
# logstash config
input {
syslog {
type => syslog
port => 514
output {
stdout { debug => true debug_format => "json"}
View nethttp_vs_restclient.rb
#!/usr/bin/env ruby
require 'rest_client'
require 'net/http'
require 'benchmark'
URL = ''
time = Benchmark.realtime do
(1..100).each {
url = URI.parse(URL)
req =
View gist:5087142
Facebook is one of the most feature-rich apps available for Android. With features like push notifications, news feed, and an embedded version of Facebook Messenger (a complete app in its own right) all working together in real-time, the complexity and volume of code creates technical challenges that few, if any, other Android developers face--especially on older versions of the platform. (Our latest apps support Android versions as old as Froyo--Android version 2.2--which is almost three years old.)
One of these challenges is related to the way Android's runtime engine, the Dalvik Virtual Machine, handles Java methods. Late last year we completed a major rebuild of our Android app (, which involved moving a lot of our code from JavaScript to Java, as well as using newer abstractions that encouraged large numbers of small methods (generally considered a good programming practice). Unfortuna
View gist:5078067
#when scripting against rvm with a terminal shell, you might need to source this to use RVM files etc, tip from LS chat room
source ~/.rvm/scripts/rvm
View gist:4083050
So agree with @davetron5000 that defects to users are the most important to prevent.
I also agree that a test failure doesn't mean a defect occurred as tests themselves
often just are bad tests that don't test what they should. While you do have to maintain
and think about a test suite, well written tests should be entirely isolated.
The app code you do need to reason about the changes of the code effect other pieces of
the application. So while a buggy tests might be a bit flaky, if it just passes and I am
not specifically working with that test it isn't increasing my thought load while reasoning
about the code structure.
I still think people should maintain and keep clean tests, and unless you are doing payments,
View ruby_number_examples
>> Integer('1001')
=> 1001
>> Integer('1001a')
ArgumentError: invalid value for Integer: "1001a"
from (irb):26:in `Integer'
from (irb):26
#note this is very odd, so is '10a100'.to_i
>> '1001a'.to_i
=> 1001
>> Float('1001.0')
* <p>Title: </p>
* <p>Description: </p>
* <p>Copyright: Copyright (c) 2004</p>
* <p>Company: </p>
* @author not attributable
* @version 1.0
public class Room {
View I18n_bad_test.rb
require File.dirname(__FILE__) + '/../test_helper'
class FakeTest < ActiveSupport::TestCase
test "first de" do
puts "about to be de: #{I18n.locale}"
assert_equal 'en', "#{I18n.locale}"
I18n.locale = 'de'
assert true