skysight-inc/HackerNews huggingface dataset:
Sometimes weakened strains of the flu can end up giving you symptoms of the actual flu. It costs money to get the flu shot. The needle could be infected. You could get in a car accident on the way to the clinic. You could pick up the flu from a previous visitor to the clinic.

All of which is to say, TANSTAAFL.
Must be like the broccoli thing - some folks like it, some can't stand it. I can't stand coffee, and have absolutely no idea what people are talking about when they rave over its flavor.
Spike and Rea discuss the big issues
The Hit List (mac app, single developer so I haven't needed fancy things yet. Actually I did have my testers use Lighthouse for a while, but that was too cumbersome for me.)
What I find distressing about this example is that it's being used to support the idea of writing such systems in C++, where such errors are very easy to make; rather than in a language where you can protect against it in the type system.
absolutely. I bet Vegas is taking bets on it
Yup. I'm a graduate of the "mac labs".
"Took the plunge"? More like waded to the shallow end.
Its a common addict's behavior - rationalization.
Don't get me wrong; I'm glad your drug intake is down to manageable levels where you can function . The only way I managed that is going cold turkey.
I sat up to see who the hell was being an idiot and when I saw him I was just like "oh, Scoble". I guess people kind of expect it from him these days.
Wicked! Well....

Some sort of "roadmap" feature. The ability to manually mark a revision as being relevant to the ticket (like the auto feature you have). When a revision (or revisions) are related to a ticket display a prominent, separate, link(s) to them in the ticket. Due date and importance for tickets. Highlight the importance in the list view (e.g. urgent = red etc.). When a revision is "tagged" in the mercurial repository create a link to a "changelog" that lists fixed issues for that tag name (if it exists: version or milestone - or even a separate tagging system).

That's just a few off the top of my head. (sorry; I always seem to be dissing you guys :( not intentional)
Sorry to re-open this so late, but I thought about this discussion today as I was reading a paper which had a typo in the subscript specifying a distribution: http://dx.doi.org/10.1103/PhysRevLett.103.138101 (it never ceases to amaze me that people get away with publishing glaring errors like that one).

In eq. (4), they specify P_{k|v}[x|v]. Thankfully, here, it's easy to spot the typo, because k is discrete and x is continuous. But this made me realize that my objection to these subscripts is really akin to wanting to write DRY, self-commenting code.

The fundamental information is already there in the equation. Adding extra subscripts is then like adding unnecessary comments to code - if they're right, they just add redundancy but maybe help the uninitiated; but if they're wrong, they're infinitely worse than having put nothing at all (someone who didn't know that PRL lets all kinds of crap fly could really be thrown for a loop figuring out how equ. 4 is possible).

> Pedagogically I've found that saying "X takes on the value x" confuses a LOT of undergraduates.

I haven't taught this to anyone, so your experience is more valuable than mine here. Nonetheless - I noticed in my undergraduate statistics class that programmers (i.e. people who are accustomed to obtuse rules regarding case sensitivity) had no problem with this, while other people accustomed to playing fast and loose with notation (economists and physicists in particular) were somewhat put off.
If memory serves me, yearly flu vaccines are formulated based on predictions about which strains will be most common for a given season. Is it really a surprise that they guess wrong sometimes? Easy, 100%-accurate predictions don't really happen much in science outside of Physics 101 homework.

Also, is influenza vaccination really recommended for healthy adults, anyway? My impression was always that it was only worthwhile for people who would be at high risk from the disease.

As for the whole "it's all misguided groupthink, only a few brave people are sacrificing career success to speak truth to power" thing, I kinda have to roll my eyes. Maybe the author of the article is right, but most of the time when I've heard people say things like that, they don't actually understand the ideas they're criticizing and are being reflexively contrarian because that's a good way to make applause lights blink in the heads of their audience. Really, if most specialists in a field agree on something it's probably because it's true, and if you really think you've seen the light where everyone else has gone astray your point will be stronger if it stands on its own without the rah-rah anti-establishment social signalling.
In the last swine flu vaccination (30 years ago), hundreds of Americans died from receiving the vaccine. You can find the sixty minutes episode on this online.

Vaccines usually come with other toxic substances that will be injected in your body.

The same research articles that show influenza vaccines aren't useful also indicate that the risk of severe side effects (such as death) are low. Those must be weighed against the benefits, which in the case of the influenza vaccine, seem to be mild or unproven.
>For example, commonly used examples of less effective call to action are “click here”, “submit”, “read more,” etc.

>Instead, you should use more descriptive and persuasive text that tells your visitors where they are going and why they should go there.

Interesting how on their homepage the most noticeable buttons say "Learn More" and "Get Started Now", both generic and not very descriptive.
It looks like it was a nice talk, but unfortunately it failed to address the reason why there is so little reliable science when it comes to software development.

