( ・ω・)ノ<しすてむ開発。 このページをアンテナに追加 RSSフィード

2011-08-16 りはびり このエントリーを含むブックマーク このエントリーのブックマークコメント

ちょっとずつ復帰。φ(..)

2011-07-03 ようやく

[] 14:28 を含むブックマーク のブックマークコメント

ついったーを受信機として以外で使い始めた。

アプリ大杉

2011-05-29 フリーソフトのバグは犯罪に

[]ほんとに由々しき問題ですよ 09:38 ほんとに由々しき問題ですよを含むブックマーク ほんとに由々しき問題ですよのブックマークコメント

こちらの記事より

バグ放置が犯罪とな? 由々しき問題である

ソフトウェアとは人間の作業の集大成なのであり、人間が完璧でない以上、プログラムコードのどこかにバグが入り込むことを完全に排除することなど無理なのである

同感したうえで。

その過去を一切否定するような「バグ放置は犯罪」などと主張する政治家には去ってもらいたいし、「バグ放置を犯罪」とするような立法の動きには強く警戒する必要がある

まーじーでそんなことが!?

っと思って原文へ

ウイルス罪法案、バグ放置が提供罪に該当する事態は「ある」と法務省見解

大口委員:その説明がない場合を問題にしているわけでございますけども……。まあ、そういう事例もあると。それから、プログラム業界ではバグがつきものだと、バグのないプログラムはないと言われております。そして、たとえば無料プログラムですね、このフリーソフトウェアを公開したところ、重大なバグがあると、ユーザからですね、そういう声があった、それを無視してですね、そのプログラムを公開し続けた場合は、それを知った時点で少なくとも未必の故意があってですね提供罪が成立するという可能性があるのか、おうかがいしたいと思います

江田法務大臣:えー、あると思います

上記引用箇所以外も読んだら、テキトーに「ある」とか言ってんじゃねぇっと思った。


「ハイテク犯罪に対処するための刑事法の整備に関する要綱(骨子)」に関する意見書提出, 情報処理学会会長 益田隆司, 2004年2月2日 ”

1.攻撃を意図しない、ソフトウェアバグ仕様の不完全性を処罰対象としないこと(要綱第一)

優しさに涙した。


この論点について以前、法律家の方と話をしていたときに、「バグは直すべきじゃないの?」という発言が出てきて驚いたことがある。

べき論ではその通りだが、

「法の不備は直すべきじゃないの?」と同じレベルの話じゃね?


お偉いセンセー方がご大層な理由を申されると思いますが、

おそらくおんなじ理由でソフトウェアバグも容易には直らないのですよ。

[]この処罰話の心配事。 09:38 この処罰話の心配事。を含むブックマーク この処罰話の心配事。のブックマークコメント

こんなことが出来てしまう

フリーソフトいちゃもんのようなバグ報告を行う

   ↓

 作者:いちゃもんゆえに無視

   ↓

 タイーホ

この流れが現実となったら萎縮しまくるだろね。

少なくともボクはVectorに乗せてるフリーソフトの公開を全部やめる。

愉快犯だとしてもナンクセ怖いもん。

<本音>

当時はよかれと思って作ってのせたけど、結局自分で使うものは数限られるやん?

今使ってないものなんかしらんやん?

そこ突いてこられたらハラたつやん?


フリーソフトでこれなんだから、業者間なんてもっと大変なことになるだろなー

・これを背景に、業者間での不具合対応応酬が激化する

   ↓

 ってか委託元と委託先のパワーバランスが委託元の方にさらに強化される。

   ↓

 「これバグじゃねーの?」

 って言葉仕様変更しまくることに拍車がかかる。

   ↓

 以後、委託先は防御のための工数のために費用up


業者間の場合これが一概に悪いことかと言えば、不適正な安値が減るかもしれないあたりに

希望は見出せるだろうが、上がった分以上の要求を突きつけられるのでやっぱり悪いのだ。

2011-05-28 むずいぞ

[]ウォーターフォール 19:33 ウォーターフォールを含むブックマーク ウォーターフォールのブックマークコメント

実際にしみじみ実感してみると難しいねこの手法。


