ありし日の気分(改)

● Chromebook ASUS C101PA購入

自宅のデスクトップ環境はこの2月のiMac 27inch購入によりRetina化されたので、携帯電話(iPhone/Android)、タブレット(iPad)、ノートPC(MacbookPro)、デスクトップ(iMac)がようやく全てRetina化が主体となりました。

もうぼんやりした文字で作業するのは(仕事ではガマンするしかないけど)プライベートではゴメンだと思っていたので、新しいモバイルノートPCもMacbookを選ぶつもりでいました。

ただ、iMac環境にそれなりに投資した結果、(1) デスクトップでの作業が快適になった (2) モバイルノートへの投資計画縮小、といった理由でMacbookを少なくとも今のタイミングで買うのは止めるべきという判断をしました。モバイルノートでがっつり作業する気はないので、いっそえいやとChromebookを選択してみることにしました。とは言えモバイルでもemacsとgccとrubyぐらいは触りたいのでcroutonをインストールする前提ではあります。

本来ならChromebookでもRetina(というか高解像度)を選ぶつもりでいたのですが、1kgを切る重さで高解像度という選択肢が見当たりませんでした。という訳で、Retinaは妥協することにして、ChromebookでのベストセラーらしいASUS C100PAの後継であるC101PAをamazon.comでぽちっとしてみました。個人的にASCII配列キーボードの優先度は高い*1ので、米国のamazonでの購入です。送料とか関税とかも入れて33,000円弱程度でした。

次の週末までには届く予定なので楽しみです。

● Unreal EngineアプリのC++開発本を書きました

本を書かせて頂きました。書名は「C++でつくるUnreal Engineアプリ開発 for Windows & macOS」で、発売日は2018年2月24日(土)です。

Unreal EngineってのはUnityと並んで最もメジャーなゲームエンジンの一つで、主要なロジック記述言語はビジュアル言語のBlueprintです。Blueprintの本はいろいろ出ています。

Unreal Engineで先ず使うべきなのはBlueprintなんだけど、例えば既存のC言語の関数を呼び出したいなどの時にはC++を使うこともできます。でも、C++を知ってれば書けるのかと言えば、実は一筋縄ではいかない、ちょっと言語拡張が入ったC++なんです。無防備に読もうとすると「これなに？」の嵐です。しかもこの辺りのことをちゃんと書いた本がありませんでした。

本書は、そんな「これなに…」で挫折しそうになった人(過去の自分…)をターゲットに書いた本です。また、これまでBlueprintでコード書いてきたけどゲームロジックをC++でも書いてみたいという人にもお勧めです。

目次はざっくりこんな感じです。(より細かい目次は書籍のページを見て下さい。)

Chapter 1. 本書を読む前に

Chapter 2. Unreal Engine基礎知識の確認

Chapter 3. UE C++の概要

Chapter 4. UE C++オブジェクト

Chapter 5. UE C++ライブラリ

Chapter 6. 標準C++との連携

Chapter 7. プラグイン

Chapter 8. エディタプラグイン作例

Chapter 9. OpenCV利用プラグイン作例

Chapter 10. エディタモード追加プラグイン作例

実際に動く具体的コード例で説明しています。また、本文で使ったサンプルコード*1の配布もします。ただ、Unreal Engineについて一般的な内容は最低限のことしか書いていないので、先行する多くの本を参照して下さい。良い本がどんどん出てきています。

書名「C++でつくるUnreal Engineアプリ開発 for Windows & macOS」、価格2,700円で、ラトルズから2018年2月24日(土)発売です。A5サイズで200ページちょっとなので持ち運びにも便利なんじゃないかと思い*2ます。ぜひ買ってみて下さい。

ラトルズ

amazon.co.jp

● Apple Watchアプリ開発本

大体アプリの構造を「コード, UI要素, リソース」を分けるとすると、Apple Watchのサードパーティアプリって

- iPhone側: コード, リソース

- 時計側: UI要素, リソース

という具合に分解されるという特徴があります。

これによってApple Watch本体でサードパーティの(やんちゃな)コードが動かないためにバッテリ消費量の見積りが可能になるというメリットがあります。(他にも他のアプリとの連係時には何も考えなくてもいいっていうこともメリットとして挙げることはできるけど、アプリの内側で苦労するか外側で苦労するかってだけの話なのかも。)

