robinson7d

A lot of people seem to complain about this. Personally, as a user, I'm pretty okay with Facebook not showing every post from every page that I like in my news feed. If I really want to see every post from a page, I have options that are immediately available in the like dropdown of the page (either "add to interest lists", or "see first").

The thing is, in the current state of Facebook, wanting to hear everything that a page writes is an exception. As a user, I'm glad it isn't default anymore.

The problem is a combination of things. One problem is that there's pressure (from several potential sources, sometimes from Facebook's UI, sometimes social pressure from friends) to like too many pages. This has sort of diluted the meaning of a "Like" w/r/t a page.

Another big problem is that pages spam - some to the tune of several messages per day. I expect that most people who "Like" the pages that often get "Likes" (which appears to be largely big companies, bands, movies, etc.) don't actually want to see every one of these posts - they'd drown out the user's "Friends".

It is unfortunate for small business owners that things happened this way. Fortunately, really loyal fans should be more likely to listen to you when you ask them to subscribe to something outside of Facebook, or to do the extra couple clicks of adding to an interest list in Facebook. I expect, however, that some of the "loyal fan" base might be made up of (as mentioned before) people who liked the page out of social pressure.

Yeah, totally. I had not previously read about flattr, but it appears to be exactly what I proposed! That's excellent, and I think that I'll read more about it, and likely sign up. I certainly hope that it doesn't also live up to the bleak outlook that I had.

Reddit Gold is definitely a wonderful solution.

However, I was replying to a comment about a "donate" button on the browser, and trying to keep within the problem that it is trying to solve, which is (at least as far as I can tell) paying for the vast number of far smaller sites that make up the internet.

That might be tricky because you'd have to determine how much "one tip" (/click,submit) is. Even if a small amount was decided upon, I wonder if there would be too much added stress along the lines of "is reading this worth the X of a tip?" Which, also, is hard to know until you've actually consumed the whole item, at which point a lot of people have probably linked somewhere else, flowing their way across the web.

I think that this might be helped if it acted like playlists, or bookmarks, where clicking the button would add the site to a list. Later you can opt to donate to items on the list (or provide a single donation split evenly among everything on the list).

Of course, I doubt many would actually use such a feature either.

I agree with all of those sentiments.

At the same time, I prefer the idea of presenting previous open source work instead of having a group of potential employers agree on a project that they can all judge. One benefit is that the work is less arbitrary, potentially useful for others. Another is it's more likely to be unique than an assignment is. Finally, do I want to work for any of those other employers?

Applying to a group that way would seem odd to me; part of me thinks that choosing companies is important, but another thinks that there's some chance that that's just because I haven't tried it.

Which, of course, leads me to agree that the OP is great as an experiment - it might well be a better solution in many cases. The fact that, in the OP, it's opt-in is a big deal as well. Though I'm still very skeptical of take-home interviews in general.

As others have mentioned, the trade-offs can be pretty complicated. Perhaps the take-home is always better for you, I won't try to argue against your personal preferences, I'm simply going to list a few reasons why it turns out worse for a lot of people.

For one thing, as expected, the take-home questions are typically far larger than in-person interview questions. When you go into the office you're generally asked, in my experience, much simpler questions; you might get a simple FizzBuzz-like starter, and a few slightly more difficult ones. All in, it takes a few hours (Google and the like can be an exception to that, but I'll get to that after - I'm comparing smaller companies right now).

The take-home work I've seen has generally been suggested by the company to take 8 hours, but typically been a bit more; they've been along the lines of build a fairly simple crud (I've had one that was a calendar, another that's a stream, etc.) with a bootstrap-or-similar UI, back-end validations, and unit tests for the initial commit, implement these 3-5 features on top of it in separate commits (tested, also standard bootstrap-or-similar UI, proper validation, etc.) And then, simply provide access to the repo.

At first, this didn't seem wrong, in fact I figured "well, I guess it's a good way for them to see that you understand everything". But it came with several annoyances. For one thing, since each feature is a commit, unless you specifically try to prevent it they can see things like how long each part took; even if not consciously, this makes people try to get the work done quickly, without taking many breaks. It sort of reintroduces the "hard to 'refactor' your ideas during a 45m coding interview" problem. Another annoyance is that sometimes (and judging by other comments here, even often) they don't respond at all. The silence is unpleasant, to say the least. In-person, you can at least try to read tone and facial expressions.

