Amazonのミーティングはとても奇妙な形で行われることが多い - ミーティングの最初にドキュメントを参加者が黙読するのだ。議論は全員が読み終わったことを確認してからスタートする。基本的に文章を読まずにいきなり発言し出したりということは許されない。大人数が一つの部屋に集まり、一つの文章を黙って読む姿は結構シュールである。 私はこの奇妙なミーティングをする会社に7年ほど勤めていた。こういった環境で生き残るには人に読ませる、よいドキュメントを書かねばならない。しかもアメリカで働いているのだから当然英語で書く必要がある。しかしながら私は帰国子女でもなく、特段英語が得意というわけでもない。最初の頃に書いたドキュメントは複数人にレビューされていつも真っ赤っかになっていて、そのマークアップの量を見ては鬱々としたものである。が、小さな子供とVisa問題を抱えて異国の地でクビになるわけにもいかない。英語弱

tl;dr 依存パッケージのダウンロードは最初に実行しよう マルチステージビルドは必須と覚えておこう RUN --mount=type=cache を使おう（でも BuildKit を使えるかは確認して！） pnpm fetch も期待大 はじめに みなさん，Docker を使って開発するときに依存パッケージのダウンロードをずっと待ち続けた経験はありませんか？「依存パッケージの追加なんて頻繁に発生しないし，我慢しよう…」と妥協している方も多いでしょう． 頻繁に発生しない？本当にそうですか？ 追加ではなくても依存パッケージの更新なんてよく発生するし，ベースイメージを更新することもあります．その度に全部ダウンロードし直しなんて堪ったもんじゃありません．モバイル回線だったら一瞬でギガがなくなっちゃいますよ！ ということで，この記事ではキャッシュを活用して依存パッケージのダウンロードが何度も発生し

実は今年はこのブログを開設してからなんと10年目だったらしく、2年以上放ったらかしだった当ブログではありますが、今までお世話になった人たちへ、そして最近仲良くなった人たちに、あとこれから仲良くなる人達に向けて、ちょっとこの10年を振り返りつつ、僕が何をしていて何がしたいのかを一度ちゃんとと書いておこうと思い、とりあえず筆を取ることにしました。 ちなみに最近別でPodcastをしており、そちらも丁度1年目（50本目）ということもあり、これらの活動をきっかけに知り合った方も沢山居るので尚更こういうの書かないとなってノリです。 2年もブランクがあると、もはや書き方を忘れてる自分がいて早速絶望を感じていますが、とりあえずいってみましょー！ セナって誰か このブログが多くの人に見られていたのは2014年から2017年くらいまでということもあり、恐らく今見てくれた方や知り合いになった方は僕のことをそも

This repository contains the codes of the Backend Master Class course by TECH SCHOOL. You can also find it on Udemy at this link. And don't hesitate to join Tech School's Discord group to chat directly with me and other students. In this course, you will learn step-by-step how to design, develop and deploy a backend web service from scratch. I believe the best way to learn programming is to build

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

※取りに行く話なのでまだ取ってません。 界隈ではコンピュータサイエンス（以下CS）を学ぶことが流行っていますが、これはとあるパパのとある一例です。どなたかの参考になれば。 こちらの通り申請致しました。 https://t.co/IDkVJAWjc2— Y (@wbspry) 2021年2月13日 誰？ 事の経緯 なぜ大学でCS・数学を学びたいのか CS系学位を課す外資大企業たち CSできるマンへの憧れ 立ちはだかる数学の壁 dynamicなものよりstaticなもの ところで、CSって何？ 選択肢と選択 なぜUoPeopleではなかったか 週次の人巻き込み課題が大変そう 単位移行が可能なのか（※当時は）よくわからなかった とはいえ なぜ帝京理工通信ではなかったか なぜJAISTではなかったか 学位授与機構との出会い 新しい学士への途（単位累積加算制度）とは 学位取得までの流れ そして単位集

マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その

課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

本書は、Micro Frontends Architecture Patternsというタイトルを付けていますが、モノリスからJAMstack、Micro Frontendsまで、Webフロントエンドを包括した様々なアーキテクチャパターンの詳細を体系的に紹介しています。 ソフトウェアとしてのアーキテクチャ全体を俯瞰し、他のシステムとのやりとりを設計するような考え方が役に立つことは多いです。フロントエンド観点で、様々なアーキテクチャパターンをまとめることで、Web開発の助けになればと考えています。 また、アーキテクチャの歴史と変遷を知ることで「Micro Frontends」への理解を深めることができると筆者は考えました。Micro FrontendsはThoughtWorksのTechnology RadarではすでにADOPTとなり、海外で多くの事例が存在します。Micro Fronte

この記事は Go 2 Advent Calendar 14日目の穴埋め記事です。 はじめに @okdyy75 さんによる Go 5 Advent Calendar 14日目の の記事「だから僕はGo言語を辞めた」 が「ベンチマークっていうのはこうやるんだよ」というのを説明するために反面教師的な意味で良い教材だと思ったので、反証記事を書きたいと思います。 ベンチマークを取りながらコードを改善して、最終的にGoは遅くないからやめる必要はないということ、そして、なぜ遅いという結論になってしまったのかを掘り下げていきたいと思います。 下準備 幸いなことに、ベンチマークのソースコードがGitHubにある ので、こちらを実行しながら問題点を改善していきましょう。 ちゃんとコードが上がっているのは素晴らしいですね！ 一方で、元記事には測定環境が明記されていませんでしたので、同じ環境で測定することはできま

data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL

こんにちは、ISC 1年 IPFactory 所属の morioka12 です。 この記事は IPFactory Advent Calendar 2020 の10日目の分になります。 IPFactory という技術サークルについては、こちらを参照ください。 本記事の最後に記載されている余談でも IPFactory の詳細を紹介しています。 はてなブログに投稿しました #はてなブログ IPFactory Advent Calendar 2020 の10日目の記事を書きました#JWT #security セキュリティ視点からの JWT 入門 - blog of morioka12https://t.co/g1MYe77hAF — morioka12 (@scgajge12) 2020年12月10日 普段は Web Security や Cloud Security 、バグバウンティなどを興味分

こんにちは、タイミーデリバリー開発チームの宮城です。 この記事はJP_Stripes Advent Calendar 2020の10日目の記事です。 タイミーデリバリーはデリバリーを頼みたい人が安い価格で注文でき、飲食店も安い利用料で注文を受けられるデリバリープラットフォームです。 その決済機能として今回はStripeを導入しました。 この記事では、決済基盤の技術選定/Stripeを活用したクレジットカード決済と各事業者への入金までの流れ/Railsでの具体的な実装内容 をそれぞれタイミーデリバリーでの活用事例として紹介します。 導入にあたった背景 決済基盤の技術選定基準 Stripeでできること PCI DSSについて 利用したStripeの機能 Custom Account Stripe SDKを利用したRails/Swiftでの実装内容 PaymentIntent Customer

この記事は はんドンクラブアドベントカレンダー 2日目の記事です。なお筆者は，Mastodonサーバの一つ「はんドンクラブ」の管理人で，本アドベントカレンダーの主宰です。 最近，複数回説明した事柄をもう一回別の人に説明するのがめんどくさくなってきて，「この記事読んどいて」と言うために記事を書くことがあります。今回もそれに漏れず，携帯電話・スマートフォン用の次世代通信システムである5Gについて，なぜか私がよく聞かれることを説明する記事とします。一つの読み物として読んでいただければ幸いです。 5Gって？ ご存じの通り，5Gの特徴はURLLC・eMBB・mMTCです。 といっても通じない方が多いですよね。でも一応，これが正式な言い方なんです。それぞれ， 超低遅延*1 ＝ URLLC（Ultra-Reliable and Low Latency Communications） 超高速 ＝ eMBB

自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

要約 Docker in Docker な CI では、以下の Docker Build をオススメします。 スクリプト Buildx を使う Buildx を使えないならば、BuildKit + –cache-fromオプションを使う Dockerfile ステージ間の依存を弱くする(依存インストールとビルドを分ける) 中間イメージも軽量化する 不要なキャッシュを削除 ファイル変更差分によりますが、これらにより最大 1/3 へビルド時間を短縮しました。 はじめに 『ホットペッパービューティー』美容クリニックのカウンセリング予約サービスのバックエンドを担当している安達です。 新卒として 4 月に入社して、5 月中旬に美容クリニックに配属され、すでに約 4 ヶ月が過ぎました。 まず、チーム内で自分が活躍できる庭を作りたかったため Docker について詳しくなろうと思いました。 そこで、CI

これは マンション光配線の方式別になぜ速度が出ないのか？を解説する資料 配線方式によって天地の差が出るマンションタイプの回線を、できる限り快適に利用したい人向けの情報 付随情報として、J:COMとかのCATVの話や、UCOM光とかBB4Uとかのマンション共有インターネットの話も載せておく (注意) 一部例外はあります。例外につきましては、「そういうこともある」だと思って下さい。 想定すべき前提知識 フレッツ光やauひかりの分岐数は方式に関わらず 1収容 あたり 最大で 32 回線 となる 光配線方式はGE-PONの仕様上、どの事業者でも最大分岐数は32分岐となる NUROの採用するG-PONは規格上の最大分岐数は64~254となっているが、実際の運用は資料がないのでわかりません NTT の シェアドアクセスを利用している以上、8以上、8の倍数(8, 16, 24, 32, .... )分岐

Amazon で長年にわたってサービスを構築してきた中で、新しいサービスを構築するけれども、このサービスはそのリクエストを満たすためにいくつかのネットワーク呼び出しを行う必要があるというシナリオのさまざまなバージョンを経験してきました。おそらく、この呼び出しは、リレーショナルデータベース、Amazon DynamoDB などの AWS のサービス、または別の内部サービスに対するものです。単純なテストまたは低リクエストレートでは、サービスはうまく機能しますが、問題もあることにも気付きました。問題は、この他のサービスへの呼び出しが遅いこと、または呼び出し量が増えるとデータベースのスケールアウトに費用がかかることです。また、多くのリクエストが同じダウンストリームリソースまたは同じクエリ結果を使用していることに気づいたため、このデータをキャッシュすることが問題の解決策になると考えています。キャッシ

攻撃に立ち向かうイヌさんThe English version is available here. タイトル訂正: 「自作サービス『に』→『が』DDoS攻撃された話」「それはDDoSではない」という指摘に関して末尾に追記 (6/18)SaaSを開発していると本当にいろんな事が起こります。それらは時に開発者に喜びや悲しみ、怒り、感謝、落胆や興奮をくれます。思い返してみれば結局はみんないい思い出になるものです。先週末に、拙作の小さなウェブサービスがDDoS攻撃を受けました。言わずもがな、悪い出来事です。本稿ではこの事故がどんなものだったのか、どうやって対処したのかについてお話します。 どうもTAKUYAです。僕はInkdropというクロスプラットフォームなMarkdownノートアプリを独りで3年以上開発・運用しています。ユーザ数2万人以下のとてもニッチなSaaSで、僕はこのサービスで生計を立