■質問を書く上で
(1) 質問にならない投稿はご遠慮ください。(煽り、コード制作依頼など)
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は
ttp://validator.w3.org/ で [Check] してみてください。 (8) 質問を具体的かつ詳細に書くと回答を得られやすいです。質問テンプレートを活用してみてください。
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【ライブラリ】使用しているライブラリ名を記入してください。(ex: jQuery)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
ttp://jsdo.it/ ttp://jsbin.com/ ttp://jsfiddle.net/ ttp://ideone.com/ 使い方が簡単でシンプルのものが欲しいです。
まず、「ルーティング」の定義から説明してみたら？
ttps://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0 こまけー
ルーティングはフレームワークと密接に
結びついているものなので
単体では存在しません。
他にも圧縮率など優れたライブラリがあったら教えて欲しいです
npmでzipやunzipで検索して使いやすそうなもん選べばいいと思うよ
（ container = new PIXI.Container(); ）
幾つかのパーツをひとまとめにした画像をスプライトに分割して使う時はさ
new PIXI.BaseTexture(source, scaleMode, resolution)
でペーステクスチャ作って
new PIXI.Texture(baseTexture, frame, orig, trim, rotate)
でパーツに分けて new PIXI.Sprite(texture) でやるのかなと思ったけど
デフォなやり方ってあるんすか？
あと分割せずにRectangleとかで範囲指定して
表示領域を変化させる方法とかあります？
あったわ！(ヽ´ω`)
ttps://github.com/kittykatattack/learningPixi#make-a-sprite-from-a-tileset-sub-image jsonでテクスチャアトラスデータつくってあとはそこで指定した名前でspriteつくるだけじゃないのかな？
ありがとう
どこかのブログで見かけはしたけど
わたしにはちょいむずいな(ヽ´ω`)
jsZIPが簡単
だけどjsでM単位のファイルはやめとけよ。
Chromeで試したけどどれもこれも止まって使い物にならんかったぞ。
使い方が悪いのでは？
巨大なファイルで時間がかかるのはわかりきっているのだから
ライブラリに細かく分割して処理するための機能があるか、
もしなければ別スレッドでやればいいだけだし
ただ10MBくらいだと同期でもいいくらいのはずだし、
反対に100MBを超えてくるとブラウザのメモリ制限に引っかかる恐れが出てくるので
シーケンシャルに作成しながらDBに保存していったり、サーバに送ると言った手間が要りそう
いつの時代の話をしてるんだ？？
クアイアント側でzipするの？
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない
Lazy.js > Lo-Dash > Underscore
Lazy.js って使われているの？
version 0.4.2 だけど
ZIPファイルをJavaScriptで扱ったけど1.1GBまでできたぞ
> 数百MBのファイルを扱うと
> 実際はその２倍、３倍のメモリを使うことにもなりかねないからね
ん？ なんか根拠あっていってんの？
まさか5MBのファイルを扱う時に15MB使っていたから、
100MBなら300MBに違いないとか思ってんの？
5MBのファイルに+10MBのワークメモリを使用するのなら
100MBなら+10MBで110MBですよ
なんで3倍とか思っちゃったのかな？ｗ
> 速さでは遅延評価する、Lazy.js が速いらしいけど、
それって遅延評価することで計算が省ける場合に限っての話でしょ？
殆どの計算は遅延評価のオーバーヘッドがないぶん
普通に計算したほうが速いと思うけど
ホラ吹きかよ
何で煽ってるのかわからないな そりゃ実装の工夫次第だけど、
まず原本ファイルがあって、各チャンクを圧縮したり、暗号化したり、
最後にZIPファイルとしたり固めてたら、
一時的に元ファイルの２倍３倍使ってしまうこともあり得るでしょ
だから512MBが上限だと思うなら、そういう『工夫のない実装』だと
100MBくらいが安心してサポートできる上限だ
100MBを超えてくればメモリ管理を特に意識する必要が出てくる
と言ってるだけなんだよ？ 全くもって自明でしょ？
でたでた後付け厨w
俺の至らないレスで気分を害したことは謝る
本当に済まない
本当に済まない
本当に済まない
だけど俺は終始真面目に話をしてるんだから
頼むから煽らずに建設的な話を続けて欲しい
なぜそんなに煽ってくるのか困惑してる
突っ込みに対して補足を入れたら後付け厨なのか？
それとも最初から突っ込みが絶対入らない呪文を書けるとでも思ってるのか？
いっぺんに思考の全てを文章にして相手にぶつけることなんてできないんだから
こうして会話して行ってお互い真意を探るのは良いことだろうよ
それをあざ笑ったり煽るのは、真意を探ろうとかいう気持ちじゃなくて
最初から攻撃目的の突っ込みじゃないのか？
俺はそれは絶対に間違ってると思うよ
たった一行の草生やした煽りレスに一々構うのは労力の無駄だぞ
こいつは相手したらだめだよ
小学生並の屁理屈で自分が偉いと勘違いするタイプ
そもそも、相手の話のコアが通じない時点で立派なコミュニケーション障害なのにその認識の差異を必死でアピールというどうしようもないやつ
1GBの動画fileをスライス
↓
スライスしたfileをAES暗号化
↓
ローカル上でZIP化
↓
ローカルに保存
IE11で何度か試してみたけど1GBまでは成功したぞ
環境による
逆にブラウザが保証してくれてもOSにブラウザプロセス毎殺されることもあるだろうし
まあ普通のデスクトップツールならファイルとして書き出しながら処理するから
極端な話圧縮辞書くらいしかメモリ使わなくても済むが
WebのJSでやるのはちと大変だろうな
環境によるなら、3倍メモリを使うのも環境によるわけで、
えらっそーに（笑）断言するべきじゃなかったですねｗｗｗｗ
誰か何を断言したの？
主観が標準
思い込んだことが標準
否定されると事実をねじ曲げて牙を向ける
指摘されると挙げ足をとって話をそらす
またいつものこう言った輩だろ。
主観条件を想像して平気でこんな発言している。
>>実際は2倍、3倍のメモリを使うことにもなりかねないからね
今の時代だよ
数百MBのファイルを扱うと
実際はその２倍、３倍のメモリを使うことにもなりかねないからね
デスクトップEdgeでも512MBしか保証されていない
そうや3倍とかにもなりかねんのや
不安だろう？
我が言霊の力じゃよ
こうやって言葉で揺さぶりをかければ
相手に不安を与えるもんなんじゃよ
これが人生経験というものかのう
下手すれば5倍、いや10倍、もっといけば100倍にも
なるかもしれんのう。そうなったらどうするんじゃ？
おまえって生きてて悲しくならないの？
勝てない喧嘩なら最初からふっかけるなよ
その判断すらできないからいつもそんな惨めな人生おくることになるんだぞ
そもそもローカルで512Mとか技術ありませんと認めたようなもんだろw
Edgeでjs制御すればGB単位の処理する方法はあるからな。
まるで道具の使い方を知らない土人だな。
その何GBでもOKな自身のEdgeに少し分けてもらえばいい
否定したいからじゃね
アリバイがないことがお前が犯人の証拠！
正論や事実を突きつけられると突拍子も無いことや極端な例えを持ち出す人とたまにいるよね。
これに該当する人も必ず書き込みするよ
人と違う考え方が格好いいとかズレた考えの人もいる。
ただ偏屈なだけかも。
今回のは見当違いというか噛み合っていない
のことか？
天の邪鬼や社会不適合者の類いだな
どこかで、見たような気がするのだが、探せない
それと、lodash の日本語訳は無い？
無いよな
結局、lodash厨は、この板で普及活動だけして、日本語訳を作らなかったのか
お前の能力の低さは隠せないぞｗ
lodash、英語とか日本語以前に
コードがあるからそれで十分じゃね？
関数の使い方と戻り値から何をしてるのかわかるでしょ
たとえば何か１ファイルを取ってくるのだったら
fetchXxx()という名前の関数にするのが良いと思うぞ
直接ユーザーに出さないのなら殆ど開発者の好みの問題でどうでもいいとも言える
ただね、Fetch APIっていうのはとても素直に見えて、
実は少し細かいことをやると特殊な仕様の宝庫だからね
つまり、結局は、ブラウザ上で「フェッチ」するためのAPIであって、
Nodeでもどこでも使いやすい、汎用的なhttp通信のためのAPIではないということ
だからおれは、もしAPIを提供するときにfetch感を出すときは、取得する物と方法を決め打ちして、
中間を見せないfetchXxxという名前の関数にしなさいといったの
で、結局はfetchでもrequestでも、環境にそぐわないAPIの叩き方、使われ方をされることに
どういう対処しているのかが、例え君がそういう使い方をしないとしても、『良いAPI』を見極めるために重要だと思う
でも一番いいのは、http通信なんてコード量大したことないんだから、自分でラッパーを書くこと
そしてその名前をfetchでもrequestでも無いものにしておくこと
標準的な物に沿うことも重要だけど、それがはっきりしていない場合はあえて開き直って完全独自にすることも重要
何が言いたいのか
俺が先に書いておけばよかったね。といっても「どちらも流行ってない」が答え
事実だけど煽り見えるだけなので書くのが面倒で放置していたら長文野郎に絡まれたねw
まあ俺も長文野郎だけどw
がごちゃごちゃ言い訳がましいことを言ってるのは
"ウェブ標準を推奨したいけど欠点があるから" なんだよ。
はっきり（今の）ウェブ標準はクソと言い放ってしまえばいいのだけれど
この人、ウェブ標準大好きな人だからそれが言えないんだろうねw
まず今の標準化されてるブラウザのFetch APIはクソ。なぜならもともとAjax（XHR）で
できていたはずのキャンセル機能や進捗情報ができなくなってしまっているから。
それもこれもPromiseなんか採用してしまったから。
だからFetchもRequestもPromiseを使っているものは現時点では全部アウト
そして今頑張ってFetch APIにキャンセルと進捗状況を取得できる機能が追加されようとしてる。
本来はPromiseに追加すべき機能だけど、Promise作ってる奴らが動こうとしなから
Fetch APIの方に組み込もうとしている（将来それがうまくいけばPromiseに移植されるかも）
このように現在は "ウェブ標準" のFetch APIは制限があり仕様は過渡期であるため薦めることができない。
そのことをはっきり言わないからはごまかすようなレスになってる。俺ははっきりいう。
（今の）Fetch APIはクソ。Requestはウェブのような標準仕様がないのでクソ
Promiseを採用しているならば、それもクソ。よってどちらも流行ってるなんて言えるもんじゃない。
それから完全独自実装なんて手間がかかるだけ。バカがやること。これだけはやってはいけない。
とは言え現時点では標準もブラウザでネイティブに動かすのも諦めるしかない。
だからSuperAgentなんかが有名でいいんじゃないか？ 将来は別の何かに置き換えることになるかもしれないが
その時、完全独自実装の大量のコードを読み解くよりも、
ライブラリを使って少ないコードでシンプルに書いていれば変更は楽になる。
条件を満たすライブラリがあれば中の人が全部吸収してくれるからベスト
自分でXHRやhttp使ってラッパー書いてもいいけどね
この辺はpolyfillで何とかなりそうだけど, これに加えてCookieの取り扱いがブラウザとnode-fetchで違っていて辛そうだと思った
promise自体がクソだとは思わないけど現時点で機能不足だというのは確かにその通りだと思うわ, 少なくともPromise/A+の現時点の規格では時間の掛かる処理にはとても使えない
progressとかcancelは一応under discussionみたいだし将来に期待しておくことにする(それまではQでも使えばいいのかな)
とりあえずSuperAgentとpromiseベースだけどprogressとcancelが出来るaxiosとで比較検討してみますわ
どうもありがとう
だってまずはヘッダを取得して、そこから更に何をするかとなるのが自然だから、そこまでは普通
fetchが出すResponseがReadableStreamを返す仕組みなのも苦労とかじゃなくてごく自然
ただReadableStream自体は微妙というかObservableであったほうが良いとは思う
そしてキャンセルはあるべきだけど、なぜか皆Promiseに付けろと思うけどそれは間違い
実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
だから、.cancelの提案なんてない。代わりにCancelToken型の用に仕組みが分離してあるものが提案されている
これならObservableにも使えるしずっと筋が良い
だからFetch APIはPromiseではないものを返すべきだってことなんだが。
お前の結論からもPromiseを返すのがおかしいという結論にたどり着いてるじゃんか
目的はPromiseを返すことではない。Promiseは手段でしかない。
時間がかかるから非同期を使う。ということはよくよく考えてみると
非同期は時間がかかる以上キャンセルと進捗状況の確認機能は必須であることに気づく
だからPromise自体筋が悪い仕様だったってことなんだよ。
という考え方だから便利な機能はサポートされない運命
実用的なPromiseの一つであるbluebirdはキャンセル機能が搭載されている
ttp://bluebirdjs.com/docs/api/cancellation.html > 実際はPromiseに生えてたら凄い使いにくいし、Promiseの概念上分かりにくことになるのは考えたら分かる
それはあなたの感想ですよね？
> だから、.cancelの提案なんてない。
普通にあるが？
ここまでの流れを示しておくわ
Fetch の中断と Promise のキャンセル方法の標準化
ttps://blog.jxck.io/entries/2017-07-19/aborting-fetch.html あーあー、本来はPromiseにキャンセル機能が搭載されて
シンプルになったはずなのになー。
理想の案ではなくて次点の案ですすんでるとはな
今更に否定されたCancelTokenとか持ち出されてもw
> 要約すると以下のようなものだった。
>
> CancelToken (.NET の知見) という API 経由で Promise をキャンセルする。
> キャンセルはエラーとは違うため、 resolve/reject 以外に 3 つめの状態を追加する。
> しかし、結論から言うと議論の途中で頓挫してしまった。
>
> なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
>
> Why was this proposal withdrawn? #70
今最も、そして唯一のPromiseのキャンセル関連の仕様なのは間違いない。
ttps://dictionary.goo.ne.jp/jn/162000/meaning/m0u/ とん‐ざ【頓挫】の意味
１ 勢いが急に弱まること。また、計画や事業などが途中で遂行できなくなること。
「活動に一頓挫を来?(きた)?す」「不況で事業が頓挫する」
棄却に相当するものは事業が失敗する、会社が潰れるなどのことだよ。
頓挫というのは勢いが急に弱まる事を言う
誰もが何らかの仕組みが早く欲しいと思い続けてきたキャンセル周りにおいて、その場しのぎにしかならない価値の薄い.cancelではなく
ようやく新しい構文だとか何もかも含めて全体的に上手くいきそうな提案が出てきたけどスムーズに進まなかったという、大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
ES DiscussやMeetingを追ってすらもない奴らが自分の意見を肯定するためだけに書かれた気持ちや前提を汲まず悪用するのは気分が悪いね
> 大きな期待と逸る気持ちがあってこそ出た大袈裟な失望の言葉なのに、
それはあなたの感想ですよね？
何処かに定義でもあるんですか？
ステージが進まないのなんて珍しくないし、実際提案の勢いに変化が生じた訳ではない、ただキャンセル周りの仕様がサクサク決まることは難しそうという不安感は出てきた
とは言っても.cancelがあり得ない以上、似た仕様になる事は確実
じゃあまずどうして.cancelが失敗したのか、そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
その上で具体的な疑問があれば答えるから
リスクが大きいってことだな。
SuperAgentもしくはaxiosを使うのが現実的
じゃあなんで頓挫したのか教えて
なんで頓挫したかの詳細は、仕様策定の中心だった domenic の悲痛な一言に集約されている。
ttps://github.com/tc39/proposal-cancelable-promises/issues/70#issuecomment-267414933 ttps://github.com/tc39/proposal-cancelable-promises This proposal has been withdrawn
This proposal has been withdrawn by its champion and is no longer
active in the TC39 process. For reference to previous documentation
and specification work, see the Git commit history.
ちなみにwithdrawnには撤退という意味がある
空っぽになってしまった、これこそがCancelTokenである
const cancelToken = new CancelToken(cancel => {
cancelButton.onclick = () => cancel("The cancel button was clicked");
});
performCancelableOperation(cancelToken);
ttps://github.com/tc39/proposal-cancelable-promises/tree/0e769fda8e16bff0feffe964fddc43dcd86668ba 削除されてしまったのか？
削除されたのにリポジトリを残してるのは
単なるあてつけだとかるが
ではなぜ
CancelTokenはなぜ仕様の内容が
削除されてしまったのか？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
> そして今CancelTokenは奴に否定されたのに残ったのかを考えた方が良い
残ってないよ。
リポジトリの中身は削除されてる
元をたどればで
CancelToken『型の用に仕組みが分離してあるもの』
と書いたように、俺はCancelTokenそれだけに拘って考えて言っていたのではない
例えば俺がstage0だなんだ言ったのはCancellation APIを意識してたから
そこんところごっちゃにしてたのは本当に謝る
CancelTokenが消えたのは、結局CancelablePromiseが否定されたのを、
じゃあcancel状態の代わりにelse状態を持ってればいいだろというように
結局皮が剥け切れて無かったから、そこを奴に付かれた
だから逆に言うと、「分離」してある形になるのはより確実になってきたと言える
俺が言いたいのはそこ
今も生きてる仕様がどこに書いてあるかを言えばいい
俺が言ってたのはこれ
ttps://github.com/tc39/proposal-cancellation ⇒
ttp://asaswq3wq.sblo.jp/article/181819223.html 興味がある人だけ見てください。
KH0BV0X79E
ttps://uppy.io/examples/dashboard/ このライブラリすご
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』
NHNSG
