HN user
Something very unsettling about a government mandating ISPs block/sniff/track your internet traffic on behalf of the film industry.
If only the government was equally motivated to remedy injustices incurred by those who aren't already filthy rich.
Can someone confirm that this actually works? Seems like a pretty weak attempt at a block if true. I think the real problem is them sniffing your traffic.
I wish iOS allowed you to change DNS for celluar networks.
Are you torrenting from your iPhone?
On the surface, the rax-redux implementation appears to be a lot simpler. For example, react-redux's connect spans all these files https://github.com/reactjs/react-redux/tree/75658dab18f7fe3e... and includes "connectAdvanced": https://github.com/reactjs/react-redux/blob/75658dab18f7fe3e...
While the rax-redux equivalent seems to be contained in a single file:
https://github.com/alibaba/rax/blob/07e20908e4e17b182873db09...
The simpler implementation might indicate that the rax developers are trimming overcomplicated bloat, or culling features that don't align with specific needs of Alibaba. Or maybe they're just removing code they don't yet understand the necessity for. It's not immediately clear what tradeoffs each are making, but having rax audit what's really necessary could be a good thing for everyone.
For data that's mostly to do with the the API provided by the particular mongodb driver, than mongodb itself. Mongo stores and transmits BSON, not JSON. Most mongo drivers expose an API that serialises your data to BSON for writes and wraps the BSON data with a JSON-like interface for reads.
Doing it this way requires overriding every single built-in rule that uses the property you're trying to override… including states like :hover, :before, :disabled, :disabled and :hover, etc which can be easy to miss.
I've had some success with simple find & replace preprocessor but this gets complicated if the CSS uses colour manipulation functions e.g. color: color(var(--color-base) tint(50%)), then you're basically going to be re-implementing their whole stylesheet again.
Also, good luck making sure everything still works if and when the components are updated.
Ideally, you alter theme variables in one place, rather than finding and overriding them everywhere they're applied.
These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language.
There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build time: http://cssnext.io, yet as far as I can tell, all of these component frameworks impose some other nonstandard compiles-to-CSS language or one of many possible APIs for writing inline styles.
Inline styles seem to be a trend at the moment but I can only assume the people driving this movement haven't had the experience of working with 3rd party components (which you may or may not have the source for) and needing to alter something the designers didn't expose and simply having no simple options because the damn inline style can't be overridden even by !important. Now you've got to fork whole the f'ing component, possibly multiple, each of which potentially coming with yet another different compiles-to-CSS toolchain all because you wanted to add a single line of CSS.
Admittedly, antd doesn't use inline styles si the above doesn't apply here, but having to maintain a custom builder for antd in order to change some fonts and a few colors was a frustrating experience. Not sure what a good solution is until CSS variables get more browser adoption, but it'd be great if we could collectively start standardizing on standards.
Compiled JavaScript?
technical debt and not wanting to break people's workflows
no, it just installs everything it can into the top level node_modules. npm@2 would do this to a degree as well, it was just less sophisticated about it.
what you described is npm@2's behaviour. npm@3 will flatten dependencies as much as possible
My experience with melatonin:
If I take the normal dose of >3mg, I'll experience incredible irritability the following day. I become sensitive to sound and anything that isn't entirely perfect. Things make me feel unreasonably furious. This is bad. These days I always microdose melatonin.
If I don't fall asleep with the first tiredness crash that happens 20-30 minutes after taking melatonin, I find myself restless and unable to sleep for another 4 or 5 hours. The more melatonin I take, the more intense the initial crash will be, but the harder it is to sleep if I miss that crash.
Did this as a course on Coursera with a group of friends. Highly recommended.
"…they care more about monetizing their users than their users privacy or interest."
Sadly this is true for all but a handful of companies.
"Lambda is not well documented"
AWS in general is not well documented. Well-written drivel mostly.
My guess is that there's little to no feedback between documentation writers & developers actually trying to use that documentation to achieve real outcomes. Same could be said about many of the AWS UIs.
Why do many language home pages not show a single sample of the language?
broken vs different
Ubisoft appears to have some institutional problems. Their other recent Tom Clancy title, Rainbow Six Siege, is hands-down one of the most rewarding & intense shooters I've ever played, however it too is yet to realise its full potential due to amateur-hour quality issues and ongoing troubles with hackers.
Same issue in Singapore. The Netflix library available here doesn't even contain the latest season of House of Cards – and it's a bloody Netflix production.
I would love to pay someone for timely content, but now that Netflix is blocking vpn access there is literally nobody to pay. It's complete madness.
npm has namespaces. https://docs.npmjs.com/misc/scope
Yeah this is a long way off and lots of things need to happen before node can even consider this… 1. TC39 needs to get async functions to stage 4: https://github.com/tc39/ecma262/blob/master/README.md 2. V8 needs to implement: https://github.com/nodejs/promises/issues/4 3. Node then needs to use this updated V8, and to be able to use this reliably, this V8 will need to reach an LTS release: https://github.com/nodejs/LTS/blob/master/schedule.png 4. Also Node API needs to become promises-compatible, which is god-knows how long away: https://github.com/nodejs/promises
what (generic) code is `super` syntactic sugar for?
super.propertyOnSuper ~= this.__proto__.propertyOnSuper
super() in constructor ~= ParentConstructor.call(this)
https://github.com/isaacs/inherits/blob/3af5a10c6b51f9e99d9f...
Yet another language on HN that doesn't show a single code snippet on the linked page.
Link should probably go here http://www.taodyne.com/tutorial-2.0.html#/language
If you'd used leveldb from the beginning you wouldn't have this problem as it will happily work on the server and in the browser https://www.npmjs.com/package/level-js
Anyone looking for the zsh equivalent of the `bind -P | grep` command, it's just `bindkey`.
One downside of passing data as `this` that isn't mentioned is you can't use the concise function syntax `=>`. If we ever get thin arrows this problem will go away.
The V8 4.2 update adds support for Native Classes in JavaScript: https://github.com/iojs/io.js/issues/1393
Significant & controversial.
The argument here is that when things go sour you can restore a running process more quickly. Of course things should actually work and issues should be fixed, nobody is suggesting that.
I've been working on a similar tool that works with (some) real browsers. Pipe JS in, get console logs out. Simple.
Compile-time checks can't make guarantees about 3rd party code or user input.
The real benefit of one language everywhere is reduced penalty for context switching and flexibility with your architecture.
The promise of "code reuse" is very alluring but reusing application code rarely happens in reality. However, reuse of patterns and libraries is very common – solve a generic problem once and you don't have to research how to achieve the equivalent in another ecosystem. Just grab the exact same library, browserify the thing and you're done (ideally).
"One language everywhere" grants you lots of flexibility – where your code executes is no longer locked in stone – you can shift responsibilities from the server to client & vice-versa without significant overhead. No need to port to a different language which perhaps lacks similar paradigms or tooling. Doors are opened to optimisations and architectural changes that would not have even been a consideration otherwise.
To get the benefits of "one language everywhere" doesn't necessarily mean "use JavaScript" but it's a safe decision to choose the lowest common denominator; JavaScript is not going out of fashion any time soon, it runs on nearly every platform and has an ecosystem that's competitive in a wide gamut of problems. An investment in vanilla JS will pay out in long term, while any investment in Framework-X or compile-to-js Y or AltJS-Z is high risk and usually only pays out for the 18 months or so while said tool is in vogue.
JS may not be the best choice, but it's a smart choice.