複数マシン間で、atomで取ったメモを同期するための環境を整えた

自分は、いろんな作業をするときに、人に報告したり、twitterに書いたりするほどでもないことを、atomを使ってmarkdown形式でメモをとりながら進めています。
1台のマシンでメモを取るだけなら、シンプルでいいんですが、VMを含め、複数台のマシンを行ったり来たりしながら作業するとなると、これらの間でどうやってメモを同期するか、という点が悩ましくなってきます。
今回のエントリは、どうやってatomを用いて、複数のマシンでどうやってメモを同期させるか考えたっていう、そんなお話。

TL;DR

  • atomのsync-on-saveはとても良い
  • WindowsとLinuxだとパッチ当てないと動かない(2017年10月12日時点)

gitでメモの同期をとりたい。でもコマンド打つの、面倒だな。

ファイル単位で同期を取る仕組みというのは、atomには色々あって、たとえばRemote-FTPというパッケージで実現することができます。
最初はこれを使っていたんですが、同期の粒度がファイルだと、複数のマシンで同じファイルを変更したときに、どちらかがどちらかをうっかり上書きして、せっかく書いたメモを失う、なんてことになりそうだなと思いました。
実際に上書きをしてしまったことはなかったものの、そういうことが起こりうるということを意識しなければならないのがなんとなくストレスでした。

だから、ファイルよりも小さい単位で同期を取りたい。
そうだ!僕達には、gitがある!gitを使おう!と考えました。

でも、gitも、コミットメッセージを書いたり、共有のためにpushしたりと、やらなければいけないことが多くてちょっと面倒です。

sync-on-save というパッケージに面倒事を引き受けてもらう

どうせ、自分が適当に見るメモなんだから、コミットメッセージなんて適当に自動でつけてくれればいいし、pushも勝手にやってくれればいいのに。
そんなパッケージないかなー?と探してみたところ sync-on-saveというパッケージがありました。

このパッケージを使って救われました。本当に欲しいものそのものでした。
コマンドパレットからEnable Syncすると、ファイルを保存したタイミングでgit commitとgit pushを自動でしてくれます。
あとなんか他の場所で同じファイル編集してたらmergeもしてくれる。

本当に便利だ。素敵だなぁ。

LinuxとWindows向けにバグがあって動かなかった→なおした

バグを見つけたので直しました!バージョン0.1.5からは何も考えずにATOMのパッケージをインストールすれば使えるようになりました!
みんな使ってみてね。

2017年10月12日時点でダウンロード可能な、バージョン0.1.4にはちょっとしたバグあり、WindowsとLinuxでは動きません。
直したのでプルリク投げてみるつもりです。

差分は1行なので、これ読んで今すぐ使ってみたい!って思った人は、sync-on-saveをインストールした上で、コードを直接いじるのが楽そうです。
コミットの情報はここにおいときますので参考にしていじってみてね。

https://github.com/sirrow/sync-on-save/commit/7df50d7094156b9fd030ab698a6ff69a680177af
おしまい。

本文に書ききれなかったけど書きたかった事

sync-on-saveを作った人について

sync-on-saveを作った人すごいなぁ、ありがたいなぁ。プルリクも投げなきゃいけないし、どんな人なんだろう?って思ったので調べてみたら、 Hajime Morita さんでした。
そういえば、rebuild.fm 聞いたことないし、今度聞いてみよう。

昔はssh + screen + emacsでメモを取ってた

自分は一昔前は、VPS上でscreenを動かして、その上で動かしたemacs -nwに、色んなマシンからsshでログインした上でattachしてメモを取ってました。
これはこれで悪い方法じゃなかった気がします。手軽だしね。ただ、ネットワークから切断されるとつらいんだこれ。
gitなら手元にコピーあるからネットワークなくても編集できるしね。そんなところが素敵。

タスク管理をtrelloからOpenProjectに変えようかなと思ったけど結局redmineにした話

今回の移行に当たって考えたことのまとめから書いておく

Wrikeは最高だけど、高すぎて厳しい。
OpenProjectは貧乏VPSには性能面で辛かった。
結局Redmineしか選択肢がなかった。
RedmineをDockerでインストールするとプラグインのインストールが辛かった。

ことの経緯

