【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/04/11(月) 16:28:34.52

pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&;lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 3【io.js】(c)2ch.net
http://echo.2ch.net/test/read.cgi/tech/1419673207/
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/

**デフォルトの名無しさん** · 2017/07/26(水) 16:04:27.16

ちなみに、なんでクラスで書こうと思ったのかと言えば
クロージャとクラスのインスタンスが内部的には等価だと思っていたからです

**デフォルトの名無しさん** · 2017/07/26(水) 16:54:58.69

codepenとか使うかgithubに上げるかして欲しいわ。
正直zipでってなんかイャ

**デフォルトの名無しさん** · 2017/07/26(水) 16:56:23.68

>>728
将来の自分のためにも流儀は合わせておくべき。
コード量の削減に影響するとも思えない。

**デフォルトの名無しさん** · 2017/07/26(水) 21:17:16.61

>>728
thisが違うことから等価じゃないことが証明されてるでしょ？
じゃあクラスで書こうと思った理由は消滅してるよね？
ならクラスで書くのをやめるべきだよね？

**デフォルトの名無しさん** · 2017/08/18(金) 21:49:38.61

useの第2引数に何が許されてるのかドキュメント読みなさい

**デフォルトの名無しさん** · 2017/08/27(日) 14:46:16.26

forkの経緯を眺めてたけどこれio.jsの時と違って結構めんどくさいな
これまでのNodeは人治主義のOSSだったってことか

**デフォルトの名無しさん** · 2017/08/27(日) 15:42:03.26

シングルスレッドだから遅くならないって言うけど
マルチスレッド言語で動的にスケールすればいいでしょ？

**デフォルトの名無しさん** · 2017/08/27(日) 15:44:19.45

Node.js Foundationに対し不安を持つグループによるNode.jsのフォークプロジェクト「Ayo.js」誕生
https://mag.osdn.jp/17/08/25/163000

**デフォルトの名無しさん** · 2017/08/27(日) 15:53:01.24

>>734
だよな

**デフォルトの名無しさん** · 2017/08/27(日) 15:53:18.14

>>735
matakayo

**デフォルトの名無しさん** · 2017/08/27(日) 16:05:49.89

シングルスレッドだから遅くならないなんて言っている人なんているかねぇ？
C10Kの話ならかなりニュアンスが違う。

**デフォルトの名無しさん** · 2017/08/27(日) 16:12:18.21

優秀な一名をこき使うから速いんだな。
ほんの少しでも空時間があったら仕事をぶっこむ。
人間なら死ぬわ。

**デフォルトの名無しさん** · 2017/08/27(日) 16:17:42.17

>>738
メモリ使用量が増えないってnodeのメリットじゃないの？
そんなのスケールアウトで十分だと思うんだが

**デフォルトの名無しさん** · 2017/08/27(日) 16:22:23.64

> メモリ使用量が増えないってnodeのメリットじゃないの？
だれがメモリ使用量が増えないというメリットが有ると
いったんだ？お前の脳内か？

**デフォルトの名無しさん** · 2017/08/27(日) 17:35:42.54

nodeが良かったのはは非同期apiにより
プロセスあたりのリクエスト処理数を高めたからでしょう？
マルチプロセスにすればその分リクエスト処理数もある程度スケールしてくれる。ただしdbアクセスは考慮しないものとする

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

mongoDBとかNoSQLとはなんだったのか

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

>>743
nodeとは全く別もので、ただのデータベース

**デフォルトの名無しさん** · 2017/08/28(月) 11:26:19.65

Nodeが普及したのは良いサイバーサイドJS環境だったから

**デフォルトの名無しさん** · 2017/08/29(火) 09:43:28.14

let dict = {}
で辞書のように使おうとしたんだけど、
dict['constructor']ではまった
アレイにkvペア入れて頑張るしか無いの?
16万項目あるので線形検索は躊躇う

**デフォルトの名無しさん** · 2017/08/29(火) 10:19:27.35

