かなり新し目のフレームワークRAGプラットフォームアプリ RAGFlowとは? RAGFlowは、深い文書理解に基づいたオープンソースのRAG(Retrieval-Augmented Generation)エンジンである。LLM(大規模言語モデル)を組み合わせることで、様々な複雑なフォーマットのデータから根拠のある引用に裏打ちされた、真実味のある質問応答機能を提供し、あらゆる規模のビジネスに合理化されたRAGワークフローを提供する。
こんにちは、Crane&Iの藤島です。 この記事で3記事目となりますが、少しずつ、自分の書くスタイルが定まってきたかなと感じます。 ありがたいことに、SEを取りまとめる事業統括という立ち位置を頂きながらお仕事をしているので、 私のこれまでのエンジニア、人生経験を交え、キャリア形成に結びつくような有益な情報をお伝え出来たらいいなと思いながら、文字を打っています。 今回は「評価されるエンジニアの特徴」に焦点を当てていきたいと思います。 最初に ちょっとした誤解を招く表現をするかもしれません。 斜め読みで構いませんので、一応、最後まで読んでください。 言い訳はちゃんと書きます(笑) 突然ですが、私は「贔屓(ひいき)」をする人間です。 併せてお伝えしますが、「えこ贔屓」は好みません。 というか、立場上、それを許されておりません。 Qiitaを利用されている方には、リーダーをやられている方も沢山いる
最近、分散データベースとかNewSQLとかサーバレスなデータベースとか色々聞きますよね。 でも、専門ではない人たちにとって、「何が違うの?」「自分たちに必要なDBはどれなの?」という点が分かりづらいと思います。 私も良く聞かれます。 AuroraはNewSQLですか? NewSQLってサーバレスなんですか? スケールできないDBとか聞きますけど、リードレプリカ増やせますよね? などなど。この辺に基本的なところから答えられるように、順を追って解説していきましょう。 「コンピュートとストレージは別であれ」 と神が言うと、コンピュートとストレージは分離された。 と言うのは冗談ですが、まずはここからスタートしましょう。 クラウド以前のデータベースを使っていた人にはお馴染みのように、それまでデータベースは大きな1つの箱でした。 過去に私は下図でデータベース(厳密にはRDBMS)のコンポーネントを解説
いつも時間に追われている、仕事漬けなのに成果が伴わない、プライベートを楽しむ暇がない……こんな悩みを抱えている人も多いのではないでしょうか。『結果を出してサクッと帰る 神速時短』の発売を記念して開催された本イベントでは、著者であり国際エグゼクティブコーチ/企業研修講師のヴィランティ牧野祝子氏が登壇。本記事では、世界10ヶ国で20年以上会社員をしてきた牧野氏が、グローバルリーダーが実践している「神速時短サイクル」について解説します。 前回の記事はこちら 仕事漬けなのに生産性が低い日本 ヴィランティ牧野祝子氏:海外の方を見ていると、みんながみんなじゃないですが、平均的に仕事に必要以上に時間を使っていない。でも、生産性が高く幸せ。ここで言っているのは、個人の生産性というよりも、チーム、会社、国、全体を見た時の生産性になります。 日本(のビジネスパーソン)は仕事漬けで、生産性が国として全体的に低く
「英語講師の話す英語はわかるのに、ネイティブ同士の会話が聞き取れない」 「映画を英語字幕付きで見ていても、同じことを役者が話しているように聞こえない」 ある程度の英語力があるにも関わらず、ネイティブの話す英語が聞き取りにくく感じてしまう原因のひとつにリエゾン(リンキング)があります。 リエゾンとは言葉の音声変化のことで、ネイティブスピーカーの英語では自然に発生しています。 このリエゾンを意識できると、相手の英語がぐっと聞き取りやすくなるばかりか、自分でもスピーキングのときにより自然な発音ができるようになりますよ。 しっかりリエゾンを身につけて、リスニングもスピーキングも、自信を持ってできるようになりましょう! 執筆者:Lin 小4までアメリカの現地校に通い、帰国後は「英語はネイティブ並みでしょう?」という周囲の誤解とプレッシャーゆえに、英語の勉強から遠ざかった過去あり。中途半端な英語力にコ
人は、ほんの些細なきっかけで、ビデオゲームから離れてしまうものです。 それまでどんなに熱心にプレイしてきた人であっても、仕事が忙しくなったり、子どもが生まれたり、そういった生活の変化の中でなんとなくゲームを触らなくなってしまい、そのまま卒業してしまうことがあります。 僕自身のことを話すと、僕は40代の社会人で、奥さんと、6歳の双子の娘の4人家族です。 忙しい生活ではありますが、なんとかゲーマーを自称できる程度にビデオゲームを遊ぶことができています。年間数十本程度の作品に触れ、こうやって定期的に文章を書けるくらいには情熱を保っています。 改めて考えてみると、これは決して自然に達成できていることではなくて、「ビデオゲームとの向き合い方」を常日頃からある程度意識的に考えているからなのかなあ、と感じています。 言い換えると、自分が現役ゲーマーであり続けるための「生存戦略」を常に頭に置いて実践してい
最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio
RPGでは当たり前に存在する「回復」と「ショップ」をなくした理由──「回復」というのはこれまでのRPGにおいて当たり前に存在している要素だと思うのですが、『サガ エメラルド ビヨンド』では回復がないとお聞きしています。なぜRPGのバトルから回復という存在を排除したのでしょうか? 河津秋敏氏(以下、河津氏): 自分としては、回復はバトルを引き延ばしてプレイヤーの時間を奪っている要素だと思っているんです。ゲームに縛り付ける時間を長くするだけの要素で、必要性を感じないんですね。 ──回復はユーザーの時間を奪っている……ですか。これまでRPGには当たり前に存在していた要素なだけにその視点は驚きです。 河津氏: それに回復があると、回復役に盾役に攻撃役にと、パーティ編成が固定化されてしまうじゃないですか。そうすると自由度がなくなる。 自分自身、HPが削られるのが嫌いなのでどうしても守りを固めて回復で
この連載ではおなじみのキャラクター「明日来子さん」に右側からライトを当ててみた。左がIC-Lightを適用したもので、右がオリジナル。環境はWebUI Forge用の拡張機能を使用 5月8日に、「ControlNet」など画像生成AI関連の著名研究者であるイリヤスフィール(lllyasviel)さんが発表した「ICライト(Imposing Consistent Light、印象的な一貫的なライト)」が盛り上がりました。入力した画像をもとに、後から指定した照明効果を踏まえた画像を生成する技術です。 画像生成AIで照明効果がつけられる「ICライト(IC-Light)」 発表された学習済みモデルは、「ライトを指定すると、キャラクターのデータに合わせてテキストのプロンプトに合わせて独自に背景を生成するもの」「キャラクターとライトの影響を加味して、別の背景画像と合成するもの」の2種類があります。これ
Ghost of Tsushimaなどを作った会社の人が書いた本です。ゲーム開発におけるコードを書く際の教訓を整理し、改めて示し直したいい一冊だったと思います。大事なことですが、著者は決して「このルールを絶対使え」と言っているのではなくて、そもそもまず会社の製品の特性上、このようなルールを敷いておくと品質や生産性を高く保てたという前提があり、その前提を元に「ルールを選び取って自分たちのコーディング哲学を構築しよう」と推奨しています。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール 作者:Chris Zimmermanオーム社Amazon この手の本では『リーダブルコード』がよく薦められる傾向にあると思います。私にとってもリーダブルコードは確かに駆け出しの頃すごく役に立った記憶はあるのですが(もう10年くらい前に読んだので正直忘れた)、そこから知識がアップデートされ
こんにちは。VP of Engineering の morizumi です この記事では2024年2月にプロダクトサイド(注:プロダクト開発に直接的に関わっている各部の総称)内で実施したフルリモートワークに関するアンケート結果のサマリをご紹介します。SmartHR では2021年7月より本格的にフルリモート体制に移行しており、移行から2年半ほどが経ちました。2年半を経て、従業員としてフルリモートワークをどのように受け止めているのか? というのを調べるために行ったのが今回のアンケートです なお、この記事は僕が書いた社内ドキュメントからほぼコピペして作っているため、一部わかりにくい用語や言い回しがあったり、若干の内輪ノリがあるかもしれませんがその点はご容赦いただけると幸いです それでは早速、アンケート結果のサマリをご紹介していきます (これ以降基本的に社内ドキュメントのコピペです) アンケート
# 開発用ステージ FROM python:3.11.9-slim-bookworm AS developer ENV PYTHONUNBUFFERED=1 ENV PYTHONDONTWRITEBYTECODE=1 WORKDIR /app RUN apt-get update \ && apt-get install -y --no-install-recommends \ wget=1.21.3-1+b2 \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt COPY . . # ビルド用ステージ FROM python:3.11.9-slim-bookworm AS build
こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 早速ですが、これは弊社のとあるチームの1ヶ月のサイクルタイムです。 最初のコミットからマージされるまで平均3.6時間程度と、開発に着手したらその日のうちにリリースされるのがデフォルトとなっています。 今回はこの開発スピードを継続し、更に速くするために弊社で実践しているテクニックを紹介していきます。 それでは見ていきましょう! タスク分解 Pull requestの粒度 テスト CI/CD 高速化 自動化 通知 まとめ タスク分解 開発タスクをアサインされた時、まず最初にタスク分解をします。 タスク分解をすることによるメリットとしては、 工数見積もりの精度が上がる 対応方針の認識を他メンバーと合わせやすくなる 対応漏れに気づきやすくなり、手戻りの発生が少なくなる Pull requestの粒度を適切に保つことが
「トカゲの尻尾切り」で建物の全壊を防ぐ!建物の破損は自然災害や車両の衝突、設計上のミスなど、さまざまな要因で発生します。 特に建物の全壊は損害が非常に大きく、中にいる人命を失ったり、のちの救助活動を困難にさせるものです。 現在の建築技術では一般的に、建物の各セクションが強固に接続されるように設計されています。 これは建物に加わった力を均等に分散するためです。 このアプローチはある程度の衝撃に対して効果的な耐久力を発揮しますが、他方で地震レベルの大きな衝撃が加わると、最初にダメージを受けた部分が全体に波及し、建物を全壊させるリスクがあります。 しかし、建物が最初にダメージを受けた部分だけを切り離すことができればどうでしょうか? 研究チームはこの着想を「トカゲの尻尾切り」から得ました。 トカゲはご存知のように、天敵に襲われると尻尾だけを切り離して逃げることができます。 トカゲの尻尾には破断面が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 公式ドキュメントを読め!Qiitaを使うな このような発言はネットで時々見かけるような内容であり、ある程度プログラミングができるような方を中心に見かけるイメージのあるものです。 私はこの発言を見るたび思うことがあります。 Qiitaに投稿すべき内容を多くの人が間違っているからこのような発言が生まれている 今回は、「公式ドキュメントを読むべき理由」「Qiitaが適切な場合」「Qiitaに投稿すべき内容」について書いていきます。 公式ドキュメントを読め 「公式ドキュメントを読め」 これは私として気持ちがものすごくわかります。 公式
大石竜子 @OoishiRyuko 我が家のアレクサの聞き分けが悪くて大きい声で指令を出していたら、猫が自分はアレクサって名前になったんだと思い込んで膝に乗ってぱやややと必死で弁明してきます。あなたはアレクサではありませんよと諭していたらアレクサがそれに反応して返事をするのでよく分からないことになっています。 2024-05-26 23:10:09 大石竜子 @OoishiRyuko xの通知が見たことのない数字に…。ありがたいので猫ちゃんの写真を貼っておきますね。本当はのびをした時の舌ペロ写真とかv字開脚してる所の美脚等を激写したいのですが距離が近すぎてなかなか良いのが撮れません。ついでに私はイラストレーターですと宣伝をしておきます。猫マンガ描こうかな… pic.twitter.com/JbKl8WZxdC 2024-05-27 15:37:30
Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は(使い古されたネタではありますが)モノレポ化についてお話ししたいと思います。 おさらい:モノレポ(mono repo)とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ(poly repo)と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること
こんにちは!Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング(XP)の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム(頭字語)から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く