JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/07/18(月) 02:42:22.09

>>319
これか。確かに俺が確認したのと同じ事だな。
http://os0x.hatenablog.com/entry/20100916/1284650917

**デフォルトの名無しさん** · 2016/07/18(月) 02:45:40.64

>>322
読めば一瞬で終わってた内容。
おつかれさんｗｗｗ

**デフォルトの名無しさん** · 2016/07/18(月) 02:47:05.64

>>321
まあ今のお前にいくら言っても分からないとは思うが、必要なのは、
「構造的」簡潔さなんだよ。
「記述的」簡潔さではない。
もちろん記述も簡潔な方がいいんだけどね。
とはいえ、構造が簡潔なら記述が複雑になることもないんだよ。

とにかくお前は大きいのをまずは書いてみることだよ。
そうすれば色々と至らなさが分かると思うよ。

**デフォルトの名無しさん** · 2016/07/18(月) 02:49:44.99

>>323
それはない。
俺の疑問はgetTime()が何故いるのか？であって、
add/subについてではないから。

まあこの際どうでもいいが。

**デフォルトの名無しさん** · 2016/07/18(月) 03:01:24.39

また殺人くん呼ばわりのあのアホかな。

あのな、DateTimeというのは、日付と時間だよな。ある一点を指し示す値だ。もっと詳しく言えば、ある内部値を、日付と時間として扱えるようにしたオブジェクトだ。

その、「ある一点を指し示す日付と時間同士を、四則演算する」って凄くナンセンスだと思わない？

ある一点と、ある一点の間の距離は、numberか？
違うよな。
.net見てみろよ。TimeSpan型がある。

例外とかそういう馬鹿な話じゃない。

頭の中を整理して、できて良いかできてはいけないのか精査せえ。

何故getTimeしてるかわからんのか？
エポックとして、一点の情報ではなくなり、原点からの長さとして値を返してると考えるとことができる秒に変換しとるよな。要はベクトルに。

お前高校数学からやり直してこいよ。

**デフォルトの名無しさん** · 2016/07/18(月) 03:02:19.26

>>326
言い忘れ。
「ベクトルなら加減乗除自在だよね」とダメ押ししとくわ。

**デフォルトの名無しさん** · 2016/07/18(月) 03:11:07.49

>>325
> 俺の疑問はgetTime()が何故いるのか？であって、

日付に +1 するときだろｗ

**デフォルトの名無しさん** · 2016/07/18(月) 03:13:48.33

いま普及している言語で、完璧な
構造的簡潔さとやらを備えてる言語ってなんだろうねｗ

重要なのは道具として使えることだよ。
道具として使えるならば簡潔でなくても良かった。

そうやって、制限のある中で今まで
実現してきたんだって。

**デフォルトの名無しさん** · 2016/07/18(月) 05:04:13.15

>>325
ES.nextでvalue-objectやらvalue-proxy、もしくは演算子オーバーロードが議論されてるよ。
まあとは言え今のDateをそのまま対応させるのはナンセンスだし、いろいろ問題あるから、
サフィックスで数値型を拡張できる優秀な案を使って、
1s -> <time>(1s)
2016Y+7M+18D -> <time>(1468767600000s)
3s - 1s -> <time>(2s)
date - 1s -> <date>
の用にできる。

まあその場合もgetTimeが要らなくなるわけじゃない、
勿論今でも単項+演算子使えば要らないので、要らないの定義によるが、
君は結局もっといい形があるじゃん、と言いたいのか、なんなのかよくわからないな。

**デフォルトの名無しさん** · 2016/07/18(月) 23:56:44.27

>>330
基本的には
・getTime要らないなら何故いちいち付いているのか？（全員付けているのか）
・今確かに動いているが本当に引き算は出来るのか？（仕様内なのか）
の確認だから。

今の仕様でもそんなに悪くないけど、直交してないから実装に負担がかかる。
とはいえ今更変更することは無理だし、
新仕様を検討している連中はこの辺全て分かっているだろうから、見守るしかないね。
なおgetTimeが要らないといっているのは引き算時限定であって、（これは経緯を見れば分かるはずだが）
やっぱりlodash君は「前との関連で」の会話が出来ないんだな。
多分ガチのアスペなんだと思う。

とはいえここは匿名掲示板なんだから、俺たちがアスペに対して気を使う必要はない。
（個人を特定して気を使う必要はない）
過去の発言は全部読めるのだから、ちゃんと読み直して付いてこいとしか言えんね。
lodash君の会話の組み立て方では普通は荒らし扱いされる。
それは読み直すことによって多少は改善するから、まずはそれを心がけることだ。

という書き方だと伝わらないのかな？
まあしかしこれ以上面倒見れんが。

**デフォルトの名無しさん** · 2016/07/19(火) 00:27:47.65

> ・getTime要らないなら何故いちいち付いているのか？（全員付けているのか）
たまたま

> ・今確かに動いているが本当に引き算は出来るのか？（仕様内なのか）
仕様に書いているのだから、仕様通り

**デフォルトの名無しさん** · 2016/07/19(火) 00:39:36.64

> なおgetTimeが要らないといっているのは引き算時限定であって、（これは経緯を見れば分かるはずだが）

他にどんな演算子があるかぐらい調べろよｗ

