どうも、みずかずです。

ここ最近、物欲センサーが反応しっぱなしで夜な夜なスペックシートや海外レビューを眺めてしまっているガジェットがあります。

それが、中華携帯ゲーム機「TRIMUI Smart Pro S（TSPS）」。

名機として人気の高かった「TRIMUI Smart Pro」のマイナーチェンジ・強化版にあたるモデルなのですが、これが今、僕の中で「買わない理由を探すほうが難しい」レベルで刺さっています。

今回は、数ある中華エミュ機の中からなぜ僕がこの機種に辿り着いたのか、その選定理由と手元にある実機カセットの思い出を交えて整理してみました。

初めてのエミュ機選び。なぜ「5インチ横型」なのか？

中華エミュレーター機の世界は今や群雄割拠で、AnbernicやMiyooなどから毎週のように新機種が出ています。

そんな中、「エミュ機を初めて買う1台目」として自分の中で絶対に譲れない条件を設定した結果、自然と選択肢が絞られていきました。

1. 縦型（ゲームボーイ型）を見送った理由

レトロゲーム機といえば「ゲームボーイ型（縦型）」がアイコニックで、見た目もレトロ感があって可愛いですよね。同メーカーの「TRIMUI Brick」や「Miyoo Mini」あたりもかなり魅力的でした。

ですが、今回はあえて縦型を候補から外しました。

理由はシンプルで、「長時間のプレイで手が疲れる」ことと、「画面サイズに限界がある」からです。

今回は腰を据えてじっくりダンジョンに潜ったり、モンスターを育成するゲームをやり込みたい。となると、両手でしっかりとホールドでき、指の配置に無理がない横型配置が必須でした。

2. 「最低でも5インチ前後」の視認性が欲しい

携帯機とはいえ、3.5インチ前後の画面だと大人になった今の目にはテキストやドット絵がどうしても小さく感じてしまいます。

• スマホより一回り小さくても、しっかり迫力と見やすさを確保できるサイズ感
• 等倍スケーリングやベゼル（黒帯）を考慮しても文字が潰れない余裕

これを満たす落としどころが「最低でも5インチ前後」でした。

TRIMUI Smart Pro Sの4.96インチ（1280×720）IPS液晶は、大きすぎず小さすぎず、携帯性と視認性のバランスが絶妙です。

3. 最初だからこそ「1万円前後の手頃さ」で収めたい

もちろん、2万〜3万円出せばAndroid搭載機やハイエンド機（Retroid PocketやOdinなど）も選べます。

ただ、今回はあくまで「初めてのエミュ機」であり、主な用途はPS1やGBAなどのレトロゲーム。オーバースペックで高額なデバイスを買うより、1万円台前半で気軽にポチれて、道具としてガシガシ使い倒せる価格感が理想でした。

既存モデルから正統進化した「Smart Pro S」の魅力

横型・5インチ・低価格という条件だけなら無印の「TRIMUI Smart Pro」でも満たせるのですが、あえて強化版の「S」を待っていた理由があります。

• Allwinner A523搭載＆アクティブ冷却ファンの追加
  SoCの刷新に加え、ファンが搭載されたことで熱対策と動作安定性が向上。長時間のプレイでも熱ダレを気にせず遊べる安心感があります。
• Wi-Fi 6 / Bluetooth 5.4の足回り強化
  レトロゲーム機とはいえ、ワイヤレス周りがしっかり最新規格に対応しているのはガジェット好きとしてそそられるポイント。
• PS Vitaを彷彿とさせるビルドクオリティ
  マットなサラサラ質感のシェル、押し心地の良いボタン、スティック周りの控えめなLEDなど、所有欲をしっかり満たしてくれるデザインも健在です。

手元にある2本の名作GBAカセットをもう一度やり込みたい

「どんなゲームを遊ぶために買うのか？」

ここが一番の原動力です。部屋の棚を整理していたら発掘された、この2本の実機カートリッジ。

• 『トルネコの大冒険3アドバンス 不思議のダンジョン』
• 『ドラゴンクエストモンスターズ キャラバンハート』

どちらもGBA時代に狂ったように遊んだ名作中の名作です。手元にあるカセットを見つけた瞬間、「あ、これ綺麗な大画面で最初からやり直したいな……」という衝動が爆発しました。

1. 『トルネコの大冒険3アドバンス』を大画面＆どこでもスリープで

言わずと知れた1000回遊べる名作ローグライク。

PS2版から追加要素が増えたアドバンス版ですが、異世界の迷宮やポポロでのモンスター勧誘など、とにかく時間を溶かす要素が満載です。

実機のGBAだと「バックライトがなくて暗い」「画面が小さくて見づらい」というハードルがありますが、Smart Pro Sの綺麗なIPS液晶とスリープ復帰機能があれば、布団の中でじっくり1ターンずつ考えながら進める……想像しただけで至福の時間です。

2. 『キャラバンハート』の独特な世界観をもう一度

DQMシリーズの中でも、馬車システムやガードモンスター、食料の概念など、独特な手触りと旅情がある『キャラバンハート』。

あのドット絵の質感やフィールド曲の雰囲気は、大人になった今だからこそじっくり味わい直したいところ。横型でしっかりホールドできる筐体なら、長時間の育成・移動作業も疲れずに楽しめそうです。

GBAの「3:2」画面と「16:9」の相性はどうなのか？

TRIMUI Smart Pro Sの画面比率は16:9（1280×720）。

一方で、GBAの画面比率は3:2（240×160）です。

4:3の画面を持つ機種に比べると、16:9の画面はGBAを等倍スケーリング（整数倍）で表示したときに、左右の黒帯（ベゼル）が比較的少なめで綺麗に収まります。

