PureBuilder Simplyと新しいサイトのお話

PureBuilder Simply

デザイン

PureBuilder Simplyは従来とは大幅に考え方を変えた。

従来は基本的に「いっぺんの処理ですべて行う」というものであった。 このため、特に難しかったのが、ACCSにおける「前後の記事へのリンク」である。

PureBuilder Simplyは処理が分離されている。 一番基準となるスクリプトはデフォルトで全記事を処理する。 そして、全記事のメタデータをデータベースに書き出すのである。

従来はPureDocメタセクションに直接書くという方法をとってきた。 そのため、ドキュメントが処理時に変更されるのだが、これは扱いにくい側面が結構あった。

従来のPureBuilderはドキュメントごとに処理するようになっており、 メタデータはドキュメントにある。 そのため、処理時には「そのドキュメントのメタデータしか知らない」状態であった。

今回のPureBuilderもすべてのドキュメントのメタデータを読み込むことはしないが、 すべてのドキュメントのメタデータの書き出しは行う。

メインスクリプト以外については、このスクリプトが書き出したデータベースに基づいて処理を行うため、 すべてのドキュメントのメタデータを知った状態で処理することができる。

Frontmatter

もともとPureBuilderはPureDocを前提としていて、Markdown supportはPureBuilder2で採用された。

Markdown Supportを採用したのはWindowser向けのフレンドリーシュガーであり、 Mimir Yokohamaでサービスを展開するにあたって、記述の難しいPureDocではなく、 記述しやすいMarkdownで書けるようにすることで「ユーザーによる更新の容易さ」を向上させる目的があった。

この時点でMarkdown YAML Frontmatterのことを知らなかった。 そのため、従来のPureBuilderではMarkdownドキュメント中にHTMLコメントを入れ、その中にPureDoc meta headerを入れるという仕様になっていた。

だが、そもそもMarkdownにYAMLでメタデータを書ける仕様である。 同じYAMLのメタデータなのだから、これに従うべきだ。

そのため、PureBuilder SimplyではMarkdownドキュメントのFrontmatterを必須としており、 frontmatterが存在する前提で処理する。 (titleメタデータが必須であるため、どのみちfrontmatterは必須となる)

さらにReStructured Textに対応したが、これも先頭にコメントを入れてYAMLでヘッダを書く、という仕様とした。 次のような具合である。

ReSTなら

Pandoc

PureBuilder Simplyはドキュメント処理をPandocにゆだねている。

これは別に手抜きというわけではない。従来にしてもMarkdownの処理はKramdownによって行っているのであり、 PureDocの実装は別なので特にPandoc採用でアウトソーシングしたという感はない。

Pandocの利便性と「標準性」から、「Pandocを主としてPureBuilderは補助であるほうがユーザービリティが高い」と判断したのだ。

PureBuilder Refinedでは新しいPureDoc Zをサポートする予定だが、 PureBuilder Refined自体がPureBuilder Simplyでは不足の場合に限られるので微妙かもしれない。

「事前生成」戦略

PureBuilderは言葉の意味としてはCMSで合っているのだが、どちらかというとCCS(Content construction system)に近い。 基本的に生成機能だけで、管理に関してはシステムの標準的機能でなるべく簡単てにできるようにしている。

一般的なCMSとの最大の違いは、「Webアプリケーションとして動作しない」ということだろう。 原則としてPureBuilderは(ホームページビルダーなどで書いた場合と同様に)ローカル環境でウェブページを組み上げ、そのままアップロードすることで動作する。

従来のPureBuilderにあった、Webアプリケーションとして動的に生成するためのプラガブルな仕様は現時点ではPureBuilder Simplyにはない。 予定もされていない。単一ページのサポートは限定的で、原則としてディレクトリ単位でビルドを行う。 全体ビルド機能も排除された。

より「サイトを構築するためのスクリプト」という点に特化した。

私のウェブコンテンツ生成は可能な限り「事前生成戦略」をとっている。 通常、ページは書く回数よりも読まれる回数が多いので、コストのかかる処理は1度だけ行いたい、という方式だ。

これは構造的に最速の方式でもある。

ウェブサイトの仕組みを考えればわかるが、たとえばWordPressでは

  1. ウェブサーバーが接続を受け付ける
  2. ウェブサーバーがPHPプロセスにWordPressを渡す
  3. WordPressがデータベースにアクセスする
  4. データベースから必要なデータを受け取ったWordPressがページを生成して返す
  5. ウェブサーバーが応答する

という手順になる。 WordPressのキャッシュ機能ではWordPressはデータベースから受け取った結果を処理せずにそのまま応答するため、高速化するのだが、 それでもこの接続にかかる時間が決して小さくない。

対して、静的ファイルならば

  1. ウェブサーバーが接続を受け付ける
  2. ウェブサーバーがファイルを読み込んで応答する

とプロセスが少なくなり、より高速だ。 WordPressの高速化手法も、PureBuilderが同様の手法を適用すればさらに高速する。

さらに、ウェブサーバーにとって静的ファイルの応答は基本的機能であるため、 より高速なウェブサーバーが選択できる、というメリットがある1

また、静的ファイルのみでウェブサイトの構築が可能なことで、ウェブサーバーの選択肢が増える。 PHPが動作しないGeocitiesやGitHub Pagesでも構築可能だ。

Mimir Yokohama新サイト

新サイト開設

Mimir Yokohamaの新ウェブサイト開設は、主に「異様にサイトが重くなっている」という事情からきているのだが、 実はそもそもPureBuilder Simplyはこの新サイト構築のために書き直した。

Aki SIE新サイト開設時もそのためにPureBuilder2を作ったのだが、 PureBuilder2が6ヶ月も要したのに対して、作業時間で4日、経過時間でも9日と非常に速く書き上がった。 やはりデザインは大事だ。