The reason is, of course, that we have yet to come up with a reliable, meaningful metric for programmer productivity, one that would apply to the lone ruby on rails coder as well as to the enterprise java cog-in-the-great-machine or the ThoughtWorks elite agile programmer in a 6-people iterative team.

Until there is a meaningful way to compare the productivity of different software methodologies, it is pointless to berate the lack of scientific studies comparing the productivity of these methodologies.

As a final nail in that coffin, I don't think anyone can claim that Google is lacking in the "let's measure everything" department, with their reputation for intensive A/B testing of every single pixel change. And yet Google has yet to resolve this problem... which would tend to indicate that this is a real, non-trivial problem, not just a case of people not trying hard enough.
I'm a little biased since it's my startup, but we use Zen (http://agilezen.com/). We only have a team of two, but some of our customers have sizable teams using it.
People believe what their government tells them. In this case it is the CDC, recommending an influenza vaccine for everyone older than 6 months, and particularly for certain at risk groups. The CDC is representing the science as demonstrating a high effectiveness, which as these review articles point out, is not the case.

This is not just a problem of CDC marketing, though. As the Atlantic article points out, the scientists that are publishing research showing a lack of effectiveness in vaccines are not getting equal treatment among their peers who still believe them to effective.
At the risk of mentioning something I did myself, here is a simple, STM implementation in C: http://github.com/skaphan/stmmap . It's at a very different design point from others like Clojure's in that it is just a simple API, not a language mechanism, it is for concurrency at the process level, not threads, adds no extra "goo" between the program and its data, but has a fairly coarse grain size for conflict detection (page size). Who knows, it might be appropriate for some situations...
sifter is amazing and it has one of the best blogs I have read.
Test Track Pro
Um hm, and in a vacuum or some alternate reality where your favorite paradigm won out, that would be practical for companies.
But at the moment, the ecosystem consists of millions of C++ beasts, with a few exotic animals grazing among them. All the herd owners will be hiring cowboys for what they have; most of the cowboys will know how to handle C++.
I'm on your side somewhat; pity the poor big company that needs not just a few good developers, but hundreds, and has to write a position description that has a chance of netting those hundreds.
I think bankers are an early example of a knowledge-worker occupation where the amount of economic value produced by one's labor scales in relation to deployed capital, rather than in relation to hours worked, and therefore they command stupidly high salaries because (when performing properly) they should.

Bad news for anyone who enjoys income equality: I think they're not the last occupation that will see this decoupling of returns from hours worked (which, since everyone has a roughly similar cap at some fraction of 24 in the day, is the ultimate thing keeping wages in the relatively narrow band people associate with "normal" folks).

Many people take it as an article of faith that there is a 10x difference in productivity between the best programmers and (take your pick) either average programmers or the worst programmer in their organization. Almost no programmers, however, are compensated at 10x the compensation of the average or lowest performing member of their organization.

This is a sign of economic inefficiency. The market abhors economic inefficiency. And the market generally gets what it wants.

I mentally consider myself in the middle of two engineers at the day job. One of them is literally incapable of programming Java, and earns to the yen what I do because our seniorities are equivalent. The other is the 10x engineer -- 10x in relation to me, easily. He is older but his premium on my wage is, hmm, 15%? 25%? Something like that.

One thing I have learned recently is that my skillset generates more value than my salary quite literally while I am sleeping. That number is going to keep increasing at a rate faster than my salary, and at some point the essential conflict is going to deprive my company of my services. Honestly, that won't be the world's biggest loss to them. What should worry them is when math becomes inescapable to the 10x engineer, too.
Hot Celebrity Topic: Kambakkht Ishq wins 'Best Locations' award
Hulu blocks geographic regions _and_ nationality, too!

pokesfun :)
His message is great; his story amazing. But consider: for a living he gives inspirational speeches. What odds he accidentally wound up in a situation that gives him a lifetime of stories to tell?
Yerba mate is really good. Unfortunately it's not commonly accessible. I wouldn't be surprised though, considering that Argentina, Uruguay, Paraguay and Chile are the only countries where it's common.
Breaking News: Vast majority of humans only care about themselves.

Does that make them jackasses? Not sure.
I'm of the opinion that the reason there is no quantitative metric for programmers is the same reason there is no quantitative metric for writers, artists or musicians.
Startup School 2009: Divvyshot
Internet Speeds and Costs Around the World
Dataflow languages lend themselves to graphical programming paradigms much more readily than imperative approaches as well. e.g. This company's http://www.futurepointsystems.com/?page=products XEE product is a pretty slick dataflow XML ETL tool.
I just don't get it why age matters.

If something is stable and good enough, then why should it be reinvented, instead of improved?
One solution to this is that you can measure similar projects. "The Mythical Man-Month" is based on this idea. If you compare large projects to large projects (or a large project to itself with different methods, different number of people, etc), you get a decently reliable, if imperfect, metric which can give good results.

