mizdra's poem

雑なこと (日記/技術ポエム/メモ/…) を書くブログです. 真に受けないでください.

2018-12-30

掃除

年末大掃除をやった.

人間優柔不断がちなので一度に不要なもの全てが捨てられる訳ではなく, 掃除の回数を重ねていって初めて捨てる決断が出来るものが増えていく. ものを捨てるという判断は意外にMPを消費するし, それが沢山行われるとなると1回の掃除で捨てられる数には限度がある. 実際, 1回目は悩んで捨てられなかったものが5回目にしてようやく捨てられるなんてことがザラにあった. 掃除は積み重ねが大事ということですね.

とりあえず自室は攻略完了したけどあんまり家の人が掃除に関心がなくて家中割れ窓だらけなので, 来年以降は掃除範囲を自室以外へと広げていきたい.

ReLIFE

12話まで見て放置していたReLIFEの続きをAmazon Prime Videoで見た. BD&DVDに収録されている地上波未放送の完結編 (14〜17話)もAmazon Prime Videoで配信されていてありがたい. After Storyで追い打ちを掛けてくるのがCLANNADっぽくて優勝でした.

振り返り

毎年大晦日に1年の振り返り記事を書き始めて年内投稿失敗, という芸をやっていたのだけど, 今年の僕は優秀なので勝たせていただきました.

poem.mizdra.net

2019年も宜しくお願いします.

2018年を振り返って

年の瀬なので2018年振り返りやっていきます*1.

技術

まず技術関連の話. こちらは今年作ったものの一覧です.

この中で一番思い出深いのはWebAssembly関連のものでしょうか. 去年の振り返りで2018年はWebAssembly触ってみたいと言っていたのを実行するべく, 今年は本格的にRustを学び初めてその片手間でWebAssemblyをやっていくという年でした.

https://www.mizdra.net/entry/2018/10/17/080000www.mizdra.net

また, その副産物として「Rust を用いて WebAssembly の開発環境を構築する手法を紹介する電子書籍」を執筆・公開しました*2.

www.mizdra.net

本というものを初めて書いてみて分かったのですが, 技術書を書くのって本当に難しい… 書いた文章のことを自分が分かっていても, 読者が同じように理解できるとは限らないし, 知識量も人それぞれ. 加えて途中で飽きられてしまう可能性もあります. そのために対象読者を絞ったり, 流れるように読めるような章立てをし, 時には洒落を入れたりするのですが, それが難しい… けど人に技術を教えたり, 技術に関する文章を書いたりすることが好きなので, 結構楽しかったです. また機会があれば教材みたいなものを書いてみたいですね.

また大学の卒業研究では言語処理系に関する研究をしようと思っていて, 「Writing An Interpreter In Go」を買って読んだり, あれこれ記事を読んだりしています. 現状言語処理系の知識はインターネットの海に漂う情報を掻い摘んだ程度で理論的な事柄を全然把握できていないので, 来年以降は専門書を読んできちんと体系的に学んでいきたいですね.

労働

今年でB3になり進路のことを考えなければならない時期になったので, インターンシップに行ったり, アルバイトを始めたりしました.

GitHub

去年

f:id:mizdra:20181229235028p:plain

今年

f:id:mizdra:20181229234343p:plain

約2倍になっていてすごい. めでたい. 去年と違って大学の講義で作ったプログラムも積極的にGitHubで管理するようになったというのもcontributionsが増えた要因の1つですが, 一番の要因は開発の速が上がったことでしょうか. 2017年の終わりあたりから「速が出てきたな〜」と感じていて, それが数字として現れているみたいです. 来年は1000 contributions超えたいですね.