・後戻り不可

レビューによる修正は戻らずに流れながら吸収  ←←←

・ゆえにレビューもおざなりに

リソースとしてのコーダー&テスターどもは全員使うこと  ←←←

リソースとしてのコーダー&テスターどもをチームとして機能させることはナシ


アジャイルなあの瞬間にもどりたひ。。。

[]忙しいからこそやること 19:33 忙しいからこそやることを含むブックマーク 忙しいからこそやることのブックマークコメント

・「楽だから」という理由だけで作業は行わない。行わせない。

 → 禍根を多分に残すことになる

 ※ あと一言見出して、必然性が生まれるなら必然性を理由に楽をしようとは思ってる。

仕様の確認時には忘れていても経緯を踏まえる

 → 思いつきでやっても碌なことにはならない

 ※いついかなるときも確認は大事

・不備を見つけたら「本来あるべき姿」に向けて修正する

 → 目先の手間を惜しんで禍根を・・・(ry

・単純作業の依頼であっても「何のために」は明確にする

 → お願いされました〜実は間違ってました〜拡大してました〜となってからじゃもっと大変な目にあう

・以上、偶然による成功を一切排除して、仕事に向う


個人的に。

以上のことをしていると、しばしば面倒くさがりと衝突する。

理由を言えない人々と衝突する。

衝突しないまでもボクが絡むこともある*1

方法で意見が分かれても、そこは戦う。

相手を貶めずに戦う。

だって同じ目標に向っている仲間のはずだから。

ぼくらの向う先は同じ。

*1:『〜〜これって「こういうことをしたいからやる」ですよね?』ってな質問にYes or Noで答えられないとなんかあるんじゃないかと勘ぐるから絡んでしまうぼくがいる

2011-05-27 効率と実測値

[] 07:41 を含むブックマーク のブックマークコメント

ここの2人の人がいる。

プログラミング仕事を早く終わらせることが出来るのはどちらだろう。

・Aさん

 自分PCに向かいもくもくと作業を進行する人

・Bさん

 誰よりも仕様を聞きに行き、何度も確認しながら

 その合間に自分PCに向うような人

 

AさんがBさんより早く終わらせるための条件は限られている。

・作るべきものが見えている場合。

・Aさんが仕様確定者である場合。

などなど。


なぜか。

だいたいの現場の状況では、

両者のスタートラインが「仕様なんてよくわかっていません」から始まるため。

答えのない状況から模索することを要求されたとき、

ドキュメントを読み、結果を予測して作業をする

ドキュメントを読まず、結果を聞いて作業する

の、極端に分けた作業形態だと後者のほうが確実性が高い。


プログラミングの作業内訳を以下でわけるとすると

 (1) 考える時間・理解する時間

 (2) プログラム作る時間

 (3) 動作確認する時間

 (4) 修正する時間

後者は(2)〜(4)の繰り返し

前者は(1)〜(4)の繰り返し

となる。

単純に内訳を比較すると後者のほうが早そうですよ。

ミスを前提に再考慮した場合。

ミスの影響はどこにかかるかを考えたら、やっぱり同じになるでしょう。


だって人は勘違いするんだもん。

圧倒的にタイピングが早くても、作る方向を間違えていたら

軌道修正に時間かかるやん?

その時間ってまるでムダやん?

ってこってす。

[] 07:41 を含むブックマーク のブックマークコメント

大人になってから学んだこと。

・AとBとどちらをえらぶ?

みたいな二者択一を迫られたとき、答えはどちらでもなく

「AとBのいいとこ取り」なことがとても多い。


人はとっても欲張りだと思う。

gallugallu 2011/05/27 16:53 おいらは「湖の女神様理論」とか言ってますが。
女神様に「あなたが落とした斧は金の斧ですか? 銀の斧ですか?」と聞かれたら。「落としたのは鉄の斧だけどね。どうせなら金と銀の斧だけじゃなくて、女神様、あんた「も」欲しい!」って発言をすることを心がけてます(笑

とのとの 2011/05/28 08:28 そこで毎日花を捧げるくらいの行動ができると欲望がかなうかもしれないですねww