みなさんは、外国のチームと開発 "オフショア" を経験したことはあるでしょうか?
オフショア開発では予想できないハプニングや思いがけないアクシデントが多々生じます。
私は現在所属しているチームに参画して以降、PHPでの開発を共に進めているオフショア先のベトナムチームとの窓口を4年担当し、
情報共有不足による失敗や、遠隔メンバとの距離感や温度感の違いによる認識齟齬をはじめとする様々な出来事を経験しました。
また、PHPでの開発を行う場合は、PHPを扱っているからこそ起きる "設計者が意図していない実装" にも意思疎通に障壁がある中で対応する必要があります。
4年担当した今でも、基本的な確認事項などを抜かしてしまうだけで、予想外の事態が発生します。
本セッションでは、そんなオフショアにおけるハプニングやアクシデントを紹介し、それらを回避するノウハウなどを実例を交えてお伝えすることで、齟齬の発生しないコミュニケーションや、相手への意図の伝え方をお伝えできればと思います。
システムで使われるエラーメッセージについて、こんな書き方は良くないというテーマで話します。
プログラム言語には依存しないため、PHPとは直接的な関係は無いです。
~オフショア先のコード品質向上は難しい~
オフショアの場合、遠隔地であることだけでなく言語や文化、環境が違うため、お互いに意図を理解できているかや共通の認識を持てているかどうかが怪しくなってしまいます。
特に、コード品質向上のために行ったコードレビューのフィードバックについては、
・正しく内容を理解してもらえているか
・フィードバック内容を次回のコーディングに活かしてもらえるか
など、オフショア先との意思疎通が障壁となって、改善が行えない場合が多くあります。
そこで、私のチームではコードレビュー時に「再利用可能な」情報を提供することで、サービス全体のコード品質向上に取り組んでいます。
このセッションでは、
・どのようにしてオフショア先のコード品質向上に取り組めばいいのか
・オフショア先のモチベーションを保ちながらどのように改善を行っていくのか
などを、PHPのコードを紹介しながらお話しします。
私は普段、CakePHP2をCakePHP4にバージョンアップする仕事をしています。
その中で得られたCakePHP4を利用した開発におけるモダンなテクニックについてご紹介します。
皆さんはコードを読む時の工夫って、どんなものがありますか?
私は「脳内にスタックトレースを溜めておくの大変だぜ〜、すぐ混乱するぜ〜」となるので、その辺りは便利な道具で補いたいなあと思っています。
ここ暫くは、デジタルホワイトボードツールのMiroというサービスがお気に入りでして、ある時に「これは自分の思考を整理したらアイディアを繋ぎ止めておく時に使うツール・・・という事は!何かの複雑なコードを読む時にも、大活躍してくれるのでは!?」と閃きました。
実際に使ってみると、とても良かったのです。
本トークでは、実際にどんな風に使ったの?どう便利だったかな??を、体験談を盛り込みながらお話します。
複雑なコードや難しいソフトウェアも、これで少しは読みやすくなるかもです。
Circle CI, Travis CI, GitHub Actions, AppVeyor, ...
いろんなCIツールが存在していますが、皆さんはどれがお好きですか?
私の担当するSaaSプロダクトでは、もともとJenkinsでCIを動かしていました。
しかし、CIの活用を拡大していくにあたり、GitLabとの連携や設定の管理といった点で課題が出てきました。そこで、そうした課題をクリアすべくGitLab CIに乗り換えることを決断しました。
このLTでは、GitLab CIを選択した理由、移行を進める上でのポイントについてお話しします。
PHPerなら必ずと言っていいほどお世話になったことがある Composer ですが、自作したプログラムを Packagist に登録することは馴染みが薄い方も多いのではないでしょうか。
自作したプログラムを世界中のPHPerに配布する際、Packagist に登録するだけで Composer からインストールしてもらえるようになります。
ですが、せっかくインストールしてくれたユーザには、そのプログラムの内容をできるかぎり明確に伝えたいですよね。
本LTでは、自作したプログラムを Packagist に登録して世界中の PHPer に配布する際に気を付けたいことと、PackagistのWebの閲覧画面を確認する際に知っておくと良いポイントについてお話できればと思います。
■話すこと
・composer.json の書式に関する基礎知識
・Packagist への登録方法と閲覧画面で確認したいポイント
・親切な composer.json の書き方
■この発表をご覧いただくことで得られること
・composer.json の基礎知識
・Packagist への登録が想像より簡単だという実感
ユニットテストを生き甲斐としているPHPerが、ユニットテストの魅力を語ります。
プロダクト側のメリットではなく、いちエンジニアとしてのスキルセット向上に関して話そうと考えています。
「 え!?4分でモブプログラミング・ベストプラクティスを!? 」
マーク・パール著「モブプログラミング・ベストプラクティス 」を実践してみて学んだことをギュッと圧縮してお話しします。
みなさんモビングしてますか?
モビング(モブプログラミング、モブプロ)とは複数人でプログラミングを行うことを意味します。
なぜやるのか? どうやるのか? ペアプロとなにが違うのか?
明日から役立つモブプロのエッセンスをお伝えできたら幸いです。
派手なSQLインジェクションは一般的なWebフレームワークを使用すれば基本的に発生しません。
しかし、LIKE検索を行う場合はDoS攻撃が成立してしまうことがあります。
LIKE "%a%b%c%d%e%e%f%g%@%.%"
上記のようなクエリはSQLエンジンに大きな負荷をかけます。
LIKE句のメタ文字はエスケープする必要がありますが、
$query->where('hoge', 'LIKE', '%' . $value . '%');
と直に書いてしまうケースは多いと思います。
LaravelでのこのLIKE句のインジェクション対策はおそらく3通りほどあると思うので、
それぞれのソリューションをご紹介していこうと思います。
API定義のSwaggerUIやデザインカタログのStorybookなどの静的ファイルを社内展開する際にどのようにアクセス制御してますか?
AWSを利用している場合はCloudFrontとCognitoを組み合わせることで簡単に閲覧制限の仕組みを作ることができます。
弊社ではSchemaSpyで生成したER図をこの仕組で社内共有しています。
この仕組の作り方についてサクッと!紹介したいと思います!
Composerはとても便利で、生活必需品ですね!!
ただし、狭い意味での composer install
を考えると、 「composer.lockを読み取って」「ファイルをDL・解凍・規定のパスに配置する」というだけです。
もし、Composerの中身(実装)を読んで、仕組みを理解して、気持ちに寄り添う事ができれば・・・
必ずしも「PHPプログラム」ではなくても良いかも知れない。PHPの世界を飛び出して、Composerを実現する!!!
そんな夢を、私は見ました。
本LTでは、「composer installのためのツールを、Goで作ってワンバイナリで動かせるようにする」をテーマに
と言った点に触れてお話をします。
Githubが提供しているDependabotをみなさんは活用していますか?
Dependabotは大きく分けて3つのサービスを提供しています。
私が所属しているM&Aクラウドではもともとアラートとセキュリティアップデートのサービスを利用し、最低限の保守としてPHPやJavaScriptの依存ライブラリをメンテナンスしていました。
最近になりバージョンアップデートを利用して常に最新のライブラリに依存するように運用を始めたところです。
このLTではこのサービスの概要と弊社の運用を紹介し、ライブラリの依存関係を常に最新に保つための方法を紹介します。
ここ5年ほど、自分の部署の勉強会を企画・運営してきました。
5年間同じスタイルで続けるのではなく、いろいろ変革してきました。
最初はスピーカー集めで大変だった勉強会、、ですが、
直近で開いた勉強会はめちゃくちゃスピーカーも集まって大成功を飾れました!
5年間やってきたことで
などなどを話していければと思います!是非に!