taion

Interestingly enough, in Python, the minimal, official style guide of PEP 8 actively suggests using properties (the equivalent of the JS getter/setter syntax) for simple things: https://www.python.org/dev/peps/pep-0008/#designing-for-inhe... (See the section that starts with "For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods.")

I think in practice this ends up being mostly a function of what's idiomatic in the ecosystem. The most common JS style guide recommends _against_ using getters and setters, so it would be surprising for something in JS to do so. The most common Python style guide recommends _for_ using properties, so the syntactical near-equivalent ends up being something "expected".

The thing that strikes me as weird about Cypress is that, while the DX is quite nice, their core claim of being an end-to-end testing experience is, for the most part, not true. You can see that in how most events are simulated instead of native. As such, we're not really simulating user experience, and in fact the accuracy of testing doesn't seem to be meaningfully better than what's available in Karma.

DX is fantastic, of course, but I'd feel quite uncomfortable in committing to a commercial offering that I thought was being less than fully honest in what they were offering, just as a matter of trust.

It really is a great test runner on its own merits, though.

Per the piece, it's actually "2.5c a kilometre", or $0.025, so the EV driver is still paying quite a bit less.

Less than you'd think – it comes up in serializing/deserializing data, somewhat, because JNI has a fair bit of overhead, but this isn't really like Rust's "unsafe". To have fast Java, you really need the JIT to be happy, and that's not a safe bet if you're doing random things with Unsafe.

There are still a number of players in the HFT space that use JVM languages.

I think as with any space, if you really zoom into the details, you see a lot of diversity. You're obviously right in that people who are still hitting the CPU can't compete with people that do everything on FPGA, but it seems like there's still plenty of money to be made by people who are just a bit less fast than that.

I've heard people argue that they prefer being in that sort of space, too, as it gives them a bit more room to compete on their own alphas, and tends to be a bit less winner-take-all.

There's a major historically-contingent component to this, too. The Island ECN, later absorbed into NASDAQ's ECN, originally ran its matching engine as one of these low-latency Java processes, writing everything using explicit object pools to avoid doing any GC on the critical path, as this was long before Zing was around.

This was a pretty reasonable choice at the time, as this was long before C++11 was around, and Java just offered a lot of advantages for developer ergonomics.

A natural consequence of this is that a number of HFT shops that were seeded by ex-ISLD devs just fell into using something like the ISLD tech stack, which at least at first involved a lot of GC-free Java.

I sorta doubt that any of those social psych studies replicated, though.

pip-compile added support for pinning hashes in 1.8.0 (in 2016) and support for non-editable URL dependencies in 3.7.0 (in May).

This was such an unexpectedly powerful piece of writing. Thanks for sharing this.

There's currently a TC39 stage 1 proposal to add something very like the Python syntax to JavaScript: https://github.com/tc39/proposal-slice-notation.

There's an active Babel feature request to implement exactly that proposal: https://github.com/babel/proposals/issues/41. As such, it'd definitely make a lot of sense to implement this!

What's the benefit of using Exodus over just using the official-ish static builds of FFmpeg? https://johnvansickle.com/ffmpeg/

This works just fine on AWS Lambda. The `ffmpeg` binary there weighs in at 46 MB. Unless you need something not bundled with that build, it seems like this is sufficient and is easier to set up.

It's funny that he would take the famously lazy and impatient Leonardo as a role model here.

Unless he thinks The Last Supper is supposed to be like that.

This is a fairly poorly-informed piece, especially in light of the recent NY Times piece on construction costs in the New York area: https://www.nytimes.com/2017/12/28/nyregion/new-york-subway-...

Alon Levy, who was the source for many of the initial investigations into high costs here, argues quite convincingly that, at the current projected price tag, Gateway is not a justifiable project: https://pedestrianobservations.com/2015/11/13/when-theres-no...

The real problem here is that ARC, Gateway, &c. all have unjustifiably huge multi-billion-dollar price tags. We only have this problem in the first place because of the absurd construction costs in New York.

Additionally, the writer does not appear to have reached out to any independent transit people. Penn Station is actually less busy than, say, Châtelet-les-Halles in Paris, which has many, many fewer tracks. The biggest reason that it doesn't work well is just organizational – Penn Station would be able to handle its current capacity just fine if it did things that were standard elsewhere like through-running.

