ピープルマネジメントは「感情労働」と言われたりもしますが、その要因の1つは「色々な他人と真剣に個人対個人で向き合わなければいけないこと」だと思います。
共感し寄り添う必要がありつつ、「一緒に怒る」「一緒に焦る」という風にグラグラしていては身が持たない…という面もあります。
真面目に話を聞く!しかし適度に自身を安定させる!
その両立は、どのように可能となるのでしょうか?
リーダーシップ論を学んだり、コーチングのトレーニングを受けた事は、「自分の感情を保護する」のにも役立っていると感じます。
それらも踏まえ、自分自身がマネジメントに携わり2年ほどで、学んだ知識や実践の中で磨いてきたものを共有します。
皆さんはPHPStorm、Xdebugを使いこなしているでしょうか?
メソッドジャンプや、単純にテストを実行するだけで使ってないでしょうか?
このトークでは基本的なセットアップ方法から解説し開発チームが
PHPStorm + Xdebugを使って効率的にかつ、素早くデバッグを行えるTipsを紹介していきます。
・PHPコードの実行フローを追跡して、バグの原因を特定する。
・変数の値を監視し、変数の値や状態を確認する。
・ブレークポイントを設定して、特定のコード行で停止し、デバッグを進める。
・ステップ実行や式の評価を使用して、コードの動作を詳細に調査する。
・デバッグ時の便利なツールや機能を活用して、生産性を向上させる。
・Dockerを使ったリモートデバッグの設定と実行
など...
Webアプリケーションではさまざまな事情からSQLを発行したくなることがあります。
PHPでSQLを発行する際のベストプラクティスのひとつはPDOを使ってパラメータをバインドすることですが、残念ながらこの方法では可変個の要素に対して文字列組み立てを避けられません。
今回のトークでは私が社内ライブラリを再実装した「憂鬱なSQLのためのアレ、またはPDOと仲良くして枕を高くしてねむる」で紹介したライブラリを2022年にどのようなコンセプトで再設計したのかを紹介します。
「チームでふりかえりをしている」という組織は多いと思います。
どんなふりかえりをしていますか?あるいは、何の為に行っていますか?
実際には、「出来事や結果を共有する」「その再発防止や改善について話し合う」ものになっている事が多いかも知れません
良いふりかえりは、「上手いやり方を学ぶ場」を超えて「チームが学び方自体をアップグレードして行く場」に成り得るはずです!
チーム自体の進化を促したり実感できるふりかえり、できていますか?
そうでないのであれば、何ができていて・何が足りていないのでしょうか。
「学習する組織」のコンセプトをヒントにして、ふりかえりについて改めて考えていきます
アジャイルサムライの中では「概算見積もりは当てずっぽう」と書かれ、相対見積もりを推奨されています。
スクラムではストーリーポイントという名前を使って単位の意味合いを曖昧にすることで時間やお金に対する「約束」という概念から遠ざけています。
しかし、プロダクト開発をするうえではプロダクトロードマップがあり、それを達成することで事業成功を牽引する開発チームがあります。
プロダクトロードマップを作成するにも概算見積もりはあったほうが立てやすいですが、それが「約束」となって開発チームへの「呪い」ともなるケースもあります。
そんなPdMとエンジニアの狭間で、見積もりに対する考え方を言語化しチームに伝搬していこうとする話です。
みなさんライブラリを公開していますか? PHPのサポートバージョンをどうやって決めていますか?
原則論で考えればEOLを迎えてサポート終了したバージョンや、極論をいえば自分が使っているPHPのバージョン以外はサポート継続する義理はないわけですが、技術者としては可能な限り古いPHPでも使えるように互換性を保ち続けたいというのは人情ではあります。
このトークでは個人的な興味でメンテナンスを継続しているPHPライブラリでいかにして後半なPHPバージョンをサポートしているか、そして開発体験を落とさずに古いバージョンへのサポートを維持するために考えられるテクニックについて紹介いたします。
「プログラミング、上手くなりたいです!」
しばしば聞かれる質問です。
「まずはエラーを気にしましょう!」
最近はこう答えるようにしています。
プログラミング言語は、(数学や理学の世界と比べて)人工的であり恣意的な創造物です。
エラーが出ると怖い・面倒臭いと思われるかも知れませんが、
温室に氷を放置すれば溶けていくのに比べて、プログラミングのエラーは「誰かがわざとそうしている」に過ぎません。
プログラマにとって、なぜエラーが重要なのでしょう?
あるいは、PHPを作る人は、何をエラーとして何を許容してきたのでしょうか?
このトークでは、
事を試みます。
それによって、エラーと仲良くなって、「まともなコードを書ける」人が増えることを目指します。
アスペクト指向プログラミング(AOP)は、アプリケーションのコードベース全体に横断的に影響を与える部分(Cross-cutting concern)を効果的に管理するためのプログラミングパラダイムで、
オブジェクト指向プログラミングには無い新たな視点を提供します。
本トークでは、まずAOPの基本概念や利点について確認します。
その後、PHPで実装されたAOPライブラリを紹介し、どのように実装されているのかをライブラリによる違いや共通点に着目して深掘りします。
最後に、AOPを導入・活用するにあたってのポイントなどを紹介します。
本トークを通じて、AOPの基本概念を知り、PHPでどのように実現されているかを知ることができます。
「テストがないコードはレガシーコードだ!」
Webアプリ開発においてPHPUnitなどでテストが書かれることは一般的になりました。
ですが、テスト完走までにかかる時間は適切でしょうか?
テストにかかる時間は生産性に直接的な影響を及ぼす重要な要素です。早ければ早いほど良い。
本トークでは、PHPUnitで書かれているテストを高速化するテクニックについてお話します。
セキュアなアプリケーションを実装することはとても大事なことですよね。
しかし、開発者だけで様々なセキュリティ対策を施すのは限界があります。
そこで本セッションでは、GitHubが提供する機能を活用することで「セキュリティ対策の仕組み」を構成する方法について解説します。
また、GitHub Actions+クラウドサービスで実装可能なDevSecOpsについても解説を行う予定です。
ソフトウェアをソフト(変更容易)に作るって、めっちゃ難しくないですか?
私はずっと難しいと感じていて、設計のスキルを伸ばすのに苦闘しています。
そんな私にとって、2022年12月に発売された『ちょうぜつソフトウェア設計入門』(ちょうぜつ本)は非常に学びが大きい一冊でした。
躓いていた概念が(かわいい挿絵の力もあって)スルスルわかり、設計に関する知の高速道路と感じています。
このトークでは、設計スキルで壁を感じている方向けに、ちょうぜつ本や『Clean Architecture』を参照して、理解が深まったポイントを(使い慣れた)Python🐍のコード例を交えて共有していきます(PHPのコードは書籍をどうぞ!)。
トピック
・Clean Architectureとは
・オブジェクト指向 「鍵は抽象!」
・SOLID原則
・私見:一発でソフトに設計できるほど強くないと割り切る戦略
話者は前回のPHPカンファレンスにて「RFC911*から振り返るHTTPの仕様」という話をさせて頂きました。
その中で特に新しい仕様である「RFC 9114 - HTTP/3」を読んでインターネットの未来を感じました。
今回はHTTP/3に焦点を絞ってRFC 9114からの仕様を理解した後に検証を行い、これまでのHTTPとの違いを体験します。
PHPerとは切っても切り離せないHTTPの次世代プロトコルを体験することでその価値に触れ、
HTTP/3採用のモチベーションになれば幸いです。
Webアプリケーション開発でデータストアとして良く使われているRDBMS 「MySQL」。
大きなシェアを誇るMySQLですが、ご存知の通り2023年10月に5.7系はEOLを迎えます。
安全のためにもMySQL 8へのバージョンアップが必要となりますが、メジャーバージョンアップとなると押さえておくべきことがたくさんあります。
本セッションでは、MySQLを8へバージョンアップするに当たって押さえておくべきこと、省力化する方法についてお話致します。
PHPerの皆さまは今日もPHPを何処かの環境で動かしている事だと思います。
様々なクラウドベンダーの上にはPHPを動かす選択肢がいくつもあるのですが、
実際にどの環境で動かすのが良いのか迷ってしまいます。
今回はクラウドベンダーをAWSに絞り、
現在稼働させることのできるPHP実行環境の比較を行います。
より良いPHP環境を選択して、コスト効率よくPHPを運用しましょう。
フレームワークは偉大です。
共有済みの知見を共有しながらスピーディーに開発を行えます。
今回その中身について深く知りたくなりフレームワークの気持ちを知るために
ある目的に合わせたフレームワークを作成することにしました。
その目的とはPHPをサーバーレスに動かすためのフレームワークです。
BrefというOSSと組み合わせながら、AWS Lambda上で快適に開発を進める事を目標に
フレームワークの作り方を学びながら、機能を再履修します。
OSSのコードリディングと手を動かすことにより、フレームワークの世界へDeepDiveしましょう
グローバルプロダクトを作ろうとすると、避けては通れないのが多言語化対応です。
データベースに保持される情報の多言語化はどうするのかが悩ましいところです。
そして、考えた先に思いつた EAV(エンティティ・アトリビュート・バリュー)という方法。
しかし、EAVは様々な理由によりSQLアンチパターンに含まれています。
その理由と照らし合わせて、実際どうなのかを考えた話
■ あらすじ
今明かされるサイボウズGaroon開発チームの学生向けインターンシップの裏側。
以前開催されたのは2018年。
5年の沈黙を破り、開催されるインターンシップ。
ノウハウ乏しく、格闘するチームメンバー。
何を準備すればいいのか。
何をすれば学生は喜んでくれるのか。
最後に我々はこのインターンで何を得ることができたのか。
このトークは、そんなインターンシップの裏側で奮闘した者たちの、半年間の記録である───
■ 話すこと
■ こんな方向け
MySQLなどに代表されるRDBMSには、トランザクションをはじめとする排他制御が実装されています。 複数人から同時に使われうるWebアプリケーションにおいて、信頼できるデータストアとして十分な機能が備わっています。
一方で、RDBMS外のデータストアには、それと比較して柔軟な排他制御の機構を有しているとは限りません。 例えばオブジェクトストレージのAmazon S3などでは、占有ロックをとって書き込みを制限することはできません。
MySQLに備わる排他制御には、レコードやテーブル単位ではなく、任意の文字列でロックをとることのできる、ユーザレベルのロック操作(GET_LOCK関数)があります。 本セッションでは、この GET_LOCK関数を用いた排他制御と、それをオブジェクトストレージのデータ移行に適用した実例を紹介します。
開発者数が多く、MVPアプリにも高トラフィックなアプリにも採用できるPHP。
インターネットではPHPのゆるい使い方ばかりが槍玉に上がっていますが、最近のPHPは言語仕様としての型サポートも強固になってきています。
もう一歩進んで、より安全に仕様変更やリファクタリングを行うためにどういう工夫が出来るでしょうか?
本セッションでは、プロダクト開発時に堅牢性を高めるための仕組みと文化についてお話致します。
私が担当するLaravelアプリケーションは、DBマイグレーションの問題、テストフレームワークの不在、CI/CD環境の欠如といった荒野のような状況でした
以下の改善策を実施し、アプリケーションは徐々に成長し、品質と開発効率が向上しました
荒野のような状況から始まるLaravelアプリケーションの成長ストーリーを通じて、「PHPUnitの導入と開発環境最適化」がアプリケーションの品質と開発効率をどのように向上させたのかをお伝えします
参加者には、類似の課題に対する解決策と効果についての具体的な知識を提供し、自身のプロジェクトに応用できる洞察を得ることができれば幸いです