朝、7時頃起きる。
睡眠時間が短いわけじゃないけど、少し寝不足な感じがする。

昼に会社の人数人でカレーを食べに行った。
秋葉原のベンガルがおすすめということで行ってみると、確かに美味しかった。
野菜カレーはレンコンとかゴーヤとか入ってて、珍しかった。

夜は7時頃うちに帰ってきて、ご飯食べたりテレビを見たり。
TEDの「良いアイデアはどこで生まれる？」が興味深かった。
GPSの仕組みが他国の衛星の電波を聞いて見るところから始まり、
決して偶然のひらめきではなく、普段の考えの中から作られてくるということ。
また、大きな発見は、得てして偶発的に見つかったことにしたがる傾向があること。

普段からいろいろなことに興味を持ち、疑問に思ったことは深く考えてみたりして、
深く考えていってみることが大切なんだろうな。
そうすると、自ずと面白いアイディアが出てきたりするんだろうね。
ただ、それを単純に待ち続けるのではなく、より早くアイディアを出せるような
より流動的な考えを持って行くと良いんだろうね。

会社は有給をもらって、TechCrunch Tokyoに行ってきました。
いろいろと情報収集したかったけど、僕の興味とは違う感じだったな。

朝、家賃の自動送金の手続きのため銀行へ。
「継続のお知らせ」って手紙もらったから行ったのに、
新規で書類書かせるのはやめてくれ…。ほんと時間の無駄。

TechCrunch Tokyoは少しおくれて10時過ぎに会場入り。
同時通訳用のレシーバーを借りるのを忘れていて、そのまま聞くことに。
話すのが早いのと、すごく単語をつなげて話すから聞き取れない聞き取れない…。
慣れてないとダメだね。

結局、4時頃にまぁいいやっていう気になって帰宅。
晩御飯は一人チゲ鍋を作った。
ウェイパ、味噌、豆板醤など、自分で合わせてスープを作った。
辛さ加減が調節できていいね。

日中はお仕事。
朝からあるモジュールのスループットが出ていないという話の打ち合わせ。
週明けだと完全に頭から抜けていて、的はずれな質問を繰り返すなど…。

お昼は時間がなかったので弁当で済ませる。
最近お昼を食べに家に戻ることが少ない。

午後はひたすら計算、このFIFOの段数で足りるか？とか
どの状況でFIFOがあふれるかとか。
ちゃんと評価しとかないと、後々自分が困るわけだからね…。

夜は新しい人が入ったので歓迎会。まぁいろいろとありました。
最後は数人で秋葉原のBeerSであれこれと話してました。

ブラントンはやっぱり美味しいなぁと再認識。
ブラントンは友人にはじめて教えてもらったウイスキーなんだけど、
意外なことにもずっと美味しいと思えるウイスキーなんだよね。

ハーパーとかも一時期美味しいと思ったけど、最近飲んだら
何か味にトゲがあるような感じがして、ちょっと避けてるかなぁ。

帰ったのは1時頃。さっさと寝ました。

午前、「日本人の英語」を読む。
日本人の冠詞の使い方は、単純に一つ（a）なのか特定のものなのか（the）とするけど、
実際にはもっと多くの意味合いが含まれているよ、ということ。
なるほど、と意気込んで実際に書いてみると、「あれ？」となっちゃう。
もう少し頭に叩きこむ必要がありそう。

午後、ヨドバシにスマートフォンのケースを買いに行く。
少し前からヨドバシの1階入り口に移動されていて、多くの人の目につくようになっている。
中国での卸の価格を知っていると、そりゃそうなるよなと思う…。恐ろしい利益率だろうなぁ。

小さいデバイス作ろうと思った場合、普通に手に入る範囲で
どんなのがあるんだろう、と思って探してみた。
秋月で扱っているものだと以下のもの。

ＡＴｔｉｎｙ１０実装モジュール　（米粒ＡＶＲ）
http://akizukidenshi.com/catalog/g/gI-05174/

3[V]駆動で1[MHz]だとアクティブ時で400[uA]程度、
CR2032が220[mAh]なので、常に動作していると550時間程度ね。
それでも23日ぐらい持つもんなんだね。

朝から打ち合わせとか、昼ごはんの時間帯に午後の準備あれこれとか。
事前に準備しとけばという話だけど、機材が今日届いたので仕方なし。
昼ごはんにありつけたのは午後の3時頃。まぁでも、充実していると楽しいよね。

あることでステッピングモータの制御プログラムを書いていました。
昨日になって「ステッピングモータの脱調が多くなったんだけど、どうしよう…？」という
話になりまして、急遽対応することになりました。

いろいろと検討をしていって、結果としては摩耗が進んで接地面積が増え抵抗が
増したのではないか、ということ。
多くの人は「え？たったそれだけのことで？」と思うかもしれないけど、
開発した本人にとっては「やっぱりそうなっちゃったか…」という感じでした。