Mapを使うとかlet dict = Object.create(null)とか

**デフォルトの名無しさん** · 2017/08/29(火) 11:53:07.27

>>746
16万項目のデータをメモリ内に置くのか。
もっといい方法無いかな。realmとか使えればいいんだけど。

**デフォルトの名無しさん** · 2017/08/29(火) 11:59:45.48

Object.createで上手くいった
try catchで検出してエラーになるのを、別管理と考えてたけど、すっきりした
さんきゅ

**デフォルトの名無しさん** · 2017/08/29(火) 12:07:49.40

>>748
db構築に使うフォーマット変換ツールなので、適切な時間で終了する事が要件で
利用リソース量はあまり気にしない

**デフォルトの名無しさん** · 2017/09/03(日) 12:30:07.14

eslintとそれにぶら下がるプラグイン本当互換性がない
ツール入れる所でトラブらないといけないとかだるいわ
これだからJavaScriptなんて書きたくないんだよ

**デフォルトの名無しさん** · 2017/09/03(日) 12:34:43.60

eslintのプラグイン何を使おうとしてるの？
使わなければいいじゃない

**デフォルトの名無しさん** · 2017/09/03(日) 12:59:47.72

airbnb辺りのプリセット使えばええやん

**デフォルトの名無しさん** · 2017/09/03(日) 20:32:32.58

そのairbnb関連のjsx-a11yとかな
https://github.com/evcohen/eslint-plugin-jsx-a11y/issues/283

**デフォルトの名無しさん** · 2017/09/04(月) 11:57:48.72

>>742
そういうのもNginxやApacheがある程度やってくれるようになってるからね。
後ろは好きな言語をそのまま使えばいい。PHP-FcgidとかuWSGIとかRackとかServletとか。

**デフォルトの名無しさん** · 2017/09/04(月) 18:58:52.14

>>755
非同期apiはphp処理系では無理じゃない？phpはインスタンスの生存時間がリクエストを受けてからレスポンスを返すまでの固定だよね。

どうやってイベントループ回すの？

**デフォルトの名無しさん** · 2017/09/04(月) 20:39:48.99

>>756
フレームワークによってはイベントループで生存期間が無限のものもあったはず。
前の会社で、そういうWebSocketフレームワーク使おうとしてたよ。

…そんな用途全く想定してない普通のPHP用のオレオレライブラリ組み合わせて
メモリリーク起こしてたけど（藁

**デフォルトの名無しさん** · 2017/09/05(火) 08:00:30.55

>>757
メモリリーク起こすなら使えないな。
phpってインスタンスの生存時間短い前提だから、
メモリリークってさほど気にしなくて良い言語なのかも。
素直にjsでいい気がするけどね。今の時代。
yahooで勤務してる知り合いも今はjsでサーバサイドを書いてるってさ。

**デフォルトの名無しさん** · 2017/09/05(火) 14:51:11.75

もともとCGIはリクエスト毎にプロセス作ってサービスしてた
なので、一つのリクエストが終了するとperlやphpのプロセスも終了するので、オブジェクトを解放(リファレンス外す)しないCGIが多くある

ところが、これじゃおせーよと言うことで、終了させないで無理やりに複数リクエストを処理させる仕組みをでっち上げた
これがPHP-FcgidとかuWSGI

リークしまくりのサービスが出来上がり

三菱とかやりそうだろ

**デフォルトの名無しさん** · 2017/09/05(火) 15:05:46.14

だから一定数のリクエストを処理したらプロセス再起動する
三菱でも大丈夫

**デフォルトの名無しさん** · 2017/09/05(火) 15:06:06.76

メモリだけじゃなくて
CPUもファイルI/Oも簡単に食い潰せるからな

**デフォルトの名無しさん** · 2017/09/05(火) 16:00:05.67