画面いっぱいに引き伸ばしてドットを歪ませるのではなく、アスペクト比維持＋お気に入りのカスタムオーバーレイ（ベゼルアート）を配置して表示させれば、5インチ液晶の恩恵を受けつつレトロな雰囲気を存分に楽しめそうです。

まとめ：おそらく近日中にポチります

• 「スマホのエミュレーターだと物理ボタンの押し心地がなくて味気ない」
• 「Nintendo Switchを持ち出すほどではないけど、しっかりした大画面でレトロゲームがしたい」
• 「1万円台前半で、所有欲を満たしてくれるビルドクオリティの横型機が欲しい」

そんな僕の今の気分に、TRIMUI Smart Pro Sはこれ以上ないくらいドンピシャにハマっています。

海外通販（AliExpressやMechdiyなど）のセールや在庫状況をチェックしつつ、近いうちにポチることになりそうです。

実際に手元に届いたら、外観の質感やボタンの押し心地、GBAを動かしたときの画面の見え方など、詳しい実機レビューを書きたいと思います！

どうも。みずかず（@mizukazu_1）です。

先日、WordPress本体に深刻な脆弱性「CVE-2026-87902」が見つかりました。

きっかけは、僕が利用しているXserver（エックスサーバー）から届いた「【重要】WordPressの脆弱性に関するご案内」というメールでした。

セキュリティの通知って、メールを開いた瞬間に「えっ、自分のサイト攻撃されたの？」「何かヤバいこと起きてる？」と一瞬焦りますよね……。

結論から言うと、すでに実際の攻撃への悪用が確認されている危険度の高い脆弱性のため、WordPressを運営している方は早急な確認とアップデートが必要です。

この記事では、CVE-2026-87902の概要や危険性だけでなく、「エックスサーバーから通知が来たけど結局何をすればいいの？」「自分のサイトは安全？」という方向けに、確認手順と具体的な対処法を分かりやすくまとめました。

【3秒でわかる要点まとめ】

1. 何が起きた？：WordPress本体に任意のファイルを実行される重大な脆弱性（CVE-2026-87902）が発覚
2. 対象は？：WordPress 4.7.0 〜 7.1.1 の各ブランチ（すでに悪用事例あり）
3. やるべきこと：管理画面の「ダッシュボード → 更新」から修正済みバージョンへアップデートする（Xserver側で自動適用されている場合もありますが、確認は必須）

そもそもCVE-2026-87902とは？何が危険なの？

CVE-2026-87902は、WordPressのページテンプレートを探す処理（テンプレート解決処理）にある「パストラバーサル」の脆弱性です。

パストラバーサルによるリモートコード実行のリスク

パストラバーサルとは、ファイルパスの制限が甘いことで、本来アクセスできないはずのディレクトリやファイルにアクセスされてしまう問題のことです。

今回の脆弱性では、ログインしていない外部の第三者（未認証の攻撃者）が、テーマのディレクトリ外にあるサーバー上のPHPファイルを勝手に読み込ませることができてしまいます。

その結果、条件が揃うとサーバー上で不正なプログラムを実行される「リモートコード実行（RCE）」につながる恐れがあります。

• CVSS 4.0 スコア：9.2（深刻度：Critical）
• 攻撃の前提条件：
  • 有効化しているテーマ内に page- から始まるディレクトリが存在する
  • サーバー上に読み取り可能な対象PHPファイルが存在する
  • など、環境やテーマの構成によって条件が左右されます。

「うちのテーマは大丈夫かも？」と思っても、攻撃手法が広まると予期せぬ形で悪用されるリスクがあります。CVSS 9.2という数値からも分かる通り、放置は厳禁です。

影響を受けるWordPressのバージョン一覧

公式アドバイザリによると、WordPress 4.7.0 から 7.1.1 までの幅広いブランチが対象となっています。

今回の対応では、最新版（7.1系）だけでなく、過去のメジャーブランチに対してもセキュリティ修正版が一斉にリリースされています。

※上記より古い6.6以前のブランチにも修正版が配布されています。

なお、WordPress 4.6以前はそもそもセキュリティアップデートのサポートが終了しているため、これを機に安全なバージョンへ移行することをおすすめします。

エックスサーバーからメールが来た時の対処法・確認手順

エックスサーバー等から通知が届いた場合、次のステップで自分のサイトの状態を確認・対処しましょう。

手順1：現在のバージョンを確認する

まずはWordPressの管理画面にログインします。

1. 左メニューの「ダッシュボード」→「更新」をクリック
2. 画面上部に表示されている「現在のバージョン」を確認する

ここで先ほどの表にある「修正済みバージョン」になっていれば、ひとまずこの脆弱性への対策は完了しています。

エックスサーバーで勝手に更新されている場合もある？

エックスサーバーなどの一部ホスティング会社では、危険度が高い脆弱性に対してサーバー側で一括のセキュリティアップデートや緩和策を実施するケースがあります。

「メールを見て確認したら、すでに修正済みバージョンになっていた」という場合は、サーバー側の自動更新やWordPressのバックグラウンド更新が働いた証拠ですのでご安心ください。

手順2：手動でアップデートを実行する（未更新の場合）

まだ古いバージョンのまま残っている場合は、画面に表示されている「今すぐ更新」をクリックしてアップデートを行います。

• 注意点：アップデート前には、万が一のプラグイン競合や画面崩れに備えて必ずバックアップ（サーバー機能やバックアッププラグイン）を取得しておきましょう。

手順3：更新後の動作確認を行う

アップデート完了後は、以下の3点をサクッと確認します。

• ブログのトップページや個別記事が正常に表示されるか
• お問い合わせフォームなどの主要機能がエラーになっていないか
• 管理画面からログアウトし、正常に再ログインできるか

すでに攻撃を受けていないか心配なときは？

シンガポールのサイバーセキュリティ機関（CSA）の発表などによると、CVE-2026-87902はすでに実際のサイバー攻撃で悪用された事例が報告されています。

もし「長期間放置してしまっていた」「サイトの挙動がなんだかおかしい」と感じる場合は、以下のポイントをチェックしてみてください。

1. 見覚えのない管理者ユーザーがいないか
   • 管理画面の「ユーザー」一覧を開き、身に覚えのない管理者（administrator）アカウントが勝手に追加されていないか確認します。
2. 怪しいファイルが生成されていないか
   • FTPやファイルマネージャーで wp-content やルートディレクトリを見た際、ランダムな英数字の怪しい .php ファイルが置かれていないか確認します。
3. サーバーのアクセスログ
   • 不正なパストラバーサル試行（URLに奇妙なパラメータやパスが含まれるリクエスト）が多発していないかログを確認します。

不審な痕跡を見つけた場合は、速やかに管理パスワードの変更やサーバー会社への相談を行ってください。

まとめ：セキュリティ通知を見かけたら即確認が鉄則！

今回は、WordPressの脆弱性「CVE-2026-87902」の概要と対処法について解説しました。

• ページテンプレート処理に起因するパストラバーサルの脆弱性（CVSS 9.2）
• 条件が揃うと未認証で任意のPHPを実行される恐れがある
• 対象は WordPress 4.7.0 〜 7.1.1
• 管理画面の「ダッシュボード → 更新」から修正バージョンへ即時アップデートする
• エックスサーバー等で自動更新されている場合も、一度バージョン確認をしておくと安心

セキュリティアップデートの通知って後回しにしてしまいがちですが、放置しておくとサイトの改ざんや乗っ取りに発展するリスクがあります。

通知メールが届いた方やまだバージョンを確認していない方は、ぜひ今すぐ管理画面をチェックしてみてくださいね！

どうも。みずかずです。

今回はニゴイングについて書いてみます。

結論から言うと、ニゴイはもっと評価されていい魚だと思っています！

最近、川でルアーを投げていて前より明らかに気になる魚がいます。ニゴイです。

シーバス狙いの外道として掛かったり、バス釣りのゲストとして出てきたり、どちらかというと本命扱いされにくい魚なんですが、ちゃんと見ていくとこの魚かなり面白い。

引きは強いし、身近な河川にいるし、流れの中で掛かるとかなり気持ちよくロッドを曲げてくれます。しかもルアーでしっかり狙って釣る余地がある。

まだ自分の中でも研究途中ではあるのですが、最近の実釣感覚と、ニゴイの生態に関する論文を合わせて整理すると、ゲームフィッシングの対象魚としてかなり優秀なんじゃないかと思っています。

この記事では、まずニゴイがどんな魚なのかを軽く整理して、そのうえで実際に川で見ていて感じる面白さ、狙いどころ、タックルの話まで書いていきます。

この記事で書くこと

• ニゴイの生態をざっくり整理
• 実際に川で見ていて感じるニゴイの面白さ
• ニゴイがゲームフィッシュとして優秀だと思う理由
• ニゴイングで使いやすそうなタックルとルアー

なお、生態に関する記述は主に筑後川の研究を参照しています。自分の現場感に基づく部分とは分けて読めるようにしておきます。^[1][2]

まずニゴイってどんな魚なのか

ニゴイは Hemibarbus barbus とされる日本の淡水魚で、研究ベースで見るとかなり広い環境を使っている魚です。^[1][2]

ニゴイは、思っている以上に広い環境を使っている魚です。

筑後川での調査では、未成魚の多くが感潮域の淡水域で周年確認され、成熟した個体は春に20kmから40kmほど遡上して産卵するとされています。主な産卵期は4月です。^[1]

食性についてもかなり面白くて、成長に応じて動物プランクトンからユスリカ幼虫などの底生動物、さらにシジミ類や小魚まで利用することが報告されています。2歳以上の個体の消化管からはウナギの稚魚やモクズガニ幼体も確認されています。^[2]

このあたりを踏まえると、ニゴイって単に底で何かをついばんでいる魚ではなくて、流れの中でかなり柔軟に餌を使い分けている魚なんですよね。だからこそルアーにもちゃんと反応する余地があるんだろうなと思っています。

最近川で見ていて思うこと

ここからはかなり実体験寄りの話です。

ここから先は、自分が実際に川で見ていて感じていることベースです。

最近、中規模河川や都市河川でルアーを投げていて思うのが、ニゴイって思っていた以上に「流れの中のいい場所」に入っていることが多いということです。

流芯のど真ん中にべったりいるというよりは、流れが少し緩むラインだったり、橋脚や護岸でヨレができる場所だったり、瀬が終わるところの少し落ち着くところだったり、そういう場所にいる印象があります。

このへんは、もちろん全く同じではないにしても、シーバスと少し似た生態を持っている感じがするんですよね。流れが当たる場所と緩む場所、その境目の使い方がどことなく近いというか、見ていてちょっと重なる部分があります。

あと、掛かったときのファイトが想像以上にいいです。

正直、最初は「ニゴイかあ」で終わっていた時期もあったんですが、流れのある場所でいいサイズが掛かると全然そんなことない。下流に走るし、足元でも最後まで暴れるし、雑に寄ってこない。