というのも、実は今回のモータの機構、当初想定していたモータドライバと異なるものを
使っていたり、最終的な動きが初期の設計の段階で検討されていなかったりして、
結構ちぐはぐな状況で動いていたんです。
その事実には気づいていたんですが、僕の方に来た段階ではすでに出来上がった状態、
前に戻るにも戻れず、動かし方はほとんど決まっていたりで、仕様変更が難しかったため、
モータ自体の性能のぎりぎりのところでソフト的な調整をしていました。
最終的な動きを少し遅くしたり、余裕は少し持たせるようにしました。
でも、やっぱり無理なものは無理だったようです。まぁ当然かなぁ…。

今回のことから学ぶのは、アナログなものとはいえ、しっかりと机上計算をして余裕を見ておくこと。
データシート見れば特性は書いてあるので、これと合わせてちゃんと定格+ある程度の余裕で
所望の動作を見積もれることを確認しておくことが大切だと思う。

アタリマエのことだけど、以下のことは確認しよう：

• 必要なトルクは事前に計算をしておく。モータのトルクが十分足りることを確認する
• これに合うようにモータの種類、ドライバの電流値、電圧値を設定する
• ドライバの熱に対する変化を見て、燃えないか、高温時に電流を十分に流せるか、などを確認する
• 安全率（マージン）をある程度とって置くようにする

何か大学の時にロボット作った時にもこんな感じだったね…。
横着して計算しなかったのは今も昔も変わらずか。。。

最近はそう思えるようになってきたかも。
物がいくらあってもそれは一時的な幸福に過ぎず、
思い出という形になるほうが長期的な幸福なんだと思う。

何かついつい余計なものを買ってしまったり、
本当に必要かどうかわからないのに「ま、いっか」で
買ってしまったりするけど、良くないよね。

ただ、思い出を作ると言っても、年齢によってできるものだったり
できないものだったりすることがある。
できるうちにいろいろなことを体験・経験してみて、
素敵な思い出を作ると良さそうだよね。

これは面白い。
過去の台風情報と比べて、類似する台風の経路を表示したり、
ある月の雲の動きを動画で見られたり、「こんなのあったらいいな」的なものが揃ってる。

デジタル台風：台風画像と台風情報 - 国立情報学研究所
http://agora.ex.nii.ac.jp/digital-typhoon/

特に今年の台風19号は突然進路が変わったり、速度が早くなったりしていたけど、
これを見ると偏西風の影響を強く受けて、雲が散り散りになっていくことがわかるね。

ＪＲ東日本で非常ブレーキ不具合　山手線など１５４８両
http://www.asahi.com/articles/ASGB6764KGB6UTIL07W.html

理由を見てみると、

システムでは、電車の走行中に６０秒間、運転士がブレーキや汽笛などを動かさないと警告ブザーが鳴る。
さらに５秒間放置すると、「運転士に異常発生」と判断。非常ブレーキがかかるはずだが、
ＡＴＣ（自動列車制御装置）などにより速度が抑えられると、運転士が操作したものと誤って認識してしまうという。

ありがちだよなぁと思った。システムが複雑化してくると見落としがち。
まぁテスト仕様考えるときに、きちっと影響範囲が見えてればこういうミスも防げるだろうな。

でも、これ本当に見落としたのかな？
ATCで自動制御すればなんとかなるでしょ、と担当する人は思って、非常ブレーキを優先しなかったようにも見える。
優先度としては、ATCは人間より上、非常ブレーキは人間より下（人間の操作があれば動作しないという意味で）だと思うので、
ATCが優先されるのはそういうもんなんじゃとも思う。

Rails4以降、今まではscript以下にあったスクリプトがbin以下に移動されているようです。
また、gemから入るrailsコマンドはrails new専用になったとのこと。
結果として、bin以下のパスが通っていない時にrails serverを使用すると、rails newのusageが表示されてしまいます。
この辺りの話は、以下の記事に書いてありました。ありがとうございます。

Rails 4.0 と bundler install --binstubs について - willnet.in
http://www.willnet.in/82

この辺りの変更に関しては、railsのrelease noteを見ても記述が見当たらず。
railsの初期化の資料を見てみると、3系列と4系列で以下の1.3の記述が変わっている。これかな？

http://guides.rubyonrails.org/v4.1.6/initialization.html
http://guides.rubyonrails.org/v3.2.13/initialization.html

私の場合は、gitにコミットするときに「binはいらないよね…」と思ってこのフォルダを除外してしまったこと。
別のclone先で動かしても動かないのでおかしいなと思ったら、bin以下のファイルが足りていなかった。
binフォルダを追加して動かしてみて、無事動くことが確認できた。

報道発表資料 : 千代田区とコミュニティサイクルサービス「ちよくる」を開始 | お知らせ | NTTドコモ
https://www.nttdocomo.co.jp/info/news_release/2014/09/19_00.html

10月から千代田区でコミュニティサイクルサービス（要は無人のレンタルサイクル）が始まるらしい。
秋葉原のあたりもいくつかあるみたい。
買い物に使えると良いなぁと思ったけど、うちのすぐ近くにはなかった。残念。

