トーク

皆さんはこんな課題ありませんか？
・そろそろLaravelのサポート切れるのでバージョンをアップしないとまずい。
・でも、手動で一つ一つコード書き換えていくのが大変。

そんな時に便利なのがLaravel Shiftです！
Laravel Shiftは簡単にいうと、課金すれば Laravel のアップグレードを自動でやってくれるというものです。
今回は実際にLaravelリポジトリのバージョンアップをしてみた体験談も交えて話します！
ただ、一筋縄ではいかなかったので、その辺も含めて話します！笑

太古の昔、サーバーの設定をいじるとなると、プロフェッショナルなインフラエンジニアにお任せだったと聞きます。
我々（PHPer）の手に負えない程大きくなったインフラの管理は、それこそ職人技だったのだと想像できます。

一方現代、インフラの多くはクラウドです。
皆さんもAWSなどを活用していると思われますが…形だけのクラウドになっていませんか？
クラウドの登場で誰でもポチポチ簡単にサーバーを建てれるようになりました。が、"本番環境にそびえ立つ謎のサーバー"や"誰も設定がわからないLB"などオンプレ時代とそう変わらない問題を大なり小なりどの現場も抱えているかと思います。
我々はいつまでコンソールの画面をポチポチしてサーバーを作るのでしょうか？

昨今IaC呼ばれる便利ツールが流行っています。ただ、メリットがわかっていても、「キラキラでなんか怖い！」「うちには導入できない！」と思われて二の足を踏んでいる方もいることでしょう。
大丈夫です。我々が「ポチポチコンソールによるAWS」から「IaCによるAWS」にマイグレーションした過程をお話します。
「最初からすごい人がいたんじゃないの？」と思われるかもしれませんが、そんな事ありません！移行の過程で一つずつコード管理を進めました。
いまあるサーバーを動作させながら少しづつIaC化しましょう！

本トークでは
・TerraformなどIaCをつかうメリットを紹介
・アプリケーションエンジニアがTerraformを使えると良い理由
・ポチポチコンソールで作成した現在稼働中のサーバーを、Terraformで管理する方法・Tips
を話したいと思います。

※話さないこと
・ツールのインストール方法や、チュートリアルレベルのお話
・PR TIMESのAWS移行時の具体的な作業の説明

本トークを聞き終わった後に、PHPerのみなさんが「自社のサーバーをIaCツールで管理したい！俺らの手でやるぞ！」と思えるトークを目指します！

私たちの運営するサービスは、コア機能部分が未だにレガシーコードとなっており、リファクタリングが必要な状況になっていました。
しかし、影響範囲が大きくテストもないので中々触りたくない、サービスの成長（機能追加）のための開発と両立できない、自分の担当プロジェクト以外は分からない、等など一筋縄では行かない問題もありました。

そこで私たちは、月に一度、大規模にリファクタリングが可能な日（リファクタリングデー）を設けました。
リファクタリングデーでは通常の開発を１日止めて、コア機能も含めた影響範囲の大きい箇所のリファクタリングを行い、全ての機能をQAしてリリースします。

このトークでは、リファクタリングデーを行うために何をしているのか、また、実際に１年ほど行って感じたメリットや、課題などについて説明します。

話すこと

• 大規模にリファクタリングを行うための開発フロー（スケジュール）
• あまりコツは必要無いという話し

話さないこと

• リファクタリング手法・設計の話し
• 自動化などの仕組みの話し

備考

https://developers.prtimes.jp/2021/12/13/introducing-refactoring-day/

「推測するな、計測せよ」という言葉を耳にしたことがあるかもしれません。

例えばアプリケーションのパフォーマンス改善を行う場合に行き当たりばったりでアクションしてもうまくいかないことが多いと思います。

そのためにはまず実際の状況を知るための、「計測」するというアクションが大事です。

例えばツールを使ってコードのメトリクスを取るのもよいでしょう。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「現状把握」をすることができます。

さまざまな値を取得すると有用な値やそうでない値なども出てきます。
その上で取得した値を分析・考察したり組み合わせて、「判断」をします。どこがアプリケーションの改善点なのか…？何がアプリケーションにとって最適なのか…？？プロダクトにもっとも寄与するためには…？？？

