Vue3 へのアップデートでハマったこと3選

Vue3 へのアップデートでハマったこと3選
Vue3 へのアップデートでハマったこと3選

People illustrations by Storyset

こんにちは、開発チームでエンジニアをしている和田です。

最近は担当しているプロダクトのフロントエンドを Vue2 から Vue3 にバージョンアップを行うタスクを任され、なんとか本番リリースができました🙌

自分自身、ライブラリやフレームワーク全体のバージョンアップは初めてでもあり、チームとしてもかつてない規模の変更だったため、大仕事でした😭

そのような背景もあり、今回は Vue3 へのバージョンアップでハマったことを 3 つほど紹介させていただきます。

背景・目的

Vue3 へのバージョンアップ作業でハマったことの備忘録です。
Vue3 へのバージョンアップに取り組む方の参考になれば嬉しいです。

前提条件・コンテキスト

自身が担当していたプロジェクトは Vue2 で作られており、Options API と Composition API のそれぞれで書かれたコンポーネントが混在している状況でした。 Composition API の導入が決まってから少しずつ Options API からの書き換えを行ってきた途中で Vue3 へのバージョンアップを行ったという背景があります。


Vue3 のバージョンアップでハマったこと3選

1. リアクティブな値が取得できない

原因: 構文書き換え時の .value のつけ忘れ

Vue3 へ書き換えが完了した直後、期待しない動作を示すほとんどの原因が .value のつけ忘れでした。 Vue3 から Vue を学習されている方は馴染みが無いかもしれませんが、Vue2 の Options API ではリアクティブな値を次のように定義します。

<script>
  export default {
    name: "TestComponent",
    data() {
      return {
        fruits: [],
      }
    },
    computed: {
      apples() {
        return this.fruits.filter(fruit => fruit === "apple");
      }
    }
  }
</script>

一方で、Vue3 Composition API では次のように記述します。

<script>
  export default defineComponent({
    name: "TestComponent",
    setup() {
      const fruits = ref([]);
      const apples = computed(() => fruits.value.filter(fruit => fruit === "apple"));

      return { fruits, apples };
    }
  })
</script>

Vue3 ではリアクティブな値には .value をつけて値の参照を行うため.value をつけずに処理すると当然、不具合が発生します。 computed を使用している値も .value が必要となるため、記述忘れによる不具合が開発中によく見られました。

Vue3 書き換えの際は TypeScript を導入しておらず、これらの記述ミスがあったとしても一見、問題なく動作するように見えます。 結合テストでしっかりチェックしないと気づかない場合もあるので侮れないですね😬


2. ref 属性から子コンポーネントのメソッドが実行できない

原因: ref 属性に記述したリアクティブな値を return していない

次に子コンポーネントのメソッドがなぜか実行できないという問題に遭遇しました。
結論として、子コンポーネントのメソッド実行のために ref 属性に記述するリアクティブな値を return していないことが原因でした。

Vue2 で Composition API を使用する場合、下記のように記述して子コンポーネントのメソッドを実行していました。

<template>
  <ChildComponent ref="refChildComponent" />
</template>

<script>
  export default defineComponent({
    name: "ParentComponent",
    setup(props, context) {
      const doChildMethod = () => {
        context.refs.refChildComponent.childMethod();
      }

      return { doChildMethod };
    }
  })
</script>

一方、Vue3 Composition API では次のように記述します。

<template>
  <ChildComponent ref="refChildComponent" />
</template>

<script>
  export default defineComponent({
    name: "ParentComponent",
    setup() {
      const refChildComponent = ref(null);
      const doChildMethod = () => {
        refChildComponent.value.childMethod();
      }

      return { refChildComponent, doChildMethod };
    }
  })
</script>

context.refs を使って refChildComponent にアクセスできなくなったため、子コンポーネントref 属性に記述した名称と同じリアクティブな変数を定義してあげる必要があります。
さらに子コンポーネントのメソッドを実行するには refChildComponentreturn させないといけません。

Vue2 Composition API では return の記述が必要なかったため盲点でした。
新しく Vue3 でコンポーネントを作るような状況であれば、このような見落としは生じづらいかもしれませんが、大量の書き換え作業の中ではやはり抜け漏れがあると疑った方が良いですね。

この問題が発見しづらい要因として、ref 属性に記述した値は文字列であるということも挙げられます。 例えば下記のように子コンポーネントprops に変数を渡す場合、その変数が return に記述されていないとエラーが出ます。

<template>
  <ChildComponent :title="refChildComponent" />
</template>

<script>
  export default defineComponent({
    name: "ParentComponent",
    setup() {
      const title = ref("")

      return { title }; // ここに title を入れないとエラー
    }
  })
</script>

先程の ref 属性の例ではこのようなエラーは表示されないので、一見問題ないように見えてしまうわけですね... 恐ろしい...😱


3. this の残骸によって処理が走らない

原因: Options API の this を消し忘れている

最初の Vue2 Options API の例にも示したように、Options API ではコンポーネントで定義されたメソッドやリアクティブな値を使用すときは頭に this を付ける必要がありました。
Composition API になってからは this の記述は不要になったのですが、Composition API に書き換えるときに Options API の残骸の this が、残っていても警告が出ないパターンが存在します。

