Autumnsky

WordCamp関西に参加した話

序

WordPress自体はほぼTwitterと同時に触り始めたので、歴は７年にもなる。
だが、思い出した時にテーマを書く程度で、ブログとしてもほとんど使えてない始末。
そんな中、Autumnskyの3代目テーマを考えるうちに「やるなら、今度は本式にやってみたい」ということでWordBenchでCSS設計のお話を聞いたのが、昨年15年の9月。
そこからちょこちょこ、大阪・神戸のWordBenchに参加。
WordCampという二日間開催のカンファレンスがあると聞いても、最初はあまり乗り気ではなかった。
が、登壇者の一覧と内容が確定するに連れて「行くしかねえ！」モードへ。
特に気になったのが、男木島図書館、WordPressのDockerize、コアコントリビュータになってよかった話。
そしてOrganic Lean UX。User ExperienceがOrganic？分からん。しかし、惹かれる。
あと、阪大キャンパスに入れる。キャンパスは好きだ。母校ですら卒業してから10年は足を踏み入れていない。
ましてや他大学、行くしかないでしょ、このビッグウェーブに。
日程＆体力を考慮して二日目のみ参加しました。以下、拝聴したセッションで印象に残ったことをつらつらと。

実行委員会が公式テーマ登録に挑んだ話

もっと引きずり回せばよかった       ―ナターシャ/花谷琢磨/チミヲ

実行委員のチーム3名が、公式テーマの登録に2ヶ月で挑戦してみたらどうなったかという話。
様々な効率化を駆使するも、時間不足＆プロジェクトマネジャー不在＆テーマ審査待ちにより、残念ながら7月10日時点では公式ディレクトリに採録されていない。
EditorConfigというツールを使うと、メンバーの細かなコーディング規約の順守が楽になり、摩擦が減る。
ふむ、そういうツールがあるのか。
しかし、根本的な問題として

「リーダーシップが大事」

3人チームですら、GitHubのIssue機能では収拾つかなくなってしまったのと、誰が何を担当しているか把握できなくなってしまったそうで、ラベルやAssignee（担当者）機能を使ってなんとかした。
この辺、やっぱりRedmineが適すのかなと思ったけど、短期で少人数だと逆に機能多すぎるかも。
チケットを切る「オーバーヘッド」がちょっと大きい。
何より、レビュー依頼してフィードバックまで数ヶ月待ちはキツイですね。自分もきっとダレてしまうだろうな。

昼休み

アセンブリホールでは立食のような感じでパンとおにぎりが置いてある。
これを目当てに昼ご飯を買ってこないで来た。飲み物もある、コーヒーメーカーもある。天国かよ…
高速WordPress実行環境 KUSANAGI
前のステージでスポンサー企業がプレゼンをしている。
これ、この前ネットで見たヤツだ！ノーマルでも10倍は速いらしい。
うちのブログもレスポンス速くしたいなー。


パンを頂いて喫煙所を求めてキャンパスを少し散策。阪大図書館は近未来的な外観だ。
緑豊かないいキャンパスだなあ。
toyonaka_campus
スモーキング・ボックスで一服、狭い。守衛さんも一服入れてました。
清浄機の机でたまたま前に居た人が話している。
「週10サイトの依頼を受けてる知り合いがいて…」
「ムチャ振りだなあ。WEB広告で収益モデルも先がないのでは」
「JSで完全に動的なサイトだとSEOで不利。だからロボットのクロールが来た時だけヒュッと静的なページを返す」
私「なんかすごいですね」
「海外では結構事例があるよ」
など見知らぬ人と、スモーキング・トーク

WordPressに活かす！最近のPHPエンジニアトレンド2016

Vim/EmacsおじさんがIDEを使うようになってきている
田中ひさてる 関西PHPユーザーズグループ


「スピーカーは田中ひさてるさんです」
あ、あれ、さっき喫煙所で一緒だった方だ！
PHP7、昨年12月リリース、なんと11年ぶり。そんなに変わってなかったのか。
文法の変更ではバージョンは上げないと明言しているとのこと。
「PHP言語はWordPressを非常に重視している」とのことだが、エンジニア向けカンファレンスだったので、フレームワーク使いの方々には届かなかったのでは。
PhpStormというIDEの話。FTPは今でも「使える」ナイスな方法でした。
そうか、WordPressだと管理画面からテーマ変えちゃうから、FTPの差分同期あるといいよね。
標準化が進んでて、JavaScriptでいうNode.jsみたいなもんが遂に正式リリース。
パッケージを選んでインストール、そしてそれを管理できる。PHPはComposerという。
Ruby on RailsだとGemになるのかな。

WordPressでも使えるから、これでプラグイン管理すれば、人の書いたコードを自分のGitで管理しなくていい。

それはありがたい。バージョン管理ソフトは自分や自チームの書いたコードだけにしておきたい所。
これは別のセッションでも、「WordPress丸ごとバージョン管理システムに入れたらエラいことになった」事案とも関係する。

アプリケーションが発達すればこそ、優れたテキストWEBコンテンツとして、HTMLドキュメントはこれからもますます重要だと思います

私の解釈としては、PHPでCMS作ってブログ＝WordPressとか、アプリケーションからAPI叩いて情報を取得するとか、
この辺はつまるところ伝達技術の話で、中身のコンテンツのことではない。
FAXの伝送方法がG3になったから高速とか、はがきのサイズが規格化されたとか、そういうことかな。
重要なのはやはりコンテンツ＝中身で、Webなら基本のHTML文書ではないかという話。
うん、確かにコンテンツがきちんと構造化されているというのは、何に使うにしても重要な感はする。

Mac / WindowsでのWordPressのDockerize

仮想OSが不要なコンテナ方式なのに仮想マシンを走らせるVirtualBoxを必要とする高度な問題
Kite


Dockerというコンテナ方式の仮想化方式は軽くて速い。
そこでWordPressを走らせると環境構築が速い。
Mac/WindowsではVirtualBoxとVagrantを必要とする。
で、結局OSがいる現状なので軽いOSとしてBargeOSを用意しているとのこと。
はいWockerでお世話になってるので星入れました。
公式のDockerToolBoxがあって、Kitematic（カイトマティック）というソフトからDockerをGUIで扱える「GUI好きの人のために」
CLIとシームレスな点はよさそうですね。
そしてこれは、カイトさんがコミットするしかないのでは。
最後にDocker for Windows Macもあるよ。
ネイティブである、Linux＋Dockerに一番近いとのこと。
Linux+Dockerがネイティブということは、コンテナ技術はやはりサーバーから始まったのかな。
最近（16年6月頃？）オープンβに移行したらしいので、誰でも試せる。
コンテナの作り方
DockerFile -> DockerImage -> コンテナと作って、実行されるのはコンテナ。
コンテナの考え方から行くと1コンテナ1プロセスなので、データベースとPHPで分けてDockerImageにした方がいいらしい。
あくまで開発用なのでWordPress用のは1コンテナでやっているとの話。

DockerImageはたい焼きの型なので、たい焼きであるコンテナはいくらでも作れる

やっぱり、ここは「たい焼き」と「たい焼きの型」理論が一番わかり易い。
一枚板に何匹も並んでるのでなく、一匹ずつ棒の先についてるタイプ。
DockerFileからのビルドはビルドレイヤーがあって、キャッシュが効きますよとのこと。
（ビルドレイヤーがいまいち分からない…）
具体的にはDockerFileのスクリプトが1行ごとにキャッシュされるみたい。デモで吐かれてるビルドログみてると、「Using-cache」の文字が。
こういうところも高速化されてるんだなあ。
Windowsから直接Dockerコンテナ走らせたいですね。次に私がやりたいのはRuby on Railsで、開発環境はVagrantを使う予定。
開発にも仮想化の恩恵は大きいはずという思いを新たにした。

WordPress RESTFul API & Amazon API Gateway

コストを削って、やりたいことをやろう
AWS芸人こと清水崇之


AWS芸人さんの謎ガジェットから何がAPIなのかと思ったら、
APIの基本から、Amazon API Gatewayの活用方法まで、分かりやすかったです。
掴みのおかげでしょうか。


サーバーは運用コストが結構かかる、お金も手間も。
なのでサーバーレスでコストを削って、やりたいことに注力しようということでした。
そこらへん、ストレスは軽減しておきたいですね。

AWS+WordPress.SkeltonでスケーラブルなWordPressサイトを作る

データベースのスケーラビリティはお金で解決している。
gorou_178


まず、スケーラビリティについて私は漠然と「処理能力を引き上げる方法」ぐらいにしか理解してなかった。
負荷を複数サーバーのWordPressに分散させるとして、メディアファイルはどうするか、という具体例でかなり理解が助けられた。
私のような個人ブログで構築している程度だとまず考えなくていい領域である。
で、複数サーバーにアクセスを振り分けるとして、各サーバーに「同一のWordPress」を用意する必要がある。さて、どうするか。
はい、ここでもWordPressを丸ごとgitにいれた人がおられました。
コアのアップデートがあると「2,448 Changed Filesでテーマの変更とか全く分からなくなる」
私のやっていたVCCWを丸ごとgitに入れるなどという暴挙に出ますと、Changed 6,000ファイルとかになってもう何やってんだかわかりません。
私はそこからテーマ用にサブモジュールとか使ってみましたけど、ローカルはサブモジュールも解除して放置状態、Githubリモートは削除。
あ、これじゃ「バージョン管理やっている」とは言えないな…やってる人で手を挙げてしまったが。
そこで、コア＝WordPress本体とプラグインは、Skeltonというテンプレートを使ってディレクトリを分解、Composerでパッケージ管理にしてしまう。
ここでまたComposerきました。そんな方法が？！
で、ダウンタイムゼロでアップデートをするBlue-Green Deploymentという手法。
方法は聞いたことあるけど、そういう名前だったのか。
今後、WP REST APIでバックグラウンドにWordPressを使うことも多いだろうから、今のうちにスケーラブルにしておきましょうとのこと。
確かに、APIだと同時接続数が跳ね上がりそうですよね。
質疑応答で「データベースのスケーラビリティはどうしているか？何かアイデアは？」という質問に対して、

「今はできていないので、将来はやりたい。今はお金で解決している」

とのことでした。
実はこの二つのセッションは、流れでそのまま居座って聞いてたのですが、とても興味深かったです。
この次から、私の聞いたセッションは技術的な話ではなくなってきます。
でもどれも本当に興味深く、面白いセッションでした。

WordPressのプラグイン作ったりコアコントリビューターになった話。そしてその楽しさと意義

英語で説明するのがツラかったのでテストコード書いてプルリク投げたらコアにマージされた。
Toro_Unit


This is Open Source Power.を感じたセッションでした。
Toro_Unitさんのコミットメントは最初は「騙されたと思ってプラグインを公開」から始まったんですね。
でフィードバックをもらうと嬉しい。この辺は、誰でも同じだなあ。
そしてフィードバックをもらうと、自分では知らなかったことが分かる。自分のスキルアップになる。
なるほど、これはマズローの欲求五段階説、承認欲求から最後の自己実現欲求へ昇華していく過程かな。
バグに気づいて直して公開する、開発者も利用者もみんなハッピー。
これはまさにオープンソースでなければ、なしえない方法ですね。
近江商人の「三方よし」に近いものがある（売り手よし、買い手よし、世間よし）
私が思うに、オープンソースが何故上手くいくか、
それは参加者個人が、人間として根源的な満足を得られるからではないか。
そしてオープンソースは社会に新たな満足を提供するための、新しい方法でもある。
よってオープンソースソフトウェアに参加するというのは、人が社会に貢献する新しい方法でもあるのではないだろうか。
この辺はToro_Unitさんも触れてたエリック・レイモンド著「伽藍とバザール」でも書いてある。ちょっと、とっつきにくいけどオープンソースの聖典ともいえるので、使う人も作る人も是非一読をオススメしたい。
というわけで、聴いている皆さんも是非コントリビュートしましょうという呼びかけで、WordPressコアの初心者向けバグチケット集のページを紹介された。
コアの開発に参加するというと難しそうだけど、簡単そうな修正パッチも必要とされているよ、とのこと。
{44} Good First Bugs -WordPress.org
翌日、ちょっと覗いてみたところ、まさに私がテーマ書いててぶち当たって解決済み（私の中では）のと似たような内容のチケットがあった。
これは、パッチ投げるしかないのか？！

デザイナーが WP-API を使う意味 ～男木島図書館のスマートフォンアプリ制作から学んだWordPressの“これから”

今までのやりかたで、いつまで行ける？
額賀順子


まず、男木島図書館という特殊性からの説明。
住民175名の離島、NPO運営の私設図書館（公立ではない）、小さい島でもちゃんとした図書館はあるといいと思います。
いや、コミュニティが小さいから作らないという選択肢はないはずです、社会として。
そこで図書館のオンラインアプリがほしい、図書館を名乗るからにはオンライン検索が必要。
（OPAC Online Public Access Catalogこれが理想型）
「旅人」が教えてくれたJavaScriptからスマホアプリを作ってWordPressのREST APIでコンテンツを届ける方法。
これがあれば、バックエンドとフロントエンドが完全分離できるのでは。
そこから始まる、新たな制作手法があるのではないか。
もうWebといっても表示環境も利用状況も一気に増えた今、「今までのやり方で、いつまで行ける？」
WordPressのテーマ作成で額賀さんご自身によくあるワークフローが三つ紹介されました。

  1. ウォーターフォール
  2. フレームワークを指定されてデザインカンプ（今ならBootstrapが多い）
  3. 公式テーマから選んで子テーマでユーザーに合わせてカスタマイズをする

今思ったのだが、三つ目はテーラーメイドに似てるかも。生地や型、見本を職人と見ながらどういう服にするか相談しながら決めていく。生地は始めから織ったりはしない、反物で仕入れたものを使う。

WordPress × API
ワークフローを変えることができる仕組み

オンライン男木島図書館は、まさにWordPressがフィットする規模と状況じゃないかなと思いました。
スピーカーの額賀さん曰く「海外では実際にWordPressを使ってる図書館もある」とのことだが。
また、ウォーターフォールがダメかというと、そうではない。
市立図書館クラスだとやっぱり従来型のウォーターフォールで大規模プロジェクトを組んだ方がいいと思う、蔵書数も膨大だし利用者も数千単位になるし。
Agile開発は「クリティカルな業務には向かない」と提唱者が書籍に書いているように。
私は額賀さんの話した「完全分業」でなく、逆ベクトルで「PHPを分かってる人が、PHPとCSSでプロトタイピングでテーマを作る」という方法が手っ取り早くていいかもしれないと思っている。
WordPressにかぎらず、フレームワーク使ってWebサービスを立ち上げるなら、動作モデルをコーディングしながらスタイル当てるの最速ではなかろうか。
エンドユーザーにすごく近い人が、個人的な問題を解決したり、小さなコミュニティに解決策を作る、ニッチを埋めていく…
一人二人でも十分に扱えて強力なフレームワーク、そのための新しいワークフロー…
離島の私設図書館が自身の課題と地域社会のために、新しいワークフローを模索する、広大なフロンティアを感じました。

男木島をWordPressの島にしたい ―額賀順子

Organic Lean UX

プロセスに振り回されない
Ustwo社 インタラクションデザイナー 中村麻由


ついにコードの話やWordPressの話がなくなった。
中村さんの肩書きはインタラクションデザイナー…インタラクション＝双方向性だったか。
UX UserExperience ＝ シンプルでエレガントな見た目で、快適に使える（原文ではjoyと表現されていた）
「UXデザイナーと名乗る人もいるが違うんじゃないかと思う、だから私はインタラクションデザイナーです。」
UXは体験なので、それはデザイン不可能だ。@igiさんの言葉を借りれば「コントロール不可能な目標」
バズワードによくある現象

デザイナのガジェットが尽きて終わり、みたいなプロジェクトも沢山あった。
アジャイルとかスクラムとかUCDとか、
プロセスばかり重視されて、プロダクトを大事にできていなかった。

そこに提唱されたLean UXという考え方。
日本語では「無駄のない」 訳本では「贅肉のない」と訳されているそうだ。
Lean（リーン）…対義語はRich（リッチ）
大体分かる、「希薄」という意味もあるが、果たして合っているのだろうか。
ここでワークショップ的なことをやる。

隣の人、できるだけ見知らぬ人がよいです、1分間自己紹介します。
された人は自己紹介で得た「事実」を元にして、
誕生日プレゼントに何を贈れば喜んでくれるか「推測」して下さい。
どうでしたでしょうか、答え合わせはあえてしません。
――デザインのプロセスは、これと同じです。事実を元に推測する。

