#羽生くんの画像をアップすると近い構図の羽生さんの画像が送られてくる 「このタグ反則すぎる(笑)」
http://togetter.com/li/957923
も、たしかに凄い＆面白いけど、
#デレマスの画像を送るとそれに近いヒラリークリントンの画像が送られてくる
http://togetter.com/li/945989
のヒラリーさんの写真のほうが凄い！よくみつけてくるなあ・・・
#羽生くんの画像をアップすると近い構図の羽生さんの画像が送られてくる 「このタグ反則すぎる(笑)」
http://togetter.com/li/957923
も、たしかに凄い＆面白いけど、
#デレマスの画像を送るとそれに近いヒラリークリントンの画像が送られてくる
http://togetter.com/li/945989
のヒラリーさんの写真のほうが凄い！よくみつけてくるなあ・・・
「嫌なら辞めなさい。勉強は・・・」 林先生の言葉が正論すぎて共感の嵐
http://buzzmag.jp/archives/55391
この記事、林先生が「勉強は贅沢なんだから」っていう言葉で有名らしいんだけど、
そこよりも、最後の「林先生の授業風景」がすごすぎ！
SE教育の文章の読み解き方、書き方に絶対いいと思う！！
たぶん、これを勉強することで、
SEさんが徹夜にならなくて、
命を削らなくてすむ場面も出てきそうなくらい、
よさげな内容・・・
売ってないかなあ、どこかにビデオ・・
企業システムが分かるクラウドエンジニアが足りない
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/040200525/
足りない・・・ぜんぜん足りてないと思う。将来的には。
プログラマはもう十分だけど、
クラウドはより高度化、多サービス化、障害の複雑化していくと思うけど、
それに対応できる人が、ぜんぜん足りていないと思う。
日本の技術力の足かせになるよね・・・
大学は、プログラム教育するより、クラウド教育する必要があると思う・・・
この前のJALのシステム障害、
「プログラム更新ミス」
「プログラム設計ミス」
「プログラム設定ミス」
など、いろいろな書き方がされているが、どうも、これが原因そう
同システムで、計算用サーバーとデータベースサーバーが連動する２つの処理が同じようなタイミングで実行され、互いの処理を妨害した。このため乗客数などのデータが滞留して全体が不具合を起こし、搭載指示などができなくなった。
３月２３日に同システムの開発会社によるプログラム修正を行った結果、不具合が発生する設定になった。同社でプログラム修正と検証作業を行っている。
（太字は
ＪＡＬシステム障害 システム内で２つの処理が互いに妨害 影響人員約２万４０００人に
http://headlines.yahoo.co.jp/hl?a=20160406-00000577-san-soci
より引用）
そうなんだよねえ～
昔のバグは、プログラムの書き間違いや
intにString入れて、超ウケね～とか
画面間の矛盾、DB更新の矛盾などだったけど、
今のバグは、分散処理に関係するもの、
といっても、デッドロックのような昔から言われているようなものでなく、
ライブロックや公平性、スタベーション（飢餓）に絡んだものとかのほうがある。
つまり、分散処理、スケール、クラウドが進んだがゆえに起こる、
環境依存のバグというよりは障害なのだ・・
この手の障害は、特定の状況でしかおきないので、再現が難しいし、気づくのも難しい。
たとえば、普段は問題なく取れているのだけど、
Javaでガベージコレクションが走り、処理できなくなって、
キューがたまりすぎて、一部の処理がリスタートすると、
ずっとリスタートするままになるとか（ライブロックが起こっている）
モデル検査ではじけるものもあるんだけど、
モデル検査自身が難しいし、
確率論的なものや、環境上の知らない資源(windowsのグラフィックコンテキスト等）
で起こるものなどは、仕様が記述できないものもある。
ってことで、運用してみて、ログ解析して、危険を察知する
とかいうことしかない。しかし、キケンとわかっても、問題が起きていない
（実際その後も問題にならないこともある）中で、どこまで開発が対応できるか
（時間的に、予算的に）っていう問題もある。
この手の新たな問題が発生しているのが最近の障害だったりする・・・
ま、このレベル以前の障害が、いまだに圧倒的に多いんだけどね・・・
＜その後追加＞
その後、以下の記事を見た
JALシステム障害、前週に追加の排他制御がデッドロックを誘発
http://itpro.nikkeibp.co.jp/atcl/news/16/040601011/
ごめん、圧倒的に多いほうだった・・・「このレベル以前」。
資源間のデッドロックで、これだと、たぶん、モデル検査かければ出てくるね。
ただ、JALは元に戻すのでいいけど、他の会社には、このシステムで
収めているんでしょ？他の会社のシステムは、どうなんでしょう（＾＾；）
「プログラム更新ミス」
「プログラム設計ミス」
「プログラム設定ミス」
など、いろいろな書き方がされているが、どうも、これが原因そう
同システムで、計算用サーバーとデータベースサーバーが連動する２つの処理が同じようなタイミングで実行され、互いの処理を妨害した。このため乗客数などのデータが滞留して全体が不具合を起こし、搭載指示などができなくなった。
３月２３日に同システムの開発会社によるプログラム修正を行った結果、不具合が発生する設定になった。同社でプログラム修正と検証作業を行っている。
（太字は
ＪＡＬシステム障害 システム内で２つの処理が互いに妨害 影響人員約２万４０００人に
http://headlines.yahoo.co.jp/hl?a=20160406-00000577-san-soci
より引用）
そうなんだよねえ～
昔のバグは、プログラムの書き間違いや
intにString入れて、超ウケね～とか
画面間の矛盾、DB更新の矛盾などだったけど、
今のバグは、分散処理に関係するもの、
といっても、デッドロックのような昔から言われているようなものでなく、
ライブロックや公平性、スタベーション（飢餓）に絡んだものとかのほうがある。
つまり、分散処理、スケール、クラウドが進んだがゆえに起こる、
環境依存のバグというよりは障害なのだ・・
この手の障害は、特定の状況でしかおきないので、再現が難しいし、気づくのも難しい。
たとえば、普段は問題なく取れているのだけど、
Javaでガベージコレクションが走り、処理できなくなって、
キューがたまりすぎて、一部の処理がリスタートすると、
ずっとリスタートするままになるとか（ライブロックが起こっている）
モデル検査ではじけるものもあるんだけど、
モデル検査自身が難しいし、
確率論的なものや、環境上の知らない資源(windowsのグラフィックコンテキスト等）
で起こるものなどは、仕様が記述できないものもある。
ってことで、運用してみて、ログ解析して、危険を察知する
とかいうことしかない。しかし、キケンとわかっても、問題が起きていない
（実際その後も問題にならないこともある）中で、どこまで開発が対応できるか
（時間的に、予算的に）っていう問題もある。
この手の新たな問題が発生しているのが最近の障害だったりする・・・
ま、このレベル以前の障害が、いまだに圧倒的に多いんだけどね・・・
＜その後追加＞
その後、以下の記事を見た
JALシステム障害、前週に追加の排他制御がデッドロックを誘発
http://itpro.nikkeibp.co.jp/atcl/news/16/040601011/
ごめん、圧倒的に多いほうだった・・・「このレベル以前」。
資源間のデッドロックで、これだと、たぶん、モデル検査かければ出てくるね。
ただ、JALは元に戻すのでいいけど、他の会社には、このシステムで
収めているんでしょ？他の会社のシステムは、どうなんでしょう（＾＾；）
アクセス
トータル
ランキング
