「よくある業務開発の自動化事情」を聞いてきた！

11月28日にJJUG CCC 2015 Fallに行ってきた話のつづき。

---

■How to speed up your application using JCache

・ＪＳＲ１０７
・ヘーゼルキャストの関心高いけど、今日はJCacheの話
・キャッシング入門
　キャッシュ：ナノセカンドで返ってきたりする
　特色①パフォーマンス②オフロード③スケーラブルでないところにスケーラビリティ
　　→需要が急に増える場合、ヘーゼルキャストを入れて早めたり

・いつキャッシュを使うか
　データを２回以上使うなら価値あり
　キャッシングが有効になるところ
　　①Ｗｅｂアプリ（突然需要上がる）
　　②ネットワークにまたがるシステム
　　③データが複雑、オブジェクトが入り組んでいる
　　④オブジェクトがグラフ構造


・データベースキャッシング

・キャッシュ：ＲＡＭに構築
　　Ｊａｖａ：分散キャッシュ→ヒープストア：ガベージコレクションの制約
　　（メモリの三角形の）上のほうは１つのマシン上で考えている
　　　　　　　　　　　　下のほうは分散→クラスタ組んでいるのを想定

・アムダールの法則：複数プロセス実行時、パフォーマンスを高めるには、
　　　　　　　　　　ボトルネックを早くしたほうがよい

・キャッシュの効率
　あまり統計データ持っていない
　キャッシュ効率高い：オフロードできている
　　効率での考慮→レファレンスデータ、データ変更頻度、頻繁に使われるデータ

・分散キャッシュ

・オブジェクトのコピー：安全性に問題
　　→イミュータブルなデータなら安全
　　問題→一貫性、整合性、マルチコンシステンシー、Javaメモリーモデル、
　　　　　Eventual Consistency、weak Consistency、atomic oparation

・Javaキャッシング
　ＪＤＢＣみたいなものを目指している
　完了した
　Spring 4.0サポート、4.1拡張
　Spring Boot 使ってくれます
　実装したもの：長いリストになっている
　Mavanでの設定

・コンセプト　ＪＳＲ１０７
　出発点　Ｍａｐ　ＶＳ　Cache API どちらもキーバリュー
　Jcache サービスローダー　キャッシングプロバイダを見つける
　　　　キャッシュマネージャー　ＤＢに相当
　　　　キャッシュ　　キーバリュー

