・・・＞＜ "最高気温(℃) 32.3 14:28"-- 2016年05月22日　帯広(オビヒロ)　毎正時の観測データ jma.go.jp/jp/amedas_h/ye…

蚊　つらい＞＜

同時多発どうでしょうTL＞＜

なんかのアニメでオマージュとしてつかったっぽい？＞＜

ANA8551の音聞こえた＞＜ JA755A

jisinn><

ホノルル時間、UTC-10だから、UTCの時計だけでもわかりやすくて便利＞＜

＞＜；

@aldehydon これ？＞＜ 高速フーリエ変換より高速なフーリエ変換アルゴリズム | スラド サイエンス science.srad.jp/story/12/01/23…

@aldehydon わかんなくてぐぐったらそれが出てきた・・・＞＜

寝てない・・・＞＜　北極に住みたい＞＜

これ、マウスモードってあるけどトラボっぽい感覚で使えるのかな・・・？＞＜ -- MAD CATZ(マッドキャッツ）Micro C.T.R.L.R madcatz.co.jp/products/madca…

ルートビア飲みたい・・・＞＜

＞＜

まだ読んでないけどあれじゃん＞＜　機器間インタフェース共通化する宇宙機版CANっぽいやつ入れて近代化したから失敗したんじゃなく、逆にカビが生えた人力石器時代システムだったから駄目だったんじゃん？＞＜

なんかASTRO-Hあんまり興味無くて事故も興味無かったけど、まさかのオレンジが大好物な『「システムのデザインの欠陥を起因とする」ヒューマンエラー』だったという展開に＞＜；

起きたばっかりでガリレオ／ソユーズ打ち上げ見逃した＞＜；

インシデントやヒヤリハット事例をここだけの話にしてたらそりゃ事故起こすよその組織感・・・＞＜

さかのぼって考えると、なぜNASDAを作ったのか？って点も、色々政治的なの全部抜きにして、そんな感じだったからなんじゃないのかなって気が・・・＞＜

ISASの文化のおかしさでもう一つ付け加えて指摘するならば、神社で神頼みしてんじゃねーよ＞＜って点かも＞＜ スペースシャトルの備品に聖書は無かったよ＞＜（ソース：ライディングロケット）　神頼みは工学じゃないんだよ＞＜

オレンジはものすごく前者だ・・・＞＜

オレンジは、疑問をツイートして、その時点での限られた知識による考察ツイートして、調べながら考察してツイートして、「ほらね！＞＜」とか「ぐぬぬ＞＜；」みたいなツイートして、まとめの考察ツイートして、そしてツイート数がすごいことに・・・・＞＜；

でもそうやって疑問と調べてる過程と考察を全部ツイートしておくと、あとで自分のtwilogを辞書みたいに使えるから便利＞＜

まだ読んでないけどJTSBの調査報告書を読むような楽しさで読めそう・・・？＞＜；

え・・・＞＜

8197と8198はまだすこしだいじょうぶっぽい？＞＜

JA8197とJA8198は引退させる時にできたら記念フライトやって欲しいかも・・・＞＜

SYE2っぽい？＞＜ 写真撮れるかも？＞＜； - 全日本空輸 (NH) # 9434 ✈ FlightAware ja.flightaware.com/live/flight/AN…

CAVOK！＞＜

既にパニック＞＜

借り物のデジイチのバッテリー充電＞＜

三脚無いのつらい＞＜；

オレンジの中で飛行機撮影ミッションとJAXAネタが同時進行して混乱が生じまくっている＞＜

給電しっぱなしだったはずのT90Chiのバッテリーがなぜか空っぽ＞＜；

激安タフパッドやっぱ買えばよかったかも＞＜；　よくかんがえたら飛行機撮影時にLiveATC流しながらそこらに（比喩表現ではなく）放り投げてもいいって使い方が出来たのか＞＜；

充電デジイチバッテリー混乱完了緊張痙攣もう駄目＞＜

一人でも絶対しない＞＜；

自分しか食べないものを調理する時も、必ず菜箸使うし、味見する時は小さいお皿においてからにして絶対に直接口付けないし、テレビで有名シェフとかがそれ気にしてないの見ると「ぎゃー＞＜；」ってなる＞＜；

別の話題によって混乱から現実逃避するソリューション＞＜（混乱）

オレンジの頭の中にないというか意図的に無視してるのこれかも？＞＜

そうだ＞＜；　時計合わせしようとしてたんだ＞＜；

T90充電遅すぎる；；

SYE Y11 CHE Y116 AWE Y114 ANIMO B337 PAKLI B241 MAPEG B241 ENM J179 SQA AMOTT1 ja.flightaware.com/live/flight/AN…

雲あってだめだ＞＜； SYE付近飛んでる飛行機ぎりぎり目視できるけど手持ちで撮れる天候じゃない・・・＞＜　撮るのは諦めよう＞＜

三脚持ってたらバルブ撮影すれば写るだろうけど持ってないし；；

羽田や成田は雲無いのに＞＜；

（まだ読んでないけど）1960年代の体質のままで1980年代のテクノロジーでやってる感がある＞＜ ISAS スーパーマン思想もありそうだし＞＜（「最後は人が」という間違ったヒューマンエラー対策＞＜）

航空での例をあげるなら、いわゆる『ハドソン川の奇跡』を「ditchingボタン押し忘れ沈没事故」って捉えるか捉えないかで違うかも＞＜　美談（とされるもの）の中に含まれる重要な失敗にも注目して学べないと、美談が尽きるまで同じ事故は起こり続ける＞＜

飛行機時間混乱＞＜

SYEの方向の雲厚くなってるしもしかして目視も出来ない可能性が＞＜；

OPPAR3だったら撮れたかもしれないけど、うろこ雲があるから撮れないかもしれない・・・＞＜；

それを言いたかった＞＜ twitter.com/orange_in_spac…

8197だ＞＜(ANA99) on Flightradar24.com fr24.com//9cf3529 #flightradar24

8199飛びそう＞＜

JA8199とんだっぽい＞＜

（電波法＞＜；）

JA8199出た＞＜ -- on Flightradar24.com fr24.com//9cf378b #flightradar24

di SYE now><

準備＞＜

ちょっとだけ目視出来た気がしなくもない＞＜（確信できないくらい曇ってた・・・＞＜）

電波法的に書かなかったけど、グッデイとかじゃなくそう言ったの耳に残った＞＜

RT @APInfo_bot: 東京・羽田発 #ANA 全日空 NH9434便 ボーイング777-200 JA8199 退役後のフェリーフライト (今日でちょうど20歳) 20年間お疲れ様でした。

つまり飛行機が好きになってから20年くらい経ったのかという点でオレンジ的に777の初期導入機は特別な感じでつらい・・・＞＜

つらいけど脳内の思考をとりあえず飛行機から宇宙機へ切り替えて報告書読む＞＜；

ASTRO-Hの異常事象調査報告書、斜め読みで今61ページまで来たけど、JTSBの報告書と比べると、あっちは飛行機がどうやって飛んでるかわかんない人にもわかるように書こうとしてるんじゃないのかってくらいに丁寧だけど、これはなんか内部向けプレゼン資料みたいだ・・・＞＜

プレゼン資料というかプレスリリース的というか、JTSBの報告書で言う所の『説明資料』（大きな事故の報告書の時に一般人向け（？）に概要を説明するために作成される（？））っぽさが・・・＞＜

事故調査のプロとそうじゃない人々が書いた報告書って違うんだなみたいな・・・＞＜ あらためて事故調査のプロのすごさがわかるというか・・・＞＜

JTSBの報告書、地方事務局の船舶の報告書だとやっつけなのもかなりあるけど（手漕ぎボートがコケただけとか）、そういうのでもちゃんとフォーマットがしっかりしてるからやっつけでも読める＞＜ 一方で大事故の巨大な報告書でも読みやすい＞＜

JAXAの中の人も運輸安全委員会の報告書読むべきだと思う・・・＞＜ 学ぶべき失敗を知ることが出来ると言う面でもだけど、事故調査とはどういうものかを知る意味でも＞＜ じゃないとたぶん事の大小に関わらず失敗した時にちゃんと検証できないじゃん？＞＜

結局見なかった＞＜；

ASTRO-Hの異常事象調査報告書、63ページが全てだって感じがすごい感じでアレだ＞＜（言葉に出来ない）

なんていうか、そこらの一般人レベルに下げると、テストコード書く時に使ったボタンの名前が「button1」とかのままのツールをそのまま使ってるような＞＜；（かなり違う気もする＞＜；）

まじでこれヒューマンエラーが起きない方がおかしい駄目なデザインのお手本だよねこれ＞＜；（デザインされて無いけど） "運用支援業者の作業者が「RCS駆動マトリクス生成ツール」出力を「パラメータテーブル生成ツール」入力する際に負値を正値に直さなければならないところを実施しなかった。"

UXのレビューの大切さを示す一例でもあるかも＞＜； 「使いにくい＞＜＃ 」ってキレる事の大切さ＞＜ 使いにくいってキレる人が居ないとどこがおかしくて将来どんなエラーを招くのかがうまく表面化しない＞＜（だからオレンジは普段から気に入らないUXに対してキレまくってる＞＜）

この前SobaCha使ってみた時に「ユーザーの切り替え方わかんない＞＜＃ 」ってキレたじゃん？＞＜ あれ、キレる人が居なかったら切り替え方がわかりづらいし、現在のUXのままではFAQ辺りに説明が必要という事にも多分気づけないじゃん？＞＜

（話が飛びすぎちゃうからそっち方面は省略しよう＞＜；）

（話を元に戻して）これ、運用支援業者の作業者は全く一切1ミリも悪くないかも＞＜ "運用支援業者の作業者が"（略）"入力する際に負値を正値に直さなければならないところを実施しなかった。" "本作業は初めてであり"（以下略）

逆にどう悪かったのかと考えると、こんな使いにくいシステム使えるわけ無いだろ！ってキレなかった点かも＞＜ でも、実運用時の目の前の初の作業でキレても、慎重に作業して切り抜けたかもしれないけど、でもすぐには直せないよね・・・＞＜

UXでムカついたらみんなキレよう＞＜ 鉄道でのUXへの不満で駅員に殴りかかるような人は論外でも、UXに対しての不満を口にして情報化することは大切だし、正しくないUXに無言で従うのは事故へまっしぐら＞＜ 黙っているのは事故回避の重要なヒントを捨ててるのと同じ＞＜

ASTRO-Hの事例もオレンジのデザインへの考え方 「私はそれをどうやって知ることができますか？」が適用できる事象かも＞＜

ショートカットキー間違えて自分のツイートふぁぼった＞＜＃ (フォークしたんだから自分でなおしましょう＞＜；)

5.2.3(P75) "（略）人的ミスをゼロにすることは難しく、ミスは起こりうるものとして衛星の運用システム（運用手順等含む）は構築されているのが一般的である。"

プロテクションだ！＞＜ オートメーションと言い訳しない手動を排除する正しいプロテクションのデザインの必要性だ！＞＜ - 5.2.3(P75) "したがって、（略）見逃してしまった仕組み"（略）"ならない対策（設計など）が課題と考える。"

やっぱりエアバスの方が正しい！＞＜（暴走）

手動で運用でカバー駄目絶対＞＜ 『「最後は人が」思想』駄目絶対＞＜ 唯一の正解は事故から学びプロテクションをひたすら改良し続ける事＞＜

チェックリストなかったとか、手動でパラメータの正負書き換えとか、航空事故調査報告書に学んで反映してたらやらない大失敗かも＞＜

（オレンジは事故調査報告書を日常的に読んでるけどちゃんと反映して無いからよく失敗する＞＜；（でも、それは自らを実験台にして学ぶべき失敗事例の一例になろうとしてるからという面もある＞＜；））

"６．対策・改善事項" "（次回提示）" ズコー（AA略） （この速さでまとめたんだからある意味すごいし航空事故の最終調査報告書並みの品質を求めるのも酷なのかも＞＜；）

Twitterの投稿文字数制限が緩和決定　ユーザー名や添付画像がノーカウントに - ねとらぼ https://t.co/wW1J8tzL9u nlab.itmedia.co.jp/nl/articles/16…m_nlabさんから

林檎が好きななんとかのぶなんとかって人のせいのような気がしなくも無い＞＜

@nebula121 なんか『終わりに』の所の"実はPySideで..."の所の意味がよくわからない・・・・＞＜