中古で購入したdocomo版iPadがSIMロック解除できるようになったのでやってみた
2019年2月20日以降、中古端末のdocomo版iPadはSIMロック解除できる
こういうニュースリリースが出ました。
これはとてもありがたい話ですよ。2015年5月以降の端末なら、中古で譲り受けた場合やリサイクルショップで購入した場合でも、オンラインで無料でSIMロック解除できるのですから。
これまでは、端末を新品で購入したユーザだけがSIMロック解除できましたので、他のキャリアのSIMを使いたい場合は端末を手放す前にSIMロック解除していることが必要でした。
しかし多くのケースではSIMロック解除されることもなく、そのまま販売されていたと思います。これからはこういうことを気にしなくても済むのですから。
どういう方にメリットがあるのか?
au / SoftBank 回線の方は、手持ちのキャリア以外に、docomo版も選択肢になりますね。選択肢が単純に2倍になるのだから、とても選びやすくなりますね。
IIJmio(みおふぉん)でタイプD(ドコモ回線)のSIMをdocomo版iPadを使っている方は、SIMロック解除すればタイプAで運用できます 。これは通信回線を冗長化できることを意味します。たとえば、もしもdocomo回線で何かの障害が起きた場合でもau版回線は生きている可能性が高いので、スマートフォンとタブレットでタイプDとタイプAを混在させておけば、そのような運用ができます。
実際にやってみるためにIMEIを確認する
SIMロック解除ではIMEI番号が必要です。これは次のどちらかの方法で確認できます。
iPad で確認する
iPadの設定アプリで「一般」を開くと、IMEIが表示されています。ここを長押しするとコピーできます。
iTunes で確認する
iPadをパソコンにつないでiTunesを開くと、接続したデバイスが確認できます。
「シリアル番号」と表示されている箇所を複数回クリックするとIMEIが表示されます。ここを右クリックするとコピーできます。
実際にやってみる
IMEI番号が確認できたら手続きを進めます。
docomoでのSIMロック解除手続きはMy docomoで行いますが、My docomo のアカウントはdocomo回線を持っていなくても作成できます。
ここでは既に My docomo アカウントがある、という前提で説明を進めますので、アカウントがない場合は先に作成しておいてください。
My docomo にログインし、「その他のお手続きはこちらから」に進む
ログインして画面をすこしスクロールすると、こういう表示が確認できるはずです。ここから「その他のお手続きはこちらから」を選んで次の画面に進みます。
「SIMロック解除」のメニューを探す
「その他」のカテゴリーの中に「SIMロック解除」がありますので、これを選んで先に進みます。
2段階認証を行う
My docomoでの各種手続きは2段階認証が必須のようです。docomo契約がない場合は登録メールアドレスにセキュリティコードが送信されます。
届いたセキュリティコードを入力して先に進みます。
IMEI番号を指定してSIMロック解除を申し込む
あらかじめ確認しておいたIMEI番号をここに貼り付けます。
これで手続き完了!
手続き完了の通知が画面に表示されます。またメールで送られてきます。これで完了です。
完了したらどうすれば良いのか?
別キャリアのSIMがある場合は、それを挿して再度のアクティベーションを実施すればよい。
別キャリアのSIMが無い場合は、 iPadを初期化してアクティベーションし直します。iPadを事前にバックアップしておきましょう。
より正確な手順はこちらで説明されています。
Delphi / C++Builder 向けパッチの自己流管理方法
Delphi / C++Builder に限らず、ソフトウェア製品はかならずパッチやアップデートがリリースされますので、適切に適用することが大切ですね。
しかし、Delphi / C++Builder のパッチインストールはおせじにも簡単とはいいがたく、インストールがめんどくさいと思います。
たとえば 10.2 Tokyp Subscription Update 3 向けのパッチはこれだけあります。これらは個別のzipファイルで提供されることが多く、Delphi / C++Builder のインストールパスに手作業で展開する必要があります。(例外的に一部のパッチは実行形式で提供されることがあるようですけど。)
パッチ名 | ダウンロードページ |
---|---|
30831_rad_studio_10.2.3_android_push_notification_patch | https://cc.embarcadero.com/item/30831 |
30832_rad_studio_10.2.3_ems_package_wizard_patch | https://cc.embarcadero.com/item/30832 |
30833_RAD_Studio_10.2.3_Context_Help_Patch | https://cc.embarcadero.com/item/30833 |
30834_C++Builder_10.2.3_C++_Compiler_4k_Stack_Allocation_Patch | https://cc.embarcadero.com/item/30834 |
30835_RAD_Studio?_10.2.3_iOS 11.3_Patch | https://cc.embarcadero.com/item/30835 |
30836_delphi_10.2.3_rad_server_linux_apache_patch | https://cc.embarcadero.com/item/30836 |
30837_rad_studio_10.2.3_ios_11.3_and_codeinsight_patch | https://cc.embarcadero.com/item/30837 |
30838_rad_server_10.2.3_performance_patch | https://cc.embarcadero.com/item/30838 |
こういう仕組みはシンプルだから嫌いではありませんが、それそれのパッチの適用状況がわかりづらいです。
そこで、こういう方法でパッチのインストール状況を管理することにしました。
RAD Studio のインストールフォルダに "HotFix" というフォルダを作って適用済みホットフィクスの情報を記録しておく
ツール側にパッチの適用状況を管理する仕組みがないなら、どうにかしよう、ということで、それを管理するためのフォルダを作成します。
ここには、以下のルールでファイルをパッチ単位で作っておきます。
- ファイル名は、パッチの番号および名前にしておく。拡張子は txt にする。
- ファイルの内容は、パッチが公開されているページのURLにする。
このようにしておくだけで、パッチのインストール状況が一目でわかりますし、そのパッチを他の機材に適用したい場合には、そのファイルをひらけばURLがわかるので内容の確認やダウンロードも簡単です。
どうせなら、パッチをひとまとめにしたアーカイブを作ってしまおう
とはいいつつも、複数の作業マシンを使い分けている場合は、それらに同一のパッチを入れる作業は案外めんどくさい。
また、環境をゼロから作り直す場合も同様にめんどくさい。
そこで、前述の構成をとりつつ、複数のパッチをマージしたアーカイブを作ってしまえば、すべてのパッチを一括で導入できますし、何を適用しているかもわかります。
では、そのアーカイブはどんな形式で作るのがよいのか?
普通に考えれば zip 形式一択なのですけど、zip 形式は圧縮率がさほど高くないという印象があります。そこで、複数の圧縮フォーマットでファイルサイズがどれくらい変わるかを比較してみました。なお、作業の都合上、これは macOS 上で実施しております。また、処理時間は1回だけ実行した時の実測値なので処理時間の絶対値を見るのではなく、相対的に速い、遅いという観点での比較にご利用いただけます。
アーカイブ名 | ファイルサイズ | 作成方法 | 処理時間 |
---|---|---|---|
R10.2.3.30831-30838.tar | 1583243776 | tar cvf R10.2.3.30831-30838.tar R10.2.3.30831-30838 | 3秒 |
R10.2.3.30831-30838.zip | 907663024 | zip -r R10.2.3.30831-30838.zip R10.2.3.30831-30838 | 2分45秒 |
R10.2.3.30831-30838.tar.gz | 907840100 | cat R10.2.3.30831-30838.tar | gzip -c -9 > R10.2.3.30831-30838.tar.gz | 2分35秒 |
R10.2.3.30831-30838.tar.bz2 | 874491124 | cat R10.2.3.30831-30838.tar | bzip2 -c -9 > R10.2.3.30831-30838.tar.bz2 | 2分49秒 |
R10.2.3.30831-30838.tar.xz | 598725872 | cat R10.2.3.30831-30838.tar | xz -c -9 > R10.2.3.30831-30838.tar.xz | 15分32秒 |
*上記の処理で cat を pv (pipe viewer) に置き換えて実行すると、処理状況が可視化され、実行終了予測時間も表示されますので、私が実際に作業するときには cat ではなく pv を使います。
こうやって比べてみると、zipとgzipはファイルサイズに極端な差はありませんが、bzip2はそれよりも小さく、xzはさらに小さいことがよくわかります。圧縮のためにそれなりに時間はかかりますが、xz が取り扱えるなら基本的には xz 一択で良いと思います。
ちなみに、この xz のアーカイブを展開するためにかかる時間は、約10秒でした。圧縮には時間がかかるけれど、展開で10秒なら全く問題ないレベルです。
では、xz は Windows でどうやって扱えるか?
GUI 指向の方は 7-zip を入れておけば扱えるようですが、私は Windows 向けのGUIツールでアーカイブを扱うことを基本的にしないので、使い勝手はよく知りません。
CUI 操作に不都合がない方は、Windows Subsystem for Linux をセットアップしておけば、普通に xz や tar コマンドで扱えます。
ちなみに、Windows 側の特定のフォルダで bash で作業するのに cd コマンドで移動、とかする必要はありません。エクスプローラでそのフォルダを開いた状態で、アドレスバーから "bash" と入力するだけでよいのです。
Sufrace Go 64GB のSSD性能をベンチマークしてみる
Surface Go 64GB を一時的に使うことになったので、SSD性能をベンチマークしてみました。
計測に試用したのは CrystalDiskMark のストアアプリ版です。
Surface Go 上位モデルのベンチマーク結果はいろんなところで記事化されているのでそちらと比較してみると、こんな感じになりました。
- 読み込み性能は1/3くらいに遅い
- 書き込み性能は上位モデルよりちょっと速い
なお、この Surface Go には RAD Studio 10.3 Rio Enterprise をフルインストールするという無茶振りをしてみたので、ストレージの空き容量がだいぶ減ってます。
この状態で iOS/macOS/Linux のSDKをPAServer経由で開発環境側にコピーすると、さらに足りなくなりそうなので、RAD StudioのインストールフォルダなどをNTFS圧縮しようかと考え中。
Samsung microSD 32GB MB-MC32GA/ECO を買ったのでベンチマークしてみる
Samsung microSD 32GB MB-MC32GA/ECO を買ったのでベンチマークしてみることにします。
ベンチマークは下記2種類のI/Fで試しました。
- MacBook Pro Retina 13inch SDスロット
- ダイソーで買ったSD/microSD-USBリーダ
ダイソーのリーダーは100円で売ってたので試しに買ってみました。
Blackmagic Disk Speed Test の結果
item | write | read |
---|---|---|
MB-MC32GA/ECO (MacBook Pro Retina 13inch SDスロット利用 | 31.0MB/s | 87.1MB/s |
MB-MC32GA/ECO(ダイソーで買ったSD/microSD-USBリーダ) | 4.6MB/s | 8.3MB/s |
過去にこういうベンチマークをしてみましたが、これに比べるとMB-MC32GA/ECOは書き込み速度がずいぶん良いので、書き込み性能が必要な場合は古いのを使い続ける意味はなさそうです。
ダイソーのリーダーは、なんというか、これは非常用としては使える程度、ですね。
試用期間が終了した kintone のトライアルを再度申し込む
Delphi/C++Builder でクラウドサービスをデータソースとして利用できる Enterprise Connectors が2018年11月に kintone 対応したので、kintone をトライアル利用しつつ Delphi/C++Builder との連携を試していたのですが、気がつくと kintone のトライアル期間が終了してしまいました。
しかし、kintone では下記ページに記載のとおり、試用期間終了後に再度試用申し込みすることができます。 https://faq.cybozu.info/alphascope/cybozu/web/kintone/Detail.aspx?id=1049
そこで再度の試用申し込みをすることにしました。ただし再試用後も直前の試用で使っていたサブドメイン名を引き続き使いたかったので、以下の手順で再試用することにします。
- 試用期間が終了したサブドメインを、一旦別名のドメインに変更する
- 新たに試用を申し込む
- 新しい使用環境のアカウントを、以前の試用環境のものにあわせる
- 新しい使用環境のサブドメインを、以前の試用環境のサブドメインに変更する
この手順がベターなものかどうかは知らないけど、とりあえず目的は達せられたので良しとする。
Delphi/C++Buidler/RAD Studioのデータベース接続コンポーネントFireDACからDockerコンテナのMySQLにつなぐ
とりあえずざっくりな忘備録。開発環境からつないでみるだけです。
MySQL Serverを自分の作業マシンや仮想マシンに入れるのはイマイチな気がしたので、せっかくなのでDockerで作ることにします。
手順自体は普通に MySQL Server をインストールする場合と基本的には同じです。
必要なもの
- Delphi/C++Builder/RAD Studio Enterprise
- libmysql.dll(MySQLのWindowsクライアント)
- Docker MySQLコンテナ
- FireDAC での接続定義の作成
準備
Delphi/C++Builder/RAD Studio Enterprise
買いましょう。
libmysql.dll(MySQLのWindowsクライアント)
libmysql.dll は MySQL Connecotr/C に含まれるので、これを開発環境に一旦インストールする。
https://dev.mysql.com/downloads/connector/c/
ただし単体インストーラは存在しないので、MySQL Installer でインストールします。
MySQL Connecotr/C はインストールの途中で明示的に追加します。
インストールしたら、パスが通っているフォルダか、またはDelphiのIDEのパスにコピーします。
Docker MySQLコンテナ
Delphi 10.2 では MySQL は Version 5.7 までの対応っぽい。 ここに対応データベースバージョンが書かれている。
そこで Docker MySQL コンテナイメージも 5.7 のものを選んで入手することにします。
公式のイメージは https://hub.docker.com/r/mysql/mysql-server/ に情報がありまして、これを見ると 5.7 は次のようにインストールできそうです。
docker run \ --name mysql57 \ -e MYSQL_ROOT_PASSWORD=secret \ -p 3306:3306 \ -d mysql/mysql-server:5.7
ただしこの手順で起動しても、MySQL への接続は localhost からしか行えません。そこで一旦こんなふうに実行して、root ユーザがすべてのデータベースに対して任意のノードから接続できるようにしてみます。
$ docker exec -it mysql57 mysql -uroot -p mysql> grant all privileges on *.* to root@'%' identified by 'secret';
実際の運用環境では、当然ながら、こんなざっくりとした設定をしてはダメです。
FireDACでの接続定義の作成
TFDConnectionで、最低限、こんな感じで設定すれば接続できるはずです。黄色でハイライトされている箇所を実際の環境にあわせて設定します。
設定を作ったら「テスト」を実行して設定が正しいことを確認します。
接続できたら、あとはTFDQueryなどでクエリ実行するなりして利用できます。
うまく接続できない場合は、MySQL Workbench や mysql コマンド等で接続できるかどうかを確かめるとよいでしょう。
ちなみに最初は MySQL 8 のコンテナを立てたのですが、MySQL Workbench からは正常に接続でき、FireDAC から接続するとエラーが出たので、サポートバージョンで明記されている 5.7 のコンテナを作り直しました。とはいえ、docker run するだけなので、手間なく動かせるのは大変ありがたいです。実インストールしていたら、アンインストールするとか、スナップショットに戻すとかの作業が必要になるわけですし。
Windows向けのEXEやDLLが、32bitなのか64bitなのかを調べる方法をいくつか考えてみる
アプリケーションとDLLのビット数が合わないと動かないので、確認方法を把握したいと思った
あるツールのビット数と、そのツールが使うDLLのビット数が合っていないことに気づかず、意外に手間取理ました。そこで EXE や DLL のビット数の確認方法を考察してみることにした。
とりあえず見つけた方法はこんなところ。
- dumpbinコマンドで見る
- バイナリを直接見る
- fileコマンドで見る
- 7zip のコマンドラインツールを使う
この中では、自分の環境では file コマンドでチェックするのが最もよさげ。
dumpbin コマンドで見る
Visual Studio に含まれる dumpbin.exe で見れるらしい。
こんなふうに実行すると、x64 or x86 という情報が出るらしい。
dumpbin.exe /headers ファイル名 | findstr machine
でも、自分の環境には Visual Studio を入れていないので、この方法は取れない。
直接見る
0x80 前後に以下のようなデータの並びを探せばよいそうです。
50 45 00 00 4C 01 = 32bit 50 45 00 00 64 86 = 64bit
うん、わかった。でもちょっとめんどくさい。だけど、データサイスの小さいバイナリなら、notepad や command prompt で more コマンドを使ってこんなふうに上記のデータを探せます。そう考えると、これはこれで追加のツールをインストールできない環境では悪くない方法です。
32-bit の場合
64-bit の場合
file コマンドで見る
macOS, Ubuntu, CentOS, cygwin などに含まれる GNU file コマンドを使えば容易に確認できます。Windows 10 で WSL を入れていれば file コマンドが利用可能です。
EXEはこんなふうに示される。
$ file System32/net.exe SysWOW64/net.exe System32/net.exe: PE32+ executable (console) x86-64, for MS Windows SysWOW64/net.exe: PE32 executable (console) Intel 80386, for MS Windows
DLLも、こんなふうに示される。
$ file System32/winusb.dll SysWOW64/winusb.dll System32/winusb.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows SysWOW64/winusb.dll: PE32 executable (DLL) (console) Intel 80386, for MS Windows
file コマンドはさまざまなファイルのフォーマット判定に利用できるから、これが最も汎用性が高い。
7zコマンドを使用する
7-zip をインストール済みの場合は 7z.exe l some.exe | findstr CPU
のように実行すると "CPU = x86" または "CPU = x64" という結果が取得できるそうです。
実際にやってみると、ごらんのとおり。
C:\>"C:\Program Files\7-Zip\7z.exe" l c:\windows\system32\cmd.exe | findstr CPU CPU = x64 C:\>"C:\Program Files\7-Zip\7z.exe" l c:\windows\syswow64\cmd.exe | findstr CPU CPU = x86 C:\>"C:\Program Files\7-Zip\7z.exe" l c:\windows\system32\winusb.dll | findstr CPU CPU = x64 C:\>"C:\Program Files\7-Zip\7z.exe" l c:\windows\syswow64\winusb.dll | findstr CPU CPU = x86
まとめてみると、調べ方はこんなかんじです。