zimkies

# MonkeyPatch for Jquery hide() and show() to work with Bootstrap 3
#
# Bootstrap 3 defines hidden and hide with the !important marker which
# prevents .show() and .hide() from working on elements that have been
# hidden using these classes.
# This patch modifies the hide and show to simply add and remove these
(($) ->
  show = $.fn.show
  $.fn.show = ->
    @removeClass("hidden hide")

zimkies

{
  "font_size": 10.0,
	"ignored_packages":
	[
	],
	"translate_tabs_to_spaces": true,
	"trim_trailing_white_space_on_save": true
}

zimkies

# Default open with vim
set -o vi

# Include npm bins in path
export PATH=$PATH:/usr/local/share/npm/bin:/usr/local/sbin
PATH=/usr/local/bin:$PATH

# Add folder color
export CLICOLOR=1

zimkies

GET /api/me/attendables

{
 attendables: [ 
 # Members Party
 {
   event_type: "members_party",
   attendable_guid: "abcde",
   attendable_type: "Party",
   initiat: null,

zimkies

ngrok - for forwarding a local/port to the internet

zimkies

require 'date'

class Range
  def intersection(other)
    return nil if (self.max < other.begin or other.max < self.begin) 
    [self.begin, other.begin].max..[self.max, other.max].min
  end
  alias_method :&, :intersection
end

zimkies

Move file: Cmd Sh p | f m Rename file: Cmd Sh p | f r

Multi-select cursor skip current selection: Cmd k

zimkies

    # FML You are joking right?
    # THere has to be something wrong with this model.
    def user_has_been_to_venue?(user, venue)
      Reservation.joins("LEFT JOIN venues_tables ON venues_tables.id = reservations.table_id LEFT JOIN venues ON venues_tables.venue_id = venues.id LEFT JOIN groupers ON groupers.id = reservations.grouper_id LEFT JOIN crews ON crews.grouper_id = groupers.id LEFT JOIN users ON users.id = crews.leader_id")
        .where("crews.leader_id = ?", user.id)
        .where("venues.id = ?", venue.id).exists?
    end

zimkies

class PoolsCreator

  def create_all
    Week.where("starting_on > ?", 1.week.ago).each do |week|
      create_for_week(week)
    end
  end

  def create_for_week(week)
    City.active.each do |city|

zimkies

Hi there,
There's no downside to opening connections on initialization or after forking, even if you don't use the connections often. Aside from reducing the chance for connection errors during the request loop, you'll also speed up your request loop by not spending time establishing new connections. I definitely recommend making this change if you can.
For Resque, there's unfortunately no way around the fact that every job is run inside a forked process and can't inherit or share any connections. You'll have to open a new Redis connection for every Resque job that uses Redis. The best way to do this inside the "after_fork" Resque hook. If you use ActiveRecord, it's likely that you're already establishing a new connection inside this hook. Here's what our after_fork hook looks like, in our config/initializers/resque.rb file:
```ruby
Resque.after_fork do
  tries = 0
  begin
    $redis.client.reconnect
    ActiveRecord::Base.establish_connection
  rescue