google, mobile, smartphones
Nokia 8: a phone from the new Nokia brand that you might actually want
August 31, 2017 Tim Anderson	Leave a comment
This morning I attended Nokia's press breakfast here in Berlin, where the main product on show is the Nokia 8 smartphone. It is not quite a new launch – there was an event in London a couple of weeks ago – but it was my first look at HMD's first flagship device.
HMD Global Oy was founded in May 2016 as a new company to exploit the Nokia smartphone brand. The company is "owned by Smart Connect LP, a private equity fund managed by Jean-Francois Baril, a former Nokia executive, as well as by HMD management," according to the press release at the time. Based in Finland, the new company acquired the right to use the Nokia trademark on smartphones as well as "design rights relating to Microsoft's Feature Phone Business" (what feature phone business, you may ask).
HMD made the decision to market a pure Google form of Android. I find it intriguing that a Nokia-branded smartphone was once powered by Symbian, then became a Windows device, and now has Google deeply embedded. The two companies are now "joined at the hip," according to an HMD spokesperson this morning. Though it is a rather unequal relationship, with HMD having fewer than 500 employees and relying on outsourcing for much of its business.
A UK release of the Nokia 8, together with operator deals, will be announced on September 6th, I was told. The unsubsidised price might be around £600 (or Euros, the currencies being of nearly equal value in these Brexit days).
So why might you want one? Well, it is a decent phone, based on an 8-core Qualcomm Snapdragon 835 chipset, 2560 x 1440 display, 4GB RAM, 64GB storage, up to 256GB MicroSD, fingerprint reader and so on.
There are a couple of special features. The most obvious is that both front and rear 13MP cameras can be used simultaneously, enabling what Nokia inevitably calls "bothies".
Is this a feature worth having? It is problematic, partly because taking good selfies is difficult without a selfie stick which most of the time you do not have with you, and partly because the view behind you is typically less interesting than the view you are trying to photograph.
I am not sure whether this matters though. It is a distinctive feature, and in a crowded market this is important.
I am more interested in another feature, called OZO audio. OZO is a professional cinema camera made by Nokia and the system in the phone is based on OZO surround sound algorithms. The phone has three microphones, and using OZO you can apparently capture a simulated surround effect even though the output is two-channel.
Although it seems counter-intuitive, I do believe in the possibilities of simulated surround sound; after all, we only have two ears. OZO works in conjunction with the phone's video camera so you can capture more atmospheric audio. The demo was impressive but this is something I will need to try for myself before forming a judgement.
The other aspect of the Nokia 8 which is attractive is the company's attitude towards Android modifications and bundled apps. Essentially, you get Android as designed by Google, plus Google apps and not much else. Operators will not be able to bundle additional apps, I was told (though I am not sure I believe it).
While I do not like the way Google constantly gathers data from users of its software, I do think that if you are going to run Android, you might was well run it as designed, rather than with additional and often substandard "enhancements".
I hope to do a full review and will look carefully at the audio performance then.
androidgoogleifa2017nokia
.net, microsoft, software development, visual studio, windows
Microsoft updates the .NET stack with .NET Core 2.0 and updated Visual Studio. Should you use it?
August 15, 2017 onlyconnect	2 Comments
Microsoft has released .NET Core 2.0, a major update to its open source, cross-platform version of the .NET runtime and C# language.
New features include implementation of .NET Standard 2.0 (a way of targeting code to run under multiple .NET platforms), new platform support including Debian Stretch, macOS High Sierra and Suse Linux Enterprise Server 12 SP2. There is preview support for both Linux and Windows on ARM32.
.NET Core 2.0 now supports Visual Basic as well as C# and F#. The version of C# has been bumped to 7.1, including async Main method support, inferred tuple names and default expressions.
Microsoft has also released Visual Studio 2017 15.3, which is required if you want to use .NET Core 2.0. New Visual Studio features include Azure Stack support, C'# 7.1 support, .NET Framework 4.7 support, and other new features and fixes.
I updated Visual Studio and downloaded the new .NET Core 2.0 SDK and was soon up and running.
Note the statement about "This product collects usage data" of which more below.
The sample ASP.NET MVC application worked first time.
How is .NET Core doing? The whole .NET picture is desperately confusing and I get the impression that most .NET developers, while they may have paid some attention to what is happening, have concluded that the safe path is to continue with the Window-only .NET Framework.
At the same time, .NET Core is strategically important to Microsoft. Cross-platform support means that C# has a life on the Mac and on Linux, which is vital to its health considering the popularity of the Mac amongst developers, and of Linux as a deployment platform for web applications. Visual Studio for Mac has also been updated and supports .NET Core 2.0 in the new version.
Another key piece is the container trend. .NET Core is ideal for container deployment, and the only version of .NET supported in Windows Nano Server. If you want to embrace microservices running in containers, while still developing with C#, .NET Core and Nano Server is the optimum solution.
Why not use .NET Core, especially since it is faster than ASP.NET? In these comparisons, .NET Core comes out as substantially faster than .NET Framework for various algorithms – 600 times faster in one case.
The main issue is compatibility. .NET Core is a subset of the .NET Framework, and being a relative newcomer, it lacks the same level of third-party support.
Another factor is that there is no support for desktop applications, though some solutions have been devised. Microsoft does have a cross-platform GUI story, in Xamarin Forms, which is now in preview for macOS alongside iOS, Android, Windows and Tizen. If Xamarin used .NET Core that would be a great solution, but it does not (though it does support .NET Standard 2.0).
One of the pieces that most concerns developers is data access. If you use .NET Core you are strongly guided towards Entity Framework Core, a fork of Microsoft's ORM (Object-Relational Mapping) framework. Someone asked on this page, is EF Core usable? Here's an answer from one user (11 days ago):
Answering 4 months later but people should know: Definitely not, it is still not usable unless you are doing something very trivial and/or have very small DB.
I don't understand how it is possible for MS to ship it, act like it's OK and sparsely here and there provide shallow information about its limitations like in this article without warning clearly and explicitly about the serious issues this "v1 product" has.
Someone may jump in and say no, it is fine; but there are undoubtedly missing pieces and I would suggest caution.
You can also access data using the Connection/Command/DataReader approach which avoids EF, and although this is more work, this is what I would be inclined to do personally since you get the best performance and flexibility. Here is an example for SQL Server.
Who is using .NET Core? Controversially, Microsoft gathers telemetry from your use of the command-line tools though you can opt out by setting an environment variable. This means we have some data on .NET Core usage, though unfortunately it excludes Visual Studio usage. I downloaded the most recent dataset and imported it into a database. Here are the figures for OS family:
Total rows 5,036,981
Windows 3,841,922 (76.27%)
Linux 887,750 (17.62%)
Mac 307,309 (6.1%)
Given that this excludes Visual Studio users, who are also on Windows, we can conclude that the great majority of .NET Core developers use Windows, and only a tiny minority Mac (I do not know if Visual Studio for Mac usage is included). This is evidence that .NET Core has so far failed in its goal of persuading Mac-using developers to adopt .NET. It does show interest in deploying .NET applications to Linux, which is an obvious win in licensing costs as well as performance.
I would be interested in comments from developers on whether or not they use .NET Core and why.
.net coreasp.netmicrosoft
An overreaching Office 365 integration from Sage
Sage, a software vendor best known for its accounting software, recently introduced an Office 365 integration in its products called Sage 50C Accounts (the "C" is for cloud).
The integration offers several features including:
Automatic data backup to OneDrive
Contact integration so that you can easily see Sage accounts data for contacts in Office 365/Outlook
A mobile app that lets you capture receipts with your smartphone and import them
Excel reports
A Business Performance Dashboard
Very good; but how is this implemented? Users get a special Getting Started email which says:
Are you ready to integrate your Microsoft Office 365 account with Sage 50c Accounts? All you need to do is click Get Started and sign in using the administrator account for your Office 365 Business Premium subscription, and we will guide you through accepting terms and conditions, how to sync your data and setup the Sage apps and users
To sign in, you'll enter your email and password for your administrator account. Your email is formatted as follows: xxx@xxx.onmicrosoft.com. If you have forgotten your Office 365 administrator password, please click here for more information.
You'll be asked to accept a provider invitation to give us permission to activate the Sage add-ins for your Office 365 account. Easy.
If you know Office 365 you will spot something odd in the above. Sage is asking you not just to install an Office 365 application, but to "accept a provider invitation".
It is as bad as it sounds. In order to get its integration working, Sage demands that you appoint it as a Cloud Solution Provider (CSP) for your entire Office 365 tenancy. This does not require that you start paying for your tenancy via Sage, as it can be alongside an existing CSP relationship. However it does give Sage complete access to the tenancy including the ability to reset the global administrator password.
While I do not think it is likely that Sage will do anything bad, this is a lot to ask. It means that in the unlikely event that Sage has its systems compromised, your Office 365 data is at risk.
It gets worse. Once you have agreed to hand over the keys to your Office 365 kingdom, you click a "Let's get started" button in Sage 50C Accounts on your desktop. You have to log in as manager (a local Sage administrator) and then enter the credentials for your Office 365 global administrator. These credentials are then stored by Sage for 90 days and used to perform synchronization. After 90 days, it will demand that the credentials are entered again.
And by the way, you will need an Office 365 Business Premium license for the global administrator, even though it does not normally use that license for day to day work.
Why is this bad? First, it is a mis-use of the global administrator account. Best practice is that this account is used only for Office 365 administration. It should not be an active user account for email, OneDrive etc, since this increases the risk of the account being compromised.
Second, end users (such as those in the accounts department) do not normally have knowledge of the global administrator credentials. Therefore to perform this operation, they will need to contact their IT support every 90 days.
Third, the fact that Sage has these credentials on a user's PC, albeit I presume encrypted, adds a possible attack mechanism for your Office 365 tenancy. If the PC became hijacked or infected with malware, some bad guy can now start trying to figure out if there is a way of persuading Sage to do something bad.
Fourth, it is not even wise to enter these credentials on an end user PC. Perhaps I am being excessively cautious, but it is obvious that an end-user PC that is used for day to day work, web browsing and so forth, by someone non-specialist in IT terms, is more vulnerable than an administrator's PC. If a keylogger were installed, then there is an opportunity to grab the global administrator credentials every 90 days.
Frankly, I do not recommend that businesses use this integration in its current implementation. Nor is it necessary. There are plenty of ways to create Office 365 applications that integrate nicely using the APIs which Microsoft has provided. Maybe there is a feature or two which is difficult to implement without these rights; in this case, the correct thing to do is to badger Microsoft to provide a new API, or perhaps to recognise that the security cost of adding the feature is not worth the value which it adds.
My suspicion is that Sage has gone down this path by a process of evolution. It set itself up as an Office 365 CSP (before doing this integration) in order to get some extra business, which is fair enough. Then it started adding value to its Office 365 tenants, making use of what it could do as the customer's CSP. Then it wanted to extend that to other Office 365 customers, those for whom it was not the CSP, and went down the path of least resistance, "oh, let's just require that we become their CSP as well."
Imagine if other third-party vendors go down this route. Your specialist business software supplier, your CRM supplier, your marketing software, all demanding total access and control over your Office 365 setup.
It is overreaching and disappointing that Microsoft CEO Satya Nadella blessed this integration with a quote about "empowering professionals" when the truth is that this is the wrong way to go about it.