<script>
  export default defineComponent({
    name: "TestComponent",
    setup() {
      const doFoo = () => {
        doHogeHoge();
        this.doBar(); // 意図しない this が紛れ込んでもエラーが見えない
        doFugaFuga();
      }
    }
  })
</script>

幸いなことに自分が担当しているプロダクトでは this を使用している箇所は限定的なため見つけるのは簡単でしたが、開発中にエラーとして出てくれないのはやはり怖いです。


この問題に今後どう向き合うか?

今回、紹介したハマった箇所3つはいずれも開発中に見落としがちになるものばかりでした。
結合テストでほとんどの問題を発見するに至りましたが、できればテストを実施する前の段階で見つけたいです。型チェックによって防げるものも多いので TypeScript を導入すれば、より安全に開発を進めることができるかもしれないですね。

とはいえ、Vue2 から Vue3 への大規模なアップデートのタイミングで TypeScript を入れるのもハードルが高いかもしれないので導入のタイミングは検討する必要があります。


まとめ

最後まで読んでくださりありがとうございました 🙇‍♂️
紹介させていただいたハマった点はいずれも初歩的なものです。普段なら間違えないような作業も、大量の書き換え作業の中で埋もれてしまって気づかないということを教訓として得ました。

改めてこの記事が Vue3 へのバージョンアップに挑む開発者の参考になれば嬉しいです!

コミュニティ・リソース・参考文献

【初心者】JavaScript のカウンターの書き方。色々な書き方から無限の学びを得る。

【初心者】JavaScript のカウンターの書き方。色々な書き方から無限の学びを得る。
【初心者】JavaScript のカウンターの書き方。色々な書き方から無限の学びを得る。

Work illustrations by Storyset

こんにちは、開発チームでエンジニアをしている和田です。
最近は担当しているプロダクトの開発メンバーが入れ替わったりとバタバタしている毎日です🏃‍♂️

いろんな開発メンバーがいると十人十色のコードが生まれます。また、自分自身に焦点を当ててみても過去の自分と今の自分では書き方に差があるはず... なんて哲学的なことを考えていると、一つの処理を様々な書き方で書いてみたくなりました(どうゆうことやねん笑)

というわけで今回は JavaScript 初心者の方向けにカウンターのいろんな書き方を簡単に紹介させていただきます。

JavaScript でカウンターをいろんな書き方で書いてみる

変数を使ったカウンターの書き方

まずは最も簡単な変数を使った書き方です。

let counter = 0;

for (let i = 0; i < 10; i++) {
  console.log(counter++);
}

console.log(`counter: ${counter}`);
console.log(`counter: ${counter}`);
0
1
2
3
4
5
6
7
8
9
counter: 10
counter: 10

プログラミングを最初に学んだときのループ処理などでよく見る例ですね。
ループの中では最初に counter 変数に入っている値をコンソールに表示した後にインクリメントを行います。 当然、ループを抜けた後の counter 変数の中身は常に 10 となります。

関数のプロパティを使ったカウンターの書き方

プロパティと聞くとオブジェクトをイメージされる方が多いかもしれません。
JavaScript では関数は特殊なオブジェクトとして定義されているので、関数の宣言を行っていればオブジェクトのように . でプロパティの値を操作することができます。

const uniqueInteger = () => uniqueInteger.counter++;
uniqueInteger.counter = 0;

for (let i = 0; i < 10; i++) {
  console.log(uniqueInteger());
}

console.log(`counter: ${uniqueInteger.counter}`);
console.log(`counter: ${uniqueInteger.counter}`);
0
1
2
3
4
5
6
7
8
9
counter: 10
counter: 10

uniqueInteger 関数の返り値に uniqueInteger.counter++ とすることで、uniqueInteger 関数の counter プロパティの値を返してからインクリメントを行います。
関数を宣言した時点では counter プロパティには何も値が入っていないので、宣言の前後で uniqueInteger.counter = 0; という初期化が必要となります。 ループの中のみで関数を実行しているので、ループの外では現在格納されている値を呼び出すことができます。
カウンターの値を初期化するのが少し手間ではありますが、「どの関数を何回実行したか?」が強調された書き方です。

即時実行関数とクロージャを使った書き方 その1

即時実行関数やクロージャと聞いて馴染みのない方もいるかも知れません。
まずはサンプルコードを確認しましょう。

const uniqueInteger = (() => {
  let counter = 0;
  return () => counter++;
})();

for (let i = 0; i < 10; i++) {
  console.log(uniqueInteger());
}

console.log(`counter: ${uniqueInteger()}`);
console.log(`counter: ${uniqueInteger()}`);
0
1
2
3
4
5
6
7
8
9
counter: 10
counter: 11

uniqueInteger は即時実行関数、すなわち宣言した直後に実行される関数なのでuniqueInter にはcounter++ という処理をもつ関数が格納されています。
したがってuniqueInteger() として実行すると counter をインクリメントした結果を返してくれるわけです。 ポイントとなるのはuniqueInteger 関数の counter 変数の値を直接、確認することができない点です。
今回の書き方は、これまでとは異なり、ループ後の値を保存しておきたい場合は専用の変数を設けるなどする必要があります。

【補足】即時実行関数で書かないとどのような結果になるか?

これまでのサンプルに対する理解を深めるためにあえて uniqueInteger を即時実行関数ではなく、ただの関数として実行してみます。

const uniqueInteger = () => {
  let counter = 0;
  return () => counter++;
};

for (let i = 0; i < 10; i++) {
  console.log(uniqueInteger()());
}

console.log(`counter: ${uniqueInteger()()}`);
console.log(`counter: ${uniqueInteger()()}`);
0
0
0
0
0
0
0
0
0
0
counter: 0
counter: 0

uniqueInteger 関数からは () => counter++ という関数が返されるので、実行時は uniqueInteger()() と少し変わった書き方をしてあげる必要があります。この場合、実行結果はループがあってもなくても 0 となります。これは関数が呼び出されるたびに counter 変数が counter = 0 として初期化されるためですね。一方で即時実行関数は宣言した後すぐに実行されるため、その後も uniqueInteger 関数内の counter 変数を初期化せずに参照し続けます。このような違いがあるため即時実行関数とクロージャを使うとカウンターとして機能するわけです。

即時実行関数とクロージャを使った書き方その2

関数のプロパティを使った書き方では、関数名とプロパティ名を . で繋ぐことで「どの関数を何回実行したか?」がわかりやすく書かれていました。 即時実行関数・クロージャでも同様の表現で記述することができます。

const uniqueInteger = (() => {
  let counter = 0;
  return {
    current: () => counter,
    counter: () => counter++,
    reset: () => (counter = 0),
  };
})();

for (let i = 0; i < 10; i++) {
  console.log(uniqueInteger.counter());
}

console.log(`counter: ${uniqueInteger.current()}`);
console.log(`counter: ${uniqueInteger.current()}`);
console.log(`counter: ${uniqueInteger.counter()}`);
console.log(`counter: ${uniqueInteger.counter()}`);
console.log(`counter: ${uniqueInteger.reset()}`);
console.log(`counter: ${uniqueInteger.counter()}`);
console.log(`counter: ${uniqueInteger.counter()}`);
0
1
2
3
4
5
6
7
8
9
counter: 10
counter: 10
counter: 10
counter: 11
counter: 0
counter: 0
counter: 1

先程の記述方法と異なっているのは uniqueInteger 関数の返り値がオブジェクト形式になっている点です。

さらにオブジェクトのそれぞれのプロパティの値は関数となっているため uniqueInteger.current() とすれば現在のカウンターの値を取得することができ、uniqueInteger.counter() でこれまで同様にインクリメントすることもできます。
また uniqueInteger.reset() とすることでカウンターの値をリセットすることもできます🙌

これまでのサンプルコードのいいところを全部詰め込んだコードですね。

どのカウンターがベストプラクティスか?

カウンターの処理1つとってもこれだけたくさんの書き方ができます。
では、どの書き方がベストプラクティスと言えるでしょうか?

答えは「時と場合による」です😇

とても簡単な処理では、最後の多彩な機能が盛り込まれたカウンターよりも最初の単純な変数によるカウンターの方が簡潔で理解もしやすいです。 チームや必要とされる機能などによって、どのような書き方が最適なのか?というのは常に変わるものなのでいろんな書き方を覚えておくのが良いかもしれませんね。


まとめ

最後まで読んでくださりありがとうございました🙇‍♂️
ただのカウンターの処理をいろんな表現で書かかせていただきました。
ライブラリから提供されている関数やメソッドにも今回紹介した書き方で実行するようなものが見られます。カウンターに関する知識だけでなく、今回紹介した内容がコードを読み進めるときに役に立つことを願っています🙏

技術ブログを運営してきた半年間の試行錯誤

技術ブログを運営してきた半年間の試行錯誤
技術ブログを運営してきた半年間の試行錯誤

こんちには、N2i Tech Blog が半年続いていることに感動している編集長の和田です。
いやぁ年末ですね🎄 この N2i Tech Blog は 2023年5月に正式に始動して以来、毎週欠かさず投稿を続けて来ました。 少ないながらも本記事の執筆時点では既に30記事以上を皆で投稿しています。

今回は普段の記事とは趣向を変えて、Tech 系の企業の技術ブログ運営をされている方向けに Tech Blog を継続してきた工夫や反省について述べさせていただきたいと思います。

技術ブログをこれから運営する予定の方にも参考になればと思いますので、最後まで読んでいただけると嬉しいです🙏

N2i の技術ブログの運営体制

工夫や反省について述べる前に、N2i の技術ブログの運営体制について簡単に紹介させていただきます。

運営メンバーについて

まず、運営としてコアメンバーとして動いているのは和田(筆者)と岡部の2名で記事の管理や N2i Tech Blog の運営方針などを決めています。両者とも普段はエンジニアとして作業しており、業務の合間の時間で当ブログの運営を行っています。

執筆メンバーについて

執筆者は運営メンバーはもちろん社内のエンジニア全員(PMやEMも含む)を対象としており、各人に決められたノルマなどは設けておらず自由に投稿していただいています!

執筆していただいた記事は専門領域の開発メンバーと我々、運営メンバーが校閲し、記事を公開するような流れです。

技術ブログ運営の目的

N2i Tech Blog のチームとしての目標は「エンジニアが自発的に技術発信をする文化を作ること」です。

学んだことを自分からアウトプットして各々が切磋琢磨しているチームは素敵ですよね。N2i をそんな組織にしたくて技術ブログを運営しています。

ここまでが N2i Tech Blog の運営体制・目的の簡単な説明です。次に半年ほど毎週投稿を行うに当たって工夫したことについて説明させていただきます。


技術ブログの運営に当たって工夫したこと

技術ブログの運営に当たって工夫したこと
技術ブログの運営に当たって工夫したこと

People illustrations by Storyset

様々な方々に支えられながら継続できている N2i Tech Blog ですが、継続のために色々と工夫をして参りました。 その中で特に継続の工夫として効果があったと感じることを3つ紹介させていただきます。

1. 投稿の目標宣言をする

幸いなことに毎週の事業部全体ミーティングの中で当ブログの活動を発表するための時間を設けていただいています。 その中で「毎週1記事必ず投稿する」ということを口酸っぱく言い続けてきました。

宣言し続けたがゆえに逃げ道のない状況となり、筆者自身の編集長としての責任も相まって本当に毎週1記事投稿できています。 非常に単純なことではありますが、発足以来この指針をぶらさず徹底してきたのは我々 N2i Tech Blog チームの誇りです👍

工夫というより精神論的なものかもしれませんが、個人的に最も継続のために効果があった行動だと思っています。

2. 頑張り過ぎない低燃費スタイル

「毎週1記事必ず投稿する」の裏返しでもあるのですが「週1記事以上は投稿しない」ということも大切にしてきました。 たくさんの方が執筆してくれた週は嬉しくなって投稿を早まる気持ちもありました。しかし、すぐに投稿はせずに現状のペースを保つことを心がけました。

週1記事すなわち毎月4記事の投稿が目標となるため、その分達成のためのハードルも低くなって無理なく継続できたと思います。 ちょっとした時間に一気に2記事も書いてしまえば、後は書いてくれそうな人を二人くらい見つければ目標達成といった具合です。

あえて目標を小さく設定したのは方針として良かったと感じています。

3. 記事のジャンルにこだわらない

N2i Tech Blog の記事を見ていただくと分かるように、サンプルコードが記載されたいかにも技術ブログらしい記事から社員へのインタビュー・書籍の紹介記事など、さまざまな記事を投稿してきました。

techlog.n2i.jp

techlog.n2i.jp

techlog.n2i.jp

技術ブログとして運営する以上は、技術に関する専門的な内容を主軸として投稿をしたいのが正直なところではあります。しかしながら、ブログ運営の初期の指針としてはジャンルよりも継続と量が大切であると考えたため、あまり制限を設けずに投稿してきました。

技術に関連している・業務に関連した学びがあるという条件に少しでも当てはまっていれば投稿してきたのは良い選択だったと思っています。


ここまでが運営にあたって工夫してきたことです。特別な仕組みやシステムを設けているわけではありません😅
一方で運営を継続するにあたってあまり効果を感じられなかった施策もあります。当ブログの運営にあたって失敗したと思われる施策についても紹介させていただきます。


技術ブログの運営で効果のなかった施策

技術ブログの運営で効果のなかった施策
技術ブログの運営で効果のなかった施策

Sport illustrations by Storyset

  • 記事ネタがない
  • 書き手が見つからない

これら2点はどこの企業ブログでも抱える問題ではないでしょうか?
N2i Tech Blog でも同じ問題を未だに抱えているわけです...
それらを打開するために試行錯誤したもののあまり効果の感じられなかった施策を3つほど紹介させていただきます。

1. 記事のテンプレートを用意するも使う人がいない

開発メンバーのほとんどが技術記事の執筆経験がなく、最初の記事を書くハードルが高い状況でした。
そこで下記のような記事の骨組みとなるようなテンプレートを設け、できる限り楽に記事が書けるような環境を整えることを考えました。

<!-- 
記事のタイトル例
- 「新しいエディター〇〇を試してみました」
- 「なぜ Mac で開発するのか?」
- 「最近流行りの〇〇ターミナル使ってみた件」
-->


## 背景・目的

<!-- 記事の目的や背景を説明し、読者に対して何が提供されるかを明確にする。 -->

### 対象読者

<!-- 記事の対象となる読者層や必要な事前知識を明示する。 -->

### 開発ツール・環境の概要

<!-- 関連する開発ツールや環境の主要な機能や特徴を紹介。 -->

### 主な機能と特徴

<!-- 関連するプログラミング言語やフレームワークの主要な機能や特徴を紹介。 -->

### インストールと環境設定:

<!-- 開発ツールや環境のインストール方法と環境設定手順について説明。 -->

---

## 実践内容

<!-- サンプルコードや実践例を用いて、プログラミング言語やフレームワークの使用方法を紹介。 -->


### 自分の意見・ベストプラクティス

<!-- 実践内容を通じて思ったことや意見。効率的で安全な開発のためのベストプラクティスや推奨されるコーディングスタイルを紹介。同じ目的を持つ代替ツールとの比較を行い、選定したツールのメリットやデメリットを説明。 -->

---

## まとめ

<!-- 記事の内容を要約し、読者が得た知識をどのように活用できるかを強調。 -->


### コミュニティ・リソース・参考文献

<!-- 関連するドキュメント、チュートリアル、ブログ、フォーラム、コミュニティなど、さらなる情報を得るためのリソースを紹介。 -->

毎週の定例ミーティングの中で上記のテンプレについて周知するものの執筆者が増えるわけでもなく、執筆してくれた方はテンプレを使わずに書いてくださったので効果が感じられなかったです😅

自主的に書ける人はスラスラと筆が進むし、そうでない人は別のところに障壁がありそうです。

今は書き方以前に「何を書くか?」に困っているのでは?というところに着目し、「私の作業環境シリーズ」などといった誰でも書きやすいようなテーマを設けて検証しています。

2. 記事の代筆アピールも効果なし...

開発チームのメンバーは各々がタスクに取り組んでいるため、単純に記事を書く時間がないというのが現実です。 当然、ブログの運営メンバーもエンジニアとしてタスクに取り組んでいるため、業務に支障のない範囲で活動をしています。

開発チームが執筆してくれるメンバーのタスク量をコントロールすることは難しいので

「普段の業務中の学びや作業メモを箇条書きにしたものを投げてくれればこちらで記事にしますよ〜」

...などとアピールしましたが、特に効果は得られませんでした。


この記事の執筆時点では「N2i Tech Blog に記事を投稿して何が得られるか?」という書き手側のメリットを示せていないため、執筆するメンバーが記事を書きたくなるような仕組みづくりが必要なのかもしれません。

3. 月に4記事という頑張ったら一人でもなんとかなる目標設定

冒頭でもお話した通り、週に1記事つまりは月に4記事程度書くことを当ブログの目標にしています。
この施策自体は失敗とは思っていませんが裏目に出たことがあります。

それは投稿するメンバーが固定化されてしまうということです。

正直なところ月に4記事だったら一人でもなんとか書けてしまうため、数名のメンバーが執筆してくれれば目標を達成するのは難しくありません。結果として誰かが書かなくても目標が達成されるという状況が生まれてしまい、メンバーが固定化されるという事態に陥りました。

「エンジニアが自発的に技術発信をする文化を作ること」が目標なので、可能なかぎりいろんな人に記事を書いてもらいたいと思っています。しかしながらメンバーが固定化されているのは、目的から遠ざかっているようで悲しいですね🥲


まとめ

最後まで読んでくださりありがとうございました🙏

効果の感じられなかった施策に対する代替案は今のところありませんが、このままのペースで記事数を増やしていこうというのが今の方針です。

この記事がこれから技術ブログを運営する方や技術ブログを運営されたばかりの方の参考になることを願っています。

この記事を読んで「エンジニアが自発的に技術発信をする文化を作ること」を実現するためのアイデアが思いついた方はぜひ N2i Tech Blog チームにご連絡ください🙏

【私の作業環境】N2i のエンジニアリングマネージャー吉野さんのデスクを覗いてみた!

私の作業環境

こんにちは、N2i Tech Blog 編集長の和田です。
エンジニアのみんなの作業環境について紹介していくシリーズ「私の作業環境」😆

物理的な環境・お気に入りのツール・ワークフローなんでも構わず社員のみんなのこだわりポイントを紹介させていただきます。
今回はエンジニアリングマネージャーの吉野さんです!


今回、紹介する吉野さんのデスクはこんな感じ👀

吉野さんの作業環境
吉野さんの作業環境

美しいですね。
筆者自身、音響機器には決して詳しくないですが、オーディオにこだわりを感じるデスクですね✨
使用されている機材も教えていただきました!

  • モニター: BenQ EX270QM
  • キーボード: HHKB Professional Type-S
  • マウス: Kensington Expert Mouse
  • マイク: RODE NT-USB Mini
  • カメラ: LOGICOOL C980GR
  • ドッキングステーション: CalDigit TS3 Plus
  • USB-DAC: FiiO K3ES & Fostex PC100USB
  • アンプ: Marantz HD-AMP1
  • スピーカー: Wharfedale DIAMOND 210

キーボードはエンジニア御用達の HHKB のハイエンドモデル👍
たくさんの機材を使用していながら、この写真にキレイに収まるくらい整頓されているのがびっくりです😁

吉野さんからはこだわりのポイントなども教えていただきました!

私の作業環境のこだわりポイント

-- デスクの中で一番こだわりをもってるのはどこですか?

有線ですべて繋がっていることです!

一時期、無線化を進めていましたが、イヤホンの充電を忘れることがあったり、カメラ・マイク・キーボード・マウスは接続状況が安定せず、無線機器の機嫌に左右されてストレスを感じることがあったんですよね...😅 もう無線の機嫌問題を考えたくないと思って無線化は諦めました。

また、ほとんどが USB 切り替え機(UGREEN)を経由して繋がっていて、仕事用 PC とプライベートの PC との USB 機器の切り替えと共有がスムーズにできるのも便利に感じています。

-- おすすめの機材を1つ教えていただきたいです!

マイクがコンパクトだけど性能が良くて気に入っています。
前面の物理ボタンがミュートボタンではないところはちょっと微妙です。

-- デスクの「ここを改善したい」があれば教えていただきたいです!

CalDigit TS3 Plus の Display Port が 1.2 で HDR に対応していないため、別途 USB-C - Display Port の変換アダプタ (Cable Matters) を使っています。ここは改善したいですね。
CalDigit TS4 (CalDigit の新しいドッキングステーション) に買い換えればいいんですが、値段分の満足度を得られるんだっけ?というところでずっと迷っています...

まとめ

最後まで読んでくださりありがとうございました!
以前の田中さんのデスクはモニターが印象的でしたが、今回の吉野さんは音響機器が印象的でしたね。
配線の工夫やこだわりにも驚かされました✨

まだ前回の「私の作業環境」シリーズを読まれてない方はぜひ下記からチェックして下さい!

techlog.n2i.jp

N2i のデザイナー幸地さんにインタビュー!!

N2i のデザイナー幸地さんにインタビュー!!
N2i のデザイナー幸地さんにインタビュー!!

Designer illustrations by Storyset

こんにちは、N2i Tech Blog 編集長の和田です。 定期的に開催している N2i の社員へのインタビュー企画の記念すべき第4回目です🙌

今回はデザイナーとして開発チームを支えている幸地さんに話を伺いたいと思います。
前回のインタビュー記事を読まれていない方は、下記からぜひお読み下さい。

techlog.n2i.jp

これまでの経歴

-- 幸地さんはご出身が沖縄と聞いています。どのような経緯で名古屋に来られたのでしょうか?

高校卒業後はデザイナーを志望していました。
デザインを学べる場所を探していた時に「デザイナー」と検索して上位に表示されていたのが、名古屋のデザイナー専門学校だったんですよね。 特に深い理由があるわけではないのですが、デザイナーとして学びを得るために名古屋にやってきました。

学校卒業後、デザイナーとして働いていくうちに N2i でお仕事することになりました。


-- そうだったんですね。職種としてデザイナーを選択されたのには理由があったんですか?

当時は若かったこともあり、キャリアについては深く考えてなかったかもしれないです笑
たまに絵を書くこともあったり、Web サイトを自分で作ってみて楽しかった思い出があるので、そのような経験からデザイナーを選択したのかもしれないですね。

N2i の中では HTML と CSS に誰よりも詳しいという自信があります。


-- いやぁ、デザインに関する打ち合わせのときにいつもスタイルの知識をご教授頂いてます🙏

-- ここからはデザイナーとしてのお仕事自体について質問させていただきます!

デザイナーのお仕事について

-- 個人開発でフロントエンドを作る際にデザインで行き詰まる人も多いと思います。デザイン力をアップするにはどうしたらいいでしょうか?

いろんな方法があるとは思いますが、僕の個人的な意見としては「とりあえず作る」しかないと思いますね。
今はたくさんデザインのフレームワークがでているので、それらを利用してみるのがいいと思います。少し古いかもしれませんが Bootstrap などは有名ですよね。

本を読んで知識をつけるのも良いですが、デザインもプログラミングと同じで自分で手を動かさないことには始まらないです!


その通りですよね。ちなみに幸地さんはデザインのヒントとして、参考にしているものはありますか?

今はアプリケーションのデザインを担当させていただくことが多いので、既存のデザインをベースに進めることが多いですね。 新しくデザインを考えないといけないときは、Pinterest などのサイトを見て着想を得ることはあります。


-- 様々なデザインに触れる機会が多いと思うんですけど、最近のデザインの流行りなんかがあれば教えていただきたいです!

ここ数年で増えてきたと感じるのは、ジャンプ率の高いデザインが多くなってきたような気がしますね。
ジャンプ率とはデザインの緩急を表す言葉で、見出しと本文の文字サイズやフォントなど、比較する文字の見た目に差が大きいと「ジャンプ率が高い」といいます。
反対に見出しと本文に見た目の差があまりないようなものを「ジャンプ率が低い」といいます。


-- 言われてみれば普段、自分が見るサイトにジャンプ率が高めのデザインが多いです👀

-- デザイナーとしての仕事術をお聞きしたいです。デザインを作成する上で、オススメの仕事術だったりTipsはありますか?

デザインに限らずですが、ショートカットキーを覚えることは仕事を速くする必須項目だと思ってます。 あとは、Karabiner-Elements などのキーボードカスタマイズツールを使って自分の使いやすいキー配列に工夫することですね。

僕の場合は、Mac⌘X でデザインの切り取りを行うことが多いので Caps LockX に変更してます。
個人的にはこの配置で切り取り操作がかなり便利になりました。

自分の仕事で頻繁に行う操作をカスタマイズツールを使ってやりやすくするのはオススメですよ。


-- エンジニアと共通するところがたくさん見つかって嬉しいです🙌

-- 幸地さんはエンジニアと仕事する中で、ここはやりやすい・やりにくいと感じることはありますか?

エンジニアの方は「できる・できない」をハッキリと伝えてくれるのが、個人的にはありがたいですね。 デザインするだけではアプリケーションは作れないので、打ち合わせの中で実装上の都合は確認させていただきます。

あとはできるだけエンジニアの方にはピクセルパーフェクトを目指してほしいですね。
自分がデザインしたものを完璧に再現してくれていると嬉しく感じます。
ピクセルパーフェクトを求めるからには、デザイナー自身もコーディングの知識は持ってないといけないですね。


最後にデザイナーとしてこだわりを持ってることを教えてください!

