Skip to content

[書評] 大国の暴走「米・中・露」三帝国はなぜ世界を脅かすのか

[書評] 大国の暴走「米・中・露」三帝国はなぜ世界を脅かすのか published on [書評] 大国の暴走「米・中・露」三帝国はなぜ世界を脅かすのか へのコメントはまだありません

戦略SLGと国際政治ニュース

「先の事を考えるのが楽しい」点が似ている

子供の頃は戦略シミュレーションゲームが好きだった。光栄(現:コーエーテクモ)のゲームとか、大戦略シリーズとか。相手がどうやって攻めてくるのか、それをどう撃退するのかとか、色々考えるのが楽しかった。

話を現代に戻すと、普段、ニュースサイトとかアプリで色んな記事を読む。その中で、個人的に国際関係のニュースが一番好きなのは、多分戦略ゲームと同じ感覚なんだろうという事に気づいた。国と国同士の(広義での)攻防の行方を想像したりするのが結構楽しいんだと思う。

身体性の有無

もちろん、そうした攻防の中で、(シリアやミャンマーの例を出すまでもなく、)生身の人間が沢山死んだりしているのは知っているんだけど、何だかんだであまり身近な話ではなく、いまいちリアルな感覚を持ちきれない面があるのは否定できない。

身近な北朝鮮問題であっても、ミサイルが来る可能性があるのは米軍基地か東京都心だろうし、自分が住んでいるところは大丈夫、とか思ってしまうのは安全性バイアスというやつかもしれない。

Continue reading [書評] 大国の暴走「米・中・露」三帝国はなぜ世界を脅かすのか

Categories

複数バージョンの Ansible を使う

複数バージョンの Ansible を使う published on 複数バージョンの Ansible を使う へのコメントはまだありません

複数の Ansible を使いたい理由

本番環境のプロビジョニングやら開発環境構築で Ansible を使っている人は多いと思う。Ansible はバージョンがどんどん新しくなっていくので、複数のプロジェクトをやっていると、プロジェクト毎に必要とされる Ansible のバージョンが異なって困る、という事が良くある。

VM を使って、隔離された環境を使えば?という意見もあるけど、開発環境構築では、

  • ローカルマシンの Ansible を使用して
  • (Vagrant 等で構築した)VM 上の環境を構築

というケースが結構あるので、Ansible のバージョン毎に異なる VM を使うというのはちょっとやりづらい。

実現方法の案

大抵のプログラム言語では、複数のバージョンを使い分ける仕組みが整っているけど、Ansible にはそういうのが無いようなので、ある程度自分でやる必要がある。

Ansible のインストール方法のページを見ると、色んな方法が用意されている。

