ブログもそうですが その他のところでもタグ付けって結構あちこちにあります
で 思うのですがタグに親子関係のような関連性を持たせたいです
記事でいうと React の記事を書いたらタグには "React" をつけますが その他にも "JavaScript" や "Frontend" などもつけると思います
Fastify の記事であれば "Fastify" 以外に "JavaScript", "Node.js", "Backend" など
このタグなら他にこれらもついてくるみたいなのを記事側に全部つけなくてもタグ側でやってほしいのですよね
React だけつければ その記事は React タグで検索したとき以外に JavaScript や Frontend タグで検索したときも出てきてほしいです
あと class というタグがあったとき オブジェクト指向言語で使われるクラスなのか HTML 属性のクラスなのかわからないです
同じ名前で違う意味のものがあるとときに区別ができないです
この点でも ただの名前の文字列だけじゃなくて関連性を持つものなら オブジェクト指向と関連性をもつ class か HTML と関連性を持つ class かで分けられます
こういうタグシステムが普及してほしいのですが 現状はどこのサービスもただの文字列だけでしかないんですよね
楽に作れる物が欲しいです
いつもなら細かくライブラリを厳選してそれらを組み合わせて使うほうが好きなので 全部入りで色々決まっていてカスタマイズの余地が少ないライブラリやフレームワークは好みではないです
色々と自分でできるほうが楽しいですし自分の好みに調整できます
ですが 時間を掛けずとりあえず動かしたいってときもたまにはあるんですよね
どう作るかよりも何を作るかに力を入れたいときです
そういうときはこだわりはなくコードがどうなっていようと言語がなんであろうと動けば何でもいいです
やりたいことが実現できないとかでなければですけど
AI がもう少し賢ければありかもと思うのですが 現状だと動かないコードばかりですし コードを書く量は減っても人がバグを見つけて修正するような作業をしないといけないです
AI のコードレビューはしたくないので AI はなしでフレームワークに頼りたいところです
といっても Node.js ってあまりそういうフレームワークがないです
Express や Koa はミドルウェア系で本体は最小限で 各機能は外部のミドルウェア任せです
Fastify は基本的なプラグインは公式が提供していますが 結局別パッケージに分かれていたり設定の自由度があるので楽かというとそうとも言いづらいです
普段使いのテンプレートみたいなのがあればいいですが そうでないと色々考えることが多いです
公式にあるプラグインは基本的なウェブサーバーとしては十分ですが アプリケーションとして考えると不足箇所が多く結局そこはサードパーティのプラグインを探すか自作が必要になります
マイナーどころを探せばそういうフレームワークもないわけではないですが こういうフレームワークはメジャーであって 情報が多いことが重要です
フレームワークの内部実装まで読んでコードを書いたりしたくないですし
そうなると 他言語で Ruby の RoR や PHP の Laravel になってくるのでしょうか
これらもあまり気軽に使えるようなものじゃない気がしますけど
いつもなら細かくライブラリを厳選してそれらを組み合わせて使うほうが好きなので 全部入りで色々決まっていてカスタマイズの余地が少ないライブラリやフレームワークは好みではないです
色々と自分でできるほうが楽しいですし自分の好みに調整できます
ですが 時間を掛けずとりあえず動かしたいってときもたまにはあるんですよね
どう作るかよりも何を作るかに力を入れたいときです
そういうときはこだわりはなくコードがどうなっていようと言語がなんであろうと動けば何でもいいです
やりたいことが実現できないとかでなければですけど
AI がもう少し賢ければありかもと思うのですが 現状だと動かないコードばかりですし コードを書く量は減っても人がバグを見つけて修正するような作業をしないといけないです
AI のコードレビューはしたくないので AI はなしでフレームワークに頼りたいところです
といっても Node.js ってあまりそういうフレームワークがないです
Express や Koa はミドルウェア系で本体は最小限で 各機能は外部のミドルウェア任せです
Fastify は基本的なプラグインは公式が提供していますが 結局別パッケージに分かれていたり設定の自由度があるので楽かというとそうとも言いづらいです
普段使いのテンプレートみたいなのがあればいいですが そうでないと色々考えることが多いです
公式にあるプラグインは基本的なウェブサーバーとしては十分ですが アプリケーションとして考えると不足箇所が多く結局そこはサードパーティのプラグインを探すか自作が必要になります
マイナーどころを探せばそういうフレームワークもないわけではないですが こういうフレームワークはメジャーであって 情報が多いことが重要です
フレームワークの内部実装まで読んでコードを書いたりしたくないですし
そうなると 他言語で Ruby の RoR や PHP の Laravel になってくるのでしょうか
これらもあまり気軽に使えるようなものじゃない気がしますけど
最近メインの方のブログで異常なアクセス数になってることがあります
サーバーはライブドアブログのものなので私にとってはどうでもいいことですが 1 人で同じページに数千回のアクセスってもう攻撃レベルですよね
自分でサーバーを管理する場合はこういうのに対応しないといけなくて大変そうなので やっぱりこういうサーバー管理は自分で行わないサービスがいいですね
にしてもここまでくれば IP をブロックしてもいいと思うのにこれだけのアクセス数が数えられてるってことはブロックせずレスポンスを返してたってことで緩めなんだなと思います
サーバーはライブドアブログのものなので私にとってはどうでもいいことですが 1 人で同じページに数千回のアクセスってもう攻撃レベルですよね
自分でサーバーを管理する場合はこういうのに対応しないといけなくて大変そうなので やっぱりこういうサーバー管理は自分で行わないサービスがいいですね
にしてもここまでくれば IP をブロックしてもいいと思うのにこれだけのアクセス数が数えられてるってことはブロックせずレスポンスを返してたってことで緩めなんだなと思います
やりたいことを実現する良い方法が思いつかなくてググってみてもこれといったのがみつからないです
なんとなく AI にでも聞いてみるかと思って聞いてみました
回答は想像以上に求めているものが出てきました
そんなのがあったんだ！と驚いてその名前でググったのですがそれっぽいのは出てきません
ドキュメントの URL を出してって言ったら公式サイトらしい URL や Github 上のファイルの URL を出してくれました
ただ アクセスしても 404 エラー
実在しない機能みたいです
名前や機能はいかにもそれっぽくてありそうだったのに
あと URL はとてもそれらしい名前でした
そのサイトの命名規則に従っていて パッと見では正規のものにしかみえなかったですし
Github だとリポジトリ名やブランチ名は実在のもので パスもいかにもな感じでした
やっぱり正確性が足りないと 知らないことを聞くのには向いてないですね
なんとなく AI にでも聞いてみるかと思って聞いてみました
回答は想像以上に求めているものが出てきました
そんなのがあったんだ！と驚いてその名前でググったのですがそれっぽいのは出てきません
ドキュメントの URL を出してって言ったら公式サイトらしい URL や Github 上のファイルの URL を出してくれました
ただ アクセスしても 404 エラー
実在しない機能みたいです
名前や機能はいかにもそれっぽくてありそうだったのに
あと URL はとてもそれらしい名前でした
そのサイトの命名規則に従っていて パッと見では正規のものにしかみえなかったですし
Github だとリポジトリ名やブランチ名は実在のもので パスもいかにもな感じでした
やっぱり正確性が足りないと 知らないことを聞くのには向いてないですね
このブログのトップページやカテゴリページなど 記事が一覧表示されているところでは記事の開閉が行なえます
記事の右端でスクロールバーがありそうなエリアが開閉ボタンになっています
閉じてるときは青色の場所です
開くと黄色になります
個別ページに飛ばなくても一覧ページで中身も見れて便利機能ではあるのですが これって使ってる人どれくらいいるのでしょうか
気になったので調査してみました
直近の 1 ヶ月をみたところ
6 人
でした
かなり少ないですね
ここまでだとむしろなぜその 6 人は開いたの？って疑問に感じるくらいです
ただ考えてみるとこっちのサブブログはそもそもの訪問者数が少ないです
直近 1 週間のユニークユーザーから平均を求めると だいたい 70人/日 でした
この数字には bot 等も含まれます
リファラを見ると 9 割以上は Google 検索です
ググって出てきたページを見るときって軽い気持ちでいくつか開いてみて ほとんどは期待と違っていて閉じます
それを考えたら 中身が期待と一致していて さらにそれで終わらずブログのトップページに移動して 他の記事まで読もうと思って 横のボタンに気づく人なんてかなり少ないはずです
そう考えると 6 人は多い方なのかもしれません
ところで人数は日でリセットされてるかわからないので もしかすると別の日にアクセスしてるだけで実際は 1 人という可能性もあります
記事の右端でスクロールバーがありそうなエリアが開閉ボタンになっています
閉じてるときは青色の場所です
開くと黄色になります
個別ページに飛ばなくても一覧ページで中身も見れて便利機能ではあるのですが これって使ってる人どれくらいいるのでしょうか
気になったので調査してみました
直近の 1 ヶ月をみたところ
6 人
でした
かなり少ないですね
ここまでだとむしろなぜその 6 人は開いたの？って疑問に感じるくらいです
ただ考えてみるとこっちのサブブログはそもそもの訪問者数が少ないです
直近 1 週間のユニークユーザーから平均を求めると だいたい 70人/日 でした
この数字には bot 等も含まれます
リファラを見ると 9 割以上は Google 検索です
ググって出てきたページを見るときって軽い気持ちでいくつか開いてみて ほとんどは期待と違っていて閉じます
それを考えたら 中身が期待と一致していて さらにそれで終わらずブログのトップページに移動して 他の記事まで読もうと思って 横のボタンに気づく人なんてかなり少ないはずです
そう考えると 6 人は多い方なのかもしれません
ところで人数は日でリセットされてるかわからないので もしかすると別の日にアクセスしてるだけで実際は 1 人という可能性もあります
海外サービスってログをずっと残しておいてくれるのが多いと思います
Amazon だと購入履歴がかなり昔のものも見れます
それに対して日本の銀行みたいなところってある程度の期間の情報しか残ってません
まぁ 全ユーザーの過去ログを保存してるとストレージ使用量も多くなりますし 検索負荷も高くなりますからね
消えるのは仕方ないにしても ユーザーは手元に記録を残しておきたいのでエクスポートできるようになってるものが多いはずです
そんなときのエクスポートするフォーマットって何がいいんでしょう
よく見るのはやっぱり PDF
印刷が前提ならとりあえず PDF となります
でもわざわざ印刷するような人って今の時代少ないですよね
それだとあまり PDF のメリットはないです
簡単に編集できないので誤って変更してしまうことはないですが 環境によっては扱いづらいです
あとデータを抽出して扱いたい時に PDF は相性が悪すぎます
そういうことを考えると XLSX
簡単に編集できますが 一応編集できないよう保護することもできます
保護を外せますが 外すなら意図的に変更してるのでそこは気にしてなくもいいと思います
データを抽出して扱いたい時は別のブックにデータをコピペしてそのままエクセル上で処理できます
ただ エクセルが入ってることが前提になります
最近は Office を入れてない人もいます
一応 OneDrive に保存してオンラインでエクセルを操作することはできますけど 扱いやすいとはいえないです
意外といいかもと思ったのは HTML
ダブルクリックすればブラウザで見れます
CDN のライブラリを使わなければ HTML 単体でネットに繋がっていなくても見れます
エクセルや PDF よりリッチな見た目にもできます
テキストエディタで開かないと編集はできないので誤って変更することはなさそうです
HTML 構造からデータを取り出せますし 内部でデータを JSON で持ってそれから DOM を作るようにしておけば JSON を取り出すこともできます
ただ エクセルよりは専門的な知識がいるので誰でもできるものじゃないです
Amazon だと購入履歴がかなり昔のものも見れます
それに対して日本の銀行みたいなところってある程度の期間の情報しか残ってません
まぁ 全ユーザーの過去ログを保存してるとストレージ使用量も多くなりますし 検索負荷も高くなりますからね
消えるのは仕方ないにしても ユーザーは手元に記録を残しておきたいのでエクスポートできるようになってるものが多いはずです
そんなときのエクスポートするフォーマットって何がいいんでしょう
よく見るのはやっぱり PDF
印刷が前提ならとりあえず PDF となります
でもわざわざ印刷するような人って今の時代少ないですよね
それだとあまり PDF のメリットはないです
簡単に編集できないので誤って変更してしまうことはないですが 環境によっては扱いづらいです
あとデータを抽出して扱いたい時に PDF は相性が悪すぎます
そういうことを考えると XLSX
簡単に編集できますが 一応編集できないよう保護することもできます
保護を外せますが 外すなら意図的に変更してるのでそこは気にしてなくもいいと思います
データを抽出して扱いたい時は別のブックにデータをコピペしてそのままエクセル上で処理できます
ただ エクセルが入ってることが前提になります
最近は Office を入れてない人もいます
一応 OneDrive に保存してオンラインでエクセルを操作することはできますけど 扱いやすいとはいえないです
意外といいかもと思ったのは HTML
ダブルクリックすればブラウザで見れます
CDN のライブラリを使わなければ HTML 単体でネットに繋がっていなくても見れます
エクセルや PDF よりリッチな見た目にもできます
テキストエディタで開かないと編集はできないので誤って変更することはなさそうです
HTML 構造からデータを取り出せますし 内部でデータを JSON で持ってそれから DOM を作るようにしておけば JSON を取り出すこともできます
ただ エクセルよりは専門的な知識がいるので誰でもできるものじゃないです
最近は働きたくなさの現実逃避で色々新機能とかライブラリに触れてみたりしてたので 記事に書く予定のものが多くなりすぎて土日では処理しきれなかったです
もう少し本文を減らしたり 書く内容を厳選したりすべきですね
働きたくないでござるとか働いたら負けのネタ T シャツを着て面接に挑みたい（落ちる）
もう少し本文を減らしたり 書く内容を厳選したりすべきですね
働きたくないでござるとか働いたら負けのネタ T シャツを着て面接に挑みたい（落ちる）
semver 準拠だと 互換性がなくなる破壊的変更はメジャーアップデートで 互換性がある機能追加ならマイナーアップデートです
そういうこともあってか メジャーアップデートは破壊的変更だけを行って 機能追加はしないという方針のプロダクトもあるようです
メジャーアップデートというと 大きく変わって新機能もいっぱいで期待できるものという印象でした
互換性がなくなるデメリットはあっても それを上回る追加機能で便利になるのでコストを掛けてでも更新したいというものです
そのプロダクトとしては ◯周年みたいなものと近い感じで お祭りというかお祝いというかそういう雰囲気だと思ってました
ですが 機能追加はマイナーアップデートで行って メジャーアップデートでは非推奨機能の削除や次のマイナーアップデートのための互換性のない変更を行うだけとなると嬉しいものではないですね
むしろ嫌なもの
段階的に更新できるメリットがあるのかもしれませんが メジャーアップデートという言葉に嬉しさを感じられなくなってきて残念です
そういうこともあってか メジャーアップデートは破壊的変更だけを行って 機能追加はしないという方針のプロダクトもあるようです
メジャーアップデートというと 大きく変わって新機能もいっぱいで期待できるものという印象でした
互換性がなくなるデメリットはあっても それを上回る追加機能で便利になるのでコストを掛けてでも更新したいというものです
そのプロダクトとしては ◯周年みたいなものと近い感じで お祭りというかお祝いというかそういう雰囲気だと思ってました
ですが 機能追加はマイナーアップデートで行って メジャーアップデートでは非推奨機能の削除や次のマイナーアップデートのための互換性のない変更を行うだけとなると嬉しいものではないですね
むしろ嫌なもの
段階的に更新できるメリットがあるのかもしれませんが メジャーアップデートという言葉に嬉しさを感じられなくなってきて残念です
Chrome が勝手に Youtube や GoogleDrive のアプリ (Chrome を開くだけのリンク) を Windows PC にインストールしたようで Windows メニューの最近の追加のところに出てきていたので消しました
そのときインストール済みプログラム一覧のページに飛んだのですが リストの内容が思ってたより少なかったです
この PC はもう 1 年以上使ってるのですけど スクロールせずに収まるほど
昔はけっこうな量が並んでいたので 時代は変わったなと思います
最近は何するにもブラウザだけでほぼ終わりますからね
もしかすると ストアアプリのほうが増えてるのかも と思いもしましたが 数はありましたがデフォルトでインストールされてるもので使わないものばかりでした
今のところ自分でインストールして使ってるものはこれくらいです
ブラウザ
Chrome
テキストエディタ
VSCode
IME
Google 日本語入力
キーボードユーティリティ
AutoHotKey
アーカイバー
7-Zip
画像ビュワー
IrfanView
ペイント
Paint.NET
その他
WSL
Node.js
以前は軽量のテキストエディタとしてサクラエディタを入れてましたが PC の性能が高めでメモリも十分に余ってれば VSCode で十分かなと この PC では入れてないです
ただ VSCode はフォルダを開く概念があるので プロジェクトに属さないテキストを見たり編集したりするときは少し扱いづらくて シンプルなテキストエディタを別に入れておいてもいいかなという気はしてます
Google 日本語入力は 入れなくても標準ので大丈夫かもと思って試してみましたが 無理でした
標準のは使いづらすぎな上にいい感じの予測変換が出てきてくれません
予測変換に大きく頼ってる自分としては必須なものでした
また 「今日」 と打って日付が出たり 「zh」 で 「←」 が出たり 郵便番号から住所が出たり と言った隠し便利機能も Google 日本語入力のほうが充実してます
画像の表示は Windows10 から標準のアプリが重たくなり さらに写真向けなのかスクショみたいなものの等倍表示がきれいに表示されなかったりで微妙なんですよね
以前は Windows7 の頃のビュワーに戻してましたが それなら軽量で高機能なフリーソフトを使ったほうがいいかと思って IrfanView を入れるようになりました
Windows11 では標準のビュワーが改善されてるのでしょうか
ペイントソフトは標準のが使いづらいので昔から Paint.NET にしています
リサイズ・トリミング・フォーマットの変更くらいなら問題ないのですが 中身をいじったり色を調整したりオブジェクトを切り抜いたりしようとすると機能不足感が強いです
本体はシンプルでプラグイン任せが強いソフトで 昔は色々なプラグインがありましたが 度重なるプラグインの互換性をなくすメジャーアップデートでほとんどが使えなくなりました
Firefox の拡張機能みたいな状態ですね
追従している作者のプラグインでも新しいバージョンで動作が変わっていて求めてるのは古いバージョンだったりすることもあり 昔できていたことができなくなっていたりします
GIMP 等への乗り換えを検討中
プログラミング言語系は WSL 内に入れることが多いですが Node.js のみ Windows にも入れています
Windows 側で動かしたいことが多めなのと Node.js は PHP などより Windows/Linux の差が少なく Windows 側に入れて動かすのに抵抗が少なめです
この PC では Windows Terminal や新しい PowerShell は入れてないです
VSCode のターミナル機能があれば 勝手に落ちてる Windows Terminal はなくてもいいかなという思いで Windows Terminal は入れませんでした
PowerShell はなんだかんだ古い方で困ってないので 必要なったら入れればいいかと思って入れてないままです
そのときインストール済みプログラム一覧のページに飛んだのですが リストの内容が思ってたより少なかったです
この PC はもう 1 年以上使ってるのですけど スクロールせずに収まるほど
昔はけっこうな量が並んでいたので 時代は変わったなと思います
最近は何するにもブラウザだけでほぼ終わりますからね
もしかすると ストアアプリのほうが増えてるのかも と思いもしましたが 数はありましたがデフォルトでインストールされてるもので使わないものばかりでした
今のところ自分でインストールして使ってるものはこれくらいです
ブラウザ
Chrome
テキストエディタ
VSCode
IME
Google 日本語入力
キーボードユーティリティ
AutoHotKey
アーカイバー
7-Zip
画像ビュワー
IrfanView
ペイント
Paint.NET
その他
WSL
Node.js
以前は軽量のテキストエディタとしてサクラエディタを入れてましたが PC の性能が高めでメモリも十分に余ってれば VSCode で十分かなと この PC では入れてないです
ただ VSCode はフォルダを開く概念があるので プロジェクトに属さないテキストを見たり編集したりするときは少し扱いづらくて シンプルなテキストエディタを別に入れておいてもいいかなという気はしてます
Google 日本語入力は 入れなくても標準ので大丈夫かもと思って試してみましたが 無理でした
標準のは使いづらすぎな上にいい感じの予測変換が出てきてくれません
予測変換に大きく頼ってる自分としては必須なものでした
また 「今日」 と打って日付が出たり 「zh」 で 「←」 が出たり 郵便番号から住所が出たり と言った隠し便利機能も Google 日本語入力のほうが充実してます
画像の表示は Windows10 から標準のアプリが重たくなり さらに写真向けなのかスクショみたいなものの等倍表示がきれいに表示されなかったりで微妙なんですよね
以前は Windows7 の頃のビュワーに戻してましたが それなら軽量で高機能なフリーソフトを使ったほうがいいかと思って IrfanView を入れるようになりました
Windows11 では標準のビュワーが改善されてるのでしょうか
ペイントソフトは標準のが使いづらいので昔から Paint.NET にしています
リサイズ・トリミング・フォーマットの変更くらいなら問題ないのですが 中身をいじったり色を調整したりオブジェクトを切り抜いたりしようとすると機能不足感が強いです
本体はシンプルでプラグイン任せが強いソフトで 昔は色々なプラグインがありましたが 度重なるプラグインの互換性をなくすメジャーアップデートでほとんどが使えなくなりました
Firefox の拡張機能みたいな状態ですね
追従している作者のプラグインでも新しいバージョンで動作が変わっていて求めてるのは古いバージョンだったりすることもあり 昔できていたことができなくなっていたりします
GIMP 等への乗り換えを検討中
プログラミング言語系は WSL 内に入れることが多いですが Node.js のみ Windows にも入れています
Windows 側で動かしたいことが多めなのと Node.js は PHP などより Windows/Linux の差が少なく Windows 側に入れて動かすのに抵抗が少なめです
この PC では Windows Terminal や新しい PowerShell は入れてないです
VSCode のターミナル機能があれば 勝手に落ちてる Windows Terminal はなくてもいいかなという思いで Windows Terminal は入れませんでした
PowerShell はなんだかんだ古い方で困ってないので 必要なったら入れればいいかと思って入れてないままです
アクセスログを眺めてたときのこと 異常にアクセス数が増えてるページがあって 生のログを見てみると同じユーザーから 10 回以上の連続したリクエストが来てました
詳細を見るとリファラなしの直接アクセスみたいで UA を見ると古い Chrome (80 くらい)
クローラーとか自動でアクセスしてきてるやつで UA をそのときの Chrome に設定したままなんだねーと思ってました
そんなこともあるかーで流しておこうとしたら 一番最後だけ UA が変わってるのに気づきました
ほぼ最新の iPhone から同じページへのアクセスです
見直してみると連続アクセスは機械的にリクエストしたにしてはタイムスタンプが奇妙です
1 秒に何回もあるわけではなく数秒おきでアクセスされていました
アクセス間隔は等間隔ではなくばらつきがあります
もしかして本当に古い Chrome を使って人がアクセスしていたのでしょうか
80 だと 3 年半ほど前のバージョンなので たぶんページが正しく表示できないと思います
表示されないのをサーバー負荷などの問題と思って何度もリクエストを繰り返して 最終的に諦めて iPhone からアクセスしたということなんでしょうか
アクセス元のドメインを見るとお堅そうな日本の会社でした
割りとあり得るかもしれない……
今の時代ブラウザは自動更新されるものなのに古いバージョンに固定なんてありえないですよね
IE が消えて 世の中のページも最新機能を取り入れるところが増えているので見れないページが多くなります
インターネットに接続せず社内システムを見るために使うというならまだわかりますが こっちのサイトにアクセスしてる以上 インターネットにつながってます
古いバージョンは脆弱性のパッチも当たってないのにそれでネットしてるって セキュリティ的にどうなの？って思います
詳細を見るとリファラなしの直接アクセスみたいで UA を見ると古い Chrome (80 くらい)
クローラーとか自動でアクセスしてきてるやつで UA をそのときの Chrome に設定したままなんだねーと思ってました
そんなこともあるかーで流しておこうとしたら 一番最後だけ UA が変わってるのに気づきました
ほぼ最新の iPhone から同じページへのアクセスです
見直してみると連続アクセスは機械的にリクエストしたにしてはタイムスタンプが奇妙です
1 秒に何回もあるわけではなく数秒おきでアクセスされていました
アクセス間隔は等間隔ではなくばらつきがあります
もしかして本当に古い Chrome を使って人がアクセスしていたのでしょうか
80 だと 3 年半ほど前のバージョンなので たぶんページが正しく表示できないと思います
表示されないのをサーバー負荷などの問題と思って何度もリクエストを繰り返して 最終的に諦めて iPhone からアクセスしたということなんでしょうか
アクセス元のドメインを見るとお堅そうな日本の会社でした
割りとあり得るかもしれない……
今の時代ブラウザは自動更新されるものなのに古いバージョンに固定なんてありえないですよね
IE が消えて 世の中のページも最新機能を取り入れるところが増えているので見れないページが多くなります
インターネットに接続せず社内システムを見るために使うというならまだわかりますが こっちのサイトにアクセスしてる以上 インターネットにつながってます
古いバージョンは脆弱性のパッチも当たってないのにそれでネットしてるって セキュリティ的にどうなの？って思います
少しは涼しくなってきたし 転職活動でも再開しないとなぁとか思ってます
面倒だし考えるだけで憂鬱です（働きたくないでｇ
求人では ウチこういう技術使ってますよー とか書いてます
見てると Github を業務で使ってるところもあるようです
たしかにそういうところもあるよねー くらい思ってました
……が それに関連している ある書き込みを見かけました
個人ブログだったか Qiita みたいなプラットフォームだったか 場所まで正確に覚えてませんがこういう内容です
「ウチの会社では Github は個人アカウントを使うことにしています」
そういえば Github のアカウントは規約で複数アカウントを禁止しているから 仕事用と個人で同じのを使わないといけないという話題が何度かネットで話題になってましたね
話題に上がっても はっきりした結論はなく 問い合わせた返答で規約的にはダメというのと問題ないというのの両方あるらしくはっきりしない感じで終わってました
ググって出てきたのを見てる感じでは 仕事でも個人のを使わないといけないという主張は
「規約的にそう読める」
「（日本の？） Github で働いてる人に聞いた」
アカウントを分けて問題ないという主張は
「英語で本社に問い合わせたら問題ないと解答された」（複数あり）
のようです
問い合わせて問題ないと言われてるなら問題ないでいいと思います
普通に考えて 仕事で個人用アカウントを使うなんてありえないですし 仕事で個人のアカウントバレなんてもっとありえないです
コメントで見かけた
「アカウントを切り替えるのが面倒な人や 仕事でやったことも個人のコントリビュートにしたい人が 自分に都合良くしたいがためにそう広めてる」
というのがしっくりきました
英語圏ではそもそもこれが問題として議題に上がることもない（私が調べたわけではない）というのもこの説の信憑性感じられます
何にしても迷惑な話です
転職した先が個人アカウント使ってなんて方針だと 絶対お断りですが 事前にそういう情報がわからないというのも怖いですよね
Github を使ってるところは避けたほうが無難という気もしてきます
面倒だし考えるだけで憂鬱です（働きたくないでｇ
求人では ウチこういう技術使ってますよー とか書いてます
見てると Github を業務で使ってるところもあるようです
たしかにそういうところもあるよねー くらい思ってました
……が それに関連している ある書き込みを見かけました
個人ブログだったか Qiita みたいなプラットフォームだったか 場所まで正確に覚えてませんがこういう内容です
「ウチの会社では Github は個人アカウントを使うことにしています」
そういえば Github のアカウントは規約で複数アカウントを禁止しているから 仕事用と個人で同じのを使わないといけないという話題が何度かネットで話題になってましたね
話題に上がっても はっきりした結論はなく 問い合わせた返答で規約的にはダメというのと問題ないというのの両方あるらしくはっきりしない感じで終わってました
ググって出てきたのを見てる感じでは 仕事でも個人のを使わないといけないという主張は
「規約的にそう読める」
「（日本の？） Github で働いてる人に聞いた」
アカウントを分けて問題ないという主張は
「英語で本社に問い合わせたら問題ないと解答された」（複数あり）
のようです
問い合わせて問題ないと言われてるなら問題ないでいいと思います
普通に考えて 仕事で個人用アカウントを使うなんてありえないですし 仕事で個人のアカウントバレなんてもっとありえないです
コメントで見かけた
「アカウントを切り替えるのが面倒な人や 仕事でやったことも個人のコントリビュートにしたい人が 自分に都合良くしたいがためにそう広めてる」
というのがしっくりきました
英語圏ではそもそもこれが問題として議題に上がることもない（私が調べたわけではない）というのもこの説の信憑性感じられます
何にしても迷惑な話です
転職した先が個人アカウント使ってなんて方針だと 絶対お断りですが 事前にそういう情報がわからないというのも怖いですよね
Github を使ってるところは避けたほうが無難という気もしてきます
Short の方は短くシンプルに要点だけにしようとか思っていたはず
技術ブログ寄りな感じ
だけど振り返ると メインのブログの方の分量が少ない版みたいな状況になってます
意識しないと日記状態になるんですよね
時系列順にやったことをだらだらと書いてる感じ
理想形は 問題点や記事でやることの概要と記事全体の結論を最初に書いてから その詳細の説明や調べてる間にわかったところをまとめて書く
やってはみたけどムダだったあれこれは含めない
たぶんそんな感じ
直前の記事を書き直すならこんな感じ
VSCode のデバッグ実行時に pino からのログ出力が表示されません
原因は pino の出力方法が process.stdout.write を使うからでした
VSCode のデバッグ実行時 デフォルトでは標準出力はキャプチャされません
標準出力のキャプチャが必要な場合は launch.json を作って 「"outputCapture": "std"」 を追加する必要があります
追加する場所は configurations の各オブジェクトのトップレベルです
以下が確認用コードです
ターミナルで実行すると 3 つのログが出力されますが VSCode でデバッグ実行すると最後の CONSOLE LOG しか出ないはずです
outputCapture を設定後には 3 つとも出力されるようになります
これくらいで良いはず なんですよね
感情が入らず無機質に
この分量ならコード部分を含めなければ続きを読むボタン押さなくても全体が読めますし
でもまぁ書き始める段階で書く内容が確定してないというのも原因としてあります
上の記事なんて書く時点では 「中で pino が使われてると VSCode でログが出ない」 くらいなものでした
記事に書いてる途中で あれはどうだろう そういえばこのパターンは試してなかったとか 色々思いついて書きながら追加であれこれやっていて 書き終わるまでに解決してるというケースはけっこうあります
そんななので自然と時系列でやったことが順に書かれていく傾向があります
そんなことをしてると理想どおりにするには書き終わってからまとめ直すしかないのですが 一旦書いたら せっかく書いたのにもったいない感が出てくるのと面倒だしこれでいいかとなってきます
やっぱり私はちゃんとした文章を書くのは苦手ですね
思いついたことを適当に書いてるのがちょうどいいです
技術ブログ寄りな感じ
だけど振り返ると メインのブログの方の分量が少ない版みたいな状況になってます
意識しないと日記状態になるんですよね
時系列順にやったことをだらだらと書いてる感じ
理想形は 問題点や記事でやることの概要と記事全体の結論を最初に書いてから その詳細の説明や調べてる間にわかったところをまとめて書く
やってはみたけどムダだったあれこれは含めない
たぶんそんな感じ
直前の記事を書き直すならこんな感じ
VSCode のデバッグ実行時に pino からのログ出力が表示されません
原因は pino の出力方法が process.stdout.write を使うからでした
VSCode のデバッグ実行時 デフォルトでは標準出力はキャプチャされません
標準出力のキャプチャが必要な場合は launch.json を作って 「"outputCapture": "std"」 を追加する必要があります
追加する場所は configurations の各オブジェクトのトップレベルです
以下が確認用コードです
ターミナルで実行すると 3 つのログが出力されますが VSCode でデバッグ実行すると最後の CONSOLE LOG しか出ないはずです
outputCapture を設定後には 3 つとも出力されるようになります
const pino = require("pino")
const logger = pino({ level: "info" })
logger.info("PINO LOG")
process.stdout.write("STDOUT LOG\n")
console.log("CONSOLE LOG")
これくらいで良いはず なんですよね
感情が入らず無機質に
この分量ならコード部分を含めなければ続きを読むボタン押さなくても全体が読めますし
でもまぁ書き始める段階で書く内容が確定してないというのも原因としてあります
上の記事なんて書く時点では 「中で pino が使われてると VSCode でログが出ない」 くらいなものでした
記事に書いてる途中で あれはどうだろう そういえばこのパターンは試してなかったとか 色々思いついて書きながら追加であれこれやっていて 書き終わるまでに解決してるというケースはけっこうあります
そんななので自然と時系列でやったことが順に書かれていく傾向があります
そんなことをしてると理想どおりにするには書き終わってからまとめ直すしかないのですが 一旦書いたら せっかく書いたのにもったいない感が出てくるのと面倒だしこれでいいかとなってきます
やっぱり私はちゃんとした文章を書くのは苦手ですね
思いついたことを適当に書いてるのがちょうどいいです
TypeScript が使われてるところが相変わらず増えてるなぁと思いながら ふとサーバーサイドって何使ってるんだろうと思いました
やっぱり Node.js なのでしょうか
Deno は TypeScript をサポートしているので TypeScript ユーザーは積極的に移行して Deno が流行るのかなと思ったこともありましたけど 最近はあまり流行ってないようです
そもそも Deno という名前を目にする機会がほぼないです
Deno が npm をサポートしてしまってからはどんどん注目されなくなりつつあるとか聞いたこともあります
たしかに私自身 npm をサポートしたあたりであまり興味がなくなってきましたし
npm を捨てて完全に新しいものという点で興味があったのに 結局 npm を使うなら Node.js でいいやと言う感じです
ライブラリ作者視点でも npm に登録しておけば Node.js からも Deno からも使えるならとりあえず npm に登録となって ユーザーも npm で使えるなら Node.js のままという感じでしょうか
私の場合は TypeScript を使わないので Node.js のままでも全然問題ないですが TypeScript を使う人の場合は変換のひと手間が必要になるので 新規に TypeScript で何かを作るときは Deno にしてもいいと思うのですけどね
TypeScript の普及に比べて Deno があまり普及してないように思うので 何を使ってるのかなと疑問に思いました
ただ TypeScript/JavaScript の記事を思い出してもサーバーサイドとして使ってるのをあまり見ない気もします
みんな基本はフロントのみで Vite や Next.js みたいな既存ツールを使うためだけに使っていて サーバーサイドにはそもそも TypeScript/JavaScript を使ってないのかもしれません
そういう用途だけなら Node.js でパッケージを入れて実行するだけでいいですし
やっぱり Node.js なのでしょうか
Deno は TypeScript をサポートしているので TypeScript ユーザーは積極的に移行して Deno が流行るのかなと思ったこともありましたけど 最近はあまり流行ってないようです
そもそも Deno という名前を目にする機会がほぼないです
Deno が npm をサポートしてしまってからはどんどん注目されなくなりつつあるとか聞いたこともあります
たしかに私自身 npm をサポートしたあたりであまり興味がなくなってきましたし
npm を捨てて完全に新しいものという点で興味があったのに 結局 npm を使うなら Node.js でいいやと言う感じです
ライブラリ作者視点でも npm に登録しておけば Node.js からも Deno からも使えるならとりあえず npm に登録となって ユーザーも npm で使えるなら Node.js のままという感じでしょうか
私の場合は TypeScript を使わないので Node.js のままでも全然問題ないですが TypeScript を使う人の場合は変換のひと手間が必要になるので 新規に TypeScript で何かを作るときは Deno にしてもいいと思うのですけどね
TypeScript の普及に比べて Deno があまり普及してないように思うので 何を使ってるのかなと疑問に思いました
ただ TypeScript/JavaScript の記事を思い出してもサーバーサイドとして使ってるのをあまり見ない気もします
みんな基本はフロントのみで Vite や Next.js みたいな既存ツールを使うためだけに使っていて サーバーサイドにはそもそも TypeScript/JavaScript を使ってないのかもしれません
そういう用途だけなら Node.js でパッケージを入れて実行するだけでいいですし
Twitter が急に名前とロゴを変えるといって X になったらしいですね
会社名は以前から X だったらしいですけどサービスやアイコンまで変わるとは
会社名でもある X なので以前のおふざけの柴犬と違って正式な変更になりそうです
URL まで変わると過去に作った Twitter の URL 扱うものの変更が必要そうで面倒
ところでこのアイコンどこかで見覚えあるなーと思って考えたら x11 でした
X というアルファベット 1 文字なので大体似てそうには思いますが 左上から右下への線だけ太いというのは割と特徴的だと思うのです
見比べると X は太い方の線の中が抜けてて x11 は右上から左下への線が交わるところで微妙にずれてるみたい
会社名は以前から X だったらしいですけどサービスやアイコンまで変わるとは
会社名でもある X なので以前のおふざけの柴犬と違って正式な変更になりそうです
URL まで変わると過去に作った Twitter の URL 扱うものの変更が必要そうで面倒
ところでこのアイコンどこかで見覚えあるなーと思って考えたら x11 でした
X というアルファベット 1 文字なので大体似てそうには思いますが 左上から右下への線だけ太いというのは割と特徴的だと思うのです
見比べると X は太い方の線の中が抜けてて x11 は右上から左下への線が交わるところで微妙にずれてるみたい
最近はこれを作りたいというのもないです
作るものありきではなく ただ言語やライブラリ等を使うだけとしてもあんまりこれといった変化がなく興味が出てきません
主に JavaScript ですが 最近って大きな変化無いですよね
Polyfill できるレベルの機能追加はありましたが 構文が変わるレベルではないので 変化を感じません
期待してる機能は色々ありますがどれも Proposal のステージは昔から変わらず近いうちになにかあるようには見えません
むしろ以前から使えていた Import Assertion が仕様変更で記法が変わるなどネガティブな変更があったくらいです
ブラウザでいえば CSS で CSS Nesting が使えるようになったのはとても大きなことだと思います
ただこれも PostCSS や CSS-in-JS 等でこれまでも使えていただけあって だから何をしようと思うわけでもないです
そういったものを準備しないような使い捨ての HTML ファイルに直接書くときに楽になったなくらいです
言語標準機能以外でライブラリを見ても 最近ってサーバー側もクライアント側も昔ほどフレームワーク戦争的なものはないです
落ち着いてきて各自好みのものを使うくらいです
Vue は Composition API には興味あったものの テンプレートが相変わらず好みに合わず React でいいかなとなり lit や Solid は周辺ライブラリ的に React でいいかなとなり 当の React は最近は SSR とかサーバーサイドコンポーネントとかそういうのに力を入れてるようです
新しいドキュメントの推奨の開始方法で CRA がなくなって Next.js を推してるくらいです
SSR 不要派でサーバー側にまで React を持っていきたくない自分としては全く興味がない話です
その他ライブラリでもあちこちで TypeScript の話ばかりみかけますし ウェブの記事でも TypeScript 記事が多いです
嫌気が差します
たまにはブラウザから離れようかなと思っても 他って UI を作るのがかなり面倒だったり自由度が少なかったりです
.NET 系では以前は WinForms や WPF の頃に作っていて 今だと WinUI というのがあります
ドキュメントでもデスクトップアプリ開発でまずこれがでてきて WPF 等はその他の方法として出てくるレガシーぽい扱いになってそうです
少し興味は持ったものの Windows でも Electron を始め Web の機能で UI を作れてるのにわざわざ面倒なものを使おうって気があまり起きないです
以前気になっていた Flutter ですが これもやっぱり Dart がつらくて実際に書こうとは思えなかったです
個人的に JavaScript の構文は C 系でありながらもその不満なところの多くを改善したものだと思ってるので JavaScript をさらに C に近づけた構文の Dart は見ていて常に不満を感じるレベルでした
型の考え方とかを TypeScript と比べるとかそういう段階までもいかなかったです
あと Mac は持ってないので iOS 用ビルドはできず Android はかなり古い端末しかもってなくて 結局 Web 用ビルドしか使うことがなくてなんで Flutter を使ってるの？となりそうです
そんな感じなので最近はたいして何もしてなくブログ記事数も少なめです
今月で今年も半年がすぎるのにメインの方では 12 記事で こっちの短め記事も 50 記事未満です
無理してなにかする必要もないので やりたいことが出てくるまでしばらくは更新をサボろうかな
作るものありきではなく ただ言語やライブラリ等を使うだけとしてもあんまりこれといった変化がなく興味が出てきません
主に JavaScript ですが 最近って大きな変化無いですよね
Polyfill できるレベルの機能追加はありましたが 構文が変わるレベルではないので 変化を感じません
期待してる機能は色々ありますがどれも Proposal のステージは昔から変わらず近いうちになにかあるようには見えません
むしろ以前から使えていた Import Assertion が仕様変更で記法が変わるなどネガティブな変更があったくらいです
ブラウザでいえば CSS で CSS Nesting が使えるようになったのはとても大きなことだと思います
ただこれも PostCSS や CSS-in-JS 等でこれまでも使えていただけあって だから何をしようと思うわけでもないです
そういったものを準備しないような使い捨ての HTML ファイルに直接書くときに楽になったなくらいです
言語標準機能以外でライブラリを見ても 最近ってサーバー側もクライアント側も昔ほどフレームワーク戦争的なものはないです
落ち着いてきて各自好みのものを使うくらいです
Vue は Composition API には興味あったものの テンプレートが相変わらず好みに合わず React でいいかなとなり lit や Solid は周辺ライブラリ的に React でいいかなとなり 当の React は最近は SSR とかサーバーサイドコンポーネントとかそういうのに力を入れてるようです
新しいドキュメントの推奨の開始方法で CRA がなくなって Next.js を推してるくらいです
SSR 不要派でサーバー側にまで React を持っていきたくない自分としては全く興味がない話です
その他ライブラリでもあちこちで TypeScript の話ばかりみかけますし ウェブの記事でも TypeScript 記事が多いです
嫌気が差します
たまにはブラウザから離れようかなと思っても 他って UI を作るのがかなり面倒だったり自由度が少なかったりです
.NET 系では以前は WinForms や WPF の頃に作っていて 今だと WinUI というのがあります
ドキュメントでもデスクトップアプリ開発でまずこれがでてきて WPF 等はその他の方法として出てくるレガシーぽい扱いになってそうです
少し興味は持ったものの Windows でも Electron を始め Web の機能で UI を作れてるのにわざわざ面倒なものを使おうって気があまり起きないです
以前気になっていた Flutter ですが これもやっぱり Dart がつらくて実際に書こうとは思えなかったです
個人的に JavaScript の構文は C 系でありながらもその不満なところの多くを改善したものだと思ってるので JavaScript をさらに C に近づけた構文の Dart は見ていて常に不満を感じるレベルでした
型の考え方とかを TypeScript と比べるとかそういう段階までもいかなかったです
あと Mac は持ってないので iOS 用ビルドはできず Android はかなり古い端末しかもってなくて 結局 Web 用ビルドしか使うことがなくてなんで Flutter を使ってるの？となりそうです
そんな感じなので最近はたいして何もしてなくブログ記事数も少なめです
今月で今年も半年がすぎるのにメインの方では 12 記事で こっちの短め記事も 50 記事未満です
無理してなにかする必要もないので やりたいことが出てくるまでしばらくは更新をサボろうかな
新年あけましておめでとうございます
去年はメインの方のブログは記事少なめで こっちの Short が多めだったと思います
ムダに長文になっても後から探すときに自分でも面倒なのでこんな感じでいいかなと思ってます
ただ 去年はあんまり新しいものには触れてなかったなーという気はしています
いつものほぼ変わりがない感じです
ブラウザ周りでは React の使用率が一番高くなってた気がします
すでに別記事で書いてますが それ故に不満度も上がってなにか別のにしたいとも思ってます
そもそも JavaScript 界隈が最近はあまり変化してない気がしますね
最近は新機能があまり入っていませんし 特に ES2015 や async/await みたいな構文に大きな変化がある提案はずっと Stage1, 2 のままです
Stage3 では期待しているものもありますが まだブラウザには実装されていません
ECMAScript 以外のブラウザ機能もあまりこれといったのがないです
見かける話題も JavaScript やブラウザ機能というよりはサードパーティライブラリがほとんどです
特に TypeScript による侵食がひどすぎて ライブラリや記事を見るときに TypeScript が多すぎて嫌になります
あとは SSR 前提フレームワークだったり クラウドというか CDN 関係の話とかあまり自分とは関係なく興味ないのが多めです
いっそのこと他言語始めて見るのもありかなーと思ってたりもします
TypeScript のおかげで再確認できたのはやっぱり動的言語は良いです
ただ JavaScript/PHP/Python と有名どころはすでに使っています
他だと Ruby/Perl/Lua/PowerShell 等でしょうか
PowerShell は一応使ってると言っていいのかもしれません
モジュール化とか高度な機能は使ってないですが ちょっとした bat ファイル代わりのスクリプト程度には使っています
Lua は昔軽く使ってみましたが 使うところがなさすぎて全然使っていません
以前はプラグイン用言語として使われているのを見ることがあったのですが 今だと JavaScript などのほうが多い気がします
Perl は 6 が raku に改名したり 5 の延長である 7 を出す予定とか以前言っていたのに未だに出てなかったりでよくわからない状態になってます
過去に使ってた人ならともかく新規に使い始めるような言語ではない気もします
Ruby も似たようなものかもですが Perl よりはマシな気はしています
ただ最近だと PHP, Python に比べると人気は劣ってる気はしますし RoR もあまり聞かなくなりましたし デフォルトでインストールされてるものでもないので使い所があまりない気がしています
そんな感じで結局去年はこの辺は触れてきてないんですよね
やっぱりそれを使って作りたいものがあってこそでしょうね
という点だと Rust でしょうか
Electron アプリを年に 1 回あるかどうかくらいで更新しているのですが 破壊的変更が多すぎて対応が面倒です
Electron みたいな特殊なことをせずシンプルに OS の WebView を使うらしい Tauri だとこの辺は楽になったりしないかなと期待していつか移行してみようと思ってます
ただ WebView だけで完結しないので ファイルアクセスなどのバックエンド部分は Rust で書かないといけないみたいです
あとは Flutter です
Windows 対応もしたとかでここ最近では目にする機会が増えてます
最近は Windows 開発でも WinUI みたいな新しいのがあるようですが WinForms にしても WPF にしても使いやすいとはいえないものだったので そこまで期待してないです
こういう別手段があるならそっちを試してみたいなというところです
それに以前は不満に感じていた Dart ですが TypeScript を触れてみるともしかしていいものでは？と考え始めました
TypeScript は JavaScript の互換性にこだわるあまり中途半端な微妙なものになっています
そもそも JavaScript は静的型付け言語として作られてないのですから 型をつけるならそれに合わせて変えるべき部分はありますが JavaScript のスーパーセットであることにこだわっているので不足や制限が多くなり不満点が目立ちます
特にウェブ互換性のために残っているおかしな仕様などはなくしてしまうなどしてほしいのにそれができていません
Dart の場合は JavaScript を改善するのが目的で JavaScript に似ていますが TypeScript ほど互換性重視はしていません
変数宣言や引数・返り値の型の書き方が C に寄りすぎていて この点では TypeScript の方が好みということもあり あまり細かいところは見ずに全体的なコードの構文を見て Dart は使おうとは思わない と思っていました
ですが TypeScript で多くの不満を感じたあとなら良いところが多く感じられるかもと期待しています
世間的には Dart より TypeScript の方が優れていると言ってる人が多そうですが 本当にそうであれば Flutter の言語を TypeScript に切り替えるとかいう話が出ても良さそうなのに Dart3 という新しいバージョンを出す予定というニュースも見かけましたし TypeScript とは別の方向の言語として進んでいくのでしょう
あとこれまで不満に感じていた UI の記法ですが XML より JSON の方がいいという点では HTML に合わせなくてもいいのではということで JSX 的なものがないのは別にいいのかなと感じているので 今年使ってみようかな度が一番高いものかもしれません
去年はメインの方のブログは記事少なめで こっちの Short が多めだったと思います
ムダに長文になっても後から探すときに自分でも面倒なのでこんな感じでいいかなと思ってます
ただ 去年はあんまり新しいものには触れてなかったなーという気はしています
いつものほぼ変わりがない感じです
ブラウザ周りでは React の使用率が一番高くなってた気がします
すでに別記事で書いてますが それ故に不満度も上がってなにか別のにしたいとも思ってます
そもそも JavaScript 界隈が最近はあまり変化してない気がしますね
最近は新機能があまり入っていませんし 特に ES2015 や async/await みたいな構文に大きな変化がある提案はずっと Stage1, 2 のままです
Stage3 では期待しているものもありますが まだブラウザには実装されていません
ECMAScript 以外のブラウザ機能もあまりこれといったのがないです
見かける話題も JavaScript やブラウザ機能というよりはサードパーティライブラリがほとんどです
特に TypeScript による侵食がひどすぎて ライブラリや記事を見るときに TypeScript が多すぎて嫌になります
あとは SSR 前提フレームワークだったり クラウドというか CDN 関係の話とかあまり自分とは関係なく興味ないのが多めです
いっそのこと他言語始めて見るのもありかなーと思ってたりもします
TypeScript のおかげで再確認できたのはやっぱり動的言語は良いです
ただ JavaScript/PHP/Python と有名どころはすでに使っています
他だと Ruby/Perl/Lua/PowerShell 等でしょうか
PowerShell は一応使ってると言っていいのかもしれません
モジュール化とか高度な機能は使ってないですが ちょっとした bat ファイル代わりのスクリプト程度には使っています
Lua は昔軽く使ってみましたが 使うところがなさすぎて全然使っていません
以前はプラグイン用言語として使われているのを見ることがあったのですが 今だと JavaScript などのほうが多い気がします
Perl は 6 が raku に改名したり 5 の延長である 7 を出す予定とか以前言っていたのに未だに出てなかったりでよくわからない状態になってます
過去に使ってた人ならともかく新規に使い始めるような言語ではない気もします
Ruby も似たようなものかもですが Perl よりはマシな気はしています
ただ最近だと PHP, Python に比べると人気は劣ってる気はしますし RoR もあまり聞かなくなりましたし デフォルトでインストールされてるものでもないので使い所があまりない気がしています
そんな感じで結局去年はこの辺は触れてきてないんですよね
やっぱりそれを使って作りたいものがあってこそでしょうね
という点だと Rust でしょうか
Electron アプリを年に 1 回あるかどうかくらいで更新しているのですが 破壊的変更が多すぎて対応が面倒です
Electron みたいな特殊なことをせずシンプルに OS の WebView を使うらしい Tauri だとこの辺は楽になったりしないかなと期待していつか移行してみようと思ってます
ただ WebView だけで完結しないので ファイルアクセスなどのバックエンド部分は Rust で書かないといけないみたいです
あとは Flutter です
Windows 対応もしたとかでここ最近では目にする機会が増えてます
最近は Windows 開発でも WinUI みたいな新しいのがあるようですが WinForms にしても WPF にしても使いやすいとはいえないものだったので そこまで期待してないです
こういう別手段があるならそっちを試してみたいなというところです
それに以前は不満に感じていた Dart ですが TypeScript を触れてみるともしかしていいものでは？と考え始めました
TypeScript は JavaScript の互換性にこだわるあまり中途半端な微妙なものになっています
そもそも JavaScript は静的型付け言語として作られてないのですから 型をつけるならそれに合わせて変えるべき部分はありますが JavaScript のスーパーセットであることにこだわっているので不足や制限が多くなり不満点が目立ちます
特にウェブ互換性のために残っているおかしな仕様などはなくしてしまうなどしてほしいのにそれができていません
Dart の場合は JavaScript を改善するのが目的で JavaScript に似ていますが TypeScript ほど互換性重視はしていません
変数宣言や引数・返り値の型の書き方が C に寄りすぎていて この点では TypeScript の方が好みということもあり あまり細かいところは見ずに全体的なコードの構文を見て Dart は使おうとは思わない と思っていました
ですが TypeScript で多くの不満を感じたあとなら良いところが多く感じられるかもと期待しています
世間的には Dart より TypeScript の方が優れていると言ってる人が多そうですが 本当にそうであれば Flutter の言語を TypeScript に切り替えるとかいう話が出ても良さそうなのに Dart3 という新しいバージョンを出す予定というニュースも見かけましたし TypeScript とは別の方向の言語として進んでいくのでしょう
あとこれまで不満に感じていた UI の記法ですが XML より JSON の方がいいという点では HTML に合わせなくてもいいのではということで JSX 的なものがないのは別にいいのかなと感じているので 今年使ってみようかな度が一番高いものかもしれません
「Safari 15.6」 で Bingる(?) と 15.6 インチのノート PC とか出てきて Safari は出てこない
下の方にスクロールするとやっと出てくる
関係ないノート PC は何なのと思ったら広告らしい
小さく書かれてる
なんで検索結果の最初に見える画面全体が広告だけで埋まってるの
しかも広告の文字が Google よりもわかりづらいし
下の方にスクロールするとやっと出てくる
関係ないノート PC は何なのと思ったら広告らしい
小さく書かれてる
なんで検索結果の最初に見える画面全体が広告だけで埋まってるの
しかも広告の文字が Google よりもわかりづらいし
プロジェクト内で共有する設定ファイルの階層で迷います
設定ファイルを使うものは ウェブサーバーだったり 手動実行するスクリプトや常駐するツールなどです
ここでは app1, app2, ... とします
設定する内容は色々ありますが仮に logger の設定と database の設定とします
みたいに logger や database を外側に書いて app1 や app2 を内側に書くのがひとつです
もうひとつは反対に app1 や app2 を外側に書いて logger や database を内側に書きます
どっちにしようかよく悩むんですよね
外側にある方はトップレベルのキーを見るだけでいいので一覧がすぐわかります
例えば database などが外側だと app1 は内側です
app は何種類あるのかを探すときに各ブロックを見ていくことになり少し手間です
上の例だと database にも logger にも app1 と app2 となっていて 内側のキーは一緒ですが app2 が database を使わないなら database のオブジェクトに app2 キーは存在しなくなります
なので 1 つ目を見るだけでは app が何種類あるかを判断できず logger など他のすべての外側のオブジェクトを見る必要があります
その点では アプリケーションの種類を一覧したいなら app1 などを外側に出すといいです
ただ使うツール・サービスの方も一覧で見たいことがあります
メールを使うものあったっけと思ったときに外側のキーだけを見て無いなとわかります
なのでどっちもどっちなんですよね
外側でグループされた内側の一覧も考えてみます
app1 が外側だと app1 で使うツール・サービスを一覧できるので app1 は database と logger を使うんだ というのがわかりやすいといえます
ただ database を使うのはどれなのか 使う場合の host をまとめて見たい という視点だと database が外側にあって database でグループ化されてるほうが見やすいです
やっぱりどっちという決め手にならないんですよね
それにこれらは見るときの都合です
ちょっとしたスクリプトを書けば階層を展開してフラットにしてフィルタやソートができますし そこまでこだわるほどでもない気がします
各アプリケーションが設定を保持することを考えると トップレベルにある自身の名前空間だけを取得して残りは捨てれる app1 を外側に持ってくるパターンの方がいいのかもしれません
その考えで言えば最初から設定ファイルはアプリケーションごとに作ればとも思えてきます
でもそれをまとめている理由は共通部分があるからのはずです
データベースは全部共通だったり データベースやスキーマは別でもホストは共通とかあります
共通部分を外側の database として書いて 個別に違うところだけを app1 みたいなキーも用意して書いてみると
外側にキーが混ざるのでネストする形にすると
量は少なくなって共通部分と差分という形はわかりますが 脳内でマージしないといけないので本当に見やすいのか疑問です
脳内に限らず実際に使うときも差分形を解決して一つのオブジェクトにする必要があります
それなら冗長でも最初のような形のほうが良かった気がします
同じ設定を繰り返すので変更時に複数箇所の変更が必要になりますが 一括置換できますし JavaScript で作るオブジェクトなので変わりそうなら変数に入れておくこともできます
となると 最初に戻るわけですが どっちにするか悩みます
設定ファイルを使うものは ウェブサーバーだったり 手動実行するスクリプトや常駐するツールなどです
ここでは app1, app2, ... とします
設定する内容は色々ありますが仮に logger の設定と database の設定とします
export default {
logger: {
app1: {
path: "/path/to/log-file1",
},
app2: {
path: "/path/to/log-file2",
},
},
database: {
app1: {
host: "localhost",
user: "user1",
database: "app1",
password: "pw",
},
app2: {
host: "localhost",
user: "user2",
database: "app2",
password: "pw",
}
}
}
みたいに logger や database を外側に書いて app1 や app2 を内側に書くのがひとつです
もうひとつは反対に app1 や app2 を外側に書いて logger や database を内側に書きます
export default {
app1: {
logger: {
path: "/path/to/log-file1",
},
database: {
host: "localhost",
user: "user1",
database: "app1",
password: "pw",
},
},
app2: {
logger: {
path: "/path/to/log-file2",
},
database: {
host: "localhost",
user: "user2",
database: "app2",
password: "pw",
},
},
}
どっちにしようかよく悩むんですよね
外側にある方はトップレベルのキーを見るだけでいいので一覧がすぐわかります
例えば database などが外側だと app1 は内側です
app は何種類あるのかを探すときに各ブロックを見ていくことになり少し手間です
上の例だと database にも logger にも app1 と app2 となっていて 内側のキーは一緒ですが app2 が database を使わないなら database のオブジェクトに app2 キーは存在しなくなります
なので 1 つ目を見るだけでは app が何種類あるかを判断できず logger など他のすべての外側のオブジェクトを見る必要があります
その点では アプリケーションの種類を一覧したいなら app1 などを外側に出すといいです
ただ使うツール・サービスの方も一覧で見たいことがあります
メールを使うものあったっけと思ったときに外側のキーだけを見て無いなとわかります
なのでどっちもどっちなんですよね
外側でグループされた内側の一覧も考えてみます
app1 が外側だと app1 で使うツール・サービスを一覧できるので app1 は database と logger を使うんだ というのがわかりやすいといえます
ただ database を使うのはどれなのか 使う場合の host をまとめて見たい という視点だと database が外側にあって database でグループ化されてるほうが見やすいです
やっぱりどっちという決め手にならないんですよね
それにこれらは見るときの都合です
ちょっとしたスクリプトを書けば階層を展開してフラットにしてフィルタやソートができますし そこまでこだわるほどでもない気がします
各アプリケーションが設定を保持することを考えると トップレベルにある自身の名前空間だけを取得して残りは捨てれる app1 を外側に持ってくるパターンの方がいいのかもしれません
その考えで言えば最初から設定ファイルはアプリケーションごとに作ればとも思えてきます
でもそれをまとめている理由は共通部分があるからのはずです
データベースは全部共通だったり データベースやスキーマは別でもホストは共通とかあります
共通部分を外側の database として書いて 個別に違うところだけを app1 みたいなキーも用意して書いてみると
export default {
database: {
host: "localhost",
user: "user1",
database: "app1",
password: "pw",
},
app1: {
// 共通と一緒
},
app2: {
database: {
// データベースだけ違う
database: "app2",
},
},
}
外側にキーが混ざるのでネストする形にすると
export default {
database: {
host: "localhost",
user: "user1",
database: "app1",
password: "pw",
app2: {
database: "app2",
},
},
}
量は少なくなって共通部分と差分という形はわかりますが 脳内でマージしないといけないので本当に見やすいのか疑問です
脳内に限らず実際に使うときも差分形を解決して一つのオブジェクトにする必要があります
それなら冗長でも最初のような形のほうが良かった気がします
同じ設定を繰り返すので変更時に複数箇所の変更が必要になりますが 一括置換できますし JavaScript で作るオブジェクトなので変わりそうなら変数に入れておくこともできます
となると 最初に戻るわけですが どっちにするか悩みます
デフォルトで開くくらいのウィンドウサイズで拡張機能設定画面を見ると
Array や RegExp や Error など 昔からあるものには new があってもなくてもいいものがあります
オブジェクトを作るときはとりあえず new
という感じで書いてましたが new ってけっこう邪魔です
単項演算子ではあるもののスペースで離れてる分 ! や + と違って 複雑な式の中に入っていると読みづらいケースがあります
この点は await も同様ですがこっちは非同期化して Promise を待機するという重要な意味があります
それに対して new はなくてもいいものです
普通に関数を呼び出してオブジェクトが返ってくることも当たり前なので new をつける必要は特に無いです
内部的に this の扱い方の違いとかがあるものの 内部で完結可能で使う側に new を強制させる理由はないです
以前はプロジェクト内のファイル全検索時にインスタンス作成箇所がわかりやすい？とかも考えましたが 普通に関数呼び出しを探せばいいのであまり効果はなかったです
むしろ new の後に改行しても構文的には問題ないので探しづらくなっています
あと Number 等のプリミティブ型で new を使うとオブジェクトとして受け取るので これらは new を使うべきではないです
そうなると Number 等だけを例外として考えないといけなくなります
そんな事を考えずとりあえず共通で new なしで呼び出せるほうが良いです
ライブラリでも new が必要かどうかはそれぞれバラバラです
これはいるこれはいらないなんて考える必要もないように 全部 new なしのほうが優れていると思います
ということで new を使わないようにしようと思って書いてみましたが class 構文を使われたものでは new が必須とされていました
そういえばそんな仕様あったっけ
余計なことしなくていいのに
どうせなら Python のような new を使わない言語に合わせてくれればよかったのに
最低限自分の作る分は new を要求しないようにするためこういう風にラップしました
オブジェクトを作るときはとりあえず new
という感じで書いてましたが new ってけっこう邪魔です
単項演算子ではあるもののスペースで離れてる分 ! や + と違って 複雑な式の中に入っていると読みづらいケースがあります
この点は await も同様ですがこっちは非同期化して Promise を待機するという重要な意味があります
それに対して new はなくてもいいものです
普通に関数を呼び出してオブジェクトが返ってくることも当たり前なので new をつける必要は特に無いです
内部的に this の扱い方の違いとかがあるものの 内部で完結可能で使う側に new を強制させる理由はないです
以前はプロジェクト内のファイル全検索時にインスタンス作成箇所がわかりやすい？とかも考えましたが 普通に関数呼び出しを探せばいいのであまり効果はなかったです
むしろ new の後に改行しても構文的には問題ないので探しづらくなっています
あと Number 等のプリミティブ型で new を使うとオブジェクトとして受け取るので これらは new を使うべきではないです
そうなると Number 等だけを例外として考えないといけなくなります
そんな事を考えずとりあえず共通で new なしで呼び出せるほうが良いです
ライブラリでも new が必要かどうかはそれぞれバラバラです
これはいるこれはいらないなんて考える必要もないように 全部 new なしのほうが優れていると思います
ということで new を使わないようにしようと思って書いてみましたが class 構文を使われたものでは new が必須とされていました
class A {
a = 1
}
A()
// TypeError: Class constructor A cannot be invoked without 'new'
そういえばそんな仕様あったっけ
余計なことしなくていいのに
どうせなら Python のような new を使わない言語に合わせてくれればよかったのに
最低限自分の作る分は new を要求しないようにするためこういう風にラップしました
//// [A.js] ////
class A {
a = 1
}
export default function() { return new A() }
//// [index.js] ////
import A from "./A.js"
console.log(A())
// A {a: 1}
console.log(new A())
// A {a: 1}
JavaScript で if が文なせいで困ることは多いのですが do 式は一向に進展しないです
if がそのまま式化するだけでもいいし パターンマッチングでもいいのでとりあえず const 前提で書くときの不便をなくしてほしいものです
今回不満に感じたもの
bar の場合は必ず x に値が入るけど foo の場合は options によっては null/undefined になるかもしれない
x に代入後に !x の場合に foo のオプションがおかしいってエラーを起こしてる
bar の場合は関係ないので use_foo が true の場合の式中に書きたい
if が式なら なんの問題もない
アロー関数の即時実行は書きづらいし見づらいから使うのは控えめにしたい
かと言ってこういうのをつくってみては 使いやすいとも言いづらく結局使わない
最近は PHP でも match 式が使えたり色々進化してるのに最近の JavaScript はあまり新機能もなくて勢いが落ちてる気がする
周辺ツールも Rust などにいって WebAssembly が増えてるし そういうのに移行していくことになるのかな
if がそのまま式化するだけでもいいし パターンマッチングでもいいのでとりあえず const 前提で書くときの不便をなくしてほしいものです
今回不満に感じたもの
const x = use_foo
? foo(options)
: bar(options)
if (!x) {
throw new Error("error: foo options")
}
bar の場合は必ず x に値が入るけど foo の場合は options によっては null/undefined になるかもしれない
x に代入後に !x の場合に foo のオプションがおかしいってエラーを起こしてる
bar の場合は関係ないので use_foo が true の場合の式中に書きたい
if が式なら なんの問題もない
const x = (
if (use_foo) {
const foo_value = foo(options)
if (!foo_value) {
throw new Error("error: foo options")
}
foo_value
} else {
bar(options)
}
)
アロー関数の即時実行は書きづらいし見づらいから使うのは控えめにしたい
かと言ってこういうのをつくってみては 使いやすいとも言いづらく結局使わない
const x = use_foo
? conditional(
foo(options), v => v,
v => v,
v => {new Error("error: foo options")}
)
: bar(options)
最近は PHP でも match 式が使えたり色々進化してるのに最近の JavaScript はあまり新機能もなくて勢いが落ちてる気がする
周辺ツールも Rust などにいって WebAssembly が増えてるし そういうのに移行していくことになるのかな
IE がサポート終了してもう 3 週間くらいになるので IE を起動したら Edge が起動するんだろうなーと思いながら起動したら普通に IE が起動した
IE のタブで Edge のホームページが開かれるだけ
強制的に Edge が開くようになるんじゃなかったの？
PC は Windows 10 で Windows Update して再起動済み
他の PC でも試したけど同じみたい
これだと気にせず使い続けてる人も多そう
IE のタブで Edge のホームページが開かれるだけ
強制的に Edge が開くようになるんじゃなかったの？
PC は Windows 10 で Windows Update して再起動済み
他の PC でも試したけど同じみたい
これだと気にせず使い続けてる人も多そう
repository はリポジトリと読んでます
ネットでレポジトリと書いてる人を見かけました
どっちでも良さそうな部分ですが なんか違和感
と思ったのも束の間
いつもどっちで書いてたっけ？と心配になるくらいレポジトリも自然に見えてきました
そもそもどっちが一般的なんでしょうか
re は基本 リ と読みたいですが re から始まる英単語を思い浮かべると 繰り返しの意味の re をプレフィックスとしている retry, remind, react, rename などは リ でそれ以外で re から始まる render, rest, rectangle, replica などは レ です
もしかしてプレフィックスの re かどうかで分かれるの？
それなら repository は レ ？
とりあえずググってみます
Wikipedia ではリポジトリでした
https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA
「リポジトリまたはレポジトリ」と記載されていて リポジトリの方が主です
ページタイトルや本文中は リ になっています
また Google 検索結果のヒット数を見てみると
"リポジトリ" → 約 9,190,000 件
"レポジトリ" → 約 607,000 件
圧倒的にリポジトリです
リポジトリ読みの方が一般的のようですね
ネットでレポジトリと書いてる人を見かけました
どっちでも良さそうな部分ですが なんか違和感
と思ったのも束の間
いつもどっちで書いてたっけ？と心配になるくらいレポジトリも自然に見えてきました
そもそもどっちが一般的なんでしょうか
re は基本 リ と読みたいですが re から始まる英単語を思い浮かべると 繰り返しの意味の re をプレフィックスとしている retry, remind, react, rename などは リ でそれ以外で re から始まる render, rest, rectangle, replica などは レ です
もしかしてプレフィックスの re かどうかで分かれるの？
それなら repository は レ ？
とりあえずググってみます
Wikipedia ではリポジトリでした
https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA
「リポジトリまたはレポジトリ」と記載されていて リポジトリの方が主です
ページタイトルや本文中は リ になっています
また Google 検索結果のヒット数を見てみると
"リポジトリ" → 約 9,190,000 件
"レポジトリ" → 約 607,000 件
圧倒的にリポジトリです
リポジトリ読みの方が一般的のようですね
最近 Next.js を使ってるという話を見かけることが以前より増えてる気がします
昔使ったときはあまり使ってみようと思えるものでもなく使いやすくもなく Nuxt.js のほうが良い印象でした
なんというか悪い意味での企業がやってるツールって感じだったのですよね
コミュニティがやってる OSS に比べて製品ぽいわかりづらいホームページでドキュメント等もなんか見づらい感じでした
この何年かで Next.js が大きく改善した みたいな話も聞いたことはあります
良くなってるなら使ってみるのもありかなと久々に見てみました
ぱっと見ではあまり変わった気はしません
相変わらず作ってる Vercel と混ざっていてわかりづらいページです
使わなかった一番の理由である SSR のみサポートがどうなったかを見てみたのですが 変わったような話が見当たりません
SSR の無効化機能をリクエストする issue も放置気味のようです
未だに SSR 前提みたいですね
SSR は要らなくて 単純に CSR の SPA ページを作りたいのですが それをサポートしていません
Nuxt.js は 以前使ったときは SPA と SSR を全体オプションで簡単に切り替えできました
Next.js にもあっても良さそうな機能なのに無いようです
SSR できないコンポーネントはありえるので コンポーネント単位での SSR 無効化はあるらしいです
しかしアプリケーション全体として SSR の無効化ができないようです
完全にできないというわけではないらしく 探せばやってる例はあるのですが やらなくていい苦労をやってるような感じです
できはするが辛いので推奨しないと書かれていたり そういうことをするなら Next.js を使う必要はない CRA を使ったほうがいい といったコメントがついてたりもします
Next.js も Rails のような こういうファイルはここに置くとかフレームワーク側で事前に色々決められてる系で それに従えば楽に作れるけど外れると辛くなるというタイプのフレームワークのようです
楽に使えるならと使ってみようかと思いましたが そんな辛くなるなら無理に Next.js を使う必要もないので今回もやめておきます
それにしてもそんな Next.js がそこまで人気というのがよくわかりません
みんなそんなに SSR したいのでしょうか？
開発時だけではなく 本番用環境のサーバにまで Next.js が必要になってサーバサイドの自由度が減ると思うのですけど
フロントエンド都合はサーバ側に持ち込みたくなくて API を共有するだけで完全に独立したアプリケーションであってほしいという自分からするとサーバサイドに Next.js 必須になる SSR は敷居が高すぎるのですけどねー
昔使ったときはあまり使ってみようと思えるものでもなく使いやすくもなく Nuxt.js のほうが良い印象でした
なんというか悪い意味での企業がやってるツールって感じだったのですよね
コミュニティがやってる OSS に比べて製品ぽいわかりづらいホームページでドキュメント等もなんか見づらい感じでした
この何年かで Next.js が大きく改善した みたいな話も聞いたことはあります
良くなってるなら使ってみるのもありかなと久々に見てみました
ぱっと見ではあまり変わった気はしません
相変わらず作ってる Vercel と混ざっていてわかりづらいページです
使わなかった一番の理由である SSR のみサポートがどうなったかを見てみたのですが 変わったような話が見当たりません
SSR の無効化機能をリクエストする issue も放置気味のようです
未だに SSR 前提みたいですね
SSR は要らなくて 単純に CSR の SPA ページを作りたいのですが それをサポートしていません
Nuxt.js は 以前使ったときは SPA と SSR を全体オプションで簡単に切り替えできました
Next.js にもあっても良さそうな機能なのに無いようです
SSR できないコンポーネントはありえるので コンポーネント単位での SSR 無効化はあるらしいです
しかしアプリケーション全体として SSR の無効化ができないようです
完全にできないというわけではないらしく 探せばやってる例はあるのですが やらなくていい苦労をやってるような感じです
できはするが辛いので推奨しないと書かれていたり そういうことをするなら Next.js を使う必要はない CRA を使ったほうがいい といったコメントがついてたりもします
Next.js も Rails のような こういうファイルはここに置くとかフレームワーク側で事前に色々決められてる系で それに従えば楽に作れるけど外れると辛くなるというタイプのフレームワークのようです
楽に使えるならと使ってみようかと思いましたが そんな辛くなるなら無理に Next.js を使う必要もないので今回もやめておきます
それにしてもそんな Next.js がそこまで人気というのがよくわかりません
みんなそんなに SSR したいのでしょうか？
開発時だけではなく 本番用環境のサーバにまで Next.js が必要になってサーバサイドの自由度が減ると思うのですけど
フロントエンド都合はサーバ側に持ち込みたくなくて API を共有するだけで完全に独立したアプリケーションであってほしいという自分からするとサーバサイドに Next.js 必須になる SSR は敷居が高すぎるのですけどねー
Github とかにログインすると登録してるメールアドレスに自動でメールが送られて そこに書かれた 6 桁くらいの数字を入力しないとログインできない
2 段階認証なんて面倒なものはしたくないから 初回登録時に聞かれたらオフにしてるはずなのに
最近はそういうサービスが多い気がする
今はメールサービスはそういうことしてないから その場でメールサービスにログインして番号を確認できるけど メールサービスまでそういうこと始めたら番号の確認すらできなくなりそう
Google はすでにログイン時に番号入力必要だった気がするから Gmail で登録するとありえそう
メールサービスはログインしたままにすればよいかと思ったけど ウェブは Cookie 期限やなにかのタイミングで全 Cookie 削除がありえる
アプリでもしばらく使ってないと有効期限切れで再ログインさせられることがある
メールアドレスは用途ごとに使い分けてることが多いし 時々しか使わないアカウントは基本ログアウト状態
外出時にはタブレットにしたり 借物 PC を使ったり 普段遣いの PC を使わないかつすぐに触れる環境にないこともある
やっぱりパスワードのみでログインできるメールサービスを使うしか良い対処方法はなさそう
2 段階認証なんて面倒なものはしたくないから 初回登録時に聞かれたらオフにしてるはずなのに
最近はそういうサービスが多い気がする
今はメールサービスはそういうことしてないから その場でメールサービスにログインして番号を確認できるけど メールサービスまでそういうこと始めたら番号の確認すらできなくなりそう
Google はすでにログイン時に番号入力必要だった気がするから Gmail で登録するとありえそう
メールサービスはログインしたままにすればよいかと思ったけど ウェブは Cookie 期限やなにかのタイミングで全 Cookie 削除がありえる
アプリでもしばらく使ってないと有効期限切れで再ログインさせられることがある
メールアドレスは用途ごとに使い分けてることが多いし 時々しか使わないアカウントは基本ログアウト状態
外出時にはタブレットにしたり 借物 PC を使ったり 普段遣いの PC を使わないかつすぐに触れる環境にないこともある
やっぱりパスワードのみでログインできるメールサービスを使うしか良い対処方法はなさそう
久々に JavaScript で class 構文を使って 最近はほぼ使うことはなくなったなと思いました
もともと class 嫌いなので積極的には使ってなかったのですが Web Components の Custom Elements で HTMLElement を継承する必要があったりで一部では使ってました
ただ Custom Elements の機能ってネイティブな HTML の要素みたいなものを自作するわけで低レイヤーよりです
考慮すべき部分も多かったり コード量も増えて気楽に使うには React や Vue みたいなものに頼るか コンポーネントに分けず lit-html を使うとかです
class を使わないというと 単純な関数だと全部を毎回引数で渡す必要があって不便に思われたりしますが class でコンストラクタで設定を受け取って保持してそれをメソッドの処理で使うというのは関数でオブジェクトを返しても一緒です
比べてみると class を使わないほうが遥かにシンプルに書けて this という厄介な存在と関わる必要もありません
例えば単純な足し算と引き算の処理で 計算結果に下限上限を設定したいとします
class だとこんな感じでしょうか
下限上限という設定をコンストラクタで受け取って保持して add/sub メソッドで使います
これは class を使わなくてもこう書けます
すごくスッキリしています
まぁ class でもアロー関数にすれば多少はスッキリしますけど this がいるのは変わらずです
React や Vue でも class から関数よりに変わっていってますし 特に Vue はイミュータブルで関数型という考えではなくリアクティブなオブジェクトという考えのままで this を使わなくて良くなる方法にしてますし
もともと class 嫌いなので積極的には使ってなかったのですが Web Components の Custom Elements で HTMLElement を継承する必要があったりで一部では使ってました
ただ Custom Elements の機能ってネイティブな HTML の要素みたいなものを自作するわけで低レイヤーよりです
考慮すべき部分も多かったり コード量も増えて気楽に使うには React や Vue みたいなものに頼るか コンポーネントに分けず lit-html を使うとかです
class を使わないというと 単純な関数だと全部を毎回引数で渡す必要があって不便に思われたりしますが class でコンストラクタで設定を受け取って保持してそれをメソッドの処理で使うというのは関数でオブジェクトを返しても一緒です
比べてみると class を使わないほうが遥かにシンプルに書けて this という厄介な存在と関わる必要もありません
例えば単純な足し算と引き算の処理で 計算結果に下限上限を設定したいとします
class だとこんな感じでしょうか
class Calc {
constructor(min, max) {
this._min = min
this._max = max
}
_fix(x) {
return Math.max(this._min, Math.min(this._max, x))
}
add(a, b) {
return this._fix(a + b)
}
sub(a, b) {
return this._fix(a - b)
}
}
const c = new Calc(10, 20)
c.add(10, 30)
// 20
c.sub(30, 25)
// 10
下限上限という設定をコンストラクタで受け取って保持して add/sub メソッドで使います
これは class を使わなくてもこう書けます
const calc = (min, max) => {
const fix = x => Math.max(min, Math.min(max, x))
return {
add: (a, b) => fix(a + b),
sub: (a, b) => fix(a - b),
}
}
const c = calc(10, 20)
c.add(10, 30)
// 20
c.sub(30, 25)
// 10
すごくスッキリしています
まぁ class でもアロー関数にすれば多少はスッキリしますけど this がいるのは変わらずです
class Calc {
constructor(min, max) {
this._min = min
this._max = max
}
_fix = (x) => Math.max(this._min, Math.min(this._max, x))
add = (a, b) =>this._fix(a + b)
sub = (a, b) =>this._fix(a - b)
}
React や Vue でも class から関数よりに変わっていってますし 特に Vue はイミュータブルで関数型という考えではなくリアクティブなオブジェクトという考えのままで this を使わなくて良くなる方法にしてますし
データを一意に識別するためのものをなんと呼ぶか
個人的には id だと思います
ネットで見る（ソース）コードでたまに使われているのが cd というもの
ディレクトリ移動しそうに思いますが code の略だそうです
code なら cd よりももう少し見る気がします
識別子というだけだとどっちでもいいとは思いますが 個人的には違いがあるものだと思ってます
id というと自動で振られる番号でだいたいが連番になってるイメージです
code というと id みたいなものだけど 自動の連番じゃなくてなにか意味があって手動でつけられた名前って感じがします
ソースコードとかコードネームとかそういうところで使われる「コード」を見ても意味がない連番みたいなのと違い ちゃんと意味があるものって感じですし
あと id はログイン ID みたいな一部を除いて数字のみのイメージです
連番ですし
code はというと数字のみもあればアルファベット混じりもあったりってイメージです
なのでデータベースの AUTO INCREMENT や SERIAL の列の名前はもちろん id です
これらの id のことを cd や code と書かれている（ソース）コードを見ると少し混乱します
どの界隈の人なのか詳しくないですけどなんで意味のない連番が code なんでしょうか
商品コードだと数字の連番かなと思いましたがアルファベット混じりもありえそうです
それにカテゴリごとに食品なら 100 から家電なら 300 から始まるみたいな意味がある番号を割り当ててそうです
後から関連系が入ったときのために 連番を少し番号を確保して 50 番の次を 60 番にするとかもありそうです
そうなると意味があって手動でつけた番号になって code です
自動連番じゃないんですよね
個人的には id だと思います
ネットで見る（ソース）コードでたまに使われているのが cd というもの
ディレクトリ移動しそうに思いますが code の略だそうです
code なら cd よりももう少し見る気がします
識別子というだけだとどっちでもいいとは思いますが 個人的には違いがあるものだと思ってます
id というと自動で振られる番号でだいたいが連番になってるイメージです
code というと id みたいなものだけど 自動の連番じゃなくてなにか意味があって手動でつけられた名前って感じがします
ソースコードとかコードネームとかそういうところで使われる「コード」を見ても意味がない連番みたいなのと違い ちゃんと意味があるものって感じですし
あと id はログイン ID みたいな一部を除いて数字のみのイメージです
連番ですし
code はというと数字のみもあればアルファベット混じりもあったりってイメージです
なのでデータベースの AUTO INCREMENT や SERIAL の列の名前はもちろん id です
これらの id のことを cd や code と書かれている（ソース）コードを見ると少し混乱します
どの界隈の人なのか詳しくないですけどなんで意味のない連番が code なんでしょうか
商品コードだと数字の連番かなと思いましたがアルファベット混じりもありえそうです
それにカテゴリごとに食品なら 100 から家電なら 300 から始まるみたいな意味がある番号を割り当ててそうです
後から関連系が入ったときのために 連番を少し番号を確保して 50 番の次を 60 番にするとかもありそうです
そうなると意味があって手動でつけた番号になって code です
自動連番じゃないんですよね
最近は専用のソフトの PDF ビューワーは入れずにブラウザに入れてみてます
高速で開けますし 基本はこれで十分
ですがテキストボックスを入れたりハイライトしたりといった簡易編集機能が使えません
稀にこれらが必要になるのでなにか入れようとしたのですが 最近って何がいいんでしょう？
標準的なのは Adobe のやつ
だけど Adobe 製品って重いしそんな使いやすくないしインストール時に余計なものを入れるしであまりいれたいものではないです
以前高速だからと使っていたソフトは Sumatra PDF
これは高速な分シンプルで最小限の機能しかないので編集はできなかったはず
編集に使っていたソフトは PDF-XChange Viewer か Foxit PDF Reader
XChange の方は機能は多いけど重めで機能が多い分見づらかった記憶
Foxit は表示・編集の機能的には良かったけどその他でちょっと問題あり
Foxit の日本語版は扱いがちょっと特殊です
英語のグローバル版を使えば言語設定で言語を選べますが そこに日本語はありません
日本語サイトが別にあって そこで日本語用の別のインストーラが配布されています
英語版だと普通にダウンロードできるのに 日本語版は名前やメールアドレスや利用目的をフォームに入力する必要があります
返信されるメールにダウンロードリンクがあるようです
中身見て承認とかせず自動でしょうし 適当な一時メールアドレスをとって偽名でも良さそうですが こういうムダな手順が必要です
昔はこんなのなかったのですけどね
この日本語版だと言語設定に日本語が含まれます
日本語版は分かれてるせいで更新されるのが遅いし バグなのかアップデートが正常に行われません（英語版だと正常なのかは知らないです）
アップデートの処理が途中で停止して古いバージョンのアンインストールだけ行われて新しいバージョンがインストールされないです
どれだけ待っても終わらないのでタスクマネージャで停止するしかありません
そのままだとアンインストールされて Foxit が入ってない状態になっているので 自分で Temp フォルダからインストーラを探してきて手動でインストールする必要があります
ダウンロードし直そうとするとフォーム入力が必要になるので Temp フォルダを探してました
一度や二度ではなく毎回アップデートのたびにこれでした
開くファイルや編集時に入力するのが日本語なので日本語版にしてましたが UI は英語でもいいので英語版を使ったほうがいいのかも
そういうこともあって 他にいいのがあれば Foxit 以外にしてみたいところですが ググってもこれといって新しくて良さそうなのが見当たらないです
ベスト◯選みたいなところで出てきた知らないものだと Slim PDF というのがありましたが これも Sumatra PDF みたいに編集はできない閲覧専用みたいです
あとは以前から名前は聞いたことがあった Nitro PDF Reader
こっちは単独ではなくて Nitro PDF Pro のトライアルと一緒になってるみたいで名前やメールアドレスをいれるフォームあり
PDF Reader ってこういうのばかりですね
商用製品の簡易版とか体験版みたいのじゃなくて公式サイトが Github Pages になっているような OSS 系ってないんでしょうか
高速で開けますし 基本はこれで十分
ですがテキストボックスを入れたりハイライトしたりといった簡易編集機能が使えません
稀にこれらが必要になるのでなにか入れようとしたのですが 最近って何がいいんでしょう？
標準的なのは Adobe のやつ
だけど Adobe 製品って重いしそんな使いやすくないしインストール時に余計なものを入れるしであまりいれたいものではないです
以前高速だからと使っていたソフトは Sumatra PDF
これは高速な分シンプルで最小限の機能しかないので編集はできなかったはず
編集に使っていたソフトは PDF-XChange Viewer か Foxit PDF Reader
XChange の方は機能は多いけど重めで機能が多い分見づらかった記憶
Foxit は表示・編集の機能的には良かったけどその他でちょっと問題あり
Foxit の日本語版は扱いがちょっと特殊です
英語のグローバル版を使えば言語設定で言語を選べますが そこに日本語はありません
日本語サイトが別にあって そこで日本語用の別のインストーラが配布されています
英語版だと普通にダウンロードできるのに 日本語版は名前やメールアドレスや利用目的をフォームに入力する必要があります
返信されるメールにダウンロードリンクがあるようです
中身見て承認とかせず自動でしょうし 適当な一時メールアドレスをとって偽名でも良さそうですが こういうムダな手順が必要です
昔はこんなのなかったのですけどね
この日本語版だと言語設定に日本語が含まれます
日本語版は分かれてるせいで更新されるのが遅いし バグなのかアップデートが正常に行われません（英語版だと正常なのかは知らないです）
アップデートの処理が途中で停止して古いバージョンのアンインストールだけ行われて新しいバージョンがインストールされないです
どれだけ待っても終わらないのでタスクマネージャで停止するしかありません
そのままだとアンインストールされて Foxit が入ってない状態になっているので 自分で Temp フォルダからインストーラを探してきて手動でインストールする必要があります
ダウンロードし直そうとするとフォーム入力が必要になるので Temp フォルダを探してました
一度や二度ではなく毎回アップデートのたびにこれでした
開くファイルや編集時に入力するのが日本語なので日本語版にしてましたが UI は英語でもいいので英語版を使ったほうがいいのかも
そういうこともあって 他にいいのがあれば Foxit 以外にしてみたいところですが ググってもこれといって新しくて良さそうなのが見当たらないです
ベスト◯選みたいなところで出てきた知らないものだと Slim PDF というのがありましたが これも Sumatra PDF みたいに編集はできない閲覧専用みたいです
あとは以前から名前は聞いたことがあった Nitro PDF Reader
こっちは単独ではなくて Nitro PDF Pro のトライアルと一緒になってるみたいで名前やメールアドレスをいれるフォームあり
PDF Reader ってこういうのばかりですね
商用製品の簡易版とか体験版みたいのじゃなくて公式サイトが Github Pages になっているような OSS 系ってないんでしょうか
別記事で CSS の詳細度が消えて欲しいって愚痴を書いていて そういえば JavaScript も互換性を理由にイマイチな仕様が色々残ってるなと思いました
ウェブ関係は ES2015 から JavaScript が大幅に進化して その他ブラウザの WEB API も進化してきました
ですが 古いページを見れるようにという理由で互換性を重視するので イマイチな仕様が残ったりです
廃止とされた機能もありますが 昔からある機能だと削除されることは全然なくて形だけのあまり意味がないものです
新規作成時に使わないほうがいいというだけで 消されることがないのはほぼ確定だし 新しいのを覚えるのも面倒だからと使い続ける人もいます
単純に使わなければ自分には関係ないというタイプの機能ならまだいいですが CSS の詳細度みたいに絶対関わってきて回避のために面倒を強いられるものもあります
typeof で null が "object" になるのも 見方を変えればおかしくはないのでしょうが 使うときには不便でしか無いです
直接 CSS や JavaScript を書かずに他言語で書いて CSS や JavaScript を生成するのも一つの方法ですが 手間が増えてますし ブラウザで直接動くわけじゃなく間に余計なものを挟むことになって気が進みません
型が欲しいから TypeScript を使うとか 関数型言語が好きだから Elm を使うとか そういうポジティブな理由でならまだいいですが JavaScript でいいけど 互換性のために変な仕様があるのが嫌だからというネガティブな理由では alt 系を使うのは気が進みません
特にその理由が昔のページを表示するために互換性を残すというのも不満に感じるところです
その他言語だと古いバージョン使えばいいという理由で 互換性を捨てられます
変化が大きすぎると Python みたいに移行が進まないとかはあるかもですが その他言語でもメジャーアップデートで徐々に古い機能が使えなくなってるのはよく見かけます
古いページを表示するためと言って互換性を残しているといつまで経っても古い機能を引きずることになって 他言語に比べると発展が妨げられます
最近ではウェブ以外でも Electron だったり WebView だったりでローカルアプリなどでも使われてますし いつまでも過去の負債を残してないで綺麗にして欲しいところです
そもそも更新もされない過去のサイトなんて どれだけの人が見てるんでしょうか
Google 検索でも古いページはめったに出てこないです
互換性を切ったとしても古いサイトを見る時は IE の互換モードでも使えば良いです
IE の完全終了をウェブの一区切りとして廃止機能や一貫性の無い部分を消して新しいものにしていってくれるといいのですけどね
ウェブ関係は ES2015 から JavaScript が大幅に進化して その他ブラウザの WEB API も進化してきました
ですが 古いページを見れるようにという理由で互換性を重視するので イマイチな仕様が残ったりです
廃止とされた機能もありますが 昔からある機能だと削除されることは全然なくて形だけのあまり意味がないものです
新規作成時に使わないほうがいいというだけで 消されることがないのはほぼ確定だし 新しいのを覚えるのも面倒だからと使い続ける人もいます
単純に使わなければ自分には関係ないというタイプの機能ならまだいいですが CSS の詳細度みたいに絶対関わってきて回避のために面倒を強いられるものもあります
typeof で null が "object" になるのも 見方を変えればおかしくはないのでしょうが 使うときには不便でしか無いです
直接 CSS や JavaScript を書かずに他言語で書いて CSS や JavaScript を生成するのも一つの方法ですが 手間が増えてますし ブラウザで直接動くわけじゃなく間に余計なものを挟むことになって気が進みません
型が欲しいから TypeScript を使うとか 関数型言語が好きだから Elm を使うとか そういうポジティブな理由でならまだいいですが JavaScript でいいけど 互換性のために変な仕様があるのが嫌だからというネガティブな理由では alt 系を使うのは気が進みません
特にその理由が昔のページを表示するために互換性を残すというのも不満に感じるところです
その他言語だと古いバージョン使えばいいという理由で 互換性を捨てられます
変化が大きすぎると Python みたいに移行が進まないとかはあるかもですが その他言語でもメジャーアップデートで徐々に古い機能が使えなくなってるのはよく見かけます
古いページを表示するためと言って互換性を残しているといつまで経っても古い機能を引きずることになって 他言語に比べると発展が妨げられます
最近ではウェブ以外でも Electron だったり WebView だったりでローカルアプリなどでも使われてますし いつまでも過去の負債を残してないで綺麗にして欲しいところです
そもそも更新もされない過去のサイトなんて どれだけの人が見てるんでしょうか
Google 検索でも古いページはめったに出てこないです
互換性を切ったとしても古いサイトを見る時は IE の互換モードでも使えば良いです
IE の完全終了をウェブの一区切りとして廃止機能や一貫性の無い部分を消して新しいものにしていってくれるといいのですけどね
基本はサーバを Node.js にしてフロントエンドもバックエンドも JavaScript にしてます
たまには気分を変えてサーバが JavaScript でない構成で作ることがあったのですが やっぱり揃ってたほうが楽でした
フロントエンドとバックエンドだとやることが違ってそれぞれに適した言語がベストみたいな考え方もありますが 最近って昔はバックエンドでやってたこともフロントエンドでやってしまいます
あんまりやることが変わらないので 同じような処理を別言語で 2 回書く必要が出て ただ面倒なだけだったり
完全に同じ処理を両方で書く部分もあって そのまま移植できたらいいのですが 言語ごとの機能の違いで別の書き方にしないといけなくて面倒でした
ひとつはサーバに送信するデータのチェック
チェックのたびにサーバに送りたくはないので JavaScript でチェックしてから最終的なチェックのみをサーバでしてます
JavaScript でチェックしてるので普通ならサーバサイドでのエラーは起きないです
丁寧なチェックやメッセージ表示は ブラウザ内で行って サーバ側は最低限の受け付けてはいけないものを拒否する程度です
なので基本的にはブラウザとサーバで同じ処理にはなりませんでした
特に SPA で API 呼び出し前提なので フォームと API が 1 対 1 で対応しません
例えば ユーザ情報編集画面で名前の変更とテーマや背景色の変更は別ページでできるとします
API まで分ける必要はないので ユーザ情報を変更する API 一つだけにします
画面的には名前とテーマを同時に変更できないのに API を直接呼び出せばできてしまいますが できても問題ないので許可しています
逆に一緒に変更したいのでユーザ情報とまた別の情報を 1 つのフォームで変更できるようにするときは保存時に 2 つの API を呼び出します
API ベースでなくとも パスワードやメールアドレスの一致チェックみたいのはユーザの入力ミスを防ぐ親切機能みたいなものなのでブラウザ上だけで十分です
パスワードが◯文字以上とか 半角のみというのもサーバ側でまでチェックしなくても十分です
ということであまりチェック処理が負担になると考えてませんでした
ですが データによっては保存可能な条件が複雑で数十行程度のコードが必要になりました
必須な条件なのでサーバサイドでもチェックが必要です
完全に同じ処理を別言語で書いていて すごく無駄なことをしてる気分でした
二回書くことでロジックのミスに気づける可能性が増えるみたいなポジティブなことを言う人もいますし たまに見つけれたりはしますが どっちかにバグが入ると動かなくなるのでバグ発生確率が上がってるような気がします
Node.js だとモジュールにしておいてサーバからも同じファイルを読み込むだけで使えるのに
どの言語でも動くように事前にチェック処理用の関数を用意しておいてルールを JSON みたいな多くの言語で扱えるデータとして書けばいいかなと思ってなにか作ろうとしたことは何度かあります
便利な関数を作るとなるとすごく大変なので 四則演算や比較みたいな基本的な機能だけに対応してあとは組み合わせる感じと考えてました
「[">", 100]」 で 100 以上とか 「["if", condition, then, else]」 で分岐とか 「["regex", "/^a/"]」 で正規表現マッチングとか
構文的には Lisp みたいな感じ？
ただ実際に必要になる複雑なケースは JavaScript でもチェック処理が数十行になったりするもので こういうのの組み合わせで実現はかなり辛いです
書いたとしても長すぎますし 日付計算みたいな言語側に付いてる便利機能を使いたい部分も多いです
問題のほうが多いので実用まで行かずにやめました
同じ処理がある程度必要になる以上 揃えておいたほうが何かと便利で むしろ別言語を使うメリットのほうが出てきません
ふたつめも似てますが ブラウザ内を前提とした処理がサーバ側でも必要になるケースです
API 前提だと サーバ側はデータしか扱わず HTML みたいな見た目は気にしませんし ユーザ用の表示も知る必要がありません
数値が金額で 「,」 付きで表示が必要かとか この値はフラグで 0 なら 「無効」 と表示して 1 なら 「有効」 と表示するとか enum 値の日本語ラベルみたいなのも知らなくていいです
そういうユーザ用のデータはブラウザ側だけに置いておけばいいです
と思っていたのですが HTML 以外でユーザ用の表示を作らないといけなくなるとサーバサイドにこれらを持ってこないといけません
JSON などの静的なファイルとして保持しているならサーバ側の言語が違っても対応しやすいでしょうが 動的な部分もあって JavaScript のモジュールとして管理しているとサーバサイドでは JavaScript を実行できずに困ります
最近だとエクセルや PDF の出力でもブラウザ側でできてしまうので あまりサーバ側でしないといけない処理はありませんが セキュリティ的な意味で署名や暗号化とかが入ってくるとサーバ側でやらざるを得ませんし メールや Push 通知などの方法でユーザ用の通知を送信する場合もサーバ側でせざるを得ないところです
結局ブラウザ側だけのつもりだった処理をサーバ側でも実装することになり 同じものを二重に管理してるという面倒な状態になります
同じ仕様を基にフロントエンドとバックエンドで完全に分かれて作って最後に結合するみたいなことをやってる大きなプロジェクトだとあまり気にならないのかもしれませんが 全部一人で作ってるとすごく気持ち悪い部分なんですよね
最近は WebAssembly の対応が進んでますし サーバサイドを Node.js 以外で作るなら フロントエンドもその言語で作って WebAssembly 出力するのもありなのかもしれません
ただ現状だと負荷が高いアルゴリズムなどの関数やゲームなどのグラフィック処理がほとんどで 一般的なウェブフロントエンドの処理全体を WebAssembly でできるのって限られてる気がしますけど
Rust や C# はフロントエンド用フレームワークみたいな感じで作れるのを見た気がするけどどうなんでしょう
Elm みたいに JavaScript でしかできない部分を別に作ってポートして呼び出すみたいなのがいっぱいだとイマイチな気がしますけど
とりあえず今のところはサーバサイドも JavaScript がベストだと思います
たまには気分を変えてサーバが JavaScript でない構成で作ることがあったのですが やっぱり揃ってたほうが楽でした
フロントエンドとバックエンドだとやることが違ってそれぞれに適した言語がベストみたいな考え方もありますが 最近って昔はバックエンドでやってたこともフロントエンドでやってしまいます
あんまりやることが変わらないので 同じような処理を別言語で 2 回書く必要が出て ただ面倒なだけだったり
完全に同じ処理を両方で書く部分もあって そのまま移植できたらいいのですが 言語ごとの機能の違いで別の書き方にしないといけなくて面倒でした
ひとつはサーバに送信するデータのチェック
チェックのたびにサーバに送りたくはないので JavaScript でチェックしてから最終的なチェックのみをサーバでしてます
JavaScript でチェックしてるので普通ならサーバサイドでのエラーは起きないです
丁寧なチェックやメッセージ表示は ブラウザ内で行って サーバ側は最低限の受け付けてはいけないものを拒否する程度です
なので基本的にはブラウザとサーバで同じ処理にはなりませんでした
特に SPA で API 呼び出し前提なので フォームと API が 1 対 1 で対応しません
例えば ユーザ情報編集画面で名前の変更とテーマや背景色の変更は別ページでできるとします
API まで分ける必要はないので ユーザ情報を変更する API 一つだけにします
画面的には名前とテーマを同時に変更できないのに API を直接呼び出せばできてしまいますが できても問題ないので許可しています
逆に一緒に変更したいのでユーザ情報とまた別の情報を 1 つのフォームで変更できるようにするときは保存時に 2 つの API を呼び出します
API ベースでなくとも パスワードやメールアドレスの一致チェックみたいのはユーザの入力ミスを防ぐ親切機能みたいなものなのでブラウザ上だけで十分です
パスワードが◯文字以上とか 半角のみというのもサーバ側でまでチェックしなくても十分です
ということであまりチェック処理が負担になると考えてませんでした
ですが データによっては保存可能な条件が複雑で数十行程度のコードが必要になりました
必須な条件なのでサーバサイドでもチェックが必要です
完全に同じ処理を別言語で書いていて すごく無駄なことをしてる気分でした
二回書くことでロジックのミスに気づける可能性が増えるみたいなポジティブなことを言う人もいますし たまに見つけれたりはしますが どっちかにバグが入ると動かなくなるのでバグ発生確率が上がってるような気がします
Node.js だとモジュールにしておいてサーバからも同じファイルを読み込むだけで使えるのに
どの言語でも動くように事前にチェック処理用の関数を用意しておいてルールを JSON みたいな多くの言語で扱えるデータとして書けばいいかなと思ってなにか作ろうとしたことは何度かあります
便利な関数を作るとなるとすごく大変なので 四則演算や比較みたいな基本的な機能だけに対応してあとは組み合わせる感じと考えてました
「[">", 100]」 で 100 以上とか 「["if", condition, then, else]」 で分岐とか 「["regex", "/^a/"]」 で正規表現マッチングとか
構文的には Lisp みたいな感じ？
ただ実際に必要になる複雑なケースは JavaScript でもチェック処理が数十行になったりするもので こういうのの組み合わせで実現はかなり辛いです
書いたとしても長すぎますし 日付計算みたいな言語側に付いてる便利機能を使いたい部分も多いです
問題のほうが多いので実用まで行かずにやめました
同じ処理がある程度必要になる以上 揃えておいたほうが何かと便利で むしろ別言語を使うメリットのほうが出てきません
ふたつめも似てますが ブラウザ内を前提とした処理がサーバ側でも必要になるケースです
API 前提だと サーバ側はデータしか扱わず HTML みたいな見た目は気にしませんし ユーザ用の表示も知る必要がありません
数値が金額で 「,」 付きで表示が必要かとか この値はフラグで 0 なら 「無効」 と表示して 1 なら 「有効」 と表示するとか enum 値の日本語ラベルみたいなのも知らなくていいです
そういうユーザ用のデータはブラウザ側だけに置いておけばいいです
と思っていたのですが HTML 以外でユーザ用の表示を作らないといけなくなるとサーバサイドにこれらを持ってこないといけません
JSON などの静的なファイルとして保持しているならサーバ側の言語が違っても対応しやすいでしょうが 動的な部分もあって JavaScript のモジュールとして管理しているとサーバサイドでは JavaScript を実行できずに困ります
最近だとエクセルや PDF の出力でもブラウザ側でできてしまうので あまりサーバ側でしないといけない処理はありませんが セキュリティ的な意味で署名や暗号化とかが入ってくるとサーバ側でやらざるを得ませんし メールや Push 通知などの方法でユーザ用の通知を送信する場合もサーバ側でせざるを得ないところです
結局ブラウザ側だけのつもりだった処理をサーバ側でも実装することになり 同じものを二重に管理してるという面倒な状態になります
同じ仕様を基にフロントエンドとバックエンドで完全に分かれて作って最後に結合するみたいなことをやってる大きなプロジェクトだとあまり気にならないのかもしれませんが 全部一人で作ってるとすごく気持ち悪い部分なんですよね
最近は WebAssembly の対応が進んでますし サーバサイドを Node.js 以外で作るなら フロントエンドもその言語で作って WebAssembly 出力するのもありなのかもしれません
ただ現状だと負荷が高いアルゴリズムなどの関数やゲームなどのグラフィック処理がほとんどで 一般的なウェブフロントエンドの処理全体を WebAssembly でできるのって限られてる気がしますけど
Rust や C# はフロントエンド用フレームワークみたいな感じで作れるのを見た気がするけどどうなんでしょう
Elm みたいに JavaScript でしかできない部分を別に作ってポートして呼び出すみたいなのがいっぱいだとイマイチな気がしますけど
とりあえず今のところはサーバサイドも JavaScript がベストだと思います
ある PC で調べ物をするとなぜか他の PC よりも求めてるサイトがでてきませんでした
別の PC で調べたときには 「この検索ワードで 1 ページ目の上の方にあったはず」 とまでわかっていたときでも出てきません
何が違うのかと比べてみると 片方は Google の言語設定が英語でした
プログラムとか PC 関係のことを調べるなら英語のサイトのほうが良い情報が見つかるので 英語設定にしてるほうが良かったりします
ただ今回は日本語で検索して出てくるページも日本語です
それなら Google の設定の言語はどっちでも対して変わらないかと思っていたのですが けっこう差があるようでした
英語設定にしているほうが有用なサイトが上位に来ています
日本語設定だと 有用なサイトの情報を劣化コピーしたような邪魔なサイトがいっぱい出てきます
アルゴリズムが違うのでしょうか
それとも中身が無いのに検索で上位に来るようにしようというサイトは日本向けの SEO しかできないとかなんでしょうか
なんにせよ 日本語で検索する場合でも 良い情報が出てこないなら言語設定を英語にしてみるというのはありだと思います
別の PC で調べたときには 「この検索ワードで 1 ページ目の上の方にあったはず」 とまでわかっていたときでも出てきません
何が違うのかと比べてみると 片方は Google の言語設定が英語でした
プログラムとか PC 関係のことを調べるなら英語のサイトのほうが良い情報が見つかるので 英語設定にしてるほうが良かったりします
ただ今回は日本語で検索して出てくるページも日本語です
それなら Google の設定の言語はどっちでも対して変わらないかと思っていたのですが けっこう差があるようでした
英語設定にしているほうが有用なサイトが上位に来ています
日本語設定だと 有用なサイトの情報を劣化コピーしたような邪魔なサイトがいっぱい出てきます
アルゴリズムが違うのでしょうか
それとも中身が無いのに検索で上位に来るようにしようというサイトは日本向けの SEO しかできないとかなんでしょうか
なんにせよ 日本語で検索する場合でも 良い情報が出てこないなら言語設定を英語にしてみるというのはありだと思います
結合されたセルの中のどれかを参照すると 一番左上のセルだけに値が入っていて 残りは空となるエクセルの仕様 本当に使いづらくてやっかい
結合してるんだから全部のセルで同じ値を参照できてほしい
指定のセルが結合セルなら空にせず値を取得する関数があれば問題ないのにそういう関数もない
そもそも結合されてるセルかの判断すらできない
LET とか LAMBDA みたいな新規関数追加するならこういう基本的なエクセル機能を扱う関数を用意してほしい
VBA マクロなら結合セルを取得できるけど そのためなんかに VBA を使いたくない
セル結合を使うなと言ってる人は見かけるけど エクセルは機械的に扱うデータのためだけのツールじゃない
人が見る 見た目優先のものを作るのにも使われる
エクセルがセル結合をサポートしてるんだからそれを使うなというのがおかしい
データとして再利用するとかなく見た目上のもので楽につくるために数式を使うだけなのにデータシートを分けるなんてやったら無駄に時間がかかるだけ
変にエクセル内の式でセル参照なんかせず Python などで全部のセルのデータを値として埋め込んでエクセルファイルを生成する方が楽な気がしてきた
結合してるんだから全部のセルで同じ値を参照できてほしい
指定のセルが結合セルなら空にせず値を取得する関数があれば問題ないのにそういう関数もない
そもそも結合されてるセルかの判断すらできない
LET とか LAMBDA みたいな新規関数追加するならこういう基本的なエクセル機能を扱う関数を用意してほしい
VBA マクロなら結合セルを取得できるけど そのためなんかに VBA を使いたくない
セル結合を使うなと言ってる人は見かけるけど エクセルは機械的に扱うデータのためだけのツールじゃない
人が見る 見た目優先のものを作るのにも使われる
エクセルがセル結合をサポートしてるんだからそれを使うなというのがおかしい
データとして再利用するとかなく見た目上のもので楽につくるために数式を使うだけなのにデータシートを分けるなんてやったら無駄に時間がかかるだけ
変にエクセル内の式でセル参照なんかせず Python などで全部のセルのデータを値として埋め込んでエクセルファイルを生成する方が楽な気がしてきた
fn(point => min <= point)
min を強調させてるようにしか見えない
英語で聞いてみたりしたときに シンプルに求めてる回答が来れば お礼だけ返して楽に終わるけど ときどき面倒なことになるときがある
こっちが求めてるところ以外で謎の指摘が来たり
日本語なら軽く 「これはこういうものだからそれで問題ない むしろこのほうが優れてる」 と答えて終わりだけど英語だとそれだけでも面倒
複雑な文になると翻訳ツール使ってもうまく伝わらないような形になることもあるし 言い回しの調整とかで時間取られる
返信したらしたで また返答来たりで長く議論が続きそうな予感しかない
疲れるしそれに勝って得られるものもないからもうそれでいいよとそのままスルーすることが多いけど 日本語でなら絶対にこれはこうあるべきと言いたいくらいなところだからなんだかなーという気分になる
こっちが求めてるところ以外で謎の指摘が来たり
日本語なら軽く 「これはこういうものだからそれで問題ない むしろこのほうが優れてる」 と答えて終わりだけど英語だとそれだけでも面倒
複雑な文になると翻訳ツール使ってもうまく伝わらないような形になることもあるし 言い回しの調整とかで時間取られる
返信したらしたで また返答来たりで長く議論が続きそうな予感しかない
疲れるしそれに勝って得られるものもないからもうそれでいいよとそのままスルーすることが多いけど 日本語でなら絶対にこれはこうあるべきと言いたいくらいなところだからなんだかなーという気分になる
リストや表の表示のコンポーネントを見てると 全件データがある前提で JavaScript 内でフィルタやソートやページングしてるのをみることがけっこうある
検索ページで検索条件やソート・ページが切り替わるごとにサーバにリクエストしてリストを表示してるとこれらの機能を役立たせられないし 表示せずデータ受信だけならそんなに時間かからないし 画面開いたときに全件取得して保持して JavaScript で検索やソートでいいかな
新規に頻繁にデータが来て直ぐに反映したいわけじゃなければ 更新は 1 時間に 1 回とかでもいいし
必要ならユーザが更新ボタン押せば再取得とかで困らなそう
全件が何百万件ってデータがあるならともかく数千件レベルなら問題なさそうだし
サーバ側も基本全員に同じデータだから変数上に保持しておいたのをそのまま返すだけでデータベース経由しなくていいし
ありな気がしてきた
検索ページで検索条件やソート・ページが切り替わるごとにサーバにリクエストしてリストを表示してるとこれらの機能を役立たせられないし 表示せずデータ受信だけならそんなに時間かからないし 画面開いたときに全件取得して保持して JavaScript で検索やソートでいいかな
新規に頻繁にデータが来て直ぐに反映したいわけじゃなければ 更新は 1 時間に 1 回とかでもいいし
必要ならユーザが更新ボタン押せば再取得とかで困らなそう
全件が何百万件ってデータがあるならともかく数千件レベルなら問題なさそうだし
サーバ側も基本全員に同じデータだから変数上に保持しておいたのをそのまま返すだけでデータベース経由しなくていいし
ありな気がしてきた
パスワードは完全に自由に設定できるべきだと思います
ユーザが a というパスワードでいいならシステムはそれも受け入れるべきです
それでアカウント乗っ取られても自己責任でそれでいいんです
なのに
「大文字小文字数字を混ぜてください」
「記号を入れてください」
「使える記号はこれだけです」
「文字数は何文字から何文字に収めてください」
「何ヶ月に一回パスワードを変更してください」
「同じパスワードは使いまわせません」
こんな注文がいっぱい要求されることが多いです
ほんとうんざりです
警告として強度が弱いですよ と言われるくらいで無視できるならいいのに強制です
強制したところで簡単なパスワードにしたい人は結局 「passwordA1!」 みたいに最後に大文字数字記号の基本的なのをつけるだけで意味ないと思うんですよね
ここまで要求するならもうシステム側でパスワードを自動生成して「これを使ってください」といえばいいと思うんです
あれがだめこれがだめと言われながらパスワードを考える時間が無駄です
それに システムの自動生成なら使い回し問題もありえないですし
ユーザが a というパスワードでいいならシステムはそれも受け入れるべきです
それでアカウント乗っ取られても自己責任でそれでいいんです
なのに
「大文字小文字数字を混ぜてください」
「記号を入れてください」
「使える記号はこれだけです」
「文字数は何文字から何文字に収めてください」
「何ヶ月に一回パスワードを変更してください」
「同じパスワードは使いまわせません」
こんな注文がいっぱい要求されることが多いです
ほんとうんざりです
警告として強度が弱いですよ と言われるくらいで無視できるならいいのに強制です
強制したところで簡単なパスワードにしたい人は結局 「passwordA1!」 みたいに最後に大文字数字記号の基本的なのをつけるだけで意味ないと思うんですよね
ここまで要求するならもうシステム側でパスワードを自動生成して「これを使ってください」といえばいいと思うんです
あれがだめこれがだめと言われながらパスワードを考える時間が無駄です
それに システムの自動生成なら使い回し問題もありえないですし
これはバグだ仕様だの話を見るときによく思うこと
製作者から見て仕様であっても 使う側からみるとバグ なんてのはよくあるもの
どっちが正しいと言うのはないと思うし どっちも正解だと思う
使う側で使えない以上 その人からしてはバグなんだし
もちろん CSV パーサで JSON がパースできない みたいに明らかにおかしいのもあるけど
機能的に一貫性があればこういうときはこうなるはずだ これとこれを組み合わせたらこういう事ができるはずだ というところで 想定したとおりに動かないみたいもの
作る側が想定していなかったから動かないし直すつもりはないというのは別に構わないと思う
でもそれを仕様と呼んだところで ユーザからすれば動くべきところが動かないというだけ
製作者側が一方的にこれは仕様かバグかを決めるならその違いに対して意味はないと思う
仕様かバグかはどっちでも良くて 動くか動かないか 使えるか使えないか だし
仕様書なんてのがある世界で生きてる人は それが一つの基準かもしれない
でもそれはすべてのケースが網羅されてるの？
そこに書いてない挙動は何があっても全部仕様？
そう契約してるならそれでいいと思うけど すべてがそういうわけじゃないよね
作るときに想定してなくても 「言われてみると そのほうが正しい」 と思うなら直すこともあるし 逆にバグと認めていても直さない・直せないことだってある
バグ報告があって それが仕様かバグかの判定なんていらないから 直すか直さないか で伝えたらいいと思う
実際に どう見てもバグであっても自分の方が正しいと仕様と言い切ったり 間違ってると理解していても直せないから仕様ということにする人だっている
仕様です って返答されても 「だから使えないって言ってるんだって」 としかならないしイライラさせるだけ
まだ 直さない・直せないと言う答えのほうが納得できると思う
あと 自分の周りというかネットも含めて見かける範囲では 昔ながらの IT 系で働いてる人に 過剰と思うほど仕様かバグかをはっきりさせたがる人が多いように思う
バグと言う言葉に過敏に反応して バグ扱いされたら これはバグじゃない！とすごく熱くなってる
バグと言う言葉自体を「言ってはいけない言葉」であるかのように扱ってるようにも見える
業界的なことなのかもしれないけど 自分はユーザ寄りで気軽にバグバグ言うので 理解できない世界
自分が作ったプログラムを我が子のように思ってたりするのかな？
バグ扱い＝家族を侮辱されたと考えれば あの必死さもわからなくもない……ような気もするような
製作者から見て仕様であっても 使う側からみるとバグ なんてのはよくあるもの
どっちが正しいと言うのはないと思うし どっちも正解だと思う
使う側で使えない以上 その人からしてはバグなんだし
もちろん CSV パーサで JSON がパースできない みたいに明らかにおかしいのもあるけど
機能的に一貫性があればこういうときはこうなるはずだ これとこれを組み合わせたらこういう事ができるはずだ というところで 想定したとおりに動かないみたいもの
作る側が想定していなかったから動かないし直すつもりはないというのは別に構わないと思う
でもそれを仕様と呼んだところで ユーザからすれば動くべきところが動かないというだけ
製作者側が一方的にこれは仕様かバグかを決めるならその違いに対して意味はないと思う
仕様かバグかはどっちでも良くて 動くか動かないか 使えるか使えないか だし
仕様書なんてのがある世界で生きてる人は それが一つの基準かもしれない
でもそれはすべてのケースが網羅されてるの？
そこに書いてない挙動は何があっても全部仕様？
そう契約してるならそれでいいと思うけど すべてがそういうわけじゃないよね
作るときに想定してなくても 「言われてみると そのほうが正しい」 と思うなら直すこともあるし 逆にバグと認めていても直さない・直せないことだってある
バグ報告があって それが仕様かバグかの判定なんていらないから 直すか直さないか で伝えたらいいと思う
実際に どう見てもバグであっても自分の方が正しいと仕様と言い切ったり 間違ってると理解していても直せないから仕様ということにする人だっている
仕様です って返答されても 「だから使えないって言ってるんだって」 としかならないしイライラさせるだけ
まだ 直さない・直せないと言う答えのほうが納得できると思う
あと 自分の周りというかネットも含めて見かける範囲では 昔ながらの IT 系で働いてる人に 過剰と思うほど仕様かバグかをはっきりさせたがる人が多いように思う
バグと言う言葉に過敏に反応して バグ扱いされたら これはバグじゃない！とすごく熱くなってる
バグと言う言葉自体を「言ってはいけない言葉」であるかのように扱ってるようにも見える
業界的なことなのかもしれないけど 自分はユーザ寄りで気軽にバグバグ言うので 理解できない世界
自分が作ったプログラムを我が子のように思ってたりするのかな？
バグ扱い＝家族を侮辱されたと考えれば あの必死さもわからなくもない……ような気もするような
ウェブでは Content-type に mime type が使われます
これを見て JavaScript を実行するかなどの判断が行われるので 全部 text/html 扱いの簡易サーバだと動かない部分があります
簡易サーバを自作するときでもこの当たりが面倒なので パッケージに頼ることが多いです
この mime type ですがいらないと思うんです
ちゃんとファイルの中身を見た上で ファイルの種類を判断してサーバがレスポンスを返してるならともかく ほとんどの場合は拡張子から自動変換するだけです
ファイルの中身を見てからファイルの種類を判断して mime type を返すようなものは見たことがないです
Node.js だと Express や Koa などのフレームワークはだいたいこのどちらかのパッケージを使っています
mime type と拡張子の対応が記述されている JavaScript オブジェクト形式のデータベースファイルです
https://github.com/broofa/mime/blob/master/types/standard.js
https://github.com/jshttp/mime-db/blob/master/db.json
どちらも週間ダウンロード数が 3000 万を超えています
外部パッケージは使わない方針の hapi でもこれを使っています
Python でも標準の mimetypes.guess_type で mime type を取得できます
都度 ファイルの中身を確認するのは処理が遅くなりますし ファイルごとに mime type 情報を別に保持しておくのも面倒が多いので仕方ないとは思います
ですが それなら最初から mime type じゃなくて拡張子を見ればいいと思うんです
ウェブページの URL なので HTML ファイルに .html がついてないとか .php を HTML ファイルとしたいとかあるのはわかります
そういうときだけ HTTP ヘッダーのレスポンスに情報を付加して なにもないデフォルト値は拡張子を見てほしいです
今更 変わらないとは思いますけど ちょっとしたことするだけでも mime type 変換もいるのは面倒なんですよね
ブラウザ拡張機能として localhost サーバから未指定・text/plain・text/html が来たときは拡張子から判断したものに置き換えるようにするのはありかもですね
サーバは色々変わってもブラウザは同じですし
これを見て JavaScript を実行するかなどの判断が行われるので 全部 text/html 扱いの簡易サーバだと動かない部分があります
簡易サーバを自作するときでもこの当たりが面倒なので パッケージに頼ることが多いです
この mime type ですがいらないと思うんです
ちゃんとファイルの中身を見た上で ファイルの種類を判断してサーバがレスポンスを返してるならともかく ほとんどの場合は拡張子から自動変換するだけです
ファイルの中身を見てからファイルの種類を判断して mime type を返すようなものは見たことがないです
Node.js だと Express や Koa などのフレームワークはだいたいこのどちらかのパッケージを使っています
mime type と拡張子の対応が記述されている JavaScript オブジェクト形式のデータベースファイルです
https://github.com/broofa/mime/blob/master/types/standard.js
https://github.com/jshttp/mime-db/blob/master/db.json
どちらも週間ダウンロード数が 3000 万を超えています
外部パッケージは使わない方針の hapi でもこれを使っています
Python でも標準の mimetypes.guess_type で mime type を取得できます
都度 ファイルの中身を確認するのは処理が遅くなりますし ファイルごとに mime type 情報を別に保持しておくのも面倒が多いので仕方ないとは思います
ですが それなら最初から mime type じゃなくて拡張子を見ればいいと思うんです
ウェブページの URL なので HTML ファイルに .html がついてないとか .php を HTML ファイルとしたいとかあるのはわかります
そういうときだけ HTTP ヘッダーのレスポンスに情報を付加して なにもないデフォルト値は拡張子を見てほしいです
今更 変わらないとは思いますけど ちょっとしたことするだけでも mime type 変換もいるのは面倒なんですよね
ブラウザ拡張機能として localhost サーバから未指定・text/plain・text/html が来たときは拡張子から判断したものに置き換えるようにするのはありかもですね
サーバは色々変わってもブラウザは同じですし
ルーターをコンポーネントで作るとき こんな構造になってるのが多いと思う
ルート定義それぞれがコンポーネントになってて DOM に存在する
1 つ目のルートがアクティブなら
3 つ目のルートがアクティブなら
アクティブなルート定義コンポーネントの子要素としてページの DOM が作られる
これだと グローバルなヘッダーなど共通なパーツもページ（ルート）ごとに別になる
同じパーツなら見た目上は変わらないけど 再作成してるし無駄も多い
ヘッダーに検索用 input とかあったら再作成でリセットされるし
ShadowDOM を使って共通の場所に作るか app-route を DOM として作らないほうがいいかも
page-header や page-footer が同じ要素なら使いまわして再作成しないようにする
app-route を作らないなら app-router のプロパティやメソッド呼び出しで DOM ではわからない形でルートを定義する
基本的にはルート定義コンポーネントが直接ページ内の要素を管理しないので ルート定義コンポーネントではルートに対応するページコンポーネントの要素を作って そのコンポーネントがページ要素を管理する構造になるはず
こうなるとアクティブなときに app-route の子要素に配置しないようにしても
とか
になって結局ヘッダーなどの要素は共有できてない
ページのコンポーネントじゃなくて共通の部分とページごとの可変部分の親子コンポーネントにすれば良さそう
*-layout の ShadowDOM 内に *-content を slot で配置
同じ default-layout を使うルート間の移動なら default-layout 要素はそのままなので page-header/page-footer はそのまま維持される
だけど list-content のところで user-list-content と article-list-content があった場合
どっちもリスト系なのでリスト系共通の要素があるけど コンポーネントが分かれるのでここは DOM が異なってしまう
page-header みたいに 同じなら DOM を使いまわしたいなら list-content のところも共通と個別のところを分けて親子構造にする必要が出てくる
これも大変で面倒だし 実際の DOM にコンポーネントが挟まらない React とか lit-html とかのほうが良いのかも
それ以前に 別に重いとか見た目崩れるとかないなら 無理に DOM の使い回しとかせずページのルートコンポーネントから置き換わっても別に困らないとも思う
<app-router>
<app-route route="/">
<app-route route="/foo">
<app-route route="/bar">
ルート定義それぞれがコンポーネントになってて DOM に存在する
1 つ目のルートがアクティブなら
<app-router>
<app-route route="/">
<page-header>
<page-content>
<page-footer>
<app-route route="/foo">
<app-route route="/bar">
3 つ目のルートがアクティブなら
<app-router>
<app-route route="/">
<app-route route="/foo">
<app-route route="/bar">
<page-header>
<page-content>
<page-footer>
アクティブなルート定義コンポーネントの子要素としてページの DOM が作られる
これだと グローバルなヘッダーなど共通なパーツもページ（ルート）ごとに別になる
同じパーツなら見た目上は変わらないけど 再作成してるし無駄も多い
ヘッダーに検索用 input とかあったら再作成でリセットされるし
ShadowDOM を使って共通の場所に作るか app-route を DOM として作らないほうがいいかも
<app-router>
<app-route>
<app-route>
<app-route>
#shadow
<page-header>
<page-content>
<page-footer>
<app-router>
<page-header>
<page-content>
<page-footer>
page-header や page-footer が同じ要素なら使いまわして再作成しないようにする
app-route を作らないなら app-router のプロパティやメソッド呼び出しで DOM ではわからない形でルートを定義する
app_router.routes = [
"/": {},
"/foo": {},
"/bar": {}
]
基本的にはルート定義コンポーネントが直接ページ内の要素を管理しないので ルート定義コンポーネントではルートに対応するページコンポーネントの要素を作って そのコンポーネントがページ要素を管理する構造になるはず
<app-router>
<app-route route="/">
<page-top>
#shadow
<page-header>
<page-content>
<page-footer>
<app-route route="/foo">
<app-route route="/bar">
こうなるとアクティブなときに app-route の子要素に配置しないようにしても
<app-router>
<app-route route="/">
<app-route route="/foo">
<app-route route="/bar">
#shadow
<page-top>
とか
<app-router>
<app-route route="/">
<app-route route="/foo">
<app-route route="/bar">
#shadow
<page-foo>
になって結局ヘッダーなどの要素は共有できてない
ページのコンポーネントじゃなくて共通の部分とページごとの可変部分の親子コンポーネントにすれば良さそう
<app-router>
<default-layout>
<list-content>
<app-router>
<default-layout>
<detail-content>
<app-router>
<special-layout>
<account-content>
*-layout の ShadowDOM 内に *-content を slot で配置
<app-router>
<default-layout>
<list-content>
#shadow
<page-header>
<slot>
<list-content>
<page-footer>
同じ default-layout を使うルート間の移動なら default-layout 要素はそのままなので page-header/page-footer はそのまま維持される
だけど list-content のところで user-list-content と article-list-content があった場合
どっちもリスト系なのでリスト系共通の要素があるけど コンポーネントが分かれるのでここは DOM が異なってしまう
page-header みたいに 同じなら DOM を使いまわしたいなら list-content のところも共通と個別のところを分けて親子構造にする必要が出てくる
<app-router>
<default-layout>
<list-common>
<list-user-content>
#shadow
<page-header>
<slot>
<list-common>
<list-user-content>
#shadow
<list-header>
<slot>
<list-user-content>
<page-footer>
これも大変で面倒だし 実際の DOM にコンポーネントが挟まらない React とか lit-html とかのほうが良いのかも
それ以前に 別に重いとか見た目崩れるとかないなら 無理に DOM の使い回しとかせずページのルートコンポーネントから置き換わっても別に困らないとも思う
今すぐに実行せずに後になってから実行したい処理の書き方で
後で実行する部分を関数にまとめて その関数をどこかに渡しておいて 実行するタイミングで呼び出すのと 「await xxx」 みたいのを書いておいて その後ろに後で実行する部分を書いて実行するタイミングで xxx の Promise を resolve するの
どっちがいいか迷ってて 処理を関数にまとめて渡すほうがわかりやすいかなって気はしてたけど コールバック関数と await と考えたら await のほうが良い気もしてきた
「1 秒後に実行」で考えてみたら await の方かなぁ
でも 複雑になってくるとコールバック関数のほうかも
後で実行する部分を関数にまとめて その関数をどこかに渡しておいて 実行するタイミングで呼び出すのと 「await xxx」 みたいのを書いておいて その後ろに後で実行する部分を書いて実行するタイミングで xxx の Promise を resolve するの
どっちがいいか迷ってて 処理を関数にまとめて渡すほうがわかりやすいかなって気はしてたけど コールバック関数と await と考えたら await のほうが良い気もしてきた
「1 秒後に実行」で考えてみたら await の方かなぁ
function a() {
something()
setTimeout(() => {
something2()
}, 1000)
}
async function b() {
something()
await new Promise(r => setTimeout(r, 1000))
something2()
}でも 複雑になってくるとコールバック関数のほうかも
const items = []
setInterval(() => {
items.shift()?.()
}, 5000)
function a() {
something()
items.push(() => something2())
}
async function b() {
something()
const promise = new Promise(r => items.push(r))
await promise
something2()
}
ページが 1 つで機能も 1 つだけだとコンポーネントに分けても結局データは全部最上位になる
あるデータを管理（ローカルに登録して表示と編集）するツール
機能を分けて 3 つのコンポーネント
● ルートコンポーネント
(1) リスト表示
(2) 選択中の項目のデータを編集
(3) リストの全部を専用ライブラリでグラフィカル表示・選択中はマウス操作で編集可能
編集中データなどは (2) の編集用コンポーネントだけで持ちたいけど (3) のコンポーネントでも編集できる
ルートコンポーネントで編集中も持つと 保存ボタンやリセットボタンが (2) にあるけど 押したことをルートコンポーネントに伝えるだけ
ルートコンポーネントでデータのチェックや保存などが必要
ほとんどがルートコンポーネントの処理になって複雑になってくる
一応ページ全部で 1000 行は超える程度のコード量なので そのほとんどをルートコンポーネントに押し込むのはなんかイヤ
それに (1) ～ (3) はほとんどルートコンポーネントから受け取ったデータの表示と押されたボタンを親に伝えるだけになってる
WebComponents らしい機能は持ってないし WebComponents (lit-element) で書くと長くなるだけ
こういうタイプなら React のほうが楽にかけそう
あるデータを管理（ローカルに登録して表示と編集）するツール
機能を分けて 3 つのコンポーネント
● ルートコンポーネント
(1) リスト表示
(2) 選択中の項目のデータを編集
(3) リストの全部を専用ライブラリでグラフィカル表示・選択中はマウス操作で編集可能
編集中データなどは (2) の編集用コンポーネントだけで持ちたいけど (3) のコンポーネントでも編集できる
ルートコンポーネントで編集中も持つと 保存ボタンやリセットボタンが (2) にあるけど 押したことをルートコンポーネントに伝えるだけ
ルートコンポーネントでデータのチェックや保存などが必要
ほとんどがルートコンポーネントの処理になって複雑になってくる
一応ページ全部で 1000 行は超える程度のコード量なので そのほとんどをルートコンポーネントに押し込むのはなんかイヤ
それに (1) ～ (3) はほとんどルートコンポーネントから受け取ったデータの表示と押されたボタンを親に伝えるだけになってる
WebComponents らしい機能は持ってないし WebComponents (lit-element) で書くと長くなるだけ
こういうタイプなら React のほうが楽にかけそう
onclick みたいなイベントにするから起きるのであって
Promise にすれば 1 回限りのはず
Promise にすれば 1 回限りのはず
document.querySelector("#submit").addEventListener("click", () => {
form.resolve()
})
form.then(async () => {
const response = await fetch("/path/to/api", {
method: "POST",
headers: { "Content-Type": "applicatin/json" },
body: JSON.stringify(values),
})
// response に応じてなにかの処理
})
ライブドアブログの記事 ID は全ブログで共通の ID で連番になってると思ってたけど
このブログは 24387993 みたいに 2 千万番台
メインのブログは 83109131 みたいに 8 千万番台
どういう基準なんだろう？
単に分散処理にしてるのかな
ID が重複したらダメだから ID 作るところは並列処理できないはず
同時リクエストが多いとそこで待ち時間が長くなりそう
一千万ごととかでカウンタわければ カウンタの数で並列処理できるし待ち時間減りそう
とは言っても ID 振るのなんてミリ秒単位の処理だと思うし Twitter とかならともかくライブドアブログの規模で必要なのかなとも思う
このブログは 24387993 みたいに 2 千万番台
メインのブログは 83109131 みたいに 8 千万番台
どういう基準なんだろう？
単に分散処理にしてるのかな
ID が重複したらダメだから ID 作るところは並列処理できないはず
同時リクエストが多いとそこで待ち時間が長くなりそう
一千万ごととかでカウンタわければ カウンタの数で並列処理できるし待ち時間減りそう
とは言っても ID 振るのなんてミリ秒単位の処理だと思うし Twitter とかならともかくライブドアブログの規模で必要なのかなとも思う
ページ指定で「page=2」みたいのにするか
「from=20201001120000」や「max=5000」みたいにタイムスタンプや ID を使うか
後者のほうが長く複雑には見えるけど扱いやすいはず
page だと追加があると次のページの最初に前のページの最後のが入ってきて重複することがあるし
そのわりにページのほうが主流なのはなぜだろう
キャッシュのしやすさ？
＝追記＝
ブログのページャの感じで考えてたけど 表形式での表示とか考えるとやっぱり page の方が良さそう
id 指定の方法はソート対象が色々あると大変
id 順じゃないのに id を指定してこれの次からってやるのは効率悪い
ソート対象でクエリが変わることになるし ソートする列がユニークじゃないなら同じ値のどこから取得すればいいかわからない
列ごとに▲▼ボタンをつけて何でもソートできるなら page が楽そう
フィルタはしても id 順しかないものだと id 指定でその続きから取得でも大丈夫
ちなみに Github のコミットログはハッシュ値の before/after でページャしてる
「from=20201001120000」や「max=5000」みたいにタイムスタンプや ID を使うか
後者のほうが長く複雑には見えるけど扱いやすいはず
page だと追加があると次のページの最初に前のページの最後のが入ってきて重複することがあるし
そのわりにページのほうが主流なのはなぜだろう
キャッシュのしやすさ？
＝追記＝
ブログのページャの感じで考えてたけど 表形式での表示とか考えるとやっぱり page の方が良さそう
id 指定の方法はソート対象が色々あると大変
id 順じゃないのに id を指定してこれの次からってやるのは効率悪い
ソート対象でクエリが変わることになるし ソートする列がユニークじゃないなら同じ値のどこから取得すればいいかわからない
列ごとに▲▼ボタンをつけて何でもソートできるなら page が楽そう
フィルタはしても id 順しかないものだと id 指定でその続きから取得でも大丈夫
ちなみに Github のコミットログはハッシュ値の before/after でページャしてる
考えてみると
ができるなら
ができてもいいと思う
(x || y).prop = 1
ができるなら
(x || y) = 1
ができてもいいと思う
色々使ってるとどれかに揃わないので最近の使い分け
ちょっとしたもの:
lit-html もしくは Preact+htm
少し規模が大きくなる:
WebComponent を使いたい:
lit-element もしくは WebComponent を生で
WebComponent を使いたくない:
ES Modules を使いたい:
Preact+htm
Webpack する:
React+JSX
気分を変えて:
hyperhtml
エディタの機能でコメントとかを消したい
丁寧にコメントやら書いてくれてるコードもあるんだけど 基本的に見ないしむしろ邪魔
無いほうがスッキリ全体が見えるし 読みやすい
正規表現とか使って手動で全部消してみることはあって見やすくはなるんだけどやっぱり面倒だから自動でエディタ側の機能としてやってほしい
基本読むときに欲しいのは実際に行う処理のロジックだけ
その他メタデータみたいなのはノイズになる
そこで明確な型が何かは重要じゃないし メソッドやプロパティなどの名前でだいたい何するかはわかるしそれで十分
コードじゃ何してるかわかりづらいなって思うことがあってはじめてコメントを読む
型定義も ここの具体的な型を知りたいなって思うことがあってはじめて見たくなる
だから普段はなくていいし 非表示にしておきたい
ボタンで表示切り替えしたり マウス乗せると表示したりにして普段は隠れててほしい
英文のページを自動翻訳で読んでるときに よくわからない文が出てきたときに原文と切り替えたりマウス乗せて原文見る感じ
全文が日英両方出てると邪魔だしね
漢字に全部ルビ振られてると邪魔だから基本消したいというのにも似てるかも
丁寧にコメントやら書いてくれてるコードもあるんだけど 基本的に見ないしむしろ邪魔
無いほうがスッキリ全体が見えるし 読みやすい
正規表現とか使って手動で全部消してみることはあって見やすくはなるんだけどやっぱり面倒だから自動でエディタ側の機能としてやってほしい
基本読むときに欲しいのは実際に行う処理のロジックだけ
その他メタデータみたいなのはノイズになる
そこで明確な型が何かは重要じゃないし メソッドやプロパティなどの名前でだいたい何するかはわかるしそれで十分
コードじゃ何してるかわかりづらいなって思うことがあってはじめてコメントを読む
型定義も ここの具体的な型を知りたいなって思うことがあってはじめて見たくなる
だから普段はなくていいし 非表示にしておきたい
ボタンで表示切り替えしたり マウス乗せると表示したりにして普段は隠れててほしい
英文のページを自動翻訳で読んでるときに よくわからない文が出てきたときに原文と切り替えたりマウス乗せて原文見る感じ
全文が日英両方出てると邪魔だしね
漢字に全部ルビ振られてると邪魔だから基本消したいというのにも似てるかも
ログイン前後でもページの読み込みはしない SPA にしようとしてるのを見て そこ SPA にする必要あるの？って思ってた
ログイン成功時にログイン済みユーザ用 SPA に切り替えればいいじゃん と言う感じ
でも考えてみるとログインしなくても色々見えるサービスってけっこうある (例えば StackOverflow とか Github とか)
自分の場合 そういうのを作ることが全くなくて ログイン機能があるものならログインするまではログイン画面くらいしか見えないものばかり
そんなのだとログイン画面は単体 HTML で済む程度
だけど 未ログインでも色々見えるのならログイン前後で共通コード多いし ひとつの SPA アプリのほうが良いかなと思った
ログイン成功時にログイン済みユーザ用 SPA に切り替えればいいじゃん と言う感じ
でも考えてみるとログインしなくても色々見えるサービスってけっこうある (例えば StackOverflow とか Github とか)
自分の場合 そういうのを作ることが全くなくて ログイン機能があるものならログインするまではログイン画面くらいしか見えないものばかり
そんなのだとログイン画面は単体 HTML で済む程度
だけど 未ログインでも色々見えるのならログイン前後で共通コード多いし ひとつの SPA アプリのほうが良いかなと思った
ファイルやフォルダ名に無意味に番号つけたがる人いますよね
01 foo.txt
02 bar.jpg
みたいなの
あれがすごく迷惑です
音楽 CD のトラック番号みたいに意味のある順番なら全然問題ないと思います
私もそういうものであれば番号をつけます
しかし その並びに意味があるわけでもないのに番号をつけられてるのもあります
個人の PC 内に限れば使う人が並べたいように番号をつけるのは好きにすれば良いと思います
でもそれを共有フォルダなんかでもやる人がいるんです
余計な番号がなければ 名前でソートすればアルファベット順なので目的のものがすぐ見つけられます
ファイルがない場合でもここにあるはずと場所がわかります
t から始まるものは s と u の間です
そこに無いならファイルはないと判断できます
しかし番号のせいでどこにあるかわからないと全体を何度もみることになります
エクスプローラならキーボードで最初の文字を入れるとそこに移動してくれる機能もあります
しかし 番号があるとその番号を知らないとその機能を使えません
番号に規則性があって統一性もあってドキュメント化されているならマシです
例えば github とかにありそうなフォルダ構成だと
のように 00 は bin で 01 は src みたいなものです
番号に対応するものが決まっていて全部のプロジェクトフォルダで統一でその情報がどこかにまとまってるならいいんです
なのに実際は 01 が src だったり lib だったりするし 対応表みたいなものもありません
他の人が見るところで作った人の脳内にしかない番号を勝手につけるのはホントやめてほしいです
日本語の漢字であれば名前の順にして並びがわかりづらいのもあります
しかし普段から PC 使ってればなんとなくどの辺か見当つくこともあります
少なくともドキュメント化されてない番号がついてことに比べると何倍もマシです
日本語の並びのためだけにムダな番号をつけるくらいなら全部半角文字でいいと思います
私自身 分類するためのフォルダを作るときに日本語はまず使ってないですが対して困ってません
最近では減りつつあると思いますが 日本語ユーザ名だと使えないプログラムもあるくらいです
使わなくて済むならフォルダやファイルに日本語を使わないほうがいいと思います
高機能なエクスプローラならフォルダ内でフィルタ機能があるので助かります
番号を無視してフォルダやファイル名の一部を入れるとマッチするものだけ残ります
でも標準のエクスプローラだと検索になって再帰的にフォルダ内のフォルダ内のファイルなども見てしまうんですよね
さらには エクセルや PDF の本文まで見たりする高機能ぶりです
要らないものまで候補に出すぎて探しづらいです
標準ツールしかない場合はアドレスバーに cmd と打ってコマンドプロンプトを表示して
「dir | find "ファイル名の一部"」 コマンドで番号付きファイル名を調べるのが一番早いかもしれません
また これ関連で 「ファイル名は周りに合わせてつけろ」 と言われたみたいな話を聞いたことがあります
「いやそれ無理だろ」 と思いました
規則性もなく並んだ番号にどう合わせるのでしょうか
別のフォルダで同名のものについた番号を探してもその番号が使われてるかもしれないです
適当に番号をつけて見た目だけ ◯桁の番号が付いていて揃ってるようにしてるんだとしたら最悪ですね
どんどん意味不明な番号が増えて探しづらくなります
もしかして日本語の読みとして 50 音順になるように番号つけてるとしたら 間に新しいのが入るとそれ以降を全部ずらさないといけないと考えると……恐ろしい
＝＝ちょっと追記＝＝
上の方の例で 01, 02 のような隙間のない連番を出したので これだと新しいファイルが来たらとりあえず次の数字にすれば良さそうとも思えます
今 13 まであるなら 14 みたいに
作った時期や順番に意味があるところなら 数字を増やすだけの連番だったり日付をプレフィックスにする意味もわからなくはないです
ですが 実際には 10, 20, 30 だったり 100, 200, 250 のような間に何かが入る可能性を考慮した数字だったりするんですよね
さらに 01, 02, 05, 07, 08, 11, 12 みたいに欠番があったり
もう 「連番」 と呼ぶのがおかしいのかもしれませんが こういう状況だったら新しく作ったファイルの番号を何にするかわかったものじゃないですよね
01 foo.txt
02 bar.jpg
みたいなの
あれがすごく迷惑です
音楽 CD のトラック番号みたいに意味のある順番なら全然問題ないと思います
私もそういうものであれば番号をつけます
しかし その並びに意味があるわけでもないのに番号をつけられてるのもあります
個人の PC 内に限れば使う人が並べたいように番号をつけるのは好きにすれば良いと思います
でもそれを共有フォルダなんかでもやる人がいるんです
余計な番号がなければ 名前でソートすればアルファベット順なので目的のものがすぐ見つけられます
ファイルがない場合でもここにあるはずと場所がわかります
t から始まるものは s と u の間です
そこに無いならファイルはないと判断できます
しかし番号のせいでどこにあるかわからないと全体を何度もみることになります
エクスプローラならキーボードで最初の文字を入れるとそこに移動してくれる機能もあります
しかし 番号があるとその番号を知らないとその機能を使えません
番号に規則性があって統一性もあってドキュメント化されているならマシです
例えば github とかにありそうなフォルダ構成だと
- project1/
- 00 bin/
- 01 src/
- 02 lib/
- project2/
- 00 bin/
- 01 src/
- project3
- 01 src/
- 02 lib/
- 03 dist/
のように 00 は bin で 01 は src みたいなものです
番号に対応するものが決まっていて全部のプロジェクトフォルダで統一でその情報がどこかにまとまってるならいいんです
なのに実際は 01 が src だったり lib だったりするし 対応表みたいなものもありません
他の人が見るところで作った人の脳内にしかない番号を勝手につけるのはホントやめてほしいです
日本語の漢字であれば名前の順にして並びがわかりづらいのもあります
しかし普段から PC 使ってればなんとなくどの辺か見当つくこともあります
少なくともドキュメント化されてない番号がついてことに比べると何倍もマシです
日本語の並びのためだけにムダな番号をつけるくらいなら全部半角文字でいいと思います
私自身 分類するためのフォルダを作るときに日本語はまず使ってないですが対して困ってません
最近では減りつつあると思いますが 日本語ユーザ名だと使えないプログラムもあるくらいです
使わなくて済むならフォルダやファイルに日本語を使わないほうがいいと思います
高機能なエクスプローラならフォルダ内でフィルタ機能があるので助かります
番号を無視してフォルダやファイル名の一部を入れるとマッチするものだけ残ります
でも標準のエクスプローラだと検索になって再帰的にフォルダ内のフォルダ内のファイルなども見てしまうんですよね
さらには エクセルや PDF の本文まで見たりする高機能ぶりです
要らないものまで候補に出すぎて探しづらいです
標準ツールしかない場合はアドレスバーに cmd と打ってコマンドプロンプトを表示して
「dir | find "ファイル名の一部"」 コマンドで番号付きファイル名を調べるのが一番早いかもしれません
また これ関連で 「ファイル名は周りに合わせてつけろ」 と言われたみたいな話を聞いたことがあります
「いやそれ無理だろ」 と思いました
規則性もなく並んだ番号にどう合わせるのでしょうか
別のフォルダで同名のものについた番号を探してもその番号が使われてるかもしれないです
適当に番号をつけて見た目だけ ◯桁の番号が付いていて揃ってるようにしてるんだとしたら最悪ですね
どんどん意味不明な番号が増えて探しづらくなります
もしかして日本語の読みとして 50 音順になるように番号つけてるとしたら 間に新しいのが入るとそれ以降を全部ずらさないといけないと考えると……恐ろしい
＝＝ちょっと追記＝＝
上の方の例で 01, 02 のような隙間のない連番を出したので これだと新しいファイルが来たらとりあえず次の数字にすれば良さそうとも思えます
今 13 まであるなら 14 みたいに
作った時期や順番に意味があるところなら 数字を増やすだけの連番だったり日付をプレフィックスにする意味もわからなくはないです
ですが 実際には 10, 20, 30 だったり 100, 200, 250 のような間に何かが入る可能性を考慮した数字だったりするんですよね
さらに 01, 02, 05, 07, 08, 11, 12 みたいに欠番があったり
もう 「連番」 と呼ぶのがおかしいのかもしれませんが こういう状況だったら新しく作ったファイルの番号を何にするかわかったものじゃないですよね
ブログや SNS で●●が動かない バグってる こんなメッセージが出る とか書いてるのって ウェブとかサーバと通信するものだと中の人に特定される可能性ありそう
多くの人に発生して書かれてるものならともかく 発生原因が特殊でケースがほとんど無い場合 サーバ側の調査で該当が数アカウントだとあの人はこのアカウントなのかって特定できそう
まぁ まともなところなら知ってもそれを公開したりはしないだろうけど
多くの人に発生して書かれてるものならともかく 発生原因が特殊でケースがほとんど無い場合 サーバ側の調査で該当が数アカウントだとあの人はこのアカウントなのかって特定できそう
まぁ まともなところなら知ってもそれを公開したりはしないだろうけど
