pslaboが試したことの記録

はてなダイヤリーからはてなブログに引っ越してきました

この日記は現在実行中の減量記録を含む個人的なメモとして始めましたが、最近はコンピュータやガジェット、ハック、セキュリティネタのほうがメインになっております。

はてなダイヤリー時代はカテゴリ分けが適当だったのですが、これはそのうち直します。


ブラウザを起動時からプライベートモードで利用する設定

Webアプリケーションの挙動をテストするときに、コンテンツやCookieがないキレイな状態から始めたい場合があります。しかしブラウザを起動時からプライベートモードやシークレットモードで動かす方法はブラウザごとに違うので整理してみました。

ブラウザ 設定方法
Firefox privatebrowsing.autostastをtrueに設定する
Chrome 起動時オプションに --incognito を指定する
Safari 環境設定の"一般"より"Safariの起動時"の設定を"新規プライベートウィンドウ"に設定する
Internet Explorer コマンドラインパラメータに -privateをつけて起動する
Edge (EdgeHTML) コマンドラインパラメータに -private をつけて起動する
Edge (Chronium) コマンドラインパラメータに--inprivateをつけて起動する

こうしてみると、Firefoxマルチプラットフォームで利用できて、なおかつデフォルトでプライベートモードで起動する設定を作りやすい気がします。

ChromeInternet Explorer, Edgeはコマンドラインパラメータに足すだけなので、プライベートモード用のショートカットを作っておけば使い分けは割と容易。

Safariは開発専用のmacOSを用意できるならアリだけど、そうではないならちょっと微妙。

macOSにVirtualBoxをhomebrewでインストール

サイトからインストーラをダウンロードして実行して、さらにExtension Packをインストールする、という手順が微妙にもどかしいので、brew でインストールする際のコマンドをログとして残しておきます。

brew cask install virtualbox
brew cask install virtualbox-extension-pack

iPad Pro 旧モデルの修理はAppleStore持ち込みではなくオンラインでの手続きの方が良いかもしれない

タイトルだけで用件が済む方はスルーしてください。

詳しく知りたい方はどうぞ

発端:タッチパネルの反応が悪くなった

紙媒体と同じレイアウトのPDF資料を読もうとすると、10インチ前後のiPadでは読みづらいという理由でiPad Pro 2G 12.9インチを使っているのですが、あるとき、iPadのタッチパネルを触っても反応しないことがあるのに気づきました。

具体的には次の症状が出ました。

  • ホーム画面からアプリを選択しようとしてもタップが認識されない
  • Safariでスクロールや拡大表示しようとしても操作できない
  • Google Keepで手書きメモを記入中に2本指操作でスクロールできなかったり、拡大縮小操作をピンチ操作で行おうとしても行えない(操作を認識しなかったり、拡大縮小した状態から指を話すと元のスケールに戻ったり)
  • Apple Pencilで手書き中の内容が、手書きメモを終了すると正しく保存できていない

これらの症状がだんだん悪くなってきたので、AppleStoreに持ち込むことにしました。AppleStoreならハードウェア診断したり、その場で修理対応や交換ができるかも、と思ったからです。

しかしいくつかの想定外の状況により、修理が完了しませんでした。

誤算1: タッチパネルのハードウェア診断はできない

Genius Barで聞いたところ、タッチパネルの不良に関するハードウェア診断はできないのだそうです。診断ツールでログをとることはできても、そのログからは調べられないのだとか。

この時点で持ち込み修理のメリットが半減した印象があります。

誤算2:iPad Proの修理は本体交換以外の選択肢がない

iPhoneのパネル破損だと店舗で修理できたりしますが、iPad Proは店舗では修理出来ず、本体交換となるそうです。これはたぶんそうではないかと予想してたのですが、その通りでした。

誤差3:iPad Pro 2G 12.9の交換用機材が店舗にない

iPhoneの持ち込み修理ではストックがあって、その場ですぐに交換できる場合が多いと思いますが、iPad Pro 2G 12.9は店舗になく、その場で交換できないということでした。

しかも新型コロナウィルスの影響で物流が滞っているので、入荷に時間がかかるのだそうです。

その場で交換修理できないなら、Genius Barを予約して持ち込む必要はなく、オンラインでの修理手続きでもよさげな気がします。

結果

