mizdra's poem

雑なこと (日記/技術ポエム/メモ/…) を書くブログです.

2020-05-10

オレオレ eslint-config

というわけで作った.

github.com

依存しているeslint-configに更新があると, dependabotによりPRが立つので, リリースノートを見て新しいルールを追加してマージする, という流れ. patchバージョンアップの場合はauto-mergeするようにしているので, 新規ルールの追加やBreaking Changesがあった時だけPRに目を通す形になる. インターフェイスはeslint-config-teppeisを真似ている.

テストをメンテする気さえ起きないのでノーテストだけど, ただのeslint-configなのでそう壊れることはないはず. そもそも壊れても僕だけしか使っている人居ないはずなので, 自由なタイミングで直せば良い.

publishするのもだるいなと思ってmasterにマージしたら自動でpublishするような仕組みも作ったけど, 手でpublishするのとそんなに手数変わらないし, 複雑な仕組みを導入したせいで逆にメンテが面倒になりそう. とはいえ自動デプロイ導入しているリポジトリは(Netlify以外)過去に無いので, 勉強がてら運用してみるのも悪くなさそう.

ゆかりスロット

ゆかりスロットをplay/pauseキーで操作できると面白いかなと思ってMedia Session APIで遊んでた. けど, Media Session APIを使うには Audio インスタンスを用意したり, AutoPlay Policyを突破する必要があるようで, 面倒くさくて諦めてしまった. また気が向いたら再開します.

記事

この日記を書いている時点でまだ一文字も書いてない. 困った.

2020-05-06

記事

記事書いてた. 偉い. 何か重要なことだけに絞って書いているはずなのにどんどん記事のボリュームが膨らみ始めている. まあそれだけテーマが良いということなのだろうけど. 記事のボリュームがでかいと読むのがだるくなりがちなので, 出来るだけ明快な言い回しをしたり, 読んでいて面白い (ネタに走る訳ではなく, 飽きさせないという意味) と感じるような文章を書くよう気をつけている. 中々大変だけどテーマが良いので書くのは楽しくやれている. 来週の月曜くらいに出せると良いかな〜

睡眠

昨日睡眠失敗して, 今朝の5時くらいまで起きていた. 破滅してます.

記事書いてたらどんどん良い文章の断片が頭の中を駆け巡るようになって, 布団に入って目を閉じてもそんな状態だったので気になって全然寝れなかった. 仕方なく断続的に布団から出てPCの前に行って記事書いてた. 進捗が出るのは良いことだけど睡眠は大事なので困る.

今朝11時に起きて, それでも睡眠時間が足りなかったので, 2時間くらい昼寝してた. 疲れはだいぶ取れたと思うけど, 明日は仕事なので念の為素早く寝ます.

2020-05-05

日記

そういえば昨日の日記書いてなかったなと思い出して書くことにした. もう翌日の22時だけど…

ゆかりスロット

突然ゆかりスロットに面白機能搭載しようと思って, その前準備としてリファクタリングしてた. リポジトリは諸事情あってprivateになっていたのだけど, 折角作ったので公開できるよう整備して公開してみた. MITライセンスなのでスロットゲーム作りたい人はforkして作ってみて下さい.

github.com

記事

ゆかりスロットのコードを整備する過程で, 画像の読み込みによるガタツキがどうも気になってしまって, どうにかできないか色々調べてた. 調べていく内に昔はintrinsicsize属性を使っていたところが, 最近は別のテクニックを使うよう推奨されていることが分かった. intrinsicsize属性に関する日本語の記事は出回っているけど, 新しいテクニックについては皆無だったので記事を書くことにした. とりあえず導入は書けた. 今は後方互換性について書いてる. 久々の大作になる予定です.

脱線

昨日(2020-05-04)までrocketimer作っていたはずが, 今日になってゆかりスロット触り始めて, さらには記事を書き始める事態になってしまった. めちゃめちゃ脱線している. 何故こんなことに…

まとめ

記事書いてて今日も偉い.

2020-05-04

日記

GW入ってから毎日日記書いてるので今日で3日連続で日記投稿してることになる. 偉すぎる.

乱数調整向けタイマー (rocketimer)

tscとtsserverの速度測定できる環境作ってひたすら測定してた. 今回はTSのバージョンを3.9に上げるのと, --skipLibCheck でdepsの型定義ファイルの型検査をスキップするのを試してみた. どちらもそれなりにtscに対しては効果あったけど, tsserverに対してはイマイチだった. TSのバージョンは上げとくだけ得*1なので上げれば良いと思うけど, 後者は運が悪いとバグを見逃す原因にもなりかねないので, わざわざ導入するほどでもないと思う. rocketimerの場合はまだ小さなプロジェクトなので --skipLibCheck による高速化は軽微なものだったけど, ハチャメチャにdepsが多いプロジェクトとかだとまた変わってきそう. そういう場合は --skipLibCheck も有用かもですね. 実際の測定結果などは以下のPRにまとめてあるので興味ある人居たら読んでみて下さい.