ちょっと都内をぶらぶらしたいときに使ってみようか。
都内、あまり駐輪場がないのが気にはなるけど、隅田川沿いをサイクリングとかならありなのかな。

僕だけかもしれないけど、あるケースにおいてドモルガンの法則を使わないと間違えることがある。
例えば、緯度、経度が(135.5278526, 34.6416962) 以外 ある処理を行うとする。
ぱっと思いつくと以下の通りとなってしまう。

(lon != 135.5278526 && lat != 34.6416962)

でも何だか変だなと思って、ドモルガンの法則使って書き直すと以下のとおり。

!(lon == 135.5278526 && lat == 34.6416962)
=> (lon != 135.5278526 || lat != 34.6416962)

&&ではなく、||が正しい。
結局、「(135.5278526, 34.6416962)以外」という言葉が曲者で、

「緯度が135.5278526 かつ 経度が34.6416962 であるもの以外」
=> 「緯度が135.5278526でない または 経度が34.6416962ではない」

となるんだろうな。

おそらく、頭のなかの思考としては、緯度・経度が異なる集合に属するものという認識が薄いんだろうなぁ。
単なる数値として見てしまっている。

そもそも同じ集合だと仮定した場合、式としては A = a1 && A = a2 となり、これは常にfalseなのか。。。
やっぱり捉え方がナンカおかしいんだろうな。

第2回 システム系論文輪読会に参加してきました！
発表の内容などについては以下を参照 :

第2回 システム系論文輪読会
http://connpass.com/event/8493/

システム系と一概に言っても分野の幅が広く、DB、VM、GPUなどなど様々な話が聞けたのは良かったね。
話していただいている方もその分野に精通していて、わかりやすくかつ突っ込んだ話を聞くことができた。

僕自身としては、久しぶりに研究的な話を聞いて、面白いなぁと実感した時だったな。

ふと、N700系で静かな車両（＝モータ音や環境の騒音が少ない）のはどこかなと思った。

で、調べてみると1号車、16号車以外はモータを積んでいるとのこと。

新幹線N７００系で、最も磁励音（モーター音）のする車両は何号車でしょうか。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1430284669

ということは、最後尾の車両が一番静かということかな。

実際、名古屋への出張で普段とらない16号車の指定席だったんだけど、
なんかいつもより静かだなと思った（気のせいかもしれないけど）。

あ、でも、東京行きの場合は最後尾が1号車で、自由席になっちゃうのか…。
まぁ、また乗る機会があれば16号車に乗ってみよう。

今年は野菜の値段が高いそうな。
実際、売り場を見てるとレタスが350円とか、驚く値段が多い。
それだけ値段がしても、日照不足には変わりないので、
質は普段通りかそれより劣るぐらいとなってしまう。

そう思いながら、一つ一つ品定めしながら見てると、きのこ類とか加工品だったりとか、
気候条件に左右されづらいものばかり買ってることになったりね（笑）

64bitのアドレス空間を持つとあるシステム
以下のようなコードがあって、うまく動かないからなんでだろうなぁと思ってたら、
実はSIZEの値がオーバーフローしていたというオチ

#define SIZE (6*1024*1024*1024)

...

REG = SIZE / 8;

ふと思いつくアイディアがあると、微妙だよねって結論も多いと思う。

でも、よくよく考えてみると、単に自分で無理って思ってるだけだったり、
いくつかのアイディアの本質の部分は同じだったり、そんなことがある。
時には深く追求してみて、

・何がダメなのか？
・これを実現するための別の方法もないのか？
・別の視点で見てみたらどうか？

などなど、考えてみるのが大切なんだろうね。

データベースの構造とか思い浮かべていると、今のIntelのプロセッサがしっくりと来るよなと思う。
でも、画像処理とか並列演算系を考え始めるとベクトル演算できると良いよねってので、nVidiaのGPUとかがしっくりと来るよね。

メインのCPU + GPUで処理？ なんか無理矢理感があるよね。そう考えると量子コンピュータなのかな。
もっとうまいやり方があるんじゃないかなぁとか、そんなことを考えてると面白くなってくるよね。

任意文字列中の日付を探す方法、どうするのがスマートなんだろう？
いくつか決まりきったフォーマット（例えば、2014/08/26と2014年8月26日とか）を
正規表現に入れ込んで手当たり次第に調べていけば、確かにできる。

でも、これだとルールベースになってしまてt、ルールから外れたものは認識されない。
それよりも、正確性は落ちるものの、できるだけ多くのケースを網羅できる
（欲を言えばルールから外れていても認識できる）方法が何とかないかなぁ。

ひとつは隣接する4桁・2桁・2桁の数字列を探して、これを日付として
判断して、数値が有効な範囲に入っているかどうかで判断する方法がある。
ただ、もう一捻りやってうまい方法を見つけたいなぁ。