2020年1月 2日(木)
2019年10月19日に大崎ブライトコアホールで開催したCSS Nite LP64「Coder's High 2019」のフォローアップとして、阿部 正幸さん(モチヤ)の『ウェブ開発のいまと、コーディングしない制作手法』セッションのスライドなどを公開します。
CSS Nite LP64 Coder's Highに参加の皆さま、長時間のセミナーお疲れ様でした。
第2セッションの「ウェブ開発のいまと、コーディングしない制作手法」に登壇させていただきました、モチヤの阿部と申します。
今回のセッションではコーディングしない制作手法の話をさせていただきました。
弊社の場合ですとDrupal(CMS)を使っておりますが、これはWordPressでも、
concrete5でもどのCMSでも同じ作り方が可能です。
コーディングしない制作手法は、世界では一般的な流れですので、ぜひ一度お試しいただければと思います。
セッションを終えまして皆さまからご質問いただきました内容です。
Q.「工数が大幅に削減できる」とありますが、デメリットのときに「フロントエンドの開発工数があまり変わらない」と仰ってました。実際どの部分の工数が減らせるのでしょうか?
A. 説明が分かりにくくて申し訳ございません。
フロントエンド(HTML、CSS)の組み込みの工数は結果あまり代わりまんが、CMSの組み込み工数やテスト工数は、大幅に削減できます。
理由はあらかじめ作っておいたHTML構造に合わせてCMS側で、無駄なコードを書かなくて良いから。CMS本来のカスタマイズがし易くなるためです。
Q. パフォーマンスバジェットの担保が難しそうだけど、そうでもないのかな?CMSに丸っとやってもらう感じになりそう
A. CMS独自のキャッシュ構造を使うので、ある程度のレスポンスは担保できます。
サーバーサイドに関しては、CDNを入れたり、Varnish、OPcache、スケールアップ、アウトで対応しております。
サーバーサイドのキャッシュ機構、Webサーバー、CDN、等々ある程度決まったものを会社として使っています。
Q. この制作手法は案件規模はどの程度まで対応できますか?
A. 50ページくらいのサイトから、誰もが知っているような会社の大規模サイトまでをこの手法で行なっております。
あまりにもページ数が少ない場合は、静的で構築した方が効率は良いかと思います。
Q. バックエンドの脆弱性がCMSに依存すると思うのですが、致命的な脆弱性が発見された際の初期対処はどうされてますか?
A. クライアントが大きいと、パッチが出てから適用までにスケジュール調整や、パッチの検証などすぐに実施することができません。
セキュリティ担保のために、WWWからオリジン(CMS)にアクセス出来ないようにシステム設計をしています。
セキュリティパッチが出てからDevで検証し、Stgにアップし、Prod(本番)に適用を行なっております。
参加いただきました皆さまありがとうございました。
また皆さまにお会いできることを楽しみにしております。下記は私のソーシャルアカウントです。
お気軽にフォローください。
2019年、CSS Niteでは49回の関連イベントを通して123セッションが行われました。その中からベスト・セッション+αを選びました。