I've been running various Windows and Linux OSs in VirtualBox on my MBP since it was new in 2010.

I always assumed the silicone ones were proxies for more traditional rings when the traditional ones weren't appropriate to wear for the situation (e.g. doing heavy work, using power tools, etc.).

It was a common term at the last job I worked. Perhaps it was the Swiss/German influence.

The core products for the company I work for are mainly COM based libraries. I've written .Net libraries of extension methods that help hide the COM ugliness and provide a more .Net friendly interface.

If you make Run an extension method and rename it to IgnoreExceptions for clarity, you can say:

var s = (() => GetString(100)).IgnoreExceptions();

You can go one further and add another parameterized type for the catch's use to only ignore certain types of exceptions:

var s = (() => GetString(100)).Ignore();

This is what's worked for me in a similar situation: lead by example. Rather than say "this is cr@p, we need to change it all", instead work on what's assigned and make changes around the code you touch in order to improve it. Don't talk to anyone about refactoring, just do it in the course of doing the work at hand. That is what refactoring is all about anyway. It's not a separate task. Eventually, hopefully they can see the changes and recognize for themselves the improvement. Then they'll have a template to follow. Improving an existing code base is a marathon, not a sprint.

There are two calculators. One in the new, what used to be called Metro, style. One that's the old one we know and love. Sounds like the key is bound to the former rather than the latter. (Edit: at least this is true in Windows 8.1.)

If you have a dual-head extruder, you can do hard and flexible printing in the same object. For an example, check out some of the stuff James at xrobots.co.uk[^] does with a combination of ABS and ninjaflex. With multi-head extruders, you can do different colors in the same print too.

How about a different option? Leave voting anonymous but require a reason to be given when down voting.

Yeah, I agree. But there are many who prefer it.

AE (like most (or all?) Adobe products) is not available for purchase as a stand-alone license anymore. You can only get it packaged in a bundle with other products for a monthly fee. Pro: lower initial outlay. Con: possibly higher long term costs. They do still have the 30-day trial though.

Jeremy Falcon wrote:

I like After Effects for editing. I know most pros would say go Premiere

Just to clarify a bit... After Effects : Premiere Pro :: compiler : linker AE and PP are different tools in the video editing tool chain. Although, unlike the compiler/linker comparison, they do have some overlap and, for some scenarios, can be used interchangeably.

Before you switch sites, just let them know. That way it's expected, you haven't been hacked (at least this isn't evidence of it :-)) and they understand you're using a third party payment system.

Thanks for sharing your experience using both approaches in two different environments.

Keld Ølykke wrote:

I find it pretty annoying in Java. They clearly made this better choice...

These two statements seem to conflict with each other. If the one approach is "pretty annoying" is it really "better?" And this is reason I raise the question: I have the same conflict internally. Which approach is "better" seems to come down to where you approach the problem from. One day I look at the problem from one perspective and one way seems "better." The next day I look at the code and say "How crappy! This way is better!" What I optimize for changes the context enough to change the answer.

Keld Ølykke wrote:

Another question, is whether to use enums or classes as arguments, but ... that is another question ;)

Yes. Yes it is. :-D

jschell wrote:

Perhaps you misunderstood what I was saying.

Perhaps so. Typically when I hear people refer to "in my (your) experience" they are referring broadly to the sum total of all experiences, not narrowly to the one under discussion. I apologize. As to the rest of our conversation, we're going meta into the importance/relevance of the question relative to other things and away from my original question. I think we view things through different lenses and just disagree, which is cool. Different perspectives provide food for thought. Thanks for the feedback.

jschell wrote:

No it isn't. Which is obvious based on your experience.

LOL. Pretty condescending statement, don't you think?

jschell wrote:

Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'.

Sure, that's one way to measure 'better.' And there are two sides to that bug count: the users' and the implementers'. But there are other measurements of 'better' too: ease of discover-ability, semantic clarity, ease of use and ease of implementation among them. It's these more subjective qualities that I was looking for feedback and opinion on.

jschell wrote:

And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?

Sorry, I don't understand the relevance of this question. Are you still trying to make the point that this isn't important? If so, that's fine. I simply disagree. The floorplan and architecture of a house is just as important as the quality of materials and workmanship in framing, plumbing and electrical work. If any of it sucks, home buyers will look elsewhere. The API of a public library is as important as the private implementation. If either one sucks, users will look for alternatives.

Eddy Vluggen wrote:

Repeating a specific value in a method name, while you have declared an enum that holds the same information would;

Ah, right. I agree, it would be pretty confusing to have the name and an enum both. Sorry, I guess in my original post I didn't make it clear that I intended those to be mutually exclusive options. Thanks.

Interesting. How do you see multiple methods violating DRY?

Thanks for the pointer to Clean Code. I obviously need to go reread that as I'd quite forgotten RCM had discussed this topic.

Other problems, of course. Relative size is a matter of opinion. :-) In this case, the API is the primary way for users to access the rest of the product. It's pretty important.