とりあえず店舗では交換修理がすぐにはできない状況でしたが、iPadの現行モデルへの買い替えを提案されました。今のiPadはどれもApple Pencilに対応しているからProのスペックが不要なら、確かに買い替えの方が安くつくし、すぐに問題解決できるわけで、提案としては悪くないと思います。

だけど12.9インチのスクリーンサイズで資料のPDFを見たり、Macbookのサブディスプレイとして使いたいからこのサイズのデバイスを使っている身としては、iPadの10.2インチスクリーンには魅力がなく、Pro11インチでも大きさが少し足りない。だからこの提案は選択肢としてイマイチです。

そして使用中のモデルはCellularモデル+Apple Pencilの組み合わせだから、iPad Pro現行モデルでリプレースするとストレージが最小構成でも143,300円、11インチモデルでも121,300円、いずれもApple Careをつけない状態でコレなので、この費用はちょっと厳しい。

結局、同じモデルへの交換なら63,800円なので、今回は交換することにして交換機器の手配を依頼しました。交換機器が店舗に届き次第、もう一度店舗に行く必要があります。そうすると、結果的にはオンラインで修理申し込みした方が時間のロスがなくてよかったかも、というのがこの話の話のオチでした。

Sencha ArchitectでExt JS最新版向けに作成したプロジェクトをExt JS旧バージョンと組み合わせる

Sencha Architect で Ext JS 7.1 を選んで作り始めたプロトタイプを Ext JS 6.x 向けに変更する必要が出てきたので、とりあえずなんとかしてみた内容をログとして残します。

この手順はあくまで気休め程度に自己責任で試すやりかたです。過去バージョンでサポートされていない機能を含むプロジェクトは正しく動くわけがないので、動いたらラッキーくらいの立ち位置で。

サマリ

  • Sencha Architectのプロジェクトファイル(拡張子 xds)はプロジェクトで使用するツールキット(Modern, Classic)のバージョン情報を含む。

  • プロジェクトのアーカイブ(拡張子 xda)を作成する場合はアーカイブSDKを含めるかどうかを設定できる。そしてSDKを含まないアーカイブは、Sencha Architectで開いて保存するとき、必要なSDKがプロジェクト保存フォルダに保存される。

  • つまり、この仕組みを意図的に利用すれば、プロジェクトが使用するSDKのバージョンを変えることができる。

  • ただしこの仕組みは、プロジェクト自体にExt JS SDKが含まれない状態のプロジェクトファイルを開くときに

  • Sencha Architectのプロジェクトアーカイブのファイルフォーマットはzipなので、単にzipアーカイブツールで展開すれば内包されているxdsファイルを編集できる

手順

Sencha Architectでプロジェクトを Archive として保存する

  • FireメニューからArchive Projectを選ぶとxdaファイルを生成できる。
  • 保存時にSDKを含むアーカイブにするかどうかを聞いてくるので、SDKを含まないアーカイブで生成する

xda ファイルをzipとして展開する

  • ファイル名の拡張子を単純に zip にすれば、OS標準の機能でzipファイルを展開できる

展開後のフォルダに含まれるxdsファイルをエディタで編集する

xdaファイルに下記のような箇所があるはずなので、探して修正する。

{

    "settings": {
        // ここは "cmd": {}, のように中身を消してしまう。
        "cmd": {
            "cmdVersion": "7.1.0.16",
            "license": "commercial",
            "frameworkVersion": "7.1.0.48"
        },
        ...
    },
    ...
    // このフレームワーク指定の部分を ext67 などに書き換える。Classic Toolkitはext71、Modern Toolkitはmodern71のように表記する。
    "framework": "ext71",
    ...
}

書き換えた xda ファイルを Sencha Architect で開くと、指定した旧バージョンを使用するプロジェクトとして開くようになる

  • Ext Premium Addons を使用していないプロジェクトの場合は単にセーブすればプロジェクトディレクトリに指定したバージョンの Ext JS SDK が展開される
  • Ext Premium Addons を使用している場合はプロジェクトに追加することでプレビューが正しくするようになる。

IMEで入力できる言語、キーボードだけで入力できる言語

なんとなくのまとめ。 興味本位でざっくり調べただけなのであまり意味は無い。

