In the new year, I plan on archiving the repositories below. Because I plan on only archiving the repositories, any project that depends on any of these projects will continue to work. However, I will no longer be accepting issues or pull requests and will never tag a new release.
The reality of each of the projects listed below is that I've almost completely ignored issues and pull requests for
This document covers how to setup netboot.xyz, a service that provides iPXE-based installation and live boot of a bunch of operating systems, on a Ubiquiti EdgeRouter.
I've made a few assumptions throughout this document that will probably be different for your setup:
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
| provision_list: | |
| ############################################ | |
| "staging-apps+search": | |
| ############################################ | |
| env: staging | |
| count: 1 | |
| roles: | |
| master: yes # has all the background services (cron) |
| # Interpret the Ansible log for humans. In particular, we | |
| # look for command executions and format their content | |
| # | |
| # - name: list files | |
| # shell: "ls -lrt *e*" | |
| # | |
| # Might produce | |
| # | |
| # TASK: [1] *********************************************************** | |
| # changed: [localhost] |
| SUBMODULE=lib/ansible/modules/core | |
| SUBMODULE_COMMIT=4d9ce9cf2cdee14b1c417e92059d4ef83dbcc457 | |
| for superproject_tag in $(git tag); do | |
| git ls-tree -r $superproject_tag | grep $SUBMODULE | awk '{ print $3 }' | while read submodule_commit_in_superproject_tag; do | |
| (cd $SUBMODULE && git rev-list $submodule_commit_in_superproject_tag | grep $SUBMODULE_COMMIT >/dev/null && echo "Found submodule commit in superproject tag $superproject_tag") | |
| done | |
| done |
| - name: Launch {{env}}-{{service}} Instance(s) | |
| hosts: localhost | |
| gather_facts: false | |
| connection: local | |
| vars_files: | |
| - group_vars/env/{{ environment }}.yml | |
| - group_vars/service/{{ service }}.yml | |
| - group_vars/admin.yml | |
| # Launch instances with the following parameters. Register the output. |
This is a simple little note I wrote down when talking to another company owner on the topic of moving a fully distributed team (with some folks in the same city) to a mostly-distributed team with an HQ office in a single city. It's not necessarily useful as general advice beyond that
I often advise clients that are actively focused on improving their teams to either embrace a fully-distributed team or a fully-colocated one, and to avoid other permutations of organization. Patterns that I see a lot:
n similarly-sized engineering offices
I was asked to get some feedback on the following definition:
Dear Mr. Debois,
I would like to ask you for some feedback on the following definition drafts for the terms release engineering and DevOps.
Here, at RWTH Aachen University in Germany, we try to find definitions for those terms as part of a seminar in software engineering. Moreover, >in my work, I try to point out the differences between release
| <%= stylesheet_link_tag "application", :media => "screen,print" %> |