やはり、「ユーザーストーリーに沿っているか?」という観点は大事にしています。
当たり前のことだと思うんですけど、どのようにユーザーが利用するか?といったストーリーが見えてこないとデザインは作れないです。


-- ユーザーストーリーってホント大事ですよね。何のために作るのかが見えてこないとエンジニアとしてもやりずらさを感じます。
インタビューはここまでとなります。本日はありがとうございました!!

今回はデザイナーの幸地さんにインタビューさせていただきました。
筆者自身はエンジニアとして幸地さんと一緒に仕事をさせていただいているのですが、デザイナーの目線の考え方について理解を深められる良い機会となりました🙌

【Vue 入門】業務でよく使う動的 class の切り替え方

【Vue 入門】業務でよく使う動的 class の切り替え方
【Vue 入門】業務でよく使う動的 class の切り替え方

こんにちは、開発チームでエンジニアをしている和田です。

最近は Vue2 → Vue3 の移行作業に力を注ぐ毎日です🔥

作業中に Vue の <template /> タグで class を動的に切り替えるための記述方法を何種類も目にしたため、忘れないように一覧にまとめておこうと思いました。

ということで今回は Vue で class を動的に切り替える方法を一挙に解説させていただきます。

背景・目的

Vue で動的に class を切り替える方法について学ぶこと。

対象読者

Vue の初心者。Vue の知識を深めたい開発者。


Vue で動的に class を切り替える方法一覧

1. 真偽値による class の切り替え

<template>
  <component :class="{ 'dynamic-style': isActive }" />
</template>

簡単な真偽値のみでの class の切り替えです。
isActivetrue の場合は <component /> タグに dynamic-style class が付与されます。
isActivefalse の場合は <component /> タグには class は付与されません。

2. 条件式による class の切り替え

<template>
  <component :class="{ 'dynamic-style': counter > 10 }" />
</template>

条件式による class の切り替えです。
先程の isActive 変数を条件式 counter > 10 に置き換えただけですね。
counter の値が 10 より大きければ、dynamic-style class が付与され、10 以下であれば class は付与されません。

3. 複数の真偽値・条件式の組み合わせによる class の切り替え

<template>
  <component 
    :class="{
      'dynamic-style-a': isActive,
      'dynamic-style-b': isVisible,
      'dynamic-style-c': counter > 10,
      'dynamic-style-d': fruit === 'apple'
    }" 
  />
</template>

複数の真偽値や条件式との組み合わせです。
{} の中であれば , で区切ることでそれぞれ付与したい class ごとに条件を切り替えることができます。

4. 三項演算子による class の切り替え

<template>
  <component :class="isActive ? 'dynamic-style-a' : 'dynamic-style-b'" />
</template>

三項演算子を使って class の切り替えを行う場合はこのようになります。
isActivetrue であれば dynamic-style-a が付与され、false ならば dynamic-style-b が付与されますね。

5. 関数による class の切り替え

<template>
  <component :class="generateClass(staffRoleId)" />
</template>

<script setup>
const generateClass = roleId => {
  switch (roleId) {
    case 1:
      return 'dynamic-style-a'
    case 2:
      return 'dynamic-style-b'
    case 3:
      return 'dynamic-style-c'
    default:
      return;
  }
}
</script>

単純に文字列を返すだけの関数を作成すれば、その返値を class として付与することもできます。 <template /> タグ内に複雑な条件を記述したくない場合などに便利かもしれません。

6. 複数の真偽値・条件式・三項演算子・関数の組み合わせによる class の切り替え

<template>
  <component 
    class="static-style-a"
    :class="[
      { 'dynamic-style-a': isActive },
      { 'dynamic-style-b': isVisible },
      { 'dynamic-style-c': counter > 10 },
      { 'dynamic-style-d': fruit === 'apple' },
      isSelected ? 'dynamic-style-e' : 'dynamic-style-f',
      isDisabled ? 'dynamic-style-g' : 'dynamic-style-h',
      generateClass(staffRoleId),
      'static-style-b'
    ]" 
  />
</template>

<script setup>
const generateClass = roleId => {
  switch (roleId) {
    case 1:
      return 'dynamic-style-i'
    case 2:
      return 'dynamic-style-j'
    case 3:
      return 'dynamic-style-k'
    default:
      return;
  }
}
</script>

これまでの総集編のような記述方法です。
:class=[] のように [] で囲うことで、真偽値・条件式・三項演算子・関数のすべてを組み合わせて書くことができます。 三項演算子や関数は全体が {} で囲まれた場合だと一緒に使えないため、[] の中に書くことになります。

また、この書き方だと static-style-a のような静的な class も一緒に書けます。
ただし、:class ではなく普通の class にも静的 class は書けるためわざわざ :class の方に書く必要はないかもしれません。

[] を使った書き方であれば1~5 までの書き方に全て対応できるので、これさえ覚えておけば問題はないのですが、より簡潔なコードを書けるようになるためには 1~6 すべての書き方をいつでも書けるようにしたいですね。


まとめ

最後まで読んでくださりありがとうございました!
今回は Vue で動的に class を切り替える方法一覧を紹介させていただきました。
チーム開発では様々な人が携わる分、コードの書き方も人それぞれです。
今回紹介させていただいた記述方法は、実際に筆者が携わるプロダクトで全て登場するので、しっかりと覚えておきたいです。

