isaacs

// See comments below.

// This code sample and justification brought to you by
// Isaac Z. Schlueter, aka isaacs

// standard style
var a = "ape",
  b = "bat",
  c = "cat",
  d = "dog",

evancz

A vision for data interchange in Elm

How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?

These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.

Literature Review

By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.

martijnvermaat

Installation of NixOS with encrypted root

These are my notes on instaling NixOS 16.03 on a Lenovo ThinkPad X1 Carbon (4th generation) with an encrypted root file system using UEFI.

Most of this is scrambled from the following pages:

• Encrypted Root on NixOS - Nix Wiki
• Installing NixOS - Chris Martin
• Linux administration and use - Earl Douglas
• Installing NixOS on a ThinkPad W540 with encrypted root - Bluish Coder

evancz

Haskell Style Guide for Elm

Goal: a consistent style throughout all Elm projects that is easy to read and produces clean diffs to make debugging easier. This means valuing regularity and simplicity over cleverness.

Line Length

Keep it under 80 characters. Going over is not the end of the world, but consider refactoring before you decide a line really must be longer.

Variables

faisalman

/**
* Convert From/To Binary/Decimal/Hexadecimal in JavaScript
* https://gist.github.com/faisalman
*
* Copyright 2012-2015, Faisalman <fyzlman@gmail.com>
* Licensed under The MIT License
* http://www.opensource.org/licenses/mit-license
*/

(function(){

markerikson

May 12, 2016

[8:23 PM] jrajav:: Heya. I'm wondering what the function of components really are. Just don't fully understand - why not just pass in the state with something like store.subscribe( () => render( , document.getElementById('root') ) ) ?

[8:24 PM] jrajav:: Passing in dispatch functions as well

[8:24 PM] jrajav:: Then, split apart the state as appropriate further down for each subcomponent

[8:25 PM] jrajav:: If all of the components are pure, stateless functional components this approach should still be just as performant, right?

Chadtech

Someone in the Elm slack channel threw out this idea of naming Msg in the past tense, and not imperatively. I thought it was an interesting idea and I adopted the practice, just to try it out. I forgot who it was, I wish I could give them credit.

Anyway, the ramifications were more than I expected, and not simply the same Msg with different names. What I started doing is naming Msg as if they were saying "This happened". So where I would say "HandleUsernameField" I might instead say "UsernameFieldChanged" or instead of "Close" I would do "XClicked". What I didnt account for was that Msg and functionality dont map one to one. So for example, if you have a Msg named Navigate, its going to be the one Msg you use whenever you want to navigate. But if you are naming Msg as paste-tense descriptions, then several different things could happen that could cause a navigation. Since many things should cause a navigation, naming Msg in the past tense leads to lots of Msg which do the same thing.

alvivi

#!/usr/bin/env node

const fs = require("fs");
const parse = require("css").parse;
const path = require("path");

if (process.argv.length !== 3) {
  const exec = path.basename(process.argv[1]);
  console.log(`usage ./${exec} input.css`);
  console.log("converts css to elm-css snippets");