The other problem is one company I applied with threw a 10+ hour take-home without any warning before the interview. So a bit over an hour in their office, and another 10+ later. This is difficult if you're working another job. It's very difficult if you have a couple such take-homes at the same time, and a full-time, in office job. Scheduling a few interviews around work, and other commitments, is pretty feasible, but throwing in dozens of hours of additional coding is more difficult.

With companies like Google, you know ahead of time approximately how long it will take. You can take time off accordingly. The process is known going in, and that's great.

Basically, I think that for many people, myself included, white-board interviews are very stressful and frightening, but not quite as much so as: scheduling lots of extra time around your life, budgeting X extra hours because they take longer than suggested, building out the (much larger) projects, still having the time-constraint/expectancy issues, and after all of that not always even getting a message/comment afterward.

Both interview processes suck.

Canadian postal codes are both letters+numbers as well (formatted AxByCz, where A,B,C are letters, x,y,z are numbers), so UK seems like it would be safe.

Too many or few characters, like you point out as the case for Taiwan, would be the problem.

It may be worth noting that the Nexus 5 came out more than two years after the iPhone 4S (Oct 31, 2013 vs Oct 14, 2011), and as of now it hasn't even been 2 years since the Nexus 5 was released.

That said, it has been less than 4 years since the iPhone 4S was released; they shouldn't be failing yet, and that reflects poorly on the iPhone (as well as iOS) in your case. However, I'm also not yet convinced that the Nexus 5 will be operating well in late 2017 - that's yet to be determined.

Agreed. One example would be that using named variables, particularly set with "default" values, makes white-labelling applications much simpler.

Not that I agree with the sentiment of the article (defaulting with || is usually okay!), but hopefully people reading these pieces, and worrying about such things, are already using strict mode.

One of the reasons that it's a big deal is because of what it means for functions. It helps make named-parameters more attractive, which can help a lot with code maintainability.

Example code: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Additionally, it's nice sugar for module loading, for modules that export multiple values.

It's actually a bit better than that.

You're suggesting a simple view where you look at the average amount people who subscribe to this (e.g. $10/month) service would have otherwise paid, and that if that number is less than $10/month the devs (/musicians) win. This is certainly true.

However, there's the additional benefit that not every user that subscribes will entirely drop their purchasing habits. Perhaps less often, but some subscribers will buy apps (/music) on top of their subscription.

It doesn't feel, to me at least, as much that aesthetic standards have changed in general as much as that they've changed on computers. I'm not certain why, but I'd guess it has to do with various things ranging from screen resolution to font availability to marketing.

On the other hand, the "fun" of fonts like San Francisco ('84) might have partially worn off as computers became more integrated into our lives.

Many currently popular web typefaces have been around for decades. Helvetica, Avenir, Franklin Gothic, Futura, etc.

Your parent likely knows what it means; the message is no longer clear but the post it was in reply to originally said "random note". Your parent was simply a suggested correction, which didn't hold up after the correction was made.

That article actually confirms the 33B "liquid cash" quoted in your parent. The other ~160B is "long-term investments".

It's not a particularly great wrapper (I've had to handle a couple minor issues in a further wrapper directive), but for the two-pickers situation where you want a range, I've recently used https://github.com/fragaria/angular-daterangepicker

Which is itself just a directive wrapper around Dan Grossman's DateRange Picker for Bootstrap https://github.com/dangrossman/bootstrap-daterangepicker

Of course, those have a lot of dependencies, so if the app isn't using bootstrap/moment/etc. it isn't as useful.

I also don't think a promise makes much sense, if we're talking about the same sort of widget. For a "selector", where the whole purpose is selecting a thing, I think that even better than that would be to use ng-model (or something similar). Which nearly comes back full circle to the original $emitting an event scenario, except instead the other side would $watch (rather than $on, and avoiding the emit/broadcast part on the directive's side totally).