そして当然ながら、Mimir YokohamaウェブサイトがPureBuilder Simplyのデビュー戦となった。

「楽」という言葉の意味

Mimir Yokohamaのウェブサイトの出来には非常に満足している。

だが、この開発において“PureBuilder Simplyの開発”は全行程における30%程度でしかなかった。

PureBuilder Simplyを使ったサイトは非常に「楽」であり、「簡単」なのだが、誤解してはいけない部分がある。

今回はWordPressからの移行であるため、WordPressで利用している機能に近い状態を狙った。 デザイン的にも近く、バックエンドの変更や、それによって品質が低下した印象を与えないようにしている。

まず言っておくと、「WordPressのサイトを欲している」のであれば、PureBuilderを採用するよりも、 WordPressを採用したほうが確実に楽にできる。 なぜならば、そもそも欲しているのはWordPressなのだから、WordPressよりも楽にはならない。

そもそもPureBuilder Simplyによる構築と、WordPressによる構築はちょっと話が違うのだ。

WordPressの場合、テーマ機能やプラグインなどは既に揃っている段階から話をはじめる。 PureBuilder SimplyはそもそもWordPressではできない完全なカスタマイズを実現するという前提があり、 WordPressで言えばテーマやプラグイン、CSSなどを「すべて0から記述するところからはじめる」というのと同じ位置にある。

もしもWordPressをその位置ではじめるという形で条件を揃えたならば、PureBuilder Simplyのほうが「楽だ」と断言できる。

実際はそのような条件では比べないと思うのだが、逆にWordPressに合わせて構造やビルドの仕組み、テンプレートやCSSなどがすべて揃った状態からはじめるならば、 これもPureBuilderとしてはそこまで分の悪い勝負ではない。

なぜならばその状態で必要なことは

  • 文書を配置したい場所に新しくファイルを作り、MarkdownまたはReSTで書く
  • PureBuilderのバッチスクリプトを実行する
  • Gitでcommit&pushする

というだけのことだからだ。

「設定ファイルを書く」「コマンドを実行する」というあたりに、「Unixer的な楽さ」の感覚があるが、 これに関しても別にお客様に納品するときにはちょちょいと調整すれば良い話だ。 若干手順が多いようにも感じられるが、実際はWordPressの場合は

  • ログインページにアクセスしてログインする
  • ダッシュボードから新規記事の投稿を選択する
  • ページ上で文章を書き、タイトルやカテゴリなどを選択する
  • 投稿ボタンを押す

という手順で、慣れてしまえば麻痺するが、かなり手順は多い。 私が使っているWordPressサーバーは遅く、1クリックあたり1分とか待たされるので、 「WordPressは手順が多くて面倒」という印象が強い。 あちこち飛んではキーボードとマウスを持ち帰るUIも嫌いだ。

もし、PureBuilder Simplyでできることと相当のものとして、 「WordPressもデザインや挙動をカスタマイズする」 という条件にしたならば、これはPureBuilder Simplyが有利だろう。

PureBuilder Simplyを採用するのは「入り口」

だが、実際はPureBuilder Simplyの採用というのは全行程においてそこまで大きなものではない。 おそらく、PureBuilder Simplyのデフォルトで作られたサイトには誰もが失望するだろう。

PureBuilder Simplyの場合、「テンプレート」と「CSS」という要素がある。 これを書くのは、PureBuilder Simplyで「簡単にしている」部分ではないところであり、技術者の腕のみせどころだ。

最近はwebといってもCMSありきのエンジニアが増えていて、HTMLやCSSを直接記述することができない人が増えている。 だが、それはCMSの枠の中でしか仕事ができていない。 PureBuilder Simplyはそれをイチから作るのであり、ウェブデザイナーとエンジニアの腕の見せ所だ。

PureBuilder SimplyのテンプレートはPandocのHTMLテンプレートである。 ただし、「Pandocの出力に対してeRubyで処理できる」ようになっている。 結果、テンプレートの展開は2度行われる。

Pandocのテンプレート機能は意外なほど強力だが、 「値が○○だったら」という式はかけない。

eRubyは完全なプログラムであり、「なんでもあり」である。

比較的単純な(PHPやSSLで行うような)ものに関してはPandocテンプレートで処理できる。 実際、現時点でMimir YokohamaのウェブサイトはeRubyでの処理を無効にしている。

PureBuilder Simplyにおけるテンプレートの作成は「若干の、もしくは本格的なロジックを含むHTMLテンプレートを書く」という作業である。 もちろん、それはデザインが必要であり、CSSと連動した「ページ設計」が必要となる。 ページ設計はかなりエンジニアリングレベルの高い作業だし、 最も単純にはデフォルトテンプレートを使っても良いのだが

CSSと連動した高度なロジックを使いたいといった場合には難易度は上がる。

プログラミングではないけれど、ロジカルに考える

もちろん、CSSを書くのはプログラミングに近い次元になってくる場合もある。

今回のMimir YokohamaのウェブサイトはハンバーガーメニューとドロワーについてはJavaScriptを一切使用していない。 これはAki SIEウェブサイトで使用されていたものの改善版である。

だがそのために、配置や仕組みに関してはかなりロジックが含まれている。 CSSにはロジックはほとんど含まれないが、「ロジックをほとんど含むことのできないものによって動的なフローを実現する方法」を考えるところにロジックが行使されているのだ。

プロモーションモードのページでは下からフェードインするようなページデザインになっているが、 これもJavaScriptは使用していない。

これは単純にHTMLとCSSで実現するウェブサイトを構築するときに、 「単に書くのではなく、そこにロジックを含んだ構造をもたせる」ときに必要となるものだ。

PureBuilder Simplyはウェブサイト構築ツールであって、 デザインに関しては感知しない。 だから、そこに関しては「自分で作る」必要があるのだ。

今回も難易度や作業量としては、テンプレートとCSSを書くことのほうが大きかった。

