Hatena::ブログ(Diary)

やねうらお−ノーゲーム・ノーライフ このページをアンテナに追加 RSSフィード

tokutoku777 tokutoku777 ランキング
電王戦出場記念! 書籍化されたで! 監修したで!(`ω´) 絶版なってしもた Kindle版で復活!! 記事書いたで!
解析魔法少女美咲ちゃん マジカル・オープン!

YaneuLabs / やねうら王公式 / やねうらおにメール / twitter / プロフィール

 | 

2012-06-25 定期的に繰り返し実行する簡単ではないお仕事

[] 定期的に繰り返し実行する簡単ではないお仕事  定期的に繰り返し実行する簡単ではないお仕事を含むブックマーク  定期的に繰り返し実行する簡単ではないお仕事のブックマークコメント


いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。


最初とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム


今回は、これを「定期的に実行する機能が欲しい」と言われた。

この要望を実現するのがすこぶる難しかったんだ。


やねうらおってそんなプログラムすら書けないの?老害なの?」


とか言わないで欲しい。この問題、本当に難しいんだよ!


■ 1度目のひよこの全滅


まず、この要望に沿って、私の会社プログラマが当初、次のようなダイアログをつけたわけだ。


f:id:yaneurao:20120625134749p:image


繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やりのタスクが終わったあとに1440分待機するような動作になる。


ところが、このプログラムを使ったところ、ある日、ひよこの餌が出てこなくて、ひよこが全滅した。これにはお客さん、カンカンで…って、以前似たような話を書いたが*1、今回のケースは少し状況が違うので順番を追って書いていく。



あらかじめ予告しておくけど、今回はこのあとひよこは何度も全滅するんだぜ…。



さて、なぜ、最初ひよこが全滅したのかその原因を書いておこう。

次図をご覧の通り、お客さんのイメージでは24時間ごとに餌やりをして欲しかったわけだ。お客さんの言う「定期的に」と言うのは、「(餌やりのタイミングが)一定間隔になっていて、その間隔が調整できること」が本来の要件だった。


f:id:yaneurao:20120625134750p:image:w800


ところがこの要件が正しくヒアリング出来ていなくて弊社プログラマが次図のように実装してしまった。


f:id:yaneurao:20120625134751p:image:w800


こういう実装にしてしまうと「ひよこの餌やり」タスクが長引くと次の餌やりのタイミングが遅延してくる。間違った実装と言えるかも知れないが、後者のほうがお手軽な実装だし、タスクの内容によってはこれで事足りる場合もあるから、これがありえないような実装というわけでもないとは思う。しかし、今回のタスクはこの実装ではまずく結果としてひよこが全滅したということだ。


ここまではヒアリング不足、要求仕様の理解不足と言えると思う。


■ 2度目のひよこの全滅


そこで、上の前者の図(お客様要望)のようになるようにプログラムを修正した。UIはさきほどと同一である次のUIのままである


f:id:yaneurao:20120625134749p:image


しかし、ここでお客さんから待ったがかかった。


前回のことで煮え湯を飲まされたお客さんは「あと何分後にひよこの餌やりタスクが実行される予定なのか画面に表示させて欲しい」という追加仕様を出してきたのである


これは「さもありなん」という感じで、「(次のタスクの実行が)あと何分後」という表示があれば、次のタスクの実行がきちんと予定されていることが目で見てわかるし、また、その表示があれば上の後者の図ではなく前者の図のように実装されているかのチェックにもなる。なるほど、我々は最初からこのような表示をするべきだった。


ということで次図のようなダイアログに変更した。


f:id:yaneurao:20120625134752p:image


それで気分よく運用していたお客さんであったが、ある日、Windows UpdateがあってOS再起動した。これでひよこはまたもや全滅した。


今回製作しているアプリ自体はOS起動時に自動的に起動するようになっている。アプリが起動していなかったので餌やりタスクが実行されなかったとかではない。


またアプリは定期的に状態を保存して(シリアライズして)、起動時に状態を戻す(デシリアライズする)。ゆえに、UI上の数値などはアプリを終了〜再起動した場合も前回の状態のままであるアプリが設定されたUI上の数値を保存していなかったなどでもない。


それでは原因は何かと言うと、「次回の実行は XXXX分後です」の数字インターバルタイマーで定期的に(1分ごとに)1を引く実装になっており、ここが0になった時点で再度タスクが実行されるという実装にしてあった。


ところが、この実装だとアプリを終了させ、次回起動するまでの時間ノーカウントになってしまう。ゆえに、そのノーカウントである時間の分だけ餌やりのタイミングが遅れてしまうわけだ。


ついでに言えばWindows Updateのあと、お客さんとしてはまだ実行を開始する時間じゃないからしばらくパソコンの電源を切ったままにしていたらしいのだが…。


そこで正しい実装としては次のようになっているべきだったのだ。


(1) タスクを開始した時点で、

次回予定実行時刻 = タスク開始時刻 + 何分後に実行するのかのテキストボックスで設定された時間

とやって次回予定実行時刻というのを算出する。


(2) アプリ終了時にはこの次回実行時刻を保存しておき、アプリ起動時にはこの次回実行時刻を復元する。


(3) 「次回の実行は XXXX分後です」という表示は

XXXX = 次回予定実行時刻 − 現在時刻

とやって算出して表示するべきだし、XXXXが0を下回って、かつ、「繰り返し実行する」のチェックボックスにチェックが入っていれば、そのタイミングで再度タスクが実行される。


これで万事うまく行くように思えた。ところが…。


■ 3度目のひよこの全滅


このプログラムを長時間動作させているとまたもやひよこが全滅した。


お客さんは、昼の12:00から24時間ごとにタスクを実行するつもりで1440分と設定していた。


なのに次第にタスク開始時刻が日に日に数秒ずつずれて来て、長期間運用すると何時間も開始時刻が昼の12:00からずれてしまっていた。


これは、

(4) (3)でタスクが再実行されたとき

タスク開始時刻 = 現在時刻

としていたためだ。ここは、

タスク開始時刻 = 次回実行予定時刻

としなければタスク再実行〜現在時刻の取得までの分の誤差が累積してしまうというのが原因だった。


3度目のひよこの全滅を目の当たりにしたお客さんは「毎日昼の12時にひよこの餌をやって欲しいだけなのに、なんでこんな簡単なこと出来ないの?馬鹿なの?死ぬの?」と怒り心頭に発した。


さて、(4)の修正をして、さすがに三度目の正直、これでうまく行くだろうと安易に考えていたのだが…。


■ 4度目のひよこの全滅


お客さんは、タスクの開始時刻が12:00からずいぶんずれてしまったので、明日はまた12:00から開始したいとおっしゃるわけであるしか12:00にパソコンの前に正座して開始ボタンを押したくはないので、明日12:00に開始されるように設定できないのかと言われたわけだ。


ああ、わかりました。設定できるようにしましょう。

ということで、「次回の実行は XXXX分後です」と表示されていたXXXXの部分をテキストボックスにしてここの値を変更できるようにした。


f:id:yaneurao:20120625134753p:image


ここの値は自由に変更できるので残り時間明日12:00までの時間になるように設定してもらえればいいですよ、と。


そこでプログラムには次の処理を追加した。


(5) 「次回の実行は XXXX分後です」のXXXXの部分がユーザーによって変更された場合は、

次回実行予定時刻 = 現在時刻 + XXXX

と再計算する。


ところが、このようにアプリ仕様を変更したところ、ひよこがまた全滅した。お客さんが残り時間計算を間違えて設定してしまったからだ。


お客さんいわく「昼の12:00に実行したいだけであってそのために残り時間とか電卓計算したくないんだよ!全滅したひよこは弁償してもらいますからね!」だそうで、確かに使いにくいUIかも知れないが、そのUIでいいと言ったのもあんただし、計算を間違えたのはあんただろと思いながらも、やはりこのUIには問題があることは認めざるを得なかった。


すなわち、「次回実行は XXXX分後です」ではなく、最初から「次回の実行予定時刻は 2012/06/06 12:00:00です」のようにDateTimeが表示されているべきだったのだ。


そして、次回実行予定時刻を変更したいという要望に対しては、この値をDateTimePickerで選択できるようになっているべきだったのだ。


■ 5度目のひよこの全滅



以上の試行錯誤のすえ、我々が最終的に行き着いたUIは次のUIだった。


f:id:yaneurao:20120625144846p:image


なるほど、これは素晴らしい。


お客さんがある日このアプリの起動を忘れていて12:10に起動した場合も、次回実行予定時刻はその日の12:00になっているので、即座にタスクは開始されたし、(4)の処理により、次回実行予定時刻は翌日の12:00になった。翌日も12:00になればきちんと処理が開始される。


これにはお客さんも「大変素晴らしいアプリを作ってくれた!」と掌(てのひら)を返したように大喜び。


ところが、喜びも束の間。数日後にまたもやひよこが全滅したのだ。


そうだ。お客さんが、ある日、ひよこ部屋の掃除のためにその日は手動で餌をやったのだ。


アプリの起動を2日後に起動させられたこのアプリは、二日分のタスク連続して実行した。つまり通常の二倍の餌が1日で与えられたわけである


我々は、アプリが起動時に2つ以上のタスクが実行される予定になっているときは警告ダイアログを出すようにした。つまり次の条件である


(6) 警告ダイアログを出す条件

(次回実行予定時刻 <= 現在時刻 + XXXX * 2)

※ この条件を満たすとき連続して2つ以上のタスクが実行されることになるので。


■ 6度目のひよこの全滅


ある日、このお客さんの会社の重役の人がこのアプリを別PCにもインストールして別の施設のひよこの餌やりにも使うことにした。その人は、繰り返し設定として1440分後に実行するように設定した。


しかし「次回の実行予定時刻」を設定するのを忘れた。この項目、初回起動時には1900/01/01 00:00:00になっている。


この状態で実行するとタスクが2つ以上連続実行されるという警告ダイアログが出る。


そこで次回の実行予定時刻のところを次回に実行して欲しい明日12:00にセットした。


その結果…またもやひよこが全滅した。タスクが実行されなかったのだ。


そうだ。「次回の実行予定時刻」のところはタスクの実行を開始した瞬間にXXXXだけ加算される。つまり、この表示は「次回の実行予定時刻」だが、開始ボタンを押す前に設定すべき値は「(今回の)実行予定時刻」なのだ。いますぐ実行を開始したいなら現在時刻になっていなければならない。


この重役の人はカンカンで、「ここの値はアプリの初回起動時は現在時刻になっているべきではないのか」と言ってきた。なるほど、それもそうだ。


あと「次回の実行予定時刻」という表記も紛らわしい。

「2012/06/25 12:00:00 にひよこに餌をやるのを開始」というように変更した。


■ そして別のお客さんからクレームの嵐


これらの処理を入れたのちは長期間この仕様運用し、実績も出来、我々のUIプログラム完璧だと自負していた。


他のお客さんからも「定期的に実行したいんだけど」と言われれば、必ずこのUI提供することにした。


ところが、他のお客さんにとっては、これが非常にわかりづらいらしく「もっとシンプルにならないの?」「何分後に実行するかだけ設定できればそれでいいんだけど?馬鹿なの?死ぬの?」など歴史は繰り返すわけである


それらのお客さんもここに書いてきたような試行錯誤を経て、やがて理解はしてくださるわけだが、毎回毎回、「定期的に実行したいんだけど」と言われるごとにこれらの話を説明するのが面倒なのでこのように記事にまとめておく次第である


■ まとめ


「定期的にタスクを実行する」ためにはどういうUI提供し、どういう設計にすればいいのか、私が直面した課題を一通り書いた。これにより、簡単に出来そうな内容なのに一筋縄ではいかないことがはっきりわかったと思う。


私として、ここで書いたものが決定打だとは思っていないが、「タスクを定期実行したい」というありがちな要求仕様を満たす、一番シンプルUIでありロジックだと思っている。ただし、お客さんからの受けはあまりよろしくない。


これよりいいUI/設計があるならコメント欄で教えていただきたい。


■ 2012/6/25 21:00 追記


twitterのほうでmsmhrtさんから「ひよこの餌やりプログラム(仮)」のUI、こんな感じでいかがでしょうか? → http://goo.gl/m4Pxu  」と提案いただきました。*2


f:id:yaneurao:20120625210228p:image

これ、わかりやすいですね!こうやって皆さんの力で、「定期的に実行する」ためのスタンダードUI確立していくといいのですが。(他力本願)


■ 2012/6/25 21:30追記


はてブお勧めされた。面白そうなのであとで読む

パーセニーパーセニー 2012/06/25 16:43 田舎プログラマなので参考になるか判りませんが・・・

僕が作るなら最終形とほぼ同一の仕組みを作るかと思います。
ただ、Datetimeの生情報はお客様にとって判りづらい気もするので、日本語的な文面になるかと思いますが。

次の実行予定時刻〜などの情報は、Web系なら閲覧ページやTOPページ、またはデスクトップ上に出てくると判りやすいかな?

タスク管理を行う処理自体はさほど難しくないんですが、お客様のイメージとのすり合わせがピッタリ合うまでが・・・お客様との相性等々次第で、難しいですね。

yaneuraoyaneurao 2012/06/25 17:57
> 僕が作るなら最終形とほぼ同一の仕組みを作るかと思います。

一発で最終形に到達できる人は稀有な、優れたプログラマの人だと思います。
自信を持って良いのではないでしょうか。

「定期的に実行する」って簡単そうに見えて、結構、誰でもやってしまいがちな地雷がたくさんあるんだなーというのが私の印象でした。

こういう問題をきちんと処理する能力というのは純粋なプログラミング能力とはまた違った能力だと思うのですが、こういう部分ってこの手のいろんな問題に取り込んで経験を積んでいかなければならず、書籍なんかでは教えてくれない部分なのでなかなか経験値が上がりにくいですね。

通りすがり通りすがり 2012/06/25 19:13 個人的に、東芝のRDレコーダーの予約録画の思想が好きなので(古い型だとダビング作業を強制終了させてまで「予約録画を確実に実行」する)同じようなアプローチで出来ないでしょうか。それこそユーザーが設定し忘れていても、基本デフォルト設定を強制発動して、時刻設定なんかが狂ってる時はアプリ側で勝手にカウントダウンして強制的に餌やりしてしまうようなアプリです。掃除などで手動で止めるときは、パスワードを入力したり、何度も確認ダイアログが出たりひどくめんどくさいシステムにするのも忘れずに。餌をやり過ぎるより、やり忘れるほうが危機的な状態になるので、やり忘れるほうが難しいというめんどくさいアプリのほうが役に立たなでしょうか?

yaneuraoyaneurao 2012/06/25 19:23
そうですね。やり過ぎに対するペナルティがゼロに近い場合はおせっかいすぎる設計もアリだとは思います。

yaneuraoyaneurao 2012/06/25 19:25
今回の記事がまたもやGIGAZINEのヘッドラインニュースで紹介されていた。
http://gigazine.net/news/20120625-headline/

一つ前の記事も紹介されたばかりなのに…。
http://gigazine.net/news/20120620-headline/

二つ連続して取り上げてくれるだなんて、GIGAZINE大ちゅき!

ドラ焼きドラ焼き 2012/06/25 19:27 こんにちは、学生プログラマなんで実績も糞も無いので、生意気言ってたらすいません。
クライアントもほんとめんどくさいですね(笑)
ひよこの餌やりぐらい自分でやればいいじゃん!と思いました(笑)


というのは置いといて、UIですが間隔の設定も、○分だけにするよりは○時間○分としたほうがミスが減ると思います。
あとは、クライアント次第ですが、曜日指定なども必要な場面もでできそうですね(笑)

それにしてもえさやり機とはUSBで接続しているのでしょうか?

koba789koba789 2012/06/25 19:41 これと同じわかりづらさを経験したことがあると思ったら、同業者の cron でした。

hikipurohikipuro 2012/06/25 20:29 UIをタブブラウザのような構成にして、
・「毎週」「毎日」「毎時間」 というようなタブを作る
・「毎時間」の場合は"分"を選ぶセレクトボックスをタブ内に表示
・「毎日」の場合は"時"を選ぶセレクトボックスをタブ内に追加
・「毎週」の場合は"曜日"を選ぶセレクトボックスをタブ内に追加
(スケールの数が増えたら、スケールに応じたセレクトボックスを追加する)
・開始ボタンをタブの外に配置し、開始ボタンを押した後は、タブとその中身を Disable 表示にして触れないようにする
・停止ボタンを押すと触れるようにする (開始ボタンが押されたら、ラベルが「停止」になるという実装の方がボタンの個数が減って理解がしやすいと思います。)

というのはいかがでしょうか。

hikipurohikipuro 2012/06/25 20:31 すみません、上の感じだと2時間毎とかできないですねw

yaneuraoyaneurao 2012/06/25 20:33 ↑*2 Googleカレンダーがそんな感じですかね。( twitterで言及のありました→ http://twitpic.com/a0c5zm )

あれは、日にち単位でのスケジュール設定がしたい場合には結構優れたUIだと思います。

tsuyoshitsuyoshi 2012/06/25 22:48 古い考え持ちですが

んー、なんというか仕様レベルでの意見の擦り合せが、まずできてなかったんじゃないか、という気がどうしてもしてしまう。

固い開発なら仕様の洗い出しが重要になるんだし、そこで出せない(出しきれなかった)仕様についてはサポートできんと事前に強く念を押せる環境(というか立場)を持てないと厳しそう。

アジャイル的というか改善を繰り返すなら影響の少いテストベッドで改善を素早く繰り返すようにしないと被害がでちゃう。

---
この状況でどういうUI/動作になる、っていう話も、見えてない周辺の状況でさらに色々変りそうだし、なんとも言えないなぁ...(状況読む力がたりないな > 自分)

とりあえずとりあえず 2012/06/25 23:53 確認の意味で、あなたも含んだ両者に餌やり終わったらメールもらえるようにすればいいのでは?

t_tutiyat_tutiya 2012/06/26 00:07  msmhrtさん版のUIを見ると、「定期的に実行する」というシンプルな問題領域でさえ、汎用UIの設計が如何に困難かが分かって面白いですね。
 警告の意図が不明瞭なので(きっと、この警告は見てる人にスルーされる)、「次回給餌時刻は、指定された繰り返し間隔より[長く|短く]設定されています」と付記したらどうでしょう。
 あと、「前回の給餌時刻を修正する」というのは、意図は分かりますが、実際に行われた「前回の給餌時刻」と、見た目上の「前回の給餌時刻」が不一致になるのは分かりにくいですね(餌やりログを残す場合にも変な事になりそう)。

Ta(ryTa(ry 2012/06/26 02:35 なにか1秒毎にカウントダウンしてるものが数字を1つ飛ばしてカウントダウンしても気にしない

へぇ〜へぇ〜 2012/06/26 08:48 面白いですね。悪い意味じゃなくて、ソフト屋さんの発想が面白いです。

私、元々ハード屋で今はサーバ屋(ネットワーク屋)ですが、サーバ屋的には「何分後」といった「間隔」ありきという発想はしないです。常に「時刻」という絶対的な基準を基にしますね。
まぁ、元ハード屋としては一つ一つクロックを数えて・・・という間隔の考え方はありますから、そこから今回の課題で言えば「間隔」を補足します。これ、純粋なサーバ屋さんには無い考え方です。

karmenkarmen 2012/06/26 10:34 http://www.atmarkit.co.jp/fwin2k/win2ktips/335tasksched/tasksched.html
要件を満たせるかどうかはさておき、タスクスケジューラが標準で付いてますヨット。

toctoc 2012/06/26 10:38 同じような経験あります。
このケースは時刻表示が日本標準時だけですが、様々なタイムゾーンを考慮するUIが必要になったりするともっと混乱します。

Error401Error401 2012/06/26 12:44 うーん、「定期的に実行するタスク」のUIの見本として、何故最初にWindows等のタスクスケジューラやUnixのcronを思い浮かべなかったのかが謎です。そうすれば、最初から最終形に近いUIや機能が実現できてたと思います。
「定期的に実行するタスク」の要件として、アプリケーションの再起動はもちろんのこと、OSのリブートも越えて「定期的」になるよう実装すべきだということは常識な感じなんですが、そうでもないんでしょうか。

yaneuraoyaneurao 2012/06/26 15:18 ↑*1,↑*3
> そうすれば、最初から最終形に近いUIや機能が実現できてたと思います。

当初は問題の複雑さを理解していなかったので、「こんなものぐらい簡単だろう」という気持ちがあって何も考えず自前実装の道を取りました。

あと、本文の例では24時間の定期的な実行(≒定時実行)ですが、実際はここは23時間とか22時間とかかも知れないのでタスクスケジューラやcronはあまり参考にならないと私が思ったため、参考にしませんでした。

それから、タスクスケジューラやcronは
・ntpで時刻合わせが起きて時刻が少し巻き戻った場合、同じタスクが二度実行されないか
・ntpで時刻合わせが起きて時刻が少し進んだ場合、タスクが実行されなかったりすることはないのか
・PCがN日電源がONにならなかった場合、未消化のタスクがどう実行されるか
・PCがONになった瞬間に実行予定時刻が過ぎていた場合、そのタスクはどうなるのか
など、やはり今回の記事と同じ問題を孕んでいると私は思うのです。(そもそもそういう問題があること自体が当初は気づいていなかったわけですが…)

anonymousanonymous 2012/06/26 18:36 3度目(1度目も?)の奴はゲームで使うFPS管理タイマの実装でもよくあるトラブルのような気がするんですが、ゲームプログラミング本でそのあたり言及してませんでしたっけ?

↑*5
>常に「時刻」という絶対的な基準を基にします
ソフト屋でも時刻を使いたがる人は少なくないというか、数時間を超える計測で(しかもトラブル発生後の修正でも)間隔基準の思考を続けてたらソフト屋にも頭が固いと言われるんじゃないかと思います。

ii 2012/06/26 19:21 長期間でタスクをリピートするのであれば、cron的な方針でいくと思います。
実行ログを取っておいてダブリや漏れを減らす方向で。
実行中やログ書き換え中に吹き飛んだ場合とか、えさやり機械がエラー投げ返した場合とか、例外の複合とか全部フォローするのは難しいので、予算とご相談ということで。
あと、サーバのリソースが枯渇していて想定する時間内にバッチが終わらないと結構悲劇的なことになりますね。
金融系で定期的にトラブルが起きてたはず。

asdfasdf 2012/06/27 12:09 > ntpで時刻合わせが起きて時刻が少し巻き戻った場合、同じタスクが二度実行されないか
> ntpで時刻合わせが起きて時刻が少し進んだ場合、タスクが実行されなかったりすることはないのか
> PCがN日電源がONにならなかった場合、未消化のタスクがどう実行されるか
anacronというのがあってですね、、、と言いたくなります...
http://linux.die.net/man/8/anacron
anacronでは連続餌やりの禁止はしませんが、こういうのを知っていれば「給餌時刻にPCに電源が入っていなかったらどうします?」ぐらいの質問はできると思います。

> そうだ。お客さんが、ある日、ひよこ部屋の掃除のためにその日は手動で餌をやったのだ。
鉄道事故が信号の手動扱い時に起きやすいように、手動と自動の切り替えは難しい。要件がタスクスケジューリングなら、一定時間が経ったら済んだことにするでも良いけど、他の要件なら「餌をやったことにする」ボタンをつける。でもできれば付けたくない。絶対押し忘れるから。

ところで、日本ではないですが、冬時間→夏時間、夏時間→冬時間の切り替わりでひよこを全滅させる人もいるそうです。(切り替わる時間が夜中の12時ではないというのが罠)

asdfasdf 2012/06/27 12:45 anacronをそのまま使うことはできないが、連続餌やりの禁止はしないためというのはおかしかった。

yaneuraoyaneurao 2012/06/27 12:58 ↑*2
> こういうのを知っていれば「給餌時刻にPCに電源が入っていなかったらどうします?」ぐらいの質問はできると思います。

anacronは知りませんでした。なるほどですね…。

まあ…この手の問題って、自分が実際に直面してみるまでは「XXXぐらい簡単だろう」とかナメてかかってるところがあって、なかなか他のツールの実装状況を調べたりしないんですよね。「XXXは難しい」という事前知識だけでもあると違うと思うのですが。

Ta(ryTa(ry 2012/06/28 00:52 ↑*2
DSTといえばどちらの切り替わりも「午前2時」だから重複する1時間と失われる1時間が生じるなんてものがあって困った。
isDstも記録しておかないと重複する1時間からUNIX Epochなどに変換出来なくなっちゃって。

kawakawa 2012/06/28 17:56 「ライト、ついてますか」もオススメの本です

通りすがり通りすがり 2012/06/30 10:52 UIの問題なのかなぁ…
ミスを犯す人間がミスを犯さずに設定し続けないとひよこが全滅するのが問題では。
餌をやらない条件を決め、それ以外は必ず餌をやればよかったのでは。
さらに機構部にも各種センサーを取り付け故障検知したり、フェールセーフの考えで異常時に縮退運転したり、色々できそうですが…

yaneuraoyaneurao 2012/06/30 17:23 ↑*1
> さらに機構部にも各種センサーを取り付け故障検知したり、フェールセーフの考えで異常時に縮退運転したり、色々できそうですが…

例えば予算が3000円でそのようなセンサーを買って設置してそれを検知して対処するプログラムを書くことが出来ますでしょうか。限られた予算、限られた作業工数のなかで現実レベルで通用するソリューションを提供していかなければならないのです。

100%確実である100万円の製品より、99%正しく動く1万円の製品のほうが求められることは現実世界ではよくあることなのです。

ぽぺぽぺ 2012/07/01 01:39 実際の業務をかなり抽象化・変更して公開されていると思うんですけど、どの分野の仕事だったのか、聞いてみたいなーなんて(チラチラ

うちの会社だと、お客様と瑕疵担保で問題になった場合は、やっぱり仕様書に書いてあるかどうかだけが争点になるですが、なかなかそういうのはお付き合いとかがあるから難しいんですかねー。
こー、99%動く1万円の製品作るお仕事って、すごくよく言われて、引き合いも多いんですが、イバラな道って分かってるので、うちの会社は断ったりすることが多いんですよー。そんな仕事やっていらっしゃるのかー、すごい技術力ある会社だなー、とか思ってしまったですよ。

akirameiakiramei 2012/07/01 14:59 担当したプログラマさんが画面(UI)から作り始めたのが問題だった気がします。間隔設定時にスケジュールが決まるか、実行中に変わっていくか仕様確認して最初に決まるならその時点でタイムテーブルを作ってしまう方が堅い気がします。実行時の処理はシンプルが良いのでデータに仕事を押し付けられるならそうするのが楽かなー

Ta(ryTa(ry 2012/07/08 15:52 この前のうるう秒でもやっぱりひよこは全滅だったの?
ひよこが弱過ぎない?

nucnuc 2012/07/13 00:39 どうもお久しぶりです。
もう少し広げると、これは、制約を満たしたまま、好みの動作をさせるというものなので、難しいのでしょうね。
なので、制約の中身を UI に含めようとする追記の方法は正攻法だと思います。

yuayua 2012/09/05 18:41 大切なのは一番マズい事が何かを理解することなのかな。(この場合はひよこが死ぬこと)
ヒアリングの際に何時間餌をやらなかったら死ぬの?と聞けばいいのかしら。
一番マズい事さえ回避できれば、後は運用なりなんなりで回避できることは多いと思う。

 | 

人気blogランキング tokutoku777
1900 | 01 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 06 | 08 | 10 | 11 | 12 |
2015 | 01 | 02 |


Microsoft MVP
Microsoft MVP Visual C# 2006.07-2011.06