無印吉澤

Site Reliability Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

Amazon Linux, RHEL, CentOS での pip のインストール方法の違い

f:id:muziyoshiz:20171120220420p:plain

やらかした話

Amazon Linux は Red Hat Enterprise Linux (RHEL) をベースに開発された Linux ディストリビューションです*1。しかし、古い RHEL 5〜6 をベースにして、その後の開発は分岐しているため、パッケージ管理の方法などには違いがあります。

RHEL や CentOS では、EPEL を使って pip をインストールしても最新版にならず、pip install -U pip (pip install --upgrade pip) を実行する必要があります。

しかし Amazon Linux には独自の yum repository があるため、以下のように yum で最新版にアップデートできます。

$ sudo yum update python27-pip

しかし、それを忘れていて、Amazon Linux 上でつい

$ sudo pip install -U pip

としたところ、/usr/bin/pip が削除されて、新しい pip が /usr/local/bin/pip にインストールされてしまいました。ぐぐってみたら、同様の報告が Stack Overflow にもありました。

stackoverflow.com

「もしかして、これって最新の RHEL や CentOS でも同じことになるんだろうか?」と思って、EC2 上で検証してみました。

検証結果

結果を先に言うと、RHEL や CentOS ではそうなりませんでした。

  • Amazon Linux AMI 2017.09.1

    • 最新の pip が入っており、これ以上アップデートできない(Python 2.7.12, pip 9.0.1)
  • Amazon Linux AMI 2017.03.0

    • Python 2.7.12, pip 6.1.1 がインストールされている
    • pip は alternatives で管理されており、/usr/bin/pip は /etc/alternatives/pip へのシンボリックリンク
    • pip install -U pip を実行すると、/usr/bin/pip は削除され、/usr/local/bin/pip にインストールされる
    • yum update python27-pip でアップデートすれば /usr/bin/pip のままで pip 9.0.1 になる
  • Red Hat Enterprise Linux 7.4 (HVM), SSD Volume Type

    • Python のバージョンは 2.7.5 で、pip はインストールされていない
    • yum install epel-release で EPEL をインストールできず、rpm ファイルをダウンロードしてインストールする必要がある
    • yum install python-pip で pip 8.1.2 がインストールされる
    • インストール先は Amazon Linux と同じ /usr/bin/pip
    • pip install -U pip を実行すると、パスは /usr/bin/pip のままで pip 9.0.1 にアップデートされる
  • CentOS 7 (x86_64) - with Updates HVM

    • Python のバージョンは 2.7.5 で、pip はインストールされていない
    • yum install epel-release で EPEL をインストールできる
    • これ以降は RHEL と同じ

補足:現時点の最新バージョンは Python 2.7.14, pip 9.0.1

まとめ

結論としては、Amazon Linux では pip install -U pip しちゃ駄目ですが、他の Red Hat 系だと特に問題ない(むしろ yum では最新版が入らない)みたいです。Amazon Linux の pip は alternatives で管理されていることが影響しているんでしょうか?

Qiita で同様の症状がいくつか報告されていて、これらはどうも Amazon Linux ではなさそうですが、これ以上は深入りしないでおきます。

この件を Python に詳しい同僚に話したところ、yum が Python 2 で動作する関係で、RHEL や CentOS ではなかなか Python のバージョンを上げられないという事情もあるそうです。

pip は Python 3.4 以降に標準添付されていますが、RHEL や CentOS でその恩恵が受けられるのは当分先になりそうですね……。

おまけ(1):今回の検証に使った AMI

f:id:muziyoshiz:20171120220437p:plain
f:id:muziyoshiz:20171120220448p:plain
f:id:muziyoshiz:20171120221007p:plain

おまけ(2):そもそものきっかけ

今回そもそも何故 Amazon Linux で pip をアップデートしようとしたかというと、こんな経緯でした。

pyenv や virtualenv を使っていれば、今回みたいな目には遭わないと思います。Ansible で使いたいだけだから、と手抜きしたのがよくなかったですね。

Ansible が Python に依存してるせいで、ときどきどうでもいいところでつまづく気がします(今回のは完全に自業自得ですけど)。運用管理ツールを Go で作りたくなる人の気持ちが最近よくわかります……。

*1:AWS Developer Forums: Amazon Linux AMI - what distro is this based on? での Ben@AWS の回答によると、Amazon Linux は RHEL 5.x と、RHEL 6 の一部を元にしている。

Nginx でリバースプロクシを立てるときに気にすべき proxy_next_upstream 設定

