クラウド時代のプログラマについて考えたみた。

クラウド時代のプログラマについて考えたみた。

オンデマンドインスタンス型プログラマ

オンデマンドインスタンス型のプログラマは時間単位の報酬で作業を受ける。
プログラマに作業依頼にするには、ウェブコンソールから「インスタンスの作成」を行う。
ここで様々な種類のプログラマから作業内容にあったインスタンスタイプを選ぶことができる。
インスタンスタイプについては後述する。

スポットインスタンス型のプログラマ

プログラマはもしも定時にあがることができたなら家で少しだけ作業ができる。
強調しておくが、”もしも” 定時にあがれたらだ。
この空いた時間帯に副業として作業を依頼する分には少しだけ安く作業を請け負うことができる。

リザーブドインスタンス

もしプログラマに長期的に作業をしてもらいたい場合は、リザーブドインスタンスがお得だ。
あらかじめ年間に一定以上の作業を依頼する約束をすることで、安く作業を請け負ってもらうことができる。
ただし、もし約束しただけの作業を依頼できなかった場合でも、同等の報酬は払わなければならない。

インスタンスタイプ

プログラマにもタイプが存在し、作業に応じて向き不向きがある。
このため、クライアント様においては、作業内容に応じて適切なプログラマのインスタンスタイプを選ぶことが重要だ。

m4インスタンス

m4インスタンスは汎用的に使えるプログラマインスタンスタイプだ。特にこれに対して強いというものはないが
大抵のことをそれなりな感じにこなしてくれる。
どのインスタンスタイプを選べば分からない場合はとりあえずこれを選んでおけばいい。

c4インスタンス

とにかく特定の作業を早くこなしてもらいたい場合はこのインスタンスを使う。
ただし、このインスタンスタイプのプログラマはたくさんのことを覚えたり、たくさんのことを同時に行うのは苦手だ。

r3インスタンス

c4とは反対に、色んなことを同時にさせたり、記憶力の良いプログラマを所望する場合はこのインスタンスだ。

まとめ

冗談はさておき、実際もっと短いスパンで色んな仕事をこなすというのも面白いきはする。

MacでJavaの起動が遅い原因はアンチウイルスソフトだった

MacでJavaの起動がすごく遅いことに気づいた。
Javaのアプリケーションが重いのではなく、JavaのJVMそのものの起動が遅い。
java -version するだけでも10秒ほどかかった。

原因はアンチウイルスソフトだった。
リアルタイム保護機能が効いており、JVMを起動時にチェックしていたようだ。
私の場合はFortiClientというアンチウイルスソフトを使っていたが、これのリアルタイム保護を無効にすることでちゃんと１〜２秒で起動してくれるようになった。

ChromeのPush APIで「This site has been update in the background」という通知が表示される原因

「This site has been update in the background」はPUSH通知が来たが表示するメッセージがなかった場合に表示されるデフォルトのメッセージだ。
pushイベント内で showNotification() が確実に実行されるようにすることで、このメッセージを回避できるようになる。

evt.waitUntil() に渡すPromise内でshowNotification()することになるが、ちゃんと各箇所でPromiseをreturnしているか確認する必要がある。

私はfetch()のPromiseをリターンしていなかったためにこのメッセージ表示されており相当な時間ハマってしまった。

Amazon SESのTXTレコード設定、Value-Domain版

Amazon SESではドメインの認証をすることで、そのドメインからのメール送信ができるようになる。
ドメインの認証をするにはSESに指定された値をDNSのTXTレコードに設定する必要がある。

下記のように設定しなさい、と指示されるがValue-Domainの管理画面から設定する場合はどうするのか？
Name: _amazonses.example.com
Type: TXT
Value: <認証コード>

結論。

TXT _amazonses.example.com <認証コード>

で、認証が通りました。

SPFの設定だと v=～～ ~all とか書式があるから、なにかそういう書式が必要なのかと思って迷いました。
DNSは苦手です。

さくらのメールを使おうとしたら「550 5.7.1 Command rejected」と言われてメールを送信できなかった。vultrのせいだった。

さくらのメールボックスを借りてPEAR::Mailでメールを送信しようとしたところ、メールが送信できず困った。
PEAR::MailはMail::factoryの第２引数に渡すパラメーターで 'debug' => true を設定することでSMTPのやりとりを出力してくれる。
これでやりとりを見てみると Authentication OK という文字が見えることから、認証は成功しているようだが、そのあとすぐに「550 5.7.1 Command rejected」というメッセージがでて接続が切れていた。
なんとも不可解な動作にずっと悩んでいたが、どうもvultrというクラウドを使っていたことが原因のようだった。

