読者です 読者をやめる 読者になる 読者になる

ThinkPad T460s Ubuntu でトラックパッドを無効化

Linux Ubuntu

5ヶ月ほど ThinkPad T460s を Ubuntu(Xubuntu) で使ってます。

ちょっと前に さよならMac | めがねをかけるんだ という ThinkPad をdisった記事が話題になりましたが、自分はあんまり不満はありません。 ノートPCでLinuxを使う時の鬼門だった無線LANやサスペンドもまったく問題ありません。 当然トラックパッドは無効にしています。

唯一の不満がこのトラックパッド無効化です。

トラックパッドを無効にしようとBIOSで無効に設定しても無効になりません。

しょうがないので、Xubuntu の設定の「マウスとタッチパッド」でタッチパッドの設定を無効化します。

f:id:tmtms:20170218135347p:plain

これでトラックパッドが無効になってめでたしめでたし。

…と思ったのですが、しばらく使ってると、時折トラックポイントのボタンをクリックしても効かないことがあります。

どうやらトラックパッドに触れているとボタンのクリックイベントを取りこぼすようでした。 トラックパッドを無効にしていたので、それが原因だとなかなか気がつきませんでした。

トラックパッドに二本以上の指が触れているとかなりの確率でボタンのクリックイベントを取りこぼしてしまいます。

どうやら psmouse ドライバのインストール時に proto=bare を指定するとトラックパッドを完全に無効化できるようです。 というより proto=bare ではトラックパッドを扱えないというだけな気がします。

# modprobe -r psmouse
# modprobe psmouse proto=bare

これでトラックパッドに触れていてもボタンクリックを取りこぼすことはなくなりました。

…が、もうひとつ問題が。

proto=bare ではトラックポイントの感度と速度の調整ができません。

proto=bare を指定しない時は、次のようにして感度と速度を調整できました。

# echo 200 > /sys/devices/platform/i8042/serio*/serio*/sensitivity
# echo 200 > /sys/devices/platform/i8042/serio*/serio*/speed

proto=bare で psmouse をインストールした時は、この sensitivity, speed ファイル自体ありません。

色々試行錯誤したところ、proto=bare をつけずに psmouse をインストールして、感度と速度を調整した後に proto=bare をつけて psmouse を再インストールすると感度と速度が保持されたままになることがわかりました。

とりあえず、簡単なシェルスクリプトを作って、電源ON時やサスペンドからの復帰時に走らせてます。

#!/bin/bash
DIR=/sys/devices/platform/i8042
SPEED=200
SENSITIVITY=200

# echo が刺さることがあるので1秒でタイムアウトさせる
sub() {
    (echo $1 > $2) &
    pid=$!
    (sleep 1; kill $pid) &
    pid2=$!
    wait $pid
    kill $pid2
}

modprobe -r psmouse
modprobe psmouse proto=any
while :; do
    sleep 0.3
    speed=$DIR/serio*/serio*/speed
    test -f $speed || continue
    sens=$(dirname $speed)/sensitivity
    test -f $sens || continue
    sub $SPEED $speed
    test "$(cat $speed)" -eq $SPEED || continue
    sub $SENSITIVITY $sens
    test "$(cat $sens)" -eq $SENSITIVITY || continue
    break
done
modprobe -r psmouse
modprobe psmouse proto=bare

Unicode Collation Algorithm

MySQL

文字コードは面白いね! わーい! たのしー!

🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾

MySQL で utf8mb4_unicode_ci コレーションを使用した時に「🍣」=「🍺」や「ハ」=「パ」になる問題があります。

この utf8mb4_unicode_ci ってなんぞや?と思ってマニュアルを見てみると、

MySQL は、http://www.unicode.org/reports/tr10/ で説明している Unicode 照合順序アルゴリズム (UCA) に従って xxx_unicode_ci 照合順序を実装します。照合順序は、バージョン 4.0.0 UCA 重みキー (http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt) を使用します。

https://dev.mysql.com/doc/refman/5.6/ja/charset-unicode-sets.html

とあります。

Unicode には Unicode Collation Algorithm (UCA) という標準があり、MySQL の utf8mb4_unicode_ci は UCA のバージョン 4.0.0 を使用しています。

