You're basically saying that we should let the guys in the warehouse manhandle 500kg loads by hand because they "prefer" not to use the forklifts. We should just let them do whatever they please, because that's what makes for good management, right?
Good management advocates what makes folks productive that meets whatever production levels and goals are required for the business. Having someone manually handle 500kg loads is obviously inefficient, left alone the safety and liability concerns it raises. Warehouse operations requirements are different than software development operational requirements.
It's not even a good idea to let developers pick their favorite IDE either, because there are productivity gains to be had from consistency.
It depends on the project and personnel. A core problem I have with mandated IDEs is can cause undesired dependencies in the software build and packaging process. When I have the responsibility of setting up a software project, I make sure that the software can be built and packaged independently of any IDE. I cringe when I am on project that states you need to run this given IDE to build the software.
IDEs have their own quirks and bugs, some not that obvious. When IDE mandating exists, it promotes a blind-trust mindset on the tool, and when it is the IDE that is the source of a problem, it can consume many wasted hours of development time. When IDE "magic" goes wrong, it can go horribly wrong.
I advocate what makes the project most efficient. In some environments, have a single IDE that everyone uses may be the most efficient overall, but management must be aware that it can cripple more senior, experienced developers that can be more efficient than the IDE (hence, my base goal of the software being able to be built without the IDE). Compare the typical mindset and capabilities of a developer that has solely operated in IDEs vs those that have functioned outside them.
A good test on the skill level of a programmer is how well they can make code changes without using an IDE. In a project I have control over, I had to setup an Eclipse project because a new person management hired struggled a lot working with the project source since they mainly used Eclipse in the past. Unfortunately, that person could not set up the Eclipse project themself, so I had to do it so the person can become productive. The lesson: IDE mandating can restrict the flexibility of the developer, and when that developer moves on to other projects with different environments, they are very lost. IDE mandating may be good from a management perspective, but it can have negative impacts from a developer's perspective.
I have used IDEs (Eclipse, Netbeans, and many moons ago, even Visual Studio). But they have never been my primary go-to tool. I use them selectively when they provide something for me that is more efficient than my normal working environment (Vim and a Unix-based shell and tools). On average, IDEs slow me down, and I have never had a single complaint from management or colleagues on how I work. I normally out-perform all other team members and whatever tools/IDEs they choose to use.
One last comment: When working on projects that utilize a variety of technologies, a single IDE will sometimes not be able to adequately support all of the technologies. Hence the need for flexibility and the primary mindset that a given project is never dependent on a single IDE.
The patent in the article is much more narrow than just sending a URL through an email. A key concept mentioned in the patent is that the email (plaintext or html) contains an URL in some form
The term "URL" is not used in claim 1. Basically, anything that specifies a location of a resource, so limiting yourself to a URL-only based mindset will make it hard to find any prior art before the patent date.
I actually use mharc, http://www.mhonarc.org/mharc/, on my private server to archive various public lists and work-related email since it provides searching capabilities.
For work-related email, I have nmh folders I file message to for the various projects I work on and then have a cron job that runs each night that uses mharc's mh-month-pack script to copy the mail into mharc's archive area.
This system provides me an MUA-neutral way to read and search email. Since mharc keeps an mbox formatted version of all data, I can import the messages to any MUA I want, however since I still have the nmh folder data, I've never had the need.
The other advantage of my setup is I can following mailing lists w/o cluttering my inbox. I have a separate mail account I used to subscribe to lists of interest, and I archive the messages on my private server for reading and searching whenever I want.
Plus, you can define your own auto-proxy configuration file that blocks ad URLs. Therefore, when Yahoo changed there mail interface awhile back to be more "ad friendly", it did not really affect me. Though, I did get larger blank areas where big-assed ads should be.
BTW, for mozilla, the auto-proxy can redirect to a non-exist host:port to quietly drop ads in case you are unable to run a server to absorb ad proxy redirects. This works for my mother's PC where I did not want to mess with running a web/proxy server on.
Every little picofarad has a nanohenry all its own. -- Don Vonada