Twitter Facebook github

Archive for 12月, 2015

2015年 お世話になりました

今年も残すところあとわずかとなりました。

今年の振り返りは既に誕生日エントリに書いたので、簡単にご挨拶だけ。

このブログを読んでいただいているみなさん、お仕事でご縁があったみなさん、プライベートでお相手してくださったみなさん、今年もたくさんお世話になりました。

これは私が実践していることですが、1年の計は元旦にありといいますので、お正月こそその年に達成したい目標を設定し、誓いとすることお勧めします。年の初めに明確にビジョン化できたものは現実化するスピードが速いものです。

まだまだ未熟な私ですが、来年もビジネス・プライベート共に、前向きにがんばっていきたいと思いますので、よろしくお願いいたします。

それでは、よいお年をお迎えください。

デプロイ用ユーザーの在り方を考える

たいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。

 

今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。

WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。

前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。

(後から調べたことですが、Red Hatが共有ディレクトリのベストプラクティスとして提案していたようです。)

 

今回のゴール

  • デプロイ用の専用ユーザーを作り、WordMoveはデプロイ用のユーザーからデプロイを実施する
  • ウェブサーバーの実行ユーザーは変更しない(apacheまたはnginx)
  • 上記のままうまく回るようにユーザーとディレクトリのパーミッションを変更する

 

デプロイ元の環境で鍵ペアを作る

今回はVCCWを使ったVagrant内のWordMoveを使います。特にWordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。

秘密鍵のパスフレーズは必要に応じて設定してください。

ssh-keygenコマンドで鍵ペアが生成されますが、触れていいのは ~/.ssh/id_rsa.pub のように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。なお、当然ですが ~/.ssh/id_rsa は秘密鍵です。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。

 

デプロイ用のユーザーを準備する

ここでは deployer という名前で作成します。

 

デプロイユーザーが対象のディレクトリに書き込めるようにする

今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。

今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。

 

これで終わり…なら簡単で、記事にすることもないんですが、2つ問題があります。

deployerでファイルの編集をしてみます。問題なくできます。

 

次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。

次にパーミッションをチェックします。

1つめの問題です。このように、新規でファイルを作成してしまうと所有権は deployer:deployer になってしまいます。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。

これを解決する方法として特殊なパーミッションビット、setgidを使います。

 

setgidを理解する

setgidというのは、setuid, setgid, sticky bit と並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。今回はsetuidとsticky bitは使わないので省略します。

setgidはset group idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。

setgidはchmodコマンドで g+s を指定することで設定できます。

チェックしてみます。

デフォルトでグループがnginxに割り当てられています。

今度こそ終わり… と思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。2つめの問題です。

 

デフォルトパーミッションを変更する

ここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。

umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。デフォルトではumask 022(=新規ファイルは644、自分だけ書き込み可)になっていますので、今回はumask 002(=664、自分とグループの人が書き込み可)に変更したいわけです。

今回はdeployerユーザーにumask 002を付与したいので、deployerユーザーの .bash_profile を利用します。

テストしてみます。ただし、sudo -u deployerを使うとrootのログインシェルに入ってしまいumask 022が適用されてしまいますので、su – を使います。

新規ファイルも664のパーミッションで、グループを継承できました!念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。

 

WordMoveでデプロイしてみる

今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。

Pulling Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。

ちゃんとプッシュできていることを確認して終わりです。お疲れ様でした。

 

雑感

ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。ただめちゃくちゃ面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。難しいですね。

nginxでHTTP/2ことはじめ

このエントリを書いているうちにクリスマスイブになりましたね。いよいよ年末ムードですが、今年は年の瀬ギリギリまでお仕事です。クリスマスなんて無かった

前回のエントリの最後でHTTP/2, SPDYやりたいって書いたので有言実行ということで。この記事は既にstable(1.8)なnginxでSSLサイトを構築している環境が前提になります。

 

一昔前にGoogleが開発した次世代WebプロトコルのSPDYが流行っていましたが、SPDYを受け継いだHTTP/2の出現から、新たにSPDYを導入することはほとんどないようです。

Google自身もHTTP/2へ移行したようですので、今回はSPDYではなくHTTP/2を使ってみようと思います。cssやjs、画像などを多くロードしているページでは、表示速度がかなり向上するようですよ。

