スノーボール〜ウォーレン・バフェット伝〜を読んだ

書評 金融

伝説的投資家、ウォーレン・バフェットの伝記を読んだ。文庫で上中下の大作。

スノーボール(改訂新版)〔上〕 ウォーレン・バフェット伝 (日経ビジネス人文庫)

スノーボール(改訂新版)〔上〕 ウォーレン・バフェット伝 (日経ビジネス人文庫)

スノーボールというタイトルが付いている。初めはどういう意味かわからなかったが、これは資本が雪だるま式に膨らんでいく様を表しているらしい。Like a Rolling Stone的な趣がある。

恥ずかしながら投資についての知識はからきしだったので、とても長い書籍だったが全ての出来事が新鮮で終始飽きずに読むことが出来た。バフェットはバークシャー・ハサウェイのCEOだったという事実は知っていたが、会社の起こりが紡績事業を行っていた会社だったということは驚きだった。IT銘柄が嫌いな割にはビル・ゲイツと親交が深く、自分の財団の資産をビル・ゲイツ財団に寄付するくだりなどはなるほどという感じだった。

伝記なのでもちろん彼の人間的な部分にも触れられており、特に妻のスーザンが亡くなったシーンは物語のクライマックス的な趣があった。

この著作をきっかけにバリュー投資についての勉強してみようかなと思うようになった。

世紀の空売りを読んだ

書評

マネー・ショートが映画化されて話題だったので原作の方を読んだ。

世紀の空売り―世界経済の破綻に賭けた男たち (文春文庫)

世紀の空売り―世界経済の破綻に賭けた男たち (文春文庫)

金融用語の知識があったほうが映画が楽しめると聞いたので、それならばテキストで楽しんだ方が良いなと思ったので書籍を先に楽しんだ。最近はある程度話題になった金融界隈の文庫を読んでいる（リーマン・ショック・コンフィデンシャル、ウォーレン・バフェット伝の二冊だけだけど）。

リーマン・ショック・コンフィデンシャル(上) (ハヤカワ・ノンフィクション文庫)

リーマン・ショック・コンフィデンシャル(上) (ハヤカワ・ノンフィクション文庫)

金融界隈の物語はそのスケールの大きさが読んでいてSFのように面白いし、今回読んだ本もこれまで読んだ本の登場人物が出てきて点が線になる感じ、スピンオフ作品的な感じが尚更良い。マネーは誰しもにも関わるテーマだし、その延長線上にあのファンタジーのような世界が広がっていると思うと感慨深い。

また、とは言っても現実の世界の話なので、リーマン・ショックとは何だったのか、いかに債券市場が暴走したのか、その中でウォール・ストリートの投資銀行たちはどう立ちまわったのか、サブプライム・ローンとは、モーゲージ債とは、CDOとは、CDSとはなどなどの知識も得られるのでお得な体験になっている。

M・ルイス氏は同様に金融界隈についての著作をいくつか書いているらしい。ライアーズ・ポーカーと迷ったが、次に読む本はブーメランに決めた（リーマン・ショック後の欧州危機について著作）。フラッシュ・ボーイズ（HFTに関する著作）もOmiさんが面白いって言っていたので早く読みたい（しかしまだ文庫になっていない。ハードカバーは買う気にはならないし、Kindle版を買うのもいまいち好きではないというか文庫という形態が好きすぎるので文庫で読みたい）。

ブーメラン 欧州から恐慌が返ってくる (文春文庫)

ブーメラン 欧州から恐慌が返ってくる (文春文庫)

ライアーズ・ポーカー (ハヤカワ・ノンフィクション文庫)

ライアーズ・ポーカー (ハヤカワ・ノンフィクション文庫)

作品の中で好きなシーンは、医師から個人投資家に転身した天才マイケル・バーリが、自分がアスペルガー症候群だったと気づき愕然とするシーンです。

embulkでgithubからpluginをインストールする方法

ビルド(Java)

./gradlew gem

ビルド(Ruby)

rake build

pkgの下にgemファイルができるので、

embulk gem install pkg/xxx.gem

する。

Hadoop / Spark Conference Japan 2016

概要

Hadoop / Spark Conference Japan 2016に参加したチラ裏レポ、感想です。Hadoopカンファレンス初参加でした。途中仕事のメールが入ったためかなり適当にメモったので適当なこと言っていたらすみませんm(__)m

www.eventbrite.com

基調講演

Hadoopを取り巻く環境2016

  • 濱野 賢一朗 （日本Hadoopユーザー会, NTTデータ）
  • Spark Conference 2016初開催！
  • Hadoop10周年！このカンファレンスは6回目、7年目。
  • 去年1299名→今年1347名。今回は63%が初参加。
  • 「Hadoopはひとつのものではなくなった」
  • 昔はHDFSとMRだけだった。どこからどこまでがHadoopかわかりにくくなってきた。
  • 昔のLinuxも同じことを言われてきた。少しずつ修練されていくと思っている。
  • 今どんな変化があるのかを良く知ることが大事。

Hadoopの現在と未来

  • 鯵坂 明（Hadoopコミッタ）、小沢 健史（Hadoopコミッタ）
  • Hadoopとは。コンポーネントは三つある。
  • YARNの現状と未来。リソース管理を汎用化するための手段。
    • YARNがマスタを立ち上げるため。
    • 得意な処理だけをやらせる。
    • バッチ処理ではSQLに似た言語による記述が主流。DSL。
    • バッチ処理とストリーム処理を透過的に扱える様な言語。Flink、GDF。
    • 高水準言語も登場。SystemML、TensorFlow。
    • CPUだけでなくGPGPUやFPGAなどを利用したミドルウェアを利用。
    • YARNはCPU,メモリ、ディスクの処理に焦点を当てていたが、GPGPU、FPGAなどを含む計算リソースを扱えるようになる。
    • データセンターOSとしてのYARN
  • HDFS
    • 安価になったSSDやメモリを活用。異なるストレージの構成に対応。
    • セキュリティ・運用性の向上。アクセス制御。データの暗号化、ローリングアップグレード。適用領域を広げる。
    • Hadoop変更行数ランキング。Hortonworks, Huawel, Cloudera, NTt, Altiscale, Intel, Yahoo, Microsoft, twitter, Salesforce
    • 今後もHadoopをよりよくする活動。メンテナンスリリースの継続。Java8/9対応。新しいハードウェアを意識。開発者を増やしたい。
    • ざっくりYARNユーザーの80%以上がHive, Sparkを使っている。

Yahoo! JAPANのデータプラットフォームの全体像と未来

  • 遠藤 禎士（ヤフー）
  • マルチビックデータカンパニー。
    • Variety。100以上のサービス。
    • Volume。649億PV。8300万ユニークブラウザ。
    • Velocity。一秒間に5万アクセス。
  • 全体像
    • Hadoop。6つのクラスタ。6000ノード。120PB。
    • RDB。MySQL（Percona）560DB。Oracle200。
    • DWH。テラデータ。月間933万件クエリ。
    • ObjectStore。レガシー1500ノード。10PB。Goで作る単価2円。
    • KVS。カサンドラ2000ノード。30クラスタ。1TB。秒間15万。
  • これから
    • SQエンジン。Tezの導入本格化。LDAPも。
    • インメモリ系。HBase、Phoenix。
    • ストレージ。Erasure code。Archival Tier。
    • Spark。サイエンス部隊で、検索データのグラフデータ化に取り組んでいる。
  • Hadoopに関する技術チャレンジ。
    • データ容量が年率四倍になっている。5年後の1024倍は稟議が降りないでしょう（笑）
    • 3000台のHadoopクラスタリソースを8ヶ月で使い切る。
    • 広告レポートのチャレンジ。毎日13億行が追加される。10万クエリ/hour,、年3.3倍している。
    • Hive on Tez。Metastoreがボトルネック。RemoteからLocalへ変更で性能が二倍。
    • リソースマネージャー。アプリケーションマネージャのランチャースレッド数を2倍に。
    • ハートビート数にRMが耐えられなかったので間隔を伸ばした。結果二倍。
    • 他ノードのコンテナ再利用。レプリケーションファクタの増加。ラストアワープロブレム。直近のデータのレプリケーション数を増やした。10万クエリ捌けるようになった。
    • NameNode。同時クエリ数を調整する。上げれば良いものでない。
    • ジョブ終了時にランダムスリープを入れると良い：ジョブが一斉に終わるとログを書き込む処理がボトルネックになる。
  • 今後のYahoo Japanの方向性
    • USEからMAKEへ

