きゃべログ

プログラミングや電子工作などについての記事がほとんどです

HHKB Professional2, BT, Type-Sの3種とパームレスト2種を買って比較してみた

HHKBを初めて購入したのは2018年2月1日でした。それから半年して気づいたらHHKBを3台持ちするようになっていました。現在はそれぞれ会社用、自宅用、MacBook Proと一緒に携帯して使う用に使い分けています。据え置きの会社用、自宅用にはパームレストを合わせて運用しています。

今回はこれまでに買ったHHKB Professional2HHKB Professional2 Type-SHHKB Professional BTの3種を性能や使い勝手などの面で比較してみたいと思います。また、バード電子のパームレストWP-HHK2CWP-HHK2WNの2種類も比較レビューしてみました。

そもそもHHKBとは?

HHKBとはPFU製のHappy Hacking Keyboardの略称です。東プレ製のRealforceと並び、高級キーボードとして多くの方に愛用されています。

省スペース

enter image description here
HHKBの変態配列ともいわれる特殊な配列により、手のひら2つ分に収まるサイズのコンパクトなキーボードです。ファンクションキーが数字キーと一緒になっていたり、テンキーレスなのはもちろんのこと、矢印キーなども他のキーと同居する形になっています。

静電容量無接点式

静電容量で押下を検知するため、スイッチ方式のキーボードと異なり完全に押し切らなくてもキーが反応します。脱力して打鍵しても押し損じがなく、ストレスフリーです。

UNIX配列

Aキーの横にControlキーがあるUNIX配列です。MacBookを使っている方やLinuxユーザーの方にはとても馴染みやすい配列になっていると思います。

HHKB 3種比較

まずは3種のキーボードから比較していきましょう。それぞれJP配列、US配列のラインナップがありますが、私が所持しているのはいずれもUS配列ですので、下記比較はUS配列に限定します。

カラーバリエーションと価格と特徴を比較してみます。
特徴は私がそれぞれの製品の特長を簡潔にまとめてみました。
(価格は2018年8月11日現在のAmazonのPFU公式ストアの価格より引用)

項目 HHKB Professional2 HHKB Professional2 Type-S HHKB Professional BT
白/墨
価格 19,398円 29,700円 29,700円
PCとの接続 USB Type-A (2.0/1.1) USB Type-A (2.0/1.1) Bluetooth V3.0 Class2
USBポート Type-A 2個 Type-A 2個 なし
特徴 スタンダードモデル 静音モデル Bluetooth無線接続モデル

色はProfessional2は白と墨、Professional BTは墨のみ、Professional2 Type-Sは白のみとなっています。Type-S、BTモデルは付加価値がある分、無印よりも1万円高くなっています。

上から順にHHKB Professional2 Type-SHHKB Professional BTHHKB Professional2です。基本的に形状に違いはほとんどありません。大きさもキー配列も同じです。

形状に違いがあるとすればBTモデルの前面に電池を入れる構造があるくらいです。

HHKB Professional2

HHKBの中で最もスタンダードなモデルです。価格は3つの中で一番お手頃価格になっています。打鍵感はしっかりしていて、タイピングしている感を味わいながら入力作業ができます。PCとはキーボード前面からUSB Type Aの 1.0/2.0ケーブルで接続します。さらにUSBポートが2つあり、それぞれ100mAまで給電可能です。USBメモリを手元で手軽に使えたりして便利ですね。

1分間の文章入力

キータイプ時の音はコトコトとした音です。音量は少し大きいかもしれませんが、音色が上品なのでそこまで不快ではない感じだと思います。音フェチ界隈では結構好まれるているとか。

各キーの入力音比較

アルファベットキーと、それ以外の形状が違うキーでは少しずつ音が違います。キーが大きい分スペースキーは若干音が大き目の印象です。個人的にはエンターキーの音がコトコト感が強く好みです。

HHKB Professional2 Type-S

HHKBの静音モデルです。USB周りの仕様はProfessional2と同じです。打鍵感
は他の2つのモデルと比較して少し軽やかな印象。Professional2を触っていると少し物足りない気持ちになるかもしれません。キーの感触に若干ザラザラ感がありますが、エイジング効果でしょうか、使っていくうちに気にならなくなります。

1分間の文章入力

さすが静音タイプ、入力音の高周波が抑えられていてより穏やかな音になっています。また、他のモデルで感じられるキーに触れた時のカチャカチャ音がなくなっています。

各キーの入力音比較

音は全体的にサクサクとした音色です。カチャカチャとした音がしない分、高速で入力しても耳障りになりません。

HHKB Professional BT

HHKBのBluetooth無線接続モデルです。USBケーブルでPCとつなぐ必要がなく、机の上がすっきりします。また、PCだけでなくBluetooth接できるAndroidやiOS端末などの携帯端末とも接続できます。外出先でもキーボードのクオリティは保ちたいというノマドワーカーにはお勧めですね。打鍵感やタイプ音はHHKB Professional2とほぼ同じだと思います。

PFU Happy Hacking Keyboard Professional BT 英語配列/墨 PD-KB600B
PFU (2016-04-12)
売り上げランキング: 3,795

尊師スタイル

尊師スタイルとはノートPCの上にHHKBを置いて使うことを言います。どんな感じに使うかを下記に示してみます。

尊師スタイルで使うなら断然BTがおすすめです。なぜかというとPCにもよりますが有線接続のタイプだとHHKB前面に接続されたケーブルがディスプレイに引っかかってうまく配置できないことがあるためです。下記はMacBook Pro 2015 Earlyモデルで検証してみたものです。また、ケーブル接続が不要なため、持ち運んで使う場合サッと出してすぐに使える良さもあります。

なんかケーブルにもよくなさそうな曲がり方をしている。

enter image description here

BTモデルだとすっきりおさまりました。

尊師スタイルのセッティング風景を動画にしてみました。

1分間の文章入力

入力音はProfessional2とほとんど変わりありません。若干高い音の成分が強い気がしますが、Professional2の方が使い込まれているため、比較的音がまろやかになったのではと思います。

各キーの入力音比較

こちらも同上です。

パームレスト2種比較


続いてパームレスト2種の比較です。今回私が購入したのはいずれもバード電子のパームレストで同一ベンダー内製品の比較です。他にもFILCOのパームレストも人気が高いですが、バード電子のパームレストはPFUダイレクトで公式に売り出されているというお墨付きがあるためこちらを購入しました。

同梱品

