スノーボール〜ウォーレン・バフェット伝〜を読んだ
伝説的投資家、ウォーレン・バフェットの伝記を読んだ。文庫で上中下の大作。
スノーボール(改訂新版)〔上〕 ウォーレン・バフェット伝 (日経ビジネス人文庫)
- 作者: アリス・シュローダー,伏見威蕃
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2014/06/03
- メディア: 文庫
- この商品を含むブログ (2件) を見る
スノーボールというタイトルが付いている。初めはどういう意味かわからなかったが、これは資本が雪だるま式に膨らんでいく様を表しているらしい。Like a Rolling Stone的な趣がある。
恥ずかしながら投資についての知識はからきしだったので、とても長い書籍だったが全ての出来事が新鮮で終始飽きずに読むことが出来た。バフェットはバークシャー・ハサウェイのCEOだったという事実は知っていたが、会社の起こりが紡績事業を行っていた会社だったということは驚きだった。IT銘柄が嫌いな割にはビル・ゲイツと親交が深く、自分の財団の資産をビル・ゲイツ財団に寄付するくだりなどはなるほどという感じだった。
伝記なのでもちろん彼の人間的な部分にも触れられており、特に妻のスーザンが亡くなったシーンは物語のクライマックス的な趣があった。
この著作をきっかけにバリュー投資についての勉強してみようかなと思うようになった。
世紀の空売りを読んだ
マネー・ショートが映画化されて話題だったので原作の方を読んだ。
- 作者: マイケル・ルイス,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2013/03/08
- メディア: 文庫
- 購入: 1人 クリック: 30回
- この商品を含むブログ (20件) を見る
金融用語の知識があったほうが映画が楽しめると聞いたので、それならばテキストで楽しんだ方が良いなと思ったので書籍を先に楽しんだ。最近はある程度話題になった金融界隈の文庫を読んでいる(リーマン・ショック・コンフィデンシャル、ウォーレン・バフェット伝の二冊だけだけど)。
リーマン・ショック・コンフィデンシャル(上) (ハヤカワ・ノンフィクション文庫)
- 作者: アンドリュー・ロスソーキン,Andrew Ross Sorkin,加賀山卓朗
- 出版社/メーカー: 早川書房
- 発売日: 2014/02/07
- メディア: 文庫
- この商品を含むブログ (6件) を見る
金融界隈の物語はそのスケールの大きさが読んでいてSFのように面白いし、今回読んだ本もこれまで読んだ本の登場人物が出てきて点が線になる感じ、スピンオフ作品的な感じが尚更良い。マネーは誰しもにも関わるテーマだし、その延長線上にあのファンタジーのような世界が広がっていると思うと感慨深い。
また、とは言っても現実の世界の話なので、リーマン・ショックとは何だったのか、いかに債券市場が暴走したのか、その中でウォール・ストリートの投資銀行たちはどう立ちまわったのか、サブプライム・ローンとは、モーゲージ債とは、CDOとは、CDSとはなどなどの知識も得られるのでお得な体験になっている。
M・ルイス氏は同様に金融界隈についての著作をいくつか書いているらしい。ライアーズ・ポーカーと迷ったが、次に読む本はブーメランに決めた(リーマン・ショック後の欧州危機について著作)。フラッシュ・ボーイズ(HFTに関する著作)もOmiさんが面白いって言っていたので早く読みたい(しかしまだ文庫になっていない。ハードカバーは買う気にはならないし、Kindle版を買うのもいまいち好きではないというか文庫という形態が好きすぎるので文庫で読みたい)。
- 作者: マイケルルイス,Michael Lewis,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2014/09/02
- メディア: 文庫
- この商品を含むブログ (4件) を見る
- 作者: マイケルルイス,Michael Lewis,東江一紀
- 出版社/メーカー: 早川書房
- 発売日: 2013/10/04
- メディア: 新書
- この商品を含むブログ (6件) を見る
作品の中で好きなシーンは、医師から個人投資家に転身した天才マイケル・バーリが、自分がアスペルガー症候群だったと気づき愕然とするシーンです。
embulkでgithubからpluginをインストールする方法
ビルド(Java)
./gradlew gem
ビルド(Ruby)
rake build
pkgの下にgemファイルができるので、
embulk gem install pkg/xxx.gem
する。
@satoshihirose こんにちは、git cloneして、javaなら./gradlew gem ; rubyならrake buildです。pkgの下にgemファイルができるので、embulk gem install pkg/xxx.gemとすれば良いです。
— hiroyuki sato (@hiroysato) April 22, 2016
@hiroysato @satoshihirose 手前味噌ですが、 https://t.co/9qDNGlNQ0O という方法もあります。
— joker1007に宜しく (@joker1007) April 22, 2016
Hadoop / Spark Conference Japan 2016
概要
Hadoop / Spark Conference Japan 2016に参加したチラ裏レポ、感想です。Hadoopカンファレンス初参加でした。途中仕事のメールが入ったためかなり適当にメモったので適当なこと言っていたらすみませんm(__)m
基調講演
Hadoopを取り巻く環境2016
- 濱野 賢一朗 (日本Hadoopユーザー会, NTTデータ)
- Spark Conference 2016初開催!
- Hadoop10周年!このカンファレンスは6回目、7年目。
- 去年1299名→今年1347名。今回は63%が初参加。
- 「Hadoopはひとつのものではなくなった」
- 昔はHDFSとMRだけだった。どこからどこまでがHadoopかわかりにくくなってきた。
- 昔のLinuxも同じことを言われてきた。少しずつ修練されていくと思っている。
- 今どんな変化があるのかを良く知ることが大事。
Hadoopの現在と未来
Yahoo! JAPANのデータプラットフォームの全体像と未来
- 遠藤 禎士(ヤフー)
- マルチビックデータカンパニー。
- Variety。100以上のサービス。
- Volume。649億PV。8300万ユニークブラウザ。
- Velocity。一秒間に5万アクセス。
- 全体像
- これから
- 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
- API Foundation in Spark 2.0はどうなるか。Steraming、DataFrameの成熟。ANSI SQL。
- ストリーム処理が難しい理由は、長期間のアウトプット、遅延処理、障害、分散。これが複雑なオペレーションにわたって機能しないといけない。
- SQL/DF performanceが10倍になる。
- Spark2.0は4、5月にリリース
- [余談] Fortuneのこの記事を日本ローカライズしたネタ笑った。北川景子をXin氏に伝えたの誰だったんだろ。
さくらインターネットが構築した、Apache Sparkによる原価計算システム
- 須藤 武文(さくらインターネット)
- 規模を追求する「持つ経営」なので、資産が増加していく。
- どのくらいコストが掛かっているのか。を知りたい。
- これまでの方法は。手作業に時間がかかる。十分なデータ収集が出来ない。コスト計算の明確なルールが整備不足だった。
- 原価計算の精緻化・迅速化。データ整備と社員の意識向上。分散処理基盤の構築・運用に関する知見を溜める。
- データ量は300GB/day。
- 物理サーバーは30台。総メモリ量は1.6TB。アドホックに増設している。利便性が高くて良い。
各論
YARN: Resource Manager for Analytic Platform
- 小沢 健史(NTT)
- YARNの機能
- 計算機クラスタ内におけるリソース管理
- YARNアプリケーション実行履歴
- 動作中のサービスの場所を知るための仕組み
- なぜYARNを使うのか。
- リソースマネジャー。マスタがクラスタ全体のリソースを管理。
- ノードマネージャー。スレーブが計算機毎のコンテナを管理。
- 課題:割り当てられたコンテナのリソースが全て使い切れているとは限らない。
- 実行履歴の管理。パフォーマンス・チューニング。
- TimelineServer。アプリケーション固有の情報を利用することでリッチな性能解析が可能。例:TezUI
- ServiceRegistory。ある意味サービスディスカバリー。HivemallのMixServerみたいな用途。
- YARN上におけるMR派生の並列分散処理基盤。
- Spark, Tez(Hiveの下で動く)、Flink。汎用的で非循環有向グラフ(DAG)
- MapMapReduceみたいな感じでジョブの数を減らせる。シャッフルが増えると並列性が行かせない。
- Tezは、HivePigといった高水準言語を前提に、シャッフル時のソートがないようなDAGを記述することが可能。
- コンテナの再利用で、コンテナの立ち上げ時間を減らせる。
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の話がどこかでされていたようで、聞きたかった😣
現在の弊社にどう活かせるか
S3/Riak上にPlazmaDBを構築して、そこにデータを貯める。HDFSなどをデータ置き場に使わないことで、運用負荷を下げて、更新しやすくなる #hcj2016
— Mr. Fiber (@repeatedly) February 8, 2016
- こう言う意見も全然わかる。
でも、SQLならBigQueryでいいような気もするけど。
— Kazunori Sato (@kazunori_279) 2016, 2月 8
- 「YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想」みたいなものがデータ処理をスケールさせるためには必要であって、そのためにはストレージを中心にデータ処理周りのコンポーネントの開発が活発なHadoopエコシステムにbetするのは長期的に見て間違いない(別にストレージはAWSとかGoogleとかでも良いんだけど)
- Sparkはもちろん銀の弾丸って訳ではないのでって当たり障りのない話になってしまうのだけれど、課題に対してメリット(自分でスケールする分散処理の仕組みを用意するより楽)やデメリット(学習コスト運用コストが増える、cronとかダサい)とかを鑑みて最終的な判断する必要がある。
ScalaMatsuri 2016
概要
ScalaMatsuri 2016に参加した感想です。
DAY 1
Refactoring in Scala
僕のスライドこちらです。スクリーンが見づらい場合はお手元でご確認ください https://t.co/MtTi7m7DE5 #ScalaMatsuri #sm_a
— がくぞ (@gakuzzzz) January 30, 2016
- Tagged Type便利そう。
- IsoやPrismの概念、関数型っぽい。
- 確かにLong型よりもUserId型(Value Type)を定義すると分かりやすかったりbugの埋め込みを減らせる気もするけれども、それが原因でDBとの境界に気を使ってコード量を増やしたりパフォーマンスに気を使ったする箇所を増やしたりするのトレードオフだなって感じだった。
なぜリアクティブは重要か
本日の資料です。毎度ながら詰め込み過ぎなのでバンバン流していきます…。ぜひお手元で見ながらお聞き下さい。 https://t.co/anE0sH8mFc #ScalaMatsuri #sm_a
— Yuta Okamoto (@okapies) January 30, 2016
- okapiesさんのスライドわかりやすい。
- Reactiveなシステムって文脈をProgramming model, Runtime Engine, Architectureに分けて説明したの良かった。
- Reactiveなシステムの設計の概要とそこにおけるApache Dataflowのポジションがクリアーになったのが良かった。これから標準化がどう進むのか見ものだ。
- 分散処理系はまだまだ発展の余地があってとても話を聞いていて楽しい。
- WebサービスのオーケストレーションにもReactiveなシステムの適応余地があるのでは?って話の詳細聞こうと思っていたけど忘れてた。
- この発表聞いていたおかげでTypesafeメンバーのパネルディスカッションの話も分かりやすくなったと思う。
猫という考え方
「猫という考え方」 の発表資料です #ScalaMatsuri #sm_c - https://t.co/LWC5f6Xhqq
— eugene yokota (@eed3si9n_ja) January 30, 2016
- トークの最初にHardとSoftの話半分くらいしますと言っていたように、環境を含めたCatsの概要を理解するのに良かった。
- 「softwareは真空状態にあるものではない」
- Scalaで関数型で行うための障壁を取り除くのがCatsの目標。それは技術的な複雑さ、職場で未知への恐怖、社会的な障壁。 長期的で協力的なコミュニティを促進していく。
- スライド中に猫が箱に頭突っ込んでいる画像が頻出するのウケた。
- 最初に聞いたとき、型を指定しないことで実装が制限させるところがよくわからなかった。
@satoshihirose Intには値があるから値を元に分岐できるけど、値がなければ分岐できないのです。(関数型としてはキャストは考えないので、型がわからないと同じ型を返す実装はそのまま返すしかないです。)
— かず(原材料に小麦粉を含む) (@kazzna) January 30, 2016
- Constraints Liberate, Liberties Constrainが印象的。制限と自由の話、Typesafeの人が好んで使っていた。
バッチを Akka Streams で再実装したら100倍速くなった話
13:40〜の講演資料はこちらです! | バッチを Akka Streams で再実装したら100倍速くなった話 https://t.co/Dc9VPKXWF1 #ScalaMatsuri #sm_a
— Negoro Kazuki (@negokaz) January 30, 2016
- TISとTypesafeの関係知らなかった。
- レガシーなバッチ処理をAkka Streamsで置き換えたら295倍になったとのこと。
- これ別にAkka Streamsじゃなくても100倍とかにはなっていたんじゃないかという気はするけれどまあご愛嬌。
ScalaコードはJVMでどのように表現されているのか
#ScalaMatsuri 2016 1/30(土) 14:30 - 14:45 「ScalaコードはJVMでどのように表現されているのか」で使用したスライドを公開しました!https://t.co/yJvz4EhAqF
— じゅくちょー Koichi Sakata (@jyukutyo) 2016, 1月 30
- javapの話。
- バイトコード読んだ経験特になかったのでまあ勉強になった。
- こんな使い方するとのこと。他にどんなとき読みたくなるんだろうか。パフォーマンスとか気にするとき?
Scala使いは皆、javapにも習熟するものと思っていたけど違うようだ。例えばSparkのnon-serializable系のエラーの解決には、javapでコード確認して$outerに紛れ込んでいるオブジェクトを見つけるなどが必要 #ScalaMatsuri
— Taro L. Saito (@taroleo) January 30, 2016
レジリエンスが無ければ、他は無いも同じ
Here is the full 1 h version of my #ScalaMatsuri talk today (without translation) /cc @momotas210 https://t.co/NRbrKXVjuM
— Jonas Bonér (@jboner) January 30, 2016
- TypesafeのCTOのトークが今回一番印象深かった。システム論っぽい感じ。思想的。
- ドメイン知識がシステムそのものなんだろうなって感じ。
- レジリエンスは設計方針。
- Actorとベンディングマシーンの例わかりやすかった。(よく使われる例なのだろうか?)
- 造船時の防水隔壁パターンの話。タイタニックは障害のカスケーディングの典型例。事故の原因は故障した部品ではなく、部品どうしの関係性にある。
- システムのレジリエンスをどうやって実現するかって話。actorごとにboundaryを設けて、障害の伝搬を防ぐ。threadでもmachineでも良い。
- トークの最初と最後にロッキーのテーマを流してたけど好きなのかな。
The Zen of Akka
Published my slides for the #zen of #akka talk at #ScalaMatsuri, どぞ: https://t.co/lE8it9l2hx
— Konrad Malawski (@ktosopl) January 31, 2016
- Zen。味があるトークだった。
- Akkaのロゴを山水画の山に透過させて描いていたのウケたんだけど、ロゴの由来だったりするの???
- Actorは1つの責務に特化させるべし。他と強調して動くべし。
- Errorはビジネスロジックの問題。Failureはインフラの問題。
- Akka Clusterの話も一般的な問題の話っぽくて面白かった。
- AkkaはFrameworkではなくToolkit。適切に使え。
- Constraints Liberate, Liberties Constrain(制限は私達を自由にする。自由は私達を制限する)
- 元ネタ
- Happy HAkking, Community!
DAY 2
Kafka Tuning
#ScalaMatsuri #sm_b 資料ですhttps://t.co/rQuUaTLGZj
— Kenji Yoshida (@xuwei_k) January 31, 2016
"Apache Kafkaを使ったマイクロサービス基盤"
- ドワンゴの社内マイクロサービス基盤?ではAt Least Once。Exactory Onceや順序保証はなし。
- RabbitMQやめた理由。そこまでスケールを意識していない設計になっている?
- 既存のクライアント(Reactive-kafkaとか)は要件を満たさず使っていない。
- 通信は独自のバイナリプロトコル。httpアダプタを自作。既存のhttpアダプタは無いの?コンフルエントが出しているけれど、機能少ないという判断で使うの辞めた。
- kafka 0.8当時consumerのjarが作りかけなのにmaven centralにpublishされていた…?(ガクブル)
- コードの辛みと運用の設定値チューニングの辛み。ブログとかMLとか読み込んだとのこと。
- 最後の質問でクラウドサービスは検討しなかったの?って聞いたら、オンプレあるししなかったって言われた。ですよね。
Scalaz入門
- よしださんともみあげさんとがくぞさんのハンズオン?パネルディスカッション?
- 最初はEitherとかFolderbleとかValidation
- Scalazは道具だから目的になるなって話でとりあえず釘をさしていた。
- FP in Scalaの第一章は素晴らしいのでそれだけでも読みましょうとのこと。
- 関数型プログラミングではサブタイピングによるポリモーフィズムを避けようって話があるので、OOPと組み合わせるとimplicitがバッティングすることがあったりもするとのこと。
- 参考
リアクティブシステム入門
Typesafe Reactive Platformで作るReactive System入門https://t.co/ukCt8ltzdX
— にわタコ (@niwatako) January 31, 2016
#ScalaMatsuri #sm_c
- 昨日のJonas氏のトークを日本語で要約した感じ。Reactive Platformのコンポーネントのその中での役割をちょっと具体的に説明している。
- デモ。ソーラーファームを運営しているお客様。一万枚のパネルの発電状況をモニタ。故障検知。1msも無駄にしたくない。リアルタイムで。MQTT, Akka, Play, WebSocket。
- TISはSIでもTypesafe Reactive Platformを適用出来ないか頑張っているとのこと。すばらし。
Typesafeの人にリアクティブについて聞こう/Reactive adoption with Typesafe members
- Typesafeの四人が登壇して、質問に答える形式。
- 質問:金融とかクリティカルなとこではどうなの?
金融業界ではReactiveSystemという概念が出る前からそのような仕組みが作られていた #ScalaMatsuri #sm_a
— にわタコ (@niwatako) January 31, 2016
#ScalaMatsuri 分散トランザクションを求められるが、実際は金融ではそうではないと。各金融機関間でメッセージのやり取りをして決済をするので、実は非常にReativeに向く。
— Kimura Sotaro (@kimutansk) January 31, 2016
#ScalaMatsuri システム全体として重複を除去できれば問題ないと。そういう考えは面白い。トランザクションで思考停止していた感があります。
— Kimura Sotaro (@kimutansk) January 31, 2016
- 質問:GoogleもDataflowとか標準化しようとしているけれどどう戦ってくの?
#ScalaMatsuri GoogleのDataflowとどう伍する?>GoogleのDataflowとSparkと補完的な立ち位置にある。Akka Streamの本質は適切なBack Pressure。サポートチケットの大半はロード超過
— Kimura Sotaro (@kimutansk) January 31, 2016
- okapiesさんのReactive Streamに関する質問とスライド使ったファシリテーション素晴らしかった。
- これ期待
@huntchr Thanks for participating the panel discussion! I'm looking forward to blog posts about "reactive database" about ES #scalamatsuri
— Yuta Okamoto (@okapies) 2016, 1月 31
- 録画見てちゃんと理解したい。
Scala.js コンパイル・パイプライン
- どうやってScalaのコードをJSに理解させるコードに置き換えているかの講義だった。
- 後半はよくわからなかった。
- 同じ感想。いきいきと話す人だった。
今回の #ScalaMatsuri の一番大きい収穫は、Scala.jsの開発者は相当本気で、やっぱりProduction readyだったということがわかったことですね。
— はちさん (@armorik83) January 31, 2016
パネルディスカッション:Scala社内教育
- Scalaは色んなレベルの人が色々な書き方が出来るので、その人の背景とかレベルに応じた教育方針がそれぞれあって面白かった。
- 一日目にドワンゴの新人研修資料が公開された。
- hatenaの新人研修資料は最初の年に海外の秋採用の新人を使ってdebugしたとのこと。 github.com
大学教育とScala
- 最近から弊社にインターンシップに来始めた学生が発表していたので顔出してみた。
「大学教育とScala」の発表スライドです https://t.co/fmIAJkTfCu #ScalaMatsuri
— みっちょん (@3tty0n) 2016, 1月 31
Scala 転職・年収
- 各社の年収状況
ScalaMatsuri来場者の年収分布(左端列が海外) #ScalaMatsuri #sm_h pic.twitter.com/9ZKPAwqp1r
— りあくてぃぶ (@nyamngo) January 31, 2016
全体の感想とまとめ
Typesafe
- Typesafeの方々のトークを直に聞けたのがとても良かった。
- またeed3si9nさんにTypesafeの概要とかの話を聞けたのも良かった。
運営
- 一日目の最初に技術カンファレンスの行動規範についてののビデオが流れたけれどもとても良く出来ていた。
技術カンファレンスの行動規範の講義始まったいた。 pic.twitter.com/FB4rKjbGVE
— さとしお (@satoshihirose) January 30, 2016
2015年に飲んだビールまとめ
一年でビール何銘柄程度飲めるか
二年位前からビールが好きになったので、去年は100銘柄ビールを飲もうという目標を立てました。
年始は張り切って人を誘ってビアバー巡ってましたが、年の後半はお金も使いたくないので食事誘われたらビアバーを提案するくらいのペースに落としました。 ビールが好きだと言っているとお誘いやお土産の引き合いがあってそれはそれで楽しい一年でした。
以下の一覧では写し疲れたので100で辞めましたが、記録していない銘柄もあるのでだいたいユニーク銘柄数は120-130位でしょうか。 銘柄被りや居酒屋で飲む日本のラガーを合わせれば3倍くらい飲んでそうなので、一杯平均して350mlだとすると大体100Lくらい飲んだ計算になるでしょうか。 ちなみに東京人の平均ビール消費量は35L程度だそうです。
1人あたりのビールの消費量の都道府県ランキング - 都道府県格付研究所
美味しかったビール
初めにビールを好きになった頃はホワイトビールが好きでした。特にハーブ感が強いエーデルワイスをよく飲んでいました。
この企画を始めた頃はIPAが好きでした。DirtWolfのDouble IPAが香り高くて良かったなと印象に残っています
途中からポーターが好きになりました。開栓直後の反射炉ビアポーターは感動的な美味しさでした。
また最近は大麦と小麦を混ぜたビールの味がとても美味しく感じたので探っていきたいなと感じています。
ビールの美味しさはその時の体調や気分や開栓からの期間だったりに左右されてしまうので、体験の質を上げるのもまた良いと思います。 うすはりグラスでよく冷えたビールを飲んだり、
桜を見ながら外でビールを呑んだり
好きな女の子とビールを飲んだりですね。 2016年も楽しんでいきましょう。
印象に残っているビアバー
訪れたのは一昨年なのですが、とても印象に残っています。たぶんデートには使えません。
映画配給会社の店舗の一角を使った飲食店とは思えない狭い店内。 映画配給で日本行脚するツテで、日本の地方ブリュワリーからビールを仕入れてお店にしているという変わった出自のお店。 そのオーナー?の方がずっと日本のビール醸造の今昔話をしてくれてとても興味深かった記憶があります。
今はどうなっているかわかりません。
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年の振り返り
作ったものはだいたいこんな感じ。 入社一年👏 - satoshihirose.log.2
見事に週末はcommitしていないことが分かる。
自分の興味感心はソフトウェアエンジニアリングよりもシステムアーキテクト領域かなと最近思い始めている。
自己組織化するシステムを作る
- ルールベースのプリミティブなものでしかないけど、まあ可。今後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年は何かしら成果を出したい。