トーク

「いいコードを書けるようになりたい？3回リファクタリングしてやっとかけるようになるよ」的なことを言われたことがあります。
いいコードを書くには多くの場合リファクタリングが不可欠ですが、そのコードが本番で動いていると、修正するには当然リスクが伴います。

今回は過去の自分が書いたコードをリファクタリングする際に、テストコードがどのように役立ったのか・どのようなテストがあると（あって）よかったのかを事例をもとに解説します。

ターゲット:

• テストコードをまだ書いていない方
• とりあえずテストコードを書いているが、テストの恩恵をそこまで感じていない方（私もそうでした）

あなたは、そのテストコードを信じ、リファクタリングの世界にダイブできますか？

カンファレンスに参加した！
参加するまではドキドキでも終わってみたら楽しかったな！と感じるのではないでしょうか？？

ただ、みなさんからいただいた熱量をもって明日以降に活かすぞ！と意気込むのですが、何からやっていけばいいのかな…と悩んでしまうこともあると思います。（カンファレンスなどに参加したてのわたしもそう思っていました…）

でも、ほんの少しのアクションをするだけでも明日以降のモチベーションや次回以降の参加につながる！と最近は思っています。（本当にささいなアクションでよいのです！）

本トークではわたしが実践しているささいなアクションを紹介しつつ、「今日は楽しかった！」と感じていただいた方が明日から先にも続いていくカンファレンス人生をより楽しんでいただくためのヒント（になって欲しいこと）をお伝えしたいと思っています！

みなさんご存知のように、2024年は毎月PHPイベントが開催されるほどPHPコミュニティが活況を呈しています。私はそれに合わせて、2019年以来久々に「日本PHPカンファレンススタンプラリー2024」を実施しています。今年は台紙とスタンプという物理媒体ではなく、ウェブサービスとして電子的なスタンプラリーを実装し、それに関する発表もPHPカンファレンス北海道2024で行いました。その際の実装はPoC的なものでしたが、福岡ではおそらく本サービス実装になっていると思われます。本LTではその本番実装についてと、それまでのスタンプラリーの利用具合について発表します。

この世の中には、何かを決定する機会がとても多いです。
例えばサービスのある仕様を決める時、例えば技術選定をする時、例えば設計で悩んでいる時・・・

そんな時、たった一つのシンプルなルールとして、「何かを決める時は、より質良く / より多く理由を言える方が良い」を提案したいと思います。
このLTではそのルールについての解説や、具体例について話していきます。

このLTで話すこと

• 様々な視点・視野・視座からものを考えた結果として、より質良く / より多く理由を言えるようになる
• どれだけより質良く / より多く理由を言えるかと意思決定のスピードを両立するには、あれこれ試して振り返る学習ループを地道に回すしかない

PHP書き初めて半年経っていない初心者が、爆速と噂（要出典）のphalconでWEBアプリケーションを作った所感について話します。
Larabelや他フレームワークとの比較をしつつ、果たして開発で使うべきなのか、初心者に優しいのかというような観点から、
個人の独断と偏見を元に、５分間という短い時間の中を爆速で紹介していきます。

プログラミングの学習をして、開発経験を重ねて……
しかしながら「一人や少人数で行う個人的な開発」と「実務として行うお客様のためのシステム開発」には大きな違いがあります。
前者にはなくて後者にはあるものとは何でしょうか？
私たちは誰のために、何のためにコードを書いているのでしょうか？

システム構築〜保守・運用まで全て自社内で一貫して行う会社に異業種からエンジニアとして転職し、初めてシステム開発案件に参画して痛感した「実務経験」の話をします。

きっと今の私にしか話せない内容です。この先も大切にしたい”今だからこそ得られる気づき”をお話できればと思います。

【話すこと（予定）】
初めての案件で痛感した、実務におけるコードの書き方・開発の考え方
コードはコミュニケーションだという話

