MLB大谷早くも大活躍!

大谷翔平、サイ・ヤング賞右腕撃ち! 第2打席で2試合連発の同点2ラン! | Full-count | フルカウント ―野球・MLBの総合コラムサイト― - (2)

大谷すごい!こんなにも早く2HR打って、MLBファンも熱狂させてしまうとは。

自分が大谷の凄さを実感したのは、成功を確信したのは2015年のこと。 それは、なでしこジャパンの澤が引退したときに大谷が発したコメントが凄すぎたんだ。

「選手のうちに養える技術は10年、20年では足りない。暇な時間はあまりない。そのためにしっかりと大事に過ごしたい」

「全部知るのは無理だけど、ちょっとでも近づきたい。時間はみんな平等だけど、時間は足りない」

みんな分かる?これ弱冠21歳の若者が発した言葉ですよ。 20歳そこそこなんて、派手な金髪に袴はいてお酒飲みながら成人だー、なんてやっている人がいるくらいで、ましてや抑圧された高校野球時代からプロ野球に入った人は、みんなお金もいっぱい貰って、新しい遊びもいっぱい覚えて…一流選手と呼ばれる選手でさえそんな感じだと思う。

大谷は違う。これこそが超一流のメンタルなんだと思った。

日本人はショッピングモールがお好き

地元近くにショッピングモールがまた一つ出来る。 といっても、テナントに入る店はどれも超おなじみの全国店舗数最大規模のチェーン店ばかり。知らない店を探す方が難しい。

自分は新しく出来たからって、ショッピングモールなんて行かないけど。しかしこれだけ周辺にショッピングモール乱立で、どこもかしこも全く同じ店構えだったら、さすがのB層な人達(死語!)も行く理由ないんじゃないか?と思ってしまう。。 でも意外と人入るのかな?

そんなんよりも、空き地とか、少し高い鉄棒のある公園とか、壁打ち場が欲しいよ。探しても全然無いのさ・・・

阪神大山悠輔選手

今シーズンのタイガースで一番注目しているのが、大山選手。 昨年新人の年は打率.237に終わったけど、試合を見てとんでもない可能性を秘めた選手だと思った。

何が凄いって、打席でフォームが全くブレない。一線級の投手と対戦しても、自分のスイングを崩されない。 もう数年間チームの四番を打って来たかのような安定度。 新人でこんなのは初めて見た。いや正確には高橋由伸中村剛也以来か。

デビューしたての6月あたりは、明らかにプロのスピードに戸惑って崩されて二軍に落ちていったけど、戻ってきたら別人。 しかも凄いと思うのは、結果が出ていない時でも変わらずスイングに迷いが無いこと。

大選手に育って欲しい。

機内で観た映画

出張の帰りの飛行機の中で、久しぶりに邦画を見た。 普段絶対に見ないのだけど(昔は映画散々見たけど、今はほとんど時間の無駄だと思ってる)、今世の中でどんな映画が作られているのか、参考に知っておこうかなと思って珍しく見てみた。

はたして期待はしてなかったけど、これがほんとひどかった。 昭和時代の雑貨屋の店長が、悩み相談を手紙でやりとりするという内容なのだけれど、次から次へと、都合良く設定された感動させようとするだけの(感動の押し売り)ストーリーがオムニバス的に展開される。

こういう作品いっぱいあると思うけど、とにかく設定・プロット以外に何も伝わるものが無いんだよね。 『養護施設の子供を見舞ったらその晩火事になって、子供を助けるのとひきかえに亡くなってしまう。』 て書けば、もう映画を見たのと同じ。

見た後、どうしてこんなつまらない映画を作っちゃうんだろう、と考えた。

おそらく、原作はもっと描写のあるまともな作品なんだろう。 ヒットした原作を基にして、売れてる俳優そろえて、主題歌にいい曲持ってくれば映画はヒットする、と考えてるからなんだろうか。 何か伝えたいことがあって映画を作ってるんじゃなくて、映画を作って興行収入を得ることが目的。商業映画と言って片付けてしまえば、そうなのかもしれないけど。。

その時ね、ネットで見た小室哲也の引退のニュースを思い出した。

小室哲也のニュースは、引退とか不倫の話とかは全く興味無いけど、意外にも彼の話に共感した。 それは彼の、新しい音楽を作る自信が無くなった、枯渇したという告白だ。

