年初の家計見直しと目標設定

今日は一年間の家計の貯蓄と出費について夫婦で目標設定を行いました。

昨年に婚姻というものを行ってお金を適切に利用する必要ができたため、家計の管理というものについて試行錯誤しています。

やりたいこととしては

• キャッシュフローの把握
• 貯蓄額の目標設定
• 使うお金の配分の認識合わせ

という感じです。

一つ目のキャッシュフローの把握なんですが、妻の所得は会社からの給与だけですが、私の所得は一人会社からの給与と個人事業主として継続している売上があります。銀行口座とクレジットカードの口座が個人、個人事業、法人のそれぞれにあり、更に会社に残る利益なども考えると、どういうお金の動きがあってどうするのが最適なのかというのが意外と難しくなっています。

こういったことを踏まえてFP2級を(一応)持っている夫婦で昨年からやってきたことを簡単にまとめておきます。

1. 将来について話す

いつまで働くのか、子供はどうしたいか、稼げなくなる可能性は、海外で仕事をする可能性は、持ち家にしたいか、日本経済の今後はどうなるか、などなど話しておかないと前提が違ってくるのでお互いの考えを話しておくと良い気がします。

とはいえ結局はお互い「将来のことはわからない」ということで、基本的には無理しない範囲でためて、資産運用は適切にしておこう、くらいのゆるい話になっています。

2. キャッシュフロー図を作る

どういうのが正解なのかはわからないのですが、下のような図を手書きで書きました（実際には具体的な数字を書き込んでいます）。

お金のINとOUTが1つに図になることでお互いの認識にずれがなくなって個人的には良いものを作れたなと思っています。

※ 実際にはふるさと納税など他にもお金の動きがあり全く完璧では無いのでざっくり把握する程度のものです。

3. 貯蓄額目標を設定する

ある程度キャッシュフローが見えてきたら現実的な範囲で目標設定をしています。

そこまでしなくてもある程度は貯まるとは思いますが、やはりお金を貯めるには最初に別枠にしてしまうのが鉄則です。

4. 大きな出費用の積立額を決める

旅行などはたまにする大きな出費ですが何も基準がないと（私が）ついお金を使いがちなので、月額いくらかを積み立ててその中でやりくりすることで、節度ある出費におさめています。

この積立はどこかのタイミングで基本的には消費する前提で、金額内であれば贅沢をしても問題ないのでお金を使うことに罪悪感がないのも良いです。

今のところは旅行、衣服費、家財・家電という三種類の積立を行っています。

5. 残りの費用を出費に割り振る

出費はおおよそ下記のカテゴリわけです。変動費は細かくしてもそこまで意味がないのでざっくりとしたカテゴリに分けています。

• 固定費
  • 水道
  • ガス
  • 電気
  • 携帯電話
  • インターネット
  • ジム
  • お小遣い(お互いの個人的出費の目安)
• 変動費
  • 食費
  • 日用品費
  • 雑費

またここで改めて貯蓄目標や積立額を見直してバランス良い形に収めました。

雑費については妻の裁量に任せて個人的なものに使ってもよくしているのでそれなりにストレスなくお金が使えるような状態にできている気がします。

（自分は会社の経費で欲しい物（ガジェット）は買える場合が多いのでそもそもお金はほぼ使わない。）

6. 資産運用を検討する

貯蓄分についてどう運用するかですが、個人的には最低半分はリスク資産にしておきたい気持ちなので投資商品について色々と話し合って決めました。

7. 毎月の出費を管理、記録する

あとは毎月の動きを追いかけて、無理のない計画になっていないかなどを確認します。

ほぼキャッシュレス決済なので、Zaimを使って手間としては月末にスプレッドシートに入力するだけです。

毎月の動きをちゃんと追えるように少しずつ手を入れながら作っていたら残高試算表ぽい感じになって結局は複式簿記が最強なんだなという気持ちになりました。

各々の日々の出費についてはZaimを利用していますが、資産残高についてはMoneyForwardを利用するという使い分けにしています。

おわりに

共用の口座に決めた額だけ入れて残りは自分が自由にする、という考えもよくありますがそれだとどうしても部分最適になってしまいます。

お互いの収入を家庭の収入として、その配賦をお互い納得する形にできるのが全体最適であるべき姿だと思っています。（もちろんプライベートな部分もあって良いですが。）