f:id:muziyoshiz:20171026000347p:plain:w400

個人的に、Nginx で「これは危険だ」と思っている設定があって、Nginx でなにかあるたびにその設定をつい疑ってしまいます。その設定について他の人に話すたびに、いちいち資料を集めるのが面倒になってきたので、今回はその設定項目についての情報をまとめておきます。

まだ理解に自信がない部分があるので、新しい情報が入ってきたら、この記事を適宜修正します。

リバースプロクシ設定の基本

Nginx をリバースプロクシとして使う時には、ngx_http_upstream_module でサーバのグループを定義します。そして、サーバ名やロケーション(パス)に対して、送信先のグループを指定します。

以下はマニュアルにある例です。その Nginx サーバへのすべてのアクセスを、backend グループに指定されたいずれかのサーバに送信します。

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

この送信に関わる設定は、proxy_pass を含む ngx_http_proxy_module の方にあります。このモジュールの設定のなかで、(僕が個人的に)よくつまづくのが proxy_next_upstream から始まる設定です。

proxy_next_upstream から始まる設定

これらは、upstream(リクエストの送信先)からエラーが返されたり、リクエストがタイムアウトした場合の動作に関する設定です。

  • proxy_next_upstream
    • 失敗したリクエストを他のサーバに再送する条件(複数指定可)
  • proxy_next_upstream_timeout
    • Nginx 側でリクエストがタイムアウトしたと判断するまでの時間
    • proxy_next_upstream で timeout が指定された場合のみ、この設定が使われる
    • 時間の単位は Configuration file measurement units を参照
  • proxy_next_upstream_tries
    • proxy_next_upstream の条件に合致したリクエストを、最大で何台のサーバに送信するか
    • マニュアルには明示されていないが、この送信回数は最初の1台を含む
      • 1が設定されたら、最初のサーバ1台にしかリクエストを送信しない
      • 3が設定されたら、最初のサーバ1台への送信と、それ以外の2台への再送を行う

これらの設定が明示的に指定されなかった場合のデフォルト値と、その意味は以下の通りです。

  • Default: proxy_next_upstream error timeout;
    • 何らかのエラーが発生した場合、または Nginx 側でリクエストがタイムアウトした場合に、リクエストを再送する
    • ここで言う「エラー」とは、(転送先)サーバへの接続時、リクエストの転送時、またはレスポンスヘッダの読み込み時に発生するエラーのこと
    • 4xx 応答、5xx 応答は、ここで言う「エラー」には含まれない
  • Default: proxy_next_upstream_timeout 0;
    • Nginx 側でのタイムアウトは起こらない(0 は無制限を表す)
  • Default: proxy_next_upstream_tries 0;
    • upstream ディレクトリで定義されたすべてのサーバに対して順番に、エラーが発生したリクエストを再送する(0 は無制限を表す)

不適切な設定が問題になるケース

proxy_next_upstream_tries を指定せずに使っていると、バックエンドのサーバへの接続で何らかのエラーが発生したら、最悪の場合、そのリクエストはすべてのサーバに対して送信 されます。

例えば、以下のような状況になると、無駄なリクエストが Nginx で大量に増幅されて、システム全体の負荷が急増します。

proxy_next_upstream 設定を何も指定していない状態で、
→ アプリケーションサーバが何かのバグで不正なレスポンスを返すようになる
→ そのバグを踏むリクエストが来る
→ そのリクエストがアプリケーションサーバの台数だけ複製される(サーバ10台なら10倍になる)
→ システム全体の負荷が急増

また、proxy_next_upstream_timeout だけ設定していると、こういうこともあり得ます。

proxy_next_upstream_timeout が2秒に設定されていて、proxy_next_upstream_tries は未指定の状態で、
→ 処理時間が2秒を超える重いリクエストが来る
→ その重いリクエストがアプリケーションサーバの台数だけ複製される(サーバ10台なら10倍になる)
→ システム全体の負荷が上がって、普段は2秒未満のリクエストも2秒以上かかるようになる
→ それらのリクエストも10倍に複製される
→ システム全体の負荷が急増

あるべき設定

個人的に考える、あるべき設定は以下の通りです。

proxy_next_upstream_tries は必ず0以外に設定する

この値がデフォルト値の0(無制限)でさえなければ、上記のような問題は起こらないので、まずこれを設定します。

1にすれば再送は起こりませんが、アプリケーションサーバを再起動するような場合にいちいちエラーが出てしまいます。再起動の場合のみを考えるなら、この値が大きすぎても意味はありません。そのため、proxy_next_upstream_tries は2〜3でいいと思います。

