サーバーを使ったConoHaを使うと幸せになれるnの理由

はじめに

この記事はConoHa Advent Calenderとして書かれたものである。

Qiitaのみなさん、ConoHa愛好家のみなさん、はじめまして。 コンニチハ、ハルカデス。

Qiitaをよく見ている人ならこのブログをご覧頂いたこともあるかもしれない。 技術的な記事を期待しているかもしれないが、今回はカテゴリからしてもおわかりの通り、ビジネス的なお話である。

ConoHaについて

ConoHaはGMOグループが提供しているVPSサービスである。 以前はVPSではなくレンタルサーバーを名乗っていたような気がするが、最近はVPSだと言っている。

「三雲このは」というマスコットキャラクターで有名なサービスになる。

そのためにサービス自体については軽視されがちなのだが、サービスも特徴的である。

ホスティングサービス, VPS

まず、かなり難しい区分なのだが、web基準で考えると次のような段階がある。

  • 用意されているアプリを使うだけ
  • 用意されているスペースにファイルが配置できる
  • サーバーを操作できる
  • サーバーを構築できる

アプリを使うだけ、というのはブログやECなどの特定の機能を持ったアプリケーションによるサイト公開が可能になっているものだ。 主立ってはamebloやSeeSaaなど、ConoHaと同じGMOグループではGMOペパボのJUGEMや、GMOメディアのYaplogなどがある。

さらに、GMOペパボには「ホームページ作成サービス」系のGoopeもある。 Qiitaもこの形態のひとつであるといえる。

用意されているスペースにファイルが配置できるのは、かつてのGeocitiesが有名で、 これを有料のサービスで行うというのはかつてはひとつの頂点であったとも言える。 最近は減ったがかつては多彩なサービスがあった。 GMOペパボのLolipopはその中でも有名にして定番のものだろう。私も以前は使用していた。また、同社はHetemlという上位サービスも用意している。 GMOインターネットもドメインサービスのお名前.comの一環として提供していたりする。

残る2者はいわゆるroot権限がとれるタイプのものだ。 前者はサーバーの再インストールや、サーバーのOS選択などは基本的にできない。後者はサーバーのインストールや追加なども可能なものだ。

VPS

VPSという語に明確な定義というか、区別はないようだ。 VPSという語が登場した当初のことを考えると、基本的に「rootがとれる従量課金のサーバー」という意味合いであったように思われる。 実際、VPSと名乗るもので、従来のホスティングサービスとの違いが「従量制課金である」ということ以外にあまり明瞭なものがなかったのである。

VPSで当初よりAmazon AWSは非常に強力なサービスであったが、 通信料など外部的要因によって変動する事象によって従量課金となるため、軽い気持ちでサーバーを立てた人が月に数十万円の請求をされる事案も少なくなかった。

そのために、金銭的にかなり余裕があるのでない限りVPSは選択肢にはならなかったのが実情だ。

ConoHaは当初その中間のような存在だったと言える。 VPSのようにいくつものサーバーを立てることができるが、料金はサーバー台数*プランというシンプルなもので、過大な請求がかかることなく安心して使用することができた。

現在のConoHa

当初と比べConoHaは幾分VPSらしくなった。 例えば計算資源からは独立したストレージ容量や、時間従量制などだ。

時間従量制というのは、携帯電話料金のような上限つき従量制と近いものだが、 例えば512MBプランは月額630円で、1時間あたり1.0円。24時間*31日だと744円であるため、それよりも安く収まることになる。

普通は従来型ホスティングサービスが月額制なのだから、現代では珍しい純粋なユーザーメリットによる料金体系である。

このために一時的な用途やテストサーバーなどを含め気軽かつ柔軟にサーバーを用意できることがConoHaの大きな特長である。

ライバル

このようなサービスはあまり類をみないように思うが、最大のライバルはやはりさくらインターネットによる「さくらのVPS」だろう。

このサービスも月額制で複数インスタンスが利用可能だ。 人気はこちらのほうが高く、周囲にも利用者が多い。

クーポンをイベントで配布していた、という点でも類似である。 ただし、ConoHaはクーポン配布はやめてしまったようだ。

お客様のサーバーにConoHaを

私が代表を務めるMimir Yokohamaでは、サーバーを使用するサービスを提供する際には指定がない限りConoHaを使用している。

これは、私がConoHaからコミュニティ支援を受けているという事情もあるが、 別にこれは他サービスの利用を制約するものではない。 ConoHaを使用しているのは、それによってエンジニアとお客様が幸せになるためだ。

サーバーを伴うサービスの展開戦略

自社で使用している巨大なインスタンスにすべて格納する「共有サーバー」スタイルを採用している事業者も多いだろう。

実際のところ、Mimir Yokohamaのお客様のご要望は、サーバー一台用意するのはコスト的に見合わないタイプ(アクセスの少ないウェブサイトなど)と、 共有させるのは難しいタイプ(XMPPサーバーを立てたり、アプリケーションサーバー必要とするケース)が混在している。

ひとつの仮想ホストですべてを賄おうとするのは、管理面を考えてもあまりうれしいことはない。 パフォーマンス低下によってお客様にもストレスをかけてしまうかもしれないし、 セキュリティ的に分離したいケースがあることも普通に考えられるのだ。

つまり、多少アップグレードしてでも複数の環境をホスティングする共有タイプのサーバーを提供してコストを抑えるべきケースと、 性能は控えめでもサーバーを専有すべきケースがある。

これをroot権限があるタイプのレンタルサーバーで行うのは、費用がかさむ上に管理も大変だ。 以前そのようなサービスを提供していたこともあるが(Mimir Yokohamaができるより前の話だ)、正直労力に見合わないものであった。

ConoHaならば仕様の異なる複数のインスタンスを立てることができる。 事業の拡大とともにインスタンスをどんどん増やしていっても構わないのだ。

2GBプランであれば共有webサーバーにも十分耐える。 上手に構成すれば1GBプランでも十分だ。 (分散できるのであれば1GBプランのホストを2つ用意するほうが負荷は厳しくない)

負荷の少ない環境で専有サーバーが必要なケースは512MBプランのインスタンスを使うといいだろう。

性能面

私は個人サイトはDTIのサーバーで運営しているのだが(このブログはまた違う)、速度的にはConoHaにとてもかなわない。 最大の理由は「すべてSSDで提供している」というストレージバックボーンだろう。 Mimir YokohamaのWebプランは可能な限り静的ページとして提供する構造をしている。 そのため、ほとんどストレージ性能と帯域で速度が決まる。「高速なウェブページ」を売りにする以上、インフラが遅いことによる限界というのは悲しいものがある。

もちろん、湯水のようにお金を使えば大幅なパフォーマンスアップも可能なのだが、 「リソースが足りてさえいればコストを抑えても性能が確保できる」というのは非常に嬉しいポイントだ。 仕方なくサーバーを使われるお客様というのは、なるべくなら費用は抑えたいとしつつも、性能はストレスのないものだと信じているものだ。 あまり性能が劣っているとお客様が悲しまれてしまう。

ConoHaは最小の512MBプランを、ちゃんと「多くのリソースは使わない」というだけの理由で選ぶことができるのだ。

以前はConoHaよりもさくらのVPSのほうが安かったのだが、現在は最小プランではほぼ同等の内容でConoHaのほうが少し安い。 1GBプランはConoHaのほうが安いにもかかわらず、SSDの容量はConoHaのほうが大きい。 Mimir Yokohamaは一般のお客様が中心であるため、これらのプランが中心となる。

この「費用の小さいプランでも満足度が高い」ということは、サービスを提供する際の価格設定を抑えられるということにもなる。 サーバー側の金額が安いとあまり大きな利益を載せにくいという面はあるが、安い価格から提供可能なサービスは競争力を向上させるだろう。

イメージ保存機能

サーバーを「凍結したい」という場合や、「移行したい」「サーバーは廃止するがデータは損失したくない」というケースは意外と多い。 サービスを開始する際にサービスを終了することを考えたくない気持ちはわかるのだが、 良いサービスのためには「お客様が気持ちよく完了できること」は不可欠な要素なのだ。

イメージ保存機能はこうしたケースにおいて極めて便利だ。 イメージ保存機能の存在によってお客様に柔軟な終了戦略を提示することができる。

API

ConoHaにはAPIがある。 これはさくらのVPSに対するアドバンテージでもある。

APIを使用することでサーバーの管理を容易にすることができる。

多くのサーバーを展開する場合において手作業の量を減らせば価格設定も抑えることができ、 それは事業の強みとしても活かせるはずだ。

しかも、APIはシンプルなJSONであるため、書くのも簡単。 このような機能をスマートに活用することは、優れたサービスとして欠かせない作法であろう。

カスタムISOからのインストール

重要なのはISOイメージによるインストールが可能なことだ。

Mondo RescueによってシステムバックアップのISOイメージ化か可能であるため、ローカルな仮想環境で練った(アップデートも済ませた)サーバーイメージをテンプレートとして使用することで、スタートアップの時間と労力を減らすことができる。

これは納期を急がれるお客様のご要望にお応えできることに加えて、 コストの大幅な削減にもつながる。

無駄な手間をかけることで価格を釣り上げるような戦略はとるべきではない。 お客様が本当に必要とされているもののためにより多くの労力をかけるべきなのだ。

これは、VPSでなければ難しい(場合によってはVPSですらも難しい)Arch Linuxによるサーバーによって 少ないリソースでもパフォーマンスを発揮するという点でも活用されている。

海外リージョン

今は日本でも海外の顧客を相手にする企業は大変多い。

B2Bサービスを提供する場合、お客様は海外向けにサービスを提供される場合は多いのだ。 実のところ海外とのトランジットが割と少ない日本のサーバーというのは、海外から見るとあまりうれしくない。 どこかの果てにある得体のしれないサーバーであり、実際に応答が遅い。 これは我々が日本からベルギーやデンマークあたりのサーバーにアクセスすれば体験できる事象だ。

私もお客様が海外と商売をされているケースというのは「意外なほど多い」という印象を受けている。 このようなケースにおいてはやはりサーバーも日本ではなく適切な場所に配置したいところだ。

ConoHaにはアメリカとシンガポールという、「適切な場所」としやすい2箇所が用意されている。

このおかげでよりお客様にとってかゆいところに手が届くサービスを展開しやすくなっている。

提灯記事?いやいや…

なんといってもこの記事はConoHaのAdvent Calenderのために書いたものだし、 私がコミュニティ支援を受けているということもあり、PR記事疑惑は拭えないところだろう。

だが、そんなことはない。 なんといっても、特にこの記事作成にあたってConoHaから見返りを得ていないのだ!!!!! (もちろん、見返りをいただけるのなら大歓迎である!!!!!)

実際にMimir Yokohamaのサービスというのは、「ConoHaがある」ということが先にあった。 つまり、Mimir Yokohamaにラインナップされているサーバーを利用するタイプのサービスは、 いずれも私が「ConoHaがあるからこんなこともできる」という発想によって設定したものであり、 ConoHaがなければこれらのサービスは存在しなかった可能性が高い。 実際、ConoHaとの関係がなかった初期にはサーバーを使うサービスというものは非常に限定的であった。

もちろん、ConoHaがなくてさくらのVPSがあるという状況であれば、 いずれそのようなサービスを考えてさくらのVPSを使って展開していた可能性は高いが、 ConoHaを使うことによってお客様にメリットを提供しつつ、 それを事業の強みとして活用することができているのだ。

それどころか、一時期「ConoHaを活用できる」ということは、事業の価値において非常に大きな割合を占めていた。 そのようなVPSの利用があまり一般的でなく、圧倒的に低価格に、かつ柔軟にサービスを構成することが可能だったからだ。

Mimir Yokohamaはお客様の笑顔のために、ConoHaを利用しています。

新品コンピュータを初期状態に戻せるようにバックアップ

これは何

新品コンピュータを購入したときに、完全に元の状態に復元できるようにするものである。

バックアップ手段は色々とあるのだが、もっとも確実かつ完全な手段が「ディスクの完全なクローンを得る」という方法だ。