まだちょっとずつやり方が変わってきているので、もう少し運用が落ち着いたらちゃんとやり方をまとめてみたいです。

大してまとまってなく誰に向けて書いたわけでもないですが、もし誰かの参考になれば幸いです。

2019年下半期振り返り

まだ半月残ってますが大して中身のない振り返り2019下半期ver。上半期は下記。

miyasakura.hatenablog.com

仕事

• 忙しくなった
  • 土日も何かしらやっていることが多い
  • 相変わらず工数の半分くらいはボランティアみたいなもので収入は増えない
  • そろそろ形になるのが出てくるような気配もしている
• 人を他の人や会社に紹介するようになった
  • 人をつなぐということも大事だなと思い苦手なことだけどチャレンジ中
• ちょっと作りたいプロダクトが出てきた
  • 作り始めたので来年には何かしらの結果を出したい
• プライベートが忙しかったのであまり仕事に集中できなかった面もある

技術

• Kubernetes触り始めた
• AWSで新しく触ったのは、LightSail, EKS, WorkSpacesくらい
• 久々の自宅Linuxサーバー運用

プライベート

• 入籍した
  • 結婚式を上げた
  • バリに行った
• ジムに行き始めた
  • 週1で運動する習慣
• 買ってよかったもの
  • フルワイヤレスイヤホンを買った
    • 耳に合うイヤホンが人生で初めて見つかる
  • ScanSnap FI-IX100A
    • ハンディかつWiFiというだけでここまで使うストレスが減るとは
  • 自宅用デスクトップマシン
    • 思ったより満足度が高い
• 読んだ本
  • 巨富を築く13の条件
  • イシューからはじめよ
  • ゼロ秒思考
• 見た映画
  • 天気の子
  • ジョーカー
  • わたしは光をにぎっている

まとめ

忙しさもあって自分の成長に時間を使えなかった。

来年前半も忙しそうなので、後半くらいからは落ち着けたらなと思う。

3泊5日バリ島旅行の記録

9月に18日(水)〜22日(日)で行ってきました。

少し仕事するかなーと思っていたのですが結局PCは一回も開かず。

取引先に特に何も告げずに行ったので色々迷惑がかかってしまいました。すみません。

旅行は思ったよりも楽しかったので備忘録として内容をメモ。

予約

リゾートに行こうと思い立ったのが8月末。

ダナンやグアムなどがアイディアとして出たものの雨季だったり飛行機が直前過ぎて高いのしかなかったので、HISに相談に行ったらバリで安いプランがあったのでそれに決定。

その中でホテルはSofitel Bali Nusa Dua Beach Resortというちょっと良いのにして、飛行機＋ホテル＋現地送迎で2人で29万くらい。

航空券が普通に取れるならホテル含めて自分でとった方がもうちょい安くなる価格設定だと思う。

準備

ドタバタしてたので準備は何もしてなくて飛行機の出発時間すら前日に確認したくらい。

前情報としては妻の友人からUbudは行ったほうが良いという情報だけもらった。

海外旅行用の買い物としてはコンセントの変換プラグとアネッサの日焼け止めだけ購入。

1日目

2人ともリュック1つずつの荷物だったので預ける荷物なしで行ったらチェックインのときにやや驚かれた。

成田を午前11時発で現地着が17:30くらい。

時差は1時間なので実質のフライト時間が7:30くらいあって疲れた。

現地についたら空港のATMで500,000ルピア（4000円くらい）ほど引き出してそのあとSIMを購入。

空港で買えるSIMはTelkomselとIM3というSimで前情報だとTelkomselがオススメということだったものの、IM3だと6GB／5分の通話／同じ会社だと通話し放題で100,000ルピアということで十分そうだったのでこれを選択。

これが実際に使ってみたら6GBの内訳がは午前1-6時しか使えないものが2GB、4Gが使えない一部区域のものが2GBとなっていて実質2GBしか使えないものだった。

通話は一瞬でもつながると1分単位で減ってしまうのでかけられるのは最大で5回。更に同じSIM同士でかけても通話時間が減ったので本当にUnlimitedなのかは謎。

ということでお勧めはしないSIMです。

その後HISの人と合流。

その他の人が来るのを待ってかつ他のホテルに寄ったりしたので結局ホテルに付いたら20時くらいになっていた。

