macOS Catalinaにアップデートしたらphpenv installでビルドエラーしたのでhomebrew phpつかうようにした

PHP mac

f:id:jiska_roxx:20191031010953j:plain:w200

こんにちは。開発部の森です。

先日MacBook Proが故障してしまったので修理に出したらクリーンインストールされて返却されたので、せっかくだから新しい環境作るかと思いmacOS MojaveからCatalinaにアップデートしたのです。

OSバージョン

10.15ですね。

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15
BuildVersion:   19A602

症状

phpenv でphpのビルドが失敗するようになってしまいました。

以下はphp7.3.9をビルドしようと試みたターミナルの出力結果です。

$ phpenv install 7.3.9
[Info]: Loaded extension plugin
[Info]: Loaded apc Plugin.
[Info]: Loaded composer Plugin.
[Info]: Loaded github Plugin.
[Info]: Loaded uprofiler Plugin.
[Info]: Loaded xdebug Plugin.
[Info]: Loaded xhprof Plugin.
[Info]: Loaded zendopcache Plugin.
[Info]: php.ini-production gets used as php.ini
[Info]: Building 7.3.9 into /Users/jiska/.anyenv/envs/phpenv/versions/7.3.9
[Skipping]: Already downloaded and extracted https://secure.php.net/distributions/php-7.3.9.tar.bz2
[Preparing]: /var/tmp/php-build/source/7.3.9

-----------------
|  BUILD ERROR  |
-----------------

Here are the last 10 lines from the log:

-----------------------------------------
configure: WARNING: This bison version is not supported for regeneration of the Zend/PHP parsers (found: 2.3, min: 204, excluded: ).
configure: error: Cannot find zlib
-----------------------------------------

The full Log is available at '/tmp/php-build.7.3.9.20191029095924.log'.
[Warn]: Aborting build.

tmpに出力されたログには Cannot find zlib しか情報がありませんでした。

ログ全文はこちら https://gist.github.com/jiska/2be7ee5a8bf70d3dbf88e537b4537c0b#file-php-build-7-3-5-20191022215209-log

phpenvがダウンロードした /var/tmp/php-build/source/7.3.9 に出力された config.log を確認してみます。

config.log全文はこちら https://gist.github.com/jiska/2be7ee5a8bf70d3dbf88e537b4537c0b#file-config-log

エラーを抜粋すると、hファイルが参照できていないようです。

$ cd /var/tmp/php-build/source/7.3.9
$ grep 'fatal err' config.log
conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found
conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found
conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found
conftest.c:52:10: fatal error: 'minix/config.h' file not found
conftest.c:19:10: fatal error: 'minix/config.h' file not found
conftest.c:60:10: fatal error: 'sys/pstat.h' file not found
conftest.c:27:10: fatal error: 'sys/pstat.h' file not found
conftest.c:28:10: fatal error: 'sys/exec.h' file not found
conftest.c:40:10: fatal error: 'sys/prctl.h' file not found
conftest.c:47:12: fatal error: 'port.h' file not found
conftest.c:48:12: fatal error: 'sys/devpoll.h' file not found
conftest.c:47:12: fatal error: 'sys/epoll.h' file not found
conftest.c:48:10: fatal error: 'sys/apparmor.h' file not found
conftest.c:98:10: fatal error: 'crypt.h' file not found
conftest.c:101:10: fatal error: 'ieeefp.h' file not found
conftest.c:124:10: fatal error: 'sys/statfs.h' file not found
conftest.c:125:10: fatal error: 'sys/vfs.h' file not found
conftest.c:125:10: fatal error: 'sys/sysexits.h' file not found
conftest.c:125:10: fatal error: 'sys/varargs.h' file not found
conftest.c:126:10: fatal error: 'sys/loadavg.h' file not found
conftest.c:128:10: fatal error: 'unix.h' file not found
conftest.c:305:10: fatal error: 'io.h' file not found
conftest.c:272:10: fatal error: 'io.h' file not found

エラーは置いておいて手動でconfigure, makeしてみます。

# iconv指定しないとconfigure正常終了しないのでlibiconvもインストールしておく
$ brew install libiconv
$ ./configure --with-iconv=$(brew --prefix libiconv)

configureは終了しましたがmakeが途中で失敗してしまいます。

$ make 
 (中略)
