2023/12/06に、 Platform Engineering Meetup で発表した菅沼の資料です。

はじめに こんにちは。データエンジニアとして社内横断で使われるデータ基盤 Crois の開発を担当している青木です。 2024 年 9 月に開催された AWS Innovate - Migrate. Modernize. Build. にて、「リクルートのデータ基盤 Crois - 年 3 倍成長！ 1 日 40,000 コンテナの実行を支える AWS 活用とプラットフォームエンジニアリング」というタイトルで発表を行いました。 汎用的なワークフローエンジン・ジョブスケジューラとして開発された Crois は、リクルートのデータ利活用の進化に伴い急速に利用が拡大しています。 その急成長を支えている要因として、AWS の活用・プラットフォームエンジニアリングの実践という 2 つの観点に着目しお話しさせていただきました。 本記事では、その内容をご紹介します。 本記事は、データ推進室 Advent

For more than a decade now, the fact that people have a hard time gaining actionable insights from their data has been blamed on its size. “Your data is too big for your puny systems,” was the diagnosis, and the cure was to buy some new fancy technology that can handle massive scale. Of course, after the Big Data task force purchased all new tooling and migrated from Legacy systems, people found t

個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

Most career ladders define a single, uniform set of expectations for Staff engineers operating within the company. Everyone benefits from clear role expectations, but career ladders are a tool that applies better against populations than people. This is particularly true for Staff-plus engineers, whose career ladders often paper over several distinct roles hidden behind a single moniker. The more

だれでも・効率よく・迷わずに。 SmartHR Design Systemは、すべての人によりよい体験を届けるためのデザインシステムです。SmartHRに関わる人はどなたでも利用・参加できます。 デザインシステムとは？

「ユーザビリティチェックリスト」ということで、UIデザインの「あるある」を取り上げ、改善案とセットでまとめています。 今回は、10のヒューリスティクスをもとに分類してみました。10のヒューリスティクスについては、以前記事にまとめています。 具体的な事例を一緒に取り上げ、よりわかりやすく解説していますので、こちらもあわせてご覧ください。 また弊社ホームページにて、ユーザビリティチェックリストをダウンロードいただけます。こちらも合わせてご活用ください。 1. システムステータスの可視化（Visibility of system status）1-1. 入力項目が多いときはステップを分けるフォームの入力項目が多い場合は、項目をグルーピングして画面を分割しましょう。 フォームが長すぎると、ユーザーは入力を途中で辞めてページから離脱してしまうかもしれません。 その上で、ステッパーを設置して現在の進捗

SIerから事業会社のエンジニアに転職後、SREチームのリーダーになって1年経過※したので、個人的なふりかえりのためにやったことを言語化し整理します。 ※ 本当は7月で1年なので先月書きたかったけど、7月は評価と目標設定に加えて障害対応などが重なりめちゃくちゃ忙しかった。。。 筆者の略歴SIerで10年半、インフラ主軸で大企業向けクライアントワーク＆技術支援 2021/10〜、NewsPicksのSREチームメンバーとして参画 2022/7〜、同チームリーダーになり、現在に至る SREチームの業務Googleが提唱した サイト信頼性エンジニアリング（SRE）がチーム名の由来です。SREはサービスの安定運用と変化への対応のバランスをとるためのプラクティス(技術的実践)なので、このプラクティスを遂行することがチームの業務と完全に一致するかというとそうではありません。 とはいえ、それを体現するチ

注意 このページにアクセスするには、承認が必要です。 サインインまたはディレクトリの変更を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更を試すことができます。 アジャイルな手法を使用して技術的負債を返済する David Laribee すべてのコードベースには、暗くて恐ろしい隠れた場所や小道があります。非常に脆弱なコード、回帰バグが発生するコード、および処理をたどろうとするとイライラしてしまうようなコードのことです。 Ward Cunningham は、コードの、変更が困難でエラーが発生しやすい部分を金銭的負債ににたとえて、みごとな隠喩を作りました。技術的負債があると、前に進んだり、利益を得たり、"黒字" の状態を維持したりすることができなくなります。現実世界と同様に、安い負債もあります。低リスクの金融商品よりも利率の低い負債です。また、負債をさら

Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801

システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

How to handle and report errors effectively in Rust applications is a common question. This blog shares our experience organizing variant types of Error in a complex system like GreptimeDB, from how an error is defined to how to log the error or present it to end-users. Such a system is composed of multiple components with their own Error definitions. TL;DR: In this article, we discuss the practic

テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。サイボウズの2023年度 新入社員向け研修の資料です。 本資料をもとにした書籍も発売中です：https://amzn.asia/d/2hQNEk2 Twitter：http…

このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

2024/2/15 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215

コンピューターで作られたシステムに問題があって、困っているとしよう。システムを作った人はここにいないし、一から作り直す時間はなかったり、そもそも触る権限がなかったりする。そういうシステムを、どうにかうまく使えるようにすることを、ハックという。 ここでいう「ハック」は、コンピューターを壊すとか、システムに侵入するという意味ではないし、単純にコンピューターに精通するというニュアンスでもない。責任の境界を超越して、システムをうまく動くようにしてしまう行為のことを言っている。いいかえれば、他人に依頼して直してもらうめんどくささを回避して、自分でシステムを直してしまうことだ。 たとえば、macOSの標準ブラウザーのSafariには「サイト固有のハックを無効にする」という開発者向けの設定項目がある。これは、どういう意味だろうか？ 世の中のWebサイトは、コンテンツを配信するWebサーバーと、それを受け

Thanks as a QAE, I was so tempted to write all my validations in a single test esp when there is a continous flow happening. Now that temptations has eased. Howeve this because more challenging when we write UI Tests with a lot of inputs before it even lands on the page to test. Where is the line to be drawn before going crazy and write automation tests for each test case vs combining all tests in