:hyuki: 「意味のあることに時間を使おう」と考えるのも善し悪し 自分の時間を意味のあることに使うのは結構なことですけれど、難しいこともあります。 1つは、自分の時間を意味のあることに使おうといっても、それだけだと息が詰まってしまうような場合があるということ。 もう一つは、自分が何かをやろうというときに「これは意味のあることだろうか」と考えていると多くのことが無意味に感じられてしまうということ。 もう一つは、意味のあることだけをしようとすると、何も始められなくなるということ。 それからもうちょっと深い話になるんですけど、自分が判断する「意味のあること」は本当に意味のあることなのかという問題もありますね。 ざっと要約すると、そのくらいの懸念点というか、問題点が思いつきます。これはプラクティカルな問題で、しかも注意が必要です。疲れているときや、あまり調子が良くないときに「意味のあることだけに時間を使おう」とすると、メンタル的にはよろしくない方向に進むという実感があります。ですから「意味があることに時間を使おう」と考えるのは、悪いことでは無いんですけれど、それもまたほどほどにしたほうがいいと思っています。

"Divide and Conquer" in writing process I engage in the task of writing books every day, and a thought that often crosses my mind is the importance of dividing my work into smaller, manageable pieces. This concept of "divide and conquer" resonates deeply with me. If taken to an extreme, one might argue that nearly every technique exists for the purpose of this division. Since humans can't process vast amounts of information all at once, both writers and readers rely on this division. It's rational, especially when humans communicate with each other. We divide books into chapters, sections, and paragraphs, and this division becomes a natural part of our working process. It’s not just a casual division, but a deliberate strategy to tackle work consciously. Tools such as outline editors can assist in this division, but the choice between using an outliner or a regular text editor might not be the critical point. Instead, understanding the mode in which one is working and the type of division being applied is more crucial. Whether writing or programming, the concept of divide and conquer becomes evident once we consider things from a slightly higher abstract level. However, it may be questioned whether the essence of the work changes by dividing, and perhaps it doesn't. But what's vital is the ability to gauge progress, to say "this part is done," or "this part still needs work." Dividing the work makes such references possible. As I wandered during my morning walk, I pondered that the division must be done in moderation. Dividing time or work excessively creates new complexities to manage, which can defeat the purpose of the division itself. There is a lesson here in the dangers of taking a single strategy to its extreme. You should not divide to the point where governance becomes difficult. The art of divide and conquer is indeed essential to my daily routine of writing, but like many things in life, it must be approached with balance and careful consideration. From: @npub1leyv...thvh

結城浩のマストドン

結城浩 / Hiroshi Yuki (@hyuki@social.hyuki.net)

Attached: 1 image :hyuki: 本の執筆作業と分割統治 毎日、本を書く仕事をしているわけですけれど、いつも思うの�...

:hyuki: AI時代の技術文書について思うこと 先ほど分割統治の話をしていたんですが、このAI時代、もしかすると、将来的にプログラムのドキュメンテーションというのが全くその意味を変えてしまうんではないかと思いました。 ドキュメンテーションが必要なのはなぜかというと、将来そのソフトウェアをメンテナンスする必要があるからですね。メンテナンスするタイミングで開発した人はいなくなってるかもしれないし、開発した人が、たとえ同じ会社の中にいたとしても、内容を忘れている可能性が高いでしょう。それは人間の限界だからです。 でももしも、プログラムの内容をAIが全て把握しているとしたら。プログラムの内容に関する質問に全てAIが答えてくれるとしたら。あるいはまたプログラムの改良そのものもAIがやってくれるとしたら。そのときには、ドキュメンテーションは果たして必要になるかというのは大きな疑問です。もちろん、何らかの責任担保をするためにドキュメントが必要になるということはあるでしょう。でも、それはいわば人間の側の都合であって、実際にプログラムの改良や修正を行う上では、不必要なドキュメントである可能性がありますね。 これはあくまで予想なのですけれど、現在書いているような技術的文書(特にプログラムの内部的な文書)に関しては、将来的に大きな変化があるんじゃないでしょうか。 おそらく、これは、AIが行う処理に関する説明責任に関わることを研究している人にとっては、既知の話題だと思いますが、なんとなく思ったので書いておきます。