自分は生きるのが下手で、タスク管理やスケジュール管理がうまくできず、どうやってこれらをやっていくのかということについて色々試行錯誤していたりします。

昔はredmineで何でもかんでも管理することで落ち着いていたのですが、

  1. タスクの数が増えてきた時にごちゃごちゃしてくる
  2. 自力でホスティングするのめんどくさい
  3. UIが前時代的で辛い

あたりが理由で、trelloに移行していました。
子供が生まれてあんまり難しいことを家でやらなくなっていたので、シンプルな使い勝手のtrelloがとてもいい感じでした。
ただ、このところ子供がある程度大きくなってきて、自分が色々する時間も取れるようになってきたので、何か新しいことをしようと思った時に、タスクの入れ子が1段階しかできないtrelloだと複雑なことをしようとしたきのタスクのドリルダウンがしづらくて窮屈に感じられるようになってきました。

なので、タスクの入れ子現実的な範囲でいいので入れ子にできることを条件に色々探して見ました。

Wrike試してみた

2017年っぽいUIでスッゲー使いやすくて、これにしようって思ったのですが、試用期間が終わると、Freeではタスクの入れ子ができないので今回の要件に合わない。
けど課金額はどうだ?と思って調べて見たところ、課金は1人あたり月 $5と書いてあったので、$5ならVPS1つ借りるのと同じだしいけるんじゃないかと思ったんですが、5人ぶんまとめて契約しなきゃいけないらしく、1人で使うとしても月$25になってしまって辛いということが判明し断念。

すごくつかいやすいのに。もうちょっとカジュアルに使える価格設定だったらよかったのになぁと後ろ髪を引かれつつ使うのをやめました。

OpenProjectを試してみた

自力でホストしてもいいので何かいいものないかなぁと思って探して見たところ、最近はOpenProjectというOSSのプロジェクト管理ツールがあるという情報に当たったので、試してみようと一念発起。
公式でdocker imageが用意されていたので、これを利用しようとGoogle Compute Engineに1番安いインスタンスを立てて、dockerホスティング用のイメージを起動。その上にインストールすることを試みました。
が、なんかインストールがコケる。

インストールの感じを見ていると、どうも、dockerのイメージがでかいらしく、ディスクを使い切ってしまっていた模様。
なるほどね、と思って手元のPCのLinuxのVM上にdocker環境を整備してそこに入れてみたらいい感じで動いた。

Wrikeほどの使い勝手はないものの、RedmineよりはちょっぴりモダンなUIで、これでいいんじゃないかと思ってメモリの使用量を軽くチェックして見た所、起動するだけで1.2GBほど使う模様。
なんか、dockerのイメージ内に、サービスの本体であるRubyだけでなく、postgresやmemcacheも含んでいた。なるほど、イメージがでかいわけだ、とある程度納得。
しかし、メモリ使用量がこれでは、やすいVPSやクラウドインスタンス上に立てっぱなしに使うってのは若干厳しい。

とはいえ、ものは試しだと思って、昔契約した2GBのメモリが使える海外の安いVPSにインストールしてみた。
そしたら、起動はちゃんとしたものの、めちゃめちゃ重たい。
多分、ブラウザとサーバ間のレイテンシが何倍にも重なってUIの表示に効いてくるような作りになっているんだと思う。(未検証)

となると、手元のVMや家の中に置いたサーバーで動かすにはいいけど、外に置こうとするとレイテンシが辛くなってしまうな、ということで、これも不採用。

Redmineに戻ってきてしまった

色々不自由な点もあるけど、軽いし、もうredmineでいいや ということで、Redmineを改めて使い始めることにしました。
インストールはdockerで気軽に。アップデートもきっと手軽にできるでしょう。
いい時代だ。

Dockerでインストールした時にプラグインどうするんだ問題

Redmineには、プラグインが存在しています。いくつかのプラグインをDockerでインストールした手前、コンテナの中に踏み込んでプラグインをインストールするのはなんだかダサい気がしました。なので、自分でプラグイン用のDockerfileを書いてプラグイン類をインストールしました。
複数のプラグインを入れるのでそれぞれのDockerfileは分割して作成しました。
Dockerfileは、ベースとなるイメージの名前とバージョンを指定して、このイメージにどういうファイルを追加するのか、どういう風に起動するのかといった情報を追加して行くという書き方をするようになっています。

