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

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

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

みなさん！こんにちは！

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

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

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

サービスを運用していると利用しているミドルウェアのアップグレードや巨大なデータベースのテーブルへのインデックスの追加などメンテナンスを入れて行わないといけないオペレーションが出てきます。
本発表では私が行ったデータベース(Amazon RDS)のメジャーアップグレードを例に、運用サービスのメンテナンスをどのように計画、実施したのかを紹介します。
またメンテナンスでの反省から学ぶ、準備と対応の重要性、メンテナンスの計画/実施したことない方にもイメージしやすいようメンテナンス時に考慮すべき点についても紹介できればと思います。

話すこと

• 行ったRDSのメジャーアップグレードについてのついての紹介
• メンテナンスまでに行った準備
• メンテナンスの反省点
• これからメンテナンスを行う人に向けて気をつけるべき点の紹介

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

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

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

お話すること

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

お話しないこと

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

ターゲット

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

みなさまPHP "以外の" 言語を書いていますか？
書籍「達人プログラマ」では1年に1言語あたらしいプログラミング言語を学ぶことを奨めています。
目の前の課題が同じでも言語が変われば別のアプローチになるのはよくあることです。さまざまなアプローチを学ぶためにもさまざまな言語を学ぶのは良いことです。

ところが、そうやって学んだ「他の言語でよくやるやり方」をそのままPHPに持ってきても上手くいかないものです。
言語を超えて適用できるベストプラクティスとはどのようなものか、PHPで推奨されるPHPらしい書き方とはどんなものなのか、このトークで一緒に考えてみませんか？

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

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

エンジニアにとってドキュメンテーション・技術ブログ・業務でのチャットコミュニケーションなど文章を "書く" 技術は重要ですよね。
とはいえエンジニアは文章の専門家ではありません。そのため文章を書くのに苦手意識を感じつつ悪戦苦闘している人も多いのではないでしょうか。

テキストアウトプットはメリットが多い、にもかかわらず文章術の学び方やノウハウはあまり出回っていません。
今回はブログがバズってるわけでもなく文章で食ってるわけでもない私が、苦手意識を克服して普通に書けるようになるまでに学んだことを振り返ってみます。

普通のエンジニアが普通の文章を書く技術を知って、テキストアウトプットのメリットを享受しませんか。

想定聴講者

• テキストアウトプットのメリットを知りたい人
• ブログ・ドキュメントなど何かを書こうと思っても手が止まってしまう人
• 最近ブログ書いてないなーという人

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

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

このトークでは、OSSから学ぶ方法について話します。

学習のためにOSSに触れるとよいと聞きますが、言うは易し行うは難し、学ぶことにもハードルがあると感じたことはありませんか？

私は丸腰ではコードが読めません。環境を整え、道具を駆使して、少しばかり工夫しながら読み進めてゆきます。このトークでは、PHPStanの並列処理を題材に、一定複雑な処理がどのように実装されているのかを紐解いてゆく過程を見てゆきます。

チュートリアルの次のステップとして、既に稼働実績のある実用的なコードから学ぶことで実践力を高めようという試みです。

このトークではOSSから学ぶことのハードルを下げることを目指します。スキルアップへの引き出しが一つ増えれば幸いです。

実行中の PHP スクリプト内の各要素は、それぞれがメモリ上に何らかの領域を占有しています。ローカル変数のための領域、配列の各要素やハッシュテーブルを収めるための領域、文字列のための領域、オブジェクトやそのプロパティを収めるための領域。実行中に様々な領域が確保され、そして不要になると解放されたり、意外とスクリプト終了まで解放されなかったりします。

PHP には標準の組み込み関数として memory_get_usage() や memory_get_peak_usage() といった関数があり、呼び出し時点でのメモリ使用量や実行開始からのピーク値を得ることができます。しかし、これらを呼んでも「どこで」「何が」「何バイト」メモリを使っているかまでは追えません。

