我々の業界では、オープンソースソフトウェア(ハードウェア)によって支えられています。
PHPもオープンソースです。いきなりですが、そんなPHPに何かで貢献してみませんか?
本トークではオープンソースによって得られる恩恵と、貢献の仕方・手法をご説明します。
php-srcに貢献しているぼくが個人的に嬉しい貢献をバーっと並べていきます。
たとえば
初心者でもやっていけることをやることでオープンソースに貢献をすることで知見が得られ、
エキスパートへの道を一歩踏み出すきっかけになれば幸いです。
おおきに
静的解析ツールは使っていますでしょうか?
昨今のPHPのバージョンアップでは型定義が厳しくなってきており、静的解析ツールを導入することの優位性が高まってきています。
15年以上続いているレガシーシステムにPHPStanを導入した際の課題と効果について紹介します。
・既存の静的解析ツールからPHPStanへの移行
・PHPStanの導入時の課題
・導入から半年での効果と課題
既存の静的管理ツールに課題を感じている方や、静的解析ツールを導入したいと考えている方にとって参考になる内容となっています。
世の中には数多くのシステムサービスがありますが、少額であっても利益化まで持っていけるサービスは本当に限られるかと思います。
そこで今回は自分がリリースしているサービスで、少しですが利益化できたサービスの技術構成やLaravelだからこそできるサーバー代節約術、どうやってユーザーを獲得したのか、どのような告知を打ったのか、その費用対効果はどうだったのかなど、「技術的な側面」と「ビジネス的な側面」両方から経験に基づいたお話をしたいと思います!
目の前に立ちはだかる削除フラグ......
削除フラグがアンチパターンであることは知っていても、目の前の削除フラグと付き合っていくしか無い...
そう思って諦めていませんか?
削除フラグを既存のアプリケーションに影響をできるだけ閉じて無くすことはできます。
テーブルから状態や属性を別のテーブルに移し、アプリケーションを壊すことなくリファクタリングしていくために必要なことを説明します。
レガシィコードと向き合い、リファクタリングして、目の前のプロダクトを改善している現場のテクニック、余すこと無くお話します!
何度も遭遇する PHP の「Allowed memory size ...」。しかし、結局解決方法がわからず、最後には memory_limit を -1 にしてその場を凌ぐという苦い経験をした方も多いのではないでしょうか。
PHP ではガベージコレクションもそれなりに発達しており、メモリを気にしないで書けるから良いと思っている人も少なからずいらっしゃると思います。
static はメモリ効率がいい… PHP 8.1 から導入された readonly などの機能を制限する書き方をすればメモリ効率がいいなど考えている方もいらっしゃるかもしれません。
そこで本トークでは、PHP では本当にメモリについて気にしなくていいのか。そして,どのようにすれば省エネにメモリを使えるのか。PHP のメモリ確保の仕組みや最適化の仕組み,そしてメモリ効率の良い書き方のヒントまで含めてお話できればと思います。
なんとなく口にしがちな「"品質"が高いコード」。
定義があいまいで要領を得ないため、すり合わせはおろか万人が万人の「願望する"品質"」の話に終始してきました。
一方で「品質」は工業規格としての定義があります。
このトークでは工業規格の定める「品質」に基づいて、「"品質"が高いコード」の定め方と達成の仕方についてお話します。
このトークで得られる知見
このトークで話さない事
誰かの書いたコードが世に出る過程で、コードレビューを行う組織は多いのではないでしょうか。
コードの質を担保するため。属人化を防ぐため。知識共有や認識合わせのため。チーム内のスキルアップのため。
コードレビューは様々な意味や目的を持って行われます。
先日発表したPHP Conference2023「CodeReviewerが求められること」の続編です。
https://fortee.jp/phpcon-2023/proposal/25891e6c-7762-47b5-8cb3-e3db7f056abc
前回のおさらいや、PHPコード上でのコミュニケーション例の紹介、
そしてどんなコーディングやPullRequestの出し方がCodeReviewerに求められるものとなっているのかに迫ります。
少しでもお役に立てると幸いです。
対象者: コードレビューに携わる全エンジニア(役職問わず)
開発と運用が分かれていた時代、「コードを書く人」から見て「本番システムの監視」は遠い存在だったと聞きます
──「アプリ側」の自分から見て、「それって本当に勿体ないぜ」と強く感じるのです!
頑張って作ったWebアプリケーション、ユーザーに気持ちよく使ってもらいたいですよね
そのために、少しだけ視野を広げてみませんか?
開発者としてサービスに関わる人に、少しでも「良いものを届ける」ために「監視もやるぞ!!」という想いを持ち帰ってもらう
古くからあるサービスには、機能強化とともにサブシステムが増えていきました。
最初は良いけれど、
・検証サーバーは共用だったり、個人毎だったりバラバラに存在
・共用サーバーには、交代して使用する為に待ち時間が発生
・複数の人が使うので、テストデータがぐちゃぐちゃに
・サブシステムが増える度にサーバーも増えてくる
・当然、ソース修正や管理、デプロイもややこしくなる
というような問題が、だんだん見えてきました。
では、この問題の改善にチャレンジしよう!とは言いつつ、
「今まで使い慣れたエディタやリポジトリ構成、開発の流れは変えたくないよ」という声もあります。
さて、どの様に改善していったでしょうか。
・Dockerで共用サーバーを廃止して、メンバー毎の環境を整理しましょう
・コンテナ環境でも今まで通りPhpStormで開発作業ができるようにしましょう
・ユニットテストもうまく連携しましょう
PHPのソースコードを正確に検査したり、ソースコードの一部を書き換えたいと思ったことはありませんか?
PHPにはPHP-Parserという構文解析ライブラリがあり、静的解析ツールのPHPStanやリファクタリングツールのRectorはPHP-Parserをベースにしたプラグインでソースコードを検査したり、ソースコードを書き換えたりすることができます。
しかしながら、構文木を操作するには普段何気なくPHPコードを書く以上のプログラミング言語についての知識が求められます。この発表では構文木を取り扱う前提となるプログラミング言語についての知識、PHP-Parserの構造、PHPStanとRectorそれぞれの拡張方法と実例についても紹介します。
情報発信の種を育てるには、どうすればよいのでしょうか。そもそも、情報発信は何のためにするのでしょうか。
遡ること2019年、それまでGaroon開発チームは外部に向けた情報発信をほとんどおこなっていませんでした。
長年の開発による負債に悩まされ、自分たちの仕事を魅力的だと感じられなかったことが大きな要因のひとつでした。
しかし、とある会を皮切りに、開発者にとって魅力的なプロダクトを目指して活動することができ、徐々に状況は変わっていきました。
私は、長年Garoon開発チームに所属しつつ、技術広報を兼務してきました。
Garoon開発チームの変化と共に歩んだからこそ見えてきた、情報発信を続ける理由と技術広報としての関わり方、目指すものをお話しします。
情報発信について考えている方々に届き、情報発信と開発組織について考えるきっかけにしたいと考えています。
どのプログラミング言語の初心者にもお伝えしたい知見「テストを書こう」のPHP版です。
これは私が考える「良いコードを書くための心得」です。
初心者時代の私は目指してはいても変更しやすい実装ができませんでした。
実はこれは達人ケント・ベックも同じようで、それを知って以降、少しずつ実装を改善する道を選びました。
テストコードがあると、変更前後で振る舞いが変わっていないかを何度でもすぐに確認できます
こんな方に向けて話します
こんなことを話します
Target class [...] does not exist.
このようなエラーを見たことはないでしょうか?そして、よくわからないけど、ファイル名を直したらうまく動くようになった!という経験はないでしょうか?
実はこの裏ではautoloadという仕組みが働いています。
autoloadがどういう仕組みで動いているのかを知ることで、ファイルが読み込まれない時やクラスが見つからない時の原因が早くみつけられるかもしれません。
このトークではPHP初心者向けにautoloadの仕組みを少し掘り下げてお話しします。
トークの内容
・autoloadは何を解決するか
・autoloadのルール
・autoloadを実現する仕組み
皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか?
私はあります(※)。
PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。
私が担当しているメール共有サービスのメールディーラーでバージョンアップ後に、一部の受信メールが文字化けをしました。
受信したメールのエンコード時にmb_detect_encodingを使っていたからです。
下位互換性がないため文字化けを回避することができず、結果的にメールヘッダに文字コードの指定がないRFCに準拠していないメールまで対応しました。
メールディーラーの保守運用・顧客対応チームのリーダである私が顧客対応で泣きをみたことを中心にお話いたします。
私と同様に顧客対応されているエンジニアの方々の参考になれば幸いです。
※実際には飛び込んでいません
弊社では文化として受け継がれている「条件分岐禁止」というのがあります。
条件分岐禁止バンドをつくっちゃうほどに
条件分岐があることでコードが複雑化してしまったり見にくくなってしてしてしまいます。
そのアンチパターンやどうしたら良いコードになるのかを話します。
対象者: PHPのコードを綺麗に書きたい人
このトークでは架空サイトのログインをInterfaceを利用して差し替えることでInterfaceへの理解を深めます。
「Interfaceってなんだか抽象的で分かりにくい」
「解説しているブログ記事や映像を見てもいまいちピンと来ていない」
「ライブラリのInterfaceの使い方見てもいまいち嬉しさが分からない」
そんな方は是非このプロポーザルに☆をつけてください!
Interface、コワクナイ!
「PHPコミュニティ、その魅力と熱狂をあなたにも」と題した私のトークへようこそ!
2022年から数々のPHPカンファレンスや勉強会に飛び込んで、今や参加したイベント数は両手ではとうに数えきれないほど、私はPHPコミュニティへの熱い愛に満ちています!!!
PHPにとどまらず、技術コミュニティへの情熱は、一人のPHPerとして、また一人のエンジニアとして、成長の核となっています。
「技術コミュニティとは何か?」、「なぜ私はPHPコミュニティをここまで愛するのか?」という問いに対し、私の体験と感動を通じてその答えをお届けします。
ただ参加するだけではもったいない!このトークを通じて、「PHPコミュニティ人生をどうすれば200%楽しめるか」という秘訣を余すことなく解説します!
6年ぶりのPHPカンファレンス関西2024だからこそ聞いてほしいトークです!是非、この機会をお見逃しなく!!
Mutation Testing とは、プロダクションコードに対するテストコードがどれだけ十分なものか、というテストの品質自体を評価するテスト手法です。
Mutation Testing を導入することで何がよいかというと、見かけ上のコードカバレッジが高く、作成したソースコード全般的にテストコードが網羅できていたとしても、テストコードが正しく書けているとは限らないのですが、その部分を簡単に検出できるということです。
今回は「Mutation Testingとは?」という詳しいお話から始め、実際にInfection PHPを利用してMutation Testing をライブデモしながらお話をすることで、より品質の高いテストコードの作成に寄与できればと考えています。