Pascal Hartig passy

A while ago I did some rage tweeting about job ads. Here is a list of helpful things people sent me to read then and since:

On good hiring generally

(diverse hiring generally) https://modelviewculture.com/pieces/25-tips-for-diverse-hiring
(hiring and retaining women) http://geekfeminism.wikia.com/wiki/HOWTO_recruit_and_retain_women_in_tech_workplaces
(Buzzfeed's approach to building a diverse team) http://www.buzzfeed.com/bensmith/what-were-doing-to-keep-building-a-diverse-editorial-operati#3jjmnvr

On programming tests

https://twitter.com/alicebartlett/status/528300863333605376

Several developers asked me about how difficult it will be to migrate Angular 1 to Angular 2. Angular 2 isn't done, so I legitimately have no idea how hard it will be. But there are a few high-level guiding principals in the design of Angular 1 that make adapting to changes like this fairly painless.

Angular 1 was designed so it would have a fairly minimal API surface. Let's look at controllers, since these are the meat of your app. Controllers are just functions that get passed other components as arguments:

MyController ($scope) {
  $scope.list = [];
  
  $scope.addItem = function (name) {
    $scope.list.push({

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

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

	module Main where

	import Debug.Trace

	import Data.Tuple
	import Data.Either
	import Data.Lazy

	class Memo a where
	memo :: forall r. (a -> r) -> a -> Lazy r

	#include <utility>
	#include <iostream>

	struct void_
	{
	template<typename Stream>
	friend Stream &operator<<(Stream &s, void_)
	{
	return s << "()";
	}

	var Dialog = React.createClass({
	render: function() {
	// 1) render nothing, this way the DOM diff will never try to do
	// anything to it again, and we get a node to mess with
	return React.DOM.div();
	},

	componentDidMount: function() {
	// 2) do DOM lib stuff
	this.node = this.getDOMNode();

	import com.google.auto.value.AutoValue;
	import java.lang.annotation.Retention;
	import java.lang.annotation.Target;

	import static java.lang.annotation.ElementType.TYPE;
	import static java.lang.annotation.RetentionPolicy.RUNTIME;

	/**
	* Marks an {@link AutoValue @AutoValue}-annotated type for proper Gson serialization.
	* <p>

	module FizzBuzzC

	%default total

	-- Dependently typed FizzBuzz, constructively

	-- A number is fizzy if it is evenly divisible by 3
	data Fizzy : Nat -> Type where
	ZeroFizzy : Fizzy 0
	Fizz : Fizzy n -> Fizzy (3 + n)


	<!-- Declare the permission for body sensor -->
	<uses-permission android:name="android.permission.BODY_SENSORS" />