nginxでhttp/2を導入する場合は、–with-http_v2_module というパラメータをつけてビルドしないといけません。ただ、nginx公式のリポジトリから落とせるバイナリはこのパラメータ付きでビルドされているようですので、今回はこれを使う方針で進めます。(ちなみにSPDYは古いnginxで利用できていましたが、HTTP/2に載せ替えられる形で使えなくなりました。)

 

古いnginxの削除

まずは今インストールされているバージョンを確認します。

執筆時点のAmazon Linuxで標準のリポジトリからyumでインストールすると、上の通りstableな1.8がインストールされます。nginxは今年の9月末にリリースされたv1.9.5でHTTP/2をサポートするようになったので、1.8.0のnginxは削除します。

 

メインラインnginxをインストール

前述の通り標準のリポジトリからインストールすると1.8が落ちてきてしまいます。メインラインのnginxをインストールするには、公式のドキュメントを参考にnginxのリポジトリを参照するように変更します。

正しくメインラインのnginxが取得できるか確認し、問題なければインストールします。今回はnginx.repoにpriority=1を追記したので、Amazon標準リポジトリよりnginxリポジトリが優先して参照されます。このほかyumのコマンドに –disablerepo=amzn-main を記述することでもインストール可能ですが、yum updateなどで問題になることがあるので特に理由がなければ優先度を変更しましょう。

すんなりインストールできました。念のために自動起動の設定を確認しておきましょう。

 

http2の設定

次は1.9.9のnginxでhttp2を使えるようにします。

今回は1.8系のnginxからの乗り換えなので、古いnginxをremoveした時に残っている設定ファイルをベースに書き換えていきます。

SSLは前回設定していますので、書き換えるのはここだけですね。本当に簡単です。

なお、http2はSSLなしでも利用できる仕様ですが、事実上SSL対応しないと使えませんので、SSLに対応していない場合は過去のエントリ「Let’s Encryptをnginxで使ってみる」などをご参考ください。

 

動作確認する

ちゃんとHTTP/2で通信してくれているかどうかは、Chromeの場合デバッグ機能のnet-internalsを開くことで確認できます。新しいタブで、

chrome://net-internals/#http2

を開いてみてください。

HTTP/2 sessionsのテーブルに、今回対応したドメインが表示されていればうまく動いています。

スクリーンショット 2015-12-24 2.55.28

 

また、Chrome Extensionの「HTTP/2 and SPDY indicator」もオススメです。これをインストールしておくと、ブラウズしているページがHTTP/2またはSPDYに対応しているかどうかをURLバー右側の雷アイコンで視覚的に表示してくれます。

表示されている雷アイコンが青色であればHTTP/2、緑色であればSPDY、灰色であればこれらのプロトコルに対応していないことを表します。正常に動いているようですね。

 

雑感

数年前にSPDYで賑わったことは比較的記憶に新しいのですが、暫くその動向を追っていない間にHTTP/2が策定され移行が進んでいるようです。Web技術の変革スピードの早さを再認識しました。時代に取り残されないよう、新しい技術も積極的にキャッチアップしていきたいですね。

WordPressをSSLに対応させる手順

非SSL環境で動かしていたWordPressをSSL化するときの手順です。ちょうどLet’s Encryptを使って認証された証明書が手に入ったので、これを使ってWordPress全体をSSL化してみました。手順を備忘録として残しておきます。

 

wp-config.phpの修正

まずは基本ですね。WP_HOMEとWP_SITEURLを書き換えます。また、FORCE_SSL_ADMINを設定することで管理画面はHTTPSを強制できます。

 

データベースの修正

WordPressのデータベースに接続し、(WPプレフィックス)_options テーブルを開きます。

option_nameカラムがsiteurlになっているレコードを探し、値のhttp://をhttps://に書き換えます。続いてoption_nameカラムがhomeになっているレコードを探し、同じように書き換えます。

 

HTTP接続をHTTPSにリダイレクト

上の2ステップでWordPressのシステム的な部分の移行が終わりました。HTTPSで適当なページを開いて正しくリンクが遷移できるか、リンク遷移後もページもHTTPSになっているか、画像や画像のサムネイルが正しく読み込めているか、管理画面へHTTPSのままログインできるか、などをチェックします。

