マイクロソフトは、「ARの軍事利用」をためらわない

っていうか、そもそも軍事でもWindows使っているんじゃないの？

マイクロソフトは、それでも「ARの軍事利用」をためらわない
https://wired.jp/2019/02/27/microsoft-ceo-defends-army-contract/

Azure Custom Visionで簡単画像認識見てきた

2月23日、オープンソースカンファレンス 2019 Tokyo/Spring

Azure Custom Visionで簡単画像認識　Mobile App開発(ios編）

を聞いてきた＆デモ見てきたのでメモ

---

・自己紹介
　資料は展開する。Tweetに必死になってくれ
　iPhone並ぶおじさんです
　DEVRELCON

・Microsoft Azure 超超概要
　２７０超のサービス、リージョン数も多い（世界中）
　なんかいっぱいある、よくわかんない
　今回はコグニティブサービスにフォーカス

・コグニティブサービス
　WebAPI経由で利用できる人工知能パーツ
　MLの予測モデルを自作せずに結果だけ利用
　（今日はモデルの作成から）

・AIを作る使う
　AI=ビッグデータ＋ML
　　　１：予測モデルの構築
　　　２：予測モデルによる推定

　Microsoft Garage

　コグニティブサービスは６つにわかれている
　　ビジョン
　　スピーチ
　　ランゲージ///


　ビジョンは７つに分かれている
　　カスタムビジョンだーびすもその一つ

　CreateML
　　Appleにも自社製の機械学習ある
　　　Swift Playground乗でMLモデルを作成可能

・デモ
　XCode MacのIDE
　MLの場合はMacOS（IoSでも）を使う
　Save→Playgroundでやったものがダウンロード→アプリ組み込み可能

カスタムビジョンサービス
　https://azure.microsoft.com/ja-jp/services/cognitive-services/custom-vision-service/
　２つまで今なら無料で
　　ジェネラルのコンパクトを選ぶ
　エクスポートできる

Custom Visionを使ったアプリ
　SeeingAI

Microsoft Learnのご紹介
・学習メニューを用意、無料

嫁型ロボット、中国で開発

いや、こういうのは日本が初めに開発しなきゃダメでしょ！

中国、世界初「AI嫁」を開発　「結婚の心配もう不要」専門家が危惧
http://news.livedoor.com/article/detail/16056014/

雑談を交わすことができ、家事をこなす。

いや、需要はそこじゃないと思うよ・・・

MySQLの雑談きいてきた

２月２３日のオープンソースカンファレンス２０１９　Tokyo/Spring　つづき

MySQL～yoku0825とsakaikが語る最新事情と周辺情報～

・雑談をしようというのが今日の趣旨

・自己紹介
　MyNA会の人

・必ず聞いてくる
　Oracleどうなの？：おカネは出してくれる
　GPLユーザーは悩むことはなにもない
　１０の約束
　MySQL単体で黒字が出ている
　　→東南アジアの政府系：サポート買うので　インドやたら行ってる
　５．７は１５０、８．０は２００機能ある
　８．０いろいろ変わった→おもしろい
　５．７以上に変わった。
　inno-DBチームと一緒になったこと大事
　　→innoDBべったり。もうべたっとくっつけて性能上げる
　　　PostgreSQLがプラガブル
　　　→PostgreSQLと同じような機能になってきた

・使えなくなったら→Maria？誰かがやってくれる？
　MariaDB：ベースが違う。５．５から分岐、そこから１０．１
　　ただし、innoDBは追従している
　昔通りの使い方をするのなら同じ
　CentOSはmariaが入っている（mysqlが入っている）
　認証プラグイン
　金もうかってるの？　ありばば→isql：最近コントリビュート

　日本MySQL「とか」ユーザー会：MyNA会でmariaの話題にしていい

　mariaに行くくらいならPostgreSQLのほうがいい
　　→誰かが助けてくれるから

・Postgreユーザー会とは？
　なかいいですよ。メーリスみてる
　中、濃い
　walの話はいいや・・

・８．０の話
　追いかけるの諦めました・・・
　よくなったところ
　WITH句　FROM句サブクエリーをWITH句で
　　店舗拉致テーブルでもそれなりに
　CDE
　性能を上げてきてからWITH句へ
　UNDOとデータ本体を分けた
　テンポラリテーブル：並列性能を上げた
　PostgreSQL：標準SQLが入ってて困らない
　　→Window関数がうごくので、MySQLでも
　ユーザーはいらないというけど、使うと便利

　select 1+2 from dualと書いてもエラーにならない

　MyISAMなくても動く、もう戻せない
　INNO DBだけで動く FRMファイルがなくなった

　DDLなげたらコミットされる→SQLにはない。PostgreSQLはドロップしてもロールバックできる
　GIS
　　緯度経度：地球のマルさを計算に入れる

　INNODBクラスタ：いろんな機能の組み合わせ（MySQLルータとかGCSとか）
　　マルチマスター：WordPress
　　MySqlクラスタとは違う・別物

・ユーザー会の紹介
　古くからやってる。２０００年３月、ちょうど１９年
　来年２０周年
　メーリングリストに登録すると、だれでも会員です。
　（会則ちゃんとないです）

・sakaiさんが、データベーステーブル設計の基礎という話をしている
　→このやり方が好き
　私db　lOVEではない
エンジニアhub
　PostgreSQLとMySQLどっちがいい

Ubuntuサーバー話を聞いてきた

２月２３日　オープンソースカンファレンス２０１９　Tokyo Springの話のつづき

Ubuntuサーバーの特徴と様々な機能

を聞いてきたのでメモ

---

今日の資料はすでにある
　https://wiki.ubuntu.com/MitsuyaShibata/Slides

結局
・インストールさえすれば、ただのLinux
　Ubuntuでも大丈夫

Ubuntuとは
・開発　Ubuntuコミュニティ、うらにカノニカル
　商用版はない
　カノニカルはサポートで
・リリースはタイムベース
　まもなく１４．０４のサポートが終了します
・長期サポート版
　通常９か月、こっちは５年
・Ubuntu Japanese Team

他のOSの違い
・ほかのLinuxディストリビューションと大差ない
・特に最近はその差が小さくなっている
　　コンテナで隔離環境
　　ホストとアプリの隔離環境の視点
　気を付ける差
　　インストールされているシステムソフトウェア
　　パッケージ管理システム
　　商用版
　　サポート期間

・パッケージ管理システム
　　Ubuntu　Apt/dpkg（でぃーぱっけーじ）
　 RHEL/CentOS Yum/DNF/RPM
　　SUSE　Zypper/RPM
　pip,npmとの併用

・リポジトリの扱い
　RHELのリポジトリだいたいUbuntuのmain/restricted
　EPELだいたいUbuntuのuniverse/multi・・・
　ubuntuは「最初からEPELが有効か済」の状態
　カノニカルによるサポート対象：メインだけ

・リリース周期とタイミング
　UbuntuのLTS：２年ごと、５年間
　RHEL：３年ごと、１０年間＋３年
・Debian：２年ごと、３年サポート＋２年LTS
・Ubuntuのポイントリリースは機能追加なく保守的
　RHELはある程度積極的

・Debianとの違い
　サポートアーキテクチャが多い
　　Ubuntuは６つ　おうちにメインフレームがある人はs390x
　システムソフト鰓に対する選択肢の多さ

・結論
　基本的な差異は「慣れ」で解決
　細かい部分はケースバイケース
　あえてUbuntuを選ばなくてもよい状態が理想

ターゲットマシンとイメージの選択
・どのリリースを使うか
　サーバー用途であればLTSが無難
　通常リリースがいる場合
　　　最新のハードウェアで動かしたい
　　　　→ポイントリリースで十分なことも
　　　　・Ubuntuのポイントリリースについて
　　　　　　１８．０４LTS；
　　　　　　ポイントリリース　２月→４．１８を使っている
　　　より新しいカーネルを使いたいとき
　　　　独自のカーネルパッケージ作成
　　　　mainline buildsを使う→動くビルドである保証ない
　　　より新しいソフトウェアを使いたい
　　　　ユーザーランドはコンテナに閉じ込めよう
　　　　　Dockerがらく LXD
　　　　　特定pyenvなどいろいろ

　デスクトップイメージは？
　　インストール直後のパッケージ構成が異なるだけ
　　　GUIが欲しければデスクトップ、不要ならサーバー

さまざまなインストール方法
・どうやって
　　Subiquity　サーバー版のインストーラー
　　cloud-init 初期化ツール　構成管理はAnsible
　　conjure-up/juju：
・物理マシンにインストールする
　仮想マシンにインストールする
　ハイパーバイザーで他のOSと併用
　コンテナにインストール

Ubuntuサーバーの運用方法
・管理アカウントの違い
　rootはロックされている
　sudo -i
　ノウハウはWikiにある
　apt関連の設定はapt_preferencesなどを参照
　リリースの更新：コマンドラインで可能
脆弱性：セキュリティノーテス
・ソフトウェアのインストール
　公式リポジトリ
　PPA
　サードパーティ
　Snap
　→基本、公式
　本いっぱいある

オフラインミーティングあるよ

　

GANの論文を訳してくれているブログ記事

GAN(Generative Adversarial Networks)｜DeepLearning論文の原文を読む #11
https://lib-arts.hatenablog.com/entry/paper11_GAN
その記事に原著論文のリンク先もある

Raspberry Pi4がいつ出るとか、SDカード壊れるよねとかいう話を聞いてきた！

２月２３日、オープンソースカンファレンス2019 Tokyo/Springで

Raspberry Pi 情報アップデート(2019/2)

を聞いてきたので、メモメモ

---

3月3日にRasPiのイベント：ひたすらハンズオン
　ユーザーグループ、なりゆきで男女半々
　→女性陣：ことしはひなまつり、じぶんたちにやらせろ！
　特徴：LED、ユカイ工学（GoogleHomeをいじったような）
　イベント登録して、買い物する→KSYから安く買える
　Microbitをスイッチサイエンス
　買い物来る人だけの登録でOK→登録しないと入れない
　場所；サイボウズさんのオフィス２７階
　　→くわしくはHPみてね！

MakerFair京都（場所は奈良です）
・ポールビーチ

Raspberry Pi4
・２０２０年に延期（UKの雑誌で出た）
　→本人に聞いた、２０２０年は目安、前倒しになるようにがんばる
　こんなに伸びた理由
　　POE HATの初期不良：１００度を超える　今はFIX
　　Raspberry PIストア　ケンブリッジの中心に
　　　オフィシャルキーボードリリース　販売されるが、はじめ英語のみ
　　　その後アジア系（時間かかる）　
　ここは５時でしまる
　ロボット、ケースも扱っている

・SDカード
　こわれたの調査中
　エンタープライズ向けでやっても同じ現象起きる
　デフラグ、バッドデータの上書き
　→現象として認識している

・コンピュートモジュール
　→eMMC,LTS
　　スピードとかは変わらない？若干早い！
　技適・・・遅れてます

・今後、どういう方向に
　RasPiファンデーション
　　　教育
　　　製造
　　　出版：まぐぱい→出版しにくい　（まぐぱいはやすい。数か月たつとタダで配る）
　　　　　　ワイヤーフレーム、ハックフレーム
　日本の事例を増やしている

・DVB-T
　テレビチューナー　日本で出ない
　　チップ：日本の地デジ　プロプリエタリ→ソニーがオープンソースにならないと

・４が出るまでの余興系
　エベンは日本に来たいと言っている

・コーダ―どうじょう、コードクラブ、会社は残っているけど、一緒に
　　→コード開発に
　先生不足：オンライントレーニング
　翻訳協力：おめがーTではなくて、
　　　ローカライゼーションマネジメントツール：機械翻訳してくれる

Gitを再入門してきた！

2月23日、オープンソースカンファレンス２０１９　Tokyo/Springに行ってきて、

いまさら聞けない人のためのGit超入門

を聞いてきたのでメモメモ（一度聞いた気がするけど）

---

（会社紹介の途中から入場）

・会社紹介

・本日のアジェンダ

・Gitを利用した開発モデル
　Gitを利用したバージョン管理
　　分散開発
　　プルリク（マージリクエスト）
　　　プルリク：引っ張ってください
　　　　→メインストリームに取りこむ：マージ
　　　→いきなりソースを取り込まれない
　　ほかのツール
　　　　Jenkins,Redmine

・git-flow
　マスター
　デベロップ
　　→ブランチ
　　　　プロダクトバックログのいくつかまとめて名前を付ける

・GitLabを使って試してみよう
　Githubの有償版はオンプレがおおい
　今日のデモ：GitLab Community版　本もある
　Cent OS →yumで一発（リポジトリ登録必要）
　　　オムニバスインストール
　　　インストールの最後、最後コケるChefがうまくは知らない
　　　　　→sudo gitlab-ctl reconfigureする


　GitLabの管理単位
　　ユーザー
　　グループ
　　プロジェクト

・初期設定：読んでください
　　　管理者、初期ユーザー作って

・ユーザーでプロジェクト作成
　　　ユーザー認証必要になる場合もある

　リポジトリの種別
　　　ローカルリポジトリ
　　　リモートリポジトリ
　　→非同期、pushしないといけない

・ローカルリポジトリの確認
　　.git隠しディレクトリの中に実態

　ステージングとコミットの関係
　　リポジトリ：データベース、複数持てる→ブランチ
　　ローカルリポジトリ―にコピー：チェックアウト→作業ディレクトリ変わる
　　コミットすると、使っているブランチに入る→使っていないブランチには入らない

・リポジトリにファイルを追加
　１．作業ディレクトリにファイル追加
　２．ファイルをステージング
　３．ステージングしたファイルをコミット
　４．コミットしたファイルをリモートにプッシュ

・デモ
　developで作成
　　viでかく
　　git add
　　git commit

　マージする
　　git marge develop

　修正の重複
　　コンフリクトが通知される
　　一回プルする
　　修正
　　ローカルコミット
　　マスタプッシュする

・ブランチ戦略を考える
　人数、規模感
　コミット、マージの頻度・粒度
　テストの頻度、リリース頻度
　タグ：バージョン管理タグ

・この先に考えたいこと
　テスト駆動やチケット駆動との連携
　　Recmine,slack
　テストの自動化、チケットの自動化

・DevOpsの想定されるするめ方
　　１．ToBeモデルの構築
　　２．現時点での課題の抽出
　　３．優先順位の策定
　　４．PoC環境の構築と運用
　　５．PoC環境からのふぃ０度バックと改善
　　６．小規模社内展開
　　→自社だけでは困難

・DevOpsを始める前に悩むこと
　　どのインフラ　
　　どのリポジトリ
　　情報共有方法は？
　→誰かが決めてくれよとなる

・DevOpSaaSが解決する課題
　標準リファレンスモデル提供によるDevOpsの加速
　・各種ツールの組み合わせテスト済みパッケージの提供
　・各種ツールのバージョンアップ

・サポート環境
　開発
　　CirtcleCI
　構成自動化 Ansible
　　CloudFormation
　インフラ Kubernatis
　　AWS EKS
　運用監視 Prometheus
　　DataDog

・改めて大募集

※ブース行ってね！

Windowsパッチの署名がSHA-2へ一本化でWindows7は・・・

Windowsパッチの署名がSHA-2へ一本化 ～Windows 7は7月までに対応を済ませないと更新不能に
https://forest.watch.impress.co.jp/docs/news/1170465.html
（以下引用）

Microsoftは、Windows向けの更新プログラムで“SHA-1”の署名を廃止する。レガシーOS（Windows 7 SP1、Windows Server 2008 R2 SP1およびWindows Server 2008 SP2）や一部の古いバージョンの“Windows Server Update Services（WSUS）”では、デバイスを“SHA-2”コードサイニングに対応させるための更新プログラムをインストールする必要がある。
　「Windows 7 SP1」および「Windows Server 2008 R2 SP1」の場合、この更新プログラムは3月12日にスタンドアロンのセキュリティ更新プログラムとして提供される予定（「Windows Server 2008 SP2」は4月9日）。7月16日のアップデートを適用するには、この更新プログラムの適用が必須となる。

「おまえJSONもわからないの？」・・・言った途端に会社は損害賠償、あなたはクビかも！

飲み会で話題になったテクハラ

むかしは「●●も知らないの？」といって、マウンテンしてメシウマしている
人がいたけど、危ないよね、今、そんなことしたら、損害賠償で訴えられるし、
会社首になるかもしれないもんね。

仕事できないからって、会社首にならないけど、
どんなに仕事できて、頑張っても、テクハラで訴えられたら、一発退場でクビじゃん！
っていうはなし。

具体的に分かりやすく書いてあるサイトがあった。

ITが苦手な人への嫌がらせ「テクハラ」 会社に改善を要求できる？
https://www.bengo4.com/c_5/n_780/

読んでもらうとわかるけど「請求できる」

つまり、

「おまえJSONもわからないの？」・・・

といって、相手が人格権を侵害されたと思えば、
テクハラ（パワハラの一種）として訴えることができて
言った人間にも、会社にも損害賠償責任がある。

普通、会社に損害賠償をさせるほどの損害を与えたら懲戒免職だよね！
違法行為したんだから・・・っていうことで、一発退場でクビ！

・・・マジっすか！

チャットボットのカオスマップとか、AIの領域のマッピングとか

メモ

チャットボットをまとめたカオスマップ公開（2019年版）
https://jp.techcrunch.com/2019/02/14/chatbot-caosmap/

AIの事業領域
ＡＩに関する米国主要プレイヤの事業領域マッピング
blogs.itmedia.co.jp/business20/2019/02/post_1678.html

おまけ

あなたたちは、本当に「AI開発プロジェクト」をやる気があるのか？ (1/3)
https://www.itmedia.co.jp/enterprise/articles/1808/30/news010.html

SASのオープン・AIプラットフォームをPythonから―Python向けAPIパッケージ DLPy

良くわかっていないので、メモ

SAS Viya：Python API向けパッケージ：DLPyの最新版1.0拡張機能概要紹介
https://blogs.sas.com/content/sasjapan/2018/11/01/sas-viya_dlpy10_new_feature1/

セールストークって、機械学習できるの？

セールストークを機械学習させるとすると、

他人がしゃべったセールストークの特徴ベクトルと、
その結果（教師信号）を学習して、

結局、他人がしゃべったセールストークをパクるわけだよねえ・・・

他人のセールストークを丸パクリではちっとも売れない当然の理由
https://www.mag2.com/p/news/384737

「マイナンバーカード、保険証に」って、

保険証代わりにしたら、マイナンバーカード持ち歩く人も
多くなるだろうから、なくしたりしないのか？

個人情報保護とか大丈夫なのか・・・

と、不安になるニュース

マイナンバーカード、全病院で保険証に　21年3月から
https://www.nikkei.com/article/DGXMZO41217110T10C19A2SHA000/

なぜ、プログラムは書けるのか：計算論からゴールによる様相論理、意味論まで俯瞰してみる

Hello worldの次は何やったらいいという人は、自分は本当になにをしたいのか問うほうがいい
https://blog.goo.ne.jp/xmldtp/e/761fd2136761fed4867a9e5de22ee1a4

で「２．２プログラムを学びたい場合、計算論とかの話になる。これは別エントリで」と書いた。
それについて

つまり、プログラムを書くとは？というのを突き詰めていくと、どうなるのか？
→サブテーマとして、プログラムは作成可能なのか？その根拠は論理的に説明できるのか？
　　→説明できないとしたら、どこかに論理のジャンプが起こることになり、
　　　　　論理的にプログラムは書けない＝プログラムで論理性を養うというのはおかしい
　　　ことになる。

あんまり詳しくないので、
ロリポおじさん程度の不正確さで書くので、まあ、大目に見てやってください
（書いてあること、信じないでね！）

---

【プログラム→計算可能まで】

プログラムを書くとはどういうことかを調べるのは、まずはいくつかのプログラミング言語で書いてみたり、調べたりすることになる。
そうすると、プログラムは大きく２種類の箇所に分かれていることが分かる

　　・意味的には各言語共通で表記方法が違う
　　　　　：足し算、引き算などの四則演算など

　　・各言語ごとに特徴があり、目的に応じて使う
　　　　　：Java等のクラス、Cのメモリアクセス（＝ポインタ）

ここで、目的の話はしないことなので、上のほうをつきつめる。
表記法はさておき、意味的に考えて、コンピューターはなんでも計算できるのか？

これは、計算可能性という話で、計算論という学問分野になる。
大きく２つの方法で議論できる
・１つは、チューリングマシン
・もう一つは、ラムダ計算。この分野には教科書的な本が昔あり（高橋正子「計算論 計算可能性とラムダ計算」）そこに出てくるけど、一般的に計算を定義して、どのようなものが計算可能か定義する（これは資源を考えない。資源を考えると計算複雑性という話になる）

この２つは、チャーチ・チューリングのテーゼによって、同じこと言っているということになる。


【ラムダ計算→型つきラムダ計算】

　ところが、ラムダ計算で「正しさ」を議論していくと、不完全性定理のコンピューター版みたいな話（一階述語論理の決定可能性問題）になる。つまり、「正しいかどうかは停止しない限り判断できない」

　そこで「正しい」ということが証明できないとこまるので、「強く正規化する」（つまり停止する）ものが求められた。そこでカリー・ハワード対応、型つきラムダ計算が出てきて（ただし、型つきラムダ計算の中には、強く正規化しないものもあるようだ）。この型つきラムダ計算は、Javaで出てくる多態性（ポリモーフィズム）なんかを議論したり、圏論へと広がっていく。また、型の話は、型と命題の関係にいく。ここから先の話は後述の「では、仕様をどう表現するか：意味論」へつづく。

　一方、「正しい」ことを証明する話は、「形式仕様」という議論の場に移っていく。この形式仕様では、仕様を論理的に記述して正しいことを示す「形式仕様言語」(Z,B,Event Bなど）と、正しいかどうかは証明できないけど、正しくない場合には検出する「モデル検査」(SPINなど）が出てきた。形式仕様言語の場合、正しいことを証明するには停止しないといけないが、そもそも、組み込みのプログラムは停止しないから、証明できなくなってしまう（なので、組み込みは、モデル検査やシミュレーションをよく使う）。証明は大変なので、自動定理証明が出てきたり、証明支援が出てきたり（coqなど）・・・っていう広がりを見ている。


【要求仕様をプログラムに実装できるか】
　今までの話は、どんなもの（WHAT)が計算可能かという話だった。これとは別に、どうやって（HOW)要求仕様から設計プログラミングに落とし込めるかという話が「別に」ある。実務上では、要求仕様→設計→プログラミングといくが、ここに一貫性があるのか、完全性を保ちながら要求仕様からプログラミングまでの変換は可能であるかという話だ。「ない」となったら、「トレーサビリティマトリックス」とか作っている私たちの立場は？ってことになる。

　実際、「一貫性はない」という意見があった。

　要求仕様は「WHAT」を定義していて、設計は「HOW」を定義している。WHATはHOWに”とらわれてはいけない”（要求分析者は設計方法に左右されずに要求を出さないといけない）。だからこの間には断層がある。これが佐藤正美氏の提唱する「SDLCの断層」だった。この論理はウォーターフォールではまあいいんだけど、アジャイルになると、設計と要求定義は混在化してくる。そうすると、あちらこちらに断層ができて、一貫化したプログラムは作れない！という話になる。

　一貫性がないなら、一つの視点で表現することができない。結果として、ふるまいの部分はアクティビティ図、構造はクラス図など、様々な図を使って仕様を表すUMLが広まった。が、これらの図は、何がどうつながっているのかが分かりにくい・一貫性が見えない・完全性は大丈夫なのかわからない事態を生みだした。

　しかし、Lamsweerdeがゴールという概念を用いてKAOSという手法を提唱することにより、この断層はなくなった。そして、UMLの各図はKAOSから導きだせることが、1冊の本(Requirements Engineering: From System Goals to UML Models to Software Specifications)で示された。

　KAOSの考え方は、様相論理を用いる。システム化に成功するということは、「現状Pから、システム化に成功した状態（要求を満たした状態）Qへ、いつかは状態遷移すること」である（P→□Q）と考える。そしてこのP→□Qをゴール（一番初めに定義するゴールをトップゴール）とよぶ。そうすると、ゴールの状態Qを表現すること（WHAT）が要求定義であり、設計とは現状Pから状態Qに状態遷移させる方法を考えること（P→□Qの→に相当）である。となる。つまり、２つの行為は１つのゴールで表現できる。

　そしてこのゴールP→□Qを「何らかの手法で」分割し（詳細化・洗練という）、さらにそのゴールを分割して・・・と分割していったとき、すべてのゴールは、ある人によって実現可能なプロセスを実行することによって達成されるならば、全プロセスが実行されたときにゴールは達成すると考える。
（なお、ここでは達成ゴールを紹介した。ゴールにはほかに、回避ゴール、維持ゴールなどあるけど、詳細な説明は省略。似た話だから）

　これにより、どうやって（HOW)要求仕様から設計プログラミングに落とし込めるかという話は、システムのトップゴールP→□Qから、どうやって詳細化を行って、実行可能な末端ゴールに一貫性（完全性）を保ちながら分解できるかという話に帰着した。この完全性を保ちながら分解する方法は、What部分を分解する要素分解と、状態遷移を分解するマイルストーン分解を行えば可能でありそうということを直感的に言っている人もいるが、数学的にはまだ証明されていない。ここが最前線。

