ashearer

This assumes that the HSR would operate at full theoretical capacity, which wouldn't be true of all potential lines. If a locality is deciding between HSR and Hyperloop, it would be better to compare costs based on projected passenger load. That measure would presumably benefit Hyperloop on lower-activity lines, where HSR would have difficulty recouping costs, and HSR on higher-activity lines.

We're addressing this problem at Care Thread (http://www.carethread.com), where we integrate patient-centered messaging and EMR data to ensure that everyone stays in the loop.

Existing electronic medical records systems are at their best for long-term documentation, and fall short on keeping care providers abreast of ever-changing plans across shift transitions. Pagers and phones, which doctors and nurses use instead for real-time communication, fare even worse. The information is simply invisible to the next person who takes over.

We've had terrific, sustained adoption where Care Thread's system is deployed, and are working to measure the effect on patient outcomes. Some study results are pending (from Partners / Brigham & Women's Hospital in Boston, where researchers put iPads in the hands of patients and used our mobile messaging system to help keep care providers aligned with each other and with patients).

A major aspect is miscommunication. According to the Joint Commission: "Ineffective hand-off communication is recognized as a critical patient safety problem in health care; in fact, an estimated 80% of serious medical errors involve miscommunication between caregivers during the transfer of patients." [1]

I co-founded Care Thread [2] to help address the communication problems I saw working in hospitals. Electronic medical records systems weren't designed around real-time communication, and mobile secure messaging systems tend to replicate the original alpha pager workflow, without directing the improved technology at improving collaboration.

The project involves removing points of communication friction, keeping track of the patient's care team, injecting relevant EMR data into the communications stream and pushing it to the right care team members as soon as it's available, and keeping everything visible to the interested parties.

If you're interested in something like this, I'd love to talk. Please contact me through my profile or on our web site.

[1] http://www.jointcommission.org/assets/1/6/tst_hoc_persp_08_1... [2] http://www.carethread.com

There's a crucial distinction to be made. Ignoring unknown properties is a defined part of the CSS spec, so implementing it that way is just being correct. Postel's Law leads to trouble when "being liberal" means unilaterally extending the spec in ill-defined and ultimately incompatible ways. Example: autocorrecting "awesome-new-value" to its closest known match "alternative-old-value".

Adding to your list: "they released the newest OS for my old iPhone for free in order to slow it down and make me buy a new iPhone".

It's not limited to Apple, but the pattern is the same: it goes immediately from conjecture to absolute certainty of malicious intent (but they didn't count on the speaker being clever enough to see through the scam). And if disproved, it's just the exception that proves the rule, which the speaker then has to loudly reassert.

We need a new rule: Never ascribe to malice what's adequately explained by others having different priorities than you.

Well-thought-out fork that proves optionals can work in Go's language model, with clear benefits for runtime safety. Congratulations to the author!

I took it to mean that with Node, some functions have a traditional return value, like functions in most common languages. But if there's even the possibility that they may indirectly invoke an async function, they need to have a different signature using callbacks or promises. For example, here's a simple function:

  function isValidFoo(val) {
      ...return boolean
  }

