みなさんこんにちは。
[`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/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>
```

このコンポーネントに大きな問題があるわけではないのですが、スクリーンリーダーユーザーのことを考えると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://hikiroom.site/post/2021/07/20210720_1)で、そのサービスの良さを記しているのでぜひご覧ください）。  

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

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

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

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

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

#### 自己分析

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

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

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

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

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

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

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

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

関連記事：
- [無職になったから自分の課題を管理するためのアプリを作ったンゴ日記アプリ](https://hikiroom.site/post/2021/02/20210218)
- [アイデア出しに役立つアプリを作ったからみんな使え！！](https://hikiroom.site/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年目フロントエンドエンジニアが初転職するまでの話

[こちらの記事は転職ドラフト体験談投稿キャンペーンに参加しています](https://job-draft.jp/articles/251)

題名の通り、フロントエンドエンジニアである私が、転職ドラフトというダイレクトリクルーティング型の転職支援サービス経由で転職をしたため、この記事ではその感想をつらつらと書いていきます。先に結論を述べておくと大変満足しています。

転職活動自体については、「[専門卒の3年目フロントエンドエンジニアが初転職するまでの話](https://hikiroom.site/post/2021/07/20210720_2)」という記事に詳細を書いていますので、興味がある方はそちらも合わせてご覧ください。

## 転職ドラフトに登録したきっかけ

私よりも早くに転職をされた前職場の先輩に転職について相談をした時、「転職ドラフトっていうおもしろいサービスがあるから試しに登録してみれば」と紹介をしていただいたのが登録のきっかけです。

ちなみに、サイトをはじめてみた時の印象は「なんだか怪しげなサイトだなあ」です。笑

## サービス登録後

サービスの登録自体は、先輩から紹介があった日にすぐしたのですが、レジュメ（職務経歴書）の登録が面倒だったため、そこから数ヶ月放置していました。  
ですが、転職活動を本格的に始動したタイミングで重い腰をあげて、レジュメの登録をするに至ります。

レジュメ登録後は、転職ドラフト運営の方からレジュメの審査があるわけですが、返却されることなく一発通過することができました。  
ただ、「レジュメに〇〇を書くと詳細度があがってより良くなるよ」といったご指摘[^1]をいただいたので、そのご指摘を元にレジュメを少し修正して、2021年5月度のドラフトに参加をしました。

[^1]: レジュメ添削は無料な上に、とても的確なので本当に有り難かったです

## 転職ドラフトでの指名状況

ドラフト初参加でしたが、有難いことに5社の指名をいただくことができました。  
希望年収を未設定の状態にして参加したのものの、いずれの指名額も私が心の中で希望していた額よりも大幅に上回っていたので驚きました。また、自分の市場価値が結構高いことを知れて素直に嬉しかったです。

ちなみに最終日まで私の指名は0だったので、「こりゃだめだ」と期待はまったくしていなかったのですが、最終日の夕方頃から一斉に指名メールが届きはじめました。  
ですので、指名が無くて落ち込んでいる人は最終日の締め切り時間まで希望を捨てないでおくと良いと思います。

私の観測範囲上では、バックエンドやインフラ系のスキルをもっている方々が早めの段階から多くの指名をもらっていたので、指名数や市場価値を高めたいと思うのであれば、そこらへんの実績を作っておくのが一番でしょう。

## 面談と面接について

指名を頂いた5社の内、3社の面談を受け、そこから2社に絞って面接を受けました。  
いろんな方の体験談にも書かれていますが、指名をもらったからといって確実に内定が出るわけではありません。

とくに、指名文が数行程度の会社はあまりこちらのレジュメや実績を把握していないので、面談と面接を受ける際は注意が必要だなと感じました。つまるところ、そういった会社に指名をもらったとしても双方ミスマッチである確率が高く、面接で普通に落ちる可能性があります。

逆に指名文がしっかりと書かれていたり、レジュメ以外の実績にコメントをくれる会社については、先に述べたような問題はなく、建設的な面談や面接ができたように感じました（内定をいただいた会社はこちら側に属していました）。

兎角、面接を経て自分と会社がミスマッチであれば落ちますし、そうでなければ受かるということです。ただ、指名をもらっているということは、ある程度の技術的適性があるとも考えられますので、その点は自信をもって挑んでいただければいいと思います！

## 内定後の提示年収額

最終的に第一志望であった1社から内定をいただくことができ、その会社からは転職ドラフト上で提示していただいた額より気持ち上の年収を提示いただくことができました！  
最悪、転職ドラフト上で提示いただいた額の90%内であれば問題ないと考えていたので、それを超える額を提示頂いた時の高揚感は忘れられません。

ちなみに、その会社の内定を承諾して8月から一緒に働かせてもらう予定です！

## 転職ドラフトを使ったことがない方へのメッセージ

転職を考えているエンジニアの方であればとてもオススメできるサービスです！

このサービスは現在進行形でユーザーが増えているということもあり、今後は人が溢れて参加者のレジュメが埋もれていってしまう可能性があります。  
先駆者のみが甘い蜜を吸えるというのが世の定めです。やって損はないと思いますので、少しでも興味がある方は早めにサービス登録を済ませてドラフトへ参加すると良いかもしれません！

フロントエンドエンジニアが転職ドラフト経由で転職をしたので感想をつらつらと書く

現在提案されている[Canvas 2D APIの新機能案](https://github.com/fserb/canvas2D)がおもしろいので、今更ながら本提案の概要と気になっている機能をさくっとまとめておきます。

## 概要

今より簡単に、よりリッチな表現をCanvas 2D APIで可能にするための提案で、9つの機能が提供される予定です。

2019年11月にWICGへ投稿された「[Proposal: updates for Canvas2D API](https://discourse.wicg.io/t/proposal-updates-for-canvas2d-api/3910)」が初出のようですが、去年開催された[Chorome Dev Summit](https://www.youtube.com/watch?v=dfOKFSDG7IM)の紹介によって認知された方が多いのではないでしょうか。Chorome Dev Summit内でも語られていましたが、すでにGoogle Chromeではフラグ（Experimental canvas 2D API features）を有効化することで各種機能を試すことができます。

以下は、各種機能名およびそれの簡易的な説明です。

- Canvas context loss： ページがバックグラウンドにある時などに、Contextを破棄してリソースを開放するための機能および破棄後にContextを再構築するための機能
- willReadFrequently： Canvasの画像データを頻繁に読み取ることを明示的にすることでブラウザにヒントを送り、データ読み取り時のパフォーマンスを最適化する機能
- Color input： [CSSColorValue objects](https://drafts.css-houdini.org/css-typed-om-1/#colorvalue-objects)を使った色の指定を可能にする機能
- Text modifiers： CSSで使用できる`letter-spacing`や`font-stretch`といった機能をCanvas 2D API上で利用可能とする機能
- Reset function： Canvasの状態（pathやtransformなど）をリセットする機能
- RoundRect： 角丸な長方形を描画する機能
- Perspective transforms： 遠近感のある物体を描画できるようになる機能
- Conic Gradient. 円錐形のグラデーションを作るための機能
- Modern filters： Canvas上でSVGフィルターを使うための機能

いずれも、以下の3つの軸で提案されているものとなっており、今までの慣例じみた実装をいい意味で破壊してくれるのではと期待しています。

1. 世に出回っているライブラリを参考にして、需要の高い2D API群と同等の機能を提供
2. 現在のCSSが持つ機能へのアクセス
3. パフォーマンス改善

## 気になっている機能

### Reset function

逆になんでいままで存在しなかったのかおかしいぐらいの機能だと思っています。  
この機能が追加されることで、canvasの状態を初期化する際の`canvas.width = canvas.width`や`ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height)`といった記述が`ctx.reset()`に統合されます。

Canvas 2D APIを普段から使っていない人からすれば、普通に考えて`canvas.width = canvas.width`とか謎でしかないですもんね。

### RoundRect

個人的に大本命の機能です。
というのも今まではCanvas 2D APIで角丸の長方形を描画しようと思ったら以下のように複数行のコードを書く必要があり、記憶的負荷やパフォーマンス負荷が多少なりともかかっていました。  

```js
ctx.beginPath();
ctx.moveTo(left + radius, upper);
ctx.lineTo(left + width - radius, upper);
ctx.arcTo(left + width, upper, left + width, upper + radius, radius);
ctx.lineTo(left + width, upper + height - radius);
ctx.arcTo(left + width, upper + height, left + width - radius, upper + height, radius);
ctx.lineTo(left + radius, upper + height);
ctx.arcTo(left, upper + height, left, upper + height - radius, radius);
ctx.lineTo(left, upper + radius);
ctx.arcTo(left, upper, left + radius, upper, radius);
ctx.fill();
```

それが、今後は`ctx.fillRoundRect(x, y, w, h, radius)`の1行で済むようになるのです。  
これにより、先述した負荷軽減ならびにコードの可読性を著しくあげることができます。

### Element as a source for drawImage

今回提供が予定されている機能の中には含まれていませんが、アイデアとして「Element as a source for drawImage」という機能が挙げられています。  
img要素やvideo要素以外のHTML要素をソースとして描画できる機能だと認識しているのですが、これが実装されれば[html2canvas](https://html2canvas.hertzen.com/)などに依存することなく簡単に要素を基点としたのWebページのキャプチャが撮れることになります。  
後発ということもあるので、html2canvasなどで正常に認識できないスタイル（CSSプロパティ）の認識が可能であったり、その他ユーザーが求めている機能群を盛り込んだAPIが追加されるのではと予想しています。

私の場合、Webアプリ開発時にページのキャプチャを撮りたいと思うことが往々にしてありますので、この機能を先んじて各ブラウザベンダーに実装してもらえると嬉しかったりします。

## おわりに

さまざまな有用機能が追加される一方で、canvas要素を使用する時の懸念点となりやすいa11yの改善案が1つもなく、少し残念な気持ちになりました。  
ですが、新機能が追加されること自体は非常に喜ばしいことなので、今後もよりよいアップデートがあることを期待して末長く動向を追っていければと思っています。

Canvas 2D APIの新機能案がアツい

Next.jsをTypeScript化した際にモジュールパスのエイリアスが正しく動作せず、VS Codeに表題の警告が出た場合は、恐らくtsconfig.jsonの設定不足です。  
以下の通り、tsconfig.jsonの`baseUrl`と`paths`オプションを有効化して、適当なパスを入力しましょう。
```
    "baseUrl": "./",                   /* Base directory to resolve non-absolute module names. */
    "paths": {
      "@/*": ["./src/*"]
    },                                 /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
```

これで治らない場合は、VS Codeを再起動してみたり、next.config.jsに設定したモジュールパスのエイリアスとtsconfig.jsonに設定したパスが一致しているか確認するとよいでしょう。

おわり。

参考:
[https://nextjs.org/docs/advanced-features/module-path-aliases](https://nextjs.org/docs/advanced-features/module-path-aliases)

Next.jsにTypeScriptを導入したらVS Codeで「モジュール 'module name' またはそれに対応する型宣言が見つかりません。」という警告が出た

「[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}`];
    });
},
```

## おわりに

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

アイデア出しに役立つアプリを作ったからみんな使え！！

数年前に妹から「なぜ、ご飯を残してはいけないのか」という質問をされた時に、中途半端な回答をしてしまったことをふと思い出したので、今更ながらその質問に対する回答をここに記しておきます。

この質問に対しては「バチが当たるから」「農家の人が一生懸命育てているから」という回答をよく見聞きしますが、個人的には「*自分もしくは他人の時間を無下にする行為だから*」なのではないかと考えています。

たとえば、仮にあなたが時給1000円の仕事をしているとしましょう。  
そして、あなたは500円の弁当を買い、半分だけ食べて残りは食べずに捨ててしまいました。

モノだけで捉えれば弁当半分、もしくは250円を捨てたと言えるでしょう。  
ただ、それを時間で捉えるのであれば、あなたは**15分の時間を捨ててしまっている**とも言えるのではないでしょうか（500 / 2 / 1000 * 60)。

私は、後者の考えをもっており、食べ物を残す人を見ると「自分の時間をムダにする人だな」と感じます。  
時間は有限であり、なにものからも得ることができない尊いものです。  
時間の使い方は人それぞれと仰る人がいますが、先に述べた通り有限である時間をあってないようなものとするなんて、0点と刻まれたテストの答案用紙を自慢げに見せびらかすことと同じくらいマヌケな行為であり、愚の骨頂以外の何者でもないでしょう。

ですので、時間を有効的に使いたいですとか、他人の時間を無下にしたくないのであれば、食べ物を残してはいけない（残すべきではない）のです。

以上、「なぜ、ご飯を残してはいけないのか」に対する回答でした。  
反駁などは私の[Twitter](https://twitter.com/hikiroom)へどうぞ彡(^)(^)

食べ物を残すことは時間を捨てていることと同義

`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でネストされたディレクトリのコンポーネントを自動インポートした時にでるエラーの対処法

先日「[カダイの付箋](https://kadai-no-fusen.site/)」という課題管理Webアプリケーションを制作したので、制作の経緯など記しておきます。

## 制作した経緯

端的にいってしまえば、無職になったので自己管理を徹底せねばと思ったからです。

無職になると24時間すべてを自由に使えるわけですが、ざっくりな予定しか立てずに行動をしていると、大した成果もなく日々があっという間に過ぎてしまいます。  
また、そうしているうちに「あの時ああしていれば」、「この時間にあの作業やってたら」のようなタラレバが嵩んでいき、過去を後悔するようになります。

そういった後悔を回避するには、今ある課題から目を背けずに整理し、明示して、解決する必要があります。  
この課題の「整理・明示・解決」の方法は人それぞれやり方があると思うのですが、私はこの無職の期間中は基本家におり、その間のほとんどはPCを触っているだろうと予想しているので、一番無理なく続けることができそうなWebアプリケーションを使う（作る）という方法を選択しました。

## 制作の流れ

制作は、「機能要件の定義」、「WF（情報設計）作成」、「実装」の3工程で行いました。  
機能用件の定義の段階では、自分が欲しいと思った機能をMDファイルに書き殴っていきました。  
また、実業務の課題管理をする際に使用していた、「Backlog」および「Win 10に付属している付箋ソフト」などが有する機能をまとめたりもしました。

そして、それら基にWFを起こしていきました。

<tl-img
    src="/images/post/2021/02/20210218_2.jpg"
    alt="カダイの付箋のWF">
</tl-img>

WFなんて久しく書いていなかったので、なかなか骨が折れました…。  
WFができてからはゴリゴリ実装作業を開始したのですが、もともと1週間程度で終わらせようと思っていたのに、なんだかんだ2週間くらいかかってしまいました（それもこれも作業環境がﾜﾙｲｾｲﾀﾞ）。

少し内部的のことも書いておくと、このアプリケーションのデータ保持には「[IndexedDB API](https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API)」というをモノを使用しています。  
もともとFirebaseを使って認証機能およびデータの保持をしようと思っていたのですが、それ（というか認証機能）をつけてしまうとこのアプリケーションの手軽さが消えて、おそらく継続して使わなくなるだろうと考え、現在の実装になりました。

同じようなAPIに「[Web Storage API](https://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API)」などがありますが、なぜそれらを使わなかったのかというと、IndexedDB APIのバージョンアップ機能や非同期で処理が実行できる点に魅せられたからです。

## おわりに

すでに自分で使っていて気になる箇所がいくつかあったので、今後もアップデートを重ねてより良いサービスにしていきたいと思います彡(^)(^)

ちなみにデザインについてはある程度WFで想像を膨らまして、実装でそれを落とし込めればいいかなと思い端折りましたが、結局そのせいで実装の微調整を繰り返して余計な時間を食ってしまいました。やはりデザインはしっかり作ってから実装作業をしなくちゃなあと思いました（コナミ）。

無職になったから自分の課題を管理するためのアプリを作ったンゴ

今まで「Next.js × microCMS」で構成していた当ブログを「Next.js × md」の構成へ変更しました。  
リプレースした理由は

*「記事を書くのにわざわざブラウザ開くのが面倒臭い」*

これに尽きます。  
ここ数年はブログを書くと言えば、所属している会社の技術ブログくらいだったのですが、そこでは記事をmdで管理しており、

「記事を書いたやで！あとはgitでリポジトリにぽいや〜彡(^)(^)」

これだけで完結していたのです（厳密にはもう少し工程がありますが）。  
そんなmd湯に使っていたため、今更ブラウザを開いて、サイトにアクセスして、記事を書くなんてことはできるわけなかったのです。

なにはともあれ、骨の折れるリプレース作業が終わったので、今後は当ブログにのんびり記事を投稿していこうと思います。

ひきるーむ

最新のチラ裏