くたくたシェルのブログ

気ままに楽しむ燃え殻 (ash) のような人間が自分の頭の舵取りをするために書いています。つぶやくよりは考え、考え過ぎるよりは吐き出す、そんな記録を脳みその外に置きます。

Node.jsの第一歩：インストールしてみた

とあるクラウドの解説記事に出てくるサンプルアプリを作ってみるにあたり、どうやら避けて通れない要素技術らしいので、触ってみることに。Node.jsは大量のリクエストをさばくのに向いているらしく、速いらしい。

さて、どれくらい触ったらよいものだろうか。。。ひとまずお決まりのHelloまでやったのでメモを兼ねて整理してみた。

ローカルに初めてNode.js環境をつくるにあたり参考にしたサイト:

liginc.co.jp

githubからnvmリポジトリをクローンする形でnvmをインストール

$ mkdir work.nvm
$ git clone https://github.com/creationix/nvm.git ~/work.nvm
$ ls work.nvm/
$ source work.nvm/nvm.sh
$ nvm help

Node.jsのバージョン管理ツール nvm を使って Node.js ver.0.12.7 をインストール

$ nvm ls-remote

$ nvm install v0.12.7
$ node -v
$ nvm alias default v0.12.7

nvm 実行環境（大げさか？）をセットアップ

bashのfunctionやら何やらが定義されているスクリプトをログイン時に毎回ロードするようにしておく。

$ vi ~/.bash_profile
$ tail -n 3 ~/.bash_profile

if -s ~/work.nvm/nvm.sh ;
    then source ~/work.nvm/nvm.sh
fi

 

動作確認

いわゆる「サーバーサイドでJavaScriptを動かす」というもの。

$ mkdir -p ~/hello-node.js
$ cd ~/hello-node.js/
$ vi example.js
$ cat example.js

$ node example.js &
$ wget http://localhost:8124
$ cat index.html

Hello World

 ここまでくるのにかかった作業ステップが短く、起動が速い。。

ここで少し用語整理

NPMというものがNVMをインストールしたら同梱されている模様。

$ which npm
~/work.nvm/versions/node/v0.12.7/bin/npm

  • NPM (Node Package Manager) : Node.js で作られたモジュールを管理するツール
  • NVM (Node Version Manager) : Node.js 自体をバージョン管理するツール

以下のサイトに触りかけると登場するので一応あらかじめ。

次にやってみたいこと

www.atmarkit.co.jp

 ・・・一読し、一通り触ってみました。

 

qiita.com

・・・読んでみましたがよくわかりませんでした。熟読はしていません。

 

ビギナーのための Node.jsプログラミング入門

 

dotinstall.com

 

www.atmarkit.co.jp

 

バックアップをちゃんとやりたい

ディスククラッシュの悪夢を経験したこともあり、バックアップ自体はこれまでにもやっていたものの、結構いい加減なものだった。内蔵HDDが十数GBだった頃に比べ、外付けHDDの数百GBクラスが手に入るようになってからというもの、楽になった反面、いい加減さが増したように思う。要するに、ただのコピー。rsyncで使って真面目に差分コピーしていた頃の方がまだマシだったように思うが、いつの間にかやらなくなっていた。

それ以前に、データの整理自体もいい加減になってきたように思う。気になる情報やツールやデータ、その他もろもろのファイルを使うかどうかわからないにもかかわらず保存する癖があって、過去のディスクを見ると、なんでこんなものを保管したんだろうと自分の目を疑うものが少なからずある。バックアップを含めたデータ全体をさらにバックアップするというバックアップのネストすら起きており、自己嫌悪の材料が満載だ。

手に入る情報と保存できる情報の量がともに巨大化してきたことを背景に、ディスククラッシュの悪夢と保存癖とが負の連鎖を生み出しているという状況に危機感を抱き、バックアップを設計したいという動機が生まれた。

検索してみるとノウハウが沢山ある。まずヒットするのはDB関連で、情報整理の方法もいろいろある。。。ふと我に帰り、こういうトップダウン的なバックアップ手法をお勉強して実践するのも一案だけど、もっと具体的に自分が抱えている問題やケースに特化してじっくり考えるところから始めた方がよさそうだと感じた。手法や技術の問題ではないのだ。

それで今更ながら、「必要なものと必要でないものというレベルでの絞り込み」と、「積極的に捨てる（削除する）」、さらには「闇雲に調べない」ということを意識的にやり始めた。お題にある「バックアップをちゃんとやりたい」状況から「バックアップをちゃんとやっている」状況になるまで、いろいろステップはあるだろうけど、ひとまず記録として残す。

無駄に気になることが気にならなくなることも、１つの目安かもしれない。

 

追記：

身の回りのことに対する好奇心や関心、モチベーションが薄れるにつれ、そういったものが生じたときに覚えておきたいと思うようになった。情報やデータが云々というより、自分が関心を持ったものを自分に思い出させたいという構図があるようだ。

また、気になることを気になったときにすぐ調べることで、逆にもともと気になっていたことや動機や方向性を見失ってしまいやすく、このことも相まっているように思う。

Eclipse ユーザーライブラリの移行

Eclipseでユーザー・ライブラリーを登録し、プロジェクトのビルドパスに設定するということをやっています。ワークスペースを作り直すとその辺りの設定もし直す必要がありますが、どうやらエクスポート＆インポートできるようです。

「設定」→「Java」→「ビルド・パス」→「ユーザー・ライブラリー」

この設定画面で「エクスポート...」と「インポート...」ができます。エクスポートしたファイルは *.userlibraries になるようです。

参照の構造

ちなみに、登録したライブラリに対するプロジェクトからの参照は論理的・仮想的なもので、ライブラリを構成するJARの配置パスなどといった物理的な構成は別のメタファイルに定義されているようです。実際に意識することはないことですが、ファイル内をテキスト検索した感触だと、次のようになっているようです。

  • プロジェクトごとのユーザーライブラリの参照設定： {EclipseWorkspace}/.metadata/.plugins/org.eclipse.core.resources/.projects/{ProjectName}/org.eclipse.jdt.core/state.dat
  • ワークスペース単位でのユーザーライブラリの構成定義： {EclipseWorkspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs

気付き

そういえば、Eclipseワークスペースの様々な設定内容は、ファイルメニューのエクスポートを選択すると、*.epf というファイルにエクスポートできます。この記事で取り上げたユーザーライブラリーの内容は含まれないのか、機会があれば試してみたいところです。