こちらのブログを見つけられなかったらずっと悩んでいたかもしれない。感謝。

Vultrからメールが送れないのでSendGridを使う

このブログのリンク先の公式サイトにて、下記のメッセージを確認。

Do you allow outbound SMTP?
Outbound SMTP is blocked by default. To lift this restriction, you must contact our support team and fill out an authorization form.

しかし認証までうまくいくのは何故なのか謎すぎる。接続もできない状態であればすぐ気づいたのだけど。。。

解決策としては、やはりクラウドサービスを利用することにした。AWSは使い慣れているのでAWSのSESを使うことにした。EC2以外から使う場合は無料枠がないようなのでちょっと微妙だけれどほとんどメールなんて飛ばないだろうからいいやという判断。

Androidでリンクを強制的にChromeで開く方法

リンクを強制的にChromeで開く方法を30分くらい探しまわったところやっとこさStackOverflowで見つけた。

http://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome

とても助かります。。。

フォーマット：
<a href="intent://<URL>#Intent;scheme=http;package=com.android.chrome;end">

実例：
<a href="intent://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome#Intent;scheme=http;package=com.android.chrome;end">テスト</a>


強制的にChromeで開くのではなく、ユーザーにURLを開く方法を選択させる方法。
<a href="intent://stackoverflow.com/questions/29250152/what-is-the-intent-to-launch-any-website-link-in-google-chrome#Intent;scheme=http;action=android.intent.action.VIEW;end;">テスト</a>

Chromeでしか動かないWebアプリに飛ばす場合なんかに使いたいですね。
ちゃんと理解すると色々応用が効きそうです。

Docker を利用した Web アプリケーションのデプロイ（私の場合)

先日、「クックパッド開発者ブログ」で「Docker を利用した Web アプリケーションのデプロイ」という記事があがっていた。
僕の関わっているプロダクトでもDockerを採用していて、ほとんどデプロイの仕方が同じだった。

私の構成

クックパッドさんと異なる点としては
・Nginxもコンテナとして起動している
・UnixソケットではなくコンテナのIPを直接してアプリケーション・サーバーと繋げている
というところ。

あと環境変数の共有とかはいまのところ必要性を感じていないのでやっていない。

うちのNginxの設定はちょっとトリッキーかもしれない。
設定ファイルはerbテンプレートから出力する。変数は環境変数として持っておく。

Nginxの向き先を新しいアプリケーション・サーバーに向けるスクリプトはこんな感じだ。

# switch.sh
export WEBAPP_HOST=${1}
erb /docker/etc/nginx.conf.erb > /etc/nginx/nginx.conf
/etc/init.d/nginx reload

そしてこれがNginxの設定ファイルのテンプレートの一部

# /docker/etc/nginx.conf.erb

location / {
  proxy_pass http://<%= ENV['WEBAPP_HOST'] %>/;
}

Nginxに限らず多くの設定ファイルがerbテンプレートを使用している。
基本的に設定の変数には環境変数を使っていきたいと考えたが、多くの設定ファイルは環境変数を参照するといったことはできない。sedなどでは対応しにくいパターンもある。なのでなるべく柔軟に対応できるようにテンプレートシステムを使うことにした。erbにこだわりがあるわけではなくphpでもよかったと思う。
最初に導入したのがruby製であるfluentdの設定ファイルを作成していたときなので自然と？erbになってしまっただけだ。

実際のオペレーション方法

基本的なオペレーションはAnsibleで包んでいる。

だから新しいAPIサーバーをデプロイするには下記のようなコマンドを実行するだけでいい。(versionはコンテナ名のSuffixになる)

ansible-playbook -i hosts/production playbooks/api-server-start.yml -e "version=1"
ansible-playbook -i hosts/production playbooks/reverse-proxy-switch.yml -e "version=1"

ansible-playbookを実行するWebフロントエンドも開発済みで開発環境では既にAnsibleのコマンドを叩く必要もないところまで自動化できている。

課題

Dockerによるデプロイ体制は整ってきたが、気になっているのが修正の反映をするのにかかる時間だ。
ソースを修正して環境に反映するのには下記の手順が必要になる。

1. ソースを修正する
2. Dockerイメージをビルドする
3. docker pushする
4. docker pullする
5. イメージを起動する
6. リバースプロキシの向き先を変える

たった１行のコード修正であろうと 2～4 の手順にどうしても時間がかかってしまう。
git pullするだけで反映が終わるような仕組みも用意すべきか否か悩んでいる最中だ。