Hubotでコマンドの引数を省略可とする場合の注意

module.exports = (robot) ->

  # コマンド受け付け
    # 引数1: サブコマンド
    # 引数2: 非負整数
    # 引数3: 非負整数または非負小数
  robot.respond /([a-zA-Z]+) ([a-zA-Z_]+) ([0-9]+) ([0-9\.]+)/i, (msg) ->
    cmd = msg.match[1]
    type = msg.match[2]
    qty = msg.match[3]
    avept = msg.match[4]
    switch cmd.toLowerCase()
      # 作業種別指定・点数指定・平均pt指定の引き合い
      when 'inq'
        # 引き合い（今発注、今入稿）に対する最早予想納品時刻を算出
        typeRedmine = typeHubot2Redmine type
        etd = calcEtd typeRedmine, qty * avept, new Date()
        typeJa = typeHubot2Ja type
        msg.send "#{String.fromCharCode(0x16)}#{typeJa}#{qty}点（平均#{avept}pt）を今発注、今入稿していただくと最早予想納品時刻は#{etd}です。" # 反転表示

のようなコマンドをHubotで実装した。

たとえば
cdr inq cut 100 1.5
とIRCで打つと、この.coffee内のサブルーチンで実装された生産スケジューラが計算を行い、最早予想納品時刻を回答するというしくみだ。なお、cdrはこれまでにも出ている我らがHubotの名前である。またcutは「切り抜き」という当社のひとつの作業種別を指す。

このとき、最後の引数の+を*に変えても、その引数は省略可能とはならないことに注意が必要だとおもった。すなわちmsg.matchに対する*はあまり意味がない。引数を省略可としたければ、もうひとつrobot.respondを書く必要がある。

※なお、上のスクリプト中、typeHubot2RedmineはIRCで打たれた作業種別文字列をRedmine用に正規化するサブルーチン、typeHubot2Jaは同じく日本語への変換ルーチンである。calcEtdは生産スケジューラが最早予想納品時刻を回答するサブルーチンであり、その最終引数に予約入稿日時を指定することができるようになっている。スクリプトは今入稿の場合である。

Moore and Hodgson Algorithmって、これ実装してますとはなかなか公言しづらいよね

少数のお客様に多大な納期遅れを集中させることにより大多数のお客様を納期遅れにしない手法。

各種のジョブ順序決定法の比較と演習
http://www.oit.ac.jp/dim/~honiden/Exercise/Scheduling/Sch_3.pdf
http://www.mi.s.osakafu-u.ac.jp/~hojo/lecture/jugyo7.pdf
http://www.mi.s.osakafu-u.ac.jp/~hojo/lecture/jugyo8-ans.pdf

ちなみに、より多くのお客様に納期遅れを薄く広げるのは、このサンプルによれば単純EDD法。

貴女はどちらを選びますか？

（もちろん、納期遅れを発生させないマネジメントをするべきですが）

Which method should 
I implement in our system?

生産計画法について勉強中…

誰もが必要とすることなのに、意外と、決め手となる理論や解法はなく、みんな苦労してるんだなぁ、というのが率直な感想。
自社ではどうする、も含めてメモってみた。

○APS=Advanced Planning and Scheduling（事実上、生産スケジューラのマーケティング用語）

http://monoist.atmarkit.co.jp/mn/articles/0901/23/news132_2.html
オーダーが出発点（インプット）だからプル生産向き
cf. MRPは材料供給と同期して製造指示をリリースする考え方が根底にあるから、プル型の製造工程コントロールとは折り合いが悪い

○生産座席予約

http://www2.odn.ne.jp/scheduling/SCM/Onepoin6.html#label00004
ラフカット能力計画に基づく将来の生産能力（capaticy）を、各時刻に対して、いくつかの基本モデルベースについて「この基本モデルベースからできる最終製品をご発注の場合には何個できる」という数量換算（時間でなく）の形で社外に開示し、それに対して「予約」という法的にあいまい（日本的）なアポを受け付ける。その予約をもとに最終製品品目を確定させ生産計画をアウトプットする。
cf. MRP IIのATP（Available to Promise）では逆に、最終製品生産計画をもとに、引き合いに対し数量・納期回答する。生産能力を社外に開示しない。

○作業負荷のフォワード展開

