skysight-inc/HackerNews huggingface dataset:
>Yes, Oberon was one of them, used by the complete IT department at ETHZ, including normal employees. Were they more than 100, I don't know, never counted them.

Well, I think this falls in the "researchers and hard core fans" of my range.
There’s no reason the guy with the cannabis plot shouldn’t be outvoted by all the people that will benefit from the new building. The issue there is some combination of a collective action problem and what amounts to corruption.

The answer, as mentioned, is go to a higher level of government where there are even more people to outvote Mr. “But Muh Views”.

In the case of CA there’s seven million people in the Bay Area and 33 million in the rest of the state that would benefit from continued growth there and don’t care at all about shaded backyards in Palo Alto. That sounds like a referendum waiting to happen to me.
It seems to have a natural equilibrium. The issue is that it's too popular and valuable, there are people putting too much effort in, so a casual investor won't get into it. If it were less popular and valuable, it wouldn't be worth putting so much effort in, so people wouln't, making it more appealing to a casual investor. The feedback loop seems to be stable.
How do you handle people who've had their systems hacked and address books stolen though? Is it just a blanket FU?
"As soon as you know what your business is going to be, make sure your technology stack is flexible."

As a form of devil's advocacy - Why? Just improving the codebase under the hood won't bring any new users in the initial market segment where your product-market fit is proven. Focusing on marketing, will...
This article reminds me of the adage about ops people which goes, "You know you're doing a great job in operations when nobody thinks you do anything."

The problem with taking the experience that "future proofing" is never worth it, is that it suffers from survival bias, which is to say that when you did it and it made the future event a non-event, it didn't even register on your brain. If you practice more mindful engineering you can teach yourself to recognize the things you did in the past that made what you are doing today easy or even possible.

That is not to say that all future proofing is good, especially if it ties up the group in knots trying to predict all possible futures. That is where the mantra of keeping it simple really helps. Simplicity is the greatest protection against the future precisely because it has the smallest disruption surface. The simpler a process or product is, the more difficult it is to find a change that would invalidate its effectiveness.
Same. I have tried multiple times.
My mantra is - never assume features, but always assume change.

As others have mentioned - it's orders of magnitude easier to add a layer of abstraction to a simple system as requirements evolve, than it is to remove an unneeded one down the line. The latter is often impossible.
Needs more server-less to cope with the load :)
Not necessarily. Depends on circumstances. Putting a book on a school or college curriculum is a form of enforced reading dictated however by people whose opinions you presumably respect.
FWIW, maybe I'm living in a bubble but I don't seem to run across unnecessary "future proofing" very often. In fact, I see the opposite as a problem much, much more frequently. I work in a boring corporate job though, not a hip startup, so nobody at any of my jobs are trying to be the next Google or Facebook - that's probably the main difference.

>We need to hire a team of developers and build in-house software, despite wordpress and shopify being a much easier alternative, because when our customer base grows to 100 times what it is now, it will make our lives easier.

I think this comes from "not invented here syndrome" rather than the assumption you'll need to support hundreds of orders a minute in the future. Also job security.
But many drummers are infamous animals.
I use a specific Lambda function that acts like a sink. It receives messages via SNS from a myriad of other services and its only job is to push these messages to the main applications API. There the actual inserts and updates are done. The main API lives on Heroku.
Why not have your frontend proxy running somewhere else, pointing both to Wix and to the evil ad network? Wix will still think it's the host, so it should be fine.
Meson seems increasingly popular. Never tried it myself though.
Thanks. We changed the URL to that from https://differentimpulse.com/ten-trillion-degree-quasar-asto... and banned the latter.
This looks really nice. I have been working on something that might perhaps be of interest to you.

https://github.com/canselcik/libremarkable

I would love it if someone built a terminal emulator using it. All the pieces needed to achieve that is already in place.
In most applications, replacing HTTP with WebSockets is a big mistake.

HTTP is cachable, can be proxied, inspected via curl and examined in Chrome's devtools. More importantly, typical app communication with the server has request-response shape. If you're communicating over a WebSockets connection, that doesn't change the natural shape of your queries. So you have to correlate requests and responses and multiplex over the connection - essentially reimplementing HTTP, but poorly!

