Noratetsu Lab

　糸口①（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

　今回は以上です。
　

何ヶ月分か意図せずお題をスルーしてしまいましたが、今月の分について滑り込みで書いてみようと思います。「ノウハウに何を求めているのか」の方はたまたま昨日の投稿がカバーしたかなと思うので、今回は「上半期の振り返り」についてです。

情報管理や書き物に関する範囲で半年を振り返ってみようと思います。
色々と細かいことで変化があった半年だなと思います。大きなことではないけれどそれまで考えたことがなかったというような試行がいくつかありました。

Scrapboxをブログのガイドにしてみた

まず、自分のブログの補助としてScrapboxのプロジェクトを用意しました。
何度も繰り返し取り上げるような概念というのがありますが、普段記事を書く時というのはその概念の説明に終始することはなく、それに関して何かを語る形になっています。そうすると、その概念についてリンクしたいというような時に、過去記事へのリンクというのは適切ではない場合がよくあります。そういう時に自分がもやもやするのを防ぐために辞書的な場が欲しいと思い、Scrapboxを活用することにしました。
バリバリ使っているというわけではありませんが、悩むことがなくなったので気持ちの面では随分スッキリとしました。
将来的には、自分のサイトを自分で作り、wiki的な機能を組み込んで記事要素と辞書要素が滑らかに繋がるようにしてみたいと考えています。

長期連載風のことを始めてみた

次に、かなり大きなサイズのシリーズ記事を書き始めました（ノートテイキングアプリDIY体験記）。専門的な知見を含むわけでもなく、単にただの自分語りを「シリーズものにする」とわざわざ宣言して取り組んでいるだけのことですが、極度に飽きっぽい私としてはちょっとしたチャレンジです。他の何かにロングスパンで取り組むための練習という意味もあります。
このシリーズを書くにあたって、過去に自分が作ったツールを、挙動をおおよそそのままにしてエラーを潰し変なコードを書き直して公開する、という義務を自分に課しており、文章よりその作業のせいで進みが非常に悪いのですが、今のところモチベーションは全然衰えていません。
過去の自分の工夫を見直し、それをより良いコードで再現するにはどうしたらいいか、というようなことを考えるうちに、プログラミングについての理解も深まってきた気がします。オブジェクト指向という意味がようやく体感としてわかってきたところです。

DynalistをChrome拡張機能で便利にしてみた

また、このシリーズを書く上で、それまで単発記事に特化したツールを自分で作って書いていたのを改めて、Dynalistを執筆ツールとして活用するようになりました（これについては前にトンネルChannelに投稿しました（Dynalistでブログを書く））。全体像を思い描くためにアウトライナーの力が必要だったからです。俯瞰と執筆で場所を変えるのは億劫だったので、本文もDynalistで書くようにしました。
とはいえ、Dynalistは長文をそのまま書くことに向いているアプリケーションとは言えません。個人的に最も困るのが字数の把握ができないことです。逆に言うとそれができればまあ私としてはDynalistで問題はないなと思いました。実際、ずっと前にはDynalistで記事を書いていた時期があって、メモ書きや没にした箇所の扱いが楽で重宝しました（子項目にしてしまえばいいのです）。
じゃあそれならばと、Chromeの拡張機能を作って字数カウントを表示するようにしました。webページに対して処理を加える拡張機能はほとんど初めての試みだったのですが、想像以上に便利になりました。この経験は、とても地味ですが大きな一歩だったように思います。

ひとり掲示板を始めてみた

少し角度が変わりますが、ひとりで掲示板を使い始めました。
のらてつの雑記帳 - zawazawa
自分の言語化を駆動するために「人が読むかもしれない」という場に書きたいけれども、Twitterのように「人の視界に流し込む」ようなのは本意ではない話題、について書く場所がほしいと考えてこの形に行き着きました。別に人目に触れるのが憚られるような話というのではなく、あまりにも自己完結しているつぶやきだなと感じる話題の置き場所を探していたのです。
使ってみるととても面白い感じがしました。面白いといっても何か愉快なことが起こるというのではないですが、自分の書き込みの並び方やリンクのさせ方について考えるとなんとなく楽しい気分になってくるのです。どんなトピックを作ろうかな、というのも楽しいポイントです。
後述する事情で更新が滞りましたが、今現在も面白いと思っていて、気が向いた時に書き込むつもりでいます。

のらてつの着ぐるみを脱いで浦島太郎になっていた

ゴールデンウィーク前あたりから最近まで、「のらてつ」の名前でアカウントを作っているサービスでの読み書きをずっとやめていました。Twitterも見ないし、ブログも書かないし、RSSもチェックしないし…という感じです。今書いたひとり掲示板も、これによって停滞していました。このことについてはブログに記事を書きました（拾い直しの旅）が、積極的な理由があったわけではなく、なんとなくフェードアウトして、なんとなく長引いたという感じです。
細かい要因が色々絡み合っての長期離脱になりましたが、充電も出来たように思います。ついこの間まで、ブログを書くという行為をどうやればいいのかわからなくなっていましたが、今は割とスイスイ書ける感じがします。まず「書こう」という意志があります。「書こう」という気持ちさえあれば何かは書けるという感じがします。

