今さらだからこそ考える、Surface Pro 3への再投資
さて、皆様の中には、 Surface Pro 3 持ってて、 Surface Pro 4、Windows Hello で顔で認証できて良いなぁ、でも買い直すほどの金は持ってねーよ。うーんなんて人は沢山いるんじゃないでしょうか。
僕も、実は、 Surface Pro 3 ユーザーで Surface Pro 4、少しだけ羨ましかった人です。
ただですね。僕が今日、ここで書きたいのは、 Surface Pro 3 のアクセサリアップグレードは結構、費用対満足度、高いですよということです。
Surface Pro 4 Type Cover (指紋認証センサー付き) ブラック
Pro 4 って書いてありますが、 Pro 3 でもちゃんと使えます。何の問題もありません。
英語キーボードが嫌じゃなければ、マストバイです。むしろ、顔認証 Windows Hello が存在しない Pro 3 だからこそ、これを買うべきなのです。指紋認証最高です。
実は、顔認識の Windows Hello に関しては、Surface と目が合うだけでロック解除されてしまうとか、いろいろ困ったこともあってですね、結局、能動的にログインしたいときだけログイン出来る指紋の方が便利な事も多いんですよ。
また、キーボードとしても、Pro 3 用から比べると、かなり剛性が高くなっていて、キーボードの「しなり」などはほとんど問題と思わなくなります。ぶっちゃけ、手元の ThinkPad X1 Carbon 2016 よりもキーボードの打ち心地はしっかりしていると思います。
で、安く買いたいなら、これ：
Surface Pro 4 Type Cover (指紋認証センサー付き) ブラック
アフィリンクなんか張るなやボケって人もいるでしょうが、上のリンクは先は Amazon ですが、アフィリエイトではありません。僕は本文中にアフィリエイトリンクを張るような姑息な真似は絶対しませんので安心してください。
そういうことじゃなくてですね、 Microsoft Store よりは、 Amazon で並行輸入品を狙った方が確実に安いのです。
この業者たちは、まだ、日本でこのキーボードが買えない頃に並行輸入で差益を取ろうとしたのかもしれませんが、今となっては正規ルートから購入できるようになってしまったので、正規ルートよりも補償面などで劣る製品を定価よりも安く売っているわけですね。
どうせ、アクセサリの補償なんてどうでもいいやっていうリスクを取れる人々は Amazon で買えばかなり安く買えるのでお得です。
※僕はかなり早い時期に個人輸入で購入したので3万弱ぐらいかかりましたし、補償も事実上ありませんが、後悔していませんよ！
Surface Pen (新しい奴)
こちらも Pro 4 って書いてありますが、 Pro 3 でもちゃんと使えます。
今更、ペンなんて買い直しても意味ないだろうよって思うかもしれませんが、少しでも Surface Pen を使いたいなら、こっちを買うのは良い選択です。Surface Pro 3 では精度面での向上は望めないのですが、従来の Surface Pen から比べて、書き心地が著しく良くなっています。昔の奴は「カツカツ」っていう感じの書き心地でしたが、こちらでは、サインペンのような、もっと柔らかな感じの書き心地になっています。 ペン先キットも標準添付なので、堅さも好きな物が選べます。
まとめ
今日現在の金額だと、キーボードと Surface Pen 両方を買っても、￥23,280 です。 Microsoft Store だと、キーボードだけで、 ￥22,118 なので、 Surface Pen 分がまるまる浮くような計算になります。
そして、こいつらは、万が一、 Surface Pro 4 を買う羽目になっても、再利用できるのです。アクセサリに互換性を持たせてくれる MS の方針は嬉しいですね。投資が無駄になりません。
個人的には、キーボードは本当に満足感高いので、こっちだけでも買いましょうって感じです。
Surface Pen の方は、ペンも使ってるって人なら絶対に買うべきです。使ってない人は買わなくて良いです。
既に持ってるPCが、アクセサリ交換だけでこんなに見違えるようになるんだっていう感覚を是非味わって欲しいです。
ミーティングとか発表時に持ってるとスゲー便利な接続ケーブル
最近は、 MacBook Pro は言うに及ばず、 Surface、ThinkPad の全てに Mini DisplayPort が標準搭載されています。
普通は、こいつらを使ってる限り、プロジェクターに接続できなくても誰かがケーブル持ってるよねぇ的な気持ちにもなるんですが、それでも、会社によっては、未だにアナログRGBしかなかったり、まぁ、変換ケーブル持ち歩くにも相手の都合によっていろいろ持ち歩かないとイケないのはダルいし、そもそも、Apple 純正品なんて買おうものなら金がいくらあっても足らない。
Amazon は良いんですけどね、玉石混淆で、どれが正解なのかさっぱり分からん。
そんな中で、僕が何度も購入してる(たまにどっかに忘れてくるw)奴を紹介しておきます。
Mini DisplayPort オス to HDMI/DVI/VGA メス 3-in-1変換アダプタケーブル 黒
VGA、HDMI(4K対応)、DVI、これだけ生えてれば客先でケーブルの形が違って困るとかもほぼないはずです。
これだけの機能からすると激安ですし。
2016/5/9「JXUGC #13 東京 緊急開催 Xamarin のすべて！」でLTしてきました
誰とも被らなそうなネタ(誰も興味が無いかもしれないネタ)ではあるんですが、ごく一部の人ぐらいには刺さるかなぁと思って、 C++ と C# を全部、Visual Studio だけでどこまで出来るんだ？っていう可能性を確かめてみたという話でLTしてきました。
www.slideshare.net
結論から言えば、割と面倒というか、そこまでして Visual Studio で全部やらなくてもいいじゃないか的な(誰もが分かってる)部分がありました。
箇条書きにすると、
- p/invoke でどんな DLL でも呼び出せる C# 神。
- Androidへのディプロイはかなり簡単(条件付き)
- iOS は、vcremote は使えるけど微妙に不安定
- universal-binary 化が正攻法では出来なさそう
です。やり方を考えないと、普通に使う分にはまだまだ問題がありますねぇという結論になってない感じの結論で終わった話です。
まぁ、LT で 10分だったので、本当は書きたかった話も割愛している部分が多いので、近いうちにフォローアップの記事を書くかもしれません。
しかし、17人もの方々が発表されたのにも関わらず(僕以外の発表はどれも素晴らしいものばかりでした。ライブコーディングとか心強すぎとかw)、驚異的なスケジューリングにより、時間ぴったりに終了できたのは、もう、運営さんスゲーとしか言えないですね。
# そして、懇親会で飲み過ぎ、日曜日を棒に振りました。
新しい VC++ のコンパイラを試す
ツイッターを見てたら、
Introducing a new, advanced Visual C++ code optimizer | Visual C++ Team Blog
こんなのがありまして、へー、でも試すの面倒くさいなぁと思っていたらですね、
こんなのもあって、要は、「nuget で簡単に最新コンパイラ試せるよ！」ってなってたわけです。
知りませんでした。簡単ですねー。
で、
ってあったんですが、コマンドラインから叩きたい。既に VS2015 入っているという僕には、いろいろ面倒そうなので、別の未知を模索してみました。
インストールしてみた(自己流)
とはいえ、やったことは簡単です。
http://dist.nuget.org/win-x86-commandline/latest/nuget.exe
をダウンロードして、適当なフォルダに配置して、
nuget install VisualCppTools -source http://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease
って実行しました。そうすると、 VisualCppTools.14.0.24104-Pre\lib\native に dll やら exe やらが沢山展開される。
このまま実行しても良いですけど、 CRT のヘッダ・ライブラリしかないよんって感じなので、どうにか Windows 系のヘッダとかも参照したい。
しばらく考えた末、
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" set PATH=C:\Users\kawasaki\Desktop\cl\VisualCppTools.14.0.24104-Pre\lib\native\bin\amd64;%PATH%
続続) 気づいたら、C# が C++ の速度を凌駕している！
先日の記事、
.NET Native だとどうよ？っていう話があったので、試してみました。
コードは趣旨を変更しない範囲で弄りました。
スレッドプールのプライオリティとかどうなってんの？っていう疑問はあるんですが、
実行した感じ、それらの影響はなさそうなので、結構適当です。
概要だけ提示できれば良いので、XAMLは提示しませんが、普通にバインドして表示しているだけです。
using System; using System.Collections.ObjectModel; using System.Diagnostics; using System.Threading.Tasks; using Windows.UI.Xaml.Controls; namespace App1 { public sealed partial class MainPage : Page { public ObservableCollection<double> Times { get; } = new ObservableCollection<double>(); public MainPage() { this.DataContext = this; this.InitializeComponent(); Loaded += (s, e) => workOnBackground(); } async Task workOnBackground() { double t1 = 0, t2 = 0; await Task.Factory.StartNew(() => { int w = 4321; int h = 6789; int stride = (w + 3) & ~3; var a = new byte[stride * h]; t1 = time(() => test1(a, w, h, stride)); t2 = time(() => test2(a, w, h, stride)); }); Times.Add(t1); Times.Add(t2); } static void test1(byte[] a, int w, int h, int stride) { for (int y = 0; y < h; y++) { int offset = y * stride; for (int x = 0; x < w; x++) { a[x + offset] = (byte)(x ^ y); } } } static unsafe void test2(byte[] a, int w, int h, int stride) { fixed (byte* p0 = a) { for (int y = 0; y < h; y++) { byte* p = p0 + y * stride; for (int x = 0; x < w; x++) { p[x] = (byte)(x ^ y); } } } } static long time(Action action, int count = 100) { var tw = new Stopwatch(); tw.Start(); for (int i = 0; i < count; i++) action(); tw.Stop(); return tw.ElapsedMilliseconds; } } }
結果
32-bit/64-bit で特に何の差も見れませんでしたので、そこに関しては割愛。
結局、ここにある、 "Compile with .NET Native tool chain" を ON/OFF した結果だけです。
OFF の時。
ON の時。
面白いですねー。
.NET Native が OFF の場合の速度の傾向はフルの .NET Framework 4.6 のコードと同じですね。配列は遅く、 unsafe は速い。ただ、前回調べた、 .NET Framework 4.6 や C++ と比べると、微妙に遅いですね。
ところが、 .NET Native を ON にすると、配列と unsafe の速度差がグッと縮む。速度的に、2～3%程度の差しかありません。この差だと、 unsafe コードを無理して使わないでも良いような気がする速度です。
この差を見せられると、時間をかけてコンパイルできる AOT コンパイラは馬鹿に出来ないなぁと思わざるを得ません。
.NET Framework 4.6 や C++ との速度差は、プライオリティの問題かもしれませんし、フレームワーク自体の問題かもしれませんし、その他のノイズかもしれません。調べるのが面倒なのでそこまでは追求しません。