If you have the choice, request-response communication is preferrable because it's always going to be simpler than bidirectional communication. If server push is an important part of your user experience, implement it as an addition to your HTTP routes and as a completely separate pathway (and consider using SSE instead of WebSockets).
Sure I vote. “Pesky” younger people are welcome to vote for repealing Prop 13 if that’s what they want. I won’t, at least not if it has the effects described here.
Letter to the German Press, by Jay Rosen
Herman Roebbers talked about this [1] at a conference earlier this year, together with the fact that the displays and what drives them have to be interconnected and low power.

[1] https://ulpc.nl/wp-content/uploads/2018/03/Herman-Roebbers.p...
I can see how you would come to that (incorrect) conclusion. No sense of entitlement to free lunches, plush offices, massages, and other perks that are common in SV. In return, no expectation of being tied to the office or working crazy hours.

We pay everyone exceptionally well - way higher than they would normally make in their home countries. Even at low-mid Bay Area levels. Just not near the top end of Bay Area salaries. There's no huge disparity in the pay for anyone. See my comment history for who is hiring posts with salaries included.

The founders live in SV and earn less than most of the workers actually. I think longer term we're going to just move away - we have no ties here at this point and we're just throwing money down the drain.
Ha! Honestly, I'm actually not sure if you're meaning it's you who's having to fix things, even though they set it up, or if you mean one of them is always fixing it.
Here's a corollary: http://slatestarcodex.com/2013/04/11/read-history-of-philoso...

tl;dr read the works of thinkers who were wrong in the past, in order to expand your search space to find out what you're wrong about in the present.
Please note that this is not a temperature measurement in the sense of a thermodynamic temperature. It's not made clear in the article, but the ten trillion degrees is a "brightness temperature". This is a convention in radio astronomy where you take a measured specific intensity (power / unit area / unit solid angle / frequency) and compute the temperature a blackbody would need to have to emit the same specific intensity. When the brightness temperatures are this high, it indicates that the emission process is non-thermal (in this case, synchrotron emission from relativistic electrons).

See equation 2.32 of: https://www.cv.nrao.edu/~sransom/web/Ch2.html
Carbon nanotubes are cool, but i will believe space elevators possible once someone shows me a carbon nanotube rope i can climb with. I'd settle for a bike or motorcycle chain. A nanotube-based shoelace would be worth a noble prize or two.
He was apparently patient zero for the list's spread through hollywood and other creative industry twitter.

Beyond that, no idea - I'm a bystander who happened to've read a few articles giving various points of view on this and have pieced together what I hope is an accurate 10,000ft view, but YMMV definitely applies.
> If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible.

Thats the crux of the problem. Different people have different definitions of flexible. How are you defining it?
I'm always trying to quantify things because when I walk around SF, the homeless problem seems insanely bad but my pro-SF friends say things like "homeless has actually been stable or slightly improving for years and you are being unfair to SF's complex situation". But on the other had, I was walking around the Embarcadero last week at a very fancy conference hotel and the situation on the street was deplorable.

I'm not disagreeing with your comment, just adding on to it. You are 100% right that homelessness is a complex issue with lots of causes. But I think it's also fair to say at the end of the day that SF is completely failing at fixing the problem - both for the safety of the homeless people and for the safety of other citizens. It's a public health crisis in my opinion when you look at the basic numbers.

Here's some numbers:

San Francisco population: 884,363 (2017/Wikipedia)

San Francisco unsheltered population (conservative): 6,600 (7,499 SF self-reported homeless count * 88.2% HUD estimated unsheltered rate)

Unsheltered population rate (conservative): ~0.75% of residents (my calculation) - nearly 1 in 100!

Compare that with London, another city also experiencing a homelessness epidemic due to explosively rising housing costs:

London population: 8,825,000 (2017/Wikipedia)

London unsheltered population: 1,137 (homeless.org.uk)

Unsheltered rate: ~0.01% of residents (my calculation)

So obviously homelessness rates in SF are absurdly high. In fact, there are more unsheltered homeless people in SF than the entire country of England:

San Francisco unsheltered population: 6,600 (2017)

England unsheltered population: 4,751 (2017)

I'm not saying they are equivalent situations, but somehow a country with a population greater than the state of California manages to have fewer homeless people than one relatively tiny city in California.

And people say things like NYC has a much higher homeless population of 76,501, but according to HUD, only 5.1% of NYC homeless are unsheltered. In SF, the unsheltered rate according to HUD is almost 90% - nearly the worst in the country. That means NYC actually has fewer unshelted people than SF on the streets despite a much larger population.