その方法について紹介しよう。

なお、これは「やや複雑な手段をとっても効率的に、確実に元に戻せる手段を構築したい」という人向けであり、 そのような場合は諦めるという人や、考えたり努力することを回避したいという人は対象としていない。

新品ならでは

新品のコンピュータのディスクは、ファイルをコピーしているわけではない。 データを流し込んで複製しているのだ。

一般的には、先頭からWindowsシステム用の領域が書き込まれ、そして末尾にバックアップ用の領域があるのが一般的である。 バックアップ用の領域はパーティションが切られ、その中に格納されていることもあるし、パーティションレイアウトの末尾の後ろに配置される場合もある。

このため、データが書かれているのは先頭と末尾のみで、中間は全くデータがなく、0が書かれている。

128GBのディスクをフルクローンした場合は当然ながら128GBのファイルが出来上がる。 だがしかし、連続する0のデータは圧縮すると極めて小さくなる。そのため、このようなディスクイメージは圧縮することによって非常にコンパクトにできるのだ。

これが使用していたディスクであればうまくいかない。 データが記録されていない領域も0で埋められているわけではなく、ごちゃごちゃに記録された状態になっているため、フルディスクイメージを圧縮したときに極端に小さくなることはない。 そのため、完全性や確実性が低下してでもなるべくコンパクトな形式でバックアップするのが一般的なアプローチになる。(partimageやntfscloneなどを使うということだ)

書き戻しに関して

次のようにして取得したイメージは

$ dd if=/dev/sda | xz -z -c > /mnt/sda.img.xz

次のようにして書き戻すことができるのだが

$ xz -d -c /mnt/sda.img.xz > /dev/sda

この場合、128GBの「元のディスクに」書き戻すことを前提している。

サイズが違う場合どうなるかというと、ディスクが大きければパーティションがディスク全域ではなく途中で終了し、途中にリカバリー用の領域が置かれた状態になる。 ディスクが小さい場合はパーティションがディスクのサイズよりも大きく設定されてしまう。 この修正はちょっと大変だ(Windows上では難しいかもしれない)。

だが、実際のところリカバリー領域は書き戻しによって復元できているため、なくなってしまっても構わない、と考えられる。 そして、パーティションテーブルはパーティションの内容より前にある。 よって「先頭からデータのある分だけを復元すれば良い」ということになる。

このため、復元したデータは全部書く必要はなく

$ xz -d -c /mnt/sda.img.xz | dd of=/dev/sda bs=1024M count=10

のようにすれば良い(1024MB=1GiBを10回なので10GiB書き込むことになる)。 内容としてはどのみち残りは0なのであり、書いてもかかなくても同じだ。 ディスクサイズが異なる場合はパーティションサイズのみ変更すれば良い。

バックアップの仕方

Linuxで起動する…ところまでは省略しよう。 UnetBootinなどの使用は勧めないが。

まずはpartedでディスクを確認しよう

$ sudo parted -l

これによって各ディスク名(/dev/sdaなど)を得ることができる。 ここではバックアップ対象のディスクはsdaであるとしよう。 異なる場合は読み替えること。

リムーバブルディスクにバックアップ

モダンなLinuxシステムではリムーバブルディスクを接続すれば認識され、ファイルマネージャが起動する。

ファイルマネージャ上でリムーバブルディスクを開き、そこで右クリックから端末(ターミナル)を開く、とする。 そして

$ dd if=/dev/sda bs=64M of=recover.img

のようにする。 もし、圧縮も同時に行うのであれば

$ dd if=/dev/sda bs=64M | xz -z -d > recover.img.xz

のようにする。時間がかかっても圧縮率を上げるのであれば

$ dd if=/dev/sda bs=64M | xz -z -d -e -9 > recover.img.xz

とすれば良い。

なお、NASなどのネットワークドライブ上に保存する場合も似た手順で行うことができる。

ネットワーク上のLinuxホストに対して行う

もう、説明がいるのかどうかも怪しいが、計算機母艦となるLinuxを運用している場合は 受け取る側のLinuxホストではnetcatをインストールしておく。

そしてnetcatで通信を待機する。 次の例ではBSD netcatを使用する。

$ nc -N -l 22500 > recover.img

受け取り側で圧縮する場合は次のようにする。

$ nc -N -l 22500 | xz -z -d -e -9 > recover.img.xz

送り側はncなどはない場合が多いだろうし、ライブブートではインストールも難しい。 しかし、bashにはTCP機能があるため、これを利用する。

$ dd if=/dev/sda bs=64M > /dev/tcp/192.168.1.128/22500

注意点は、bashでなければならないこと、そしてファイルに書けばよいわけではなくリダイレクト機能を使わなければいけないことだ。

悩みに悩んでThinkPad X1 Carbon 2017買いました

はじめに

この記事はThinkPad X1を買ったテンションの高さを活かして書いたものである。

結構悩んでじっくり調べたり検討したりしたので、そこで集積した知識のおすそ分けということになる。 どちらかといえばある程度わかる人向けで、比較が欲しい人向け。

モバイルラップトップでお悩みの方の一助になればと思っている。

購入を決めたわけ

以前はThinkPad e440を使っていたのだが、とにかく重いのと(2.13kg)、ディスプレイの具合がよろしくない。 仕事上、画面を人に見せることが多いため、ディスプレイの乱れはちょっと許容できない。

そこで、おんぼろな中古のDynabook R731を購入したのだが、これも具合がよくない。 キーボードが死にかけている(特にEnterキーはぐりっと押してやらないと入らない)のと、ヒンジが死んでいる。 HDDが死んで退役しかかったが、HDD換装により不死鳥の如く蘇った。 だが、相変わらずおんぼろであった。 キーボードを交換したところでR731の(というかDynabookの)キーボードは苦痛でしかない。

というか、お客様の前でそこまでぼろいラップトップを出すと不安にさせてしまう。

いい加減買い換えないとなぁ、と実に2年ほど考えていたのだ。

候補

候補に上がっていたのは以下

  • Lenovo ThinkPad X1
  • Lenovo ThinkPad A275
  • Lenovo ThinkPad T470s
  • Lenovo ThinkPad X270
  • hp Spectre13
  • hp Envy13
  • hp Elitebook Folio G1

全体的な傾向

ThinkPad

ThinkPadはThinkPadである、というべきかもしれない。

質実剛健で堅牢なつくり、無骨で、ThinkPadに求められるThinkPadらしいこだわりが貫かれている。

残念ながら現在はタッチパッドは常に搭載されているが、それでもトラックポイントは維持されている。独立したボタンと、トラックポイントと組み合わせてスクロール可能なセンターボタン、さらにストロークが深く確かな打ち心地を提供するキーボードなどだ。

キーボードのタッチは独特のものだ。デスクトップでもThinkPadのキーボードを使いたがる人は多い。

hp

まるっこい板と薄さ、そしておしゃれなデザインが特徴だ。

おしゃれラップトップといえばMacBookらしいが、hpはそれに優るとも劣らない。というよりも、Spectre13に関しては絶品だ。

キーボードはキーストロークが短く、固い。 かなり打ちにくいモデルが多いが、SpectreとEnvyに関してはそれなりにミスタッチしづらくなっている。 より固めだからだろうか。

除外理由

ThinkPad X270

Wi-FiはIntelとRealTek混在のようだ。

キーボードがX260とX270で変化した。X270のほうが柔らかくなった。 X260のキーボードのほうが好ましいと思う。 また、右方のキーが小さいのは、多用する私にとってはいまひとつである。

なにより、12.5インチというのは実際に使っていて常に「小さい」と感じるのだが、にも関わらず1.5kg近く携行性が劣るのは残念なところだった。

12.5インチの小ささも気になるし、1.5kgというのは重すぎるため、除外した。バッテリーマイレージも短めだ。 ThinkPadにはキーボードを強く求めているだけに、キーボードが劣るのも受け入れがたかった。

ThinkPad A275

謎の新選択肢A275。 A275自体もそのコンポーネントもとても情報の少ない謎のThinkPadだと言っていい。

ミニマムだと6万円台で購入できる(2017-11-01時点)というのが魅力だが、ミニマム構成だとウェブカメラやフロントバッテリーが含まれない。また、キーボードはバックライトなしだ。 X270のミニマムに近い構成だと7万円弱といったところである。

X270が95000円くらいなのでこの価格差をどう見るかだが、「ものすごく安いわけではないが確かに安い」。

ポップにも不明な点が多く

  • バッテリー容量がX270と異なる記載だが、カスタマイズすると同一だとわかる
  • A275の筐体は樹脂製となっているが、情報としては(マグネシウムフレームの)X270と同一筐体である

さらに、A10-9700Bというプロセッサがまた謎である。2016-10-24リリースのものなのだが、情報がとにかくない。 AMDのサイトのAPUの情報自体はあるが採用例がこれまでなかったのか、ベンチマーク情報は全くない。 「i3くらいじゃないか?」ということのようだが。

X270と比べるとバッテリーのもちが若干悪いようだ。 それ以外に特に目立った欠点はないどころかむしろX270よりも良いかもしれないほどだが、AMDなので実際に運用するとIntelと比べ妙にストレスフルな状況があるかもしれない。

Wi-FiがRealTekだったのが致命的。 LinuxではRealTek製Wi-Fiチップは非常に不安定で、E440でさんざん悩まされていた。

さらに1.5万円ほど安かったら決めていただろう。

ThinkPad T470s

X1とコンセプトが非常に近い、14インチのモバイルラップトップ。 値段的に少し安いのと、メモリモジュールのスロットが1つあるのが魅力だ。

キーボードの打ち心地が少し劣る、少し重い、少しバッテリー持ちが悪い、

T450sのときはバッテリー交換が可能で、メモリモジュールも挿せるということでX1とは明確に異なる価値があったのだが、T460s以降はX1とコンセプトが接近しすぎて「X1の劣化品」という印象が強くなってしまった。

特に1.3kgを越える重量はかなり魅力を減じている。 価格差の小ささもあり、「T470sならX1」という判断が働いた。

Folio G1

X270と比べキーピッチが均一で使いやすいそうに感じられるのだが、誤打率が非常に高い。 あまりにもうすすぎるからだろうか。

価格的にはX270よりも安く、性能的にも文句はない。 堅牢性も高くデザイン性も良い。

12.5インチというサイズは常に小さく感じられる。だが、970gという軽量さと引き換えならば悪くない。 10万円を切る程度という価格設定もとても魅力的だ。

だが、誤打率の高さが生産性と精神衛生にとても響くのは明らかであったため、除外した。

Envy13

Spectreの下のモデルとして追加されたEnvy13。 Envyよりも上のモデルとしてSpectreを追加してEnvyを廃止していたため、ある意味では正しい並びになった。

おしゃれで高級感はあるが、他のメーカーにもありそうな感じ、 MacBookのほうがおしゃれかもしれない。 Spectreの強烈なアピアランスはない。

Homeキーなどが右側に配置された。 このため右端を前提とした手の位置にしているとBSやEnterはとても間違える。 ただし、キー自体はSpectreよりも深めでよく、USB3.1 Type-Aがあるなど良い点もある。

これもかなり致命的なのだが、Spectreのような特別な魅力がないことと、価格的にはRAM 8GBを選択すると 12万円近くとX1とほぼ変わらない値段になるのが致命的だった。 この場合性能はX1にもSpectreにも接近するため、「若干安い分若干見劣りする」という事態になる。

「やすければ考える」という感じのものであったため、除外した。 1.24kgという重量も理由としては大きい。 95000円のモデルが8GBだったら決めていた可能性が高い。

X1 vs Spectre13

デザインはSpectre13のほうが優れていると思う。 hpはFolioにせよEnvyにせよおしゃれではあるのだが、Spectreはとびきりだと言っていい。

また、Spectreは13.3インチ、X1は14.0インチである。 携行性との兼ね合いでは13.3インチのほうが優れていると思う。 ただし、Spectre13は後部に厚みがあるため、13.3インチにしては小さくない。

