知識の深さと広さの話
久しぶりにポエム書く！
開発者としてなにかものを作る際に自分が担当してない箇所の知識をどれくらい持つべきかと言うことをちょっと考えてみました。開発者の採用面接してる中で、自分が候補者に対してものを作る上で必要となる一通りの知見を求めていることに気づいたので、どうしてそのように考えているのか整理しようと思ったのがきっかけ。
ものを作るに当たって、うちの会社はディレクターやデザイナーなど、他の役割の人とチームを組んで、それぞれの役割を担っていくことが多く、彼ら彼女らとうまくコミュニケーションをとることがプロジェクトの質を上げていくことに繋がると思っています。で、人とうまくコミュニケーションをとる際に重要なのが共通の知識だと考えています。
仕事をすすめるにあたって、役割分担の境界ってあるじゃないですか。責任範囲と言うよりは、内容的にどの職種の人が担当するか悩ましい場所。うちの会社だと例えばHTMLやCSSのコーディングやUI系のJavaScriptの実装なんかはプロジェクトによって結構開発者がやるかデザイナーがやるかが変わってきます。画面仕様考えたり進捗管理したりみたいな仕事はディレクターの状況を見て任せたり引き取ったりとまちまちです。
そのような境界にあるような仕事内容はそれぞれの職種の人の間でコミュニケーションが頻繁に行われる箇所でもあります。その境界の仕事について、開発者とデザイナー、開発者とディレクターが共通の知識を持っていないと仕事を進めるにあたっての必要なコミュニケーションをとることは出来ません。その場合、コミュニケーションの質が下がるか、コミュニケーションコストが増大するか、その両方か、いずれかの状態に陥ってしまいます。
もちろん、そんな完璧超人みたいな人がほいほい居るわけもなく、自分が出来ているかというと全然出来ていないわけですが、大事なのはそうあるべきという姿勢なのかと思います。自分の学習、成長に「これは知らなくていいや」って線を引かない人であろうとすることが大事なのかなと思っています。
風呂の話
アウトプットが致命的に足りてない…！AWSのFargateやAurora Serverlessが東京リージョンに来て色々触って遊んでいるので、そのうちになんか書きます。
毎年夏になると毎日湯船にのんびりつかるようになる。38℃程度のぬるま湯に30分くらいかけて入るのがとても気持ちがいいのです。
夏のぬるま湯におすすめの入浴剤を上げておきます。
どちらも炭酸ガスが多めに含まれているので、血行がよくなり睡眠の質が上がる感じ。それに加えてメントールで体の表面はスーッとして爽快感があります。見た目のお湯も澄んだ青で涼しげなのもいい感じです。
風呂でお仕事のslackに返信している時は「本当にこれでリラックス出来てるのだろうか…」と思うこともあるが、それはそれで。
Oculus goが届いたんよという話
去年末くらいからずっと「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で静的サイトをさっくりと作る話
最近のお仕事ではサーバーサイドのアプリケーションを伴わない静的サイトのインフラを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がとても便利という話
今更感はあるのですが、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で支払ってるなー」という人ほどおすすめですね。
会社内のリバースプロキシサーバーをALBに置き換えた話
うちの会社、社内に開発用だったりその他諸々のサーバーが結構動いているのですが、そろそろこいつらのお世話から解放されたいので、ここ1年くらいはサーバー削減を進めています。
基本的には外部のマネージドサービスに置き換えていく方針でやっています。特に落ちると困る人がいるようなヤツは優先的にやっつけようとしています。
で、そのうちの一つがnginxで実現しているリバースプロキシサーバー。こいつは社内ローカルのVMで動いてるアプリをインターネット経由でアクセスできるようにするために利用しています。クライアントチェックだったり、https通信が必要なものだったり、そういう用途で使われることが多いかな。
結論から言うと、表題通りにALBにお引っ越ししました。必要なことは以下の通り。
まず、ALB自体がVPC内に作られる訳で、それがバックエンドのローカルサーバーに接続できるというのが大前提。ですので、社内ネットワークとAWSのVPCをVPN接続で相互通信できるようにしておく必要があります。
ALBは上記VPC内に作るわけですが、ALBではホスト名やリクエストパスに応じて接続するサーバーを変えることが出来ます。正確にはリクエストの条件によってターゲットグループを選ぶことができ、ターゲットグループに実際に接続されるサーバーがぶら下がっています。
現在のnginxで実現しているリバースプロキシサーバーでは、ホスト名ベースのバーチャルホストの設定で接続するサーバーを切り替えています。ALBではターゲットグループを選ぶことルールとしてHostヘッダを利用できるため、そちらを利用して実現しました。
図にすると、とりわけ大したことしてないな…。
あとはDNS側でリバースプロキシしたいホスト名をALBに向けたら完了です。新しくリバースプロキシの設定を追加する際は以下の作業を行います。
- ターゲットグループを作成し、追加したいサーバーのプライベートIPを設定する
- ALBに上記ターゲットグループを追加し、ルールとしてHostヘッダにアクセスさせたいFQDNを設定する
- DNSに設定したい名前がALBを向くように追記する
上記の一連の作業をスクリプト化し、自動で行えるようにしておくといいかと思います。slackのbotで実現しようかしら。
これで社内のリバースプロキシサーバーを、AWSのALBというマネージドサービスに移行することに成功しました。このサーバー、設定のデプロイがgitlab-ciで行っていたり、サーバー自体が廃止予定のストレージサーバー上に構築されていたりと、なにかとサーバー削減の障壁になっていたので、これで色々サーバー削減が進みそうです。