普段Perlのテストはターミナル上で prove t/hoge.t で実行しています。 これを楽するために、VS Codeの拡張機能 Code Runner - Visual Studio Marketplace を使い、編集中のファイルを開いたまま、ボタン一つで実行できます。 拡張機能 Code Runner をインストールします settings.json を開いて以下の設定を追記します { " code-runner.executorMapByGlob ": { " *.t ": " prove " } , VS Codeウィンドウの右上に ▷ のボタンを押します 開いたテストファイルを実行する

miro アプリ 弊社は モバワーク を導入していて、チームメンバーも普段はフルリモートワークをしています。 チームでは オンラインホワイトボード として miro を導入していて、例えばこんな事に使ってます。 ボード上でタスクチケットの管理 残りタスクと進捗の可視化 タスクの見積もりと作業可能時間の集計と比較 特に最後はmiro SDKを使ったmiroアプリを開発して実現しています。 そんなmiroアプリを開発できるようにするまでの手順をご紹介します。 1 準備 下のリンクの手順に従って、dev teamとYour appsを作る https://developers.miro.com/docs/getting-started 2 app作成 パッケージがあるので使いましょう https://www.npmjs.com/package/create-miro-app $ yarn create miro-app my-miro-app $ cd my-miro-app $ yarn start 3 公開 ここではひとまずngrokで公開 $ brew install ngrok ngrokの アカウント登録 をして、 Your Authtoken からtokenをコピペ $ ngrok authtoken <取得したtoken> $ ngrok http https://localhost:3001 # yarn startしたときに動いてるポート Forwardingに出てるアドレスをコピペ(必ずhttpsの方) 4 app URL登録 1 準備 でmiroに登録したappに、 3 公開 でコピペしたアドレスをappに登録 dev teamのボードを開いて、tool barを見たときにappが追加されていて動けばok 自分たちのチームでは、タスクカードを選択するだけでそれらの見積もり時間を集計するアプリとして開発して使ってます。 その後 miro SDKはオブジェクトの読み取り、配置、変更、オブジェクトが更新されたらxxxをする、みたいなことが出来るのでかなり自由度が高いです。 また、miro appは単なる静的ページなので開発し終わったらgithub pagesなどで公開するのも可能です。

CLIツールのパフォーマンス気になりますね 皆さん普段様々なCLIツールをご利用かとは思いますが、そのCLIツールのパフォーマンスが気になったことはありませんか？私はまれによくあります。今回はそういうときに役に立つ hyperfine をご紹介です。 github.com 基本的な使い方は以下のとおりです。 $ hyperfine ' ここに測定したいコマンドを書く ' sleep 0.3 を測定すると以下のような出力が得られます。 $ hyperfine ' sleep 0.3 ' Benchmark 1: sleep 0 . 3 Time ( mean ± σ ) : 308 . 9 ms ± 8 . 2 ms [ User: 0 . 7 ms, System: 1 . 6 ms ] Range ( min … max ) : 302 . 9 ms … 322 . 7 ms 10 runs 他にもキャッシュを捨てるようなコマンドを事前に実行させたり、ウォーミングアップを指定回数行えたりもできます。詳しくはREADMEを読んでみてくださいね。

ここ半年、競プロをこつこつ頑張っているエンジニアの id:dorapon2000 です。好きなアルゴリズムは累積和です。 解決したい課題 「MySQL 5.7 内で完結できるように、クエリだけでランキングを取得したい」 データベースのデータを使って調査をする際、ランキングを出したいこと、あるいはランキングを基にした処理をしたいことがあります 1 。アプリケーション側で集計・ソートして値を取得することもできますが、1回限りの調査の場合、わざわざコードを書くことが億劫です。 MySQL 8.0ではRANK関数が導入されたため、そちらで簡単にランキングを取得できます（記事末尾に参考で記載）。今回は、RANK関数導入以前のMySQL 5.7 で、クエリから一発でランキングを取得することを目指します。 検証環境 MySQL 5.7.36 scoreというテーブルを作成し、1万レコードのscore（0〜9999のランダム）をインサートしました。このscoreの降順のランキングを取得することを目指します。 mysql> desc score; + ---------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | + ---------+---------+------+-----+---------+----------------+ | user_id | int ( 11 ) | NO | PRI | NULL | auto_increment | | score | int ( 11 ) | NO | | NULL | | + ---------+---------+------+-----+---------+----------------+ 2 rows in set ( 0 . 00 sec) mysql> show create table score\G; *************************** 1 . row *************************** Table : score Create Table : CREATE TABLE `score` ( `user_id` int ( 11 ) NOT NULL AUTO_INCREMENT, `score` int ( 11 ) NOT NULL , PRIMARY KEY (`user_id`) ) ENGINE=InnoDB AUTO_INCREMENT= 16394 DEFAULT CHARSET=utf8 COMMENT = ' score ' 1 row in set ( 0 . 00 sec) mysql> select count (*) from score; + ----------+ | count (*) | + ----------+ | 10000 | + ----------+ 1 row in set ( 0 . 01 sec) 方法① SQL標準 MySQLに限らずどのDBでも実行できる、SQL標準でのランキング取得方法です。 SELECT s1.score, s1.user_id, ( SELECT COUNT (s2.score) FROM score AS s2 WHERE s1.score < s2.score) + 1 AS r FROM score AS s1 ORDER BY r LIMIT 10 ; そこまで複雑なクエリではないですが、ポイントはサブクエリの外と内で別々に2つのscoreを呼び出していることです。外側の score AS s1 で選ばれたs1.scoreが score AS s2 の中でどの順位にいるのかをWHERE句で判定します。scoreを使った2重のfor文と考えるとイメージしやすいかもしれません。正確ではないかもしれませんが、時間計算量はO(N 2 )だと考えられます。 実行結果は以下のようになります。 mysql> select s1.score, s1.user_id, (select count (s2.score) from score as s2 where s1.score < s2.score) + 1 as r from score as s1 order by r limit 10 ; + -------+---------+------+ | score | user_id | r | + -------+---------+------+ | 9999 | 2080 | 1 | | 9999 | 9919 | 1 | | 9999 | 9507 | 1 | | 9997 | 6792 | 4 | | 9997 | 7412 | 4 | | 9995 | 532 | 6 | | 9993 | 5835 | 7 | | 9990 | 8757 | 8 | | 9990 | 8890 | 8 | | 9988 | 2596 | 10 | + -------+---------+------+ 10 rows in set ( 17 . 23 sec) mysql> explain select s1.score, s1.user_id, (select count (s2.score) from score as s2 where s1.score < s2.score) + 1 as r from score as s1 order by r limit 10 \G; *************************** 1 . row *************************** id: 1 select_type: PRIMARY table : s1 partitions: NULL type : ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows : 10000 filtered: 100 . 00 Extra: Using temporary; Using filesort *************************** 2 . row *************************** id: 2 select_type: DEPENDENT SUBQUERY table : s2 partitions: NULL type : ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows : 10000 filtered: 33 . 33 Extra: Using where 2 rows in set , 2 warnings ( 0 . 00 sec) 時間計算量が大きいため、たった1万レコードの集計でもかなり時間がかかってしまうことが難点です。 同スコアの場合は同順位になります。 方法② ユーザー定義変数 SET @r = 0 ; SELECT score, user_id, @r:=@r+ 1 FROM score ORDER BY score DESC LIMIT 10 ; MySQLでは、そのセッションでのみ有効な ユーザー定義変数 というものをクエリの中で使うことができます。ここに順位を一時格納することで、ランキングを実現します。時間計算量はO(N)です。 実行結果は以下のようになります。 mysql> set @r = 0 ; Query OK, 0 rows affected ( 0 . 00 sec) mysql> select score, user_id, @r:=@r+ 1 from score order by score desc limit 10 ; + -------+---------+----------+ | score | user_id | @r:=@r+ 1 | + -------+---------+----------+ | 9999 | 9507 | 1 | | 9999 | 2080 | 2 | | 9999 | 9919 | 3 | | 9997 | 7412 | 4 | | 9997 | 6792 | 5 | | 9995 | 532 | 6 | | 9993 | 5835 | 7 | | 9990 | 8890 | 8 | | 9990 | 8757 | 9 | | 9988 | 2596 | 10 | + -------+---------+----------+ 10 rows in set ( 0 . 01 sec) mysql> explain select score, user_id, @r:=@r+ 1 from score order by score desc limit 10 \G; *************************** 1 . row *************************** id: 1 select_type: SIMPLE table : score partitions: NULL type : ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows : 10000 filtered: 100 . 00 Extra: Using filesort 1 row in set , 1 warning ( 0 . 00 sec) 同じscoreの場合、同順位にならない点が意図しないかもしれませんが、時間計算量が小さいため爆速で集計が終わります。 （参考）MySQL 8.0の場合 MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.21.1 Window 関数の説明 mysql> select score, user_id, rank () over w as ' rank ' from score window w as ( order by score desc ) limit 10 ; + -------+---------+------+ | score | user_id | rank | + -------+---------+------+ | 9995 | 5081 | 1 | | 9994 | 3665 | 2 | | 9994 | 7494 | 2 | | 9993 | 558 | 4 | | 9993 | 6981 | 4 | | 9992 | 3584 | 6 | | 9992 | 8848 | 6 | | 9990 | 9185 | 8 | | 9989 | 525 | 9 | | 9989 | 4740 | 9 | + -------+---------+------+ 10 rows in set ( 0 . 00 sec) Redisのsorted setなどランキングに適したデータストアを使う方がより良いと思いますが ↩

こんにちは、新卒エンジニアの id:d-kimuson です 先日 type-predicates-generator という型定義からユーザー定義型ガード・アサーション関数を自動生成するツールをリリースして 紹介記事 を書いたのですが、感想とかを眺めていたら同じく外部から来た値に安全な型付けをするためのライブラリやツールの情報をいくつも観測しました この辺りのランタイムチェックライブラリの情報ってあまりまとまっていない印象で自分が知らないものもいくつかあったので、調べつつ簡単にまとめられたらなと思ってこのエントリを書きました 外部からやってきた値を型安全にするにはざっくりと 型生成によるアプローチ ランタイムチェック用の独自型を書かせるアプローチ 型情報からランタイムチェック関数を自動生成するアプローチ の 3 つのアプローチがあると思うので、それぞれのアプローチごとに紹介します ① 型定義の生成によるアプローチ 外部から値がやってくる主たるケースは API 通信で、GraphQL や OpenAPI のスキーマから型定義を自動生成することで型安全性を守るアプローチです スキーマと生成ツールの実装が正しいという前提の元ですが、外部からやってくる値に正しさを一定担保した上で型をつけることができます GraphQL Code Generator GitHub - dotansimha/graphql-code-generator: A tool for generating code based on a GraphQL schema and GraphQL operations (query/mutation/subscription), with flexible support for custom plugins. GraphQL のスキーマから型定義を自動生成するツールです 自分は Gatsby で個人の技術ブログを書いていて、そこで使用してます 公式サイト に例が載っているので、見てみるとイメージしやすいと思います openapi-generator GitHub - OpenAPITools/openapi-generator: OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3) OpenAPI スキーマから型安全に API を呼べる API クライアントを自動生成してくれるツールです // openapi-generator + axios のサンプルコード import axios from "axios" import { PetApiFactory , Configuration , PetStatusEnum } from "./typescript-axios" // 自動生成されたコード const api = axios.create ( { /* config here */ } ) const config = new Configuration ( { /* config here */ } ) export const endpoints = PetApiFactory ( config , `baseURL` , api ) // APIコール endpoints .getPetById ( 0 /* 引数に型が付く */ ) .then (( response ) => { response.data /* Pet に型が付く */ } ) aspida + openapi2aspida GitHub - aspida/aspida: TypeScript friendly HTTP client wrapper for the browser and node.js. aspida という型安全に API コールを行うためのライブラリがあり、 openapi2aspida を使うことでスキーマから aspida のクライアントを自動生成してくれます // aspida のサンプルコード import axios from "axios" import aspida from "@aspida/axios" import api from "./api/$api" // 自動生成されたコード const client = api ( aspida ( axios )) // API コール client.pet ._petId ( 0 /* 引数に型が付く */ ) . get() .then (( response ) => { response.body /* Pet に型が付く */ } ) openapi-generator は TS に限らず様々な言語のクライアントを生成しますが、openapi2aspida は TypeScript 専用でより使いやすい印象です 自分は API を叩くときは aspida を使うことが多いです この辺りのツールは型安全性の担保ももちろんですが、すでに存在するスキーマと同じ型を手動で書かなくて良い点も嬉しいポイントですね ② TS の型ではなくランタイムチェックを行える独自の型宣言を行うアプローチ TypeScript では型定義からランタイムのコードを生成することはできません なので型定義とは別にランタイムチェック用の型を書いてそれでチェックしようというアプローチです ランタイムチェック用の型はライブラリが指定する独自の書き方で宣言する必要があるので、重複管理になりそうに思うかもしれませんが、値から TS の型を取り出すのは難しくないので、ランタイムチェック用の型から TypeScript の型を拾えるようになっています io-ts GitHub - gcanti/io-ts: Runtime type system for IO decoding/encoding 言わずとしれたランタイム型チェックのライブラリの王道です io-ts の指定する形で型定義を書いてランタイムチェックを行えます // io-ts のサンプルコード import * as t from 'io-ts' import { isRight } from 'fp-ts/lib/Either' const UserRuntimeType = t. type( { id: t. number , name: t. string , union: t.union ( [ t. string , t. number ] ), optional: t.union ( [ t. string , t. undefined ] ), nullable: t.union ( [ t. string , t. null ] ), } ) type User /* : { id: number; name: string; union: string | number; nullable: string | null; optional?: string | undefined; } */ = t.TypeOf <typeof UserRuntimeType > const maybeUser: unknown = 'invalid' const user = UserRuntimeType.decode ( maybeUser ) if ( isRight ( user )) { // ランタイムバリデーションが成功したときだけこのブロックを通る user.right /* : User に型が付く */ } isRight とかに関数型っぽさが見え隠れしますね runtypes GitHub - pelotom/runtypes: Runtime validation for static types io-ts と同様に独自の構文でランタイムチェックの型を宣言してチェックします io-ts は fp-ts に依存していて書き方も関数型チックになるので、関数型に寄るのを好まないケースで使われる印象です // runtypes のサンプルコード import { Number , String , Undefined , Null , Record , Union , Static , } from 'runtypes' const UserRuntimeType = Record ( { id: Number , name: String , union: Union ( String , Number ), optional: Union ( String , Undefined ), nullable: Union ( Null , Undefined ), } ) type User = Static <typeof UserRuntimeType > const maybeUser: unknown = 'invalid' const user = UserRuntimeType.check ( maybeUser ) // おかしかったら error を投げる user /* User に型が付く */ io-ts は decode 時に型ガードを行いますが、runtypes ではバリデーションして値がおかしかったら例外を投げるという形のようです superstruct GitHub - ianstormtaylor/superstruct: A simple and composable way to validate data in JavaScript (and TypeScript). これは自分が知らなかったライブラリなのですが、結構人気のあるライブラリらしくスターも 5600 ついていました Introduction - Superstruct ドキュメントもかなり充実していました // superstruct のサンプルコード import { object , number , string , Infer , assert , union , optional , nullable , is , } from 'superstruct' const UserRuntimeType = object ( { id: number (), name: string (), union: union ( [ string (), number () ] ), optional: optional ( string ()), nullable: nullable ( string ()), } ) type User = Infer <typeof UserType > const maybeUser: unknown = 'invalid' if ( is ( maybeUser , UserRuntimeType )) { maybeUser /* User に型が付く */ } assert ( maybeUser , UserRuntimeType ) // バリデーションに失敗したら例外が発生 maybeUser /* User に型が付く */ 型の絞り込みはアサーションと型ガード両方に対応しているようです Utilities - Superstruct Utility types に対応する omit, partial, pick も使えるらしく表現力がかなり豊かそうで好感触でした ランタイムチェックはしたいけど io-ts は合わないって方にはファーストチョイスになりそうです zod GitHub - colinhacks/zod: TypeScript-first schema validation with static type inference 上の2つと同様の Zod が提供するデータ型でスキーマを宣言して、ランタイムチェックを行います // zod のサンプルコード import { z } from "zod" const UserRuntimeType = z. object ( { id: z. number (), name: z. string (), union: z.union ( [ z. string (), z. number () ] ), optional: z.union ( [ z. string (), z. undefined () ] ), nullable: z.union ( [ z. null (), z. string () ] ), } ) type User = z.infer <typeof UserRuntimeType > const maybeUser: unknown = "invalid" const user = UserRuntimeType.parse ( maybeUser ) // 失敗したら例外を投げる user /* User に型が付く */ const result = UserRuntimeType.safeParse ( "invalid" ) if ( result.success ) { maybeUser as User // 型ガードは非対応 (unknown のまま) だがバリデーションはできるので、型キャストは安全 } 型ガードには対応してないようですがバリデーション自体はできるので型キャストは一応安全です また今回の値の型が TypeScript の型通りかをランタイムチェックするという趣旨とは若干ズレるので詳しくは触れませんが、 ajv , yup , joi 等のバリデーションライブラリを使う手段もあります ③ 型定義からランタイムチェックの関数を自動生成するアプローチ ② のアプローチでは TS の型を一時の型にしたい状況にはあまり適しません 使うことができないわけではありませんが、型情報が二重管理になってしまいます 具体的には ① のアプローチで TypeScript の型を自動生成しているケース 学習コスト等の問題で TypeScript の型で定義したいケース 等です 実行時に TS の型から値を作ることはできませんが、事前に型情報からコード生成をすることなら可能なのでコード生成によって対応しようというアプローチです ts-auto-guard GitHub - rhys-vdw/ts-auto-guard: Generate type guard functions from TypeScript interfaces cli が提供されていて $ ts-auto-guard ./path/to/type.ts すると、 type.guard.ts に型ガード関数が生成されてインポートして使うことができるようです // ts-auto-guard のサンプルコード import { isUser } from './type.guard' const maybeUser: unknown = 'invalid' if ( isUser ) { maybeUser /* : User */ } type-predicates-generator GitHub - d-kimuson/type-predicates-generator: generating predicates and assertion function by type definitions. 今回僕が作ったツールです、詳細は 紹介記事 を書いたばかりなのでそちらに譲りますが watch を立てておき、型定義の変更にリアルタイムに追従してランタイムチェック関数を自動生成することができます $ type-predicates-generator -f 'types/**/*/ts' -o predicates.ts -a -w // type-predicates-generator のサンプルコード import { isUser , assertIsUser } from '/path/to/predicates' const maybeUser: unknown = 'invalid' if ( isUser ) { maybeUser /* : User */ } assertIsUser ( maybeUser ) maybeUser /* : User */ typescript-is GitHub - woutervh-/typescript-is typescript-is は少し特殊で ttypescript という TypeScript にデフォルト以外の transform 処理を挟むツールとセットで使うことで、ビルド時にランタイムチェック関数を生成することができます // typescript-is のサンプルコード import { is } from 'typescript-is' type User = { id: number name: string } const maybeUser: unknown = 'invalid' if ( is < User >( maybeUser )) { maybeUser } 本来は is<User>() のような形で User 型に合わせたようなチェック関数を作ることはできませんが、カスタムトランスフォーマーで前の 2 つと同じようなコード生成をビルド時に行うことでトランスパイル後のファイルにランタイムチェックを書き出すことができます 上の if 文は以下のようにトランスパイルされます if ( (0, typescript_is_1.is)(maybeUser, object => { function _number(object) { if ( typeof object !== 'number' ) return {} else return null } function _string(object) { if ( typeof object !== 'string' ) return {} else return null } function _0(object) { if ( typeof object !== 'object' || object === null || Array .isArray(object) ) return {} { if ( 'id' in object) { var error = _number(object [ 'id' ] ) if (error) return error } else return {} } { if ( 'name' in object) { var error = _string(object [ 'name' ] ) if (error) return error } else return {} } return null } return _0(object) } ) ) { maybeUser } 標準ではない ttsc でビルドする必要があること 同じ型に対するチェックも毎回長々と書き出すのでバンドルサイズが増えがち ランタイムチェックの実装がアップデート等で変わったときにソースコードじゃないので気づけない といった成約はあると思いますが、直感的かつ手軽に値の型を守ることができます おまけ: as-safely プリミティブ等の型を気軽にチェックするには、 as-safely というライブラリが手軽です。isString 等のランタイムチェック関数が提供されています import { asSafely , isString } from 'as-safely' const maybeStr: unknown = 'valid' asSafely ( maybeStr , isString ) // チェックに失敗したら例外を投げる maybeStr /* string に型がつく */ カスタムのランタイムチェック関数も使用できるので、② や ③ のライブラリ/ツールと組み合わせてアサーションを手軽に行うこともできます 例えば ts-auto-guard はアサーション関数の自動生成を提供しないようですが、asSafely とセットで使うと手軽にアサーションも行うことができます import { asSafely } from 'as-safely' import { isUser } from './type.guard' const maybeUser: unknown = 'invalid' asSafely ( maybeUser , isUser ) maybeUser /* : User に型が付く */ まとめ 外部からやってきた値に安全に型をつける方法について3つのアプローチに分けて紹介しました！ io-ts が一番有名だと思いますが、これに限らず複数の選択肢があるのでプロジェクトにあった形で型を守れると良いのではないでしょうか 個人的には ちゃんとしたスキーマがある箇所 → ① + ③ のあわせ技 それ以外 → ② 関数型っぽさが入っても問題ない → io-ts もっと普通のが良い → superstruct 辺りになりそうかなという印象でした それでは良い型安全ライフを！