厳密にいうと、WindowsmacOSではサポートが違うはずだから、そこも含めて調べるべきと思うけど、そこまでのモチベーションがありません。

スマートフォンはそもそもソフトウェアキーボードなので対象外です。

IMEで入力できる言語

言語 入力方法
日本語 ローマ字入力、かな入力して漢字変換する
韓国語 ハングルを子音、母音の組み合わせで入力
中国語(簡体字 アルファベットでピンインを入力して候補から探す
中国語(繁体字 Windows10ではいろんな入力方法がサポートされているようだが、ちゃんとしらべていない

IMEを使用せずキーボードで入力できる言語

言語 入力方法
英語
ドイツ語
フランス語
ロシア語
デンマーク
イタリア語
ポルトガル語
スペイン語

モバイルPASMOについて考察する

※考察内容は不定期に更新しています。

モバイルPASMOAndroid向けサービスに関するリリースが2020年1月に出てから、いろいろと期待が高まりますが、自分なりに現時点で考察した内容をまとめてみました。

当たるかもしれないし当たらないかもしれないけれど、こういうのは自分の推測した内容と実際の事実がどのように合致して、どのように合致しないかを照らし合わせてみるだけでも面白いと思うので、ざっくりまとめます。

ちなみに考察の中にはAndroidアプリ開発に関するキーワードも出てきますが、私はモバイルアプリ開発DelphiAndroid/iOSアプリを開発したり、Sencha Architect で Ext JS ベースのプロジェクトをCordova/PhoneGAPでビルドする程度のことしかしていないので、Androidアプリ開発はできるけど、がっつり開発しているわけではありません。

Android:モバイルPASMOモバイルSuicaを併用できるかどうか

たぶん不可能ではないかと推測しています。

まず、モバイルSuicaおサイフケータイの「鉄道・バス領域」を189ブロック使用する。しかし「鉄道・バス領域」は全部で345ブロックしかないので、モバイルPASMOを残り156ブロックに追加することはおそらくできない。

もし共存できるとしたら、モバイルSuicaとモバイルPASMOの両方で共通する部分、しない部分をうまい具合に管理して、モバイルPASMOで必要となる部分だけを残りの156ブロックに割り当てるという方法が取れる場合だろうと思う。

次に、Androidおサイフケータイには使用するカードを明示的に指定するモードがないので、2種類の交通系ICカードをインストールして使い分けるということができない。

おサイフケータイ領域の消費ブロック数問題とカードの明示的な切り替え機能の両方が解決したら併用可能になるかもしれないが、これはあまり期待できない。もしこれが実現するとしたら、おサイフケータイの仕様やGoogle Pay の機能変更を伴う対応が必要になるだろうから、すでにリリース済み端末ではこのような対応が行えず、利用可能な端末が新しい機種に限られるか、または旧機種向けと新機種向けで別アプリをリリースせねばならないだろう。容量の問題が解決でき、Google Payのアプリでどの交通系ICカードをアクティブにするかを変更できるようなアップデートが行われるなら実現の見込みがある。

この様な改修はコスト的にメリットがなさそうなので、このような変更は行われず、モバイルSuica/モバイルPASMOのいずれか1つだけをインストールできるという状況になると考えられる。

技術的な理由で共存ができないなら、よく使うカードどちらか1枚を登録せざるを得ないけど、乗車券としての機能でSuicaだけで利用できた機能がPASMOでも利用できるようになれば実用上の問題がないので、おそらくそのようなサービス改訂が行われるのではないだろうか。たとえば、JR東日本モバイルSuicaJR東日本管内の新幹線に乗車できる「モバイルSuica特急券」は3/14以降はサービス改訂によりPASMOその他の交通系ICカードで利用できるサービスに変わるので、モバイルSuicaの利用者がモバイルPASMOに切り替えたとしても利便性は変わらない。

Android:鉄道・バス領域の容量の問題がなく、モバイルSuica導入済みの端末にモバイルPASMOを追加できるとしたら、使い分けはどのようになるか?

この仮定自体がおそらく無意味であり、SuicaPASMOは同時にはインストールできない可能性が高いが、使い分けが可能になるとしたらGoogle Payのアップデートによって可能となるのではと考えられる。Google Payは2015年以降に提供開始されているが、2015年というとAndroid 6がリリースされた年でもあります。そしてモバイルPASMOAndroid 6以降の端末が対象なので必然的にGoogle Payの仕組みに乗っかっている。ならばGoogle Pay側が使用する交通系ICカードの明示的な指定に対応しさえすれば切り替えは可能になる。

ここで疑問符が付くとしたら、Android 6向けのアップデートをGoogleがそもそもやるかどうかの話。AndroidバイスのOSバージョンのユーザー比率は最新よりも古いバージョンにピークがあり、シェアの高い順にバージョンを並べると 8→7→6→5の順に並びます。Google PayはAndroid 6以降で提供されていたと思いますのでモバイルPASMOの対応予定バージョンとも符合します。

具体的な数字でいうと、2020年2月時点のシェア率はこういう割合です。

バージョン シェア率
5 14.50%
6 16.90%
7 19.20%
8 28.30%
9 10.40%

もうちょっと正確なシェア率はこちらのダッシュボードで見れます。developer.android.com

さて、Google Playでアプリ公開する場合は現在は APIレベル28(Android 9)サポートが必要なはずなので、原則論から言えばこれから新規公開されるであろう、モバイルPASMOアプリはAndroid 9以降の端末しかターゲットにできないはずです。一方で Google Pay アプリはGoogle のアプリだし、既存アプリなのでこの制約は受けない。そしてモバイルPASMOGoogle Payアプリ側からみれば利用できるICカードの種類が増えるだけ(と言い切ってよいかどうかは微妙。。。)なので、無記名PASMOカードとして使う分にはGoogle Payアプリ側だけで対応できるのでしょう。

ただし新規公開アプリがAndroid 9をターゲットにせねばならない前提を厳密に適用するとAndroid6-8にはモバイルPASMOアプリが提供できず、カードを新規発行できるけど退会できないという謎仕様のサービスになってしまう。(少なくともモバイルSUICAを完全に止めるにはモバイルSUICAアプリからの退会手続きが必要)

そのように考えると、Google PayとモバイルPASMOアプリの両方がAndrod 6以降で正しく利用できるようにアップデートされるか、またはGoogle Payアプリ単独で交通系ICカードの退会手続きが行えるように改修されるのではないかと推測する。そうするとGoogle Payアプリでの交通系ICカードの切り替え利用の機能が含まれることも期待できる。

まあ、すべては共存できるかどうか次第なのですが。

iPhone:モバイルPASMOモバイルSuicaを併用できるかどうか

モバイルPASMOiOS向けに提供開始されるとしたら、モバイルSuicaと併用できる可能性がある。

そのように考える理由は、現状でもiPhoneでは最大3枚のSuicaが扱えることや、そのいずれかのカードをTouchID/FaceIDの認証なしに使えるエクスプレスカードとして設定できること。

iPhoneモバイルSuica対応は最大3枚のSuicaを登録できるため、複数枚のSuicaの使い分けを、仕事用とプライベート用、電車乗車用と買い物用などで切り替えているケースもあると思います。しかしこの機能は発行元が異なる複数のサービスに対応している可能性を考えたほうが良いと思われる。

もし、発行元が違う交通系ICカードを複数収容でき、そのどれかをエクスプレスカードとして指定できるなら、モバイルPASMO/モバイルSuicaの使い分けは適切に行うことが可能。

もしモバイルPASMOモバイルSuicaを同時に収容出来ないとしても、どちらかを排他的に登録することはできるだろうし、モバイルsuicaを端末から削除してAppleIDにバックアップし、モバイルPASMOを別途発行することができるのではと推測します。

iPhone向けのモバイルPASMOはいつごろ提供開始されるだろうか?

iPhoneモバイルSuica対応が明らかになったのは、iPhone7の製品発表(2016/9/8)の時であり、実際にサービス提供開始されたのは10月下旬でした。それより前の段階でiPhoneへのモバイルSuica対応の話は確定した情報としては全く出ていませんでした。

ここでPASMO/Suicaの2020年のタイムラインを少し整理してみると、次のようなスケジュールが見えてきます。2020年3月はモバイルPASMOの件だけではなく、モバイルSuicaでもサービス内容の変更が予定されています。だから2020年3月14日までに何らかの発表があり、2020年春(3/14以降)にAndroid/iPhoneの両方でモバイルPASMOが利用できるようになる、というのがもっとも可能性の高いスケジュールのように思えます。

時期 内容
2020年3月上旬 Android向けモバイルPASMOに関する詳細を発表予定 (このあたりでiPhone向けモバイルPASMO対応の発表も行われるかも?)
2020年3月14日 新幹線eチケットサービス開始に伴い、モバイルSuica特急券えきねっとが統合、新しいサービスではPASMOでもJR東日本の新幹線を利用できるようになる
2020年春 Android向けモバイルPASMOサービス開始(Suica側の変更にあわせて3/14開始?)

日本では通勤通学定期券の買い替え時期が春と秋に集中しますから、この時期にAndroid/iPhoneのモバイルPASMOサービスを両方とも開始するのはサービスの垂直立ち上げという観点では理にかなっています。

しかし、一方で、あえてこの時期を避けてiPhone向けサービス開始を遅らせなければならない理由があるかもしれません。

iPhoneモバイルSuicaに対応した際も、多くのユーザが物理カードからモバイルSuicaへの切り替えを行ったことでトラブルがありました。多くのユーザがモバイルPASMOのサービス開始直後に物理カードのPASMOをモバイルPASMOに移行すると同じ問題が起きる恐れがあります。だからユーザー移行の時期を分散させたいという意向は当然あるはずで、このときにAndroidiPhoneでサービス開始時期を分ければユーザ移行のトラフィックは半分程度になると考えられますので、iPhone向けサービス開始をあえて後ろ倒しにするというのも十分に合理的な判断です。

またiPhone利用者がモバイルPASMOのためだけにAndroidに乗り換えるかというと、そうではなく、むしろアーリーアダプタな方がモバイルPASMO用の端末を買い足すのではないでしょうか。かく云う自分もSIMフリーおサイフケータイ対応Androidを所有しているので、どうしてもモバイルPASMOをサービス開始直後から使いたいならそちらにセットアップします。

Google Chrome のアドレスバーからSalesforceの情報を直接検索できるようにする

Salesforceで顧客情報や商談情報を検索したいときに、Salesforceの画面を開いて検索のテキストボックスに入力するのはテンポが良くないと思うので、Google Chromeのアドレスバーから検索できるようにしてみます。

Google Chrome のアドレスバーに検索機能を追加する方法を確認しておく

Google Chrome ではアドレスバーで複数の検索エンジンを必要に応じて切り替えて利用できます。 この切り替えは、検索エンジンを選択するキーワードを入力するだけで行えます。 たとえばアドレスバーにyahoo.co.jpと入力してタブキーを押し、さらに検索ワードを入力するとYahoo Japanでの検索結果が表示されます。

この設定は chrome://settings/searchEngines で管理されており、検索エンジン名、検索エンジンを選択するキーワード、クエリURLの3つの組み合わせが管理されています。

そこで、たとえば検索エンジン選択のキーワードを sf と設定し、Salesforceで検索実行するURLをクエリURLに設定すれば、アドレスバーから sf と検索ワードを入力するだけでSalesforceの検索を実行できるわけです。

詳細についてはこちらのページをお読みいただくと良いでしょう。

support.google.com

Salesforceの検索結果ページのURLパラメータを調べてみる

Salesforceにログインして、何かのキーワードで検索してみると検索結果のURLは 次のように表示されました。

https://[SalesforceのURL]/_ui/search/ui/UnifiedSearchResults?searchType=2&………&str=何かの検索キーワード

パラメータが沢山ついているのですけど、最終的には str=xxxx で検索が行われていることが分かります。つまり、次の文字列をクエリURLとして登録すれば検索が行えます。

https://[SalesforceのURL]/_ui/search/ui/UnifiedSearchResults?searchType=2&………&str=%s

でも、ちょっと長すぎる気がしますので、次のように実行できないか試してみました。

https://[SalesforceのURL]/_ui/search/ui/UnifiedSearchResults?str=何かの検索キーワード

すると自分の環境ではこれでも検索結果が表示されました。ただし最初に行った検索結果よりも詳細な情報が表示されるようになりました。どうやら、普通に検索実行するときのクエリパラメータは検索結果の種類に対する絞り込みが設定されているようです。

どちらを利用するかは好みの問題なので、使いやすいと思うほうをクエリURLとして登録すれば良いと思います。