コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。
いわゆる、1対1のコミュニケーションがどれだけ発生するか?というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか?という経路としてのパスもあります。
個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか?というのもチームコミュニケーションにとって大切な要素ではないでしょうか。
本トークでは、1対1のコミュニケーションにおける対話(パス交換)に着目して、私が大切にしていることを共有したいと考えています。
アプリケーションのパフォーマンス改善を行う場合、適当に手を動かしてもうまくいかないことが多いと思います。
少しでもよいカイゼンを行うためには「事実」を把握するために「計測」するというアクションが大事です。
ツールを使ってコードのメトリクスの取得するのも1例です。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「事実」を把握することができます。
把握できた色々な「事実」を元に、どこがアプリケーションの改善点なのか…?何がアプリケーションにとって最適なのか…??プロダクトにもっとも寄与するためには…???を考え「判断」し、「行動」に繋げていきたい。
このトークではどのように考えてカイゼンのための行動をとっているのか?をお伝えしたいと思っています。
モブプログラミングを始める際は、業務コードを書き始めるのではなく実験的なコードから入るのが良いとされています。
そのためには実験用のリポジトリが必要です。
しかし、下記のような問題でリポジトリ作成ができず、モブプログラミングを始められないケースが考えられます。
このセッションでは、GitHubリポジトリにあるCollaborators機能を用いて、手軽にモブプログラミングを始めるためのリポジトリを準備する方法を紹介します。
このセッションでは、並行処理のパラダイムシフト、アクターモデルの探求とその魅力に焦点を当てます。
基本的な概念から実践的な利用まで、アクターモデルがPHPの開発者にどのような新たな視点と可能性を提供するかを掘り下げます。
アクターモデルの基本的な概念やダイナミックな特性などを解説、
並行処理の挑戦にどのように対応するのかを理解し、
なぜマイクロサービスアーキテクチャやES+CQRSで協力なサポートを得られるのか、
などなど皆さんの開発へのヒントになるような内容をお届けします。(もちろん失敗談なども)
PHPだけで実現するのは難しいものですが、並行処理の新たなパラダイムであるアクターモデルを理解し、
適材適所に組み込むための手引きとなることを目指します。
アクターモデルが新たな視点と刺激を提供し、PHPによる開発が新たなレベルに達する一助となることでしょう!
PHPはインタプリタ言語であり、Zend EngineによってPHPコードが「OPcode」という中間表現にコンパイルされます。
またOPcodeは、OPcacheを有効にすることで共有メモリ上にキャッシュされるものです。
※OPcacheとは、予めコンパイル済みのバイトコード(OPcode)を共有メモリに用意し、パフォーマンスを向上させる仕組みです。
ではPHPコードから変換されたOPcodeを読んだことはありますか?
本トークでは下記の内容について話すことによって、PHPコードから変換されたOPcodeと慣れ親しみます。
このLTを聞き、PHPコードが内部でどのようなOPcodeに変換されるかを目の当たりにすることで、PHP処理系内部や低レベルへの興味が掻き立てられることでしょう。
「マイクロサービスは銀の弾丸なのでは・・!?」以前の私はそう考えていましたが、現実は甘くありませんでした。
今回のトークでは、PHPやRailsでゴリゴリにモノリシックな開発に飽きつつあった私が、ゴリゴリにマイクロサービスな開発をする環境に移ってどのような学びを得たかをお話しします。
・経験の前後でマイクロサービスに対して感じたギャップ
・今更感じる、マイクロサービスの長所と短所
・運用の難しさ(複雑性やトラブルシューティング) ※特にフォーカスしたい箇所
これらのテーマに添いつつ、今の会社に移ってから肌で感じた「マイクロサービスアーキテクチャによるプロダクト開発のリアル」を共有し、お互いの学びの場になればと考えています。
※本トークでは、特定のプログラミング言語やライブラリ、フレームワークを深掘りする話はしませんが、私のさじ加減で組織・チームの話は入るかもしれません。
2人月くらいの工数がかかる機能開発を1人で担当することがあります。
納期のプレッシャーに追われながら必死にコードを書いた結果、気づけば1回で80ファイル分の変更がある地獄のような巨大プルリクが出来上がっていました。
レビューをすり抜けたバグが障害を発生させてしまい、どげんかせんといかん!となった時に改善を行ったことで、リリースを細かくできたり、障害の発生が抑えられたりと良いことづくめで開発品質を上げることができるようになりました。
このLTでは、PRを分割した方法や分割することの大事さについてお話します。
PRを小さくしてみんなで幸せな開発ライフを送りましょう。
プロダクト開発激化時代において、より魅力的で競合優位性のあるプロダクト開発をしていくために開発組織の育成は必要不可欠です。
開発組織の開発力、生産性を上げるために避けては通れない、エンジニア一人ひとりの技術力アップをどのように推進していけばよいのでしょうか。
私がEMとして、ここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について、理論を具体例をおり混ぜながら話します。
(なお、本セッションはPHPカンファレンス福岡と沖縄で話した理論と実践の話の再編になります)
最初に組織において育成がなぜ重要なのかについて話します。
「個への育成」と「組織への育成」へフォーカスを移し、それぞれへの育成理論や1on1などで使える具体例を紹介します。
最後に弊社で組織での教育の仕組みづくりをどのようにして行い、どのように変わったのかを話します。
「(git add / git commit / git push)」
「プルリクエスト出したので確認お願いします!」
これはいつもの日常だ。
俺も入社したての頃よりはGitコマンドにも慣れて開発出来るようになってきたな。
そういえばこの前、git rebaseやgit cherry-pickとかいう便利そうなコマンドのことを先輩から聞いた。
でもなんだか難しそうだし、今は困っていないからいつか調べてみよう。
私も以前はこのPHPerと同じでしたが、ブランチやコミットを整理してレビューしやすいプルリクエストを作ることで、チーム開発がスムーズに進むようになりました。
このLTでは、時間が許す限り、発展的なGitコマンド・オプションの使い所をお伝えします。
どうですか?社内イベント、開催してますか?
エンジニアとして生まれたからには様々な社内イベント開催のチャンスがあるかと思います。
LT会や勉強会、輪読会や懇親会……
でもどうやって開催したらいいんでしょう?何を、いつまでに、どのように進めたら?当日はどうする?
本セッションでは、私が社内イベントの運営や司会進行を数年務めてきた中で、
得たノウハウや個人的に大事にしている価値観についてお伝えできればと思います。
皆で楽しく円滑な社内イベントを作り上げていきましょう!
ぜひ聞いてほしい方
※トーク内容の大半は社内/社外を問わないものとなりますが、
社外イベント特有の観点について扱わないため今回は「社内イベント」に限定します
フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。
この意味、正しく理解していますか?
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ?」みたいな認識をしていませんか?
実は PHP の機能としては namespace(名前空間)とディレクトリ名、ファイル名には一切の関係はありません!
「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの?」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。
※本トークは「第 146 回 PHP 勉強会@東京」にて発表した LT の改訂版です。
Google Apps Script(以下、GAS)とはGoogleが提供するローコードプラットフォームです。
単なるJavaScript実行環境にとどまらずGoogleの提供する各種サービス(スプレッドシートやフォーム等)との連携を容易に行えたり、動的なWebページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。
何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説検証のサイクルを回す必要がありますが、GASの備える特性はその際の強力な助けとなります。
本トークでは、その際に知っておくと役に立つ
についてお話します。
コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
テレワークは働きかたに様々な利点をもたらしてくれた一方で、新たな問題をもたらした側面もあります。
私たちのエンジニア組織は従業員どうしの関係性や勉強会等の活発さといった文化を強みのひとつとしていました。
そして、テレワーク導入直後にはその強みがほとんど見えなくなっていたのです。
もともと組織文化醸成の役割を担っていた「開発組織活性チーム」は、この問題に対して活動内容をテレワークに適応させるための試行錯誤に舵を切ります。
本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。
「システム移行の際に、リリース後に不具合が発生した」という苦い経験をお持ちの方は多いのではないでしょうか?
特に、影響範囲が大きい機能に手を入れると、不具合の規模も大きくなってしまい、後始末に追われることになります。
影響範囲を狭めて段階的にリリースするための手法として「レガシーミミックパターン」というものがあります。
弊社においても直近の開発で採用し、かなりの安心感を得られたので、知見を共有したいと思います。
常に機能追加が続く運用中の大規模オンラインゲームプロジェクトで、PHPを5.5から8.1にバージョンアップしました。
言語バージョンアップに伴い、PHPUnitも4.5から10に更新しました。
今回のバージョンアップについて、以下のポイントで話したいと思っています。
みなさんはWebAssembly(WASM) はご存知でしょうか?
ブラウザで利用するケースはもちろんのこと、WASI( The WebAssembly System Interface) の普及で様々な利用シーンが考えられるようになりました。
そのようなWASMですが、我々PHPerにとって縁の遠い話だと感じられるのではないでしょうか?実はそのようなことはありません。
ブラウザでリアルタイムにPHPが動作するhttps://php-play.devサービスを作りました。
つまり、WASM化することによって、サーバー以外でもPHPを動作させることが可能になりました。
今回のトークでは、以下の2点をテーマにお話します。
本当の初心者向けのセッションです。
このセッションはPHPを始めたいと思っている方、はじめてすぐつまづいてしまった方にゼロからわかりやすくPHPについてお伝えします。
・PHPとはどんな言語か
・PHPをはじめる環境
・PHPの書き方
・簡単なプログラムを作ろう
2023年はAIがとても話題の一年になりました。
わからないことはAIに聞いて楽に進めましょう。
プログラミングを行う上でのAIの使い方などにも触れてゆきます。
Macユーザーの皆様。Docker環境はどうされておりますか?
Rancher Desktopですか?Docker for Macですか?
そこでOrbStackをおすすめしたいです。MacのDocker環境の遅さに悩まれている方に最適です。
このLTではOrbStack( https://orbstack.dev/ ) のメリットデメリット、最新の情報の追い方を説明していきます
誰かの書いたコードが世に出る過程で、コードレビューを行う組織は多いのではないでしょうか。
コードの質を担保するため。属人化を防ぐため。知識共有や認識合わせのため。チーム内のスキルアップのため。
コードレビューは様々な意味や目的を持って行われます。
本セッションでは、コードレビュワーがコードレビューイに求められていることとそれに応える方法を下記の例と共に考察していきます。
・PHPコード上でのレビュワーとレビューイのコミュニケーション例
・レビューが活性化するPHPコード例
また、実際に弊社で働く様々なポジションのPHPerエンジニアにインタビューを行い、彼らが求めるレビュー内容をもとに共通項を見つけたり、
レビュワーとしてコメントをするときの工夫点や注意点を紹介します。
レビュー時、依頼時に少しでもお役に立てると幸いです。
対象者: コードレビューを行う全エンジニア(役職問わず)
PHPは読み書きがしやすくユーザーによるコンパイルが不要な素晴らしい言語です。その魅力的な構文と特性を支える素晴らしい立役者がいることをご存知でしょうか?本トークでは私たちが愛してやまないPHPの裏側を紹介します。
対象者
話すこと
話さないこと