Undefined symbols for architecture x86_64:
  "_libiconv", referenced from:
      _php_iconv_string in iconv.o
      __php_iconv_strlen in iconv.o
      _zif_iconv_substr in iconv.o
      __php_iconv_strpos in iconv.o
      _zif_iconv_mime_encode in iconv.o
      __php_iconv_appendl in iconv.o
      _php_iconv_stream_filter_append_bucket in iconv.o
      ...
  "_libiconv_close", referenced from:
      _php_iconv_string in iconv.o
      __php_iconv_strlen in iconv.o
      _zif_iconv_substr in iconv.o
      __php_iconv_strpos in iconv.o
      _zif_iconv_mime_encode in iconv.o
      __php_iconv_mime_decode in iconv.o
      _php_iconv_stream_filter_factory_create in iconv.o
      ...
  "_libiconv_open", referenced from:
      _php_iconv_string in iconv.o
      __php_iconv_strlen in iconv.o
      _zif_iconv_substr in iconv.o
      __php_iconv_strpos in iconv.o
      _zif_iconv_mime_encode in iconv.o
      __php_iconv_mime_decode in iconv.o
      _php_iconv_stream_filter_factory_create in iconv.o
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sapi/cli/php] Error 1

make失敗しました。これを修正しても他にもオプションを追加しないといけないので大変です。

手軽に複数バージョンのphpをインストール、ビルドしたかったのにこれだとつらいですね。

暫定対応

homebrewでphpをインストールする

phpenvをいったん諦め、 homebrewで提供されているphp を使うことにします。

パッチバージョンは指定できないですが（hash指定すればできるけど手軽でないので割愛）マイナーバージョンは指定できるのでなんとかなります。

# 2019-10-29現在 7.3.11 がインストールされる
$ brew install php
（後略）

$ /usr/local/opt/php/bin/php -v
PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:00) ( NTS )
（後略）

# php@7.2 だと 7.2.24 がインストールされる
$ /usr/local/opt/php@7.2/bin/php -v
PHP 7.2.24 (cli) (built: Oct 25 2019 11:13:56) ( NTS )
（後略）

direnvでPATHを変更する

phpenvを使っているとディレクトリに .php-version ファイルを配置することで使用するphpを指定できますね。それに近い設定をするべく direnv でPATHを変更します。

direnvをインストール、.profileなどに設定を追加後にphpのバージョンを変更したいディレクトリに以下のような .envrc を配置し direnv allow . します。

$ cd path/to/my-project

# この例ではphp 7.2を指定している
$ cat .envrc
export PATH="/usr/local/opt/php@7.2/bin:$PATH"

$ direnv allow .

direnv: loading .envrc
direnv: export ~PATH

これでphpのバージョンが変更されます。

$ cd path/to/my-project

direnv: loading .envrc
direnv: export ~PATH

# 7.2.24 になった
$ which php
/usr/local/opt/php@7.2/bin/php

$ php -v
PHP 7.2.24 (cli) (built: Oct 25 2019 11:13:56) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.24, Copyright (c) 1999-2018, by Zend Technologies

# 他のディレクトリに移動するとphpのバージョンが標準のものにもどる
$ cd

direnv: unloading

$ which php
/usr/local/bin/php

$ php -v
PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:00) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.11, Copyright (c) 1999-2018, by Zend Technologies

Xdebugをインストールする

開発には Xdebug が欠かせないので pecl でインストールします。

# peclのPATHも変更されている
$ which pecl
/usr/local/opt/php@7.2/bin/pecl

$ pecl install xdebug
（後略）

# Xdebugがインストールされた
$ php -v
PHP 7.2.24 (cli) (built: Oct 25 2019 11:13:56) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans
    with Zend OPcache v7.2.24, Copyright (c) 1999-2018, by Zend Technologies

これでphpの準備ができ、なんとか窮地を脱しました。

まとめ

  • phpをhomebrewでインストールした
  • direnvでPATH変更した
  • xdebugを追加した

Catalinaにバージョンアップした際には皆様もお気をつけください。

最後に

株式会社ROXXでは一緒に agent bank と back check を作っていくメンバーを随時募集しています。 この記事を読んでROXXに興味を持ってくれた方はぜひご応募ください。   www.wantedly.com

Inversifyを使った、型堅牢なDIコンテナの構築

Inversifyを使った、型堅牢なDIコンテナの構築

こんにちは、 kotamatです。 新マイクロサービスのアーキテクチャーにNode.jsとTypeScriptを導入したのですが、そちらの基盤技術としてInversifyを導入したらめちゃくちゃ良かったので、使い方含めて紹介します。

DIコンテナって何？

DI(Dependency Injection)を達成するためのコンテナのことです。

DIは色んな所で紹介されているので、割愛しますが、簡単に言うと

class Hoge {
    get() {
        const fuga = new Fuga()
        ...
    }
}

とあったときに、Hoge::get()はFugaがnewされないと処理を実行できないため、例えばこの関数をユニットテストしたいときに、Fugaのコンストラクタの実装に依存してしまいます。 例えばコンストラクタ上でデータストアに接続するような処理がある場合、テスト環境にもデータストアの環境を整備しなければならず、本来やりたかったこと以上のことをする必要があり、面倒でありメンテコストも上がってしまいます。