This function is synchronous now, but its contract needs to change if it internally calls something async (say, it's updated to check a value from a cache, which may trigger a DB lookup). The new signature has to add a callback parameter and drop the return value, or return a promise. Then its callers have to change how they invoke the function, and if they were previously synchronous their signatures have to change as well. Every synchronous function up the call stack needs to care about this internal change.

To avoid a ripple effect, all functions have to be designed to be asynchronous from the beginning, but this increases program complexity significantly. It means avoiding built-in language features such as direct return values, and often means substituting async library functions for built-in looping constructs.

Other languages including Go aren't like that. You don't need to wrap a simple return value in a promise or callback just because retrieving it might someday involve I/O. Execution of the thread/goroutine simply resumes whenever the value is ready, and the function returns normally. In those languages, Node's distinction between sync and async is artificial and unnecessary.

(Warning: also not a lawyer.) Despite the framing as a "one-off tool" instead of a mass-market "product", iOS itself is definitely an Apple product, and the FBI is requesting a custom version of it. Apple then has to sign it as an iOS update, so that from the perspective of the phone it's trusted as a new version of iOS.

The fact that the FBI requires Apple to vouch for it as an iOS product makes the "not-a-product" argument harder to maintain. (Also weakening the argument: the applicability of nearly the same software to replace the OS on an unlimited number of iPhones that the FBI may introduce later, or if leaked, a large number of iPhones in the wild.)

I think it's important to separate its positive effects on the community from the merits of its UI. To me, SourceForge epitomized the "it's complicated for us, so it should be complicated for you" school of UI design. The owners didn't appear to do much to improve that over time, instead treating the site much like toxic code that no one dares to modify for fear of breaking something. No doubt that was a huge factor in their decline, which fed into the user-hostile cash grab tactics. However, the fact that it existed at all when no alternatives were available was great. I wish the new owners the best of luck in turning the site around.

"Anti-pattern" sounds close enough, as shorthand, when "bug" might cause readers to file the article incorrectly. The author is warning others that a normally-unremarkable JavaScript idiom causes suboptimal performance in this particular case, and it's likely not to present itself as a bug (having no visible symptoms on smaller pages and no impact on functionality otherwise). Putting aside whether suboptimal performance should always be classified as a bug, there are many ways to accidentally break equality comparisons (despite a full understanding of them), and now my eyes are primed to catch one more pitfall. I appreciate when that happens for reason that doesn't involve hard experience.

Go and Python deployment aren't quite that equivalent. I've seen build and deployment problems over multiple years with widely-used Python libraries including Python-MySQLdb and Python Imaging Library (PIL). The Go equivalents for such essential libraries are typically in pure Go, so it's much easier to avoid C build and link errors when choosing project dependencies. The prevalence of pure-Go libraries is likely to remain high in the long term even as Go's base of libraries expands.

I see parallels to PHP initially taking off for web development instead of Python via mod_python. Paradoxically, it was so much fun to build your own web framework in Python that everyone did, so none got enough traction.

By the time Django finally broke through, PHP (with a good-enough mini-framework baked in) already dominated Python for web development, and the fragmentation of the Python world was arguably a contributing factor. Others adopted a third language because of a single mindshare-heavy framework, Rails.

I prefer ES6/ES2015 (currently via Babel, and considering TypeScript). The let keyword and arrow functions in particular make it a much more pleasant language to work with than plain JS. It's now competitive with CoffeeScript, but with more coherent and predictable parsing rules.

I agree with the approach indicated by the title ("caution required"), but the tone of the article veers toward being alarmist.

Takedown articles tend to share similar characteristics. Many are on a mission that emphasizes the negatives of their subject, even minor ones, while overlooking the positives and handwaving away problems with the alternatives. They set the bar higher for the subject by finding issues that it shares equally with its alternatives, and presenting them as damning evidence against it (since users may expect it to be better and be disappointed). The specific alternative that's held up as superior to the subject varies from point to point--no one alternative is actually superior in all points. They may even acknowledge that many of their arguments are weak, but make up for it in volume.

In its favor compared to such articles, this one does make some attempts to be evenhanded, but they're overpowered by the dramatic language used to make the opposing points. (For example, the brief acknowledgement that point 1 is the "weakest argument against WebSockets" is surrounded by phrases like "wreak havoc", "weird stuff will definitely happen", "rogue proxies will break you").

This article puts itself squarely in the category of "the case against".

A more balanced article might discuss:

1. The situations where you might want to avoid WebSockets (no HTTPS, IE 8 & 9 compatibility, a server platform without good support, or where they don't provide actual usability benefits).

2. Pitfalls that both long-polling and WebSockets share (you have to handle reconnections and synchronize state, be mindful of the open connections when reconfiguring a load balancer, account for server load, and use a server platform with good support for long connections).

3. Differences that can be viewed just as reasonably in WebSockets' favor, which the article counts as negatives. Example 1: Resynchronizing state after a network interruption is necessary with both long-polling and WebSockets, though the article notes it as a WebSockets disadvantage. The reconnection process is explicit with WebSockets, but some long-polling libraries make it very easy to ignore these events, leaving the client out of sync. Example 2: WebSockets aren't limited to 6 connections, unlike long-polling, so you won't get a silent connectivity roadblock on some tabs when the user has several of them open.

4. Advantages unique to WebSockets: responsiveness is improved due to not needing to send HTTP headers with every request and response, and the underlying TCP connection is already warmed up; load balancing and redundancy may be simplified by no longer requiring a session affinity mechanism (because the connection itself preserves short-term state, which can be re-established by the client transparently to the user in the rarer event of reconnection); less overhead than long-polling; a whole class of problems resulting from cookies as the sole mechanism of state transfer is avoided; the same protocol can be implemented simply and efficiently by native mobile apps.

Possible reason: to distinguish the list from an "or" list.

Reading the standard library is a huge help in learning to write Go well. It's a high-quality compendium of best practices.

Both hypotheses in this case are plausible. Beyond that, it would be great to have the tools to numerically calculate a psychological phenomenon such as the placebo effect the way a physicist calculates the energy of a particle. But we're very far from having them, and in the meantime, I don't know of a practical alternative to RCTs that would expand our knowledge at least as much. (I think we can both agree that over-reliance on significance testing is a problem, though not one limited to RCTs.)

The discussion is about how to test the placebo effect (which corresponds to your example's "theory A"), so the proposed alternative to RCT would have to include the process of first deducing the effect size. For this problem, how would you realistically do that without referring to past experimental results? There are so many unknowns, including psychology. The 1955 paper was itself a survey of experimental results.

I expect it to be much easier to come up with a statistical prediction for the get-better-anyway effect (regression to the mean), with more specificity than x>0. It would be needed regardless, in order to exclude the null hypothesis.

Say theory A (the placebo effect theory) predicts a 25% improvement, because it's been measured in the past with that result. Then there's also theory B (the get-better-anyway theory, or null hypothesis), which wasn't measured initially but in recent studies shows a similar 25% improvement.

I don't understand how more studies testing theory A and getting 25%, while excluding theory B from testing, can show that A should be preferred over B. The rationale that A has been tested more thoroughly and therefore has a smaller confidence interval sounds circular.

How does that address the get-better-anyway effect, without a group to measure it?

I meant the original 1955 publication of “The Powerful Placebo” that put the idea of the “placebo effect” into the public consciousness. (Use of the term really takes off starting then [1].)

That article's more recent (2010) link supports its conclusion, which wouldn't need to be stated unless it contrasted with what it calls “pharmacological folklore” from the original publication, which the author says he “took literally” for many decades after.

The point being that the 1955 version of the idea is currently much more widely known than modern no-treatment comparisons, and most people don't realize that its research basis is so flimsy.

[1] https://books.google.com/ngrams/graph?content=placebo+effect...

So the research that established the placebo effect—an effect that’s well-known, and widely regarded as an illustration of the importance of control groups in research—itself had no control group? That’s incredible.

If you integrate the crappy thing everyone's using with something less crappy, gradually displacing the crappiest parts, then the world has gotten better. Maybe not fast by Silicon Valley standards, but still an improvement.

As for health records, perhaps the expectation of a neat database decomposition—data perfectionism—is itself the enemy. For just about any given application, such complete information isn't necessary to improve on the status quo.

From my perspective, too much effort is spent creating One More Standard to unlock data nirvana, and not enough on breaking down the organizational walls and misaligned incentives that brought us to this point.

The post author alluded to this, in mentioning the EHR cash incentives that tragically lacked viable interoperability requirements, and so just served to lock in the major vendors' existing systems.

Summary: a short intro to reducing DB lock contention with "SELECT ... FOR UPDATE OF x FOR SHARE OF y", and the upcoming Postgres 9.5's "SELECT ... SKIP LOCKED".

It's a decent heads up about these features, but there are some editing errors and an odd emphasis on multiple CPUs, while DB row locks are the limiting factor in the examples. I'm having trouble interpreting the final paragraph. ("Keep in mind: If you only got a single CPU, concurrency will be a problem. Therefore is essential to do things in a way that many CPUs can do their share of work at the very same time.")

For iOS, there's a hidden dimmed mode, which is great for nighttime. It's not obvious how to get to it, to say the least. Directions at http://lifehacker.com/toggle-your-iphones-brightness-with-a-...

This is very true--trying to create a single outcomes-based ideal of what's fair is both difficult and subject to the same strategizing that caused gerrymandering in the first place. Instead of choosing what "fair" is and maximizing it, the proposal takes a different approach: by using an extremely simple geometric rule, the algorithm seeks to avoid choices that would be susceptible to influence for political gain. Those are the choices that tend to result in gerrymandering, which by locking down power is expressly designed to be the opposite of fair to future voters. So instead of the difficult task of directly maximizing fairness, the proposal aims to minimize a great source of unfairness. I'd be curious to know how well it would work in practice.

...and for anything larger than a small fixed-size array (like the example), you'd avoid data-copying overhead by passing a slice, which is a bounds-checked bundle of pointer and length.

That's true of some decisions, but not all. It's a divide-and-conquer strategy. In some situations, ranking would be easier than the decision itself otherwise would be. In others, the method wouldn't necessarily be easier, but it would be more accurate. For weighty decisions, accuracy trumps ease.

Nice work! The article benchmarks a > 20X speedup for AES-128-GCM, for performance described in the text as "on par" with OpenSSL. It would be helpful for reference to have an OpenSSL column added to the benchmark table.

One reason may be that Postgres doesn't have built-in operators for updating an individual field within a JSON doc. (The workarounds are complex and/or inefficient.)