アニメ

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

  • 2018冬
    • 三ツ星カラーズ: 優勝
    • ポプテピピック: 良い
  • 2018春
    • シュタインズ・ゲート ゼロ: 良い
  • 2018夏
    • 劇場版 のんのんびより ばけーしょん: 優勝
    • シュタインズ・ゲート ゼロ: 良い
    • ヤマノススメ サードシーズン: 優勝
    • ハッピーシュガーライフ: 最高
    • 進撃の巨人 Season3: 最高
    • One Room セカンドシーズン: 最高
  • 2018秋
    • 転生したらスライムだった件: 良い
    • ソードアート・オンライン アリシゼーション: 最高
    • ゴブリンスレイヤー: 最高
    • 色づく世界の明日から: 最高
    • となりの吸血鬼さん: 良い

「ヤマノススメ サードシーズン」, 最高でしたね. 全然山に登らずに仲違いして仲直りを高速に繰り返していたという話も聞きますが, 仲違いして仲直りも上下運動みたいなものですし, 実質山登りですよ. ヤマノススメです.

三ツ星カラーズも最高でしたね. 回を追うごとに引き込まれる感じがゆゆ式っぽかったです*3. OP&EDも好みの感じで良かった.

音楽

小中高と音楽や漫画にあまり興味を持たず過ごしてきてつい最近まで全然音楽や漫画を消費してこなかったのですが, 今年は割と積極的に消費していたのでその振り返りもしてみます. 音楽といっても99%がアニソンですが...

以下, 今年放送されたアニメのアニソンTop10*4. 公式からMVや試聴動画が配信されているものはリンクを付けておきました*5.

あとこれは2018年に放送されたアニメとは全く関係のない曲から選んだ, 「今年よく聞いたアニソンTop10」.

以前日記でも触れたけど元気で明るい曲が好きなので「今年放送されたアニメのアニソンTop10」にはそれが濃く出ていることがわかる. あとYURiKAさんが歌う曲は大体好みということがわかる.

漫画

amakan見ながら今年読んで良かった漫画をリストアップ. amakan最高.

  • 宝石の国
  • 甘えたい日はそばにいて。
  • 箱入りドロップス
  • がっこうぐらし!

去年見た宝石の国のアニメが優勝ものだったので, 続きが気になって原作を買いました. 毎巻「Oh...」という感じの内容でダメージが大きすぎる. 続きが楽しみですね.

「甘えたい日はそばにいて。」は幸腹グラフィティと作者が同じで気になって買ったという感じです. 今年読んだ漫画の中では一番パワーが強かったです. すごかった. それでいうと「箱入りドロップス」も同じパワー強い系でしたね. 元々きらら展で展示されていたイラストを見て気になって思い切って買ったものだったんですが, 大当たりでした. 最終巻を読んだ上できらら展の図録を見るとウオーになれて便利です. それと後から気づいたんですが図録の漫画の右列4コマ目, よく見ると良いモノが写り込んでいるので図録持っている方は今すぐ見ましょう.

おわりに

今年は本を書いたり, Rust/WebAssemblyを学んだり, 労働を始めたり, 音楽や漫画といったカルチャーに手を伸ばし始めたりと新しいことづくめでしたね. 2019年もやっていきましょう.

去年の目標の達成率

  • WebAssemblyで何か作る: O
  • Fluxで何か作る: △
  • サーバサイドの勉強をする: X

来年の目標

  • 英語の勉強をする
  • サーバサイドの勉強をする
  • 最高のWebサービスを作る
  • 言語処理系の勉強をする

*1:3年連続で年内投稿間に合わない芸をやっていて今年も間に合わないだろうと期待していたファンの方々, すみません. 今年は勝たせて頂きます.

*2:執筆はjs-primmerJavaScript Promiseの本などインターネットで公開されている書籍を参考に行いました. 大変お世話になりました.

*3:アニメ自体のテーマや雰囲気は全然違いますが

*4:https://twitter.com/Mitu217/status/1078944147237531649 をから体を拝借しています.

*5:公式なんだけど公式であることを示すバッジが付いていないチャンネルが多くて確認作業が大変だった… 困るので各位ちゃんと付けておいて欲しい…

2018-12-26

情報収集