【隠れ目的】
実務経験をさらに重ねているであろう未来の私がこのLTを思い出して大切な初心を思い出せること

皆さんはPHPerでしょうか？
なぜPHPerを続けているのでしょうか？

このトークではある日突然職種も業種も変えることになった私が「なぜPHPerになることを選択したのか？」と、「なぜ今もPHPerを続けているのか？」という観点からPHPとそれを取り巻くコミュニティの良さについてお話したいと思います

お話する内容

• 非PHPerだった私からみたPHPのイメージ
• 実際にPHPerになってからのPHPのイメージ
• PHPerコミュニティの良さ

想定聴講者

• 比較的最近PHPerになった人
• PHPコミュニティに入ってきて日が浅い人
• PHPとそのコミュニティに対する愛について話せる仲間が欲しい人

全プログラマー必見、累計発行部数20万部越えの名著「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」について、
ギュギュギュっと圧縮してサマリーをお伝えします！！
「リーダブルコード」をまだ読んでない方は、このトークでリーダブルコードのエッセンスを学ぶことができます。
もううろ覚えになっちゃっている方は、このトークで記憶の彼方から思い出すためのよいおさらいになるでしょう。

リーダブルなコードを書くエッセンスを持ち帰っていただけるLTになること保証します！

このトークは、オライリー・ジャパン出版の名著「SQLアンチパターン」で紹介されている25のアンチパターンを「超特急」で学ぶものです。
わずか5分のLTで、25個のアンチパターンをおさらいします。スピード感のある超特急LTをお楽しみください。

大事なところだけをギュッとして、明日からすぐ使える知識としてお届けできたら幸いです。

皆さんはタスク管理、何でしてますか！？
僕はNotionだったり、TickTickだったり、Apple純正リマインダーだったりと色々フラフラしましたが、Notionに落ち着きました。

ツールは決まったとして、じゃあどんなやり方をしていますか？
僕はGTD（Getting Things Done）とポモドーロを自己流に合体させたやり方をしています。

（僕はMacユーザーなので）そこにランチャーツールであるAlfredを使って、タスクの追加を楽にしています。

このやり方を始めてから、あたふたせずにタスクが回るようになりました。
自動でその日に行ったタスクをまとめるページも作っているので、1日の振り返りも楽々です。
ツール好きということもありますが、タスク管理自体が楽しいです笑

そんな僕のタスク管理を紹介します！

みなさんの作っているアプリケーションは様々なライブラリに依存していることと思います。
その依存しているライブラリに脆弱性の報告があった場合、適切にパッチを当てる取り組みが行われていますか？

このLTではDependabot Alertを用いて脆弱性アラートの検知と、パッチを当てるために私の所属している会社が行っている取り組みを紹介します。

受託開発PHPerがインフラエンジニアとして転職しました。
福岡在住の方も多いでしょうし、福岡から東京の会社でフルリモートする話や、転職についてどんなツールを使い、どんな思いで転職先を選定していったかなどを話せたらなと思います。

PHPにもっと詳しくなりたいなぁ〜と思っていた2022年の4月、ふと思い立って PHP のメーリングリスト（Internals）を読み始めました。途中、しんどすぎて中断したこともありましたが、段々と体が慣れてきて、最近は安定して週１でまとめを発表するまでになりました。

当然ですが、メーリングリストの中身は PHP の話題で満載です。知らない機能、使ったことのない関数、初見の仕様などが盛りだくさんです。

本 LT では、Internals を読むとどんな知識が得られるのか、そしてそれが実際にエンジニアリングにどのように役に立つのか、Internalsの魅力をお伝えします。

「エンジニアもオーナーシップを持とう」、「エンジニアにオーナーシップを持ってもらうには？」
プロダクト開発をするエンジニアがオーナーシップを持つに越したことはないというのは既に共通認識だと思います。
しかし、オーナーシップとは何で、どうしたら持てるものでしょうか。
福岡の奥地まで探しに行ってみたいと思います。