>>760
なるほどね。大雑把な作りだ。
大昔Dephiの案件をやった時に、PLが
ひとかたまりのEXEを画面ごとにバラバラのEXEにして
切り替えるたびに終了させる仕組みを作り出して、メモリリークを
極力抑える仕様にしてたの思い出した(データはDBにおいてる)

**デフォルトの名無しさん** · 2017/09/05(火) 17:07:49.21

>>760
三菱は自動再起動なんて技術がないから、連絡受けて手動で再起動してた

**デフォルトの名無しさん** · 2017/09/06(水) 21:18:48.34

何故、三菱が引き合いに出されるのだ?
なんかやらかしたんかい。

**デフォルトの名無しさん** · 2017/09/06(水) 21:34:30.85

Librahackで検索

**デフォルトの名無しさん** · 2017/09/06(水) 22:59:23.06

三菱電機インフォメーションシステムズ (MDIS) 製のソフトウェアは、
1時間に400以上リクエストを送られると他のリクエストの処理が不可能になる不具合を含んでいた

これか?
9秒に1回以上で破たんするなんてどんな実装か興味津々

**デフォルトの名無しさん** · 2017/09/06(水) 23:25:37.77

これを読むとイメージがわかる
http://takagi-hiromitsu.jp/diary/20130316.html
http://el.jibun.atmarkit.co.jp/pressenter/2012/09/1-0f4e.html (事件をモデルにしたフィクション)

**デフォルトの名無しさん** · 2017/09/07(木) 03:05:39.43

そもそもDOMとのメモリリークとかまともに対応してきたJS界のエンジンが優秀過ぎるだけで
他のサーバサイド言語で環境を跨いた循環参照とか上手く処理できるエンジンは無いし、他のGC技術や調整も何年も遅れてる

**デフォルトの名無しさん** · 2017/09/07(木) 06:19:08.39

WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
普通にやったんじゃできないよね。

**デフォルトの名無しさん** · 2017/09/07(木) 07:18:46.25

応答しなければいい

**デフォルトの名無しさん** · 2017/09/07(木) 09:17:55.33

>>769
expressだって、グローバルスコープの変数にコネクション保持すれば、その参照切るまで残るぞ

**デフォルトの名無しさん** · 2017/09/07(木) 12:06:54.84

>>769
膨大な数のリクエスト処理するのになぜ閉じるのかが逆に理解できないんだけど
普通WebアプリやサービスのDBはつなぎっぱなしだとおもう

**デフォルトの名無しさん** · 2017/09/07(木) 12:43:46.04

Webのセッションが終わってるのにコネクションをセッションのために１０分間保持してたって事でしょ?
普通はコネクションは閉じないがWebのリクエスト毎に紐付けは開放でしょ。

**デフォルトの名無しさん** · 2017/09/07(木) 13:10:59.01

>>773
アプリサーバーとか作ったことある？

**デフォルトの名無しさん** · 2017/09/07(木) 14:19:14.16

>>773
その紐付けを解放しないのが三菱流

**デフォルトの名無しさん** · 2017/09/07(木) 19:20:21.66

>>774
ないズラ
そんなヤツ僅少だろ

**デフォルトの名無しさん** · 2017/09/07(木) 19:23:08.30

>>775
三菱に限らずSIerの技術力低下が半端ない

**デフォルトの名無しさん** · 2017/09/07(木) 22:32:27.03

自分達の底辺技術レベルが原因で、無実のエンジニアを罪人にして、ほっかむりしたのは三菱だけ

**デフォルトの名無しさん** · 2017/09/08(金) 00:15:56.20

ちなみにDBってopenとtransactionを分離している奴があるけど、これって何で？
例えばIndexedDBでもそうで、open後にtransactionを作ってアクセスしなければならない。
しかし普通に読み書きだけなら
DBWrite(DBname, objectStores, key, value)
みたいなAPIでクエリ毎にopen/close繰り返した方が使う側は楽だよね。

何らかの理由でopenが重いから分離しているのだろうけど、
普通に実装すればそんなに重いとも思えない。
（実際はopenは数秒かかる時もある程重いが）
これって何で？

ちなみに類似ケースはXHRで、通常は毎回XHRをnewするだろ。
indexedDB.openもそれに近くて、本来はオブジェクトを初期化するだけで終わるはず。

**デフォルトの名無しさん** · 2017/09/08(金) 00:27:44.82

>>769
> WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
> 普通にやったんじゃできないよね。

コネクションプールを使ったら普通にそうなりますが？

**デフォルトの名無しさん** · 2017/09/08(金) 00:28:57.91

>>779
DBをopenしてselectしてcloseするなら
トランザクションいらないでしょ？

**デフォルトの名無しさん** · 2017/09/08(金) 00:31:58.67

>>779
> 何らかの理由でopenが重いから分離しているのだろうけど、
> 普通に実装すればそんなに重いとも思えない。

ゆえにopenが重いから分離しているという
あなたの想像は間違いだって言うこと。

根拠のない想像を結論にしないようにしよう
検証の前にあるのは結論ではなく仮定という

トランザクションは複数の操作を一塊にするもので
openが軽いのとは関係ない話

**デフォルトの名無しさん** · 2017/09/08(金) 00:47:45.77

>>781
IndexedDBの場合はトランザクションは常に必要だ。
他の楽観的なトランザクション分離のDBについては知らん。

>>782
では何故openとtransactionを分離するんだ？
最初からtransaction単位でopen/closeするAPIにしておけばいいだけの話だろ。
そこを分離して手動でやらせる理由が分からん。

**デフォルトの名無しさん** · 2017/09/08(金) 00:55:56.99

IndexedDB特有の話なら、IndexedDBの話だって書けよ

はい、トランザクションつかってませーん。ばいなら

http://qiita.com/butakoma/items/2c1c956b63fcf956a137#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%B9%E3%83%88%E3%82%A2%E4%BD%9C%E6%88%90

オブジェクトストア作成
オブジェクトストアは、RDBでいうテーブル。

var storeName = 'sampleStore';

var openReq = indexedDB.open(dbName, dbVersion);
// オブジェクトストアの作成・削除はDBの更新時しかできないので、バージョンを指定して更新

openReq.onupgradeneeded = function(event){
var db = event.target.result;
db.createObjectStore('storeName', {keyPath : 'id'})
}

**デフォルトの名無しさん** · 2017/09/08(金) 00:57:25.86

IndexedDB特有の話ならtransaction使わないと
readonlyなのかreadwriteなのか決められないからだろ

**デフォルトの名無しさん** · 2017/09/08(金) 01:14:01.64

>>779
DBへの接続(open)とトランザクションは別のレイヤーだからだよ
1つの接続で2つのトランザクションを実行したい場合どうすんの？

transactionを明示的に指定しない場合に
デフォルト設定で例えばステートメント単位でトランザクションになるような仕組みがDBにあればtransaction指定は必須でなくなる
一般的なRDBはそうなってると思うけど

**デフォルトの名無しさん** · 2017/09/08(金) 01:20:17.29

>>784-785
つかお前根本的に分かってないだろ。

IndexedDBはonupgradeneededの時は最初からトランザクションを張っている。
これはMDNからはとてもそうは読めないのだが、とにかくそう。

そしてAPIが
> DBWrite(DBname, objectStores, key, value)
> DBWrite
とかでいいのではないか？というのが俺の疑問なのだが。

何故かは知らんがDBには「繋ぎっぱなし」の文化はあるんだよ。>>772
IndexedDBのAPIからもそれは読みとれる。
> Web アプリが別のタブで開かれているときにバージョンを変更する
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB
毎回閉じる文化ならそもそもこれは要らない。