UCAのドキュメントをちゃんと読んだわけではないので以下の説明はテキトーです。

各文字の比較レベルを定義したテーブルは Default Unicode Collation Element Table (DUCET)と呼ばれて UCA のバージョン毎に提供されています。

UCA 4.0.0 の DUCET の中味はこんな感じです。

0061  ; [.0E33.0020.0002.0061] # LATIN SMALL LETTER A
FF41  ; [.0E33.0020.0003.FF41] # FULLWIDTH LATIN SMALL LETTER A; QQK
0363  ; [.0E33.0020.0004.0363] # COMBINING LATIN SMALL LETTER A; QQK
249C  ; [*0288.0020.0004.249C][.0E33.0020.0004.249C][*0289.0020.001F.249C] # PARENTHESIZED LATIN SMALL LETTER A; QQKN
1D41A ; [.0E33.0020.0005.1D41A] # MATHEMATICAL BOLD SMALL A; QQK

左端の16進数はUnicodeのコードポイントを表し、その次の [ ] で括られた4つの16進数は文字の比較レベルを表します。

レベルは左から順に次のようになっています。

L1 Base characters 基本文字
L2 Accents アクセント
L3 Case/Variants 大文字小文字/異体字
L4 Punctuation 句読点(?)

いくつか抜粋してみます。左に文字をつけました。

a 0061 ; [.0E33.0020.0002.0061] # LATIN SMALL LETTER A
FF41 ; [.0E33.0020.0003.FF41] # FULLWIDTH LATIN SMALL LETTER A; QQK
24D0 ; [.0E33.0020.0006.24D0] # CIRCLED LATIN SMALL LETTER A; QQK
A 0041 ; [.0E33.0020.0008.0041] # LATIN CAPITAL LETTER A
FF21 ; [.0E33.0020.0009.FF21] # FULLWIDTH LATIN CAPITAL LETTER A; QQK
å 00E5 ; [.0E33.0020.0002.0061][.0000.0043.0002.030A] # LATIN SMALL LETTER A WITH RING ABOVE; QQCM
Å 00C5 ; [.0E33.0020.0008.0041][.0000.0043.0002.030A] # LATIN CAPITAL LETTER A WITH RING ABOVE; QQCM
b 0062 ; [.0E4A.0020.0002.0062] # LATIN SMALL LETTER B
FF42 ; [.0E4A.0020.0003.FF42] # FULLWIDTH LATIN SMALL LETTER B; QQK
B 0042 ; [.0E4A.0020.0008.0042] # LATIN CAPITAL LETTER B

「a」っぽい文字は L1=0E33 で「b」っぽい文字は L1=0E4a になっています。

Å」は複数のレベルを持ち、1個目のレベルは「A」とまったく同じで、2個目のレベルは合成文字用の「˚」です。 NFD正規化された状態(?)でレベルが表されます。

L1 や L1+L2 で比較すると「a」「」「A」「」は同じ文字として扱われます。 L1+L2+L3 で比較すると異なる文字として扱われます。

文字の比較にどのレベルまで使用するかはアプリ次第で、MySQL の utf8mb4_unicode_ci では L1 しか使用していません。 そのため、英字は大文字/小文字/全角/半角は区別されません。

は=ぱ=ば=ハ=パ=バ

で、問題の「は」「ぱ」「ば」「ハ」「パ」「バ」ですが、次のようになっています。 濁点/半濁点つきの文字は正規化されて、清音文字+濁点文字の2つのレベルの組み合わせで表されてます。

306F ; [.1E6B.0020.000E.306F] # HIRAGANA LETTER HA
3071 ; [.1E6B.0020.000E.306F][.0000.0141.0002.309A] # HIRAGANA LETTER PA; QQCM
3070 ; [.1E6B.0020.000E.306F][.0000.0140.0002.3099] # HIRAGANA LETTER BA; QQCM
30CF ; [.1E6B.0020.0011.30CF] # KATAKANA LETTER HA
30D1 ; [.1E6B.0020.0011.30CF][.0000.0141.0002.309A] # KATAKANA LETTER PA; QQCM
30D0 ; [.1E6B.0020.0011.30CF][.0000.0140.0002.3099] # KATAKANA LETTER BA; QQCM

