Vagrantで利用するコマンド-仮想環境 起動とか停止とか

Vagrantで利用するコマンド

vagrant -h
ヘルプを表示
vagrantで実行できるコマンドの一覧を表示する

vagrant [コマンド] -h
vagrant [コマンド]のオプションや引数のヘルプを表示する

vagrant init
仮想環境をセットアップする
Vagrantで起動するために必要なVagrantfileが生成される

vagrant up
Vagrantfileで指定したBoxから仮想環境を起動する

vagrant suspend
起動中の仮想環境を一時停止する
仮想環境の復帰時間は少ない

vagrant halt
起動中の仮想環境を終了する
仮想環境の電源を落とすので復帰時間はvagrant suspendよりかかる

vagrant destroy
作成した仮想環境を破棄する
仮想環境にあるデータはすべて消去される
オプションをつけなければ事前に破棄するか確認メッセージが表示される
一からやり直したいときにはvagrant destroyしてvagrant upする

SQLのJOINで結合するときのレコードを絞りたい

片方のテーブルのレコードをすべて表示して、もう片方の結合するテーブルのレコードは
ある条件に一致するレコードに絞り込みたいという状況が必要になりました。

カテゴリのレコードはすべて必要だけどカテゴリに属するアイテムを結合するときのレコードは
アイテムの価格がXX以上だけのようなときです。

// カテゴリに属するアイテムを結合
select * from category left join item on category.id=item.category_id

// カテゴリに属するアイテムで価格が1000より大きいレコードだけを結合
select * from category left join item on category.id=item.category_id and item.price>1000

方法を見つけるのにも時間が掛かったので、同じようなことにならないようメモ。

ドキュメントとかリファレンスは見るように意識しよう

開発ですぐに期待した動作を実装することをつい優先するので、どこかのコードを
流用したりしてしまいます。
目の前の簡単?そうなやり方で進められたと、そのときは感じても
ホントはドキュメントとかリファレンスを見てみるともっと良い書き方とか、用意されているAPIが
あるなんて事を身をもって体験済みです。

開発の際には利用している言語とかライブラリとかフレームワークの資料は見るようにしようと
思います。

自分がメソッドとか作るときには必ずAPIドキュメントは書こうと思いました。
当たり前か。ハハッ。

JSON文字列で受け取った値を連想配列で扱う方法

WebシステムでJavaScriptを多用するときにお世話になるJSONですが
ブラウザから受け取ったJSONデータをPHP側でよしなに利用する場合
json_decodeを利用しますがjson_decode(JSONデータ)で返された値は
stdClassのオブジェクトになります。
連想配列として扱いたい場合はjson_decode(JSONデータ,true)とします。

json_decodeはPHP5.2以上で利用できます。

長いことPHPでは配列と連想配列を多用していたのでjson_decode(JSONデータ)を
実行してオブジェクトが返ってきて意図しない動作をしたときにはビツクリしました。

PHPもオブジェクトを利用する場面が増えてくるのかなと遅いながらも感じました。

JavaScriptでタイムスタンプを簡単？に取得する方法

var millisecond = +new Date(); 

これでタイムスタンプを参照することができます。
要素を動的に生成したときに仮IDを割り振りたい場合に利用できると思います。

ScalaでWebアプリケーションを作るときのフレームワーク

仕事でWebアプリケーションを開発するときにはPHPがメインなのですが、最近他の言語でも
作れるようになりたいと思い、何が良いか調べていたところScalaが気になったのでScalaに
決めました。

触れたことの無い言語だったので、どうやって進めていけば良いか模索状態ですが
フレームワークも利用して覚えていけば良いかなと思っています。

そのフレームワークがどんなものがあるのかも調べてみたところPlay2(Play Framework2)と
Scalatraというものがあるようです。

簡単なもので良いからそれぞれのフレームワークを触ってみようと思います。
気付いたこと、出来るのかなと思ったことはGitHubを利用して進めよう。

仕事でのコミュニケーション-2

職業柄プログラムや仕様の確認事が多いですが、確認したときには必ずといって良いほど
プログラムや設定内容を何か編集したりします。

そんなときに「ここ変更しました」とか「追加しました」だけメールや口頭で発信されてます。
その状況が続くとあとで振り返ったときに「何故？」が生まれて結局分からず不完全燃焼します。

コミュニケーションって最近は"そのとき"だけじゃなくて"その後"も振り返られることが
できるようにするのが、大事なのではと思っています。

プログラムなどに関っている場合は編集内容を残すのではなくて、編集した理由のほうが
後で大切になるので、"理由"を残すように意識しています。

編集内容は"diff -u"で見やすくすることも出来ますし、Gitとかバージョン管理しておけば
さらによくなると思います。

仕事場ではプログラムに関する内容や仕様に関する内容があれば、メールや口頭ではなく
バージョン管理と連携しているシステムを利用してとお願いしているのに中々根付かないので
モヤモヤしています。

口頭だと周りから見ればコミュニケーションが取れているように見えるけど、その場・その時・そこ
止まりなので"そのときの当事者"しか影響しません。
メールなら内容は残りますが"残るだけ。"さらにそれに関連づくものを残しているかで難易度が
変わっちゃいます。
仕事場では「メール探すのにも時間が掛かるから」と関係するメンバーになったのに探さず
文句を付け加えて関ろうとしないメンバーも現に居ます。
そんな調子で仕事を進めてきたから何も変わらないんだろうなと、事あるごとに思います。

編集したときのコミットメッセージに口頭でやり取りに到った理由を付け加えておくとか、
必要な情報はサービスや仕組みを利用して、メールは必要以上に情報を含めないようにして
通知・気付くための用途で利用するものにしたりとか。
次の一歩を含めないと何もプラスにならないのにね。と思う。