2026年3月28日から手書きのノートをつけ始めて6月8日(明日)で一冊が終わる。今回のエントリは、その2ヶ月ちょっとの記録のふり返りと感想。

PCに入力した記録の場合、ふり返りは検索やフィルタを駆使して目的のものを探しだすのも簡単でスグ。あとで整理してまとめるには便利だ。

それに比べると手書きのノートはめっちゃ不便。

最初のページから最終ページまで、1ページずつ記入する。どこに何を書いたかなんて覚えてない。保証されているのは、唯一

「最初のページから最後のページまで順番に並んでいる」

ということだけ。

もちろん、付箋やタブなんかを使って、リニアに書かれてるものを効率よく利用することもできなくはない、と思う。けど、それならPCの出番。

手書きのノートを、ざっくり頭っからページをめくっていくと、雑多な記録の羅列が現われる。

駅ネットで新幹線の予約に悶絶してたり、ポケモンGOの対人戦で右往左往してたり、WEB本棚のローカル版についての問い合わせ対応してたり、ActivityPub実装のバグ修正してたり、ミニ五徳を探して買ってたり、ワクチン打ってたり、ブログのCMSの修正してたり、DELLのノパソがバッテリまわりでいよいよ終了しそうだったり、メバチマグロでハンバーグを作ってたり、電子書籍制作がらみでツールを作ってたりetc.etc.

仕事、生活、ゲーム、健康、料理などなど、思いついたまま書かれていて、なんじゃこれ、というものがたくさんある…というか「なんじゃこれ」がほとんど。

ただ、それぞれが微妙に繋っていて

「マグロのあらを買ってたら/後日にレシピがあって/何回めの食事になって」ということがバラで書かれていてもページ順に並んで繋がってくる。

そんなひとつずつで、いちいち「あ、そうだった、この時スクリプトのサブルーチンに修正いれたんだった」とか思い出して、それと関連してユーザーさんの他のリクエストを思い出して、その頃そういえば…とノートに書かれていないこともだらだら思い出すのは老人特有の現象かもしれない。

先日もちらっと紹介した

「ノートはタブレットよりテスト得点が2割増！立命館大学と「ノートとタブレットへの筆記における記憶効果の比較」の共同研究を実施」

https://www.kokuyo.com/news/release/20240731st/

という記事もあって、覚えてる、思い出せることが増えたような気がする。脳ミソに定着してくれるんだろうか。

フラシーボかもしれないけど、これならボケ防止になると思う。

そんなごたくはともかく、手書きで埋めた手帳をあとから眺めるのが楽しい。

ほんとは、文字とイラストをテキトーに混ぜて記入した方が覚えもいいんだけど、絵の方はもう少し大きく描いておきたいので、文字用とお絵描き用で分けることにした。

↑ 絵も文字もごちゃっと入れると小学生の夏休みの宿題「絵日記」みたいで面白いんだけどねー

次のノートは同じようなリングノートでも、罫線の入ってない無地のものにしてみるかな。

---

[06/11 08:24:49]

今さら、このブログに「ハッシュタグ」っぽい機能追加。

以前のブログでは、カテゴリだけでやっていて、「思いつき」レベルでテキトーな単語をカテゴリ登録。

当然というかカテゴリがカオス。内部的にはカテゴリの種別を仕込んで状況に応じて表示のON/OFFをしてたんだけど、手軽にカテゴリを追加できるようにしたことがごちゃごちゃする原因、DBにゴミが増える原因。

なので、今のブログではカテゴリ登録はSQLを作って流すという面倒くさいやりかたにした。

ただ、そうすると、今の大雑把なカテゴリだけだと不足する。

そのために「検索」をつけてるんだけど、いちいち検索窓に単語を入れるひと手間が自分でも面倒くさくなったんで、エントリ本文に「#」と「単語」があったら、それを検索リンクにするようにした。

という「なんちゃってハッシュタグ」

その時々でハマってることをハッシュタグ化して使い勝手をみてみる。

#手書きノート ←いまだとこれ。正規表現でひっかけてリンクにしてるだけでも、クリックだけでフィルタリングできるのはラクチンだなあ。

[更新]2026-06-11 08:28:58

みけさんが亡くなった。

2023/6/6 15:00 27歳

（写真は6/5早朝、ベッドに飛び乗ってきたところを撮影）

今まで本当にたくさん、言い尽くせないほどたくさん、本当にありがとう。

これからゆっくり休んでください。

2023/6/10

一之江の城東動物霊園で荼毘にふしてもらってきた。

2008/2/7に23歳で亡くなったホームズ

2010/1/4に12歳で亡くなったちー

と同じ霊園。

[更新]2024-04-30 07:53:20

perlは本当にスゲー。こんなのないかな、あるかな、と思ったら、ほとんどすでにCPANに登録されている。ほかの lightweight language の状況は知らないので比較できないけど、perlがあればほとんど用が足りてしまうんじゃないか。