:hyuki: 本の執筆作業と分割統治 毎日、本を書く仕事をしているわけですけれど、いつも思うのは、いかにして仕事を小さく分割して片付けるかというのが大切だということです。いわゆる分割統治ですね。これはほんとにそうです。 極論するならば、いかなる技法もこの分割統治のためにあると言ってもいいんじゃないかと思うほどです。 たくさんの情報をいっぺんに処理できないので、分割するしかないんですね。これは書く側だけではなくて、読む側もそうですから、そもそも分割することは理にかなっているのです。少なくとも人間が人間とコミュニケーションを取る上ではそうです。 本を章に分割することとか、さらに節に分割することとか。節が段落に分かれていることとか。全てがそうです。 仕事をしていると、自然にそのように分割して作業を行うことになるんですけれど、それを積極的に推し進めるという考え方があります。つまり、なんとなく分割統治になるのではなくて、意識的に分割統治するということです。 具体的には、1つの節を書くときに節全体をいっぺんに書こうと思わないということです。今はこの段落に集中する。他の段落のことはいったん忘れる。そのようにして1段落ずつ書き進める。しばらく書いたところでモードを切り替えて、今度は節全体を眺めて段落同士の関係を調べる。これは気持ちのレイヤーを切り替えて、分割統治を行っていることに他なりません。 それを助けてくれるのはアウトライナーなどのツールになりますけれど、アウトライナーを使うか、通常のテキストエディタを使うかというのは、実はあまり大きなポイントでは無いかもしれません。 そうではなくて、今どういうモードで自分が作業しているのか。どのような分割統治を行っているのか。それを踏まえて作業を進めることが大事なのではないかということです。 もちろんそんなに杓子定規に機械的に作業が進まないんですけれど、基本的にはしっかり分割して、その小さな部分に意識を集中させるのが大事なのです。 今便宜上小さな部分と言いましたけれど、実際には小さな部分とは限りません。抽象度を上げて作業をしているときには、物理的に大きな単位をまとめて扱うことはよくあります。章の構成を考えているときには節を扱いますし、本全体の構成を考えているときには章を扱います。つまり、その抽象度のレイヤーに合わせて扱う対象は変化します。それを意識するということです。 それはプログラミングとよく似ていますね。プログラミングはプログラムという大きなものを構成していますし、本の執筆では、本という大きなものを構成しています。具体的にやっている作業は違いますけれど、ちょっと抽象度をあげれば、どちらも大きなものを構成するために分割統治を行っていることになります。 ところで、そのようにしていろんなレイヤーで分割統治を行って、次第に完成に向かうわけですけれど、もしかしたら、結局のところやっている作業内容は同じなのではないかという疑問も浮かびます。分割統治しようがしまいが、同じことをやっているんじゃないかということです。 そうかもしれませんけれど、大事なのは、どれだけ作業が進んだか、作業者が意識できる所が重要じゃないでしょうか。別の言い方をすると、「ここの部分はもうできた」「ここの部分はまだまだできていない」のように進行状況を把握できるということです。 分割することによって「ここの部分」という参照が可能になるということもできます。分割しなければ全体がもやもやとしていますから、ここの部分もあそこの部分もありません。指を指して「この部分」というためにこそ分割はあるのでしょう。 実のところ、作業自体も分割せざるをえないといえます。というのは、1日に働ける時間は限られていますから、その働ける時間のスロットにどのような作業を割り当てるかを考える必要があります。そんなに機械的には行きませんけれど、目安としてそういう割り当てが必要になるでしょう。 そしてそのときにもまた「今日はこの部分に取り組もう」のように参照する必要があります。ですから、大きな成果物を部分に分けておくということは、本質的に大切なのだと思います。 さらに、意識して分割統治するという先ほどの考えに則って言うなら、「今日はこの部分に取り組もう」というだけではなくて、「今日の午前中は」「今日の午後は」のように、さらに細分化することも有益でしょう。 しかし、何事も物事には程度問題というのがあって、この細分化をやりすぎてはいけません。なぜなら、時間を細分化することによって、今度はたくさんの時間という新たな管理すべきものが生まれてしまうからです。そもそも、たくさんのものを1度に扱うことが難しいというので分割統治を行っているのです。それにもかかわらず、たくさんの細かい時間とたくさんの細かい作業を作り出して、全て管理しようと思っては本末転倒です。 ここには教訓があります。1つのストラテジーを極限まで推し進めることの危険性です。作業を分割すればいいだろうといって極限まで分割してはいけません。なぜなら今度は統治が難しくなるからです。 朝の散歩をしながら、そんなことを考えていました。 　＊　＊　＊ 今回の話題も、加筆修正の後にメールマガジンの読みものにしたいですね。 いつもお読みくださりありがとうございます。 今日もまた素敵な1日になりますように。

