動かしながらテストするテストでは品質は上げられない。品質を上げられるのはコード。感想Fusicのテスターが一人とは思わなかった。言いたいことは実感としてわかるんだけど、職人の技が光っていて中々横展開ができなさそう。あとテスターにエンジニアの経験があるだけでテストする側もされる側もだいぶ変わるんだろうなぁっと思う。いう意味では羨ましい限り。(@sasezaki)発表資料が公開されている。発表資料が公開されている。wayを書いた人が作ったマイクロフレームワーク。middle、PSR-7、di-containerしか無い軽量なフレームワーク。composerなどのおかげでライブラリが外に出ていく傾向があり、slim2からフレームワークとして提供している機能が減っている。感想Slimは前から気になっていたフレームワークなので概要がわかった感じ。言っても実戦投入ってレベルの理解まではできていないので、これも今後の課題にしたい。複雑じゃないAPIサーバなんてのだったら簡単にかけるんだろうけど、もう少し複雑なものになるとどういう風にするのか辺りが気になるところ。(@miya0001)発表資料が公開されている。APIで操作するための仕組み。現時点のバージョンではWP-APIプラグインが必要(4.7からCoreに取り込まれる予定)。プラグインで拡張することも可能。APIで解決できることWPをバックエンドシステムとして扱える普及しているWPの管理画面を使えることは利用者の学習コストを大幅に下げることができるフロント側では本番環境でもステージングでもライブデータを扱えるマイクロサービスの一部としてのWP。他のCMS都の連携もAPIの結果にキャッシュを効かせることができるようになる開発のワークフローの改善(フロントとバックエンド)実例フロントエンドをnode.js+React。バックエンドをWordpressフロントのサーバはDockernpmのサイトもバックエンドはWordpressnode.js側でキャッシュしているのでWP側が落ちても大丈夫NewYorkTimesやWiredなどでも利用されているWP-APIはWPのテーマ主体としたエコシステムを変える存在になりうる。カスタム投稿タイプはWPのボトルネックになる。WP-APIで複数のカスタム投稿タイプを利用するのであれば、WP自体をカスタム投稿タイプごとに分けてしまうのもあり。感想タイトルの段階では特に興味はなかったんだけど、今回一番面白い話だった。確かにWordpressのフロント側ってのは面倒くさいんだけど、Wordpressのバックエンドは使いたいって要望はありそう。いうか本編中でもあったように利用者の学習コストを大幅に下げることができる。それに加えて、バックエンド側を開発するコストも大幅に下げることができるので、案件全体の省力化が見込めるような気がする。カスタム投稿タイプ周りなんかもあるので、テスト的にやってみてその辺りを確認してを見てみたい。2と一番変わったところは、ModelのEntity。これを有効に使うことでModelの負担を減らし、よりCakePHP3らしいコードを書くことができる。別の方が補足記事を書いてくれている。(@debility)発表資料が公開されている。(@nojimage)発表資料が公開されている。(@tette)発表資料が公開されている。(@sizuhiko)発表資料が公開されている。(@uzulla)発表資料が公開されている。(@kaz_29)発表資料が公開されている。(2)はてなブログをはじめよう!atyksさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。