トーク

去年の5月から「Laravel.shibuya」というIRT(Interactive Round Table)メインにした勉強会を開催するようになりました。
IRTをメインとした勉強会の事例があまり無く、不安もありましたが、第1回では応募開始からすぐに満員となり好調なスタートを切る事ができました。
しかし、いざ開催してみるとIRTならではの課題が見つかります。

・IRTをメインにしてるにも関わらず上手くディスカッションが回らない
・経験の差でどうしても上級者の方が喋ってしまい、初心者の方は一方的に聞き手に回ってしまう
・隣のテーブルが盛り上がると話題が全然聞き取れない。
・IRTのトークテーマが事前に集まらない。

これらの課題について運営メンバーで取り組んだ改善方法についてご紹介します!

弊社のあるチームでは、CI で実行される PHPUnit のカバレッジ取得が 6 時間もかかっていました。
試行錯誤の結果、これを 18 分まで高速化することができました。

PHPUnit は、カバレッジ取得を有効にすると、有効にしていないときと比較して大幅に遅くなりがちです。
遅くなる理由の一つは、xdebug によるカバレッジ情報の取得が遅いことです。
また、別の理由として、グローバルな状態に依存したコードをテストするため、
PHPUnit の process isolation オプションを有効にして毎回プロセス起動を行ってしまうことがあります。

これを解決するために、以下の改善策を行いました。

・xdebug の代わりに pcov を使用する
・並列実行する
・process isolation オプションを無効にし、backup globals や backup static attributes を有効にする

このときの調査や改善活動で得た知見についてお話いたします。

あまり使われないPHPのマジックメソッドですが、使い方次第ではとても便利に使うことができます。
書籍にもあまり載っていないPHPの数少ない黒魔術の使い方をお話しします。

FaaSと言えばAWS Lambda?
いいえ、他にも様々なFaaSはあります。

今回はAzure Functionsを利用してみます。
みんなでFaaSの使い方を覚えましょう！

■お話する内容

• Azure Functionsの使い方
• Tips

■お話しない内容

• 細かな仕様

Serverless は僕達をサーバー管理から開放してくれます。

未来の投資として非常に有益だと考えているのですが、構築するには様々な知識が必要になります。

今回はMicrosoft Azureを利用した Full Serverless Applicationを開発する為のTipsをご紹介しようと思います。

このトークによりみなさんがサーバー管理から解放される一歩を踏み出せればと考えています。

■お話する内容

• アーキテクチャ説明
• 開発手法
• テスト

■お話しない内容

• 認証
• CI/CD

■関連技術

• Azure Functions
• Azure Storage
• Azure Cosmos DB

Serverless は僕達をサーバー管理から開放してくれます。

未来の投資として非常に有益だと考えているのですが、構築するには様々な知識が必要になります。

今回はMicrosoft Azureを利用した Full Serverless Applicationを構築する為の方法をご紹介しようと思います。

このトークによりみなさんがサーバー管理から解放される一歩を踏み出せればと考えています。

■お話する内容

• アーキテクチャ説明
• 開発手法
• 認証
• テスト
• CI/CD

■関連技術

• Azure Functions
• Azure Storage
• Azure Cosmos DB
• Azure Active Directory
• Azure Resource Manager

皆さんの職場では継続的なライブラリのアップデートができているでしょうか？
弊社では1年以上前からcomposer updateを自動化し、毎週PRが自動で作成される環境を作ることで、マージするだけで簡単にバージョンアップできるような仕組みを取り入れました。しかし、仕組みは作るだけで終わりではなく日々の運用や改善がないとうまく回りません。

本トークでは、毎週composer updateをする試みを実際に1年以上継続した中でうまくいったこと、逆にうまくいかなかったこと、そしてどうやって改善していったかをお話します。

関連リンク

• PHPフレームワークのバージョンアップを支える技術 - コネヒト開発者ブログ
  • https://tech.connehito.com/entry/2019/05/14/121215
• Composerのupdateを自動化した話 / phpstudy-128-composer-update-request - Speaker Deck
  • https://speakerdeck.com/o0h/phpstudy-128-composer-update-request

プロダクト開発に置いて、様々なデータを集め、取得し、分析、活用していくのが当たり前になってきました。
しかし専属の分析担当/チームがある会社もまだ多くはないかもしれません。

そういった場合に取得と分析を誰がどうやっていくのかがいいのでしょうか。

例えば下記のようなケースもあるかと思います。

• エンジニアが分析担当を兼任し、ビジネスサイドは関与しない
• ビジネスサイドから欲しいデータの抽出をエンジニアに依頼、ビジネスサイドが分析していく

私達はスピードと柔軟性のためにビジネスサイドもエンジニアも一緒にやっていくことを選びました。
それを実現するにはビジネスサイドもSQLを活用できないといけません。

