ThinkPad X201sで3G通信する

ThinkPad X201s

ThinkPadのよいところは、(保証に目をつむれば)カスタマイズの範囲が広い事だが、X系列は3G通信(WWAN)のオプションが搭載できる点でも良い。しかし、国内向けにはWWANオプションの選択肢が少ないか、あるいは提供されていない。

そんなわけで、どうすればそのようなX201sに3G通信の能力を与えられるか、というメモ。
(トライする場合は自己責任で、念のため)

  • QualComm Gobi2000 Mini PCIex moduleを買う。
    注意点は、ThinkPadの場合モジュールロックがあるので、ThinkPad用として販売されているモジュールしか使えない。例えば、Gobi2000はQualComm(Sierra)純正のモジュールが存在するが、これを取り付けるとBIOSがエラーを発してしまう。mod BIOSを入れるという選択肢もあるが、リスクを承知していない普通の人は手を出すべきではないだろう。特に純正モジュールは安かったりするので、飛びつかないように注意。
    もう一点は通信方式で、EVDO/EDGEタイプを買ってはいけない。国内の場合、DoCoMoかSoftBankに接続しなければならない。KDDIはEVDOの周波数帯は一致しているものの、KDDI側に機器の登録が必要らしいので、事実上使えない。
    今なら、Gobi3000やGobi4000(LTE)という選択肢もある。
    なお、これらモジュールは、技適マークがついている筈。
  • WWAN用無線アンテナを買う。
    国内向けThinkPadには、殆どのモデルでWWANアンテナが内蔵されていない。そのため、機種にあったWWANアンテナを入手する必要がある。ここで問題になるのが、アンテナの種類で、ヤフオクで売っているアンテナの大半は、GPSに対応していない。GobiシリーズはGPSにも対応しているのだが、こういったアンテナを買うと、WWAN通信は出来るがGPSは電波を拾えない。そんなわけで、GPSも使えるようにしたいのなら、Tycoのアンテナは多分ダメで、可能なら純正アンテナを入手するのが良い。
    X201sについての補足として、高解像度LCDを使っている場合は、そもそもWWANオプションは(世界的にも)存在しない。どうも天板の形状が通常LCDモデルと異なるようなので、仮に純正のアンテナを買うと、高解像度LCDモデルには取り付けできない可能性がある。
    なお、Gobi2000の場合は、アンテナは2系統必要。Gobi4000は、写真を見る限りでは3系統必要なようだ。私は、天板を外すのが面倒なので、3系統入れてしまった。Tycoのアンテナなので、GPSは使えない。取り付け位置は(幸いTycoは小型なので)適当に張り付けた。
  • SIMを入手する。
    国内では徐々に選択肢が増えてきた。手元で確認したのは、
    b-mobile ZSIM(使用しなければ0円のお手軽契約)
    DTI ServersMan SIM 3G 100(オプションなしで500円、100kbps)
    で、どちらもOKだった。ちなみに両方とも回線はDoCoMoを使う。

あとはドライバだが、Lenovo USA他の海外サイトから入手可能。変なドライバサイトからダウンロードしなければトラブルはないはず。これらはThinkVantageアプリケーションシリーズとして扱われており、Access Connection、GPSがある。但し、新品SIMのアクティベーションには以下のドライバが必要だが、この事はあまり書かれていないので注意(入れるだけでOK)。

Lenovo Mobile Broadband Activation (Windowsのバージョンが違う場合は探す事)

3GSIMを素で運用する場合、初めての場合は知らないかもしれないが、APNと呼ばれる識別子を設定する必要がある。b-mobileもDTIも説明書に書いてあるので、それに従ってAccess Connectionsのプロファイルを作ればよい。ユーザー名・パスワードも固定だが、忘れずに指定するように。

ACSettings1

ACSettings2

ACSettings3

晴れて接続できれば、以下のようになる。

Access Connection

コーディングガイドラインの車輪を再発明

正直、「好きだね、決めるのが」というところなのだが、コーディングガイドラインについての定義が多いなあと思う。
先日、CodeProjectで、またもやその一つが投稿され、コメントが炎上(?)していた。

Some practices to write better C#/.NET code

