生命の起源と人工生命の研究分野は、生命の本質とその発生過程を探求している。両分野とも、「非生命」の状態から「生命」がどのように生まれるかを問うている。生命が出現するほとんどの基質に共通する特徴の一つは、自己複製が始まると同時に、その系の動態が大きく変化することである。 しかし、自然界で自己複製体がどのように発生したかについていくつかの仮説はあるものの、自己複製体が出現するための必要条件については、まだほとんど解明されていない。 研究チームは、単純なプログラミング言語や命令セットを用いて、計算環境における自己複製能力を持つプログラム（自己複製プログラム）が自然発生する過程を詳細に観察し分析した。この研究の中心となったのは、「Brainfuck」（BF）という極めて単純な言語を拡張した「Brainfuck Family」（BFF）と呼ばれる言語環境である。BFFでは、64バイトの長さを持つ13

2024-07-13「大吉祥寺.pm」の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。

NTT基礎数学研究センタでは、数学の基礎研究をとおして科学技術の源泉である「知の泉」をより豊かにしたいと考えています。本稿ではまず、NTT基礎数学研究センタでの研究の全体像を俯瞰します。さらに、センタの中心的な研究領域である「数論、特に数論力学系」「代数幾何・数論幾何」「表現論・保型形式」について紹介します。 およそ2500年前のギリシャで、素数の研究がなされたことは驚きです。素数が無限に存在することや自然数が素数の積に一意に分解できることが示されていました。どんな動機があったのかは不明です。しかも1977年のリベスト、シャミア、エーデルマンによるRSA暗号方式の発明まで、その工学や社会での応用は期待さえありませんでした。加えてRSAの鍵となる「 を素数、 を整数とすれば が成り立つ」というフェルマーの小定理（1）の発見（証明はライプニッツ）後も、その確立に300年余を要しました。 数論（

概要 「インターネットの中身」についてどれぐらい知っているでしょうか？ インターネットを普段から当たり前のように使ってる人は多いですが、その裏側の仕組みについて知っている人は、決して多くはありません。(IT業界で働く人であっても、インターネットを構成する深い部分まで理解している人はごく一部だったりします。) 本講演では、業界歴13年の現役ネットワークエンジニアであり、YouTubeにて5年に渡って情報発信してきた発表者が、ネットワーク業界関係者しか知らない「インターネットの裏側の仕組み」について、ディープに、かつ初心者にもわかりやすい言葉遣いで噛み砕いて解説させていただきます。 インターネットの仕組みやネットワークインフラの存在を知ることで、みなさんが普段お使いのサービスの裏側が理解できるようになるのはもちろんのこと、みなさんの業務においても、的を射たビジネス企画やサービス提案が実現できる

Amazon Web Services ブログ 日本最速のスーパーコンピューター「富岳」はなぜAWS上で仮想化されたか 本記事は、2024年4月16日に公開された Why Fugaku, Japan’s fastest supercomputer, went virtual on AWS を翻訳したものです。翻訳は Solutions Architectの佐々木が担当しました。 日本の富士山（富岳） 世界で最も有名な山頂の1つに登ろうとするとき、最初に山へのアクセスのしやすさを考える人は少ないかもしれません。富士山はその高さと裾野が広いことで有名ですが、国によって登山道が整備されているため、初心者のハイカーでも時間をかけずに登ることができます。現在、世界最速のスーパーコンピューターの1つである「富岳」の開発者たちは、このスーパーコンピュータをアマゾンウェブサービス（AWS）クラウドでもアク

Gemini 1.5 モデル をお試しください。Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダル モデルです。 試す ※この投稿は米国時間 2024 年 6 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。 Google Cloud ネットワーキング チームは長年にわたり、お客様のネットワークの構築、修正、強化の支援に深く携わってきました。その間に、ネットワークのパフォーマンスと効率を最大限に高める重要なパターンやベスト プラクティスを発見しました。この豊富な知見は、ただの理論的なリソースではありません。Google Cloud、クロスクラウド、オンプレミス、その他のクラウド プロバイダなどデプロイ先を問わず、お客様のビジネス目標達成を支援するよう設計された実用的なツールキットです。Google はこの専門知識を共有する