Lastly, neither Moynihan Station nor many of the Penn Station revamp ideas are well-regarded in transit circles. As noted, Moynihan Station makes people walk an extra long block. The original Penn Station, meanwhile, was not particularly well-regarded for things like pedestrian flow. It had a beautiful waiting room and some great architecture, but it's generally been regarded as being mediocre functionally, especially compared to Grand Central, which is both beautiful and has very good pedestrian flow.

We didn’t hit a hard limit. Slack explicitly disabled new user signups for us because they thought we were getting too big.

Is the "two weeks" of time in the Dota environment, or two weeks of training time running in parallel as with A3C or something?

For those, like me, who find the writing style somewhat annoying, this is the part of the article that relates directly to the title:

> Imagine the situation Florence Nightingale confronted in the Crimea. Everyone knew that, in a war, soldiers get shot. Everyone knew that people who are shot tend to die. What they didn't know was that the vast majority of deaths in the Crimean War weren't caused by wounds at all -- they were caused by diseases like cholera and typhus. Thus military leaders didn't implement the basic sanitary precautions in field hospitals and military barracks that would save lives by stopping the spread of disease.

> Florence Nightingale saw the problem, but she needed her own ammunition. So she counted the dead, collected the data, and displayed it in a polar area diagram.

> It was a credible, clear and compelling display of the causes of death. And suddenly the problem was no longer too abstract to ignore. It was fixable.

> That is how a woman -- a nurse -- took on the top brass of the British military and won.

It wasn't; the link was malformed.

Clicking through to "very" is pretty amusing too.

I strongly recommend checking out TensorFlow-Slim if you're looking for a lightweight abstraction for using TensorFlow – at least the layers, anyway.

The API looks similar to something like Keras or Lasagne, but the layers are just simple operations on tensors, so it integrates seamlessly with vanilla TensorFlow in a way that something like TF-Keras won't.

At the same time, though, the layers are the same foundation that TF-Keras look like they'll use, so you get much of the same expressive power, but without sacrificing flexibility.

This code appears to be using the legacy Babel decorators transform in order to use so-called "annotations".

This is a really bad idea. There is no decorator transform that matches the current draft specification. There's only the legacy transform that matches an old, outdated version of the decorator spec.

In general it's not a good idea to do this sort of thing – you're pretending to use an ES7 feature, but actually you're not. You're using what's effectively a bespoke version of the language with no necessary resemblance to what's going to become the spec.

Exactly! Enabling unstable language features like decorators by default is the opposite of a novice-friendly decision, as is enabling by default features that require pulling in e.g. the Regenerator runtime.

The author of the post doesn't seem to understand that many of the transforms supported by Babel touch on proposals that are actually at various stages of being experimental or unstable, which actively should not be enabled by default for the sanity of users who don't know better.

Opting a novice user by default into a language feature that might well change is not a good thing! Otherwise we end up with something dumb like the legacy decorator transform, where people unknowing code against proposals that are liable to change under them.

Babel-5-stage-0-ese is not ES.next!

The author posits that "Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc."

There's a very good reason that Babel doesn't, and we should actually be fairly grateful that the Babel team have made the considered decision not to include such things.

First off, neither async/await nor decorators are actually part of ES2015. They're both TC39 proposals, at various stages of completion: https://github.com/tc39/ecma262. Very justifiably, neither Babel 5 nor Babel 6 transpiled those out-of-the-box by default; for novice programmers, using language features that are unstable proposals that have not finalized is quite dangerous – what are you going to do if those proposals change, as the decorators proposal actually has changed?

More specifically, there are meaningful issues with both of those transforms if used without further thought. Babel's stock transpilation of async/await brings in an entire runtime component in the form of the Regenerator runtime, and additionally requires that Promises exist in the JavaScript environment, which requires polyfills in the general case.

