世界最大の配送会社UPSはなぜ、最短距離を走らないのか

自分の研究に関係するんでメモ

世界最大の配送会社 UPS が効率化に成功した意外な秘策とは？
http://gereports.jp/post/158429014824/ups-dont-turn-left

自分へのメモ
運搬経路問題（vehicle routing problem）

SQLServerをSUSE LINUXで稼動できるようになる話を聞いてきた！

３月１５日、

Suse Expert Days 2017

に行ってきた！の続き。後半の内容をメモメモ

---

■スピードと柔軟性を向上させるためのこれからのIT環境のクラウド化
　・これからのIT環境をどうすべきか
　・IaaSとPaaSの併用で始めるクラウド化
　・これから選ぶクラウドの選定ポイント

１．これからのIT環境をどうすべきか
　２つにわけられる
　(A)今まで出来なかったことを実現する
　　　新規事業：
　　　　Uberはマイクロソフトのクラウド活用
　　　　　　顔認証チェック
　　　→SaaS,PaaSが増えている　例：Office365

　(B)今まで出来ていたことを早く、安く、簡単に実現する
　　　Webサーバーの立ち上げ
　　　　→社内手続き、拡張するのに投資
　　　クラウドでIaaS（リフト＆シフト）

２．IaaSとPaaSの併用で進めるクラウド化
　コグニティブ：同じ人？年齢、性別　サマーランドの入口カメラ

・IaaSで柔軟性とコスト最適化を両立する選択肢
　　SQL Server + SLES HA
　SQL ServerのLinux版

　IaaSで実行環境の構築を自動化
　　ARM（Azure Resource Management)のテンプレートで出来ること
　　　　最適なデプロイ、べきとうせい
　　　　リソースをまたいだ構成
　　ARMテンプレート
　　　Githubでテンプレートを公開

・PaaSで自動運用型Webサイト構築
　　スタジオ　カラーさん

・デモンストレーション
　　Azureの中のLinuxマシン：いま３分の１だが、増えている
　　サブスクリプション：プリペイドカードで買うことも出来る
　　PaaSでも

・エンタープライズクラウド選定のポイント
　スケーラビリティと事業継続性
　セキュリティ・コンプライアンス
　出来なかったことが出来るか→デジタルトランスフォーメーション

　マイクロソフト：いかなる国でもクラウド内の情報を開示しない

　ビデオ

・グローバル規模でのビジネスを支援するスケーラビリティ
　３４の地域でサービス中（３８まで予定）
　地球約５６周分の光ファイバ
　日本で２つのリージョン　SAP　HANA　ワークロード
　Hadoop最適化
　Azure+SUSE+SAP→アビームで

　ビデオ

・マイクロソフトはオープンで柔軟なクラウドを提供します
　デベロッパーセンターでSDKやサンプルを提供
　Azureフォーラム
　AzureOSSコミュニティ・ブログ

---

■Software Defined Storage
　OpenStack最新ソリューション

（ごめん、説明した人の日本語がよくわからなくて？
　聞き取れなかった。適当にコトバが、以下並んでいる）

・トラディショナルなエンタープライズストレージの課題
　　値段高い
　　スケールと管理難しい
　　SDDCむずかしい

・SUSEエンタープライズストレージ
　コモディティサーバーとディスクドライブ
　Cephアーキテクチャ

　ブロックデバイス　オブジェクトストレージ　ファイルインターフェース
　　　　RADOS(コモン　オブジェクト　ストレージ）

　ユースケース
　　Bulkストレージ
　　ビデオサービランス
　　データアーカイブ

・HPCストレージ

・OpenAttic
　　デモ

・ロードマップ


●OpenStack
　なぜ使っていないのか？
　大企業の８１％は使う予定
　９３％はIaaS

・SUSE　OpenStack Cloud
　速くて簡単
　ハイパーバイザーサポート
　SUSE OpenStack7
　OpenStack
　　６つのコア
　　他のプロジェクトもサポート

・SUSE OpenStack Cloud7
　　Day2管理
　　コンピュートノードHA（KVM,XEN)
　　構成サポート：Magnum,Kubernetus
　　ハイパーバイザーの選択とサポート KVM,XEN,Z/VM,VMWare
　　JeOS(じゅーす）ミニマム

・SUSE Open Stack ロードマップ

・SUSE コンテナ　あず　あ　さーびす（CaaS)プラットフォーム

・CloudFoundry

●SUSEが提供する開発ツールチェーン
　SUSEの由来（ドイツ語）
　　Software
　　Und
　　System
　　Entwicklung
　→ソフトウェアとシステム開発

