Shay Frendt shayfrendt

This is a quick brain dump of problems I've run into using Rails Engines.

Problems

Dependencies If an Engine requires a gem at version X, and the application requires the same gem at version Y. You could specify a lose version constraint on the Engine, but that's just asking for trouble. If the application updates to a newer version that the Engine isn't expecting, things go wrong.
Layouts/Assets To customize these, you need to overwrite certain magical paths. This ends up duplicating a lot of the engine and forces you to dig into the internals of how the Engine works rather than trusting it as a standalone component.
Models If you use an Engine's models, you're crossing into the Engine's abstractions again. It seems like a good place to share code, but it means your models will need to become versioned.
Complexity It's hard to debug problems when they come up. Is it coming from the engine, the app, or the app's overrides of the engine

The @roidrage meatballs extravaganza.

The secret ingredient to this recipe is letting everything stew for a few hours. First the tomato sauce, requires at least 90 minutes to 2 hours. Then the meatballs in the sauce another 90 minutes. The longer the better.

Once the meatballs are in the sauce, the more time you give them, the more delicious flavor will seep from the meat into the sauce, and vice versa. I'd recommend giving it a total of four hours for maximum taste extraction.

The long stew ensure that the fluids have evaporated and that you're left with the tastiest meatballs you've ever had.

Ingredients (serves four hungry people):

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

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

	# note - you may need to split into a before-deploy (stop) and after-deploy (start) depending on your setup

	desc "Hot-reload God configuration for the Resque worker"
	deploy.task :reload_god_config do
	sudo "god stop resque"
	sudo "god load #{File.join deploy_to, 'current', 'config', 'resque.god'}"
	sudo "god start resque"
	end

	after 'deploy:update_code', 'deploy:update_shared_symlinks'

	module Vagrant
	module Provisioners
	class Sprinkle < Base
	register :sprinkle

	class Config < Vagrant::Config::Base
	attr_accessor :cookbooks_path
	end

	def prepare

	function git_remote_url() {
	# DOES NOT WORK FOR HTTPS, ONLY [email protected]:username/repo.git
	git config --get remote.origin.url \| sed 's/git@//' \| sed 's/github/https:\/\/github/' \| sed 's/com:/com\//' \| sed 's/\.git//'
	}

	function git_current_branch_name() {
	git symbolic-ref HEAD \| sed 's/refs\/heads\///'
	}

	function git_push_open() {

	#!/bin/bash -x

	# This should be your "script/ci" checked into version control, and then wired as your sole build step in Jenkins.
	#
	# Simplifying Assumptions:
	#
	# * You build all branches
	# * You want to deploy all branches.
	# * You wired up an SSH key to your CI server appropriately so it can talk to your deployment target(s) via Cap

	#!/bin/bash

	# Sample use:
	# PATTERN="\"/some-route\"" FILE=config/routes.rb ~/bin/git-line-history.sh
	# Thanks to mikedillion <https://github.com/mikedillion> for the basis of this!

	set -e

	#PATTERN="version':"
	#FILE="setup.py"