はてなブックマーク

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

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

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

この記事は スタディストアドベントカレンダー 2019 9日目の記事です。 二枠連続で投稿する機会を得ましたので、業務の中のとある取り組みについて、前後編に分けてご紹介したいと思います。 さて前編ではキャッキャウフフ会の発足の経緯と最終的なゴールの解説をしました。 後編となる今回は実装上の詰まりポイントや、キャッキャウフフ会がなぜうまく回っているのかについて、メンバーで振り返りを実施した結果についてまとめます！ と、その前にまずはゴールの再掲から。 アーキテクチャ図再掲 会の活動実績を改めて振り返ったところ、上記の流れを一通り実装しきるまでの活動としては全 3 回 開催されていました（その他にもいろいろなテーマで活動しているので、機会があったら改めてご紹介します！） というわけで各回のゴール設定とつまずきポイントについてご説明〜 第 1 回： Hello AWS World ! まずは導入

この記事は スタディストアドベントカレンダー 2019 8日目の記事です。 二枠連続で投稿する機会を得ましたので、業務の中のとある取り組みについて、前後編に分けてご紹介したいと思います。 改めましてになりますが、スタディスト開発部はSREチームに所属のおかだと申します。 今回は開発部のゲリラ的活動（？）のひとつ、 キャッキャウフフ会 について説明します。 キャッキャウフフ会とは 名前だけ聞くとただただ楽しそうなだけの会ですが、実態は至ってまじめ。 WebチームとSREチームがチームの垣根を越え、互いの知見を活かしてチーム横断的な課題をモブワークで解決する会 です。 SREチームからはハリネズミ好きのぼくが、Webチームからはペンギン好きの高橋とデグー好きの笹木が参加し、主に三人でキャッキャウフフしてます。 画像はイメージです 活動開始は基本的に18時。各々お菓子と飲み物を買って50インチの

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

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

はじめに カックさん（@kakakakakku）のブログメンタリングのメンティとなってから 1 ヶ月半が経過しました。 ブログメンタリングの最長期間は 3 ヶ月なので、今日でちょうど折返しとなります。 そこで今回は前半戦の振り返りと、後半戦に向けた意気込みのようなものをまとめておきたいと思います。8 割くらいは自分の備忘録として残すことが目的です。 ちなみにカックさんのメンタリングはめちゃ素晴らしい！でも詳細はメンタリング終了時に書く予定なので、今回はほぼ触れません。 前半戦の振り返り この記事を書いている時点では、以下のようなフローでブログ記事の投稿に取り組んでいます。 1. 書きたいテーマを思いついたらブログ用の Trello にタスクを切る ブログ用カンバン（執筆予定のタイトルにはモザイクかけてます） 上記の画像の様な感じで、大玉・中玉・小玉にわけて記事のアイデアをとりあえず起票しま

はじめに さて前回、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

さて前回 EC2 インスタンスを作成し、必要なパッケージを一通りインストールしましたね。 いきなり手を動かしてもヨクワカラナカッタので、改めて概念の予習をしておきます。 コンテナを構成する考え方 元記事では大きく分けて以下の3つがあげられていました。 ざっくり述べると、いずれもなんらかの制約を課すための技術です。 ・Isolation / Namespace （リソース空間の隔離） ・Limitation / cgroup （物理リソースの制限） ・Restriction / Capability （権限の制約） それぞれの要素技術の実態がどのようなものなのか？ 具体的な技術の解説に入る前に、まずは以下の説明をお読みください。 とある家族の物語 「あんなボロ家でまともに生きていけると思ってるのか！？本当にそう思うなら好きにしろ！今すぐ出ていけ！！！」 「言われなくたって出ていくわよこんな家

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

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