MDISはこの「繋ぎっぱなし」の文化でWeb側にも解放したらリソースが枯渇しただけだろ。
ただそもそもこの「繋ぎっぱなし」ってなんなのさ？
open/closeが軽いのなら毎回open/closeすればいいだけだし、
普通に実装すれば重いとも思えないし、ということなのだが。
（ただし実際にはIndexedDBでもopen/closeは重い）

**デフォルトの名無しさん** · 2017/09/08(金) 01:26:20.56

>>786
> transactionを明示的に指定しない場合に（以下略）
これについてはそれでいい。
APIコール1回＝1つのtransactionになるって事で。

> 1つの接続で2つのトランザクションを実行したい場合どうすんの？
これってどういうケース？
その2つのトランザクションをくっつけて1つのトランザクションにしておけばいいだけの話では？
並列性を限界まで出したくて、例えばライト/リードでトランザクションを分けておきたいとかか？

**デフォルトの名無しさん** · 2017/09/08(金) 03:16:51.74

>>788
1回の接続で複数トランザクションを実行したいケースってあんまりないのかな
例えば２つのトランザクションのうち後者が失敗しても前者をロールバックしたくない時とか考えてみたら？

トランザクションのたびに再接続するので良いケースもありうるけどそうじゃないケースもありうるよね
だから一般的にはトランザクション境界と接続の開閉を一つにしたAPIってのはいい設計じゃないと思う

>>787
繋ぎっぱなしの文化なんかなくて、ただの開放漏れのバグだよ
openしたらcloseするのが必須

**デフォルトの名無しさん** · 2017/09/08(金) 08:36:52.78

>>780
コネクションプーリングはコネクションを使いまわす仕組みだからDBには繋がったままだけどWebのセッションからはリクエストの度に切り離される。
とっくに終わってるセッションがコネクションを独占するようなアホな作りはどうやったらできるのかって事。

**デフォルトの名無しさん** · 2017/09/08(金) 08:40:11.92

>>787
繋っぱなしってコネクションプーリングのことでしょ。アプリから見ると毎回、open/closeしてるように見える。

**デフォルトの名無しさん** · 2017/09/08(金) 09:36:43.18

>>790
コネクションを独占ってなんだ？
異なるセッションから、コネクションを使いまわすのがコネクションプーリングなんだが？
セッションが終わってるっていうのなら、コネクションは明け渡してるだろ

**デフォルトの名無しさん** · 2017/09/08(金) 09:38:38.44

>>787
> IndexedDBはonupgradeneededの時は最初からトランザクションを張っている。

じゃあなおのこと、openでトランザクションは貼れないな。
だって、何の操作をするかで、トランザクションの種類が変わるわけで
openした時点ではわからないんだから

**デフォルトの名無しさん** · 2017/09/08(金) 09:40:18.14

>>787
> そしてAPIが
> > DBWrite(DBname, objectStores, key, value)
> > DBWrite
> とかでいいのではないか？というのが俺の疑問なのだが。

トランザクションは複数のDBWriteを
一つにまとめるものなんだから
それじゃだめだろって言ってるんだが？

いいからトランザクションを勉強してくれ
お前、根本的に分かってない（笑）

**デフォルトの名無しさん** · 2017/09/08(金) 11:27:15.08

>>792
>>766-767

**デフォルトの名無しさん** · 2017/09/08(金) 19:22:44.56

>>789
ただのバグでMDISが糞だというのは同意だが、APIは糞だぞ。

> 例えば２つのトランザクションのうち後者が失敗しても前者をロールバックしたくない時とか考えてみたら？
これなら2つトランザクションを打てばいいだけ。それで何の問題もない。

> トランザクションのたびに再接続するので良いケースもありうるけどそうじゃないケースもありうるよね
ねえよ。具体的に挙げられないだろ。