最強のノートツールを作った

「のらてつ」の着ぐるみを脱いでいる間、自分用ツールの開発は続けていました。懐古モードに入っていたのでVectorでフリーウェア探しなんかをしていたのですが、そこで試した種々のアプリケーションから大いに刺激を受けました。そのことによって、それまでとは根本的に違う仕組みのツールを作り始めました。
詳細はそのうちどこかに書きますが、日々発生する自分のためのメモの置き場として理想的なツールを欲していて、その解となるツールを作り上げたという感じです。日記、日誌、予定管理、自己対話、文章執筆、読書メモ、調べ物、といったものを全部カバーするもので、データとしては「カード」「チャット」「Wiki」の三種類の形式をひとつのツール上で扱っています。
Dynalistを執筆に使い始めたという話をしたばかりですが、書き物の場はこのツールに取って代わられました。

このような感じです。この半年間が良いことばかりだったわけではありませんが、情報管理と書き物の面では大きく前進した半年だったのではないかと思います。

こちらの投稿を読みました。

• productivityからpracticalityへ - by 倉下忠憲@rashita2

productivity（生産性）よりpracticality（実用性）の尺度を物差しとしてはどうか、というお話にはその通りだなと頷いて読みました。
多分議題としてズレたものになるのでこのお話に対する新たな提案というわけではありませんが、ちょっと考えたことがあったので書こうと思います。

生産性にしても実用性にしても、これは「客観的に測るもの」であることを前提とした尺度と感じました。生産者に依存するのではなく、単位時間当たりにどの程度生産されるのかとか生産物が世の中でどう価値を持つのかということです。そもそもが「しょうもないものをただバンバン生産できたからってしょうがないよね」という文脈なので当たり前の視点かと思います。
外国語ではどのようなイメージを伴っているのかわかりませんが、日本語では「知的生産」という言葉に工業的な響きがあり、否応なしに「質」と「量」の概念を引き連れてくるという感じもします。「知的生産」と呼ぶ限り、書き手は「生産者」なのです。

一方で、私が個人的にイメージしていたのは、「その人に可能な最大限のもの」を上限とした尺度です。少し俗っぽい言い方ですが、巷で言われている「パフォーマンス」です。
performanceを辞書で引くと、2番目に「仕事ぶり」、3番目に「（スポーツ選手などの）プレーぶり」とありました。1番目には「業績」とか「成績」とあって、それはカタカナ語として使われている用法から少し離れるなと感じるので、ここで採用したいのは「仕事ぶり」「プレーぶり」の方のニュアンスです。ここに「上げる」とか「下がる」とかの動詞がつくことで、その人なりの「○○ぶり」の程度が上下するイメージが生まれるように思います。
アスリートのプレーぶりに使われることが多いので、パフォーマンスという言葉の背景には「質を最大限に高めないと勝てない」という世界観を感じます。つまり効率性ではなく実際的な価値を追求するものということです。仮に練習メニューを手早くこなせるようになっても、試合で自分が発揮する力に貢献しなければ意味がないわけです。
また、一般的に「仕事ぶり」と言った場合も、ただ「早く仕事を片付けられる」という意味で言うわけではないと感じます。仕事が早いことも含みますが、本人としても周りとしても気持ちが良い仕事の仕方であるという意味合いが込められているでしょう。

ただまあ、「パフォーマンスを上げる」という表現には真新しさもなければカッコよさもないので、「知的生産のパフォーマンスを上げる」ということを掲げてもなんだかスッキリしません。そもそも、パフォーマンスを上げるという表現が出てくる場面がスポーツかビジネスかで、結局競争の文脈がついて回るのもこの表現が最善ではない感じをもたらしています。
知的生産という文脈に合わせて日本語に戻すならば「書きぶり」ということになるでしょうか。これなら競争している感はありません。ただし向上させるイメージもちょっと失われます。その人固有の能力っぽい感じを纏い始める気がするからです。
となると、もったりとした表現になりますが、気持ちとしては「良い書きっぷりを目指す」というのがよい感じです。「良い文章を目指す」としてしまうとどこかに正解があるかのようで迷走の元になりかねませんが、「良い書きっぷり」とすると私の感覚としては適度に主観的に思えます。

例えばAIの力を借りて知的生産をするという時、効率の話が主になると如何にも「要領の良さ」が明暗を分けるかのようで、AIが世界の無味乾燥度合いを増進させるような雰囲気が漂います。
しかし、素朴に「自分の質を上げてくれる」ことに感動している人はたくさんいるわけで、「社会で勝ち抜く」的な雑音に惑わされずに自分の○○ぶりを良くするイメージを持ち続けたいものだと思っています。

「自分なりの」という面を中心に置いた見方について綴ろうとしてみたわけですが、でも結論としては倉下さんのお話と同じことを繰り返しただけな気もします。望ましいと思うベクトルの向きが同じだからですね。

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

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

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

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

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

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

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

情熱の記録

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

励ましというよりは

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

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

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

いきなり作れ

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

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

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

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

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

• 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」の解説を見てみましょう。

• Draggable | jQuery UI 1.10 日本語リファレンス | js STUDIO

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

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

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