mizdra's poem

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

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の更新通知が流れるチャンネル怖いと思う

2020-03-05

Flutter

最近Android/iOSのクロスプラットフォームなアプリ作りたくて技術選定をしている．ionic，react native，PWAなどを検討していたけど，どれもあまり気乗りしない / 役不足で困ってる．

そんな中，Flutter良いよ〜と人からオススメされたので触ってみた．とりあえず公式チュートリアルやってみたので，感想を書き留めておきます．

  • 環境構築が思いの外簡単
    • モバイルアプリ開発は環境構築が大変というイメージがあったのだけど*1，意外とサクサクできた
    • 基本的にはガイド通りにやっていけば良い
    • 困ったら flutter doctor 叩けば開発環境の不備と修正方法を教えてくれる．便利〜
  • Dartは雰囲気で書ける
    • Dart書いたこと無いけどFlutterのチュートリアルの範囲内では一度もDartのドキュメント見ずにコードを読み書き出来ている
      • 見た目完全にJavaだしJavaが読めればDartも読める
      • 「Dartを書いたことない」はFlutterの採用を避ける強い理由にはならないなと感じた
        • まあ人によってはJava風の構文に馴染みが無くて強い理由になったりするかもだけど
    • 冗長 / 古臭い 等様々な声があると思うけど，一方で多くの人にとって取っつきやすいのは強力な利点だと思う
  • コード修正 => デバイス側に反映 のサイクルが爆速で回せる
    • hot reloadイケててすごい
    • ガイドや各種エディタのプラグインでもhot reloadを全面に押し出していて，かなり力を入れていることが伝わってくる
    • Node.js界隈のHMRよりは安心感がある
      • 2年前くらいに初めてHMR触ったときはCPU使用率がすぐ100%になるなど使い物にならなくて，それ以降ずっとHMRは入れていない．最近どうなのかは知らないけど…
        • 少なくともFlutterはそういう場面まだ遭遇してない

開発ツールがかなり充実していて，綺麗なレールが敷かれている感があった．チュートリアル一通り終えても「この技術はちょっとな〜」となることはなく，むしろ続けてFlutter使ってみたいなと思える程度には満足度高かった．ひとまずFlutter採用する前提で進めて，作りたいアプリを本当にFlutterで作れるのかプロトタイプを作って調べてみます．

調子とまぶた

今日はなんだか気分が良いな〜なんでだろう〜と思いながら過ごしていたら，鏡を見ているときに気づいた．普段は左まぶたが右まぶたより1〜2mmくらい大きく開いているのだけど，今日は0.5mmくらいだった．調子とまぶたに相関ってあるのかな… 左右のバランスが整うことで調子が良くなったという可能性はありそう．何もわからないけど…

思考

ゆゆ式の「シュポーン」思い出した．

そういやゆゆ式って本やインターネットから誤字を見つけて喜ぶシーン一切ないなと気づいた．外部から提供されるネタには一切頼らずに，ゆずこ・唯・縁の3人で題材を見つけてきて，それをネタに昇華させているイメージがある．本日の気づきでした．

*1:まあWebフロントエンドのほうも大概だけど…

2019年を振り返って

振り返り

年の瀬なので1年の振り返りをします.

※年内投稿チャレンジ失敗したので, 各自「今年」を2019年, 「来年」を2020年に読み替えてください.

技術

