MJHD

エモさ駆動開発

2023年振り返りと抱負

去年のやつ:

mjhd.hatenablog.com

 

師走と言いながら今年はゆっくりした年末年始を過ごしております。

前職よりお仕事がちゃんと定時に始まって定時に終わっており、連勤も徹夜も残業もなくてすごい。

去年一昨年の抱負であった「均し」は割と達成できたかなという気がしています。

 

代わりに趣味に使う時間が増えた。

お勉強

あんまり体系だったアカデミックなことはあんまりしてないです。

必要に応じて調べ事するぐらい。活動時間が減ったわけではないので正常かなと思ってます。

お仕事・技術

お仕事でキメを作らなければいけないことが増えたので、「今まで惰性でこういう技術選択してたけどなんでだっけ」と振り返る機会が増えました。

最近は技術的なこだわりって結構どうでも良くて、明確な要点だけ押さえたら後は有象無象がそのうち完成形へ収束していくんだよなぁ~という気持ちになってます。

はたから見たら急に変なところにこだわりだすな~って思われてそう。

 

人生みたいなもの。

趣味

VRChat

1年続きました。めっきり音楽イベントばかりになっちゃいましたが。

最近はワールドづくりを始めてUnityの知識が徐々に増えてきています。お仕事の片手間にシェーダーっぽいの書いてたことあったんですが、あの辺の知識やらエミュレータ作りやら3Dゲーム数学、Flutterのレンダリング周りなどここ数年の知識が実際の技術に結び付いてきた感あって楽しいです。「役に立ったかは分からないけど、脳内で概念が結び付いて楽しい」という状態です。

来年はUnityやRust、シェーダーなどの趣味技術系のエンジニアコミュニティにたくさん入れるといいな。

DJ

DJ初めて1年ぐらい経ちました。何も分からないままrekordboxというソフトがあることだけ調べて、音源を集めてUSBに放り込んだのが2022/12/3でした。

翌日の12/4、少人数の前とはいえいきなりDJ機材で50分ぐらいのセトリをやったのはなかなか頑張った気がする。

当時のプレイリスト見てみるとこんな感じ。いつもDJを聴きながら曲を集めていたので、当時聞いていたDJさんたちの趣向が強い気がしてます。

なんでラジオ体操第一が入ってるんだ

2022-12というプレイリスト

その後も月一程度で身内で発表していました。DDJ400を知人に譲ってもらったのもこの辺です。

そして、2023年2月に勢いでVRDJデビューした記憶があります。

そこから始まりちょうど30件のイベントに出させていただきました。ありがとうございます。

DJ出演履歴 (notion.site)

 

DJはいくらやってもなんも分からん。

DTM

DJ始めたらDTMも始めることになりますよね。多分。

いくらかRemixを作ったりちょっとした音遊び的な曲を作ったりしています。

DTM日記 (notion.so)

 

まだまだやること多そうで良い趣味。

お絵かき

半年ぐらいやってないかな?

一旦お絵かきは中断です。そのうち再開するかも。

まとめ

VRChatとDJとDTMをしてた。

来年は趣味の技術方面を伸ばしたい気持ち。

2022年振り返り 学んだことと来年の抱負

去年の振り返り

mjhd.hatenablog.com

 

早いもので一年も終わり。年々一年経つのが早くなっており、今年は3か月分ぐらいの記憶しかありませんが、振り返ってみたいと思います。

今年学んだこと

今年も、例年に引き続き

  • 低レイヤー周り
  •  CS・数学
  • 哲学・思想

の三軸で色々お勉強をしました。

 

低レイヤー周り

OS

去年の抱負にもあった「OS自作本」ですが、有休消化期間を使って進めました。(実は転職したんです)

ゼロからのOS自作本

ゼロからのOS自作入門 | 内田 公太 |本 | 通販 | Amazon

 

結果としてx86の闇を知ることができたり、マルチタスクの仕組みなど学ぶことができました。x86、OSを作るための機能がモリモリで、逆にARMとかどうしてるんだと心配になっています。

本を進める中で、いくつか罠を踏んでトラブルシューティングをしたのですが、こういった経験ができたのも大きな学びだったなと思いました。

github.com

 

PlayStationエミュレータ

去年の抱負では「GBAエミュレータ作りの続きをやっていきたい」と書きましたが、気が付いたらPlayStationエミュレータ作りに変わっていました。

詳しい内容は記事に書いたのですが、MIPSアーキテクチャに親しみが持てるようになったのは大きな学びだったなと思っています。

また、今までのレトロゲームとは違い、ようやくGPUに近いプロセッサを実装したので、世のGPUドライバがどんなことやってるんだろう~、という疑問がなんとなく想像ついた気がします。

 

現在はCDドライブの実装を続けており、BIOSがデータの読み出しを行ってDMAによってRAMに転送されるところまでは動いています。が、そこから先まだ動作しないため要実装です。何かROMが動くと良いな。

zenn.dev

github.com

 

Flutterのリンダリングパイプライン

これは比較的高レイヤーにはなるのですが、Flutterのレンダリングパイプラインについてたくさん勉強をして記事を書きました。

お仕事でFlutterを触る機会も増えたため、豊富なドキュメントやソースコードを読み漁りました。

PlayStationエミュレータ開発の知識も相まって、GPU~ブラウザの間で行われている処理について何となく全体感が分かるようになってきました。

また意外にも、FlutterとChromeは関連するところが多く、Flutterを学ぶことでWebフロントエンドについても理解が深まりました。もっというとFlutterはReactにも影響を受けているので、少し距離を置いてReactを見つめなおすことができました。

こういう、無関係に思える概念同士が繋がる瞬間はとても楽しいですね。

developers.cyberagent.co.jp

zenn.dev

 

関連して、Flutter系の記事執筆や登壇をしました。一年間で十分深ぼれたんじゃないかな…満足です。

アクセシブルFlutter: Semantics入門 (zenn.dev)

Flutterの課題、Early-onset jankとは何か (zenn.dev)

