thomaswhyyou

Prelude

I. Preface and Motivation

This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.

For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai

thomaswhyyou

import React from 'react';
import GoogleAnalytics from 'react-ga';

if (process.env.REACT_APP_ENVIRONMENT === 'production') {
  GoogleAnalytics.initialize('UA-91111111-1');
}

const withGA = WrappedComponent => {
  const trackPage = page => {
    GoogleAnalytics.set({ page });

thomaswhyyou

// http://codepen.io/ClaireLarsen/pen/XmVyVX/

<svg viewBox="0 0 960 300">
	<symbol id="s-text">
		<text text-anchor="middle" x="50%" y="80%">Montserrat</text>
	</symbol>

	<g class = "g-ants">
		<use xlink:href="#s-text" class="text-copy"></use>
		<use xlink:href="#s-text" class="text-copy"></use>

thomaswhyyou

import hoistNonReactStatic from 'hoist-non-react-statics';
import React from 'react';

function getDisplayName(WrappedComponent) {
  return WrappedComponent.displayName || WrappedComponent.name || 'Component';
}

// See: https://facebook.github.io/react/docs/higher-order-components.html
export default function mutatable({ mutationName = 'mutate' } = {}) {
  return (SourceComponent) => {

thomaswhyyou

What I Wish I'd Known About Equity Before Joining A Unicorn

Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.

This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would

thomaswhyyou

var RecursiveChildComponent = React.createClass({
  render() {
    return <div>
      {this.recursiveCloneChildren(this.props.children)}
    </div>
  },
  recursiveCloneChildren(children) {
    return React.Children.map(children, child => {
      if(!_.isObject(child)) return child;
      var childProps = {someNew: "propToAdd"};

thomaswhyyou

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 6561 lines of CSS (and just 5 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

• SUIT CSS naming conventions + SUIT CSS design principles;
• PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
• Flexbox is awesome. No need for grid framework;
• No DRY. It does not scale with CSS, just focus on better components;

thomaswhyyou

Who pays when startup employees keep their equity?

JD Maturen, 2016/07/05, San Francisco, CA

As has been much discussed, stock options as used today are not a practical or reliable way of compensating employees of fast growing startups. With an often high strike price, a large tax burden on execution due to AMT, and a 90 day execution window after leaving the company many share options are left unexecuted.

There have been a variety of proposed modifications to how equity is distributed to address these issues for individual employees. However, there hasn't been much discussion of how these modifications will change overall ownership dynamics of startups. In this post we'll dive into the situation as it stands today where there is very near 100% equity loss when employees leave companies pre-exit and then we'll look at what would happen if there were instead a 0% loss rate.

What we'll see is that employees gain nearly 3-fold, while both founders and investors – particularly early investors – get dilute

thomaswhyyou

defmodule MyApp.User do
  def changeset(model, params \\ :empty) do
    model
    |> cast(params, @required_fields, @optional_fields)
    |> validate_format(:email, ~r/@/)
    |> validate_length(:password, min: 8)
    |> validate_format(:password, ~r/[0-9]+/, message: "Password must contain a number") # has a number
    |> validate_format(:password, ~r/[A-Z]+/, message: "Password must contain an upper-case letter") # has an upper case letter
    |> validate_format(:password, ~r/[a-z]+/, message: "Password must contain a lower-case letter") # has a lower case letter
    |> validate_format(:password, ~r/[#\!\?&@\$%^&*\(\)]+/, message: "Password must contain a symbol") # Has a symbol

thomaswhyyou

https://www.reddit.com/r/elixir/comments/4jk1sv/elixir_process_vs_node_child_process/d379lf6

So node processes created from spawn are actual OS processes. OS processes are expensive to create and have a lot of overhead which aren't strictly necessary for getting concurrency benefits. So as a semi-lightweight alternative you have threads, which are cheaper to create. But great as they are, at the end of the day you can only physically run one thread per core of a process at any given time.
Another kind of thread is a "green thread", which is a thread that is scheduled on a VM instead of by the OS like a native thread.
To take full advantage of the available processes and threads, what the Erlang VM does is it spawns one native thread per processor core and runs multiple green threads on a single native thread. Each native thread runs an Erlang Scheduler that intelligently runs and trades Erlang Processes between threads, giving them a set number of operations to run before switching to a different Erlang Proc