まず技術関連の話. 今年作った技術的成果物一覧です.

  • Now Browsing ツール (1〜9月) (WIP)
    • Twitter で Now Browsing するツール
    • 普段 Tweet: Now Browsing! や Omnitweety を使って Now Browsing してるのだけど, いまいちイケてないな〜と思って自作してる
    • 日常的に触るツールになるので, 結構気合入れて作ってる
      • ちゃんと要件定義したり, プロトタイプで実際に機能するのか確認ながら技術選定したりと丁寧にやってる
      • 丁寧にやりすぎて開発着手から9ヶ月経った今も完成してないのだけど, まあそれも個人開発の醍醐味だよねということでのんびりやってます
    • 来年の夏までにはリリースしたいな〜
  • ターミナルエディタ (3〜4月)
    • 大学のネットワークプログラミング実験の課題でターミナルエディタを作った
    • 実はエディタ自体は去年の10月に完成していたのだけど, コードは公開してなかった
      • 折角面白いプロダクト作ったので皆に見てもらいたいな〜と思って, 3月くらいからちまちま公開作業してたのでした
    • その成果がこちらです: mizdra/minimum-ot-editor
    • 見どころ
      • 複数人で同時編集できる
        • Operational Transformation というアルゴリズムを採用することで, 変更箇所が衝突しても良い感じに変更されるようになってる
        • 同時編集の様子: YouTube
      • サードパーティライブラリを一切使わずターミナルエディタを実装
        • ターミナルにはANSI Escape Sequenceと呼ばれる一部の文字列をターミナルを制御する特別な文字列として扱う機能がある
        • これを使って, エディタ画面のリフレッシュやカーソルの移動を実現してる
      • 現代的な C 開発環境
        • Language Server Protocol (clangd) 関連の設定仕込んだり, フォーマッタ (clang-format) 導入したり
    • 本当は記事も書いて紹介したかったのだけど, 力尽きてしまった
      • 今度 WebAssembly + WASI + Emscripten で ブラウザでデモ動かせるようにしようと思ってるので, それが出来たら記事書こうかな
  • フリーマーケットのレジシステム (10〜11月)
    • サークルの学祭の出し物で「ジャンク市」という怪しい市を開催していて, その市で利用するレジシステムを作っていた
    • レジシステム自体は今までの学祭で何度か作ってるのだけど, システムが複雑すぎて誰も継承できず毎年作り直す羽目になってる
    • 流石にそれじゃイカンだろう, ということで今年は巨大な出来るだけシンプルな構成で作り直してみた
      • 技術スタックは Node.js / express / REST API / prisma2 / Next.js / TypeScript / passport.js という感じ
        • 巨大なWebフレームワークは使わず, シンプルな技術を組み合わせで構築してる
        • 後はバックエンド・フロントエンドの言語をTypeScriptで統一したことで, TypeScriptさえ読み書きできればメンテできるようになってる
        • Next.js はWebフロントエンドのビルド周り任せるために入れたのだけど, これはまあ微妙な選択だった気がする
          • SSR要素必要ないので Parcel + React でも良かったと思う
    • 技術的挑戦という話だと, バックエンド・インフラ・ハードへの挑戦が挙げられる
      • passport.jsで部のLDAPサーバと連携してLDAP認証したり
      • 今話題のSameSite=Strictをセッションcookieに付けて「外部サイトからアクセスするとログアウトされた状態になってる〜」とかやったり,
      • 部のサーバにlxd入れてSystemdでサーバプロセス管理したり
      • DNSレコードやnginxの設定弄って部内サーバ上のWebサーバを外部に公開してみたり
      • レシートプリンタ使って値札やレシートを印刷してみたり
      • こういう普段触らない部分触れるのは色々勉強になって良かったです
        • 普段Netlifyで完結するようなWebアプリしか作ってないので, バックエンド・インフラ・ハード触る機会全く無いんですよね
        • 実際触ってみないと分からないようなところが分かるようになったのは大きかった
  • 今日のゆゆ式 (12月)

去年と比較すると成果物は半減してるけど, まあ今年は色んな分野に手を伸ばせたのでトントンという感じですね. 来年は色んな分野に手を伸ばしつつ成果物の量を増やしたい.

GitHub

去年

f:id:mizdra:20181229234343p:plain

今年

f:id:mizdra:20200101021201p:plain

ついに1000の大台に... と一見めでたいように見えるのですが, 300 contributions くらいはお仕事の分で実際には去年とほぼ変わらないです. 開発の速は次第に上がってるけど, 開発に割ける時間が減ってきていて伸び悩んでます. 来年こそ個人開発だけで 1000 contributions 超えたい.

アニメ

animetickを見ながら良いと感じたアニメを列挙するコーナー. 良い << 最高 << 優勝 の順でランク付けしていきます.

  • 2018冬
    • 私に天使が舞い降りた！: 優勝
    • 約束のネバーランド: 優勝
    • かぐや様は告らせたい～天才たちの恋愛頭脳戦～: 最高
    • 転生したらスライムだった件: 最高
    • 賭ケグルイ××: 最高
    • 五等分の花嫁: 良い
  • 2018春
    • 進撃の巨人 Season3 Part.2: 最高
    • 鬼滅の刃: 最高
    • ぼくたちは勉強ができない: 最高
  • 2018夏
    • 女子高生の無駄づかい: 優勝
    • からかい上手の高木さん②: 優勝
    • 鬼滅の刃: 最高
    • まちカドまぞく: 最高
    • 彼方のアストラ: 最高
    • ダンジョンに出会いを求めるのは間違っているだろうかII: 良い
  • 2018秋
    • BEASTARS: 優勝
    • 慎重勇者～この勇者が俺TUEEEくせに慎重すぎる～: 最高

「女子高生の無駄づかい」がめちゃめちゃ良かったです.

アニソン

今年ハマったアニソンの中でイチオシの曲を紹介するコーナーです.

しんみり/さわやかな曲に弱いことが分かる.

漫画

今年のイチオシ漫画を紹介します.

『微熱空間』が今年のベスト・オブ・漫画です. 最近ラブコメ結構好きだということが分かりつつある. 来年はラブコメ方面でもうちょっと漫画漁ってみたいですね.

おわりに

2019年もやっていきましょう.

*1:自炊(2日) + プログラミング(1日) = 3日