FlutterのRaster Cacheを追ってみる (zenn.dev)

Flutter前史: ChromeがFlutterになるまで (zenn.dev)

Flutterリプレースの難易度と取り組んだこと | CA BASE NEXT - CyberAgent Developer Conference by Next Generations

 

その他

CHIP-8のエミュレータをzig言語で書いてみたり、学生時代からメンテしているアセンブラとシミュレータが新しい本で採用されたので、アプデを行ったりしていました。

mj-hd/zhip8: chip-8 emulator in Zig (github.com)

mj-hd/ASC-Simulator-and-Assembler: 「算数で読み解く コンピュータのしくみ」より、ASC用アセンブラとシミュレータ (github.com)

gihyo.jp

 

CS・数学

今年はフワフワしてる分野の学び直しを重点的に学習しました。

線型代数(学び直し)

学部でやったころの記憶が完全に吹っ飛んでいたので、放送大学の「線型代数学」を受講しつつ、「実例で学ぶゲーム3D数学」を読みました。

ジョルダン標準形までの一通りを放送大学で復習しつつ、ゲーム3D数学の本で幾何的イメージを付ける、といった流れで実際の活用例まで理解することができ学びだったなと思います。

低レイヤー周りの勉強とも繋がってきて、GPU周りの用語や概念はゲーム3D数学を読んだ後だとスッと入ってきました。

bangumi.ouj.ac.jp

www.oreilly.co.jp

 

統計学(学び直し)

仕事でFlutterのパフォーマンスチューニングをしていて、「統計的有意な差がある」とは何なのか、ちゃんと説明できなかったので学びました。

放送大学の授業内容は理論的な話に持ち込まず、いろいろな統計手法の簡単な原理と特徴の説明と例題を解く感じだったので、まだ少しフワフワしています。

目的の benchmarkhor | Dart Package (pub.dev) というパッケージがどのように統計的解析をしているのかはキチンと説明ができるようになったのでヨシとしますが、自分で検定の設計ができる程度にはどこかで学びたいな…。

bangumi.ouj.ac.jp

 

ブロックチェーン

巷でWeb3というものが話題になっていたので、理論をちゃんと学んでおきたいよね、ということで例の論文 bitcoin.pdf を読む勉強会を3人ぐらいでやりました。ギャンブラー破産問題面白かったです。

おかげで某Web3の本のアレな部分にも気づけました。

とはいえ、大学の卒論がこの辺りだったのであんまり新しい学びはないかも。

 

制御工学

カルマンフィルタの基礎

www.amazon.co.jp

友人と数年間続けている勉強会の題材を考えていて、次に学ぶことに迷いすぎて気が付いたらカルマンフィルタの学習を始めていました。

今まで学んだどの科目とも違う分野で、つまづくことがかなり多いです。脳負荷が高くて良い。

そもそも古典制御をおろそかにしていたので、古典制御を学びつつカルマンフィルタの本を進めています。ラプラス変換、神、ナニコレ。

 

その他

様相論理の本を買って読むなどしましたが、途中で放置してます…。知識論理や信条論理などの面白い派生や、モデル検査など応用の幅が広いしエンジニアにもかなり近い分野なのでそのうち読破したいです。

www.morikita.co.jp

 

哲学・思想

ここ3年?ぐらい、哲学や思想を放送大学の授業や入門書によって学習してきました。最近は入門本ではなくて翻訳書を読み始めています。

以前は独学で翻訳書を読んで撃沈することが多かったのですが、有料の勉強会を見つけたので解説を交えつつ読むことができるようになってきました。

ルネ・デカルト方法序説

方法序説

http://www.the-five-books.com/lecture/34

The Five Booksという、一か月ほどかけて哲学書を読む勉強会に参加し、デカルトの「方法序説」を読みました。

試論を含まない序説だけならかなり薄い本で、内容もそこまで難しくないため、本自体はサクッと読むことができ、デカルトの生き方に学ぶことが多かったです。

例えば、明晰判明という概念はソフトウェア工学とかなり相性が良いのではと感じますし、彼の定める格率は自分より年下の年齢で考えたと思うと素晴らしいなと感じます。

勉強会の方では、時代背景や他の勉強会参加者の意見を聞く場面があるなど、独学で読む数倍の学びでした。

The Five Booksはかなり推しなので来年はライプニッツの「モナドジー」を読む会に参加したいと思います。(むずそう)

 

カンタン・メイヤスー「有限性の後で」

そもそも思想を学び始めたきっかけがグレアム・ハーマンのオブジェクト指向存在論(もっというとOOUI)なのですが、避けては通れないカンタン・メイヤスーの「有限性の後で」を年末年始で読んでいます。

読み始めてから後悔したのですが、先にカントの純粋理性批判を読んでおきたかった…。

有限性の後で

www.jimbunshoin.co.jp

 

趣味

今年はいくつか趣味も開拓しました。

VRChat

www.moguravr.com

お砂糖文化やVR睡眠文化に憧れて、Meta Quest2とゲーミングPCをポチって、VRゲームのVRChatを始めました。気が付いたらTrustedになっててびっくりしてます。

基本的にはワールド巡り(観光)や、DJイベント、フレンドとお喋りがメインの楽しみ方をしてます。お酒を飲みながらVRChatするのが楽しすぎて肝臓がダメになったので、最近はノンアルコールです。

VRの世界には正解がありません。常識的なものはないので、どんな楽しみ方をしても(人に迷惑をかけなければ)OKです。

対面の会話が苦手だな~下手だな~と自分で思うことが多いのですが、VRChatはアバターという仮面をつけた状態でコミュニケーションの成功体験を積むことができるので良いです。似たような報告は色々と見かけるので、こういう仮面舞踏会状態のコミュニケーションって良いものなんだろうなと感じます。

関連して、BlenderやUnityとちょっと仲良くなりました。昔メタセコイア触ったりUnityでゲームを作ったことがあったのですが、あのあたり経験が無駄にならずに済んだ。

 

お絵かき

こちらの記事に触発され、お絵かきの練習を始めました。

