mic47

Assuming you've got cell coverage (or cheap roaming).

> "Should we spend the first 36.8% of our adult lives dating casually, and then settle down with the first person we find who’s better than anyone we’ve dated so far? That would suggest men start seriously looking for a life partner at 39 — and women at 41."

The problem suggest anything like that. It suggest you should spend 36.8% of dating time (or date count) on exploring, not 36.8% of your life...

Second problem with the blog, that it just produces lot of possible issues, but does not show any example where 36.8 algorithm would fail horribly. Maybe those drawbacks does not matter in practice.

This is more of an old web, and because of bad design: keeping state of the app on server, rather than in the browser (or are you referring to limiting open in new tab?).

But yes, I hate the new web too (sometimes).

Tab in browser provides way better user experience than electron app (or native android/ios app). With website you can to mind-blowing things like:

* Open other part of your app in new tab.

* Open other part of your app in new widow, and have time side by side.

* Open external link in new tab, in the same window (OMG!!!).

* I can send link from the web app to someone else.

* Consistent back button.

* Use browser extensions.

* Have cookies (i.e. I am logged out of most of the things in your in-app browser).

Composers are generally thing that are better in apps, but as long as I don't need to compose complex stuff, web app always wins. And if I do, I'll prefer to use native/electron app only for composing, not for consumption.

> Maybe they are just obvious from the outside looking in when you know how the black hats operate these endeavors.

Or, they are just obvious from the outside when you haven't actually tried to solve that problem, but that solution actually don't work. I've seen a lot of "why don't you just do X" in my career questions, where X is something that looks good on first attempt, but in fact is really easy to circumvent by any blackhat (or it was even tried and it didn't work).

I am not saying that your solution don't work, but without you saying which it is, it's impossible to judge.

Are there somewhere accessible documents where Facebook is allegedly in favor of upload filters, or that they actually lobbied for it? Because only what I see in the article (and some linked articles) is that Facebook admitted that they use some of upload filters (which is not lobbying), or that they prefer cooperation over legislation (which is definitely not lobbying). I probably missed something...

> On the flip side, I'm not sure how important choking it off completely really is to facebook, why get rid of ad revenue if you can pretend to chase the bad guys and keep everyone happy?

It's pretty important. In short, there is no incentive for FB to really keep "bad" ads, "fake" accounts, "spammy" pages and so on, as it creates crappy experience for user. If Facebook would be full of fake accounts, the there would be less people using it, and ads would be less effective (that means less money for FB). If there would be shitty ads, people would use more ad-blockers...

Disclaimer: I worked in Facebook's anti-spam team for couple of years.

No, it's more like a patch. In branch, you drag with you all the dependent changes, while with patch, you have only the actual change, and information which CL -- or PR in github terms -- is dependent.

With branches, if someone updates the branch you depend on, your work is based on stale stuff, and it can get ugly. Just try to do it on github :-)

> Just speculating, but they might just need this information to combat bots actually.

That would be actually quite useful for fighting bots, but I doubt that is the reason.

My guess would be just gathering telemetry to how how API is used, and what type of android devices are there (you know, like to know what you should support and test on).

If you are stealing the parcels, you gotta have to do it casually, or you'll look suspicious.

"why Facebook chose to share the wrong metrics"

Why did you choose to include that bug into your code?

Srsly, people don't choose to make mistakes (but sometimes they choose to do cover up).

Also, there is no such things as "Facebook". Facebook didn't choose, someone inside Facebook either make mistake, or deliberate decision. "Facebook" is not single entity with single agenda and plan, but complex company, with different people optimizing for different things (i.e. security/privacy and growth and ads). There is shared high-level vision, but not every decision is made at single place.

If it works well as phone, then it will be great.

When I do phone call, when someone pick up, I introduce myself and start talking. When I do hangout meeting, everybody first asks "Can you hear me"?

Or the FB's own thing is not ready yet. You might get software update to add FB's assistant if/when they do it.

Or, voice assistant is not the market FB want to compete on.