高さを合わせ、滑りを防止するためのゴム脚がどちらの製品にも同梱されます。ゴム脚は厚めものと薄めものの2種類が同梱されています。下の写真は高いほうのゴム脚をつけた写真です。なお、1枚目の写真に写っている4つのゴム脚は薄い方です。厚めの方をつけるとパームレストとHHKBの高さがちょうど同じくらいになります。

クリアオイル仕上げ WP-HHK2C

木そのものの色や手触りを求める方はこちらのパームレストが良いかと思います。現役で活躍中ですが、個人的には角が若干ざらついたり、木目の摩擦抵抗が強いのが気になっています。

ウォールナッツオイル仕上げ WP-HHK2WN

クリアオイル仕上げに対してダークな色味です。
手触りはニスを塗ったような滑らかさが特徴です。
どこを触ってもすべすべしていて触り心地が良いので個人的にはこちらのほうが好みです。

タイピング動画

パームレストを使ってタイピングするとどんな感じになるか、それぞれのHHKBと組み合わせて使ってみました。

HHKB Professional2 × パームレスト

HHKB Professional2 Type-S × パームレスト

HHKB Professional BT × パームレスト

まとめ

HHKB3種およびパームレスト2種をレビューしてみました。
どれも一長一短特色があるので、ニーズと利用シーンに応じて使い分けるのが良いと思います。
それでは良いHHKBライフを!

HHKBの使い分け

HHKB Professional2: 価格を抑えて、入力心地を特に重視する人向け。接続はUSB接続が良い場合。」

HHKB Professional2 Type-SS: 軽やかなタッチのキーボードを求めている人向け。会社などあまり大きな音を立ててタイピングしたくない場合。」

HHKB Professional BT: 机の上をケーブルでごちゃごちゃさせたくない人向け。携帯端末とペアリングしたりノートPCと連携して使いたい場合。」といったかんじでしょうか。

パームレストの使い分け

パームレストは完全に色と手触りの好みに依存すると思います。
WP-HHK2C(クリアオイル仕上げ): 木そのものの色とザラザラ感を愛している人」

WP-HHK2WN(ウォールナッツオイル仕上げ): 暗めの茶色と手触りの滑らかさを求めている人」

参考リンク

Happy Hacking Keyboard | HHKB Professional2 | PFU
Happy Hacking Keyboard | HHKB Professional2 Type-S | PFU
Happy Hacking Keyboard | HHKB Professional BT | PFU
ウッドパームレスト - B-SHOP

DMMコミックレンタルで漫画をネットで借りてみたら楽でコスパ最高だった話

最近突然「東京喰種:re」が読みたくなってAmazonのKindleで一括まとめ買いしてしまいました。占めて8923円。衝動的散財をやっちまいました。仕方ない……読みたかったんだから。

東京喰種トーキョーグール:re 1 (ヤングジャンプコミックス)
石田 スイ
集英社 (2014-12-19)
売り上げランキング: 13,869

面白いなと思いつつ読んでいて、9巻くらいまで読んで思うんですね。
前作の「東京喰種」の内容を忘れたから読み直したいと。
前作は2年以上前に読んだきりで内容を忘れており、全14巻Geoのコミックレンタルで読んでいたため、手元にはなく。
とはいえ買うには高すぎるので、レンタルコミックを探すことに。

理想としては電子書籍でレンタルできるところを探してみたのですが、有名どころのコミックを取り扱ってるところは調べた限りなさそうでした。そこで方向性をシフトしてコミック(物理)をネットでレンタルする方向に。そこで探した中でいい感じだったのがDMMコミックレンタルでした。

いい感じだったところ

1. 安い

レンタルが10冊以上から、というロットはあるものの、一冊80円でレンタルできます。送料は往復一律840円です。例えば私が今回借りたケースだと

全14巻新品で購入した場合: 7700円(Amazon)
全14巻レンタルした場合: 1960円(DMMコミックレンタル)

差額5740円。馬鹿にならないですね。

2. 店舗に行かなくてもネットでポチるだけで借りられる

学生時代よくGeoの店舗によく漫画を借りに行ったものですが、店舗に行くのが面倒だったり、たくさん借りて重い袋を持って帰るのがつらいものがありました。ネットで借りられるので家に居ながらにして、簡単に借りられます。外出先から借りるということも可能です。ものにもよりますが、2日程度あれば届くと思います。

3. 返却が楽

こういった段ボールに漫画が入って届くのですが、これにそのまま詰めて返すだけ、というのが非常に楽です。

  • 電話で集荷依頼
  • コンビニや郵便局に持ち込み

の2通りの返却方法が用意されており、いずれにしても柔軟性があり便利ですね。

まとめ

今回はコスパが良くてレンタル手続きと返却が便利なDMMコミックレンタルをご紹介しました。別にDMMの回し者でも何でもないですが、ネットで漫画を借りるという体験が思っていたより良かったので記事にしてみました。予定のない休日や雨の日のお供にぜひ利用してみてください。

机が狭いと思っていたときにモニターアームを買ったら最高だった話

この話は某ソフトウェアエンジニアが机の奥行きの狭さに嘆いていたところ、モニターアームを買ってみたら色々捗って仕方ないという物語である。

動機: 机の奥行きが足りないと思っていた

私は普段写真のような構成で作業していました。

  • デスク(奥行550mm, 幅1000mm)
  • ノートPC: macbook pro(early 2015)
  • ディスプレイ: acer P193W (19inch wide)
  • Amazonベーシックモニタースタンド

デスクが広く使えなくて、作業できないほど辛いというほどではないですが少し作業しづらいなという感覚でした。どのあたりが困っていたかというと、Macbook Proが机のかなり手前にあって、キーをタイプするとき、机の縁に手首の近くで支えないといけなくて不安定という点です。打ちにくいだけならまだしも、割と腕がつかれるんですね、これ。

そういうわけで、奥行きが700mmくらいあるデスクに買い替えたいなぁ、でもこの机去年買ったばかりだし、新しいの買おうとすると高いしなぁ、でもほしいなぁ、と葛藤する日々が続きました。

もともと私はラップトップのちょうど真上にディスプレイを配置したいという気持ちがあり、最初の写真のように、モニタースタンドを使ってディスプレイの高さを底上げしていました。これを使わなければ正直作業にならないので必要だったのです。仮にディスプレイを机に直に置いたところで、ディスプレイの足は安定性を確保するためにそれなりに大きい足があります。それほど机上のデッドスペースは減りません。この構成はそれなりに気に入っていたのですが、軽い不便さを感じてはいました。

Amazonベーシック 金属モニタースタンド - ブラック
AmazonBasics
売り上げランキング: 1,623

そこで一つのアイデアが浮かびました。
ひょっとしてモニタースタンドをモニターアームに置き換えればデスクのデッドスペースが減るのではないか。