　ジェネリックを使っている
　かぎとなるＡＰＩは、putとget(put；値返さない）

・Spring
　アノテーションで操作できる

・Jcacheのインプリは６種くらいある
　Jar入れ替えなどでＯＫ
　当然ヘーゼルキャスト使ってね！

---

■よくある業務開発の自動化事情

・広いままでもできなくはないけど　AAA(A* Automation Alliance)
　キレイな事例紹介で終わる

・今回はJava,Webアプリケーション、受託開発、スキル会社バラバラを想定
　５個ぐらいの現場で会ったこと

・自動化の目的→早く帰ること
　２種類
　　手作業とまったく同じものを出力する自動化
　　手作業でできないことを自動化する

・対象はすべての活動

・ビッグバン自動化

【自動化事情】

・環境構築
　　開発、検証、本番
　課題
　　　・手順書ベース（更新されていない）
　　　・複数バージョン動作させたいとき
　解決
　　　・プロビジョニングツール
　　　・仮想化技術、コンテナ技術
　使ってみたところ
　　　・クリーンすぎて困った→テストつくるとき
　現実
　　　・プロジェクトだとコスト重い
　　　・現場に浸透していない。その人だけ使えても・・・
　　　・重い
　　　・組織の壁

・構成管理
　前提
　　　・ＣＶＳはあたりまえ、SVNかGit使ってる
　　　・Ｇｉｔは気合いるけど、多くなってきた
　　　・検証済みマージ
　　　・リポジトリはNexus/とArtifactory
　現実
　　　・コミットしてはいけないファイルをコミットしてしまう
　　　・ローカル用の設定変更
　　　・Ｇｉｔはトラブルに弱い→たまに事故
　　　・Mavenのリリースバージョン

・ビルド
　　　・antで解決していた
　課題
　　　・依存関係
　解決
　　　・Gradleなど
　現実
　　　・ビルドツールは使いこなされていない
　　　・mavenの場合、pom.xmlとかは特定の人しかわからない

・ＣＩ
　　　・Jenkins
　課題
　　　・ワンクリックデプロイ
　　　・ＣＩサーバーは市民権をええいる（ビルドサーバー）
　現実
　　　・属人性の排除はできていない。ＣＩ職人へ
　　　・ワンクリックデプロイは組織の壁

・コーディング
　　　・設計書から自動生成だ
　　　　→イマドキのフレームワークなら生成する必要ないだろう
　　　　　ＩＤＥによる自動記述→ＩＤＥを使い倒そう
　課題
　　　・大量のソース書く
　解決
　　　・パワフルなフレームワーク
　　　・ＪＶＭ言語
　現実
　　　・昔自動生成した、ソースコードは？
　　　

・テスト
　　　・自動テストはよく話題に上がる
　　　　システム自動化カンファレンス
　　　・JUnitなテスト　Excelマクロで生成：無駄に量が多い
　　　・JUnit5
　　　・ブラウザ使うやつ： selenium
　課題
　　　・自動化して工数減らす
　現実
　　　・自動化しても工数減らない
　　　・実行には時間がかかる

【自動化観察日記】
１章
　　自動化担当召喚
２章
　　即時対応したい
　　→パトランプなど
　　順風満帆
３章
　崩壊の足音
　　担当者変更
　黙らされたＣＩサーバー

テスト自動化　８つの誤解：ググって調べる

自動化ハイ
げんかつぎ

【まとめ】
・自動化は
　　高速道路はあるが
　　突っ走ったら死ぬ
　　適当に降りて迷宮に入ること

Javaのデバッガのしくみ(JDI)とか、Garbage First GCとか

11月28日にJJUG CCC 2015 Fallに行ってきた話のつづき。

「Cloud Native Application Framework with Spring」
「デバッガのしくみ（ＪＤＩ）を学んでみよう」
「Garbage First GC」

をメモメモ

---

■Cloud Native Application Framework with Spring


・ソフトウェアによるビジネス変革
　アジャイルの専門pivotal labs

・高価な環境からのクラウドへのワークロード移行

・スケールアップが他からスケールアウト型への移行

・へろく→Twelve Factor app:クラウド時代のアプリのあり方

・新しいトレンド：マイクロサービス
　マイクロサービスのエンタープライズへの浸透
　　　マイクロサービス→ジョブディスクリプションに
　→それなりの要件を求められる
　独自のプラットフォームを展開する会社

・リファレンスアーキテクチャ
　リファレンスとしてNetflix→OSSとして公開
　クラウドにおいて、ＯＳＳで高かようせい

・クラウドネイティブアーキテクチャ at Netflix
　カオスモンキー

・フレームワーク、ランタイム、プラットフォーム
　Asgard(あっしゅがーど？）→spinnaker
　　　（運用にちかい）
　→共通のパイプライン、ＣＩ，CD

・プラットフォーム大事

・Spring
　　Spring Boot 構成済みパターン
　　　　どうやって活用し、支えていくか？
　　Spring Cloud　Service

　例：Spring Cloud+Netflix OSS

　デモ　Spring Oneでおこなったもの

・Configサーバー
　Service Registration/Discovery　Eureka（ゆうりか）サーバー

・サーキットブレーカー
　Fault Tolerance - Circuit Breakers

　エンドポイント登録→サービス側情報をライブで見れる

・App Manager Marketplace
　マイクロサービス　あげるのたいへん
　→cloudfoundryで：ダッシュボード

・プラットフォーム：Cloud Foundry
　.net,docker,ビルドパック対応で動かせる
　数多くのフレームワークと管理手法、自動化ツール

　Pivotal cloud foundry
　　デプロイの自動化　cf push
　　マルチクラウドへの展開
　　ミドルウェアサービスの利用
　　サポート部門へのチケット依頼も激減

・実行環境：Buildpackとコンテナ

　Becoming Cloud Native
　Pivotal Web Service ５０日の試用期間（カード不要）

---

■デバッガのしくみ（ＪＤＩ）を学んでみよう
（資料はあとで公開予定）

・ふつうはＩＤＥ使ってデバッグ→うしろのしくみ

・アジェンダ
　でばっがのしくみ
　ＪＤＩ解説
　デモ

・デバッガの仕組み(JPDA)
JPDA Java Platform Debugger Architecture
　ＪＶＭ　ＴＩ　JavaVM Tool Interface
　　　 ブレークポイント、ツールのためのインターフェース（ＪＶＭに対して）
　ＪＤＷＰ
　　　　通信プロトコルの定義
　ＪＤＩ Java
　　　　ここの説明をこれから

・ＪＤＩ
（１）コネクタの取得
（２）ターゲットＶＭへ接続
（３）ＶＭに対する操作
（４）リクエストとイベントキュー

・コネクタの取得
　提供されるコネクタ＆ターゲットＶＭへ接続
　　Listening Connector
　　Attaching Connector
　　LauncingConnector デバッガからターゲットＶＭ生成

・ターゲットＶＭのオプション
　デバッガが　Attaching Connector　server=y tramsport=dt_socket
　デバッガがListening Connector

ＶＭに対する操作
・ロード済みクラスの一覧を取得
・スレッド一覧を取得
・クラスを再定義
・ＶＭを強制exit

リクエストとイベントキュー
・リクエストとキュー監視
・各種リクエスト／イベント

ちょっと注意
・LaunchingConnectorを使う場合、
　標準出力、標準エラー出力を適宜読む
・ターゲットＶＭが終了する場合、正常終了ではデバッガ側は異常でおわる
・ＪＤＩの標準実装、例外をチェインしてない（箇所が多い？）
　→スタックトレースの情報だけで悩んでいると、見当違いのことも
・ＪＤＩでググると、ジャパンディスプレイがでる（ＪＤＩ　Ｊａｖａで）

余談
・なんでＪＤＩに興味を満ったのか？
→カバレッジ

---

■Garbage First GC

たこやき器の説明

・ログから把握できる動作状況

・HeapStats開発

・Ｇ１ＧＣ概要
　ＧＣ
　不要なメモリ領域（ｈゴミ）を判別
　かいしゅう

４種類のＧＩ
　シリアル、パラレルＧＣ
　コンカレントまーくＳｗｅｅｐＧＣ
　Ｇ１ＧＣ

パラレルとコンカレント

メモリ管理
　ヒープ
　　従来：Eden,survivor,old
　→Ｇ１ＧＣはガラッと変わる
　　リージョンと呼ばれる空間に分ける
　　リージョンサイズ以上のオブジェクトはHumongous Objectとして扱われる
　　世代分けはする。Full GCもおこる
　　Humongous Objectは専用に割り当てられるがコスト高い

　ごみの多いオブジェクトだけＧＣする

　ヒープレイアウト：従来と同じく世代別、ただし細分化
　ごみの多い場所をやるのでＧ１ＧC

Ｇ１処理とログ
GC pause (G1 Evacuation Pause)(young)
　→youngGCが発生した
　実際の時間ＳＴＷ時間
　→オブジェクトコピーの時間に注目
・young GC サバイバー入らないとoldへ

複数回のYoungGC後→Marking Cycle
・漏れを防ぐため全スレッド止めて再マーク
　コンカレントではない処理はSTWが発生する

Ｍｉｘｅｄ　ＧＣ
・アルゴリズムはＹｏｕｎｇＧＣと同じ
　　→大きな違いはＧＣ対象のリージョンが違う
・達成するまで複数回

注意すべきパターン
・Evacuation Failure
　ログにはto-space exhausted　そのあとFull GC
対策
１．ヒープを増やす
２．サイクル頻度を上げる
３．over-tuningを回避
→ヒープを増やそう

・Humongous Allocation頻発
　対策：リージョンサイズをＨｅａｐと一緒に増やす
　　　　巨大な配列を作らない
→ヒープを増やそう

・ＣＰＵ処理時間が長い
対象案
・物理ＣＰＵ余裕あり＝並列度をあげる
→ＣＰＵを増やそう（NUMA環境は注意）

out of memoryのときは、ヒープダンプをだすといいかも
jstatでみれる
カード：リージョンごとにカードが割り当てられる→カードテーブル
　　割り当てられるとフラグが上がる＝ダーティカード

Facebookメッセージは、友達リクエストの時点では届かない

手順メモメモ

http://webdesign-tokita.jp/2015/11/23/facebook-message/

「#てらだよしおがんばれ」を聞いてきた！

今日(11/28)JJUG CCC 2015 Fallに行ってきた。
そのなかから、（順番めちゃくちゃだけど）まずは、
「てらだよしおの赤裸々タイム」
からメモメモ

---

■てらだよしおの赤裸々タイム

Microsoft love Java

・その節はみなさまおさわがせいたしまして・・
・１人でやるとは思っていなかった。
・なぜマイクロソフトに行ったのか、なにをやりたいのかを１０～１５分
・そのあとしつもん。みんなにやにやしてこわい・・・
　→温かい目で・・・

自己紹介
・２０１５年７月１１日入社
・元オラクルJavaエバンジェリスト
・ハッシュタグ　#てらだよしおがんばれ

サティアナディラ（マイクロソフトＣＥＯ)
・前の社長だったら今ここにいなかった
・キャリアの中で、マイクロソフトはなかった
　→Sunにいたので
・Sunは挑戦者だった。次のＩＴを作っていく→赤い会社に買収されたけど・・・
・サティアさんになってから、マイクロソフトはガラッと変わった
・マイクロソフトにもＯＳＳ研修ある→次のイノベーションはＯＳＳ
・OpenJDKのソースコミットもしている

Ａｚｕｒｅ－オープンなプラットフォーム
・LinuxやJavaが動くことを知らない人もいる
・Jenkins、Docker→Visual studio ちーむさーびしーずからのデモをやっていた
　→今まで使っていたまんま
・JavaEE GlassFishを始めていった感覚と似ている
　→そんな盛り上がるわけないじゃんと言われたのが・・・・
・Ｍｉｎｅｃｒａｆｔ：開発はJava　自分で拡張できる
・子供むけのプロふらミング教育さかん　１２月７日

【質問タイム】
・ニコ生のとき
　まわりはVisual studioたいかの人。でどきどきしてた！

　今回のこと：チャレンジ
　チャレンジしている会社が好き（前の会社がどうかと言ってないですよ）
　マイクロソフトはアップル、アマゾンの挑戦者
　　→目まぐるしく変わっている
　Ｓｕｎに戻ってきた感覚（あんまりいいすぎると前職に・・・）

・今聞かれたくない質問はなに？
　前の会社のこと
　（以下、つぶやくなという指示あり）

　（たぶん、ここからＯＫ？）

・エンジニアの転職に必要なことって？
　いきなり面接官に！
　光るモノを持っている
　入った後に、こんなことをやりたい
　→口だけの人もいる
　話をしていてわかる
　→しっかり自分を持っている
　オールマイティより、とがった人を集めて横の関係を強める

Nottyって終わるんだって・・・

・・・その前に、忘れてた（＾＾；）
・・・みんな、覚えてた？？・・・


スマホ向け放送「NOTTV」、ついにサービス終了
http://bylines.news.yahoo.co.jp/ishikawatsutsumu/20151127-00051868/

Web記事＋２ちゃんねる＝大規模アジャイル？

みずほ銀行次期勘定系システムの話。

ここの記事
［1］
みずほ銀行「次期勘定系システム」の全貌　プロジェクト完遂へいよいよ正念場
http://itpro.nikkeibp.co.jp/atcl/column/14/090100053/111300102/


［2］8000人が支えるみずほ銀行「次期勘定系システム」　開発プロジェクトの内情
http://itpro.nikkeibp.co.jp/atcl/column/14/090100053/111700103/


［3］「次期勘定系システム」万難排せ　みずほ銀行が打った三つの布石
http://itpro.nikkeibp.co.jp/atcl/column/14/090100053/112000104/


をみると、もうばっちりで、あとはテストのように読める

でも、

◆みずほ銀行次期システム開発を見守るスレ18◆ [転載禁止]©2ch.net
http://hello.2ch.net/test/read.cgi/infosys/1447159626/

を見ると、まだ、要件定義しているように読める。

これは、どう解釈すればいい？

（１）記事がほんとう、２ちゃんねるが「ガセ」
　→たぶん、きっと、一般的な解釈は、こうだろう・・・

（２）２ちゃんねるが本当、記事がまちがっている
　→記者が偉い人に取材に行き、現場は違っている場合に起きる

（３）どちらも本当
　→壮大なアジャイル開発をしている。つまり、要求を出してテストして
　　までが繰り返されている。

　　もし、この場合、さらに３種類が考えられる
　　（３－１）だんだん品質はよくなっていく
　　　　→みんな、こうなると思っているが・・・・
　　（３－２）ループしている
　　　　→デスマーチになる
　　（３－３）デグレしていく
　　　　→デスマーチになる

　（３－２）、（３－３）でないことを祈るのみと・・・・
　さあ、正解はどれ？

---

P.S

[3]の後半の工夫・・・ちょっと気になるので、コメント

２番目の工夫「設計上は変更のない処理についてのテスト」
　これは回帰テストに相当することなので、工夫でなく、逆にやらないとまずい。
　問題はそこではなく、そのあと・・・

「最後が、利用部門によるユーザー受け入れテストを手厚くする」
　ここで、問題が起きた場合、修正だけでなく、全体をテストしないといけない。
　ということで、「プロジェクトの最後まで確認作業を続ける」のであれば、
プロジェクトの最後まで仕様変更が起こることになり（アジャイル）、
ならば、システムの最後まで回帰テストを行わないといけない。

　しかし、２番目の工夫は、回帰テストを意識した書き方になっていない
（自動化するとは書いていない）。とすると、ユーザーテストが始まった
ところで、問題が露呈し、修正ミスすると、それがどんどん派生し、
（３－２）、（３－３）になっていく。

　ただ、回帰テストを自動的に行うには、構成管理がしっかり出来ていないと
いけない。まあ、そのへんは、これほど大きいシステムになると、ちゃんとした
人が入っていて、ちゃんとやっているんだろうが（そうでないと・・・）

「私たちは何を知っているのか」聞いてきた

昨日（１１月２６日）NIIの市民講座
「私たちは何を知っているのか」を聞いてきたので、その内容をメモメモ

---

１．長い前置き
・ロボットとお客さんの会話
　　あお→却下
　　食事、
　まくしたてられる：想定した答えしか言わない

・機会が会話＝理解している
　　→チューリングテスト
　他人が考えてるなんて、わかんないだろう？
　　→知性を行動で判断する
　会話が自然と理解してることは別？

・推論ができる
　ある文→別の文
　含意関係認識タスク→機械に認識

・今日：機械に推論
　→アノテーション付きコーパス、オントロジー

・単純なケース：文を含んでいる場合
　→形態素解析

・述語項構造レベルでの比較
　Ｘ取り消す表現文（否定表現、認識的モダリティ表現、条件表現）

・取り消す表現を例外にする
　Ｘ生き残る推論内容→前提：背景にある、取り消されない

　【前提】
　　・なぜ～かの～は前提
　　・とりたてし

・スコープ
　　ではない、わけではない：影響範囲違う

・表現の曖昧性→じゃない（否定、事実確認、推量）

アノテーション（注釈）つきコーパス
　　・質をあげる方法は？
　　・質を下げる方法はいっぱい


世界知識をつかわないとできない

・とにかく知識を集める？
　　→なにが存在するのか：オントロジー

・オントロジーとは？
　　世界の捉え方：暗黙を明示
　　他人との合意

　概念クラス→いんすたんす
　概念クラスの階層関係

・おなじである
　うまくいかないこと
　　→ロールの問題：ロールとロールホルダー
　　→性質

・ニーズに応じてオントロジーを選ぶ

・良い知識源を作るための取り組み

・さいぶ：ちしきをあつめる

IoTとかロボットとか・・ちょっとコンピューター界隈を離れると、そこまで流行ってないかも？

今日(11/26)HOSPEX Japan 2015等とINCHEM Tokyo2015等を見に、東京ビッグサイトに行ってきた！ので、その内容をメモメモ

■HOSPEX Japan 2015等
　医療系の展示会。
　フードサービス、空調、ベッド、病院、清掃・・・いろいろあるけど、
　コンピューター系で言うと・・・

・位置検知、位置情報なんかがいくつかった。
　　→関連してる話として、ビーコンやレーダーも・・・

・電子カルテ、看護配置（ナーススケジューリング）なども
　もちろんあるけど、小さい・・・サ高住ソフトなどもあり

・クラウドとしては、SaaS型ME機器管理MEDICSONとか・・

・ロボット関係は、富士ソフトがコミュニケーションとぼっとpalroを出していた
・ロボット介護機器開発導入促進事業とか展示してあって、
　　RTワークスがロボットアシストウォーカーというのをだしていたが、
　　いわゆるロボットとはイメージちがうかも（でも、こちらのほうが役立ちそう）
　　他に移動介在とかも
・見守りロボットとかもあった

が、全体的にいって、いわゆる（Pepperみたいな）ロボットは期待するより少ない。
IoT（ウェアラブル）、ビッグデータ話もすくない。

---

■INCHEM Tokyo2015
・プロセスエンジニアリング、ポンプ、プラントなど・・・
　というと、IoTやIndustry4.0といいたくなるが、そんな展示は？？なかったか？？
・アズビルが、ビックデータで異常を早期発見というのをやっていたが、
　ビッグデータのネタは、それくらいじゃなかったかな・・
・金属のRFID?とかはあった

---

ということで、プラントとか、医療系とか、いかにもIoT,ビッグデータ
話がでそうだけど・・・そんなになかった。
IoTとかで盛り上がってるのは、コンピューター業界だけで、
周辺業界は、そうではないのかもしれません。

排他制御、確実なのは「二股交際」

－以降、セクハラの内容を多分に含みますので、そのような内容を嫌う女性の方は、読まないでください－

昨日の、

トランザクションの矛盾回避－なぜ昔DBのテーブル名が数字だったか－
http://blog.goo.ne.jp/xmldtp/e/c77583b1d65c4accd6c8a040efb86f09

に関連したことが、日経System　２０１５年１２月号の９ページ

　RDBの真のメリットは？

にあったので、ついでにひとこと。

---

そこでは、一貫性の話として、INSERT ONLYの場合
（は昨日書いたようにINSERTでの矛盾回避は難しい）
先に子レコードから書くという話が載っていた。

でも、これでも問題が残ることがある。
入荷（＝納品）の場合を考えると、

　　納品票＝親データ
　　納品明細（各商品）＝子データ

となる。
在庫数を見たい＝入庫数をしらべるとき、
納品明細から書かれてしまうと、納品明細を書いている
途中、たとえばA,B,Cという商品が納入され、この順番で
更新するとき、A商品更新後に検索がかかると、AとBC間
で矛盾したものが検索されてしまう。
かといって、コレを防ぐ為に、親レコード（納品レコード）
が存在するかと常に聞くのは、無駄が大きい。

---

このことが、昔、問題になったことがある。

当時は、前回のように、入荷出荷の問題で、かつ、
在庫確認から、出庫まで時間がかかり、その間に
変化する可能性が大きい場合だった。

で、そのケースではどうしたか？
（その前に、すでに入る順番とかは決めてある）

誰かが思いついた・・・
（当時はセクハラなどという概念はない）
二股、三股交際すればいいんじゃない？

結婚したい相手が３人いたとする。
で、その子たちをキープしながら
（当時はこういう言い方をしたのだ）
結婚相手を１人に絞る場合・・・

３人と付き合って、つばつけておく（とそいつは言った）
そうすれば、最後に自分の気に入った１人と結婚した瞬間に
２人はフリーと、第三者は分かる。仮に当人に連絡しなくても・・・

？？？

---

つまり、DBに言い直すと、こうだ。

１．検索した時点なり、更新したい時点なり、
　ともかく、更新する可能性が起こった時点で、
　更新したい人（端末）のIDを「更新予約」という
　項目に入れておく

　　前の例だと、納品書テーブル、入庫テーブル
　　を含む全テーブルに「変更予約」という項目があり

　　納品書に新規納品レコードを、
　　入庫テーブルで商品A,B,Cの各レコードを入出庫数０で、
　　「変更予約」に自分のIDを入れて更新する。

※これが、つばつけておく（二股、三股交際）に相当

２．「更新予約」がある場合、それ相応の処理をする
　　更新されそうなレコードがある場合、どういう対応を
　　するかはさまざま。
　　ただし、一度更新予約されたレコードは、
　　自分が再度更新予約してはならない。

※交際していれば、他のやつは手を出さないだろうということ

３．実際に更新する時は、
　　・更新予約情報に自分が見たときと変化があれば、
　　　　→その間に誰かが操作した
　　　　→データ矛盾。トランザクションキャンセル

※タッチの差で手の早いやつに略奪婚された場合の回避

　　・更新予約情報に変化が無ければ
　　　　　実際に行いたい更新を行う
　　　　　更新予約レコードの予約を解除する
　　　　　　　例えば、更新予約レコードを更新予約をクリアする
　　　　　　　もしくは(INsert ONLYのときなど）
　　　　　　　　更新予約に何も入っていないレコードが書かれたら、
　　　　　　　　更新予約が入っているレコードは検索されないなど

　　　前の例だと、納品レコード、入庫レコードに
　　　　数値をいれ、更新予約をクリアして更新

※結婚したことに相当。この場合は、結婚した相手以外に通知した
　場合に相当する（こんなかんじ）


４．かりに、更新予約を修正しないで終了してしまったとする。
　その場合、システム監視をしていて、一定時間たっても更新予約が
　更新されていないレコードがあれば、システムを監視している人が、
　問い合わせるようにする。
　　その結果、更新予約しておく必要がなければ、システム監視者が
　更新予約をクリアする。

※結婚した相手以外に通知しなくてもOKな場合に相当する

---

この提案（念のために言っておく。私ではない）、
世の中的にはどうなんだ？はさておき、
結局、「更新予約」という概念は採用しました。
　

トランザクションの矛盾回避－なぜ昔DBのテーブル名が数字だったか－

まえに、

Sparkは来るのか来ないのか、Hadoopから乗り換えたほうがいいか、聞いてきた
http://blog.goo.ne.jp/xmldtp/e/789ccb053f6b7fa42efb5e21f9ad9a3c

で、

途中でてくるOCC（optimistic concurrency control：楽観的並行制御、楽観的排他制御、楽観的ロック）の話は、また別に書く


と書いた件について

---

■まず、何が問題？：わざと難しい問題設定

この話をするまえに、なにが問題か、確認しよう。
わざと難しい問題設定にする。

２つの関連あるテーブル操作のお話
たとえば、入庫テーブル（商品が入ってきた）と出庫テーブルと
あったとする。

このとき、入庫数の合計－出庫数の合計　＝　在庫数　＞＝０である。

１．今、５個入庫していて、出庫０だとする

２．Aさんは５個出庫したいが、在庫がなくなるとこまるので
　　１）５個出庫
　　２）５個発注
　　したとする

３．このとき、「なにもロックしていないと」５個出庫した時点で、
　Bさんが読み込むと、Bさんは在庫０と思い、発注をかけてしまう
　仮に５個かけたとしましょうか・・・

　この結果、Bさんに読み取られていることを気づかないAさんは、
　２）の５個発注を行い、在庫０と思ったBさんも５個発注する。
　→在庫１０個となり、在庫が積みあがる。

　たぶん、Write-Skewとかの中で、これが一番難しいケースだと思う。
　なので、今回は、これで説明する

　ちなみに、上記エントリで言ってたOCCのwrite-skew問題は、

Making Snapshot Isolation Serializable　再考
http://d.hatena.ne.jp/okachimachiorz/20130331/1364709005

の「○Write-Skew」のところ「X+Y > 0 という制約条件」・・・とかいう話

---

■なにが難しいのか

★悲観的ロックはかけられない
　まず、「排他制御すればいいじゃん。Aが書き終わるまで」
　というかもしれない。
　いわゆる、悲観的ロックだ。しかし、これは現実的でない。
　それは、シナリオを書いて、ロックしている範囲（時間）を考えれば分かる。
　
【シナリオ】
　Aさんは５個出庫したい
　●在庫検索＝商品名入力
　ロックスタート

　●在庫検索結果表示
　　Aさんは５個出庫したいが、在庫がなくなるとこまる
　●出庫画面＝５個出庫
　●発注画面＝５個発注
　ロック解除
【シナリオEND】

●が画面である。つまり、複数画面遷移して、やっとこさ、ロック解除できる
これは昔のように１アクション１画面のような同期を取る画面遷移では、
DBとの通信がきれてしまうし（でなければ、Staticでずっと、ロック＆トランザクション
を保持していることになる）非同期でも、ドンだけ長い時間ロックしているんだよ！
ということになる。

　つまり、ロックをずっとかけているのは、こんな長時間の場合、現実的でない

★デッドロックには「ならない」
　そもそも、デッドロックでは？と思うかもしれないが、それもならない。
　デッドロックは、更新しているテーブルが、交互になるときである。
　今回は
　　Aさん＝出荷、発注
　　Bさん＝発注
　なので、Bさんは、（待つかもしれないけど）２つのテーブルを操作しているわけでは
　ないので、落ちない

★楽観的ロックでもX
　楽観的ロックは「更新」日時をチェックする。
　たとえば、入荷、出荷テーブルでなく、「在庫」テーブルがあるのなら、
　　Aさん＝在庫テーブル更新、発注テーブルにレコードを「挿入」する
　　Bさん＝発注テーブルにレコードを「挿入」する
　このBさんが発注テーブルを更新するときに、在庫テーブルの更新日時を確認すれば、
　この問題は防げる。今回、Bさんは、在庫テーブルの更新日時が違っていたので、
　全部のトランザクションをキャンセルすればよい

　しかし、今回は
　　Aさん＝出荷、発注テーブルにレコードを「挿入」する
　　Bさん＝発注テーブルにレコードを「挿入」する
　新規レコードの場合、データを追加する＝挿入するのであって、更新するのではない
　ので、更新カウンターを見ない＝楽観的ロックは使えない

---

■昔の対策

そこで、昔は以下のような対策が採られた

・テーブルロックをかける順番を決めておく
・親－子－孫・・・という関係がテーブル間にある場合、
　子、孫のテーブルを修正し、親テーブルを修正しない
　場合であっても、親テーブルの更新日時を変更する
　（例：受注明細しか変更しなくても、受注テーブルの更新日時を上げる）
・子テーブルに追加するときは、その子の直上の親テーブルレコードの更新日時を上げる
　一番上の親は、「更新カウンタテーブル」というテーブル（これが、ロックをかけるとき、最上位のテーブルになる）の親テーブルのレコードに対して、更新日時を上げる
・テーブル削除は、論理削除とする。よって、修正と同じ更新日時処理をする。

こうした場合、「更新カウンタテーブル」の「出庫」「発注」レコードに対して
　　Aさんが検索をかけた時間を保持（出庫・発注1:23:45とする）
　　Aさんが出庫データ書き出し
　　　現レコード1:23:45/保持1:23:45で一致するので書き出しOK
　　　出庫レコード書き出し時間を1:23:47とする
　　Bさんも検索（出庫：1:23:47,発注1:23:45）
　　Aさんが発注データ書き出し
　　　現レコード1:23:45/保持1:23:45で一致するので書き出しOK
　　　出庫レコード書き出し時間を1:23:50とする）
　　Bさん書き出し
　　　→発注1:23:45 保持1:23:50で
矛盾して書き出せない

これを実現する為には、テーブルのロックをかける順番と、親となるテーブルを
定めなければならなかった。
　そこで、01D100などのファイル名になった。
　ここで　01:データベーススキーマ、サブシステムなど
　　　　　100：テーブルを示す。２桁目が００のものは、最上位の親テーブル、
　　　　　　　　以下110,120・・・のように数字を変えて親子関係を並ばせる。
こうすると、数字が順番に並んでいることを確認するだけで、ロックに確認が出来る

---

■技術承継は・・・

しかし、

プロセスを継承することが技術継承なのか？だとしたら、いつかは環境変化で継承できなくなる
http://blog.goo.ne.jp/xmldtp/e/0a68cbb384be26f161f314442b861106

に書いたように、この方法を継承する必要はない
今は、テーブルを数字で表現しない。
だから、このやり方でやらなくていい。

たとえば、今風にすると、ロック＆トランザクションをかけて、
その後、テーブルを更新するときに、満たさなければいけない制約をチェックする。
参照制約なら自動的にチェックしてくれ、おかしければエラーになるし、
それ以外でチェックしたければ、トリガーを組んでもいい。
（そのトリガーで制約を満たしていないことが分かったら、ロールバックする）

・・・なかんじかな。

プロセスを継承することが技術継承なのか？だとしたら、いつかは環境変化で継承できなくなる

ＣＯＢＯＬで書かれたシステムがあったとする。
そのＣＯＢＯＬプログラムをベテランから新人へ
保守を移転することは技術継承といえる。

しかし、一般的には、そのＣＯＢＯＬプログラム
をＪａｖａで書きなおした場合、技術継承とはいわない。

でも、同じ結果（おなじ出力帳票とか）の場合、
ＣＯＢＯＬでもＪａｖａでもいいんじゃないだろうか？
つまり、開発・保守「プロセス」ではなく、
出力結果の「ゴール」が同じになるように継承していけば
よいのではないだろうか？

ＣＯＢＯＬの開発・保守プロセスを技術継承していくことは
今は可能だとしても、数十年先の将来までも可能かどうか
わからない。むしろ、いつかはシステムの環境変化で
ＣＯＢＯＬの保守は、継承できなくなると考えるほうが
自然だろう。

とするならば、新しい技術を使って結果を同じにすることを
考えたほうがいい。将来、環境変化でどうしょうもなくなって
から、考えるよりは・・・

「IoT時代に求められるセーフティ設計・セキュリティ設計」のセミナー

ＩＰＡネタでもうひとつ

IoT時代に求められるセーフティ設計・セキュリティ設計
http://sec.ipa.go.jp/seminar/20151207.html

というセミナーが12月7日にあるらしい。

今はやりのIoTセキュリティですね！

IPA、教育用画像・動画・資料などフリー素材約17,000点無償提供

だって！

ここの記事

IPA、教育用画像・動画・資料などフリー素材約17,000点無償提供
http://resemom.jp/article/2015/11/12/27914.html


ただ、そのサイトがどこにあるのか、ＵＲＬがはっきりかいていない。
ここ

教育用画像素材集 :: トップページ
https://www2.edu.ipa.go.jp/


ちなみに、こんなのも見つけた！

ディジタルコンテンツ（教育用画像素材集）
http://www2.edu-ctr.pref.okayama.jp/contents/

シンギュラリティを超えたら人工知能が人間を支配するなら、野球は４番打者とピッチャーで勝てるはず！

「リーダーのためのレジリエンス 11 の鉄則」という本の１７５ページに「チームにもＩＱがあるという仮説」という話がある。「集団的知能」を決めるのは「個々のIQ」より社会性ということらしい。

　一人のＩＱが高くても、集団としてのパフォーマンスが良くなるとは限らないのだ。
　つまり、シンギュラリティを超えて、人工知能が人間より知能で勝るようになったとしても、
　社会的なパフォーマンスは（知能で決まるわけではないので）、上がるとはいいきれない。

　それはそうで、もし、個人の能力が高ければ、好成績になり、パフォーマンスが良くなるのであれば、
野球は４番打者とピッチャーばかり集めればよいことになる。

　そういうチームを作ったら、守備はボロボロになってしまうので、点をとられるけど、みんな
ホームランを打とうとするから大ぶりになり、勝てそうもないことは、想像がつく。

　ってことからしても、仮に人工知能が人間を超えても、それでパフォーマンスが上がるとは、限らなさそうだ

Ｐ．Ｓ　ちなみに、こうすれば、パフォーマンス上がるみたい

「できる」チームに共通する6つのポイント
http://www.lifehacker.jp/2014/10/141013team.html

ストレスチェックの手順と関係者をまとめてみた

こんなかんじかなあ、あってるかなあ・・・
間違ってたらごめん（なので、正しいことは、以下のサイトで自分で確認してね）

改正労働安全衛生法のポイント（ストレスチェック制度関連）
http://kokoro.mhlw.go.jp/etc/kaiseianeihou.html


■関係者とその役割

　　●制度担当者：実施計画の策定、実施者の選定等
　　●実施者：産業医等の専門家。実施、評価判定等
　　●実施事務従事者：実施に伴う事務作業を行う
　　●社員：ストレスチェック、場合により面接を受ける

　実施者は、産業医など、一定の専門家となる（自称専門家はX）
　実施者、実施事務従事者は人事権限を持ってはならない（制度担当者はOK)。

　ということは、医者でも、経営者は実施者になれない。
　したがって、会社の場合、病院などでも２人（経営者と制度担当者・実施者（産業医）・実施事務従事者・社員）ふつうは最低３人（経営者、実施者、制度担当者・実施事務従事者・社員）は必要なはず。

　このほかに、労働基準監督署（報告義務）が関係する。

■手順
（１）ストレスチェックの実施計画を策定して、調査票・評価方法等を決定する
　　→制度担当者（というか衛生委員会）が以下のことを決定
　　　実施者、実施事務従事者を誰にするか
　　　どのようなシステムを利用するか
　　　どのような調査票を使い、だれがどう評価して高ストレス者を決めるか
→調査票として厚生労働省がだしているものが、これ（Wordファイル）

http://www.mhlw.go.jp/bunya/roudoukijun/anzeneisei12/dl/150803-1.doc

　　　　　　　
（２）ストレスチェックを社員に説明して、受検してもらう
　　→制度担当者や実施事務従事者が社員に
　　　ストレスチェックを説明する
　　→説明資料は、以下のものが使える

http://www.mhlw.go.jp/bunya/roudoukijun/anzeneisei12/pdf/150511-1.pdf

　　　
（３）ストレスチェックを受検（調査票記入）
　　→社員
　　→受検していない社員には、制度担当者や実施事務従事者等が受検を勧奨

（４）ストレスチェックを集計→実施事務従事者
　　【個人に対して】
　　　高ストレス者の判定基準を決定する→実施者
　　　受験者個人への結果通知→実施事務従事者
　　　高ストレス者に面接指導を受けるよう推奨

　　【集団に対して】
　　　集団ごとの分析を行い経営層などへの報告

（５）面接指導の申し出をおこない→高ストレス者
　　　面接指導のスケジューリング等を実施事務従事者は行う
　　　高ストレス者で面接指導を受けていない場合は、実施者が勧奨する

（６）産業医の面接指導→必要があれば産業医は会社に意見
　　　会社（経営陣）は産業医からの面接指導の意見を検討

（７）ストレスチェックの受検者数などを労働基準監督署へ報告

（８）データを保存（５年間）する

国のちゃんとした図は、以下のとおり

[出典元]　改正労働安全衛生法に基づくストレスチェック制度に関する説明会資料（平成２７年４月２２日公表）
http://www.mhlw.go.jp/bunya/roudoukijun/anzeneisei12/pdf/150422-1.pdf