CategoryTech

Google Compute Engine 上で WordPress インスタンスを走らせる

このブログはもともとさくらのレンサバ上で動かしていたのだが、小さなブログひとつのためにレンタルサーバーを維持するのはオーバーキルだなという感じがしてきたので Google Compute Engine に移してみた。

移行は容易であった。cloud.google.com から自分のダッシュボードへ行き、Cloud Launcher から Bitnami の提供する WordPress パッケージを選ぶだけ。あとは古い WordPress からデータを移行して、ドメイン名からのひも付けを再設定すれば終了だ。

今のところ3日間利用して $0.5 しか課金が発生していない。ステマになってしまうが素晴らしいサービスである。

HTTP/1.1 が更新された

HTTP/1.1 just got a major update という記事が Hacker News 一面に出ていた。さっと訳す。正確性は保証しない。


IETF は、 HTTP/1.1 を更新するいくつかの新しい RFC を発表した。

RFC 7230: Message Syntax and Routing
RFC 7231: Semantics and Content
RFC 7232: Conditional Requests
RFC 7233: Range Request
RFC 7234: Caching
RFC 7235: Authentication
RFC 7236: Authentication Scheme Registrations
RFC 7237: Method Registrations
RFC 7238: the 308 status code
RFC 7239: Forwarded HTTP extension

これらは、従来の HTTP/1.1 を置き換えるものである。HTTP オタクとしては大事件だ。

15 年前に書かれた RFC 2616 こそ、皆が実装してきた仕様であり、読者もよく参照として利用してきただろう。

HTTPBis グループはこの仕様を少なくともここ7年間この仕様をアップデートする作業に費やしてきた。HTTP ほど後半に使われているプロトコルには様々なステークホルダーがおり、充足しなければならない意見も多くあったことが想像される。

まだ開発中の HTTP/2.0 も、これらの RFC を参照し、すべての定義をスクラッチから始めるよりも、これらの書類に単にリンクするだろう。

ここ数年、私もこれらの新しい使用書類のドラフトを使ってきた。元のものよりも参照しやすくなるのに時間がかからなかったからだ。

何が変わったか

最大の差異は、古い仕様と比べて、単純に文章量が多いということだ。理解しやすく、読みやすくなり、曖昧さもなくなった。

それから、仕様の核が6つの異なった仕様書に分割された。昔は HTTP のために RFC 2616 が、Basic および Digest 認証のために RFC 2617 があるだけだった。

この2つだけでも、API の作成者が仕様書を最初から最後まで読む意味はある。学ぶことはたくさんあるだろうし、よりよい HTTP API デザインへのインスピレーションが得られるだろう。

それから、308 ステータスコードが新しいスタンダードになった。これは4つ目のリダイレクト ステータスで、永久的なリダイレクトを意味する。308 を受け取ったクライアントは、リダイレクトをたどり、全く同じリクエストを行うことが期待されている。これは、クライアントが通常メソッドを GET に変更する 301 リダイレクトとは少し異なる。

RFC 7239 は Forwarded ヘッダーを標準化する。これは、 X-Forwarded-For や X-Forwarded-Proto などのヘッダーを置き換えるものだ。

以下、変わったことの全く網羅的ではないリスト。

  • 不意のホワイトスペースへの対処の明確化。これは HTTP レスポンス分割の脆弱性を解決するはずである。
  • サーバーあたりの接続数限界が排除された。
  • HTTP/0.9 のサポートがなくなった。
  • ISO-8859-1 のデフォルト charset がなくなった。
  • サーバーは、すべての Content-* ヘッダーを取り扱う必要がなくなった。
  • PUT リクエストでの Content-Range が明確に禁止された。
  • リファラーが存在しない際、Referer ヘッダーには about:blank を利用することが推奨されている。これは、「リファラーがない」と「リファラーを送りたくない」を区別するためだ。
  • 204, 404, 405, 414, 501 ステータスコードがキャッシュ可能になった。
  • 301 と 302 ステータスコードは、POST から GET へユーザーエージェントがメソッドを変更することを許容するように変更された。これは、皆が(間違って)既に実装していたもので、仕様側で実際の運用に沿うように変更を行ったものだ。
  • Location ヘッダーは、フラグメント アイデンティファイアと相対的 URI を含むことができる。
  • Content-MD5 がなくなった。

他に何か面白い変更があれば教えてくれ。

参照

さくらの VPS に Ubuntu 12.04 をインストール

もうちょっと Linux について知りたいと思ってさくらの VPS を契約したので、勉強のためいじっていこうと思う。初期では CentOS が入っているので、これを Ubuntu 12.04 に変更する。以下、覚書。

環境

  • MacBook Pro Retina 13″
  • OS X 10.9.1 Mavericks

手順

  1. Java Runtime Environment 6 を用意する。最新は 7 なので、すでに最新バージョンがインストールされている場合、Apple のヘルプ記事 に従ってダウングレードを行う。
  2. さくらの VPS コントロールパネルにログイン。この際、Safari を使うのが良いようだ。
  3. OS再インストール > カスタムOSインストール > Ubuntu 12.04 amd64 を選択。確認、実行をクリックする。
  4. Java 実行環境が起動するのを待つ。ダイアログが出る場合、確認とか、実行とか書かれている方をクリックする。
  5. あとは、さくらのヘルプ記事 を参考に進めていけば良い。

特に、Java Runtime Environment のバージョンが 6 でなければならない、というのが躓きやすい点だ。また、サブネット・マスクを 255.255.254.0 に設定することを忘れずにおこう。

ssh config

ufw で ファイアウォールを設定。ssh のアクセスを許可しておく。

$ sudo ufw enable
$ sudo ufw default DENY
$ sudo ufw allow ssh

ssh-keygen で鍵を生成し、アップロードして、authorized_keys にする。この辺は さくらVPSでのセキュリティ関係の設定(Ubuntu)- ウェブ、ショウジン とかを参照した。

最後に、パスワード認証によるログインを不可にしておこう。これで大体は安心である。

vim

デフォルトではいろいろ入っていないので、 sudo apt-get install [package] で入れていく必要がある。

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install vim

わたしの .vimrc は晒すほどのものでもないが、ググると色々出てくる。とりあえず、Vundle は入れておこう。

$ git clone https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle

golang

何も考えずに

$ sudo apt-get install golang

したが、これで入る go のバージョンは少し古い 1.0 であった。最新のものを入れるために gvm (Go Version Manager) を導入するとよい。

