フロントエンドやバックエンドのような技術的関心事で担当領域を区切るのではなく、プロダクトが価値を提供するために技術面全般へ責任を持つ「フルサイクルエンジニア (full-cycle developer)」という考え方があります。

本トークでは、フルサイクルエンジニアという働き方についての説明と、私がフルサイクル開発者として5年ほど仕事をしてきた中で「良い仕事」をするために意識していることをご紹介します。

対象観客

• フルサイクルエンジニアという考え方に関心があるかた
• フロントエンド/バックエンド/インフラだけを専門的にやっているがこれで良いのか？という悩みを抱えているかた
• プロダクトについてもっと責任を持ちたいと考えているかた

話すこと

• フルサイクルエンジニアとは何か
• フルスタックエンジニアとの違い
• 専門性についての懸念
• どうあれば「良い仕事」と言えるのか
• 「良かった」とフィードバックを貰えた仕事例

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
もともとソフトウェアエンジニアにとってテレワークは相性が良い部分もあったことから、様々な利点をもたらしてくれました。
その一方で、良いことずくめに思えたテレワークも、新たな問題をもたらしたこともまた事実でした。

従業員どうしの関係性や勉強会等の活発さといった文化をひとつの強みとしていたエンジニア組織は、テレワーク導入直後にはその強みがほとんど見えなくなっていました。
もともと組織には「開発組織活性チーム」というチームが存在しており、テレワーク導入による問題が無視できなくなってきた頃、「失われつつある組織文化を取り戻し、維持すること」を新たなミッションに掲げて活動内容を変化させました。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

スキーマ駆動開発を行っていくと実装とスキーマが乖離してしまい辛いという話をよく聞きます。

スキーマ定義自体はOpenAPIを利用するケースが多いと思いますが、OpenAPIはエコシステムが充実しているが故にツールの組合せだったり、APIを作成する際の開発手順は様々だと思います。
本セッションでは如何にキーマ定義と実装に乖離が発生しない・させない様に開発フローにまで踏み込んで実現させた事例を紹介したいと思います。

トークの狙い

• スキーマ定義をどの様に扱い開発フローに組み込むと良いか？を理解できる
• 利用するツールとそのテクニックに触れることができる

今年 3 月に開催された PHPerKaigi 2023 にて「いろいろなフレームワークの仕組みを index.php から読み解こう」と題して 4 つの Web アプリケーションフレームワークの共通点から、（PHP の）Web アプリケーションフレームワークと呼ばれるものがどうやって動作するのか、一般に何の役割を担っているのか、というお話をしました（https://fortee.jp/phperkaigi-2023/proposal/e68c1ed6-8fb4-4ff9-9d99-99214d9dba8d）。

ならば今度は「共通点」ではなく「差異」に着目し、各フレームワークが提供しようとしている価値や設計思想の違いについて比較、考察した結果をお話します。
今回は index.php にとどまらず、フレームワークが備える機能やエコシステム、公式ドキュメント等も比較の材料として扱います。

本トークで扱うフレームワークは以下の通りです。

• CakePHP
• Laravel
• Slim
• Symfony

AWS上で構築したWebアプリケーションを開発したとき、PHPをメインに使っていてもフロントエンドから amplify を使って直接サーバーリソースにアクセスすることもあるでしょう。

これまで長らく使われてきた aws-sdk-js（以降 aws-sdk）は v2 から v3 となり、モジュール別のパッケージとして展開されるようになりました。

私も担当しているプロジェクトではサーバーサイド、クライアントサイド共に TypeScript を使っていますが、 aws-sdk v2 が本年中にメンテナンスモードに入ることから v3 への移行作業を行なっています。

そこで蓄積された v3 移行のナレッジや、ハマりポイントなど、v3 移行の現場から生の声を稲妻トークでお届けします。

家を買うべきか、買わないべきか。
買うとしたらマンションか、戸建てか。
勤続年数が浅かったりフリーランスだと住宅ローンの審査が通りにくいという話は本当か。

家の購入って分からないことが多すぎて無限に悩みますよね。

本トークでは、家を購入するに当たって自分自身が調べたことや不動産屋に相談したことからの学びをご紹介します。

対象観客

• 家を買うか買わないかで迷っている
• 転職・独立を考えていて、住宅ローンが組めなくなるのか不安
• 家を買おうと思っているが何を気にするべきか、いくら現金を用意する必要があるか知りたい

話すこと

• 家を買うべきか、買うべきでないか
• 物件を選ぶときに考慮するべきポイント
• 家を購入するのに必要なお金
• 住宅ローンうんちく (金利、返済方法、借りやすい金融機関)

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

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

Google App Engine はリリース当初の2009年よりPHPをサポートするPaaS基盤です。
第一世代と呼ばれる言語仕様に制限のあった状態で PHP5.5 のサポートが行われてきました。
その後言語アップデートに関しては無料枠のあるスタンダードエディションから、有料で利用できるFlexエディションで実施されるようになり、次第にGAEの注目度は下がっていたように思います。