github.com

それにしても丸一日掛けた割には特に実践に使える情報は得られなくて無だった... これだけ調べて何もアウトプットが無いの悲しすぎるので米粒程度でも良いので何かまとめて記事にしたい気持ちがある. ハチャメチャにdepsが多いプロジェクトに --skipLibCheck 入れると速くなって便利だよ, みたいな記事良いかな, と一瞬思ったけど --skipLibCheck がハマるほどハチャメチャにdepsが多いプロジェクト触ってる人ほぼ居ないだろうし, そもそも自分はそんなプロジェクトに関わっていない…

*1:ここ韻踏んでます

2020-05-03

散髪

朝から散髪した. 超偉い.

乱数調整向けタイマー (rocketimer)

コードべースリファクタリングしたり, ESLintの設定 (主に @typescript-eslint 関連のrule) 見直したりしてた. 気軽に @typescript-eslint のrule使っていくと型情報要求されまくってlintに時間掛かりがちなので, opinionatedなものは可能な限り避け, bad practiceを検知できるruleを中心に入れるという方針でruleを追加していた. TIMING=1 yarn run eslint とかするとどのruleに時間が掛かってるか分かって便利です.

github.com

TypeScriptとパフォーマンス

rocketimerではmaterial-uiを使っているのだけど, material-uiはビルドや型検査に時間が掛かることが以前から知られていて *1*2*3 , 件のプロジェクトでもビルドが遅くなったり, tsserverの反応が遅かったりと影響が出ている. 常に遅い訳ではなくて, TSX書いてる時は数秒待たされるけど, ただのTS書いてる時は即座にレスポンスが返ってくるという感じ.

めちゃめちゃ困っている訳ではないけど, TSXちょろっと書く度に数秒待たされるのまあまあしんどいので, 改善できると嬉しい. 無闇に最適化するのは危険だけど, まあ困ったときの切り札として最適化テクニックを学ぶのは悪いことではないだろうと思って, 今日は色々それっぽい情報調べてた. 明日ビルド速度測定する環境構築しつつ, TS 3.9RCに上げたり, tsconfig.json弄ったりしてビルド速度爆速化してみる.

“Solution Style” tsconfig.json

TS 3.9でrelease予定の「“Solution Style” tsconfig.json」とかいう新機能, 便利そうだった.

*1:https://material-ui.com/guides/minimizing-bundle-size/#development-environment

*2:https://github.com/mui-org/material-ui/issues/19113

*3:https://github.com/microsoft/TypeScript/issues/34801

2020-05-02

掃除

連休初日の朝から机周り掃除した. めっちゃ偉い.

乱数調整向けのタイマー

rocketimerという乱数調整向けのタイマー作ってる. 昔emtimerという乱数調整向けのタイマー作ったことあって, それの第二世代という位置づけ. emtimerは既存の乱数調整向けのタイマーがFlash製で数年後にサポート終了することから, その代替として開発したものだった. 機能も既存の乱数調整向けのタイマーとほぼそっくりで, いわばモダンな技術でタイマーを作り直しただけ. UIがモダンだったり, モバイルフレンドリー, Flashの無い環境でも動くといった点がウケたのか, 今でもそれなりのアクセス数がある.

一方で, emtimerには以下のような問題がある.

  • Viewとタイマーのコアが密結合している
    • 新しいタイプのカウントダウンタイマーを実装しようにも, 既存のタイマーを壊さずに導入することが困難
  • テストが無い
  • 60pfsで描画されない
    • 乱数調整では1/60秒単位 でゲームの操作を要求されるため, タイマーも60fpsで動作してほしい
    • しかし今のemtimerは40〜55fpsほどしか出ていない
  • 多段タイマー機能がない
    • 1つ目のタイマーが終わったら, 2つ目のタイマーを開始してほしい(多段タイマー), という需要があるが, それをサポートする機能が今のemtimerにはない
    • Viewとタイマーのコアが密結合しているため実装が困難
  • コードベースが古い
    • アップデートをサボっていたせいでライブラリやフレームワークのバージョンが古い
    • 今だったらもっと格好良い書き方できるはずだけどフレームワークのバージョンが古くてそんなことはできない, みたいな状態

