子どもが産まれたし、最近のこととこれからのこと

11月に子どもが産まれた。
長女で名前は日菜乃とつけた。僕は5歳になった長男といつまでもふざけていてまともな案を出さなかったが、妻がいい名前を考え出してくれた。非常に素敵な名前だと思う。
女性の名前は難しい。いくつか考えてみたけれど、どうにもしっくりこない。
あまり名前に対して強い思い入れがない質なので、画数がほとんど命名の拠り所になっている。まず画数で調べて、その中で音と雰囲気で良さそうなものを選ぶことにしている。
長男の時もそうだし、今回産まれた長女についても上記の通りなので、幼稚園なんかで名前の由来を提出するような企画で少し困る。

11月の半ばから12月いっぱいは育休を取得している。 長男は予定日より早く生まれたので、今回も予定日より早めの11月に初旬頃に生まれるだろうと漠然と思っていたけれど、たっぷり予定日を超えて産まれた。
11月初旬に生まれたらその段階から育休取得すれば2ヶ月くらい取れると考えていたが、その目論見は完全に外れてしまった。
最終的には計画出産になったけれど、突然生まれるのと違って、産まれる日を決めることができてしまうので、お腹から出てくるのがなんとなく寂しいような気持ちになった。

出産にあたって、長男の幼稚園の諸々とか家事のことがあるので7時に起床することになった。今までは9時に起床することが多かったので心配だったけど、今は逆にこのサイクルに慣れ始めている。
7時に起きて洗濯や子供のご飯の用意、着替え、布団を片付けて幼稚園の支度、送り出し、諸々が済むと大体9時ごろになっている。
この調子が続くのであれば仕事に入っても問題ないと思うけれど、赤ん坊は刻一刻と状況を変化させるので、実際に仕事が始まる頃にはどのような状況になっているかはわからない。

もう長男は冬休みに入ってしまったので変わってしまったが、およそ午前中9時から長男の迎えがある15時ごろまでは、たまに赤ん坊の様子を見つつ自分の時間を過ごしていた。
絵を描いたり、最近では音楽を作ったり、または新しいプログラミング言語の勉強をしていたりするとあっという間に時間は過ぎる。
この時間が本当に楽しくて、いつまでも育休だったらいいのにとも思う。
思えば仕事で1日8時間働くというのは凄まじいことだ。
起きてから日が暮れるまで、体感的に最も人間が何かを行うのに向いている時間だと思うし、そんな時間を週の5日分も提供するということをもっと意識すべきだなと思う。

2年前の自分の日記を読み返すと、子供には仕事は楽しいものだと伝えたい旨を記述していたけれど、今もそれは変わっていない。
逆にいえば、上記のような時間を費やすことを考えると、前向きに過ごせない仕事だとすごくもったいないと思う。

仕事はおそらくうまくいっている。もう長いこと今の職場で働いたような気がするが、来年でまる3年ということになるらしい。
コードを書くことは相変わらず楽しい。コードを書くことはもちろん楽しいのだけれど、ここ最近は何を作るかということが自分のモチベーションに強く関わっていることに気づいた。

世の中には様々な課題があって、多くの会社はその課題を解決することで需要を創出し、利益を得ている。 その課題や解決方法が自分の関心に近いほど仕事は面白いのかもしれない。

子供と仕事の話をすることがある。仕事の話というか将来なりたい職業のような話をする。
話していると自分は社会にでてこの年齢なるまで、仕事の種類というものをほとんど知らなかったなと思う。
仕事だけでもないけれど、世の中にある様々なものを広く知ることで、可能性が広がるし、いろいろなことに興味を持ってその中から好きなものを選べるようになるといいなと思う。

音楽の制作は最近始めたばかりですごく楽しい。
元々音楽が好きで自分で作ってみたいと言う気持ちはあったけど、何から手をつけたらいいのかわからなくて後回しになっていた。
そんな中、たまたま先輩のところに遊びに行って相談したところ、使ってないMIDIキーボードがあるからといただいた。
それを毎日のように触っている。鍵盤を押すといろんな音がなってとても楽しい。
もちろんまだまだ思うようなものは全く作れていないけれど、もっと早くやればよかったなと思う。

もっと早くやればよかったと思うことは沢山あるし、今後も増えて行くと思う。
消化するには今は時間が足りなさすぎる。10年前は時間があったがお金がなかった。

だけど、今思えばお金がなかったというのはいいわけで、単純にお金を払う胆力がなかったんだなと思う。