これを

class Hoge {
    get(fuga: Fuga) {
        ...
    }
}

って外部から注入してあげれば、例えばfugaをモックしたオブジェクトを外から注入してあげるだけで上記の問題が解決します。 これがいわゆるDIと呼ばれるものです。

当然呼び出し元でnewすれば注入できるわけですが、そうすると呼び出し元がFugaに依存するようになってしまい、処理がより複雑になってしまいます。 CleanArchitectureなどに代表される、多層化されたアーキテクチャーを採用する場合、この問題はより顕著になり、下記のようになってしまいます。

/// A -> B -> Cという依存

class A {
    constructor() {
        new c = C()
        new b = B(c)
    }
}

class B {
    constructor(c: C) {
    ...
    }
}

class C {
}

また、どのクラスをnewすればいいかという観点において、基本的にはアプリケーションごとに唯一のクラスが指定できればいい（通常はモックなしのもの、テスト時はモックありのもの）はずなので、どこかで定義できてしまえば解決します。

これを解決するために、newする処理を一つのコンテナ（オブジェクト、グローバル変数のようなもの）に集約することによって、依存性解決をわかりやすくしようというのが、DIコンテナの役割となります。

Inversifyを使った方法

DIコンテナは各言語、フレームワークごとに独自で実装されていたりするのですが、TypeScriptではInversifyというライブラリがあります。 Inversify これは、TypeScriptのアノテーションを使うことによって、DIコンテナを実現してくれます。 TypeScriptベースで作られているため、型安全に実装できるのがポイント。 JavaScriptでも使用できるため、TSユーザじゃなくても使うことができるのが魅力的です。

インストール

npm install inversify reflect-metadata --save

refrect-metadataというものも必要なので、注意。 refrect-metadataはグローバルのシングルトンなので、一度だけimportするようにしましょう

tsconfig.jsonには下記のように入れていきましょう。

{
    "compilerOptions": {
        "target": "es5",
        "lib": ["es6", "dom"],
        "types": ["reflect-metadata"],
        "module": "commonjs",
        "moduleResolution": "node",
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true
    }
}

使用方法

まず先に実装クラスと、対応するinterfaceを実装します。 今回はDB接続を想定した設計でやってみます。

interface DatabaseInterface {
    connect(option: Option): void;
    find<T>(query: Query): T;
}

interface UserRepositoryInterface {
    find(id: string): User;
}

次にDIで用いる識別子を登録していきます。 Symbolで実装することを推奨しているようです。

let TYPES = {
    DB: Symbol("DB"),
    UserRepo: Symbol("UserRepo"),
    UserCntl: Symbol("UserCntl")
}
export default TYPES;

最後に実装していきます。DIされるクラスには@injectableデコレータを、DIするインスタンスは@injectデコレータをつけていきます。

import { injectable, inject } from 'inversify';
import 'reflect-metadata';
import TYPES from './types';

// DB
@injectable()
class Mongo implements DatabaseInterface {
    public connect(option): void {
        // ...
    }
    
    public find<T>(query: Query): T {
        // ... 
        const res: T= {} as T;
        return res
    }
}

// Repo
@injectable()
class UserRepository implements UserRepositoryInterface {

    private _db: DatabaseInterface;

    public constructor(
        @inject(TYPES.DB) db: DatabaseInterface // constructorに注入
    ) {
        this._db = db
    }

    public find(id: string): User {
        const query: Query = {};
        return this._db.find<User>(query);
    }
}

// Controller

class UserController {
    @inject(TYPES.UserRepo) private _repo: UserRepositoryInterface; // property に直接注入
    
    public get(): User {
        const userId: string = 'hoge';
        return this._repo.find(userId);
    }
}

こちらを見てもらえれば分かる通り、UserControllerはどのDBの実装クラスが使われているかも、どのUserRepositroyのインスタンスを使うかも気にすることなく、直下のUserRepositoryInterfaceを継承する何かを使うという処理を書くだけで終了します。

実際の依存関係は inversify.config.ts に記載します。

import { Container } from 'inversify';
import TYPES from './types';

const container = new Container();
container.bind<DatabaseInterface>(TYPES.DB).toConstantValue(new Mongo()); // シングルトンで登録
container.bind<UserRepositoryInterface>(TYPES.UserRepo).to(UserRepository);
container.bind<UserController>(TYPES.UserCntl).to(UserController);

最後にコンポジションルート(最上位のmain処理)に依存性解決の処理を記載します。

import container from './inversify.config';
import { UserController, DatabaseInterface } from './main';
import TYPES from './types';

function main() {
    // Controllerでゴニョゴニョする
    const controller = container.get<UserController>(TYPES.UserCntl);

    const user = controller.get()
    console.log(user) //　なにかする
}

