2 in 1 PC とは何か？

ノートブックPCの進化形(?)として、2in1 PC がある。YOGA BOOK もこのジャンルのモデルだ。このジャンルがよく分からないので、まとめてみた。

可搬型 PC の種類

従来のノートブック型のPCも含めて、持ち歩きを前提にした PC の形態について、以下にまとめる。

ノートブック PC (クラムシェル型)

キーボードと本体(基盤、ストレージ、バッテリー)が一体化されている。ディスプレイは、キーボードを含む本体にヒンジを使って接続される。ディスプレイを開いたり閉じたりする様子が貝に似ているためクラムシェル型と呼ばれる様になった。

2in1 PC-コンバーチブル型

クラムシェル型と同様に、キーボードと本体が一体化されている。ディスプレイは、キーボードを含む本体にヒンジを使って接続される。ディスプレイが360度回転するのが特徴で、ノートブックモード、テントモード、スタンドモード、タブレットモードに変形して使用できる。Lenovo の Yoga シリーズが代表的である。

2in1 PC-セパレート型

ディスプレイと本体が一体化され、独立してタブレットとしても使用できる。キーボードとディスプレイは、取り外し可能なヒンジで固定し、従来のクラムシェル型と同様の使い方ができる。マイクロソフトの Surface Book シリーズが代表的である。

2in1 PC-タブレット＋カバー型

ディスプレイと本体が一体化され、独立してタブレットとしても使用できる。キーボードは純正カバーとして提供され、無線、あるいは専用コネクターで接続する。ディスプレイにスタンドが付いており、従来のクラムシェル型に似た形態での使い方もできる。マイクロソフトの Surface pro シリーズが代表的である。

2in1 PC が生まれた背景

マイクロソフトが Windows をタブレット OS としても使える様にしようとしたことが発端である。Windows 8 で標準のデスクトップにタイル表示を導入し、タブレット操作で Windows を使える様にしようと目論んだ。それに合わせて、各社から純粋な Windows タブレット機が出され、一部のユーザーに受け入れられた。その一方で、通常のデスクトップ PC ユーザーやノートブック PC ユーザーからは、標準 GUI の改変に対して反発が生まれた。特に、従来のスタートメニューがなくなった点は批判が多く、後に Windows 10 でスタートメニューが復活するということで落ち着いている。この事は、結果的に Windows のタブレット形態での使用時の UI がこれ以上は向上しない、ということになった(それとも、緩やかに変化しようとしているのだろうか？)。

当初から指摘されていたが、マウスとキーボードを使った操作と指での操作では全く異なる GUI が要求されるが、無理やり融合しようとすることで歪みが生じる。エクスプローラーでのファイル操作で、マウスで選択して別のウィンドウにドラッグしてドロップするという操作を指で行うには、確実にファイルを選択するためにアイコンのサイズは大きい方がよく、複数選択もチェックボックス方式の方がし易いなど、GUI に要求される表現方法が変わって来る。そのため、Windows を純粋にタブレットのみで使用する使い方は一般化しなかった。しかし、マイクロソフトは Windows のタブレットでの使用を諦めず、自ら Surface シリーズを提供する事で、タブレット市場の活性化と拡大を目指した。

Windows 8 発売当時の純粋な Windows タブレットは重かった。通常のノートブック PC と同等のパフォーマンスを得るには、単純にノートブック PC の本体がタブレット内に含まれる。Intel の Atom プロセッサーを載せた 8" サイズの軽量なモデルも現れたが、パフォーマンスが劣るせいもあり、主流とはならなかった。そのような中で、タブレットとノートブック PC を融合する形態として 2in1 PC が主流となってきた。

コンバーチブル型は、通常のノートブック PC のヒンジの構造を変えて、ディスプレイを360度回転するようにし、タブレットのような形態でも使用できる様になっている。このタイプは、従来のノートブック PC の構造のままタブレットとしても使えるようにできるため、設計し易いと思われる。ノートブック PC としての強度も確保でき、ノートブックモードでの使用時の重量バランスも良い。一方で、スタンドモードやタブレットモードで使用するときに、キーボード面が机や手に接触するため、誤動作や破損が懸念される。恐らく、ノートブック PC のディスプレイをひっくり返せばタブレットになるんじゃね？的な発想から生まれたのだろう。ディスプレイを回転させるアプローチが古くから有ったが、やはり強度確保の面で難しかったのだろう。Microsoft の Serface シリーズにはこのタイプのラインナップはない。

タブレット＋カバー型は、タブレット単体からのアプローチで、単体のタブレットとして動作する事が前提となる。キーボードを載せた専用のカバーを併用し、タブレット自体にスタンドを持たせる事で、容易にノートブック PC のような形態での使用ができるようになる。その場合、スタンドが必要になるため、占有面積がクラムシェル型などに比べて広くなる。膝上で使用する場合や、都市部のコーヒーショップの狭い机で使用する場合には、使いづらい。Apple の iPad が、この形態でキーボード入力と可搬性の向上を図っている。Microsoft の Surface pro と Serface Go では、タブレットにスタンドを追加することで、より使いやすくなっている。

セパレート型は、タブレット＋カバー型の発展型である。キーボードとタブレットを脱着式のヒンジで固定する事で、容易にノートブック PC のような形態での使用ができるようになる。その場合、重量バランスを持たせるために、キーボード側にバッテリーや追加のストレージを載せる事が多い。その結果、総重量が増すことになる。また、ヒンジ部の強度確保など、設計も難しい。恐らく、重量面のデメリットから、消えゆく運命にあると予想する。Microsoft の Serface Book がこのタイプである。

2in1 PC の行く末

ここからは、私の妄想となる。

従来型であるクラムシェル型は生き残るだろう。ただし、コンバーチブル型が重量面と価格面でクラムシェル型と差がなくなれば、コンバーチブル型が可搬性 PC の主流となりうる。99% はノートブックモードで使用するが、稀にタブレットとして使いたい、スタンドモードで使いたい、という場合にも対応できるためだ。

タブレット＋カバー型については、そのうち消えるのではないかと考えている。スマートフォンの能力向上と普及率の高さから、Windows をタブレットとして使うメリットは無く、既存の豊富なデスクトップアプリケーションを使用する環境として Windows を使うメリットの方が大きい。その場合キーボード入力とマウス操作が前提となる。タブレット＋カバー型で、結局はキーボード入力とマウス操作を行うのであれば、重量と価格のメリットが無くなったときに、使い勝手の良いクラムシェル型に収束すると思う。

ここで、なぜ今 2in1 PC があるのか考えてみよう。この疑問には、別の疑問で考えよう。なぜ Windows タブレットは単体で使われないのだろうか？と。

まず、Windows タブレットとは何かを考える。Windows タブレットとは、CPU とメモリー、ストレージとバッテリーを内包して、タッチ操作ができるディスプレイによって画面操作を行う情報端末で、OS に Windows を使用したものである。タブレットを起動すると、そこには慣れ親しん Windows のデスクトップ画面が表示される。タブレット専用の GUI ではない。それが Windows タブレットだ。

Windows タブレットの画面に表示されているアイコンのクリックやメニュー操作は、指での操作に最適化されたものではない。スタイラスや Surface Pen のようなものが必要になる。あるいは、慣れ親しんマウスだ。何らかの操作をして、アプリケーションを起動しよう。例えば、皆大好き、Excel だ。ノートパッドでもいい。何か、数値や文章を入力しよう。タブレットとして使用している場合、仮想キーボードを表示して入力する事になる。Windows ではタッチキーボードを表示する。その場合、画面の下1/3がキーボード入力エリアとして占有される。そして、普段 Windows をデスクトップ PC やノートブック PC で使っているユーザーにとって、タッチ操作での入力はもどかし過ぎる。ならば、使い慣れた物理キーボードを使えばいいじゃないか！しかし、せっかく可搬性の優れたタブレットに、デスクトップ用のキーボードを使ってしまったら、持ち歩きが不便だ。もっと軽量コンパクトなキーボードを使うことにしよう。そういえば、専用のキーボードカバーがあるじゃないか！デスクトップ用キーボードより打ちにくいけど、タッチキーボードに比べれば遥かにマシだ。タッチキーボードが無くなって、画面も広く使えるし、使い勝手はノートブック PC に匹敵するぜ！

こうして、Windows タブレットのノートブック PC 化が為され、Windows タブレットとキーボードカバーとマウスとペンのセット販売が主流となっていく。2in1 PC のタブレット＋カバー型である。Apple の iPad でこのスタイルが確立していることも、一般化の助けとなっている。