この感触を何度か味わうと、外道というより普通にかなり面白いターゲットだなと思うようになります！

しかも、ミノーや小型バイブ、小さめのスピンテールを流れに合わせて通したときに反応が変わる感じがある。ここがすごく大事で、適当に投げてもたまたま掛かるだけの魚ではなさそうなんですよね。

ニゴイはゲームフィッシングの対象魚としてかなり優秀だと思う

自分がそう思う理由は大きく3つあります。

身近で、強くて、考える余地がある。 この3点がかなり大きいです。

1つ目は、身近な河川で成立しやすいことです。

人気ターゲットほど情報が多すぎず、でも魚はちゃんといる。このバランスがかなり良いです。仕事終わりに1時間だけ見に行くみたいな通い方がしやすいので、研究対象としても優秀です。

2つ目は、掛けてからがちゃんと面白いことです。

ただ釣れるだけだとハマりにくいですが、ニゴイはファイトがいい。流れを使う魚なので、同じサイズでも止水の魚とは違う面白さがあります。

3つ目は、ルアーへの反応を考える余地があることです。

さっきの論文でも、ニゴイは成長に応じて食性をかなり変えていますし、底生動物だけでなく魚や甲殻類も使っています。^[2] そう考えると、流れの中でルアーを追ったり食ったりするのは全然不自然ではないです。

しかも専用タックルがなくても始めやすい。シーバス、チニング、長めのバスロッドあたりから入れるのでハードルも低いです。

この入りやすさも、ニゴイングのかなりいいところです。

自分ならこんな場所から探す

今のところ、自分がニゴイを狙うならまず見るのは流れです。

まずは「流れが変化する場所」を優先して見ていくのが良さそうです。

具体的にはこんな場所です。

• 橋脚周り
• 流れがヨレる場所
• 瀬の落ち込み
• 護岸際のえぐれ
• 水深変化のある場所

このあたりを見ていると、ニゴイはただベタ底に張り付いているというより、流れの変化の中でポジションを取っている魚として見た方がしっくりきます。

シーバスみたいに明暗だけを撃つ感じではなくて、もっと素直に流れと地形を見る釣りになりそうです。見える魚だけをサイトで追いかけるより、いそうな筋にきっちり通して反応を取る方が再現性はありそうだなと思っています。

ニゴイングのタックルはこのくらいがやりやすそう

ここもまだ試行錯誤中ですが、今のところは「流れのある川で7gから15g前後のルアーを扱いやすいタックル」がちょうどよさそうです。

最初から専用タックルを組むというより、手持ちのシーバス、チニング、バス用タックルから入るのが現実的だと思います。

ロッド

• 7ft台後半から8ft台前半くらいのLからMLクラス

シーバスロッドならライト寄り、バスロッドなら少し長め。このあたりがかなり使いやすそうです。

柔らかすぎると流れの中で主導権を取りにくいし、強すぎると今度はルアーの扱いや面白さが落ちる。この中間くらいが良さそうです。

リール

• 2500番から3000番くらいのスピニング

飛距離も出しやすいし、PEも扱いやすいので、まずはスピニングで始めるのが無難だと思います。

ライン

• PE0.6号から1号
• リーダー10lbから16lb前後

流れの中で掛けることを考えると、あまり攻めすぎた細糸よりは少し余裕が欲しいです。魚体よりも、石や護岸、流れの強さを見てラインを決める方がいい気がしています。

タックルの要点だけ先にまとめると

• ロッドはLからMLくらいの少しライト寄り
• リールは2500番から3000番のスピニング
• ラインはPE0.6号から1号くらいで少し余裕を持つ

ルアーは何が軸になりそうか

今のところ反応を見たいのはこのへんです。

「強すぎないけど存在感はある」ルアーが軸になりそうです。

• 小型から中型のバイブレーション
• スピンテール系
• 小型ミノー
• シャッド系
• ボトムを取りやすいメタルルアー

論文ベースでも、成長したニゴイは底生動物だけではなく、より大きな餌資源も使っています。^[2] なので、ボトムべったりの釣りだけに寄せず、流れに乗せて少し上のレンジを通すのもかなり有効なんじゃないかと思っています。

個人的には、巻き抵抗が強すぎないルアーの方が相性が良さそうです。流れの中で自然に動いてくれるものを、少しスロー寄りに通すイメージです。

ガチャガチャ速く巻くというより、流れに仕事をさせるイメージの方が合っていそうです。

ニゴイングの何が面白いのか

結局これって、未開拓感なんだと思います。

シーバスほど情報が多いわけでもないし、バスみたいにセオリーが細かく整理されているわけでもない。でも魚はちゃんといて、しかも面白い。

だから、自分で考えたことがそのまま釣果や反応に返ってきやすい釣りになる可能性があります。

ルアーを変える、コースを変える、通すレンジを変える。それで答えが返ってくるなら、もう十分ゲームフィッシュとして魅力的です。

この「自分で考える余地」があるのが、ニゴイングの一番面白いところかもしれません！

最後に

ニゴイって、どうしても地味な魚扱いされがちです。

でも実際は、身近な河川で狙えて、引きが強くて、ルアーで考える余地もある。しかも研究を読むと、生態的にもかなり面白い魚です。^[1][2]

最近は本気で、ニゴイはゲームフィッシングの対象魚としてかなり優秀なんじゃないかと思っています。

まだ自分の中でも仮説段階の部分は多いですが、だからこそしばらく追いかける価値がある。今後もっと釣行を重ねて、ルアーや季節ごとの傾向まで見えてきたら、そのあたりも改めて書いてみようと思います。