main();

何がいいの？

開発環境と本番環境でDB接続が違う場合

例えばAWSにはDocumentDBというMongoDB互換のDBがあります。 こちらのDBはほとんどMongoDBと同等なのですが、TLS接続が標準であり安全性のために必須にしているかと思います。 ただ、ローカルではTLS接続はしたくないといったパターンの場合、上記でいうconnect()の関数だけ変更したくなります。

そういった場合は、下記のように専用のクラスを作り、inversify.config.tsを変更するだけです。

@injectable()
class DocDB extends Mongo {
  protected ca: Buffer[];

  public constructor() {
    super();
    this.ca = [fs.readFileSync("/path/to/pem/rds-combined-ca-bundle.pem")]; // caファイルの読み込み
  }
  public connect(): void { // connectのオーバーライド
    ...
    this.client = new MongoClient(url, {
      auth: { user, password },
      useNewUrlParser: true,
      useUnifiedTopology: true,
      sslValidate: true,
      sslCA: this.ca
    });
  }
}

inversify.config.ts

container.bind<DatabaseInterface>(TYPES.DB).toConstantValue(
    process.env.NODE_ENV === 'production' ? new DocDB() : new Mongo()
);

たったこれだけで本番環境と開発環境でデータストアを切り替えることができます。

テストで使いたい

テスト環境で使いたい場合も非常にシンプルです。 UserRepositoryをテストしたい場合は、 下記のように注入したいモックオブジェクトを作成し、それを注入するだけです。

import * as TypeMoq from "typemoq";

describe("test", (): void => {
  test("repo", async () => {
    const user = {};
    const mock: TypeMoq.IMock<DatabaseInterface> = TypeMoq.Mock.ofType<
      DatabaseInterface
    >();
    mock
      .setup(m => m.find<User>("id"))
      .returns(() => user);
    const repo = new UserRepository(mock.object);

    const result = repo.find("id");
    expect(result).toBe(user);
  });
});

また、この他containerにはrebindという関数もあるため、テスト全体で用いるinversify.config.tsを予め用意しておき、テスト専用のモックをrebindで新たにbindした上でテストを行うことによって、多層的な依存関係のクラスのテストも容易になります。

まとめ

今回はTypeScriptでinversifyを使ったDIコンテナの紹介をさせていただきました。 軽量なアプリケーションではこのようなアーキテクチャは不要かもしれませんが、変化が激しい、レイヤーが複数あるアプリケーションや、外部との接続が多いBFFのようなものを実装する際は、処理の実行確認が非常に難しくなるため、使える技術かなと思っています。

NuxtMeetUp#9 オールスターズを開催しました

こんにちは株式会社ROXXの西澤 央貴です。

皆様のおかげで、NuxtMeetUpも第9回目を迎えました。 そこで今回は、今までのNuxtMeetUpで協賛頂いた企業様をあつめ、各社からLT登壇していただくという形を試みました。

今回のスポンサーである株式会社メルペイ様のご協力のおかげで過去最大規模である300人定員のNuxtMeetUpを行うことが出来ました。ありがとうございました！

会場

会場は六本木ヒルズ森タワーの18階にてやらせていただきました。

f:id:hiroki-nishizawa:20190827112358j:plain

今回300人定員のなか120人ほど当日キャンセルが出てしまい、参加者自体は220人ほどでしたが改めて見てもすごい人数だったなと思います。暑い中ご参加いただき本当にありがとうございます。

発表

今回スポンサー枠のメルペイさん含め8人の方にLTをしていただきました。全てを書くと長くなってしまうためいくつかピックアップして書いていきたいと思います。

Nuxt.js+TypeScriptのベストプラクティスを考えてみる

株式会社サイバーエージェント様からはTanaka yuiさんがご登壇してくれました。

f:id:hiroki-nishizawa:20190827112442j:plain

speakerdeck.com

最近良く耳にするTypeScriptとNuxt.jsでのAPI周りで別ドメインのAPIを叩く際にいい方法はないのかということについて話してくれました。Nuxt.jsでBFF APIを持つという話があり良さそうだなと思いました。

Nuxt.jsとテストコード

株式会社エス・エム・エス様からはkeitaさんが話してくださいました。

f:id:hiroki-nishizawa:20190827112531j:plain

speakerdeck.com

スライド見ていただけるとわかると思いますが、Nuxt.jsでのテストの種類・目的・書き方についてお話してくれました。ComponentsやVuex、E2Eのテストについえてそれぞれサンプルコードもあるのでとてもわかり易いなと思いました

Nuxt マイクロサービスを3つに分割した話

株式会社メルペイ様からはtanakaworldさんがご登壇してくれました。

f:id:hiroki-nishizawa:20190827112609j:plain

speakerdeck.com