I'm not saying these numbers are perfect, but it gives us an idea of the scale of the problem. Politicians may or may not be smart, but at the end of the day they are doing a terrible job of fixing this issue in a meaningful way. Someone needs to step up and treat this like the public health crisis that it is, even if that means bringing in more federal resources or changing the strategy significantly.
The cars would travel at up to 200kph and arrive at the space station eight days after departure from Earth.

These early cable experiments are important, but someone should also be working on the composing an 8 day Elevator Muzak score that won't drive you insane.
I would rather disagree with these practices. Some of them are subjective and some will likely be outdated soon.

> Each function should do only one thing. The problem with one/a few functions running your entire app, is that when you scale you end up scaling your entire application.

Sure, but is that a problem in general? Same thing can be said about a monolith vs microservices, and there is always a trade-off. A function with a larger code-base makes the code easier to navigate; may be easier to deploy. First reason about / compare cold-start times before making the decision to break the function.

> Functions don’t call other functions

Is the cost of calling the other function negligible (e.g. the functions are called rarely)? If yes, feel free to do it.

> Use as few libraries in your functions as possible (preferably zero)

Security risk is another discussion, not related to serverless. Worry instead about the cold-start time. If it's short enough for your use case - do use libraries. Should be no problem for Go, Node is usually OK. Java - native compilation is slowly approaching.

> Avoid using connection based services e.g. RDBMS

If adding another library is not a problem in your case, then why not? It's not too difficult to create a pool with a single connection. As for security, there are some new options like AWS Aurora IAM authentication. No VPC needed.
As an example, DHTML Lemmings - https://www.elizium.nu/scripts/lemmings/
Violent action is already mediated by compute devices: police and soldiers are dispatched by computer command to capture or kill people they don't know and have never seen before. Rarely do human actors have any discretion in the field, so the fact that a human constitutes "the tip of the spear" wouldn't seem to matter much.
CORS has a performance cost, and that is shitty. But CORS has many benefits.

Fine grain control over the options response, in certain contexts, is great. Being able to immediately ship 3rd party functionality and know that it will work is great. A unified API for your JS, your 3rd party JS, and all the API consumers out there, is also great. For me it's a security and speed-of-development thing; not a performance-while-travelling thing. This means it's great for full-featured apps used by businesses in Canada, the US, Japan, and most of Europe.

If a connection is seconds slow; and you have a project that needs to be a complex SPA, the right way of handling slow connections is to fallback to a simple server side pure HTML / CSS bare bones website that sets aggressive caches with crazy secure HTTP headers and uses encrypted cookies to handle session between a separate web server that communicates through the main backend API on the session's behalf. If you use Ember, this is trivial with Fastboot[0] if you've followed best practices, and not much work if you haven't.

Also, how you architect your API and frontend matters greatly. The reason I like following JSON API[1] is that EmberData-like data model mappers / persistence libraries mean that I can supply multitudes more information about the world in one response if I want to. Sure I have multiplexed HTTP2 set up, but if A needs B and B needs C1 through C20 and they each need their own D it's nice to be able to just send that all down and skip all the requests; and of course it's always possible to design the API to be optionally told to fetch only a subset and everything works easily for out of the box because these frontend libraries can rely on the standard.

The only thing I wish came with CORS was a small DSL, so I could do things like whitelist a pattern. But I get it; someone would probably screw up at some point and for what? It's kinda nice that a technology defaulted to secure for once.

[0] https://www.ember-fastboot.com/docs/user-guide

[1] I use v1.1 because I like to stay ahead wherever I can.

http://jsonapi.org/format/upcoming/
This assumes good signal. If you have poor mobile signal then you can easily get 5-10 seconds latency.
I had a deep lamellar graft 15 years ago, for keratoconus, and it wasn't painful, just uncomfortable for a while. The followup appointments also involved some discomfort, but were fine.

As with any transplant, I'd say it might be helpful to prepare yourself for the fact you'll have someone else's body part (I'll be celebrating my cornea's centenary before that long).

And don't have huge expectations for the result -- I can't comfortably read a book with my operated eye, though no doubt the vision would be acceptable with contacts. They're such a pain and the vision in my unoperated eye is still good enough that it's better to rely mostly on that eye than bother with them.

I still won't drive in the dark, won't play contact sports and my eyes get tired fairly easily, but overall it was a big win and I'd go for it again in a heartbeat. Good luck!
So one year the defense budget.

Seems possible
> So I guess the new membrane they put into the 2018 MacBook Pros didn’t solve the problem?

