jaawn

However, I disagree with the author on the specific point of how CS curricula are preparing students for "real life" development. The issue is not necessarily that there are specific tools students aren't being exposed to, it is that they often are not exposed to certain classes of tools at all (such as source control, deployment/build tools, etc...)

There is an excellent post on Coding Horror that covers this: http://blog.codinghorror.com/how-should-we-teach-computer-sc...

Right now, I don't know of anyone who has limited spare time who would risk trying something unknown just because it shows up in their Netflix recommendations. If Netflix got those right frequently, people would rely on it more and probably enjoy it more. A 10% increase in accuracy has a decent chance to push beyond the invisible "good enough to trust" threshold and create an experience other streaming services just don't have.

There are always exceptions, but they are just that: exceptions. The existence of an exception or outlier does not disprove what generally holds true for everyone else.

What you are saying might be true if most hiring was done by CEOs and not department managers.

If most companies were transparent, employees would be a lot more knowledgeable about what leads to more pay. I think we would see more negotiation and engagement and healthier conversations about money. People would be upset at first, but once we start collectively understanding the legitimate reasons for pay discrepancies, and we eliminate the illegitimate ones, I think most people would be happier.

I think most of us probably work at a company that discourages salary transparency (most people do in general). I think we could have a more valuable discussion about how our experiences compare/contrast to the content of the tweets, and save the "omg a bunch of tweets are not an article!" comments for when someone writes a blog post about that and shares it on HN.

However, the resolution is pretty simple. Employees can either accept the justification given by management or not. If they are disgruntled about it, they can try their luck at a different employer, or use the information to learn how they can get a raise. This last point is one of the benefits for employees—they learn what would get them more money at their current employer.

Example: person 1 makes 15% more than person 2, and now both are aware of it. Person 2 is upset and talks to their manager. They find out the reason is because person 1 has additional education/certification and a couple years more experience. Now person 2 knows they can pursue the extra education/certification and use it as leverage to get a raise, when prior to the transparency they would have had no idea and possibly gone awhile longer making less money.

I think, given what I've seen so far, women are given less leverage to start with, they are subject to the chilling effects of gender biases, and they are discouraged from negotiating more often than not.

Sure, a woman can overcome these obstacles, but she shouldn't have these extra obstacles in the first place. The "pay gap" is almost certainly not due to managers thinking "oo I'll pay her less because she's a woman," but it is still indicative of some (more complex) gender inequality.

I work at an enterprise with ~5,000 employees, and attitudes toward topics like transparency vary wildly, even in cases where there is an official company stance. This is because it is common to give managers a lot of freedom to manage their departments without interference. So, for example, our company has a pretty good work-from-home policy, but your manager is completely allowed to ban it in your department if he or she feels like it.

Basically, it is possible that both sources are mostly accurate, and they represent the perspectives from different parts/levels of the company at Google.

I am not applying any overly austere morals here. I think you would be hard-pressed to successfully argue that an affair in the traditional sense is not an immoral act. If you promise to be "faithful" to someone, and you break that promise and try to hide it, it is immoral based on most people's morals and understanding.

Sure, you might disagree with popular morals, that's fine. However, a relationship involves two people, and both should be valued equally. If one person thinks it is fine to break their promise and cheat in secret, so they do it despite knowing how the other person feels...they are putting themselves first. They are not treating both they and their partner as equals. That is the issue. It has nothing to do with some sort of ideological anti-affair "beliefs." It is simple respect.

I guess it is even technically "fine" to think you deserve more liberty than others, or that you think others' feelings don't matter as much as your desires (I'm not saying you do, I'm speaking generally). If that is the case, just own up to it and people can choose how to react accordingly. If you find partners that align with your views, great, everyone is on the same page, but if not, people deserve the truth. Everything else is up in the air, but they deserve to know. Keeping it from them is like robbing them of the choice to deal with it or leave.

Basically, it is irrelevant if they "should" or "shouldn't" be harmed, most of them will feel harm once the affair inevitably comes to light. I don't really agree with it, but even if it is irrational to feel harmed over an affair, and even if it is based on self-referential beliefs, people still feel the feelings, and those feelings hurt.

If the cheater knew those feelings would probably happen, and they already promised they would not engage in the behavior, and then they do it anyway...in secret...that is obviously wrong by most people's standards. There are a lot of important "if"s in there. Notice that I did not say that having multiple partners is harmful, or that leaving a partner is wrong, or that it is "always wrong" for someone in a relationship to go off with someone else for awhile. I did not say any of that.