$ bash < <(curl -s https://raw.github.com/moovweb/gvm/master/binscripts/gvm-installer)
$ gvm install go1.2
$ gvm use go1.2

GOPATH、GOROOT も各自設定される。便利。依存関係があるので、適宜 apt-get で入れていこう。

あとは、

$ go get github.com/nsf/gocode

とか。続く。

PageSpeed Insights によるモバイル分析 (勝手訳)

Google のモバイルに関するスピード向上のためのガイドラインである Mobile Analysis in PageSpeed Insights の一部を適当に訳したので公開する。これは個人的なもので内容の正確性とかは一切保証しないので注意してくれ。


PageSpeed Insights によるモバイル分析

PageSpeed Insights では、モバイルネットワークという劣悪な環境においてページを1秒以下で読み込むにはどうすればよいか、Google の推奨事項に基いて改善点を分析することができる。分析によれば、ページの読み込みに1秒以上かかってしまうと、ユーザの思考の流れは一旦絶たれてしまうという。これでは快適なネットサーフィンとは到底言えない。重要なのは、ユーザーがまだページに興味を抱いている間に、どんなネットワーク上でも最善の体験を提供すること、これだ。

もちろん、1秒以下というのは簡単なことではない。しかし朗報だ。ページのすべてを1秒以内に表示しなければならない、というわけではないのだ。その代わりに、Above-the-fold (ATF) と我々が呼ぶ、画面に最初に表示され、ユーザーの視野に最初に入ってくる部分を1秒で表示すればいい。あとは、ユーザーがそれを読んでいる間に、他の部分をレンダリングしてしまえば良いのである。

モバイルネットワークは遅い

どんなネットワークにも1秒以下で対応する、というのは並大抵のことじゃない。4G や 3G、あるいは 2G のどんなネットワークからもユーザはやってきうる。もちろんだがモバイルは遅い。はるかに遅い。我々は ATF コンテンツを1秒、つまり 1000 ms で表示したいのに、ネットワークのせいでかなりの時間を食ってしまう。一回ののラウンドトリップに、これだけの時間がかかってしまうのだ。

  • 3G なら 200-300 ms
  • 4G なら 50-100 ms

今のところ世界で一番メジャーなのは 3G だ。たしかに 4G も徐々に導入が進んできてはいるが、平均的なユーザーは 3G を利用していると考えるべきだろう。つまり、リクエスト1回につき、平均で 200 ms、0.2 秒かかると見積もるのだ。

そう考えると、DNS ルックアップで 200 ms、TCP ハンドシェイクのためのラウンドトリップでもう 200ms、そして実際の HTTP リクエストとレスポンスで 200ms かかるわけだ。もう 600 ms = 0.6 秒も経過してしまった。あと 400 ms しか残っていないではないか!

それでも1秒未満を達成するのだ

あとたった 400 ms でどうしろっていうんだ?サーバー側でレスポンスを生成し、クライアントサイドのコードを実行し、ブラウザーでコンテンツのレイアウトとレンダリングを行わなくてはならない。我々の野望は潰えたのか?いや、そうではない。こうすればいい:

  1. 200 ms 以下でレスポンスを返す: サーバーが最初の HTML を返すまでの時間からネットワークの転送時間を引いたものがサーバーレスポンスタイムだ。我々には時間がないので、これはできるだけ小さくしよう – 200 ms 以下が理想だ。

  2. リダイレクトの数の最小化: ひとつ HTTP リダイレクトを入れるたびに、ラウンドトリップをひとつかふたつふやすことになる(DNS ルックアップが必要ならふたつだ)。すでに見たように 3G 回線ではこれは致命的だ。その時点で数百 ms のハンデである。リダイレクトはできるだけ排除しよう─無くせるなら無くした方がいい。特に HTML 文書に関しては特に重要だ (“m.” とか “touch.” とかはクールじゃない)。

  3. ラウンドトリップの数の最小化: TCP がコネクションのキャパシティを予想するやりかた(スロースタート)のせいで、新しい TCP コネクションはクライアントとサーバーの間の帯域をフルで使うことができない。このせいで、サーバーは新しい接続の最初のラウンドトリップで最大 10 の TCP パケット (~14KB) を送ったあと、輻輳ウィンドウを拡大させ更なるデータを送信するためにクライアントがそれを確認するのを待たなければならない。この挙動を考えれば、ラウンドトリップの数を最小化するために、理想的には、ATF 内のコンテンツは 14KB 以下であるべきだ。そうすれば、たった一度のラウンドトリップでページを描写できることになる。それから、この「10パケット」という数字は最近のアップデート (IW10) で TCP 規格に追加されたものだということも知っておこう。もしこのアップデートにサーバーが対応していなければ、おそらく限界は 3-4 パケットだ。

  4. Above-the-fold 内の JS と CSS をインライン化する: ページをパースしている最中に非同期コードや外部スクリプトに出会ってしまうと、ブラウザは一旦パースを中止してそのリソースをダウンロードしなければならない。そのたびにラウンドトリップが増え、ページのレンダリングを遅くする。
    だから、ATF 内に表示される JS と CSS はインライン化するべきだ。補助的な機能をページに追加する JS や CSS は、ATF コンテンツが表示されてからロードすれば良い。

  5. ブラウザ側でコンテンツをレイアウト&レンダリングする時間を残す (200ms): HTML と CSS をパースして JS を実行するのには時間がかかるし、クライアント側のリソースを使う。デバイスの速度とページの複雑さに応じて、数百 ms かかってしまうことがある。このオーバーヘッドのために 200 ms 残しておこう。

  6. JS の実行 & 表示時間を最小化する: 複雑なスクリプト、非効率なコードのせいで数百 ms かかってしまうことがある。デベロッパーツールをうまく利用して、コードを最適化せよ。 Chrome Developer Tools のインテラクティブコース を受講するのがおすすめ。

注意:もちろん、これはすべての最適化の網羅的なリストではない。パフォーマンスチューニングのためにできることは他にもいろいろある。詳しくは PageSpeed Insights をチェックせよ!特に以下がオススメ。

FAQ

  • 4G だとどうなんよ?

4G マジオススメ。ラウンドトリップのレイテンシが減る。見りゃわかるけど 3G では1秒の半分以上がこのせいで使われてるわけだからな。でも、上で書いたけど、ネットワークとしては今でも 3G が主要だから、かわいそうな 3G 民のことをちゃんと考えてやってくれ。

  • jQuery 使ってるんだが。

うん、そういう JS ライブラリを使ってる奴が多いのはわかる。色々と機能とかアニメーションとか追加できて捗るよな。しかし、こういうことは ATF コンテンツを表示させてからロードすればいいのだ。JS を実行するタイミングを再考せよ。

  • JS フレームワークを使ってるんだが。

コンテンツが JS を利用してクライアントサイドで生成される場合は、まず、JS をインライン化して無駄なラウンドトリップを減らせ。それから、サーバーサイドでレンダリングを行うことで最初のページロードのパフォーマンスは上がる。JS テンプレートはサーバー側でレンダリングし、結果を HTML にインラインで挿入、その後アプリがロードしてからクライアントサイドテンプレートを利用せよ。

  • SPDY とか HTTP 2.0 とかについて詳しく

どちらも TCP 接続をより効率化することでページロードのレイテンシを減らすために努力している。多重化とかヘッダ圧縮とか優先制御とか。SPDY にまず対応し、時が来たら HTTP 2.0 にスイッチするのがオススメだ。

  • どの CSS が一番重要なのかわからん

クロームデベロッパーツールを使え。捗るぞ。

  • めんどくさいから自動化できんのか

おう、商用のものも、オープンソースのものも、ウェブパフォーマンス最適化のための製品はいろいろあるぞ。具体的には このページ を見れ。

  • どういうふうにサーバーをチューンしたらいいんだ?

まずサーバーが最新の OS を走らせていることを確認しよう。TCP の輻輳ウィンドウの拡張 (IW10) に対応するためには、Linux kernel 2.6.39 以上が必要だ。ほかの OS についてはドキュメントを見れ。
サーバーレスポンスタイムの最適化については、何がボトルネックになっているのかを診断するためにアプリケーションモニタリングのためのソリューションを導入すれ。スクリプトの実行なのか、データベースコールなのか、RPC リクエストなのか、それともレレンダリングなのか…。いいか、目標は 200 ms だぞ。

  • Content Security Policy

CSP を使っている場合は、デフォルトのポリシーをアップデートする必要があるかもしれない。

まず、HTML 要素内の CSS 属性を避ける。不必要なコードの重複に繋がるし、CSP を利用しているとデフォルトではブロックされる。JS をインライン化する場合は、ポリシーに “unsafe-inline” を追加して実行を許可する必要がある。デフォルトでは全部ブロックだからな。


以上だ。誤訳があったら教えてくれ。

Markdown エディタ Mou.app がすごい

しばらくのところ新しいエディタを導入するということはしてこなかった。基本的には Scrivener.app を論文作成には利用し、あとは場合に応じて CotEditor.app や Microsoft Word などを使ってきた。けれども最近、発見と共にわたしのエディタ利用率トップに躍り出たアプリケーションが存在する。それが Mou.app である。

Mou.app

仕組みも使い方も簡単。ウィンドウは二分割になっており、左側に Markdown 記法でテキストを書き込むと、右側にパースされた状態のものがリアルタイムで表示される。リンクやテーブル、画像もきちんと表示してくれる。スタイルはプリセットのものが三種類あるほか、 CSS を書くことで自分好みにカスタマイズすることも可能だ。プリセットのものでもとても美しく処理を行ってくれるので、何も変えずにわたしは使っている。

その他にも機能はいろいろだ。日本語で文章を書いている人間にとっては、縦書きで使えると言うこともちょっとした魅力だろう。わたしにとってはなにより、HTML 書き出し機能が有難い。見えているそのまま WYSIWYG で美麗な HTML を書き出してくれるので、とても有難い。早速今書いているレジュメを Markdown で書いて HTML 化してみた。

Mou.app 使用例

以前ははてな記法のほうが慣れていたということもあって、Markdown 記法はあまり使っていなかったのだが、最近はずいぶんと対応のものが増えてきたので、あまりはてな記法を使うと言うことがなくなってきてしまった。はてな記法と Markdown 記法がどちらも利用できるエディタなどあれば嬉しいなと思う。

キー・リマップのススメ: KeyRemap4MacBook がすごい

英国で購入した MacBook Air。当然、キーボード配列は British である。実のところアメリカのキーボードとは随分と勝手が違っており、良いところもあるのだが、一方で改善したいことも随分とあるので、KeyRemap4MacBook の機能拡張をインストールしてみた。British キーボードを利用している日本人向け、という比較的少ない人々を対象にした記事だけれども、その他のキーボードを利用している方にもお勧めだ。

同じようで結構 US 配列とは異なっている

以前からしていたことは、コントロールキーとキャップスロックキーの入れ替え。これは購入して即行った。これは US キーボードでも同じだが、あまり使わない Caps Lock が A のすぐ左の押しやすいところにあるのに、しょっちゅう必要になるコントロールキーが左下の押しにくいところにある。これはかなりの損失なので、システム環境設定の「キーボード」を開いて「修飾キー…」をクリックすると入れ替えることができる。

さて、それ以外にも、KR4M のおかげでかなり快適にタイプすることができている。設定というものがここまで大事だったとは思っていなかった。キイをタイプする減らすことでかなり快適になるものだ。まず、British 配列では「英数・仮名」のキイが存在しないので、右のコマンドキーを「かな」に、左のコマンドキーを「英数」キーに設定した。もちろん、普段はコマンドキーとして利用することができる。これでコマンド+スペースをいちいち押す必要がなくなるので、英字と日本語のタイプを行ったり来たりする際に非常に便利だ。

また、British 配列では US 配列で # があるところに £ (ポンド記号)があり、プログラミングなどする際に不便であるので、左上にあるセクシヨン記号をそのまま#にしてしまうオプシヨンを有効にした。これでぐっと操作性がよくなった。ついでに、左のシフトの右隣にある ~ キーを、シフトに変更してしまうと言うこともできる。実はこれがある分 US 配列よりキーがひとつ多く使えて、カスタマイズする分にはよいのだが、しょっちゅうシフトを押さなければならない場合は小指を気持ち左に広げなければならないのでむしろ不便なのだ。

英国配列利用者のためのオプションが用意してある

設定は様々なキーボードのために用意してあるので、あらゆるユーザにお勧めできる環境設定だろう。

巷で噂のフォント Ricty を Mac で生成し利用する

プログラミング用フォント Ricty は、英字フォント Inconsolata と日本語フォント Migu 1M を合成させた、美麗な等幅フォントで、エディタでの利用に向いている。しかし、ライセンスの関係で TrueType 形式での配布がなくなり、自分で材料を用意しなくてはならなくなった。Ricty は利用したいけどこういう UNIX っぽいことには明るくないという私にような人だって数多くいるはずであるから、参考にしたい方もいるだろうと考えて、覚書を残しておく。

環境

  • MacBook Air 11″ (Mid 2011)
  • OS X 10.7 Lion
  • XCode インストール済み

材料を用意する

  • Inconsolata のウェブページから OpenType 形式のファイルをダウンロードする
  • M+とIPAの合成フォント のウェブページから Migu 1M の TrueType 形式ファイルをダウンロードする
  • 前述の Ricty ページから生成スクリプトをダウンロードして解凍しておく
  • 解凍されたフォルダ Ricty に、既に用意しておいた Inconsolata と Migu 1M のファイルを移動させる

Homebrew 経由で FontForge を入れる

Homebrew は、MacPorts の代替手段として開発されたパッケージ管理システムである。フォント生成プログラムである FontForge をインストーするために必要となる。

  • Homebrew をインストール – ターミナルを起動させ、ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)" を実行
  • FontForge をインストール – そのままターミナルで brew install fontforge を実行
  • 終了まで待つ – コーヒーでも飲もう