note.com

お絵かきは、少なくとも死ぬまでに自分で満足いく程度で良いのでファンアートなど描けるようになりたい、と思っていた夢の一つでした。

そもそも自分は恐らく自分一人でゲームを作りたいんだろうな、と思うことがあり、取り組んでいます。(プログラミングのきっかけもゲームだった)

 

基礎的な練習をしつつ、たまに下手な絵を描いてお絵かきコミュニティに投稿すると少ないですが「いいね」を貰えて嬉しいです。前述したVRChatで使っているアバターのファンアートを描いたらアバターの作者さんがRTしてくれて感動してむせび泣きました。こういう体験ができただけでも始めた甲斐があったのかなぁ…と思います。

それにしても巷の絵師、みんな改めてすごすぎる、上手すぎる。

 

DJ

ひょんなことからDJコン(DDJ-400)を手に入れてたまに小さな仲間内でDJするようになりました。DJライブはずっと好きだったのですが、自分で一度やってみるとパフォーマンスの解像度が上がってさらにライブを楽しめるようになりました。良い。

転職もそうですが、同じ事柄を少しずらした別の視点から観測すると、3Dメガネのように一気に解像度が上がりますね。

 

ゲーム

朝早起きして少しずつゲームをプレイしました。

www.gamecity.ne.jp

www.compileheart.com

www.marv.jp

 

抱負「均し」はどうだったか

去年、抱負として「均し」を上げ、ハードワーク燃え尽きサイクルからの脱却を目指し、コンスタントにパフォーマンスを出していきたいという目標でした。

達成率: 50%、といった印象です。

技術的・人生的な学びもありつつ、6-8月ぐらいに体力・精神的なバーンアウトをしました。

バーンアウトしない計画的なアウトプットというものが大事だと気づかされました。

 

でも、例年2-3回ぐらい燃え尽きてたので多少改善してそうです。気持ちの切り替えができるようになってきて偉い。

 

来年の抱負

去年の抱負の「均し」をより具体的にして「力をうまく抜く」です。

世の中の色々は思ってるより頑張らなくても勝手にどうにかなってしまうものも多いなと思い始めています。(仕事もプライベートも)

ビリヤードの玉のようにせわしなく行ったり来たり、どうしても生き急いでしまうところがあるので、来年はうまく肩の力を抜いてドッシリ構えていけたらなと思っています。

ズボラ自炊ブートキャンプ

やあお前ら!元気に過ごしているか?

この記事は 一人暮らし Advent Calendar 2022 - Adventar の17日目の記事だ。他の記事もみんな面白いからぜひ見てくれ!

 

今日はズボラに自炊を続けるノウハウを、ブートキャンプ形式でお前らに伝授したいと思う!楽しい旅になるはずだ、心してついてきてくれ。

 

俺たちズボラー

お前ら心して聞くように!

 

怠惰は美徳だ!ズボラであることに誇りを持て!

もう一回言おう、

怠惰は美徳だ!ズボラであることに誇りを持て!

 

真面目に家事なんてやってたら飯が冷めちまうからな。

必要十分な条件を見つけて、とにかく手を抜くことが世の中大事なんだ。

 

自炊を続けたい

いいか、ものごとを継続して行うには、全力で自分を甘やかすことが大事だ。

自炊を継続させたいという気持ちから「毎日作ろう」「作り置き頑張ろう」「お弁当毎日もってこう」とか考え始めてはダメだ。

特に俺たちズボラーは、毎日頑張ることなんてできない!なぜなら怠惰!美徳だからだ!

できなかったときに失敗体験を覚えてしまうような呪いを自分にかけるんじゃない!

諦める理由になるし、意識していなくても軽いトラウマの素になってしまうことだってある!

苦手意識を持ってしまうことだけは全力で避けろ!

 

逆に、自炊のハードルを下げて下げまくれ!

野菜炒め作ったら自炊?偉いぞ!お惣菜をレンチンしたら自炊?いいじゃん!カップラーメンにお湯入れたら自炊?いいよいいよ!

自分を追い込むのではなくて、とにかくハードルを下げて下げて、自炊が好き!と言える状態がゴールだ!

 

いいか!今日の話のメインはここだ!「自炊のハードルを下げ、好きになるためには」

まだまだウォーミングアップだ、しっかりついてこい!

 

必要なもの

自炊を楽しくする、心持ちを楽にするために必要なものを紹介していく!心に響いたらぜひポチってくれ。

 

マルチビタミン&ミネラル

栄養について考え出すと料理は途端に難しくなる!特にビタミン、ミネラルは生野菜を取らなければいけなかったりとズボラーにはあまりに難易度が高い!

そこで、マルチビタミン&ミネラルを飲んで、おおよそ一日に必要な栄養素を担保しよう!

こいつがあれば、俺らズボラーは好きなご飯を食べることができるわけだ!これでだいぶ心持ちも楽になる!

 

(もちろんこれ以外にも必要な栄養素はある。完全食を自作してみた1 - MJHD (hatenablog.com) を見ると他にどんな食品が必要か分かるかもしれない。でも三食食べていれば基本大丈夫だと思う)

 

ポリエチレン手袋

ポリエチレン手袋

ポリエチレン手袋L 120枚入 | 【公式】DAISO(ダイソー)ネットストア (daisonet.com)

 

ズボラーは自らの手を汚すべからず!

食材を切るとき、洗い物をするとき、生ごみを捨てるとき、あらゆる場面で湯水のごとくこの手袋を使え!

手が汚れないだけでも料理に対する嫌な気持ちがかなり減る!

 

いいか、使い道は下の三つだ:

- 手が汚れそうな下ごしらえの時

- 排水溝のごみや生ごみを捨てる時(ゴミをつかんで、そのまま裏返して口を結んでポイ)

- キッチンの掃除をする時

 

特に我々ズボラーは「排水溝のごみや生ごみを捨てる、キッチンの掃除をする」にめちゃくちゃ抵抗を感じると思う!

わかる、わかるぞ!

とりあえずポリエチレン手袋を300枚ぐらい買え!これがあるだけで料理に対するハードルがかなり下がるはずだ!

 

アイラップ

これも3つぐらい買え!

一人暮らしだと玉ねぎも人参も肉もあらゆる食材を半分程度しか使わない!余った食材をこれに包むもよし!

俺は毎月一回、5kgほどの肉を買い込み、一食分の大きさに切ってからアイラップに包んで冷凍している!肉がいつでもあるというだけで料理のハードルが下がるぞ!

我々ズボラーはカレーが大好きだ!カレーは意外と腐りやすいので、冷めたら一食分に小分けでアイラップに入れ、冷凍しよう!

簡易手袋としても、簡易ゴミ袋としても使えるこれは必需品だ!

 

バット

バット

ステンレストレー深型 約21.5×16cm | 【公式】DAISO(ダイソー)ネットストア (daisonet.com)

これも3つぐらい買え!いやもっと買っても良い!

俺たちズボラーは煮込みながら食材の下ごしらえを同時並行ですることはできない!

あらかじめ全ての食材の下ごしらえをして、バットにためておいてからから鍋に放り込むんだ!

とりあえずあるに超したことはない!

 

その他

包丁やまな板は一旦100均のGalaxyなんとかと書いてあるような安いやつで良い!

とりあえずなんか買ってくれ!

後述するが、自炊熱が冷めてきたころにこの辺りの道具を新調するとモチベと継続に繋がるので、それまで良い調理器具は我慢しておき、安い調理器具でハードル低く始めるというのも戦略の一つだ!

あと料理のさしすせそと言われるものと、各種うまみ調味料(味の素、だしの素、ガラスープの素、コンソメ)は一通りある前提で進める!なかったら一旦買っておいてくれ。

 

料理を作れ!

自炊する準備はできたか?

ちゃんとマルチビタミン&ミネラルも飲んだか?アレは空腹で飲むと死ぬほど気持ち悪くなるから何か胃に入れてから飲めよ?

 

よし、じゃあ料理を始めるぞ!

野菜と肉を刻め!全部バットに入れていけ!フライパンに放り込め!火を通せ!

 

ここで俺と約束して欲しい。火を通してる間に包丁とまな板とバットは全部洗ってくれ!

食べ終わった後にシンクが料理の洗い物で埋まってる様子を見るだけで、失敗体験になってしまう。いいか、火を通してる間は洗い物の時間だ。動きを止めるな!

やる気が起きなかったらHip Hop流して踊りながら洗ってほしい!時間が余ったら踊りながらキッチンの掃除をしてくれ!次の料理をするハードルがかなり下がるはずだ!

 

火が通ったら、うまみ調味料を入れろ!うまみ調味料は絶対入れろ!終わり!

 

いいか、これはイーブイだ。ここに好きな調味料を加えて飽きないようにしてくれ

- 醤油と酒やみりん(和風)

- カレールー

- オイスターソース(中華)

- ナンプラー・トムヤムペースト(エスニック)

- 酒・豆板醤・甜麵醬(麻婆)

- トマトピューレ

- チリソース

- ...なんかKALDIで売ってるやつ適当に入れろ

 

水を入れてスープにしても良いな!塩と砂糖とうまみがまともなら大抵のものは美味しくなるはずだ!

塩を入れる量は、1日の推奨摂取量(男: 7.5g, 女: 6.5g)を3食分で割った量を入れると、健康的で味付けに失敗もしなくて良いぞ。(しょっぱい調味料、醤油などを入れた場合はそこも考慮しよう)

 

どうだ?美味しかったか?美味しかったらそれはもう成功体験だ!君は「自炊が好き」と言っていいんだぞ!

 

これだけでもう自炊は十分続けられるはずだ!

よしよし、よくここまでついてきた、お前ならやれると信じていたぞ!

 

飽きてきた

おいおい、もう飽きてきたのか?よし、じゃあ飽きてきた時のモチベ維持について話そう!

 

調理器具を新調しよう

以下は俺が実際に使っていて良いと感じた調理器具たちだ。調理器具をアップグレードするとやる気がでる。そういえばゲームも途中で使える技が増えたり、武器がアップグレードすることで楽しくなるよな、あの理論だ!

 

ペティナイフ

ペティナイフは果物を切る際に使うナイフのようだが、GLOBALのペティナイフは若干刃渡りが長く、普段使いの包丁として使いやすい!

小回りが利くし、切っ先が鋭いので「引き切り」と言われる切り方が得意、慣れると素早く下ごしらえができるようになる。あと鶏肉の皮なども切っ先で引き切りすると切りやすかったりする。

(気を付けないと左手の指を切るので注意)

 

まな板

最近お気に入りのまな板だ!木製で軽いが、加工されており傷や汚れが付かず耐久性がある。とても丁度よいまな板。

 

電気圧力鍋

万能調理器具、電気圧力鍋。食材を放り込んだらなんかいい感じに食べれるようにしてくれるぞ!ズボラーにぴったりだな。

個人的に、付属のレシピ集にこそ価値があると思っている。料理のレパートリーが増えて自炊が一気に楽しくなるぞ。

一人暮らし用はほどほど小さいサイズなので、食卓において鍋などもできる。

 

オーブンレンジ

これも事実上の万能調理器具。ノンフライ調理ができるのでから揚げやトンカツをヘルシーに作れて良いぞ!

オーブン機能もあるのでパンやピザ、グラタン、お菓子作りもできる。

こちらもレシピ集が付属するのでここに価値がある。料理のレパートリーがさらに増える。

 

本屋でレシピ本を立ち読みしろ!

レシピ本を買うのも手だが、一旦本屋で立ち読みするだけでもヒントがある!

完全にまねする必要はないから雑にパラパラと読み、とりあえずモチベが上がったら大成功だ!

レシピサイトとかでも良いな。

 

冷凍の食材を買いまくれ

業務用スーパーが近場にあれば、冷凍の野菜を大量に買うと良いぞ!