http://ci.nii.ac.jp/els/110003423442.pdf?id=ART0003956455&type=pdf&lang=jp&host=cinii&order_no=&ppv_type=0&lang_sw=&no=1414977177&cp=
時刻0（現在）から始まる各時点について順に、最遅開始時刻（工程が1つしかない仕事の場合には、納期から所要時間を引いた時刻=最小slack法だろう）が最も早い作業を優先して割り当てるようスケジュールしていく。（PERT山崩し法=PERT/Manpower）
ある時点において、もし割り当てることができる作業がなければ、1つ後の時刻について同様の操作を繰り返す。
cf. 納期が最も早い作業を優先するD.DATE法

○作業負荷のバックワード展開

フォワード展開の逆のアルゴリズムで良いのだろう：
工程が1つしかない仕事の場合：
すべての仕事の納期のうち最も遅い納期時刻tmaxから遡る各時点について順に、納期が最も遅い仕事を優先して割り当てていく。
ある時点において、もし割り当てることができる作業がなければ、1つ前の時刻について同様の操作を繰り返す。
結果、いずれかの仕事の開始時刻がその入稿時刻か現在より前と算出された場合、その仕事はこのままでは納期に間に合わないことを意味する。

○納期回答法

既存のすべての仕事をバックワード展開で割り当てたのち、問い合わせの仕事をフォワード展開でそこへ追加割り当てし、その算出された終了時刻を回答納期とする。

スレイリスとカンボジア大六のこれまでを振り返る（やや長文です…）

スレイリスが入社したのは2009年11月19日だが、
社長廣田に初めて会ったのは2010年3月5日だ。
スレイリスは僕の面接を経ずに採用された唯一の社員だ。
なぜなら廣田は当時ベトナムに5ヶ月カンヅメになっていたからだ。
欠員補充のため、妻が近所から見つけてきたのがスレイリスだった。
そんな所にも、この世の縁というものを感じずにはいられない。

カンボジア大六は2009年8月に社員8名で操業を開始した。
4名は日本語学科新卒のプノ大生様。
もう4名は日本語のできない近所の若者だったが、それでも大卒だった。
そんな所へ入社したスレイリスは、まだ高校生の歳の女子であった。
男女比は男6人、女2人だった。
自分はずっとこの会社の下っ端でやっていくんだろう…。
そうスレイリスが思っていたであろうことは想像に難くない。

しかしスレイリスは、会社の生産性トップに躍り出た。
品質管理責任者・生産管理責任者の任に就いた。
ある種のトレースの技能は、彼女だけが身に付けていた。
DTPの技能も、誰より早く身に付けた。
持ち前の明るさで職場のムードメーカーになった。
決めの問題をサバサバと決めていく態度で自然に職場のリーダーになった。
僕がお客さんからのお土産を社員に配る時も、スレイリスに託すのが常となった。
新たな制度を導入する時も、彼女の率直な反応を見ながらできたから安心できた。
上記の責任者への任命は、こうしたことの追認にすぎなかった。
スレイリスは、DTP生産管理責任者への任命も間近に控えていた。
増えていく後輩社員たちにも、技能をよろこんで指導した。
これらはすべて、スレイリスの資質と頑張りと人格の賜に他ならない。

スレイリスは、多くの後輩社員に対し、働き方・学び方・教え方の模範となった。
どんなに働き者でも、入った職場の先輩が怠け者なら、怠けてしまうだろう。
どんなに学ぶ意識が高い者でも、入った職場の先輩の意識が低ければ、怠けてしまうだろう。
どんなに教え好きな者でも、入った職場の先輩が教え好きでなければ、怠けてしまうだろう。
しかしこの職場には、スレイリスという模範があった。
だからこそ、後輩社員の働き者や、学ぶ意識が高い者や、教え好きな者が、それを発揮できた。
そうでない者がおのずと弾き出される空気とサイクルが出来上がった。
そうして会社は精鋭集団となった。

しかし会社の制度が悪ければ、どうだったろうか。
彼女ほどの人間であっても、いまだに一介の工員だったであろう。
大卒だとか日本語できるからという理由だけで自分より上にいる能力低い人間の下で。
その点に秘かに誇りも感じている。

