yanowitz

Purchasing Power Parity is meant to capture elements like cheaper costs of construction. It gives a real sense of the gap between Indonesia (4th most populous country, with China and India neck-and-neck, followed quite a bit lower by the U.S.) and the Netherlands. Corruption may be a factor too, but you can’t squeeze blood from a stone.

GDP per capita is more than 4x in Netherlands (on a PPP basis). On a straight per capita basis, it’s even higher. See, e.g., https://tradingeconomics.com/indonesia/gdp-per-capita

This is a great summary. I think it's valuable to say that learning how to map your problem domain onto instances of categories like Monoid is useful because it immediately makes your problem embarassingly parallel, because you can parallelize the addition process (just making sure to preserve overall ordering of operations). I.e., map/reduce. And if it's a commutative monoid, you don't even have to sweat the ordering.

Interesting article--I'd love to see one just on GC.

I just downloaded the latest node.js sources and v8 still has a call to CollectAllAvailableGarbage in a loop of 2-7 passes. It does this if a much cheaper mark-and-sweep fails. Under production loads, that would occasionally happen. This led to pause-the-world-gc of 3600+ms with v8, which was terrible for our p99 latency.

The fix still feels weird -- we just commented out the fallback strategy and saw much tighter response time variance with no increased memory footprint (RSS).

I never submitted a patch though because although it was successful for our workload, I wasn't sure it was generally appropriate (exposed as a runtime flag) and I left the job before I could do a better job of running it all down.

Well, part of the problem is a lack of consistent prosecution, so it's not a surprise that there have been little in the way of murder charges or convictions.

We've seen video of an officer shooting someone and then going back to his squad car and appearing to remove a gun from his bag and plant it on the victim. Carrying around a "burner" gun (in case you might need it) seems premeditated to me, but IANAL.

This obituary was quite good (and for fans of Halt and Catch Fire, seasone one, evocative) including bits like this about the Grid laptop: NASA also used one as a backup navigational device in its space shuttle program. One was aboard the Challenger on the morning of Jan. 28, 1986, when a rocket-booster failure destroyed the craft shortly after liftoff from Cape Canaveral in Florida. The Compass, which had been attached to a dashboard with Velcro, was recovered from the debris and found to be still working.

For the less-RF-literate (such as myself), can you please elaborate on the several reasons?

I'm listening to this blast from my past: https://archive.org/download/Kool_DJ_Red_Alert_-_Radio_Mix_9...

Even has Scott La Rock up front...

For Heroku, which has a read-only filesystem for /etc, we did this: https://gist.github.com/yanowitz/8329d8b27d8294ca7027f504326...

The documentation is reasonably comprehensive: https://smile.amazon.com/gp/help/customer/display.html/ref=h...

ObOriginalTanenbaumTorvaldsConflictLink: <https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...

Linus' personality is remarkably intact, 24 years later.

More background: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...

I think this is a great artistic piece. It made me think about lucky I am to have English as a first language, as it's also the language of CS and thus, computer language keywords. For those learning programming who don't know English, I assume this isn't too far removed from their experience.