業務で大活躍!VScode の拡張機能20選!!

業務で大活躍!VScode の拡張機能20選!!
業務で大活躍!VScode拡張機能20選!!

Technology illustrations by Storyset

こんにちは、開発チームでエンジニアをしている和田です。

先日、開発環境の整理整頓を行っている最中にふと

「そういえば、VScode拡張機能が増えすぎたな... 掃除するか... 🤔」

と思ったので、今回はそのついでに実際に業務中に活躍している VScode拡張機能を一覧にしてまとめてみようと思います。

この記事の中で読者の方のエンジニアライフに役立つような便利な開発ツールを見つけていただけると嬉しいです🙏

以前、役に立つ開発ツールを一覧にしてまとめたのでこちらの記事もぜひ読んでみて下さい🙇‍♂️

techlog.n2i.jp

Auto Close Tag

marketplace.visualstudio.com

筆者はフロントエンドの開発では Vue のプロジェクトをよく触ります。
自動で HTML の閉じタグを補完してくれるため、楽にコーディング作業が進められます👍

Auto Rename Tag

marketplace.visualstudio.com

同じく HTML タグの補完ツール。
タグの名称を変更する際に、対応する閉じタグの名称も変更してくれます。
間違いが少なくなるので超便利です。

Trailing Spaces

marketplace.visualstudio.com

不要な空白を赤く強調してくれます。
当然、不要な空白は無い方がいいので、コードをきれいに保つために役立ちます!

zenkaku

marketplace.visualstudio.com

思わぬ不具合を招く全角文字を白く強調してくれます。
zenkakuがあれば、全角文字列がうっかり混入するなんてことはなくなります。

Code Spell Checker

marketplace.visualstudio.com

英単語のスペルミスを教えてくれます。
「動かないと思ったらスペルミスしてた😅」なんていうお決まりのミスが軽減されるので重宝してます。

Prettier - Code formatter

marketplace.visualstudio.com

有名なコードフォーマッター。コレを入れてから改行云々で悩むことはありませんね。
チームでも導入必須のプラグインです!

ESLint

marketplace.visualstudio.com

ESLint の設定で非推奨な記述をしている箇所に警告を出してくれます。
バグの原因になるような危険な書き方を未然に防ぐことができます🙌

Color Highlight

marketplace.visualstudio.com

カラーコードが記述されている箇所に実際の色(パレット)を表示してくれます。
16進数を見るだけで色のわかる超人には不要かも😂

Edit csv

marketplace.visualstudio.com

VScode 上でエクセルライクに CSV の編集ができる優れもの。
スプレッドシートやエクセルを、わざわざ開かなくてもCSVをささっと編集できます。

Rainbow CSV

marketplace.visualstudio.com

CSV データを VScode で開いたときに、カラムごとに色分けしてくれます。
簡単な編集やデータの確認をする際に便利です!

Git Graph

marketplace.visualstudio.com

Git の変更履歴を GUI で確認できます。ブランチが可視化されるので見やすくてありがたいですね。

GitLens - Git supercharged

marketplace.visualstudio.com

コードにカーソルを重ねると「いつ誰がどんな変更をしたか?」が確認できる便利ものです。
「なんだこの〇〇コード!!って思ったら自分だ...」なんていう気づきを与えてくれます😇

Markdown All in One

marketplace.visualstudio.com

マークダウンでドキュメントを書くときに VScode 上だとマルチカーソルが使えて便利ですよね。
VScode の機能をそのままに GitHub に Issue を書く感覚でマークダウンが書けちゃいます🎉

markdownlint

marketplace.visualstudio.com

マークダウンのリンターです。
Markdown All in One と併用して便利にマークダウンが書けます。

Svg Preview

marketplace.visualstudio.com

SVG ファイルを見たときに「これどんな画像だっけ??」という疑問をその場で解消できます。
画像のプレビューを表示してくれるので、 SVG に悩まされるなんてことがなくなりました。

Postman

marketplace.visualstudio.com

VScode 上で Postman の操作ができます。
リクエスト・レスポンスの確認にわざわざアプリを開かなくて良くなるのはありがたいですね。

TODO Highlight

marketplace.visualstudio.com

TODO コメントなどをハイライトしてくれます。
ところで「いつかやるべき変更」ってコメントはいつやるんでしょうか?笑

Todo Tree

marketplace.visualstudio.com

TODO コメントをサイドバーから一覧で確認することができます。
こちらの拡張機能にもハイライト機能はありますが、筆者は TODO Highlight のハイライトの方が好みなので併用しています。

ENV

marketplace.visualstudio.com

味気ない env ファイルに色をつけてくれます。
どこまでが変数名でどこまでが値なのかわかりやすくなるので便利です。

YAML

marketplace.visualstudio.com

yaml ファイルを触るときに補完や改行のサポートをしてくれます。
docker-compose.yml の作成が捗りますね。


最後に

最後まで読んでいただき、ありがとうございました🙇‍♂️

いかがだったでしょうか?

今回、紹介した他にも開発に利用している VScode拡張機能はたくさんありますが、普段の業務で特に活躍しているものを厳選させていただきました!

皆さんのエンジニアライフのお役に立てれば幸いです。