はじめに はじめましての方ははじめまして、ブロックチェーンチームの id:Nanamachi です。夏頃まではエンジニアとして関わっていましたが、故あって現在はプロダクトマネージャとしての道を進んでいます。今日はそんな新米プロダクトマネージャが、膨れ上がるプロダクトバックログ、特にその中で発生するチケットの依存関係を可視化するために、ホワイトボードツールであるmiroを導入した話を書いていきます。 抱えていた問題 現在弊社では、 backlog をタスク管理ツールとして用いています。カスタム項目が使えることやガントチャートが自動的に引けることなどは便利なのですが、タスク間の依存関係が見えにくい問題を抱えていました。 一見ふつうのプロダクトバックログ 例えば上のバックログ。1191のチケットは1137の調査タスクであるため、先に1191を終わらせる必要があります。また、998、999の修正を結合するのが1000であるため、998、999の両方が終わらないと1000に取りかかれません。しかし、この関係性はbacklogだけで直感的に表現できない……そのために、本来先に進めていなければいけないものが終わっていないなど、計画どおりに進行できないことがありました。 実際はこの順番で実装しなければいけない! この問題をホワイトボードアプリケーションのmiroを使って解決していきます。 miroについて詳しく知りたい方は下記の記事などがわかりやすいかと思いますので良ければご覧ください。 jaco.udcp.info プロダクトバックログをmiroで可視化する miro上で整理されたチケットの例 チケットの依存関係と優先順位を可視化するために欲しいものはチケット名、マイルストーン、進行状況、ストーリーポイントなどです。これを空き時間で書いたスクリプトで転記できるようにしました。あとはこれを元にmiro上でチケット間に矢印を引いていきます。 実際に使い始めると、当初の目論見であったチケットの依存関係や優先順位が整理されるのはもちろんですが、それ以上に恩恵がありました。例えば機能ごとのグループやロードマップの管理などプロダクト戦略に関すること、また現在のマイルストーンの進捗状況など、プロダクト・プロジェクトに関する様々なことをひと目で認識できるようになりました。チームが転ばないようにするための見通しを立てやすくなり、非常に便利です。 おわりに チケットをmiroで可視化することでチームの状態が整理されました。チームメンバーがスプリントプランニングをする際にも役に立つため、ぜひやってみてはいかがでしょうか。