ビジネスサイドとエンジニアが協力をして実際にどういうことを行ったか、
ビジネスメンバーはどういうことからはじめて、どれくらいのことができるようになったのか、エンジニアとどういう分担をしているのか、
そしてそれらを行っていく中でうまくいった点や改善点についてPHPerのエンジニアが話します。

※ 具体例としてDBはBigQuery,データはFirebaseで収集したアプリのイベントを使います。

想定する聴講者

• 経験や職種関係なくSQLを活用して、データ抽出を行いたい、ダッシュボードを作りたい方
• SQLの活用を他のメンバーにも広めたいエンジニア

話さないこと

• PHP
• 分析の詳細
• SQLの詳細の文法

プロダクト開発に置いて、様々なデータを集め、取得し、分析、活用していくのが当たり前になってきました。
しかし専属の分析担当/チームがある会社もまだ多くはないかもしれません。

そういった場合に取得と分析を誰がどうやっていくのかがいいのでしょうか。

例えば下記のようなケースもあるかと思います。

• エンジニアが分析担当を兼任し、ビジネスサイドは関与しない
• ビジネスサイドから欲しいデータの抽出をエンジニアに依頼、ビジネスサイドが分析していく

私達はスピードと柔軟性のためにビジネスサイドもエンジニアも一緒にやっていくことを選びました。
それを実現するにはビジネスサイドもSQLを活用できないといけません。

ビジネスサイドとエンジニアが協力をして実際にどういうことを行ったか、
ビジネスメンバーはどういうことからはじめて、どれくらいのことができるようになったのか、エンジニアとどういう分担をしているのか、
そしてそれらを行っていく中でうまくいった点や改善点についてPHPerのエンジニアが話します。

※ 具体例としてDBはBigQuery,データはFirebaseで収集したアプリのイベントを使います。

想定する聴講者

• 経験や職種関係なくSQLを活用して、データ抽出を行いたい、ダッシュボードを作りたい方
• SQLの活用を他のメンバーにも広めたいエンジニア

話さないこと

• PHP
• 分析の詳細
• SQLの詳細の文法

2019年11月、GitHub Universe 2019で「GitHub Actions」がついに正式版になったことが発表されました。
これまではベータ版として公開されており、v1, v2と大きな仕様変更を経て正式版公開となったわけですが、興味はあるもののしっかりとキャッチアップできている人はまだまだ多くないのではないでしょうか？

本トークではGithub Actionsを1から解説し、実際にこれまでCircleCIやTravisCIで行っていたPHPアプリケーションのCI/CDを、Github Actionsを利用して実現できないかを検証します。
Dockerコンテナを活用しつつ、PHPUnitによるテストや、phpcs・phpstanといったQAツールを実行する具体例として参考となるものにできればと思います。

2019年11月、GitHub Universe 2019で「GitHub Actions」がついに正式版になったことが発表されました。
これまではベータ版として公開されており、v1, v2と大きな仕様変更を経て正式版公開となったわけですが、興味はあるもののしっかりとキャッチアップできている人はまだまだ多くないのではないでしょうか？

本トークではGithub Actionsを1から解説し、実際にこれまでCircleCIやTravisCIで行っていたPHPアプリケーションのCI/CDを、Github Actionsを利用して実現できないかを検証します。
Dockerコンテナを活用しつつ、PHPUnitによるテストや、phpcs・phpstanといったQAツールを実行する具体例として参考となるものにできればと思います。

PHP Code Snifferはコミュニティで広く支持を得て、活用されています。その為の仕組みや資産、例えばCI上での活用tipsに始まり、IDEとの連携・支援も拡がりました。これらの状況は、導入を考える人たちを強く励ますものです。
多くの場合は、「そのまますぐ使える」という土台が整っているとも言えます。フレームワークが提供しているrulesetを用いたり、PSR-12を適用するのは合理的な判断です。

しかしながら、このツールはあくまで「開発者を支援する」ものであり、「開発者を支配する」ものではありません。世間の標準に乗っかるだけでなく、チームやプロダクトの事情に応じて、本当に欲しいルールを手に入れるべきです。

そう考えた際に、独自のルールを作成できると夢が広がりませんか？
例えば、「PHP Code Sniffer」「PHP_CodeSniffer」「PHP CodeSniffer」正しいのはどれでしょうか？少なくとも言えるのは、チームでの正解はチームが決めれば良いのです。

ルールを自作する力を得て、より踏み込んだ活用の可能性を見つけませんか。

CakePHPが2015年以来のメジャーバージョンアップを行い、その番号は「4」を刻みました。
まだ「CakePHPといえば2.x時代のイメージ」という人も多いと思います。しかし、3.x台では、現代的な開発現場の要求に十分に応えられるフレームワークへと進化を遂げています。
そして4.xは「PHP7.1すらEOLを迎えた今」の時代に立脚したフレームワークです。

2.xとの比較の視点も簡単に織り交ぜつつ、「どんな魅力を持つのか」「4.xの特徴や推しポイントは」といった紹介をします。