proxy_next_upstream_timeout はアプリケーションサーバ側の応答時間より長くする

proxy_next_upstream_timeout がアプリケーションサーバ側の応答時間よりも短いと、せっかくアプリケーションサーバがレスポンスを返しても Nginx で破棄されてしまいます。これではサーバの計算資源の無駄遣いです。

そのため、アプリケーションサーバの応答時間を事前に見積もって、それより長い時間を proxy_next_upstream_timeout に指定しましょう。これは、タイムアウト設計をきちんとしましょう、そして時間がかかる処理(データベース接続)があるならアプリケーション内にきちんとタイムアウト処理を入れましょう、という話ですね。

応答時間の見積もりが難しいなら、proxy_next_upstream_timeout はデフォルト(タイムアウトなし)のままでもいいと思います。

サービスによっては再送処理をオフにする

API 提供時など、クライアント側で再送処理をしてくれるなら、proxy_next_upstream off; を設定し、再送処理をオフにするという手もあります。

関連情報

艦これアーケードのプレイデータ管理ツール Admiral Stats 1年分のユーザデータ解析

f:id:muziyoshiz:20170128164643p:plain

今月の9月3日に、艦これアーケードのプレイデータ管理ツール Admiral Stats の公開から1周年を迎えました。少しずつユーザが増え、開発に協力してくれる方も現れて、おかげで今日まで楽しく開発を続けてこられました。本当にありがたいことです。

1周年というのはよい節目なので、今回は Admiral Stats のユーザデータを解析して、利用傾向を調べてみました。この手のプレイデータ管理ツールを公開すると、どれくらい人が集まるのか(あるいは集まらないのか)の参考としてどうぞ。

解析対象は MySQL 上のデータです。解析方法の詳細は、このブログ記事の最後に貼っておきます。

アクティブユーザ数

Admiral Stats は、Twitter アカウントがあれば誰でもログインできるようになっています。しかし、この時点では、プレイデータは何も表示されません。

ログイン後に、SEGA 公式サイトからエクスポートしたプレイデータを Admiral Stats にインポートすると、プレイデータを時系列に表示できるようになります。

そのため、ログインしただけではアクティブユーザとは言えず、インポート機能を使っていればアクティブユーザと言えます。ただ、1回インポートして辞めてしまう人も割といるので、いくつかの基準で集計してみました。

グラフ上の項目名 集計基準 9月3日時点
ログイン その日の23:59までに1回以上ログインしたユーザ数 417
インポート その日の23:59までに1回以上インポートしたユーザ数 248
インポート(過去30日) その日から過去30日以内に1回以上インポートしたユーザ数 113
インポート(過去60日) その日から過去60日以内に1回以上インポートしたユーザ数 134
f:id:muziyoshiz:20170928002847p:plain

このデータを見ると、だいたい、以下のような傾向がありそうです。

  • ログインしても、インポートする前に離脱してしまうユーザが多い。しかし Admiral Stats 自体の改善が進んだためか、離脱率は徐々に下がっている
  • 2016年9月の まとめサイト取り上げ時 は、離脱率がかなり高かった
    • その後の1週間で増加したログインユーザのうち、78%(=61/78)が離脱してしまった
    • 当時は Ruby 版エクスポータしか無く、使うのが難しかったためと思われる
    • 流入の効果は1週間程度しか続かなかった
  • 2017年7月に 艦らぼ で紹介してもらった際は、離脱率が低かった
    • 公開後1週間で増加したログインユーザのうち、32%(=9/28)しか離脱していない(!)
    • これは、艦らぼに 丁寧な解説記事 を書いてもらえた影響もかなり大きいと思ってます
  • 艦これアーケードの期間限定海域(イベント)の期間中はアクティブユーザが増えて、終わると一時的に落ち込む

余談ですが、Admiral Stats は、おーぷん2ちゃんねると Twitter(@admiral_stats) で宣伝していました。おーぷんで宣伝したのはまとめサイトでの取り上げを期待してのことだったのですが、

  • 機能追加しても、まとめサイトでは最初の1回しか取り上げられなかった
  • おーぷんで宣伝しても、ある時期から PV が増えるだけでインポートユーザ数は増えなくなった

ことから、いまは Twitter でしか宣伝していません。

MAU (Monthly Active User) と継続率

インポート機能を使っているユーザを「アクティブユーザ」と定義して、これをもう少し詳しく調べてみました。

