Agreed that it's not in the summary, but as you correctly note, it's just a "summary". Anyone who reads the underlying blog post will read this among the facts on which the court based its opinion: "The public was allowed to search by keyword. The search results showed only the page numbers for the search term and the number of times it appeared; none of the text was visible."

So those readers who RTFA will be in the know.

Don't I wish.

A cynic might argue that the key difference in this case was that, for a change, the ISP's, and not merely defendants, were challenging the subpoenas; but of course we all know that justice is 'blind'.

An ingrate might bemoan the Court's failure to address the key underlying fallacy in the "John Doe" cases, that because someone pays the bill for an internet account that automatically makes them a copyright infringer; but who's complaining over that slight omission?

A malcontent like myself might be a little unhappy that it took the courts ten (10) years to finally come to grips with the personal jurisdiction issue, which would have been obvious to 9 out of 10 second year law students from the get go, and I personally have been pointing it out and writing about it since 2005; but at least they finally did get there.

And a philosopher might wonder how much suffering might have been spared had the courts followed the law back in 2004 when the John Doe madness started; but of course I'm a lawyer, not a philosopher. :)

Bottom line, though: this is a good thing, a very good thing. Ten (10) years late in coming, but good nonetheless. - R.B. )

I suspect there's a bit of a definition issue at play here (with all fault apparently being on my end, given some of the other comments in this discussion). In my mind, DevOps roles are such only if the "Dev" and "Ops" parts are connected--I.e., you manage operations for the software that you've developed. I agree that there are rapidly diminishing or negative returns otherwise. E.g., if you write some Nodejs web services on Monday and troubleshoot MS Exchange/ActiveDirectory integration issues on Tuesday, there isn't much benefit. In that case, however, I'd argue that you don't have a DevOps role, you just have 2 different unrelated roles (which, as I stated, is apparently a definition issue on my part).

The only part that I would argue with is..

You cannot, in my opinion, "know" the operations side if you have never actually been the operations side. The real question is whether knowing the operations side is worth the effort of being the operations side (at least for a while). In my experience, the answer is unequivocally "yes" (but again, with the caveat that you are the operations side only for the software that you develop, and not for, e.g., rolling out the latest Windows service pack to all users at your location).

I should also clarify that my experience has only been with internal development. The demographic differences with respect to external-facing applications (i.e., user/developer ratios on the order of possibly millions to 1 vs. 10s or 100s to 1), among other things, would necessarily limit the ability of developers to participate in operations.

As you've noted, having to run operations to the exclusion of all development activity would bore you to tears. What that has done is forced me to consider--to a degree and precision that would never have occurred to me previously--how the design and architecture of a proposed solution impacts deployment and operations. Because I did not want to spend all my time supporting the system I mentioned in my previous post, I designed it such that it required about all of 30 minutes every other month to administer, and was easy as hell to troubleshoot in production. This meant a much more complex design, and more difficulty in implementation, but saved me a ton of time on net balance such that I could still spend the vast majority of my time doing more interesting stuff.

If deploying and administering the software that you've developed becomes your full-time occupation to the exclusion of all other activity, then either:

1. You do not actually understand deployment and administration in the relevant environment(s), and are therefore horribly inefficient at it (and would benefit greatly from learning).
2. Your design made it very difficult/time-consuming to deploy and/or administer. This is almost an inevitable outcome if the above is true, but can also occur if the developer has a "not my job/problem" attitude when it comes to deployment and administration, or can be a straight-up deliberate trade-off based on available resources.
3. Both of the above. Or...
4. You are working at a scale or in a domain for which deployment and administration is an inherently difficult problem independent of solution design (though paradoxically in this case it is usually even more important for the developer to understand Ops, because while there may be little they can do to make the hard problem easier, there are lots of ways they can inadvertently make the hard problem impossible).

I essentially have this kind of role within my organization. I design, develop, deploy, and support small to mid-tier systems (e.g., the planning system for a $XXXmio/yr global department, with 300+ direct users) while being one of my own customers, as I am actually a business planner (by role) as opposed to developer. I develop systems as a way to do my "day job" much more effectively. Typical tech stack would be Excel UIs, PostgreSQL data store, and whatever else I need in the middle (e.g., nodejs, tomcat, redis, whatever).

What I've found is that, in general, doing the right thing the "right way" is not worth the cost compared to doing the right thing the "wrong way". By definition, in either scenario, the right things is getting done. What most pure developers utterly fail to understand is that in trying to do the former, there is an overwhelming tendency to do the wrong thing the right way instead.