しかし2018年、GAEはgVisorベースの第二世代によってPHP7.2をサポートするようになり、それ以来最新の言語バージョンに追従するようになりました。

このセッションでは、GAEをご存知でない方や、第二世代のGAEを利用したことがない方に向けて、PHPアプリケーションをGAEのスタンダードエディション第二世代を動かすための概要やメリットを紹介します。

また、私も第一世代よりGAEを使って長年個人サービスを運営していますが、このたび2024/1/30をもって第一世代および第二世代のPHP7系ランタイムサポートが終了されるアナウンスがありました。
これにより私の第一世代で運用しているPHP5.5アプリケーションも一気にPHP8.1へジャンプアップする必要性も生じています。
こちらの移行の最新状況や、どのように移行しているかも含めた、GAEに興味がある/使っている人に向けたセッションになります。

テストコードの書き方について説明する資料等は世の中に充実しつつあります。
一方で具体的にテストコードを書いていく様子を説明、実演する資料というのはまだ数が限られています。

そこで今回はソフトウェアテストの領域でよく題材とされる「マイヤーズの三角形問題」の実装を取り上げ、
素朴な PHP コードからはじまり、テストコードを補いながら、ときにつまづきつつ、解くべき問題を捉えたコードへと洗練させていく過程を実演します。

本セッションで扱うテーマ

• テストファーストなアプローチによるコーディング、リファクタリング
• PHPUnit の基本的な使用法と data provider の活用

本セッションで扱わないテーマ

• テスト戦略やテスト設計について

（PHPerKaigi 2023でパンフレットに寄稿させてもらった https://fortee.jp/phperkaigi-2023/proposal/caec413f-384d-415e-8020-59053058a1f6 のトーク版です）

今ではオープンソースソフトウェア（OSS）を使うことは当たり前になっています。このことに異論を挟む人はいないでしょう。

ところで、「OSSへのコントリビュートをするのは敷居が高い」「OSSを作るのはなかなか難しい」とよく聞きます。
確かにそれもOSSの1つの側面かもしれません。

そこで提案です。趣味としてOSSを書くのはどうでしょう？
実はOSSは趣味で書くのもアリなのです。
皆さんの中にも「プログラムが好き」「プロダクトが好き」「モノづくりが好き」という方は少なくないはずです。
そんなあなたは趣味OSSの素質ありです。

筆者は「少し実用的で小さなOSSを書くのが趣味」と公言しています。
あくまで「いち趣味の紹介」としてOSS開発のはじめかたをお伝えできればと思います。

そして、オフライン発表だからこそできる、私の積みOSS（ネタ帳）を全てお見せします！
これは発表資料には含めない予定なのでその場限りの公開になるかもしれませんよ。

PHPのDockerfile、秘伝のタレとなっていませんか？なんとなくのコピペになっていませんか？特定の人だけが触っていませんか？

【この発表のゴールについて】
Dockerfileの書き方を解説し、効率的なPHPのDocker環境を構築を迷いなくできるようになることを目指します。

【発表内容】
PHP8.2の実行環境を構築するということを前提に、以下の内容に触れます。

1. Dockerfileのお作法:
   Dockerfileの機能をおさらいしながら、最新の書き方が出来るよう解説します。

2. ベースイメージの選定方法:
   DockerHubにて公開されている公式PHPイメージにはいくつかの種類があり、タグ付けされています。(例えば8.2.4-alpine, 8.2.4-apache,8.2.4-fpm,8.2.4-cliなど) それらの違いを理解した上で適切なベースイメージを選べるように解説します。

3. PHPの各種拡張機能について:
   公式のPHPDockerイメージだけではアプリケーション開発は難しいです。拡張機能やパッケージを追加する必要があります。公式のPHPDockerfileを読み解きながら、何があり、何が追加で必要なのかを解説します。

【対象者】

• 自信をもってDockerfileをかけるようになりたい人
• PHPの拡張機能について理解を深めて行きたい人

【触れないこと・想定しないこと】

• Docker、Docker composeの詳細な説明やそのメリット・デメリットについて

Github Actionsでworkflowを作成してCI/CDされている方も多いのではないでしょうか？
本セッションでは2022年にリリースされたカスタムアクションで開発者体験が良かったものを紹介したいと思います。
実際にプロジェクトに導入して習慣が変わっていった体験談にも触れたいと思います。
関連してworkflowの作成時のtipsもいくつか紹介したいと思います。

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「ふぁっ！？」

、、、はい。あると思います。
そんなときはArray shapesなりで、ひーひー言いながら対応すると思いますが、泣きながらこう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」と。

今回のトークでは、そういった疑問をソースコードリーディングを交えながら、みなさんと一緒に解き明かそうと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

• PHPStanのレベル6について
• レベル5とレベル6での解析方法の違い
• 字句解析, 構文解析, 評価 について少し

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「ふぁっ！？」

、、、はい。あると思います。
そんなときはArray shapesなりで、ひーひー言いながら対応すると思いますが、泣きながらこう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」と。