プロダクトチームの粒度に合わせてマイクロサービスを分割したという実例をもとに話してくださり、今後同じようにマイクロサービスを分割しないといけない課題にあたっている方には貴重なセッションだったのではと思います。

スライドまとめ

今記事では細かく書くことが出来ませんでしたが、LINE株式会社様・株式会社ピースオブケイク様・株式会社ガイアックス様の代表として登壇してくださり本当にありがとうございました。

懇親会

ミートアップですので発表と同じくらい大事な懇親会の様子です。

f:id:hiroki-nishizawa:20190827113950j:plain

f:id:hiroki-nishizawa:20190827113959j:plain

100名以上の方が残ってくださりとても大盛りあがりでした。

まとめ

今回オールスターズということもあり大変豪華なメンバーにご登壇いただきとても濃い時間を過ごすことができました。

次回の開催はまだ未定ですが、詳細が決まり次第connpassで告知させていただきます。もしご協力していただける企業様がいましたら、ご連絡いただけますと幸いです。

最後に

現在、株式会社ROXXでは、エンジニア、デザイナーの募集をしております。

興味のある方は、是非下記からご応募お願い致します！

www.wantedly.com

www.wantedly.com

www.wantedly.com

スクラムマスターとしての考え方[CSM]

はじめに

こんにちは株式会社ROXXでスクラムマスターをやっている西澤 央貴です。

先日認定スクラムマスター(CSM)の研修を受けに行ってきました。講師は日本人で唯一の認定スクラムトレーナー(CST)である江端 一将さんの研修を受講しました。

この研修で最も学べたことはスクラムの知識だったりチームを自立させる方法とかではなく、スクラムマスターとしての考え方だったと思っています。そのため全てをこの記事に書ききることは出来ませんが、特に印象深かった考え方について書いていきたいと思います。

提案は論理的になっていて計測できなければならない

前提として基本的にはスクラムマスターがなにかの意思決定をする権限はありません。なのでスクラムマスターの発言は提案になり、提案するという行動は他の人の時間を使うという行為になります。そのため発言する際には責任を持たなければならないということを常々おっしゃっていました。

論理的ではない提案をしてしまった時、提案された側はたまたま同じアイディアを持っていない限り動こうとは思わないかと思います。

江端さんの話を聞いていて、相手が協力的に動いてくれる条件として以下になるのではと思いました。

  • 提案したアイディアの理由が理にかなっていて、それを実行したことによりチームがよくなっているということを計測できる仕組みになっている
  • チームとしてやりたいと思っていたものに矢印が向いていて提案したものはそこに辿り着くためのプロセスになっているとなおよし

トップダウンではないスクラムにおいて、上記2つが出来ているからこそチームが協力的に動いてくれるかと思っています。

最後の一人になっても考え続けなければならない

先程も話しましがスクラムマスターに決定する権限は基本的にありません。なので振り返りなどでtryが全然決まらない時に決め方を提案したり、決める前にもっといい案がないかを考えたりはスクラムマスターは行うと思いますが最終的に決めるのは開発チームになります。

ただ決まった後もスクラムマスターはそれよりもいい案はないのか、もっとチームを今よりよくする案は本当にないのかを考え続けなければいけないです。変わらないというのは現状維持なのでスクラムをマスターしている人の考え方として本当にいいのかということを考えさせられました。

スプリントレトロスペクティブは答え合わせ

江端さん曰く、スクラムの公式イベントにあるスプリントレトロスペクティブはスクラムマスターにとって答え合わせの時間。

スクラムマスターはチームの現状把握として課題は先に洗い出して置かなければなりません。チームの本質的な課題が分からなければチームがよりよくなる提案など出来ないです。そのため先にチームの現状を把握できるようにしておかなければいけません。そういう意味でスクラムマスターにとってスプリントレトロスペクティブは答え合わせなんだと思います。

飲み会の席で聞いて驚いたのですが、江端さんの頭の中には参加者36人の3日間のタイムラインが頭の中にはあると言っていました。

現状自分の力だと頭の中にメンバー全てのタイムラインを作成することが出来ないので、現在はチームのタイムラインはチームに貼ってもらっています。それとは別で個人のタイムラインを自分が作成してスプリントレトロスペクティブまでに課題を探し出してリストを作成するという取り組みを行っています。

CSMの感想

結果的には1日目に出された議題に対して最後まで結論が出ずにCSMは終了してしまいました。1日目の議題から課題が膨れ上がっていく中で、その一つ一つの課題に対してとにかく論理的に解を出すことが求められました。「その解によって本当にチームがよくなると思っているのか」「発言する時には36人全員の手を止めることなるがその責任を持って発言しているか」「チームが協力的に動いてくれるにはどのような提案をすればいいのか」を常に考え続ける3日間でした。