Android Wearとかでは「コード, UI要素, リソース」が全部時計側で動くので、やんちゃなサードパーティアプリによってあっという間にバッテリが実際になくなってしまったりします。

そのために、Apple Watchのアプリではユーザが何か操作をしたり画面遷移が発生したりする度にiPhone⇔Apple Watch間の通信が発生します。ちゃんと考えないと使いにくいアプリになります。

正直、使いやすいApple Watchアプリ開発をするためのノウハウはまだ蓄積途中です。ただ、アプリ開発を行うための注意点はわかってきました。

こういったApple Watchのアプリ開発時の注意点やつまづいた点をKindleの電子書籍にまとめました。プログラミング言語にはSwiftを用い、iOSアプリ開発者を対象に、iOS SDK APIとの対比しやすいように書いています。Apple Watchもやってみようかなと思っているiOSアプリ開発者にお勧めです。

● スマートウォッチのバンド

基本的にプログラマブルな小さなデバイスは好きで、スマートウォッチと言えば思い出してみるとPalm OSを搭載したWristPDAぐらいから常用したりしています。(とは言っても永続的に毎日腕時計はめていたかと言えばそういう訳でもないのですが。) スタンドアローンでPalmのアプリが動いて視認性も良くていい端末でした。

覚えている範囲で買ったものをリストアップしてみるとI'm Watch, WIMM, MetaWatch, Pebble, moto360, Apple Watchとまぁ、色々買いました。I’m Watchは1つ壊しちゃって追加で一個買ってるし、MetaWatchはなぜか１つ余分に頂いて友人に譲ったり、inPulseってのも買ったんだけどUSPSに紛失されて入手できなかったり。あと、(Wearでない)普通のAndroidが載った腕時計型端末も買いましたっけ。・・・書いてる内に自分でも呆れてきたのでこの辺りで。

で、まぁ、今は現役の3台にしぼって日替わりで左手首に付けています。3つというのはPebble, moto360, Apple Watchの流行りものです。

個人的には一日中キーボードを触ってる日もあるぐらいにキーボードを使うんですが、手首をパームレストとか机とかに置く癖があるんです。*1 そのせいで昼前にスマートウォッチのバンドのバックルが腕にあたって痛くなります。で、昼過ぎには我慢できずに腕時計を外してしまいます。悲しくなります。

手のひら側にバックルがくるのが問題かなと。(つけてるのはMetaWatchです。)

スマートウォッチだってなんだかんだ言って腕時計です。腕時計付けてキーボード叩いてる人もいっぱいいるでしょう。同じ問題で困っているひとだっていっぱいいるんでないかとぐぐったり時計屋さんにメールで問い合わせたりしましたが、なかなか解決しません。

ちなみにApple Watchはスポーツバンドで使ってるんですが、バックルが痛くないんです。あちこちで言われてますが、Apple Watchってハードウェアとしてよくできているな〜とか思いました。Apple Watchについては腕時計バンドの対策不要で、一日付けていても平気です。

残る現役スマートウォッチはPebbleとmoto360ですが、まずはPebbleから。

Pebbleの場合はNATOタイプのバンドで解決しました。NATOタイプというのは腕時計の上下でつながっている形状のバンドなんです。

で、これをPebbleに取り付けるとバックルが手のひら側に来ない。これで痛くないです。ちなみにデザイン的にも気に入っています。

残るはmoto360なんですが、moto360にはNATOタイプのバンドを付けられません。腕時計の上と下で分離しているバンドじゃないと無理です。最初はメタルバンドを付けてみましたが、標準のバンドほどではないけど、これも使っている内に痛くなってくるんです。(ちなみにmoto360の噂のプラスティックのガードはこの段階でニッパーで切り取ってしまいました。) こうなると痛いのが嫌だし、どうせなら一日付けていられるApple WatchかPebbleを毎朝選んでしまいます。

で、これならバックルが手のひら側ではないなーと思って買ったのがウェンガーのナイロン製腕時計バンド。

ところが、残念ながらそのままでは付けられませんでした。ナイロンの布の厚みがありすぎて、moto360の細いバンド接続部に通せなかったのです。