最近情報収集をちょっとサボっていたので冬休みを使って消化している. あまりにサボりすぎてPocketsの底は見えないし, Chrome for Androidのタブ数は :D になっていてとにかく大変. 頑張って消化していきたい.

一応サボらないための工夫はあるのだけど, 感情を利用した素朴なものだったりする. 「Twitterにシェアする記事は基本的に最後まで読んだものにする」という, とにかく最後まで読むことを強制するというもの. 特に良い記事の場合は「良い記事なのでシェアして皆に見てもらいたい!」という心理が働くので, 結構効果的に機能する.

結局「時間的」余裕が無いことよりも「心理的」余裕が無いことにより情報収集をサボることが多い気がしていて, 今回サボったのもその面が大きい. もう少し心理的な障壁を無くす工夫を考えていきたい.

bet

Webフロントエンド周りの情報収集しながら, 今後Webフロントエンドはどんな技術・ライブラリが躍進し, 衰退するのかを考えていた. 例えばWebComponent, Preact, WebAssembly, off the main thread, React vs Vue.js, Node.js vs deno, TypeScript vs other AltJS, Rust/WebAssembly vs AssemblyScript/WebAssemblyといったもの. どれが筋が良いか, 将来的に成長するか, 信頼できるか, どれにbetすると将来的に幸せになれるか. 必ずしも答えがあるものではないので無駄かもしれないけど信頼できないものに足元を任せるのは怖いので, よくこういうことを考えている.

最近のJavaScriptはTypeScriptのお蔭で治安良くなってきたし, 暫く (3年くらい) はJavaScriptにbetし続けて良い気がしている. 実際rust-wasmを見ていると (これはrust-wasmの思想というよりはwasmの思想だけど) WebAssemblyとJavaScriptの共存を考えて*1/既存のWebのエコシステムに載るよう設計されているし*2, 過去のDartのようなJavaScriptを完全に置き換える野心的なプロジェクトも (観測している限りでは) 見かけない. Proposalに上がっているPipeline OperatorPattern Matchingも仕様に入れば今よりは書きやすくなるだろうし, 割と楽観的に見ている.

WebAssemblyはどうだろう. 現状Rust/WebAssemblyの情報はwatchしているけど, バックにMozillaが付いているので見ていて安心感が凄い. wasm-bindgen, js-sys, web-sysなど, JS-wasm間の穴を埋めようとする動きが活発なのも良い. あとwasm-bindgenはHost Bindingsのpolyfill的な位置づけになっているのもちゃんと未来を見据えている感じがして信頼できる. どうでも良いけどrust-wasm関連のプロジェクトの大多数にalexcrichton氏が関わっていて異常. どこ見てもalexcrichton氏が出てくる. すごすぎる.

AssemblyScriptは全然watchしていないのでよく分からないけど, 静的型の付いたJavaScriptを書いていたら勝手に速くなっていたという未来は確かに来て欲しい. 折角静的型があるのに今はそれをトランスパイル時に削ぎ落としてしまっていて勿体無いと思っている. それでいうとdenoにも注目していたりする. よく分かってないけどMicrosoftあたりがTypeScriptをLLVMにコンパイルするコンパイラ作ればdenoにもwasmにも使えてハッピーそう?

React vs Vue.jsについても考えてみる. 個人的には界隈全体が生のJavaScriptからTypeScriptへと移行していく流れがある中で静的型が付きにくいAPIをしているVue.jsは中々近寄りがたい. Vue.js v3では本体がTypeScriptで書き直されるとの話があるので, JavaScriptから触れるAPIは静的型が今よりもずっと付くだろうけど, 現状エディタによる型支援が受けられていないtemplateはv3でも殆ど変わらないと言っているので不安になる. と思ったけどtemplateにsource mapが付くという話もあるので, それで解決されそう? Reactは新しく登場した/登場するHooksやSuspendを使ってコンポーネント構築のベストプラクティスを探していく段階にあると思っていて, また暫く賑やかになりそう. 来年はReactを積極的に使ってみようかな.

