The summary pretty much covers it in terms of what was presented. There definitely would not have been enough time to discuss the changes they made at length.

Technically couldn't you just write a separate bash script that tests the exit status or return of anything you are scripting in bash? Feels like bringing in any other "framework" would possibly just get in the way?

I think the GP was talking about tests written in Bash, not tests for Bash code.

The even crazier runner is the one with MS who continues to run and is now one of the best distance runners in the country. She also collapses at the finish line. There was an ESPN short video piece about her last year:

http://espn.go.com/video/clip?id=11909407

The NYT wrote an article as well and it is linked in the above article but I thought I would call it out here:

http://www.nytimes.com/2014/03/04/sports/for-runner-with-ms-...

Yeah I remember the video. I think it was shared here inclusive.

It's incredible how amazing is the people. Even with their fragility, their own limitations and problems and yet they can do amazing things.

I want to throw the little go book into the ring as another great resource:

http://openmymind.net/The-Little-Go-Book/

Short and also freely available.

Wanted to say, you can potentially do better than this in go for arbitrary JSON:

type JSON map[string]interface{}

Go ahead and use the json.RawMessage type instead:

http://golang.org/pkg/encoding/json/#RawMessage

Not even going to wade into the lack of generics war, still very happy without them and going on a full year of Go usage.

Yeah, I almost never use map[string]interface{} when unmarshalling JSON. Most JSON has a static structure (and I'd argue that any JSON that doesn't is misbehaving). If the structure is static, you can simply use a struct that represents this[0].

If it doesn't, then you just use json.RawMessage to defer unmarshalling, but you can still dispatch to a finite number of structs that represent the universe of possible responses.

[0] And no need to write it all out by hand - if you have a single example JSON response, you can generate it automatically: https://github.com/ChimeraCoder/gojson

The biggest benefit in my opinion as that every person who implements balanced can "own" a piece of the company. You don't like something, change it. You want to propose a new feature, do it. Being able to directly impact a product you have implemented is a rarity in today's marketplace and it should be encouraged.

Zach, exactly! We think of Balanced as payments by developers. For example: we've got a guy named victor in Taiwan that's completely taken over work on the recurring billing/payouts engine we're building called Billy. Since Billy is completely open-source (just another Balanced API client), he can work on it as he likes. Check it out: https://twitter.com/balancedbilly

So,

I love the writeup and the product but I am surprised that you didn't run into draft when doing your research:

https://draftin.com/

It's exactly the competitor you were looking for and Nate is a totally awesome guy who I am sure you could even ask for advice while building your product!

Doing some research on my own, you focused on "GitHub for writers" which uses a very specific player in the version control space. Seems that being more generic in your search terminology with "version control for writers" leads directly to what you were searching for.

I think you might've read too quickly.. this is almost exactly what I wrote:

In my case, the ‘GitHub for writers’ concept is really just a specific solution to umbrella categories of ‘collaboration for writers’ and ‘version control for writers’, so I found competitors under those terms. Draft, Editorially, and Authorea are some of them (now part of a huge list of competitors in my folder, too).

This should get you comfortable with using the h,j,k,l mapping then. I actually turn arrow keys off in my vimrc, I can definitively say it is one of the things that has made me faster.

Do not turn them off; remap them! That is valuable keyboard real estate.

I use them for buffer switching, since I do that frequently. Left and right change to the next and previous buffers, respectively. Down to quickly swap to the previously focused buffer. Up to bring up a buffer switch menu. Here are the .vimrc lines:

    " Arrow keys for buffer switching
    nnoremap <left> :bprev<cr>
    nnoremap <right> :bnext<cr>
    nnoremap <down> :buffer #<cr>
    nnoremap <up> :buffers<cr>:buffer<space>

Such a good call! I don't use buffers enough :)

Great tip!

Good point about using this to get me comfortable with the keymapping. I dunno if I'll get too depressed from dying over and over before I get the hang of it though! ;)

Getting frustrated and depressed with keymapping? Sounds just like my experience using real vim ;)

Interesting that they launch this without API access and without adding it to the right hand nav. Sure, it's above your repo but I don't think that catches the eye enough and this is definitely meant to be a primary item users will be searching for.

I don't know who he is, you can add me to the count.

Now, will someone fill me in on the details?