モニターアーム初購入

思い立ったのは昨日の夜22時頃でした。思い立ってからはすぐ行動するのが私の信条なので、すぐさまモニターアームを選定し、Amazonでポチりました。そしたら今日のお昼には届きました。注文した品はこちらです。

レビューを見たところ34型ウルトラワイドディスプレイで使えるとのことだったので、私の19インチのディスプレイであれば余裕があると思い選定しました。あと一つ注意したいのはVESA規格75mm/100mmに準拠しているディスプレイであることです。

参考
VESA 標準について - ERGOTRON

簡単に言えばディスプレイを壁掛けしたり、モニターアームに設置するための穴がどうついているか、どれくらいの重さまで耐えられるかという規格です。

モニターアームの設置はクランプで挟み込む型なので、机の天板が挟める安定性を持っているかは確認したほうがいいかもしれません。

組み立て

組み立てはそこまで大変ではありません。やることは、ディスプレイ本体とアームをマウントする作業と、机にポールを設置する作業、ポールにアームを設置する作業だけです。15分くらいで設置が可能です。作業手順書にはいくつかプラスで組立作業が書いてありましたが、すでに組み上がっている工程もあったのでラッキーな気持ちになりました。

結果

こんな感じになりました。ディスプレイの足元のスペースが空いたことでMacbook Proを奥に置けるようになりました。さらに、期待していなかったのですが、ディスプレイの高さが自由に調節できるようになったこと ディスプレイのうつむき加減の調整の自由度があがったこと、が結構嬉しいです。普段椅子にがっつりもたれかかって作業するので、ディスプレイには結構下を向いておいてほしいのですが、これもいい感じになりました。

問題になっていた腕の置き場もしっかり確保できています。腕の細い部分だけで支えることなく、太めのところでしっかり支えられています。手首付近の動きに自由度が上がったのでタイピングのしやすさは格段に向上しました。

アームを手前に持ってきて角度をつけるとこんな感じになります。ちょっとドラマにでてくるハッカーっぽい気分とか、歯医者さんのモニターっぽい気分になれます。

ディスプレイの裏はこんな感じになっています。ポールの近くに左右に1軸、アームの真ん中で左右1軸、ディスプレイ付近で左右回転方向に1軸、上下方向に1軸の計4軸です。かなり自由度が高いです。

まとめ: まだモニターアームを使っていない人にはおすすめしたい。特にエンジニア。

机を広く取ることで、コーディング中にノートを開いて手書きのメモをしたり、単純に広々と使えたりすることで、ストレスフリーな開発環境が手に入ります。

ディスプレイ付属のディスプレイスタンドがいまいちだと感じている方、テーブルを広く使ってみたい方に是非モニターアームをおすすめしたいです。

今回買ったものは4000円程度で手に入りますので、まずは試してみてはいかがでしょうか。大型ディスプレイをお使いの方はご自身のディスプレイに合ったモニターアームを探してみてください。

Gitのカレントブランチのハッシュ値やブランチ名を取得する方法

Gitのコミットの前後のファイルをブランチ名.zipでまとめるという処理をシェルスクリプトで書きたいと思いました。そこでgitのカレントブランチの名前を取得したいなあを思って、方法を調査してみました。

  • gitのコミットハッシュ値を取得するコマンド
    • git rev-parse HEAD
  • gitのカレントブランチ名を取得するコマンド
    • git rev-parse --abbrev-ref HEAD

もろもろの自動化に使えそう。

Cabbageの2017年を振り返る

あけましておめでとうございます。
今年もよろしくお願いいたします。

時が経つのは早いもので、もう年が変わってしまいました。毎年思うわけですが、今年は特にそう思います。学生からサラリーマンと、ライフスタイルが大きく変わったことが要因だと思います。プライベートの時間が思ったより確保できないのが会社勤めの難しいところ。時間は自分で作らないといけません。あとはやることとやらないことの選別が重要だと痛感しています。2017年はあれよあれよと過ぎていき、やりたいと思っていたことの多くをやり残してしまいました。特に技術的アウトプットが少なかったのが心残り。とはいえ、初めから上手くいくとは考えていないので、2018年はいい方向に進むように、自分マネジメントをしていきたい。

2017年のアウトプット

あっという間に1年が過ぎてしまったので、自分がプライベートでどんなアウトプットを出したかを忘れてしまったので、まとめようと思います。だいぶ忘れたので漏れは何個かありそうです。

5月 [Python]ToAtm:Python用Twitterのアクセストークンマネージャ

cabbage63/toatm: Twitter OAuth Access Token Manager for Python

TwitterのAPIを使うためのアクセストークンを管理するツールです。環境変数に保存しようとか、データベースに保存しようとか、そういうのはプロトタイピングでは面倒なので作りました。アクセストークンをまとめたファイルを作成し、そのファイルをgitignoreすればGitHubにPushしてもいいですよっていうツールです。

学生時代研究で機械学習のためにPythonをこそこそ使っていたので、コーディングにはあんまり苦労しませんでした。ただどうもOAuthとかWebAPI周りが苦手だったのでいい勉強になったなあと思っています。

6月 [C言語]コマンドラインオセロ書いた

cabbage63/reversi: Reversi written in C language

2人対戦用のコマンドラインで動くオセロです。オセロって言ったら権利上ややこしいのでGitHub上ではリバーシと命名しました。

会社の研修でC言語をお勉強させていただいたので、習得に向けて自学自習を進めました。このプログラムではあまり高度な文法を扱っていないので、復習に役立ったかというと疑問があります。リファクタリングもあんまり出来ていないので残念なコードですが、書かないよりましなので良しとしましょう。

6月[Processing]動く!C言語プログラミングスタンプ

動く!C言語プログラミングスタンプ! - LINE スタンプ | LINE STORE

エディタでC言語をカタカタコーディングしてる風のLINEスタンプです。新規性は、それなりに使いやすい意味があるコードを考えたところと、スタンプが動くところです。ご査収ください。

コーディングをしているときにふと、「コードで挨拶出来るんじゃね」と思ったのがきっかけでした。どうせなら「シンタックスハイライトしたいんや」 とか「カタカタ入力してるように見せたいんや」と欲が出てきました。ドローツールでしこしこ作るのは無理だと思ったので、Processingで連番画像生成用のプログラムを書き、apngasmでアニメーションPNGとして結合することにしました。生成は簡単になりましたが、コードのネタを考えるのが超大変でした。

あと、この場をお借りして謝罪したいのですが、実はこのスタンプ

バグがあります

