※このページは個人サイト内のBBS風マイクロブログコンテンツです。
プログラミング日記
現在使っている言語
JavaScript/TypeScript
(AutoHotkey)
取り組んでいること
HTML+CSS+JavaScript+ローカルサーバーで自作Webアプリ
- （前はElectronを使っていたが今はWebブラウザ＋ローカルサーバー）
Chrome拡張機能開発
（VSCode拡張機能開発）
DenoおよびFresh
他のプログラミング関連の情報置き場
ここ数日VSCodeの拡張機能開発をやり始めた。
VS Code API | Visual Studio Code Extension API
日本語の解説記事はあんまりないので、数少ない手本とこの公式のAPIガイドとにらめっこしてちまちま進んでいる。
TypeScriptにそこそこ慣れたので、型で説明されている部分も大分わかるようになってきた。進歩を感じる。
このレスへのレス（>>3）
>>1
というか、API全般そうだけど、JavaScriptだけやってても説明がよくわからないのではという感じがする。
TypeScriptを使えるようになるというのは「読む」ために必要なことなのかもしれない。
このレスへのレス（>>4）
>>3
あ、でもJSDocがわかればいいのか。
いずれにしろどちらかの方法で型付けを理解する必要があるのだろう。
あとVSCodeのデバッグ機能というのを初めて使っている。
これまでデバッグ機能は「よくわからないから触らないでおこう」という感じだったので、前進した感がすごい。実績解除というやつか。ゲームで鍵がかかっていた機能が解放されたみたいな。
といっても今のところは「拡張機能開発ホスト」というのを立ち上げる用途しか理解していない。とりあえずはそれでいいかなと思う。そのうち勉強します。
言及先
ここ数日VSCodeの拡張機能開発をやり始めた。
VS Code API | Visual Studio Code Extension API
日本語の解説記事はあんまりないので、数少ない手本とこの公式のAPIガイドとにらめっこしてちまちま進んでいる。
TypeScriptにそこそこ慣れたので、型で説明されている部分も大分わかるようになってきた。進歩を感じる。
>>1
というか、API全般そうだけど、JavaScriptだけやってても説明がよくわからないのではという感じがする。
TypeScriptを使えるようになるというのは「読む」ために必要なことなのかもしれない。
このレスへのレス（>>4）
>>3
あ、でもJSDocがわかればいいのか。
いずれにしろどちらかの方法で型付けを理解する必要があるのだろう。
言及先
言及先
ここ数日VSCodeの拡張機能開発をやり始めた。
VS Code API | Visual Studio Code Extension API
日本語の解説記事はあんまりないので、数少ない手本とこの公式のAPIガイドとにらめっこしてちまちま進んでいる。
TypeScriptにそこそこ慣れたので、型で説明されている部分も大分わかるようになってきた。進歩を感じる。
>>1
というか、API全般そうだけど、JavaScriptだけやってても説明がよくわからないのではという感じがする。
TypeScriptを使えるようになるというのは「読む」ために必要なことなのかもしれない。
>>3
あ、でもJSDocがわかればいいのか。
いずれにしろどちらかの方法で型付けを理解する必要があるのだろう。
自作アプリケーション（デジタルノート系）を色々作ってきたけど、結局今ガッツリ使っているのは日記用に作ったものひとつだけ…。
前にブログに書いた、HyperDatabaseと名付けた自分的に高機能なアプリケーションは、自分の生活の状況によって使い勝手が変わってくるというのが自分でわかっていて、作った時はよかったけど今はちょっと違うかなという感じで休眠している。また使う時が来るだろうとは思う。
あと自作よりカスタマイズの方が難しくて、ScrapboxのUserScriptなりChromeなりVSCodeなりを自分で機能拡張できるようになったのは本当に大きい。
やっぱり、土台の頼りない完全自家製ツールで頑張るよりも、ちゃんとしたものを自分仕様に近づけられた方が安心感があるし有用だと思う。でもそれができるようになるにはツールを自作しまくって鍛錬を重ねることが必要だったと感じる。
VSCode拡張機能は今のところ、
左サイドメニューにアイコン設置
左サイドパネルの表示
任意のデータでツリー構造作成（Tree View）
- 開いているmdファイルのフロントマターのデータをサイドパネルにツリー構造で表示
絞り込んだファイル群を選択肢としたクイックオープン構築
- 選択でそのファイルを開く
あたりができるようになった。
そんなに難しくはないのだと思うけど、APIと格闘するということ自体がそんなに慣れていないことなのでなかなか時間がかかる。
少し前から諸事情によりしばらくの間マウスを使いにくい環境になってしまって、作業効率が著しく落ちている。
文章はそんなに影響ないんだけどプログラミングがやりにくい…。
あまり「全てキーボードで完結！」みたいなことやっていないからマウスの有無の影響が大きい。
TypeScriptでオブジェクトの全プロパティを走査するときの注意点 | JavaScript/TypeScriptメモ
TypeScriptでfor...inを使うと面倒だなあと思っていた。あんまりスッキリした解決策はないのか。
このレスへのレス（>>12）
>>9 の問題はMapで解決するのだろうか。
でもJSON化は難しいか？ というか、オブジェクトへの変換を挟む必要が出てくるか。
javascript Mapからjsonに変換する | mebee
// Map→Object
const map = new Map([
[1,'aaa'],
[2,'bbb'],
[3,'ccc']
]);
const obj = Object.fromEntries(map);
const json = JSON.stringify(obj);
// Object→Map
const obj2 = JSON.parse(json);
const arr = Object.entries(obj2);
const map2 = new Map(arr);これだとmapではkeyがnumberだったけどObject.fromEntries()の時点でstringになるのか。
このレスへのレス（>>13）
>>12
keyに何でも設定できる、ということもちゃんと考える必要があるな。
JavaScriptのMapオブジェクトってどういうタイミングで使えば良いんだろうと思ってたけど、ObjectをObjectとして使うことを考えるとMap的に使っているものはObjectにしないでMapにすべきということか。
初心者的に「オブジェクト」を考えた時、オブジェクトらしさではなくあくまで「キーとプロパティの組」を束ねたものとしてイメージしている。それがMapだということかな。
このレスへのレス（>>11,>>15,>>19）
>>10 >>14
有効かどうか、良いコーディングかどうか、というより、もっと色々遊びたいなという感じ。自分の遊び場を広げていきたい。
言及先
JavaScriptのMapオブジェクトってどういうタイミングで使えば良いんだろうと思ってたけど、ObjectをObjectとして使うことを考えるとMap的に使っているものはObjectにしないでMapにすべきということか。
初心者的に「オブジェクト」を考えた時、オブジェクトらしさではなくあくまで「キーとプロパティの組」を束ねたものとしてイメージしている。それがMapだということかな。
言及先
TypeScriptでオブジェクトの全プロパティを走査するときの注意点 | JavaScript/TypeScriptメモ
TypeScriptでfor...inを使うと面倒だなあと思っていた。あんまりスッキリした解決策はないのか。
>>9 の問題はMapで解決するのだろうか。
でもJSON化は難しいか？ というか、オブジェクトへの変換を挟む必要が出てくるか。
javascript Mapからjsonに変換する | mebee
// Map→Object
const map = new Map([
[1,'aaa'],
[2,'bbb'],
[3,'ccc']
]);
const obj = Object.fromEntries(map);
const json = JSON.stringify(obj);
// Object→Map
const obj2 = JSON.parse(json);
const arr = Object.entries(obj2);
const map2 = new Map(arr);これだとmapではkeyがnumberだったけどObject.fromEntries()の時点でstringになるのか。
このレスへのレス（>>13）
>>12
keyに何でも設定できる、ということもちゃんと考える必要があるな。
言及先
言及先
TypeScriptでオブジェクトの全プロパティを走査するときの注意点 | JavaScript/TypeScriptメモ
TypeScriptでfor...inを使うと面倒だなあと思っていた。あんまりスッキリした解決策はないのか。
>>9 の問題はMapで解決するのだろうか。
でもJSON化は難しいか？ というか、オブジェクトへの変換を挟む必要が出てくるか。
javascript Mapからjsonに変換する | mebee
// Map→Object
const map = new Map([
[1,'aaa'],
[2,'bbb'],
[3,'ccc']
]);
const obj = Object.fromEntries(map);
const json = JSON.stringify(obj);
// Object→Map
const obj2 = JSON.parse(json);
const arr = Object.entries(obj2);
const map2 = new Map(arr);これだとmapではkeyがnumberだったけどObject.fromEntries()の時点でstringになるのか。
>>12
keyに何でも設定できる、ということもちゃんと考える必要があるな。
JavaScriptのクラスとインスタンスのことをもうちょっと柔軟に考える必要があるかもしれない。
Smalltalk（Pharo）に触って感化された。
このレスへのレス（>>15,>>16）
>>10 >>14
有効かどうか、良いコーディングかどうか、というより、もっと色々遊びたいなという感じ。自分の遊び場を広げていきたい。
>>14
オブジェクトとは何か、ということについて考えるようになった。
JavaScriptのObjectの仕組みもようやくわかってきた。プロパティとメソッドが読めるようになってきた。
このレスへのレス（>>17）
言及先
JavaScriptのMapオブジェクトってどういうタイミングで使えば良いんだろうと思ってたけど、ObjectをObjectとして使うことを考えるとMap的に使っているものはObjectにしないでMapにすべきということか。
初心者的に「オブジェクト」を考えた時、オブジェクトらしさではなくあくまで「キーとプロパティの組」を束ねたものとしてイメージしている。それがMapだということかな。
JavaScriptのクラスとインスタンスのことをもうちょっと柔軟に考える必要があるかもしれない。
Smalltalk（Pharo）に触って感化された。
>>10 >>14
有効かどうか、良いコーディングかどうか、というより、もっと色々遊びたいなという感じ。自分の遊び場を広げていきたい。
言及先
JavaScriptのクラスとインスタンスのことをもうちょっと柔軟に考える必要があるかもしれない。
Smalltalk（Pharo）に触って感化された。
>>14
オブジェクトとは何か、ということについて考えるようになった。
JavaScriptのObjectの仕組みもようやくわかってきた。プロパティとメソッドが読めるようになってきた。
このレスへのレス（>>17）
言及先
言及先
JavaScriptのクラスとインスタンスのことをもうちょっと柔軟に考える必要があるかもしれない。
Smalltalk（Pharo）に触って感化された。
>>14
オブジェクトとは何か、ということについて考えるようになった。
JavaScriptのObjectの仕組みもようやくわかってきた。プロパティとメソッドが読めるようになってきた。
あ～、今見たら使い所がちょっとわかったかもしれない。どう実装すればいいのかずっとわからなかったことが、これで解決するんじゃないか。
言及先
JavaScriptのMapオブジェクトってどういうタイミングで使えば良いんだろうと思ってたけど、ObjectをObjectとして使うことを考えるとMap的に使っているものはObjectにしないでMapにすべきということか。
初心者的に「オブジェクト」を考えた時、オブジェクトらしさではなくあくまで「キーとプロパティの組」を束ねたものとしてイメージしている。それがMapだということかな。
このレスへのレス（>>21,>>22）
>>20
JavaScript互換性の要！Symbol（シンボル）について｜もっこりJavaScript｜ANALOGIC（アナロジック）
シンボルは私たちのようなJavaScriptを使ってコードを書く側の人間ではなく、JavaScriptの仕様策定側にとって最も必要な仕組みだった、というわけですね。
なるほど。
>>20
ECMAScript6にシンボルができた理由 - Qiita
そんな訳で、ECMAScriptの仕様策定側にとってシンボルは非常に重要。だが逆に言えば、使うライブラリを自分達で決められ、自分達で書いたアプリを自分達でテストできる一般の開発者は、名前の衝突なんてどうとでも回避してきたわけで、今更シンボルが使えてもそんなに嬉しいことはないと思われる。
言及先
>>20
JavaScript互換性の要！Symbol（シンボル）について｜もっこりJavaScript｜ANALOGIC（アナロジック）
シンボルは私たちのようなJavaScriptを使ってコードを書く側の人間ではなく、JavaScriptの仕様策定側にとって最も必要な仕組みだった、というわけですね。
なるほど。
言及先
>>20
ECMAScript6にシンボルができた理由 - Qiita
そんな訳で、ECMAScriptの仕様策定側にとってシンボルは非常に重要。だが逆に言えば、使うライブラリを自分達で決められ、自分達で書いたアプリを自分達でテストできる一般の開発者は、名前の衝突なんてどうとでも回避してきたわけで、今更シンボルが使えてもそんなに嬉しいことはないと思われる。
Functionのapply,call,bindってよくわかってなかったけどなんとなくわかった気がしないでもない。
なんでもかんでもオブジェクトのメンバー化してまとめる期がちょっと前までマイブームだった。クラスでそうしていたのを、インスタンス化しないオブジェクトでもそうしてみようと思ってやっていた。
そのオブジェクト内で完結させる、という発想を自分の中で定着させるにはとても役立ったが、オブジェクトだとprivateに設定できないので外からアクセスするメソッドがどれかがパッとわからないという欠点があった。
現時点では、即時関数を使ってメソッドをまとめたオブジェクトを返す形に落ち着いている。
最初からこうしていればよかったのになあ。
このレスへのレス（>>25）
>>24
これをクロージャというわけだ。
言及先
なんでもかんでもオブジェクトのメンバー化してまとめる期がちょっと前までマイブームだった。クラスでそうしていたのを、インスタンス化しないオブジェクトでもそうしてみようと思ってやっていた。
そのオブジェクト内で完結させる、という発想を自分の中で定着させるにはとても役立ったが、オブジェクトだとprivateに設定できないので外からアクセスするメソッドがどれかがパッとわからないという欠点があった。
現時点では、即時関数を使ってメソッドをまとめたオブジェクトを返す形に落ち着いている。
最初からこうしていればよかったのになあ。
>>24
これをクロージャというわけだ。
textarea内でショートカットキーを使った時に色々便利なことが起こるように機能を作っているんだけど、Markdownのtable記法の処理ができるようになって我ながらすごいものを作ったという気分。
行追加、列追加、列の入れ替えができるようになった。
このレスへのレス（>>27）
>>26
offset類の計算がどうも苦手で頭がこんがらがったが、テストをちょこちょこやって正しいっぽい挙動を作れた。
結構複雑な処理になった…。
言及先
textarea内でショートカットキーを使った時に色々便利なことが起こるように機能を作っているんだけど、Markdownのtable記法の処理ができるようになって我ながらすごいものを作ったという気分。
行追加、列追加、列の入れ替えができるようになった。
>>26
offset類の計算がどうも苦手で頭がこんがらがったが、テストをちょこちょこやって正しいっぽい挙動を作れた。
結構複雑な処理になった…。
自分のサイトにzawazawaから内容を移すにあたり読み返したけど、VSCode拡張機能開発とかやっていたことすら忘れていた。もちろん（？）やり方も忘れた。
頑張って作っても、操作方法とかを覚えていられないと使い続けられない。アフォーダンスを整えるのは機能そのものより大変で面倒くさいし、やはりプロの仕事はそこがすごい。
今はもっぱらDenoのFreshをやっている。
昨日、Freshでえらく苦戦して結局動かない理由が分からないで終わった。
しかし一夜明けて今朝コードを見て、根本的な原因にあっさり気がついた。「islands」として書かなければいけない部品を「routes」のファイルに直に書いてしまっていたからだった。というか、islandsで完結すべきところを、routesでsignalの橋渡しをしようとして動かないということになっていた。
この「動かない」はエラーが出ないので原因が見えてこなかった。逆に「エラーが出ないけど動かない」はサーバーサイドとクライアントサイドの区別を誤っているということだとアタリをつけるべきなのかも。
DenoとFreshによって自分の自由さが急激に上がった感じがする。翼を得たみたいな。
HTMLの記号・特殊文字の文字コード表（文字実体参照、数値文字参照） | GRAYCODE HTML&CSS
使う機会が多い文字実体参照
&→＆amp;"→＆quot;＆nbsp;<→＆lt;>→＆gt;
※「＆」は実際は半角。
ScrapboxのJSONを元にサイトのデータを作る時に参考にしたページ。
CSSはそれなりに前から取り組んでいるけど、コーディングより苦手だなと思う。というか、勉強の仕方を掴めていなかった。
最近読んだページ
久々にChrome拡張機能をいじったけど色々忘れていて戸惑った。
あとjsにJSDocを駆使して書いているけど、それがちょっと見づらい…。自分の使い方が下手でわかりやすくなってないせいか。
いや、「上に書いてある」のが見づらい原因な気も…。
このレスへのレス（>>36,>>37）
>>35
あと当時の関数の作り方が下手すぎる…。
ラッパーを作ることにハマっていたからラッパーを色々作っているけどそれ作る意味ある？という関数があるし逆に肝心なラッパーがない。
加えて、GitHubで見かけるプロダクトへの憧れでファイルを色々分けているけど、ファイルを分けるんじゃなくてClass使うとかすべきなんじゃないかこれは。
>>35
JavaScriptで書くの辛いしメンテナンスしづらいし、これTypeScriptで書いてDenoでbundleしたらいいかなあ…。
言及先
久々にChrome拡張機能をいじったけど色々忘れていて戸惑った。
あとjsにJSDocを駆使して書いているけど、それがちょっと見づらい…。自分の使い方が下手でわかりやすくなってないせいか。
いや、「上に書いてある」のが見づらい原因な気も…。
>>35
あと当時の関数の作り方が下手すぎる…。
ラッパーを作ることにハマっていたからラッパーを色々作っているけどそれ作る意味ある？という関数があるし逆に肝心なラッパーがない。
加えて、GitHubで見かけるプロダクトへの憧れでファイルを色々分けているけど、ファイルを分けるんじゃなくてClass使うとかすべきなんじゃないかこれは。
言及先
久々にChrome拡張機能をいじったけど色々忘れていて戸惑った。
あとjsにJSDocを駆使して書いているけど、それがちょっと見づらい…。自分の使い方が下手でわかりやすくなってないせいか。
いや、「上に書いてある」のが見づらい原因な気も…。
>>35
JavaScriptで書くの辛いしメンテナンスしづらいし、これTypeScriptで書いてDenoでbundleしたらいいかなあ…。
以前作ったテトリス風ゲームを自分のサイトに移植しようかと思っているけど、なかなか大変だ。
Preactに書き換えないで単にjsファイルを読み込む形にした方がいいかもしれないなあ。
とりあえずそのやり方で移してみるか。書き換えるかどうかはその後考えよう。
このレスへのレス（>>39）
>>38
やっぱり書き換えるのは大変過ぎるのでやめておこう。
元のjsファイルをちょっと調整したら読み込めたので、古いツールやゲームはとりあえずその形で移植することにする。
言及先
以前作ったテトリス風ゲームを自分のサイトに移植しようかと思っているけど、なかなか大変だ。
Preactに書き換えないで単にjsファイルを読み込む形にした方がいいかもしれないなあ。
とりあえずそのやり方で移してみるか。書き換えるかどうかはその後考えよう。
>>38
やっぱり書き換えるのは大変過ぎるのでやめておこう。
元のjsファイルをちょっと調整したら読み込めたので、古いツールやゲームはとりあえずその形で移植することにする。
ScrapboxのUserScript開発の拠点に迷っている。
Scrapbox上で直に書くと書き間違うしサジェストがないのは辛い。
あとTypeScriptを使いたい。結局VSCodeで書いてバンドルしてコピペ、という形が一番スムーズかなあ。
Scrapboxのページ間でimportできるから各ページをmoduleとして使うということをやっているけど、Scrapbox上にあるコードはメンテナンスが面倒くさくてページを分けると硬直的になってしまう。module化はしないで各ページで完結させた方がいいのかもしれない。
Notion APIを大体理解したので例えば自分のサイトデータをNotionで管理とかも一応できるであろうという感じではあるけど、そうした方がいいかっていうと微妙なところだ…。
それにしてもNotion API、他のAPIとオブジェクトの構造が違いすぎてなかなか理解が難しかった。
このレスへのレス（>>44）
>>41
rich_textのオブジェクトとMarkdownをコンバートする関数を作れたら多分そんなに苦労がないんだけど自力で作るのちょっとしんどいな…。
このレスへのレス（>>45）
>>44
まさに求めていたものがあった。誰かは作ってくれてるんじゃないかと思ったけど。ありがたい。
Chrome拡張機能開発で今日一日悩んでいたことがやっと解決した…。
コンテキストメニューでクリップボードを使うためには、background.js(service worker)からメッセージを送ってcontent scriptsでキャッチして実行する必要があるということを学んだ。
Dynalistで長い文章を章ごとに書いたりしたのをコマンド一発でいい感じにまとめて一本のtxtに出力できるようにした。API万歳。
言及先
Notion APIを大体理解したので例えば自分のサイトデータをNotionで管理とかも一応できるであろうという感じではあるけど、そうした方がいいかっていうと微妙なところだ…。
それにしてもNotion API、他のAPIとオブジェクトの構造が違いすぎてなかなか理解が難しかった。
>>41
rich_textのオブジェクトとMarkdownをコンバートする関数を作れたら多分そんなに苦労がないんだけど自力で作るのちょっとしんどいな…。
このレスへのレス（>>45）
>>44
まさに求めていたものがあった。誰かは作ってくれてるんじゃないかと思ったけど。ありがたい。
言及先
言及先
Notion APIを大体理解したので例えば自分のサイトデータをNotionで管理とかも一応できるであろうという感じではあるけど、そうした方がいいかっていうと微妙なところだ…。
それにしてもNotion API、他のAPIとオブジェクトの構造が違いすぎてなかなか理解が難しかった。
>>41
rich_textのオブジェクトとMarkdownをコンバートする関数を作れたら多分そんなに苦労がないんだけど自力で作るのちょっとしんどいな…。
>>44
まさに求めていたものがあった。誰かは作ってくれてるんじゃないかと思ったけど。ありがたい。