![2PC配信のケーブル/機材地獄、Wave XLR Pro 1台でこんなにあっさり解決した [Sponsored]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7d2022426e9203329d980aa3f1fd5ac78f84b94e/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fpc.watch.impress.co.jp%2Fimg%2Fpcw%2Flist%2F2117%2F322%2F01.jpg)
Dev Container上からホスト(Windows)で起動しているアプリケーションにアクセスしたい場合に、ホスト側の接続先を指定する必要があります。 1. Docker Desktopを使っている場合 1-1. ✅host.docker.internalを使う Docker Desktopを使っているならば、ホストにはhost.docker.internalでアクセスできます。 Connect a container to a service on the host - How-tos | Docker Docs 2. Docker Desktopを使っていない場合 Docker Desktopを使っていない場合、例えばWSL2上にDocker CEをインストールして利用しているような場合には、host.docker.internalが使えないので他の方法を取る必要があります。 試して
皆さんこんにちは。この記事では、筆者が最近開発した新しいReactフレームワークであるFUNSTACK Staticについて紹介します。 ドキュメント FUNSTACK Staticの概要 FUNSTACK Staticは、React用のサーバーを立てる必要がなく、静的なファイルサーバーにデプロイできる古き良きSPAを作ることに特化したフレームワークです。 それでいて、React Server Components (RSC) による最適化をしっかり効かせることができるのが特徴です。 以前の記事で説明したように、RSCはサーバーというくらいだからサーバーをデプロイしないといけないと思われがちですが、実はそうではありません。RSCの恩恵を受けつつも、サーバーを立てずに静的ホスティングで動かせる方法があります。 Next.jsなど既存のフレームワークもそのようなモードをサポートしています。しか
【最新バージョンはこちらです】 Claude Codeの開発者である Boris Cherny氏 (@bcherny) が公開した「2026年の開発セットアップ」が、Claude Codeを使う全人類が読むべき内容でした 彼が実践しているのは、単なるツールの使いこなしではありません。 人間自身のCPUをマルチスレッド化するという、エンジニアリングの極致です。 そこで、この記事では彼が明かした驚異のワークフローを解剖し、我々が今すぐ取り入れるべき次世代の開発思想を深掘りします。 1. ターミナルとWebで「多重影分身」 まず度肝を抜かれるのが、同時に稼働させているClaudeの数です。 「AIの回答待ちにスマホを見る」。そんな無駄な時間は、彼の辞書にはありません。 彼は、常時10〜15体ものClaudeインスタンスを並列で従えています。 ここまでくると「一人の開発者」ではありません。AIエー
うぐいすソリューションズ Advent Calendar 2025の 24 日目担当の zen です。ラストバッター頑張ります。 エンジニアのコミュニケーションで気をつけているのは「正しさ」より「前に進むか」 エンジニアとして働いていると、「何が正しいか」は割とすぐ分かるのに、それをどう伝えるかで悩む場面が多いなと感じます。 僕自身、コミュニケーションが得意だと思ったことはあまりありません。それでも振り返ってみると、(自分を変に攻撃してくる人がいない場合に限りますが)プロジェクトが大きく揉めたり、人間関係が壊れたりすることは少なかった気がします。 なぜだろう、と考えてみた結果、どうやら僕はずっと 「正しいことを言う」より 「チームが前に進むかどうか」 を優先してきたように思えます。 この記事では、そんな僕が普段あまり意識せずにやっている、エンジニアとしてのコミュニケーションの考え方をまとめ
はじめに アドベントカレンダーの時期、ブログなどで、セッションの通し方、みたいなノウハウが語られることが多いようです。カンファレンスの実行委員としてオープンプロポーザル形式で公募するようになって長いので、私なりにこうあってほしいなーということを書いてみることにしました。 「よいセッションの作り方」「よいプロポーザルの書き方」「そのための日々の過ごし方」という流れでブログが書かれるといいなーと思うのですが、実際は「ウケるプレゼン作成術」「通るプロポーザルの書き方」こそが利用者にウケる、というコンテンツが増えたりはしそうです。 これはOutput, Outcome, Impact の話につながるのですが、登壇することを通じて得たい成果(Outcome)は話を聞いてもらって、参加者の皆さんに活かしてもらうこと、それが話者の評価にもつながるというところかなと思います。そうして参加者の皆様が成功すれ
「Slackで何を言いたいのかわからない」「ドキュメントを書くのに異常に時間がかかる」 こういった人は組織に一人はいないだろうか。 マネージャーとして「言語化能力を鍛えてほしい」と思うことは多いとは思います。また、LLMを利用して業務を行う際には言語化能力が非常に重要となると考えております。 ですが、正直なところ、できていない人に対して、トレーニングでなんとかなるのか疑問に感じることもあるのではないでしょうか。 僕は23歳の頃、会社の先輩に「お前、何言ってるかわからないから話すのやめるわ」と言われたことがあります。かなりショックだったのですが、それ以来、「どう伝えればわかってもらえるか」を強く意識するようになりました。 その結果、今では言語化能力が高いと言われることもあります。（このようなnoteを書いていると言語化してもらうの助かるとも言われます。） このような経験から言語化能力は天性の
Claude Codeを使ってリポジトリ内を探索してWikiを構築してもらったところ、高精度で実用性の高いものができました。再現手順を共有します。 実例 このようなWikiが完成しました。 DeepWikiが出力したものと比較しても遜色ない品質であると思います。 Wikiのセットアップ GitHubリポジトリの設定画面からWikiを有効にし、空のHomeページを作成してください。 詳細な説明は省きます。 Git submoduleとしてクローン GitHub WikiはGitリポジトリとして扱えるため、以下のコマンドでsubmoduleとしてcloneします。 クローン先はどこでもいいですが、今回はリポジトリ直下のwikiディレクトリにします。 手順書(wiki-manual.md)を作成 Wikiを作る際のルールをまとめた手順書を用意します。自分の好みに合わせた手順を用意すればいいですが
sizu.me はじめに 先日、「技術力に優劣はない（技育などに参加している学生に向けて）」という記事を読みました。技育に参加する学生たちへの励ましのメッセージで、技術との向き合い方の多様性を認め、コミュニケーション力の重要性を説き、相互リスペクトの大切さを訴える、とても温かい内容でした。 この記事は、あの記事の対象読者ではない私が、横から口を出すような形になってしまうことを承知で書いています。 元の記事の主張——技術の感受性には段階があること、ジュニアにはコミュニケーションが大事なこと、べき論に揺さぶられないこと、どの段階にいてもキャリアは作れること——これらは本質的に正しいと思います。 ただ、私はこう思います。それでもなお、技術力という軸においては、やはり優劣が存在し、それが中長期的なキャリアに大きな影響を与えます。 このブログが良ければ読者になったり、nwiizoのXやGithubを
グローバル環境が引き起こす依存関係の「地獄」から脱却する Pythonを使った開発を始めるとき、最初に直面するのが環境構築の壁です。「とりあえず動けばいいや」と安易にPC全体（グローバル環境）にパッケージをインストールし続けた結果、以下のような深刻なトラブルに遭遇した経験はありませんか？ プロジェクトAではライブラリXのバージョン1.0が必要だが、プロジェクトBではバージョン2.0でないと動かない。 新しいライブラリをインストールしたら、既存の別のプロジェクトが突然エラーを吐くようになった。 「私のPCでは完璧に動くのに、デプロイ環境や同僚のPCではエラーが出る」という再現性の問題に悩まされる。 これらの問題はすべて、開発環境が独立していない「依存関係の衝突」が原因です。プロフェッショナルな開発現場では、このリスクをゼロにするための厳格なルールが存在します。それは、すべてのプロジェクトで「
はじめに バックエンド API のテスト事情 バックエンドのテスト構成（これまでとこれから） テスト構成分類（これまで） テスト構成分類（これから） 「ちょうどいい API テスト」とは API テストに求める価値 実行の容易性 メンテナンスのしやすさ 技術選定のポイント runn の採用理由 Testcontainers の活用 実装例 API サーバー実体 APIテスト runn シナリオ APIテストコード おわりに はじめに バックエンドエンジニアの nome です。花粉症🤧なのでこの時期はリモート仕事の幸せを改めて実感しています。 テックタッチのバックエンドAPIでは、これまでユニットテストと Postman による API 統合テストを中心に自動テストを実施してきましたが、テストカバレッジの不足や実行・メンテナンスコストの課題がありました。 本記事では、これらの課題を解決する
2010年より、SHIFTの社内向けブログにさまざまなメッセージを書いてきました。そのメッセージをより多くの方たちに読んでいただきたいと思い、noteに転載したいと思います。今回は、SHIFTの評価制度に関する根本的な考え方についてのメッセージです。 （SHIFTの社内向けブログ2018年4月4日） ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ SHIFTは新卒の人、中途の人、めちゃくちゃ増えていますし、毎年1.6倍で成長しており、従業員も2,000人を超えるほどになってきました。 僕は兼ねてから、経営というよりも会社は街の運営だと言っていますよね。 みなさんが、技術を磨いたり、社員同士でお互いに経験をシェアしたり、品質保証とは違う視点で交流をはかったり、安心安全に働ける環境を整え、その結果お客さんが喜び、価値を認めてもらい、しっかりとフィーを払ってもらい、その結果自分
今回はVisual Studio CodeにAI Toolkit for Visual Studio Codeをインストールし、Ollamaのフロントエンドとして使用する方法を紹介します。 AIにプログラムを書かせるところまでしなくても 世間ではAI（LLM）にプログラムを書いてもらって云々という話題をよく見かけますが、そこまではしなくても、プログラムに関する悩みごとがパパっと解決したらいいなと思うことはよくあります。たいていは試行錯誤の上で解決するので、LLMに悩みを聞いてもらって解決できたら、ずいぶんと生産性が上がることでしょう。もっといい書き方あるのではないかと訝しんだり、思いつかない不具合があるのではないかと疑心暗鬼になることもあります。そんなときも、LLMに聞いてもらえればそれなりの答えが期待できます。とはいえあまり大事にはしたくないので、ローカルで動作するLLMを使用したいとこ
これはなに こんにちは、LT開発部のもりたです。 今回はもりたが最近はじめたZettelkastenのご紹介をします。これは知識管理の手法で、アウトプットの敷居がめっちゃ下がるやつなんですが、ま〜〜よくわからん単語すぎて困ると思うので、今日はサクッと本編に入りますね。 Zettelkastenとは？ Zettelkasten（ツェッテルカステン）は、学びを小さなメモにして保管する方法論です。やっていることはそれだけで、ただただ学んだことを小さくメモにまとめて貯めていきます。その際に大切な点があり、それは「自分の言葉で書く」ことと、「情報をなるべく小さく保つ」ことです。 Zettelkastenっていろんな説明のされ方があるんですが、この「範囲は小さく、品質は高く」思考を言語化できるというのが最初の大きなメリットです[1]。 今回はZettelkastenなんて１ミリも知らんぜというみなさん
4 万行超の openapi.yaml のツラミ ファイルが大きすぎて編集しづらい OpenAPI が肥大化していくにつれて開発体験の低下を招いていました。 GitHub Copilot や Cursor の Tab 機能で随分楽になりましたが、それでも 4 万行もあるファイルを手作業で入力するのは純粋に辛いです。 AI Agent のコンテキストを大きく圧迫する Cursor 等の AI Agent のコンテキストを大きく圧迫することが直近の開発で大きな課題となりました。 具体的には次のような問題が発生したため、ファイルを分割することが急務となりました。 コンテキストが溢れて Cursor Agent が停止する Longer Context を有効化すると処理できるようになるが、トークンを余分に消費してしまう TypeSpec とは TypeSpec は、API を記述するための Mi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
