New technology for non-volatile memory

“第3のメモリー”の衝撃、ストレージとDBが一変する

これは凄い。不揮発性だがフラッシュメモリに比べて圧倒的に高速なアクセスが可能な新しいメモリだそうです。ビッグデータ時代には、大量データを保持するストレージへのI/Oアクセスがボトルネックになるだろう事が容易に想像できますが、この新メモリ技術はその問題の解決に大いに役立ちそうですね。

Self-driving car will share 75% of the entire automotive market

セルフドライビングカーは2035年には乗用車の75％を占めるようになる

これは大変面白いです。高速道路での自動運転は近い将来実用化されそうですから、20年も経てばもう高速道路以外での自動運転も一般的なのかも知れませんね。

Clipping an article of a tech startup

「学生起業家たちの肖像」 - 第5回　「われわれは100倍、速く書ける」――PFI 西川徹

面白そうな記事を見つけたので備忘録代わりに記しておく。記事は3年前のものでちょっと古いが、このPreferred Infrastructureという会社、ビッグデータ時代に重要な技術を色々とやっている技術ベンチャーで面白い。

Underground Thermal Energy Storage - case example of "Tokyo Sky Tree"

東京スカイツリーに隠れた“名所”〜地中熱で夏場の電力9割カット〜

もう一つ日経ビジネスオンラインの記事から。

そうか、電力を熱として使いたいのであれば、初めから熱に変換しておき、タイムシフトすれば良いわけですな。

というわけでちょっとググったら、"Seasonal thermal energy storage (STES)"というのを見つけました。これは数ヶ月にわたって地中に熱を貯めておくことが出来る技術を総称して呼ぶ呼び名のようです。

"Seasonal thermal energy storage (or STES) is the common umbrella term for several technologies for storing heat or cold for periods of up to several months" - Wikipedia

これだと、特に日本の様に四季によって温度変化が激しく夏や冬に空調の為にエネルギーを多く使う土地柄では、比較的エネルギー消費の少ない春や秋にエネルギーを使って熱(もしくは冷気？)を地中に貯めておき、必要な時に使う、ということも出来そうです。

技術革新も必要だけれど、色々な工夫や発想の転換で、日本のエネルギー事情(特に電気エネルギー)は随分と改善し安定化してくれる様な気がします。

Smart grid introduction in California, USA

カリフォルニアが蓄電に舵を切る〜再エネ導入を前提に送電網を構築する米国〜

今日は日経ビジネスオンラインの記事から。

カリフォルニア州はスマートメーターの普及が進んでいるようです。

ところで「蓄電」という言葉を聞いて、ついついリチウムイオン電池の様な蓄電池を想像してしまったのですが、充電と放電のタイミングをシフトしたいのであれば他の方法も使えるわけで、例えば揚水発電もそうですよね。

Wikipedia曰く「揚水発電（ようすいはつでん、Pumped-storage hydroelectricity）は、夜間などの電力需要の少ない時間帯の余剰電力を使用して、下部貯水池（下池）から上部貯水池（上池ダム）へ水を汲み上げておき、電力需要が大きくなる時間帯に上池ダムから下池へ水を導き落とすことで発電する水力発電方式である。すなわち実質的には、発電だけを目的とする発電所というよりも、電力需要・供給の平準化を狙う蓄電を目的した、ダムを用いる巨大な蓄電池、あるいは蓄電所と言うべきものである。また、発電する電気量に対し、水を汲み上げるために消費される電気量がおよそ３０％割増となるため、その点効率の悪い発電様式とも言える。」とのこと。

要は、余剰電力を使って水の位置エネルギーを増加させ(＝下のダムから上のダムにポンプで水を吸い上げる)、電力需要の高まりを待ってそのエネルギーを電気エネルギーに戻す(＝上のダムの水を落として発電する)、という電力の需給タイムシフトを行うシステムです。

このタイムシフト用の蓄電方法が簡易かつ効率的であると理想なのですが、他にどんな方法が採れるでしょうか。つまり、電気エネルギーを使って何か他のエネルギーを生み出し、それを(出来れば劣化せず)需要時点まで保存し、需要時点で(出来れば損失を最小に抑えて)電気エネルギーに戻す事が出来る方法があるか、という質問です。

電気エネルギーを他のエネルギーに変換しようとすると、変換先のエネルギーには幾つか候補があると思います:

1. 磁気エネルギー・・・磁場を発生させる
2. 熱エネルギー・・・何かを温める
3. 位置エネルギー・・・(揚水発電の様に)何かを重力に逆らって持ち上げる
4. 運動エネルギー・・・何かを加速させる
5. 化学変化・・・(エネルギーでは無いですが)別の分子やイオンに変化させる