はじめに offsetWidth や offsetHeight などの幅や高さを取得する関数たちは、 display: none になっている場合、0を返します。 Vue.jsで要素の表示非表示に v-show を用いている場合、 v-show はその要素に display: none を付与して制御を行うので、非表示中の offsetWidth は0として返ってくることになります。 < template > < div > < p v-show= "false" > ここのoffsetWidthは0pxです！ </ p > </ div > </ template > ハマりやすいポイント offsetWidth などは、自分の要素だけでなく、親要素に display: none が付与されていても0を返します。 注意したいのは、親コンポーネントで v-show を用いている(コンポーネントの表示制御を行っているなど)場合です。 Parent.vue < template > < div > < div v-show= "flag" > < Child /> </ div > </ div > </ template > < script > import Child from "./Child" ; export default { name: "Parent" , components: { Child, } , data () { return { flag: false , } ; } , mounted () { setTimeout (() => { this .flag = true ; } , 1000) ; // 描画されて1秒後にtrueになる } , } ; </ script > Child.vue < template > < p ref= "target" > hello, world! </ p > </ template > < script > export default { name: "Child" , mounted () { console.log ( `pタグのoffsetWidthは ${ this .$refs.target.offsetWidth} px です！` ) ; // pタグのoffsetWidthは 0px です！ } , } ; </ script > この場合、 v-show では表示非表示に関わらず描画が行われ、その後 display: none で制御を行います。そのため子コンポーネントの mounted のタイミングでは v-show が false なので、結果は0pxになってしまいます。 2つの解決方法 offsetWidth を取得できるようにする方法を2種類紹介します。 フラグを受け取り v-show が true になった直後に取得する 親で用いているフラグを受け取って watch することで、 true になった瞬間に offsetWidth を取得します。 mounted のタイミングでは取得できませんが、 watch と組み合わせれば任意のタイミングで利用できるようになります。 Parent.vue < template > < div > < div v-show= "flag" > < Child :flag= "flag" /> <!-- flagを子コンポーネントに渡す --> </ div > </ div > </ template > < script > // 省略 </ script > Child.vue < template > < p ref= "target" > hello, world! </ p > </ template > < script > export default { name: "Child" , props: { flag: Boolean , } , watch: { flag ( newFlag ) { if ( newFlag ) { console.log ( `pタグのoffsetWidthは ${ this .$refs.target.offsetWidth} px です！` ) ; // 取得できた！ } } , } , } ; </ script > v-if に変えて遅延描画にする 切り替えコストが上がってしまいますが、 v-if の遅延描画を活用することで、 mounted フックで取得できるようになります。 Parent.vue < template > < div > < div v-if= "flag" > <!-- v-ifに変更する --> < Child /> </ div > </ div > </ template > < script > // 省略 </ script > Child.vue < template > < p ref= "target" > hello, world! </ p > </ template > < script > export default { name: "Child" , mounted () { console.log ( `pタグのoffsetWidthは ${ this .$refs.target.offsetWidth} px です！` ) ; // 取得できた！ } , } ; </ script > まとめ offsetWidth が取得できない場合の解説と解決方法の紹介でした。親コンポーネントを探しに行かないといけない点は盲点だったので、同じ問題にハマらないように気をつけたいですね！

チーム開発で、指標をうまく使えると便利ですが、この「うまく使う」というのはなかなか難しく、罠はあると思っています。 今回は、この罠を、信号機に例えて、説明してみたいと思います。他にも、罠があればぜひ教えてください！ 壊れた信号 壊れた信号 データが壊れていて、信用できない そのまま放置されている 信号無視 信号無視 人によって、良し悪しの判断基準が異なる 基準を用意しても無視をする 信号だらけ 信号だらけ 指標がありすぎて、どこを見れば良いかわからない 分かる人にしか分からない状態 工事のいる信号 工事のいる信号 信号を見るのに、工事業者に依頼をしなければならない つまり、データを見るのに手間がかかる さいごに ここでは行動を妨げる罠を紹介しました。 裏を返せば、良い行動を引き出す信号、作っていきたいですね・・！！現場からは以上です。

こんにちは、新卒エンジニアの id:kaoru-k_0106 です 何をしたか 私のチームでは、コミットメッセージの先頭にチケット番号を入れるルールがあります。 例えば、 PROJECTNAME-123 〇〇の処理を変更した だと、 PROJECTNAME-123 の部分がチケット番号です。 最初はこれを手動で入力していたのですが、時々入力を忘れることがあり自動挿入しようと思いました。 ちょうど、トピックブランチ名がチケット番号だったので、ブランチ名を使う方針で実装をしました。 導入手順 その1 Gitのコミットテンプレートを設定する Gitのコミットテンプレートとは、コミットメッセージエディタを開いたときにデフォルトで設定されている文字列です。 この設定は、次のようにテンプレートファイルを作成し、 git config で設定できます。 % echo ' [branch-name] ' > ~/.commit_template % git config commit.template ~/.commit_template その2 Git Hooksでコミットテンプレートをブランチ名に置き換える 次に、このコミットテンプレート内の [branch-name] をブランチ名に置き換えるためにGit Hooksを使用します。 具体的には、 .git/hooks/prepare-commit-msg を実行権限をつけて置きます。 #!/bin/sh current_branch = $( git rev-parse --abbrev-ref HEAD ) sed -i " s/ \[ branch-name \] / $current_branch / " $1 # Macだと以下のようにする # sed -i "" "s/\[branch-name\]/$current_branch/" $1 これで、ブランチ名が自動で挿入されるようになりました。 実際に挿入されるか確かめてみます。 動作確認 git commit を叩くと、 [branch-name] がブランチに置き換わった状態でコミットメッセージエディタが開きます。 ちなみに、Visual Studio Code (VSCode)のソース管理機能でコミットした場合もブランチ名に置き換わります。 入力欄ではテンプレートの [branch-name] がそのまま表示されていますが、コミットするとブランチ名に置き換わります。 おわりに これだけでコミット時にブランチ名を自動挿入することができました。 ミスを減らすことができ、チームの開発効率にも貢献できると思います！

はてなさんのコンテキストクイズに拙作の Contextual-Diag で答えてみました。これでコンテキストマスターですね！？ github.com use Test2::V0; use CDD; like( warnings { length ( cdd ) }, [ qr/wanted SCALAR context/ , qr/evaluated as STR/ ], 'length <ここ> ... STR in SCALAR' ); like( warnings { if ( cdd ) {} }, [ qr/wanted SCALAR context/ , qr/evaluated as BOOL/ ], 'if (<ここ>) ... BOOL in SCALAR' ); like( warnings { for my $i ( cdd ) {} }, [ qr/wanted LIST context/ ], 'for my $i (<ここ>) ... LIST' ); like( warnings { package Hoge { sub new { bless {}, $_[ 0 ] } sub hello {} } my $obj = Hoge->new; $obj->hello ( cdd ) }, [ qr/wanted LIST context/ ], '$obj->method(<ここ>) ... LIST' ); like( warnings { my $x = cdd }, [ qr/wanted SCALAR context/ ], 'my $x = <ここ> ... SCALAR' ); like( warnings { my ( $x ) = cdd }, [ qr/wanted LIST context/ ], 'my ($x) = <ここ> ... LIST' ); like( warnings { my @y = cdd }, [ qr/wanted LIST context/ ], 'my @y = <ここ> ... LIST' ); like( warnings { my %hash = ( key0 => 'hoge' , key1 => cdd, ) }, [ qr/wanted LIST context/ ], q!my %hash = ( key0 => 'hoge', key1 => <ここ> ); ... LIST! ); like( warnings { scalar ( cdd ) }, [ qr/wanted SCALAR context/ ], 'scalar(<ここ>) ... SCALAR' ); like( warnings { cdd }, [ qr/wanted VOID context/ ], '<ここ>; ... VOID' ); # 注: sortの幾通りかの使い方を知っている前提で、テストしている subtest 'sort <ここ>' => sub { # sort BLOCK LIST like( warnings { my @a = sort { cdd } ( 'a' , 'b' ) }, [ qr/wanted SCALAR context/ ], 'sort <ここ> / CASE: sort BLOCK LIST ... BLOCK context is SCALAR' ); # sort SUBNAME LIST like( warnings { my @a = sort cdd ( 'a' , 'b' ) }, [ qr/wanted SCALAR context/ ], 'sort <ここ> / CASE: sort SUBNAME LIST ... SUBNAME context is SCALAR' ); # sort LIST like( warnings { my @a = sort (cdd( 'a' , 'b' )) }, [ qr/wanted LIST context/ ], 'sort <ここ> / CASE: sort LIST ... LIST' ); }; done_testing;

TSの型迷宮に迷い込んだエンジニアの id:dorapon2000 です。 ディレクトリのパーミッションを調べるとき、皆さんどうしていますか。例えば /etc のパーミッションを確認したいとき、以前の僕はこうです。 ❯ ls -l / total 104 drwxr-xr-x 2 root root 4096 6 月 28 18:34 bin drwxr-xr-x 3 root root 4096 6 月 28 18:35 boot drwxr-xr-x 15 root root 3640 11 月 16 10:02 dev drwxr-xr-x 128 root root 12288 11 月 2 10:55 etc drwxr-xr-x 4 root root 4096 4 月 6 2021 home drwxr-xr-x 22 root root 4096 6 月 15 2020 lib drwxr-xr-x 2 root root 4096 6 月 28 18:33 lib64 drwx------ 2 root root 16384 4 月 7 2020 lost+found drwxr-xr-x 2 root root 4096 4 月 7 2020 media drwxr-xr-x 2 root root 4096 4 月 7 2020 mnt drwxr-xr-x 4 root root 4096 6 月 1 16:33 opt dr-xr-xr-x 173 root root 0 11 月 16 10:02 proc drwx------ 9 root root 4096 10 月 6 19:26 root drwxr-xr-x 30 root root 1120 11 月 16 10:03 run drwxr-xr-x 2 root root 12288 6 月 28 18:34 sbin drwxr-xr-x 6 root root 4096 3 月 9 2021 snap drwxr-xr-x 2 root root 4096 4 月 7 2020 srv dr-xr-xr-x 13 root root 0 11 月 16 10:24 sys drwxrwxrwt 10 root root 12288 11 月 16 10:25 tmp drwxr-xr-x 11 root root 4096 6 月 1 16:33 usr drwxr-xr-x 14 root root 4096 3 月 11 2021 var うっ、数が多くてため息が出てしまいます... -d オプションを使うと次のようになります。 ❯ ls -ld /etc drwxr-xr-x 128 root root 12288 11 月 2 10:55 /etc もっと早く知りたかった...

　次のコードの通り、 DBIx::Sunny を利用した際、 $dbh->select_one を呼び出せるにも関わらず、 $dbh->can('select_one') が false となります。 　 can の挙動が、デフォルトと異なり、一見すると困惑します。 use Test2::V0; use DBIx::Sunny; use Types::Standard qw(HasMethods) ; my $dsn = "dbi:SQLite:dbname=test.db" ; my $dbh = DBIx::Sunny-> connect ( $dsn , 'root' , '' ); ok ! $dbh->can ( 'select_one' ), '不思議な挙動' ; ok $dbh->select_one ( 'SELECT 1' ); ok $dbh->UNIVERSAL ::can( 'select_one' ); done_testing; 　これは、DBIが can を上書きし、Driverで実装されているか、あるいはDBIでデフォルトで提供されているメソッドかどうか判定するためです。デフォルトの挙動で動かしたいのであれば、 UNIVERSAL::can で確かめられます。 metacpan.org

VSCode でホバーして型情報を見ようとすると、交差型はプロパティが展開されません プロパティの型を展開する Mapped Types を通すことで省略せずにプロパティを見ることができます。プロパティが交差型になっていることもあるので、再帰的にプロパティを Mapped Types に通すような型を定義しておいて、通すことでプロパティを全て確認できます type Expand < T > = T extends object ? T extends infer O ? { [ K in keyof O ] : Expand < O [ K ] > } : never : T type Temp = Expand < `確認したい型` > 厳密でなくとも簡単にどんなプロパティがあるか把握したいだけなら組み込みの Required や Partial を使うのが手軽です。ただし、あくまでデバッグ用途でそれぞれ省略可能プロパティになる/でなくなるので注意が必要です プロパティが多い時に省略しない これで展開した型が見られるようになりましたが、展開した型を表示するとプロパティの数が多い時に省略されてしまいます noErrorTruncation オプションを有効にすることでプロパティ数が多いときでも全ての型情報を確認できます // tsconfig.json { compilerOptions: { + "noErrorTruncation": true, } } 拡張機能で確認する 一度型変数に置くのがめんどくさければ、展開された型を表示できる VSCode 拡張機能を作ったので、これを使うことで手軽に確認することができます ts-type-expand - Visual Studio Marketplace からインストールできます 画像のように、VSCode の UI 上から展開されたプロパティを確認することができます

こんにちは。ブロックチェーンチームのソフトウェアエンジニアの id:odan3240 です。 ブロックチェーンチームでは NFT を販売するための Uniqysマーケットプレイス (以下、ユニマ)と、その NFT を販売するための管理画面(以下、管理画面)を開発しています。ユニマはブロックチェーン上の NFT を日本円で売買可能なマーケットプレイスです。 ユニマの開発はブロックチェーンに関するサービスなので、ブロックチェーンに関する技術をゴリゴリに使って開発しているのでは？と考える方がいるかもしれません。しかし実際はそうではなく Web アプリケーションに関する開発は普通の技術スタックで開発しています。もちろん実装するロジックによってはブロックチェーンに関する知識が必要となる場合もありますが、マネージドサービスやフレームワークやツールを活用してコア機能の実装に集中できるように技術スタックを選択しています。 この記事ではユニマと管理画面の主に Web アプリケーションに関する技術スタックと、その採用理由について紹介します。 技術スタック TypeScript ユニマと管理画面のフロントエンドとバックエンドの全てで TypeScript を使用しています。モバファクはプロダクトのバックエンドには Perl が採用されることが多い企業でしたが、開発の効率化のために静的な型がほしいのと文法が JavaScript とかなり近くメンバーの学習コストも低いという点から、2018年に立ち上がったブロックチェーンチームでは立ち上げ当初から各プロダクトに TypeScript が採用されることが多いです。 ユニマと管理画面もこの流れをくんで TypeScript を採用しました。 NuxtJS ユニマと管理画面のフロントエンドの実装に NuxtJS を使用しています。Vue.js は他のチームでの採用実績があり社内のノウハウやリソースを流用できそうな点と、プロダクトの立ち上げ当初はエンジニアに比べるとデザイナのリソースが浮くことがたまにあり、いざとなればデザイナもフロントエンドの実装に参加できるように書き方が HTML/CSS に近い点が採用理由です。 TypeScript との相性を少しでもよくするために Vue.extend を使用してコンポーネントを定義して、VSCode の拡張機能に Vetur を使用しています。Vue.js は TypeScript と相性が悪いと言われますが拡張機能に Volar を利用することで、SFC の template の型推論やコンポーネントの props の指定の有無を静的にチェックしてくれます。また、Vue.js の v2 でも Composition API の defineComponent を使用すれば v3 と同様の開発体験を得ることができそうで、Vetur からの置き換えを検討中です。 ユニマは SNS からの流入が想定されているのでOGP のために NuxtJS を使って Lambda で SSR しています。 一方で、管理画面はどの画面もログインして使用するページであり、SNS からの流入も想定されていないため、SPA として S3 に静的ファイルをホスティングしています。SPA でもユニマとの開発体験を揃える、ビルド周りのシステムを隠蔽するなどの理由で NuxtJS を選択しています。 Vuetify 管理画面のフロントエンドの実装に UI ライブラリの Vuetify を使用しています。ユニマのフロントエンドは自由度の高いデザインを実現するために Atomic Design をベースにフルスクラッチで UI コンポーネントを実装しています。一方で、管理画面に求められるのは管理画面的な UI なので、Vuetify を採用してフロントエンドの実装コストを削減することを目的としています。 NestJS ユニマと管理画面のバックエンドは同じサーバを参照していて、 NestJS を使用して実装しています。 NestJS は生の Express を採用するよりも、規約の従って開発が可能なこと、DI の仕組みによって依存関係をモックしやすくテストが書きやすいこと、周辺のモジュールが整っていてコアの開発に集中できそうなこと、などが採用理由です。 OpenAPI フロントエンド向けに REST API を提供しています。NestJS にはバックエンドのコントローラーから OpenAPI の定義書を自動生成するモジュールがあります 1 。自動生成された定義書は openapitools/openapi-generator-cli を使用してフロントエンド向けの TypeScript のコードをさらに自動生成しています。つまり、バックエンドでコントローラーを定義すると、それを呼び出すフロントエンドのコードが自動生成される仕組みを用意しています。GraphQL を採用しなかった理由は、バックエンドの API を SaaS 用の API として公開する計画がプロジェクトの立ち上げ当初からあったからです。公開用の REST API とフロントエンドで使用する GraphQL の両方を実装、管理するより、公開用の REST API を使用してフロントエンドを実装するほうが作成するべき API が1つだけになるので、メンテナンスのコストが下がると判断しました 2 。 TypeORM ORM には TypeORM を使用しています。過去のプロジェクトで採用実績があったのと、NestJS に TypeORM のモジュール 3 があったので採用しました。TypeORM を採用した感想は、マイグレーションの仕組みが用意されていたりと便利ですが、レコードを select してくるときの型安全性がないことや、テーブルを多数 join すると SQL の実行速度とは別でパフォーマンスが劣化するなどの問題 4 が知られていて一長一短だなと思いました。特に select 時の型安全性がないのは、TypeScript を採用しているメリットを下げることにつながるので、次に新しいプロジェクトが立ち上がるなら他のライブラリを検討すると思います。 Terraform AWS のリソースの IaC 化に Terraform を使用しています。IaC 化の手段として、フロントエンドとバックエンドと言語を揃えるために AWS CDK も候補にありました。しかし、Terraform が会社の横断的にインフラを担当しているチームによって全社的に導入されそうな雰囲気があったことと、 terraform import コマンドの存在から Terraform を採用しました。 terraform import は AWS にある既存のリソースを Terraform 管理下にするためのコマンドです。ユニマの開発におけるリリースの流れは、ステージング環境で動作確認を行った後に本番環境にデプロイを行う流れです。新しくインフラのリソースを作成するときは、AWS のマネージドコンソールでステージング環境にリソースを作成して terraform import で Terraform 化した後に、この Terraform をベースに本番環境にリソースを作成します。この terraform import を使用した一連の流れで作業を行うことで、ステージング環境と本番環境が限りなく一致する、マネージドコンソールから直感的にリソースを作成できる、といった利点があります。 MySQL データストアには MySQL (Amazon Aurora) を使用しています。まず最初に「Ethereum 上の一部データをデータストアに取り込み、集計処理を行う」という用途がメインになると考えて RDB を選択しました。そして社内の他のチームでの採用実績もあり、MySQL の設定や運用のノウハウを参考にできると考えて MySQL を選択しました。 バックエンドにマルチテナント機能を実装するときになって PostgreSQL の Row Level Security 機能を知って「PostgreSQL の方が良かったのでは？」と後悔しました。次データストアを選ぶときは PostgreSQL の機能も含めて検討したいです。 Truffle/TypeChain これらはどちらも Ethereum 上で動くスマートコントラクトの実装を補助するツールです。Truffle はコントラクトのデプロイやマイグレーションの管理を行い、TypeChain はスマートコントラクトのメソッドを TypeScript から呼び出すときに、型を自動生成するためのツールです。 Truffle は当時はコントラクトの管理を行うツールのデファクトスタンダードでしたが、最近は Hardhat がその座を奪いつつあるという印象です。Hardhat はデバッグの容易さや多数のプラグインがコミュニティによって開発されており、コントラクト実装時の開発体験の改善が期待できます。機会を見て Truffle を Hardhat に置き換えるか、新規プロジェクトでは Hardhat を採用したいと考えています。 TypeChain に関しては以前に紹介記事を書いたのでそちらを御覧ください。 tech.mobilefactory.jp Infura/IPFS/Torus これらはユニマで使用しているブロックチェーン関係の SaaS やプロトコルです。 Infura はマネージドな Ethereum API を提供する SaaS IPFS は分散してファイルを管理できるプロトコル Torus は非カストディに秘密鍵を管理する SaaS ブロックチェーン関係の技術スタックについて後日別の記事で詳細を紹介できればと考えています。 終わりに ユニマと管理画面の技術スタックの紹介をしました。 これらのスタックに興味を持った方やもっと詳しく話を聞いてみたい方はカジュアル面談をしてみませんか？以下からエントリーしてフリーコメント欄に「アドベントカレンダーを見た」と記載してエントリーしてください。 open.talentio.com OpenAPI (Swagger) | NestJS - A progressive Node.js framework ↩ Auth0 の API ドキュメント の anything that can be done through the Auth0 dashboard (and more) can also be done through this API という状態が理想です ↩ Database | NestJS - A progressive Node.js framework ↩ Performance of query with many relations · Issue #3857 · typeorm/typeorm ↩

こんにちは！エンジニア組織開発責任者の id:kfly8 です。 今年もモバイルファクトリーのAdvent Calendarをお送りします🎉 今年のアドベントカレンダーは「 今日から使える技術 」をテーマにコンパクトにお届けしていきます！ *1 今予定しているキーワードを見ると・・「TypeScript」「Vue.js」「Perl」「CLI」「MySQL」「AWS」「地図」「プロダクトマネジメント」などがあります。ぜひお楽しみください！ 一覧 12/1 tech.mobilefactory.jp 12/2 tech.mobilefactory.jp 12/3 tech.mobilefactory.jp 12/4 tech.mobilefactory.jp 12/5 tech.mobilefactory.jp 12/6 tech.mobilefactory.jp 12/7 tech.mobilefactory.jp 12/8 tech.mobilefactory.jp 12/9 tech.mobilefactory.jp 12/10 tech.mobilefactory.jp 12/11 tech.mobilefactory.jp 12/12 tech.mobilefactory.jp 12/13 tech.mobilefactory.jp 12/14 tech.mobilefactory.jp 12/15 tech.mobilefactory.jp 12/16 tech.mobilefactory.jp 12/17 tech.mobilefactory.jp 12/18 tech.mobilefactory.jp 12/19 tech.mobilefactory.jp 12/20 tech.mobilefactory.jp 12/21 tech.mobilefactory.jp 12/22 tech.mobilefactory.jp 12/23 tech.mobilefactory.jp 12/24 tech.mobilefactory.jp 12/25 tech.mobilefactory.jp 過去のアドベントカレンダー qiita.com qiita.com qiita.com qiita.com qiita.com *1 : 140字くらいの記事でもOKというルールを今年は設定しています。

こんにちは、21卒エンジニアの id:d-kimuson です。 先日、プロダクトで使用している lodash を lodash-es に置き換えることで、バンドルサイズの削減をしました。 lodash を lodash-es に置き換える話はよくありますが、今回のプロダクトは運用歴が長く CommonJS と ESModules が混在している少し特殊な環境での試みだったので、知見を共有したいと思います。 利用されていないコードを消し、バンドルサイズを減らす lodash はバンドルサイズの大きなライブラリです。minified な状態で 69.9KB のサイズになります。 参考: lodash v4.17.21 ❘ Bundlephobia webpack にはデッドコードを削除する TreeShaking という機能があり、ライブラリのデッドコードを削除することができるのでバンドルサイズの削減に効果的です。 しかし、lodash は CommonJS で記述されていて、TreeShaking の効果を得にくいので ESModules で書かれている lodash-es を使用することで、効果的にバンドルサイズの削減をすることができます。 長いので以降 CommonJS は CJS, ESModules は ESM と記します。 lodash から lodash-esに TreeShaking が効くように置き換える このプロダクトでは、CJS で記述されたモジュールと ESM で記述されているモジュールが混在しているので、個別に置き換えていきます。 ESModules で記述されているモジュールを置き換える ESM の置き換えはシンプルです。 lodash-es を使うようにする 全体ではなく、使う関数のみ個別でインポートする 形に変更します。 -import _ from 'lodash'; +import { defaults } from 'lodash-es'; // ... -const obj = _.defaults(obj1, obj2); +const obj = defaults(obj1, obj2); あとは webpack が自動的にデッドコード( defaults 以外) を削除してくれます。 CommonJSで記述されているモジュールは、CommonJS のまま TreeShaking が効くように置き換える TreeShaking が効く条件は webpack が TreeShaking に対応していること webpack4: ESM のみ webpack5: ESM, CJS 両対応 (効果は ESM のほうが大きい) 使用する値のみ import していること です。 このプロダクトでは CJS のコードも多く残っていますが、webpack5 を利用しているので「CJS のままでも TreeShaking の効果を得られるが、ESM にしてから置き換えるとより効果が大きい」という状態でした。 ですので CommonJS のまま置き換える (楽だけど効果は小さい) ESM に置き換えつつ、lodash-es に置き換える (大変だけど効果が大きい) の選択肢があります。 詳しくは触れませんが、webpack 環境で ESM に置き換えるときには、default export の場合、同時にそのモジュールを参照している他のモジュールも ESM に置き換える、あるいは require 文を書き換えなくてはいけないという制約があり、2の内容で修正すると変更範囲が大きくなってしまうという懸念点がありました。 したがって、CJS で記述されている場合には 置き換えファイルを参照しているファイルに CJS で記述されているものが存在するか default export に置き換える必要があるか を確認して、変更範囲がそのファイルのみに閉じている一部のものは ESM に置き換えますが、それ以外の大部分のソースコードでは CJS のまま置き開ける方針を取ることにしました。 変更範囲がファイル内に閉じているものは以下のように ESModules にしつつ置き換えます。 // 参照元がCJSでかつdefault_export -const _ = require('lodash'); +const { map } = require('lodash-es'); -const obj = _.defaults(obj1, obj2); +const obj = defaults(obj1, obj2); 変更範囲がファイル外に及ぶものは、ESModules には置き換えず、CJS のまま TreeShaking だけ効くように個別の値をインポートします。（※後述しますが、この方法ではTreeShakingが効かないので、別の方法を取る必要があります） // それ以外 -const _ = require('lodash'); +import { map } from 'lodash-es'; -const obj = _.defaults(obj1, obj2); +const obj = defaults(obj1, obj2); これで CJS でも置き換えが完了しました。 CJS から lodash-es を読むとむしろバンドルサイズが増える問題に遭遇 上記の指針で置き換えを完了したのですが、いざバンドルサイズを計測してみるとむしろバンドルサイズが増えていることがわかりました。 エントリ 元サイズ 置き換え後のサイズ entry1 493.95KB 534KB entry2 369.18KB 408.39KB entry3 362.57KB 401.97KB バンドルサイズが増えてしまっては置き換えた意味がないので、原因を調査しました 原因①: ESModules を CommonJS で利用するための変換コードが増えてしまった バンドルサイズを個別に見てみると、lodash のサイズが増えてしまっていることが分かったので、詳細な原因を探すために、以下のパターンでそれぞれ lodash 関係のバンドルサイズを計測してみました。 lodash を CJS で全体/個別 に読む lodash を ESM で全体/個別 に読む lodash-es を ESM で全体/個別を読む lodash-es を ESM で全体/個別に読む 以下が調査結果です。 ライブラリ 呼び出し 全体サイズ tree-shaking lodash CJS 69.2 KiB X lodash ESM 69.4 KiB X lodash-es CJS 148 KiB O (24.2 KiB) lodash-es ESM 81.1 KiB O (7.19 KiB) この結果から「lodash-es を CJS で依存解決しても TreeShaking でデッドコードを削除することができるが、総バンドルサイズが増えてしまうので一定数読んだ時点で lodash 時よりバンドルサイズが増えてしまう」ということがわかりました。 ただ、lodash-es を CJS で依存解決すると総バンドルサイズが増える原因はよく分からなかったので、実際に ESM, CJS で記述されたモジュールをそれぞれ ESM, CJS で依存解決するときの webpack のバンドルがどういう形になるのかを確認してみました。 webpack では概ね以下のようなコードにバンドルされています。 ※そのままでは読みにくいので、読みやすいようにかなり簡素化・改変しています。 ;(() => { var moduleMap = { 100: (initilizedModule) => { initilizedModule.exports = "export text" } } , moduleCache = {} function require(id) { if (id in moduleCachle) return moduelCache [ id ] ; const mod = moduelCache [ id ] = { exports: {} } moduleMap [ id ] (mod) return mod } (() => { // エントリーポイント const resolved = require(100) } )() } )() ESM だとエントリーポイント箇所に直接展開されますが、CJS や、CJS のモジュールを ESM から読んだり、ESM のモジュールを CJS から読むときには moduleMap にモジュール定義が書かれ、それをエントリーポイントから require を使って解決するようです。したがって、require や moduleMap 部分が ESM のみの場合と比べて余分なコードになります。 また、ESM で書かれたモジュールを CJS で読むときには、モジュール定義箇所で default export に改変するような処理が追加で必要になるため、以下のようにコード量が増えます。 var moduleMap = { - 100: (initilizedModule) => { + 100: (initilizedModule, _exports, require) => { + "use strict" - initializedModule.exports = "export text" + require.r(_exports), require.merge(_exports, { default: () => t }) + const t = "export text" }, }, この辺りがサイズ増加の原因になって増えているようです。実際のバンドルでは変数名は1文字なので use strict も比較的コード量が増える部分です。特に lodash-es の場合は、関数ごとにファイルが分かれているので、関数ごとに上記の余分なコードが生成されるため影響が大きくなっていると思われます。 全体のバンドルサイズが増える問題については、CJS から依存解決する以上必要なコードが増えているだけなので、CJS を使うのであれば避けようがないサイズの増加であることが分かります。 原因②: そもそも TreeShaking が効いていなかった また、原因①の調査をしていて分かったのですが、そもそも今回の書き換えのように const { findIndex } = require( 'lodash-es' ) の書き方だと、TreeShaking が働かないことも分かりました。 webpack では上記のコードを以下のように展開します。 ;(() => { var moduleMap = { 100: (initilizedModule) => { // lodash-es // ここに全 lodash-es のバンドルが書き出される } } , // ... 省略 (() => { // エントリーポイント const { findIndex } = require(100) } )() } )() 見てわかるように全てソースコードがバンドルに含まれてしまっています。 TreeShaking が効く書き方に直して、バンドルサイズを減らす 原因①については、将来的に ESM への置き換えが終われば解消しますが、CJS の状態では依存解決のための必要なコードが増えているだけなので許容するしかありません。 一方、原因②については以下のような書き方ならきちんと TreeShaking が働いて使われている箇所だけバンドルしてくれます。 // その1: require からメソッドチェーンで関数を呼ぶ require( 'lodash-es' ).findIndex() また、TreeShaking ではありませんが個別のモジュールを指定して依存解決することで使用する関数のみバンドルに含めることもできます。 デッドコードさえ削除できれば良いので、こちらの方法でも原因②は解消できます。 // その2: 使用する関数を指定して import する const { default : findIndex } = require( 'lodash-es/findIndex' ); findIndex() その1の書き方では、使用箇所に require を書く必要があることに対して、ESModules は基本的にモジュールの先頭でまとめて依存解決を書くので、将来的に ESM を置き換えることを考えてより近いその2の書き方で置き換えることにしました。 バンドルサイズを削減することができた CJS で個別に import するようにしたことでやや可読性が悪くなりましたが、これでプロジェクトの lodash を全て置き換えることができましたので、再びバンドルサイズを計測しました。 エントリ 元サイズ 置き換え後のサイズ 割合 entry1 493.95KB 459.74KB -6.9% entry2 369.18KB 327.9KB -11.2% entry3 362.57KB 325.01KB -10.4% バンドルサイズを 6-11% 程度削減できていることが分かります。 今回のプロジェクトでは無事削減することができましたが、lodash-es の総バンドルサイズが増える原因①については解消していないので、lodash-es の関数の使用量が一定量を超えるとむしろバンドルサイズが増えてしまうと推測されます。実際にバンドルサイズがどうなったか計測することをおすすめします。 また、このプロジェクトではフロントエンドエコシステムのアップデートに取り組んでいて、その中で CommonJS で記述されたモジュールを ESM に置き換えようとしています。置き換えが完了すれば lodash-es の総バンドルサイズが増える問題も解消されるので、さらにバンドルサイズの削減が期待できます。 おまけ 基本的には、この記事で書いた形で置き換えていけば良かったのですが一部特殊対応が必要だったので紹介します。 wrapper 記法を置き換える lodash には wrapper 記法という関数をメソッドチェーンで呼ぶことができる書き方があり、一部でこの記法が使われていました。 import _ from 'lodash' const arr1 = _.map( [ 1, 2, 3, 4, 5 ] ) // 基本的な書き方 const arr2 = _( [ 1, 2, 3, 4, 5 ] ).map((num) => num * 2) // wrapper 記法 メソッドチェーンで書かれているので、一意な置き換えができませんでしたが数が多くなかったので手動で書き直すことにしました。 chain を利用しない lodash に存在する chain 関数が lodash-es には存在しませんでした。 How to use chain with lodash-es while supports tree shaking? · Issue #3298 · lodash/lodash · GitHub 上記の Issue に書かれているように TreeShaking をサポートできないため追加してない様でした。 こちらも1箇所しか使われていなかったのと、無駄な処理が多く書かれていたことから、lodash を使わずに書き換える形になりました。 まとめ 今回は ESM と CJS が共存する環境下で lodash-es を置き換えることでバンドルサイズを削減する知見を共有しました。 バンドルサイズが大きいので lodash-es 使うようにしてサクッとサイズを減らしたいくらいの温度感だったのですが、実際やってみると CJS と ESM 周りで詰まることがあり、webpack で CJS と ESM 周りがどう依存解決するのか、webpack がどういう形でコードをバンドルするのか等学びが多かったです。 CJS 環境下では webpack5 を利用している lodash から使用している関数の量が一定以下 という条件付きではありますが、lodash-es に置き換え、TreeShaking が使えるようにすることでバンドルサイズを削減できることが分かりました。

こんにちは、エンジニアの id:mp0liiu です。 8月28日(土)の Learn Languages 2021 というイベントの Language Update というセッションで @charsbar さんと一緒に2018年以降のPerl5やPerlコミュニティの最新動向について話してきたので、そのとき話した内容に補足などしつつ記事にしていきたいと思います。 配信アーカイブは こちら から見れます。 時系列 2019/5/22 Perl5.30 リリース 2020/6/20 Perl5.32 リリース 2020/6/24 Perl7の発表 2021/5/21 Perl5.34 リリース Perl5.30 の変更点 正規表現や文字周りの細かい改善などはありますが、正直めぼしい変更点が見られないです。 Perl5.32 の変更点 isa 演算子の実装 値があるクラスのインスタンスもしくはそのサブクラスのインスタンスかを調べる演算子です。 use feature qw( isa ) ; package A { use Moo } my $obj = A->new; print '$obj is instance of A.' if $obj isa A; 今まででも isa メソッドで判定できましたが、メソッドの場合クラス名からでも呼び出せてしまうので、インスタンスの場合のみ判定したい場合は長い条件や経験者でないとわからないような workaround を書く必要がありました。 これを使えばその必要がなくなります。 連鎖比較機能 例えば $x < $y && $y <= $z を $x < $y <= $z といったふうに、同じ値を比較する条件式を簡潔に書けるようになりました。 間接オブジェクト記法を無効化できるように 間接オブジェクト記法は method $object @args というふうにメソッドを呼び出せる記法です。 Perl は割と英語として読み下せることを重視する文化があった *1 ので、昔はこのような書き方をするのが主流でした。 次のようなコードを動かしてみると無効にできるのが確認できます。 no feature 'indirect' ; new Foo; # Bareword found where operator expected, near "new Foo" 無効にしていない場合、次のようなわかりにくいエラーメッセージがでます。 new Foo; # Can't locate object method "new" via package "Foo" (perhaps you forgot to load "Foo"?) 間接オブジェクト記法は関数の括弧を省略し呼び出した場合の文法と似ていて、関数がインポートされているかどうかで間接オブジェクト記法呼び出しとして解釈される関数呼び出しとして解釈されるかが変わり、わかりにくいエラーメッセージがでる場合があります。 これがよく開発者を混乱させていたので無効にできるようにしたようです。 Perl7の発表 Perl5.32 のリリースの少し後、Conference in the Cloud にて当時のPerl5のリリースマネージャー(Pumpking)であるSawyer X氏によってPerl7が発表されました。 *2 Perl7の内容は、以下のようなものでした。 機能的には5.32と同じ デフォルトで strict, warnings などのよく使われるプラグマや最近追加された新機能をONにし、Perl5.0以前からあるPerlの文法を複雑にしている構文を無効にする 目的 初心者がいろんなプラグマを覚えなくてもすぐにPerlコードを書き始められるようにすること 20世紀に書かれたコードの互換性を残すことを大事にしすぎない Perl6がRakuに改名され名前的にも完全に別の言語となったことで、ちゃんとPerl5の後継バージョンをだしたいというモチベーションもあった 最初に書かなければならないボイラープレートがなくなるとコードが書きやすくなりますし、初心者もとっつきやすくなるのでかなり良さそうに見えますね。 少なくとも発表後、日本のPerl界隈ではかなり好反応だった印象があります。 しかし、Perl7やPerl7の発表には様々な問題がありました。 過去のPerl5で書かれたコードを書き換えないと動かなくなる やはり一番目立つ問題として過去のPerl5で書かれたコードを書き換えないと動かなくなることがあげられます。 Perlには後方互換性を重視する文化があり、これはPerlコアにまつわるさまざまな方針を文書化した perlpolicy にも記述されています。 発表された内容のとおりにPerl7が実装されてしまうと perlpolicy に反するわけです。 他にも後方互換性がなくなることで、次のような問題が発生することが考えられます。 /usr/bin/perl は常にPerl5互換だとおもっていたら、OSディストリビュータの都合で任意のタイミングでPerl7に切り替わり過去の資産が壊れてしまう ＃!/usr/bin/perl でどのバージョンのPerlで実行しているのかが明確でなくなって、7で書いていたつもりのコードを5で実行してしまいONになっていたつもりの機能が実はOFFになってしまう Linuxディストリビューションのパッケージ管理が大変になってしまう コミュニティ内で十分に議論せずに突然発表された コミュニティ内で十分に議論せずに Pumpking が突然発表したことも問題になりました。 従来ならこのようなPerlコアの方針の重要な変更を行う場合は Perl5 Porters(Perl5開発者向けのメーリングリストに参加しているPerlの開発に興味のある人たち)に発表してから公にするものですが、これによってコミュニティの一部からはPerl7が受け入れられにくい雰囲気になってしまいました。 より正確に言うと、コミュニティ内で十分に議論せずに突然発表されたというよりは、Pumpking は perlpolicy によって定義される Perl Porter の一人に過ぎず perlpolicy を超越した立場ではないはずなのに perlpolicy に明確に反する方針を打ち出したことが問題視されました。 Pumpking = 行政機関、Perl Porters = 立法機関 と考えてもらうとわかりやすいかと思います。 要は行政を担当する人が法律そのものを変えるような行動をしてしまったというわけですが、これによってコアチームやコミュニティ内で混乱が発生してしまい、Perl5の正式なガバナンス制定が必要だという流れになりました。 Perlコミュニティのガバナンス制定 そういった流れでガバナンス制定についていろいろ話し合いが行われ、2020年12月頃ガバナンスが制定されました。 この内容は perlgov に文書化されています。 ざっくり内容を紹介すると、コアチームとPSC(Perl Steering Council)と呼ばれる運営評議会について明確に定義されるようになりました。 コアチームはPerlの継続的な開発に携わるグループです。 基本的にはコアのコミッターで、運営評議会のメンバーを選出し、コアチームのメンバーを管理する権限を持ちます。 PSCはPerl5の新しいバージョンのリリーススケジュール、プロセスの管理など最終的な決定をする人たちのことで、コアチームから選ばれた3人のメンバーから構成されます。 従来の pumpking を置き換えるものです。 すでにPSCのメンバーはいろいろ入れ替わっていますが、現在のメンバーは Paul Evans 氏, Ricardo Signes 氏, Neil Bowers 氏の3人のようです。 Perl5と7の今後 今後の方針について混乱していたPerl5と7ですが、2021/4/11 にPSCのミーティング *3 が行われ、そこで以下のような方針が決まりました。 以前発表された Perl7 の内容は取り下げて、従来のバージョンによる機能ガードを続けていく( use feature version の形で新機能を有効に) Perl7はそのうちリリースするが、少なくとも来年リリースされることはなくて、当分はこれまでと同じように毎年安定版のリリースを続けていく 十分な機能が揃ったら Perl7 と呼ぶことになるかもしれない Perl5.34 の変更点 コミュニティのゴタゴタがあったのであまり大きな変更点はないですが、大きな変更点としては次のようなものがあげられます。 try-catch 構文 次のように try-catch で例外処理を記述できるようになりました。 use feature qw( try ) ; try { die 'hogehoge' ; } catch ( $e ) { print $e ; } これにより今まで eval-if で書いていた例外処理をわかりやすくかけるようになります。 また、Try::Tiny などと違って ; 忘れがなくなったり、例外処理のモジュールも乱立しがちだったのでどれを使えばいいのかあまり悩まなくて良くなります。 更に自分でコードを動かしてみた限りだと Try::Tiny などの外部モジュールとコンフリクトしないので、既存のプロジェクトにも取り入れやすそうです。 8進数数値リテラルの新構文 2進数が 0b1111 、 16進数が 0xFF といったように記述できていた感じで、 8進数が 0o777 というふうに記述できるようになりました。 今までは8進数を記述する場合先頭に0をつけて 0777 というふうに書いていたので、以前より8進数の記述が見やすくなったかなと思います。 barewordファイルハンドルを無効化できるように barewordファイルハンドルとは型グロブに格納されたファイルハンドルのことです。 昔はファイルハンドルは型グロブに格納するのが一般的でしたが、今は変数に格納するのが一般的なのでそれを強制するような機能ですね。 次のようなコードを動かしてみると無効にできるのが確認できます。 no feature 'bareword_filehandles' ; open FH , '<' , 'tmp.txt' ; my @lines = <FH> ; close FH ; 擬似的な多次元配列(multidimensional)を無効化できるように 擬似的な多次元配列というのは、ハッシュの要素を $foo{$a , $b , $c} というふうにアクセスすると $foo{ join ( $; , $a , $b , $c ) } というふうに動作することで擬似的に多次元配列をエミュレートする機能のことです。 昔のPerlでは多次元配列を使えなかったために実装された機能で、今は使うことも目にすることもないと思いますが、ハッシュスライスの構文 @foo{$a, $b, $c} と似ていて混乱を招くので無効化できるようにしたのだと思います。 次のようなコードを動かしてみると無効にできるのが確認できます。 no feature 'multidimensional' ; my %foo ; $foo{ qw( a b ) } ; #Multidimensional hash lookup is disabled Perl5.36以降はどうなるか Perl5.35 での変更 開発版の Perl5.35 ですでに新機能の追加や言語機能の改善が行われています。 これらはこのまま特に問題がなければ Perl5.36 にも取り込まれると思います。 defer構文の追加 Goなど他の言語などでも見られる構文と同じような感じで、スコープを抜けたときに実行される処理を defer { ... } 内に記述することができるようになります。 この構文は perl5.35.4 で追加されました。 *4 真偽値の扱いの改善 条件式などから返される値や、 !!0 や !!1 などの真偽値を変数に代入しても真偽値としての性質を保つようになりました。 これによって他の言語との相互運用やJSONのエンコードなどデータのシリアライズなどが楽になります。 この改善は perl5.35.4 で行われました。 *5 RFCとして提案されているもの Perlの変更の提案は こちらのリポジトリ を見ればわかるのですが、これらのうちからいくつか取り上げます。 forループの繰り返しごとに複数の要素を参照する構文の追加 現在のfor文だと繰り返しごとにリストの先頭から1要素ずつしか参照できませんが、 for my ($foo, $bar, $baz) (@array) { ... というように複数の要素を順番に参照できるようになります。 この構文が実装されるとハッシュ内の全key, valueのペアを for my ($key, $value) (%hash) { ... } で参照できるようになります。 *6 Everything Slices ハッシュや配列に含まれる値やキー/値の完全なセットを含むスライスを取得する構文を追加しようという提案です。 具体例をあげると %hash{ * } ; # %hash{ keys %hash } と同じ %array[ * ] ; # %array[ 0 .. $#array ] と同じ @hash{ * } ; # @hash{ keys %hash } と同じ @array[ * ] ; # @array[ 0 .. $#array ] と同じ といった感じになります。 {} , [] の中はコードも書けるようで、例えば %array[ grep {; $_ > 5 } * ] といったコードも書けます。 forループの繰り返しごとに複数の要素を参照する構文の追加と一緒に追加されると便利になりそうで、組み合わせて使うと for my ($i, $v) (%array[ *]) { ... } と書くと配列のindexと要素をイテレーションすることができるようになります。 その他 既にカンファレンスでPSCのメンバーが5.36以降どうしたいかなどといったことを話しているので、いくつか取り上げます。 FOSDOM2021 での Paul Evans氏 のトーク 2021/02/06~07 の FOSDOM2021 でPSCのメンバーである Paul Evans 氏が「Perl's Amazing Time Machine」 *7 というタイトルでトークしており、その中で2025年には次のような機能を実装したいという話をしていました。 match-case構文 の追加、現状の壊れた given-when を置き換える 厳密比較演算子の追加、暗黙的な型変換をせずに値を比較する演算子 静的/動的に型チェックする構文の追加 サブルーチンのマルチディスパッチを可能に、同名でシグネチャが違うサブルーチンを書けるようにする Paul Evans 氏はXS(perl処理系の記述に使われているCのマクロ言語)をバリバリ書ける開発者です。 5.34 の try-catch 構文や 5.32 のisa演算子もこの方が実装しています。 Perl開発の意思決定者にバリバリコード書ける人が入るのは久しぶりのことで、これによりPerlコアの開発が活発化しそうだという期待があります。 Conference in the Cloud! A Perl and Raku Conf での Ricardo Signes 氏 のトーク 2021/06/10 の Conference in the Cloud! A Perl and Raku Conf で PSCのメンバーである Ricardo Signes 氏が「What's new in Perl? 」 *8 というタイトルでトークしており、その中で5.36では次のようなことをしたいと話していました。 use version でベストなコードが書けるようにしたい warnings, utf8 の有効化 barewordファイルハンドル, 間接オブジェクト記法などの混乱を招きやすい機能の無効化 現在20近くある実験的機能の整理、experimental を外せるものは外し、Perlに追加すべきでない機能は削除する Perlコア以外の動向 Perlコア以外にも面白い動きがあるのでいくつかとりあげます。 Corinna Ovid氏 によるオブジェクト指向構文をPerlコアに入れようという提案です。 github に提案や実験的実装がまとめられています。 Perlコアに現状あるオブジェクト指向プログラミング関連の機能は貧弱だったり、CPANにはそれを補うようなモジュールが乱立しているので、このような動きは学習コストが下がったりコードが書きやすくなって嬉しいです。 Perlコアにオブジェクト指向構文を入れようとする挑戦は過去にも何度かありました。 有名なものでは Stevan Little 氏が Moose をPerlコアに入れようと頑張ってたりしていましたが、Moose が大きすぎるなどでうまく行きませんでした。 仕様的には Moose や Raku の影響を大きく受けています。 Moose、Moo などのOOPフレームワークモジュールとは違って keyword plugin の仕組みを使い新しい構文を追加します。 なので ; 忘れがなくなる、記述量が減る、 $self を介さず変数から直接インスタンス変数にアクセスできてインスタンス変数の宣言がなければコンパイル時エラーになるのでtypoに気づきやすい、などといったメリットがあります。 Paul evans 氏が Object::Pad という実験的実装モジュールを作っており、既にCPANにあがっています。 彼の会社では使い始めたりもしているようです。 UV2.0 のリリース libuv のPerlインターフェースを提供する UV が Perl foundation の助成を受けて開発が進み、バージョン2.0がリリースされました。 まとめ ここ最近はPerlコミュニティでいろいろゴタゴタがありましたが、それもようやく落ち着いてきていて今後開発が活発になっていきそうだという感じです。 これからのPerlに期待ですね！ *1 : 「実用 Perl プログラミング」にはPerlで詩を書く話がでてきますが、そのことを考えると当時の雰囲気が少しわかると思います *2 : https://www.perl.com/article/announcing-perl-7/ *3 : https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259789.html *4 : https://metacpan.org/release/WOLFSAGE/perl-5.35.4/view/pod/perldelta.pod#defer-blocks *5 : https://metacpan.org/release/WOLFSAGE/perl-5.35.4/view/pod/perldelta.pod#Stable-boolean-tracking *6 : 現状でも while (my ($key, $value) = each %hash) { ... } でできますが、途中でループが止まった場合などでハマりどころがあり for my $key (keys %hash) { my $value = $hash{$key}; ... というふうに書かれることが多いです *7 : https://www.youtube.com/watch?v=Kc_bP73xNyM *8 : https://www.youtube.com/watch?v=FlGpiS39NMY

モバイルファクトリーのエンジニアは、NFTマーケットプレイスの「ユニマ」や位置ゲームの「駅メモ！」など様々な事業の開発をしています。そんなエンジニアたちが、普段、どのようなことを考えているのか。3人のエンジニアに聞いてみました。 この記事に出てくる人たち チームによって性質は異なるのだから、課題に応じて、開発の進め方を変える ワークログを書くのは楽しい 可視化するのは、組織開発においても、当然サービス開発、エンジニアリングでも大事 可視化は目的ではない 楽しく仕事をする。そのために斧を研ぐ 理想を知らないと妥協してることに気づかない 自分が望んでいる環境があるなら、そう変えればいい 三者三様のキャリア @kfly8 : 今日は、モバファクのエンジニアが普段どんなことをしているのか、考えているのか、大切にしているのか、みたいなことを聞いていきたいです。よろしくお願いします！ まずは、みんなが普段どんなことをしているのか、自己紹介兼ねて教えてください。 @tsukumaru : エンジニアとして入社し、いまはマネージャーをしています。チームビルディングやピープルマネジメントに興味があるので、今回はその辺りを中心に話せればと。 @odanado : ブロックチェーンチームでソフトウェアエンジニアをしているodanです。チームではテックリードのポジションでブロックチェーン技術のキャッチアップや機能開発の設計などしています。ブロックチェーンの他にWeb 技術やプログラミングが好きです。 @maeken : 開発とスクラムマスターをしていて、普段はビールを飲んでいます。 @kfly8 : マネージャー、テックリード、スクラムマスターだね。 遅れたけれど、自分も簡単に自己紹介を。エンジニア組織開発責任者をしていて、堅く言えば、人材開発、組織開発、採用、技術広報など開発パフォーマンスにかかること何でもできればと思って動いています。 今日は３人のイイ話を楽しみにしています！ @maeken : まかせてください。 この記事に出てくる人たち @tsukumaru 2016年新卒でモバファクに入社。駅奪取、ブロックチェーンチームのエンジニアを経て、現在はマネージャーとして、チームビルディングやピープルマネジメントなどに注力している。 去年生まれたこどもと過ごす時間が一番の癒し。 @odanado 2018年新卒でモバファクに入社。入社当初に立ち上がったブロックチェーンチームにソフトウェアエンジニアとして在籍。現在はブロックチェーンチームのテックリード。 @maeken 沖縄県出身。琉球大学大学院理工学研究科情報工学専攻修了後、モバイルファクトリーにエンジニアとして2019年に入社。アワメモ！の新規開発・運用を経験し、現在はステーションNFTチームの開発・スクラムマスターを行う。ビールを飲むのが得意。 @kfly8 ゲーム開発やプロダクトマネージャーを経て、現在はエンジニア組織開発責任者。エンジニアの育成、採用、組織課題などに取り組む。また、技術コミュティ好きをこじらせて、Japan Perl Associationの理事もやらせてもらっている。 チームによって性質は異なるのだから、課題に応じて、開発の進め方を変える @kfly8 : まずは、普段の働き方、開発環境だったりを教えてほしい。 @tsukumaru : フルリモートで、コアタイムありのフレックスで働いていますね。東京だけじゃなくいろんな所で働いている。 @kfly8 : 支給されているPCはどうだろう？ @tsukumaru : 会社支給のMac Book Pro。スペックは不足している印象はない。M1 Macなども使い始めているので、新しいものも反映されていて良いなと。 @kfly8 : odanはどう？ @odanado : あー、それで言うと足りていなくて（笑） tsukumaruさんのチームだと、AWS上に開発環境があって、大丈夫ですけど、自分のチームはローカルでバックエンドも、フロントエンドも開発している。 メモリ16GのMacBookProを使っているんですが、メモリが足りない。 これは会社にどうこうでなく、Appleシリコンで32GB積んだやつをAppleに出してもらえればと（笑） @kfly8 : 2台PCがあればいい？ @odanado : あー、開発用とSlack用？（笑） 一同 : （笑） @odanado : リモートワーク前提だと、デスクトップマシンを支給するのはもしかしたらあるかもしれない？ @kfly8 : １周回っている感じだね。以前はデスクトップPCを使っていて、会議室へ持ち込みしやすくするためだったり諸々の理由で、ノートになった。フルリモート環境だと、デスクトップに回帰する選択肢もあるのかもね。 各々の在宅環境もそれぞれだよね。 tech.mobilefactory.jp @kfly8 : 開発の進め方についても聞かせてほしい。 これもチームごとに個性があるけれど、スクラムマスターのmaekenから聞こうかな。 @maeken : 前提として、開発の進め方は、チームに任されている。「会社として開発の進め方は決まっているんですか？」と聞かれることがあるけれど、そうではなくて、自分のチームと他のチームでも異なる。 @maeken : それで、うちのチームはイテレーションが1週間のスクラム。週に各種セレモニーがあって、それを繰り返している。作ったものをレビューしてもらって、開発の方向性を決めていくのを大切にしている。スプリントレビューといった定例もあれば、もう少しまとまった単位でレビューを行う場も用意していたりする。ただ、ミーティングの量はスクラムのセレモニー以外は減らすようにしている。これには失敗談があって、なるべく全員で、共有する場を設けていたけれど、それだと、ベロシティが伸び悩んでいた。振り返りをして、まとまった作業時間がエンジニアは必要だと思った。細切れの時間だと集中ができない。ミーティングをガッとまとめて、作業時間もまとめてとるようにしてみて、スゴイ改善した。やるならミーティングを固めるようにする。 普段の開発の進め方も随時、ふりかえり、改善していっています。 @odanado : 会議を1日に集中させる、というのはうちのチームも取り組んでいるプラクティスですね。実際、メンバーからも好評の声が。 @maeken : odanさんのチームとスプリントの長さも違いますよね。 @odanado : あー、ですね。1週間だったスプリントを、2週間のスプリントに変更した。それはミーティングを減らしたり、まとめたりする意図もあった。スプリントのセレモニーを、毎週にすると実質開発する日が4日となるので。 @kfly8 : odanのチームは、1週間だと収まり切らない大きいチケットがありがちだったよね。小分けにするプランもあったけれど、価値の切り口が難しかった。結局、2週間で計画を立てる形にして、うまくいっていそう。 @maeken : チームによって性質が異なるから、それによって開発の進め方が変わる良い例ですね。 @tsukumaru : 開発チームとしてミーティングをまとめるのは良さそうではありつつ、違う切り口で、ひとつ。今の自分のマネジメントの役割だと、1on1をすることがあるけれど、それを1日にまとめると、喋りつかれちゃう（笑） 自分の場合は、意識的にずらしたりしている。 @kfly8 : マネジメントあるあるだ（笑） ワークログを書くのは楽しい @kfly8 : フルリモートになって工夫していることはある？コミュニケーションなど、新たに出てきた課題などあれば。例えば、新しい人が入ってきた時に工夫していることとか、コミュニケーションするために何かしていることとか。 @maeken : コミュニケーションは、意外とそこまで変わってないですね。 ミーティングは先程の通り時間をまとめたり、合間で雑談をしたり、あとは、Slackでのチャットコミュニケーションと、オフラインの時とあまり変わっていない。 @maeken : チケットの整理など、物理ホワイトボードが使えなかったのが一番大きい変化。みんなで図を書いて議論したり、付箋ぺたぺたしてふりかえりするのとかしづらい。最近はホワイトボードのWebサービスを使っていて、すごい良かった。ふりかえりや、チケット同士の依存関係、あとは朝会の連絡事項なども掲示板的な感じで使っている。逆にオフラインになったとしても使うと思う。どこでも見れるし、無限にでかいホワイトボードで記録が残る。 @kfly8 : コミュニケーションに変わりないのは興味深いね。意外。 @odanado : maekenさんのチームは、リモート前とメンバーが変わっていない、というのは大きいかも？リモート前の関係値がある状態で、リモートをやっているので、そんなに困らなかったのかなぁと思った。チームとして成熟している印象。 @maeken : たしかに。2年間くらい同じメンバーで、チームや関係値ができている状態なので。以前、気軽に雑談できる場所を用意してみようと、コミュニケーションツールを導入してみたが、結局だれも利用しなかった。様子を見ていると、コミュニケーションも悪い感じじゃなさそうだから、それはそれでいいのかなぁと。 @kfly8 : チームメンバーが変わって、課題やトライしたことがあれば。だれか教えて。 @maeken : tsukumaruさんのチームだと、毎日定期的に雑談する予定を設定していますよね？どんな感じ？ @tsukumaru : それは、2,3名で話すくらい。これがもっと機能していればリモートワークの工夫として良いかもしれないけど、まだ工夫が必要そう。 自分のチームでやっていたのは、オンボーディング用のドキュメント整備を行った。長年のドキュメントが溜まってきて、どこから読んだら良いのか、どこまで読んだら良いのか困っていた。それを、新卒は"まずここだけ読めば良い"という案内をわかりやすくした。これは好評ですね。 @kfly8 : イイネ。ドキュメントが多いというけれど、ドキュメントを書く人が多い？ @tsukumaru : みんな書いてますねー。 仕様だけでなく、ワークログとか。 @kfly8 : ポジショントークになってしまうけれど、ドキュメントをよく書くのは、モバファクの特徴的な良い文化と思っている。 @maeken : たしかに。入社してからドキュメントがあるなと思った、先輩も書いているし、自分でも書こうと思った記憶ある。 @odanado : ワークログという概念は、入社して初めて知ったが、良いなと思った。個人開発でも書くようになったし、Zennがスクラップ機能を出して、そこにワークログ書いている。どうして書くか言語化が難しいけど、メモを残すのは楽しい。 可視化するのは、組織開発においても、当然サービス開発、エンジニアリングでも大事 @kfly8 : 最近、直面した課題があれば、教えてほしい。 @maeken : ステーションNFTに関連するサービスを最近作っていて、そこのスクラムマスターとして開発している。最初の数週間が思うように開発が伸びなかった。そこで、数週間分スプリントを回した内容踏まえ、大きなまとまりのふりかえりを行った。何か開発のボトルネックはないか？って見直した。その時に、さっき話した、ミーティングが多くて、開発に集中しずらい課題が出てきた。 @maeken : もう一つが、要件決めを何からやれば良いかわからない課題が出てきた。スプリントでやることを決めるためには、何をやるのか決まっていなくちゃいけなくて、さらにその前に、要件を決めていく必要がある。で、当時、開発途中で別の要件が発覚したり、変わったり、逆に削除になったりで、そういったことが原因で開発のスピードが伸びないことがわかった。 　それをどうにかするために、いくつか先のスプリントまで、いつ何をしないといけないのか、依存関係はどうなっているのか可視化した。スクラムでいうとバックログの透明性をあげよう、とした。可視化したことで、自ずと「このタイミングでこれをするから、その前にこれの要件を決めておこう」といった会話がしやすくなった。それはすごい効果があった。 　問題をチームで見えるようにすることで、動きやすくなる。それは、開発のパフォーマンスであったり、開発の着地の見込みであったり、同じかなって思ってる。 @kfly8 : 普通にいい話。今度、詳しくブログに書いてほしい。 @tsukumaru : 可視化、に関連して、最近やっている、DX Criteriaの話がある。 自分のチームは、かなり大所帯。エンジニアはたくさんおり、それ相応にやることも多いし、要件を考えるディレクターの余裕もない状況。 それを改善するために何かできるかと、がっとふりかえってみて、チームの課題点を洗い出し、改善できるところを可視化しようとして、DX Criteriaを使ってみた。やってみた感じ、直感的に「ここまずいだろうなぁ」と感じていたところが、ちゃんと実際に赤く問題があると可視化された。これから改善の行動を取る必要があるけれど、一旦可視化って所はできたなと。 @kfly8 : イイネ。 こんなことを言うと、良くないかもしれないけれど、すでに直感的にまずい所はあって、可視化せずとも出来るところから進めたいと感じる人もいると思うんだ。なぜわざわざ遠回りしたのか？ @tsukumaru : 直感的に感じている課題だけが、課題なのかわからなかった。全体像を把握したかった。全体像を把握した上で「いくつか課題があるけれど、今はこの課題に取り組んでいる」と、全体像を共有しながら、改善していきたいと思った。局所解にならないようにしたいと思った。 @kfly8 : イイネ。もう少し聞かせてもらいたいのだけれど、大所帯のチームだし、チームの人を動かすのに苦労はしなかった？ @tsukumaru : 計測をするのは、チームに相談して、反発はなかった。むしろ「そういうの良いと思うんでやってみましょう！」といった反応。 多分、問題になるのはこの先。こういう課題があるのでやっていきましょう、と言ったときにみんなが取り組んでくれるか。そこをどう進めていくか、は問題。 @kfly8 : 今後に期待だね。応援したい。 テックリードとして別の切り口で、odanから最近課題になっていることあれば。 @odanado : 最近チーム内でWeb APIのパフォーマンス分析で、どうやってボトルネックを探すか、が課題になった。こういうパフォーマンスの文脈だと場合は「推測するな、計測せよ」と良く言われるけれど、これもさっきの可視化の話に繋がりますね。可視化するのは、組織開発においても大事だと思うし、当然サービス開発、エンジニアリングでも大事。 @odanado : 元々ある程度計測しやすい状態にはあった。というのも、ISUCONのおかげ。ISUCONでの学びを活かして、プロダクトに事前にAPI呼び出しをトレースできるようなものをバックエンドやフロントエンドに仕込んでいた。そのおかげで、ボトルネックの可視化という面で役に立って、何時何分にAPIのリクエストが始まり、何時何分に終わったか、というのが全部データで取れていて、さらにその中で何時何分にクエリが始まっているかだとか、何時何分から外部APIを呼び出しているかなどある程度計測できる状態にあって、すごい助かったというのはあった。 けれど、全てを計測できるわけではなくて、足りないオブザーバビリティの改善をした。オブザーバビリティの向上はこれからもやっていこうと感じています。 @kfly8 : odanもイイネ。 可視化は目的ではない @kfly8 : 3人とも可視化をして、チームを動かす、システムをよくしていく話だったね。 敢えて聞くけれど、可視化に落とし穴もあると思うんだ。例えば、人によって解釈が違う、数字が1人歩きしてしまったり、数値の低さに注目が集まり本質的な話しから逸れたり。 可視化するときに気をつけていることはある？ @maeken : 落とし穴は、計りすぎること。計ることや数値自体が目的になってしまうのは良くないなと。例えば、ベロシティの話であれば、1人1人のベロシティは計っていない、チームのベロシティだけ計っている。個人個人のベロシティを計ることで、その人を評価しているようにみえるし、比較になってしまう、それによって、低い人のショックに繋がる。 ベロシティを計っているのは予測をするため。今これくらいのペースでアウトプットを出しているから、未来のここではこれくらいのことが出来ていそうと予想が立てられる。手段と目的が逆転しないように、計測する際は、目的を添えて伝えるようにしている。 一同 : 大事大事。 @odanado : うーん、なんだろう。 自分は対象がシステムだから、そういう懸念はあまり起きないなーと。 @maeken : APIのパフォーマンスで、数値のやばさの基準はどうやって作った？ @odanado : 相対的に見るなら、同じアプリケーションのAPIの平均、分散や呼び出される回数などをみて、API間のグラデーションを見る。 そもそも、パフォーマンスが絶対的に悪いかどうかは、フィーリングかなぁと。実際にユーザーになって、マウスを動かしたり、スマホでボタンタップをしてみたりして、まぁ雑ですけど、もっさり感を感じるか、とか、フィーリングに今は頼っていますね。 @maeken : 実際にさわってみて、そのフィーリング。 @odanado : ですねー。ここは今後、プロダクトマネージャーと話さないといけないところで、例えば、このAPIは何ms未満にすることが、このプロダクトの価値提供なんだと、決めていきたい。プロダクトによって、例えば「100ms」を早いと取るか遅いと取るかは異なる。50ms or dieとか、場面場面というか、どんなサービスやっているかに寄ってきますね。 @maeken : 変わってくるからこそ、例えば「100ms」を遅いと決めつけたり、それも落とし穴なのかなと思った。 @odanado : ですね。maekenさんが言っていた、目的の話に繋がる思っていて、プロダクトのゴールや体験してもらいたいことがあって、そのためにどこまでが許容ラインなのか決める話なので。 @kfly8 : 可視化するだけでなく、目的志向でありたいと。 楽しく仕事をする。そのために斧を研ぐ @kfly8 : 可視化にフォーカスされているけれど、他に開発で大切にしている価値観があれば聞きたい。 @maeken : 全てひっくるめて、開発、というか、仕事は楽しくできた方が良いと思っていて、命大事に、楽しく開発するために、頑張る。仕組みづくりやチーム作りを頑張る。余計なことをやらない。結局、楽をしたいじゃないですか。ラクするというのは、サボるという意味じゃなく。大切なことに集中したいので、そのために頑張る。 @tsukumaru : 自分も楽しく、というのはある。そのために、斧を研ぐ時間は大事にしたいと思っている。木こりのジレンマの話。第一領域に集中するだけでなく、もちろん大事なんですけど、それだけでなく、第二領域、チームの改善や振り返りなど、そこもやっていかないとチームが良くなっていかない。チームがよくなっていかないと、個人も楽しくなっていかないと思うので、その時間は大事にしたい。第二領域をやれるようチームを動かすのも自分のマネジメントの仕事の一部かなと思っている。 理想を知らないと妥協してることに気づかない @kfly8 : odanは全然違う視点で話してくれるはず。 @odanado : そう思っていました（笑） ソフトウェアエンジニアのマインドとして、理想を追い求める。これは個人的に大事にしている思想で。理想は誰にも見つかっていないとしても、絶対に理想はあると思っていて。設計や実装をするのは、そこに向かうための道だと思っている。業務というのは、それを見つける作業だと信じているところがある。 @odanado : 基本的に100％妥協しないように仕事をしていることが多い。例えば、外部ライブラリを使う場面で、とりあえず目的は達成できているから、ライブラリの挙動がわからないけどokとするのではなく、ドキュメントを読み理解をした上で、ライブラリがどうやって動作するのか、それを解釈した上でコードを書いたりとか、そういう部分は強く持っている。 @odanado : ただ、もちろん、ビジネス的な要求だったりで、システム的な妥協をすることもある。けれど、理想を知らないと妥協してることに気づかない。それは成長とか、プロダクトの品質向上には繋がらない。ので、常に理想を持ち、それを追求できれば追求できるくらいの気持ちでいる。 @kfly8 : ふわっとした質問になるけれど、システムの理想ってなんだろうね？もちろんこれも目的次第だけど。システムはどんな特徴を満たしてると良いのか、特に気にしているところがあれば聞きたい。さっき出てきた話なら、オブザーバビリティとか。 @odanado : あー難しいですねー。 理想を、フレームワークに閉じ込める、というのは１つあるかも。仕組み化することによって、常に万全の状態にする、というか。チームのフレームワーク、規約に沿って開発すれば、ベストプラクティスに乗った状態で開発できるようになっていると良いなと思う。例えば、この関数で、Web APIを呼び出せば、バックエンドにログが残り観測性が担保できるとか。 @kfly8 : フレームワークに乗れば、ベストプラクティスに乗れる、というのは発想としては、Easy？中身がわかった上でライブラリを使えた方が良いという話と、若干相反する？ @odanado : Easyというより、開発者体験。１回目は中身を見て理解して、２回目以降はEasyの恩恵を預かれて、開発者体験が良くなるくらいのイメージでしたね。 自分が望んでいる環境があるなら、そう変えればいい @kfly8 : 話が変わるけれど、どうしてモバファクに入社したのか教えてくれるかな？ @maeken : 就活をしている時、自分がやりたいことがある程度できるところが良いなと。そのために雰囲気を見ていた。会社の人数で100名を超えてくると分からない人が増えてきたり、風通しが…といった話を聞いたことがある。ので、100人くらいの規模で探していた。そんな中、話を聞いて、面白そうだと思ったのがモバファク。 @odanado : もともと駅メモ！のライトユーザーで、もっさり感を感じていた。競技プログラミングもやっていたので、パフォーマンス改善、最適化に興味があった。自分が触ったことがあるゲームで、なおかつ、パフォーマンス改善でおもしろそうなことができそうだなと思った。 ただ入社直後にブロックチェーンチームが立ち上がり、手を挙げ現状こうなっている。入社してから全く駅メモ！に関わっていないですね（笑） @tsukumaru : 社長のメッセージと位置ゲームに惹かれましたね。 社長のメッセージに「家族を守る力がほしい」と書いてあった。そんなこと言っている会社って他にいなかった。他だと「会社を成長させる」「社会に還元」っていうのが多かったけれど、家族に注目している社長はいなかった。珍しいと思った。自分自身も家族を大事にしつつ働きたいと思っていたので良さそうだなぁと。 あと位置ゲームに関しては、もともと自分がゲームを作りたいわけではなかった、サービスが作りたかった。位置ゲームは、人のおでかけするっていう実際の行動に影響を与えられるゲームだと思った。これも珍しいなぁ、良いなぁ、と思った。 @kfly8 : 入社してみて、思っていたことと違ったことはあった？良い意味でも悪い意味でも。 悪いギャップがないのも不自然だし、それは改善すれば良いこと。 @tsukumaru : 悪い方のギャップはなかった。いい意味で予想通り。 面接で、みんな強そう、いい人そうという印象。実際入ってみるとみんな強くて、いい人たち。予想通りだし、予想以上にそういう会社なんだなとおもった。 唯一驚いたのは新卒同期が3人しかいなかったこと（笑） @kfly8 : 例年はもう少しいるからね。 @maeken : 良かったギャップは、思ったよりやらせてもらえること。入社して、新卒で配属されるのが、いきなり新規開発になると思ってなかった。配属言われた日に驚いたことを覚えています。 悪いギャップは、現場と経営層で思ったより距離があった。100人規模の会社なので、社長であったり直接話す機会は多いと思っていた。 @odanado : まず良いギャップについて。 就職活動の時、モバファクか従業員10名くらいのベンチャーで悩んでいた。研究室の先生や周りの友人に相談していて、「同期は一生の繋がりだからいいよ」と言われていて、「ホンマか？」と思っていたが、今でもプライベートでゲームするくらいの仲。そういう所が良いギャップ。 悪いギャップは、シニアエンジニアがもっと欲しい。当初、シニアエンジニアがチームにいたが、半年で退職してしまった。チームメンバーの歳が割と近くて、びっくりした。 @kfly8 : 確かに。若い人が多いね。 ２つの悪いギャップに関して動いていることはある？ 現場と経営層のギャップに関してはどうだろう？ @maeken : 月次の全社締め会で、社長に質問をして回答してもらうコーナーが始まったけれど、社員の経営と距離が遠い、という社員の声を拾って始まった。きっかけとしては良い取り組み。直接話せる場があるかないかで全然違う。結果踏まえ変えていくところはあると思うけれど、どんどん取り組んでみるの良いと思う。 新型コロナのこの状況的に直接会って飲むのは難しいけれど、逆にリモートだから、オンラインでパッと集まってパッと聞ける、なども良いなと思った。 @kfly8 : シニアエンジニアが、もっと欲しい件に関しては、どう？ @odanado : とりあえず自分がシニアエンジニアになった（笑） @kfly8 : かっこいい @odanado : 去年からフロントエンドランチ会を定期的に開催している。フロントエンド技術のキャッチアップしながら、雑談する場。教育というか、会社全体のレベル感を引き上げるための取り組みを行なっていますね。 きっかけは、他社でもフロントエンドランチ会をやっているのを聞いていた。そういう会があることや、そこに参加する社員がいる会社がとても魅力的に感じた。まずは自分がいる会社にそういう文化を作るのが良いかなと思った。他社の真似をしながら、モバファクでもやってみようと思った。 自分が望んでいる環境があるなら、そう変えればいい。 一同 : エライ！ @odanado : 今年の新卒もフロントエンドランチ会に参加してもらえているので、脈々と続けられるかなと。 三者三様のキャリア @kfly8 : 最後に、今後どうしたいのか、今後のキャリアについて聞かせてもらいたい。モバファクにどんなエンジニアがいるのか伝えるためにぜひ。 @maeken : 今のスクラムマスターはエンジニアリングマネージャーの一つの要素だと思っていて、そこに興味がある。今、イメージしやすくて、成功体験や楽しさを感じられているから。 自分だけじゃなく、チーム全員で楽しくできるようにしたい。 @tsukumaru : エンジニアリングマネージャーの話が出たけれど、元々自分もEMに憧れてはいて、最近管理職になったことでそういった動きがしやすくなった。ただそこで終わりではなく、経験、知識が足りないので、まずはEMとして成果を出していきたいし、自分が成果を出すことで、maekenとか他のメンバーにEMっていいね！と思ってもらいたいし、その結果会社に良い影響を与えられると良いなと思う。 EMを広めつつ、最終的には、会社の事業の変化を楽しめるような、変化に強い会社をつくることに貢献できたら嬉しいですね。 @odanado : キャリアプランは、最強になることで。 @kfly8 : それどこかで聞いたな（笑） @odanado : （笑） 理由はより良い妥協をするには、理想を知っている必要があって、仕事の上でより良い妥協を繰り返して、選択していくことで、任意のテクノロジートピックについての理想を知っている状態。つまり最強になりたい。 @maeken : 全知全能に。 @odanado : 全知全能に。 @kfly8 : はい！それでは今回はこの辺で。ありがとうございました！ モバイルファクトリーでは、エンジニア組織をより強くするために、採用を行っています。 興味を持っていただいた方は、カジュアル面談も実施していますのでぜひお気軽にご連絡ください。 カジュアル面談のお申し込み あわせて、こちらの採用サイトもご覧ください。 recruit.mobilefactory.jp

はじめに こんにちは。ブロックチェーンチームのエンジニア、 @nanamachi です。 tech.mobilefactory.jp 前回の記事ではたくさんの方に閲覧&コメントいただきありがとうございました。この記事から1年。モバイルファクトリーは日本のどこからでも働けるようになり、書籍購入、資格取得、セミナー参加、懇親会の支援制度などフルリモートに適応できるよう多くの変化をしてきました ( https://recruit.mobilefactory.jp/work-style/ )。その中で社員の環境もさまざま変わったことでしょう。 この変化を記事にすれば、 閲覧数を稼げる 弊社の魅力を発信できるに違いない!という目論見で、初めてバズった記事にすがるエンジニア組織開発責任者の @kfly8 から次のようなチャットが送られてきました。 kfly8: インターネット識者 *1 の @nanamachi さん、よかったら在宅開発環境の記事の２回目書きませんか？ nanamachi: インターネット有識者……🤔🤔🤔 ということで今回はリモートワーク開始から1年半、さらなる進化を遂げた在宅環境をごらんください! 前回の記事も合わせて読むとさらに楽しめます♪ 01. デザイナー @momoyagi さん 在宅環境の様子を教えてください 社用のディスプレイ2枚+Mac Book Pro 電動昇降デスク ハーマンミラーのチェア 無線のヘッドセットマイク Alexa echo dot バランスボード 推したいポイント、改善したいポイント オフィスと同じものではないですが、電動昇降デスクを導入して立ち仕事を可能にしました。バランスボードでユラユラしながら仕事してます。 どんな変化があったか教えてください 仕事環境の改善のために書斎を設けられる広さの家に引っ越しました。電動昇降デスクを導入、モニターやチェアも一新して開発環境をグレードアップしています。MTGなども毎日あるので、音周り環境もう少しよく出来るんじゃないかなーと思ってます。 フリーコメント BGMはDJAlexaです。 02. エンジニア @nanamachi 在宅開発環境の様子を教えてください すでに在宅で仕事ができる環境に満足してしまったので、次はモバイルモニターとコンパクトなキーボードでノマド環境を整備しました。 推したいポイント、改善したいポイント モニター: EVICIV 13.3インチ モバイルモニター 持ち運び可能なモニターです。サイズとしてはA4用紙とほぼ同じくらい。ベゼルが薄いためMacとシームレスに作業できGOODです。 また、USB Type-Cケーブル1本で給電と映像出力の両方ができるのでケーブルがごちゃつかない利点もあります。 キーボード: VORTEX Core 47キー メカニカルキーボード テンキーレスのキーボードから更にFunctionキーと数字キーなどを除いた、40%キーボードと呼ばれるジャンルのミニサイズキーボードです。 カスタマイズ性が非常に高く、設定次第ではフルサイズキーボード以上の使い勝手にすることが可能です。 自分はなるべくフルサイズキーボードに近い操作感を保つため、下記の配置にしています。 青字で書かれたキーは左親指に割り当てられたFnキーと同時に押すと入力されるキーです。 標準では右Spaceの一つ右のみなのですが、Fnキーを多用する配列にしたため押しやすい位置に移動しました。 その他こだわりの点はこんな感じ。 フルサイズキーボードの最上段をそのまま一つ下に下げた位置に配置 コーディングでも日本語入力でもよく使うハイフンを同時押し無しで押せる配置 ホームポジションで矢印キー *2 にアクセスできる 特に数字・記号・矢印などのキーを短いストロークで打てる点が便利で、慣れたら戻れないという意見も納得です。 また、設定を変えたことによってキーキャップに印字されているキーと異なる配置になったためキーキャップも改造しました。 無地のキーキャップにプラモデルなどに用いる装飾シール *3 をちまちま貼っていけば、オリジナルキーキャップの完成です。 アナログなモノづくりが久しぶりだったことありなかなか楽しかったです。 整備してみて 外に出る機会は少ないのですが自宅の中で場所を変えて仕事するだけでも気分転換になるのは良い発見でした。展開に時間もかからないのでおすすめです。 03. 事業部長 Sさん 在宅開発環境の様子を教えてください ディスプレイ: EIZOの4Kディスプレイ キーボード: HHKB HYBRID TYPE-S 無刻印 机: FlexiSpotの電動式昇降デスクの脚にイケアの150x75の天板 椅子: アーロンチェア オーディオインターフェイス: UNIVERSAL AUDIOのAPOLLO TWIN X QUAD スピーカー: GENELECの8320 GLM Studio ウェブカメラ: ロジクールのC922n マイク: オーディオテクニカのAT4040 照明: Profoto C1 Plusを複数台 推したいポイント、改善したいポイント 前回記事からの進化としては、スタンディングデスク導入と、ビデオ会議時の音声品質の向上が大きなところです。 リモートワークが始まった当初は、映像の方に力を入れていて、ミラーレスカメラを使用したり、Blackmagic Design ATEM Miniを導入したりしましたが、結局、大事なのは映像より音声だという結論に至り、マイクやオーディオインターフェースなど試行錯誤を重ねました。 去年の夏頃にオーディオテクニカのAT4040とUNIVERSAL AUDIOのAPOLLO TWIN X QUADの組み合わせにしてからは非常に満足しています。 APOLLO TWIN Xでは、Neve 1084、Teletronix LA-2A、PULTEC EQP-1Aといったプラグインをリアルタイムにかけていて、ビデオ会議の相手に聞きやすい音声となるよう調整を行っています *4 。 自分で壁に吸音材も取り付けました。 映像については、ロジクールのC922nでビデオ会議には充分なクオリティと判断して、机の上をなるべく広くするために映像関連の機材は撤去しましたが、Elgato MULTI MOUNTというスタンドを使って、カメラや照明などは必要に応じていつでも取り付けができるようにしています。 スタンディングデスクは気分転換で時々利用します。また、会社からハーマンミラーのセイルチェアと32インチモニターを送ってもらったので、リビングの隅にも作業スペースを作りました。 MacBook ProとHHKBだけ持っていけば自室とほぼ同じ環境で作業できるように、マウスやウェブカメラの機種、机の天板の色などは同じもので揃えています。 04. エンジニア @the96 さん 在宅環境の様子を教えてください モバワークを活用して実家からの参戦です *5 。 そこそこ田舎なので、休みの日には5kmくらい散歩して神社に行ったりしています。 左ディスプレイ: LG ULTRAGEAR 27GN800-B (27インチWQHD) 右ディスプレイ: IO-DATA LCD-MQ321XD (32インチWQHD) ディスプレイアーム: エルゴトロン LXデュアル デスク マウント アーム スタッキング MBPスタンド: Twelve South BookArc for MacBook キーボード: Mistel Barocco MD770 キーボードの間にあるもの: Anker PowerWave 10 Stand (ワイヤレス充電器), タニタ TT-580 WH (質温度計) 机: 幅145cm 奥行き60cmのL字デスク 椅子: 中古のバロンチェア オーディオインターフェース: UR12 + MG10XU スピーカー: JBL 104-BT-Y3 マイク: sE Electronics X1 推したいポイント、改善したいポイント おすすめ: 分割キーボード キーボードが左右に分離しているので、肩を開いて自然な姿勢でタイピングすることが可能です。 普段は背もたれに身を預けて楽な姿勢で仕事しています。 あと、体の正面が空くので、資料を置いたり時計を置いたりワイヤレス充電器を置いたりできて便利です！ お気に入り: スピーカーとイヤホンの同時接続 スピーカーとイヤホンから同じ音を流していて、スピーカーの音量つまみを操作するだけでMTGに対応できるのがお気に入りです！ MG10XUはWin機とMBPでマイクやスピーカーを共有するために使っています。 フリーコメント 推しに囲まれて仕事するのたのしいです 05. エンジニア うっひょいさん 在宅環境の様子を教えてください 開発者自身の筋肉のスケールアップ、体の軽量化を行った *6 。 Before After 逆立ちしながら考えている様子 Before 驚異の-8.2kg! 推したいポイント、改善したいポイント 在宅開発環境で推したいポイントとしては僧帽筋と三角筋です。日々の自重トレーニングによって、僧帽筋や三角筋を鍛え上げ、長時間デスクワークをしても肩こり知らずです。 また、三角筋や体幹を鍛えればコーディングのときの実装で悩んだときは逆立ちしながら考えることが可能です *7 。 在宅開発環境で改善したいポイントとしては腸腰筋です。デスクワークのときの眠気覚ましにVシットや逆立ちをやってるのですが、腸腰筋が弱いので安定しなくて困っています。 06. エンジニア組織開発 @kfly8 さん 在宅環境の様子を教えてください 200cmの机をDIYして使っています。 夫婦で並んで作業するだけでなく、子供もお絵描きをしたりして気に入っています。 子供は横並びになったり、向かいに座ったりと好きなところに座ります。 1年が経ち、次の点を変えました。 腰が痛かったので、セイルチェアに変えた。デザインも生活空間にあっても違和感なし。最高。一脚は会社から譲渡してもらった。 机の角が痛かったので、削った。娘が楽しそうにヤスリがけをしていた。 ディスプレイ背面、モニターアーム、ケーブル類を、スプレーで黒塗りをした。 最近は、モバイルプロジェクターのAnkerのNebula Capsule IIを購入して、子供が動画を観るのにはかどっています。左右の台形補正が入ったら、嬉しいなーと思う人生を過ごしています。 みかんは「愛媛まどんな」という品種で、美味しい 元々は白いディスプレイ背面、アルミ色のモニターアームでした。塗りました。 モバイルプロジェクターで動画を選んでいる様子 推したいポイント、改善したいポイント 正直、塗装は酔狂な人がすると思っていました。ですが、スプレー缶数本で生活環境に統一感を出せるので、非常にコスパが高く合理的。 買い換えるコストと比較したら、「いい仕事をした」と妻に褒めてもらえました。 ※塗装は自己責任でお願いします。 フリーコメント 塗装風景はコチラです。趣味が活かせて良かったです。 https://twitter.com/kfly8/status/1343786958313594880 07. 採用担当 @overallfactory さん 在宅環境の様子を教えてください ◆ディスプレイ ディスプレイは、もともと持っていたLGのモノと会社から譲り受けたDELLのモノを使用しています。採用の仕事柄Slackやメールをすることが多いため、ディスプレイの一つは縦型にしています。 ◆机 机はリモートワークスタート共にFlexiSpotのスタンディングデスクに変更しました。眠くなったら立って仕事をしています。 ◆キーボード 机にモノを増やしたくない+浅いストロークのキーボードが好みということで、Magic Keyboardを利用しています。ただ、キーボードに傾斜が欲しかったので、裏にキーボードスタンドを取り付けています。 ◆配線 一日中家にいると、机や床が汚れるスピードがとても早いです。 毎日掃除をしたい人なので、コードやティッシュ、文房具などは全て浮かせるようにしています。浮かすは正義です。 ◆ライト 会議や面談でテレビ電話をすることが多いので、デスクライトを買いました。 机の上のモノを増やしたくなかったので、USB給電でディスプレイ上につけられるライトを選択。 また、家でON／OFFを切り替えるのが得意ではないため、仕事の時と休憩の時で色を変えられるものを選びました。 推したいポイント、改善したいポイント 二点あります。 一つは照明へのこだわりです。 ライトの色で自分はON／OFFを切り分けています。 ONの時は昼白色、OFF時は電球色にして過ごしています。 もう一つは部屋から色を無くしたことです。 集中力が増すように、デスク周りはもちろん、家にある家具（カーテン、絨毯、小物）を全て茶色か白黒に変えました。 08. エンジニア @odan3240 さん 在宅環境の様子を教えてください 開発の作業はMacBook Pro と31インチのディスプレイがメインです。この31インチのディスプレイは会社の移転に伴い、昔会社で使っていたものを抽選で譲ってもらいました。基本的には MacBook Pro でコードを書いて、ディスプレイは Slack の周回、ブラウジング、コードリーディングに使用しています。 机は Amazon で横幅120cmのものをポチって使っています。FlexiSpot も検討したのですが、昇降機能は MUST ではないと考えてこちらにしました。 椅子は最近セイルチェアを購入しました。これは椅子について詳しくないため、会社で使用していて座り心地が良かったので同じセイルチェアに決めました。 Before After 推したいポイント、改善したいポイント 推したいポイントは31インチのでディスプレイです。サイズが大きいため左右に分割してブラウザと Slack を開いていることが多いです。1枚のディスプレイで実質2枚分の働きをしてくれるのが良いところです。 改善したいポイントは机と配線です。 机を購入した当時は立って作業することはなかったので、昇降機能は MUST ではないと判断しました。しかし実際に机を使用しているうちに高さではキーボードのポジションに違和感を覚えるようになりました。なので次机を購入するときは FlexiSpot などの昇降機能が付いているものを検討したいです。 また配線はちょっとぐちゃぐちゃしているのをなんとかしたいです。HDMI の分配器など机の下に隠せるものはいくつかあるんですが、ゲームのイヤホンのコードなど、どうしても有線で繋ぐ必要があり机の上に配線を置く必要があるものを、いい感じに整理したいです。 フリーコメント 左の一回り小さいディスプレイはゲーム用です。お昼休みや退勤後即ゲームができる環境が整っています。息抜きも大事です。 Ex. @NortonSam1 さん 前回の記事で異色の存在感を放っていた @NortonSam1 さんは惜しくも先日退職されましたが、特別に回答していただきました! 今回はどのようになっているのでしょうか……? 在宅環境の様子を教えてください 職が変わり自宅での作業が皆無となった現在、転居先の住居は食事睡眠入浴以外の用途を果たさなくなりました。その結果荷ほどきもろくにせず、段ボールはそのまま簡易テーブルに早変わり。されど前回デスクの役割を果たしていたアイロン台は依然として健在です。 Before After 推したいポイント、改善したいポイント 気に入っているポイントは特にありません。エアコンをつけるとくしゃみが止まらなくなるので転居先を探しています。強いてあげるならば山が近いことでしょうか。最近は仲良くなった地域住民に空き家を譲ってもらおうと頑張っています。 どんな変化があったか教えてください 職が変わりました。現在は木こり見習いとして活動しています。椎茸栽培にも手を出しています。夏にはわな猟の免許を取得します。昨日は乗っていた軽トラックの後輪が走行中に外れて田んぼにすっとんでいきました。 おわりに ここまで読んでいただきありがとうございました! 「仕事しやすい」から一段先のこだわりが見えてきて、1年前よりも更に個性が出てきたように思います。それぞれ違う最適な環境を作り上げていけるのはリモートワークならではの醍醐味ですね。 モバイルファクトリーに働き方についてさらに詳しく知りたい方は下記のサイトからどうぞ！ 在宅環境こだわる方もこだわらない方も募集中です♪ まずは気軽にお問い合わせください。 recruit.mobilefactory.jp *1 : 本当にこう書いてありました。違うのに! *2 : 当然HJKLです *3 : デカールシールというそうです *4 : 実際に聞いたところ非常に音質がクリアで良かったです *5 : ここ2年の新卒の方は特に実家からリモートワークしている方が多いようです *6 : これも広い意味では在宅環境の様子ですね!!!!! *7 : タイピングも逆立ちしながらするのでしょうか

こんにちは。ブロックチェーンチームのソフトウェアエンジニアの id:odan3240 です。 この記事では昨年の9月から社内で取り組みを続けているフロントエンドランチ会について紹介します。 フロントエンドランチ会とは 第2木曜と第4木曜のランチの時間 (13:00-14:00) にフロントエンド技術に興味がある有志のメンバーがオンラインで集まってランチする会です。 この会の目的は以下の通りです。 フロントエンドに関する技術の情報交換 フロントエンドに興味がある人の親睦を深める この会で実際に行っていることは以下の通りです。 13時頃にみんなぼちぼち集まってくる その日のファシリテーターを2人決める ファシリテーターは約30分で交代する ファシリテーターの画面を共有しながら JSer.info の最近の記事を開く ファシリテーターが記事の内容を読み上げつつみんなで深堀りしていく わからない単語/概念はないか？ 実際に仕事に活かせそうか？ 企画しようと考えたきっかけ 物理出社時代のランチでの雑談の再現 東五反田オフィスには「リフレッシュルーム」と呼ばれるランチを食べるための部屋がありました。そこで相席になったエンジニア同期とゆるいテックトークをするのが当時の楽しみでした。しかし昨年の2月からのリモートワーク化に伴いこの時間が失われてしまいました。 なんとかゆるいテックトークを会社の人とオンラインでやりたいという気持ちを抱えて半年が過ぎていました。 他社のフロントエンドランチにあこがれて ゆるいテックトークで思い出したのはサイボウズさんのフロントエンドランチ 1 でした。自分がこの催し物を知ったのはコロナ禍以前で、参加者の方が Twitter でその様子を実況しているのを見て、「羨ましい」「いつか参加してみたい」などと考えていました。この理由としてはお互いの知見を広げられることや単に自分がテックトークをするのが好きだからです。 このときはもし転職するならこういう文化がある会社が良いなぐらいの気持ちでした。しかし上記のランチでのテックトークをオンラインで復活させたいというモチベーションと掛け合わせたときに、文化がある会社に行くより今いる会社で文化を作るほうが面白いという考えに至りました。 この流れがあり、去年の9月にフロントエンドランチ会を企画することにしました。 実際の様子 2021-07-08 に開催されたフロントエンドランチ会の様子を紹介します。 この日は 2021-07-06のJS: TypeScript 4.4 Beta、immutable-js 4.0.0-rc.13、petite-vue - JSer.info をみんなで読みました。このときのサマリーを紹介します。 TypeScript 4.4 beta の useUnknownInCatchVariables は顧客が求めていたものと言う話になりました imutable-js は OSS の運用周りでなにかあったらしい 大変そう 最近だと immer をよく聞くよね 社内で Vue.js を採用しているプロダクトが多いため petite-vue に関心が集まった HTML の構文に違反しないように v-effect が新しく導入されたのでは コミットログを見返すと Evan You が約1週間で petite-vue をフルスクラッチから実装していてやばい actions/setup-node にキャッシュ機能が入ったのは便利そう ただ actions/setup-node の存在と UNIX 哲学ことを考えると諸説あるのでは The State of WebAssembly 2021 について The State of Hoge を見ると年末感出るけどまだ6月ｗ やっぱ Rust が多いよね polyfill とは別に ponyfill という概念があるんだ 実際にフロントエンドランチ会を開催してみた感想 第一に企画当初の狙い通り、定期的にフロントエンド技術についてキャッチアップすると技術的な雑談をする時間を確保できたのが嬉しい点でした。 企画当初には考えてなかった嬉しい点もありました。それは会社に入ってきた新しいメンバーとの交流の場にもなった点です。会社のフルリモートワーク化に伴い別のチームのメンバーとの交流の機会が減る中で、チームを超えた交流が促進されました。 運営で心がけていること ゆるく継続して開催することと、参加者の意見を取り入れて内容をブラッシュアップすることを心がけています。 ゆるく継続して開催するために、ファシリテーターを交代制にすることと、開催頻度を隔週にしました。ファシリテーターを交代制にすることで主催者である自分自身の負荷を軽減しています。開催頻度については、毎週開催にすると「木曜日はフロントエンドランチ会」という固定概念とともに参加に対する義務感が生まれてしまうのではという懸念から隔週にしています。 また参加者の意見を取り入れるために、開催初期は 表明じゃんけん を使って最後に参加者に良かった点と改善点の声を募るようにしていました。この結果記事に対する深堀りの方針として「実際に仕事に活かせそうか？」という視点が追加されました。 終わりに フロントエンドランチ会の概要、企画のきっかけ、実際の様子を紹介しました。フロントエンド技術のキャッチアップだけでなくチームを超えた人との交流も促進されるため個人的な満足度は高くおすすめの取り組みです。 サイボウズのフロントエンドエキスパートチームの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ ↩