「これだけモデリング」と、「これだけじゃない要求開発」を聞いてきた！

６月２８日、要求開発アライアンスの
日経SYSTEMS４月号 要求開発特集企画 『執筆者が語るこれだけじゃない要求開発』
を聞いてきたのでメモメモ

---

■さらなるダイエットに挑戦する「たったの「これだけモデリング」」
・自己紹介

・再び「これだけ」モデリングの勧め
　こんなに強力なのに今一使われていない。なぜ？
　どのくらい役に立つかわかっていない。とくに上流で
　使いどことが間違っているのでは
　今でも忙しい。これ以上負荷を増やしたくない
　なくてもやてる。あえて必要ない
　敷居が高い、たくさん勉強しなければならない
　それぞれの場面に適したレベルの「これだけ」モデリングがある

・アジャイルではモデリングが不要か？
　アジャイルではモデリングが不要なのか
　間接コミュニケーション媒体としてのモデリング
　　ドキュメントによる役割間の情報受け渡し、チーム内情報共有は不要
　　少数多能エンジニアチームでは、単なるオーバーヘッドへ
　直接コミュニケーション媒体としてのモデリング
　　ナプキンモデリングは口頭伝達を超える
　　　言葉より手っ取り早くて正確に伝えるメモ的モデルは有効
　指向ツールとしてのモデリング
　　全体構造や複雑な構造を可視化して考える
　　手ぶらで下手な考えより図に起こして整理する

・損益分岐を突破するモデリング
　パフォーマンス
　　効果の高いところに集中して適用する
　コスト
　　ミニマムのレベルに抑えて学習コスト・ランニングコストを下げる
　　徹底的だんしゃり

・モデリングにおけるだんしゃりポイント
　　ダイヤグラムの種類
　　記法
　　利用シーン
　　目的
　　気軽に
　　ツールを使う

・ＵＭＬのダイヤグラム構成
　　１３種類
　　せいぜい４～６種類で十分
　　○ユースケース図、アクティビティ図、シーケンス図、クラス図
　　△パッケージ図、状態マシン図

・モデルによる業務とシステムの連携

・上流で使うのは、さらに限られている
　　ユースケース図：ビジネスユースケース図
　　クラス図：概念クラス図
　　アクティビティ図：業務フロー図

・ビジネスユースケース・業務フロー・システムユースケース
　業務とシステムはバラバラではだめ。

・システムユースケース
　　ユースケース記述
　　　　その中の機能一単

・クラス図
　　概念クラス図
　　（分析）クラス図
　　設計クラス図
　　データ設計図

・英検２級レベルで、１級レベルは使わない（通じない）

・モデリングのそもそもの使いどころ
　全体構造を捉える
　　業務の全体の流れや構造を知る
　　・業務全体、システム全体図
　複雑な部分を整理し、理解する
　　特に理解しにくいところを集中的に分析する
　　ホットスポット、考え方の難しいところ
　構造や動作を設計する、検証する
　　業務やシステムの中の主要動作を組み立てしみゅれーシィんする
　　　ワークフローやフレームワークで実現する
　　　As-IsとTo-Beを比較し、課題が化いけるされることを検証する
　抽象化して本質的な概念、構造、メカニズムを捉える
　　　共通性や根本原理に迫る
　　　　アナリシスパターン、汎用システム設計

・目的に合わせたレベルのメリハリモデリング
　　範囲
　　　業務・システムの中でモデル対象にする部分を絞る
　　粒度
　　　業務フローなどでしばしば問題
　　詳細度（粒度とややかぶり）
　　　詳細化過ぎるとかえって本質がみえない
　　抽象度
　　　根本原因までさかのぼる必要は、ほとんどない
　目的を考えるとおのずと適切なレベルが決まる

・小難しくない、萎縮させない
　モデリング原理主義（アンチパターン）に陥らない
　ユーザーを巻き込む：難しい記法は、メモなどで代用する
　ミニマムセットを設定する

・ツールを使う
　Excelや手持ちの汎用ソフトでは生産性が低い
　アナログ的アプローチもある程度ＯＫ
　何といってもastah*

・モデリングの目的をはっきりさせる
　　全貌の理解
　　詳細（複雑なもの）の理解
　　伝達
　　記録

　　スケッチ　　　　　何を書くか
　　設計書　　　　　　どの程度書くか
　　プログラム　　　　どう描くか

　　下記捨てる
　　中間生成物として使う
　　最終成果物として残す
　　保守資料としてメンテナンスする

・企業システムでさらに広がるモデリングビーズ
　　企業システムの疎結合課
　　　ドメイン分割→マイクロサービス
　　えんたープライズアジャイル
　　企業システムのＡＩ化

・古典的アジャイルとエンタープライズアジャイル
　　→要求開発とアジャイル開発の究極コラボ

・エンタープライズのＡＩ化
　ロジック
　固定ルール
-----インテリ---------
　経時変化する経験知：機械学習
　暗黙知　　　　　　：ディープラーニング