少し前に、僕の職域の界隈で有名なazu氏が寄付に関するサービスをリリースしていて、そのドキュメントにお金を手放すことには苦痛が伴うということが書いてあった。

https://azu.github.io/slide/2021/open-philanthropy/open-philanthropy.html

思い返せば、今まで満足にお金を持った経験がなく、常にお金を使うことを避けてしまっていたので、僕は多分お金を手放す苦痛と今までうまく向き合うことができていなかったんだなと思う。

先日久しぶりに服を買いに行った。服や靴などを1人で買いに行くことは非常に久しぶりだったが、自分で選び何かを買うという体験はこんなに難しくて、こんなに楽しいものだったのかと思った。
何より僕は服を買うことが下手になったなと思った。 何かを決断するのにも苦痛が伴う。
このことと僕はもう少し向き合う必要があると感じている。

絵は引き続き描いている。
年内に一枚、少し大きめの絵を仕上げたいと思っている。
今回は特に展示をする予定もないし、おそらく完成してSNSにあげて、それでおしまいになると思う。
今年はおそらくアナログでは4、5枚、デジタルで着彩したようなものが他に何作か、それでも地道に続けている。

そもそも僕は絵を描いて何をしたかったんだろうなとよく考えている。
何者にもなれずに、特に評価されるわけでもなく、今後評価されることもおそらくはないと思う。
お金にしたいという気持ちもあまりない。展示をしたいみたいな気持ちはあるけれど、優先度としてはかなり低い。
東京のことは知らないけれど、関西アートシーンに対してははっきり言ってネガティブな印象を抱いていることも関係しているのかもしれない。

ただ、それでも描き続けているし、今のところ辞めるということは全く考えていない。

長男の幼稚園が冬休みに入って、昼間の自由時間はすっかりなくなってしまった。
子供を寝かしつけた後、可能であれば起きて自分の作業をする時間に充てる日々が始まっている。
来年になれば仕事が始まるので、この日々がまたずっと続くと思う。
これを繰り返すことは、なんというか、削っていくような感覚になる。

もしかしたら今後、絵を描くことは限りなく少なくなるのかもしれない。
でも絵の代わりにコードを描くことや、音楽を作ること、または違う何かを作ることは続けて行くと思う。

最近よく、人間というのはコンバータみたいなものでかもしれないと考えている。
なんらかの入力があって、それを何かの形に変換して出力することを繰り返しているのかもしれない。
入力は例えばその日の出来事や今までの記憶、経験みたいなもので、出力は入力に伴う単純な応答や、表情、あるいは料理、絵、創造物みたいなものになる。
自分は単純に、自分が何を出力するのかに興味があって、それが知りたいがためにずっとこの行為を繰り返しているのかもしれないなと、漠然と考えている。

自分が絵を描いて、世の中に対してインパクトを残したいというよりも、自分が何かを作るとどんなものができるかわからないから知りたい、みたいな単純な話なのかもしれない。

幼稚園が冬休みに入った長男と、毎日レゴで遊んでる。
レゴで何かを作るというより、レゴの小さいフィギュアたちに名前をつけて、毎日戦わせたり物語を作って一緒に遊んでいる。
この遊びはもう2年続いている。
2年間、ほぼ毎日ずっとこの遊びを繰り返している。
最初はトラックたちが主人公だった。毎日形を組み替えながら、何台かのトラックたちで話をして、物語を作っていた。
今もそのトラックたちはいる。長男の成長と興味の移り変わりに合わせて、トーマスが入ってきたり、マリオが入ってきたり、マイクラが入ってきたりして、ほとんどカオスな世界観が広がっている。
今、自分の一番の友達はきっとこの長男で、2人で2年かけて作りあげてきたこの世界は、本当に宝物みたいに感じている。
だけどいつかきっと、パパとは遊ばなくなって、この世界が終わって、この世界があったことも忘れてしまう日が来るんだろうなと思う。
それでもいいさ、それがいつになるかはわからないけど、だから今思う存分遊んでおかないとなと思う。

そういえば今年は個人制作でアプリを一つリリースした。長男がマイクラのスキン作りにハマっていたことがあって、既存のアプリだと作りにくそうにしていたので、より簡単に作れそうなものを考えて作ってみた。
マイクラのスキンを作るためのアプリで、ブラウザで遊ぶことができる。
カスタムスキンは残念ながらswitchのマイクラは非対応だけど、スマホ版やJava Edition では使えると思う。

