イベント名: オブザーバビリティ再入門 - 大切さと高め方を知ろう! イベントURL: https://mackerelio.connpass.com/event/316449/ 概要: 可観測性の概念を理解し、OpenTelemetryなどの実装に必要な道具があっても、自分たちのプロダクトやチームにどう適用させていけばよいのかは、自分たちで考え、設計しなければなりません。開発チームがメトリクス、ログ、トレースをどういった基準で採用していくかについて、具体例を用いながらお話します。
結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは? MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd
スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。 私は HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。 この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたの
株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編(一部社内向けの内容)
昨今は、さまざまな要因から、複数のクラウド(IaaS)プロバイダーを活用することが多くなりました。例えば、サービスのワークロードはAWSだが、データ分析はGoogle CloudのBigQueryを使うなどです。異なるプロバイダー間でのリソースにアクセスするには、認証が必要であり、シークレットを安全に発行・交換する必要があります。クラウドプロバイダーが動的に発行する等さまざまな方式がありますが、システムの制限や運用によっては安全なシークレットの取り扱いのために、慎重な技術設計が必要になる場合もあります。 今回は、LayerXにおける要件パターン、脅威モデリングに基づく判断と実装方法を紹介することで、「どこまで気をつけるべきか?」「何を想定すべきか?」といった実務に対して参考いただけると嬉しいです
技術的負債という言葉がある。もともとは、「楽するために導入したが、メンテにコストがかかるようになってしまった技術や構成」くらいの意味合いで使われているように思う。しかし、そもそも全部が負債ではないか、というのがこのメモの趣旨である。 負債 同僚とSlackで会話していると、「けっきょくどの言語を利用しても負債になるときはなるし、大抵負債になる」といった話になった。言われてみればそうで、基本的にコードというものは書いたそばから負債になっていく。去年書いたコードのことも思い出せない。 そんな中で思ったのだが、そもそも、負債になるコードと負債にならないコードとがあったり、技術が「負債化する」のではなく、コードや技術そのものが負債なのではないか。そして、どの言語で書こうが負債からは逃れることができない。負債にならないコードは存在しない。ゆえに、コードや技術は無ければ無いほど良い、ということになる。
生成AIを活用する企業は増える一方だが、それとともに、AIの間違いによって損害を被る企業も増えている。 エア・カナダはチャットボットの誤回答で賠償金を支払うはめに。別の企業は生成AIが作成した解雇合意書に重要な項目が欠落していたため、高額な和解金を支払わなければならなくなった。 企業に求められるのは、生成AIは間違いを犯すという前提に基づいた準備や行動。AIが間違えているかどうか分からない領域では活用すべきではない。 (小林 啓倫:経営コンサルタント) チャットボットで損害を被ったエア・カナダ 企業内でのAI活用が加速している。社員や顧客と自然な言葉でやり取りできる生成AIが登場したことで、AIを応用できる業務が増え、具体的な成果も見えやすくなったためだ。 たとえば、カナダで1855年に設立され、現在では同国で最大の規模を誇るTD銀行(Toronto-Dominion Bank)は、コンタ
GitHub Actions における JavaScript/TypeScript Custom Action の開発・運用知見を紹介します! 2024-05-16 GitHub Actions Meetup Tokyo #3 にて発表 https://gaugt.connpass.com/event/317178/ 会場:株式会社サイバーエージェント Abema Towers YouTube 配信アーカイブ https://www.youtube.com/watch?v=mR684-oSAJw
React Aria Components は Adobe によって提供されている Headless UI コンポーネントライブラリです。振る舞いや国際化に, アクセシビリティに関する機能を備えており、Button や Input, TextField, Label などのシンプルな要素から、DatePicker や ComboBox などの様々なコンポーネントが提供されています。 今回は React Aria Components の設計について紹介します。 React Aria Components のコンポーネントの設計 React Aria Components の API はコンポジションを中心に設計されています。これにより、パターン間で共通のコンポーネントを共有することも、個別に使用することも可能です。なお、コンポジションについては React Component Compos
はじめに 初めまして!ソーシャル経済メディア「NewsPicks」SREチーム・新卒エンジニアの樋渡です。今回は「AWS Security Hub」と「Slack」を用いて、弊社で利用しているAWSリソースの監視運用を効率化したお話です。 お話の内容 年々増加するサイバー攻撃に対抗するため、セキュリティ対策は日々重要度が増してきています。 そこで弊社で利用しているAWSのリソースに対して、各種セキュリティイベントの収集ができるAWS Security Hubを利用することで、セキュリティ状態の可視化と迅速な対応がしやすい運用を行い、セキュリティ状態の現状把握から始めることにしました。特にNIST CSFの「検知」部分の運用について整備した内容となっています。 NIST Cyber Security Frameworkについて 皆さん、「NIST Cyber Security Framewo
GitHub、「Copilot Workspace」テクニカルプレビューを開始。ほとんど全ての開発工程をAIで自動化 テクニカルプレビューは上記のCopilot Workspaceのページからウェイトリストボタンをクリックして申し込みます。 Copilot Workspaceはほとんど全ての工程を自動化 Copilot Workspaceは、自然言語で書かれたIssue(課題)を基に、Copilotが仕様案と実装計画を示し、コーディングや既存のコードの修正を行い、ビルドをしてエラーがあればデバッグも行うという、プログラミングのほとんど全ての工程をCopilotが自動的に実行してくれる、というものです。 人間は各工程でCopilotから示される内容を必要に応じて修正するか、そのまま見守ることになります。 GitHub CEOのThomas Dohmke(トーマス・ドムケ)氏は、Copilot
英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効/無効状態の確認」や「検証に成功した場合の身元の保証(アクセストークンの発行等)」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい!」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください! メガクラウドと特化型クラウド/ハイパーバイザーのSoC化/ライセンスとクラウドベンダー/イベント駆動型API/LLM時代のAIペアプロ力/生活必需品としてのGPU・NPU/Passkey/ウェブアクセシビリティ/リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS(Function-as-a-Ser
「Agentic Design Patterns」と呼ばれるLLMベースのAIエージェント(以下、LLMエージェント)の4つのデザインパターンについて紹介します。 まず、「Agenticワークフロー」について説明し、続いて4つのデザインパターンを説明します (Part5の前に公開してしまったので、後追いで更新予定です) Agentic Design Patterns Part 1 Agentic Design Patterns Part 2, Reflection Agentic Design Patterns Part 3, Tool Use Agentic Design Patterns Part 4, Planning Agentic Design Patterns Part 5, Multi-Agent Collaboration 動画もあります。 LLMエージェントについての説明
言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く