■開発に先立つ前さばきで要求の全体像をつかむ
・自己紹介

・本来の要求開発の使用用途
　ビジネス分析
　要求開発：
　　　準備（課題設定からゴール設定）→
　　　立案（現状分析）→
　　　デザイン（あるべき姿のデザイン）→
　　　シフト（システムが担うべき役割）→ＲＦＰとか
　システム開発

・なぜ、システム開発の前さばきが必要か
　技術要素が先行し、目的が明確でない
　要求があいまい

→けっこうわけわからない要件定義が出てくる

従来の開発対象
　会計システムの場合
　　お手本になるモノが存在

開発対象の変化
　　従来の開発
　　　参考となる実体が存在する
　　　開発対象のスコープが限られている
　　　システム化の選択肢が限られている

　　いまどきの開発
　　　参考となる実態が存在しない
　　　システム要求の自由度が高い
　　　システム化の選択肢が多い

・時間をかけずにポイントを押さえる
　ＦＰＭ（ふぁいぶぽいんとめそどろじー）rede編（りくあいあめんとでべろっぷめんと、要求開発編）
　ポイントをつかんで効率よくシステム化の土台作りをする

　プロジェクトの本体の目的を明らかにする
　　１．プロジェクトの前提を整理する
　　２．要求の全体像を捉える
　　３．ゴールを設定する
　　　　→１かげつだと、このていど
　立案フェーズ・デザインフェーズ
　　４．業務分析・新業務設計

　シフトフェーズ
　　５．システム要求の明確化


ポイント１：プロジェクトの基本情報を整理する
　プロジェクトを進めるうえでの前提条件
　　→プロジェクト定義書
　　　（要求開発アライアンスで出している）
　　　　超上流を極めるための要求開発入門
　　　　　→不明点は確認する

　ステークホルダーを確認する
　　→ステークホルダーリスト
　　　　　ＢＡＢＯＫ，ＰＭＢＯＫ：ステークホルダーリストをつくりなさい
　　　（要求開発アライアンスで出している）
　　　　超上流を極めるための要求開発入門


ポイント２：要求の全体像を捉える
・要求が漠然としていると感じる理由
　　ステークホルダーの立場の違い
　　人は自明なことは省略して話す
　　要求分析ツリー
　経営　　　業務管理者　　　システム要求
　
ポイント２：ゴールを設定する
・最終的に達成すべきゴールを設定し、ステークホルダー間で共有する
　システム化により得たい成果について、達成時期や、達成の判断基準を示す
　ゴール記述書
　　　（要求開発アライアンスで出している）
　　　　超上流を極めるための要求開発入門
　　定量的に表す

まとめ
・要求開発は時間をかけずにポイントをつかんで要領よく
・要求開発のステップをフルセットで実行するのではなく、ウィークポイントを効率よく整理する
・１００点は求めない

主にPlay Framework、一部WildFly Swarm、ときどきSpring

６月２７日、【東京】JJUGナイトセミナー Javaフレームワーク特集 - WildFly Swarm / Play Framework / Spring Bootに行ってきた！
んだけど、はじめ補欠で、もう直前（３０分前くらい）に参加できることになったので、
はじめのほうは、聞けかなった。

途中から、メモメモ

---

■WildFly Swarm - Rightsize Your Java EE Apps
（資料はここにあるみたい）

フラクションの説明（途中から）
・Arquilian（あきゅりゃん）
　・JUnix、TestNGのテストをやるとき
　・Swarmは持っている
・NetFlixのOSSもとりこんでいる
　Ribbon
　　同じサービスを使いたい人
　Histrix
　　サーキットブレーカー
　　エラーの伝搬を食い止める（とりあえずのレスポンス）
・サービスのTopology
　・サービスディスカバり
　　consulでの例
・KeyCloak
　・認証、認可に対応したＳＳＯ（OAuth2とか）
・Swagger
　・ＪＡＸ－ＲＳからドキュメント、モックを作る
　・@API等のアノテーションを書く
　・SwaggerUIによるドキュメント化
・Spring/SpringBoot
　・アプリケーションをSpringでつくっているとき
　　　→対立する必要はない

便利な機能
・Project-stages.yml
　・ステージごとにいろいろ書ける

コミュニティ
・いろいろある
　Twitter,Googleグループ、IRC（活発）
・ドキュメント充実
・サンプル豊富

最後に
・WildFly Swarm Tour

所感
・まだＧＡではない
・まだ色はついていない
・生かすも殺すもコミュニティ次第

ＱＡ

---

■The High Velocity Web Framework For Java and Scala

・自己紹介

・免責事項
　PlayはJavaのフレームワークではない
　　Ｗｅｂのフレームワーク
　→Play2はScala

・目次

・アンケート
　Struts1,2
　Springおおいですね
　JavaEEおおいですね
　Play　ぱら

・playの歴史
　登場した経緯を理解しないと・・・経緯おさらい
　Play1 おおむね1.2
　Play2
　play3の計画も