ニゴイング、かなり伸びしろがある釣りだと思います！

引用・参考文献

1. 竹下直彦, 木村清朗. 筑後川におけるニゴイの回遊について. 日本水産学会誌, 57巻5号, 1991, p.869-873.
   DOI: https://doi.org/10.2331/suisan.57.869
2. 竹下直彦, 木村清朗. 筑後川におけるニゴイの食性. 日本水産学会誌, 61巻6号, 1995, p.860-867.
   DOI: https://doi.org/10.2331/suisan.61.860

どうも。みずかず(@mizukazu_1)です。

今回は趣味の一つである釣りの釣行記です。
今後はこういった趣味関連の記事も書いていこうかなと思っています。

2月の潮周りのよいタイミングで何回かバチ抜け釣行に行ってきました。
計4,5回くらい行ったかな？
バチが結構抜けてる日も多かったのですが残念ながら釣れたのは2月20日の一日だけでした。

この記事を書いてるのが3月下旬でして、3月も2回くらいバチ抜け釣行に行ってるのですが自分は全然ダメです。
ハクが多く入ってきてる日もあってバチが抜けても食わないっていうこともありました。

2月20日から約1ヵ月ほど経っていて、なおかつ当日の状況をメモしていないので思い出しながら書いていきます、、、！

当日の状況

この日は大潮後の中潮2日目でした。
タイドグラフを遡れなくて分からないのですが満潮時刻がだいたい18:30～19:00だったと思います。

釣り場に着いたのが満潮と同時くらいでその時はあまり流れが効いておらず、釣りを始めて少ししてから流れ出してそのタイミングでバチも抜け始めてポツポツライズが出るっていう状況でした。

バチの量

バチの量は程よい感じでした。
バチソーメンを恐れていたのですが後中2日目で川幅も広いこともあり釣りにならない！っていうレベルで抜けることはありませんでした。

時合いがくる

釣りを始めて約1時間くらいしてバチも流れ始めてきてライズが出るようになります。
このタイミングで釣ることが出来ました。
3キャッチ、1匹目が82cmのランカーでした。

人生初ランカーを釣ることができたのでめちゃくちゃテンション上がりました！！

使用したルアー

ノガレ160F 銀粉チャートブラックベリー
ヒソカ120F オレンジパールギーゴ

ノガレは引き波系のルアーで巻き抵抗はほぼないので若干苦手意識がありましたが今回の釣行で間違いなくバチ抜けシーズンの1軍ルアーへと昇格されました、、、！！

ヒソカは今回の釣行で初めて使ったのですがバチ抜けだけじゃなくて他のシーズンでも使えそうだなっていう印象を受けました。
なによりオレンジパールギーゴのカラーがすごくいい。めっちゃ好き。

ヒットしたシチュエーション

ノガレもヒソカも投げてほとんど放置してる間に釣れました。
流れが結構あったので投げて糸ふけだけ回収するようなイメージでリールを巻いていても勝手に流れて勝手に水を掴んで勝手にアクションしてくれるっていう感じです。

もう少し詳しく書いておきます。

1匹目ですがノガレをクロスに投げてそのまま放置してました。
糸ふけだけ回収する感じです。

バチ抜けてるかな～と思い足元をライトで照らして見てたんですがその時にルアーがダウンに入ったくらいのあたりでライズ音。
自分のルアーかもしれないと思って一応合わせたらロッドがグッとしなりヒット。

82cmのパワフルなランカーシーバスでした。

2匹目はヒソカを投げてゆっくり巻きつつ基本放置。
ダウンに入ったまま放置してさっきと同じように足元のバチを見てたらルアーの方向からライズ音。
合わせを入れてヒット。

3匹目はヒソカをアップにキャスト。
着水してすぐにライズ。
合わせを入れてヒット。

こんな感じの使い方をしてました。
最近思ったことなんですが、想像してるより全然巻かない方が魚は釣れるなっていう。
シンペンとかバイブレーションとかも巻き抵抗を受けないくらいで巻いてる方が反応が良かったりします。(個人の意見です)

使用タックル

ロッド：シマノ ディアルーナ86ML
リール：シマノ 24ヴァンフォードC3000XG
PEライン：ピットブル 8+ 0.8号
リーダー：FLUORO SHOCK LEADER 16lb

最後に

今回のバチ抜け釣行は3本キャッチ内ランカー1匹ゲットできたので最高に楽しかったです。

ノガレ、ヒソカは巻かずとも釣れるということが分かり、これはおそらくこの2つのルアーに限ったことではなくてバチ抜けルアー全般に当てはまるんじゃないかと。とても学びの多い釣行でした。

今年の川バチは終了しましたが今年は港湾でのくるくるバチ、ハクパターンもしっかりやろうかなと考えてます！

ブログ自体は全然更新してないしアクセス数もないのでいいんですが何となく気になったのでエラー対応してみました。

今回の方法はLION BLOG公式が出してるものではないのでもし同じようにやってみる人がいる場合は自己責任でお願いします。

どんなエラーが出てたか

エラーはこんな感じです。

Fatal error: Uncaught Error: Call to undefined function create_function()

create_function()という関数がないよーって言われてますね。

調べてみるとこのcreate_function()という関数がPHP8.1では削除されたみたいです。

https://www.php.net/manual/ja/function.create-function.php

なのでテーマの中で使用されているcreate_function()を代わりのものに置き換える必要があります。

create_function()は2箇所で使用されている

LION BLOGのテーマのコードを検索するとcreate_function()が使われているところが2箇所あります。

functions.phpの4514行目と4611行目です。

