In functional programming you often want to apply a function partly. A simple example is a function add
.
It would be nice if we could use add
like:
var res2 = add(1, 3); // => 4
var add10To = add(10);
var res = add10To(5); // => 15
# Roman Numeral Evaluation is a Monoid | |
# Chad Brewbaker | Software Engineer | Telligen.org | |
# [email protected] | |
# Initial release January 15, 2013 | |
class RomanMonoid | |
attr_accessor :prefix, :prefix_size, :suffix, :suffix_size, :suffix_credit, :sum, :homo | |
def initialize(val) |
/** | |
* Merge defaults with user options | |
* @private | |
* @param {Object} defaults Default settings | |
* @param {Object} options User options | |
* @returns {Object} Merged values of defaults and options | |
*/ | |
var extend = function ( defaults, options ) { | |
var extended = {}; | |
var prop; |
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
const I = x => x | |
const K = x => y => x | |
const A = f => x => f (x) | |
const T = x => f => f (x) | |
const W = f => x => f (x) (x) | |
const C = f => y => x => f (x) (y) | |
const B = f => g => x => f (g (x)) | |
const S = f => g => x => f (x) (g (x)) | |
const S_ = f => g => x => f (g (x)) (x) | |
const S2 = f => g => h => x => f (g (x)) (h (x)) |
My objective is to have some production files ignored on specific branches. Git doesn't allow to do it.
My solution is to make a general .gitignore
file and add .gitignore.branch_name
files for the branches I want to add specific file exclusion.
I'll use post-checkout hook to copy those .gitignore.branch_name in place
of .git/info/exclude
each time I go to the branch with git checkout branch_name
.
<!DOCTYPE html> | |
<html> | |
<head> | |
<title>Sine Wave</title> | |
<script type="text/javascript"> | |
function showAxes(ctx,axes) { | |
var width = ctx.canvas.width; | |
var height = ctx.canvas.height; | |
var xMin = 0; |
// __tests__/example.js | |
jest.mock('fs'); | |
it('should serve as a nice example', () => { | |
const fs = require('fs') | |
// fs can be set up at any point by calling __configureFs. | |
fs.__configureFs({ | |
'/test': { |
https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff
While attempting to explain JavaScript's reduce
method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.
JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List
is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu
Git is the key tool we use to allow multiple people to work on the same code base. Git takes care of merging everyone's contributions smoothly. Hence, learning how to use Git is critical to contributing to open source.
Exercise 1: Go through the Try Git Guide
Exercise 2: Learn How to file a github issue.