リストや表の表示のコンポーネントを見てると 全件データがある前提で JavaScript 内でフィルタやソートやページングしてるのをみることがけっこうある
検索ページで検索条件やソート・ページが切り替わるごとにサーバにリクエストしてリストを表示してるとこれらの機能を役立たせられないし 表示せずデータ受信だけならそんなに時間かからないし 画面開いたときに全件取得して保持して JavaScript で検索やソートでいいかな
新規に頻繁にデータが来て直ぐに反映したいわけじゃなければ 更新は 1 時間に 1 回とかでもいいし
必要ならユーザが更新ボタン押せば再取得とかで困らなそう
全件が何百万件ってデータがあるならともかく数千件レベルなら問題なさそうだし
サーバ側も基本全員に同じデータだから変数上に保持しておいたのをそのまま返すだけでデータベース経由しなくていいし
ありな気がしてきた
Chrome 92 がリリースされた
新しいタブにファビコンがついた
Chrome アイコンの影みたいなの
開発者向け機能だと JavaScript に .at() や crypto.randomUUID() が増えた
新しいタブにファビコンがついた
Chrome アイコンの影みたいなの
開発者向け機能だと JavaScript に .at() や crypto.randomUUID() が増えた
"foo".at(-1)
// "o"
[1,2].at(-1)
// 2
crypto.randomUUID()
// "90b7eb58-6640-4ad4-a546-532783d17513"
const handler = (ctx, name) => (...args) => ctx.prototype[name].call(...args)
const S = ctor => new Proxy(ctor, { get: handler })
使用例
S(Array).reverse([1, 2, 3])
// [3, 2, 1]
S(String).slice("foobar", 2, 4)
// ob
パイプライン演算子が来たりでもないと基本はメソッドで良さそう
数少ない役立つところは map などの関数に入れる使い方
const SString = S(String)
const texts = [" a ", " b"].map(SString.trim)
// ["a", "b"]
毎回 「x => x.trim()」 って書くの疲れるし
文字数的にはそんなにだけど記号打つのが面倒
この方法だと prototype のメソッドを call するのと一緒なのでキャストされる
配列風なものを配列として扱いたいとかでは使えるけど 変換いらずにただその名前のメソッドを呼び出せればいいならこれで十分そう
const handler = (ctx, name) => (value, ...args) => value[name](...args)
const X = new Proxy({}, { get: handler })
const texts = [" a ", " b"].map(X.trim)
// ["a", "b"]
X.trim が引数の trim を呼び出す関数になるなら
parseInt(X, 2) で X のところに引数が入って呼び出される関数にもなってほしい
parseInt そのままではただの関数呼び出しに X が渡されるだけなので一工夫する
const handler = (ctx, name) => (value, ...args) => value[name](...args)
const fn = f => (...args) => a => f(...args.map(x => x === X ? a : x))
const X = new Proxy(fn, { get: handler })
X に関数を渡して その返り値を関数として使う
const hex2dec = X(parseInt)(X, 16)
hex2dec("ff")
// 255
const bit = X(Math.pow)(2, X)
bit(16)
// 65536
見やすさはなんかいまいち
やっぱり構文として対応してほしい
けど PHP では提案があったけど複雑すぎるとかで却下された話を聞いたし JavaScript でも入らなそうな気はする
少し長くなるけどアロー関数でできるといえばできるし 関数本体部分でちゃんと呼び出し形式になっていてどう実行されるかがわかりやすいし
X => parseInt(X, 2)
X => X.trim()
RDB をたまにしか使ってないとロックみたいな複雑なところは こういうときにどうなるんだっけ?と思って毎回調べてたりするのでメモ代わりに
UPDATE 時の WHERE で更新日時が等しいことを条件としていれば上書きされることはないはず と思ってたけど トランザクションが同時実行された場合は
1: トランザクション A が書き換えようとする
条件に一致するので正常に書き換えできる
2: トランザクション B が書き換えようとする
A がコミットされてないので古いバージョンが見えている
条件に一致するので正常に書き換えできる
3: トランザクション A をコミットする
4: トランザクション B をコミットする
5: A の書き換えが消える
になるような気がする
これが困るなら同時実行されないように分離レベルとか設定必要なんだっけ?
試したほうが早いと思ってやってみると PostgreSQL のデフォルトだと特に問題なかった
B 側の UPDATE 時にロックされてて UPDATE が処理されず A 側がコミットされてから処理される
その結果 更新日時が違うので B の更新はされてない
余計な心配だったみたい
UPDATE 時の WHERE で更新日時が等しいことを条件としていれば上書きされることはないはず と思ってたけど トランザクションが同時実行された場合は
1: トランザクション A が書き換えようとする
条件に一致するので正常に書き換えできる
2: トランザクション B が書き換えようとする
A がコミットされてないので古いバージョンが見えている
条件に一致するので正常に書き換えできる
3: トランザクション A をコミットする
4: トランザクション B をコミットする
5: A の書き換えが消える
になるような気がする
これが困るなら同時実行されないように分離レベルとか設定必要なんだっけ?
試したほうが早いと思ってやってみると PostgreSQL のデフォルトだと特に問題なかった
begin;
select * from tt;
id | v | updated_at
----+---+---------------------
1 | 1 | 2021-07-01 09:00:00
(1 row)
update tt set
v = 2,
updated_at = '2021-07-01 10:00:00'
where id = 1
and updated_at = '2021-07-01 09:00:00';
select * from tt;
id | v | updated_at
----+---+---------------------
1 | 2 | 2021-07-01 10:00:00
(1 row)
begin;
select * from tt;
id | v | updated_at
----+---+---------------------
1 | 1 | 2021-07-01 09:00:00
(1 row)
update tt set
v = 3,
updated_at = '2021-07-01 10:00:10'
where id = 1
and updated_at = '2021-07-01 09:00:00';
-- 待機状態
commit;
select * from tt;
id | v | updated_at
----+---+---------------------
1 | 2 | 2021-07-01 10:00:00
(1 row)
-- コミットされたので update の処理が終わる
select * from tt;
id | v | updated_at
----+---+---------------------
1 | 2 | 2021-07-01 10:00:00
(1 row)
-- 更新されてない
B 側の UPDATE 時にロックされてて UPDATE が処理されず A 側がコミットされてから処理される
その結果 更新日時が違うので B の更新はされてない
余計な心配だったみたい
const [a, b] = 1
const [a, b] = null
const [a, b] = {}
こういう処理をしようとすると
1 is not iterable
null is not iterable
{} is not iterable
のようなエラーが出ます
not iterable と言われるので分割代入のところに入れようとしている値がおかしいとわかります
ですがここの右辺が Promise の場合は
const [a, b] = Promise.resolve(1)
undefined is not a function
undefined なんてどこにもないので何を言ってるかわからないエラーです
Promise が右辺になるのは await 忘れでよくあることなのにこのわかりづらさは不便です
ここまでシンプルな行ならともかく 右辺がもっと複雑だとどの部分が悪いのかわからずに困ります
とりあえず 配列の分割代入の行で undefined is not a function と言われたら await 漏れを確認するのがよさそうです
これを実行するとエラーでした
Chrome では
「Promise.all called on non-object」
Firefox では
「Receiver of Promise.all call is not a non-null object」
Promise.all を関数として渡しているので内部的に呼び出されるときに Promise というオブジェクトのメソッドというコンテキストで呼び出されないからですが この制限があると
のように呼び出さないといけなくなって面倒なんですよね
昔は console.log も同じ問題があったのですが 結構前に解決されて
みたいに then に直接渡すだけでも良くなりました
組み込み関数なら全てこういう風にしてほしいものです
this の考え方が関数渡しに適してないので this は消えてほしいです
自動で this を bind 済みにしてくれる記法ができればいいんですけどね
が
と同じになるみたいな
const promises = [
[Promise.resolve(1), Promise.resolve(2)],
[Promise.resolve(3), Promise.resolve(4)],
]
promises.map(Promise.all)
Chrome では
「Promise.all called on non-object」
Firefox では
「Receiver of Promise.all call is not a non-null object」
Promise.all を関数として渡しているので内部的に呼び出されるときに Promise というオブジェクトのメソッドというコンテキストで呼び出されないからですが この制限があると
promises.map(x => Promise.all(x))
のように呼び出さないといけなくなって面倒なんですよね
昔は console.log も同じ問題があったのですが 結構前に解決されて
fetch("").then(x => x.text()).then(console.log)
みたいに then に直接渡すだけでも良くなりました
組み込み関数なら全てこういう風にしてほしいものです
this の考え方が関数渡しに適してないので this は消えてほしいです
自動で this を bind 済みにしてくれる記法ができればいいんですけどね
obj..method
が
obj.method.bind(obj)
と同じになるみたいな
パスワードは完全に自由に設定できるべきだと思います
ユーザが a というパスワードでいいならシステムはそれも受け入れるべきです
それでアカウント乗っ取られても自己責任でそれでいいんです
なのに
「大文字小文字数字を混ぜてください」
「記号を入れてください」
「使える記号はこれだけです」
「文字数は何文字から何文字に収めてください」
「何ヶ月に一回パスワードを変更してください」
「同じパスワードは使いまわせません」
こんな注文がいっぱい要求されることが多いです
ほんとうんざりです
警告として強度が弱いですよ と言われるくらいで無視できるならいいのに強制です
強制したところで簡単なパスワードにしたい人は結局 「passwordA1!」 みたいに最後に大文字数字記号の基本的なのをつけるだけで意味ないと思うんですよね
ここまで要求するならもうシステム側でパスワードを自動生成して「これを使ってください」といえばいいと思うんです
あれがだめこれがだめと言われながらパスワードを考える時間が無駄です
それに システムの自動生成なら使い回し問題もありえないですし
ユーザが a というパスワードでいいならシステムはそれも受け入れるべきです
それでアカウント乗っ取られても自己責任でそれでいいんです
なのに
「大文字小文字数字を混ぜてください」
「記号を入れてください」
「使える記号はこれだけです」
「文字数は何文字から何文字に収めてください」
「何ヶ月に一回パスワードを変更してください」
「同じパスワードは使いまわせません」
こんな注文がいっぱい要求されることが多いです
ほんとうんざりです
警告として強度が弱いですよ と言われるくらいで無視できるならいいのに強制です
強制したところで簡単なパスワードにしたい人は結局 「passwordA1!」 みたいに最後に大文字数字記号の基本的なのをつけるだけで意味ないと思うんですよね
ここまで要求するならもうシステム側でパスワードを自動生成して「これを使ってください」といえばいいと思うんです
あれがだめこれがだめと言われながらパスワードを考える時間が無駄です
それに システムの自動生成なら使い回し問題もありえないですし
https://bodhi.fedoraproject.org/updates/FEDORA-2021-6679746a3d
testing ステータスになってる
Fedora のパッケージのリリースやアップデート情報はこのサイトで見れるみたい
https://bodhi.fedoraproject.org/
ドメインにある bodhi ってなにかと思って調べてたら Fedora のアップデートを管理するウェブシステムの名前でリポジトリもあった
https://github.com/fedora-infra/bodhi
上のは cifs-utils と同じ原因でエラーになってる別パッケージで cifs-utils がこのパッケージを使ってるわけじゃないので cifs-utils の修正とは関係なかった
cifs-utils の方はフォーラムではメンテナの人の個人的な事情でしばらく修正のリリースができないみたいだし まだ修正は先そう
testing ステータスになってる
Fedora のパッケージのリリースやアップデート情報はこのサイトで見れるみたい
https://bodhi.fedoraproject.org/
ドメインにある bodhi ってなにかと思って調べてたら Fedora のアップデートを管理するウェブシステムの名前でリポジトリもあった
https://github.com/fedora-infra/bodhi
上のは cifs-utils と同じ原因でエラーになってる別パッケージで cifs-utils がこのパッケージを使ってるわけじゃないので cifs-utils の修正とは関係なかった
cifs-utils の方はフォーラムではメンテナの人の個人的な事情でしばらく修正のリリースができないみたいだし まだ修正は先そう