スクリプトを実行してフォントを生成する

以上のインストールが終わったら、ターミナルで先ほど作成された Ricty フォルダへ移動し、sh ricty_generator.sh Inconsolata.otf Migu-1M-regular.ttf Migu-1M-bold.ttf を実行させ、先ほど入れたコーヒーを飲みながら少し待てば Ricty の完成である。後は、ダブル・クリックして Font Book を起動させ、インストールを完了させればよい。

新しい Mac に導入するソフトウェア: MacBook Air 11″ を購入した

先週発売されたばかりの新しい MacBook Air 11″ を購入した。カスタムなしの128GB版。イギリスで購入すると、キーボードの配列が多少異なる。私は以前から British を使っているので、こちらの方が手になじむ。

The new MacBook Air 11"

ひとことで言うと、すばらしい。とても軽いし、動作も速い。音楽や動画などは入れるつもりはないが、メディア・センターとしてもさくさく動いてくれそうだ。

移行アシスタントは利用せず、データは Dropbox で同期し、あとはソフトウェアを少しずつ入れていく方式をとった。以下、導入したものをリストアップしていく。

ネットワーク関連

  • Dropbox – 言わずと知れたファイル同期アプリ。これで重要なファイルはほぼすべて同期することができた。無料。
  • Google Chrome – メインブラウザは Safari を今のところ利用しているが、やはり Chrome も便利である。無料。
  • SafariStand – Safari の機能を拡張するプラグイン。パッケージによるアプリケーション拡張プログラムである SIMBL が必要なので、先にインストールしておくこと。
  • Twitter – Twitter のオフィシャル・アプリ。以前よりもかなり使い勝手がよくなった。無料。
  • Evernote – メモアプリとしてはかなり秀逸。後述の Reeder からの共有がかなり便利。無料。
  • Reeder – RSS Reader の決定版と言ってよい。各自ソーシャルネットワークへの共有も一瞬でできる。問題は、はてなブックマークへの共有をサポートしていないこと。850円。
  • Skype – 友人との会話や会議のために。ここのところかなりインターフェースや機能が改善されてきた。無料。
  • Transmit – 最強の FTP アプリ。Cyberduck はいまいち信用ならない場合が多い。2950円。
  • マカロン – 2チャンネルブラウザ。マカー用。が開発終了になってしまったので、その後継であるマカロンを利用している。よりモダンで Aqua ライクなものもあるのだが、2ちゃんねるを見るときはなんやかんやでこちらの方がしっくりくる。無料。

