パンジェンシーの「汗だく開発日誌」

システム開発の備忘録です。

【Ubuntu】MongoDB最新版をインストール

Ubuntu MongoDB

どうも！
パンジェンシーです！

f:id:x-fieldatts:20150508114016p:plain

今回は、MongoDBの最新版をインストールする方法の備忘録です。 ====

環境

  • Ubuntu 14.04 LTS 64bit
  • MongoDB 3.0.7 ←をインストール
 

方法

リポジトリを登録します。

$ sudo apt-add-repository "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.0 multiverse"


リストを更新します。

$ sudo apt-get update


MongoDBをインストールします。

$ sudo apt-get install -y mongodb-org


MongoDBのサービスを起動します。

$ sudo service mongod start


Mongoシェルを起動し、動作確認をします。

$ mongo
> version()
3.0.7

まとめ

最初からaptに入っているリポジトリからでは、最新版をインストールできなかったので、ちょっと面倒ですが、リポジトリを手動で登録する必要がありました。


今回も、世界の誰かのお役に立てれば幸いです。


ではまた。

【Ubuntu】【Node.js】サーバーアプリをデバッグできる「node-inspector」

Node.js Ubuntu

どうも、パンジェンシーです。

f:id:x-fieldatts:20150502134035p:plain

node.jsでアプリを作るのは楽しいですね。クライアント側のデバッグは、Google chromeのデベロッパーツールがあれば、だいたい何とかなりますが、サーバー側のコードは、なかなかデバッグが難しいですね。

 

そこで今回は、サーバー側のコードも、クライアントと同じような感じでデバッグできる、nodeのモジュール「node-inspector」のご紹介です。 ====

環境

  • Ubuntu 14.04 LTS
  • node.js v0.10.37
  • node-inspector v0.12.4
 

使い方

使い方はとても簡単。まず、node-inspectorをインストールします。このモジュールは、アプリのパッケージ毎なく、グローバルにインストールするというところだけ注意しましょう。

$ npm install -g node-inspector


次に、デバッガーの起動方法です。以前は、ターミナルを開き、「node-inspector」を実行して、「http://0.0.0.0:8080/debug?port=5858」にアクセス！という方法でやっていたのですが、何故か動かない！


GitHubのページを確認したのですが、やり方が変わっているようです。
GitHub - node-inspector/node-inspector: Node.js debugger based on Blink Developer Tools
上のページによると、

$ node-debug app.js

という風に、node-debugコマンドでアプリを起動すれば、デフォルトのブラウザで、デバッガーが自動で立ち上がります。
でも、ChromeとOperaしか対応してないので、Firefoxなど、他のブラウザをデフォルトにしている人は、デバッガーのページをChromeかOperaで開きなおしてくださいね。

だそうです。いつの間にそんな変更が…！ちなみに、

 

pangency.hatenablog.com


でも紹介した、express-generatorを使ってひな形を作成している人は、npm startでアプリを実行しているかと思います。


この場合は、「package.json」にある、

"scripts": {
	"start": "node ./bin/www"
}

というところを、

"scripts": {
	"start": "node-debug ./bin/www"
}

とすればOKです。


ちなみに、デバッガーが起動した直後は、アプリの最初の行でプログラムがとまった状態になるようです。そこから、ブレークポイントを設定するなり、ステップ実行するなりして、デバッグしていきましょう。アプリのプログラムがひと通り走って、リクエスト待ちの状態にならないと、ブラウザからページにアクセスしても応答がないので注意してください。


ルーター設定周りのコードにブレークをはると、サーバーとクライアントの間のやりとりが、どういう順番で行われているかよくわかるので、何となくサンプルコードを動かしてみたけど、何のことやらわからん！という人は、一度見ておくことをオススメします！

まとめ

「node-inspector」を実行してもうんともすんともいわないので、ちゃんとインストールできてないのか、小一時間奮闘していましたが、まさか、使い方が変わっていたとは…。


今回も、世界の誰かのお役に立てれば幸いです。ではまた！


もしよければ、漫画も読みに来てください！
↓のページのムーワァとデーヴァの大冒険に、私、パンジェンシーも出演しています！
medibang.com

