WordBench は誰のもの?

先日、WordBench がサービスを終了するというアナウンスがありました。

サービス終了のお知らせ

このお知らせが発表される前に、WordBenchの行動規範が公開されました。

WordBench の行動規範が公開されました

その行動規範の発表を受けて、行動規範とは一般的にどのようなものなのかをまとめつつ、その規範の決め方について提案をした私(@shinichin)の記事がこちらでした。

WordBench とはなんだったのか。 | Capital P

上記の記事はCapital Pに書いているのに、どうして今回は個人のブログなのかというと、先日信頼している人から「西川さんはそんなことないと思ってるかもしれないけど、Capital Pっていうのはメディアなわけで、それなりの信用もついてきているところにああいう記事が出ていると、『あ、なんかちゃんとしたところが言ってる!』って思われるんだよ。」ということを言われたからです。

その時に僕が言ったのは「たしかに影響力が高まるようにあそこで書いたけれども、それはそうしなければ誰も聞いてくれないように思ってたので、分かっててCapital Pに書いたんですよ!」ということでしたが、それでも「あのメディアで書いたら影響力が強すぎる」ということで、なるほどそうまで言うのであれば個人のブログに書くことににしようかな、と思った次第です。

この記事では、また懲りずに、まずは提案をして、そのあとでどうしてこの提案なのかを書いていきたいと思います。

提案

僕からの提案は以下です。

では、どうしてこう思うのかを、長くなりますが以下に書きます。

「WordBench とはなんだったのか」に対する答えの更新

さて、件のCapital Pの記事のタイトルは「WordBenchとはなんだったのか」でした。「WordBenchはウェブサイトにすぎない」と公式サイトに書いてあるのを読んで、「え?そうだったの?」という気もちの現れとしてのタイトルです。また、そこで僕は「それはイベントである」ということを書きました。なのですが、この期間、色んな人の文章を読んだり、人と直接話したりしているうちに、どうもしっくりこない感じがしてきて、時間がたってピンとくるようになったことがあったので、WordBenchとはなんだったのか、更新された答えを書いてみたいと思います。

WordBenchとは、ウェブサイトではないし、オフラインイベントでもなく、WordBenchとはコミュニティーのことです。

分かってみたら当たり前のことです。

WordBenchという言葉があってロゴがあって、それらを見たときに想起されるのは、勉強会や懇親会といった活動であったり、その場に参加した一人ひとりの経験であったり、あるいはそこで出会った人たちの顔であったりすると思いますが、常にみんなに開かれていたこの総体のことを、人はコミュニティーと呼びます。WordBenchって聞いて何か思い浮かぶとしたらそれのことで、それはコミュニティーのことではないかと。

うしろに「WordBench 男木島」などと地名がついて、それがローカルコミュニティーになる、という仕組みもおもしろいです。地域ごとのイベントの名前でありながら、「WordBench [地名]から来た山田です」みたいに、所属している感じも出たりする。WordCampよりも小さい単位なだけに、身近な感じもするし、日本中で同じ名前が使われていて、つながりも感じられる、よいあり方ですね。

WordBench は誰のもの?

wordbench.org というドメイン名は三好さんのもので、創始したのも三好さん。ロゴはどなたが作ったのか知りませんが、投票で決まったそうです。ウェブサイト WordBench.org の管理者も、三好さんなのでしょう。

そもそものアイディアは、10年前のWordCamp Tokyo 2008の懇親会での話し合いから生まれたそうです。10年という時間はすごく長いもので、ひとつのウェブサイトがこれだけ長持ちするというのは、大変なことです。いろんな問題もあったことでしょうし、作業的な負荷も多かったことと思います。それを粛々と10年間やってきたということに対して、感謝もそうですが、人知れずやっていたということに対して畏怖の念のようなものがあります。

けれども、10年という時間がたった今、「WordBenchは誰のもの?」という問いに答えようとするとき、それが10年前と同じであるかどうかはよく考えてみないと見誤ります。

コミュニティーの持ち主が個人ということは、特にオープンソースのコミュニティーにおいては、その性質上ありえません。人間の集団やその人間たちの活動をそもそも所有することはできないし、少なくとも僕は誰かの持ち物であると思ってイベントをやったりスピーカーをしたりしてきた自覚は全くありません。

コミュニティーは、コミュニティーに参加している一人ひとりのものです。

