<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>あんぜんぴんの落書き帳</title>
    <link>https://annpin.com/</link>
    <description>Recent content on あんぜんぴんの落書き帳</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>ja</language>
    <copyright>© 2018-2024. All rights reserved.</copyright>
    <lastBuildDate>Sat, 11 Oct 2025 08:19:52 +0900</lastBuildDate><atom:link href="https://annpin.com/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>HTTP/3 を試してみる</title>
      <link>https://annpin.com/posts/2025-10-11-20251011-082051http3-setup/</link>
      <pubDate>Sat, 11 Oct 2025 08:19:52 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2025-10-11-20251011-082051http3-setup/</guid>
      <description>2025 年 10 月現在、世界中のウェブサイトの約 35 % が HTTP/3 での接続に対応しているようだ (https://w3techs.com/technologies/details/ce-http3). そろそろ仕事でも HTTP/3 接続への対応が必要になりそうなので、ひとまず HTTP/3 に対応した nginx サーバーを立てられないかを試してみる.
しかし、そもそも自分はウェブサイトを閲覧する際にいつも HTTP/3 で接続していたのだろうか？ HTTP/2 のままだったのだろうか？ このあたりがよくわかっていなかった.
なので、まずはブラウザから HTTP/3 接続が行われているのかどうかを確かめるところからはじめてみる. 幸い Cloudflare が提供している検証サイト (https://cloudflare-quic.com) にアクセスしてみると、現在のブラウザから HTTP/3 で通信できているのかを確認できるようだ.
試してみたところ、どうやら macOS Sequoia の M1 MacBook Pro からは Google Chrome 、 Firefox 、 Vivaldi などの全てのブラウザで HTTP/2 で接続されてしまっていた.
ちょっとややこしそうな気配を感じるので、先に curl などのコマンドラインプログラムから HTTP/3 での通信が行えるのかどうかを確かめてみることにした.
curl からの HTTP/3 接続を試す curl は 2023 年にリリースされた v8.5.0 から HTTP/3 での接続に対応しているようなので、 macOS Sequoia 標準の curl ならば接続できるはずである (https://news.</description>
    </item>
    
    <item>
      <title>Cats でデフォルトで導出される EitherT の Parallel インスタンスはエラーを集積しないという話</title>
      <link>https://annpin.com/posts/2025-09-17-20250917-182649eithert-parallel-instance-for-error-accumulation/</link>
      <pubDate>Wed, 17 Sep 2025 18:26:01 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2025-09-17-20250917-182649eithert-parallel-instance-for-error-accumulation/</guid>
      <description>タイトルの通り. 「 Either ←→ Validated 間で行けるんだから EitherT でも行けるだろう…​」 と思っていたところ見事にハマった.
検索してもあまり説明している人がいなそうなので、とりあえずメモしておく.
TL;DR 自分の使っているエフェクトが F[_] であるならば、以下の 1 行をスコープ中に含めれば良い.
given Parallel[F] = EitherT.accumulatingParallel おわり.
以下は詳細.
Cats では Parallel 型クラスを介して Either と Validated の自動的な変換が提供されている まずは前置き.
例えば、 Scala には「エラーの可能性」を表現するデータ型として Either[E, A] 型が用意されている. Either はエラーを表すデータ型 E を固定することで Either[E, *] でモナドを成すため、 flatMap あるいは for 式を用いて複数の Either 値を合成することができる. 例えば、 val ea: Either[E, A] 、 val eb: Either[E, B] 、 val ec: Either[E, C] であるとき、以下のような for 式を書くことができる.
for { a &amp;lt;- ea b &amp;lt;- eb c &amp;lt;- ec } yield { /* a, b, c を使って何か計算 */ } しかし、 ea 、 eb 、 ec の中の 1 つ以上がエラー値である場合、それらのエラーを集めようとすると困ってしまうこととなる.</description>
    </item>
    
    <item>
      <title>macOS で Neovim を使っているときに発生する Too many open files エラーを解決する</title>
      <link>https://annpin.com/posts/2025-05-16-20250516-045804macos-too-many-open-files-error/</link>
      <pubDate>Fri, 16 May 2025 04:57:40 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2025-05-16-20250516-045804macos-too-many-open-files-error/</guid>
      <description>しばらく前から macOS 上で LSP を有効にして Neovim で開発を行っていると、唐突に
Process failed to start: too many open files: ... と表示され、その後ファイルの保存も何もできなくなるという問題が発生していた.
どうやら原因は macOS 自体の「ファイルを開ける最大数」の設定だったようだ.
ターミナル上で launchctl を用いて設定を確認してみる.
$ launchctl limit cpu unlimited unlimited filesize unlimited unlimited data unlimited unlimited stack 8372224 67092480 core 0 unlimited rss unlimited unlimited memlock unlimited unlimited maxproc 10666 16000 maxfiles 256 unlimited ということで maxfiles は 256 (デフォルト) に設定されている. 左側に表示されている値が &amp;#34;ソフトリミット&amp;#34; で、右側に表示されている値が &amp;#34;ハードリミット&amp;#34; であるとのこと.
基本的にはソフトリミットの上限値が適用されているらしく、この値を変更すれば良いらしい.
/Library/LaunchDaemons/limit.maxfiles.plist というファイルを作成し、そこに更新後の maxfiles の値を書いておく. (このファイルはデフォルトでは存在しないらしいので、新規に作成する必要がある.</description>
    </item>
    
    <item>
      <title>Cloudflare Workers を試してみる</title>
      <link>https://annpin.com/posts/2024-11-05-20241105-030828cloudflare-workers-%E3%82%92%E8%A9%A6%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B/</link>
      <pubDate>Tue, 05 Nov 2024 03:08:15 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2024-11-05-20241105-030828cloudflare-workers-%E3%82%92%E8%A9%A6%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B/</guid>
      <description>Cloudflare Workers の Get started を試してみる.
TypeScript プロジェクトの場合 C3 による Worker プロジェクトの作成 まず、 C3 (create-cloudflare-cli) でプロジェクトを生成する. これは pnpm create cloudflare@latest コマンドで行うことができる.
$ pnpm create cloudflare@latest hello-cloudflare-workers hello-cloudflare-workers ────────────────────────────────────────────────────────────────────────────────────────────────────────── 👋 Welcome to create-cloudflare v2.31.1! 🧡 Let&amp;#39;s get started. 📊 Cloudflare collects telemetry about your usage of Create-Cloudflare. Learn more at: https://github.com/cloudflare/workers-sdk/blob/main/packages/create-cloudflare/telemetry.md ────────────────────────────────────────────────────────────────────────────────────────────────────────── ╭ Create an application with Cloudflare Step 1 of 3 │ ├ In which directory do you want to create your application?</description>
    </item>
    
    <item>
      <title>GNU LilyPond の動作テスト</title>
      <link>https://annpin.com/posts/2024-11-04-20241104-033723/</link>
      <pubDate>Mon, 04 Nov 2024 03:37:08 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2024-11-04-20241104-033723/</guid>
      <description>GNU LilyPond のコードを Asciidoc 中に埋め込んで楽譜を表示できるかのテスト.
References https://lilypond.org/index.ja.html
https://docs.asciidoctor.org/diagram-extension/latest/diagram_types/lilypond/</description>
    </item>
    
    <item>
      <title>Docker コンテナ内の PHP 8.0 を macOS 上の PhpStorm から Xdebug 3.3.2 を介してデバッグする</title>
      <link>https://annpin.com/posts/2024-08-02-20240802-145200/</link>
      <pubDate>Fri, 02 Aug 2024 14:53:00 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2024-08-02-20240802-145200/</guid>
      <description>Docker コンテナ内の設定 まず、 Docker コンテナ内に PHP と Xdebug を導入しておく必要がある. Xdebug は pecl コマンドが使えれば簡単にインストール可能. PHP をソースからビルドする場合、 configure 実行時に --with-pear フラグを付けておかないと pecl コマンドがインストールされないため要注意.
# PHP 8.0.10 をソースからインストールする場合は Dockerfile の記述は以下のような感じ. RUN wget https://github.com/php/php-src/archive/refs/tags/php-8.0.10.tar.gz \ &amp;amp;&amp;amp; tar xvzf php-8.0.10.tar.gz \ &amp;amp;&amp;amp; cd php-src-php-8.0.10 \ &amp;amp;&amp;amp; ./buildconf --force \ &amp;amp;&amp;amp; ./configure \ --enable-fpm \ --enable-gd \ --with-zip=/usr/lib64 \ --with-mysqli \ --with-pdo-mysql \ --with-curl \ --with-zlib \ --with-openssl \ --with-pear \ &amp;amp;&amp;amp; make \ &amp;amp;&amp;amp; make install \ &amp;amp;&amp;amp; cp php.</description>
    </item>
    
    <item>
      <title>mac で Realforce R3 mac 配列を使っていると日本語入力切替が遅延する</title>
      <link>https://annpin.com/posts/2024-07-09-20240709-011600/</link>
      <pubDate>Tue, 09 Jul 2024 01:16:00 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2024-07-09-20240709-011600/</guid>
      <description>入力切替の際、画面中央などに切り替え先の入力ソースを表示しようとするのが遅延の原因であるようだ. (https://scribble.washo3.com/mac-input-switch.html)
改善方法 システム設定 -→ キーボード -→ キーボードショートカット と進んでキーボードショートカットの登録ウィンドウを表示する。
入力ソース を開き、 前の入力ソースを選択 と 入力メニューの次のソースを選択 のキーボードショートカットを逆転させる.
デフォルトでは 前の入力ソースを選択 に command + space 、 入力メニューの次のソースを選択 に command + option + space が割り当てられている.
これを逆転させ、 前の入力ソースを選択 に command + option + space 、 入力メニューの次のソースを選択 に command + space を割り当てる.
これにより、入力切替の際の遅延が解消し、スムーズに切り替えが行えるようになる.
References https://scribble.washo3.com/mac-input-switch.html</description>
    </item>
    
    <item>
      <title>英語ツール</title>
      <link>https://annpin.com/posts/2023-07-18-20230718-195510/</link>
      <pubDate>Tue, 18 Jul 2023 19:55:10 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-07-18-20230718-195510/</guid>
      <description>Grammarly
https://app.grammarly.com
Quillbot
rephrase ツール
https://quillbot.com
Google Translate
https://translate.google.com
DeepL
https://www.deepl.com/translator</description>
    </item>
    
    <item>
      <title>Linux へのログイン履歴を調べる</title>
      <link>https://annpin.com/posts/2023-07-18-20230718-154847/</link>
      <pubDate>Tue, 18 Jul 2023 15:48:47 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-07-18-20230718-154847/</guid>
      <description>lastlog と last コマンド lastlog コマンドを使うとその Linux マシンの各ユーザーが最後にログインしたのはいつであるかを一覧表示することができる. この内容は /var/log/lastlog の中身を整形したものである.
last ユーザー名 コマンドを使うと指定したユーザーの直近のログイン履歴を調べることができる. この内容は /var/log/wtmp の中身を整形したものである. 各ログインはどの IP アドレスからいつ行われたのかが記録されているため、 https://rakko.tools/tools/11/ などを使えばその IP アドレスがどこのエリアのものであるかを調べることができる.
References https://uxmilk.jp/26163
https://rakko.tools/tools/11/
https://qiita.com/toshihirock/items/22de12f99b5c40365369</description>
    </item>
    
    <item>
      <title>display 属性 : block / inline / flex</title>
      <link>https://annpin.com/posts/2023-07-16-20230716-134733/</link>
      <pubDate>Sun, 16 Jul 2023 13:47:33 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-07-16-20230716-134733/</guid>
      <description>詳細 display: block
親要素も display: block の場合、横いっぱいに広がろうとする.
display: block 要素同士は間に改行が入るように解釈されるために縦に並ぼうとし、横に並ぶことはない.
一般的なユーザーエージェントスタイルシートでは body 要素が display: block であるため、 インライン要素や flex 要素が間に入らない限りは基本的に常に横いっぱいに表示される.
width や height で幅を設定することはできる. ただし、横に並ぶことはない.
display: inline
横に並ぼうとする.
幅・高さを持たず、中に含んでいる要素の幅・高さが自動的に自身の幅・高さとして設定される.
display: flex
中に含む要素を flexbox のルールに従って並べようとする.
中の要素数が 1 つだけの場合でも、 display: block のように自動的に横に伸びたりはしない.
中の要素が display: block であっても、その要素は横に伸びない. (親要素が display: block でないため). そのような場合、 要素に対して明示的に width: 100% のように幅を設定しなければならない.</description>
    </item>
    
    <item>
      <title>設定ファイルを読み込まずに Vim 8 / NeoVim を起動する</title>
      <link>https://annpin.com/posts/2023-07-09-20230709-004906/</link>
      <pubDate>Sun, 09 Jul 2023 00:49:07 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-07-09-20230709-004906/</guid>
      <description>--clean オプションをつけるだけ # Vim 8 $ vim --clean ファイル名 # NeoVim $ nvim --clean ファイル名 References https://vi.stackexchange.com/questions/6112/how-can-i-get-vim-to-ignore-all-user-configuration-as-if-it-were-freshly-instal</description>
    </item>
    
    <item>
      <title>Debian 系 OS でログインを一定回数失敗したアカウントをロックする</title>
      <link>https://annpin.com/posts/2023-05-21-20230521-181737/</link>
      <pubDate>Sun, 21 May 2023 18:17:37 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-05-21-20230521-181737/</guid>
      <description>設定手順 cd /etc/pam.d/
sudo cp common-auth common-auth.bk
sudo vim common-auth
# # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms.</description>
    </item>
    
    <item>
      <title>443 番ポートを使った ssh 接続</title>
      <link>https://annpin.com/posts/2023-05-21-20230521-175632/</link>
      <pubDate>Sun, 21 May 2023 17:56:32 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-05-21-20230521-175632/</guid>
      <description>設定手順 基本的には sshd_config のポート番号を変更して sshd を再起動するだけ.
リモートサーバに ssh 接続する.
デフォルトの 22 番接続でのパスワード認証ならば、 ssh ユーザ名@アドレス の書式でログインできる.
パスワード認証のかわりに鍵認証を使っている場合は ~/.ssh/config にかかれているホスト名を使って ssh ホスト名 で OK.
cd /etc/ssh/
sudo cp sshd_config sshd_config.bk
sudo vim sshd_config
13 行目付近にある #Port 22 の下の行に Port 443 を追記して保存.
sudo systemctl restart sshd.service
これにより、ログアウトしてから再度 ssh 接続しようとするとデフォルトの 22 番ポートでの接続は Connection refused で拒否されるようになる.
代わりに ssh -p 443 ユーザ名@アドレス のようにして明示的にポート番号を 443 番と指定するとパスワード認証でログインできるようになる. 鍵認証を行っている場合には ~/.ssh/config に以下のようにしてポート番号の指定を追加すれば良い.
~/.ssh/config Host ホスト名 User ユーザ名 Port 443 HostName IPアドレス IdentityFile 秘密鍵ファイルのパス References https://mymanfile.</description>
    </item>
    
    <item>
      <title>モナド則</title>
      <link>https://annpin.com/posts/2023-05-06-20230506-052908/</link>
      <pubDate>Sat, 06 May 2023 05:29:08 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-05-06-20230506-052908/</guid>
      <description>左同一性 (left identity) (return x) &amp;gt;&amp;gt;= f == f x return は &amp;gt;&amp;gt;= に対してほとんど単位元である.
f で移される前に何度上下に写しても結果は変わらない.
Category&amp;#39; +-----+ +-----+ | m X | | m Y | +-----+ +-----+ | mx | | my | +-----+ +-----+ ^ : &amp;gt;&amp;gt;= ^ return | : f / | : +-------+ | : / | v / +-----+ +-----+ | X | | Y | +-----+ +-----+ | x | | y | +-----+ +-----+ Category 右同一性 (right identity) my &amp;gt;&amp;gt;= return == my return は &amp;gt;&amp;gt;= に対してほとんど単位元である.</description>
    </item>
    
    <item>
      <title>macOS でのダミーファイル生成</title>
      <link>https://annpin.com/posts/2023-04-21-20230421-114909/</link>
      <pubDate>Fri, 21 Apr 2023 11:49:09 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-04-21-20230421-114909/</guid>
      <description>ダミーファイルを作る macOS 上でダミーファイルを作る場合、 mkfile コマンドを使うのが簡単.
コマンドの書式 mkfile &amp;lt;サイズ&amp;gt; &amp;lt;ファイル名&amp;gt; サイズには単位を指定することができ、 b (Byte)、 k (KB)、 m (MB)、 g (GB) を数値の後ろに付与してやればよい.
作成例 $ mkfile 1m dummy.txt ファイル属性（作成日時・更新日時 etc.）を変更する ファイルの更新日時を変更するだけならば touch コマンドのほうが簡単なようだが、 macOS には setfile というファイル属性 (作成日時、更新日時、作成者) を変更するためのコマンドが存在する.
setfile コマンドの使い方については以下の通り.
Usage: SetFile [option...] file... -a attributes # attributes (lowercase = 0, uppercase = 1)* -c creator # file creator -d date # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])* -m date # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])* -P # perform action on symlink instead of following it -t type # file type Note: The following attributes may be used with the -a option: A Alias file B Bundle C Custom icon* D Desktop* E Hidden extension* I Inited* M Shared (can run multiple times) N No INIT resources L Locked S System (name locked) T Stationery V Invisible* Z Busy* Note: Items marked with an asterisk (*) are allowed with folders Note: Period (.</description>
    </item>
    
    <item>
      <title>Scala 2 の implicits と Scala 3 の対応機能</title>
      <link>https://annpin.com/posts/2023-04-15-20230415-151553/</link>
      <pubDate>Sat, 15 Apr 2023 15:15:53 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-04-15-20230415-151553/</guid>
      <description>Scala Matsuri 2023 一日目の発表 Say goodbye to implicits (https://slides.com/magdastozek/goodbye-implicits-20) を受けて、Scala 2 の implicits を Scala 3 の機能と比較してみる.
implicits の機能 文脈の引き回し
既存の型への機能の追加 (Enrich my library)
型クラス
暗黙型変換 (implicit conversion)
依存性の注入 (dependency injection)
expressing capabilities
computing new types
proving relationships between types
Scala 2 における implicits 関連の機能 implicit parameter (文脈の引き回し・型クラスインスタンスの適用)
implicit argument
implicit value (型クラスインスタンスの定義)
implicit object
implicit def (暗黙の型変換・(型コンストラクタのための) 型クラスインスタンスの定義)
implicit class (Enrich my library パターン・型クラス syntax の導入)
implicit import incantations (呪術的な import 文)</description>
    </item>
    
    <item>
      <title>macOS でのいろいろなキャッシュの置き場所</title>
      <link>https://annpin.com/posts/2023-04-03-20230403-183433/</link>
      <pubDate>Mon, 03 Apr 2023 18:34:33 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-04-03-20230403-183433/</guid>
      <description>Maven
~/.m2/repository
sbt (coursier)
~/Library/Caches/Coursier/v1
Python、Node.js、Java/Scala などのプログラム中からアクセスできる一時フォルダ
/private/var/folders/ql/3v2ny0zn6szg8p7h62zkrz_w0000gn/T
(環境によってフォルダ名は異なりそう)</description>
    </item>
    
    <item>
      <title>GHCup で Haskell 環境をインストールする際のワークアラウンド</title>
      <link>https://annpin.com/posts/2023-02-14-20230214-202916/</link>
      <pubDate>Tue, 14 Feb 2023 20:29:16 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-02-14-20230214-202916/</guid>
      <description>症状 2023/02 現在、GHCup で GHC をインストールして stack run や stack build しようとすると、以下のようなエラーが発生する.
ld64.lld: error: unknown argument &amp;#39;--gc-sections&amp;#39; clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc&amp;#39; failed in phase `Linker&amp;#39;. (Exit code: 1) この原因は GHC をインストールする際に Homebrew でインストールした clang で GHC がビルドされてしまうことであるようだ.
この問題を回避するためには、Homebrew を PATH から外した状態で GHCup で GHC をインストールすればよい.
状況 現在、 brew list を実行してみるとたしかに llvm パッケージがインストールされた環境となっている.
さらに、 llvm パッケージでインストールされる clang にパスを通すため、 .zshrc に以下のようにパスの指定が記述されている.</description>
    </item>
    
    <item>
      <title>Docker コンテナ中で動いているウェブサービスから送信専用メールを送れるようにする</title>
      <link>https://annpin.com/posts/2023-01-11-20230111-035207/</link>
      <pubDate>Wed, 11 Jan 2023 03:52:07 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2023-01-11-20230111-035207/</guid>
      <description>ウェブサービスの開発では登録されたユーザーの確認などのために返信不可の送信専用メールを送る必要が出てくる. この機能の実装ができるよう、今回は Docker コンテナ内で動いている Debian 11 (bullseye) から Postfix を用いて送信専用メールを送れるように環境構築を行う.
例えば PHP からメールを送信する場合には mail 関数や mb_send_mail 関数といった関数が利用できるが、 これらの関数は pnp.ini に記述された sendmail_path の値を参照することでメール送信用のプログラム (MTA) を指定できるようになっている. (https://www.javadrive.jp/php/mailini/index1.html)
「 sendmail_path という名前なのだから sendmail というプログラムをインストールして使わなければならない. だから Postfix は関係ない」 …​というわけではなく、 sendmail の代わりに Postfix をインストールしても全く問題なくメール送信できるので sendmail を使わなければならないと思っていた人も一旦 Postfix を試してみて欲しい.
前提 1: メール送受信システムの構成要素 メーラーの設定に慣れている人ならば、メールの送信と受信にはそれぞれ異なるプロトコルが使われていることを知っているだろう. メール送信の際には SMTP (Simple Mail Transfer Protocol) というプロトコル、受信の際には POP3 (Post Office Protocol 3) や IMAP (Internet Message Access Protocol) というプロトコルが使われている.
しかし、Postfix を使った送信専用メールのような「メーラーを使わないメール送受信のための設定」を行う場合、 MTA とか MDA のような今まで見たことのない略称がたくさん出てきて混乱すると思われる.</description>
    </item>
    
    <item>
      <title>vim でのレジスタ操作</title>
      <link>https://annpin.com/posts/2022-12-29-20221229-060854/</link>
      <pubDate>Thu, 29 Dec 2022 06:08:54 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-12-29-20221229-060854/</guid>
      <description>Vim や NeoVim において y や d 、 c といったオペレータでテキストのヤンクやカットを行う際、一度ヤンクした内容を直後のヤンクやカットで上書きしてしまってヤンクをやり直したりすることが頻発する.
このような場合には Vim の レジスタ 機能を活用すると良い. Vim は標準で複数のレジスタを用意してくれており、 a から z の 26 のレジスタはユーザーが自由に値を保存するために使えるようになっている.
なお、 + レジスタは OS 標準のクリップボードの内容となる.
レジスタの使い方 レジスタを使用するには、 &amp;#34; + レジスタ名 + コマンド のように入力すればよい.
例えば、現在の行を n レジスタに格納したい場合には、 &amp;#34;nyy と入力する. 同様に、 n レジスタに格納した内容をペーストしたい場合には &amp;#34;np あるいは &amp;#34;nP とすれば OK.
References https://qiita.com/a4_nghm/items/d29b35f5d056ef5da0d9
https://qiita.com/r12tkmt/items/97afb4b489966e746b20
https://qiita.com/0829/items/0b3f63798b6910623efc</description>
    </item>
    
    <item>
      <title>CSS 設計: FLOCSS と BEM について - 破綻しにくい CSS 命名規則</title>
      <link>https://annpin.com/posts/2022-12-22-20221222-003537/</link>
      <pubDate>Thu, 22 Dec 2022 00:35:37 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-12-22-20221222-003537/</guid>
      <description>良い CSS 設計とは？ (Philip Waltson) 予測しやすい: クラス名を見るだけでどんなクラスであるかを大体理解できる.
再利用しやすい: プロジェクト中の複数箇所で必要になった際に使い回すことができる.
保守しやすい: スタイルが重複したり、意図せずにスタイルが当たったりしない.
拡張しやすい: 複数人での作業を全体に、誰が作業したとしても同じような品質のコードを得るために共通のルールを定める.
FLOCSS: Foundation Layout Object CSS (フロックス) CSS を 3 つのレイヤーと 3 つの子レイヤーに分けて管理する.
分類ごとにファイルを分けて管理する.
| |- Foundation : 基本的なスタイル (リセット CSS、基本指定、変数定義、ファンクション etc.) |- Layout : サイト共通で使用するブロック (ヘッダー、メイン、フッター、サイドバー etc.) `- Object : 再利用可能なモジュールを 3 つの子レイヤーに分けて管理. |- Component : 最小単位のモジュール (ボタン、タイトル、フォーム、アイコン etc.) |- Project : 複数の Component やそれに該当しない要素 (プロフィール、カード、モーダル etc.) `- Utility : スタイルの調整のための便利クラス Sass プロジェクトのファイル構成 /sass | |- /foundation | |- _base.</description>
    </item>
    
    <item>
      <title>数学・物理学における 「線型」 と 「非線型」 という言葉について</title>
      <link>https://annpin.com/posts/2022-12-08-20221208-143938/</link>
      <pubDate>Thu, 08 Dec 2022 14:39:38 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-12-08-20221208-143938/</guid>
      <description>線型と非線型という分け方は大雑把すぎる？ 本質は、 「重ね合わせの原理」が使えるかどうか ということ. 「重ね合わせの原理」が使えるならば 線型 、使えないならば 非線型 といえる.
すなわち、そもそも 「線型・非線型の 2 通りへの分類じゃ大雑把だからもっと多く分類するほうが良いのでは」 という考えが見当外れ.
非線型とは、 問題を解く際に有力な道具である 「重ね合わせの原理」 を使うという試みが成功しない問題である という認識を表したものと解釈するべき.
「重ね合わせの原理」が使えれば、フーリエ解析や演算子法といった道具が使えることとなる.
重ね合わせの原理とは？ 「重ね合わせの原理」 とは、 線型な系一般に成り立つ特徴的な原理 といえる. すなわち、&amp;#34;二つ以上の入力&amp;#34; が同時に与えられた時に、系が返す応答が それぞれの入力が単独に加えられた場合に返される応答の総和となること をいう. したがって入力 A に対して応答 X が返され、入力 B に対して応答 Y が返されるならば、入力 ( A + B ) に対して返される応答は ( X + Y ) となる.
重ね合わせの原理が成り立つためには、 加法性 および 斉次性 という二つの性質が成立する必要がある. 以下のような性質を持つ写像 (線形写像) はそのような性質を持つものの一つ.
加法性: F(x1 + x2) = F(x1) + F(x2)
斉次性: F(a x) = a F(x)</description>
    </item>
    
    <item>
      <title>DNS の設定で出てくる A レコードと CNAME レコードについて</title>
      <link>https://annpin.com/posts/2022-11-16-20221116-210516/</link>
      <pubDate>Wed, 16 Nov 2022 21:05:16 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-16-20221116-210516/</guid>
      <description>毎回忘れるのでメモ.
A レコードと CNAME レコードの違いは？ A レコード は ドメイン名 (ex. blog.annpin.com) と IP アドレス (ex. 35.185.44.232) の対応付け を行うもの.
CNAME レコード は ドメイン名 (ex. howm.annpin.com) と既に存在している他のドメイン名 (ex. annpin.gitlab.io) の対応付け を行うもの.
ドメイン名 : IP アドレス = 1 : 1 の関係となるケース 基本的に DNS はドメイン名を IP アドレスに変換するものなので、ドメイン名と IP アドレスが 1 : 1 対応するという関係は特に不思議ではない.
例えば、 dig コマンドを使ってみると blog.annpin.com が 35.185.44.232 という IP アドレスと 1 : 1 で対応していることがわかる.
$ dig blog.annpin.com ; &amp;lt;&amp;lt;&amp;gt;&amp;gt; DiG 9.10.6 &amp;lt;&amp;lt;&amp;gt;&amp;gt; blog.</description>
    </item>
    
    <item>
      <title>Nerd Font が合成された Ricty フォントを生成してみる</title>
      <link>https://annpin.com/posts/2022-11-14-20221114-231324/</link>
      <pubDate>Mon, 14 Nov 2022 23:13:25 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-14-20221114-231324/</guid>
      <description>まずは必要なファイルをダウンロード.
Font Forge のインストールと必要ファイルのダウンロード # Install Font Forge $ brew install fontforge # Download generator script $ wget https://rictyfonts.github.io/files/ricty_generator.sh $ wget https://rictyfonts.github.io/files/os2version_reviser.sh # Download Migu 1M $ wget https://osdn.net/projects/mix-mplus-ipa/downloads/72511/migu-1m-20200307.zip また https://fonts.google.com/specimen/Inconsolata の Download family から Inconsolata フォントを Inconsolata.zip としてダウンロードし、Zip ファイルをこのフォルダに配置しておく.
$ tree . ├── Inconsolata.zip ├── README.adoc ├── migu-1m-20200307.zip ├── os2version_reviser.sh └── ricty_generator.sh 0 directories, 5 files 各フォントを解凍する.
# Decompress zip files $ unzip migu-1m-20200307.zip $ unzip Inconsolata.zip -d Inconsolata 解凍されたフォントファイルを (取り敢えず) すべてインストールしておく.</description>
    </item>
    
    <item>
      <title>Docker コンテナ内の PHP を VSCode でデバッグする (Docker Desktop for Mac)</title>
      <link>https://annpin.com/posts/2022-11-08-20221108-225009/</link>
      <pubDate>Tue, 08 Nov 2022 22:50:09 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-08-20221108-225009/</guid>
      <description>Docker コンテナ中で動いている PHP をホストの macOS 上の VSCode でデバッグするための備忘録. ここでは PHP 7.4.30 を PHP-FPM のコンテナで動かしているとする.
まずはコンテナ中に Xdebug をインストール.
Dockerfile FROM php:7.4.30-fpm-bullseye ... RUN pecl install xdebug ... 次に Xdebug の設定ファイルを作成する. xdebug.client_host には VSCode が動作しているホストのアドレスをセットする. Docker Desktop for Mac では host.docker.internal という名前でコンテナ内からホストを参照することができる. なお xdebug.client_port にはホストの IP アドレスを指定するが、この値は後述する VSCode 側でのポートの設定と一致させる必要がある.
docker-php-ext-debug.ini zend_extension=xdebug xdebug.mode=debug xdebug.start_with_request=yes xdebug.client_host=host.docker.internal ;xdebug.discover_client_host=1 xdebug.client_port=9003 作成した Xdebug の設定ファイルをコンテナ内にマウントするように docker-compose.yml を作成する.
docker-compose.yml services: my-service: ... volumes: - type: bind source: ./docker-php-ext-xdebug.ini target: /usr/local/etc/php/conf.</description>
    </item>
    
    <item>
      <title>名前付きパイプを用いたプロセス間通信</title>
      <link>https://annpin.com/posts/2022-11-02-20221102-154913/</link>
      <pubDate>Wed, 02 Nov 2022 15:49:13 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-02-20221102-154913/</guid>
      <description>ブラウザからリクエストがあった際にサーバーが巨大なデータを処理 (大量のデータの圧縮など) する必要がある場合、 ナイーブな実装では サーバー上ですべての処理が終わってからダウンロードが開始される という振る舞いになってしまい、 ダウンロード開始待ちの時間が長すぎてしまう可能性がある.
そのような場合に プロセス間通信 (IPC) を活用することで、ファイルに書き出すことなくプロセスが処理した結果を逐次ブラウザにダウンロードさせることができるかもしれない.
名前付きパイプの活用 名前付きパイプ (named pipe) を活用することで、ファイルに書き出すことなくプロセス間でデータを直接やり取りすることができる.
通常のパイプとは異なり、名前付きパイプはファイルシステムを利用する. mkfifo コマンドで名前付きパイプを作成することができる.
$ mkfifo mypipe $ ls -l total 0 prw-r--r-- 1 annpin staff 0 Nov 2 16:14 mypipe ^ \ &amp;#34;p&amp;#34; という見慣れないフラグがセットされる. 作成された名前付きパイプ mypipe に対し、2 つのプロセス (読み込み用プロセス、書き込み用プロセス) がアクセスすることができる.
名前付きパイプの動作 例えばシェルを 2 つ開き、それぞれを同じディレクトリへと cd したとする. 最初に左側 (読み込み用) のシェルで cat mypipe してみると、通常の cat とは異なりいつまで待ってもシェルの制御が戻ってこないということが確認できる. これは名前付きパイプに何らかのデータが流し込まれてくるのを待ち受けしている状態である. 次に右側 (書き込み用) のシェルで echo &amp;#34;Hello, named pipe!&amp;#34; &amp;gt; mypipe を実行してみるとこのコマンドはすぐに終了し、その直後に左側の読み込み用シェルの cat が結果 Hello, named pipe!</description>
    </item>
    
    <item>
      <title>Docker でのファイルマウントについて試してみる (volume / bind mount / tmpfs mount)</title>
      <link>https://annpin.com/posts/2022-11-02-20221102-120338/</link>
      <pubDate>Wed, 02 Nov 2022 12:03:38 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-02-20221102-120338/</guid>
      <description>Docker を使う時のデータ永続化の方法としていくつか方法があるらしいのでそれぞれ試してみる.
Docker でのデータ永続化 公式ドキュメントを確認してみると、Docker ではデータ永続化の手段として以下の 2 つのファイルシステムのマウント方法を提供しているらしい. (https://docs.docker.com/storage/)
ボリューム (volumes)
バインド・マウント (bind mounts)
(加えて、永続化しない in-memory ストレージとして tmpfs mount というマウントの設定も存在する.)
この中のどのマウント方式を選んだ場合であっても、コンテナの内部からはどれも全く同様のファイルとして見えるようだ.
各マウント方式の特徴は以下の通り.
Volumes
Docker 中においてデータを永続化するための最善の方法として推奨されている.
ホストのファイルシステムの中で、Docker によって管理される一部分 (Linux では /var/lib/docker/volumes/) にデータが保存される.
Docker 以外のプロセスはファイル・システム中のこの部分を書き換えることはできない.
Bind mounts
ホストシステム中のあらゆる場所にデータを保存できる.
重要なシステムファイル・ディレクトリも指定できるのでセキュリティ上の問題が生じる可能性もある.
Docker のホスト上で動いている Docker 以外のプロセスや Docker コンテナはいつでもこれらのファイルを書き換えることができる.
tmpfs mounts
ホストのメモリ上にのみデータを保存できる. ホストのファイルシステムには書き込まれない.
docker-compose でのマウント設定の書き方 docker-compose.yml を使う場合、これらのマウント設定は各サービスの中の volumes に記述する. volumes の書き方は一行で書く書式と複数行で書く書式があり、特に一行で書く場合は Volumes を使うのか Bind mounts を使うのかの区別がつきにくい. (https://amateur-engineer-blog.com/docer-compose-volumes/)
まず、 Volumes を使う場合の一行での書き方は以下の通り.
services: service_name: volumes: # パス指定だけを行う場合. (無名ボリューム) Engine に自動的にボリュームを作成させる.</description>
    </item>
    
    <item>
      <title>VSCode でデバッガを動かしてみる</title>
      <link>https://annpin.com/posts/2022-11-02-20221102-003005/</link>
      <pubDate>Wed, 02 Nov 2022 00:30:05 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-02-20221102-003005/</guid>
      <description>いまさらながら VSCode 上でデバッガを使った開発をできるようにしてみる.
VSCode からブラウザ上で動く JavaScript プロジェクトのデバッグ まず、簡単な HTML ファイルと JavaScript ファイルを用意する.
index.html &amp;lt;!DOCTYPE html&amp;gt; &amp;lt;html&amp;gt; &amp;lt;head&amp;gt; &amp;lt;meta charset=&amp;#34;utf-8&amp;#34; /&amp;gt; &amp;lt;meta name=&amp;#34;viewport&amp;#34; content=&amp;#34;width=device-width&amp;#34; /&amp;gt; &amp;lt;script defer src=&amp;#34;main.js&amp;#34;&amp;gt;&amp;lt;/script&amp;gt; &amp;lt;/head&amp;gt; &amp;lt;body&amp;gt; &amp;lt;div&amp;gt; &amp;lt;div class=&amp;#34;form&amp;#34;&amp;gt; &amp;lt;input type=&amp;#34;number&amp;#34; value=&amp;#34;1&amp;#34; id=&amp;#34;num1&amp;#34; /&amp;gt; + &amp;lt;input type=&amp;#34;number&amp;#34; value=&amp;#34;2&amp;#34; id=&amp;#34;num2&amp;#34; /&amp;gt; = &amp;lt;span id=&amp;#34;result&amp;#34;&amp;gt;&amp;lt;/span&amp;gt; &amp;lt;/div&amp;gt; &amp;lt;div class=&amp;#34;action&amp;#34;&amp;gt; &amp;lt;button id=&amp;#34;buttonExecute&amp;#34;&amp;gt;計算&amp;lt;/button&amp;gt; &amp;lt;/div&amp;gt; &amp;lt;/div&amp;gt; &amp;lt;/body&amp;gt; &amp;lt;/html&amp;gt; main.js const elementButton = document.querySelector(&amp;#34;#buttonExecute&amp;#34;); elementButton.addEventListener(&amp;#34;click&amp;#34;, update); function update() { // 要素を参照 const elementNum1 = document.</description>
    </item>
    
    <item>
      <title>PHP アプリケーションを VSCode でデバッグする</title>
      <link>https://annpin.com/posts/2022-11-02-20221102-000223/</link>
      <pubDate>Wed, 02 Nov 2022 00:02:23 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-02-20221102-000223/</guid>
      <description>PHP アプリケーションを VSCode でブレークポイントを入れて開発できるように設定する.
PHP の開発環境を整える PHP アプリケーションの開発環境構築については M1 mac 環境に phpenv + php 7.4.30 + composer をインストールする 参照.
VSCode でデバッグできるようにする 次に PHP プロジェクトを VSCode でデバッグできるようにする. ここでは PHP プロジェクトを php -S &amp;#34;0.0.0.0:8888&amp;#34; で起動しているものとする.
まず最初に VSCode を起動し、 File → Open Folder…​ から PHP プロジェクトのフォルダを開く. (プロジェクトのルートディレクトリが VSCode 上できちんとルートディレクトリとして開かれるようにすべきだろう.)
次に、PHP スクリプトをデバッグするため Xdebug の VSCode 拡張をインストールする. VSCode 上で Extentions を開き、 PHP Debug (https://marketplace.visualstudio.com/items?itemName=xdebug.php-debug) という拡張機能をインストールする.
拡張機能がインストールできたら、デバッグのための構成情報 .vscode/launch.json を生成する. 手順は以下の通り.
Run and Debug を開き、左側ペイン上の create a launch.</description>
    </item>
    
    <item>
      <title>M1 mac 環境に phpenv &#43; php 7.4.30 &#43; composer をインストールする</title>
      <link>https://annpin.com/posts/2022-11-01-20221101-210149/</link>
      <pubDate>Tue, 01 Nov 2022 21:01:49 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-11-01-20221101-210149/</guid>
      <description>他の *env 系と比べてだいぶインストール作業が難航したのでメモ. (環境は macOS 12.3 の M1 mac)
phpenv 自体のインストール phpenv 自体のインストールはそれほど複雑ではない. 概ね、他の env 系のツールと似たような操作でインストールできる.
# git clone することで ~/.phpenv にインストール. $ git clone git@github.com:phpenv/phpenv.git ~/.phpenv 続いて、 ~/.zshrc を編集して phpenv のパスを通した上で初期化スクリプトを実行するようにする.
# phpenv $ export PATH=&amp;#34;$HOME/.phpenv/bin:$PATH&amp;#34; $ eval &amp;#34;$(phpenv init -)&amp;#34; シェルに設定を再読み込みする.
$ exec $SHELL -l このままだと phpenv コマンド自体は使えるが phpenv install が使えないため、 php-build をプラグインとして phpenv にインストールする必要がある.
$ git clone https://github.com/php-build/php-build $(phpenv root)/plugins/php-build これで phpenv が動くようになった.
$ phpenv --version phpenv v0.</description>
    </item>
    
    <item>
      <title>Docker for Mac でのディスクスペースの管理について</title>
      <link>https://annpin.com/posts/2022-10-30-20221030-200407/</link>
      <pubDate>Sun, 30 Oct 2022 20:04:07 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-10-30-20221030-200407/</guid>
      <description>ディスクスペースの解放方法について.
不要なコンテナ・イメージの削除 docker version が 1.25 以降ならば、以下のコマンドが使用できるはず.
# システムで使用している容量を表示 $ docker system df -v # イメージ一覧表示 $ docker image ls # コンテナ一覧表示 $ docker container ls -a # 不要なものの削除 $ docker system prune データの実体について データの実体は以下の位置の Docker.raw というファイルに格納されている.
$ cd /Users/annpin/Library/Containers/com.docker.docker/Data/vms/0/data $ ls -klsh Docker.raw 18117708 -rw-r--r-- 1 annpin staff 200G Oct 31 00:47 Docker.raw References https://docs.docker.jp/docker-for-mac/space.html#id8
https://matsuand.github.io/docs.docker.jp.onthefly/desktop/mac/space/</description>
    </item>
    
    <item>
      <title>Git でコミット間の diff を確認する</title>
      <link>https://annpin.com/posts/2022-10-28-20221028-171327/</link>
      <pubDate>Fri, 28 Oct 2022 17:13:27 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-10-28-20221028-171327/</guid>
      <description>コミット間の diff を出力する $ git diff &amp;lt;commit_id_1&amp;gt; &amp;lt;commit_id_2&amp;gt; なお、現在のブランチの状態と過去のコミットを比較したいときには以下のように記述する.
$ git diff &amp;lt;commit_id&amp;gt; コミット間で変更されたファイル名一覧を出力する $ git diff --name-only &amp;lt;commit_id_1&amp;gt; &amp;lt;commit_id_2&amp;gt; 特定のファイルについてのコミット間の diff を出力する # まず、変更されたファイル一覧を出力して確認. $ git diff --name-only &amp;lt;commit_id_1&amp;gt; &amp;lt;commit_id_2&amp;gt; # 続いて、特定のファイルの diff を確認. $ git diff &amp;lt;commit_id_1&amp;gt; &amp;lt;commit_id_2&amp;gt; &amp;lt;file_name&amp;gt; References https://qiita.com/kasyuu/items/bc8489831e200b641456</description>
    </item>
    
    <item>
      <title>macOS での 「アプリケーション &#34;xxx&#34; は開けません」 というエラーへの対処</title>
      <link>https://annpin.com/posts/2022-10-01-20221001-220959/</link>
      <pubDate>Sat, 01 Oct 2022 22:09:59 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-10-01-20221001-220959/</guid>
      <description>対処法 まず、「システム環境設定」を開き、「セキュリティとプライバシー」を開く. その中の「一般」タブの中の「ダウンロードしたアプリケーションの実行許可」の中に「すべてのアプリケーションを許可」というチェックボックスがあるかを確認する.
これがなかった場合、まずはすべてのアプリケーションに対する実行許可を与えられるようにする必要がある. ターミナルで以下のコマンドを実行し、再度「システム環境設定」を開き直すこと.
$ sudo spctl --master-disable 「すべてのアプリケーションを許可」というチェックボックスが表示されるようになった後は、このチェックボックスにチェックを入れてからターミナルで以下のコマンドを実行してアプリケーションに実行権限を与えれば実行できるようになるはず.
$ chmod -R 755 /path/to/your/application/xxx.app アプリケーションを開くことができるようになったら、 再度ターミナルで以下のコマンドを実行すると良いだろう.
$ sudo spctl --master-enable 参考 https://www.youtube.com/watch?v=E52Z7zAwCOg</description>
    </item>
    
    <item>
      <title>使用中のポート番号一覧を調べる</title>
      <link>https://annpin.com/posts/2022-09-22-20220922-012830/</link>
      <pubDate>Thu, 22 Sep 2022 01:28:30 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-09-22-20220922-012830/</guid>
      <description>現在使用中のポート番号を調べたい場合のメモ
Windows &amp;gt; netstat macOS # -P: ポート番号をポート名に変換しない $ sudo lsof -P | grep &amp;#34;LISTEN&amp;#34; # -i: ポート番号を指定する $ sudo lsof -P -i:80 | grep &amp;#34;LISTEN&amp;#34; Linux # -n, --numeric : 出力を数値のみに。DNS逆引きを行わない # -p, --program: プロセスIDとプログラムを表示 # -l, --listening: listen状態のみ表示 # -t, --tcp: TCPのみ # -u, --udp: UDPのみ $ sudo netstat -npltu References https://solution.fielding.co.jp/column/it/itcol04/202105_01/
https://uuutee.net/shell/show-using-port/</description>
    </item>
    
    <item>
      <title>Vim で置換を行う際に置換後に改行を入れたい場合</title>
      <link>https://annpin.com/posts/2022-09-17-20220917-134636/</link>
      <pubDate>Sat, 17 Sep 2022 13:46:36 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-09-17-20220917-134636/</guid>
      <description>Vim では任意の範囲で文字列の置換が行える. 例えば、様々な範囲で hoge という文字列を fuga に置換したい場合には以下のようにコマンドを入力するとよい.
文書内全体
:%s/hoge/fuga/g
(VISUAL モードにおける) 選択範囲
:&amp;#39;&amp;lt;,&amp;#39;&amp;gt;s/hoge/fuga/g
行指定 (9 行目から 10 行目の範囲 など)
:9,10s/hoge/fuga/g
このとき、置換元の文字列として改行文字を指定したい場合には通常のプログラミング言語と同様に \n という記法を用いればよいが、置換先の文字列として改行文字を指定したい場合にはこのように \n と入力してもうまく改行を行ってくれないようになっている.
置換先の文字列中に改行文字を含めたい場合には、 Ctrl-v + Enter と入力するようにすると良い.
例えば、 hoge を fuga\n に置換したい場合には f + u + g + a + Ctrl-v + Enter と入力する. Vim 上ではこの置換コマンドは :%s/hoge/fuga^M/g のように表示されることとなる.</description>
    </item>
    
    <item>
      <title>git stash について</title>
      <link>https://annpin.com/posts/2022-08-24-20220824-105739/</link>
      <pubDate>Wed, 24 Aug 2022 10:57:39 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-08-24-20220824-105739/</guid>
      <description>git stash を使用することで、まだコミットしたくない一時的な変更を git の中で退避しておくことができる.
作業を一時的に退避する # コメント付き $ git stash save &amp;#34;コメントメッセージ&amp;#34; # コメント無し $ git stash これによって最新コミットの後に行われたワーキングツリーに対する変更が stash として退避され、 ワーキングツリーの状態が最新コミットの状態に戻ることとなる.
なお、 git stash は基本的に git add していない untracked なファイルに対しては退避されないようになっている. しかし、 -u あるいは --include-untracked オプションを付与することで untracked なファイルも一緒に退避させることができる.
# untrack ファイルも含めて退避する $ git stash -u 一時的に退避した変更のリストを表示する $ git stash list 一時的に退避した変更をワーキングツリーに再度反映する # ワーキングツリーに反映し、stash 自体はそのまま保持しておく $ git stash apply stash@{0} # ワーキングツリーに反映し、元の stash は削除する. $ git stash pop stash@{0} なお、一度 stash として退避したファイル群の中で、 特定のファイルだけを取り出してワーキングツリーに反映したい 場合には以下のように git checkout を使用する.</description>
    </item>
    
    <item>
      <title>SSH での公開鍵認証</title>
      <link>https://annpin.com/posts/2022-08-20-20220820-072923/</link>
      <pubDate>Sat, 20 Aug 2022 07:29:23 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-08-20-20220820-072923/</guid>
      <description>SSH での公開鍵認証のメモ (後で書き直す）
# client side config $ cd ~/.ssh $ ssh-keygen -t ed25519 -f KEY_NAME $ pbcopy &amp;lt; KEY_NAME.pub $ ssh TARGET # server side config $ vim authorized_keys # Paste the public key. $ chmod 600 authorized_keys $ exit # client side config $ vim ~/.ssh/config # Add IdentityFile field and specify the corresponding secret key. ~/.ssh/config の例は以下のようになる.
Host bitbucket.org User git Port 22 HostName bitbucket.org IdentityFile ~/.</description>
    </item>
    
    <item>
      <title>git rebase について</title>
      <link>https://annpin.com/posts/2022-07-25-20220725-175759/</link>
      <pubDate>Mon, 25 Jul 2022 17:57:00 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-07-25-20220725-175759/</guid>
      <description>git rebase にはいくつかの使用パターンがある.
作成してから分岐元のブランチのコミットが進みすぎて古くなってしまったブランチを再度最新のコミットを基準にして生やし直す場合 以前 master ブランチから派生したブランチ dev があったときに、その後 master ブランチへのコミットが増えて master の最新コミットと dev の最新コミットとの間の差が 大きくなってしまった場合には git rebase を行うことで dev ブランチを master ブランチの最新コミットから再び分岐させ直して作ることができる.
$ git checkout dev $ git rebase master # コンフリクトした場合、コンフリクトを解消してから $ git commit # コンフリクト解消後、rebase を続行 $ git rebase --continue * -&amp;gt; * -&amp;gt; * [master] * -&amp;gt; * -&amp;gt; * [master] \ ===&amp;gt; \ * -&amp;gt; * [dev] * -&amp;gt; * [dev] Git でコミットしたあとにコミットメッセージを変えたくなった場合 直前のコミットのコミットメッセージを変更したいだけならば git commit --amend で対応できるが、2 つ以上前のコミットのコミットメッセージを変更したい場合には git rebase が必要となる.</description>
    </item>
    
    <item>
      <title>Hello howm!</title>
      <link>https://annpin.com/posts/2022-06-01-20220601-151851/</link>
      <pubDate>Wed, 01 Jun 2022 15:18:00 +0900</pubDate>
      
      <guid>https://annpin.com/posts/2022-06-01-20220601-151851/</guid>
      <description>howm: 一人お手軽 Wiki もどき を使ってみる.</description>
    </item>
    
    <item>
      <title>VSCode で編集すれば仮想マシン中で動作する Web サーバでも Live Reload できるよという話</title>
      <link>https://annpin.com/posts/20/12/09/vscode-vm-live-reload/</link>
      <pubDate>Wed, 09 Dec 2020 04:00:55 +0900</pubDate>
      
      <guid>https://annpin.com/posts/20/12/09/vscode-vm-live-reload/</guid>
      <description>Vagrant を使うと VirtualBox で VM を立ち上げてホスト OS との間で共有フォルダの設定をするのも簡単でいいですよね. ただ、ホストから共有フォルダ中のファイルを編集しても、VM 中で動いている Web サーバ (webpack-dev-server など) はファイルの更新を認識してくれなくて Live Reload できないのは難点だったりします.
でも、VSCode を使っているなら実は割と簡単に VSCode 上での編集を Live Reload で反映できます.
VSCode を開き、Extensions から Remote Development という拡張をインストールしてください. この拡張は VSCode から SSH でサーバに接続し、そのサーバ上のファイルを VSCode 上で編集できるようにしてくれるという拡張です. この拡張がインストールされると、VSCode のウィンドウの一番左下 (歯車マークの Manage の下) に ≶ というアイコンが表示されるようになります.
あとは、VSCode から VM に対して SSH で接続するための鍵情報が用意できれば OK です. Vagrant を使っている場合、シェル上で以下のようにして鍵情報を用意することができます.
$ vagrant ssh-config --host &amp;#34;Vagrant の VM 名&amp;#34; &amp;gt;&amp;gt; ~/.ssh/config これにより、以下のような内容の SSH の鍵情報が ~/.ssh/config へと追記されることになります.</description>
    </item>
    
    <item>
      <title>Linux カーネル v2.6.39 と v4.18-rc5 のコードをチョット比べてみる</title>
      <link>https://annpin.com/posts/18/07/17/linux-kernel-code-reading/</link>
      <pubDate>Tue, 17 Jul 2018 19:12:33 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/07/17/linux-kernel-code-reading/</guid>
      <description>2.6 系の Linux カーネルのコードを解説してくれている本を読んでみたら、 最新の Linux カーネルの実装がどの程度変化しているのかちょっと調べてみたくなってしまった.
なので今回は int $0x80 や sysenter が呼ばれた際のシステムコールハンドラの動きをちょっとだけ比べてみた.
ちょっと見比べてみたときのメモの単なる垂れ流し. オチなし.
x86/x64 でのシステムコール呼び出し - int $0x80 と sysenter って何が違うのよ x86 の Linux では古くは int $0x80 / iret によるソフトウェア割り込みでシステムコール呼び出しを行っていたらしいが、呼び出しのオーバーヘッドが大きいことから近年の実装では x86 では sysenter/sysexit、x64 では syscall/sysret が使われているらしい.
sysenter や syscall は近年の x86 や x64 CPU で追加された命令らしい. こっちのほうが int $0x80 よりも高速に動くから、こっちを使うことにしましたって感じですかね.
v2.6.39 Linux カーネル 2.6.39 では arch/x86/kernel/entry_32.S#498 および arch/x86/kernel/entry_64.S#455 にて ENTRY(system_call) によって system_call というラベルが定義されている.
arch/x86/kernel/entry_32.S#498 arch/x86/kernel/entry_64.S#455 加えて、arch/x86/kernel/traps.c#871 には system_call ラベルを割り込みハンドラに登録しているようなので、system_call ラベルがシステムコール実行の窓口になっている模様.</description>
    </item>
    
    <item>
      <title>バイナリ解析についてのメモ</title>
      <link>https://annpin.com/posts/18/07/16/binary-analysis-memo/</link>
      <pubDate>Mon, 16 Jul 2018 12:30:10 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/07/16/binary-analysis-memo/</guid>
      <description>バイナリ解析ツールの使い方とか雑多なことについての個人的なメモ.
不定期更新.
ツールについて objdump 実行ファイルの逆アセンブルができる汎用ツール. コンパイル後に各関数がどんな機械語に落ちているのかを調べるのに便利.
# アセンブリのみの出力を得る. $ objdump -d binary_file # 元の C 言語ソース付きの出力を得る. $ objdump -S binary_file # デフォルトの AT&amp;amp;T シンタックスではなく、(nasm などの) Intel シンタックスを使用して表示する. $ objdump -d -M intel binary_file # 大体出力結果が多すぎるので、head で先頭だけ取り出したりする. $ objdump -d binary_file | head # でも出力結果を細かく調べたいときには vim が便利. $ objdump -d binary_file | vim - なお、バイナリファイルのフォーマットを objdump が自動判定できない場合には --target オプションを与えることでファイルの読み込みフォーマットを手動で設定することができる. (--target=coff-i386 など.)
readelf readelf コマンドは ELF 形式の実行ファイルの解析ができる. 関数のシンボルテーブル情報が含まれているため、各関数がどのアドレスに割り当てられているのか確認できる. 複数の関数が同じアドレスに割り当てられているかを調べることで関数同士が互いにエイリアスになっているかを調べられる.
# -a は全ての情報を出力する. --all でも同様.</description>
    </item>
    
    <item>
      <title>gdb のコマンドメモ</title>
      <link>https://annpin.com/posts/18/07/16/gdb-commands/</link>
      <pubDate>Mon, 16 Jul 2018 07:47:21 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/07/16/gdb-commands/</guid>
      <description>gdb (GNU Debugger) のコマンド、わりと毎回調べ直してる気がするのでとりあえずまとめとく. シェル内での操作は先頭に $、gdb 内での操作は先頭に (gdb) と付けているが、これらは実際に入力する必要はないので注意. なお、基本的にすべて 32 bit の Linux 環境での実行結果となる.
準備 C プログラムを gdb でデバッグしたい場合、gcc などのコンパイラにデバッグオプションを渡してからそのファイルをコンパイルする. hello.c を gcc でコンパイルするなら、以下のようにして -g フラグを渡してコンパイルする.
$ gcc -o hello hello.c -g -Wall -Wall フラグは警告を可能な限り多く表示するフラグ. とりあえず有効にしておいたほうが無難らしい.
なお、実は -g オプションを付けずにコンパイルした実行ファイルを gdb でデバッグ (ブレークポイント設定やステップ実行) することも可能ではある.
ただし、実行ファイル中には &amp;ldquo;各機械語命令が元となった C 言語ソースファイルのどの部分に対応するのか&amp;rdquo; というシンボル情報が含まれなくなるため、C 言語ソースコードレベルのデバッグはできなくなる.
よってアセンブリコードレベルのデバッグだけが可能である.
このため、C 言語ではなく全てアセンブリで書かれたコードをアセンブル・リンクして得られる実行ファイルも gdb を用いてデバッグすることができる. x64 アーキテクチャの Linux において hello.asm を nasm と ld を用いてアセンブル・リンクして実行ファイルを得るには、以下のコマンドを実行すれば良い.
$ nasm -o hello.o -f elf64 hello.</description>
    </item>
    
    <item>
      <title>C/C&#43;&#43; の const 修飾子の位置で混乱しないために</title>
      <link>https://annpin.com/posts/18/03/27/c-cpp-const/</link>
      <pubDate>Tue, 27 Mar 2018 18:16:17 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/03/27/c-cpp-const/</guid>
      <description>C や C++ の const 修飾子は変数や引数に指定することで &amp;ldquo;値が不変である&amp;rdquo; ということを示す. 極めて単純である.
これは書き方にいくつかのバリエーションが存在するが、ポインタ変数に対して指定する場合には初見だと非常に混乱する記述となる. この記事ではこの const 修飾子を混乱せずに使うための考え方についてまとめる.
変数に対して const 指定する場合 int a = 10; のように宣言された変数を const 指定する場合には、以下のいずれかの書き方がある.
const int a = 10; // 変数 a の値は書き換えできなくなる. int const a = 10; // 同上 このいずれかの記述を行った場合、変数 a は値を書き換えることができなくなる. すなわち、a = 20; のような代入を行おうとするとコンパイルエラーが発生するようになる.
これらは 2 通りの書き方で同じ効果が得られるので &amp;ldquo;どちらの書き方でも良い&amp;rdquo; とよく説明される. つまり、const int と int const はどちらも &amp;ldquo;不変 (constant) な int 型&amp;rdquo; を表すのである.
よって const int a や int const a は &amp;ldquo;不変な int 型の変数 a&amp;rdquo; と読むわけである.</description>
    </item>
    
    <item>
      <title>macOS Sierra で非 LLVM な gcc をビルドし、他のプロセッサ向けのクロスコンパイラ gcc をビルドする</title>
      <link>https://annpin.com/posts/18/03/07/cross-compiler/</link>
      <pubDate>Wed, 07 Mar 2018 10:19:24 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/03/07/cross-compiler/</guid>
      <description>まぁタイトルの通りなのだけれども、macOS で LLVM じゃない普通の gcc をビルドした後で他のプロセッサ向けのクロスコンパイラ gcc をビルドする方法についてメモしておく. 今回は i386 の Linux 向けのクロスコンパイラをビルドすることにする.
まずは作業用のディレクトリを作成する. 今回はホームディレクトリ中に cross というディレクトリを作り、そこで作業することにした.
$ mkdir ~/cross $ cd ~/cross さて、最初からいきなりクロスコンパイラをビルドできるわけではない. macOS 標準の gcc は実体は clang であるが、クロスコンパイラのビルドにはネイティブの gcc が必要となるためまずはホスト環境のためのネイティブ gcc を用意する必要がある.
今回は gcc 7.3.0 を使うことにするので、このネイティブ gcc は N-gcc-7.3.0 というディレクトリに配置することにする.
$ mkdir N-gcc-7.3.0 $ cd N-gcc-7.3.0 はじめに、GNU の公式 から必要となるソフトウェア郡を FTP 経由でダウンロードする必要がある. GNU の FTP は国ごとにたくさんのミラーが存在しているが、今回は JAIST の FTP ミラー を利用することにした. gcc のビルドには以下のソフトウェアのソースが必要である.
GNU Compiler Collection (gcc): tar.gz GNU Multi-Precision Library (gmp): tar.</description>
    </item>
    
    <item>
      <title>macOS Sierra 環境で 自作エミュレータで学ぶ x86 アーキテクチャを読み進めるための環境構築をしたかった</title>
      <link>https://annpin.com/posts/18/03/07/x86-emulator-book-on-macos/</link>
      <pubDate>Wed, 07 Mar 2018 10:19:10 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/03/07/x86-emulator-book-on-macos/</guid>
      <description>ということで 前回の記事 で触れたように、macOS 上で 自作エミュレータで学ぶ x86 アーキテクチャ を読み進めていく際の開発環境を作ろうとした際の奮闘記を置いておく.
この本は x86 の CPU エミュレータを自作することで、普段使っている Intel CPU の基本的な振る舞いについてを学習できる本だ. とても面白い. しかし、この本は基本的に Windows 環境でサンプルを動作させることしか前提としておらず、macOS では動作が保証されていない. エミュレータ自体は C 言語で開発していくため、別に C 言語が使える環境ならばどの OS 上でも動作させることができるだろう. しかし、問題となるのは エミュレータに読み込ませるためのテストプログラムが Windows 以外の環境で用意できるか である. エミュレータを作る立場では、そもそもテストプログラムが意図した機械語列でなければ本に沿って作業を進めていくことができない. したがって、C 言語で書かれたテストプログラムを意図した通りの機械語列に変換させる必要がある. 通常、C 言語のプログラムがどのような機械語に変換されるかはコンパイラ任せであるため、意図したとおりの機械語列を得ようとするならば、全く同一の環境を用意して作業するのが当然望ましい だろう. (同じ OS、同じバージョンのコンパイラ)
はじめに弁明しておくと僕は前回の記事で述べた通り、結局 VM 上の Windows でテストプログラムをコンパイルし、生成されたバイナリを macOS 上に移動させることで本書を読み進めていった. したがって、以下の記事で説明している内容は たぶん参考にならない. というのも、やはり C コンパイラは macOS 環境下で意図した機械語列を吐いてくれなかったためである&amp;hellip;
この本では、例えば最初に以下のようなプログラムをテストプログラムとして使用する.
casm-c-sample.c void func(void) { int val = 0; val++; } 本文 p.18 ではこのプログラムをコンパイルするために gcc -Wl,--entry=func,--oformat=binary -nostdlib -fno- asynchronous-unwind-tables -o casm-c-sample.</description>
    </item>
    
    <item>
      <title>低レイヤーのはじめの一歩</title>
      <link>https://annpin.com/posts/18/03/06/hello-low-layer-programming/</link>
      <pubDate>Tue, 06 Mar 2018 20:18:01 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/03/06/hello-low-layer-programming/</guid>
      <description>今年は年始辺りから低レイヤー周りの勉強を始めている.
はじめは Z80 アセンブリを macOS 上のエミュレータで動作させるところからスタートした. この動画 を参考に、z80pack に 付属している Z80 アセンブラ z80asm とエミュレータ z80sim を使って はじめて読むマシン語 の サンプルプログラムを自分で動かしてみたりしていた. ただ、DB 命令を使うサンプルでは z80asm が DB を疑似命令として認識しないようであったため、 一部 z80asm の代わりに zasm を使った.
z80asm と z80sim は組み合わせて使う分にはとても快適なのだが、生成/実行される機械語プログラムの先頭にどうも 0xFF 0xYY 0xXX というフォーマットの 3 バイトのヘッダを付与することを前提としているようだ. この 3 バイトのうち、0xYY と 0xXX はアセンブリコード中で ORG 0xXXYY と指定したエントリポイントのアドレスがそのまま挿入されるらしく、zasm で生成した機械語プログラムを z80sim で正しく読み込むためにはこの 3 バイトのヘッダ情報を自分で付与してやる必要があった.
いずれにしても、低レイヤー周りの知識を一切持たなかった身としては Z80 アセンブリはとても良い導入であったと思う. Zilog 社が開発した Z80 は非常に古い 8 ビット CPU ではあるが、Intel が発売した 8 ビット CPU である 8080 の完全な上位互換を持っている.</description>
    </item>
    
    <item>
      <title>About</title>
      <link>https://annpin.com/about/</link>
      <pubDate>Tue, 06 Mar 2018 19:05:37 +0900</pubDate>
      
      <guid>https://annpin.com/about/</guid>
      <description>自己紹介 Name: あんぜんぴん (AnnPin) Qiita: https://qiita.com/AnnPin GitHub: https://github.com/AnnPin 読書メーター: https://bookmeter.com/users/886207 一言: なんとか就職しました。 </description>
    </item>
    
    <item>
      <title>ブログを始めてみる (N 回目)</title>
      <link>https://annpin.com/posts/18/03/06/hello/</link>
      <pubDate>Tue, 06 Mar 2018 14:22:04 +0900</pubDate>
      
      <guid>https://annpin.com/posts/18/03/06/hello/</guid>
      <description>ブログを始めてみることにする&amp;hellip; と書くのは何度目だろうか&amp;hellip; ブログっていつも長続きしないで放置するんだよなぁ.
主に書きたくなるような記事はプログラミング技術に関することぐらいしかないから Qiita に上げるだけでいいかと思っていたのだが、 Qiita に上げるべきか悩むような記事をもっと気軽に書けるようにするには自分でブログを持ったほうが楽なのではと考え直した.
まぁ思い出した頃に覚書的にちょっと書く、みたいな使い方になるだろう.
今回は github.io だから、とりあえず git で push すれば即更新できるお手軽仕様. Vim キーバインドが無いエディタで何か書くことは苦痛でしかないので、こういう手軽な環境はとてもありがたい. それから Hugo という golang 製の静的サイトジェネレータがかなり良さそうなので試しに使ってみている. markdown 文書を書くだけで記事を投稿できるのだから快適.
恐らくは自分が勉強したことや調べたことの覚え書き的な記事が書かれることになるはず.
へっぽこですが、どうぞよろしく.</description>
    </item>
    
    <item>
      <title>Search</title>
      <link>https://annpin.com/search/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://annpin.com/search/</guid>
      <description> </description>
    </item>
    
  </channel>
</rss>