タブレット＋カバー型は、Windows タブレット単体の操作性を補完した結果、クラムシェル型のノートブック PC に近づいていくアプローチだが、セパレート型とコンバーチブル型は、逆のアプローチである。大半はクラムシェル型での使用を想定し、ある1時点のみタブレットとして使用する想定である。タブレットとして使う際に、完全なタブレットとなるのがセパレート型で、分厚い裏面がキーボードになっているタブレットとなるのがコンバーチブル型である。本体の能力を犠牲にすること無く、軽く薄くすることができれば、コンバーチブル型のアプローチが有利になる。

いずれにせよ、Windows タブレットの使い勝手を上げようとすれば、結局はクラムシェル型のノートブック PC に近づくことになる。現在の Windows タブレットで、タブレットの形態で使用するのは、ペン入力によるコメント書きや、イラスト作成程度ではないか思われる。十分に軽く薄くなっていれば、タブレットの形態で使用する時だけキーボードをひっくり返すコンバーチブル型で十分だ。タブレットの形態で常時使用するような用途には、指によるタッチ操作により優れた iPad や Android タブレットが採用されるだろう。実際のところ、Surface Pro や、Surface Go を、タイプカバー無しで購入するユーザーの割合はどの程度なのだろうか。

それから、タブレット＋カバー型とセパレート型では、ケーブルがマヌケに見える。このタイプでは、充電しながら使ったり、ドックを使って拡張する場合には、ディスプレイの横からケーブルが飛び出した状態になる。以前、ThinkPad 8 を所有していた時期があるが、家で bluetooth キーボードを接続して使用しているときに、ThinkPad 8 は充電ケーブルを差していた。ディスプレイの上から充電ケーブルが生えている姿は、どうにもマヌケである。Microsoft の Surface Go の 8GB モデルは処理能力と(Office が欲しい人にとっては)価格のバランスが良いモデルだが、やはり、USB で充電したり拡張すると、ディスプレイの横からケーブルが生えることになる。見た目がスマートでは無い。クラムシェル型やコンバーチブル型では、充電中でも、拡張しても、ディスプレイの周りはスッキリしている。私にとってはそれだけでも、タブレット＋カバー型を避けて、クラムシェル型やコンバーチブル型を選択する理由になる。

さらに、主に複数のウィンドウを使用して作業している場合に、変形してタブレットにして縦に持ち替えたとしよう。画面は90度回転し、それに合わせて、開いていたウィンドウの横幅は狭められる。元の横向きに戻すと、ウィンドウの横幅は狭くなったままだ。これにもイライラさせられる。常にウィンドウ最大化して使えば、この問題は解消できるが、それなら Windows にこだわることもない。iOS や Android のタブレットの方が使いやすいだろう。

最終的には、コンバーチブル型に収束する、と言うのが私の予想だ。

YOGA BOOK への期待

妄想は続く。

ここで、私の考えでは、2in1 PC の中で、YOGA BOOK への期待が生まれる。現時点でタブレットとしてなんとか使用できる 800g 以下であり、厚さも 9.6mm である。初代 YOGA BOOK with Windows は Atom CPU+4GB RAM+eMMC 64GB であり、パフォーマンスについてはかなり妥協する必要があるが、第2世代の YOGA BOOK c930 では、大幅に改善されている。

YOGA BOOK with Windows の平面キーボードだが、正直に言って、Halo キーボードは打ちにくい。物理キーボードの3～5割減の入力速度になる。ただし、Android タブレットの仮想キーボードでの入力と比べると、1割増程度の入力速度向上がある(と感じる)。YOGA BOOK c930 でも同様だろう。恐らく、Lenovo の開発陣は、電子ペーパーによる平面キーボードの実現と、キーボード面を第2のディスプレイとしての活用、および、ディスプレイとは別のペン入力デバイスとして機能を盛って行こうと考えているだろう。私としては、今は電子ペーパーによる平面キーボードの実現までで抑えて欲しい。それだけでも、SKU の全世界共通化が実現できてコストメリットは出るはずだ。それ以上の機能は必要ない。ペン入力については、むしろディスプレイに直接ペン入力できることに注力して欲しい。ダブルクリックでディスプレイが開くようにするよりスリープ時のバッテリー消費を下げて欲しい。そして、メモリーは8GBにして欲しい。

平面キーボードの採用は、物理キーボードに慣れたユーザーにとっては、入力のストレスが高い。しかし、最初にスマートフォンやタブレットでの入力に慣れた世代に取っては、その延長であるというスタンスで使用すると、それ程苦痛では無いのではないか。実際、タブレットのキーボードが画面から移動し、大きくなったと考えて使ってみると、さほど苦にならない。8インチサイズの小型ノートブック PC での入力に比べれば遥かに使いやすい。実は私は YOGA BOOK with Windows の発表時には、新しいペン入力とキーボード入力を採用した、キワモノという認識しかなかった。その後、退職に伴いノートブック PC が1台もない状態となって、5万円前後で 10～12" 程度のディスプレイを持った、1kg 以下のモデルを探してみた。ASUS T101HA に惹かれたが、解像度の低さで対象外となったが、その売場の近くに展示してあったのが YOGA BOOK だった。値段相応のスペックだが、FHD の解像度である点に興味を持ち、手にとってみて軽さを実感した。そしてキーボード入力を試したら、タブレットでの入力レベルはであることが分かり、入力音を全く出ないようにできることも分かった。その場で購入を決断した。タブレット画面の仮想キーボードが下にせり出した構造、と理解したからだった。最初からペン入力は考えていなかった。

ネット上のレビュー記事を読むと、平面キーボードは入力し難い、と言うのが一般的だ。いずれの記事も、物理キーボードでの入力を平面キーボードで再現しようとして、ブラインドタッチで高速入力ができるように工夫し、努力し、その結果、平面キーボードは使えないという結論に至る。むしろ、通常のノートブック PC のキーボードに劣るキーボードカバーであっても、物理キーボードであれば、ブラインドタッチができるため、入力速度が上がるという結論に達する。その結果として、タブレット＋カバー型が主流派になっている。中には、より快適な入力環境を求めて、PFU の bluetooth 接続の HHKB キーボードや、Lenovo の bluetooth 接続のトラックポイントキーボードを Surface Go と合わせて持ち歩く猛者も出てくる。その一方で、タブレット単体でタッチキーボードでの入力する場合と平面キーボードで入力した場合を比較している記事は見かけたことが無い。ブラインドタッチを求めず、タブレットのタッチキーボードに比べれば、多少早い、というスタンスで使用すれば、平面キーボードもまんざら捨てたものではないし、軽量化、薄型化、静音化、掃除のしやすさのメリットが生きてくる。夜の新幹線では、隣の席でサラリーマンが資料作りをしていることがある。カタカタカタカタ、ターン！と賑やかである。しかし、それが始終繰り返されるとイライラしてくる。平面キーボードでは、音とバイブレーションの設定を OFF にすれば入力時にほとんど音が出ないため、周りに迷惑をかけることもない。会議中に議事録をとる場合など、入力音がしないことはメリットになる。YOGA BOOK c930 が発表され、一時は出荷できないほどの予約があったようだ。話半分としても、一定数のユーザーがいるようだ。入力し難いと言われる平面キーボードだが、タブレットの仮想キーボードよりはマシという見方であれば、機能としては十分である。

同様に、タッチパッドの使い勝手の悪さが指摘されている。狭いし、機能も少ない。YOGA BOOK c930 では、スペースキーの分だけ広げるモードも導入された。いっそのこと、面全体をタッチパッドとするモードを導入してはどうだろうか。Web サイトを見ている時や、動画視聴、電子書籍を読むといった時には文字入力は不要だ。だったら、タッチパッドで～す、バーン！というモードがあってもいい。少なくとも、狭さから来る不満は解消される。

恐らく、数年先には CPU の消費電力当たりの処理能力の向上、および、量産による低価格化が進み、同様に RAM 容量単価と SSD の容量単価が下がるだろう。そして、Windows 10 がこのまま年2回の大規模アップデートはあるものの、以前のように前提H/W要件が大幅に変わるほどの変更は無い状態で推移すれば、販売開始からサポート終了まで約12年半という長寿命だった Windows XP のお陰で生まれたネットブックのように、より安価に Windows PC が製造されるだろう。そして、OS の仕様に大きな変化が無ければ、その上で動くアプリケーションが成長することになる。大幅な OS の仕様変更に追随し続ける必要はなくなるし、蓄積された know-How の陳腐化がなくなるだろう。その結果、開発者はアプリケーションの洗練化や機能の改善、処理速度の最適化などに時間を回せるようになるからだ。その頃に、Windows タブレットがどうなっているかは分からないが、Windows 10 がゆったりとした変化を続けるのだとすれば、コンバーチブル型に収束され、恐らくは消えて行くと思われる。

現在 2in1 PC がジャンルとして確立しているが、これまでに述べた様に、コンバーチブル型に収束すると思われる。その中で、YOGA BOOK のような平面キーボードを持ったコンバーチブル型のジャンルも生き残るのではないだろうか。平面キーボードの採用によって、より薄く軽い PC を作ることができる事は、すでに YOGA BOOK が実証している。そして、2代目では、電子ペーパーでキーボード面を表示させることで、その1台で様々な言語版のキーボードとして使えるようになった。

このように、電子ペーパーによる多国語対応の平面キーボードを使用し、OS の標準言語を UTF-8 (Windows だから UTF-16 か？) に統一し、全ての言語のフォントを備え、各国語対応の入力メソッドも備えていれば、どこの国の人でも使える全世界対応 PC を作ることができる。この全世界対応 PC が、どこの国に行っても、気軽にレンタルできるようになっていると考えよう。全世界対応 PC を借りて起動すると、ログイン画面が表示される。この画面は英語である。そこで、Microsoft アカウント(あるいは別のサービスのアカウント)を使ってログイン認証を行うと、サーバーから自身のアカウントのホームディレクトリーと端末設定情報がダウンロードされ、キーボードは設定されている言語版となり、デスクトップ画面は自身の設定した内容が、設定された言語で表示される。その頃になれば 5G 通信も一般的となっているだろうから、ローカルドライブもリモートドライブも 300MB/s 以上でアクセスできるだろう。必要なアプリケーションはネットワーク経由で実行するか、キャッシュとしてローカルドライブにダウンロードして使用する。Webサービスは現在と同様に、ブラウザー経由で利用できるだろう。予め必要なアプリケーションをローカルドライブにキャッシュしておけば、それ以降はネットワークが繋がらない環境でも実行できるし、通信料金を抑えることもできよう。後は、その PC を持ち歩いて好きな場所で好きなようにアプリケーションを使えば良い。仕事なり、旅行が終わったら、作成したデータは、使用したアカウントのクラウドストレージに保管し、レンタルした PC の返却前に PC を初期化した後、返却すれば良い。

飛行機や新幹線でも同様のサービスを受けることができるようになる。最初はビジネスシートやグリーン席の限定サービスだろう。座席前のテーブルを引き出し、蓋を開けると、全世界対応 PC が現れる。移動中は、レンタルのケースと同様に使用できる。使い終わったら、初期化だ。

このような環境が生まれたら、旅行や出張時に PC を持ち歩く必要はなくなる。飛行機の搭乗時にわざわざ PC を開く必要もない。

Intel が内部で進めていた Tiger Rapids プロジェクトでは、片面が液晶ディスプレイで、片面が電子ペーパーとなっていた。YOGA BOOK c930 は、その形態によく似ている。また、別のプロジェクトでは、両面が液晶ディスプレイとなっており、タッチ操作ができるようだ。ASUS はこの方向に研究を進めており、タッチパッドを液晶ディスプレイにしたモデルが、既に発売されている。これらの延長線上には、片面がデスクトップ画面表示、片面がキーボード表示された、2画面表示のノートブック PC の姿が見える。YOGA BOOK のように、片面を平面キーボードとして使うだけで無く、両面を使って電子書籍の見開きを行ったり、片面は編集結果表示に使用し、もう片面はキーボードだけでなく操作画面を表示するといった使い方もできるだろう。さらに、bluetooth 接続の物理キーボードを使えば、コンパクトな2画面環境となる。片面には参考資料を表示し、もう片面で文書作成ツールを使って文書作成を行うといった使い方もできよう。もう1台と接続して、3画面表示＋キーボードという使い方もできる。

いずれにせよ、平面キーボードを受け入れられれば、これまでとは違ったジャンルとして使えるのではないだろうか。今日では、スマートフォンが普及し、国内では 80% 近くとなっている。13～59歳では90%を越えている。対して、PC の世帯主当たりの普及率は 80% 未満だ。特に地方では普及率が低いようだ。それでも、2台目として Surface Go のようなサブノート PC を個人が持つ時代が来ると考えている。最近は、文系の大学生でも、入学と同時にノートブック PC を購入するようだ。文献の調査や、課題の論文作成で使用するらしい。理系の学生なら、研究結果の集計やシミュレーション、数値計算などに使用するだろう。こういった世代が就職し、業務を PC でこなす上で、持ち運びに重点を置くことは容易に想像できる。自宅にデスクトップ PC を持つ場合は、24" 超のディスプレイを使うだろうし、ノートブック PC がメインである場合は 15" 程度のディスプレイのモデルが普及価格帯になってくる。そういった大きいディスプレイの情報機器と、スマートフォンの間にあるのが 8～10" のタブレット、または、10～12" のディスプレイのサブノート PC になる。常時持ち歩くことを考えると、800g 以下に収まるのが望ましい。OS に拘らずに軽くしたいならタブレットが向いているし、Windows 環境が必要であればサブノート PC になる。800g 以上でも構わないなら、13～14" のノートブック PC で、メインともなりうるモデルの方が良い。自宅では、大画面ディスプレイとキーボードに接続し、デスクトップ PC として使う方が良いかもしれない。

「現場で使える Ruby on Rails 5 速習実践ガイド」の梱包サイズは 23.5 x 18.3 x 2.6 cm　 = 1118.13 立方cm → 1.2g/cm3 x 1118.13 ≒ 1.3kg となる。これら技術書を電子書籍で持てば、浮いた 1.3kg が追加で持てるノートブック PC の重さだ。梱包サイズではなく、書籍サイズであればもう少し軽いだろう。800g が目安となるのは、こういった裏付けもある。

移動時の使用を想定して、ある程度パフォーマンスに妥協すれば、Surface Go のような重量と大きさが扱い易い。もし、Surface Go が Office なしで上位モデルが6万円前後で販売されていたら、状況は少し変わったかもしれない。タイプカバーを付けて8万円前後だ。YOGA BOOK も同じジャンルに位置づけられる。スマートフォンとメイン PC の間で、お外で使用する可搬性に特化した Windows PC だ。Surface Laptop Go LTE 版なんて出てきたら、日本では受けるのではないだろうか。

参考

• the 比較 - 2 in 1 PC/タブレットPCの比較＆おすすめ
• Intelが秘密裏に開発する2画面PC「Tiger Rapids」の正体が明らかに
• 総務省 平成30年版 インターネット利用の広がり
• １立方センチメートルあたりの平均的書籍の重量

Lenobo Yoga Book with Windows で Ruby on Rails チュートリアル

Yoga Book with Windows

Ruby on Rails チュートリアルを実施する環境として、Lenovo の Yoga Book with Windows (2016年モデル) を使用している。

開発環境

Yoga Book の Windows 10 Home に Windows Subsystem for Linux (WSL) として Ubuntu 18.04 LTS を導入し、Rails 開発環境を構築した。

通常は、WSL で SSL サーバーを起動し、Tera Term v4.101 で作業を行っている。WSL 上で使用しているエディターは vi である。当初は X-Window を導入し、IDE として Visual Studio Code (VSCode) で実装を進めるようとしたが、実際に使ってみると画面が崩れ、パフォーマンスが非常に低いことから VSCode の使用は断念し、軽量な vi での実装に切り替えた。Ruby on Rails チュートリアルでのコーディング量なら vi でも十分賄える。 作業ログとメモは、Markdown 形式のテキストファイルで記述している。エディターはテキストエディターの EmEditor Professional v18.5.0 と Markdown エディターの Typora v0.9.62 を使用している。Typora は分かり易くて使い勝手も良いが、重い。そのため通常は EmEditor で記述して、レイアウトの確認で Typora を使用している。

Yoga Book の良い面

Yoga Book での作業をしてみて良い面を下記に挙げる。

• 軽くて薄いため可搬性が非常に高い。気軽に持ち出せる。
• キーボードが無音(バイブレーションと音はOFFにしている)であるため、周りへの気遣いは不要であり、集中できる。
• 価格は約6万円程度(購入当時は64GBのモデルで約5万円だった)で、手を出しやすい。
• クラムシェル型であることで、テーブルの専有面積がタブレット＋カバー型の2in1モデルより小さく、膝上でも安定して使える。
• キーボードの掃除が拭くだけになり、楽である。
• スピーカーの音が、サイズを考えるといい方である。
• 自分の使い方ではペン入力、タッチ画面は使用していないので、性能と使い勝手はどうでもよい。

Yoga Book の悪い面

Yoga Book での作業をしてみて悪い面を下記に挙げる。

• パフォーマンスが非常に低い。Yoga Book 自体のスペック(Atom/eMMC)が低いことと、WSL のファイルシステムが遅いことで、rails コマンドの実行が遅い。例えば rails test の実行に20秒かかる。また、年に2回の大規模 Windows Update 適用には4～5時間を要する。
• キーボードが打ちづらく、通常のメカニカルキーボードに比べて入力速度はかなり落ちる。ある程度慣れたが、ブラインドタッチはできない。キーボードを見ながら人差し指を中心にした入力をしている。
• Home/End/Insert キーが無いため、テキストエディターでの編集効率が悪い。
• タッチパッドが狭くて使いづらい。
• 電源兼用の micro-USB ポートが1つのみで、拡張性が低い。しないけど。
• バッテリーの膨張問題が有るらしく、バッテリーの寿命が製品寿命となる。
• micro SD カードは相性があるようだ。ある日突然、スリープからの復帰で認識できなくなった。

