iDeasilo

  • 先日、本屋を徘徊していてたまたま目にとまった WordPress のセキュリティに関する書籍を立ち読みしていたところ、プラグインやテーマの入手先として ThemeForest や CodeCanyon などのマーケットプレイスを「推奨」するかのような記述を見つけてその場で卒倒しました。 「野良プラグインは避けましょう」というような記述もあったので素性の確かでないソフトウェアを利用することの危険性については著者も認識しているようでしたが、よく知られたマーケットプレイスなら安全だろうとよく確かめずに書いたのかもしれません。事実は正反対で、WordPress.org が公認していないマーケットプレイスから入手したプラグインやテーマを利用することには極めて重大で直接的なセキュリティリスクがあります。今回は非公認のマーケットプレイスがいかに危険かを生々しい実例を挙げて解説したいと思います。

  • クライアントが道を外れそうになっていたら諫めるのがプロフェッショナルの役回りだと思う。そうでなければどんなに知識が豊富でもプロとは呼べない。素人だ。

  • 今回はユーザー入力データにアクセスするための API、あるいはフォームデータモデルについて書きたいと思います。Schema-Woven Validation は異なるプラットフォームでも一貫したバリデーションロジックを提供する枠組みですからバリデーションの対象であるフォームデータの一貫性が基礎となりますが、各プラットフォームが標準装備するフォームデータモデルにはびっくりするぐらいの違いがあるのが現実です。

  • フォームのバリデーションにおいて文字列の長さの上限、下限を定めるルールは定番です。今回は文字列の長さをどうやって測るかという話をします。

  • 前回はバリデーションの前処理として両端の空白文字を取り除くことについてお話ししましたが、この処理に使うのが trim() です。今回は、おなじみ trim() に関するあまりなじみのなさそうな話をしたいと思います。

  • 先週の続きで、以前 Contact Form 7 のサイトに書いた「一貫性のある両端空白文字取り扱い方針」で扱ったような話を取り上げるつもりだったんですが、どこかの時点で HTML の仕様が変わったらしく、今では input の型に関係なく両端空白文字が取り除かれた上でバリデーションにかけられるようになっているようです。

  • HTML のフロントエンドバリデーションの話をします。

  • 結局、開発者が燃え尽きるのが関係者皆にとって一番の不幸だと思うのです。それがわかっているなら、開発者が第一に考えるべきことは自分自身が燃え尽きることを避けること。何としてもこれを避けねばならない。どんな手を使おうとも。いかなる代償を払おうとも。絶対に。

  • はてなの最近の事件について書こうとしたときにふと思ったんだけど、この文中の「はてな」を AI は正しく固有名詞として認識できるのだろうか。AI に限らなくても、たとえば外国語に翻訳するときなんかはどうだろう。まあできそうではあるけど、100% 確実にはできないだろう。

  • 4月9-11日の日程で開催された WordCamp Asia 2026 に参加するためインドに行ってきました。また、「Schema Sharing Makes Web Form Management Sustainable」というタイトルでお話しさせてもらいました。