自分がスクラムマスターを学ぶきっかけになったのは、開発チームの人数が多くなったため「1チームだったのを2チームに分けたほうがいいよね」「1チームだったらなんとかなるけど2チームをPOだけで見るのは辛いよね」ということからスクラムマスターを置くことになりスクラムマスターを任命され今に至ります。

江畑さんの言葉になりますが「上司からスクラムマスターを任命されたからスクラムマスターになれるのではなく、スクラムマスターとしての動きをしていて、周りからスクラムマスターみたいだねと言われて初めてスクラムマスターになれる」とおっしゃっていました。自分はまだ前者になるので周りからスクラムマスターだねと言われるように、「論理的に考えられているか」「他によりよくなる方法は本当にないか」を常に考え行動していきたいと思います。

ただ論理や指標についてずっと頭を使い続けた3日間。研修期間中はもちろんでしたが、研修終わって2週間経った今でも夢に出てくるのはやめてください江端さん。。。

最後に

チームが成長していくにあたり、これからもメンバーを増やしてもっと生産性の高いチームにしていきたいと思っています。

新規事業や既存事業の拡大も考えているため自分の力で事業を成長させたいエンジニアを絶賛募集中です！

興味のある方は下記からご応募いただくか、こちらまでご連絡ください！！

www.wantedly.com

www.wantedly.com

yarn workspace で複数パッケージを同一レポジトリで管理する

SARDINEエンジニアの @jiskanulo です。jiskaと書いて「ゆうすけ」と読んで欲しい中二病を20年近く患ってるんですが誰にも伝わらないのが最近の悩みです。

SARDINEでは、たとえばお客さまが見る画面やROXX社内の人間が操作する管理画面、それらで共通で参照するパッケージ、API通信をやりとりするサーバー...などなど様々な用途のレポジトリが存在していますが、現在それら複数パッケージを同一レポジトリで管理する Monorepo 化を進めています。

MonoRepo化を進めているかの詳細はCTO @kotamats が登壇しました Monolith→MultiRepo→MonoRepoにいく上でのリポジトリ戦略 もご覧いただけますと幸いです。

この記事では yarn workspace を用いてMonorepoを新規構築するための手順をまとめます。

また、今回の記事を通して作成したレポジトリは https://github.com/jiska/yarn-workspace-example にpushしています。

yarn workspace

yarn workspace は複数パッケージを一つのレポジトリで管理するための機能です。 それぞれのパッケージでpackage.jsonを保持しつつ、yarn.lockはプロジェクトのrootに1つだけ作られるようになります。

workspaceを有効にするためにpackage.jsonに "private": true, "workspaces": ["packageのパス"] の記述を追加します。

{
  "name": "yarn-workspace-example",
  "version": "1.0.0",
  "main": "index.js",
  "author": "yusuke mori <210861+jiska@users.noreply.github.com>",
  "license": "MIT",
  "private": true,
  "workspaces": [
    "packages/*"
  ]
}

パスにはワイルドカード指定ができるのでこの場合は packages ディレクトリ以下すべてのディレクトリがworkspace管理の対象に含まれます。

パッケージを追加する

package-one , package-two とパッケージを追加してみます。package-oneはNuxtをただ追加しただけの素ページ、package-twoは vue create で作成したページです。

package.json, yarn.lockは以下のように配置されます。

.
├── package.json
├── packages
│   ├── package-one
│   │   └── package.json
│   └── package-two
│       └── package.json
└── yarn.lock

yarn workspace <workspace_name>

各パッケージのディレクトリにcdせずにプロジェクトrootから各パッケージに向けて yarn run や yarn add を行うことができます。

詳細は https://yarnpkg.com/en/docs/cli/workspace をご確認ください。

yarn workspace package-one dev と yarn workspace package-two serve している様子をAsciinemaにアップロードしています。

asciicast

git pre-commit hookを調整する

pre-commit hookの調整に Husky と lint-staged と ESLint を追加します。

これらはプロジェクト全体で利用したいのでプロジェクトrootのpackage.jsonに追加します。 追加するためには -W オプションを付与する必要があります。

yarn add --dev -W husky lint-staged eslint

pre-commit hookが動作している様子をAsciinemaにアップロードしています。

asciicast

今回は新規パッケージを作成するため0からレポジトリを構築しましたが、既存のレポジトリを追加したり npm publish の手順については触れませんでした。

それらのニーズを叶えるには Lerna を使うとよさそうです。LernaとYarn workspaceは共存可能なので今回の記事の内容と合わせて試してみてください。

最後に

株式会社ROXXでは一緒に SARDINE と back check を作っていくメンバーを随時募集しています。 この記事を読んでROXXに興味を持ってくれた方はぜひご応募ください。   www.wantedly.com