各地の「WordBench ○○」を立ち上げた人、引き継いだ人、会場を探して予約して告知文を書いた人、部屋の入口にイベント名を書いた紙をはりつけて、来場した人たちを迎えて、前に立って「来てくれてありがとう。では始めます」と言った人、告知を手伝うためにブログを書いたりTweetしたり、知り合いに口コミで教えた人、会場を提供することを社内で話してくれたいろんな企業のいろんな人。セッションに登壇した人や参加者ももちろんそうですし、懇親会の予約をした人もそうだし、お会計で千円札を集めた人もそうです。家に帰ってから参加レポートを書いた人たちもです。新しいWordBenchが始まるというときに力を貸したり現地に行って盛り上げた人や、各地のWordBenchわぷーを作った人のことも忘れてはいけないです。

そういうコミュニティーがあったから、はじめての勉強会がWordBenchだった、はじめての登壇はWordBenchだった、友だちができた、教えてもらってウェブサイトを完成させられた、ウェブサービスができた、仕事に就けた、といった価値が起こったわけです。

この人たちがコミュニティーのメンバーであり、その活動がWordBenchを育ててきました。ひとつひとつの積み重ねが、コミュニティーの成長を進めてきて今に繋がっています。WordBenchは誰のものかというときに、所有ということがあり得るとしたら、創始者の人たちもそうだけれども、いろんな形で参加してきた人たちのものでもあります。

行動規範の決まり方について波紋が広がったのはなぜか

行動規範とは、ものすごくざっくりといえば、他者を排除したり攻撃したりさせない、誰かに居心地の悪い思いをさせないための、最低限のルールを決めた文言集で、もっと言ってしまえば、インクルーシブである、つまり「誰でも参加できる」ということを保証するための仕組みと言ってしまいたい。誰もが自分の居場所であるということを感じられるようにするために、それを邪魔する言動・行動を排除するための仕組みですね。

例の行動規範がポンと出たときに戸惑いの声や反対の声が広まったのにはいくつかの理由があったと思います。具体的な文言に対する疑義もありましたが、僕個人が特に感じたのは、その決まり方でした。自分がメンバーであるコミュニティーのルールが急に決まってふってきた、ついでにその中身にも疑問があってそれを事前に議論する時間も手続きもなかった、ということがショック。「全然参加できてない」というものです。

なので、その時の提案としては、

  • もう一回声を吸い上げる時間を作りたい
  • その上で作業チームを作って改訂版を作りたい

ということを挙げていました。自分たちの活動の方法について、自分たちの声も聞いてくれないか、ということでした。そのなかで自分の意見も言えればいいや、と。

今回も同じような話です。提案します、どう思いますか?という問いです。

それと、「やめることにしたので名前の利用はもうできません」と、これまで参加・貢献してきた人たちに言えるんでしたっけ?いきなり言っていいわけがないところまで育ってしまっていますよ、という問いでもあります。

今回の提案について

今回の提案、詳しくは上の方へ戻って読んでほしいですが、つまるところは「名前は残して、原則や運用はグローバルに合わせる」というものです。名前を残したほうがいいというのは、今までに築いてきたものを捨てることはないし、これから名前を変えてなんだかんだということをするのは作業コストが大きいし、なんならMeetupよりも歴史があるんだし、おもしろいし、みんな知ってる名前なんだから使えばいいのでは?ということです。

もう一つ言うと、これからもっといろいろできる可能性だってあると思います。現状を維持するだけじゃなくて、なんかおもしろいことがあるかもしれないのにもったいないじゃん、という気もしています。

ウェブサイトを残さなくていいと思うのは作業負荷や責任が集中しすぎて申し訳ないということです。ウェブサイトがあることでその管理者が発生してしまうという構造の問題を解消したらいいように思う、ということです。個人のプロジェクトとして始まったけれども、今回の経緯を見るに、個人としてその作業や責任を請け負うのは限界が来ているということの現れとしての一連の出来事だったのではないか、と思うからです。

グローバルに合わせるのはなぜかといえば、人材が豊富で責任を持ったり議論をしたりするための場や法人があり、そこをうまく利用するほうが楽になるという理由です。グローバルを利用せず、かつそこと同じようなメンバーや知見を揃える体力はないと思います。

議論の仕方について

一部の方はご存知かもしれませんが、僕はSlack において議論の旗振り役をやりましたが、失敗しました。炎上とは言わないまでも怖い雰囲気になりましたし、最後は僕も怒っていましたから最悪です。向いてなかったかな。がんばったけど無理でした。ごめんなさい。

