diff options
Diffstat (limited to 'vhosts/blog/public')
46 files changed, 265 insertions, 265 deletions
diff --git a/vhosts/blog/public/posts/2021-03-30/phperkaigi-2021/index.html b/vhosts/blog/public/posts/2021-03-30/phperkaigi-2021/index.html index 14117f8c..8459a549 100644 --- a/vhosts/blog/public/posts/2021-03-30/phperkaigi-2021/index.html +++ b/vhosts/blog/public/posts/2021-03-30/phperkaigi-2021/index.html @@ -69,7 +69,7 @@ <section id="section--report"> <h2><a href="#section--report">PHPerKaigi 2021 参加レポ</a></h2> <p> - 2021-03-26 から 2021-03-28 にかけて開催された、<a href="https://phperkaigi.jp/2021/" rel="noreferrer" target="_blank">PHPerKaigi 2021</a> に一般参加者として参加した。 弊社<a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> (今年1月から勤務) はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。 + 2021-03-26 から 2021-03-28 にかけて開催された、<a href="https://phperkaigi.jp/2021/" rel="noreferrer" target="_blank">PHPerKaigi 2021</a> に一般参加者として参加した。弊社<a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> (今年1月から勤務) はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。 </p> <p> このようなカンファレンスには初めて参加するのでかねてより心待ちにしていたのだが、生憎2日目から体調を崩してしまい、この記事も途中までとなっている。まだ見ていないセッションも多いが、ひとまず現時点での参加レポを書いておく。 @@ -112,7 +112,7 @@ 個人的に楽しみだった発表。 </p> <p> - 期待通りの興味深い発表だった。FUSE 自体も今回の発表で知ったのだが、これ本体の実装を見るのも面白そうだ。 この発表を聞きながらファイルシステムにマウントできそうなものを考えていたのだが、およそ木構造をしているものすべてと言えそうだ (ハンマーしか持っていないと云々)。何かできそうだがなかなか思いつかない。 + 期待通りの興味深い発表だった。FUSE 自体も今回の発表で知ったのだが、これ本体の実装を見るのも面白そうだ。この発表を聞きながらファイルシステムにマウントできそうなものを考えていたのだが、およそ木構造をしているものすべてと言えそうだ (ハンマーしか持っていないと云々)。何かできそうだがなかなか思いつかない。 </p> </section> </section> @@ -121,7 +121,7 @@ <section id="section--report--day-1--1050-a"> <h4><a href="#section--report--day-1--1050-a">10:50 [A] 実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜</a></h4> <p> - User Acceptance Test (UAT) くらいの規模になると個人開発・趣味開発では触れない領域なので、大いに勉強になった。スライドに添付されている資料が相当に充実していたので、これを読むのが本番といった様相すら感じる。 高レベルテストの自動化は現在のプロジェクトでも感じており、自動化のチャンスは伺っている。とはいえセッションでも指摘されているように自動化することにコストがかかりすぎる領域があるのも事実で、そのバランスが難しい。 + User Acceptance Test (UAT) くらいの規模になると個人開発・趣味開発では触れない領域なので、大いに勉強になった。スライドに添付されている資料が相当に充実していたので、これを読むのが本番といった様相すら感じる。高レベルテストの自動化は現在のプロジェクトでも感じており、自動化のチャンスは伺っている。とはいえセッションでも指摘されているように自動化することにコストがかかりすぎる領域があるのも事実で、そのバランスが難しい。 </p> </section> <section id="section--report--day-1--1150-a"> @@ -130,7 +130,7 @@ 型のある世界で生きてきた身として大いに楽しみにしていた発表。 </p> <p> - 昨今、動的型付き言語での型宣言・型アノテーション・型ヒントの導入が相次いでいる。長らく静的型付き言語を書いてきた私からすると、ようやく気づいたかといったところだが、ともかく型を導入する言語が増えてきた。 今のプロジェクトでも新しく追加するコードには型をつけるよう努めているが、どうしても古いコードには型がついていない。個人的には型のないコードに対してどう型を自動的に付けるかという点に興味があり、その点で Ruby の typeprof には注目している。 + 昨今、動的型付き言語での型宣言・型アノテーション・型ヒントの導入が相次いでいる。長らく静的型付き言語を書いてきた私からすると、ようやく気づいたかといったところだが、ともかく型を導入する言語が増えてきた。今のプロジェクトでも新しく追加するコードには型をつけるよう努めているが、どうしても古いコードには型がついていない。個人的には型のないコードに対してどう型を自動的に付けるかという点に興味があり、その点で Ruby の typeprof には注目している。 </p> </section> <section id="section--report--day-1--1310-a"> @@ -191,7 +191,7 @@ 今回、雑談/登壇者への質問等向けに Discord サーバもあったのだが、こちらは参加こそしたものの ROM のままになってしまった。発表に1ウィンドウ、メモを書くのに1ウィンドウ、Discord 表示に 1ウィンドウで私にはもう脳のリソースとディスプレイのスペースが追いつかなかった (さらにいうと Zoom でアンカンファレンスもやっていたようだ。こちらはまったく参加していない)。 </p> <p> - 1つ個人的な反省点としては、一つ一つのセッションを真剣に聞き過ぎたというものがある。もっと適当に聞いておけばよかった。これだけだと大変語弊があるのだが、言い方を変えると、Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。 まあ初カンファレンスだし、とお茶を濁しておこう。 + 1つ個人的な反省点としては、一つ一つのセッションを真剣に聞き過ぎたというものがある。もっと適当に聞いておけばよかった。これだけだと大変語弊があるのだが、言い方を変えると、Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。まあ初カンファレンスだし、とお茶を濁しておこう。 </p> <p> さて、カンファレンスで一つ気になったことがある。それは、Discord という書き込み場所が増えたことでニコ生のコメントの流量が吸い取られてしまったのではないか、という点だ。ニコニコだけ見ていると過疎っているかのように見えた発表も、Discord の方では盛り上がっている、というのを何度か見かけた。ニコニコのコメント方式は盛り上がりを如実に反映するが、逆もまたしかり。Discord があったこと自体はプラスだったと思うが、この点はマイナスだったのではないかと感じる。 diff --git a/vhosts/blog/public/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes/index.html b/vhosts/blog/public/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes/index.html index 93f9d779..ff62c2e9 100644 --- a/vhosts/blog/public/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes/index.html +++ b/vhosts/blog/public/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes/index.html @@ -66,7 +66,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/94090937bcf860cfa93b" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/94090937bcf860cfa93b</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/94090937bcf860cfa93b" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/94090937bcf860cfa93b</a> </p> </div> </div> @@ -128,7 +128,7 @@ </ul> </blockquote> <p> - キーワードでも属性として指定する場合は非キーワードとして使えるらしい。 実際にやってみる。 + キーワードでも属性として指定する場合は非キーワードとして使えるらしい。実際にやってみる。 </p> <p> 同サイトの <a href="https://en.cppreference.com/w/cpp/keyword" rel="noreferrer" target="_blank">keywords のページ</a> から一覧を拝借し、上のコードが出来上がった (C++17 においてキーワードでないものなど、一部省いている)。 大量の警告 (unknown attribute `〇〇’ ignored) がコンパイラから出力されるが、コンパイルできる。 diff --git a/vhosts/blog/public/posts/2021-10-02/python-unbound-local-error/index.html b/vhosts/blog/public/posts/2021-10-02/python-unbound-local-error/index.html index 7cc28941..0e8c595b 100644 --- a/vhosts/blog/public/posts/2021-10-02/python-unbound-local-error/index.html +++ b/vhosts/blog/public/posts/2021-10-02/python-unbound-local-error/index.html @@ -66,7 +66,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/5d733703afcb35bbf399" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/5d733703afcb35bbf399</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/5d733703afcb35bbf399" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/5d733703afcb35bbf399</a> </p> </div> </div> @@ -94,7 +94,7 @@ </p> </blockquote> <p> - local変数 <code>x</code> が代入前に参照された、とある。これは、<code>f</code> の <code>x</code> を参照するのではなく、新しく別の変数を <code>g</code> 内に作ってしまっているため。 前述のコードを宣言と代入を便宜上分けて書き直すと次のようになる。<code>var</code> を変数宣言のための構文として擬似的に利用している。 + local変数 <code>x</code> が代入前に参照された、とある。これは、<code>f</code> の <code>x</code> を参照するのではなく、新しく別の変数を <code>g</code> 内に作ってしまっているため。前述のコードを宣言と代入を便宜上分けて書き直すと次のようになる。<code>var</code> を変数宣言のための構文として擬似的に利用している。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#6A737D"># 注: var は正しい Python の文法ではない。上記参照のこと</span></span> diff --git a/vhosts/blog/public/posts/2021-10-02/ruby-detect-running-implementation/index.html b/vhosts/blog/public/posts/2021-10-02/ruby-detect-running-implementation/index.html index 32d472dc..d8effaf6 100644 --- a/vhosts/blog/public/posts/2021-10-02/ruby-detect-running-implementation/index.html +++ b/vhosts/blog/public/posts/2021-10-02/ruby-detect-running-implementation/index.html @@ -63,7 +63,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791</a> </p> </div> </div> diff --git a/vhosts/blog/public/posts/2021-10-02/ruby-then-keyword-and-case-in/index.html b/vhosts/blog/public/posts/2021-10-02/ruby-then-keyword-and-case-in/index.html index f266c59b..e8da5364 100644 --- a/vhosts/blog/public/posts/2021-10-02/ruby-then-keyword-and-case-in/index.html +++ b/vhosts/blog/public/posts/2021-10-02/ruby-then-keyword-and-case-in/index.html @@ -66,7 +66,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/787a8cf888a304497223" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/787a8cf888a304497223</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/787a8cf888a304497223" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/787a8cf888a304497223</a> </p> </div> </div> @@ -155,7 +155,7 @@ <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">if</span><span style="color:#24292E"> a b </span><span style="color:#D73A49">end</span></span></code></pre> </div> <p> - <code>then</code> も <code>;</code> も改行もないのでエラーになるが、これは条件式がどこまで続いているのかわからないためだ。 この例は二通りに解釈できる。 + <code>then</code> も <code>;</code> も改行もないのでエラーになるが、これは条件式がどこまで続いているのかわからないためだ。この例は二通りに解釈できる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#6A737D"># a という変数かメソッドの評価結果が truthy なら b という変数かメソッドを評価</span></span> diff --git a/vhosts/blog/public/posts/2021-10-02/rust-where-are-primitive-types-from/index.html b/vhosts/blog/public/posts/2021-10-02/rust-where-are-primitive-types-from/index.html index 26ab8bda..a480b6a4 100644 --- a/vhosts/blog/public/posts/2021-10-02/rust-where-are-primitive-types-from/index.html +++ b/vhosts/blog/public/posts/2021-10-02/rust-where-are-primitive-types-from/index.html @@ -63,7 +63,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/9a429432258bbcd6c565" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/9a429432258bbcd6c565</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/9a429432258bbcd6c565" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/9a429432258bbcd6c565</a> </p> </div> </div> @@ -116,7 +116,7 @@ 大雑把な構造としては、<code>compiler</code> フォルダ以下に <code>rustc_*</code> という名前のクレートが数十個入っている。これがどうやら <code>rustc</code> コマンドの実装部のようだ。 </p> <p> - <code>rustc</code> はセルフホストされている (= <code>rustc</code> 自身が Rust で書かれている) ので、<code>bool</code> や <code>char</code> などで適当に検索をかけてもノイズが多すぎて話にならない。 しかし、お誂え向きなことに <code>i128</code>/<code>u128</code> というコンパイラ自身が使うことがなさそうな型が存在するのでこれを使って <code>git grep</code> してみる。 + <code>rustc</code> はセルフホストされている (= <code>rustc</code> 自身が Rust で書かれている) ので、<code>bool</code> や <code>char</code> などで適当に検索をかけてもノイズが多すぎて話にならない。しかし、お誂え向きなことに <code>i128</code>/<code>u128</code> というコンパイラ自身が使うことがなさそうな型が存在するのでこれを使って <code>git grep</code> してみる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ git grep "\bi128\b" | wc # i128</span></span> @@ -212,7 +212,7 @@ <span class="line"><span style="color:#24292E">}</span></span></code></pre> </div> <p> - 関数名や doc comment が示している通り、この関数は識別子 (identifier, ident) を現在のレキシカルスコープ内で解決 (resolve) する。 <code>if ns == TypeNS</code> のブロック内では、<code>primitive_type_table</code> (上記の <code>PrimitiveTypeTable::new()</code> で作られた変数) に含まれている識別子 (<code>bool</code>、<code>i32</code> など) かどうか判定し、そうであればそれに紐づけられたプリミティブ型を返している。 + 関数名や doc comment が示している通り、この関数は識別子 (identifier, ident) を現在のレキシカルスコープ内で解決 (resolve) する。<code>if ns == TypeNS</code> のブロック内では、<code>primitive_type_table</code> (上記の <code>PrimitiveTypeTable::new()</code> で作られた変数) に含まれている識別子 (<code>bool</code>、<code>i32</code> など) かどうか判定し、そうであればそれに紐づけられたプリミティブ型を返している。 </p> <p> なお、<code>ns</code> は「名前空間」を示す変数である。Rust における名前空間はC言語におけるそれとほとんど同じで、今探している名前が関数名/変数名なのか型なのかマクロなのかを区別している。この <code>if</code> は、プリミティブ型に解決されるのは型を探しているときだけだ、と言っている。 diff --git a/vhosts/blog/public/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre/index.html b/vhosts/blog/public/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre/index.html index c3d61b1b..b35db7fb 100644 --- a/vhosts/blog/public/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre/index.html +++ b/vhosts/blog/public/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre/index.html @@ -63,7 +63,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/79ab4db8564032de0b25" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/79ab4db8564032de0b25</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/79ab4db8564032de0b25" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/79ab4db8564032de0b25</a> </p> </div> </div> diff --git a/vhosts/blog/public/posts/2021-10-02/vim-swap-order-of-selected-lines/index.html b/vhosts/blog/public/posts/2021-10-02/vim-swap-order-of-selected-lines/index.html index 5f9a5784..ffbc2abc 100644 --- a/vhosts/blog/public/posts/2021-10-02/vim-swap-order-of-selected-lines/index.html +++ b/vhosts/blog/public/posts/2021-10-02/vim-swap-order-of-selected-lines/index.html @@ -63,7 +63,7 @@ </div> <div class="admonition-content"> <p> - この記事は Qiita から移植してきたものです。 元 URL: <a href="https://qiita.com/nsfisis/items/4fefb361d9a693803520" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/4fefb361d9a693803520</a> + この記事は Qiita から移植してきたものです。元 URL: <a href="https://qiita.com/nsfisis/items/4fefb361d9a693803520" rel="noreferrer" target="_blank">https://qiita.com/nsfisis/items/4fefb361d9a693803520</a> </p> </div> </div> diff --git a/vhosts/blog/public/posts/2022-04-09/phperkaigi-2022-tokens/index.html b/vhosts/blog/public/posts/2022-04-09/phperkaigi-2022-tokens/index.html index 581e229f..46ccdb89 100644 --- a/vhosts/blog/public/posts/2022-04-09/phperkaigi-2022-tokens/index.html +++ b/vhosts/blog/public/posts/2022-04-09/phperkaigi-2022-tokens/index.html @@ -263,7 +263,7 @@ <section id="section--q1-brainfuck--commentary--numbers"> <h4><a href="#section--q1-brainfuck--commentary--numbers">リテラルなしで数値を生成する</a></h4> <p> - ソースコード中に、ほとんど数値リテラルが書かれていないことにお気づきだろうか。 PHP では、型変換を利用することで任意の整数を作り出すことができる。 + ソースコード中に、ほとんど数値リテラルが書かれていないことにお気づきだろうか。PHP では、型変換を利用することで任意の整数を作り出すことができる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#005CC5">assert</span><span style="color:#24292E">(</span><span style="color:#005CC5">0</span><span style="color:#D73A49"> ===</span><span style="color:#D73A49"> +!!</span><span style="color:#24292E">[]);</span></span> @@ -282,7 +282,7 @@ <section id="section--q1-brainfuck--commentary--conditionals"> <h4><a href="#section--q1-brainfuck--commentary--conditionals"><code>if</code> 文なしで条件分岐</a></h4> <p> - 三項演算子ないし <code>match</code> 式を使うことで、<code>if</code> を一切書かずに条件分岐ができる。 また、<code>&&</code> / <code>||</code> も使えることがある。 遅延評価が不要なケースでは、<code>[$t, $f][$cond]</code> のような形で分岐することもできる。 + 三項演算子ないし <code>match</code> 式を使うことで、<code>if</code> を一切書かずに条件分岐ができる。 また、<code>&&</code> / <code>||</code> も使えることがある。遅延評価が不要なケースでは、<code>[$t, $f][$cond]</code> のような形で分岐することもできる。 </p> </section> <section id="section--q1-brainfuck--commentary--loops"> @@ -344,7 +344,7 @@ <span class="line"><span style="color:#24292E">}</span></span></code></pre> </div> <p> - さて、この問題はさきほどのように単純に実行しただけでは、謎のブロックが表示されるだけでトークンは得られない。 トークンを得るためには、ソースコードを読み、定数 <code>N</code> を特定する必要がある。 + さて、この問題はさきほどのように単純に実行しただけでは、謎のブロックが表示されるだけでトークンは得られない。トークンを得るためには、ソースコードを読み、定数 <code>N</code> を特定する必要がある。 </p> <p> ここでは、私の想定解を解説する。 @@ -407,7 +407,7 @@ </li> </ul> <p> - ここで、PHPer トークンは必ず <code>#</code> 記号から始まることを思いだすと、 <code>$token</code> の最初の数字 <code>0x14B499C</code> は、変換の結果 <code>#</code> になるのではないかと予想される (なお、このことは、リポジトリの README ファイルに追加ヒントとして書かれている)。 + ここで、PHPer トークンは必ず <code>#</code> 記号から始まることを思いだすと、<code>$token</code> の最初の数字 <code>0x14B499C</code> は、変換の結果 <code>#</code> になるのではないかと予想される (なお、このことは、リポジトリの README ファイルに追加ヒントとして書かれている)。 </p> </section> <section id="section--q2-riddle--solve"> @@ -521,10 +521,10 @@ <section id="section--q3-toquine--commentary--quine"> <h4><a href="#section--q3-toquine--commentary--quine">プログラム全体</a></h4> <p> - コメントにもあるとおり、これは quine (風) のプログラムになっている。 Quine とは、自分のソースコードをそっくりそのまま出力するようなプログラムのことである。 + コメントにもあるとおり、これは quine (風) のプログラムになっている。Quine とは、自分のソースコードをそっくりそのまま出力するようなプログラムのことである。 </p> <p> - このプログラムは、実行すると自身とほとんど同じプログラムを出力する。 異なるのはトークンになっている部分のみである。 + このプログラムは、実行すると自身とほとんど同じプログラムを出力する。異なるのはトークンになっている部分のみである。 </p> </section> <section id="section--q3-toquine--commentary--tokens"> @@ -536,13 +536,13 @@ <section id="section--q3-toquine--commentary--states"> <h4><a href="#section--q3-toquine--commentary--states">状態保持</a></h4> <p> - トークンの何文字目まで出力したかを、ソースコードを変えずに (quine なので) 覚えておく必要がある。 このプログラムでは、トークンが出力されるとソースコードがだんだんと長くなっていくのを利用して、<code>__LINE__</code> から情報を取得している。 + トークンの何文字目まで出力したかを、ソースコードを変えずに (quine なので) 覚えておく必要がある。このプログラムでは、トークンが出力されるとソースコードがだんだんと長くなっていくのを利用して、<code>__LINE__</code> から情報を取得している。 </p> </section> <section id="section--q3-toquine--commentary--rot-13"> <h4><a href="#section--q3-toquine--commentary--rot-13">ROT 13</a></h4> <p> - Quine は、素朴に書くとプログラムの一部が 2回記述されてしまう。 これがあまり美しくないので、<code>toquine.php</code> では、ROT 13 変換を使って難読化した。 + Quine は、素朴に書くとプログラムの一部が 2回記述されてしまう。これがあまり美しくないので、<code>toquine.php</code> では、ROT 13 変換を使って難読化した。 </p> <p> それにしてもなぜこんなものが標準ライブラリに……。 @@ -556,7 +556,7 @@ 解いていただいたみなさん、また、難易度調整につきあっていただいた社内のみなさん、ありがとうございました。 </p> <p> - 今回は直前に作りはじめたのもあり、3問だけかつ使い古されたネタばかりになってしまいましたが、 来年は 5問、より面白い問題を持っていきます。 + 今回は直前に作りはじめたのもあり、3問だけかつ使い古されたネタばかりになってしまいましたが、来年は 5問、より面白い問題を持っていきます。 </p> <p> 実はもう作りはじめているので、どうか来年もありますように……。 diff --git a/vhosts/blog/public/posts/2022-04-24/term-banner-write-tool-showing-banner-in-terminal/index.html b/vhosts/blog/public/posts/2022-04-24/term-banner-write-tool-showing-banner-in-terminal/index.html index 5f0cee0a..87bf72ba 100644 --- a/vhosts/blog/public/posts/2022-04-24/term-banner-write-tool-showing-banner-in-terminal/index.html +++ b/vhosts/blog/public/posts/2022-04-24/term-banner-write-tool-showing-banner-in-terminal/index.html @@ -79,16 +79,16 @@ 以前、<a href="https://github.com/nsfisis/big-clock-mode" rel="noreferrer" target="_blank"><code>big-clock-mode</code></a> という似たようなプログラムを書いた。 これは tmux の <code>:clock-mode</code> コマンドに着想を得たもので、<code>:clock-mode</code> よりも大きく現在時刻を表示する。 </p> <p> - <code>big-clock-mode</code> を開発したのは、次のようなシチュエーションで使うためである。 弊社では現在リモートワークが基本だが、web 会議などで画面共有しているときに、休憩を挟んで特定の時刻から再開する、ということがある。 こういったケースで、画面上に現在の時刻を大きめに表示しておくと、モニタから離れても遠くから時刻がわかるので便利である。 + <code>big-clock-mode</code> を開発したのは、次のようなシチュエーションで使うためである。弊社では現在リモートワークが基本だが、web 会議などで画面共有しているときに、休憩を挟んで特定の時刻から再開する、ということがある。こういったケースで、画面上に現在の時刻を大きめに表示しておくと、モニタから離れても遠くから時刻がわかるので便利である。 </p> <p> それこそタイマアプリか何かを使えばいいのだが、ターミナルに棲むいきものとしては、住処から離れたくないわけだ。 </p> <p> - しばらく便利に使っていたのだが、ひとつ不満点が出てきた。それは、再開する時刻がいつだったかを覚えておかなければならないということだ。 どこかにメモしておいてもいいが、せっかくなら現在時刻とともに表示させておきたい。 + しばらく便利に使っていたのだが、ひとつ不満点が出てきた。それは、再開する時刻がいつだったかを覚えておかなければならないということだ。どこかにメモしておいてもいいが、せっかくなら現在時刻とともに表示させておきたい。 </p> <p> - そんなわけで、「任意の文字列をターミナルに表示する」プログラムを書く運びとなった。 まあ、作らなくても探せばあると思うが、作りたいものは作りたいので知ったことではない。 + そんなわけで、「任意の文字列をターミナルに表示する」プログラムを書く運びとなった。まあ、作らなくても探せばあると思うが、作りたいものは作りたいので知ったことではない。 </p> </section> <section id="section--program"> @@ -111,7 +111,7 @@ <code>big-clock-mode</code> が Go 製なので、今回も Go で書いた。 PNG が標準ライブラリにあったり、Shift-JIS のエンコーディングが準標準ライブラリにあったりしたのは助かった。 </p> <p> - フォントファイルは <code>go:embed</code> で実行ファイルに埋め込んでいるので、ビルド後はワンバイナリで動く。 仕事ではスクリプト言語ばかり書いているが、やはりコンパイル言語はいい。 + フォントファイルは <code>go:embed</code> で実行ファイルに埋め込んでいるので、ビルド後はワンバイナリで動く。仕事ではスクリプト言語ばかり書いているが、やはりコンパイル言語はいい。 </p> </section> <section id="section--font"> @@ -120,16 +120,16 @@ フリーの 8x8 ビットマップフォントである、 <a href="https://littlelimit.net/misaki.htm" rel="noreferrer" target="_blank">美咲フォント 2021-05-05a 版</a> を使わせていただいた。 </p> <p> - はじめは自分でポチポチ打っていたのだが、「き」くらいまでやって挫折した。 同じく 8x8 で作っていたのだが、平仮名でさえも、この小さなキャンバスにはとても収められない。 + はじめは自分でポチポチ打っていたのだが、「き」くらいまでやって挫折した。同じく 8x8 で作っていたのだが、平仮名でさえも、この小さなキャンバスにはとても収められない。 </p> <p> - 美咲フォントは、平仮名・片仮名に留まらず、JIS 第一・第二水準の漢字までサポートしている。 第二水準ともなると一生お目にかかることのない字の方が多いくらいだが、これをこの大きさで書くというのは、もはや芸術の域である。 + 美咲フォントは、平仮名・片仮名に留まらず、JIS 第一・第二水準の漢字までサポートしている。第二水準ともなると一生お目にかかることのない字の方が多いくらいだが、これをこの大きさで書くというのは、もはや芸術の域である。 </p> <p> - さらに言うと、実のところ美咲フォントは実サイズ 7x7 で作られており、余白が設けられている。 これは、単純にそのまま並べても字間・行間を確保できるようにという配慮である。 おかげでコーディングまで楽になった。 + さらに言うと、実のところ美咲フォントは実サイズ 7x7 で作られており、余白が設けられている。これは、単純にそのまま並べても字間・行間を確保できるようにという配慮である。おかげでコーディングまで楽になった。 </p> <p> - ゴシック体と明朝体があったが、私の好みで明朝体の方にした。 ただ、ゴシック体の方が見やすい気がするので、フォントを選べるように後ほど拡張するかもしれない。 + ゴシック体と明朝体があったが、私の好みで明朝体の方にした。ただ、ゴシック体の方が見やすい気がするので、フォントを選べるように後ほど拡張するかもしれない。 </p> <div class="admonition" editat="2022-04-27" operation="追記"> <div class="admonition-label"> diff --git a/vhosts/blog/public/posts/2022-05-01/phperkaigi-2022/index.html b/vhosts/blog/public/posts/2022-05-01/phperkaigi-2022/index.html index b593e374..c87a9287 100644 --- a/vhosts/blog/public/posts/2022-05-01/phperkaigi-2022/index.html +++ b/vhosts/blog/public/posts/2022-05-01/phperkaigi-2022/index.html @@ -66,7 +66,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2022-04-09 から 2022-04-11 にかけて開催された、 <a href="https://phperkaigi.jp/2022/" rel="noreferrer" target="_blank">PHPerKaigi 2022</a> に、 一般参加者として参加した。 弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> はダイヤモンドスポンサーとなっており、 スポンサー枠のチケットを使わせていただいた。 + 2022-04-09 から 2022-04-11 にかけて開催された、 <a href="https://phperkaigi.jp/2022/" rel="noreferrer" target="_blank">PHPerKaigi 2022</a> に、一般参加者として参加した。弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。 </p> <p> 昨年のレポートは <a href="/posts/2021-03-30/phperkaigi-2021">こちら</a> 。 @@ -77,7 +77,7 @@ <section id="section--comments--great-sessions"> <h3><a href="#section--comments--great-sessions">厳選おすすめトーク</a></h3> <p> - 多くの素晴らしいトークの中から、特におすすめのものを 5つ選んだ。 是非聞いてほしい。引用部分は、リンク先プロポーザルから引用している。 + 多くの素晴らしいトークの中から、特におすすめのものを 5つ選んだ。是非聞いてほしい。引用部分は、リンク先プロポーザルから引用している。 </p> <p> <a href="https://fortee.jp/phperkaigi-2022/proposal/ef8cf4ed-63fe-42f8-8145-b3e70054458b" rel="noreferrer" target="_blank">予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント</a> @@ -181,13 +181,13 @@ <section id="section--comments--token-quizzes"> <h3><a href="#section--comments--token-quizzes">トークン問題の作成</a></h3> <p> - 今回は、PHPer チャレンジ用に弊社のトークン問題を 3題作成した。 こちらについては <a href="/posts/2022-04-09/phperkaigi-2022-tokens">別途記事にしている</a> ので、そちらを参照されたい。 + 今回は、PHPer チャレンジ用に弊社のトークン問題を 3題作成した。こちらについては <a href="/posts/2022-04-09/phperkaigi-2022-tokens">別途記事にしている</a> ので、そちらを参照されたい。 </p> </section> <section id="section--comments--phper-challenge"> <h3><a href="#section--comments--phper-challenge">PHPer チャレンジ</a></h3> <p> - <a href="https://fortee.jp/phperkaigi-2022/challenge" rel="noreferrer" target="_blank">1位</a> になった。 また、賞品として <a href="https://www.amazon.co.jp/dp/B08MQNJC9Z" rel="noreferrer" target="_blank">Echo Show 15</a> をいただいた。 + <a href="https://fortee.jp/phperkaigi-2022/challenge" rel="noreferrer" target="_blank">1位</a> になった。また、賞品として <a href="https://www.amazon.co.jp/dp/B08MQNJC9Z" rel="noreferrer" target="_blank">Echo Show 15</a> をいただいた。 </p> </section> <section id="section--comments--conference"> @@ -197,17 +197,17 @@ </p> <blockquote> <p> - 1つ個人的な反省点としては、(中略) Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、 後から見返せる発表やスライドに注力してしまった、ということだ。 発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。 まあ初カンファレンスだし、とお茶を濁しておこう。 + 1つ個人的な反省点としては、(中略) Discord しかりアンカンファレンスしかり「このイベントのこの瞬間にしかないコンテンツ」に触れずに、後から見返せる発表やスライドに注力してしまった、ということだ。発表の詳細な見直しはあとからできるのだから、今しかできないことを考えるべきだった。まあ初カンファレンスだし、とお茶を濁しておこう。 </p> </blockquote> <p> - この反省を踏まえ、今年は積極的にほかの場 (公式の Discord サーバや、アンカンファレンス) にも参加した。 これにより、参加体験の質がはるかに向上した。特に Discord に関しては、登壇者ご本人による補足や、 質問への回答などがおこなわれる (ことが多い) ため、特別な理由のない限り、発言はしないまでも参加はしておいたほうが良いと思われる。 + この反省を踏まえ、今年は積極的にほかの場 (公式の Discord サーバや、アンカンファレンス) にも参加した。これにより、参加体験の質がはるかに向上した。特に Discord に関しては、登壇者ご本人による補足や、質問への回答などがおこなわれる (ことが多い) ため、特別な理由のない限り、発言はしないまでも参加はしておいたほうが良いと思われる。 </p> <p> なお、アンカンファレンスについては、1日目の終わりに <a href="https://fortee.jp/phperkaigi-2022/unconference/view/d332797a-8921-4706-a7e2-ee72640c9b5e" rel="noreferrer" target="_blank">トークン問題の解説放送</a> もおこなった。 </p> <p> - また、今年はオフラインとオンラインのハイブリッド開催であったが、去年の全オンラインと比べて、オンライン参加の体験が落ちていなかったのは、特筆すべきであろう。 今年は 3回目のワクチン接種が間に合わなかったこともあり現地参加は見送ったのだが、来年は是非オフラインで参加したい。 + また、今年はオフラインとオンラインのハイブリッド開催であったが、去年の全オンラインと比べて、オンライン参加の体験が落ちていなかったのは、特筆すべきであろう。今年は 3回目のワクチン接種が間に合わなかったこともあり現地参加は見送ったのだが、来年は是非オフラインで参加したい。 </p> </section> </section> diff --git a/vhosts/blog/public/posts/2022-08-27/php-conference-okinawa-code-golf/index.html b/vhosts/blog/public/posts/2022-08-27/php-conference-okinawa-code-golf/index.html index ac06818f..9c4eb273 100644 --- a/vhosts/blog/public/posts/2022-08-27/php-conference-okinawa-code-golf/index.html +++ b/vhosts/blog/public/posts/2022-08-27/php-conference-okinawa-code-golf/index.html @@ -134,22 +134,22 @@ <section id="section--techniques--exponential-notation"> <h3><a href="#section--techniques--exponential-notation">指数表記</a></h3> <p> - 割と多くの言語のゴルフで使えるテクニック。 <code>e</code> を用いた指数表記で、大きな数を短く表す。 このコードでは <code>10000</code>、<code>5000</code>、<code>2000</code>、<code>1000</code> を指数表記している。 + 割と多くの言語のゴルフで使えるテクニック。<code>e</code> を用いた指数表記で、大きな数を短く表す。このコードでは <code>10000</code>、<code>5000</code>、<code>2000</code>、<code>1000</code> を指数表記している。 </p> </section> <section id="section--techniques--shorten-loop"> <h3><a href="#section--techniques--shorten-loop">foreach や for の中身を1つの文に</a></h3> <p> - <code>foreach</code>、<code>for</code>、<code>if</code> などの後ろには、 通常 <code>{</code> を続けて複数の文を連ねるが、中身の文を1つにしてしまえば、<code>{</code> と <code>}</code> を省略できる。 C言語などでも使える。 + <code>foreach</code>、<code>for</code>、<code>if</code> などの後ろには、通常 <code>{</code> を続けて複数の文を連ねるが、中身の文を1つにしてしまえば、<code>{</code> と <code>}</code> を省略できる。C言語などでも使える。 </p> </section> <section id="section--techniques--omit-initialization"> <h3><a href="#section--techniques--omit-initialization">$r に初期値を入れない</a></h3> <p> - PHP では、<code>$r[] = ......</code> のような配列の末尾に追加する式を実行したとき、 <code>$r</code> が未定義だった場合は <code>$r</code> を勝手に定義して空の配列で初期化してくれる。 これを利用すると、<code>$r = [];</code> のような初期化が不要になる。 + PHP では、<code>$r[] = ......</code> のような配列の末尾に追加する式を実行したとき、<code>$r</code> が未定義だった場合は <code>$r</code> を勝手に定義して空の配列で初期化してくれる。これを利用すると、<code>$r = [];</code> のような初期化が不要になる。 </p> <p> - ただし、プログラムに 0 が渡されるとループを一度も回らないので、<code>$r</code> が未定義になってしまい、 <code>implode()</code> に渡すところでエラーになる。 それを防ぐために <code>$r ?? []</code> を使っている。 + ただし、プログラムに 0 が渡されるとループを一度も回らないので、<code>$r</code> が未定義になってしまい、<code>implode()</code> に渡すところでエラーになる。それを防ぐために <code>$r ?? []</code> を使っている。 </p> <p> もし 0 が渡されたケースを無視するなら、これが不要になるので 4 バイト縮む。 @@ -158,7 +158,7 @@ <section id="section--techniques--put-text-outside-php-tag"> <h3><a href="#section--techniques--put-text-outside-php-tag">PHP タグの外に文字列を置く</a></h3> <p> - PHP では、<code><?php</code> <code>?></code> で囲われた部分の外側にある文字列は、そのまま出力される。 今回のケースでは、先頭と末尾に必ず <code>[</code> と <code>]</code> を出力するので、そのまま書いてやればよい。 + PHP では、<code><?php</code> <code>?></code> で囲われた部分の外側にある文字列は、そのまま出力される。今回のケースでは、先頭と末尾に必ず <code>[</code> と <code>]</code> を出力するので、そのまま書いてやればよい。 </p> </section> </section> diff --git a/vhosts/blog/public/posts/2022-08-31/support-for-communty-is-employee-benefits/index.html b/vhosts/blog/public/posts/2022-08-31/support-for-communty-is-employee-benefits/index.html index d0c8d9c3..bc097fa3 100644 --- a/vhosts/blog/public/posts/2022-08-31/support-for-communty-is-employee-benefits/index.html +++ b/vhosts/blog/public/posts/2022-08-31/support-for-communty-is-employee-benefits/index.html @@ -76,7 +76,7 @@ </p> <blockquote> <p> - 結局これを通したい (私の中での) 最大の理由が、「自分の勤める会社が、これをやる会社であってほしい」というのがあり、 ↑にしても、感情ベースの理由しか出せていないというのが説得力に欠けている理由なのだと思いますが、 寄付の報告が流れてきたり、OSS のフリーライドの話が流れてきたりするたびに、自尊心が毀損される、というか (これは大袈裟すぎる表現で、実際にはそこまで明確に傷ついているわけではありませんが)。 + 結局これを通したい (私の中での) 最大の理由が、「自分の勤める会社が、これをやる会社であってほしい」というのがあり、↑にしても、感情ベースの理由しか出せていないというのが説得力に欠けている理由なのだと思いますが、寄付の報告が流れてきたり、OSS のフリーライドの話が流れてきたりするたびに、自尊心が毀損される、というか (これは大袈裟すぎる表現で、実際にはそこまで明確に傷ついているわけではありませんが)。 </p> <p> 追記: 「肩身が狭くなる」というのがより適切でした。 @@ -86,7 +86,7 @@ ※文中の「↑にしても」は、ここに載せていない別の投稿を指しています。 </p> <p> - OSS を金銭的に支援したり、技術カンファレンスへ協賛したり (あるいは <a href="https://twitter.com/tomzoh" rel="noreferrer" target="_blank">CTO</a> がカンファレンスを年2で主催したり: <a href="https://iosdc.jp" rel="noreferrer" target="_blank">iOSDC</a> <a href="https://phperkaigi.jp" rel="noreferrer" target="_blank">PHPerKaigi</a> ) といった行為は、コミュニティへの貢献であると同時に、社員に対する精神的福利厚生でもあると言えるでしょう (知らんけど)。 これらは、技術や技術者を大切にする組織である、ということの、対外的にも対内的にも強力なメッセージなのです。 + OSS を金銭的に支援したり、技術カンファレンスへ協賛したり (あるいは <a href="https://twitter.com/tomzoh" rel="noreferrer" target="_blank">CTO</a> がカンファレンスを年2で主催したり: <a href="https://iosdc.jp" rel="noreferrer" target="_blank">iOSDC</a> <a href="https://phperkaigi.jp" rel="noreferrer" target="_blank">PHPerKaigi</a> ) といった行為は、コミュニティへの貢献であると同時に、社員に対する精神的福利厚生でもあると言えるでしょう (知らんけど)。これらは、技術や技術者を大切にする組織である、ということの、対外的にも対内的にも強力なメッセージなのです。 </p> <p> 以上が、私が社内で寄付の件を進めた (かなり私的な) 理由です。 @@ -95,7 +95,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 最終的に社としての寄付まで漕ぎ着けられたのは、もちろん私の力ではなく役員の方々の決定によるものです。 この場を借りて感謝申し上げます。 + 最終的に社としての寄付まで漕ぎ着けられたのは、もちろん私の力ではなく役員の方々の決定によるものです。この場を借りて感謝申し上げます。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2022-09-29/write-fizzbuzz-in-php-2-letters-per-line/index.html b/vhosts/blog/public/posts/2022-09-29/write-fizzbuzz-in-php-2-letters-per-line/index.html index 4f1f41ef..2f471ec7 100644 --- a/vhosts/blog/public/posts/2022-09-29/write-fizzbuzz-in-php-2-letters-per-line/index.html +++ b/vhosts/blog/public/posts/2022-09-29/write-fizzbuzz-in-php-2-letters-per-line/index.html @@ -63,7 +63,7 @@ <section id="section--intro"> <h2><a href="#section--intro">記事の構成について</a></h2> <p> - この記事は、普通の fizzbuzz を徐々に変形して最終形にしていく、という構成で書かれている。 最終形を見てどのような仕組みで動いているのか解読してから解説を読みたい、というかたがいれば、 <a href="https://gist.github.com/nsfisis/04c227d5a419867472a0b23a83ad2919#file-fizzbuzz-php-2-letters-per-line-and-supports-php-8-x-without-warnings" rel="noreferrer" target="_blank">このページ</a> にソースコードがあるので、そちらを先に見てほしい。 + この記事は、普通の fizzbuzz を徐々に変形して最終形にしていく、という構成で書かれている。最終形を見てどのような仕組みで動いているのか解読してから解説を読みたい、というかたがいれば、<a href="https://gist.github.com/nsfisis/04c227d5a419867472a0b23a83ad2919#file-fizzbuzz-php-2-letters-per-line-and-supports-php-8-x-without-warnings" rel="noreferrer" target="_blank">このページ</a> にソースコードがあるので、そちらを先に見てほしい。 </p> </section> <section id="section--regulations"> @@ -102,7 +102,7 @@ </li> </ul> <p> - 備考: PHP には <code>short_open_tag</code> というオプションがあり、 これを有効にするとファイル冒頭の <code><?php</code> の代わりに <code><?</code> を使うことができ、文字どおり1行2文字で書ける。 ただ、このオプションはデフォルト off になっている環境が多いようなので、今回は使わないことにした。 + 備考: PHP には <code>short_open_tag</code> というオプションがあり、これを有効にするとファイル冒頭の <code><?php</code> の代わりに <code><?</code> を使うことができ、文字どおり1行2文字で書ける。ただ、このオプションはデフォルト off になっている環境が多いようなので、今回は使わないことにした。 </p> </section> <section id="section--problems"> @@ -193,7 +193,7 @@ バックスラッシュを使った行継続がトークンを区切らない、というのがポイントだ。 </p> <p> - さて、PHP ではそもそもバックスラッシュを行継続に使うことができない。 これにより、「3文字以上からなるトークンが一切使えない」という制約が課される。 例えば、<code>echo</code> で出力することや、<code>for</code> でループすること、 <code>new</code> でインスタンスを生成することができない。 特に、出力は fizzbuzz をどんなアルゴリズムで実装しようとおこなわなければならないので、できないのは致命的である。 + さて、PHP ではそもそもバックスラッシュを行継続に使うことができない。これにより、「3文字以上からなるトークンが一切使えない」という制約が課される。例えば、<code>echo</code> で出力することや、<code>for</code> でループすること、<code>new</code> でインスタンスを生成することができない。特に、出力は fizzbuzz をどんなアルゴリズムで実装しようとおこなわなければならないので、できないのは致命的である。 </p> <p> 当然、名前が3文字以上ある関数も使えない。なお、標準 PHP の範囲内において、名前が 2文字以下の関数は以下のとおりである: @@ -226,7 +226,7 @@ に反する (というより、「それだとおもしろくもなんともないので、このルールを足した」というのが正しい)。 </p> <p> - また、2文字だと文字列がまともに書けないのも辛い。<code>''</code> だけで2文字使うので、 「1文字の文字列リテラル」というものを書くことができない。PHP では文字列リテラル中に生の改行が書けるので + また、2文字だと文字列がまともに書けないのも辛い。<code>''</code> だけで2文字使うので、「1文字の文字列リテラル」というものを書くことができない。PHP では文字列リテラル中に生の改行が書けるので </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$a</span></span> @@ -262,7 +262,7 @@ <section id="section--commentary--remove-keywords"> <h3><a href="#section--commentary--remove-keywords"><code>for</code> の排除</a></h3> <p> - <code>for</code> は、3文字もある長いキーワードである。 こんなものは使えない。<code>array_</code> 系の関数を使って、適当に置き換えるとしよう。 + <code>for</code> は、3文字もある長いキーワードである。こんなものは使えない。<code>array_</code> 系の関数を使って、適当に置き換えるとしよう。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49"><?</span><span style="color:#005CC5">php</span></span> @@ -275,13 +275,13 @@ <span class="line"><span style="color:#24292E">);</span></span></code></pre> </div> <p> - <code>array_walk</code> や <code>range</code>、<code>printf</code> といった <code>for</code> よりも長いトークンが現れてしまったが、これは次節で直すことにする。 なお、<code>echo</code> は文 (statement) であり式 (expression) ではないので、式である <code>printf</code> に置き換えた。 + <code>array_walk</code> や <code>range</code>、<code>printf</code> といった <code>for</code> よりも長いトークンが現れてしまったが、これは次節で直すことにする。なお、<code>echo</code> は文 (statement) であり式 (expression) ではないので、式である <code>printf</code> に置き換えた。 </p> </section> <section id="section--commentary--shorten-function-invocation"> <h3><a href="#section--commentary--shorten-function-invocation">関数呼び出しの短縮</a></h3> <p> - <code>range</code>、<code>array_walk</code>、<code>printf</code> は長すぎるのでどうにかせねばならない。 ここで、PHP の可変関数を使う。可変関数とは、関数名が文字列として入った変数を経由して、関数を呼び出す機能である。 + <code>range</code>、<code>array_walk</code>、<code>printf</code> は長すぎるのでどうにかせねばならない。ここで、PHP の可変関数を使う。可変関数とは、関数名が文字列として入った変数を経由して、関数を呼び出す機能である。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49"><?</span><span style="color:#005CC5">php</span></span> @@ -298,7 +298,7 @@ <span class="line"><span style="color:#24292E">);</span></span></code></pre> </div> <p> - これで関数を呼び出している所は短くなった。 では、<code>$r</code> や <code>$w</code> や <code>$p</code>、 また <code>'Fizz'</code> や <code>'Buzz'</code> はどうやって 1 行 2 文字に収めるのか。 次のテクニックへ移ろう。 + これで関数を呼び出している所は短くなった。では、<code>$r</code> や <code>$w</code> や <code>$p</code>、また <code>'Fizz'</code> や <code>'Buzz'</code> はどうやって 1 行 2 文字に収めるのか。次のテクニックへ移ろう。 </p> </section> <section id="section--commentary--incompatible-solution"> @@ -314,7 +314,7 @@ </ul> </blockquote> <p> - というルールがない場合、「未定義の定数が評価された場合、その定数の名前が値になる」という PHP 7.x までの仕様が利用できる。 例えば、 <code>Fizz</code> という文字列が欲しければ、次のようにする。 + というルールがない場合、「未定義の定数が評価された場合、その定数の名前が値になる」という PHP 7.x までの仕様が利用できる。例えば、 <code>Fizz</code> という文字列が欲しければ、次のようにする。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$f</span></span> @@ -325,7 +325,7 @@ <span class="line"><span style="color:#24292E">;;</span></span></code></pre> </div> <p> - こうして簡単に文字列を作れる。 なお、この仕様は 7.x 時点でも警告を受けるので、<code>@</code> 演算子を使って抑制してやるとよい。 + こうして簡単に文字列を作れる。なお、この仕様は 7.x 時点でも警告を受けるので、<code>@</code> 演算子を使って抑制してやるとよい。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$f</span></span> @@ -348,7 +348,7 @@ 実際に使った手法の説明に移る。 </p> <p> - ずばり、文字列同士のビット演算を使う。 PHP では、文字列同士でビット演算 (<code>&</code>、<code>|</code>、<code>^</code>) をした場合、 文字列の各バイトごとに指定したビット演算がなされ、それを結合したものが演算結果となる。 + ずばり、文字列同士のビット演算を使う。PHP では、文字列同士でビット演算 (<code>&</code>、<code>|</code>、<code>^</code>) をした場合、文字列の各バイトごとに指定したビット演算がなされ、それを結合したものが演算結果となる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$a </span><span style="color:#D73A49">=</span><span style="color:#032F62"> "12345"</span><span style="color:#24292E">;</span></span> @@ -373,7 +373,7 @@ <span class="line"><span style="color:#005CC5">echo</span><span style="color:#032F62"> "</span><span style="color:#24292E">$r</span><span style="color:#005CC5">\n</span><span style="color:#032F62">"</span><span style="color:#24292E">;</span></span></code></pre> </div> <p> - 実行すると、<code>range</code> が表示される。 さて、PHP では文字列リテラル中に生の改行を直接書いてもよいのだった (「主な障害」の節を参照のこと)。 書きかえてみよう。 + 実行すると、<code>range</code> が表示される。さて、PHP では文字列リテラル中に生の改行を直接書いてもよいのだった (「主な障害」の節を参照のこと)。書きかえてみよう。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$x</span></span> @@ -413,10 +413,10 @@ <span class="line"><span style="color:#005CC5">echo</span><span style="color:#032F62"> "</span><span style="color:#24292E">$r</span><span style="color:#005CC5">\n</span><span style="color:#032F62">"</span><span style="color:#24292E">;</span></span></code></pre> </div> <p> - 1行あたり2文字で、<code>range</code> という文字列を生成することに成功した。 他の必要な文字列にも、同様の処理をほどこす。 + 1行あたり2文字で、<code>range</code> という文字列を生成することに成功した。他の必要な文字列にも、同様の処理をほどこす。 </p> <p> - 備考: <code>Buzz</code> 中にある小文字の <code>u</code> は、このロジックだと non-printable な文字になってしまう。 ここまでのテクニックを駆使すれば回避するのはそう難しくないので、考えてみてほしい。 + 備考: <code>Buzz</code> 中にある小文字の <code>u</code> は、このロジックだと non-printable な文字になってしまう。ここまでのテクニックを駆使すれば回避するのはそう難しくないので、考えてみてほしい。 </p> </section> </section> @@ -580,7 +580,7 @@ <section id="section--outro"> <h2><a href="#section--outro">感想など</a></h2> <p> - PHP は、スクリプト言語の中だとシンタックスシュガーが少ない (体感)。 この挑戦は不可能に思われたが、PHP マニュアルとにらめっこしていたらなんとかなった。 + PHP は、スクリプト言語の中だとシンタックスシュガーが少ない (体感)。この挑戦は不可能に思われたが、PHP マニュアルとにらめっこしていたらなんとかなった。 </p> <p> みんなもプログラムを細長くしよう。 @@ -589,7 +589,7 @@ <section id="section--alternative-solution"> <h2><a href="#section--alternative-solution">余談2: 別解</a></h2> <p> - PHP では、バッククォートを使ってシェルを呼び出せる。 これは <code>shell_exec</code> 関数と等価である。 さて、PHP ではバックスラッシュによる行継続が使えないと書いたが、シェルでは使える (当然だが、呼び出されるシェルに依存する。Bash なら大丈夫だろう。知らんけど)。 + PHP では、バッククォートを使ってシェルを呼び出せる。これは <code>shell_exec</code> 関数と等価である。さて、PHP ではバックスラッシュによる行継続が使えないと書いたが、シェルでは使える (当然だが、呼び出されるシェルに依存する。Bash なら大丈夫だろう。知らんけど)。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49"><?</span><span style="color:#005CC5">php</span></span> @@ -606,7 +606,7 @@ <span class="line"><span style="color:#032F62">`</span><span style="color:#24292E">);</span></span></code></pre> </div> <p> - なお、ここでは簡単のため出力に <code>printf</code> をそのまま使っているが、 実際には <code>printf</code> という文字列を合成して可変関数で呼び出す。 + なお、ここでは簡単のため出力に <code>printf</code> をそのまま使っているが、実際には <code>printf</code> という文字列を合成して可変関数で呼び出す。 </p> <p> ただし、これでは @@ -664,7 +664,7 @@ <span class="line"><span>'}</span></span></code></pre> </div> <p> - は変数で、中にはスペースとエスケープが入っている (<code>chr(32) . chr(92)</code>)。 シェルに渡されている文字列は次のようになる。 + は変数で、中にはスペースとエスケープが入っている (<code>chr(32) . chr(92)</code>)。シェルに渡されている文字列は次のようになる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>e\</span></span> @@ -677,7 +677,7 @@ <span class="line"><span>3\</span></span></code></pre> </div> <p> - これは、前掲したコマンドと同じだ。 かくして、スペースを陽に書かずにシェルをおおよそ自由に扱えるようになった。 Fizzbuzz のワンライナーくらいすぐ書けるだろうから、あとはなんとかなるだろう (試してないけど)。 + これは、前掲したコマンドと同じだ。かくして、スペースを陽に書かずにシェルをおおよそ自由に扱えるようになった。Fizzbuzz のワンライナーくらいすぐ書けるだろうから、あとはなんとかなるだろう (試してないけど)。 </p> <p> ということでこれは別解ということにしておく。 diff --git a/vhosts/blog/public/posts/2022-10-23/phperkaigi-2023-unused-token-quiz-1/index.html b/vhosts/blog/public/posts/2022-10-23/phperkaigi-2023-unused-token-quiz-1/index.html index 971f3c28..270ca0c2 100644 --- a/vhosts/blog/public/posts/2022-10-23/phperkaigi-2023-unused-token-quiz-1/index.html +++ b/vhosts/blog/public/posts/2022-10-23/phperkaigi-2023-unused-token-quiz-1/index.html @@ -63,13 +63,13 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2023 年 3 月 23 日から 25 日にかけて開催予定 (記事執筆時点) の、 <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> において、 昨年と同様に、弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> から、 トークン問題を出題予定である。 + 2023 年 3 月 23 日から 25 日にかけて開催予定 (記事執筆時点) の、<a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> において、昨年と同様に、弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> から、トークン問題を出題予定である。 </p> <p> 昨年のトークン問題の記事はこちら: <a href="/posts/2022-04-09/phperkaigi-2022-tokens">PHPerKaigi 2022 トークン問題の解説</a> </p> <p> - すでに 2023 年用の問題は作成済みであるが、その制作過程の中でいくつかボツ問ができた。 せっかくなので、PHPerKaigi 開催を待つ間に紹介しようと思う。 + すでに 2023 年用の問題は作成済みであるが、その制作過程の中でいくつかボツ問ができた。せっかくなので、PHPerKaigi 開催を待つ間に紹介しようと思う。 </p> <p> 10 月から 2 月まで、毎月 1 記事ずつ公開していく予定 (忘れていなければ)。 @@ -107,7 +107,7 @@ <section id="section--how-to-obtain-token"> <h2><a href="#section--how-to-obtain-token">トークン入手方法</a></h2> <p> - ソースを見るとわかるとおり、<code>$argv[1]</code> を参照している。 それを <code>$π</code> なる変数に代入しているので、円周率を渡してみる。 + ソースを見るとわかるとおり、<code>$argv[1]</code> を参照している。それを <code>$π</code> なる変数に代入しているので、円周率を渡してみる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ php Q.php 3.14</span></span> @@ -156,10 +156,10 @@ <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$s </span><span style="color:#D73A49">=</span><span style="color:#005CC5"> implode</span><span style="color:#24292E">(</span><span style="color:#005CC5">array_map</span><span style="color:#24292E">(</span><span style="color:#005CC5">chr</span><span style="color:#24292E">(</span><span style="color:#D73A49">...</span><span style="color:#24292E">), </span><span style="color:#005CC5">str_split</span><span style="color:#24292E">($π, </span><span style="color:#005CC5">2</span><span style="color:#24292E">)));</span></span></code></pre> </div> <p> - <code>$π</code> を 2 文字ごとに区切り (<code>str_split</code>)、 数値を ASCII コードと見做して文字に変換 (<code>chr</code>) して結合 (<code>implode</code>) している。 + <code>$π</code> を 2 文字ごとに区切り (<code>str_split</code>)、数値を ASCII コードと見做して文字に変換 (<code>chr</code>) して結合 (<code>implode</code>) している。 </p> <p> - 例えば、<code>$π</code> が <code>'656667'</code> だったとすると、 <code>65</code>、<code>66</code>、<code>67</code> に対応した <code>'A'</code>、<code>'B'</code>、<code>'C'</code> へと変換され、<code>'ABC'</code> になる。 + 例えば、<code>$π</code> が <code>'656667'</code> だったとすると、<code>65</code>、<code>66</code>、<code>67</code> に対応した <code>'A'</code>、<code>'B'</code>、<code>'C'</code> へと変換され、<code>'ABC'</code> になる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$π </span><span style="color:#D73A49">=</span><span style="color:#032F62"> '656667'</span><span style="color:#24292E">;</span></span> @@ -172,10 +172,10 @@ <span class="line"><span style="color:#24292E">$t </span><span style="color:#D73A49">=</span><span style="color:#24292E"> $m[</span><span style="color:#005CC5">1</span><span style="color:#24292E">] </span><span style="color:#D73A49">??</span><span style="color:#032F62"> ''</span><span style="color:#24292E">;</span></span></code></pre> </div> <p> - 正規表現でマッチングしている。<code>\x23</code> は <code>#</code> と同じであることに留意すると、 この正規表現は「<code>#</code> から始まる 2 以上の長さ (含 <code>#</code>) の文字列で、 最初に現れるスペースまで」にマッチする。つまりこれは、PHPerKaigi におけるトークンである。 + 正規表現でマッチングしている。<code>\x23</code> は <code>#</code> と同じであることに留意すると、この正規表現は「<code>#</code> から始まる 2 以上の長さ (含 <code>#</code>) の文字列で、最初に現れるスペースまで」にマッチする。つまりこれは、PHPerKaigi におけるトークンである。 </p> <p> - なお、<code>#</code> を直接書いていないのは、<code>/#.+?) /</code> と書くと、 <code>#.+?)</code> という意図せぬトークンが登録されてしまうからである。 + なお、<code>#</code> を直接書いていないのは、<code>/#.+?) /</code> と書くと、<code>#.+?)</code> という意図せぬトークンが登録されてしまうからである。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">if</span><span style="color:#24292E"> (</span><span style="color:#005CC5">md5</span><span style="color:#24292E">($t) </span><span style="color:#D73A49">===</span><span style="color:#032F62"> '056e831a4146bf123e8ea16613303d2e'</span><span style="color:#24292E">) {</span></span> @@ -194,7 +194,7 @@ 円周率を何桁も計算して ASCII コード経由で文字列化すれば、トークンっぽいものがどこかで出てくるのではないか、と考えて生まれた作品。 </p> <p> - 最初は真面目に円周率の計算プログラムを組んでいたのだが、いざ動かしてみるとやけに浅いところにあったので驚いた (ちなみに、それでも <code>M_PI</code> や <code>pi()</code> では精度が足りない)。 見つけたときは狂喜したものの、冷静になってみると大して面白くなかったのでボツになった。 むしろ、100 万桁目くらいに埋まっていてくれたほうがよかったかもしれない。 + 最初は真面目に円周率の計算プログラムを組んでいたのだが、いざ動かしてみるとやけに浅いところにあったので驚いた (ちなみに、それでも <code>M_PI</code> や <code>pi()</code> では精度が足りない)。見つけたときは狂喜したものの、冷静になってみると大して面白くなかったのでボツになった。むしろ、100 万桁目くらいに埋まっていてくれたほうがよかったかもしれない。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2022-10-28/setup-server-for-this-site/index.html b/vhosts/blog/public/posts/2022-10-28/setup-server-for-this-site/index.html index ee037dee..95b2d08d 100644 --- a/vhosts/blog/public/posts/2022-10-28/setup-server-for-this-site/index.html +++ b/vhosts/blog/public/posts/2022-10-28/setup-server-for-this-site/index.html @@ -63,7 +63,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - これまでこの blog は GitHub Pages でホストしていたのだが、先日 VPS に移行した。 そのときにおこなったサーバのセットアップ作業を書き残しておく。 99 % 自分用の備忘録。別のベンダに移したりしたくなったら見に来る。 + これまでこの blog は GitHub Pages でホストしていたのだが、先日 VPS に移行した。そのときにおこなったサーバのセットアップ作業を書き残しておく。99 % 自分用の備忘録。別のベンダに移したりしたくなったら見に来る。 </p> <p> 未来の自分へ: 特に自動化してないので、せいぜい苦しんでくれ。 @@ -72,7 +72,7 @@ <section id="section--vps"> <h2><a href="#section--vps">VPS</a></h2> <p> - <a href="https://vps.sakura.ad.jp/" rel="noreferrer" target="_blank">さくらの VPS</a> の 2 GB プラン。 そこまで真面目に選定していないので、困ったら移動するかも。 + <a href="https://vps.sakura.ad.jp/" rel="noreferrer" target="_blank">さくらの VPS</a> の 2 GB プラン。そこまで真面目に選定していないので、困ったら移動するかも。 </p> </section> <section id="section--preparation"> @@ -80,7 +80,7 @@ <section id="section--preparation--hostname"> <h3><a href="#section--preparation--hostname">サーバのホスト名を決める</a></h3> <p> - モチベーションが上がるという効能がある。今回は藤原定家から取って <code>teika</code> にした。 たいていいつも源氏物語の帖か小倉百人一首の歌人から選んでいる。 + モチベーションが上がるという効能がある。今回は藤原定家から取って <code>teika</code> にした。たいていいつも源氏物語の帖か小倉百人一首の歌人から選んでいる。 </p> </section> <section id="section--preparation--ssh-key"> @@ -93,7 +93,7 @@ <span class="line"><span>$ ssh-keygen -t ed25519 -b 521 -f ~/.ssh/github2teika.key</span></span></code></pre> </div> <p> - <code>teika.key</code> はローカルからサーバへの接続用、<code>github2teika.key</code> は、 GitHub Actions からサーバへのデプロイ用。 + <code>teika.key</code> はローカルからサーバへの接続用、<code>github2teika.key</code> は、GitHub Actions からサーバへのデプロイ用。 </p> </section> <section id="section--preparation--ssh-config"> @@ -122,7 +122,7 @@ <section id="section--basic-setup--user"> <h3><a href="#section--basic-setup--user">ユーザを作成する</a></h3> <p> - 管理者ユーザで作業すると危ないので、メインで使うユーザを作成する。 <code>sudo</code> グループに追加して <code>sudo</code> できるようにし、<code>su</code> で切り替え。 + 管理者ユーザで作業すると危ないので、メインで使うユーザを作成する。<code>sudo</code> グループに追加して <code>sudo</code> できるようにし、<code>su</code> で切り替え。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ sudo adduser **********</span></span> @@ -179,7 +179,7 @@ <section id="section--basic-setup--ssh-connect"> <h3><a href="#section--basic-setup--ssh-connect">SSH で接続確認</a></h3> <p> - 今の SSH セッションは閉じずに、ターミナルを別途開いて疎通確認する。 セッションを閉じてしまうと、SSH の設定に不備があった場合に締め出しをくらう。 + 今の SSH セッションは閉じずに、ターミナルを別途開いて疎通確認する。セッションを閉じてしまうと、SSH の設定に不備があった場合に締め出しをくらう。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ ssh teika</span></span></code></pre> @@ -303,7 +303,7 @@ <section id="section--outro"> <h2><a href="#section--outro">感想</a></h2> <p> - (業務でなく) 個人だと数年ぶりのサーバセットアップで、これだけでも割と時間を食ってしまった。 とはいえ式年遷宮は楽しいので、これからも定期的にやっていきたい。 コンテナデプロイにしたい気持ちもあるのだが、色々実験したい関係上、本物のサーバも欲しくはある。 次の式年遷宮では、手順の一部だけでも自動化したいところ。 + (業務でなく) 個人だと数年ぶりのサーバセットアップで、これだけでも割と時間を食ってしまった。とはいえ式年遷宮は楽しいので、これからも定期的にやっていきたい。コンテナデプロイにしたい気持ちもあるのだが、色々実験したい関係上、本物のサーバも欲しくはある。次の式年遷宮では、手順の一部だけでも自動化したいところ。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2022-11-19/phperkaigi-2023-unused-token-quiz-2/index.html b/vhosts/blog/public/posts/2022-11-19/phperkaigi-2023-unused-token-quiz-2/index.html index 5f1adda5..5a97f3f7 100644 --- a/vhosts/blog/public/posts/2022-11-19/phperkaigi-2023-unused-token-quiz-2/index.html +++ b/vhosts/blog/public/posts/2022-11-19/phperkaigi-2023-unused-token-quiz-2/index.html @@ -63,7 +63,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2023 年 3 月 23 日から 25 日にかけて開催予定 (記事執筆時点) の <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> において、 昨年と同様に、弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> からトークン問題を出題予定である。 + 2023 年 3 月 23 日から 25 日にかけて開催予定 (記事執筆時点) の <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> において、昨年と同様に、弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> からトークン問題を出題予定である。 </p> <p> 昨年のトークン問題の記事はこちら: <a href="/posts/2022-04-09/phperkaigi-2022-tokens/">PHPerKaigi 2022 トークン問題の解説</a> diff --git a/vhosts/blog/public/posts/2023-01-10/phperkaigi-2023-unused-token-quiz-3/index.html b/vhosts/blog/public/posts/2023-01-10/phperkaigi-2023-unused-token-quiz-3/index.html index 94a99322..48d04436 100644 --- a/vhosts/blog/public/posts/2023-01-10/phperkaigi-2023-unused-token-quiz-3/index.html +++ b/vhosts/blog/public/posts/2023-01-10/phperkaigi-2023-unused-token-quiz-3/index.html @@ -63,13 +63,13 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2023 年 3 月 23 日から 25 日にかけて開催予定 (記事執筆時点) の <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> において、 昨年と同様に、弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> からトークン問題を出題予定である。 + 2023 年 3 月 23 日から 25 日にかけて開催予定 (記事執筆時点) の <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> において、昨年と同様に、弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> からトークン問題を出題予定である。 </p> <p> 昨年のトークン問題の記事はこちら: <a href="/posts/2022-04-09/phperkaigi-2022-tokens/">PHPerKaigi 2022 トークン問題の解説</a> </p> <p> - すでに 2023 年用の問題は作成済みであるが、その制作過程の中でいくつかボツ問ができた。 せっかくなので、PHPerKaigi 開催を待つ間に紹介しようと思う。 + すでに 2023 年用の問題は作成済みであるが、その制作過程の中でいくつかボツ問ができた。せっかくなので、PHPerKaigi 開催を待つ間に紹介しようと思う。 </p> <p> 10 月から 2 月まで、毎月 1 記事ずつ公開していく予定 (忘れていなければ → 忘れていたので 12 月公開予定だった記事を今書いている)。 diff --git a/vhosts/blog/public/posts/2023-03-10/rewrite-this-blog-generator/index.html b/vhosts/blog/public/posts/2023-03-10/rewrite-this-blog-generator/index.html index 4443d31d..a0e6c642 100644 --- a/vhosts/blog/public/posts/2023-03-10/rewrite-this-blog-generator/index.html +++ b/vhosts/blog/public/posts/2023-03-10/rewrite-this-blog-generator/index.html @@ -54,7 +54,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - このブログを構築するシステムを書き直したのは 2度目である。 元々立ち上げた当初は、静的サイトジェネレータである <a href="https://gohugo.io/" rel="noreferrer" target="_blank">Hugo</a> を使っていた。 それを <a href="https://asciidoctor.org/" rel="noreferrer" target="_blank">Asciidoctor</a> にいくつかのカスタムを加えた自前のジェネレータに移行したのが 2022年の11月ごろだ。 そして今回、スクラッチから書いた <a href="https://deno.land/" rel="noreferrer" target="_blank">Deno</a> 製のジェネレータに移行した。 + このブログを構築するシステムを書き直したのは 2度目である。元々立ち上げた当初は、静的サイトジェネレータである <a href="https://gohugo.io/" rel="noreferrer" target="_blank">Hugo</a> を使っていた。それを <a href="https://asciidoctor.org/" rel="noreferrer" target="_blank">Asciidoctor</a> にいくつかのカスタムを加えた自前のジェネレータに移行したのが 2022年の11月ごろだ。そして今回、スクラッチから書いた <a href="https://deno.land/" rel="noreferrer" target="_blank">Deno</a> 製のジェネレータに移行した。 </p> <p> この記事では、移行の理由などを (主に将来の私へ向けて) 書き記しておく。 @@ -63,7 +63,7 @@ <section id="section--from-hugo-to-asciidoctor"> <h2><a href="#section--from-hugo-to-asciidoctor">Hugo から Asciidoctor へ</a></h2> <p> - 最初に断っておくと、Hugo は大変に優れた静的サイトジェネレータである。移行の理由の大半は、自分でジェネレータを書きたかったからに他ならない。 実のところ、この記事を執筆している現在、自作ジェネレータは Hugo よりも機能が劣っている。 例えば、Hugo を使っていたころはサポートしていた RSS フィードの生成は、まだ実装できていない。 + 最初に断っておくと、Hugo は大変に優れた静的サイトジェネレータである。移行の理由の大半は、自分でジェネレータを書きたかったからに他ならない。実のところ、この記事を執筆している現在、自作ジェネレータは Hugo よりも機能が劣っている。例えば、Hugo を使っていたころはサポートしていた RSS フィードの生成は、まだ実装できていない。 </p> <p> 移行先のフォーマットとして AsciiDoc を選んだのは、Markdown よりも表現力に優れるからである。Markdown は広く使われている軽量マークアップ言語だが、以下のような欠点を持つ。 @@ -117,7 +117,7 @@ フォーマットが求められた。これに合致したのが、XML をベースとする <a href="https://docbook.org/" rel="noreferrer" target="_blank">DocBook</a> (今回使っているのは、そのサブセットである <a href="https://tdg.docbook.org/tdg/sdocbook/5.1/" rel="noreferrer" target="_blank">Simplified DocBook</a> ) である。 </p> <p> - 実は、AsciiDoc と DocBook はおおよそ互換性がある。AsciiDoc で書かれた文書は (ほぼ) 情報ロスなしに DocBook へ変換でき、逆もまたしかりである。 よって、DocBook には、AsciiDoc と同等の表現力がある。 + 実は、AsciiDoc と DocBook はおおよそ互換性がある。AsciiDoc で書かれた文書は (ほぼ) 情報ロスなしに DocBook へ変換でき、逆もまたしかりである。よって、DocBook には、AsciiDoc と同等の表現力がある。 </p> <p> XML の文法の厳密さについては、説明するまでもないだろう。また、単純な文法であることから実装が容易であり、事実上 Asciidoctor へロックインされる AsciiDoc とは異なり、さまざまな言語で多くのライブラリが存在する。 @@ -126,16 +126,16 @@ 今回は、XML のパース自体も自分で書いている (これは何となく書きたかったからであり、合理的な理由があるわけではない。実装はサボりまくっているので XML のコメントが使えないといった制限がある)。 </p> <p> - XML という機械処理しやすいフォーマットを選ぶことには、機械的な変換や検査といった処理がおこないやすくなるといった利点もある。 欠点は軽量マークアップ言語と比べて冗長であることだが、書く際は補完などを用いるのでそれほど気にならない。 結局のところ、技術ブログの執筆を律速するのは調査と文章の記述であり、マークアップの手段は執筆時間に大した影響を与えない。 + XML という機械処理しやすいフォーマットを選ぶことには、機械的な変換や検査といった処理がおこないやすくなるといった利点もある。欠点は軽量マークアップ言語と比べて冗長であることだが、書く際は補完などを用いるのでそれほど気にならない。結局のところ、技術ブログの執筆を律速するのは調査と文章の記述であり、マークアップの手段は執筆時間に大した影響を与えない。 </p> </section> <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 2度のリライトを経て、記事のフォーマットとサイトジェネレータを上から下まで掌握した。 今後も改善のアイデアは多数あるので、じわじわと進めていきたいところだ。 + 2度のリライトを経て、記事のフォーマットとサイトジェネレータを上から下まで掌握した。今後も改善のアイデアは多数あるので、じわじわと進めていきたいところだ。 </p> <p> - 最後にもう一度書くのだが、Hugo は大変に優れた静的サイトジェネレータである。 無駄な拘りがなければこれを使うとよい。 私は無駄に拘ったので、ブログの記事を書く時間を潰してブログシステムを作ってしまった。 + 最後にもう一度書くのだが、Hugo は大変に優れた静的サイトジェネレータである。無駄な拘りがなければこれを使うとよい。私は無駄に拘ったので、ブログの記事を書く時間を潰してブログシステムを作ってしまった。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2023-04-01/implementation-of-minimal-png-image-encoder/index.html b/vhosts/blog/public/posts/2023-04-01/implementation-of-minimal-png-image-encoder/index.html index 22af315a..ff7e58c7 100644 --- a/vhosts/blog/public/posts/2023-04-01/implementation-of-minimal-png-image-encoder/index.html +++ b/vhosts/blog/public/posts/2023-04-01/implementation-of-minimal-png-image-encoder/index.html @@ -54,7 +54,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - この記事では、PNG 画像として valid な範囲で最大限手抜きしたエンコーダを書く。 PNG 画像に対応したビューアであれば読み込めるが、圧縮効率については一切考えない。 また、実装には Go 言語を使うが、Go の標準ライブラリにあるさまざまなアルゴリズム (PNG 画像に関係する範囲だと、zlib や CRC32、Adler-32 など) は使わない。 + この記事では、PNG 画像として valid な範囲で最大限手抜きしたエンコーダを書く。PNG 画像に対応したビューアであれば読み込めるが、圧縮効率については一切考えない。また、実装には Go 言語を使うが、Go の標準ライブラリにあるさまざまなアルゴリズム (PNG 画像に関係する範囲だと、zlib や CRC32、Adler-32 など) は使わない。 </p> </section> <section id="section--basic-structure-of-png"> @@ -77,7 +77,7 @@ </li> </ol> <p> - Chunk には画像データを入れる IDAT chunk、パレットデータを入れる PLTE chunk、テキストデータを入れる tEXt chunk などがあるが、 今回は最小構成ということで IDAT chunk (と IHDR chunk と IEND chunk) のみを用いる。 + Chunk には画像データを入れる IDAT chunk、パレットデータを入れる PLTE chunk、テキストデータを入れる tEXt chunk などがあるが、今回は最小構成ということで IDAT chunk (と IHDR chunk と IEND chunk) のみを用いる。 </p> <p> 次節で、それぞれの具体的な構造を確認しつつ実装していく。 @@ -86,7 +86,7 @@ <section id="section--implement-png-encoder"> <h2><a href="#section--implement-png-encoder">PNG のエンコーダを実装する</a></h2> <p> - 以下のソースコードをベースにする。 今回 PNG のデコーダは扱わないので、読み込みには Go の標準ライブラリ <code>image/png</code> を用いる。 + 以下のソースコードをベースにする。今回 PNG のデコーダは扱わないので、読み込みには Go の標準ライブラリ <code>image/png</code> を用いる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">package</span><span style="color:#6F42C1"> main</span></span> @@ -263,7 +263,7 @@ <span class="line"><span style="color:#24292E">}</span></span></code></pre> </div> <p> - 仕様どおり、<code>chunkType</code> と <code>data</code> から CRC を計算し、<code>data</code> の長さと合わせて書き込んでいる。 PNG では基本的に big endian を使うことに注意する。 + 仕様どおり、<code>chunkType</code> と <code>data</code> から CRC を計算し、<code>data</code> の長さと合わせて書き込んでいる。PNG では基本的に big endian を使うことに注意する。 </p> <p> 準備ができたところで、具体的な chunk をエンコードしていく。 @@ -455,10 +455,10 @@ <section id="section--implement-png-encoder--idat-chunk--image-data"> <h4><a href="#section--implement-png-encoder--idat-chunk--image-data">画像データ</a></h4> <p> - では次に、zlib 形式で格納するデータを用意する。PNG 画像は次のような順にスキャンする。 画像の左上のピクセルから同じ行を横にスキャンしていき、一番右まで到達したら次の行の左に向かう。 右下のピクセルまで行けば終わり。要は Z 字型に進んでいく。 + では次に、zlib 形式で格納するデータを用意する。PNG 画像は次のような順にスキャンする。画像の左上のピクセルから同じ行を横にスキャンしていき、一番右まで到達したら次の行の左に向かう。右下のピクセルまで行けば終わり。要は Z 字型に進んでいく。 </p> <p> - また、それぞれの行の先頭には、圧縮のためのフィルタタイプを指定する。 ただ、今回はその実装を省略するために、常にフィルタ 0 (何も加工しない) を使う。 + また、それぞれの行の先頭には、圧縮のためのフィルタタイプを指定する。ただ、今回はその実装を省略するために、常にフィルタ 0 (何も加工しない) を使う。 </p> <p> 先ほどの <code>encodeZlib</code> も使って実際に実装したものがこちら: diff --git a/vhosts/blog/public/posts/2023-04-04/phperkaigi-2023-report/index.html b/vhosts/blog/public/posts/2023-04-04/phperkaigi-2023-report/index.html index b2a5bcd8..da788f05 100644 --- a/vhosts/blog/public/posts/2023-04-04/phperkaigi-2023-report/index.html +++ b/vhosts/blog/public/posts/2023-04-04/phperkaigi-2023-report/index.html @@ -69,7 +69,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2023-03-23 から 2023-03-25 にかけて開催された、 <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> に参加した。 今年は 2つのセッションのスピーカーとして、また、当日スタッフとして参加した。 + 2023-03-23 から 2023-03-25 にかけて開催された、 <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> に参加した。今年は 2つのセッションのスピーカーとして、また、当日スタッフとして参加した。 </p> <p> 昨年、一昨年の参加レポはこちら: @@ -119,16 +119,16 @@ </li> </ul> <p> - PHPer チャレンジの話については後述する。 参照については、PHP を書き始めた頃からずっと疑問に思っていたので、仕組みを理解する良い機会となった。 + PHPer チャレンジの話については後述する。参照については、PHP を書き始めた頃からずっと疑問に思っていたので、仕組みを理解する良い機会となった。 </p> </section> <section id="section--as-staff"> <h2><a href="#section--as-staff">当日スタッフとして</a></h2> <p> - 今回はスピーカーのみならず当日スタッフとしても参加した。 カンファレンスのスタッフとしての参加は初めてだったが、初参加のスタッフでもスムーズに作業ができるような仕組みが整えられていた。 + 今回はスピーカーのみならず当日スタッフとしても参加した。カンファレンスのスタッフとしての参加は初めてだったが、初参加のスタッフでもスムーズに作業ができるような仕組みが整えられていた。 </p> <p> - PHPerKaigi は一般参加者の目線でもよくできたカンファレンスだなあという印象だったのだが、よりその思いを強くした。 なんとスタッフにとってもよくできたカンファレンスなのである。 + PHPerKaigi は一般参加者の目線でもよくできたカンファレンスだなあという印象だったのだが、よりその思いを強くした。なんとスタッフにとってもよくできたカンファレンスなのである。 </p> <p> 反省点は私自身の最大 HP がまったく足りていなかったことで、次の機会には最後まで動けるようにしたいところである。 @@ -145,7 +145,7 @@ <a href="https://fortee.jp/phperkaigi-2023/proposal/f7f2f18a-e6b0-47e4-ade0-e324f72428ae" rel="noreferrer" target="_blank">ブラウザの向こう側で「200 OK」を返すまでに何が起きているのか調べてみた</a> </p> <p> - Web に関わるなら、バックエンドでもフロントエンドでも知っておいてほしい知識。 タイトルを見て「こんな話だろうな」と想像がつくレベルなら見なくてもいいかも。 + Web に関わるなら、バックエンドでもフロントエンドでも知っておいてほしい知識。タイトルを見て「こんな話だろうな」と想像がつくレベルなら見なくてもいいかも。 </p> <p> <a href="https://fortee.jp/phperkaigi-2023/proposal/280706e0-7158-4237-8202-c9d64330b96f" rel="noreferrer" target="_blank">PHPで学ぶ “Cacheの距離” の話</a> @@ -163,22 +163,22 @@ <a href="https://fortee.jp/phperkaigi-2023/proposal/e00788a4-ef25-49ee-b254-9d2b53e19633" rel="noreferrer" target="_blank">PHPの最高機能、配列を捨てよう！！</a> </p> <p> - 実はこれも上のセッションと同様の話。 PHP の静的解析ツールは配列にも (無理矢理) 型が付けられるものが多いが、実行時にも検査できるという点において専用のクラスを作る方が優れている。 + 実はこれも上のセッションと同様の話。PHP の静的解析ツールは配列にも (無理矢理) 型が付けられるものが多いが、実行時にも検査できるという点において専用のクラスを作る方が優れている。 </p> <p> <a href="https://fortee.jp/phperkaigi-2023/proposal/7e212cb2-be37-43e8-b6ee-5236d259fcbf" rel="noreferrer" target="_blank">時間を気にせず普通にカンニングもしつつ ISUCON12 本選問題を PHP でやってみる</a> </p> <p> - 個人的に最も楽しみにしていたセッションであり、今回のモリアガリトーク賞 (盛り上がったセッションに運営側から贈られる賞) でもある。 ネタバレになるが、最終的に (Go で実装された) 本戦優勝スコアを超えている。 + 個人的に最も楽しみにしていたセッションであり、今回のモリアガリトーク賞 (盛り上がったセッションに運営側から贈られる賞) でもある。ネタバレになるが、最終的に (Go で実装された) 本戦優勝スコアを超えている。 </p> </section> <section id="section--as-attendee--phper-challenge"> <h3><a href="#section--as-attendee--phper-challenge">PHPer チャレンジ</a></h3> <p> - 昨年に引き続き、弊社デジタルサーカス株式会社からのトークン問題の作題を担当した。 また、今年はさらに作成した問題を解説するセッションにも登壇した。 今年のトークンは、昨年の PHPerKaigi 2022 が終わった段階から作り始め、約半年かけて制作した。 + 昨年に引き続き、弊社デジタルサーカス株式会社からのトークン問題の作題を担当した。また、今年はさらに作成した問題を解説するセッションにも登壇した。今年のトークンは、昨年の PHPerKaigi 2022 が終わった段階から作り始め、約半年かけて制作した。 </p> <p> - 問題の制作中は大変楽しかったが、まあやりすぎた。 いかに超絶技巧を凝らすかに注力してしまい、解く楽しさという観点を失ってしまったきらいがある。 + 問題の制作中は大変楽しかったが、まあやりすぎた。いかに超絶技巧を凝らすかに注力してしまい、解く楽しさという観点を失ってしまったきらいがある。 </p> <p> (WIP: 解説ブログ記事執筆中。終わったらここにリンク) @@ -239,13 +239,13 @@ </ul> </blockquote> <p> - プロポーザルに関しては採択されて登壇できたし、PHPer チャレンジは解説もおこなった。また、現地に行くだけでなく、当日スタッフとして参加した。 4つ目の PHPer チャレンジに関しては、今年は参加していない。 スタッフをやりながらだと入力する時間も探す時間も取れそうになかったのと、スタッフをやっている関係で少しだけ早く入手してしまうトークンがいくつか存在していたため。 + プロポーザルに関しては採択されて登壇できたし、PHPer チャレンジは解説もおこなった。また、現地に行くだけでなく、当日スタッフとして参加した。4つ目の PHPer チャレンジに関しては、今年は参加していない。スタッフをやりながらだと入力する時間も探す時間も取れそうになかったのと、スタッフをやっている関係で少しだけ早く入手してしまうトークンがいくつか存在していたため。 </p> <p> カンファレンス全体の感想についてだが、大規模なカンファレンスにオフラインで参加するのは今回が初めてだったので、その話をしたい。 </p> <p> - オンラインとオフラインだと体験が別物になる。そもそもが似て非なるものなのだ。 向き不向きはあるだろうが、オンラインしか参加したことのないという方は、一度現地参加してみてはいかがだろうか。 + オンラインとオフラインだと体験が別物になる。そもそもが似て非なるものなのだ。向き不向きはあるだろうが、オンラインしか参加したことのないという方は、一度現地参加してみてはいかがだろうか。 </p> <p> さて、参加レポは去年も一昨年もこの言葉で締め括っているので、今年もそれで終わろうと思う。 diff --git a/vhosts/blog/public/posts/2023-06-25/phpconfuk-2023-report/index.html b/vhosts/blog/public/posts/2023-06-25/phpconfuk-2023-report/index.html index 86fad30f..cba287cb 100644 --- a/vhosts/blog/public/posts/2023-06-25/phpconfuk-2023-report/index.html +++ b/vhosts/blog/public/posts/2023-06-25/phpconfuk-2023-report/index.html @@ -66,7 +66,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2023-06-24 に開催された、 <a href="https://phpcon.fukuoka.jp/2023/" rel="noreferrer" target="_blank">PHP カンファレンス福岡 2023</a> に参加した。 また、その前日に催された、 <a href="https://connpass.com/event/282285/" rel="noreferrer" target="_blank">非公式の前夜祭</a> にも参加した。 前夜祭では、15分の登壇もおこなった。 <a href="/slides/2023-06-23/phpconfuk-2023-eve/">登壇の方の資料はこちら。</a> + 2023-06-24 に開催された、 <a href="https://phpcon.fukuoka.jp/2023/" rel="noreferrer" target="_blank">PHP カンファレンス福岡 2023</a> に参加した。また、その前日に催された、 <a href="https://connpass.com/event/282285/" rel="noreferrer" target="_blank">非公式の前夜祭</a> にも参加した。前夜祭では、15分の登壇もおこなった。 <a href="/slides/2023-06-23/phpconfuk-2023-eve/">登壇の方の資料はこちら。</a> </p> </section> <section id="section--sessions-thoughts"> @@ -142,7 +142,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 居住地域から離れた場所への遠征参加は初めてだったが、大変楽しい (しかも勉強にもなる！) 体験だった。 受け取った「熱」が冷める前に、自らの手を動かしていきたい。 + 居住地域から離れた場所への遠征参加は初めてだったが、大変楽しい (しかも勉強にもなる！) 体験だった。受け取った「熱」が冷める前に、自らの手を動かしていきたい。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html b/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html index c17bc163..bd286a6d 100644 --- a/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html +++ b/vhosts/blog/public/posts/2023-10-02/compile-php-runtime-to-wasm/index.html @@ -101,7 +101,7 @@ <section id="section--goal"> <h2><a href="#section--goal">本記事のゴール</a></h2> <p> - 先にこの記事のゴールを示しておく。これから示す手順のとおりに進めると、次のようなコードが動くようになる。 このコードはこのあと使うので、<code>index.mjs</code> の名前で保存しておくこと。 + 先にこの記事のゴールを示しておく。これから示す手順のとおりに進めると、次のようなコードが動くようになる。このコードはこのあと使うので、<code>index.mjs</code> の名前で保存しておくこと。 </p> <div class="codeblock"> <div class="filename"> @@ -161,10 +161,10 @@ ほとんどはただの PHP の公開 API を使ったコードだが、Emscripten 向けの注意点が 2点ある。 </p> <p> - まずは <code>EMSCRIPTEN_KEEPALIVE</code> について。 これは Emscripten が用意している特殊なマクロである。 このマクロが付与されている関数は、どこからも使用されていなくともコンパイル後の WebAssembly バイナリから削除されない。 もしこれを付け忘れると、未使用の関数とみなされ削除される。 + まずは <code>EMSCRIPTEN_KEEPALIVE</code> について。これは Emscripten が用意している特殊なマクロである。このマクロが付与されている関数は、どこからも使用されていなくともコンパイル後の WebAssembly バイナリから削除されない。もしこれを付け忘れると、未使用の関数とみなされ削除される。 </p> <p> - 次に、コードを評価したあとに呼んでいる標準出力と標準エラー出力に対する改行の出力について。 出力バッファから出力させるためだけなら改行を出力させなくとも <code>fflush()</code> だけで事足りると考えたのだが、ないと動かなかったので追加した。 これにより、PHP コードの出力の後ろに余分な改行が追加されてしまう。 改行を出力せずともバッファを消費させる手段をご存知のかたはご教示願いたい。 + 次に、コードを評価したあとに呼んでいる標準出力と標準エラー出力に対する改行の出力について。出力バッファから出力させるためだけなら改行を出力させなくとも <code>fflush()</code> だけで事足りると考えたのだが、ないと動かなかったので追加した。これにより、PHP コードの出力の後ろに余分な改行が追加されてしまう。改行を出力せずともバッファを消費させる手段をご存知のかたはご教示願いたい。 </p> <div class="admonition" editat="2025-04-23" operation="追記"> <div class="admonition-label"> @@ -172,7 +172,7 @@ </div> <div class="admonition-content"> <p> - <code>fflush()</code> の前に改行の出力が必要だった理由が判明したので追記する。 これは、<code>index.mjs</code> で標準出力・標準エラー出力へ出力する方法を指定せず、デフォルトの実装に任せているため。 Emscripten のデフォルト実装では、改行コードを出力するまで出力内容がバッファリングされ、<code>fflush()</code> が機能しない。 + <code>fflush()</code> の前に改行の出力が必要だった理由が判明したので追記する。これは、<code>index.mjs</code> で標準出力・標準エラー出力へ出力する方法を指定せず、デフォルトの実装に任せているため。Emscripten のデフォルト実装では、改行コードを出力するまで出力内容がバッファリングされ、<code>fflush()</code> が機能しない。 </p> <p> デフォルトの出力方法は <code>index.mjs</code> の中で <code>PHPWasm()</code> を呼ぶとき、<code>stdout</code>・<code>stderr</code> というオプションを渡せば変更できる。 @@ -209,7 +209,7 @@ <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">FROM</span><span style="color:#24292E"> emscripten/emsdk:3.1.46 </span><span style="color:#D73A49">AS</span><span style="color:#24292E"> wasm-builder</span></span></code></pre> </div> <p> - 次に、 <a href="https://github.com/php/php-src" rel="noreferrer" target="_blank">php/php-src</a> から PHP 処理系のソースコードを取得し、ビルドに必要な apt パッケージを取ってくる。 有効にする拡張を増やしたいなら、ここでインストールするパッケージも増やすことになるだろう。 + 次に、 <a href="https://github.com/php/php-src" rel="noreferrer" target="_blank">php/php-src</a> から PHP 処理系のソースコードを取得し、ビルドに必要な apt パッケージを取ってくる。有効にする拡張を増やしたいなら、ここでインストールするパッケージも増やすことになるだろう。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">RUN</span><span style="color:#24292E"> git clone --depth=1 --branch=php-8.2.10 https://github.com/php/php-src</span></span> @@ -254,22 +254,22 @@ ここまでと比べると少し複雑なので、それぞれ詳しく見ていこう。 </p> <p> - まず、<code>buildconf</code> は PHP 処理系をビルドするときに (Emscripten とは関係なく) 使うツールである。 このツールの最も重要な仕事は、<code>configure</code> の生成である。 + まず、<code>buildconf</code> は PHP 処理系をビルドするときに (Emscripten とは関係なく) 使うツールである。このツールの最も重要な仕事は、<code>configure</code> の生成である。 </p> <p> - 次に <code>configure</code> するわけだが、ここで <code>emconfigure</code> を使う。 これを使うことで、Emscripten が上手く諸々のツールチェインを WebAssembly のビルド向けに調整しながら <code>configure</code> してくれる。 + 次に <code>configure</code> するわけだが、ここで <code>emconfigure</code> を使う。これを使うことで、Emscripten が上手く諸々のツールチェインを WebAssembly のビルド向けに調整しながら <code>configure</code> してくれる。 </p> <p> - <code>configure</code> の後ろに指定してあるフラグは、通常の PHP 処理系のビルドで使う <code>configure</code> と同じなので、詳しくはそちらの <code>cofigure --help</code> を参照していただきたい。 ほとんどは、機能の無効化のために指定している (依存するライブラリを減らし、ビルドをより簡単にするため)。 + <code>configure</code> の後ろに指定してあるフラグは、通常の PHP 処理系のビルドで使う <code>configure</code> と同じなので、詳しくはそちらの <code>cofigure --help</code> を参照していただきたい。ほとんどは、機能の無効化のために指定している (依存するライブラリを減らし、ビルドをより簡単にするため)。 </p> <p> - 通常の C のビルドなら、<code>configure</code> の次は <code>make</code> するところだが、ここでも <code>emmake</code> を使う。 役割はほとんど <code>emconfigure</code> と同様である。 指定してある <code>EMCC_CFLAGS</code> という環境変数は、Emscripten の C コンパイラへのフラグで、ここでは <code>ERROR_ON_UNDEFINED_SYMBOLS</code> を無効化している。 これにより、コンパイル中に出現した解決できなかったシンボルを無視するようになる (代わりに、そのシンボルを呼ぼうとしたタイミングで実行時エラーになる)。 すべての依存を完全に解決するのは面倒なので、あまり使わない機能については無視してもよいだろう。 + 通常の C のビルドなら、<code>configure</code> の次は <code>make</code> するところだが、ここでも <code>emmake</code> を使う。役割はほとんど <code>emconfigure</code> と同様である。指定してある <code>EMCC_CFLAGS</code> という環境変数は、Emscripten の C コンパイラへのフラグで、ここでは <code>ERROR_ON_UNDEFINED_SYMBOLS</code> を無効化している。これにより、コンパイル中に出現した解決できなかったシンボルを無視するようになる (代わりに、そのシンボルを呼ぼうとしたタイミングで実行時エラーになる)。すべての依存を完全に解決するのは面倒なので、あまり使わない機能については無視してもよいだろう。 </p> <p> ここまでを実行すると <code>libs/libphp.a</code> が生成される。これは後で使うので移動させている。 </p> <p> - さて、PHP 処理系をライブラリ化できたので、次に先ほど載せた C のソースコードをビルドしていこう。 <code>Dockerfile</code> と同じ場所に <code>php-wasm.c</code> という名前で保存し、次のようにする。 + さて、PHP 処理系をライブラリ化できたので、次に先ほど載せた C のソースコードをビルドしていこう。<code>Dockerfile</code> と同じ場所に <code>php-wasm.c</code> という名前で保存し、次のようにする。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">COPY</span><span style="color:#24292E"> php-wasm.c /src/</span></span> @@ -290,10 +290,10 @@ <span class="line"><span style="color:#24292E"> :</span></span></code></pre> </div> <p> - <code>emcc</code> は <code>cc</code> (C コンパイラ/リンカ) の Emscripten 版で、<code>-c</code> は「コンパイル」の意。 <code>-o</code> や <code>-I</code> は普通の C コンパイラと同様、出力ファイルの指定とインクルードパスの指定である。 + <code>emcc</code> は <code>cc</code> (C コンパイラ/リンカ) の Emscripten 版で、<code>-c</code> は「コンパイル」の意。<code>-o</code> や <code>-I</code> は普通の C コンパイラと同様、出力ファイルの指定とインクルードパスの指定である。 </p> <p> - <code>libphp.a</code> と <code>php-wasm.o</code> が手に入ったので、これらをリンクして WebAssembly のバイナリとそのラッパである JavaScript ファイルを生成する。 これにも <code>emcc</code> コマンドを使う。 + <code>libphp.a</code> と <code>php-wasm.o</code> が手に入ったので、これらをリンクして WebAssembly のバイナリとそのラッパである JavaScript ファイルを生成する。これにも <code>emcc</code> コマンドを使う。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">RUN</span><span style="color:#24292E"> emcc \</span></span> @@ -313,31 +313,31 @@ それぞれのフラグについて解説する。 </p> <p> - <code>-s ENVIRONMENT=node</code> は、生成する WebAssembly/JavaScript の実行環境を指定する。 今回は <code>node</code> を指定しているので、Node.js 向けのファイルが生成される。 + <code>-s ENVIRONMENT=node</code> は、生成する WebAssembly/JavaScript の実行環境を指定する。今回は <code>node</code> を指定しているので、Node.js 向けのファイルが生成される。 </p> <p> <code>-s ERROR_ON_UNDEFINED_SYMBOLS=0</code> についてはすでに述べたので省略する。 </p> <p> - <code>-s EXPORTED_RUNTIME_METHODS='["ccall"]'</code> は、生成される JavaScript から公開される API である。 すでに <code>index.mjs</code> で使用しているが、<code>ccall('関数名', '返り値の型', ['仮引数の型', ...], ['実引数', ...])</code> のように使う。 + <code>-s EXPORTED_RUNTIME_METHODS='["ccall"]'</code> は、生成される JavaScript から公開される API である。すでに <code>index.mjs</code> で使用しているが、<code>ccall('関数名', '返り値の型', ['仮引数の型', ...], ['実引数', ...])</code> のように使う。 </p> <p> - <code>-s EXPORT_ES6=1</code> は、JavaScript コードを ECMAScript 6 に準拠した module として生成する。 これを指定することで、<code>require()</code> ではなく <code>import</code> できる JavaScript を生成させられる。 + <code>-s EXPORT_ES6=1</code> は、JavaScript コードを ECMAScript 6 に準拠した module として生成する。これを指定することで、<code>require()</code> ではなく <code>import</code> できる JavaScript を生成させられる。 </p> <p> <code>-s INITIAL_MEMORY=16777216</code> は呼んで字のごとく。用途に合わせて適当に決めてほしい。 </p> <p> - <code>-s INVOKE_RUN=0</code> は、module をロードしたときに勝手に <code>main()</code> を呼ぶかどうか (だと思う)。 今回は <code>php_wasm_run()</code> しか使うつもりがないので切っている。 + <code>-s INVOKE_RUN=0</code> は、module をロードしたときに勝手に <code>main()</code> を呼ぶかどうか (だと思う)。今回は <code>php_wasm_run()</code> しか使うつもりがないので切っている。 </p> <p> - <code>-s MODULARIZE=1</code> は、実質的にほぼ必須のオプションであり、1 を指定することで「WebAssembly module をインスタンス化する関数」をエクスポートするような JavaScript ファイルを生成するようになる。 これを指定しないと、生成物の JavaScript ファイルを読み込むと WebAssembly module が即座にインスタンス化されてしまい、起動のタイミングを制御できない。 + <code>-s MODULARIZE=1</code> は、実質的にほぼ必須のオプションであり、1 を指定することで「WebAssembly module をインスタンス化する関数」をエクスポートするような JavaScript ファイルを生成するようになる。これを指定しないと、生成物の JavaScript ファイルを読み込むと WebAssembly module が即座にインスタンス化されてしまい、起動のタイミングを制御できない。 </p> <p> - ここまで実行すると、<code>php-wasm.js</code> と <code>php-wasm.wasm</code> が作られる。 では、ここからはこれらの実行環境を作っていこう。 + ここまで実行すると、<code>php-wasm.js</code> と <code>php-wasm.wasm</code> が作られる。では、ここからはこれらの実行環境を作っていこう。 </p> <p> - といっても、Node.js はビルトインで WebAssembly をサポートしているので、ほとんどやることはない。 先ほど掲載した JavaScript のコードは、<code>Dockerfile</code> と同じディレクトリに <code>index.mjs</code> で配置すること。 + といっても、Node.js はビルトインで WebAssembly をサポートしているので、ほとんどやることはない。先ほど掲載した JavaScript のコードは、<code>Dockerfile</code> と同じディレクトリに <code>index.mjs</code> で配置すること。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">FROM</span><span style="color:#24292E"> node:20.7</span></span> @@ -368,7 +368,7 @@ <section id="section--outro"> <h2><a href="#section--outro">まとめ</a></h2> <p> - <a href="https://github.com/nsfisis/tiny-php.wasm" rel="noreferrer" target="_blank">ここまでをまとめた Git リポジトリ</a> を用意した。 簡単にコンパイルできるので、興味があれば試してみてほしい。 + <a href="https://github.com/nsfisis/tiny-php.wasm" rel="noreferrer" target="_blank">ここまでをまとめた Git リポジトリ</a> を用意した。簡単にコンパイルできるので、興味があれば試してみてほしい。 </p> </section> <section id="section--references"> diff --git a/vhosts/blog/public/posts/2023-10-13/i-entered-the-open-university-of-japan/index.html b/vhosts/blog/public/posts/2023-10-13/i-entered-the-open-university-of-japan/index.html index 6cd37645..99656273 100644 --- a/vhosts/blog/public/posts/2023-10-13/i-entered-the-open-university-of-japan/index.html +++ b/vhosts/blog/public/posts/2023-10-13/i-entered-the-open-university-of-japan/index.html @@ -60,7 +60,7 @@ <section id="section--i-entered-ouj"> <h2><a href="#section--i-entered-ouj">放送大学に入学しました</a></h2> <p> - とあるきっかけがあり、もう一度大学生をすることにしました。 仕事のほうも、これまでどおりフルタイムで続けていきます。 + とあるきっかけがあり、もう一度大学生をすることにしました。仕事のほうも、これまでどおりフルタイムで続けていきます。 </p> <p> 黙っているよりも公表したほうがモチベーションの向上に繋がるだろうと思い、このブログに記事として載せました。 diff --git a/vhosts/blog/public/posts/2023-12-03/isucon-13/index.html b/vhosts/blog/public/posts/2023-12-03/isucon-13/index.html index 721b6c90..077d873c 100644 --- a/vhosts/blog/public/posts/2023-12-03/isucon-13/index.html +++ b/vhosts/blog/public/posts/2023-12-03/isucon-13/index.html @@ -60,7 +60,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 先日 11月25日、 <a href="https://isucon.net/archives/57801192.html" rel="noreferrer" target="_blank">ISUCON 13</a> に参加した。 ISUCON への参加は今回が初めてとなる。 私 nsfisis の1人チーム「うつしもゆ」として参加し、最終スコアは 13,580 点だった。使用言語は Go。 + 先日 11月25日、 <a href="https://isucon.net/archives/57801192.html" rel="noreferrer" target="_blank">ISUCON 13</a> に参加した。ISUCON への参加は今回が初めてとなる。私 nsfisis の1人チーム「うつしもゆ」として参加し、最終スコアは 13,580 点だった。使用言語は Go。 </p> <div class="admonition"> <div class="admonition-label"> @@ -100,12 +100,12 @@ <section id="section--strategy"> <h2><a href="#section--strategy">戦略</a></h2> <p> - ISUCON で高スコアを出す戦略については、戦闘力の高い方々が良質な記事を書いてくださっている。 ここでは、上述したような低い目標を達成するための戦略について書こうと思う。 + ISUCON で高スコアを出す戦略については、戦闘力の高い方々が良質な記事を書いてくださっている。ここでは、上述したような低い目標を達成するための戦略について書こうと思う。 </p> <section id="section--strategy--do-not-destroy-environment"> <h3><a href="#section--strategy--do-not-destroy-environment">環境を破壊しない</a></h3> <p> - ミドルウェアの設定やアプリケーションコードなど、変更を加えるあらゆるものは、必ずバックアップを取るか Git で管理する。 復旧不能になって環境ごと作り直すことだけは必ず避ける。 + ミドルウェアの設定やアプリケーションコードなど、変更を加えるあらゆるものは、必ずバックアップを取るか Git で管理する。復旧不能になって環境ごと作り直すことだけは必ず避ける。 </p> </section> <section id="section--strategy--revert-changes-immediately"> @@ -123,7 +123,7 @@ <section id="section--strategy--use-familiar-tools"> <h3><a href="#section--strategy--use-familiar-tools">使い慣れた道具を使う</a></h3> <p> - 使用する言語、ミドルウェア、ツール類を、使い慣れたものに限定する。 「このツールのオプションはほとんどそらで指定できる」と言えるようなものだけを使う。 「自分では使ったことがないが ISUCON 強者がお勧めしていた」といった理由でツールを選定しない (もちろん、本番までに練習して習熟するという選択肢は存在する)。 + 使用する言語、ミドルウェア、ツール類を、使い慣れたものに限定する。「このツールのオプションはほとんどそらで指定できる」と言えるようなものだけを使う。「自分では使ったことがないが ISUCON 強者がお勧めしていた」といった理由でツールを選定しない (もちろん、本番までに練習して習熟するという選択肢は存在する)。 </p> </section> </section> diff --git a/vhosts/blog/public/posts/2023-12-31/2023-reflections/index.html b/vhosts/blog/public/posts/2023-12-31/2023-reflections/index.html index 86248d17..b3717000 100644 --- a/vhosts/blog/public/posts/2023-12-31/2023-reflections/index.html +++ b/vhosts/blog/public/posts/2023-12-31/2023-reflections/index.html @@ -60,7 +60,7 @@ <section id="section--conferences"> <h2><a href="#section--conferences">登壇・カンファレンススタッフ</a></h2> <p> - 勉強会やカンファレンスで登壇したりスタッフをしたりし始めたのは今年かららしい。 LT 等も含めて計 11 回の登壇をおこなった。 + 勉強会やカンファレンスで登壇したりスタッフをしたりし始めたのは今年かららしい。LT 等も含めて計 11 回の登壇をおこなった。 </p> <ul> <li> @@ -117,7 +117,7 @@ <section id="section--articles"> <h2><a href="#section--articles">書いた記事</a></h2> <p> - 登壇が増えたためか記事を書く機会が減ってしまった。 特に社内記事の本数が大きく減少しており、一昨年は約 100 本、昨年は約 60 本の社内記事を書いていたが、今年は 30 本強に留まった。 その頃と比べると文章を書く筋肉が衰えているように感じる。 + 登壇が増えたためか記事を書く機会が減ってしまった。特に社内記事の本数が大きく減少しており、一昨年は約 100 本、昨年は約 60 本の社内記事を書いていたが、今年は 30 本強に留まった。その頃と比べると文章を書く筋肉が衰えているように感じる。 </p> <ul> <li> diff --git a/vhosts/blog/public/posts/2024-01-10/neovim-insert-namespace-declaration-to-empty-php-file/index.html b/vhosts/blog/public/posts/2024-01-10/neovim-insert-namespace-declaration-to-empty-php-file/index.html index 26724deb..2ed2dd3a 100644 --- a/vhosts/blog/public/posts/2024-01-10/neovim-insert-namespace-declaration-to-empty-php-file/index.html +++ b/vhosts/blog/public/posts/2024-01-10/neovim-insert-namespace-declaration-to-empty-php-file/index.html @@ -90,25 +90,25 @@ <span class="line"><span>LuaJIT 2.1.1693350652</span></span></code></pre> </div> <p> - 今回は Lua で処理を記述したため、Vim では動作しない。以下の説明でも Neovim に絞って述べる。 また、パス区切りがスラッシュである前提で記述したため、Windows には対応していない。 + 今回は Lua で処理を記述したため、Vim では動作しない。以下の説明でも Neovim に絞って述べる。また、パス区切りがスラッシュである前提で記述したため、Windows には対応していない。 </p> </section> <section id="section--ftplugin"> <h2><a href="#section--ftplugin">ftplugin を用意する</a></h2> <p> - Neovim には特定のファイルタイプに対して特別な処理をおこなうための ftplugin と呼ばれる仕組みがある。 Neovim の設定を置くディレクトリ (例えば <code>~/.config/nvim</code>) の配下に <code>ftplugin/<FILE_TYPE>.vim</code> または <code>ftplugin/<FILE_TYPE>.lua</code> というファイルを配置すると、その <code><FILE_TYPE></code> が読み込まれたときにそのファイルが自動的に実行される。 + Neovim には特定のファイルタイプに対して特別な処理をおこなうための ftplugin と呼ばれる仕組みがある。Neovim の設定を置くディレクトリ (例えば <code>~/.config/nvim</code>) の配下に <code>ftplugin/<FILE_TYPE>.vim</code> または <code>ftplugin/<FILE_TYPE>.lua</code> というファイルを配置すると、その <code><FILE_TYPE></code> が読み込まれたときにそのファイルが自動的に実行される。 </p> <p> 今回は、Neovim がデフォルトで用意している PHP 用 ftplugin が動作したあとに追加の処理をおこないたいので、<code>after/ftplugin/php.{vim,lua}</code> というファイルを配置する。名前から察せられるとおり、<code>after/ftplugin</code> 以下のファイルは <code>ftplugin</code> 以下のファイルよりもあとに実行される。 </p> <p> - この記事では Lua で処理を記述するため、拡張子には <code>.lua</code> を用いる。 これ以降載せるコードは、すべて <code>after/ftplugin/php.lua</code> の中に記述している。 + この記事では Lua で処理を記述するため、拡張子には <code>.lua</code> を用いる。これ以降載せるコードは、すべて <code>after/ftplugin/php.lua</code> の中に記述している。 </p> </section> <section id="section--did-ftplugin"> <h2><a href="#section--did-ftplugin">二重読み込みを防ぐ</a></h2> <p> - ファイルタイプは読み込んだあとに変更されることもあるので、ftplugin は複数回実行されうる。 二重読み込みを防ぐために、<code>did_ftplugin_<FILE_TYPE>_after</code> というバッファローカル変数を定義しておくのが慣習となっている。 + ファイルタイプは読み込んだあとに変更されることもあるので、ftplugin は複数回実行されうる。二重読み込みを防ぐために、<code>did_ftplugin_<FILE_TYPE>_after</code> というバッファローカル変数を定義しておくのが慣習となっている。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49">if</span><span style="color:#24292E"> vim.</span><span style="color:#6F42C1">b</span><span style="color:#24292E">.</span><span style="color:#6F42C1">did_ftplugin_php_after</span><span style="color:#D73A49"> then</span></span> @@ -267,7 +267,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 簡易的な実装だが、多くのケースではうまく動いているようだ。 最大の問題は PSR 4 に準拠しないフレームワークを用いているとまったく役に立たないことで、今まさに職場で困っている。 こちらはいずれ改良したい。 + 簡易的な実装だが、多くのケースではうまく動いているようだ。最大の問題は PSR 4 に準拠しないフレームワークを用いているとまったく役に立たないことで、今まさに職場で困っている。こちらはいずれ改良したい。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2024-02-22/phpkansai-2024-report/index.html b/vhosts/blog/public/posts/2024-02-22/phpkansai-2024-report/index.html index 5883fc26..4081d1e9 100644 --- a/vhosts/blog/public/posts/2024-02-22/phpkansai-2024-report/index.html +++ b/vhosts/blog/public/posts/2024-02-22/phpkansai-2024-report/index.html @@ -107,7 +107,7 @@ <a href="/posts/2024-02-10/yapcjapan-2024-report/">本カンファレンスの前日 2024-02-10 は YAPC::Hiroshima に参加しており</a> 、2日連続のカンファレンスとなった。かなり疲れはしたが、その分充実した週末となったように思う。 </p> <p> - 翌3月は PHPerKaigi 2024、4月は PHPカンファレンス小田原 2024 があり、いずれもスタッフ兼スピーカーで参加予定である。 今度は提供する側として、満足のいくカンファレンスになるようにしたい。 + 翌3月は PHPerKaigi 2024、4月は PHPカンファレンス小田原 2024 があり、いずれもスタッフ兼スピーカーで参加予定である。今度は提供する側として、満足のいくカンファレンスになるようにしたい。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2024-03-17/phperkaigi-2024-report/index.html b/vhosts/blog/public/posts/2024-03-17/phperkaigi-2024-report/index.html index 6870db28..d37dc3ed 100644 --- a/vhosts/blog/public/posts/2024-03-17/phperkaigi-2024-report/index.html +++ b/vhosts/blog/public/posts/2024-03-17/phperkaigi-2024-report/index.html @@ -69,7 +69,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - 2024-03-07 から 2024-03-09 にかけて開催された、 <a href="https://phperkaigi.jp/2024/" rel="noreferrer" target="_blank">PHPerKaigi 2024</a> に参加した。 今年はスピーカーとして、また、コアスタッフとして参加した。 + 2024-03-07 から 2024-03-09 にかけて開催された、 <a href="https://phperkaigi.jp/2024/" rel="noreferrer" target="_blank">PHPerKaigi 2024</a> に参加した。今年はスピーカーとして、また、コアスタッフとして参加した。 </p> <p> 過去の参加レポはこちら: @@ -105,13 +105,13 @@ </li> </ul> <p> - WebAssembly の VM を PHP で実装し、実装に至るまでの道程や WebAssembly の特徴、言語処理系を作る楽しさについて語った。 タイトルにある「WebAssembly を理解する」という目的が達成できるようなトークだったかと言われると疑問は残るものの、実際に作った人にしかできない話をすることはできたと思う。 + WebAssembly の VM を PHP で実装し、実装に至るまでの道程や WebAssembly の特徴、言語処理系を作る楽しさについて語った。タイトルにある「WebAssembly を理解する」という目的が達成できるようなトークだったかと言われると疑問は残るものの、実際に作った人にしかできない話をすることはできたと思う。 </p> </section> <section id="section--as-staff"> <h2><a href="#section--as-staff">コアスタッフとして</a></h2> <p> - 昨年は当日スタッフとして参加したが、今年はコアスタッフとして運営に参加した。 今年はコードゴルフ企画を提案し、その準備とシステムの開発、当日の運用をおこなった。 そのシステムは現在も下記の URL から閲覧でき、当日出題された問題や参加者の方々の回答が見られる。 + 昨年は当日スタッフとして参加したが、今年はコアスタッフとして運営に参加した。今年はコードゴルフ企画を提案し、その準備とシステムの開発、当日の運用をおこなった。そのシステムは現在も下記の URL から閲覧でき、当日出題された問題や参加者の方々の回答が見られる。 </p> <p> <a href="https://t.nil.ninja/phperkaigi/2024/golf/" rel="noreferrer" target="_blank">Albatross.PHP</a> @@ -128,7 +128,7 @@ <a href="https://fortee.jp/phperkaigi-2024/proposal/ac59d0dd-795a-47cb-ba59-c0b1772d00cc" rel="noreferrer" target="_blank">RubyVM を PHP で実装する〜Hello World を出力するまで〜</a> (めもりー さん) </p> <p> - 今回一番楽しみにしていたセッションであり、期待どおりの面白さだった。 私も今回 VM を作るというテーマで登壇したこともあり、高い解像度で受け取ることができたように思う。 + 今回一番楽しみにしていたセッションであり、期待どおりの面白さだった。私も今回 VM を作るというテーマで登壇したこともあり、高い解像度で受け取ることができたように思う。 </p> <p> P.S. Ask the Speaker で話した、Ruby VM (written in PHP) on PHP VM (compiled to Wasm) on Wasm VM (written in PHP) on PHP というアイデアは「マジ」なので、続報をお待ちください (自作 Wasm runtime に不足している機能を鋭意実装中です)。 @@ -154,7 +154,7 @@ <a href="https://twitter.com/nsfisis/status/1765366490277253502" rel="noreferrer" target="_blank">ゴリゴリに開発しなければいけないセッションのスピーカーとゴリゴリに開発しなければいけない企画のスタッフを同じカンファレンスでやってはいけない</a> </p> <p> - ただ、それでもコアスタッフとして半年ほど関わっただけに、終わってみると感慨深い。 例年どおり、お祭のような活気・熱気を感じることができた。 + ただ、それでもコアスタッフとして半年ほど関わっただけに、終わってみると感慨深い。例年どおり、お祭のような活気・熱気を感じることができた。 </p> <p> 来月は、また登壇とスタッフ (こちらは当日スタッフ) をおこなう <a href="https://phpcon-odawara.jp/" rel="noreferrer" target="_blank">PHP カンファレンス小田原</a> があるので、良いトーク・良いカンファレンスを作れるようにしたい。 diff --git a/vhosts/blog/public/posts/2024-04-14/phpcon-odawara-2024-report/index.html b/vhosts/blog/public/posts/2024-04-14/phpcon-odawara-2024-report/index.html index 3eed3621..676416f7 100644 --- a/vhosts/blog/public/posts/2024-04-14/phpcon-odawara-2024-report/index.html +++ b/vhosts/blog/public/posts/2024-04-14/phpcon-odawara-2024-report/index.html @@ -94,7 +94,7 @@ 今回、どこから話を始めるか大いに迷ったのだが、最終的には PHP 処理系の opcode や VM といった概念は既知のものとし、そこから JIT コンパイルへ繋げるといった構成にした。 </p> <p> - PHP の処理系がスクリプトを opcode へ変換する過程については、ちょうど同じカンファレンスの <a href="https://fortee.jp/phpconodawara-2024/proposal/21d94a60-404d-4fba-8c60-d1c8889a0138" rel="noreferrer" target="_blank">めもりーさんの発表</a> あたりを参考にしていただくとよいだろう。 また、新しい IR についてより詳しく知りたいという方は、スライド末尾の「参考資料」にあるリンクを参照いただくのがよいかと思う。 + PHP の処理系がスクリプトを opcode へ変換する過程については、ちょうど同じカンファレンスの <a href="https://fortee.jp/phpconodawara-2024/proposal/21d94a60-404d-4fba-8c60-d1c8889a0138" rel="noreferrer" target="_blank">めもりーさんの発表</a> あたりを参考にしていただくとよいだろう。また、新しい IR についてより詳しく知りたいという方は、スライド末尾の「参考資料」にあるリンクを参照いただくのがよいかと思う。 </p> <p> Tracing JIT の発火条件や、IR を使って実現される最適化方法など、調べたものの発表に入らなかった話がごまんとあるので、これもどこかに持っていければと考えている。 diff --git a/vhosts/blog/public/posts/2024-04-21/pipefail-option-in-gitlab-ci-cd/index.html b/vhosts/blog/public/posts/2024-04-21/pipefail-option-in-gitlab-ci-cd/index.html index 157dc1ab..f2d709da 100644 --- a/vhosts/blog/public/posts/2024-04-21/pipefail-option-in-gitlab-ci-cd/index.html +++ b/vhosts/blog/public/posts/2024-04-21/pipefail-option-in-gitlab-ci-cd/index.html @@ -128,7 +128,7 @@ <span class="line"><span style="color:#005CC5">set</span><span style="color:#032F62"> +o</span><span style="color:#032F62"> pipefail</span></span></code></pre> </div> <p> - こうすると、パイプ全体が失敗するようになる。 この設定は、デフォルトだと off になっている。 + こうすると、パイプ全体が失敗するようになる。この設定は、デフォルトだと off になっている。 </p> </section> </section> @@ -148,10 +148,10 @@ <span class="line"><span style="color:#22863A"> when</span><span style="color:#24292E">: </span><span style="color:#032F62">always</span></span></code></pre> </div> <p> - <code>grep</code> コマンドは、パターンにマッチする行が一行もなかったとき、exit code 1 を返す。よって、<code>pipefail</code> が on になっていると、このジョブは失敗する。 現在の <code>pipefail</code> がどうなっているか確かめるため <code>set +o</code> で全オプションを出力させたところ、<code>pipefail</code> が on になっていた。 + <code>grep</code> コマンドは、パターンにマッチする行が一行もなかったとき、exit code 1 を返す。よって、<code>pipefail</code> が on になっていると、このジョブは失敗する。現在の <code>pipefail</code> がどうなっているか確かめるため <code>set +o</code> で全オプションを出力させたところ、<code>pipefail</code> が on になっていた。 </p> <p> - しかし、先述したように Bash における <code>pipefail</code> のデフォルト値は off のはずだ。 実際に、ローカルで <code>alpine:latest</code> を動かしてみたところ、 + しかし、先述したように Bash における <code>pipefail</code> のデフォルト値は off のはずだ。実際に、ローカルで <code>alpine:latest</code> を動かしてみたところ、 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ docker run --rm alpine:latest sh -c "set +o"</span></span> @@ -179,7 +179,7 @@ <section id="section--where-pipefail-is-enabled"> <h2><a href="#section--where-pipefail-is-enabled">どこで <code>pipefail</code> が on になるか</a></h2> <p> - <code>.gitlab-ci.yml</code> で明示的には書いていないので、GitLab Runner (GitLab CI/CD のスクリプトを実行するプログラム) が勝手に追加しているに違いない。 そう仮説を立てて <a href="https://gitlab.com/gitlab-org/gitlab-runner" rel="noreferrer" target="_blank">GitLab Runner のリポジトリ</a> を調査したところ、 <a href="https://gitlab.com/gitlab-org/gitlab-runner/-/blob/c75da0796a0e3048991dccfdf2784e3d931beda4/shells/bash.go#L276" rel="noreferrer" target="_blank">ソースコード中の以下の箇所</a> で <code>set -o pipefail</code> していることが判明した (コメントは筆者による)。 + <code>.gitlab-ci.yml</code> で明示的には書いていないので、GitLab Runner (GitLab CI/CD のスクリプトを実行するプログラム) が勝手に追加しているに違いない。そう仮説を立てて <a href="https://gitlab.com/gitlab-org/gitlab-runner" rel="noreferrer" target="_blank">GitLab Runner のリポジトリ</a> を調査したところ、 <a href="https://gitlab.com/gitlab-org/gitlab-runner/-/blob/c75da0796a0e3048991dccfdf2784e3d931beda4/shells/bash.go#L276" rel="noreferrer" target="_blank">ソースコード中の以下の箇所</a> で <code>set -o pipefail</code> していることが判明した (コメントは筆者による)。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#6A737D">// pipefail オプションが存在しない環境にも対応するため、</span></span> diff --git a/vhosts/blog/public/posts/2024-04-29/zsh-file-completion-for-composer-custom-commands/index.html b/vhosts/blog/public/posts/2024-04-29/zsh-file-completion-for-composer-custom-commands/index.html index 5a7c283d..66682843 100644 --- a/vhosts/blog/public/posts/2024-04-29/zsh-file-completion-for-composer-custom-commands/index.html +++ b/vhosts/blog/public/posts/2024-04-29/zsh-file-completion-for-composer-custom-commands/index.html @@ -80,13 +80,13 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - <a href="https://getcomposer.org/" rel="noreferrer" target="_blank">Composer</a> は PHP のデファクトスタンダードなパッケージマネージャである。 Zsh では、<code>composer</code> コマンドに対する補完が提供されており、<code>composer</code> と入力してタブキーを押すと、利用可能なコマンドやオプションが補完される。 Zsh の補完はシェル関数の形で実装されており、<code>composer</code> コマンドに対応した補完をおこなうのは <code>_composer</code> である。 <a href="https://github.com/zsh-users/zsh/blob/a66e92918568881af110a3e2e3018b317c054e4a/Completion/Unix/Command/_composer" rel="noreferrer" target="_blank">記事執筆時点での補完関数の定義は、GitHub のミラーリポジトリから参照できる。</a> + <a href="https://getcomposer.org/" rel="noreferrer" target="_blank">Composer</a> は PHP のデファクトスタンダードなパッケージマネージャである。Zsh では、<code>composer</code> コマンドに対する補完が提供されており、<code>composer</code> と入力してタブキーを押すと、利用可能なコマンドやオプションが補完される。Zsh の補完はシェル関数の形で実装されており、<code>composer</code> コマンドに対応した補完をおこなうのは <code>_composer</code> である。<a href="https://github.com/zsh-users/zsh/blob/a66e92918568881af110a3e2e3018b317c054e4a/Completion/Unix/Command/_composer" rel="noreferrer" target="_blank">記事執筆時点での補完関数の定義は、GitHub のミラーリポジトリから参照できる。</a> </p> </section> <section id="section--problem"> <h2><a href="#section--problem">発生していた問題</a></h2> <p> - <code>composer</code> コマンドはカスタムコマンド (<code>composer.json</code> の <code>scripts</code> で定義されたコマンド) に対して補完をおこなわない。 つまり、途中まで入力されたカスタムコマンドを補完しないし、カスタムコマンドの引数も補完しない。 例えば、PHPUnit を呼び出す <code>phpunit</code> というカスタムコマンドを定義し <code>composer phpu</code> まで打ってタブキーを押しても、<code>composer phpunit</code> にはならない。 また、<code>composer phpunit -- --</code> まで打ってタブキーを押しても、<code>phpunit</code> コマンドのオプションは補完されない。 + <code>composer</code> コマンドはカスタムコマンド (<code>composer.json</code> の <code>scripts</code> で定義されたコマンド) に対して補完をおこなわない。つまり、途中まで入力されたカスタムコマンドを補完しないし、カスタムコマンドの引数も補完しない。例えば、PHPUnit を呼び出す <code>phpunit</code> というカスタムコマンドを定義し <code>composer phpu</code> まで打ってタブキーを押しても、<code>composer phpunit</code> にはならない。また、<code>composer phpunit -- --</code> まで打ってタブキーを押しても、<code>phpunit</code> コマンドのオプションは補完されない。 </p> <p> このことは、先ほどリンクを載せた <code>_composer</code> 関数を定義しているファイルの冒頭にも書かれている。 @@ -102,22 +102,22 @@ <section id="section--what-i-want-to-achive"> <h2><a href="#section--what-i-want-to-achive">やりたいこと</a></h2> <p> - 確かに、カスタムコマンドに対して完全な補完を提供するのは不可能か、あるいは実現できても遅くなりすぎるだろう。 しかし、不完全なフォールバックを提供するくらいなら可能なはずだ。 + 確かに、カスタムコマンドに対して完全な補完を提供するのは不可能か、あるいは実現できても遅くなりすぎるだろう。しかし、不完全なフォールバックを提供するくらいなら可能なはずだ。 </p> <p> - この記事では、これらのカスタムコマンドについて、Zsh が提供するデフォルトのファイル・ディレクトリ補完を適用する。 つまり、<code>composer phpunit -- tests/</code> まで打ってタブキーを押すと、<code>tests</code> ディレクトリの下にあるテストファイルまたはディレクトリが補完される。 + この記事では、これらのカスタムコマンドについて、Zsh が提供するデフォルトのファイル・ディレクトリ補完を適用する。つまり、<code>composer phpunit -- tests/</code> まで打ってタブキーを押すと、<code>tests</code> ディレクトリの下にあるテストファイルまたはディレクトリが補完される。 </p> </section> <section id="section--solution"> <h2><a href="#section--solution">解決策</a></h2> <p> - まずは、Zsh で補完関数を提供する場合のボイラープレートコードを書く。 以下は <code>~/.zshrc</code> にすべて書く前提だが、<code>autoload</code> を設定するなどすれば別ファイルに分離できる (詳細な手順は割愛)。 + まずは、Zsh で補完関数を提供する場合のボイラープレートコードを書く。以下は <code>~/.zshrc</code> にすべて書く前提だが、<code>autoload</code> を設定するなどすれば別ファイルに分離できる (詳細な手順は割愛)。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#6F42C1">compdef</span><span style="color:#032F62"> _my_composer</span><span style="color:#032F62"> composer</span><span style="color:#032F62"> composer.phar</span></span></code></pre> </div> <p> - <code>compdef</code> は Zsh が用意している関数で、第一引数に補完関数の名前、第二引数以降に補完を適用するコマンド名を並べる。 この場合は、<code>composer</code> コマンドや <code>composer.phar</code> コマンドに対して <code>_my_composer</code> を使って補完をおこなうよう定義している。 + <code>compdef</code> は Zsh が用意している関数で、第一引数に補完関数の名前、第二引数以降に補完を適用するコマンド名を並べる。この場合は、<code>composer</code> コマンドや <code>composer.phar</code> コマンドに対して <code>_my_composer</code> を使って補完をおこなうよう定義している。 </p> <p> 次に <code>_my_composer</code> を定義する。基本的にはデフォルトの <code>composer</code> コマンドの補完関数 (つまり <code>_composer</code> 関数) を使い、それが何も返さなかった場合に限り、Zsh のファイル・ディレクトリ補完へフォールバックする。 @@ -128,13 +128,13 @@ <span class="line"><span style="color:#24292E">}</span></span></code></pre> </div> <p> - <code>_composer</code> コマンドは何も補完候補がなかったとき非ゼロな exit status で終了するので、そうであったなら <code>_files</code> を呼び出す。 <code>_files</code> は、Zsh がデフォルトで用意しているファイル・ディレクトリの補完をおこなう関数である。 + <code>_composer</code> コマンドは何も補完候補がなかったとき非ゼロな exit status で終了するので、そうであったなら <code>_files</code> を呼び出す。<code>_files</code> は、Zsh がデフォルトで用意しているファイル・ディレクトリの補完をおこなう関数である。 </p> </section> <section id="section--conclusion"> <h2><a href="#section--conclusion">まとめ</a></h2> <p> - これらの設定をおこなうことで、部分的ながら Composer のカスタムコマンドに対して補完をおこなうことができる。 特に、PHPUnit や PHPStan などの対象ファイル・ディレクトリを引数に取るようなコマンドを使う場合に有用であろう。 + これらの設定をおこなうことで、部分的ながら Composer のカスタムコマンドに対して補完をおこなうことができる。特に、PHPUnit や PHPStan などの対象ファイル・ディレクトリを引数に取るようなコマンドを使う場合に有用であろう。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2024-06-19/scalamatsuri-2024-report/index.html b/vhosts/blog/public/posts/2024-06-19/scalamatsuri-2024-report/index.html index 9f8bafb4..54c1f999 100644 --- a/vhosts/blog/public/posts/2024-06-19/scalamatsuri-2024-report/index.html +++ b/vhosts/blog/public/posts/2024-06-19/scalamatsuri-2024-report/index.html @@ -110,7 +110,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 私が Scala を書いたり追ったりしていたのは Scala 2 の頃で、Scala 3 はほとんど浦島太郎状態だったのだが、非常に楽しく面白いイベントだった。 イベントに触発されて、長らく塩漬けになっていた Scala 製の趣味プロジェクトを久しぶりに触っているのだが、これもまた楽しい。 + 私が Scala を書いたり追ったりしていたのは Scala 2 の頃で、Scala 3 はほとんど浦島太郎状態だったのだが、非常に楽しく面白いイベントだった。イベントに触発されて、長らく塩漬けになっていた Scala 製の趣味プロジェクトを久しぶりに触っているのだが、これもまた楽しい。 </p> <p> ScalaMatsuri 運営の皆さま、スピーカーの皆さま、スポンサーの皆さま、最高のイベントをありがとうございました！次回も楽しみにしています。 diff --git a/vhosts/blog/public/posts/2024-07-19/reparojson-fix-only-json-formatter/index.html b/vhosts/blog/public/posts/2024-07-19/reparojson-fix-only-json-formatter/index.html index 51d94b92..e6caeb2b 100644 --- a/vhosts/blog/public/posts/2024-07-19/reparojson-fix-only-json-formatter/index.html +++ b/vhosts/blog/public/posts/2024-07-19/reparojson-fix-only-json-formatter/index.html @@ -73,10 +73,10 @@ <section id="section--intro"> <h2><a href="#section--intro">欲しかったもの</a></h2> <p> - Vim で JSON を編集しているときに、文法エラー (末尾カンマやカンマの不足) のみを修正して一切の整形をおこなわないプラグインが欲しかった。 整形も同時におこなうプラグインは見つかっただけでも多数あったのだが、整形しないものは見つけられなかったので自作することにした。 + Vim で JSON を編集しているときに、文法エラー (末尾カンマやカンマの不足) のみを修正して一切の整形をおこなわないプラグインが欲しかった。整形も同時におこなうプラグインは見つかっただけでも多数あったのだが、整形しないものは見つけられなかったので自作することにした。 </p> <p> - なお、作成したツール自体は単体の CLI として動作し、Vim とは無関係に使うことができる。 この記事では Neovim と組み合わせる場合の設定を紹介するが、およそ任意のエディタで使えるだろう。 + なお、作成したツール自体は単体の CLI として動作し、Vim とは無関係に使うことができる。この記事では Neovim と組み合わせる場合の設定を紹介するが、およそ任意のエディタで使えるだろう。 </p> </section> <section id="section--reparojson"> @@ -159,7 +159,7 @@ <span class="line"><span style="color:#24292E"> })</span></span></code></pre> </div> <p> - ほとんどは nvim-lspconfig と efm-langserver を使う際のボイラープレートだが、<code>formatCommand</code> で <code>-q</code> フラグを指定していることに注意してほしい。 このツールは、デフォルトでは JSON が修正された場合 exit code 1 で終了する。 これは、入力が最初から正しかった場合と修正して正しくなった場合を区別するためだが、異常終了してしまうと置き換えが発生しない。 そのため、<code>-q</code> フラグを指定して、修正されたときも exit code 0 で終了するようにしている。 + ほとんどは nvim-lspconfig と efm-langserver を使う際のボイラープレートだが、<code>formatCommand</code> で <code>-q</code> フラグを指定していることに注意してほしい。このツールは、デフォルトでは JSON が修正された場合 exit code 1 で終了する。これは、入力が最初から正しかった場合と修正して正しくなった場合を区別するためだが、異常終了してしまうと置き換えが発生しない。そのため、<code>-q</code> フラグを指定して、修正されたときも exit code 0 で終了するようにしている。 </p> </section> <section id="section--outro"> @@ -192,7 +192,7 @@ <span class="line"><span style="color:#24292E"> }</span></span></code></pre> </div> <p> - もちろん、このような操作を文法を壊さずにおこなう Vim プラグインは存在する。 しかし、単なる行の入れ換えであれば <code>ddp</code> の3ストロークでおこなうことができ、専用のキーバインドを覚える必要もない。 このツールを用いることで、より Vimmer-friendly な JSON 編集が可能となる。 + もちろん、このような操作を文法を壊さずにおこなう Vim プラグインは存在する。しかし、単なる行の入れ換えであれば <code>ddp</code> の3ストロークでおこなうことができ、専用のキーバインドを覚える必要もない。このツールを用いることで、より Vimmer-friendly な JSON 編集が可能となる。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2024-08-19/go-template-access-outer-scope-pipeline-within-with-or-range/index.html b/vhosts/blog/public/posts/2024-08-19/go-template-access-outer-scope-pipeline-within-with-or-range/index.html index 418b5203..18730a09 100644 --- a/vhosts/blog/public/posts/2024-08-19/go-template-access-outer-scope-pipeline-within-with-or-range/index.html +++ b/vhosts/blog/public/posts/2024-08-19/go-template-access-outer-scope-pipeline-within-with-or-range/index.html @@ -66,7 +66,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - Go には、標準ライブラリにテンプレートライブラリ <code>text/template</code> がある。 この <code>text/template</code> における制御構造、<code>with</code> と <code>range</code> は次のように使われる。 + Go には、標準ライブラリにテンプレートライブラリ <code>text/template</code> がある。この <code>text/template</code> における制御構造、<code>with</code> と <code>range</code> は次のように使われる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span># {{ .Title }}</span></span> @@ -87,7 +87,7 @@ <code>text/template</code> の <code>.</code> は、現在の操作対象を表す特殊なオブジェクトである。 </p> <p> - <code>with</code> や <code>range</code> は、<code>.</code> を変更する効果を持つ。 <code>with</code> は引数に渡されたオブジェクトを <code>.</code> へセットして、内部のテンプレートを実行する。 <code>range</code> は引数に渡されたイテレート可能なオブジェクトに対し、それぞれの要素を <code>.</code> へセットして、要素の個数だけ内部のテンプレートを実行する。 + <code>with</code> や <code>range</code> は、<code>.</code> を変更する効果を持つ。<code>with</code> は引数に渡されたオブジェクトを <code>.</code> へセットして、内部のテンプレートを実行する。<code>range</code> は引数に渡されたイテレート可能なオブジェクトに対し、それぞれの要素を <code>.</code> へセットして、要素の個数だけ内部のテンプレートを実行する。 </p> <p> つまりこのテンプレートは、次のような構造をレンダリングしている (<code>Execute()</code> の第2引数)。 @@ -122,7 +122,7 @@ <span class="line"><span>{{ end }}</span></span></code></pre> </div> <p> - <code>with</code> や <code>range</code> は、<code>.</code> を自身の対象オブジェクトに変更するので、 単に <code>{{ with .User }}</code> の中で <code>.Title</code> と書いても、それは <code>User</code> の <code>Title</code> プロパティを参照しているとみなされる。 + <code>with</code> や <code>range</code> は、<code>.</code> を自身の対象オブジェクトに変更するので、単に <code>{{ with .User }}</code> の中で <code>.Title</code> と書いても、それは <code>User</code> の <code>Title</code> プロパティを参照しているとみなされる。 </p> <p> <code>text/template</code> では変数が使えるので、テンプレートの先頭で @@ -152,7 +152,7 @@ <span class="line"><span>{{ end }}</span></span></code></pre> </div> <p> - <code>$</code> は、テンプレートが実行されるときに渡されたオブジェクトを指す。 これを使えば現在の <code>.</code> に関係なくトップレベルを参照できる。 + <code>$</code> は、テンプレートが実行されるときに渡されたオブジェクトを指す。これを使えば現在の <code>.</code> に関係なくトップレベルを参照できる。 </p> <p> このことは、<a href="https://pkg.go.dev/text/template#hdr-Variables" rel="noreferrer" target="_blank"><code>text/template</code> の公式ドキュメント</a>にも以下のように記載されている。 diff --git a/vhosts/blog/public/posts/2024-12-04/cohackpp-report/index.html b/vhosts/blog/public/posts/2024-12-04/cohackpp-report/index.html index 2cd7f946..c4f6d334 100644 --- a/vhosts/blog/public/posts/2024-12-04/cohackpp-report/index.html +++ b/vhosts/blog/public/posts/2024-12-04/cohackpp-report/index.html @@ -92,7 +92,7 @@ 私は「ぺ」陣営のスピーカーとして LT をしていたのですが、その前にまずは登壇以外の感想を。 </p> <p> - いや～最高でしたね。どの枠のスピーチの方も良かったのですが、特に (asumikam さん/stefafafan さんに)「育てられた」枠のお二方が印象に残っています。 (asumikam さん/stefafafan さんを)「育てた」枠としてお世話になった方に声をかけることはできると思うんですよ。 それだけでなく、「自分が育てたのだ」と言える人がいて、そしてそれに 100 点で応える人がいるということ。この素晴しさ。人徳。 + いや～最高でしたね。どの枠のスピーチの方も良かったのですが、特に (asumikam さん/stefafafan さんに)「育てられた」枠のお二方が印象に残っています。(asumikam さん/stefafafan さんを)「育てた」枠としてお世話になった方に声をかけることはできると思うんですよ。それだけでなく、「自分が育てたのだ」と言える人がいて、そしてそれに 100 点で応える人がいるということ。この素晴しさ。人徳。 </p> <p> 改めて、asumikam さん、stefafafan さん、ご結婚おめでとうございます！ @@ -116,7 +116,7 @@ <section id="section--lt--battle"> <h3><a href="#section--lt--battle">いざ尋常に勝負</a></h3> <p> - 当日は、「プログラミングマナー講座」と題して発表をおこないました。 結婚式のマナー、特に「忌み言葉」へフォーカスし、これを無理やりプログラミングに適用するというものです。 <a href="/slides/2024-11-30/cohackpp/">スライドはこちらにアップロードしています。</a> + 当日は、「プログラミングマナー講座」と題して発表をおこないました。結婚式のマナー、特に「忌み言葉」へフォーカスし、これを無理やりプログラミングに適用するというものです。<a href="/slides/2024-11-30/cohackpp/">スライドはこちらにアップロードしています。</a> </p> <p> 最終的にお祝いのメッセージを仕込んだソースコードで締めるという構成は、我ながら綺麗にまとまったと思っています。忌み言葉の案は他にも大量にあったのですが、技術 LT かつ結婚祝いスピーチにするためにどうしても最後のソースコードが必要だったので、時間の関係上それらには犠牲となってもらいました ( <a href="https://x.com/nsfisis/status/1862798137452327206" rel="noreferrer" target="_blank">ボツになった案のひとつ</a> )。 diff --git a/vhosts/blog/public/posts/2024-12-33/2024-reflections/index.html b/vhosts/blog/public/posts/2024-12-33/2024-reflections/index.html index 6043a6b9..1ef7b57b 100644 --- a/vhosts/blog/public/posts/2024-12-33/2024-reflections/index.html +++ b/vhosts/blog/public/posts/2024-12-33/2024-reflections/index.html @@ -54,7 +54,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - ご存じのとおり、4 と 11 と 23 で割り切れる年は閏年というやつで 12 月が 33 日まである。 1年の振り返りを書く猶予が平年よりも長くなるので大変に都合がよい。 + ご存じのとおり、4 と 11 と 23 で割り切れる年は閏年というやつで 12 月が 33 日まである。1年の振り返りを書く猶予が平年よりも長くなるので大変に都合がよい。 </p> <p> 去年のやつ: <a href="/posts/2023-12-31/2023-reflections/">/posts/2023-12-31/2023-reflections/</a> @@ -63,7 +63,7 @@ <section id="section--conference"> <h2><a href="#section--conference">登壇・カンファレンス参加</a></h2> <p> - 参加または登壇した勉強会やカンファレンス。 LT 等も含めて計 8 回の登壇をおこなった。 また、4つのカンファレンスでコアスタッフまたは当日スタッフとして参加した。 + 参加または登壇した勉強会やカンファレンス。LT 等も含めて計 8 回の登壇をおこなった。また、4つのカンファレンスでコアスタッフまたは当日スタッフとして参加した。 </p> <ul> <li> @@ -135,7 +135,7 @@ <section id="section--articles"> <h2><a href="#section--articles">書いた記事</a></h2> <p> - 今年はこのブログに月1記事以上の記事を書くという目標を立てていた。本数としては 12 本以上あるが、10月と11月はゼロになってしまった。 社内記事を社外向けにリライトする作業を中々進められていないので、2025年は定期的に消化していきたい。 + 今年はこのブログに月1記事以上の記事を書くという目標を立てていた。本数としては 12 本以上あるが、10月と11月はゼロになってしまった。社内記事を社外向けにリライトする作業を中々進められていないので、2025年は定期的に消化していきたい。 </p> <ul> <li> @@ -154,7 +154,7 @@ <section id="section--coding"> <h2><a href="#section--coding">作ったもの</a></h2> <p> - 今年は主に WebAssembly ランタイムと、カンファレンスの企画で使うシステムを作っていた。 後者のシステムでもサンドボックス化のための技術として WebAssembly を用いているので、今年は WebAssembly と戯れた一年だったと言える。 + 今年は主に WebAssembly ランタイムと、カンファレンスの企画で使うシステムを作っていた。後者のシステムでもサンドボックス化のための技術として WebAssembly を用いているので、今年は WebAssembly と戯れた一年だったと言える。 </p> <ul> <li> diff --git a/vhosts/blog/public/posts/2025-01-08/phperkaigi-2023-tokens-q1/index.html b/vhosts/blog/public/posts/2025-01-08/phperkaigi-2023-tokens-q1/index.html index f7021c2f..3e030b6d 100644 --- a/vhosts/blog/public/posts/2025-01-08/phperkaigi-2023-tokens-q1/index.html +++ b/vhosts/blog/public/posts/2025-01-08/phperkaigi-2023-tokens-q1/index.html @@ -82,10 +82,10 @@ </div> </div> <p> - 2023-03-23 から 2023-03-25 にかけて開催された <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> では、PHPer チャレンジという企画がおこなわれた。 PHPer チャレンジとは、スポンサーのパンフレットやカンファレンス会場などから「#」記号で始まる文字列を集め、景品などを得るという企画である。 この文字列は「PHPer トークン」と呼ばれている。弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> からは、トークン問題という形で、PHP に関する問題を解くと PHPer トークンが得られるようになっている問題を出題した。 + 2023-03-23 から 2023-03-25 にかけて開催された <a href="https://phperkaigi.jp/2023/" rel="noreferrer" target="_blank">PHPerKaigi 2023</a> では、PHPer チャレンジという企画がおこなわれた。PHPer チャレンジとは、スポンサーのパンフレットやカンファレンス会場などから「#」記号で始まる文字列を集め、景品などを得るという企画である。この文字列は「PHPer トークン」と呼ばれている。弊社 <a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> からは、トークン問題という形で、PHP に関する問題を解くと PHPer トークンが得られるようになっている問題を出題した。 </p> <p> - <a href="/posts/2023-04-04/phperkaigi-2023-report/">PHPerKaigi 2023 の参加レポ</a> でも書いたとおり、この年のトークン問題は「昨年の PHPerKaigi 2022 が終わった段階から作り始め、約半年かけて制作」された。 PHPerKaigi 当日も <a href="/slides/2023-03-25/phperkaigi-2023-tokens/">PHPer チャレンジ解説セッション</a> という形で解説の機会を頂いたのだが、せっかく時間をかけて作題したので記事の形でも残しておこうと思う。 + <a href="/posts/2023-04-04/phperkaigi-2023-report/">PHPerKaigi 2023 の参加レポ</a> でも書いたとおり、この年のトークン問題は「昨年の PHPerKaigi 2022 が終わった段階から作り始め、約半年かけて制作」された。PHPerKaigi 当日も <a href="/slides/2023-03-25/phperkaigi-2023-tokens/">PHPer チャレンジ解説セッション</a> という形で解説の機会を頂いたのだが、せっかく時間をかけて作題したので記事の形でも残しておこうと思う。 </p> <p> この記事では、全5問ある中の第1問について解説する。他の問題については以下のリンクを参照のこと。 @@ -138,7 +138,7 @@ <section id="section--commentary--read-as-image"> <h3><a href="#section--commentary--read-as-image">画像として解釈する</a></h3> <p> - まずは素直に画像として見てみよう。 全体は QR コードになっている。適当な QR コードリーダで読み込むと、次のようなテキストが表示されるはずだ。 + まずは素直に画像として見てみよう。全体は QR コードになっている。適当な QR コードリーダで読み込むと、次のようなテキストが表示されるはずだ。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>Guess password. $ echo "password" | php Q1.png >/dev/null</span></span></code></pre> @@ -147,7 +147,7 @@ メッセージは、この画像の実行方法とこの問題でやるべきこと (パスワードの推測) を示している。 </p> <p> - 次に QR コードの中央部に目を向けると、小さな文字で「Password is one of the PHPer tokens.」と書かれているのがわかる。 他の PHPer トークンの中から適切な1つを見つけだし、「パスワード」として渡すことで答えとなる PHPer トークンが得られるというわけだ。 + 次に QR コードの中央部に目を向けると、小さな文字で「Password is one of the PHPer tokens.」と書かれているのがわかる。他の PHPer トークンの中から適切な1つを見つけだし、「パスワード」として渡すことで答えとなる PHPer トークンが得られるというわけだ。 </p> </section> <section id="section--commentary--password"> @@ -163,10 +163,10 @@ すでに <a href="#section--how-to-solve">「解き方」の節</a> で示したように、パスワードである PHPer トークンは「#iwillblog」である。これを与えて実行すると正解のトークンが得られる。 </p> <p> - このパスワードの選択にはとある事情がある。 今回の問題の作問は前回の開催 (PHPerKaigi 2022) 直後からスタートしており、この時点では PHPerKaigi 2023 で登録される PHPer トークンにどのようなものがあるかはまったくわからない状態であった。 作問作業を早期に終わらせるには、次回開催でも確実に使われるであろう定番のトークンを予測して選ぶ必要があったのだ。 かくして、私が知る限り毎回登場しているトークンである「#iwillblog」に白羽の矢が立てられた。 + このパスワードの選択にはとある事情がある。今回の問題の作問は前回の開催 (PHPerKaigi 2022) 直後からスタートしており、この時点では PHPerKaigi 2023 で登録される PHPer トークンにどのようなものがあるかはまったくわからない状態であった。作問作業を早期に終わらせるには、次回開催でも確実に使われるであろう定番のトークンを予測して選ぶ必要があったのだ。かくして、私が知る限り毎回登場しているトークンである「#iwillblog」に白羽の矢が立てられた。 </p> <p> - なお、解いてくださった方の中には、先頭の「#」を入力せずに何度も試してしまい答えが得られずじまいになった方もいらっしゃるようだった。 問題を置いていたリポジトリにヒントとしてパスワードのトークンが「i」で始まると書いていたのだが、これが意図せずミスリードになってしまった。 これは私のミスである。 + なお、解いてくださった方の中には、先頭の「#」を入力せずに何度も試してしまい答えが得られずじまいになった方もいらっしゃるようだった。問題を置いていたリポジトリにヒントとしてパスワードのトークンが「i」で始まると書いていたのだが、これが意図せずミスリードになってしまった。これは私のミスである。 </p> </section> <section id="section--commentary--png-steganography"> @@ -195,7 +195,7 @@ PNG フッタの後ろにあるデータは、画像ビューアには解釈されず、画像の表示には影響を与えない。したがって、PNG フッタの後ろには任意のデータを埋め込むことができる。 </p> <p> - さて、PHP には、PHP プログラムの始まりを示すための PHP タグ (<code><?php</code> または <code><?</code>) がある。 CLI で実行する場合、PHP タグよりも前にあるデータは標準出力へそのまま出力される。 + さて、PHP には、PHP プログラムの始まりを示すための PHP タグ (<code><?php</code> または <code><?</code>) がある。CLI で実行する場合、PHP タグよりも前にあるデータは標準出力へそのまま出力される。 </p> <p> この画像ファイルは次のような構造になっていた。 @@ -240,7 +240,7 @@ <span class="line"><span>// (以下略)</span></span></code></pre> </div> <p> - <code>IHDR</code> や <code>IEND</code> が PNG 画像の一部で、<code><?php</code> からが実際のプログラムになっている。 もちろんこれを PHP プログラムとして動かすと、PHP タグより前にある PNG 画像としてのデータはそのまま標準出力へと出力されてしまう。 それを防ぐため、QR コードを読み込んだときの実行方法 + <code>IHDR</code> や <code>IEND</code> が PNG 画像の一部で、<code><?php</code> からが実際のプログラムになっている。もちろんこれを PHP プログラムとして動かすと、PHP タグより前にある PNG 画像としてのデータはそのまま標準出力へと出力されてしまう。それを防ぐため、QR コードを読み込んだときの実行方法 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>Guess password. $ echo "password" | php Q1.png >/dev/null</span></span></code></pre> @@ -255,7 +255,7 @@ <section id="section--commentary--php-program"> <h3><a href="#section--commentary--php-program">実行される PHP プログラム</a></h3> <p> - 画像の正体がわかったところで、画像に隠されていた PHP プログラムについて見ていこう。 先ほどは一部しか記載しなかったので、全体を載せる。 なお、ある程度ゴルフしながら書いたので、空白こそ残しているものの可読性は非常に低いことと思う。 + 画像の正体がわかったところで、画像に隠されていた PHP プログラムについて見ていこう。先ほどは一部しか記載しなかったので、全体を載せる。なお、ある程度ゴルフしながら書いたので、空白こそ残しているものの可読性は非常に低いことと思う。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#D73A49"><?</span><span style="color:#005CC5">php</span></span> @@ -361,7 +361,7 @@ <span class="line"><span style="color:#005CC5">fwrite</span><span style="color:#24292E">(</span><span style="color:#005CC5">STDERR</span><span style="color:#24292E">, </span><span style="color:#005CC5">str_replace</span><span style="color:#24292E">(</span><span style="color:#032F62">'403 Forbidden'</span><span style="color:#24292E">, </span><span style="color:#032F62">'401 Unauthorized'</span><span style="color:#24292E">, $o));</span></span></code></pre> </div> <p> - これは一体なんなのか。ずばり、難解プログラミング言語の一つ Piet のインタプリタである。 Piet はピエト・モンドリアン (『赤・青・黄のコンポジション』などで知られる抽象画家) の作品にインスピレーションを受けて作られた、画像をソースコードとするプログラミング言語である。 インタプリタは画像の各ピクセルの上を進みながら、色等に応じて特定の処理をおこなっていく。 ここでは詳しい言語仕様については解説しないので、気になる方は <a href="https://ja.wikipedia.org/wiki/Piet" rel="noreferrer" target="_blank">Wikipedia の記事「Piet」</a> などを参照してほしい。 + これは一体なんなのか。ずばり、難解プログラミング言語の一つ Piet のインタプリタである。Piet はピエト・モンドリアン (『赤・青・黄のコンポジション』などで知られる抽象画家) の作品にインスピレーションを受けて作られた、画像をソースコードとするプログラミング言語である。インタプリタは画像の各ピクセルの上を進みながら、色等に応じて特定の処理をおこなっていく。ここでは詳しい言語仕様については解説しないので、気になる方は <a href="https://ja.wikipedia.org/wiki/Piet" rel="noreferrer" target="_blank">Wikipedia の記事「Piet」</a> などを参照してほしい。 </p> <p> プログラムの冒頭にあるこの箇所 @@ -370,16 +370,16 @@ <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#24292E">$b </span><span style="color:#D73A49">=</span><span style="color:#005CC5"> unpack</span><span style="color:#24292E">(</span><span style="color:#032F62">'C*'</span><span style="color:#24292E">, </span><span style="color:#005CC5">file_get_contents</span><span style="color:#24292E">(</span><span style="color:#005CC5">__FILE__</span><span style="color:#24292E">));</span></span></code></pre> </div> <p> - で <code>__FILE__</code> つまりこの画像ファイルを読み込んでいる。 先ほど Piet は画像をソースコードにしていると説明した。 そう、今回の問題の画像ファイル <code>Q1.png</code> は、PHP 製 Piet インタプリタであると同時に、Piet のソースコード画像でもあるのだ。 QR コード中央のカラフルな部分が Piet の命令になっている。 + で <code>__FILE__</code> つまりこの画像ファイルを読み込んでいる。先ほど Piet は画像をソースコードにしていると説明した。そう、今回の問題の画像ファイル <code>Q1.png</code> は、PHP 製 Piet インタプリタであると同時に、Piet のソースコード画像でもあるのだ。QR コード中央のカラフルな部分が Piet の命令になっている。 </p> </section> <section id="section--commentary--piet-source-code"> <h3><a href="#section--commentary--piet-source-code">Piet のソースコード</a></h3> <p> - さて、Piet でどのようなコードが書かれて (いや、描かれて) いるのかを解説したいところだが、今の私にはできそうにない。 というのも、すでに述べたように Piet は「難解プログラミング言語」である。 およそ人が描いたり読んだりするようには作られていない。性質としては、パズルに近い代物である。 + さて、Piet でどのようなコードが書かれて (いや、描かれて) いるのかを解説したいところだが、今の私にはできそうにない。というのも、すでに述べたように Piet は「難解プログラミング言語」である。およそ人が描いたり読んだりするようには作られていない。性質としては、パズルに近い代物である。 </p> <p> - というわけで、ここではあらましを説明するだけでご容赦いただきたい。 それぞれの部分はおおよそ次のようなことをやっている (再検証・再読解はしていないので大嘘かもしれない)。 + というわけで、ここではあらましを説明するだけでご容赦いただきたい。それぞれの部分はおおよそ次のようなことをやっている (再検証・再読解はしていないので大嘘かもしれない)。 </p> <ul> <li> @@ -426,10 +426,10 @@ <span class="line"><span style="color:#005CC5">fwrite</span><span style="color:#24292E">(</span><span style="color:#005CC5">STDERR</span><span style="color:#24292E">, </span><span style="color:#005CC5">str_replace</span><span style="color:#24292E">(</span><span style="color:#032F62">'403 Forbidden'</span><span style="color:#24292E">, </span><span style="color:#032F62">'401 Unauthorized'</span><span style="color:#24292E">, $o));</span></span></code></pre> </div> <p> - コメントにも書かれているが、この Piet のソースコード画像には誤りがあった。 本来 HTTP のステータスコードを真似るのなら、認証の失敗には 401 を返さなければならない。 しかし、Piet のソースは 403 を返すように書いてしまっていた。 そのことに私が気付いたのは PHPerKaigi 2023 が開催されるひと月前で、その時点で私はこの Piet のソースコードを (ちょうどこの記事でそうなっているのと同じように) 読解できなくなっていた。 さらに悪いことに、正しいメッセージ「401 Unauthorized」は元の「403 Forbidden」よりも3文字長い。 3文字出力が長くなるということは、それだけ Piet で塗るべきピクセルが増えることを意味する。 もはや3文字追加で出力するだけの余白はこの画像に残されていなかった (と思う。腕ききの Piet プログラマならできるかもしれないので挑戦してみてほしい)。 + コメントにも書かれているが、この Piet のソースコード画像には誤りがあった。本来 HTTP のステータスコードを真似るのなら、認証の失敗には 401 を返さなければならない。しかし、Piet のソースは 403 を返すように書いてしまっていた。そのことに私が気付いたのは PHPerKaigi 2023 が開催されるひと月前で、その時点で私はこの Piet のソースコードを (ちょうどこの記事でそうなっているのと同じように) 読解できなくなっていた。さらに悪いことに、正しいメッセージ「401 Unauthorized」は元の「403 Forbidden」よりも3文字長い。3文字出力が長くなるということは、それだけ Piet で塗るべきピクセルが増えることを意味する。もはや3文字追加で出力するだけの余白はこの画像に残されていなかった (と思う。腕ききの Piet プログラマならできるかもしれないので挑戦してみてほしい)。 </p> <p> - これを解決するために私が選んだのは、インタプリタを改造し、本来のメッセージとは異なるメッセージを無理やり出力させて帳尻を合わせることだった。 そういうわけでこの Piet インタプリタは完全な Piet インタプリタではなく、「403 Forbidden」というテキストを絶対に出力できない。 + これを解決するために私が選んだのは、インタプリタを改造し、本来のメッセージとは異なるメッセージを無理やり出力させて帳尻を合わせることだった。そういうわけでこの Piet インタプリタは完全な Piet インタプリタではなく、「403 Forbidden」というテキストを絶対に出力できない。 </p> </section> <section id="section--commentary--misc"> @@ -448,7 +448,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - この問題の自己評価はこちら。 問題の出題順はおおよそ作成した順になっているのだが、そのせいで難易度高めの問題が1問目に配置されてしまった。 これは反省点の一つである。 + この問題の自己評価はこちら。問題の出題順はおおよそ作成した順になっているのだが、そのせいで難易度高めの問題が1問目に配置されてしまった。これは反省点の一つである。 </p> <ul> <li> diff --git a/vhosts/blog/public/posts/2025-01-26/yaml-breaking-changes-between-v1-1-and-v1-2/index.html b/vhosts/blog/public/posts/2025-01-26/yaml-breaking-changes-between-v1-1-and-v1-2/index.html index 2db1aac9..36469811 100644 --- a/vhosts/blog/public/posts/2025-01-26/yaml-breaking-changes-between-v1-1-and-v1-2/index.html +++ b/vhosts/blog/public/posts/2025-01-26/yaml-breaking-changes-between-v1-1-and-v1-2/index.html @@ -73,7 +73,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - データ記述言語の一つ YAML には 1.0、1.1、1.2 のバージョンがある。 これらのうち、1.1 と 1.2 の間には無視できない非互換の変更が多く、1.2 に対応していないライブラリもある (Ruby 同梱の <code>yaml</code> など)。 この記事では、YAML 1.1 と YAML 1.2 の主な破壊的変更を紹介する (影響範囲が広いものを抜粋しており、すべての非互換を網羅してはいない)。 + データ記述言語の一つ YAML には 1.0、1.1、1.2 のバージョンがある。これらのうち、1.1 と 1.2 の間には無視できない非互換の変更が多く、1.2 に対応していないライブラリもある (Ruby 同梱の <code>yaml</code> など)。この記事では、YAML 1.1 と YAML 1.2 の主な破壊的変更を紹介する (影響範囲が広いものを抜粋しており、すべての非互換を網羅してはいない)。 </p> <p> 参照した仕様書はこちら: <a href="https://yaml.org/spec/1.2.2/ext/changes/" rel="noreferrer" target="_blank">https://yaml.org/spec/1.2.2/ext/changes/</a> @@ -84,13 +84,13 @@ <section id="section--breaking-changes--boolean-literals"> <h3><a href="#section--breaking-changes--boolean-literals">Boolean としてパースされるトークンが <code>true</code> / <code>false</code> とその亜種のみに</a></h3> <p> - この変更の影響が最も大きいと思われる。 YAML 1.1 では、boolean 値のリテラルとして <code>true</code>、<code>false</code> のほか <code>yes</code>、<code>no</code>、<code>y</code>、<code>n</code>、<code>on</code>、<code>off</code>、それらの大文字バージョンなどが認められていた。 YAML 1.2 では、<code>true</code> と <code>false</code>、それらの大文字バージョン (<code>True</code>、<code>TRUE</code>、<code>False</code>、<code>FALSE</code>) のみが boolean としてパースされるようになった。 + この変更の影響が最も大きいと思われる。YAML 1.1 では、boolean 値のリテラルとして <code>true</code>、<code>false</code> のほか <code>yes</code>、<code>no</code>、<code>y</code>、<code>n</code>、<code>on</code>、<code>off</code>、それらの大文字バージョンなどが認められていた。YAML 1.2 では、<code>true</code> と <code>false</code>、それらの大文字バージョン (<code>True</code>、<code>TRUE</code>、<code>False</code>、<code>FALSE</code>) のみが boolean としてパースされるようになった。 </p> </section> <section id="section--breaking-changes--octal-literals"> <h3><a href="#section--breaking-changes--octal-literals">八進数リテラルには <code>0o</code> が必須に</a></h3> <p> - C 言語などでは、<code>0</code> から始まる数字の列を八進数としてパースする。 YAML 1.1 もこれに準じていたが、1.2 からは <code>0o</code> のプレフィクスが必須となった (“o” は “octal” の “o”)。 プログラミング言語では、Python や Haskell、Swift、Rust などがこの記法を採用している。 + C 言語などでは、<code>0</code> から始まる数字の列を八進数としてパースする。YAML 1.1 もこれに準じていたが、1.2 からは <code>0o</code> のプレフィクスが必須となった (“o” は “octal” の “o”)。プログラミング言語では、Python や Haskell、Swift、Rust などがこの記法を採用している。 </p> </section> <section id="section--breaking-changes--merging"> @@ -122,7 +122,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 全体的に、<em>There’s more than one way to do it.</em> から <em>There should be one - and preferably only one - obvious way to do it.</em> へ移行しているように思われる。 データ記述言語としては望ましい方向性ではないかと感じる。 + 全体的に、<em>There’s more than one way to do it.</em> から <em>There should be one - and preferably only one - obvious way to do it.</em> へ移行しているように思われる。データ記述言語としては望ましい方向性ではないかと感じる。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2025-02-24/phpcon-nagoya-2025-report/index.html b/vhosts/blog/public/posts/2025-02-24/phpcon-nagoya-2025-report/index.html index 8a421f26..a6ff034c 100644 --- a/vhosts/blog/public/posts/2025-02-24/phpcon-nagoya-2025-report/index.html +++ b/vhosts/blog/public/posts/2025-02-24/phpcon-nagoya-2025-report/index.html @@ -108,7 +108,7 @@ <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 今回もカンファレンスくらいでしか聴けないようなセッションがいくつも聴けてよかった。 また、ちょうど連休だったのもあり名古屋も楽しむことができた。 運営のみなさま、お疲れさまでした&ありがとうございました。 次は PHPerKaigi 2025 で会いましょう。 + 今回もカンファレンスくらいでしか聴けないようなセッションがいくつも聴けてよかった。また、ちょうど連休だったのもあり名古屋も楽しむことができた。運営のみなさま、お疲れさまでした&ありがとうございました。次は PHPerKaigi 2025 で会いましょう。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2025-03-27/zip-function-like-command-paste-command/index.html b/vhosts/blog/public/posts/2025-03-27/zip-function-like-command-paste-command/index.html index 366e8a72..00c6943e 100644 --- a/vhosts/blog/public/posts/2025-03-27/zip-function-like-command-paste-command/index.html +++ b/vhosts/blog/public/posts/2025-03-27/zip-function-like-command-paste-command/index.html @@ -116,10 +116,10 @@ <span class="line"><span>' a.txt b.txt > ab.txt</span></span></code></pre> </div> <p> - <code>paste</code> コマンドは複数のファイルを引数に取り、それらを1行ずつ消費しながら <code>-d</code> で指定した文字で区切って出力する。 <code>-d</code> は区切り文字の指定で、デフォルトだとタブ区切りになる。 + <code>paste</code> コマンドは複数のファイルを引数に取り、それらを1行ずつ消費しながら <code>-d</code> で指定した文字で区切って出力する。<code>-d</code> は区切り文字の指定で、デフォルトだとタブ区切りになる。 </p> <p> - ファイル名には <code>-</code> を指定でき、その場合は標準入力から読み込んで出力する。 このとき <code>paste - -</code> のように複数回 <code>-</code> を指定すると、指定した回数の行ごとに連結することができる。 例えば <code>ab.txt</code> だとこうなる。 + ファイル名には <code>-</code> を指定でき、その場合は標準入力から読み込んで出力する。このとき <code>paste - -</code> のように複数回 <code>-</code> を指定すると、指定した回数の行ごとに連結することができる。例えば <code>ab.txt</code> だとこうなる。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ paste - - < ab.txt</span></span> diff --git a/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html b/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html index 42356f6f..df8307a9 100644 --- a/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html +++ b/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html @@ -95,7 +95,7 @@ </p> </blockquote> <p> - 【日本語訳 (私が訳したもので、公式なものではない)】 送信者は、同じ field name の header field を複数生成してはならない (MUST NOT)。 ただし、header field の値がコンマ区切りのリストとして定義されているか、header field がよく知られた例外 (後述) である場合はその限りでない。 + 【日本語訳 (私が訳したもので、公式なものではない)】 送信者は、同じ field name の header field を複数生成してはならない (MUST NOT)。ただし、header field の値がコンマ区切りのリストとして定義されているか、header field がよく知られた例外 (後述) である場合はその限りでない。 </p> </section> <section id="section--specification--recipient"> @@ -106,7 +106,7 @@ </p> </blockquote> <p> - 【日本語訳 (私が訳したもので、公式なものではない)】 受信者は、同じ field name を持つ複数の header field を、メッセージの意味を変えないようにしつつ同じ順序で追加して、単一のコンマで区切られた <code>"field-name: field-value"</code> のペアに結合してよい (MAY)。 したがって、同じ field name を持つ header field がどのような順序で受信されたかは、結合された値の解釈に影響する。 よって、プロキシは、メッセージを転送する際、header field の順序を変えてはならない (MUST NOT)。 + 【日本語訳 (私が訳したもので、公式なものではない)】 受信者は、同じ field name を持つ複数の header field を、メッセージの意味を変えないようにしつつ同じ順序で追加して、単一のコンマで区切られた <code>"field-name: field-value"</code> のペアに結合してよい (MAY)。したがって、同じ field name を持つ header field がどのような順序で受信されたかは、結合された値の解釈に影響する。よって、プロキシは、メッセージを転送する際、header field の順序を変えてはならない (MUST NOT)。 </p> </section> <section id="section--specification--exception"> @@ -117,7 +117,7 @@ </p> </blockquote> <p> - 【日本語訳 (私が訳したもので、公式なものではない)】 注意: 実際には、<code>Set-Cookie</code> header field (<a href="https://datatracker.ietf.org/doc/html/rfc6265" rel="noreferrer" target="_blank">RFC6265</a>) は、しばしばレスポンスメッセージ中に複数回現れる。 これはリストの構文を使っておらず、上述した同じ field name を持つ header field についての要件に違反している。 この値は単一の値へ結合できないため、受信者は、header field を処理する際、<code>Set-Cookie</code> を特別扱いした方がよい。 + 【日本語訳 (私が訳したもので、公式なものではない)】 注意: 実際には、<code>Set-Cookie</code> header field (<a href="https://datatracker.ietf.org/doc/html/rfc6265" rel="noreferrer" target="_blank">RFC6265</a>) は、しばしばレスポンスメッセージ中に複数回現れる。これはリストの構文を使っておらず、上述した同じ field name を持つ header field についての要件に違反している。この値は単一の値へ結合できないため、受信者は、header field を処理する際、<code>Set-Cookie</code> を特別扱いした方がよい。 </p> <p> おそらく、「送信側」のところで書かれている「よく知られた例外」の一つがこれだと思われる。 diff --git a/vhosts/blog/public/posts/2025-04-20/trick-2025-most-ruby-on-ruby-award/index.html b/vhosts/blog/public/posts/2025-04-20/trick-2025-most-ruby-on-ruby-award/index.html index a8b4129f..5e1debc5 100644 --- a/vhosts/blog/public/posts/2025-04-20/trick-2025-most-ruby-on-ruby-award/index.html +++ b/vhosts/blog/public/posts/2025-04-20/trick-2025-most-ruby-on-ruby-award/index.html @@ -160,7 +160,7 @@ シンタックスハイライトは、トークナイズとトークン種別に応じた色付けの2段階からなる。 </p> <p> - トークナイズには Ruby 3.4 からデフォルトのパーサになった <a href="https://github.com/ruby/prism" rel="noreferrer" target="_blank">Prism</a> を利用している。 <code>Prism.lex()</code> を使うとトークナイズができるので、トークンに付いているソースコード位置の情報を使いつつ元のソースコードを復元する。 + トークナイズには Ruby 3.4 からデフォルトのパーサになった <a href="https://github.com/ruby/prism" rel="noreferrer" target="_blank">Prism</a> を利用している。<code>Prism.lex()</code> を使うとトークナイズができるので、トークンに付いているソースコード位置の情報を使いつつ元のソースコードを復元する。 </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span style="color:#E36209">y</span><span style="color:#D73A49"> =</span><span style="color:#005CC5"> 1</span><span style="color:#6A737D"> # 現在の行</span></span> @@ -236,7 +236,7 @@ <span class="line"><span style="color:#D73A49">end</span></span></code></pre> </div> <p> - トークンの種類 (<code>t.type</code>) またはトークンの文字列表現そのもの (<code>t.value.downcase</code>) を使ってテーブルを引いて振り仮名へ変換している。 このテーブルのキー部分そのものにも振り仮名を振るために、トークンが <code>:</code> で終わっていれば <code>:</code> を取り除いて振り仮名を得ている (例: <code>"value:"</code> → <code>"value"</code> → <code>"48746992"</code>)。 + トークンの種類 (<code>t.type</code>) またはトークンの文字列表現そのもの (<code>t.value.downcase</code>) を使ってテーブルを引いて振り仮名へ変換している。このテーブルのキー部分そのものにも振り仮名を振るために、トークンが <code>:</code> で終わっていれば <code>:</code> を取り除いて振り仮名を得ている (例: <code>"value:"</code> → <code>"value"</code> → <code>"48746992"</code>)。 </p> <p> このテーブルはサイズ制限を突破するために圧縮されており、<code>kana()</code> 関数で展開される。 @@ -263,14 +263,14 @@ <span class="line"><span style="color:#6A737D"> # => "バリュー"</span></span></code></pre> </div> <p> - これは後で気付いたのだが、Ruby は多倍長整数が扱えるので <code>"48746992"</code> のようなデータは単に <code>48746992</code> と書けばよかった。 <code>kana()</code> 関数が多少長くはなるが、振り仮名データの数 x 2 バイト分サイズが減るのでこちらの方が短くなる。 サイズ制限の都合で振り仮名を振るのを諦めた記号もあったのでもったいない。 + これは後で気付いたのだが、Ruby は多倍長整数が扱えるので <code>"48746992"</code> のようなデータは単に <code>48746992</code> と書けばよかった。<code>kana()</code> 関数が多少長くはなるが、振り仮名データの数 x 2 バイト分サイズが減るのでこちらの方が短くなる。サイズ制限の都合で振り仮名を振るのを諦めた記号もあったのでもったいない。 </p> </section> </section> <section id="section--outro"> <h2><a href="#section--outro">おわりに</a></h2> <p> - 本っ当に取りたかったので心から嬉しいです。 全部で 3作提出したのですが、他の 2つも選外佳作として選出していただけた上、そのうちの “Least Truthful” については最後に Matz 氏から言及があり、審査員賞と合わせて望外の栄誉となりました。 + 本っ当に取りたかったので心から嬉しいです。全部で 3作提出したのですが、他の 2つも選外佳作として選出していただけた上、そのうちの “Least Truthful” については最後に Matz 氏から言及があり、審査員賞と合わせて望外の栄誉となりました。 </p> <p> ありがとうございました！ diff --git a/vhosts/blog/public/posts/2025-04-24/composer-patches-v2-does-not-require-gnu-patch-even-on-macos/index.html b/vhosts/blog/public/posts/2025-04-24/composer-patches-v2-does-not-require-gnu-patch-even-on-macos/index.html index 9d9dc7a1..487ec2c3 100644 --- a/vhosts/blog/public/posts/2025-04-24/composer-patches-v2-does-not-require-gnu-patch-even-on-macos/index.html +++ b/vhosts/blog/public/posts/2025-04-24/composer-patches-v2-does-not-require-gnu-patch-even-on-macos/index.html @@ -82,7 +82,7 @@ <a href="https://getcomposer.org/" rel="noreferrer" target="_blank">Composer</a> は PHP におけるデファクトスタンダードなパッケージ管理システムである。 </p> <p> - Composer を拡張するプラグインの一つに、<a href="https://github.com/cweagans/composer-patches" rel="noreferrer" target="_blank">composer-patches</a> という Composer パッケージがある。 これは、Composer でパッケージをインストールするときにそのパッケージへ任意のパッチを当てるプラグインである。 + Composer を拡張するプラグインの一つに、<a href="https://github.com/cweagans/composer-patches" rel="noreferrer" target="_blank">composer-patches</a> という Composer パッケージがある。これは、Composer でパッケージをインストールするときにそのパッケージへ任意のパッチを当てるプラグインである。 </p> <p> 社内で発見しすぐに適用しなければならないバグ修正や、Pull Request こそあるもののなかなかマージされない機能等をすぐさま適用してリリースすることができる。 @@ -94,7 +94,7 @@ <section id="section--on-macos"> <h2><a href="#section--on-macos">macOS での問題点</a></h2> <p> - <code>composer-patches</code> は、macOS で一部のパッチの適用に失敗することが知られている。 関連 issues: + <code>composer-patches</code> は、macOS で一部のパッチの適用に失敗することが知られている。関連 issues: </p> <ul> <li> @@ -105,10 +105,10 @@ </li> </ul> <p> - これは、<code>composer-patches</code> の想定する <code>patch</code> コマンドが GNU 実装の patch であることに由来する。 macOS にプリインストールされている <code>patch</code> はいわゆる BSD patch であり、GNU patch とは完全な互換性がない。 + これは、<code>composer-patches</code> の想定する <code>patch</code> コマンドが GNU 実装の patch であることに由来する。macOS にプリインストールされている <code>patch</code> はいわゆる BSD patch であり、GNU patch とは完全な互換性がない。 </p> <p> - ワークアラウンドとして、macOS にも GNU patch をインストールしてしまうという方法がある。 例: + ワークアラウンドとして、macOS にも GNU patch をインストールしてしまうという方法がある。例: </p> <div class="codeblock"> <pre class="shiki github-light" style="background-color:#f5f5f5;color:#24292e" tabindex="0"><code><span class="line"><span>$ brew install gpatch</span></span> @@ -124,7 +124,7 @@ 現在ベータ版である <code>composer-patches</code> v2 では、このワークアラウンドが不要になる (見込み)。 </p> <p> - 最新の実装では、<code>git apply</code> コマンドが最優先で使われる。 また、Git リポジトリがない場合 (<code>config.preferred-install</code> を <code>dist</code> に設定している場合など。デフォルトではそうなる) には <code>git init</code> を使って一時的にリポジトリを作成し、その上で <code>git apply</code> を実行するようになった。 + 最新の実装では、<code>git apply</code> コマンドが最優先で使われる。また、Git リポジトリがない場合 (<code>config.preferred-install</code> を <code>dist</code> に設定している場合など。デフォルトではそうなる) には <code>git init</code> を使って一時的にリポジトリを作成し、その上で <code>git apply</code> を実行するようになった。 </p> <p> この変更により、環境ごとに差異のある <code>patch</code> コマンドへの依存がなくなるので、macOS で <code>composer-patches</code> を使うときの厄介事は解消されるものと思われる。 diff --git a/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html b/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html index 4b7b2a68..299d3f94 100644 --- a/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html +++ b/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html @@ -60,7 +60,7 @@ <section id="section--intro"> <h2><a href="#section--intro">はじめに</a></h2> <p> - C コンパイラと言えば、世界三大自作したいソフトウェアの一角である。 というわけで <a href="https://www.sigbus.info/compilerbook" rel="noreferrer" target="_blank">『低レイヤを知りたい人のためのCコンパイラ作成入門』</a> (以下 compilerbook) 片手に作ることにした。 + C コンパイラと言えば、世界三大自作したいソフトウェアの一角である。というわけで <a href="https://www.sigbus.info/compilerbook" rel="noreferrer" target="_blank">『低レイヤを知りたい人のためのCコンパイラ作成入門』</a> (以下 compilerbook) 片手に作ることにした。 </p> <p> 実装する機能を適切に絞ってやればゴールデンウィークの間 (2025-05-03 から 2025-05-06) にセルフホストまで持っていけるのではないか？という仮説を立て、ISO 8601 の表記で 4日間を表す “P4D” を冠して P4Dcc と名付けた。 @@ -92,7 +92,7 @@ <section id="section--design"> <h2><a href="#section--design">設計</a></h2> <p> - ゴールデンウィークの4日間で終わらせたいので、実装する言語機能は最低限に絞ることが必要になる。 今回は次のような設計とした (compilerbook の設計を踏襲しているものは除く)。 + ゴールデンウィークの4日間で終わらせたいので、実装する言語機能は最低限に絞ることが必要になる。今回は次のような設計とした (compilerbook の設計を踏襲しているものは除く)。 </p> <ul> <li> @@ -333,7 +333,7 @@ compilerbook のようなインクリメンタルな進め方を取らずに、最初から普通の言語処理系のような構成にしたのには理由がある。 </p> <p> - それは、どのくらいの言語機能があればコンパイラを作るのに十分かをこの時点で見積もるためである。 開発を開始する前にも必要な言語機能にはあたりを付けていたが、実際にプロトタイプを作ってみて、これだけの機能セットがあれば足りるだろうという正確な TODO リストを作りたかった。 実際、このとき作ったチェックリストはこのあともほとんど変わっていない (大きな変化点は、配列型をサポートしないと決めたことくらいか)。 + それは、どのくらいの言語機能があればコンパイラを作るのに十分かをこの時点で見積もるためである。開発を開始する前にも必要な言語機能にはあたりを付けていたが、実際にプロトタイプを作ってみて、これだけの機能セットがあれば足りるだろうという正確な TODO リストを作りたかった。実際、このとき作ったチェックリストはこのあともほとんど変わっていない (大きな変化点は、配列型をサポートしないと決めたことくらいか)。 </p> <p> このあとは、おおむね compilerbook に従って以下のように機能追加を続けた。 @@ -455,13 +455,13 @@ <code>&</code>、<code>*</code>、<code>sizeof</code> あたりの実装が終わるとかなり C 言語らしくなっていき楽しい。 </p> <p> - このあたりから、セルフホストに向けて逆方向からのアプローチも並行しておこなっている。 セルフホストするためには処理系のソースコードで使っている言語機能をすべて実装する必要があるわけだが、これまでは処理系が扱える機能を拡充していくという方向だった。この逆、つまり処理系のソースコードで使っている機能を減らすことでもセルフホストに近付いていく。 + このあたりから、セルフホストに向けて逆方向からのアプローチも並行しておこなっている。セルフホストするためには処理系のソースコードで使っている言語機能をすべて実装する必要があるわけだが、これまでは処理系が扱える機能を拡充していくという方向だった。この逆、つまり処理系のソースコードで使っている機能を減らすことでもセルフホストに近付いていく。 </p> <p> - 例えば、このコンパイラは <code>typedef</code> をサポートしていないが、開発中ずっと <code>typedef</code> を使わないというのは面倒だ。 そこで、セルフホストがある程度現実的になるまでは構造体を <code>typedef</code> しておいて、途中のどこかで <code>typedef</code> を手で脱糖する。 + 例えば、このコンパイラは <code>typedef</code> をサポートしていないが、開発中ずっと <code>typedef</code> を使わないというのは面倒だ。そこで、セルフホストがある程度現実的になるまでは構造体を <code>typedef</code> しておいて、途中のどこかで <code>typedef</code> を手で脱糖する。 </p> <p> - これらの作業をおこなうことで、処理系自身のソースコード <code>main.c</code> をパースしてバイナリを出力することができるようになった。 いわゆる第2世代のコンパイラである。この現時点ではまだ第2世代コンパイラは何もできない (何を与えてもクラッシュする)。 + これらの作業をおこなうことで、処理系自身のソースコード <code>main.c</code> をパースしてバイナリを出力することができるようになった。いわゆる第2世代のコンパイラである。この現時点ではまだ第2世代コンパイラは何もできない (何を与えてもクラッシュする)。 </p> </section> <section id="section--development--day3"> @@ -470,7 +470,7 @@ さて、第2世代コンパイラが手に入ったので、ここからは地獄のデバッグ作業が始まる。多段になっているために問題が起きている箇所の特定が難しい。 </p> <p> - ……と考えていたのだが、実際のところデバッグは1時間ほどで終わってしまった。 修正したのは1点のみ。 なんのことはない、2日目終了時点でほとんど完成していたわけだ。 + ……と考えていたのだが、実際のところデバッグは1時間ほどで終わってしまった。修正したのは1点のみ。なんのことはない、2日目終了時点でほとんど完成していたわけだ。 </p> <p> 記念すべき (?) 最後のバグはこちら。 @@ -485,13 +485,13 @@ <span class="line"><span style="color:#24292E"> }</span></span></code></pre> </div> <p> - メモリアドレスから参照先の値を得る際、その型によってロードする命令の種類を変える必要があるのだが、その切替をポインタ型でおこなっていた。 正しくは、そのポインタ型が指す型を元にして切り替えなければならない。 + メモリアドレスから参照先の値を得る際、その型によってロードする命令の種類を変える必要があるのだが、その切替をポインタ型でおこなっていた。正しくは、そのポインタ型が指す型を元にして切り替えなければならない。 </p> <p> これを修正すると、第2世代コンパイラが第3世代コンパイラを出力できるようになり、その後も第N世代が第N+1世代を生成できるようになった。 </p> <p> - あとは、第2世代のコンパイラがそれ以降のコンパイラとバイナリレベルで一致するかどうかを確かめればよい。 実際に調べてみると、ほとんどの場所が一致したもののどの世代も 6バイトだけ異なることがわかった。 + あとは、第2世代のコンパイラがそれ以降のコンパイラとバイナリレベルで一致するかどうかを確かめればよい。実際に調べてみると、ほとんどの場所が一致したもののどの世代も 6バイトだけ異なることがわかった。 </p> <p> 一体どこが異なるのか。<code>hexdump</code> の差分がこちら。 @@ -509,7 +509,7 @@ <span class="line"><span> 00015e10 79 70 65 5f 6e 65 77 00 74 79 70 65 5f 6e 65 77 |ype_new.type_new|</span></span></code></pre> </div> <p> - <code>fatal_error</code>、<code>read_all</code>、<code>tokenize</code> <code>type_new</code> はいずれも <code>main.c</code> で定義された関数の名前である。 このことから考えると、これは GCC が埋め込んだシンボルテーブルである可能性が高い。 わずかに異なっている 6バイトは、ランダム生成された何かのように見える。 + <code>fatal_error</code>、<code>read_all</code>、<code>tokenize</code> <code>type_new</code> はいずれも <code>main.c</code> で定義された関数の名前である。このことから考えると、これは GCC が埋め込んだシンボルテーブルである可能性が高い。わずかに異なっている 6バイトは、ランダム生成された何かのように見える。 </p> <p> そこで <code>gcc</code> に <code>-s</code> (シンボルテーブルを削除するフラグ) を渡してみると、めでたく2世代目以降のコンパイラのバイナリが完全に一致するようになった。 @@ -525,10 +525,10 @@ 最終的な実装は1900行ほど、所要時間は20時間弱となった。 </p> <p> - 正直なところ、思ったより早く終わって拍子抜けしている。 これは compilerbook がうまく実装順を整理しているのと、アセンブリの細かい落とし穴を事前に解説して潰していることが大きいと思われる。 + 正直なところ、思ったより早く終わって拍子抜けしている。これは compilerbook がうまく実装順を整理しているのと、アセンブリの細かい落とし穴を事前に解説して潰していることが大きいと思われる。 </p> <p> - 当初の仮説どおり、サポートする機能を慎重に選ぶことにより短期間でセルフホストまで持っていくことができた。 案外簡単に作れてしまうので、まとまった休みに是非いかがだろうか。 + 当初の仮説どおり、サポートする機能を慎重に選ぶことにより短期間でセルフホストまで持っていくことができた。案外簡単に作れてしまうので、まとまった休みに是非いかがだろうか。 </p> </section> </div> diff --git a/vhosts/blog/public/posts/2025-06-14/baba-is-you/index.html b/vhosts/blog/public/posts/2025-06-14/baba-is-you/index.html index aaeb52f7..1283ee2b 100644 --- a/vhosts/blog/public/posts/2025-06-14/baba-is-you/index.html +++ b/vhosts/blog/public/posts/2025-06-14/baba-is-you/index.html @@ -63,7 +63,7 @@ <section id="section--intro"> <h2><a href="#section--intro">Baba Is You とは</a></h2> <p> - <a href="https://www.hempuli.com/baba/" rel="noreferrer" target="_blank">Baba Is You</a> という倉庫番系パズルゲームがある。 私がこれまでプレイしたことのあるパズルゲームの中で、間違いなく最高のパズルゲームだと断言できる。 これより面白いパズルゲームを知っている人は、絶対に買うので教えてほしい。 + <a href="https://www.hempuli.com/baba/" rel="noreferrer" target="_blank">Baba Is You</a> という倉庫番系パズルゲームがある。私がこれまでプレイしたことのあるパズルゲームの中で、間違いなく最高のパズルゲームだと断言できる。これより面白いパズルゲームを知っている人は、絶対に買うので教えてほしい。 </p> <p> すでに押しも押されもせぬ傑作としての名をほしいままにする本作だが、名作の感想はいくつあってもいいので書く。 @@ -77,10 +77,10 @@ <section id="section--no-spoiler--what-is-baba-is-you"> <h3><a href="#section--no-spoiler--what-is-baba-is-you">どういうゲームか？</a></h3> <p> - Baba Is You はいわゆる倉庫番パズルの一種である。 2D のグリッドで操作キャラを動かし、アイテムを押して動かすことでパズルを解く。 + Baba Is You はいわゆる倉庫番パズルの一種である。2D のグリッドで操作キャラを動かし、アイテムを押して動かすことでパズルを解く。 </p> <p> - Baba Is You の特異な点は、倉庫番のルールが盤面上で動かせるオブジェクトとして配置してある点にある。 これは Baba Is You の一番最初の面である。 + Baba Is You の特異な点は、倉庫番のルールが盤面上で動かせるオブジェクトとして配置してある点にある。これは Baba Is You の一番最初の面である。 </p> <p> <img alt="最初の面「BABA IS YOU」のスクリーンショット" src="/posts/2025-06-14/baba-is-you/LEVEL_BABA_IS_YOU.jpeg"> @@ -127,7 +127,7 @@ 最初の状態では、<code>YOU</code> である baba (うさぎや猫のような白い生き物) が <code>WIN</code> である旗に触れることで勝利条件を満たしクリアとなる。 </p> <p> - これらのルールを構成しているテキストを押して動かすことで、ルールをさまざまに変化させることができる。 この面なら一例として次のようなルールが作れるだろう。 + これらのルールを構成しているテキストを押して動かすことで、ルールをさまざまに変化させることができる。この面なら一例として次のようなルールが作れるだろう。 </p> <ul> <li> @@ -161,19 +161,19 @@ </li> </ul> <p> - この「ルール自体を変えられる」という性質により、パズルの難易度・複雑さが大きく上がっている。 プレイヤーは、どのオブジェクトを <code>YOU</code> にするのか、<code>WIN</code> にすべきは何か、どれに <code>PUSH</code> を付けるべきか、いつどの順番でルールを変えるのか、今の手札で作れるルールは何か等と悩みながら、次第に難しくなるパズルと格闘しなければならない。 + この「ルール自体を変えられる」という性質により、パズルの難易度・複雑さが大きく上がっている。プレイヤーは、どのオブジェクトを <code>YOU</code> にするのか、<code>WIN</code> にすべきは何か、どれに <code>PUSH</code> を付けるべきか、いつどの順番でルールを変えるのか、今の手札で作れるルールは何か等と悩みながら、次第に難しくなるパズルと格闘しなければならない。 </p> </section> <section id="section--no-spoiler--play-time-and-difficulty"> <h3><a href="#section--no-spoiler--play-time-and-difficulty">ゲームのボリューム・難易度</a></h3> <p> - 遊べる面の数は「200 以上」ある (Steam ストアページの表記より引用。正確な個数はここでは控える)。 ただしこれは追加 DLC の分を含んでいないので、実際には更に大量にある。 + 遊べる面の数は「200 以上」ある (Steam ストアページの表記より引用。正確な個数はここでは控える)。ただしこれは追加 DLC の分を含んでいないので、実際には更に大量にある。 </p> <p> - パズルゲームなのでプレイ時間には大きくブレがあるだろうが、私の場合はノーヒントで 75 時間弱だった。 ゲーム画面を閉じて紙とペンで考えていた時間を含めれば、+10～+20時間といったところだろうか。 + パズルゲームなのでプレイ時間には大きくブレがあるだろうが、私の場合はノーヒントで 75 時間弱だった。ゲーム画面を閉じて紙とペンで考えていた時間を含めれば、+10～+20時間といったところだろうか。 </p> <p> - パズルの難易度はべらぼうに高い。 ひとつ解くのに数時間かかったり、数日間ひとつも解けなかったりするのはよくある (あくまで全クリを目指す場合)。 + パズルの難易度はべらぼうに高い。ひとつ解くのに数時間かかったり、数日間ひとつも解けなかったりするのはよくある (あくまで全クリを目指す場合)。 </p> <p> 完全クリア以外にもいくつかマイルストーンはあるので、それを目指すのもありだろう。 @@ -187,10 +187,10 @@ <section id="section--no-spoiler--appeal--very-difficult"> <h4><a href="#section--no-spoiler--appeal--very-difficult">高い難易度</a></h4> <p> - すでに書いたが、このゲームは非常に難しい。 ゲームのルールを変えられると聞くと、何でもありの大味なプレイ体験かのように思えるかもしれない。 しかし、適当にルールを弄り回して解けるような面は最序盤くらいにしかなく、ゲームが進んでいくと総当たりすら困難になっていく。 解けない、やれることは全部試したはずだ、ゴールから逆算してもこれ以外ありえないのに実現できない、とにかく解けない。 何度もそう思うことになるだろう。 + すでに書いたが、このゲームは非常に難しい。ゲームのルールを変えられると聞くと、何でもありの大味なプレイ体験かのように思えるかもしれない。しかし、適当にルールを弄り回して解けるような面は最序盤くらいにしかなく、ゲームが進んでいくと総当たりすら困難になっていく。解けない、やれることは全部試したはずだ、ゴールから逆算してもこれ以外ありえないのに実現できない、とにかく解けない。何度もそう思うことになるだろう。 </p> <p> - それにもかかわらず、理不尽だと感じることは驚くほど少ない。 隠された法則・秘密のルールがないというわけではない。 最初の面を再び例に出そう。 <code>ROCK</code> <code>IS</code> <code>PUSH</code> と <code>ROCK</code> <code>IS</code> <code>STOP</code> を同時に成立させたら、岩は押せるのか押せないのか。 <code>PUSH</code> と <code>STOP</code> の優先順は言葉で説明されるわけではないし、自分で試して規則を発見することが求められる。 しかし、実際にゲーム上で試しさえすれば、その規則は明らかな結果となってプレイヤーへと提示されるのである。 これを繰り返すことで、プレイヤーは単語ごとの挙動を、そして Baba Is You を理解していく。 + それにもかかわらず、理不尽だと感じることは驚くほど少ない。隠された法則・秘密のルールがないというわけではない。最初の面を再び例に出そう。<code>ROCK</code> <code>IS</code> <code>PUSH</code> と <code>ROCK</code> <code>IS</code> <code>STOP</code> を同時に成立させたら、岩は押せるのか押せないのか。<code>PUSH</code> と <code>STOP</code> の優先順は言葉で説明されるわけではないし、自分で試して規則を発見することが求められる。しかし、実際にゲーム上で試しさえすれば、その規則は明らかな結果となってプレイヤーへと提示されるのである。これを繰り返すことで、プレイヤーは単語ごとの挙動を、そして Baba Is You を理解していく。 </p> <p> この特徴により、その難易度に比して理不尽さが大きく低減されていると感じる。 @@ -199,10 +199,10 @@ <section id="section--no-spoiler--appeal--very-flexible"> <h4><a href="#section--no-spoiler--appeal--very-flexible">新しい単語との出会い</a></h4> <p> - このゲームには <code>PUSH</code>、<code>STOP</code>、<code>WIN</code>、<code>YOU</code> 以外にもさまざまな単語がある。 新しい単語が導入されるときは大抵チュートリアル用の簡単な面が用意されており、プレイヤーはそこで新単語を使っていろいろと実験をすることになる。 + このゲームには <code>PUSH</code>、<code>STOP</code>、<code>WIN</code>、<code>YOU</code> 以外にもさまざまな単語がある。新しい単語が導入されるときは大抵チュートリアル用の簡単な面が用意されており、プレイヤーはそこで新単語を使っていろいろと実験をすることになる。 </p> <p> - それらの単語の中には、一目で「危険」だとわかる奴らがいる。 <code>YOU</code> や <code>WIN</code> は最初からいる連中だが、普通のパズルゲームなら操作キャラや勝利条件を変えられるだけでもとんでもないルールブレイカーだろう。 + それらの単語の中には、一目で「危険」だとわかる奴らがいる。<code>YOU</code> や <code>WIN</code> は最初からいる連中だが、普通のパズルゲームなら操作キャラや勝利条件を変えられるだけでもとんでもないルールブレイカーだろう。 </p> <p> 危険な匂いのする単語と出会ったときの「こんな単語を許したらとんでもないことになるぞ」という感覚は実際にプレイしなければ味わえない。 @@ -211,10 +211,10 @@ <section id="section--no-spoiler--appeal--very-beautiful"> <h4><a href="#section--no-spoiler--appeal--very-beautiful">美しいパズル</a></h4> <p> - 私が大好きなとある面の話をしよう。 この面は最終盤に出現する。 これは序中盤で出てきたとある面のリメイクであり、ほんの少しだけ手が加えられている。 オリジナルとリメイク版の差分は1マスの窪みがあるかないか。 この一つの差分だけで、難易度が劇的に上昇している。 片や特筆することのない印象の薄い面、片やゲーム内屈指の高難易度面である。 最終盤にあるがゆえになんとか解けるものの、もし配置順が入れ替わりでもしようものなら (難易度の差を考えれば絶対にありえないことだが)、ほとんどのプレイヤーがここで諦めるだろう。 + 私が大好きなとある面の話をしよう。この面は最終盤に出現する。これは序中盤で出てきたとある面のリメイクであり、ほんの少しだけ手が加えられている。オリジナルとリメイク版の差分は1マスの窪みがあるかないか。この一つの差分だけで、難易度が劇的に上昇している。片や特筆することのない印象の薄い面、片やゲーム内屈指の高難易度面である。最終盤にあるがゆえになんとか解けるものの、もし配置順が入れ替わりでもしようものなら (難易度の差を考えれば絶対にありえないことだが)、ほとんどのプレイヤーがここで諦めるだろう。 </p> <p> - これを解いたときは、たった1マスの差でこれだけ難しくできるものなのかと感動した。 他にも似たような例はいくつもある。 素晴しい出来の美しいパズルに何度も何度も出会うことができる。 + これを解いたときは、たった1マスの差でこれだけ難しくできるものなのかと感動した。他にも似たような例はいくつもある。素晴しい出来の美しいパズルに何度も何度も出会うことができる。 </p> </section> </section> @@ -227,7 +227,7 @@ お世辞にも簡単だとは言えないが、苦しむ価値のあるゲームである。 </p> <p> - この次のセクションからはネタバレありの感想を書くが、プレイしていない人はもちろん、プレイ中で完全クリアしていない人も読まないことを勧める。 その価値があるゲームだと保証する。 + この次のセクションからはネタバレありの感想を書くが、プレイしていない人はもちろん、プレイ中で完全クリアしていない人も読まないことを勧める。その価値があるゲームだと保証する。 </p> </section> </section> @@ -237,7 +237,7 @@ ではここからは完全クリアしたプレイヤーに向けて話そう。 </p> <p> - ここでいう「完全クリア」はレベルパックの「Baba Is You」(いわゆる本編) に用意されているパズルをすべて解いた状態を指すことにする。 Steam の場合、全実績解除と読み替えてもよい。 すなわち、「Museum」や「New Adventures」を含まない。 + ここでいう「完全クリア」はレベルパックの「Baba Is You」(いわゆる本編) に用意されているパズルをすべて解いた状態を指すことにする。Steam の場合、全実績解除と読み替えてもよい。すなわち、「Museum」や「New Adventures」を含まない。 </p> <section id="section--spoiler--notation"> <h3><a href="#section--spoiler--notation">表記</a></h3> @@ -267,7 +267,7 @@ </li> </ul> <p> - また、個々のパズルのことはここまでと同様に「面」と呼ぶことにする。 「<code>LEVEL</code> というテキストが指すゲーム上のオブジェクト」は「level」と書く。 + また、個々のパズルのことはここまでと同様に「面」と呼ぶことにする。「<code>LEVEL</code> というテキストが指すゲーム上のオブジェクト」は「level」と書く。 </p> </section> <section id="section--spoiler--impressive-levels"> @@ -287,7 +287,7 @@ </img> </p> <p> - ここまでスルスル解けていて初めてしばらく止まった面。 また、苦戦して解いた次の面がその面の派生で絶望するという経験をした最初の面。 この瞬間が苦しくもあり楽しくもある。 + ここまでスルスル解けていて初めてしばらく止まった面。また、苦戦して解いた次の面がその面の派生で絶望するという経験をした最初の面。この瞬間が苦しくもあり楽しくもある。 </p> </section> <section id="section--spoiler--impressive-levels--map--prison-and-dungeon"> @@ -300,7 +300,7 @@ </img> </p> <p> - 高難易度面で当然のように要求されるテクニックの初出。 可能な行動が大きく制限されているのでマシだが、それでも初見時には困惑した。 + 高難易度面で当然のように要求されるテクニックの初出。可能な行動が大きく制限されているのでマシだが、それでも初見時には困惑した。 </p> </section> <section id="section--spoiler--impressive-levels--map--further-fields"> @@ -310,7 +310,7 @@ </img> </p> <p> - お気に入りの面。 <code>MOVE</code> を活用するのも <code>YOU</code> を一時的に消すのも好きなので、両方出てくるこの面は大好き。 + お気に入りの面。<code>MOVE</code> を活用するのも <code>YOU</code> を一時的に消すのも好きなので、両方出てくるこの面は大好き。 </p> </section> <section id="section--spoiler--impressive-levels--map--scenic-pond"> @@ -330,7 +330,7 @@ </img> </p> <p> - これも初見時に苦戦した面。 PRISON などと同様に一度理解すれば何ということのない面だが、最初に解けたときは偶然だった。 <code>FLAG</code> <code>IS</code> <code>WIN</code> がギリギリ取り出せそうに「見える」のが嫌らしい。 + これも初見時に苦戦した面。PRISON などと同様に一度理解すれば何ということのない面だが、最初に解けたときは偶然だった。<code>FLAG</code> <code>IS</code> <code>WIN</code> がギリギリ取り出せそうに「見える」のが嫌らしい。 </p> </section> <section id="section--spoiler--impressive-levels--map--lock-the-door"> @@ -340,7 +340,7 @@ </img> </p> <p> - <code>SHIFT</code> 重ねの初出面。 このテクニックを再び使うのは終盤になってからであり、私はそのときにはもう <code>SHIFT</code> 重ねを忘れていたので大苦戦した。 戯れにスロット2を使って2周目をやっていてこの面まで到達し、そこでようやく <code>SHIFT</code> 重ねが <code>MOVE</code> もどきになることを思い出した。 その意味でも印象深い面。 + <code>SHIFT</code> 重ねの初出面。このテクニックを再び使うのは終盤になってからであり、私はそのときにはもう <code>SHIFT</code> 重ねを忘れていたので大苦戦した。戯れにスロット2を使って2周目をやっていてこの面まで到達し、そこでようやく <code>SHIFT</code> 重ねが <code>MOVE</code> もどきになることを思い出した。その意味でも印象深い面。 </p> </section> <section id="section--spoiler--impressive-levels--map--insulation"> @@ -350,7 +350,7 @@ </img> </p> <p> - MAP の前半 (～DEEP FOREST) では最も苦戦した面。 <code>SWAP</code> の理解が固まっておらず、「こういう状況が作れたら解けそうだ」という勘が働かなかった。 正直なところ <code>SWAP</code> は今も苦手意識がある (終盤で強制的に学ばされる <code>SHIFT</code> と違って、それほど高難度面での出番がないのも大きいと思う)。 + MAP の前半 (～DEEP FOREST) では最も苦戦した面。<code>SWAP</code> の理解が固まっておらず、「こういう状況が作れたら解けそうだ」という勘が働かなかった。正直なところ <code>SWAP</code> は今も苦手意識がある (終盤で強制的に学ばされる <code>SHIFT</code> と違って、それほど高難度面での出番がないのも大きいと思う)。 </p> </section> <section id="section--spoiler--impressive-levels--map--bottleneck"> @@ -360,7 +360,7 @@ </img> </p> <p> - MAP の中で一番苦しんだ面。 実は一度ここで投げて諦めたのだが、<code>EMPTY</code> を理解した今となっては脳内でも瞬殺できるくらい簡単になってしまった。 最初に面を見てから解き終わるまでの時間は間違いなく最長で、半年以上かかっている (他は長くとも数日間)。 + MAP の中で一番苦しんだ面。実は一度ここで投げて諦めたのだが、<code>EMPTY</code> を理解した今となっては脳内でも瞬殺できるくらい簡単になってしまった。最初に面を見てから解き終わるまでの時間は間違いなく最長で、半年以上かかっている (他は長くとも数日間)。 </p> </section> <section id="section--spoiler--impressive-levels--map--heavy-cloud"> @@ -370,7 +370,7 @@ </img> </p> <p> - 難しい面ではあるのだが、それ以上に解法の美しさに感動した面。 解き終わった後に思わず「美しい……」と呟いてしまったのはこの面だけだった。 Baba Is You の好きな面はと聞かれれば真っ先にこれを挙げる。 + 難しい面ではあるのだが、それ以上に解法の美しさに感動した面。解き終わった後に思わず「美しい……」と呟いてしまったのはこの面だけだった。Baba Is You の好きな面はと聞かれれば真っ先にこれを挙げる。 </p> </section> <section id="section--spoiler--impressive-levels--map--adventurers"> @@ -390,7 +390,7 @@ </img> </p> <p> - MAP の問題児。正攻法がテキスト重ねである最初の面。 この面、<code>ICE/LAVA</code> <code>IS</code> <code>PUSH</code> を作ったあと重なった ice と lava を (<code>ICE</code> <code>IS</code> <code>PUSH</code> だけ作るなどして) 分離しないといけないのだが、意気揚々と ice on lava の状態で door に向かって push して push できなかったときの感情はよく覚えている。 テキスト同士を重ねて <code>A</code> <code>IS</code> <code>PUSH</code> と <code>B</code> <code>IS</code> <code>PUSH</code> を両立させるというぶっ飛んだアイデアを実現してもなお解けないのか、この方針がまさか間違っているなどということがあるのか、いやそんなはずはない……。 実際のところそこからのリカバリーはすぐできたが、そのときの絶望はこれまででも最大であった。 + MAP の問題児。正攻法がテキスト重ねである最初の面。この面、<code>ICE/LAVA</code> <code>IS</code> <code>PUSH</code> を作ったあと重なった ice と lava を (<code>ICE</code> <code>IS</code> <code>PUSH</code> だけ作るなどして) 分離しないといけないのだが、意気揚々と ice on lava の状態で door に向かって push して push できなかったときの感情はよく覚えている。テキスト同士を重ねて <code>A</code> <code>IS</code> <code>PUSH</code> と <code>B</code> <code>IS</code> <code>PUSH</code> を両立させるというぶっ飛んだアイデアを実現してもなお解けないのか、この方針がまさか間違っているなどということがあるのか、いやそんなはずはない……。実際のところそこからのリカバリーはすぐできたが、そのときの絶望はこれまででも最大であった。 </p> </section> <section id="section--spoiler--impressive-levels--map--seeking-acceptance"> @@ -400,7 +400,7 @@ </img> </p> <p> - ここも好きな面。 FURTHER FIELDS の精神的後継のようなものなので当然かもしれない。 せっせと働く bird がかわいい。 + ここも好きな面。FURTHER FIELDS の精神的後継のようなものなので当然かもしれない。せっせと働く bird がかわいい。 </p> </section> <section id="section--spoiler--impressive-levels--map--fragile-existence"> @@ -410,16 +410,16 @@ </img> </p> <p> - MAP の印象的な面と言えば、これを取り上げないわけにはいかない。 <code>LEVEL</code> <code>IS</code> <code>A</code> による level の変換がおこなえる初の面である。 ここまで Baba Is You を進めたプレイヤーであれば、初出のテキストが現れたらまずはその場の色々なテキストと組み合わせてみて相互作用を確認する。 それを見事に利用されたというか、気付かずにはいられないように仕向けられているというか、本当によくできたゲームである。 + MAP の印象的な面と言えば、これを取り上げないわけにはいかない。<code>LEVEL</code> <code>IS</code> <code>A</code> による level の変換がおこなえる初の面である。ここまで Baba Is You を進めたプレイヤーであれば、初出のテキストが現れたらまずはその場の色々なテキストと組み合わせてみて相互作用を確認する。それを見事に利用されたというか、気付かずにはいられないように仕向けられているというか、本当によくできたゲームである。 </p> </section> <section id="section--spoiler--impressive-levels--map--map"> <h5><a href="#section--spoiler--impressive-levels--map--map">MAP</a></h5> <p> - MAP 自身。FRAGILE EXISTENCE でそれに気付いたなら当然 HOSTILE ENVIRONMENT でも気付くし、MAP で baba が操作できることに気付いたならもちろん右下のルールに目を向ける。 次に考えるのは無論こうだ。ここで flag を取ったらどうなるんだ？ このゲームはその疑問に答えてくれる。期待をはるかに上回る形で。 + MAP 自身。FRAGILE EXISTENCE でそれに気付いたなら当然 HOSTILE ENVIRONMENT でも気付くし、MAP で baba が操作できることに気付いたならもちろん右下のルールに目を向ける。次に考えるのは無論こうだ。ここで flag を取ったらどうなるんだ？ このゲームはその疑問に答えてくれる。期待をはるかに上回る形で。 </p> <p> - ??? でまたしても待ち構える <code>BABA</code> <code>IS</code> <code>YOU</code> と不穏な <code>LEVEL</code> のテキスト、そして GLITCH の <code>W</code> <code>E</code> <code>L</code> <code>C</code> <code>O</code> <code>M</code> <code>E</code>。 間違いなく最高のパズルゲームだと確信した。 + ??? でまたしても待ち構える <code>BABA</code> <code>IS</code> <code>YOU</code> と不穏な <code>LEVEL</code> のテキスト、そして GLITCH の <code>W</code> <code>E</code> <code>L</code> <code>C</code> <code>O</code> <code>M</code> <code>E</code>。間違いなく最高のパズルゲームだと確信した。 </p> </section> </section> @@ -432,7 +432,7 @@ </img> </p> <p> - ??? で大いに苦戦した面のひとつ。 PRISON と DUNGEON で既出のテクニックが肝だが、ちと離れすぎじゃないのか。 この面のリメイクもあるが、ここで苦しんだからかそちらはあまり苦戦しなかった。 + ??? で大いに苦戦した面のひとつ。PRISON と DUNGEON で既出のテクニックが肝だが、ちと離れすぎじゃないのか。この面のリメイクもあるが、ここで苦しんだからかそちらはあまり苦戦しなかった。 </p> </section> <section id="section--spoiler--impressive-levels--triple-question--ultimate-maze"> @@ -442,7 +442,7 @@ </img> </p> <p> - 普通に解くだけなら大したことのない面だが、問題はこれの <code>LEVEL</code> <code>IS</code> <code>TEXT</code> 解である。 出現順に書いているのでここに置いたが、解いたのはもっと後、META の後半に差しかかった頃になる。 ??? コンプリートの実績が取れていないことに気付き、残っているとすればここの <code>LEVEL</code> <code>IS</code> <code>TEXT</code> しかないと考えたまではよかったが、そこからが大変だった。 個人的にこのゲームで一番苦しかったのがここの <code>TEXT</code> 変換解である。 単純な難しさに加え、実績が取れていない原因がこの面だという確信も持てなかったので、解けるかどうかわからない状態で挑み続けることとなり疲弊した。 + 普通に解くだけなら大したことのない面だが、問題はこれの <code>LEVEL</code> <code>IS</code> <code>TEXT</code> 解である。出現順に書いているのでここに置いたが、解いたのはもっと後、META の後半に差しかかった頃になる。??? コンプリートの実績が取れていないことに気付き、残っているとすればここの <code>LEVEL</code> <code>IS</code> <code>TEXT</code> しかないと考えたまではよかったが、そこからが大変だった。個人的にこのゲームで一番苦しかったのがここの <code>TEXT</code> 変換解である。単純な難しさに加え、実績が取れていない原因がこの面だという確信も持てなかったので、解けるかどうかわからない状態で挑み続けることとなり疲弊した。 </p> <div class="admonition" editat="2025-06-15" operation="追記"> <div class="admonition-label"> @@ -450,7 +450,7 @@ </div> <div class="admonition-content"> <p> - ??? の DO IT YOURSELF 以降を開くにはこの面の <code>LEVEL</code> <code>IS</code> <code>TEXT</code> が必須だと思っていたのだが、どうもそうではないらしい。 いずれにせよそれを思いつけなかったので同じことか。 + ??? の DO IT YOURSELF 以降を開くにはこの面の <code>LEVEL</code> <code>IS</code> <code>TEXT</code> が必須だと思っていたのだが、どうもそうではないらしい。いずれにせよそれを思いつけなかったので同じことか。 </p> </div> </div> @@ -465,7 +465,7 @@ </img> </p> <p> - 両方とも難しい面ではあったが、単文字のテキストが綺麗に活用された美しい面として印象に残っている。 <code>G</code> <code>R</code> <code>A</code> <code>S</code> <code>S</code> <code>IS</code> <code>H</code> <code>O</code> <code>T</code> をこれほど無駄なく使えるとは！ + 両方とも難しい面ではあったが、単文字のテキストが綺麗に活用された美しい面として印象に残っている。<code>G</code> <code>R</code> <code>A</code> <code>S</code> <code>S</code> <code>IS</code> <code>H</code> <code>O</code> <code>T</code> をこれほど無駄なく使えるとは！ </p> </section> <section id="section--spoiler--impressive-levels--triple-question--getting-together"> @@ -475,7 +475,7 @@ </img> </p> <p> - 初見のインパクト大にして難易度も相応に高い良作。 この頃はまだ <code>SHIFT</code> を<em>理解</em>していなかったので大変だったが、ここを越えたことでむしろこの後の難所が楽になったと言える。 + 初見のインパクト大にして難易度も相応に高い良作。この頃はまだ <code>SHIFT</code> を<em>理解</em>していなかったので大変だったが、ここを越えたことでむしろこの後の難所が楽になったと言える。 </p> </section> </section> @@ -491,7 +491,7 @@ </img> </p> <p> - DEPTHS の序盤で道を塞いでいる必須面であるにもかかわらず圧倒的難易度で立ちはだかる凶悪な面。 大苦戦した挙句 <code>LEVEL</code> <code>IS</code> <code>BELT</code> を作ってアレ？となったのは私だけではないはず。 + DEPTHS の序盤で道を塞いでいる必須面であるにもかかわらず圧倒的難易度で立ちはだかる凶悪な面。大苦戦した挙句 <code>LEVEL</code> <code>IS</code> <code>BELT</code> を作ってアレ？となったのは私だけではないはず。 </p> </section> <section id="section--spoiler--impressive-levels--depths--parade"> @@ -501,7 +501,7 @@ </img> </p> <p> - 取れる行動が多いこと、もう少しで解けそうなルートが多いこと、そのどれもが一筋縄ではいかないこと。 それらがすべて揃った高難度面。 昔のバージョンでは ??? に置いてあったらしい。そんなバカな。 + 取れる行動が多いこと、もう少しで解けそうなルートが多いこと、そのどれもが一筋縄ではいかないこと。それらがすべて揃った高難度面。昔のバージョンでは ??? に置いてあったらしい。そんなバカな。 </p> </section> </section> @@ -517,7 +517,7 @@ </img> </p> <p> - 難しいとか難しくないとかじゃなくここは触れざるをえない。 <code>FLAG/TEXT</code> 解以外はそれほど苦戦しなかったが、とにもかくにもクリアの要求回数が多すぎる。 もちろん最短で進められるなら別だが、META での試行錯誤のためにはこいつの形を毎回変えなければならない。 しかもどの変換もそれなりにステップ数を要するのが厄介である。 印象に残った面であるのは確か。 + 難しいとか難しくないとかじゃなくここは触れざるをえない。<code>FLAG/TEXT</code> 解以外はそれほど苦戦しなかったが、とにもかくにもクリアの要求回数が多すぎる。もちろん最短で進められるなら別だが、META での試行錯誤のためにはこいつの形を毎回変えなければならない。しかもどの変換もそれなりにステップ数を要するのが厄介である。印象に残った面であるのは確か。 </p> </section> <section id="section--spoiler--impressive-levels--meta--the-box"> @@ -527,7 +527,7 @@ </img> </p> <p> - よくぞこの面を作ってくれた。 外の level を参照させるギミックは、<code>LEVEL</code> <code>IS</code> <code>A</code> の変換をやりだした頃からいつかあるはずと思っていたので、そのとおりのパズルが出てきてくれて嬉しい。 これぞ Baba Is You。 + よくぞこの面を作ってくれた。外の level を参照させるギミックは、<code>LEVEL</code> <code>IS</code> <code>A</code> の変換をやりだした頃からいつかあるはずと思っていたので、そのとおりのパズルが出てきてくれて嬉しい。これぞ Baba Is You。 </p> </section> <section id="section--spoiler--impressive-levels--meta--the-return-of-scenic-pond"> @@ -537,7 +537,7 @@ </img> </p> <p> - 前半のネタバレなし感想にも書いたが、これは SCENIC POND のリメイクであり、ほとんど差異がない。 たった1マス窪みが無くなっただけである。 それだけでここまで難しくできるのか。 + 前半のネタバレなし感想にも書いたが、これは SCENIC POND のリメイクであり、ほとんど差異がない。たった1マス窪みが無くなっただけである。それだけでここまで難しくできるのか。 </p> <p> 最終盤に配置されていたことで難易度の割には苦戦しなかったが、難易度以上にリメイクの美しさに感動した面。 @@ -548,7 +548,7 @@ <section id="section--spoiler--difficult-levels"> <h3><a href="#section--spoiler--difficult-levels">初見時難易度ランキング</a></h3> <p> - 最後に、初見時の難易度を 10 位までランキングにしてみた。 あくまで初見のときの難易度なので、面自体の難易度ではない。 解くのにかかった時間とも少し違う。 あえて言うなら苦しんだ順。 + 最後に、初見時の難易度を 10 位までランキングにしてみた。あくまで初見のときの難易度なので、面自体の難易度ではない。解くのにかかった時間とも少し違う。あえて言うなら苦しんだ順。 </p> <ol> <li> |