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:
// 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", |
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:
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.
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.
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.
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.
/** | |
* 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(){ |
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?
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.
#!/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"); |