未分類の雑記

・睡眠時間7時間くらい。すげくねみぃです。電車に乗ってても半分以上はぼーっとしてます。


・とりあえず、今の状態をログしてみる。
別に「複雑なことを考えられない」「ネタ出しができない」という状態ではなく、ある程度の発想は浮かんでくれるし、コーディングの質も落ちているとは思えない。ただ、思考が長く続けられない。
原因は睡眠不足と推定。少なくともマイナス感情に流されているわけではない。マイナスなことを考えることによる思考の中断ではなく、思考することがしんどくなってくるための中断。
ただ、マイナスの感情が奥にひっこんでるだけで、実はマイナスの感情が原因だったりするかもしれない。


・そもそも、「思考したくない」という感情は面白いな。それは自分にとって何の利益があるんだろう。「疲れてるから動きたくない」みたいな回復方面の話なんだろうか。


・なぜ自分の「調整期間の見積もり」が甘いのかに関する考察。
まず、来月でようやく3年目に突入するバイトプログラマーであり、経験するプロジェクトは今回の出まだ2つ目であるということ。前回のプロジェクトの担当箇所の応用が多少は利くものの、基本的には初めての作業であること。ゆえに見積もりが甘い可能性。
次に、趣味でも「調整」にあまり時間をかけたことがないということ。基本的には「アイデアの具現化」の作業がメインであり、面白くなさそうならそこで終わってしまう場合がある。つまり、「プロトタイプ作成」と「調整」の試行回数に差があるため、その経験の差が出ている可能性。これは、「プロトタイプの作成はわりと早くできる」「プロトタイプの段階ではあまりプログラムの構造が綺麗ではない」にも通じる。普通はプロトタイプのコードは汚いものらしいけど。
んで、最後は「他人とやる調整」の試行回数の少なさ。趣味での調整は全部自分ひとりでやるが、仕事の場合は「こちらで作成→企画側の確認→企画側の要望出し→こちらで要望対応」というループがあり、企画側への伝達やら要望の解釈などのコストがあり、企画側も常にこちらに専念してくれるわけではないので、企画側に渡した後に時間がわりとできる。そこらへんを考慮できてなかった可能性。
たぶん、全部正しい。簡単に言えば経験不足。

  • だいぶ回復してきたので、最近の作業を書き出してみる。
    • コーディングはしてない
    • パラメータの調整(というか確認作業)
      • 途中で、もう少し効率の良い方法を思いつく
    • 音楽の音量を少し大きくして両耳で聴くモード

あんまり作業内容は関係ないかな。前回の記憶はさっぱりだが、たぶんこの手のは一定時間で回復してたはずだ。記憶がさっぱりなんでログしとかないと検討できないが。とりあえず、12:30の段階で使い物になる程度には回復。



・もしかしたら、前日の養分摂取が影響してるんじゃないか?野菜食ってないしな。


・昨日は、ただでさえ遅い帰りだったのに、「彩冷える」の曲を買うために寄り道をしたのだった。しかも、ついでにそこでPlastic Treeの曲も買ったのだった。そして、今聴いているのだが、この体調で聴くものじゃないなという感じなのだった。
体調が良い時に聴かないと流されすぎる。


・なんかもう、わりきって雑記書くべきなんじゃないかと思い始めた。今の精神状態も少しアレなので、あんまりこの判断は信用できんが。


・で、たしかメモし忘れてたが、リアルタイムの説明の場合、相手の聞き返しに対してはやっぱり極力別の言葉で言い直さんといかんね、と。「構造の解説」で上手くいかなければ、「個々の事象」を提示してから云々とか。この程度のは本なりなんなりでまとまってそうだし、そっちを当たった方が早いはず。時間をかけるべきは実践と調整の方だ。


・「ハウツー本」とはつまり「手法」の提示であり、その書評なり感想なりはその手法の「検証結果」である、とみなせる。「提案」と「検証」。ループを高速で回すには本だと遅いか。検証結果を受けて、本を書き直すのは時間がかかりすぎる。でも、最初の段階で精度を上げるなら本で良いか。「本→実践→調整→実践→調整→...」。ここらへんを1セットで扱う手法は?
て、「本=1冊」とみなしてしまってた。本が複数あれば、それぞれに検証可能で、最初の検証だけなら回数こなせるか。


・「ハウツー本の数をこなすこと」への揶揄として「そんなの読んでばかりじゃ云々」とかがあり、それはつまり「最初の検証」しかこなしてないという点に対しては妥当だが、「検証→調整」のループに対しては妥当じゃないな、とか。


・コードの云々は、「機能」と「意味」に分けられるだろうか。「書く側」にしても「読む側」にしても。
書く側は、普通に機能を書きつつ、「コメント」「const」「protectedとprivate」などによって「意味」を伝える。
読む側は、それらの「意味」を頼りに「機能」の読解を行う。
みたいな?
それは自然言語に適用するとどうなる?
なんか、以前書いた気がしてきたが、「C++の動作はCでも全て可能である。つまり、機能が同じである以上、それ以外の差がもたらすものは意味だ」という感覚が最近芽生えたので改めて。「機能」の定義が曖昧だなぁとか、「作りやすさ」とかはどういう扱いなのかとか、色々他に考えることもあるんだけど。


・「雑記」と「一人語り」の差って何だろう。


・「苦労したこと」なら解説はわりと簡単。「苦労してないこと」の解説は難しい。
そして、「知らないこと」への対応をどうすべきかを、考えたことがなかったことに気付いた。「知りません」だけじゃあんまりだ。「知ってそうな人を紹介する」だとか、色々できるはずなんでこれはこれで考えたいなぁ。


dankogaiの「愛」の定義を見て、「色々反論出そうだなぁ」と思いつつ、「定義がある分、比較検討がしやすそうだなぁ」と考えつつ、「でも、自分はまだ"愛"を定義も知覚もしてないんだよなぁ」となる。「認識」まではできてるんだけど、「知覚」ができないし、「定義(文章化)」もしてない。
「認識」という単語は適切でないか。「理論上、愛されてるはずだ」という導出までは可能であり、だからといってそれを感じることはできない状態。


・「愛は言語化できない」というベタな反論を想定しつつ、「それが現象である限り、言語化は可能だ」と脳内で反論して、「個体差が大きい場合、言語化による一般化は不適切」とさらに脳内で反論してみる。反論も内容自体はベタだった。
それよか、脳内反論で出てきた「現象である限り記述可能」というのはどの程度正しいのだろう。