Rails 3.0 introduced support for routing constrained by subdomains.
A subdomain can be specified explicitly, like this:
match '/' => 'home#index', :constraints => { :subdomain => 'www' }
require 'benchmark' | |
require 'sexpistol' | |
require 'sxp' | |
require 'strscan' | |
class Lexer < StringScanner | |
def next_token | |
# Housekeeping. | |
skip /\s*/ |
I've been using this technique in most of my Ruby projects lately where Ruby versions are required:
.rbenv-version
containing the target Ruby using a definition name defined in ruby-build (example below). These strings are a proper subset of RVM Ruby string names so far....rvmrc
(with rvm --create --rvmrc "1.9.3@myapp"
) and edit the environment_id=
line to fetch the Ruby version from .rbenv-version
(example below).Today I learned about another Ruby manager, rbfu, where the author is using a similar technique with .rbfu-version
.
(use '[datomic.api :only [q db] :as d]) | |
(def uri "datomic:mem://accounts") | |
;; create database | |
(d/create-database uri) | |
;; connect to database | |
(def conn (d/connect uri)) |
Many programming languages, including Ruby, have native boolean (true and false) data types. In Ruby they're called true
and false
. In Python, for example, they're written as True
and False
. But oftentimes we want to use a non-boolean value (integers, strings, arrays, etc.) in a boolean context (if statement, &&, ||, etc.).
This outlines how this works in Ruby, with some basic examples from Python and JavaScript, too. The idea is much more general than any of these specific languages, though. It's really a question of how the people designing a programming language wants booleans and conditionals to work.
If you want to use or share this material, please see the license file, below.
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
/* | |
On OS X, basic text manipulations (left, right, command+left, etc) make use of the system key bindings, | |
and don't need to be repeated here. Anything listed here will take precedence, however. | |
*/ | |
[ | |
{ "keys": ["super+shift+n"], "command": "new_window" }, | |
{ "keys": ["super+shift+w"], "command": "close_window" }, | |
{ "keys": ["super+o"], "command": "prompt_open" }, | |
{ "keys": ["super+shift+t"], "command": "reopen_last_file" }, | |
{ "keys": ["super+alt+up"], "command": "switch_file", "args": {"extensions": ["cpp", "cxx", "cc", "c", "hpp", "hxx", "h", "ipp", "inl", "m", "mm"]} }, |
ClojureScript does not have a standalone macro system. To write ClojureScript macros, one must write them in Clojure and then refer to them in ClojureScript code. This situation is workable, but at a minimum it forces one to keep ClojureScript code and the macros it invokes in separate files. I miss the locality of regular Clojure macros, so I wrote something called maptemplate
that gives me back some of what I miss. The technique may be useful in other scenarios.
Suppose you're wrapping functionality in another namespace or package so that you can have your own namespace of identically named but otherwise decorated functions:
ClojureScript:
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying