サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめに製造業でローカルLLMの導入が話題になっています。 「ChatGPTは便利だけど、機密情報を扱えない」 「社内にサーバーを置けば、安全に生成AIが使えるらしい」 「最近のローカルLLMは性能が高いと聞いた」 こういった期待を持って、ITベンダーに相談する。担当者は丁寧にヒアリングしてくれます。立派な提案書も届きます。そして見積もり。金額は300万円から1,500万円、期間は3ヶ月から半年。 数ヶ月経って契約が成立し、プロジェクトが進みます。要件定義、環境構築。そして2〜3ヶ月後、ようやく検証環境が完成します。 検討開始から半年が経過。ようやく現場の担当者が触ってみる。 「あれ、このUI、使いにくいな...」 「既存の業務フローに合わない」 「思ったより効果が出ない」 でも、既に300万円を払った後です。 問題は、ITベンダーのPoCが悪いわけではありません。問題は、「触る」のが遅す
2025-10-11: スリープからの復帰問題の解決策に関する情報を追記 2025-10-10: キーマップの変更、AWS CLIのインストール、外付けSSDのマウントについて追記 2025-10-08: 音声文字入力ソフト、ナチュラルスクロール、タブ化のショートカットの Omarchy本体でのサポート予定について追記 2025-10-07: システム全体の日本語化の補足、Public Keyの記事の追加、音声の再生が途切れる件の解消法の追記、ダッシュボードのサンプルが一部動作しなかったため cal → btopに変更、ウインドウのタブ化のバイディング設定の一部が間違っていたので修正、音声編集ソフトについて追記 2025-10-06: 初版 はじめに 私はMac がまだ “Macintosh” と呼ばれていたころからずっとMac を使ってきました。ですがこのたび、思い切って Omar
世間ではよく、「プロダクトにオーナーシップを持て」というようなことを言われる。かんたんにいうと「このプロダクトは自分のものだ」と思って仕事しろ、という話だ。よく言われるということは、逆にいうと「そうなっていないことが多い」ということだとも思う。つまり、「ほんとうはオーナーシップを持っていてほしいんだけど、そうじゃないから、"持て"と言われる」ということだ。あいさつがあたりまえになされている場所では「あいさつをしましょう」と言われない、というような話。 では、なぜオーナーシップを持つことが難しいのだろう？ ぼくは、いままでいろんな現場を見てきて、いくつかのアンチパターンがあるな、と思っている。 アンチパターンの解説から入るまえにまず、前提の話から。そもそも、ソフトウェアエンジニア自体が「オーナーシップなんか持ちたくないよ」と思っている場合、それはどうやってもオーナーシップを持たせることは不可
私はこれから数週間、このサイトの管理を離れる予定だ（半分は休暇、半分は仕事）。日々のルーティンから離れることを考えているうちに、LLMやAIの現状について、散漫な考えを共有したいと思った。AIがソフトウェア開発に与える影響についての初期の調査をいくつか目にした。生産性は向上しているのか？コードの品質は上がったのか？下がったのか？などである。こうした調査の大きな問題は、LLMの使い方を考慮していない点だ。私が知る限り、LLMの使い方の大半は（主にco-pilotを使用した）「高機能なオートコンプリート」である。だが、LLMを使いこなしている私の知人たちは、オートコンプリートはあまり役立たないと考えており、LLMにソースコードのファイルの読み込みと編集を許可し、タスクを実行させるアプローチを好んでいる。LLMの使い方を無視した調査は、誤った方向へ人々を導くデータを生み出すのではないかと懸念し
最近はコードを書くときには、なんでもClaude Codeに書いてもらってるのだけど、何が便利かというと、MTGの開始時にお願いして、MTG中ほったらかしにして、終わった頃に見たら進捗が出ている。多少変でも、そこから手直ししたら使えるものになるので、大満足。 人によって印象がちがうけど、期待通りに書いてもらえない、と不満を言っている人はフルタイムで開発している人で、そういった人は自分で1の進捗を出せていたものが0.5になっていて不満で、一方、満足している人は、もともと自分でコードを書く時間がなくて何も作れていなかったのが、ちょっとは作れるようになる、という、0が0.5になっているので満足している、ということかもしれない。 また、フルタイムで開発する人は要件が曖昧なビジネスロジックの実装をしていて、前提知識が多いので、ちょっとしたプロンプトくらいではうまく作れない。 コードを書くのがメインじ
ある開発者が自身のLLMを用いたコード生成ワークフローを次のように語っている。 tl;dr まずブレインストーミングで仕様を固め、次に “計画そのものを計画” し、それから LLM のコード生成で実装。小さなループを回していき、あとは魔法 ✩₊˚.⋆☾⋆⁺₊✧ Step 1: アイデアを絞り込む 対話型LLMに、アイデアを磨き上げさせる。 Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea... Remember, only one question at a time. （訳：このアイデアを徹底的かつ段階的な仕様に落とし込むために、一度に一つずつ質問してください... 覚えておいて、質問は一度に一つだけです。） これでかなりsolidなspec.mdが手に入
ソフトウェア開発で目撃したものを説明するために、私は造語を作る習慣があります。 便利な用語が少ないので、ソフトウェア開発の分野の書き手はこのようなことをよくやります。 造語を作るときの問題は、意味の希薄化により本来の意味が失われ、別の意味が追加されてしまうことです。 意味の希薄化が発生するのは、個人やグループが作った用語があり、適切に定義されていたにもかかわらず、歪められた定義がコミュニティに広まったときです。 これにより、用語の定義が完全に失われる危険性があります。 また、それに伴い、用語の利便性も失われてしまうでしょう。 私が本記事を書こうと思ったのは、「アジャイル」と「Web 2.0」に意味の希薄化が発生しているからです。 いずれも数年前に作られた用語であり、しっかりとした定義があります（アジャイルにはアジャイルマニフェストがあり、署名者たちが執筆した書籍や記事も多数あります。Web
第1章Stripe決済の全体像 概要Stripeを使うことで、従来は複雑だった決済システムの実装ハードルが大幅に下がります。全体像をつかむための最低限必要な知識として、Web決済に的を絞って、Stripe決済の基本構造、単発決済とサブスクリプション決済の違い、テスト環境の使い方を説明します。 Web決済システムの全体像Stripe決済システムは以下のようなコンポーネントで構成されています： ※最小限の基本的な決済に必要なもの。実際にはもっと複雑で、膨大な構造です 基本概念 商品（Product）: 販売する商品やサービスの基本情報 価格（Price）: 商品の価格設定（金額、通貨、請求間隔） 顧客（Customer）: 購入者の情報を管理 支払いインテント（Payment Intent）: 単発決済の処理を管理 サブスクリプション（Subscription）: 継続課金の管理 アプリ
昔書いて結構ご好評を得た「process-book」なんだけど、サンプルコードが古かったりbuild環境が古かったりしたので、令和最新版にリバイスした。 https://github.com/Shinpeim/process-book リバイスした内容としては……docker containerでの実行環境を同梱したGitHub Actionsで pages のbuildとreleases（pdf版）をビルド,publishするようにした サンプルコードをRubyに統一 ClaudeCodeと一緒に、説明が薄いところなどを加筆修正した 基本的な内容は変わっていないです。正直ずっと「価値のある文章のはずなんだけど、いろいろと古くなってて手をいれないとな……」「けどめんどくさいな……」が戦っていたんだけど、Claude Codeとの生活を始めたことで「まあパッとやっちゃうか」になることがで
Rubyの生みの親・まつもとゆきひろ氏が若手エンジニアに贈る、キャリア構築のヒント。35年にわたるソフトウェア開発者としての経験から、「つよつよエンジニア」と呼ばれる存在になるための本質的な考え方を語ります。技術だけでなく、成功への道筋や自分らしさの活かし方など、プログラマーとして生き抜くための実践的な戦略を、ユーモアを交えながらわかりやすく解説しました。 「日本人で一番有名なプログラマー」Rubyの父が語る35年の経験まつもとゆきひろ氏：こんにちは。まつもとゆきひろと申します。今日は「学生エンジニアの生存戦略」というテーマで話すように依頼されています。私は、まつもとゆきひろと言います。Rubyを作った人として知られています。それで、英語圏ではMatzというふうに言われています。 そのせいもあって、みなさん「Matzさん」と呼んでくださることも多いんですけども、Rubyを作った人ですね。お
![「つよつよエンジニアになれない」と悩むすべての人へ Rubyの父が教える“本当の成功の道”とは [1/2] | ログミーBusiness](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f8b21ed0d2374104f047dc09435b1971cd30190ab%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fimages.logmi.jp%252Fmedia%252Farticle%252F331833%252Fimages%252Fmain_image_163d876ca11c0a8ee3ffc8861dc873b70cd3907a.jpg&f=jpg&w=240)
Ubuntu Weekly Recipe 第864回レコード登録なしに名前解決を行える、ワイルドカードDNS「nip.io」をセルフホストする ワイルドカードDNSの必要性 意味を持った名前でサーバーにアクセスできる名前解決は、インターネットの根幹を支える重要な技術です。特に最近のWebアプリには、名前解決ができることを前提としているものも多く、ドメインのないLAN内にテスト環境を立てるのが面倒、といった経験のある方も多いのではないでしょうか。KubernetesのIngressなどで、よくこの問題に当たりがちです。 LAN内でお手軽に名前解決を実現したいのであれば、最初の候補に挙がるのがAvahiでしょう。Avahiを使えば、DNSを用意せずとも、ホスト名からIPアドレスを引くことができます。サーバーのホスト名が「www」であれば、「www.local」でそのサーバーにアクセスでき
「Cursor」「Github Copilot」「Windsurf」「Cline」の料金プランをまとめました。 1. Cursor・https://www.cursor.com/ja/pricing 1-1. Hobby ($0)・Proの2週間トライアル ・2000回の補完 ・50回の低速プレミアムリクエスト 1-2. Pro ($20/月)・無制限の補完 ・月に500回の高速プレミアムリクエスト ・無制限の低速プレミアムリクエスト ※ プレミアムリクエストは、チャットで高性能なAIモデルを使用する時に消費されます。 2.Github Copilot・https://docs.github.com/ja/copilot/about-github-copilot/plans-for-github-copilot 2-1. Copilot Free ($0)・月に2,000 回の補完 ・月
最近、生成AIサービスを契約したり、churnしたりといったことを繰り返している。その結果、自分自身が今どのサービスを、どのような目的で使っているのかが、非常に曖昧になりつつあると感じている。 そこで、一旦立ち止まり、自分のための整理も兼ねて「AIサービスデッキ」を作成してみることにした。今後、各AIサービスをどのように活用し、どれをやめて、どれに移行していくべきか。その方向性を明確にするために、現状の状況をここでまとめておこうと思う。ChatGPT Pro 現状、間違いなくもっとも頻繁に使っているのはChatGPT。Proを解約しようかと思った矢先にo3の発表があり、そのままズルズルと課金を継続している。数週間後にはo3 pro modeのリリース予定、とアナウンスされていたのだが、現時点ではまったく続報がないため、若干信頼性に揺らぎが生じている。 ただ、実際にはo3をかなり気に入って
テストコードを実装する際に単体テストで書くか、統合テストで書くか迷う場面はないでしょうか。本エントリでは、私なりのテスト戦略についての考えをまとめました。 概要 対象アプリケーション本エントリにおける単体テストと統合テスト 単体テスト（ユニットテスト） 統合テスト（結合テスト、API テスト、フィーチャテスト） 単体テストと統合テストの特徴 テスト方針 テスト戦略 単体テストのみ 統合テストのみ 単体テストと統合テストを組み合わせる コンポーネント別のテストガイドライン 統合テストによるテスト テストピラミッドとテストダイヤモンド 統合テストの懸念 統合テストが無い 共有データセットが辛い 実行時間が遅くなりそう まとめ 参照 概要 単体テストと統合テストの特徴 テスト戦略 統合テストの懸念への対応NotebookLM による音声概要を作成しました。よくまとまっているのでこちらもどうぞ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