https://minecraft.skin-editor.com/

来年はどんな年になるかわからないけど、後悔がないように楽しく過ごしたい。

ReactやAngular、VueなどでComponentのスタイリング時に抑えておきたいこと

React CSS

なんとなく自分の中で言語化しておきたかったので、整理も兼ねて記載しておきます🙆🏻‍♂️

普段仕事で様々なAngular、またはReactののコンポーネントを作ったりメンバーから出るPRを読む中で、コンポーネントのスタイルはどういうふうに当てるのが破綻しにくいんだろうと考えていました🤔
Angularは良くも悪くも一つのComponentが結構おっきくなりがちだったのでそこまで意識しなかったですが、Reactは何なら分割しないと気持ち悪いとすら思えるくらいにコンポーネントを分割しやすいです。
コンポーネントを分割することは各ファイルごとに把握すべき事柄が減るので基本的にはいいことだと思っていますが、スタイリングについては意識しないと破綻してしまうなーと思っています。
（もちろん、スタイリングに限らず意識しないと破滅するんだけど、今回はスタイルについての話です）

スタイルの破綻っていうのは、ロジックの破綻と同じで、どこで何があたっているか把握できない、みたいなことだと思っています。
あるいは、利用側からどうやってそのコンポーネントを使えばいいのかわからなかったり、必要以上にスタイリング用のたくさんのpropsを貰う必要が出てくる、みたいなのもそうかなと思っています。

そこでいくつか守ったほうが良さそうなパターンがあるので、それを列挙していきます💪

■ 外に対してのmarginは持たない

これはMust💪
例えば以下のようなことはNG ​

const StyledButton = styled.button`
  margin: 16px auto;
`;

export const Button: React:FC = () => <Button>ボタン</Button>

​

なぜNGか

このButtonは自分がどこで使われているか知らないはずなのに外側の隙間を定義するmarginを持ってしまっています。
子はそんなことは考えなくって良くて、どこに配置するかは使う側（親コンポーネント）が考えれば良いとおもいます🙆🏻‍♂️
逆にこういうstyleを持ってしまうと、「違うmargin渡したいから、marginもpropsに追加しなきゃ、、、」みたいになりがちです。 同様の理由で、position: absoluteなんかも自身が持たないようにしましょう（親のコンテキストによって位置が決まるので）

🤔 paddingはどうですか？

paddingは持っても大丈夫です。paddingはコンポーネント自身の内部の隙間です。
例えるなら、paddingというのは脂肪です。marginはソーシャルディスタンスです。自身のことはそのコンポーネントが知っていて大丈夫なので、paddingは問題ありません🙆🏻‍♂️

🙆🏻‍♂️

const Parent: React:FC = () => (
  <div>
    <Button css={{ marginBottom: '16px' }} />
    <Button />
  </div>
);

みたいに使う側で指定してあげましょう。

■ widthは特別な事情がない限り指定しない

widthをpropsとして渡せるコンポーネントを見る機会が結構あります👀
ですが、widthはそもそも、親のコンテキストで決まるので、多くの場合widthを指定する必要はない気がしています👀
というより、display: blockであれば、そもそもwidthは100%になっているはずです。
widthが100%の状態であれば、使う親の方でdivで囲むなりして幅を指定してやることが可能です。

ただ、そのコンポーネント特有のwidth、またはmax-widthがある場合もあります。
例えばボタンや、バッジなどです。こういうものに関しては、width、またはmax-widthを持つことになると思います。 そもそも、そういうコンポーネントは自身のサイズが決められているので、あまりwidthを変更したいと言う機会がない気がしますが、もし必要になる場合はパターンがあると思うので、本当にpropsでwidthをpx単位とかで渡すのではなく、サイズを表す定数（たとえばlargeやあるいは使われるコンテキストの名前など）を定義してそれを渡すほうが良さそうです。 もし定義するのが辛くなるくらい大量に定数が発生する場合はもしかしたらデザイナーと相談したほうがいいかもしれません。

■ レイアウトに関するスタイル、またはタグはできる限り全体を見通せるように指定する

いいたいことはこれです（毎度非常に良い記事ばかりで勉強になっています🙇‍♂️）。
https://blog.uhy.ooo/entry/2020-10-15/react-paired-css/

例えば、flexはdisplay: flexの子要素として初めて意味を成すスタイルです。
なので

const StyledWrapper = styled.div`
  display: flex;
  & > .hoge {
     flex: 〇〇;
  }
`;

のようにまとめて書くと非常に全体を把握しやすいです。
もちろん様々あると思うので必ずこの方法​で記述しろとは言いませんが、少なくとも1ファイル内で追えるようにすべきです👀

また、これはhtmlタグについても同様です。
thはtd、またはli、dt、ddなどは親要素がいないと意味をなさない要素です（逆もまたしかりです）。 それらは必ず1ファイル内で追えるようにし、単体でexportしないようにしましょう🙆🏻‍♂️

■ 【要検討】 displayはinline系にしない

これは微妙に賛否が分かれると思うのですが、基本的にコンポーネント自体のスタイルとしてはdisplay: blockまたはflex, tableなど、インラインでないほうがいいのかなと思っています👀
理由はinline、inline-block等のインライン要素は記述コンテンツ => 文章とその中に含まれるマークアップとして定義されているものが持つスタイルで、使用されるコンテキストとしてもinlineであることを期待してしまっているからです。

https://developer.mozilla.org/ja/docs/Web/HTML/Block-level_elements#Block-level_vs._inline

コンポーネントを考えたときに、コンポーネントはなにかのパーツではありますが、それ自身で完結しているものでもあります🤔
そうだとするならば、コンポーネントのdisplayがインラインであるのはコンポーネントとして不自然な状態だと言えるのではないかなーと思っています👀

また、使う側からすると、各コンポーネントがblock、またはそれに準じたdisplayになっていることで、どのコンポーネントもある程度似たように扱うことができるようになります。
flex等の指定が可能になったことで、コンポーネントがinlineでないと実現できないレイアウトもほとんどなくなったと言う認識です。

ただ、これについてはwebcomponentsのCustom elementsのissueでデフォルトのスタイルをdisplay: blockにすべきだという議論があったものの、この意見を補強する資料が見つかりませんでした🙄

https://github.com/WICG/webcomponents/issues/224

なので、僕にとってはこのほうがやりやすいが、そこまで気にしなくていいことなのかもしれません👀

以上です🌮
はい

​ ​

ReactでrequestAnimationFrameを使う

React JavaScript canvas

ふと自分で遊んでる時に、ReactでCanvas触るのどうするんだろなーという気持ちになったので調べた。

ここを読めばすべてのことが書いてある。
https://css-tricks.com/using-requestanimationframe-with-react-hooks/

DEMO

https://codesandbox.io/s/mystifying-framework-hdk7k

具体的に

基本的にrequestAnimationFrameを使う場合は、再帰的に呼び出されるような処理のことが多い。有限なのであればいいが、例えばcanvasで背景アニメーションを描画するなどして永遠に描画させ続けるような場合もある。 そういう場合、例えばもらうpropsが変わって再描画されるたびに、追加であたらしいrequestAnimationFrameのループが始まるようだと困る。 そういう場合はcancelAnimationFrameでcancelしてから、新しいrequestAnimationFrameのループを始めたい👀

useRefを使えばよろしい

useRefは何もDOMにアクセスするためだけにあるわけではなくって、再描画されても同じ値を保持し続けたいような場合に使える。
なので、戦略的には、useRefにrequestAnimationFrameを格納し続けておいて、任意のタイミングでそれをcancelAnimationFrameするということになる。

const Canvas: React.FC = () => {
  const animationRef = useRef(null);
  const animate = () => {
    animationRef.current = requestAnimationFrame(animate)
  };
  
  // なんかのタイミングで
  cancelAnimationFrame(animationRef.current);
}

まぁ、いわゆるなんかのタイミングっていうのは、このコンポーネントが破棄されたとき、となるわけなので、

const Canvas: React.FC = () => {
  const animationRef = useRef(null);
  const animate = () => {
    animationRef.current = requestAnimationFrame(animate)
  };
  useEffect(() => {
    animationRef.current = requestAnimationFrame(animate);
    return () => cancelAnimationFrame(animationRef.current);
  }, [])
}

のようにuseEffectを使ってやると、コンポーネントが破棄されたときにcancelAnimationFrameが呼ばれるようになる。

そういうわけでrequestAnimationFrameを使う処理をCustorm Hooksに切り出してやる

const useAnimationFrame = () => {
  const animationRef = useRef(null);
  const animate = () => {
    animationRef.current = requestAnimationFrame(animate)
  };
  useEffect(() => {
    animationRef.current = requestAnimationFrame(animate);
    return () => cancelAnimationFrame(animationRef.current);
  }, [])
};

