現在YugabyteDBを検証しています。YugabyteDBの動作検証のためにDockerも相変わらず使っています。 検証の初期はIntel CPU版のMacを使っていました。なので特に問題なくLinuxのDockerで動くコードをそのままIntel CPU版のMacでも動かせていました。 つい先日、M4のMac miniが安価で出ていたので購入しまして、若干その修正が必要になりました。 手で修正するのは簡単なのですが基本私は面倒くさがりなので、AIを使って対応してみようと思いました。 macOS版のDocker Desktopについて macOS版のDocker Desktopでは、バージョン4.25以降のバージョンではRosetta 2に対応しており、設定を有効化してコンテナを起動するときにオプションを追加指定することで、ARM Mac上でx86_64向けのコンテナを起動できます。 実際起動するときは、interactiveとかdetachとかポートのpublishオプションなどを追加すると思います。 --platform linux/amd64オプションを付与することにより、ARM Mac上でx86_64向けのコンテナを起動できます。 # Rosetta 2を使って、macOSのDocker Desktopでx86_64のコンテナを起動する docker run –platform linux/amd64 <イメージ名> 背景 念のために言っておくと、YugabyteDB自体のコンテナイメージはx86_64のイメージの他、ARM対応のイメージも提供されています。そのため、特別なことをしないでもARM Mac上でYugabyteDBのコンテナーを動かすことはできます。 https://hub.docker.com/r/yugabytedb/yugabyte/tags ただコンテナーの中でsysbenchを動かす必要があり、かつ対抗がYugabyteDBという分散DBなので、本家のsysbenchではなく、分散DBにも対応するコードが入ったsysbenchをインストールする必要がありました。そのsysbenchのパッケージがx86_64でしか提供されていなかったために、このような対応が必要だったというわけです。 https://docs.yugabyte.com/preview/benchmark/sysbench-ysql/ 本題 変更前のマニフェストは次に公開されているものを使います。 https://github.com/ytooyama/yuga-sysbench-example Dockerfile Dockerfileは二つ用意しており、base用とsysbench用です。 YugabyteDBのオフィシャルイメージは、AlmaLinux 8をコアに利用したイメージになっています。 base用はiproute-tcのRPMパッケージをインストールするだけの内容になっています。これならARM64向けのimageを使っても良いかもしれませんが、コンテナ間でア クセスする必要があるので、sysbenchコンテナはx86_64で、そのほかはaarch64でコンテナで動かす前提にします。 ただ、Dockerfileには特別なタグは設定しません。 # ベースイメージとして指定されたYugabyteDBのイメージを使用 FROM docker.io/yugabytedb/yugabyte:2.25.2.0-b359 # 必要なパッケージをインストール RUN dnf install -y iproute-tc && dnf clean all # デフォルトのコマンドを指定（必要に応じて変更） CMD ["/bin/bash"] 前述のように、Yugabyteのパッチが適用されたsysbenchをインストールするようにDockerfileに記述します。 次のようなDockerfileを作成しました。 # ベースイメージとして指定されたYugabyteDBのイメージを使用 FROM docker.io/yugabytedb/yugabyte:2.25.2.0-b359 # 必要なパッケージをインストール RUN curl -LO https://github.

先月の話にはなりますが、普段作業用に使っているMacをIntel CPUモデルのMac mini 2018からM4 Macminiに乗り換えました。Amazonのセールで8万円程度で出ており、熟考した結果購入することにしました（その間に8千円ほど値段が前後してしまいましたが）。 使っていたMac mini 2018はメモリーこそ16GBに変更していますが、それ以外はカスタマイズせずに買ったものです。CPUは第8世代Core i3で4コアですし、ストレージは256GBで、外付けGPUはありません。これでも10万円位した気がします。 とは言え普段使いには特に困ることは無いので、Mac mini 2018はもうしばらく使おうかなと思っていたのですが、来年のmacOS 27がIntel CPU対応のMacの大部分をサポート外にすると聞き、それならもう新しいものを買ってしまおうと思って今回、購入に至ったわけです*1。 同じきっかけで今後Apple Silicon版Macに移行する人も増えると思ったので、今回、こんなブログ記事を書こうと思いました。 今回私が買ったモデルはCPU 10Core, GPU 10Core, メモリーは16GB、ストレージは256GBの標準モデルです。 公式では94800円のモデルですが、私が購入した頃は8万円前半で出ていました。定期的に開催されるセールの時が狙い目です。 https://www.amazon.co.jp/dp/B0DLCCBD1H 「ところでストレージ256GBじゃ足りないのでは？」とよく言われますが、Mac mini 2018のストレージが普段使いで160GBくらい空いていたので大丈夫だろうという判断です。普段からMac上で大きなアプリケーションを動かすことは無くて、sshとかしてほかの環境で動かすので、何とか256GBでもやりくりできています。 もちろんそれには若干工夫が必要で、VirtualBoxを使って仮想マシンを実行する場合は仮想マシン置き場を設定変更し、外付けのSanDiskのSSD 1TBに変更しています。そこまでする必要は無いと思って私は設定していませんが、最近のmacOSにはAppStoreのアプリを外部ストレージに保存するオプションも追加されているので、アプリの管理をAppStoreでおこなっている場合は、有益なオプションかもしれません。また、なんらかの信頼性のあるクラウドストレージの併用は必要だと思います。私はApple Oneを契約しているので、そちらを主に使っています。 support.apple.com 大きさを比較してみます。右上はPowerPC G4 Mac mini、左下がIntel Mac mini、右下がM4 Mac miniです。 M1からM2のMacminiもIntel Mac miniと同じ大きさでしたから、M4モデルのその大きさにびっくりします。 筐体がコンパクトになった分、若干厚みが増しました。これまでMac miniはスタンドを使って縦置きにして使っていましたが、厚みが変わったことで、これまで使っていたスタンドが使えなくなりました。新しいのを探さないと。 データ移行 最近はずっと新しいMacへの移行作業をするときは標準の移行ツールは使わずに、ユーザーの.sshと一部のファイルだけをコピーして移行完了とし、後のアプリケーションは新規インストールしていました。 ただ今回は久しぶりに移行ツールを使ってみようと思い、標準の移行ツールを使ってユーザーデータ丸々を移行しました。移行は問題なく完了してライセンスも問題なく引き継げましたが、amd64版のソフトウェアがそのまま入っているため、その対応が必要でした。 ミーティングアプリ リモートワーク主体になったのもあり、リモートコミュニケーションツールは一通りそろえる必要があります。いまだったらZoomとかSlackとか、Teamsとかでしょうか。 SlackはもともとApple Store版のSlackを使っていたため、特に何もせずに使えました。 TeamsおよびMicrosoft 365 Appについては、移行後に再度ログインが求められました。これはライセンスで管理されているソフトウェアなので仕方がないです。特にエラーが出ることなく使い続けられています。 Zoomは起動したものの、amd64版が動いているのでアップデートが必要（arm64版に移行）と勧められました。賢いですね。そのまま指示に従えばApple Siliconに対応したバージョンに切り替えられます。 だいたいそれで終わりです。 Homebrewでインストールしたソフトウェアの移行 Homebrewでインストールしたソフトウェアは基本的にそのままamd64版のソフトウェアがインストールされた状態です。 brew listコマンドでインストールしたパッケージ一覧を出力してメモしておき、いったんすべて消してHomebrew自身も削除、後は新規インストールの方法に従って設定していくだけです。 移行のついでに手動でインストールしていたアプリケーションをbrew install --caskを使ってインストールしました。 今回の移行をきっかけに、ほぼ手動インストールしたソフトウェアは無くなりました。 セットアップ後にbrew listのメモに従ってインストールし直しするだけです。移行のついでにもう使わないものは取捨選択することにしました。これで移行は完了です。 Homebrew以外でインストールしたソフトウェアの移行 macOSのアプリケーションはユニバーサルバイナリーなので、アーキテクチャーに合わせたほうで動いてくれます。一方、特定の用途のためにインストールしたCLIツールはアーキテクチャーごとにリリースされているため、置き換えが必要でした。ほとんどはHomebrewなどの管理ツールを使っているものの、一部理由があってほかのツールを使っていることがあるので、そこら辺も置き換えが必要です。 基本的に同様に消して入れ直すだけでしょうか。管理ツール自体のarm64移行が必要だったりもします。 SDKMANを使ってインストールしていたJavaはいったん消してSDKMAN自体も入れ直しですね*2。ざっくり作業をまとめるとこんな感じです。

今月も Visual Studio Code の新バージョンがリリースされました。さっそくリリースノートをチェックしていきましょう。 目次 目次 新バージョンのリリース情報 主なリリース内容 VS CodeでGitHubのMCPサーバーを使ってみよう 新バージョンのリリース情報 Visual Studio Code のバージョン 1.102 がリリースされました。 主なリリース内容 変更点 変更内容 Copilot Chat のオープンソース化 GitHub Copilot Chat 拡張機能が MIT ライセンスで公開され、コミュニティによる開発参加が可能に。 言語モデルの構成が可能に chatmode.md のメタデータにモデル識別子を指定し、IntelliSense による補完をサポート。 カスタムインストラクション生成機能 コードベースを分析し、プロジェクトに合った指示を自動生成・カスタマイズ可能に。 インストラクションファイルのオンデマンド読み込み .instructions.md と glob パターンで条件付き適用が可能になり、LLM が必要時に指示を取得。 過去リクエスト編集機能（実験的） 過去のリクエストやモードを編集後、後続リクエストをリセットして再送信可能に。 ターミナル自動承認機能（実験的） 許可・拒否リストで安全なコマンドを自動承認し、危険なコマンドは手動確認を要求。 エージェントのタスク・ターミナル認識 実行中タスクやターミナルを把握し、GetTaskOutput で出力を取得・重複実行を防止。 チャットビューの最大化 セカンダリサイドバーをエディタ全体に展開し、再起動後も状態を自動復元。 MCP サポートの正式リリース VS Code で MCP 全機能が利用可能となり、組織ポリシーによる管理にも対応。 中クリックスクロール対応 中クリックでマウス移動によるスムーズなスクロールが可能に。 その他の詳細なリリース内容については June 2025 (version 1.102) をご覧ください。 VS CodeでGitHubのMCPサーバーを使ってみよう Visual Studio Code（VS Code）で、MCP サーバーに関する情報がまとめられており、まるでマーケットプレイスのように使いたいサーバーを見つけることができます。今回は、もっとも身近な GitHub の MCP サーバー をインストールして使ってみます。

7月になり、西日本は例年よりも早い梅雨明けで本格的な夏モードですね。東日本は梅雨は明けてないものの厳しい暑さが続いています。 さて、今月も月が変わりましたので、恒例の月刊DevOpsニュースをお届けします。 データベース クラウド プログラミング 生成AI その他 データベース AWS、事実上無制限にスケールするPostgreSQL互換の大規模分散DB「Amazon Aurora DSQL」正式版を提供開始 www.publickey1.jp 次期PostgreSQL 18では非同期I/Oの採用により性能が2～3倍向上する見通し www.publickey1.jp クラウド Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと www.publickey1.jp クラウドインフラのシェア、Canalysの調査ではAWSがシェア30％台を維持、Azureは23％と急増。Canalysによる2024年第4四半期の調査結果 www.publickey1.jp Cloudflareが重大なサービス障害の原因を説明。実はWorkers KVがGoogle Cloudに依存しており、Google Cloudの障害が原因だったと www.publickey1.jp プログラミング Kotlin言語によるバックエンド開発強化へ、JetBrainsがSpringと戦略的提携 www.publickey1.jp Visual Studio Code、Web標準の「Baseline」チェックに対応。コード内のHTMLやCSSにカーソルを合わせれば説明表示 www.publickey1.jp 生成AI GitHub、リモートGitHub MCPサーバーをパブリックプレビューで提供開始 gihyo.jp OpenAI、推論モデルo3-proをリリース ——推論スタックの最適化により、API経由のo3の価格は80%値下げに gihyo.jp AIコードエディタCursor 1.0リリース ―BugBotの実装、MCP対応、Background Agentをすべてのユーザが利用可能に gihyo.jp NotebookLM、共有機能を強化し、「公開ノートブック」をNotebookLMユーザー一般と共有可能に gihyo.jp Google、Geminiをコマンドラインから利用できるGemini CLIをオープンソースとして公開 gihyo.jp AIコードエディタCursor 1.0リリース ―BugBotの実装、MCP対応、Background Agentをすべてのユーザが利用可能に gihyo.jp Figma、「Dev Mode MCP Server」ベータ版の提供を開始 ―MCPを使ってエージェント型コーディングプラットフォームとデザインコンテキストを共有 gihyo.jp Gemini 2.5 Proアップグレード版プレビューリリース gihyo.jp セールスフォースがインフォマティカを1兆円超で買収すると発表。データ統合やAIエージェントの強化に www.publickey1.jp AWS、Google、マイクロソフトらがAIエージェント連携のため「Agent2Agentプロジェクト」設立。Linux Foundation傘下で www.publickey1.jp

今回のとことんDevOps勉強会は「GitLabでCI/CDを動かしてみよう」と題し、日本仮想化技術の大内がGitLab初心者やこれからCI/CDに挑戦したい方を対象に入門編として登壇しました。 GitLabは、ソースコード管理に加えてCI/CDパイプラインの構築や自動化が可能な開発プラットフォームです。本セッションでは、GitLabの基本的な使い方に加え、CI/CDの実行基盤となるRunnerの仕組みと設定方法について、図解とデモを交えてわかりやすく解説しました。 セミナー動画 発表資料 Q&Aまとめ エラー発生時にメール・Slack・Teamsへ通知する方法は？ GitLabをオンプレミスでCI込み運用する際の必要スペックは？ CIがうまく動作しないときのトラブルシューティング方法 GitLab CIとGitHub Actions、どちらが使いやすい？ フルでCI/CDのステージを作るとどのような感じになりますか？（DockerfileのLint、Docker buildなど GitLabにもJenkinsのような拡張機能はありますか？ オンプレGitLabとgitlab.comの同期は可能？ セミナー動画 youtu.be 発表資料 speakerdeck.com Q&Aまとめ エラー発生時にメール・Slack・Teamsへ通知する方法は？ 質問 CI/CDの処理結果をメール、Slack, Teamsに送信したい（エラー発生時）。どのような設定が必要でしょうか？ 回答 GitLabではエラー時に各種通知を送信可能です。メールは個人設定か、.gitlab-ci.ymlで外部メール送信コマンドを利用。Slackは「Slack通知」インテグレーションでWebhookを設定、TeamsはIncoming Webhookを作成し.gitlab-ci.ymlでcurl等でPOSTします。ジョブにwhen: on_failureを指定すれば失敗時のみ通知されます。 GitLabをオンプレミスでCI込み運用する際の必要スペックは？ 質問 GitLabをCI込みでオンプレで動かす場合、どの程度のCPUやメモリを割り当てたらいいものでしょうか？ 回答 GitLabをCI込みでオンプレ運用する場合、最小構成でも4CPU/8GBメモリが推奨されます。ただしCIジョブの数や規模によってリソース消費が増えるため、中規模以上では8CPU/16GBメモリ以上を確保すると安心です。さらにGitLab Runnerを複数動かす場合はRunner用に別途リソースを見積もるのが望ましく、ジョブの並列数に応じて追加のCPU・メモリが必要になります。運用開始後は負荷状況をモニタリングし、必要に応じてスケールアップを検討してください。 CIがうまく動作しないときのトラブルシューティング方法 質問 CIがうまく動作していないような場合、どのようにトラブルシューティングをしたらいいのですか？ 回答 まずはGitLabのジョブのログを確認し、エラーの原因を特定します。.gitlab-ci.ymlの記述ミスやパイプライン設定の不備がないかも見直しましょう。次に、ローカル環境で同じコマンドを実行し、環境依存の問題を切り分けます。また、ランナーの状態や権限設定も確認が必要です。それでも解決しない場合は、GitLabの公式ドキュメントやコミュニティフォーラムを活用するとよいでしょう。 さらに最近では、CircleCIがMCP（Model Context Protocol）を活用し、生成AIとの連携による問題解決支援に取り組んでいます。これにより、ジョブログの解析やエラーの根本原因特定、修正案の提示までAIがサポートする未来が期待されています。現時点では実験的な段階ですが、今後こうした技術が他のCIツールにも広がる可能性があります。 GitLab CIとGitHub Actions、どちらが使いやすい？ 質問 GitLabのCIとGitHubのCI、どっちが使いやすいのでしょうか 回答 GitHub Actionsは特に拡張性や豊富なマーケットプレイスが魅力で、多様なワークフローが簡単に構築できます。また情報量が豊富で、検索すると多くの事例や解説が見つかるため、学習コストが低く初心者にも優しい点が特徴です。初めてCI/CDを触る場合はGitHub Actionsを推奨できます。 フルでCI/CDのステージを作るとどのような感じになりますか？（DockerfileのLint、Docker buildなど 質問 フルでCI/CDのステージを作るとどのような感じになりますか（様々なので困ると思いますが）？DockerfileのLint、Docker build など 回答 CI/CDのフルステージはプロジェクトにより異なりますが、一般的には コードチェック → ビルド → テスト → デプロイ の順に構成します。例えば、DockerfileのLintを行うステージでは hadolint を使い、次に docker build でイメージを作成、さらにセキュリティスキャンや動作確認テストを追加する流れです。最後に docker push でリポジトリにプッシュし、本番やステージング環境へデプロイします。全体をパイプライン化することで、自動で品質チェックとリリースが行える仕組みになります。

ローコード・ノーコード開発ツール「Pleasanter（プリザンター）」は、業務アプリケーションをスピーディに構築できる便利なプラットフォームです。特に、データ同士を関連付ける「リンク機能」は、複雑な業務プロセスの中でデータの整合性を保つうえで非常に重宝します。 しかし、実際に使い始めてみると、画面操作ではうまくいっていたのに、スクリプトやインポート時にうまく動かないという事象に直面することがあります。この記事では、Pleasanterを使い始めた方がつまずきがちなリンク機能の落とし穴と、その解決方法を紹介します。 起きていること リンク機能をインポート処理で活用する場合、リンクしたい値（たとえば、メールアドレスのドメイン）を事前に設定しておけば、Pleasanterが自動的にリンク先とマッピングしてくれます。 しかし、スクリプト(サーバースクリプトも含む)を使って抽出した値をそのままリンク項目に設定し、インポートしてみると、「？ xxxx」のように表示され、うまくマッピングされないことがあります。 なぜ起きてるのか まず、初歩的な原因として考えられるのは、そもそもマスタとして該当の値を登録していな いか、値の前後に空白文字か画面に表示されない特殊文字などが含まれていて、完全一致しないケースです。 それでも解決しない場合、問題の切り分けとして手動操作とスクリプト実行を試してみます。操作した結果、画面上から手作業で入力して登録されたが、スクリプトを使った処理では上手くいかない場合が今回のお話です。 この現象が起きる理由は、普段はブラックボックスになっており、あまり意識ないところかと思いますが、画面上では「ラベル名」や「表示名」が表示されています。見た目はテキストで紐づけられているように見えますが、Webアプリケーションのリストダウンを使用した際の標準的な仕組みです。 リストダウンで選択した値はデータ上では「ID」で管理されており、内部的には与えられた数字（サイトID）を使って関連付けを行っています。そのため、スクリプトで文字列として抽出した値を直接設定しても、Pleasanter側でIDとして認識されず、マッピングができなくなってしまうのです。 対処法 この問題を解決するには、先ほど触れたようにIDを指定するだけで解決します。IDを指定するだけと言ったものの、そこまで簡単な話でもなく、スクリプトで検索して取得してから設定する必要があります。 具体的な方法として、Pleasanterにはitems.Getという便利な関数が用意されており、指定した条件に合致するレコードを取得できます。以下はその一例です。 const results = items.Get( domainTableSiteId, JSON.stringify({ View: { ColumnFilterHash: { Title: mailDomain, }, }, }) ); // 結果から最初のアイテムを取得する let targetData = null; for (const result of results) { targetData = result; break; } if (targetData) { model.ClassA = targetData.ResultId; } このコードでは、抽出したドメイン名（mailDomain）を条件にリンク先のテーブル（domainTableSiteId）から該当するレコードを取得し、そのID（ResultId(または、IssueId)）をリンク項目（ClassA）に設定しています。 [source]

同じような環境を作ったり消したりしたい場合、仮想マシンや物理マシンに環境を展開する場合はAnsibleを使っています。 10年くらいでようやく、その習慣が染みつきました*1。 環境構築自体は好きなほうなので、台数が何台になっても環境のセットアップは苦ではありませんでした。 しかしある時気が付くんですよ。手動でセットアップし続けるのは時間の無駄をしているなって。 私は仕事柄、何かの環境を作っては破壊し、また作り直しと言うことをよくやります。 その都度手動でセットアップしては効率が良くないですし、いい加減Ansibleを使い始めようと重い腰を上げてはや10年。 歳もとるわけです。 AnsibleがAnsibleとAnsible Coreに別れて以降、私は主にAnsible Coreを使って必要なモジュールだけを追加して利用していました。 新しいAnsible Coreがリリースされればそれに追従して、なるべく古いバージョンを維持するような使い方はしたくないので避けてきました。 それができたのは、これまでのAnsibleが古いバージョンのPythonが導入した環境でもAnsibleが動いたためです。 これまでなんらはまるとは無かったのですが、つい最近、レガシーOSに割と新しめのAnsible Coreを使ったらいろいろはまったので、情報共有がてらブログにまとめようと思いました。 そのレガシーOSというのがRHEL8やAlmaLinux 8といった、システムPythonが3.6な環境です。その他のOSでも古いバージョンを使う場合、同じような問題に当たる可能性があります。 たとえばAnsible Playbookで次のような処理、具体的に言うとdnfコマンドで特定のパッケージをインストールするにはPython3のdnfモジュールの導入が必要です。 tasks: - name: Ensure dependencies are installed ansible.builtin.dnf: name: - wget - tar - firewalld - python3-firewall - glibc-langpack-en - glibc-locale-source state: latest RHEL 8.10などをターゲットマシンにする場合かつ、dnfコマンドを使ってソフトウェアのインストールを実行するロジックが必要な場合、python3-dnfパッケージがインストールされているのが最低要件です。 sudo dnf install python3-dnf インストールが終わったので早速チェックモードでPlaybookを流すと、エラーが発生しました。 % ansible-playbook -i hosts.ini install_yugabytedb.yml -C PLAY [Install YugabyteDB on Linux] *************************************************************************************************************************************************** TASK [Gathering Facts] *************************************************************************************************************************************************************** ok: [192.168.56.12] TASK [Ensure dependencies are installed] ********************************************************************************************************************************************* fatal: [192.

今月も Visual Studio Code の新バージョンがリリースされたので、リリースノートを見ていきましょう。 目次 目次 新バージョンのリリース情報 主なリリース内容 今月のピックアップ 新バージョンのリリース情報 Visual Studio Code のバージョン 1.101 がリリースされました。 主なリリース内容 変更点 変更内容 チャットツールセット機能の追加 関連ツールをグループ化できる「ツールセット」が定義可能に。エージェントモードで簡単に切り替え可能。 プロンプトへの MCP 対応 MCP サーバーで定義したプロンプトをチャットで / コマンドとして利用可能に。 チャット UX の改善 ユーザーと AI のメッセージを区別しやすく表示。リクエストの取り消しや添付の操作性も向上。 編集の効率化とキーバインドの統一 編集処理の最適化により大規模ファイルでの動作が改善。キー操作も整理・統一。 インプリシットコンテキストの改善 現在のファイルをチャット文脈に簡単追加・削除可能に。ファイル名とカーソル位置のヒントも提供。 タスク設定エラーの修正支援 タスク設定エラー時に GitHub Copilot による自動修正が可能に。 カスタムチャットモードの追加（プレビュー） 独自のチャットモードを作成可能に。ツールや指示のカスタマイズに対応。 要素をチャットに送信（実験的） Live Preview 拡張から Web 要素を選択し、チャットに送信可能に。 非公開拡張機能の警告表示 Marketplace から削除された拡張に警告アイコンを表示。問題の早期発見が可能に。 設定検索の AI サジェスト（プレビュー） 意味ベースの AI 検索で、自然言語から関連設定を提案可能に。 Copilot コーディングエージェント統合 PR や Issue を Copilot に割り当て可能。進捗やステータスも VS Code から確認可能。

6月に入り全国的にも一気に梅雨入りしましたね。過ごしにくい日が続きそうですが、適度に水分補給やエアコン使用して体調にはお気をつけください。 さて、今月も月が変わりましたので、恒例の月刊DevOpsニュースをお届けします。 データベース プログラミング 生成AI リリース その他 データベース 高速化したインメモリDB「Redis 8.0」正式リリース。AGPLv3対応によりオープンソースに復帰 www.publickey1.jp 高速化したインメモリDB「Redis 8.0」正式リリース。AGPLv3対応によりオープンソースに復帰 www.publickey1.jp プログラミング Google、自律型コーディングエージェント「Jules」をベータ公開 www.publickey1.jp Google、WebUIの自動生成ツール「Stitch」をベータ公開。自然言語で指示するとHTML/CSSを生成 www.publickey1.jp 生成AI ［速報］「GitHub Copilot Coding Agent」パブリックプレビュー。AIにIssueをアサインすると、解決に向け自律的にプログラミング www.publickey1.jp OpenAI、AIコードエディタの「Windsurf」の買収で合意との報道 www.publickey1.jp OpenAI、日本におけるデータレジデンシーの開始を発表。プロンプトやアップロードされたデータを日本国内のデータセンターに保存 www.publickey1.jp AWS、AIエージェントがGitHubのコードを読んで開発やレビューを行う「Amazon Q Developer in GitHub」プレビュー公開 www.publickey1.jp OpenAI、AIコードエディタの「Windsurf」の買収で合意との報道 www.publickey1.jp リリース Linux 6.15リリース、BPFに新しいキュー型スピンロックを実装 gihyo.jp その他 ［速報］マイクロソフト、Windows Subsystem for Linux（WSL）のコードをオープンソースとしてGitHubに公開 www.publickey1.jp [source]

今回のとことんDevOps勉強会は「いまさら聞けない Git 超入門 〜Gitって結局なに？から始める第一歩〜」と題して、日本仮想化技術の宮原がGit初心者や基礎から学び直したい方を対象とした超入門セッションを発表しました。 Gitは、ソフトウェア開発の現場をはじめ、ドキュメント管理やチーム開発など、さまざまなシーンで活用されているバージョン管理システムです。しかし、「聞いたことはあるけど、実はよく分かっていない」という方も少なくありません。 今回のセッションでは、「Gitとは何か？」「なぜ使うのか？」といった基本的なポイントから、clone、commit、pushといった主要コマンドの使い方までを、図解と実演を交えてやさしく解説しました。今後全3回にわたって、GitLabの使い方やCI/CDの基礎までを扱っていくシリーズの第1弾です。 セミナー動画 発表資料 よくある質問（FAQ） GitとGitHub（またはGitLab）は何が違うの？ commitしたらファイルは保存されたってこと？ コミットメッセージって適当でも大丈夫？ 間違えてファイルを消してしまった！元に戻せる？ .gitignoreって何？なんで必要なの？ セミナー動画 youtu.be 発表資料 speakerdeck.com よくある質問（FAQ） GitとGitHub（またはGitLab）は何が違うの？ 回答 Gitは「バージョン管理システム」そのもので、ファイルの変更履歴をローカルで記録・管理するツールです。 一方、GitHubやGitLabはそのGitの履歴をインターネット上で共有・運用できるリモートサービスです。 簡単に言えば： Git：道具（ローカル） GitHub/GitLab：道具を活かすプラットフォーム（クラウド） という関係です。 commitしたらファイルは保存されたってこと？ 回答 はい、git commitをするとローカル（自分のパソコン上）に履歴として保存されます。 ただし、他のメンバーと共有されるわけではありません。チームと共有するには、GitHubやGitLabなどのリモートリポジトリにgit pushで送信する必要があります。 コミットメッセージって適当でも大丈夫？ 回答 形式的にはどんなメッセージでも動作しますが、後から見返したときに意味が分かるように書くのがベストです。例は、わかりやすく日本語で表現しています。 例： NG：「修正」や「ちょっと直した」 OK：「バグ修正：画像が表示されない問題を解消」 履歴が読みやすくなり、チーム全体の生産性も向上します。 間違えてファイルを消してしまった！元に戻せる？ 回答 Gitは変更履歴を記録しているので、コミット済みの内容であれば復元が可能です。 例：git checkout <ファイル名>で直前の状態に戻すなど。 ただし、addやcommitをしていない「未保存状態」の削除は復元できないため、こまめなコミットが安全対策になります。 .gitignoreって何？なんで必要なの？ 回答 .gitignoreは、Gitで「追跡対象から外したいファイル」を指定するための設定ファイルです。 例えば： 一時ファイル（例：*.log） 個人の設定ファイル（例：*.env） コンパイル後のビルド成果物（例：dist/） これにより、チームに不要なファイルを誤って共有するリスクを防げます。GitHubやGitLabでも.gitignoreが設定されていないと、大量の無関係ファイルがアップされてしまうことも。 [source]