エンジニアをマネジメントする際に気をつけていることや困ったことなどのあるあるをお話します。会場のエンジニアに響くよう努めます！

PHPerの皆さん、CSSを書いていますか？
CSSに対して苦手意識を持って敬遠してる方も多いようですが、実は皆さんが思っている以上にCSSで表現できる幅は広いです。
ドット絵やアニメーションといったデザイン的なところから、sin/cosといった計算、HTTP GETなどの通信も行うことができます。

当LTではCSSでPHP(elePHPant)を描く方法を複数紹介してCSSのポテンシャルの高さ体感してもらいます。

北九州生まれ北九州育ちのPHPerが、コロナ禍を乗り越えて、今年ついに福岡にUターンしました！

東京と福岡でのワークスタイルの違いや、取り巻く環境の違い、メリットやデメリットをお話しします。

福岡を愛する誰かのロールモデルとなるよう、自身の経験を含めてお話しします！

今から約2年前、未経験で飛び込んだIT業界ですが、今ではそこそこの仕事を任せてもらえるまでに至りました。また、就活も終え内定先も決まったので、今までのインターンでの経験を振り返り、その苦労と成長をお話したいと思います。

未経験だった自分が2年間のインターンで何をして、どう成長できたのかを中心にお話します。
(初登壇でめちゃくちゃ緊急してます笑)

AWS AppSync は、データソースに対して GraphQL API を簡単に実装できる仕組みで、開発者はリゾルバーと呼ばれるコネクタ処理を記述します。
AppSync は Amplify でも利用されています。
ただ、これまでは VTL（Apache Velocity Template Language) で記述する必要があり、少し導入に迷うポイントでもありました。
しかし現時点では JavaScript を使ってリゾルバを記述できるようになっています。これを APPSYNC_JS と呼んでいます。
APPSYNC_JS になって、VTLよりも良いことだらけなのでは？と思って使い始めてみたが....

このLTでは APPSYNC_JS を使って開発して得られた良いところ、苦労することのナレッジを稲妻トークで共有していきます。

コロナ禍入社した新卒3年目のエンジニアがリモートワーク環境で働いて感じたあるあるネタを社内からも情報収集して語ります。
「失敗」「成功」「解決しない問題」などを盛り込みます。

みなさん、PHP上のEnum値はデータベースにどのような値で保存してますか？

数値型？ DB上のEnum型？ それとも文字列？

「いやいやw 文字列で保存したらデータ量が無駄やんw」
「変な値入れられたらアプリがバグるやんw」
「速度的にどうなん？w」

という声もあるかもしれません・・・

それでもなお僕は言いたい
「Enum値は文字列で保存してクレメンス！」

みなさんチームで学習していますか？

環境の変化が激しく不確実性が高いこの時代に適応していくためには学習は必須！
しかし自分一人だけ勉強してもモチベーションも続かないし、勉強したことをチームメンバーに教えるのも大変。

そこでチームみんなで勉強してみませんか？明日から始めることができる方法を紹介します！

みなさん！こんにちは！

日常的にPHPを使用した開発をするなかで、「自分って実はすごいことをやり遂げているのに、誰もすごさに気づいてくれない！」と思ったことはないでしょうか？
もしくはチームで開発した成果物に対して、本来は誇るべき成果であり、チームとして自信を持ちたいのに、「今回はここがダメだったから、反省すべき！」とネガティブな方向に話が進んでしまったことはないでしょうか？

このLTでは、私が開発現場で使っているマウンティングテクニック、いわゆるMX駆動開発とは何かを紹介します。
以下がMX駆動開発で成し遂げられることです。
・開発者として、自分の作った成果物に自信を持てるようになる！
・チームメンバーとマウンティングし合うことで、共通認識を持てる！→結果的に納得度の高い成果物を開発できる！

みなさんはこのLTを聞くことで、早速マウンティングをしてみたくなることでしょう。

過去10年間PHPに触れ続けた人間がPythonを扱うようになった後、改めて感じたPHPの良さを語ります。
双方のコーディング体験の違いを経験し、Web開発のしやすさという観点においてPHPの方が良かったと感じる点があります。