問題がないようであれば、httpでの接続はすべてhttpsにリダイレクトするようにします。(任意です。httpsにすると若干サーバーの負荷も増えますので、ハイトラフィックなブログを運営されている方はhttpの方が有利という考え方もできます。ブログであれば、http/httpsどちらでもアクセス出来るようにしておき、通信を暗号化するかどうか判断をユーザーに委ねるのも良い方法です。)

今回nginxを使っているので、nginx.confを書き換えることにしましょう。リダイレクトにはrewiteを使っているブログも多く見られますが、nginx.orgではreturnが使われていたのでreturnを使うことにします。計った訳ではないですが、シンプルな分処理も早そうです。

保存したらnginxを再起動します。

再起動が終わったら、適当なURLを叩いてみてHTTPSに正しくリダイレクトされることを確認します。

 

安全でないリソースを排除する(Mixed Content問題)

これで9割方終わっていて、SSLにするという目的自体は達成なのですが、次のように「このページに安全でない他のリソースが含まれています。」と表示され、URLのアイコンや文字色も緑色にならないことがあります。

これは、アクセスしているページはSSL接続にも関わらず、そのページ内から非SSLの静的ファイル等をロードしているためです。例えば、サードパーティのCSSやJavaScript、フォントファイル、画像ファイル等を絶対パスでhttp:// に続く形でロードしていることに起因するものが多いです。

これらを見つけて、httpsが提供されているコンテンツはhttpsでロードするように、提供されていない場合はライセンスを確認して自分のサーバーでホスティングできるか確認して移行するなどの対策を行います。量が多いと結構大変ですね…。

どのファイルがMixed Contentなのかは、Google Chromeのデベロッパーツールにあるコンソールが助けになります。

例えば上の画像のように、過去にアップロードした画像ファイルに起因するものであれば、次の項を読んでみてください。テーマやプラグインに起因するものは、手動で直さなければいけません。

