この記事は 個人開発 アドベントカレンダー 2019 24日目の記事です。 個人開発者の強い味方、Firebase で作ったサービスを紹介しつつ、全クリまでの軌跡をお話します！ 全クリ？ 個人開発者のみなさん、Firebase 使ってますか？ これまでの個人開発 アドカレを拝読する限り、使っている方はそれほど多くないように見受けられましたが、とっっっても便利ですよ！！ とは言えぼくもはじめて Firebase に手を出したのは今年の夏のこと。はじめて作ったのがこのブログでも何回か登場している増田ランダムというサービスで、プロトタイプができたのが7月上旬のことでした。 あれからおよそ半年。いくつかのサービスの開発を経て、いまではちょっとした規模のモノを、そこそこのスピードで作れるようになりました。 そこで今回はWebサービス開発のうえで登場する Firebase の五人衆を紹介しつつ、いかに

この記事は SIer脱出を語る アドベントカレンダー 2019 19日目の記事です。 とある独立系 SIer からWeb系スタートアップ企業に転職して約一年、この一年を振り返って思うことを徒然草したいと思います。 前置き 本題に入る前に。「SIer から Web 系へ」 だと主語があまりにも大きすぎて不適切な気がするので、自分が語らんとする境遇にマッチするよう言い換えたいと思います。 以下に述べるのは 「創業約40年の独立系中小SIer から B2B SaaS のスタートアップ」へ転職したぼく個人の考え です。 言うまでもないことですが、所属する組織や所属していた組織の公式見解は1ミクロンたりとも含みません。 また「脱出」というと「悪し」から「良し」への移行というニュアンスが含まれる気がしますが、良し悪しの話でもありません。 ぼくは前職の人々と今でもよく飲みに行ったり遊んだりしていますし、

今回の記事は完全に自分のための備忘録です。 GCP の認証スキームのひとつであるサービスアカウントの認証・認可まわりがなかなか理解し難かったため、整理のために投稿します。 Firebase の Cloud Functions 経由で Google Spreadsheet を編集することが目的でした。そのうえで、実際に採用した手順を紹介します。 サービスアカウントの使用 目的を一段階具体的に書くと、 Cloud Functions で作成したアプリケーションから Spreadsheet の Cloud API サービスを実行し、スプレッドシートに行を追加すること です。 そのためには Spreadsheet 側の Cloud API サービスに対する認証が必要であることがわかりました（そりゃそうだ。ぼくのスプレッドシートに対して誰からも勝手に書き込まれたら困るもんね） そこで今回採用したのが

この記事は Firebase アドベントカレンダー 2019 18日目の記事です。 Firebase を活用して個人開発した結婚式の写真管理Webサービスのアーキテクチャなどについて書きます！ さて前回記事になりますが、サービス自体の概要と開発の経緯についてまとめました。 今回は技術的背景の解説ということで、いきなりですが全体構成図をバーンと！ 全体構成図バーン！ 技術的には Firebase + Google Spreadsheet + Glide（というSaaS。詳細は後述） で構成しています。 以下では各要素を分類し、それぞれの役割について解説していきます。 Firebase部分 使用しているのは Firebase Hosting Cloud Functions Cloud Storage for Firebase の3つです（写真送信画面での手間を極力省くため、認証は噛ませていませ

久しぶりの個人開発サービス紹介です！ この記事自体はアドカレ用の記事ではありませんが、明日18日に控える Firebase アドベントカレンダー への布石です。 なので今回はサービスの概要を紹介し、次回の投稿で技術的な裏側のことを書く予定です！ つくったもの 一言でいうと、結婚式の写真管理をイイ感じにまとめるWebサービス です！ 先日友人の結婚披露パーティにお呼ばれした際にお披露目し、多くの出席者の方に実際に使っていただきました！ 感無量😭 用意したのは 画像送信用フォーム 送信された画像を閲覧するためのPWAアプリ（頭痛が痛い） のふたつです。画面が分かれているだけで、すべての出席者が両方にアクセスして使用します！ （PWA is ナニ？ は以下の記事をご参照ください） 画像送信用フォームは以下のようなイメージ（実際の画面ではありません。主に個人情報まわりを加工。） 画像送信用フォー

はじめに さて前回 Hipster Shop のログおよびメトリクスの監視が可能になったので、今回から少しずつ中身をみていきます！ まず実際に特定の Pod のログをみてみましょう。 すると、なぜか自分がアクセスしていない間にも定期的にログが出力されていることを確認できます。 カートの中身を管理するサービスのログ 例えば👆の gif では GetCartAsync という、（おそらく）カートの中身を確認するときに出力されるはずのログが定期的に吐かれているようですね。 いったいなぜでしょうか？ その犯人こそ今回扱うテーマ、 loadgenerator という Pod なのです！ Load（負荷） Generator（生成）という名の通り、負荷をかけるために存在する Pod です。 こやつが各サービスに対して Synthetic な（≒ ユーザ行動を模した）リクエストを いつの間にか！勝手に