My money is that OP’s laptop isn’t the new edition.
By the way, Prop 13 was a response to what was happening as a result of property values dramatically rising. It was an effect, not the cause, so repealing it isn’t likely to reverse the increase in property values.
> Rarely do human actors have any discretion in the field

That seems like a very strong claim.
The experiment sounds great. But should this work and a real cable to orbit is built, what happens when the cable snaps!? Can such a structure be made failsafe?
Here is another PR, more recent, based on Babel 7 and its TS support: https://github.com/facebook/create-react-app/pull/4837

I'm waiting it to be merged to switch to TS.
Music? The first four days will be safety announcements. The last four will be debates as to who is responsable for cleaning up all the vomit. A week of near-zero-g in a room with 30 people will not be fun.
How much Balzac or Dostoyevsky would you estimate you've understood through osmosis without reading them?
While I was not suggesting doing to this particular model I would imagine a good chunk of them end up in a landfill.
"A company that can eat one marshmallow now should never wait to get two marshmallows." This is simply false.
He mentions DynamoDB for the data layer instead of regular RDBMS. I have tried to use DynamoDB several times but have been disappointed with it. I am not saying traditional RDBMSs solve the problem that DynamoDB has, but even DynamoDB is a poor fit for systems with rapidly changing load patterns. Some things that have been big pain points while using DynamoDB:

- It has autoscaling built in now but even that leads a lot to be desired, autoscaling is slow and your lambda functions will error out for significant amount of time(I have seen it happen upto 5 minutes) for 5X spikes until it scales up the IOPS. This fills up the queues quite fast and can lead to patterns where your spike increases because of failure retries. You can control this somewhat by limiting lambda invocations though.
- Limited number of scale downs allowed.
- Scale down doesn't completely reduce the throughput limits. I have seen situations where the write load went to 0 on certain times but scale down reduced it to something like 400 IOPS which can be a huge cost drain.

I am still looking for a DB which has done this well. Essentially what I want is compute layer separated from the storage layer in the database well enough so that both can be scaled independently and the compute layer can react to quick changes in load patterns. Does anyone here have any recommendations?
Dostoevsky's The Gambler was written to get him out of something like that. I couldn't find a good web page with the story, but https://books.google.com/books?id=heVDCgAAQBAJ&amp;amp;amp;a... has the basics.

The story is better than that, though. He was working on one of his great novels as a serial (Crime and Punishment, I think), so he had to keep writing that during the day. But he had to produce another novel at the same time in order not to lose his future royalties to this publishing contract, which he had signed to pay off his own gambling debts. He was in despair, but a clever friend found the star pupil at the local shorthand academy and Dostoevsky dictated The Gambler to her in the evenings while she got it down in shorthand (a new technology at the time) and later transcribed it. They only had a few weeks, and finished it at the last minute, but the publisher had cunningly closed his office that day. He was no match for Anna, however, who took the manuscript to the nearest police station and got a receipt, rescuing Dostoevsky's career. Then he married her.
The story I told is the story as I understand it, from reading a smattering of articles from various viewpoints. I suspect many people have largely heard the story from a giant game of telephone on twitter, and as such details and nuance have been lost and distorted.

Note that when I describe what I think the argument somebody's making is, that doesn't mean I endorse the argument, merely that I'm trying to explain what the argument is.

I'm not taking a position on "fault", all things considered.
It was a ridiculous example to show that you can have a curated discussion forum that doesn't lead to an echo chamber. I took it to an absurd length to make it quite obvious that it was what it was and chose a topic light enough so that there's no need to actually debate the merit of the issue raised by the example. Basically whether or not Jet Grind Radio is the best Dreamcast game is a dumb point to argue, but we can agree that a forum that enforced that opinion would just create an echo chamber of people who really like that game. And that that's bad curation.

Essentially, agreeing with the guy I responded to that an echo chamber requires silencing dissenting opinions without any hope of discussion.

I wasn't passing judgment on whether or not HackerNews is or is not an echo chamber.
If you are interested in the boring part, so not how algorithms are invented and implemented, but more on the real world usage, I have written a blog "Commercial Cryptographic Key Management in 2018", where I am explaining a little bit about the hardware, people and processes behind it.
https://www.malgregator.com/key-management.html
> California schools are among the worst in the country.

true. OTOH, California makes up for it by tossing its own, homegrown student population under the bus. this state is perfectly happy to encourage and help SV companies import workers from every other school system on earth.