This gist is part of a blog post. Check it out at:
http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer
# Gemfile | |
… | |
gem 'uuidtools' | |
… |
#!/bin/sh | |
host=localhost:9200 | |
curl -X DELETE "${host}/test" | |
curl -X PUT "${host}/test" -d '{ | |
"settings" : { "index" : { "number_of_shards" : 1, "number_of_replicas" : 0 }} | |
}' |
This gist is part of a blog post. Check it out at:
http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer
This is a post by Joel Spolsky. The original post is linked at the bottom.
This is such a common question here and elsewhere that I will attempt to write the world's most canonical answer to this question. Hopefully in the future when someone on answers.onstartups asks how to split up the ownership of their new company, you can simply point to this answer.
The most important principle: Fairness, and the perception of fairness, is much more valuable than owning a large stake. Almost everything that can go wrong in a startup will go wrong, and one of the biggest things that can go wrong is huge, angry, shouting matches between the founders as to who worked harder, who owns more, whose idea was it anyway, etc. That is why I would always rather split a new company 50-50 with a friend than insist on owning 60% because "it was my idea," or because "I was more experienced" or anything else. Why? Because if I split the company 60-40, the company is going to fail when we argue ourselves to death. And if you ju
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
/*jshint browser:true */ | |
/*global DS:true, io:true, App:true */ | |
(function() { | |
'use strict'; | |
// Initializer for Models | |
window.Models = {}; | |
console.warn("Don't pollute the global namespace with Models!"); |
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.
# Public: A module to be mixed in another class with common methods to index | |
# records in ElasticSearch. | |
# | |
# The host object needs to respond to 'indexed_attributes', which will return | |
# an array of the attributes names to be indexed. | |
# | |
# It's also recommended to override the 'save?' method to make sure only | |
# records that match some specifications are indexed. | |
# | |
# The type used for the ElasticSearch index will be extracted from the name of |
{ | |
"app/assets/javascripts/models/*.coffee": { | |
"command": "jmodel", | |
"alternate": "spec/javascripts/models/%s_spec.coffee", | |
"template": "App.%S = DS.Model.extend" | |
}, | |
"app/assets/javascripts/controllers/*_controller.coffee": { | |
"command": "jcontroller", | |
"alternate": "spec/javascripts/controllers/%s_spec.coffee", |