買い出しは自炊の中でも結構面倒な工程、端折れるのであれば端折っていこう。

セブンの冷凍小口ネギは万能でいいぞ。

 

休め!

自炊に飽きたら休むのも手だ!実は外食も出かけなきゃいけなかったり、UberEatsも地味に高かったりと万能ではない。

そのうちまた自炊したいと思えるはずだ!幸いなことに君の冷凍庫には食材と、調理器具と、レシピが頭に入っている。

また自炊をしたいと思えるまで休憩するのも、飽きないための秘訣だ!

 

以上!

今日のズボラ自炊ブートキャンプは以上だ!ぜひ楽しく自炊を初めて欲しい!

株式会社サイバーエージェントを退職しました

mjhdです。
内定者バイト・新卒で入社し、4年勤め5年目に入る株式会社サイバーエージェントを退職しました。
お世話になった方々、ありがとうございました。

どんな会社だったか?

CA用語とも言われますが、独自の用語があることが度々話題になることからも分かる通り、独自の文化・共通言語が浸透しており、ベンチャー気質ながらも大企業としての体制を兼ね備えた良い会社でした。
メガベンチャーの部類に入るため、社内にいても知らない部署だらけで、ニュースやプレスリリースで初めて知るサービスがほとんどで、ワクワクのあふれる会社です。
手を上げれば任せてもらえるというのが4~5年勤めた一番の感想で、上層部の人であっても発言に対してフラットに応答してもらえる、抜擢(若手に任せる)文化があるといった点が印象に残ります。
実際、私も新規事業部として新規事業の立ち上げに参加させてもらったり、メインではない職種(WebフロントやFlutterを用いたアプリ開発など)に柔軟に再配置してもらうのなどの様々な経験をさせていただきました。
私に期待をしてくださった方々や、わがままを聞いてくださった方々に多大なる感謝を…!

退職のきっかけ

エンジニアとして迷走しはじめており目標設定に課題を感じていたこと(具体的な内容は社内timesに書き残しました)や、現在の部署で古参になってしまい居心地が良すぎたという点が大きな理由です。
気持ちをリセットし、新鮮な姿勢でエンジニアリングに向き合いたいと思い始めました。

そしてこれから

幼少期からずっと、作ったものを人に見せてモチベーションを上げてまた作る。人の作ったものを見てモチベーションを上げてまた作る。というのが自分のプログラミングやその他の活動の原体験だったと思ってます。
小学生の頃ゲームを作りたいと思い立ち、プログラミングをはじめドット絵や、MIDIメタセコイア、プロットやシナリオに入門し、小さなコミュニティの中で教えてもらいながら見せ合いながらパソコンを覚えていった記憶があります。
高校の入学祝で兄から自宅サーバ用のPCを買ってもらってから大学時代と、徐々にWebサービスの開発にシフトしていきましたが、次のお仕事では、この辺りの原体験を大切にしつつ、気持ちをリセットしてエンジニア活動をしていけたら良いな思っています。

Github Actionsのcacheをデータの永続化(?)に使う

Github Actionsでワークフローを作るとき、「どこかにデータを保存して次の実行時に参照したいな」「別のワークフローとデータを共有したいな」と思ったことはないでしょうか。

実は、普段キャッシュ用途に使っている actions/cache を使うと、制限付きでこの辺りが実現できます。

actions/cache

actions/cache は任意の文字列(key)を使って、指定ディレクトリや指定ファイルを保存し、任意の文字列(restore-keys)を使って復元できる仕組みです。

主に依存インストールのキャッシュやビルドのキャッシュに使われていますが、この仕組みをもっと汎用的に考えればデータの永続化(?)にも使えます。

制限

actions/cache には以下の制限があります:

  • レポジトリ全体で10GBまで(2022/6/4現在)
  • 保持期間は7日間

この条件を満たさないものは、古いものから順に削除されていきます。

なのでこの記事が適用できるのは、例えば決まった曜日にscheduleで実行されるWorkflowで7日以上間隔が空かないものや、一定期間過ぎたらリセットされても問題ないものになります。

(私は、月曜と木曜にメンバーを輪番で指名するWorkflowのために使用しています)

Starカウンター

簡単な例としてレポジトリにスターが付くたびにインクリメントするWorkflowを考えてみましょう。

on句にwatchを指定することでスターが付くたびにWorkflowが実行されます。あとは、cacheを使って現在のスター数をインクリメントしていけば、なんとなくカウントできそうです。

Github API叩けばスター数取れるじゃんというのは一旦置いておきましょう)

name: Star Counter

on:
  watch:
    types: [started]

env:
  STATE_FILE: './state'

jobs:
  increment:
    runs-on: ubuntu-20.04
    steps:
      - name: IDの生成
        id: build-id
        run: echo "::set-output name=id::$(date +%s)"

      - uses: actions/cache@v3
        id: state
        with:
          path: ${{ env.STATE_FILE }}
          key: counter-${{ steps.build-id.outputs.id }} # 毎回、最新のキャッシュを保存するためにIDを指定する
          restore-keys: counter- # 復元時は最新のキャッシュを指定する

      - name: 初回ならカウンターを初期化
        run: |
          if [ ! -f ${{ env.STATE_FILE }} ]; then
            echo '0' > ${{ env.STATE_FILE }}
          fi

      - name: カウンターをインクリメントする
        run: |
          VALUE=$(cat ${{ env.STATE_FILE }})
          echo "CURRENT: $VALUE"
          echo "$((VALUE + 1))" >| ${{ env.STATE_FILE }}

これを実行すると、以下のように実行されるたびに前回の状態を復元し、インクリメントするWorkflowが実現できます。

カウンターがインクリメントされている様子

その他の可能性

まだ試していませんが、Workflowが同時に走らないという前提があれば、このキャッシュを通じて他のWorkflowとも値を共有できます。

このキャッシュは「ブランチ」と「key」のスコープで共有されるため、同じ「key」を指定すれば同じデータが見れるはずです。

Workflowが同時に走りうる場合は不整合が起きるので、トリガーがscheduleで1日おきに動かすWorkflowなどだったら安全に扱えるのではと思っています。

https://github.com/actions/cache#cache-scopes

まとめ

制限はあるが、actions/cache を使ってデータの永続化(?)ができる。 簡単なWorkflowなら、Workflow間の状態を持たせることができる。

読みやすいコードって何だろう

読みやすいコードってなんでしょうね。  新卒の頃、たくさんリテイクを受けて書き直しした経験からよくよく考えはじめましたが、永遠に結論はでなそうです。

ひとまず、ここ数年考えている頭の中身を書き出したいと思います。

「コード」ってなんだ?

「読みやすさ」とは何か、の話に移る前に、そもそも「コード」とは何か考えてみます。

ここでいうコードは、もちろんあるプログラミング言語の文法に従って入力されたコードを差すわけですが、その本質は何でしょうか?

プログラミング言語の発祥を考えると、まずマシン語がありアセンブリ言語があり、より人間が読みやすく高度な構造化ができるよう高水準言語たちが生まれてきました。(と思います)

この言語の読者は、機械と人間であり、両方にとって読みやすい共通語として役割があります。この事実は、人間が読みやすいという自然言語との共通点でもありますし、人間以外の機械も読みやすいという差異でもあります。

今回の記事は、読者が人間である場合の「読みやすいコードとは何か」について深掘りたいと考えているので、ここでいうコードは人間の読み書きする文章としてのコードに重きを置きます。なので、安全性やパフォーマンス、その他の機械にとっての意味論は一旦前提として、人間にとっての意味論を考えます。

人間にとっての意味論を考えるとき、おそらく「読みやすい"文章"とは何か?」と考えても、結論は似たようなものになるのではないでしょうか。

読みやすい文章の話

よくネットで見かけるミームに「完全に理解した」→「何も分からない」があります。
私自身よく体感するのですが、例えば入門書を読んだ直後は「完全に理解した」状態になります。
一種の無敵感と言いますか、頭の中に矛盾が一切なく、読んだ内容を誰かに伝えたい、応用にチャレンジしたいとすら思っています。

ここで実際に他人に読んだ内容を伝えたり、もしくは自分で応用にチャレンジしたとき、今度は「何も分からない」状態になります。

不思議ですね…読み終わった直後は矛盾が一切なかったのに、他人から質問を受けたり、応用する中で新しい事実に出会ったときに「実は何も理解してなかったんじゃないか…?」と不安になります。
そしてこの不安をTwitterフィルタを通して書き込むと「何も分からない」になるのです。

私は、この「完全に理解した」→「何も分からない」の繰り返しのことを、事実の再グループ化だと思っています。

事実

ここでいうところの事実とは、実際に目で見て出会った出来事です。近所に新しくできたごはん屋さんに入ったら美味しかった。遠くの国で人が死ぬニュースを見た。実験の結果A群が優秀だった。なんでも良いのですが、とにかく当人にとって新しい出来事であり、集まると思い出や知識、陰謀論、宗教、いろいろな概念を形作ります。

グループ化

例えば、全く同じ事実をそれぞれ別の人に与えたとして、同じ概念には至らないと思います。地震が発生したとして、「良くあることだ」と思う人もいれば「某大学が実験をしている」と思う人もいるでしょう。(いるんですか?)

また、様々な心理的なバイアスによってもこの結び付く力関係は変わってきます。

事実同士をどう結び付けるか、逆に言うとどう線を引くのか、このグループ化によって概念はできていそうです。

再グループ化

「完全に理解した」→「何も分からない」の繰り返しを、事実の再グループ化と言いました。

「完全に理解した」は、入門書を読み終わった後など、自分の頭の中に矛盾がない一種の無敵状態でした。

「何も分からない」は、他人から質問を受けたり、応用する中で新しい事実に出会ったときに「実は何も理解してなかったんじゃないか…?」と不安になることでした。

ここで起きていることは、質問や応用で出会った「新しい事実」を、どうグループ化するかという悩みであり、これは事実の再グループ化と言えそうです。

入門書というのはよくできているので、分かりやすい事実(例や問題など)とそのグループ化の基準を最低限教えてくれます。当然、本としてまとまっているのでその中に矛盾はなく、しっかりと読んでいれば矛盾のない事実とグループ化による概念が読者の頭の中に構築されます。

しかし、その後「新しい事実」に出会ったときどうグループ化するのかは読者にゆだねられています。人は「完全に理解した」→「何も分からない」を繰り返しながら、頭の中の事実マップを拡張していき、事実のグループを適切にメンテナンスしていくことで、学習をしているからです。

文章

事実のグループ化を踏まえて読みやすい文章について考えたいと思います。

読みづらい文章というと、どんな文章を思い浮かべるでしょうか。「知らない単語がある」「何を言っているのか分からない」「矛盾している」「説明が端折られている」などが最近読んだ本だと思い当たります。読者の中で「分からない」が発生していると考えられそうです。

ということで、少なくとも「何も分からない」状態が起こりうる文章は分かりづらいはずです。まあ当たり前ですね、何も分からないのですから。

読みやすいコードの話

では、読みやすいコードとは何でしょうか。

文章における読みやすさはコードにも通じるはず、という前提なので、文章における事実のグループ化の構造にコードを当てはめて考えてみたいと思います。

事実

コードにおける事実は、例えば変数や関数などのシンボルが最も分かりやすいです。

letやvarなどの変数宣言や、fnやdeffunc、functionなどの関数宣言はまさに「新しい事実だよ」と伝えています。これらのシンボルを組み合わせて、ロジックを構築していきます。

もちろん、人間の読むコードはもっと曖昧ですので、プログラミング言語の文法と事実が完全に一致していないケースもあります。素晴らしいワンライナーなどはまとめて一つの事実となりそうです。今回は例として、シンボルに限った話をしたいと思います。

グループ化

コードにおけるグループ化は、例えばパッケージやファイル、関数やクラス、空行で区切ったコードの塊などが当てはまると思います。

