What would you guys like to see in an anonymous company wall? - <AUTHOR> https://whiteslip.com/about

<comment><USER2> >>Only people with a verified company email address can join your company network.

What's anonymous about that?

<comment><AUTHOR> Thanks for your question. The email address is only used to verify that you are with the company. We'll send you an invitation code once there is quorum, which you can use to sign up for an anonymous account. We don't link this account and your corporate email. We just mark your corporate email as taken, so no one else can sign up from the same email. The unfortunate side effect is that you would not be able to recover your password in case you forget it.

<comment><USER2> Try explaining that better. There's 3 possible people that could need an account depending on how you look at it.

1\. An email account to create a wall for an organization.

2\. A person in that organization so they can comment about their own organization.

3\. A random person that wants to comment on an organization.

I'm not sure which you're targeting.

<comment><AUTHOR> This is for case 2. It's a wall so that people within an organization can ask questions / share opinions with others from their organization. Thanks for the clarification.

</comment></comment></comment></comment><comment><AUTHOR> We are planning to open-source our code on github so we can get feedback on best practices.

</comment><comment><USER3> How will you prevent companies from being anonymously slandered?

<comment><AUTHOR> Yep, that's always an issue. There are a few things we are implementing in V1 to ensure a first line of defense against this:

1\. All posts are only visible within the company. So, it's not the average internet user posting on the company wall. 2\. Also, we are building community tools for voting, and marking a post as spam / slander.

We'd love to hear any other ideas that you may have.</comment></comment>


Why Is U.S. Health Care So Expensive? Some of the Reasons Turn Out to Be Myths - <AUTHOR> https://www.nytimes.com/2018/03/13/upshot/united-states-health-care-resembles-rest-of-world.html <comment><USER2> The meat of the article:

> There were two areas where the United States really was quite different:

> We pay substantially higher prices for medical services, including > hospitalization, doctors' visits and prescription drugs.

> And our complex payment system causes us to spend far more on administrative > costs.

> The United States also has a higher rate of poverty and more obesity than > any of the other countries, possible contributors to lower life expectancy > that may not be explained by differences in health care delivery systems.

Which is amusing, because people who argue against single-payer tend to argue that a) single-payer would lead to an inefficient government bureaucracy handling billing and administration, rather than the status quo of "efficient" hospitals and insurance companies; and b) private health insurance that requires everyone (or their employers) to pay for their own healthcare encourages more healthy living and more efficient pricing due to a more direct awareness of the costs.

