Free and open source, database design editor. No signup -> get a diagram in just 15sec Free and open source, DB design editor. No signup -> get a diagram in just 15sec

ある案件で、GitLab CI/CDでRSpecによるテストを自動化しています。 その際に以下の問題がありました。 テスト完了まで30分ほどかかる たまに落ちるテストがある CIでは、テスト成功後に開発環境へ自動デプロイするようになっているため、たまに落ちるテストによりテスト全体を再実行することになり、デプロイ完了まで多くの時間がかかってしまっていました。 改善方針 たまに落ちるテストをいい感じにリトライするCircleCI Workflowsの設定 を参考にさせていただき、失敗したテストのみ実行するretry-testというステージをRSpecを実行するtestステージの後に追加し、only-failuresオプションで失敗したテストのみ再実行できる構成にしました。 ステージを分けることでテストの再実行に失敗しても、retry-testステージのジョブのみをさらに再実行することも可能にな

SREチームの長田です。 SREsとしての業務がメインではあるのですが、実はSREチームの人事リソース管理を担当していたりします。 今回はそんな立場から「SRE活動用のリソース」について紹介してみようと思います。 SREなのに「SRE活動用」リソース？ カヤックのSREは、担当プロダクトチームのメンバーとして動く、いわゆるEmbedded SREです。 社内の予算計画の話になってしまうのですが、プロダクトを持つ事業部がSREメンバーのリソース配分を期ごとに確保する形式となっています。 例えばあるメンバーのリソース(100%)のうち、50％分をTonamel(ゲームコミュニティ事業部)に、 30％分をまちのコイン(ちいき資本主義事業部)に割り振った場合、 各割合分のリソースを各プロダクトが属する事業部が負担する形です *1。 Embedded SREの活動とは別に、プロダクトとは直接関係のな

リファクタリングは、設計やコードを綺麗に保つという普遍的に求められる活動の一要素です。常識的な習慣として推進すべき活動です。 ただ、有効性の理解を得られないままリファクタリングを行って物議を醸す場面も存在します（例えばここのはてなブックマーク等で巻き起こった議論などです）。 実際、リファクタリングは、以降の保守作業をサポートしてこそ価値がでるものであり、考えなしにいつでも一律実施すればよいというものではありません。リファクタリングの対象やチームの状況によって、リファクタリングをすべきかどうか、線引きがされます。 このリファクタリングをすべきかどうかの基準ですが、一言でまとめると「妥当な保守性の実現を、妥当な費用対効果で実現できるか」になります。今回はこの基準を構成する「妥当な保守性の実現」と「妥当な費用対効果」について、それぞれ解説します。 リファクタリングで妥当な保守性を実現できるかの基

An IDE built on top of a canvas, Haystack takes care of the tedious and confusing parts of coding for you

本日8月25日はCHAGE and ASKAのデビュー記念日。このたびの配信は彼らのデビュー45周年を記念して実施された。「VERY BEST ROLL OVER 20TH」はCHAGE and ASKAのデビュー20周年を記念してリリースされた作品で、「ひとり咲き」「万里の河」「LOVE SONG」「PRIDE」「太陽と埃の中で」「SAY YES」「YAH YAH YAH」「めぐり逢い」など、1979年から1999年までの楽曲から選ばれた全29曲が収められている。 なお「VERY BEST ROLL OVER 20TH」以外の作品はすべて10月1日に配信される。 CHAGE and ASKA「VERY BEST ROLL OVER 20TH」収録曲01. ひとり咲き 02. 万里の河 03. 終章（エピローグ）～追想の主題 04. 男と女 05. 安息の日々 06. MOON LIGHT

【Assured×カケハシ】DXを牽引する先進プロダクト開発に携わるエンジニア達が語るドメインモデリング https://techplay.jp/event/952464

2024年8月1日21時より予定しておりましたmibotの予約開始につきまして、決済システムに不備が見つかったため、予約開始を延期させていただくこととなりました。ご予約を心待ちにされていた皆様には、多大なるご迷惑をおかけしますことを心よりお詫び申し上げます。 新たな予約開始日時については、現在調整を進めております。決定次第、当社公式ホームページおよびニュースレターにて速やかにご案内いたします。お客様に安心してご利用いただけるよう、決済システムの安全性と信頼性を確保するため、万全の体制を整えてまいります。ご理解とご協力を賜りますようお願い申し上げます。