そこでやろうとしていたのは、言いたいことがある人が言いたいことを言える場を用意して、なんだかんだ時間がかかるかもしれないけどなんとか集約して形にして、「考えたのでこれにアップデートしません?」という形で運営チームに出してみよう、ということでした。そもそも聞いてもらえるのかどうかも分かりませんでしたが、とりあえず動こう、と。

結局のところ、そうこうしているあいだに終了宣言が出て、行動規範改訂も御破算になりましたし、それまでに発言が全部拾えたかというとそんなこともなく、各地の人たちの発言が多かったとも言えず、とはいえあんな怖い場所に書き込んでくれるのを望むというのもそれは無理だろうということで、そういう失敗でした。

思ってることがある人へ

先日信頼しているある人(さっきからこのフレーズが出てますが、デジタルキューブの小賀さんです)が言ってたのは、みんな自分のブログで書けばいいじゃん、ということでした。思ってることがある人は別に書けばいいのでは、と。意見が違ってもいいから言いたいこと言っちゃえや、と。自分はこうしたらいいと思う、こうしたいという、これからのことを書いたらいいよ。そういうのがいろいろ出てきてなんとなく集約されればいいじゃん、と言われました。なるほどすぎますね。

別にブログじゃなくてもいいです。Slack参加方法)でもGitHubでも大丈夫ですし、Twitterとかでもいいかもしれないです。

どうせ自分の声なんて聞かれない、あるいは、発言するのが怖い、というのはよくないですよ。なぜよくないのかといえば、そういう雰囲気のコミュニティーなのだったら、WordBenchが残るにせよ残らないにせよ、遅かれ早かれ、先はないと思うからです。多様性と自発性のないところに未来は無いと思います。

運営チームの方々へ

上記の提案は僕の個人的な提案(Capital Pに書いたのものそうだったんだけど、今になって思えば書く場所間違えました。ごめんなさい)にすぎず、色んな人の声が集まって決まったことであれば当然受け入れますし、僕の思ってるところも変わるだろうなと思ってます。ディスカッションがオープンであることが保証されればいいや、ということです。自分の居場所のことを決めるのに参加できないのはいやだし、思ったことは言えるはずだ、ということです。わがままじゃないと思うし、そういう考え方しかできないし、それが当たり前だと思うので、誰か返事ください笑。

↓ プラグインを作る方々への本、書きました。 ↓

シングルインストールのWordPressをマルチサイトの子サイトとしてインポート/マイグレーションする。

WordPress のシングルインストール(普通にインストールしてあったサイト)のコンテンツから何からをまとめてマルチサイトの子サイトとしてマイグレーションする方法。

普通のWordPressの移行の方法とほとんど同じで差があるところは、

  1. url が変わる
  2. uploads/ ディレクトリのパスが変わる( uploads/sites/site_id )になる
  3. users と usermeta がマルチサイトの親サイトに統合される

の3点です。

今回は、3点目は手動でなんとかすることにして、1, 2 をぱぱっとやる手順についてまとめます。example.jp というサイトを example.com/ja に移行するとすると以下のようになります。

  1. マルチサイトを用意して、子サイトを作る
  2. 子サイトのIDを把握する。以下、サイトIDは2だったとして進めます
  3. シングル側でDBをダンプする(wp_users, wp_usermeta はしない)
  4. ダンプしたDBに対して、以下の置換を行う
    1. example.jp -> example.com/ja
    2. /wp-content/uploads/ -> /wp-content/uploads/sites/2/
    3. `wp_ -> `wp_2_ (バックティックを含めると事故が少ない)
  5. themes/, plugins/ ディレクトリを移す
  6. uploads ディレクトリを wp-content/uploads/sites/2/ に移す
  7. マルチサイト側にインポートする

これでできます。作業中なので他にも何かあったら更新していきたいと思います。

コマンドで置換する

sed コマンドを使います。

cat ./prod-single-sub.sql \
 | sed -e 's/https:\/\/example.jp/http:\/\/example.com\/ja/g' \
 | sed -e 's/http:\/\/example.jp/http:\/\/example.com\/ja/g' \
 | sed -e 's/example.jp/example.com\/ja/g' \
 | sed -e 's/`wp_/`wp_2_/g' \
 | sed -e 's/\/wp-content\/uploads\//\/wp-content\/uploads\/sites\/2\//g' \
 > ./dev-multi-sub.sql

wp-cli で、特定のテーブルのみをエクスポートする

3の wp_users, wp_usermeta を排除するには、次のようにするとよいです。

