アカウント名:
パスワード:
矢印も書いてあるのに、なぜ間違う！若い技術者はどうなるんだろ？
矢印が書いてあろうと、逆に取り付け可能なデザインにした。その時点で起きるべくして起きた事故なんですよ。
そっかー、だからUSBはあんななのかー
大手メーカー製の製品でUSBコネクタを上下逆向きに取り付ける製品があった筐体内レイアウト／基板設計の都合で逆向きにコネクタを取り付けた（基板下面を部品取り付け面にした）ようだが、大手の会社なんだからそれに合わせて逆向き取り付け用のコネクタ特注しろよ～と言いたい（無理やりコネクタを押し込もうとして壊す客を恐れないのか）
特注しなくてもそんな部品は存在しているので正しい部品を使わない奴らがクズ。
特注コネクタなんて作るというコスト高の行為自体がまず避けるべきことなのだから、その程度の理由では正当付けられないので、ない。上下間違えて挿すのも、普通の向きであってもありすぎるほどいるのでまず影響しないな。1394コネクタ差し込んで壊したとか、どうやったのか知らないがRJコネクタをねじ込んだとかいろいろあるんだよ
どこぞのキャリアのAndroidスマホがUSBコネクタが裏表逆（基盤の裏側にコネクタ）になっているな。
機種変前の機種も後の機種もそうだった。よく見ると共通充電器側のUSBコネクタも裏返しになっていた。仕様だったのか。
それでも逆さに刺した奴が居るから困る
誤接続不可能に設計したはずのセンサーが誤接続されて墜落したどこかの国の戦闘機みたいな例もあるわけですが
矢印の意味をどう定義するかにもよるしね。
「戻り値が0だったら正常終了、-1だと異常終了。」「戻り値が0だったら偽、1だと真。」「戻り値が0以上だと計算結果。負だと異常終了。」「戻り値は計算結果。異常終了は例外を投げる。」みたいなもので、そういうのは一つの慣習としてあるだけで、そうなる必然性があるわけではない。
歴史的経緯やその他の理由で逆になることも珍しくないし。＃せめてコメントに書いてくれーーーーー。orz
弁を誤操作、浄化進まず 福島第一原発の汚染水処理施設http://www.asahi.com/special/10005/TKY201106230177.html [asahi.com]
汚染水が浄化されずに装置を素通りしている部分があったという。作業員が弁に開閉の表示について油性ペンで書いた際に、逆に書き間違えていた。
ISO 1503、JIS Z 8907 で「方向の標準化」ということがされていまして、一般に、スイッチ類は、時計回りに回すと積極的な方向への変化が生じるように設計されています。電気のスイッチの場合、時計回りに回すと ON とか「高温」とか「高速」とか「明るい」とか「音量大」とかの変化が生じます（身の回りにある電化製品も工場にある制御盤も必ずそうなっています。）。
ところが、弁の場合は、時計回りに回すと消極的な方向（流量小）への変化が生じるようになってしまっていまして、今更逆にすると混乱が起きるので、もう直せないのです。
弁の役割は「流量を制限すること」じゃないの？時計回りに回すと「積極的に制限する」んだから別におかしくないような…
制限しないなら弁なんて必要ないんだし、弁が壊れれば流れは止まらなくなる。元々ある流れを弁で止めているのであって、弁で流れを作り出しているわけじゃない。
という理屈じゃダメなの？
ま、言ってるあなたもちょと無理があるなとは思っているだろうけど、他のスイッチの明るさとか熱さっていうのが弁については流量にあたるからねえ……。
自分もおかしくないと思う右ねじの時計回りにひねったら押し込まれるイメージ押し込まれるからスイッチなら積極的になるし弁なら閉じる普通じゃね？
弁が物理的ねじならまだ感覚的に素直だけど、全部ダイヤル型スイッチで、電流と温度と流量がパネルのゲージで表示されているとしたらどうすか？
けどカセットコンロの流量とかになると逆だけど。別のコメントにあるけど可変抵抗はどうです？ 弁に慣れてるから自然だと思ってるだけだと思うよ。
# 慣れてて自然だから変じゃないという話をしたいならその通りだと思うけど。
自分でなんとなく推測するに、自分にとっては #2421782 の理屈のように「右回りで積極的な方向に変化するルール、ただし弁は例外」の方がしっくりくるのだが、「弁も含めて右回りで積極的な方向に変化する」の方がしっくりきて、それぞれのしっくりの理屈に合うものを持ち出して見せ合っているって感覚なんだけど、君はそうじゃないのかい？
理屈の背景として、弁とスイッチを制御装置としてひとくくりにするかしないかで吸収できるのは理解できるけど。
その辺の解釈の違いそのものが理解できていないということなんでしょうか？ それとも分かった上で自分の解釈の理屈を説明しているのでしょうか？
例え話はややこしくなるなあ。うまく書こうとしたけど、やっぱりややこしいよ。
車ならブレーキとアクセルはやめて１つのスイッチにした方がいいと言いたいんでしょうきっと。
こういう、既存の操作をどうこうしようって話じゃなくて、既存の操作をどう解釈するかって話じゃないかなー。
自分の意見として書き方を変えると、
自分にとっては #2421782 の理屈のように「右回りで積極的な方向に変化するルール、ただし弁は例外」の方がしっくりくる
であり、「弁も含めて右回りで積極的な方向に変化する」（弁の積極的な方向というのは制御量増である）という解釈には屁理屈めいたものを感じる、というのが意見ですね。
制御量を言い出したら、制御の仕組みによって右回りと左回りを使いわける必要があって、弁を例外とする話でフォローできる範囲を越えてきますから。
補足だけど、既存の制御をどうこうするという話はしているつもりはなかったです。そういうつもりだったんですね。弁を回す方向を変えてどうすんだと逆に聞きたいくらいです。
弁ってのはキルスイッチなんだからアクティブな方向は流量小でいいんじゃね？
それを言ったら可変抵抗器のつまみを右にまわすと抵抗が減るのはおかしくないのか?
なんにしても、習慣はむやみに変えないほうがいいよ。
可変電源装置の一部だから電流が増えるのはおかしくないが
そのあたり、アメリカのNASAは超優秀です。
スペースシャトルのオービター輸送機の接続部にこういう巨大な注意書きをしました。
http://www.enjoyspace.com/uploads/editorial_blog/septembre2009/humour-... [enjoyspace.com]
ATTACH ORBITER HERENOTE: BLACK SIDE DOWN(ここに軌道船を接続せよ 注意：黒い側が下）
// 名前（最大64文字） modified at 2012/01/12char name[48];64文字にまず修正できて無いじゃん。序に64+1無いと格納できないじゃん。32文字すら格納できないじゃん。
これでいいのか？
(スコア:-1, 無粋)
utf-32 使おうぜますますコメント文とずれて楽しいよ
さらに、本システム内ではUTF-8で持つようにしててここに日本語を入力しているとBABEL BABEL BABEL BABEL BABEL
Sﾖ「おかしいな、ヌル文字も考慮して領域を確保してもまだ落ちる」プログラマ「char name[100], buff[100]: とするとなぜか落ちないですね」Sﾖ「よしそれでいこう。こりゃコンパイラのバグだね。 コーディング規約に追記だ『32文字格納する領域は、余裕をみて100文字分くらい確保すること』」プログラマ（そういえば64文字入力できるようにしようって話は・・・まあいいか）
そして愛媛県のツヅラガワにお住まいのカツラギ様という方から「落ちるよ」とクレームが・・・
include忘れで、Ｃ言語で宣言してない外部変数へのアクセスでコンパイル時にエラーにならず、リンク時エラーとなることがあった。調べると宣言していない変数はunsigned char型なんですがint型のように処理していたのでリンク時に型が合わない為エラーがでていた。
コンパイラのバグ？っていうと、そういった仕様もあるとか言われたのですが本当にあるのでしょうか？聞いてもネットに書いてあったしか教えてくれず、ネットを隅々まで調べることなんてできないので誰かご存知でないでしょうか？
省略されてる部分にどんな面白コードが入ってるかも疑わないと。
// 名前最大長 64 modified at 2012/01/12#define MAXNAMELEN 64....// // //名前（最大32文字）// // 名前（最大64文字） modified at 2012/01/12// 不統一なサイズだったため修正 2013/02/05char name[40];char buff[40];...strcpy( buff, name);....for (i = 0; i MAXNAMELEN; i++)....
日付はatじゃなくてonだよな
「矢印が先頭を向くように取り付ける」という説明を受けていたか否かですね。たとえば「この矢印と別の矢印を向かい合わせて……（「→ ←」みたいな感じに）」みたいな誤認をしたかもしれません。
＞矢印が先頭を向くように取り付け
矢印がロケットの噴射方向を向くように取り付けたのでは？
あるいは重力方向とか。
「逆さ吊りの姿勢で、上向きに取り付けよ」
あれってソフトもハードも糞なことに定評のあるIBMが諸悪の根源なんだっけ?
FDDケーブルって、PC関係で逆刺ししても壊れない唯一のものだと思っっていたよ。（寿命には影響するかも）
# 97年以降に買ったFDDはコネクタの全周を囲む囲いが無い奴ばかりだから、簡単に逆刺しできた。
矢印の意味がわからないから、どのように間違えたかなんとも言えない。そういう誤りやすさを研究する科学もあるし。
例えば、 "[→]" をセンサーとして、本体に、「ここに矢印の先頭を合わせよ」という意味で、取り付け位置の脇に
[→] ←
と描いてあったのを、技術者が「矢印の向きを合わせるのか」と思って、
[←] ←
というふうに取り付けちゃったとか。
設置場所には方向を示すものは何も書かれてないんじゃないのかな。センサーにしか設置方向は記されていなかったとか。
同じ矢印を使うにしても例えば矢印の下や上に一本線を引いておくだけでも違うと思うんだよね。「←|」「→|」みたいに。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
うわ、だっさー (スコア:0)
矢印も書いてあるのに、なぜ間違う！
若い技術者はどうなるんだろ？
Re:うわ、だっさー (スコア:5, すばらしい洞察)
矢印が書いてあろうと、逆に取り付け可能なデザインにした。
その時点で起きるべくして起きた事故なんですよ。
Re:うわ、だっさー (スコア:2)
Re:うわ、だっさー (スコア:1)
汎用部品だとそうも行かない？
------------
惑星ケイロンまであと何マイル？
Re: (スコア:0)
そっかー、だからUSBはあんななのかー
Re: (スコア:0)
大手メーカー製の製品でUSBコネクタを上下逆向きに取り付ける製品があった
筐体内レイアウト／基板設計の都合で逆向きにコネクタを取り付けた（基板下面を部品取り付け面にした）ようだが、大手の会社なんだからそれに合わせて逆向き取り付け用のコネクタ特注しろよ～と言いたい
（無理やりコネクタを押し込もうとして壊す客を恐れないのか）
Re:うわ、だっさー (スコア:1)
特注しなくてもそんな部品は存在しているので正しい部品を使わない奴らがクズ。
Re: (スコア:0, 興味深い)
特注コネクタなんて作るというコスト高の行為自体がまず避けるべきことなのだから、
その程度の理由では正当付けられないので、ない。
上下間違えて挿すのも、普通の向きであってもありすぎるほどいるのでまず影響しないな。
1394コネクタ差し込んで壊したとか、どうやったのか知らないがRJコネクタをねじ込んだとか
いろいろあるんだよ
Re: (スコア:0)
どこぞのキャリアのAndroidスマホがUSBコネクタが裏表逆（基盤の裏側にコネクタ）になっているな。
機種変前の機種も後の機種もそうだった。
よく見ると共通充電器側のUSBコネクタも裏返しになっていた。仕様だったのか。
Re: (スコア:0)
それでも逆さに刺した奴が居るから困る
Re: (スコア:0)
Re: (スコア:0)
誤接続不可能に設計したはずのセンサーが誤接続されて墜落したどこかの国の戦闘機みたいな例もあるわけですが
Re:うわ、だっさー (スコア:4, すばらしい洞察)
矢印の意味をどう定義するかにもよるしね。
「戻り値が0だったら正常終了、-1だと異常終了。」
「戻り値が0だったら偽、1だと真。」
「戻り値が0以上だと計算結果。負だと異常終了。」
「戻り値は計算結果。異常終了は例外を投げる。」
みたいなもので、そういうのは一つの慣習としてあるだけで、
そうなる必然性があるわけではない。
歴史的経緯やその他の理由で逆になることも珍しくないし。
＃せめてコメントに書いてくれーーーーー。orz
Re:うわ、だっさー (スコア:2, 興味深い)
弁を誤操作、浄化進まず 福島第一原発の汚染水処理施設
http://www.asahi.com/special/10005/TKY201106230177.html [asahi.com]
Re:うわ、だっさー (スコア:5, 参考になる)
ISO 1503、JIS Z 8907 で「方向の標準化」ということがされていまして、
一般に、スイッチ類は、時計回りに回すと積極的な方向への変化が生じるように設計されています。
電気のスイッチの場合、時計回りに回すと ON とか「高温」とか「高速」とか「明るい」とか「音量大」とかの変化が生じます（身の回りにある電化製品も工場にある制御盤も必ずそうなっています。）。
ところが、弁の場合は、時計回りに回すと消極的な方向（流量小）への変化が生じるようになってしまっていまして、今更逆にすると混乱が起きるので、もう直せないのです。
Re: (スコア:0)
弁の役割は「流量を制限すること」じゃないの？
時計回りに回すと「積極的に制限する」んだから別におかしくないような…
制限しないなら弁なんて必要ないんだし、弁が壊れれば流れは止まらなくなる。
元々ある流れを弁で止めているのであって、弁で流れを作り出しているわけじゃない。
という理屈じゃダメなの？
Re:うわ、だっさー (スコア:1)
ま、言ってるあなたもちょと無理があるなとは思っているだろうけど、他のスイッチの明るさとか熱さっていうのが弁については流量にあたるからねえ……。
LIVE-GON(リベゴン)
Re: (スコア:0)
自分もおかしくないと思う
右ねじの時計回りにひねったら押し込まれるイメージ
押し込まれるからスイッチなら積極的になるし弁なら閉じる
普通じゃね？
Re:うわ、だっさー (スコア:1)
弁が物理的ねじならまだ感覚的に素直だけど、全部ダイヤル型スイッチで、電流と温度と流量がパネルのゲージで表示されているとしたらどうすか？
LIVE-GON(リベゴン)
Re:うわ、だっさー (スコア:1)
けどカセットコンロの流量とかになると逆だけど。別のコメントにあるけど可変抵抗はどうです？ 弁に慣れてるから自然だと思ってるだけだと思うよ。
# 慣れてて自然だから変じゃないという話をしたいならその通りだと思うけど。
LIVE-GON(リベゴン)
Re:うわ、だっさー (スコア:1)
自分でなんとなく推測するに、自分にとっては #2421782 の理屈のように「右回りで積極的な方向に変化するルール、ただし弁は例外」の方がしっくりくるのだが、「弁も含めて右回りで積極的な方向に変化する」の方がしっくりきて、それぞれのしっくりの理屈に合うものを持ち出して見せ合っているって感覚なんだけど、君はそうじゃないのかい？
理屈の背景として、弁とスイッチを制御装置としてひとくくりにするかしないかで吸収できるのは理解できるけど。
その辺の解釈の違いそのものが理解できていないということなんでしょうか？ それとも分かった上で自分の解釈の理屈を説明しているのでしょうか？
LIVE-GON(リベゴン)
Re:うわ、だっさー (スコア:1)
例え話はややこしくなるなあ。うまく書こうとしたけど、やっぱりややこしいよ。
こういう、既存の操作をどうこうしようって話じゃなくて、既存の操作をどう解釈するかって話じゃないかなー。
LIVE-GON(リベゴン)
Re:うわ、だっさー (スコア:1)
自分の意見として書き方を変えると、
であり、「弁も含めて右回りで積極的な方向に変化する」（弁の積極的な方向というのは制御量増である）という解釈には屁理屈めいたものを感じる、というのが意見ですね。
制御量を言い出したら、制御の仕組みによって右回りと左回りを使いわける必要があって、弁を例外とする話でフォローできる範囲を越えてきますから。
LIVE-GON(リベゴン)
Re:うわ、だっさー (スコア:1)
補足だけど、既存の制御をどうこうするという話はしているつもりはなかったです。そういうつもりだったんですね。弁を回す方向を変えてどうすんだと逆に聞きたいくらいです。
LIVE-GON(リベゴン)
Re: (スコア:0)
弁ってのはキルスイッチなんだからアクティブな方向は流量小でいいんじゃね？
Re: (スコア:0)
それを言ったら可変抵抗器のつまみを右にまわすと
抵抗が減るのはおかしくないのか?
なんにしても、習慣はむやみに変えないほうがいいよ。
Re: (スコア:0)
可変電源装置の一部だから
電流が増えるのはおかしくないが
Re:うわ、だっさー (スコア:2)
そのあたり、アメリカのNASAは超優秀です。
スペースシャトルのオービター輸送機の接続部にこういう巨大な注意書きをしました。
http://www.enjoyspace.com/uploads/editorial_blog/septembre2009/humour-... [enjoyspace.com]
ATTACH ORBITER HERE
NOTE: BLACK SIDE DOWN
(ここに軌道船を接続せよ
注意：黒い側が下）
Re:うわ、だっさー (スコア:1)
// 名前（最大64文字） modified at 2012/01/12
char name[48];
char buff[32];
...
strcpy( buff, name);
Re: (スコア:0)
// 名前（最大64文字） modified at 2012/01/12
char name[48];
64文字にまず修正できて無いじゃん。
序に64+1無いと格納できないじゃん。
32文字すら格納できないじゃん。
これでいいのか？
Re: (スコア:0)
(スコア:-1, 無粋)
Re: (スコア:0)
utf-32 使おうぜ
ますますコメント文とずれて楽しいよ
Re: (スコア:0)
さらに、本システム内ではUTF-8で持つようにしてて
ここに日本語を入力しているとBABEL BABEL BABEL BABEL BABEL
Sﾖ「おかしいな、ヌル文字も考慮して領域を確保してもまだ落ちる」
プログラマ「char name[100], buff[100]: とするとなぜか落ちないですね」
Sﾖ「よしそれでいこう。こりゃコンパイラのバグだね。
コーディング規約に追記だ『32文字格納する領域は、余裕をみて100文字分くらい確保すること』」
プログラマ（そういえば64文字入力できるようにしようって話は・・・まあいいか）
そして愛媛県のツヅラガワにお住まいのカツラギ様という方から「落ちるよ」とクレームが・・・
コンパイラのバグ？ (スコア:0)
include忘れで、Ｃ言語で宣言してない外部変数へのアクセスでコンパイル時にエラーにならず、
リンク時エラーとなることがあった。調べると宣言していない変数はunsigned char型なんですが
int型のように処理していたのでリンク時に型が合わない為エラーがでていた。
コンパイラのバグ？っていうと、そういった仕様もあるとか言われたのですが本当にあるのでしょうか？
聞いてもネットに書いてあったしか教えてくれず、ネットを隅々まで調べることなんてできないので
誰かご存知でないでしょうか？
Re: (スコア:0)
Re: (スコア:0)
それでリンク時にトラブるとは思えない。
C++なら、リンク時に型まで見るからエラーになるけど、宣言していない関数は呼べない。
変数だったら、いずれにせよ、宣言していない外部変数は使えないので、
どこかの宣言を見落としているか、defineされているかそんなんだと思うけど。
Re: (スコア:0)
省略されてる部分にどんな面白コードが入ってるかも疑わないと。
Re: (スコア:0)
// 名前最大長 64 modified at 2012/01/12
#define MAXNAMELEN 64
....
// // //名前（最大32文字）
// // 名前（最大64文字） modified at 2012/01/12
// 不統一なサイズだったため修正 2013/02/05
char name[40];
char buff[40];
...
strcpy( buff, name);
....
for (i = 0; i MAXNAMELEN; i++)
....
Re: (スコア:0)
日付はatじゃなくてonだよな
Re: (スコア:0)
「矢印が先頭を向くように取り付ける」という説明を受けていたか否かですね。
たとえば「この矢印と別の矢印を向かい合わせて……（「→ ←」みたいな感じに）」みたいな誤認をしたかもしれません。
Re: (スコア:0)
＞矢印が先頭を向くように取り付け
矢印がロケットの噴射方向を向くように取り付けたのでは？
Re: (スコア:0)
あるいは重力方向とか。
Re: (スコア:0)
「逆さ吊りの姿勢で、上向きに取り付けよ」
Re: (スコア:0)
設計変更が頻繁に行われている環境であれば、いつの設計の時の物か分からない矢印なんて信頼できたものじゃありませんし。
むしろ矢印なり経験に頼って手順書を読まずに作業される方が困ったものです。
#結局は規定の作業方法を順守し、周りがミスをフォローできる体制であれば防げたのには変わりありませんがね
Re: (スコア:0)
Re: (スコア:0)
あれってソフトもハードも糞なことに定評のあるIBMが諸悪の根源なんだっけ?
Re: (スコア:0)
FDDケーブルって、PC関係で逆刺ししても壊れない唯一のものだと思っっていたよ。（寿命には影響するかも）
# 97年以降に買ったFDDはコネクタの全周を囲む囲いが無い奴ばかりだから、簡単に逆刺しできた。
Re: (スコア:0)
矢印の意味がわからないから、どのように間違えたかなんとも言えない。
そういう誤りやすさを研究する科学もあるし。
Re:うわ、だっさー (スコア:1)
例えば、 "[→]" をセンサーとして、本体に、「ここに矢印の先頭を合わせよ」という意味で、取り付け位置の脇に
[→] ←
と描いてあったのを、技術者が「矢印の向きを合わせるのか」と思って、
[←] ←
というふうに取り付けちゃったとか。
Re: (スコア:0)
設置場所には方向を示すものは何も書かれてないんじゃないのかな。
センサーにしか設置方向は記されていなかったとか。
同じ矢印を使うにしても例えば矢印の下や上に一本線を引いておくだけでも違うと思うんだよね。
「←|」「→|」みたいに。