For decorators, the proposal itself is still in flux. The current version of the proposal (https://github.com/wycats/javascript-decorators/blob/master/...) is actually quite different from the old proposal, which was the one that was implemented in Babel 5. Additionally, the current proposal isn't even fully nailed down yet. Certainly one should not expect Babel to implement a language feature for which there isn't even yet a stable proposal!

This isn't to say that Babel 6 is perfect, but the specific counterexamples the author of this post brings up are extremely weak, and if anything demonstrate very good choices on the part of the maintainers of Babel.

npm has a feature that's broadly equivalent to virtualenvs, in that each directory is implicitly a virtualenv, and you use the packages installed in a given directory (or its ancestors). This is a bit less powerful than virtualenvs since it's tied to the directory structure, but in practice it ends up being really convenient for most use cases. Along those lines, there are also some cool affordances for managing dependencies – you can do e.g. "npm install --save <package>" to install a package and update the equivalent of setup.py with the new package, and it will automatically set that up with a semver range that matches the current stable release of that package.

That's actually not what I'm talking about, though, since ultimately those are just DX conveniences. The big difference is that, by default, npm installs dependencies in a nested rather than a flat manner. This means that you can install "library A" and "library B", which both depend on "library C", without worrying about potential incompatibilities between the required versions of "library C". This isn't possible in Python; one consequence is that you see a bunch of libraries that vendor their own small subsets of six to avoid having potential dependency issues – you don't get this in the Node ecosystem, because you can just pull in that dependency and not worry about potential version conflicts.

All of this adds up to a much nicer experience when developing libraries.

I split my time pretty evenly between the Python and Node ecosystems, and I've found that Python dependency management is extremely poor compared to Node dependency management.

For example, Python's lack of support for nested dependencies means that it can be extremely difficult to use small "utility" libraries like six as subdependencies without running into potential problems from conflicting version requirements from other dependencies.

Additionally, Python's management of different types of dependencies is very weak, specifically with regard to setup.py and requirements.txt. npm has (among other things) very nice explicit concepts of development dependencies and regular dependencies, in addition to application shrink-wraps, which gives library maintainers very easy ways to split out different kinds of dependencies, or lock down all dependencies and subdependencies, using the same set of tools.

While I can say that the current version of pip, especially in conjunction with pip-tools, is significantly better than earlier iterations of Python packaging, I strongly hold that Python packaging is substantially worse than at least one other prominent example.

Benjamin Kabak is almost certainly well aware of the bloated costs of the MTA.

Nobody seriously disagrees that MTA costs are ridiculous, but it's a messy dilemma; most likely even at current costs, things like the Second Avenue Subway and the Utica Avenue Subway are well worth building.

You're also glossing over the point he makes that our prioritization is inane and quite possibly insane – programs like building nicer ferries for LGA or building an AirTrain that's slower than current options do almost nothing to help things, and is much more a matter of local and regional politics than MTA inefficiency per se.

That's really fascinating – I looked up the reference, and your recollection is on point. C. californici was in fact driven extinct, possibly due to fumigation of the last few condors.

Better to call this the nth intentional pest elimination, then.

The community consensus is that deprecation warnings don't strictly require major version bumps.

That said, the React Router 2.x release does also include a few actual breaking changes to APIs that were only used by integrations - which is to say that 2.x is a minor release for end users, but is a major release from the perspective of maintainers of packages like react-router-relay or redux-simple-router.

What do you find annoying about React Router?

If anything, working on react-router-relay has only made me appreciate React Router's design more.

A lot of the changes in 2.x are specifically from lessons we've learned in building react-router-relay and other integrations, but they're closer to refactorings and code reorganization than to wholesale rewrites.

Your code example is actually wrong. The intended API use looks like:

  import { Router, browserHistory } from 'react-router';

  const router = <Router history={browserHistory} />;

One perk is that you can then navigate using the singleton if you want, e.g. with

  browserHistory.push('/foo');

The scroll behavior stuff is definitely messy; I haven't had time to clean it up. The nice thing about OSS, though, is that the rest of you are all free to contribute changes.

Our top priority after we get 2.0 solidly released is to revamp the documentation and provide a better tutorial. The work that Dan Abramov has done with introducing Redux is a positive example to all of us.

As for the change to the case with using multiple named child components - we made that change because React upstream made it no longer valid to pass objects into this.props.children. It wasn't that we decided one way or the other that it was nicer to spread named children into top-level props; the old way that we did it (which for this case was arguably cleaner) was literally no longer supported by React, so we had no choice.