で、そのまま諦めるのも残念ということで、テグスで結びつけることにしました。

moto360の方にはバンドを通さずにそのままバネ棒をはめて、テグスは図のように通して結びました。結び目は瞬間接着剤で固めています。

裏側はこんな感じですが、痛くありません。この写真だとバックルがあたりそうにも見えるんですが、あたる箇所はナイロンの部分で大丈夫。

一旦結んでしまえば使い勝手は普通に付ける場合と変わりませんし、この止め方でOKだったら他にも付けられる腕時計バンドは多そうです。デザイン的にも気に入っていますし、手首も痛くないです。付けてよかったです。

● つけてる写真

このバンドつけてる写真を忘れてました。こんな感じです。テグスで結んでるなんてぱっと見でわかんないと思いますよ。

● [iOS] Objective-CとSwiftの速度比較

SwiftとObjective-Cの速度比較をすると、Swiftの方が速かったり遅かったりします。どういう時にSwiftの方が速いのかがわかれば、速いコードを生成する方法もそこからわかると思って簡単な例から速度の比較をしています。 例えばこんな例。長さ1000000のInt型(Objective-CではNSInteger型)の配列を用意して簡単な計算結果を書き込んでいきます。

ObjC:

- (void) clear:(NSInteger)val {

  for (int i = 0; i < 1000000; i ++) {

    array[i] = i & val;

  }

}

Swift:

mutating func clear(val : Int) {

  for i in 0 ..< 1_000_000 {

    array[i] = i & val

  }

}

arm64でビルドしてiPhone6で速度比較をしてみるとこんな感じみたいです。

2014-12-28 13:11:46.278 ASMTest[14858:3959193] swift: 0.00826001167297363

2014-12-28 13:11:46.296 ASMTest[14858:3959193] objc: 0.0162650346755981

順序を入れかえてもこんなもんの数値なので有意に速度が違うんでしょうかね。

コンパイル結果のアセンブリコードを眺めてみるとこんな感じみたいです。 先ずはObjective-Cの場合。

ObjC:

LBB1_1:

	and	x11, x8, x2  // x8がi, x2がval

	str	x11, [x9, x8, lsl #3]  // 配列arrayに計算結果を書込み (x9がarrayのアドレス)

	add	x8, x8, #1  // i += 1

	cmp	x8, x10  // iと1000000の比較

	b.ne	LBB1_1

素直なコードです。(この箇所を特定するのはあんまり素直じゃないですが)

ではSwiftの方はどうかと言うと

Swift:

LBB0_1:

	and	x25, x24, x20  // x24がi、x20がval

	add	x24, x24, #1  // i += 1

	str	x25, [x21, x22]  // 配列arrayに計算結果を書き込み (x21がarray中身のアドレス)

	add	x22, x22, #8  // array中身先頭からのオフセット

	cmp	x24, x23  // iと1000000の比較

	b.ne	LBB0_1

という具合で変数iを格納するレジスタ(x24)と配列先頭からのオフセット用のレジスタ(x22)を分けているぐらいが、Objective-C側との違いぐらいなものです。 実際にはSwift側では、読みにくくなるので上のコードからは削っていますが、_swift_retainとか__swift_isUniquelyReferencedとかってのをループ内で呼び出したりしています。 どうしてそれでここまで速度に差が出るのやら、正直よくわかりませんでした。orz

という具合でしまりのない記事でした。でもSwiftってObjective-Cに比べて遅いと思われてるかも知れないけど、そんなことないんですよってことはわかると思います。(ぉぃ)

そんなこんなで私も書かせて頂きました「開発のプロが教える Swift標準ガイドブック」がクリスマスに発売となりました。 Objective-Cの経験のある方ならSwift書くときにどういう風に考えるかなー、どこでつまづくかなーって考えて、話し合って書いていきました。 Objective-CにはないGenericとかOptionalについても(私の執筆箇所じゃないですが)わかりやすく書けていると思います。 structやclassのつまづきやすいところもけっこうネチネチ調べて書いていますので、中級者以上の方も何かしら新しい発見があるのではないかと思います。 年末年始の休みのお供にぜひお買い求め下さい。

amazonのページはこちらです。