Kafka のパーティションとの付き合い方 - Repro Tech Blog
Platform Team/Core Unit の村上です。 Repro は分散メッセージングシステムである Kafka を用いたイベント駆動アーキテクチャで構築されています。 私が所属している Core Unit は、Repro のコアとなる基盤を支えているチームであり、Kafka のストリームアプリケーションを日常的に扱っています。 私は Repro に入ってから Kafka のストリームアプリケーションを触るようになりましたが、一般的な Web API や Worker アプリケーションの実装とは異なるマインドセットが求められると感じます。 その中で特に重要だと考えているのが Kafka のパーティションに関する理解です。 Kafka のパーティションは分散処理を扱う上で重要な概念であり、ここの理解が浅いまま実装を進めていくと、後になってトラブルに見舞われることがあります。私自身 K
Reproで実感したスケーラブルな世界の入口 - Repro Tech Blog
こんにちは。新規事業部門でエンジニアをやっている重本です。2025年5月にReproへ入社し、この記事を書いている今でちょうど3ヶ月が経ちました。 わずか3ヶ月ながらも、プロダクトの一部を担う責任や、技術的に解くべき課題の難しさ、そしてそれらを支える人や文化に、日々驚きと学びの連続でした。入社を検討している方や、同じような課題意識を持つ方の参考になればと思い、この記事を書くことにしました。 入社経緯 私はこれまでSESを中心に、複数の会社・案件で開発を経験してきました。ある程度のアプリケーションは作れるようになってきた反面、「この先、エンジニアとして何を積み上げていけば良いのか？」という漠然とした悩みもありました。 そんな中、Reproの面談で率直にその悩みを話してみたところ、「じゃあウチで修行してみる？」という一言で話が進みました。 「修行」と聞くと少しストイックな印象もありますが、私に
"開発者体験が良い" とはどういうことか、あるいは例のランキングの使いかた - たごもりすメモ
TL;DR 「例のランキング」と言われるようになってしまったエンジニアが選ぶ"開発者体験が良い"イメージのある企業ランキングですが、これをどう解釈すればいいか、企業側、採用側としてどう考えればいいかについて、自分なりの意見があるけどXの話とかであまり見ないので書いてみようと思った。 開発者体験とは、本質として「開発者個人の期待と現実のギャップ」である しかし開発者個人の期待というものは人によって千差万別だから、 "開発者体験が良い" は人によって求めるものが違いすぎているし、外部の人が評価できるものでもない ただし 「"開発者体験が良さそう"というイメージ」については、期待と現実のギャップをコントロールできているように外部に見えている、という指標として有用かもしれない Disclosure 筆者はさくらインターネット株式会社で勤務しており、かつ、採用関連の活動にはこの1年弱のあいだ、それな
gopkg.in/yaml のアーカイブと乗換先やメンテナンス継承議論 | おそらくはそれさえも平凡な日々
この話は、goccy/go-yaml 作者のgoccyさんと、YAMLの話を…止めない!という私のポッドキャストエピソードでも話した内容だが、口頭では説明が難しかったり、上手くまとまってなかった部分もあったので、補足的にエントリーを書いた。ポッドキャストでは裏話的な話やgoccyさんの生の意見も聞けるので、そちらも是非聞いてみて欲しい。 GoのYAMLライブラリとそのアーカイブ事件 GoのメジャーなYAMLライブラリには大きく以下の2つがある。 gopkg.in/yaml.v3 (gopkg.in/yaml) 7k stars github.com/go-yaml/yaml が開発リポジトリ github.com/goccy/go-yaml (goccy/go-yaml) 1.7k stars 他にもYAMLライブラリはいくつかあるが、実態は、gopkg.in/yaml のラッパーであるこ
スタートアップで働いていたときに心がけていたこと。反省含む - dackdive's blog
これは何か 今月末で今の職場を離れることになったので、ふりかえりも兼ねて。 これまでの経歴的にスタートアップで働くことが多かったので、前職に限らずこれまでのキャリアをふりかえってみて、日頃どんなことに気をつけながら働いていたか、あるいはこれまでの人生で「もっとこうすりゃよかった」みたいなしくじりを整理したもの。 前職を辞める前に社内でLTぽく話したのを少し改変している。 前提：私はこういう性格 自己肯定感が低い 今やってる仕事は別に誰でもできるよな〜とか思っちゃう ので、俺すごくね？って滅多に思わないし、こんなんやりましたでドヤ！みたいな発信が苦手 他者とのコミュニケーションに必要以上に気を使いがち Slackの投稿文は何回も何回も考えてようやく発信してる @全社all メンションとか極力打ちたくない おしながき 自分が気持ちよく働ける限界値を把握しよう ワイはできてた度：★★★★☆ 周り
View Transition APIについて調べてみた - Repro Tech Blog
Repro Boosterの開発を担当しているRyoma Shindo です。 今回はView Transition APIについて、基本的な使い方やCore Web Vitalsへの影響の有無など調査したのでご紹介します。 View Transition API とは View Transition APIは、ページ遷移する際のアニメーションを手軽に実装するためのAPIです。MPA（Multi Page Application）/SPA(Single Page Application)どちらでも利用できますが、MPAで利用する場合、MPAでありながらSPAのようなスムーズな画面遷移を実現できます。 今回はMPAでの動作に焦点を当てて記載します。 最低限の使い方は簡単で、以下をCSSに追加するだけです。 @view-transition { navigation: auto; } 適用する
新入社員のDevinと過ごす日々 - Repro Tech Blog
皆様こんにちは。Boosterの杉浦です。 Repro ではここのところ、各種 AI を活用して生産性を上げられないか、色々模索しているところです。 Devin も複数のチームで実験的に導入をはじめ、現状3か月ほどになりました。 Booster チームでは主に既存レポジトリのコードの改善、機能追加の目的で試しており、以下のような感触です。 人間のジュニアプログラマと比較して十分役に立ち、高速かつ大量に作業を行える プレーンテキストのドキュメントやリソースがすでにあるかが非常に重要 開発 - ビルド - テストのパイプラインが手元の VM/Docker ですべて完結するように整備されていると、作業のスピードもクオリティも上がる 実機が要る、などの場合は現実的に頼めることがあまりない ローカルでテストが回せないと途端にやり取りの手間が激増する テスト環境の整備自体を頼むこともできる 頼む側は、
Repro における AWS アカウント分離の取り組み - Repro Tech Blog
Development Division/Platform Team/Sys-Infra Unit では、よりセキュアな状態を維持できるように様々なことに取り組んでいます。 背景 Repro ではメインとなる AWS アカウントに以下の環境で利用するリソースを全て作成していました。1 production 所謂本番環境 staging 本番リリース前に QA を行うための環境 dev_staging 開発者の動作確認用 test アプリケーションの CI で利用する internal 内部利用のためのウェブアプリケーション AWS Well-Architected Tool を使って既存環境をチェックしたところ、まずは AWS アカウントを分離し、各環境のワークロードを分離した方がよいとの結果でした。 SEC01-BP01 アカウントを使用してワークロードを分ける: - AWS Well-
オブザーバビリティ入門: OpenTelemetryについて知っておくべきこと - joker1007’s diary
自分が在籍している会社でKafkaを利用したマイクロサービスが増えてきているので、昔からオブザーバビリティの向上というものにちゃんと着手したかったのだが、最近になってやっと手を動かせる所まで優先度を上げられた。 という訳で、ここしばらくは社内にあるマイクロサービス群にOpenTelemetryによる計装を入れまくっている訳だが、大分可視化が進んできたので、これを社内のメンバーに周知しなければならない。 とは言え、説明したい内容が余りに一般的な知識なので、社内向けのクローズドなドキュメントとして書くのは勿体無いので、オープンなブログの方にまとめることにする。 (会社のテックブログに書いた方がいいのではという話はあるが、仕事っぽくなると面倒臭い……) 基本的にはOpenTelemetryの公式ドキュメントを自分なりに解釈して要点を絞る、という形で解説していくつもりなので、公式ドキュメントは一通
103 Early Hints とは何か？ ～マイナーだけど革新的なHTTPステータスの世界～ - Repro Tech Blog
はじめに みなさまこんには。日々 Booster で楽しくコードを書いている杉浦(sugi) です。 Booster プロジェクトではタグを入れるだけでサイトを高速化できる「Repro Booster」という製品を作っていますが、そのためにも日々さまざまな最適化手法を調査・模索しています。 その中で個人的に期待しているのが、 103 Early Hints というHTTPステータスコードです。 この記事では Repro Tech Meetup #9 で行った発表(資料)を元に、103 Early Hintsはどのような仕組みなのか、なぜ高速化につながるのか、さらに現状の実装に関して解説します。 ちょっとマイナーな内容ですが、知っておくとウェブパフォーマンス最適化の大きな武器になるかもしれません。 103 Early Hintsの背景 従来のHTTP通信の課題 通常のHTTP通信においては、
ServiceWorkerの課題を解決する!? Static Routing APIを使ってみた - Repro Tech Blog
はじめに こんにちは、Repro Booster という製品の開発責任者／プロダクトマネジメントを担当しているEdward Fox（@edwardkenfox）です。 今回は、ServiceWorkerに組み込まれた新機能「Static Routing API」を実際に試してみた件について説明します。Repro Boosterでの応用を通じて得た知見を共有できればと思います。 Repro Boosterとは Repro Boosterは、私たちが提供しているパフォーマンス最適化ソリューションです。サイトにタグを設置するだけで、読み込み速度が向上するというシンプルなコンセプトで設計されています。 その鍵となる技術の一つがServiceWorkerの活用です。ServiceWorkerはブラウザのバックグラウンドで動作し、リソースキャッシュやネットワークの中継など、従来のWebサイトでは実現で
Reproで技術書の読書会を続けるために行っていること - Repro Tech Blog
Repro Team / Feature Unit の下村です。 Reproで行っている技術書の読書会をどのように運営しているのかについて紹介します。 Reproの技術書読書会の現状 現状は2週間に1回のペースで1時間ほど時間をつかって読書会を行っています。参加者はその時々によって変わりますが、2-5人程度が参加しています。 今までは以下のような本を読んできました。 システム設計の面接試験 (半年程度で読破) ソフトウェア設計のトレードオフと誤り (半年程度で読破) 分散システムデザインパターン (現在読んでいるところ) Reproでは高トラフィックなシステムの保守運用や開発が求められる場面が非常に多いです。せっかくなのでそのようなReproの特性に合う本を読もうという方針のもと、参加者間で議論して読む本を選んでいます。 モチベーション そもそもなぜ読書会をやりたいのか？という理由はチーム
リードについて - @m_seki の
リードについて 本書のエッセイをお願いされた時、リーダーシップとはなんだろう、リーダーとはなんだろうと考えました。きっとリードする人がリーダーですよね。うーん。どうも「リード」自体がよくわかってないようです。 私たちのチームには明示的なリーダーが存在しません。チームをリードする係の人がいないのです。そこで、チームの毎日をふりかえって、リードのようなものがなにかないだろうかと探してみました。 そういえば、メンバーの誰かがチームを変化させることがあります。いつもの 1 日 のちょっとした場面で、チームの安定を壊すような「言いにくいこと」を言うのです。 それは技術的な指摘であったり、ムードの問題であったり、執務環境のことであった り、体調のことであったり、いろいろありますが、どんな発言であってもそれを聞い てチームは新しい状態に変化します。私たちのチームにとって、チームを引っ張ると いうより、チ
続く道 花の跡 - ななせ悠 | 少年ジャンプ＋
JASRAC許諾第9009285055Y45038号 JASRAC許諾第9009285050Y45038号 JASRAC許諾第9009285049Y43128号 許諾番号 ID000002929 ABJマークは、この電子書店・電子書籍配信サービスが、著作権者からコンテンツ使用許諾を得た正規版配信サービスであることを示す登録商標(登録番号 第6091713号)です。
マネージャーとNegative Capability - scrapbox - hotchemi
Negative Capabilityという概念を最近知った。詩人ジョン・キーツが提唱したとされている用語で「事実や理由を性急に求めず、不確実さや不思議さ、懐疑の中にいられる能力」を意味する。対義語はPositive Capabilityで、所謂課題解決能力の事。 我が身に翻ってみると思い当たる事が多く、特にマネージャーをやっているとこの能力の有用性を感じずにはいられない。例えばよく目にするのは以下の様な事象だ。 新しく入ってきたマネージャーが成果を出そうと張り切って色々提案するが、芯を外していたり合意を得られてなかったりで現場でハレーションが起きる ある問題を解決する為に新しいツールを導入するが、新しいツールが更なる問題を引き起こし以前より状況が悪化する 組織内で色々改善活動を試みるが、すぐには効果が出ず反応も芳しくないので心が折れてしまう これらはpositive capability
ワクチン接種予約システムの負荷対策指針と事例
こんにちは。株式会社X-Tech5 取締役CTOです。 先日株式会社Topotalと共同で、 新型コロナウィルス感染症のワクチン接種予約システムのアクセス集中の、不具合の調査支援及び改善提案を無償提供するプレスリリースをしました。 新型コロナウィルス感染症のワクチン接種予約システムのアクセス集中による不具合の多発を踏まえ、不具合の調査支援及び改善提案を無償提供 このエントリでは、実際に行った負荷対策の要点を公開し共有します （というわけで、宣伝半分・事例紹介半分です）。 この考え方・やりかたが正しいのだ、という意図はありません。 新型コロナウィルス感染症のワクチン接種予約システム（以下接種予約システム）のアクセス集中対策の参考にしていただき、世の中から接種予約システムの負荷トラブルが減ると嬉しいです。 ポイント1：価値基準の確定・すりあわせ まずは関係者で価値基準を確認し合意します。 接種
相談されなくなる理由 - Konifar's ZATSU
誰かからの相談がなかった時、遅かった時、どうして相談してくれなかったのか、なぜ勝手に物事を進めるのかと憤りを感じることがあると思う。 自分の経験から言うと、相談されない時は相談を受ける側に理由がある。いや実際には違うかもしれないが、そう考えておいた方が楽。相手の行動を変えるより自分の行動を変える方が簡単だしコントロール可能だからだ。100%自分に理由があると仮定して物事を考える方が建設的である。 相談されなくなる理由は大きく分けて2つしかない。「相談する必要がないと考えている」か、「相談したくないと考えている」かのどちらかだ。 「相談する必要がないと考えている」 この場合、どういう時に相談をしてほしいか相手とすり合わせる必要がある。デリゲーションポーカーなどで権限委譲を見直したりしてもいいかもしれない。 目的とインパクトの大きさの認識があっていないこともある。まあこれも話すなり明文化するな
freeeアクセシビリティー・ガイドライン — freeeアクセシビリティー・ガイドライン Ver. 202411.0-RELEASE+5.1.0
このガイドラインは、参考情報の追加や表現の改善などで、随時更新されます。 リリース:Ver. 202411.0-RELEASE+5.1.0 ガイドライン・バージョン：Ver. 202411.0-RELEASE チェックシート・バージョン：5.1.0 更新日:2024年11月22日
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rubygem開発で鍛える設計力
bashでset -xしたときの出力をmask
