2/18~2/24 在宅勤務/過剰な健康への不安

在宅勤務

すでに発表されている通り弊社は在宅勤務期間中だ。僕はソフトウェアエンジニアの一般社員なので仕事に占めるコミュニケーションの割合が低く、在宅勤務でもそこまで不便を感じていない。エンジニア職以外の事情はよくわからないし、エンジニアでもリーダー級以上になるとミーティングが多くあるのでなかなか大変なところがあるのではと思う。

あえて不便なところを挙げると、オフィスが使えない分自宅の環境に左右されるところか。自宅のPCデスクはかなりリソースを投じて強化してきたので問題ないどころか会社以上に快適。だがネット回線は時間帯によって不安定でイライラする。自宅の周りに飲食店がないので食事に変化がなくなるし(自炊のレパートリーが少ない)、運動不足にもなる。通勤が不要なぶん1日あたり80分くらい時間が浮いてるので、その時間を使って散歩でもすればいいのか。でも花粉のシーズンだからなあ。

過剰な健康への不安

先週の虫歯の処置以降、なんでもない歯の感覚がどれも虫歯の兆候なのではと思えてしまって不安だ。歯医者では処置した歯以外は問題ないと言われているが、それもあまり信用できない気分。一般論として医者は信用すべきなんだが。

もともと僕は健康を損ないたくない、特に永続的にダメージが残るような病気にはなりたくないという心配が強すぎる。年齢的に考えればこれから健康は失っていく一方だというのに、バカバカしい。

ちゃおネイキッドプロジェクトの進展

自動デプロイ

Spotify機能のためにredisを立ててdocker-composeで連携するようにした。これに伴いデプロイの手順が変わったので.drone.ymlを調整した。docker runに複雑なオプションを載せまくるよりもdocker-compose.ymlに書いてしまう方が楽だし1コンテナでもdocker-composeを使うべきなのかもしれない。

CSSレイアウトのお勉強

Spotifyで聴いている曲を表示できるようになったので、画像・タイトル・アーティストをいい感じにレイアウトしたくてCSSのお勉強をした。MDNのドキュメントが大変参考になった。というかCSS系の情報はググってもノイズが多すぎる。

勉強のためにstyled-componentsでCSSをTSの中で記述してみた。ファイルの中身がカオスになる感覚は否めないが、コンポーネントとスタイルの結びつきが強くなるのは使いどころによっては便利なのだろう。特にwebpackを弄らずとも導入できるのはよい。

bundleサイズ削減

bundle analyzerで見てみるとmomentのタイムゾーンとかlocaleのファイルがすごい容量食っててビビったのでググって削減した。効果が数字で見えるのは楽しいのだが、webpack.config.jsがどんどん複雑になっていくのはつらい。

今後の野望

  • 監視・ロギングの強化
  • 様々な自動投稿機能がついたTwitterタイムラインのようなサービスにしていきたい

SpotifyAPI実装記

2/11(火)

自宅にこもってSpotifyNowPlayingをホームページに表示する機能を作っていた。

Spotifyのaccess_tokenをredisで保持することにしたのだが、そうすると本番環境にもredisを用意せねばならない。docker-composeで連携させることになるだろうが、デプロイフローをまるごと変えなければならないので大変だ。

クライアントとサーバーのアプリケーションをどういうリポジトリ構成で管理するかも難しい問題だ。クライアントはReact、サーバーはexpressなので両方ともTypeScriptであり、型の共有などのメリットは活用したいが、両者を近づけていくとビルド周りの設定が煩雑になりそうだ。

既にサーバー側のビルドがなぜかクライアント側の型エラーで落ちる現象が起きている。おそらくtsconfigを共有しているせいでクライアント側のコードまでincludeしてしまっているからだろう。

OAuth認証も難しい。僕のSpotifyアカウントでリソースへのアクセスを許可する必要があり、これはブラウザからしかできない。よってその工程までは手作業で行ってからaccess_codeをconfに記入し、アプリケーションを起動することになる。

適当にパソコンをポチポチしていた

2/1(土)

していたら土曜日が終わった。

OpenToonzの1.4.0が出たのでLinuxでビルドしてみた。ドキュメント通りで特に問題なし。

動画サイトの再生エリアのスクショをワンクリックで撮れるようにしたくて調べていたんだけど、ざっくりMDNを読んだ感じセキュリティ上の理由でクライアント側だけではどうにもならないっぽい。

その他、寝たり起きたり鍋作ったりDota2したりしてたら1日が終わってた。僕は休日は無計画に浪費する方が好きだ。あまり褒められたことではないが…。

カレーうどん界の動向

1/25(土)

同僚と外出。昼に千吉のカレーうどんを食べた。カレーうどんの専門店が存在するとは思っていなかった。

Dota2のプレイ履歴が見られるOpenDotaというサービスにちょっとしたバグがあり、OSSだったのでPRを出しマージされた。intの0が入りうる箇所で !hoge という書き方でvalidationをしているので0がinvalid扱いされていた。生のJSは辛い。

Dota2は調子がいい。7.23の環境にようやく体が慣れてきた。8連勝中。今は大規模な大会も行われていてアツい。

TypeScript Interfaces メモ

1/9(木)

http://www.typescriptlang.org/docs/handbook/interfaces.html

Introduction

  • TSはduck typingでありstructural subtypingである

Our First Interface

  • TSは要求されているプロパティがあるかだけをチェックする

Optional Properties

  • プロパティ名の後ろに?をつけるとoptionalになる

Readonly properties

  • プロパティ名の前にreadonlyをつけると書き換え不可になる
  • ReadonlyArray<T> というやつもあるぞ

Excess Property Checks

  • 要求されているプロパティがあるかだけをチェックする とoptionalを組み合わせると、optional propertyのプロパティ名のtypoが型エラーにならなくなる
  • でもtypoはバグとして検出したい…検出したくない?
  • なのでTSはプロパティ名を手書きする(リテラル)ときは特別に excess property checking をする
    • Object literal may only specify known properties, but 'hoge' does not exist in type 'Fuga'.
  • excess property checking を回避する方法
    • as
    • interfaceの方に [propName: string]: any; を足しておく
    • 一度変数に入れる

axios.getの型

1/3(金)

自宅の気温や湿度を表示するwebアプリをいろいろとリファクタリングしていた。APIを叩いたレスポンスには型の保証がないが、 axios.get にジェネリクスを与えておけばその型が来たという想定で書くことができていい感じだった。このコードで渡すジェネリクスを更に外から与えられるT型にしているのは、インフラ層でドメイン層で定義した型を使ってはいけないから(ホンマか?)。

moment.jsはめちゃ便利。JavaScriptの組み込みのURLオブジェクトはパスの結合が便利にできるかと思いきやそうでもない。ホストとパスの結合だけ。

ESLint入れた

12/18(水)

TypeScript+ReactのプロジェクトにESLintとprettierを入れた。ESLintのプラグインを上手く組み合わせていくテクニックが難しかった。

結論はこんな感じ。

.eslintrc.json

{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "tsconfig.json",
    "sourceType": "module"
  },
  "extends": [
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended",
    "plugin:react/recommended"
  ]
}

yarn lint で能動的にlintを実行できるようにしつつ、lint-stagedとhuskyでcommit時にも仕込んだ。