アウトプットが致命的に足りてない…！AWSのFargateやAurora Serverlessが東京リージョンに来て色々触って遊んでいるので、そのうちになんか書きます。
毎年夏になると毎日湯船にのんびりつかるようになる。38℃程度のぬるま湯に30分くらいかけて入るのがとても気持ちがいいのです。
夏のぬるま湯におすすめの入浴剤を上げておきます。
どちらも炭酸ガスが多めに含まれているので、血行がよくなり睡眠の質が上がる感じ。それに加えてメントールで体の表面はスーッとして爽快感があります。見た目のお湯も澄んだ青で涼しげなのもいい感じです。
風呂でお仕事のslackに返信している時は「本当にこれでリラックス出来てるのだろうか…」と思うこともあるが、それはそれで。
去年末くらいからずっと「2018年初頭発売開始！」と公式サイトに出続け、「2018年初頭っていつやねん！」ってずっと思っていたOculus goですが、ゴールデンウィークに入る頃に突如発売開始。
届いた。注文フォームが日本語に対応していたので、油断して届け先を日本語で書いたら、謎の英字変換されていて、よく無事に届いたなと感心しました。今販売サイト見ると、「ローマ字表記で入力してください」と注意書きがありますね。
さて、何故Oculus goを購入したのか。それは「寝っ転がって、Netflix（および、ブラウザで閲覧できる各動画配信サイト）が見られる」という使用方法に惹かれたからです。VRという言葉から今までそれほど出てこなかったこの身近な、悪い言い方をすれば志の低い体験。ここに、なんとなくVRが次のステージに上ったと個人的に思ったのです。
Virtual Reality。仮想現実と日本語では訳されたりしますが、Virtualはどちらかというと「実質的な」という意味合いが正しい単語です。「実際にはそのような形をしていないけれども、あたかも実質的にそのものであるような」というのが正しいVirtualのイメージですかね。計算機屋さんなら、Virtual Memoryを想定すると分かりやすいかも。そう考えると、今までのVRが現実世界における何かの実質的なオルタナティブであったことはそれほど無かったと思います。
で、寝っ転がって動画が見られるという話。これは紛れもなくVirtual Realityだと感じました。現実には存在しない大スクリーンを、「実質的にそのものであるように」体験できるのがOculus goによる動画視聴です。画面解像度の問題や視野角の問題もあり、まだ現実の大スクリーンには及びませんが、間違いなくそこに向けて近づいているものであると思います。今まで手に入らなかったものを、実質的に手に入れてしまえるようになる未来を、NetflixのアプリとOculus goの手軽さから感じたわけです。
ちなみに弱視の知人が、遠くのものをスマートフォンで撮影して間近で見ることで視力をカバーしていることがあるんだけども、そういう人がOculus go見たらどう見えるのかな。ちゃんと見えるなら、これは弱視の人にとっては凄いデバイスになるよね。
ちょっと身内にちょっとしたことで怒られることがあったので、反省も踏まえて。 利害関係があるところではなく、家族や友人等を怒らせてしまって謝らなければいけないときに考えたことのメモです。
怒られているときに自分が考えているのは以下のことです。
まず、起こっている相手に出来ることは基本的に謝ることしかないと思っています。ただ、自分が悪いと思ってないこと、相手が怒っているポイントと外れたところで謝っても、相手には響かないです。ですので、まずは相手が怒ってることと、その中で自分が悪いと思っていることを上げ、その点について謝ります。この際、反論したいことや自分の非ではないことについて色々言及したくなりますが、言わない方がいいです。黙って謝れという話ではなく、人と話す際に1つの話に複数のトピックを入れない方がいいと思っているからです。そうした場合、だいたいにおいて印象的な片方のトピックしか伝わりません。つまり、謝意とともに意見を述べると、反論しただけで謝意が全く伝わらないことがほとんどです。特にオンラインの文章でやりとりしているときにやりがちです。
平謝りをすべき、という話ではなく、自分の言動についてどこに非があったのか、真摯に反省をする必要があるということです。
その上で、最初のステップでは謝意を受け入れてもらうことに全力を尽くすべきです。反論したいことや、相手に要求したいことも当然あると思います。それはそれで適切に伝えるべきなのですが、相手が怒っているときには基本的に伝わらないことを理解しなくてはいけません。親しい身内間での怒りというものは、だいたい何かしらの期待を裏切られたという悲しみの感情が裏にあります。その部分を解消しないことには怒りが消えることはないので、まずは「自分は引き続き期待するに値する人である」と思ってもらうことを最優先にする必要があります。
自分の言いたいことは、相手と笑顔で会話できるようになってからで遅くないです。怒られているときには、相手の怒りを解くことに注力しましょうというお話。言いたいことがあるなら、怒りを解いた後に言った方が確実に伝わります。
最近のお仕事ではサーバーサイドのアプリケーションを伴わない静的サイトのインフラをAWSで構築することがちょくちょくあります。シンプルなサイトから、APIサーバーが別にあるようなリッチなフロントのサイトまで、内容はそれぞれですが、基本的にはCloudFrontとS3で作ることがほとんどです。
CDNと言えば、アクセス数が非常に多いような限定的なサイトで利用されることが多いイメージがありますが、自分が静的サイトを作る際はアクセス規模の大小にかかわらずCloudFrontを前段に起きます。理由の大半はHTTPS対応のためで、Googleのランキングの影響であったり、HTTP/2に対応できるなどのメリットがあるため、POST等で暗号化しなければいけない情報を送信しない場合でもHTTPSには対応すべきかと思います。HTTPS以外の理由としては、アクセス数の大小によらず同じような構成が作りたいというのも理由の一つです。アクセス数からCloudFrontを利用するかどうかの判断をしなくてもいいので、設計時に考えることが減ります。
構成はこんな感じ。CloudFrontのオリジンとして直接S3のバケットを指定できますが、自分はS3のWeb Hostingを設定したうえで、そのURLをオリジンとして指定します。リクエストパスにファイル名が指定されなかった際にindex.htmlにアクセスさせるディレクトリインデックスの機能はWebサーバーに必須ですが、CloudFrontから直接S3をオリジンにするとこの機能が使えません。特定のファイルのみCloudFront経由にする場合は特に問題ないのですが、Webサイトをまとめてホスティングする場合は困ることが多いです。/をリクエストされたら/index.htmlを返して欲しいし、/newsをリクエストされたら/news/index.htmlを返して欲しいです。これを実現するためにはS3側で単独のWebサイトとして動作して、ディレクトリインデックスの挙動をここで実現してもらう必要があるのです。
S3側に直接アクセスされないように、S3側はCloudFront以外からのアクセスは拒否したいところですが、S3へはCloudFrontの全世界にあるエッジロケーションからアクセスされるわけで、IPによるアクセス制限は不可能です。とりあえず自分はUserAgentによる制限をかけるくらいにしています。直接S3にアクセスされても、負荷がかかるわけでなければ困ることはそれほど無いので…。気になる人は追加でバケット名を推測されにくいものにすると、S3側のエンドポイントにアクセスされることはほとんど無くなるはず。だいたいこんな感じのバケットポリシー書きますかね。
{ "Id": "Policy1524134364829", "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1524134363397", "Action": [ "s3:GetObject" ], "Effect": "Allow", "Resource": "arn:aws:s3:::<バケット名>/*", "Condition": { "StringEquals": { "aws:UserAgent": "Amazon CloudFront" } }, "Principal": "*" } ] }
CloudFrontのTTLの設定ですが、静的サイトであれば更新頻度からDefault TTLを適切に設定しておけば問題は無いかと思います。S3のファイルを置き換えた後、5分くらいで更新が反映されれば良ければ、Default TTLに300秒を設定しておけばいいと思います。Minimum TTLやMaximum TTLはデフォルトのままで問題ないです。S3の設定で明示的にCache-ControlヘッダやExpiresヘッダを付与しない限りは影響しません。
HTTPSの証明書はCertificate Managerで作ります。CloudFrontで利用する場合はus-east-1リージョンで証明書を作らないとCloudFront側から認識されないので、その点だけ気をつけてください。CloudFront側ではHTTPにアクセスされたらHTTPSにリダイレクトする設定が出来るので、こちらを設定して強制的にHTTPSでのみアクセスさせるようにします。
上記の環境を作成するterraformの設定ファイルを作ったので、こちらを実行すればぽんぽんと静的サイトの環境が作れます。
自動化するに当たって、Route 53のHosted Zoneだけは手動で作る必要がある仕様にしました。同じドメインで複数のサイトを作るケースもあるので、ドメインの管理自体はterraformで管理しないようにしています。環境を削除する際にHosted Zoneごと消されると結構な事故になりそうな気もするので。
また、ステージング環境やリリース前本番環境など、IPによるアクセス制限をかけたい場合はWAFを使います。このあたりのお話も機会があれば。
今更感はあるのですが、KYASHが数ある個人間送金アプリのなかで気に入って愛用しています。 個人間送金アプリの現状に関しては以下のサイトに詳しく書いてあります。
ユーザー体験から紐解く「個人間送金」アプリの仕組みと歴史（日本編） | hajipion.com
常日頃から「俺は金が欲しい訳じゃなくて、金で買えるものが欲しいのだ」と言っているので、現金化できないというポイントはあまり気にならず、むしろ残高を使う手段がどれだけ用意されているかの方が大事でした。KYASHはアプリを利用開始した時点でVISAのバーチャルカードが作成され、KYASHで送金されたお金をそのカード経由で利用することが出来ます。現在はネット通販等に限られてしまうのですが、実店舗でも利用できるようになっていくみたいです。Amazonでお買い物するのと、モバイルSUICAのチャージが出来るので、首都圏内で生活している人の大半はそのお金の使い道には困らないと思います。
KYASHで支払いをするためにはKYASHのアプリをインストールする必要があり、割り勘が必要になった際に全員がKYASHユーザーと言うことはなかなかないので、そういった純粋な割り勘アプリとしての使い勝手は他のアプリより悪いかなと思います。paymoはアプリインストールなしに支払いできるし、LINE Payだと大体のユーザーがLINE使っているだろうし。おそらくは10人とか20人とかといった宴会みたいなものの割り勘はKYASHではあまりターゲットにしていない感じがします。
2～4人くらいで旅行に行ったときの旅費精算みたいなケースはかなりKYASH向きのシチュエーションですね。このくらいの人数なら、その場でインストールしてもらうのもそれほど難しくないし、高速道路のETCを通過したときとかガソリンスタンドで給油したときとか、その場で請求→支払いが出来るのはとても楽です。従来はレシートとっておいて旅行の終わりくらいにまとめて精算してましたから。車旅行の運転手だったり、幹事的な人に感謝の投げ銭が出来るのもいいですね。
あと、自分はMoney Forwardでお金の出入りを管理してるのですが、KYASH経由のお金の出入りもちゃんとMoney Forwardで管理できるのがとてもいいです。すべてのお金の出入りが勝手に記録されるとうれしいので、KYASH経由の送金がちゃんと記録されるのは本当にありがたいです。
「最近、あんまり現金使わなくなって、だいたいカードかSuicaで支払ってるなー」という人ほどおすすめですね。
うちの会社、社内に開発用だったりその他諸々のサーバーが結構動いているのですが、そろそろこいつらのお世話から解放されたいので、ここ1年くらいはサーバー削減を進めています。
基本的には外部のマネージドサービスに置き換えていく方針でやっています。特に落ちると困る人がいるようなヤツは優先的にやっつけようとしています。
で、そのうちの一つがnginxで実現しているリバースプロキシサーバー。こいつは社内ローカルのVMで動いてるアプリをインターネット経由でアクセスできるようにするために利用しています。クライアントチェックだったり、https通信が必要なものだったり、そういう用途で使われることが多いかな。
結論から言うと、表題通りにALBにお引っ越ししました。必要なことは以下の通り。
まず、ALB自体がVPC内に作られる訳で、それがバックエンドのローカルサーバーに接続できるというのが大前提。ですので、社内ネットワークとAWSのVPCをVPN接続で相互通信できるようにしておく必要があります。
ALBは上記VPC内に作るわけですが、ALBではホスト名やリクエストパスに応じて接続するサーバーを変えることが出来ます。正確にはリクエストの条件によってターゲットグループを選ぶことができ、ターゲットグループに実際に接続されるサーバーがぶら下がっています。
現在のnginxで実現しているリバースプロキシサーバーでは、ホスト名ベースのバーチャルホストの設定で接続するサーバーを切り替えています。ALBではターゲットグループを選ぶことルールとしてHostヘッダを利用できるため、そちらを利用して実現しました。
図にすると、とりわけ大したことしてないな…。
あとはDNS側でリバースプロキシしたいホスト名をALBに向けたら完了です。新しくリバースプロキシの設定を追加する際は以下の作業を行います。
上記の一連の作業をスクリプト化し、自動で行えるようにしておくといいかと思います。slackのbotで実現しようかしら。
これで社内のリバースプロキシサーバーを、AWSのALBというマネージドサービスに移行することに成功しました。このサーバー、設定のデプロイがgitlab-ciで行っていたり、サーバー自体が廃止予定のストレージサーバー上に構築されていたりと、なにかとサーバー削減の障壁になっていたので、これで色々サーバー削減が進みそうです。
昨日同僚とコミットログを英語で書くべきかという話になり、自分でもあんまり考えてなかったんだけど、人と話して少し整理できたのでまとめておこうかと書いてます。
まず、今自分はどうしてるかというと、基本的には英語で書くようにしています。書き始めたきっかけはなんとなくで、英語苦手だけどちょっとチャレンジしてみようというくらいのノリではじめました。
オープンソースコミュニティを見渡すと、日本のソフトウェアでも英語でかかれていることが多く、それが一般的な作法である、という程度の理解をしています。
一方で、会社内のプロジェクトで基本的に日本人しかいないのに、わざわざ英語で書く必然性はないという話もあります。コミュニケーション手段なので伝わらなければ意味がなく、わざわざ不得手な言語でやりとりする理由はない、と。
自分は、プロジェクト等で英語を採用することで著しく不利益になることが見えている、と言うことでなければ基本的に英語で書くべきかなと思ってます。
一番大きな理由は、世の中のソフトウェア開発、特にオープンソースコミュニティでは基本的にそのように行われているからです。そして、会社で採用する技術、やり方を基本的に世の中の標準に合わせ、どこでも通用するようにすべきと考えているからです。会社で優秀な人はどこに出ても優秀な人であってほしいし、優秀な人が会社にジョインしたときはその能力がすぐ活かせる場所であってほしいです。
ここ数年、国内だけで仕事していても英語を書かなければいけないという機会が増えてきてると思います。グローバルなクラウドサービスを利用する機会が増えてきているのですが、サポートとお話をしなくてはいけない場合、その言語は必然と英語になってしまいます。それもあって日常的に英語を書くということに慣れておきたいという気持ちもあります。
どう書けばいいかわからない、という人もいるかと思います。みんな同じ悩みにあたるらしく、「コミットログ 書き方」等で検索すればいろいろ記事が出てきますので、目を通すといいかと思います。
個人的に気に入った記事はこれ。コミットログの例を集めて羅列してあります。自分もコミットログの大半は「Add ...」「Modify ...」「Remove ...」「Fix ...」で始まってますね。
このあたりも。