　しーさーは、EOLを迎える
　Struts2 バグフィックス番号多い
　Spring盛り返している
　Rails ことし５．０？

・Play1の歴史
　２００９～２０１１
　　Java6,SAStrutsなど→Java停滞感
　　→Railsほしい
　→play1
　　２０１０年　playはサーブレットを使っていません
　　HTTP ステートレス
　　サーブレット→ステートフルになってしまう
　　Javaを拡張し始める
　　Javaの非合理な慣習をやめる（多少やりすぎ感？）
　　熱狂的ファンもつく
　→play2へ
　　Webはリアルタイム：Scala使う

・Play2の歴史
　Ｊａｖａ復活
　AWS本気
　フレームワークの世代交代
　　ＭＶＣフレームワークの先
　Scala（アプリはJavaでも書ける）
　ＳＤＴ（しんぷるでぷろいつーる）
　バージョンアップするたびに変更
　akkaと統合
　　Reactive Platform
　akka
　　並行分散処理フレームワーク
　lagom
　　マイクロサービスフレームワーク

・Playの特徴
　Webフレームワーク
　　サーブレットコンテナ：やらないほうがいい
　　→Struts2などの移行先としては？
　　Jettyで動く
　　ステートレスアーキテクチャ
　　　キャッシュAPI
　ホットリロード
　　サーバーを再起動せずに同期
　スキーマ管理
　　Evolution
　フルスタック
　　Web開発に必要な機能をデフォルト機能
　モジュール

　Java/Scala API

　非同期処理
　　Play2：基本的に非同期

・Playの使い方
　インストール
　プロジェクトを作る
　　　テンプレートを探して
　　　Activator UI
　　　IDE
　アプリケーション
　　ディレクトリ構成重要
　　　モデル
　　　ビュー
　　　コントローラー
　ルーティング
　　リバースルーティング
　動作確認
　ＪＳＯＮ
　その他の機能
　　ドキュメント

