それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

共有メニューは使わなくないですか?消しました。

windows 10 の共有メニュー。

誰が使うんですか。これ。

f:id:takuya_1st:20210912102527p:plain

共有メニューの問題点

Shareメニューは日本語訳で「共有」になるのですが。共有メニューは、Win10からの共有と、WinNTからの「ネットワーク共有」とWin内部ローカルユーザー間の「ユーザー間共有」と、もはやわけがわかりません。共有メニュが何を指すのか、使い方を調べるのも一苦労です。そのため、誰も使いたがりませんし使ってないと思います。iPhoneユーザがWindowsを使い始めたときに癖で押して使うだろうが使いにくくて苦労していると思います。

シェアメニューを押して出てくる画面も、情報多すぎて全然わかりません。iphoneの人は、他アプリが出てくると思いきや「他アプリ」は「Open With(別で開く)」ですから。ユーザーが迷うだけです。ゴミ機能です。

消しましょう。

Computer\HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\ModernSharing

f:id:takuya_1st:20210912102929p:plain

アスタリスク( * ) がちょっとわかりにくいですが、*はすべてのファイル(フォルダ)という意味でレジストリツリーに存在します。

参考資料

https://shellfix.nirsoft.net/context_menu_list.html

f:id:takuya_1st:20210912103018p:plain

Shift押したときだけ右クリックメニューに表示するようにしたい

Shift押したときだけ右クリックメニューに表示するようにしたい

右クリックメニューに余計なものが多すぎる。

Windowsには、「Shiftを押したときだけ右クリックメニューが表示される」のフィルタ機能がある。

右クリックメニューに出現するアプリたち。使わないのに右クリックメニューを占拠して私達を迷わせ無駄時間を使わせる極悪非道な右クリックメニューたち。やつらを一斉解雇したい。

だけど、全部消しちゃうと流石に不便なので契約維持・解雇・2軍に分けたい。

Shift化→スタメン落ち

邪魔なメニューだけど、消すのも困るっていうスタメン落ち。2軍(登録抹消)ほどでもないけど、常に表示されるのは困る。

Extended Mode

それは、レジストリでは、Extended Mode 拡張モードにする。

ExtendedModeのエントリを作成しておく。キーが存在するだけでいい。これでShiftのみで表示されるコンテキストメニューが有効になる。

f:id:takuya_1st:20210912100434p:plain

shellmenuviewで閲覧・編集

Windowsレジストリを直接触るのは大変なので、shellmenuviewを使ってカスタマイズする。

ExtendedModeがYesに設定している。

f:id:takuya_1st:20210912095336p:plain

f:id:takuya_1st:20210912095833p:plain

Backgroundは、なにもないところを右クリックしたとき

エクスプローラでなにもないところをクリックするだけでも大量にメニューが出てくるので困りますよね。

ピン留め系のメニューを消す。

ピン留め系のメニューなんて初期設定したあと殆ど使わなくないですか?

f:id:takuya_1st:20210912101358p:plain

ということでこれもスタメン落ちさせてみます。

Computer\HKEY_CLASSES_ROOT\Folder\shell\pintohome

f:id:takuya_1st:20210912101512p:plain

メニューから消える。

Shiftキーを押せばいつでも出てくる。

f:id:takuya_1st:20210912101524p:plain

右クリックメニューが多すぎて押し間違え起きる。

Windowsは右クリックメニューを増やしすぎて、押し間違えで面倒が起きるので、整理しておくのがおすすめです。

WEBフォーム項目の連動項目でのバリデーションの一般的な解決法(laravelでの実装例)

Selectやラジオボタンのチェック項目よって、バリデーションが異なる場合。

根本問題としてそういうフォームを作るなと思うのですが。

直前の選択項目によって次の入力項目のバリデーションが異なることがある。

例 電話番号

固定電話と携帯電話で番号をバリデーションする場合

例として電話番号のバリデーションを考えてみる

HTMLの例

<select name='tel.type' >
  <option value=''>--選んで--</option>
  <option value='cellular'>携帯</option>
  <option value='home'>自宅</option>
</select>
<input type=tel name='tel.number' >

フォーム項目の連動(選択肢よって入力制限が異なる)場合の例として自宅・携帯によって電話番号のバリデーションを変えたいとする。

バリデーションの例

<?php
$validator = Validator::make(
  ['tel' => [
    'type' => 'cellular',
    'number' => '080-1234-5678',],
  ],
  [
    'tel.type' => ['required'],
    'tel.number' => ['required'],
    'tel' => ['required',
      function( $key, $value ) {
        [$type, $number]=array_values( $value );
        
        if ( $type == 'cellular' ) {
          $exp = '/0[789]0-\d{4}-\d{4}/';
        } else if ( $type == 'home' ) {
          $exp = '/0\d{2,3}-\d{2,4}-\d{4}/';
        }
        return preg_match( $exp, $number );
      }],
  ] );

$ret = $validator->passes();

ポイント:グループ化

ポイントは超単純。フォーム項目を「グループ」に分ける。

今回は、フォーム項目をtel配列に入れている。配列に入れるとバリデーションは格段に扱いやすくなる。

そしてグループ(配列)ごとに、バリデーションすると考える。

バリデーションの項目をrequired_if などであれこれ考えるより、配列で綿たほうが早い。

バリデーションのネスト。

コールバックを用いてバリデーションしている箇所が、if 連鎖で美しくないと思う人もいるだろう。

そういうときは、バリデーションをネストしてあげる。

コールバックで難読化してるのを

<?php
[
  'tel.type' => ['required'],
  'tel.number' => ['required'],
  'tel' => ['required',
    function( $key, $value ) {
      [$type, $number] = array_values( $value );
      if ( $type == 'cellular' ) {
        return preg_match( '/0[789]0-\d{4}-\d{4}/', $number );
      } else if ( $type == 'home' ) {
        return preg_match( '/0\d{2,3}-\d{2,4}-\d{4}/', $number );
      }
    }],
]

スッキリ(ネスト)させる

<?php
'tel' => ['required', function( $key, $value ) {
  $validator = Validator::make( $value, [
    'type' => 'required',
    'number' => ['required', new PhoneRule( $value['type'] )],
  ] );
  return $validator->passes();
}]

相当スッキリするはずである。

まとめ

要は、「配列」(パーツ)にフォーム項目を分けて、ネストしてパーツごとにバリデーションするとスッキリする。

あれこれ、Ruleを考えたり、require_if などを組み合わせるより圧倒的にかんたんで読みやすい。検索しても出てこないのが不思議である。

今回は、laravelにおけるバリデーションであったが、railsでもjavaのspringやpython djangophp のその他のフレームワーク(cakephp)などでも全く同じ考え方で処理できると思うんですよね。バリデーションが複数にまたがるときも「分割統治する」という分割責任原則が通用する。

バリデーションが複数個所で入力値によって変わるときどうするのかという質問は頻発なのになんでみんな複雑なものを複雑にコーディングしてしまうんだろう。