<comment><USER3> It seems we in the United States have traded inefficiencies. Though our payments are higher, from the (little bit of) evidence I could gather from other single payer systems our wait times are far lower. This CNN opinion piece offers supporting evidence: [https://www.cnn.com/2017/09/25/opinions/single-payer- failure...](https://www.cnn.com/2017/09/25/opinions/single-payer-failure- opinion-atlas/index.html)

It's been my own experience as well. My dear friend in Australia who otherwise praises her system has had to wait over a year for some very important foot surgery. I was able to schedule a not-very-critical knee surgery in a matter of days, and I have the lowest-cost insurance plan my company offers.

Even while unemployed and on government insurance, my daughter was able to have open heart surgery when she was six months old. She waited a few weeks for an opening. I shudder to think how long she might have had to wait in Canada.

I can't see the article because my free views are up; Do they discuss what I view as the two most heavy flaws of United States healthcare? The increased regulations and the ability of doctors and hospitals to charge exorbitant prices due to insurance itself.

Regulations (in my observation) consistently bring heavy cost burdens to every industry they are applied to.

And insurance permits cost hiding: It doesn't trouble me terribly that a saline bag costs $70 if 3 million of those on my plan pay less than a penny each to pay for my saline. Doctors and hospitals have jacked prices sky high since insurance has become the norm. Whereas stories abound of cash payers getting their hospital bills slashed by significant margins. Only because they bypassed insurance.

<comment><USER4> My daughter was born a month premature, with her stomach outside of her belly still. She was in the ICU for a month in one of London's top hospital. There was no waiting (obviously), and this was all for free. I shudder to think of the costs that would have been in the US. I would say 100k easily and I would be bankrupt.

I've also lived in Australia and when I needed a eye operation, it wasn't even life threatening or dangerous (probably in 30 years it might have blinded me). I got surgery scheduled on the same day.

So really the wait all depends and of course it's on a triage system. I would say if your daughter needed her surgery in a socialised healthcare system it would have been triaged and made a priority.

<comment><USER5> This is my experience aswell. (in the dutch healthcare system).

i was also born prematurely, and as a result of that had to have some pretty major surgery done as a child. All of these surgeries where done rapidly aswell to keep the impact to a minimum.

Compared to a couple of months ago, where i needed to get some surgery done in my hand, in which i had to wait a couple of months. The issue with my hand was annoying and slightly painful at times, but nothing life threatening or "serious" compared to my premature birth surgeries.

Sure, the wait time sucks, but healthcare is (in my opinion) something collective that should be done by society as a group.

if i have to wait a couple of months to get my hand fixed. While at the same time it allows a premature child to get fixed up and get's a proper chance to live, so be it.

<comment><USER6> As much as I am opposed to the collectivist view points on society in the world, it seems this is one area where an individualist perspective doesn't work as well.

But the problem here, as you pointed out, is that to implement this idea in America, people would have be less selfish and more responsible for their own health. Neither of which is a core tenant of our modern society. 50-70 years ago is when we should have done this.

</comment></comment></comment></comment></comment><comment><USER7> There's something horribly wrong with a system in which the doctor cannot readily tell you how much a procedure will cost.

It's not like the doctor is building a new space rocket every time they do an appendectomy, or designing something completely new. It's a procedure that is done thousands of times per day. But still, no one can tell you how much it will cost.

There's layers and layers of waste in American healthcare. No one seems to really want to take point in fixing it. Frankly, it seems like a hopeless situation that will only get worse.

<comment><USER8> > There's something horribly wrong with a system in which the doctor cannot > readily tell you how much a procedure will cost.

There's a reason for this, and I've written about it in more detail on Hacker News before, but in short:

Medicare reimburses rates below-cost. About 7% below COGS, which means providers lose money _per-patient_ , even before they have to pay doctors, nurses, janitorial staff, building upkeep, etc.

To make up for this, providers inflate the rates they charge to private insurers. They don't expect private insurers to pay the full amount that they bill for, of course, but private insurers usually peg their final reimbursement agreements to multiples of what Medicare pays (e.g. "350% of the Medicare rate)[0]. The provider can't tell you what you'll end up paying, because they literally don't know - it depends on the rate your insurer ultimately agrees to pay, which depends not just on what your provider charges, but also on whether the insurance network has existing payment agreements that apply to your treatment and supersede the rate that they bill.

Private practices that don't accept insurance can always tell you what they'll charge you. Private practices that accept _only_ private insurance actually can sometimes tell you, because they don't have to do the roundabout dance to the same degree[1], so they often have more standardized rates with private insurers. However, standalone private practices are a dying breed - most are part of practice groups, which are themselves owned by hospital networks, so it's very hard to find a doctor who _does_ accept private insurance but is _not_ part of a provider network that accepts Medicare patients[2].

[0] It doesn't help that, in many cases, private insurers are required _by law_ to reimburse more than Medicare does, which perpetuates this whole cycle.

[1] They may still have a back-and-forth billing negotiation, but because they don't have to use privately-insured patients to subsidize the publicly-insured ones, they have a much better idea of where it will end up.

[2] Some hospitals are actually talking about dropping Medicare altogether, because it's so expensive and complicated for them to accept Medicare patients, but even if they ultimately decide to, it will take a long time to actually implement, for a number of reasons which are rather tangential to the topic at hand here.

<comment><USER9> Why do providers accept a loss doing treatments for Medicare?

If it's a loss per patient, it's a loss and you'll go out of business. What is the advantage for the provider to do any Medicare work?

<comment><USER8> > Why do providers accept a loss doing treatments for Medicare?

They don't really "accept" it, as much as Medicare can set the rates unilaterally, and providers don't really have a choice (other than refusing to treat Medicare patients).

> If it's a loss per patient, it's a loss and you'll go out of business.

Exactly.

> What is the advantage for the provider to do any Medicare work?

There... isn't a great incentive, really. This wasn't always the case, but it's gotten worse in the last 10-15 years. That's why many private practices _have_ gone bankrupt and closed (or gotten bought out by larger systems), and others have stopped taking Medicare patients.

Larger hospitals have some tricks they can use to make the numbers work out, but as Medicare's reimbursement rates have gotten worse and worse (compared to COGS and inflation), they've been feeling the pressure too. That's exactly why some are starting to talk about refusing to treat Medicare patients altogether.

There are some exceptions, too. For example, Medicare has a special program for hospitals in rural areas that treat large numbers of Medicare patients, and they'll essentially pay them an extra sum on top of their normal reimbursement rates, to make up for the fact that they don't have many privately-insured patients to overcharge to make up the difference. (But most hospitals aren't eligible for this, even if they treat large numbers of Medicare patients).

For independent practices, refusing to treat Medicare patients is easy (and many already have). For larger practice groups and hospitals, refusing to treat Medicare patients is the "nuclear option". It'll take a lot of work structurally to adjust the way they're organized in order for this to be feasible. But the way things are headed, that's what we'll start to see, because, as you pointed out, you can only lose money per-patient for so long before you go out of business.

</comment></comment></comment></comment><comment><USER10> I don't live in the US, but I've always though it was because it is for profit.

In most countries the hospitals don't have to return a profit to the owners and run at cost. In the US they have to pay the profit on top of the cost. In addition you have an insurance industry with high administrative cost and the need to turn a profit that makes it even more expensive.

This in addition to very high medicine prices results in an overall expensive healthcare system.

The article seems to support this notion although it doesn't spell it out directly. The punchline is "It's not that we're buying more pizzas, we're just paying more for each pie,"

<comment><USER11> You have your conception of profit backwards.

The existence of profit is supposed to act as an incentive to competition. Profit isn't something that is added on top of the cost; profit is the difference between the cost and what the market is willing to pay. Lots of profit attracts competition, and competition reduces the market's willingness to pay.

Normally profit arises from looking at what the market is willing to pay, then figuring out how to provide that for some cost that is lower. Profits are normally increased by decreasing costs, since increasing prices is not normally an option - the market won't pay the higher costs due to alternatives.

What stops the market functioning is irrational markets (e.g. people always want the best and won't settle for second-best, so they overpay; or they want treatment even if risks and costs due to treatment are worse than the probability adjusted costs of the thing being treated), barriers to competition (lots of regulation - for good reason), monopolies (e.g. drug patents), information inefficiencies (lack of pricing transparency so price isn't able to act like the signal it should), information asymmetries (doctors know more than the patients, who are actually paying for the healthcare), incentive misalignment (employer-provided healthcare being a big one), etc.

<comment><USER10> It's not really backwards though.

There is nothing to stop a non-profit hospital from being as efficient as a for-profit one.

In that situation the non-profit will always be less expensive as the for- profit one unless the investors are willing to take a 0% return on their equity.

When it comes to what the market is willing to pay, what will a man that is about to die be willing to pay to be cured? Quite a lot I guess so there is nothing really to stop price gauging if the patient is paying for it directly.

<comment><USER12> > There is nothing to stop a non-profit hospital from being as efficient as a > for-profit one.

Sure, but there is also no motivation to do so. NASA never even thought about having a rocket return. SpaceX/Blue Origin, that was the first thing they thought of "how do we reduce cost over time, this is wasteful"

<comment><USER13> The solution could be a government lower cost alternative to the private health care so they can keep each other in control. Same as us post office does for ups and fedex

<comment><USER12> I actually really like that idea.

</comment></comment></comment></comment></comment></comment><comment><USER14> A lot of padding before the core:

> There were two areas where the United States really was quite different: We > pay substantially higher prices for medical services, including > hospitalization, doctors' visits and prescription drugs.

> And our complex payment system causes us to spend far more on administrative > costs.

> The United States also has a higher rate of poverty and more obesity than > any of the other countries, possible contributors to lower life expectancy > that may not be explained by differences in health care delivery systems.

So the explanation for "why is this so expensive" is "we pay more"...

</comment><comment><USER15> A daily reminder that the US spends more per-capita on socialized medicine than any other country except Norway, and spends more on _socialized_ medicine per capita than many first world countries (e.g. france, australia, japan) spend on medicine in _total_ , both public and private. [1]

Conservatives (I am a conservative) who say we have a free market system are wrong. Liberals who say we are too heartless to pay for a socialized medical system are wrong. Anyone who says our military spending is why we don't have public healthcare is wrong. Anyone who suggests the US is competent enough at public administration to implement a public health care system is also probably wrong.

Collapse appears to be the only way out.

[1] - [https://en.wikipedia.org/wiki/List_of_countries_by_total_hea...](https://en.wikipedia.org/wiki/List_of_countries_by_total_health_expenditure_per_capita#/media/File:OECD_health_expenditure_per_capita_by_country.svg)

</comment><comment><USER16> Maybe I just haven't had enough coffee, but this article felt really lacking.

> There were two areas where the United States really was quite different: We > pay substantially higher prices for medical services, including > hospitalization, doctors' visits and prescription drugs.

> "It's not that we're buying more pizzas, we're just paying more for each > pie,"

We already know we pay more. That's literally stated in the title. _Why_ are we paying more? Isn't that the central question being discussed?

> It's often argued that patients in the United States use too much medical > care. But the country was below average on measures of how often patients > went to the doctor or hospital.

They don't specify, so I have to wonder if they made any effort to distinguish between hospital visitation rates for people with and without insurance (or with and without _good_ insurance). Considering that visiting the hospital - or even worse, ending up the ER - can be financially crippling for those without adequate insurance, I have to think this is an important variable.

Also, this article doesn't address what is probably one of the most oft-cited explanations for high healthcare costs in the US : prescription medicine. Specifically the idea that the US 'subsidizes' pharma R&D by virtue of not having any entity that is capable / willing to negotiate the prices that many other countries enjoy. You'd think that an article that purports to debunk 'common' explanations would at least mention the most common one of them all.

</comment><comment><USER17> One benefit for other countries is experience. Germany, where a national healthcare system started when the country did (originally Krupp offered it to their employees), when Germany became a country in the late 19th century, they adopted Krupp's ideas on a national scale. I have a relative that works in a Doctor's office in a small town in Germany, she sometimes drives them on house calls. People there don't worry about getting health care or paying for it, however on weekends and evenings you do have to drive to another town to get care. No system is perfect, but it generally involves little stress to the "customers" other than inconvenience. Also in Germany when you have surgery people are commonly sent to rest "resorts" to recover, so that when they return to work they are over the surgery. Her town is filled with these places because there are a lot of walking paths and nature for people to enjoy. All paid by the healthcare system. Of course they have challenges paying for this, yet it's still half of what the US pays per capita. No one gets rich working in healthcare in Germany, but no one goes bankrupt using it.

<comment><USER5> > No one gets rich working in healthcare in Germany, but no one goes bankrupt > using it.

the notion that one should get rich working in healthcare is a strange one to me?

You work in healthcare because you want to help other people in getting a healthy (and hopefully happy) life? Money should not be the prime motivator for working in healthcare in my opinion.

a good example of this is my S.O, which works in specialized care for the mentally ill. She makes around 30K euro's a year (which is slight below the global average in NL). Its a decent wage, it's not going to make you a millionare. It's a very demanding job in terms of working hours, stress and physical labour but the energy she get's from it makes it absolutely worth it for her.

Money should not be your prime motivator in life.

<comment><USER18> If only you could convince most of America of that last point. I am reminded of the 'temporarily embarrassed millionaires' quote about Americans and socialism.

</comment></comment></comment><comment><USER13> I recently realized that maybe the biggest scam of the American health care is that we pay twice for healthcare. when young and healthy we sponser the profit of the health insurance industry and sponsor the older people higher expenses through taxes (Medicare)

</comment><comment><USER19> Since this is Hacker News, I feel like asking...

What startups working to fix these issues? Large companies? Is there a market opportunity here?

</comment><comment><USER20> I've read the article but I am surprised by its lack of substance. The basic TL:DR is: health care is more expensive because we pay more for the same.

That's pretty obvious and also the reasons why it's more expensive are not really detailed in the article (besides admin costs).

</comment><comment><USER21> 1) Profit

</comment><comment><USER22> Sad to here that..

</comment><comment><USER23> Oh, no. Even the NYT uses click-bait titles, now.

"journalism is dead, the reason will completely shock you!".

<comment><USER24> It kinda sounds like that's an intentional reference to a common clickbait format. My guess would be the article is about how clickbait has affected journalism?

<comment><USER23> I don't know because I don't click on those out of principle and didn't click on this one, either :-D</comment></comment></comment>


Using KiwiSDRs to locate HF radio transmitters and numbers stations - <AUTHOR> https://www.rtl-sdr.com/locating-various-hf-transmitters-and-number-stations-with-kiwisdrs/ <comment><USER2> $300 seems very reasonable for a software defined radio. Could be fun to tinker with.

<comment><USER3> There is also the hackrf one which is pretty much on the same level as Kiwi if not a bit better you can find it for about the same price but the difference is that the HackRF often goes on sale with a 30-50% discount.

On a tangent number stations is like the number one "secret" I would love to be solved, I'm really curious if these are still used to direct I/Os or of these are just the RF community version of trolling these days.

<comment><USER4> HackRF One seems to have strikingly different architecture compared to KiwiSDR, so I'm not sure if they are really comparable at all.

<comment><USER5> They don't seem to be. HackRF is 1MHz - 6GHz and it's a beast (you can go lower with upconverter like Ham It Up). I only just learned about KiwiSDR and I'd love to know for which use cases people would choose it over HackRF. If I understand correctly the setup may be easier, but other than that?

<comment><USER6> I'm totally with you. The selling point of KiwiSDR seems to be that it allows everyone to use the same device simultaneously as the entire spectrum that KiwiSDR can capture is available all at once.

[https://www.sdr.hu](https://www.sdr.hu)

Here is the top entry: [http://sdr.hu/click?id=172](http://sdr.hu/click?id=172)</comment></comment></comment></comment></comment>


The Junk Mail Men: Selling Your Data for over a Century (2019) - <AUTHOR> https://www.saturdayeveningpost.com/2019/12/the-junk-mail-men-selling-your-data-for-a-century/ <comment><USER2> The internship I was assigned in college was a local junkmail mill. I was supposed to sign an NDA at some point but never did. Apparently they were able to use FOIA requests targeted at localities to get a lot of information for mail campaign targeting that all got put in a big database. Seemed a little sketchy.

<comment><USER3> No need to do that when the USPS will sell it to them.

<comment><USER2> I think the FOIA's gots extra info like who got a permit to build a pool.

</comment></comment></comment><comment><USER4> Never thought I would feel nostalgic for old school address labels. The current version of marketing is much more, ah, specific. If you work with data about people, you should read Christopher Wylie's description of more powerful technology:

[https://www.amazon.com/Mindf-Cambridge-Analytica-Break- Ameri...](https://www.amazon.com/Mindf-Cambridge-Analytica-Break- America/dp/1984854631)

<comment><USER5> The "old school" data brokers were keeping track of menstrual cycles 20 years ago for timed targeted ads. They were very specific about many things. The new kids Google and Facebook didn't invent this game.

<comment> noman-land Mind posting some links about this? I'd be very interested in reading about it.

<comment><USER6> I think the show Mad Men mentions this, Peggy if I'm not mistaken. Lunar cycles correlate with menstrual cycles. [1]

[1] [https://www.ncbi.nlm.nih.gov/pubmed/3716780](https://www.ncbi.nlm.nih.gov/pubmed/3716780)</comment></comment></comment></comment>


Tesla batteries will live longer than expected, survey finds - <AUTHOR> https://www.engadget.com/2018/04/16/tesla-battery-packs-live-longer/ <comment><USER2> Tesla used to (still does?) put larger batteries in their cars than ordered, and limits them with software:

[http://www.thedrive.com/sheetmetal/12820/tesla-is- silently-p...](http://www.thedrive.com/sheetmetal/12820/tesla-is-silently- putting-bigger-battery-packs-in-its-entry-level-model-s)

So if these numbers are from the owners reading them from the dash... they wouldn't know their 40kwh battery was actually a 60kwh battery that was software limited. That's a lot of spare capacity to hide aging.

Remember when they flipped a switch to allow Florida owners to use the range of their larger batteries to escape the hurricane:

[https://techcrunch.com/2017/09/09/tesla-flips-a-switch-to- in...](https://techcrunch.com/2017/09/09/tesla-flips-a-switch-to-increase-the- range-of-some-cars-in-florida-to-help-people-evacuate/)

Larger batteries than purchased are clearly quite widespread with Tesla.

<comment><USER3> Not saying it's impossible - or even unlikely - but has anyone actually done a tear-down confirming there are identical batteries in cars sold as having different batteries?

The reason I ask is a lot of lithium cell suppliers say "This is an x kWh battery... but don't charge above 90% or discharge below 20%" so the usable capacity is 70% of the advertised capacity. Could be that Tesla just advertises the usable capacity.

<comment><USER4> Hmm, I think it's not relevant because those constraints apply on the cell level, and Tesla battery packs are just thousands of small cells.

Well I suppose it depends if you leave x% of cells unused (prolonging their life, and ready to swap in when other cells lose capacity, much like SSDs do) or distribute across all cells, lowering the charging level X%. Either way I suspect you're hitting the "full cycle" that diminishes the cells life, so probably better to use the former strategy, leaving you with some healthy cells in the future.

Curious to hear if someone suspects otherwise though.

<comment><USER5> They don't have cell-level control, so it's definitely the latter. The cells are wired in strings, then paralleled.

[http://qnovo.blogspot.co.uk/2014/11/31.html](http://qnovo.blogspot.co.uk/2014/11/31.html)

(although apparently they do have individual fuses!)

</comment></comment></comment></comment><comment><USER6> For some lithium battery chemistries (eg. LiIon) they have a limited shelf life regardless of number of cycles (which is why, for example, phones and tablets tend to drop sharply in battery life after 2-3 years regardless of level of usage). I'd be curious to know how the Tesla packs perform in that regard.

<comment><USER7> LiIon refers to a whole range of different chemistries; Tesla uses Lithium Nickel Cobalt Aluminum Oxide which offers a longer lifespan while typically laptops and phones use Lithium Cobalt Oxide.

I was also under the impression that Lithium batteries suffer from calendar degradation, but I wonder how much of a thing that is with modern batteries if they have good thermal management (like Teslas do), or if we even notice it when actually using a device (laptops and phones run the battery hard and hot, so end up having a 2-3 year lifespan from normal use.

<comment><USER8> Tesla use Panasonic's NCR18650B cells which were originally designed for laptops. (At least in the Model S anyway, I think the Model 3 is using something a little more custom.)

<comment><USER7> You are describing battery sizes, not chemistries. 18650 is a standard cell size which Tesla uses in their older vehicles, and is common in older laptops and powertools. The types of chemistry used in it may vary (just like you can get AA cells in alkaline, NiCd, NiMH, and other chemistries)

<comment><USER8> No I'm not. 18650 is the size, NCR1850B is a very specific model of off-the- shelf cell in that size manufactured by Panasonic with a specific chemistry and specification. As far as I can tell (it's not something the manufacturers release much information about publicly) the "NCR" part identifies the chemistry as Lithium Nickel Cobalt Aluminum Oxide.

</comment></comment></comment></comment></comment><comment><USER9> Well the data shows just how much active cooling helps to lengthen their live. Gen 1 Leaf packs didn't have active cooling and their life goes downhill quickly.

[https://insideevs.com/nissan-issues-statement-on- leaf-30-kwh...](https://insideevs.com/nissan-issues-statement-on-leaf-30-kwh- battery-degradation/)

<comment><USER10> No Leaf has active cooling, including the latest 40kWh Gen4.

<comment><USER11> I'm not trying to nitpick, I really cannot tell and don't have context or pre- existing knowledge to resolve it for myself and I'm not a native speaker either:

Do you mean "No Leaf has active cooling", or do you mean "No, Leaf has active cooling" (with a comma)?

Because I _suspect_ the comma version, because I think the no-comma version would probably have been formulated slightly differently?

<comment><USER12> The reply you're responding to was a rebuff of the original parent to the thread - so it should be read without a comma i.e. it is correctly written.

You could write it as:

"Not a single Leaf has active cooling" or "None of the Nissan Leaf's have active cooling".

The above two alternative sentences aren't as elegant or concise as the original, hence why it was likely chosen.

</comment></comment></comment></comment><comment><USER13> Netherlands - Belgium. Temperatures there seem to get close to freezing, but mostly not below. At least it's not California, so the batteries do hold well.

Is there a survey from places with actual winters anywhere?

<comment><USER14> I believe there's been a fleet of Model S taxis in Montreal Canada for several years. They could have some cold weather data. Oh, and of course Tesla sells a ton of cars in Norway which can get chilly too.

</comment></comment><comment><USER15> Is this survey more than just reading the stats of the dashboard? How do we know those are correct? How much reserve do the Tesla battery packs have that is not reported in the car dashboard?

<comment><USER16> If Tesla has a reserve, the most obvious implementation would have a curve of degradation that would give it away: 100% for a long time, then a significant and steady drop.

Hard disks and SSDs work that way; hard disks have a 20% reserve these days.

</comment></comment><comment><USER17> 1.2 Billion kilograms of lithium are estimated in reserves on planet earth - estimated by the USGS.

10 Kilograms of lithium are needed for each Tesla battery

~122M Tesla batteries can be made.

0.5M teslas produced per a year by 2020 is their aim.

20 to 100 gigafactories would mean 50 to 300 years of lithium availability.

8 year durations on Tesla batteries.

I'm not sure extended duration on these things means anything environmentally relevant.

<comment><USER18> I think your data is bit off:

[https://minerals.usgs.gov/minerals/pubs/commodity/lithium/mc...](https://minerals.usgs.gov/minerals/pubs/commodity/lithium/mcs-2018-lithi.pdf)

53M tons of lithium available = 53000M of kg = 5300M of Tesla batteries can be made...

<comment><USER19> Also, that's just the lithium deposits we know about now.

<comment><USER16> Actually, no, that's the lithium deposits that we know can be extracted at the current price. If the price goes up, the reserves rise immediately, because more of what we know becomes extractable.

</comment></comment></comment></comment><comment><USER20> ...yet, my last two laptop batteries stopped holding a charge for more than 30 min after one year (I'm only slightly exaggerating)</comment>


Change Data Capture for a Brave New World - <AUTHOR> https://www.youtube.com/watch?v=0cZ4elFNAQQ <comment><AUTHOR> Hannu Valtonen, gives a presentation discussing the evolution of CDC for PostgreSQL, as well as how to stream those changes using Apache Kafka with the Debezium connector.</comment>


Yaël Eisenstat: 'Facebook is ripe for manipulation and viral misinformation' - <AUTHOR> https://www.theguardian.com/technology/2020/jul/26/yael-eisenstat-facebook-is-ripe-for-manipulation-and-viral-misinformation <comment><USER2> Ripe for implies a future problem. FB has become viral information by definition. Previously by definition it was only a vector for advertising, now the ratio of advertising to misinformation is the only measure of its utility.</comment>


Elon Musk says full self-driving Tesla tech 'close' - <AUTHOR> https://www.bbc.com/news/technology-53349313 <comment><AUTHOR> "I feel like we are very close. "I remain confident that we will have the basic functionality for level five autonomy complete this year. "There are no fundamental challenges remaining. "There are many small problems. "And then there's the challenge of solving all those small problems and putting the whole system together." Real-world testing was needed to uncover what would be a "long tail" of problems, he added.

<comment><USER2> Based on my personal programming experiences, if there's no fundamental problems and they're just fixing minor edge cases then about 90% of the work still needs to be done

</comment></comment><comment><USER3> Why wait till it's ready?

<comment><USER3> More seriously, the nice thing about this "prediction" is that it's so close. So I can go on record and say: Teslas will _not_ be fully self-driving "by the end of the year" nor even by the end of _next_ year, nor the year _after that_. I doubt we'll see one in 2030, for that matter.

If a car isn't smarter than a human, it will kill people in ridiculous circumstances. Reaction time can be an order of magnitude better than human, but you can't release a car that occasionally drives over a baby for no reason.

If Musk actually claimed otherwise in earnest, he's either having another episode, or maneuvering to fix an issue with PR or stock price.

<comment><USER4> > _you can 't release a car that occasionally drives over a baby for no > reason._

I disagree entirely. We have planes that occasionally kill people, we have x-ray machines, microwaves and gas BBQ's too. And of course, 36,000 people are killed on the roads in the USA each year [1].

Any self driving car doesn't have to 100% perfect, it only needs to be better than human drivers, and it will be saving lives. Yes, the "bad press" will be painful, but in the long run less people will die as a result, so it's a net win.

[1] [https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in...](https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in_U.S._by_year#Motor_vehicle_deaths_in_U.S._by_year)

<comment><USER5> I am not sure you are looking at the correct numbers. according to NHTSA – [https://www-fars.nhtsa.dot.gov/Main/index.aspx](https://www- fars.nhtsa.dot.gov/Main/index.aspx) there are 1.18 fatalities per 100 millions miles driven. That means, if an individual drives 15.000 miles per year, that individual will face the possibility of dying in a fatal crash as a driver, passenger or pedestrain, once in 6666 years, so the cars and road system are extremely safe as they are today. Most of the self driving cars developers recognize this like Chris Urmson in his Recode Decode interview – "Well, it's not even that they grab for it, it's that they experience it for a while and it works, right? And maybe it works perfectly every day for a month. The next day it may not work, but their experience now is, "Oh this works," and so they're not prepared to take over and so their ability to kind of save it and monitor it decays with time. So you know in America, somebody dies in a car accident about 1.15 times per 100 million miles. That's like 10,000 years of an average person's driving. So, let's say the technology is pretty good but not that good. You know, someone dies once every 50 million miles. We're going to have twice as many accidents and fatalities on the roads on average, but for any one individual they could go a lifetime, many lifetimes before they ever see that." – [https://www.recode.net/2017/9/8/16278566/transcript-self- dri...](https://www.recode.net/2017/9/8/16278566/transcript-self-driving-car- engineer-chris-urmson-recode-decode) or Ford Motor Co. executive vice president Raj Nair – "Ford Motor Co. executive vice president Raj Nair says you get to 90 percent automation pretty quickly once you understand the technology you need. "It takes a lot, lot longer to get to 96 or 97," he says. "You have a curve, and those last few percentage points are really difficult." Almost every time auto executives talk about the promise of self-driving cars, they cite the National Highway Traffic Safety Administration statistic that shows human error is the "critical reason" for all but 6 percent of car crashes. But that's kind of misleading, says Nair. "If you look at it in terms of fatal accidents and miles driven, humans are actually very reliable machines. We need to create an even more reliable machine." – [https://www.consumerreports.org/autonomous-driving/self- driv...](https://www.consumerreports.org/autonomous-driving/self-driving-cars- driving-into-the-future/) or prof. Raj Rajkumar head of Carnegie Mellon University's leading self-driving laboratory. – "if you do the mileage statistics, one fatality happens every 80 million miles. That is unfortunately of course, but that is a tremendously high bar for automatically vehicle to meet." min.19.30 of this podcast interview – [http://www.slate.com/articles/podcasts/if_then/2018/05/self_...](http://www.slate.com/articles/podcasts/if_then/2018/05/self_driving_cars_are_not_yet_as_safe_as_human_drivers_says_carnegie_mellon.html) or Elon Musk himself - "On average, a person is killed in a traffic accident in the United States once every 100 million miles. Elon Musk says Tesla's Autopilot is half as likely to be involved in a collision as a human driver. That would suggest that somewhere around the 200 million mile mark someone will die as a result of an automobile driven by a machine." \- [https://www.teslarati.com/autonomous-cars-make-us-worse- driv...](https://www.teslarati.com/autonomous-cars-make-us-worse-drivers/)

What you are using is a fallacy, emotional statement done by self driving cars developers and enthusiasts in order to make people think by adopting this technology they will be part of a bigger better future, by doing essentially nothing."

<comment><USER4> What I'm saying is that self-driving cars don't have to be perfect, they just have to be better than human drivers.

Once there are less deaths with self-driving cars that human-driven cars (however you want to measure that) then it makes sense to use it.

<comment><USER3>
        >  they just have to be better than human drivers.

That's where the difference in our outlook is:

The way I see it, people can stomach the existence of _ridiculous_ accidents (ridiculous in the sense that the details are "absurd", not just "very grim") when they can blame a human.

I don't think many people will tolerate even occasional "self-driving" accidents if the circumstance show a human would have recognized the danger.

For a self-driving car to be fit-for-purpose, it can't run over kittens at low speeds on an empty road - _even if they 're very small kittens that don't exceed some motion-sensing threshold_. That requires common-sense reasoning.

<comment><USER4> I think you're absolutely right there will be push-back if the self driving cars crash is stupid ways, but again, it's all about the numbers.

Planes still fall out of the sky for stupid reasons (maintenance errors, mostly) yet the numbers say they're very, very VERY safe, so people use them.

Once the facts show self driving cars are safer than human driving cars (even if they sometimes crash in stupid ways), there will be no holding back.</comment></comment></comment></comment></comment></comment></comment>


Why I think Node.JS is a terrible platform - <AUTHOR> http://dev.hasenj.org/post/31042963934/nodejs-hate <comment><USER2> Node.js is one of the worst things to happen to the software industry in recent times, a whole generation of programmers are being taught the worst of all ways of doing concurrency, in a system that doesn't scale either in performance or project size and with one of the languages most plagued by pitfalls ever created.

JavaScript was already painful enough in the browser, why on earth anyone ever thought it was a good idea to use it on the server boggles the mind.

We will be paying the price of this misguided hyped fad for decades to come.

Of all the ways of doing concurrency, callbacks are by far the worst, Twisted was plagued by them and is the main reason why it failed, and that was with a much more sane and reasonable language like Python (stackless Python was a much better alternative and used a model similar to Go's CSP).

And the sad thing is that there are much better alternatives around with much more sound models and environments, Erlang and Go are the two obvious examples, and that is for the highly specialized situations where you have great concurrency needs, for any other problem anything else will be much better than Node.js, even PHP.

<comment><USER3> "JavaScript was already painful enough in the browser" only because its in a browser where standards are inexistent.

<comment><USER4> No JavaScript in all honesty was painful because the way it was designed (it was made in ten days). Equality operator ('==') is a cause of MAJOR headache and so is the global scoping, the bizzaro addition operator, etc.

See[1min 23s] <https://www.destroyallsoftware.com/talks/wat>

<comment><USER5> <http://stackoverflow.com/a/9033306> \- this "wat" meme is getting old. At best, you people that keep posting this are automatically qualified as trolls. The fact is that probably none of you folks from the "wat" crowd didn't take the time to read the ECMA standard. I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either.

And yes, developing under node is not the same as developing for the browser where you need to use the lowest common denominator, which usually is IE6.

I'd say that the issue is the "omg node.js" crowd that promoted it as the hammer for every issues that may pop out. It isn't. But this doesn't mean that it is completely useless.

<comment><USER4> Sorry, but please explain how is this issue somehow elevated by node when it is a part of language standard (ECMAScript standard linked in the article it posted)? Does V8 break ECMAScript? This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive.

<comment><USER5> I said:

> I don't claim that the behavior is intuitive, or appropriate for some cases. > But the lack of RTFM isn't excusable either.

You failed the read test. Twice. The first was the manual itself.

> please explain how is this issue somehow elevated by node when it is a part > of language standard

You failed the read test. For the third time. Please indicate the part where I claim that node elevates the issue vs. standard ECMAScript behavior. I said something about the node vs browser runtimes. This is a totally different beast.

> This is a gotcha of a language. It uses + operator that does something > completely differently than what it usually does on almost any other > language with similar syntax. It's the definition of counter-intuitive.

The only gotcha is the coercion that some regard as dark magic vs statically typed languages vs the operators themselves. The "+" and "-" operators in JavaScript: "+" for summing Numbers or String concatenation, "-" for subtracting a Number from another Number (which basically makes it a strict arithmetic operator, you know, stuff for Numbers).

Besides:

\- PHP uses the + and - as strictly arithmetic operators (it has the . operator for string concatenation), while summing up two strings equals int(0) since (int) 'foo' === 0: <http://php.net/manual/en/language.operators.arithmetic.php>

\- C (and to some extent C++) uses the + and - as strictly arithmetic operators: invalid operands to binary + (have 'char _' and 'char_ ')

\- Java uses the + the same way as JavaScript: [http://docs.oracle.com/javase/tutorial/java/nutsandbolts/ops...](http://docs.oracle.com/javase/tutorial/java/nutsandbolts/opsummary.html)

What other language with "similar syntax"? D?

<comment><USER4> Yes, I may have skimmed a little. But this doesn't excuse language makers for not anticipating such a use common case and returning a result that can be said to be expected (i.e. error, trying to add one list on other). If there isn't a real comparison, you should take a couple of people that are likely to use this and say "what should [] + [] return". You can't say that they couldn't have implemented " []+[] " throws a TypeError or something, even in a dynamic language.

It is said that API is UX for programmers. Well this is UX for a computer language. And JS fails at it. Big time. And this isn't the only stumbling rock (see global variables, == operator, semi-colon insertion, etc.).

My point was that developing under Node.js is same as developing under a browser only the lowest common denominator changes to V8.

Edit: I'm pretty sure + operator in Ruby concatenates two arrays.

<comment><USER5> > "[]+[]" throws a TypeError

Couldn't agree more. But that's the standard. At some point I hoped that the ES5 'use strict' would fix all of this SNAFU, but it didn't.

However, not even once I tried to sum [] + [] or {} + {} till that "wat" video. Funny, but unrealistic, therefore: close, but no cigar. One could operate the "World's safest table saw", but the common sense tells us that usually finger vs. saw => saw wins. Safer tools are desirable, but it's up to the craftsman to use them properly.

> the lowest common denominator changes to V8

V8 is pretty much on par with its competition with the ES5 adoption, therefore we can hardly talk about a lowest common denominator that's actually low. The only thing that I actually missed in V8 vs. the Mozilla engines is the support for E4X (which most runtimes don't support anyway).

<http://kangax.github.com/es5-compat-table/> \- even if IE6 and IE7 are gone from the traffic stats, IE8 is there to stay with the XP users. Some of us still don't have the possibility to just drop those users as long as the analytic data shows a fair share of legacy users.

Ruby isn't part of the "similar syntax" family. The '==' operator isn't recommended in JS (and PHP). In fact, jslint yells at you if you use it. That's why '===' exists. The semi-colon insertion is one of the big failures on the "allowed" part. Wish that never happened. But any developer that doesn't try to adhere to some hipster JavaScript coding style uses the semi- colon at the end of the statement.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I get the impression that a lot of people are trying to use Node for things it isn't particularly suited for. That being, 95% of the things you'd want to build on the web.

My take on Node is that it's what you use when you want to build an Etherpad. If your app will have 1000 people messing with one thing at once, with all their interactions propagating out everywhere instantly, you're going to want to use Node. If you're building a mmorpg-in-a-browser, you'll probably find Node will be a good fit.

If you're building a CRUD app, however, Node is likely the worst choice you can make in terms of productivity lost versus advantage gained. I mean sure you'll pull it off. But the kid who wrote the same thing in Rails will be on his third failed startup by the time you get your MVP launched.

There's probably a balance that you can strike for apps that "sorta" need Nodeishness. Use a standard, non-insanity-inducing stack for the bulk of the site, then keep a Node instance off in the corner to run the "App" bit that needs the realtime communication.

I think this message got lost somewhere along the way, and now we're seeing a lot of frustration from people using this cool, specific, technology for stuff that it's just plain not suited for.

<comment><USER7> I understand node is quite good at those scenarios but is there any real advantage over say Ruby/EventMachine or Python/Twisted or if you're serious about it scaling, Erlang/OTP? Evented systems are great for those scenarios but I can't work out if there's some secret sauce in Node I'm missing or whether there's a lot of excitement from people that don't realise there are mature solutions to those scenarios in other languages.

<comment><USER8> luriel wrote a nice answer, like a good, old hater would write. (You can't just go around and insult programming languages. They have feelings too, dude.)

 _is there any real advantage over_ I think that's the wrong way to choose a platform. Are you good in Ruby? Then use RoR. Are you good in JS? Then use node.js. Maybe RoR is a much better platform than node.js, maybe it's not. But I finished writing my framework/application 10 times, before you even typed RoR. :D Furthermore: You. Don't. Use. node.js. For. CPU heavy. tasks! Don't do it. For everything else I think it's a wonderful framework, if you want to write something I/O heavy.

btw: The strict asynchronous programming style, using JSs closures, is pretty much the same thing you would write in C (except for that you don't have closures). I recommend everyone to look at least once into <https://github.com/joyent/libuv/> But unfortunately many "programmers" here won't do it, since C is stupid and for old farts. I mean: I can do anything in C# in a tenth of the time compared to you with C (<http://programmers.stackexchange.com/q/164017>)

<comment><USER2> > But I finished writing my framework/application 10 times, before you even > typed RoR.

You are never 'finished' writing, code requires almost perpetual maintenance and improvement. (Unless the project is a total failure or you are DJB.)

I'm sorry, but if you are _only_ good in JS, or PHP, the very first thing you should do is become good with some better tools.

Yes, it is possible to write working code in any language and platform, but languages and platform still matter and have a cost you will pay during the lifetime of your application, in security, reliability, scalability and maintainability.

<comment><USER8> Please don't just grab some random words from my post. I'm pretty sure you know that the sentence in question was just an idiom. And just so you know: I have experience in, and still regularly use C/C++, C#, Java, Haskell, Ruby, Python, Javascript, PHP. I don't know what node.js did to you (maybe you tried something as writing a whole webframework with node.js? or something as foolish as a file server?), but you should know that there are many projects out there which use node.js where it fits and it's running good (prime examples are Microsoft and LinkedIn).

 _> I'm sorry, but if you are only good in JS, or PHP, the very first thing you should do is become good with some better tools._

And I don't know what the hell is wrong with you, that you assume that you are the wisest of all men and know what is wrong with everything and what to use in any situation and what I know and what I do and what I should do...

 _> and have a cost you will pay during the lifetime of your application, in security, reliability, scalability and maintainability._

So thanks for this lesson. I swear I will spread the word, but before I will go and worship JS/PHP, as the little, stupid fanboy I am. (fyi that's called the language of sarcasm)

As I said: Don't go around and "insult" programming languages, because most of them have their right to exist and nobody forces you to use something you don't like, nor anybody else. Most programmer choose to use node.js and if they fail it's not necessarily the fault of the "tool" (though it can be), but also the fault of the programmer in question, by choosing a "tool" which didn't fit. I mean: You wouldn't try to put a screw in the wall with a hammer. Am I right?

</comment></comment></comment></comment></comment><comment><USER9> I think that a much better alternative to Node than Python or Go is Haskell. Why? Well, for one, it makes writing asynchronous code very easy--you essentially get it for free. Haskell web servers perform very well while keeping the code readable.

However, ignoring performance, there are also all of Haskell's other advantages. The type system is great--you can do stuff like ensuring links within your app work using the type system. Haskell is also very good at embedding DSLs, which can make writing web-specific code much nicer. In my experience, Haskell code tends to be more concise and declarative than Go or Python, making it easier to read. And, crucially, you can program at a higher level of abstraction which makes it both easier to write and maintain relatively complicated code.

Now, admittedly, going from almost any other language to Haskell is quite a shift. For most programmers, learning Haskell will take a bit longer than learning yet another imperative language (e.g. Go). However, I think this is well worth it, and web apps are a particularly convenient field for it.

This[1] StackOverflow question and an associated paper[2] are very interesting to read about how a Haskell web server could work and have good performance.

[1]: [http://stackoverflow.com/questions/3847108/what-is-the- haske...](http://stackoverflow.com/questions/3847108/what-is-the-haskell- response-to-node-js)

[2]: [http://community.haskell.org/~simonmar/papers/web-server- jfp...](http://community.haskell.org/~simonmar/papers/web-server-jfp.pdf)

It would also be useful to look at a Haskell web framework like Yesod[3], Snap[4] or Happstack[5]. I'm currently a little biased towards Yesod (which has, coincidentally, recently received commercial backing), but I think the choice of framework is largely a matter of preference.

[3]: <http://www.yesodweb.com/>

[4]: <http://snapframework.com/>

[5]: <http://happstack.com/>

<comment><USER10> Finally I am convinced about Haskell. I am giving it a shot: <http://learnyouahaskell.com/chapters>. Thanks :)

<comment><USER11> There's lots of books, you can find RealWorld and Road to Logic online too (not sure if RtL is legit)

<http://alexott.net/en/fp/books/#sec7>

and tuts

<http://www.haskell.org/haskellwiki/Learning_Haskell>

<http://www.haskell.org/haskellwiki/Category:Tutorials>

<comment><USER12> Learn you a Haskell for Great Good is one of the best introductory programming language books I've ever read. I don't use Haskell very often, but after carefully reading this book, I'm now able to easily use functional code in my Python and CoffeeScript/JavaScript when I need to do so.

The online version is free, but I bought the book. It's worth it.

<http://learnyouahaskell.com/>

</comment></comment></comment></comment><comment><USER13> "You lose expressiveness, you lose maintainability, you lose peace of mind"

Really, you found all that out after your experience...wait, what experience? You said yourself you failed to build a single simple app. So it seems to me you can only comment on expressiveness.

I'd love to read your review of, say, Haskell next. I have a feeling if you applied the same (lack of) rigor you demonstrated here, it would be _double extra_ terrible. The point being, there's no substance here, but it confirms people's negative feelings about JavaScript, so they'll upvote it.

<comment><USER14> It's pretty easy to find alternatives to Node.js that are a lot more sound, a lot easier to work with, and a lot more performant if you need asynchronicity. You gain _nothing_ save for the ability to use JS itself, for which the supposed benefits of sharing code are a total wash.

Node.js is async for people who don't actually know what they're doing, but are still willing to push an unnecessary boulder up the hill for the sake of a familiar language instead of learning how the industry's been handling async for the last few decades.

Node.js users "lack rigor", not this guy for questioning the ridiculousness of it all.

Go look at SFS/sfslite and its ilk to see how async is supposed to be done.

<comment><USER13> Do you mean this SFS? <http://www.fs.net/>

That appears to literally be the official website.

Sorry, but your post just sounds like "get off my lawn!" But good luck trying to convince everyone to write their web apps in C++.

<comment><USER14> <http://okws.org/> is a better example.

Actually, it's more like, "Write your web apps in Python/Clojure/Go/Java/Scala/Haskell/Erlang/C++/C/Common Lisp/Racket which all have better concurrency and async mechanisms than Node.js"

I was mentioning SFS/sfslite more as exemplars of clean ways to abstract asynchronicity than recommending C++ for web app development.

But you don't learn something like that if you don't learn to code without jQuery and npm packages.

<comment><USER15> What does jQuery have to do with NPM, which is one of the best designed package managers out there? Are easy_install, gem, cpan for noobs too?

<comment><USER14> I was making a crack about JS-only people.

</comment></comment></comment></comment></comment></comment><comment><USER16> _You lose expressiveness, you lose maintainability, you lose peace of mind, and you get speed._

\- I don't think my JS/CoffeeScript code is (significantly) less or more expressive and maintainable than the Python code I would have written. Use coffee if you want a whole bunch of language features, including some missing in Python. Oh, and a much cleaner way to write lambdas.

\- Yes you need to understand async. It is of course, increasingly relevant with services and devices talking to each other. For example, in Microsoft's WinRT anything taking more than 50ms has to be async by design. After a while you might even wonder why async isn't the default way of doing most I/O.

\- Flow control is hard in async, especially when you are getting started. But there are libraries which help, such as <https://github.com/caolan/async>.

\- The library approach works for me and is a safer bet, but isn't the cleanest. If you are adventurous you could try iced-coffeescript, which introduces keywords to give you simpler code.

\- Finally, you need to have a really good grip on JS.

<comment><AUTHOR> > I don't think my JS/CoffeeScript code is (significantly) less or more > expressive and maintainable than the Python code I would have written

The loss does not come from JS or coffeescript, it comes from everything being done with callback (whether nested or not).

<comment><USER17> Those wanting to succeed with node.js should listen more closely to the parent post. IcedCoffeeScript promises, _"Say goodbye to callback pyramids; say adios to massive code rewrites when synchronization requirements change slightly. Say hello to clean, readable, maintainable control flow for network and asynchronous operations!"_ (<http://maxtaco.github.com/coffee-script/>)

Personally though, I haven't yet tried/loadtested it, so can't speak to its effectiveness.

In any case, simply using plain CoffeeScript + async + underscore, will greatly cut down on node.js's complexity. Sure, you still have some async callbacks when doing I/O like calling some service, but it's much less awful.

(I haven't yet evaluated ClojureScript.)

</comment></comment></comment><comment><USER18> Node.js actually has two problems that I think will be very major issues for it in the long run:

\- it's based on JavaScript, which is a crappy language (despite how nice V8 is)

\- (OP's point) the async style is horrible for readability, which puts a tremendous toll on productivity (though many will deny it).

There are libraries like async (<https://github.com/caolan/async>) and streamline (<https://github.com/Sage/streamlinejs>) which try to eliminate #2. They are band-aids: the language itself must support asynchronous execution without callbacks.

Node has many advantages that make it really nice - V8 is awesome because of an interesting case of technological path dependence; the standard library has a lot of modules that take great advantage of asynchronous I/O; the standard library is very high quality; the community is great - but I think the two issues above really leave room for another project to take the good parts and not the bad ones, and steal Node's thunder. It could be Go or Python (with some badly needed extra work on coroutines, concurrency, performance/adoption of pypy, etc), or something new.

</comment><comment><USER19> I write applications professionally in Python, Javascript, and Java. While there is some overlap, I find each platform to have merit.

* I like Java for projects that I know are going to become big and complicated. When you have thousands of classes and multiple people working in a codebase, static typing is a godsend. I don't care if it involves a little more typing. As an added bonus, the JVM performs great.

* I like Node.js for small projects, especially ones with large concurrency needs. I recently did a project that involved being able to aggregate repeated barrages of several thousand requests with a finite deadline of a couple seconds. Node.js handled twice the throughput of Twisted or Tornado, and was considerably more stable. Gevent and coroutines would have been even slower.

* I like Python for stuff "in between". Rich libraries, blocking i/o, exceptions, and proper stacktraces. Even has halfway-decent IDE support (PyDev). Execution is slow by JVM standards but Python makes a great swiss army knife.

There's no perfect platform for all situations. Use the right tool for the right job - sometimes that's Node.js. There's a lot of overlap with Python, but not as much as you seem to think.

</comment><comment><USER10> I had the same experiences as you did because of jumping on the bandwagon. Hasen, when you opined "Node.js is a terrible platform", I thought you would also say something about the bad decisions we make because of it. This is how I made mine:

Day 1: Let's Node.js because everyone is doing it. In that context, no-sql databases gel very well with it, so let's do that.

Day 3: Whoaa! Prototype is already done. Great

Day 4: My databases entities are so thin, sql databases are so overrated. I don't need sql.

Day 6: Uh-Oh, I did not think of that database entity. Oh no, look, it has a relationship too.

Day 7: Frack, the no-sql CRUD operations code is damn mess.

Day 8: More relationships! "If I only had used sql". Sighs. Oh wait, look a node.js-mysql library. (Code Hustle). No no, it is still a mess. Well, it is still working so let's have a little patience.

Day 15: Why my code looks like a puke?

Day 20: Ok, I/O code is now like 7-8% of my complete project. Why did I go for Node.js again? This doesn't make sense. I am going on a vacation.

Day 27: First thing back from vacation, farewell Node.js. Let's go for Flask(python) + SqlAlchemy(oh I missed you so much) + Gunicorn + Gevent + Juggernaut(for websocket.Node.js, you found your rightful place).

I think the reason for such hype around Node.js is due to the rise of a new class of startups which are born with a "fail-fast" mentality. Node.js does help you to fail fast. But I think that it is a pessimistic view of idea and software development. Agreed that node.js removes the initial inertia to implement an idea, but I think that this is it's greatest failure. A little inertia can be good. It forces you to sit down and think hard about the architecture and the idea itself. It's same as a small group of lean mean soldiers can extract a defended fort from the enemy, but holding the fort would take a lot of strategic thinking, resources and more soldiers. I think it's time to get a bit optimistic about our own ability to do that. Well, unless, you never wanted to hold the fort. In that case, everything is just fine.

<comment><USER20> I've seen many people and organizations run into problems like you describe. I don't mean to come off as insulting to you, but the only reason I can see a path like that being taken is out of complete ignorance.

At the beginning of your project, how did you ever think that it'd be a good idea to use JavaScript, Node.js and NoSQL? Yes, there may be a lot of hype around them, but after a brief analysis of them it's clear they're inferior to most other options that are already available.

I can completely understand JavaScript being used for browser-based scripting, where it's basically the only practical option. But why would anyone ever consider it for server-side development, given that so many better options are available?

The same goes for Node.js. Reading a brief introduction to it only serves to make Erlang and Go, among other options, look far more appealing.

And again, the same goes for NoSQL. Cursory investigation reveals that anything that can be done with a typical NoSQL database can be done with any capable relational DBMS, plus you at least get the option of using proper SQL queries if necessary.

So how can a month (or much longer, in some cases I've seen) be wasted on obviously-inferior technologies? Was it really not obvious at the very beginning that the outcome would be disastrous?

<comment><USER10> The project started out as a minor one, but after a few successes it kind of snowballed. If I didn't had those earlier successes, I would have introspected about my decisions earlier. Unfortunately I got fooled into thinking otherwise. These small successes turned out to be red herrings. Also, it's hard not to give into mass hysteria and perhaps I wanted to taste the impracticability for myself. Thus, despite reading all about node.js, nosql and their horrors, I got greedy.

</comment></comment></comment><comment><USER21> Japanese is a terrible language. I tried speaking it for a while, but I can just get my ideas across so much more easily in English. It's just easier. This must be because Japanese is terrible.

That seems to be the basic reasoning at work here.

<comment><AUTHOR> No, that's not the basic reasoning here.

And btw, I actually love the Japanese language, I find it more poetic and actually more expressive too, because you can nest expressions more easily than in English or even Arabic (my native language).

<comment><USER21> > _No, that's not the basic reasoning here._

Then I don't know what was, because your point certainly seemed to be that you used Node and had a harder time reading and writing code with it than an environment that was more familiar to you, and therefore Node is terrible.

</comment></comment></comment><comment><USER22> This post shows exactly why "just use code to get things done" can be taken too far and why a solid theoretical background can be essential to growing as a programmer. The author bravely admits, "The async-style of programming is almost entirely inaccessible to my brain." There comes a point on the road to being a great coder where you can no longer really approach it as a craft; the theory and philosophy start to matter. A common plateau is the point where it becomes necessary to see the commonality between essentially the same computation being driven by different control approaches. I've seen many a competent procedural programmer be unable to write their first GUI app because they can't adjust to an event driven model or unable to make the most of SQL because of its semi-declarative nature. Coders need to see such mind expansion as an essential and fun part of the job.

</comment><comment><USER23> I've been using NodeJS in production for a few years, and I'd agree that is probably not the best way to write an application with many layers of business logic.

That said, it's wonderful for networking, child process management and handling subscription connections (via Socket.IO, etc).

Effective evented programming does have a radically different style, and many times it boils down to tastefully drawing the line between when to bind and trigger events vs when to pass functions as arguments.

<comment><USER24> What bothered me is that I couldn't find a way to find out what code had triggered an event, or what listener was attached where. So, suddenly you're getting an error in code and you can't figure out why it's even being called, because it was attached from one of eight libraries that you picked up as to not reinvent the wheel.

...and grep emit isn't an effective solution. :)

I put a question up at SO and never received a response. [http://stackoverflow.com/questions/12215273/how-are-event- tr...](http://stackoverflow.com/questions/12215273/how-are-event-triggers- debugged-in-node-js) \-- the problem itself I finally worked through, but then I ran into another. And another. And while I know my fair share of JS, and have no problem with async programming, node.js still felt awkward after a month. So long as I was in my own code, I was fine, but reasoning about code I hadn't written was painful not because of the language, but because of the flow it took.

<comment><USER15> Your question doesn't provide enough details for anyone to offer any insight, unless they've seen this exact error before.

From the error, I'd guess that you were trying to insert an email into an integer field. Check the db code in the event handlers, add some debugger calls (you can even step through code using node-inspector), done. There aren't magical solutions to application-specific errors.

<comment><USER24> Well, that's why I was asking for the general case. I couldn't find where the event was being emitted. It was somewhere in the passport code that called my code that implemented an authentication strategy, and it was calling with the email rather than the id.

And I was trying to figure out where the code was coming from in passport. The only tool for that was "grep emit". That's ridiculous.

The problem went a level deeper, but that's irrelevant to the task at hand -- I was overriding the prototype (as per the passport example) and yet my code wasn't being called, and there was some order of execution issue going on with how the initialization was interacting with express, which is when I decided to scrap the code and rethink the implementation.

And for multiple reasons, I'm rethinking that implementation in Scala instead. :)

</comment></comment></comment></comment><comment><USER25> Node is not for everybody. Node is not for everything.

2 hasenj: try using coffeescript to get expressiveness if you're coming from Python(like I do). You'll be much more comfortable with it. Especially when you're using it for both frontend and backend.

Node was a "why not?" choice for my last small inhouse realtime analytics. I could write it in python, but I've been writing LOTS of CoffeeScript recently so I've tried to go with node and redis. And it was a perfect fit for this task.

I'm pretty sure I wont use it for some complex business logic or number crunching. But that's not because I'm afraid to loose maintainability or peace of mind. It's because that would be just stupid, there is a lot of better tools for this. You should keep in mind whats your platform nature, whats it good for.

Every contending platform or language has it tradeoffs. I like ErlangVM features and philosophy, but I can't pass over the language weirdness. And VM speed sucks. And the community is much smaller. Nodejs is booming, you should agree on that.

Go is great, I'm planning to use it for my next "why not?" project. But it takes a lot of things you love in dynamic languages away. You choose between "program performance vs programmer performance". And again, the community and adoption is taking its first babysteps.

<comment><USER15> Except that if you don't really know javascript, and hate cps, coffeescript won't make much of a difference.

</comment></comment><comment><USER26> Looks like the author got upset that he needed to learn a platform in order to use it.

Another issue is that JavaScript doesn't really lend itself to continuation passing style, leading to ugly nested callbacks. There are many libraries that make this more manageable, like async: <https://github.com/caolan/async>

<comment><AUTHOR> I'm upset because I invested a substantial amount of time without really reaping much of a reward (other than knowing to avoid it). I'm upset because there's a lot of unreasonable hype.

<comment><USER27> I find that stretching my head around a new and different paradigm is it's own reward. Everyone's different and has different goals.

If your goal is to implement dynamic web content as productively as possible, no one will fault you for sticking with what you already know and are comfortable with. But it's not valid to conclude that everything else is terrible if it doesn't improve the type of things that you do.

Personally, I've lost count of the number of times I'd wished a blocking API call was instead non-blocking. Do a survey of how many desktop Windows applications are able to exit gracefully while a File->Open dialog box is still open.

<comment><AUTHOR> Stretching my head around functional programming was rewarding. Stretching my head around lisp was rewarding. Stretching my heard around continuation[1] passing style was rewarding.

Stretching my head around everything-is-async was _not_ rewarding. Just because it's different, doesn't mean it's good.

[1]: [http://community.schemewiki.org/?call-with-current- continuat...](http://community.schemewiki.org/?call-with-current-continuation)

<comment><USER27> I agree that FP, Lisp, and CPS are rewarding. I find async IO very appealing because so very often I've had to implement imperfect workarounds when it wasn't available.

But I still feel _really_ conflicted about Javascript.

</comment></comment></comment></comment></comment><comment><USER28> I encountered the same issue. I found the callback oriented programming style to be confusing and overly complex for the sake of a fast application. Although I managed to build something and still work with it, the uses for Node.JS are quite limited.

Want to build a realtime analytics platform? Node has you covered. Want to build a super lean and powerful server for an iPhone game? Node also has you covered. Want to build a web application that doesn't require anything realtime? Not so much.

Node serves a purpose for a lot of things, anything that requires a lot of connections and continuous streams of data it is a perfect fit, but nothing much else.

As for the Python remarks and websockets, I find Beaconpush does the job well: <http://beaconpush.com/> \- the server that drives Battlelog on Electronic Art's game Battlefield 3 is a python framework with websocket support, I believe it uses Beaconpush.

</comment><comment><USER29> Another "mommy I quit because it's too hard for me" post. Why is that tolerated? He doesn't even present an interesting perspective on the technology. "I cannot build cool things with Lego, so Lego is terrible". Yeah awesome.

</comment><comment><USER30> _"I wasted a lot of time trying to learn node and do something useful with it (other than a dumb file server), but couldn't. I just didn't really know where to begin...The APIs might have been documented, but it wasn't clear how to piece things together to make something useful."_

I haven't had this problem myself. To me, piecing together different libraries in Node feels much the same as it does in any other language. You find the libraries via Google, you learn the APIs, and you write glue code to hook them in to your business logic. I'm not sure what would make Node at all different in this respect.

 _"The async-style of programming is almost entirely inaccessible to my brain."_

I'm guessing you're referring to the mess of ultra-deep, nested callbacks that plagues many Node apps. If you just keep nesting callback after callback, then yes, your code will be ugly and unmaintainable. But there are solutions to this. Look into control flow libraries like Step.

 _"So what exactly is your excuse for choosing Node.JS as your backend platform?"_

Here's my main reason. When building for the web, Node can sometimes be far more maintainable than many other platforms. That's because you can share code between client and server. Admittedly, the community hasn't yet settled on a best practice for implementing client-server code sharing. But folks have found ways to do it that work, and you can just pick one that feels good. Sharing code is a big maintainability improvement if you have a thick client that knows a lot about business logic.

</comment><comment><USER31> Whenever I read something like this I always just tack on 'for me' to the end of the title. The article makes a lot more sense if you read it with this perspective. I always did the same thing when a developer would tell me something was too hard to do.

<comment><AUTHOR> That's sort of why I put the "I think" bit on the submission's title.

<comment><USER31> Right, you think that Node.js is a terrible platform _for you_. I'm pretty sure that everyone here would agree with that statement. You really can't make any more general of a statement than that though given your limited experience.

<comment><AUTHOR> I actually would advice that it's bad in general, not just for me.

If node.js works _for you_ , then I'd argue that Go would work even better for you.

If you don't mind losing some of the expressiveness of python/ruby, then surely you wouldn't mind transitioning from python/ruby to Go. And, what's more, Go is _much_ better suited for large and complex programs than Node.js.

</comment></comment></comment></comment><comment><USER32> The async nature of the language and platform is very easily managed with libs like <https://github.com/caolan/async>, I came from Django and to me, once I mastered the async nature and understood it, nodejs was a breath of fresh air.

</comment><comment><USER27> tl;dr: "Node.JS is a terrible platform [because] the async-style of programming is almost entirely inaccessible to my brain."

<comment><AUTHOR> Not only that, but also because there are better alternatives.

If there was no way to do scalable web services or provide things like websockets other than node.js, then my objection would be completely invalid.

<comment><USER27> Look at it this way:

Async event-driven programming is not going away, it's probably always going to be the most performant model because incoming packets translate into interrupts and kernel mode and thread context switches are expensive.

Javascript is not going away, and has become shockingly efficient with V8.

These are both forces of nature in their own respective domains. So somebody's gonna combine them to implement an async IO reactor system in Javascript. This is Node.js, which looks to me like a pretty decent implementation of the idea.

It may not be your cuppa tea, or the best way to implement every dynamic website. It just is what it is: inevitable.

<comment><AUTHOR> > Async event-driven programming is not going away, it's probably always going > to be the most performant model because incoming packets translate into > interrupts and kernel mode and thread context switches are expensive.

That's like saying "assembly isn't going away, because it's the language of the CPU". Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where.

Coroutines are a much better way to write performant network services. In Go, when a goroutine blocks on I/O, it yields execution to other goroutines. You, the programmer, never think about it, because the platform handles it for you.

<comment><USER27> _Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where._

Assembly largely has gone away. It used to be that _all_ serious PC apps were written in asm. Eventually though, C compilers and RAM improved enough to not require that. Today the only things written in asm tend to the absolute lowest-level system routines and a few hand-tuned loops.

But you might also be interested to know that MS embeds the web server in the kernel using async IO (http.sys) and that the WinHTTP client library runs async as well.

 _Coroutines are a much better way to write performant network services._

I agree native coroutines or CPS would better. There are better choices of development language than Javascript, too.

But it's not the tool, it's the hand and the attitude that wields the tool that determines the quality of the result.

</comment></comment></comment></comment></comment><comment><USER33> WebSocket protocol is pretty easily implemented in pure Python; my co-founder and I did this just recently to support some of our game client functionality.

<comment><USER34> Not only is the protocol easy to implement, some Python servers come with WebSocket support. Tornado (<http://www.tornadoweb.org/documentation/websocket.html>) and Autobahn (<http://autobahn.ws/>) are examples.

<comment><USER35> > Not only is the protocol easy to implement, some Python servers come with > WebSocket support.

Even when they don't, it's easy to find. There are both websocket and socket.io implementations available for gevent for instance.

</comment></comment></comment><comment><USER36> Node.js can be made to be plenty writeable and readable once you wrap your head around asynchronous programming. I'd write everything in my life in an asynchronous way if I could.

</comment><comment><USER37> Isn't client side Javascript programming also async event-driven in the exact same way as node?

Why isn't anybody whining about how terrible this is when writing client side Javascript?

<comment><USER38> Because when writing client side js, you don't have a choice.

On the server, you can do whatever you want, and you're free to choose something better.

<comment><USER37> Yeah but I've seen several people who tries node dismiss it on the grounds that this programming style is immensly complex and incomprehensible. In this guys words "The async-style of programming is almost entirely inaccessible to my brain".

I just find it contradicting then that every man and his dog seems to be able to whip up some client side Javascript which works in the same way..

</comment></comment></comment><comment><USER39> Funny, I think Python and JavaScript about even in the amount of syntactic sugar (programming shortcuts) they provide. They both have some little things that the other doesn't have, but overall there is nothing that makes me think python is preferable to JavaScript (except perhaps older and more mature libraries for server side code, don't know about that).

No comment on the callbacks - I suppose you don't have to use them if you don't want to.

</comment><comment><USER40> People love NodeJS is because it's JavaScript and Async. If you don't like both you are not in the NodeJS boat.

But don't blame it. Everyone has their choices.

And NodeJS is not a general purpose stack and It never says it is like that.

When you need to do some nasty app with lot of IO and you don't need to learn erlang than NodeJs is for you.

Haters are always there! Who cares?

</comment><comment><USER41> Nose.js is a great platform , but not for YOU needs. You don't like Node.js, so you won't like Twisted and Tornado in Python too. The thing you hate is not Node.js, but it is its approach. And the reason is, that it is not designed for YOUR needs. That's all.

<comment><AUTHOR> What is it designed for?

It's being hyped as a platform for writing scalable web applications. Not simple networking tools or little glue utilities, but large, complicated web apps that people have been using ruby and python to develop.

<comment><USER42> to be honest, I think one of the key issues with "javascript" and "fast" in the same sentence. (yeah, this reply would be better beneath you, but HN says I can't reply to that guy.)

The reason why NoeJS is "fast" isn't JS. It's being event-driven. I also believe JS isn't as easy to work with as python by design, even thus there are zillions of JS coders. Most of the people indeed follow the hype, more than "wait, is this actually something I should use" (you also did follow the hype and got bitten by it, in fact)

<comment><USER13> To be fair, V8 (the JavaScript engine under Node) _is_ really, really fast. Even without introducing any event-driven code. Normal procedural code will (in general) be an order of magnitude faster than standard Python and Ruby runtimes.

<comment><USER43> "standard" run-times .. yeah, right. But try PyPy - same perf class as V8. And LuaJIT - probably faster than V8 - apart from GC. And for GC perf: Erlang does parallel (per "green thread") GCing ..

</comment></comment></comment></comment></comment><comment><USER44> The entire post was an opinionated piece of crap based on the author's opinion that anything to do with callbacks are evil.

I couldn't help but see in the comments that the author states that avoiding callback hell in node.js is somehow different to using the same javascript design patterns in browser side javascript to avoid callback hell. What's the difference?

The author's problem is he doesn't understand JavaScript, so he never had a chance at properly understanding Node.Js and where it's strengths and weaknesses are let alone how to build something in such a way to ease developer pains associated with learning any new language.

</comment><comment><USER45> If you don't like callbacks, you can wait until generators become available or use the likes of fibers today.

I've implemented a number of synchronous CommonJS specs on top of Node using fibers (<https://github.com/olegp/common-node>), which allows me to use libraries written for RingoJS (e.g. <https://github.com/olegp/stick>) with Node.

All in all I'm very happy with the stack I've built - I get the performance and low memory usage of Node combined with the ease of development of RingoJS.

</comment><comment><USER46> Python can do websocket: [http://twistedmatrix.com/trac/export/29073/branches/websocke...](http://twistedmatrix.com/trac/export/29073/branches/websocket-4173-2/doc/web/howto/websocket.xhtml)

I too was interested in Node.js but I don't like the idea of using JavaScript - I simply prefer python for coding. I looked into it, found the counterpart of node.js in python and am happy with it.

</comment><comment><USER47> Someone is making an effort to lower the threshold to my field of expertise, and make it available to a general public.

My livelihood depends on this!

We must divert our energies to repress and quell this enemy. Spread the fear, uncertainty and doubt!

// the node haters manifesto //

</comment><comment><USER48> People fear and inevitably hate what they can't understand especially when they fail to associate with it while others do so easily. OP should learn java script before learning "Node.JS".

</comment><comment><USER49> "The async-style of programming is almost entirely inaccessible to my brain. Certainly not a fun way to write programs." does not equals to "a terrible platform"

</comment><comment><USER50> Offtop: Why clicking your link leads to downloading an application on Nexus7?

</comment><comment><USER51> Everything is terrible unless it fits. Period.</comment>


The world's biggest city in 2030 - <AUTHOR> http://worldbank.tumblr.com/post/138482525341/the-worlds-biggest-city-in-2030 <comment><USER2> I am surprised to not see Lagos [0] in the list.

[0] [https://en.wikipedia.org/wiki/Lagos](https://en.wikipedia.org/wiki/Lagos)

</comment><comment><USER3> It should be noted that the density of Delhi is almost twice that of Tokyo (according to Wikipedia, 11.3k / km^2 vs. 6.2k / km^2)

<comment><USER4> Usually the high density is actually a problem for future growth. For one, there are concerns about the mass of people being exposed to various risks, primarily related to sanitation. Then the high density becomes a problem for further development, because any change involves dealing with more people and problems, making things more cumbersome and expensive. This is where a city like New Delhi "grows" by simply sprawling with slums. This in itself is not that attractive for quality people.</comment></comment>


Battle of JavaScript: The 4 Frameworks Leading the Pack in 2016 - <AUTHOR> http://blog.debugme.eu/javascript-frameworks-for-2016/ <comment><USER2> Yes, these are frameworks which are worth enough to talk about. I prefer Angular but used React as well</comment>


Ultra-Thin Skin Sensor Can Tell How Fast Your Blood Is Pumping - <AUTHOR> http://www.popularmechanics.com/science/health/a18017/skin-sensor-blood-flow/ <comment><USER2> Anyone know what the correlation is between "blood speed" and heart disease, and how this correlation compares to blood pressure vs. heart disease?

If the correlation is equally strong, this device might finally solve the limitation of current wearables in that they can only track vital signs that have poor correlation with heart disease (i.e. no reliable watch-like BP monitor is available yet)

<comment><USER3> I saw this tech presented at Compute Midwest (KC) a week ago and it was mind- blowing. It can do amazing things, including serving as a true EKG. The article seems to focus more on the blood speed measurement, perhaps because that's one of the more novel abilities of the device, but to answer the core of your question - it can already relay EKG-quality statistics about a potential heart condition.

Another exciting capability (IMO) was that they've also experimented using the sensor to emit specifically-tuned electrical pulses from the sensor into your skin, basically triggering a haptic response. So a haptic suit with VR goggles is now in the realm of possibility.

</comment></comment><comment><USER4> Blood doesn't pump. Blood is pumped.</comment>


Google App Engine: Post-mortem for February 24th, 2010 outage - <AUTHOR> https://groups.google.com/group/google-appengine/browse_thread/thread/a7640a2743922dcf?pli=1

<comment><USER2> Original post here: <http://news.ycombinator.com/item?id=1168493>

</comment><comment><USER3> A pretty good write-up about what went wrong. I like the mitigation procedure of implementing recovery drills that "include the rare and complicated procedures"... whoever runs that is going to have a wickedly fun job!</comment>


Could anybody send me a Google inbox invite? - <AUTHOR>

tvvocold#gmail.com thx,i have been waiting too long.
update:no one send me one for now,,,have been waiting tooooo long time. send me one plz! firstname.lastname@example.com (2 'v' not 'w') thx!!!
update:still don't got it!lol <comment><USER2> I have exactly one invite left, and happy to share it. First person to reply to this thread agreeing to terms below gets it:

\- You agree to share at least one of your invites with another user on this thread.

\- You agree to update your comment to indicate which users you sent invites to and how many more you have left.

Update: invite sent to codepeach. 0 invites left.

<comment><USER3> Many thanks sinak!

I've installed on android, and it hasn't given me invites to hand out?! I've also checked on desktop version (win7/chrome) and the same again.

After reading some comments on other pages, it seems im not alone either. Regardless, when it finally does allow me to send invites, I'll send to others in this thread :)

<comment><AUTHOR> u could just go to ur mobile and hit plus button then chose 'Invite to Inbox', type my email (firstname.lastname@example.com (2'v' not 'w')),done,,and thx!

<comment><USER3> ^ have tried exactly that on both mobile and desktop versions, and i get everything else but the invites button (some others are reporting the same thing also). i'll keep checking regularly and send invites to you guys if/when i get invites :)

<comment><AUTHOR> ok, thx

<comment><USER4> I guess we are still waiting!

<comment><AUTHOR> yup

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I have upvoted you. So can I get an invite when you get one? Kindly send it to - aneeska2k5

<comment><USER6> can you invite me please to INBOX firstname.lastname@example.com

<comment><USER5> I have just received an invite. Will send you one shortly!

</comment></comment></comment><comment><AUTHOR> update: maybe u need wait for 24 hours to active the invite button.then send me one plz! firstname.lastname@example.com (2 'v' not 'w') thx!!

<comment><USER4> Fingers crossed

<comment><AUTHOR> lol

</comment></comment></comment><comment><USER4> Google Inbox invites are selling on eBay for over $200.00 :D

</comment><comment><USER7> I would like to have one as well :) juliensansot#gmail.com

</comment><comment><AUTHOR> no one send me one for now,,,have been waiting tooooo long time. send me one plz! firstname.lastname@example.com (2 'v' not 'w') thx!!!

</comment><comment><AUTHOR> updade: i got the invite but i will send u guys invite when i active the invite button after 24 hours(i guess).

<comment><USER5> please send me one to aneeska2k5. I promise to send it to another on this thread :)

<comment><AUTHOR> i don't know, have been waitin for 72 hours ,still cannot saw the invite button in app or chrome...lol

<comment><USER4> Thanks a lot. Got your invitation just now. I will send to others as soon as I get one.

</comment></comment></comment></comment><comment><USER8> Kindly send me one too at usman.azam173

</comment><comment><USER9> angelo.es215 at gmail.com

</comment><comment><AUTHOR> anyone? plz</comment>


ISP injecting "alerts" into non-https webpages - <AUTHOR> https://twitter.com/nictrix36/status/991777770681188352 <comment><AUTHOR> Some more details about their "browser alert service": [https://www.cox.com/residential/support/about-cox-browser- al...](https://www.cox.com/residential/support/about-cox-browser-alerts.html)</comment>


How long does "being in the zone" last? - <AUTHOR>

Just curious... often times, when doing some work, you hit your stride and get "in the zone".
How often does this occur and how long does this period normally last for you guys?
Does it take some distraction - like someone calling, a sudden IM pop-up, etc. - to break it or does it just recede on its own? <comment><USER2> I used to do this for very long stretches, longest I remember is while building a 'softmodem' but I paid for that by nearly falling down two flights of stairs.

The last couple of years the longest I've been able to manage was probably a couple of hours, 3 or 4 at best.

The thing that will get me out of my concentration almost invariably is some kind of sound. When I really sit down to hack I exit (not minimize) all software that might distract me, and I like to work like that at night, which doesn't help because it screws up my day/night rhythm and then it can take me a long time to get back to 'normal'.

</comment><comment><USER3> There is a recent Google TechTalk about using meditation practice to make it easier to get into the zone and stay there longer. <http://www.youtube.com/watch?v=Ky7vMFB4iAs>

I make no claims about the effectiveness of the technique. Anyone have first- hand experience?

<comment><USER4> Here's another techtalk, again by Shinzen Young: <http://www.youtube.com/watch?v=8XCWP4pODbs> The technique is called Vipassana meditation, according to his website.

I've been doing zazen for a little less than a month. Zazen is a little different from vipassana(with wich i have even less experience than with zazen, as i said, less than a month). I chose zazen mainly because it sounds so simple: sit with your spine straight up(in the lottos position if possible, im not there yet, im too inflexible) breathe normally and count your breaths for 10 minutes every day, no magic Indian mysticism involved, which is what threw me off Buddhism the first time i encountered it.

<comment><AUTHOR> What were your reasons for turning to zazen/vipassana? Was it to be able to concentrate better? Or were the reasons separate and an increased focus was an added benefit you noticed? Meditation definitely helps a lot - I have seen it do wonders for a family member's depression where medication did little.

</comment></comment></comment><comment><USER5> I find a strong correspondence with physical health. Some health issues severely limited my prior ability to "get in the zone", let alone stay there. On days when the physical symptoms receded, I could do so.

Actually, this was one of the most frustrating aspects of the health issues.

If you have trouble concentrating, do not overlook or discount your physical health.

A separate comment. For me, personally, it can take an hour or two to really get into the zone. That can be a challenge. Once really there, distractions fade into the background and I can work a good 8, 10 hours, until outright exhaustion overcomes my concentration. I may take some breaks, sometimes just to walk around by myself. Actually, this can aid the overall process. I stop the conscious concentration and heavy (in my work, typically) visual input. A walk, maybe a cup of tea, etc., engages my other senses and different sensory processing. The work remains in my subconscious, and not infrequently, the change in attention allows me to make subconscious progress that I might not have achieved or so readily achieved through conscious attention.

In such a state, I don't just consciously, step by step, put "pieces" of information and steps of processes together. I tend to form an increasingly developed "Gestalt" of the material and my ideas, and new ideas and relationships reveal themselves as my overall attention (conscious and subconscious) continues to analyze and infer. It's one of the more enjoyable sensations of living.

Until I get deeply into that mode, interruptions and distractions can be quite disruptive. Once I do get there, sometimes -- blessedly -- they fade into irrelevance.</comment>