総評

Yoga Book での Ruby on Rails チュートリアルの実装は、コマンド実行に待たされるためあまり効率的ではない。一方、喫茶店で実装を行う時など、気軽に持ち出せ、キーボードの音がしないのが気に入っている。パフォーマンスとキーボード入力に対して妥協できれば、Ruby on Rails チュートリアル用なら十分使用できると思う。ただし、キワモノなので、使う人を選ぶ。

Yoga Book を使ったら Happy になれる人

• 10インチサイズのサブノートPCとして割り切った使い方ができる人
• Halo キーボードの未来感に触れたい人

上記以外の人は、手を出してはいけない。

補足1

2018年後半に Yoga Book c930 が出たが、CPU が強力になったこと、ストレージ eMMC から SSD になった点、容量が 128～256GB に増えた点、USB type-C x2 が付くのは魅力的だ。しかし、RAM 容量が 4GB 固定なのと価格が3倍近くになったことで購入意欲が削がれた。安い方のモデルでは、Microsoft Office 無しで RAM 4GB/128GB SSD で 780g、13万円となる。少し足せば ThinkPad X1 Carbon が買える値段である。ほぼ同じサイズの Surface Go (RAM 8GB/128GB SSDモデル) は、(いらないけど) Microsoft Office 付き。タイプカバーを追加して 760g、約10万円である。

先日、量販店で Yoga Book c930 が実機展示されていたので、キーボード入力を試してみた。旧モデルよりもタッチパッドの触り心地や反応は良くなっていた。それから、タイトルバーのダブルクリック＆ドラッグで、ウィンドウの移動ができるようになっていた。打ちにくさは相変わらずだが、モダンキーボードモードにするとキーを若干大きくできるので、多少は改善される。このモードではタッチパッドをキー1列分大きくできるが、どうせなら、全面タッチパッドにした方がいいんじゃないか？

10万円を切っていれば買っていたかもしれない。

補足2

一般ユーザー向けの Surface Go LTE Advanced が発売開始された。8GB メモリーと SSD 128GB、Office 付きで9万8千円。やはり、Office 込みとなっている。タイプカバーとペンを着けたら、Yoga Book c930 とほぼ同じ価格帯だ。

そろそろノートブックPCのRJ45ポートは止めないか？

一般的なRJ45コネクターのLANケーブル

今回は、有線LAN に関する妄想。

最近のノートブックPCの仕様を見て、有線LANを搭載したPCが非常に少なくなって来ていることに気付いた。というか、前からその傾向はあったのだけど。

原因は、WiFi の普及と、PC本体の薄型化に有線LANのコネクター(RJ45ポート)の大きさが邪魔になったためだ。中には富士通のように、折り畳み式を採用しているメーカーもあるが、必要ならUSBドングルでいいじゃない？というスタンスが主流だ。

実際、WiFi も1Gbps辺りまででるようになってきており、配線の面倒くささもあって、有線LAN環境自体が省略されて来ている。それでも、有線LANは安定性が高く、セキュリティー面でも閉じた環境を作りやすいといったメリットがある。そのため、私の家庭内LANは、インターネット接続用の無線LANとデータ共有用の有線LANを併用している。

そのため、ノートブックPCのデータのバックアップは、有線LANに接続して実施する。例えば、VMWare の仮想ディスクなどの10GBを超えるファイルのコピーでは、無線LAN経由(我が家は最高でIEEE 802.11n環境)だと時間がかかる。IEEE 802.11ac ルーターを導入することで改善できるが、既にある Gbit Ethernet 環境が有るため、そちらを活用しようと考えてしまうからだ。

恐らく、今後のノートブックPCにはRJ45ポートは搭載されない方向に収束するだろう、というか、すでにそうなっている。その代替として、USB Type-C コネクターを使って、USB ドングル経由での有線LAN接続が標準となる。だとしたら、1000 BASE-T のハブの代わりに、複数の USB ドングルを内蔵し、LAN のハブとしても機能するものがあればいいのではないか？USB PD 機能も内蔵させれば、電源としても使える。例えば、外出先からオフィスに戻り、この LAN+PD ハブに接続すれば、社内 LAN に有線で接続しつつ、充電しながらPCが使える。外出するときには、USB ケーブルを抜くだけだ。一般的なUSBドックを人数分揃えるよりは、設置スペースの節約になり、配線も電源とLANケーブルが統合されて1/2になる。このLAN+PD ハブ間は従来のLANケーブルで接続すればよい。

この LAN+PD ハブを導入する前提は、接続する PC が USB PD に対応した USB 3.1 Gen2 ポートを持っていることと、USB+LAN ハブに内蔵されたLANアダプターが、OS の標準デバイスドライバーとして認識されることだろう。LAN アダプター部分は枯れたチップを使用すれば、特別に開発する必要はない。更に、コストが許せば、10G Ethernet 環境への移行もしやすいだろう。これは、小さい USB Type-C コネクターの一般化、10Gbps に耐える USB 3.1 Gen2 の普及、 USB PD による充電の普及によって実現可能となる。恐らく、2年内にほとんどのノートブックPC側はこの要件を満たすだろう。スマートフォンやタブレットでも使えるだろう。オフィスだけでなく、コーヒーショップでも差別化に使えるのではないだろうか？もちろん、家庭内LANでも、有線LAN使用時の配線をスッキリできる。こんな LAN+PD ハブが10ポート10万円位で出てきたら、売れるのではないか？

# 今は、USB PD 対応のドックを買っとけ、てことなんだけど。

塾に通わずに大学入学試験に合格する方法

勉強中

今回は、学習方法について考えてみた。 長くなったため、最初にまとめを述べる。

まとめ

• 国語はとても大切。
• 授業中は無為に過ごさない。
• 予習と復習は大切。
• 教師と友人は大いに利用する。
• ノートってすごい。

序

そろそろ、大学の入学試験が本格的に始まる時期になった。私は、友人や兄弟の子供も大学受験を迎えたり、既に終わったという世代である。

そういえば、自分の大学受験はどうであったかを思い出すと、当時は周りには浪人生を除いて、塾に通っている友人は少なかった。それでも、卒業時には7～8割の生徒がいずれかの大学の入学試験に合格していたと思う。当時の普通科高校の進学クラスに在籍していたので、就職クラスの状況は分からない。

当時と今とでは、入学試験の内容や実施方法が異なるだろうが、少なくとも、試験範囲は小学校、中学校、高等学校で学習の範囲を超える事は無いはずである。難易度は違えど、応用問題として回答できるはずだ。その範囲を超える場合については、経験が無いので触れないでおく。

さて、表題の「塾に通わずに入学試験に合格する方法」だが、予習と復習と授業ですべてをまかなうということである。以下にその方法について紹介する。ちなみに、この方法は父が学生時代に実践していたものを自分なりにアレンジしてみて実践したものなので、本質的には現世代でも通用すると思う。地方の国立大学に合格した実績を持つ手法であるであることを付記しておく。

受験対象は国公立大学を想定し、受験対象の教科は全教科とする。共通一次試験の世代であるため、国語、数学、英語、そして、理科と社会は選択であるため、得意な科目を選ぶことになる。私の場合は、どちらかと言えば文系が好きだったが、受験対象の大学の選択肢を狭めたくなかったため、高校時代は理系クラスを選択した。苦手な数学、物理の授業は嫌でも受けることで、共通一次試験の合計点数を上げることを目指した。ちなみに、理科は化学と生物を、社会は世界史と政治・経済を選択した。

最も大切な教科

最初に、国語について述べる。

大学受験だけでなく、就職して実社会に出てからも含めて、日本人の最も大切な教科は現代国語であると考える。国内で大学を受験する場合、外国語学部など一部を除いて、試験問題は日本語で書かれている。問題文を理解できなければ、回答を書くこともできない。マークシート方式であれば適当に選択もできるが、それは残り時間が足りなくなったときの応急措置と考えよう。

学習全般についても、参考書は通常は日本語で記述されているし、授業の説明も日本語で行われる。質問する場合も、その回答も日本語だ。脳の中で自身の考えをまとめるにも通常は日本語を使用する。そのため、空気を吸うが如く日本語が使えることが、高等学校卒業レベルでは求められていると考えてよいし、目指すレベルだ。

