トーク

開発をしているときにコメントがあると助かりますよね。
「なるほど、ここはそういう処理をしてるのか！」と、コードの中身を詳しく読まなくとも実装を進めることができます。
しかし、時としてコメントは嘘をつき、あなたを陥れます。
特に古いシステムではこれまでに蓄積され、忘れられ、熟成されたコメントが至るところに散りばめられています。

私が普段開発をしているメール共有サービス メールディーラーはリリースから20年以上が経つサービスであり、熟成されたコメントが多数存在します。
本LTでは私が実際に遭遇したレガシーコードに潜む奇妙なコメントをご紹介し、コメントを信じることが如何に危険なことであるかを知っていただきます。

コメントを信じるか信じないかはあなた次第です！

速いは正義、アプリケーションは速くあるべきです。

ではどうすれば良いのか

細かい理論などは気にしない、こうしたら早くなった

結果を貼り付けながら、何をしたのかひたすら話しますが、細かいことは話しません

OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して、情報を詰め込むだけ詰め込むことに挑戦します。

※注釈は付けますので細かな理論はそちらでご確認ください

• 想定する聴講者

  • PHPWebアプリケーションのパフォーマンスに興味がある方
  • PHPのインフラを整備するエンジニア
  • PHPでISUCONに挑戦する方

• お話しないこと

  • パフォーマンス以外の話
  • アプリケーションコードによる改善
  • 劇的なパフォーマンス改善策

みなさん、PHPを初めて学んだ時に感じた「？」を覚えていますか？

私の所属する開発チームでは、PHPマニュアルの精読を始めました。
精読してみて改めて感じたPHP独自の魅力について、皆さんに共有したいと思います。
このセッションでは、PHPの特殊な機能、他のプログラミング言語との比較、その機能ができた背景について、私なりに調べた結果や考察を発表します。

対象者:

• 他のプログラミング言語からPHPに転向を考えているエンジニア
• PHPの良さを知りたいエンジニア

PHP8.1では、いくつかのリソースがobjectに移行しました。
例えば
pgsql result リソース → PgSql\Result オブジェクト
pgsql link リソース → PgSql\Connection オブジェクト
などです。

私が開発しているMaildealerは、すでに開発から20年以上経過しているレガシープロダクトです。
その中に存在する PgSQL 用の独自ライブラリは、すべてがリソースで扱うことが前提のコードになっていました。

マイナーリリースで気軽に入れられた変更が、レガシープロダクトに与えた影響と、その解決方法をお話します！

先日、製造業で働いている友人からIT業界に転職したいという話をいただいたのですが、その際にある疑問が湧きました。
それは、完全な初心者が2か月間訓練したら、どれくらいPHPが書けるようになるのだろうか……？というものです。
お互いに平日はお仕事があるので、夜中や休日にひっそりとお勉強するしかありません。

IT未経験の若者が苦労の末 2か月間でPHPを習得する 話、 聞いてみたくない ？

具体的な内容

• PHPやバックエンドについて教えた2か月間の記録
• 教わる側の新人目線でどういうところがキツイと感じたかについてのぶっちゃけ裏話
• 実際に教えた技術と実践で作ったもらった成果物の紹介
  対象者
• 未経験エンジニアの可能性に興味がある方
• 新人教育でPHPを教える際に難しさを感じている方

私が最初に出会ったプログラミング言語は大学の授業で勉強したC言語でした。授業や試験で問題を解くためにC言語を勉強していました。

ですが、授業外でHTMLやCSS, JavaScriptでWEBサイトを制作し、そこでPHPに出会いプログラミングが好きになりました。ここで初めて「プログラミング = 授業で勉強するもの」の考え方がなくなりました。プログラミングでWEBアプリケーションを作成し、エラーに苦しんで、実際に動かす体験は嬉しさと楽しさでワクワクしていました。
最初はノンフレームワークのペライチのコードを書き、次はフレームワークで開発、一周回ってノンフレームワークで開発しました。

本セッションでは、PHPで「作ることが楽しい」体験から「コードが書ける、読める楽しさ」に変化していった経験についてお話しします。

メールを送る処理の実装時うっかり誰かに送ってしまうことはないでしょうか？
開発時のメールの誤送信事故を防止するために、ダミーのメールサーバに送るようにするということが多いかと思います。
Mailcatcher や Mailhog、Mailpit などの便利なツールが公開されていますが何か使われていますか？

弊プロダクトでは、ツールは利用せずにログにメールの送信内容を出力しています。

このアプローチでの Laravel を利用した開発時のメリットとデメリット、ログの可読性を上げるための工夫など私たちが行っていることを紹介します。

普段どういう風にlaravel開発を行なっていますか？
デバッグする時にddやlogなど使用していますか？
今回紹介するXdebugではより洗練され、便利で、直感的なデバッグが可能になります。
私自身、同僚にXdebugを教えてもらってからその利便性に驚かされました。
簡単なデモ動画でXdebgの初期設定、基本動作、共有できればと思っています。
皆さんの開発作業の効率が格段に向上するはずです。ぜひこの機会にXdebugの魅力を実感していただければ幸いです。