例えば、2つのプラグイン(それぞれプラグインAとプラグインBとする)をインストールするために
公式Redmineイメージ -> プラグインA追加イメージ → プラグインB追加イメージ
という順番でイメージを拡張するとします。
この時、プラグインA追加イメージを作るためのDockerfileには、ベースとなるのは公式Redmineイメージですよと書いてありますし、ブラグインB追加イメージを作るためのDockerfileにはベースはプラグインA追加イメージですよと書かれています。
なので、例えば、上記の状態から、やっぱりプラグインAが不要だから、プラグインAを取り除こうと思っても、単純にプラグインA追加イメージを作成しないだけではダメうまくいきません。プラグインB追加イメージ作成用DockerfileにあるベースとなるイメージをブラグインB追加イメージから公式Redmineイメージに書き換えないといけないという手間があります。

そんな感じで、若干、長く管理できるんだろうか、大丈夫なんだろうかという疑問は持ちつつも、とりあえずDockerでやっていこうということに決めました。

ちなみに、プラグインは、easy gantt plugin(free)Time Loggerだけ使ってます。シンプルに。

プラグイン追加後のDockerイメージをdockerhubにアップしておこうかなとも思ったのですが、easy gantt plugin が GPL v2にも関わらず、ソースコードは配布して欲しくなさそうなので自重。プラグインダウンロード用のワンタイムのURLを生成したり、そもそもgithubあたりにも置いてなかったりして、長く使い続けられるのか若干不安。ただ、そういった不安に目をつぶれるくらいeasy ganttでredmineは使いやすくなるので使っていこうと思います。
easy gantt freeは、ソースコード開示をしぶったりせず、最初からインストール済みのDockerイメージを配布しちゃえば、試してくれる人、買ってくれる人増えるんじゃないかなって思ったりするんですが、そうでもないんですかねぇ。

それよりも、easy redmineのホスティングサービス売りたい感じなのかなぁ。

ConoHaのAPIを叩く・・・のは面倒くさかったのでnovaコマンドを使ってみた。

ConoHa VPSのインスタンスをコマンドラインから操作したい!

こんにちは。先日、ConoHa VPS上にVDI環境を作ったよ!という日記を書きまして、結構いい感じに実用しております。

で、先日作った環境だと、起動や終了のためにウェブブラウザを使ってConoHaのポータルを開いてマウスでポチポチするひつようがありまして、それってちょっと面倒くさい。起動や終了やイメージの作成なんかを自動化したいなぁとおもうのは人のサガでありまして、なので、APIを叩いて、コマンドラインツールを作ろうかなぁ、などと思ったのですが・・・

Conoha VPSはOpenStackベースだからOpenStack向けのコマンドラインツールが使える!

よくよく考えたら、ConoHa VPSは、OpenStackというOSSのクラウドを作るためのソフトをベースに作られているので、OpenStack用に作られたコマンドラインツール群を用いてある程度コントロール可能なはずです。なので、まずはOpenStack用のコマンドラインツールのうちVMの起動、停止、削除などを行えるnovaコマンドについて試してみることにしました。

novaコマンドとは

OpenStackは、幾つかのサーバで構成されています。それぞれのサーバはAPIを公開しています。このうち、VMを起動したり停止したり削除したりといった操作を行うサーバをnovaと呼びます。novaコマンドは、novaのAPIを叩き、novaの持つVMを起動したり停止したり削除したりといった機能を呼び出します。

novaコマンドのインストール

OpenStackを構成するサーバや、これらのサーバを操作するためのコマンド群をインストールする方法には、いくつかあります。今回は、手元にある環境がCentOS 7.1だったため、RDOと呼ばれる、OpenStackをインストールするためのyumレポジトリに置かれているrpmのパッケージをインストールすることにしました。CentOSやFedoraならこの手順で大丈夫なはずです。

sudo yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
sudo yum install python-novaclient

これでnovaコマンドがインストールできました。

ちなみに、UbuntuにはUbuntu OpenStack Installer が用意されていますし、pipのパッケージとしても公開されているので、好みに応じてインストール方法は選べそうです。