こういう送迎は初めてお願いしてみたものの普通にタクシーで行けばよかったなという感想。

ついたらHISの人が気を利かせて部屋をツインからダブルにしてもらえるということで更に30分くらい待ち。

何度かまだですかね？みたいなのを聞いてたら怒ってると思われたのかAfternoon Teaのバウチャーをくれた。

ホテルは施設も部屋も接客も思った以上のクオリティ。

夕食は外に出ようかと思ってたものの、思ったより遅くなってしまったのでホテル内のビュッフェスタイルのところにすることに。

これも各国の料理がかなりの種類あったりで大満足。

夕食を取りながら2日目のプランをとりあえず買い物を色々してゆっくり過ごすということに決定。

その後は戻って部屋に戻って風呂に入って就寝。

無料である水が瓶だったのに栓抜きの場所がよくわからず2回もフロントに場所を聞いてしまった。

栓抜き

2日目

朝食も前日に夕食を食べた場所。

やはり満足度は高く、特に目の前で作ってもらえるスムージーが良かった。

朝食後はヌサドゥアエリアの浜辺を歩いて、バリコレクションでショッピング。

その後はGrab Taxiを使って移動。バリコレクションからだとGrab Taxiが使えないみたいでちょっと離れた場所でPick upしてもらった。

いくつかのショッピングモールを移動しながらTシャツ買ったりサンダル買ったり。

その中で最初のGrab Taxiの運転手がUbudへ案内してくれると言ってくれたのでお願いして、これによって翌日はUbudを回ることが決定。

ほとんど予定は立てていなかったので3日目の予定が埋まって一安心するなど。

そして更にDiscovery Shopping Mallに行ったら怪しい人に話しかけられて、もらった紙を開けるとなんと1等があたる。

内容としては、Karmaホテルの説明を1時間聞くことを条件に

• 7泊のホテルチケット
• Go Pro
• 2,000,000ルピア（約15,000円）

のいずれかがランダムでもらえるとのこと。

1等があたった。怪しい

軽くホテルについてググってそこまで危険ではなさそうだったので良いホテルを1時間見るくらいなら良いかと話を聞きに行ったら、いわゆるマルチ商法的な雰囲気の勧誘をされた。

ゴルフ会員権的な性質の商品で面白そうだったもののそのまま聞いてると4, 5時間くらいはかかりそうな雰囲気だったので1時間経ったところで無理やり切り上げる。そしたらマネージャーを呼ばれて色々言われたものの、ちょっとキレ気味に対応したら普通に商品くれて帰してもらえた。タイやドイツで無料で7泊できるらしい。

Shopping Mallに再度連れてきてもらって昼飯を食べてショッピングをしていたらいきなりアナウンスが流れてみんな慌てて外に逃げていくという光景が。

どうやら地震がおこったみたいで、こういうときに言葉がわからないとどんな危機が迫っているのかわからないのが怖い。

店員たちが中に戻っていくのを確認して再度買い物をして、ホテルに戻ったら16時くらい。

ビーチとプールを少し楽しんで、お腹が空いたので夕食に。

レストランに行っても良かったものの、人生初のルームサービスにチャレンジしてみることに。

インドネシア料理っぽいものを色々と部屋に届けてもらった。

その後はいつもどおりお酒を飲みすぎて調子に乗ってワインのボトルを頼んだりで中々のお値段になってしまった。

3日目

前日にお願いしたタクシーの運転手と朝9時にホテルで合流してUbudに向かう。

まずはUbudに行く途中でバロンダンスとやらを鑑賞。価格は100,000ルピア。

日本の歌舞伎っぽい感じで面白かった。

その後はUbudでブランコをやってRice Terraceを歩いてという王道ぽいことをやったあと昼飯を軽く食べてショッピングに。

小さい露店が大量にあるところに連れて行ってもらった。

200,000ルピアって言われたものが要らないって言ってると50,000ルピアくらいまでは余裕で下がる。

しかもそれでも普通に安めの店で買えば30,000ルピアくらいで買えたのでエンターテイメントとして割り切って楽しむところなんだなという感じだった。

個人的にはこういう騙し合いみたいなのは好きじゃないのでもっと静かに買い物したいなぁなんて思いながらそれでもいくつか物は買ってしまった。

ショッピングが終わったら別エリアのシーフードを食べれるレストランに移動。

