harvest dailyside

一応生きてます。

という日記を自動生成するスクリプトってどうかなぁ、と思うくらい、仕事以外何もしていない今日この頃。

うおォン 俺はまるで人間コード製作所だ。
体はソースコードで出来ていた。
定時は5時だ…！5時だが…今回午前・午後の指定はしていない…！

どれでもお好きなのをどうぞ。

Q.最近よく見るサイトは？

A.http://localhost:3000

上のオススメサイトは多いときは一日16時間くらい見ています。
時々、すごいバグがあったりして、とても面白いです。
と、いうわけで元気にワーキングホリデー頑張ってます。

最近、私を含めて数名がとても忙しいです。
そのせいか、お客様へのレビュー中、レビュー先の同僚から「おい、リンク先にunkoとだけ書かれたファイルがあるぞ」と報告を受けたり、とんでもない事になっています。
報告を受けた時は眠気のピークだったのですが、10秒で修正して事なきを得ました。
テストデータとはいえ、あまりにひどいデータを入れるとろくな事がありませんね…

さて、世間は三連休。
私もせめて、冬物の服を買ったりする余裕が欲しいです。
最近目も悪くなった気がするし、高校の時にメガネを再構成し忘れて以来、メガネを作ろうかなぁと思っています。
そう言えば、自転車もパンクではなく別の部位からの空気漏れのようで臨終っぽいです。

ああ…時間が欲しい…！

ここ数年、毎年書いている気がしますが…
今年も残念ながらドラフト指名はされませんでした。
ドラフトも電子化してくれれば、何かの間違いも起こると思うんですが…
とりあえず、来年は一回くらいは多田野を見に行こうと思います。
それ以前に、本当に入団するの？て感じですが。
マリーンズの試合もずいぶん見ていないし、千葉マリンに行けるといいなぁ…

と、いうわけで土日からの流れ。

土曜日正午くらいに出勤。
翌、日曜日正午くらいまで作業。
午後10時くらいまで睡眠。
そこからまた出勤、午前6時に出て行った同僚を見送る。
シャワーを浴びに帰宅、定時よりだいぶ前に出社。
そして現在に至る…途中きつすぎて一回ダウンしました。

人間、切羽詰ると思いのほか力が出るもので、アプリも案外きちんと動作しているようです。
まあ、これからぼろが出るだろうことを見越して、ばれない内にばーっとやってがーっと裏からアップ！
今回は完全にスケジューリングで後手に回った形なので、反省したいところ。

そろそろ寒くなってきたし、来週末は買い物できる余裕くらいあるといいんですが。
体を壊さないように頑張ります。

普段、Ruby でメモリのことなんて気にする機会はないのですが、今回ちょっと面白かったので。

irbを起動して、こんなスクリプトを書いてみます。

a = 1
ary = []
ary << a #Rubyを知らない方は、配列に a を挿入したと思って下さい
p ary[0] => 1
a = nil
p a => nil
p ary[0] => 1

結果を見てもらうと分かるとおり、ary[0] に a を代入して、a が nil になったとしても、ary[0] の中身は変わらないんですね。
Ruby の実装はどうなっているんでしょう？

a = 1 と書くと、a の参照先を適当に設定して、そこに int クラスの無名オブジェクトを生成。
ary[0] << a と書くと、 a の参照先アドレスが ary[0] に渡されて、a に関わらずその参照を持ち続ける、とか？

CとかJavaっぽく考えると上の考え方が正しいのかな、と思います。
もちろん、ソースを読んだわけでも、ましてRubyのコミッタでもないのでてきとーな事を言っているだけですが。

一方こちらは別のケース。

(1..10).each do |i|
a = i
p a.object_id
end

object_id というのはオブジェクトの実体を示すIDなのですが、上のように定義するとループの一回毎にIDが変わります。

a = nil
(1..10).each do |i|
a = i
p a.object_id
end

一方で、こう書くと a の object_id は常に同じ値になります。
ブロック内で定義した変数はブロックから抜けると無効になるので、外で定義すればずっと保持されるという事ですね。
この場合も、やはり a はポインタっぽい雰囲気に思えるのですが…

求む、識者の意見！

独り身のプログラマはお金がたまるというのは、あれは本当ですね。
何せ、遊ぶ時間がないくらい仕事をするからお金は稼げるし、遊ぶ時間がないから使う暇もないと。
こんな状況でも、日記くらいはつけないとなぁ、と思う今日この頃です。
まあ、データのインポートテスト中で、結構暇があるとも言いますが。

ちなみにこのデータインポートが曲者で、2G積んでいるメモリを食いつぶした挙句No Memory Errorとかを吐いてくれます。
そこで私が取った対策とは…
…対策とは、インポート元のデータを分割して、別にインポートする。
forループの中って、メモリはどうなってるんでしょうか？
イメージとしては、一回の処理毎にガベージコレクションで初期化してくれそうなんですが。
こんな時、C言語でインポートをしていれば…きっと地獄ですね。

生命保険の会社の方が、カップめんを大量に差し入れてくれました。
これを食って不健康になって、うちの保険に入れという策略らしいです。
まあ、関係ないのでみんなでおいしく頂いてます。
明日は頼んでおいたペルツォフカも届くし、楽しみですね…

最後に、恒例のやつを。
俺…このプロジェクトが終わったら例のブツを買うんだ…

SQLで group by を使うと、where 句というのは意味をなしません。
理由はSQLの実行順序によるもので、指定しようとしてもエラーになります。

例えば、下のSQLは user_type_id ごとの登録ユーザ数を、 users テーブルから取得します。

select count(*) from users group by user_type_id;

会員種別ごとに、ユーザが何人いるのか調べたい場合ですね。