ユーティリティ

  • The Unarchiver – 万能解凍ソフト。無料。
  • AppCleaner – 関連ファイルもアプリケーションと同時に削除させてくれるアンインストール用アプリ。類似アプリは数多くあるがかなり便利。無料。
  • CotEditor – 軽量で良質なテキストエディタ。ちょっとしたテキスト編集やコーディングはこれでばっちり。無料。
  • ClipMenu – クリップボード履歴管理ソフト。以前コピーした文章や画像が履歴として残る。無料。
  • Sketchbook Express – ドローソフト。非常に高機能で、プロ版もあるが私のような人間にはエクスプレス版で十分である。無料。
  • Wunderlist – タスク管理ソフト。Things や Omnifocus といったアプリケーションが有名だが、これは無料で、iPhone 版や Android 版も提供されている。Web アプリケーションも存在する。すべて無料。
  • Day One – 日記ソフト。Web サイトのデザインも秀逸。iPhone 版もあり、Dropbox を利用して簡単に同期することができる。850円。
  • ATOK 2011 for Mac – ことえりも相当熟成してきた感じはあるが、やはりATOKには勝てない。キーバインドはことえり風にしているが。年額3000円で利用できるのはありがたい。月額では315円。
  • Jumsoft Money 4 – 金銭管理ソフト。iPhone用もあり、使ったお金をその場で記録しておくことができる。かなり便利である。今なら1650円。
  • KeyRemap4MacBook – キーボードカスタマイザ。英国配列であるので、いろいろといじくっている。コマンドをかな・英数として利用したり、#を素早く入力できるようにしたり。かなり便利である。無料。
  • XCode 4 – 言わずもがな。無料。

