今までIH調理器だと思って使ってたものがあって、
何か火力弱いな〜、IHだからこんなもんなのか？と思ってた。
さすがに何か変だよなぁと思って、説明書見てみると
「光と熱で調理します」と書いてある。

それみて「ん…？」、そうかIHじゃなかったのか、とようやく気づいた。
1年ぐらい使ってて何かおかしいなぁとは思ったけど、今まで気づかなかったとは。

本来ならタイについてから空港で買うけど、
今回、ツアーでホテルまでの送迎付きになっているので、
空港に居る時間がほとんどないことが想定される。
ツーリスト用のものを市内で探すのも大変だし…と思って、
ちょっと悩んでいたら実は国内で売っていた！

Amazon.co.jp： タイで7日間3Gデータ通信&100B分の通話付き！AIS 1-2 Call 3G TRAVELLER Simカード
http://www.amazon.co.jp/dp/B00F93ZDL4

空港だと300Bぐらい（日本円で1000円ちょっと）なのでだいぶ割高だけど、
まぁいろいろと面倒ごと含めるといいや、と思ってこれを使うことにした。

いつも悩ましく思ってた、AndroidのButtonのOnClickListenerをどこに実装するか？

昔はAndroidのアプリを作ってた時は、Activityにimplements OnClickListenerしていた。
たぶん、Win32APIのメッセージループを連想してそうしてたのかな。

最近になって、サンプル眺めてると引数に無名クラスを渡すケースが
多いなぁと思って、どうするのが一般的なのか調べてみた。

Android - 美しいOnClickListenerの実装方法(を教えてください) - Qiita
http://qiita.com/t2low/items/8ac683c7ebf4b6dd1b41

自分で調べたわけではなく、すでに記事があったので参考に。
結局、他所から参照される余地をなくす、ミスを減らすという点で
引数に無名クラスを渡すケースが有利とのこと。なるほど。

個人的には、一つの関数の行数が多くなるから…と思って
嫌なんだけどなぁと思うんだけどね。