Hadoopのストレージの現状と展望

  • Todd Lipcon（Cloudera）
  • HDFSの初期からの開発者。Kudoのリードエンジニア。
  • 「エンジニアだからグラフが好きだ」
  • 2012年からKudo開発。
  • Hadoopには現在800以上のコントリビュータ。コンポネントも2→26へ。
  • Basics 2006-2007。Early adapterだけ。Facebook、Yahoo。
  • Producion 2008-2011。HDFS HA。HBaseがTLPに。：ランダム・アクセス
  • Enterprise 2012-2015。アクセスコントロール。障害復旧。暗号化。SQLonHadoop。HBase1.0。クラウドステレージの対応。
  • Next-Gem 2016-2020 RAMが安くなった。ランダム・アクセスが早くて、アナリティクが早くなるようなストレージとしてのKudo。
  • Prediction。Kudoのエンプラ対応。HDFSが進化していく。クラウドストレージの重要性が増してくる。

Spark Conference Japanの開催にあたって

  • 猿田 浩輔（Apache Sparkコミッタ）
  • Spark熱が高まっている。
  • 55%以上の人がSparkSQL, Dataframe。MLlibやStreamingも40％に近い結果に。

Spark 2.0: What's Next

  • Reynold Xin（Databricks）
  • SparkのPMCでTangsutenプロジェクトのリーダー。
  • speed, ease of use, sophisticated analytics。オープンソースデータ処理エンジン。
  • 2015は1000のコントリビュータ。R。幅広い業界に採用。
  • environment, standalone48%, yaron40%, mesos11%, public cloud51%
  • BI, DWH, Recommendation、ログ処理、ユーザー向けサービス、不正検出などに使われる。
  • Spark2.0
    • Frontend、RDD, DF, ML。 Streaming, df, SQL
    • Backend, schedular, shuffle, operator。x10performance, Codegenベクトル化。
    • DataframeAPIはLogicalplanが挟まる（Catalyst Optimizer）すると各クライアントがその層を使える。
    • その先はJVMだけだったが、Tungstenが加わる。
  • API Foundation in Spark 2.0はどうなるか。Steraming、DataFrameの成熟。ANSI SQL。
  • ストリーム処理が難しい理由は、長期間のアウトプット、遅延処理、障害、分散。これが複雑なオペレーションにわたって機能しないといけない。
  • SQL/DF performanceが10倍になる。
  • Spark2.0は4、5月にリリース
  • [余談] Fortuneのこの記事を日本ローカライズしたネタ笑った。北川景子をXin氏に伝えたの誰だったんだろ。

Spark as a 北川景子

A photo posted by satoshihirose (@satoshihirose) on

さくらインターネットが構築した、Apache Sparkによる原価計算システム

  • 須藤 武文（さくらインターネット）
  • 規模を追求する「持つ経営」なので、資産が増加していく。
  • どのくらいコストが掛かっているのか。を知りたい。
  • これまでの方法は。手作業に時間がかかる。十分なデータ収集が出来ない。コスト計算の明確なルールが整備不足だった。
  • 原価計算の精緻化・迅速化。データ整備と社員の意識向上。分散処理基盤の構築・運用に関する知見を溜める。
  • データ量は300GB/day。
  • 物理サーバーは30台。総メモリ量は1.6TB。アドホックに増設している。利便性が高くて良い。

各論

YARN: Resource Manager for Analytic Platform

  • 小沢 健史（NTT）
  • YARNの機能
    • 計算機クラスタ内におけるリソース管理
    • YARNアプリケーション実行履歴
    • 動作中のサービスの場所を知るための仕組み
  • なぜYARNを使うのか。
    • データ分析基盤を使い分けたい場合がある。
    • その場合の対応方法
      • クラスタを分ける（管理が複雑）
      • 処理基盤を同居する（計算リソースの分離が困難）
    • YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想
    • 処理系のマスタをジョブ毎に立ち上げられる（Yahoo Incの要望で導入とのこと）
      • これまではJobトラッカーが死活監視していたのがボトルネックになることがあった。それを負荷分散するため。
  • リソースマネジャー。マスタがクラスタ全体のリソースを管理。
  • ノードマネージャー。スレーブが計算機毎のコンテナを管理。
  • 課題：割り当てられたコンテナのリソースが全て使い切れているとは限らない。
  • 実行履歴の管理。パフォーマンス・チューニング。
  • TimelineServer。アプリケーション固有の情報を利用することでリッチな性能解析が可能。例：TezUI
  • ServiceRegistory。ある意味サービスディスカバリー。HivemallのMixServerみたいな用途。
  • YARN上におけるMR派生の並列分散処理基盤。
    • Spark, Tez(Hiveの下で動く）、Flink。汎用的で非循環有向グラフ（DAG）
    • MapMapReduceみたいな感じでジョブの数を減らせる。シャッフルが増えると並列性が行かせない。
    • Tezは、HivePigといった高水準言語を前提に、シャッフル時のソートがないようなDAGを記述することが可能。
  • コンテナの再利用で、コンテナの立ち上げ時間を減らせる。
    • MapReduceにあったContainerReuseとの差は？実装がなくなっていた。セッションにより、リソースを再利用することが出来るようになった。
    • LLAP。Long Lived and Process。立ち上げっぱなしのコンテナ。ふつうのDBとやっていることと同じ。余ってるリソースをYARNから継ぎ足せるのが良い。
    • Spark上におけるYARNでもコンテナ再利用相当の機能は実装済。逆にコンテナが終了できない。リソースの利用率が低下する。動的リソース管理。

KuduによるHadoopのトランザクションアクセスと分析パフォーマンスのトレードオフ解消

  • Todd Lipcon（Cloudera）
  • Why Kudo?
    • TimeSeries。ファイナンシャルマーケット。
    • Online reporting
    • Xiaomiのユースケース。100億/day
      • Kafka->Storm->Kudo
      • table is horizontally partitioned into tablets. replicas 3 or 5 , Raft consensus. fault tolerance 5 seconds.
    • don't need ZK or some module.
  • How to work.
    • カラムなストレージ。
    • データはテーブルに格納する。

Project Tungsten. Bringing Spark Closer to Bare Metal

  • Reynold Xin（Databricks）
  • 独自のメモリ管理でJVMのオーバヘッド（空間的、GC）を克服する。（四文字のストリングも48バイトになってしまう）
  • Janinoコンパイラを使用して、コードの生成時間を減らした。
  • アルファソート。キャッシュフレンドリーなソート。プレフィックスを付けることで、短絡化する。
  • Spark as a Compilerの話。複雑なIOはコンパイル出来ない。

感想

  • Spark、HadoopやKuduのCommiter氏各位の話、分散処理基礎に始まり機能紹介やらコミュニティ今昔やら比較やらが聞けるのでとてもためになる。
  • 濱野氏が最初の挨拶で言っていたようにまだまだHadoopコンポーネントは発展していくのだろうし、開発者が良い判断することは暫くは難しいままだろう。
  • Maintainable Cloud Architecture of Hadoop聞きたかった😣
  • データドリブン企業における、Hadoop基盤とETL ～niconicoでの実践例～も聞きたかった😣
  • DynamoDBの話がどこかでされていたようで、聞きたかった😣

現在の弊社にどう活かせるか

  • 弊社のような小規模な開発チームでは、楽になったとはいえまだ自前でHadoopクラスタを運用するコストを割くことが出来ないなとは思う。
    • そういう意味でTodd Lipcon氏が言っていたようにクラウドストレージの需要はますます高まってくるのは間違いない（Clouderaはプラットフォーム作ってくれないのかしら）（ユーザーの半分はクラウドストレージを使っているって言ってたのTodd氏だっけ？Xin氏だっけ？）
    • もしくは、KuduのようにZKやHDFSに依存しない道や、TDのようにS3にストレージ任せてしまうって道もあるっぽい（トーク聞いていないけどどうやらそんな話をしていたらしい）
  • こう言う意見も全然わかる。
  • 「YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想」みたいなものがデータ処理をスケールさせるためには必要であって、そのためにはストレージを中心にデータ処理周りのコンポーネントの開発が活発なHadoopエコシステムにbetするのは長期的に見て間違いない（別にストレージはAWSとかGoogleとかでも良いんだけど）
  • Sparkはもちろん銀の弾丸って訳ではないのでって当たり障りのない話になってしまうのだけれど、課題に対してメリット（自分でスケールする分散処理の仕組みを用意するより楽）やデメリット（学習コスト運用コストが増える、cronとかダサい）とかを鑑みて最終的な判断する必要がある。

ScalaMatsuri 2016

概要

ScalaMatsuri 2016に参加した感想です。

scalamatsuri.org

DAY 1

Refactoring in Scala

  • Tagged Type便利そう。
  • IsoやPrismの概念、関数型っぽい。
  • 確かにLong型よりもUserId型(Value Type)を定義すると分かりやすかったりbugの埋め込みを減らせる気もするけれども、それが原因でDBとの境界に気を使ってコード量を増やしたりパフォーマンスに気を使ったする箇所を増やしたりするのトレードオフだなって感じだった。

なぜリアクティブは重要か

  • okapiesさんのスライドわかりやすい。
  • Reactiveなシステムって文脈をProgramming model, Runtime Engine, Architectureに分けて説明したの良かった。
  • Reactiveなシステムの設計の概要とそこにおけるApache Dataflowのポジションがクリアーになったのが良かった。これから標準化がどう進むのか見ものだ。
  • 分散処理系はまだまだ発展の余地があってとても話を聞いていて楽しい。
  • WebサービスのオーケストレーションにもReactiveなシステムの適応余地があるのでは？って話の詳細聞こうと思っていたけど忘れてた。
  • この発表聞いていたおかげでTypesafeメンバーのパネルディスカッションの話も分かりやすくなったと思う。

猫という考え方

  • トークの最初にHardとSoftの話半分くらいしますと言っていたように、環境を含めたCatsの概要を理解するのに良かった。
  • 「softwareは真空状態にあるものではない」
  • Scalaで関数型で行うための障壁を取り除くのがCatsの目標。それは技術的な複雑さ、職場で未知への恐怖、社会的な障壁。 長期的で協力的なコミュニティを促進していく。
  • スライド中に猫が箱に頭突っ込んでいる画像が頻出するのウケた。
  • 最初に聞いたとき、型を指定しないことで実装が制限させるところがよくわからなかった。
  • Constraints Liberate, Liberties Constrainが印象的。制限と自由の話、Typesafeの人が好んで使っていた。

バッチを Akka Streams で再実装したら100倍速くなった話

  • TISとTypesafeの関係知らなかった。
  • レガシーなバッチ処理をAkka Streamsで置き換えたら295倍になったとのこと。
  • これ別にAkka Streamsじゃなくても100倍とかにはなっていたんじゃないかという気はするけれどまあご愛嬌。

ScalaコードはJVMでどのように表現されているのか

  • javapの話。
  • バイトコード読んだ経験特になかったのでまあ勉強になった。
  • こんな使い方するとのこと。他にどんなとき読みたくなるんだろうか。パフォーマンスとか気にするとき？

レジリエンスが無ければ、他は無いも同じ

  • TypesafeのCTOのトークが今回一番印象深かった。システム論っぽい感じ。思想的。
  • ドメイン知識がシステムそのものなんだろうなって感じ。
  • レジリエンスは設計方針。
  • Actorとベンディングマシーンの例わかりやすかった。（よく使われる例なのだろうか？）
  • 造船時の防水隔壁パターンの話。タイタニックは障害のカスケーディングの典型例。事故の原因は故障した部品ではなく、部品どうしの関係性にある。
  • システムのレジリエンスをどうやって実現するかって話。actorごとにboundaryを設けて、障害の伝搬を防ぐ。threadでもmachineでも良い。
  • トークの最初と最後にロッキーのテーマを流してたけど好きなのかな。

The Zen of Akka

  • Zen。味があるトークだった。
  • Akkaのロゴを山水画の山に透過させて描いていたのウケたんだけど、ロゴの由来だったりするの？？？
  • Actorは1つの責務に特化させるべし。他と強調して動くべし。
  • Errorはビジネスロジックの問題。Failureはインフラの問題。
  • Akka Clusterの話も一般的な問題の話っぽくて面白かった。
  • AkkaはFrameworkではなくToolkit。適切に使え。
  • Constraints Liberate, Liberties Constrain（制限は私達を自由にする。自由は私達を制限する）
    • 元ネタ
  • Happy HAkking, Community!

DAY 2

Kafka Tuning

  • ドワンゴの社内マイクロサービス基盤？ではAt Least Once。Exactory Onceや順序保証はなし。
  • RabbitMQやめた理由。そこまでスケールを意識していない設計になっている？
  • 既存のクライアント(Reactive-kafkaとか)は要件を満たさず使っていない。
  • 通信は独自のバイナリプロトコル。httpアダプタを自作。既存のhttpアダプタは無いの？コンフルエントが出しているけれど、機能少ないという判断で使うの辞めた。
  • kafka 0.8当時consumerのjarが作りかけなのにmaven centralにpublishされていた…？（ガクブル）
  • コードの辛みと運用の設定値チューニングの辛み。ブログとかMLとか読み込んだとのこと。
  • 最後の質問でクラウドサービスは検討しなかったの？って聞いたら、オンプレあるししなかったって言われた。ですよね。

Scalaz入門

リアクティブシステム入門

  • 昨日のJonas氏のトークを日本語で要約した感じ。Reactive Platformのコンポーネントのその中での役割をちょっと具体的に説明している。
  • デモ。ソーラーファームを運営しているお客様。一万枚のパネルの発電状況をモニタ。故障検知。1msも無駄にしたくない。リアルタイムで。MQTT, Akka, Play, WebSocket。
  • TISはSIでもTypesafe Reactive Platformを適用出来ないか頑張っているとのこと。すばらし。

Typesafeの人にリアクティブについて聞こう/Reactive adoption with Typesafe members

  • Typesafeの四人が登壇して、質問に答える形式。
  • 質問：金融とかクリティカルなとこではどうなの？
  • 質問：GoogleもDataflowとか標準化しようとしているけれどどう戦ってくの？
  • okapiesさんのReactive Streamに関する質問とスライド使ったファシリテーション素晴らしかった。
  • これ期待
  • 録画見てちゃんと理解したい。

Scala.js コンパイル・パイプライン

  • どうやってScalaのコードをJSに理解させるコードに置き換えているかの講義だった。
  • 後半はよくわからなかった。
  • 同じ感想。いきいきと話す人だった。

パネルディスカッション：Scala社内教育

  • Scalaは色んなレベルの人が色々な書き方が出来るので、その人の背景とかレベルに応じた教育方針がそれぞれあって面白かった。
  • 一日目にドワンゴの新人研修資料が公開された。
  • hatenaの新人研修資料は最初の年に海外の秋採用の新人を使ってdebugしたとのこと。 github.com

大学教育とScala

Scala 転職・年収

  • 各社の年収状況

全体の感想とまとめ

Typesafe

  • Typesafeの方々のトークを直に聞けたのがとても良かった。
  • またeed3si9nさんにTypesafeの概要とかの話を聞けたのも良かった。

運営

  • 一日目の最初に技術カンファレンスの行動規範についてののビデオが流れたけれどもとても良く出来ていた。
  • スライドの日英対訳、同時通訳とても素晴らしかった。
  • 国際化対応や行動規範、投票制のトーク選定、アンカンファレンスなどから垣間見れる運営のScalaコミュニティを尊重している態度とても良いなあって思った。
  • とても有意義な二日間になりました。関係者の方々、本当にお疲れ様でした。ありがとうございました。

2015年に飲んだビールまとめ

一年でビール何銘柄程度飲めるか

二年位前からビールが好きになったので、去年は100銘柄ビールを飲もうという目標を立てました。

年始は張り切って人を誘ってビアバー巡ってましたが、年の後半はお金も使いたくないので食事誘われたらビアバーを提案するくらいのペースに落としました。 ビールが好きだと言っているとお誘いやお土産の引き合いがあってそれはそれで楽しい一年でした。

以下の一覧では写し疲れたので100で辞めましたが、記録していない銘柄もあるのでだいたいユニーク銘柄数は120-130位でしょうか。 銘柄被りや居酒屋で飲む日本のラガーを合わせれば3倍くらい飲んでそうなので、一杯平均して350mlだとすると大体100Lくらい飲んだ計算になるでしょうか。 ちなみに東京人の平均ビール消費量は35L程度だそうです。

1人あたりのビールの消費量の都道府県ランキング - 都道府県格付研究所

美味しかったビール

初めにビールを好きになった頃はホワイトビールが好きでした。特にハーブ感が強いエーデルワイスをよく飲んでいました。

安っ！って思ったけど+開栓料

A photo posted by satoshihirose (@satoshihirose) on

この企画を始めた頃はIPAが好きでした。DirtWolfのDouble IPAが香り高くて良かったなと印象に残っています

dirtwolf

A photo posted by satoshihirose (@satoshihirose) on

途中からポーターが好きになりました。開栓直後の反射炉ビアポーターは感動的な美味しさでした。

#67 反射炉ビア ポーター

A photo posted by satoshihirose (@satoshihirose) on

また最近は大麦と小麦を混ぜたビールの味がとても美味しく感じたので探っていきたいなと感じています。

#25 フランツェスカーナヴァイスドュンケル

A photo posted by satoshihirose (@satoshihirose) on

ビールの美味しさはその時の体調や気分や開栓からの期間だったりに左右されてしまうので、体験の質を上げるのもまた良いと思います。 うすはりグラスでよく冷えたビールを飲んだり、

京都岡山街道麦酒ケルシュ #22

A photo posted by satoshihirose (@satoshihirose) on

桜を見ながら外でビールを呑んだり

昼から桜を観ながら贅沢している。

A photo posted by satoshihirose (@satoshihirose) on

#30 EFES Dark

A photo posted by satoshihirose (@satoshihirose) on

好きな女の子とビールを飲んだりですね。 2016年も楽しんでいきましょう。

印象に残っているビアバー

tabelog.com

訪れたのは一昨年なのですが、とても印象に残っています。たぶんデートには使えません。

映画配給会社の店舗の一角を使った飲食店とは思えない狭い店内。 映画配給で日本行脚するツテで、日本の地方ブリュワリーからビールを仕入れてお店にしているという変わった出自のお店。 そのオーナー？の方がずっと日本のビール醸造の今昔話をしてくれてとても興味深かった記憶があります。

今はどうなっているかわかりません。

2015年飲んだビール銘柄一覧

  • レフ・ブロンド
  • レフ・ブラウン
  • ティママン・ブランシェのランビックホワイト
  • オーストリアエーデルワイス
  • ウェストマール・トリプル
  • ステラアルトワのラガー
  • キルケニーのレッドエール
  • ベアードビール修善寺ヘリテッジヘレス
  • ベアードビールシングルテイクセッションエール
  • ベアードビールスルガベイインペリアルIPA
  • 栃木プレストンエールのIPA
  • 栃木プレストンエールのブラウンエール
  • 北海道フルーツブルーイング チェリー＆ベリー
  • BREWDOG BREWERYのパンクIPA
  • 北海道ノースアイランドビールのヴァイツェン
  • 北海道ノースアイランドビールのコリアンダーブラック
  • アサヒレーベンブロイ
  • サッポロ月夜のデュンケル
  • サッポロ那須の森ビールデュンケル
  • カールスバーグ
  • ハートランド
  • Dreher
  • 長野諏訪浪漫
  • 長野善光寺浪漫
  • 長野安曇野浪漫
  • 日本ビール有機農法ビール
  • ブルマーブルーイングのゴールデンエール
  • ブリマーブルーイングのバーレーワイン
  • 軽井沢浅間高原ビールクリア
  • 京都岡山街道麦酒ケルシュ
  • シュパーテンのオクトーバーフェストビア
  • フランツェスカーナのヘフェヴァイスビア
  • フランツェスカーナのヴァイスドュンケル
  • フレンスブルガーのヴァイス
  • TECATE
  • オリオンのシークワーサービール
  • ピッツァポートブリューイングポントセッショナブルIPA
  • イギリスFuller's Organic Honey Dew
  • オーストラリアVictoriaBitter
  • スペインエストレージャガリシア
  • 那須高原地ビールヴァイツェン
  • 八海山泉ビールIPA
  • サンクトガーレンのロンドンコーリングIPA
  • イギリスアボットエール
  • YONAYONAのTOKYO BLACK
  • YONAYONAのインドの青鬼
  • YONAYONAの僕ビール君ビール
  • YONAYONAの東京ピクニック
  • 伊勢角屋ブラウンエール
  • 伊勢角屋スタウト
  • 伊勢角屋ペールエール
  • ガッフェルのケルシュ
  • ツムユーリゲのアルトビール
  • 栃木うしとらブルワリーIPA
  • 栃木うしとらブルワリー赤苦
  • あくらICウィンドセッションIPL
  • しもつまビールヴァイツェン
  • サントリーラドラー
  • SOCブルーイングのハスカップブロンド
  • 常陸野ネストだいだいIPA
  • 常陸野ネスト塩梅
  • 常陸野ネストジャパニーズクラシックエール
  • Victory BrewingのHeadwaters Pale Ale
  • Victory BrewingのStorm King Stout
  • みちのく福島路ビール黄金桃のリッチエール
  • みちのく福島路ビールピーチエール
  • 馨和のRouge
  • Wolf 8
  • Mad River BrewingのCompany Steelhead
  • 日本ビールレモンビール
  • 伊豆韮山ビール反射炉ビヤポーター
  • メキシコデイ・オブ・ザ・デッドIPA
  • Bisonオーガニックビールのハニーバジル
  • リーフマンスのオン・ザ・ロック
  • 舞浜ハーヴェストムーンサマーバケーションエール
  • 志賀高原ビールインディアンサマーセゾン
  • Samuel AdamsのStony Brook Red
  • スペインイネディット
  • ハーベストの丘 こだわりやさかい ライラガー
  • 群馬吾つま恋し麦の酒のエール
  • サッポロエーデルピルス
  • SPRING VALLEY BREWERYの496×Galaxy Hop
  • 田沢湖ビールアルト
  • Gigantic BrewingのCider Riot!
  • いわて蔵ビール金蔵
  • 小樽麦酒アンバーエール
  • 銀河高原のペールエール
  • 石川グランアグリ
  • オーストラリアンブルワリーTHE PALE ALE
  • Bear BeerのDark Weat
  • サントリーThe Pumpkin
  • サッポロCraft Label 柑橘香るペールエール
  • キリン取手作り
  • キリンGALAXY HOP
  • BIG WAVE
  • ヒューガルデンのロゼ
  • イタリアムンダカペールエール
  • Houblon Chouffe Dobbelen IPA Tripel
  • T.Y HARBOR BREWINGのスタウト
  • T.Y HARBOR BREWINGのIPA

2015年振り返りと2016年目標

2015年の振り返り

自己組織化するシステムを作る

  • ルールベースのプリミティブなものでしかないけど、まあ可。今後Breakdownしてやっていくかは微妙。
  • 機械学習を使った仕組みは導入できていないけれど、一年やってみてまあそういう段階まではもうちょっとだなって認識になっている。

データストアの勉強をする

  • AWS(SQS, RDS, ElastiCache、DynamoDB)、Redis、MongoDB、HBaseとか試したり使ったりしていたので可。
  • DynamoDBに触れて、もっと分散処理周りの勉強したいなと思えた。
  • あとSQS便利だけどいくつか不便な仕様も見えてきてKafka導入考えたいなと思った。

システムを止めない

  • サービスイン時の失敗があったりしたので、不可。やっぱり余裕がなくなると視野が狭くなってダメね。
  • その他大きな障害は無いが、システムテストが不十分だったり書きやすいコードになってなかったりするのはダメな感じ。

ブランドに対する知見、人が興味を抱くきっかけについて知見を溜める

  • 取り組まなかった。必要無い。

ビール100銘柄、新規ビアバー10店舗

  • これはいい感じの数値的目標だったので、無理せず達成出来た。楽しかったし人と交流するツールにもなったし、ビールに対する知見も溜まった。また後で2015年飲んだ銘柄まとめる。

その他

  • 生活にKindleを導入し始めたが、Webに転がっているpdf取り込んで手軽に読めるとか重宝している。頭から順に読んでいくような読み方にはfitするけど、zappingして気になるチャプターだけ読むような読み方には向いていないなという感じ。UIの改善頼む。

2016年の目標

英語を使いこなせるようになる

  • 昔から英語コミュニケーションが苦手であることがコンプレックスになっている気はしていたのだが、解消しといた方が良いんじゃないかと思い始めた。
  • 日常的にPodcast聴くとかCourseraを受講するとかはし始めた。
  • 定性的目標は、エンジニアとしてビジネスユースで使えるレベルまで鍛える。
  • 定量的目標は、TOEFLでいい感じの点数を取るって感じにしておいてもいいかもしれない。
  • これとか気になっている。 表参道から徒歩5分！英会話を学ぶならCLUB CUE英会話ラウンジ | 株式会社CUE

OSSへのcommit

  • 出来るか分からないけど一応意識しておきたい。

年収

  • 3年後に800万って煽られたので考えていく。

人生の進捗を出す

  • 2015年はありませんでした。2016年は何かしら成果を出したい。