フロント側のテストって何を書いていいかわからない、UI部分のテストって書くのが難しそう、と思ったことはないでしょうか。

私はすごく難しいんじゃないかと思っていました。

そこでフロント開発の自動テストについて調べて、実際に作成した時、こんなライブラリやツールを使ってこんなテストをしたよ、っていうようなことを話したいと思います。

具体的には以下のような内容を話す予定です。

•Storybookを使った自動テストの作成
•Jestを用いたテストの作成
•Chromaticを用いたUIの変更点のテスト作成
•Codecovを用いてコードカバレッジを取る

ピクシブではドメインごとにクロスファンクショナルチームを事業部体制として構築し、会社としてのミッション達成を目指しています。
そういう環境で、2018年よりエンジニアギルドというエンジニア職の単一職能の横断体制を敷いて、事業部横断でエンジニア全体としての採用・評価・育成を同じ思想で強化していく活動を進め続けています。

わたしはその活動をとくに中心で、ときに一歩引いたところから推し続けてきたのですが、実現されるエンジニアリング強化とは事業を実現するケイパビリティの一つとして捉えており、またエンジニアひとりひとりの成長したい意欲を後押しすることも仲間同士で実現していきたいと常々考えていました。

5年ほど運用してきて再現性もあると考えたため、このカンファレンスの機会でこの知見をお伝えすることで、業界全体としてのエンジニア成長の加速の一助になればと思います。

昨今、Forteeはカンファレンスのプラットフォームとして多くの国内カンファレンスで使用されています。

また、最近では「カンファレンスに登壇やスポンサーをする」という趣旨のブログやプレスリリースが増えてきています。私も所属している企業でテックブログを執筆しています。

何回か登壇情報のテックブログを書くうちに、「Forteeから情報をコピペするのがめんどくさい」「集め終わった情報をjsonなどで保存したい」と思うようになりました。

そこでプログラムを書き、Forteeからtalk情報やog画像を取得できるようにしました。

本セッションではプログラムをどのよううに作成したかを紹介します。具体的には、プロポーザルページデータ(html)の取得、HTMLデータの加工方法についてお伝えします。

このセッションの対象者は登壇ブログを書く方や未来のFortee CLIの開発者です。

皆さんは､全く慣れない言語を｢今から使ってね｣と言われた経験はありませんか?私はいままさにそうです｡
コンパイラの言うことを聴いているだけで動くコードが書けるRustと違い､PHPは気をつけることがいっぱい......｡(個人の感想)
そんなPHPに不慣れな私が普段のRust開発と変わらずPHP開発ができるようになった自分なりに開発環境や気をつけていることをおはなしします｡

もしこれから全く違う言語を触ってね､と無茶振りされている人･これからされそうな人､安全にPHP開発がしたい人向けのLTにする予定です｡

新卒2年目(発表時)のPHPerがPHPのあるあるを時間の許す限り言い尽くします！

手前味噌ですが、私の所属する株式会社リンケージには、PHPのカンファレンスで毎度のごとく登壇するような実績のあるエンジニアが集まっています。

私は23年3月からPdMとしてエンジニアの方々と一緒に働いてますが、よく耳にする一般的なエンジニアとは思考と行動がまったく異なると日々感じています。
この1年間、そのノウハウを盗むべく、気づきがある度にメモを取り参考にしてきました。
今回は、そのメモをもとに、PdMという客観的な視点から実績のあるエンジニアはどのような思考をもってどのような行動をとっているのか、以下3つのベクトルに分けて説明していきます。

①対エンジニア職（開発チーム内）
②対ビジネス職
③対自己

【主な対象者】
・エンジニア/プロダクト開発に関わる方：働き方やチームビルドの参考に
・ビジネス職の方：エンジニアとの関係構築の参考に
・エンジニア採用担当者：エンジニア採用の参考に