"How We Moved Our API From Ruby to Go and Saved Our Sanity"... Right, so using Go will alleviate severe mental illness? Why isn't Golang all the buzz in professional psychologist and psychiatrist circles?
Slander is spoken falsehood, I think you meant libel. Also something is only a falsehood if it is false, and much of the writings here are quite characteristic of misogyny, rape culture (esp. apologetics), and male privilege as commonly used in SWE.
Nice straw-man, since I never claimed to be a victim (I was merely making an observation). Also citing your wife's individual experience is a red herring since she alone does not represent a large sample size.
"on display in these comments" is a pretty clear reference to a source. The people here defending the whole PUA genre are defending an objectification of women. The PUA approach treats women as objects that are to be manipulated to achieve the end the PUA desires. Defending such an objectification is a hallmark of male privilege throughout history, and furthermore is a type of misogyny and characteristic of rape culture.
This isn't a legal issue. You can write all you want promoting rape culture. Kickstarter, as a private company, is well within their rights and Terms of Service to pull your project if they find it in bad taste. And they should most definitely be commended for deciding that rape-culture-promotion is inappropriate.
It's easy to see why there aren't more women in computing with the mountain of rape culture, misogyny, and male privilege on display in these comments.
HTTP specification API, web-server, Sinatra-like DSL, and client implementations already exist in Julia (and are listed in the package manager): https://github.com/dirk/HTTP.jl
The server is also pure-Julia and doesn't require a shared library, unlike this project.
If you look at the bottom right under "Key stats and ratios"[1] you can see a trace of Google creating a time with 0 (default I guess) and spitting out the year (+/- 1 because of timezones) of the Unix epoch.
That's only the beginning of the flaws; I saw no mention of the author taking into account the individual scoring systems that the various reviewers used. Some reviewers can be quite harsh, and would use the majority of the 0-100 spectrum for scoring AAA titles, others (i.e. the ones getting the games for free from the publishers) tend to only use between 65-100 (65 being an arbitrary cutoff) on the scale (they'd give a 65 to a game that another reviewer who used the entire scale would give a 0 to). It's especially ironic that the author bashes Metacritic and other aggregation sites for being "shallow," then proceeds to churn out similarly shallow, infographic/graph-laden content. With something as incredibly subjective and contextual as a video game review, distilling a game to a numbered score is pretty ridiculous; then aggregating those scores together into a totally context-lacking mass is pointless, as the result would be totally lacking in almost any meaning whatsoever.
Read it three years ago; entertaining, engaging, and quite deep in it's development of characters within a relatively static environment. Definitely a great.
Mastering Regular Expressions by Jeffrey Friedl, the first edition (a.k.a. "The Perl Edition", http://regex.info/ for more information about the book and its editions)
It's my standard litmus test judging a programmer; if you haven't read or don't care to read a book on regular expressions, then I probably don't want to write code with you. It's also useful to remind people who think they're nerds because they own a smartphone and can download "apps" that they're in a league far below.
Totally air-tight houses can be a danger as well; in my home (which is old and "breathes"), a heater once malfunctioned; when I noticed the malfunction (black accumulant around the vents) and called a technician to come check it out, the technician said that if the house had been air-tight I would likely be either severely hospitalized or dead, so sometimes a little non-air-tightness can be good, especially since it encourages you to open the windows and doors and get some fresh air instead of relying on the air conditioner all year round.
Personally I hate extra features; but that doesn't mean that the possibility shouldn't exist. Diaspora's plans for opening up their system appears to be "we'll add plugins later." This seems fundamentally flawed to me. I'd rather use a protocol that had a minimalistic base that could then be extended with the desired functionality. I really don't care about relationship statuses, so why should I have my profile cluttered with them? The best extensions of a flexible protocol would grow in popularity as users demanded them; instead of having to wait for the Diaspora team or some other ruling body to approve your patch to add in a new feature, you could write your own extension to the base protocol and convince other people to implement that extension on their profiles. If other people liked them then they'd tell their friends, and the extension would spread organically according to demand, not by decree of some Overload of the Social Networks.
I don't really care about the users and features at this point; the foundation is what matters, and it seems to me that the current foundations are all low-grade concrete and not reinforced at all with rebar.
One thing I'd add to the to the list is have someone to talk to. When building large systems it's always important to have the big picture in mind, and being able to get another person's input on what you're doing can often be invaluable. I've saved hours upon hours of time from stupid mistakes just by spending thirty seconds to get another perspective.
It doesn't seem that it was necessarily stinginess of neglect, but rather stinginess imposed by their situation. Like the article said, it took hours to create a new shard, downtime that Foursquare definitely did not want.
What exactly is the rate like for transferring data across MongoDB instances on EBS? Was the overhead of going across EBS volumes the major factor in the length of the downtime?
The 60%/40% sharding distribution doesn't seem too bad in the big picture; are there any plans to be evening that out?
The duration of the downtime seems to have been dependent on not just disk throughput, but also network and CPU throughput. Eliot did mention that a large portion of the downtime was partly caused by the slowness of EBS. Making a rough estimate, I think the downtime would probably be about 2/3 of how long it was if it had been on an SSD RAID. However, then you run into the issue of having to maintain your own servers; which, judging by the fact that they are using EC2 and EBS so heavily, Foursquare does not have any desire whatsoever to manage their own infrastructure.