NOBODY:PLACE

「ルージュの伝言」ってなんで「魔女の宅急便」のOPテーマなんだろう

映画

もしかするとどこかに制作者の方のコメントがあるのかも知れないけど。

京都マラソン2013にエントリーしました！

「京都マラソン2013」は2013年3月10日開催、8月20日から応募受付開始 | mutter というわけで、エントリーしてきました。友人の東松君曰く、

「去年の倍率は3.3倍だったけど今年は知名度上がったからもっと上がるんちゃう？」

あー… 抽選に弱いことで定評のある僕なので…ますます自信がありません。そろそろこの辺で、フルマラソン走っておきたいと思ってるのですけどねえ。ってまぁ、ただフル走りたいだけならなにがしかあるんですけど。とりあえず、半年後の京都マラソンに向けて調整していかねば！

【Minecraft】各種Mod 1.3.2対応状況まとめ【メモ】

Minecraft

「バグ修正だけだから1.3.1と1.3.2で対応状況なんか変わらないだろう」と思っていたのですが、存外に動かない。なんだろう…ModLoader（もしくはForge Mod Loader）に対応バージョンのチェックがあるのかな…わかりませんが、自分的にちょっと混乱してきたので整理する目的で「1.3.2対応まとめ」としてまとめ直し。あ、今回から前提Modは「Minecraft Forge」だけになったら良いなあと思ってます。無理そうなら仕方ないですが。

[ExtJS4] コンストラクタ的な要素の呼ばれる順【メモ】

ただのメモです。

Controllerの場合

init

It is called before the Application’s launch function is executed so gives a hook point to run any code before your Viewport is created.

Viewportがインスタンス化する前に呼ばれます。

onLaunch

A template method like init, but called after the viewport is created. This is called after the launch method of Application is executed.

Viewportがインスタンス化された後に呼ばれます。

Componentの場合

initComponent

constructor

インスタンス化されるときに実行されます。2つはほぼ同時に実行されますが、中身が全く同じと言うことではないようです。詳細は以下のエントリ参照。 Extjs4 initComponentとconstructorの違い – 日々精進

createdFn

Optional callback to execute after the class is created, the execution scope of which (this) will be the newly created class itself.

Ext.defineの第3引数。そのクラスが生成されたあとに実行されるコールバック関数。「created」ってのはインスタンス化ではなくてファイルが読み込まれたとき…と言うような気がする（後述の実行順参照）

実行順例

Component: createdFn
Controller: init
Component: constructor
Component: initComponent
Application: launch
Controller: onLaunch

ややこしい…

【Review】「アサヒドライゼロ」缶半分までならドライの代わりになる

昼間からビールを飲むのが苦手です。あー…いや、嫌いとかなんとかじゃないんです。そうじゃなくてね、休日の昼間とか特に今夏だしビール飲みたくて飲みたくて仕方ないわけですが、僕、そこで飲むとダメなんですよ。昼間にビールを飲むと、あっという間に試合終了で眠たくなって寝ちゃったり、何にもする気が無くなってだらだらしちゃったりするわけです。したいこともしなくちゃいけないこともあるのに。ダメだこりゃ。そういうわけで個人的に控えてるわけです。ちくしょう。昼間から公園で子どもと遊びながらビール飲んでるタク…のひとがうらやましい。うらやましい。

【Tumblr Posts】 Tumblr 2012年7月まとめ【女の子】

2012年7月にTumblrでPostまたはReblogした画像のまとめ女の子編。

【読書感想文】藤村忠寿/嬉野雅道 / 人生に悩む人よ藤やん・うれしーの悩むだけ損!

この本は、電撃オンラインで好評連載中のコラム「藤やん・うれしーの悩むだけ損！」の書籍版。

システムを便利にすればするほど作業者の能力が劣化するというジレンマ

至極当然なのですけれどね。今現在、すべて頭で記憶しその記憶を元に手を動かしてしている作業があったとします。例えば特定のお客様を記憶しておき、そのお客様からの注文の場合には必ず領収書を封入するとか、昼間は受け取ってくれないことが多いので何も指定が無くても夜指定で出荷するとか。もっと単純に「今日のランチメニュー」がなにか把握するとか。こうした作業は、担当者が十分に優秀であり、かついつも通りのパフォーマンスを発揮できる状態であれば特に問題は起きませんが、どちらかが欠けた場合には必ずミスに結び付くため業務フロー上のリスクとなります。このリスクを減らすためには、自動化するなりリマインダ機能を付けるなりして人間が記憶しなくてはならないことを減らし、誰がやっても滞りなく作業できるような形へ持って行くことが必要です。業務フローの設計としてはそれで合格点であり、完了であり、計画通りに進めば確実に良い結果に到達するはずなのですが、機械とは違って人間相手の最適化ってのはなかなかそう上手くいきません。