VS Codeで、Rubyで書かれたプログラムをデバッグする方法です。単一のRubyファイルをデバッグするためのものであり、RSpec、およびRuby on Railsなどのフレームワークを用いたプログラムは対象外です。 rbenvによる環境構築 環境の確認です。Macで確認していますが、Windows 10でも同様です。今回は、Rubyのバージョン管理マネージャであるrbenvを使用します。本記事執筆時点で最新版である2.7.1を使用して確認します。
VS CodeでPython - Visual Studio Marketplaceの拡張機能を使用すると、Pythonで記述されたプログラムのデバッグや、Jupyter Notebook環境をVS Codeで実行できて大変重宝します。たまに、このJupyter Notebookが、以下のエラーにより起動しなくなったことがあったため、その対処法をメモしておきます。
🔁 2026年リライト版 この記事は2020年4月に公開した「DjangoやFlask（Python）アプリの開発を始めるならVS Code + Dockerが最適」を、Dev Containers、uv、FastAPI、Cursor 前提で全面書き換えしたものです。 2020年からの主な変化点 Dev Containers（旧 Remote - Containers） が VS Code / Cursor の標準ワークフローに昇格 uv が pip + venv + pip-tools を一本化。2024年以降デファクト FastAPI が Django / Flask と並ぶ第三の選択肢に成長（ASGI、型ヒント、自動 OpenAPI） Cursor / Windsurf などAI統合IDE が台頭。VS Code の Dev Container 仕様と互換 Python 3.12 / 3.13: typing 改善、asyncio / pattern matching / GIL 弱化オプション 環境 macOS Sequoia 15 / Tahoe 26 Docker Desktop or OrbStack VS Code 1.95+ または Cursor 0.40+ 拡張機能: Dev Containers（ms-vscode-remote.remote-containers） プロジェクト構成 my-api/ ├── .devcontainer/ │ └── devcontainer.json ├── app/ │ └── main.py ├── pyproject.toml └── uv.lock 1. pyproject.toml を作成 FastAPI の例:
🔁 2026年リライト版 この記事は2020年4月に公開した「MacBook Proを購入したら最初に行うシステム環境設定（2020）」を、2026年時点のmacOS（Tahoe 26 / Sequoia 15）とApple Silicon前提で全面書き換えしたものです。macOS Ventura（13）以降、「システム環境設定」は「システム設定」にリネームされ、UIもiOS風に完全リデザインされたため、当時のメニュー構造はもう通用しません。
🔁 2026年リライト版 この記事は2020年4月に公開した「データ分析（データサイエンス）に必要な環境（Jupyter Lab）を一発で整えるワンライナー」を、Dev Containers / uv / Apple Silicon 前提で全面書き換えしたものです。 2020年からの主な変化点 Apple Silicon (M1–M4) が主流化。jupyter/datascience-notebook も linux/arm64 イメージが公式公開（マルチアーキ化） Dev Containers（旧 VS Code Remote - Containers） が成熟。devcontainer.json 一枚で VS Code / Cursor から即座にコンテナ開発可能に uv（Rust製Pythonパッケージマネージャ） が2024年以降デファクト化。pip install より10〜100倍高速 Rancher Desktop / OrbStack / colima など Docker Desktop の代替が普及（ライセンス変更で企業は代替を検討するケース多し） JupyterLab 4.x + AI Notebook extensions（Jupyter AI、Cursor Notebooks）で対話的ML開発が一般化 パターン1: 最速ワンライナー（変わらず健在） ❯ docker run --rm -p 10000:8888 \ -e JUPYTER_ENABLE_LAB=yes \ -v "$PWD":/home/jovyan/work \ quay.io/jupyter/datascience-notebook:latest 2024年からイメージレジストリが Docker Hub → quay.io/jupyter/* に移行しています。jupyter/datascience-notebook は Docker Hub にも残っていますが、更新が遅いので quay.io 版の使用を推奨します。
🔁 2026年リライト版 この記事は2020年4月に公開した「ローカルホストでGitHubの環境を汚さずにNetlify CMSをテストする」を、2026年時点の Decap CMS（2023年に Netlify CMS がリネーム・フォーク）前提で書き換えたものです。 2026年の状況 — Netlify CMS → Decap CMS Netlify CMS は、2023年2月に元運営元 Netlify が開発撤退し、コミュニティで Decap CMS としてフォーク・改名されました。パッケージ名も netlify-cms から decap-cms へ変わっています。ローカルで動かすためのプロキシサーバも netlify-cms-proxy-server から decap-server に名称が変わりました。
🔁 2026年リフレッシュ macOS Tahoe 26 でも ⌘+Shift+5 のスクリーンショットUIで「フローティングサムネールを表示」を直接オフにできます。本文の defaults write com.apple.screencapture show-thumbnail -bool false も現役で、設定GUI経由と同じ結果になります。キルール後は killall SystemUIServer で反映します。 スクリーンショットを撮影した際に右下に表示される、サムネールを非表示にする方法をご紹介します。スクリーンショットを保存する前に、注釈やテキストを付け加えてマークアップしたり、誰かに共有するには便利な機能ですが、即座に保存したい場合には少し邪魔な機能です。
🔁 2026年リフレッシュ macOS Sequoia 15 / Tahoe 26 でも Automator の Folder Action は引き続き利用可能です。一方、より柔軟な代替として Shortcuts.app（ショートカット） の「オートメーション」がmacOSにも来ており、画像圧縮なら sips -Z 2000 や pngquant/guetzli を Shortcut から呼び出す構成が2026年では一般的です。本文の Automator レシピ自体は今でも動作します。 撮影したスクリーンショットを、ブログ等の用途で掲載したいことがあります。取得したスクリーンショットをそのままアップロードするとサイズが大きく、閲覧者の負担やWebページの表示に時間がかかります。アップロードの事前に、画像を圧縮してファイルサイズを小さくしておくことが推奨されます。
🔁 2026年リライト版 この記事は2019年5月に公開した「Macのターミナル（iTerm）で生産性を上げるための方法」を、2026年時点の定番構成（Starship、sheldon、fzf、zoxide、Nerd Fonts v3）に合わせて全面書き換えしたものです。 2019年からの主な変化点 zsh がデフォルトシェル: macOS Catalina 10.15（2019年10月）以降、ログインシェルは zsh が既定。chsh -s /bin/zsh は不要 oh-my-zsh 一辺倒からの卒業: 依然として人気だが、起動が遅いため軽量フレームワーク（sheldon / zinit）に乗り換える人が増えた プロンプトテーマ: powerlevel9k は開発停止、後継の powerlevel10k か、シェル非依存で高速な Starship が定番 Nerd Fonts v3: アイコン体系が刷新され、brew install --cask font-hack-nerd-font の書式も font-hack-nerd-font に変わった（brew cask install コマンドは2020年に廃止） ターミナルアプリ: iTerm2 に加え、GPU アクセラレーションの速い Ghostty（2024年 GA）や WezTerm、Alacritty が有力候補 ファジーツール: fzf は健在。加えて zoxide（cd の賢い代替）、eza（ls の代替）、bat（cat の代替）、ripgrep が新定番 2026年版 最小構成 以下、zsh + Starship + sheldon + fzf + zoxide の組み合わせを紹介します。oh-my-zsh を使わないため、起動が軽く、設定ファイルの見通しもよくなります。
前回の記事でGitの基本的な操作方法についてご紹介しました。ローカル上にGitのリポジトリを作成し、コミット、ブランチ、マージといったGitのコアとなる部分について学びました。今回は、GitHubを使用して主にリモートリポジトリの扱いに焦点を当ててご紹介します。あらかじめ、GitHubのアカウントを作成しておいてください。（今回はGitHubの機能を使用するわけではないため、厳密にはGitHubのアカウントについては必須ではありません） まずは、GitHubにサインインして、新規リポジトリを作成しましょう。その際に、すでにコミットされているローカルリポジトリの情報をマージするため、「Initialize this repository with a README」のチェックは外しておきましょう。今回は、trainingという名前で空のリポジトリを作成しました。