他の関数や変数などのシンボルをまとめて、一つの意味を持たせたグループです。空行で区切ったコードも、暗示的に意味を持っていたり、または明示的にコメントで役割が説明されています。

コンテキスト

ここでもう一つ、コンテキストという概念も登場させたいと思います。

ここでいうコンテキストは、事実をグループ化した概念の中でも、コードを読む上で読者(レビュワーなどコードリーディングをしている人、またはコンパイラや機械)が前提として持っていなくてはいけない概念たちのことです。

例えば、AファイルのB関数を読んでいる場合、Aファイルでimport/include/useされているパッケージの情報は前提として読者が持っていなければ、B関数の中で使われているシンボルを読んだときにグループ化されていない新しい事実が生まれてしまいます。

これは、人間にとっては「何も分からない」ですし、機械にとっては「undefined symbol」です。

よって、「何も分からない」を防ぐためには、コンテキストも大切になってきます。

ただし一点だけ注意が必要で、「人間は、機械よりもコンテキストが曖昧」です。機械はメモリのある限りコンテキストを厳密に記憶し参照できますが、人間の認知はより忘れやすく曖昧でノイズも多いです。例えば、「人が覚えられる事柄はせいぜい3~5個」のような心理学のお話を見かけますが、これはコンテキストにも当てはまるため、「機械的には解決できるシンボルも、人間には解決できない」ことが多々あります。

強いコンテキスト、弱いコンテキスト

どのコンテキストが失われやすいのか?を把握するために、強いコンテキスト、弱いコンテキストという言葉を錬成したいと思います。

強いコンテキスト: 直前で定義された概念(画面内に収まる)、現在行よりも上で定義された概念(人は上から下に読む)、現在ファイル内で定義された概念、現在ファイル内で明示的に参照された概念(名前付きimport, 明示的なself, 引数など)…

弱いコンテキスト: ファイル外で定義された概念、暗黙的に参照される概念(グローバル変数など), 演算子オーバーロード

これは一例ですので、状況によってグラデーションは変わってきますが、弱いコンテキストに含まれる概念はIDEなどの支援なしでは読めない可能性が高そうです。また、プロジェクト内で普遍的な関数群などは強いコンテキストに含まれるかもしれませんし、新参者にとっては弱いコンテキストかもしれません。

よって、読みやすいコードの要素として、弱いコンテキストへの参照が少ない、という項目も挙げられそうです。

読みやすい、とは

本題ですが、「読みやすい」とはなんでしょうか。ここまで出た話をまとめれば「何も分からない」を防ぐため、適切な「事実」と「グループ化」を与えることだと言えそうです。

さらに、人間の認知の制約上、コンテキストは失われやすいという性質も考慮に入れる必要があるため、「弱いコンテキストへの参照が少ない」ことも挙げられました。

まとめると、「適切にグループ化され」「弱いコンテキストへの参照が少ない」コードが読みやすいと言えそうです。

「適切なグループ化」は色々な文脈で色々な言葉で語られていますが、「弱いコンテキスト」の話はあまり見かけない気がしています。(無知なだけかもしれません、既にあれば教えていただきたいです)

Go言語の例

以前、視覚に障害のある開発者からみたGo言語の良さに関する記事で「読みやすい/読みづらい」についての言及がありました。

zenn.dev

Go言語のレシーバー(他言語でいうthisやself)が明示的に記述されているためメソッドであることが確定する点や、public/privateが命名に現れるため参照しやすい、型が明示的であるためオブジェクトの動作を把握しやすい…などが挙げられています。

視覚情報が限られた状況では、強いコンテキストと弱いコンテキストのグラデーションはより濃くなるため、強いコンテキストの多いGo言語は読みやすいと言えるのでは、と思っています。

この話は晴眼者であるかに関わらず起こる問題で、コードレビューのような限られたdiff、限られた時間で読まなくてはいけないコードではグラデーションが濃くなると思います。

三行まとめ

コードは文章の一種。

適切なグループ化はやはり大事。

弱いコンテキストは読みづらい、特にレビュー時など。

 

余談

この「事実」「グループ化」「コンテキスト」の話は、文章、コード以外にもUIデザインだとか物語、音楽など、シーケンスがあり人間が認識する色々なものに適用できるんじゃないかとなんとなく思っています…。

2021年 振り返りと抱負

去年の振り返り
mjhd.hatenablog.com

早いものでもう2021年も終わり、体感的にはまだ6月ぐらいなんですが、カレンダーはバグらないので僕がバグってるのでしょう。
振り返りたいと思います。

どんな年だったか

エモさ溢れる年でした。今年も仕事でチームを移動しました。
同じプロジェクト内でチーム移動をするのが今回で二回目なのですが、やはり立ち位置を大きく変えるのではなく少しだけズラすことで差分が分かりやすく、組織的にも技術的にも人生的にも気づきが多いです。
2Dの映像も、ちょっとだけ視点をずらした映像を用意すれば立体的に見えると思います。あのイメージです。

仕事方針的な変化

チームを率いるというよりは、個人としての技術力を磨く方針に転換しました。
理由としては今の自分の技術力に自信がなく、確固たる芯を築きたい(そこまでは行かなくてももうちょい自信つけたい)というのが根本的な理由です。
あくまで技術に軸足を置きたい、でもまだ片足も地面についてない、という焦燥感がありました。

方針転換後、当然悩むのが、今までと同じだけの価値をどうやって個人で達成するのかという点。団体戦vs個人戦なわけです。
ここについては引き続き悩んでいきつつ、なんとなく対策は見えてきた気がするので来年実践していけたらと思います。(ユニークスキルを伸ばしつつ、影響範囲を広げてけば良いと思うのです)

内面的な変化

