The Redmond giant stunned the software development world this week by opening up several core technologies, including the entire .NET platform, to the public:
We are building a .NET Core CLR for Windows, Mac and Linux and it will be both open source and it will be supported by Microsoft. It'll all happen at https://github.com/dotnet.
Much of the .NET Core Framework 4.6 and its Reference Source source is going on GitHub. It's being relicensed under the MIT license, so Mono (and you!) can use that source code in their .NET implementations.
Dr. Dobbs is impressed (as am I):
Of these platforms, Linux is clearly the most important. Today, Microsoft earns much of its (record) profits from enterprise software packages (SQL Server, SharePoint, Exchange, etc.). By running .NET on Linux, it now has the ability to run those apps on a significant majority of server platforms. Except for Solaris sites, all enterprises will be able to run the applications without having to add in the cost of Microsoft Server licenses.
But perhaps more important than the pure server benefit is the cloud aspect. VMs on the cloud, especially the public cloud, are principally Linux-based. Windows VMs are available, too, but at consistently higher pricing. With this move, .NET apps can now run anywhere on the cloud — or said another way, between servers and the cloud, the apps can run anywhere IT is operating.
The big winners of all this goodness are C# developers. In theory, .NET portability favors all .NET languages equally, but it's no secret that C# is the first among equals. (It is, in fact, the only language that Xamarin supports currently.) Microsoft has been an excellent steward of the language, evolving it intelligently and remarkably cleanly. Among developers who use it regularly, it is uniformly well liked, which distinguishes it from most of the other major development languages today, where an appreciation that borders on ambivalence is the more common experience.
The big loser is certainly Java. Java's stock in trade has been its longstanding ability to run without modification or recompilation on all major platforms. In this valuable trait, it has had no major competition. If Microsoft's port of .NET provides a multi-platform experience that is as smooth and seamless as Java, then the JVM will have some very serious competition.
Once I'm done with the deliverable that's due tomorrow, I may download the .NET Framework and take a look. I'll also spin up an Azure VM and play around with Visual Studio 2015 before the end of the week.
Ah, FitBit. I'm guessing the device only stores time stamps and not time-and-date stamps. I'm also guessing they haven't worked out daylight saving time, either. Because apparently going to bed before 1am CDT and getting up at 7:30 CST was only 5½ hours. (It was actually 7½.)
This seems related to a problem I saw Wednesday. I got to Atlanta just past midnight and synced my FitBit to my phone—which had already switched to Eastern time. Since the device never got past midnight, it's daily summary value started at the total step count for Tuesday, so my total steps for Wednesday and for the week were overstated by 16,000.
Look, I get that time zones are hard, but they're not that hard. It's also not hard to use date-time stamps with unambiguous values—for example, always using UTC internally and only using local time to display and calculate things that depend on local time.
I've got a support incident open with them. I hope I can help them fix this problem, but it may be a hardware issue. That's disappointing.
Meanwhile, I'll make my first attempt at a workaround on Tuesday morning after I land at Heathrow. (The flight crosses local midnight in Chicago but not London.) I'll sync the device in Central time before changing my computer's time zone to GMT, so that it will have experienced midnight in its local time zone. Then I'll re-sync in GMT and see what happens. At the very least I'll get some data on what is causing this defect.
A couple weeks ago I updated SourceTree and discovered I could no longer connect to my Bitbucket repositories through SSL. This is because of the Poodle defect in SSL 3.0. (I'll skip the explanation.) The failure looked like this:
In any event, the only Atlassian forum entry on the subject gave me only partial guidance.
The problem, which took me some time to uncover, turned out to be that I had Mercurial 2.7 lurking on my machine. Uninstalling it and SourceTree, then installing Mercurial 3.0 and re-installing SourceTree, fixed the bug.
This has been a public service blog post.
While I'm up to my eyeballs at work, I've got a backlog of articles to catch up on:
Once I've got some free time (maybe this afternoon) I'll talk about yesterday's Supreme Court non-decision that changes civil rights in the U.S. forever.
The apotheosis of modern aviation's intersection with modern communications—in-flight internet service—is a tease sometimes.
For $50 a month, I get unlimited in-flight internet on American an U.S. Airways. And I'm on a brand-new 737-800, with a functioning seat-back entertainment unit that says I'm over south-central Utah.
However, because I planned to have in-flight internet on this flight, and the internet connection appears to have dropped completely, I now have no way to communicate with my team and therefore no way to finish the task I thought would take half an hour.
I hope this is temporary. Until it comes back, I will contemplate the amazing ability of the human mind to take miracles for granted.
We live in a wondrous age of travel. The mobile phone has revolutionized it: You can get travel alerts, boarding passes, taxis, delay notifications—everything you need.
Against that you have the state of the human brain at 5 in the morning.
According to my mobile phone, I actually woke up at 6. But I'm not in my home time zone. Nor have I exactly gotten enough sleep this week. So when I woke up at 6, I started executing the Leave Louisville Plan, which did not, unfortunately, include checking my mobile phone for flight delays.
It's only a one-hour delay. But it's an hour I could have stayed in bed.
Smart phone, dumb guy.
West Monroe Partners (my employer, who have no editorial control over this blog, nor do they endorse anything I write here) has a thriving mergers and acquisitions practice. In order to provide appropriate advice to our private equity clients, we perform "diligences," which are thorough investigations of a company's strengths and weaknesses. Almost always, the target companies have technology assets that we evaluate as part of the diligence. Which is why I'm up at the crack of dawn in a hotel outside Phoenix.
Obviously I can't disclose anything about a diligence effort, or what kind of transaction is contemplated, or even what industry the company is in. In fact, sometimes I won't even know who the target is until I get there, as is the case today. So I am able to say nothing more about today's work than I'm in Arizona.
Still, the work is really interesting. We get pretty deep into the target's processes, methodologies, even sometimes their actual code and infrastructure. As a technology professional, it gives me exposure to different ways of doing things, especially what works and what doesn't. And it gets me out of the house for a day or two.
Of course, this will slow down posting a bit this week...
Microsoft veteran Raymond Chen explains why Ctrl-F doesn't "find" in Outlook, like it does in every other modern application across the universe:
It's a widespread convention that the Ctrl+F keyboard shortcut initiates a Find operation. Word does it, Excel does it, Wordpad does it, Notepad does it, Internet Explorer does it. But Outlook doesn't. Why doesn't Outlook get with the program?
Rewind to 1995.
The mail team was hard at work on their mail client, known as Exchange (code name Capone, in keeping with all the Chicago-related code names from that era). Back in those days, the Ctrl+F keyboard shortcut did indeed call up the Find dialog, in accordance with convention.
And then a bug report came in from a beta tester who wanted Ctrl+F to forward rather than find, because he had become accustomed to that keyboard shortcut from the email program he used before Exchange.
I'll let Chen give you the punchline.
I have to dash off to a meeting in a few minutes, then to Wrigley. So this is more of a note to myself.
Lucene.NET will be coming to Weather Now, I hope in a few weeks. This will massively improve its piss-poor searching, and allow me to do a few other things as well given Lucene's amazing search capabilities.
Unfortunately, Weather Now ranks third in development priorities behind my employer and my long-suffering freelance client. At least it kind of runs itself these days.
Imagine you're sitting on your front stoop, strumming your guitar, and Eric Clapton comes out of nowhere to give you some pointers.
That's about what happened to me today. Earlier this week, Jon Skeet (described by Scott Hanselman as "the world's greatest living programmer) noticed something I posted on the IANA Time Zone list, and asked me about the Inner Drive Time Zone library.
So I sent him the package.
And this afternoon, he sent me a benchmark that he wrote for it. Just like that.
Of course, the benchmark showed that my stuff was about 10% as fast as the Noda Time library, an open-source project he curates. So, having a couple of hours for "personal development time" available, I optimized it.
The specific details of the optimization are not that interesting, but I managed to more than double the library's performance by changing about ten lines of code. (It's now 20% as fast as Noda.) Along the way I exchanged about 10 emails with Skeet, because he kept making really crack suggestions and giving me valuable feedback about both my design and his.
That was cool.