国語力を身につけるには、社会人なら新聞の社説を読むのが良いだろう。高校生では社説は内容が身近に感じられない。とにかく本を読むのが良いだろう。題材は短めのエッセイ集とか参考書で良いので、起承転結がしっかりした文章が良い。現代国語の問題集の例文を読むのも良いだろう。共通一次試験の過去問も入手しやすかった。小論文の解答例もよい題材となる。とにかく、程良い長さの、構成がしっかりした文章に常に接すること、結論までの流れを把握することを続ければ、基礎力は付く。世の中に広く行われている Blog を書くことも、文章の構成や語彙の習得、問題の整理に役に立つ。復習の方法としても、役に立つのではないか。小論文の練習にもなる。フィードバックがあれば、改善することもできるし、モティベーションにもなる。

社会人になってからは、国語力がないと仕事にならない。仕事によって差はあるが、SE として働くには、仕様書を読む書く、設計書を読む書く、設計書を読む書く、プログラムのソースコードを書く(日本語はコメントのみだが)、メールを読む書く、説明資料を読む書く、などのように日本語を使っての情報の伝達に非常に多くの時間を割くことになる。昨今では、この中で英語の比重が増えて来るが、標準語が日本語である企業で働く限り、日本語でのコミュニケーションによって様々な活動が行われる。業務指示も日本語であり、伝達ミスは障害発生要因となり、場合によっては訴訟に及ぶトラブルにもなりかねない。訴訟は極端な例であるが、会議室の予約時間の伝達ミスで、会議開始の時間に使える会議室が一つもなくて会議ができない、といった事は新人の頃に経験はあるだろう。如何に正確に伝えられるかは非常に重要な技術となる。

プログラミングの世界では、1990 年代にオブジェクト指向が出てきた。オブジェクト指向での重要な考え方として、「継承」がある。この継承の概念を説明する時に、オブジェクトの例として「犬」で説明しようとするような例が多かった。「犬」オブジェクトには「鳴く」メソッドがあり、出力は「ワンワン」である。この「犬」オブジェクトのスーパークラスは「動物」であり、「鳴く」メソッドの他に「眠る」メソッドがあり、出力は「スヤスヤ」である。この「動物」クラスを「犬」クラスは継承することで、「眠る」メソッドはスーパークラスの「動物」クラスに実装された「眠る」メソッドをそのまま使用する。一方、犬特有の「鳴く」メソッドは独自に実装する。ここで、新たに「猫」クラスを考えよう。「猫」クラスは「動物」クラスを継承して、「犬」クラスと同様に「鳴く」クラスを独自に実装し、出力は「にゃあにゃあ」としよう。このように、犬と猫の共通した特性はスーパークラスで実装し、犬と猫の独自の特性は「動物」クラスを継承したサブクラスとして実装する。犬と猫のそれぞれの独自の特性である「鳴く」メソッドを実装するのが、オブジェクト指向の継承を使用した差分コーディングである、云々。この説明では本質的には間違っていない。しかし、プログラマーにはピンと来ない。抽象的な継承という概念を、たとえ話をプログラミングでは扱わない例で説明しているからだ。このケースでは、UNIX の「ファイル」と「ディレクトリー」を例にした方が、より具体的なイメージができる。「ファイル」がスーパークラスで、「ディレクトリー」は「ファイル」のサブクラスである。「ファイル」クラスには「名前」の取得メソッド、変更メソッドがある。また、作成メソッドと削除メソッドがある。「ディレクトリー」クラスは、それに加えて、自身に含まれる複数の「ファイル」または「ディレクトリー」オブジェクトを操作するメソッドがある。また、削除メソッドは自身を削除する前に、含まれている全ての「ファイル」「ディレクトリー」オブジェクトの削除メソッドを呼ぶようにメソッドの振る舞いが変わる。「名前」の取得メソッド、変更メソッドはスーパークラスのメソッドをそのまま使用する。このような例で説明した方が、実際にプログラムを設計する際の参考となりやすい。単純に左から右に伝えても良い場合もあるが、相手が理解しやすい様に表現する必要もある。そういう国語力が社会人になってからは求められる。

授業の受け方

授業は集中して受けること。

社会人であれば、年間の授業料を1時限当たり幾らになるかを意識することで、授業を無為に受けることは無いだろう。授業をないがしろに受けて塾で補完することは、学費が嵩むばかりでなく、塾への通学時間などで学習時間を減らすことになる。それほど裕福な家庭でもなかったので、塾に通うお金と時間は、参考書の購入と予習復習の時間や趣味の時間に充てる方が良いと考えていた。

授業は予習で理解できなかった箇所の確認の場とする。

授業での説明だけで理解できれば復習は不要になる。また、予習では自分なりの解釈をするが、授業では教師による説明がより洗練されているはずだ(もちろん、そうでない教師もいる訳だが...)。さらに、耳から説明を聞くのも、自習では得られない学習方法であり、記憶の残り方が違う。

授業だけで分からない箇所は教師に質問する。

質問はその場でもいいし、授業終了後でもいいし、放課後でもいい。教師は教えるプロであるため、疑問点に対して親身になって教えてくれる。担当教師がそれができなければ、別の教師に質問する手もある。授業料を払っているのだから、効率よく授業を受けて、教師の能力を活用しよう。学生の頃、塾の講師のアルバイトをしていて、教える立場で接してみると、質問の回数と内容が生徒の学力と関係があるように思えた。また、質問を受けると、相手が理解し納得するまであの手この手を使って説明するようになり、相手が理解できたことが自身の快楽中枢への刺激となっていく。分からないことを質問して理解することは、生徒側だけでなく、教師側にもプラスの方向に働くことは知っておくと良いだろう。

時にはハズレの教師もいる。授業ではなにを言っているのかよく分からない、教科書に書いてあること以上の説明がない、つまらなさそうに生徒に接する、そういった教師の授業は真面目に受ける必要は無い。損切りと考え、その授業は自習の時間と割り切る。テストに関連する説明だけに注意を向けて、後は問題集を解きまくって補完し、分からない箇所は別の教師に質問する。

予習の仕方

予習は授業を効率よく受けるための準備である。

私自身は、予習にそれほど力を入れた記憶はないが、授業を受ける前に教科書に目を通し、分からない箇所、補足が欲しい箇所にアタリを付ける程度は行っていた。これは、余裕があれば前日、余裕がなければ授業前の休み時間を利用して行っていた。

また、年度初めに教科書が配布され受け取った直後に、現代国語と英語の教科書は全て読んでいた。そのため、授業を受けるときには、その文面にデジャヴ感を覚えていた。他の教科については、ザッと目を通す程度だった。世界史は多少読み込んで、脳内の世界地図と年表に照らし合わせるようにした。

予習にかける時間があれば、授業を受ける前に、その範囲の練習問題を解くところまでできているとよい。そこまでできなくとも、事前に授業で注目する箇所、質問が必要な箇所を洗い出しておく。そうすることで授業を効率良く利用することができる。

復習の仕方

復習は授業内容の整理と理解の定着を行う儀式である。

高校生時代から、教科毎のノートにはルーズリーフを使用していた。各教科はインデックスシートで分割管理し、２～３日分のブランク用紙を持ち歩くことで、全教科でノートは薄いバインダー1冊持ち歩けば良かった。

帰宅後、本日分のノートを自宅の保管用バインダーに移動する。その際、ノートを読み返して、理解できていない箇所について、教科書や参考書を読んで補完する。授業ノートで足りない部分については、ルーズリーフの新しいシートにポイントをまとめて、追加しておく。これが主な復習となっていた。

ルーズリーフを薄く軽くすることがモティベーションとなり、授業ノートの整理を毎日行った。その際に、当日分のノートを見直すことで授業内容を思い出し、反復学習とする。また、参考書などの問題集を解くことで、理解を定着する。その繰り返しだ。理解ができない箇所については、参考書等で補足し、それでも理解できなければ、翌日以降の質問内容としてメモしておき、学校で教師に質問する。そうすることで、理解できない箇所を潰していく。

ルーズリーフを使う方法がベストとは言わないが、ノートの整理が復習のトリガーとなり、自分の中では上手く機能した。恐らく、教科毎にノートを使うのが一般的だと思う。その場合は、毎日、当日分のノートの記載内容に目を通す習慣をどのように身につけるかを考えると良いだろう。

その他

その他の勉強方法について述べる。

友人と相互に教え合う