ぼくは SRE（サイト信頼性エンジニア）という仕事をしています。 ひとことでいうと、サービスを安定して稼働させることに対してエンジニアリングによって貢献し、同時に責任を持つおしごとです。 弊社には「スタディストSRE にとってだいじなこと」という @katsuhisa__ が書いた憲法があり、「SRE は、とにかく信頼されることが重要」というフレーズから始まります。 サービスの堅牢な設計や顧客影響のある本番環境でのオペレーション、障害発生時の意思決定は、信頼できる人にしか任せられませんものね。納得です。 さて最近自分のなかで少し思うところがあり、信頼されるエンジニアになるために必要な要素について考えてみました。 テーマ的に意識高い高い系なのであんまり真面目腐るのもなぁ、という思いもあり、あいうえお作文でお届けします。 一部こじつけもありつつ、自分の中では割と腹落ちする項目にできたのではと思

はじめに さて前回、Hipster Shop をとりあえず起動するところまで試してみました。 adservice-56d6b86b69-ps58x 1/1 Running 0 12m cartservice-5b769fbcd-vghph 1/1 Running 0 12m checkoutservice-76cf7d66c4-9cn26 1/1 Running 0 12m currencyservice-676c45cbd8-sbndb 1/1 Running 0 12m emailservice-554cd4f969-lt5hz 1/1 Running 0 12m frontend-b8454cdfd-s7whb 1/1 Running 0 12m loadgenerator-545785998f-b78cx 1/1 Running 0 12m paymentservice-7945c

面接官「えーではまず『マイクロサービス』とはなにか、あなたなりの言葉で説明してみてください」 ぼく「アッアッ、マイクロ、アッ、マイクロサービスアッアッ、マイクロサーッアッアッ」 ※ ラッパーではなくテンパっている様子です 手に汗握る展開ですね。 マイクロサービスとはなにか。こう聞かれたときに ぼく「はい、私の考えるマイクロサービスとは（ペラペラペラペラ）」 こうなりたくはないですか！？！？ というわけで今回からしばらく マイクロサービス is ナニ？？ を勉強していきます！ はじめに なにはともあれまずは Google 先生に聞いてみましょう。 「マイクロサービス 勉強」で検索してみると、お、1ページ目から良さそうなサイトが見つかりました！！ ぼく「アッアッ、カックさアッ、ブログメンタッアッ、今週のノルマアッアッ」 閑話休題。 我が師、カックさんが書かれた上記の記事では、Sock Shop

はじめに ダニング = クルーガー効果をご存知でしょうか。 エンジニア界隈では時折目にする、下記の曲線です （引用元はこちらのツイート） 理解の浅い状況では自分の視座の低さを認識できないため 完全に理解した という過大評価状態に陥ってしまう反面、ある程度経験を積み、視座が高くなることで なんも分からん という過小評価状態に陥ってしまうという認知バイアスの一種です。 コンテナ、完全に理解した。 上記の画像を踏まえたうえで、ぼくはコンテナを完全に理解しています。 前回の記事では ECR + ECS を組合せた自動化の仕組みについて触れました。 業務でも Docker を日常利用していますし、ある程度簡単な内容であれば Dockerfile や docker-compose.yml を一息で書くこともできます。 またコンテナのメリットとしてプロセスの実行環境を隔離できるため、ひとつのホストマシン

前回、増田ランダムってなぁに？を書きましたので、今回は裏側のことを書きたいと思います！ まえおき その前に導入として、ぼくがサービス開発をするうえで大切にしている考えを3つ挙げてみます。 1. 自分が使いたいサービスであること（最重要！！！） 2. サービス開発をつうじて多くの学びを得られること 3. できるだけお金をかけずにサービス提供を続けられること（大事…） 1. については前回の記事で増田ランダムを作った経緯や理由を書きました。 今回はそれを踏まえたうえで 2. と 3. に焦点をあて、増田ランダムが どう動いているのか？ なぜその技術スタックを選んだのか？ 運用のために実際どんくらいお金がかかっているのか？ を赤裸々に書いていきます！ ので、今回はちょっぴり技術的な内容になっています。 アーキテクチャ まずざっくりと、全体像はこーんな感じになっています。 アーキテクチャ図 それっ