CLIP+Faiss+Streamlitで画像検索アプリを作成してみる - OPTiM TECH BLOG
R&Dチーム所属の伊藤です。気がついたら半年ぶりくらいの投稿になってしまいました。 今回はrinna株式会社より公開された言語画像モデルである日本語対応CLIPを使ってみた話になります。 元々はCLIPとFaissを組み合わせて画像検索のためのツールを作れないかを試していたのですが、どうせだったら可視化までしようと考えてStreamlitを使用したアプリ化も行いました。 今回作成したコードはGithubのリポジトリにありますので、興味がある方は覗いてみてください。 CLIPとは？ Faissとは？ CLIPとFaissで画像検索 事前準備 画像ベクトルのインデックス作成 インデックスを読み込んで画像検索 Streamlitで画像検索アプリを作成する 最後に CLIPとは？ CLIPはOpenAIより提案された、テキストと画像を使用して画像分類モデルです。 CLIPはContrastive
データベース自作勉強会・輪実装会のススメ - エムスリーテックブログ
先日、社内有志で開催していたDB自作本 Database Design and Implementation の輪読会ならぬ輪実装会がついに完結を迎えました。 RDBMSをゼロから、毎週一人ずつ、1章分を実装してPullRequestを出しつつ資料も準備して発表をこなすという一見ハードな勉強会で、完走できるか不安もありつつスタートしましたが、やってみるとめちゃくちゃ楽しく最後まで完走できました。 本記事ではみなさんに「うちでもやってみたい」と思ってもらえることを願って、読んだ本の推しポイントや、どのように勉強会を進めたかを紹介したいと思います。 感動で涙の出るコード Part1: おすすめポイント 本が良い みんなでワイワイやるのが良い 3ヶ月で完走できるのがいい 完走後のモチベーションアップが良い Part2: 輪実装会 募集 参加者 進め方・実装 期間 Part3: おれたちのDB実装
またRustでB+Treeかいたよ - totechite's blog
Rust標準ライブラリのBTreeMapの実装コードを参考にB+Treeをフルスクラッチで実装しました。 get, insert, remove, rangeなどの基本的な操作は実装できているので、ひとまずここに記録します。 ソースコードはGitHubリポジトリに公開しています。そちらもみて見てください github.com どなたかのB+Treeの実装や理解の参考になれば幸いです。 (1600行程度で収まったのでstd::collections::btree_mapより追いやすくなっていればいいなと) 実装した主な操作 Rustっぽい疑似コードです。細かい仕様はソースコードみてください。 fn get(key) -> Option<value> 入力に全順序なkeyを取る。もし要素が存在すれば、そのvalueを出力する。 fn insert(key, value) -> Option<o
DB初心者が自作DBMS始めてみた - Qiita
この記事は DeNA 24 新卒 Advent Calendar 2023 の 23 日目の記事です。 TL;DR DBMSの基本的な仕組みを知るのに有益だったリソース CMUのDBMS講義 先人の素晴らしい自作DBMSの解説記事&ソースコードリーディング 小さな小さな自作DBMSの設計と実装 最小限SELECTやINSERTなど基本的なSQLが動く この記事のゴール データベースの内部構成を超ざっくり理解するために有用なリソースを知り、そして（全開発者のロマンである）自作 DBMS に一歩踏み出すきっかけになればうれしいです。 モチベーション 自分は普段業務でアプリケーションのような割と高レイヤーな開発がメインなこともあって、ミドルウェアやOS、ネットワークと言った低めのレイヤーに憧れを持っており、この気持ちをまずは自作DBMSをやってみることによって解放してあげようと思ったことがきっか
AndroidスマホでNostrP2Pのサーバが動いた - Ryoの開発日記 Neo!
先日以下のような記事をQiitaに書いたのですが、サーバをずっと動かすとなるとそれが可能なマシンを用意できるか、持っているかが問題だよなー、とか考えてました。 qiita.com で、そういえば、AndroidスマホならTermuxというAndroid端末内に独自Linux環境を構築するアプリがあるので、使わなくなったAndroidスマホなんかを有効活用して、サーバ動かしておくというのは悪くないのでは、と思い試してみたところ、見事動きました! （そもそもAndroidはLinuxの一種なので、アプリがユーザに見せるシェルにおいてだけ、chrootでファイルシステムのルートの位置を変更して、あれこれ必要なファイルを配置してあげれば、独自のLinuxユーザランドが作れるよね、というのがTermux、という認識） まずは、下のサイトなどを参考にしつつ、Fdroidアプリを経由してTermuxをイ
ピュアP2P分散マイクロブログシステム NostrP2Pを作ってみた - Qiita
こんにちは。 ryo_grid です。 今回はピュアP2P分散マイクロブログシステム NostrP2Pというものを作ってみたのでそれについて書いてみます。 ひとまず開発物のGitHubリポジトリはこちら ryogrid/nostrp2p ryogrid/flustr-for-nosp2p アイキャッチ画像です。 前提知識 Nostr プロトコルについてのざっくりとした理解 こちらの記事などに目を通しておいていただければ十分かと 開発しようと思った経緯 元々NAT透過なオーバレイ上で動作するピュアP2Pなアプリケーションを作ってみたかった DHTベースの分散KVSを作ったことがあったが、NATの壁を超えることはできなかった 上の思いから、ひとまずgossipプロトコルなどで雑にNAT透過なオーバレイを実装できないか考えていた => そのものずばり、どころかよりインテリジェントな実装であるwe
userspace RCU(QSBR)の使い方と解説 - くまメモ
http://lttng.org/urcu|Userspace RCU という大変クールなプロジェクトがあります。 「RCU（リードコピーアップデート）をユーザースペースで行うもの」という事で、そこだけ聞くとなんのこっちゃという感じ。 リードコピーアップデートって何よ リードコピーアップデートそのものの正しい説明はWikipedia*1 でも読んでもらうとして、Wikipediaを読むのすら面倒な人の為に説明すると「みんなで共有してるデータをfree()しても良いタイミングを見極める技術」です。 特定の構造体をみんなで共有して書き換えたりしたいな → Lockとればよくね？ すごく頻繁にアクセスするし読み出しの方が多いからLockはやだな → Read-Write Lockでよくね？ Read-Write LockだとAtomic命令多すぎてパフォーマンスでないな → Lock無くしてデー
オリィ研究所・ソラコム共催 Web通信/配信サービスの裏側公開 開催レポート！
みなさん、こんにちは！ソラコムでソラカメの事業開発を担当しております高見（ニックネーム：yuu）です。 2023年4月27日に、分身ロボット「OriHime」をはじめとするコミュニケーションテクノロジーの研究開発・製造販売をされている株式会社オリィ研究所と株式会社ソラコムの共催でネットワークエンジニアのMeet Upイベント「Web通信/配信サービスの裏側公開」をオリィ研究所が運営する分身ロボットカフェDAWN ver.βにて開催しました。 本記事では、当日のイベント内容や会場の雰囲気についてご紹介します。 プレゼン：「ソラカメ」の映像配信技術についてご紹介 まずトップバッターは株式会社ソラコムのソフトウェアエンジニアである松下こと、ニックネーム名：kokiから「ソラカメの映像配信技術」と題して、発表しました。 松下はリモート参加でしたが、今回はオリィ研究所の分身ロボット「OriHime」
Bluesky meetup in Osaka Vol.2 (2024/04/14 13:30〜)
なんとTokyo開催に続き、 Bluesky Meetup in Osaka も開催します！ BlueskyチームのWhyさんが大阪にも来てくれることになりました！ 前回(2023/4/7)の東京開催の様子 ※画像提供 東城朱音さん ブログ記事 前回(2023/4/7)の東京開催のメディア記事 ITmediaの記事 ギズモードの記事 前回の大阪開催はBluesky上でしか募集していませんでしたが、去年の6/25に大阪でもmeetupという名のBBQを開催していました。 なので今回は大阪開催２回目です！ Bluesky とは Blueskyは、もともとTwitter社が開発を主導していた分散型のSNS。 ジャック・ドーシー氏がTwitterに居た頃から開発が開始され、2021年に暗号資産 Zcashのソフトウェアエンジニアの経歴を持つJay Graber氏がプロジェクトリーダーに任命されてい
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - better_hacking_life
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
ピュアP2P分散マイクロブログシステムの第一歩 - Ryoの開発日記 Neo!
オーバレイでメッセージをブロードキャストできるだけのものができた！ https://github.com/ryogrid/buzzoon/releases/tag/v0.0.3 構想はコレ: みんなで頑張る分散ピュアP2Pマイクロブログシステム（Buzzoon） · GitHub 試し方（サーバ起動） ryogrid.net:9999 ryogrid.net:8888 に既にオーバレイネットワークに参加しているサーバが2匹いるのでどちらかに接続。 バイナリはWin環境なら buzzoon.exe、Linux環境なら buzzon_linux、Mac環境ならbuzzoon_mac ローカルのサーバは下のように起動 $ .\buzzoon.exe server -l 0.0.0.0:20000 -p 1985 -n ryo -b ryogrid.net:9999 -l オプションはバインドする
自作RDBMSやろうぜ!
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
ハッカーのおもちゃとしてのNostrのススメ - Qiita
はじめに Nostrという、SNSのようなものはご存知でしょうか？ ご存知でなければ、ぜひまず一度触ってみることをお勧めします。 割と普通にSNSっぽく使えます。 分散系SNSっぽいシステム Nostrは、分散系のSNSっぽいネットワークです。 図で表すとこんな感じ。普通に想像するWebサービスとは随分形が違うと思います。 各所のリレーサーバーに、ユーザーは投稿をばらまき、ユーザーがそれを見る形です。 分散の責任がユーザー(クライアント)側にあって、リレーサーバーが落ちたり消えたりしても影響が起きにくい仕組みです。 より詳しい説明は上記でやってるのですが、端的に言って 中央管理者がいない(各リレーに管理者はいる) 冗長で災害に強い Websocketのリアルタイム通信 オープンでシンプルで、でも拡張し放題な仕様 数多のサーバーによる分散ネットワーク といった特徴があります。 ※P2P技術は
Lightning Memory-Mapped Database（LMDB）について調べてみた - Qiita
はじめに これは データベース・システム系 Advent Calendar 2023 の12/23の記事である そして Nostr (2) Advent Calendar 2023 の12/2の記事である LMDBというDBMSについて調べてみた内容をつらつらと書く Discraimer 筆者はデータベースシステムの専門家ではないため、頓珍漢な記述をしている可能性あり。その点ご留意頂きたく。誤っている点があれば指摘頂ければ幸甚 一部、推測に基づいた内容あり。それらの箇所は推測に基づいている旨分かるように記述する （実装を確認するといったところまでは行えなかったため） LMDBについて調べようと思ったきっかけ nostrなる分散アプリケーションのための通信プロトコル・アーキテクチャがある 比較的自由度の高いものであるが、現状の主なアプリケーションが分散SNS（マイクロブログ）であるため、その
LevelDB入門 (基本編) - from scratch
さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDB は Google のBigTableをベースにしたアーキテクチャを持
ChatGPTに匹敵する性能の日本語対応チャットAI「Vicuna-13B」のデータが公開され一般家庭のPC上で動作可能に
Vicuna-13BはChatGPTの90％の性能を持つと評価されているチャットAIで、オープンソースなので誰でも利用できるのが特徴です。2023年4月3日にモデルのウェイトが公開され、誰でも手元のPCでチャットAIを動作させることが可能になったとのことで、早速使い勝手を試してみました。 GitHub - lm-sys/FastChat: The release repo for "Vicuna: An Open Chatbot Impressing GPT-4" https://github.com/lm-sys/FastChat/#vicuna-weights 2023年3月30日にはオンラインで動作を試せるデモ版が公開されていました。デモ版の様子は下記の記事で確認できます。 ChatGPTやGoogleのBardに匹敵する精度の日本語対応チャットAI「Vicuna-13B」が公開され
Nostrで電車男みたいな大捜索劇があったのでそのチラ裏トーク的な何か - 拝啓 たけのこの里より。
今北産業 Nostrユーザー(以下Nostr民)のひとりが東京駅で電車を降りるときに車内にリュックを置き忘れてしまった 別のNostr民が折り返しの電車を特定し、近くまで来ていた別のNostr民がNostr上の投稿を頼りにリュックの在処を発見して回収し、本人に直接届けた これら一連の出来事がNostr上で実況され、在りし日の2chを彷彿とさせる出来事として盛り上がった そもそもNostrって何？ 長くなるので詳細は割愛するけど、一見すると分散型SNSっぽい何か。でも厳密にはSNSではない。 Twitterヤバいよね、の流れでここ1〜2ヶ月でちょっとずつ盛り上がってきた。 基本的に全ての投稿が公開鍵暗号方式で電子署名されており、署名時に使う秘密鍵と公開鍵のペアが個人を特定する識別情報になる。 ここまで読んで初見で理解できる人間はほぼ居ないと思うので、詳しくは日本ユーザー有志によるScrapb
私の考える最強のNostrプロトコル拡張（考え中） - Ryoの開発日記 Neo!
分散システムに明るいと自称している私なので、Nostr *1なアプリケーション（ここではマイクロブログ型SNSとする）をスケール可能（全体のユーザ数が増加しても使えるものであり続ける）にするためにはどうすればよいかと、思考実験レベルで考えてみている。 これならいける！というところにはたどり着いていないけれど、アイデアとか、糸口になるかなーみたいな気づきはあったのでここに記す。 Nostrの特徴として維持されないといけないこと 大事。 中央集権的なサーバに頼らない リレーサーバは気軽に建てられて運営をやめてもユーザに迷惑がかからない （ボランティアベースになるというところはひとまず仕方がない、ということにしておく） リレーサーバに要求されるマシンスペックや通信リソースがべらぼうな量にならない クライアントはそれなりに遅延なくデータを取得できる （ピュアP2Pなアーキ等だと遅くなりがちであると
（Nostrプロトコルの）リレーサーバ実装 strfry について調べた - Qiita
どうも、ryo_gridです。 strfryなるNostrプロトコルのリレーサーバ実装が、他の複数のリレーサーバからデータを受信したり、クライアントから送信されたデータをフォワードすることで、クライアントは自分だけに接続すればいいぞー、みたいなことできるらしいと耳にして、それはクライアントの負荷も減るしええやん、とドキュメントとコードを読んで分かったことを共有します。 注:同じようなGitHubリポジトリへのリンクが表示されていますが、ページ内リンクがついていてそれぞれ飛び先は異なります リレーサーバのデーモンとしては単体で完結するような作りになっている模様 自身に接続してきたクライアントの相手を普通に行うのが基本で、その中で受け取ったイベントデータは自身のDBに格納する。 他のリレーサーバとのやりとりはCLIなコマンドが用意されていて、それを用いて行う 主には、イベントデータの受信および
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