ここで、users テーブルに active という boolean の列があったとして、これが true のユーザのみが有効な会員だとします。
この有効な会員だけを持ってきたい場合、前述のとおり where 句は使えません。
こんな場合、以下のように having 句を指定します。

select count(*) from users group by user_type_id having active = true;

ただし、これをこのまま通すとエラーになります。
理由はSQLのルールに、having で使ったフィールドは「すべて」 group by 句でも指定しないといけない、というものがあるため。
上のSQLは、こう書けば動きます。

select count(*) from users group by user_type_id, active having active = true;

この時、例えば users に年齢をあらわす age という列があったとして、20代の会員を指定したい場合どうすればいいでしょう。
先ほどの話のとおり、having で指定した場合 group by にも指定が必要なので、以下のようになります。

select count(*) from users group by user_type_id, active, age having active = true and age between 20 and 29;

これを実行すると、group by で年齢によるグルーピングをしているため、20代の会員データが年齢別で表示されてしまいます。
今欲しいのは20代すべての人数の合計なので、これではまずいですね。

こんな場合、サブクエリを使って値を絞ってしまうべきでしょう。

select count(*) from (select * from users where age between 20 and 29) as selected_users group by user_type_id, active having active = true;

あらかじめ20代のユーザだけを取得しておく事により、条件の指定が必要なくなっています。

以上、今の案件でRailsを使っているにも関わらず、find_by_sql を使う事が多かったので、何となく。

風邪は治らないし、起きたら自転車はパンクしているし、だめな時は本当にどうしようもないですね。
こういう場合、さっさと帰って寝てしまうに限るので、今日はそうしました。
正直な話、風邪が抜けていなくて辛いので、今週は騙し騙しやります。

後、もし…もし、万が一、自転車を誰かが故意にパンクさせていたとしたら…部屋の片隅の悟史のバットが…
実際、最後に乗ったときは無事だったはずなので、故意の可能性もあります。
ま、疑っても仕方ないし、土日にでもさくっと直してきます。
ただ、さすがに次はないなぁ…

金曜日から、弊社に新入社員が一人入ります。
私から言える事があるとすれば、基礎を頑張ろうという程度。
基礎体力があると、無理やりプログラムを書いたり、無理やりSQLを書いたりできるので、いざというときに踏ん張りがききます。
基本情報とかを会社が取らせたがるのは、無理にでもその辺を叩き込むためじゃないかなぁ、と最近感じています。

後、土曜日に買い物につきあうとか、ネトゲで昔夫婦でしたとか言ったら、自動的にカップル認定。
主にバイで有名な弊社のCTOと、腐女子の姉を持つサラブレッドの副社長から。
うほ趣味はないのだよ、うほ趣味は！
でも、綾崎ハーマイオニーは許可。治外法権。

風邪をひくのは、実際はバカだけだと実感した月曜日。
24時間、ほぼ休みなしで眠って何とか出勤しています。
緑茶は本当に喉にやさしい…あれがなかったら、回復が1日単位で遅れていたでしょう。

Radioheadが、新作に自分で値段つけていいよキャンペーンというのをやっていました。
ちなみに私は最低額、0円で購入…支払方法も分からなかったので。
ここで0が選べるあたり、どこかの島国の著作権団体とは違うよなぁと思います。
惜しいと思ったのは、英語サイトかつユーザビリティが微妙なせいで、試聴ができるのかわからなかったところ。
試聴してから値段を決められればいいのでは、と思いました。

今月、何か+10万円くらいの収支になりそうです。
CD買ったり色々したのですが、食費を抑えたのが勝因っぽいです。
この調子なら年内に赤いにくいやつが買える…乞うご期待。

仕事では使うまいと思っていたのですが…
ついに、Java及びEclipseで仕事をしてしまいました。
しまいました、という言い方は語弊がありますが、何となくJavaは使いたくありませんでした。

で、今回使ってみての感想。
Eclipseは拡張であるRadRailsを使っていたおかげで結構分かり、パッケージ管理はFlexBuilderのおかげで分かり、Javaへの理解はRubyをやったおかげで深まっていた、という。
昔よりJavaらしいJavaのコードが書けるようになった気がします。
多言語に生きると専門性は薄れますが、こういう利点もあるという事ですね。
何かひとつだけできればいいというほど恵まれた環境でもないので、このように相互補完していくのが技術力を高める近道だと思います。

そして、今回JavaがRubyより優れていると感じた点。
それは、設計者の意図をより確実にコーダに伝えられる点です。
伝え方は『クラス/メソッドの構造他で無理やり縛る』方式ですが、多人数環境においては有効ではないかな、と。
とりあえず書けば動くというのは、ある意味怖さを含むと感じました。

大真面目な話の後で何ですが、タイトルは前作のラスボスが強烈すぎて、あまり印象に残っていないロマサガ3のラスボスから。

どこぞのラーメンマンではありませんが…
秋葉原の駅前によく行くラーメン屋があります。
特別おいしいわけではないんですが、なぜかよく行ってしまう謎の店。
今日行ったら、何か味が違っていた…というか、麺のゆで方が適当で、一部生でした。
中の人が変わったんでしょうか？
それとも…中に誰もいませんよ…？に切り替えた？
機械で作ったラーメンはうまひぃぃ、てやつですか？？

背中は可もなく不可もなくという感じです。
もともと姿勢が悪いので、無理やり矯正した方がいいのかも。
背筋に大リーグボール養成ギブスみたいなものをあてればいいんですよね。

本日も弊社技術部は全員残業。
社長は事務のおばさんを雇うとか言っていますが…
事務の13歳メイド少女さんとか事務の音無さんがいいです（まだ言うか）。

めも：11/9 Hellsing(9)

追記：結局今日も、3日連続のラーメン。
下に張ってあるのは、弊社の活力源。