Ilkka Poutanen ilkka

set -e, -u, -o, -x pipefail

The set lines

These lines deliberately cause your script to fail. Wait, what? Believe me, this is a good thing.
With these settings, certain common errors will cause the script to immediately fail, explicitly and loudly. Otherwise, you can get hidden bugs that are discovered only when they blow up in production.

set -euxo pipefail is short for:

set -e
set -u

Things I believe

This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.

Agree? Disagree? Feel free to let me know at @JanStette.

Fundamentals

Keep it simple, stupid. You ain't gonna need it.

Important: At the time of writing (2019-11-11) Immutable.js is effectively abandonware, so I can no longer recommend anyone to follow the advice given here. I'll leave the article here for posterity, since it's still getting some traffic.

Understanding Immutable.Record

Functional programming principles and with it immutable data are changing the way we write frontend applications. If the recent de-facto frontend stack of React and Redux feels like it goes perfectly together with immutable data, that's because it's specifically designed for that.

There's several interesting implementations of immutable data for JavaScript, but here I'll be focusing on Facebook's own Immutable.js, and specifically on one of i

How to show migration guides in GitHub Markdown

Use the diff code highlighting tag.

  ```diff
  - foo
  + bar

Example:

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

	---
	AWSTemplateFormatVersion: '2010-09-09'
	Description: 'Cloudformation stack to manage permission to deploy a serverless service'

	Parameters:
	ServiceName:
	Description: Name of the Service you want to deploy
	Type: String
	ServiceName2:
	Description: Name of the 2nd Service you want to deploy

	# this script prints the preferred apache mirror and path_info to download components;
	import urllib
	import json
	url="https://www.apache.org/dyn/closer.cgi?as_json=1"
	#url='https://www.apache.org/dyn/closer.cgi/maven/maven-3/3.0.5/binaries/apache-maven-3.0.5-bin.tar.gz?as_json=1'
	result=json.load(urllib.urlopen(url))
	print result['preferred']
	print result['path_info']