All functions in Haskell are curried by default

Your `add2` uses a tuple instead of currying whereas `add1` is already curried. In ghci:

    Prelude> (+) 3 4 == (+ 3) 4
    True

So you could have an `add3` just by applying 3 as the first argument.

    Prelude> let add3 = (+ 3)
    Prelude> add3 5
    8

hoogle describes uncurry as a function on pairs. https://www.haskell.org/hoogle/?hoogle=uncurry

> uncurry converts a curried function to a function on pairs.

> All functions in Haskell are curried by default

That's not really a meaningful statement. Functions are not really anything "by default".

Care to elaborate? I'd say functions in Haskell are many things "by default":

- Curried

- Partial

- Lazy

- Values

- Recursive

- etc.

Let's elaborate on "curried" since that was what OP was interested in. How are functions in Haskell "curried" by default? Sure, you can write

    f x y = 2 * x + y

and that will define a function that takes an Int, say, returns a function. But why is that any more "default" than

    g (x, y) = 2 * x + y

?

All functions in Haskell are single-argument functions. Multiple arguments are syntactic sugar. The syntax sugar can make it confusing to talk about but if you define an `add` function that takes two arguments x and y:

    add x y = x + y

it's sugar for multiple single-argument functions.

    add = \x -> \y -> x + y

When examining it this way, the `g` function above would translate to

    g = \(x, y) -> 2 * x + y

Which is a function taking a single tuple argument. It is still "default curried" but the argument being passed in is a single argument rather than multiple so we don't expand it to multiple single-arg functions. Perhaps it is more illustrative to show the definition as the single argument it is rather than using haskell's destructuring to pull x and y out of the tuple.

    g tuple = 2 * (fst tuple) + (snd tuple)

and a ghci session for completeness:

    Prelude> let g (x, y) = 2 * x + y
    Prelude> g (1,2)
    4
    Prelude> let y tuple = 2 * (fst tuple) + (snd tuple)
    Prelude> y (1,2)
    4

So when we say that Haskell functions are "curried by default", what we're referring to is roughly the underlying single-argument nature of haskell functions.

Those are different functions. Your `g` function takes a single argument, but it's a composite datatype. It's akin to the following Javascript:

    function g(args) {
      return 2 * args[0] + args[1];
    }

You're right that we could write either `f` or `g`, but the reason `f` is the "default" way is that it involves no extra datatypes. Consider the following:

    h [x, y] = 2 * x + y

I wouldn't say this is "default behaviour" in the same way as `f` or `g`, but it certainly seems 'closer' to `g`. Similarly:

    data Pair a b = MkPair a b
    i (MkPair x y) = 2 * x + y

This seems very "non-default", especially since it's using a non-default datatype. Yet that datatype is alpha-equivalent to `(x, y)`.

Whilst tuples (or the above `Pair`) are isomorphic to curried functions (e.g. via the `uncurry` function and its inverse), they're not alpha-equivalent, so there is a meaningful distinction between tuples and curried functions. Since tuples are defined in the Prelude, we could do away with them (and use `MkPair` instead, if we wanted), so they're not really "built in". On the other hand, functions are (AFAIK) built quite strongly into the core of Haskell, and hence we cannot avoid them, making them, and hence the function-returning behaviour of currying, more pervasive, unavoidable and hence "default".

(Note that Haskell may at some point be less tied to functions; e.g. Conal Elliot's 'compiling to categories', among others, looks like a reasonable justification for allowing something like an "OverloadedFunctions" pragma)

windmove is probably it -- https://www.emacswiki.org/emacs/WindMove

link-rest fits the use case where you might not be able to transition the REST endpoint to be behind a GraphQL API (and thus be server-side resolvable which is definitely preferable) due to organizational or other concerns.

Right, but it would be great to take full advantage of the existing rest endpoint server-side. With that you don't even necessarily need to build GraphQL apis at all, and sort of get the best of both worlds.

I've been super excited about Chrome headless but haven't had a chance to dig into using it yet. The api here looks amazing for getting started without getting lost in the weeds. It'd be fairly trivial to hook this up to a Slackbot and to get on-demand screenshots of various pages on my websites, etc.

A month ago I was trying to migrate some tests from phantomjs to chrome headless. The big blockers I ran into were that chromedriver automation has certain functionality that only works with a special chrome extension that it installs- but headless chrome doesn't support extensions.

There's work being done to fix this, but it's still in progress, last I checked. Until then, resizing windows, taking screenshots and a handful of other things simply don't work.

Loading (and error, etc) state should be the responsibility of the component doing the content rendering, not the parent. So the ConditionalSpinner component:

   <ConditionalSpinner renderIf={data}><PersonRenderer person={data.person} /></ConditionalSpinner>

Could be written better as:

   <PersonRenderer person={data.person} />

Where PersonRenderer would be defined as such:

   class PersonRenderer extends Component {
     render() {
       if(this.props.person) {
         return <div>personcontent</div>
       }
       return <LoadingIndicator/>
     }
   }

Given this, I'm still not sure how an If "component" would be achieved (and further, you'd need an Else or a Switch component anyway if going down this route). Maybe you could explain the benefits of such a path?