グラフ上の項目名 集計基準 8月末日時点
MAU(全体) その月に1回以上インポートしたユーザ数 118
MAU(その月の新ユーザ) MAU のうち、その月に初回ログインしたユーザ数 29
継続率 前月に1回以上インポートしたユーザのうち、その月もインポートしたユーザの割合 83.3 %
f:id:muziyoshiz:20170928002920p:plain

この指標で見ても、Admiral Stats の離脱率は徐々に下がっている(=継続率が徐々に上がっている)と言えそうです。

また、意外なことに、毎月増えるユーザ数(その月の新ユーザ)はイベントにそれほど左右されず、一定の値を保っていたようです。しかし、それが今年の7月で2倍近く増加しています。とうとう普及が一山越えたんでしょうか?

インポート回数

ユーザ1人あたり、1ヶ月に何回くらいインポートしているか調べてみました。インポート回数が多いほど、Admiral Stats を日常的に使っていると言えます。

Admiral Stats は複数のプレイデータ(提督情報、艦娘情報、など)をサポートしていますが、「提督情報」のインポート回数のみを数えました。ほとんどのユーザがこのデータをインポートしており、これを Admiral Stats の利用回数と同一視して差し支えないと判断しました。

以下がその結果です。僕自身のインポート回数(動作確認含む)と、それぞれの月で最もインポート回数が多かったユーザは、外れ値として計測対象外としました。

平均 標準偏差 合計
2016-09 5.84 4.51 111
2016-10 5.33 4.80 192
2016-11 5.52 5.35 276
2016-12 5.71 6.57 217
2017-01 4.65 4.36 214
2017-02 5.02 5.10 246
2017-03 7.45 7.83 417
2017-04 8.02 7.73 497
2017-05 9.60 8.83 806
2017-06 8.36 9.64 619
2017-07 9.50 11.40 893
2017-08 9.77 11.05 1133
全期間 7.76 8.79 5621
f:id:muziyoshiz:20170928002958p:plain:w640
f:id:muziyoshiz:20170928003012p:plain:w640

インポート回数も、イベント期間中は増えて、終わると一時的に落ち込んでいます。それとは別に、インポート回数の平均と標準偏差が増えていますが、これは Admiral Stats のヘビーユーザが徐々に増えている影響のようです。

エクスポータの種類別のユーザ数

SEGA 公式サイトからプレイデータをエクスポートするために、以下のエクスポータを提供しています。エクスポータは Admiral Stats の「使い方」ページ からダウンロードできます。

  • Ruby 版
    • 僕が最初に公開したエクスポータ
  • PowerShell 版
    • sophiarcp さんが Ruby 版を移植してくれたもの(2016-09-18 提供開始)
  • ブックマークレット版
    • sophiarcp さんが開発してくれたもの(2016-10-29 提供開始)
  • Python 版
    • mimikun さんが開発してくれたもの(2017-04-18 提供開始)

今年の3月12日に、エクスポートしたプレイデータを Admiral Stats に自動アップロードする機能を追加しました。この自動アップロード時の User Agent から、実際に使われているエクスポータの種類が(やっと)わかるようになりました。

以下がその結果です。全ユーザが自動アップロード機能を使っているわけではないので、MAU よりは少なくなっています。また、1人が複数のエクスポータを使っている場合もあります(例:家では Ruby、外ではブックマークレット)。

Ruby 版 PowerShell 版 ブックマークレット版 Python 版 その他
2017-03 5 10 14 0 0
2017-04 5 8 26 0 0
2017-05 7 9 45 0 2
2017-06 5 8 43 0 1
2017-07 6 7 69 1 1
2017-08 3 6 86 1 1
f:id:muziyoshiz:20170928003058p:plain:w640

ブックマークレット版のユーザ数が圧倒的ですね。正直、この集計をするまで、Ruby 版を使ってる人はもっと多いと思ってました……。PowerShell 版とブックマークレット版を作ってくれた sophiarcp さんにはホントに頭が上がらないです。

集計方法

今回の集計は、以下の手順で行いました。普通ですね。

  1. MySQL のバックアップデータをローカル開発環境に持ってくる
  2. rails console で CSV 出力する
  3. CSV を Excel に取り込んで、グラフを書いたり、ピボットテーブルを作る

rails console で実行したコマンドは、2周年のときの集計のために(自分が忘れないように)Gist に貼っておきました(Gist: Admiral Stats 1周年のユーザデータ解析)。Admiral Stats のソースコードは GitHub (admiral_stats) にあるので、興味のある方はそちらもどうぞ。Star を押すと開発者が喜ぶのでオススメです。