この中に何点か、自分的に納得いかないプラクティスがある。

  • Capitalization Conventions – プロパティはともかく、フィールドはプライベートもPascalなのか?自分的にはこうだ:moneyRemains_ – これは、ANSI C/C++において、安全とみなせるシンボル表記だ。但し、アンダースコアが後ろに続く表記はあまり見たことが無いかもしれない。自分のように、C++、C#のどちらも頻繁に書く場合、どちらでも通用する書き方にしたい。但し、それはシンボルが公開インターフェイスでなければ、の話だ。この記事ではないが、進行中のプロジェクトでは、readonlyフィールドが全て大文字という縛りがあって、かなり違和感がある。ここだけ単語の区切りが分かりにくいので、アンダースコアで区切ることになる(DIEING_DICTIONARYのような)。すると、確かに目立つは目立つが、まるでconstかと主張しているようだ(constではなくreadonlyなのだが)。どうも、readonlyインスタンスとconstの決定的な違いを分からず決めたように感じる。
  • DO declare all member variables at the top of a class, with static variables at the very top. – たのむからプロパティをコンストラクタより上に持ってこないでくれ。フィールドとプロパティを同一のように扱うと罠にはまる事があるから、見てすぐにわかるようにしておきたい。
  • DO NOT suffix enum names with Enum – これは同意だが、できれば列挙型名は複数形にして欲しいな。列挙型を定義してTlbExpでタイプライブラリを出力、C++側でインポートした時とか、不自由しなくなる。まれなケースだけど、まれなケースの時だけルールを変えるぐらいなら、複数形にする事に負担があるわけじゃないからやればいい。
  • Avoid Obsolete Comments – これはかなり炎上していたな。前提としては、コメントを「書かなくても済むようにする(シンプルで意味が明瞭な実装を心がける)」ということに賛成だが、不可避な場合がある。結局、突き詰めていくと、コーディングの問題じゃなくて、大枠の設計(ユーセージモデルとか)が問題で複雑化してしまっていたりするので、どうしてもコードが複雑にならざるを得ない事がある。そのような場合に、将来自分でこのコードを見たときに、昔自分が何を考えてこのように実装したかを書いておくためにコメントを使っている。これを書いておかないと(自分でも)理解不能ではないだろうかと思うような場所で、かつ改善できないような痛い場所だ。しかし、出来れば設計からやり直させたいね。
  • Avoid Multiple Exit Points – これは絶対拒否だ。一体これをやりたがるのは何故だ?CPUにはプログラムカウンタ(インストラクションポインタ)とスタックというものがあり、これらの情報で一種の仮想的な「ハードウェアステートマシン」を実現しているのだ。条件分岐のブロック内に居るという「事実」が、この情報だけで表現されているのに、何故手でステートを管理したがるのか。ステート変数を導入すれば、それがいつどこでどのように変更され、どのような場所や場合においても正しくふるまっているかどうかを管理しなければならなくなる。C++でRAIIが当たり前に使われているのは、こうしたステート変数を避けるためだ。これ以上、処理の必要がない分岐ルートでは、速やかにメソッドから退出(return)する。そうすることで、余計な分岐ルートを削減できる。分岐ルートを削減できれば、パターン網羅のためのテストコードも少なくて済む。メソッドが下に落ちていくほどルートはふるいにかけられ、終盤ではそこに居るための「暗黙条件」は絞られるはずだ。結果として、コードはよりシンプルになる。

思うに、こういう事は意外かもしれないが、「ルールを決めて徹底させる」事が諸悪の元凶に思う。たとえば、重厚な開発プロセスを導入する事は、そこから緩慢な死へと向かい、より良い未来に前進することはない。プロセスを定義するという事は、「考えなくても出来る」ことを目指すため、例外なく「思考停止」し、本当は何が問題でどうしようとしていたのかが置き去りにされてしまう。常に最善とは何かを考えるためには、プロセスは邪魔なのだ。

もっとも、多人数で作業を進めるために、何らかの決まり事は必要となる。重要なのは、それが常に陳腐化する可能性があり、いつでもすぐに見直し、正しい方向に修正しなければならないことをメンバー全員が周知していなければならない事だ。加えて、業務を遂行するために、いつでもルールが変更可能でなければならない。何らかのプロセスを導入していると、「こうするのがルールだから仕方ないよね」というところから始まって、なし崩し的に開発効率が落ちていく。終いには、何が悪くてこうなってしまったのかすら、誰もわからないという寒い状況に陥る。

上記に示したルールは、私が業務を進めるにあたって、C++/C#の両刀使いである前提でのルールも含まれている。CodeProjectの元記事や私のルールを鵜呑みにせず、積極的にルールをぶち壊し、再発明してほしいものだ。