Similarly, compare elite six-man teams to other elite six man teams (not very reliable, but interesting if results are extreme) or to themselves on other projects, possibly with slightly different methodologies.

Yes, it's difficult. It would be nice if we had some simple means of measuring productivity, but much of programming is very artlike -- we're not solving identical problems, and we may solve them in very different ways, and a lot of the resulting quality depends on the taste of the viewer. We're not going to get a really excellent, predictable way to measure quality.

Waiting until we do means no research, which is awfully fatalistic.
Still, there's a lot of room between "no evidence" and "double-blind clinical trials", and reason to believe that statements about software development can profitably be moved towards the latter.

I would take Code Complete as a good example. There are sections on methodology that run along the lines of "Company A tried this method and got a B% reduction in defects compared to the first version of the product. Company X also used it and only got a Y% improvement compared to the previous year, but that's still worth using." Studies don't have to be totally conclusive in order to provide meaningful back-up to anecdotal reports and subjective experience.

In other words, the perfect is the enemy of the good, and good evidentiary metrics may be achievable even if perfect ones aren't.
At work we use Microsoft Team Foundation Server...
See the Microsoft vs TomTom lawsuit:
http://en.wikipedia.org/wiki/Microsoft_v._TomTom
Ethics are not ridiculous. Randomized placebo controlled double-blinded studies have the potential to cause harm to humans.

A fantastic post on the issue can be found here http://www.sciencebasedmedicine.org/?p=467
To be honest he wasn't the only one asking stupid/long-winded/time-wasting questions. Some people kinda need to learn how to prepare and succinctly make a point.
Paul's talk was refreshing, but is he always like that? He kinda seemed high.

I'll definitely know I'm successful when I can just stand on stage and ramble about my life in front of 800 people. How awesome!
Homepage is a very bad example of conversion optimization, there are so many possible next things to explore for a visitor. If it were a landing page, I would have been very concerned. On homepage, having descriptive buttons can be suboptimal in some cases.
Well, I take his point, and it is worth making to the [paraphrasing] 'SUV driving graying hipsters who are, despite good intentions, going to Hefty (trash bag) 2/3 of their "haul" '. People shouldn't base their choices upon gross misunderstandings of e.g. economy and efficiency.

On the other hand, a couple of hours in an orchard is a highlight of my year. And I suspect it is for a good many kids, as well. For my part, I can't take the kind of crowd he describes; fortunately, I have a much more "basic", but peaceful and beautiful, orchard in the area. One run by local folks with help from their friends during harvest season.

Time there I find well worth the expense -- not just of the picking, but the driving, my time, etc. And it's not like I'm incurring that expense throughout the year for all my food. For many the kids I see, I can't help thinking it's an invaluable lesson to actually source their own food, for once; to see where it comes from and to be a part, even if a small one, of providing for themselves.

The choice he describes cuts both ways. People can get a bit hung up on apple varieties. On the other hand, the varieties presently commercially available represent a small fraction of what once found itself distributed throughout the country; so many of those "heritage" varieties have been squeezed out by large scale, commercial production. And so much of that commercial production ends up with flavor that is a pale shadow of what you can find in other varieties not harvested to optimize hardiness under mechanical manipulation, transportation, and storage.

At my local orchard, Golden Delicious is my preference. They have other varieties, but the trees, terroir, and whatever else make the Golden Delicious a terrific choice. Good eating, but I find they hold up admirably in a pie, as well. Variety need not create a tyranny (of choice). For me, the best thing in the neighborhood is Golden Delicious. And I find ways to work with that, rather than worrying about all that I might be missing.
The Geek DefenseDo criminals with Asperger's syndrome deserve special treatment?
The C for RFC in short - What's the point ?

I really don't understand what problem this draft solves, and the draft doesn't seem to explain it coherently.

It effectively describes just another layer on top of TCP that implements its own addressing, loosely follows HTTP syntax and utilizes TLS for security. The application still needs to implement yet another layer to deal with the data carried by this protocol. So instead of using (TLS + application protocol) combo, the app needs to use (TLS + WS + application protocol).

So what's the point in making this protocol a standard ?

-- PS --

Historically, creating an instant messenger chat client as a Web application has required an abuse of HTTP to poll the
server for updates while sending upstream notifications as distinct HTTP calls.

Perhaps that's how they do it at Google, but historically applications like httptunnel simply opened exactly two persistent HTTP connections - one with a very long POST and the other one with a very long GET - and used them to send data up and down respectively.
New CNN.com Goes Live: What Do You Think?
I don't see anyone buying an iMac instead of an HDTV. The resolution on the iMac is way overkill for 10 ft viewing, but is great for computing. If Apple were to release a 40" computer (with 1080p resolution), it would more likely be branded Apple TV (or something new) than iMac.
It may help to stop thinking of it being used specifically for recursion - there can be tail calls between several functions. In cases where TCO is applicable, function A calls B, and B calls C, but since B isn't doing anything to the result, C can return directly to A. This is transitive - D, E, F, ... could all return to A as well, in constant space. It "goto"s the next function (but with arguments), and returning and popping the results off the call stack is deferred.

