Skip to content

Instantly share code, notes, and snippets.

View gist:415421
$(document).ready(function(){
$('.other_submit').click(function(){
this.form.action = this.getAttribute('data-action')
})
})
@agnellvj
agnellvj / Gemfile
Created January 11, 2011 16:06
load specific gems for specific platforms.
View Gemfile
source :gemcutter
eval File.read(File.expand_path("../config/bundler/general.gemfile", __FILE__))
unless RUBY_PLATFORM[/mswin/] || RUBY_PLATFORM[/mingw/]
eval File.read(File.expand_path("../config/bundler/unix.gemfile", __FILE__))
end
View gitconfig.ini
$ git clone github:lenary/guides.git
Cloning into guides...
remote: Counting objects: 255, done.
remote: Compressing objects: 100% (216/216), done.
remote: Total 255 (delta 111), reused 163 (delta 35)
Receiving objects: 100% (255/255), 1.49 MiB | 564 KiB/s, done.
Resolving deltas: 100% (111/111), done.
$ cd guides
$ git remote -v
View gist:996151
curl localhost:9200/_search -d '{
"query" : {
"filtered" : {
"query" : {"match_all" : {}},
"filter" : {
"and" : [
{
"range" : {
"file_size" : {"from" : 10, "to" : 10000}
}
View gist:1020297
data = ["1", "11", "111", "2", "22", "222", "3", "4", "5"]
y = (1..9).inject({}) { |memo, data| memo[data.to_s] = 0; memo }
data.each { |z| y[z.chr] = y.fetch(z.chr, 0) + 1 }
puts y
y = {};(1..9).map { |x| y[x.to_s] = 0 }
data.each { |z| y[z.chr] = y.fetch(z.chr, 0) + 1 }
puts y
@agnellvj
agnellvj / tire_http_clients_benchmark.rb
Created September 9, 2011 01:13 — forked from karmi/tire_http_clients_benchmark.rb
Benchmark Tire gem with RestClient and Curb HTTP Clients
View tire_http_clients_benchmark.rb
#
# A basic, synthetic benchmark of the impact HTTP client has
# on the speed of talking to ElasticSearch in the Tire gem.
#
# In general, Curb seems to be more then two times faster the RestClient, in some cases it's three
# to five times faster. I wonder if keep-alive has anything to do with it, but it probably does.
#
# Run me with:
# $ git clone git://github.com/karmi/tire.git
# $ cd tire
@agnellvj
agnellvj / friendly_urls.markdown
Created September 11, 2011 15:52 — forked from jcasimir/friendly_urls.markdown
Friendly URLs in Rails
View friendly_urls.markdown

Friendly URLs

By default, Rails applications build URLs based on the primary key -- the id column from the database. Imagine we have a Person model and associated controller. We have a person record for Bob Martin that has id number 6. The URL for his show page would be:

/people/6

But, for aesthetic or SEO purposes, we want Bob's name in the URL. The last segment, the 6 here, is called the "slug". Let's look at a few ways to implement better slugs.

@agnellvj
agnellvj / api.markdown
Created September 12, 2011 20:16 — forked from jcasimir/api.markdown
Exposing an API in Rails 3
View api.markdown

Exposing an API

APIs are becoming an essential feature of modern web applications. Rails does a good job of helping your application provide an API using the same MVC structure you're accustomed to.

In the Controller

Let's work with the following example controller:

class ArticlesController < ApplicationController
View jquery_in_rails.markdown

Using jQuery

jQuery has become the most popular JavaScript library both inside and outside the Rails community. Let's look at how to take advantage of the library with our applications.

Setup

The setup process differs depending on whether your app is running on a version of Rails before 3.1 or greater than 3.1.

Before Rails 3.1: jquery-rails

@agnellvj
agnellvj / 01_README.md
Created January 28, 2012 00:18 — forked from ddemaree/01_README.md
How Sunspot implements its wonderful search/index DSL
View 01_README.md

This code is extracted/adapted from Mat Brown's Sunspot gem. One of Sunspot's nicest features is an expressive DSL for defining search indexes and performing queries. It works by instance_eval-ing a block you pass into it in the context of its own search builder object. In this code, the pig thing1 statement is roughly equivalent to zoo = Zoo.new; zoo.pig(thing1).

Sunspot's DSL has to resort to trickery: the instance_eval_with_context method uses eval to get the block to give up the object it considers to be self, then sets up an elaborate system of delegates and method_missing calls so any methods not handled by the DSL are forwarded to the surrounding object. But as a result, this syntax is minimal and beautiful, and it works the way you expect whether or not you prefer blocks to yield an object.

Without this trick the block would be restricted to either the original, "calling" context (as a closure) or the DSL's "receiving" context (using instance_eval), but not both.

Using `ins