This is a great article (I haven't written a compiler in years but was still able to follow along) that can easily suck up an evening of descending his explanatory links. That's a good thing.

Favorite new trivia bit:

"C++ has an even more extreme version of this problem since type/variable disambiguation could require arbitrary amounts of template instantiation, and therefore just parsing C++ is technically undecidable (!!)"

A web page devoted to the usability of an object whose main reason for existence was its uber-nerd signaling via poor UX. There's something both amazingly abstruse and disarmingly charming about the whole endeavor.

It's two detectors, each of which has two tunnels at right angles to each other (and generate an interference pattern when a gravity wave distorts the tunnels length).

Humans evolved meeting their survival needs collectively (in hunter-gatherer times). Language development aided this cooperative mode of production. So too would criticism and praise.

I've found reductionist social Darwinism lacks explanatory for these phenomena.

The arguments the author makes around technological constraints precluding language development seem wrong in a few ways, but I'm not that familiar with the field, so the column may be short handing more sophisticated analysis. Specifically:

1. Most (all?) written languages are linear -- they are processed sequentially by the brain and then deeper meanings are extracted (particularly wrt metaphors and allegory, but also viz. complex sentence structure). Emoji are not unique on this count.

2. Paper and pen (the surfer example) also have technological constraints. It's a "2D" surface, width of line, etc.

3. The input difficulties of emoji today seems temporary. For example, a gesture interface to get you to the correct emoji.

4. What about non-alphabetic written languages?

These seem like obvious first-order responses to the article, so I suspect I'm missing something (besides my first cup of coffee).

I would recommend the following: Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go.

Retrospective meetings (where the topic is how the work is getting done, not what is getting done) are a standard and useful way to do this (assuming the results lead to actionable change). The frequency of the retros themselves should be part of your discussion (pick something to start with ("every 2 weeks") and periodically decide if that's the right cadence). Length of sprints, styles of coding, amount of pairing, etc. -- all of these are variable based on the experience of the team and the problem being tackled. Pick reasonable defaults to start with and regularly ask yourselves if those defaults make sense given your experiences.

I could say more, but the above is the base minimum I've found for success across different teams, different problems, different companies. Cheers.

I thought the point was that this provides another channel (etiology?) for materialist explanations of "Eastern" medicine.

I'm not taking a position on that question, as I haven't studied it sufficiently (though acupuncture, for example, seems more compelling that reiki).

The more expensive subscription displays the pub glass. I don't think sky minds if you want to pay for the more expensive sub and move it elsewhere.

Because satellite is one-way, the cheapest option for sky is to pay for enforcers. There must be quite a spread between commercial and home licenses.

Fun paper. I conclude that the warning worked: goto is used carefully and with restraint.

I suspect you could generalize this to many similar language construct and tool warnings/anti-patterns.

Except csh. It's always harmful.

I think we should automate recovery for error conditions where possible and change business processes to be automatable where not. If neither can be done for some pressing reason, then the failure condition should be defined as an expected condition that needs dedicated staff to recover. But that cost should be surfaced and tracked and the first and second order approaches should be automation above all.

Of course, teams need the authority to solve the pain if they also have the responsibility for it.

I agree with these points.

I'm a big fan of developers being on call for their application. It puts the pain where it belongs--with those building the systems (modulo lower-level errors--such as power failures or network outages--those should go to the appropriate place).

However, that pain should only rest with the development team if they also have the freedom and will to spend time dealing with it. They will have spend time (either a constant tax, or more likely, with occasional sprints) to reduce operational pain. They are in the best position to reason about the tradeoffs and pragmatically reason about priorities.

In my experience, this produces the highest code quality and the highest team morale. I also like the rule -- if you're paged during the night, sleep in the next day.

I love the app but I've found the data feed can sometimes be spotty (maybe this is just in Chicago)? For example, it's snowing outside right now and Dark Sky shows no precipitation for the next hour. Yahoo Weather correctly showed it was snowing (and showed it was likely to continue for several hours, so I parked in the garage).

It would be useful to have some insight into the underlying data, it's freshness, and an easy way to report inaccuracy (I've sent support emails but they've gone unanswered -- I assume the support load is enormous for a small team).

It's only the previous month of unused data from that month's allotment (and that data gets used first), but that's better than nothing, I guess.

Assuming 15GB plan:

Month 1 (15, 0 avail): Use 10 GB, roll forward 5

Month 2 (15, 5 avail): Use 8, roll 7, lose the previously rolled 5

Month 3 (15, 7 avail): Use 20, roll nothing (lose the unused 2)

Month 4 (15, 0 avail), etc. etc.

So this saves you if you have one outlier month, but it's still not as good as rolling what I've nominally paid for.

It is. While not optimal, I just go to google, search for the URL and click on th top link. With referrer set to google, most newspapers show you their content.

Bookmarklets, referer spoofing and other improvements left as exercise for the reader.

I feel like this advertorial for Candid Camera, appearing in the New York Times, is a meta-prank on the reader.

Seems like the show relies on the kindness of strangers and that still exists, even in a smartphone world.

Interesting article that buried the lede.

The part about the criticism of the positivity ratio was particularly interesting because a co-author wrote the brilliant parody of post-modernism published in one of its seminal journals, Social Text (http://en.m.wikipedia.org/wiki/Sokal_affair).

A critique by Sokal is prima facie intriguing.

I need to go read the original article but the Wikipedia summary is fascinating (http://en.m.wikipedia.org/wiki/Critical_positivity_ratio) in specific, Fredrickson and Losada appear to have chosen functional parameters that yield good results, not ones based on evidence.

I think the argument is that bot-nets can appear to be 1000s of legitimate users and you can use this to undermine competitors.