現在私はプレイングマネージャーという形で、複数の案件を掛け持ち自身も開発をしながらメンバーを管理し、加えて会社の組織設計や雑務も行っています。
様々な仕事を行う中で、特にシステム開発という仕事は楽しくやりがいがあり、集中した時にはあっという間に1日が終わってしまいます。
そして後から気づくのです。「開発以外の仕事全然できてない」と。。
この問題を打破すべくタイムトラッキングを導入し、自分が何の仕事にどれだけ時間を使っているか可視化することで本来やるべきことに時間を使えるように改善を進めていきました。
このLTでは実際に発生した問題から始まり、タイムトラッキングツールの導入、実際に可視化して気づいた点や自身の作業の改善内容、導入してみて良かった点/反省点をまるっとお話します!
アジャイルソフトウェア開発宣言の中に「包括的なドキュメントよりも動くソフトウェアを」と記載がある通り、アジャイル開発において「動くソフトウェア」というものは非常に重要視されていると思います。
そのため、普段の開発業務で「動くソフトウエア」を素早く提供することを求められる場面は、きっと多いのではないでしょうか?(むしろ、常にそういう期待値を持たれているかもしれません。)
本トークでは、そんな「動くソフトウエア」を素早く提供するために実際にスクラムチームで取り組んだことについて、実体験をベースにした知見をご紹介します。
このトークでお話すること
・「動くソフトウエア」とは何か
・どうやって価値提供のスピードを上げたのか
・内部品質を保つためにどんなことをしたのか
・まだ改善していく余地はあるのか
Web アプリケーションフレームワークを使ったプロジェクトを新規作成し、自動生成されるファイル郡の中にある config というファイルまたはディレクトリ。
いったいこいつは何なのか?
どうやら項目を自分でも追加できるようだが、一体何を追加してよくて、何を追加すべきでないのか。
本トークはそんな疑問にお答えします。
不具合が確認され、丸一日かけて調査したら原因はうっかりミスによる構文エラーだった.......そんな経験ありませんか?
「そんなうっかりミスを実行する前に気づけたらいいな」そう思ったあなたにお勧めするのが静的解析です!
本トークでは PHP 静的解析ツールの一例として PHPStan を取り上げて、それが使えるとどんなことがいいのかをお話します。
PHPのソースコードでよく empty($hoge)
を見ることは有りませんか?
ドキュメント( https://www.php.net/manual/ja/function.empty.php )にて仕様は書かれていますが、腹落ちしていますか?
このLTでは、emptyの挙動を理解できるように、php-srcを読んでどのようなことをemptyは行っているかを説明します。
追記
注意: これは、関数ではなく 言語構造のため、可変関数 や 名前付き引数 を用いてコールすることはできません
https://www.php.net/manual/ja/function.empty.php
とのことで、関数と表記をしてしまいました。お詫びして訂正いたします。
ScalaにはOptionクラスがあるのをご存知でしょうか?
これは何らかの処理結果(オブジェクト)を返すメソッドにおいて、通常時は子クラスのSomeに結果を返し、処理できなかった場合は子クラスのNoneを返してくれるものです。
この仕組みがあれば、nullableのドメインプロパティを利用する際に制御が容易になったり、値がないかもしれないことを明示的に表現できるのでコードの可読性と保守性が向上します。
ただOptionクラスはPHPにないのです...ではどうするのか?
自分たちで用意するしかないですね!
このトークではPHPでOptionクラスを用意するところをご紹介します。
資料に余裕があれば、
弊社のプロダクトはこれまでnullableのドメインプロパティをどう扱っていたのか経緯を踏まえつつ、なぜOptionクラスに行き着いたのかも合わせてご紹介できればと考えています。
こんにちは!
PHPerTeaNight運営メンバーの久保田です。
PHPerTeaNightはPHPer(PHPを愛するプログラマ?)のためのIRT形式による勉強会です。
2022年7月から開始し、ほぼ毎月開催する勉強会です。
ぜひ、PHPerコミュニティとして輪を広げたいと思い番宣ならぬ、会宣をさせていただきたいと思います!
以下のような内容をトークしたいと思います。
このトークを聞いた人がPHPerTeaNightに参加してくださったり、他のPHPコミュニティの勉強会なども参加してくださると嬉しいです。
みなさんは普段開発している際、バグに遭遇することがあると思います。そしてそのバグの発生要因が PHPDoc のメンテナンス不足であると考えると怖くないでしょうか。
私は実際に Laravel を使用して開発している際前述したような経験をしました。そして PHPDoc の修正を行い、Laravel のコントリビューターとなりました。
私はこの一連の出来事からコードリーディングがとても大事であることに気付かされました。
この発表では PHPDoc の不足をどのように見つけたのか、どう修正したのか、そしてコードリーディングが世界の誰かに役に立つかもしれないということを話します。
大きなソフトウェアを一人で作ることは難しく、エンジニアには常にコミュニケーションスキルが求められます。
ましてや外国のチームと開発 "オフショア" においては必須スキルと言ってもいいでしょう。
オフショア開発では意思疎通の問題から予想できないハプニングや思いがけないアクシデントが多々生じます。
私は、現在所属しているチームにてベトナムチームとの窓口を4年担当し、
情報共有不足や、遠隔メンバとの温度感の違いによる認識齟齬をはじめとする様々な出来事を経験しました。
その中には、後から考えれば「ここでちゃんと伝えておけばよかった」と後悔するものもたくさんあります。
本セッションでは、そんなオフショアにおけるハプニングやアクシデントを紹介し、それらを回避するノウハウなどを実例を交えてお伝えすることで、
齟齬の発生しないコミュニケーションや、相手への意図の伝え方をお伝えできればと思います。
現在私が BABYJOB 株式会社で開発を担当している保活サービス「えんさがそっ♪」では、バックエンドは PHP で Laravel、フロントエンドに Laravel の Blade テンプレート + jQuery で構築しています。
最近ではフロントエンド開発への課題感から React の導入を積極的に行っています。
React 導入の経緯としては...
①肥大化した jQuery の管理に限界を感じていた
②流行りの SPA に挑戦したかった
今回は Laravel 製のサーバサイドレンダリングアプリケーションに React を部分導入してみて、感じたメリットとデメリットをお話ししたいと思います。
Laravelのアップデートを、Laravel Shiftを使いながら行ってきました。
実際にどのようなことを行ってきたかをお話しできればと思います。
アップデートをいずれ行う予定の方や、Laravel Shiftの導入を検討している方に
経験したことをシェアすることで、何かしらの参考になればと思います。
Java 6 のバックパックを背負ったまま、PHP 8 の山を登ろうとしたらどうなるでしょうか?このライトニングトークでは、私のそんなエピソードをご紹介します。
①スタート地点: Java の世界から出発し、PHP 8 の新たな土地を目指した時のお話。
②サバイバルギア: 新しい世界を生き抜くために、私が手に入れたリソース、ツール、そして秘密の武器についてお見せします。
③オンザロード: 途中で出くわした難問や驚きの発見、そしてそれらをどうクリアしたかのエピソードをシェアします。
まだトレッキング途中ではありますが、私の経験が、新しい技術にチャレンジしようとしているあなたの背中を押す一助となれば幸いです。
生成AIはときに新しい発見や、気づきを与えてくれます。
昨今話題のChatGPTを始めとした生成AIですが、みなさん使い方に迷ってませんか?
まずは身近なところから始めましょう、そうです、自分の登壇をまず分析しましょう。
ということで去年ペチコン(2022)の私の登壇「フィーチャートグルを使って素早く価値を検証する 早く安全に失敗し学ぶために」を題材にして
生成AIに分析させてみようと思います。
分析例
もし何かの間違いで採択されてしまったら
https://www.youtube.com/watch?v=F71zTEPwy5c
これのPHPerバージョンを頑張って作ってLT会場を温めます!出順はトップバッターでお願いします!
どうも、要件ヒアリングに自信ニキです。
私はフリーランスエンジニアとして受託開発のお仕事をよく頂くのですが、お客さんとの対話・ヒアリングを割と得意としています。
お客さんはシステム開発のプロではないので、説明が的を射ないことも多く、複雑なシステム要件のヒアリングには根気と体力を要しますよね。
そればかりか、なかなか合意や結論に辿り着けずいたずらに時間が奪われた挙句、結局失注して悲しみ、といった経験はないでしょうか。
私はよくお客さんから「1しか言ってないのに100のアウトプット出てくるんやが」「話が早すぎてもはや笑える」などと言われます。
一体私はお客さんとの対話中に何を考え、どんな手順でヒアリングを進めているのでしょうか。
このLTでは、お客さんとの対話中の私の頭の中身をまるっと皆さんにシェアします。
明日からのお客さんとの対話・ヒアリングに少しでも役立てていただけると嬉しいです!
Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか?
実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。
このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう!
Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか?
Docker経由でしかPHPを使わないみたいな猛者スタイルで行ければいいのかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvやsymfony-cliと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
この辺はいざ導入しようとするとYak Shavingの嵐が待っていて(実体験)非常に面倒だったりします。
というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います!
コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。
いわゆる、1対1のコミュニケーションがどれだけ発生するか?というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか?という経路としてのパスもあります。
個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか?というのもチームコミュニケーションにとって大切な要素ではないでしょうか。
本トークでは、1対1のコミュニケーションにおける対話(パス交換)に着目して、私が大切にしていることを共有したいと考えています。
アプリケーションのパフォーマンス改善を行う場合、適当に手を動かしてもうまくいかないことが多いと思います。
少しでもよいカイゼンを行うためには「事実」を把握するために「計測」するというアクションが大事です。
ツールを使ってコードのメトリクスの取得するのも1例です。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「事実」を把握することができます。
把握できた色々な「事実」を元に、どこがアプリケーションの改善点なのか…?何がアプリケーションにとって最適なのか…??プロダクトにもっとも寄与するためには…???を考え「判断」し、「行動」に繋げていきたい。
このトークではどのように考えてカイゼンのための行動をとっているのか?をお伝えしたいと思っています。
モブプログラミングを始める際は、業務コードを書き始めるのではなく実験的なコードから入るのが良いとされています。
そのためには実験用のリポジトリが必要です。
しかし、下記のような問題でリポジトリ作成ができず、モブプログラミングを始められないケースが考えられます。
このセッションでは、GitHubリポジトリにあるCollaborators機能を用いて、手軽にモブプログラミングを始めるためのリポジトリを準備する方法を紹介します。