高校時代はクラスメートは、国公立大学受験を目指すという共通の目標があり、それぞれの学力レベルも知っている間柄だった。そのため、得意科目について教え合うという行為も自然に行われていた。教えるのも勉強と言われるが、実際に他人に自分が理解している内容を、相手が理解できるように説明する作業は、自分が理解することに比べて数倍の力を要する。説明対象について正確に理解していることは当然で、その内容の伝達の為の例えとか説明を考え、相手の理解レベルに合わせて説明内容も変化する必要がある。時には、自分で説明をしながら、ストンと腹に落ちるように理解することもあったり、逆に自分がとんでもない誤解をしていることが見つかることもある。複数人で話していれば、より効率の良い考え方や教え方に出会うこともある。教えて貰う立場では、教師とは異なる背景が自分に近い同世代の人間から教わることで、より理解しやすかったり、楽しかったりする。こうして教え合う関係が構築されると、次第にこの分野は誰に聞け、といった得意分野が出てくる。そうなると、自分の得意分野については一層理解しようと努力するようになるし、説明を重ねることでさらに理解が深まるという正のスパイラルが発生する。このように、教師とは異なる視点と立場を持った友人と教え合うのは、メリットが多い。

苦手分野の巻き取り

授業と予習、復習だけではなんともし難い部分も出てくる。基本的に、大学受験で必要とされる学力とは、小学校、中学校、高等学校で学ぶ範囲の集大成である。どちらかと言えば、知識に重点が置かれて記憶力が高い方が有利である。しかし、前年度に習得した知識に基づいて内容が構成される、積み重ね型の教科もある。この場合は、特定の箇所のみ重点的に学習しても効果は出ない。自分にとっては、数学がそれに該当し、中学校の正比例、反比例の当たりがモヤモヤしていた。そこで、本格的に受験勉強を始める高校3年生の時に、中学生用の参考書を購入して、6年分を勉強し直した。結果として、平均点以上を取れるようになった。

ノートについて

以下は、ノートについての蛇足である。

高校生時代に採用したルーズリーフによる授業ノート管理は、大学時代も続けた。大学でも機能したが、ノートを貸した場合に紛失するという事故も発生した。それ以降は、コピーを貸すことで防止した。

社会人になって 1990 年代は、小型化してシステム手帳でスケジュール管理と備忘録として使用する様になり、ルーズリーフは使用しなくなった。仕事の文書類は、ほぼA4サイズ (一部、A3 サイズ) に統一され、プリントアウトしたものを持ち歩く様になった。

2000 年代からは、文書の電子化が進むと同時に、可搬性の高いノートPCを携帯する様になった。その結果、プリントアウトした文書の量は減少していった。一方で、仕事を表すものとして、案件毎に紙の文書を扱うようになった。ある案件に必要な資料をクリアホルダーでまとめて管理していた。仕事に行く場合、必要なクリアホルダーと、ノートPCのみ持って行く。ノートは持たず、A4のノートパッド、もしくは、A4のブランク用紙を無印良品のアクリル クリップボードに挟み、書き込んだ紙は案件毎のクリアホルダーに挟んでいく。クリップボードのお陰で、立った状態でもメモが取れ、用紙には不要なプリントアウトの裏面を使ったりしていた。案件毎のクリアホルダーの最上面には、手書きで案件名とチェックリストを書いて、進捗も分かるようにしていた。作業が完了したら、赤字で済みと記述し、保管が不要なら破棄すれば仕事が1件片付くということが分かりやすかった。クリアホルダーが数冊になる場合は持ち歩く時用に薄いドキュメントケースにクリップボードと共に入れて鞄に入れていた。これで、クリップボードの金具部分でノートPCへの傷防止も果たすことができる。

2010 年代は更に文書の電子化が進み、共有機能が増したことと、ビューアーとしてスマートフォンやタブレットなども使用できる用になった。その分、手書きの紙媒体が使いにくくなり、スキャナーでPDF化することで補完する様になった。普段のメモも、テキストファイルで記録する様になった。最近は、より表現力が高く入力負荷の低い Markdown 形式のテキストファイルでメモを作成するようになった。Markdown 文書の利点として、Word や Excel 文書と異なり diff による差分確認ができることと、Git でのバージョン管理との相性の良さがある。また、OS 標準の文字列検索が利用できる点も利点となる。コマンドラインで grep や findstr でも検索は可能だ。出力結果に意味不明な文字列が含まれることもない。更に、インターネット環境下では UTF-8が標準の文字コードとして使用されるようになり、エディターなどのツール類でUTF-8対応している物が増えた結果、自分に合った使い方ができるツールの選択肢が増え、より使い易い編集環境で作業ができるようになった。文書管理は、PC 上のファイルシステムのフォルダーで行い、OneDrive や Dropbox でクラウド化している。短い使い捨てのメモや、アイデア出しには Evernote を利用している。単純な表計算や図の作成には Google Drive を利用している。プロジェクトで使用する文書は主に Excel や PowerPoint が現役だった。ただ、一段落した所で PDF でも出力していた。そうすれば、Mac の QuickLook でスペースキー押下で内容の確認ができる。Windows ならば、Microsoft Store アプリの WinQuickLook で同様の使い方ができる。

実現する方法は異なるが、高校時代に目指していた、ノートの薄型化と軽量化の追求は継続している。電子化が進むことで、ネットワークに繋がれば、現物のファイルを持ち歩かずに、どこでもノートにアクセスできるようになった。しかも、シチュエーションに合わせた機器でアクセスできる。混んだ通勤電車内ではスマートフォンの方が良いし、場所と電源の確保ができる場所ならノートPC、ベッドやソファーで寛いだ姿勢ではタブレットで、と選びたい放題だ。

また、ルーズリーフで始めたドキュメントの薄型化と軽量化の追求は、そのまま、ノートPCの進化とも連動している。自分達の世代は、紙文書の文化からデジタル文書の文化への移行の流れに巻き込まれて生きてきた。親の世代は、紙文書の文化が中心だろう。現在の子供の世代は、デジタル文書の文化の世代だ。次の世代は音声入力だろうか、喧しくなりそうだ。いずれにせよ、ペンと紙による文書記述の手法が、文字変換ソフトに置き換わる事で、漢字の読み書きや適切な漢字、用語の選択などの国語力が落ちないようにする必要があろう。

近い将来、小学校からのプログラミング教育が必修化される。プログラミングに必要な論理的な思考を、幼い頃から育もうとしているようだが、どうだかなあ、というのが率直な意見である。小学生までは国語を中心とした教育を行って、中学生で英語を導入するのと同時期にプログラミング教育を始めた方が効果的ではないだろうか。SVOC といった英文法を修得した後にプログラム言語を学んだ方が理解し易いだろう。一般的にプログラム言語は暗黙的に英語をベースとして作り出されている。日本語ではなく英語で考えた方がプログラミングには向いているし、各種ライブラリーやメソッド名も英語が使用されている。ドキュメントは通常は英語のみである場合も少なくない。日本語がされている場合は、英語版と日本語版の両方みることで、英語の学習にもなるだろう。

また、大学の共通試験も、導入時に普及していたマークシート方式が採用されて30年近く経過した。昨今の多くのIT関連の技術資格試験では、PC操作の選択式回答方式が採用されている。技術的にはWebサーバーで試験問題を出題し、スマートフォンで回答することが可能となっている。大学の共通試験を記述式も含めてPCで行うようにすれば、必然的にPC操作やキーボード入力が受験の前提スキルとなり、教えなくとも勝手に学ぶことになるだろう。

随分前にネットブックが話題になったが、その根底には発展途上国での子供のコンピューター教育用として、安くて丈夫で必要十分な能力を持った可搬性の高いコンピューターを提供する目標が有った。それにより、ノートPC型で5万円以下というジャンルが生まれた。大学入学試験をPCで行うのと同時に、3万円レベルのサブノートPCのジャンルの確立を国策として進めてみてはどうだろうか。ミドルレンジのスマートフォンレベルのPCである。海外では、そのセグメントは Chromebook が強いと聞く。Google へのロックインを避けるなら、OS は例えば Ubuntu 日本語 remix を使えば良い。最悪、学校には据え置きのデスクトップPCを用意して、生徒はポータブルSSD のみを持ち歩く。学校で、ポータブル SSD から PC を起動すれば、生徒の個人環境が立ち上がる。授業で使用する教科書もノートも辞書も全て ポータブル SSD に収まるため、「なまら重」い教材を持ち歩く事も無くなる。ノート PC の場合はそれよりもずっと重くなるが、それでも800gに抑えられれば、ランドセルよりは軽い。価格も3万円程度であれば、ランドセルと同程度と思えよう。前述のネットブックが出て来たのが約10年前だが、Windows XP を動かして 1kg 程度の重量に押さえていた。OS についても、新たに開発せずに Ubuntu など既存の Linux ディストリビューションを国で定め、国費からそのディストリビューションの改良、開発を行うことで、使い易くするだけでなく、国内の開発技術の底上げを行うことも望めよう。OS の新規開発よりも、教材開発や通信費補助に予算を割り当てれば、費用対効果が高いのではないだろうか。また、OS に一般的な Linux のディストリビューションを採用する事は、即ち各生徒の学習環境が開発環境ともなるメリットがある。bash だけでなく、Perl、Ruby、Python といったスクリプト言語は使える状態になっているだろうし、GCC は通常は直ぐに導入できるはずだ。本格的なプログラミング環境を購入する必要がない。興味を持った生徒はその日からプログラミングを始められる。また、互換性はまだ十分ではないが、オフィスソフトも揃っている。物足りなければ、国の負担で改良すればよい。CPU も、x86 に限定せずに ARM や RISC-V 準拠のものも対象にして省電力に注視すれば、バッテリー容量を減らすことで、より軽量化が望めるのではないだろうか。そうして環境面の均一化ができて、コンピューターリテラシーが底上げされるようになれば、新入社員がキーボードで入力できないなどと嘆くことも無くなるだろう。

