タグ

関連タグで絞り込む (131)

タグの絞り込みを解除

プログラミングに関するarajinのブックマーク (929)

  • LLM Embeddingを活用した問い合わせBotを社内向けに導入して効率化した話 - Findy Tech Blog


    こんにちは。 FindyでMLエンジニアをしているyusukeshimpo(@WebY76755963)です。 今回はLLM Embeddingを活用した自動応答Botを開発&導入し、社内の問い合わせ業務を効率化することができたので、その取り組みを紹介します。 Botを開発することになった背景 弊社ではSlackを使用し、自社サービスに関する社内質問に回答するチャンネルを運用しています。 主にビジネスサイドからの技術的な疑問にエンジニアが答える仕組みです。 質問はテンプレートを使って送信され、エンジニアが回答しますが、このワークフローには次のような問題が発生しています。 同じ質問が異なる人から届いてしまう 質問の度にエンジニアの工数が発生してしまう 半期で70件以上の質問が発生し、1件につき1~1.5時間かかることもあります。 多くの質問は社内ドキュメントで解決可能ですが、検索がしづらく利
    LLM Embeddingを活用した問い合わせBotを社内向けに導入して効率化した話 - Findy Tech Blog
    arajin
    arajin 2024/06/23
    “テキストデータ処理後、コサイン類似度計算のためにOpenAIのtext-embeddingを使用しました。 作成した構造化データはBot内で保持します。”
    リンク

  • 組織が記憶喪失になるのをどうすれば ～ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog


    何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした組織が記憶喪失になることにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 (@ryuzee) さんにふらっと相談してみたら一瞬で突破口が見つかった＆話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念‥ADR ADRの実践‥その1何を書くか ADRの実践‥その2どこに書くか ADRの実践‥その3どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 (@ppyv) です。 開発・検証用PCの開発に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよ
    組織が記憶喪失になるのをどうすれば ～ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog
    arajin
    arajin 2024/06/11
    「ソフトウェア開発で使われているADR: Architectural Decision Recordsっていう手法が役に立つ」「HOWはコード見れば分かるので、なんでそれを書いたの？というのを残しておく必要があります」
    リンク

  • 「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ


    Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ﹁Code Health﹂が、﹁DRYを早まって適用しないこと﹂と題した記事を公開しました。 Google Testing Blog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは﹁Don't Repeat Yourself﹂の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用
    「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ
    arajin
    arajin 2024/06/07
    「DRY原則の適用を厳格にしすぎると抽象化が早まってしまい、将来の変更が必要以上に複雑になる」
    リンク

  • 30年前のノートPCからファイルをコピーする方法


    1994年製のAppleのノートPC﹁PowerBook Duo 280c﹂に保存された音声ファイルを、現代のPCにコピーする方法をソフトウェアエンジニアのルークさんが解説しています。 How to Copy a File From a 30-year-old Laptop - Unterminated https://www.unterminated.com/random-fun/how-to-copy-a-file-from-a-30-year-old-laptop ルークさんはPowerBook Duo 280cに保存された音声ファイルを現代のPCで聴けるようにしてほしいと家族から依頼されたそうです。PowerBook Duo 280cは起動し、内蔵スピーカーも正常に動作するものの、PowerBook Duo 280c本体にはオーディオジャックがないため音声ファイルの良質なアナログコ
    30年前のノートPCからファイルをコピーする方法

  • Gitの仕組みと用語 / GitHub Term

    物理情報工学ソフトウェア開発演習

    Gitの仕組みと用語 / GitHub Term

  • プログラミングとは ― 最強のカレーレシピ ― - golden-luckyの日記


    ﹁うちの学校でもついにプログラミングの授業が始まったよ﹂ ﹁それは興味深いね。どんなふうに教えてるの？ やっぱりScratchとか？﹂ ﹁Scratch？ ああ、プログラミング言語のことか。プログラミング言語は使わなくていいんだよ﹂ ﹁え？﹂ ﹁小学校で学ぶプログラミングっていうのは、プログラミング言語を覚えさせることが目的じゃないからね。システム思考力とかロジカルシンキングって聞いたことあるだろ？﹂ ﹁あるかないかでいったら、あるよ﹂ ﹁プログラミング言語みたいなのは、単なる技術だ。それは仕事で必要な人だけが覚えればいい。子どもたちに教えるべきことは、プログラミング言語みたいな技術じゃなくて、システム思考やロジカルシンキングの延長といえるプログラミング的思考なんだよ﹂ ﹁プログラミング的思考っていうのが、システム思考やロジカルシンキングとどう違うのか、いまいちよくわからないんだけど…﹂
    プログラミングとは ― 最強のカレーレシピ ― - golden-luckyの日記

  • 接続不調が続く「OSDN」、米「SourceForge」がプロジェクトの勧誘に乗り出す／過去の不祥事がネックだが……「GitHub」への移行が難しければ有力な選択肢【やじうまの杜】

    接続不調が続く「OSDN」、米「SourceForge」がプロジェクトの勧誘に乗り出す／過去の不祥事がネックだが……「GitHub」への移行が難しければ有力な選択肢【やじうまの杜】

  • 羽生先生の発言は何が開発者の反発を招いたのか？ | やねうら王 公式サイト


    2つ前の投稿で羽生先生のインタビュー記事の発言を取り上げたらプチ炎上しました。私は特に炎上を狙ってやっているわけではなく、羽生先生の発言が将棋AI界隈に悪い影響が残り兼ねないので書いたのですが、開発関係者からは一定の同意が得られたものの、将棋ファンからは殺害予告やら、こんなツイートやらが届く始末です。 まあ、一線を越えているものに関しては関係各所と連携しつつ、粛々と対応させていただく次第です。(念のために言っておきますと、将棋ファンのすべてがこういう人たちばかりだとは私は思っていません。極一部にちょっとややこしい人がいらっしゃるという認識です。) この記事は大変長くなるので、﹁最新版のやねうら王が(お金を出してでも)欲しい！﹂と言う方や、﹁やねうら王の開発に支援してやる！﹂と言う方は、とりあえず、この記事の末尾のリンクから御支援くださいませ。 今回は、前回の羽生先生の発言を再度取り上げ、何
    arajin
    arajin 2024/01/01
    “Bonanzaを無償で公開してその後の将棋AI界をビジネスが成立しないような焼け野原にしてしまった意味もあります。”
    リンク

  • 認知負荷の種類と対策と組織文化について - すがブロ


    このエントリは、SmartHR Advent Calendar 2023 シリーズ1の3日目です。 シリーズ1の前日のエントリはalpaca sanの佐渡島の物件情報を集める方法 - alpaca- tcでした シリーズ2の前日のエントリはasonas sanのE03との戦いでした これは何 当初、Rubyを取り巻く型情報に関するツールの関係性についてまとめようと思ったのですが、既に良いドキュメントがあり、自分が満足してしまったので別の話題として認知負荷をテーマに筆をとっております。 ツールの関係性については↓のエントリをご覧ください Ruby3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ 閑話休題 認知負荷という言葉、よく聞きますよね。私もよく言いがちでした。しかし、﹁認知負荷﹂という言葉をふわふわな認識のまま﹁
    認知負荷の種類と対策と組織文化について - すがブロ

  • モノリス解体に向けたパッケージ構成 - 10X Product Blog


    CTOのishkawaです。 この記事は10X アドベントカレンダー2023の3日目の記事です。 先日、サーバーサイドのメンバーを中心として、コードをどのように分割管理していくか話すオフサイトを実施しました。オフラインで1日中話していたこともあり、話題は色々な方向に進んだのですが、その中でもモノリス解体にトピックを絞ってシェアしたいと思います(他の話は他のメンバーが書いてくれるはず！)。 前提 10Xには4つの開発チームがあります(お買い物チーム、お会計チーム、お届けチーム、マスターデータチーム)。今年の4月にチーム分割が始まり、コードやデータのオーナーシップも各チームにアサインしてきました。 この組織移行によってオーナーシップ分割は進んでいるものの、依然としてモノリスのパッケージ(Dartのパッケージ)は大きいままで、ほとんどのコードがそこにある状態でした。領域ごとのディレクトリ分割は進
    モノリス解体に向けたパッケージ構成 - 10X Product Blog
    arajin
    arajin 2023/12/06
    “業務領域を跨いた処理に対する制限が弱く、意図しない結合が生まれやすい。”
    リンク

  • プログラミングの原則：構造化テキストを文字列結合で作らない、置換でいじらない - Uzabase for Engineers


    こんにちは、ソーシャル経済メディア﹁NewsPicks﹂のむとうです。 先日から﹃Ghost of Tsushima﹄の開発者が書いた﹃ルールズ・オブ・プログラミング﹄という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 ︵SQL インジェクション編︶の内容とある面では同じ話です。
    プログラミングの原則：構造化テキストを文字列結合で作らない、置換でいじらない - Uzabase for Engineers

  • 社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog


    はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
    社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
    arajin
    arajin 2023/10/18
    “まず小さな意思決定をイベント情報としてドキュメント化し、次にそれらの積み重ねを参照することでリソース情報やより抽象的なイベント情報をドキュメント化する”　課内のwikiつくって、似たようなことやってた
    リンク

  • 5年いた富士通を退職した理由


    5年エンジニアとして務めた富士通を一昨年退職した。そろそろほとぼりも冷めたと思うので、書く。 真面目に書いている増田もいるが、僕は自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる。 開発環境がだめまずこれがトップにくる。 本当にだめだった。多分開発させる気なんてなかったんだろうなあ。ニートでももうちょっといい環境を使っていると思う。 メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。 Macなんか認めん！iOSアプリも富士通PCで作れ！︵本当にあった話︶。 机上環境もだめいろんな環境にいたが、その中でもひどかったのは、もともと生産ラインがあった場所に机を置いて事務所として使っていた場所だ。机もせまかったし、気温も暑いか寒いかのどちらかだった。 そこに協力会社を大量に押し込んで、ソフトウェアの生産ラインを作
    5年いた富士通を退職した理由

  • ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴


    www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、﹁コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ﹂というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている︵ご存じの方は彼にご一報を︶。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80％、いやもしかしたら90％をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく
    ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴

  • 手を動かさないマネージャーを試している - id:onk のはてなブログ


    2月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください！— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
    手を動かさないマネージャーを試している - id:onk のはてなブログ

  • elmo型学習の特徴と短い持ち時間で強くない理由 in elo河童理論 - コンピュータ将棋 Qhapaq

    # elmo-qhapaq将棋理論。略してエロ河童理論ですね elmoの学習部が公開になりました。秘密にしておけば次の大会でも勝てる見込みが高いにも拘わらず、公開してくれた開発者の方には感謝してもしきれない気持ちでいっぱいです。 さて、elmoの学習部の特徴はやね師匠のブログ（elmoがもたらしたオーパーツについて | やねうら王 公式サイト）などでも言及されている通り、浅い局面での評価値を、従来の深い局面での評価値ではなく、深い読みの評価値と、その局面から指させた時の勝敗を使って補正することにあります。 開発者の多く（？）が数式を見て最初に思ったのは「勝率の補正項大きいなあ」であったことでしょう。また、elmoの評価関数は浮かむ瀬に比べレート+200程度と強烈に強いにも拘わらず、持ち時間0.1秒の将棋などではあまり強くならないという特徴があります。 こうした不思議はなぜ起こるのか、elm

  • Rで円を描く方法あれこれ


    グラフに円を描くような関数が用意されていてもよさそうなものですが、どうもないみたいですので、自力で描く必要がありそうです。 簡単のため、半径1の円の例です。 まず思いつくのは、 x^2 + y^2 = 1 をyについて解いて、 y = ±√(1 - x^2) という関数の形にして、curve関数を使って描く方法でしょうか↓ curve( sqrt(1-x^2), xlim=c(-1,1), ylim=c(-1,1), asp=1) curve(-sqrt(1-x^2), xlim=c(-1,1), ylim=c(-1,1), add=T)
    Rで円を描く方法あれこれ

  • 『なっとく！関数型プログラミング』は読者の理解度の進捗を先読みして作り込まれた”プログラミング入門”の良書 - Magnolia Tech


    なっとく！関数型プログラミング 作者:Michał Płachta翔泳社Amazon 良い、買おう、読もう、︵コードを︶書こう、以上！ めっちゃ良いですよ、この本 中盤のプリミティブじゃやりづらい→直積→直和→二つ合わせてADT→値を取り出すためのパターンマッチの解説の流れの疾走感がいいですね— magnoliak🍧 (@magnolia_k_) 2023年8月6日 ﹃なっとく！関数型プログラミング﹄は、2022年に出版された﹃Grokking Functional Programming﹄の邦訳版で、主にScalaを題材として関数型プログラミングを学んでいくための入門書("Grokking"は、完全に理解する、という意味)。あくまで関数型プログラミングの考え方、コードの書き方、良い設計の指針の解説が主眼に置かれているので、Scalaの言語機能の入門書ではない。Scalaの言語仕様を網羅
    『なっとく！関数型プログラミング』は読者の理解度の進捗を先読みして作り込まれた”プログラミング入門”の良書 - Magnolia Tech

  • プログラマーのための行動経済学 (コードをきれいにするのはいつ？) - techtekt


    はじめに サマリー 先延ばし傾向︵現在バイアス︶ 対策‥コミットメント 課題点 1. 金銭的な制裁を行うのが難しい 2. 現在バイアスを自認していない人はコミットメント・デバイスを使わない 3. コミットメント・デバイス設計の問題 組織内の先延ばしを防ぐには まとめ ※三浦は退職していますが、本人の同意を得て、掲載を継続しています。 はじめに こんにちは。パーソルキャリア株式会社でデータアナリストとして働いている三浦です。8か月前ぐらいに、将来の自分のためにもコードはきれいにした方が良いという内容の記事を書きました。 プログラマーのための行動経済学 (自信過剰とリーダブルコード) コードをきれいにする、新しい技術を学ぶ。 将来のために必要だと分かっていても、面倒でつい先延ばしにしてしまいませんか。 この記事も、半年前には書き終わっている予定でした。 今回は、こういった先延ばしをテーマと
    プログラマーのための行動経済学 (コードをきれいにするのはいつ？) - techtekt
    arajin
    arajin 2023/08/04
    “コミットメント・デバイス”
    リンク

  • ウェーブレット木の世界 - Preferred Networks Research & Development

    岡野原です。ウェーブレット木の解説を統数研チャンネルにて行いました。 統数研チャンネル（プレミアム会員ならしばらくタイムシフト視聴可能）。 ウェーブレット木は万能のデータ構造であり、系列データ、全文検索、グラフ、二次元情報、フィンガープリントなど様々なデータに対して多くの操作をサポートします。 本解説では大規模データの背景、ウェーブレット木の作り方、使い方、様々なデータへの適用、最前線（ウェーブレット行列）などを紹介しています。本解説は拙著「高速文字列解析の世界」とあわせてみていただけたらと思います。

    ウェーブレット木の世界 - Preferred Networks Research & Development
  • 1 2 3 4 5 6 7 8 9 10 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.