PureBuilderはサイトの内容については感知しないのだから、別にJavaScriptを含んでもいい。 特にそれを禁止はしていないし、支援もしていない。 別にWordPressのクローンを作ることも、できなくはないのだ。

「サイトを構築する」手間で考えると…

単純に「見栄えするサイトを作りたい」という条件で考えた場合、 WordPressのほうがずっと楽だ。 なぜならば、デザインやロジックが既に存在していて、それを選ぶだけだからだ。

PureBuilderが担っている部分に関してはWordPressよりも楽かもしれないが、 WordPressにはあるがPureBuilderにはない部分がある。 それについてはどうしてもWordPressでは発生しない労力を払わざるをえない。

だから、サイトを構築する手間がWordPressよりも軽いということはない。 WordPressのインストールの労力を含めてもだ。

だが、そのような「敷居の低さ」を求める人がPureBuilder Simplyを自らインストールしてサイトを構築することは想定していない。 PureBuilder Simplyで自ら構築する人は、そんなものがなかったとしてもテンプレートを書き、CSSを書き、JavaScriptを書く人だ。 私がお客様にPureBuilderの簡便性を説くときは、そのような想定で話しているわけではない。 構築はこちらで行って、更新をお客様がされる際には難しくない、ということを言っているのだ。

テンプレートやCSSやJavaScriptは自分で書く、という前提のもとでは、PureBuilder Simplyの採用はかなり労力を削減することができる。 PureBuilder2と比べ管理の手間もかなり減り、非常に楽になった。

新サイトのデザイン、ポリシー

PureBuilderの強みは事前生成による高速性である。

さらにMimir Yokohamaでもポリシーとしている「軽量さ」と「アクセシビリティ」に重きをおいたデザインとなっている。

ただし、Aki SIEのウェブサイトは発想力をアピールする意図もあったのだが、デザインがちょっと古くさい2。 今回Mimir Yokohamaのサイトではよりモダンなデザインを採用することにした。

といっても、そのデザインはほとんどがWordPressで使用していたテーマのビジュアルを踏襲している。 ただし、全く同じというわけではなく、もとがシンプルなデザインであったために「ブロックごとに端までボーダーをひっぱる」「白に対してグレーのラインを引くモノトーン調」「右側サイドバーの2カラム」といったことを踏襲しているだけで、 メニューデザインなどは異なるし、実はカラーテーマも違う。 このあたりは「変えることが目的だった」わけではなく、そもそももとのブログでもカスタマイズしたかった部分なのだ。

ちなみに、ブログではそんなシンプルなデザインであるにもかかわらず、ちょっと古い環境(IEなど)では表示が崩れる。 なんでその程度のもので崩れてしまうのか、私には疑問でならない。

前述の通り、ハンバーガーメニューやフェードインテキストなどはCSSで記述されている。 これは、主に次のような意図だ。

  • JavaScript禁止の環境や、JavaScriptを搭載しないブラウザでもエクスペリエンスを損ねない
  • JavaScriptを使用していない分容量的に軽量
  • HTMLを「意味」を欠落させない

ただし、古いブラウザでのエクスペリエンスは若干犠牲になっている。 だが、それは「アニメーションが表示されない」程度の話で、表示自体はChrome 1.0, Firefox 1.7, Opera 9.0, Safari 3.1で対応している。 あまり言いたくはないが、IEは9.0からの対応だ。

実は今回のサイトではHTML中に同じメニューが2回登場する。これは、上記環境よりも古い環境においてはドロワーが表示できない代わりにサイドバーにメニューを表示させるようにするためだ。 これはアクセシビリティのための処置だが、場合によっては1kB程度はサイズが増加するため、ちょっと残念なところだ。 このメニューはごく初期のCSSしかサポートしない環境でも正常に表示される。 CSSを全くサポートしない環境の場合、メニューは2つ表示される。 この場合上のメニューは記事タイトルよりも上になり、高さもあるため見栄えしないが、そのような環境では仕方ないし、十分許容範囲だろう。 むしろタイトルと記事の間に入るよりはずっと良いと考えられる。

軽量性重視だが、従来と違い飾りとしての画像がところどころに入っている。 従来があまりにも殺風景すぎたという反省であり、このあたりはブログの時点で投入しているものを継承している。

プロモーションページの実現

全く印象の異なるプロモーションページだが、書き方はほとんど同じである。 別にテンプレートをかき分けることもしていないし、普通にMarkdownで書かれたページだ。

プロモーションページの印象の違いは、テンプレートにおける若干の工夫と、CSSによって実現されている。 frontmatterでプロモーションページであることを指定すると、Pandocテンプレートによってそれがクラス設定される。 あとはそのクラス設定に基づいてCSSで見せたくない要素を消去し、一部レイアウトを変更する。

こうした発想力は、やっぱりロジカルシンキングなのだ。

プロモーションページもかなりシンプルだが、 見出しには画像を使いたかった、という気持ちがある。

そうしていないのは、「適切な画像」の選定が非常に困難だったことと、 ヘッダーごとに画像を選択するためにはそれなりにあまりスマートでない余計なロジックを追加する必要があったからだ。

もしもこれぞという画像があれば採用することだろう。

ちなみに、プロモーションページはスマートフォンの商品プロモーションページをイメージしている。 なるべく説明的にならないようにしたのだが、後に書いたものほど説明的になってしまった。 どこまでイメージで語り、どこまで具体的に語るかは難しいところだ。

速度

実際のところ、Mimir Yokohamaにおける制作ポリシーと同一ポリシーで制作したのであり、「最速を目指す」という方式ではない。3

だがそれでも、旧WordPressサイトの10倍程度の速度になっている。 高速化のために使用した手段は以下のようなものだ