これらの文字は L1 レベルでは同じレベルなので、L1 でしか使用しない MySQL の utf8mb4_unicode_ci では区別されないことになります。

「は」「ぱ」「ば」だけでなく「か」「が」や「さ」「ざ」も区別されません。

日本語としては、清音、濁音、半濁音をそれぞれ区別するのが自然ですが、Unicode の標準の規則にしたがった Case insensitive だと区別できません。

utf8mb4_japanese_ci の登場に期待したいところです。

🍣=🍺

絵文字の比較はまた事情が異なります。DUCET には絵文字は定義されていないのです。実は漢字も定義されていません。

UCA では DUCET に定義されていない文字の扱い方も定めています。(7.1.3)

AAAA = BASE + (CP >> 15);
BBBB = (CP & 0x7FFF) | 0x8000;
CP => [.AAAA.0020.0002.][.BBBB.0000.0000.]

BASE:
FB40 CJK Ideograph
FB80 CJK Ideograph Extension A/B
FBC0 Any other code point

「漢」という文字のCP(Code point)はU+6F22なので、[.FB40.0020.0002.][.EF22.0000.0000] となります。 この2つのレベルを組みわせて使用します。

mysql> SELECT HEX(WEIGHT_STRING('漢'));
+---------------------------+
| HEX(WEIGHT_STRING('漢'))  |
+---------------------------+
| FB40EF22                  |
+---------------------------+

同じように「🍣」と「🍺」の値を求めると 「🍣」(U+1F363)は FBC3F363となり、「🍺」(U+1F37A)はFBC3F37Aとなるので、区別できるはずです。

ところが MySQL の utf8mb4_unicode_ci では、絵文字についてはそれに従わず、FFFD にしてしまっています。

一般的な照合順序の補助文字の場合、重みは 0xfffd REPLACEMENT CHARACTER の重みです。UCA 4.0.0 照合順序の補助文字の場合、照合重みは 0xfffd です。

https://dev.mysql.com/doc/refman/5.6/ja/charset-unicode-sets.html

mysql> SELECT HEX(WEIGHT_STRING('🍣'));
+-------------------------+
| HEX(WEIGHT_STRING('?')) |
+-------------------------+
| FFFD                    |
+-------------------------+

つまり、utf8mb4_unicode_ci で 🍣=🍺 となるのは Unicode のせいではなく、MySQL の問題です。

なお、utf8mb4_unicode_520_ci ではちゃんと計算された値を使用しています。

mysql> SET NAMES utf8mb4 COLLATE utf8mb4_unicode_520_ci;
mysql> SELECT HEX(WEIGHT_STRING('🍣'));
+-------------------------+
| HEX(WEIGHT_STRING('?')) |
+-------------------------+
| FBC3F363                |
+-------------------------+
mysql> SELECT HEX(WEIGHT_STRING('🍺'));
+-------------------------+
| HEX(WEIGHT_STRING('?')) |
+-------------------------+
| FBC3F37A                |
+-------------------------+

MySQLの文字コード事情

MySQL

この前 MySQL Casual に登壇して、「MySQLの文字コード事情」と称して発表してきました。

終電の都合で途中退席しましたが楽しかったです。また機会があれば参加したいです。

発表スライドはこちら

www.slideshare.net

以下、補足のような何か。

「Charset≒エンコーディング (MySQLに限らない)」

英語版のWikipediaでもcharsetCharacter encoding にリダイレクトされます。

自分がcharsetという用語に出会ったのはおそらくメールのContent-Typeヘッダが初めてだったと思います。 今ではメールだけではなくHTTPのヘッダでも使用されています。

なお、CharsetはInternet Assigned Numbers Authority(IANA)という組織で管理されています。http://www.iana.org/assignments/character-sets/character-sets.xhtml

ujis

MySQLで日本語を使用できるようになった時にEUC-JPエンコーディングのcharsetの名前をujisとしてしまったのは自分です。ゴメンナサイ。