このように、推測で考えずに「計測」して「現状把握」を行い「判断」するというステップをもってカイゼンへのアクションを取ることが大切だと考えています。

このトークでは実際にどのように考えてアクションに移しているのか？どのように計測から現状を把握し、判断を持ってカイゼンのためのアクションをとっているのか？というエッセンスをお話しできればと思っています！

先輩「この実装はどうしてこうなっているの？」
自分「ここは〇〇という理由でこうしています！」
先輩「了解です、その説明はコードコメントに書いておくとよいので追記お願いします～」
コードレビューを受けているとき、こんな経験はありませんか？

コードで表現できないことを説明したいとき、それを書く場所の候補はコードコメント、コミットメッセージ、プルリクエスト（説明欄やコメント）と多岐に渡ります。
「どこに書けばいいのかわからない！」そんなときの指針となるお話をします。

数年間で成長してきた自社プロダクトが、増加したトラフィックを処理できない問題に気付き、
AWSインフラをリプレースすることにしました。

2016年に立ち上げられた自社プロダクトは、利用者数と利用コンテンツがどんどん増えていきました。
さらに、利用プラットフォームもウェブとガラケーからモバイルアプリへと拡大し、利用者の利用頻度も急激に増加しました。
具体的には3年で利用組織が6倍、ユーザーが6倍になりました。
それに伴って、サーバーへのトラフィックも急増し、ボトルネックになりそうな状態に陥りました。

しかし、サーバーは今後も増え続けるトラフィックをうまく処理できず、高いレイテンシで応答するか、最悪の場合システムがダウンするほど可用性が低い状態でした。さらに、障害へのトラブルシューティング対策も不十分で、不安が募りました。

そこで、AWSインフラの問題点を洗い出し、対策案を立てました。
固定台数のEC2インスタンスで対応していたサーバーを、
負荷分散と自動スケーリングが可能な仕組みに変更しました。
さらに、サーバーで行われていたさまざまな処理をサーバーレスに移行し、
自動フェイルオーバーの仕組みも導入しました。
特に、数年間継続して運営してきたサーバーを含むインフラを一新するにあたり、
インシデントが起きないようにリリースまでの流れに検証の内容をしっかり盛り込みました。

• インフラ設計 ‐ 草案
• インフラ構築・実現検証 ‐ デモ
• サーバー簡素化
• システム改修
• プロビジョニングツール導入
• 構築・確認・検証 ‐ デモ
• インフラ設計 ‐ 最終版
• 構築・確認・検証 ‐ 本番
• インフラ切り替え
• ヘルスチェック・イベント可視化

その結果、トラフィックが増えてもうまく分散できるインフラが整い、
低レイテンシでサービスを提供することができるようになりました。
また様々な検証のおかげで、プロダクトに障害を起こさずにインフラのリプレースが実現できました。

このセッションでは自社プロダクトでインフラのリプレースを行った背景ときっかけ、そして実際にリプレースを行った流れを紹介させて頂きます。

現代のフロントエンド開発は、過去と比較して複雑化が進んでおり、HTMLの仕様に対する意識が低下しがちです。アクセシビリティの向上がますます重要視される中、HTMLはその基礎であり、正しい仕様の理解と実装が不可欠です。しかし、HTMLの仕様は想像以上に複雑で、WAI-ARIAなどの関連技術も含まれています。

このライトニングトークでは、Markuplintというツールを開発者が自ら紹介します。
Markuplintを導入することで、開発者は複雑な仕様を覚えることなく、リンターが問題点を指摘し、開発に集中できるようになります。

内容:

1. アクセシビリティの重要性とHTML + WAI-ARIA
2. クイズ: このHTML正しい？
3. Markuplintの紹介と導入方法

このトークを通じて、参加者にMarkuplintの有用性を理解していただき、より品質の高いWeb開発が行われることを期待しています。

MVP, Minimum Viable Product 顧客に価値を提供できる最小限のプロダクト。
よくアジャイル開発の文脈で「プロダクトはMVPから作りましょう」という話を聞くと思います。
たとえば初日にシステム全体のサイトマップを書き始めたり、ユーザーModelやログイン機能から作っちゃダメということです。
「価値を提供できる最低限」を見極めて、顧客の課題を解決するコアとなる機能から作る考え方とコツをお伝えします。