　なお、(Requirements Engineering: From System Goals to UML Models to Software Specifications)の表紙には、バベルの塔が書かれている。システムをUMLの様々な図というか言語（UMLのLは言語のL)で表した混乱を、この本で終止符を打つということでしょうか？日本はともかく、世界的にこの本は要求仕様の教科書となっている。

【では、仕様をどう表現するか：意味論】

　ただ、ここではP→□Qの状態PやQの表現方法については議論していない。なので、次は「状態はどのように表現できるか。単なる記号ではなく、意味を持った形で表現できるのか？」ということが議論の対象になる。

　現状は、この状態（要求仕様）を自然言語で書いているが、それだとあいまいになる。そこで、論理式で書くことになる（そもそも、様相論理なので、論理式だよね）。記号を論理式で書く・・・この方向は、記号論理学の話から、ミニマリストプログラム、CCG(Combibatory　Categorial Grammars)、DisCoCatへとつながっていく。ここら辺が最新なの？

　また命題と型とが結びついて、すべての命題がある型であるというホモトピー　タイプ　セオリー（HoTT）が出てくる。型つきラムダ計算から来た流れは、この辺が最先端？

　でも、これらも１つの表現方法だけど、実際のプログラムでは、項目と値によるエンティティモデルやクラス・オブジェクトで表現したりする。

　さらには、AIの世界だと、特徴ベクトルという形で状態を表現し、その特徴ベクトルの演算を考えるようになってきた（Word2Vec)この辺が、先端かしら・・・

　ということで、意味論の分野は、論理（命題）、型、特徴ベクトル、項目と値を、どんな感じで「まぜまぜ」するのかが話題。　＜　いまここ。


【ちゃぶ台返しの量子コンピュータ】

　ここで、ちゃぶ台返しが起こる。量子コンピューターは、これらの流れと全く違った計算方法をする。いわく、ブラとケットがでてきてブラケット・・・わけわからん。

　そのうえ、もっとわけわからんことが起こってる。いわく

・答えは、「これ」と求まらない。確率的に求まる（は、はい？？）
・アルゴリズムがないと、計算できない

　そのアルゴリズムで、素因数分解するものは、ある。ショアのが。
　で、これでパスワードが無効になるとか言われて話題になっている（サイエンスZEROでも再放送してた）。
　
　もう一つ、行列式は解ける。このアルゴリズムがある。

　で、さっきの意味論に戻ってくる。特徴ベクトルは行列で表してるけど、それなら、量子コンピューターでも扱える？
　この辺っていうか、量子コンピューター全体が先端


【量子コンピューターとAI：不確かさ】

　量子コンピューターは確率的に答えが求まるけど、AIの機械学習も確率的に求める。
　いままでのバチンと答えが求まるものと違う。

　このような確率的、不確かななかで、どう計算するのかというのが先端の話題。
　不確かさの中でのAIのテストとか、不確かさの中での形式仕様PATとか
　不確かさについて扱うのが、今先端。

　今後は、確率論的ということで、ベイズが入ってくるか？入ってくるならどんな感じで？
　なんかが、近未来的な話なのでしょうか・・・



【で・・・】

　こんな話、おもしろいですか？

　おもしろいなら、プログラムを学ぶことを目的にすることもアリだと思うけど、
　（将来、量子コンピューターの方向に進むなら、いままでの勉強は無駄になっちゃうけど・・・）

　たぶん、こういうことをやりたい人はごくわずかで、プログラムを「作る」のが楽しいんではなくて？