This is because, as Fred Brooks pointed out long ago--and as the "lean startup" movement is re-discovering today--for any non-trivial novel problem you cannot know in advance what the "right thing" is until you've actually tried to implement a solution. Brooks stated this understanding as the need to throw away the first try, and the lean startup movement is essentially defined by a corollary--you have to figure out how to try cheaply enough that you can afford to throw it away and try again (and again, and again if necessary), while progressively elaborating a robust definition of what the "right thing" looks like by using those iterations as experiments to test hypotheses about what the "right thing" is. Doing things the "right way" usually costs so much in time if not capital that you simply can't afford to throw away the first try and start over, or you cannot complete enough iterations to learn enough about the problem.

Now, I'm not saying that you should be totally ignorant of software engineering best practices, design patterns, etc. What I am saying is that there is a limit to how effective you can be in reality if you live purely within the development silo. Having a "DevOps" role (granted, self-imposed in my case) has been one of the best things that's ever happened to me as far as making me a better developer, right up there with the standard oldies like writing your own recursive descent parser and compiler.

In short, it is commonly-accepted wisdom among programmers (for good reason!) that you are more effective if you actually understand the technology stack down to the bare metal or as close to it as you can manage (even if only in abstract-but-helpfully-illustrative examples like Knuth's MMIX VM), and that this understanding can only be gained via practice. It should be obvious that the same is true in the other conceptual direction through deployment and end use.

I once got asked a question which I found hurtful and offensive, and felt tempted to 'blow up' the interview at that point. Fortunately, I resisted the temptation. As it turns out, the question was his way of introducing the next thing, which was telling me that he was offering me the job.

You can basically interpret it as "I acknowledge your communication". It is meant to convey that they are, in fact, paying attention and wish to communicate that fact, but the acknowledgement is specifically devoid of any communication regarding the interpretation or judgment of the content communicated.

What you are seeing is the effect of the top 10% of a country with 300M citizens competing agains the top 0.01% of countries with 1B+ citizens each.

Given that educational opportunity in other countries is also subject to extreme selectivity, those 0.01% have also had the benefit of superior education not just through the system provided, but also due to the peer environment. A genius in a school full of geniuses must learn to work hard to succeed as opposed to being able to coast on the momentum of inherent advantage. The benefit of developing a good work ethic manifests itself in college where even a genius has to apply themselves consistently (if not strenuously) in order to master the material being presented.

Here's my report on the actual ruling which is being reviewed: 2nd Circuit affirms denial of plaintiffs' preliminary injunction motion in WNET v Aereo

I guess it would take a litigator to notice this, but it's quite unusual that a preliminary injunction denial would be getting this kind of appellate attention.

In the first place, it was unusual for an interlocutory appeal to be granted from the denial of the preliminary injunction motion. In federal court usually you can only appeal from a final judgment.

Similarly, apart from the fact that it's always rare for a certiorari petition to be granted, it's especially tough where the appeal is not from a final judgment, but just from a preliminary injunction denial which does not dispose of the whole case.

Maybe if someone actually spoke the truth while in office the problems plaguing our government would have a better chance of being addressed.

No, but this is probably difficult to understand until you've held or are qualified to hold a position of significant accountability and independent authority. At the level of executive leadership, you have to be cognizant of the consequences--especially with respect to your responsibilities.

Essentially, the problem in this case boils down to the fact that speaking candidly as he is doing now would have destroyed his ability to be an effective Secretary of Defense, as the little cooperation he was getting from Congress and the Whitehouse would have evaporated in an instant. It therefore would have been an irresponsible thing to do while he held that position.

The logic goes something like this:

• - If I am going to prosecute a PR battle with powerful but corrupt/petty/incompetent politicians and bureaucrats, it will do no good unless I win
• - In order to win a PR battle with professional popularity contest winners and influence brokers, I will need to devote all of my energy to the effort. Failure is still probable.
• - Even if I win, is the resulting good still worth the opportunity cost related to the list of tasks T that I have allowed to lapse in the meantime? (hint: the answer is 'no' when T == 'stuff the US Secretary of Defense is supposed to be doing').

The responsible thing to do is to pour your energy into fulfilling your responsibilities. If you do not feel that you can fulfill them adequately, resign (after some due dilligence to ensure sufficient continuity in the organization). Wait a while before commenting on your past position and its challenges, as doing so immediately upon resignation is likely to poison the well for your successor. These are the actions of someone focused on doing the best thing to fulfill the responsibilities of the role--up to and including self-removal therefrom if the logical conclusion is that they are not able to effectively do the job.

If you feel that the role of critic is more important than the role you were given, you should not have accepted it in the first place and instead applied to become a journalist/commentator.