SecondForge

If you’re using rspec 3, you might run into the following error when you try to run a views spec with the rake spec command:

1
2
3

Failure/Error: render
NameError:
  undefined local variable or method 'render' for #<RSpec::ExampleGroups::ViewNameHere>

If so, try two things: first, make sure that your spec has require 'rails_helper', not require 'spec_helper'. Additionally, make sure you specify type: :view in the RSpec definition, e.g. RSpec.describe 'view.html.erb', type: :view do.

I spend most of my time programming, but my formal academic education is a mixture of mathematics, statistics, and finance. I’ve recently been thinking about employment of programmers through the context of finance.

The value of financial assets, e.g. stocks, bonds, commodity futures, options, &c depends on the value of other assets¹. For example, the value of an option has been shown to depend on the current “risk free rate”, the price of the underlying security, and the volatility of the underlying security’s price, and the time to expiration of the option.

For each of these factors, we can calculate our “exposure”, which is just the first derivative of the price of the security we’re interested in, taken with respect to the factor we’re interested in calculating our exposure to. For bonds (as an example), this concept of “interest rate risk exposure” is called “duration”; the dollar duration is (approximately) the expected change in price of the bond in response to a 1% parallel change in the interest rate curve.

But this concept can be extended to non-financial assets well. After all, the simplest model of a company is as a bundle of assets, have a certain value that is a random process, and a bundle of liabilities, which also have a certain value that is determined by a random process. The value of the equity - that is, the company - is simply the (positive) difference between these two values; if the value of the assets becomes less than the value of the liabilities, the company goes into bankruptcy. This is actually one method of pricing certain kinds of credit derivatives, including credit default swaps².

And even though many assets don’t have straightforward pricing models - for example, there is no formula to give you the change in price on a stock based on a change in the price of oil, as you can calculate for bonds and interest rates - we can still calculate exposures using a mixture of fundamental and statistical methods.

This extends all the way down to your own work product. The hours you work generate a product - be it computer code, fine steak dinners, or something else - and the value of that work product is expected to change over time. This is the concept of “human capital” that is often bothers people who believe in a labor theory of value ³.

But, given that your current and future labor has value, it’s a good idea to figure out if you’re long or short that value. If you’ve entered into a freelance contract, or a regular employment agreement, you’ve agreed to sell your future work at a certain price at a certain time, repeatedly. You’ve entered into a futures contract. Are you long or short?

You’re short. You’ve sold your work product already; if it goes up in value in the mean time, you lose. If it goes down in value, you win, because you’ve already sold it. You are literally short yourself.

A certain amount of this is necessary. By working at a company, you gain access to resources that magnify the value of your work product significantly. And by shorting, you do get the peace of mind that comes with knowing how much you’ll get paid next week, month, or year, more or less.

But being short yourself means that you don’t get to benefit fully from your own learning, from your personal development, or from dumb luck or serendipitous ideas.

When do you want to be short? When you expect the underlying asset to go down in value. Do you think an hour of your time one year from now will be worth less than it is today? Do you want it to be worth less than it is today?

You’ll note that most wall street traders - perhaps those most familiar with the short/long dynamic - are (at least partially) long themselves, because they get paid a percentage of the profits they earn for the corporation. The more their work product goes up in value, the more they get paid.

Regardless of how you feel about wall street, there’s something to be learned from the traders.

At this point, many internet writers would urge you to go start your own company, and be 100% long your own work. I don’t think that is necessarily a good idea. There are huge advantages to not being 100% long your own human capital - diversification, reduced variance, peace of mind - and I firmly believe most people will be happier working for someone else, and being short themselves.

But, next time you’re discussing your work, think about what you’re short, and what you’re long. And if you are confident in yourself, maybe there’s a way to go long.

Many professional git users suggest that when working with remote git repositories, one should ‘always fetch and merge instead of pull’. The basic reason for this is that although the quick description of what ‘git pull’ does is ‘fetch the remote branch that your local branch tracks against and merge it into the local branch’, inspecting the source code shows that it actually does a lot more.

How do we actually do this? The syntax of git when working with remotes can be rather confusing.

First, understand that everything git does, happens with files on your machine. Running git branch -a will show you all the branches available to you, including a bunch that will be listed as something like remotes/origin/branchname (for a remote server named origin). These aren’t links to the remote, like you might expect; they’re local copies of the branch as obtained from the remote - which is known to be from a remote because of the remotes/ prefix. That remotes/origin/branchname branch exists on your machine and can be used without connecting to the network at all, though it’ll need to be periodically updated from the network.

In normal operations the only time git will connect to the network is if you run git fetch or git push, including running git fetch via git pull.

This explains the differences in syntax, which might be confusing at first. If we are working with the network, we need to specify which remote we’re working with, as a remote - not as part of a branch. So to update our remote-tracking branches from origin, we do git fetch origin, which will fetch all the origin branches. And if we want to push to origin, we use git push origin branchname, not git push origin/branchname; origin/branchname is a remote-tracking branch on our machine, not a remote machine.

On the other hand, when merging in the fetch & merge pattern, we aren’t interacting with the network at all; we’re just using our local copies of a remote branch. So, the correct command to merge the remote branchname branch into our local working branchname branch is git merge origin/branchname (while having the branchname branch checked out); we don’t need to specify the remote as an argument because we’re not interacting with the network at all.

Hopefully, this helps give a better understanding of how git works. Happy committing!

I’ve been experimenting with Middleman for a new static, non-blog site that I am working on. Figuring out how to give my template a dynamic title was much harder than it should have been, because the relevant section of the documentation doesn’t actually mention titles at all. The end result: all of the YAML frontmatter in your page file is accessed via the current_page.data object, so your title is current_page.data.title. Enjoy!

Congress recently passed a spending bill¹ that authorizes approximately $1T in federal expenditures, keeping the federal government working through the end of the year. The debate was contentious, and involves congresspeople fighting over line items as small as a $6m cut to the EPA.

In unrelated news, federal debt outstanding currently totals more than $10T. Despite S&P’s rating downgrade of the US in 2011, there is little doubt that the US has the ability to pay its debt obligations in principle.

Consider the structure of federal debt. More than $3T of treasury debt has a maturity of less than or equal to 1 year ².

Here’s a fact: if interest rates increase by 1%, within one year the federal government will be forced to refinance $3T of debt at the new, higher rates, incurring an additional $30B of interest expense each year. This is about the same as the budgets of NASA ($18B) and the IRS ($13B) combined.

And if interest rates increased to their long term postwar average of 3.57%³ for 3m bills (versus .02% today)⁴, within one year there would be additional interest expenditures of about $105B, which is more than the discretionary spending of the Department of Health and Human Services, and 1/5th the discretionary spending of the Defense Department⁵.