原則として日本語社員や大卒社員を上に立てない。
この方針は創業当初から胸に描いていた。
制度設計もそのように行なった。
理由は、メリットがなくデメリットのみ多いことをあちこちで目にしてきたからだ。
しかし、では上に立てるに足る人間が他にいるのか。

いる、ということを最初に証明してくれたのはスレイリスだった。
彼女はぐんぐん伸びていった。
一方で、日本語社員も、大卒社員も、どんどん辞めていった。
会社が彼女のおかげで今あるというのは決して僕の中では誇張ではない。

スレイリスがせっかくここまで引き上げてくれたこの職場だ。
僕の職場と思えば、弱気になることもある。
だが、スレイリスが作った職場と認識するならば、どうだろうか。
そうならば、そう簡単に諦める権利は、僕にはないのではないか。
スレイリスが築いたこの職場をさらに発展させていく。
そうでなければ、スレイリスに対して、失礼ではないか。

社員が亡くなりました

当社カンボジア大六の社員で、DTPチームの最古参社員であるプロム=スレイリスが、今朝交通事故で亡くなったとの報を受けました。

数ヶ月前に結婚式を挙げた新婚女性でした。

ご冥福をお祈り致します。

理不尽です。

カッコつけないことがカッコいいと考えてるプログラマの痛さ

Redmineのプログラムに手を入れるようになって知ったのだが、Rubyというのは関数であれサブルーチンであれ呼び出しに()つけなくていい言語らしい。

で、HubotのためにCoffeeScriptをチョボチョボと書いていますが、この糖衣言語はRubyプログラマに好かれているらしく、そのせいか同様に()つけなくていい。

そりゃ確かに()は打つのめんどいよねえ。わかるよ～。ということで僕も倣ってみた。
これがほんとのカッコつけないコーディングスタイルである。

だけど、メソッドチェーンとか関数入れ子のときは引数の具合によっては結局()つけなきゃいけない。
単純に引数ないときもつけなきゃいけない。
ぐにゅ。
プログラムが複雑になってきたら、これがバグの温床となっている気がする今日このごろである。
↑などと書く理由は、ご明察のとおり、数日前にそこでみずから実際にハマったからである。初心者さんホイホイの穴へ見事にいらっしゃ～いなカンジ！

カッコいかに付けないかを競うプログラマーとかいそうで、いたら痛い。
んなことより、プログラムが確実に動くことや、後で見やすいことを目指せよとおもう。

むかし業務でげしげし書いていたVisual Basicでは、関数には()必須で、サブルーチンには()つけないでいいことになっていた。たしかに、サブルーチン（としてプロシージャを呼び出す）ならばメソッドチェーンとか関数入れ子はありえないわけで、実は最も合理的な言語仕様かもしれない。

CoffeeScriptで引数ないときに()つけないといけないのは、そうしないと関数というオブジェクトを指すことになってしまうからだが、人間としたら、俺が動詞1個発したら、そこは素直に命令文と受け止めてくれよとおもうのが人情ではないだろうか。

「その動詞というオブジェクトですね！」
とか、
「その動詞への参照ですね！」
とか、
「その動詞へのポインタですね！」
なんてシチめんどくさい答え返すヤツは、現場で生き残れないのではないだろうか。

"Freeze!"
と言われて、
「はい、ご注文のfreezeという動詞への参照をご用意しました。お持ち帰りですか？ こちらでお召し上がりになりますか？」
などと答えるヤツは、俺だったら撃ってしまいたい。

その動詞による命令よりも、その動詞というオブジェクトを指すほうが、より抽象的な、間接的な伝達内容なのだから、符号化理論的に言って、より表記が複雑であるべきだ。C#はそのようになっている。

逆になっているのは僭越だと個人的に感じる。

などと、JavaScriptでサブルーチンから()を取ってしまってコンパイルエラー出した日曜の昼下がりにつらつら想うのでありました。

クアラルンプール都心で手榴弾爆発、シンガポール人・タイ人・中国人含む14名死傷

「しばらくブキ=ビンタンへは行きたくない」という外国人たちの声を報じるニュースです。

プノンペンですらこれほどの事件は2001年頃を最後に起こっていないとおもいます。

クアラルンプールへはトランジット以外で行ったことがありませんが、非常に安全な街という印象があったので驚きです。