ThinkPadのスピーカーは決して良いものではない。 スピーカーをウリにするSpectreは(十分にはなりようがないし、意味もないのかもしれないが)良いものである。

Spectre13のインターフェイスはUSB3.1 Type-Cが3つである。 よく3.1が3つも載ったものだと思うが、このいずれに挿しても充電できるというのだから驚く。 だが、Type-Cインターフェイス用のアダプタなどあまり手持ちにあるものではないし(私でもあるほうだと思う)、あまりうれしくない気がする。 付属するアダプタはUSB-Aに対するもののみ。 なお、映像出力はalt modeで行うようだ(Display Port出力)。映像出力用のハブはオプション、全部入りでかなり大きい。 この点においてはX1のほうがはるかに良いだろう。 さすがにRJ-45端子やVGA端子は省かれてしまっているが、USB-RJ45アダプタが標準搭載である。 わずかに追加することでHDMI-VGAアダプタに変更することもできる。

キーボードはSpectreのものはhpの中でも良い。ストロークは短いが確実に入力でき、誤打率は割と低い。 この手の薄いキーボードとしては非常に良いほうだが、さすがにThinkPadのキーボードが相手では分がない。 また、Spectreは薄さもあって結構たわむ。

モニターはSpectreはグレア、X1はノングレアである。 Spectreのモニターは美しいが、業務で使うにはX1のディスプレイのほうがずっと良いだろう。 背部に関してはX1のほうがたわむ。ThinkPadはディスプレイのトラブルが続いているため、この点はかなり気になる部分だった。 hpは圧力負荷テストはかなりやっているようだし。

ポインティングデバイスはSpectreはボタンのないタイプだが、誤動作は少なくトラックパッドとしては 不満もない。くぼんでいて、昔のトラックパッドが進化したもののようだ。 だが、やはりトラックポイントとボタンの組み合わせにはかなわない。トラックパッドはやや邪魔で誤動作もあるが、トラックパッド自体の使い心地は他のものと比べても非常に良い。

重量はほぼ同じだが、hp全モデルに言えることとしてSpectreは重量感がある。 逆に1.14kgとSpectreより若干重いThinkPadは非常に軽く感じる。

価格は今回(2017-11-01)はThinkPadの値引きが強く、同等の構成で1.5万円ほどSpectreが高額であった。 ThinkPadのクーポンが延長保証に対しても効いたのは大きい。 保証についてはThinkPad側には最大4年の延長保証があった。hpは案内がなかったが、あるのかもしれない。

最終的に

最終的には使い方で決めた。

ThinkPadは質実剛健、ハッカーの相棒と言えば一目に納得する「いかついやつ」だ。 ThinkPadには、それを知らない人にも伝わる凄みがある。 ThinkPad、そのフラッグシップたるX1を持つということは、ハッカーとしての自分を表現することを支えることになる。 自信があり、それを裏付ける実力があり、それを発揮するための道具があるという信頼感を示すことになる。

だが、それは、一般の、コンピュータに遠い人にとっては最も遠い位置にあることになる。 ハッカーの持ち物であり、コンピュータの象徴、つまりは「怖いもの代表」だ。

一方、Spectreは美しく洒落ている。 特に女性ならファッションの一部として持ち歩いてもいいと思うのではないだろうか。 街中で見ることはほとんどないので、目も引くだろう。 実際、Spectreを女性に見せた反応は非常に良い。 一般の人にとっては遠く、遠ざけたい世界を身近なものに、IT業界を、そして人とITの関係を変えていくという理念を考えればまさにそれを象徴するようなものだと言えるかもしれない。

だが、それは質実剛健さ、実力といったものを期待する人からすればチャラいように感じられるかもしれない。 私に求められているのは、洒落た伊達男のファッションではなく、確かな実力と誠実さなのだから。

結局は次の要素からX1を選択した。

  • キーボードの入力感の差は非常に大きい。生産性としてもストレスとしても
  • 後部の仕様など、Spectreに若干の無駄を感じる部分があり、あまり好みでなかった
  • Spectreのほうが高かった。性能・機能的にX1が優れていた分、Spectreのほうが1万円くらい安かったらもっと悩んでいた
  • キーボード以外にも本体側剛性、重量バランス、ポートの配置、リッドの強度などThinkPadのほうが実用品として洗練されている
  • Type-C x3というSpectreのインターフェイスに対する不満はかなり強かった。アダプタが色々と用意されていたなら印象はだいぶ違ったが
  • ヒンジ側を握って抱えたときの安定感がX1のほうがずっと高かった。道具として馴染むかどうかというのは大きいと思う
  • LENOVO側に明確に延長サポートがあり、それも比較的安価に提供された
  • hpの販売スタッフの姿勢が消極的で知識も不足しているように感じられた。画一的な回答を返しているだけで、hp愛も感じられなかった
  • ThinkPadのシルバーは全く印象が異なり、ThinkPadに備わっている重苦しさや威圧感がだいぶ和らぎ、スタイリッシュである
  • 信頼できる道具がほしいこと、伊達よりも誠実こそが私の武器であること、私のライフスタイルから言ってもSpectreと私が馴染まない気がしたこと

Spectreのデザイン性はモチベーションを大きく上げるが、全体にSpectreには「微妙だな」と思う部分が多かった。 そのもやもやが覆されることがなかった、というのがSpectreを選ばなかった理由だ。 X1もSpectreも非常に魅力的だという前提があるため、選ばないという選択がなされれば他方は選ぶという選択がなされることとなった。

ハッカー御用達のタイプの近いモデルでの比較。

項目 LENOVO ThinkPad X1 Performance hp Spectre13 Standard Dell XPS13 Standard
CPU Core i5-7200U Core i5-7200U Core i5-8250U
RAM 8GB LPDDR3 8GB LPDDR3 8GB LPDDR3
Display 14" FHD IPS non-glare 13.3" FHD IPS glare 13.3" FHD AG
Storage 128GB SATA M.2 SSD 256GB PCIe NVMe M.2 SSD 256GB PCIe SSD
Wireless Intel AC8265, BT4.1 Intel AC8260, BT4.2 Killer1535, BT4.1
Ports 2x Thunderbolt3, 2x USB3.0-A, HDMI, microSD, microSIM USB3.1-C, 2x Thunderbolt3 (alt), headset 2x USB3.0 A (1 PowerShare), SD(SD/SDHC/SDXC), headset, Noble lock, Thunderbolt3 (alt)
Webcam 720p/Mic HD TrueVision WebCam / DualMic WideScreen 720pWebcam DualArray mic
Speaker Stereo Bang&Olufsen Stereo Speaker Waves MaxxAudio 1Wx2
battery 3cell 57Wh, 15.3h 4Cell, 10h 60Wh, 18h
Weight 1.13kg 1.11kg 1.20kg
Charger 240g 45W USB-C, 2.4h 200g 45W USB-C 45W USB-C
Price 124,654 140,184 123,233
  • X1は自動適用のJPWE1105クーポン込み、XPS13は15%オフクーポン込み
  • X1はQHD(2550×1440), XPS13はQHD(3200×1800)液晶が選択可能
  • X1はUSB3.0 Type-A GbEアダプタが、SpectreはThunderbolt USB Type-Aアダプタが付属
  • XPSの駆動時間はスペックシートに記載がないため真偽不明

コメント

  • DellはKabyLake-Rプロセッサモデルが選べる。下位モデルはKabyLakeで、こっちの安さはかなりの武器
    • ちなみに、「第8世代」と呼ばれているKabyLake-R(8000番台)、ほとんどKabyLake(7000番台)と変化なしということでその呼び方が相当不評
  • 16GBを積む選択肢があるX1とXPSと違い、Spectreは8GB固定
  • スピーカーに無頓着なのはThinkPadの伝統。とはいえ、ラップトップの付属スピーカーにこだわる?
  • USB Type-CしかないSpectreの使い勝手がかなり気になる
  • すべてType-C給電。これからのスタンダードなのかもしれない
  • さすがにスペック自体は似通っている
  • X1のQHD選択可能はトピックスだけれども、XPSのQHDはそれを上回る。ただ少し特殊なドット数。
    • ディスプレイ自体、Dellが美しい
    • ディスプレイに関していえば、Spectreは綺麗ではあるけどグレアパネルで映り込みが激しく、作業上は不便
  • XPSのベゼルは極度に薄く、そのためサイズ的には13.3インチとは思えないほど小さい
    • ただ、この都合でXPSはウェブカメラが液晶の下側にある。個人的な意見としては、こっちのほうがいい
  • SpactreもXPSも決して打ちやすいキーボードとは言えない。キーボードは圧勝
  • また、この両者はタッチパッドも全くへこまない、ボタンもないものなので、ThinkPadが使いやすい
  • 比較した時、14インチが欲しいならX1一択
    • 14インチで13.3インチと同等の重量とはやはりすごい

国産の高性能モバイルとの比較。

項目 LENOVO ThinkPad X1 (Customized) Panasonic LX6 CF-LX6XDQQP NEC Hybrid-Zero (Customized)
CPU Core i7-7500U Core i7-7600U Core i7-7500U
RAM 16GB LPDDR3 16GB 8GB
Display 14" QHD IPS non-glare 14" TFT FHD Anti-glare 13.3" LED IPS FHD Non-glare, touch
Storage 256GB PCIe NVMe M.2 SSD 256GB SATA SSD 256GB SATA SSD
Wireless Intel AC8265, BT4.1 Intel AC8265, BT4.1 ac/a/b/g/n, BT4.1
Ports 2x Thunderbolt3, 2x USB3.0-A, HDMI, microSD, microSIM BD/DVD Super multi, 3x USB3.0-A, RJ-45(GbE), Mic, Headphone, HDMI, VGA USB3.1-A, USB3.0-A, HDMI, Mic, Headset, SD(SDHC/SDXC)
WebCam HD/Mic FHD/Array Mic HD / Stereo Mic
Speaker Stereo Stereo YAMAHA AudioEngine Stereo 1W+1W
Battery 3cell 57Wh, 15.3h 10.8V/3400mAh, 9.5h 10.0h
Warranty 3年 3年 3年
Weight 1.13kg 1.295kg 813g
Charger 240g 45W USB-C, 2.4h 220g 45W, 3h 192g, 3.5h
Price 170,532 274,228 189,300
  • X1は自動適用のJPWE1105クーポン込み

コメント

  • 14インチモバイルのライバルは実質Let’s Noteのみ
  • Let’s NoteはSバッテリーで1.295kg、Lバッテリーで1.495kg。14インチってそれくらいはする
    • Sバッテリーで9.5hと多分こちらが本命。Lバッテリーは16hとかなり駆動時間が長い
    • ちなみに、Let’s Noteはバッテリーパックが交換可能で、S+Lのセットもあったりする
    • しかしThinkPadはType-Cなので、Dell電源コンパニオンをはじめPDなUSB-Cバッテリーで充電できたりする。RAVPower RP-PB058とか良いみたい
  • Let’s Note全般に言えることだけれども、とても高い。これでもこのモデルは安い方(!)
  • Let’s Noteは全体的にレガシィなインターフェイスを維持している。これは実用上大変にありがたい
  • ThinkPadがハッカー向けの先進性なのに対して、Let’s Noteはさらに質実剛健で実用志向
  • Hydbrid-Zeroはこのモデルでも813gと非常に軽い。タッチ対応の2in1なのでモデルタイプがだいぶ違う
    • だが、実際ラップトップとして使っても決して劣らない性能を持っているところが恐ろしい
    • 13.3インチ。13.3インチのほうが激戦だからか、なにやらすごいモデルが多い
  • 残念ながらHydrid-ZeroはRAMは8GBまで。16GBは積めない
  • LX6は7500U搭載モデルが比較的少ない
    • LX6はカスタマイズできないけれどラインナップが異様なまでに豊富
    • オーダー自転車を扱うPanasonicらしいとも言えるかもしれない
    • X1で7600Uを選択することもできるけれど、性能差は1割未満。2万円近い値段差はほぼ報われない
  • 興味深いのがHybrid-Zeroがマイク端子(3.5mm 3極)とヘッドセット端子(3.5mm 4極)を持っていること。そのため、2プラグ型のSkypeマイクも、1プラグ型のヘッドセットも両方使える
  • 極限まで高性能化するThinkPad, 高性能パーツを使っているけれどそれ以上に高いLet’s Note, 性能高めのパーツ選択のHybrid-Zero
  • こうして見ると改めて14インチのライバルの少なさをとても感じる
    • 以前はXPS14なんてのもあったのだけれど…