バグといってもLINEがバグるとかではなく、「仮にスタンプに書いてあるコードの内容をコンパイルして実行すると思った挙動をしてしまう」という意味ですのでご安心を。よかったら探してみてください。

9月[Processing]動く!Pythonプログラミングスタンプ

動く!Pythonプログラミングスタンプ - LINE スタンプ | LINE STORE

機械学習とか、入門にいいとかでPythonを使う人が増えてきているみたいなので、「乗るしかない、このビッグウェーブに」と思い作りました。Processingのソースコードはほぼ流用ですが、Python用に新しく挨拶に使えるコードを考えるのが大変でした。C言語が16個入りなのに対してPythonは24個入りです。また、Python版では今のところ大きなバグ報告はいただいておりません。念入りに確認しておいてよかった。お値段は据え置き、動くスタンプの最低価格の240円です。使ったってください。

C言語とPythonを合わせるとおよそ800件近く購入していただいています。毎日世界のどこかで自分が作ったスタンプが使われていると思うと本当に嬉しいです。

LINE Creators Marketでは自分の作ったLINEスタンプの利用統計が見れたりするんですが、日本、インドネシア、韓国、台湾の方に多くお使いいただいているようです。LINEが普及しているのはアジアが中心ということが数字で読み取れますね。

書いたブログの記事

7件でした。2014年は7件、2015年は23件、2016年は15件書いていた事を思うと結構減ってしまっているなあと思います。月に1回も書いていない計算になりますね。特に技術系の話題を扱うことが減ってしまっているので、インプットとアウトプットが足りていない感があります。2018年は技術力を高めていきたい。

2017年の記事リスト

ToAtm:Python用Twitterのアクセストークンマネージャを作りました
Amazon Kindleストアで一部の技術書が50%オフ中「夏のプログラミング特集」
libpython2.7.so.1.0: cannot open shared object file
レバテックキャリア様の「使い勝手のいいおすすめテキストエディタまとめ」に記事を紹介していただきました
Apple公式ドキュメントの「AR Human Interface Guidlines」を日本語化した
人気npmパッケージ25本をサクッと紹介する
Microsoft「ExcelにPythonを載せちゃおっかなー」の話について考えてみた

2018年に向けて

振り返ってみると、2017年もっとできたんじゃないかなって思わずにはいられません。Webでもネイティブでもいいので自分のアプリをリリースするのが2018年の目標です。面白い報告が出来るように頑張ります。

あとは一昨年立ち上げたAffinity DesignerとAffinity Photoの解説サイトAffinity Tipsの更新が滞ってるのでなんとかしたいと思っています。お問い合わせのメールを昨年だけでもかなりいただいたので、日本向けの解説サイトはそれなりに需要があると感じています。クリエイティブの加速に役立つWebサイト作りをやっていきたい。

そこでご相談ですが、誰かAffinity DesignerやAffinity Photoのユーザの方で寄稿してくださる方とかいらっしゃいませんか。もし興味のある方がいらっしゃればContactまでご連絡をお願いします。筆者欄を設けるなどのインセンティブを提供したいなと考えています。

まとめ

2017年は環境の変化が大きく、なかなか前に進めませんでしたが、2018年は慣れた分もっと進化していきたいなと思いますのでどうぞおつきあいください。

今年もよろしくお願いいたします!

Microsoft「ExcelにPythonを載せちゃおっかなー」の話について考えてみた

概要

こちらはpython Advent Calendar 2017 - Qiita21日目の記事です。

今回は技術ゴリゴリというよりはポエムに近い記事です。あんまりまとめることを意識せず、つらつらと書いているので変なところがあるかもしれません。賛同やご意見、議論のある方は是非コメント欄へ!

さてお決まりですが…

※この発言は個人の見解であり、所属する組織の公式見解ではありません

はじめに

ExcelのコミュニティサイトであるExcel’s Suggestion Boxに2015年11月5日にExcelのスクリプトとしてPythonを使いたいという旨のコメントが投稿されました。これはDanielさんという1ユーザの小さな一声。

そして2年後、記憶に新しい2017年12月15日にこのコメントにマイクロソフトのExcelチームから下記の正式なレスポンスが付きました。

Hi folks –

Thanks for the continued passion around this topic.

We’d like to gather more information to help us better understand the needs around Excel and Python integration.

To help us with this, can you please complete the survey below?

https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR7tUuWqOwSJFpBE5ZLhdkgtUMkhZWlkxRjhDRklXSjNTVkNSWkE2WlNQMS4u

Ashvini Sharma
Lead Program Manager
Microsoft Excel

要するに、Danielさんの投稿について熱い議論が長い間続いたので、ExcelにPythonが搭載されることのニーズを知るためにアンケートに協力してくれ、という内容。公式の開発チームがアンケートを取るところまで動き出し、ネット上では話題沸騰です。

PythonがExcelの公式スクリプトになった未来を考える

ここではもしPythonがExcelの公式スクリプトになったらどんな影響があるのかを考えてみましょう。

プログラマにExcelがもっと身近になる

1番最初に思いつくのはこの点でしょう。なぜ身近になるかというと、VBAに比べるとPythonの方がプログラマにとって学習コストが低く、親しみ易いからです。VBAっぽさを感じるDimとかSubといったキーワードは近年一般に使われているC言語、Java、Python、Ruby、JavaScriptでは見かけません。特殊さが他の言語間のそれとは比にならないような気がします。

プログラマにとっては学習することが簡単⇔難しいという単純な尺度だけでは単に学習コストは見積もれません。レガシー⇔モダンなど今後の応用性や発展性に関わる尺度と同時に見積もるべきです。そもそもVBAに対してPythonを習得するのが難しいかというと、簡単なことを実装するレベルであれば大差ないように思います。

情報源の幅が急激に広がる

Web上に情報源が多いのは圧倒的にPythonです。情報源の広がりは、Excelマクロのような軽量プログラム群にはかなりクリティカルに効いてくると思います。なぜならコピペで済むスクリプトが多く流通するから。業務効率の向上が見込まれます。

下記エビデンスから明らか。(結果はすべて2017/12/19時点のものです。)

Google検索結果

  • Python: 60M件
  • VBA: 21M件

PythonはVBAの約三倍です。より多く検索されているということは使っている人もそれだけ多いということが推測できます。

Googleトレンドの人気指数

  • Python: だいたい75
  • VBA: だいたい25

こちらもPythonはVBAの約3倍です。人気指数は検索ヒット数に起因している?

ちなみに地域別の関心度合いを見ると、PythonよりVBAの方が指数が高いのは数ある国の中でも日本(Python:VBA=2:3)とアルジェリア(Python:VBA=1未満:1未満)のみ。 なおアメリカは Python:VBA=4:1 という比率になっている。 普通に蛇の意味でのPythonが引っかかっているかもしれないので、コメントしないことにする。

GitHubのリポジトリ数

  • Python: 2M件
  • VB: 45K件

GitHubのPublicなリポジトリを対象に、様々な統計を出しているnamariというサービスから引用しました。Visual Basicなので厳密にはVBAじゃないのですが、VBAという項目がなかったので仕方なくこれで。

マクロスクリプトの性能が向上する

VBAに比べてPythonの方がプログラミング言語としては明らかに勢いがあることは先述のとおりです。それだけでなく、プログラミングに明るい人が話題に上げるのもやはりVBAよりもPythonです。処理のチューニングや最適化に関する情報はPythonの方が豊かであることは自明でしょう。

ライトなプログラマの人口が急増する

ここでのプログラマとは、「ソフトウェアを生業にして生きている人」ではなく、「コアコンピタンスとは別のスキルとしてプログラミングがこなせる人」のことを意味しています。

Excelでの業務プログラミングをきっかけに、更にディープな技術を学び始める人が増えるかもしれません。企画畑のアイデアマンがパワポを作るような感覚で自分でサービスのプロトタイプを作成し、会議で発表する、なんてことが普通になる未来が来るかもしれません。

マルウェアが増える?

VBAに比べるとPythonは豊富なライブラリが充実しており、複雑な機能も比較的簡単に実装出来ます。それを逆手に取れば、厄介な機能を持つ悪質なソフトウェアを作るのも容易であると言えます。VBA專門のマルウェア開発者だけでなく、他のマルウェア開発の片手間にExcelマクロマルウェアを開発するというシナリオは想像できなくはないでしょう。

VBA職人には生き辛い世界になる

これまでVBAによる業務効率化マクロを生活のあてにしていた人が苦しむことになるのではと考えています。Pythonは言語としての注目度が高く、情報系の学生はもちろんのこと、データ処理を必要とする理系学生の一部も普通に使います。また、ホビーとしてのプログラミングに使う言語としても人気の言語です。ライトなプログラマ層が増えることで、副業やアルバイトとしてのマクロコーダーが発生するのではと考えています。
PythonコーダーがExcelマクロに手を出す分にはそれほど苦労しないと思います。逆にVBAしか使えないひとは唯一に近いフィールドであるExcelマクロの領域を奪われてしまうことになる。VBAの言語としての応用性を考えると、他の領域に取り組もうとすると言語の再学習が必要になり、大変そうです。

蛇足: Excelを扱うPythonライブラリ

Excelが公式にPythonをサポートしていないからといって、マクロスクリプトとしてPythonが使えないわけではありません。現状、色々なライブラリがPythonからExcelを扱う障壁を下げてくれています。

まとめ

色々書きましたが、Excelユーザ、Pythonユーザにとっては今回のニュースは喜ばしいものだと思っています。Pythonユーザであり、業務でExcelを扱う私としては是非Excelの公式スクリプトとしてPythonを採用して欲しい限りです。あと、実現するならPythonをベースにした独自スクリプトとかはやめてほしい。

人気npmパッケージ25本をサクッと紹介する

こちらはNode.js Advent Calendar 2017 - Qiitaの20日目の記事です。

今回はnpm rankの2017/12/12のデータを元に、もっとも権威のある(検索でヒットしやすい)パッケージTOP25を超簡潔に紹介していきます。

node.jsには便利なパッケージがたくさんあり、ほとんどのことはパッケージで効率化できます。しかしパッケージを使うには、どういうパッケージがあるか知らなければサッと使うことができません。とはいえ1つずつググっていくと意外と多くの時間がかかってしまう。そのために頭のなかに索引をつくるような記事を書いてみようと思いました。苦労して調べるのは一人でいい!
私自身ほとんどパッケージを知らないので、サーベイの意味を込めて。

説明の誤りや改善点があればコメントください〜。

Node.js超入門
Node.js超入門
posted with amazlet at 17.12.21
掌田津耶乃
秀和システム
売り上げランキング: 17,840

1. lodash

JavaScriptでで関数型プログラミングをするのに使えるモダンユーティリティライブラリ。配列や数値、オブジェクト、文字列の扱いを簡単にする。関数型プログラミングでおなじみの合成関数も利用できます。あと速い。

参考

Lodash
JavaScriptで関数型プログラミングの入門

2. request

httpコールをシンプルに作成するためのライブラリ。とりえずWeb API叩いてみたいときはこれ使っとけばいい感じ。

参考

request - GitHub
Node.jsのrequestモジュールを使ってHTTPSでPOSTリクエストを行う - Qiita

3. chalk

ターミナルに表示する文字列のスタイルを指定するのを簡単にする。ログの出力を簡潔な表記で色付けしたりボールド体にできる。メソッドチェーンを使って1文でハイコンテキストなスタイリングが可能。

参考

chalk - GitHub

4. async

非同期処理をシンプルなAPIで記述できる。また並列処理と逐次処理を同じインターフェースで記述できる。

参考

async
Node.js asyncの有効な使い方 - エンジニアとして生きる

5. express

高速、オープン、軽量なNode.jsのためのWebフレームワーク。
JavaScriptでデファクトスタンダードのMVCフレームワークです。
REST APIの実装とかチャチャッとしたいとき便利。

参考

express

6. commander

CLIツールを作るためのフレームワーク。
簡単にバージョン指定できたり、オプションが指定できたり。

参考

commander - GitHub
NodeでCLIツール作成時にCommander.jsを使うと便利だった話 - Qiita

7. bluebird

Promiseを実現するためのモジュール。
ちなみにPromiseは非同期処理をベースにした並列処理の実装です。コールバック地獄からの解放。

参考

bluebird
今更だけどPromise入門 - Qiita
PromiseとQとBluebird - Qiita

8. debug

Node.jsとWebブラウザで動作する軽量デバッグユーティリティ。デバッグのときのみログ出力したいときに有効。デバッグログ用にconsole.log()を使ってしまうと、実働コードでコメントアウトor削除する手間が生じる。debugモジュールを使えばDEBUG環境変数をいじるだけでログのON/OFFが可能。

参考

debug - GitHub
Express のデバッグ
debug パッケージの使い方 - Qiita

9. fs-extra

Node.jsにデフォルトで存在するfsモジュールには含まれないファイルシステム関連メソッドを追加するモジュール。fsモジュールにない、mkdirp,rimraf,ncpなどを個別にインポートする手間が省ける。promiseに対応させることも可能 。fsモジュールをインポートする代わりにfs-extraモジュールをインポートすればfsの機能も使えるのが大変使い勝手が良い。