複数バージョンを使い分ける方法としては、以下が考えられそう。

  • 複数バージョンのソースを持ってきて、ソースから実行する(Running From Source
  • pyenv 等で複数の Python 環境を用意して、 pip でバージョン指定で Ansible をインストールする

今回は、前者の方法でやった。その途中で後者の方法も思いついたけど、実際に試してはいない。pip でのインストールは、ドキュメントでは Latest Releases Via Pip という見出しだけど、バージョン指定も出来るはず。

Continue reading 複数バージョンの Ansible を使う

コイン

[書評] 新 賢明なる投資家

[書評] 新 賢明なる投資家 published on [書評] 新 賢明なる投資家 へのコメントはまだありません

概要

「賢明なる投資家」は、「投機」でなく「投資」のバイブル的書籍。現代における投資の神様的存在のウォーレン・バフェットも、本書を絶賛してるらしい。

1949年に初版が出て、1973年(?)に第4版が出たが、それに現代の状況に合わせた「注解」を加えて2003年に発行されたもの。日本語版は2005年出版。

随分前に買ったのに、数年間本棚に眠っていたのを、ようやく読んだ。もっと早く読んでおけば良かった。

自分なりに簡単にまとめる

本書の教えを、日本の現在の状況に合わせて勝手に解釈して3行にまとめると、以下の通りかと。

  • 「積極的投資家」と「防衛的投資家」とは、取れるリスクの違いではなく、かける時間の違い
  • 大多数の人が当てはまるであろう「防衛的投資家」は、株式インデックスファンド:債権インデックスファンド=1:1の割合で定額積立すべし(iDeCo や NISA を活用)
  • 相場(Mr. Market)に惑わされるな

感想等

歴史の重み

内容は素晴らしいに尽きる。彼の理論は、長い年月を経て正しいことが実証されている。「長い年月」には、大恐慌や、本書発行後のインターネット・バブルなども含まれる。大抵の「理論」は、過去10〜20年たまたま上手くいっただけの手法を、真理かのごとく喧伝しているのがほとんどだが、本書にかかれている内容の正しさは歴史が証明済みで、重みがある。

注解が助かる

ベンジャミン・グレアムによる原文が書かれたのは1973年だが、40年以上前なので、当然状況が現在と異なる。また、一読しただけだと内容が分からない文も結構あった。各章の後ろについている、ジェイソン・ツバイクによる詳細な注解は、当時の状況と現在の状況の違いや、分かりにくい部分の解説などもあって、個人的には助かった。

アメリカと日本で異なる

とは言え、注解もアメリカでの話なので、日本の状況に置き換えて理解するには、最低限の経済・金融商品の知識が必要だと感じた。

自分自身も専門家ではないが、書籍等でごく基礎的な知識は持っているつもりなので、ある程度は理解出来た(と思っている)。

本書が難しすぎると感じた人は、ページ末尾の本をお勧めする。

もっと若いうちに読んでおけば良かった

読んだ感想で一番大きいのは、もっと若いうちに読んで、定年後の生活費や子供の将来の学費などのために、賢く資産形成をしておくべきだと思った。

ということで、このページを読んだ若い方は、是非本書を購入して読んで欲しい。

個人的まとめの補足

債権

日本では、個人投資家が債権に投資する選択肢としては、実質的には

  • 個人向け国債
  • 債権ファンド(ETF 含む)

くらいしか無いと思う。

時間をかけたくない「防衛的投資家」にとっては

  • 分散投資という観点では、債権ファンドが良い
  • 手数料を考えるとインデックスファンドが良い
  • ドルコスト平均法で時間軸で分散投資するためには、積立型が良い

ということで、債券インデックスファンドへの積立が良いかと。

(誤りのご指摘等があれば、是非お願いします。)

株式

株式も債権と同様の理由で、株式インデックスファンドへの積立(TOPIX連動型とか)が良いと思う。

国内、海外先進国、エマージング等は、個人の好みで適当な割合でどうぞ。

税金

投資で無視できないのが、税金(と手数料)。

所得控除され、運用益も非課税の iDeCo は最強。年数が決まってるけど運用益が非課税の NISA も使うべき。

ただ、iDeCo は、60才まで下ろせない点だけは要注意。

基礎的知識を得るための書籍

本書は、読み進めるにはある程度基本的な知識が必要だと思う。それがない人向けに、(個人的に良かったと思う)入門書を何冊か挙げておく。

と思ったけど、別エントリーとして書く予定。

サーバーラック

AWS の r3 より r4 + EBS の方が安くて速かった

AWS の r3 より r4 + EBS の方が安くて速かった published on AWS の r3 より r4 + EBS の方が安くて速かった へのコメントはまだありません

結論

AWS の r3 系インスタンスを使っている人は、r4 系 + ディスク追加に切り替えると、値段が安くなってパフォーマンスも上がる可能性が高い。

背景

仕事で、EMR 上で Sparkを 使っている。処理としては、1日1回のバッチ。(詳細は書けないので省略。)

日によってデータ量にばらつきがあり、persist した時に、メモリに入りきらず一部ディスクに書き込まれる時がある。ちなみに、storage level は MEMORY_AND_DISK を指定している。

インスタンスタイプは、r3 系を数十台使っている。

途中からプロジェクトに加わったので詳しい経緯は分からないけど、ディスクも使うため、インスタンスストアのある r3 を使っているものと思われる。スペックの違い等は、以下のページを参照。

インスタンスタイプ – Amazon EC2 | AWS

r4 の方が安いが、EBS のみ

以下の価格表を見ると、r3 インスタンスの後継(?)である r4 インスタンスの方が安い。

EC2 インスタンスの料金 – アマゾン ウェブ サービス (AWS)

が、r3 インスタンスには付いていたインスタンスストア(SSD)が r4 インスタンスには付いていない。

また、色々調べてた時に見た以下のブログ記事に、

東京リージョンで「r4」インスタンスが利用可能になりました | Developers.IO

以下のような記述があった。

現在、「r3」のオンデマンドで稼働中であったり、リザーブドインスタンスの契約更新を控えたEC2インスタンスについては、 利用中のストレージを確認し、EBSのみの利用でである場合には、「r3」→「r4」への変更を検討頂ければと思います。

なので、ディスクを使いたい場合は r3 を使う必要があると思いこんでいた。

ディスクは追加出来る

一旦、r3 での運用で落ち着いていたけど、やはりコスト削減はしたい。ということで、もう少し調べてたら、EMR のインスタンスには EBS ボリュームを追加することが可能。詳細は以下のページを参照。

インスタンスストアと Amazon EBS – Amazon EMR

ということで、r3 → r4 + ディスク増設に切り替えてみた。

結果・・・

  1. 時間あたりの料金削減(r3とr4の差額分削減、EBS追加分増加、トータルでは削減)
  2. バッチ処理時間削減

となった。2は予想外だったけど、以下のページにちゃんと書いてあった。

次世代のメモリ最適化EC2インスタンス(R4) | Amazon Web Services ブログ

大きなL3キャッシュと高速なメモリを搭載することで、既存のR3インスタンスより高い性能を発揮します。

ちなみに、ディスク追加の方法だが、GUI の場合は、画面から EBS を追加できるはず。(やったことないので未確認。)CLI の場合は、create-cluster の –instance-groups で EbsConfiguration を指定する。

詳細は以下のページを参照。

create-cluster — AWS CLI 1.11.136 Command Reference

まとめ・雑感

リザーブドインスタンスが残っているのでなければ、一般的には最新のインスタンスに乗り換えたほうが良い。あと、やっぱり、オフィシャルのドキュメントをしっかり読み込むのが大事。

国際化

Play! framework + React サイトの i18n

Play! framework + React サイトの i18n published on Play! framework + React サイトの i18n へのコメントはまだありません

概要

タイトルからある程度想像はつくと思うけど、一応書く。

前提

  • Play! framework の messages ファイルとかを使って、テキストの i18n を行っている。ドキュメントはこの辺
  • 日付とか、その辺の i18n は今のところやっていない

やりたい事

  • React で表示しているメッセージも多言語化したい
  • Play 用、React 用と、ファイルを2セット用意するのは避けたい

環境

  • Play! framework 2.5
  • React 15

結論 (tl;dr)

  • Play JsMessages というライブラリを使用し、messages ファイルの内容を JavaScript のオブジェクトとして出力するエンドポイントを作成 (/i18njs/allMessages という名前にした)
  • Play! framework のビューの中で <script> タグを使ってそのJSオブジェクトを読み込む
  • i18next というライブラリに、その JS オブジェクトを渡す
  • React (やその他 JS コード)でテキストを出力する部分で、i18next を使う

Continue reading Play! framework + React サイトの i18n

Nunjucks + gulp で静的 HTML をモジュール化する

Nunjucks + gulp で静的 HTML をモジュール化する published on Nunjucks + gulp で静的 HTML をモジュール化する へのコメントはまだありません

やりたいこと

概要

静的 HTML を複数ページ作成するときに、共通部分(ヘッダーとかフッターとか)をコピペしたくない。

「PHP とか使って include とかすればいいじゃん」

ていう意見もあるんだけど、動作確認に web サーバー立てるの面倒だし、単なる HTML で済むなら HTMLで 完結させたい。

細かい背景

gulp-ect を使って、やりたいことは大体実現出来ていたんだけど、以下の2つの理由により、別の方法に切り替えたいと思った。

  • ECTgulp-ect も最終更新日が3年前
  • ファイルのパスを埋め込む(後述)、というののやり方が分からなかったし出来なさそう

やったこと(TL;DR)

さきに結論だけ書いておくと、

  • Nunjucks というテンプレートエンジンの記法で、ファイルを作成
  • gulp-nunjucks-render という gulp のプラグインを使って、HTML を出力
    • gulp-data という微妙な名前のも併用

という方法で実現した。

Continue reading Nunjucks + gulp で静的 HTML をモジュール化する

Scala とか Play の Future と ExecutionContext について

Scala とか Play の Future と ExecutionContext について published on Scala とか Play の Future と ExecutionContext について へのコメントはまだありません

背景

Scala や Play! framework で Future 使うときに、ExecutionContext を渡せと言われる。よく分からない場合は、とりあえず

import scala.concurrent.ExecutionContext.Implicits.global

とやっておけば、とりあえずコンパイルは通るんだけど、よく分からずにやっている人も多いと思う(ノ)。

今回は、そっから先の話。

Continue reading Scala とか Play の Future と ExecutionContext について

Scala の並列コレクションが直列でしか動かないと思ったら・・・

Scala の並列コレクションが直列でしか動かないと思ったら・・・ published on Scala の並列コレクションが直列でしか動かないと思ったら・・・ へのコメントはまだありません

追記

やっぱり、並列コレクションを使うのはやめて、Future 使って、Execution Context とかをちゃんと設定する方法にした。

が、一応、以下の内容はそのまま残しておく。

並列コレクションを使う動機

今、いろんな API からデータを取ってきて、それらを検索可能にするっていう(元々は自分用の)サービスをちょこちょこ作っている。(興味のある方は以下のリンクより使ってみて、是非フィードバックを下さいませ↓)

Track Down Anything on GitHub, Slack or Google Drive | Commet

いろんな API からデータを取ってくるので、直列で実行すると、どっか1箇所の API が不調だったりしてレスポンスが遅いと、それに引きずられてしまうので、並列化しようと思った。

コード

元々のコードは、大雑把にはこんな感じ。

SomeDatabase.findAllApiEndpointsToCall.foreach { apiCall =>
  apiCall.execute
}

これを並列化しようとして、以下のコードにした。

# par をつけた
SomeDatabase.findAllApiEndpointsToCall.par.foreach { apiCall =>
  apiCall.execute
}

ログをみると、

02:08:35.008 [ForkJoinPool-3-worker-5] INFO xxxxx

という感じで、別スレッドで動くようになったようだけど、スレッド名が常に同じ=1つのスレッドしか使われていないらしい。

以下のドキュメントを見ると、設定変更出来るらしいので、やってみた。

Parallel Collections – Configuring Parallel Collections – Scala Documentation

val apiCalls = SomeDatabase.findAllApiEndpointsToCall.par

# TaskSupport なるものを作成して、コレクションのプロパティにセット
val taskSupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(4)) # 4並列
apiCalls.tasksupport = taskSupport

apiCalls.foreach { apiCall =&amp;gt;
  apiCall.execute
}

これで、とりあえず並列で処理されるようになった。

Continue reading Scala の並列コレクションが直列でしか動かないと思ったら・・・

Commet

Slack の App Directory に掲載してもらった

Slack の App Directory に掲載してもらった published on Slack の App Directory に掲載してもらった へのコメントはまだありません

サービスを Slack App Directory で一般公開した

結構前からちょこちょこ開発してたものの、時間がなくて半分自分+知り合い専用になっていたサービスを、一念発起して一般公開することにした。

で、今回、Slack の App Directory に載せてもらったので、その手順とかを簡単に情報共有する。

どんなサービスか

GitHub, Slack, Google Drive 等のサービスから API 経由でデータを取ってきて、一括で検索できるようにするというもの。興味のある方は以下からどうぞ。

Continue reading Slack の App Directory に掲載してもらった

[書評] SPRINT 最速仕事術

[書評] SPRINT 最速仕事術 published on [書評] SPRINT 最速仕事術 へのコメントはまだありません

おおまかにどんな本か

Sprint とはGoogle Venturesで使われているプロトタイピング、課題検証のための方法で、それを説明したのが本書。

日本語のサブタイトルが「最速仕事術」なのは分かりにくい。英語の Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days の方がそのままズバリでわかりやすい。

主な対象読者は、新規事業をやっている人だろうけど、それ以外の人にも参考になる部分がありそう。

内容

月〜金までの1週間で、目標設定、アイディア出し、テストする案の決定、プロトタイプ作成、ユーザーテストまでを行う。

  • 月曜:長期目標の決定、課題のマップ作成
  • 火曜:ソリューションを各自で考える
  • 水曜:ベストな案を決定し、ストーリーボードを作成
  • 木曜:プロトタイプの作成
  • 金曜:ユーザーテスト、インタビュー

事前準備のプロセスもあるので、実際には5日+αがかかるが、それくらいの短期間でアイディアを試して、実際にその方向で進めるか、やめるかを決定する。みたいな感じ。

火曜は、「TUESDAY: 思考を発散させる」という見出しがついていて、ブレインストーミングとかを思い出す人もいるかと思うけど、本書では「はじめに」の一番最初、そして火曜日の章でも、ブレインストーミングを否定している。

月〜金曜日のすべてのプロセスについて、細かい手順について説明されているので、可能であれば最初はするのが良さそう。

思ったこと

Lean Startup とかで、仮説検証のサイクルを短くすることの重要性は一般に認知されてきたと思うけど、それを極限まで効率化した方法で、有用そうだなと思った。

じゃ、まずはそのまま実践しよう、となるかというと、なかなか難しいと思った。個人的な事情で言うと、本書はある程度の人的・資金的リソースがあることが前提となっているので、個人事業主だったり零細企業だとそのまま実践するのが難しいと感じた。ただ、出来るところから取り入れていけばいいし、実際にいくつか取り入れてみたところ、それなりに効果は出ているように感じた。

なお、月〜金曜日の各手順は、いろいろ試行錯誤したうえで出てきたベストプラクティスと思われる。他の本などで書かれている内容をもう少し洗練させた方法だったり、そういうのが結構たくさんある。個人的には、木・金の内容は、比較的既視感があった一方、月〜水の内容は色々と新しい発見があった。

全般的に良い本だと思うし、おすすめできる。