検討に上がらなかったLenovo勢との比較

項目 LENOVO ThinkPad X1 Performance LENOVO ThinkPad 13 Standard LENOVO ideapad 720S Platinum
CPU Core i5-7200U Core i3-7100U Core i5-7200U
RAM 8GB LPDDR3 4GB DDR4 8GB DDR4
Display 14" FHD IPS non-glare 13.3" HD IPS non-glare 13.3" FHD non-glare
Storage 128GB SATA M.2 SSD 128GB SATA M.2 SSD 256GB PCIe NVMe M.2 SSD
Wireless Intel AC8265, BT4.1 Intel AC8265, BT4.1 Intel AC3165, BT4.1
Ports 2x Thunderbolt3, 2x USB3.0-A, HDMI, microSD, microSIM 2xUSB3.0, Powered USB3.0, USB Type-C (DC-in/Video out), HDMI, Headset, Lenovo OneLink+, DC Power, 4in1(SD/SDHC/SDXC/MMC) Media Reader USB3.0 Type-C(PD), Thunderbolt3(alt:DP, PD), 2xUSB3.0, Headset
Webcam 720p/Mic 720p/Mic WideScreen 720pWebcam DigitalArray mic
Speaker Stereo Stereo JBL Stereo
battery 3cell 57Wh, 15.3h 3cell, 13.6h 4cell, 12.8h
Weight 1.13kg 1.44kg 1.14kg
Charger 240g 45W USB-C, 2.4h 240g Lenovo DC, 2.3h 45W 200g USB-C, 3h
Price 124,654 64,152 87,048
  • ThinkPad13はメモリがスロット式である上にスロット数が2。古き良き柔軟仕様
    • このため、メモリ容量が少ないモデルに選択の余地があるので安く上がる
  • ideapadの方はThinkPadとは全く異なる、ごく今風で普通のモデル
    • キーボードはDellのものに近い。スピーカーにもこだわっていて、ライバルに近いもの
    • SSDはNVMeだし、メモリはオンボード。このあたりも最新のモバイルラップトップの仕様
  • ThinkPad13はエントリーモデルのような構成ではある
    • Xシリーズと違って樹脂ボディ。キーボードも光らない
    • しかし、メモリの交換が効くなど悪いことばかりではない
    • +9,720でFHD液晶が、+1080円でバックライト付キーボードが選べる
    • つまりX270よりも少し安い程度
    • 実は液晶やキーボードも選べるし、付属してないだけでUSB-Cでの充電もできる
  • ThinkPad13のオーダーモデルは納期が3-4週間と結構遅い
  • ThinkPad13は結構キラーモデルだと思う
  • 720Sのほうはライバルよりもちょっと安くて、同等性能のThinkPadの2/3くらいのお値段とかなり魅力的
    • ただし、ThinkPadの良さはなく、キーボードやタッチパッドなども異なる完全に別物
    • 別物だということを受け入れた上でなら実はとても良い選択肢。ライバルと比べても売れてないみたいだけど

ThinkPad X1の紹介

ThinkPad X1 Carbonについて改めて紹介しておこう。

ThinkPadは、かつてはIBMで販売されていたラップトップだ。 1992年に誕生した、A4サイズのラップトップ。

仕事に使える、持ち出せるコンピュータであり、先進的な、コンピュータメーカーの巨人であったIBMの矜持を詰め込んだラップトップだった。

堅牢性にこだわり、実用性にこだわり、キーボードにこだわった。 ThinkPadはあくまで「仕事をするための道具」だった。 21世紀が近づき、ラップトップも「おしゃれ」に化粧をはじめてもその質実剛健を実直に貫く姿勢から、信頼できる丈夫な道具を求めるハッカーやジャーナリストに愛された。

IBMのキャッチフレーズは“Think Different”だった。 日本IBMのボールペンには「考えよ」と書かれていた。

2005年にIBMのパソコン部門はLENOVOに売却され、ThinkPadもLENOVOから出ていますが、ThinkPadは今もThinkPadです。

「ビジネス」というと質素で退屈なイメージがある。その意味でThinkPadはビジネスという言葉とは若干ズレがある。 ThinkPadはハッカーや、優れたエンジニアが持っているととても様になる。 それを使いこなすことができる達人の道具、という趣がある。

ThinkPadにはThinkPadの哲学がある。 非常に強いこだわり、独自性があるのだ。 あくまでストロークが確保されたキーボード、「赤いポッチ」ことトラックポイントもその一部。 無骨なデザインも、ピースチキンと呼ばれる黒い塗装もその一部だ。

そのため、ThinkPadには熱狂的なファンが多い。 Mac勢(Appleファン)というのは基本的に熱狂的で偏屈なものだ。 だから、Apple製品を批判すると噛み付かれやすい。 それと比べWindowsユーザーを批判してもそうはなりにくい。広汎すぎるという理由もあるが。

だが、そんなWindowsユーザーの中で、熱狂的で強いこだわりをもっているのがThinkPadユーザーだ。 ThinkPadファンに対してケンカを売るのはあまり得策ではない。 こだわりがあり、能力があり、知識もあるThinkPadファンは、浅薄なディスりを受ければ相手を完膚無きまでに打ちのめすだろう。

黒の中に浮かぶ赤いぽっち。 まさにThinkPadらしさだ。

そんなThinkPadの、現代の頂点に立つのがX1だ。 2011年に登場したX1は、伝統的ThinkPadの継承である“Classic”ラインでありながら、薄型軽量で、最もスタイリッシュなモデルと位置づけられた。 2012年にはThinkPad X1 Carbonとなり、ThinkPadの頂点に立つモデルとして位置づけられてきた。

さらにコンバーチブルモデルのThinkPad YogaがThinkPad X1 Yogaとして合流している。

実際のところ、hpやDell、あるいはショップのプライベートブランドでも言えることだが、余計なソフトも入っておらず、基本的に使い方の分かっている人が買うものであり、ユーザー層もレベルが高い。 LENOVOにはLENOVOのPCもあるため、ThinkPadへの「無知なユーザー」の誘致はあまり積極的ではなく、「初心者お断り」な空気もあるにはある。

実際、生産性から言っても1から10まで教えてほしい人が購入するには向いていないだろう。

ThinkPad X1 Carbon 2017の紹介

ThinkPad X1 Carbonは14インチのラップトップだ。

14インチというのは、持ち歩きはあまり多くないことを想定した15.6インチと、持ち歩きだけを重視した12.1インチの間にある。 同じくそれらの中間である13.3インチが携行性を重視しているのに対して、14インチは性能や作業効率を重視しながら持ち歩きも考慮している、といった趣だ。

あまりこれらのサイズを取り揃えるメーカーというのはなく、特に14.0も13.3もあるメーカーというのは珍しい。実際、ThinkPadには13.3インチのモデルはない。

現行の14インチのラップトップは1.5kg前後のものが多い。 ちなみに、ThinkPadの14インチでエントリーモデルのE470に関しては1.9kgほどある。

ところがX1 Carbonは「14インチながら非常に軽い」というのが特徴だ。 方向性がかなり接近しているT470sが1.37kg、「軽い14インチ」として先鞭をつけたPanasonicのLX6が1.275kgであるのに対して、1.14kgとかなり軽い。これは13.3インチのhp Spectre13の1.11kgとほぼ同等だ。

しかも電池持ちが良い。 電池は容量と重量が比例するため、軽くするとバッテリー容量が減る。そうすると駆動時間が減ることになる。 そのため、小型軽量のモバイルPCは、意外と電池持ちがよくない。 それでもバッテリーをもたせるためにはCore MやAtomのような超低消費電力プロセッサを採用して性能を落として電気を使わないようにするのだが、X1はラップトップとしてトップクラスの高性能を兼ね備えている。 だが、電池持ちは14時間と非常に良い。

そしてCarbonの名の通り、カーボンファイバーを駆使して軽量だが堅牢なシェルを作っている。 フレームはマグネシウム合金製で、一眼レフカメラのようだ。

「大きめの画面ながらかなり軽くて丈夫で、とっても高性能で、電池もちもいい」 X1を簡単に言い表すとそういうことになる。

だが、それだけではライバルは多い。13.3インチ勢なら1kg前後というものもあるし、12インチまで落とすとLavie Hybrid Zeroに関しては779gと超軽量だ。 なかなかここまでバランスのとれたライバルはいないが、Envy13やSpectre13、XPS13などは強力なライバルとなるだろう。

だが、これら加えて極上のタイピングを提供してくれるキーボードがある。 慣れない人には使いにくいかもしれないが、トラックポイントも魅力的だ。

完璧じゃないかって? そう完璧だ。ここまで全方位にバランスの取れたラップトップは珍しい。 そうなると「すごく高い」という欠点があるのじゃないかと思うかもしれないが、国産モデル(NEC, Panasonic, Toshiba, Fujitsu, VAIOのことだ)を選択肢に考えられる人ならば、むしろとても安いことに驚くだろう。 最高性能を求めると結構高価になるが、それでも国産勢の高性能モデルとはだいぶ開きがある。

しかし欠点がないわけではない。 特に「普通の人」にとっては。

「おしゃれさ」優先の人には向かないだろう。 Let’s Noteとはまた違った意味で至って質実剛健、おしゃれさなど最初から求めていないし、そもそも色が黒しかない。今回X1にシルバーがあるのは、かなり驚きだ。

また、国産ラップトップのように、色々なソフトが詰め込まれているわけではない。 オプションでMS Officeはあるが、買ったらすぐはがき作成ソフトやDVD作成ソフトなど色々と入っていて欲しい人には向いていない。

「普通ではない」人に向けた話もしよう。

とにかく薄く、軽くしなければならないため、薄型ラップトップでは既に主流になっているが、組み込みになっているものが多い。 例えばバッテリーの自力交換はできないし、メモリは基盤実装であり増設も交換もできない。 SSDはM.2で交換は可能だが、普通のHDDが入れられるような構造ではない。 キーボードが部品として出ておらず、基盤も全部はずした上にパネルごと交換、というと驚くかもしれない。

つまり、X1を後からいじるのは難しい。基本的にメーカーに頼る必要がある。 しかも構成変更のようなことはほぼほぼできない。 ハードウェア的には、X1は渡された時点で完成品なのだ。

お勧めできるか

X1は「妥協なき高性能を持ち歩く」ことが中心にある。

持ち歩かない人にはあまりオススメできない。

それなりに扱いにくいハードウェア構成をしていて、改修ができない、修理代が高いという欠点がある。 あまり持ち歩かないのであればX1の良さを活かしきれない。 お金がありあまっているのならなくもない選択肢だが。

それにしても「持ち歩くための高性能」だと考えるべきだし、携行するときもあるけれど、携行重視ではないのならThinkPad T470sという選択肢がいいと思う。

そして13.3インチがいいか、14インチがいいか、という話になる。 13.3インチは他の人に画面を見せるときにはちょっと小さい。また、動画などを見る時には小ささを感じる。 それと比べ14インチは大きい。ただ、「モバイルとしては大きすぎる」と感じる程度に大きい。 14インチに価値を認めるならX1かLet’s Note、13.3インチがいいならその他ライバル勢ということになる。

しかし13.3インチが良いという場合でもThinkPadの素晴らしいキーボードがそれを上回る魅力を見せるかもしれない。 12.5インチのZ270は意外にも1.5kg近い。 重量が増加してもサイズが増加することを避けるのか、重量の増加を避け大型化を受け入れるのかという選択になるだろう。