novaコマンドの設定

環境変数に設定されている値を使うので設定します。必要な情報はConoHaのダッシュボード右下のAPIボタンのところを叩けば参照したり設定したりできます。

export OS_USERNAME=APIユーザのユーザ名
export OS_PASSWORD=APIユーザのパスワード
export OS_TENANT_NAME=テナント情報のテナント名
export OS_TENANT_ID=テナント情報のテナントID
export OS_AUTH_URL=https://identity.tyo1.conoha.io/v2.0

以上をファイルに書き込んでおいて、必要に応じて読みだすようにすると楽だと思います。

novaコマンドを使ってみる

novaコマンドを実行すると、どういうオプションがあるのか色々表示できます。

起動したり、削除したり、リブートしたり、イメージを作ったりなど先日のVDI作成エントリで必要な操作は全部コマンドラインから実行できることが確認できました。これまでブラウザからしなければならなかった作業がコマンドラインからできるようになりました!これでちょっと楽になりました。

インタフェースを守ってくれているConoHaの中の人に感謝!

おそらく、ConoHaではOpenStackのコードをそこそこ変更していると思うのですが、それでもAPIを変更せずに守ってくれているおかげで既存のツールを使えてとてもありがたいです。

中の人たちに感謝しつつ、OpenStackを前提としたエコシステムのありがたみを享受して楽しく生きていきましょう。

以上です。

VDI環境をConoHa上に作った、その理由。

安くVDIを実現したい!

お小遣いに悩めるIT系サラリーマンの皆様こんにちは。
最近は、容量が小さいSSDを積んだノートPCが多くて、なんだか困りますよね。
ホストに入っているOSがWindowsやOS Xなのだけど、Linux環境が欲しい!でも、SSDの容量が小さいのでVMを作ってディスクの容量をガバガバ食うのはちょっとつらい。
かと言って、新しいPCを用意してそこにリモートアクセスするのも、PCを買うのも電気代もかかっちゃって、なかなか厳しい。
と言うシチュエーションはまま有ると思います。というか、僕自身がそうですしね。

そこで、考えてみました。クラウド上に開発環境を作ればいい!と!思いつきました。
でも、クラウドに置いたLinuxのインスタンスにはsshでアクセスして、emacsやvimで開発するんでしょ?ちがうんだよ!IntelliJやsublimeみたいなもっとリッチな環境が使いたいんだよ!という人、多いと思います。
と言うか、僕自身がそうですしね。

というわけで、いろいろ試してみたところ、ConoHaのインスタンス上にTigerVNCを用いてアクセスすることで、安くVDI環境を構築できたので紹介します。

なんでConoHaを選んだのか

インスタンスの料金体系がVDI向き

ConoHaのインスタンスは、1時間刻みで課金されます。
お小遣いに悩めるIT系サラリーマン的には、開発環境は常時起動しているわけではありません。
例えば、仕事から帰ってきた後とか、土日だけとか、限られた時間、安く使えることが大切なのです。
なので、細かい粒度で課金してくれるConoHaはとてもこういった用途に向いているな!と思うわけです。

50GBまでディスクイメージの保存にお金がかからない

これがけっこう重要なポイントで、一般的なクラウドでは、インスタンスの電源を切っても削除しなければお金がかかりつづけます。
インスタンスの削除を行うと、一緒にそのインスタンスで用いていたディスクのイメージも削除されます。
したがって、インスタンスを削除し、課金を止めるためには、ディスクのイメージのバックアップを取得する必要が有ります。
ConoHaでは、このディスクイメージバックアップが50GBまで無料です。
そして、インスタンスが用いるディスク容量は低スペック~中スペックくらいのものは50GBです。
なので、ディスクイメージを無料でバックアップすることが可能です。

したがって、
インスタンスの停止 → ディスクイメージのバックアップ取得 → インスタンス削除
という手順を踏むことで、ディスクイメージを保持したまま課金を止めることができます。

また、インスタンスの起動時にバックアップイメージを書き戻して起動することが出きるので、
インスタンス削除時の環境を取り戻すこともできます。

必要に応じて性能が選べる