参考

jprichardson/node-fs-extra: Node.js: extra methods for the fs object like copy(), remove(), mkdirs()
node.jsで階層ディレクトリ作成やコピーをしたいときは? - Qiita

10. moment

時間のデータを扱うための軽量ライブラリ。パースしたり検証したり操作したりフォーマットを整えたりできる。

参考

Moment.js
Moment.jsを使う - Qiita

11. mkdirp

シェルのコマンドmkdir -p 相当のことが出来る関数を使えるようになる。デフォルトのモジュールではできないところを解決するシンプルなモジュール。

参考

mkdirp - GitHub

12. body-parser

httpリクエストのbodyをパースするためのミドルウェアという位置づけのモジュール。マルチBodyな構造には対応していない。

参考

body-parser - GitHub

13. react

FacebookのUIライブラリであるReactをサクッと使うためのモジュール。Reactを使用したモジュールをbrowserify(モジュールの依存関係を解決し、1つのjsファイルに)するときに特に有用。

参考

React - A JavaScript library for building user interfaces
react - npm

14. glob

ワイルドカードを使ってファイル名を特定するモジュール。パターンに合うファイルを探すときに使う。拡張子がjsのファイル名が知りたい時とか。

参考

glob - GitHub
【npm】 globとはなんなのか - コンパイラかく語りき

15. underscore

配列やオブジェクトの操作をシンプルに書くための関数などの便利関数がパッケージ化されているモジュール。map, reduceなどの関数型プログラミングもサポートしている。

参考

Underscore.js
第1回 Underscore.jsとは:Underscore.jsの入り口|gihyo.jp … 技術評論社
Underscore.jsの全メソッドを表にまとめてみた - あと味

16. babel-core

ES2015やJSXなどのモダンなJS仕様でコーディングされたものをブラウザでも動作するように生のJSに変換するトランスパイラ(コンパイラ)。

参考

Babel
Babelを使おう - Qiita

17. colors

node.jsコンソールに表示する文字列のスタイルを指定するのを簡単にする。3番目に紹介したchalkと類似のモジュール。chalkと比較するとstringにメソッドを生やすなど影響範囲が大きいらしい。

参考

colors.js - GitHub
良く使うnpmパッケージの紹介 - Qiita

18. webpack

複数のモジュールを1つにまとめてファイルを出力するモジュールバンドラ。類似のモジュールにはBrowserifyがあるが、Webpackがユニークな点は、css、画像、Webフォントなどのアセットをモジュールとして扱って1つのバンドルにして出力する点。

参考

webpack
webpack - GitHub
webpack 入門 (v3系 対応) - Qiita
フロントエンドエンジニア必見!JavaScript開発現場で人気の「Webpack」とは?

19. react-dom

元々Reactで提供されていたDOMのルートノード作成機能を分離提供したもの。reactreact-domはReactを使うのに最低限必要。

参考

react-dom
React - A JavaScript library for building user interfaces

20. babel-loader

webpackのモジュールローダとしてbabelを使うために必要。簡単に言うとローダーは入力したファイルをバンドル(一個にまとめる)ときに生JSにコンパイルしてくれる。TypeScriptやES2015などのモダンJavaScriptだけでなくcssや画像のローダが存在する。

参考

babel/babel-loader - GitHub
モジュール管理、だけじゃない-Webpack入門 〜 JSおくのほそ道 #029 - Qiita