*1:「WebAssembly は JavaScript と異なる言語ですが、その置き換えを意図していません。」引用元: WebAssembly のコンセプト | MDN

*2:rust-wasmはスレッドにwebworkerを, スレッド間のリソース共有にSharedArrayBufferを利用しており, 車輪の再発明を避けている. 参考: Multithreading Rust and Wasm | Rust and WebAssembly

2018-12-10

ゆかりスロット

www.mizdra.net

1ヶ月前に作ったアプリをゆゆ式 Advent Calendarで紹介したらバズってTwitterのトレンドに載ったり*1, 有名な漫画家の方々に遊んでもらったりした*2*3 *4. とにかく自分の想像以上に色んな人に遊んでもらえたようで驚いてる. SNSの拡散力はすごいですね.

shiki

自作言語「shiki」とそのインタプリタ開発の話. 今日はGo言語でつくるインタプリタの1章3節〜2章4節を読んだ. 読んだ際のメモを以下に貼っておく.

  • 1章
    • 字句解析について
    • テスト駆動で簡単なトークンから字句解析していく
    • 小さく始めるに当たって, それぞれの文字をどのような粒度でトークンとして扱うかについて決める
    • 数字や複合文字などは1文字ずつ空白まで読むようにする
    • 言語によって空白や改行を無視するなどの戦略を決める
      • その言語にとって意味を持つか持たないかを考えると良い
    • 2文字トークンを実装する際には先読みを用いると良い
    • 言語によるパースの難易度の違いはソースコードを解釈する際に, どの程度先まで読む必要があるかに依存する
  • 2章
    • パーサとは「入力を入力を表すあるデータ構造へと変換する」もので, 変換の過程で入力が期待された構造に従っているかをチェックする
    • 抽象構文木の「抽象」とは
      • セミコロン, 改行文字, ホワイトスペース, 波括弧などのASTとして不要なものを排除するため
    • 今回は「前章で作成した字句解析器の出力」を入力とし, 「インタプリタが要求する仕様を満たすような独自のAST」を出力とする
    • 本書では構文解析法の違いについて詳細に立ち入らない
      • ドラゴンブックなどを参考にする
      • パーサの高速化や正当性に関する形式的な証明, エラーリカバリ, 構文誤りの検出なども行わない

2章はパーサの作り方について書かれているのだけど, 大抵パーサの実装は複雑になりがちなため, 「学習目的のため作成するパーサにどういう機能を実装し, 逆にどういう機能は実装しないのか」について注意深く書かれている点が面白かった. 本書の冒頭の「はじめに」の章でも語られているが, 本書は一貫して「インタプリタがどう動いているか知りたい人向けの, 特定の理論や数学的な知識を前提としない, 学習目的のインタプリタを作る方法」について書かれており, その思想が2章によく反映されている. 例えばletによる代入文やifなどによる制御構文は扱うが, パーサの高速化や正当性に関する形式的な証明, エラーリカバリ, 構文誤りの検出などは扱わない. それらが無くともインタプリタの仕組みを理解するのに十分なので, 意図的に省かれている. それらを省く際にその理由も同時に説明していていて, 何というか, 安心して読めるような内容になっていて良い.

*1:人によってカスタマイズされているので一概には言えないけど, 少なくとも僕のアカウントから見たトレンドには載っていた.

*2:https://twitter.com/mikamikomata/status/1071833085031763968

*3:https://twitter.com/_namori_/status/1071834010211409921

*4:https://twitter.com/1093yuiko/status/1071854769793187841

2018-12-06

shiki

大学でプログラミング言語とその処理系を実装する実験をやっていて, Rust-likeな構文を持つ小さな動的型付け自作言語「shiki」*1とそのインタプリタをRustで作っている. 折角一から言語を設計するのでlexerもparserも自作しようと思って, lexやyaccを頼らず自力で実装している.

