「だったら先に言ってくださいよ！」Z世代の育成に頭を抱える上司たちの悲鳴（後略）
https://shueisha.online/articles/-/254589

タイトルは「Z世代」とあるが、要点は世代に関係ない「無駄や間違いへの価値観の違い」に関する話か。

「失敗は良くてやりなおし、悪ければ不可逆的な不利益==時間やコストに無駄が起きる」のは、間違いない事実。
でも同時に、人間、「失敗しない」なんてことはあり得ない：人間はミスをする生き物なんだよ。
程度もあるけど「失敗を嫌がる（ゆえに何もしない）」とか「失敗を（厳しく）責める」ようなのは、世代を問わず望ましくないと感じる。
もちろん感情的に難しいのも否定しないけど、失敗した側・された側とも、失敗の程度に合わせた受容と肯定が必要なんじゃないかと思う。

バーコード決済詐欺は巧妙化、対策されてもさらに新たな手口…「決済画面は他人に渡さない」厳守を
https://www.yomiuri.co.jp/national/20250804-OYT1T50045/

詐欺グループが「被害者人物の支払いバーコード」のスクリーンショットを入手、それによって被害者に成りすまして購入するという話。

QRコードを含めたバーコード決済は、結局「クレジットカードの番号/ICチップ」「SUICAでのICカード識別情報」にあたる情報をバーコードで示すもの。
ICチップが「物理的に偽造困難なモノ」なのに対して、バーコードにはそういう「保証」手段が不足しているってことなんだろう。
バーコードは公開仕様だから、買い物日時とか金額とかの変動情報が埋め込まれていたとしても、「本物」を知っていれば再構築==偽造できてしまう。
それ自体が「独立した端末」で実現しているので多要素認証も難しいし・・・厳しいね。

宅配に入ってる「梱包紙」は捨てたら損！ミニマリスト主婦の「賢い活用術」をご紹介
https://ichioshi.smt.docomo.ne.jp/articles/limited/32900

記事自体はタイトル通り：Amazon通販などで緩衝材に使われている「黄土色の紙」の再利用ネタ。
「フリマ販売時の緩衝材」という入手時と同用途の再使用だけでなく、「水気を吸う、生ごみ処分のお供」とか「泥付き野菜保管時の下敷き」とか。

友瀬的にはこの内容自体はあまり重要ではなくて。「紙の新聞が売れなくなった」ことを想起させられたのがポイントかな。
この「賢い活用術」とやらは友瀬から見ると特段新しいことではない、「昔は新聞紙でやっていた」あたりまえのこと、なんですよ。
新聞を購買しなくなったことで、どの家庭にもある「雑に使えるざら紙」の代表格が通販梱包材に変わったんだなあ、って話。

じつは“冷蔵庫保存がNG”な調味料３つ「間違ってた…」「劣化するんだ」
https://saita-puls.com/voice/35504

料理酒、砂糖、オリーブオイルが「冷蔵庫保管NG」という記事。

調味料はついついあまりがちなので興味を持って読んだんだけど、一部内容が論理破綻していてもやもやする。
ともあれ内容は：砂糖は「乾燥から固まる」「匂い移り」。オリーブオイルは「油分が固まる」。この２つは冷蔵庫NGというのも納得。
でも料理酒がよくわからん：『未開封なら温度変化が少なく湿気がこもらない「冷暗所」、開封後も同じ』とある。
冷蔵庫ってまさに「温度変化が少なく湿気がこもらない冷暗所」なんだよね・・・

MastercardはSteamやitch.io上のゲームに「いかなる制限も要求していない」と主張もValveは決済代行業者経由で圧力をかけてきたと主張
https://gigazine.net/news/20250805-mastercard-not-required-restrictions-steam-claims-otherwise/

少し前からときどき話題になる「アダルト商品を扱うサイトで、クレジットカード会社に決済を拒否される」という、事実上の検閲に関する話題。
今回は「SteamなどのWeb上のゲームプラットフォーム」vs MasterCardでもめているという状況。

MasterCard側の主張『あらゆる合法的な購入が可能』はごもっともで理解できるんだけど、じゃあその合法の「法」とはどこの国・地域のもの？
要はこれって「グローバルなやり取りが当たり前のインターネット」起因の、国境を越えた犯罪に類似した、難しい問題だと思う。
「少女イラストの18禁画像」が違法な国もあれば合法の国もある、っていうことなんだよね。

ご意見などがあれば。

大前提の話：pukiwikiとhtmlとの関係†

「気が向いた人だけ」とは言いましたが、いちおーは、努力する（笑）

いわゆる「Webページ」のほとんどの部分はhtmlという構造・ルールに従ったテキストデータによって書かれています。
（画像や動画といった非html形式の部分も多数あるんですが、それはちょっと置いておきます）
htmlは大雑把に言うと「本質的に表示したい文字」と「それに属性を付与するためのマーク（タグ）」からなります。
例えばありがちというか一般的な話として、記事の書き出し部分には「その記事のタイトル・見出し」的なのを書きたいですよね。
そういう場合、htmlに次のような感じに記述します。

<h1>記事タイトル</h1>

ここでいう「h1」というのは、本でいうところの「目次の第一階層」というような意味です。
このようにhtmlでは「表示したい本質部分」を「属性を付けるためのマークで挟み込む」構造が基本になっています。

ただ、htmlにはさまざまなルールがあり、それを詳しく覚えて・ルールを守ってテキストで書くのは難しいです。
そこでそういう「難しい」ことを隠ぺいして、「比較的わかりやすい」形で書けるようにする仕組みがさまざまに使われています。

