本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。 という感じで、Suggesterのデータ構造とか仕組みを書こうと思っていたのですが、思ったよりも調べないといけないことが多くて挫折しました。。。 (これの続きは年末年始で調べて書くはず?) ということで、代わりにElasticsearch/OpenSearchのアーキテクチャの変更に関してさらっとまとめてお茶を濁してみようと思います。 発端はElasticON Tokyo? 先週の11月30日に、ElasticのオフラインイベントであるElasticON Tokyoが開催され参加しました。 参加しようと思ったのは、10月の頭にElasticのブログで公開された「Stateless — your new state of
1971年福井県生まれ。得意ジャンルは、パソコン・デジタルAV・家電、ネットワーク関連など「電気かデータが流れるもの全般」。主に、取材記事と個人向け解説記事を担当。 iPhone 14シリーズには、衛星と通信をして緊急通報をする機能が搭載されている。この機能は現状、アメリカとカナダでのみ使える。 11月から使用可能になっているのだが、現在米ラスベガスに出張中なので、デモ機能で実際にどんな感じなのか試してみた。 ▲砂漠の真ん中ラスベガスで、遭難していないけど「緊急通報」をデモ機能で体験 ※この記事は、毎週月曜日に配信されているメールマガジン『小寺・西田の「マンデーランチビュッフェ」』から、一部を転載したものです。今回の記事は2022年12月5日に配信されたものです。メールマガジン購読(月額660円・税込)の申し込みはこちらから。コンテンツを追加したnote版『小寺・西田のコラムビュッフェ』(
数理最適化 Advent Calendar 2022の9日目です。 新緑の頃、新型コロナ流行の合間をぬって、ささやかな結婚披露宴を表参道の式場にて催しました。諸々の準備の中でも席次はこだわるとキリがなく、数理最適化を使って決めました。人間関係をできるだけ保つようなゲスト集合から座席集合への写像を考えます。 ゲスト間人間関係を考慮して良い感じの配席を考えたい tl;dr 披露宴をしました 知り合い関係が複雑かつ長机でゲストの席配置が難しい 組合せ爆発は本物。高々20人の配置に1週間以上悩んだ結果、数理最適化した方が早いと結論 「知り合い同士を近くに配席する」問題は非凸な二次計画になり汎用ソルバでうまく解けない ゲストを席に"輸送"すると考えて最適輸送の一種で解くとうまくいった 本質的に非凸な問題を非凸のまま、しかし性質の良い距離構造を活用するアプローチが奏功したのではないか 再現用Colab
2022年は画像生成AIに代表される「生成AI」が一大ブームとなった。次に話題になりそうなAIは何だろうか? by Melissa Heikkilä2022.12.09 21 12 この記事は米国版ニュースレターを一部再編集したものです。 2022年は、生成AIの分野でブレークスルーが相次いだ。例えば、数個の単語から動画を生成する人工知能(AI)や、曲の断片からそれに続くメロディを生成するモデルなどだ。 グーグルは先日、マンハッタンのハドソン川沿いにある洒落た真新しいオフィスで、AIイベントを開催した。私はその騒ぎにつられて立ち寄ってみた。グーグルもまた、現在のトレンドの合わせて、生成AIの成果を次々と発表している。その1つに、テキストから動画を生成する同社の2つのAIモデル、フェナキ(Phenaki)とイマジェン(Imagen)を組み合わせたシステムがある。フェナキが、脚本のように見える
業界のトップを走るビジネスパーソンに仕事の「こだわり」を聞く新連載「トップランナーの流儀」が始まります。 今回ご登場いただくのは、おもちゃ開発者の高橋晋平さんです。バンダイ在籍時に手掛けた「∞(ムゲン)プチプチ」が、国内外で累計335万個売れる大ヒットを記録。現在もさまざまなおもちゃメーカーと協業しながら、世間をアッと驚かせるようなおもちゃをつくり続けています。 その一方で、新人時代は企画がなかなか採用されなかったり、体調を崩して1年半も休職したり……すべてが順風満帆なわけではありませんでした。 そうした試行錯誤のなかから、一体どんなこだわりが生まれたのでしょうか。高橋さんのこだわりには、アイデアを生み出し、アイデアを形にする「本質」が詰まっていました。 高橋晋平。1979年、秋田県生まれ。2004年、株式会社バンダイに入社し、「∞プチプチ」などバラエティおもちゃの企画開発・マーケティング
Goodbye to the C++ Implementation of ZigHow we used WebAssembly to annihilate 80,000 lines of legacy codeAuthor: Andrew Kelley It’s funny - I have shared this story a handful of times with friends of mine who are qualified, competent software engineers, and each time the response was confusion about why any of this would be necessary or even remotely helpful. WebAssembly?! After ten minutes of puz
この記事は ANDPAD Advent Calendar 2022 の 9日目の記事です。 こんにちは柴田です。 Ruby のフルタイムコミッタとして活動を開始した 11/7 から 12/1 までに行った Ruby の開発についてご紹介します。 毎日多くの時間を Ruby に費やす事ができるようになり、最初に手をつけたのはつぎはぎの時間では集中して解決まで持っていく事が難しかった ruby-lang.org の裏側にあるサーバー群のリプレイスです。 今回は複数のサーバーのうち、neon と呼ばれる debian で稼働し続けていたメールサーバーを別の何かしらの SaaS またはクラウド環境へ同等の機能を有したまま移設を行う部分を担当しました。この neon というサーバーは私が Ruby コミッタになった10年ほど前から NaCl の shugo さんが管理する Xen 環境で稼働を続けて
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売!クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太(うひょ),川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ!という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
これは Livesense Advent Calendar 2022 DAY 8 の記事です。 転職ドラフトでエンジニアをしている verdy_266 です。 僕の2022年を振り返ると、採用広報チームでの活動を無視することはできません。転職ドラフトの開発を行う傍ら、昨年末に採用広報チームにジョインし、記事の執筆や校正に多くの時間を割いてきました。 今まで記事を投稿したことがなかったこちらのブログにも共作含め5記事を投稿し、11月には Software Design への寄稿の機会をいただくこともできました。文章を書くことが思った以上に好きなんだなと発見があった年でもありました。 made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp 弊
Amazon Web Servicesは、Linux関連のオープンソースを特許リスクから保護する「Open Invention Network」への加盟を発表しました(AWSの発表、OINの発表)。 これにより、Amazonとその子会社が持つ特許全体のうちLinux関連(正確には「Linux System definition」)についての特許がOpen Invention Networkとのクロスライセンスの対象になるとのことです。 Today we are excited to announce that Amazon has joined the Open Invention Network. AWS looks forward to working with OIN, its members, and the broader #opensource community to fur
技術者はよく、実装可否の問い合わせに対して本当はやりたくない・すべきでないと思っているのにやればできることだからと「技術的には可能です」と答えてしまいハマる⋯って本当ですか? 私は最低でもここ10年は「技術的には可能です」と発言した記憶がありません。なぜそう言うことがないかというと、可否の問い合わせを受けた時点で次のようなことを考えてしまうからです。 運用は回る? 人力操作が絡むフローがあるけど利用数が増えたときにちゃんとスケールする? 休日深夜対応が必要になりそうだけど要員と人件費コストは確保できてる? カスタマーサポート対応激増しそうだけど(以下同文 誤操作があったりしてデータの修正依頼が来たときに訂正しようがない要件っぽいけど大丈夫? エンジニアがDB直操作対応するサービスメニューが存在するけど事故リスク、工数コスト、今後の開発停滞リスクは織り込み済み? 事故の際の責任はエンジニアに
「これまではスマートスピーカーや家電、住設機器などを手掛けるメーカー各社が独自のプロトコル(規格)で囲い込みをしようとした結果、スマートホーム市場が分断されて思うように成長しなかった。そこで、プロトコルを共通化しようと世界のさまざまな企業が手を組んだ点で大きなインパクトを持つ」(三菱電機リビング・デジタルメディア事業本部IoT・ライフソリューション新事業推進センターセンター長の朝日宣雄氏)20
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く