・開発ソリューション
　モジュール式オープンソースソリューションスイート
　Open Build Service(OBS)
　　ソースをOBSに提出
　　パッケージ化して
　　KIWIでイメージ作成→Docker,ISO

　JeOS
　　最小構成ホスト
　　　目的に応じ、それに何かを足す
　　Machinery　高度なシステム管理モジュール

　OpenQA
　　自動テストインフラストラクチャー
　　OpenSUSEとSUSE Linux Enterprise
　　　様々なコードパスとインストールオプションをテスト
　　　アウトプット：ログファイル、画像

　ツールチェーンモジュール
　　新しいコンパイラとツールチェーンを提供する
　　コンテナモジュール
　　　Portusで安全にコラボレーション
　　コンテナとイメージの管理
　　　コンテナアプリを外科的にパッチ
　　　　コンテナとイメージチェック
　　　　セキュリティホール見分ける
　　　　イメージのアップデート

　SUSE Developer Program
　SUSE Linux Enterprise 12 For Raspberry PI
　　ダウンロードできる
　　Raspbianとの違い：カーネル、６４ビット、ブート、ルートファイル

　　

なぜ、機械翻訳が素人考えで、プロは翻訳メモリを使うのか？

「人工知能が変える仕事の未来」を聞いてきた
http://blog.goo.ne.jp/xmldtp/e/6089e0ee0fb3f8734273e8e06acc69ef

で「機械翻訳→経済的に使い物にならない」と書いてある。
この前に、「素人は良く思いつくんだけど」みたいな事を言ってた気がするけど、
じゃあ、プロはどうしていて、

どうして、
　素人は機械翻訳をやろうとして失敗し、
　プロは翻訳メモリを使うのか
について、説明しようと思う。

これを説明すると、今の人工知能の限界が分かると共に、
機械翻訳っていうのが、どんだけ「無茶しやがって」
なのかがわかる。

でははじめる

---

■翻訳のプロは、翻訳メモリを使っている

例えば、あるソフトを日本語化するときとかは、
十印とかに依頼すると思うけど、そこでは
翻訳メモリを使って日本語文が作られる（らしい）。


翻訳メモリ（ほんやくメモリ、英語: translation memory）は、原文と翻訳文を一対としてデータベース化し、その内容を自動的に繰り返し利用することで翻訳を支援する翻訳支援ツールである

Wikipediより

つまり、
　英語を訳すのではなく
　既に訳した文を元に、それを効率的にコピペする。

手順としては
　　はじめに画面などから、いくつかの単語を取り出す

　　それを（場合によっては何人かの人＝翻訳スタッフ各人に）訳してもらう：仮訳

　　訳したものを持ち寄り、違いを見つけ、統一見解を出し、そのように訳す
　　　　用語統一

　　用語統一した単語を、辞書に入れる

　　この辞書に入れた単語をベースに訳していき、翻訳メモリに入れていく

こうすると、翻訳メモリをベースに訳語が統一されたものができる。
用語統一した時点で、プログラムチームだけでなく、マニュアルチームにいったりする

私が関わっていた頃はこんな流れだけど、今は、この分野発展したので、
大きく変わってるかも。今は、TMSになってるのかな？
たぶん、Tradosが有名なのは、変わっていない？
フリーではOmegaTすくしょはここ

---

■そもそも、翻訳には、２つのケースがある

「It's fine today」を「今日は晴れです」と訳した場合を考えよう。

このケースには、２つの場合がある。

（１）日本語を知ったアメリカ人が、「It's fine today」を
　　「今日は晴れです」と訳した場合と

（２）英語を知っている日本人が「It's fine today」を
　　「今日は晴れです」と訳した場合（って、普通こうは訳さないけど・・）

（１）は、
　アメリカの文化を知ったアメリカ人が、
　日本語の知識を元に、
　日本人なら、こういうだろうと「妄想して」
　つけた訳文

（２）は、
　日本の文化を知った日本人が、
　英語の知識を元に、
　多分、こういうことを言いたいんだろうと推測して、
　つけた訳文

　アメリカ人でも、「It's fine today」というのを見たとき、
　　２通りの意味があることは、想像がつくと思う。

　一つは、　「今日は晴れです」
　もう一つは「マイクのテスト中」

　どちらのことを言っているかは、コンテキストからわかる。
　だが、日本の文化で、マイクのテスト中は
　「本日は、晴天なり」というということまでは、妄想できないかもしれない。
　なので、どっちかの訳になる。

　日本人は、日本の文化で知っている。
　なので、コンテキストでマイクのテスト中だと分かれば、
　「It's fine today」を　「今日は晴れです」ではなく
　「本日は、晴天なり」と訳すだろう。
　場合によっては、「チェック・ワン・ツー」と訳してもOKだ。