夕日を見ながらと言っていたものの、ショッピングを楽しみすぎたせいで道の途中で完全に日が沈んでしまっていた。

目の前で生きている魚を指定してそれを調理してくれる形式で、ロブスターと謎の黄色い斑点がある魚を食べた。

魚は辛さでごまかしていたが結構臭みが強かった。

そしてホテルに戻ったら21時くらい。

3泊目の夜で最後ということでホテルにあるBeach Clubに移動。

Clubなので音楽はテンション高めの曲がかかっているものの、イメージするクラブとは違ってプールサイドでカクテルを飲んでゆっくりできる場所でとても良いものだった。

4日目

最終日なのでチェックアウトぎりぎりまでホテルを楽しむことに。

朝から海でココナッツを飲んで、ホテルに戻ってプールにあるバーでジュースを飲んでとなかなか日本ではやらないようなことができた。

チェックアウトしてから初日にもらったバウチャーでAfternoon Teaを飲んでヌサドゥアエリアを後に。

いくつかのデパートやスーパー、土産屋を移動して色々とお土産を買って、空港へ移動。

早くチェックインしてラウンジに行こうと思ったらチェックインはフライトの3時間前からしかできないようで、しかもチェックインからイミグレーションまでが込みすぎてて結局ラウンジに行くほどの時間もなかったのでそのままゲートで飛行機を待つことにした。

0:45発で定刻で日本に向かう。

5日目

8:50くらいに空港着。帰りは荷物を預けたのでそれをピックアップして9:59発の京成スカイライナーに乗って帰宅へ。

感想

• バリはセブより物価が高かった
• 英語が訛りすぎてて聞き取りづらかった
• ビーチリゾートは今まで無縁だったけど予想以上に楽しかった
• Sofitel Hotelはとても良いホテルなのに日本人も少なくて異国感をしっかりと感じれたのが良かった。英語である程度コミュニケーションを取る気があればオススメ

AWS障害の対応振り返り

本番稼働しているサービスいくつかのうち、動かなくなるものがあったので対応した振り返り。

一人で運用している程度の比較的規模が小さいものなのであくまで自分のメモ程度に。

構成

• ECS, RDS, ALB, ElastiCache, S3, SQS, CloudFormation
• RDSだけSingleAZになっていた
  • 昔は t2.micro をMultiAZにできなかったのかそれか無料枠を使うためにSingleAZにしてた気もする。

影響

• 13:30頃に外形監視のアラートから電話がかかって調査開始
• ECSのコンテナが起動していない
• ログを見ると13:10頃から2つのコンテナのうちコンテナが1つ落ちてその後起動しなくなっていた
• もう1つのコンテナはギリギリ13:30過ぎまで生きていたが13:10からすでにだいぶ不安定でユーザーはまともに利用できていなかった可能性が高い
• 顧客からの問い合わせもこのくらいから入り始める

調査対応

• コンテナが起動しない原因調査としてログを見るとRailsでMigrationが他のコンテナで行われているよ〜みたいなログが出ていた
• RDSに入ってshow processlistをするとおかしなプロセスはなさそう
• もう一回show processlistしたら帰ってこない
• とりあえず再起動
• 再起動が全然終わらないのでこれはディスクが死んだかと思ってSnapshotから復元を試みる（最新のSnapshotが12:50までだった）
• Snapshotの復元待ちの間Twitterを除くとAWSがトレンドになっていて全体の障害だと気づく
• DBの復元完了を待ちつつAWSの障害じゃしょうがないよなぁと思ってゆっくり待つ
• しばらくまったがDBの復元が完了しないので諦めるか…と思ったもののAZの障害なら復元先のAZを変えなきゃだめじゃんと気づく
• 違うAZに復元したら進んだ
• 12:50からのアクセスログからGET以外のものを抜き出してこのままスナップショットからサービス継続した場合の影響範囲を調査
• 責任者に復旧を待つかスナップショットから復元したDBを向けるかで判断を仰ぐ
• スナップショットから復元したものでいくことに決定
• DBの向き先を変えたものをDeployして復旧（CircleCIが動いていたのでいつもどおりのフローでデプロイ）
• 障害のタイミングで行ったRDSの再起動が終わったのは夜の時間帯

振り返り