いや、今でこそEUC-JPの方がメジャーでujisなんてもう見かけないんですけど、1998年当時はeucJPとujisのどちらも使われたんですよ。(あと ujis と sjis で韻を踏んでいていいかなーとか…)

EUCは Extended Unix Code の略で、ujisは Unixized JIS の略です。ググってみたら ujis の方が EUC-JP よりも歴史は古いようですね。

「歴史的には、まず「日本語EUC」の元 (ujis) があって、その工夫を I18N 的枠組に拡張したものが EUC」

http://naruse.hateblo.jp/entry/20090308/1236517235

「ふつうはutf8mb4」

とスライドには書きましたが、cp932を使うメリットも無いことはないです。

UTF-8は日本語の文字は普通3バイトですがCP932は2バイトです。 つまりディスクやメモリの消費量がUTF-8に比べて2/3で済むということです。

扱える文字が Windows-31J の範囲の文字だけで良くて、少しでも資源を節約したいのであれば、cp932を使用するのもいいかもしれません。

🍣=🍺問題とCollation

伝統的にMySQLは標準で大文字小文字を区別しないので、ci(Case Insensitive)を使いたくなってしまうのですけど、PostgreSQL とかは普通に大文字小文字は別の文字扱いだし、実は MySQL も utf8mb4_bin でも全然問題ないのかもしれません。

utf8mb4_bin であれば🍣=🍺問題も、ハハ=パパ問題も発生しませんし。

‘🍣’=‘🍺’=‘�’

MySQLで同じ文字とみなされるかどうかは WEIGHT_STRING() という関数の戻り値が同じかどうかで確かめられます。

SET NAMES utf8mb4 COLLATE utf8mb4_general_ci;
SELECT HEX(WEIGHT_STRING('🍣'));  -- => FFFD
SELECT HEX(WEIGHT_STRING('🍺'));  -- => FFFD
SELECT HEX(WEIGHT_STRING('�'));  -- => FFFD

SET NAMES utf8mb4 COLLATE utf8mb4_unicode_520_ci;
SELECT HEX(WEIGHT_STRING('🍣'));  -- => FBC3F363
SELECT HEX(WEIGHT_STRING('🍺'));  -- => FBC3F37A

SET NAMES utf8mb4 COLLATE utf8mb4_bin;
SELECT HEX(WEIGHT_STRING('🍣'));  -- => 01F363
SELECT HEX(WEIGHT_STRING('🍺'));  -- => 01F37A

utf8mb4_bin の場合は Unicode のコードポイントがそのまま使用されるようです。

「'パ'=‘パ'」と「'パ’ LIKE ‘パ'」

半角カナの「パ」は「ハ」と「゚」の二文字で構成されていますが、unicode_ci では一文字の「パ」と一致します。

SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;
SELECT 'パ'='パ'; -- => 1

ですが、LIKE では一致しません。

SELECT 'パ' LIKE 'パ'; -- => 0

SQL 標準では、LIKE は文字ごとに一致を実行するため、= 比較演算子とは異なる結果が生成される可能性があります。

https://dev.mysql.com/doc/refman/5.6/ja/string-comparison-functions.html#operator_like

…ということのようです。

Unicode Collation Algorithm

そのうち書きたい(書くとは言ってない)。

書いた

ThinkPad T460s 購入

Linux ThinkPad

ちょっと前ですが ThinkPad T460s を買いました。

軽いPCが欲しくて、1kg前後のPCを探したりしてたんですけど、ThinkPad T460s が 10万円以下で買えるようになったので値段に負けました。

購入したモデルはこんな感じです:

  • Core i5-6200U (2.30GHz, 3MB)
  • ディスプレイ 14.0 FHD (1920x1800 IPS)
  • メモリー 12GB (4GB + 8GB)
  • 日本語キーボード
  • 指紋センサーなし
  • SSD 256GB
  • 1.36kg
  • 米沢生産
  • 102,211円

9/25 に注文して 10/7 に届きました。

振り返ってみると16年くらいずっと ThinkPad です。

前に使ってた ThinkPad X220 よりも画面が広くて薄くて軽くていい感じです。

X220 の時は Xubuntu 使っててサスペンド&レジュームが不安定で良くフリーズしたり、bluetooth マウスの接続がうまくいかなかったりしたんで、新しい PC では Windows の上に仮想マシンで Linux Desktop を動かそうと考えていました。