論文用ソフト

  • LibreOffice – フリーのオフィス・スイート。基本的には Office 2011 を買う必要はなさそうである。
  • Papers 2 – 文献管理ソフト。論文はもちろんのこと、アップデートで書籍データも入れておくことが可能になった。これで、論文を書く際の引用文献は完全に Papers を利用すればよいこととなった。以前は Zotero や BibTeX を利用していたが、修士論文は TeX を利用しないことも検討したい。学生割引で 5000 円ほど。
  • Scrivener – 筆記ソフト。こちらに pdf を入れておくこともできる。メモは Evernote に書き、下書きとしてこちらに移す、というプロシージャである。3900円。

さしあたっては以上である。ランチャなどは特に入れなくてもよいと思われる。Spotlight があれば基本的にそういったたぐいのソフトウェアは必要ない。ほか、キーバインドの設定などを多少いじり、現在は非常に快適に動いている。

[追記 07/26 BST 18:00]パッケージ管理システム Homebrew や FontForge そして Ricty をインストールする様子を巷で噂のフォント Ricty を Mac で生成し利用する | The Long Wait で記述した。

WordPress へ移行した

結局 MT は耐えられず、Wordpress へ移行することにした。やはり使いやすくてよい。はてなスターの設置も完了した。インストールしたプラグインは次の通り。

