Completely agreed. He can also use his network of (public) contacts to make introductions between threatened enterprises and the right people to fix them - or introducing peers who have had similar issues but aren't happy being completely public about that fact yet both trust him to use that knowledge for their benefit. Getting your security vendor wrong could be a very expensive mistake.

You need to talk to a better attorney then (if you're near Austin I can recommend Tom Nesbitt - IANAL but I do consult with them when I have questions like this). Even in Texas there's a long list of things that a company has to do in order to enforce a non-compete clause including but not limited to showing that your actions caused them real harm. I prefer to follow both the letter and the spirit of those agreements, but its always good to know how much is actually enforceable.

Your current company does not have the right to take away your future livelihood.

One thing that I enjoy about both modern development and enterprise development is that - when done correctly - you can actually do both. With task oriented design rather than data oriented design, each workflow can be exactly as simple as it can be and as powerful as it needs to be for every situation. Its harder and more expensive to build this way, but the savings in training and support can more than make up for it. Convincing people of that fact is part of the reason that a good enterprise sales team is expensive.

Even better - tell your lawyer. They have whole teams of people dedicated to solving this problem. Let them do the job that they're experts at and stop worrying about it.

Yup. And when you give them money they may spend it on hookers and blow - or even donations to the Heritage Foundation or Greenpeace. You'll be dead. Once you've passed on the data and what it represents, its truly not your problem and no longer your concern.

If it bothers you that much have your lawyers set up a trust instead. Again, let experts be experts.

Indeed, that's the whole point - swapping limited protection in exchange for permanent education. Somewhat akin to the goals of the OpenSource movement on steroids, if you think about it.

In theory, at least.

No need to raise fees by the way, simply keeping the money the patent office charges in the patent office rather than using it as a generic profit center would more than take care of the staffing and backlog problems.

That's just it though. You can patent a fan if its novel in some way. You cannot patent the idea of a thing that moves air by spinning a wheel with blades on it.

Traditionally, software patents have been far closer to the latter than the former.

Honestly, I'm no fan of software patents, but that's as silly as claiming that if you weren't advancing the art of blacksmithing that you couldn't patent a complex and novel piece of machinery made out of iron.

That'd be just fine IMO. Most software patents show vague pictures of the inputs and outputs of those transformations, and then claim to have patented the transformations themselves. Its as if the cotton gin patent simply showed cotton growing in fields, then t-shirts, and had a large box in between them that was patented under "a method for transforming cotton from its natural state," which was then used to attack the loom.

The two things that can make slide to unlock physical are the rough specifics of the action (size of slider, size of track, visual/tactile feedback, etc) or the specific code approach used to implement it. In each completely separate case the process patented would have to be novel. The notion of a specifically designed sliding motion to unlock the phone probably was novel - the research that went into coming up with a method that was natural and yet almost impossible to happen unintentionally was not insignificant. The idea of taking a generic action because of a sliding your finger in any way over a phone is not patentable. Using a substantially different sliding method to unlock a phone would not violate Apple's patent either.

Think about simple physical patents for a second. You can't patent the idea of a bladed fan, even the idea of using one to cool a computer. You can patent a specific complex design (xx blades with different thicknesses and pitches) that produces a specific response (less noise, less space, more cooling), but in doing so the patent also has to be specific enough for someone to reproduce your invention once the patent has expired.

Rewrites often work well if the original goal for the software has morphed over time, so that its overall structure just no longer makes sense. In other cases codebase does contain a ton of good tribal knowledge that's often lost and has to be relearned during a rewrite process. Confusing things is the fact that in many areas the tools available to developers now (libraries, etc) are far more powerful than they were even 4-5 years ago, so removing code that isn't necessary to meet a business need can really help.

tl;dr: its complicated, and it all depends.

The same thing would happen if you'd tested on an iPhone 5S and then your users tried to run it on an iPhone 4. Is that their fault also?

Odd to hear this from you, since we deploy many apps written extensively in JavaScript, but do go on.

Aha! Sounds like you had slow code in one language and replaced it with slow code in another language. FWIW, there are plenty of free JS charting libraries that run really well generating complex charts blindingly fast even on very old iOS devices.

What's that saying about a craftsman blaming his tools again?

I'm with you on Windows and Linux. OSX has been doing this natively, with no blurriness, since they first started shipping retina laptops. It really is amazingly nicer than the old low-res screens. Source: been using it personally since 2012.

What, both of them?

The simulator is very useful for developing all sorts of apps. The fact that it didn't work well for yours because it was hiding some poorly optimized code doesn't mean that a huge majority of apps don't benefit from it.

Most apps in the app store are not the latest and greatest video epic.

If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well ... that's not the simulator's fault.

Its a good thing that C never encouraged fixed-width record constructs...