Without wanting to detract from the engineering accomplishments here (which I have never come close to), it's important to note that low-latency does not appear to be a design criteria i.e. it's okay if it takes a couple minutes to process events during peak load, which means there is some leeway for smoothing the input peaks over processing time.
Furthermore, these are just click events. It's okay to lose a few, so the design doesn't have to be especially good at making sure events aren't lost, as far as I can tell.
A good design is as much about what is left out as what is left in, which is the lesson between the lines here in my opinion.
My thoughts exactly. If you come to my house and ring the bell, but it takes me 15mins to get off the couch to reach the door, I can't really claim to be "available" with a straight face. Sure, I "technically" am available, but that level of latency is not practical.
>> The system is still available if your ring gets an acknowledgement of receipt
This is the equivalent of (as per my example) yelling out "I hear ya! Coming..." and then take 15mins to reach the door. I never said that low latency implies anything about the level of availability; I merely meant that arguing about the availability of systems is incomplete without a thorough discussion of latency.
In the case of Bitly, I'm just curoius about the systems that are highly available but "require" low latency vs systems that don't require it. As ryanjshaw points out, the system may have a degree of tolerance for lossy click events. If you have a heterogeneous mix of systems with different tolerance levels, that surely affects the architecture does it not?
We'll probably do a small beta as we get the local cloud ready for release to make sure things are easy to use and work as expected. Since it'll be open source, I'm hoping the beta group can help find bugs and even send in pull requests if there are pieces they want added. The beta signup thread is here at the moment: https://community.spark.io/t/where-is-the-source-code-for-th...
I would not use Camlistore as an example for typical Go best-practices. Aside from the fact that >30% of the project (by Github's estimation) is written in various other languages, the opening comment on the Makefile reads, "The rest of this Makefile is mostly historical and should hopefully disappear over time."
Also, GP is conflating the issues of (1) fetching dependencies, (2) building a project, (3) installing the project. Makefiles aren't inherently evidence against "go get"; there is no reason that "go get" couldn't call "make" instead of "go build" (which it does).
The main reason that (almost) no pure Go projects have Makefiles anymore is because they're frankly not needed. The standard Go build tools are more than sufficient.
Don't take my word for it, though. Hop on #go-nuts on freenode and ask the guys there (many of whom are core contributors) what they think of Makefiles. They'll tell you the same thing that they told me over a year ago when I tried to advocate the use of Makefiles in pure Go projects.
 For what it's worth, before Go 1.0 came out, projects had Makefiles. The fact that Makefiles were a part of the standard build process and later removed should be a hint as to what the idiomatic Go approach is considered to be.
 "go get" isn't exactly a build tool in this sense; it's a convenience wrapper for cloning using git/hg/etc., followed by "go build" and "go install"
> Also, GP is conflating the issues of (1) fetching dependencies, (2) building a project, (3) installing the project. Makefiles aren't inherently evidence against "go get"; there is no reason that "go get" couldn't call "make" instead of "go build" (which it does).
Go get conflates those issues. It fetches dependencies, builds the project, and installs it.
You don't need Makefiles, you're right. You need a script that sets GOPATH and calls "go build".
The most important thing is to not depend on the whims of somebody else's repository. In the best case, they'll push an update and break your code for a while. In the worst case, they'll delete their repo; then you get to find your local copy, push it to github, and change all your source files to point to that.
Heaven help you if other people want to fork your project. Say I wrote "github.com/jff/bigproject", which depends on my package "github.com/jff/mypackage". Now, if Joe wants to fork the package and make a tweak, he also has to fork the main project and change all of its imports to point to github.com/joe/mypackage so he can compile and test it. Of course he can't very well push that, he'll have to revert the import changes again assuming I accept his pull request for mypackage. I've dealt with this in real practice when we had 3 people working on a project which imported 3 other packages. We were forever dealing with build failures and changed import paths and of course could hardly do a pull from one fork to another. It was hell.
Better to distribute the entire workspace, with src/ containing all the packages you need and nothing else.
Yeah, that's pretty ballsy. Seems like they're exposing themselves to unnecessary poaching risk. And what do they do in that situation? What if someone has a competing offer and they want to keep them around? Offer a bonus?
People don't work that way. There is quite a bit of discontent or discomfort people will put up with until they are sufficiently motivated to take action. The number of people who are underpaid by 30% and unwilling to look for another job is far greater than the number who would accept that offer once its in front of them.
Nope, you talk about transparency, fairness, etc. If you're sticking to that salary structure you're not going to win on price in this market.
Warm fuzzies are important to a lot of people, look at how non-profits retain people. Also, there are a lot of people who don't know how to negotiate that would probably benefit from something like this.
I know a few devs who stick around at places because they like the people, etc, despite having had multiple offers for more money. Not my style, but it takes all sorts.
> I know a lot of devs who stick around at places because they like the people, etc, despite having had multiple offers for more money.
Sure, but that's not the only consideration here. Employees don't always have the option of sticking around at a company. Not all startups make it, and people are terminated or laid off from jobs they love all the time.
If and when the time comes to find another job, a public record of your previous salary may not benefit you in your negotiations with prospective employers.
In general, it's seen as bragging if your salary is high, and mortifying if your salary is low, so it's usually just better to keep your mouth shut about it.
I've told a number of people my salary and regretted it every time. They seem to take a vicarious pleasure in telling other people how much money I make. "Oh, you should listen to delluminatus, he makes $xx thousand a year." Ugh.
Companies (especially large ones) don't like it as it limits their negotiation position it can also disclose indirect discrimination e.g. "oops all the females seem to be under paid by 10/20%" which can get expensive.
And it also limits employees when they want to move as the new employer knows how much they make now.