高速なサーバーを選択
ConoHaはSSDを採用しており、ネットワーク帯域も太く高速だ。 Nginxを採用
静的ファイルの応答に関してはNginxは最速に近い コンパクトなHTML
できるだけ冗長な表現を避けてコンパクトなHTMLが生成されるようにした。ただし、アクセシビリティを優先してメニューは重複している 可能な限りCSS
JavaScriptなしで動作するようにしたのは「JavaScript無効というオプションを与えるため」だが、ロジックの最適化によってある程度の容量削減に繋がっている WebP
WebPをサポートするのはChrome/Chromium系列だけだが、WebPは「アルファチャンネルつきロッシー圧縮」が可能なため、PNGよりもだいぶ軽くなる。一部PNG画像についてはobjectタグによりWebPを優先して使用するようにしている。アクセシビリティを重視し、重要な画像ではこの処理は行われずimg画像を使用している。 画像よりもCSS
「デザインはセンスでがんばる」方式で、画像などのアイテムの使用数は非常に少ない。寂しさはグラデーションで埋めているが、華やかさに欠ける感は否めない。

高速性ということでいえば、「CSSが重い」ということは感じるが、改善は若干難しい。 もちろん、minifyなどのテクニックである程度は小さくなるが、保守性を重視しているためだ。

また、CSSを3つから1つに減らすというアイディアもあったのだが、比較的サイズの大きいファイルであり、並列ダウンロードしてもらったほうが速いことから分割に戻した。

ミーミルのロゴなどは埋め込んだほうが高速化するだろうが、軽量化には寄与しないし、アクセシビリティが下がるので実施していない。 トップページで51.5KB、低速なうちの環境でTTFBは14.08ms、DNS lookupとfaviconを除いた時間は101.36msとなった。 従来が500kB/5s程度だったことを考えると、この計測では1/10の容量、50倍の高速化となっている。

MarkdownとReST

今回、Pandocの採用によってMarkdown以外のソースフォーマットに対応することが可能になった。 そして、最初に採用したのがReStructured Text(ReST)である。

Pandocがサポートする中で最もMarkdownに近い汎用性があるのはReSTである。 他にそのようなフォーマットはないが、あるいは専門分野での記述用にDocBookなどをサポートする可能性はある。

なお、入力ソースとしてのHTMLは、判別しがたさの観点からサポートは行わない。

ReSTはMarkdownと比べて表現力に優れている。 記述の簡便性も「好みの問題」と言えるような差異だ。 ただし、ReSTが優れている点について必ずしもそのまま適用できるわけではない。 なぜならばPandocがReSTをフルサポートしていないからだ。

実際のところ他フォーマットへの変換を想定しないのであれば、HTMLを直接記述できるMarkdownの優位性は揺らがない。


  1. 今回はNginxを使ったが、基本的にNginxも静的HTMLファイル向けのサーバーで、アプリケーションは他のサーバーに接続するリバースプロキシとして動作する方式だ。Thinなどを使う手もあるかもしれないが、Nginxよりも高速化するかは疑問。

  2. 800pxのブロックが中央にフロートしているデザインは2005年ころから流行したブログデザインと類似のものだ。今でもamebloなんかはこのデザインなのだが、新規にサイト立ち上げると画面めいっぱいまで使うデザインがデフォルトになっている。

  3. 最速を目指すのであればコードゴルフやminified、画像の排除や機能の統一化なども考えられる。実際のところ「速度は上がるがアクセシビリティが下がる」方式は取ってないし、コスト過剰にもならないようにしている。

ConoHaへのサーバー引っ越しレジュメ (DeleGate-Nginx/Postfix/Dovecot, Let’s Encrypt)

概要

作業概要は以下の通りだ

  • サーバーをDTI(@ServerMan)からConoHaに変更する
  • サーバーOSをCentOS (6.9)からArch Linuxに変更する
  • WebサーバーをDeleGateからNginxに変更する
  • WebコンテンツシステムをPureBuilder2からPureBuilder Simplyに変更する
  • Mimir YokohamaのWebコンテンツを別サーバーのWordPressから新サーバーのPureBuilder Simplyに変更する
  • Webメニューを完全JavaScriptフリーにする
  • Postfix/Dovecotを引っ越しする
  • DNSサーバーをConoHaとし、DNSの設定を変更する
  • 一部のドメインを廃止とする
  • 一部のドメインの役割を変更する
  • Let’s EncryptによるSSL証明書を取得し、HTTPSに対応する
  • 同証明書にメールも対応させる

なお、あまり詳細な解説はしていない。 Linuxやサーバーに関する基本的な事項に対して理解していないまま実施するのは危険であるため、 「コピペ仕様」にはしていない。 詳細に対してエラーが生じるなどの理由でより情報が欲しい場合はあるだろうが、 「言っていることが理解できない」のであれば、サーバー構築をするにはまだ危険なレベルにあると思ったほうが良いだろう。

承前: 開発

PureBuilder Simplyの開発

今回のために新しいコンテンツシステムであるPureBuilder Simplyを開発した。 この詳細は別に譲ろう。

テンプレートの開発

PureBuilder SimplyはPandocテンプレート+eRubyテンプレートというテンプレートを扱うことができる。 PureBuidler Simplyにテーマファイルがあるわけではないので自分で書く前提である。

今回は複数の表示デザインがあるのだが(現在のところは表示されるのはアーティクルモードとプロモーションモードの2つだけだが)これは全てPandocテンプレートとCSSで実現している。

もちろん、このようなテンプレートの開発はWeb屋の腕の見せ所だろう。

CSS

サイトはそれほど華やかなデザインではないが、技術的に劣っているわけではない。 その最たるものがCSSのみで書かれたハンバーガーメニューとドロワーだろう。

ポイントを簡単に言うと

  • ドロワーはfixedで上部に最初からある。display: noneで、高さは比較的新しい単位であるvhである
  • ハンバーガーメニューはtransitionを使っている
  • z-indexでメニューのほうが上になるようにする
  • 状態変遷は次のような方法でコントロールしている
    • 表示されないチェックボックスを用意し、操作対象をlabelで関連づける。これによりlabelで囲まれた要素をクリックするとチェックボックスがトグルする
    • CSSの+セレクタは同じ親要素を持つ次の兄弟要素に適用される
    • チェックボックスにはチェックが入っているときに適用される疑似要素:checkedがある
    • そこで、チェックボックス本体の直後に対象となるセクションコンテンツを置くことでチェック状態によって状態をトグルできる
    • ドロワーはfixedなのでどこに書いても構わないので、このセクションコンテンツの中におく。場所としてはメニューの位置に基づくのが良いだろう

見た目はWordPress時とあまり変わっていないが、性能は大幅に向上した。

速度

キャッシュの効かない初回アクセスで従来のWordPressページが5.57s、新しいページは約400msと10倍程度高速化した。

ConoHaサーバーのスタートアップ

立ち上げ

ConoHaのサインアップは10分もあれば可能で、即座にサーバーを使いはじめられる。

サーバー仕様は東京リージョンの1GBプランである。

512GBプランは安いが、性能が十分でなく、またマイグレーションができないため、1GBプランとしている。

この時点でサーバー選択が可能なので、Arch Linuxを選択する。 また、この時点である程度のセットアップが可能だ。 ここでSSH公開鍵の登録が可能である。

のようにして専用に生成しておく。 そしてconoharoot.rsa.pubを登録する。 名前からもわかるように、ここで登録する鍵はroot鍵である

また、開放するポートも選択できる。 ここで開放するポートはサーバーよりも上流でフィルタリングされる。 ここで透過していないポートに対するアクセスはサーバーに到達しない。

ただし、結果的にSSHポートの変更はサーバーに負担がかかるものになっている。 少なくともパスワードログインは禁止すべきだろう。

現時点ではSSHのみを通過させる。

初期設定

ConoHaのArch Linuxは標準インストールではなく、ある程度調整されている。 主にSSHログインが可能で、SSH公開鍵が登録され、パスワード認証不可となっている、といったことだ。 こうした内容は/etc/cloud/conoha-init/conoha-init.shによって確認可能だ。

複数のサーバーを接続する予定であれば変更すべき点は多いが、そうでなければ作業は平凡だ。

アップデート

まずはアップデートする。 20MB/sも出るため、超早い。

Zsh

私としてはZshがないと話にならないので入れておく。

これ移行はZshでの作業

一般ユーザーの追加

もちろん、一般ユーザーは登録されていない。

この時点で一旦再起動しないとパスワード設定ができないので、再起動しておく。

パスワードの設定

その上でvisudoを使って%wheelに対するsudoを許可する。

pacaurとyaourtのインストール

AURパッケージも扱う予定であるため、pacaurを入れておく。

# su - jrh
% gpg --recv-keys 487EACC08557AD082088DABA1EB2638FF56C0C53
% sudo pacman -S git

%git clone --depth=1 "https://aur.archlinux.org/cower.git"
%cd cower
%makepkg -si
%cd ..

%cower -d pacaur
%cd pacaur
%makepkg -si

これでAURからのパッケージインストールが可能になったので、Yaourtを入れておく。 作業が明確に自動化されていたり、システマチックに行えるのならYaourtはいらないかもしれないが、 まとめて検索するためには欲しい。

% pacaur -S yaourt

必要なソフトのインストール

ここでいう「必要なソフト」は私の取り扱い上の話だ。

% yaourt -S ruby openbsd-netcat rsync mercurial postfix dovecot nginx fcgiwrap certbot certbot-nginx vim

一般ユーザーでの鍵ログインの準備

サーバーで受け入れの準備をする

% mkdir .ssh

ローカルで鍵を生成しておく。

% ssh-keygen -f ~/.ssh/conoha.rsa

~/.ssh/configに設定する。 これは名前によるアクセスを可能にするためである。 (同一ホストに対する異なる鍵でのアクセスのため、鍵を指定せずに済むようにでもある) もちろん、読み替えること;

Host conoha-root
  User root
  Port 22
  HostName conoha.site.static.cnode.io
  IdentityFile ~/.ssh/conoharoot.rsa

Host conoha
  User jrh
  Port 22
  HostName conoha.site.static.cnode.io
  IdentityFile ~/.ssh/conoha.rsa

rootでは作業できるので、転送する。

% ssh conoha-root 'cat > /home/jrh/.ssh/authorized_keys' < ~/.ssh/conoha.rsa.pub

サーバー側でパーミッションの設定を行う

% sudo chown -R jrh:jrh .ssh
% chmod go-a -R .ssh
% chmod go-a .

そしてsshdリロード

% sudo systemctl reload sshd

DNS設定

ドメインを複数持っていない場合はいきなり完全移行できなかったりするので、 一時的にサブドメインを作るなどする必要がある。

ConoHaコントロールパネルのDNSからDNSの設定を行う。 (DNSの設定ってなんだ、という者はサーバーを立てるにはまだ早い。修行してくるべし)

これは本番サーバーのものを含む。 ただし、稼働中の本番サーバーのアドレスをこの時点で変更してはならない

そして、DNSサーバーをConoHaのものに変更する。

今回の場合従来はドメインサービス提供のDNSを使用していたため、同サービスのメニューから変更を行った。

WebとLet’s Encrypt

Nginxの立ち上げとテスト

従来がDeleGateで、Nginxにするため互換性は全くない。

Nginxは単純にstartすればアクセス可能な状態だが、移行のための準備をしていく。

まずは、Archの記述に合致するようにserver-avilableディレクトリを読むようにしたほうが良いだろう。