20歳も7年が過ぎ、いよいよ自分をだんだんと客観的に見れる余裕が出てきました。
これは人生を送るサブルーチンが刈り込まれ圧縮され、脳内メモリに余裕ができたので、自分をマネジメントするためのインスタンスを新たに立ち上げることができるようになったのが要因だと思ってます。
これがもっと脳内メモリに空きが出たら他人を気にかけるほどの余裕が生まれるのではないかな。(自分はこの段階に到達するのが遅い部類の人だと思います) 逆に一時的にでも脳内メモリが減り余裕がなくなるとマネジメントインスタンスがOOMKillされ、あっぷあっぷし始めます。リソースが足りてない中人生を送るために大切な非常措置だと思いますが、この状態を抜け出すのは大変です。
そして、そもそもこれは非常措置なので、発火させない予防が大事です。

均し

来年のキーワードは「均し」です。

地均し
1 地面の高低やでこぼこをなくし、平らにすること。また、そのために使う道具類。
2 あることをうまく進めるために、あらかじめ準備をしておくこと。「意見調整の地均しをする」
地均しとは - コトバンク

自分の今までの生き方は、端的に言ってこんな感じでした。
ノコギリ波

モチベやパフォーマンスが一時的に上昇します。ですが、上昇しきった後、意図的な代休や有休・虚空を見つめるだけの時間を作ることでクールダウンし、マイナスからまた徐々に上昇し始めます。意図的じゃなく燃え尽きることも度々ありました。
この生き方の問題点は、
1. 平均すると0付近にいるにも関わらず、自己評価や他人からの評価はプラス面を見がち。なので過大評価につながる
2. マイナス領域にいるときの上昇要因が、過大評価への焦りになりがち。なので振幅が徐々に増えていき負のサイクルに

誰も現状を正しく把握できなくなり、さらに負のサイクルも引き起こしてしまいます。
また、この生き方で成功体験を積んでしまうのも今後の自分や他人にとって悪影響があると思いました。

今年は、この波を均すことを目標にしたいと思っています。均すといっても傾き0というわけではなく、ゆっくり着実に右肩上がりを目指します。
コンスタントに学び、成果を出し、現状を正しく把握し、正しく振り返れる年。 それが理想です。

強みと弱み

マネジメントインスタンスを立ち上げたことで、徐々に自分の強みと弱みも具体的にわかってきました。

強み:
- 遅効的な思考が得意(じっくり考える, 執着する..)
- 深掘り好き(自分で考え理解する, 疑問点を残さない, ....)
- のめり込める
- 飲み込みが早い

弱み:
- 瞬発力のある思考が苦手(口頭で迫られる決断, 会話の切り返し, 臨機応変, 無茶ぶり...)
- ノイズのある環境に弱い(騒音, 集中力の乱れる情報, ...)
- 生き急ぎがち(パフォーマンスに波がある)

思考の早さやノイズについては立ち回り方でどうとでもなりそうです。

今まで自分は「熱しやすくて冷めやすい」や「一念発起が得意」な人間だと自覚していたのですが、改めて振り返ってみると、集中すると成果が出せるけど、セルフマネジメントが下手なので純粋に燃え尽きているだけだと感じます。
ここにも、来年のキーワードである「均し」が活きてくると良いです。

学んだこと

今年は三つの軸で学びました:
1. 低レイヤー(GB, NES, GBAエミュレータづくり)
2. CS・数学(暗号理論, 符号理論)
3. 哲学・思想(放送大学の授業)

低レイヤー

去年の抱負にこう書きました。

今年は、新しい技術や言語の習得ができていない年だった。(マズイ)

Rust を少し齧ったが、まだまだ「Rust らしいコード」を書けていない。

抱負としては「低レイヤーに関する知識を深める」。CPU/GPU、ドライバ、カーネル、OS、コンテナ…などなど。

この対策として、今年はゲームボーイファミコンゲームボーイアドバンスなどのレトロゲームエミュレータを複数書きました。

mjhd.hatenablog.com

mjhd.hatenablog.com

github.com

結果として、Rust力もはじめと比べたら多少は上がった…かな?(正直言語に関してはPRDで書かなければ上達しなさそう)
低レイヤーに関する知識は、正直そんなに上がっていません。命令パイプラインの実物を初めてちゃんと知れた…ぐらいでしょうか。
来年もGBAの開発を続けつつ、少し裾野を広げて「30日で作るOS本」でもやろうかな。

CS・数学

今年いっぱい、数学の得意な友人と一緒にCS・数学の輪読会を月2~3回ぐらいのペースで行いました。

XORSHIFT: Google Chromeが採用した、擬似乱数生成アルゴリズム「xorshift」の数理 – びりあるの研究ノート

楕円曲線暗号: 楕円曲線暗号アルゴリズムを理解する|TechRacho by BPS株式会社

暗号理論: 暗号理論と代数, 松本 眞, 広島大学: http://www.math.sci.hiroshima-u.ac.jp/m-mat/TEACH/network-algebra.pdf

暗号理論は、シーザー暗号に始まり、数学的難問を使った鍵交換、暗号化など現代でも使われている暗号化まで一通り網羅できる分野です。
CS・数学の分野的には、離散数学で扱うような剰余類の話であったりとか、そこから発展して群論の話など、幅広く扱います。

符号理論: 例題で学ぶ符号理論入門 | 先名 健一 |本 | 通販 | Amazon

符号理論は、ガロア理論に基づいた多項式表現により二進数を表現することで、多項式を用いた様々な性質を情報科学の分野に持ち込みます。
必要な数学的分野としては、離散数学線形代数です。
これにより、現代のQRコードや通信で使われるような誤り訂正のロジックを説明できます。

以上を学びました。個人的に、輪読会は続かないものだと思っていたので、今回一年を通して数学を学べたことはかなり良い成功体験になりました。

哲学・思想

哲学、思想については放送大学で、概論的な授業と、言語哲学の授業をとりました…が、正直言語哲学の方は時間がなく、単位を取ることができませんでした。
教科書自体はあるので、来年隙を見つけて取り組みたいと思います。

まとめ

来年は「均し」をキーワードにエンジニア人生を歩んでいく。
個人的な学習としては引き続き、低レイヤーとCS・数学をメインに行っていく。

今年もありがとうございました、来年もどうぞよろしくお願いいたします。