v-for 内でコンポーネント、クラス名、イベントハンドラまで動的に指定する

Nuxt.js

ROXX エンジニアの匠平(@show60)です。

同じようなタグが繰り返されているのを見ると、どうにかスッキリまとめられないもんかなと思いますよね。

今回はアイコンコンポーネントを例に、 v-for 内で動的な指定と、クラス名、イベントハンドラの設定までやってみようと思います。

v-for のループ内で任意のカスタムタグを指定する

ユースケースとしては、バラバラのコンポーネントを並べたいときなどでしょう。

1 つのアイコンのみを含んだコンポーネントがあるとして、並びに規則性のある場合には 1 つずつタグを置いてスタイルを設定するよりもコード量が減ってスッキリします。

下記のコードを例にすると、各アイコンコンポーネントが並ぶとき、コードの見通しはいいのですが同じクラス名が入ってくると冗長になりがちなのですっきりとさせたい気持ちです。

<icon-news-feed class="icon"/>
<icon-my-page class="icon"/>
<icon-settings class="icon"/>

配列の要素名と同じアイコンを指定する

下記のようなアイコンの名称が入った配列を用意します。

// 並べたいアイコン
icons: [
  'news-feed',
  'my-page',
  'settings'
]

テンプレートでこのように記述します。

// template
<ul>
  <li
    v-for="(icon, index) in icons"
    :key="index"
  >
    <component 
      :is="icon-${icon}"
    />
  </li>
</ul>

Vue の is 属性を使うことでコンポーネントを動的に生成できるため、単純な v-for だけで表現できます。

注意が必要なのは、当然ですがこれらのアイコンコンポーネントの import は個別に必要ということです。

ここでは 3 つのコンポーネントを例にしていますが、もっとアイコンが増えると利用価値も十分あるかと思います。

また、このアイコンを並べるコンポーネントを用意し、並べたいアイコン名を配列にして親コンポーネントから props で渡すだけで指定することができます。

API — Vue.js

component タグにクラス名を追加すると、呼ばれているアイコンコンポーネントにクラス名が追加されます。こちらも動的に指定できますので例を挙げてみます。

クラス名を動的に指定

ナビバーやフッターなどでは、上記のようにアイコンを並べることがあるかと思いますが、現在のページのアイコンのみ色を変えたいですね。その場合は、動的にクラス名を指定すればよさそうです。

// template
<ul>
  <li
    v-for="(icon, index) in icons"
    :key="index"
  >
    <component 
      :class="getClass(icon)"
      :is="icon-${icon}"
    />
  </li>
</ul>

...

<script>
// import で各アイコンコンポーネントを呼び出し、 export 内で components に記述する

export default {
  methods: {
    getClass(iconName) {
      const path = this.$route.path
      if (iconName === path) {
        return 'is_selected'
      }
    }
  }
}
</script>

// style で is_selected に任意のスタイルを当てる

v-for のループ内で任意のイベントハンドラを指定する

Vue.js 2.6 からディレクティブの引数を動的に指定できるようになりました。

テンプレート構文 — Vue.js

要するに v-bind:●●="something" , v-on:●●="something()" の●●を動的に指定できるのですが、ユースケースとしてはあまり多くないのかなという印象です。

上記で挙げている例でいうと、ある条件下ではアイコンの click 時にイベントが発火し、別の条件下では mouseover でイベント発火するようなケースですね。サイドメニューのサブメニューの開閉を切り分けたいときなんかには使えそうな印象です。

他には下記のように、アイコンが示すページ内にいるときにはイベントハンドラを与えないという処理には使えそうです。

// template
<ul>
  <li
    v-for="(icon, index) in icons"
    :key="index"
    @[getEvent(icon)]="handleEvent()"
  >
    <component 
      :is="icon-${icon}"
    />
  </li>
</ul>

...

<script>
export default {
  methods: {
    getEvent(iconName) {
      const path = this.$route.path
      // 今開いているページのアイコンにクリックイベントを与えない
      if (iconName !== path) {
        return 'click'
      }
    },
    handleEvent() {
      console.log('何かを発火!!')
    }
  }
}
</script>

叩いたメソッドの handleEvent 内で分岐することが多いかもしれませんが、このように書くこともできそう、という所感です。

PHPStorm と VSCode のデフォルト設定では、イベント名 ( handleEvent() のところ) にシンタックスハイライトが効かないので、コードの読みやすさの面ではあまり良くないですね。

この用途ではコード量は減らないため、別のイベントハンドラを与えたいときに使う、が有用のようです。

動的引数の値の成約

ドキュメント内にもありますが、動的引数の指定にはいくつか制約があります。上記のケースで、 method で @[getEvent(icon)] のように指定せず直接記述したいと思いましたが、下記のような記述はできません。

