面倒くさい作りにしたせいで誤った使用法が広がったならそれは設計に問題がある
この機械ボタン押し続けな動かんな。せや！こうやったら押しっぱなしにできるで。生活の知恵や→こうして重大事故が起きる - Togetter フォロー・ブクマ外からクソリプ失礼します。 フールプルーフ機構を回避した結果、重大な事故が起き、更にはその回避方法によってそれが悪化するというシチュエーションについて話す場であるという前提のもとに、フールプルーフ機構の設計自体に問題がないかを設計者は考えるべきではないかという問題定義をさせて頂きます。 まず前提として、フールプルーフ・フェイルセーフを搭載しようとする判断自体は極めて正しいと思っております。 使用者に対して「完全に説明書を読み込み常に無限大の集中力を発揮すること」を求める設計は双方完全合意の極めて特別な場合以外は推奨されない設計であり、もし作る側が使用者に対してこのようなことを何の相談もなしに安易に求めるのならばそれはモノづくりとしては不誠
)
リファクタリング (プログラミング) - Wikipedia
この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2020年10月） この記事で示されている出典について、該当する記述が具体的にその文献の何ページあるいはどの章節にあるのか、特定が求められています。ご存知の方は加筆をお願いします。（2014年4月） リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。 リファクタリング登場の経緯と目的[編集] リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手
なぜHaskellを学ぶと良いか - Qiita
なぜこれを書くのか 私がQiitaに投稿した記事を見た方から、メールが届きました。 プログラミング言語のHaskellを勉強し始めたものの、難しくてやめようかと考えているそうです。 その気持ちも非常によく分かります。 すごいH本が出版されてから年月も経ち、それなりに勉強しやすくなったとはいえ、お世辞にもHaskellを学ぶ環境が整っているとは言えません。 私はHaskellで製品開発をする会社を保守運用していたことがあり、また自分自身もHaskellでプログラムを書いています。 また、Haskellを普及させるべく、「こわくないHaskell入門」という記事を書いたこともあります。 これらの経験を踏まえ、この機会にあらためて「なぜHaskellを学ぶと良いか」についてまとめたいと思い立ちました。 Haskellについてまだよく知らない方が、入り口として読める内容を目的としているので、できる
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
KISSの原則 - Wikipedia
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。 由来[編集] この言葉は、ロッキードスカンクワークスの技術者のケリー・ジョンソン（1910-1990）によって造られた。 この言葉は、一般には Keep it simple, stupid.（シンプルにしておけ！この間抜け） と解釈されるが、ジョンソン自身は「simple」
公差に対する思い込み
公差設計をしていく上で身に付けておくべき知識は幅広い。ここでは，中でも基本的な知識について解説していきたい。公差を勉強し始めたばかりの技術者だけでなく，公差の基本知識は十分に持っていると自負している技術者も，あらためて読んでみてほしい。当たり前だと思っていたことでも，実はある一面しかとらえていなかったケースがあるかもしれない。 緩めても安くならない？ 公差を厳しくすれば製造コストが高まり，公差を緩めれば低くなる─。公差を考えるときの基本はその通りだが，実は逆の場合もある。工程能力に余裕があるなら，公差を変えてもコストは変わらないこともある。 例えば，公差が緩すぎると加工は楽になるが，後工程でトラブルが発生しやすい（図1の上）。組立工程に投入する前の部品を測定してランク分けする必要が生じたり，作業者が現場でトライ・アンド・エラーでぴったりはまる部品の組み合わせを探ったりする事態を招き，思わぬ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードをどまんなかに据えた設計アプローチ - Speaker Deck
設計の「なぜ」を考える | タイム・コンサルタントの日誌から