実践Node.js プログラミング (Programmer's SELECTION)
Mike Cantelon Marc Harter T.J. Holowaychuk Nathan Rajlich
翔泳社
売り上げランキング: 189,232

21. yargs

CLIツールを作成する際に引数のパースやユーザインターフェースの作成のための機能を提供するモジュール。6番目に紹介したcommanderに近い。

参考

yargs
yargsを使ってタスク自動化ツールのコマンドにオプションを指定する - dskd

22. babel-runtime

babel-polyfillを使うのに必要らしい。
あんまり深い情報を得られなかったので良い解説求む。

参考

babel/packages/babel-runtime - GitHub
babel-polyfillとbabel-runtimeの使い分けに迷ったので調べた - Qiita
フロントエンドでもES6構文使ってみる【webpack+babel-loader(旧6to5-loader)】 - yutaponのブログ

23. q

Promiseを扱うためのライブラリ。Promiseは関数の返却値と例外を定義するオブジェクト。7番目に紹介したbluebirdと類似。

参考

kriskowal/q - GitHub
PromiseとQとBluebird - Qiita

24. css-loader

webpackであらゆるファイルをJS一本化する際、CSSをJavaScriptに変換するのに必要なモジュール。これはsass やlessなどのメタCSS言語をコンパイルするのではなく、プレーンなCSSをJavaScriptで読み込めるようにする機能を持つ。

参考

webpack-contrib/css-loader - GitHub
なんとなくで理解しないWebpackのCSS周辺 - Qiita
webpackのcss-loaderでCSS Modulesをやる - Qiita

25. inquirer

その名の通り、コマンドライン上でユーザに問いかけるのに使うモジュール。
質問を投げかけたり、入力された内容をパースしたり、入力された内容を検証したり、階層構造を持つ質問を管理したり。

参考

SBoudrias/Inquirer.js - GitHub

あとがき

これ書いてて痛感したんですが、モジュールのREADMEに「Why ◯◯?」みたいにそのモジュールの価値を簡潔に書いてくれてるのはすごくありがたい。

最近よく使われている技術をさらっと俯瞰することは勉強になりますね。私はjQueryでなんでもやっちゃおうという世代なので、モダンJS特有知らない概念を吸収できた点が有益でした。これからモダンJS使えるようになりたい。

あと、人気モジュールを追うことで今のデファクトスタンダードが自ずと見えてくる。ライブラリ導入の判断材料として役立ちそう。

はじめてのNode.js -サーバーサイドJavaScriptでWebアプリを開発する-
松島 浩道
SBクリエイティブ
売り上げランキング: 256,064

Apple公式ドキュメントの「AR Human Interface Guidlines」を日本語化した

はじめに

こんにちは。cabbage(@cab_kyabe)です。 本記事はARKit Advent Calendar 2017 - Qiitaの13日目の記事です。 この内容に近い記事は元々公開していた時期があったのですが、完成度が低かったので、Advent Calendar用にリファインして再投稿しました。

Augmented Reality - Technologies - iOS Human Interface Guidelines
を一通り読み、日本語として要約しました。内容は厳密に1対1対応させていません。平易な表現で要点がわかりやすいように表現したつもりです。原文を読んで解釈が明らかにおかしいというのを見つけた方がいらっしゃればご指摘ください。異論は認めます。原文を読むのは結構骨が折れる作業だと私は感じたので、少しでも皆さんのお力になれれば幸いです。

概要

現実と仮想物体をシームレスに重ねて、没入感があり、魅力的な体験を実現するために、iOSアプリではAppleのARKitを使うことができる。
カメラはスクリーン上のビューに現実世界を表示するのに使用する。3次元の仮想物体はそのビューに重畳され、物体が本当に存在するように錯覚させる。もしその体験が正確であれば、ユーザはiOSデバイスの向きを変えて仮想物体を様々な角度から調べることや、ジェスチャや動きを使ったインタラクションが可能である。

魅力的な設計

人々を惹きつけるに画面全体を使うこと

現実世界を表示したり仮想物体を表示するために出来る限りスクリーンを大きく使うこと。また、没入体験を損なうのでスクリーン上をコントロールのパーツや情報で散らかさないこと。

物体を配置するときは説得力のある錯覚を生み出すようにすること

すべてのAR体験に現実に近い仮想物体が必要なわけではない。しかし配置される仮想物体はあたかも現実世界に存在するようにしなければならない。ベストプラクティスは本物そっくりのテクスチャが貼り付けられた詳細な3Dアセットを作成すること、またARKitが提供する現実世界の平面認識を使用して仮想物体の照明の当たり方に適用し、現実世界の画面に仮想物体の影をつけること、カメラの位置変化に仮想物体の位置を適応することである。

物理的な制約を考慮すること

ARがうまく動かない環境でも人々はアプリを使おうと試みることを心に留めておくこと。例えば、動き回ることが出来るほどのスペースがなかったり広い平らな部分がないような場所でも人々はアプリを開くかもしれない。難題を課せられるシナリオを想定して、明確に制約や例外を人々に率直に伝えるよう試みること。

ユーザが心地よくなるように心がけること

長期間に渡ってデバイスを特定の距離、あるいは角度に保つのは骨の折れる作業である。そのためユーザがアプリを使う際にどんなふうにデバイスを持つのかを考慮し、不快感を引き起こさない楽しい体験を目指すこと。例えば、仮想物体を近くに移動させてくる必要がないように、最初から仮想物体を配置することができる。

ユーザの動きを促進するなら、動きを徐々に紹介すること。

例えばゲームにおいてはARに入り込んですぐに仮想世界を見せないようにする。まずは体験に順応するための時間をユーザに与えること。そして、徐々に動きを促進していくこと。

ユーザの安全に配慮すること

近くに他の人や物体があったら、あちこち歩き回る行為は危険となり得る。アプリの操作が安全になるような方法をよく考えること。たとえば、ゲームにおいて大幅な動きや急な動きを避けるように仕向けることが挙げられる。

没入体験を促進するには聴覚と触覚フィードバックを使うこと

音声や衝突感は物理的表面や他の仮想物体に接触するようになったと確信を得るための重要な方法である。没入感のあるゲームでは、BGMはユーザが仮想世界に包み込まれるのを手助けする。

参考

可能な限りコンテキストヒントを提供すること

例えば、物体の3次元回転のインジゲータ(矢印など)を示すことはテキストベースの指示を配置するよりも更に直感的な方法である。しかし、ARKitが平面を検出する前やユーザがコンテキストヒントに反応していない場合はテキストヒントを表示する方が確実である。

説明テキストを表示しなければならない場合、親しみやすい専門用語を使うこと

ARは先進的な概念であるため、怖がる人がいるかもしれない。ARを親しみやすいものにするために、技術的な言葉やARKitWorld detection, trackingのような技術者向けの言葉を使用しないこと。代わりにほとんどの人たちが理解できる会話体の言葉を使うこと。

AR体験を不必要に妨げることを避けること

ユーザーがARを終了したり再開する度に、環境は解析されて平面が検出される。さらに端末とカメラの位置は変わるかもしれない。結果として、以前に配置された物体の配置場所が変わるおそれがある。物体はもはや実世界の平面上に配置されたままである保証もない。こういった体験の妨害を防ぐ方法の1つとして、ユーザに物体の位置や設定をAR体験を抜けずに変更出来るようにさせることが挙げられる。例えば、ユーザがリビングに置くための椅子の購入を検討しているとする。AR上で椅子を配置したとして、ユーザは他の生地の椅子を色々試すような機能が欲しいと思うかもしれない。

ARの世界に入りこむ

初期化が実行されていることを示し、ユーザを巻き込むこと

周囲の環境を評価する初期化処理はアプリがAR機能を開始するとき毎回実行される。この処理には数秒かかる。ユーザの混乱を減らして処理を早くするために、初期化の際にする行動を示すこと。例えば表面を見つけられるように周囲をあちこち映すように勧める。

仮想物体を配置する

(例)平面検出のインジゲータ
(例)仮想物体配置のインジゲータ
(例)アプリのデザインに合わせたインジゲータ

ARKitが平面を見つけたタイミングや物体を置くタイミングをユーザがわかるように助けること

視覚的なインジゲータは平面検出がアクティブになっていることを伝えるのにとても有効な手段である。例えば、画面中央に台形と十字線を置くことで、ARKitが平面を探しているだろうということをユーザは推測できるだろう。ひと度平面が見つかれば、現在物体を置くことができるこを示すために見た目を変えるべきである。あなたが作るアプリに馴染むような視覚的なインジゲータをデザインすること。

ユーザが物体を配置したときには適切に反応すること

平面検出の精度は、かなり短い時間でしだいに良くなっていく。ユーザが物体を配置するために画面をタップすると、現在使える平面情報を用いて物体を即座に配置する。そして平面検出が完了すると、微妙に物体の位置を調整する。もし物体が検出された平面領域からはみ出て配置されていたら、ARKitは物体を平面上にそっと動かす。

検出された平面の端に整然と物体を並べようとしないこと

ARでは平面の境界線は近似的なもので、周囲環境の解析が更に進むと変わるかもしれないためである。

仮想物体に対するユーザインタラクション

スクリーン上に別のUIを設けるよりは直接操作することが好ましい

物体に働きかける際、画面上に別にボタンなどのコントローラを設けるよりは、ユーザがスクリーン上の物体にタッチして働きかけることができる方がより没入感があり、直観的である。

標準的で親しみやすいジェスチャーを使って物体に働きかけられるようにすること

例えば物体を動かす際に1本指のドラッグをサポートしたり、2本指の回転ジェスチャで物体を回転させるようにするなどが挙げられる。関連情報はジェスチャーの項目を参照。

一般に物体への作用はシンプルであること

(例)物体の移動を2次元平面に制限する
(例)物体の回転を一軸に制限する

AR体験は現実世界の3次元に関わっているが、タッチジェスチャはそもそも2次元である。
仮想物体に対するユーザの作用を簡易化するために次のようなアプローチを検討すること。

  • 移動する方向を物体が置かれている2次元平面上に制限する
  • 回転方向を一軸に制限する

物体近くへ作用する妥当なジェスチャにも反応すること

小さかったり、薄かったり、遠くにある物体上のある1点を正確にタッチするのは難しいかもしれない。あなたのアプリが作用できる物体に近い位置のジェスチャを検知したら、ユーザはその物体に働きかけたいのだと推定するのがふつうは最善である。

ユーザが配置したオブジェクトのスケーリング機能が必要かどうかよく考えること

おもちゃやゲームキャラクターのように物体が固有のサイズがなく、ユーザがそれを大きくしたり小さくしたりしたいと思う場合サイズのスケーリングは一般に適切である。しかし現実世界において固有のサイズを持つ家具のような物体を正確なサイズで配置しようとする場合には不適切である。スケーリングは物体の距離を調整する方法としては使えない。例えば物体が近くに見えるように物体を大きくしても、単に遠くにより大きい物体あるように見えるだけである。

ジェスチャの衝突には気をつけること

例えば2本指のピンチジェスチャは2本指の回転ジェスチャととても似ている。もしこのような2つのジェスチャを実装するならば、アプリはそれらを正確に解釈できるのかをテストして確かめること。

仮想物体の移動は滑らかであるか確認すること

ユーザが物体をリサイズしたり回転させたり新しい位置へ移動するとき、物体がジャンプしているように見えてはいけない。

より魅力的な物体への作用方法を探求すること

ジェスチャだけがARにおいて仮想物体に働きかける唯一の方法ではない。アプリでは端末の動きや物体への接近などの他の要素を使うことができる。例えばゲームキャラクタにユーザが近づくと、ゲームキャラクタがユーザの方向を向くようにするなどである。

問題を解決する

AR体験がユーザの期待に沿っていない場合、ユーザ自身でリセットできるようにすること。

状態が改善するまで待たせたり、物体の配置に苦労させてはいけない。ユーザにもう一度やり直してより良い結果が得られるか確認できる方法を提供すること。

問題が起こったら改善方法を提示すること

暗かったり、平面が光を反射しなかったり、平面のディテールが十分でなかったり、カメラの動きが過剰すぎるなど様々な理由によってユーザの環境分析や平面検出は失敗することがある。アプリが平面のディテールが不十分だったりカメラの動きが過剰であると知っていたら、あるいは平面検出に時間がかかりすぎていれば、問題解決の方法を提案すること。

問題と改善案の例

  • 検出されるディテールが不十分→光をもっと照らし、端末を動かして周囲を映してください
  • 過剰な動きを検出→端末をもっとゆっくり動かしてください
  • 平面検出に時間がかかりすぎている→端末を動かして周囲を映してください。また、端末が十分ざらざらした平面を映しているかを確認してください。

ARの機能は使える端末だけに提供すること

もしあなたのアプリの主な目的がARであれば、ARKitをサポートしているデバイスのみでしかアプリを利用できないようにすること。また、もしあなたのアプリが製品の写真を含む家具のカタログのようなARを二次的な機能として使用し、いくつかの製品をARで見られるようにしている場合、ARをサポートしていないデバイスでその機能を使用しようと試みたときにエラーを表示しないようにすること。もしデバイスがARKitをサポートしていない場合、最初からオプションのAR機能を提示しないこと。開発者の手引として、ARKitキーについてはInformation Property List KeyUIRequiredDeviceCapabilitiesを参照のこと。また、ARConfigurationisSupported - ARConfiguration | Apple Developer Documentationも参照のこと。

ARのピクトグラム

アプリはAR体験を開始するボタンなどのコントロールにARピクトグラムを表示することができる。ARピクトグラムは
Resourceからダウンロードできる。

ARピクトグラムは本来意図されたとおりに使うこと

ARピクトグラムはARKitを用いたAR体験を開始する場合のみに限って使われるべきである。サイズや色を変更するなど以外の変更をピクトグラムを適用したり、他の用途に使用したり、ARKitで作られていないAR体験の開始に使用してはならない。

最小限の余白を保つこと

ピクトグラムの周りに最小限の余白として、ピクトグラムの高さの10%を確保しなければならない。他の要素でそのスペースを侵害したり、ピクトグラムを隠してはならない。

ARバッジ

製品やその他のアイテムのコレクションを含むアプリにおいて、ARKitを使ったARで見ることができる特定のアイテムを識別するために、ARバッジを使うことができる。例えば、デパートのアプリでは家具を購入前に自分の家でその見た目をプレビューできるようになるかもしれない。

ARバッジは本来意図された通りに使うこと

ARバッジ
ピクトグラムのみのARバッジ

ARバッジはResourceからダウンロードできる。これらの画像はARKitを使ってARで製品やその他の物を見ることができることを識別するためにのみ使われるべきである。バッジを変更したり、色を変えたり、他の用途で使用したり、ARKitを使っていないAR体験と関連づけて使用したりしてはならない。
ARピクトグラムよりARバッジを使用することが望ましい。一般的に、ピクトグラムだけのバッジは画面のスペースが限られているときや、ARバッジを配置しきれない場合に使われるべきである。いずれのバッジもデフォルトサイズでうまく動作する。

ARバッジはARで見ることができるものとそうでないものが混ざっている場合にのみ使うこと

もしアプリの中のオブジェクトすべてがARで閲覧できるとすれば、そのときバッジは冗長で不要なものである。

バッジの位置は不変で明確に保つこと

バッジは物体の写真のある隅に表示されるのが最も良い。常に同じ角に配置し、バッジがはっきりみえるのに十分大きいことを確認すること。ただし大きすぎて大事な写真の詳細を覆ってしまうようではいけない。

最小限の余白を保つこと

ピクトグラムの周りに最小限の余白として、ピクトグラムの高さの10%を確保しなければならない。他の要素でそのスペースを侵害したり、ピクトグラムを隠してはならない。

まとめ

さて、日本語でもかなり読むのに苦労する記事だったと思いますがいかがでしょうか。 ユーザにやさしいAR体験にはとても大事な項目が多いです。 初めて使うユーザがストレスフリーにアプリを利用できるよう、ポイントを押さえて置きたいところです。