wp db export prod-single-sub.sql --tables=wp_commentmeta,wp_comments,wp_links,wp_options,wp_postmeta,wp_posts,wp_term_relationships,wp_term_taxonomy,wp_termmeta,wp_terms

--tablesでどのテーブルを対象にするのかが決められるのですね。

↓ プラグインを作る方々への本、書きました。 ↓

WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか

OAuth認証やってまいります。

WP REST API の OAuth 認証用のプラグインの github レポジトリのドキュメントのフローの通り進めます。また、リクエストの送信には、Paw という Mac アプリを利用します。

この記事自体の中に上記のドキュメントで伝えられていることを逐次翻訳して残しておこうと思います。上記のドキュメントは読まなくても大丈夫になるように頑張ります。間違いがあったら、 @shinichiN へお願いします。

STEP 0: Client Key と Client Secret を作成する

ドキュメントサイトの方には「OAuth のプラグインにUIはありません。そのうち作ります」などと書かれておりましたが、実際にはありました。

WP REST API の OAuth プラグインのアプリケーション作成画面
WP REST API の OAuth プラグインが提供するアプリケーション作成画面

wp-cli を利用して $ wp oauth1 add みたいなことをしないといけない、とドキュメントサイトにはありますが、管理画面でできました。

というわけでさっそく作っていきましょう。

コンシューマを作ってみました。
コンシューマを作ってみました。

NameDescription は管理用のものだと思われますので適当に入れます。Callback URL はよく分からないですが必須なので /success としました。

Client Key と Client Secret をメモしておきましょう。

OAuth フローの概要と、その意義

OAuth1/Auth-Flow.md at master · WP-API/OAuth1 にある OAuth 認証のフローを翻訳します。クライアント側から見ると、3つのフローに分かれています。

続きを読む WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか

↓ プラグインを作る方々への本、書きました。 ↓

習うより慣れろ。WP API にリクエストをいっぱい投げる。& REST クライアント “Paw” が超便利。

WP REST API サイトの主要なページをじっくり読んだところで、次は習うより慣れろということで、リクエストいっぱいしてみて、レスポンスをじっくり見てみよう、という趣向で進めてみたいと思います。

前提として、以下の記事を読んでおくと、話がよく分かると思います。

また作業にあたり、Mさんこと @miya0001 さんから Paw – The ultimate REST client for Mac という、REST クライアントを紹介してもらいましたので使ってみました。

スクリーンショット 2016-01-03 10.34.36

Paw is a full-featured and beautifully designed Mac app that makes interaction with REST services delightful. Whether you are an API maker or consumer, Paw helps you build HTTP requests, inspect the server’s response and even generate client code.

Paw は機能フル装備の美しい Mac 用アプリで、REST サービスとのインタラクションを快適にします。API を開発するひとにとっても、使う人にとっても、HTTP リクエストをビルドしたり、サーバからのレスポンスを詳しく見てみたり、さらにはクライアントコードを生成してみたりするのに便利です。

いやー、実を言いますと httpie はとっても手軽なんですけど長い json がどわーっと来ると目的の key を探したりするのが不便で困っていたんです。手元でパッとテストするにはとてもいいのですが、使い分けですね。

ということで、

  • エンドポイントやリクエスト内容を整理して保存
  • レスポンスを綺麗に見る
  • 自分が何をやっているのか見て分かるようになる

ということのためによさそうです。まずは30日間の Trial ができるということです。

インストールするとこんな感じで、

Paw の初期画面
Paw の初期画面
  • アクションを選び、
  • URL を入れて
  • パラメータを指定する

ための画面が出てきました。とりあえず、

というのをやってみます。

Paw では認証関連もサポートしているようなので、次回以降は以下の作業もやってみます。

  • 認証をしてみる(参考: WP REST API のドキュメントの認証ページの翻訳)
    • まず Basic 認証を
    • 次に OAuth 認証を

続きを読む 習うより慣れろ。WP API にリクエストをいっぱい投げる。& REST クライアント “Paw” が超便利。

↓ プラグインを作る方々への本、書きました。 ↓

WP REST API ドキュメント Discovery

Discovery | WP REST API v2 Documentation の翻訳です。

Discovery 発見/探索

未知のサイトにアクセスする際、そのサイトでは何が可能でどのように設定されているのかを知る必要があります。何を知りたいのかによりますが、幾つかのステップで探索することができます。

続きを読む WP REST API ドキュメント Discovery

↓ プラグインを作る方々への本、書きました。 ↓