Models | Examples |
---|---|
Display ads | Yahoo! |
Search ads |
# before this file is loaded, a locale should be set: | |
# | |
# In a browser environment, you can use: | |
# ```<script>__locale='en';</script>``` | |
# | |
# In a server environment (specifically node.js): | |
# ```global.__locale = 'en';``` | |
# normalize in-app locale string to "en" or "de-AT" | |
parts = @__locale.split('-') |
Eduardo - http://amzn.com/w/32N99W91GA626 | |
Hélio - http://amzn.to/sdnYtJ | |
Suga - http://ow.ly/86Oj7 | |
Danilo - http://amzn.com/w/273L0ITRM85JV | |
Otavio - http://amzn.com/w/GZW8H6AOZONH | |
Guilherme - http://amzn.com/w/2M8E4LNY4FR8P | |
Vinicius - http://amzn.com/w/3DCAHIYA51X0Y | |
+-----------+----------+---------+ | |
| Nome | Comprou? | Chegou? | |
# place this in lib/fakeout.rb | |
require 'ffaker' | |
module Fakeout | |
class Builder | |
FAKEABLE = %w(User Product) | |
attr_accessor :report |
Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000
Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n
concurrent flows.
After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?
It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed
class Ticket < ActiveRecord::Base | |
belongs_to :grouper | |
belongs_to :user | |
validate :user_cant_be_blacklisted, on: :confirmation | |
validate :user_cant_double_book, on: :confirmation | |
validate :grouper_cant_be_full, on: :confirmation | |
validate :grouper_cant_have_occurred, on: :confirmation |
source 'https://rubygems.org' | |
gem 'rake' | |
gem 'lotus-router' | |
gem 'lotus-controller' | |
gem 'lotus-view' | |
group :test do | |
gem 'rspec' | |
gem 'capybara' |
/* bling.js */ | |
window.$ = document.querySelector.bind(document); | |
window.$$ = document.querySelectorAll.bind(document); | |
Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); }; | |
NodeList.prototype.__proto__ = Array.prototype; | |
NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); }; |
Should be work with 0.18
Destructuring(or pattern matching) is a way used to extract data from a data structure(tuple, list, record) that mirros the construction. Compare to other languages, Elm support much less destructuring but let's see what it got !
myTuple = ("A", "B", "C")
myNestedTuple = ("A", "B", "C", ("X", "Y", "Z"))