ThinkPadの性能は選択によってアッパーミドルからハイエンドといったところ、 軽量、頑丈、大型ディスプレイなど隙がない。 モバイルラップトップとしては最高性能に近い。このため、次のような動機の人にならオススメできる。

  • 高性能で携行性の高いラップトップが欲しい
  • 携行性の高い、しかし画面の大きいラップトップが欲しい
  • キーボードがいいラップトップが欲しい

携行性はいらず、高性能なものが欲しい場合は、ThinkPad P51を検討するといい。 携行性はそこまで重視せず、高性能なものが欲しい場合はThinkPad T470sを検討するといい。

携行性をそれほど求めず、画面が大きいものを望むのなら、 ThinkPad T470sのほか、XPS15も良い選択肢だ。 携行性を重視し、画面サイズは小さくていいのなら、Spectre13やXPS13、Hybrid-Zeroなどが有力な選択肢だ。

Let’s Noteは常に強力なライバルである。ただし、高い。

キーボードを望むならThinkPadしかないが、次のような選択肢幅がある

  • やや重いがより小型で安価 : X270, A275
  • やや重いがやや安価 : T470s
  • 同サイズで携行性・性能は妥協、安価 : E470
  • 大きめサイズで携行性は妥協、安価 : E570, E575
  • 重量は重いがより高性能 : P51

ちなみに、実際にタイプすると他のシリーズとは若干だが感触が違う。 個人的にはX1, T470s, P51/s, その他の順だ。

理系でも文系でも2時間で書けるようになるMarkdown講座

「Markdown書きたいけど難しい」と言われる方がちらほらおられるので優しくお教えしよう。

Markdownとは

普通のテキストなんだけれど、強調したり箇条書きしたりできる。

さらに、ウェブ表示用とか印刷用とかに変換したりもできる。 主には変換するために使うのだけれど、ウェブサービスではそのままMarkdownで書いたら勝手に変換していい感じにしてくれたりもするものもある。

Markdownは「見た目」を決めるものではない。 だから、華やかなチラシを書いたりするためのものではない。 意味を持った文章を書くためのものだ。 論文やレポートや記事や本を書くのに適している。

必要なもの

とりあえずコンピュータ。

あとは特別なものはいらない。 テキストエディタで書く。 Windowsならばメモ帳でいいし、LinuxならGeditでもPlumaでもKwriteでもMousepadでもVimでも良い。

ただ、できればWindowsならば良いテキストエディタを入手することをおすすめしたい。 高機能なのはAtom、複雑なのは苦手ならMarkdownPadあたりでどうだろう。

基本的な機能

Markdownには様々な事情や拡張や機能があるが、 それを覚えなければ書けないわけではない。

基本的には

  • 段落
  • 強調
  • 箇条書き
  • 章立て

があれば十分機能的に記述できるだろう。

段落

段落というのは、文のまとまりだ。

ウェブページ上では行間が広くとられて空行があるように見える(一般的には)。

日本語の文章では、改行して、書き出しを一文字下げるアレだ。

Markdownは「見た目」ではなく、意味を定義する。 だから、段落によって「ひとまとまりの文が終わって次の文のまとまりになる」ことを示す。

Markdownで改行することはできないことはないが、基本的には使用しない。 「行を変える」という見た目ではなく、「ひとまとまり」を示す段落を使おう。

段落を示すには「空行を開ける」。次のようにだ。

段落1

段落2

改行は単なるスペースだとみなされる。 だから、次の例

段落1
段落1

段落2

は次と同じ意味になる。

段落1 段落1

段落2

だから、次のように書けばいい。

吾輩は猫である。
名前はまだない。

ところで君。
月が綺麗ですね。

強調

書いていると、特に重要な部分があったりする。

声を大にして言いたいようなことだ。

強調をするには強調したい部分を*で囲む。

あなたのことが*好き*です。

もっと強調したい場合は**で囲む。

あなたのことが*好き*です。**愛して**います。

なお、気にしなくても良いが、*で囲む場合は文を囲ってもよいのだが、 **は単語を囲むことになっている。 日本語の場合は単語を囲むのは難しいので、文節を囲むことになると思うが。

箇条書き

箇条書きもよく使うだろう。 箇条書きをするには行頭に*を書いてスペースを開ける。 前後の段落はあけなくてはならない。

今日のご飯は

* カツ丼
* 秋刀魚丼
* ご飯ドーン

番号つきで箇条書きしたい場合は、数字の後に.をつけてスペースをあける。 数字は1, 2…と書かなくて良い。 変換するときに勝手に番号が振られる。

あなたがするべきこと

0. 私のTwitterページにアクセスします
0. 「フォロー」と書かれたボタンをクリックします
0. 愛の告白をします

他にも書き方はあるが、一種類覚えれば書けるだろう。

章立て

長い文章は1章, 2章, 1節, 2節と分けたほうが見やすいだろう。 この記事もそのように書かれている。

章立てを行うには、先頭に#を並べた上でスペースをあけて、見出しを書く。 #の数が多いほど細かな分け方になる。

# 第一章

## 第一章第一節

## 第一章第二節

# 第二章

## 第二章第一節

### 第二章第一節第一項

### 第二章第一節第二項

先頭にまとめて書くわけではなく、章や節が切り替わるところで書く。

キャンセル

例えば*のような文字は特別な意味に取られてしまう。 そのようなことを避けて、「単に*という文字を書きたい」という場合には、 特別な意味にとられてしまう文字の前に\と書いて\*のようにする。

もうちょっと書きたい

コード類の記述はプログラムを書く人しか使わないし、 そのような人はMarkdownのリファレンスを読むなどたやすいだろうから、 それ以外のものを少し。

リンク

クリックして他のページに飛ぶことができるリンクを表現するには

[タイトル](アドレス)

とする。 つまり

