I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
#!/bin/sh | |
# 初期設定 | |
WORK=$HOME/Builds/GCC | |
PREFIX=$HOME/mingw | |
export PATH="$HOME/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin" | |
# ソースコードのダウンロード | |
if [ ! -d $WORK/src ] ; then | |
mkdir src |
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
/// Playground - noun: a place where people can play | |
/// Church-Turing clan ain’t nothing to func with. | |
/// Church encoding is a means of representing data and operators in the lambda | |
/// calculus. In Swift, this means restricting functions to their fully curried | |
/// forms; returning blocks wherever possible. Church Encoding of the natural | |
/// numbers is the most well-known form of encoding, but the lambda calculus is | |
/// expressive enough to represent booleans, conditionals, pairs, and lists as | |
/// well. This file is an exploration of all 4 representations mentioned. |
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
// | |
// Free.swift | |
// Swift_Extras | |
// | |
// Created by Robert Widmann on 9/19/14. | |
// Copyright (c) 2014 Robert Widmann. All rights reserved. | |
// | |
import Foundation |
import Graphics.Element (Element, flow, down) | |
import List (map) | |
import Text (asText) | |
main : Element | |
main = | |
let fizzBuzz n = case (n % 3, n % 5) of | |
(0, 0) -> "FizzBuzz" | |
(0, _) -> "Fizz" | |
(_, 0) -> "Buzz" |
#!/usr/bin/env xcrun swift -i | |
import Foundation | |
import Darwin.ncurses | |
initscr() // Init window. Must be first | |
cbreak() | |
noecho() // Don't echo user input | |
nonl() // Disable newline mode | |
intrflush(stdscr, true) // Prevent flush |
It has been brought to my attention that there was more use for the unintended values()
functionality that I had outline in my "Other Languages" Java example below.
On the Swift Evolution mailing list, one developer outlined their requirement to loop through an array of enum
case values to add different states to objects.
Another example where a values
array would be useful if the developer wants to do something different for each different case, such as setting an image on a UIButton
subclass for each different UIControlState
#import <CommonCrypto/CommonCrypto.h> |