You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは、つくぼし(tsukuboshi0755)です! AWS Lambdaのロギング設定を制御できるようになったというアップデートがあったので、今回試してみます! 何が嬉しいか 今までCloudWatch Logsに対するLambdaのロギング設定は、以下がデフォルトで固定され、変更できないようになっていました。 ログ形式:Text ログレベル:なし ロググループ名:/aws/lambda/<関数名> ※なおログ形式については、今までもPowertoolsを使用すればJSONに変更可能でした。 上記3点について、今回のアップデートによりLambdaのコンソールまたはAPIを通じて柔軟に設定できるようになりました! 試してみる それではどのようにログ設定を変更できるようになったか試してみましょう。 公式では以下のブログで使い方が紹介されています。 上記のブログはLambdaのランタイム
以下の記事が面白かったので、かるくまとめました。 ・Applying OpenAI's RAG Strategies 1. はじめに「Open AI」はデモデーで一連のRAG実験を報告しました。評価指標はアプリケーションによって異なりますが、何が機能し、何が機能しなかったかを確認するのは興味深いことです。以下では、各手法を説明し、それぞれを自分で実装する方法を示します。アプリケーションでのこれらの方法を理解する能力は非常に重要です。問題が異なれば異なる検索手法が必要となるため、「万能の」解決策は存在しません。 2. RAG スタックにどのように適合するかまず、各手法をいくつかの「RAGカテゴリ」に分類します。以下は、カテゴリ内の各RAG実験を示し、RAGスタックに配置する図です。 3. ベースライン距離ベースのベクトルデータベース検索は、クエリを高次元空間に埋め込み(表現)し、「距離」に基
{ "name": "lib-a", "version": "0.0.0", "type": "module", "main": "dist/index.js", "scripts": { "build": "rm -rf dist && tsc" } } この場合、lib-a の src/index.ts を変更だけしても lib-b には反映されません。なぜなら lib-b は lib-a の dist/index.js を参照しているため、build を実行して dist ディレクトリの中を更新する必要があるからです。 またこのときに tsserver の機能を使って lib-b から lib-a の参照にジャンプしても src/index.ts に飛ばないという問題点もあります。 解決策 問題の原因は依存元の lib-a の main に build によって生成されるファイルへの
登壇者の自己紹介とアジェンダ紹介 金岡亮氏:みなさんこんばんは。「LLMからはじめる、プロダクトへのAI導入」というタイトルで発表いたします。私たちSmartHRは「従業員サーベイ」というプロダクトを提供しており、その中で「要約AI」というLLMを使ったサービスをプロダクトとして出しています。これをリリースするまでにどんなことをやってきたのかというお話ができればと思っています。 私は金岡と申します。私はふだん、プロダクトマネージャーをしており、弊社のタレントマネジメント系のプロダクトを複数見ています。今年に入ってからLLM利用のタスクフォースや、AI活用のR&Dの組織を立ち上げています。前職では、AIの受託系の会社でプロジェクトマネージャーをしたり、データアナリストをしていました。 今日のアジェンダですが、機能リリース前のお話と機能リリース後のお話。あとは4つ学びと今後の展望というかたちで
Now and Next Generation of CSS Cascading Model araya @arayaryoma FRONTEND CONFERENCE OKINAWA 2023 araya @arayaryoma - FRONTEND CONFERENCE OKINAWA 2023 自己紹介 araya / Ryoma Abe x.com/arayaryoma github.com/arayaryoma bsky.app/profile/araya.dev Web standardsやBrowser APIが好き 今日はCSSの新しめの仕様について 話します araya @arayaryoma - FRONTEND CONFERENCE OKINAWA 2023 2020年4月 日経入社 日経電子版のWeb開発
At Airplane, we collect observability data from our own systems as well as remote “agents” that are running in our customers’ infrastructure. The associated outputs, which include the standard “three pillars of observability” (logs, metrics, and traces) are essential for us to monitor our infrastructure and also help customers debug problems in theirs. Over the last year, we’ve made a concerted ef
同僚と1on1していて面白い話をしたのでメモ。 プロジェクトの不確実性 前提として、自分はソフトウェアエンジニアとして働いているのだが、0→1的な仕事の場合、プロジェクトは最初は不確実で混沌とした状態にあり、しばらくの創発的な状況を通過していくことでいずれ不確実性が減っていき、最終的にはプロダクトとして結実する、という流れを辿る。 最初のうちは不確実だし、様々な可能性に目を向けることが必要な段階なので、ブレインストーミング的な感じでランダム性やクリエイティビティを誘導したりすることが多い。一方、これはビジネスなので、最終的にはプロダクトとして結実させなければならない。したがって道筋を描くための段取りはしなければならない。 よくある不確実性コーンみたいなのを思い描いてほしい。 不確実性へのアプローチ 自分は理数系の正式な教育を受けておらず、どちらかといえばいわゆる人文系な発想をしがちである。
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
概要 ゲーミングPC、ゲーミングマウス、ゲーミングキーボード、ゲーミングチェアーなど、色々ありますが、なぜか光っています。 なので、WEB画面も光らせてみようと、gaming-cssというプラグイン作成しnpmに公開しました。 セットアップ方法 下記のコマンドでインストールできます。 詳細な使い方についてはREADMEを確認して頂ければと思います。 CSSを適用 Qiitaのプロフィール画面を装飾しました! Before After とっても綺麗になりましたね!(Qiita運営さん!ゲーミングテーマはいかがでしょうか?) ちなみに、CSSを適用するのに1時間くらいかかりました。 仕組み 仕組みは、簡単です。下記のように、線・文字・背景・画像などに対してアニメーションのスタイルを用意して適用しているだけです。 /*背景色*/ .gaming-background-color { animat
GitHub.com で利用できる Markdown 記法のアラートは、これまで [!Note]・[!Warning] と 2023 年 7 月 23 日 に追加された [!Important] がありました。 このアラート記法は断続的に更新されており、2023 年 11 月 14 日にいくつかの重要な変更がなされました。 本記事では、これらの変更を紹介します。 追加されたアラート 2023 年 11 月 14 日に、これまでのアラートに [!Tip] と [!Caution] が追加されました > [!NOTE] > Highlights information that users should take into account, even when skimming. > [!TIP] > Optional information to help a user be more su
モチベーション そもそも TypeScript や JSX に詳しくないのでどう書くのがいいのか悩みたくない ESLint や Prettier の設定を なんとなく 設定して使ってしまっている Formatter / Linter 関連のライブラリの内容を理解せずにアップデートしてしまっている 依存関係は減らしていきたい Rust で書かれた言語向けの高速なツールが好き Rye とか Ruff とか efmt とか Biome Biome は Rust で書かれた Formatter / Linter を含むツール。本当におかしいくらい早い。 全然大きくないが、以下のソースコードに適用したときの速度。 $ pnpm run fmt > biome format --write ./src Formatted 114 file(s) in 11ms $ pnpm run lint > bi
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く