さて、絶賛脱線中だが、もう少し続く。

ノートは自分の脳の補助記憶装置である。PC で言えば、外付け HDD だったり、NAS だったり、クラウドストレージだったりに該当する。以前、同じ様な文書を作ったなあ、というときに紐解くような使い方が主である。しかし、忘れたときに思い出すためだけではなく、ノートに纏めるという作業自体に、物事について自分の捉え方と考え方を整理するという作業が含まれている。ノートは紙媒体でもテキストファイルでもWebサービスでも何でも良い。将来は言葉で入力したり、脳波によって思考を入力する様になるかもしれない。何れも、自分の考えを整理するツールとして使い、迷ったときの道標として使えればよい。自分にとって入力しやすく、参照しやすく、無くならないものであれば、時代の環境に合わせて保存方法は選択すればよい。ノートに纏めるというだけでも立派な学習手法であるし、後で見返して自信を取り戻すこともできる。ノートを取るというシンプルな行為が持つ効能は、もっと評価して活用したいものだ。

---

参考 - 「日本語の主語とは何か」 - 「ニトリ ランドセル スピリッツ」

Windows Update 適用後に ThinkPad トラックポイント・キーボードのミドルクリックが効かなくなる

ThinkPad トラックポイント・キーボード

備忘録である。

私は、Lenovo の ThinkPad トラックポイント・キーボードを愛用している。長年、ThinkPad を使ってきたから慣れているというのもあるし、マウス操作をするのにキーボードから手を離さずに済むのが良い。また、センターボタンがあり、スクロールではなく、ミドルクリックとして使っている。Chrome や FireFox でタブのクローズやリンクを新規タブで開く操作が、ミドルクリック一発でできるのが便利だ。

久しぶりに Windows 10 のデスクトップ PC を使うことになり、ひたすら待たされる Windows Update を適用した後で再起動したら、ミドルクリックが使えなくなってしまった。どうやら、マウスのデバイスドライバーが更新された様子である。

Lenovo のサイトから最新版のドライバーをダウンロードして適用してもダメ、マウスのプロパティ設定ではスクロールの設定のみで、センターボタンにする設定は無い。

Google で調べてみたところ、やっと原因がわかった。マウスのプロパティの詳細設定タブで「トラックポイントの優先スクロール」がチェックされた状態になっていた。このチェックを外したところ、ミドルクリックが復活し、元の操作ができるようになった。分かってしまえばしょうもない設定漏れとなるが、この設定画面は何度も見たはずなのに、「トラックポイントの優先スクロール」が何を意味するのかが理解できていなかった。

マウスのプロパティで「トラックポイントの優先スクロール」のチェックを外す。

まとめ

• 大規模な Windows Update を適用した後は、設定が初期化されることがあることを前提に確認しよう。
• 設定項目が何を示しているのか冷静に見よう。

Ruby on Rails チュートリアル第2章 MVC を理解する (2周目)

Ruby on Rails Tutorial

Ruby on Rails チュートリアル の2周目、第2章の User モデル追加を行った。演習でなんとなく MVC の図で分かったつもりだったが不十分だったので、もう少し突っ込んでみた。

シーケンス図にしてみる

第2章の「2.2.2 MVCの挙動」のような図はよく見かけるもので、なんとなくは理解していたが、実際のソースコードとのマッピングが自分の中で十分できていなかった。そこで、シーケンス図を描いてみてより理解を深めることにした。下図はチュートリアル内の MVC を説明する図である。

実際に Rails を動かし、ユーザーの一覧表示、新規登録、ユーザー情報編集、削除のオペレーションを行って、新たに追加されたソースコードがどのように使用されているかを確認した。結果は次のようになった。

ユーザーの一覧表示

ユーザーの新規登録

ユーザー情報編集

ユーザーの削除

解析の方法

最初は、byebug を使って少しづつ動作してみたが、効率が悪い。それぞれのソースコードに記述されたクラスのメソッドで、呼び出しと return の箇所に puts でメッセージを標準出力させるようにした。いわゆる print debugging である。これでブラウザーで操作をしては、Rails のメッセージ出力を読むことで呼び出し順を確認した。

メッセージを出力するのに苦労したのは、モデルの user.rb である。scaffold で生成されたソースコードは下記の通り。

class User < ApplicationRecord
end

使用されているメソッドとメッセージ出力を加えたソースコードは下記の通り。

class User < ApplicationRecord

  def User.hello
    puts "-------------------------------- user.rb#hello ------"
  end

  def User.all
    puts "-------------------------------- user.rb#all Enter --"
    @users = super
    puts "-------------------------------- user.rb#all Exit ---"
    return @users
  end

  def initialize(*)
    puts "-------------------------------- user.rb#new Enter --"
    @user = super
    puts "-------------------------------- user.rb#new Exit ---"
  end

  def User.find(args)
    puts "-------------------------------- user.rb#find Enter --"
    @user = super(args)
    puts "-------------------------------- user.rb#find Exit ---"
    return @user
  end
end

また、ビューの index.html.erb は試行錯誤した。修正後のソースコードは下記の通り。他のビューのソースコードも同様に修正した。

<p id="notice"><%= notice %></p>

<% puts "-------------------------------- index.html.erb Enter --" %>
<h1>Users</h1>

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Email</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @users.each do |user| %>
      <tr>
        <td><%= user.name %></td>
        <td><%= user.email %></td>
        <td><%= link_to 'Show', user %></td>
        <td><%= link_to 'Edit', edit_user_path(user) %></td>
        <td><%= link_to 'Destroy', user, method: :delete, data: { confirm: 'Are you sure?' } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<br>

<%= link_to 'New User', new_user_path %>
<% puts "-------------------------------- index.html.erb Exit ---" %>

コントローラーは、各メソッドの最初と最後にメッセージ出力を追加した。修正後のソースコードは下記の通り。

class UsersController < ApplicationController
  before_action :set_user, only: [:show, :edit, :update, :destroy]

  # GET /users
  # GET /users.json
  def index
    puts "------------------------- UserController#index Enter --"
    #User.hello # => method not found error
    @users = User.all
    puts "------------------------- UserController#index Exit ---"
  end

  # GET /users/1
  # GET /users/1.json
  def show
  end

  # GET /users/new
  def new
    puts "------------------------- UserController#new Enter --"
    #@user = User.new
    @user = User.new()
    puts "------------------------- UserController#new Exit ---"
  end

  # GET /users/1/edit
  def edit
  end

  # POST /users
  # POST /users.json
  def create
    puts "------------------------- UserController#create Enter --"
    @user = User.new(user_params)

    respond_to do |format|
      if @user.save
        format.html { redirect_to @user, notice: 'User was successfully created.' }
        format.json { render :show, status: :created, location: @user }
      else
        format.html { render :new }
        format.json { render json: @user.errors, status: :unprocessable_entity }
      end
    end
    puts "------------------------- UserController#create Exit ---"
  end

  # PATCH/PUT /users/1
  # PATCH/PUT /users/1.json
  def update
    puts "------------------------- UserController#update Enter --"
    respond_to do |format|
      if @user.update(user_params)
        format.html { redirect_to @user, notice: 'User was successfully updated.' }
        format.json { render :show, status: :ok, location: @user }
      else
        format.html { render :edit }
        format.json { render json: @user.errors, status: :unprocessable_entity }
      end
    end
    puts "------------------------- UserController#update Exit ---"
  end

  # DELETE /users/1
  # DELETE /users/1.json
  def destroy
    puts "------------------------- UserController#destroy Enter --"
    @user.destroy
    respond_to do |format|
      format.html { redirect_to users_url, notice: 'User was successfully destroyed.' }
      format.json { head :no_content }
    end
    puts "------------------------- UserController#destroy Exit ---"
  end

  private
    # Use callbacks to share common setup or constraints between actions.
    def set_user
      puts "------------------------- UserController#set_user Enter --"
      @user = User.find(params[:id])
      puts "------------------------- UserController#set_user Exit ---"
    end

    # Never trust parameters from the scary internet, only allow the white list through.
    def user_params
      params.require(:user).permit(:name, :email)
    end
end

シーケンス図は PlantText を使用して作成した。ユーザーの追加の操作の PlantUML の記述は下記のようにした。他の図も同様に作成した。