と思ってたら、もっと良い方法が先ほどのページに書いてあって、
Butter Kninfeなどを使うとアノテーションでOnClickの指定ができる。
おぉ、こりゃ便利。例えば、こんな感じ。

  @InjectView(R.id.button_login)
  Button login_button_;

  @OnClick(R.id.button_login)
  void onClickLoginButton() {
    String user  = text_user_.toString();
    String pass  = text_pass_.toString();
    ....

毎度忘れるのでメモ

Android Studio ショートカットキーリスト for Mac - Qiita
http://qiita.com/Tazake/items/5c725a8b68d13271d43d

いざ、一からハードウェア〜ソフトウェアまでのアーキテクチャを
考えようとすると、結構悩むことが多い。
レイヤーの積み重ねをして、各コンポーネントのやることを
小さくしていくことで問題の局所化をすれば、
まぁまぁそれなりのものはできてくるんだけど、
イマイチ綺麗ではないなぁ…と思ってしまう。

具体的な解放はともかくとして、一つ確実に言えることは
既存のソフトウェアアーキテクチャをよく観察しておくこと。
一から洗練されたものは難しいので、既存のアーキテクチャに
ちょっと付け足して工夫をしたりすることで、よりよいものを作ってく。
いろんなことに共通する考え方だろうね…。

そんなこんなで、今週一週間は悩んでいましたとさ。

生活の中で拍子抜けすることがあって、
気持ち的にざわついていたけど切り替えが大切だなと。
気分一新して、邁進していこう

いろいろと調べてみたので、頭の整理も兼ねたまとめ。

現在のLinuxの基本はプリエンプションありだけれども、クリティカルセクションの最中などは
常に特定の処理が走るため、必ずしも一定時間で応答がかえってくるとは限らない。
この点でLinuxにはリアルタイム性がないとなっている。

当然、Linuxも組み込み用途で使いたいという需要から、リアルタイム（RT）化するパッチが出ている。
それがPREEMPTRTのパッチ。
厳密なリアルタイム性を保証しているわけではないが、リアルタイムにできるだけ近いものになっている。
（いわゆるソフトリアルタイム）
この、PREEMPTRTのパッチが何をやっているかに関しては、以下のスライドの前半がわかりやすい。

http://events.linuxfoundation.org/sites/events/files/slides/rtmux_1.pdf

やっていることは、

• スピンロックをMutexに変更してプリエンプション可能にする
• クリティカルセクションの最中もプリエンプション可能にする
• Mutexはプライオリティの継承ができるようにする（これの意図がいまいちわかっていない）
• 割り込みはカーネルスレッドに割り当てて、プリエンプション可能にする

簡単に言うと、とにかくどこでもプリエンプション可能にして、処理をぶった斬れるようにすること。
Linuxの場合、どのプログラム（ドライバ）が何やっているかを気にしていると
キリがないので、どのプログラムが実行してようがとにかく実行権を取り上げる、って思想だと思う。

それ以上のリアルタイム性（いわゆるハードリアルタイム）が欲しい場合、
Xenomaiや別のOSを同時に動かすことなどがあげられる。

上場廃止決定後、29日、30日はストップ安でザラ場引け
SBIの場合、ストップ安（高）で終わった場合は、以下の配分方法になるとのこと。

株式のストップ配分方法は？
http://faq.sbisec.co.jp/faq_detail.html?id=10972

29日、30日ともに結構な確率だけど、出来高はあるので機会はあったみたい。
ただし、両日共に当たらず。

1月30日に東証からスカイマークの制限幅撤廃の通知。

東証 : スカイマーク（株）株式に係る呼値の制限値幅の撤廃について
http://www.tse.or.jp/news/20/150130_c.html

それにともなって、2月2日に32円で成立した。
この日の最高値が35円、終値が19円なので、成り行きで全部売っぱらうのが正解だったのかな。
（まだ、今日以降の取引次第ではあるけど…）

スカイマーク株、１９円に下落　値幅制限解除で取引成立：朝日新聞デジタル
http://www.asahi.com/articles/ASH2261YKH22ULFA02X.html?iref=comtop_list_biz_n02

被害がないといえば嘘になるけど、まぁまぁ想定出来うるリスクの中で対処できたので良かった
上場廃止になった企業がどうなるか、良い勉強になりましたよ。。。

エアバスはなぜスカイマークによるA380キャンセルで巨額の違約金を請求しようとしているのか？ - BusinessNewsline
http://www.businessnewsline.com/news/201501161234310000.html

そう、一度巨額な違約金を言ってしまうと、今後のビジネス展開に支障がでるんじゃ…と
思ってたんだけど、この記事見て納得。
A380のような大型機はあまり需要がなくて、その中でキャンセルしようとしてるから
エアバス側が回収に躍起になってるということなんだね。

14年ベストエアラインはキャセイ、スカイトラックス調査
http://www.travelvision.jp/news/detail.php?id=62562

あれ、全日空が全然見当たらない。。。
勝手な印象としては、JAL > ANAと思ってたけど、そうでもないのね。
国内線の航空券の価格からそういう印象が来てるのかもな…。

いくつかの航空会社で国がわからなかったものをあげてみた。
よく聞くけど、いつも「どこだろう？」と流してたんだな。。。

• キャセイパシフィック航空
  • 香港
• アシアナ航空
  • 韓国
• エバー航空
  • 台湾
• ヴァージンアトランティック航空
  • イギリス

バランスボールを会社で使っています。
今まで午前・午後のどちらかだけだったんですが、
最近ようやく一日中できるようになりました。
導入してからすでに半年近くになるので、ようやくといった感じ。
一日中やった場合の効果はどうなのかな？

どうやら、投稿されてもメールが来てなかった模様…。
コメントを今までに投稿した人に送るロジックはあったけど、
僕自身にくるロジックが抜けていた。。。

なんだろな、昼は包丁で千切りにしていたら、親指の関節を切ってしまい、
（そもそもちゃんとした持ち方していれば、そんなところ切るはずもないんだが…）

夜は鍋敷きの上においてあった鍋をコンロに移動して、火をつけてから
鍋敷きがくっついたままのことに気づいたり…。
（鍋敷きは焼けてしまってダメになりました…）

何か変な一日でした。

それ以外は、AR.DroneのSDKが気になって少し下調べしたり、
料理の科学的な裏付けが気になってこちらも調べてみたり、
資料を読んだりするのがほとんどだったかな。

服買うときは、ちょこちょこと買うのではなく、まとめて買ってしまうようにしている。
そのほうが、時間もかからないし、服全体の統一感とか組み合わせがやりやすいよね。

ここ1,2年はほとんど冬物を買ってなかったので、久しぶりに服を買いに行ってきました。
場所は酒々井のプレミアムアウトレット。東京駅からバスが出てて、片道1時間ぐらい。

最初はGarrettのポップコーン、酒々井は穴場のようで15分ぐらいで買えました。
その日、何度か店の前を通りかかって見てた感じ、必ず並ぶ必要はありそうだけど、
概ね15分ぐらいで買えそうな感じでした。東京駅で1時間、2時間待ちより良いよね…。

その後は服探し。いつも買う系統の店3店舗ぐらいを回って、目星をつけてささっと購入。
上下合わせて合計8点ぐらい購入。結構良いのが見つかって良かった。

ちょっと前までは家に帰って昼ごはんを食べていたけど、
それも移動するのが面倒だなと思い始めて、弁当を作って会社で食べてます。

弁当っても、手軽に済ませたいので、スープとおにぎり2つにしてます。
スープはAmazonの「THERMOS 真空断熱フードコンテナー 」ってのに入れて、
二日おきぐらいにレシピを変えたものを入れてます。
このフードコンテナだとかなり保温がきくので、その点も非常に良いね。

おにぎりはまだ試行錯誤中。
ほとんど力を入れずに握ると、ふっくらした感じに仕上るところまではできてきた。
ただ、味付けとか、ふっくらさ加減とか、まだまだ改良の余地はありそうなので、
毎日試行錯誤してます。

こうやって料理作ってると、いろいろと考えて改善できるところが多いので、
やっぱり楽しいなと思うね。

今日から本業に復帰
長い休みでよい気分転換になったと思う
やることもたくさんあるので、ちゃちゃっと終わらせてこう

読もうと思ったきっかけは、普段書くコードが他人から見て見にくいな、と思ったこと。
決して見せられないほどひどくは書かないけど、頭にスラスラと入ってくるぐらい良いコードを書けていないので、
この機会に見なおそうと思いました。

Amazon

http://www.amazon.co.jp/dp/4873115655

内容

タイトルの通り、コードをいかにしてより良いものにするかというがメインです。
コメントや変数名の付け方などの基本的なものから、
1関数1機能にすること、をどう徹底するかなど、ちょっと踏み入ったものまであります。
普段コードを書く人からすると、すでに身についているものも多いですが、
文章として書かれると、意外と知らず知らずにやっていたことが「そうなっていたのか」と納得できることもありました。

感想

僕としては、以下の内容が良かったです。

• コメント
  • 曖昧な代名詞は避ける。曖昧な部分を排除することで、よりコメントが読みやすくなる
• 変数
  • 説明変数・要約変数を用意して、処理フローや関数の引数をわかりやすくする
  • 例えば、関数の引数にbooleanを渡す場合は、その意味を表す変数で代入する。isforce = true; delete(“.”, isforce); など
  • 時間の変数などは、_msなど単位をつける
  • 他の意味と間違えられないように、変数名は何度も検討をする
  • 例えば、listのsizeを求める関数がある。この関数が要素を一つ一つカウントするのであれば、countとする方が良い。直感的に計算量が違うことがわかる
• 条件式
  • あまりにも大きな条件式ができてしまった場合、問題を一度整理してみる。複雑すぎるとバグのもととなる
• 関数
  • 無関係の下位問題は別の関数としてくくりだす
  • 関数内の各段落（コード単位）で一つのタスクを行う（実際に本の例を見るとわかりやすい）
• テスト
  • （行数が）最小のテストを作り、読みやすいテストにする。新しいコードを追加しときに、テストをしやすくなる

全然本の内容とは関係ないけど、本文中の以下の言葉も納得。

「エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。」

普段のコードにも取り入れてみて、より良いコードを書いていきたいね。

11月、12月と仕事がたてこんでいたこともあり、
年末年始休みと合わせて、今週もお休みをもらった。
普段時間取れなくて進められていなかったこととか、
こういう機会に進められて良い感じ。
明日もまたがんばろう！

あけましておめでとうございます。今年もよろしくお願いします！

年末から1週間ほどかけてAndroidのアプリケーションを作っていまして、
三が日も親戚周り以外はカタカタとコーディングをしています。
その傍ら、突然始めてみたSimcityが面白くて、アイテム作っては
市場で売ってお金を手に入れたりなど、まずまずはまっています。
まぁ、iPad版だとなのか、時間の流れが遅いので、そろそろ飽きそうですが…。

そんな感じで、今年も技術的な部分、それ以外の部分合わせて、
頑張っていきたいと思いますので、よろしくお願いいたします。
5年先、10年先に役に立つものをしっかりと考えてかないとね。

2014年もありがとうございました！ みなさまお世話になりました。

今年はいろいろと動きの多い、一年だったなと思います。
特に技術的な面だと、仕事でやってきたことがようやく形になってきました。
個人では「将来的にこういうものがあると良いのでは？」という長期的な視点で、やっていく方向性が決まってきました。
まだまだ学んだり、考えたりすることは多いですが、実際に形にできるようにがんばっていきます！

来年は（仕事も個人も）基本的な部分をおさえつつ、5年・10年先の未来がちゃんと描けるような基盤を作っていきます。
仕事はファームウェアやドライバの開発が一気に来るので、実装を頑張るというよりは、
道筋をしっかりと考えて、無理のない期間で終わらせられるようにやっていきたいです。
あと、個人的なところでも大きな節目となるので、そちらも進めていかないとな。

来年もがんばっていきます！