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とかバージョン管理しておけば
さらによくなると思います。

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

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

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

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

他の人と一緒に仕事をするとき必ずコミュニケーションというやり取りがあります。

社会人となって間もないころは手探り状態でした。
報告・連絡・相談(ホウレンソウ)なんて言葉もそんなとき知りました。
面と向かってやり取りすることは少ないので、他の部署や管理職などから見れば口下手
(コミュニケーション不足)では？と言われています。

他の人と認識を共有するのは一筋縄ではいかないことを今現在、実感中(苦笑)です。
職業柄、プログラムに関することや業務上の仕様の確認とかが主になるのですが、最近は
メールでやり取りする方法に違和感を感じています。
といっても、面と向かって全部やり取りするということも何か違うような感じがしています。

メールのやり取りも必要以上の情報とかが含まれたり、返信に次ぐ返信で何がなんだか
分からなくなったりします。
関連性があるからと新規ではなく返信でやり取りしてさらに混乱。
メールは直ぐに発信できそうで、やり取りが続くと混乱するなと思うこのごろ。

口頭でやり取りするときも、その時聞いた本人は解決しているのですが、そこ止まり。
たぶん最近の私はやり取りした内容について「自分が納得したからそれで終わり。」
ということにモヤモヤしています。なんか違うと。

自分だけが納得、解決したからそれで良いという事が私にとってはダメなんだと思いました。

自分といっても昨日の自分も別人ですから、そのことを頭に入れないと後で痛い目を見ます。