Noratetsu Lab

動じないために。

タグの定義・詳細

ノートテイキングアプリDIY体験記

ノートテイキングアプリの自作(プログラミング)について振り返る記事群。
NTA-DIYを一年間やってきたことを振り返る。(2022年1月27日~)
JavaScriptの習得と活用の様子をメインに、のらてつ製デジタルノートツールのらてつ製孫の手ツールについても触れる予定。

NTA-DIY:まえがき

ということで、一年間を振り返って感じたことや学んだことを語り直したいと思います。情報としての正確さは本職のプロフェッショナルに任せるとして、プログラミング適性が大して無い人間がどこにぶつかるのかを細かく書いていこうと思っています。合間合間に前日譚として「プログラミングに無縁だった頃の自分の認識」についても整理していきます。それなりの量のシリーズになるでしょう(気力が尽きなければ)

タイトルの「○ヶ月目」は私がプログラミングを始めて○ヶ月目の時、ということです。
例:「2ヶ月目」→2022/02/27~2022/03/27の間

[この記事群を書く理由〉〉([なんでこれを書いているのか考え直す(https://noratetsu.deno.dev/article/CyV9hKh9T212P1NSmVCbc0tO)での整理)

  • 食うためでないプログラミングがもたらしてくれる自由の共有
  • 私が私の人生を忘れないための記録
  • 自分でアプリケーションを作ってもいいのかもという気持ちの肯定と惹起
  • 見切り発車したもの勝ちというメッセージ
  • 自力で何かを作ることの感動の共有

※2023/11現在 やり方を考え直したほうが良いと判断し更新は休止

Backlinks

他の「Series」カテゴリの語句

「ノートテイキングアプリDIY体験記」タグの記事一覧

2023/10/08

NTA-DIY:何をどう書いたらいいか考え直す

 ノートテイキングアプリDIY体験記の連載再開、と思って意気揚々と記事を投稿する気でいましたが(ほとんど書き終わっていましたが)、ちょっと待てよと思ったので一度立ち止まります。自分らしい文章になっていない気がしたのです。


 例によって、自分の頭の中だけで完結させていい話をわざわざ書いて投稿してしまうことにします。内容としてはどちらかというと「ノートテイキングアプリDIY体験記」ではなく「ブログの書き方ド下手問題」の方に入るべきものかもしれません。いったい誰得かというと、私得のためのものです。
 二ヶ月半ほど前にも一度立ち止まりました。その時は動機が曖昧だという問題の解決を試みました(なんでこれを書いているのか考え直す(NTA-DIY:なんでこれを書いているのか考え直す)。記事内で示した動機を並べると以下のようなものです。

  • 食うためでないプログラミングがもたらしてくれる自由の共有
  • 私が私の人生を忘れないための記録
  • 自分でアプリケーションを作ってもいいのかもという気持ちの肯定と惹起
  • 見切り発車したもの勝ちというメッセージ
  • 自力で何かを作ることの感動の共有

 もう一段階整理すると、

  • メッセージ① プログラミングは自分を自由にするものである
  • メッセージ② プログラミングは誰でも今すぐチャレンジしてよいものである
  • メッセージ③ 私の人生にはこういう日々があったのである

 という三つのメッセージに集約できるかもしれません。①②は自分以外の誰かへのメッセージで、③は未来の私へのメッセージです。

 さて、動機についてはまずまず明らかになりました。しかしそれに沿って書いてみようとした時、何かが「違う」感じがしました。動機を明らかにする以前よりはピントが合ってきた感はあるのですが、何か足りないのです。自分が読者だったとして、多分「へえ」とか「ふうん」とかは思うのですが、読んでよかった感をどこから得ればいいのかわからない感じがしました。
 文章自体は書けるのに、その文章がブログ記事に投稿されるものとしてはピンと来ない。そんな時こそ「ブログの書き方ド下手問題」の出番です。自分が書いたからといって自分に定着しているわけではありません。ヒントがあるかもと思って読み返しに行きました。
 ちょっと長くなりますが、今の自分の問題意識に関連する箇所を抜き出してみます。長いので重要なところを下線で強調します。

ブログの書き方ド下手問題①~世に訴えたいことはないのだが私は書きたい~

私が何かを書くに当たっては書き手が主人公であり続けるのではなく、読み手が主人公になれる瞬間がある文章を綴らなければ私のエネルギーは無駄になるだけなのだ。
ブログの書き方ド下手問題②~自己の言語化を意味あるものにするには~
自己の中の現象を書き表わそうとしたとき、その現象の瞬間、つまり「気づき」にフォーカスしたくなる。私の中でこれが起きたのだ、ということに力を入れて書きたくなってしまう。確かにそれを含むように書くのではあるが、その気づきというのは他人にとっては必ずしも意味のあるものにはならない。少なくとも本人ほどはそこに感動はしない。本人にとっても、本当はそれが単発で意味をなしているのではなく、そこに至る経緯がそこに意味を作り出しているからである。
自分語りに対して読み手が期待するのは、書き手の状況がその間抜けさや滑稽さまでも隠さず明らかになっていくことであり、案外「膝を抱えてぐだぐだといじけている」ようなことなのではないかと思う。気づきや決定や変化の、その手前に共感を見出すからこそそれらのターニングポイントに意味が生まれるのだろう。
ブログの書き方ド下手問題⑤~結論が出ないことを恐れない~
無理して結論めいたものを書こうとしなくてよかったのにな、と思う記事がいくつもあるのだが、結論を捻り出さないとしてその記事はどういう位置づけになっただろうか。そう考えると、多分それは「近況報告」というものだったのだろう。「○○してみた結果、~と言えそうだ」とまでいかずに「○○してみた」で止めても良かった。
ブログの書き方ド下手問題⑥~試行風景を実例にしようとしない~
そもそも私が「自分はこうすることにしたんですよ」と書きたいのは、上述したように自分のやり方の有効性を示したいからではなく、ただ単に、こういう私がここにいて、こういうことをやっているんですよと言いたいからというだけである。こういうことを考えてこういうことを始めてみました、こういうことをやったらこういう学びを得たんです、それが言いたいだけなのである。そしてへえこういう人がいるんだなと思ってもらえたらそれで良いのである。別に私のやり方は他の人の役になんか立たなくていいし(役に立てばそれはそれで嬉しいけれど)、のらてつ流の何とかが広まってほしいとも思わない(広まったらそれはそれでまあ気分は良いのであろうが)
ブログの書き方ド下手問題⑦~考えが整ったのに記事にしにくいものたち~
文章を書く時というのは、書きながら書き手自身に発見がないととてもやっていられない。自分としては既にわかりきっていることを、ただ人に読めるように翻訳するだけの作業というのは大変に苦痛なのである。書くということ自体が謎を解く探検の旅であるからこそ、私たちは何千字や何万字とかいう量の文字を拵えることができるのだと思う。
やはりここまでの回で考えてきたように、私に書けるのは「自分が困っていること」の分析または「今自分はこうしている」という近況報告くらいなのだろう
ブログの書き方ド下手問題⑧~文章にするの面倒くさい問題~
何かが不十分であった過去という経緯があり、何かを気づいたり獲得したりすることによって変化し、より良い状態に至ったという流れが文章の骨格となる。逆に言えば、そういう骨格が見出された時、そのことについて話さずにはいられなくなるとも言える。

 現状について気づいたことがいくつかあります。

  • 読み手が共感し得るポイントが明らかでない
  • Before/Afterがはっきりしていない
  • 読み手を引っ張ろうというメッセージ性が強すぎる
  • 文章を書いている間自分自身に発見がない

 むしろどうしてこれで書き続けられると思ったのか。「ブログの書き方ド下手問題」での内省はなんだったのか。頭を抱えてしまいますが、このズレが発生するのにも理由があります。別にこのシリーズ記事以外の単発記事には違和感はないのです。普段書くにあたっては、「ブログの書き方ド下手問題」での格闘はちゃんと活きています。
 この「ノートテイキングアプリDIY体験記」というシリーズは私にとって、というかこのブログに於いて、かなり特殊な位置づけになってしまっています。冒頭で整理した動機でそれが明らかになっていますが、何かしらのメッセージを誰かに送ろうとしているものなのです。「プログラミングは自分を自由にするんですよ、あなたもどうですか」「プログラミングをする時は見切り発車でやっちゃっていいんですよ、あなたもえいやとやってみてください」、といった具合です。そもそも私はそういう風に書きたくないのだということを繰り返し記していたはずなのに、どうしてそうなってしまうのか。

 やはり根本には、「プログラミングの素人なのに、プログラミングについて書いて、何か意味があるのか」という疑問があります。本音としては意味があろうがなかろうが書かねば気が済まないから書くのですが、自分の良識がそれにいちゃもんをつけています。ちゃんと読み手が得するように書きなさいよと。さしあたっては、「自分もプログラミングしてみたい!」という気分にさせることを目指したらいいんじゃないかと。それに貢献しない記述は文章を冗長にするだけだから省きなさいよと。
 なんだかおかしいことが起きている感じがバリバリします。今のところは書いていて全く楽しくないというわけではないのですが、楽しみきれていないと感じてはいます。一応の体を成した時点で終わりにしてしまうからです。そして普段の単発記事と違ってこのシリーズは体を成すのが大変なので(自分の良識の要望に応えようとしているために)、一応のラインに達した時点で「もう疲れたから投稿してしまって次に行きたい」という気分になっています。おかしい! 勝手に書いているブログなのに、恰も仕事でやらねばならないことを最低限クリアして片付けているかのようです。おかしいおかしい。

 自分が目指すべき姿勢として「読み手が主人公になれる瞬間がある文章」を書く、ということを述べました。また、今しがた自分の良識からの文句として「ちゃんと読み手が得するように書きなさい」と表現しました。これらは似ていますが、しかしおそらくはかなり違っています。
 基本に立ち返る必要があります。私にとっての基本、つまり文章を書く時の根本の目的とは、「自己の仔細な言語化を通じて他の誰かの内面の言語化に貢献する」ということですブログの書き方ド下手問題③~自分節を見つけ出す~。対象は「自己」で貫くのが正解でしょう。しかし現時点では「プログラミング」「ツール作り」を対象にしているので混乱が生じるのです。プログラミングを対象にしてしまうから、語る資格があるとかないとかいうことを考えなくてはならなくなるのです。

 いつもは「まさに自分と同じ状況にある人」とのシンクロを図って書いています。普遍的な話題なら、性質的に重なるところさえあれば職業も年齢も性別も趣味嗜好も関係なくシンクロの可能性はあるでしょう。しかし「プログラミングに悪戦苦闘している自分」のことを書くとすればシンクロする可能性のある範囲はかなり絞られてしまいます。似た性質であることに加え、更にプログラミングに挑戦してかつ悪戦苦闘している人、にしか共感が生まれないかもしれないからです。なので、文章を書く努力が無価値になることを恐れて、「まだ挑戦していない人」という、より広い範囲に向けて書こうという気持ちが生まれているわけです。
 ですが……別にいいじゃないか、という気がしてきました。シンクロする範囲は狭くて結構。というのも、私より先に進んでいる人が「そうだったなあ」と思ってくれるかもしれませんし、この先挑戦し始めた人が「あれはこういうことだったのか」と後から納得してくれるかもしれません。読んだ時点で共感はなくてもよくて、「よくわからないけど、なんか意味のありそうなことを書いている気がする」くらいの感想を持ってもらえたら御の字というものです。
 他の人が言ってくれることは私が頑張って言わなくてもいいわけで、私は私の時間と労力を、私からしか出てこないかもしれない何かを搾るために費やしたほうが良いはずです。

 そういうわけで、記事の在り方をもっと「いつもの調子」に寄せる形に改めてやり直していきたいと思います。自己満足は自己満足として本気で徹底しなくては、読み手にとっても面白くなりませんよね。

用語集へのリンク

2023/08/05

NTA-DIY:2ヶ月目④~よくわからん三銃士~

 それなりのツールを作ろうとすると、それなりに調べ物が多岐にわたることになりますが、そうなると「よくわからないあれをまた見かけた」ということをしばしば体験します。


 自分の目的を速やかに達成したいが、自分の理解が追いついていなくてちょっと避けているものがどうしてもついて回ってくる、という状態です。
 そこでちょちょっと調べて「なるほどそういう意味ねー」となれば話は早いのですが、そうならないから逃げ回って結局遭遇してということを繰り返すことになります。

 二ヶ月目のこの頃に困っていたのは主に三つの概念です。ずばり、アロー関数コールバック関数非同期処理です。JavaScriptをわかる人はこれらが如何に避けがたいものかおわかりかと思います。実際に何か作ろうとするならば、それが簡単なプログラムであっても扱わざるを得ないものたちです。
 当時困っていたもの三銃士という話なので、三つの粒度はバラバラです。理解の難易度も実際には大きく差がありますが、当時はどれも同程度に馴染み難いものでした。急に抽象度が上がったような感覚になるのです。
 数学で言えば、平方根、指数対数、三角関数、微積分、行列などの単元に入った時の感覚でしょうか。もちろんわかる人はすんなりわかるのですが、そのステップアップに失敗して数学で挫折したという人も多いでしょう。既に自分の中にある理解の組み合わせが通用せず、正面からの格闘を求められているような感覚です。
 これらについて誤りなく説明できる自信はないですし、解説は世の中にいくらでもあるのでここでは詳しく説明しませんが、混乱している人に寄り添うために自分の混乱を元に書けることを書いておきたいと思います。最初はこうだよね、というお話です。

アロー関数

 アロー関数というのは、関数の書き方の一種で、function~で定義するより簡潔な見た目をした構文です。

// 普通の関数宣言    
function add(a, b){  
  return a + b;  
}  
// アロー関数  
const add = (a, b) => a + b;  

「=>」の部分から「アロー(=矢印)関数」という名前がついています。
 アロー関数は単に「関数宣言を簡単に書けるようにした」というだけのものではなく、挙動に色々違いがあります。その違いはとても重要で、そこに躓く人も少なくないと思いますが、私の場合はそれ以前にまずこの書き方の見た目に混乱してしまいました。
 上記の例だと引数の部分に括弧がついているので辛うじて関数っぽさがなくもないですが、例えば以下のように書かれるとわけがわかりません。

const f = a => b => a + b;  

 プログラミング脳になっていないと、パッと見た限りでは「fにaを代入、と思いきや矢印がある、けどaはすぐ出てこなくてなんか急にb出てくる」みたいな見え方をします。ちなみにこれは普通の関数宣言で書くと以下のようになります。

function f(a){  
  return function(b){  
    return a + b;  
  }  
}  
console.log(f(1)(2)); // 3  

 「関数を返す関数」というのも初学者の「わけわからないポイント」のひとつですが、とりあえずfunctionの形にしてみれば、括弧なし引数の矢印矢印の連鎖よりかは意味に想像がつくことでしょう。シンプルすぎるアロー関数はかえって理解に苦労することがあります。

 で、「アロー関数ってなんなんだ」という感覚になった時、「アロー関数とは」などと検索をかけても「functionとの違い」を細かく解説されるばかりで、「なんなんだ」感はいまいち解消されなかったりします。「なんなんだ」とは思っているのですが、「なんなのか」を説明されても困るのです。(解説記事が悪いのではなく、「なんなんだ」と思って「アロー関数とは」と調べざるを得ないところに難点があります。求めているものではないものの山に突っ込んでしまうのです。)
 じゃあこれを乗り越えるにはどうしたらいいかということですが、もし私のように「パッと見た時に意味が取りにくくて困惑する」という意味で「なんなんだ」になっているのだとしたら、私に言える答えはひとつです。アロー関数を書きまくるしかありません。それまでfunctionで書いていたものをとりあえずアロー関数で書いてみる。頭の理解をどうにかするのではなく、目が慣れるまで書く。ルートやインテグラルやシグマに目が慣れるまで問題集を解くのと同じです。
 見た目に困惑しなくなった頃に、functionとの違いが気になり始めると思います。そうなったら本格的にアロー関数について勉強することになるでしょう。
 ちなみに私が「おおよそアロー関数をわかった」と思えるようになったのは五月末あたりです(functionとの違いも含めて理解したのがそのくらいということです)。ツールを作る上で、理解しなくてもどうにかなるものの理解は後回しにしてまず作る、というスタンスでやっていたのもあって、なんだかんだ三ヶ月くらい曖昧なままでいたことになります。

コールバック関数

 次はコールバック関数です。コールバック関数とは引数として渡される関数のことです。以下のような関数があった時、引数funcに入れている関数fugaがコールバック関数になります。

function hoge(func){  
  const q = confirm('実行しますか?');  
  if(q) func();  
}  
function fuga(){  
   alert('Hello world!');  
}  
hoge(fuga);  

 ちなみにこの場合hogeの方は高階関数と言うようですが、今のところ「高階関数」というワードがすごく重要と思ったことはありません。
 で、コールバック関数の定義としてはこうなのですが、問題は「コールバック関数の引数に値が渡される」という状況です。上記の例ではfuncに入る関数には何も渡されていないので話が簡単に見えるかと思いますが、値を渡して使う場合の方が多いのではないかと思います。
 さて少し話が枝分かれしますが、コールバック関数に最初に直面するタイミングというのは、自分で高階関数を書こうとする時ではなく、コールバック関数を引数とするメソッドを使う必要が生じた時だろうと思います。具体的にはArray.prototype.find()などです。配列の中から条件に合うデータを探し出す時にコールバック関数が必須になるのです。
 簡単な日記データからデータを取り出す例を書いてみると、たとえばこんな感じです。

const data = [  
  { date: '2023-08-02', text: 'すごく暑かった。' },  
  { date: '2023-08-03', text: '夜にアイス食べた。' },  
  { date: '2023-08-04', text: '今日も暑かった。' },  
]  
const today = data.find((obj) => obj.date === '2023-08-04'); // 2023-08-04のデータを返す  
const soHot = data.filter((obj) => obj.text.includes('暑かった')); // 2023-08-02と2023-08-04のデータを含む配列を返す  

 実際にはDateオブジェクトを使って今日の日付を指定したりしますが、とりあえずfindとfilterに注目してもらいたいので直に値を入れました。
 コールバックわからんちんな人もこの例を見るとfindやfilterの括弧の中にどう書けばいいのかなんとなくわかるのではないかと思います。これを「コールバック関数を引数に渡している」感が出るように書くと例えばこうなります。

function callback1(obj){  
   return obj.date === '2023-08-04';  
}  
const today = data.find(callback1);  
  
function callback2(obj){  
  return obj.text.includes('暑かった');  
}  
const soHot = data.filter(callback2);  

 アロー関数で一気に書いてしまっていたのを別途整理したわけですが、逆に意味がわからなくなったかもしれません。コールバック関数として渡した関数がfindやfilterメソッドの中でどう使われるのか想像できないからでしょう。(ちなみに「obj」という文字列の部分は別に何でも好きに決めていいのですが、何でもいいのだというのは関数を分けて書いてみると明らかでしょう。)
 findなどのメソッドが具体的にどういうコードで出来ているかわかりませんが、メソッドの中で「引数に渡したコールバック関数に配列の各要素を渡し、その返り値がtrueかfalseかを判定して条件分岐」という処理が行われているはずです。
 各メソッドは、引数として渡される関数(コールバック関数)の引数にどんなものをどの順番で渡して処理するかが決まっています。Array.prototype.findなら、配列arrのi番目を判定するとして、引数の一つ目はarr[i]、二つ目はi、三つ目はarrです。つまり、それらを私たちはコールバック関数の中で活用することができるということです。そして各メソッドは私たちが渡したコールバック関数の引数に順番にこれらを入れて実行してみて、trueなら次の処理を実行、というようなことをしていくわけです。if(callback(arr[i], i, arr)){}みたいなことです(あくまでイメージです)

 しかし最初はそのことがよくわかっていませんでした。「data.find((obj) => obj.date === '2023-08-04');」みたいな文は「こう書くもの」としておまじないのように書いており、これが「関数を渡している」のだという感覚があまりありませんでした。いや、わかってみればこれはどう見たって関数を渡していますし、関数じゃなきゃなんなんだよという話なのですが、関数に関数を渡すという概念がわかっていなかった時は関数を渡した結果それがどうなるのか想像できなかったので、「これがなんなのかよくわからないが、とりあえずこう書く」という理解でfindやfilterを使っていたわけです。この時点でアロー関数自体馴染んでいなかったというのは手前で書いた通りです。
 しばらくして、自分で関数を書いていて「任意の関数をその中で実行させたい」と思う場面が来ました。その時当たり前に「引数として関数を渡して、それを実行すればいいんだろう」と思いました。そして試して期待通りに動いた時、はたと「コールバック関数を必要とするメソッドってつまりこれじゃん」と気がつきました。なぜその瞬間までわからなかったのかわかりません。その瞬間が訪れたのは確か三月末のことです。
 たまたま自分で同じ形のものを作って初めて「あれってこれじゃん」と気づいて理解が一気に進んだというのは、他のことでもいくつかあります。メソッドの説明を読んだだけではよくわからなかったのが、後からまさにその挙動を欲するタイミングができた時に、自分でわざわざ複雑なコードを作ってから「もっと簡単にならないのか?」と思って「あのメソッドってこれじゃん!」と気づいたりします。説明を読んだだけではすんなり理解できないがゆえに多分遠回りをしているのですが、わかった時には具体性をもってわかっているので(まさに目の前に実例があるわけです)、もうそれ以後はポンポン使えるということになります。

非同期処理

 最後は非同期処理です。なんというか、名前からして意味がよくわかりません。「非同期」ということは「同期していない」ということだというのはわかりますが、そもそも「同期」している処理って何? という話です。Aの存在を認識していないのに急に「非Aとは」と言われてもなんのこっちゃです。
 一言で言うと、「手前のものが終わるのを待って次に行く」のが同期処理で、「手前のものが終わるのを待たないで(よそに投げておいて)次のことを始めてしまう」のが非同期処理です(多分)。「同期」という単語とプログラム的な意味内容が脳内でいまいちバシッとリンクしませんでしたが、とりあえずそういうことだと理解しておかねばなりません。ファイルの読込など規模の大きい処理が必要な時、それが終わるのを待ってから次となるとリソースがもったいないので、他の処理を進めておいてから規模の大きい処理をやる、というような形にする必要が生じるわけです。
 とても難易度が高い概念なのですが、ツールを作るとなるとファイルの読込というのが不可避で、そうなると非同期処理を使うことになります。というのは、ファイルの内容を取得するのに使うfetch APIが非同期処理の形をしているからです。非同期的に処理したいとか考えるまでもなく、そういう形式になっているのでその形を理解しなければ使えないのです。
 一口に非同期処理と言っても、非同期処理にする書き方はいくつかあるので非同期処理とはこの形という話にはなりませんが、とりあえずファイル読込に使うfetch()が必要になるので、それについて書いていきます。

fetch('./test.txt')  
.then(response => response.text())  
.then(text => {  
  // 引数textには「test.txt」の中身の文字列が入っている  
  console.log(text);  
})  
  
fetch('./data.json')  
.then(response => response.json())  
.then(json => {  
  // 引数jsonには「data.json」の中身がオブジェクトまたは配列に変換されて入っている  
  console.log(json);  
})  

 なんじゃこりゃあ。「.then」って何? responseには一体何が入っていて何が処理されてるの? というようなことが、初学者にはわかりません。同期処理か非同期処理かという話より、構文の見た目の異質さに戸惑ってしまいます。これまた数学の微積分のごとく、それまでになかった概念と直面した瞬間です。習ってないのでわからないのは当然です。
 これを正しく理解するにはPromiseチェーンというのがわかる必要があります。そんなにべらぼうに難解な話ではないのですが、何しろアロー関数の意味すらあやふやな状態でやっているのです。説明を理解するのはちょっと大変です。全部理解するまで頑張っていたらツール作りが進みません。
 なので私の脳みそを非同期処理にしてしまいましょう。Promiseチェーンの理解という規模の大きい処理は後回しにして、まず目下のツール作りを先に進めてしまうのです。ツール作りの合間にキューが空いたらPromiseチェーンに取り組むことにします。二ヶ月目のこの時点では、とりあえずおまじないを書けるようになれば良しとしました。
 肝心なのは、自分が書いた処理がfetchでデータを読み込んでから行われる必要があるということです。

fetch('./data.json')  
.then(response => response.json())  
.then(json => {  
  // 自分の作った処理がここで実行される必要がある  
  hoge(json);  
  fuga(json);  
})  

 そうなると、ツールで実行する処理というのは関数で綺麗に整理しておかないと大変です。このthenの中にずらーっと書いていってもまあ動きますが、きちんとまとめておいてthenの中に関数をいくつかぽんと置いて実行すると見通しが良くなると感じます。それまではべたべた直に書いて上から順に実行していた箇所が多かったわけですが、これを機に関数の使い方が少し変わっていきました。
 ちなみにPromiseチェーンを(ある程度)理解したのは結構後のことです。自分用のデジタルノートアプリを作るだけなら、fetchでローカルファイルの中身やAPIにアクセスした結果を取ってこれればそれで大体事足りました。

 その後あれこれ試みる中でこの三つに苦手意識を感じなくなった時に、JavaScriptでのプログラミングはぐっと自由さを増したように思います。苦手意識がなくなるのは割と唐突で、ふと「あれ、わかったぞ」という感覚がありました。最初は苦手でも、その周辺をうろうろしていればそのうちどうにかなるものですね。
  

2023/07/29

NTA-DIY:糸口②~環境を整えよう~

 糸口①NTA-DIY:糸口①~結局何をどうしたら動くのさ~では「WebブラウザをGUIとしたアプリケーション」って何、という話をしました。まずHTML・CSS・JavaScriptを使ったツール作りという営みの意味を明らかにしておく必要があろうかと思ったので、その話からスタートしたわけです。
 今度は、具体的にどういうアプリケーションを使ってプログラムを作れば良いかという話が必要だと思うので、ちょっとだけ書いておきます。


 と言っても、自分が実際に使っているものしか知りませんので、網羅的でもなければ最善の保証もありません。でもより良いものを探すために検索する取っ掛かりにはなるでしょう。
 前回同様、記事内で解説しようというのではなく、何を調べればいいかのガイドとなるものを目指しています。

メモ帳とWebブラウザがあればコードは動く

 JavaScriptを書いて動かすために必要なものとして本当に最低限のものは、「メモ帳」と「Webブラウザ」だけです。誰のPCでも最初から備わっていますね。要するに、Webブラウザが読んで動かせる形式で書いた文字列があればいいだけなので、メモ帳で書いてもいいのです。
 メモ帳でもいいのですが、実際にコーディングするには、入力の補助がないと大変やりづらいです。メモ帳はコードが間違っていても指摘してくれませんし、色分けもしてくれないですし、サジェストもしてくれません。コーディングに特化したテキストエディタならそういうことをやってくれるので、とても入力が楽になります。

コードエディタをインストールしよう

 では、コーディングに特化したテキストエディタとは何でしょうか。
 有名なものはいくつかあるようですが、私が使っているのは「VSCode(Visual Studio Code)」です。他のコードエディタは使ったことがないので比較して良さを言うことはできませんが、とりあえず困ることは何もなく、「VSCodeを使っとけば間違いない」という記事もひとつふたつではなく見かけたので、ひとまずVSCodeをインストールしておいて損はないかと思います。
 他のものが気になるようなら、適当に「コードエディタ おすすめ」とかで検索するだけで候補は把握できます。
 ちなみに、VSCode(というかMicrosoft製品)の入力支援・自動補完システムのことは「インテリセンス IntelliSense」と言います。使っていて何か気になることがあれば調べてみると理解が深まると思います。

ファイルはどう作る?

 コードを書くツールについてはそれで良いとして、次は具体的にどう書いてどう保存すればいいかについて整理してみます。
 ここではあくまでHTML・CSS・JavaScriptのセットでのプログラミングの話をしますので、他の言語については各々お調べになってください。大抵は実行環境(コードを書いて作ったファイルをプログラムとして実際に動かすための環境)の構築が必要になると思います。WindowsではPythonも自分でインストールしなければなりません。その点JavaScriptはWebブラウザがあればいいので、プログラミング脳が全く育っていなくても手探りで始めることが容易かと思います。
 さて、先程からHTML・CSS・JavaScriptの三点セットで話をしていますが、「.html」「.css」「.js」の三種類のファイルを用意する方法と、CSSとJavaScriptの両方または一方をhtmlファイルの中で埋め込む形で書いてしまう方法とがあります。スタイル情報とスクリプトはそれぞれHTMLのstyleタグとscriptタグで記述することになりますが、外部ファイルのインポートもできますし、直にタグ内に書くこともできるわけです。
 直に書くとインデントが余計に深くなり、記述が長くなると把握も難しくなるので、最終的には外部ファイルに書くのが基本になるでしょうが、ちょっとしたプログラムを作るだけならhtmlファイルひとつだけにまとめてしまうのもよいでしょう。
 糸口①NTA-DIY:糸口①~結局何をどうしたら動くのさ~に載せたコードはstyleタグとscriptタグに直に書いている例になります。それぞれ別途「style.css」「main.js」というファイルに書いてインポートする形にするとすれば、htmlファイルの記述は以下のようになります。(cssファイルはlinkタグでインポートすることになります。)
https://gist.github.com/nora-tetsu/08c8e410c200f539376c89b692452156

ちょっとしたコードを試したい時

 HTMLとは関係ないようなコードを試してみたいこともあるでしょう。例えば数字の計算をしてみたいとか、乱数を作ってみたいとか、メソッドを試して意味を確認したいとか、そういうものです。
 その試行結果を、例えばHTMLのspanタグの中に表示して確認するというようなことも可能ですが、ただ足し算してみたいだけでそんなトリッキーなことをするとなったらちょっと面倒です(練習のために敢えてやるのもありですが)。console.log()を使うにしても、エディタで書いたものをWebブラウザで開いてコンソールで確認する、というのは若干手間が多い感じがします。VSCodeのデバッグ機能を使う……とかいうことができる人は今これを読んではいないでしょう。
 もうちょっとこう、さっと書いてさっと試したいという感じがします。
 そういう時には「Webブラウザのデベロッパーツールのコンソールに直に書いて実行する(Enterを押す)」とか「Web上のプレイグラウンドサービスを使う」という手があります。VSCodeなどのエディタは脇に置いておいて、Webブラウザだけで事足ります。

 デベロッパーツールは、Chromeなら右上の設定アイコン→「その他のツール」→「デベロッパーツール」、Firefoxなら多分右上のアイコン→「開発者ツール」→「開発者ツールを表示」という手順で開くことができます。デベロッパーツールでやれることは多岐にわたるので、詳しくは検索なさってみてください。
 コンソールというのは、現在開いているページで走っているスクリプトによる情報が表示される場で、コードの挙動を確かめることができます。「console.log(hoge)」などのConsoleオブジェクトのメソッドを用いることによって処理中の情報を書き出しておくほか、エラーが発生した時には自動でエラー箇所と理由が表示されるなどします。しかしコンソールというのは「情報を確認できる」だけではなく、そこにコードを書いて実行してしまうことも可能なのです。

画像

 ありがちなうっかりミスとしては、入力してEnterキーでコードを実行してしまうので、サジェストされた候補を選択しようとしたり改行しようとしたりした時に意図せず途中で実行してエラーを出してしまうことが多々発生します。私は多々発生させました。直に打ち込まないでコードエディタで書いたコードをコピペしてEnterの方が安全ではあります。

 もうひとつの選択肢のプレイグラウンドとは、オンラインでコードを試して遊ぶことができるサービスのことです(文脈によって他の概念を指す場合もあると思います)。様々な言語についてそういう場が作られており、JavaScriptについては「JavaScript playground」で検索すると色々と出てきます。
 JavaScriptの場合はどのサービスでもHTMLとCSSもセットで試すことができるようになっています。コードを書いて、左上などにある「Run」をクリックすればすぐに結果が出ます。Runを押すまでもなくリアルタイムに反映してくれるものもあります。基本的に全て英語ですが、コードの挙動を確認するだけならメニューの意味などを全て理解しなくとも支障はないと思いますので、身構えなくて大丈夫です。

Playgroundで試行する

 JavaScriptのプレイグラウンドには色々あるようですが、それぞれちょっとだけ触ってみた限りでは、PlayCodeというサービスが使いやすいかなと思いました。入力補助があり、コードの実行結果がリアルタイムに更新されます。
 いずれのサイトも、そのサイトにコードを保存するとなるとユーザー登録が必要ですが、ただ試すだけなら登録は要りません。試したコードをコピペして他に保管しておいて、挙動を試したい時だけ貼り付けて確認するというのもよいでしょう。
 最終的にはローカルファイルにコードを書き、htmlファイルを開いて実行することになりますが、ツールの体を成す前の試行錯誤はWeb上のPlaygroundでやってもいいと思います。htmlとcssとjsを並べて表示でき、手早く結果を確認できるので、挙動を知るのにはとても効率が良いです。

メソッドはどこで調べる?

 環境が整ったはいいですが、何を入力すればいいのかと戸惑うかもしれません。JavaScriptにどんなメソッドが実装されているのか、初心者にはわからないからです。
 ごく基本的な文法は適宜初学者向けのサイトなりアプリケーションなり本なりで勉強してもらうとしても、JavaScriptが備えているオブジェクトとそのメソッドというのはそれだけでは到底カバーされません。網羅的に解説している何かの力を借りる必要があります。辞書が要るのです。
 私がいつも参照しているのはMDN Web DocsというMozillaの公式ウェブサイトです。メソッド名で検索すればこのサイトの記事が上位に出てくるので、わざわざトップページから探していかなくても記事にアクセスすることは簡単です。
 しかし本当の初学者の段階ではちょっと記述が難しすぎるので、その場合には日本のプログラマーが書いた記事を頼りにするとよいでしょう。というか、自分のやりたいことがどんなメソッドで解決できるのかがわからないだろうと思うので、最初は「JavaScript ○○するには」みたいな検索をせざるを得ないと思います。
 情報量の乏しいしょうもないようなサイトもしばしば検索結果の上位に出てきたりしますが、逆にそのくらい薄い方が最初の最初は読みやすかったりもします。内容としては同じことを言っていても言葉遣いの違いでわかったりわからなかったりするのが初学者なので、ネットを利用して色々見てみるのがよいと思います。もちろん、評判の良い書籍を探すのが一番かと思います。
 いずれにしても、たまたま出会った記述にその都度こだわって格闘しすぎるよりは、切り口の異なる記述をあれこれ見た方が早いと個人的には思います。書き手は各々全力を尽くしていたとしても、自分と相性がマッチしなければ読解は難しくなりますし、そもそも内容が絶対正しいとも限らないのです。

 登場したキーワードを並べておきます。

  • コードエディタ
    • VSCode
      • インテリセンス
  • 実行環境
  • デベロッパーツール
    • コンソール
      • console.log()
  • プレイグラウンド
    • PlayCode
  • MDN Web Docs

 今回は以上です。
 

2023/07/23

NTA-DIY:なんでこれを書いているのか考え直す

 自分のシリーズ記事について自問自答してもいいだろう、そしてそれを記事にしてしまってもいいだろう、と思ってちょっと書くことにします。


 一般的に見てこの種の自問自答は他人にはあまり面白くないものと思いますが、まあ、自分のために書くものなので私が助かれば良いのです。

 さて、このシリーズはノートテイキングアプリケーションのDIY(NTA-DIY)体験記として書いているわけですが、本当のところ何がしたくて書いているのか、というのが微妙に曖昧だったなと感じています。
 無目的に書いているというよりは、自分の中に動機があるはずだがその動機を自分で正しく捕まえられていない、という状態でした。やりたいことがあって書いているのは確かなのに、それをピンポイントで押さえられていなかったのです。

 まえがきNTA-DIY:まえがきを今読み返してもなんとなく漠然としています。学びを書き残したいという気持ちは強くありましたが、その学びとは何なのかははっきりしていませんでした。
 プログラミングの力がほぼゼロだった状態から前に進んでいって今に至るその過程を言語化したい、というところまでは明確なのですが、あったことをただ並べているだけでそれが「伝わる」状態になるかというと、どうも違う感じがします。

 食っていけるような技術を得たわけでもないのに、プログラミングで食っている人がそこらじゅうにいる中でわざわざ体験を書く意味とは何なのか。

食うためでないプログラミング

 まず「食うためではないプログラミング」の意義について考えたいということがあります。
 今の人々の様子からすると、プログラミングで食っているプログラマー、本職は別にあるけど自作ツールを公開するくらいのことはしているサンデープログラマー、全くプログラミングをしない人、のいずれかに分かれているように思われます。つまり、「ちょっとプログラムを書く」という層が見当たらないのです。
 もちろん、そういうライトな層は発信できることが乏しいのでわざわざ発信しない場合が多いでしょうし、発信してもスキルの劣る素人の文章は話題に上りにくいという事情もあるでしょう。しかし体感として、実際に「ちょっとプログラムを書く」という層は薄いだろうと思っています。積極的にプログラミングの話をしている人以外の人々は、全然やらない、全くわからない、ということがほとんどのように見えます。
 食うためではないプログラミングをするということはつまり、プログラミングの勉強がそのまま稼ぎに繋がるわけではないということですから、プログラミングの勉強に手間がかかることと天秤にかけてもなおプラスになるイメージは持ちにくい、ということはあると思います。私もそう感じていた面があったので、ずっと手を付けないできました。プログラミングを覚えたところで、それで何をするのよ、という疑問があったわけです。
 プログラミングに無縁だった当時の自分に、今の自分が如何に自由かを伝えたい。そのために、食うためではないプログラミングにどういう意義があるのかを言葉にする必要があります。実際には過去の自分には伝えようがないので、自分と似た人間の誰か一人にでも届けばいいなという思いです。

情熱の記録

 そのように「プログラミングと無縁な自分」と「プログラミングをちょっとだけできる自分」のビフォーアフターを表現したいというのは動機として大きな要素なのですが、しかしそれだけではありません。それだけなら具体的に時系列を追って自分の体験を書き記す必要はあまりないでしょうし、直接心に訴えるような文章を目指して書いたほうが早いように思えます。
 わざわざ細かく書いているのは、読み手に何事かを伝えたいということとは別に、自分のために書く必要を感じているからです。
 自分が生きた証をこの世に残したい、ということにはさして興味がないのですが、自分で振り返って「いろいろ考えていろいろやったはずだけど、なんだったかなあ」と思う羽目になることには非常に大きな恐怖を感じています。自分の人生がどこかに飛んでいってしまったように感じるからです。全てを記録しておかねばということではないのですが、いっときでも情熱を傾けていたはずのことは、そのまま飛んでいってしまっては困ります。困る割に記憶力が弱くて全然定着せずにすぐ飛んでいってしまうので、どうにか残しておかなくてはなりません。
 書き残すにあたって、普通はそういう時こそ日記の出番かと思いますが、日記を「後から読み返して楽しいくらいの記述」程度にしっかりしたレベルで継続するのが私には困難なので、自分以外の読み手の存在を借りる必要があります。人が読むと思うとちゃんと書かなければなりませんし、またそう思えさえすればするすると言葉が生まれていくのです。

励ましというよりは

 ここまでは、前々から考えていたことでした。ですがこの二点はどうも噛み合っていません。今書いてきたように、それぞれ別の動機であって、そのままではうまく絡み合わないのだろうと思います。
 それゆえに、「書けるのはこんなもんだけど、これでいいんだろか」という気持ちがいつもつきまとっていました。自分に書けることのレベルは決まっていますし身の丈に合ったものを書くしかありませんが、読み手に手渡そうとしているものが曖昧なのはよろしくありません。
 噛み合わせるにはどうしたらいいかと考えて動機を整理した時、上述の二点がまず浮かんだわけですが、「異なる二つの動機が離れたところにあるからうまくいかないのだ」という結論ですんなり納得できたわけではありません。というのも、それとはまた別に何かあって記事を書こうとしているはずだ、という気持ちがあったからです。鎹(かすがい)となる何かがあるに違いないのに自分でそれを捕まえられていないことが問題なのではないかと思いました。では、それは何か。
 これまでの記事をお読みいただいている方はご存知と思いますが、初心者初心者と言う割に、いきなり「ツール」と呼べそうなものを作ってきました。コードはぐちゃぐちゃでへんてこですが、それなりの機能は備えているものです。プログラミングが既にわかる人からすれば大した処理ではないことは明らかなものですが、全くやったことがない人から見ると「えっ、すごい」と感じる可能性もあるのではと想像します。
 その意識の乖離を埋めたいという思いがまずあります。ただ、これまで伝えようとして何か違うなと感じていたところでもあるのですが、「ちょっとできるようになればこんなにも自由になるんですよ」というメッセージが自分の本当の思いなのかというと、どうも少しズレているような気がします。
 なぜかといえば、私がツールを作るにあたって用いているものは、「ちょっとしたプログラミングのスキル」だけではないからです。なので私と同じ程度のスキルを身につけてもらったとして、それによってすぐツールを作れることを保証することはできません。「JavaScriptの勉強をたった一週間やるだけでこんなこともできるんですよ」という話をするとすれば、それはちょっと詐欺臭い感じがします。
 できるとかできないとか、そういう観点での励ましをしたいわけではないのかもしれません。励ましになればそれはそれで大変嬉しいのですが、「あなたもできるよ!」という話をしたいというよりは、「既存のツールにもやもやしているくらいなら自分で作ったほうがいいのかも」という気持ちを後押ししたいと感じています。

自分にできることは「選ぶ」だけではない

 立派なプログラマーが作った立派なアプリケーションが多様になるにつれ、「その中から選ぶ」ということがますます当たり前になっています。色々なものがあるので、その中のどれかひとつくらいは自分に合うような気がしてしまいます。今はまだなくても、待っていれば誰かが自分にぴったり合うものを作ってくれそうな気もします。親切で気の利いた開発者が世の中にたくさん存在しているのを知っていながら、敢えて手間をかけて自作する、なんていうことはもう考えにくいのではないでしょうか。会社で使うアプリケーションが定められていれば尚の事です。
 しかし、これまでの実感からして、本当に待っていれば自分にぴったりのアプリケーションを誰かが作ってくれるかというと、正直に言ってそれは望み薄だろうと感じています。ビジネスとして成り立つためには、リリースするアプリケーションは汎用的なものにならざるを得ず、個々人の痒いところに手を届かせるには限界があります。今は有志がプラグインを開発してそれを拝借するという形が当たり前になりつつありますが、どれだけ多様性が増していっても、自分が欲しい機能を必ず誰かが作ってくれるわけではありません。どうしたって、「これがあればなあ」「この機能のここがこうなっていればなあ」というちょっとした不満を抱えながら我慢して使わざるを得ないのです。(奇跡的に自分の要望を完璧に満たしてもらえることもあり得るにはあり得ます。)
 そうなった時に、「自分にはどうせ作れないし」と悄気げるのではなく、「やってやろうじゃねえか、ええ?」と思っていいのだぞ、ということが私の言いたいことの核にあるような気がしてきました。例えばアウトライナーがほしいと思ったら、まだそんなスキルはなくても、作ろうと思っていいわけです。作ろうと思えばいずれ作れます。「どうせ」とか言っている場合ではありません。作るったら作るのです。
(念の為言い添えると、何も「不満を言ってないで自分で作れ」と迫っているわけではありません。作るも作らないも自由なのであって、作るためのコストが収支としてマイナスになるなら挑まない方が賢明ですし、自力で作らないでいるのは悪だとかいうことではないです。)

いきなり作れ

 で、自分で作ってやろうとなった時に、「まずJavaScriptの知識を一通りインストールして…」と座学を決め込む必要はありません。もちろん基本的な文法については学ばなければ何もできませんが、解説書の最初から最後までまず読み通してから、などと考え始めると自由を得るまでが遠すぎます。そもそもそんな簡単に「一通り」勉強できるようなものではないので、如何に早く見切り発車してしまうかが大事だと個人的には思います。何事も子どもの習得が早いのは、全貌なんか気にせず知識を得次第に行動するからでしょう。
 また、初心者のうちに「他の人のコードを参考にしよう」とは考えないほうが良いです。工夫が凝らされた実践的なコードというのは初学者には到底読めません。積み木遊びしかできないのにタワーマンションの図面を解読しようとするようなものです。頑張っても「全然わからない」という気持ちに覆われるだけでしょう。読んでないで作るのです。おみくじを作る、じゃんけんを作る、トランプゲームを作る、メモアプリを作る、タスク管理ツールを作る、やれることは色々あります。どんどん作るのです。
 そして「じゃあこんなこともできるのかな?」と何か思いつけば、もうそこに「これまでこの世に存在しなかったツール」が誕生するのです。それを作れる人は無限にいますが、誰も作らなかったからこの世に存在していなかったツールを、他ならぬ自分の手で作り出したことになります。別にそれは世界初のひらめきというわけではないでしょうが(それはそう)、少なくとも自分の視界を作っている世界の中では見当たらなかったものを自分で作り出せたなら、それは結構嬉しいことで、そして結構すごいことです。
 というようなことを、私は記事を通して伝えたいのだと思います。

行きあたりばったりな紀行文を目指す

 誰かの旅の話を聞くとします。事前に綿密な計画を立て入念に準備を整えて決行に至った旅の話も興味深いですが、行きあたりばったりで(あるいは想像とあまりに違っていたために)全てが偶然の出会いとして語られるような旅の話はわくわくします。冒険譚のような感じがするからでしょう。
 実際の旅を行きあたりばったりにやるのはリスクが高すぎるのでそうそう真似できませんが、もっと身近なことを十分な予備知識なしにやってみることはできます。例えばオモコロの「やってみた」系の記事は、たまにシェアされてきたのを読んでみるといつも楽しさと驚きに満ちています(昔のニコ動もそういうのが面白かった)。いずれも本気でやっているので準備は入念になさっていることが多いですが、予備知識があるはずもないものに挑むわけなので、やっている本人が一番びっくり、みたいなことがたくさんあります。
 何かしら「やってみたらこうなった」という要素があり、そこに何らかの面白みが伴っているとわくわく感が生まれるだろうと思います。実際、自分がプログラムを書いている時というのは、(サンデープログラマーはきっとみんなそうですが、)ふと思いついたことを試しにやってみてその結果に感動したり心躍らせたりしているわけです。その気分を共有しなくては書いた甲斐がありません。オモコロのような高度な愉快さを提供できるわけではありませんが、兎にも角にも目指してみなくては話は始まらないでしょう。
 現状は「記録」あるいは「説明」といった様相なので、もう少し切り口を工夫した方が良いのかもしれません。とはいえ説明的に伝えなくてはならない要素が多いので、切り口を変えて改めて語り直すということもあり得ると思います。もしくは、説明的な部分を註にするのもありかもしれません。ブログを書いていて註をつけたことがなかったので今の今まで思いついていませんでしたが、文脈から外れる要素はそうやって話の外で補えばスッキリさせられそうです。

 やっているうちにだんだん雰囲気が変わってくるとか、同じ話を繰り返したいだけ繰り返すとか、そういうのを防いでしまう必要はないわけですから、しっくり来る表現を探しながらふらふら書き進んでいきたいと思います。
 

2023/07/19

NTA-DIY:2ヶ月目③~付箋ツールを自作してみる-後編-~

 前回の続きです。付箋ツールに色々な機能を搭載していく話になります。

2023/07/16

NTA-DIY:2ヶ月目②~付箋ツールを自作してみる-前編-~

 久しぶりの更新になってしまいました。二ヶ月目の話の続きです。
 これまで作ってきたのは、カード風メモツールにしろアウトライナーにしろ、内容の表示を自動で整えるタイプのものでした。決まった形式の見た目になって整然と並んでいくという形です。きっちり整列させられるのはデジタルのとても良いところですが、逆に自由に配置したいということもあります。きちんと並んでいてほしいものはきちんと並んでいてほしいわけですが、きちんと並んでいる必要のないものがきちんと並んでしまうのはあまり嬉しくなかったりするのです。
 ということで、付箋ツールを作ることにしました。ポストイットを壁に自由に貼り付けるように、情報を書いた四角い領域を自由に移動させられるようにするということです。


 JavaScriptのことがわからなかった時、要素を自由に位置づけるということは、かなり難易度の高そうな、プログラマーにしかできない魔法のように思えていました。どうやったら実現し得るものなのか全然イメージできていなかったからです。位置の移動だけなら良いとして、それを保存しておく術がわからなかったのです。
 しかしちょっとJavaScriptを齧って考えてみると、「styleのtopとleftの値を保存すればいいだけだ」ということがわかりました。localStorageに保存するデータにtopとleftのキーを作り、styleの値を保存しておいて、リロード時にhoge.style.topにその値を指定すれば要素の位置は復元されるわけです。
 文章で書いてもわかりにくいのでその部分の単純なコードを書いてみると、例えば以下のように書くことができます。保存・読込部分の最低限の処理なのでこれだけでは全然ツールにはなっていませんが、ともかく位置の保存と読込は簡単にできるということがわかりました。
https://gist.github.com/nora-tetsu/51a587d0045f79d6ad2ee59b3fbdbdb8

 このli要素をドラッグできるようにして、CSSを整えれば、付箋ツールっぽいものができていくということになります(ul要素とli要素で作ることにこだわる必要は特にありません)。何をすればいいのかがイメージできるようになったので、うきうきとツール作りに着手しました。

 付箋ツールらしさには、まず「ドラッグして位置を自由に動かせること」「付箋のサイズを自由に伸縮させられること」の二つが必要でしょう。サイズ変更に関しては必須ではないですが、そうできた方が柔軟で嬉しい感じがします。逆に敢えて余計な自由を封じた方がいい場合もあります。
 これらを実現するにはマウスイベントを色々設定する必要があります。結構大変です。正直二ヶ月目のこの時点ではちょっと厳しかったので、ライブラリの力を借りることにしました。「jQuery UI」というものです。(導入方法については検索していただくとして、ここでは割愛します。)
 2023年の今の時代でjQuery UIを使うのが最善手かというとそれはわからないところですが、素人でも良い感じの機能を比較的簡単に作れるようになるので、JavaScriptに挑戦したい人は知っておいて損はないと思います。私個人はjQuery UIをマウスイベントの実装にしか使ったことがないので全容を語ることはできませんが、今でも自力で実装するのが難しいような処理をまかなってくれるのでありがたい存在です。
 しかしそれでも楽勝というわけではありません。プログラミング初心者の身にはちょっと難しく感じられたのが、オプションの設定です。例えば「Draggable」の解説を見てみましょう。

 ありがたいことに日本語リファレンスがあるので言葉の壁はないですが、オプション、メソッド、イベントの各タブを見た時に、つまるところどうしたらいいのかがパッとわかりませんでした。解説が不親切ということではなくて、自分が「初心者用の懇切丁寧なガイドがない記述」を理解できる域にまだ到達していなかったということです。
 この時点では引数にオブジェクトやコールバック関数を渡すという経験がなかったので、内部的に何が行われるのかが想像できず、少し飲み込みが悪かったなという記憶があります。設定項目が複数あるうちの一部だけを記述して渡すというのはどういうことなのだろうとか、コールバック関数の引数に入るものというのはどこから来るんだろうとか、今となっては謎の疑問に囲まれていました。できる人に尋ねても「質問の意味がわからない」と言われるタイプの疑問でしょう。
 初学者はそういう疑問をたくさん抱えながら進むことになるものと思います。疑問の持ち方とそれを表現する言い回しが千差万別なので、序盤のつまずきなのにもかかわらず先輩に尋ねて解決するのは大変に難しいものです。コードを書きまくっているうちにいずれ唐突に霧が晴れる時が来るので、その瞬間の訪れを信じてもがくしかないと私は思っています。
 そんなわけで、それまで自分で書いていたより複雑さが一段上のコードと格闘することになったのですが、幸いこのレファレンスは実例のコードを見ることができるので、この説明はこういう意味なのだろうかというのを探っていくことが容易です。ドラッグやドロップなどのイベントは作っていて楽しいこともあり、JavaScriptを理解するための教材としても役に立ったなと思います。

 エラーを出しながらも手探りでどうにかDraggableやResizableを設定することができました。そうすると随分付箋ツールらしくなりました。結構な格闘があったにもかかわらず、できてみると「簡単じゃないか」という気分になり、それじゃあと調子に乗って色々な機能を搭載することにしました。
 本題はここからという感じですが、記事一本としてはちょっと長くなってしまうのでここまでを前編とします。
 画像がないとちょっとイメージが湧かないと思いますので、当時作ったもののスクリーンショットを最後に一枚貼っておきます。

画像

(書いてある内容は初学者の勉強中のメモなのでおかしいところを見つけてもスルーしてください。)
 

2023/04/21

NTA-DIY:糸口①~結局何をどうしたら動くのさ~

 このシリーズ記事では私の体験を記録として残すべくあれこれ書いていますが、読んでいても結局何をしたら真似できるのかわからんぞ、というご感想もあろうかと思いますので、私の環境を共有する記事もちょっと書いておこうと思います。


 以前から「WebブラウザをGUIとしたアプリケーションを作った」という話をずっとしているわけですが、それってそもそもどうやるのと思われた方もいらっしゃるかもしれません。何をどう調べたら情報が出てくるかもあまりよくわからない感じがします。
 挑戦しようとした時に一番困ることは、まさにこの「何を調べたらいいのかがわからない」ということだと思います。何を調べたらいいのかがわかるなら調べればいいのです。なので、私のスタンスとしては、知識そのものを提供するのではなく、何を調べたらいいのかの手掛かりになることを目指して書くことにします。知識の理解の手助けは私自身初学者ゆえ何も責任を持てませんので、学習そのものは書籍や学習サービス、インターネット検索などでどうにか頑張ってください。
 なお親切な書籍やサービスはたくさんあるかと思いますが、私自身はインターネットの力で強引に進んできましたので、これがいいよというのを具体的に薦めることはできません。その上どういうワードで何を調べたのかも曖昧です。なので、全く良い導き手ではないことを先に侘びておきます。ですが「自分のペースでのんびりやりたい人」の良き友人でありたいと思っています。

 本題に戻りましょう。WebブラウザをGUIとしたアプリケーションを自作するというのは、超簡単に言うと「自前のHTMLをブラウザで開く」ということです。GUIとは、コマンドプロンプト的ではない、マウスなどによって操作可能で人間にわかりやすいインターフェースのことです(「アプリケーション」と言って思い浮かぶものがつまりGUIです)
 その「自前のHTML」にてCSSやJavaScriptを呼び出して機能を使えるようにしているわけです。最もシンプルな方法は、拡張子htmlのファイルに然るべき書き方であれこれ書いて、ファイルをダブルクリックするなどして開くというものです。
 htmlファイルの開き方はいくつかあります。列挙すると例えば以下のような選択肢です。言っている意味がわからないところもあるかもしれませんが、最初から全部理解する必要はありません。

  1. htmlファイルをそのままWebブラウザで開く
  2. ローカルサーバーを立て、htmlファイルを呼び出してWebブラウザで開く
  3. Electronのアプリケーションとしてhtmlファイルを開く(※Webブラウザではない)

 どうしてこのような複雑な選択肢が生まれてしまうのかというと、Webブラウザにはローカルファイルの扱いに於いてセキュリティのための制約があるからです。1は制約がそのままで、2、3はその制約を回避しています。

 ノートテイキングアプリケーションを作る場合、データというのはローカルファイルとして存在して、アプリケーション上で編集するためにそのファイルの中身を呼び出し、書き込んで保存する、という形になってほしいものと思います(私はそうです)。持って回った言い方になりましたが、ファイルを編集するタイプのデスクトップアプリケーションは普通そうなっています。
 しかし、Webブラウザ上で実行するスクリプトによってローカルファイルを編集できるようになっていては危険極まりないので、Webブラウザでは通常そういうことができないようになっているわけです。ローカルファイルの内容を読み取るだけなら簡単な方法があるのですが、書き込むことはどう頑張ってもできません(ローカルサーバーを使わない限り)
 GUI自体を作ることができる言語を使えばこの問題は起こりませんが、GUIを作るというのはおそらくプログラミング初心者にはかなりハードルが高いので、セキュリティの問題の複雑さとの戦いがあってもなお「HTMLを書いてWebブラウザで開く」という方式を採用しています。
 日頃、WebブラウザをGUIとして利用したアプリケーションについて語る中で、ローカルサーバーがどうこうとかElectronがどうこうとかいう話をしばしば登場させていますが、それはこういう事情によるものです。

 最初の最初は普通にWebブラウザで開いて動かすものを作るのが簡単です。ローカルファイルへの保存は直にはできませんが、ブラウザ内には保存領域があるので(localStorage)、データが失われないように保存すること自体は可能です。なのでローカルサーバーだのElectronだのということがわからなくてもアプリケーションとして成り立つものは作ることができます。
 やがて「ローカルファイルに保存できたらいいのに!」という気持ちが高まったらローカルサーバーやElectronの勉強をするということになるでしょう。ちなみに、Webサイトの運営をしたことがある人はサーバーというものに馴染みがあるかもしれませんが、私は全く無縁だったためサーバーという概念の理解が難しく、先にElectronを習得することになりました。今はElectronをやめてローカルサーバーでやっています。どちらが簡単ということはなく、それぞれ違う種類の難しさがあると思います。

 ここまでの話と補足情報をまとめてざっくり整理しておきます。

  • WebブラウザをGUIとした自作アプリケーションとは、ここではhtmlファイルを書いてWebブラウザで開いて動かすものを指している。
  • Webブラウザは基本的にローカルファイルを編集できないようになっている。
    • 代わりにWebブラウザにはlocalStorageという保存領域がある。
    • Webブラウザからローカルファイルを編集するならローカルサーバーを立てる必要がある。
    • WebブラウザではなくElectronというフレームワークを使えばローカルファイルを自由に編集できる。
      • ElectronはWebブラウザではなくデスクトップアプリケーションだが、Chromium(Google ChromeやEdgeなどモダンなブラウザの核みたいもの)を使ってレンダリングしているので、感触としてはWebブラウザとほぼ同じ。

 すぐ必要になるので検索すると良いかもしれないキーワードは以下の通り。 

  • HTML
  • CSS
  • JavaScript
  • localStorage
  • ブラウザのデベロッパーツール

 いつかは調べることになるけど焦らなくていいキーワードが以下の通り。

  • ローカルサーバー
  • Electron
  • Chromium
  • Node.js

 
 それでは最後に、htmlファイルを適当な名前で適当なフォルダに作ってみましょう(どこでもいいです)
 そのhtmlファイルを「メモ帳」か他のテキストエディタで開いて、以下をコピペしてください。簡単なスクリプトを書いてあります。
https://gist.github.com/nora-tetsu/b650bb9b9ae2f89d1f278ebacd1769ca

 Webブラウザでこのhtmlファイルを開いてみましょう。こういう画面になると思います。(フォントは全然違ったものになると思います。)

画像

 テキストエリアに何かしら入力して追加ボタンをクリックすると、書いたものが下に表示されるはずです。入力と追加を繰り返すとどんどん下に追加されます。
 追加されたものをダブルクリックしてみましょう。すると削除していいか聞かれます。OKで記述は削除されます。
 これは簡単な例ですが、こういう処理の組み合わせによってアプリケーションを作っていくことになります。localStorageへの保存処理を作ってドラッグアンドドロップ処理や編集機能などを加えればToDoリストなどとして使えるものになるでしょう。

 こんな感じでツールづくりのヒントを書いていこうかと思います。自分自身が初学者だから書けることというのも何かしらあるのではと思っています。先生ではなく隣の席の「ちょっと予習進んでるやつ」くらいの立ち位置のつもりです。一連のシリーズ記事の主目的は体験の文章化なのでこちらは余力があればになりますが、よろしければ参考になさってください。
 なお、これは本シリーズに於いて「プログラミングの話が書いてあるのに参考にできない」という穴を埋めるためのものであり、正確な知識や網羅的な情報を提供することを目指したものではありません。独力で調べられる方は自力でお調べくださいますようお願い致します。
 

2023/04/10

NTA-DIY:2ヶ月目①~アウトライナーを自作してみる~

 二ヶ月目の話に入っていきます。JavaScriptの勉強を開始して丸一ヶ月でアウトライナーの自作に挑戦しました。


 NTA-DIY:1ヶ月目⑩~初めてのノートテイキングアプリDIY~で書きましたが、一ヶ月が経つまでに多少独自性のあるメモアプリ的なものを自作するところまでたどり着きました。
 発想を具現化できる取っ掛かりをちょっと掴んだことで、色々なアイデアが思い浮かぶようになりました。少し前まで「JavaScriptって何が嬉しいの?」と思っていたNTA-DIY:前日譚②~JavaScriptを書けると何が嬉しいの?~わけですが、「超嬉しいじゃん!」という心境です。
 そんな中でふと、アイコンをクリックするとul要素が display:none; になるようにすればアウトラインの形は作れるな、と思い至ったことで、試しに作ってみようと考えました。最初から既存のアウトライナーを代替するものを作ろうと意気込んでいたとかではなく、思いついたから試さずにいられないという気持ちで取り組んでみたわけです。
 とはいえ、ただアウトライナー機能を再現しただけでは面白くないので、既存のアウトライナーに対して抱えているもやもやを解決するアイデアを実践できたら尚良いと考えました。こうして軽快な足取りで無謀な挑戦に踏み出してしまいました。

 私が普段アウトライナーを使う中でうまくいっていなかったことのひとつが、「引用をメモする」ということでした。例えば、太宰治が『正義と微笑』の中で書いた「真にカルチベートされた人間になれ」という一文をアウトライナーに書いておきたいとします。これが『正義と微笑』の読書メモの中なら話は難しくありません。「太宰治著『正義と微笑』」というような項目の下にペーストすればそれで終わりです。引用だとわかるように括弧で囲むか「> 」などを頭に入れるかすれば混乱は生じないでしょう。
 しかし引用は必ずしも読書メモのひとつとして書くわけではありません。WebページやTwitterなんかから取り出すこともあります。そうなると、然るべき親項目というのが無いパターンが発生します。形式的に「引用」とかいう項目の下位に「Twitter」などと作ってその下に貼り付けるというようなこともあり得なくはないですが、無意味に階層が深くなりますし、デイリーの項目を使っているならその中に書きたいこともあります。他のトピックの中に存在していてほしいこともあります。なんにせよ引用部分を親項目に囚われずに自由に移動させられたらその方が良いです。
 では、「真にカルチベートされた人間になれ」という項目の下に「太宰治」「『正義と微笑』」といった情報を入れてしまえばよいでしょうか。それはひとつの解決策で、それでいいと思えばそれでいいだろうと思います。ただ個人的には、それらの情報は「下位項目」なのかと考えた時に、ちょっと違和感を覚えてしまうところがあります。それらの情報が、他の「下位項目らしい下位項目」とフラットに並んでしまうことへの違和感です。これはごく個人的な感覚の問題に過ぎないことなので、その構造はおかしいとか言いたいわけではありません。単に私個人の納得いかなさを解消するために、私は自分で工夫しなければならないということです。
 もうひとつの解決策として、ノート機能を使って書くということがあります。これはとても現実的な方法です。それでも良いには良いのですが、しかし個人的にはすっかり納得できるわけでもありません。ノートを表示していると情報量が無闇に増えて煩わしく、畳むと今度はノート部分にどういう種類の情報を入れたのかがわからなくなるという問題があるのです。
 いっそのこと、全部項目に突っ込んで「「真にカルチベートされた人間になれ」(太宰治『正義と微笑』)」などとする手もあります。出典部分が短ければそれほど違和感はありません。ただ、どこかのWebページの一節みたいなことになると同梱はちょっと苦しい感じがします。普通にあり得るやり方ですが、ベストではないように感じてしまいます。

 要するに、ノードにメタデータを自由に設定できて、且つ、それらのメタデータの存在がひと目でわかるようにしたかったのです。
 それができるアウトライナーはひとつもないのでしょうか。いえ、少し前にメタデータの設定が可能なアウトライナーが誕生していました。Dave Winer氏のDrummerです。おそらくですが、メタデータを利用したスクリプトを自分で書けばメタデータの内容をアウトライン上に可視化することも可能だろうと思います。多分スクリプトによって可能になることは無数にあり、Drummerには果てしのない可能性を感じます。
 よって、自分の要求を満たすにあたり、Drummerをバリバリ使い倒すという選択肢もありえます。しかし当時はごく簡単なコードしか書けませんでしたし、Drummer用のメソッドの仕様を見ても何がなんだかわからなくて何もできませんでした。Drummerのデザインや操作感の癖に馴染むのが容易でないということもあり、とりあえずDrummerそのものを自在に活用するという道は諦めました。
 じゃあ、自分で作るしかないよね、ということになるわけです。

 ついでに、一般的なアウトライナーへの不満として「1カラムしかない」ということがあったので、その解決も試みます。画面の高さより離れた位置にあるノードを参照するにはいちいちスクロールしなければならない煩わしさをどうにかしたかったのです。なお、今なら例えばRemNoteは複数ファイルの同時編集が可能です。

 当時作ったもののスクリーンショットを貼っておきます。

画像

 実際にアウトライナーもどきを作ってみると、まあ一筋縄ではいきませんでした。
 アウトライナーっぽい動き(開閉やインデント)の再現だけなら、クリックイベントとキーボードイベントさえわかれば可能なので、それほど大変ではありません。「おお、『っぽい』ぞ」という感動は割と早く得ることができました。
 しかし、「編集したデータの管理」と「ドラッグアンドドロップ処理」を実装するのにはかなり頭を悩ませました。アウトライン操作というのは実装すると色々なイベントを実行することになるわけですが、どのタイミングでどうやってデータを更新するのかをきちんと考えなくてはなりません。
 おそらく最もシンプルなのは、DOMツリー自体をデータと見なして、それを丸ごとデータとして保存することです。アウトライン部分が入ったul要素のinnerHTMLをlocalStorageに突っ込むということです。確か最初はそうしていました。リロード時にはそのままul要素のinnerHTMLに代入し、中身のli要素などに各種イベントリスナーを設定する処理をしました。必ずしも処理が単純になるわけではありませんが、データの形式を考えずに済むという利点はあります。階層構造をどう管理したらいいのか当時はよくわかっていなかったのです。
 データの管理を複雑にしたのは、「メタデータがある」ということと「2カラムである」ということです。データの形式としてHTMLを使うとなると、メタデータの管理のためにはHTMLのカスタム属性を駆使する必要があります。そして2カラムあると片方のカラムの更新をもう一方に反映させなければなりません。一言で言うととにかく無謀だったのですが、しかしそれがモチベーションになっているわけなので、なんとか頑張って実現するしかありません。
 そこに更にドラッグアンドドロップが加わります。ドラッグアンドドロップ処理というのはなんとも複雑です。ドロップ時の処理が判別できるようにドラッグ中にスタイルを変更するようにしたのですが、そうなると「dragstart」「dragover」「dragleave」「drop」の四つのイベントをセットすることになりました。
 そして階層構造になっているもののドラッグアンドドロップなので、親要素を子要素の中にドロップするということを禁じる必要もあります。あっちもこっちも初めて知った概念の連続で、数限りないエラーと格闘する羽目になってしまいました。
 このブログは体験談として書いているので具体的なコードの説明はここではしませんが(別の機会にする可能性はあります)、とにかく沢山の試行をして無数のエラーを出しました。どれだけ失敗してもリスクはゼロなので気楽なものです。コードは最終的に1100行くらいになりました。
 一応形にはなりましたが、とても「出来の良いツール」とは言えず、処理の信用ならなさが自分でわかっているのでしっかり実用したわけでもありません。しかし「こういうものが作りたい」と思いつきさえすればある程度は脳内を再現できるという手応えを感じました。当時このツールを作ったことについて「気分としてはメタルキングを倒した感じ」と表現しましたが、今振り返ってもそうだなと思います。

 当時作ったものを全面リファクタリングしたサンプルがTwoColumnOutlinerにあります(例によってPC用です)。なお上記のスクリーンショットは当時のもので、今回のサンプルとはあちこち違っています。

 以下は「2ヶ月目」の話ではない余談です。
 コードの説明はしないと先述しましたが、サンプルはなるべくまともなコードに改めた上で公開すると決めているので、今回も頑張って書き直しました。
 これがおそろしく大変でした。「エラーの恐怖がつきまとうが一応動く」という状態から「エラーの不安なく動き、メンテナンスとカスタマイズが比較的容易である」という状態に自分なりに書き換えたわけですが、データの管理やDOM生成はどうするのが良いのか一から考え直すことになり、設計するのに想像以上に時間がかかってしまいました。
 結局、サンプル版では当初搭載した機能の半分くらいしか実装していません。いずれもこうすれば実装できるという見通しはついていますが、このツールを今後自分が使っていく予定は今のところないので、費やすに値する時間と労力の兼ね合いから再現は途中までにしました。当初作ろうとしたものは、内部処理をまともな形にするとなるとかなりの手間を生じるほど複雑だったということです。
 しかし、これをリファクタリングしようとしたことで、それまで知らなかったメソッドや思いつかなかったアイデアを様々獲得しました。この連載を書くことで読み手に何かプラスがあるかわかりませんが、私自身の得るものが非常に大きいので、この先も勝手に頑張っていこうと思います。(1ヶ月目を終えてからかなり間が空きましたが、単純にコーディングに苦労していただけでモチベーションの低下があったわけではないのでした)
 

2023/03/30

NTA-DIY:前日譚④~VBScriptの感動~

 ずっと前にVBScriptというWindows用のプログラミング言語をちょっと齧ったことがありました。中高生向けにプログラミングの考え方を説いた本を手にとったことがあり、その中でこの言語の説明があったのが出会いのきっかけです。


 齧ったと言っても、一噛みで歯のほうが折れたという感じでプログラミングの勉強の履歴としてはカウントしていません。(VBAもちょっとだけやりましたが、必要に迫られる環境になかったので本当にちょっとだけです。)

 実現したいことでググって、コードを拝借して弄れそうなところを弄る、という感じでtxtファイルやxlsxファイルの編集はしたことがありました。
 先日Excelの話を書きましたがNTA-DIY:前日譚③~Excelの拡張としてのデジタルDIY~、「打ち込む」と「見て使う」のうち「入力する」方のUIを新たに作る試みだったと言えます。専用のアプリケーション以外からデータを弄ることができるということにはかなりの驚きがありました。コンピュータを使っている、という感触を覚えました。
 しかしこの言語について全然理解はしていないので、調べて出てくること以外の挙動は何も作れません。基礎をやらずに当てずっぽうにコピペしていても何も身につかないのです。そりゃそう。

 VBScriptをやっていてもう一つ驚いたのが、テキストエディタでコードを書いて、それをvbsという拡張子で保存し、そのファイルをダブルクリックすればそれだけでコードが走るということです。当時は本当に仰天しました。書いて、ダブルクリック。環境構築のための努力は何も要りません。このパソコンにはそういうものが最初から備わっているのか、と感嘆しました。自分はパソコンのことを何もわかっちゃいないのだと思ったことを覚えています。
 まあ、今でもコマンドプロンプトなんかはわからないに等しいです。辛うじてNode.jsとGitに関するコマンドは使えるようになりましたが、コマンドというものの可能性がどこまで広がっているのか見当もつきません。自分が勉強さえすれば何も新たに導入せずとも実現可能なこと、というのが実はたくさんあるわけですね。

 もう一度VBScriptを勉強し直してもいいかなとも思っています。VBScriptでは「画面」を作れないのでノートテイキングアプリをつくることは難しいですが、逆に画面が要らない自動処理などはわざわざ他の言語を使わなくてもいいわけです。(ちなみにWindowsはPythonもインストールが必要です。)
 多分、他の言語(特にJavaScriptやPythonなど)をやっていれば、VBScriptの習得には苦労しないだろうと思います。
 とはいえ開発が終了して久しい言語であり、今ならPowerShellの方を勉強するのがきっと現実的で、どうせならVBScriptだけでなくPowerShellも覚えられたらより良いだろうとは思います。今のところ、PowerShellについては全くなんにもわからない状態です。日頃普通に生活していてPowerShellというワードを見かけたことがほぼないので、あまり関心を向ける機会がなく、存在を一応認識していながらもノータッチでここまで来ています。

 ちなみにどうしてVBScriptをやめてしまったかというと、どこでどう勉強すればいいのかその時はわからなかったのと、コードが動くという面白さを感じる一方で「役に立つ」ものは作れなかったからです。VBScriptではGUIを作れないというのが、プログラミング思考の弱い当時の私には致命的にミスマッチでした。何が何でも習得しようという熱意が生まれなかったのです。
 

2023/03/13

NTA-DIY:余談①~ScrapboxとGitの貢献~

 最初の一ヶ月について十本かけて書いてきました。(もう一本書くつもりでいたので締め的なことを書きませんでしたが、一ヶ月目については前回で終わりです。)
 一年も前のことですが、比較的解像度高く書けたのではないかと思います。もう少し細かく書きたい気持ちもありましたが、費やせるリソースはこれが限界と思いちょっと駆け足になりました。


 一年前のことを書けるのは、簡単ながら記録を残していたからです。何がわからなくて何に感動したのか、Scrapboxの個人プロジェクト(非公開)に書き込んでいました。
 こう書くとその都度きちんと整理していたかのようですが、実際には「○○って~~ってこと?」とか「なるほどね!!」とかいう感じの記述があるだけです。後々のために残そうとかいう意識はなく、何もしていなかったかのような気分になるのを防ぐために書いていったらそれなりの記録になった感じです。
 ページの粒度としては、「次のステージに進んだ」と感じたらページを改めていき、期間にして1ページあたり数日から一週間程度の記録になっています。実際のページ名を並べるとこんな感じです。

  • TS/JS日誌vol.1 基本~配列・関数・オブジェクト
  • TS/JS日誌vol.2 ブックマークレット実作
  • TS/JS日誌vol.3 「TypeScriptで学ぶJavaScript入門」復習/ブックマークレット進化
  • TS/JS日誌vol.4 ScrapboxのPageMenu作成
  • TS/JS日誌vol.5 bookmarks.htmlの自動生成実装&cards.html開発
  • TS/JS日誌vol.6 card.htmlのlocalStorage化、メモアプリに進化
  • TS/JS日誌vol.7 outline.html開発

 これらのページの中に、日付を書き、参照したURLと疑問や感想、作ったコードへのリンクを日付の下に箇条書きでずらっと並べていきます。実のところ八割がたURLの列挙で、日記的な記述はそんなにはありませんが、何に取り組んでいたかがわかりさえすればその時どうだったかはある程度思い出せます。また、いちいち細かく書いていないことによって、逆に「わざわざ書いた」部分の困り具合や感動具合、その他正直な心境が目立ちました。これは思わぬ収穫です。この一連に関してはズボラ日記で正解でした。
 見返すために書いたのではなく書くために書いていたものなので、今回このシリーズ記事を書くにあたって見直すまで、一年近くこれらのページを開くことはなかったように思います。たまたま記事を書こうと思ったので役に立つ日が来ました。
 Scrapboxでなければこうはできなかった、というようなものではなく、Obsidianでもアウトライナーでもtxtファイルでもなんでもいいのですが、Scrapboxは気軽に書ける雰囲気があり、他のことにも使っているのでScrapboxを選択しました。

 じゃあずっとこれを書いていたのかというと、実際は上記の七ページだけです。ちょうど一ヶ月分しか時系列に沿った日記はありません。JavaScriptの習得スピードが速くなるといちいちメモしていられず、また疑問点も比較的すぐ解決できるようになり、ノートを取る必要性が薄くなっていきました。書くために書いていたので、書く必要がなくなると途絶えてしまったわけです。
 代わりに、一ヶ月が過ぎた頃からはツール開発を始めていたので、書いたコードは頻繁にGitでコミットするようになりました。勉強したことは実際に動かすコードとして反映され、その記録がGitに全て残っています。コードを書き、また別に日誌を書く、となると二度手間になってしまいますが、Gitを使えばその時点の状態が記録されていくので、コードをこまめにコミットするだけで日誌を書いているのとおおよそ同じことになります。
 ただ、漫然とコミットしているとそのコミットが前回のコミットとの間でどう違うのかひと目ではわからず、資料として使いづらくなります。そこでコード内のコメントやコミットメッセージを工夫する必要がありますが、これがまた結構難しいです。いずれもその時点の文脈に基づいて書き残すことになりますが、後から難点になるのが、知識・スキルの状態の変化です。

 知識が乏しく経験が浅い時点で書いたメモは、その時の感覚で「こう書けばわかるはず」と思っているのですが、もっと先に進んでから戻ってくると何のことを言っているのかびっくりするほどわかりません。書き方自体が下手だったのも大きいと思いますが、能力不足で的確な表現ができないことによって、結局コードを細かく見ないと何がなんだかわからない記録になってしまいました。その時点ですごく頑張って記録をつけても、言葉にする労力があまり活きない可能性があるのです。
 このことを解決する術はわかりません。まあ、プログラミングを勉強し始めた最初期しか起こらないこととも思うので、「最初に学ぶ言語の学習記録はどんなに頑張っても読めるものにならない」と思った方がいいのかもしれません。Gitのコミットは如何にも「後から確認できるようにするための記録」然としているので、あまり意味をなさない記述が気になってしまいましたが、最初の一ヶ月にScrapboxに書いていたもののように、「見返すために書いたのではなく書くために書いた」と思って見れば十分な記録だと思えます。他の人に読んでもらうものではないので、何かしら残っていればそれでいいでしょう。
 その意味で、うまく記録を作る力がなくとも、「そのもの」を残しておけるGitというのは本当に素晴らしい仕組みです。見たままを撮れる写真ですら写真の撮り方の上手い下手が後々問題になりますが、Gitのコミットログはどこからでも見れる3Dモデルを全ての段階で残しておけるようなものです。威力を遺憾なく発揮できるのはプレーンテキストの記録に限られはしますが、今やっていることを言語化すること自体が困難な状況の中で「とりあえずそのまま残す」が可能というのは大変ありがたいことです。(うまくやれていないものを前にして素朴に喜んでいられるのは趣味の独学者の特権ですね。)

 そんな感じで、ScrapboxとGitに残した記録を元に、一年間の書き起こしに取り組んでいます。一ヶ月以上かけてやっと一ヶ月目が終わったところですが、二ヶ月目以降はもう少しサクサクいけると思います。
 

管理人

アイコン画像

のらてつ Noratetsu

キーワード

このブログを検索

検索

ブログ アーカイブ

2025
2024
2023
2022
2021