• 12:50〜13:10のデータが失われてしまった
• 復旧は14:40にはできたので障害時間は2時間弱
• RDSの復旧を待っていたら10時間かかっていたので比較的影響は小さく抑えられた
• MultiAZじゃなくても良いという判断をするレベルのサービスなので20分程度のデータ損失はぎりぎり許容範囲だったと思う
• 今後はMultiAZにします…

ECSで動いているIP制限ありのサービスをLet's EncryptでSSL化

シングルサーバーで動かすちょっとした社内向けサービスの依頼があったのでサクッと作ってAWS上にECSを使ってデプロイしたんですが、さすがにhttpsにしてほしいという話になりました。

ALB配置すればいいだけなんですがそのために毎月2000円も払うほどのものでもないので簡単にhttps化できないものかと考えました。

シングルサーバーでDockerをhttps化するといえば nginx-proxy + letsencrypt-nginx-proxy-companion の組み合わせが王道かなと思っているのですが、社内IPにアクセスを閉じているためhttp-01の認証方式が使えません。

どうしたものかと少し悩んだのですが、letsencrypt-nginx-proxy-companionを書き換えて dns-01 に対応させてしまうことにしました。

やったこと

1. letsencrypt-nginx-proxy-companionをdns-01に対応させる

GitHubのリポジトリが GitHub - JrCs/docker-letsencrypt-nginx-proxy-companion: LetsEncrypt companion container for nginx-proxy これなんですが、中を見ると simp_le というLet's Encryptのクライアントを使っているようです。これはhttp-01の方式にしか対応していなさそうなので、これを certbot + certbot-dns-route53 プラグインという構成に変更します。

やり方としては上記のリポジトリをフォークしてソースコード読んでそれっぽく対応させます。simp_le から certbot への入れ替えればOKかなと思ったのですが、証明書や鍵の保存場所が異なるのでそこも nginx-proxy 側のソースを読みつつ適切なファイル名でコピーしてあげる必要がありました。

Use dns-01 instead of http-01 · kenjimiyao/docker-letsencrypt-nginx-proxy-companion@59514cb · GitHub

ちゃんとやってると大変なので、かなり適当です。

これを dockerhub に push します。（機密情報は無いのでパブリックリポジトリで問題なし）

2. docker-composeで動かしてみる

いきなりECSだと大変なので適当にEC2サーバーを作って実行してうまく動くことを確認します。

まずEC2のInstance Roleには Route 53の操作権限が必要です。

route53:ListHostedZones
route53:GetChange
route53:ChangeResourceRecordSets

そしてdocker-compose.ymlを作成します。

nginxの後ろで動くアプリケーションが必要ですが、すぐに動くサーバーアプリケーションが思いつかなかったのでこれも謎に作りました。

FROM python:3.7.4-alpine

EXPOSE 3000
CMD ["python", "-m", "http.server", "3000"]

で 色々試しながら docker-compose は下記のような感じに。複数ファイルに分けるパターンもあるようですがひとまず1ファイルで。

docker-composeのバージョンが2の例が多くて少し悩みました（3だとvolumes_fromが使えない）

version: '3'
services:
  app:
    image: kenjimiyao/hello-world
    ports:
      - 3000:3000
    environment:
      VIRTUAL_HOST: supertest.example.com
      LETSENCRYPT_HOST: supertest.example.com
      LETSENCRYPT_EMAIL: asdf@example.com

  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./certs:/etc/nginx/certs:ro
      - proxy:/etc/nginx/vhost.d
      - proxy:/usr/share/nginx/html
    restart: always
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy"

  letsencrypt:
    image: kenjimiyao/docker-letsencrypt-nginx-proxy-companion
    container_name: letsencrypt
    depends_on:
      - nginx-proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./certs:/etc/nginx/certs:rw
      - ./letsencrypt:/etc/letsencrypt:rw
      - proxy:/etc/nginx/vhost.d
      - proxy:/usr/share/nginx/html
    restart: always

volumes:
  proxy:

3. ECSに対応させる