はじめに現代のWebアプリケーションにおいて、ユーザが写真や動画などのファイルをアップロードする機能は、しばしば求められます。 本記事では、ファイルアップロードを実現するための一手段として、「署名付きURL」を利用した方式を取り上げ、その設計について詳しく解説します。 今回は、Amazon Web Services（AWS）を利用する前提のもと、このアプローチを探求していきます。 前半部分は署名付きURLをそもそもよく知らない方向けの導入部となっていますので、要点だけ抑えたい方は設計上のポイントから読まれることをお勧めします。 ファイルアップロードの実現方式パターン署名付きURLの話をする前に、ファイルアップロード機能をWeb APIとして実現する方式について、いくつか代表的なものを紹介します。 Pattern 1. multipart/form-datamultipart/form-da

大規模言語モデル (LLM) の学習データに含まれない知識（各社の特有の書類など）を踏まえてLLMに回答させる際に最早必須となってきたRAG (Retrieval-Augumented Generation)。 今回はそんなRAGのSurvey論文を元に、RAGの変遷や構成要素、新たに出てきた技術を俯瞰していきます。 Survey論文へのリンクはこちら arxiv.org RAGとは LLMはそれ単体で回答させると、質問によってはハルシネーションや学習時のデータにはなかった情報を生成時に加味できないといった問題から正しくない回答を生成することが多々あります。例えば世間一般に公開されていない自社の就業規則や業務標準についてをChatGPTに質問しても、正しい回答は得られません。 そのような問題への対応としてRAGが使われます。 「LLM単体で適切な回答を生成できないなら、ユーザーの質問を元に

開発の生産性を高める新たな視点〜開発生産性フレームワークSPACE〜 での登壇資料です

2024年7月1日、OpenSSHの開発チームは深刻な脆弱性 CVE-2024-6387 が確認されたとしてセキュリティ情報を発出し、脆弱性を修正したバージョンを公開しました。この脆弱性を発見したQualysによれば、既定設定で構成されたsshdが影響を受けるとされ、影響を受けるとみられるインターネット接続可能なホストが多数稼動している状況にあると報告しています。ここでは関連する情報をまとめます。 概要 深刻な脆弱性が確認されたのはOpenSSHサーバー（sshd）コンポーネント。脆弱性を悪用された場合、特権でリモートから認証なしの任意コード実行をされる恐れがある。 悪用にかかる報告などは公表時点でされていないが、glibcベースのLinuxにおいて攻撃が成功することが既に実証がされている。発見者のQualysはこの脆弱性の実証コードを公開しない方針としているが、インターネット上ではPoC

中間管理職は限界なのか？本記事は、本日2024年7月1日21:00にNewsPickで放映される【2Sides:中間管理職は不要か？】という番組に関連した記事となります。 動画については、『罰ゲーム化する管理職』など、数々の名著を生み出していらっしゃる、パーソル総合研究所の小林祐児さんとMCの加藤浩次さんとのセッションであり、最終的には明るい内容でまとまっています。 本記事については、本動画で提唱している「マネジメント民主化モデル」について解説しつつ、坂井の会社でエンジニア採用を開始することに伴い、「なぜ坂井が本事業をやっているのか？」についても触れていきたいと考えています。(※採用情報は末尾となります) 形骸化する管理職研修昨今、小林祐児さんの『罰ゲーム化する管理職』に代表されるように、「管理職の過剰負荷問題」が騒がれるようになりました。 実際に、坂井も企業のマネジメント基盤の支援をする

はじめに 2024年1月にリテール(ネットショップ・レジ)部門からサービス(予約)部門に異動になった @ucks です。 異動してからはスマートリストという機能の開発を行っていて、5月6日に無事リリースできたのと、開発途中で障害に至ってしまった部分があるので、裏側を少し紹介しようかなと思います。 はじめに スマートリストとは スマートリストの設計 検索の仕様変更 高負荷時のハンドリング そして障害へ 見逃した点 DBの実行計画確認時の見逃し 動作確認時の漏れ 監視先の漏れ ログの損失 おわりに スマートリストとは スマートリストの開発についての話を行う前に、まずはスマートリストについて簡単に説明しておきます。 スマートリストとは、特定の条件の顧客をラベリングする機能です。 早い話、最終予約日がいつ、予約回数が何回以上等の顧客の検索条件を保存しておいて、閲覧時にラベリングして、視認しやすくし

