セッションデイに一般参加してきましたので、簡単にレポートをまとめたいと思います。セッション登壇者氏名の敬称は略とさせていただきます。サーバがダウンし、それにどう対処したか。「現場あるある」の体験談を基にしたセッションでした。JOINしていることが窺えます。言われてみれば「確かにそうですよね」と頷くところですが、WordPressの場合はWP_Queryオブジェクトで上手くラッピングされているので意識が薄まりがちだと思います。JOINしたレコードを抽出しようとしたら......それはメモリ負荷が恐ろしいことになりそうだと思いました。WordPressが単なるWebサイトのツールではなく、RDBS(リレーショナルデータベース)を駆使したシステムであるということを改めて認識しました。対策として挙げられた自前SQLでなるべく処理を軽くする抽出条件をSQLではなくPHP側に分散させることでボトルネックを解消するというのも、システムプログラマとしてよく経験するであろう内容で、この部分でもサーバサイドプログラム(PHP)とSQLに精通したバックエンドエンジニアが必要ということが窺えます。後半の「初期仕様を把握している人間がいない」「コミュニケーション不足」「ドキュメントがない」というのも現場あるあるではあるものの、改めて社内ドキュメントが大切であるかを考えさせられました。い合わせフォームなどまとめ運用はきちんとやる。APIを使って、WordPressを使ったサービスを考えよう所感WordPressのサーバ構築・運用周りにフォーカスして、「単純にWordPress上でテーマ(デザインテンプレート)を変更してサイトを構築」とは異なった趣のサイト構築・運用の提案を示すセッションでした。cssといった上層まで、多様なレイヤーの知識・技術が求められます。JavaScriptといったフロントエンドをWordPressと切り離すことで負担を分散させるといった考え方を使い、そのための具体的な手法を示していました。保守運用は皆苦労するところなのだとしみじみ感じました。Fieldではいろいろ問題点が......カスタムフィールドに全て登録されるので、通常のWordPressの検索ではヒットしない(デフォルトはタイトルと本文のみ)カスタムフィールドも検索対象になるように自前でカスタマイズすれば良い。したブロックエディタによって、それまで行っていた業務をより便利にカスタマイズできるようになる方法などの例示。画像を任意の枚数を売乳する)のは難しい縦に分割されたコンテンツの列数を増減させるのは難しいブロックエディタ:同じパーツを繰り返すことができるデフォルトで用意されているブロックで、縦に分割されたコンテンツの列数を増減させることが可能といったところが挙げられると思います。テキストベースのコンテンツのレイアウトや流用性・拡張性ではブロックエディタが有用ですが、カスタムフィールドの全てがブロックエディタで置換できるかというと、カスタムフィールドの方が有利な場面もあり、ケースバイケースで使い分けることができるのがベターだと思います。ブロックエディタをカスタマイズする場合はNode.jsやReact.jsといった最近の高度なJavaScriptを必要とする場合が多いため、技術スキルの専門性が高まるということも留意事項として挙げられます。した点を考慮して、上手く付き合うことができれば良いと思いました。他の技術と組み合わせることで、WordPressのコンテンツ管理の部分とデザインの部分を切り離し、新たな価値を提案する内容のセッションでした。WordPressを使った新しいプロダクト・サービス開発について考える」のセッションとも重複しますが、アップデートなどの運用部分も管理するサービスの「マネージド(managed)」やクラウドを利用する開発環境内でコンテンツを取得・含んだ状態で静的サイトとして生成してしまうということでセキュリティなどのリスクを下げつつ、表示の高速化などのメリットを受けるという新しい開発・運用のワークフローが提示されました。毎日のように更新するようなサイトではなく、更新頻度の少ないコーポレートサイトやランディングページのような期間限定ページでは上手く利用できると思うので、自分でも上手いことができないか考えさせられました。アクセスの度にWordPressサーバにデータを取得するようにプログラミングする(動的生成。ブラウザ上で動くクライアントJavaScriptではなく、Node.jsをインストールしたサーバ環境内で動くサーバサイドJavaScriptとして。その意味ではPHPと立ち位置的には近い)Netlify(Node.jsベースのホスティングサービス)を使うShifterもnetlifyへ投げる機能ありといった方法が考えられるとのことでした。したがって、「JavaScriptで完結できる」という意味ではバックエンドとフロントエンドは分離できますが、代わりに(ここ最近の新しい)JavaScriptの高度な知識が必要になると思われます。他の方法としてCIとの連携となるとそうした環境の知識・技術も必要になるため、継続してスキルアップが必要だと感じました。セッション外での情報収集スポンサーブースでいくつか情報収集もしました。AMP特に印象に残ったのは、GoogleのサーバがキャッシュしてくれるAMPですが、暫く見ないうちにカルーセル等のアニメーション的な要素にも対応し、Webコンポーネント化していたことでした。数年前は静的サイトの高速キャッシュ、というイメージだったのですが......いつの間にこんなに化けていたのか......。アフターパーティアフターパーティはダンスクラブでした。去年とは違う場所で、音が小さい小ホールも用意されていたので大声でなくても会話ができる、ということで進化していました。備考どのセッションでも、登壇者の発声とほぼ同時に文字起こし、英語翻訳されたものがスクリーンに表示されていました。これはUDトークというアプリを使用していたようです。凄まじいテクノロジーの進歩を感じました......。アフターパーティ会場への移動の途中でスバルビル跡地の「新宿の目」も観てきました。イベントこの記事を書いた人アルム=バンドフロントエンド・バックエンド・サーバエンジニア。LAMPやNodeからWP、Gulpを使ってejs,Scss,JSのコーディングまで一通り。RasPiで遊んだり、趣味で開発したり。Meetupに参加してきたので、そのレポートを軽くまとめます。参加レポート食器を洗う水と一緒に、ラジオ体操が流れている。