この記事の要約
- 英語が話せるようになれば、日本の人材市場ではなくグローバルの人材市場で自分の価値を判断されるようになる
- ITエンジニアにとって日本語のみの仕事はグローバルに比べて給料・待遇ともに劣っていて、各種経済予測からこれが改善されることは絶望的
- 英語使ってグローバル企業で働くことは、「一攫千金や立身出世を狙う野心家のキャリアパス」ではなく、ITエンジニアにとって生き残るための必須能力となりつつある
voluntas-bot (以下bot) とは、 @moriyoshit が開発した pyspa チャットのための bot ツールである。普通のchatbot同様、コマンド入力に応じた動作を行うことができるのが、sayingコマンド(通称「語録」)という非常にユニークな操作ができるのが特徴である。本記事では、主にこのsayingコマンドの進化に絞った形でのbotの発展の歴史を振り返っていく。
初期の saying コマンドの運用は、まさに文字通り、参加者の語録を保存しランダムに表示するためのものとして用いられていた。
例えば、moriyoshi が「いくつになってもsvnを触るとドキドキするもんだよ」とチャットで発言し、これを私がとても面白いと思ったとする。そのとき、私は moriyoshi の発言をヲ語録として登録することができる。
!moriyoshi いくつになってもsvnを触るとドキドキするもんだよ
このように登録された語録は、あとからランダムで一つ取り出すことができるようになる。
!moriyoshi
> いくつになってもsvnを触るとドキドキするもんだよ
また、任意のユーザを追加できることができる。例えば、私の語録を新規に作成したい場合は以下のコマンドを実行すればいい。
!saying create shiumachi
見ての通り、非常に単純なkey-value型のデータストアをベースとしたコマンドであり、仕組み自体はとても簡素なものである。この基本的なアーキテクチャは現在も全く変わっていない。
しかし、たったこれだけの仕組みで非常に多様な表現ができるようになるのである。その変遷をこれから紹介しよう。
複数の語録を連結して表示する機能が追加され、そして文字列リテラルが追加された。
その後、誰かが「誰」「何」という語録を作成した。続いて、「サ変」という語録を作成した。
これにより、以下のようなコマンドが実行できるようになった。
!{誰}が{何}を{サ変}した
> ドラえもんが10万円を確定申告した
このように、名詞とサ変動詞を語録として保存しランダムに取り出すことで、文章の自動生成が可能になったのである。
当初のsayingコマンド開発時の想定から大きく離れた、全く別の活用方法である。
この品詞語録の特徴はあくまで「人力」ということである。
ただ同一品詞の言葉を集めてをDBに追加するだけなら簡単なのだが、重要なのは pyspa チャット参加者が、pyspa チャットの発言を見て面白いと思ったと品詞を追加するというというプロセスである。
これにより、pyspa チャットの人達の琴線に触れる品詞のみが集積されていき、生成される文章が pyspa チャット参加者にとって面白くなる確率を上げているのである。
上記の文章の例は比較的一般の人でも楽しめるようなものを取り上げたが、実際には pyspa チャット内でのみ楽しめるような内輪ネタのような文も多く生成されている。
また、語録を連結したコマンドそのものも語録として登録できるようになった。
これにより、生成パターンそのものをランダムに出力させることができるようになった。
たとえば、以下のように「日記」語録を作成することができる。
!日記 {今日は}{誰}{と}{どこ}{に行って}{どうした}{。by}{誰}
!日記
> 今日は蒼井そらと歓楽街に行って買い取った。by tokibito
品詞語録が作れるのであれば、同じモーラ数で集めた語録も作ることができることは明白である。モーラとは、言葉の音の拍子の数のことである。例えば、「バルク」「あの日」「手術」は全て3モーラである。詳細は wikipedia の該当項目を参照してほしい。 https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%BC%E3%83%A9
これにより、俳句語録を作成することができるようになった。
!俳句 {2}{3}{" "}{5}{2}{" "}{3}{2}
!俳句
> カツ麻薬 ディープキス事故 破壊キス
俳句というにはあまりに風情のない生成文ではあるが、五七五の音を作り出すことができるようになった。
あるとき、モーラ語録に登録された言葉を三種類に分類できることに気づいた。
これを元に、従来のモーラ語録から一部の言葉を「接頭」「接尾」語録に振り分けた。たとえば「3」語録なら、「3接頭」「3接尾」というようにである。
これを活用し、俳句語録の改良版である「俳句2」語録を開発した。
!俳句2 {3接頭}{2}{" "}{4}{3接尾}{" "}{5}
!俳句2
> 地味な海 邪気眼匂う 秋深し
この改良により、俳句としての美しさが格段に上がり、より深みのある自動生成俳句を楽しむことができるようになった。
しかし、俳句2もまだ完璧というわけにはいかない。接頭・接尾のような分離が難しい5・
7語録にも問題が残されている。
例えば先ほど例でとりあげた俳句「地味な海 邪気眼匂う 秋深し」は、本来この「秋深し」は初句(一番最初の五の部分)に来るべき内容であり、結句(一番最後の五の部分)に表示されるのはふさわしくない。
これは短歌にしたときに7語録にも同じ話が言える。下の句である七七のどちらの位置で生成されるのがふさわしいかは内容によって異なるのである。
そこで、「5初句」「5結句」「7中句」「7結句」を作成し、「俳句3」を開発した。
!俳句3 {5初句}{" "}{7中句}{" "}{5結句}
!俳句3
> 寂しさに キングファイルが 救世主
「誰」「サ変」に代表されるに品詞語録によって、簡単な文章の作成は行えるようになった。しかし、長文を生成するとなると、生成された単語を繰り返し使う必要が出てくる。これを実現するには変数束縛の仕組みが必要である。
moriyoshiがいくつかの方式を実装したが、文法がかなり複雑であまり普及しなかった。しかし、rsub関数の登場により変数束縛の時代が訪れることになった。
rsub 関数はpython の re.sub() にインスパイアされた、正規表現マッチングによる置換機能を持つ関数である。
最もシンプルな(そして想定された)使い方は、生成された文章の特定の語を置換することである。
!rsub("[ww]", "笑", がーすー)
> 地獄絵図じゃないっすか笑
しかし、正規表現のグルーピングを利用することで、変数束縛を行うことができる。
!rsub("(.*)::(.*)", "昨日、"{$1}"が"{$2}"に行ったら、"{$1}"の妹に会った。", {random}"::"{どこ})
> 昨日、とんぷーがハト小屋に行ったら、とんぷーの妹に会った。
変数束縛したい言葉を第三引数に記述する。第三引数全体にマッチさせることで第三引数は最終的に生成させず、第二引数に記述された「置換後の文章」が実際に生成される文章のベースとなる。
!伝記 rsub("(.*)::(.*)::(.*)",{"その昔、"}{$1}{"という日本人が"}{$2}{"で活躍したという文献が残っている。
"}{$1}{"は旅の"}{職業}{"だったが実は"}{$3}{"の達人で、秒間"}{nine}{num}{"回も"}{$3}{"することができたため、"}{$2}{"が危機に瀕したときに大いに役立った。
"}{$1}{"の子孫は"}{random}{"という名で、今も日本にその血筋が残っている。"},{random}{"::"}{国}{"::"}{サ変})
!伝記
> その昔、とんぷーという日本人がカザフスタンで活躍したという文献が残っている。
とんぷーは旅のゲームクリエイターだったが実は割り勘の達人で、秒間63回も割り勘することができたため、カザフスタンが危機に瀕したときに大いに役立った。
とんぷーの子孫はaodagという名で、今も日本にその血筋が残っている。
それからしばらくして、let関数が実装された。これによって変数束縛はより容易になった。上記のrsub関数による伝記語録は、以下のは、語録と等価である。
let({"その昔、"}{主人公}{"という日本人が"}{活躍国}{"で活躍したという文献が残っている。
"}{主人公}{"は旅の"}{職業}{"だったが実は"}{スキル}{"の達人で、秒間"}{nine}{num}{"回も"}{スキル}{"することができたため、"}{活躍国}{"が危機に瀕したときに大いに役立った。
"}{主人公}{"の子孫は"}{random}{"という名で、今も日本にその血筋が残っている。"}, 主人公(random), 活躍国(国), スキル(サ変))
といっても4月1日の話なのでもう一ヶ月以上も前になるのですが、色々と忙しくて後回しにしてました。
ブログで転職報告してから4年の間、どういう仕事をしてきたのか書いてないことに気づいたので、せっかくなのでちょっとまとめてみようと思います。
「朝、ベッドから起きると、そこが職場になっていた」
この感覚は今でも忘れません。オフィスも同僚もいなかった私は、在宅勤務という形で Cloudera での仕事を始めました。1Kの小さいマンションに住んでいたため他の作業部屋がなく、自分のベッドの横の机がそのまま仕事場になりました。
サポートエンジニア(今は COE = カスタマー・オペレーション・エンジニアという名前になっている)として今の会社での仕事を始めたのですが、肩書き通りの仕事だけをしていればいいなんていうことは当然あるわけもなく、日本にいる唯一のエンジニアとして何でも仕事をこなさなければなりませんでした。 (営業などは別にいました)
私が日本で最初に行った仕事らしい仕事は、Hadoopのトレーニングの講師の補助でした。当時はまだ日本のインストラクターがいなかったため英語で開催していたのですが、通訳などのコミュニケーション補助を行いました。
前職 NEC とは全く異なる文化で、本当に驚くことばかりでした。一番衝撃だったのはクビを切ることに対する文化です。
初めての出張で US のオフィスに行き、オフィスのトイレであるエンジニアと会話しました。
「よう、お前日本から来たんだってな。お前の斜め後ろの席あたりに座ってるから、なんかあったらいつでもいってくれよな!」
この会社に入ってから感じのいい人ばかりに巡りあっていて、この人もまた愛想のいい人だったので、やっぱりこの会社に入ってよかったなとそのときは思いました。
一時間後、一通のメールが全社員宛に届きました。
「◯◯はもうこの会社にはいない。本人のプライバシーを守るため、本件については一切口外しないように」
青ざめました。あまりに怖くて、彼が座っていたデスクの方を振り向くことさえできませんでした。どんなにみんなフレンドリーでも、ここはアメリカの会社なんだと再認識しました。
今ではすっかり名作アニメとなってしまった、当時放映されたばかりの「魔法少女まどか☆マギカ」の巴マミの末路を思い出し、いきなり目の前から人が消えるってこういうことなんだなと感じました。
それから数日後、別の社員がメールを送ってきました。
「新人研修を担当している××だ。アメリカにいるうちに研修やるから、来週の月曜時間空けといてくれよ」
彼は月曜に出社しませんでした。メールボックスには「××はもうこの会社にいない」という全社宛のメール。最初の一件のインパクトが強すぎたのか、2回目は最初ほどショックを受けませんでした。結局この研修を受けることはありませんでした。
衝撃的だったのはその週の金曜夜でした。会社の飲み会があって参加したのですが、普通にクビを切られた彼も参加していたのです。
「だからオレ達の会社がさ、おっと失礼、君たちの会社がさ、」なんてジョークを飛ばして笑い合ってたのです。日本における「クビ切り」とは全く感覚が違うのだとそのとき理解しました。
一応後から学んだ知識で補足すると、この彼は多分どちらかというと例外に属し、実際にはクビを切られるというのは多くの人にとってあまり気分のいいものではないのは間違いないはずです。ただ、クビを切られる=人生の終わり、みたいに捉える人はまずおらず、誰にでも起こりうることという捉え方はされています。
年の始めにようやく小さなオフィスを構えることができました。といっても用意されたのはオフィススペースだけで、家具は自分達でそろえなければなりませんでした。その当時のメモがこちらに残っています。
日本でも少しづつ知名度が上がり始め、顧客もパートナーも増えてきたため、次の社員を雇う必要がでてきました。
英語もしゃべれて技術力もあり、しかもこんな小さい会社に来てくれる人となると探すのが非常に困難です。
そこで友人の @d1ce_ に声をかけることにしました。こんな簡単にクビを切られるような会社に友人を誘うというのは本当に勇気がいるものです。彼にはこの会社に勤めるリスクやデメリットなど、知りうることを全て説明しましたが、それでも彼は来ることを選択してくれました。
今では日本はもちろん Cloudera のグローバルでもトップクラスの COE として活躍しています。正直ここまで活躍してくれるとは想像もしませんでしたが、本当にいいエンジニアを誘えたと思っています。
@d1ce_ が一人前の COE としてサポート業務の活動を回せるようになる一方で、私はサポート以外の業務がどんどん増えていきました。そこで、当時社内でもかなり特殊な仕事だったプロアクティブサポートエンジニアという職種にロールチェンジすることを選択しました。
このプロアクティブサポートエンジニアは、サポートチームに属してはいるものの顧客対応がメインの仕事となるため、当時の自分の業務内容にピッタリな仕事でした。
後にプロアクティブサポートの仕事のうちの顧客対応の部分はセールスエンジニア側に継承されていき、ロール自体はよりサポート特化となっていきますが、これが後の私の2回目のロールチェンジにつながっていきます。
この当時はサポートを実際に購入した顧客向けの、ある意味「ポストセールスSE」としての活動がメインでした。
また、この年から APAC として組織的な強化をし始め、同じタイムゾーンの同僚が急激に増えていきました。
今まではほとんどの同僚がアメリカやヨーロッパに住んでいたために時差を気にして仕事をすることが多かったですが、同じ業務時間中に連携できるというのは非常に心強いことでした。
長らく日本の面倒を見てくれていたコンサルの方が外れ、新しい日本のトップがチームに加わりました。この人は日本語を全くしゃべれなかったため、オフィスの言語は英語になりました。
この年に私は2回目のロールチェンジを行い、セールスエンジニアとなりました。といってもサポートチームの仕事もある程度引き続き行っていて、結局のところ二足のわらじを履いていたのが非公式から公式になったようなものでした。
このセールスエンジニアという仕事はサポートとはまた違う方向で面白い仕事です。
サポートを行っているとどうしても異常系に偏って技術力が伸びる傾向になり、どこをどうすれば壊れるか、という知識は多くなります。
一方セールスエンジニアは、どこをどう使えばやりたいことを実現できるか、という正常系の知識が多く要求されます。
セールスエンジニアは顧客が購入にいたるまでの技術的な責任を持つというのが仕事で、自社の製品をどう使えばどのようなことができるのかということをきちんと理解し、場合によっては独自に調査する必要があります。
当然自分だけの知識では対処しきれないため、グローバルの人達の力を借りることになります。各技術の最先端のエンジニアと様々な議論をしながら顧客のニーズを実現するための方法を模索していくというのは非常に楽しい仕事です。
日本ではもちろんのこと、もうすっかり社内でも古株になってしまいました。
入社当時に比べて社員の規模は10倍以上になりましたし(正確な数字は秘密)、日本もどんどん人が増えていっています(こちらも正確な人数は秘密)。先日はオフィスも新しい場所に移り、大分広くなりました。
さすがに会社に在籍中の身なので書けないこともたくさんありますが、上に書かれていないところで大変なことがたくさんありました。順風満帆とはほど遠い道のりをたどっていますし、何度も「もうおしまいだ」と思ったものです。
そもそも明日どうなるかも分からない世界です。こんな記事を書いてて翌日にクビになっててもおかしくありません。
面倒なことだってたくさんあります。やりたくない仕事もあります。それでも会社を辞めないのは、やりたいことがたくさんあるからですね。
Hadoop を日本で広める手伝いをしようと思って今の会社に転職して4年経ちましたが、それでもまだまだ普及にはほど遠い状況です。
既に US では昔の Hadoop から脱却して汎用の大規模分散処理・大規模分析処理の基盤としての地位を確立しつつあるのに、日本では昔の Hadoop すら理解していない人が多い状況です。
昔も今もたびたび Hadoop 不要論が唱えられたりしていますが、実際に顧客の話を聞いてみると、明らかに Hadoop を使った方がやりたいことを実現できるというケースはたくさんあります。
そうした人達にこの技術の価値をもっと伝えていければと思っています。
また、この会社には一流の技術者がたくさんいます。それも、世界でトップクラスの技術者です。技術者だけじゃなく、ビジネス側にも優秀な人達がたくさんいます。こうした人達と一緒に仕事できるというのは本当に楽しいです。
社員だけでなく顧客も優秀です。海外はもちろん日本でもかなり先進的な取り組みをしているお客様がたくさんいます。こうした人達と一緒に仕事できるのも魅力ですね。
……と、こんな感じでこの会社のいい部分というのをたくさん挙げることができるうちは他の会社に行かなくてもいいかなと思ってます。
そんな私と一緒に東京でセールスエンジニアとして働きたい!と思った方はこちらからご応募ください。
最近 ask.fm 始めましたので質問があればこちらに。
有用そうな内容はこちらの記事にも転載します。
質問は公開されます。どうしても個人的に質問したいのであれば、別の方法でご質問ください。
いくつかの想定質問と回答を先に書いておきました。
よく聞かれるんですがそんな言うほどもらってないです。同じ業界のエンジニアと話してたら「そんな安いの?」って驚かれたレベル。それでも前職よりはもらってます。
生活できるので別に困ってないし不満にも思ってないです。
「営業活動に関わる技術全般」です。デモ環境作ったり技術説明のプレゼンをしたりというのが定番ですが、ぶっちゃけ何やってもいいです。
Cloudera だと ASF で開発やっててコミッターになったりとか本書いたりとか色々います。個人的には会社のエンジニアの中で一番フリーダムな仕事と思ってます。
普通に大学受験の勉強ですね。面接は当然英語なのでそこでもまた事前に特訓しましたが、今の英語力はほとんど入社してから身につけました。
英語の勉強法については私が4年前に書いたこちらの記事をご覧ください。
(追記) 「お前帰国子女だろ!」ってツッコミがあちこちから入りましたが、ぶっちゃけ小学校低学年の語学力なんて大したことないので今の英語力にほとんど影響ないと思いますよ……。
ask.fm を埋め込む方法がわからなかったのでツイートで代用してます。
「もうおしまいだ」とはどういう時に思ったのですか? — 言えるくらいならとっくに書いてますね……。どのくらいのレベルかというと、「HARD THINGS」を読んで「あ、これよりは100倍マシだったわ」と思ったレベルです http://t.co/bwab8lchfU
— Sho Shimauchi (@shiumachi) May 10, 2015
転職するに当たって何を重視したかお聞きしたいです。 — 忘年会にすき焼き食べてたら「来ない?」って誘われました。ほんとそれだけです。こんな機会一生に一度あるかないかと思ったので失敗してもいいからやってみようと思いました。 http://t.co/szPHmKyfOb
— Sho Shimauchi (@shiumachi) May 10, 2015
本社とのタイムゾーンが違うことで、苦労した点などあればお聞きしたいです。 — 先日も午前1時〜午前8時でミーティングに参加したおかげで次の日(というかその日)風邪で寝込みましたが、特に苦労した点はありませんね http://t.co/wS2K4E910u
— Sho Shimauchi (@shiumachi) 2015, 5月 11
首相官邸へのドローン襲撃事件をきっかけに、日本でもドローンに対する規制の議論が盛り上がってきました。
意外と規制反対している人が多くて驚きましたが、実際に海外だとどんな規制があるのだろうと思って調べてみました。
(注意: 私は法律の専門家でもドローンの専門家でもありませんので、記載内容の正当性に関して何ら保証することはできません。この記事を利用して発生したいかなる損害についても責任は負いません)
元ネタ: http://droneflight.co.uk/pages/summary-of-uk-legal-requirements
ドローン開発会社 Droneflight 社による、イギリスでの法規制のまとめです。
法律そのものを読みたいかたはこちら: http://www.caa.co.uk/docs/33/CAP393_ANO_Jan2015.pdf
管轄: イギリス民間航空局 (UK Civil Aviation Authority)
用語 | 説明 |
航空機 | ドローンを含む航空機全般。ここではドローンと読み替えて問題ない |
小型無人航空機 | 要するにドローンのこと。 |
遠隔操縦者 | 要するに操作している人のこと。 |
CAA | イギリス民間航空局 |
先ほど紹介したページに、以下のような項目としてまとめられています。
また、上記とは別のドローンに関連する規制が存在します。
故意かどうかに関わらず、小型無人航空機に搭載された偵察カメラの利用時に収集された個人を特定できる画像は、データ保護法の管理下にあることに注意すること。この法律にはそのような画像の収集、保存、利用についての要求が含まれているので、小型無人航空機の操縦者は適切な要求及び免除規定に従っていることを保証しなければならない。詳細については www.ico.org.uk を参照のこと。
元ネタ: http://knowbeforeyoufly.org/for-recreational-users/
Know Before You Fly という、無人航空システムのNPOであるAUVSIを始めとしたいくつかの団体による啓蒙キャンペーンのサイトです。
上記の規制まとめは個人用で、他に商用向けと公共団体向けが存在します。情報が多いので全部はまとめません。必要に応じて原文を読みましょう。
管轄: 連邦航空局 (Federal Aviation Administration)
用語 | 説明 |
UAS | unmanned aircraft system. 無人航空機、すなわちドローンのこと。 |
sUAS | small UAS。小型無人航空機。 |
FAA | 連邦航空局 |
繰り返しますが、この規制は個人向けです。商用の場合は上記リンクから別ページを参照してください。
先日ちょっと出張でニューヨーク行ってきたのでingressをプレイしてきました。
たくさんポータルキーを取得したのですが、帰国後は特に使い道もなかったので泣く泣く処分。
ただ捨てるのももったいないので、記録として残すことにします。
また、NYCでプレイした感想も記しておきます。
プレイしたエリアはセントラルパーク南部からブロードウェイあたりです。
忙しくてほとんど時間がなく、まともにプレイできたのは帰国直前の2時間程度でした。それでも UPV 200 / UPC 60 ぐらいは稼ぐことができました。
ポータルは両陣営ともボロボロで、まともにリンクすら張られていません。旅行前に X8 を集めておけば、簡単に落とすことができるでしょう。
相手陣営からの反撃もありません。「ならやりたい放題じゃん?」と思うかもしれませんが、そうは甘くはありません。リアルに危険なので、常に現実世界の周囲に気を配ってプレイする必要があります。日本のように、夜中にスキャナ見ながら歩くなんてことはできません(日本でやっても危ないので控えましょう)。
ポータルの数は確かに多いのですが、日本に比べて圧倒的に広く、ポータル密度はかなり薄いです。山手線の主要駅の密度の半分以下と思って間違いないです。なので、徒歩で移動するのはかなり大変です(先述のスコアはかなりの早歩きで達成)。
高層ビルが多く、GPSがとりづらいところも多いです。西新宿や渋谷、東京丸の内のGPSの飛び具合をイメージしてもらうとわかりやすいでしょう。
注: 私はNYCに数日滞在しただけなので、以下の感想が正しいかどうかは全くわかりません。このメモを信じて行動して何かあっても責任とりませんのでご注意ください。
スバル男爵(本人の意思により仮名)からしきりに薦められていた Ingress ですが、待望の iOS 版が登場したので早速プレイしました。
陣営はレジスタンス(青)です。
以下のページを一通り読んで、基本知識を頭に入れておいた。
http://ingressjp.blogspot.jp/
初期装備の購入。
18:00 頃、麻布十番駅付近で電車に乗っている際に iOS 版リリースのツイートを発見し、その場で下車、ユーザ登録を完了。駅を出てプレイ開始。
チュートリアルに従い、レゾネータを挿したりリンクを貼ったりしてみる。
その後ふらふらと歩いてハックしつつ、地下鉄に乗って帰宅。
ここで、地下鉄を使うと移動中にアイテム回収ができないことを知る。
帰宅後、自宅付近のポータルを自転車で巡回していく。
自宅近辺が緑になっていることを知る。
この日のうちに 47,000 AP 稼ぎ、レベル3に。
自宅付近のポータルを自転車で巡回。
昼間、地上の路線に乗る機会があった。どうも一定速度以上の移動をしているとハックはできないようだ。しかしXMの回収はできるのでリチャージが大量にできることがわかった。
夜、intel マップを見ていると、丸ノ内のオブジェがたくさんあるエリアで白ポータルが大量に出現しているのを発見。
帰宅時に1時間ほど巡回し、3万ポイントほど稼ぐ。
帰宅後、自宅付近のポータルを自転車で巡回。
レベル4、102,000 AP。
朝は自転車で巡回。
夜は スバル男爵 に誘われて六本木から麻布十番でレベル上げ。ここで 12万→19万と7万AP稼ぎ、L5に。
ここで高レベル者からX5 (レベル5のXMPバースター) を大量にもらった。
まだモバイルチャージャーを入手していなかったため2時間でバッテリーが枯渇。離脱した。
帰宅後、自宅付近のポータルを自転車で巡回し、CFを貼っていく。
レベル5、21万AP
ついにモバイルチャージャーを入手。
夜は スバル男爵 と一緒に丸の内を攻撃。
スバル男爵 が破壊し、私がレゾネータを挿していくというスタイルでプレイした。
これで22万→30万と8万稼ぎ、L6に。
帰宅後、自宅付近のポータルがアンカーポータルになっていたので潰してきた。
帰宅時、麻布十番に立ち寄りいくつかのポータルを奪い取る。
帰宅後、雨が降りそうだったので傘を持って徒歩巡回したが結局降らなかった。
近所のポータルを2つほど落とす。X3が200個ほどあったが全部使い切った。
この日は7万APほど稼ぎ、現在 38.5万 AP。
連休第1日。
午後、 スバル男爵 と一緒に麻布十番・六本木を回る。ここで20万稼ぎ、A7に。
このとき、緑が麻布十番にいたらしく、 スバル男爵 が破壊して白ポータル(レゾネータが挿されていない状態で、どちらの陣営のものでもないポータル)が奪われていった。私たちは二手に分かれ、別々の場所で「破壊」「設置」を行っていった。また、緑エージェントの位置を読みつつ、相手の裏をかいて緑にしたばかりのポータルの場所まで回りこんで再度取り返したりもした。
これが本当に楽しい。麻布十番の適度な広さといい、まさに現実世界で FPS をプレイしている気分だった。
その後休憩しながら スバル男爵 の講義を受ける。
また、このとき地域コミュニティのハングアウトに参加する。
スバル男爵がX7等の物資をたくさん支援してくれた。
レベル7、61.8万 AP。
連休第2日。
10時過ぎに出発。近所のポータルを回りつつ、最寄り駅ではなく次の駅まで徒歩で移動。
道中いくつかの緑アンカーポータルを破壊して回った。X7は強力だがもったいないのでX5メイン。
霞ヶ関に向かおうと思ったが、新橋エリアも緑で埋まっていたので、予定を変更し新橋から内幸町、御成門のあたりのポータルを全部青に染め上げた。
83万AP。
夜、iPhone 組でレベル8に到達した人がいたという話を聞いた。自分も負けてはいられない。
朝7時半出発。霞ヶ関を攻める。14時まで霞ヶ関〜内幸町方面までを攻略。
この時点で107万。24万ほど自力で稼いだ。
ソロでの長時間プレイだと圧倒的に低レベルのレゾネータが足りないので、P4(レベル4のポータル)に調整してグリフハックすることにより現地調達を行った。
その後 スバル男爵 の地元に移動し、地域コミュニティの人とも連携して近所のエリアの復旧作業を行う。
復旧作業中の午後5時、無事レベル8に到達。レベル8までの到達時間は6日と23時間。ギリギリ一週間以内に達成できた。
忙しい中たくさんの時間を割いて私のレベル上げに付き合ってくれた スバル男爵、本当にありがとうございました!
また、私のような初心者に温かいアドバイスをしてくれた青陣営の皆様もありがとうございます。
タイトルとスライドの通りです。
Hadoop Conference Japan を運営された皆様、本当にお疲れさまでした。
また、私のセッションに参加して話を聞いていただいた皆様、ありがとうございました。
朝のキーノートで「使用しているコンポーネント」で Impala がランクインしていて実は結構驚きました。まだまだ普及していないと思っていましたけど、意外と使われているようでうれしいです。
(後 Hue がランクインしているのにも驚いた)
今回は他のSQLエンジンのセッションの間に挟まれての講演だったので、これは気を抜けないなと思い、結構頑張ってスライドを作りました。
やっぱり調べてみると Impala はとても面白くて、機能の細かい部分などを見て新たな発見もたくさんすることができました。
Impala が爆速なのは疑いようのない事実で、これをどう説明するか思案しましたが、結局 US で公開している以下のブログをベースに紹介することにしました。ブログを日本語訳にしてなかったのでちょうどよかったかなと。
http://blog.cloudera.com/blog/2014/05/new-sql-choices-in-the-apache-hadoop-ecosystem-why-impala-continues-to-lead/
ソースコードもあらためて読んでみると非常に楽しく、新たな発見がありました。
Impala のソースコードは、ヘッダファイル部分のコメントで仕様について非常に詳細に書かれていて、もう一つのドキュメントと言ってもいいぐらいです。
例えば simple-scheduler.h というヘッダファイルの一部は以下のようになっています。
// Performs simple scheduling by matching between a list of backends configured // either from the statestore, or from a static list of addresses, and a list // of target data locations. // // TODO: Notice when there are duplicate statestore registrations (IMPALA-23) // TODO: Handle deltas from the statestore class SimpleScheduler : public Scheduler { public: static const std::string IMPALA_MEMBERSHIP_TOPIC; // Initialize with a subscription manager that we can register with for updates to the // set of available backends. // - backend_id - unique identifier for this Impala backend (usually a host:port) // - backend_address - the address that this backend listens on SimpleScheduler(StatestoreSubscriber* subscriber, const std::string& backend_id, const TNetworkAddress& backend_address, Metrics* metrics, Webserver* webserver, ResourceBroker* resource_broker, RequestPoolService* request_pool_service);
また、今回のスライドはUSの開発チームのレビューを受けるために全て英語で作成しました。
全レビューが終わった段階で日本語に再翻訳しています。
実際に使用していないとはいえ、英語で40分セッション用のスライドを作るのは初めてで、結構大変なんじゃないかなと思ったのですが、実際には英語のドキュメントの文言をそのまま流用できるなどのメリットも多く、そんなに苦労はしませんでした。再翻訳の分時間はかかりましたが。
今回は40分という時間の関係上機能や性能を紹介するだけで終わってしまいましたが、実際の使い方などについてもわかったことがたくさんありますし、アーキテクチャの深い部分とか、パフォーマンスチューニングの方法など、かなりのネタを集めることができました。残念ながら今回ほとんど紹介できなかったので、またどこかの機会で是非紹介してみたいですね。