mizdra's poem

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

2019-01-13

日記 ポエム 漫画

緊張感を設定する

GitHubの芝見ると分かるけど, 無気力すぎて去年の6月くらいからコード書く回数減っている. 以前までは何か思い立ったら我武者羅にすぐにコードを書く, みたいなことをしていたのだけど, それをやらなくなったのが6月くらいだった気がする. やらなくなった, というよりはやる気力が中々湧いてこない. やるぞ！！！ｳｵｰ！！！ﾊﾞﾘﾊﾞﾘﾊﾞﾘｰｰｰｰ！！！みたいな機会が減ったという感じ.

多分, 緊張感が足りなくなったのが原因なんだろうと思う. 以前は憧れのエンジニアを頭の中に思い浮かべて追いつく気持ちで活動していたのだけど, 4, 5月くらいから意識しなくなった気がする. 憧れのエンジニア, なりたいエンジニア像を設定して自分の能力と比較し, 緊張感を持たせる. そうして気力を引き出していたように思う.

趣味や自分の主張が時間の経過と共に綻び変わりゆくように, なりたいエンジニア像というものも綻びていく. だから適切なタイミングで緊張感, 頭の中の憧れのエンジニアを再設定する必要がある. 恐らくその時期がやってきたということなんだろう. とりあえず頭の中で思い浮かんだ数名を設定しておいたので, これからは緊張感出してやっていきたいですね.

がっこうぐらし!

土曜の話だけど, がっこうぐらし! 11巻を読んだ. こっちは(別の意味で)常に緊張感MAXで良いですね. 巻を追うごとに丈槍由紀さんと恵飛須沢胡桃さんが強くなっていてすごい. 次巻で最終巻らしいが果たしてどう終わるのか…気になる…

がっこうぐらし! (11) (まんがタイムKR フォワードコミックス)

がっこうぐらし! (11) (まんがタイムKR フォワードコミックス)

ポエム

普段どんなこと考えながらプログラミングをしているか, ずっと整理してみたかったので, 雑にScrapboxに書いてみた.

scrapbox.io

2019-01-05

日記

インタプリタ

今日もせっせと例のインタプリタを作っていた. 取り組んだのは評価器. まだ一部の式のみしか評価できなくて, 代入文やラムダ式は明日以降取り組む予定.

それとインタプリタ作っていて思ったことを言葉にした.

具体的には以下のような問題に遭遇した.

  • 失敗例1: 無の状態からインタプリタを作る際に, ある1つの言語機能 (例えば数値演算) がREPLで評価できるようにlexer, parser, evaluatorを一気に実装する
    • lexer, parser, evaluatorのそれぞれのドメインで必要とされる知識や概念が多くて詰まる
    • そもそもlexerやparserがlexer+parserではなく個々に分けられているのは, 巨大なために分割統治された結果であるから, 分割された領域ごとに取り組んだほうが良い
    • ドメインの依存関係が最初から多すぎるというのも問題
      • lexerだけ作るならlexerに対する依存関係はlexer->tokenくらいだが, parserも実装するとparser->{lexer, token, ast}の依存関係が発生する*1
      • evaluatorも実装するとevaluator->{parser, object, env, ast}が追加される
      • この状態でlexerのAPIを変更するとparserだけでなくevaluatorなども影響を受ける可能性がある
        • それがAPIの仕様変更が頻発する開発の初期段階で発生する
  • 失敗例2: パーサを作る際に「代入文もreturn文も式が使われているし, 式文を先に実装したら楽なのでは?」と考え式文から実装し始める
    • パーサ設計の中で一番難しいのが式のパース
    • 前置演算子と中置演算子の区別, 制御構文(if式, while式, ...), 演算子の優先順位など扱う要素が沢山ある
    • 途中で辛くなってブランチを放棄した
    • 最終的には書籍と同様に式のパース処理をダミーの処理にして代入文やreturn文を先に実装し, パーサのプロトタイプをある程度作ってから式文に取り組む方式に移行した
  • 失敗3: 評価器を作る際に最初から環境 (変数などのランタイムデータを保持するアレ) を考慮したコードを書く
    • 式文の評価だけ行うなら環境は不要 (なはず) なので, 環境を考慮せず式文からやるのが正解

小さいと思ったドメインが大きいとびっくりするし気が滅入ってしまうので, 正確にドメインの大きさを見定めるのは大事. が, よく分かってない分野では見定めるだけの能力を持っていないので失敗しがち. もうちょっとドメインの調査に時間を割いておけば良かったのかなあ. でも無限に調査する時間があったら手を動かしたほうが良い気もする. 上手くバランスを取っていきたい.

*1:厳密に言うとparserはtokenだけ受け取れればlexerに直接依存する必要はないが, lexerとtokenは強い依存関係にあり, そのtokenと間接的に依存しているので候補に上げている

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をやっていくという年でした.

www.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-primmerやJavaScript 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 OperatorやPattern 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

日記 shiki

ゆかりスロット

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:名前の由来は式指向言語とゆゆ式の「式」から