2024年の振り返りと抱負
去年:
「均し」とは何だったのか、走り切った一年、去年はお仕事も落ち着いてプライベートが充実し始めたころだったようですが今となってはプライベートが忙しすぎて心と体の限界まで走り回る日々で立ち止まって考える余裕なんてものは一切なくなってしまったようです。これが本当の師走か。せめて年末年始はゆっくりしようと思いつつ、既に締め切りに追われる日々が始まっていたのでした。自分で広げた風呂敷を自分で畳んでいるだけなのです。畳んでる最中の風呂敷に入るな猫。キュム...。
今年はどんな年だったか
お仕事のサービスリリースから始まりDJイベント参加やDJイベント企画、諸々の制作・引越・転職いろいろが一斉に重なって特に10-12月はとにかくパチンコの玉のように色んな所にぶつかりまわる日々を過ごしました。体力的にもメンタル的にも総じて忙しい一年でしたが今後の人生において大事なことを色々考えさせられたと思います。そういえばこの期間に30歳になりました。
20代の終わりに際して色々と過去を振り返ってみましたが、 20代はどん底から始まり、環境を変えながら這い上がる10年間だったなと思います。環境ってマジで大事よ。10代と似たような軌道をたどりつつも一回り大きくなっていて、人生はらせん構造だなと感じます。来10年も似たような軌道を描きそうな予感。ニーチェもそんなこと言ってた気がする。知らんけど。
来年はどんな年か
転職をしました。1月から働き始めます。まずは慣れることが最優先事項か。
色々な変化のあった2024年の後の年なので、30代1年目もあり、とにかく慣れて今後10年の基盤をしっかり固め辛いときにも踏ん張れる環境が作れたら良いと思っています。去年までが「均し」でしたが、今年からは「慣らし」かな。
今は不安:ワクワク=2:1ぐらいのブレンド具合の気持ちでいます。
お仕事
今年は一人で色々見なけばいけない場面が多く、設計力やエイヤとリリースする力が増したと思います。中でも複雑で重要な処理の設計を押し進めることができたのは当時はハラハラでしたが今となってはいい経験をしたなという気持ちです。反省点もありつつ、この動きは今後大事になってきそう。思いの外、エミュレータ作りなどで培ったバイナリやフォーマットを見る力が活きたなという感想です。前職では先輩エンジニアがやっていた領域を自分一人で設計実装テストリリースまでできたのも改めて良かったです。
職場やチームのコミュニケーションを観察する場面も増えて、色んな価値観があるんだなぁ...ということを心から理解することができました。後半は会社全体を俯瞰してみることもできたんじゃないかな。
お勉強
今年は音楽関係の趣味に打ち込みすぎてなかなかアカデミックをできませんでしたが、辛うじて数理マルクス経済学のお勉強を始めました。
簡単な線形代数と微積分が出てくる程度で比較的理解しやすく、経済学というジャンルは大学の基盤教育で受ける程度でちゃんと学んだことがなかったため選んでみました。
読んでみると、経済や市場や労働者や資本家をモデル化しようという試みのようです。
経済学の文脈の数学が行われているため、読みづらかったり解説が丁寧だったり初めて見る言い回しが行われていたりと文化の違いを感じる場面も多々ありますが、身の回りの経済が元となっているので現実に近く理解しやすい分野だなと感じました。
ちなみにこの本を読む前に簡単なマルクス経済学の入門書を読んでみましたが、なるほど、これを言いたいのだなといい具合にネタバレをされてなかなか良かったです。
マルクスというとエンゲルスと共に革命家の印象が強く警戒しがちですが、純粋に経済学の観点だけみるととても面白かったです。
趣味
DJ
前半は月3回ほど、後半は月1回ほどとなりました。去年に比べて、リアルのカジュアルDJの頻度が上がったなという所感があります。
中にはデッカいイラストレーターさんのライブペインティングのバックDJをさせていただく場面も2回あり、色々学びの多かった一年でした。
数えてみたらセトリの数はついに70個ほどになっていて、思えば遠く来たものだ。未だに下手ですが。
DTM
1曲書きました。M3で売りました。偉い。
SHIZUMIという曲は「諦めと希望の中間」のテーマで作った曲で、自分の人生観がちょっと出せて良かったし、それに対して考察や感想を貰えることは純粋に自分の学びにもなりました。
VRChat
後半はほとんど入れなくなっちゃった...。ワールドを作るなど裏方業が忙しくなり、そちらに専念してしまっています。
逆に言うと、BlenderやUnityととても仲良くなれたのは良かったかなと思っています。
RTX4090 OC買ったのに全然活かせておらず悲しい。
思ったことの羅列
ここ数年で考えたことのメモから、面白いなと思ったものを羅列しておきます
(一部抜粋)
事実と真実とがあり、事実は無限に分解・還元できてしまいます。
ところで人間には自覚的なパラメータと無自覚なパラメータがあります。
パラメータ軸の具体例を考えてみます。
コミュ力が高い
=> トーク力がある
=> わかり手力がある
=> 気が利く
=> おもろい奴
=> ...仕事力がある
=> 状況把握が早い
=> 決断力がある
=> 調整がうまい
=> アイデア力がある
=> .......いっぱい軸がでてきます。軸は無限にあります。そして無限に分解できます。
どうしても他人と自分を比較する場面は出てきますし、競争社会なら尚更です。
この時、パラメータの軸が無数にあることを意識しないと、不幸せな結果になってしまうと感じます。
Aさんと比べてBさんは相対的にトーク力がない => よって、BさんはAさんより劣っている
と判断するのは早すぎます。軸は無数にあります。無数にある軸を無視し、優劣を決めると色々な不幸せがおこります。A > Bの関係ができたとき、同じ理論で無数にある軸からある1つの軸を選びB > Cの関係を作ることができてしまいます。
負のスパイラルです。優劣の劣を例にしましたが、逆もまた然りです。どうとでもとれてしまうのです。無自覚なパラメータというのは、先天的に与えられたパラメータと、後天的に獲得したパラメータのうち無意識に伸びたものです。
無自覚なパラメータは、自分が普段自然と行っていることです。昔ある人が「人間の臓器は異常が起きるまでその存在に気づかれない」ということを言いましたが、そのようなものです。
異常が起こっている、すなわち環境によって判断された出力の善し悪しから逆算して、このパラメータの値が悪そうだぞ、と推論して初めて軸を自覚します。無自覚なパラメータを自覚するためのもう一つの方法が、褒め・褒められです。
特に、「努力した覚えもないけどなんか褒められた」というのが「無自覚なパラメータの自覚」です。
自覚するパラメータが増えたということは、比較する軸も増えたということです。
そして軸が増えたということは、他者の軸の値も（相対的に）見えてきます。他者の軸の値が見えてくるということは、バイアスを考慮した配慮もできるようになります。
「どうして●●ができないんだろう」「自分だったら●●するのに」のような経験ありませんか。
この背後には無自覚なパラメータが存在しそうです。結局、軸が無数にある中で人をきちんと評価(これはお仕事の評価に限らない)することは、かなり難しいと感じます。
とはいえ評価が必要な競争社会ですので、大事なのは評価を内面化しすぎないというところなのかなと思っています。
逆に、プライベートな人間関係では、他人を評価するという行為はとても大それたことだなと思うので、極力上下関係を作らずに生きたいものだなぁと思うこの頃です。2023/1/16
負の感情を昇華するのも良いけど、それで成功すると負の感情を人に押し付けてしまいそう。良くも悪くも力が保存されているというか、押された分どこかが出ちゃう。
良いサイクルを回すためには、施しを受けたら施しを返す、受けた正の力を正の力で返すこと。2021/12/21
執着してるものを一つを止めると勝手に世界は広がるのかもしれない
2021/12/3
気の持ちようとして(そもそも気の話だが)、「自分の欲求は自分で満たさなくてはいけない」というルールがある。
自分が感じた欲求は、まず自分が第一の当事者として解決しなくてはいけない。
手を差し伸べてくれる人はいるが、その場合は「低姿勢」で「感謝」をマジで伝える。2021/9/23
過去の記事:
2023年振り返りと抱負
去年のやつ:
師走と言いながら今年はゆっくりした年末年始を過ごしております。
前職よりお仕事がちゃんと定時に始まって定時に終わっており、連勤も徹夜も残業もなくてすごい。
去年一昨年の抱負であった「均し」は割と達成できたかなという気がしています。
代わりに趣味に使う時間が増えた。
お勉強
あんまり体系だったアカデミックなことはあんまりしてないです。
必要に応じて調べ事するぐらい。活動時間が減ったわけではないので正常かなと思ってます。
お仕事・技術
お仕事でキメを作らなければいけないことが増えたので、「今まで惰性でこういう技術選択してたけどなんでだっけ」と振り返る機会が増えました。
最近は技術的なこだわりって結構どうでも良くて、明確な要点だけ押さえたら後は有象無象がそのうち完成形へ収束していくんだよなぁ～という気持ちになってます。
はたから見たら急に変なところにこだわりだすな～って思われてそう。
人生みたいなもの。
趣味
VRChat
1年続きました。めっきり音楽イベントばかりになっちゃいましたが。
最近はワールドづくりを始めてUnityの知識が徐々に増えてきています。お仕事の片手間にシェーダーっぽいの書いてたことあったんですが、あの辺の知識やらエミュレータ作りやら3Dゲーム数学、Flutterのレンダリング周りなどここ数年の知識が実際の技術に結び付いてきた感あって楽しいです。「役に立ったかは分からないけど、脳内で概念が結び付いて楽しい」という状態です。
来年はUnityやRust、シェーダーなどの趣味技術系のエンジニアコミュニティにたくさん入れるといいな。
DJ
DJ初めて1年ぐらい経ちました。何も分からないままrekordboxというソフトがあることだけ調べて、音源を集めてUSBに放り込んだのが2022/12/3でした。
翌日の12/4、少人数の前とはいえいきなりDJ機材で50分ぐらいのセトリをやったのはなかなか頑張った気がする。
当時のプレイリスト見てみるとこんな感じ。いつもDJを聴きながら曲を集めていたので、当時聞いていたDJさんたちの趣向が強い気がしてます。
なんでラジオ体操第一が入ってるんだ
その後も月一程度で身内で発表していました。DDJ400を知人に譲ってもらったのもこの辺です。
そして、2023年2月に勢いでVRDJデビューした記憶があります。
そこから始まりちょうど30件のイベントに出させていただきました。ありがとうございます。
DJはいくらやってもなんも分からん。
DTM
DJ始めたらDTMも始めることになりますよね。多分。
いくらかRemixを作ったりちょっとした音遊び的な曲を作ったりしています。
まだまだやること多そうで良い趣味。
お絵かき
半年ぐらいやってないかな？
一旦お絵かきは中断です。そのうち再開するかも。
まとめ
VRChatとDJとDTMをしてた。
来年は趣味の技術方面を伸ばしたい気持ち。
2022年振り返り 学んだことと来年の抱負
去年の振り返り
早いもので一年も終わり。年々一年経つのが早くなっており、今年は3か月分ぐらいの記憶しかありませんが、振り返ってみたいと思います。
今年学んだこと
今年も、例年に引き続き
- 低レイヤー周り
- CS・数学
- 哲学・思想
の三軸で色々お勉強をしました。
低レイヤー周り
OS
去年の抱負にもあった「OS自作本」ですが、有休消化期間を使って進めました。（実は転職したんです）
みかん本を進めていきます
— エムジェイ（mjhd） (@wait00002) 2022年9月25日
ゼロからのOS自作入門 | 内田 公太 |本 | 通販 | Amazon
結果としてx86の闇を知ることができたり、マルチタスクの仕組みなど学ぶことができました。x86、OSを作るための機能がモリモリで、逆にARMとかどうしてるんだと心配になっています。
本を進める中で、いくつか罠を踏んでトラブルシューティングをしたのですが、こういった経験ができたのも大きな学びだったなと思いました。
PlayStationエミュレータ
去年の抱負では「GBAエミュレータ作りの続きをやっていきたい」と書きましたが、気が付いたらPlayStationエミュレータ作りに変わっていました。
詳しい内容は記事に書いたのですが、MIPSアーキテクチャに親しみが持てるようになったのは大きな学びだったなと思っています。
また、今までのレトロゲームとは違い、ようやくGPUに近いプロセッサを実装したので、世のGPUドライバがどんなことやってるんだろう～、という疑問がなんとなく想像ついた気がします。
現在はCDドライブの実装を続けており、BIOSがデータの読み出しを行ってDMAによってRAMに転送されるところまでは動いています。が、そこから先まだ動作しないため要実装です。何かROMが動くと良いな。
Flutterのリンダリングパイプライン
これは比較的高レイヤーにはなるのですが、Flutterのレンダリングパイプラインについてたくさん勉強をして記事を書きました。
お仕事でFlutterを触る機会も増えたため、豊富なドキュメントやソースコードを読み漁りました。
PlayStationエミュレータ開発の知識も相まって、GPU~ブラウザの間で行われている処理について何となく全体感が分かるようになってきました。
また意外にも、FlutterとChromeは関連するところが多く、Flutterを学ぶことでWebフロントエンドについても理解が深まりました。もっというとFlutterはReactにも影響を受けているので、少し距離を置いてReactを見つめなおすことができました。
こういう、無関係に思える概念同士が繋がる瞬間はとても楽しいですね。
関連して、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)
CS・数学
今年はフワフワしてる分野の学び直しを重点的に学習しました。
線型代数（学び直し）
学部でやったころの記憶が完全に吹っ飛んでいたので、放送大学の「線型代数学」を受講しつつ、「実例で学ぶゲーム3D数学」を読みました。
ジョルダン標準形までの一通りを放送大学で復習しつつ、ゲーム3D数学の本で幾何的イメージを付ける、といった流れで実際の活用例まで理解することができ学びだったなと思います。
低レイヤー周りの勉強とも繋がってきて、GPU周りの用語や概念はゲーム3D数学を読んだ後だとスッと入ってきました。
統計学（学び直し）
仕事でFlutterのパフォーマンスチューニングをしていて、「統計的有意な差がある」とは何なのか、ちゃんと説明できなかったので学びました。
放送大学の授業内容は理論的な話に持ち込まず、いろいろな統計手法の簡単な原理と特徴の説明と例題を解く感じだったので、まだ少しフワフワしています。
目的の benchmarkhor | Dart Package (pub.dev) というパッケージがどのように統計的解析をしているのかはキチンと説明ができるようになったのでヨシとしますが、自分で検定の設計ができる程度にはどこかで学びたいな…。
ブロックチェーン
巷でWeb3というものが話題になっていたので、理論をちゃんと学んでおきたいよね、ということで例の論文 bitcoin.pdf を読む勉強会を3人ぐらいでやりました。ギャンブラー破産問題面白かったです。
おかげで某Web3の本のアレな部分にも気づけました。
とはいえ、大学の卒論がこの辺りだったのであんまり新しい学びはないかも。
制御工学
友人と数年間続けている勉強会の題材を考えていて、次に学ぶことに迷いすぎて気が付いたらカルマンフィルタの学習を始めていました。
今まで学んだどの科目とも違う分野で、つまづくことがかなり多いです。脳負荷が高くて良い。
そもそも古典制御をおろそかにしていたので、古典制御を学びつつカルマンフィルタの本を進めています。ラプラス変換、神、ナニコレ。
その他
様相論理の本を買って読むなどしましたが、途中で放置してます…。知識論理や信条論理などの面白い派生や、モデル検査など応用の幅が広いしエンジニアにもかなり近い分野なのでそのうち読破したいです。
哲学・思想
ここ3年?ぐらい、哲学や思想を放送大学の授業や入門書によって学習してきました。最近は入門本ではなくて翻訳書を読み始めています。
以前は独学で翻訳書を読んで撃沈することが多かったのですが、有料の勉強会を見つけたので解説を交えつつ読むことができるようになってきました。
ルネ・デカルト「方法序説」
http://www.the-five-books.com/lecture/34
The Five Booksという、一か月ほどかけて哲学書を読む勉強会に参加し、デカルトの「方法序説」を読みました。
試論を含まない序説だけならかなり薄い本で、内容もそこまで難しくないため、本自体はサクッと読むことができ、デカルトの生き方に学ぶことが多かったです。
例えば、明晰判明という概念はソフトウェア工学とかなり相性が良いのではと感じますし、彼の定める格率は自分より年下の年齢で考えたと思うと素晴らしいなと感じます。
勉強会の方では、時代背景や他の勉強会参加者の意見を聞く場面があるなど、独学で読む数倍の学びでした。
The Five Booksはかなり推しなので来年はライプニッツの「モナドロジー」を読む会に参加したいと思います。（むずそう）
カンタン・メイヤスー「有限性の後で」
そもそも思想を学び始めたきっかけがグレアム・ハーマンのオブジェクト指向存在論（もっというとOOUI）なのですが、避けては通れないカンタン・メイヤスーの「有限性の後で」を年末年始で読んでいます。
読み始めてから後悔したのですが、先にカントの純粋理性批判を読んでおきたかった…。
趣味
今年はいくつか趣味も開拓しました。
VRChat
お砂糖文化やVR睡眠文化に憧れて、Meta Quest2とゲーミングPCをポチって、VRゲームのVRChatを始めました。気が付いたらTrustedになっててびっくりしてます。
基本的にはワールド巡り（観光）や、DJイベント、フレンドとお喋りがメインの楽しみ方をしてます。お酒を飲みながらVRChatするのが楽しすぎて肝臓がダメになったので、最近はノンアルコールです。
VRの世界には正解がありません。常識的なものはないので、どんな楽しみ方をしても（人に迷惑をかけなければ）OKです。
対面の会話が苦手だな～下手だな～と自分で思うことが多いのですが、VRChatはアバターという仮面をつけた状態でコミュニケーションの成功体験を積むことができるので良いです。似たような報告は色々と見かけるので、こういう仮面舞踏会状態のコミュニケーションって良いものなんだろうなと感じます。
関連して、BlenderやUnityとちょっと仲良くなりました。昔メタセコイア触ったりUnityでゲームを作ったことがあったのですが、あのあたり経験が無駄にならずに済んだ。
お絵かき
こちらの記事に触発され、お絵かきの練習を始めました。
お絵かきは、少なくとも死ぬまでに自分で満足いく程度で良いのでファンアートなど描けるようになりたい、と思っていた夢の一つでした。
そもそも自分は恐らく自分一人でゲームを作りたいんだろうな、と思うことがあり、取り組んでいます。（プログラミングのきっかけもゲームだった）
基礎的な練習をしつつ、たまに下手な絵を描いてお絵かきコミュニティに投稿すると少ないですが「いいね」を貰えて嬉しいです。前述したVRChatで使っているアバターのファンアートを描いたらアバターの作者さんがRTしてくれて感動してむせび泣きました。こういう体験ができただけでも始めた甲斐があったのかなぁ…と思います。
それにしても巷の絵師、みんな改めてすごすぎる、上手すぎる。
DJ
ひょんなことからDJコン(DDJ-400)を手に入れてたまに小さな仲間内でDJするようになりました。DJライブはずっと好きだったのですが、自分で一度やってみるとパフォーマンスの解像度が上がってさらにライブを楽しめるようになりました。良い。
転職もそうですが、同じ事柄を少しずらした別の視点から観測すると、3Dメガネのように一気に解像度が上がりますね。
ゲーム
朝早起きして少しずつゲームをプレイしました。
抱負「均し」はどうだったか
去年、抱負として「均し」を上げ、ハードワーク燃え尽きサイクルからの脱却を目指し、コンスタントにパフォーマンスを出していきたいという目標でした。
達成率: 50%、といった印象です。
技術的・人生的な学びもありつつ、6-8月ぐらいに体力・精神的なバーンアウトをしました。
バーンアウトしない計画的なアウトプットというものが大事だと気づかされました。
でも、例年2-3回ぐらい燃え尽きてたので多少改善してそうです。気持ちの切り替えができるようになってきて偉い。
来年の抱負
去年の抱負の「均し」をより具体的にして「力をうまく抜く」です。
世の中の色々は思ってるより頑張らなくても勝手にどうにかなってしまうものも多いなと思い始めています。（仕事もプライベートも）
ビリヤードの玉のようにせわしなく行ったり来たり、どうしても生き急いでしまうところがあるので、来年はうまく肩の力を抜いてドッシリ構えていけたらなと思っています。
ズボラ自炊ブートキャンプ
やあお前ら！元気に過ごしているか？
この記事は 一人暮らし Advent Calendar 2022 - Adventar の17日目の記事だ。他の記事もみんな面白いからぜひ見てくれ！
今日はズボラに自炊を続けるノウハウを、ブートキャンプ形式でお前らに伝授したいと思う！楽しい旅になるはずだ、心してついてきてくれ。
俺たちズボラー
お前ら心して聞くように！
怠惰は美徳だ！ズボラであることに誇りを持て！
もう一回言おう、
怠惰は美徳だ！ズボラであることに誇りを持て！
真面目に家事なんてやってたら飯が冷めちまうからな。
必要十分な条件を見つけて、とにかく手を抜くことが世の中大事なんだ。
自炊を続けたい
いいか、ものごとを継続して行うには、全力で自分を甘やかすことが大事だ。
自炊を継続させたいという気持ちから「毎日作ろう」「作り置き頑張ろう」「お弁当毎日もってこう」とか考え始めてはダメだ。
特に俺たちズボラーは、毎日頑張ることなんてできない！なぜなら怠惰！美徳だからだ！
できなかったときに失敗体験を覚えてしまうような呪いを自分にかけるんじゃない！
諦める理由になるし、意識していなくても軽いトラウマの素になってしまうことだってある！
苦手意識を持ってしまうことだけは全力で避けろ！
逆に、自炊のハードルを下げて下げまくれ！
野菜炒め作ったら自炊？偉いぞ！お惣菜をレンチンしたら自炊？いいじゃん！カップラーメンにお湯入れたら自炊？いいよいいよ！
自分を追い込むのではなくて、とにかくハードルを下げて下げて、自炊が好き！と言える状態がゴールだ！
いいか！今日の話のメインはここだ！「自炊のハードルを下げ、好きになるためには」
まだまだウォーミングアップだ、しっかりついてこい！
必要なもの
自炊を楽しくする、心持ちを楽にするために必要なものを紹介していく！心に響いたらぜひポチってくれ。
マルチビタミン＆ミネラル
栄養について考え出すと料理は途端に難しくなる！特にビタミン、ミネラルは生野菜を取らなければいけなかったりとズボラーにはあまりに難易度が高い！
そこで、マルチビタミン＆ミネラルを飲んで、おおよそ一日に必要な栄養素を担保しよう！
こいつがあれば、俺らズボラーは好きなご飯を食べることができるわけだ！これでだいぶ心持ちも楽になる！
（もちろんこれ以外にも必要な栄養素はある。完全食を自作してみた1 - MJHD (hatenablog.com) を見ると他にどんな食品が必要か分かるかもしれない。でも三食食べていれば基本大丈夫だと思う）
ポリエチレン手袋
ポリエチレン手袋Ｌ １２０枚入 | 【公式】DAISO（ダイソー）ネットストア (daisonet.com)
ズボラーは自らの手を汚すべからず！
食材を切るとき、洗い物をするとき、生ごみを捨てるとき、あらゆる場面で湯水のごとくこの手袋を使え！
手が汚れないだけでも料理に対する嫌な気持ちがかなり減る！
いいか、使い道は下の三つだ:
- 手が汚れそうな下ごしらえの時
- 排水溝のごみや生ごみを捨てる時（ゴミをつかんで、そのまま裏返して口を結んでポイ）
- キッチンの掃除をする時
特に我々ズボラーは「排水溝のごみや生ごみを捨てる、キッチンの掃除をする」にめちゃくちゃ抵抗を感じると思う！
わかる、わかるぞ！
とりあえずポリエチレン手袋を300枚ぐらい買え！これがあるだけで料理に対するハードルがかなり下がるはずだ！
アイラップ
これも3つぐらい買え！
一人暮らしだと玉ねぎも人参も肉もあらゆる食材を半分程度しか使わない！余った食材をこれに包むもよし！
俺は毎月一回、5kgほどの肉を買い込み、一食分の大きさに切ってからアイラップに包んで冷凍している！肉がいつでもあるというだけで料理のハードルが下がるぞ！
我々ズボラーはカレーが大好きだ！カレーは意外と腐りやすいので、冷めたら一食分に小分けでアイラップに入れ、冷凍しよう！
簡易手袋としても、簡易ゴミ袋としても使えるこれは必需品だ！
バット
ステンレストレー深型 約２１．５×１６ｃｍ | 【公式】DAISO（ダイソー）ネットストア (daisonet.com)
これも3つぐらい買え！いやもっと買っても良い！
俺たちズボラーは煮込みながら食材の下ごしらえを同時並行ですることはできない！
あらかじめ全ての食材の下ごしらえをして、バットにためておいてからから鍋に放り込むんだ！
とりあえずあるに超したことはない！
その他
包丁やまな板は一旦100均のGalaxyなんとかと書いてあるような安いやつで良い！
とりあえずなんか買ってくれ！
後述するが、自炊熱が冷めてきたころにこの辺りの道具を新調するとモチベと継続に繋がるので、それまで良い調理器具は我慢しておき、安い調理器具でハードル低く始めるというのも戦略の一つだ！
あと料理のさしすせそと言われるものと、各種うまみ調味料（味の素、だしの素、ガラスープの素、コンソメ）は一通りある前提で進める！なかったら一旦買っておいてくれ。
料理を作れ！
自炊する準備はできたか？
ちゃんとマルチビタミン＆ミネラルも飲んだか？アレは空腹で飲むと死ぬほど気持ち悪くなるから何か胃に入れてから飲めよ？
よし、じゃあ料理を始めるぞ！
野菜と肉を刻め！全部バットに入れていけ！フライパンに放り込め！火を通せ！
ここで俺と約束して欲しい。火を通してる間に包丁とまな板とバットは全部洗ってくれ！
食べ終わった後にシンクが料理の洗い物で埋まってる様子を見るだけで、失敗体験になってしまう。いいか、火を通してる間は洗い物の時間だ。動きを止めるな！
やる気が起きなかったらHip Hop流して踊りながら洗ってほしい！時間が余ったら踊りながらキッチンの掃除をしてくれ！次の料理をするハードルがかなり下がるはずだ！
火が通ったら、うまみ調味料を入れろ！うまみ調味料は絶対入れろ！終わり！
いいか、これはイーブイだ。ここに好きな調味料を加えて飽きないようにしてくれ
- 醤油と酒やみりん（和風）
- カレールー
- オイスターソース（中華）
- 酒・豆板醤・甜麵醬（麻婆）
- トマトピューレ
- チリソース
- ...なんかKALDIで売ってるやつ適当に入れろ
水を入れてスープにしても良いな！塩と砂糖とうまみがまともなら大抵のものは美味しくなるはずだ！
塩を入れる量は、１日の推奨摂取量（男: 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言語の良さに関する記事で「読みやすい/読みづらい」についての言及がありました。
Go言語のレシーバー(他言語でいうthisやself)が明示的に記述されているためメソッドであることが確定する点や、public/privateが命名に現れるため参照しやすい、型が明示的であるためオブジェクトの動作を把握しやすい…などが挙げられています。
視覚情報が限られた状況では、強いコンテキストと弱いコンテキストのグラデーションはより濃くなるため、強いコンテキストの多いGo言語は読みやすいと言えるのでは、と思っています。
この話は晴眼者であるかに関わらず起こる問題で、コードレビューのような限られたdiff、限られた時間で読まなくてはいけないコードではグラデーションが濃くなると思います。
三行まとめ
コードは文章の一種。
適切なグループ化はやはり大事。
弱いコンテキストは読みづらい、特にレビュー時など。
余談
この「事実」「グループ化」「コンテキスト」の話は、文章、コード以外にもUIデザインだとか物語、音楽など、シーケンスがあり人間が認識する色々なものに適用できるんじゃないかとなんとなく思っています…。