ということで初めは VirtualBox に Xubuntu 入れてフルスクリーンでデスクトップを使ってみましたが、 トラックポイントの中ボタンをクリックとスクロールの両方で使えなかったり、動画が見れなかったり。

VirtualBox の代わりに VMware Workstation Player で試してみたら動画はちゃんと見れるようになったのですが、トラックポイントの動きは変わらず。

トラックポイントのはどうも Linux か X の制御の問題のような感じでした。

それでもしばらくは Xubuntu on VMware on Windows で使おうと思ってたのですが、突然 Windows update によって勝手にリブートされたので、嫌になって直接 Xubuntu を動かすようにしました。そしたらサスペンドも bluetooth も普通に動いたので拍子抜け。

一応 Windows は残してデュアルブートできるようにしてあります。ヘタレなので。

Firefoxで絵文字が白黒で表示される

Linux Ubuntu Firefox

Firefox 50 で絵文字に色がつきました。

次のようなテキストファイルを表示すると

🍣と🍺

次のように表示されるようになりました。

f:id:tmtms:20161123163111p:plain

ですが、Ubuntu で次のファイルを表示すると

🐭🐮🐯🐰🐲🐍

次のように「🐭」と「🐮」だけ白黒で表示されてしまいました。

f:id:tmtms:20161123163115p:plain

どうやら、OSのフォントに該当する文字があればそれが優先されるようです。

Dejavu Sans フォントに該当するフォントが入ってるようなので、それを読ませないようにすればいいようです。

% sudo apt purge fonts-dejavu-core

ちゃんと色付きで表示されるようになりました。

f:id:tmtms:20161123163119p:plain

なお、fonts-dejavu-core を削除すると、合わせて xubuntu-core や xubuntu-desktop も削除されてしまいますが、これらはメタパッケージなので特に問題ありません。 それが嫌な場合は、要するにフォントファイルを見せなければいいので、次のようにするだけでも良いようです。

% sudo chmod 000 /usr/share/fonts/truetype/dejavu

[追記]

font-manager を使って Dejavu Sans のチェックボックスを外すことで無効に出来ます。 そのユーザーだけに影響してシステムには影響しないため、上記の方法よりも望ましいと思います。

どのフォントファイルに定義されているのかを調べる

「🐭」と「🐮」がどのフォントファイルで定義されているか調べるのにいくつかツールを使ってみました。

gnome-font-viewer

特定の文字しか表示されないのでダメでした。

fontforge

UIが使いづらかったのでやめました。

gnome-specimen

そのフォントに定義されていない文字はデフォルトのフォントで表示されるようなので使えませんでした。

font-manager

これで見つけることができました。

waterfall

ちょっと使いにくかったですが、これでも見つけられました。

Ruby の Enumerable#sum

Ruby

最近のruby-core (2016年7月)」に次のような記述がありました。

Enumerable#sum というメソッドが追加されており、特定の場合(浮動小数点数の配列とか)には誤差が累積しないアルゴリズムが採用されています。

Ruby 2.4 に Enumerable#sum が追加されたのは知ってましたが、「誤差が累積しない」というのは知りませんでした。

というか、元々誤差が累積しない加算の目的で追加されたものだったのですね(最近のruby-core (2016年3月))。単純に 「#inject(:+)」にわかりやすい名前をつけただけなのかと思ってました。

簡単に試してみます。浮動小数点演算で、0.1を10個足すと1.0にならないというのはよく知られていますね。

> 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1
=> 0.9999999999999999

> [0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1].inject(:+)
=> 0.9999999999999999

> [0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1].sum
=> 1.0

sum を使った場合はちゃんと 1.0 になりました!

軽く Ruby のソースを眺めてみたのですが、Array#sumEnumerable#sum とは別に実装されていました。 ロジックは同じようなのでおそらく高速化のためだと思います。

ソースのコメント中に次のように書かれていました。

Array#sum method may not respect method redefinition of "+" methods such as Fixnum#+.

数値クラスの + メソッドを上書きしても sum メソッドでは効かないようです。

