What are we trying to observe? Raw object data.
// Objects
var obj = { id: 2 };
obj.id = 3; // obj == { id: 3 }
// Arrays
var arr = ['foo', 'bar'];
arr.splice(1, 1, 'baz'); // arr == ['foo', 'baz'];
What are we trying to observe? Raw object data.
// Objects
var obj = { id: 2 };
obj.id = 3; // obj == { id: 3 }
// Arrays
var arr = ['foo', 'bar'];
arr.splice(1, 1, 'baz'); // arr == ['foo', 'baz'];
| ; ex. 1: | |
| (repeat 5 "Odelay!") | |
| ; ex. 2: | |
| (when-not (re-find #"aura" "restaurant") (System/exit 0)) | |
| ; ex. 3: | |
| (map clojure.string/capitalize ["toast" "cheese" "wine"]) | |
| ; ex. 4: |
This tutorial uses the "Sample hapi.js REST API" project.
Take a look at: https://github.com/agendor/sample-hapi-rest-api/
##Topics
| var E_PREFIX_RATE = 0.25; | |
| // All of our word lists: | |
| var _word_lists = { | |
| verb : [ | |
| "implement", "utilize", "integrate", "streamline", "optimize", "evolve", "transform", "embrace", | |
| "enable", "orchestrate", "leverage", "reinvent", "aggregate", "architect", "enhance", "incentivize", | |
| "morph", "empower", "envisioneer", "monetize", "harness", "facilitate", "seize", "disintermediate", |
| #!/usr/bin/env sh | |
| # first check to see if mongo service is running. you can't delete any files until the service stops so perform a quick check. | |
| launchctl list | grep mongo | |
| # NOTE: the pipe | symbol means the commands on the right performs on the output from the left | |
| # grep is a string search utility. `grep mongo` means search for the substring mongo | |
| # use the unload command to end the mongo service. this is required to 'unlock' before removing the service. | |
| # first look for the file to delete | |
| MONGO_SERVICE_FILE=$(ls ~/Library/LaunchAgents/*mongodb*) |
Copyright (c) 4-digit year, Company or Person's Name
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
A list of some other badges: http://shields.io/
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| import Control.Applicative | |
| import Control.Monad.ST | |
| import Control.Monad | |
| import Data.STRef | |
| while :: | |
| Monad f => | |
| f Bool | |
| -> f a | |
| -> f () |
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil