
`npx create-nuxt-app`で作ったプロジェクトにて、コンポーネントを自動インポートしようと思ったのですが、以下のエラーがでて小一時間ハマったので同じような状態の人のためにメモを残しておきます。

> [Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. Bailing hydration and performing full client-side render.

このエラーの原因は、コンポーネントの自動インポート機能を担っている[nuxt/components](https://github.com/nuxt/components)にありました。  
どうやら、つい最近[破壊的変更](https://github.com/nuxt/components/releases/tag/v2.0.0-0)があったようで、この変更の影響で「components」ディレクトリ以下のディレクトリからコンポーネントをインポートする時は、そのディレクトリ名を接頭辞としてコンポーネントへ指定しなければいけなくなったようです。

たとえば、componentsディレクトリが以下のような構造だった場合、ButtonディレクトリのPrimary.vueを使いたい時は、`<Primary>`ではなく、`<ButtonPrimary>`と指定します。

```
components/
    Button/
        Primary.vue
```

「なんでそんな変更したの」と思っている人は以下からこの破壊的変更の動機を確認できますのでどうぞ。

- [https://github.com/nuxt/components/issues/67](https://github.com/nuxt/components/issues/67)
- [https://github.com/nuxt/components/pull/81](https://github.com/nuxt/components/pull/81)

ざっくりな意訳ですが「現状だとコンポーネント名が重複した時に正しく解決されていなくて大規模ページ作る時に不便だから、ディレクトリ名を接頭辞代わりにするのはいかがかしら」と書かれています。

まあ、おっしゃる通りですね彡(^)(^)


Nuxt.jsでネストされたディレクトリのコンポーネントを自動インポートした時にでるエラーの対処法


みなさんこんにちは。
[`position: sticky;`](https://caniuse.com/css-sticky)とoverflow系のプロパティを組み合わせて使ったとき往々にして発生する*要素が意図した位置に張り付かなくなってしまう挙動*は、いささか分かりづらい点があるためこれに頭を抱えたことがある人は多いことでしょう。

そのため今回の記事では先の挙動がなぜ起こってしまうのか、その理由を記していこうと思います。

## 結論

`position: sticky;`を付与している要素が開発者の意図しているscroll containerに属していないため、先の挙動が発生していると考えられます。

この時点で理解された方はこの先の文章は蛇足と感じるかもしれません。逆に疑問符が頭上に浮かんだ方はこの先で記す`position: sticky;`とscroll containerの関係性を知ることで知見が広がるはずなので是非読み進めてみてください。

閑話休題、それでは詳しい説明に移りましょう。

## scroll containerとは

まずはじめに先述したscroll containerとはなにかという話ですが、これはCSS Overflow Moduleの文脈で頻出する概念であり、ざっくりいうとスクロール可能な要素のことを指します。  
たとえば、`overflow-x`, `overflow-y`, `overflow`のいずれかのプロパティが設定されていて且つ、それらの値が`hidden`, `scroll`, `auto`である要素はscroll containerです。`hidden`が設定されている要素がスクロール可能なのかと疑問を抱く方もいると思いますが、あれはJavaScript経由でスクロールを制御できることからscroll containerに含まれています。

ちなみに、scroll containerの可視範囲のことを「scrollport」と呼びますのでこれも併せて覚えておきましょう。（以下はscroll containerとscrollportの範囲を表した図です）  
![](/images/blog/post/2022/06/20220614_2.png)  
_※scroll containerの下部がうっすらと見えていますがこれは便宜上の表現であり、通常は不可視な領域です。_

## `position: sticky;`とscroll containerの関係性

さて、scroll containerについてはなんとなく理解が進んだところで本命の`position: sticky;`とscroll containerの関係性に迫っていきましょう。  
といっても実は単純で、`position: sticky;`が付与された要素は直近の祖先であるscroll containerのscrollportを基準にして張り付く仕様となっているため、この2つは非常に密結合な関係にあるのです。付言すれば`position: sticky;`を動かしたければ、その祖先にscroll containerを正しく設置しなければいけないということです。

ここらへんを理解せずにoverflow系のプロパティを使っていると、scroll containerが乱立して冒頭で記した通り`position: sticky;`を付与した要素が意図しないscroll containerに属して動かなくなってしまうわけですね。

## viewportは暗黙的なscroll container

先の関係性の話を受けて「overflow系のプロパティを指定していなくても（明示的にscroll containerを設置していないくても）`position: sticky;`を付与した要素が動くのはなぜなのか」という新たな疑問を持った人がいると思いますが、その疑問は以下に記したUAが準拠している仕様を見ることで氷解できると思います。

- root要素に設定されたoverflowプロパティをviewportに適用しなければならない
- root要素がbodyを子要素にもつhtml要素であって且つ、そのhtml要素のoverflowプロパティの値が`visible`であれば、その子要素であるbody要素のoverflowプロパティの値を適用しなければならない
- viewportに使用されるoverflowプロパティの`visible`は`auto`と解釈されなければならない

つまり、htmlおよびbody要素のoverflow系プロパティの値をいじらなければviewportが暗黙的にscroll containerとなるので、明示的にoverflow系のプロパティを設定していなくても`position: sticky;`を付与した要素が動くわけですね。

## おわりに

ここまで内容を見ていただいた結果、「position: sticky;をoverflow系のプロパティと組み合わせて使うと期待通りに動かなくなってしまう理由」がわかったのではないでしょうか。

`position: sticky;`には今回記したこと以外にも、inset properties（topやleftプロパティなどの総称）が設定されていないと動かないなどの細かい仕様がありますが、それらについてはあまり深く理解していなくてもなんとかなります。逆にscroll containerとの関係性は非常に肝要であり覚えておかないとろくに`position: sticky;`が扱えないのでしっかりと理解を深めておきましょう！

以下、参照記事一覧

- [https://drafts.csswg.org/css-position/#valdef-position-sticky](https://drafts.csswg.org/css-position/#valdef-position-sticky)
- [https://drafts.csswg.org/css-overflow-3/#scroll-container](https://drafts.csswg.org/css-overflow-3/#scroll-container)
- [https://www.w3.org/TR/CSS22/visufx.html](https://www.w3.org/TR/CSS22/visufx.html#:~:text=UAs%20must%20apply%20the%20'overflow'%20property%20set%20on%20the%20root%20element%20to%20the%20viewport)


position: sticky;をoverflow系のプロパティと組み合わせて使うと期待通りに動かなくなってしまう理由


以下のどちらかの例に沿って、コマンドを実行すればおｋ

```
git stash push <pathspec> [<pathspec>...]
```

```
git stash -- <pathspec> [<pathspec>...]
```

※`pathspec` = ファイルのパスです  
※仮に「hoge」というファイルをstashしたい場合は、`git stash push hoge`もしくは`git stash -- hoge`と記述します。

## 勝手なQA

### `git stash push`ってなに？

ファイルをstashするためのコマンドです。  
みなさんが普段どのようにしてファイルをstashしているのか分かりませんが、おそらく`git stash`を使っているのではないでしょうか。実は`git stash`というコマンドは暗黙的にサブコマンドにpushが追加されて`git stash push`として実行されるようになっています。

参考: [Git - git-stash Documentation](https://git-scm.com/docs/git-stash#Documentation/git-stash.txt-push-p--patch-k--no-keep-index-u--include-untracked-a--all-q--quiet-m--messageltmessagegt--pathspec-from-fileltfilegt--pathspec-file-nul--ltpathspecgt82308203)

### 例に上げられている2つのコマンドの違いを教えて

完全版か簡略版かの違いです（1つ目が完全版で2つ目が簡略版です）。  
先述の通り、`git stash push`は`git stash`に簡略化できるわけですが、以下のようにサブコマンドの位置にファイルパスを入れてしまうと、Git側がそれをファイル名なのかサブコマンドなのかを区別できなくなくなってしまいます。

```
git stash <pathspec> [<pathspec>...]
```

そこで、サブコマンドの位置に`--`という文字列を含めて、ファイルパスとサブコマンドの曖昧さを回避しています。

### そもそも、なんで今更`git stash`についての記事を書こうと思ったの？

「`git stash`　特定のファイルのみ」とかで検索すると、検索結果の多くが古い情報であったり、部分的におかしい情報ばかりで正しい情報が手に入らなかったからです。たとえば、「stashしたいファイル以外を`git add`してから残っているファイルを`git stash`する」とか、「`git stash push -- pathspec`」とかとか……厳密には間違ってはいないんですけれど冗長なコマンドを教えている記事が数多く存在していました。そういった情報から皆さんを守るためにこの記事を書いています（？）。

## 余談

つい最近、`git stash save`が非推奨になっていたことを知って衝撃を受けました。  
`git stash save`が非推奨ならstash entryにどうやってメッセージを付ければいいんだ？と首を捻ったのですが、どうやら`git stash push`の`--message`（`-m`）オプションを使えば簡単にstash entryにメッセージを付けられるようです。

gitコマンドって割と雰囲気で使っちゃうことがあると思いますが、結構隠れた仕様などがあったりするので、普段使っているコマンドだけでもしっかりと公式の仕様書を見てみると良さそうです。

参考: [Git - Documentation](https://git-scm.com/doc)


git stashで特定のファイルのみをstashする方法


つい最近、お仕事で以下のようなリンクコンポーネントを使う機会がありました。

```html
<p>
  詳しくは次のリンクをご確認ください。<a href="https://example.com"
    >→詳細ページ</a
  >
</p>
<p></p>
```

このコンポーネントに大きな問題があるわけではないのですが、スクリーンリーダーユーザーのことを考えるとa要素内の「→」というテキストが気になりました。  
単なる装飾的なテキストである「→」ですが、スクリーンリーダーでは「みぎやじるし」と読み上げられます。そうなるとスクリーンリーダーユーザーに余計な情報を与えてしまい、前後の文言によっては混乱を招いてしまう可能性があるわけです。

これについて職場の先輩とお話しした結果、修正については保留となったものの、こういった場合はどう対処するべきかについて自分なりに考えたのでここに記しておきます。

## 結論

今回のようなコンポーネントでは「→」をspan要素などで囲って、`aria-hidden`属性を付与してあげるのがベストだという考えに至りました。  
以下は実装例です。

```html
<p>
  詳しくは次のリンクをご確認ください。<a href="https://example.com"
    ><span aria-hidden="true">→</span>詳細ページ</a
  >
</p>
```

こうすることで、余計なテキストがアクセシビリティツリーから消えて、スクリーンリーダーで読み上げられなくなります。  
結論としては以上なのですが、上記のようなHTMLではなく、CSSのcontentプロパティで「→」というテキストを表現したい場合も往々にしてあると思いますので、そちらについても併せて紹介しておきます。

## CSSのcontentプロパティで「→」というテキストを表現する場合

CSSの場合、以下のように擬似要素のcontentプロパティにインラインSVG画像を設定してあげるのがベストだと考えています。

```html
<p>
  詳しくは次のリンクをご確認ください。<a href="https://example.com"
    >詳細ページ</a
  >
</p>
```

```css
p > a::before {
  content: url('data:image/svg+xml;charset=UTF-8,<svg xmlns="http://www.w3.org/2000/svg" width="13" height="13"><text dominant-baseline="text-before-edge" font-size="13px">→</text></svg>');
}
```

なぜ、contentプロパティに「→」を直接書かないのかというと、仕様上contentプロパティに設定したテキストはスクリーンリーダーで読み上げられるようになっているからです。
また、通常の画像ではなくインラインSVG画像を使っているのは、汎用性のない画像に対して管理コストをかけたくないと思ったからです。

ちなみに、現在はインラインSVG画像を使っていますが「[CSS Generated Content Module Level 3](https://drafts.csswg.org/css-content-3/)」の中にある[contentプロパティの値に代替テキストを付加させる機能](https://drafts.csswg.org/css-content-3/#alt)が各種ブラウザーに実装されれば、ここで述べた方法を使う必要はなくなります[^1]。ですので、これについては先述した機能が実装されるまでの代替案だと思ってもらえればと思います。

## おわりに

この記事で言及している問題や対策に関してはあくまでも主観であり、すべての状況や環境で適合するわけではありません。  
ですので、その辺りは自身で考えた上、実行してみてくださいね。

[^1]: [各種ブラウザの実装状況](https://caniuse.com/?search=Alternative%20text%20after)


矢印テキストのアクセシビリティについて考えてみる


会社から貸与されているMacで、VS Codeにショートカットキー（`cmd+@`）を登録しようと思ったらなぜかできなくて結構ハマりました。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">社用PCだとVSCodeのキーバインドがうまくいかない悲しい🥲<br>とくにcmd+@が使えないのは痛すぎる🥲</p>&mdash; ひきこもり (@hikiroom) <a href="https://twitter.com/hikiroom/status/1422869226746875909?ref_src=twsrc%5Etfw">August 4, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

先にこの問題の原因を述べると、OSのショートカットキーとVS Codeのショートカットキーの干渉です。

ネットで調べても同じ状況になっている人が見つからなかったものの、ショートカットキー（`cmd+{`など）が機能しないなどの類似した情報はあったので、そこから深掘りしていった結果、先述した情報へ行きついたのでした。  
ちなみにMacでの対処方法は「システム環境設定」→「キーボード」→「ショートカット」から、VS Code上で正しく機能しないキーの組み合わせを見つけて、Mac側のキーの組み合わせを適当なものに変更するだけです。

おそらくOSのアップデートとかで、いつのまにかOS側にショートカットキーが設定されたとかそういうオチなんだろうけど普通におぼけたちゃ😡


Visual Studio Codeに一部のショートカットキーが登録できない、もしくはショートカットキーが正しく機能しない時の対処法


専門卒の3年目フロントエンドエンジニアである私がはじめて転職活動をしたので、その記録をここに残しておきます。  
あくまでも備忘録程度の詳細度ですが、私と近い属性の人に役立てば幸いです。

## 転職活動時の私のスペック

### 年齢

24歳

### 最終学歴

電子系専門学校のWebデザイン科卒

### 住居

東京都23区内（一人暮らし）

### 職業

Web A11yで有名な老舗Web制作会社のフロントエンドエンジニア

### プログラミングスキル

なにをもってプログラミングスキルというのかはさておき、完全Webフロントエンド専業マンだったので、無知の知を得ているくらいにはWebフロントエンドに関するスキルを有していました。

ざっくりいうとHTMLやCSSなどはもちろんのこと、TSやVue.jsといった、いわゆるモダン開発に使うような技術はひととおり扱えて、仮に知らないものであっても基礎知識があるため、すぐに吸収できるような状態でした。  
また、Web A11yで有名な会社に所属していたということもあって、基礎的なWeb A11y知識も持ち合わせていました。

Webフロントエンド以外のスキルでいうと、個人開発で触ったことがあるレベルのバックエンド（Node.js）とネイティブアプリ（iOS）のスキルを有していました。

## 転職の動機

転職の動機は以下の2点です。

1. 継続的に1つ乃至複数のサービスを成長させていきたかった
2. 単純にお給料をあげたかった

とくに、1点目の動機が強かったです。

前職場では、有難いことに新卒の時から多くのプロジェクトに携わらせていただき、さまざまな経験をさせてもらいました。ですが、その一方で受託制作という形態ゆえに継続的に1つのサービスを成長させていく経験がなかなか出来ず、歯痒さを感じていました。  
そんな思いを抱えながら社会人3年目に差し掛かかったところで、2点目の転職動機やその他の細々としたことが引き金となり、「自分にはもっと合う場所があるはずだ！！」と考えるようになりました。そうです、私はいわゆる3年目病に蝕まれていったのです（？）。

その結果として3年弱（実務年数でいうと2年10カ月強）で前職場を退職して転職活動をするに至りました。

## 転職活動について

### 転職活動準備

私は落ち着いた状態で転職活動をしたいと考えていたため、職についている時には転職活動準備をほとんどしていませんでした。そのため、退職後から約3カ月の間で以下の転職活動準備を行いました。

- 転職サイトへ登録
- これまで業務でやってきたことの棚卸し
- 自己分析
- ポートフォリオサイトの作成
- 自分のスキルを明示化するためにプロダクトをいくつか作成
- 職務経歴書の作成
- 履歴書の作成

#### 転職サイトへ登録

これは転職活動民が最初期にやることですよね。  
自分で言うのもなんですが私はかなりの面倒くさがりのため、以下の5つのダイレクトリクルーティング型の転職サイトのみ登録して、受け身の体制をとっていました。

- Green
- Findy
- doda
- Wantedly
- 転職ドラフト

登録したとは書きましたが、実際に機能したのはWantedlyと転職ドラフトくらいで、他のサービスについては正直そこまで使っていませんでした（転職ドラフトについては[別記事](https://sitagakey.me/blog/post/2021/07/20210720_1)で、そのサービスの良さを記しているのでぜひご覧ください）。

ちなみに、エージェントサービス[^1]については、なぜかあまり良い印象がなく、今回の転職活動では一切使っていません。ただし、自分の観測範囲上だとエージェントサービス経由で転職されている方が多いので、とくに拘りがなければエージェントサービスを使ってみるのもいいかもしれません。

[^1]: 転職時に必要な諸々の作業などを仲介人が対応してくれるサービスを指しています

#### これまで業務でやってきたことの棚卸し

その名の通りなのですが、これまで自分が業務で何をやってきたのかを通年および案件単位でまとめました。  
これをしたことで、自分が業務でなにをやってきたのかということが可視化され、面談や面接の際に自分がなにをやってきたのか相手に伝えやすくなりました。

この作業は、退職前の1カ月ほど前からやっていたのですが、自分の携わった案件概要を3年分抽出するのは苦行以外のなにものでもなかったので、転職を考えている人は早めに行動しておいたほうが良いと思います（人間って意外と1カ月前のことですら覚えていないものです）。

#### 自己分析

私は専門学校卒で、技術採用をしてもらった身であり、一般的な就職活動をしたことがありませんでした。  
そのため、本格的な自己分析をするのははじめてだったので、とにかく念入りに分析をしました。

たとえば、自分の幼年期から今までの年表を作成して、そこから自分の持つ強みや弱みなどをさぐったり、自分の頭の中に漠然とあった短、中、長期それぞれの目標や夢を明確化しました。

結果的に、自分の考えの言語化であったり転職活動の軸の形成ができました。

#### ポートフォリオサイトの作成

”エンジニアの転職＝ポートフォリオサイトを作成する”のイメージがあったので、2週間ほどかけてとりあえず作りました。

ただ、ポートフォリオサイト内には前職場の案件実績なども含めており、サイトを作り終えた後に「なんだか前職場を裏切っているような感じがするなあ」と感じて、結局一度も使うことなくお蔵入りとなりました。

#### 自分のスキルを明示化するためにプロダクトをいくつか作成

ポートフォリサイトをお蔵入りさせたと先述しましたが、やはり自分の実力を知ってもらうためには、なにかしら形のあるものを見せられなくてはいけません。  
ということで、自分の抱えている問題などをベースに複数のプロダクトを作成して、[GitHub](https://github.com/sitagakey)上にコードをアップロードをしました。

関連記事：

- [無職になったから自分の課題を管理するためのアプリを作ったンゴ日記アプリ](https://sitagakey.me/blog/post/2021/02/20210218)
- [アイデア出しに役立つアプリを作ったからみんな使え！！](https://sitagakey.me/post/2021/04/20210417)

#### 職務経歴書の作成

職務経歴書はmd形式で管理して、必要に応じてVS Codeを使い、そのファイルをpdf形式にして出力していました（pdf形式にした時の枚数が3枚に収まるように工夫しました）。  
ちなみに職務経歴書のアウトラインは悩んだ末、以下に落ち着きました。

- 職務経歴書
  - 基本情報
    - 氏名
    - GitHub
    - フロントエンドスキル
  - 職務経歴
    - 会社名と所属期間
      - 職務概要
        - 会社でやってきた職務の概要を記載
      - 実績
        - 直近3件の案件を抜粋して、その案件の概要であったり、どのような機能を開発してきたのかを記載（もちろん案件名などの守秘義務系はボカす）
  - 自己PR
    - 自分の強みであったり、次の会社で役に立つであろうポイントを2つ記載

#### 履歴書の作成

今回選考を受けさせていただいたすべての会社が紙の履歴書不要とのことだったので、履歴書は[JISZ8303](https://www.jisc.go.jp/app/jis/general/GnrJISNumberNameSearchList?toGnrJISStandardDetailList)（一般的な履歴書に使われているJIS規格）に沿ってHTMLで作りました。  
なぜ、HTMLで作ったのかと言うと、志望動機などの項目欄の高さや位置などを柔軟に変更できるからです。あとは、私が求めるフォーマットの履歴書がネット上に落ちていなかったからです。

ちなみに、履歴書を自作する際の豆知識ですが、JISZ8303には名前欄や志望動機欄といった市販の履歴書で頻出するような項目を載せなくてはいけないという規定はありません。すなわち、履歴書に載せる項目は作る人の自由であるというわけです。

極端な話、名前欄がなくてもJISZ8303に準拠していると言えるわけですが、そんなことをすると履歴書と呼べなくなってしまうので、ある程度は市販の履歴書に書かれた項目を踏襲するとよいでしょう。

### 転職活動本番

先述した準備を終えた後、そこから2カ月強の間、カジュアル面談を含む転職活動の本番に挑みました。  
今回の転職活動でカジュアル面談を受けさせていただいた会社は6社で、そこから選考に進ませていただいた会社は3社でした。

ちなみに選考を受けさせていただいた会社の結果は、1社1次選考落ち、1社最終選考辞退、1社合格です。

#### カジュアル面談について

今回の転職活動を通じて、はじめてカジュアル面談を経験したのですが、転職活動をする際は必ずこの面談を受けるべきだと感じました。また、その際は自分と同じ職種の方であったり、今後その会社に入社したらコミュニケーションを取るであろう方達に同席してもらうことが肝要であるとも感じました。その理由は簡単で、「選考を受ける前に、今後自分が働くであろう環境の雰囲気や、スキルレベルなどを知ることができるから」です。

選考を受ける前に会社の雰囲気やスキルレベルなどを知ることで、自分とミスマッチな会社に対して履歴書を書いたり、余計な選考期間を過ごす回数が減ります。それから、一緒に働くであろう方達と話をすることで、その職場での将来像がより詳細に見えきて、志望動機などがパッと思い浮かびやすくなります。

#### 面接について

いずれの会社も1次面接は割と雑談ベースだったので、最初の自己紹介こそ声が震える場面はありましたが、比較的落ち着いて受け答えができていた気がします。  
質問は技術的なものが多く、普段から目的などを意識してコード書いていた自分としては、そこまで詰まるような質問はありませんでした。  
評価軸としては、技術面が大半を占めている印象で、次点で人柄などが評価されていたのではと考えています。

最終面接についてですが、1社のみしか受けていないのでこれが普遍的なものかは不明なものの、「会社に入社してなにをしたいのか」を中心に問われたと記憶しています（緊張のせいで途中の記憶が飛んでいます）。  
「なにをしたいのか」というのは自己分析の中で見出したつもりだったのですが、最終面接を通して、依然として抽象度が高いことに気付かされました。ここらへんに関しては自分1人だと気がつきにくいので、面接前などに友達や家族といった第三者に確認してもらうが吉です。  
この最終面接での評価軸は、「その会社の目的を共に達成していく気持ちがあるのか」という意識的な部分だったのではと考えています。

ちなみに、1次選考を含めてすべての選考結果は早くて次の日、遅くとも4日後にはいただけました。

## 初転職活動を終えてみての感想

「**転職活動って思っていたよりも、めっちゃ時間がかかる！**」というのが素直な感想です。

正直、長くて2カ月くらいで終わるものだと思っていたのですが、大幅に予定がずれ込み5カ月強もかかってしまいました。  
ある意味で就活がはじめてだったということもあり、準備期間などの見積もりがガバガバだったというのが原因ですね（ガハハ）。

ちなみに、このガバガバ見積もりのせいで、もともと120万ほどあった貯金が、各社の選考を受けていた時期には家賃や生活費に削られ底をつく寸前でした。そういったこともあり、各社からの選考結果を待っている時は、明日への不安から鬱状態になっていました。

今だからこそ笑えますが、当時は身動きができないほどに精神がやられていました…。  
皆さんが転職活動をする際は、「転職活動は時間がかかるものだ」ということを理解した上で、活動していただければと思います。そうすれば、私のような悲惨な目に合わなくて済むでしょう彡(^)(^)

## おわりに

有難いことに最終面接を受けた会社とご縁があり、8月1日より正式にフロントエンドエンジニアとして働かせていただくことになりました。

人、サービス、会社の方針、どれをとっても素晴らしいとしか言いようがない会社だと思っており、その会社で働けることを今からとてもワクワクしています。  
実際に働いてみてからじゃないとわからないことも多々あると思いますが、全力で次の会社に尽くして行くつもりです！


専門卒の3年目フロントエンドエンジニアが初転職するまでの話


「[THE 拡散思考](https://the-divergent-thinking.netlify.app/)」という拡散的思考を活用したアイデア出しアプリを作ったのでアプリの概要ざっと書き残しておきます。

## アプリの目的

アイデア出し時の視野を広げることを目的としています。

## 機能

拡散的思考特化のアプリにしたかったため「ユーザーの入力したワードを元に、関連するワードを大量に表示する」という1機能のみ実装しています。今後も大きな機能追加は予定していません。

## 内部仕様

特記することはあまりないので、このアプリの根幹機能である関連ワード取得についてのみ書きます。  
この機能には「Google Suggest API」を使用しているのですが、APIの仕様が公開されていないようなので結構手探りで使うことになりました。

ちなみにJavaScriptでこのAPIを使う場合はパラメーターに`client=chrome`もしくは`client=firefox`を追加して、レスポンスを`text/javascript`形式で受け取ってjsonpで読み込む必要があります。このAPIについて調べると検索上位の記事に「現在はXMLしか取得できない」などと書かれているわけですが、JavaScriptの場合はどうあがいてもCORSエラーを抜けることができなないため逆にXMLの取得はできないと思います。

以下のコードは実際にAPI取得のときに使っているものです。ご参考までにどうぞ（jsonpの読み込みには[fetch-jsonp](https://www.npmjs.com/package/fetch-jsonp)というライブラリを使用しています）。

```ts
async getSuggestWord(query: string): Promise<string[]> {
    return await fetchJsonp(`https://www.google.com/complete/search?hl=ja&client=chrome&q=${query}`).then((res) => res.json()).then((res) => {
        const query = res[0];
        const words = res[1];
        const replacedWords = words.map((word: string) => word.replace(`${query} `, ''));

        return replacedWords;
    }).catch((err) => {
        return [`__error__: ${err}`];
    });
},
```

## おわりに

自分で作っておいて言うのものなんですが、なかなか有用なものを作った気がします彡(^)(^)  
使っていてすでに直したい部分がいくつかあったので、今後もちまちま更新していこうと思います。おわり。