sum メソッド中の数値の足し算は C レベルでやってるので Ruby で定義したメソッドが呼ばれないのですね。

「合計を返すとは言ったが + を使うとは言ってない!」( ー`дー´)キリッ

試してみます。

class Integer
  # a + b で a * b の結果を返す
  def +(other)
    self * other
  end
end
p 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1  #=> 1
p [1, 1, 1, 1, 1, 1, 1, 1, 1, 1].sum     #=> 10

sum メソッドのループの実装は、次のようになっているようです。

  1. Integer または Rational オブジェクトの間繰り返し。それ以外のオブジェクトが現れたら 2 へ。
  2. Integer, Rational, Float オブジェクトの間繰り返し(ここで誤差が累積しないアルゴリズムが使用される)。それ以外のオブジェクトが現れたら 3 へ。
  3. + メソッド呼び出しを繰り返し。

ということで、次のように数値オブジェクトではないものが配列にあると、それ以降は「誤差が累積しないアルゴリズム」は使われません。

class A
  # 最初に 0 + self が呼ばれるので 0.0 を返す
  def coerce(other)
    [other, 0.0]
  end
end

p [A.new, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1].sum  #=> 0.9999999999999999

まあ、わざわざこんなことする人がいるとは思えませんけど。

Suica対応スマホに変更

Android

f:id:tmtms:20160919235256j:plain

データ通信用のスマホの他に、通話とモバイルSuicaのためにガラケー(F-01E)を持っていたのですが、ガラケーの2年縛りの契約の更新時期になりました。最近SIMロックフリーのスマホでもSuicaが使えるものが出てきたので、1台にまとめました。

arrows M03 の評判が良いみたいだったのでそれにしました。宗教上の理由で iPhone 7 ではありません。

今までも NifMo を使ってたし、キャッシュバックキャンペーン をやっていたので、NifMo で購入。

月々の維持費はこんな感じです。(税抜き)

docomo タイプシンプルバリュー 1483円
docomo ひとりでも割50         -740円
docomo iモード                 300円
NifMo SMS対応3GB              1050円
------------------------------------
合計                          2093円

NifMo 音声通話対応3GB         1600円
スマホセット割                -200円
arrows M03                    1482円 (24回払いの月額)
キャッシュバック              -416円 (1万円を24分割した値)
------------------------------------
                              2466円

2年経過後は 1600円/月 になる予定。

NifMo は「NifMo バリュープログラム」というのがあって、アプリをインストールしたりショッピングしたりすると料金が割り引かれるみたいなんですけど、面倒なのでやってません。

ただ、「勝てばスマホ利用料が安くなる!川崎フロンターレウイニングキャンペーン」は登録しました。何もしなくても川崎フロンターレが勝つ毎に20円割引されます。 サッカーには興味ないんですけど、ちょっとフロンターレを応援しようかという気になりますね :-)

スマホ移行

元々使ってたスマホは ASUS Zenfone 5 でした。

アプリの移行

基本的には Zenfone で Helium を使って SDカードにバックアップして、それを arrows M03 にリストアする感じでやりました。 詳しくはこちら

バックアップが禁止されているアプリがいくつかあったので、それは個別に。

slack

slack はバックアップできませんでした。まあログインし直せばいいだけです。

LINE

事前にメールアドレスを登録しておけば、新しい環境に LINE でログインするだけで使えるようになりますが、トーク履歴は引き継がれません。

移行前に元の環境で「トーク履歴のバックアップ」をしておいて、新しい環境で「トーク履歴をインポート」すればよいです。トーク毎にやらないといけないのでちょっと面倒です。

詳しくはこちら

データの移行

写真や音楽データは SDカードに元から入れてたので特に何もしなくても良かったです。

Zenfone だと文字化けしていた mp3 タグの「Boøwy」がちゃんと表示されました。Android のバージョンも違うのでそのせいかもしれません。

ガラケー移行

電子マネー

モバイルSuica と nanaco を使っていました。どちらもガラケーが使えなくなる前に機種変更手続きをしておく必要がありました。

モバイルSuica 機種変更

nanaco 携帯電話の機種変更について

ちゃんとやっとかないと、かなり面倒なことになりそうな感じです。

メール

実はちょっとトリッキーなことをして、imode メールをケータイじゃなくてIMAPを使ってスマホで読んでました。

iモードメールをスマホで送受信する(iPhone偽装による設定方法)

なので、PCのメールアプリからメールを全部コピーすれば終わりです。

電話帳&写真

docomo のサイトで新旧の機種を入力すると手順が表示されます。

データ移行ナビ

この手順は、SDカード経由でデータを移行するので通信ができなくなった後からでも行うことができます。

MNP切り替え

同梱されてた紙にURLが書かれてたので、そこにアクセスしてポチっとすれば申請は完了です。

夜に申請したのですが、すぐには切り替わらないので(たぶん人手で処理してる)、翌日は今までのガラケー&スマホと新しいスマホの3台持って出かけました。

切り替わるまでは新しいスマホはデータ通信できないので、元のスマホでテザリングしてました。

昼くらいにガラケーのアンテナが圏外になりました。新しいスマホは通信できないままだったのですが、再起動したら使えるようになりました。

移行後

それまで使ってた Zenfone 5 よりもちょっと小さいので違和感ありましたが、すぐに慣れました。

元から入ってた日本語入力の「Super ATOK ULTIAS」はかなりもっさりだったので、今まで使ってた普通の ATOK にしました。 キーボードを切り替えずに手書き入力ができたりして面白そうだったんですけどね…。

Suica は普通に使えました。これが使えないと話にならない…。

全体的に Zenfone 5 よりもちょっと遅い気がします。Android バージョンが異なるのでそのせいかもしれません。

Zenfone 5 には大きな不満が2つあって(「充電中は通知ランプが機能しない」「ナビゲーションバーが液晶外でボタンが絵なので暗いところで使うと見えない」)、それが解消したのはよかったです。

ホーム画面アプリはすぐに Nova Launcher に切り替えてしまったので使い勝手はわかりません。

モバイルSuica

iPhone 7 に Suica がついて、おそらくモバイルSuica が使えるようになるのに、「Suicaなんていらねー」と思っている人が結構いるようです。

個人的にはモバイルSuicaはチョー便利だと思ってるので解せません。

モバイルSuicaがあると、

  • JR東日本の新幹線の予約がスマホからできる。
  • 座席の指定もスマホから可能。
  • モバイルSuicaで指定席を買うと、普通に自由席を買うよりも安い。
  • Suicaのチャージがスマホからできる。

注意事項もあって、

  • モバイルSuicaの乗車券は新幹線下車駅まで。そこから先の乗車券は別料金。
  • たとえば、長野から品川まで行くとしたら、普通に切符を買ったら東京までの乗車券で品川まで行けるけど、モバイルSuicaの場合は、東京-品川間は別料金が掛かる(それでもモバイルSuicaの方が安いけど)。
  • ビューカード以外ではモバイルSuicaは年会費が掛かる。
  • ビューカードだとモバイルSuicaの年会費は無料なんだけど、ビューカード自体に年会費が掛かる。
  • 個人的におすすめなのは、ビックカメラSuicaカードで、前年度にカード利用が1回でもあれば年会費無料。モバイルSuicaで新幹線に乗ったり、Suicaのチャージにカードを使っても実績になるので、実質年会費無料。

書いてて思ったんですけど、JR東日本の新幹線に乗らないような人にはあんまりメリットないかもしれない…。

[追記]

二週間ほど使ってみたんですが、CPU性能の問題なのかメモリが少ないからなのか、ヒジョーに遅いです。

ハードウェア的なスペックは前に使ってた Zenfone5 と同じくらいなので、同じような感じで使えるのかと思ってましたが、Android のバージョンが 4.4 から 6.0 になっているせいもあるのかもしれません。

ちなみに、ポケモンGOを起動してみると50秒もかかりました。

まあ最近はほとんどポケモンGOやってないんからいいんですけど、ポケモンGO以外もかなり遅くなることがあります。

Suicaが使えるSIMフリー端末ということで SHARP の「AQUOS mini SH-M03」と迷って、値段で arrows M03 にしてしまったんですけど、AQUOS にしておけばよかったかなぁ…。