このトークではスクリプト内の各要素について、処理系内で何がどうメモリを消費するかを時間の許す限り1つ１つ手当り次第に解説します。

プログラムの本質的構造を示すAST（抽象構文木）に変化がなければテストを省略できる場合があることに着目し、ASTのハッシュ値を比較することでPHP 8.1からPHP 8.2にバージョンアップする作業の一部をスムーズに進められることが分かりました。ASTを取得および比較する方法や、事前に行った対象箇所の特定およびファイル更新方法などに関する具体的な手順や使用したソフトウェアを紹介しつつ、ASTがPHPのバージョンアップ時にも役立つことを解説したいと思います。

テストコードを書いていますか？
テストを書いた方が良いと誰しもが思いテストを整備していると思いますが、中にはテストコードを書く時間が作れない、意味を理解してくれない、テストコード実装の優先度が下がる、様々な理由でテストコード実装が出来ていない現場もあるかと思います。
今までテストコードを書かなかった開発現場が、テストコードを整備し開発・運用面・リリースの状況が変わった話や、効果を数値化した話、社内でテストコード導入を広めていくために沢山の手段の中からテストコード研修を実施するに至った話をします。

• テストコードが無かったアプリケーションの実態と現場状況
• 多くの時間を割いていたQAテストをテストコードでカバーできるか網羅率や整備コストを出し、効果を数値化した話
• テストコード整備後のリリース数や開発工数変化
• テストコード必須とした導入フローを検討の末、研修実施へ至った話

みなさんは動画編集をやったことはありますか？
動画編集とは元来めんどくさく手間がかかるものではあるのですが，普段からWebアプリの開発をしている私は，以下のようなことを考えていました．
HTML/CSSのように複数オブジェクトを一つのコンテナのように扱えたら，CSSのように統括して装飾を指定できたら，HTMLレンダラーが相対値から計算して値を指定するように，動画のオブジェクトの時間長も編集アプリが計算して指定してくれたら，もっと楽に動画編集できるのになぁ，と．
そこで私は，HTML/CSSをベースとした，動画の構成を記述する言語を記述することで動画編集を行えるという技術を開発しました．

↓以下の記事でも紹介しておりますが，ここからの進捗についても発表したいと考えております．
https://qiita.com/PigeonsHouse/items/7e3a3c4ed8473a61f4ac

プログラマーとして生きていると、仕事をする中であるいは日々の生活の中で、ちょっとした自動化のためにスクリプトを書くことがあるでしょう。
そういったスクリプトはすぐに使い捨てるつもりだったり、あとで修正することもなかったりするかもしれません。

このとき、みなさんは「最低限の品質」をどこに置きますか？
いざ、ぱっと聞かれると返答に困るような質問かもしれません。

私のなかではある程度の基準があります。
本トークでは「ちょっとした自動化のためにパッと書いたスクリプト」をいくつかのレベルに分けて、どこまで作り込むかの観点と判断基準の一例をお見せします。

PHPerKaigi 2024で一千を風靡したPHPer向けゲーム、「PHP8.3秒チャレンジ」の企画や開発の裏話をします！

PHP 8.3秒チャレンジとは、PHPの最新版である8.3をみんなで目指そうというコンセプトのストップウォッチゲームです
8.3秒ぴったりに止めるという至ってシンプルなゲームですが、通常のストップウォッチと異なり、途中から数字が消えてしまうので目押しはできません

このゲームをPR TIMES企業ブースで展開したところ、現地でXでも大変盛り上がりました！
本セッションでは以下の観点から裏話をお話しする予定です！

• 企画: ゲーム形式・コンセプトの誕生秘話
• 開発: API・インフラの工数削減話・Leaf PHPによるPHP APIの実装をした話など

このトークは、イベントで何かブラウザを使った出し物をしたい方の参考になることを目標としています✨

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

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

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

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

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

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

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

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

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

ターゲット:

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

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