add_action( 'widgets_init', create_function( '', 'return register_widget( "AdWidgetItemClass" );' ) );

add_action( 'widgets_init', create_function( '', 'return register_widget( "Popular_Posts" );' ) );

解決方法

create_function()を無名関数に置き換える

create_function()は動的に関数を作成する関数です。

PHP8.1では無名関数が使えるので以下のようにadd_actionの第二引数に直接関数を渡します。

add_action( 'widgets_init', function() { return register_widget( "AdWidgetItemClass" ); } );

add_action( 'widgets_init', function() { return register_widget( "Popular_Posts" ); } );

これでエラーが出なくなりブログが正常に動作しました。

最後に

今回の対応は公式がサポートしているやり方ではないのでもし同じ対応をする場合には自己責任でお願いします。
サイトを復旧させたい場合などの応急処置には良さそうですが実運用するには望ましくないと思われます、、、

今後も同じようなエラーが出てくると思いますので早めに他のテーマに変更するのがおすすめです。

「Vike」って知っていますか？

Vikeは、ViteをベースにSSRやSSGなどのレンダリング方法を選べるようにするフレームワークです。Reactだけに限らず使えますが、Reactを使う場合は公式の vike-react を組み合わせます。

もともとはViteのプラグイン vite-plugin-ssr として知られていたものが、現在のVikeにつながっています。「Vikeの意味」や「ViteとVikeの違い」を調べている場合は、Viteがビルドツール、Vikeがその上でルーティングやSSR・SSGを扱うためのフレームワーク、と考えると分かりやすいです。

Viteが開発・ビルドの土台で、VikeがルーティングやSSR・SSGを担当します。Reactで使うときは、vike-react を組み合わせてページの描画を構成します。

Vite × ReactでSSGを使いたいと思って探していたところ見つけたのですが、動的ルートのSSGで少しだけハマったので、現行仕様を確認しながらまとめ直しました。

公式ドキュメントは以下です。

Vike公式ドキュメント

VikeでSSGするための基本設定

SSGは、ビルド時にHTMLを生成しておく方式です。Vikeでは、現在は vite.config.js のプラグインにSSG用のオプションを渡すのではなく、ページ側の + ファイルで設定します。

まず、vite.config.js のVikeプラグインは次のように読み込みます。

import vike from 'vike/plugin'

export default {
  plugins: [vike()]
}

SSGの設定は、ページディレクトリの +config.js に書きます。

export default {
  prerender: true
}

そのうえで vike build を実行すると、対象ページのHTMLがビルド時に生成されます。生成先は通常 dist/client/ です。

古い記事やサンプルで見かける vite.config.js 側のSSG設定ではなく、現行の公式案内では +config.js などの + ファイルにVikeの設定を置く 形が基本です。

参考
Vike公式：Pre-rendering
Vike公式：Vite plugin
Vike公式：設定ファイルの移行

ReactアプリでVikeを使う

既存のVikeアプリにReactを追加する場合は、公式の vike-react をインストールします。

npm install vike-react

そして pages/+config.js でReactの設定を拡張します。

import vikeReact from 'vike-react/config'

export default {
  prerender: true,
  extends: [vikeReact]
}

ページのコンポーネントは、例えば次のように +Page.jsx に作成します。

export default function Page() {
  return <h1>Vike + React</h1>
}

参考
Vike公式：vike-react

動的ルートをSSGさせる

ただ、これだけでは /category/@slug のような動的ルートの全ページを自動で生成できません。

動的ルートをSSGするには、ビルドプロセスの中でVike側に生成対象のURL一覧を渡します。

そのために onBeforePrerenderStart() というフックを使います。名前の通り、プリレンダリングの前に実行されるフックです。

このフックが実行されるのは、基本的に vike build でプリレンダリングするときです。開発中の vike dev では実行されないので、動的ページのURL一覧を確認するときはビルド時のログを確認します。

export default '/movie/@movieId'

export { onBeforePrerenderStart }

async function onBeforePrerenderStart() {
  const movies = await Movie.findAll()
  const moviePageURLs = movies.map(movie => '/movie/' + movie.id)
  return moviePageURLs
}

生成したいパスを配列に詰めて返しているだけですね。

実際のコードに当てはめてみた

今回作成していたサイトには /category/@slug という動的ルートがありました。例えば、カテゴリ一覧からURLを作るなら次のようになります。

export default '/category/@slug'

export { onBeforePrerenderStart }

import { categories } from '../../../constants'

async function onBeforePrerenderStart() {
  const categoryPageURLs = categories.map(
    category => '/category/' + category.slug
  )

  // 同じURLを複数回返さない
  return [...new Set(categoryPageURLs)]
}

エラーが発生する

ここで少しハマりました。ドキュメントの通りにファイルを作成したのですが、次のようなエラーが出ました。

Error: [vike][Wrong Usage] URL /category/work provided twice by the onBeforePrerenderStart() hook (/pages/category/+onBeforePrerenderStart.ts). Make sure to provide the URL only once instead.

同じURLが複数出ているので、1回だけ返してほしいという意味です。カテゴリの元データに同じslugが含まれていたり、複数の処理で同じURLを追加していたりすると発生します。

まずは onBeforePrerenderStart() が返す配列を確認して、重複を取り除きます。上の例では Set を使っています。

また、次の点も確認します。

• +route.js で定義しているパスと、返しているURLの形が一致しているか
• 同じ動的ルートを別の場所でも定義していないか
• categories の中に同じ slug が入っていないか

解決方法

今回の構成では、次のように index ディレクトリの中へファイルを移動することで解決しました。

