giuseppeg

// FizzBuzz solution with one comparison:
// Bitwise operations, using predefined 0-15 numbers mask

// live demo: http://jsfiddle.net/TbAuQ/
// source: http://www.zoharbabin.com/which-fizzbuzz-solution-is-the-most-efficient

var words = [undefined, "Fizz", "Buzz", "FizzBuzz"],
    mask = 810092048, //11 00 00 01 00 10 01 00 00 01 10 00 01 00 00
    c = 0;

pgilad

Generate private key

$ openssl genrsa -out private.key 4096

Generate a Certificate Signing Request

openssl req -new -sha256 \

joncalhoun

gotest() {
  go test $* | sed ''/PASS/s//$(printf "\033[32mPASS\033[0m")/'' | sed ''/FAIL/s//$(printf "\033[31mFAIL\033[0m")/'' | sed ''/FAIL/s//$(printf "\033[31mFAIL\033[0m")/'' | GREP_COLOR="01;33" egrep --color=always '\s*[a-zA-Z0-9\-_.]+[:][0-9]+[:]|^'
}

serras

Some thoughts on building software

Lately I have been busy reading some new books on Domain Driven Design (DDD) and software architecture -- including a short yet eye-opening one in Python and a great one in F#. At the same time, it seems that more people in the Functional Programming world are looking at more formal approaches to modelling -- some examples here. This has brought some thought from the background of my brain about how we should model, organize, and architect software using the lessons we've learnt from functional programming.

Before moving on, let me be clear about this being just a dump of some thoughts, not always well-defined, definite

snoyberg

#![feature(generic_associated_types)]

trait Functor {
    type Unwrapped;
    type Wrapped<A>: Functor;

    fn map<F, B>(self, f: F) -> Self::Wrapped<B>
    where
        F: FnOnce(Self::Unwrapped) -> B;
}