サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
okadato623.hatenablog.com
カックさん(@kakakakakku)のブログメンタリングのメンティとなってから3ヶ月が経過しました。 上記記事にもある通り、ブログメンタリングの最長期間は3ヶ月なので、今日が最終日となります。 というわけで今回はブログメンタリング自体の振り返りのため なぜメンティに応募したのか? 応募時の目的はどの程度達成できたのか? ブログメンタリングに対する感想 ブログというアウトプット手段に対する所感 をまとめたいと思います。ちなみに折返し時点で書いた記事はコチラ。 上記記事では How? に関してある程度の重きをおいて書きましたが、今回はほぼ触れません。 アドカレによる締切駆動執筆という特殊な手段を用いた以外、方法論についてはほぼ変わっていないので。 なぜメンティに応募したのか? きっかけは、これらのツイートでした。 #ブログメンタリング 新規ブログメンティを「数名」募集します!メンタリング開始
この記事は 個人開発 アドベントカレンダー 2019 24日目の記事です。 個人開発者の強い味方、Firebase で作ったサービスを紹介しつつ、全クリまでの軌跡をお話します! 全クリ? 個人開発者のみなさん、Firebase 使ってますか? これまでの個人開発 アドカレを拝読する限り、使っている方はそれほど多くないように見受けられましたが、とっっっても便利ですよ!! とは言えぼくもはじめて Firebase に手を出したのは今年の夏のこと。はじめて作ったのがこのブログでも何回か登場している増田ランダムというサービスで、プロトタイプができたのが7月上旬のことでした。 あれからおよそ半年。いくつかのサービスの開発を経て、いまではちょっとした規模のモノを、そこそこのスピードで作れるようになりました。 そこで今回はWebサービス開発のうえで登場する Firebase の五人衆を紹介しつつ、いかに
この記事は SIer脱出を語る アドベントカレンダー 2019 19日目の記事です。 とある独立系 SIer からWeb系スタートアップ企業に転職して約一年、この一年を振り返って思うことを徒然草したいと思います。 前置き 本題に入る前に。「SIer から Web 系へ」 だと主語があまりにも大きすぎて不適切な気がするので、自分が語らんとする境遇にマッチするよう言い換えたいと思います。 以下に述べるのは 「創業約40年の独立系中小SIer から B2B SaaS のスタートアップ」へ転職したぼく個人の考え です。 言うまでもないことですが、所属する組織や所属していた組織の公式見解は1ミクロンたりとも含みません。 また「脱出」というと「悪し」から「良し」への移行というニュアンスが含まれる気がしますが、良し悪しの話でもありません。 ぼくは前職の人々と今でもよく飲みに行ったり遊んだりしていますし、
久しぶりの個人開発サービス紹介です! この記事自体はアドカレ用の記事ではありませんが、明日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つです(写真送信画面での手間を極力省くため、認証は噛ませていませ
この記事は SREアドベントカレンダー 2019 11日目の記事です。 テック要素ゼロ・エモ全振りの内容なので、SRE以外の方にもぜひご一読いただきたいです! 【追記】 SRE とは Site Reliability Engineering の略です!詳細は弊SREチーム Mng のコチラの記事をご覧ください! 改めましてになりますが、スタディスト開発部はSREチームに所属のおかだと申します。 突然ですがSREとして働いているみなさん、月刊アフタヌーンで連載されている「フラジャイル 〜病理医岸京一郎の所見〜」というマンガをご存知でしょうか? 2016年には長瀬智也さん主演でドラマ化もされた作品です(ぼくは原作しか読んでいないのですが…) 病理医という(ちょっとマイナーな?)職業がテーマの、個人的に超イチオシのマンガです!! まずは作画をなさっている恵三朗さん(@36_Megu)の Twit
この記事は スタディストアドベントカレンダー 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 な(≒ ユーザ行動を模した)リクエストを いつの間にか!勝手に
ぼくは SRE(サイト信頼性エンジニア)という仕事をしています。 ひとことでいうと、サービスを安定して稼働させることに対してエンジニアリングによって貢献し、同時に責任を持つおしごとです。 弊社には「スタディストSRE にとってだいじなこと」という @katsuhisa__ が書いた憲法があり、「SRE は、とにかく信頼されることが重要」というフレーズから始まります。 サービスの堅牢な設計や顧客影響のある本番環境でのオペレーション、障害発生時の意思決定は、信頼できる人にしか任せられませんものね。納得です。 さて最近自分のなかで少し思うところがあり、信頼されるエンジニアになるために必要な要素について考えてみました。 テーマ的に意識高い高い系なのであんまり真面目腐るのもなぁ、という思いもあり、あいうえお作文でお届けします。 一部こじつけもありつつ、自分の中では割と腹落ちする項目にできたのではと思
はじめに カックさん(@kakakakakku)のブログメンタリングのメンティとなってから 1 ヶ月半が経過しました。 ブログメンタリングの最長期間は 3 ヶ月なので、今日でちょうど折返しとなります。 そこで今回は前半戦の振り返りと、後半戦に向けた意気込みのようなものをまとめておきたいと思います。8 割くらいは自分の備忘録として残すことが目的です。 ちなみにカックさんのメンタリングはめちゃ素晴らしい!でも詳細はメンタリング終了時に書く予定なので、今回はほぼ触れません。 前半戦の振り返り この記事を書いている時点では、以下のようなフローでブログ記事の投稿に取り組んでいます。 1. 書きたいテーマを思いついたらブログ用の Trello にタスクを切る ブログ用カンバン(執筆予定のタイトルにはモザイクかけてます) 上記の画像の様な感じで、大玉・中玉・小玉にわけて記事のアイデアをとりあえず起票しま
ダニエル・ピンク氏が執筆された、 モチベーション3.0 という書籍をご存知でしょうか。ぼくはこの本の 1 〜 6章 を何度も何度も何度も何度も繰り返し読み、そのたびに強い刺激を受けています。冗談抜きに100回以上は読んでいるでしょう。 ◇第1部 新しいオペレーティング・システム ・第1章 〈モチベーション2・0〉の盛衰 機能しなくなった〈モチベーション〉 アメとムチの勝利 互換性に関する3つの問題 ・第2章 アメとムチが(たいてい)うまくいかない7つの理由 〈モチベーション2・0〉に発生したバグ 期待以下の効果 望まないことを増やす ・第2章の補章 アメとムチがうまくいく特殊な状況 ・第3章 タイプIとタイプX 「やる気!」研究の新しい流れ/アルファベットの力/タイプIとタイプX ◇第2部 〈モチベーション3・0〉3つの要素 ・第4章 自律性〈オートノミー〉 自由に好きなように仕事をする
はじめに さて前回、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. に焦点をあて、増田ランダムが どう動いているのか? なぜその技術スタックを選んだのか? 運用のために実際どんくらいお金がかかっているのか? を赤裸々に書いていきます! ので、今回はちょっぴり技術的な内容になっています。 アーキテクチャ まずざっくりと、全体像はこーんな感じになっています。 アーキテクチャ図 それっ
はじめに マイクロサービスの文脈などでときどき登場するスキーマ駆動開発、さらにその文脈のなかで目にすることのある GraphQL をご存知でしょうか? (スキーマ駆動開発については Studyplus さんの以下の記事がとても参考になりました!) ぼくは聞いたことはある、くらいのレベルだったので、GraphQL チョットワカル 程度のレベルに到達することを目標に、概念の理解から簡単な実装まで試してみました。 今回の記事はテーマとしてはわりと技術寄りなものになっていますが、愛すべきポケモンたちに登場してもらうことで、できる限りわかりやすい内容になるよう心がけたつもりです! 肩の力を抜いてお読みいただけるとさいわいです! 前提 以下の情報はすべて GraphQL どころか REST 初学者が書いたものです。 記載内容の誤りや、より良い実装などありましたらご指摘いただけますとうれしいです! また
はじめまして! 10月1日からの3ヶ月間、「Trelloがあるから眠れない」でお馴染みの狂人(褒め言葉)、 @kakakakakku さんの #ブログメンタリング のメンティに選んでいただいた、おかだと(@okadato623) ともうします。 まずは初回投稿ということで、簡単に自己紹介を。 プロフィール画像はお気に入りのハリネズミちゃん ぼくはこんな人間です 1. スタートアップで、SREという仕事をしています! 都内にあるスタディストという会社で働いています。 (会社の開発ブログもありますので、よければチェックしてみてください(宣伝)) その前は約5年間、某 SIer で主にネットワークやインフラ系の業務を担当していました。 具体的にはIP電話のライブラリや、VPN通信システムの サーバ/クライアント 開発など。 前職の業務で一番多く書いていたのはおそらく C言語 です(!) OSI参
このページを最初にブックマークしてみませんか?
『okadato623.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く