const Canvas: React.FC = () => {
  useAnimationFrame()
}

これで、useAnimtionFrameをつかって何かしらをすることができるようになったが、実際のrequestAnimtaionFrameで回したい処理をどの様に書くかかという点がある🤔

requestAnimtionFrameで回す処理をもらう

どうすべきかなーとか思っていたけど、useAnimationFrameはAnimationFrameについて関心を持っているべきで、それ以外のことは知っておくべきではない。
それ以外のことについては使う側が勝手にやってくれよな✊🏻

というわけで、requestAnimationFrameで関数を受け取るように変更する🚀　　

const useAnimationFrame = (callback: () => void) => {
  const requestRef = useRef<ReturnType<typeof requestAnimationFrame>>();
  
  // callback関数に変更があった場合のみanimateを再生成する
  const animate = useCallback(() => {
    callback();
    requestRef.current = requestAnimationFrame(animate);
  }, [callback]);
  
  // callback関数に変更があった場合は一度破棄して再度呼び出す
  useEffect(() => {
    requestRef.current = requestAnimationFrame(animate);
    return () => {
      if (requestRef.current) {
        return cancelAnimationFrame(requestRef.current);
      }
    };
  }, [animate]);
};

const Canvas: React.FC = () => {
  useAnimationFrame(() => {
    // なんかやりたい処理
  })
}

まとめ

  • useRefはコンポーネントの再描画に関わらず、とっておきたい値を入れるのに向いている
    • elementの参照以外にも色々活用法があるぞ！

これでReactでCanvas遊びがやりやすくましたね✊🏻

Good Canvas & React Lifeを🎍

switchかなんかで条件によって異なる値を返す関数の型の書き方

TypeScript JavaScript

この間やっててハマったので、意外とハマる人多いのでは？ということでメモ

前提⚠️

  • typescript v4.0.2

■ 前提となる変数たち

type valueOf<T> = T[keyof T];

const KEY = {
  foo: 'foo',
  bar: 'bar'
} as const;
type Key = valueOf<typeof KEY>;

const VALUE = {
  foo: 'foo',
  bar: 'bar'
} as const;
type Value = valueOf<typeof VALUE>;

こんな場合の話🙆🏻♂️‍

const getFooOrBar = (key: Key) => {
  switch (key) {
    case KEY.foo:
      return VALUE.foo;
    case KEY.bar:
      return VALUE.bar;
  }
};

const foo = getFooOrBar(KEY.foo);

このとき、fooはfooのリテラル型になっていてほしい、というかなるのでは？と思ったが、実際は以下のようになる

const foo: "foo" | "bar"

僕がハマったとき、実装がもう少し複雑だったので問題がなにかに気づくのに時間がかかったし、端的に言って鬼ハマリして時間をドバドバとほとんど湧いては捨てられる温泉のように無駄にした♨️

どうやんの？😕

ここに書いてあります🦸♂️‍ https://stackoverflow.com/questions/58673034/type-inference-from-switch-case-return-with-typescript

公式はこいつです🙋 https://www.typescriptlang.org/docs/handbook/functions.html#overloads

なるほど、たしかにopenapiとかで自動生成されたコードで見たことあるわ、こいつ🤔
というわけで、functionのoverloadsを使います

function getFooOrBar(key: Extract<Key, 'foo'>): Extract<Value, 'foo'>;
function getFooOrBar(key: Extract<Key, 'bar'>): Extract<Value, 'bar'>;
function getFooOrBar(key: Key) {
  switch (key) {
    case KEY.foo:
      return VALUE.foo;
    case KEY.bar:
      return VALUE.bar;
  }
}

const foo = getFooOrBar(KEY.foo); // const foo: "foo"

■ curry化されていて、返す関数の型をやるとき

はキモいですがこんな感じ🐛

const createFooOrBarGetter = () => {
  function getFooOrBar(key: Extract<Key, 'foo'>): Extract<Value, 'foo'>;
  function getFooOrBar(key: Extract<Key, 'bar'>): Extract<Value, 'bar'>;
  function getFooOrBar(key: Key) {
    switch (key) {
      case KEY.foo:
        return VALUE.foo;
      case KEY.bar:
        return VALUE.bar;
    }
  }
  return getFooOrBar;
};

■ この関数をexportしたいとき

は全部exportしてね🚛

export function getFooOrBar(key: Extract<Key, 'foo'>): Extract<Value, 'foo'>;
export function getFooOrBar(key: Extract<Key, 'bar'>): Extract<Value, 'bar'>;
export function getFooOrBar(key: Key) {
  switch (key) {
    case KEY.foo:
      return VALUE.foo;
    case KEY.bar:
      return VALUE.bar;
  }
}

良かったですね🙆🏻♂️‍

TypeScriptで自作している便利型Tips

TypeScript

たまになんかこういうの取り出したいんだけど、なんかないかなーみたいなことになっていくつか作ってみたりしているので、せっかくなので記載しておく🙆🏻♂️ ‍ 命名が微妙なので、命名をどうにかしたいというのがある

valueOf<T>

keyOfの反対。
与えられたオブジェクトのvalueのユニオン型を作る

type valueOf<T> = T[keyof T];
const HOGE = {
  hoge: 'test',
  fuga: 'test2'
} as const;

type Hoge = valueOf<typeOf HOGE> // 'test' | 'test2'

mappedConst<T extends string>

与えられた文字列のkeyとvalueを持つオブジェクト

type mappedConst<T extends string>  ={
  [key in T]: key;
};
type HogeOrFuga = 'hoge' | 'fuga';

type HogeFuga = mappedConst<HogeOrFuga>;
/**
{
  hoge: 'hoge',
  fuga: 'fuga'
}
*/

OptionalExceptFor<T, K extends keyof T>

Tの型からKを除いたものをOptionalにする

export type OptionalExceptFor<T, K extends keyof T> = Pick<T, K> &
  Partial<Omit<T, K>>;
type A = {
  foo: string;
  bar: string;
  baz: string;
};

type B = OptionalExceptFor<A, 'foo' | 'bar'>;

const b: B = {
  foo: 'test',
  bar: 'test'
};

RequiredExceptFor<T, K extends keyof T>

Tの型からKを除いたものをRequiredにする

export type RequiredExceptFor<T, K extends keyof T> = Pick<T, K> &
  Required<Omit<T, K>>;
type A = {
  foo: string;
  bar: string;
  baz: string;
};

type B = RequiredExceptFor<A, 'foo' | 'bar'>;

const b: B = {
  baz: 'test'
};

ArgType<T, N>

引数のN番目の型がほしいとき。Nは省略可能で省略された場合は0番目の型

type ArgType<
  T extends (...args: any[]) => any,
  N extends number = 0
> = Parameters<T>[N];
const getNString = (num: number, str: string = 'hoge') => str.padStart(num, str);

type Arg1 = ArgType<typeof getNString>; // number
type Arg2 = ArgType<typeof getNString, 1>; // string

ToKeyValueTuple<T>

keyとvalueのタプル型を得たい👀
例えば、関数で

const [state, setState] = useState({});
const updateValue = (key, value) => {
  setState(state => ({
    ...state,
    [key]: value
  }));
};

みたいなときに、stateのkeyValueのペアを引数でもらうのに型をつけたいみたいなモチベーション

type ToKeyValueTupleWithKey<
  T,
  K extends keyof T
> = K extends keyof T ? [K, Pick<T, K>[K]] : never;

type ToKeyValueTuple<T> = ToKeyValueTupleWithKey<T, keyof T>;
const a = {
  a: 'a',
  b: 10,
} as const;
type A = ToKeyValueTuple<typeof a>;

const aa: A = ['a', 10]; // 型 '["a", 10]' を型 '["a", "a"] | ["b", 10]' に割り当てることはできません。

なお、以下だとうまく行かない

type ToKeyValueTupleWithKey<
  T,
  K extends keyof T
> = [K, T[K]];

const aa: A = ['a', 10]; // ['a' | 'b', 'a' | 10]なのでエラーにならない

また気が向いたら追加していきます💪

2019年が終わる

もう後7時間後には2019年が終わる。全くなんの感慨もないし、実感もない。年々実感がなくなっていく。
僕にとって年越しというのは、祖父の家に行って寿司を食って、帰りの車の中でフロントガラスに雪が吸い込まれていく様子を眺めながら除夜の鐘を聞くことなのかもしれない。
そしてそのあと、コンテナが連なったみたいなカラオケボックスに行って友達たちがいかに地獄になっているかを確認することなのかもしれない。
しばらくそういうことは行われていない。
だから年末年始というのが実感を伴わないままやってきて過ぎていくというのが、ここ最近の通例になっている。

さっき作品が多分完成したので微妙にハイだ。多分というのは、後ほど見直すとなにかしら手を加えたくなる可能性があるからで、だけど多分このまま完成とする可能性が高いのでは？と思っている。
できたはいいけど、これは来年の1月からの展示で使うので今すぐ公開できない。できたものをすぐ公開できないのは悲しい。

展示すること自体、3年ぶりくらいになる。
年末に声がかかって出すことに決めた。そろそろ動きたいと思ったからだ。公募展で出展するのは一作品だけ。周りの出展者が決まると僕はなんとなく他の出展者のサーチをしまくった。久しぶりすぎてびびってる。びびってるし、やっぱり出すからにはポジティブな評価を得たい。調べたことで作成する作品に変更を加えるということはないけれど、なんか気になって仕方なかった。多分3年の間に随分と周りの状況が変わっているだろうし、自分も変わった。その差分がどの程度なのかを確認したかったのかもしれない。

制作は難航した。
序盤にしっかり失敗して、夜中3時に途方に暮れた。 絵のパーツが全く浮かばなくて、会社の往復中ずっとiPadにぐちゃぐちゃ描いてみたりした。
色も決まらなくて、絵の前でなにもせずに音楽を聴いて、取り敢えず、と言って漫画を読んで時間が過ぎた。
塗った色が気に食わなくて6時間くらい同じ色ばかりいじってみたりした。
さっきまで完成の見込みが立たなくて、どうすればいいのか途方に暮れていた。

絵を描いてる時に思い出すのは、大学の時に良くしてもらった柳楽先生の

絵は結局、色と形と構図

という言葉で、ずっと頭に残っている。
最近料理について考えていた時、この言葉が浮かんで、料理は味と香りと食感やなと思ったりした。

—-

2月から新しい職場に移って、もうすぐ丸一年。
仕事についてここでとやかく言いたいことはないけど、何事もなく過ごせている。

プログラミングは楽しい。もちろんなにをするかによるわけだけど、多くの場合コードを書くことは自分にとって楽しい。
楽しいことをやって金を得ている。絵を描いている時は金のことを考えると途端にしんどくなったが、コードは楽しく書いてられる。もちろん金を得られるからコードを書くというわけでもなく、家だと環境の問題で書くことができないのでわざわざコワーキングスペースに行ってまで書いたりしている。
結局物を作るのが好きで、それがコードから成ろうが、絵具からなろうがあまり差異はないのかもしれない。むしろ絵の場合は個人的な部分に深く根ざしすぎているし、マネタイズが非常に難しいこともあって、同じ好きを仕事にするでもプログラミングの方が合っていたのかなとおもう。
特に絵は3年前はなんとなく制作に金銭のことがちらついて、これが売れるといくら、あるいは売れやすそうな作品、飾りやすそうな作品、というようなことが常に浮かんでしまっていた。
3年経ってそういう気持ちは随分なくなった。もはや忘れ去られただろうという気持ちと、金は別で稼いでいるので、売れなくても困らないと割り切れるようになった。というより、売れなくてもいいので自分が面白いと思える物を、という気持ちが強くなった。

なんとなく仕事は辛いイメージがある。楽しくない、生きるために仕方なくやることだ、みたいな。
1日8時間、月160時間も費やすのに苦痛でいるのはどうなのだろうと思う。なんとなく子どもには仕事は楽しいものだと伝えたいし、子どもの前では楽しく仕事してるようにしたい。

個人的にアプリを開発しようと思ってコワーキングスペース通いを週一くらいで続けていたけれど、全く形にならないまま終わってしまった。これは来年頑張りましょう。

プログラミングの職種的に僕はWebフロントエンドデベロッパーに分類されるわけだけど、来年はデザイナーやサーバサイドとの協業をもっと意識的にしていきたいし、新しいことにももう少し挑戦したい。レガシーとの戦いもどこかでまとめておきたい。
これらは来年仕事でやりましょう。

—-

絵が完成して、今年これで何枚かけただろう。アナログ作品は記憶にある限りこれで4枚目。毎年4枚50年描いても200枚にしかならない。
200枚。人間の一生で描く枚数としては非常に少ない気もする。
もちろんそれはライフステージによって変化するし、いつか辞めたりすることもあるのかもしれない。プログラミングも全くしなくなる時がやってくるのかもしれない。であればできるだけ楽しく自分に嘘なくやっていきたい。