new Date() / 1
new Date() * 1
new Date() % 10
new Date() ** 1
+new Date()
-new Date()
~new Date()
new Date() > 0 (< <= >= も同様）
new Date() << 1 （>> >>> も同様）
new Date() & 1
new Date() | 1
new Date() ^ 1

これらも仕様通りgetTime()はいらない。

というか逆に+のときだけgetTime()が必要と思ったほうが良いぐらい。
+は文字列結合と数値の加算の二つの意味があるから、仕方なくこうなってしまったという話。
（それ以外は二つの意味はない）

**デフォルトの名無しさん** · 2016/07/19(火) 00:48:15.24

> 今の仕様でもそんなに悪くないけど、直交してないから実装に負担がかかる。
> とはいえ今更変更することは無理だし、

直すならばDateの仕様ではなく、+オペレーターの方。
Perlみたく、+ は数値演算、 . で文字列結合とするしかない。

**デフォルトの名無しさん** · 2016/07/19(火) 01:05:34.97

どうやら俺の発言が気に食わないようだが
俺に比べて技術と知識も劣ってるから、
getTimeがいらないのは引き算限定とかいう
発言で反論しようとするんだよなｗ

一般論として技術力が高い人ほど多くのことを
知っているんだよ。知ってるからこそ技術力も高くなる。
関数型プログラミングはいいよ。コードがシンプルになる。
lodashやjQueryは便利なライブラリ。

**デフォルトの名無しさん** · 2016/07/19(火) 02:25:00.57

相変わらずアスペ全開だな。

まあついでに言っておくと、JavaScriptの連中は仕様書を書いている連中すらゴミだってことだ。
オブジェクト指向を理解出来てない。

Type固有の案件は全部15章に突っ込まないと駄目だ。
11章の演算子(+)に書くとか、親クラスのメソッドに子クラス毎にif文入れているようなものだ。
あの仕様書では頭からお尻まで全部読まないと理解できない。典型的な駄目コードだ。
だから俺も読み込むまでに余分に時間がかかった。

var Object = {
operator+: funciton() {
if (typeof(this)==='Date') // 11.6.1 NOTE1 // 現行仕様書
}};

var Date = {
operator+: function() { // 15.9.X　// こっちに書くべき
}};

Type固有の例外規定が15章に書いてない時点で仕様書の構造がゴミ。
但し書きはダブって良いので、15章にも書き、そっちがオリジナルであるべき。
上記上側みたいに、Dateオブジェクトの特別扱いを、子クラスでメソッドをオーバライドせず、
親クラスのメソッドにいちいちif文入れてこられたらキレるだろ？
上記下側のように、子クラスでオーバライドした上で、
親クラスのメソッドに「Date型ではオーバライドされています」とコメントを付けておくべき。

**デフォルトの名無しさん** · 2016/07/19(火) 02:25:35.18

お前らの大半はこれにすら気づけないと見ている。
正直、JavaScriptの連中が上達してないのはかなり根が深い問題だと認識し始めてる。
仕様書すらこれだ。
多分君らの大半は何が良いコードなのかも理解出来ていない。
それはまともな構成の仕様書/コードを見たことがないからだ。
これについては、丁度OOPのスレでそれを問う勇者がいたから見てくるといい。(今は死にスレだが)
http://echo.2ch.net/test/read.cgi/tech/1467992113/10
http://echo.2ch.net/test/read.cgi/tech/1467992113/65

例えば仕様書だけでもまともであれば、
無意識的にオブジェクト指向を学習出来たはずなのだが、そうなっていない。
この酷い仕様書を読むまでは気づかなかったが、
当たり前だが他言語の仕様書は達人が書いているので、こうはなっていない。
だから仕様書を読んでいれば無意識的に
オブジェクト指向（正確には著者のプログラミングスタイル）も学習していける。
JavaScriptにはこれがない。つまるところ、教科書が悪いから上達しにくい。
それでも、他人のコードをほぼ全て見える状況は、おつりが来るほど有利だとも思うのだが。

**デフォルトの名無しさん** · 2016/07/19(火) 03:43:57.22

上達くんはトリップ付けてくれよ

**デフォルトの名無しさん** · 2016/07/19(火) 04:38:03.16

自分の能力不足を仕様のせいにまでしてきたねｗ

**デフォルトの名無しさん** · 2016/07/19(火) 04:50:08.67

Dateにオペレータ+を書くとかさ間抜けすぎるっていうかｗ
世の中にはいろんな言語があるってことを知らないんじゃないかねぇ。
そして最高の言語があるとか思ってるんじゃないかねぇ。

JavaScriptにおいて演算子はクラスのメソッド（相当）ではない。
演算子のオーバーロードがないのもクラスのメソッドじゃないからだ。
だから演算子が特定のクラスにつくことはない。

もし+演算子がクラスのメソッドであれば、それはクラスごとに変更可能であるはずだ。
また戻り値も好きに変えられるはずだ。（例えばComplex型+Complex型の結果をComplex型にする等）

だけどJavaScriptではそれは出来ない。といったらJavaScriptは劣ってるとか言うんだろうな（苦笑）
これは言語のコンセプトの違いでしか無い。スクリプト言語としてそういう設計になってる。

JavaScriptにおいて演算の結果は文字列か数値にしかならない。（厳密に言えばNaNとかもあるが）
演算子はクラスメソッドではなく、演算子が使われた段階でオブジェクトはプリミティブ型に変換される。
Date型に対して+メソッドが呼ばれるのではなく、プリミティブ型への変換メソッド（valueOf）が呼ばれる。
その後に演算子の効果が働く。

な？能力が低いんだよこいつは。
自分の知ってる○○の言語の常識でしか考えることが出来ない。

**デフォルトの名無しさん** · 2016/07/19(火) 04:57:24.04

Dateにoperator+を書くべきじゃないと言ったが、
もちろんObjectにも書くべきじゃない。

>>336はさも、Objectにoperator+があるのが
現行の仕様だと言っているが、現行の仕様は
Objectにoperator+なんてものは存在しない。
ObjectにあるのはvalueOfメソッドだ。

そしてObjectのvalueOfメソッドに if Dateなら？みたいなコードはない。
Operator+解釈のアルゴリズムの結果、Date型のvalueOfメソッドが呼ばれるだけだ。
Operator+の処理が実行されるのは、Object（やDate）のメソッドが呼び出される前だ。
それは仕様を読めばわかること。

だからこそ15章 Native ECMAScript objects ではなく、
11章 Expressions に分離して書かれているのだ。

**デフォルトの名無しさん** · 2016/07/19(火) 09:44:05.11

>>336
仕様書が変に構造化されてて読みにくいのは非常にその通り。
でもES2015以降徐々に改善されて行ってるよ。
そういう意味でも最新の仕様書を読んだほうが良い。

で、確かに@@toPrimitiveはビルトインではDateとSymbolくらいにしかついていないので特有だが、
別にこれは外したり自由に付けたりもできるし、処理の流れの中で例外というわけでもない。

**デフォルトの名無しさん** · 2016/07/19(火) 17:59:10.43

頭おかしいのかな。
オブジェクト指向でも、クラス指向ではない。
型は無いに等しい。アヒルの様に鳴き、アヒルの様に歩けば、それはアヒルである、という「見做し」を代わりに使用する。
この2つだけで、何故演算子がその時と場合で意味が変わるか、理解出来るんじゃなかろうか。

知能低すぎなのは、その程度で関数型とか言っちゃってる脳味噌じゃねえの？
valueOfは、見做しの典型だろ。
どんなオブジェクトであれ、どんな経緯でプロトタイプがチェーンされていても、それを辿って一番最初に見つかったvalueOfが使われるんだから。

**デフォルトの名無しさん** · 2016/07/19(火) 19:56:18.15

まあそういう挙動が変だ、嫌だって言うなら
delete Date.prototype[Symbol.toPrimitive]
すれば変えられる。
誰かは言わないけど世の中には
delete Object.prototype.__proto__
とか嫌いで許せない物をまず削ってから始める派の人も居るみたいだしね。

**デフォルトの名無しさん** · 2016/07/20(水) 00:55:34.54

>>344
そー。
if Dateとかナンセンスすぎんのよ。
とりあえずvalueOf呼んで、その実装が誰のものかどのインスタンスのものかなんか気にせず、帰ってきたのが値で、
それ以上でもそれ以下でも無い。

クラスのメソッドとか脳味噌の代わりにウニ詰まってるレベル。
オブジェクトか、オブジェクトのプロトタイプのプロパティに
functionが入ってるだけであって、クラス()のメソッド()でも何でも無い。
関数を一級市民とみなす関数型言語erが、まさかの関数をメソッドと特別扱いするとは。

演算子は演算子であって、それ以上でもそれ以下でもない。その後に効果が働くも何も、それ以外の役には立たんから演算子として、言語として定義されとんのだ。

**デフォルトの名無しさん** · 2016/07/20(水) 02:05:37.37

>>342
> 処理の流れの中で例外というわけでもない
俺が言っているのは、ToPrimitiveを呼ぶことではなくて、
ToPrimitiveのデフォルト値がTypeによって異なっていることだ。
ただしこれについては俺も>>336内では間違っていた。正確には以下。

var Object = {
ToPrimitive: funciton(hint) { // 9.1
if (typeof(this)==='Date') // 11.6.1 NOTE1 // ES5.1仕様書
}};

つまり、15.9 に書くべき内容が、次点の 9.1 にも書いてなくて、 11.6.1 に書いてある。
二重に落とし穴になっている。
そして、当たり前だがNOTE1が例外だと言っている。
というか例外じゃなければNOTEの意味無いだろ。

仕様書のおかしな構造は、おそらく仕様書それ自体を書いたわけではなくて、実装から起こしたからだ。
だから仕様書として妥当な場所ではなく、それが実装してある場所に記述があるのだろう。
とはいえその場合でもこのNOTE1の内容なら 9.1 にあるべきであって、
いずれにしても 11.6.1 にあるのはかなり謎なのだが。
そして、実装から起こすにしても、まともな実装ならそのまま仕様書に焼き直しても上手く行く。
いずれにしてもアレなんだろうさ。

NOTE1（仮): Dateの場合はhintにStringを与えて呼び出す // 11.6.1 にあっても不思議ではない、
　// 336の俺の勘違いはこれ、11.6.1にある点と整合させる為に脳内変換してしまった
NOTE1(ES5.1仕様書）: ToPrimitiveはhint無しの場合、
　Date以外はNumberが、
　DateはStringがhintに与えられたものと見なす
　// ToPrimitiveの動作説明を(+)の説明内に配置？意味不明
　// しかもToPrimitiveの場所(9.1)にはこの説明は無しかよ！マジで頭おかしい

**デフォルトの名無しさん** · 2016/07/20(水) 02:06:29.35

さてES7仕様書を確認してみた。確かに大幅改訂されている。
7.1.1のToPrimitiveの所にNOTEがある。（改善あり）
12.8.3の + の所にはこれまでどおりのNOTE記述、まあこれはあった方がいい。
20.3.4.45にはDate.prototype[@@toPrimitive](hint)が追加されている。（改善あり）
結果、俺が問題だと思った点は全て改善され、妥当な配置になっている。

> そういう意味でも最新の仕様書を読んだほうが良い
ああその通りだ。今後俺はそうするよ。少なくともES5.1仕様書はゴミだ。

> 別にこれは外したり自由に付けたりもできるし、処理の流れの中で例外というわけでもない
それは完全に後付だよ。とはいえ妥当な解決策ではあるが。
最初からNumberならこの部分自体が丸々要らない。
無駄仕様で無駄に膨らむ駄目パターンの典型だ。

とはいえ、ES7には今のところ問題点はないね。
俺もこの解決策を採るだろうし、仕様書としても今現在俺が検出した問題点は全て解決済みだ。
徐々に改善されているのは事実だね。

ただまあ、20年も経とうとしているのにこのレベルの改善を未だにやっていること自体が問題だが。
他言語の仕様/仕様書なら、最初からこんな問題は存在しない。
というか、ブレンダン・アイクは何で仕様書を書かなかったんだろう？
彼が第1版を書けばこんな事にはならなかったはずなんだよ。

>>344
ググったらヒットした。で、試してみた。
が、効果あるか？特に何も変わらない気がするが。
ES6フラグとか指定必要？

**デフォルトの名無しさん** · 2016/07/20(水) 02:09:56.99

あ、ちなみに試したのは後者、間違いないようにもう一度書いておくと、以下ね。

> delete Object.prototype.__proto__

とりあえず期待した効果がない（気がする）

**デフォルトの名無しさん** · 2016/07/20(水) 02:15:43.13

> 他言語の仕様/仕様書なら、最初からこんな問題は存在しない。

そんなわけねーだろｗ
どんな言語でも最初は汚いし
完璧な言語はない。

なによりお前、他の言語と言ってるが、
じゃあ具体的にどの言語だよ？
どうせしらんだろ

**デフォルトの名無しさん** · 2016/07/20(水) 02:31:38.89

>>344
いじってみると、動作の差異を検出出来た。
delete以降は__proto__指定でのプロトタイプ切り替えは出来なくなる。
ただし、リテラルとしてオブジェクト全体を生成する場合は指定が効くという、
極めて中途半端？な状態になっている。

果たしてこれが仕様なのか、もちろん動作自体ももっと確認しないと怖くて使えないが、
これが仕様であれば、意図は分かるし、最初からこうならこっちの方がいい。
ただ、今現在の動作しているコードの中でこれをやるのは無理だね。副作用が怖すぎる。
(つまり、結論としては、仕様だと確認出来ても使わない)

**デフォルトの名無しさん** · 2016/07/20(水) 02:40:40.72

>>350
それがなぜかが判れば、自分がどれだけ間抜けな事言ってるかかわかると思うよ。
アスペならダックタイピングとか、関連用語を詰めてこい。

**デフォルトの名無しさん** · 2016/07/20(水) 03:30:00.35

B.2.2だろ？
他を見てもアクセサとして実装するところまでは仕様のようだから、
deleteに関しても仕様通りの実装になっていれば同じ動作だろう。
しかしObject.definePropertyを使えば同じ事が副作用無しで出来るのに
わざわざdeleteする意味は何？

**デフォルトの名無しさん** · 2016/07/20(水) 07:46:36.40

>>350
まあ多分Object.prototype.__proto__が嫌いな人は
Object.prototypeに余計で醜いの生やすな！って言いたいのもあるだろうから
それで良いんじゃないのかな。

あとまあES仕様は基本的に一箇所に最小限しかかかれていなくて、
慣れていないうちはあっち行ったりこっち行ったりする必要があるが、
逆に言うと基本処理を覚えてパターンに慣れるほどに読みこなしてしまえば、
短い一部を読むだけで理解できるからむしろ楽という事もある。
仕様書いてる人もそうだから、初めて読む人の読みづらさがなかなかわからないんじゃないかな。

**デフォルトの名無しさん** · 2016/07/20(水) 09:31:33.55

このようにJavaScriptの仕様書っていうのは
よく読まれやすい。読んでいるからこそ苦情も出てくる。

それに対して、他の言語の仕様書は読む気すらおきない

**デフォルトの名無しさん** · 2016/07/20(水) 13:30:34.45

処理系と仕様が完全に分離されてるのもどちらかと言うと珍しいのもあるかもな。
RubyやPythonだったら言語学者でもない限りメインの処理系の動き＝仕様ということで納得する部分があるが
JSだと沢山の処理系で動くように作らないといけないからね。

各処理系の対応度合いもまちまちだし、１つの処理系だけ取っても変化が早い。
だから言語仕様書を頼ることが多くなるのかもね。
でも言語仕様書はあくまで言語仕様書であり、リファレンスとは違うので誰にでも分り易いものではないね、

**デフォルトの名無しさん** · 2016/07/20(水) 23:30:45.27

JavaScriptの標準APIがRubyのそれとは違って
大幅に機能が少ないからのは標準化のせいなのかな？
他言語を見習って一気にメソッド増やしてほしいものなんだが。

http://ruby-doc.org/core-2.3.1/Enumerable.html

これらのメソッドの多くがないから、lodashなどに
頼る必要が出てくる。

他言語で標準化されてるならば、JavaScriptに取り入れるかなんて
議論する必要はないと思うんだけどな。

**デフォルトの名無しさん** · 2016/07/21(木) 07:48:11.60

Rubyやらより遥かに後方互換性を切るのが難しいからね。
Rubyやらはなんだかんだ言ってメジャーバージョンアップの時には思い切って互換性を切ることができる。
そこでの一番の問題はユーザーがついてきてくれるかとか、そんなところ。

でもJSは後方互換性を切るとなったら、それが受け入れられるかなんてむしろどうでもよくて、
今あるコンテンツのほぼ全てに影響がないかが大事になる。
それは同等の力を持ったエンジンが複数あり、ユーザーコミュニティではなくエンジン開発陣主体だから。

目線が違うので、便利だから入れようという盛り上がりが起こることは少なく、
今ある特にパフォーマンスや技術的問題を、具体的に解決できる提案が取り入れられやすい。

**デフォルトの名無しさん** · 2016/08/21(日) 21:25:32.47

IndexedDBでdeleteObjectStoreする時にトランザクションが（仕様上）取れなくて、
そのままdb.close()するとエラーになる時があるんだが、これってどうすればいいのだ？
e.target.errorは以下。e.target.transacsionはnull(IDBFactory.openで呼んだ直後）

target:IDBOpenDBRequest
error:DOMException: The connection was closed.
code:20
message:"The connection was closed."
name:"AbortError"

createObjectStoreはtransactionプロパティがあるのでそれでoncompleteを待てるのだが、
deleteObjectStoreは何故かvoidを返す仕様で、待ちようがない。
ならばそのままクローズで良いのかと思いきや、エラーになる。
https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/deleteObjectStore

普通ならIDBDatabase.transactionがプロパティでそこから辿れるはずなのだが、メソッドだし。
deleteの時にトランザクションがないわけがないし、
それにアクセス出来ないのは仕様上の欠陥だと思うが。
createObjectStoreがobjectStoreを返すのは便利で良いが、本来はTransactionを返すべき。
だったら空オブジェクトにtransactionプロパティだけでも付けておいてくれないと対応出来ない。

なおヒット状況は、
1. あらかじめIndexedDBに500個ほどオブジェクトストアを作っておく。
2. open直後にそのうち3つほどを連続して消す。
3. クローズ。
この3のタイミングの取り方が分からない。

IndexDBは初めて使うので、使い方が間違っていたり、
或いは大幅に勘違いしてるかもしれないけど、その辺も含めてよろしく。
なおアプリとしてはもう一度削除されるだけなのでクリティカルな問題ではない。

**デフォルトの名無しさん** · 2016/08/21(日) 22:46:27.65

>>358
createもdeleteもversionchangeでしか使えんだろう。

**デフォルトの名無しさん** · 2016/08/21(日) 23:07:56.19

createObjectStoreも単発で作るだけなら同じかもしれないが、それは試していない。
こちらの使い方では以下サンプルの通り、
createObjectStore直後にobjectStore.transaction.completeで書き込みを行っているので、
書き込み側では今のところ問題はない。

> 「データベースを構築する」からの抜粋
> var objectStore = db.createObjectStore("customers", { keyPath: "ssn" });
> objectStore.transaction.oncomplete = function(event) {
> }
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB#Opening_a_database

ちなみにcreateObjectStoreのtransactionは複数作成しても同一なので
(oncompleteは最後に1回呼ばれるだけ）
おそらくdeleteObjectStoreのトランザクションとも同一。
だからこれが見えれば問題は解決出来るはずなのだが、辿り方が分からない。
（というか仕様上抜けているように見える）

**デフォルトの名無しさん** · 2016/08/21(日) 23:34:58.54

ちなみにcreateObjectStore/deleteObjectStoreを常用しようとしている。
APIを見る限り、確かにこれは通常想定されている使い方ではないようだが、
versionカウンタが64bit整数だから出来ない使い方でもない。

管理上最適な階層にすると、今回はcreate/deleteを常用する事になる。
だからそれが出来るかどうか試している。（実用に耐えるかどうか）

**デフォルトの名無しさん** · 2016/08/21(日) 23:35:23.04

トランザクションはversionchange全体で１つ

**デフォルトの名無しさん** · 2016/08/21(日) 23:45:38.76

>>360
ハンドラに代入したらそりゃ一回だけじゃねえの？
addEventListener使わないのはどうして？

複数作成しても同一、ってなんで複数作成する必要があるの？
トランザクションと同じ、の根拠何なの？
onupgradeneededでしか使えないんじゃなかったっけ？
消す意味がわからんのだけど、なんで消したいの？
消さなきゃいけないなら保存なんかしなけりゃ良いと思うんだが。

createObjectStoreがなんでtransaction帰すべきなの？
ObjectStoreをcreateしたのに。
一つのストアから、2つ以上のトランザクション作りたい場合に詰むんじゃねえの？

なんか根本的に間違ってない？

**デフォルトの名無しさん** · 2016/08/21(日) 23:48:10.59

なぜ、ストアごと消す必要があるんだろう。
中身だけ消せばいいんじゃねえの？clear一発っしょ。

**デフォルトの名無しさん** · 2016/08/22(月) 00:02:44.22

中身だけ消す使い方も出来るが、それだと名前対応の辞書引きが必要になる。
管理上「最下層の名前＝最下層のobjectStoreの名前」が一番簡単だからそうしている。
アクセス/追加/廃棄単位もこれと同一だから、管理上はそこにobjectStore階層を置きたい。
もちろんキーに全部含めてフラットに扱うことも出来るが、
元々階層オブジェクトなのをフラットにしてDBに負荷をかけるのは本末転倒だ。
それでコードが楽になるならメリットもあるが、今回はそうではないし。

今回は完全に階層オブジェクト（末端はファイル）だからIndexedDBの必要はないのだけど、
FileSystemAPIだとChromeしか使えない。
これについてはFireFoxはIndexedDBを使えという主張らしく、
確かに機能的には上位互換だから、動作が十分に軽ければ問題ない。だからそれを試している。
https://dev.mozilla.jp/2012/07/why-no-filesystem-api-in-firefox/
http://www.html5rocks.com/ja/tutorials/file/filesystem/

**デフォルトの名無しさん** · 2016/08/22(月) 00:09:17.75

ファイルって何に使ってるの？
最悪消えても良いのならCacheStorageもあるが。

**デフォルトの名無しさん** · 2016/08/22(月) 00:15:46.53

>>362
確認した。おそらくそのようだ。
> Transactions of this mode cannot run concurrently with other transactions. Transactions in this mode are known as "upgrade transactions."
> https://developer.mozilla.org/ja/docs/Web/API/IDBTransaction
そしてこの"upgrade transactions."がどこのプロパティに現れるのか知りたい。
つか、一つならdb.transactionにぶら下げといてくれよなと。
createObjectStoreの後にもここにはぶら下がってないね。

**デフォルトの名無しさん** · 2016/08/22(月) 00:23:12.68

>>366
Web上のファイルの保存用途に使う。（アーカイブ）
だからファイルが保存出来れば何でも良い。
(まだFileSystemAPIは試していない)

URLは最初から階層になっているし、それを保つのが管理上一番楽だからそうする。
したがって、DBアクセスの必要はない。
ユーザがライフタイムを完全に管理出来なければならない。
(Web上から削除された時、ユーザ側で削除するか保存するか決める）

CacheStorageはあとで見てみるが、チラ見では新しすぎる感じ。

**デフォルトの名無しさん** · 2016/08/22(月) 00:32:40.08

>>365
頭おかしくなければ、もともと階層オブジェクトなのをフラットに、とか変な事考えなくていいんじゃねえの？
/hoge..../a.php?aaa/bbb
/hoge.../a/aaa/bbb
が同じとかあんじゃん。

url:{
content:Blob,
schema:xxx,
host:xxxx,
port:xxxxx,
path:[aaa,bbb,ccc]
}
とでもオブジェクト作って、pathにインデックス貼れば？
なんの負担でも無いよ。indexで引くDBだからindexedDBなんだし。
階層構造を保存するためにハードディスクが階段の形してるなら寝言続けて。

**デフォルトの名無しさん** · 2016/08/22(月) 00:36:42.04

>>366
CacheAPI見てみたがライフタイムの管理がよく分からん。
「ユーザ側からの削除無しなら永久保存」（つまりファイルと同じ）に出来る物なの？
https://developer.mozilla.org/ja/docs/Web/API/Cache

あとIndexedDBはFireFoxがそういっているから試してみているだけであって、
FileSystemAPIだとWindowsから直接コピーとか出来るはずなので、
結果的にアーカイブの管理が楽にはなるから、そっちを使うかも。

いずれにしても今は試している段階だ。
何か情報あればよろしく。

**デフォルトの名無しさん** · 2016/08/22(月) 00:42:53.49

自分はすごく考えた結果、こうする他がない、でもわからん。不自然な答えになる。そのやり方は不自然なやり方だからどこにも載ってないから教えてってときに、情報出し渋るなよ。
どう考えても自分の発想が間違ってる以外の結論出ないんだから。

>>370
しかしなんでパスをインデックスに出来ないの？
限界サイズは一番でかいか無限だよ。IndexedDBは。

**デフォルトの名無しさん** · 2016/08/22(月) 00:43:11.87

>>369
それも何の負担もないが、
元のURLもクエリを含まないからそのままでも全く負担無いんだよ。
だからその方法ではコードは楽にならない。

仮にFileSystemAPIを使ったとして、
Windowsから直接ファイルをアクセス出来れば、
アーカイブが要らなくなった時にエクスプローラから削除出来るでしょ。
直感的に一番簡単。

それを意味無くフラットなDBにしてしまったら、
そのアプリいちいち起動しないとあれこれ出来ないでしょ。
バグってて削除出来ないとかもあり得るわけでね。そういうこと。
他アプリとインタフェースが揃っているのは重要なんだよ。
仮にIndexedDBも結果的にWindowsファイルの階層として見える形で
objectStoreを置いてくれていれば、同様のことが期待出来るわけだし。

**デフォルトの名無しさん** · 2016/08/22(月) 00:49:08.43

>>371
出し渋るも糞もアーカイブだと言ってるだろ。
パスはインデックスにするよ。ただしフラットにはしない。
限界サイズはndexedDBよりも多分FileSystemAPIの方が上だ。

**デフォルトの名無しさん** · 2016/08/22(月) 00:56:03.75

IndexedDBの容量制限は実質1/10*HDDね。
https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

多分FileSystemAPIには上限がない(HDDの上限だと信じている）

繰り返すが、今回は元々アーカイブ用途だからそもそもDBアクセスの必要はない。
（横断的クエリとか検索とかは全く必要ない）
ただ、機能的には上位互換だから動作に問題なければそれでもいい。それだけ。

**デフォルトの名無しさん** · 2016/08/22(月) 01:07:03.73

>>372
は？消すのはエクスプローラーなの？

意味なくフラットなぁ。
十分に意味のあるフラットだと思うけど。
バグって削除できないから、だから最初の発想では毎回ストアを作って破棄します、なんて考え方だったの？あきれた。
upgradeはなんなのか。

dir /S/Bした結果だから余程見慣れてると思うけどね。
WindowsWindowsって気持ち悪いけど。
べつに、どのフォルダ以下、って、キーの先頭xxxxxx文字が指定のもの、なんだし、特に変わらんと思うんだけど、
お前の中で違うならそうなんだろう。

フラットに見えるものが、フラットではないと思うのがよくわからなすぎて悩むわ。
indexedDBには文字列しか保存できないと思ってんのかな。

フラットにはしない！って、じゃあどうやってWindowsってフォルダの構造保存してるんだろう。
って考えたら、
フラットなものに保存されてる事気づくと思うんだけど。

>>374
だから、実際のサイズ調べてこいよ。
クォータまでだよ。
それに、残念だけど、フォルダとして見られる物じゃないよ。

**デフォルトの名無しさん** · 2016/08/22(月) 01:09:42.35

まさかディレクトリ掘るのに再起使ってるから、平たくする方法がわからんのかな。
そんなに階層階層言うなら、階層構造渡したらそのまんま保存してくれるラッパ作るか、
バイナリの保存はちょっと考えなきゃならんがブラウザ版nedbでも使えばいいのに。

**デフォルトの名無しさん** · 2016/08/22(月) 01:16:58.93

>>370
保証はされていないが、一般的な環境ではまず問題ない。
というかIDBも実際は永続性は保証されていない。
Fxだと保証されているのは非標準のオプションを指定した時のみで、
他のブラウザでも基本的に一時的なものでディスクが埋まった時は利用頻度の少ないものから削除される。
トランザクションだって完璧でない。実際はパフォーマンス向上のためにディスクの書き込み完了を待たない。

**デフォルトの名無しさん** · 2016/08/22(月) 01:19:31.86

>>375
> それに、残念だけど、フォルダとして見られる物じゃないよ。
そうか、これは残念だ。

だったらやっぱりFileSystemAPIかな。
削除機能は内部にも付けるけど、
エクスプローラでも追加/移動/削除出来た方がいいのは自明だろ。
他アプリとの連携もし易くなるし。

まあお前が色々勘違いしているのは分かるけど、
既に言っていることばかりだから読み返してくれ。

**デフォルトの名無しさん** · 2016/08/22(月) 01:25:17.05

>>378
だから、FileSystemApiがだよ。
フォルダとしては見られないか、超掘り返さないと見れないよ。
更にいうと、エクスプローラでなんなりするべきものじゃない。

それはもう、Electronかなんかで作れ。な？

お前が勘違いしてるのは、多分indexedDBへの保存の方法だとの思うけど。
そのために必要な階層構造を保ったまま、indexdDBに十分入れれるからな。

**デフォルトの名無しさん** · 2016/08/22(月) 01:25:40.46

まぁ、インスペクタでは表にしかならんだろうけど。

**デフォルトの名無しさん** · 2016/08/22(月) 01:30:27.67

>>377
了解。ありがとう。

アーカイブ用途なのでトランザクションに関しては問題ない。
再ダウンロードして保存すればいいだけだから。
機能は、Web上で削除されたファイルをまだ削除されていないように見せかけるもの。
それが永久だとアーカイブということになる。

CacheAPIは多分この用途に作られているから、
それが使えるのならそっちを使った方が色々すんなり行くのだろうね。
プロキシとして機能してくれるなら、いちいちObjectURLに張り替える必要もなくなるし。
全体として楽になる。

ただ永久保証無しなら、何らかの形で抽出機構が必要になる。
これがちと面倒か。
多分CacheAPIの区画を「永久」「一時」とユーザー側で指定出来れば一番良いのだけど、
無理だよね？

**デフォルトの名無しさん** · 2016/08/22(月) 01:33:03.22

>>379
JavaScriptオブジェクトそのまま突っ込めるって話だろ。
もう試したが、今回の用途にはメリットがないんだよ。

**デフォルトの名無しさん** · 2016/08/22(月) 01:34:46.91

>>379
> だから、FileSystemApiがだよ。
え、マジで？

**デフォルトの名無しさん** · 2016/08/22(月) 01:38:12.92

>>382
そのままじゃなくて、書き加えて保存できるし、
その任意のプロパティをインデックスに出来るよ。

お前の言うフォルダ名も、そのままでも、セパレータで分割しても、両方でもインデックスとして保存できる。

このフォルダ以下、これと同じ階層のもの、ファイル、全部綺麗に管理できるんだけどね。

これをフラットだからダメ、って言うなら、
一つのオブジェクト入れるオブジェクトに好きなだけツリー構造こしらえれば良いのかもしれん()が。

ノータリンに説明した時間が無駄だったな。

**デフォルトの名無しさん** · 2016/08/22(月) 01:44:52.41

>>384
とりあえず384に書いていることは全部知っているぞ。
ただそんなことせずともURLそのままで保存すれば良いだけなんだよ。
サーバ側でそれなりに考えて階層化されているわけでね。

**デフォルトの名無しさん** · 2016/08/22(月) 01:53:36.82

>>385
はぁ。そうですか。
それでidb程度が使えないというか、わけわからん仕様出してくるとは、「それなりに考えて」階層化してるものが、表型DBに落ちてりゃ最高に面白いけど、フォルダ()なんだろうな。
好きに悩んでバギーなもの作ればよろし。

**デフォルトの名無しさん** · 2016/08/22(月) 01:59:36.01

ブラウザの枠越えてフォルダがどうとか言うなら普通にWindowsアプリ組めばいいんじゃないのかな。
ブラウザはブラウザでサンドボックスになってるから良いのに。

**デフォルトの名無しさん** · 2016/08/22(月) 02:02:44.31

>>386
いや何を勘違いしているのか知らんが、コードはもう動いているし今はテスト中だぞ。

まあそれはさておき、FileSystemAPIが異なるファイルシステムを使っているのは
確定ではないがどうやらそのようだ。
というかこれだとWeb屋は言葉を間違っている。

サンドボックス：その内部で何をやっても外部に影響はない
ブラックボックス：その内部がどうなっているか外部からは見えない

ブラウザストレージはサンドボックスである必要はあるが、
ブラックボックスである必要はない。というかFileSystemAPIならなおさら。
てかマジでブラックボックスならFileSystemAPIの存在価値無いよ。
これだとFireFoxの言うとおりだと言うことになる。

何で意味無くブラックボックス化してんだ？

**デフォルトの名無しさん** · 2016/08/22(月) 02:14:19.68

>>388
サンドボックスだ、としか言ってないし、
ブラックボックスではない、とは言ってないからいいんじゃねーの？
動いててテストフェーズなのに未実装機能あるなんて面白いのか面白くないのかわからんな。

だから言ってんじゃん。
それゴミ。idbの方がはるかにマシ。
要はクロームアプリ同士で、ファイルが筒抜けにならんように隔離してみました、って感じ。

**デフォルトの名無しさん** · 2016/08/22(月) 02:22:51.64

>>389
いやFileSystemAPIと言うからにはエクスプローラで操作出来ないと駄目だろ。
機能としてはIndexedDBの方が上位互換なんだから、
独自ファイルシステムなら存在価値がない。

> 要はクロームアプリ同士で、ファイルが筒抜けにならんように隔離してみました
この必要あるの？
具体的に言えばアプリのシグネチャ？でも混ぜ込んであるって事？
ローカルストレージが共通なのが多少問題だったから仕切ったってわけか？

**デフォルトの名無しさん** · 2016/08/22(月) 02:50:07.77

あー、つかお前らがよく使う言葉思い出したわ。

IndexedDBでもFileSystemAPIでも、
内部データを「追加/移動/削除」する為の機能を自分で作るのは、
「エクスプローラーの再開発」(車輪の再開発）なんだよ。

Windows上のエクスプローラーが使えたらそれが一番良いだろ。
ドラッグアンドドロップやプレビューの機能は全部持っているし、バグもないし。
つか何故いちいち「マイエクスプローラー」を開発しなければならんのよ？

これが>>379の勘違いに対するお前らの言葉での答えね。
そしてChromeは「マイエクスプローラー」の開発を強制するわけだ。
アホかねと。

**デフォルトの名無しさん** · 2016/08/22(月) 07:34:32.01

>>390
ブラウザってパソコン以外にも乗るじゃん。
その時、ファイルシステムなんて存在しないかもしれないよ。
って話。

>>390
例えば、なんかのアプリで保存したパスワードなんかを、別のアプリから覗き見出来ないようになってる。

>>391
世界中の人がWindowsのエクスプローラやマックのFinder使ってるから訳じゃないんだよw
内部データを追加、移動、削除するってのは、つきつめたらそれが機能なんだから。
お前が使いたいのがたまたまエクスプローラなだけだから、そう思うんだろうけど。
マイエクスプローラーではなくて、自分が使いやすいUI作れよ。
それか、どっかポート開けてwebDAVででも晒してローカルでマウントさせろ。

**デフォルトの名無しさん** · 2016/08/22(月) 10:56:09.85

どうしてこういう人は、ライブラリを作ろうとはしないんだろう。
ディレクトリ一覧を帰す関数、あるディレクトリのディレクトリとファイル一覧を帰す関数、ファイルを新規、取得、更新、削除する関数を作っときゃ、それらの下回りがindexedDBだろうがサーバ関数だろうが関係無く透過的に扱えんじゃねえの？
それこそ、内部実装無視してindexedDBに行ごとに入れようが、クソでかいオブジェクトとして入れようが、はたまたサーバに入れようが、ご希望の動きがすぐ書けると思うんだけど。

**デフォルトの名無しさん** · 2016/08/22(月) 21:30:14.52

すまぬ、>>358は間違い。
upgradeのときはe.target.transactionが最初から入っている。
昨日も確認したのだが、どうやら間違えたようだ。
これで修正出来たかは確認中。

これとは別に、createObjectStoreのoncompleteが少し早いタイミングで返ってくるらしく、
oncomplete直後にput等をせずに終了するとエラーになる。
これはupgradeのtransactionが並列出来ないということなので、
一旦closeして開きなおして並列性を高めようとしたが、失敗した。

**デフォルトの名無しさん** · 2016/08/22(月) 21:40:34.14

>>392
未来のストレージがどうなるかは別の話だ。
FileSystemAPIはオレオレエクスプローラの再開発をしなくて良いのが利点であって、
それがないのならゴミでしかない。
お前が色々再開発をするのは勝手だけど、大多数の人にとっては、
普段使っている物がそのまま使えるのが一番分かりやすいUIだ。

Webアプリ間での相互アクセスを禁止するのはいいとして、
OSからの透過アクセスを禁止する意味はない。
ブラウザアプリからは常にブラウザ経由になるのだから、
アクセス権限、unixで言う644とか755とかを管理するのが一番簡単。
何でそんな糞仕様にしたのか意味不明。

ていうかChromeではBlobをIndexedDBにいれれないのか。使えねえ。
IndexedDBで両対応という作戦は頓挫した。根本的に練り直しだ。
てかマジでこの辺統一しろよな。
> While Firefox supports blob storage for IndexedDB,
> Chrome currently does not (Chrome is still implementing support for blob storage in IndexedDB).
> If you are targeting Chrome for your app and you want to store blobs,
> the File System API and App Cache are your only choices.
> However, AppCache storage isn't locally mutable,
> and doesn't allow for fine-grained client-side management.
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Introduction

**デフォルトの名無しさん** · 2016/08/22(月) 21:41:45.37

>>393
それはお前が無能だからお前の周りも無能しかいないだけ。

**デフォルトの名無しさん** · 2016/08/23(火) 00:24:48.05

>>395
なら、エクスプローラーで管理しろよもう。
文句ばっか言って鬱陶しいわ。
electronでざっくり作るか、いっそcsで書けば？Windows()だけでしか動かないクソアプリを。

>>396
お前の事言ってるの。
俺はライブラリ作ってるよ。
オフラインアプリ用のスクリプトも画像も、ServiceWorkerとindexedDBで全部賄ってるから、「出来るのに技術的な問題だと思いこんでカスだなこいつ」って思ってんじゃん。

**デフォルトの名無しさん** · 2016/08/23(火) 00:49:53.34

今のところはそのつもりだ。cscriptと併用する。
Unix使いならcron位自分で書けということでいい。
もちろん他にいい方法が見つかったら変更する。

長期的運用を考えた場合、
ブラウザがクラッシュした時に破損する可能性がある場所はアーカイブとしては使えない。
また他アーカイバも既にあるので、それらとの相互運用を考えた場合も、
生ファイルシステムでないと駄目だ。

格好は悪いがこれが運用上は一番マシだ。
まあもうちょっと考えるが。

**デフォルトの名無しさん** · 2016/08/23(火) 01:04:54.52

>>398
生ファイルシステムほど不安定な場所もないと思うけど。
サーバ側mongo,クライアント側nedbで適当に同期すれば？

**デフォルトの名無しさん** · 2016/08/23(火) 01:17:30.72

インストールが必要な時点でアウト。
というかお前は無駄にシステムをでかくする病気にかかっていると思うぞ。

**デフォルトの名無しさん** · 2016/08/23(火) 01:47:37.85

>>400
はぁ。
思い描くものがあれば説明してみ。
大体な、それは不可能と応えていくわ。

**デフォルトの名無しさん** · 2016/08/23(火) 08:05:29.74

システムをでかくする病気って言われても、要件が見えなさすぎるんだししゃーなくない？
サーバ側ではデータベースに入ってんだろ？じゃあリプレイスすりゃいいじゃん。
むしろ、サーバのデータベースは何者かわからん。
アーカイブってなんだそりゃ。何のどんなアーカイブかわからんし、さらにそれが階層構造とか、階層構造はデータベースに入れられない()とか不思議発言過ぎるんじゃねえか？

**デフォルトの名無しさん** · 2016/08/23(火) 08:18:51.01

>>395
お前一体何時の記事見てんだよ。
MDNに頼るにしても最低でもLast updatedくらい見ろ。
もう何年も前にサポートされてるわ。
この手の情報は半年経つともう古い。
そして最終的にはブラウザのissuesやcommitsやソースコードを読まないと確かなことは言えない。
独自実装・勝手解釈・消費期限切れの塊であるMDNに１から１０まで頼るのは危険。

**デフォルトの名無しさん** · 2016/08/23(火) 11:20:47.03

というかね、ミニマムなコード片書いてくれればいいと思うんだが。
書いて、あ、Blob入るじゃんって気づくから。
入らなければbase64なりにして突っ込みゃ良いだけだし。
そのまんま、自分のライブラリになると思うけど。

**デフォルトの名無しさん** · 2016/08/23(火) 11:32:18.33

ファイルが保存できればそれでいい、って言う割には、階層が、とか、自分の実装に凝り固まり過ぎだろ。

ただのrdbでもindexedDBでも
フルパス|[パス,,]|ファイル名|拡張子|中身|更新日などの情報|
って形で保存すりゃなんとでもなるだろ、常識的に考えて。
パスは、
file://
file://home
file://home/xxxxx
file://home/xxxxx/yyyyy
の配列で持っといて。
あるパス以下の物→パスで絞れば一撃
あるファイル→ファイル名で一撃
あるパスのあるファイル名→フルパスで一撃
でカーソル取れんじゃん。
あとはよしなに処理すりゃいいんじゃねえの？その為のトランザクションなんだし。
ディレクトリごとにストア分けて、ディレクトリを削除するのに、トランザクション何個も張る羽目になるっしょ。

**デフォルトの名無しさん** · 2016/08/23(火) 21:49:08.63

>>403
おおありがとう。Blobサポート済みか。
となるとボツではなくなった。
記事は古いとは思ったが、政治的案件は時間では解決しないから、どうせ駄目だと思っていた。

>>401
いやcscript併用案はもう既に動いている。
考え方は簡単で、ブラウザで出来ないのはローカルファイルのサポートだから、
それをcscriptにやらせるということ。
とはいえ読み出しには手動で指定が必要だから、それとどっちがマシかということになる。

俺が勘違いしていたFileSystemAPIは
・ブラウザ側で「あるディレクトリ」を指定。これはブラウザ側で手動でしか出来ない。
(指定方法の取り扱いは「ダウンロード」フォルダと同じ)
・そのディレクトリ以下は読み書き自由。
だった。
もちろん生ファイルシステムでOS側からは直接読み書き変更可能。
ブラウザ側からのアクセスはWebアプリ毎にアクセス権が設定されている。

というかこれ以外のFileSystemAPIなんてゴミだろ。
あの糞仕様なら誰も使わない。使う意味無いし。

JavaScript界隈で思うのは、「使ってない奴」「三流プログラマ」が仕様を策定しているということ。
だから「使えない」「使いにくい」仕様が溢れかえっている。FileSystemAPIがゴミなのもこのため。
従来は仕様策定に関われる時点でそれなりの実力者しかいないからこういう事はなかったが、
良くも悪しくもJavaScriptはWebだって事だね。

>>405
つ薬

**デフォルトの名無しさん** · 2016/08/23(火) 22:55:54.15

exeみたいな実行形式やそのOSで特別な意味を表すシステムファイル等として書き出されちゃまずいので実態は偽装される様になってる。
ゴミというか、実験的で気まぐれな機能。もう何年も更新されていない。
誰も使わない、でもブラウザ内部では使われている。別に広く使われることを期待されていない。
IndexedDBやCacheDBの存在で意義をなくしつつある。
柔軟に検索したいなら前者、そうでないのなら後者をどうぞ。

君が望むようなファイルシステムAPIなどがなかなか策定されないのは幾つか理由がある。
でも技術的要因は取り除かれてきた（例えばPermissions API、Web App Manifest）ので、
あとは需要と雛形とブラウザベンダーのやる気次第。

とはいえ今はCSSや他の比較的低レベルなAPIが盛り上がっていて注力してるから後回しだろう。
W3CのMLを見ても「いくつか議論の余地がある」レベルの関心だ。
今はまだアイディアを貯めている段階だろう。

**デフォルトの名無しさん** · 2016/08/23(火) 23:01:47.75

あーでもやっぱりそろそろ動き出すかもな。
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_6Euwqv366U
これが落ち着けば足回りが揃うから。

**デフォルトの名無しさん** · 2016/08/23(火) 23:50:21.90

>>407
> exeみたいな実行形式
Webアプリから起動出来なければこれは問題無いだろ。
> OSで特別な意味を表すシステムファイル等
要するにシンボリックリンク等で全部筒抜けになる場合だろ。
これも結局Webアプリ側はブラウザを通しての作成しか出来ないので、それを止めればいいだけ。

OS側からシンボリックリンクを貼ったり、exeを置くのは自由でいい。
Webアプリ側でexeを起動出来ず、シンボリックリンク等を作成出来なければいいだけ。
つまりファイルは「データ」としてしか扱えないという、実装するにも至極簡単な制限でしかない。
FileSystemAPIははっきり言って使う気がない仕様を策定してる。だったら策定しない方がマシ。
まあ策定してから捨てるというのがJavaScript流ではあるようだが。

> IndexedDBやCacheDBの存在で意義をなくしつつある。
結局の所、「勝手に削除される可能性がある」時点でアーカイブとしては使えない。
見たところここを保証する気はなさそうなので、
今回俺がこれらをメインに据えることは出来ないし、
どのみち「削除されない」ストレージも必要になると思う。

**デフォルトの名無しさん** · 2016/08/23(火) 23:50:56.04

> Both Microsoft Edge and Mozilla Firefox are implementing the subsets documented in "File and Directory Entries API" for compatibility with Chrome in supporting Directory Upload.
正直これさっさと実装しろというのはある。
ディレクトリ指定出来ればUIが全然簡単になるから。

あとIndexedDBも全然こなれてない。
createObjectStore.oncompleteのタイミングがおかしいのは既に言ったが、(>>394)
それとは別にキューの実装もおかしい。
トランザクションがロールバック単位なので、
当初は各リクエストそのままで500トランザクションとか送ったら
「多すぎてキューに入りきりません」とエラーになった。
普通はキューは動的に確保すればいいので、500程度でオーバーフローとかアホかと思ったが、
そんなことを言っていても仕方ないので数珠繋ぎ方式に変更、トランザクションは数個に絞った。
ただそれでもごく偶に、しかも一つ目のトランザクションで同じエラーがでる。
つまり、IndexedDBのキューの実装はバグってる。
なおChrome50。Vistaなのでこれ以上更新出来ないし。

結局の所、大多数が使っている機能じゃないとバグ報告が上がってなくてバグが残っている。
IndexedDBもまだその程度だよ。安心しては使えない。
ただ従来方式の「ダウンロードリンク」を使うにしても、
1日10万ダウンロードとかになるので大丈夫なのか？という疑問はあるが、これも試すしかない。
（ダウンロードは履歴が残るようになっているので、手動ではあり得ないほどの数になると、
履歴がオーバフローするバグが残っているのではないかと恐れている。
これも知ってたら教えて欲しいが。）

**デフォルトの名無しさん** · 2016/08/24(水) 00:44:52.82

>>406
お前のコードこそ、特定のプラットフォームか外出てるじゃん。
どう使いにくいのかが分かれば良いんだが。
もう老人であたらしいこと覚えられないならご愁傷様。

**デフォルトの名無しさん** · 2016/08/24(水) 00:48:32.19

>>410
トランザクションがROLLBACK単位とか言うか
適宜コミットして、setTimeoutで遅延させてつかえよ。
ボンクラすぎるだろ。

タイミングも合ってるよ。

脳みそ腐ってないならば、ぜんコード上げてみろよ。見てやるから。

**デフォルトの名無しさん** · 2016/08/24(水) 00:52:22.97

IndexedDBが小慣れていないと言われてるのは周知の事実。
が、機能は揃っているので上で言われてるように
大抵皆ライブラリを書いたり、使ったりして問題なく過ごしている。

君のここまでの書き込みは全然建設的じゃないし、
ほんとにバグがあるのか、もしくは君の方がが小慣れていないのかが分からない。
結果、ただの愚痴にしか聞こえずそれに対して何も言えることはない。
せめて再現するための最低限のコードを載せてくれ。

あと10万ダウンロードはやめとけ。ZIPなどに圧縮すればいい。
もしくはもう一般WebAPIだけで作るの諦めろ。
一般公開するかは知らんが、それだけの機能なら
拡張機能もしくはブラウザアプリにしてインストール必須にしても構わないだろう。

**デフォルトの名無しさん** · 2016/08/24(水) 02:09:31.50

>>413
> ほんとにバグがあるのか、もしくは君の方がが小慣れていないのかが分からない。
これはその通り。当初の>>358は間違いだったからね。
ただ仕様は大体理解したので、多分>>394と>>410はバグだ。

とはいえ切り分けはしない。
最新版が使えない状況で切り分けて報告する意味はないので無駄だから。
(最新版では既に治っているかもしれない)
俺については「バグがある」という認識で使うか、使うのを止めるかでしかない。
つまり他の方法も試して一番マシな方法を使うだけ。
ちなみにchromiumに対してバグ報告もしたことあるし、受け付けられてもいるよ。
ただそれをやるにしてもここでやる意味はない。直接報告すればいいだけ。

コードはここには上げない。
コピペすればいいだけのコードすら協力してくれないお前らに対して期待はしていないし、(>>270,279)
話を聞く限りお前らの腕前/デバッグ出来る範囲を完全に超えている。
コードを上げてもお前らでは何も出来ないよ。
いずれにしても既に公開はしているから、勝手に探せばいい。

100kダウンロードはその話だと試したわけではないんだろ？だったら俺が試すだけだよ。
ZIP化してもいいが取り扱いが面倒になるだけだから、いければ生ファイルで行く。

> 拡張機能もしくはブラウザアプリにしてインストール必須にしても構わないだろう。
これは何が違うんだ？調べた限りでは大差ないようだったが、違うのか？
なお今回欲しい機能は以下。
・ローカルファイルからのユーザ指定無しでの読み込み
・ダウンロード時のフォルダ指定（階層化したフォルダに対してのダウンロード先指定）
これらが出来るのなら乗り換えを検討する。
ちなみに今のところGreaseMonkeyで不自由していない。
ただ、GM専用機能も使ってないので、乗り換えは出来る。

**デフォルトの名無しさん** · 2016/08/24(水) 02:10:28.07

> 君のここまでの書き込みは全然建設的じゃないし、（中略）
> 結果、ただの愚痴にしか聞こえずそれに対して何も言えることはない。
上記の通り、俺は相談以上の期待をお前らに対してはしていない。
だから気に入らなければレスくれなくていい。
（上記経験により俺もそういう距離感で行くことにしたから)
そちらも分かるように、どこまでの情報があれば何を回答出来るかはこちらも分かっている。
その上で書いているのだから、それについては無理という件については無視でいい。
馬鹿共は置き去りにしないとスレのレベルが上がらない。

その上でバグ確認に協力してくれるというのなら、
それは申し訳ないが今回はそこに踏み込む気はない。
理由は上記どおり、最新版でないと意味無いから。
そちらが既にバグに当たらない記述のライブラリなりを持っているのならそれで問題ないわけだし。

心配せずともchromeなんてバグだらけだぞ。
こなれていないところに踏み込んだらすぐに遭遇する。
それはそちらも知っていると思うが。

君らは気に入らないかもしれないが、俺は情報をくれた奴には感謝している。
ただ君らが「持ちつ持たれつ」という感覚を持ち合わせていないことも学習したから、
君らに大して期待もしていない。だから再度言うが、気に入らなければ無視でいい。
(というかこれまでの俺が甘かっただけで、本来は君らのスタンスの方がここには向いている）

**デフォルトの名無しさん** · 2016/08/24(水) 02:47:00.24

>>413
> IndexedDBが小慣れていないと言われてるのは周知の事実。
ちなみに俺はJavaScript屋ではないから、
こういう、「周知の事実」ってのは知らない情報だ。
だから君にとっては大したことなくても、俺にとっては助かっている。

その「周知の事実」にアクセス出来る人に対してこちらから提供出来る情報はほぼ無い。
せいぜい遭遇した事実/外部目線で見た感想を垂れ流すことくらいだ。
で、これを既にやっているわけだが、
結果、愚痴にしか見えないというのなら、それはそれで仕方ない。
残念ながら、こちらが「情報交換」として提供出来るのはこの程度でしかないんだよ。
何が君らにとって有意義な情報かもこちらには分からない。
だからとりあえず垂れ流すのみ。

**デフォルトの名無しさん** · 2016/08/24(水) 07:24:26.62

何様かわからんな。
出せる情報もなく、教えてくれって虫が良すぎるだろ。
Qiitaにでも行ってくれば？

**デフォルトの名無しさん** · 2016/08/24(水) 08:19:51.08

俺はindexedDBを商用製品に普通に使ってる（しかも、ローカルへのキャッシュとして）から、ぶっちゃけどんなドヤされても、こいつの書いた実装が悪いんだろうなとしか思えん。
トランザクションで500件を超えるって、そんなデカいアトミックな操作が思いつかんレベル。
ファイルの取得であれば、保存できればそれでワントランザクションだろ。
関数越えてトランザクション持って回って、どっかで非同期な呼び出しがあってカーソル見失った瞬間にトランザクション失敗してるんじゃねえの？
とかそんな感想。
ある一定バージョンのファイルセットが取得できるまでをトランザクションと見なすなら、バージョンごとに仮データとして保存するトランザクションと、
古いセットを削除して、仮データを有効データに更新するトランザクションの二本で充分でしょ。

なんで、自分より相手方の方が馬鹿に違いない、と思えるのかわからん。
俺もコミッタだけど、その発想でプルリク投げた事は無いわ。

**デフォルトの名無しさん** · 2016/08/24(水) 08:36:10.31

ダウンロードリンク、の代わりにindexedDB使う発想がわからん。
何がどこにどうダウンロードされるんだろう。
それはローカルに持ってたらどう便利なんだろう≒ローカルにあれば二度と押さないボタンなんだろうか？

なんか（アーカイブってのが何のアーカイブかはわからんが）ウェブから取得させるときに、二回目以降はそのクライアントのデータを使わせて、ダウンロードしたフリすれば良いの？

サービスワーカーで書いちゃだめなの？その処理。

**デフォルトの名無しさん** · 2016/08/24(水) 08:45:06.93

>>416
おいおい、はぶてんなってｗ
建設的でないどころではなくなってるぞ。
これだけ皆が比較的長文で沢山レスして構ってくれてるんだから
あとは君の態度次第で強力な仲間となるだろうよ。

答えをもらう代わりに問題をきちんと問題として認識できる形であげれば
それで十分「交換」になる。
あとDLに関しては500くらいで試してみて。
確かpermissionの取り方によるのか知らんが50か100毎に確認出たはずだから。
ファイルごとにオーバーヘッドもかかるだろうしアーカイブ化した方がいい。

**デフォルトの名無しさん** · 2016/08/25(木) 00:05:19.06

>>420
1日500DLなら現在味見中で、既に2週間ほど動作して問題は発生していない。
確認は一度も出ていない。ただ、出る環境の場合はこれは使えないのも確かだ。
まあ500DLなら人力でも十分あり得る範囲、さすがにこれでバグ遭遇はない。

ローレベルでのファイルのオーバーヘッドはない。
そもそも自動アーカイブはほぼ書き込みばかりだから投げ捨てだ。
また、データの大半はjpg等の圧縮済みファイルだ。
(個数としてはテキストの方が多いがjpg一枚でおつりが来る）
だからzipというよりtarなんだが、それもしない方がいいだろうという読みだ。
まあここら辺はこちらで試す。

> あとは君の態度次第で強力な仲間となるだろうよ。
セミコロンの位置でドヤア()、文法でドヤア()する奴がいくら居たって邪魔なだけ。
俺について助けになるのは、プログラミング上級者(10k行のコードを平気でメンテ出来る）か、
俺以上にJavaScriptの仕様に詳しい連中だけだ。

後者については俺がJavaScripterではないのでここの連中でも当てはまるケースも多い。
それが俺がここにいる理由。
前者について当てはまるのはここには居ても数人だ。
だから内部構成についての指摘は大半が俺から見ればデタラメに過ぎなく、ウザイだけ。
よって、そっちに流れないように上位アーキテクチャの話に絞っているわけでね。

**デフォルトの名無しさん** · 2016/08/25(木) 07:26:33.09

なーんだ
自分の手足となってくれる素直で言うこと聞いて優秀な部下もしくは奴隷がフリーで欲しいってことだったのか

サイコパスにちょっとでも強力しようと思った俺がバカだったわ

**デフォルトの名無しさん** · 2016/08/25(木) 08:20:27.91

それにどうindexedDB使うのか全然わからん。
圧縮済みデータはそれ以上圧縮かからないから、圧縮しない、は
圧縮済みデータが一つのときだけじゃない？
エントロピーが偏れば圧縮は効くんだから、いくつか混ぜるとちゃんと圧縮は効くと思うけど。
そういう意味ではtarでアーカイブした上で、積極的な圧縮はせずに、Webサーバのgzip任せていいんでないの？
無駄な作り込みはバグ生むよ。

正直、普通に職業マやってたら、そんなステップ数のメンテは逆にしない。
逆に、しないように、スクラッチの時点でちゃんと切り分ける。

別に上級者気取りでも気にはしないけど、どう考えてもアーキが浮かばん。
アーキ屋何してんの？

何か情報を出すと俺のすごいシステムがパクられそうで怖い、みたいに聞こえるけど、そういうのって大体みんな通り過ぎて、王道はなるほど王道なんだな、って「そうしないだけ」だから、
気にせんで良いんじゃないの？
ホントに凄いかも！と思ったら、先にアイディアだけどっかに書いとけばいいよ。

**デフォルトの名無しさん** · 2016/08/26(金) 18:32:39.75

ID:fTj2N0cj
ID:m1LOPf7I
ID:fG60fvYz
ここって他者を見下して優越感に浸る人が多いよな
>>1からしてそんな感じだったからなるべくしてなったのかもしれんが

**デフォルトの名無しさん** · 2016/08/26(金) 18:53:36.65

もし本当に他者を見下してるように見えるんなら精神病院行ったほうが良い。
本当に見下してれば相手と会話したりしない。

**デフォルトの名無しさん** · 2016/08/26(金) 23:31:04.14

バカほど人を見くびるもんだよ。
そして見くびれるからバカで居られる。
会話するメリットなんかいくらでもあるよ。ぬいぐるみは反抗しない「から。
反抗反論されると言うことは、自分の発言は反抗反論される程度の意味があんだ、むしろ相手が理解できない馬鹿なんだ」と思うことすらでき、一人で気持ちよくなれる。

**デフォルトの名無しさん** · 2016/08/27(土) 05:01:58.71

反抗しないぬいぐるみなんてここには居ないが？
後半は今回で言うと間違いなく ID:eAOsu6G6 の方だな
早く気付けよ

**デフォルトの名無しさん転載ダメ©2ch.net** · 2016/08/27(土) 05:49:03.76

Slot
🍜🍜👻
💣💯🎴
💯🌸🍜
(LA: 0.55, 0.58, 0.53)

**デフォルトの名無しさん** · 2016/08/27(土) 09:23:29.57

>>427
反抗するぬいぐるみが居るから、書きに来てるんだろ、って文書のつもりだったけど、眠くて誤字でわけわからん感じだな。すまん。

**デフォルトの名無しさん** · 2016/08/27(土) 21:50:54.70

よく分からんが反抗する側がバカにやり込められるのなら、
それはやり込められた側の方がもっと酷いんじゃないのか？

**デフォルトの名無しさん** · 2016/09/25(日) 17:50:33.44

Flashの仕組み全く知らないんだけどさ、Flashって高速再生出来るようにならないのかね？
以下知恵袋では「プレイヤーも自作」となっているので、
逆に言えばJavaScriptで高速プレイヤーを作成して入れ替えてしまえば可能なのか？
認証とかはさておき。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10160742165

具体的にはGyaoの動画を1.5-2倍速で再生したい。要求スペックは以下。
・個人的に使えればいい。つまりコマンド手打ちが必要でもいい。
・再生速度は固定でいい。つまり最初から1.5xか2xで固定、再生中の変更は必要ない。
・最悪バッファでもいい。つまり30分の動画なら15分バッファした後の2x再生でいい。
・ダウンロードすれば出来るのか？しかし面倒なので出来ればダイレクトで。

**デフォルトの名無しさん** · 2016/09/25(日) 19:27:04.48

スクリプトでURI解析→ネットワークに対応した外部プレーヤで再生

**デフォルトの名無しさん** · 2016/09/25(日) 21:06:19.30

確かにそんなに難しく考える必要はないのかもね。
で、試してみたんだが、今のところ駄目だ。

データ取得先は当然あっさり分かる。
それをGOMプレイヤーに食わせてみた。
曰く、「ストリーミングサーバーが見つかりません」

ただGOMプレーヤー自体も滅多に使わないから、使い方が間違っているかも。
URLもこれでいいのかは謎だし。
なおAlquadeLiteも試したが、こちらは起動するもののFlashPlayerがクラッシュして駄目だった。

まあ何かあればよろしく。

**デフォルトの名無しさん** · 2016/09/25(日) 23:14:29.89

結局「GYAO動画ダウンローダJava」を使って高速再生は出来た。
ただし事前DLが必要だが、10倍速くらいでDL出来るので問題はない。

ただ正直ちょっと複雑だ。
こんなに簡単に出来るのなら公式で用意してくれよというのと、
意外に高速再生も快適ではないのでやっぱり用意する意味もないのかとも。

いずれにしても情報をくれた人はありがとう。

**デフォルトの名無しさん** · 2016/10/16(日) 16:56:27.94

・「クライアントサイド」のJavaScriptでは、innerHTMLをエスケープ（サニタイズ）する必要ないのか？

サイトのJSON_APIがスクリプトタグを含む文字列を送ってきていて、
こちらのGreaseMonkeyスクリプトは今はそれをそのまま表示してしまっている。（見た目は消える）
これはXSS的に問題だと思っていたのだが、以下を見ると、またこちらでも試した限り、
divタグの中身等としてappendChild/insertBeforeする分には実行されないようだ。

> が！残念ながらこの場合はscriptは動きません。
> http://tech-blog.tsukaby.com/archives/894

とはいえ、見た目消えてしまうのでどのみち修正は必要なのだが、
XSSの脆弱性という意味での対策は必要ないということでいいのだろうか？

俺はJavaScriptの専門家ではない。
したがって情報は基本的に全てWebなのだが、例えば以下のように、

> 例えば、DOM Based XSSを発生させる典型的なコードの例として、
> 以下のようなinnerHTMLの使用があったとします。
> // ★★★脆弱なコードの例★★★
> var div = document.getElementById( "msg" );
> div.innerHTML = some_text; // 外部からコントロール可能な文字列
> http://www.atmarkit.co.jp/ait/articles/1312/17/news010_2.html

とあって、その後「ブラウザー上で」エスケープするなりcreateTextNodeをしているわけだが、
これって全くの間違いで、必要ないのだろうか？
（サーバーサイドならもちろん必要として、クライアントサイドなら問題なしでいいのか？
今のところ、筆者もこれらを混同しているように見える。
記事は2013/12と古いのだが、これ以降に仕様変更されたのか？
なお上記一つ目（動かないと書いている方）のブログは2015/04)

なお念のため再度言うが、「クライアントサイド」で「innerHTML」の場合。
「サーバーサイド」でもなく、「outerHTML」でもない。

**デフォルトの名無しさん** · 2016/10/17(月) 00:31:40.71

>>435
script タグでなくともイベントハンドラ（ onxxxx = ）で動作するコードを注入されたら危険だろう

**デフォルトの名無しさん** · 2016/10/17(月) 01:16:39.60

>>436
ああ、確かにその通りだ。<img onload>とかね。
ではやはりエスケープしないといけないね。
なるほど、ありがとう。

**デフォルトの名無しさん** · 2016/10/18(火) 13:06:11.48

ぶっちゃけいかなる脆弱性があったとしても、お金が関わるようなサイトでなければ関係ない
例えばある種のURLで飛ばされた時にXSS脆弱性があったとしても、
それは悪意のあるサイトから遷移したユーザーの責任。
それにCookieが抜かれようと変な表示がされようと何か致命的な問題になることはない。
いたずらレベル。

**デフォルトの名無しさん** · 2016/10/18(火) 22:14:37.24

それはその通りだし、神経質にやる気はない。
逆にそのためのブラウザの制限に辟易している状況だし。
とはいえ、JSON_APIの中身がtextなのかHTML文字列なのかは気にしておかないといけない。
その上で、どこまでやるかを各プロジェクト毎に決めればいいこと。

**デフォルトの名無しさん** · 2016/10/19(水) 08:20:38.16

そういうとこを気にするのは愚か
CSPを使い、それが通るように書けば良いだけ

**デフォルトの名無しさん** · 2016/11/21(月) 01:56:59.51

IndexedDBのスループットが全く出ないんだが、誰か高速実装サンプルコードを知らないか？
URLくれると有り難い。

こちらの実装では、スクレイプ結果の9000ファイルを書き込むのに15-20分かかっている。
全体の容量は、IndexedDB格納済みで20MB程度、tarファイルだと30MB弱といったところ。
キャッシュ済みの状態なら再スクレイプには2-3分しかかからない。
これを<a download=xxx>でtarファイルにするのには数秒しかかからないが、（最後のダウンロードに数秒）
IndexedDBに全て書き込むには15-20分かかる。
この場合はスクレイプと同時に内部的にtarファイルを作成しており、
大半は再スクレイプの時間なので比較としては不適だが、5-10倍程度遅い。(A)
なおtarファイルの展開には2-3分かかるので、これとの比較でも5-10倍程度遅い。(B)

現状、ファイルに落とす場合はスクレイプの方が明らかに遅いので全く問題ないのだが、
IDBに格納する場合はスクレイプよりも遅いのでそこで詰まる。
といっても2倍も遅くはなく、またスクレイプ側は通常は90%以上idle状態なので
現実的には問題は発生しないはずだが、それにしても遅すぎる。

トランザクション等の機能は所詮CPU時間なので、何をやってもここまで遅くはならない。
(chromeの実装が酷くても、また俺の実装が酷くても）
上記ファイル時間(B)でも5-10倍遅いのは何かおかしい。

とはいえ使い方が悪い可能性も多々ある訳なのだが、
とりあえず高速実装サンプルコードがあれば比較出来るので助かります。

実装/実験の詳細は、上記の通り、9000ファイルをIDBに格納、全体で20MB程度、
objectStoreは多めで150個程度、その中に30-150個くらいのファイルがそれぞれ格納される。
トランザクションはオブジェクトストア毎に纏めており、
実際のトランザクションは40-80個程度で、大半は平行可能。（仕様としては）
一つのトランザクション内には20個ずつputを入れている。
（トランザクション単位でのロールバックなので今回は20個くらいが適当かと思っている）
ただしいかんせん書き込んでくれない。
何かヒントあればよろしく。

**デフォルトの名無しさん** · 2016/11/21(月) 02:24:13.88

またお前か。
なぜそんな事をブラウザでやるか、それもindexedDBになぜ入れるかわからんが、
インデックス貼り過ぎではないか、
WebWorkerやServiceWorker使わずに表スレッドでやってないか
くらいかな。
スクレイプの方がはやい、DBの方が遅い、と言っても、同時に走るわけでは無いよ、ネイティブの機能でない限り。

**デフォルトの名無しさん** · 2016/11/21(月) 02:56:54.44

いや、表スレッドでやっているぞ。

ただそれは実際には問題になっているようには見えないが。
もちろん同期APIは使ってない。
つまり当然非同期だし、表スレッドで待つことはない。

> 同時に走るわけでは無い
あまりにスループットが低いのが気になっているわけだが、
確かにこの意味では「詰まる」事はあり得ないのも事実だな。

> インデックス貼り過ぎではないか
こちらはインデックスは使っていない。
インデックス使わないと超遅いとかいうのも見かけたが、
（覚えでは）3-4年前の記事だったし、取り下げていたのであてにならないと見たが、使わないと駄目か？
こちらはキーパス無し、キージェネ無し。外部キーを自前で供給している。
(要するにlocalStorageの容量増加版として使用している。ただし非同期だからどうにも使いにくいが。)
> データベースを構築する
> キーパスキージェネレータ
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB

> なぜそんな事をブラウザでやるか
一番手軽だからだよ。ブラウズする時にはブラウザは必ず使う。
アーカイブ勝手に取れてれば楽でしょ。
別ソフト起動するのが面倒でない人はそうすればいい。

> indexedDB
ブラウザ側から「消せる」方が使い勝手がいいから。
なおファイルに落とす機能はもう完成済みで、サイトのミラーが勝手に構築出来るようになっている。
もちろん外部スクリプトでtarファイルを展開しなければならないが、これは仕様的に仕方ない。
IndexedDBはボロすぎて諦めていたんだが、微妙に使えそうになってきたので色気を出している。

というか俺はGreaseMonkeyだからね。サイトのスクリプトではないからあしからず。

**デフォルトの名無しさん** · 2016/11/21(月) 04:59:18.67

愚直に１つずつ保存しようとするから愚直なパフォーマンスしかでない。
DBには圧縮ファイル１つしか保存しない。
利用するときは解凍してメモリ上で１つずつ読み書きする。
最後に圧縮して保存する。これで問題ない。
もしくはキャッシュ用に設計されたCacheStorageを使う。

**デフォルトの名無しさん** · 2016/11/21(月) 08:17:47.88

>>443
だから、表スレッドでやるから遅いんよ。
同期APIでなくとも、常に一本しか走らん。

インデックス使わないと中身探すのに全舐めだよ。
もし、挿入でなくupdateしてるなら絶対に必要。これはライブラリとか使ってなくて手で書いてたら気づいてると思うけど。

アーカイブは普通、拡張書いてそこからDOM舐めて、http通信でサーバに送ったりindexedDBに保存したりファイルにしたりする。
グリモンのスクリプトでもあんま変わらん。

**デフォルトの名無しさん** · 2016/11/21(月) 15:43:00.92

とりあえず必要最小限のコードを全部提示しろ

**デフォルトの名無しさん** · 2016/11/21(月) 23:45:11.05

すまん解決したかも。

詳細を投稿しようとしたが何故かNGワード規制なので細切れで試す。

**デフォルトの名無しさん** · 2016/11/21(月) 23:46:56.58

俺はIDBTransaction.oncomplete内でdb.close()していたのだが、
以下ではIDBRequest.onsuccess内でやっており、
//nparashuram.com/IndexedDB/perf/#Transaction based on Write
それってありか？ということでMDNを確認した結果、MDNでもそうなので
https://developer.mozilla.org/ja/docs/Web/API/IDBDatabase/close
パッチして味見した結果、とりあえず倍くらいにはなった。

それでもまだ遅いが、今は安定して動く状態ではないので詳細は確認出来ない。
本修正して安定動作させ、まだ遅いようならもう一度投稿する。
ちなみにコード自体は上記上側と似たようなもの。ただしoncompleteを使っていた。

**デフォルトの名無しさん** · 2016/11/21(月) 23:47:37.28

上記一つ目、httpが引っかかったようだ。脳内補完よろしく。

**デフォルトの名無しさん** · 2016/11/22(火) 01:12:38.73

>>448
あのさあ。
なんで強引にそうむりやり解決するのかわからん。
db.close使うことなんかほとんど無くねえか？
当たり前のようにonsuccessでトランザクションcommitするだけじゃねえの？

ずーっと偉そうだけど、脳筋が知恵の輪を強引にバラしてドヤ顔してるように見えて仕方ない。
ラグビー部員かゴリラレベルだよ、それ。

**デフォルトの名無しさん** · 2016/11/22(火) 23:13:11.58

oncomplete->onsuccessについては失敗した。
これは積み込みが早くなる（見た目終わったように見える）だけであって、
スループットは変わってない。
db.open->db.close間の時間を計測していたので間違えた。

意味としては並行トランザクションの数を増やせば同じだし、実際そんな感じだ。
onsuccessでやると他情報のライフタイムがずれるので、話が面倒になっただけだった。

**デフォルトの名無しさん** · 2016/11/22(火) 23:23:12.59

>>444
いや愚直なパフォーマンスでいいんだが、それすら出てないから問題視しているわけで。
ファイルと等速かやや遅いくらいなら十分なんだが。

圧縮展開を自前でやるのはさすがに面倒だ。
というかそれが常に成り立つならその機能ごと組み込んでおけという話だし、
実際そうなっている感触だ。
だからバグ対策でなければ自前でわざわざやる意味はないはず。

IndexedDBに関しては、基本的には「キー」となるものを「全体を一覧」出来る場所に保存して、
「本体」への参照をそれに持たせればよいだけだから、
ちゃんと実装してあれば大型ファイルへのアクセスはほぼファイルと等速になる。
だからFireFoxがFileSystemAPIを実装しない理由も妥当なのだが、
全然そうなってないからあれ？ってことで。（まだchromeでしか試してないが）
キャッシュ用に設計されている場合も
大型ファイル本体へのアクセス速度は上記の通り大して変わらないはず。
ただIndexedDBのようなインデックス検索が必要ないからその分速いが、
今はそこが見えるほどの状況になっていない。

ちなみに後述するが読み出しは速い。
（絶対的に速いかは未確認だが、書き込みと比べて50倍速い）

**デフォルトの名無しさん** · 2016/11/22(火) 23:24:53.24

>>445
いやIndexedDBは基本的に別スレッドで実行される。
いちいち "in a separate thread" って書いてあるだろ。
俺は使ったこと無いが多分Nodeと同じ。
> https://developer.mozilla.org/ja/docs/Web/API/IDBObjectStore

ちなみにプロファイラーで確認したが、表スレッドは完全に遊んでいる。
60秒間で100ms程度動いていて、他はアイドル。
OS上のCPUメーターでも遊んでいるし、いずれにしてもCPUがらみで引っかかっている感じではない。
ただ、I/Oで引っかかるなら普通のファイルと同速になるはずなのだが、これがないから不思議に思っている。

> インデックス使わないと中身探すのに全舐めだよ。
> もし、挿入でなくupdateしてるなら絶対に必要。これはライブラリとか使ってなくて手で書いてたら気づいてると思うけど。
これはないよ。
普通にIndexedDBを実装する場合、外部キーもインデックスとして実装するでしょ。
今は更地(データベースそのものの構築、onupgradeneeded でバージョン1)から始めて9000ファイル書いている。
全舐めの問題なら1000個目のファイルと9000個目のファイルで9倍速度が落ちるはずだけど、それは全くない。
先にも言ったがインデックス検索はCPU時間(usオーダー）の話だ。
実際にそこも遅いのかも知れないが、今はそこが遅くても見えないほど他が遅い。

なおリードと勘違いしているのなら、今問題になっているのはライトだけ。
後述するが、リードはとりあえず十分な速度が出ている。
ちなみにIDBCursor.update()は使っていない。俺が使っているのはIDBObjectStore.put()。

**デフォルトの名無しさん** · 2016/11/22(火) 23:34:52.08

一応パラメータ振ってみたが、
トランザクションの数を絞る(40->2)と目に見えて遅くなるので、並列はしているっぽい。
ただし増やしても速度は上がらない。
一つのトランザクション内のput数を増やしても明確な速度変化は見られない。(20->20-200)

問題点を整理すると、
・I/O律速ならファイルと同等程度になるはずだが、5-10倍遅い。(ライトだけ）
・CPU律速ではないように見える。CPUは空きまくり、スレッドもほぼ全てアイドル時間。
で、何が引っかかってこんなに遅いの？という話。
ちなみに読み出しは十分速く、IndexedDBの中身を丸ごとtarファイルにして出力するのに10秒程度。
格納に20分かかるのに、読み出しには10秒しかかからない。
（読み出しに10秒＝中身を読みだしてtarファイルをblobとして作成するまでに10秒、
その後ダウンロードする時にさらに10秒かかる）
このtarファイルを7-Zipで更地に展開するには25秒。
cygwinで既にあるファイルシステムに上書き展開するのには2-3分かかった。（これが前の話）
格納だけ異常に遅いんだが、これって何？
単純比較するとリードと比べてライトが45-120倍遅い。

ただまあwriteが遅いのは事実のようだが、ここにあるように50k records for 10 sec ならいいんだが。
ttp://stackoverflow.com/questions/22577199/indexeddb-access-speed-and-efficiency

記事は古いがここ見る限り駄目なことはやってなさそう。
ttp://blog.nparashuram.com/2013/04/indexeddb-performance-comparisons-part-2.html

既に書いたとおり、コードはここと似たようなものだが、oncompleteを使っている。
ttp://nparashuram.com/IndexedDB/perf/#Transaction based on Write

とはいえライトだけ50倍遅いのは俺の使い方に問題があるのだろう。
実装が如何にボロくてもここまでにはならないし。
というわけで高速書き込みのサンプルコードがあればURLよろしく。

**デフォルトの名無しさん** · 2016/11/23(水) 00:39:24.04

もう出来てる、だがなんだか知らんが、それ捨てたほうが良いとおもうわ。
普通はこう言うのオフラインモード持ったプロキシとして作る。

**デフォルトの名無しさん** · 2016/11/23(水) 23:07:06.62

とりあえず自力で辿り着けそうな雰囲気になってきた。
速いコードを見つけた、というかMDNのそのままをコピペしてコンソールで試したら十分速かった。
確実にこちらのコードに何か原因があるのだろう。
もし調べてくれてたらありがとう。

**デフォルトの名無しさん** · 2016/11/24(木) 15:10:21.36

この白痴
IDBを使うな、使うにしてもそう使うなと言われてるのに聞かないんだもんな
救いようがない

**デフォルトの名無しさん** · 2016/11/24(木) 16:54:40.99

なんともならんよなぁ。
何故クローム拡張を作らんか(jsで書けるし、妥当な保存方法だし、クロスドメインで苦労しなくても良いし、もし配布を気にしてるならzipでも蒔ける)
色んな疑問が湧く。

要は、ロスカット出来ない類の奴なんだと思うよ。
今まで掛けた工数が惜しいとか、自分が未熟だと認めるのが悔しい、とか、
自分は一番良い方法を考えてて、その中で「ちょっとだけドキュメントが未熟だから」実現方法が分からない事を聞いてるだけなのになんだこいつら、とか。
ベンチャーか中小企業の社長に居そうな奴。
5年目か10年目に破産する類の。

**デフォルトの名無しさん** · 2016/11/25(金) 00:21:37.68

こちらは解決しつつある。今はテスト中だ。前と同様にとちっているかもしれないが。
とはいえ、俺はお前らが何でそこまで自信過剰なのかさっぱり分からない。

5-10年目に破産したベンチャーの社長を笑えるのは、
ベンチャーを起こして10年以上持たせた奴だけだぞ。
お前らがそうだとは到底思えない。
そんなんだからゆとりは意識高い系()とか言われるんだよ。
意識高いだけで中身がないからウザイだけ。
まあお前らに付ける薬もないのも事実だが。
俺に付ける薬もないのと同様にね。

お前ら、OSSに参加もしてないだろ。
よくもまあそれで、としか思えないけどね。

**デフォルトの名無しさん** · 2016/11/25(金) 00:52:34.50

>>459
メンテナしてるけどそれが何か、って話な位で、得意になるもんでも無いんじゃ？
参加とやらの程度にもよるけど、ある程度やってりゃ、プルリクくらい普通に出せるだろ。
コミッタって関わるにあたって特別な事なんもしてないと思うけど。
リポジトリ晒せと言われたら色んなものが傷つくからやらんが。

「お前らがそうとは到底思えない」
「してないだろ」
「よくもまあそれで」
ってまぁ意識たけえなぁ。
ベンチャー起こして10年も持たさんで良いだろ。
まともな会社でそれなりに勤めて、何度か転職して、それなりの立場にいる方が余程視野が広がるよ。
少なくとも金の算段を必要以上にせんで良いからな。

大→中堅→ベンチャー→大と転職して色んな良いところ悪いところ見てきたからわかるが、お前は悪いところの総和みたいな姿しとるよ。

**デフォルトの名無しさん** · 2016/11/25(金) 01:07:59.74

一人が自信満々なのを否定するのと大多数が自信満々なのを否定するのは意味が違うからな

**デフォルトの名無しさん** · 2016/11/25(金) 01:21:08.20

>>460
お前がそれならそれでいいよとしか言いようがない。
それがWeb系といわれる所以だろうし。
別に俺はお前に評価される必要なんてないし。

OSS云々ってのは、明らかにお前らは距離感がおかしいからだ。
OSSやってる連中は、限られたリソース（時間と金）の中でやりくりしている。
各自が今現在の状況で最大の効果が出るように考えている。
もちろん制約条件がそれぞれ異なるので、
君にとっての今の最適解が俺にとっての今の最適解でないこともよくある。逆も然り。
だけどそれはそういうものだから、いちいち文句は言わないし、言われない。
文句があるならお前がやれ、方針が違うならフォークしろ、の世界であるし。

だからお前らみたいな「俺の提案が神だからそれ以外は認めない」はないんだよ。
君は参加しているつもりになっているだけで、実際は観戦しているだけだよ。
参戦していない。

**デフォルトの名無しさん** · 2016/11/25(金) 01:22:21.94

ただまあそれ以前に俺はお前らの提案がいいとも思わないけどね。
いちいち反論した方がいいのか？ならば言ってみてもいいが、
余りこんなのをやってもお互いに意味はないんだよ。
どうにもお前らはこういうのが好きなようだが。

>>458
CacheStorageはhttps縛りだから使えない。
クローム拡張にしない理由は、FireFoxもサポート対象だから。
並行して2つのソースを管理するほどリソースはない。GreaseMonkeyなら一つのソースで済む。
ここら辺は要するに楽な方をとっているだけ。
クロスドメインについてはGreaseMonkeyは独自拡張を持っていてスルー出来る。
配布なら苦労してない。
GreaseMonkey導入後の環境ならuser.jsリンクをクリックすればインストールされる。
zipすら要らない。リンク一つで済む。
掛けた工数云々は関係ない。
未来の工数も踏まえた上で、今現在の最善手を選んでいるだけ。
これは俺以外のOSSに関わる連中全員そのはずだが。
上記の通り、今現在何も問題ないし、移行のメリットもないのにするわけないだろ。
IndexedDBと同様、chrome拡張にもどんな落とし穴があるかも分からないわけだし。

これで満足か？
何でお前らがこんな点ばかりににこだわるのか俺はよく分からないが。

**デフォルトの名無しさん** · 2016/11/25(金) 08:31:00.71

>>462
評価される必要はないのに、相手を下げて自分を高めようとえらく必死だな。

限られたリソースは現実であって、目指すべきものはそのリソースに縛られたものにすべきじゃない。
俺には手一杯だからとか、この部分俺あんまり強くないから、とかは、放置するんじゃなくて、明言する。
どんどんマサカリ投げて、どんどんプルリク投げて欲しくて、画像貼らせてほしい。
誰かのリソースが足りないのなら、そう書いて、他の誰かのリソースの援助を求めるべきなんよ。
リソースが足りてないから制約条件になります、はおかしいし、ここまで物言いがついたら、最適条件がなぜ最適条件なのか、くらいからもう一回ゆっくり考えるべき。
ソクラテスのいじめまがいの問答をもってでもやるべき。

「俺の提案が神だからそれ以外は認めない」？
俺はそんな事は言ってないが。
むしろ、お前がずーっと言ってる事じゃねえの？

>>463
httpsなんかなんとでもなるだろ。letsencryptもあるし、イントラなら証明書配れば良い。
並行して管理するのは画面周りで良いので、実際の管理工数は1.3倍程度になる。きっちり画面とロジックの設計をしてれば。
なら、むしろグリモン縛りなら、グリモンでプロキシ書いたらいかんのか？
あと、データは普通に、indexedDB使わんと、ファイルに書けんじゃん。
そのアーカイブとやらをBase64にして、前後にvar tmp=""つけてjsとして書き出して、選んで@requireで読み込むだけで良いんだが、なんかindexedDBの出番ある？
それこそインデックスだと思うけどね。

**デフォルトの名無しさん** · 2016/11/25(金) 08:34:29.54

いつも思うが、ここの質問者は複雑な背景がある質問をソースコードを出さずに質問するのは何故だ？
代替案が提案されるのは情報が出そろってないから
初めから全ての情報を出せばこんなことにはならない
アドバイスした人や否定意見を「お前等は分かってない」で一蹴してさんざん馬鹿にした上で去るのが常
お前が情報を出さないのが全ての原因

**デフォルトの名無しさん** · 2016/11/25(金) 08:47:16.69

>>465
賢いつもりで、文句言ってくるやつは愚鈍だと言いたいんだろう。
そもそも相手を愚鈍にしておきたいから、ソース出さないんだと思うけどね。
俺なら早めに自分のリポジトリの上げて、声出して、便利そうだけどここで使い物にならんので、置いとく、とかやる。
個人の持ち物なら。
仕事や金儲けでやってたら、人の話聞かないと大怪我するのはわかってるしな。

**デフォルトの名無しさん** · 2016/11/25(金) 09:05:01.87

いいんだよもう。
本当に心底困ってて、礼儀正しく質問してくる奴なんて幻なのだから。
俺すげーしたいやつ、ただここでアピールすることで興奮し、
不安を取り除いてやる気を出そうとするやつの話を聞いてやるのもこのスレの役目。

**デフォルトの名無しさん** · 2016/11/25(金) 12:43:41.42

まぁ、拡張もクリック一つなんだけどね。
それが現状ベスト、ではなくて、それしか使えない、って白状すりゃいいのに、プライドの高いやつだなぁ。

**デフォルトの名無しさん** · 2016/11/25(金) 13:19:56.25

自分は万全に良く知ってて良く考えてると思ってるけど、
技術が圧倒的に足りないのもあってうまいこと行かず、
もやもやしたフラストレーションが溜まってるんでしょう。

要するに何か具体的に解決したいのではなくスッキリしたいだけ。
まあそれは結局自らの問題だから他人に言っても仕方ないんだけどね。

**デフォルトの名無しさん** · 2016/11/25(金) 22:05:14.23

お前らがそういうことにしたいのならそれでいいけども、
お前らのレベルの低さは他言語スレ見たらすぐ分かると思うんだが。

とはいえWeb系()に付ける薬はないのは分かった。
そしてこの言葉が広まっているのはつまり皆が同感するからであり、
それを俺が何とかしようとしても、所詮俺如きではどうにもならないのも分かった。

まあせいぜいポストゆとりに殺されてくれ。

**デフォルトの名無しさん** · 2016/11/25(金) 22:06:17.97

>>465
ここでのこういうやりとりは無駄であって、
その時間をソースコード開発に回すべきだと思っているから。
ここに晒したらいちいち反応しなければならなくなるだろ。
それは時間の無駄だ。結局今回も自力で辿り着いてしまったし。

俺も結局は最善手を選んでいるだけ。
ここでコードを晒して時間を浪費するよりは、
何か情報があればラッキー程度として、基本的に自力で解決することに賭けた。
これまでのやりとりを見る限り、君達には俺のコードは読めないし、解決する能力もない。
だからせいぜいサンプルコード発掘くらいだと思ってそうした。
書き込み速度のオーダーを知っていればその点の即答もあるかと思ったが、それもないし。
おそらく君らは俺がやっているほど負荷掛けた使い方をしていない。だから何も知らない。
オススメのCacheStorageのスループットも知らないだろ？要するに君らはその程度なんだよ。
それで何でそこまで自信過剰なのか俺には分からないのだが。
(俺もそれを知らないから俺が大したこと無いのももちろん事実だが、
君らも大したことはないんだよ、それを自覚しないといけない）

そもそも代替案なんて必要なかった。
もう対策は出来ていて、十分な速度は出ている。（以前と比べて50倍速以上）
本来あるべき回答は「その書き込み速度は明らかに遅すぎるから、お前のコードに問題がある」だった。
ただ君らは本来の書き込み速度自体を知らないから、これに答えられず、
「遅いのなら違う方法を試せ」という間違った回答をよこし、それを正解にしようとしている。
色々明らかにずれているんだよ。

**デフォルトの名無しさん** · 2016/11/25(金) 22:07:04.84

とはいえここら辺のずれもこれまでどおりだから、
俺は君らからでも有効回答が得られる可能性を残しつつ、
無駄に巻き込まれないように出す情報も絞ってある。
それだけ。
ただ、やっぱり難癖付けられて巻き込まれてはいるが。
前も言ったが、こっちもどこまで出せばどれくらいの精度が期待出来るかは分かるから、
こちらが出していない部分については当然回答がないということで全く問題ないんだよ。
出している範囲で明らかにおかしければ指摘して欲しいし、問題ないならスルーでいい。
ただ今回は出している範囲でも明らかにおかしいのに誰も指摘出来てないだろ。
そしてさらにおかしな回答をよこしてそれを正しいと主張している。
お前らがそれで仕事しているらしいからWeb系()って怖いわ。

なお君は465=444か？
だったら俺は君の回答には不満はない。知っている範囲で答えた良い回答だ。
知らない奴が間違った主張をするからおかしな事になるわけであってね。
ただなんか知らんがJavaScriptの連中はこういうのが多いが。

**デフォルトの名無しさん** · 2016/11/25(金) 22:36:44.21

うーん、やっぱり、何かおかしいわ。

開発って長くやってりゃわかるけど、コード睨んでるより、飯食って風呂入って嫁とゴロゴロしてる時くらいに謎の天啓で解けるようなもんで、
ソースコード自体は「こう書く」と決めてから、ガーッと書いて半日位で終わるんだよなぁ。

ゴリラの知恵の輪見て、「お、解けてる、ゴールに辿り着いたな」と思うのは仏くらいだろ。

そのスループット、は背景がわからないと答えられないんよね。
グリモンでもバージョンによって違うし。
遅いなら違う方法試せ、は要は、「情報が足りなすぎてわからん。自分でやってみろよ」の糖衣文だろ。

やってるほど負荷をかけてない、って当たり前よ。
密航船の奴隷でもあるまいし。
普通は人数と航路に対して適切な船を選ぶか、船に対して適切な航路と人数を選ぶもんだ。

絞ったものには、絞ったなりの答えしか来ないよ。

WebはWeb屋、俺はイントラ屋と思ってるおっさんでも思うんだから、お前が馬鹿にしてる新進気鋭のWeb屋さんならもっとキツめに思うと思うよ。

少なくとも俺はそれはブラウザではやらん。

**デフォルトの名無しさん** · 2016/11/25(金) 23:59:05.15

お前も話をすり替えるのな。それもWeb系()の悪い癖だわ。
多分すぐに「ポストゆとりの新進気鋭のWeb屋」に駆逐されるよ。
俺の知ったことではないが。

**デフォルトの名無しさん** · 2016/11/26(土) 00:52:43.95

すり替えられた、何か攻撃されてる、それはWeb系()だからだ、と保身で揶揄してるままだと、それこそ新進気鋭に駆逐されるよ。
合理的だからね、彼らは。
最後から二つ目の段落に書いてあることも読めないくらいだから仕方ないけど。

**デフォルトの名無しさん** · 2016/11/26(土) 01:30:19.73

もしかして理解できない事はどれだけ喩えて言われてもすり替えられてると思ってるのかな

**デフォルトの名無しさん** · 2016/11/26(土) 02:26:09.31

>>471
お前が自分の都合しか考えない自己中な奴だという事が分かっただけだな
お前が情報を開示しない事で、他人がお前の状況を正確に把握できず、お前の求める答えが無ければ情報を後出しして非難するわけだ

お前と同じ環境を揃えなければ再現する事は不可能だ
仮に俺の環境で検証したとしても後出しでいろいろと情報を付け足して否定するのは目に見えている
再現性が限りなく低いと分かっている問題に時間をかける奴はいない
「君達には俺のコードは読めないし、解決する能力もない」といってるが、実際にはお前の説明能力の問題

**デフォルトの名無しさん** · 2016/11/26(土) 05:01:06.08

そもそも解決して頂こう、その努力をしようと思っていないしな。
こいつは人様を一体何だと思ってるんだ？
技術者として以前に人間として下手くそな奴だな。

**デフォルトの名無しさん** · 2016/11/26(土) 11:38:59.71

相変わらずゆとりの言い訳ばかり。本当にお前らどうしようもないな。
そうやって自己正当化ばかりしているからゆとりのままなんだよ。
まあそれをやり続けて数年後に死ねばいいと思うよ。

情報は後出ししてない。
最初の投稿>>441の時点で異常に遅いと分かるし、指摘出来る。
もちろん俺も異常に遅いと感じたから色々確かめていた。
とはいえコード自体は特に問題なさそうだったし、
そもそも俺はIndexedDBを初めて使うから速度のオーダーが分かってなかった。
だから聞いた。結果、誰も知らず、50倍遅いのを誰も見抜けなかっただけ。

結局お前らの実力ってその程度って事だよ。これは事実だよ。
他言語で50倍も遅いのに気づかないようだと殺される。
もちろん初心者ならいいけど、お前ら初心者じゃないつもりなんでしょ。
俺はそこら辺の勘違いを直せと言ってるんだよ。

とはいえ全く聞く耳持たないようだし、多分Web系()と言われる理由はそこなのだろう。
おそらく俺も他言語の技術者が既にやってきた指摘を繰り返しているだけ。
お前らがムキになって俺を悪者に仕立てるのもよく分からんが、そうしたければそうすればいい。
そんなことをしてもお前らの実力があることにはならない。

数年後にポストゆとりに殺されるか、
JavaScriptがもっとメジャーになって他言語の上級者が流入してきてお前らのゴミっぷりがばれて殺されるか。
あるいはWeb系()は今のままで低空飛行を続けられるか。
まあ俺の知ったことではないが。

**デフォルトの名無しさん** · 2016/11/26(土) 19:29:29.83

言ってることが無茶苦茶
ユーザースクリプトがワンクリックなんちゃらとか
拡張機能でもワンクリックで更新できますが？
そういった事が山ほどある
もう働きたくないでござる！働きたくないでござる！と言ってるようにしか見えない。

それとなんか、自分の正当性をペラペラ喋りまくることが正義だと思ってみたいだけど大間違い。
この世の正義とは、可愛げ・真摯さ・悪どさであって、
本当にひたむきに取り組むかは別にして、相手の意見を組んだことを示さなきゃ、
あれも嫌、これも嫌、じゃ最悪

お母ちゃんに駄々をこねる思春期少年のような態度を示されても困る
情報の後出し云々以前の問題
人間としてまともにコミュニケーション取れるようになってから来いよな
ほんと

**デフォルトの名無しさん** · 2016/11/26(土) 20:26:02.31

説明力0だしな。
でかいファイルの更新、は、遅いよ。
levelDBの実装見りゃわかる。

**デフォルトの名無しさん** · 2016/11/26(土) 22:27:36.04

JavaScriptの環境にも色々問題があるのだけど、
お前らが上達してない最大の原因はお前らの人格だよ。
しかもそれを認めないと来てる。ゆとりは嫌われて当然だよ。
技術的なことは技術的に判断しないといけない。

>>473
一応言っておくけどお前もWeb系()以外の何者でもないよ。
50倍遅いコードを擁護するなんて他言語ではあり得ないから。
それを見抜けない奴を擁護することもね。

いや、正確に言えば、Web系ではサーバーサイドの連中も含まれてしまうので申し訳ない。
駄目なのは「ゆとりJavaScripter」と「その取り巻き」だね。

サーバーサイドでは処理性能が鯖コストに直結する為、50倍なんて当然認められない。
俺が遭遇したケースだと、Goの奴に「そんなところでString.replace使ってんじゃねーよ。
forで回して変換しろ」と言われたことがある。まあ正直、勘弁してくれよと思ったが。
フルスタック()とか言っているらしいけど、
俺が見る限りPHPの連中はお前らよりマシっぽいし、上記の通り環境もキツいので鍛えられる。
ポストゆとりを待つまでもなく、PHPerがフルスタック化すればお前らは殺されるよ。
まあPHPerには別の問題があるのかもしれないし、それも含めて俺の知ったことではないが。

**デフォルトの名無しさん** · 2016/11/26(土) 23:21:05.86

>>482
なんだそりゃ。
鯖とかフルスタックの話するとなると、はっきり言って、

「使うべきでないものは最初から使わない」
に行き着くべきなんだが。

そんな事をするぐらいなら、札束でAWSのインスタンスをガンガン起こすSIerの発想の方がまだ正しいよ。
万能ナイフでビーフシチューは、作れないことも無いけど、作るべきじゃない。
その程度の次元の話。
あと、これはすり替えではなくて、無能に説明してる比喩表現だからね。

**デフォルトの名無しさん** · 2016/11/26(土) 23:42:25.47

>>483
お前は文脈が読めてないな。
JavaScriptの前に日本語を勉強した方がいい。

それと、
> 「使うべきでないものは最初から使わない」
に関しては俺も同意だが、そんなに議論したいのなら、>>464の馬鹿を何とかしろ。
CacheStorageを無理に使いたいからletesencryptを使ってサーバ絡ませて@require？
GreaseMonkeyでIndexedDBを直接扱えばそれで終わる話で、何でそんなことになるわけよ？
としか思えなかったが、人格に至らない点があるらしい俺からでは説得は無理だ。
素晴らしい人格と説明能力の持ち主である君から是非彼を説得してくれ。

**デフォルトの名無しさん** · 2016/11/27(日) 01:20:07.95

>>484
あのさぁ。抗う言葉が無くなってきたからといって、それはなかろう。
全然同意してないじゃん。
してるならそのソース捨てなよ…。

文脈を読ませるのはお前の仕事だ。
逆に、書いてあることを書いてある通りに読み、書いてない事を読まないのもお前の仕事だ。

IndexedDBなんか使うな、と言っとろうが。464でも。CacheStroageを使えとも言ってない。

適当にファイルに落とせば？って言ってんの。
それしたいなら、拡張で書くか、プロキシとして実装しろ、と。

何で相手がお前以下だと、お前の発想を単に否定しているだけだと思いこむの？
モヒカンなの？

**デフォルトの名無しさん** · 2016/11/27(日) 01:52:00.72

>>485
ファイルに落とす機能はもう既にあって、動いていると>>443で言ってるだろ。
お前は本当に日本語が不自由な奴だな。

大体IndexedDBなんてただのストレージなんだし、どう使おうが問題ないだろ。
お前ら何で駄目だと思いこんでるんだ？

**デフォルトの名無しさん** · 2016/11/27(日) 02:10:05.21

ID:EHtLgt8W
この人、「お前ら」と一括りにして反論する癖があるのね
選民意識の強い人と言うべきか
この人の場合は「自分」と「自分以外」で選民している感が強い
全能感も強くてコミュニケーション能力に問題がある感じ

**デフォルトの名無しさん** · 2016/11/27(日) 02:17:18.52

>>486
日本語が不自由とか自己紹介良いよほんと。

外部スクリプトで展開、とかアホな事言ってんじゃん。
なんでそれ直接読めるような鯖かかんの？って疑問。
そうすりゃ解決すんのに。

ただのストレージではないし、どう使っても問題ないものでは無い。
indexでアクセス出来る、indexが昇順で並んでいる、サブインデックスも張れる、本来はバイナリを入れるためのものでは無いものだよ。
だから、万能ナイフとかそういう喩えで話してんじゃん。
やろうと思ったら出来るけど、それやるくらいなら別のやり方するって言ってんの。

>>487
きれいな言葉で包んでやらんでも良かろう。
ただの自己愛性人格障害でしょ。

**デフォルトの名無しさん** · 2016/11/27(日) 02:53:05.25

誇大性（空想または行動における）、賛美されたい欲求、共感の欠如の広範な様式で、成人期早期までに始まり、種々の状況で明らかになる。以下のうち5つ（またはそれ以上）によって示される。

自分が重要であるという誇大な感覚（例：業績や才能を誇張する、十分な業績がないにもかかわらず優れていると認められることを期待する）
>>全レス
限りない成功、権力、才気、美しさ、あるいは理想的な愛の空想にとらわれている。
>>概ね全レス
自分が “特別” であり、独特であり、他の特別なまたは地位の高い人達（または団体）だけが理解しうる、または関係があるべきだ、と信じている。
>>459 OSS発言、
過剰な賛美を求める。

特権意識（つまり、特別有利な取り計らい、または自分が期待すれば相手が自動的に従うことを理由もなく期待する）
>>471-472
対人関係で相手を不当に利用する（すなわち、自分自身の目的を達成するために他人を利用する）。
>>471-472
共感の欠如：他人の気持ちおよび欲求を認識しようとしない、またはそれに気としない。
>>全レス
しばしば他人に嫉妬する、または他人が自分に嫉妬していると思い込む。
>>459 意識高いだけ云々
尊大で傲慢な行動、または態度
>>全レス

フルビットで通院案件

**デフォルトの名無しさん** · 2016/11/27(日) 05:35:11.63

人にケチ付ける前に自分のレスを見直した方がいい。
「IDBで一般的にこういうコードのケースで思ったようにパフォーマンスが出ないんだが」
この一言で済む話。
他は全て、私は怠惰です、短気です、プライドが高いです、とアピールしているようなもの。

もし一生懸命自分の中でやり尽くしたと思うのなら、
尚更一般的な話に落とし込んで問題提起しなくちゃ。

自尊心は、そういう前向きな回転を生み出すことで保つべきで、
自己肯定や他者否定に縋っちゃ駄目。
もっと頑張らなくちゃ。

**デフォルトの名無しさん** · 2016/11/27(日) 10:33:33.02

>>488
いやただのストレージだよ。
FireFoxは「FileSystemAPIなんて要らない。だってIndexedDBで事足りる」という立場だ。
当たり前だがこれは「FileSystemAPIの代わりにIndexedDBを使うことに何の問題もない」という意味だよ。
少なくとも彼等はそう思っている。
（俺はOSから透過のFileSystemAPIがあった方がいいと思っている)
Blobの格納も出来るようになってるだろ。
もっとも、駄目ならBase64使う奴もいただろうし、それも選択肢だよ。
インデックスも貼れるけど、使わなくても何も問題ない。
とはいえこれらには合意する必要はない。
俺のプロジェクトは俺が方針を決めるし、君のプロジェクトでは君が方針を決めるだけのことだ。

次の質問に移ろう。
何故君はそんなに教科書的使い方にこだわるのか？

IndexedDBはインデックスを使ってアスキーを入れないといけない？何故？
俺は装備を見比べて使えそうな物を使っているだけ。具体的には
IndexedDB, CacheStorage, FileSystemAPIの中で一番マシなIndexedDBを使おうとしているだけ。

> なんでそれ直接読めるような鯖かかんの？って疑問。
サーバに関しては完全に俺の管轄外だ。
ガチの勝手スクリプトだから、こちらの要求は基本的に通らない。

**デフォルトの名無しさん** · 2016/11/27(日) 12:34:58.81

>>491
彼らって誰？
Blobが格納できるようになったのは、中期以降。
しかも、そんな一つあたりが大きいデータの為じゃない。
これは、LevelDB見てくりゃわかること。

貼らなくても問題ないことはないよ。キーっていうインデックスは出てくるわけだし、sortedなので、そのキーに長くてソートが不要なものは使うべきじゃない。

俺のプロジェクトだから、俺が決める、なんて言っちゃうなら、OSS発言は取り消しといてね。
対極の発想だから。それ。

教科書的な使い方にこだわってるんじゃないよ。
実装見て、それは遣い方が悪いってものに対して、おかしいよって言ってる。

管轄外ってなんだそりゃ。フルスタックじゃねえの？(笑)
は、置いといて。

単純に、Clientで動かすプロキシ書けばいいんだよ。
特定のURLの場合、ネットワークで取得せずファイルから見るような。

**デフォルトの名無しさん** · 2016/11/27(日) 12:45:45.17

もしかして、鯖って書いたらサーバー側で動かすもの想像してたのかな。
こいつのフルスタックって何なんだ。

**デフォルトの名無しさん** · 2016/11/27(日) 12:54:03.05

無知と怠慢。救いようがない

**デフォルトの名無しさん** · 2016/11/27(日) 12:54:44.21

なんでこんな事言ってるかと言うと、テレホの時代に、同じような物沢山観たんだよね。
metagetaしかり、Vectorにいっぱいあるレベル。
自分が一番イケてると思ってるんだろうが、単に轍に乗ってるだけ。

**デフォルトの名無しさん** · 2016/11/27(日) 13:12:59.65

ちなみに、IndexedDBで事足りる、とは言ってないんよね、Mozillaは。
ローカルファイルを使いたいなら今API策定してる、とも言ってるし。

割りと無難なブラウザオンリーな対応何は、ダウンロードしたそのアーカイブをドラッグアンドドロップやなんかでjsで受けてjsで開く事だと思うけど。すでにファイルとして出せるなら。

怠慢の方がマシ。
馬鹿な働き者は撃ち殺すしかないという典型例。

**デフォルトの名無しさん** · 2016/11/27(日) 13:18:28.75

もういいからROMって？

**デフォルトの名無しさん** · 2016/11/27(日) 13:31:22.83

>>496
お前はやはり日本語にどうにも問題がある。議論は無理だ。
とはいえお前にも分かる範囲の所は答えておく。

> 割りと無難なブラウザオンリーな対応何は、ダウンロードしたそのアーカイブをドラッグアンドドロップやなんかでjsで受けてjsで開く事だと思うけど。すでにファイルとして出せるなら。
その通りだ。そしてこれはもう実装出来ている。
そして別オプションとしてIndexedDBにも格納出来るようにしようとしている。

> 俺のプロジェクトだから、俺が決める、なんて言っちゃうなら、OSS発言は取り消しといてね。
> 対極の発想だから。それ。
違うんだな。お前はOSSに「参戦」していないからそれが分からない。
>>464なんて典型的な勘違いだぞ。
ただまあとにかく「参戦」してみろ。それだけでいろいろ分かるはずだから。

**デフォルトの名無しさん** · 2016/11/27(日) 13:35:35.02

ムダそうだからROMるわ。すまんな。

>>498
メンテナじゃアホ。

**デフォルトの名無しさん** · 2016/11/28(月) 05:41:09.72

一つ言えることは、この件についてやってみる価値がありそうなこと沢山あるのに、
めんどくさがって手を動かさないで口だけで反論するのでは前に進みようがないということだね

**デフォルトの名無しさん** · 2016/11/29(火) 03:20:41.76

別オプションとしてindexedDBに…保存する意味がわからん

**デフォルトの名無しさん** · 2016/11/29(火) 23:05:21.60

「FileSystemAPI が不要」なのは、ファイルの書き込み機能は
blob URL リンクにしてダウンロードで事足りるから、ではないのかな？

**デフォルトの名無しさん** · 2016/11/30(水) 10:48:28.24

超初心者です。
PHPとJavaScriptでホームページ作っていますがJavaScriptの変数名の使い方で質問です

phpの場合
変数名　hoge1fuga　hoge2fuga ……を使用する時変数iを使って
　→　if(hoge'.$i.'fuga == 'abcd')

→　$h = 'hoge'
$f = 'fuga'
if($h$i$f == 'abcd')
のような書き方ができますがjavascriptの場合どう書けば良いのでしょうか。

var hoge = fuga1.checked
の時に　var hoge = fuga + i + .checked　の記述にするとエラーになってしいまい、変数名の使い方そのものに疑問が湧きました。

**デフォルトの名無しさん** · 2016/11/30(水) 10:49:26.04

>>1読んでませんでした
上の質問無視してください
失礼しました

**デフォルトの名無しさん** · 2016/11/30(水) 16:00:04.29

>>503
できないことはないが、行儀が極めて悪いことだとされるのでしない。
そういうときは、配列を使う。　つまり、
var fuga1, fuga2　ではなく、
var fuga = []　とする。　利用するときは、
var hoge = fuga[i].checked　となる。

**デフォルトの名無しさん** · 2016/12/31(土) 15:44:33.33

JavaScript死亡ｗｗｗ

「WebAssembly」がITの未来に変革もたらす｜Google、Apple、Microsoft、Mozillaが共同で開発した新概念

「WebAssembly」がWebブラウザに変革をもたらします。
Webブラウザは、もともとただテキストを表示するだけのところから始まりました。その出発点から、現在ではコミュニケーションやゲームまで幅広い表現を可能にしています。
そして今回、「Webブラウザ」に新しい概念が加わわることになりました。
それをもたらしたのが、ブラウザに関わりの深い世界規模の４社「Google」「Apple」「Microsoft」「Mozilla」が共同開発した、Webのためのバイナリーフォーマット「WebAssembly」です。
今回はその「WebAssembly」について、「スゴイところって何？」「何が起きるの？」をご紹介していきます。
WebAssemblyは「JS不要。コンパイラ言語だけで動的アプリが作れる」「どの言語でもWebブラウザ上にアプリを作ることができる」

WebAssemblyによってもたらされるスゴイところは次の4つ。
コンパイラ言語だけで、Webブラウザ上に動的なアプリが作れる
ほぼ機械言語にコンパイルされるからヌルヌル動く
OSを一切気にする必要がなくなる。気にするのはブラウザのみ
C,C 以外の言語でもWebAssemblyにコンパイルされる「クロスコンパイラ」の可能性が高まった

これまでWebブラウザで、ユーザからの入力情報を元に、動的なアプリケーションを実現するためには「JavaScript」が必須でした。

「インタプリター言語」であるJavaScriptは、その都度ソースコードを機械語に翻訳する必要があるため、予め機械語に近くコンパイルされる「コンパイラ言語」と比較すると動作が遅いという特徴があります（※）。

もしコンパイル後の機械語に近い形で、Webブラウザ上でコードが実行されたら。
JavaScript以上にヌルヌルに動き、しかもJavaScriptを気にする必要がなくなります。

それを実現したのがこの「WebAssembly」です。

https://mayonez.jp/1690

**デフォルトの名無しさん** · 2017/01/01(日) 00:42:27.84

あちこちに落としているようだが、誰一人として肯定して無くてワロタw
つかマジでJavaScript界隈の馬鹿共はこんなデタラメ記事書くのをいい加減止めた方がいいと思うのだが。
自浄作用が無いのは、お前らが叩かないからでもあるんだぜ。
嘘は叩かれるべき。

Cに関しては昔は間違い叩きがすごかったと聞くが、
結果的にWeb上での間違いは皆無となり、お互いの利益になってる。
JavaScriptに間違い記事が氾濫しているのは、第一義には書く奴が悪いんだが、放置されていることも問題だよ。
とはいえ、この記事には投稿欄が無いため、#mayonez編集部＝馬鹿と覚えておくしかないが。
この点はQiitaのほうがかなりマシだな。

**デフォルトの名無しさん** · 2017/01/01(日) 08:00:47.18

>>507
素晴らしい指摘をしているであろうあなたの投稿を見たいからQiitaで使っているアカウントを教えてくれ

**デフォルトの名無しさん** · 2017/01/01(日) 08:49:58.30

>>508
ゆとり死ね

ツーかお前ら本当に池沼なのな。俺は「ゆとりBot」作れそうな気がしてきたよ。

**デフォルトの名無しさん** · 2017/01/01(日) 08:55:22.46

ID:k8/wNRO9 のような他人のダメ出ししか出来ない奴がまともな指摘をするとは思えないのでどうでもいい

**デフォルトの名無しさん** · 2017/01/01(日) 08:59:00.51

>>510
その通りだ。お前は正しい。
それが分からないからゆとりは池沼なのだし、嫌われる。

**デフォルトの名無しさん** · 2017/01/01(日) 13:57:14.12

何かと理由を付けてQiitaアカウントを隠すとは思っていたが、意外とあっさり自分の非を認めるんだな

**デフォルトの名無しさん** · 2017/01/01(日) 16:36:12.10

HTML+JavaScript+WebAPIの構成で認証処理したい場合ってこれでいいの？

ログイン画面
-- ユーザー名/パスワードを送信
-- パスワードが合ってればデータベースにユーザー名と認証トークンを保存
-- レスポンスヘッダーに認証トークンを書き込み

他の画面
-- リクエストヘッダーに認証トークンを書き込み
-- データベースの認証トークンを照会して合ってれば更新
-- レスポンスヘッダーに新しい認証トークンを書き込み

WebAPI
-- ajaxヘッダーに認証トークンを書き込み
-- データベースの認証トークンを照会して合ってたらapiを実行

**デフォルトの名無しさん** · 2017/01/01(日) 17:38:52.36

>>513
トークンって何？
JWTみたいな署名したものの類？
であれば、ログイン画面以外はサーバ側の何も更新する必要無いのでは？
新しいものを発行しまくる必要が無いと言うか、どこでもそんな事すべきでは無い。
ログイン画面に当たるものと、トークン更新のAPIがあればそれで良い。

セッションキーならまた話は別だけど。
トークンの定義が適当すぎて答えられん。

**デフォルトの名無しさん** · 2017/01/01(日) 17:39:50.17

>>512
違うぞ。

> 何かと理由を付けてQiitaアカウントを隠す
隠してねえ。そもそも持ってねえ。
> 意外とあっさり自分の非を認めるんだな
そもそも俺に非はない。

506がデタラメだと分からない馬鹿はこのスレにはお呼びじゃない。
理由が分からないのなら、必死チェッカーで調べてみろ。
JavaScript/Java/C#(Xamarin)のいずれのスレでもそれぞれ別の理由で駄目出しされてる。
もちろんそれ以外にも駄目出し出来る。

508はコミュ症過ぎて受けようがない。それを咎めている。
もっともお前もコミュ症過ぎて分からないようだが。

508は反射レスだ。俺のレスが気に入らないから定型的に返してみただけ。
だけどそういうのがお前らの状況をより悪くしている。そのことにいい加減気づけ。

**デフォルトの名無しさん** · 2017/01/01(日) 17:40:34.08

506は明確に間違いを含んでいる。それが分からないような馬鹿とは俺は話したいとは思わない。
そして真面目に話したいのなら、いちいち無駄に煽る意味は無い。
あれでは他の誰かがQiitaアカウント持ってても、508みたいなゴミに教えようとは思わないだろ。
つまり、508は俺を叩くためだけの作用しかない。プラス作用は期待できないレスだ。

では俺が叩かれる理由があるか？それはお前らが考えるべきことだが、
俺は意図的に、

#mayonez編集部＝馬鹿、つまり、
#mayonezはゴミサイトだ

と言っている。これは再度強調しておく。
俺はゴミ潰しをしているんだよ。俺が507で言ったとおりにね。

506の意図は不明だが、通常はこれだけ投下するのなら関係者が宣伝しているとかだ。
あんなデタラメを宣伝されても迷惑でしかないだろ。
だから俺は奴らが書き込む度に叩くことにより、書き込みを防ぐことを期待している。
分かるか？
書き込みを強制的に止めさせることはできない。
でも、「宣伝したい」のなら、カウンター「だって#mayonezって嘘ばかりのゴミじゃん」を合わせることによって、
相手に書き込みを止めさせることを期待している。

これを理解したうえで批判するのはお前の自由。
理解できずに反射レスしているような奴は馬鹿で、かつ加害者でもあることを自覚しろ。
お前らみたいな奴がいるから平気で506みたいな奴が沸くんだよ。
俺みたいな奴しかいなければ奴らはすぐ死滅する。他言語スレがそうだ。
JavaScriptのスレが糞なのは、お前らみたいなゆとりが馬鹿丸出しで口出ししてるからだよ。
スレの流れが読めないのなら自重しろ。

**デフォルトの名無しさん** · 2017/01/01(日) 18:08:54.61

クソ長い説明はだいたいが間違ってる。
どっかのトランスパイル馬鹿と同じ。

**デフォルトの名無しさん** · 2017/01/01(日) 18:42:12.80

ID:k8/wNRO9 は自分の書き込みが参考にならない事を正しいと認めたのだからスルーしてあげるのが優しさだよ

**デフォルトの名無しさん** · 2017/01/01(日) 18:49:08.37

なるほど、役には立たんことを逆説的に役に立つと言ってるから、
これが訳に立てば役に立たなくて、役に立てば役に立っていないのか。
難しい書き込みするなぁ。

**デフォルトの名無しさん** · 2017/01/01(日) 18:50:49.14

>>519
二段落目が、表現上意味が繋がらんな。
書き込みが役に立てばスレの役に立たなくて、スレの役に立てば役に立たない書き込み、だな。

**デフォルトの名無しさん** · 2017/01/01(日) 19:00:23.75

>>510を認めておいて何を小難しい解釈してるんだ？
読解力が足りない文盲はこれだから…