だから常に Build – Measure – Learn (ここはラーニングの方）のサイクル。

「UXをやろう！」とかけ声だけでは、プロセスの導入に終わります。
プロダクトがリリースされる前とされた後で、ほんの少しだけ「世界」が変わります。
そのプロダクトを何故提供するのか、何故その機能が必要なのか、Whyから始めましょう。
ビジョンを明確にしましょう。

「ほんの少しだけ変わる」何かが、快適で満足なことならば、それをベネフィットというのではなかろうか。
このビジョンを明確にするためにUstwo社ではクライアントとチームで最初にワークショップを行うそうだ。
このビジョンなき顧客というか事業者は結構多いもので、恐らくビジネスに必須の要素だとは思われてないんだろうな。
「御社の社会的使命は何か？御社は世界にどんないいことができるか？」とか聞かれても答えに詰まるか、一般論に逃げてしまうだろう。
そういうことを常に考えろとドラッカーもコヴィーも、もしかしたら松下幸之助も言っていると思う。
これがOrganic Lean UXの第一に重要なこと、「ビジョン」
ビジョンを明確にするためにクライアントも参加してワークショップをやるそうだ
LEGOを使ったりしているが、まあ形にならないこともあるそうだ。
質疑応答でLEGO以外の方法も話して頂いた。

  • プロダクトが成功して雑誌に載るとしたらどんな記事か？
  • 完成品をキャラクターにしてみる。

大事なのは形を成すかではなく、認識のすりあわせ。

一日の最後にチームが同じ方向を向けばよい

このために最後はVisionBoardという一枚にまとめて行くそうだ。
第二に「気づき」（Awarenessかな？）

あらゆるアイデアは仮説である

だから、検証をせよ。

スポーツにおいて状況はその瞬間ごとに変わり、
プレーヤーはそれに対して最善の行動を取らねばならないように、
プロジェクトを取り巻く状況は刻々と変わる。

結構「マッチョ」な話ですね。でも「状況」＝外の世界ってのはそういうもんだ。
この辺のリスク回避、「手前の方でボタンの色を検証し始めたり」しないよう、
最初に推測-リスクの対応表（マトリックス）を作成して、どれから取りかかるか決めるそうだ。
またプロジェクトが行き詰まってきたり締め切り間際でバタバタしてくると「コーチ」が、
今の状況を映画を見るように考えてみろ、と状況整理を促してくれるそうだ。
そういう「マネジメント」の方法は、誰にとっても余計なストレスが少なそうだ。
朝のスタンドアップ（=朝礼みたいなもの）では相談しない、昨日やったこと・今日やること のみ。
そういうスタイル、いいですよね。
第三 何でも自分たちで体験してみる

話してるだけではどうにもならない、1時間議論したことが5分で分かることもある。
体験していないことは想像でしかない、だから、いつでもユーザーテストを行う。

これを嫌うデザイナーも多いそうだ、「抵抗もある」と。

デザイナーは自分の納得いくまでプロダクトを見せたがらない。
でも完璧だと思って見せたモノが間違っているとかなりツラいので、
こまめに出してフィードバックをもらった方がいい。

この辺は実感するなあ。
とにかく人に見てもらえる形まで持って行ったら、あとは見せる。場に出す。世に問う。
フィードバック、レスポンスがないと先には進めない。
何かプロセスや新しい概念を持ち込んだら、それだけで上手くいくという考えは始めから間違っている。
「銀の弾丸」などない、繰り返されてきた言葉。
組織やチームの中でそのプロセスなり概念なりを、消化したり育んだりが必要なんだと思う。
それが”Organic”＝「自然に」ということなんじゃないだろうか。

WordCampに参加して

ネットで情報みたりテキスト打ったりするかな、とノートPCを持って行きました。
しかし、1時間でバッテリー切れ。
結局ノートを取ってみたり、XperiaからTwitterにメモ代わりに投げたりしてました。
勉強会のメモ取りには、やはりノートが最強です。図表も自由自在に描けます。
セッションは二日目のを聴くばかりでしたが、色々な領域の話で面白かったです。
あと会場の大阪大学・学生会館はモダニズムというのか、とてもいいですね。
次回も会場はここなのか分かりませんが、また来年も参加したいです。
daigaku_kaikan

カテゴリー：

最終更新：