あわせて読みたい

muziyoshiz.hatenablog.com

Admiral Stats がどういうものかわかるプレゼン資料です。

muziyoshiz.hatenablog.com

今回は Admiral Stats の利用傾向を見ましたが、こちらはプレイデータの中身を掘り下げた記事です。

Wiki のページ、[[タイトル]] から作るか、いきなり作るか?

f:id:muziyoshiz:20170827200124p:plain:w480

最近、職場で Wiki について話していて、Wiki のページの作り方は2通りあるよね、って話になりました。

  1. ページ本文のなかに [[タイトル]] と書いて保存し、あとからそのリンクを踏んで「タイトル」ページの作成画面を表示する
  2. いきなりページの新規作成画面を開いて、タイトルを記入する

僕はだいたい1番で作る方なんですが、毎回2番で作る、という人もいました。

そんなことがあって「僕の Wiki の使い方は普通じゃなかったのかな?」と思って調べてみたら、最近の Wiki の一部(Qiita:Team や esa.io)は 1番のようなページの作り方ができない んですね。

そうなのか!これは面白い!と思って、Wiki の歴史を遡って色々調べてみました。今回はそんなネタです。

Wiki ソフトウェアそれぞれのリンク記法

まず、Wiki の機能を持つソフトウェア(以下、Wiki ソフトウェア)について、その Wiki 内のページにリンクするための文法を調べてみました。僕が有名だと思うソフトウェアと、最近登場した国産のソフトを主に取り上げています。

登場時期 ソフトウェア名 記法 WikiName [[pagetitle]] その他
1994 WikiWikiWeb Yes
1999 UseModWiki Yes Yes
2000 YukiWiki Yes Yes
2001 PukiWiki Yes Yes
2002 MediaWiki Yes
2002 Tiki ((pagetitle))
2003 Hiki Yes Yes
2004 Trac Yes Yes [wiki:pagetitle]
2004 Confluence [pagetitle]
2006 Redmine Yes
2006 Backlog Markdown Yes (※)
2008 GitHub Markdown Yes (※)
2011 GitLab Markdown [text](pagetitle)
2013 Qiita:Team Markdown [text](url)(作成前にリンク不可)
2014 Crowi Markdown <pagetitle>
2015 esa Markdown [text](url)(作成前にリンク不可)
2015 DocBase Markdown [text](url)(作成前にリンク不可)
2016 Scrapbox [pagetitle]
2017 Kibela Markdown [text](url)(作成前にリンク不可)

(※) 相対パスで書けばリンク可能だが、[[pagetitle]] 記法と比べたメリットが無いので省略

以下、この表の読み方と補足事項です。

  • 「登場時期」列
    • ベータ版と正式版があるときは、正式版のリリース日を登場時期とした
    • 正確なリリース日がわからないものは、確認できた最も古いリリースの日付とした
  • 「記法」列
    • 最近は Markdown 記法(またはその独自拡張)が多いため、その場合は “Markdown” と記載した
    • Wiki ソフトウェアが複数の記法をサポートしている場合は、Markdown 記法での仕様のみ記載した
  • WikiName 列が “Yes”
    • ページ本文に CamelCase で単語を書くと、それが自動的に Wiki ページへのリンクになるもの
  • [[pagetitle]] 列が “Yes”
    • ページ本文に [[タイトル]] 形式で単語を書くと、それが自動的に Wiki ページへのリンクになるもの
  • 「その他」列
    • WikiName と [[タイトル]] 以外の文法を採用しているもの
    • ページ作成前にリンクを張れる Wiki ソフトウェアのほうが多いため、作成前にリンク不可のものはそのように明記した

[[タイトル]] 記法の歴史は古い

ウォード・カニンガムが最初に作成した Wiki(WikiWikiWeb)は、CamelCase で単語を書くと、自動的にその名前を持つページへのリンクになります。また、その名前を持つページがまだ作られていない場合は、CamelCase? のように末尾に ? が付いて、この ? がページの新規作成画面へのリンクになります。これは、他の読者に、新しいページの作成を促すための工夫だったようです。

WikiWikiWeb にはこの CamelCase の記法(WikiName とも呼ばれる)しか無かったのですが、これでは不便だということで、後発の UseModWiki で、初めて [[タイトル]] 記法が発明されました。