Rather than going into fairly abstract examples* , TCO is useful because it allows more things to be expressed in terms of function calls, without having to worry about blowing the stack. While the discussion surrounding them can be a bit overly academic, they ultimately matter because they can help make code clearer. (Not always, but you can implement clearer looping mechanisms on top of them.) A tail call is like a de-fanged goto.

* Just one: Parsing by implementing a finite state machine in function calls. See Shriram Krishnamurthi's "The Swine Before Perl" (http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...).

While the stacktrace no longer records intermediate steps, (and thus loses info useful for debugging), language implementations can typically hook tail calls to save the information when a debugging flag is on. It's not as big a problem in practice as some people think.
I think your reflexive anti-reflexively contrarian reaction is blinding you to the point the author is trying to make. The politics surrounding questioning the flu shot, even within the medical research community, are such that Jackson et al were refused publication despite doing verifiably good scientific research.

From the Atlantic article (http://www.theatlantic.com/doc/200911/brownlee-h1n1):

“People told me, ‘No good can come of [asking] this,’” she says. “‘Potentially a lot of bad could happen’ for me professionally by raising any criticism that might dissuade people from getting vaccinated, because of course, ‘We know that vaccine works.’ This was the prevailing wisdom.”

Your career will be damaged if you question the efficacy of the flu shot, because it is current medical doctrine. This kind of thing has happened lots of times before, as the Atlantic article points out.

Really, if most specialists in a field agree on something it's probably because it's true

You're treading dangerously close to an argument from authority here. What surprises me about this is that I would guess from your writing that you've got enough experience under your belt to have realized that in every field, the average person is mediocre. This isn't some tautological nonsense; what I'm saying is that if you were told that "most programmers agree that X," your reaction would probably be "yeah, but most programmers are actually crap at their job, why would I listen to them?"

You'd be right in that case, and you'd be right if you replaced programmers with doctors in the above. That most doctors believe in the flu shot isn't a reflection of the flu shot's greatness so much as a reflection of their training to that effect. Coupled with strong political forces pushing current doctrine, you have a situation where scientific research is being systematically subverted.
Preview: Liverpool vs. Manchester United
in the case of file systems, 'improving' around the original design decisions is often impossible. take hfs+ for example: almost all the filesystem metadata is stored in a single b-tree called the catalog. doing almost anything with an hfs+ volume requires exclusive access to the catalog, which locks out all other callers for the duration of the file operation. the solution is to spread the metadata out to other parts of the disk, but that can't be done without breaking hfs+ compatibility.
I wrote my own at work, and it turned into a bigger project that integrated a lot of department workflow (parts, maintenance scheduling, metrics, etc.).

If I had known then what I know now, I would not have gotten involved.
We wrote our own issue tracker using our platform. Dogfood tastes good.

https://www.labkey.org/issues/home/Developer/issues/list.vie...
Good point.

I attended this talk, and it was easily one of the best talks at Stackoverflow (Devdays) Toronto, and got a very rousing response from the crowd.

To answer your concern, the question of "why" was actually one of the overall points of his discussion. Wilson would enthusiastically agree with you that there aren't very good metrics out there not only for programmer productivity, but a number of other things that you'd want to measure in software. At the beginning of the talk he contrasted the software sciences against other, older disciplines just to show how incredibly nascent it is.

His most damning point of the current state of affairs was that there is a lot of metrics/methodology pseudoscience being spouted by people and businesses in our profession, and that we often eat it up unchallenged. His optimistic counter-point was that things are turning around and measurement, experimentation and skepticism are spreading, and as you point out, for some companies like Google, it's yielding a lot of gains, even if they haven't cracked any universal code of productivity (does anyone actually believe we ever will? This will always be a moving target).

The most frequent phrase used by Wilson in his talk was "wouldn't that be a useful thing to know?" (with respect to the result of some experiment that would show a verifiable result). Essentially, his talk was a rallying cry to attempt to stir the audience into becoming more critical about their own methods and to boost their skepticism of the things they're told about methodology.
Play Framework 1.0 OSX Installer Package
The CDC does not advertise high effectiveness. This seems to be a strawman you are knocking down. If you administer a fairly ineffective vaccine, you will still save hundreds of lives. With a very effective vaccine, you'd save even more.
It's annoying that they don't mention whether it's theoretically possible for this treatment to apply to other diseases and/or impairments.
It was a brilliant talk, easily worth the cost of driving out from Michigan for DevDays.