ちなみに、Protocol Relative URLという仕様により、CSSやJavaScriptをロードする際のhttpやhttpsを省いて記述すると、読み込み元のスキーム(SSLか非SSLか)に従って読み込むスキームも変更されポータビリティが高まります。(例えば //example.com/main.js をSSLのページからロードさせた場合はhttps://〜と解釈され、非SSLのページからロードさせた場合はhttp://〜と解釈されます。)

 

アップロード画像に起因するMixed Contents問題を直す

この場合、基本的には記事を編集して、画像へのURLを書き直すことで修正できますが、過去の記事・画像が多いと直すのに骨が折れます。

一気に前述したProtocol RelativeなURLに画像リンクを書き換えるSQL文を使うと一瞬で解消できるでしょう。テストしていますが、万一のために必ず実行前にテーブルのバックアップを取ってください。

 

無事にMixed ContentsによるSSLの警告も消えました。

 

雑感

サクっとこなすつもりが意外と色々気にすることがあって大変でした。一度やっておくとノウハウ的に使い回せるので、知識として蓄えておきたいですね。

次はHTTP/2, SPDY対応や、証明書の透明性確保あたりを触れたらいいなと思っています。

Let’s Encryptをnginxで使ってみる

Let’s Encryptとは

https://letsencrypt.org/

無料で認証されたSSL証明書を発行できるサービスです。今月パブリックベータになり、誰でも試すことができるようになりました。Web Tech界隈では今アツい技術の一つです。

今回使うnginxは1.8系のため、HTTP/2、SPDYは使えません。メインラインの1.9系を使うことで対応できるので、興味がある方は別に調べてみてください。

ビジネスなどエンタープライズで使用する際はこのSSLではなく信頼された発行元から

 

Let’s Encryptのインストール

Let’s Encryptを使うためには、nginxやapacheなどのウェブサーバーのほかGitが必要です。OpenSSLなどはインストールされていない場合、Let’s Encryptが自動的にインストールしてくれます。Gitがインストールされていなければ、事前にyumで入れておきます。

まず、Let’s Encryptのクライアント本体を適当な場所にgitでクローンしておきましょう。

gitが必要な箇所はここだけです。結構頻繁に更新されているようなので、都度ローカルリポジトリも追従させてあげるのが良いでしょう。

クローンしたら、内包されているメインのコマンド letencrypt-auto を叩いてみましょう。このコマンドを実行した場合、letsencryptが使用する必要なライブラリがインストールされていなければ自動でインストールしようとします。rootで実行していない場合はパスワードを入力してください。

今回、AWS EC2で実行している関係で上のような警告が表示されました。EC2上で利用するのであれば一般的なCentOS等と使い方は何ら変わりませんので、言われるままに継続します。

一度debugをつけて実行した後はdebugなしで利用できるようです。

 

証明書の取得

発行にはドメインの所有権認証が必要です。letsencrypt-autoでは、次の方法でこの認証を簡単なコマンドだけで実行できます。

現時点でlets encryptでは apache, standalone, webroot の3種類の証明書取得方法をサポートしています。apacheを使っている場合はapacheを使うと自動でインストールしてくれます。standaloneはletsencrypt自身がウェブサーバーを起動して所有権の認証を行います。webrootは既にウェブサーバーが起動している場合、ドキュメントルートを指定して既存のサーバーを介して認証を行います。 詳しい違いについては ./letsencrypt –help で確認してください。

今回はnginxですし、既に起動しているサーバーに対してインストールしょうとしているので、3番目のwebrootオプションを使って認証を行います。

上記を実行するとメールアドレスの入力と利用規約への同意が求められますので、指示通り進みます。認証情報を紛失した際などは、ここで登録したメールアドレスを使ってリカバリするので間違えないように気をつけてください。

次のようなメッセージが出力されれば、正しく証明書を取得することができました。

 

上の例では、/etc/letsencrypt/live/<ドメイン>/ の中に証明書類が保存されています。

 

DH鍵交換のパラメーター生成

証明書をウェブサーバーにインストールする前に、セキュリティ向上のために実行することをおすすめします。

opensslコマンドで生成します。AWSのsmallインスタンスで3分程度かかりました。環境によってはもっと時間がかかるかもしれません。

 

証明書をnginxに設定

最後に取得したSSL証明書をnginxから参照して利用できるようにします。

上の通り変更して、nginxを再起動します。設定ファイルに問題がなければSSLで通信できるようになっていますので、テストしてみましょう。

ssl-test

ということで、Let’s Encryptで簡単にSSL対応できました!

 

SSLのセキュリティテスト

SSLサーバーのセキュリティテストは Qualys SSL Report を使って簡単に実施できます。

ssl-check

最低限の設定を施しただけだとCやDランクになるかと思います。例えばPOODLEや弱いDHパラメーター、ダウングレード攻撃などの脆弱性を防いでいない場合は評価が下がります。

前述のnginx.confの設定を施せばAまたはA+の評価になると思います。ときどきこのサイトでSSLの安全性をチェックして、常にこの評価をキープしていきましょう。

 

雑感

以前から無料で発行できるSSL証明書もありましたが、手続きが煩雑だったりと色々厄介なことが多かったです。Let’s Encryptもまだ改善の余地はあり、速い速度で開発も進んでいますので、まだまだ今後に期待できるでしょう。Let’s EncryptでSSL対応が当たり前な時代になれば良いですね。

 

恩返しするということ

こんばんは。21歳になりました。

昨日は20歳の反省をしたので今日は21歳の抱負を。誕生日が12月後半なので、結局21歳の抱負=翌年の抱負ってことになってしまいますね。誕生日が6月とかだと半年スパンで振り返れていいなあと思います。

……というところまで書きましたが、明確に言葉にできないので、新年の抱負ということで、あと半月間の自分への宿題ということにさせてください。

 

その代わりといっては何ですが、もっと大きなテーマで書いてみます。

 

「お世話になっている人に恩返しする」

抱負をいろいろ考えているうちに、結局すべてこのテーマに繋がっているんじゃないかと思いました。

SNSでは少し書いたのですが、私は人と社会に貢献したいです。人を幸せにしたいです。特に今までお世話になってきた人達、今の私を形作ってきて下さった人達に恩返ししたいんです。

20歳の年は、わたしが尊敬する多くの人達と直接お話する機会に偶然恵まれ、その方々の思想を直接インプットすることができました。自分の人生観に強い影響を与えてくださった方もいらっしゃいます。そんな私の尊敬する人達に共通しているのは、彼等は人を幸せにすることに常に全力である、ということです。

例えば、私が好きなビジネスのテーマは教育です。直接人を幸せにすることもでき、社会に貢献することにも繋がっていて、これ以上このテーマにふさわしいビジネスはないんじゃないかと考えています。

また、お金を稼ぐ理由についてもこのテーマに基づいています。私は、人を幸せにするためにお金が欲しいんです。例えば身近にいる人を、お金がなくても幸せにする方法はいくらでもあります。でも、お金があればもっと幸せにすることができます。

こんなことを書くと、偽善者とか思われるかもしれません。でもそうではなくて、自分も幸せになりたいです。実は自分が幸せになることでも周りの人達は喜んでくれます。そもそも他の人を幸せにするということは、自分自身が幸せでないとできないことです。恩返しをする、他人を幸せにするというテーマは、自分を幸せにするということでもあります。

21歳もこの大きな人生のテーマを実現するために、着実に今見えているすべきことをこなしていきたいと思います。

 

共感して同じように思ってくれる人が一人でも増えてくれたらいいなと思って、このテーマをアウトプットしてみました。ブログを読んでくださっている皆さんへの恩返しと、こうして書くことで自分の意志をより確固たるものに近づけることができます。

 

また1年後、成長した自分自身に会えますように。 15/12/18

 

雑感

今年も前日の夜から親しくしてくれている友人とお酒を飲みにいって、日付が変わると同時にお祝いの言葉をかけてもらいました。わたしの誕生日のために集まってくれて、ずっとお喋りできる友人たちに恵まれたことは本当に幸せです。急遽決まったことなのに、みんな来てくれてありがとう、これからもよろしくね。

hub

 

さようなら20歳

こんばんは。

明日で21歳を迎えます。今更どう足掻いても歳はとってしまうのですが、20歳のうちに20歳の反省と振り返りをしておこうと思います。

21歳の抱負はまた明日に。振り返りなので固く書いて、明日は短く楽に書きます。

 

ちょうど1年前の今日の夜中、よく遊んでくれている友人と「ペンギンのいるBar」に行き、日が変わると同時にお酒を生まれてはじめて飲みました。はじめてのアルコールの味は、思った通りそこまで美味しいと思えるものではなく、グラス飲みきるのに結構苦労したのを覚えています。未だにお酒を好きと言えるようにはなっていないのですが、甘いカクテルなら数杯は飲めるようになってきました。一番のお気に入りはカシスミルクとピーチフィズ。見た目もかわいくて、甘くて、周りの人からは「それお酒じゃないよ笑」なんて言われちゃう通り、確かにお酒っぽくはないですね。同い年の女の子が生ビールを美味しそうに飲んでたりして、大人だなあなんて妙に感心してしまいました。いつか美味しく感じるときが来るのかな?

 

誕生日といえば、20歳の誕生日当日は自分の2社目の会社を設立しました。SNSでは猫社と呼んでいます。本業の傍ら、友人と共に経営に勤しんでおりましたが、最大で7人くらいの従業員を抱えるまで大きくなりました。また、今年の4月には東京レインボープライドに協賛する機会をいただきました。日本で一番大きいLGBTパレードに協賛させていただけることは本当に光栄なことであるとともに、わずかでもこの大きな活動を支援することができたことを誇りに思います。猫社も1周年を迎えましたが、従業員の方や経営を支援いただいた役員の方々には本当にお世話になりました。この場を借りてありがとうを。

 

自分の人生の進捗というと、GIDのことを挙げないといけません。今年は自分の名前が変わった年でもあります。6月13日、法的に今の「さくら」という名前に氏名変更が認められた、名前の誕生日になりました。GIDを理由に氏名変更を行う場合、最低も1年以上の使用実績が必要です。いろいろ悩んで悩んで、結局決まらないよね(笑)なんて思いつつ、それまでに使っていた「さくら」にしました。女性名がないと不便だからと、特に理由もなく使い出した名前でしたが、使っているうちに馴染んでいて、これしかなくなりました。名前なんてそんなものかもしれません。

両親にも名前変更のタイミングで自分がGIDであることをカミングアウトして(既に気付かれていたようですが)、自分自身を受け入れてくれたのは本当に嬉しかったことです。90近い祖母にも母から既に伝わっていたようですが、本当によく受け入れてくれたと思います。父母に理解されるのももちろん嬉しかったのですが、それ以上に祖母に受け入れられたのが本当に嬉しくて、もう隠さなくていいんだって思うと涙が出ます。これまで育ててきた子が名前を捨て、性別を変えると言い出すのですから、大きなショックがあったことだと思います。精一杯の親孝行でお返ししないといけませんね。心から、家族に恵まれたことに感謝しています。お母さん、お父さん、おばあちゃんにありがとうと、素直になれなくてごめんなさいを。

 

仕事の面では、本業は19歳の頃に入社したIT系の開発会社にずっと居させていただいております。今では技術部門のトップで、本当人生は何があるか分かりませんね。今年は主に前半はFlashを使ったストリーミングに、後半はWebRTCを使ったストリーミングに、主に映像配信技術に関する研究を行った年でした。前々から動画配信系のサービスってどう作って居るんだろう?と疑問になっていましたが、この1年でとても多くを知り、ある程度のサービスであれば自分一人で作ることもできるようになりました。知識欲をたくさん満たしてくれる職場に感謝します。残念ながら目に見える結果としては後半あまり残せませんでしたが、来年の早い段階で出せるように尽力する次第です。

また、それまでに個人的にスタートしていた事業をいくつか売却した年でもあります。私はモノづくりが好きで、ある程度成熟してきたサービスには興味がありません。今まで手がけてきたベンチャーで大きく実を結んでいるものも2つ3つありますが、勢いで作ってしまって、ある程度グロースできたところでバイアウト戦略をとっています。成熟してしまったサービスを大きくするよりもゼロからイチを作る方が楽しいですからね。

自分の手を離れた自分のプロダクトの成長を影から見守っています。

 

ずっと「生き急いでるね」なんて周りからは言われるのですが、本当にそうだと思います。私は死ぬのが怖いです。高校生のころ、自分から死ぬことを選んで病院に運ばれたこともあります。よくつぶやいたりしてますが、16歳のころは自分が20歳まで生きれるなんて思っていませんでした。だから、残り少ない人生を無駄にしたくない思いで、必死に生きてきました。それは21歳を迎える今も代わりありません。誰にも死は平等に訪れますが、重要なのは死には順番がないということです。私は90歳を生きるかもしれないし、不摂生やホルモン治療の影響で60歳を生きれないかもしれないし、交通事故や病気で30歳まで生きれないかもしれません。私の尊敬する人は「Life is today」と言いました。人生には明日も明後日もなく、今日こそが人生なんだと思います。例えば病院で、余命1年だと宣告されることを考えてみてください。あなたは残された1年という時間をどう生きますか?自分の人生という物語の終わりに、他人の人生を書くのは極めて滑稽じゃないですか。いつ自分の物語が終わったとしても後悔しないように、わたしは残り少ない自分の人生を生きることにしました。

 

最後に、こんな拙い文章を読んでくださっているみなさんに心からのお礼を。

 

雑感

こうして振り返ってみると、思ったより遠くまで歩けていたことに気付きます。学生のうち、特に時間があって暇で暇だった16歳の今頃は、ひたすら「マインクラフト」のサーバーチューニングや開発に勤しんでいました。それは好きで自分がやっていたことでしたが、今思うと今の私の大きな知識ベースになっています。人生には本当に無駄なことなんて本当はないようにできているのかもしれません。

可能性という意味では、年を取るのは本当に悲しいことです。極端なことを言えば、「学生モデルやりたい!」と思っても、私はもう学生に戻ることはできません。20歳30歳に上限の年齢制限がある職は多くはないですが、そういう職もあるんだなと。自分の生きた姿をそのまま残せるモデルさんっていうのは、結構憧れる職業だなーなんて思いつつ、「学生モデル」という限られた職に限って言えば、私がそこに入れる確率はゼロなわけです。自分が何者になれて何者になることができないのか、この年齢でも既に突きつけられたようで、ちょっと悲しく思いつつ、まだ開けている可能性を閉ざすことがないように生きていきたいと思いました。

 

以上が20歳の振り返りと、最近の雑感です。

取引メモ 151207

最近、実際に多く稼いでる専業トレーダーの人とお話をする機会が多く、毎回とても恐縮しています。

今日はいろいろ考えたことがあって、まとめておくことにします。

FXは、秒単位の0.xpips単位でのスキャルピングで全然勝てなかった嫌な思い出があって敬遠していましたが、もう少しだけ長い時間軸で持つことを考えて、実際に自分で考えたストラテジーのパラメータなどを変えつつ、様々な通貨ペアで手動バックテストを繰り返しています。

今のところ一番いい成績で自分に合っているトレード手法は、5分足を使ったテクニカル分析による超短期トレードで、平均保有時間は30分〜2時間程度です。この短い間でも多いときは50pips前後の値幅を取ることができています。

通貨ペアはユーロドル、ポンド円を組み合わせます。勝率は6〜7割でしょうか。

ストラテジーは性格により誰にでも通用するものではないですし、ストラテジーが勝ち負けに影響する割合は20%と言われていたりするため、現時点では詳しく書きませんが、そこまで複雑な分析に基づくものではありません。シンプルが一番なのかもしれないですね。

少しのバックテストを行ったあとで、今日は本番口座を使って小ロットで参加してみました。結果は17.3pipsのプラスです(括弧内は損益幅)。

1日何pips取れればいいんだろうと思って、複利計算をしてみたところ、例えばユーロドルの場合1日の平均収支が+10pipsであった場合、25倍のレバレッジを掛けると1ヶ月(20日間)で投資額の1.5倍になり、+20pipsであった場合、2.3倍近い額になる計算です。同じ計算をポンド円で行うと、後者のとき1.6倍だったりと若干効率が悪い数字になってしまいましたが、それでも1ヶ月10%前後を狙うなんてレベルではありませんね。ただしこれは100万円程度の少額だから可能なのでしょうが……。少額ならFXが効率いいというのは本当みたいです。

今まで個別株、先物、最近ではオプションにも手を出していますが、一度本腰を据えて為替を頑張ってみようと思った次第でした。

ミニマルとミニマム

英語の文章を書くとき、つい気になって調べました。

Wikipediaに答えがそのまま載っていたので下に引用します。

ミニマルの意味は日本の辞書においてはミニマム(英: minimum)と同じだが、英語圏では完全に区別して用いられる。ミニマルは形容詞、ミニマムは形容詞としてだけでなく名詞としても使われる。形容詞としては、ミニマルは「ただの最小」という意味で使われ、ミニマムは「事前に決められている最小限」の意味で使われる。使い方によってニュアンスの大分異なる単語であるため、英語圏での使用、使い分けには注意が必要である。

とのことで、やはり別物なんですね。今まで完全にフィーリングでミニマムミニマルを使い分けていましたが、ちゃんと意味的に正しいものを使おうと思います。

例えば開発の仕事で、仕様に定められている最小の値を言うときはminimal valueではなくminimum valueになるわけですね。これは感覚として理解していましたが、辞書的に納得したので自信を持って使えるようになりました。

「プロ相場師の思考術」を読了しました

purosoubashinoshikouzyutu

プロ相場師の思考術 (PHP新書)
高田 智也 著
PHP研究所
2007-08

あらゆる勝負事のなかでも、増減するお金の大きさから、もっとも厳しいとされる投資・相場の世界。その分野で勝ちつづける人たちがいる。なぜ勝てるのか?「運」「ツキ」と呼ばれるものの正体は何か?「強い人ほど負け方を知る」「情報は少なく深く利用する」「予想も予測もしない」「同じ過ちは絶対に繰り返さない」「好き勝手にできることは驚くほど少ない」-“相場で飯を食べられる人”の知られざる日常生活、仕事術の一端を垣間見つつ、プロフェッショナルな思考様式の核心を明らかにする。

~BOOKデータベースより

 

今後何か本を読んだら、このブログで思ったことやキーワード、キーフレーズを覚書として書き残そうと思います。どんな本だろうと、数年も時間を経るとその時の感情や内容を忘れてしまうのは悲しいことです。

本書内の引用を含むため、それらを見たくない人はこの記事を読まないでください。

Read More »