Node.jsプラットフォームでのWeb開発に興味があります。私のホストOSはWindows7です。開発環境をセットアップするための好ましい方法は何でしょうか。ホスト上で直接実行しますか、それともLinuxベースの仮想マシンで実行しますか?これら2つの方法の長所と短所は何ですか?
VMを使用している場合でも、WindowsでテキストエディターとWebブラウザーを実行できますか(パフォーマンス上の理由から)?
Node.jsプラットフォームでのWeb開発に興味があります。私のホストOSはWindows7です。開発環境をセットアップするための好ましい方法は何でしょうか。ホスト上で直接実行しますか、それともLinuxベースの仮想マシンで実行しますか?これら2つの方法の長所と短所は何ですか?
VMを使用している場合でも、WindowsでテキストエディターとWebブラウザーを実行できますか(パフォーマンス上の理由から)?
ええ、経験から、使用しますLinuxドッカー。
編集Docker を使用します。依存関係を焼き込み、実行時にプロジェクトをマウントし、特定のバージョンの LTS ノードのみに固定します。実行不可能なプロジェクトに 2 GB の Docker イメージを使用すると、新しいパッケージへのアップグレードを余儀なくされて数日が失われます。- 2018/04/10
しかし、Linux ベースの環境での開発に過去 8 年間を費やし、Windows ドット ネット環境で nodejs を使用してソフトウェアの開発に過去 6 か月を費やしてきた人から、衝撃的であるかどうかにかかわらず、私の発見は次のとおりです...
Debian に相当する Windowsbuild-essentials
は、実際には、インターネット上に散在する gui のみのインストーラーの不規則に広がった不規則な名前のコレクションであり、すべて特定のインストール シーケンスを必要とします。これは、sudo apt-get install build-essentials
非常に時間がかかり、隠れた落とし穴がたくさんあります。
Windows で開発すると、大文字と小文字が混在するパス名の悪い習慣が許されます。ただし、チームが従う/強制する厳格なポリシーを持っていない限り、後で問題が発生する可能性があります。
Windows はパスで 256 文字を超える文字をサポートしていますが、重要なツールはサポートしていません。左のステージに入る: rimraf と robocopy... うーん。
Windowsターミナルは最悪です...デフォルトのシェル:cmd.exeもそうです...
Powershellは構文が冗長すぎて私の好みではありません... Cmderをインストールすると、これが多少緩和されますが、Cmderがcmd.exeとやり取りする唯一の方法は、基本的にキーストロークをcmd.exeを実行している非表示のWindowsターミナルにコピーすることです。(笑)。Cmder は、よりモジュール化されたシェル (zsh、bash など) でより適切に機能します。. 更新:私は現在、pshazzとscoopでpowershellを使用していますが、これは実際に快適に使用できます。
シェルとターミナルの状況をさらに改善しても、windows 用の nodejs は、環境変数が $UNIX $STYLE ではなく %OF% %THE% %WINDOWS% %VARIETY% であると想定します。したがって、基本的には、主に cmd.exe から bower と npm を使用することになります。cross-env
コマンダーまたはヤーグを組み合わせて組み込んだので、この問題はもう発生していないようです。
Windows用のpythonもインストールする必要がありますが、chocoが存在し、そこに戻ってくるので問題ありません。更新: boxstarter を見てください。レシピを使用して新しいマシンのセットアップを自動化するのに役立ちます (または、実際に ansible または salt を使用するように卒業することもできます)。
経験豊富な python、Ruby 開発者は、古いプロジェクトを再検討する必要がある場合に備えて、古いプロジェクトのエンジンのバージョンをサイロ化する必要があると言うでしょう (新しいバージョンへのアップグレードは、ほとんどの場合、適切でも実用的でもありません。読んでください: うさぎの穴)。 rvm や virtualenv のようなものが欲しい...
nvm (UNIX システム linux および macosx でのみ動作) は、bash スクリプトのコレクションであるためです。Tarrasch/zsh-autoenv
Zgen とプラグインとともに、ZSH をシェルとして使用することをお勧めします。
nodist
Windows で使用する... bar よりもはるかに優れた選択です。nodist が設計によりこれを処理するため、ある種の autoenv について心配する必要はありません。choco install cmder nodejs python2
choco install python2
http://scoop.sh
、それを使用して pshazz をインストールします。tldr; nvm を使用します。下記以外の理由で。
~/.local/share/npm
)。幸いなことに、これは nodejs の Windows インストールが正しく行われたことを発見したものです (おそらく意図的ではありません)。node
ため#!/usr/bin/env node
、デフォルトでは nodejs は実行されません。env
幸いなことに、debian システムには、バイナリが発行するものを制御するためのきちんとした管理ツールがありますupdate-alternatives
。ここでシンボリックリンクを使用するという提案は無視してください。これは、後で微妙な方法で問題を引き起こすだけです。$ sudo apt-get install git-core git-flow build-essentials python-dev python- pip
$ curl https://raw.githubusercontent.com/creationix/nvm/v0.20.0/install.sh | bash
$ npm config set prefix ~/.local/share/npm
$ nvm install stable
$ nvm alias default stable
参照:
構成ファイルを使用するだけのシステムがあり、パスの違い ( "c:\blarg"
vs "~user/blarg"
) などの問題をすべて処理し、おまけとして、デバッグ環境と本番環境の違いを制御できます。
Node.js はクロス プラットフォームであるため、開発者はあらゆる種類のコンピューターで作業していますが、まったく問題ありません。
これは、ファイル ストレージ プロジェクトで使用する構成ファイルの例です。
/**
* All of these are mandatory except for log_level (which defaults to "info", 1)
* and log_echo_to_console (which defaults to false)
*/
exports.config = {
log_level: 0,
log_file: "/path/to/send.log",
request_log_file: "/path/to/send_requests.log",
log_echo_to_console: true,
port_number: 8088,
no_notification_emails: true,
image_url_base: "http://s3.amazonaws.com/", // MAKE SURE THIS ENDS IN "/"
tmp_file_folder:"/tmp/",
s3_info: {
key: 'xxxxxx',
secret: 'yyyyy',
file_bucket: 'sendtransfer/',
},
backend_info: {
db_info: {
server: "localhost",
user: "db_user",
password: "secret",
database: "SendRemote",
pooled_connections: 125,
idle_timeout_millis: 30000
},
memcache_info: {
host: "127.0.0.1",
port: "31111",
pooled_connections: 200,
timeout: 20000
}
},
debug_server: true
};
Windows マシンの場合は、パスを変更するだけです。大丈夫だよー!
次に、コードで次のように入力します。
var local = require('local.config.js');
fs.writeFile(local.config.log_file);
// etc
多文化主義を受け入れる!!!
私もWindows 7を使用しており、Linux(debian)ゲストでVirtualboxを使用しています。コマンドラインでいくつかのことを実行してWindowsで周りをクリックする方が速いので、それをお勧めします。
もう 1 つの優れた機能は、VM を USB スティックに置くと、それを持ち運ぶことができ、Virtualbox ホストがインストールされている場所ならどこでも使用できるため、開発環境全体を持ち運ぶことができることです。
お気に入りのテキスト エディターやブラウザーを Windows で使用することはまったく問題ありません。samba をインストールして、ホーム ディレクトリを Windows にマウントするだけです。VM は LAN 内の単なる別のマシンであるため、ブラウザーについても同じことが言えます。ブラウザーを localhost に向けるのではなく、VM の Ip に向ければ問題ありません。
ここでの明らかな欠点は、Linux の経験がない場合でも、Windows に慣れるまでに時間がかかるため、おそらく Windows に固執する必要があるということです。
私の2セントだけかもしれません:
3 番目のオプションをお勧めします。Windows/ubuntu のセットアップを二重にインストールし (できれば、最も GUI に適したubuntu dist をインストールします)、この方法でこのオプションを調査することで、Linux/Unix や iOS にも慣れることができます。 Windows をよりよく理解し、より優れたプログラマーになるようにします。仮想ボックスが遅すぎる場合がありますが、Linux はリソースに関して非常に効率的です。
仮想マシンをインストールできる場合は、Linux ディストリビューションをインストールし て、Web の多くが構築されている OS の言語/システムに慣れることもできます。
git bashを使用してWindowsでnode.jsをコーディングするのは本当に楽しいです:http: //blog.nodester.com/post/19902515151/tips-for-windows-users
VirtualBoxを実行するよりも速く、簡単に思えます。実稼働環境に移行する前のテストには、まだVirtualBoxを使用しています。