タグ

rubellumのブックマーク (2,888)

  • マイクロサービス間通信における認証認可およびアクセス制御

    はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで

    マイクロサービス間通信における認証認可およびアクセス制御
    rubellum
    rubellum 2024/07/07
  • イーロンマスクの「開発の5ステップ」をまとめました - あなたの要件はアホだし、そのプロセスも要らない、すぐ最適化するな。 - Make組ブログ

    イーロンマスク氏がスペースXを案内するという動画(Starbase Tour with Elon Musk PART1)の中で語られた「開発の5ステップ」が僕的に衝撃でしたのでまとめます。 この内容、心底素晴らしいのですが、元動画では話が少しとっ散らかっていますし専門的すぎます。 僕自身、何度も内容を思い返して役に立ったのですが、見直すたび読解に苦労するので自分のためにまとめ直しました (ありがとう、僕!愛してるよ!)。 以降については、イーロンマスク氏が語る開発の5ステップについてまとめています。 余力があれば、自動字幕ありで動画を見ながらのほうが、イーロンマスク氏の熱意を感じられて楽しいと思います(下の動画では、この話が始まる辺りから始まるようにしています)。 youtu.be イーロンマスク、開発の5ステップ 開発の中では以下の順序を必ず守らないといけません。 要件をアホのままにしな

    イーロンマスクの「開発の5ステップ」をまとめました - あなたの要件はアホだし、そのプロセスも要らない、すぐ最適化するな。 - Make組ブログ
    rubellum
    rubellum 2024/07/01
  • メンバー全員が開発リードになれる、「エピック主管」という仕組み

    はじめに HRMOSプロダクト部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしている輿水です。 私たちのチームには、プロダクト開発を進める上で次のような課題がありました。 プロダクトオーナー(以下、PO)の業務が多岐にわたり、ドキュメントの更新が大きな負担となっていた 要件や仕様について最新の情報を把握することが難しく、ステークホルダー間でのコミュニケーションコストが増大していた これらを解決するため、私たちのチームは「エピック主管」という仕組みを導入しました。これは、エンジニアがリードしてドキュメント管理を行い、プロジェクトマネジメントの役割も果たすことで、POやエンジニアリングマネージャー(以下、EM)の業務負担を削減するものです。 記事では、エピック主管とは何か、そしてその役割や成果について深く掘り下げて紹介します。 この記事では、プロダクト開発において

    メンバー全員が開発リードになれる、「エピック主管」という仕組み
    rubellum
    rubellum 2024/06/26
  • JetBrains、「Google Gemini」をGitHub Copilot対抗の「JetBrains AI Assistant」に採用へ

    JetBrains、「Google Gemini」をGitHub Copilot対抗の「JetBrains AI Assistant」に採用へ 開発ツールのIntelliJ IDEAやプログラミング言語Kotlinなどの開発元として知られるJetBrainsは、AIによるコード生成やリファクタリングなどを自動的に行う「JetBrains AI Assistant」の生成AIとして、Google Geminiを採用すると発表しました。 JetBrains is going to integrate Google’s Gemini models into AI Assistant. Read more in our blog post: https://t.co/s4fkngY7v1 pic.twitter.com/MLnRkRvG1N — JetBrains (@jetbrains) Jun

    JetBrains、「Google Gemini」をGitHub Copilot対抗の「JetBrains AI Assistant」に採用へ
    rubellum
    rubellum 2024/06/26
  • スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team

    2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。 Scrum Fest Osaka https://www.scrumosaka.org/ プロポーザル https://confengine.com/conferences/…

    スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
    rubellum
    rubellum 2024/06/25
  • HTMX入門【はじめからそうやって教えてくれればいいのに!】

    はじめに この記事の内容は、以下の動画でも解説しています。アニメーションでわかりやすくなっているので、ぜひ見てみてください。他にもWebに関する解説動画を投稿しているので、気になる人はチャンネル登録よろしくお願いします! HTMXとは? HTMX とは、一言で言うと、JavaScriptを書かずに動的なページを簡単に作成できるライブラリのことです。 htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript. (訳)htmx は、JavaScript を使用するのではなく、HTML から最新のブラウザー機能に直接アクセスできるようにするライブラリです。 </> htmx ~ Documentation ...と言っても

    HTMX入門【はじめからそうやって教えてくれればいいのに!】
    rubellum
    rubellum 2024/06/25
  • スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team

    2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。 Scrum Fest Osaka https://www.scrumosaka.org/ プロポーザル https://confengine.com/conferences/…

    スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
    rubellum
    rubellum 2024/06/24
  • dbt導入におけるデータモデリング環境整備 - pixiv inside

    はじめに 初めまして。プラットフォーム開発部にてデータ基盤の整備をしているazukiと申します。 今回はdbt(Data build tool)を導入した経緯と非中央集権的なdbtの使い方についてご紹介したいと思います。 今回は導入に関してまとめていますので、dbtの運用面の詳細は別記事で解説予定です。 データモデリングツール導入の背景 ピクシブではプロダクトの多さを理由に非中央集権データ組織を採用しています。 ドメインチームがメインでデータの取り組みやデータモデリングを行い、データ駆動推進室やデータ基盤チームはそのサポートや整備を担当しています。 その背景に関しては、【PIXIV MEETUP 2023】の方でお話していますのでぜひご覧下さい。 speakerdeck.com 今までBigQueryのデータ加工SQLは自社で開発したツールで管理していました。 pythonから変数埋め込み

    dbt導入におけるデータモデリング環境整備 - pixiv inside
    rubellum
    rubellum 2024/06/18
  • 大規模なRedis運用で生き残る方法

    こんにちは。LINE Plus(韓国にある、LINEヤフー株式会社の子会社)のRedisチームでDBA業務を担当しているJeonghoon Kimです。私たちのチームはその名の通り、代表的なキーバリューストア(key-value store)Redisを研究し、社内に導入しています。また、国や法人を問わずに独自で運営しているサービスを除く、LINE関連サービスで使用されるすべてのRedisに対して技術サポートを担当しています。 その間、新しいサービスが生まれ、既存のサービスも成長してRedisの規模も徐々に大きくなってきました。この記事では、2023年の1年間、大規模なRedisを運用してきた私たちのチームの経験についてお伝えしたいと思います。まず、私たちが運用しているRedisのおおよその規模と、HA(high availability)をどのように構成したかを簡単に説明し、クラウドリソ

    大規模なRedis運用で生き残る方法
    rubellum
    rubellum 2024/06/17
  • 開発生産性の改善から1年経過したチームで考えていること - メドピア開発者ブログ

    こんにちは。エンジニアの保立(@purunkaoru) です。 僕のチームでは、開発生産性の改善に取り組んでから1年経過しました。 開発生産性の改善系の記事やノウハウは世間によく出ていますが、1年経過した今、開発生産性に対してEMの立場で何を考えているかを言語化します。 チームメンバーの構成は、執筆時で以下の通りです。 フロントエンド: 5名 サーバーサイド: 9名 モバイルアプリ: 3名 EM(保立): 1名 弊社では、Findy Team+ を導入し、開発生産性を見えるようにしています。 まずはFindy Team+の画面を見ながら、改善結果を見ていきます。 直近1年間 直近2年間 直近2年で見ると、後半1年で生産性が改善されており、その改善が一定維持できていることがわかります。 ちなみに、このサイクルタイム分析について、数値的な目標を今まで一度も掲げてきませんでした。 どうしても指標

    開発生産性の改善から1年経過したチームで考えていること - メドピア開発者ブログ
    rubellum
    rubellum 2024/06/17
  • Gitのブランチの役割を考える | フューチャー技術ブログ

    Gitのブランチ戦略にはいくつかあります。 GitフローGitHubフローGitLabフローチームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね?社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか?というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名=役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証のブランチ

    Gitのブランチの役割を考える | フューチャー技術ブログ
    rubellum
    rubellum 2024/06/13
  • ReactとZodで作る堅牢なフォームバリデーション - ICS MEDIA

    前回の記事『2024年版 HTMLで作るフォームバリデーション』ではHTMLの機能を駆使したフォームバリデーションの実装について解説しました。HTMLのみでも高機能なフォームを作成できるのは解説したとおりですが、HTMLに加えてJavaScriptを組み合わせることでより高機能なフォームを作成できます。それに加えて、開発者体験の向上も期待できます。 記事では3つのライブラリを使用して実践的なフォームを作成する方法を解説します。 UIライブラリ「React」 フォーム向けライブラリ「React Hook Form」 型システムと相性の良いスキーマバリデーションライブラリ「Zod」 また、静的型付け言語であるTypeScriptもこれらのライブラリと同時に使用し、堅牢なフォームの実装を目指します。 記事を読むことで以下の知識が身につきます。 フォーム画面のユーザー体験(UX)と、フォーム実

    ReactとZodで作る堅牢なフォームバリデーション - ICS MEDIA
    rubellum
    rubellum 2024/06/13
  • イベント駆動とドメインモデルの完全性を意識したアーキテクチャ設計

    こんにちは。LINEヤフー株式会社で、出前館というプロダクトのサーバーサイドエンジニアをしている古田大志です。 株式会社出前館はLINEヤフーのグループ会社です。資業務提携を結んでいて、LINEヤフーが開発などをサポートしています。 詳しくはこちらをご参照ください。(https://corporate.demae-can.co.jp/pr/news/demaecan/line.html)(外部サイト) 今回の記事では、その出前館における開発の内容を紹介させていただきます。 出前館はデリバリーサービス事業のプロダクトで、開発においてはマイクロサービスアーキテクチャを採用しています。出前館のマイクロサービスの1つに、クーポンに関するドメインの責務を持ったコンポーネントであるクーポンサービスがあります。 クーポンサービスでは、ビジネスエンハンスに伴う「非機能要件の増大」や「仕様の複雑さの肥大化

    イベント駆動とドメインモデルの完全性を意識したアーキテクチャ設計
    rubellum
    rubellum 2024/06/13
  • メルカリ ハロ Webフロントエンドの開発スピードと品質両立の取り組み | メルカリエンジニアリング

    こんにちは。メルカリのSoftware Engineerの@tanashoです。連載:Mercari Hallo, world! -メルカリ ハロ 開発の裏側-の6回目を担当させていただきます。 メルカリ ハロのWebアプリケーションは複数存在し、Webフロントエンドチームが横断的に開発をしています。記事では、その前提を踏まえ、スピードと品質をどのように両立させて開発しているかを紹介します。 プロジェクトの概要とWebフロントエンドの担当領域 メルカリ ハロは「あたらしい出会いを繋ぎ、信頼と機会をひろげる」がミッションで、いますぐ働き手が欲しいパートナー (事業者) と、いますぐ働きたいクルー(働き手)を繋げるサービスです。クルーは自身のスキルや時間を活用して働くことができます。 メルカリ ハロは複数のアプリケーションが存在し、そのなかでWebフロントエンドが関わる領域として以下の3つが

    メルカリ ハロ Webフロントエンドの開発スピードと品質両立の取り組み | メルカリエンジニアリング
    rubellum
    rubellum 2024/06/13
  • E2Eテストワークフローを高速化・安定化させる取り組み | ドクセル

    スライド概要 GitHub Actions Meetup Tokyo #3 https://gaugt.connpass.com/event/317178/ このプレゼンテーションでは、サイボウズ社のGaroonのE2Eテストについて、GitHub Actions self-hosted runner 上で実行していたE2Eテストを高速化・安定化させるために取り組んだこと、E2Eテストワークフローの視点の改善アイディアについて話されます。GaroonのE2Eテストにおける実行時間とFlakyが問題となっており、その改善に取り組んだ内容が紹介されています。 おすすめタグ:GitHub Actions,E2Eテスト,self-hosted runner,Garoon,テストワークフロー

    E2Eテストワークフローを高速化・安定化させる取り組み | ドクセル
    rubellum
    rubellum 2024/06/11
  • 食べログiOSアプリで機械学習による画像分類を導入し、料理判定機能を実装した事例紹介と知見のまとめ - Tabelog Tech Blog

    こんにちは。べログでiOSアプリのサービス開発を担当している河崎です。 私の所属するプロダクトチームでは、ユーザーが継続的かつ手軽に行ったお店の記録ができるように、アプリの改善や新機能開発など様々な対応を行っています。 この記事では、iOSアプリで料理写真を判定するために画像分類を取り入れた開発事例の紹介と、開発で得られた知見についてまとめていきます。 目次 画像分類を取り入れた新機能について 画像分類の対応方針 方針1:公開されている画像分類用のモデルやフレームワークを使用する 方針2:独自の画像分類用のモデルを構築する コストが高いと判断した理由 アプリ特有の考慮すべき条件 オンデバイスであること モデルサイズが小さいこと 解析速度が速いこと Visionフレームワークでの実現 VNClassifyImageRequest とは VNClassifyImageRequest の使い方

    食べログiOSアプリで機械学習による画像分類を導入し、料理判定機能を実装した事例紹介と知見のまとめ - Tabelog Tech Blog
    rubellum
    rubellum 2024/06/10
  • 組織が記憶喪失になるのをどうすれば ~ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog

    何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした組織が記憶喪失になることにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 (@ryuzee) さんにふらっと相談してみたら一瞬で突破口が見つかった&話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念:ADR ADRの実践:その1 何を書くか ADRの実践:その2 どこに書くか ADRの実践:その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 (@ppyv) です。 開発・検証用PCの開発に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよ

    組織が記憶喪失になるのをどうすれば ~ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog
    rubellum
    rubellum 2024/06/10
  • 大公開!バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG

    こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

    大公開!バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
    rubellum
    rubellum 2024/06/10
  • プロダクトバックログアイテムの分割方法

    みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え

    プロダクトバックログアイテムの分割方法
    rubellum
    rubellum 2024/06/08
  • メルカリ ハロ リリースのQA戦略 | メルカリエンジニアリング

    こんにちは。メルカリのQAエンジニアリングマネージャーの@____rina____ です。今回は、連載『Mercari Hallo, World! -メルカリ ハロ 開発の裏側-』の第4回を担当します。 記事では、メルカリ ハロのサービスローンチまでのQAプロセスを通じて、私たちはどのようにして安心・安全なプロダクトを迅速にリリースするための戦略を実行したか、具体的な方法とともに詳述しています。 この記事を通じて、以下の点についての理解を深めていただけることを目指しています: QAの役割とプロジェクト概要 効率的なQAアサイン戦略 成果物の透明性と管理ツールの効果的な活用方法 また、この記事を書くにあたり、私自身が学んだことや得た教訓についても触れています。これらの経験は、今後のプロジェクトにおいて更なる品質向上と効率化を目指す上で非常に貴重なものとなりました。 プロジェクト概要とQAの

    メルカリ ハロ リリースのQA戦略 | メルカリエンジニアリング
    rubellum
    rubellum 2024/06/07