PHPでも「型」に関する議論が盛り上がっている今、一度「型」についておさらいしてみませんか？
近年、主要なプログラミング言語の「型」を取り巻く環境が変化しています。もちろんPHPも例外ではなく、7.0以降「型」に関する機能を強化しています。
PHPでは型ヒントの強化や、Javaではローカル型推論が導入されるなど、さまざまな言語で「型」に関する機能が拡張されています。
この拡張の傾向としては、動的型付け言語(PHP,Python)は漸進的型付けを導入する、静的型付け言語(Java,C#)は型推論を導入するというのがよくみられます。
その結果、言語の型付けの方式に寄らず、必要な個所に型を記述するというスタイルに収束していきそうな気配すらあります。
しかし、両者の間で「型」そのものの扱いには明確に差があります。その差とは何でしょうか？その差は何をもたらすのでしょうか？
そして、PHP上で「型」と向き合う時が来たとき、どのように付き合っていくのがいいのでしょうか？
このセッションでは、両者の「型」の進化をおさらいしながら、PHPがこれから「型」と付き合っていく上で得られるものや課題、PHPerが「型」とうまく付き合っていくための基礎知識についておなしします。

先日、18年間運用されているシステムで大量のユニットテストを書きました。その際大量のモックを利用し、必死にコードの動作を制御するという経験をしました。
そこで得られた知見を整理すると、ぼんやりとクリーンアーキテクチャにつながる出口が見えてきました。
なぜモックを書かなければならなかったか、大量生産したモックはいったい何を意味するのか。
モックを使うことでテストを通すだけでなく、モックを利用して設計を改善する方法があるということをご紹介します。

レガシーシステムの開発中に訪れるPHPのEOL。バージョンアップ後は全機能テストが待っています。
既存のテスト仕様書では重要機能を網羅していない、書かれている単体テストは重要機能をテストしていない・・・
このような状況でユニットテストを書くためには、問題の分割と、テストで担保したいこと(目的)の設定が重要です。
18年にわたって運用されているシステムに対して、PHPUnitと、PHPの挙動を操作するuopzという拡張を利用してテストをどのように行ったのかをご紹介します。

いわゆるレガシーシステムを運用していくにあたって、ユニットテストをどう書いていくべきでしょうか。
長大な関数、引き回されるグローバル変数、オブジェクト指向へのチャレンジの痕跡・・・このようなコードのユニットテストを単純に書くのは至難の業です。
先日、18年にわたって運用されているシステムで重要機能のカバレッジを100%にするというチャレンジを行いました。
その際に、ユニットテストとモックを駆使して問題を分割していくというアプローチを取り、一定の成果を得ることに成功しました。
今回はこのチャレンジで得た知見から、テスト手法の紹介と、今回取ったアプローチを突き詰めた先の展望についてお話します。

昨今では、アクセシビリティというキーワードを耳にすることが多くなってきました。
Webアクセシビリティとは、Webコンテンツに誰もがいつでもどこでもどんな状況でもアクセスができるようにしていくことです。

Webアクセシビリティは、デザイナーやフロントエンドエンジニアが取り組むものと思われがちですが、サーバーサイドエンジニアでもできることはあります。
私たちサーバーサイドエンジニアは何ができるでしょうか？

Webコンテンツをアクセシブルにするための指標に、Web Content Accessibility Guidelines (WCAG)というガイドラインがあります。
WCAGには、コントラスト比や画像の代替テキストなどが挙げられていますが、そもそもWebコンテンツが表示できるかどうか、レスポンスが遅すぎないかどうかなどの必須条件に関しては言及されていません。

このトークでは、Webアクセシビリティを支えるためにサーバーサイドエンジニアができることにフォーカスを当てて話します。

カンファレンス、楽しいですよね。
しかし最初からそうでしたか？

私の場合、カンファレンスに参加するにはいろいろなハードルがありました。

・上級者しかいないんでしょう？
・セッション聴いたけどなるほどわからん
・参加費がお高い
・遠征費がツライ
・懇親会ぼっち・・・
・マサカリが怖い

これらをどう超えたらいいでしょう。

初めてカンファレンスに参加してから1年の間に全国の様々なカンファレンスに参加した経験から、同じハードルを抱える方や、これからカンファレンスをより楽しみたい人へ向けて、実りある時間を過ごすためのティップスを紹介します。

昨年、子供が成人式を迎えた記念に、子育てもエンジニアとして働くことも、どちらも諦めずに過ごした21年間を振り返りたいと思います。
・実家には頼れない！
・リモートワーク
・保活とか子供の受験とか
・保護者会とかPTAとか
・残業できない自分
・旦那は気軽に飲み会に…
・勉強会などのイベントに参加する旦那(エンジニア)を見送る一方、いつも留守番の私
そして、今。

PHPとは関係ない話ですみません。
イベント参加される方々に、送り出す側の気持ちを伝えたいと共に、
子育て真っ最中の方やこれから子育てする若い方々に、エールを送れたらと思います。