PythonはシンプルでAWSとの親和性も高い言語ではありますが、コードの書き方やフォルダ構成の作り方に若干の癖があります。
これが、Web開発において、バックエンドとフロントエンドを分ける構造にすると、2つ以上の言語を行き来することになるので、より一般的なスタイルのPHPの方がわかりやすさを感じます。
本トークでは、双方のコードの実例を交えながら、発表者が感じたPHPの方が良かった点、双方共通の問題などを喋ります。

私がおよそ10年ほどエンジニアとしてお仕事をしてきたなかで、いろんなインシデント対応をしてきました。
その中であった「これは辛いよ〜〜」や「こうだったら辛いだろうな……」といった事項をできる限り詰め込んでお話したいと思います。

お話すること

WEBサービスを運用するにあたって発生したインシデント対応系の辛いこと

お話しないこと

ハードウェア的な問題のインシデントについてはお話しません

ターゲット

インシデント対応でどんなことが辛いんだろう？を知って、そうならないようにしたいと考えてくださる方

みなさまデザインパターンは好きですか？
一部プログラマ界隈では「デザパタは麻疹(はしか)」と揶揄されて忌み嫌われて(？)いますね。

なぜデザパタは嫌われるのか、デザパタに罹って治ったあとに何を学べるのか、デザパタのあるある言いたい、など。プログラマの"はしか"ことデザインパターンについてさらっと話します。

４０代半ばで技術コミュニティに初めて出会い、10年前からJAWS-UGおおいたの運営をやってきました。
地方で感じる「技術的に取り残されるのでは」というモヤモヤ感がきっかけでしたが、結局は、日本中の「個性豊かな人々」との出会いが楽しくて続けてきました。
そんな中、コロナの影響で前職のスタートアップのビジネスが頓挫し、早期退職することになりました。
普通５０代半ばで職を失うと、悲壮感が漂うはずなのですが、「不安はあるが何とかなるだろう」と楽観的に落ち着くことができました。
これは、コミュニティを通じて、「外の物差し」で自分自身の強みと弱みを知り、強みをいかせば何とかなるだろうと思えたからです。結局はコミュニティの友達がFacebookで投稿した求人情報をもとに、現在のお仕事に就くことができました。
コミュニティ活動は老若男女全てのエンジニアにとって将来役に立つことを伝えたいと思っています。

私はこれで何を伝えたいかというと、今でもレベルは高くないですが振り返るといろんなことを学んで年を経るごとに視野が広がって段々と学び方が増えてったこと、もう満足だろうと思ったら新しい世界が見えてきて考えてもみなかったことが増えていったこと、これからも楽しい経験が待っているだろうと言うのを伝えていきたいと思っています。
この業界に入ろうと思った最初の頃はIPアドレスですらなんのことか分かりませんでした。初めて入った現場でフレームワークも業務への入り方も分からず悔しい思いをしました。その時に思ったこと、何をしてどんな壁を乗り越えたのか、なんの勉強をしたのか、勉強や業務で面倒だったことはなにか、勉強する内容の変化、仕事の内容の変化、仕事で関わる仲間との交流での自分の変化を中心にお話ししたいと思います。

少し前にパスワードにまつわる「ハッシュ」と「ソルト」という言葉が話題になりました。
また「平文で保存していたパスワードが流出する」といった事件もたびたび耳にします。

パスワードの扱いについては、Web アプリケーションフレームワークを使っていればあまり意識することは無いかもしれません。
実際、意識しなくてもフレームワークがよしなにしてくれます。

でも、いったい「ハッシュ」や「ソルト」とは何なのか？
上述のような事件を起こさないよう、アプリケーション開発者としてしっかり押さえておくべきポイントをお話します。

カンファレンスは役に立って、刺激を貰えて、楽しくて…最高ですよね！？

そんなカンファレンスですが、職場の同僚を誘えると、共通の話題ができたり、技術力の底上げになったりと、もっともっと価値あるものにできます。

私は実際に、PHPカンファレンス関西で職場の同僚を5人カンファレンスに連れてくることに成功しました。
その経験を元に、同僚をカンファレンスに連れてくるためのあの手この手を伝授します！

想定する聴衆
・会社からソロでカンファレンスに参戦している猛者（昔の自分）
・同僚にもっとカンファレンスに興味を持って欲しい方
・裾野を広げてカンファレンス全体を盛り上げたい方

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

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

ターゲット:

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

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

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

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

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

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

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

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

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

このLTで話すこと

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