今回のトークでは、そういった疑問をソースコードリーディングを交えながら、みなさんと一緒に解き明かそうと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

• PHPStanのレベル6について
• レベル5とレベル6での解析方法の違い
• 字句解析, 構文解析, 評価 について少し

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

概要

プロダクト開発激化時代において、 より魅力的で競合優位性のあるプロダクト開発をしていくために組織育成は必要不可欠であり、その中でも特に育成が重要であること。
開発組織の開発力、生産性を上げるために避けては通れないエンジニア一人ひとりの技術力アップをどのように推進しているか。
私がEMとしてここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について整理して話します。

トーク内容

プロダクト開発におけるエンジニア教育の効用
良いプロダクトを作るために必要な組織の特徴
組織を作るために欠かせない採用と教育
エンジニア教育する際のマインド、モチベーションをいかに引き出すか
質とスピードはトレードオフでは無いが、成長機会とトレードオフである
表面的なスキルからより基礎、より根幹のマインドが大事なワケ
レベルごとの教育スタンス（ティーチング、コーチングの使い分け）
教育にまつわる理論（認知特性やラーニングピラミッドを活用する話）
カンファレンスでしか得られない栄養
個のスキルから組織のスキルへの転換の仕組みづくり

想定視聴者

組織のエンジニア教育にミッションを持ち悩んでる人
エンジニアとして今後の成長方針に悩んでる人
教育に興味がある人

補足

本セッションは https://tech.willgate.co.jp/entry/2022/12/24/113000 に投稿したものを加筆し、よりブラッシュアップしたものになります。

含まれないもの

エンジニアに必要な個別技術の習得方法
エンジニアとしてどのような個別技術を学ぶべきか

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

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

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

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

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

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

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

リアルタイムOSとは特定の事象が発生してから、決められた時間内に処理を実行できるシステムを構築するためのOSです。
多くの場合、組込みシステムで用いられていて、例えば自動車や飛行機、産業制御装置などのシステムに利用されます。

リアルタイムOSには以下のような特徴があります。

・複数の実行コンテキスト(タスク)を持つことができる
・タスクには優先順位を設定でき、優先順位の低いタスクに割り込む形で、優先順位の高いタスクを実行できる
・タスク間でメッセージをやり取りしたり、リソースを排他制御する仕組みがある

本トークではリアルタイムOSの一つであるAmazon FreeRTOSを題材に、タスクの動作や各機能の活用方法、リアルタイムシステムの設計方法についてお話します。

このトークでは、技術同人誌を知らない人や初めて執筆する人に向けて、技術同人誌を頒布するまでのステップを説明します。多くの人が執筆に興味を持ちながら、何から始めれば良いのかわからなかったり、完成までの道のりが遠そうだと感じて二の足を踏んでいたりするかもしれません。

実際には、技術同人誌を製作するのはそこまで難しくはありません。各種ツールを活用することで、つまづきポイントを回避しながら書籍を製作することができます。

私自身、これまでいくつかの技術同人誌を頒布してきました。技術記事を書くことや技術イベントに登壇することとは違った魅力があるため、同じ技術発信でも技術同人誌を作ることをおすすめします。完成した紙の本を手にしたときのワクワク感は、何度でも味わいたいと思えるほどです。

技術同人誌は、書きたいと思ったときに書き始めるべきです。このトークを聞いて、ぜひあなただけの技術同人誌を製作しましょう。

webサービスを開発する上で、脆弱性への配慮は非常に重要です。
皆様も一般的な脆弱性については意識をされているかと思います。しかし、マイナーな脆弱性についてはどうでしょうか？
本セッションでは Laravelにおいて実装された5c問題の脆弱性を持つデモ用のweb applicationを攻撃し、脆弱性の説明を行います。

対象

• セキュリティ対策の基本について興味のある方
• 具体的な文字コードにおける脆弱性の仕組みに興味のある方
• ctfに興味のある方

内容

• sql injectionの説明、blind sql injectionの説明
• 5c問題はなぜ起こるのか
• laravelの実装と実際のデモ
• 安全に実装するための注意点

文字コードの知識を活かしたsql injectionの防止を通じて、セキュリティへの関心を高めましょう。

webサービスを開発する上で、脆弱性への配慮は非常に重要です。
皆様も一般的な脆弱性については意識をされているかと思います。しかし、マイナーな脆弱性についてはどうでしょうか？
本セッションでは laravelにおいて実装された5c問題の脆弱性を持つデモ用のweb applicationを攻撃し、脆弱性の説明を行います。

対象

• セキュリティ対策の基本について興味のある方
• 具体的な文字コードにおける脆弱性の仕組みに興味のある方
• ctfに興味のある方

内容

• sql injectionの説明、blind sql injectionの説明
• 5c問題はなぜ起こるのか
• laravelの実装と実際のデモ
• 安全に実装するための注意点

文字コードの知識を活かしたsql injectionの防止を通じて、セキュリティへの関心を高めましょう。