インスタンスをバックアップイメージから書き戻して起動する際には、以前に用いていたインスタンスと異なる性能のものを選ぶことができます。
したがって、普段は最低スペックのものを用いておき、必要に応じて、高性能のインスタンスを選ぶことで、簡易に性能向上が可能デス。

SSDが乗っている

人間が直接扱う環境に関しては、CPUが早いよりもSSDが乗っていることのほうが体感速度に影響は大きいと思います。
ConoHaは全部のインスタンスがSSDで動いているので、人間が快適に使うのに向いていると考えます。

日本国内にホストされている

VDIはネットワーク越しに用いるものなので、手元の環境からホストされているインスタンスまでのネットワーク的な距離、主にレイテンシが重要になります。
ConoHaは国内にインスタンスをホストしてくれるため、レイテンシを小さく抑えることができます。

まとめ

以上の理由で、安くVDI環境を構築するのに、ConoHaは向いていると考えます!
このエントリも、ConoHa上で起動した最低スペックのインスタンス上のIntelliJ IDEAで書いています。
まったく何の問題もなく使えています。
新しい開発環境は欲しいけどどうしよう・・・と悩んでいる方、
ConoHaはユーザ登録すると、いくらか分か無料で使えますので、ぜひ試してみてくださいね!

Linux(fedora 21)の上でVisual Studio Code を使って sails.js の開発をしたい!

あらまし

さいきん、アニイベZというアニソンがかかるクラブイベントのをまとめたポータルサイトの拡張機能の開発を担当することとなりました。開発には、いろいろな経緯があって、 node.js 向けの RoR 風フレームワークである sails.js というフレームワークを用いて開発を行うことにしました。

これまではemacsのjs2-modeで開発を行おうと試みてきたのですが、無名関数を使うとインデントが大きく崩れたり、補完がなんだか上手く効かなかったりと、効率の悪い状況が続いてきました。

何かいいIDEは無いものかなぁ。WebStormはお金かかるからなぁ。。などと思っていたところに、Microsoftの開発者向けカンファレンスである Build 2015 にて Visual Studio Code という、WindowsでもMacでもLinuxでも動く、.Netとnode.js向けのIDEが発表されたという報道を見て、おー、これ、試してみるかー と思って、試してみました。

sails.jsもnode.jsもよくわかってないのでトンチンカンなことを書いているかもしれませんが、自分のための備忘録というか、作業ログってことで。

ここに書いてあるのを真似するとできるようになること

  • Visual Studio Code である程度補完がきくようになる
  • ブレイクポイントを置いてデバッグできる

できるようにならないこと

  • ormapper(waterline)とかblueprintの補完はできない
  • 他にもいろいろできないことがありそうだけどまだよくわからない

やりかた

1. まずはsailsを動かす

1.1. fedora 21 をインストールする

してください。自分はWorkstationをVMware Player上にインストールしました。

1.2. node.js と npm をインストールする

とりあえず、node.jsとnpmをyumでインストールします。

$ sudo yum install node npm

でも、このままだとnpmのバージョンが古くてsailsがインストールできないので、一度npmを最新版にします。

$ sudo npm install -g npm

これでnpmが新しくなりました。

1.3. sails をインストールする

というわけで、sailsをインストールします。

$ sudo npm install -g sails

1.4. sailsを動かしてみる

$ sudo npm install -g sails
$ cd visualstudio_sails
$ sails lift

として、webブラウザで http://localhost:1337 を見るとテンプレートのページが見えるはずです。

2. Visual Studio Codeをインストールしてデバッガで止めてみる

2.1. Visual Studio Code をインストールする

まずは、Visual Studio Code公式サイトからVisual Studio Code をダウンロードしてきます。zipなので適当に圧縮を解いて、適当な場所に置きます。自分は取り敢えずホームディレクトリのvscってディレクトリに置くことにしました。

$ unzip VSCode-linux-x64.zip -d vsc
$ cd vsc
$ ./Code

ってすると起動します。おお、かっこいいではないか。

Screenshot from 2015-05-07 23:56:23とりあえず右側のWelcomeタブは適当に眺めた後に閉じちゃいましょう。

2.2. さっき作ったsailsのプロジェクトを読み込んでみる

