That means the window's closing on me making a 3D wingsuit video with the intent of making an Occulus Rift wearer vomit! I'd better get cracking!

Sadly it's in Canadian dollars, so all those extra zeros are basically pointless.

I currently use a program that blocks calls not on a whitelist, but I miss the power of asterisk. Being able to turn my cell phone into a PBX system and treating the incoming cellular network as just another channel I can manage would be pretty awesome!

You do not talk about Fight Club in Derkaderkastan!

Zune Man!

That's odd. Everyone who took it had a 100% chance of dying at some point.

Yeah, taken to a US Embassy, hauled off to gitmo for 5 years after which he'll announce that he wants to chop off his dong and be referred to as "Edwina." It's not like we haven't seen that happen before...

This opens an entire new world of free amateur porn and cat videos! It's like the Internet has been invented all over again!

Filename extensions are embedding file metadata in the file name, which is never a good idea. It's a kludgy solution to a problem we had when computers were significantly less capable than they are now. The fact that we haven't already eliminated them is yet another indication of the sad state of original thinking in the current generation of software engineers. And yes I know that the original MacOS let you put metadata in the resource fork of the file three decades ago.

Nonsense! Everyone knows the initial release always has some problems! They'll surely be fixed in Minecraft 2 Service Pack 2!

That's handy. Maybe all those MQ servers I've had to deal with in the past will finally stop having to be rebooted every 3 days, if anyone ever gets around to updating them. I've been firmly in the C++ world the past couple of years and have kind of stopped looking at Java since Oracle started being such a dick about the language. If I pick up a java contract in the future, I'll have to familiarize myself with the new features.

boost::signal2 and boost::bind add signals and slots, too, and they seem more intuitive to use than QT's version. They've also been accepted into the language standard in C++11, though I'm still using the boost versions of a lot of the C++11 stuff for compatibility with older compilers. They make a great addition to library code -- I use signals in data factories to signal the availability of new objects. They're also pretty bulletproof in terms of type safety. The compiler will detect that you're trying to attach a incompatible function at compile time and you can adjust the parameters as you need to with bind. Just don't forget to pass the "this" pointer to objects!

No destructors just kills java for me. Yes, I know you have things kind of like destructors that can run at GC time but they're not guaranteed to. That means I have to rely on the programmer to remember to call close before his object goes out of scope, and he's not going to be able to in all cases. That in turn means he's going to be leaking resources. Which seems to be why a lot of the production MQ servers I've seen pretty much HAVE to be rebooted every three days.

Some time ago I was working for a company that was using Jmeter for functional testing. Don't ask me why, but it seemed to be pretty effective for them. At some point they added an SSH sampler into the mix for it. This worked just fine when you were developing the test and running it from the GUI, but when we ran the test from the command line, it would hang when it should have exited. I went digging around in the ssh sampler code and found that he was closing his ssh connection in what passes for a destructor in Java. This was getting called when the GUI exited, but not from the command line. So the ssh connection would remain open and java would sit there not doing anything, so no GC event could ever take place. Essentially a deadlock with exit waiting ssh to close and that waiting on a GC to happen.

I fixed it by moving the ssh close connection to somewhere else, but it was still rather awkward and would prevent the ssh connection from being reused. You'd have to create a brand new one each time you wanted to use one.

Java seems to encourage this sloppy mentality that you don't have to worry about any resources because the language is garbage collected. If you're going to program in it correctly, it requires as much discipline as C++, and at least as much unit testing. I've met very few java programmers who have either.

Yes. Dynamic binding and loading is ugly and clunky.Errors you don't catch at compile time are errors that you have to write tests for. You know who writes tests? No one, that's who! So in practice, errors you don't catch at compile time are errors your users are going to catch. And then you have to debug through an ugly clunky maze of dynamic binding and loading.

But don't get me wrong. I can be... objective... Ok, look. Back in the day we stood at a crossroads. Do we make our changes to C to make it OO fairly lightweight and mostly retain the C syntax, or do we radically change the entire feel of the language. Objective C went for the lightweight approach. Object instances are essentially just pointers to dynamically allocated memory syntactic sugar for pointers to functions around methods. Very C-like idiom and honestly a pretty elegant method of handling things. If you just want C with objective C is worth looking at. It's one step past maintaining some structs with pointers to functions and maintaining OO and inheritance manually, and that's not necessarily a bad thing.

C++ took longer to get where it was going, but it essentially set out for the strictness of ADA in a C like language. It's much more touchy about types and is geared toward catching as much as it can at compile time. Before they got the STL and the C++11 changes rolled in, it was really kind of a pain in the ass to use. It's big and clunky, has a lot of rules to memorize and its error messages are hideous. But in the right hands, with the right libraries, it can be incredibly concise, remarkably fast and a ridiculously powerful tool. In my opinion, one worth learning.

In either case, the first thing you should learn is a unit testing framework for that language. No matter what kind of coding you're doing, there's simply not a good excuse to avoid unit testing any code you're planning to deploy anymore.

And yeah if you go the C++ route, QT is some mighty tasty kool-aid. Sure you have to run their pre-precompiler on your code and will find it much harder if you want to just hook some random non-QT object you have into your system. Sure they demand that their includes be in a specific place in your code. But it's delicious kool-aid! Go ahead, give it a try! I was just playing around the other day with a QT window into which I'd stuffed a QImage that I had loaded up with some pixels from a GDAL raster driver, and it was less than 500 lines of code (Source code's on github if anyone's interested.) Gotta say that was pretty impressive, though still a fairly trivial example.

Did you verify that the two clicking drives were working BEFORE you removed them?

(I've never, ever had removal or re-installation of an old drive change its status, and I've surely done it more than a dozen times.)