Hacker Newsnew | past | comments | ask | show | jobs | submit | more yellowbeard's commentslogin


For what he did that was a slap on the wrist. He committed the most boneheaded act of blatant securities fraud the SEC has ever seen.


Good point, this seems like a case of survivorship bias. However, I think it does seem to show some sort of upper bound on the level and pervasiveness of sexism? That it's at least _possible_ for women to achieve at the highest level in these fields means sexism didn't stop everyone.


But these women did not experience sexism. Of course it wouldn't stop them.


Great point, if this is the case, huge attack on Amazon.


Is it really though? I doubt a large percentage of Kindle users actually go through the trouble of sideloading gapps.


Plus I bet Amazon would welcome this if they did. Just more users for Amazon's own app store and ecosystem.


Or if Google comes out and starts restricting more things, it just might result in users choosing other Android options. Samsung tablets are an option.


I think the original quote is "The stock market has forecast nine of the last five recessions." 1966 https://en.wikiquote.org/wiki/Paul_Samuelson But the idea probably applies to most predictions :)


The bank only has to have a very small percentage of the money they loan you. Most of it is created at the time of the loan.


Exactly, the bank is not hurt from money devaluating when they don't have to do anything for it but create a dept in their books. Sure, what you will pay them will be less in 20 years but it more than the nothing they had before...


Monthly actives is generally the primary metric and it's not so easy to calculate.


Quote from http://money.cnn.com/2017/10/26/technology/business/twitter-...

"These third-party applications used Digits, a software development kit of our now-divested Fabric platform, that allowed third-party applications to send authentication messages via SMS through our systems, which did not relate to activity on the Twitter platform," the company explained in its earnings report.

Really seems like something they should have caught earlier.


Do you mean it’s not easy to define? It shouldn’t be difficult to calculate any particular metric going forward, but it’s inportant to define what it means to be “active.”


Calculating these metrics at scale is not trivial.


In real time, yes.

But the user database should already have backups, importing those backups into an analysis server should be easy, and running queries like that on an analysis server should be easy.

Counting messages, or users with X messages, etc. is also largely a function of whether your backup/restore system works. But this time you do it in chunks.


I helped build Twitter's data platform, 2010-2016.

There isn't an "analysis server" and analyzing user activity is not done on a "user database backup" at Twitter's scale, though indeed that's a common way that would be done for smaller businesses.

By the way, if by user db you literally mean the db with user accounts, that's not the right data source -- you want the user _activity_ db to count active users, and for high-scale applications, those are different things. Presumably user activity updates are orders of magnitude more frequent than user object updates. You don't want to thrash your user db by constantly updating some "last seen at" field. Put that stuff somewhere else.

That said, it's true that counting is simple, it's just a Hadoop / Spark / distributed computing platform of choice job. Filter, distinct, count. It's not even hard in real-time if you have enough ram or are ok with approximate counts with bounded error, thanks to Storm, Heron, Flink, etc.

Defining what exactly constitutes an active user and catching edge cases such as this Digits thing is where things get tricky; the number of weird scenarios that cause under/overcount for what seem like reasonable and straightforward definitions would surprise you.

@baddox nailed it.


Thanks. Note that I wasn't trying to guess at what twitter does, just to provide a workflow that should be viable almost anywhere, in the absence of easier options. It's good to hear that the underlying idea of "calculating the metric isn't the hard part" is true.


Oh, fair that that would be a more important metric, but when they said "user base" I incorrectly assumed they meant "all registered users."


Any chance you can share the name of the company where you work now? Would love to know.


I don't think the data supports your assertion. Car drivers injure and kill a couple orders of magnitude more pedestrians in NYC than cyclists do.


You're unlikely to report every time a bike runs into you. Most of the time you won't even be really injured - just some bruises and pain. That's not big enough for statistics, but it still sucks as an experience.


My guess is that's the same for cars (minor injuries go unreported). It's hard to speculate about unreported statistics. The fact remains that for reported statistics, motorists injure far more people than cyclists, thus I say fear of cyclists is irrational.


Development environment becomes somewhere between extremely hard and impossible to set up. Resign yourself to running tests locally with staging as the only place to test your services talking to each other. This is my experience at a medium size public company on the bay area.


This is common, but it shouldn't be. If you have setup scripts to run each service, or if they're containerized, it's just a little additional work to get to where you can spin them up with a single command.


Docker has been a lifesaver in this realm. If you do the work to containerize each service (non-insignificant upfront cost), getting all your services running on a local box is as simple as a `docker-compose up`.


Looking at the total dollar amount of debt makes a good headline, but is simplistic. With lower interest rates, households are spending far less to service their debt than they were in 2008. The article only mentions this briefly near the end.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: