Skip to content

Vagrant 起動時の共有フォルダ周りで Protocol error

Vagrant 起動時の共有フォルダ周りで Protocol error published on Vagrant 起動時の共有フォルダ周りで Protocol error へのコメントはまだありません

症状

vagrant up で起動時に、共有フォルダを設定するところで、以下のようなエラーとなる。

==> default: Mounting shared folders...
default: /vagrant => /Users/kazu/Documents/workspace/foo
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:

mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant

The error output from the command was:

/sbin/mount.vboxsf: mounting failed with the error: Protocol error

環境

  • Host: Mac
  • Guest: Linux (Ubuntu 14.4)
  • Vagrant 2.2.2

原因と解決方法

エラーメッセージでググると、色々な原因でこのエラーが発生しうるが、自分の場合、`/home/vagrant` 以下に `vagrant` という名前で `/vagrant` へのシンボリックエラーがあったのが原因。

vagrant@vagrant-ubuntu-trusty-64:~$ ls -l /home/vagrant/vagrant
lrwxrwxrwx 1 vagrant vagrant 8 Dec 28 15:18 /home/vagrant/vagrant -> /vagrant

このシンボリックリンクを削除して `vagrant reload` で問題は解消した。

Vagrant のこの issue が参考になった。

このエラーがでるその他の可能性

  • VirtualBox Guest Addition が正しくインストールされていない、壊れている
  • 共有フォルダの設定が間違っている
  • などなど
karate

フリーランス中年男性のかんがえたさいきょうのスキルアップ方法

フリーランス中年男性のかんがえたさいきょうのスキルアップ方法 published on フリーランス中年男性のかんがえたさいきょうのスキルアップ方法 へのコメントはまだありません

フリーランスのスキルアップ方法あれこれ

昨年、Twitter でたまたま流れてきた以下のブログ記事を読んだ。

フリーランスやめるので本当のことを全部書く – Webを楽しもう「リパレード」

それ経由で、以下のアドベントカレンダーの記事もざっと一通り読んでみた。

フリーランス Advent Calendar 2017 – Adventar

フリー歴通算10年以上のおっさんとしては、「あー分かる分かる」って感じの内容が多かった。

で、本ブログエントリーでは、上の2つのページを踏まえて

  • フリーランス向けのスキルアップ方法
  • その他、アドベントカレンダーに書かれていないような事

辺りを書こうと思う。と思ったけど、長くなったので、今回は前者に絞って書く。

いわゆる、「ぼくのかんがえたさいきょうのすきるあっぷほうほう」

企業に所属した方がスキルは身につく(但し・・・)

最初に紹介したブログ記事の方は、フリーだとスキルが身につかない、というのが会社員に戻る大きな理由の一つっぽい。書かれている事は概ね正しいと思うし同意できる。

ただし、それには条件があると思う。

各ジャンルのプロフェッショナルがいる企業に所属したほうが断然効率がいい

とその方が書いている通り、「各ジャンルのプロフェッショナルがいる企業」というのが条件。

そして、そうした企業は意外に少ない。

Continue reading フリーランス中年男性のかんがえたさいきょうのスキルアップ方法

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

[書評] 大国の暴走「米・中・露」三帝国はなぜ世界を脅かすのか 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 の並列コレクションが直列でしか動かないと思ったら・・・