【node.js】サーバサイドjavascript 5【Nashorn】
>>620 Node.jsでパッケージングされているプログラムだけで完結できるのに、 新しいNode.jsにする上で、 他のプログラムや仮想化に依存しなくてはいけない理由は何ですか? 仮想環境が便利だ等であれば別の話だと思うのですが。 私はC/C++、Java、Perl、JavaScript(フロント少々)使いで、 最近Node.jsに手を出し始めたのですが、 anyenvやasdfについては全く存じ上げませんでした。 それらを覚える事によって、 それらのラーニングコストを上回る恩恵を授かれるとは思いませんでした。 >>614 さんのアドバイスから>>619 まで行き着いた次第で、 シンプルに管理コストを抑えられるるのが一番だとも思っています。 好きなもん使えばいい 俺もubuntuではaptでクソ古いNode入れてからnpmでn入れてnからlatest突っ込んでるよ Ubuntu-ltsのデフォnodejsが10.xだもんなあ オレの環境では動かない、とか言われても知らねえよ。NodeJS公式もサポートしないバージョンまでカバーできる訳ないだろうが >>625 ただの翻訳(かつ雑な簡素化)記事なのにその旨の記述がない 画像も元ブログからの転載(盗用)だけどクレジット無し 大手メディアでこれって大丈夫か? 丸コピしたのとは違うと思うぞ 画像の方はアウト臭いな node.jsのconsole.logのpretty printをデフォルトでやめさせる方法ないのかな? このおせっかい機能すごくいらいらするのは俺だけかな? process.stdout.write使え console.logはブラウザに寄せようと頑張ってるんやろ puppeteerを使ってるプログラムをwebpackでバンドルすると、distにはChromiumが無いからエラーが出ちゃうわ よく分からん nodeで作ってるapiがメモリ使用量1GBくらいでかなりベビーなんですけど ここら辺のパフォーマンスチューニングについての知見がまとまってるサイトか書籍ないですかね? puppeteerのplaygroundでforループすれば任意の回数地獄に落ちられるぞ スクレイピングの勉強するのですが、下手するとF5アタックになるとかの法的リスクと回避法を重視している入門書ってありますか? 今の所やりたいことは、特定の市町村の5年分気温気象データを収集して自分用に加工 近所のコインランドリーの稼働データを集計して空いてる確率が高い時間帯を調べるの2つです 前者は膨大なデータを取得する必要があります 後者は10分から20分おきにアクセスすることになります 頭のおかしい人に以下のようなことを言われました >>基本、スクレイピングは営業妨害との戦い。 >>どの本にも、そう書いてある。 >>スクレイピングを推奨する本はない 具体的な書籍名を教えてください >>5 ch は、マルチポスト禁止! >>同じ質問を、複数のスレや外部のサイトに書いてはいけない どこでそんなルールが決まっているのでしょうか? node初心者だけどnpmが脆弱性情報吐きまくってこわい ググったらauditはクソ設計みたいな記事が出てきた 無視して良かったんだね いままで膨大な時間を無駄にしてた…(´Д`)ハァ… なんか変な場所でエラー投げられてプロセスが止まると思ったら 依存Modの一つがPromiseコンストラクタのcallback内で非同期エラー投げて止まっていた そりゃrejectしないしcatchブロックにも引っ掛からんわどうすりゃいいねん 最悪プルリク投げるかと思ってリポジトリ見たら消えてた 捨てて自分で書くわ 具体名は避けるけどProxy関連 自前のDNSBL作るのに使ってる スクレイピングに興味があるのですが1時間に1回の頻度のGETだけで訴えられる危険があるって本当ですか? 17でStrcturedCloneの実装来るのか もうv8にある似たようなAPI使わなくてよくなるのな パッケージ管理ツールのnpmで公開されている「UAParser.js」は、ユーザーエージェントの判定処理を 実行するJavaScriptライブラリであり、Facebook・Microsoft・Amazon・Googleなどの超大手企業を 含む1000以上のプロジェクトで採用されています。 そんなUAParser.jsがハッカーによってハイジャックされ、LinuxおよびWindowsデバイスを対象に暗号 資産採掘やパスワードの盗難を行うトロイの木馬が仕込まれていたことが判明しました。 GIGAZINEからのコピペだろうけどちゃんと引用元URL貼っとけよ 上にもちょっとありましたが、レンタルサーバでnode.jsを動かすのって現実的じゃないもんなんですか? いや全然 上にある「レン鯖はPHP」ってレスは恐らく既に環境を構築済みで あとは実行する.phpを配置するだけのWebスペースを想定したレス >>655 に書いたような実質Webスペースの共有レン鯖でも端末触れる一部では使えるよ 占有型ではもちろん使えるけど今なら間違いなくVPSのほうがいい 古き良きLAMP環境に拘る理由がないなら好きにしたら良い >>656 昔ながらのFTPとかでファイル置くしかできないようなサービスならまずそんなもの導入されてないだろうな gulp4でejsをを使用したい + 別のタスクと記述方法を統一したいのですが どうしてもエラーが解消できないのでどなたかご教授頂けませんか?(exportsにオブジェクトを突っ込む方法) 古い記述方法では動作しますが、新しい記述方法ではどうしても動作しません。 色々ググったのですが、どのサイト(英語サイトも含め)も古い記述方法で書かれており困っています。 公式も古い書き方に記述されています。(ejsだけ新しい書き方に対応していない?) https://www.npmjs.com/package/gulp-ejs //old gulp.task('ejs', function() { // } 新しい記述方法では、どうしても下記のエラーが解消できません。 - The following tasks did not complete - Did you forget to signal async completion? また`ps aux`で別のプロセスも走っていないことを確認しており、別のgulpタスクも全てオフにした状態で デバッグしております。 関数の引数にdoneを入れてdone()で締めたり、return除いてみたり試行錯誤していますが、数時間ハマっています。 どなたら分かる方いらっしゃたらご教授お願い致します。 //new function ejs() { return gulp .src(srcPath.ejs) .pipe(ejs()); } exports.ejs = ejs; このエラーメッセージで検索すれば? それか、意味を考えてみれば? The following tasks did not complete Did you forget to signal async completion? もっと単純な例で、動くかどうか試してみれば? >>660 状況全く分からんが、JSのパーサーはややおかしい?所があって、returnの後はぶった切られる。 よって、 return gulp.src(srcPath.ejs).pipe(ejs()); と改行を無くして試す事を勧める。 >>663 これ return と yield (と後置演算子もか?)はパーサの仕様バグだよな? 直感的じゃ無いという意味で。 >>660 いや実際660はそうしてるだろ。俺も以前嵌った事があったし、 実際セミコロン必須の言語だとどこで切ってもいいから、660の書き方はよく見るよ。 俺はお前がおかしいと思うが。 結局これもMDNで説明するのに例外扱い("no LineTerminator here" 規則)になってるし。 統一された文法ではないよね。(=もっとましな仕様にする事も出来たし、実際他言語はそう) >>666 その書き方よくみるというけど 1行で書けば見やすいのにわざわざ複数行で見にくくしている意図がわからない >>668 そりゃ、そうした方が見やすいと思う人がそうするだけだよ。 お前がそう思わなければしなければいいだけ。 ただ実際、660にある公式のコードもそうなってるだろ。 俺も個人的には横に長いコードを書くけど、一般的には縦に長いコードの方が多いと思うよ。 returnの直後に改行してないからASI関係なくないか? >>670 660の「新しい記述方法だと動かない」とされてるコードは return gulp で改行してる。 660内の公式はこれが出来ない事を知ってるから、 gulp.src(...) で改行してる。(ただしreturnはないが) >>669 それは長い行を分けて改行しているだけ 一方で>>660 の人は長い行にならないのに無意味に改行しまくり >>671 return gulp.src() ならreturnの後にセミコロンが自動挿入されるけど return gulp .src() ならgulpの後にセミコロンは自動挿入されないでしょ それよりfunction ejs(){}って名前がダメなんじゃないの? .pipe(ejs())で再帰になってる >>672 長さではなく、意味で切るんだよ。 >>673 > return gulp > .src() > ならgulpの後にセミコロンは自動挿入されないでしょ されて gulp が返されるはずだぞ。 >>674 意味で切るならgulpと.src()の間で改行を入れてるのは明らかにおかしい 無意味な改行だ >>673 すまん、674は間違い。 試してみたところ、確かに挿入されないようだ。 >>675 相手するだけ無駄っぽいが、そういうのは物によるんだよ。 そうした方が見やすいと思う奴がそうするだけ。 return ウンコ製造器675号 .src(ケーキ) .pipe(胃) .pipe(小腸); .pipe(大腸); なら、675によってケーキがウンコに変わるのが見やすくなると思う奴もいるだろ。 (詳しくないが)gulpの場合は基本はフィルタで型が変わらないし、出発点はソースファイルに決まってるから、 return gulp.src(ソース) .pipe(フィルタ1) .pipe(フィルタ2) のケースが多いとは思うけど。 ついでに言っておくと、お前JSによくいる、やたら文法に拘る奴なら、止めた方がいい。 それだと全く進歩しないので。 上記の通り、まあどちらもいるわな、程度で進めていかないと、上達しない。 どちらが正しいとか、そういう問題ではない。 どうにもJS初心者は「改行を極める」「セミコロンを極める」とかになりがちのようで、よろしくない。 んじゃ俺は括弧の後に半角スペースを入れるのを極めるわ。 .NET Standard が世界の中心と考えてる人でしょ 別スレで見た 610です。 仕事でレス遅くなりました。 >>673 ありがとうございます! このコメントからピンときて修正したら無事に動作しました。 超初歩的なミスでした、、 こちらの書き方は関数の中にejs(gulp-ejsオブジェクト)を書いても動作しましたが gulp.task('ejs', function() { } こちらでは関数に同じ関数入れたらまだタスク終わってないよと、動作しませんよね。(気づけば当たり前なのですが、、) function ejs() { } お騒がせしました。コメント頂いた方もありがとうございました! 漏れは、Ruby でも、パーサーの誤解釈を避けるため、 . を行末に置く a. b( ). c( ) >>687 JavaScriptで駄目なのはreturnのみの行の時だけだよ return a .b() は駄目だけどこう書く人はいないから問題は起きることはない return a .b() なら大丈夫 そういうのはコーディング時にいちいち気にするよりlinterでチェックだな。 >>688 それを知ってないと嵌るだけの無駄仕様だよ。 セミコロンなしの筆頭だったAirbnbも諦めたようだし。 > ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues. > https://github.com/airbnb/javascript#semicolons 他にセミコロンなしの有名ルール勢ってあったっけ? return 'qwerty' +'asdfgh'; とは書きたくなるだろ。書きたいように書けないのはよろしくないよ。今風ではないね。 セミコロン書くルールならASIなんて無い方がマシだし。 書き方にこだわりがあるならそうではない書き方と比べて◯◯の利点があると言わないと他人の理解は得られにくい。 好みだけの問題ならスクリプトの仕様に従うしかない。 >>681 俺向けではないと思うが、 return 'qwerty' +'asdfgh'; の利点は見れば分かるとおり、インデントを揃えられる事だよ。 タグの方が分かりやすいかもしれんが一々引っかかると面倒なので止めただけ。 return '<div>' +'<span>'+ +'</span>'+ +'</div>'; だと最初のdivのインデントがずれるだろ。 まあ言うほどではないし、実際俺はこの書き方をしているが、出来れば return の後に改行したいね。 お前ら何も考えずにPrettier使え それが今のデファクトだ >>696 ならAirbnbというのは俺の勘違いだな。 俺がJSを始めた2013-14頃、有名なコーディングルールが4つほどあって、Airbnbが一番トンデモだった(が、人気は一番という話だった) その中にはセミコロンを打つな、というルールもあった。誰か思えてないかね? なお俺はgoogleのルールが一番マシっぽいのでそれを参考にした。(こちらはセミコロンあり) >>697 どこだか覚えてないけど、確かにどっかでセミコロン打たないで、短文を1行に書くときだけセミコロン使うてなの見たか聞いたりした記憶ある。 一応自分でも再確認しているところだが、 > Always use semicolons. (google) > Use them. Never rely on ASI. (jQuery) > あなたからセミコロンを奪おうとする反抗的な軍隊があるようです。でも確かに私達の伝統的な文化はまだ元気に生き残っています。だからコミュニティに従って、セミコロンを使いなさい!(Node) > https://qiita.com/takeharu/items/dee0972e5f39bfd4d7c8 npmのもかなりトンデモだった記憶があり、改めて確認すると、打つな派だ。 > ;(x || y).performAction() > ;[a, b, c].forEach(performAction) > for (var i = 0; i < 10; i ++) { > switch (state) { > case 'begin': start(); continue > case 'end': finish(); break > default: throw new Error('unknown state') > } > end() > } > https://www.w3resource.com/npm/npm-coding-style.php となると俺の勘違いはnpmという事になるが、npm==Nodeじゃねえのか?という疑問は発生する。Nodeはnpmからのフォークか? 多分俺が当時見たのは Airbnb, npm, jQuery, googleだと思う。 NodeはRyan Dahlが始めてセミコロンあり npmはIsaac Z. Schlueterが始めてセミコロンなし IsaacはNodeの2代目リーダーだけどNodeではセミコロンを書いてた セミコロンレスの強硬派として有名なのはStandard カスタマイズも許さない https://github.com/standard/standard >>701 初コミット2015年なのにstandardと主張して他と違うルールとか、頭おかしいな。 とはいえ議論する時間が一番無駄というのは同意だが。 多分セミコロン無し言語出身者用のルールが一つは必要で、 それに向けてのstandard命名なのだろうけど、なんだかね。 文字列を「+」で繋げるのもうやめようよ。見にくいよ。 「´」(バッククォート)で括ればいいじゃん javascriptならセミコロン無い方がいいかなぁ async/awaitってawaitしかしないから無駄じゃね? Promise, async/await で無駄なのは、デタラメ解説の数々、ほぼ全滅だろ、酷い惨状だねー。 それを言ったらWeb系言語は全部デタラメ解説で駄目だろ 初心者が情報公開の練習として解説を書くからそうなる それはしゃーない、正確さにこだわりすぎて萎縮する方がデメリットが大きい 読む方が気を付けて取捨選択するしかない c++とかjavaとか含めて進化してる技術の古い解説はことごとくゴミ化してるし一緒だわな classは非推奨にして欲しい。 中途半端で使いにくい。 >>709 同意だが、C#はかなりマシ 一般的に上級者は初心者向けの説明なんて書きたくないものだが、 プログラミング自体について語りたい連中も多少はおり、そいつらを上手く取り込んでる >>712 上っ面だけのクラスベース。 内容はプロトタイプのまま。 上っ面といってもそこで整合とれていて内部の問題が表に現れないなら別に問題ないと思うが。 まぁ、中途半端というなら何かそういう部分が見えているということなんだろうが。 >>714 オブジェクト指向的センスが無いと言う事だね 今の時代、両方出来ないとプロだと厳しいと思うがね プロトタイプの方が表現出来る空間が広くて、実際にただの糖衣構文でクラスを実装出来てるだけだろ クラスで閉じて使ってる限りプロトタイプの側面は見えないはずだが 混ぜて使うのってありだっけ?(class宣言した物にgetPrototypeOfとか) class構文の時にどうプロトタイプが配置されるか仕様で確定してないと駄目だと思うが、これってしてるのか? GoやRustなんかの新しい言語がクラスベースのオブジェクト指向を採用しないご時世 時代遅れとなったC++やJava風のクラス構文を導入する必要はなかったわな TC39的にはES4で入れ損なったから悲願だったんだろうけど プロトタイプベースのオブジェクト指向ってIDEや静的型付けと相性悪いのでは read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる