ipads are most useful if you want to consume content. Not much to experiment with them, at least not with the Ipad itself.

3D printers are tools, awesome tools. They have nothing in common with Ipads, you can do stuff with 3D printers. Think of them as the logo turtles of today. They show kids a tangible application of programming, physics, math.

Teachers have the opportunity to choose to use that for teaching, or just let them tinker with cool stuff.
  And I mean single teachers, they can just print a mechanical assembly, or an atom model, or a dna model, a geometric shape . With already existing, easy access easy to use, and most importantly, easy to share tools.

Compare that to the authoring you can do with an ipad (or a classroom full of ipads) by itself. You _might_ be able to sketch something, but the tools are just not there, or available.

Lost of people seem to be happy with adblock.
Think of it as as server side adblock, at the very least.

Also, with responsive design and everything, this would be a problem, but not a big one.

Are you sure?
It's hard for me to imagine an awesome CS person who struggles at math. CS is mostly math, or pretty close. Computability, regular expressions, automata, formal proofs, all of those are needed, in my book, to be awesome at CS, and I think you should be at least decent at math to grasp those.

There is a way to expand the model to the internet.

Say you pay a youtube subscription, and you get ad-free youtube, and for the same price, or for an additional, you get ad-free adsense.
That means you won't ever see an adsense ad again. The sites will still have the adsense code, and google will just micro-pay, based on your usage of their site, from your subscription money.

Doesn't look like a bulletproof strategy to me, but something like that might end up happening.

Additionally, those who don't use adsense would be at a disadvantage, because youtube subscribers won't be able to make ads go away.

Of course, the privacy implications of all this are huge, because you would be essentially logged in everywhere, and that's another service that google would be able to provide.

So it's not stealing. It's something else.

And you might want to get your analogy checked, I don't thing it holds. Maybe if it was potato soup + recipe or something like that. In any case, no need for analogies. It's easier to get it without them.

They are not stealing anything from anyone. The users didn't have any source to begin with, for example. They are not entitled to the source. The problem lies in the other end. Ubiquiti is licensing some code, and not complying with the license, by not providing source. This means they are not covered by the license.

This is plain, simple, copyright infringement. Not stealing, something else. And when you do it for profit, most people agree it's a bad thing. At least in the current context.

There's also another bit that I fail to understand.

If the Chinese Firewall guys wanted to DoS github, they could just do it. Playing synthetic traffic against github, for example.
Instead, we say that they hijacked their users computers, so they could generate traffic that in the end would have to go through the firewall.

From the firewall point of view, that wouldn't be a DDoS, because the attacker is always them, no distribution happens. It doesn't make sense, and it's a lot more work than just doing the DoS attack themselves.

Of course, MITM is something they can do, they might be doing that kind of thing, and hijacking clients computers for other reasons, but for this attack, it doesn't make a lot of sense.

In any case, you would need Amazon to actually enforce it.
While they do have more money for legal fees, they would risk a big PR issue if they tried to prevent some guy from working at Walmart after quitting Amazon. Also, the first guy with such a problem wouldn't have a lot of trouble finding someone to help them with legal fees, if only for the publicity.

This is probably just a scare tactic, to discourage people from leaving them, it is unethical, but not really enforceable.

Does that manual encourage bad code ?

The second one should also include "immutable". If it's hard to understand it will evolve easily to non working, and time spent on improvements can start to creep up very fast.

I have worked in very clever, solid code, but not easy to read. It was then maintained and extended by average, but competent programmers down the road, and turned into a big mess, only because it was so hard to understand.

In my experience, good code is easy to read, above all. That will make it easy to extend it coherently, find bugs and stuff. Also, if it doesn't work OK, it's easy to find out why. The single metric that saves time, money, and improves quality down the road is readability. Eveything else should be suject to that.

And, about the last point in the "article", "efficient", it's nonsense. Premature optimization is the root of all evil. You should _always_ follow the second rule of optimization (see http://c2.com/cgi/wiki?RulesOfOptimization ).

PHP can be good or bad, like any other code. Lately it's getting better.
As an example, do you think this looks bad? Looks pretty good to me.

  https://github.com/symfony/sym...

I have some awful, unreadable examples I could share in Java, PHP, Javascript and even C, but chosen language no longer forces you to write bad code. Maybe Perl, but I haven't seen it lately.

"OS" mentality is that it will be done when it's _done_. Not when it's _right_.
And it's tautologically true. You don't need management to change their mentality, only to _accept_ reality, and act accordingly. I know it might be too much to ask for, but it's not too much to ask.

While it does make sense to have a roadmap, release dates for new software are too often wrong. It's a good thing to keep yourself honest about expectations, and drive the development process, so you can get quality stuff, in reasonable timeframes, providing the greatest possible value.

Unrealistic expectations and pressure on estimates won't help you get there faster, or better. Being realistic will help your team improve estimations, and also help you complete stuff faster, and better.

You are right in your assessment, but there should be a solution for that.

Time and materials contracts can take care of the issues you are talking about. You can reject a pull request, but still pay for the hours.
It's a lot cheaper to pay for the hours than to fight over them. If it's an employee, help them get better, refine your specs, or maybe move them or replace them, if they are not fit for _that_ project. If it's a contractor, change contractors if they are bad.

If you are contracting software development, it's always better to assume some risks yourself, because that keeps your providers focused on helping you reach your objective, and not contract stuff. If you don't want to take risks, you shouldn't be developing software in the first place, but buying ready-made solutions.

.

I don't know whether what he says is true, but beggars are not a typical sight in communism.
In a communist state, they would either not get much gain by begging on their streets (think Cuba, at least when foreigners are not involved), and or be thrown in jail by doing it (like what they say happens in North Korea)
Also, political leaders enjoying luxury goods and meals is the norm in most countries, communist ("real" or not) or otherwise.

It's not that common for companies to have principles to begin with, tough.

Currency black markets are not "unconfortable", they are _illegal_. I'm sure there are examples of censorship in Venezuela, but that's not one.