売れていた時代は、ヒット曲をつくろうと思ってやっていたのではなく、好きな音楽をやっていたと。 それが、いつしかヒットメーカーのイメージとか、期待に応えなくちゃという意識の方が強くなってしまったんだろうね。

そして、今回自分が勝手に見た映画と結びつけたのだが、映画とか音楽とか小説って自己表現の場でもある、にもかかわらず、世の中のニーズに応えようとしすぎなんじゃないかと。

もちろん、今回のような商業映画は元々"売れる"ために作ってるのだから、売れさえすればOKなんだけど、 そうではなくて、いつの間にかそういうものに縛られてしまった人も多いんじゃないかと思う。

本来創作って、もっと自由であるべきなのにね。

ビジネスもそう。

マーケティングだの市場分析だの、競合分析だの、そういうものばかりやったところで、斬新で破壊的なビジネスは生まれない。

カイザースラウテルンより愛を込めて

研究目的の出張で、ドイツのカイザースラウテルン市に来てます。 今日が最終日、明日に帰ります。

移動を除くと滞在三日間という期間だったけれど、色々な刺激をもらって、思い出深い出張になりました。

今回の出張の目的の一つは研究開発のパートナー探しであって、議論を終えたあと、 『申し訳ないけど、今回の件はあなただけではなく、他の研究機関も候補としてあたっている』と自分が告げると、 教授はすぐにニコっと笑って、 『つまりうちのcompetitorがいっぱいあるって事だね。気にするな、我々は競争を恐れない』 と言ったんだよね。 あの言葉は凄く胸に響いたな。

翻ってうちの会社なんかはすぐに、競合がやっているから他の戦略を考えた方がいいだとか、ブルーオーシャンじゃないだとか、その業界に会社の強みが無いとか言って批判するんだけど。

本当に必要なのは、オリジナルな思想を持つことだと思った。

オリジナルというのは、必ずしもユニークである必要は無くて、でもそれは、ネットや本に書いてある戦略を真似したものなんかではなくて、 自分で考え、自分で手を動かし、自分で苦労して辿り着いた思想であること。

それがあれば、一度決めたことは簡単に揺らがないし、不測の出来事があっても、誰よりもうまくハンドルできるはず。

星野仙一死去

なんと星野さんが亡くなりました。病床という報道も無かったので驚きです。

昔、中日のファンだった友人が、星野が阪神の監督になった時に、星野が監督する間だけ阪神ファンになると宣言してその通りにしていた。それだけ魅力のある監督だったんだよね。 おそらく中日ドラゴンズが一番盛り上がったのも、1999年の優勝時でしょう。

自分は阪神ファンだけど、星野監督で一番印象に残ってるのは、1999年の優勝の年に山崎武司阪神戦でサヨナラHRを打って、ぐるぐる手回して、星野にどうだーってガッツポーズしたシーン。星野泣いてたし、阪神ファンの自分もジーンと来た。

その後、星野が阪神の監督だった2002, 2003年は本当に楽しかったな。阪神ファンをしていて、やっぱり一番盛り上がった時期。 野村監督から変わって思ったことは、全身全霊を掛けた真剣勝負って、こんなにも喜怒哀楽が出るんだってこと。

そして星野は2003年は絶対優勝すると宣言して、開幕戦を見に行ったら、応援団が配ってた歌詞の紙に、「阪神優勝シリーズ」って書いてあったくらい、みんな絶対優勝すると信じてた。 終盤戦の緊迫感なんか、試合見ているこっちにも、ものすごい伝わってきて、勝ったときはいつも矢野と同じ渾身のガッツポーズが出たよ。

中日、阪神楽天のファンはみな同じ思いを受け取ったでしょう。

星野さんには、一番熱く燃えていたあの時代をありがとう、とお礼を言いたい。

それにしても島野さん、星野さんと続いて、意外にも一番奔放そうな田淵が長生きとはね…

GoogleTestの使い方と仕組み

GoogleTestの使い方

(今回googlemockの説明はしません)

  1. GoogleTestのソースコードを持ってくる https://github.com/google/googletest

  2. GoogleTestをビルドする GoogleTestのビルド方法は二つある。1. あらかじめコンパイラしてライブラリ化しておく方法と、2. 自分のテストプログラムと同時にコンパイルする方法。

    1. あらかじめビルドする場合は、CMakeを使ってGNU向けのMakefile、もしくはWindowsの場合はVisual Studioのソリューションを作り、ビルドしライブラリ(静的ライブラリの場合gtest.lib)を作っておく。 具体的には、GoogleTestのソースをクローンもしくはダウンロードした際の、トップディレクトリの下にビルド用のディレクトリを作り(buildとする) buildディレクトリに入って cmake ../と打つ。cmake-guiの場合は、ソースディレクトリにGoogleTest自体のディレクトリを、ビルドディレクトリにbuildを選ぶ。出来たMakefileVisual Studioの場合はソリューションファイル)を実行して作成。
    2. テストプログラムと同時にビルドする場合は、(install directory...)/googletest/src/ にあるgtest-all.ccを、ビルドの対象に設定する。(その際には、(install directory...)/googletest, (install directory...)/googletest/includeをビルド時のインクルードパスに追加することを忘れずに)

    個人的には2. がオススメ。この方法だと、特にWindowsのようなランタイムライブラリの整合のために、テストプログラム側のビルドオプションと、GoogleTest側のビルドオプション(GoogleTestのソリューションファイルでのランタイムライブラリを、マルチスレッドにしたりしなかったり、デバッグにしたりリリースにしたり)のといった変更の必要がなくなるから。

  3. テスト用のメインプログラムと、テストケースごとのテストプログラムを作り、ビルドする。

テスト用メインプログラム

GoogleTestを使ったテストプログラムのメイン関数はこんな感じになる。

#include "gtest/gtest.h"

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}
テストケースの記述

テストケースの記述は、TESTマクロもしくはフィクスチャを利用する場合はTEST_Fというマクロを使い、以下のように記述する。

TEST([TEST_CASE_NAME], [TEST_NAME])
{
  // user defined test routine
}

TEST_F_([CLASSS_NAME], [TEST_NAME])
{
  // user defined test routine
}

とにかくこれを好きなだけ書くと、RUN_ALL_TESTS()によって、全てのテストケースを自動で探して実行して、サマリを出してくれます。 TEST_CASE_NAME, TEST_NAMEには好きな名前を入れられる(サマリに分かりやすく表示するためのもの)。フィクスチャの場合は、[CLASS_NAME]に、フィクスチャに使うクラス名を入れる。 細かい使い方については以下を参照。 http://opencv.jp/googletestdocs/primer.html

GoogleTestの仕組み

一度分かってしまえば簡単なのだけれど、最初はフィクスチャは何の為にどうやって使うのだろう、という人もいると思うのでに、初心者向けに簡単な仕組みを説明します。

まず、フィクスチャというのは、最も良く使われるのは、複数のテストを実行するときに、テスト間で共通に実行する処理だったり、同じデータや変数を共有したい場合に使う。 例えばあるデータを読み込んで、少し変更して保存(シリアライズ)するようなテストで、読み込みは同じなのだけれど、保存はデータ変更の種別によって別々のテストケースとして分けたい、といった場合に、データの読み込み部分は共通化したい。こういうケースである。

こういうテスト間で共通の処理をやりたいケースでは、以下のようにフィクスチャを使ったテストを作る。 つまりユーザーは、テスト間に共通して持たせたいメンバを持ち、共通して実行させたい処理をSerializeTestのSetUp(), TeatDown()メソッドに書く。最後にTEST_Fのテスト関数本体のマクロ引数の一番目として、フィクスチャクラス名を書けば良い。

class SerializeTest : public testing::Test {
protected:
  // member
  FooData foo_data;
  
  // method
  SerializeTest() : foo_data() {}
  ~SerializeTest() {}
  
  virtual void SetUp() {
    openData("name");
    readFooData(&foo_data);
  }
  virtual void TearDown() {
    closeData("name");
  }
};

TEST_F(SerializeTest, change_a_type) {
  foo_data.a_type_data  = new_a_type_data;
  writeFooData(&foo_data);
  checkSerialize(&foo_data);
}

TEST_F(SerializeTest, change_b_type) {
  foo_data.b_type_data = new_b_type_data;
  writeFooData(&foo_data);
  checkSerialize(&foo_data);
}

これでテストを走らせると、RUN_ALL_TESTS()が実行され、TEST_Fのマクロを使って定義されたテスト関数を実行するときには、TEST_Fの引数の最初のクラスがフィクスチャのターゲットクラスとして呼び出されるようになる。 このプロセスの中身は以下のようになっている。

inline int RUN_ALL_TESTS() {
  return ::testing::UnitTest::GetInstance()->Run();
}

この呼び出しを追っていくと、UnitTest::Run()の中で、UnitTestImpl::RunAllTests()が呼び出され、その中で各テストケースを実行するTestCase::Run()、そしてTestInfo::Run()が呼び出されている。 TestInfo::Run()の中で実際に、フィクスチャとして定義したクラスのインスタンスがまず生成され、その時にフィクスチャクラスのコンストラクタも呼び出される。 そしてテスト実行前にSetUp()が実行され、テスト実行後にTearDown()が実行される。

ではここで、どういったクラスのインスタンスが生成されているかは、マクロの内容を追っていくことで分かる。

まず、マクロによってフィクスチャとしてテスト共通で維持すべきクラスの名前が、test_fixture_test_name_Testのように決められて(#defineの中の##は連結。上記の例ではSerializeTest_change_a_type_Testというクラス名になる)、 フィクスチャの定義でユーザーが作ったクラスを親クラスとします(上記の例ではSerializeTestクラスを親クラスとして子クラスの定義が作られる)。

この子クラスの定義では、コンストラクタと、TestBody()メソッド、TestFactoryImplを使って、インスタンスを生成しTestInfo*を返すメソッドが定義される。

そしてマクロ展開の最後が、この子クラスのメソッドのTestBody()のシグニチャ部までとなっており、メソッドの定義が、ユーザーが書いたテストルーチンとなるようになっている。

void GTEST_TEST_CLASS_NAME_(test_case_name, test_name)::TestBody() <-- expanded by Macro
{
  // user defined body routine ...
}

まとめ

つまり、ユーザ視点で簡単にまとめると、各テスト毎にユーザーが書いたフィクスチャクラスがインスタンス化されて、コンストラクタ、SetUp()が実行される。 (テストケース毎では無いので、各テスト毎に毎回インスタンス化され、実行されることに注意。テストケースにつき一度しか実行したくない場合については、staticなメンバとメソッドを使う方法が上級ガイドに記述されている)

そして、テストクラスのTestBody()メソッドとして定義された TEST_F(test_fixture, test_name) の部分が実行され、最後にTearDown()が実行される。 これを全テストケースで繰り返す。以上。

マクロの定義抜粋

#if !GTEST_DONT_DEFINE_TEST
# define TEST(test_case_name, test_name) GTEST_TEST(test_case_name, test_name)
#endif

#define TEST_F(test_fixture, test_name)\
  GTEST_TEST_(test_fixture, test_name, test_fixture, \
              ::testing::internal::GetTypeId<test_fixture>())

#define GTEST_TEST_CLASS_NAME_(test_case_name, test_name) \
  test_case_name##_##test_name##_Test

// Helper macro for defining tests.
#define GTEST_TEST_(test_case_name, test_name, parent_class, parent_id)\
class GTEST_TEST_CLASS_NAME_(test_case_name, test_name) : public parent_class {\
 public:\
  GTEST_TEST_CLASS_NAME_(test_case_name, test_name)() {}\
 private:\
  virtual void TestBody();\
  static ::testing::TestInfo* const test_info_ GTEST_ATTRIBUTE_UNUSED_;\
  GTEST_DISALLOW_COPY_AND_ASSIGN_(\
      GTEST_TEST_CLASS_NAME_(test_case_name, test_name));\
};\
\
::testing::TestInfo* const GTEST_TEST_CLASS_NAME_(test_case_name, test_name)\
  ::test_info_ =\
    ::testing::internal::MakeAndRegisterTestInfo(\
        #test_case_name, #test_name, NULL, NULL, \
        ::testing::internal::CodeLocation(__FILE__, __LINE__), \
        (parent_id), \
        parent_class::SetUpTestCase, \
        parent_class::TearDownTestCase, \
        new ::testing::internal::TestFactoryImpl<\
            GTEST_TEST_CLASS_NAME_(test_case_name, test_name)>);\
void GTEST_TEST_CLASS_NAME_(test_case_name, test_name)::TestBody()