そのままecs-cliでデプロイもできるみたいですが私は基本的に CloudFormation を使う人なのでCloudFormationのテンプレートにします。

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      TaskRoleArn: !Ref TaskRole
      Volumes:
        - Name: volume-1
          Host:
            SourcePath: '/var/run/docker.sock'
        - Name: volume-2
          Host:
            SourcePath: '/opt/certs'
        - Name: volume-3
          Host:
            SourcePath: '/opt/letsencrypt'
        - Name: proxy
      ContainerDefinitions:

        - Name: nginx-proxy
          Essential: 'true'
          Image: jwilder/nginx-proxy
          PortMappings:
            - ContainerPort: 443
              HostPort: 443
          MemoryReservation: 100
          Memory: 100
          MountPoints:
            - ReadOnly: true
              ContainerPath: /tmp/docker.sock
              SourceVolume: volume-1
            - ReadOnly: true
              ContainerPath: /etc/nginx/certs
              SourceVolume: volume-2
            - ReadOnly: false
              ContainerPath: /etc/nginx/vhost.d
              SourceVolume: proxy
            - ReadOnly: false
              ContainerPath: /usr/share/nginx/html
              SourceVolume: proxy
          DockerLabels:
            "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy": "true"
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: !Ref LogGroup
              awslogs-region: !Ref 'AWS::Region'
              awslogs-stream-prefix: 'nginx-proxy'

        - Name: letsencrypt
          DependsOn:
            - Condition: 'START'
              ContainerName: nginx-proxy
          Essential: 'true'
          Image: kenjimiyao/docker-letsencrypt-nginx-proxy-companion
          MemoryReservation: 100
          Memory: 100
          MountPoints:
            - ReadOnly: true
              ContainerPath: /var/run/docker.sock
              SourceVolume: volume-1
            - ReadOnly: false
              ContainerPath: /etc/nginx/certs
              SourceVolume: volume-2
            - ReadOnly: false
              ContainerPath: /etc/letsencrypt
              SourceVolume: volume-3
            - ReadOnly: false
              ContainerPath: /etc/nginx/vhost.d
              SourceVolume: proxy
            - ReadOnly: false
              ContainerPath: /usr/share/nginx/html
              SourceVolume: proxy
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: !Ref LogGroup
              awslogs-region: !Ref 'AWS::Region'
              awslogs-stream-prefix: 'letsencrypt'

        - Name: app
          Essential: 'true'
          Image: kenjimiyao/hello-world
          MemoryReservation: 300
          Memory: 300
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: !Ref LogGroup
              awslogs-region: !Ref 'AWS::Region'
              awslogs-stream-prefix: 'app'
          PortMappings:
            - ContainerPort: 8080
              HostPort: 8080
          Environment:
            - Name: BUILD_NUMBER
              Value: !Ref Build
            - Name: DATABASE_URL
              Value: !Ref DatabaseUrl
            - Name: VIRTUAL_HOST
              Value: supertest.example.com
            - Name: LETSENCRYPT_HOST
              Value: supertest.example.com
            - Name: LETSENCRYPT_EMAIL
              Value: supertest@example.com

  TaskRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: [ecs-tasks.amazonaws.com]
            Action: ['sts:AssumeRole']
      Path: /
      Policies:
        - PolicyName: ecs-execution-policy
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action:
                  - 'ecr:GetAuthorizationToken'
                  - 'ecr:BatchCheckLayerAvailability'
                  - 'ecr:GetDownloadUrlForLayer'
                  - 'ecr:BatchGetImage'
                  - 'logs:CreateLogStream'
                  - 'logs:PutLogEvents'
                  - 'route53:ListHostedZones'
                  - 'route53:GetChange'
                  - 'route53:ChangeResourceRecordSets'
                Resource: '*'

以上でhttpsアクセスができるようになりました。

これが正しい方針かと言われると自信は無いというか普通ならALB使う気がしますが、ちょっとやってみたかったのでLet's Encryptにチャレンジしてみました。

一応永続化してますが、Taskがそれほど落ちない前提であれば永続化しなくても大丈夫だと思うのでFargateも対応できるんじゃないかなと思っています。

こういったことならDockerを使うんじゃなくて普通にサーバーを立てたほうが早かったりするんですが、これから自分が作るサービスはとにかく通常のサーバー管理をしたくないのでこういう知見を自分の中に貯めていきたいなと思います。

Yahoo!スコアの開示請求をしてみた

やや乗り遅れましたが話題のYahoo!スコアの開示請求をやってみました。 少し面倒ですが、かかったお金は開示請求書の送料のみでした。

流れ

サポートからのレスポンスは非常に早い印象でした。こういうことでサービスへの印象は良くなるのでサポートの品質は大事ですね。