てことで、QRコードの生成。

創作文芸見本誌会場HappyReadingのスマホ版を作ったことだし、スマートフォンで見てもらえるように、誘導したい、というのが目的。スマートフォンでちまちまURLを入力するのはうっとーしーんで、QRコードの出番だろう、と。

レンタルサーバーのlolipopには GD モジュールと一部の関連モジュールはインストールされているらしい。ただ、ここで肝心の、QRコードがインストールされていないので、CPANからもってきた。

CPAN http://search.cpan.org/~kwitknr/GD-Barcode-1.15/

↑これをダウンロードして解凍展開。中を見ると、何かをコンパイルするワケでもなく、ただ所定のディレクトリにコピーしてるだけの pure perl モジュール。そのままlolipopにFTPでアップロードしたら、問題なく使えた。

use GD::Barcode::QRcode；
binmode STDOUT；
print qq{Content-type: image/png\n\n}；
print GD::Barcode::QRcode->new(STRING，
    {Ecc=>M， Version=>10， ModuleSize=>2})->plot->png；

コードは、これだけ。

STRINGの部分にURLとかテキストを入れる。日本語もOKだけど、検索してみると、ガラケーはSHIFT JIS なので、文字コードを SHIFT JIS にしていることが多い。

これで、QRコードの画像 png を出力してくれるので、img タグに、このスクリプトのURLを書いておけばいい。ちょっと調べたのがQRコードの仕様。

ECC というは、エラー修復レベル。

アウトドアなど汚れ・破損が激しそうなところで使う場合には Hレベル(修復30%）、などなど修復できるレベルがあるので、それを指定する。

ModuleSize というのは、文字通りセルサイズ。

ひとつひとつのセルのサイズを指定できる。

Version・型番というのはセル構成＝セル数。

１～40まであって、大きいほど記録する文字数が増える。

て、ウチみたいな素人ヨタ話のブログを見るより、開発者の一次情報を確認しましょう。

QRコードドットコム

画像を生成して表示するのに、ほんの少し時間がかかるので、サイトではajaxを使ってスクリプトを呼び出すようにした。情報としては、URLとサークル名、本のタイトル。

スマホのQRコードで読み取って、URLに飛ぶとその本のページが開く。おお、これは便利だ。便利なはずだ。きっと。だがしかし。

QRコードの活用例として、流通の現場で商品の確認とか、製造の現場での商品トレースとか、バス停で時刻表とか、有効に活用されている。たとえば、WEBへ誘導するのに、チラシや名刺にQRコードがプリントされていたら便利。だけど、サイト上にQRコードを表示して、さてそれってどうなの？PCでサイトを見ていて、そのページをスマートフォンでも見てみたい、というリクエストがそんなにあるとは思えない。

QRコードが使えるのでとりあえずつけてみました感が漂う。

WEBサイト上にQRコードが表示してあって、こいつは便利だぜ、待ってたぜ、という事例があったら、ぜひ教えてください。

[更新]2012-10-02 11:24:26

って、素人判断だけど。

今日初めての、Industar-22 50mm F3.5。

予想以上でびっくり。見た目はちゃっちいチープなレンズなんだけど。

Zorki-4 Industar-22 CENTURIA:ISO200

今日は絶好の晴天だし、葛飾菖蒲祭りだし、ヨメとぶらぶら地元水元公園に行ってパシャパシャ撮りまくる。

ttp://www.holeinthewall.jp/~butch/zakki/camera.pl?id=82

こってり浮かび上がる色ノリと、シャキパキしたピントにぞわぞわっと。いや好みの問題だけなんだろうけど、これは、わたし的に神認定銘玉。しばらくはこのレンズで行くか。

それもそうだが、いつ行っても水元公園は「楽しいぞ、ゴルァッ」オーラに満ち溢れていて、普段から緩い顔がさらに緩くなってしまうなあ。

[更新]2026-02-02 08:40:39

データベース、というか、SQL文、というか、postgresql というか…手ごわいなぁ。まだまだよくわからんですよ。

重複を除いて並べ替えたい、というだけのことがよくわからんのだ。

メモ

$sql = "select * from (select distinct on (title) * from $blTABLE) as temp where read=’t’ order by $order_by offset $pos limit $view"；

タイトルの重複を除いて、既読本並べ替える。というのだけど、postgresql の場合、distinct の効率はよくない、らしい。スピードが落ちるらしいんで調べて group by がいいらしいんだけど、どうやって使うのか。

おまけに、上のSQL文って副問い合わせとやら。一度select文でデータを全部なめた結果に対してさらにselectして並べ替え…selectを2回も発行してるんだけど、こういうのも効率が悪い、らしい。

うううむ。ルールとやらで別テーブルを作っておくか、とも思ったんだけど、それもまたどうだろ、と。

難しいです。

[更新]2026-02-04 10:29:31