Pukiwikiもこのような「簡単にする手段」の１つ。
例えば先ほどの「h1 というhtmlタグ」を使って書く部分、pukiwikiでは次のように書きます。

*記事タイトル

わかりますよね：挟み込む必要はないんです。
内部的に「*1文字で始まる行は、htmlのh1に相当する行だ」とpukiwikiシステムが理解・判断してhtmlを作ってくれるわけです。

もう少し面倒くさい例、というかこれが「プラグイン」に関わる話なのですが。
例えば「注意」という感じにテキストに色を付けたい場合、htmlではこんな感じに書くことができます（他にもいろんなやり方はありますが、代表的なやり方の１つです）。

<span style="color:Red; background-color:Yellow">注意</span>

で、これと同じことをやるために書くpukiwiki書式はこんな感じ。

&color(Red,Yellow){注意};

この「&color(foreground[,background]){text};」というのが pukiwikiプラグイン。
先ほどの「*/h1」に比べると書くことは多いですが、例えば「span というタグで挟み込むんだ」ってことは考えなくていい分楽ですよね。

初期のpukiwikiで困って、拡張された話。†

文章を書く場合、上記例に挙げたタイトルや数文字程度の変換のような「短い」ものだけでなく、「広い範囲」を区切りたいことがあります。

今回の本題にも直結する例として「おりたたみ」を挙げます：
折りたたみは「ある程度の長さがある記事」の表示/非表示を切り替える機能ですから、その「折りたたまれる文章の最初と最後」がわかるようにしなければなりません。
友瀬が提供している折りたたみ用プラグインdevregionではこれを実現するために次のようなhtmlを生成します （わかりやすくするために細かいところは省略しています）

<div class='divregion' id=’rgn_summary1’>▼タイトル文字列</div>
<div class='divregion_contents' id=’rgn_content1’>
折りたたまれる「記事」の内容
このように複数行を書くことができる。
</div> (注：divregion_contentsの終端)

htmlの仕様通り「挟み込む」構造で、「タイトル文字列」と「記事の内容」とがそれぞれ別のタグ構造になっていることがわかると思います。

で、プラグインでは「htmlの細かいことを意識させたくない」のでもうちょっと簡略化できるようにしてあるのですが。
実際には、次の2通りの書き方を提供しています。

• 方法１：
  

  #divregion(タイトル文字列)
  折りたたまれる「記事」の内容
  このように複数行を書くことができる。
  #enddivregion

• 方法２：
  

  #divregion(タイトル文字列){{
  折りたたまれる「記事」の内容
  このように複数行を書くことができる。
  }}

「#」で始まる行がプラグインの開始地点。
つまり方法１では「#divregion」と「#enddivregion」という２つのプラグインを用いて「範囲を特定」しているのに対して。
方法２ではプラグインは「#divregion」のみ、代わりに｛｛ ｝｝という「2重の中カッコで挟む」書式（マルチライン引数と呼ばれています）で範囲特定しているわけです。

考えていることというか困りごとというか†

上述の例を見ると、プラグインとしては方法２のほうが簡単に見えますよね。
実際この「方法２」の書式は pukiwikiが機能拡張されたためにできるようになった書き方。
これが実装されるまでは方法１のような書き方しかできませんでした。

友瀬的にも方法２に移行したいところなんですが、単純な上位互換というわけでもないという事情もありまして。
というのはこの｛｛ ｝｝記述で使っている中カッコ、上記例では「2個セット」になっていますが、が実は2個固定ではありません。
こういうマルチライン引数の中にさらに「別のプラグイン」を書き込むことができ、すなわちさらに「マルチライン引数を入れ子に書く」ような書き方も認められているのですが。
そのような場合、その対を特定するために「{{{}}}」「{{{{}}}}」というように ｛｝の数を変えないとならない。
しかもその場合「より先にマッチした終点指定」を終点としようとするので、「親となるセクションの開始・終了をカッコ３つ」「子をカッコ２つ」というように書かなければならない（そうしないと、子の終点を親の終点として解釈してしまう）。
この結果、文章作成中に思い立って「入れ子」的な書き方をしようとしたら、「この節の親の開始点・終了点を探してカッコを増やす」ことが必要になります：一度書いた、本筋じゃないところを編集しに行かないとならない手間が発生するわけです。

方法１にはそういう「階層によって変える必要性」がないので、そこに頭や手間を使わなくていい。
そういうメリットがあって、方法１の書式を使い続けているという実情があります。

ただ同時に、方法１には「自動的に終端チェックできない」という問題：
具体的に言うと最初の #divregion を書いたけど、終端である #enddivregion を書き忘れたとしても、それをエラーとしてチェックできない。
これは本質的には「べたテキストのhtml」時代からの仕様上の「あるある」な問題なんですが・・・
ともあれこれによって「開始はしたけど終了しない」形になって、最悪ページ構造が破綻していろいろ表示されなくなる恐れがある。

方法２であれば「１つのプラグインで開始タグ・終了タグ」を作るというルールを pukiwikiシステム側が確認したうえで html変換するので、例えば終端の｝｝を書き忘れていたら「プラグインの記述エラー」と扱うため、htmlが作られません（ただの文字列として表示されます）。
その結果、開始タグと終了タグの数が不一致状態になるような構造破綻は起きないんですね。
（前述の｛｝の数に起因して）意図した構造になるか否かは別として。

という感じで困っていると。

ニッチな対策案の話。†

今、友瀬は editプラグインを使ってプレビューできるようになってるんですね。
そうすると、そのプレビューの際にタグの開始・終了の対を勘定して警告だす・・・みたいなことはできるかもしれない。
ぶっちゃけニッチすぎるんで、どうしようかなと迷っています。

まあそんな感じ。

ご意見などがあれば。