参加しました!ので、珍しく参加レポートとこっちにも投稿します。上の写真は、受付でもらったクリアファイルとしおりです。マイクロスポンサーとして参加登録したので、可愛い限定パーカーもゲットしました。Meetup(旧WordBench)には何度も参加してきていたのですが、報告はたいていFacebookで済ませていました。今回もそうしようと、ちまちまFacebookを更新していたのですが、「シェアできないからブログ記事にして!」とありがたいお言葉を頂いたのでした。記事にすればええやんな。金曜日がコントリで、土曜日がセッションです。金曜日はお仕事があったので、残念ながら不参加。仕事終わりにそのまま新幹線で向かいました。)こういう時にしか食べられないので、新幹線で食べるお弁当は、押し寿司率が高めです。ホテルに着いたのは12時くらい。ほとんど何もせずに寝ました_(-ω-_[▓▓]次からは日曜日、セッションデイの1日を書いていきます。大丈夫!実例で見るウェブパフォーマンス改善」です。大丈夫!実例で見るウェブパフォーマンス改善ウェブパフォーマンス、あるいはウェブページの表示速度は、ウェブサイト品質の重要な指標の1つです。今注目されてい...osaka.wordcamp.orgスライドも公開されています。ここのところ業務でWEXALを用いた高速化ばかりやっているので、そういったエンジンを利用しない場合の改善施策や、新しい手法を知りたくて聞きに行きました。今はJavaScriptで実現するしかないlazyloadですが、先日属性付与だけで実現できるようになるかも!?という記事を読んで、わくわくしたものです。Chromeだけなんですね...早く他ブラウザも対応して欲しい...!!以下はFacebookに投稿した、箇条書きメモです。HTTP/2などなど不要プラグインのアンインスト(1千万レコード、1.4GBまでデータを溜め込んでいるプラグインに遭遇)最適な画像形式の選択。色数少ないならsvg、多いならjpg...可能ならWebP。SVG書き出しは、イラレはスクリーン用に書き出しで。他はそのままでもOK。WordPressはセキュリティの観点から、デフォルトではSVGのアップロードを許可していない。og:○○系がSVGに対応してないので、別途jpgやpngを用意する必要あり。オフスクリーン画像の遅延読み込み。loading=”lazy”属性付与がおすすめだが、今はChromeのみサポート(最近デフォルトで対応してくれるようになった)。lazyloadプラグイン、Google製。他ブラウザでもJSで対応してくれる。Worker、ブラウザにキャッシュを保存してくれる、オフライン表示を再現。最終的には静的化、Shifter。コーディングあり改善施策ページによってCSSとJSの読み込み制御。レンダリングを妨げるリソースの除外(スライド参照)※この表にWEXALも並べれば違いが分かりやすそう。WordPressでやるなら、preg_replace()しかない。resource_hintsフックあり。dns-prefetchについては、enquereにフックしてるものをWordPressが自動でタグ追加してくれる。WordPressはAPIとして使う。減らすのは人しか出来ないが、簡単ではない。いうものを作って、どこまでやるか。伸一さんのセッションを聞きました!「エンタープライズ向けにWordPressを提供するためにあなたとコミュニティができること」です。エンタープライズ向けにWordPressを提供するためにあなたとコミュニティができることウェブのソリューションを提供している会社が、エンタープライズ(千、万単位の従業員がいたり、グローバルに展開して...osaka.wordcamp.orgスライドも公開されています。shinichi.nishikawa.www.canva.comタイトルからはなかなかどういったお話になるのか想像ができなかったけど、聞いてみるとすごく夢のある話でした。これが実現できればコミュニティがさらに発展しそうでわくわくしました。ひとつの会社というか、パートナーシップというか・・・なんか、いろいろと考えさせられました。私もどこかしらの「必要になること」への参画ができるといいな。以下はFacebookに投稿した、箇条書きメモです。Web周りで必要になるのはデザイン、開発だけではない。セキュリティとかドキュメンテーションとかワークフローとかユーザー管理とかプロマネとかサポートとかアセット管理とかとかとか。全部できる人はいないから、サービスとして提供している企業があり、そこに頼んでいる企業がある。やってることみたいだ。タッチポイントが様々、WebやIoTや店舗、DMなどと組み合わせ。パーソナライゼーション、平均からの脱却。APIファースト、様々なツールとの連携。これは大企業だけの関心ではなくなる。理解してコミュニケーションしたい、エンゲージメントを高めたい。Webサイトを持つ意味の変化→「顧客理解とコミュニケーション」「ビジネスそのものになっている」「IT部門への社内外注からの脱却」「ビジネスの基盤」\実はまだ本題ではない!/WordPressはハブとして動けばいい。前述したたくさんの必要なことは、コミュニティ内に得意な人がいるはず。\ここから本題!/それぞれ得意な人が集まればいいじゃん、というか集まってるじゃん。一人でじゃなくて、一人ひとりの力で。共同でリサーチ、ケーススタディなど。CodeGuru」が...dev.classmethod.jp今はまだ日本では利用できないし、Javaのみ対応だけど、あっという間にいろいろな国と言語で利用できるようになるんだろうな。コードレビューって工数けっこうかかるので、自動でやってもらえるならすごくありがたい!!もう既にコードレビューができるのだから、AIがコードじたいを書けるようになるのも時間の問題ですね。前もちょろっと考えてましたが、今WEXALを使っていても、AIって本当にすごくて・・・将来確実に、エンジニアの仕事ってなくなると思います。発想や提案だけAIに渡せばそれで勝手にプログラミングしてくれるとか。プログラミングするって曖昧なところがないから、画像認識とか音声認識と比べても、AIの得意分野ですよね。今後残る仕事ってきっと、人間がやらなきゃ意味がなかったり、必要とされないような仕事だけなんでしょうね。介護とか画家とか作家とか俳優とか・・・10年後にはもう仕事ないだろうなとか考えて、今後どうしようかとうっすらと考えていたりします。時間はお昼、ランチタイムです。大阪にきたので、大阪っぽいランチが食べたい!ですよね!!去年は近くのお店でたこ焼きを食べました。́ڡ`๑)今年はどうしようか、昨年たこ焼きだったから、お好み焼きとか?・・・近くにお好み焼きお店はあまりないね・・・またたこ焼きかなあ・・・と、調べに調べて行き着いたお店がこちらです。阪急東通り(大阪).町田.札幌.新潟.淡路.香港。美味しそうな食べ物の写真が撮れるようになりたいです。その後会場に戻って、スタンプラリーに挑戦。いつもより少し苦戦し、集め終わりました!左が私のわぷーです。広武ハムさんのセッション、「運用も最大限考慮!コーポレートサイトでブロックエディタフル活用の事例紹介」です。運用も最大限考慮!コーポレートサイトでブロックエディタフル活用の事例紹介ブロックエディタがリリースされる前の2018の秋口から、リリース後すぐの2019年年明けにかけて、大きめのコー...osaka.wordcamp.orgスライドも公開されています。スライド内で共有されていた記事やスライドをいくつか掲載しておきます。過去の関連スライドテーマ作成者必読。live...wptavern.comGutenbergがリリースされた当初は、私も「HTMLコーディング好きだから、ブロックエディタなんて嫌だ!マークアップ考えさせろ!」とか思ってましたが、今はがっつり使って記事を更新しています。セッションの中でも言われていましたが、本当に設計次第で、「the_content()だけで全部出せる」んですよ!テーマのコード書く量も減れば、クライアントの自由にレイアウトできるから、「ここはエディタ外の変更だから工数かかりますねー」とかもなくなる。それと・・・ブロック間の余白は統一したいはめちゃくちゃ同意です。私は新人のときでも、デザイナーさんに「ここの余白ってこっちと違うの合ってますか・・・?」とか聞いたりしてましたもん。以下はFacebookに投稿した、箇条書きメモです。最初に大事なこと札幌には「赤くて美味しいタピオカ」があるから、遊びに来てね!ブロックエディタで設計が変わった投稿コンテンツが全てブロックエディタ入力対応のサイトをリリースした。ブロック→カラムブロックを使う。カスタマイズとして、画像や商品名を再設定でなく既存記事を参照するようにした。Blocksプラグイン表ブロックのスタイルを用意。リストブロックも用意。高い投稿タイプはわかりやすく、お客様も運用しやすいようにブロック構成。いじらない特殊なページはHTMLで構成。再利用ブロックにカテゴリが設定できるようにした。変更頻度が高い再利用ブロックに専用のリンクを用意。設計4ヶ月、開発2ヶ月、調整1ヶ月、入力1ヶ月。設計の4ヶ月は、ブロックエディタ採用前からの提案だったから。ブロックエディタ使っていいか、こんなものです含めた期間。ワイヤーの段階でブロックを確定させること。ワイヤー確定後にブロック精査か、ブロック確定後にワイヤー作るか、どっちでも。今なら後者の方がいい。デザインやワイヤーから、どのようなブロックが必要かなどをまとめていく力が今後ディレクターに求められる。仕組みや構造が一緒でデザインだけ違うかなど、抽象化。カスタムブロックさえ作れば、コンテンツに全部入る。the_content()だけで全部出せる。カスタムフィールド前提の設計と構築を避けたかった。この話は今に始まったことじゃない。理想はデフォルトテーマに変えても機能するような設計と構築。外観とコンテンツを分離するため。カスタムフィールドの利点として、入力の制限と明確化があり、表示崩れ防止や運用のしやすさがあった...が、制作やメンテに負担がかなりかかっていた。私のベストプラクティス」スライドは、テーマ作成者必読。WordPress案件は難しい。機能が増えて、できることも多くなったから。運用も踏まえて仕様を詰めることと、ブロックエディタの理解が必要。デザイナーは特にどんなHTML構造か、どんなスタイルがついているかの学習が必要。ここの学習コストが増えてきた印象。ブロック間の余白は統一したい。隣あっているブロックによって余白を変えると制作工数が増える。デザイナーさんには、そのこだわりでどれくらいのコストがかかるのか知って欲しい。まとめブロックだけでページ構成できるように。制作ブロック数で工数が変わる。スタムフィールドは最小限に、使うならコンテンツ以外の構成に。英語記事だがコメントまで合わせて見て欲しい。WordPressサーバーの保守運用コストを最小化するための技術・概念として広まりつつあるServerlessおよびJAMSta...osaka.wordcamp.orgスライドも公開されています。2019のスライドです。speakerdeck.com実は、JAMstackというのを一切知らない状態で聞きに行きました。タイムテーブル見ていた時に、黄色い方が「へー、JAMstack話すのかー」みたいな反応だったので、そんな注目されてる技術なのかな?!みたいな。そんな初心者でも、おおまかにどんなものか分かるくらいに、わかりやすいセッションでした!いまいま簡単に導入するには私のスキルが足りないけど・・・別のWordPressの使い方として覚えておいて、粛々とJavaScriptの勉強しなくちゃですね。以下はFacebookに投稿した、箇条書きメモです。今の技術で阿部寛のサイトを目指そう!事前生成したHTMLを配信。WordPressテーマがmarkup、DBがAPI。markupにAPIデータをマージしてHTML生成。WordPressに使うのか早い、強い、固い、楽アクセス経路の一本化でリスクを局所化。処理とDBとフロントの分離でスコープの明確化。使うのかWordPressをAPIサーバとして採用し、Jとmの技術選定、JAM、運用のワークフロー整備。重複コンテンツに気をつける。ログイン以外は301、カノニカルやノーインデックスの設定。WordPressをメンテしないでいいようにフルマネサーバを検討。StaticGen今はReact(nextなど)やVeu(nuxtなど)。なんでもいいけど、書き方やAPI、頼れる人がいるかなどで選定。Angularはあまりメジャーじゃない使い方になる。