File -> Open Folder でさっき作った visualstudio_sails ディレクトリを選択。すると、でぃれくとりのツリーが見えます。適当にフォルダを開いてやると、ファイルの中身も見えます。

Screenshot from 2015-05-08 00:03:56

2.3. 実行環境の設定をする

Visual Studio Code内からsailsを実行したりデバッグしてあげたりするためには、nodeやsailsがどこにおいてあるかを伝えなきゃダメだよなぁということで、その辺りを設定します。

左に縦に4つ並んでるアイコンの一番下に虫禁止マークみたいなのがあるので、それをポチッとしてやります。すると、今までディレクトリ構成を表示してたところが、変数やスタックを表示するための物に切り替わります。その上の方に、如何にも設定用のアイコンといった趣の歯車のアイコンがあるので、そいつを押してやると

Screenshot from 2015-05-08 00:09:02なんか、launch.json という如何にもプログラムを動かすための設定を記述するために使うっぽいファイルが開きます。

歯車の左にあるドロップダウンリストの内容は、このjsonファイルの configuration 配列によって定義されているオーラを感じますので、このファイルをコメントと空気を読んで編集します。

具体的にはこんな感じにしてみました。

{
    "version": "0.1.0",
    // List of configurations. Add new configurations or edit existing ones.  
    // ONLY "node" and "mono" are supported, change "type" to switch.
    "configurations": [
        {
            // Name of configuration; appears in the launch configuration drop down menu.
            "name": "Launch sails.js",
            // Type of configuration. Possible values: "node", "mono".
            "type": "node",
            // Workspace relative or absolute path to the program.
            "program": "/usr/bin/sails",
            // Automatically stop program after launch.
            "stopOnEntry": true,
            // Command line arguments passed to the program.
            "args": ["lift"],
            // Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
            "cwd": ".",
            // Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
            "runtimeExecutable": "/usr/bin/node",
            // Environment variables passed to the program.
            "env": { }
        }, 
        {
            // Name of configuration; appears in the launch configuration drop down menu.
            "name": "Launch app.js",
            // Type of configuration. Possible values: "node", "mono".
            "type": "node",
            // Workspace relative or absolute path to the program.
            "program": "app.js",
            // Automatically stop program after launch.
            "stopOnEntry": true,
            // Command line arguments passed to the program.
            "args": [],
            // Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
            "cwd": ".",
            // Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
            "runtimeExecutable": null,
            // Environment variables passed to the program.
            "env": { }
        }, 
        {
            "name": "Attach",
            "type": "node",
            // TCP/IP address. Default is "localhost".
            "address": "localhost",
            // Port to attach to.
            "port": 5858
        }
    ]
}

Launch Sails.js って書いてある要素が追加した部分になります。これを保存すると、さっきのドロップダウンリストにLaunch Sails.js という選択肢が現れるので、これを有り難く選択します。

で、その左にある如何にも実行ボタンっぽい右向きの緑色の矢印を押すと

Screenshot from 2015-05-08 00:19:36なんか、エラーがでる訳です。

エラーの内容を確認すると、

Cannot start OpenDebug because Mono (or a Mono version >= 3.10.0) is required

なんか、Monoの3.10.0以上が必要だと言わます。なるほどなるほど、じゃあMonoをインストールしてやろうと思って、yum install ’mono*’ なんてやろうものなら fedora 標準のバージョン2.10のmonoがインストールされ、とても残念な気持ちになるので、ここはぐっとこらえます。

2.4. 新しいmonoをインストールする

Monoの公式ページにインストール方法が明示してあるので、ありがたみを感じながらこれに沿ってyumのレポジトリをまずは有効化します。

$ sudo rpm --import "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF"
$ sudo yum-config-manager --add-repo http://download.mono-project.com/repo/centos/

 

これで、yumのレポジトリが有効になったはずです。レポジトリの名前を確認するために yum repolist を実行すると

$ yum repolist
読み込んだプラグイン:langpacks
download.mono-project.com_repo_centos_ | 2.9 kB 00:00
download.mono-project.com_repo_centos_/primary_db | 213 kB 00:00
リポジトリー ID リポジトリー名 状態
download.mono-project.com_repo_centos_ added from: http://download.mono-p 322
fedora/21/x86_64 Fedora 21 - x86_64 42,816
updates/21/x86_64 Fedora 21 - x86_64 - Updates 16,325
repolist: 59,463