http {
    include       mime.types;
    include       /etc/nginx/servers-avilable/*;
    ...
}

これで/etc/nginx/server-avilableを作ればそこに配置したファイルを読むようになった。 この時点でrestartすると…

Dec 19 18:45:42 archlinux nginx[9339]: 2017/12/19 18:45:42 [warn] 9339#9339: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size

とのことなので増やす。

http {
    include       mime.types;
    include       /etc/nginx/servers-avilable/*;
    default_type  application/octet-stream;

    server_names_hash_bucket_size       128;
    types_hash_max_size                 4092;
    ...
}

配置するファイルはArchwikiに従ったもので大丈夫だ。

server {
  listen 80;
  listen [::]:80;
  server_name domain.tld;
  root /usr/share/nginx/html;
  location / {
    index index.htm index.html;
  }

  # ACME challenge
  location ^~ /.well-known/acme-challenge/ {
    default_type "text/plain";
    root /var/lib/letsencrypt;
  }
}

domain.tldは適切なドメインに置き換えること。

ここで、あまり書かれていない重要なこと。

rootというのはドキュメントルートで、locationの起点となる。 つまり、

location /foo {
  root /usr/share/nginx/html;
}

であるとき、/foo/bar.htmlにアクセスすると読まれるファイルは/usr/share/nginx/html/foo/bar.htmlであって、/usr/share/nginx/html/bar.htmlではない

そのような単純なマッピングを行いたい場合はrootではなくaliasを使う。

ACME challengeはhttp://domain.tld/.well-known/acme-challenge/randomnumberに対して行われるため、 rootで正しい。

だが、このディレクトリがないので作っておいたほうが良いようだった。

% sudo mkdir -p /var/lib/letsencrypt/.well-known/acme-challenge

あとはcertbotを使えば良いのだが…

% sudo certbot certonly --email webmaster@domain.tld --webroot --webroot-path /var/lib/letsencrypt/ -d domain.tld

その前にConoHaのサーバー設定でHTTPをあけておかなくてはならない。 そして、IPv4とIPv6両方をあけておくこと。 別々になっていることに気づかず、ACME Challengeのリクエストが到達せずに(/var/log/nginx/access.logを見ても記録されていない)随分とハマってしまった。

移行作業

各ドメインごとのドキュメントルートを作り、ファイルを配置、 さらに対応したドメインごとの設定ファイルを作る。

今回の場合、Mimir Yokohamaのページは既にPureBuilder Simplyによる静的ファイルへのビルドが完了しているし、 移行対象のものに関してもPureBuilder2で静的ファイルにビルドされているものなので、単純にファイルを配置するだけの簡単なお仕事である。

Aki SIE関連のアドレスはdiscontinuedなので、301を返す。

server {
        listen 80;
        listen [::]:80;
        server_name aki-sie.com akisie.com aki-sie.yokohama akisie.yokohama;

        return 301 http://www.mimir.yokohama/;
}

http://journal.reasonset.net/に関しては301でリダイレクトしていたので、これも反映する

server {
        listen 80;
        listen [::]:80;
        server_name journal.reasonset.net;
        return 301 http://chienomi.reasonset.net$request_uri;
}

NginxのLet’s encryptの対応

メールサーバーの移行まで完了した時点で作業を行うのだが、 certbotで必要なドメインをすべて署名してもらったら、1SSL対応化を行う。

設定例は以下

server {
  listen 80;
  listen [::]:80;
  listen 443 ssl http2;
  listen [::]:433 ssl http2;

  ssl_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/domain.tld/chain.pem;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_session_tickets off;
  ssl_prefer_server_ciphers on;
  add_header Strict-Transport-Security max-age=15768000;
  ssl_stapling on;
  ssl_stapling_verify on;

  server_name domain.tld;

  index index.html;
  location / {
    root /var/www/domain.tld/doc;
  }

  # ACME challenge
  location ^~ /.well-known/acme-challenge {
    root /var/lib/letsencrypt;
  }
}

メールサーバーの移行

機能させるために一旦古い証明書で作業しているため、Let’s Encryptの証明書が取れたら証明書ファイルを変更してreload/restartすること。

Postfix

Postfixに関してはCentOS 6とArch Linuxではファイル配置が異なり、 バージョンの違いから設定ファイルの違いも大きく互換性に乏しい。

そこで、CnetOSの設定ファイルを/etc/postfix.centとしてコピーする。 このほか、/etc/alias*も忘れずに移行する必要がある。 また、一旦古い証明書ファイルもコピーした。

設定ファイルの違いを見るため、diffを取る。

% diff /etc/postfix.cent/main.cf /etc/postfix/main.cf > main.diff
% diff /etc/postfix.cent/master.cf /etc/postfix/master.cf > master.diff

このdiffファイルをkwriteで2開く。 今回はNemoのsftp機能を使って開いた。

このdiffを元に手作業で変更箇所を反映していく。 主にssl, auth, virtual関連の変更を反映する必要があった。

virtual関連のファイルは/home/mailuserにあったため、これをコピーする。 ただし、これはvirtualメールボックスを含むため、移行完了までは継続的にアップデートする必要がある。 この前にvirtual用に設定していたmailuserを設定する必要もあった。

% sudo useradd --no-create-home --uid=20000 --shell /bin/nologin --system -U -M mailuser

だが、これだけではグループが適正な値にならない。 そこで、グループIDを変更した上で、ユーザーの所属する主グループIDも変更する。

% sudo vigr
% sudo vipw

Postfixをrestartして完了。

Dovecot

Dovecotに関しては設定ファイルをコピーしてそのまま使うことができた。

Dovecotの設定ファイルとして/home/mailを使っていたので、これをコピーする。

Dovecotをrestartして完了。

上流

DNSを変更してもDNSキャッシュの関係でまだ旧サーバーにもメールが届く。 ある程度はaliasを使って転送しても良いのだが、素直にPostfixで受け取りつつ、Maildirのファイルを同期していくのが良いだろう。

DeleGateを使っていたため、DeleGateのSMTP転送機能を使う方法もあるのだが、うまく動作しなかったのと、TLS接続を受け付けることができないため、諦めた。

セキュリティ関連

複雑な話になるので省略。

そこまで難しいことをしているわけではないが、 普通の対策と、らしい対策とで簡単には突破できないようにしている。

後処理(旧サーバー)

DovecotとDeleGateは停止してしまう。

Postfixは5日程度稼働したら停止してしまっていいだろう。3

その後、バックアップ(主にログや設定など)をとったらサーバー破棄である。

おまけ: ConoHaについて

DNS

ConoHaのDNSは高速である上に非常に設定しやすい。

これまで使用していたお名前.comのもの、XDomainのものは非常に設定しづらかったので、 これだけでもConoHaにする価値はあるレベルだ。

料金

コンピューティングリソースはDTIとあまり変わらないが、料金は約倍になった。

ただし、ConoHaの柔軟性やメリットを考えればそう悪くない。 両方持つと少々負担は大きいが4、一気に完全移行したためDTIを解約でき5、許容すべきコストアップだろう。

速度

速い。

「コンピューティングリソースは大きく変わらない」といったが、速度は明らかにあがった。 特にネットワークの高速化とストレージの高速化の恩恵は大きく、Webの応答性は明確に向上した。

柔軟性

DTI VPSは色々と柔軟性が足りず、困った。 特に、OSのバージョンをあげようにもサーバーがひとつしかないので、できない。 ConoHaなら

  • インスタンスが立てられるのでサーバー仕様変更もできる
  • OSが選べる。さらにカスタムイメージのアップロードも可能
  • サーバーのアップグレードが簡単にできる(512MBプランを除く)

ファイアウォール

上流でフィルタリングしてくれるのはとても嬉しい。 設定が楽になる、というのもあるが、サーバーの耐障害性が勝手にあがる上に、まあまあ重いiptablesでの処理量が減るため、パフォーマンスが改善する。 リソースが限られている中では非常に嬉しい。


  1. Let’s Encryptの証明書はSAN(Subject Alternative Name)に 対応したもので、fullchain.pemが全てのドメインに対応したものになる

  2. Kwrite/Kateにはdiffのハイライト機能があるからだ

  3. TTLは3600だったため、それに従うならば1時間待てば良いのだが…

  4. DTIが月額500円ほど(年間6000円程度), ConoHaが900円ほど(年間10800円程度)である

  5. といっても、私はDTI SIMの契約があるため、DTIの契約そのものが終了するわけではない

ThinkPad X1 Carbon 2017 レビュー

モデル

構成

ThinkPad X1 Carbon 2017で、Core i5-7500U, 8GB RAM 128GB SATA M.2 SSD, FHDディスプレイだ。

シルバーボディで、中国生産モデルとなった。

NVMeストレージやUHD液晶を選択しなかったのはバッテリーマイレージのため、i7や16GB RAMを選択しなかったのは価格のためだ。

第8世代がきちゃったけど

KabyLakeプロセッサモデルであることについては、認識自体はあって少し悩んだ。

実際、既にCoffeeLake2プロセッサはきている。 だが、CoffeeLakeプロセッサはかなり難易度が高いということで潤沢に供給されているわけではないし、そうなると低消費電力版が出てくるのはまだ先だろう。 ThinkPad X1 2018には採用される可能性が高いが、40%以上のoffになるには半年近い時間がかかる。

そうなると、CoffeeLakeモデルをこれくらいの価格で購入できるのは半年から1年くらい後ということになり、既にラップトップが壊れた問題を抱えている私には待てないものだった。 待てる人ならば、性能向上は大きいので待ったほうがいいと思う。

インプレッション

速度

もうちょっと速くてもいいかなぁ、と思わなくはない。

SSD + Core i5という構成で性能は十分だと思うのだが、状況によってはもっさりだ。 特に、KDE Plasmaが遅いと感じることはないのだが、SATAとはいえM.2 SSDを挿している状態で起動がちょっと遅いのではないか…と感じる。 電源ポストでの待ち時間が長めに設定されているということもあるが。

起動はLinuxよりWindowsのほうが速い。 特にKDE Plasma/Cinnamonの起動はそれなりに遅い。

メイン機として使う人であればCore i7+16GBのほうが良いと思う。 この構成で「満足な速度」ではないからだ。 サブ機として考えればそんなにストレスフルなわけでもないので許容範囲かなという印象。 バッテリーマイレージと引き換えになるが、NVMeストレージを選択したほうが良いかもしれない。

Cinnamon/KDEの動作速度自体はメインのワークステーションよりも良好だ。 これはKabyLakeが持っているグラフィックアクセラレーション機能が優秀であることの現れだろう。 ドライバの出来の問題や画面の広さもあるかもしれないが、KDE Plasmaでまるでひっかかりがないのは初めての経験である。

マイレージ

私の通常作業(Wi-Fi接続で、ウェブで調べ物をしながらのタイピング。輝度は30%程度、キーボードバックライトoff、Bluetooth off)では16時間程度という感じだ。

再起動も多用するインストール/セットアップ中は6時間程度だった。

輝度を落としてWi-Fiも切れば20時間は突破しそうだし、文句なしのロングマイレージと言っていい。 素晴らしい。

トラックポイントとトラックパッド

トラックポイントはlibinputを使っているとちょっと癖のある動きをする。 少し強く触ったときの動きが大きすぎるのだ。 感度を落とすと安定するのだが、KDE Plasmaでは設定できないため、辛いところがある。

ただし、これも慣れればなんとかなた。

e440と違い、ちゃんと独立したボタンは優秀だ。 Linuxでは「中ボタンクリックができる」ことは重要だろう。

また、感触がよく広いトラックパッドは「押せるように」なってる。 これは、クリックエミュレーションではなく、本当にクリックイベントを発生させる。 ほとんどの位置で左クリックだが、右下の端でのみ右クリックとなる2ボタン仕様だ。

トラックパッドでのクリックは、ボタンクリックと比べて強くおさくてはならない。 そのため、トラックパッドの決定である「タイピング中にどこかに飛んでしまう」ということをそもそも発生させないことができる。

この問題は「トラックパッドが認識されるから」ではなく、「クリックエミュレーションの結果として意図せずクリックされて」発生する。 ThinkPad X1でもクリックエミュレーションをオンにして、軽くぽんとタッチするだけでクリック動作を発生させることは可能だが、クリックエミュレーションをオフにしても、トラックパッドをボタンとして押すことでちゃんとクリックは機能するのだ。

そのため、クリックエミュレーションを無効にしてしまえば、ありがちな「ぶっとび問題」は全く発生しなくなる。

Manjaro Linuxでは最初からクリックエミュレーションが無効の状態になっていた。

キーボード

ThinkPadのキーボードはラップトップとしてはどれも素晴らしいものだ。 だが、X1のキーボードはことさらに素晴らしいと思う。

実際に使いはじめた最初は、e440よりもクリック感が強く重いことから、ややミスタイプ(というよりもアクチュエーションポイントに到達しない空振り)が発生したが、すぐ慣れた。 ストロークはごく短いがクリック感があり、そこそこ打ちやすいキーボードというのは他にもあるが(例えばhpのSpectre13やEnvy13のキーボードだ)、やはりこのストローク感が打ちやすい。

ThinkPadの良さというか、THinkPadでなければならない大きな理由のひとつだと思う。

ネットワーク

Wi-Fi, EthernetともにIntel製だ。

少し勘違いしていたのだが、ThinkPad X1 2017にはEthernetがないわけではなく、チップとしては載っている。 単に口がないのだ。

専用の口になっており、アダプタはそこからEthernet信号を引き出すものになっている。 なお、使ってみたのだが、認識されないのかリンクがとりづらく、いまひとつであった。 重大な残念ポイントである。

スムーズな動作

コンピュータは意外と繊細で、構成の問題なのか、 「ひっかかりが生じる」ケースが割と少なくない。

店頭で展示されているPCを触ると、比較的低性能なモデルでも、自分のコンピュータよりもスムーズに動作するということが少なくない。 自作するとどうもクリーンインストール直後からメーカーPCと比べて変にレスポンスが気になる、ということがあるのだが、Lenovoのコンピュータはややその傾向がある。

国産のほうがなぜかスムーズだ…と感じるのだ。 hpやDellにもその傾向はあるが、Lenovoのほうがやや強いと思っている。

シルバーボディ

「ThinkPadらしくない」シルバーボディだが、結構ありだと思う。

いままで出たものと違い、全面がシルバーになっている。

ThinkPadはもちろん良いものであり、ThinkPadの黒も、ピーチスキンも、ThinkPadの誇りというべきものだ。

しかしながら、一般の人にとってはそうはならない。 ThinkPadの特別さを知る人は(少なくともスバル車を特別なものだと感じる人1よりも)十分にマニアだろう。

Mimir Yokohamaの仕事は一般の人を相手にするものなので、「ハッカーとしての特別さ」と同時に「普通の人が見て美しいと感じる」ことが必要とされた。 それによりThinkPadとSpectre132で悩んだのだが、その折衷案3としてシルバーのThinkPadにしたわけだ。

黒よりも滑らかな手触りと、高級感のあるシルバーは、Thinkpadファンなら(邪道だと思うかもしれないけれど)注目せざるをえないもので、そうでなくてもThinkPadを使ってきた私にとって、新鮮な気持ちで使える。 「黒がよかった」と感じることはない。

ちなみに、汚れにくく汚れも拭き取りやすい、アルコールで拭いても色落ちしにくいなどのメリットもある。

携行性

ベゼルが薄く、厚みもないため、13.3inch用のZeroShockラップトップバッグに収納可能であった。

1.1kgという重量は軽く、今まで使用していたThinkPad e440 (2.1kg)はおろか、Dynabook R51 (1.4kg)と比べても明らかに軽量で携行性は良い。 さすがにPavilion x10(970g)と比べれば若干重いが。

ただし、コンパクトなラップトップ収納スペースを持つものは13.3inch用が多く、Macbook Airなど13.3inchでも薄いものを想定していてうまく収納できないケースがある点には注意が必要だ。 実際、13.3inchと比べるとfoot printは大きい。

形状としては持ちやすく、重量配分も安定していて非常に持ちやすい。

スリープ安定性

実はLinuxだと「スリープから安定して復帰できるか」というのは構成次第の結構な運の問題である。4

ThinkPad X1 Carbon * Manjaro Linux5では問題なくスリープ/復帰できている。

結論

素晴らしく良い。 満足だ。


  1. クルマにおけるスバルや、ラップトップにおけるThinkPadは一種の憧憬の対象となっている。それは、それが「好きかどうか」とは別のこととしてだ。

  2. hpの個人向け高級ラップトップ。ちょっと高めだけれど、性能的にも良好で優れたデザインを持つ。2018年モデルは色が白になってしまい、だいぶ普通になってしまった。残念。

  3. hackerのThinkPad(ただしThinkPadらしくない)とSpectreのような美しさ(しかし遠く及ばない)である

  4. もちろん設定はできるが、設定したところでそれなりの確率で復帰できないものはあり、設定しても依然として復帰できないケースもある(特にAMD製ビデオカードにCatalystドライバを使用している場合は非常に多かった)。

  5. Manjaro XFce 17.06 x86_64 Linux 4.14.4 * KDE Plasma workspace環境である。Cinnamon, XFceでも安定してスリープから復帰できている。

サーバーを使った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製のチップを採用したものがあるようで、 これらはプロプライエタリドライバがあるほか、プロプライエタリドライバを(手動で)導入しなくても動作するディストリビューションもあるようだ。