【Ubuntu】Git Colaでバージョン管理

Ubuntu

いつもブログをご覧いただき、ありがとうございます！

パンジェンシーです！

f:id:x-fieldatts:20150508114016p:plain

 

さて、今回はソースコードのバージョン管理について、書きたいと思います。
一昔前までは、バージョン管理には、Subversionというシステムを使っていましたが、最近は、Gitが主流なようなので、そちらを使い始めています。 ====

環境

 

参考ページ

今回、参考にさせていただいたページは以下です。

gihyo.jp

 

  • バージョン管理しない無視リストの作成方法が紹介されています。

www.omakase.org

 

Git Colaのインストール

今回は、参考ページでオススメされていた「git-cola」をインストールすることにしました。

$ sudo apt-get install git-cola

Git Colaの起動

インストールが終わったら、DASHホームの検索窓から「git」を検索します。「Git Cola」が表示されるので、クリックしましょう。


「Git DAG」というのも表示されますが、そちらはコミットログブラウザで、Git Colaのメニューから起動できます。

Git Colaの使い方 [2015/12/6:追記]

私の環境では、「Git Cola」リポジトリの新規作成が機能していないようだったので、リポジトリの新規作成だけGit公式のGUIツールを使いました。

Git GUIツールのインストール

$ sudo apt-get install git-gui

Git GUIツールの起動

$ git gui

Git GUIツールの使い方

「新しいリポジトリを作る」を選択し、Git管理したいディレクトリを選択します。

作成すると、「Git Cola」の方でも、「開く」からリポジトリを選択すれば確認できるようになります。

コミットする前に、プロジェクトのディレクトリに「.gitignore」を作成して、無視リストを作成しておくとよいと思います。

無視リストの作成

Gitでは、ブロジェクトにあるけどバージョン管理しないファイルを、「.gitignore」というファイルに記載しておきます。そうすると、GUIツールで、未コミットのファイル一覧に該当ファイルが表示されなくなるので、管理がしやすくなります。


管理対象となるディレクトリ内に、.gitignoreファイルを作成しましょう。

$ gedit .gitignore


例えば、node.jsで作成するWEBアプリの場合、以下のように書くといいでしょう。

# module files
node_modules/

# log files
/*.log


ここのポイントは、

  • node_modules/は、package.jsonをもとに作成可能なので、管理しない
  • logなどのデバッグ用ファイルも、管理しない

というところでしょうか。必要に応じて、修正していきましょう。


.gitignoreを編集して保存後、Git Colaを開くと、記載したファイルは一覧に表示されなくなります。

一度コミットしたファイルを管理対象外にする場合

.gitignoreに記載後、該当ファイルを削除し、「削除した」というコミットをする必要があります。

GitとSVN(Subversion)の違い

GitはSubversionなどと同じく、基本的には、コードをいじったら「コミット」をして、変更履歴を保存するという使い方です。


subversionとの違いは、

  • 「ローカル」と「リモート」のリポジトリを使い分ける
  • ブランチを作って作業していき、マージする

というところですかね（間違えてたらすみません）。


subversionでは、自分の変更を共有のリポジトリにコミットしていく感じ。


Gitは、「分散型」の管理システムなので、まず自分用のローカルリポジトリにコミットし、それらをまとめて、共有のリモートリポジトリにプッシュする、という感じです。ブランチを手軽に作成してツリーで管理できるので、例えば、「A機能の実装用ブランチ」「Bバグ修正用ブランチ」などを、それぞれ作成して、切り替えながら作業することが手軽にできます。


私自身もあまり慣れていないので、よくわかってない部分もありますが、慣れれば、複雑な管理も割と簡単にできる気がします。

まとめ

個人で作るアプリにせよ、チームでのプロジェクトにせよ、コードの量が半端ないため、ソースコードのバージョン管理は、今や必須のものとなっています。Subversionに比べ、ちょっと操作が複雑なGitですが、慣れればきっと便利なはずだし、こういうのは時代の流れに乗るのが、色々と得なので、試してみることをオススメします。


ではまた！