【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Win使いなんだけど、みんな開発環境どうしてるんです？
Winでそのまま開発？
GUIありのLinuxをバーチャルか普通にPCインストールしてそこで開発？
それともMac？ 前は仮想マシンのLinux内でやってたけど今はそのまま Node.jsなんてLinux入れるまでもないじゃん 最近のwinはlinux環境入れられるんでしょ？
もうwin環境のことは気にしなくていい？ すみません質問させてください！
postcssのビルドに7秒くらいかかるんですが、もっと早くする方法ありませんか？
使ってるモジュールはpostcss-importとpostcss-cssnextだけなのですがなんでこんなにかかるんでしょう。
browserifyの時も15秒くらいかかっててwatchify使ったら爆速になったので感動したのですが
postcssにもwatchifyみたいなのってないんでしょうか... >>274ですが、postcssを使っていると言いましたが具体的には
post-css-cliを使っています。
今、代わりにwebpackを利用したpostcss-loaderを使ったビルドを行ってみたら
物凄く早くてびっくりしました。（webpackも内部的にpostcssを使っていると思ってたのですが...）
ただjsにパッケージしたいわけではなく、cssファイルとして出力したいので
webpackは使いたくないです。
昨日、こんな記事を見つけました
http://blog.greggant.com/posts/2016/05/03/post-css-is-slow.html
やっぱりPostCSSって遅いんですかね？
なんかSassよりビルドが早いってことがメリットだと思ってたんですが... SassはRuby実装版とC言語実装版があるんだよ。
Ruby実装版は遅かった。
C言語実装版は爆速
PostCSSはJavaScript実装みたいだから
一般論としてC言語実装のほうが速いだろうね。 >>275
> （webpackも内部的にpostcssを使っていると思ってたのですが...）
どのプラグイン（loader）を使うかによる
> ただjsにパッケージしたいわけではなく、cssファイルとして出力したいので
> webpackは使いたくないです。
extract-text-webpack-pluginを使えば、cssを別ファイルに切り出せる webpackで指定したrequireをバンドルせずスルーするのってライブラリ書くときにやると思うけど
変換せずにES6 Modulesそのままで出力する時代になったら同様の手法ってどう実装するんだろ
import,exportはトップレベル限定だし >>278
だからwebpackにexternalsって機能が用意されてるだろ > ES6 Modulesそのままで出力する時代
webpackを使わないって話か？
それなら細切れのファイルのままで動くはずだろ。
これらのファイルをパフォーマンスのために結合したいっていう話であれば
結合するツールを通せばいいだけ。
それがwebpackだけどなｗ
最初からwebpackは結合ツールだろ？ npm socket.io以外の方法でsocket.ioを入れる方法はあるのでしょうか？
格安VPSを借りてnodeを入れたらnpmがメモリ不足で落ちました。。。
ちなみに128MB+swap128MBです。nodeのために借りたわけじゃないので最低プランです。
nodeを少し触ってみようと思ってみたらメモリ不足だったと。。 yarnでも使ってみたら？
npmは異常にメモリ食うツールだと思ってるんで
改良されたyarnならそこら辺も改良されてるんじゃね？ あと結局のところファイルがあれば十分だろうから、
互換性がある環境をローカルで用意してコピーしても動くだろうね。 httpリクエストのパラメーターをJSONで受け取りたいのですが簡単に型チェックを行うにはどうしたらいいでしょうか？ node.jsってコンパイル環境なんですか？
いまいちよくわからない・・・ 最近Winでも動くようにシェルじゃなくNodeのAPIでファイル操作書いてるけど
fsはディレクトリ名の変更が面倒だな native moduleでBuffer返そうとしてるんだけど何故かUint8Arrayが返る
これどうすればいい？
v8::Local<v8::Object> lr;
v8::MaybeLocal<v8::Object> buf=node::Buffer::New(isolate, datalen);
buf.ToLocal(&lr);
memcpy(node::Buffer::Data(lr), data, datalen);
args.GetReturnValue().Set(lr);//Uint8Arrayが返る(中身自体は期待通り) args.GetReturnValue().Set(buf); 自己解決 根本的な勘違いをしてた
global掴んでbuffer引っこ抜いきつつ、変換掛けたらとりあえず動いた downloadRecの処理が終わったあとに処理をしたいのですが、何かいい方法ありますか？
var client = require('cheerio-httpcli');
var URL = require('url');
var target = "http://nodejs.jp/";
downloadRec(target, 2);
function downloadRec(url, l) {
if (l <= 0) return;
console.log(url);
client.fetch(url, {}, function(err, $, res) {
$("a").each(function(i) {
var next_url = $(this).attr('href');
next_url = URL.resolve(url, next_url);
downloadRec(next_url, l - 1);
});
});
} >>295
使って色々頑張ってみたんだがどうしてもできなかったので、どうすればいいか教えてください。 Promise直接使うみたいなアホな事する時代は終わったで
時代はasync/await >>294
function downloadRec(url, l) {
if (l <= 0) return 処理終わった後に実行する関数(); >>298
それだと処理し終わった後に実行する関数が複数回実行されないか？ >>297
いやいや。段階的に移行した方がいいと知った。
先ずはPromiseを使いこなしてからasync/awaitへ
じゃないと使いこなせないし >>299
確認不足だった
$("a")のlengthを使えばできるかも すみません教えてください
node.jsでaccessのデータを扱うにはどうしたらいいでしょうか？
勉強を始めてみたもののこの部分がさっぱり分からなくて foreverで嵌まっています。
環境はCentOS6.8+node.js v4.7.2+npm 2.15.11です。
通常なら起動すると、
warn: --minUptime not set. Defaulting to: 1000ms
warn: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
info: Forever processing file: ここにパス
が出るのが正常ですが、
最終行のinfoが出ずにコマンドが帰ってこない状態になっています。
肝心のnodeは起動しているのですが、コマンドが帰ってこないので仕方なくCtrl+Cで中断するとnodeのプロセスも止まってしまいます。
forever は-g付でグローバルインストールしており、何度か削除、再インストールを繰り返しましたがだめでした。
散々ぐぐっても解決できず数日立ち往生しています。
何か気付きがある方は知恵をお貸しください。 状況の追記です。
コマンドが帰ってこないと書きましたが、状況として、
node ここにスクリプト名
を打った時と同じ状態です。
console.logの内容がそのまま出てきます。 >>304
なんでcentosなんて使ってるの？
実環境がredhatで有料サポート受けるから開発ではcentos使ってるくち？
それならわかるけど、そうでないならcentos使うメリットなんて殆どないだろ。標準リポジトリのパッケージ少なくて結局サードパーティのリポジトリから持ってくるとか、ソースからビルドとかバカじゃないの？ リポジトリ追加なんてたいした手間じゃないし
ソースからビルドも愚行でもなけりゃ別に普通だろ うちの会社はサードパーティリポジトリ認められてないな。
ソースからビルドするのはオーケーなので基本いつもビルド。 >>306
>標準リポジトリのパッケージ少なくて結局サードパーティのリポジトリから持ってくるとか、ソースからビルドとかバカじゃないの？
わろた
ほんそれ 高能力なせいかビルドでハマったこととかない
本当に申し訳ない 世界的にはとっくにubuntuとかが主流なのに日本は未だにcentosのままってとこが多いよね で、いつ目障りなio.jsとかいうゴミグループは消えるの？こいつらのやった事はnode.jsの発展と普及をいたずらに遅らせただけでしたwww
いつものコンピュータだけがお友達な根暗馬鹿の自己満足でフォークするとか辞めていただきたいね。 サーバには安全性、安定性が求められるから、
世界的に見てもエンジニアに好まれてるのはRHELクローンの方。 io.jsはとっくにnode.jsって名前に変わった >>312
現在から2年後に書き込む方法を知っているなら教えて欲しい ソースからビルド、そんなに少数かな。
俺の知ってる環境も基本はそうだった。 >>313
ガラパゴスの住人さん乙
>>318
DBサーバーなら違うって話はあり得るがここはnode.jsスレだからな
nginxと同居することも多いんだからボリュームゾーンからそう外れないだろ >>304の話もそうだけど、みんなforever大好き人間なの？
ってのも今日のTechCrunchの記事にあったKeymetricsってとこが出してるpm2ってプロセスマネージャがすんげー使いやすそうなんだけどと思ってさ。
ttp://jp.techcrunch.com/2017/02/08/20170207keymetrics-is-a-nodejs-monitoring-tool-for-your-server-infrastructure/ 普通にサービススクリプト書くかな俺は
どうせzabbix入れてるし >>319
普通にcentにnginx入れてるが
つうかどのディストリ使おうがインストール作業なんてたいしたもんじゃない
面倒なのは設定だ
ubuntuなら特別設定が楽かといったらNOだろ >>321
スクリプト書く労力も大して変わらないっってのもわかるんだけど、pm2だとプロセスのリスタートとかも簡単でさ。Node.jsにAPIをいくつもぶら下げるような環境だとこれ入れた方が楽そうだなって思って。 計算方式が複雑で専門知識も必要な超面倒なことで止まってて、npm無いかなと思ったらあったんですが、マイナーで開発も止まってるっぽいです。
installしてみたら、moduleの中にあるc++のところで何やらwarningがいろいろ吐かれてたのですが一応は動く… cは全然やったことないので何でダメなのかはぼんやり。
こんなとき。これをそのまま使うのと、改変出来るようにcも勉強するのと、専門知識と計算を自力で勉強して頑張るの、どれがベストですかね。 warning出てるから信頼性無いとかいう盲信はヤメロ >>325
レスありがとう。もうそのまま使っちゃうっ 警告の内容による
割とどうでも良い内容の場合オプションで黙らせてるオープンソースソフトウェアも多々ある
chromiumでビルドツールが吐いたファイルのコンパイルオプションを見ると
かなりの数の警告がデフォルトで無効化されてるはず 初心者ですまんだけど、functionの中で使えるモジュールとそうじゃないのあるんだけどそれってどうしてなの？
エラーも出ずにただただ動かないやつあるんだよね。関数の外だと動かせるのに。 >>328
具体的に何のモジュール？
どういう環境で動かして発生してる？ ただただその関数が呼ばれてないだけというオチに1票 呼んでないならエラー出るんじゃね？
関数の外だと動くとしたらexpressとかかな。router.getとかpostの中で走らないとかなら前にあった気もしなくない。どうしたか忘れたけどｗ Rubyを使えば？
Chefのレシピは、どこにでもある
Chef → Vagrant → VirtualBox
CentOSは8〜10年と、サポート期間が長い。
Ubuntu Serverは5年だろ Chefはオワコン
あんなものに時間を費やするとか
バカみたいだろう %w{php mysql nginx}.each do |name|
package name do
action :install
end
end
%w{php-fpm mysql nginx}.each do |name|
service name do
action :start
end
end
Chefで、複数のパッケージをまとめて、インストール・起動できる Rubyでは中間言語にコンパイルする時に、エラーが分かるから、
途中まで実行されないから、中途半端な状態にならない
シェルスクリプトではエラー処理など、複雑なプログラミングはできない
Chefでは、action :install など、共通のコードで、
ディストリによって、CentOSのyum / Ubuntuのapt-get を自動的に切り替える
設定ファイルに書き込むとか、cron での定期実行とか、
Vagrant を削除すればすべて消えるから、何回でもテストできるし、
Test Kitchen というテストツールもある
こんな全工程をとても、シェルスクリプトでは書けない Rubyは宗教だからな
>>331
もしこれなら呼ぶ順番とかnextされてないとかそういうことちゃう？ spookyjsでjsonをファイルから読み込むのってどうやるの？ >>336
> Rubyでは中間言語にコンパイルする時に、エラーが分かるから、
> 途中まで実行されないから、中途半端な状態にならない
まあ、誰に目にも間違いだと明らかにわかっていることだが、
ネタ的に面白いから言ってみて。
「他の言語だとこういう場合にこうなって、
Rubyだとそうならない」という形で例を言ってみて 面白くないし言わせなくていいよ
元々スレ違いの話だし続けても荒らしにしかならん 逃げ出すなら今のうちだぞ？ｗ
Rubyだとコンパイルされてもエラーがわからず
エラーで途中で中断されるまで実行されてしまって
中途半端な状態になる例
↓↓↓↓
f = File.new("out.txt", "w")
f.write("test")
f.close()
aaa()
File.delete("out.txt")
aaa()で途中で中断される。out.txtというファイルは消えずに残る >>340
さーせんｗ
>>336がウソだってばらしてやったので
もう来ないと思うわーｗｗ Chefの冪等性を言語の機能だと思ってんのかな
あれは苦労してそうなるように実装してるんだよ
スッキリくん おまいらがいろいろめんどくさいこと言うから事の発端の初心者の子が出てこれなくなってるじゃないかｗ ちょっと伸びててしかもなんで別言語の話になってるの？と思って追ってみただけだけど。
いつもということは常駐してんの？ひまだねえ いや
このスレに限ったことじゃなくて
２ちゃん全般だから
ひまなのは認める >>336
そろそろJenkinsおじさんに次ぐChefおじさんと呼ばれる人たちがでてくるころかな。
今始めるなら、Ansibleがおすすめだよ。 Chef（など）の冪等性の機能って本当に同じ状態にするわけじゃないからな
まず書いてないことの状態は、定まらない。例えばこういうファイルを作れや
ファイルを削除する。なら定義できるが、そこに書いたこと以外の
余計なファイルが有ったり足りなかったりしてた場合は違う状態になる。
それからパッケージとかライブラリとか、インターネット上から落としてくるようなやつは
同じになるとは限らない。バージョンを指定したら同じになるだろうが、今度は
そのバージョンが削除されたらエラーになってしまう
本当に同じ状態にするのであれば、最初に作ったものをイメージ化するしかない。
だがイメージ化したものを使って変更を入れないのならば冪等性なんかは不要になる。
これがイミュータブルインフラストラクチャーという考え方
必要なのは「最初に作るもの」を手順化したものだけ。
そこにChefが必要か？と言われれば当然必要ない。
なぜなら、Chef等が登場する以前、みんな端末から手動で構築していたろ？
端末っていうのは要するにbashだったりzshだったり。
つまりbashシェルスクリプトで全部できることでしかない。
インタラクティブな処理とファイル編集はbashシェルスクリプトでやりにくいように思うかもしれないけど
インタラクティブな処理は、シェルスクリプトでも実行する方法が用意されているものだし
ファイル編集は発想を変えて、ファイルそのものをコピーすればいい
そうすれば消して特定の状態から環境を作る処理なんざシェルスクリプトでなんの苦労もなくできる。
消さずに何度も設定を送り込んむような（クラウド的ではない）使い方をするのなら
冪等性があると便利だから使う意味があるが、それでもAnsibleで十分だし、Ansibleの方が簡単 >>336
> Chefでは、action :install など、共通のコードで、
> ディストリによって、CentOSのyum / Ubuntuのapt-get を自動的に切り替える
一見便利そうに思うかもしれないけど、汎用的なChefレシピを作ってる人（誰かいんの？）以外は
CentOSとUbuntuを変更したいなんてことはまずない。
そもそもCentOSとUbuntuではパッケージ名が違う
だから自動的に切り替えることは完全にはできない。
それからバージョン番号とかどうする？完全に一致するわけじゃない。
結局CentOSはこの名前のパッケージで、Ubuntuだとこの名前のパッケージというように
切り替えるファイルが別に必要
誰かが用意してくれてるんだろうが、マイナーなパッケージまでそれをやってくれるのか？
頑張った所でCentOSとUbuntuで違うが生まれるというのに、誰が喜ぶんだという話 https://www.ogis-ri.co.jp/otc/hiroba/technical/vagrant-chef/chap3.html
> どうやら Ubuntu と CentOS は git-daemon のパッケージ名が異なるため、
> 同じパッケージ名で両方の OS に対してパッケージをインストールできないようです。
> 以下のようにレシピ中でプラットフォームごとに適切なパッケージ名を使うように変更しましょう。
>
> package "git-daemon" do
> case node[:platform]
> when "centos"
> package_name "git-daemon"
> when "ubuntu"
> package_name "git-daemon-run"
> end
> action :install
> end
あははｗ あほくさ
本末転倒とはまさにこの事 cookbookは各社が公開している
Chef社のopscode、Railsを作っている Basecamp社、
Berkshelfを作っている Riot Games社、
Pivotal Trackerを作っている Pivotal Sprout社、
aws, engine yard
この本を参照。
Chef実践入門 - コードによるインフラ構成の自動化、2014 > cookbookは各社が公開している
そうやって誰かが用意してくれなければ
使いづらいようなものを他人（各社以外＝つまり俺ら）が
メンテ何するなんて苦行でしかない。
シェルスクリプトでみんなやれているのに
それをわざわざ別の形式で書く必要なんてないんだわ。
みんなが手動でパッケージ入れたりしているものを
単に記述しただけなんだぞ。
シェルスクリプトなら探す必要もないし、
難しさのかけらもない
2014年という終わコンになったChef soloを
使った手順しか書かれてない本も読まなくていい ansibleから漂う超光速通信感が格好いいからアンシブル好き何やってるのかは知らんけど >>352
俺がchefをやめた理由：
・アーキテクチャがころころ変わる（最大の理由）
→ なので、ちょっと前の情報がもう全然駄目になる（書籍もネットの情報も）
・リモートにインストールが必要
・他人が作ったcookbookでなにやってるのかよくわからん
・さらに、そのカスタマイズポイントを調べるのが面倒
・自分で書く場合は、結局ディストロ意識するので、CentOS用に書いた奴はUbuntuでは使えない
まあ、Ansibleにもあてはまる項目あるけどね。 >>352
俺がchefをやめた理由：
・アーキテクチャがころころ変わる（最大の理由）
→ なので、ちょっと前の情報がもう全然駄目になる（書籍もネットの情報も）
・リモートにインストールが必要
・他人が作ったcookbookでなにやってるのかよくわからん
・さらに、そのカスタマイズポイントを調べるのが面倒
・自分で書く場合は、結局ディストロ意識するので、CentOS用に書いた奴はUbuntuでは使えない
まあ、Ansibleにもあてはまる項目あるけどね。 アーキテクチャがころころ変わるのは
オンプレ連中に楽させるかよ金払えって意図がある >>357
そのAnsibleにもあてはまる項目だけど、
各アプリの設定ファイルを、わざわざAnsibleのyml形式で
書き直すっていうのがアホらしいと思う
あと、
Ansible公式でモジュールが用意されているとあるサーバーアプリがあるのだけど、
そのサーバーアプリの最新版がリリースされたら公式モジュールが動かなくなった
このように間に別の仕組みがはいって、その別の仕組はアプリごとに
用意しないといけないものというのは、公式で対応すべきじゃないと思う。
利用者が自分で書くか、アプリ自信に配布してもらうか
ちなみになAnsible Galaxy見てみたら、そのアプリに対応するモジュールが
50個以上あったわｗ 検証してられるか＝それらはゴミ >>359
> 各アプリの設定ファイルを、わざわざAnsibleのyml形式で
> 書き直すっていうのがアホらしいと思う
うん、アホらしいね
だから、設定ファイル（ふつーのテキストファイル）に変数を埋め込む機能が準備されてるんだね
ゴミに関しては、chefのcookbookの方が多いんじゃないかな
さらに同じ目的なのに多数類似品が見つかるし、動かなくなってるのもあるし ただ、
> 各アプリの設定ファイルを、わざわざAnsibleのyml形式で
> 書き直すっていうのがアホらしいと思う
は書くのは大変だけど、多大なメリットがある
それは、デプロイするパッケージのバージョンを上げるときに、付属する設定ファイルが
結構変わったり、パッケージそのものが変わっても、設定をyamlで書いとけば変更なし
（あるいはちょっとした変更）でいけたりする
iptablesからfirewalldの変更とかね
設定アイル事前準備→内容書き換え→配布だと、それに対応できない場合がある > それは、デプロイするパッケージのバージョンを上げるときに、付属する設定ファイルが
> 結構変わったり、パッケージそのものが変わっても、設定をyamlで書いとけば変更なし
> （あるいはちょっとした変更）でいけたりする
それは普通にアプリ標準の設定形式であっても同じ
もし、付属する設定ファイルが結構変わっていたりしたら
それにAnsibleが対応するまで、使えない。
実際、エラーが出て困ってる。 >>360
> 書き直すっていうのがアホらしいと思う
うん、アホらしいね
だから、設定ファイル（ふつーのテキストファイル）に変数を埋め込む機能が準備されてるんだね
そして、アホらしいから設定ファイルに変数を埋め込む方法を使えば
設定ファイルが大きく変わったとき困るよね？ >>361
> iptablesからfirewalldの変更とかね
iptablesはこっちを使いましょう
https://docs.ansible.com/ansible/iptables_module.html
firewalldはこっちを使いましょう
http://docs.ansible.com/ansible/firewalld_module.html
見ての通り使える機能が違うからオプションも違います。
iptablesを勉強した後、Ansibleのドキュメントを見て、何が何に対応するか調べましょう
そして
firewalldを勉強した後、Ansibleのドキュメントを見て、何が何に対応するか調べましょう docker派の俺、高みの見物
自社サーバー中心だとその辺楽だなあ ■ このスレッドは過去ログ倉庫に格納されています
