【node.js】サーバサイドjavascript 5【Nashorn】
>>720
仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ
初心者専用のオモチャが欲しければScratchで満足しとけ >>721
既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは
それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない >>718
してない。
だから細かい設定が解りづらい。 >>722
糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。
IDEを優先するなら何もしないのが最善。
（もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので）
>>723
仕様で確定してないのなら、混ぜて使う事は禁止だし、
クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。
何を問題視してる？ >>723
ECMAScriptの仕様書も読んだことない低脳が堂々と嘘を書くなよ
ES2020の14.6.12 >>725
自己レス「ES2020の14.6.13」の書き間違い >>724
そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ
例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う
構文解析なんかは大して難しい話ではない 実際にTypeScriptはinterface導入してるし何も問題ないだろ >>727
最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、
IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。
プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。
IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。
IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、
一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。
GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。
静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。
実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。
最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。
ちなみにTSが型を導入したのも、IDEを作るためではなく、
プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。
そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。
型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。 >>729
言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても
静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが
実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが >>720 ではIDEや静的解析といっている >>730
> 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。
それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。
IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。
よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。
上下関係で言えばプログラミング言語の『仕様』が完全に上であって、
IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
> 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。
でも確かにこれが一番生産性が高いんだよ。
当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。
だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。
最大のメリットは構文解釈を自前で実装する必要がない事。
構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、
IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。
これで言語側の仕様変更に自動的に追従するようになる。
IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。
> 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー（=静的エラー）は全て検出出来る。
しかも自前の実装もなしだから、最も生産性が高い。
自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、
それはIDEではなくリンターと呼ぶべきだが、
それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、
IDEはそのエラーを表示する事に徹するのが最も生産性が高い。
IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。 >>731
> IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
なぜそうあるべきなのですか？
近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です
プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して
宣言的記法であればスコープ内のクラス宣言を見ればだいたい事足りるので実装難易度は大幅に異なるかと 今時プロトタイプベースがぁ、って言ってるのが時代遅れじゃねーの。
クラスベースじゃないからってRustやGoを出してるがそれらはプロトタイプベースですらないわけで。 >>733
>>719はクラスベースを時代遅れと書いたんだが
ぶっちゃけオブジェクト指向が過去のものになってきてるのみんな分かってるだろ >>732
> 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
「多い」というのならまず具体的に名前を複数挙げてみろ。
出来なければそれは君の妄想だね。
> また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
違うぞ。それは今の話に関係ない。（どっちでもいい）
> 意図してたのはintellisenseのような意味解析が必要な機能です
だから何？これも君の考えが間違ってる。
flycheckのやり方でも原理的にインテリセンスは出来るんだよ。
インテリセンスで出なかったキーワードだとコンパイルエラーになるのなら、
仮にコンパイラが無限に速ければ、ソース内の全キーワードで試せば、コンパイルが通るキーワードのリストは得られる。
実際こんな事をしてる物はないと思うが、構文解釈で100%絞る必要なんて無くて、
候補が数個程度なら全部試してエラーが出なかった物を出す程度でも十分実用的なんだよ。
今時emacsでもインテリセンスするようだから、そんなにIDEが気になるのなら、彼等のアプローチを確認してみるといいよ。
全言語向けに自前でやってる事なんてないと思うよ。
プロトタイプを自分で追うのが技術的に無理なら、evalさせてgetPrototypeOfやinstanceofを使って追えばいいだけ。
自前の構文解釈器でソースからデータツリー構築をする気だからおかしくなる。
それはevalすれば実行エンジン内に構築されるものでしかないのだから、完全に再開発だろ。
eval出来る環境があり、それが一番近道なら、やればいいだけ。
君は多分「生産性」を勘違いしてる。
むしろ再開発しすぎてるし。
現状どうなってるのか知らないのだけど、メジャーなIDE、
例えばVSCodeとかだとクラスベースならインテリセンス出来るが、プロトタイプベースだと無理とかなのか？
誰か使ってたら教えてくれ。 ×クラスベース
○クラス構文
クラス構文で書いてもプロトタイプベースなのは変わらん >>734
確かにクラスベースがってよりオブジェクト指向が時代遅れって感じだね。
JS自体は関数プログラミングもいける。 言語仕様も分かってないIDEも使ってない部外者の素人同士が長文レスバって地獄だな >>735
> 「多い」というのならまず具体的に名前を複数挙げてみろ。
例えばgolangやrustはコアチームがツール開発に積極的ですね
ツールのチームがコア言語に対してフィードバックしていたりする
> eval出来る環境があり、それが一番近道なら、やればいいだけ。
"構文解釈機" という言葉を使っているから静的解析を意図してるのかと思ったけど動的解析も含んで言っていたのね
それで実用に耐えうる速度と精度が実現できるならそういうアプローチもありかもね
それから別にIDEが自前で静的解析器を開発すべきなんて主張はしてないから藁人形論法はやめてくれ
>>737
オブジェクト指向というか継承が忌避されてる気はする オブジェクト指向ならではの筆頭が継承だから継承が忌避されてる＝オブジェクト指向が忌避されてるってことよ
OOPLが提供していた継承以外の特性の多く(カプセル化など)は抽象データ型から来ていてそれは時代遅れになってないし忌避されてもいない クラスの定義だけど、
classとfunctionを混在した書き方でも問題ないの？ >>741
混在した書き方っての次第だが
class A {}
A.prototype.x = () => {}
a = new A()
a.x()
こんなのは当たり前に動くぞ
つかまずは自分で試せよw
JSなんかブラウザあれば動かせるんだからさー >>739
> 例えばgolangやrustはコアチームがツール開発に積極的ですね
それで、それらの言語のどの仕様がIDEの都合で採用されたものなの？
> 藁人形論法はやめてくれ
なら最初から分かるように主張しろ。
何が言いたいか分からないからエスパーして複数挙げてみただけ。
馬鹿は無視してきっちり自分の意見を書ききれ。
3行しか読めない馬鹿はプログラミングなんてどうやっても出来ない。
MDNその他のリファレンス見りゃ分かるが、そんな世界じゃない。
5ch程度の文にすら手こずるようではどだい無理だよ。
解釈が動的か静的かは意味無い。
出来るだけ早い段階でエラーを検出して修正したいだけであって、それが出来れば何だっていいんだよ。
その手段の一つが静的解析でソース作成時にエラーを表示する事であって。
でも、エラー表示だけなら、コンパイラやevalにぶち込めば出来るし、それをやってるっぽいのがflycheck。
構文解釈器を自前で作るとしても、クラス構文でもプロトタイプ構文でも、大して難易度は変わらない気もするが。
実際に問題になるのは、構文解釈そのもの、具体的にはJS的な様々な書き方でも問題なく動くパーサの構成だろ。
構文解釈後の親class/プロトタイプ追跡なんて辿ればいいだけだからアホでも出来る。
それで今時のIDEで実際どうなのか聞いたんだよ。
もしプロトタイプ構文ではインテリセンスが動かないのなら、何か理由はあるのだろうけど。
継承が忌避されてるのは、JAVAでは関数ポインタが使えず、同様の事をするためには継承をこねくり回すしかなくて、
それの残骸がデザインパターンなのだが、
結果、継承すべきでない局面での継承で酷い事になってるからだよ。
でも、継承すべき場所では継承した方がよくて、全部捨ててるGoはいちいち全部書かないといけないのが糞。
あれは1周目はまだしも、2周目以降でそのコピペされたソースにメンテコストがかかるから、先すぼみになると予想してる。
Rustはやってないから知らん。 何言ってるか分からない相手にエスパーして反論って藁人形そのもので完全に異常者 いい加減スレチだから他所でやってもらえんかね
このスレ伸ばすにしてもnodeにScheduling APIが入ったとか普通にネタあるだろ 最近アツいサーバサイドJSはnodeよりもdenoよりもCloudflare Workers denoは苦戦してるみたいだねー
それでexpressなどnode用のライブラリが動くように互換性を高める方針になった
でもそれならnode使い続ければいいやってなりそう puppeteerを使って投票サイトの投票を自動化したいのだけど、
実行してもエラーを起こさず無反応なんだよね
Headless Recorerを使ってるからHTML部分の間違いはないと思うのだけど、
UserAgent以外で何か対策ないっすかね いくらでも試すことはあるけど悪事の片棒を担ぎそうで怖いな
一般論として言えるのはpuppeteerでも普通にWebページのコンテキストからDOM APIを叩ける んじゃ、逆にWEBサイトを作る側はどんな対策をしているのでしょうか？ >>752
使ってるところは諦めてるんだけど、使ってないところはどうやってるのかな〜と思って
UserAgentをガラケーにしてみたり、プレステにしても無反応なんだよね 手動で操作した時のリクエストヘッダーの中身を解析して
間違いなく妥当なリクエストが投げられてるのが大前提
あとは“how to detect headless browser”でググるといいよ npmがぶっ壊れたらどうすればいいですかapt でuninstall installしても治りません スレ立てるまでもない質問はここで 158匹目
https://mevius.5ch.net/test/read.cgi/tech/1635193843/538
ここに、YouTube で有名な、雑食系エンジニア・KENTA のサロンの、
Ruby on Rails 初心者用コースの内容を書いておいた
基本的に、Rails以外のフレームワークは、シェアが少ないのでおすすめしない。
学習環境も揃わないので、無理
Railsでは、Railsチュートリアル・Railsガイド・
黒田努の3冊の本・パーフェクト Ruby on Rails・Ruby on Rails 6 エンジニア養成読本とか、
Rubyでは、改訂2版 パーフェクトRuby・改訂2版 Ruby逆引きハンドブックなどの教科書が揃っている
これほど、良い教科書が揃っているフレームワークはない！
Laravel のシェアは少しあるけど、KENTAがPHP は一生やる必要がないと言ったので、
PHP自体がオワコンになってしまったw
日本のウェブ開発の将来は、ほぼKENTAが決めている。
Scala を滅ぼしたのも、KENTA for await (const chunk of stream(foo)) {
response.write(chunk);
}
response.end();
↑みたいな感じでレスポンスに直接書いてってるやつって、一旦に変数に入れることって可能？
const chunks;
for await (const chunk of stream(foo)) {
// chunksにchunkを書き込んでいく
}
response.write(chunks);
res.end();
↑こんな感じに書きたくてさ
レスポンスのサイズを減らしたくてzlibのコード見たらレスポンスを直接圧縮するんじゃなくて、オブジェクトを圧縮してそんでレスポンスにパイプって感じに見えたもんで
ただ書き方がよく分からんくてね そんな感じのコードでやれると思うけど
ただ局所的な負荷を避けるStreamの利点が消えちゃうぞ > レスポンスにパイプ
stream.pipeline()関数を使えってこった >>757
chunksに貯め込んでからzlib.gunzip()やzlib.inflate()を呼んでいたらメモリの無駄遣い
そこでzlib.createGunzip()やzlib.createInflate()で変換用streamを作って使う
それも昔はinput_stream.pipe(transform_stream).pipe(ourput_stream)と多段に繋げていたが
しかし速度差がある時のバッファリング問題もあるため一気に協調させることになり
今はpipeline(input_stream, transform_stream, ourput_stream, cb) と好きなだけ並べて書く 758 759 760
ありがとう
pipelineってやつ使うとよいみたいやね
調べてみますわ なんでchildprocessのイベントにはSIGINTが実装されてないんだろ
それでいて親から伝搬はするからdetached入れて切り離さないと落ちちまう
親同様にリスナー付けてexitを止められるようにするべきだと思うんだが 相対パスでローカルモジュールをnpm iするとdependencieではfile:から始まる相対パスになるけど
実際これは完全に無視されて同時に作成されるnode_modules以下のsymlinkが読み込まれるんだな
なんでこんな実装になってんだ いや更新時の参照用ならこれでいいのか
nodeのrequire/importとnpmのinstall/updateを混同してたわ nodejs単体というよりOODBの管理ととトランザクションいじれるようになるのが一番じゃね？ >>765
可能と言えば可能だけど無理と言えば無理
結局何作って金稼ぐかに帰ってくる
PHPerがCRUDをLaravelで作って納品してるような事はNode.jsでも出来るけど
人口多いPHPでやれば良くないっすか？で詰む
改めてNode.jsを使う意味に戻ってくる nodeはhttpサーバ目指してんのか
クロスプラットフォームのコマンドツール群目指してんのか
立ち位置が分かりにくくなってきてるなぁ。 >>769
その辺はわりと初期から迷走してるでしょ
フロントエンド用ライブラリ郡も全てnpmで管理してるし 立ち位置としては単なるJSのランタイムだから別に迷走はしてない
あれもこれもできている現状は目標が達成できている状態だな >>770
そもそもフロントエンドの実行環境はnodeじゃないしな。
そこで動くライブラリもnpmにしたのはライブラリ開発者側の意思だろ。 npm@9にしたらupdate時にinstall済みのローカルモジュールがsymlinkから実ファイルコピーに書き換えられた
--install-linksの挙動変更だけじゃなかったのか substackがGithubリポジトリごと全部消してるけど何かあったのか
npmは基本消せないから今のところは支障ないけど スマホ持ってないのに2段階認証押し付けられて嫌気がしたからとか見かけたな 思ったよりしょうもなかったがバイク事故とかじゃなくてよかったわ TSのバックエンドでファイル処理つったらstreamでいいのかな
BufferとかBlobは要らん子？pipeってのもあるらしくて混乱中 最初はfs.writeFileとfs.readFileを使え
streamは小刻みにデータを処理する方法でpipeはその際の繋ぎ役
BufferやBlobはデータをメモリ上で扱う際の形式の一つ
TS以前にJSの基礎が怪しいから入門サイトなぞったほうがいいぞ >>780
どうも
BufferとBlobは役割同じに思えるけどなんで分けてるん？ BufferはNode固有のAPI
Blobは後から出てきたWeb (ブラウザ) のAPI
そしてTypedArrayBufferはECMAScriptのAPI
ストリームとかURLとか他にも重複してるのが多数ある >>782
どうも
JSごちゃごちゃしてて難しいっすね
でも大体わかったわ 勢いでは完全に負けてるが一応TypeORMもあるんじゃね util.aborted()が生えたけど用途がわからん nodejsでDBマネージャーとかログマネージャーとか、可能な限り同一インスタンスを維持したいインスタンスって一般的にどうしてますでしょうか。
class DbManager{
private constructor(){}
static instance = new DbManager();
}
staticクラスを使うなら上記の書き方でしょうが、一般的にstaticクラスは良くないとされています。
他の硬い言語ならDIを使うのですが、nodejsというか、javascriptだとDIライブラリはあまり使われていないように見える。
毎回クラスを作る時に引数で渡しまくるのも面倒ですし、なにか良い手順はありますでしょうか 常に引数で外部注入して生成するけど
引数にundefinedが来たら自動的にデフォルト注入を使って生成かな >>788
ありがとうございます。
そうなると大半がデフォルトなんだから、もう毎回書かなくていいや〜 ってなってしまいそう…
とにかく、それでも引数でちゃんと渡す or デフォルトで自動生成する が常套手段みたいですね。 ファイル(モジュール)のトップレベルで
export const instance = new Xxx();
で十分
Javaなんかと違ってこれでもモックできるから大げさなDIなんかJS/TSにはいらんやろ >>787
> 同一インスタンスを維持したい
シングルトンの話だな Prismaが快適すぎて最近はこれ使いたいがためにnode使ってるまであるわ
たまにEloquentとか使うとやりたいことができなさすぎて発狂しそうになる 