[Chienomiブログ](http://chienomi.reasonset.net/)

のようにだ。

画像

Markdownで画像を表現するには

![タイトル](アドレス)

と書く。アドレスなので、基本的にインターネット上にあるものを書くことになるだろう。 印刷用に変換する場合はローカルで必要となり、画像を扱う場合は出力先のことを意識して書くことになる

次のように書く

![誰かのアイコン](http://example.com/img/icon.png)

変換する

PandocとかKramdownとかとても便利なのだが、 だいたいエディタにはエクスポート機能があるので、とりあえずそれを使えば良い。

AtomであればCtrl+Shift+Mでプレビューを開き、プレビューウィンドウ上で右クリックしてSave As HTMLを選択すれば良い。

おまけ: この記事のMarkdownは

この記事はMarkdownで書かれている。

---
title: 理系でも文系でも2時間で書けるようになるMarkdown講座
cats: [ digi.it ]
tags: [ markdown, howto ]
---

「Markdown書きたいけど難しい」と言われる方がちらほらおられるので優しくお教えしよう。

## Markdownとは

普通のテキストなんだけれど、強調したり箇条書きしたりできる。

さらに、ウェブ表示用とか印刷用とかに変換したりもできる。
主には変換するために使うのだけれど、ウェブサービスではそのままMarkdownで書いたら勝手に変換していい感じにしてくれたりもするものもある。

Markdownは「見た目」を決めるものではない。
だから、華やかなチラシを書いたりするためのものではない。
意味を持った文章を書くためのものだ。
論文やレポートや記事や本を書くのに適している。

## 必要なもの

とりあえずコンピュータ。

あとは特別なものはいらない。
テキストエディタで書く。
Windowsならばメモ帳でいいし、LinuxならGeditでもPlumaでもKwriteでもMousepadでもVimでも良い。

ただ、できればWindowsならば良いテキストエディタを入手することをおすすめしたい。
高機能なのはAtom、複雑なのは苦手ならMarkdownPadあたりでどうだろう。

## 基本的な機能

Markdownには様々な事情や拡張や機能があるが、
それを覚えなければ書けないわけではない。

基本的には

* 段落
* 強調
* 箇条書き
* 章立て

があれば十分機能的に記述できるだろう。

### 段落

段落というのは、文のまとまりだ。

ウェブページ上では行間が広くとられて空行があるように見える(一般的には)。

日本語の文章では、改行して、書き出しを一文字下げるアレだ。

Markdownは「見た目」ではなく、意味を定義する。
だから、段落によって「ひとまとまりの文が終わって次の文のまとまりになる」ことを示す。

Markdownで改行することはできないことはないが、基本的には使用しない。
「行を変える」という見た目ではなく、「ひとまとまり」を示す段落を使おう。

段落を示すには「空行を開ける」。次のようにだ。

```markdown
段落1

段落2
```

改行は単なるスペースだとみなされる。
だから、次の例

```markdown
段落1
段落1

段落2
```

は次と同じ意味になる。

```markdown
段落1 段落1

段落2
```

だから、次のように書けばいい。

```
吾輩は猫である。
名前はまだない。

ところで君。
月が綺麗ですね。
```

### 強調

書いていると、*特に*重要な部分があったりする。

**声を大にして**言いたいようなことだ。

*強調*をするには強調したい部分を`*`で囲む。

```markdown
あなたのことが*好き*です。
```

もっと強調したい場合は`**`で囲む。

```markdown
あなたのことが*好き*です。**愛して**います。
```

なお、気にしなくても良いが、`*`で囲む場合は文を囲ってもよいのだが、
`**`は単語を囲むことになっている。
日本語の場合は単語を囲むのは難しいので、文節を囲むことになると思うが。

### 箇条書き

箇条書きもよく使うだろう。
箇条書きをするには行頭に`*`を書いてスペースを開ける。
前後の段落はあけなくてはならない。

```markdown
今日のご飯は

* カツ丼
* 秋刀魚丼
* ご飯ドーン
```

番号つきで箇条書きしたい場合は、数字の後に`.`をつけてスペースをあける。
数字は`1`, `2`...と書かなくて良い。
変換するときに勝手に番号が振られる。

```markdown
あなたがするべきこと

0. 私のTwitterページにアクセスします
0. 「フォロー」と書かれたボタンをクリックします
0. 愛の告白をします
```

他にも書き方はあるが、一種類覚えれば書けるだろう。

### 章立て

長い文章は1章, 2章, 1節, 2節と分けたほうが見やすいだろう。
この記事もそのように書かれている。

章立てを行うには、先頭に`#`を並べた上でスペースをあけて、見出しを書く。
`#`の数が多いほど細かな分け方になる。

```markdown
# 第一章

## 第一章第一節

## 第一章第二節

# 第二章

## 第二章第一節

### 第二章第一節第一項

### 第二章第一節第二項
```

先頭にまとめて書くわけではなく、章や節が切り替わるところで書く。

### キャンセル

例えば`*`のような文字は特別な意味に取られてしまう。
そのようなことを避けて、「単に*という文字を書きたい」という場合には、
特別な意味にとられてしまう文字の前に`\`と書いて`\*`のようにする。

## もうちょっと書きたい

コード類の記述はプログラムを書く人しか使わないし、
そのような人はMarkdownのリファレンスを読むなどたやすいだろうから、
それ以外のものを少し。

### リンク

クリックして他のページに飛ぶことができるリンクを表現するには

```markdown
[タイトル](アドレス)
```

とする。
つまり

```markdown
[Chienomiブログ](http://chienomi.reasonset.net/)
```

のようにだ。

### 画像

Markdownで画像を表現するには

```markdown
![タイトル](アドレス)
```

と書く。アドレスなので、基本的にインターネット上にあるものを書くことになるだろう。
印刷用に変換する場合はローカルで必要となり、*画像を扱う場合は出力先のことを意識して書くことになる*。

次のように書く

```markdown
![誰かのアイコン](http://example.com/img/icon.png)
```

## 変換する

PandocとかKramdownとかとても便利なのだが、
だいたいエディタにはエクスポート機能があるので、とりあえずそれを使えば良い。

Atomであれば`Ctrl+Shift+M`でプレビューを開き、プレビューウィンドウ上で右クリックして`Save As HTML`を選択すれば良い。

Markdownにまつわるお話

ことの起こり

なんだか急にMarkdown関連のことが盛り上がってきた。

Commonmark絡みなのかもしれないけれど、ちょっと私にも言いたいこともある。

Takeshi KOMIYA‏さんによるツイートその1

Markdown は記法に限りがあるというシンプルさが強みであり、弱みだよね。表がないのが非常に不満だけど、それ以外は大体これで十分だよね。それ以降、いろんな人がいくつも派生記法を作っているけれど、どれも方言の域を出ていない。脚注や参照はなくても生きていけるんだ。

その2

もちろん、それで満足が行かない人たちがいるのは知っているし、ある用途 (執筆やら巨大なリファレンスの管理とか) では不十分なのは分かるけど、それは特別なユースケースであって、Markdown のそれから外れているだけなんだよね。そういう人たちは別のものを使う方が幸せになれる

へぇ、テーブルってMarkdownの標準じゃなかったんだぁ…というのはおいといて、私が言いたいのはこんな感じ。

少なくとも私はPandocのMarkdownに9割は満足している。 Kramdownでも良い

そして、Markdownの優れているところは単にシンプルたからではない。DocbookやPODやroffやtrfやXMLのようなドキュメントメタフォーマットと比べても多くの人に取って受け入れやすく、だからこそメタフォーマットとして非常によく機能することだ。

私には自分で作ったPureDocがある。けれど、Markdownのほうがよく使う。そのほうか変換の余地が大きく汎用性が高い。つまりはドキュメントメタフォーマットとして優れているのだ。 そして、Markdownは処理系依存でもそれほど困らないが、PureDocは他に処理系はない。

Markdownの拡張が気に食わない、そんな人はMarkdownでないものを使え、というなら、拡張されたMarkdownはMarkdownではない別のフォーマットだと思えばいいではないか。Markdownを名乗らなければいいのか?それとも、似た記法を使うなんてけしからんということか?

MarkdownはHTMLを含めることすら許しているんだ。足りなければ自分で拡張したっていいんだよ。好きなものを使えばいいさ。強制することなんかない。

そんなくだらないことで言い争わないで、空を見てご覧よ。今日は満月。天使が降りてきそうな素敵な星空だよ。こんなに月が明るいのに2等星までよくみえる。

ドキュメントメタフォーマット

とりあえず紹介

ブログに書くのだからもう少し補足しよう。

ドキュメントメタフォーマットというのは、なにか別の文書形式に変換することを前提としたドキュメント形式のことである。

例えばPODはそれ自体が読みやすいテキストではあるが、「意味付け」ということはできても、それがplain textの状態で「フォーマットすることで意味付けを感じられる」というようなものではない。 PODはトランスレータと呼ばれるソフトウェアに通すことを前提としており、これにより様々な形式に変換する。 対応形式はplain, man, html, latexが標準で付属し、そのほかにも様々な形式に変換可能だ。 Perl cookbookはPODで書かれているという。

RDocも似たようなもので、こっちはもっと「Wiki」っぽい。 こちらはriと呼ばれるtexinfo形式を標準としているが、HTMLにも変換できる。

Wiki記法、はてな記法はマークアップ形式だが、あくまでもHTMLに変換することを前提としている。 HTMLよりも楽に書けるとことがその価値であり、「HTMLの簡易記法」であるといえる。

plain2, reStructuredText, Re:view, AsciiDocはMarkdownに近いものだ。 plain2はLaTeXへの変換に限られているが、ReStructuredTextはSphinxを介して

  • HTML
  • LaTeX
  • ePub
  • Texinfo
  • man
  • plain

に変換することができ、Re:viewは

  • EPUB
  • PDF (LaTeX)
  • InDesign (IDGXML)
  • Markdown
  • plain text (TOPBuilder Text Markup Language)

asciidocは、(公式プロセッサではなく)asciidoctorが

  • HTML (HTML5)
  • XHTML (XHTML5)
  • DocBook (DocBook5, DocBook 4.5)
  • manpage
  • PDF
  • ePub 3
  • LaTeX
  • Mallard

に変換する。

これらのフォーマットは「そのフォーマットをplain textとして書いて、他の形式に変換する」ことを前提としているのだ。

ちなみに、これから執拗にDocBookの話をするが、DocBookもまた他の形式に変換するためのドキュメントメタフォーマットなのだが、「XMLまたはSGMLで書かれている」という特徴がある。 はっきり言えば、前述の形式と比べて圧倒的に読みにくく、書きにくい。 前述のフォーマットがHTMLよりも簡易な記述法を使っているのに対して、むしろODFやHTML, EPUBのようなドキュメント形式として作られたものだと考えたほうが良い。

だが、DocBookに執拗に言及するのは、DocBookが技術文書の形式として普及したからであり、かつトランスレータが多様であるからだ。標準処理系で

  • HTML
  • PostScript
  • PDF
  • RTF
  • DVI
  • plain

に対応している。

ちなみに、PureDocというのは私が作ったもので、RubyをベースとしたDSLである。 これは、Markdownのようなフォーマットが目指しているものとはちょっと方向性が違う。HTMLよりも簡易な記述とHTMLよりも強力な表現を求めており、実際変換したものはHTMLを拡張したものになる(XMLネームスペースを使って独自のタグを追加する)。

RubyのDSLであるため、「ロジックを含めた記述ができる」というのがポイントになっている。

読みやすいか??

まず言っておくが、どのフォーマットが優れているかということに関しては、もはや宗教であり、好みによる。

個人的にはReStructuredTextはかなり好きだ。 plain textの状態でも読みやすいし、表現力も高い。 Python(私は好きでない)のくせにやるじゃないか、と思う。

Re:View形式と、asciidoc形式はあまり好きではない。 PureDocがそんな感じじゃないかというかもしれないが、 plain textとしての自然さがないのだ。

例えば強調は、MarkdownやReStructuredTextでは

*強調されたテキスト*

となるが、Re:Viewは

@<em>{強調されたテキスト}

であり、asciidocには強調という概念がない。 (asciidocは「見た目」での定義であり、どちらかというとTeXなどに近い)

PureDocでは

e "強調されたテキスト"

となる。DocBook/XMLは完全に技術マニュアル用であり、そもそも「エレメントを定義しろ」とあるので、こちらも強調はない。 HTMLでは

<em>強調されたテキスト</em>

となる。RDocも見た目定義だが、一応「イタリックにするとiではなくemを使う」仕様なので

_強調されたテキスト_

となる。PODにも強調はなく、一応はイタリックを強調としているので

I<強調されたテキスト>

となる。

好みはともかくとして、ドキュメントメタフォーマットとしては「読みやすさ」は「表現力」に並ぶ重要な価値だ。 なぜならば、ドキュメントメタフォーマットはそもそもMicrosoft Word形式などのプロプライエタリフォーマットに対するアンチテーゼとしての意味合いがあるからだ。

そして、同時に「書きやすい」ことは、HTMLが簡易なマークアップ言語とはいえ、「普通の人が書くにはハードルが高い」という側面があったためで、より誰にでもかけて、HTMLのように面倒な(タグ表現が妙に長い上に、「なぜ終端にまでタグを書かなければいけないのか」という冗長さを避けたかったということから来ているように思う。

そもそも「書きやすいフォーマット」というのはWiki記法から流行り始めたように思うし、 徐々にブログなどでもHTMLではなくより簡易な記法でマークアップを可能にした。

ドキュメント形式なのにロジックがあるPureDoc

ちなみに、PureDocはRuby DSLであるため、

3.times do |i|
  p { "Hello!" }
end

なんてことができ、この結果

<p>Hello!</p>
<p>Hello!</p>
<p>Hello!</p>

という出力が得られる。 全く一般向けではない仕様だ。

さらに言えばZshで書かれたPureDoc Zのほうは

repeat 3
do
  p Hello
done

とすれば同じような結果が得られる。 これを「読みやすい」と思う人はどうかしていると思う。 PureDocは「書きやすい」ようにはしているが、「読みやすい」ようにはしていない。

PureDocはほぼすべてのテキスト系HTMLタグを使用することができ、かつオプションも指定できる。 さらにnoteなども備えていて、「HTML以上」であることが前提だ。 実のところ「ロジックで書ける」のも「HTML以上」の一部であり、「仕様」だったりする。

PureDocはinstance_evalを使ってRubyコードとして評価しているし、PureDoc Zに至ってはドキュメント中でライブラリをincludeすることでDSL的に使うための語彙がshell functionとして追加されるだけのものだ。

「メタフォーマット」としての価値

WikiなどはHTMLを簡単に書くためのものなのだから、特に変換先としての意味はないのだが、 メタフォーマットとしての価値は、「一度書けば表示向けにも印刷向けにもできる」ということにある。 基本的にはHTMLとPDFにできれば良いだろうという考え方が成り立つのだが、例えば「自分はコマンドドリブンなマークアップで書けば良いけれど、みんなはWordだからDocxで吐きたい」というケースはあるものであり、多様なフォーマットでの出力というのは割と重要な価値である。

実は、私はMarkdown/Pandocと出会うまでずっとPODで書いていた。 PODの多彩な変換形式に助けられてきたからだ。

だが、PODは純粋に汎用というわけではなかったし、 「DOCよりも多くのフォーマットに変換でき、より汎用性と表現力がある形式」を求めていた。

Pandocは極めて強力な変換ツールであり、入力形式はMarkdownに限ったわけではないのだが、 一応、Markdownを軸にしている…のだと思う。

そのため、PandocをMarkdownツールだと考えれば、Markdownは圧倒的なアドバンテージがある。 (もちろん、PandocがReStructuredTextをMarkdownと同等に変換できるのであれば、特にMarkdownにアドバンテージがあるわけではなくなる)

実はPandocは多彩なフォーマットが仇となり、適切に変換されないケースがそこそこある。 さすがに完璧に…というのは相当難しいのだろう。

Markdownにはもうひとつ、様々な処理系があるということがある。 KramdownはRubyで書かれており、Rubyプログラムにおいて使いやすい処理系だ。 KramdownもLaTeXへの出力に対応しており、割と使いやすい。

方言の話

Kramdownがinput formatとして

  • Kramdown
  • Markdown
  • GitHub Flavored Markdown

の3つを挙げていることに既に闇を感じるが、 実は処理系それぞれがMarkdownを拡張していて、一口にMarkdownといっても書き方に互換性がない、という問題が存在する。 冒頭で言及されていたのはそういうことだろう。

だが、それほど問題があるとは思わない。

まず、「多彩な処理系があるマークアップ言語」自体珍しく、Re:Viewなんてほとんどないし、ReStructuredTextだってそう多くはない。 なので、「特定の処理系向けに書かれたMarkdown」がそんなに問題なのか、という疑問がまずある。

さらに、MarkdownはGFMとPHP Markdown Extraが普及していて、これらの記法はだいたい通用する。 だから、純粋なMarkdownでは表現力はかなり限られるが、これらの記法を取り込めばかなりの表現力を持つし、これらの記法を取り込んでなお複数の処理系で取り扱うことができるのだ。

拡張記法のせいで無駄に「意味」をとられるのが気に入らないのであれば、 KramdownのようにMarkdown Standardに従った処理をできる処理系を使えば良い。

Markdownが良いという話

Markdownの記法が完璧だとは思わないが、少なくともPandoc Markdownは表現力にほとんど不満はないし、Pandocの変換フォーマットにも不足はない。

Markdownという記法について「及第点」で、変換という実用面に不満がないのだから、 それで文句を言うべきことなどない。

だから、別に「Markdownじゃ足りない」というのであれば拡張すれば良いし、それが許されてもいる。 拡張されたMarkdownを使ってはいけないということはないだろうし、素のMarkdownと拡張Markdownは別物だと考えれば使い分けだって成立する。

あるいは、「簡素さ優先のMarkdown」と「高機能なGFM」のように考えればよいではないか、ということだ。

無理に「Markdownとはこうだ」ということを押し付け合う必要もないし、Markdownはいままでの苦痛を緩和してくれる、「良いもの」なのだ。

そうでないというのならば、試しに大量のドキュメントをDocBookで書いてみればいい。 DocBookは確かに技術文書を書くのに適しているが、相当に苦痛だろう。 書く量が膨大で、しかもテキストはほとんどエレメントに埋もれてしまう。

別にHTMLで書いても構わない。 Markdownよりも優れていると思うのであれば。

Markdownが好きで、しかし機能が足りないから拡張しようという気持ちはなにも間違っていないし、それはまた別のものだと考えればごく自然なものなのだ。 方言があってはいけないというものではないし、が方言があったところでMarkdownは十分に共通性があると思う。

このブログもMarkdownで書いて、Kramdownで変換している。

ツールや記法でいがみあうことなどなにもない。 誰かに何かを強制する必要などないのだ。 あなたが幸せになるように使えばいい。

LinuxでReakTek r8152/r8153 USB LANが頻繁に切断される

QtuoのUSB 3.1 Type-CのUSBアダプタを使っているのだが、これは

  • 2x USB 3.0 Type-A
  • SD card reader
  • microSD card reader
  • RJ-45 1000BASE-T Ethernet

という構成になっている。 これらはおおよそ正常に動作するのだが、イーサネットに関しては頻繁に切断されてしまう。

調べるとACPIのリセットで解決するという声もあるのだが、 それでは解決しなかった。

dmesgでエラーの内容としては、

usb_reset_and_verify_device Failed to disable LTM

と記録されている。

これはtlpをこのデバイスにおいて無効にすることで解決する。 `/etc/default/tlp“において

USB_BLACKLIST="0bda:8153"

とすることで解決する。

それで頻繁に切断されるという問題は解決するのだが、ある程度通信していると、

Tx status -71

というエラーによって切断されてしまう。

netdev listに この件が報告されている。

これは、RealTekが配布しているドライバーで解消されるような情報もあるのだが、 AURにあるドライバは2.08.0であり、最新版は2.09.0なのだが、 2.09.0でも

LINUX driver for kernel up to 4.8

ということであり、もはやまともにサポートされていないようだ。 (それでも、このDKMSモジュールをインストールすることで1.6GBのISOイメージのダウンロードとアップロードは問題なく行えた)

RealTekのNICはWi-Fiのほうも途中で通信不能になるようなバグがあり、 LinuxにとってはRealTekのNICはあまりよくないという印象だ。 (ただし、RT2870チップは問題なく動作する――むしろ非常に良好に動作する)

Wi-Fiの場合は機種を限定するものの避ける方法はあるが、 USBのネットワークアダプターは多くがRealTek製で、選択肢が非常に難しい。

動作を確認できているわけではないのだが、USBイーサネットアダプターとしては AX88772/AX88719というASIX製のチップを採用したものがあるようで、 これらはプロプライエタリドライバがあるほか、プロプライエタリドライバを(手動で)導入しなくても動作するディストリビューションもあるようだ。

Pandoc + TexLive (LuaTex)によるPDF生成と和文フォント

Pandocは非常に便利なツールだが、オプションがなかなか複雑で、特にPDFにする場合などは長くて毎回打つのはしんどい。 このことは初心者にとって使いにくい理由のひとつになっていると思い、簡単に扱うためのZshスクリプトを書いた

だが、この際に思わぬことに気づいた。

LuaTeX(TexLive)経由でPDF化する際に、ドキュメントクラスがarticlereportなら-V mainfontが効くのだが、ltjarticleltjsarticleでは効かない。 正確には、欧文にしか効かない。

追いかけると、LuaTeXはmainfontは欧文フォントの指定であり、和文フォントは独立してmainjfontを用いること、とある。 しかし、-V mainjfont=...は効かない。

検索するとmainfontを指定すれば良い、というページばかりヒットするのだが。 諸君は本当に試したのか。見聞きしたままコピペしてないか。

というわけで、Pandoc 日本ユーザー会の[藤原 惟さん(すかいゆきさん, @sky_y)](https://twitter.com/sky_y)にご報告させていただいた。

すると、一時間ほどでご回答いただけた。

-V CJKmainfont=...とすると和文フォントが指定できる、と。

-V mainfont=...で欧文フォント、-V CJKmainfont=...で和文フォントの指定。 早速スクリプトにも反映した。

今回の解決はすべて藤原惟さんのおかげである。 改めて、この場を借りて感謝申し上げたい。

さて、Pandocは非常に便利なツールなのだが、多様なフォーマットに変換する都合からか、微妙なバグが割と多い。 そのバグが変換先エンジンの問題なのか、Pandocの問題なのか切り分けにくいので毎度なかなか辛い。

現時点では--pdf-engine=lualatex環境下において

  • テーブルが右に突き抜けてしまうことがある (発生するテーブルであれば、書き方を変えても駄目)
  • ページを下に突き抜けてしまうことがある (脚注やページ番号にはかぶってページの外に出る。 表と画像を併用すると発生しやすい)

ということを把握している。 どちらもPandocよりはTexLiveが原因のような気がするが、発生原因が特定できず、現在のところ謎バグである。

また、

  • インラインコードの--がTeXのハイフンに変換される
  • コード中の"がTeXの引用符に変換される

という問題もあるのだけれど、これも冒頭で紹介したスクリプトにおいては発生せず、

pandoc -s --filter pandoc-crossref -f markdown -V geometry=a4paper -V geometry:margin=1in -V mainfont="Source Han Serif JP" -V monofont="VL Gothic" -V documentclass=ltjarticle --pdf-engine=lualatex --toc "$1" -o "${1:r}.pdf"

とすると発生する。CJKフォントを指定しても発生する。ドキュメントクラスをltjsarticleにしても発生する。 けれど、スクリプトが実行しているデフォルトの内容としては

pandoc -s -f markdown -V geometry=a4paper -V documentclass=ltjsarticle --pdf-engine=lualatex --toc -o test.pdf test.md

なのだけど発生しない。元のコマンドでフォント指定をやめると発生しなくなる。 どうも試していくとmonofontを指定するとフォントがなんであれ駄目っぽい。

AURにfcitx-mozc-neologd-utを上げました

fcitx-mozc-neologd-ut/mozc-neologd-utをメンテナンスされていた方がut2に移行したため、 これらのパッケージがAURからなくなっていた。

そこで、私がAURにputしておいた

これらに関してはupstreamの作者の方(utuhiro氏)がAnterogos使いであるため、 PKGBUILDが標準で用意されている。 私がアップロードしたものはこれを調整したものとなっている。

行った調整は主に次のようなものだ。

  • メンテナの表示を私に
  • pkgnamefcitx-mozc-neologd-utを先に
  • 本体アーカイブをインターネットから取得するように
  • 本体アーカイブのチェックサムの追加
  • makedependsqt5-baseを追加(mozcが要求する)

手法はおおよそ先人に近いもの(fc2 blog))だが、次のような点が違う

  • ダウンロードはupstreamから行っている
  • makedependsなどの調整を行った

久しぶりのPerlの使い心地は

Perl 5はもうすっかり廃れてしまった言語で、Perlが好きな私も最近はあまり長いプログラムは書かなくなっていた。

Perl自体が滅びたとか、恥ずかしいような風潮もあるのだけれども、LinuxerにとってはSedやAwkを発展させたさらなる便利ツールなので、Perlが活用できていないというのはコマンドライン活用が下手ということになるので、そっちのほうがだいぶ恥ずかしい話になる。

とはいえ、そういう日常的な作業としては長くても50行いかないような話であるため、プログラミングらしいプログラミングというのはPerlで行うことはごく少なくなってきている。 あえてPerlで書くことが好ましい状況というのは、$_をどれだけ多用するかという問題だし、そうなると長いコードを書くにはとても向かない状況が出来上がる。

そのため、「汚くてもいいのでインスタントに書く」ときだけPerlを使うようになるし、そもそもほとんどの場合ワンライナーで使うことになる。

こうなってくるとそれなりの長さのプログラムをPerlで書くという機会はめっきりなくなってしまい、50行を越えるプログラムを使うということは稀になってしまっていた。 50行に満たないプログラムなら、グローバル変数や雑な変数乱造は普通にあるし、サブルーチンやリファレンス、オブジェクトなどを使う機会はなかった。

だが、久しぶりに仕事で集中的にPerlを触った。 が、なかなか手ごわかった。

一番つらかったのは「デリファレンスの不明瞭さ」だ。

Rubyで言うと次のようなコード

result_list.each do |one_result|
fname = one_result[:fname]
one_result.each do |match|
linenum = match[:linenum_from] + 1
match[:lines].each do |line|
printf '%d %s', linenum, line
linenum += 1
end
end
end

Perlではこうなった。

foreach my $one_result (@{$result_list}) {
my $fname = ${$one_result}{fname};
foreach my $match (@{${$one_result}{result}}) {
my $linenum = ${$match}{linenum_from} + 1;
foreach my $line (@{${$match}{lines}}) {
FH->printf('%d %s', $linenum, $line);
$linenum++;
}
}
}

なにをどうデリファレンスするか、が複雑すぎて極めて混乱した。 単純にこれはリファレントを得たいということを実現できる仕組みになっていないのだ。 このあたりはもう少し美しい解法があってもよかったのではないかと思う。 Perl4との互換性から生まれた仕様という気もするが、このあたりの仕様がぐちゃぐちゃなPHPよりもひどい。

また、先のブログでも書いたWindows環境でのUnicodeファイル問題

open(FH, ">", "ภาษาไทยファイル名");

これが文字化けるのだ。Rubyだと問題ない。

File.open("ภาษาไทยファイル名", "w")

もっとも、RubyはMinGWで動作するし、PerlでもCygwinでは問題ないので、ここはPerlの問題とは違うかもしれない。 ただ、全体的にPerlが「アメリカ人の感覚だなぁ」と思うことはある。 優れていたはずの文字エンコーディングに対するサポートも、ちょっと甘い。

Perlの文字列操作は割と独特。 PerlはUCSを採用し、内部エンコーディングにUTF-8、内部改行文字にLFを採用している。 そして、「文字ベースで処理するにも関わらず、文字列としてバイナリがデフォルト」。

次の場合はいずれもバイナリ文字列となる。

my $str1 = "こんにちは世界";
my $str2 = <>;
open(FH, "<", "somefile");
my $str3 = <FH>;
close(FH);

次のようにすればいずれも内部文字列となる。

use utf8;
my $str1 = "こんにちは世界";
binmode(STDIN, ":utf8");
my $str2 = <>;
open(FH, "<:utf8", "somefile");
my $str3 = <FH>;
close(FH);
use open IN => ":utf8";
open(FH, "<", "somefile");
my $str4 = <FH>;
close(FH);

文字列は「バイナリ」か「内部文字列」かの2種類だ。 内部文字列はUTF-8+LFになっているので、そのまま出力すると元の文字エンコーディングに関わらずUTF-8で出力される。

open(FH, "<:encode(euc-jp):crlf", "somefile");
my $str = <FH>
close(FH)
print $str; # 入力はEUC-JPだったけれども、「内部文字列をそのまま出力」するとUTF-8になる

Perlは文字列操作を常に正規表現で行う。 固定文字列検索は次のような具合になる。

$str =~ /\Qこ.ん.に.ち.は\E/;

あるいは

my $search_q = quotemeta("こ.ん.に.ち.は");
$str =~ /$search_q/;

きちんと内部文字列にしておかないと次のようなコードは失敗する。

$str =~ tr/A-Z/A-Z/;

Perlでは「バイナリ」「内部文字列」と言っているが、その実ASCIIとUTF-8だったりする。 内部文字列フラグがない文字列は、ASCII前提の頭で処理されるのだ。

そして、困ったことにPerlでは内部文字列フラグつきの文字列をバイナリに戻す方法がない。 文字列を内部文字列化することはできる。

use Encode 'decode';
my $str = <>;
my $internal_str = decode("UTF-8", $str);

ただし、このとき必ず変換される。 すでにUTF-8であると言えば変換されないわけではなく、 UTF-8として不正な文字は?にされてしまう。

encodeした文字列はバイナリであるが、これも変換を伴う。なので、次のコードではASCIIに変換しようとして、いずれも変換できないために出力は??となる。

use Encode qw/encode decode/;
my $str = "世界";
my $utf = decode("UTF-8", $str);
my $asc = encode("ASCII", $utf);
print $asc;

内部文字列として処理したあとURIエンコーディングを行う必要があったため、怪しげな超絶技法を駆使したりした。

{
use bytes;
$qword =~ s/(\W)/"%".uc(unpack("H2",$1))/eg;
}

だが、UCSとして文字列を扱うための機能自体は備わっている、ということを感じる。 一応固定文字列検索をindexで行う方法もある。

use utf8;
binmode(STDIN, ":utf8");
while(<>) {
if (index($_, "こんにちは") >= 0) { print; }
}

substrは実用的ではないほど使いにくいため、s///を使わざるをえないが。 文字列操作は割と悪くない。Perlの得意分野だからか。 もっといまいちな文字列の取り扱いをする言語は多く、古いわりにはまっとうに動作する。

だが、文字列を問答無用で破壊的に変更してしまうのはちょっと辛いものがある。 例えば次のようなケースでは変更前の値を変更後に使用する必要があるためコピーが必要になる。

sub get_and_save($) {
my $qval = $_[0];
my $quri = $qval;
{
use bytes;
$quri =~ s/(\W)/"%".uc(unpack("H2",$1))/eg;
}
getstore("http://www.example.org/board?q=$quri", "${qval}.html"));
}

破壊的に変更したくない時は決して珍しくないので、Perlを微妙に感じる場合のひとつだ。

ちなみに、文字列の扱いに関してはRubyはCSIを採用するため「変わっている」。

文字列にはエンコーディングに関する情報を与えることができるが、 特にこの場合に変換はしない。

str.force_encoding("EUC-JP")

Ruby2.0からは文字列はdefault_externalの値のエンコーディングだとみなされる。ロケールに従うため、ここではja_JP.UTF-8を使用していることからUTF-8とみなされ、 変換しようとするとUTF-8からの変換が行われる。 次の例ではUTF-8からEUC-JPに変換している。

puts "こんにちは世界".encode("EUC-JP")

open時にPerlみたいな方法で指定することもできるようになっているが、 このときにPerlのように内部文字列の変換を行うわけではない。 次のコードではEUC-JPのファイルを読んでEUC-JPで出力する。

File.open("somefile", "r:euc-jp") {|f| puts f.gets }

EUC-JPと認識されているので、変換することはできる。

File.open("somefile", "r:euc-jp") {|f| puts f.gets.encode("UTF-8") }

あるいは内部エンコーディングを指定して自動で変換することもできる。

File.open("somefile", "r:euc-jp:utf-8") {|f| puts f.gets }

だが、Rubyは独特なので、Perlがモダンでないという話とは繋がっていない。 Rubyの文字エンコーディング関連は、日本人によるものだけに非常に楽だ。

Rubyと比べてという話にはなるのだけれど、JavaScriptやPHPとくらべても、彼らが当たり前に「よきに計らってくれる」ことを手動で面倒をみてあげないといけなかったりして、ちょっと不自由な感じがある。

文字列と数値をコンテキストで分けている、というのもちょっと微妙だ。 それだったらまだ型を指定させたほうがマシであるように感じる。 どうしても==eqの書き間違えなどは発生するし、割とデバッグもしづらい。

Perlへの批判は大部分がPerl4に起因するもので、「書き方次第」なのだが、統一感がないというか、ちょっとすっきりしない仕様というのはままある。 これはZshを使っていてbashに感じるものと似たもので、古いが故か洗練されていないというか、なにより直感に反する要素がしばしば入ってくるのがストレスだ。

まず、リファレンスを多様するのであれば他のプログラミング言語のほうが楽だ。 そして、デリファレンスをたくさん書くのであればオブジェクト指向で書くほうがずっとスマートだ。

Perlに求めていたのはそのあたりの改善だったのだが、それはPerl6によってではなく、RubyやPythonによって達成されてしまった。 だが、これらはすでに「Perlの良さ」はないため、Perlの新しいバージョンにはその改善を求めたかった。 実際にはPerl6は全く異なる言語であり、(なかなか良いように見えるが)望んだものとは少し違う。

依然としてUnixツールとしてのPerlは優れたものであり、これよりUnixツール的に優れた言語は登場していないが(Streemが実用レベルに達すればその状況は変わるかもしれない)、本格的なプログラミングにはいささか辛い部分も見え隠れする。 特に、「わかりづらくなりやすい」という点に関しては問題が大きく、さらに妙に面倒な状況が出る場合もある。

今、Perl5を使うにはいささかの割り切りが必要だ。 だが、他の大多数の言語よりも依然として良いのもまた事実。 プログラミング言語が業務的に語られることの多い昨今だが、優れた言語は優れた言語なのであるということを改めて実感させてくれる部分もあった。

Gtkなデスクトップ環境でGtkとQtのテーマと格闘する

Gtk環境でのQt

作業環境はManjaro XFceであり、実際の利用環境はCinnamonで、KDE Plasmaは入れていない。

KDE環境だとQtのstyle (QtだとthemeではなくてVisual Styleと呼ぶ。Windows風)は色々入っていたりするのだけども、こういうGtkデスクトップ環境だと古臭いの(ClearlooksとかMotif)とかしか入っていなかったりして、Qtアプリの見かけがだいぶよろしくない。

そこでまず、QtらしいStyleを導入する。 Qt4とQt5のStyleは分かれていて、Manjaro/Archだとkde4やkde5という名前で分けられているようだ。 とりあえず見た限りplasmaパッケージに含まれてはいるものの、KDE本体に依存するようなパッケージはない模様。

Qtのテーマ設定はQt4はqtconfig-qt4、Qt5はqt5ctで行う。

これでKDEとは関係ないけれどQtを使うアプリ(例えばEksterteraとかq4wineとか)の見た目がよくなり、 Ruby qtbindingsも快適に使うことができる。

そう、そもそも今回、ruby-qtbindingsを使ったら見た目がひどかったことからスタートしているのだ。

Gtk2テーマ

Gtk2は恐ろしく鬼門だ。 特に厄介なのが次のアプリ

  • Sylpheed / Claws Mail
  • Mikutter
  • Leafpad

なぜならば

  • Sylpheed / Calws Mailはテーマによっては起動しない。
  • Sylpheed / Claws Mail / Mikutterはスクロールバーがおかしいテーマが多い
  • MikutterはBreezeテーマなどタブの表示が変になるものも多い
  • スクロールバーずれ程度で問題がなく美しいOxygen-GtkはLeafpadはSEGVる

Leafpadを分離するのが良案か。

#!/bin/bash

GTK2_RC_FILES=/usr/share/themes/Adapta-Eta/gtk-2.0/gtkrc exec /usr/bin/leafpad

なお、Gtk3版のl3afpadを使うという手もある。

XFce4は.gtkrc-2.0や環境変数で使用するgtkrcを指定していると、全体的にそれに従う。 外観の設定に左右される範囲よりも大きいようだ。

Oxygen-gtkは良いのだけどなかなか問題がある

  • Gtk3アプリでは表示がおかしくなる可能性が高い
  • Xfce4ではアイコンが反映されなくなる
  • 部分的にUIフォントを頑なに無視する
  • もう開発も止まっているようで今後使えなくなるかも

安定して使えるGtk2テーマがなくなるのはなかなか痛い。見た目はよくはないが、XFceテーマシリーズが安定しているようだ。

Gtk3

Gtk3のほうはもっとシンプル。

Gtk2テーマを指定してXFceを起動すると、Gtk3テーマもそれに従おうとするので、明示する必要がある。

Gtk3も同一テーマで構わないものであれば良いのだが、oxygen-gtkは駄目だ。

if [[ $DESKTOP_SESSION == xfce ]]
then
  export GTK_THEME=Adapta-Eta
fi

しかし、これでもアプリケーションから開くときにGeditを指定するとOxygen-Gtkを使用してしまう。 同様のケースでGeditはfcitxが死んでいる状態で起動したりするので、コマンド名で指定して起動する必要がある。

Cinnamonではデスクトップ設定が反映されるので設定しないほうが良い。

GUIツールキットのお話

今回はRuby qtbindingsを使おうとしたところからスタートした。

RubyでのGUIはまるでスタート廃れたかのような状態にあり、まるでruby-gnome2が唯一の選択肢であるかのようである。 ただ、ruby-qtbindingsは開発は継続しているし、Windowsでも動作するようになっているようだ。

個人的にあまりGtkは好まない。 UIとして使いにくいというのもあるし、設定が複雑でうまく反映されないというような理由もある。 プログラミング上も、QtのほうがAPIは使いやすい。

UIとして優れているのはGtk2だと思う。

Gtk3はメニューが非常に少なく、わかりにくい。 また、ファイルダイアログが劣悪で、ファイルを開くときはまだ良いのだが、ディレクトリを開く場合は非常に辛い。 というのは、何もファイルを選択しない状態で入力を開始した場合のみキーボードからのパス入力を受け付けるが、 Enterを押した時点で「開く」動作をする。 そのため、ディレクトリを開く動作のときには最後まで入力するか、クリックするかしか選べない。

Qt4/Qt5のダイアログはファイル名としてディレクトリパスを入力することもできるが、やはりディレクトリを開く場合には一発で開かれてしまう。 さらに登録される場所がさらに限定的となり、Gtk3よりなお悪い。 なお、XFce4ではQtのファイルダイアログをGtk3のものに置き換えるようだ。

Gtk2のファイルダイアログではファイルリスト側にフォーカスされていればWindows同様にインクリメンタルサーチとなり、 ファイル名欄が常に存在しディレクトリに対して入力を行うとまずディレクトリに移動するという振る舞いとなっている。 これはおそらく最も適切である。 (だが、これも場合によるようで、Qt4/5のような振る舞いをする場合もある)

API的に、あるいは設計的に見ればGtk2からGtk3、Qt3からQt4というのは大幅に進化している。 実際に「よくなった」のだ。

だが、現状でGtk3、あるいはQt5の熟成度というのは全く足りていない。 Qt4からQt5はある程度の互換性を持った状態で進化している。 その進化はわからないでもない。コンピュータの進化に合わせて、あるいは周辺環境の進化に合わせてコンポーネントを作り直した。 その際にいくつかのいまひとつな設計を修正し、テーマデザインにフラットデザインを推奨した。

だが、そのような変更は必要だったのか疑問だ。 内部的な進化や、標準テーマデザインの変更に関しては互換性を維持しての改修でもよかったのではなかろうか。

期間的にGtk3やQt5は日が浅い。 Gtk3のコンセプトが不評ということもあるが、2011年にGtk2は開発終了しているにも関わらずGtk3への移行が進んでいないプロジェクトは多い(XFce4もそのひとつだろう)。 現状ではGtk2を採用するプロジェクトもGtk3への移行を模索する時期にきているが、Gtk3に移行できているプロジェクトはまだ少ない。 Qtに関しては各プロジェクトが苦労してQt3から移行を完了し、あるいは移行できなかったプロジェクトは廃止されているが、 Qt4を採用しつづけるプロジェクトはまだ少なくない。

この状態でさらに非互換性を持つGtk4やQt6へ移行する必要があるのだろうか。 いずれのツールキットもより熟成すべきであるように私には思える。

また、GUIプログラミングも以前は盛んでwxwidgetなどが流行したときもあったのだが、早々に廃れてしまった。 WXWidget自体は現在も開発が続けられているが、wxrubyは既に終了しており、rwxは十分に開発・テストされていないようだ。 RubyにおけるGUIプログラミングの選択肢は非常に乏しく、qtbindingsも将来的には不透明だ。

さらに、Gtkのその問題点から開発者が離れている。 これはGtkの問題点というよりも、Gnomeの方針に開発者がついてきていないという問題なのだが、 GnomeはGtk4においても方針を維持しており、今後もこの傾向は続くだろう。

ユーザー側にはあまり見えない状況ではあるが、実はLinuxのGUI周りはかなり不安定な状況にある。 個人的にはQtがより普及し、バインディングが安定していてくれると良いのだが…