テーマはできるだけシンプルなものを選んだが、ごてごてしているものが多くて困っている。快適に本文が読めればそれでいいのだが、素直にテキストを綺麗に表示するだけのテーマが無い。少し困っている。次善の策として現在のものを選んだが、違和感は多少ある。もっとよいものが見つかればいいのだが…

Movable Type?

ロリポップが月105円でレンタルサーバーを提供している。このブログもそのプランを利用しているのだが、この場合、「簡単インストール機能」で利用できる CMS は Movable Type しかない。そもそも、このプランでは MySQL が利用できないので、自分で WordPress をインストールしようと思ってもできないのだ。という訳で、今のところこのサイトは Movable Type で運用している。

MT に触るのは初めてだったので、いろいろと調べてみよう、と思って Google 先生と対話を続けていると、MTに未来はあるのか – Using MT という記事にヒットした。このブログによれば、MT が利用されているのは主に日本語圏で、世界的には WP がマジョリティになっているということ。まあそうだろう。

決してマジョリティだからいいという訳ではないのだが、プラグインの豊富さやいざというときのサポートなどを考えると、やはり WP の方がよいのだろう。しかし MySQL を利用するためには月263円のプランにアップグレードする必要がある。倍以上の出費である。そこまでして WP にする必要があるのだろうか?文章を書けて、そこそこ美しく見えればいい、それだけのブログのために…

© 2017 The Long Wait

Theme by Anders NorénUp ↑