最初のうちは同じようにRustでインタプリタを実装しているわだまるさんの tsuyoshiwada/rs-monkey-langを参考に書いていた. けど字句解析や構文解析の方法が全然分からないまま手を動かしていて, 流石にこれでは良くないねということで Writing An Interpreter In Go を購入して読むことにした. ただ書写するのではなく, ちゃんと背景を知った上でインタプリタを実装できるようにするのが当面の目標. とりあえず土日はこれ読んで勉強します.

*1:名前の由来は式指向言語とゆゆ式の「式」から

TikToker whywaita

こんにちは. 電気通信大学MMAというサークルに所属するmizdraといいます. 同じサークルに所属するwhywaitaさんとは先輩(whywaita)・後輩(mizdra)の関係にあります. この記事はwhywaita Advent Calendar 2018 6日目の記事です.

adventar.org

そしてこちらは部室に転がっていたTikTokロゴのヘアピンを装備したTikTokerのwhywaitaさんです.

youtu.be

以上です.

2018-12-01

12月

12月です. 12月は例年Advent Calendarの記事をひたすら書く関係で忙しいのだけど, 今年はそんな張り切らない予定なのでそこまで忙しくならないはず. 例えば今年のPokémon RNG Advent Calendarの1日目の記事は2000文字ちょっとくらいで書いている. 2016年は15000文字, 2017年が5000文字だったことを考えると大分控えめになっていることが分かると思う.

www.mizdra.net

憑依駆動執筆

2018-09-22にprivate Scrapboxに書いたまま寝かせていたエモい文章を発見したので, 折角なので少し修正してここに載せておきます.


最近, 3つの記事を同時に書くことがあった.

体験記や紹介記事の執筆は何故だか全然速が出なかったのだけど, 聴覚情報処理障害の執筆はめちゃめちゃ速が出た. 強い当事者意識があったからというのも大きな理由の一つだが, 他にも「著者を憑依させていた」ことが関連しているのではないかと考えてみた.

障害の記事ではいつもと違う文体で書かれている所にそれが表れている. これはそういう文体で書く人を頭の中でイメージさせ, その人だったらどう書くか, ということを想像しながら書いた結果である. これを僕は「憑依駆動執筆」と呼んでいる. 憑依させる人物は実在しない仮想的な人物でも良い. その人が書きそうな文章さえイメージできれば良い. ちなみに障害の記事では慎重に議論を展開させる人を選んだ.

この憑依という行為は以前から知っていた訳でも誰かから教わった訳ではなく, 障害の記事を書いている際に自然とそういう書き方をしていることに気づいたのが始まりである. インターンシップ体験記より障害の記事のほうが明らかに書く速度が速かったので, その理由を考えたら「もしかしたら憑依しているのではないか」という考えに行き着いた.

この憑依を使いこなせれば, もっと記事を上手く書けるのではないだろうか, とも考えている. 実際, 障害の記事は以下の点がよく抑えられた良い記事になっている.

  • 本人の実体験や感想を含む
    • 大げさに, 真剣に, 慎重に
  • 障害の情報や障害者に役に立つ情報を記載する
    • 丁寧に, 正確に

憑依をすることで, 書いている間にどういう論調で文章を展開していくかが次々と分かるようになる. 暗い洞窟の中を明るいランタンを持って歩くような感覚. 憑依モデルが良いほどランタンは明るくなり, より速く歩くことが出来るようになる.

憑依するタイミングは記事を書き始める時が良いかもしれない. 展開していく文章の論調が統一されてなければ, 文章としての完成度は低くなってしまうだろうから. 記事を書いている途中で憑依させ, 論調を変えるのは読者を混乱させてしまう. ランタンを付けるタイミングは洞窟に入る前のほうが良い. 途中で付けても既に迷っていて, 出口に辿り着くまでに苦労するだろうから.

自我がどこへいってしまったのかという問題はあるが, 良い憑依モデルを採用すれば, 良い記事が書けるというメリットは少なくともあるはずである. 早速, 進捗の悪いインターンシップ体験記で試してみようと思う.

ちなみにこの記事の憑依モデルはひとでくんさんです. 比喩の所にそれが表れている (と思う).