• 7/13(土) お問合せフォームから問い合わせ
• 7/15(月) 同意事項などの詳細情報がサポートからメールで返信されてくる
• 7/17(水) こちらから開示請求依頼メールを返信
• 7/17(水) 開示請求のやり方についてのメールが来る
• 7/20(土) 開示請求書を送付
• 7/23(火) 請求書の到着連絡メールが来る
• 7/25(木) 発送連絡が来る
• 7/27(金) 本人限定受取郵便の通知が届く

あとは郵便局に連絡して受け取りで完了です。

結果

488/900 でした。Yahooサービスの利用頻度が大きく関わってくるようです。最近はあまり使っていないので高くは出ないですね。

スコアが一番高いのはYahooでの検索回数で、リアルタイム検索をいつも使っているのでそれによって高くなっているようです。

スコアの項目について

叩かれやすいYahooとあって個人情報の保護という観点ではかなり気を使ってる印象です。

これくらいであれば提供しても比較的安心できるかなと思います。

初心者からフルスタックのソフトウェアエンジニアになるには

はじめに

自分自身では「ソフトウェアエンジニア」とだけ名乗ってるんですが、他人に自分を紹介してもらうときに「フルスタックエンジニア」とか「なんでもできるエンジニア」とかでざっくりと表現してもらうことが増えてきました。

そんな中、若者に質問されるのがどうやって技術を身につけられるかということです。

これまでは「誠実に目の前の仕事に取り組むのが一番の近道だよ」と答えて来ましたが、これは一定の真実ではあるんですがそれだけで良いかというとそうじゃない気はします。

ということで、若者がこれから何でもできるエンジニアを目指そうとするならこうすれば良いんじゃないかなというのを言語化してみました。

1. 基礎知識を身に付ける

応用情報技術者試験レベルの知識を身に付ける

身につけるべき知識は死ぬほどあるんですが、最低限かつ体系的にまとまってるのは応用情報の試験かと思います。意外とこのレベルの内容もわからずにプログラミングスクールを出ただけで基礎力は身についていると認識している人もいるのでまずはエンジニアならこのレベルの試験は軽く通ってほしいなと思います。

高校数学の復習をする

フルスタックと思われるには「これできる？」に対して迷わず「できます」といえる必要がありますが、難しすぎてできませんでした、とならないようにしたいです。

sin, cos, tan, atanあたりはなんだかんだ使う機会ありますよね。機械学習とかの方面であれば線形代数も必須だと思います。大学の範囲だと偏微分くらいは理解しておいたほうが良いかも。

英語を学ぶ

最近エラーメッセージをスタックトレースも含めてGoogle翻訳にかけてエラーの内容がわからないと言っている新人を見たときは衝撃でした。

英語は読み書きは最低限できないと成長速度がどうしても遅くなってしまいます。

アルゴリズムを学ぶ、実装する

複雑なアルゴリズムを覚える必要は（Googleの入社試験を受けない限り）ないと思いますが、ある程度複雑なロジックを理解して実装する力は必要なのでその勉強として本一冊分くらいはアルゴリズムの勉強はしておいて損はありません。

Apple Payの実装とかOAuthの実装とかもいざやることになったときに適当に実装してしまうと7payのような話にもなるかもしれません。（自分は課金周りの実装をミスったことがあるので大きなことは言えないですが、、、）

2. 技術を身に付ける

Webサービスを自宅サーバーでホストしてみる

PCを自分で組み立てて、その上で自分で開発したWebサービス(todoアプリでも何でも)をホスティングしてみましょう。ハードウェア、OS、Webサーバーなど広い知識を身につけることができます。

ちょっとデザインにこだわればPhotoShopなども使うことになるでしょう。

はじめのうちはググった内容を実行するだけで何をやっているかわからないと思いますが、4〜5回もやればだんだんと一つ一つの操作の意味がわかってくると思います。

Webサービスをクラウドサービスでホストしてみる

なんだかんだ今はクラウドの知識は必須だと思うので、まずは一番王道なWebサービスのホスティングをクラウドでやってみましょう。

クライアントアプリを作る

Webサービスとはまた一つ感覚が異なるのがクライアントアプリケーションです。

Android/iOS/Mac/Windowsなんでも良いですが、いくつかのプラットフォームに対して実装してみると様々な知見が得られると思います。