download.mono-project.com_repo_centos_ が追加されたレポジトリのようですので、このレポジトリの中のmonoをインストールしてやります。

$ sudo yum repository-packages download.mono-project.com_repo_centos_ install mono

で、さっき押したときにエラーが出た、如何にも実行ボタンっぽい右向きの緑色の矢印を押すと

Screenshot from 2015-05-08 00:37:09なんか、黄色い右向き矢印が出て、如何にもプログラムの先頭で止まってるなーというオーラを感じられます。なので、如何にもコンテニューボタンっぽい上部真ん中に現れた、右向きの三角形を押してやります。すると、なんかsails.jsが動き出したオーラが感じられるので、ブラウザで http://localhost:1337 を確認してあげるとちゃんと動いているのが確認できます。

赤くて四角いボタンを押すと止まります。実行と停止を何回かやってもとりあえず上手く動きます。ここで設定が終わったオーラを感じますが、もう一息です。

2.5. 何かコードを書いてデバッグしてみる

ここまで来たら、何か実際にコードを書いてブレイクポイントを置いてみたいという衝動に駆られるのが人間の性です。なので、適当にuserなどという名前のapiを作ってみます。

visualstudio_sails ディレクトリ内で

$ sails generate api user
info: Created a new api!

ってやると、userという名前のmodelとcontrollerが作られます。よし、早速実行だ!と思って実行ボタンを押して、いざ http://localhost:1337 に接続しようとすると接続できません。その内、実行が終わったような感じで、画面上部中央のデバッグ中にだけ表示されるボタンも消えてしまいます。

ここで、何かがおかしいと感じて、./Code を実行したコンソールを改めて確認すると色々表示されている中に

error: Error: The hook `orm` is taking too long to load

という文字列を見つけることができると思います。何やらormapperが上手く動いていないらしいぞ、と感づきます。

ここで、 visualstudio_sails ディレクトリ内で、 sails lift すると

In a production environment (NODE_ENV===”production”) Sails always uses
migrate:”safe” to protect inadvertent deletion of your data.
However during development, you have a few other options for convenience:

1. safe – never auto-migrate my database(s). I will do it myself (by hand)
2. alter – auto-migrate, but attempt to keep my existing data (experimental)
3. drop – wipe/drop ALL my data and rebuild models every time I lift Sails

What would you like Sails to do?

info: To skip this prompt in the future, set `sails.config.models.migrate`.
info: (conventionally, this is done in `config/models.js`)

warn: ** DO NOT CHOOSE “2” or “3” IF YOU ARE WORKING WITH PRODUCTION DATA **

と表示され、どのようにデータを引き継ぐか決めろと迫ってきます。さらにこの状態で何もせずに放っておくと

prompt: ?:  error: Error: The hook `orm` is taking too long to load.
Make sure it is triggering its `initialize()` callback, or else set `sails.config.orm._hookTimeout to a higher value (currently 20000)
at tooLong [as _onTimeout] (/usr/lib/node_modules/sails/lib/app/private/loadHooks.js:92:21)
at Timer.listOnTimeout [as ontimeout] (timers.js:112:15)

というエラーを吐いて、タイムアウトして終了します。さっき、Visual Studio Code 上で実行したのに動かなかったのはこれが原因だなーとわかります。先程のエラーメッセージの中に

info: To skip this prompt in the future, set `sails.config.models.migrate`.
info: (conventionally, this is done in `config/models.js`)

と有り難く書いてあるので、config.models.js を開くと下の方に

// migrate: ‘alter’

と如何にもそれっぽい文字列が見当たるので、このコメントアウトを取ってあげます。すると、さっきの引継方法で2を選んだことに毎回自動的になります。

改めてVisual Studio Code のデバッガからsailsを起動すると無事起動します。あとは、好きなようにコードを書いて、デバッガで止めてと快適に使えると思います。

なんか、適当にコードをかいて、ブレイクポイントを置いて、コールスタックも変数の中身もちゃんと見えてるぞというスクリーンショットと共にお別れしたいと思います。それでは皆さんさようなら。

Screenshot from 2015-05-08 01:09:26

おつかれさまでした。