Skip to content

Instantly share code, notes, and snippets.

Avatar
💭
Looking for work

Danny Andrews danny-andrews

💭
Looking for work
View GitHub Profile
View unit-testing-back-to-basics.md

Testing

Terminology

Factory - A function which simplifies the construction of some test dependency (arguments, objects, etc.). Fixture - Any form of static test data. Test-Driven Development (TDD) - A programming discipline which emphasises writing tests as a part of code design, as easy of testing is a good indicator of code quality. Behavior-Driven Development (BDD) - A approach to writing tests which focuses on specification and user-facing behavior. Unit/System Under Test (SUT)/Test Subject — The simplest piece of self-contained functionality. It could be as simple as a method, or as complex as a class, but should be isolated sufficiently from collaborators. Test Case - One atomic test (usually implemented as a function) which runs some code and makes assertions about it. Test Double* - A generic term for any kind of pretend object used in place of a real object for testing purposes. Specific examples given below:

View oop-design-patterns-without-inheritence.md

OOP Design Patterns Without Inheritance

Over the last decade, the software industry has slowly been moving away from classical-inheritance in favor of more compositional patterns (mixins in Ruby, traits in Scala, etc.) and its begs the question: what happens to the OOP design patterns we've all come to know and love (or hate 😬) in a post-inheritance world? Additionally, what happens to these patterns when we have the full power of functional programming (first-class functions, partial application, monads, etc.) at our disposal?

These are the questions this article attempts to answer. So let's take another look at how the classical OOP design patterns patterns manifest themselves (if at all) in a functional programming language with support for objects. Although several superior languages fit this bill (OCaml, Lisp, etc.) my code examples are going to be in JavaScript, because of its approachable syntax and large user-base.

In my examples, I'll be using the object creation technique simliar to the one o

View furry-curry.js
function namedCurry(source_fn, arg_order){
function receiver( received_values, n_received, defaults ){
received_values = (received_values || []).slice()
n_received = n_received || 0
Object.keys(defaults).forEach(function( input_arg ){
var value = defaults[ input_arg ]
var required_index = arg_order.indexOf( input_arg )
var is_known_argument = required_index > -1
View thing-i-save.js
const Future = require('fluture');
const R = require('ramda');
const {Reader} = require('monet');
const FakeDb = () => {
const data = {
1: {id: 1, name: 'bob', bff: 2},
2: {id: 2, name: 'alice', bff: 1}
};
View nested-monads.js
const Future = require('fluture');
const R = require('ramda');
const Reader = require('./monads/reader');
// Setup
const FakeDb = () => {
const data = {
1: {id: 1, name: 'bob', bff: 2},
2: {id: 2, name: 'alice', bff: 1}
};
View mixin-collision.rb
module A
def msg
'hello'
end
end
module B
def msg
'hi'
end
View art-for-import-temp.md

Level 1 (Loops) - (map, reduce, filter, more).

Level 2 (Callbacks/Async) - Use Promises (or better yet, Futures).*.

Level 3 (Assignment) - pipe or compose functions together to avoid unnecessary intermediate variable declarations.

A wild monad appears! Monet Olé!

Level 4 (null/undefined) - Use Maybe monad.*.

View render-prop-component-injection-crossover.jsx
const { Component } = React;
const { render } = ReactDOM;
const MyMug = ({ drink, verb = 'Drinking' }) =>
<div>{verb} an {drink}.</div>;
class Caffeinate extends Component {
state = { coffee: 'Americano' };
render() {
View compare-render-prop-solution-2.jsx
const LuckyNumber = ({ component: Component, componentProps }) => <Component number={Math.random()} {...componentProps} />;
const AppBody = ({ message, number }) => <div>{message}: {number}!</div>;
const App = ({ message }) => <LuckyNumber componentProps={{ message }} component={AppBody} />;
View compare-render-prop-solution-1.jsx
const LuckyNumber = ({ component: Component }) => <Component number={Math.random()} />;
// There's no general way to curry named parameters, so we have to do it
// manually.
const AppBody = ({ message }) => ({ number }) => <div>{message}: {number}!</div>;
const App = ({ message }) => <LuckyNumber component={AppBody({ message })} />;
You can’t perform that action at this time.