This is best workflow I've used so far (but usually I had separate branch for really unrelated changes).

difference is that if they keep something from my suitcase, I will know. I have no such guarantees when they access my phone unless I see what they are doing.

That means, that you should expect your device and all access tokens on that device compromised.

No. You own your data stored at Facebook. Facebook just have license to use "as they wish" while respecting your privacy settings (i.e. uploading facebook.tax.xz is definitely not according to privacy settings of most people).

At least that written and TOS or so.

Aaaand it's back (just tried to share it and it worked).

Mayve it has some complicated privacy rules?

Because ot was not network breach (i.e. get dump from some db), but abuse of feature available in the web app (so they had good logs to see who was affected).

Could this be only when you are logged-in to your account in chrome?

I.e.

"if you are logged-in to chrome, it won't delete google cookies because it need it for you to be logged-in to chrome (because of some UX excuse, like user confusion why it's logged-out from chrome).

If you are logged out of chrome, it will delete everything."

If it works this way, I would be willing to give them benefit of doubt, since there is reasonable UX reason to do it this way (given that logged-in to chrome now equals to logged-in to gmail). I personally would expect that deleting cookies will not log me out of chrome.

> That's great, but then it says that in order to improve you need to declare a metric so you have something to measure, and then work to improve that.

You don't have to keep the metric same. Metrics are good when they helps you to measure your progress in particular tasks. They are bad if you marry specific ones for life. If you worry about throwing the baby, setup counter-metric.

I would prefer to use editor as yiu describe. but realitybis that jupyter is something lot of people like, find awesone and want to use. this is something that helps someone like me use what other use, but feel less pain. maybe people on future will start migrating out of ui because of stuff like this.

1 thing. Code review. Even thou notebooks are not meant for production code, it's good to check them into repository to document what you did (let's ignore out of order computation and other horrors), and get feedback on your code / experiment.

Right now, ipython notebook is stored as json, where code is list of json strings (so that you have it line by line).

Additionally, the "WYSIWYG Interface" is horrible in comparison to vim, emacs, idea, pycharm or whatever you are using. What I like about notebooks is being able to present things as experiment: this is the code, and there are the outputs. "WYSIWYG Interface" is good if you want to tweak few things, or if you are starting out.

> "Significant numbers of people are expressing a sentiment through their alleged abuse of the feature, and instead of trying to channel that constructively, the company is devising ways to ignore it."

What's the character of leadership who would unjustly silence group A just because significant numbers of people are expressing sentiment to silence group A? Not sure if not doing what they are doing is actually better.

On another note:

This is not necessarily abuse. Even with no abuse, you can have different definition of fake news, than FB have. In such case, you report, someone at FB reviews, and nothing happens. Having weight on you does not change this. The "leadership" is "ignoring you" in a same way as before. Apart from the fact that it's not "ignoring you". They just have different opinion than you.

Note: I used "you" but I don't think that you necessarily have different definition than FB, if was just more convenient to formulate it this way.

> Really it's more "how likely is this person to accurately flag an article that matches Facebook's internal definition of fake news."

Couldn't say it better.

According to article it looks like it's about marking something as fake news (i.e. how "correct" you are in that). At least that is how I understood it.

I worked for FB anti-spam team, and believe me, nobody trusted user feedback absolutely (i.e. it's good to send to review, but not automatically take down). I guess that with fake news the signal to noise ratio is even worse.

The whole article sounds more like focusing on one implementation details of review queue prioritization (i.e. what is the difference of definition of "fake news" for this user vs Facebook's definition), rather than bigger picture.

For Haskell -> JVM, there is Frege/Eta compiler. You could argue those are dialects of Haskell, but are pretty close. The differences will be around FFI because of jvm

So, you can apparently compile C++ to LLVM-IR, then to Javascript, then to Python and then to C++ (you can do similar feat with C). Wonder if there is a fix point, or it diverges.

Unless the target language is functional language. Actually, prior experience in imperative languages makes it harder for you to move into functional programming language, as you have to unlearn some things.