これにより、キーの採番はPHPが勝手に行うようになるので、array_valuesが不要になります。仮引数を可変長引数にしたので、実引数も忘れずに...でアンパックします。型チェックのコードを取り除く次に一番面積をとっているforeachを消していきます。StatusCollection(...$items);単純に型宣言(タイプヒント)を使用しています。...を使う前は配列を受け取っていたのでarrayで指定していましたが、...を使うことで配列の要素の型を指定できます。面積をとっていたforeachを削除できたので、とても見通しの良いコードになりました。まとめ...を使用することで、配列のキーを気にしなくて済む...を使用することで、配列の要素の型を指定できる...は型宣言とセットで使用することでパワーを発揮しそうです。「連想配列じゃなくてもいいんだけど・・・」という場合も結構あるので、配列のキーを気にしなくて良い場合は積極的に使っていこうと思います。匠平(@show60)です。TOKYO様の新しいオフィスにお邪魔して開催いたしました。名の方に登壇いただきました。それぞれの登壇内容をさっくりとお伝えいたします。さんに登壇いただきました。ある悩みを、チームにおけるクリーンアーキテクチャの解釈を行い解決するというお話をしていただきました。Laravelのドキュメント通りではなく、DDD、クリーンアーキテクチャを取り入れることで未来の自分が助けられる。全部を解釈するのは難しいけど、部分的に取り入れることでも恩恵が受けられるよというお話でした。導入する発表者は弊社のエンジニアのniisan-tokyo(@niisantokyo)です。プロジェクトに参画された際に、DI(依存性注入)を分かりやすく噛み砕いて理解されたというお話です。プロジェクトに入られたそうで、とても分かりやすいスライドと軽快なお話で会場を楽しませていただきました。PhpStormからLaradock上のPHPUnitを動かしたら開発が捗った話ザッキー(@ytzk_)さんの登壇です。PHPUnitテストが完了するまで時間がかかる、完了するまでエラー箇所が見れないのが辛いという課題に会場のみなさんも頷く、とても共感度の高いテーマでお話いただきました。アップデートしたときに必要だった7つのこと青ごへいもち(@blue_goheimochi)さんの登壇です。タイトルの通り、アップデートをされた際にどういうエラーが発生し、どうやって乗り越えたかというテーマでお話いただきました。Ohashiwww.slideshare.netアップデートでみんなハマりそうな箇所を一つずつ順を追って説明いただきました。分かりやすくまとめていただいているので、これからアップデートされる方には大変ためになる内容です。m-mitsuhide(@m_mitsuhide)さんの登壇です。今回は6つの登壇枠の中、唯一のVue.jsのお話となりました。いうモジュールの発表をしていただきました。リクエストを型安全にし、フロントエンドの開発支援を行うツールです。実際にライブコーディングでデモンストレーションをしていただき、来場者の方もとても興味深く見ていらっしゃいました。TOKYOさんにご用意いただき、参加者同士の懇親会を行いました。connpassさいごに株式会社ROXXでは一緒にサービスを伸ばしていく仲間を募集をしております。macTweetこんにちは。MojaveからCatalinaにアップデートしたのです。OSバージョン10.15ですね。phpのビルドが失敗するようになってしまいました。以下はphp7.3.9をビルドしようと試みたターミナルの出力結果です。情報がありませんでした。https://gist.github.com/jiska/2be7ee5a8bf70d3dbf88e537b4537c0b#file-config-logエラーを抜粋すると、hファイルが参照できていないようです。libiconv)configureは終了しましたがmakeが途中で失敗してしまいます。1make失敗しました。これを修正しても他にもオプションを追加しないといけないので大変です。手軽に複数バージョンのphpをインストール、ビルドしたかったのにこれだとつらいですね。パッチバージョンは指定できないですが(hash指定すればできるけど手軽でないので割愛)マイナーバージョンは指定できるのでなんとかなります。ファイルを配置することで使用するphpを指定できますね。PATHを変更します。~PATHこれでphpのバージョンが変更されます。Technologiesこれでphpの準備ができ、なんとか窮地を脱しました。まとめphpをhomebrewでインストールしたdirenvでPATH変更したxdebugを追加したCatalinaにバージョンアップした際には皆様もお気をつけください。作っていくメンバーを随時募集しています。この記事を読んでROXXに興味を持ってくれた方はぜひご応募ください。新マイクロサービスのアーキテクチャーにNode.jsとTypeScriptを導入したのですが、そちらの基盤技術としてInversifyを導入したらめちゃくちゃ良かったので、使い方含めて紹介します。Injection)を達成するためのコンテナのことです。}}とあったときに、Hoge::get()はFugaがnewされないと処理を実行できないため、例えばこの関数をユニットテストしたいときに、Fugaのコンストラクタの実装に依存してしまいます。コンストラクタ上でデータストアに接続するような処理がある場合、テスト環境にもデータストアの環境を整備しなければならず、本来やりたかったこと以上のことをする必要があり、面倒でありメンテコストも上がってしまいます。}}って外部から注入してあげれば、例えばfugaをモックしたオブジェクトを外から注入してあげるだけで上記の問題が解決します。これがいわゆるDIと呼ばれるものです。呼び出し元でnewすれば注入できるわけですが、そうすると呼び出し元がFugaに依存するようになってしまい、処理がより複雑になってしまいます。CleanArchitectureなどに代表される、多層化されたアーキテクチャーを採用する場合、この問題はより顕著になり、下記のようになってしまいます。{}また、どのクラスをnewすればいいかという観点において、基本的にはアプリケーションごとに唯一のクラスが指定できればいい(通常はモックなしのもの、テスト時はモックありのもの)はずなので、どこかで定義できてしまえば解決します。これを解決するために、newする処理を一つのコンテナ(オブジェクト、グローバル変数のようなもの)に集約することによって、依存性解決をわかりやすくしようというのが、DIコンテナの役割となります。Inversifyを使った方法DIコンテナは各言語、フレームワークごとに独自で実装されていたりするのですが、TypeScriptではInversifyというライブラリがあります。これは、TypeScriptのアノテーションを使うことによって、DIコンテナを実現してくれます。TypeScriptベースで作られているため、型安全に実装できるのがポイント。JavaScriptでも使用できるため、TSユーザじゃなくても使うことができるのが魅力的です。--saverefrect-metadataというものも必要なので、注意。refrect-metadataはグローバルのシングルトンなので、一度だけimportするようにしましょうtsconfig.jsonには下記のように入れていきましょう。}}使用方法まず先に実装クラスと、対応するinterfaceを実装します。今回はDB接続を想定した設計でやってみます。User;}次にDIで用いる識別子を登録していきます。Symbolで実装することを推奨しているようです。TYPES;最後に実装していきます。DIされるクラスには@injectableデコレータを、DIするインスタンスは@injectデコレータをつけていきます。}}こちらを見てもらえれば分かる通り、UserControllerはどのDBの実装クラスが使われているかも、どのUserRepositroyのインスタンスを使うかも気にすることなく、直下のUserRepositoryInterfaceを継承する何かを使うという処理を書くだけで終了します。シングルトンで登録container.bind<UserRepositoryInterface>(TYPES.UserRepo).to(UserRepository);container.bind<UserController>(TYPES.UserCntl).to(UserController);最後にコンポジションルート(最上位のmain処理)に依存性解決の処理を記載します。AWSにはDocumentDBというMongoDB互換のDBがあります。こちらのDBはほとんどMongoDBと同等なのですが、TLS接続が標準であり安全性のために必須にしているかと思います。ローカルではTLS接続はしたくないといったパターンの場合、上記でいうconnect()の関数だけ変更したくなります。いった場合は、下記のように専用のクラスを作り、inversify.config.tsを変更するだけです。Mongo());たったこれだけで本番環境と開発環境でデータストアを切り替えることができます。テストで使いたいテスト環境で使いたい場合も非常にシンプルです。下記のように注入したいモックオブジェクトを作成し、それを注入するだけです。});});また、この他containerにはrebindという関数もあるため、テスト全体で用いるinversify.config.tsを予め用意しておき、テスト専用のモックをrebindで新たにbindした上でテストを行うことによって、多層的な依存関係のクラスのテストも容易になります。まとめ今回はTypeScriptでinversifyを使ったDIコンテナの紹介をさせていただきました。軽量なアプリケーションではこのようなアーキテクチャは不要かもしれませんが、変化が激しい、レイヤーが複数あるアプリケーションや、外部との接続が多いBFFのようなものを実装する際は、処理の実行確認が非常に難しくなるため、使える技術かなと思っています。皆様のおかげで、NuxtMeetUpも第9回目を迎えました。そこで今回は、今までのNuxtMeetUpで協賛頂いた企業様をあつめ、各社からLT登壇していただくという形を試みました。今回のスポンサーである株式会社メルペイ様のご協力のおかげで過去最大規模である300人定員のNuxtMeetUpを行うことが出来ました。会場は六本木ヒルズ森タワーの18階にてやらせていただきました。今回300人定員のなか120人ほど当日キャンセルが出てしまい、参加者自体は220人ほどでしたが改めて見てもすごい人数だったなと思います。暑い中ご参加いただき本当にありがとうございます。今回スポンサー枠のメルペイさん含め8人の方にLTをしていただきました。全てを書くと長くなってしまうためいくつかピックアップして書いていきたいと思います。yuiさんがご登壇してくれました。speakerdeck.com最近良く耳にするTypeScriptとNuxt.jsでのAPI周りで別ドメインのAPIを叩く際にいい方法はないのかということについて話してくれました。APIを持つという話があり良さそうだなと思いました。Nuxt.jsとテストコード株式会社エス・エム・エス様からはkeitaさんが話してくださいました。speakerdeck.comスライド見ていただけるとわかると思いますが、Nuxt.jsでのテストの種類・目的・書き方についてお話してくれました。株式会社メルペイ様からはtanakaworldさんがご登壇してくれました。speakerdeck.comプロダクトチームの粒度に合わせてマイクロサービスを分割したという実例をもとに話してくださり、今後同じようにマイクロサービスを分割しないといけない課題にあたっている方には貴重なセッションだったのではと思います。ピースオブケイク様・株式会社ガイアックス様の代表として登壇してくださり本当にありがとうございました。APIを使う懇親会ミートアップですので発表と同じくらい大事な懇親会の様子です。100名以上の方が残ってくださりとても大盛りあがりでした。まとめ今回オールスターズということもあり大変豪華なメンバーにご登壇いただきとても濃い時間を過ごすことができました。次回の開催はまだ未定ですが、詳細が決まり次第connpassで告知させていただきます。ご協力していただける企業様がいましたら、ご連絡いただけますと幸いです。最後に現在、株式会社ROXXでは、エンジニア、デザイナーの募集をしております。先日認定スクラムマスター(CSM)の研修を受けに行ってきました。一将さんの研修を受講しました。この研修で最も学べたことはスクラムの知識だったりチームを自立させる方法とかではなく、スクラムマスターとしての考え方だったと思っています。そのため全てをこの記事に書ききることは出来ませんが、特に印象深かった考え方について書いていきたいと思います。提案は論理的になっていて計測できなければならない前提として基本的にはスクラムマスターがなにかの意思決定をする権限はありません。スクラムマスターの発言は提案になり、提案するという行動は他の人の時間を使うという行為になります。そのため発言する際には責任を持たなければならないということを常々おっしゃっていました。論理的ではない提案をしてしまった時、提案された側はたまたま同じアイディアを持っていない限り動こうとは思わないかと思います。江端さんの話を聞いていて、相手が協力的に動いてくれる条件として以下になるのではと思いました。提案したアイディアの理由が理にかなっていて、それを実行したことによりチームがよくなっているということを計測できる仕組みになっているチームとしてやりたいと思っていたものに矢印が向いていて提案したものはそこに辿り着くためのプロセスになっているとなおよしトップダウンではないスクラムにおいて、上記2つが出来ているからこそチームが協力的に動いてくれるかと思っています。最後の一人になっても考え続けなければならない先程も話しましがスクラムマスターに決定する権限は基本的にありません。振り返りなどでtryが全然決まらない時に決め方を提案したり、決める前にもっといい案がないかを考えたりはスクラムマスターは行うと思いますが最終的に決めるのは開発チームになります。決まった後もスクラムマスターはそれよりもいい案はないのか、もっとチームを今よりよくする案は本当にないのかを考え続けなければいけないです。変わらないというのは現状維持なのでスクラムをマスターしている人の考え方として本当にいいのかということを考えさせられました。スプリントレトロスペクティブは答え合わせ江端さん曰く、スクラムの公式イベントにあるスプリントレトロスペクティブはスクラムマスターにとって答え合わせの時間。スクラムマスターはチームの現状把握として課題は先に洗い出して置かなければなりません。チームの本質的な課題が分からなければチームがよりよくなる提案など出来ないです。そのため先にチームの現状を把握できるようにしておかなければいけません。いう意味でスクラムマスターにとってスプリントレトロスペクティブは答え合わせなんだと思います。飲み会の席で聞いて驚いたのですが、江端さんの頭の中には参加者36人の3日間のタイムラインが頭の中にはあると言っていました。現状自分の力だと頭の中にメンバー全てのタイムラインを作成することが出来ないので、現在はチームのタイムラインはチームに貼ってもらっています。それとは別で個人のタイムラインを自分が作成してスプリントレトロスペクティブまでに課題を探し出してリストを作成するという取り組みを行っています。結果的には1日目に出された議題に対して最後まで結論が出ずにCSMは終了してしまいました。1日目の議題から課題が膨れ上がっていく中で、その一つ一つの課題に対してとにかく論理的に解を出すことが求められました。「その解によって本当にチームがよくなると思っているのか」「発言する時には36人全員の手を止めることなるがその責任を持って発言しているか」「チームが協力的に動いてくれるにはどのような提案をすればいいのか」を常に考え続ける3日間でした。自分がスクラムマスターを学ぶきっかけになったのは、開発チームの人数が多くなったため「1チームだったのを2チームに分けたほうがいいよね」「1チームだったらなんとかなるけど2チームをPOだけで見るのは辛いよね」ということからスクラムマスターを置くことになりスクラムマスターを任命され今に至ります。江畑さんの言葉になりますが「上司からスクラムマスターを任命されたからスクラムマスターになれるのではなく、スクラムマスターとしての動きをしていて、周りからスクラムマスターみたいだねと言われて初めてスクラムマスターになれる」とおっしゃっていました。自分はまだ前者になるので周りからスクラムマスターだねと言われるように、「論理的に考えられているか」「他によりよくなる方法は本当にないか」を常に考え行動していきたいと思います。論理や指標についてずっと頭を使い続けた3日間。研修期間中はもちろんでしたが、研修終わって2週間経った今でも夢に出てくるのはやめてください江端さん。最後にチームが成長していくにあたり、これからもメンバーを増やしてもっと生産性の高いチームにしていきたいと思っています。jiskaと書いて「ゆうすけ」と読んで欲しい中二病を20年近く患ってるんですが誰にも伝わらないのが最近の悩みです。ご覧いただけますと幸いです。用いてMonorepoを新規構築するための手順をまとめます。複数パッケージを一つのレポジトリで管理するための機能です。それぞれのパッケージでpackage.jsonを保持しつつ、yarn.lockはプロジェクトのrootに1つだけ作られるようになります。ディレクトリ以下すべてのディレクトリがworkspace管理の対象に含まれます。とパッケージを追加してみます。yarn.lockは以下のように配置されます。