キーボード二刀流を初めて三ヶ月弱が経過した
キーボード二刀流というのはこういうやつ。 肩凝りが改善するという話だったので初めてみて、三ヶ月弱が経過した。
要約
肩凝りは特に改善も悪化もしていない。
所感
- 初めて最初の3時間くらいは違和感があった。すぐ慣れる。
- たまに手をホームポジションに戻すのをミスったりする。
- 机がちょっとだけ狭くなった。
- トラックパッドをどこに置くのがいいかよくわからない。今は右手のすぐ下に置いている。
- 使えるキーボードが2倍になったので死蔵してたキーボードが減った。よい。
- 多少肩が楽になった気がする。
- オフィスでも二刀流にしてたら、「この会社にはモニタを2台使ってる人も、キーボードを2台使ってる人もいるの...。こわい...。」って言われた。
🏁 AquaSKK 4.3.3: MS Excel 2016対応
Office 2016のExcelでモード切り替え時にl/L/qが入力されないようにした by zalt50 · Pull Request #38 · codefirst/aquaskk · GitHubを取り込み、AquaSKK 4.3.3をリリースした。(thx to zalt50)。
ダウンロード
https://github.com/codefirst/aquaskk/releases/tag/4.3.3
変更内容
MS Excel 2016で、l/q/Lなどによる入力モードした場合、l/q/Lなどが入力されてしまう問題が修正された。詳細は#13を参照してほしい。
余談
ちなみにExcel 2011では問題なく動くらしい。動くことを確認した人が「骨董品での動作報告はちょっと…」ってdisられていたけど。
☁️AquaSKKのiCloud対応
パッケージを作って ☁️AquaSKK with iCloud - みずぴー日記 に置いた。
AquaSKKのユーザ辞書をiCloudで同期するようにした。 自分の使っているMacBookとiMacで辞書を共有できるようになった。
現状
cloudkitブランチに最新の内容がpushしてある。 いくつかのコーナーケースが残っているが、実用上の問題はないと思う。
もうちょっと完成度があがったら、ベータ版のインストーラとか作ると思う。
iCloudの使い方
iCloudを使う方法は4種類ある。 それぞれの特徴については[iOS 8] CloudKit を使ってみよう (1) 概要 | Developers.IOの冒頭に簡潔にまとまっている。 Appleの文書だとiCloud設計ガイド(PDF)がよい。
この4種類のどれを使うかはかなり悩んだが、今回はCloudKtiを使うことにした。
- Key-value Storage
- 1MBまでしか保存できないので、容量が不足している。
- iCloud document storage
- ファイルベースを意識することになるので、単語登録したときの競合解決を実装するのが大変そう。
- Core Data storage
- 現時点でCore Dataを用いていないので、あまり利点がなさそう。
- CloudKit
- iCloud上に構築されたKVSとして扱えるので、辞書データをそのまま格納できそう。 また、CloudKit dashboardで登録されたデータを確認できるので、開発が楽そう。
保存領域
CloudKitにはどのユーザでもアクセスできるpublic領域と、そのユーザしかアクセスできないprivate領域がある。 public領域の容量はアプリによって決まり、private領域の容量はユーザのアカウントによって決まる。(参考: Designing for CloudKit)
AquaSKKの辞書はprivate領域に格納するようにしたので、他のアカウントから辞書データにアクセスすることはできない。また辞書データはユーザのiCloud driveに保存される。
主な構造
SKKのエンジンが直接iCloudと通信するのを避け、中間にユーザ辞書を挟む方式を採用した。
- SKKのエンジンは、これまで通りユーザ辞書に対して単語の検索・登録を行なう。
- 同期するためのクラスがユーザ辞書を読み込み、更新分をiCloudに送信する。
- 定期的にiCloudの更新を確認し、更新があった場合はユーザ辞書に単語を追加する。
単語を検索するたびにiCloudと通信する方法も検討したが、ネットワーク通信ができない環境での利用を想定して断念した。
単語の削除
基本的に、iCloudから取得した単語をローカルの辞書にマージすることで、辞書の同期を実現している。 ただし、それだけでは、辞書から単語を削除しても簡単に復活してしまう。
そこで、「ユーザ操作によって削除された単語」は別枠で管理するようにし、ここに登録された単語は同期のタイミングでユーザ辞書から消すようにした。
同期状態の表示
同期状態を通知するために通知センターを利用している。
Dropboxのようにメニューバーに出しているアイコンで通知したかったが、InputMethodのアイコンを動的に変化させることができなったため断念した。
通知センターに用いられるアイコンはシステムにキャッシュされるらしく、AppIconを更新しても反映されなかった。 バージョンやビルド番号を更新すれば反映された。
設定画面
設定画面からiCloud同期の有効・無効化を切り替えれる。 無効にした場合はこれまでと同様の動作をする。
その他の知見
- CloudKitの使い方はccabanero/ios-cloudkit-snippets · GitHubがシンプルにまとまってて、よかった。
- ただし、CloudKitからは一度に100件しかレコードを取得できないので、ページングが必要になることは書いてないので、注意が必要。
- まさしブログ: CloudKitでページング読み込みを参考にした。
- テストにはL辞書にない単語を使う必要があったので、ゆるゆりの登場人物名を使っていた。 特に、同じ読みの単語がない「歳納」と、同じ読みの単語がある「赤座」の2つが便利だった。
- AquaSKKのエンジン部はC++、CloudKitを利用する箇所はObjectvie-Cなので、Objective-C++を使うことになった。 いわゆる「文字列」に対応する型が、
const char[]
、std::string
、NSString*
の3種類登場してつらかった。
💪3D Touchサポートの実験
FlickSKKで3D Touchをサポートするために、いくつかの実験的な実装を行なった。
既存のAPIの問題点
iPhone 6s/6s Plusで3D Touchが搭載されたが、APIから利用できるのは以下の3機能のみ*1である。(参考: iOS - 3D Touch 概要 - Qiita)
- home screenにおけるQuick Action
- peek/pop
- 圧力感知(フィードバックなし)
そのため強く押されたときに、フィードバック付きで任意のアクションを実行することはできない。
実現したこと
- 押す力が一定値以下の場合は何もおきない。
- 一定値以上になると、押す力に応じて画面にぼかしをかける。
- さらに強く押すと、hapticによるフィードバックが発生し、漢字変換を開始する。
要素技術
Taptic Engineによるフィードバック
TapticEngineを直接使うAPIは公開されていない。 しかし、公開されていないだけで実装はされているので、ヘッダファイルを自分で書けば利用できる。(参考: Using Taptic Engine on iOS · Unified Sense)
#ifndef Taptic_h #define Taptic_h #import <UIKit/UIKit.h> @interface UITapticEngine : NSObject - (void)actuateFeedback:(int)feedbackType; @end @interface UIDevice (Private) - (UITapticEngine *)_tapticEngine; @end #endif /* Taptic_h */
使い方は以下の通り。
UIDevice.currentDevice()._tapticEngine().actuateFeedback(1001)
押下時のぼかしの適用
押してる圧力は分かりづらいので、画面上になんらかのフィードバックを出すようにしたほうがいい。 今回は、圧力に応じて、画面にぼかしをかけるようにした。
UIBlurEffectを利用しようとしたが、ぼかしの強さを変更できないので断念した。
そこで、画面のスクリーンショットを取得し、UIImage+ImageEffects.hを用いて、ぼかしをかけるようにした。
その他
より具体的なことはPull request #143を直接見れば分かる。 特にForceTouch.swiftに説明コメントが多めにはいっている。
🔡AquaSKK 4.3.0: 拡張ローマ字入力AZIK/ACTの対応強化
拡張ローマ字入力の変換ルールを拡張したAZIK、ACTに対応したAquaSKK 4.3.0をリリースした。
ダウンロード
https://github.com/codefirst/aquaskk/releases/tag/4.3.2
(追記: リリースミスをしたのでバージョンをあげました)
拡張ローマ字入力AZIK/ACTとは
AZIKは通常のローマ字変換規則を拡張し、頻出するパターンを高速で入力できるようにしたものである。 例えば「k」が「inn」と同じ意味になっているので「ゆるゆりんりんりんりんりん」は「yuruyurkrkrkrkrk」で入力できる。
詳しい入力方法はAZIKとは (エイズィックとは) [単語記事] - ニコニコ大百科にまとまっている。
ACTはAZIKをDvorak配列用に移植したものであり、こちらはACT (AZIK on Dvorak)が参考になる。
既存のAquaSKKのAZIKの問題点
4.0以降のAquaSKKはAZIKに対応していたが、いくつかの問題点がある。
4.3.0ではこれらの問題を、ddskkの挙動に準ずる形で修正した。
バージョンアップ時の注意点
AZIK等の設定は、設定画面を閉じるときに更新される。そのため、すでにAZIKを使ってる場合は、一度設定画面を開き、閉じる必要がある。
余談
修正点: 補助ルールの拡張
AZIK/ACTを有効にした際にキー設定を切り替えれるようにするために、sub-rule.desc
を拡張した。
# AZIKの場合は、azik.confからキー設定を読み込む azik.rule azik.conf 拡張ローマ字入力「AZIK」を使う(JIS配列用) # ACTの場合は、act.confからキー設定を読み込む act.rule act.conf 拡張ローマ字入力「ACT」を使う
act.conf
は以下のようになっている。
# q/Qの設定をクリアする NotToggleKana q NotEnterJapanese Q # q(keycode 0x21)に機能を割り当てる ToggleKana keycode::21 EnterJapanese shift::keycode::21
ちなみにキー設定ファイルの書き方をミスするとAquaSKKが起動しなくなる。 そのときは ~/Library/Preferences/jp.sourceforge.inputmethod.aquaskk.plist
を消すとよい。
修正点: 送り仮名の正規化
ACTではカ行を入力するkの代わりにcを使う。そのため、従来のAquaSKKでは「ICu」と入力した場合「いc」でSKK辞書を検索してしまい、正常な変換ができなかった。
そこで今回からは、変換前に送り仮名の正規化を行なうようにし、この問題を修正した。
類似の問題はAZIK/ACTの「っ」についても存在したが、これで修正される。
修正点: SKK日本語入力FEP互換の記号入力の修正
📦AquaSKK 4.2.7: SKK日本語入力FEP互換の記号入力 - みずぴー日記で導入したSKK日本語入力FEP互換の記号入力だが、いくつかの変更を行なった。詳細は #34 を見てほしい。
@mzp AquaSKKの改良で参考にしていただきありがとうございます。実は次の版から、記号入力(z`)の文字を「〆」に変更する予定です。元の設定は利用頻度が少なく対となる文字の入力にモード変更が必要という問題があり、逆に打鍵数が増えてしまうというのが理由です
— どうしてcoなった (@coexe) September 27, 2015
@mzp ありがとうございます。ちなみにこれはEggというEmacsの日本語入力のルールを元にしています。EggからSKK8に環境を移行した際、利用頻度が高く便利だった文字を引き継いで細々と使ってきたものです。可能ならEggの名称を設定名のどこかで使っていただけると嬉しく思います
— どうしてcoなった (@coexe) September 27, 2015
バージョン番号
雑につけているのもどうかと思い、semverっぽくした。 機能追加なのでminor versionが加算されている。
最速入力
AZIKを初めてまともに見たのだが,「ばんじゅん」が最速で入力できることと,日本語に本当に「~ん」が多いのが分かった。(AZIKモードでゆるゆりんりんりんりんりんの歌詞を試しに入力しながら) https://t.co/N2Wp1IIujI
— ばんじゅん(!!) (@banjun) October 15, 2015
🍫cocoapods-app_group: AppGroupを用いたチーム開発補助
要約
iOS - 個人用アカウントでAppGroupを用いたチーム開発を行なう - Qiitaで書いた内容をCocoaPodsプラグインにした。
やりたいこと
問題点と解決方法は、Qiitaに書いた記事と同様のため、引用ですませる。
問題点
iOS8でアプリ間でデータを共有する仕組みとしてAppGroupが導入された。カスタムキーボードやAppleWatchアプリ等の拡張は別アプリとなるため、これらを開発をする際はAppGroupの利用が事実上必須である。 (参考: http://www.toyship.org/archives/1845)
AppGroupは開発者アカウントごとのデータであり、かつ、世界中で一意となる名前を持たねばならない。 個人(Individual)アカウントは複数人で共有できないため、同じAppGroupを使うことができない。企業(Company/Organization)アカウントならばAppGroupの共有が可能だが、取得には法人である必要がある。
そのため、法人でない団体(例: 大学サークル等)では、AppGroupの利用が難しい。
解決策
以下の方針で、開発を複数人で行なえるようにする。
- 開発者ごとにAppGroup名/Bundle Identifierを変更する。
- AppGroup名/Bundle Identifierを具体的に書く箇所を一箇所にすることで、容易に変更できるようにする。
ただし、AppStoreに提出できるのは誰か一人という制約は解決できないため、誰かが正式版のビルド係/AppStoreへの提出係となる必要がある。
インストール
gem install cocoapods-app_group
初期設定
1. Podfile への追記
Podfile
に以下のように書いて、プラグインを有効にする。
source 'https://github.com/CocoaPods/Specs.git' platform :ios, '8.0' use_frameworks! plugin 'cocoapods-app_group'
2. App group名の指定
app group名を指定したのち、インストールする。
pod app-group GROUP_NAME
pod install
3. AppGroupを有効にする。
各ターゲットのcapabilityからAppGroupを有効にする。 その際、名前としてgroup.$(APP_IDENTIFIER)
を用いる。
使い方
import AppGroup AppGroup.userDefaults().setInteger(42, forKey: "answer") let n = AppGroup.userDefaults().integerForKey("answer")
JAWS-UG 名古屋 in AWS Cloud Roadshow 2015「Amazon EC2 スポットインスタンスを開発環境にする話」
キンドル(本物)がとどいたー。 pic.twitter.com/kNckUW3IzL
— mzp (@mzp) November 4, 2015
JAWS-UG 名古屋 in AWS Cloud Roadshow 2015 でLTをした。優勝してKindleをいただいた。
スライド
発表原稿
タイトルだけでだいたい内容が分かる気がしますが、話を進めます。
自己紹介
簡単な自己紹介をすると、TwitterIDはmzpです。MisocaというWebサービスを作る仕事をしています。このインフラにはAWSを利用していますが、今回はその話ではありません。ボク個人が使っているAWSの話です。
MacBook
ところで、先日、新型のMacBookを買いました。解像度が高くなり、軽くなり、バッテリーの持ち時間も伸びました。最高です。この資料もそのMacBookで作りました。
性能の低下
その反動として、マシンの性能が低下しました。 ベンチマークのスコアでみるとこんな感じです。
Intel Core M-5Y31&M-5Y71を搭載した新しいMacBook Retina 12インチモデルのGeebBenchスコア比較まとめ。 http://t.co/U1OrlqizRc pic.twitter.com/8quOSPO1PQ
— Appleちゃんねる (@applechinfo) April 3, 2015
前に使っていたのは2011年モデルのMacBookAirなので、ベンチマークスコアが少し落ちています。 言い換えると、4年前のPCを最新機種に買い変えたら、性能が若干落ちました。
開発に支障がでた
弊社のMisocaはRailsで開発されています。ゲーム系の開発などに比べるとマシですが、Railsの開発にもそれなりにの性能が要求されます。 それをこのMacBookで行なうのはかなり厳しいです。 念のため補足すると、オフィスにいるときは会社のiMacが使っているので特に不都合はない。困るのは、自宅で作業するときや、旅先で作業するときですね。
AWS EC2 スポットインスタンス
性能のいるマシンを必要なときだけ使うといえばAWSです。Amazon Workspaceで仮想デスクトップを使うのが定石な気もしますが、今回はEC2スポットインスタンスを使いました。
主な理由は以下の2つとおりです。
- 開発ではターミナルしか使わないのでsshで接続できればよい。
- 安い。
まあ、あとはスポットインスタンスを使ってみたかった、というのもあります。
費用
いつも使うc4.large((2CPU; メモリ 3.75GB)がだいたい0.02ドル/Hなので、一日8時間*20日使ったとしても3.2ドル程度です。もし倍必要になったら、その人はちょっと働き方を見直したほうがいい気がしますね..。働きすぎないようにBilling Alertで監視してもよいかもしれません。
構築時のコツ
構築する際のコツとしては
- AMIを事前に作っておく。
- 別途、EBSボリュームを作り、消えたら困るデータはそちらに置く。
- ポートは多めにあけておく。特に1024番以上はあけておいたほうがよいです。
詳しくはブログに書きました。 http://mzp.hatenablog.com/entry/2015/04/25/110043
ちなみに最初はこれをやらずに、毎回1からchef-soloで環境を作ってコードを書く、ということをやっていました。
利点
いざ使ってみると、思ってもいなかった利点がありました。
- マシンがAWS上にあるのでバッテリーが異様に持つようになりました。重い処理を回しまくっても、バッテリーが減らないのは快適ですね。
- 同じくAWS上にあるので、ネットワークもかなり速くていいですね。通信量も抑えられるので、テザリングしてても安心ですね。
- 開発に使うデータはそれほどセンシティブなわけではないんですが、ローカルにデータを保持しないのは安心感があります。
欠点
もちろんスポットインスタンスを使っているので、いつシャットダウンされるかわからないのは困った点です。 何度か価格の急騰に巻き込まれたりしました。 このときは一気に10倍近く値上がったときのやつです。
スポットインスタンスを開発環境にするのを試してたけど、価格が暴騰して死亡した。 pic.twitter.com/8Uww1Lmwv1
— mzp (@mzp) March 20, 2015
EBS上のデータは保持されますし、大事なコードそのものはgithub上にあるので、実際は困ることはそれほどありません。が、いつシャットダウンされるか分らないというのは精神的にキます。
まとめ
そろそろ時間なので、簡単にまとめます。