or create a wrapper function ...

  function withLoadingIndicator(Wrapped) {
    return function(props) {
      if (props.loading) {
        return (<LoadingIndicator />);
      }
      return (<Wrapped {...props} />);
    }
  }

  // ...

  export class PersonRenderer extends Component {
    render() {
      return <div>personcontent</div>
    }
  }

  export default withLoadingIndicator(PersonRenderer);

I first learned about this method with react-dnd and have used it extensively since. Quite elegant.

> Loading (and error, etc) state should be the responsibility of the component doing the content rendering

It's often divided in two: One container fetching the data, and a pure component rendering it.

I think my intent might have come across wrong here.

The "states" aren't related to container/dumb components or data-fetching/selection logic. They're purely about rendering the state for a given segment of the page. Perhaps this article[0] might help convey my intent. It's more about how to render "we didn't get data from that one endpoint for this section of the page" or "we're waiting for the data to show up", etc.

[0]: https://medium.com/swlh/the-nine-states-of-design-5bfe9b3d6d...

FWIW webpack's docs are getting much better for v2

You can use something like dataloader[0] or haxl[1] to help with this issue.

[0]: https://github.com/facebook/dataloader

[1]: https://github.com/facebook/Haxl

It is possible to use Symbols instead of strings, which yields some nice improvements in terms of no longer allowing construction of actions with potentially misspelled strings, etc.

That's not actually a good idea: https://github.com/acdlite/redux-actions/issues/20#issuecomm...

You link to a comment which indicates serialization is a potentially breaking issue. This is a tradeoff that does not affect the routine behavior of redux but may affect advanced use cases such as allowing user upload of action history for bug reports.

Regardless of serialization/replay-ability, the core of the suggestion is to `import` some constant instead of using raw strings. Symbols have the benefit of forcing an import, whereas a list of constants that reference strings can be "bypassed" by writing the correct string in a random file. In fact, the redux actions documentation uses the following example of this pattern as the first example.

``` // fileA const ADD_TODO = 'ADD_TODO'

//fileB { type: ADD_TODO, text: 'Build my first Redux app' } ```

If you go the docker-machine route, you can do the following.

    brew install docker-machine
    docker-machine create --name myserver ...digital-ocean-options
    eval $(docker-machine env myserver)
    docker ps

that is:

* install docker-machine

* provision a droplet with docker on it (you can also use test.docker.com to use an RC instead of the latest release)

* set your local shell env to point docker to said machine

* use the docker client to interact with said machine

I also use docker-for-mac and a similar process to spin up swarm-mode clusters. You can also ssh into the machine if you need to by `docker-machine ssh myserver`

[0]: https://docs.docker.com/machine/drivers/digital-ocean/

This is a pretty standard use-case from my experience. I'm new to docker but I work with a lot of different startups via consulting and they are all starting to use docker and almost everyone is using docker-compose, and/or docker-machine for their set ups.

It's probably worth investing in learning docker-compose.

Very cool, I'll give this a shot!

Having React on a static blog makes it easier to share component libraries that you've built up on other projects (perhaps SPAs) with said static blog.

It also allows the use of React's ecosystem, such as react-helmet[0], which makes it easier to change the meta tags and title on the page when rendering.

[0]: https://github.com/nfl/react-helmet

...which can be done with YAML frontmatter on a markdown file in other static site generator, simply referencing the frontmatter in the layout partial that you have wrapping every page anyway.

Right, except support for that has to be built into the static site generator you're using. In the React case, the user can choose how they want to do it without the SSG author caring at all. I will also say that in the case of frontmatter, react-helment is a far more powerful solution which allows defining at any point in the tree, not just a layout partial.

In addition, the React way allows you a full language to handle import/export for "templates" instead of relying on a hampered template language/partials implementation.

The key here isn't the specific instance of frontmatter, it's having the flexibility to use everything one might use to build a SPA to target static sites. This re-use of existing solutions and skills is important.