IBM has posted 21 consecutive quarters of revenue declines.

Beamer wrote on Aug 25, 2017, 11:23:
Yup, the final paragraph is clearly about valve.

Scottish Martial Arts wrote on Mar 19, 2017, 14:49:
A serious but not back breaking undertaking if the system was well engineered to begin with; a gigantic cluster fuck if the modules that call the API were poorly engineered and too closely coupled to the specifics of the API itself.

Here's a simple, entirely contrived example: suppose you use a third party API with a function called add(a, b), which takes two integers, a and b, as arguments and returns their sum. Now suppose the developer of the API decides that that is too limiting -- after all, you often need to add more than two numbers -- and redesigns the function signature so that it's add(listOfInts), where listOfInts is an arbitrarily long list of integers. Now, your codebase breaks every place where you called add(a, b). You need to manually fix each call, perhaps changing your entire design for where you called add(), because this new add() function is really a different idea more accurately described as sumListOfInts() and you need to adapt accordingly. This is the cluster fuck scenario.

However, suppose rather than calling add(a, b) directly, you defined an interface with the signature add(a, b). You could then write an adapter class, which implements the add(a, b) interface by simply calling the 3rd party API. Now suppose the 3rd party API function signature change occurs. Rather than having to redesign any code that used add(a, b), you instead just design a new adapter class for the new API, still adhering to the previously defined interface. In this case, the new adapter which implements add(a, b) could take a and b, bundle them into a list, and then pass the list to add(listOfInts). Depending on the complexity of the API changes, this could end up being a non-trivial task, but on the other hand, it's just a matter of changing the implementation so that it still conforms to the interface definition. In this scenario, your codebase doesn't have to be redesigned, you just swap in your new adapter class. Ideally, you'll already have a unit testing framework in place for your old adapter class, so once you've designed the new adapter which uses the new API, you can confirm, through automated tests, that everything still works like it's supposed to, since both the old and the new adapter use the exact same interface and are therefore testable in the exact same way.

...

Hellcinder wrote on Mar 19, 2017, 13:26:
I remember picking Star Citizen for one of my free games when I purchased my Radeon 7990.

Grumpy Sod wrote on Aug 26, 2016, 08:31:
I've got most imported, but I believe they lost licensing rights to a few of them between editions, so didn't have the legal permission to let players of 2014 import them, even when they already owned them before. Rights laws at their best!

XCom: Enemy Unknown lets you park your sniper at one end of the map and pick off targets at the other end.