【node.js】サーバサイドjavascript 5【Nashorn】 (796ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
99: デフォルトの名無しさん [sage] 2018/05/24(木) 11:04:01.98 ID:cPlRxlDn(1) AAS
AY2FW
116: デフォルトの名無しさん [sage] 2018/07/05(木) 16:37:50.98 ID:AeL6VB/V(1) AAS
PMV
118(1): デフォルトの名無しさん [sage] 2018/07/14(土) 22:13:07.98 ID:sptiC22u(1/2) AAS
npmってのはnode.jsでサーバサイドアプリケーションを開発する人専用のツールではなく、
Javaで書かれたプログラムを実行するのにJavaVMが必要なように
何か使いたいアプリケーションがnode.jsで書かれていて、
それをインストールするために必要なものという認識でよいのでしょうか？
なんかちょっと使いたいものを調べるとなんでもnpmが出てくるのですが、
別にnode.jsで何かサーバサイドアプリケーションを作りたいわけではないので、
なんでいちいちnode.js導入しないといけないのだろうと思ってたのですが。
151: デフォルトの名無しさん [sage] 2018/07/19(木) 10:22:17.98 ID:jn3CABTs(1) AAS
サンプルコードとexpected/actual見ないと何とも言えんな
220: デフォルトの名無しさん [sage] 2018/08/23(木) 21:45:16.98 ID:6IqyOKm1(1) AAS
この手の輩は再現する最小コードを絶対に書かない
540: デフォルトの名無しさん [sage] 2020/09/09(水) 17:07:03.98 ID:SFlZHAWP(1) AAS
謙虚に質問してればレスも優しかったかもよ
549: デフォルトの名無しさん [] 2020/09/14(月) 20:42:48.98 ID:JdQogpR1(1/4) AAS
>>544544(1): デフォルトの名無しさん [] 2020/09/10(木) 19:56:10.61 ID:FWP0gZB+(1) AAS
clusterでマルチプロセスしようとしたんだけど
「EADDRINUSE(ポートが既に使われている)」
エラーがどうしても出てしまいます。
もちろん既に稼働しているnodeはなく、
fork元のapp.jsでlistenしているのと同じポート
子プロセスでまたbindしようとして失敗しているようで
子プロセスは外部からリクエストを受けるような
ものではなく、重い処理をコア分散させて並列処理したいだけです
子プロセスにポート割り当てが必要な理由がよく分かりませんが
恐らく親プロセスと子プロセス間の通信
とかに使うんでしょうか？
子プロセスのポート割り当て回避か、
親プロセスと別ポートを割り当てる方法はありますか？
の者ですが
今日これをデバッグしてました。
clusterでもwoker_threadsfでも
child_processでも
「EADDRINUSE」が発生しました
発生するタイミングは子プロセスを生成した時でも
なく
子プロセスでMySQLに対しのコネクション確立時でもなく
確立したDBコネクションからクエリを投げるコード
を実行する時に発生しますが
なぜこのタイミングなのか分かりません
ここで気になったのが
nodeでフロントユーザーに対し
80番ポートをlistenしていて
nodeがローカルのMySQLにアクセスする時
nodeのクライアントポートはフロントと
おなじ80を使うのでしょうか？
それとも別のランダムポートを取得してきて使うのでしょうか？
588: デフォルトの名無しさん [sage] 2020/11/19(木) 01:51:43.98 ID:/aqa7r+0(1) AAS
io.jsのように良い部分はNode.js側に取り込んでほしいね
最近は複雑さばかりが増しているし
729(1): デフォルトの名無しさん [sage] 2021/12/26(日) 23:27:54.98 ID:S+a9i6vw(6/6) AAS
>>727727(1): デフォルトの名無しさん [sage] 2021/12/26(日) 22:43:28.35 ID:M+F+5/6j(3/3) AAS
>>724
そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ
例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う
構文解析なんかは大して難しい話ではない
最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、
IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。
プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。
IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。
IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、
一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。
GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。
静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。
実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。
最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。
ちなみにTSが型を導入したのも、IDEを作るためではなく、
プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。
そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。
型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.031s