open/closeがAPIにある場合の利点は、連続した同一DBに対する2つのトランザクションで、
・open/transaction1/close/open/transaction2/close
を
・open/transaction1/transaction2/close
とでき、真ん中のclose/openを省ける分速度が稼げることだ。
しかしこの場合に、DB内部でキューイング機構を持ってこの余分なclose/openを自動的に省き、
・ユーザ側で手動open/closeした場合と、
・ユーザAPIはトランザクション単位で、DB内部で自動open/close
で、パフォーマンスが全く変わらない場合、前者を使う理由がないだろ。
(現実的にはユーザ側でコネクションプールを実装する必要であり、
これの代替としてDB内部でキューイング機構を持っていてもパフォーマンスは変わらないはず）

open/closeをユーザ側に見せている時、ユーザ側の解は以下で、
A. いちいちopen/closeして使う。
B. これがウザイから自前でラッパを用意し、
> アプリから見ると毎回、open/closeしてるように見える (>>791)
ようにする。
C. さらにこれもウザイから、何らかの既存ラッパ(PouchDBとか）を使う。
だろ。俺はまずAを試し、スループットが全く出ないのでBにしたが、車輪の再開発感ありまくりだった。
コネクションプーリングするのが常なら、最初から付けとけよボケ、でしかない。
（なおPouchDBもdb.open必須。多分これがDBのAPIの標準形だからだと思う）

**デフォルトの名無しさん** · 2017/09/08(金) 19:23:19.38

DBのAPIは意味不明で、そもそもオブジェクト指向にも反してる。
ユーザがやりたいのはread/writeであって、open/closeではない。
File.openの代わりにHDD.open+File.readというAPIにする奴がいたら、死ねでしかないだろ。

open/closeってもしかして今みたいなパケット相乗り回線ではなく、専用回線を掴んでいた時の名残か？

**デフォルトの名無しさん** · 2017/09/08(金) 19:24:30.23

>>790
MDISのケースは多分、図書館内端末用の界面にそのままWebを接続しただけだろ。
この場合、見た目は問題なく動く。
リソース枯渇のケースはコードから落とすしかないが、レビューが新規コードだけなら無理だ。
（この場合は新規コードはほぼ無しで、問題は今動作しているコード内にあるから）
おそらくMDISもB方式で、自前でコネクションプーリングしてる。
これは館内端末用で、端末に行列が出来ているかどうかは知る由もないから、closeはタイムアウトで10分とした。
ここまでは妥当な設計で、館内端末なんて高々数十台だし、問題なく動く。

問題はこれをそのままWeb側にも解放したことで、
この場合は一気に端末数が無限大になるのと等価で、コネクションが枯渇した。それだけだろ。
本来は、
D. Webからの入力を受ける「仮想端末」を用意し、Web入力は一旦全部そこで受けてからDBアクセス。
E. open/closeを毎回やるようにする。(Aと同じ）
のどちらかが必要で、本来はDの方がいいし多分そうしていると思う。
Dの場合はDDoS時にも館内端末は無傷で済む。
追加コードは仮想端末部分だけであり、既存コードには一切手を入れる必要がない。
Eの場合は全体のパフォーマンスが「いちいちopen/close」分だけ落ちる。
とはいえ真面目にDBを組んであればUIからでは見えないとも思う。
変更はopen/closeが内部APIで隠蔽されていれば数行、といったところか。
(そうなっていない場合は全体ソースを見直す必要があり、現実的ではない）

**デフォルトの名無しさん** · 2017/09/08(金) 23:49:21.12

>>796
もうめんどくさいな君w
DBへの接続とトランザクション境界を一致させた画期的APIを作って流行らせればいいよ？
一つのユースケースたけに特化したものとしては別にあっても悪く無いと思うよ
ただなぜそういう設計のものが存在しないのか考えてからね

**デフォルトの名無しさん** · 2017/09/09(土) 01:02:01.91

>>797
> ユーザがやりたいのはread/writeであって、open/closeではない。

そのうち二回のwriteを実行して二回目のwriteで
エラーが起きた時に一回目のwriteもロールバックするために
トランザクションがあるんですよ？

**デフォルトの名無しさん** · 2017/09/09(土) 01:12:33.18

https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB#Getting_data_from_the_database

データベースからデータを取得する

よーし、今から customers テーブルのデータを読み込むぞー！

var transaction = db.transaction(["customers"]);

おい、ちょっとまて俺はdbオープンした時に
自動的にトランザクション実行するぞ！
全てのテーブルに対してreadwriteロックじゃ
誰も読み込みも書き込みもできない
俺はcutomersテーブルなんか触らないけどなｗｗｗ

こういう迷惑バカが居るから、openとトランザクションは別にするべき

**デフォルトの名無しさん** · 2017/09/09(土) 01:14:33.64

>>798
open/closeのパフォーマンスを気にしてるのはお前だけだ
忘れろな

**デフォルトの名無しさん** · 2017/09/09(土) 01:16:06.59

>>798
> 問題はこれをそのままWeb側にも解放したことで、
> この場合は一気に端末数が無限大になるのと等価で、コネクションが枯渇した。それだけだろ。

誰もコネクションが枯渇したなんて言ってない

**デフォルトの名無しさん** · 2017/09/09(土) 01:26:53.73

>>798
当たり前すぎることだが、MDISのシステムは
「1時間に400以上リクエストを送られると他のリクエストの処理が不可能になる不具合を含んでいた」
と言ってるだけで、

ウェブのクライアントが直接DBに接続したなんて誰も言ってない。
そもそもそんなことはできない

ブラウザからデータベースに接続することなんてできない。
IndexedDBはお前、それブラウザん中に実装されてるもんだ。そこを勘違してたわけかｗ
MDISのシステムはIndexedDBを用意してなんかいない。時代的に使ってすらいないだろう

本当に当たり前のことだが、
> D. Webからの入力を受ける「仮想端末」を用意し

仮想端末じゃなくて、普通はアプリケーション・サーバーっていうんだよ。
PHPだとウェブサーバーの場合もあるな。MDISも当然その仕組みだ

> E. open/closeを毎回やるようにする。(Aと同じ）

open/closeを毎回やっても、パフォーマンス向上のために内部的にデータベースに
接続しっぱなしにする機能がコネクションプールだ。正確言うと
前回のリクエストで使った（使い終わった）コネクションを使いまわす。

> 変更はopen/closeが内部APIで隠蔽されていれば数行、といったところか。
あははｗばーかｗｗｗ　アプリは毎回open/closeをしてるんだよ。
コネクションプールというミドルウェアがcloseした時になにもしないように置き換えてるんだよｗ

**デフォルトの名無しさん** · 2017/09/09(土) 01:27:51.16

コネクションプールを行うためのミドルウェアが

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

>>802
少なくともコネクションプーリングを考えたヤツはopen/closeのコストが大きいと考えてる。
数十ミリ秒と数ミリ秒の差が影響するシステムもある。

**デフォルトの名無しさん** · 2017/09/09(土) 11:05:16.16

連想配列のキーに使用できる文字列の仕様ってどこに載ってますか？

**デフォルトの名無しさん** · 2017/09/09(土) 11:18:09.89

連想配列にキーが存在するかチェックするのならinが速いな

const o = {
'a': 1,
'b': 2,
'あ b': 3,
};

const key = 'あ b';

const l = 100000;
console.time();
for (let i = 0; i < l; i += 1) {
key in o;
}
console.timeEnd();

console.time();
for (let i = 0; i < l; i += 1) {
o.hasOwnProperty(key);
}
console.timeEnd();

//undefined: 5.921ms
//undefined: 9.741ms

**デフォルトの名無しさん** · 2017/09/09(土) 11:31:15.85

連想配列ならMapが最強
従来のオブジェクト形式が良いにしても
o = Object.create(null)でo[key]の方が早い

**デフォルトの名無しさん** · 2017/09/09(土) 11:46:17.16

o[key] = 0
で破綻するやん

**デフォルトの名無しさん** · 2017/09/09(土) 11:50:30.88

>>806
だからなんだよ。

トランザクションの話をしてる時に
open/closeのコストを考えるなって話だろうが

**デフォルトの名無しさん** · 2017/09/09(土) 12:01:05.07

>>808
> 連想配列にキーが存在するかチェックするのならinが速いな
一回あたり
59.21ナノ秒（＝0.00000005921秒）
97.41ナノ秒（＝0.00000009741秒）

だと10万回～100万回ぐらいチェックしない限り
速度を気にしたって意味なさそうだね。

**デフォルトの名無しさん** · 2017/09/09(土) 12:42:11.18

Object を連想配列にした場合、キーを、__proto__ にすると誤動作するから、
そのキーだけ、特別な処理が必要

他にも、使えないキーがあるかも

**デフォルトの名無しさん** · 2017/09/09(土) 12:46:58.91

>>813
どういう時に __proto__ をキーに使ったの？

**デフォルトの名無しさん** · 2017/09/09(土) 14:34:12.81

英文から、すべての単語を取り出して、出現回数でも調べたのかな？

どこかのサイトで、そういう質問を見た

**デフォルトの名無しさん** · 2017/09/09(土) 15:01:25.52

つい最近>>746でオレが聞いた

**デフォルトの名無しさん** · 2017/09/09(土) 15:37:47.37

>>815
そういう場合は、適当なプリフィックスをつけるだけで解決するね

obj['@' + word] = なんとか

**デフォルトの名無しさん** · 2017/09/09(土) 16:00:58.16

Object.create(null)で作ったオブジェクトには__proto__は無いし自由に値を設定できるこれ豆

**デフォルトの名無しさん** · 2017/09/09(土) 17:11:43.49

Object.create() は、ECMA 5.1, IE9 以上か

こういう機能が無かった、ES3 の頃の話かな

**デフォルトの名無しさん** · 2017/09/09(土) 19:32:09.22

chromeのdevtoolsからconsole.dir({})やるとオブジェクトの中身が見れるけど
nodejsの場合はどうやって見るんでしょうか？

**デフォルトの名無しさん** · 2017/09/11(月) 09:40:29.07

○次受けが多いほど退場率が早くなる。高くなる

直受けの50万客：いつまでもうちにいていいよ
3次受けの50万（客は90万払ってる) 客：短期延長していい？
5次受けの50万（客は150万払ってる) 客：作り終わったらとっと出てけ　できなかったら即退場だ　
長時間労働　高稼働　高スキル要求が多い

フリーランスサイトを運営している零細ITの自称エージェントは労働市場から流れてくる案件を転売してるだけだった。
労働市場に加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む

エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3　= 言い値50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募できる

eJobgo　JIET　JISA　で検索

優良エージェント・優良サイト

首都圏IT(PE-BANK) 　プログラマーズ

**デフォルトの名無しさん** · 2017/09/12(火) 14:01:13.14

https://github.com/rook2pawn/node-ddos
調べ物をしている最中にこんなの見付けたんだけど
Httpdがリクエスト受け取ってる時点でDDoS対策にならないんじゃないの？

**デフォルトの名無しさん** · 2017/09/12(火) 14:33:55.38

>>822
動作の軽いリバースプロキシ立ててそこで対応するほうがよさそう

**デフォルトの名無しさん** · 2017/09/12(火) 15:30:08.72

node 8.0ってimpotr対応してないの？

**デフォルトの名無しさん** · 2017/09/12(火) 18:35:03.20

Chromeですら対応したというのに・・

**デフォルトの名無しさん** · 2017/09/12(火) 18:49:24.80

node 8はこの秋LTSになるんだからアグレッシブに最新機能は入れないよ
node 9には入る

**デフォルトの名無しさん** · 2017/09/12(火) 21:29:56.96

くそっ、typoかよ騙された

**デフォルトの名無しさん** · 2017/09/15(金) 21:47:46.74

>>810
どういうこと？くわしく