@[ ] 内には演算子は書けないようです。

// 不正な記述
@[$route.path !== icon ? 'click' : '' ]="doSomething()"

例えば icon: {event: 'click'} のようなオブジェクトが渡ってきたときに、 icon.event で click を指定したいところですが、こちらも同様に記述できません。そのため上記のように method で与えてあげる必要があります。

// 不正な記述
@[icon.event]="doSomething()"

制約が多いため用途は限定的かもしれません。

動的引数の式には構文上の制約があります。というのも、スペースや引用符のような一部の文字は、HTML の属性名としては不正な文字だからです。また、in-DOM テンプレートを使う場合は、大文字のキーも避ける必要があります。 テンプレート構文 — Vue.js

さいごに

コンポーネントからクラス名、イベントハンドラまでを動的に配置してみましたが、イベントハンドラについては用途が限られる印象なので、開発の大きな助けになるイメージではなさそうでした。良い事例があれば教えていただけるとありがたいです。

最後に、弊社 ROXX では自社プロダクト一緒に成長させていくエンジニアを募集しています！

ご興味をお持ちの方はぜひご連絡ください！

www.wantedly.com

www.wantedly.com

理想の開発組織に沿った行動を表彰しました！

こんにちは kotamat です。

弊社の開発チームでは、理想の開発組織像というものを定義しております

techblog.scouter.co.jp

詳細は上記リンクを参考にしていただきたいですが、それを実現するために3つのバリューを設定しております。

  • ROCK
    • 個々のプレゼンスが組織のプレゼンスとなる
  • JAZZ
    • 自分史上最高のプルリクを出す
  • PROGRESSIVE
    • 好奇心を持って体系化する

弊社では3ヶ月に一回の評価を行っており、その評価において上記バリューを体現した人を選定し、表彰することにしました。

もともとはバリューの評価は給与に反映していたのですが、プロダクトが複数にまたがっていく中で、どういったバリューが評価されるのかが埋没化され、バリュー自体が形骸化されてしまうことを懸念しておりました。

他のメンバーにもわかる形で表彰することにより、他のメンバーも「こういうことをすれば評価されるのか」というのを認識できるようになるため、今Qからは表彰することになりました。

それでは早速ですが、受賞者を紹介させていただきます！

2019年第3Qの評価者はこの3名！

ROCK賞： @masaakikunsan

f:id:kotamat:20190807142218j:plain

SCOUTER Conference vol.01 - connpassを主体的に運用していたり、NuxtMeetup - connpassや外部勉強会への積極的な登壇、また他のプロダクトのフロントエンドの技術力底上げなど、多方面で存在感を発揮していたところが ROCK でした！

本人からのコメントです。

ROCK賞あざます！僕は僕らしく生きていただけですが、表彰されて嬉しいです！(イキり) 会社の今後と自分のやりたいことを上手く紐付けて今後もROCKしていきたいと思います！ イベント系に関してはメンバーの協力がないとできなかったのでこの場を借りて感謝の気持ちを伝えたいと思います、ありがとうございました！

JAZZ賞： @ktraoy

f:id:kotamat:20190807142752j:plain

システムの大改修のプランニングをするために、先日の開発合宿をしていたのですが、大改修でやることの物量が読めない中、臨機応変に合宿でのアウトプットを最大化するために動いていた点が JAZZ でした！

本人からのコメントです。

Jazz賞の表彰いただきありがとうございます。 前Qからスクラムマスターとしての役割に取り組み始めた所なので、このように評価をしていただけたのは、チームのおかげだと思ってます。 また合宿の活動の前後で共に進行役を担ったPOとスクラムマスターの協力のおかげでもあります。ありがとうございます。 まずは、プロジェクトがまだ完了していないので、プロジェクトの成功に取り組みます。その後も事業の成功のためにチームとPOをサポートしていけるように、自己研鑽を積んでいきたいと思ってます。

PROGRESSIVE： @tsmd44

f:id:kotamat:20190807143013j:plain

SARDINEのモノレポ化やk8sの提案など、今抱えている技術課題を新しい技術の導入によって解決に向かえている点が PROGRESSIVE でした！

本人からのコメントです。

この度、Progressive賞をいただき大変うれしく思います！ 業務委託にも関わらず、モノレポ化など通常の開発以外にも様々な業務を任せていただけているのは、POをはじめメンバーの理解とサポートのおかげです。 プロダクト的にも開発的にも技術で解決できる課題はまだまだあると感じており、開発スピードをさらに加速できるよう日々研鑽に励んでまいりたいと思います。 引き続きどうぞ宜しくお願いいたします！

最後に

f:id:kotamat:20190807143246j:plain

最後に表彰式に参加したメンバー全員で記念撮影。 次回は他の人も受賞できるよう、バリューの体現を期待しております！