の作業記録

シゴタノ！を書く金曜日

9:00

おはようございます。昨日の深夜に編集者さんにintroductionっぽい原稿の粗っぽいものを提出できました。一応それはそれとして01に進んでいきます。あとは、シゴタノ！ですね。

忘れてました。今日は21:00からブックカタリストのclubhouseイベントがあるのでした。気をつけないと。

シゴタノ！:

書きます。次の日曜日で9月分は終わりですし、「デジタルノートとしてのアウトライナー」を1から３まで書いてきたので、一応４まで書いて一区切りとしましょう。

＊　＊　＊

1時間で2,000字ちょっとの原稿が書けました。

たしか今年にこのデジタルノート連載はスタートしたので、一年を一応区切りに書いていきたいところ。ということは、あと三ヶ月くらいで、４をかけたら12回分くらいですかね。それで何が書けるのかをちょっと考えておきます。

push :ポケモンからPKMへ

10:00

fragment:システム拡張の誘惑:

みずほ銀行のシステムの話を最近ニュースでよく目にするようになった。

これから「みずほ銀行」に起こる、ヤバすぎる現実…システムの「爆弾」を誰も処理できない（週刊現代） | マネー現代 | 講談社（1/4）

古いシステムが使われ続けていて、統合の際にそれを整理するのではなく、むりやりつなぐことをやってきたらしい。でもって、あまりにも肥大化し、その内部構造が複雑化してしまったことで、もはや誰も触れないシステムになっている、という話だと思う。

で、今読書管理（読書手帳）をベースにした、より大きな「システム」的管理について考えているところだが、まさに同じようなトラップにはまる可能性があることに気がついた。あるものを細かく微調整することを続けて、機能拡張を続ければ、1年後の自分には何がどうなっているのかまったくわからない「システム」ができあがってしまうだろう。

まあ、個人のシステムの場合は、あっさりそれを捨てる決断ができるわけだが、それでも対策できるのならばしておきたいのが心情である。

システム開発の原則と同じで、なるべく小さなパーツの組み合わせで作り、それぞれを個別にリファクタリングできるように整えておくようにした方がいいだろう。実装したい機能を、きちんとパーツごとに設計する、という感覚だろうか。

たとえば、Amazonから書誌情報を引っ張ってくるパーツ、それを整形するパーツ、インデックスを生成するパーツ、インデックス情報からHTMLファイルを作成するパーツ、みたいな感じ。そういう風に設計しておけば、一部が何らかの要因で動かなくなっても、対応するのは簡単になる。

というような方向性で進めていこう。とは言え、まず一番最初に小さくても「使える」ものを作るのが肝要だとは思う。

11:00

妻の昼食準備など

お昼は牛丼

そして、休憩。

13:00

TH:

若干、気が重いですが、原稿に手を付けましょう。01にようやく取りかかります。

＊　＊　＊

まずは1000字ほど書きました。文字数はもうひとつですが、文章の雰囲気は良い感じです。

15:00

prebook:

イベントで頂いた質問に答える小冊子を作ります。

まずは、頂いた質問を分類し、選別します。