　つまり、

・文化によって、訳文は違うのだ。

・そして、訳される文化のほうにあわせないと
　訳の意味が変わってしまう可能性すらある

・逆に、意味さえ通じればよいのなら、
　シチュエーションさえ分かれば、
　元の言葉わかんなくっても、OKなときある
　（上記でIt's fine todayを仮に知らなくて
　　チェック・ワン・ツーって訳してしまっても、
　　原文みてない人には、OKだ・・・いわゆる超訳）

---

■なぜ、「機械」翻訳でなく「日本人が翻訳メモリを使って日本語で訳す」のか

機械翻訳は、どういう文化を理解しているのか、さっぱりわからないから。

　英語と日本語の対を学習させたのでは、

　　日本の文化を理解してるのか、
　　アメリカの文化を理解しているのか
　　別の国の文化をりかいしているのか
　　何の文化もりかいしていないのか

わからない。

例えば、神Excelということば、
この言い方は、なんでも神にしてOKな日本だから、ゆるされる。
これをアラビア語にして、イスラム圏の人に行ったら・・・
・・神を冒涜してる！とか言われて、大変なことになりそうです（＞＿＜！）

翻訳メモリを使う話は、実は、翻訳メモリが大事なのではない。
日本人が日本語にする点が重要。

はっきり言って、ソフトなんて、使い方とデータが分かれば、
パネルに書いてある言葉なんて、大体想像つく。
英語が読めなくても・・・

なので、英語は、想起しやすい目印程度でいいのだ。
日本語でつじつまが合うことが重要。
だから、日本人が訳をチェックし、
そのチェックを支援する翻訳メモリをプロが使うということ

はじめに、用語統一するのは、表面的な言葉の統一をしているのではなく、
そのソフトの世界観とか、日本におけるそのソフトの特徴づけとかを
用語を通じて統一してるわけ（カルチャーを統一しているわけね）

---

素人は、翻訳の裏に文化があり、その文化が違うと、
おかしな文になるということを知らないし、
ましてや、文化を理解させるのに、どれだけ学習させないと
いけないかなんて、まだ分かっていないということを知らない
だから、機械翻訳といってしまうけど、

翻訳するくらいなら、日本人がテキトーに画面見て、
言葉つけてったほうが、まだましなのだ・・・

それほど、文化って、影響大きい。
その文化の理解までは、機械翻訳は行っていない。

カメレオンとペンギンが抱き合う動画見てきた！

３月１５日、

Suse Expert Days 2017

に行ってきた！ので、その内容の前半をメモメモ
（表題の動画は、始まる前に流れていたので、
　以下のメモには出てこない
　ちなみにカメレオン　＝SUSE)

追加１２：４５
動画、抱き合うところは

What Does the Chameleon Say? (Ylvis - What Does the Fox Say parody)
https://www.youtube.com/watch?v=VNkDJk5_9eU
の１分５０秒のところで、SUSEっていっているところは、このビデオなんだけど、
前の部分がっていうか、大部分が違う
見てきたビデオは、ホットパッチを当てる話なんだけど・・・

---

■Define your future with SUSE

①SUSEの全体の方向性
　　｜－④クラウド
　－－－－－－－－－－－－－－－ーーーーーーーーー
｜　　　　　　｜　　　　　　｜　　　　　　　　　　｜
②Linux　③運用管理　⑤ストレージ・OpenStack　⑥開発ツール

デジタルトランスフォーメーションを支えるテクノロジーとそれが目指すもの
　Time to Market
　アジリティ
　低コスト
　カスタマーセントリック
　クオリティ、セキュリティ、RAS
　　↓
　オープンソース
　　クラウド、◎コンテナの登場、◎マイクロサービス、aaS、DevOps

　最適組み合わせを見つけてUpdateしていくのは、とても大変？

　SUSEによる「Spftware－Defined」インフラ
　　オープンソースと標準APIで構築
　　オープンソースといいながら垂直統合で囲い込み？
　　SUSEでそろえるのではなく、既にお使いのもの、他社のものも大歓迎
　サーバー、スイッチ、ストレージ
　　カーネル４．４をいち早く採用
　　SAP用、HPC用など、用途別製品
　　～用途のLinux
　Software Defined Everything
　　各種のハイパーバイザーやSDNを幅広くサポート
　ストレージ
　　Cephをベース、ノード単位課金、戦略的価格
　　SUSE自身でストレージを出す
　プライベートクラウド、IaaS、PaaS
　　もっともDeployしやすいOpenStack、HPEさまから開発リソースを買収
　　SUSEがインストール競争で勝つ
　　CloudFoundryにコミット
　コンテナ、マイクロサービス
　　Kubernetes,Magnumに投資
　運用管理
　　SUSE Managet : RHEL,CentOSも管理できるパッチ管理
　　OPEN ATTIC,Salt等

最近のトピック
・オープン　コンテナ　イニシアチブ、
　クラウドネイティブ　コンピューティング　ファンデーション
　Zero Outage（ダウンタイム０）
　Cloud Foundryのボードメンバーに
　パートナーシップ
　　富士通　ハイブリッドクラウド、ビジネスクリティカル、コンテナ技術
　　インテル
　　HPE　Preffered LINUXに
　　SaltStack　自動化

製品
　リリース
　　SUSE　Linux　Enterprise 12 SP2
　　ARM Raspberry Piサポート
　　SUSE Enterprise Storage 4
　近日
　　OpenStack Cloud7(Kubernetes)

SUSE
　２５年前、商用ディストリビューションとしてドイツで
　親会社、マイクロフォーカス
　HPと統合すると＄４B企業へ
　８％の伸び
　SUSEを中心としたエコシステム

オープンソースコミュニティに貢献するには？
　まずはコミュニティエンタープライズの要求を
　The Open,OpenSource Company
　タグラインにこめられたSUSEの哲学
　　We adapt,You Succeed
　逆が多い
　　You adapt,You Succeed

---

■SUSE Linux　エンタープライズ　Server SLES（すれす）最新動向

・デジタルエコノミーの要求：ベンダーロックインされない
　ソリューションの適用

・SLESロードマップ
　　SLES 11 SP4　２０１５年７がつGA　２０１９年
　　SLES 12 SP1
　　SLES 12 SP2
　１２　カーネル４．４　SP3開発中
　ライフサイクル：１０年標準、３年拡張
　勝手にSP2にはあがらない
　HPC・・・ARM　SP3で
　12SP2　カーネル４．４
　　→HPCとミッションクリティカル中心
　NVDIMM,XEN4.7,TPM2.0,GNOME3.20
　SUSE LINUX Enterprise for ARM
　　ARMを使ったHPC事例
　１２SP3
　SUSE コンテナ　AS A サービス　プラットフォーム

・KIWI(きゅーい）
　Workload/OS Image Templating
　→イメージを作る
　→外向けにしたのがSUSE Studio
　　オンライン版あり、アカウント作って
　　ラックスペースなどが利用
　JeOS(じゅーす）とコンテナ

・マイグレーションユースケース
　オンライン・マイグレーション・パス
　　オンラインで挙げることもできる
　　　→ワンステップごと？スキップする？：注意いることも
　オートメーション：メディアから

・フットプリントを軽く
　１２から考え方変わる
　　ベースOS:コアOS　その他：エクステンディット（メディアに入っている）
　HPCモジュールも別だしで
　　→OPEN HPC　ファアンでーション

・SUSE　HPC　スタック
　カーネルはSUSE中心、
　ハードやツールはパートナー様中心

・パッケージハブ

・ゼロダウンタイム：btr（ばたー）fs→スナップショット取れる、元に戻せる
　スナッパーが動いている

・ダウンタイム減らす
　　SAP HANA 4Tのメモリ：リブートすると１時間
　　ライブパッチング：カーネルのAPIが呼ばれる部分で切り替え
　　KPatch,Ksplice,KGraft
　　　　１年に1回定期メンテナンスのときだけ、リブートはいる
　　Oracle KSpliceとSUSEのKSpriceの違い
　　　買収されてなくなることない→オープンソースだから
・HA：業務継続性
　　Hawk2（ふぉーく）デフォルトの管理画面
　　AWS Fencing agent（将来Azureも→別にAzure組めることは組める）

・SQLServer:Linuxの上で
　ORACLE RAC必要ですか？
　Exadataでなくても、AzureのDBでよくないですか？

・SAP
　ダウンタイム減らす
　SAP HANAに特化したファイヤーウォール

・Page Cache Limit
　HANAのパフォーマンスをあげるためではなく
　処理パフォーマンスのデグレードを防ぐ
　　S/4 HANA Windows→Linuxへ（Azure多い）

・SALTで自動化
　SUSEマネージャー　サテライトベース
　サードパーティーをつなぐプラグイン
　SUSEマネージャーエコシステム
　何が問題
　　スケール◎ここ問題
　　並列化
　　Express
　SALT：並列性を挙げる軽いスケールアウト対応
　　スペースウォークから
　　SALT Masterキー
　　Minion端末
　SUSEマネージャーを使い、自動化部分はSALT