作ったサービスやアプリを世の中に出す

マーケティングやカスタマーサポートの感覚を身につけるのも重要です。

自信作がクソアプリだという評価をつけられてもヘコまない精神を身につけることもできます。

得意言語を作る

ソフトウェアエンジニアとしてはインフラからインターネット一般の知識まで広い知見が必要ですが、やはり競争力の源泉はプログラミングの能力です。

一つの言語をある程度極めれば他の言語もすぐに使えるようになるので、まずは好きな言語を人に語れるくらい極めて見るのが良いでしょう。

3. 開発スタイルを身に付ける

ウォーターフォール開発を実践する

大規模システムを作るときは日本ではウォーターフォールがほとんどです。

やってもいないのにディスるのは頂けないですし、ちゃんとやった人であればウォーターフォールそれ自体をディスる人はいないでしょう。要は適材適所です。

SIerで学んだプロジェクトマネージメントはアジャイル開発を基本としている今でも周りの人よりもうまくこなすことができている一因だと思っています。

アジャイル開発を実践する

スクラムでなくてもそれ以外でも、ちゃんとしたアジャイル開発を学んで実践しましょう。

体系立てられたアジャイル手法があるのに最初から崩したスタイルでやる人たちもいますが、まずは教科書通りにやってみたいところです。

マネージメントをやってみる

開発にしか興味がなくても、一度は10人〜のチームのリーダーとして働いたほうが視野も広くなり、どのような開発チームに入ってもマネージャーの視点で動くことができるようになります。

複数の開発スタイルを経験するためには複数の会社で働く必要がありますが、あまりにジョブホップをしているとあくまで開発者のポジションに留まってしまって、マネージメントをする経験がなくなってしまうので注意です。

4. 技術に親しむ

家でも仕事のための勉強をするのか、というのは議論によく上がりますが、専門職というのは常に専門知識をアップデートし続けてこそ成り立ちます。医者や弁護士が大学時代の知識だけで仕事してても困りますよね。

技術ニュースを読む

はてぶのテクノロジーカテゴリを追うでも良いですし、TechCrunchの記事を読むでも良いのですが、日常的にニュースに触れると少なくとも単語単位ではトレンドを追えるので世の中の流れに置いていかれずに済みます。

技術について議論する

技術がわかる同僚、友人と様々なことについてディスカッションしましょう。

新しい知識を得られたり、話すことで自分の理解が深まったりといい事ずくめです。

まとめ

各論ではDDDのような開発手法やMVCフレームワーク、関数型言語の知識など多くの人が必須だという知識は多々あるでしょう。しかしそれらを全て網羅するとそもそも時間が足りません。

「なんでもできる」と思われてても結局は「捨て方がうまい」くらいなのかもしれません。

何を捨てて何を活かすかというと、まずはここに書いてある内容くらいが自分的にはバランス感がある人材かなと思います。

ある程度基礎力ができると知識の吸収速度も上がるので、あとはとにかく色々やって経験したり本を読んで勉強したりで個別の知識を学んでいけばより良いエンジニアになれると思います。

そもそもフルスタックエンジニアを目指すべきなのか

なんでもできますというだけのエンジニアは実は市場価値が低いです。

お金がある会社は各技術要素に対して個々に専門的な人材を雇います。「なんでもできる」という人材を雇うのは各領域に対しての専門人材を雇う余裕がない企業ということなので、安い給料でしか仕事はできません。

技術の幅が広くても個人で実現できるものは小さく、多くの仕事は複数人で実現することになります。技術が一番わかっていても数十人をまとめる力がなければリーダーにはなれませんから、技術の素養が多少足りなくてもマネージメント能力の高い人間が上に行くことになります。

ということでどの仕事にも言えることですが何でも屋さんの立ち位置は実はすごく微妙です。

個人としてはフルスタックというワード自体は自分で名乗っているわけでもなく他の人から言われるだけなので良いのですが、結局は自分の売りというものがないとなかなか市場価値を上げられません。

私の場合は中学から20年以上プログラミングをやってきているので結局は設計力や開発のスピードが売りになっています。

それ以外はその開発力をサポートするための補助的なツールなのかなと今は思っています。

なので若者はまずは幅広く経験しながらも、その中で自分の好きな分野を見つけて専門性を伸ばしていくのが良いかもしれません。