・Playの利点／欠点
　Play1
　　安定している
　　Javaなので、軽快
　　欠点：いろんなところで、いろんなものとぶつかる
　　　　　そろそろ限界
　　　　　サポート体制
　Play2
　　Scalaのデファクト
　　リアクティブ
　　欠点：下位非互換(scalaも）
　　　　　コンパイル速度

・まとめ
　Play1,2ある
　サーブレットに依存していない
　使い方
　利点欠点

---

■From Zero to Hero with REST and OAuth2

・ライブコーディング

・自己紹介

・Spring Boot
　Spring:Javaのフレームワーク　ケーキでいうところの材料
　Spring Boot：フレームワークのフレームワーク　出来合いのケーキ

・Spring Initializr
　　→ひな形

・今日はOAuth2

・REST 作成
　組み込みサーバー立ち上がる
　かんぺは、後でツイートする

　ＨＡＬ：ハイパーテキスト・アプリケーション・ランゲージ
　　→ＵＩとかつくってくれる。Swaggerみたいなもん

　ページング＆ソーティングレポジトリ
　　ページネーション、ソーティングする
　ＳｐｒｉｎｇＤａｔａＲｅｓｔ
　　ＣＲＵＤ以外は、イベント処理で追加
　今までと考えを変えてRESTを簡単に

・OAuth2
　認可のためのトークン払い出し
　　リソースオーナー
　　クライアント：アプリケーション
　　オーサライゼーションサーバー：トークン払い出し
　　リソースサーバー：ＲＥＳT

・Resource Owner Password Cradentials

・OAuth
　アノテーションをつける
　　黒魔術という人に→ソース読め
　エンドポイントとか、いろいろつくる
　@enable resource server　トークン払い出した人の情報

・リソースサーバー　認可

・SpringBootだと認可つくるのかんたん。

・ＵＩサーバー

・ログインフォーム

・ＪＷＴ（ＪＳＯＮ　Ｗｅｂ　Ｔｏｋｅｎ）対応

・まき家の例

・ＡＪＡＸもかんたんに　ずーる

・ＪＳＵＧ　Ｄｏｏｒｋｅｅｐｅｒで
　芸人見てね！

---

ごめんなさい、３つめのまきさんのは、
デモだったんだけど、よくわかんなかった（＾＾；）
ので、メモメモできてません。

IoTは、今までのエンタープライズ的発想や通信制御の考えと根本的に違う

っていうことを念頭に入れないと、わけわからん話になる。

ほんと、一桁ちがう、巨大システムが出来上がってしまいそうに
なったので、いちおう、自分の発想をシェアしてみる。

---

■エンタープライズや、通信制御には、「手順」がある＝ステートフル

　この「お手順」を守ることが、大事※
　例えば、初期化して、そのあと、現在状態を返して、そうしたら・・・
　というような状態遷移があったり、

　この申請書を出して、そうしたら、誰さんが承認して、そうしたら、次の人が承認して
　OKだったら、許可証を発行して・・・
　というような状態遷移があったり、

　とにかく、状態遷移がある。

　そして、状態遷移には、かならず、「その状態に遷移しなかったら？」というエラー
　処理がついてくる。


※ちなみに通信制御手順は、
　　　「つうしんせい・おてじゅん」という通信制大学の式次第を指すのではなく
　　　「つうしんせいぎょ・てじゅん」という通信の制御の手順を指す。
　しかし、英語になおすと、どっちもプロトコルだから、問題ない）

---

■IoTは、無線で行う部分が出る。無線は、必ずしも繋がるとは限らない。

　のだ。ということは、必ずエラーが起こり、エラーが起こったときにメッセージを
　送信すると、そのメッセージも繋がらずエラーに成り、それが・・・

　・・・エラー処理を考えたとたんに、むちゃくちゃ複雑になる。

---

■状態遷移をなくす。

　この原因は、状態遷移があるから。
　・状態遷移をなし（ステートレス→RESTful）にすれば、
　・そして、処理に失敗したら、失敗したことがわかればいい。
　・あとは、その情報を使う側で、よきにはからえ
　としてしまえば、事態はめっちゃ簡単になる。

---

■つまり、IoTの場合

・センサー側は、サーバーに、現在の状態と現時刻、識別子を送信する
　送るのは、一定時間または変化が起こったとき
　　→表示などの都合は関係ない。
　　　　サーバーが立ち上がっていなければ失敗する。けど構わない

・表示側など、アクチュエーターは、サーバーに、必要なところの状態を問い合わせ
　サーバーは、結果（状態）を返す
　問い合わせるのは、一定時間または問い合わせたいとき
　　→センサーが欠測したかどうか、などは、アクチュエーター側が考える

・サーバーは、センサーの情報を受けて保存し、表示側の要求に基づきデータを返す

これだけの処理でいいことになる。
これらの処理は、完全独立になる。

---

■業務に応用した具体例

たとえば、業務で、
　　　申請書を出し、
　　　それをAさん、
　　　Bさんが承認し、
　　　その後許可書を発行
する場合

　従来の考えだと、申請書発行、Aさん承認・・・などステータスをつくる。
　ここで、Aさんが承認しなくてもBさんが承認すればOKとか、
　　　　　Aさんの承認範囲には制限があるというと、
　状態遷移がややこしくなったりする。

でも、上記IoTの考えだと
　　　申請書を出し、
　　　　　申請書出したよセンサー
　　　それをAさん、
　　　　　Aさん承認すべきもの表示
　　　　　Aさん承認したよセンサー
　　　Bさんが承認し、
　　　　　Bさん承認すべきもの表示
　　　　　Bさん承認したよセンサー
　　　その後許可書を発行
　　　　　許可書発行すべきもの表示
　　　　　許可書発行したよセンサー

とすると、それぞれ、センサーは、
　　　　申請書出したよセンサー：「申請書出したよ」→サーバーでさいばん
　　　　Aさん承認したよセンサー：「何番の申請書をAさん承認したよ」
　　　　Bさん承認したよセンサー：「何番の申請書をBさん承認したよ」
　　　　許可書発行したよセンサー：「何番の申請書の許可書発行したよ」
を、サーバーに書き出せばよく（書き出せない場合は何度もリトライすればよい）

表示のときは、
　　　　　Aさん承認すべきもの表示
　　　　　Bさん承認すべきもの表示
　　　　　　　は、どちらも、申請書を出していて、
　　　　　　　かつまだ承認されていないものを返せばよい。

Aさんが承認できるかとか、Bさんが承認したら良いかとか、
そんなことは、表示アプリ側で考えてくれ。

許可書発行も、とにかくAさん、Bさんから承認されて、
許可書が発行されていないものを全部返す
許可書を発行するかどうかは、表示アプリが考えてくれ。

許可書発行したものは、実は申請書以降のデータはいらない。
だから、削除していいけど、そんなことはサーバーが考えてくれ
表示もセンサーも、知ったこっちゃない。

というふうに、状態を考えずに、全く独立して組める。

---

■ちなみに・・

　このモデル、ないしは類似のモデルが、マルチエージェントだと黒板モデルだし、
　IoTだと、MQTTなどで使うPub/Subメッセージングモデル(出版-購読型モデル)

　類似のモデル（発展形）としては、これだと、表示側は、センサーが変化したとき、すぐに対応できない。
　また、一定時間ごとにアクセスすると、アクセス量が膨大になる場合、
　センサーに異常が起こったときや、一定時間ごとにサーバーがブロードキャストするという方法もある。

「MySQL5.7入門 レプリケーション編」を聞いてきた

６月２９日、MySQL5.7入門　レプリケーション編を聞いてきたので、
内容をメモメモ

---

マニュアル
　５．７は英語版のみ
　５．６　日本語も併記しているけど（修正・追記が反映されていない可能性）

・MySQLの高可用性構成のパターン
　レプリケーション
　Oracle clusterなど共有ディスクにデータを格納
　MySQL-DRBD Linux用のノード間データコピー
　MySQL Clusterシェアードナッシング型高性能クラスタ
　　Active-Active

　MySQL Cluster→MySQLの姉妹製品

・複合型の高可用性構成例
　共有ディスク＋レプリケーション
　MySQLクラスター＋レプリケーション

・ＭｙＳＱＬの歴史
　昔から人気の高い機能（３．２５から）

・レプリケーションとは？
　データの複製（レプリカ）を別のサーバーにもてる機能
　ＭｙＳＱＬの標準機能で、多数のＷｅｂサイト等で利用されている
　　シンプルな設定で利用可能

・補足
　サーバーは、マスター・スレーブまたは両方になれる
　マスターは複数のスレーブを持てる
　５．７からスレーブは複数のマスターを持てる

・レプリケーションの利点
　参照性能の向上
　　参照処理は、スレーブサーバーを追加することで、負荷分散できる

　高可用性の実現
　　マスターの障害時に、スレーブをマスターに昇格することで実現可能

　地理的冗長性の実現
　　地理的に離れたサイトに、災害対策サイト

　バックアップサーバーとして利用
　　スレーブサーバーでバックアップを取得することで、マスターサーバーに影響を与えずにバックアップ取得可能

　特定用途ＤＢ

・レプリケーションの仕組み
　マスターサーバーでのすべての変更点をバイナリログに記録
　　発行されたクエリのうち、更新系の処理内容のみを記録しているログファイル
　　トランザクションコミット時に記録
　　　→sync_logbin=1にする。
　　システム変数log_binを指定して出力
　　　５．７から、server_idも必要

　　バイナリログ
　　　バイナリ形式で記録
　　　mysqlbinlogコマンドでテキスト化可能
　　　ROWがデフォルト→ログが大きくなる

　　　基本的には、マスタとスレーブのテーブル定義を合わせる
　　　例外的に。変えて使っている人もいる

　スレーブからレプリケーション開始

　バイナリログの内容をスレーブに転送し、実行

　relay log
　　logslave_update

・スレーブの存在するファイル、スレッド御
　ファイル
　　リレーログ
　　バイナリログ
　　master.info
　　relay_log.info

　スレッド
　　Ｉ／Ｏスレッド：リレーログ書き出し
　　ＳＱＬスレッド：ＤＢ反映

・レプリケーションの種類
　バイナリログの記録方式による違い
　　ＳＢＲ　ＳＱＬ文→伝搬できない処理がある
　　ＲＢＲ　行イメージをもつ
　　ＭＢＲ　きほんＳＱＲ，非決定的はＲＢＲ　
　
　　　伝搬できない処理
　　　　非決定的なＳＱＬ文＝実行するたびに結果が変わる可能性があるＳＱＬ
　　　　→時刻など
　　
　同期方式による違い
　　非同期：非同期レプリケーション
　　準同期：スレーブが受け取ったこと確認してから返す
　　→障害が起きた時違う
　　　リレーログからＤＢ更新は同期とってない→製品によってはこれを同期と言っている
　　→準同期でも、まったく同時に参照処理を投げた時、同じ結果を返すことは保証していない

　　タイムアウトの設定もできる

　ＧＴＩＤを使用する、しないによる違い
　→５．６から追加
　　グローバルに一意にトランザクションを識別できる
　　自動的に、スレーブが判断、フェイルオーバーも

　ＧＴＩＤの制限事項
　Create Table・・・select
　Create Temporary table
　drop temporary tableをトランザクション内で使えない

・レプリケーションの設定方法（ＧＴＩＤ有効）
　レプリケーション用のパラメータを設定
　マスターサーバーにレプリケーション用ユーザーを作成
　マスターたーバーのバックアップを取得して、スレーブサーバーにりストア
　スレーブサーバーでCHANGE MASTER TO
　スレーブサーバーでSTART SLAVE

・パラメータ設定
　マスターに以下オプション
　　server_id
　　log-bin
　　datadir
　　gtid-mode=on
　　enforce-grid-cinsistency=on

　スレーブはサーバーの他に
　　log-slave-updates
　　read_only にしておくといい→しても、管理者は更新できる
　　port,socket　テスト用の時に設定いる時ある

　マスターサーバーにレプリケーション用ユーザーを作成

・バックアップを取得して、スレーブサーバーへりストア
　コールドバックアップ
　　りストア後にスレーブのdatadir配下のauto.cnfを削除

・mysqldumpでバックアップを取得してりストアする
　　かならず-flush-logsと-single-transactionを指定する。
　　
　注意事項：mysqldumpによるバックアップ中、ＤＤＬ文を実行しないこと
　（Ｄｒｏｐ　Ｔａｂｌｅとか、TRUNCATE TABLEとか）保証できない。

・スレーブサーバーでCHANGE MASTER TO
　スレーブサーバーでSTART SLAVE

・バイナリログの管理
　なにもしなければ、溜まり続ける
　　→expire_log_daysで自動的に消すこともできる
　SHOW MASTER STATUS
　SHOW MASTER LOGS
　FLUSH LOGS
　PURGE MASTER
　RESET MASTER　全部クリア

　SHOW BINLOG EVENTS


・スレーブ側
　START SLAVE
　STOP SLAVE
　スキップしたいときは、空のトランザクション作る(begin,commit)

・考慮事項
　　ＭｙＳＱＬレプリケーション単独では、用意されていない機能
　　 Connector/Jのロードバランス・フェイルオーバー機能
　　　jdbc:mysql://primary,sl1,sl2
　　 mysqlnd_ms

　ＭｙＳＱＬ　fablic1.5
　　高可用性とシャードによる拡張性
　　MySQL Router：ファブリック対応してなくても、ファブリックコネクタ

　一度に大量の更新処理を実行しない
　　→トランザクションを細かく分割する：遅延をすくなくするため
　　多重でやっていても、シングルスレッドにしてしまう
　　　→マルチスレッド

　レプリケーションが正しく運用できているか監視する
　　MySQL Enterprise Monitorで監視可能
　　　→商用版　エンタープライズ版
　　　　レプリケーションモニター
　　（はずれるけど）
　　クエリ解析機能　MySQL Query Analyzer

　　チューニングもサポート

　パフォーマンススキーマのテーブルの中に、レプリケーション情報も入っている
　スレーブをクラッシュフェースにしたい→５．６で実装；リレーログをＤＢで

　レプリケーションのフィルタリング

　Olacle Clusterwareを使える（条件満たせば無料）
　Enterprise Editionなら、サポートも受けられる

・MySQL Clusterを利用している所

文系女子大生がMacを選ぶ、たった1つの明快な理由

おしゃれだから。以上。

文系女子大生がMacを選ぶ、たった1つの明快な理由
http://www.itmedia.co.jp/pcuser/articles/1606/29/news041.html

ＩＯＴのシステムをＵＭＬを使って設計するフロー

ちょっと話す機会があって、
こんなかんじかしら・・・
って、説明したのをシェアシェア！

---

（１）いちばん、やりたいことの中心のシナリオをまとめる
　・人感センサーで、店内の通行量をはかり、３０秒おきに、本部に送って結果が見れるようにする

（２）なんについて、何で、何をするか、決める
　　→「なんについて」をユースケース、「何で」アクターにすると、ユースケース図が書ける
　・例「なんについて」：人気スポット集計（いいのか？この名前で）
　　　「何で」人感センサー、本部、

（３）上記（２）で決めたことを実現する為に、必要なものや事前にやっておくことを
　　　考えて、ストーリー（シナリオ）を作る

　・例：人が通ったら、人感センサーがON
　　　ONになったら、端末で、人数１UP
　　　端末は、３０秒ごとに本部にデータ送信、送信後、カウントを０に
　　　本部は、端末からデータを受け取り、DB登録
　　　本部は３０秒ごとに店舗交通量表示画面をリフレッシュ

　　→ストーリー（上記の例のようなもの）を、ユースケース記述とする

（４）上記（３）で出てきた「もの」を、１レーンとして、ユースケースごとに、業務流れ図を作成する
　　このとき、入出力を明確にして書く。
　　　　入力は、通信・DB以外として、センサーと画面がありえる
　　　　出力も、通信・DB以外として、アクチュエーターや画面・帳票・Excel等ファイルがありえる

　・例：
　　　　人、センサー、端末、本部を各レーンとして、
　　　　業務流れ図を書く
　　　　※レーンはアクター以外もありえる
　　　　（上記だと、アクターにイベントを起こす「人」や、
　　　　　内部の資源である「端末」も入る）

　　→業務流れ図がアクティビティ図になる

（５）業務流れ図をもとに、シーケンス図を作成し、
　　　メッセージ交換内容を明確にする

　・例：アクティビティ図から、メッセージが発生するのは
　　　　人感センサーと端末：GPIO？ならON/OFF
　　　　端末と本部：時間＋場所＋人数、これ以外のメッセージ居る？

　　→シーケンス図を描きましょう

（６）データ入出力部分の画面や、DBなど、決まっていないものの項目を決める
　　　画面は、画面定義書（＝画面遷移図＋画面レイアウト・画面項目定義・アクション定義）
　　　DBは、DB定義書（＝ER図＋DBテーブル（項目）定義）
　　　というかんじで・・

　→画面遷移図は、書く気になれば、状態遷移図で表現できる
　　DB定義書は、クラス図で表現できる


（７）上記（４）で作成した、業務流れ図を、レーンごとにみる。そうすると、
　　　どっかから、「イベントが起こり、一連の処理をして、どっかに飛んでいく」
　　　という流れの繰り返しになる。

　　　このとき、「イベントが起こり、一連の処理をして、どっかに飛んでいく」
　　　を１つの状態とする。
　　　そうすると、１レーンごとに業務流れ図をみると、
　　　・何かの処理をしている状態と、
　　　　何もしていない状態の繰り返しになる。
　　　　各状態の遷移を、状態遷移図であらわす。

　・例：端末のレーンに着目する
　　　「センサーからONが入ってきたら、カウンターを１上げる」という状態と
　　　「３０秒ごとに、本部データ送信、カウンターを０に」という状態がある。
　　　上記状態を「センサーON」、下記状態を「本部転送」とする。

　　　ただし、ここで、何もしないという状態が問題になる。
　　　「センサーON」と「本部転送」が独立して起こるなら、何もしない状態は、
　　　「センサーOFF]と「転送まち」状態になるが、
　　　「本部転送」中は「センサーON」処理をしないのであれば、何もしない状態は
　　　「センサーOFF＆転送まち」状態の１つとなる。
　　　これは、仕様により判断する。

　→状態遷移図は、ステートマシン図です。

（８）上記（７）の業務流れ図には、（４）で入出力を書いた。
　　なので、（７）で振った、どの状態のときに、どの入出力を行うかわかる。
　　また、（５）のシーケンス図は、（７）の業務流れ図の状態に対応できるはずなので、
　　（どちらも同じ（４）の業務流れ図を基に作っているから）
　　その状態のときに、どのメッセージを投げるかがわかる。

　　そこで、各状態において、どのような入出力と、メッセージが必要かを、
　　（４）の業務流れ図と、（５）のシーケンス図をもとに、状態ごとにまとめる。

　　例：端末
　　　case センサーONのときは、
　　　　　　GPIOから、どこかへ保存
　　　　　　break;
　　　case 端末のときは
　　　　　　保存データを読み込み、（５）で考えたメッセージを作り、本部へ送信
　　　　　　break;

　→これは、もう言葉で書くかんじなので、UMLつかわない。

（９）実装する
　　Arduinoのプログラムで、状態がどのときは。。。とか、コーディングしていく

（１０）テストする
　がんばれ！


いじょう・・・

Raspberry Piによる、板書画像を自動的に切り出す「自動ノート取り装置」

あとで読むので、ＵＲＬをメモメモ

講義を写した動画から板書画像を自動的に切り出す「自動ノート取り装置」がすごいと評判
http://internet.watch.impress.co.jp/docs/yajiuma/1007390.html

一般道自動運転用オープンソースソフトウェアであるAutowareって、何？

講演があるらしい

一般道自動運転用オープンソースソフトウェアの開発環境
http://jp.mathworks.com/company/events/conferences/automotive-conference-tokyo/2016/abstracts.html

「Surface 3」後継不在のまま終了へ

Surface 4が今後、登場するかどうかは分からないが、
とりあえず、「Surface 3」は２０１６年で生産終了ってこと？


「Surface 3」後継不在のまま終了へ　薄幸なシリーズに未来はあるか？ (1/2)
http://www.itmedia.co.jp/pcuser/articles/1606/27/news096.html

PoC（概念検証）による開発リスク回避について、日経Systemsに詳しく書いてある

今月号（２０１６年７月号）の日経Systemsの特集が

新ITの恩恵を生かす技術リスク攻略法
PoC、開発プロセス、マイクロサービス

で、PoC（概念検証）を行うことによるリスク回避の方法について、
PART４で書いてある。

そのまえに、PoCをどういう契約にしたほうがいいか（准委任）
はPART3の５３ページ

PART1の４５ページに開発の流れと、PoCの位置づけがある。

いままでの開発は、
・要件定義
・基本設計
・詳細設計
・実装
・テスト

とあったけど、基本設計の前（超上流のあと）に、「企画／提案」フェーズを
おいて、そこでPoCを行うかんじ・・・

佐賀県システム、１７歳の少年に破られる

＜不正アクセス＞「最先端の佐賀県システム破られるとは」
http://headlines.yahoo.co.jp/hl?a=20160627-00000039-mai-soci

最先端・・・っていうけど、このシステムを破ったのは・・・


不正アクセス容疑　数万人の情報流出か　１７歳少年再逮捕http://mainichi.jp/articles/20160627/k00/00e/040/130000c


の１７歳の無職少年・・・

サイエンスＺＥＲＯのディープラーニングをメモメモ

６月２６日、サイエンスＺＥＲＯの

No.548
人工知能の大革命！ ディープラーニング
を見たので、その内容をメモメモ

---

３月人工知能が囲碁棋士を破る
→可能にしたのは、革新的技術

ディープラーニング：壁を乗り越える
・これまでの人工知能を劇的に進化
　人間の脳を模倣
　例：認識する力　一瞬で探し出す
　　　想像する力　言葉→画像を作る：連想
・ディープラーニングの可能性に迫る

今、革命が起きている
ディープラーニング：深層学習
　人工知能に学習をさせる技術の一つ
　人間が無意識にやっていることをまねできる
　武器：自分で学習する
　画像認識の分野で精度を高めた

人物を識別できる人工知能
・特定したい人物を選ぶ
・カメラ；共通点のおおい人物を選ぶ
・同一人物を検出

従来：顔を正面から照合→監視カメラうまく認識できず
ディープラーニング：目的の人物が横を向いていても、後ろを向いていても
　→防犯用に期待

ディープラーニングの特徴学習
・画像のどこを見れば、自動的に
　与えるのは、画像データだけ
　ディープラーニング：人間気付かないところも

松尾先生登場

人を見分けるどうして：特徴を学習
→その人らしさ、できるようになってきた

例：数字の３　３らしさ：３の特徴
　人間にはできる、機械には難しかった
　人間が特徴を考えているのには限界があった
　ディープラーニングは、機械が考える
　→人間の脳を模倣する

学習、経験：関連するニューロンを強化
何層にも渡して作る
強くしていく

例：手書き
数字の３
・画像を細かく分解
・最初の層：小さな単位→小さな特徴を捉える
　次の層；少し大きな特徴
　次の層に進み、大きな特徴
　最後：全体像
・同じ種類をたくさん見て、特徴を学習する
・平均的な３の形
・脳と同じネットワーク→特徴抽出

汎用性が出てきた

３が入る：
　　点があるか、線があるか、
　　まるっこく、線が途中
　　３という字がとらえられる

いろんな３をみせてあげる
　　違った特徴反応
　　ここだけは外してはいけないという特徴
　　→どの３にも共通→３という概念

がんを検知する人工知能
　むねを３つのほうこう→可能性
　人間並みの精度、つかれしらず

ディープラーニング：画像認識にとどまらない
　複合的な認識
　別の感覚も認識できる
人間：統一的に
　ディープラーニング：統合学習

おがたさん、複数の感覚
　視覚と聴覚
　色と音階
　ベルの色　音階　２つを別々に学習、統合
　カメラを切って音を鳴らす→色が分かる
　人間特有の感覚を身につけられる

ロボットにモーション：関係性を教える
　運動をカメラで学習
　ロボットに目隠し
　運動→想像→映像を連想

連想する力

ディープラーニング
　音響、運動にも利用できる：統合しやすい

今までの手法：別々に
ディープラーニング：統合的に

言葉の理解：青い空
・人工知能が想像した画像
・検索でなく、書いている
　どうして→運動と映像の統合
　画像→言葉：関係性を学ぶ
　そうすると、言葉から絵
・自動翻訳へ
　意訳ができるようになる（画像を介すから）
　→作家いらなくなる
　意味理解も少しずつ

これから
・ディープラーニングと強化学習
　ロボットがだんだんうまくなりながら
　つかみ方を教えてないのにつかむ
　　→いままでできなかった

・認識の問題
・どこを持てばいいのか
・１４台がいっぺんに学習→経験を共有
　誰かが試験勉強したらコピー
・作業が上手：収穫ロボットがなかった

人工知能と人間の違い
人間：生命：生き残る、子孫
人工知能：目的を見つけることはない

IoTxAIxインフラ時代の最新技術、やってみたSPのJuly Tech Festa（ＪＴＦ）2016

チケット、買った？買った！
くわしくは、以下のサイト

http://2016.techfesta.jp/

Twitterのタグ「#自民党に質問」が炎上中らしい

Twitter「#自民党に質問」がたいへんな事になってる…
http://matome.naver.jp/odai/2146660736358141001

ま、一言でまとめるとこの国をどうしたいのですか？だねえ～

日本ものづくりワールドに行ってきた！

６月２４日、日本ものづくりワールドに行ってきた！（ビッグサイト）
いや～、たしかに人いっぱいで、人気ですね！
見切れなかったでしたよ・・・

西ホールの「機械要素技術展」は、試験とか、ばねとか、ねじとか表面仕上げとかの、
大手もあるけど、中小も多いというような感じで、こまごまとした感じ
（一部は、にぎわってないけど）まあ、けっこう人いっぱい。こまかくは見てこなかった。

で、東は「機械要素技術展」も一部あるんだけど、「設計・製造ソリューション展」とか
「３Ｄ＆バーチャルリアリティ展」など。

・３Ｄは、プリンタに限らず、スキャナ、ＣＡＤ,３次元センシング、いろいろ展示があったし、にぎわっていた。
・機械学習も一部あったね。予防とかの話で、それとIoTというのも見たけど、他の展示ほどではない。
・ＣＡＤみたいなのは、iCAD,オートデスク、ソリッドワークスが奥の方にあって、なんか人気っぽい。
・ＰＤＭ（製品データマネジメント）がそこここに、ＥＲＰとからめて
・一方ＰＬＭ（製品ライフサイクル管理）はＳＣＭにからめた展示もあった。これも、そこここに
・産業用機械とか、それに関する技術はそこここにあるのは、当然なので省略
・あーとにかく、人いっぱいだったよ、それにつきる・・・

感想としては、ものづくりまだまだ健在そう。
実際には、ＩｏＴで、コンピューターで制御するというよりも、
シーケンサーが連携(CC-Linkとか）して自動化のほうが、ありえるんじゃないかなあ？
（っていうのが、ここの話につながっていくわけ）