@startuml

title
  Ruby on Rails チュートリアル 2.2.2 MVCの挙動
  (POST /users createアクション)
end title
hide footbox

actor ブラウザー as user
box "Control"
participant users_contoller.rb as control
end box

box "View"
participant new.html.erb as vnew
participant show.html.erb as vshow
end box

box "Model"
participant user.rb as model
participant ActiveRecord as ar
end box

database SQLite3 as db

user -> control : GET /users/new
activate control

control --> model : new
activate model
model --> ar : new
model -> control
deactivate model

control -> vnew
activate vnew
deactivate control
vnew -> user
note left
  ユーザー登録
  画面の表示
end note
deactivate vnew

====

user -> control : POST /users
activate control
note left
  新規ユーザー
  の登録
end note

control -> model : create(1)
activate model

model -> ar : create(1)
ar -> db : SQL
note right
  INSERT INTO users
  (name, email, created_at, updated_at)
  VALUES (?, ?, ?, ?)
end note
model -> control : 成功
deactivate model

deactivate control
control -> control
activate control
note right : Redirect GET /users/1

control -> model : find(1)
activate model

model -> ar : find(1)
ar -> db : SQL
note right
  SELECT users.*
  FROM users
  WHERE users.id=1
  LIMIT 1
end note
db -> ar : user (1)
ar -> model : user (1)
model -> control : user (1)
deactivate model

control -> vshow : user (1)
activate vshow
deactivate control
vshow -> user : user (1)
note left
  ユーザー情報
  画面の表示
end note
deactivate vshow

@enduml

まとめ

• シーケンス図を書いてみたら理解が深まった。
• モデル クラスでは、ActiveRecord が大活躍。
• Ruby のメソッドのオーバーライドの書き方がわかった。
• byebug の使い方がわかった。
• PlantUML でのシーケンス図の書き方がわかった。

以上。

Ruby on Rails チュートリアル第1章で Heroku へのデプロイに失敗 (2周目)

Ruby on Rails チュートリアル の２周目、最後の Heroku へのデプロイがうまくできなかったため、対処方法をまとめておく。

ビルドエラー

git push heroku master で Heroku に push するとビルドが開始するが、途中でエラーとなってしまう。発生したエラーの内容は、下記のようになっている。

  :
remote: Building source:
remote:
remote:  !     Warning: Multiple default buildpacks reported the ability to handle this app. The first buildpack in the list below will be used.
remote:                         Detected buildpacks: Ruby,Node.js
remote:                         See https://devcenter.heroku.com/articles/buildpacks#buildpack-detect-order
remote: -----> Ruby app detected
remote: -----> Compiling Ruby/Rails
remote: -----> Using Ruby version: ruby-2.4.5
remote: -----> Installing dependencies using bundler 1.15.2
remote:        Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
remote:        Warning: the running version of Bundler (1.15.2) is older than the version that created the lockfile (1.17.1). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
remote:        Fetching gem metadata from https://rubygems.org/.........
  :
remote:        Running: rake assets:precompile
remote:        Yarn executable was not detected in the system.
remote:        Download Yarn at https://yarnpkg.com/en/docs/install
remote:        rake aborted!
  :

上記で、1箇所ワーニングメッセージが出ている。Heroku 上では Bundler のバージョンが 1.15.2 を使用していることを示している。PC 上では 1.17.1 を使用していたため、Gemfile.lock に 1.17.1 が記録されている。これについては、PC 上の Bundler を一旦削除して 1.15.2 を導入することで対応した。

remote:        Warning: the running version of Bundler (1.15.2) is older than the version that created the lockfile (1.17.1). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.

エラーメッセージが出ている。これは node.js でビルドできなければならないことを示しているらしい。

remote:        Yarn executable was not detected in the system.

このエラーに対しては、「herokuにアップできません」を参考にして、下記コマンドで対応した。

$ heroku buildpacks:add --index 1 heroku/nodejs

アプリケーションエラー

ビルドのエラーがなくなっても、ブラウザー画面にはアプリケーションエラーが表示される。ログを参照すると、npm start を実行しようとしている。

$ heroku logs --tail
  :
2018-12-06T17:01:39.670033+00:00 heroku[web.1]: Starting process with command `npm start`
2018-12-06T17:01:37.789569+00:00 app[api]: Scaled to web@1:Free by user xxxxxxxx@xxxx.com
2018-12-06T17:01:38.000000+00:00 app[api]: Build succeeded
2018-12-06T17:01:37.767042+00:00 app[api]: Release v3 created by user xxxxxxxx@xxxx.com
2018-12-06T17:01:41.658747+00:00 app[web.1]: npm ERR! missing script: start
2018-12-06T17:01:41.665561+00:00 app[web.1]:
2018-12-06T17:01:41.665874+00:00 app[web.1]: npm ERR! A complete log of this run can be found in:
2018-12-06T17:01:41.666017+00:00 app[web.1]: npm ERR!     /app/.npm/_logs/2018-12-06T17_01_41_660Z-debug.log
2018-12-06T17:01:41.736904+00:00 heroku[web.1]: State changed from starting to crashed
2018-12-06T17:01:41.738983+00:00 heroku[web.1]: State changed from crashed to starting
2018-12-06T17:01:41.719407+00:00 heroku[web.1]: Process exited with status 1
  :

「herokuにアップできません」を参考にして、「Heroku - The Procfile」をProcfile を作成してみたがアプリケーションエラー発生。Profile の内容は下記の通り。

web: bundle exec rails server -p $PORT

ログの内容は下記の通り。

  :
2018-12-06T17:17:14.000000+00:00 app[api]: Build succeeded
2018-12-06T17:17:20.202948+00:00 heroku[web.1]: Process exited with status 1
2018-12-06T17:17:20.227931+00:00 heroku[web.1]: State changed from starting to crashed
2018-12-06T17:17:20.230674+00:00 heroku[web.1]: State changed from crashed to starting
2018-12-06T17:17:20.134913+00:00 app[web.1]: /usr/lib/ruby/2.5.0/rubygems.rb:289:in `find_spec_for_exe': Could not find 'bundler' (1.17.1) required by your /app/Gemfile.lock. (Gem::GemNotFoundException)
  :

一旦、別の Rails アプリを作成して Heroku に新しいリポジトリーを追加し、同様にデプロイしたところサーバーの起動まではうまくいった。

この時点で Heroku のダッシュボードを見ると、エラーが発生しているリポジトリーの Settings -> Framework が Node.js になっている。もう一つのリポジトリーを見ると、Settings -> Framework は Ruby,Node.js になっている。

恐らく heroku buildpacks:add --index 1 heroku/nodejs が悪さをしていると思われたため、heroku/ruby も追加したところうまくサーバーの起動まで行った。

アプリケーションエラー

しかし、ブラウザーからアクセスすると、アプリケーションエラーが発生している。ログを参照したところ、下記のエラーが発生している。

  :
2018-12-08T15:52:05.876298+00:00 heroku[web.1]: State changed from starting to crashed
2018-12-08T15:52:05.754921+00:00 app[web.1]: /app/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.6.1/lib/active_record/connection_adapters/connection_specification.rb:188:in `rescue in spec': Specified 'sqlite3' for database adapter, but the gem is not loaded. Add `gem 'sqlite3'` to your Gemfile (and ensure its version is at the minimum required by ActiveRecord). (Gem::LoadError)
  :

「 Rails アプリを初めて Heroku にデプロイして動かなかったときの対処法 」を参考に config/database.yml を書き換えてデプロイしたところ、エラーは解消して、ブラウザーから期待通りの表示がされることが確認できた。

まとめ

Heroku でのビルドの失敗への対応

• Bundler のバージョンを heroku に合わせる。(不要かもしれない)

$ bundle clean --force
$ gem uninstall bundler
$ gem install bundler:1.5.2
$ rm Gemfile.lock
$ bundle install --without production

• config/database.yml の puroduction のデータベースの設定を SQLite3 から PostgresQL に変更する。

$ vi config/database.yml
$ git diff config/database.yml
diff --git a/config/database.yml b/config/database.yml
index 0d02f24..9ea67d8 100644
--- a/config/database.yml
+++ b/config/database.yml
@@ -22,4 +22,6 @@ test:

 production:
   <<: *default
-  database: db/production.sqlite3
+  adapter: postgresql
+  encoding: unicode
+  pool: 5
$

• Heroku のアプリケーションを作り直して、ビルドパックに heroku/nodejs と heroku/ruby を設定する。

$ heroku apps:destroy
$ heroku create
$ heroku buildpacks:add heroku/nodejs
$ heroku buildpacks:add heroku/ruby

• ビルドを実行する。

$ git commit -a -m "retry building on heroku"
$ git push heroku master
$ heroku logs --tail

以上。