Slack経由でRAGにコードレビューを依頼するBotを作成 〜 AWS SAM編 - Qiita
はじめに 前回の記事では、リーダブルコードの原則に従ったコードレビューを自動化できないものか・・と考えた結果、『RAGにリーダブルコードの原則を取り込ませてコードレビューをしてもらおう！！』という検証をしてみました。 検証環境の構築は AWSマネジメントコンソール を使用していましたが、今回は AWS SAM を使用して、より簡単に環境構築する方法の解説を行います。 使用するリポジトリは以下になります。 事前準備 リージョン切り替え 全ての手順は「東京リージョン」で実施することを前提としているため、AWSのマネジメントコンソールからリージョンを「東京」に変更してから手順を進めてください。 Cloud9 ローカルマシンの環境を汚さないために、Cloud9 を使用して環境構築を行います。Cloud9 には、今回の作業に必要な以下のツールが事前にインストールされているため、環境構築がスムーズに行
固有名詞をつけるとき - 詩と創作・思索のひろば
ソフトウェアエンジニアリングにおいて大切なのは、人間のことをのぞけば名付けだと思っている。言葉がなければ世界は混沌としたままだけど、そこに名前をもたらすことがものごとを切り分け、ひとつの秩序をもった視点をつくる。この秩序は唯一絶対のものではなくて、なんらかの意志によって導かれたものである。ソフトウェアはあくまでも現実の抽象だから、問題をどういう視点で見るか、という軸があるわけだ。そういう意味では人間のことではある。 適切につけられた名前は、そのことによって他のものとの自然な境界を与えられていて、その他の名付けと一貫性を持っている。そういう名前は既存の名付けの体系になじむので、同じ言葉を使う人々のあいだに受けいられれて、共通のコンテキストに追加される。そして次第に暗黙のものになっていく。 たとえばユーザのフォローがあるSNSのようなウェブサービスをつくるときに、QueueとかBrokerみた
Pactで小さく始めるコンシューマ駆動契約テスト｜sys1yagi
Ubie(ユビー)株式会社でソフトウェアエンジニアをしている八木(@sys1yagi)です。現在Ubieはソフトウェアエンジニアが25名おり、採用活動の進捗としてはまもなく30名を超えることが見えてきています。 Ubieには大きく2種類のプロダクトがあります。病院向け(toB)の「AI問診ユビー」というプロダクトと、一般ユーザ向け(toC)の「AI受診相談ユビー」というプロダクトです。病院向けの「AI問診ユビー」は、病院、クリニック、グローバル(アジア)に分かれており、全体で4つのプロダクトを開発しています。これらのプロダクトは15個のサービスを組み合わせて動作しています。 プロダクトとサービスの関係図 プロダクト間連携で起こる課題現在はサービス群がざっくりプロダクトのバーティカルで分かれていて、一部で共通のサービスがあったり、プロダクト間で連携しあう部分が出てきたといった状態です。人数や
レガシーコードのはなしをしてみた #DevKan - 日々常々
レガシーコードと対峙する方法を考える - DevLOVE関西 | Doorkeeper 2014/03/25にあったDevLOVE関西「レガシーコードと対峙する方法を考える」で、「"レガシーコード"再考」とか釣りっぽいタイトルで話してきました。DevLOVE関西は発表とダイアログって形式が多いので、その時のネタの一つにでもしてくれればいいかなーくらいを力点にしてます。だもんで、「レガシーコードってなんやねん」とか聞くだけ聞いて、結論付けたりとかはせずに終わったり。そんな毒にも薬にもならない話でした。 スライド "レガシーコード"再考 問い: 発表者の気持ちを答えよ（制限時間10分） 「レガシーコードの話をする」のは簡単なことだと思う。世の中にはレガシーコードが溢れてる事にはおおむね同意されるだろうし、見てきたものをそれなりに話すだけでも「あるある」とか「うへー」みたいな、参加者の多くである
結局動くコードが一番楽しい - Konifar's WIP
個人でアプリ作ってるんですが、なんだか最近めんどくさくなってきました。 いつも個人開発って早く続き作りたくてたまらない感じなんですが、最近は 「…よし、やるか！」という感じで気合い入れないと作業に入れないようになってきちゃってます。楽しくなくはないんですが、良くない傾向です。 ちょっとやり方というか、自分のマインドを切り替えないと辛そうなので整理してみます。 個人開発のフリーダムさ 仕事で開発してる方は経験あると思うんですが、業務での開発は色んなしがらみがあることが多いです。もちろん環境にもよりますが、100%自由に何でも開発できるというのは稀な気がします。 それに比べて、個人開発はもう完全に自由です。何を作ってもいいし、どれだけ時間をかけてもいいわけです。好きな言語で開発するのも、話題になり始めたばかりのクールなライブラリを使ってみるのも全部自分で決めていいわけです。 何かを作る上で、こ
Ruby フルタイムコミッタの仕事報告 2023年Q1 - ANDPAD Tech Blog
こんにちは、hsbt です。前回のエントリで触れたウィッチャー3は一段落しましたが、気の迷いから原神を初めてしまい無限に時間が溶けています。RubyKaigi 2023 が近づいて来ているのにこれはまずい。 今日は前回の Ruby フルタイムコミッタになってからやったこと、の定期報告シリーズとして、2023年のQ1にフルタイムコミッタとして行った仕事の一部をご紹介します。 Ruby のリリースについてのご紹介 まず、今回の仕事内容に入る前に2023年2月18日に開催された福岡Rubyist会議03で発表した、Ruby のリリースにまつわる課題をまとめたスライドをご紹介します。 上記スライドでは、毎年、または不定期に行っている安定バージョンのリリース時に発生していた、発生している課題について原因と対策、対策の結果生まれた新たな課題のループについて解説をしています。今回は発表では深くは触れなか
ChatGPT にプルリクエストのタイトルをレビューしてもらう - TENTIALのテックブログ
はじめまして。DevOpsエンジニアの田島です。 先日発表され大きな話題となったGitHub Copilot Xの中に気になる機能がありました。 曰くPR(プルリクエスト)のdescriptionを書く際に特定のタグを埋め込むことで該当部分がAIによるfiles changedの要約に置き換わるそうです。 素晴らしいですね。 参考: Copilot for Pull Requests - Suggestions for your pull request description 使い方としてはPR作成開始時に自動で展開される.github/PULL_REQUEST_TEMPLATE.mdに予めタグを入れておく方法が考えられるでしょう。 Related issue: #0000 # 概要 copilot.summary # 詳細 copilot:walkthrough copilot:poe
GHCに初めてコントリビュートした／最近のGHC動向 | 雑記帳
事実上の標準デファクトスタンダードなHaskell処理系であるGHCに貢献するというのが去年掲げた目標だったが、それがようやく実現したので報告する。ついでに、最近のGHC開発状況についても簡単にまとめてみる。 「貢献」と言っても色々あって、バグ報告とかも立派な貢献なのだが、ここで目標としていたのは「書いたコードをGHC本体に取り込んでもらう」ことである。 一つ目：fromInteger :: Integer -> {Float,Double} 年末に書いた記事 Haskell/GHCでの浮動小数点数の扱い – Qiita にあるように、現行のGHCのfromIntegerは値の大きさによって丸め方法が違っている。それによってどういう問題が引き起こされるかというと、 import Numeric import Data.Word main = do putStrLn $ "literal :
組織と技術の両輪で開発を加速させるkintoneチームの取り組み / JJUG CCC 2022 Fall Cybozu kintone
kintoneは2011年のリリース以降、開発チームが90名になるまで成長し、コードベースも肥大化を続けてきました。しかし、組織もコードベースもモノリシックなまま成長を続けてきたため、メンバーの認知負荷やコミュニケーションコストの増大などによって、開発体制がスケールしない問題を抱えていました。今後、開発を加速かつスケールさせるために、領域専任のチーム体制への移行に挑戦しています。技術面でも、開発を加速するための改善に取り組むプロジェクトを、エンジニアが起案し、チームを発足して進められるようになりました。JUnit 5へのアップデートや、Joda-TimeからJSR-310 Date and Time APIへの移行、さらにフロントエンドのクラス構文への移行など、多岐に渡る改善プロジェクトが進行しています。組織面と技術面の両輪で開発を加速するための取り組みについてお話しします。
2019年度未踏に関する備考録
本記事は@ushitora_anqou(以下、お魚さん)の開催した投稿大会に当たってせっかくだしそこに投げようかという気分で執筆されたものである。ちなみに間に合ってない。WordPress何もわからんので見づらいかも。なんか途中から口調が変わってるんですがまぁ執筆が日をまたいだのであれ。 主な登場人物@nimdanaoto:筆者 @Vtb:同じサークルに所属するみかん。祖父が鯛の養殖をしてるらしい。彼との会話でアイデアが固まった。自作CPUしてたし興味あるんでねと思って声をかけたやつ。 @ushitora_anqou 初見はk/vmだったと思うんだけどCコンパイラが書ける頭おかしい(そういう名前の賞もらってたしほめことばに違いない)のがいるというのを覚えていたので、みかん経由で声をかけた魚。自然言語コンパイラ。 準同型暗号という、暗号文のまま計算ができる暗号がある全ては、2019年２月末に
フロントエンドにおけるアーキテクチャとの向き合い方
FRONTEND CONFERENCE FUKUOKA2019の登壇資料です
枯れた技術ってほんとに枯れてますか？保守できますか？｜erukiti
「枯れた技術」と言われたとき、それが安定していて、保守しやすいものであるという認識が多いように観測されます（観測範囲問題かもしれない）。 この記事でいう技術は「ソフトウェア技術」に特化した内容です。ソフトウェア技術はまだこの世に生まれでてから100年も経過してないような若すぎる産業であり、脆弱性など、ソフトウェア技術に固有の事情があります。 でもそれってほんとですか？事実ですか？正しくそのことを検証しましたか？ あなたが枯れてないと認識している技術よりも保守しやすいと思っているのは、ただの思いこみではないですか？ 昨日軽い気持ちで書いた僕のフロントエンド技術に対するスタンスという記事のようにフロントエンド系のバズる記事を書くとだいたい「保守とか考えてるの？」みたいなコメントがつくことがありますが、では、バックエンド、組み込み、機械学習、インフラを見て、枯れた技術ってほんとに枯れてるの？保守
DRYについてのよくある誤解 - ひがやすを技術ブログ
WEB+DB PRESS vol.49で、「現場で役立つDRYの基礎知識」が特集されています。とても、良い記事だと思うので、ぜひみなさん、読んでください。 ただ、ちょっと補足をしておきます。 記事の中で、DRYは、「達人プログラマー」の中で、とりあげられ、Railsによって広まったとされています。確かに、Rubyの世界ではそうかもしれないけど、DRY原則というのは、ERモデリング(DOA)の世界では、ずっと「One Fact In One Place」という言葉で知られてきました。 ERモデリングにおける正規化は、「One Fact In One Place」を具体的に実現するための手段です。 DRYという言葉そのものを広めたのは、間違いなくRailsです。しかし、DRYの考え方そのものは、昔からあったし、「One Fact In One Place」という言葉も、昔から有名だったというこ
Dagger で Node.js アプリをビルドする - なんとなくな Developer のメモ
CI/CD のパイプラインを定義するためのツール Dagger を使って Node.js アプリのビルドを試してみました。 Dagger v0.2.7 今回使用したソースは こちら sample1. echo の実施 まずは以下の処理を Dagger で実施してみます。 (1) ローカルの input.txt ファイルの内容を取得 (2) alpine イメージでコンテナを実行し、(1) に _echo を付けた文字列を echo して /tmp/output.txt へ出力 (3) コンテナの /tmp/output.txt の内容を取得し、ローカルの output.txt ファイルへ出力 Dagger プロジェクト作成 下記コマンドを実行して Dagger の実行に必要なファイルを作成しておきます。 $ dagger project init $ dagger project upda
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
Pants で決める python monorepo - ABEJA Tech Blog
ABEJA で Research Engineer をやっている中川です．普段は論文読んだり，機械学習モデルを実装したり，インフラを構築したりしています．今回のブログでは3,4ヶ月の間遊び9割仕事1割で取り組んできた Python で実装された機械学習マイクロサービスたちの monorepo 化について紹介します． モチベーション 小売業向けに店舗解析ソリューションを提供している ABEJA Insight for Retail では以下のような理由から機械学習システムをマイクロサービスの polyrepo (multi-repo) で運用してきました． 様々なフレームワークで書かれた最新の研究成果を取り入れやすい． 負荷特性の全く異なる機械学習モデルをスケールさせやすい． モデルごとに容易にデプロイできる． 障害耐性や保守性を高め日々の運用負荷を下げる． 手前味噌ですが，マイクロサービス
ESLintチームから200ドルもらった話 - Qiita
ESLint チームから $200 いただきました！とても嬉しくありがたいです！ プログラマー人生の中でも、あまり無い経験だと思ったので駄文ですがこの経験を残そうと思います。 一応書いておくと私は ESLint の中の人ではありません。 まず簡単な時系列（日本時間） 3/26朝、ESLint TSCミーティングでコントリビューターの誰に今月分の寄付をするのが良いか話し合われる。 ミーティングメモのPR: https://github.com/eslint/tsc-meetings/pull/246 3/26朝、ESLint チームのリーダーである Nicholas さんから、あなたに $200 あげます（かなり意訳）な旨のメールが届く。 3/26、メールに案内の通りに Open Collective で申請。3/27、申請が承認される。 3/30 $200 もらた！ ESLint チームの
GSoC 2021 に参加して Scala3 の開発環境を改善させてもらった - たにしきんぐダム
2021/06 から参加していた Google Summer of Code 無事修了しました。 GSoC では Add synthetics and symbol information for semanticdb in Scala 3 という題目で Scala3 の IDE や Linter のための基盤となる機能の開発をしていました。 今回の成果により Scala3 でも Metals (Scala の Language Server 実装) で go-to-implementation, show-inferred-types, show-implicit-arguments (& context-params) などなどの機能が使えるようになる予定です。 https://summerofcode.withgoogle.com/projects/#5527632738779136
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モックの泥沼から脱却するために、あえてDBにつないでテストしている話
現代におけるプロダクト開発とPHPを選定するワケ @ Tokyo #phpcon2017