/category/+route.js
/category/+onBeforePrerenderStart.js

↓

/category/index/+route.js
/category/index/+onBeforePrerenderStart.js

このように index というディレクトリを作ってその中に入れる方法です。

これはすべての重複URLエラーに効く万能な解決方法ではありません。まず返却URLの重複とルート定義を確認し、それでもルートの解釈が意図と違う場合にディレクトリ構成を見直す、という順番がよさそうです。

Vikeの公式リポジトリには、動的ルートを含むサンプルもあります。実際のプロジェクトの構成と見比べると、+route.js や +onBeforePrerenderStart.js の配置を考えるときの参考になります。

Vike公式リポジトリのexamples

ビルド前後に確認すること

動的ルートを追加したら、次の順番で確認します。

1. onBeforePrerenderStart() が返すURLをログに出す
2. 同じURLがないことを確認する
3. vike build を実行する
4. dist/client/ に期待するHTMLが生成されているか確認する
5. 本番相当の環境で、一覧ページと動的ページのリンクを確認する

SSGはビルド時にHTMLを生成するため、データを追加しただけでは公開済みのHTMLは変わりません。カテゴリなどのデータを更新した場合は、改めてビルドとデプロイが必要です。

最後に

今回はVikeとは何か、ReactアプリでSSGする基本設定、動的ルートを事前生成する方法をまとめました。

以前の記事では vite.config.js にSSGの設定を書いていましたが、現在は pages/+config.js に prerender: true を設定する形が基本です。Vikeや関連パッケージを更新するときは、プロジェクトのバージョンと公式ドキュメントを合わせて確認するのが安全です。

今回も動的ルートで少しハマりました。SSGさせる方法というより、どちらかというとエラー解決記事になっていますね。

VikeはSSRとSSGを同じプロジェクトで扱えるところが便利なので、次はデータ取得やSSRとの使い分けも試してみたいです。

自分が今まで作成した成果物の見直しをしようかと思ってまず手始めにブックマーク管理ツールから手を付けたんですけどエラーが出まくっていてまともに動作していないことに気づいたんですね。

約4年くらい前にPHPで作った↓のツールです。
PHP覚えたてくらいの時にスクラッチで作ってみたものです。
ブックマーク管理ツール

ちなみにその時に書いた記事がこちらです。

【PHP】ブックマーク管理ツールを作ってみた

XSERVERでホスティングしているので多分PHPのバージョンが上がったことで動作しなくなったのだと思います。

そこでエラーを修正しようとしたんですけど今のPCにPHPの実行環境がなくPHPを動かせない、、、

ちょうど数日前にLaravelの実行環境を作ろうと思ってDockerを触ってたのでそのノリでPHPが動作する環境も作っちゃえ！ってことでDockerで作成しました。

前に友人に借りた本をざっくり一周したのと何個かコンテナ作ったりしたレベルかつ
フロントエンドがメインで業務でもDockerを使っていないので全然知識がないです、、、

なので今回の手順を備忘録がてらここに書き記しておこうと思います！
ここ2年くらいブログも書いていなかったのでリハビリも兼ねて！

docker-compose.ymlを作る

こちらが今回作成したdocker-compose.ymlです。
めちゃくちゃシンプルです。

version: "3"

services:
  php:
    image: php:latest
    volumes:
      - ./src:/var/www/html
    ports:
      - "8080:8080"
    command: php -S 0.0.0.0:8080 -t /var/www/html

上から順番に説明していきます。

version

これはdocker-compose.ymlのバージョンです。
composeファイルと呼ばれバージョン毎の書き方があるみたいです。
今回は一番最新の使用の3を使用しました。

service

作成するコンテナを書きます。
ここではphpという名前のコンテナを作成しています。

image

php:latest つまりphpの最新バージョンのimageを取得してきます。
ローカルに該当のimageがあればローカルから、なければDockerHubから取得します。

volumes

マウントするディレクトリを指定します。
コンテナ上のディレクトリとローカルのディレクトリを同期させます。
ここではdocker-compose.ymlと同階層のsrcディレクトリにコンテナ上の/var/www/htmlディレクトリをマウントしています。

ports

ポートフォワーディングの指定をします。
ローカルの8080ポートをコンテナの8080ポートに同期させます。
これでローカルの8080ポートにアクセスするとコンテナの8080ポートにアクセスできるようになります。

command

コンテナが起動した時に実行するコマンドを指定します。
phpのビルトインサーバーを立ち上げています。

最後に

今回はDockerでPHPのなるべく小さい実行環境を作りました。
webサーバーを使わなくてもPHPだけで簡易的なwebサーバーを立ち上げて実行できるからすごい楽でした。

Dockerは普段全然使わないから覚えても少し経つとすぐに忘れてしまうんですよね、、、
今年は個人開発でバックエンドも実装していく予定なので積極的にDockerを使ってインフラの構築やバックエンドの構築を行っていきたいです。

今ならChatGPT先生もいるから自分の管轄外の分野にチャレンジするハードルもだいぶ下がりましたよね。

ブログももう少し書いていきたい、、、

どうも。みずかず(@mizukazu_1)です。

XSERVERでFTP接続をした際に「ディレクトリリスト表示の取り出しに失敗しました」というエラーが表示されるという事象が起きました。

原因は難しいことではなかったので備忘録がてら残しておきます。

どんなエラーが出たか

FileZillaを使用してFTPでXSERVERに接続した際に以下のようなエラーが発生しました。

パスワードも通っているのになぜかディレクトリの一覧が表示されない、、、

原因

原因は引っ越しをしたためIPアドレスが変わったことでした。

