NTA-DIYレポートとは?

NTA-DIY(Note-taking applicationのDIYの意)の体験談の月間レポート。ノートテイキングアプリDIY体験記を「体験記」から「レポート」に改めたもの。

記事としてまとめて公開するのではなく、あれこれ見直しながら手を入れ続けて少しずつ埋めていく形にする。ひと通り書いた月には✅をつけるが、その後も加筆修正の可能性がある。

横→にスクロールします。

2022年2月(1ヶ月目)✅2022年3月(2ヶ月目)✅2024年1月(24ヶ月目)

月間テーマ

  • JavaScriptの基本的な文法を知る

  • 乱数を使ってミニゲームを作る

  • DOMを理解する

  • データのビュワーを作る

月間テーマ

  • 実用的なツールを作ってみる

  • アウトライナーの挙動を再現する

月間テーマ

  • DenoのFreshに慣れる(≒React、Preactに慣れる)

作ったもの

  • 二桁×二桁計算ドリルほか、alertを使ったミニゲーム

  • 指定した年月日について各情報(曜日、年間の残り日数、閏年かどうか、干支は何か等)を取得する関数

  • Scrapboxに保存する系ブックマークレット

  • ScrapboxのCSSを切り替えるUserScript

  • Bookmark Viewer

  • Card Memo

作ったもの

作ったもの

  • Deno Deployでテスト用プロジェクトをデプロイ

悪戦苦闘ポイント

  • hoge += 2のような+=などの書き方

  • ifの条件文で「等しい」のつもりで=にして代入にしがち

  • for文

  • do...while

  • HTML要素の文字列の取得

    • DOMについて学ぶ教材と出会わなかった(探さなかった)ため
  • ○○オブジェクトがよくわからない

    • DateやMathなどを使えるようになってもその正体がわからない
  • functionを小さい単位で作れない(より大きく括りたくなってしまう)

悪戦苦闘ポイント

  • ツールに自動保存を組み込むと、誤った処理があった時にその結果も自動で保存されてしまう罠

    • 処理によってはデータが破壊される

    • 手動保存や「元に戻す」の実装でリスク回避の必要

  • 非同期処理

    • コードの書き方がこれまでやってきたことと違うので見た目に混乱

    • 何がどうなっているのかはわからないので書き方だけ覚えた

  • コールバック関数

    • 配列のfilterメソッドで多用

    • よくわからないので書き方だけ覚えた

  • アロー関数

    • この時点では結局わかっていない

    • 関数というものに慣れるまで愚直にfunctionで書いた

悪戦苦闘ポイント

  • Freshでローカルファイルを操作するにはどうしたらいいのか

    • →APIの作り方がわかったので解決

気づき

  • 乱数を使えるようになるだけで色々小さなゲームを作れる

  • プログラムが書けると、表の必要もないのにExcelを使ってやっていたような計算も簡単にやれる

  • 世の中のちょっとしたプログラムはそんなに難しくないかもしれない

  • 世にあるコードを読もうとするより自力の試行錯誤を重ねた方が早い

  • ちょっとわかり始めればあれもこれもわかる

  • 自分で工夫する余地があると、生きているという感じがする

  • 素人である自分を恥ずかしく思わないために、スマートな(そして指摘したがりな)先達は視界から排除した方がいい

  • やりたいことがはっきりしていれば必要な分の技術の習得には苦労しない

  • 「できるようになる」までの間は「できない」状態であり続けるため、目的(=希望)がないとやっていられない

気づき

  • エラーを把握できない初学者がツールを作ってもデータの保全の信用がないので安心して使えない

    • なので当分はツールを作ってみても実用は期待できない
  • 自作ツールは技術的制約があることが前提なので機能の不足も諦められる

    • 例えばスマホでの閲覧・編集
  • 全てを兼ね備える最強のツールは作れない

    • 用途が異なるものは分かれて然るべき
  • 無駄に多機能なものを作っても結局は使えないが、無駄に多機能なものを作ろうとすることで急速にスキルアップできる

  • きちんとするのが億劫で「まあいいか」と妥協したところは必ず後でネックになる

  • 2回以上使うものは(2回だけのつもりでも)無限回の繰り返しに耐えられるように一般化した方がいい

  • 何かを設定できるようにする時は(一つだけで良いつもりでも)二つ以上設定できるようにしておいた方がいい

  • 過去の自分が書いたコードに手を入れるのは新しく作るより気分的にエネルギー消費が多い

  • 一つ言語を習得すると二つ目以降の習得は比較的楽

  • 自力でビルは建てられないが棚は作れる

    • すごいツールは作れなくとも自分の生活をちょっと便利にするツールは作ることができる

気づき

  • React系に対して自分の中にあったわからなさというのは結局「ローカルファイルはどうしたらいいのか」ということだった

    • 普通ローカルファイルはいじらないのでサンプルが世の中にほとんどない

備考

 試行錯誤を徹底するのが上達の道だと思い知った。そこで重要なのが「試行錯誤できる環境」で、試した結果をすぐに確認できる場がないと試行錯誤はうまくできない。

 基本的なコードの試行にはオンラインエディタを使う、DOM関連の試行にはWebブラウザのコンソールを使う、いずれの場合もconsole.log()を使いまくって試行結果の情報を細かく得る。そうすることによって何がどうなっているものなのかをじわじわと理解していくことになる。 

備考

 例えばアウトライナー風の「畳む」挙動をプログラミングで作る場合、「畳む」コードを作るというより、「子要素を非表示にする(非表示になるclassを付与する)」コードを作ることになる。この一歩の一般化に発想の広がりが生まれる。

 頭につけた三角とかが「▶」「▼」と動けばあたかも畳まれているようだが、その三角によって「これは畳まれているのだ」と認識するだけであって、起きていることは「非表示」。「非表示」が、同時に発生する記号の動きによって「畳む」になる。これはとても面白いことだと思う。

 こういう「結果的に、そう見える」ものが、プログラムとしてはイメージと少し違った形で作られるということがよくあるのだと思う。実現したいことが何かあった時に、最初に思い浮かべたやり方とは全然違う方法でそれを実現するということが普通にある。その柔軟さを鍛えるのがコーディングのコツなのかもしれない。

備考

 ローカルサーバーや外部APIを扱うことが多くなり、RequestとResponseがやっとわかるようになった。