toootはリスト対応してるなあ

Mastootアプリ、シンプルですごくいいんだけどリスト対応していないみたい？

:hyuki: 自作ツールの機能追加は楽しいけれど「シンプル化」も心がけた方が良いと言う話 最近のマイブームは、シンプル化ですね。 たとえばツールを作ったり、自分用のアプリを作ったりしますけれど、よくあるのはどんどん自分が入れたい機能を追加して、そのうち飽きて止めてしまうみたいなケースです。後からそのプロジェクトを再開しようとしたときに、たくさんの機能を追加しかけた状態で終わったために、全体がぐちゃぐちゃになってしまっているという困った状態になっていることがよくあります。 闇雲に自分が入れたい機能を入れるだけではなくて、使わない機能をちゃんと削除したり、あるいは入り組んでいるところをシンプルに整えたりする作業はとても大事だなと最近よく思うのです。それを先ほどはシンプル化と言いました。 狭い言い方をすればリファクタリングになるんですけれど、リファクタリングよりは、もうちょっとアバウトで広いことを私はイメージして話しています。機能を削除したり、ドキュメントを整えたり、という事全般な話ですね。 少し具体的な話をします。私はSNS関連のツールを作ることがよくあります。Twitterの投稿を自分で集めてきたり、あるいは自動的に投稿したり、そんなツールです。そういうのは動かすとすぐに結果が見えますから、とても楽しいですよね。そのために作ったツールに、いろんな機能をつけてもっと便利にならないかと追求したくなります。それは全然悪いことじゃありません。 でも、たとえば、そうやってツールをいじっている最中に仕事の方が忙しくなってしまうと、そのプログラムからしばらく離れてしまう時期が生まれます。そうやって1週間とか10日とか時間が過ぎてから、プログラムをもういっぺん見返すと何をやっているかよくわからなかったりするのです。 特に、プログラムを作るときには、その機能を実装するだけではなく、自分で新しい技術を試してみることがあります。クラウドのサービスや、今まで知らなかったライブラリ等ですね。そうなると、なおさら、時間をおいてから、プログラムを読み返すと、そもそもこれは何をやってるんだろうなどと困ってしまうケースがあるのです。 これは、多少大きなプログラムを作ったことがある人ならば、よく経験することだと思います。自分が作ったプログラムなのに、何をやっているかさっぱりわからないという状況のことです。 しばらく後からそのプログラムを読み返したときに全くわからないというのは、大変困ることですから、対策をしておきたいところです。1つの方法はドキュメントに残しておくことですが、今度はドキュメントとプログラムが不一致になることがあって、話がややこしくなります。 それなりに時間をとって、機能追加ではなくて、むしろ機能削除の作業をすることがなかなか有効だと思います。 プログラムを書いて、新しいライブラリを試して、その結果このままいきそうならばいいんですけど、ちょっと違うかなとなったときには、思い切ってその部分はもう削除してしまう。削除しても、バージョン管理ツールがありますから、ちゃんとその時点での作業結果は記録には残っているわけです。ですから、思い切って削除してしまう。 分量を減らすことは基本的に良いことです。なぜなら、自分が管理する量が減るからです。そして削除するというのは、分量を減らす最も端的な方法の1つです。 ついやってしまうのが、コメントのような形で古いコードを残しておくという失敗です。短期的にはそれでも悪くは無いのですけれど、長期的にそれをやってしまうとどんどんプログラムは肥大化してしまいます。ですから、先ほどから話しているシンプル化するという作業の中でその辺を注意したいと思っています。要するに使わないんだからどんどん削除しましょうということです。 プログラムの中身に限りません。不要なファイルを削除するとか、不要な手続きやドキュメントの項目や、ともかく「念のため」みたいに撮っておくんじゃなくて、思い切ってバンバン削除してしまう。そうやっていると、現在生きている部分が何なのかが明確になります。これこそ大事なことです。なぜなら、次回このプロジェクトに戻ってきたときに、どこが本当に生きている部分なのかを見分けることが非常に楽になるからです。そこにあるものが生きているものであって、そこにないものは生きていない(当然)。 本来なら、開発の途中からそういう作業をこまめにやっておくのが望ましいわけです。特に複数人で作業してるとしたならば、branchを切るなどして、うまくその実験的な部分とほんとに使う部分を分けたりするわけですけれど、私は1人で作業しているので、あまりその辺をうるさくしたくありません。気軽にコーディングしてるわけですからね。 でもいったんプロジェクトから離れてまた戻ってくるときのように、間に時間が重なると話は変わります。自分の手から(自分の意識から)、そのプログラムを話す前に、ちゃんとシンプル化しておくのが後々大変助けになるのです。 プログラムやファイル等のすぐ目に見える構造でもそうですけれど、もっと大きなシステム全体の仕組みのようなものも、シンプル化するに越したことはありません。 私は、実験的にクラウドを使ったり、VPSを使ったりするのですけれど、最近は「その必要がなければ、無理にネットワークにものを置く必要は無いのではないか」と思うようになりました。 というのは、私が作るアプリは自分1人がユーザであることが多いですし、私が使うデバイスはほとんどがMacBookとiPhoneです。またほとんどの場合家で作業しますので、外で扱うツールというのはとても限られているわけです。そのような自分のユースケースに合わせてコンパクトにアプリやツールのシステムを考えるのは妥当なことだと思います。 コーディングは楽しいものですけれど、過去に書いたコードをメンテナンスするというのは、なかなか時間を使って大変なものです。しかもコーディングよりは面白くなかったりします。ですから、コーディングに対して面白みを感じているうちに、そのようなシンプル化をしておくことが大事なのかなと今思っています。 朝の散歩をしながらそんなことを考えていました。 そもそも、この文章はiPhoneを使って音声入力し、自作のツールを使ってマストドンに投稿し、それをさらに自動的に「結城浩のひとりごと」という小さなウェブサイトに集約しています。こういうツールやアプリを作るのが好きなんですよね。 歩きながらの音声入力でほとんどノー編集なので、読みにくい部分があると思いますがごめんなさい。この文章は加筆修正した後にメールマガジンの読みものとなる予定です。 いつもお読みくださりありがとうございます。

Blueskyの招待コード Blueskyの招待コードをごくわずか入手できました。まだBlueskyに参加できていない場合、以下のリンクからメールを結城あてにお送りしてくだされば、おわけできます。先着順で渡しますので、無くなってしまったらごめんなさい。以下のリンクが404 Not Foundになったら招待コードが無くなったと思ってください。 https://link.hyuki.net/bsky

夏のフェア開催中です！『数学ガール』半額セール書籍一覧（2023年8月31日まで）｜結城浩 @npub1leyv...thvh #note

結城浩 / Hiroshi Yuki

『数学ガール』半額セール書籍一覧（2023年8月31日まで）｜結城浩 / Hiroshi Yuki

夏の科学・数学本フェアということで、『数学ガール』他多数が半額セールになっています！2023年8月31日ま�...

🍪おやつタイムで大失敗😖 インスタントコーヒーをお湯でとかして冷たいミルクを少し入れるはずが、考えごとしてたから何かが入れ替わって、マグに入れたコーヒーの粉に冷たいミルクをなみなみ入れてお湯を少し入れてしまった。生ぬるいミルクにコーヒーの粉が浮かんだ謎の飲み物になってしまった…まあいっか。