Related:

• 7 Ways To Ruin A Technological Revolution
• Software Patents – More Harm Than Help

While the article is about log4j, most of it (except for the “if (log.isDebugEnabled)” part) still applies even if you’ve already moved to slf4j. I especially like that she enumerates all the various goals that you try to achieve with logging.

This report examines changes in the patenting behavior of the software industry since the 1990s. It finds that most software firms still do not patent, most software patents are obtained by a few large firms in the software industry or in other industries, and the risk of litigation from software patents continues to increase dramatically. Given these findings, it is hard to conclude that software patents have provided a net social benefit in the software industry.

“A Generation of Software Patents” by James E. Bessen

Links:

• Research on Innovation
• Patent Failure (book on flaws in software patents). The first chapter (PDF) contains a lot of insight what might be wrong with software patents and why patents in other industries do work.

Image via Wikipedia

Yeah, you can go to the online config tool for flash and play around with the options and hope.

Or you can use the config file (PDF file; what did you expect from Adobe?).

Try this for starters. It will stop anyone from dumping stuff on your computer to recognize you:

LocalStorageLimit = 1
AssetCacheSize = 0
ThirdPartyStorage = 0
AssetCacheSize = 0
AutoUpdateInterval = 1
LegacyDomainMatching = 0
LocalFileLegacyAction = 0

Kudos go to: Adobe Flash, The Spy in Your Computer – Part 2

Paul Ramsey gives a very nice explanation in his talk: Beyond Nerds Bearing Gifts

It’s always the same story and always the same reason: For a change in behavior, expect a year for it to become a habit. Under the best conditions.

So how do you introduce tests to developers? Here are some tips:

1. When they fix a bug, ask “Are you sure the fix is good? How do you know? Ah, you ran the code? Good. Then run the code once more but from a little test.”

2. When they discuss a new feature and can’t decide which way to go, say “How about you write a test for the feature and then try to modify the code so it makes the test pass. This way, we’ll see quickly which way works better”

3. Write some tests yourself. Make sure they run and if they fail, talk to the guy who made them fail. Help them to fix the problem. The bad solution would be to ridicule them, or punish them. Everyone makes mistakes. The tests are there to help to make less mistakes.

If the tests become another problem in the daily routine, They won’t generate enough positive energy for anyone to bother. Result: Failure.

If you meet resistance, ask yourself: What problem do I solve? Or am I just being religious? Do I test for the sake of testing? Or do the tests make everything better for everyone? Do they reduce stress or increase stress? Why?

All these questions will have different answers depending on your specific situation and the answers will help you to find your solution. Paper can’t think, you can. If some rule (out of a book or from your boss) just doesn’t make sense, then it’s your turn to come up with a solution.

There is just one thing to keep in mind and that’s the goal: Tests must help. Everything else will follow.

Instead you need to get your job done. Then, later (whenever that might be … tomorrow or in a week or next year), you can worry about the bug. Anyone wondering why bug reports are often so bad?

But there might be a pretty simple solution: Java already can dump its heap (all objects) to a file. So what we need is a way to start this dump and add a screenshot plus a short description to it. This gets stored somewhere and when we’re done with our current task, we can return to the problem, analyze it more deeply or just zip everything up and post it as a raw bug report.

Luckily Eclipse is OSS (a.k.a “Nothing is impossible if you don’t have to do it yourself.”) See Bug 304544.

If you need a reason for this (other than plain old common sense), see this blog post.