いつ設定したのか分からないのですが、XSERVER上でFTP制限設定というものが設定されていました。
FTPで接続出来るIPアドレスを指定する設定で、今まで使用していたIPアドレスがそこに設定されていたおかげでFTP接続出来ていたようです。

今回は引っ越しをしてIPアドレスが変わったので接続が出来なくなったみたいです。

なので、新しいIPアドレスを設定してあげれば接続できるようになります。

FTP制限設定の仕方

まずXSERVERのサーバーパネルにログインします。
そこにFTP制限設定の項目があるのでクリック。

次にドメインを選択します。

次にFTP接続許可IPアドレス追加をクリック。

現在のIPアドレスを追加するを選択して確認画面へ進むボタンをクリック。

追加するボタンをクリックして設定完了です。

これで無事にFTP接続出来るようになります。

最後に

接続出来なくて一瞬焦りましたが、そんなに難しいことじゃなくて良かったです。

ただFTP制限設定ってXSERVER側で勝手にやってくれてるんですかね、、、
知らないうちに設定されていたのでその辺も調べてみようと思います。

みずかず

めでたしめでたし

どうも。みずかず(@mizukazu_1)です。

少し前に新規でFirebaseプロジェクトを作成したらJavaScriptSDKのバージョンが8から9に変わっていて
それに伴って書き方も変わったので困惑するということがありました。

今はFirebaseを使っておらず今後ももうしばらく触る予定が無いので忘れないようにざっくりまとめておこうと思います。

v8での書き方

認証機能を実装できるFirebase Authを例にしてみます。

v8では以下のような書き方でした。

import firebase from 'firebase/app';
import 'firebase/auth';

const firebaseApp = firebase.initializeApp({});
const auth = firebaseApp.auth();
auth.onAuthStateChanged(user => {});

Authの部分を丸々importしています。
これだと使わないものまでimportすることになるので若干無駄です。

v9での書き方

v9では以下のような書き方をします。

import { initializeApp } from 'firebase/app';
import { getAuth, onAuthStateChanged } from 'firebase/auth';

const firebaseApp = initializeApp({});
const auth = getAuth();
onAuthStateChanged(auth, user => {});

firebase/authからimportするのはv8と一緒なのですが、v9では使いたいものだけをimportします。
ここでいうとinitializeApp 、getAuth、onAuthStateChanged の3つですね。

この書き方はauthだけでなくfirestoreやstorage等の他のサービスでも同じです。
get<サービス名>になるだけなので覚えやすいかと思います。

2つバージョンの違いを簡単にまとめる

上で書いたことと少し被りますが、v8は全部まとめてimportをします。
逆にv9では使いたいメソッド等を個別にimportします。

効率の面でいってもv9の方式の方がなんとなく良さそうだなと思いますよね。

実際にファイルサイズで言ってもv8よりv9の方が断然小さいみたいです。

注意点

厄介な点がありましてv8とv9には互換性がありません。

なので元々v8で開発していたものをv9にバージョンアップするとあちこちでエラーが発生します。

くれぐれもいきなりv8からv9へのアップデートはやめておいた方が良いです、、、

また、npm installするとデフォルトでインストールされるのはv9のようです。

Compatライブラリについて

一応救済措置としてcompatという公式が出している互換用ライブラリがあります。

これを使用する事でv9でv8の書き方が出来ます。

例を以下に書いておきます。

import firebase from 'firebase/compat/app';
import 'firebase/compat/auth';
import { onAuthStateChanged } from 'firebase/auth';

const firebaseApp = firebase.initializeApp({});
const auth = firebaseApp.auth();
onAuthStateChanged(auth, user => {});

この部分に注目です。

import firebase from 'firebase/compat/app';
import 'firebase/compat/auth';

firebaseとapp、authの間にcompatを入れます。

こうすることでv8の書き方が使えるようになります。

最後に

やっぱり破壊的なアップデートは少し戸惑いますね、、、

事前に情報を集めていて知っていた場合ならいいんですがいきなりだとびっくりします。

今回はとりあえずざーっと走り書きしてしまったので説明が足りない点等があると思うので
今後少しずつ追記していこうと思います。

参考にしたサイト

これからFirebaseでプロジェクトを始めようとする全ての人が知っておくべきこと v8→v9リリース
React+Typescript+Firebase v9

どうも。みずかず(@mizukazu_1)です。

テーマの修正をしていた際にカスタム投稿の編集画面でカテゴリーが表示されないということがありました。
こんな感じです。

解決方法もすごく単純なことだったので忘れないように書き残しておきます。

カスタム投稿、カスタムタクソノミーの設定をしているのになぜか表示されない

カスタム投稿の設定、カスタムタクソノミーの設定はしているのですが、なぜか編集画面にカテゴリーが表示されませんでした。

カスタム投稿

カスタムタクソノミー

解決方法

原因としてはカスタムタクソノミーの設定にshow_in_restの設定をしていなかったことでした。

クラシックエディタならどうかな～と思ってGutenbergを一旦OFFにしたらカテゴリーが表示されたので、調べてみたらどうやらカスタムタクソノミーの設定にもshow_in_restの設定をしなければいけないということが分かりました。

teratailのこちらの質問を参考にしました。

「カテゴリ」「タグ」が表示させたい。

まとめ

Gutenbergのカスタム投稿編集画面でカテゴリーが表示されない場合にはカスタムタクソノミーの設定にshow_in_restを追加すること。

解決してから考えるとなんだこんなことかと思うんですけど悩んでる最中はどこが原因なのか見当がつかなくて辛いです。

意外と見落としがちなところなので忘れ内容にしようと思います。