|
http://www.extremetech.com/extreme/181930-bill-gates-hints-that-microsoft-could-sell-off-its-xbox-division[^]
http://venturebeat.com/2014/07/27/should-microsoft-sell-off-the-xbox-brand/[^]
That arm of the business has been considered for spin-off so that the executive team could focus less on consumer products and more on business products. Just five months ago, analysts were anticipating an end to the games-related division, but now Microsoft increases its games division with the Minecraft acquisition.
The lack of confidence in Microsoft handling the Minecraft brand is well-justified, as is the lack of confidence in Microsoft's attempts in maintaining a consistent corporate direction. However, the consequences of Microsoft sitting idly on billions in cash reserves is generally worse than the consequences of making random acquisitions for no apparent purpose, so we should continue to see interesting and puzzling moves from them for the next few years.
Maybe the next Codeproject poll should be "What random company should Microsoft buy next?"
|
|
|
|
|
On paper Mojang looks like a good acquisition - it has a loyal customer base, made $100,000,000 profit last year on the back of essentially a single product...
so probably not a too bad gamble, should the not stuff it up completely!
(it would be interesting if Notch now goes off and builds the next-big-thing - which is quite likely as that's exactly what he doesn't want to do!)
jesarg wrote: "What random company should Microsoft buy next?"
pooperPig inc.
PooperPig - Coming Soon
|
|
|
|
|
jesarg wrote: Maybe the next Codeproject poll should be "What random company should Microsoft
buy next?"
Xamarin?
|
|
|
|
|
Two new research studies paint a bleak picture of mobile app privacy and security, putting the blame on developers in both cases. Nostris culpa, nostris maxima culpae
|
|
|
|
|
Pls gimme codez, it's urgnt
Who wonders?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Salary cut draws employee ire; management calls it a 'co-investment in training'. That's... an interesting way to fund the training budget
|
|
|
|
|
Very interesting... let's hope it won't become popular, too.
|
|
|
|
|
Is anyone else refreshing Cringely[^] waiting to see how he tears into this stupidity?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Well, at least things like this make it easier for me to figure out which companies I don't want to work for, should I need to start looking. 
|
|
|
|
|
I will only co-invest if I get co-profit.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Every professional C++ engineer sooner or later asks herself a question: “How do I write exception safe code?” The problem is far from trivial. Write in Python instead?
|
|
|
|
|
|
The one thing consistently not mentioned in that article is that the reason exceptions were introduced was because programmers were sloppy about checking error codes.
Their example illustrated this well:
try {
AccessDatabase accessDb = new AccessDatabase();
accessDb.GenerateDatabase();
} catch (Exception e) {
}
public void GenerateDatabase()
{
CreatePhysicalDatabase();
CreateTables();
CreateIndexes();
}
Too often in C code, the error codes that CreatePhysicalDatabase, CreateTables and CreateIndexes returned are just ignored. With exceptions, at least you'll know earlier.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
C code without error checking is dead. Passing this to exceptions is even more deadlier, since introduces also internal changes, as in the example you offered - what is the status of db? created physical; tables; indexes; something else?
Doing this in C is trivial:
struct db* db = NULL;
enum error_step_t e = none;
do {
e = step_create_physical_database;
rv = create_physical_database(&db);
if(rv != 0) {
break;
}
e = step_create_tables;
rv = create_tables(&db);
if(rv != 0) {
break;
}
e = step_create_indexes;
rv = create_indexes(db);
if(rv != 0) {
break;
}
e = none;
} while(0);
|
|
|
|
|
The fact is though, a hell of a lot of programmers simply skipped those checks.
With exceptions, at least the check can't be skipped. Its still not ideal, but generally an uncaught exception is preferrable to an ignored one.
With RAII, the individual steps get unwound, and the programmer is not responsible for tracking (as your error_step_t does) how far along the computation progressed. Admittedly, not all programmers bother with RAII correctly, but at least the program does not continue as if everything was hunky dory.
In this case, I'd have create_physical_database() et al return an object that, during exception unwinding, undoes the steps taken so far.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: generally an uncaught exception is preferrable to an ignored one.
At least they are easier to find when you have to fix legacy code.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's exactly what I meant - an uncaught exception will generally be quite visible. With an unchecked error code the app will carry on oblivious.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Security researchers hack Canon printer firmware to run the classic 90s video game Doom as well as to wreak havoc with other manipulations. On the other hand: good news for Doom fans
|
|
|
|
|
The project aims to improve how open source software is developed and consumed. What part of open source needs more open?
|
|
|
|
|
|
TOTO or not TODO? That is the question. What is the Matrix? That is the other question.
|
|
|
|
|
Abstraction layers in software are what architecture astronauts tell you to do. Instead, however, half of all applications out there would be so easy, fun, and most importantly: productive to implement if you just got rid of all those layers. "It's turtles all the way down."
|
|
|
|
|
This is like the perfect Animaniacs sketch... I miss that show...
GOOD IDEA: Remove layers that you don't need.
[Animation of Mr. Skullhead taking off his winter coat when it's a bright summer day]
BAD IDEA: Remove all layers.
[Animation of Mr. Skullhead taking stripping down all the way, and a passing granny beating him with her walker]
|
|
|
|
|
|
"Abstraction layers ... just got rid of all those layers."
Yes, get rid of the abstraction layers. Do not get rid of the separation-of-concerns/encapsulation layers (or whatever you want to call them).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