どこ弄ったらどうなるか分からないし, ちょっと弄ったらすぐ壊れるし, そもそも技術が古いのでコード書いてて特に楽しさはない*1.

これらの反省を踏まえて, Viewとタイマーのコアが疎結合で, テストがあって, 60fpsで動作して, ユーザからの機能拡張の要望に答えられ, ライブラリなどのアップデートに追従できるタイマーを開発しましょう, ということになった. 具体的にはVue.js v2からReactに移行 / タイマーのコアは単なるクラスとして切り出し, それを対象にテストを用意する / タイマークラスはReact Hooksを使ってViewと繋ぎこむ / CIとdependabotを導入する, といったことをしている.

今日は秒の位が切り替わる度に音を鳴らす仕組みを作っていた. Hooks使うとこういうのサッと書けて良いですね.

あと色々機能入れたらタイマーのコアのコードが膨らんできたので表現力の乏しいいくつかの機能を削って, 表現力の高い機能で置き換える, といったリファクタリングをしている. 雑にリファクタリングしたらめっちゃテスト落ちて困ってる. ちゃんと落ちてて安心だけど, それはそうと直すのはだるい...

*1:新しい技術なら楽しい訳でもないけど...

2020-04-28

ゆゆ式指向言語

カブ

92(買値)=>83=>80=>76=>73と順調に下がってきている. 先週波型という情報を加えてツールに入れたら跳ね小型5.16%, 減少型44.3%, 跳ね大型50.6%と出てきたのでまあまあ期待できそう.

hyperwiki.jp

余談だけどこのツール, 予想結果を共有する機能が付いていなくて皆がスクショで共有していて悲しい状態. 共有用のURL作成出来てほしい. そしてそのURLごとにog:imageでグラフを, og:descriptionで「跳ね小型XX%, 減少型XX%です」と出してほしい. ユーザページ作って私の株価これです, と紹介できるとより便利そう. ユーザが株価入力したらRSSが更新されて「今日の株価はこれです. 跳ね小型XX%, 減少型XX%です. グラフはこれです(OGP画像)」みたいな通知をSlackなりに流せて最高便利ですね*1. 僕は作る気無いので誰か作っておいて下さい.

Web API

仕事でWeb API実装してたのだけど, 実装を進め始めてからAPIからこのデータ返せないね, と気づくケースが何度かあったので再発防止したいねと考えていた. そういえば昔「API実装する前にまずはデザイナから貰ったXD内に写り込んでいる文字列にひたすら丸を付けて, それがAPIスキーマのどこと対応するか確認しましょう」という話どっかで見かけたなと思い出してそれをTRYにしたのだけど, どこで見かけたっけ. どこかのWeb記事で見かけた気がするんだけど忘れてしまった.

CD取り込み

そういえば最近CD借りてないなとふと思い出して20枚くらいガッと借りて取り込みしてる. 取り込みめちゃめちゃ面倒で, まずCDドライブで1枚スキャンするのに3〜10分掛かる. CDドライブには1枚しかCDが入らないので借りた枚数Nに対し, スキャンに掛かる時間がO(N)になる. なんで1枚しか入らないの.

スキャンが終わるとジャケット付けたりアルバム名修正したりとメタタグ整理をするのだけど, これもめちゃめちゃ面倒. メタタグはツールを使って有志が管理しているデータベースサーバから取ってくるようにしていて, 運が良ければ一瞬で期待通りのメタタグが付くのだけど, データベースサーバに対応するデータが無かったり, 登録されているデータが誤っていた場合は自分でデータベースを変更しにいかなければならない. アルバムアートが登録されていないくらいならまだマシで, 対応するアルバムのデータがない場合は「このアルバムにはトラックがn個あって, それぞれのタイトルはこれで, 再生時間はこれこれこうで...」とアルバムのデータを頑張って作る必要がある. 対応するアーティストのデータがない場合はそれも作る必要がある. だるい…

そして最後にGoogle Play Musicへとアップロードする. Google Play Music Managerを使ってメタタグを付け終わったファイルをアップロードすれば良い, のだけどたまにアップロードに失敗する曲があるのでエラーメッセージを見ながらチマチマ直す必要がある. あとアップロード出来てもGoogleにより全然違う曲だと判定されてVC入りの曲がinstrumentalになったり, full sizeの曲がTV sizeになったりするのでちゃんと全部再生してみて問題ないかを確認する必要がある.

scrapbox.io

今回は20枚取り込みして, 総作業時間4時間くらいだった. 4時間ずっとCD取り込みに束縛されるのしんどいので早く自動化されてほしい.

*1:とはいえひたすらRSSの更新通知が流れるチャンネル怖いと思う