ウィリアムのいたずらの、まちあるき、たべあるき

ロリポップはＣＧＩに対応していて、

http://lolipop.jp/manual/hp/cgi/
によると、

Python
　　バージョン：2.5.2 　　/usr/bin/python
　　バージョン：2.7.3　　 /usr/bin/python2.7

に入っているそうなので、簡単にPythonをサーバー側プログラム（ＣＧＩ）
として動かせる。

（１）
Apacheで動かすphp,python,ruby の Hello World まとめ
http://d.hatena.ne.jp/ipsleo/20110729/1311904202

にあるPythonプログラム

#!/usr/bin/python # coding:utf-8 print "Content-Type: text/html\n"; print "Hello World!";

をhello.pyとかいうファイルを作成して書き込む

（２）
それを、ロリポップの自分の/の下に入れる
(ftp転送する）一応、権限を７５５に代えたけど、代えなくてもいいかも

（３）ブラウザから、
http://自分のサーバー名.jp/hello.py

とやると、見えるはず。
自分のサーバー名は、自分のログイン名.自分が選んだサーバー.jp

たとえば、
　　ログイン名 xmldtp
　　選んだサーバーkiss.jp
なら、xmldtp.kiss.jpのはず。

※大文字と小文字は区別します。

昨日、データサイエンティスト養成講座: 初級編
いってきて、気象庁データ使うときに、おもわずハマったので、
もう一度手順の復習と、そこで教わった超絶技法のご紹介。

---

■気象庁・過去データの一般的な落とし方

＜＜課題＞＞
2015年1月1日から、1月31日までの大阪の最高気温をＣＳＶでダウンロード


＜＜手順＞＞

１．サイトアクセス

過去の気象データ・ダウンロード
http://www.data.jma.go.jp/gmd/risk/obsdl/index.php


２．地点を選ぶ
大阪をクリック

大阪をクリック

→チェックが付き、右側にエリアが選択されるはず


３．項目を選択

「項目を選ぶ」ボタンをクリック

日最高気温にチェック、右側に選択されているのを確認


４．期間を選ぶ
　「期間を選ぶ」ボタンをクリックし、
　希望期間をいれ、
　右側確認


５．ＣＳＶファイルをダウンロード
・もし、「表示オプションを選ぶ」で変えたいことがあれば、
クリックして、修正する。
その語、ＣＳＶファイルをダウンロードボタンをクリック

data.csvとかのファイル名でおちると思う。

---

■使い方

１．Ｒを立ち上げたら、

２．ファイル→ディレクトリの変更で、
　　今data.csvをダウンロードしてきたフォルダを指定

３．以下のコマンドでＶに読み込み


　　　　v<-read.csv("data.csv",skip=5)

　（頭６行がみだし。そこで、５行飛ばす。HEADERのデフォルトはTRUE)

４．２列目だけ取り出す
　　　　u<-v[[2]]

---

■超絶技法

Ｃｈｒｏｍｅで（IEではできない）

http://www.data.jma.go.jp/obd/stats/etrn/view/monthly_s3.php?prec_no=62&block_no=47772&year=&month=&day=&view=a2

のヘッダーから下を選択

これをctrl+Cで、クリップボードにコピー

ここで、Rから

x<-read.delim("clipboard",header=TRUE)

と打ち込み、Ｘをみると、

のように、年と温度がだんだんになっている。

ここで、１月の気温をとってくる方法


m<-nrow(x)
y<-x[seq(2,m,2),1]

おおお～SEQを使って２行目から、２行おきにとってくればよいのね

z<-mean(y)

で平均気温が求まり、

t.test(u,mu=z)

で上述１月の気温差のｔ検定が求まる。

Zendサーバーを使うと、ＰＨＰプログラムについて
　ブラウザから、サーバーでのＰＨＰプログラムの負荷がわかる。
　ＰＨＰプログラムの各関数の動作状況（経過時間や利用メモリ量）が分かる。

前者がＺ－Ｒａｙといわれるもので、

後者がコードトラッキングといわれるものだ。

Ｚ－Ｒａｙについては

Zendサーバーをインストールし、PHPのサーバー側情報が見れるZ-Rayを表示させる
http://ameblo.jp/smeokano/entry-11988871588.html

に書かれているので、そちらを見てもらうにして、

ここでは、コードトラッキングについて書くことにする。

---

■前提

上記ブログの記事にあるように、Ｚｅｎｄサーバーはインストールされているとする。
上記ブログの指示通りにインストールすると

ローカルサーバー
http://localhost:8000

Ｚｅｎｄ管理用サーバー
http://localhost:10081/ZendServer/

となる。私の環境も、すでにＡｐａｃｈｅが入っていて、ほかのことで
ポート８０番がふさがれている。そこで、上記の例に従う。

ただし、ポート８０番を何も使っていないで、デフォルトインストールした人は

ローカルサーバー
http://localhost

となる（８０００はいらない）

------

また、今、HelloZendというプログラムが、

C:\Program Files (x86)\Zend\Apache2\htdocs

の下に入っている。C:\Program Files (x86)は、インストール先のフォルダ
なので、人によっては、ちがっているかも・・

ローカルサーバー、Ｚｅｎｄ管理用サーバーとも上がっている。
なので、ブラウザから

http://localhost:8000/HelloZend

にアクセスできる状態になっている。

---

■起動まで

まずは、Ｚｅｎｄ管理用サーバーを立ち上げる。

http://localhost:10081/ZendServer/

にアクセスすると、

とパスワードを入れる画面になるので、インストール時に設定したパスワードを入力
そうすると、いつもの画面になるので、

OverviewタブのCode Tracingを選択（クリック）

画面が変わって、左から

・ＵＲＬを入れる（今回はhttp://localhost:8000/HelloZend）
・ＧＥＴかＰＯＳＴか指定する　　
・そしたらCreate Traceボタンをクリック

実行できると、下のように実行結果がでるので、チェックして（しなくても行くかな？）
ＩＤをクリック

そうすると、処理内容と、かかった時間が表示される
中を細かく見ることも出来る。

チェックを入れると、メモリ利用量なども見える

SDIカンファレンス２０１５　東京に行ってきた！の続き

CiscoSDNを利用した企業ネットワークの進化

---

・SDN：一部の顧客で導入が始まっている
・LAN・WAN向け

企業向けSDN
APICエンタープライズモジュール

SDN・SDI
・いろんな用途のコントローラー→取捨選択

ネットワーク技術動向：SDN技術
　OpenFlowから始まるSDN技術の進化
　　　ベアメタル
　　　ハイブリッド型APIC-EM　Cisco ODL
　　　ソフトウェアオーバーレイ型Nexus 1000v
　　　ハードウェアオーバーレイ型APIC-DC,Nexus9000

企業向けSDNコントローラーの目的と課題
・集中化・シンプルかによる運用コスト削減
・仮想化による柔軟性、俊敏性の向上
・インフラの付加価値、高度化
　　　　開発コストは吸収できる
　　　　バージョンアップ

現在のLAN/WAN
　　ネットワークオペレーター
　　　動いている
　　　つぎはぎ；きりわけたり管理コスト増大
　　SDN技術の導入で何が変わるのか

段階的な移行に対応APIC-EM
　　REST-API
　　テナント管理
　　サウスバウンド：コマンド
　　OpenFlow、OnePKを足していく

デモ１：APIC-EM
　上位アプリケーションはAPIC-EMに向かって
　REST－APIでポリシーを送ればよい
　既存のCatalyst環境をそのままおくれる
　Config考えなくてよい

開発する or 調達する
　OpenDayLight：こっちもやります！
　APIC-EM：ベンダーソリューション

APIC-EMの位置づけ
　　上位肩見たネットワークに複雑性を隠蔽
　　SDNのリスクをできる限り低減
　　開発やプログラミングの要件を最適化

APIC-EM

REST-API

　　　APIC-EM

サービス抽象化レイア


ポリシーコントローラー　デモ２
・IPアドレスをREST-APIで投げるだけ

APIC-EM REST API　デモ３
・コントローラーにREST APIで聞く
　　→GUIを使いこなしてもOK
・データバラけるしくみになった（特徴）

APIC-EM トポロジーMap
ACLパストレース→APIでも取れる

開発者サポート取り組み
http://developer.cisco.com/
ハンズオントレーニング

まとめ
・用途に合ったSDN
・企業向けSDN
・APICエンタープタイズモデル
・開発者サポート
大阪はOpenDayLight

つづいて
SDIカンファレンス２０１５　東京に行ってきた！の続き

目的＆役割別SDIガイド基本のき

---

ビジネスに貢献するIT
今から初めて１０年後も価値を生むインフラのあり方とは？

ITに求めるもの
　　リアルオプション
　　ビジネス継続性
　　ビジネス永続性

本来あるべき姿
　　ビジネスの創出
　　リアルタイム経営
　　業務の効率化
　　営業力／顧客満足度向上

ビジネスプラットフォームの市８んか

３ｒｄプラットフォームに適切なのがSDI

2ndプラットフォームの問題点
・１個１個のデバイスを管理・調達
・East-Westトラフィックに対応していない
・サーバだけを仮想化していて、システム全体を構成する要素は
　ハード、ベンダー依存

３ｒｄプラットフォーム
・マルチベンダのオープンな環境
・リスースや機能の仮想化により物理制約からの可能
・容易なスケールアウト、高い可用性
・APIにより、ユーザ自身が作るサードプラットフォーム

今提供できるブロケードの価値
・永続性、継続性、オープン
・高トランザクション。スケーラブル
・自動化

シンプルかつ永続的、継続性を提供する基盤
仮想化と自動連携（SDN)
物理；ファブリック

vyattaスケールアウト
ネットワーク：プライベート、パブリック

高スループット
・ビジネストランザクションのスループットをあげる
EIP（えらすてぃっくIP)を張り替えるだけで、SmallからLargeへ

ストレージもSoftwareDefinedで

高スルーぷっとなネットワー基盤

自動化
問題はプログラマビリティ
　　→OpenStack

OpenStack
汎用ネットワ－クサービスへの適用OpenDaqyLight

ネットワークファンbクション

ハイブリッドクラウドの実現例
バーチャルルーター：SDI

事例
・マイナンバー→びやったルーター

３つのステップ
１．ネットワークの仮想化
２．ネットワーク機能の仮想化
３．ネットワーク抽象化と統合管理

つづいて
SDIカンファレンス２０１５　東京に行ってきた！の続き

Software-Defined Infrastructureを見据えた仮想化基盤のあるべき姿

サブタイトルに「～OpenStackインテグレーションを考える～」ってあったけど、
OpenStack話はあんまりなかった気が・・

---

第３のプラットフォームにシフト
１．メインフレーム
２．クラサバ
３．クラウド、モバイル・・・

第３
LOB：ラインオブビジネス　
　　アマゾニング＝産業特化型のITソリューションによる事業展開
　　２０１８年、トップ２０社の７社が入れ替わる
　　失敗したらすぐにやめることができる

IT投資　６１％事業部門　３９％IT部門
・IT部門に求められる役割
　　経営層にたいしたITを通じた経営への助言

スイッチを入れると→電気がつく
　あたりまえのこと・・：ユーティリティモデル
　　・タービン回って
　　・送電して

１０年前　altavista使っていた→Google
　　Googleがしたこと
　　　・検索して
　　　・ネットワーク
　　　　　：

　　　↓
　　　IPhone：複数のデバイスを消した：Software Defined

ところが
　　どのストレージ
　　どのロードバランサ・・・
IT基盤の構築以外にもやること満載

Value Lineを考える
電気
　　いつ使うか
　　どこで
　　電気の種類
----------------
　　送電方法
　　発電方法
　　土地の許可
　　スタッフ

パブリッククラウド
　必要なときに利用可能
　従量課金
　コスト
　セキュリティ
　　↓
プライベート／パブリック
　　↑
オンプレ
　　信頼性
　　柔軟性
　　運用管理
　　専門性の高い人間関係


データセンター・テクノロジーの変化
　　クライアント・サーバー
　　仮想化
　　クラウド：パブリッククラウド

基本的な要素
・汎用サーバーのみ（専用アプライアンスなし）
・Software Definedな環境
・SPOFなし
・予測可能なスケールアウト

・IT基盤のあるべき姿
　　　Web-Scale IT：９９年Googleデータセンターから

Web-ScaleITという思想
１．X86サーバーに集約されたシステム
２．全ての機能をソフトウェアで実装
３．全てのデータとサービスを分散処理
４．セルフヒーリング（自己修復型）システム
５．APIによる自動化と豊富な解析機能

Google　GFS
Google MapReduce
　　　→　Hadoop

Amazon　Dynamo
Google　Bigtable
　　→Cassandra

にゅーたりっくす(nutanix)
顧客１２００社
２U、４ノード
　コントローラーVM（ハイパーバイザー上）→スケールアウト可能

コンバージドインフラ
　いままで３Tire　サーバー　SAN/NAS　共有ストレージ
　　→１つの箱で実現
ハイパーコンバージドインフラのパイオニア

Solidfire
フラッシュストレージのポジショニング
　　安価で大容量
　　パフォーマンス，容量、スケール
　　　　　Solidfire
　　特定ワークロード
　　　　　Solidfire
　OpenStack

QOS：アプリごとに

きのう、ブログお休みしてしまったので、もうかなり経ってしまったが、
SDIカンファレンス２０１５　東京に行ってきた！の続き

つづいて「ネットワーク仮想化の商用化に向けた展望」
講師：ファーウェイ・ジャパンの人
なんだけど、プレゼン資料が見えなかった。
ので、ロリポおじさん程度の正確さだと思ってくれ（＝ほとんど正しくない）

---

会社説明
NFV
ソリューション
去年・今年　POC、フィールドトライアル
NFVマーケット
まとめ

会社紹介
・中心は通信事業者
　コンシューマー：端末系
　エンタープライズ：ソフトウェア
　２０％増

NFV
・なんでやりはじめたっけ？
　　コスト削減、省電力、ハードウェア
　　SDIをからめる
　　Open→インテグレーション
・どんないいこと
　　クラウドベース：簡単に早くデプロイ
　　運用の効率化
　　資産の有効活用
　　今、かんがえる

NFVソリューション
　　マルチベンダーを統括する

調査
・NFVをやるとコスト下がる？
　　サービスチェーン

・NFVをやる問題
　　OSS,BSSとNFVのインテグレーション

・NFV：キャリアグレード
　　ほんとにコスト削減されるか
　　CIOとCTOの役割分担
・日本のNFV手作業
　
・NFV→クラウド

マーケット
２つの事例
　　パケットコア
　　CPE

SDIカンファレンス２０１５　東京に行ってきたの続き

NECのSDNの取り組みと広がるSDN
について、めもめも
ソリューション

---

４年くらい前からSDN商品→当時はOpenFlowだったけど
　　メリットを問われた
SDIを見据えながら

SDNのメリットとは
SDI（仮想化基盤）増えてきている

ユースケース
・JR東日本
・ねくすこにしにほん：高速道路がネットワーク
　　→バックアップ
・SDNクラウド　自動プロビジョニング　最短５分
　　　OpenStack WebSAM
・適用領域
　　オフィスLAN
　　DC　NWクラウド
　　広域網
　お客様が自分でSDN
　→新サービス：スピード

変化への適合力を高めビジネスに貢献する
・自社DC
・パブリッククラウド
・データセンター進化論
　　・オートスケーリング
　　・リソース最適化

SDIアーキテクチャ→進化論に基づき→製品

NECの強み
・オープン性：マルチクラウド、OpenStack,KVM
・マルチサイト環境
・仮想化基盤、ITIL、→管理ソフト

SDNソリューション

NEC　SDN　パートナースペース
開発キット公開
http://sdnspace.com/

・OpenStackへの取り組み強化

セキュリティ：トレンドマイクロ
・WANルーターのSDN→物理トポロジーの自動検出、可視化

VMWareとの連携
→ネットワークで一元管理
　来週くらいに販売開始

WebSAM　Network　Automation

オーバーレイソリューション
　VXLANのコントローラー：OpenFlowとシームレスに
OpenStackのNeutronプラグイン開発
　OpenStackのベアメタル→シームレスにコントロール

今から始められるSDN
SDNレディ
→中期計画なんかつくる
　ホワイトペーパーのようにまとめた。
　参考までに

教育コースの中で、実機でさわってみて

まとめ
・SDNのメリットの議論収束SDI
・レガシーと組み合わせ

あってるかどうか分からないけど、まとめ

マルチテナントという言葉がある。

1つのシステムの中に複数の企業（ユーザー）のサービスを同居させ、リソースや運用コストを大幅に低減する方式のことである。

と
http://www.atmarkit.co.jp/fdotnet/bookpreview/azureoverview_0301/azureoverview_0301_01.html

には書いてある。この定義はこの定義でよいのだけれど、
セールスフォースのようなＳａａＳが指すマルチテナントと
OpenStack（ＡＷＳもそうだけど）のようなIaaSが実現するマルチテナントは
全く違う（というか、IaaSのマルチテナントはPaaSのシングルテナントに相当し、
それはSaaSのマルチテナントと真逆の概念）ような気がするので、まとめてみる。

---

■ＳａａＳのマルチテナントは、最低ＯＳは共有する


Windows Azureエンタープライズアプリケーション開発技法
マルチテナント・アーキテクチャ
―― 第3章　クラウドとオンプレミスの考え方の違い　3.6 ――
http://www.atmarkit.co.jp/fdotnet/bookpreview/azureoverview_0301/azureoverview_0301_01.html

のように、ＳａａＳのマルチテナントはテナントごとに
　　・単一ＤＢ共通スキーマ
　　・単一ＤＢ個別スキーマ
　　・ＤＢ分離
のようにＤＢを（どこかで）切り分けて利用する。
したがって、ＤＢは異なるかもしれないが、アプリやＯＳは、共通のものを使うと考えられる

そこで、

PaaSレイヤーの「シングルテナント」と「マルチテナント」はどちらが優位か？
http://www.engineyard.co.jp/blog/2013/singletenancy-vs-mutitenancy/

の議論が出てくる。ＰａａＳのシングルテナントとは、上記のＳａａＳのマルチテナント
とちがい、ＯＳなどを分けるというものだ。

---

■OpenStackのマルチテナントはＯＳもネットワークも分離する

OpenStack Neutronとは何か？ (1/3)
http://www.atmarkit.co.jp/ait/articles/1412/08/news009.html

にあるように、Ｏｐｅｎｓｔａｃｋもマルチテナントを対応するが、

ここでいうマルチテナントは、ＯＳもネットワークも分離した状態のものを指す。

たとえば、企業Ａ，企業Ｂというテナントがあったとき、
ＳａａＳのマルチテナントは、同一のアプリケーションの上に、企業Ａ，企業Ｂが
存在するが、

ＯｐｅｎＳｔａｃｋの場合、テナントを分けてしまうと、それぞれにＯＳを
載せられるし、サーバーが割り当てられ、別物として設定できる。

そこで、テナントである企業Ａと企業ＢのＩＰアドレスがぶつかる可能性
があるのだが、これをＮａｍｅｓｐａｃｅにより、切り分けている。

---

■何が違うのか

ＳａａＳのマルチテナントは、ＯＳ，アプリは共通なので、他テナントの
影響を受ける可能性があるが、OpenStackの場合、それぞれのテナントは
違うものなので、影響を受けない。

また、可用性に関していえば、ＳａａＳの場合は、アプリが異常終了したら
終わってしまうが、ＯｐｅｎＳｔａｃｋの場合、物理ＰＣが１台故障しても
まだ大丈夫というように独立性を保っている

たぶんＩＰも同じに出来たりするので、同一環境で大量に作成したい場合は
ＯｐｅｎＳｔａｃｋのほうが向いているのであろう。

SDIカンファレンス２０１５　東京に行ってきた。
まずは、

西原町役場SDN対応ネットワーク構築事例

をメモメモ

---

○（沖縄県）西原町について
沖縄：東と西でちがう
・東は昔ながらの沖縄
　　→さとうきび
・西は観光、

４つの大学が小さな市町村に→文京の町

○西原町はどうしてSDN？
システム：ネットワークを伴うので１７
　クライアント２～３００
　端末４００台強
　ベンダーは大手、地場９つ
　３００人の職員が働いている

○行政を取り巻く現状
　文書整理、表計算

平成１０年
　PCベースのクラサバ業務
　地域インターネット導入事業
　西原町全体が業務システム（１ネットワーク）へ
　職員１人１台
　住民基本台帳・戸籍　紙から電子データ
　LG WAN
　国保連・税関系：外部接続
　J-アラート、戸籍バックアップ
　法務省連携：（外国人）

他市町村もふくめて、可用性

今
　マイナンバー
　今後住民票コンビニ交付など増える→ネットワーク
　クラウド化

ネットワーク
　今まで縦割り
　　→横のネットワークつながること重要
　　　相互接続
いままで
　センをわける：ケーブルが１７本
　スィッチ１３台：今年は１０だい、来年３台
　　→そのたび追加：わからなくなる
　　→幹線の逼迫
　　→かなりのむだ
　小さくなるほど、専任担当者を置くのが困難
　感覚的なところは引きつなぐのは困難
　次の世代への技術継承できない

ネットワーク
　物理、論理ともに入り乱れている
　ケーブルの流れ分からない
　つないだ瞬間にループ
　　若手の職員：つないでくれる
　　　　知らないうちに・・・
　　　　（ちょっとかけない話）
　　L3スィッチ：数十万規模→過剰投資
　　設定する手間
　　死活監視が完璧にできない
　　　→とらぶるあったら、いく
　　　　ちょっかんで

SDN導入の経緯
・安定したネットワーク
・GUI
・各種制度；追加に対して柔軟に
・自治体：お金ない：長期前提

・ネットワーク：空気のようなもの
　　冗長性、可用性はしっかり
　柔軟性
・ネットワークの拡張性
　Openflow(NEC)採用

今後
・ユーザーconfig：目的が分かれば設計可能
　　いままで：物理設計も必要だあった。
　　VLANよりバーチャルテナント→柔軟性に飛んでいる
　SDN：柔軟性こそ、武器の１つ

懸念点
・OpenFlow大丈夫？
　　　民間でも使ってる→
・費用が見合っている？
　　　さほど平かななった
・同じように使える？
　　　問題なくできる
　　　４日間で：問題なくできた
　　　ベンダと１ヶ月、最終的に２回
　　　　SDNでシステムの細かい調整が省ける
　　　エッジはいままでの

SDNに以降の結果
　とらぶるはない

２７年度マイナンバーへの活用

https://www.youtube.com/watch?v=gBwzxydX3rY
【公式】ISETAN-TAN-TAN PV【公式】ISETAN-TAN-TAN PV
（音量注意）

ＳＥには、ＳＥ１とＳＥ２の分類が実はある。

顧客の矛盾した、とんでもない要求から、解決策（＝ソリューション）となる
システムを見つけ出すＳＥ１

ＳＥ１が作ったシステムを、イマドキのコンピューター用語をもちいて、
かっちょよく仕上げるのがＳＥ２。

---

一見すると、イマドキのコンピューター用語を振り回し、
システムをびしばし作っていくＳＥ２は、コンピューター屋さん
らしくて、かっこいい。

キットもてたりするに違いない。

大学なんかで教えるＪａｖａの基礎なんかよりも、
はるかに抽象概念なＤＩを持ち出したり、
イマドキのフレームワークを議論(宗教論議）したり
データ解析ではＳＶＭのカーネルトリックを駆使し、
SQLでは、（大学では教えない）ウィンドウ関数を使ったり
ＮｏＳＱＬのテクニックを持ち出してやったりするので、
周りから見ると、かっこよく見えるし、本人たちも

おれたちのこの高度な現場に比べ、
大学で教えている技術は何と低レベルなことか！
何のために大学に行くのか、大学に行くのに意味はあるのか？

とかいうから、かっちょよく見える。
テクニシャンを極め、マイスターになるコースだよね・・・

---

一方ＳＥ１のお仕事っていうのは、
かっこよくはない。

基本的にお客さんに納得してもらうには、
簡単な日本語で表現するし、

むしろ、だれにでも分かる言葉で言うことのほうが、
大切だったりする。

何のために大学に行くのか、大学に行くのに意味はあるのか？
と考える人はＳＥ１には、たぶん向いていない。

ただただ、興味のあること、面白いことに頭を突っ込んで言って、
それが、ある日突然と結びつき、ソリューションへと昇華したりする。

意義が分かるようなことをやるんじゃ、つまらない。
まったく関係ないようなことを結びつけて、顧客の
ソリューションに持ってくることが、楽しいんである。


だから、大学の勉強に意義があるかなんて考えない。
意義は自分で見つけるものだから。

---

たぶん、この世の中で、必要なのは
大量のＳＥ２と、ほんのちょっとのＳＥ１。
そして、ＳＥ１は、システムを作るのが好きな人がやっている。
（ＳＥ２よりも、お金が高いことになっているけど、
　たぶん、お金でやっているのではない）

こんなかんじでＳＥ１とＳＥ２の仕事の仕方と価値観は全く違う。
ここを理解しないで、ＳＥ２の人がＳＥ１になろうとすると
（お金高いからとかいう意味で＊）、不幸になると思う。


＊お金高いとか・・・
実は高くない。ＳＥ２の場合は、仕事と私生活が分かれている場合が
多い。ＳＥ１は、ほとんど一日中考えている（考えるのが好きな人が
仕事している）なので、時間単価で出すとたぶんＳＥ２のほうが、
単価は高い。

http://enterprisezine.jp/article/detail/6549

あとでよむ

「詳しくは明日のチラシで！」
http://www.jagat.or.jp/archives/5744


え！ジャパネットたかたって、テレビ広告（でももちろん打っているけど）
じゃなくって、チラシのほうが、売ってるってこと？

やっぱり、冷静になったところで、もう一度っていうのが、
効果あるんだろうね！

まさに、オムニチャネル

あとでよむ

米陸軍、フォレンジック解析フレームワーク「Dshell」を公開
http://sourceforge.jp/magazine/15/02/03/143000