\r\n<li><span class=\"biz-smb-fs-m1\"><b><span class=\"biz-smb-txt-link\"><a href=\"#prompt\">プロンプト一覧</a></span></b></span></li>\r\n<li><span class=\"biz-smb-fs-m1\"><b><span class=\"biz-smb-txt-link\"><a href=\"#move\">ChatGPT活用動画</a></span></b></span></li>\r\n<li><span class=\"biz-smb-fs-m1\"><b><span class=\"biz-smb-txt-link\"><a href=\"#blog\">関連記事</a></span></b></span></li>\r\n<li><span class

2023/06/24 開催「PHPカンファレンス福岡2023」（https://phpcon.fukuoka.jp/2023/ ）の LT 資料です。 詳細：https://fortee.jp/phpconfukuoka-2023/proposal/ae71f3a7-4c3c-4c87-8816-…

G-gen の佐々木です。2024年8月22日（日本時間）、Google Cloud のサーバーレス コンピューティング サービスである Cloud Functions が Cloud Run functions としてリブランディングされました。当記事ではリブランディングによる影響や変更点を解説します。 Cloud Functions のリブランディング リブランディング Cloud Functions の世代 影響と変更点 既存の Cloud Functions 関数の動作・管理に影響なし Cloud Run の機能を使用できる 第1世代の Cloud Functions は名称変更のみ Cloud Run コンソールへの統合 Cloud Run services との差別化 Cloud Functions のリブランディング リブランディング 2024年8月22日（日本時間）、Clo

Run your AI inference applications on Cloud Run with NVIDIA GPUs Developers love Cloud Run for its simplicity, fast autoscaling, scale-to-zero capabilities, and pay-per-use pricing. Those same benefits come into play for real-time inference apps serving open gen AI models. That's why today, we’re adding support for NVIDIA L4 GPUs to Cloud Run, in preview. This opens the door to many new use cases

チャットGPTをはじめとする生成AIは、登場した当初、組織の生産性と利益を急増させる超知的なツールと言われていた。だが、実際にはそうなってはおらず、奇妙なことが起こり始めている。 by Melissa Heikkilä2024.08.22 27 この記事の3つのポイント 生産性向上のためのAI活用はまだ成功していない AIの誇大宣伝が高すぎる期待を生んでいる 一方でAIチャットボットと人々の感情的な絆は深まっている summarized by Claude 3 この記事は米国版ニュースレターを一部再編集したものです。 2022年後半に「チャットGPT（ChatGPT）」によって生成AIブームが始まった。そのとき、私たちが売り込まれたのは、すべてを知っており、仕事の退屈な部分を置き換えることができ、生産性と経済的利益を急増させる超知的なAIツールのビジョンだった。 それから2年が経ち、生産性

今回は、2024年7月25日に行われたイベント「Azure OpenAI Service Dev Day」の内容を紹介します！ 700名以上が参加した本イベントには、AI統括部リスキリングチームリーダーの西山 泰仙さんとAI技術室の山本 玄人さんが登壇しました。 本記事を読むことで、トヨタコネクティッドが現在実施している生成AI研修の設計や企業で生成AIを導入するために必要なことを知ることができます。 企業の生成AI推進担当者やこれから生成AIを導入したい方は、ぜひ参考にしてみてください！ アウトライン以下のアウトラインで講演を行いました。 ※講演の内容は複数回に分けて公開します。 本記事では、リスキリングチームリーダーの西山 泰仙さんの講演内容である、Chapter01「生成AI導入の理想状態仮説と現状分析」とChapter02「生成AIネイティブになるための戦略と取り組み」を紹介します