However, when the relationship is a committed relationship, in the most common, Western, traditional sense, it is wrong to have an affair, especially a secret one. If you disagree with that kind of relationship and commitment, that is totally fine, but don't promise that to someone, and if you change your mind be up front about it.

I think the simpler explanation (and likely more accurate one) is that in most cases, each AM user has at least one partner which is being harmed by the user's actions and use of the site.

Being accepting and tolerant of different types of relationships and desires is a separate issue. The site was created for, and is marketed towards, people who want to cheat (in the traditional, harmful sense) on their current partners.

In this case, if discovery and release of the data would be something you don't think you could recover from, I think that is a good indication that maybe the data is associated with something that isn't worth doing.

Basically, there are a few truths we know about users of the site: 1. They are in a committed relationship (or seeking someone who is) 2. They are unfulfilled. 3. Those in a committed relationship do not want their partner to know about their activities (because it would hurt them)

It is the 3rd item that changes things a bit with this specific site. The unaware partners should be valued as much as the users of the site, but the site enables its users to put themselves above their partners in a way.

It is perfectly valid to criticize monogamy or to support equal treatment for people in different types of relationships, but Ashley Madison is built to help people indulge at the expense of another "innocent" person, and I think that makes it not okay. I don't necessarily think the hackers are "justified," but I do think it is understandable to feel less sympathy for the victims in this case.

I think the basic assumption has been that, even though we know the total number of "impressions" is exaggerated, the number is correlated with the "real" number. So long as that assumption is usually true, this is no more a case of fraud than Airlines' reward "miles".

To be fair though, larger clients who blanket the web with ads for a campaign have the advantage of spreading the risk over a large number of websites and times. The people most impacted by impression-based ad runs are those who can only afford the smallest campaigns.

If ads were usually like this, instead of resource-heavy Flash ads or ugly AdSense ads, I probably wouldn't use any ad blocking software. Static image banner ads are probably the only online advertising I have ever clicked or taken notice of.

If OAuth is not for authentication, someone better tell Google: "Google APIs use the OAuth 2.0 protocol for authentication and authorization." [1]

TLS is basically just the newest version of SSL. The name was changed for legal reasons. So it is an understandable oversight [2]

The others aren't security related, so I didn't address them.

[1] https://developers.google.com/identity/protocols/OAuth2

[2] http://security.stackexchange.com/questions/5126/whats-the-d...

(edit: this is an explanation of what "middle-brow dismissal" is)

I challenge you to point out specific suggestions in this article which are wrong or misleading, or to point out glaring omissions.

If your argument is that the String implementation change constitutes "unreasonably poor performance," as in...for most normal use cases, then that makes sense. I disagree with it, but it makes sense to argue that if you think that is what's happening. That goes beyond the implementation vs. contract discussion, and maybe that is the real issue many people have. Maybe some feel like the performance hit will affect so many use cases that are common for String, that it is an unreasonable performance change.

It is similar to sorting implementations. If you have a small list of items in a collection, you might not care about how fast they can be sorted as long as it is "reasonably fast," so you can just use a built-in sort() function. If you know your collection will likely be larger than most, or you need them sorted as fast as possible, you might choose to implement your own sorting function, or use a different library which specifies a given performance level.

You could just use this hypothetical, built-in sort() for now, and deal with it later if any issues arise, or you could plan ahead if it is important and future proof the code now. The former would be "proceeding with caution" while the latter would be the more maintainable, "best practices" approach when you know performance is higher priority than normal.

If you "proceed with caution" you might run into a situation where the maintainers switch from insertion sort to heap sort, because in many (most?) use cases, heap sort is faster. However, your collection is often already sorted or mostly sorted, which is a case where heap sort performs much worse than insertion sort. Now your specific application has worse performance, but other applications have improved performance. If your collection needs to be sorted at a specific performance level, it is better (but not required) for you to implement a custom sort function, or use a library that is designed for your use case. This way you can have appropriate control over the performance.

So, if you are implementing something that deals with a large input string, and creates a large number of substrings, you know there could potentially be a performance impact depending on the way the implementation works with substrings. The API makes no performance or memory guarantees about substrings. If your application has strict performance requirements, you know you either need to find another solution, or "proceed with caution."

The description in the Java 7 API for substring is "Returns a new string that is a substring of this string." That does not suggest any sharing with the parent string; it says "new string".