はじめに ChatGPTブームがひと段落した感がありますが、周りのエンジニアでChatGPTを活用している姿をあまり見みません。 基本的なテクニックを理解すれば、エンジニアこそChatGPTを活用できると思うので、普段使用しているテクニックをいくつかピックアップして紹介します。 プロンプトの記載方法 Markdown記法で指示する 色々なところで紹介されていますが、回答や処理の精度を上げる方法としてChatGPTへの指示にMarkdown記法を使用することがオススメされています。 例えば下記のような文章による指示を行おうとした場合

KDDIアジャイル開発センターのpiyonakajimaです。 突然ですが、あなたは登壇スライドの作成にどれぐらいの時間をかけていますか？ 6/21-22に開催されたScrum Fest Osaka 2024に登壇した際、Markdown+生成AIを活用して登壇スライドを作成しました。その際、45分の登壇資料作成を75%効率化（自分比）できました。 普段からMarkdownで資料を作成している方からすると、これまで時間かけすぎやろ、というツッコミが聞こえてきそうですが、登壇資料の作成時間に悩まれる方は沢山いらっしゃるのではないかと思います。今回はこの時に実施した工夫をお話します。 以下がMarkdown(Marp)と生成AIを使って執筆した45分の登壇資料です。一部PowerPointで作図した過去資料から流用しています。 Marpでは、たとえば以下のようなmarkdownを書くと、 --

t-wadaさんのセッションを聴講したこと 2024/6/29に開発生産性カンファレンスに参加してきました。 その中でなんでもかんでもE2Eテストでも実行してしまうことがあるけど、 悪ではないけどデメリットもあるよ。って話がありました。 speakerdeck.com スライドP47のアイスクリームコーンとピラミッドの図だけはご参照ください。 頭の中にその図が残っているため、前提になってます。 セッションの概要 アジェンダからざっくりお話は 信頼性の高い 誤検知（テストとして正常であるはずがエラーになってしまう）や見逃し（エラーがあっても正常にしてしまう）がないこと 実行結果 実行結果値だしたり、エラー原因が特定しやすいテストを書くこと 短い時間で到達 確認したい観点を確認できる最小のテストスコープ（単体テスト、結合テストなどの粒度）でテストできるようにすること 状態に保つ 短い時間で到達

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命

こんにちは、羽山です。 みなさんは業務に LLM（生成AI）を活用していますか？ラクーングループでは生成系AI LT大会を開催するなど、積極的な利用を推し進めています。 そこで今回は私がその生成系AI LT大会で発表し、隙間時間で開発して、社内で幅広く利用されるに至った AIアシスタント「おっさんずナビ」を紹介します。 おっさんずナビは LLM + RAG（Retrieval-Augmented Generation）を利用した Slackボットで「ラクーンホールディングスの社風を教えてください」という質問に 社内事情を踏まえた回答 をしてくれます。 ファインチューニングを利用せず RAG のみで精度を高めているのと、ベクトルDBなどの外部リソースを必要としないのがポイントで、使い込まれた Slack ワークスペースさえあればアプリを起動するだけで 社内事情通のAIアシスタント ができあが

KDDIアジャイル開発センターのpiyonakajimaです。 突然ですが、あなたは登壇スライドの作成にどれぐらいの時間をかけていますか？ 6/21-22に開催されたScrum Fest Osaka 2024に登壇した際、Markdown+生成AIを活用して登壇スライドを作成しました。その際、45分の登壇資料作成を75%効率化（自分比）できました。 普段からMarkdownで資料を作成している方からすると、これまで時間かけすぎやろ、というツッコミが聞こえてきそうですが、登壇資料の作成時間に悩まれる方は沢山いらっしゃるのではないかと思います。今回はこの時に実施した工夫をお話します。 以下がMarkdown(Marp)と生成AIを使って執筆した45分の登壇資料です。一部PowerPointで作図した過去資料から流用しています。 Marpでは、たとえば以下のようなmarkdownを書くと、 --

開発生産性Conference 2024で発表した資料です。 https://dev-productivity-con.findy-code.io/2024?m=2024/m/XmiKkhYo

2024年6月29日 Findy 開発生産性カンファレンス2024 Closing Keynote https://dev-productivity-con.findy-code.io/2024