子どもが来年から幼稚園。
今は嫁の実家で同じ歳の甥っ子と戦争を行っていて、今そこに向かっている。
子供はかわいい。非常にかわいい。子どもと遊ぶのはすごく疲れるけど楽しい。だけどそれだけが自分の全てと言うことではもちろんない。
子どもと家庭と自分とのバランスをもっとうまくとりたい。

来年はオリンピックがある。オリンピックを見ながら酒を飲むのがすごく楽しみ。

そういうわけで、グッバイ2019

まぜそば。油そば。そういう系のやつのレシピ

まぜそばが好きなので自作している。
最近はまぜそばと呼んでいるけど、昔地元で見かけた時は油そばって名前だった気がする。

イメージ

油が絡んでいてしょっぱい、ラーメンというイメージ。というかラーメンのタレをスープで割らずに麺に絡めたらなりそう。
オイルと塩と砂糖と酢を混ぜたものに麺を絡めたら形になりそうな気がするけど、オリーブオイル一本だと弱い気がするので動物性の油があると良い。
油自体の融点は豚に比べて鳥の方が低いし、ラーメンって鶏ガラベースで作られることが多いので鶏油を使っておこうみたいにしている。

考え方としては、

  • コク+ 旨み + 滑らかさ = 動物性油 + 植物性油
  • 味 = 塩味 + 甘み + 酢

というイメージ。

麺

スーパーで買えるつけ麺用の麺、或いはラーメン用の麺。こういうノリのやつ

https://www.life-netsuper.jp/fuchunakagawara/item/detail.php?im_id=13662197&detail_ilc_code=000008&detail_imc_code=001830&detail_isc_code=183010

タレ

  • 鶏油
  • オリーブオイル
  • 醤油
  • 砂糖
  • 酢

鶏油は、鶏皮が売ってたら鶏皮をカリカリに焼くと得ることができる。

このような感じだけど、もう少し小さく切った方が扱いやすいし、食べやすい。

量としては一人前に対して大さじ1から2くらいあると足りる。多分鶏皮1、2枚あれば得れると思う。量が足りなければオリーブオイルで補えばいい。
気持ち的には、鶏油だけでもいいけど、若干オリーブオイル混ぜたほうがあっさりする気がする。

使いそうな分の鶏油にオリーブオイル適当混ぜて、砂糖、醤油、酢を入れて混ぜる。これは普通に混ざらない。砂糖が溶ければいいやくらいのノリ。
麺に適当のかけて和えて、あとは醤油とか酢とか足しながら食べたらいい。特に酢は無限に足せる。

トッピング

肉味噌

  • 豚、または鳥のミンチ肉
  • 砂糖
  • ニンニク
  • 味噌
  • 酢
  • オイスターソース
  • 欲しければ鷹の爪

イメージとしては甘辛い味。麺と絡めたいので少し味濃いくらいの感じ。甜麺醤とか使うと雰囲気出ると思う。
最初にニンニクと欲しければ鷹の爪と油を入れて火にかけ、気持ちになったらミンチ肉を入れる。大量の油が得られるようならどっかでキチペ（キッチンペーパー）で拭くといい。
火が通ったら各種調味料で味付けする。俺は辛いものがええんやとなれば豆板醤でも入れておくといい。

その他お気持ちトッピング

■ 玉ねぎ、或いはネギ

玉ねぎは粗めのみじん切りにして塩揉みして、水にさらしておく。玉ねぎのベストプラクティスがわからず、最終玉ねぎが口を支配することになるので、4分の1個とかにするか、白髪葱とか青ネギのみじん切りみたいなのでもいいと思う。 この生玉ねぎの辛さを軽減する方法はマジで知りたい

■ 煮卵

樋口直哉氏の素晴らしい記事があります。

https://note.com/travelingfoodlab/n/n07b2ebda1e5f?creator_urlname=travelingfoodlab

■ もやし

簡単に火を通したものでもいいし、茹でたものでもいい。ナムルでもいい。

アドバンスド

最初に書くべきだったけど、最終的な味をどうするかというのを思い浮かべて、足すなりするといい。
上記でベーシックなわけだけど、ここに花椒と、唐辛子、胡椒をがっつり振るスパイシーになるし、好きならパクチーを入れると雰囲気が出る。パクチー入れるなら酢を強めに効かせるとより良い気がする。
食べながら適当に味を変えていくのも面白いと思う。