UseModWiki は、MediaWiki が開発される前に、Wikipedia で使われていた Wiki ソフトウェアです。History of wikis によると、この記法が発明されたのは、Wikipedia のユーザビリティを改善するためだった、とのことです。

This CamelCase convention was used by most wiki software for the first few years of wikis' existence. In 2001, the software UseModWiki, which at the time was in use on Wikipedia, switched to allow internal links to be done using standard spelling and double square bracket instead, in order to improve Wikipedia’s usability. This square bracket syntax has since become more of a default convention for internal links within wiki software in general.

WikiName のルールは日本語では不便すぎるので、YukiWiki や PukiWiki といった国産のソフトウェアが早々に [[タイトル]] 記法を採用したのは納得できます。

[[タイトル]] からページを作れない Wiki が増えている

Markdown が普及して以降、Markdown やその拡張の GitHub Flavored Markdown(GFM)を採用した Wiki が増えています。昔から存在する Wiki があとから Markdown を採用したパターンもあります。上記の表では Backlog がそのパターンです。

Markdown は Wiki を想定せずに作られたので、Wiki ページにリンクするための文法がありません。そのため、Wiki ソフトウェアごとに、Wiki で一般的な [[タイトル]] 記法を導入したり、Markdown のリンク記法を Wiki のために拡張したりしています。

その一方で、Qiita:Team や esa などの新しいソフトウェアの一部は、「ページの作成前にリンクを張る機能は不要」と割り切っているのか、そのような文法を用意していません。

どういうことか? 例えば esa で新しいページを作ると、URL は https://muziyoshiz.esa.io/posts/5 のようになります。従来の Wiki は URL にタイトルの一部が入っていましたが、この種の Wiki では連番が入るので、事前に予想はできません。そのため、リンクを張りたければ、ページを作ったあとで、[タイトル](/posts/数字) のように、Markdown の文法でリンクを書く必要があります。これはめんどい。

ただ、esa の場合は、この面倒さを減らすためにリンクのサジェスト機能を提供しています。# からテキストを書き始めると、同じチーム内の投稿へのリンクがサジェストされます。

f:id:muziyoshiz:20170827214108p:plain

そして投稿を選ぶと、以下のように Markdown 形式のリンクに置き換えられます。

f:id:muziyoshiz:20170827214121p:plain

esa の場合、テンプレートを元に階層化されたページを作れるので、ページ名はだいたい「日報/2017/08/28/masahiro_yoshizawa」のようになります。これを手入力するのは現実的じゃないですよね……。それも、[[タイトル]] に相当する記法がない理由の一つかもしれません。

まとめ

[[タイトル]] という記法は昔からあって、さらにその大本には WikiWikiWeb が持っていた「ページの新規作成を促す機能」があった、という話をしました。だから、[[タイトル]] のリンクを踏んで新しいページを作る、というのは昔からの Wiki の使い方、と言えるでしょう。

しかし、これはインターネット上で誰もが参加できるような Wiki では必要でも、企業内などに閉じた Wiki では不要な機能なのかもしれません。企業内ならテンプレートに従ってページを作る方が一般的で、それなら

  • テンプレートに従って、いきなりページを作る
  • 必要なリンクはあとから書き足す

という使い方を助けるほうがいいのでしょうか? こういう使い方が今後一般的になっていくのか、気にしてみたいと思います。

2017年9月3日追記:アンケートへのご協力ありがとうございました

この記事の公開後の1週間、9月3日までアンケートを公開していました。ご協力ありがとうございました。

結果は52:48で、まさかここまで接戦になるとは予想してませんでした……。25名の方が投票してくれたので、13:12、1票差ですね。もう少し投票数を集められるなら、次はその人が普段使ってる Wiki ソフトウェアとセットでアンケートを取ってみたいです。

あわせて読みたい

この調査中に見つけた History of wikis はかなり読み応えがあって面白いので、Wiki に興味があったら是非一読をおすすめします。個人的に面白かったのはこのあたりです。

  • フローからスタックへ、という話題は、1996年に WikiWikiWeb へ ThreadMode が実装されたころにすでに存在していた
  • WikiWikiWeb にカテゴリとトピック(今で言うタグのようなもの)の機能が提案されたことがあったが、カテゴリのみが採用された
  • 「Wiki の機能をメール、IM、SNS と結合しようとした試み」として Google Wave の話が載っている

https://en.wikipedia.org/wiki/History_of_wikisen.wikipedia.org

このブログで過去に書いた Wiki 関連記事もあわせてどうぞ。

muziyoshiz.hatenablog.com

muziyoshiz.hatenablog.com