はじめに はじめまして、Data Scientist の山内（@jof_5）です。 本記事では、先日、社内で開催した Dify ハッカソンの様子について紹介します。 はじめに Dify ハッカソン実施の背景 開発したLLMアプリケーションのご紹介 1. クラウドサービス見積もりくん 2. Sales Lead Generator 3. その他 Dify ハッカソンを通じて得た学び 最後に Dify ハッカソン実施の背景 先日、LLM アプリケーションをノーコードで開発できる Dify という新しいツールが登場し、LLM アプリケーション開発を大幅に簡素化できると話題になっていました。 dify.ai 社内でも話題に上がっており、Dify の実用性について興味深い議論が巻き起こりました。「本当に使いやすいのか？」「どこまでの機能が実装可能か？」「実際の開発現場でどの程度有用か？」といった疑問

株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ向けに開発提供しているスタートアップです。本記事では、RAGの性能を高めるための「Golden-Retriever」という手法について、ざっくり理解します。 この記事は何 この記事は、RAGシステムを専門用語に強くするための手法「Golden-Retriever」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます。確認する場合は以下の記事もご参考下さい。 本題 ざっくりサマリー Golden-Retrieverは、RAG（Retrieval Augmented Generation）を、業界特有の用語・社内用語を含むような質問に強くするための手法です。カリフォルニア大学の研究者らによって2024年8月に提案されました。 従来のRAGシステム

LLMのRAGアプリケーションにおけるオブザーバビリティを向上するツール「Phoenix」の紹介 始めに こんにちは、エンジニアの大橋です。 LLMを用いたRAG（Retrieval-Augmented Generation）アプリケーションの開発において、精度向上のための評価方法に悩まれている方も多いのではないでしょうか。 今回、AssuredではRAGアプリケーションの評価にPhoenixというツールを導入してみました。Phoenixを利用することで、LLMに何を入力しどんな出力を得られたのかを可視化し、品質を改善させるサイクルを素早く行えるようになり、RAGアプリケーションの精度向上に非常に有用だったので、その活用方法をご紹介したいと思います。 実はPhoenixを使い始める前に、DeepEvalというLLM評価ライブラリのみを利用して、LLMの生成結果の評価を行おうとした時期があり

「NotebookLM」は、ユーザーが独自のチャットボットを作成できるグーグルのAIサービスだ。2023年夏に米国で試験運用が開始され、2024年6月のアップデートで日本でも利用可能となった。今回は、NotebookLMの使い方やメリット、ChatGPTのGPTsやClaudeのProjectsといったほかのカスタムチャットサービスどのような違いがあるかについて解説する。

中途採用で面接の時にはサービスに積極的に携わりたいと言っていたのに、いざ入社すると受け身姿勢な仕事になってしまい、積極的にサービス向上には関わらなかったり、自分自身から問題意識を持てないと周りからは思われてしまうケースがあります。 仮説としては、 １．前職がクライアントワークだったり、与えられる仕事に対してアクティブに関わるというよりは、受け身的に仕事をする姿勢が板についてしまっている中途採用のケース ２．どうやったらサービスに興味を持ったら良いかわからないケース。当人はやってるつもりだけど周りからできているとは見なされない。考え方が足りないとか、考える方法がわからないとか、考えてる量が圧倒的に少ないようなケース などが考えられます。一定、そこそこの規模のサービスになったりすると、自分自身が関与しているドメインが狭く見えてしまったり、もしくは大きなレバレッジを生み出す余裕がないと思ってしま

不確実性の高いプロダクト開発や、継続的な価値提供を行なっているサービスにおいては、フロー効率を重視するのが良いとされている。ある価値が早く顧客に届く方が、早くフィードバックを得られるとか、顧客が享受する価値の総量が大きくなるとか、様々な方向からメリットは説明され尽くしている。それには同意する。 開発プロセスの文脈でもフロー効率を重視するためのプラクティスは一般的だと思う。スクラムの言葉に従えば、スプリントゴールはなるべくシンプルにひとつにしようとか、ひとつのプロダクトバックログアイテムを複数人で片付けようとか、そういった話である。チームの付加価値生産性を最大化するために、こうしたやり方を採用するのは素朴には理にかなっていると思う。しかし最近、メンバーの育成や評価に対する責任が大きくなってきて、その立場から改めてこれらのプラクティスを考えると、手放しに最高とは言い切れないなと葛藤している。