勿論、どれもエネルギー変換の効率(もしくは変換による損失)の問題と、タイムシフト中のエネルギーの減衰の問題を考慮しないといけないですね。

さて、エネルギー変換効率についてもWikipedia先生に聞いてみると、載ってます。ああ、なんと便利なんだ。

エネルギー変換効率の一覧

これを見ると、蓄電は結構ハードルの高い話だということが分かります。揚水発電の損失が30%位だそうですが、仮に電気エネルギーを使って水を電気分解し、発生した酸素と水素を気体として保存し、後で燃焼によって電気を発生させるとすると、既に電気分解で30%程度の損失が発生する為、タイムシフトして電気に戻した場合の損失も考えると明らかに揚水発電の方が効率が良さそうです。

変換効率の良いエネルギー変換や、減衰の小さいタイムシフト方法について、引き続き調べてみたいと思います。

Structuring knowledge of Buddhism

いつもちゃんと調べようとしてなかなか出来ていなかった。よくお不動様(＝不動明王)をお参りするのだが、色々な仏様にご縁がある割にちっとも知識がストラクチャされないので、この際ちゃんと整理する事に。リンク先と引用は全てWikipediaから。何でも載っているWikipedia。ありがたやありがたや・・・

まずは代表的な四如来:

• 大日如来・・・真言密教の教主。「万物の慈母」、「万物を総該した無限宇宙の全一」とされる汎神論的な仏。真言宗で最も偉い仏様ということで正しい理解だろうか
• 阿弥陀如来・・・大乗仏教の如来の一尊。阿弥陀様。無明の現世をあまねく照らす光の仏にして、空間と時間の制約を受けない仏であることをしめす。西方にある極楽浄土という仏国土（浄土）を持つ
• 釈迦如来・・・仏教の開祖釈迦（ゴータマ・シッダッタ、ガウタマ・シッダールタ、瞿曇悉達多）を、仏（仏陀）として敬う呼び方。お釈迦様
• 薬師如来・・・大乗仏教における如来の一尊。薬師如来は東方浄瑠璃世界（瑠璃光浄土とも称される）の教主。瑠璃光を以て衆生の病苦を救うとされている。無明の病を直す法薬を与える医薬の仏として、如来には珍しく現世利益信仰を集める。東方の如来という事から五智如来の阿閦如来とも同一視される

大日如来の化身、もしくはその内証（内心の決意）を表現したものが不動明王であると見なされている。「お不動さん」の名で親しまれ、大日大聖不動明王（だいにちだいしょうふどうみょうおう）、無動明王、無動尊、不動尊などとも呼ばれる。アジアの仏教圏の中でも特に日本において根強い信仰を得ており、造像例も多い。

お不動様は五大明王の中心となる明王である:

• 不動明王・・・中心
• 降三世明王（ごうざんぜ - ）・・・東
• 軍荼利明王（ぐんだり - ）・・・南
• 大威徳明王（だいいとく - ）・・・西
• 金剛夜叉明王（こんごうやしゃ - ）/ 烏枢沙摩明王（うすさま - ）・・・北

ちなみに明王とは、「仏の知恵(真言)を身につけた偉大な人」という意味である。一般に、密教における最高神大日如来の命を受け、仏教に未だ帰依しない民衆を帰依させようとする役割を担った仏尊を指す。或いは全ての明王は、大日如来が仏教に帰依しない強情な民衆を力づくでも帰依させるため、自ら変化した仏であるとも伝えられる。そのため、仏の教えに従順でない者たちに対して恐ろしげな姿形を現して調伏し、また教化する仏として存在している。

明王は一般的に「天」と名の付く天部の神々（毘沙門天、帝釈天、弁才天等）と同様に、古代インド神話に登場する神々、特に夜叉や阿修羅と呼ばれた悪鬼神が仏教に包括されて善の神となった者が多いのが特徴である。明王はもともと古代インド神話においても「天」より高い見地に所在していた神であることが多く、仏教に包括された後も「天」は仏の世界を支える須弥山という山の守護を主役割とし、明王は民衆の教令を主とするなどその役割に違いが現れている。

ちなみに「天部」に属する諸尊は、仏法の守護神・福徳神という意味合いが濃く、現世利益的な信仰を集めるものも多数存在している。

阿弥陀様は、阿弥陀三尊として祀られるときは、脇侍に観音菩薩(特に聖観音)・勢至菩薩を配する。但し、阿弥陀三尊のうちの左脇侍像として安置される観音像については、単に「観音菩薩像」と言うのが普通で、「聖観音」と称するのは、独尊像として祀られる場合にほぼ限られている。

観音菩薩は菩薩の一尊であり、北伝仏教、特に日本や中国において古代より広く信仰を集めている尊格である。「観世音菩薩」または「観自在菩薩」ともいう。「救世菩薩」（くせぼさつ・ぐせぼさつ）など多数の別名がある。一般的には「観音さま」とも呼ばれる。

密教では聖観音、十一面観音、千手観音、如意輪観音、馬頭観音、准胝観音（または准胝観音に代えて不空羂索観音）を「六観音」と称している。観音像には十一面観音、千手観音、如意輪観音など、多面多臂の変化観音と、こうした超人間的な姿ではない、1面2臂の観音像とがあり、後者を指して「聖観音」または「正観音」と称する。

六観音は六道輪廻（ろくどうりんね、あらゆる生命は6種の世界に生まれ変わりを繰り返すとする）の思想に基づき、六種の観音が六道に迷う衆生を救うという考えから生まれたもので、地獄道－聖観音、餓鬼道－千手観音、畜生道－馬頭観音、修羅道－十一面観音、人道－准胝観音、天道－如意輪観音という組み合わせになっている。

お釈迦様は釈迦三尊として祭壇に置かれる場合が多い。脇侍は文殊菩薩と普賢菩薩が多い。

薬師如来は日光菩薩、月光菩薩を脇侍とした薬師三尊像として安置される場合がある。また、眷属として十二神将像をともに安置することが多い。

十二神将は、仏教の信仰・造像の対象である天部の神々で、また護法善神である。薬師如来および薬師経を信仰する者を守護するとされる十二体の武神である。つまり、神様である十二神将が仏様である薬師三尊をお守りしてるわけですね。

• 宮毘羅(くびら)大将・・・亥年
• 伐折羅(ばさら)大将・・・戌年 / 金剛力士 (仁王様)
• 迷企羅(めきら)大将・・・酉年
• 安底羅(あんちら)大将・・・申年
• 頞儞羅(あにら)大将・・・未年
• 珊底羅(さんちら)大将・・・午年
• 因達羅(いんだら)大将・・・巳年 / 帝釈天
• 波夷羅(はいら)大将・・・辰年
• 摩虎羅(まこら)大将・・・卯年
• 真達羅(しんだら)大将・・・寅年
• 招杜羅(しょうとら)大将・・・丑年
• 毘羯羅(びから)大将・・・子年

ということで、メジャーどころの仏様だけでもこれだけいらっしゃるわけですが、如来、菩薩、明王、天部、という4つの仏様のグループを漸く理解し、何となく相関がハッキリしてきました。

Yahoo! Japan picked up "Big Data" as a focused topic

Yahoo! Japanがビッグデータのニュースを取り上げていた。幾つか興味深いところをピックアップすると:

Ginger Software、ビッグデータを活用した英文予測機能を提供

これは面白そう！英語には相変わらず苦労しているので、すぐに実用にも役立ちそう。

ウルシステムズとPivotalジャパン、ビッグデータ処理に関する技術で協業

古巣も何やら。

東大教授　詐欺容疑で逮捕　医学とＩＴ融合目指した第一人者

直接ビッグデータには関係ないが、こんなニュースも。

ビッグデータとHadoop 第5回 機械学習/データサイエンスにおけるHadoopの適用事例

これは結構テッキーな話。私のやっていた遺伝的プログラミングも並列実行可能な大量のシミュレーション繰り返すので、ビッグデータ時代にはHadoopとの融合が必須ですね。

データサイエンティストのいない企業でもHadoopを有効利用できるビッグデータ分析サービスDatameer

うーん、これだけだと抽象的でよく分からないなあ。。。

ビッグデータが入ったHDDをGoogleに送ると80ドルでクラウドにアップしてくれる

これは良いサービス！

ビッグデータはバズワードの対象ではなく - 松本 公平
ビッグデータというのはバズワードだが、要は大量データからの意味合い抽出に、まだあまりビジネス分野に広まっていない非常にアカデミックなアプローチが必要、ということだろうか。それはそうだろうなあと思う。

Twitterがビッグデータ高速処理を提供するUbaloを買収?ツイートの巨大集積を料理か

Twitterのお買い物の話。

VCのAccelがビッグデータブームの"第二波"に備えて1億ドルのファンドを確保

これからは、顧客にとっての価値を生み出すソフトウェアに焦点が移る、というのは全く同意。というかビッグデータを知っている人は世界中誰もが同意する様な気も・・・。具体的には人工知能系のアルゴリズムやヒューリスティック、それを支えるソフトウェアフレームワーク、それらを高速実行するプログラミング言語、処理系、仮想マシン、更にチューンされた垂直統合型ソリューション(Oracle ExaLogicみたいなの)辺りが注目どころでしょうかね。後ろの方は殆どM/WやH/Wの領域ですが。

ビッグデータという言葉がそもそも5〜10年後に生き残っているのか？と思うと疑問ではあるけれど、ビッグデータと呼んでいる何かによって何をすべきか、そしてその為のビジネスとITのアーキテクチャは何なのか、についてはまだまだ色々と考える余地がありそうです。

今日の読書 (8/12) / Today's readings (Aug 12)

今日読んだ本のメモ。

• ビッグデータの衝撃――巨大なデータが戦略を決める
• ビッグデータ革命 無数のつぶやきと位置情報から生まれる日本型イノベーションの新潮流

発刊から1年以上経って漸く読んだ2冊。どちらも書いている事は結構共通しているが、前者は後半がNRIの製品宣伝っぽいのがどうなのかと思うが、技術的な観点がより深い。後者はプライバシーに関する欧米や日本の現状、特に法整備についてカバーしている。技術的には浅いかも。ただ、事例がまとまっているのは良い。

Using Nexus 7 with Mac

MacBook ProからNexus 7にファイルをコピーしたくなったのでどうやるか調べてみました。

Nexus7にMacからUSB経由でファイル転送するには？

を参考にさせて頂く。MacではAndroid File Transferというソフトが必要らしいので、リンク先からダウンロードしてインストールする。

インストールしたアプリを起動すると、Nexus 7の内部がファインダーのように表示されるので、ファインダーからのドラッグ＆ドロップでファイルのコピーが可能となる。

ビッグデータ情報のピックアップ / Picking up web resources related to "Big Data"

ビッグデータ関連の情報をネット上からピックアップしてみました。

一般

• ビッグデータ - Wikipedia

政府

• 総務省｜平成24年版 情報通信白書
• 分野を超えたビッグデータ利活用により新たな知識や洞察を得るための革新的な情報技術及びそれらを支える数理的手法の創出・高度化・体系化：文部科学省

業界団体

• ビッグデータビジネス・コンソーシアム
• 東日本大震災ビッグデータワークショップ - Project 311 - (終了)
• 9．M2M・ビッグデータWG | ジャパン・クラウド・コンソーシアム JCC [Japan Cloud Consortium]

業界誌

• ビッグデータ：ITpro
• 経営 - 特集 ： ビッグデータとは何か--課題と機会、ベンダーの戦略 - ZDNet Japan
• 日本企業の取り組みはどこまで進んでいるか？　ビッグデータ関連まとめ
• 特集 ビッグデータ競争時代 | DIAMONDハーバード・ビジネス・レビュー

ベンダ

• IBM ビッグデータ ： ビッグデータとは - Japan
• 日本HP - HP Services「HP ビッグデータコンサルティングサービス」
• ビッグデータ利活用：日立
• ビッグデータ：株式会社 日立コンサルティング
• NECのビッグデータソリューション | NEC
• ビッグデータ活用を支えるソフトウェア : 富士通
• オラクルとビッグデータ
• 伊藤忠テクノソリューションズ（株）｜ビッグデータ
• ビッグデータ・インテリジェンスの基盤を支えるインテル
• AWSでのビッグデータ | アマゾン ウェブ サービス（AWS 日本語）
• IIJ GIOビッグデータラボ | IIJクラウドサービス - IIJ GIO
• ビッグデータ×マーケティング | 経営コンサルから営業支援まで | 博報堂のConsulaction（コンサラクション）サービス
• “ビッグデータ”がビジネスを変える ： 連載コラム ： コラム ： ニュース＆オピニオン ： 三菱総合研究所
• ガートナー | 2013年の展望：ビッグ・データと情報インフラストラクチャ
• ビッグデータ | Talend

技術

• ビッグデータ処理の常識をJavaで身につける
• Amazon Redshiftではじめるビッグデータ処理入門：連載｜gihyo.jp … 技術評論社
• SIOS ビッグデータ技術ブログ

その他記事

• ビッグデータ活用をめぐる企業の事情 - ITmedia エンタープライズ
• もう「ビッグデータ」はやめよう | TechCrunch Japan

Google検索上位50位くらいからめぼしいところをピックアップしたのですが、ITベンダが目立ちますね。

モバイルアプリケーションプラットフォームの勉強 (Understanding overview of mobile application platform)

自分の勉強の為に主要なモバイルアプリケーションプラットフォームの情報をまとめてみました。/ I have collected information of major mobile application platforms for my own understanding.

2013年8月現在存在する主要なモバイルアプリケーションプラットフォームは以下の8つです (リンク先は全てWikipedia) / Below is the 8 major mobile application platforms as of August, 2013 (all hyperlinks are linked to Wikipedia):

1. Android (Google)
2. iOS (Apple)
3. BlackBerry (BlackBerry)
4. Symbian (Accenture)
5. Windows Phone/Windows Mobile (Microsoft)
6. BREW/REX OS (Qualcomm)
7. Tizen (Intel)

※上位5位の順序はIDCによる2012年通年の端末出荷台数シェアに基づく / The order of the first 5 items are based on the research by IDC on the share of shipped mobile handsets in 2012.

ここで、各プラットフォームを実行環境やアプリケーション開発という観点から比較してみましょう。 / Below is the comparison of these platforms from viewpoints of runtime environment, application development, etc.

各プラットフォームの比較

Name	Android	iOS	Blackberry	Symbian	Windows Phone	BREW	Tizen
CPU architecture	ARM (v5 or later), MIPS, x86	ARM	Snapdragon (Based on ARM v7)	ARM	ARM	ARM	ARM, x86
OS kernel	Linux kernel	XNU kernel	Java Virtual Machine (v7 or before) / UNIX kernel based on QNX (v10)	Symbian OS kernel	Windows CE (v7) / Windows NT (v8)	REX OS kernel	Linux kernel
Application type	Java application (running on Dalvik VM)	Native Objective-C application	Java application (v7 or before) / Native C++ application	Native Symbian C++ application	C#, Visual Basic (running on either Silverlight or XNA Framework)	Native C++ application	HTML5, JavaScript (Web framework) / C, C++ (Native framework)
Development environment	Android SDK (application) / Android NDK (runtime, library)	iOS SDK (included in Xcode)	BlackBerry Java SDK / BlackBerry Native SDK	Symbian SDK	Windows Phone SDK	Brew MP SDK	Taizen SDK

これを見ると、幾つかの共通点が分かります。 / Now we could see something in common.

1. 動作CPUはARMが基本 / All of them works on ARM as CPU architecture
2. OSカーネルはLinuxもしくはUNIXベースが多い (XNUがベースとするのはMachというUNIX, QNXは商用のリアルタイムUNIX) / Most of them runs on Linux or UNIX-based kernel (XNU is based on a UNIX called "Mach", and QNX is a commercial real-time UNIX)
3. アプリケーションはJavaやXNAの様な中間言語アプリかC++やObjective-Cのようなオブジェクト指向言語で開発するネイティブアプリタイプが多い (中間言語アプリもJavaやC#はオブジェクト指向言語) / Application runs on an interpreter, i.e., Java, XNA, or runs as a native application written in an object-oriented language, i.e., C++, Objective-C (an object-oriented language is also used for the interpreter, i.e., Java, C#)

上記のプラットフォームがターゲットとするハードウェアは、スマートフォンやタブレットなどの比較的コンピューティングリソースが豊富な組み込み機器ですが、それにしてもARMが独占しているというのが面白いです。同じく組み込み機器で成功しているMIPSがAndroid以外のプラットフォームにサポートされていないのは何故なのでしょうか。Intel自身が開発に携わっているTaizenを除くとx86をサポートしているのはAndroidだけですが、これはx86が元々デスクトップPC向けに進化してきたアーキテクチャなので、ARMに比べて不利な点があるという事でしょうか。IntelのAtomはどこへ行ったのでしょう。

Linuxが多く使われているのは、オープンソースであり、かつ多くのプラットフォームに移植されてきた歴史がある、という点からでしょうか。コードサイズを削減して目的に特化したカーネルを生成したり、必要なデバイスドライバを追加したり、場合によってはカーネルの処理そのものを変更・削除したり、Linuxであれば低コストで柔軟に対応が出来そうです。今どきスクラッチからOSを開発する、等という事はよほどの理由が無い限りやらないのでしょうね。

オブジェクト指向言語が多く使われているというのは興味深いです。オブジェクト指向言語のランタイムは比較的リソースが豊かな環境に向いていて、組み込みではCなどよりシンプルな処理系を持つ言語が適していると思っていました。スマートフォンやタブレットはリソースが豊富で、コードを削減したり処理負荷を軽減するよりもアプリケーション開発時の生産性を上げる事の方が重要、という事でしょうか。

モバイルアプリケーションプラットフォームひとつ取っても、色々と興味深い点が多いです。時間がある時に追加で調べてみようかと思います。