投稿者「かず」のアーカイブ

かず について

東京練馬に生息する、干支も4週目終盤のオッサン。 最近は四十肩?五十肩?に悩まされております。 楽に治せる方法、ダレカオシエテクダサイ。。。

マイクラの「路」(道路)を考える

マイクラは正方形の立体で構成されている関係上、坂道の勾配がほぼ決まってしまう。

具体的には

  • 通常ブロック
  • 階段ブロック
  • ハーフブロック

基本的にはこのブロックでしか坂道を表現できない。

しかしながら実際には、これらブロック(特に階段ブロックとハーフブロック)を組み合わせることによって、勾配(傾斜)を変化させることはできるのだが、実際にはプレイヤーを含む mob の移動速度に影響したり、そもそも通常ブロック意外にはレールなどを敷設できない(トロッコの速度にも影響する)など、色々な特徴をがある。

ここでは、自身の経験をもとに、まとめておきたいと思う。

通常ブロックで坂道作る

もっとも無骨なパターン。プレイヤーは登りについては加速ができない、降りる際は、実質飛び降りになるので、加速した状態やジャンプした場合ダメージを負う可能性がある。
ただし線路は原則、通常ブロックの状態にしか設置できないので、道のデザインによっては、通常ブロックを採用するしかない場合があるかも。

ちなみにハーフブロックでも、上付きであれば設置可能。階段ブロックも(階段としての意味はなくなるが)段差の上下逆にすれば、使えないことはない。

階段ブロックで坂道を作る

坂道の第1選択肢。なぜかというと、階段にすることで、プレイヤーは加速したまま昇降することができるようになる。
実はこれ、地味にメリットというか、ストレス軽減に繋がるんですよ。

あと、階段の上に天井を設置している場合、通常ブロックで加速移動すると、天井に頭がぶつかる場合があるため、それらを考慮するなら天井の高さを上げる必要もでてくる。
これが逆に階段ブロックの場合、加速した状態でも天井に頭をぶつけないので、天井ブロックを低いままに抑える事が可能だったりもする。

逆に階段ブロックのデメリットは「もろ階段」のデザインになってしまう点。
もはや「坂道」のイメージではなくなってしまうのが、難点と言えば難点かと、あと、線路を道路を隣接させた場合のデザインも、少し考える必要あり(道路は階段ブロック、鉄道は通常ブロック)

ハーフブロックと階段ブロックで傾斜調整してみたときの話

傾斜が緩やかになるのと「ザ・階段」というイメージが緩和されるなど、デザイン面でのメリットはありますが、「移動」という点を重視した場合は階段・通常ブロックそれぞれのデメリットが併せ持つ状況になってしまいます。

ぶっちゃけた話、歩きにくいです。

とはいえ、重視すべき観点次第だとは思うので「お好み次第」なのかも知れません。

ちなみに自分は、デザイン重視で階段とハーフを使って傾斜の緩い階段を作っていたけど、特にネザーについては「とにかく移動にストレス」だったので、全部階段だけの通路に改修を進めています。

Minecraft 自鯖ルール

公開しているわけではないので、ここで書く必要はないのだけれど、なんとなくここに書いておく的な。
極めて個人的な備忘録。

この記事は、不定期に加筆・変更します。

基本的には、冒険というよりも、開拓しながら建築や道路整備、装置を作ることがゲームの目的。

  • でもゲーム性は維持したいので、サバイバルモード。
  • でも難易度は変更OK。
    • 基本はイージー。
    • 開拓や装置作成中、敵mobがウザいときは、難易度をピースフルにする。
    • 村人ゾンビとかが必要な場合の時のみ、ハードモードに切り換え。
  • コマンドによるアイテム作成や mob スポーンは、原則やらない。
    • ただし、バージョンアップ時に mob が変化してしまった場合は、戻すのはOK。
  • スペクテイターモードは許可。

活動範囲と主要路の作成

自分の使っているワールドは、比較的 0,0 座標(ゼロ座標地点)に近い場所が初期リスポーン地点となったので、まずは、0,0を中心に -1000~1000までを徹底的に開拓する。具体的には以下。

  • 主要路整備
    • 0,0から縦横放射で -1000~1000までの幹線路を整備。
      • 幹線路は「道路+中心に線路」必須。
    • 1000座標間で「四角環状」の幹線路を整備。
    • 200座標単位で主要路を整備
      • 主要路について鉄道敷設は任意だが、準備用として中心は丸石を並べておく。
  • 村の整備
    • 柵で囲む。
    • 山の下に隠れていたり、水没していたりする場合など、地形に浸食されている場合は、全部地上に出す。
    • 途切れている村内道路は、整備する。
    • チェストはすべて開けて撤去。
    • 既存の家以外は、原則増築しない。
    • 村人人口増加施策
      • ベッドや職業ブロックが増やすことが可能な家には設置する。
      • 村内にニンジン畑を可能なかぎり造成し、コンポスターを畑を中心に設置、村人を増やす。
      • 村人を増やすための食料はニンジンが原則。
      • 既存の畑がある場合のみ、その食料は残すが、造成した畑は基本ニンジン畑にする。(理由:ニンジンは村人繁殖において加工不要な食料。またプレイヤーがそのまま食べられるジャガイモ・ニンジン・ビートルートの3大食料のうち、回復量・隠し満腹度とも最もに高くて、総合的にいちばん効率が良さそうだから。)
    • ウシ・ヒツジ・ブタ・ニワトリ飼育
      • 各2匹以上を飼育する。(1つの柵内で飼育すればよい)
  • 廃坑
    • 地上⇔廃坑拠点のエレベーターを設置。
      • 近くに整備した幹線道がある場合、そこに達する道路も整備。
    • 廃坑拠点に活動拠点(ベッド・チェストなど)を持ち込み、設置。
    • 廃坑内にある支柱や生成が中途半端な坑道をツルッツルに整備。
    • 見えている鉱石はすべて採掘。
    • 吹き出している水やマグマも事故らないように整備。
  • ネザーゲート
    • 主要路に直結整備する。
    • ネザーゲートを囲む建屋を建設する(敵mob対策のため。)
    • マグマは埋める。
    • 生成されたネザーラックは埋めるか、掘って撤去する
    • ネザー探索拠点セットを設置する。
    • 全部終わったら、ゲートを点火して接続。
      • ネザー側の主要路を接続整備する。

SEED MAP

シードマップの活用はOK。
おもにバイオーム探索の省力化かスライムチャンク・廃坑・ネザーゲート・村の位置を把握するために利用。

ただし、以下の点について注意

  • 自分の場合、一つのワールド内で随時バージョンアップさせているため、ワールド初期生成のタイミングによって、生成される物やバイオームが変化する。
  • SEED MAP に記載されていても、必ずそれらが生成されるとは限らなかったり、異なったりする場合がいくつかある。
    • 処理スポーン位置(ズレることがある)
    • ダンジョン・スポナー
      (SEED MAPの通りに生成される確率は低くなりつつある。逆に廃坑に隣接する形でダンジョンや生成されたり、坑道上にスポナーが生成されたりする可能性が高くなりつつある)
    • 砂漠の寺院やジャングルの寺院(1.18以降、特に)
    • アメジストジオード
      (洞窟や坑道などの既存の地下構造物の近くには生成されにくくなったものの、1.17以降、地下構造物がかなり増えてしまったので、隣接しているものも、そこそこある。)
    • 海岸線
      (1.18以降、隣接するバイオームが浸食することが多くなり、SEED MAP上では「おおよその海岸線の位置」となった。)

村を見つけたら、開拓整備する。

まずは湧き潰しと柵の設置

村の境界

村道の外側のチャンクを基準に作成。
さらに1チャンク先までは、木は全て撤去する。
草・花・苔などは、そのままでOK。
柵の内外にはスイートベリーを設置。

縦横道路に近い付近にフェンスゲートを2箇所以上設置する。

基本的に新築はしない。
破損している建物は修復して、住めるようにする。

ベッド

部屋の大きさに合わせて増床する。村人をできるだけ増やしておくため、できるだけ多めに設置する。

畑・動物

ウシ・ブタ・ニワトリ・羊の3種は、必ずフェンスで囲って、各3匹以上、飼育する。

作物は以下の3つのみ。

  • カボチャ(⇒ジャック・オ・ランタン、明かり用)
  • ニンジン(村人繁殖用)
  • 小麦(動物繁殖用)

畑は1単位ずつで、村内の平地が確保できそうな場所のみ設置する。

小麦は、村人が最初から畑を作っている場所を除き、フェンスで囲ってしまう(村人の繁殖用途では使わせないため)。
それ以外の作物はオープンで構わない。
村人繁殖のため、できるだけニンジン畑を多く作る。

ニンジン・小麦畑の中央は、水源・コンポスターまたは土・ジャック・オ・ランタンをタテ設置する。

村人

家のベッド数に応じて、自然増殖するように設置する。

職業

職業ブロックは、家内に1個は設置しておく。種類は色々設置で構わない。

ネザー

基本は通常ワールドと同じルールで開発するが、通常ワールドに比べると開発しにくいため、限定的な開発とする。

  • リスポーン拠点付近に開設したネザーゲートにある拠点
  • ネザーゲートの接続道路網(通常ワールドの「近道」形成が重点)
  • 要塞(トラップ用)
  • 各バイオーム(資源回収用)
  • ネザー

通常ワールドとはX-Z軸の距離が 1/8 に縮小された関係。つまり通常ワールドで X1000, Z1000 の位置にネザーゲートを開通した場合、ネザー上は X125, Z125 の位置にゲートが繋がる。
この特徴を活かして、ネザーは基本「近道」形成が

道路網

  • X0 と Z0 に基準幹線網を作成。
  • 高さは Y32 (溶岩の海の海面上)
  • 原則「十字」の放射路で作成するだけ。
    通常ワールドのような「環状路」や「碁盤の目」のような道路整備はしない。
  • 天井を必ず設置する。
  • ネザーゲートとは基準幹線網から階段+直線の順で繋ぐ。
  • バイオームや要塞などの自然生成されたものとは、100番台の補助直線を作成して目的地まで近づいてから、最後に坂道階段で繋ぎ込む。

ネザライトの欠片集積専用のマイニング場

気分爽快、TNT によるマイニング場。
マイニングを設置する場所は、以下。

  • 歪んだ森バイオーム(Warped Forest)
    (理由はエンダーマン以外の敵mobが湧かないから。)
  • Y13 がブランチマイニング基準層なので、この場所にブランチ穴を掘って、TNTを2ブロック間隔で空けながら爆破する方向で。

トラップや自動化の機構を作るとき

例外はあるとは思いますが、サーバを稼働させているかぎり無尽蔵に動いてしまう機構は、電源消費だけでなく、SSDなどの記録媒体に対して常に読み書きが発生するなど、サーバ機器に対して負荷がかかるため、劣化や故障など寿命を縮めることになります。

一定の距離から離れたり、ワールドを抜けて、プレイヤーがワールド内のからいなくなれば、マイクラの処理は停止します。しかしながらマルチサーバで多人数で活動している場合など、ゲーム環境によっては負荷が減らない場合もあります。

配信用など、entertainment として利用しているなど、例外はあるとしても、平時(特に利用者がいない時など)においては、ゲームサーバに対して余計な負担やコストをかけないための配慮が必要です。

レッドストーンを使った回路

回路の途中などにスイッチを設置するなど、簡単に停止できるような機構にしましょう。

明るさで湧きを調整できる敵 mob を利用したトラップ

レッドストーンランプにスイッチを繋ぎ、普段は明かりを点けて敵 mob が湧かないようにしましょう。

回収用トロッコ

畑の下などに設置した回収用トロッコは、回収後のチェストが満杯になっている時は動かないようにして、無限回収しないようにしましょう。

大規模トラップは作らない

経験値確保や修繕、アイテム確保などの目的で、トラップが必要な状況が生じるのは間々あるとは思う。でもトラップはサーバなど負荷がかかるし、ゲームバランスを崩す要素にもなってしまうので、製作する際は、それが効率的かはよく考える必要があるかと。

天空トラップタワー(TTT)

大規模になり、見た目もかなり壮観です。
製作にロマンと満足度を得られます。

ただし、実際に回収したアイテムを常に消費できるわけがないぐらい、大量に集まります。

あと製作そのものにとても時間と手間がかかるうえ、サーバにも負荷がかかるわりには非効率です。

個人的には、Youtube などの配信など企画向きではないかと。

スポナーを活用する

個人的には自然に生成されるスポナーで回収できるアイテムは、スポナートラップを構築して回収するのが、最も効率が良いと考えています。
理由は以下。

  • 回収したいアイテム別にスポナートラップを構築できる。
  • スポナーは半径16ブロック以内にプレイヤーが入らなければ稼働しないので、起動スイッチなどは基本必要ない。

ゾンビ・スケルトン

自分の場合、ゾンビ・スケルトンについては、敵mob落下型のスポナートラップ(待機所放置と経験値回収&アイテム修繕が切り換えられる機能付き)を設置しています。

スポナートラップとしては基本的なものではないかと。

ブレイズ

ブレイズもスポナートラップとして作成しました。
ただし、ネザーにあるネザー要塞にしかブレイズスポナーは生成されないため、難易度は高め。

あとブレイズは、落下によるHP削減ができない、浮遊型の敵mobなので、自分で剣などで捌く必要があります。

ちなみにブレイズスポナートラップは「あると便利」レベル。

ブレイズロッド(からクラフト可能なブレイズパウダー)は、醸造台を使用する上では必要な材料なのですが(自分も製作した最初の理由はブレイズパウダー目的)、醸造台を稼働させる際に必要なブレイズパウダーは少量のため、トラップで大チェスト満杯になるぐらい大量確保してしまうと、それ以降、必要になる場面はほとんどありません。

ただしブレイズは経験値が高めで、経験値回収&アイテム修繕も地上のスポナートラップよりは早いので、必要に応じて使い分けている感じ。
(まぁこれも、エンダーマントラップを製作してしまうと、ほぼ利用しなくなってしまうのですが。)

マグマキューブのスライムトラップ

最も効率的なトラップは、今のところ、カエルを使ったトラップだとは思います。
これがあるとマグマクリームとフロッグライト(カエルライト)の入手が楽になります。

ただしカエルを確保する必要があるのと、ブレイズトラップ同様、ネザー(しかもこちらはピグリン要塞)にトラップを作成する必要があるため、通常ワールドに作成するトラップよりも難易度は高い(というかカエル集めとネザーへの誘導がかなり面倒)です。

カエルは色が3種あって、それぞれで製作できるフロッグライトの色も変わるので、とにかくこのカエル集めが大変。

スポナーのない敵mobトラップはどうする?

スライムトラップをはじめとするスポナーでは湧かない敵mobは、特定のバイオームやチャンクによって生成され、またプレイヤーがそのエリアから一定のエリアに入ることにより、敵mobがスポーンします。

スポナーで湧かない以上、敵mob専用のトラップは必要になるかと。

ただし今のところ、該当する(あった方がいい)敵mobトラップはスライムぐらいです。

スライムトラップ

通常ワールドの一定高さ以下に湧き層を作ってゴーレムを設置すれば良いので、比較的難易度は低いのです。

しかしながら 1.18 アプデ以降、地下には洞窟や地下渓谷が穴だらけで生成されるようになってしまったため、周辺の湧き潰しがかなり大変になってしまいました。

というのもスライムはスライムチャンクにしか湧かないのですが、近くにスライムチャンクがあると、そちらに湧いてしまうことがあるのです。

しかもこの「スライムチャンク」は、割と近場(密度が濃い状態)に生成されます。そのため、結果的に湧き潰しの効率を上げるため、周辺にできた洞窟を全て埋め戻す作業を行うという、かなり面倒な作業が生じてしまいました。

廃坑

マイクラの「マイクラたる所以」の特徴の一つとして、廃坑が生成されます。

基本的には自身のリスポーン拠点(活動の中心)から近い廃坑を片っ端から見つけて、丸裸にしています。

ちなみに廃坑(の拠点位置)は、バージョンによる X,Z座標の位置が変化しません。
ただし Y座標や、生成される内容(廃坑の通路の方向や、通路上に生成されるチェスト・スポナーなど)は、バージョンによって大きく変化します。

なので水中や地下渓谷、マグマに中途半端に浸食された廃坑が生成されることもあります。

個人的には以下の方向で、片っ端から制覇(?)しております。

  • 地上⇔廃坑拠点のエレベーターを設置。
    • 近くに整備した幹線道がある場合、そこに達する道路も整備。
  • 廃坑拠点に活動拠点(ベッド・チェストなど)を持ち込み、設置。
  • 廃坑内にある支柱や生成が中途半端な坑道をツルッツルに整備。
  • 見えている鉱石はすべて採掘。
  • 吹き出している水やマグマも事故らないように整備。

あと、ブランチよりも時間は掛かっているとは思うけど、上記のような廃坑整備していると、自然と鉱石が集まるので、ブランチするよりもマインドが虚無にならないような気がしています。
(イージー・サバイバルぐらいにしておけば、そこそこのレベルで敵mobも湧くので、飽きません。)

ちなみにエンドポータルが生成される要塞(地下要塞)は、バージョンによって生成される位置が異なるので、探す際は注意が必要。

スマードフォンのイラスト

スマホの寿命

結論からいうと、概ね5年。
ただメーカー公式とか色々な観点から少しまとめてみた。

ただしキャリア(利用している通信事業者)のサービス状況などもあるので、利用している電波によっては、もう少し変わるかもしれないけれど、そういった重箱の隅的な話は割愛

iPhone/iPad の場合

こちらに丁度タイムリーな記事があったので、詳しくはこちらを参照の事。

公式には3年。これはまぁiPhonenの場合、新型の販売開始日から1年で、次の新型が発売されることが多く、製造終息までおよそ最大2年と見立てて、そこから更に1年と考えて、結果、およそ3年と見ればよいかと。
イメージ的には「次々世代の機種が見えたら、搭載OSやアプリの主軸機種は次世代以降に移るよ〜」という感じかな。

次に5年目の壁。これは概ねOSの対応機種の壁になるかと。iOSの場合、これを超えた機種については、対応外となる事が多い。

実際のところ、この時期まで使うと、本体の痛みやバッテリー劣化も見えてくるし、最新機種に比べても、機能面で明らかな見劣りが出てくる。

またゲームや動画撮影など、ハードに負担のかかるアプリについては、動きも怪しくなることがある。(まぁこの段階では、他のアプリを全部終了すれば、そこまで影響ない状態にはできるけど。)

自分の場合、まさにこのタイミングでして。そろそろ買い換え時かなぁ、と。

でも実際のところ、10年ぐらいまではOSがセキュリティサポートしてくれるらしく、それまでは使えるそうな。
(ただし、それまでにアプリ側のサポートが終了したり、アプリそのものが重くて使うに耐えられなくなる可能性はあるし、その可能性が高い。)

Android の場合

こちらは正直なところ、メーカー次第という感じ。

メーカーの方針によって、OSアップデートをどこまでやるかが決まってくる。そう言った点では「まちまち」。

ただ個人的には、実用性という点では「5年」がかなり怪しいラインと考えている。
もちろん iPhone 同様、ハードやバッテリーの劣化も理由だが、個人的にはCPUなどのチップセットが Android のほうがシビアな選択をされている気がする。
これは本体の価格を抑えるための所以ではないかと。

実際、Android 機種については、キャリアや Google のフラグシップを使ってみても、5年も使っていると、明らかに「重たく」感じる。

この「重たい」感は、アプリのアップデートによって引き越されている気がして、特にアプリのほうに負担がかかっている感じがする。

だからと言って、セキュリティー上の対策やサービス拡充に対応していく必要があるため、アプリのアップデートをしない訳にもいかない。

ちなみに10年後の Android 端末が使えるかというと、正直「使えない」と思う。それはおそらく iPhone/iPad の比ではないレベルで、アプリとかが立ち上がらないのではないかと思う。

どっちを買えばいい?

正直なところ「決め」です。

  • iPhone/iPad ⇒ 高いけど、長持ち。有償だけどサポートや修理できる店舗もそこそこ多い。
  • Android 系 ⇒ 安いけど、長持ちするかはかなり微妙。サポートや修理が限定的になることが多い。

ただ、日本の国民性を考えると、iPhone なのかも知れません。日本人はみんな「同じ物が大好き」なので。
操作方法を教え合うという点においても、同じ iPhone だと教えやすいし。

ただし、スマホの操作が得意でないご老人やキッズに関しては、「らくらくホン」とか「キッズケータイ」などの特化型一択のほうがよいかと思います。
機能特化とか制限ついている方が判りやすい。

あと使い方のアラい人についても、正直どちらでも。
スマホはデリケートなので、アプリの反応が遅いからと言ってパチポチする人や、物理的に壊れやすい使い方を普段からする人には、参考になりません。

eset_daemon の CPU が 100% で張り付く

長年、ESET Syber Security を使っているのだが、mac 版の唯一の不満として、これが存在する。

ネットでも色々と断片的に対応方法が記載されていたのだが、一旦解決したので、まとめてみた。

Time Machine の影響

外付けなどので Time Machine (バックアップ機能)を利用している場合、それらイメージファイルの大きさや多さ、構造などが影響して固まることがある。

Docker イメージの影響

VIrtual Box をはじめとする、他の VM でも発生する可能性が高そうな話として、これら仮想環境のイメージなどを ESET が検査したタイミングで固まる可能性がありそう。

また、そもそも、これらイメージファイルを検査する事によって、仮想環境そのものの挙動が不安定になったり、クラッシュする可能性もある。

では、どうすべきか

これら対象のディスクやディレクトリ、ファイルに対して「除外」設定するのが最も効果的。

ただしこれは、セキュリティ上のリスク(特に仮想環境イメージを場外設定する場合、イメージを構成するファイルのダウンロード元が信頼あるサイトでない可能性)を考えると、トレード オフの関係となる。

そもそも企業内PCなどの場合、除外設定そのものを禁止していたり、できないように設定されている場合もあると思うので、その点は十分注意されたし。

ちなみに他のウイルス対策ソフトでは、この問題は発生しないものが多い

しかしそれはおそらく、ウイルス対策ソフトそのものが、これらファイルやディレクトリについての検査そのものを除外(もしくは簡略化)しているからではないかと思います。

これらイメージファイル内の検査については、それぞれのウイルス対策ソフトによって、その検査ポリシー(例えば「イメージの中身を検査したいのなら、ゲストOS側にウイルス対策ソフトを別途導入して検査しろ」とか?)なども含めて、色々ありそうなので、何とも言えないところ。

公立の学校教育施策は色々と煮詰まってるなぁ。。

志願者が減っているから…東京都の教員採用試験、大学3年から受験可能に 「現場に魅力がないと」の懸念も(東京新聞)

私立とかはもちろん、公立でも地域によって大幅に異なるとは思うが、都教員で倍率2倍とか恐ろしいな。

給与面の優遇とかもある程度は考えるにしても、仕事量とかが明らかに多いのは、うちの子が通ってる小学校の担任を見ていても明らか。

いや、仕事量も多さもそうなんだけど、どちらかというと「全員に理解させる」というところに教育の重点を置いているから、かな?

昔はそこそこ勉強不得意な子がいたけれど、今までの教育施策や積み重ねによって、授業の内容がかなり精緻化されてきているのでは。

そして「どうすればみんなが理解できるか」をつきつめて行った結果、先生⇒生徒児童の接し方が変わり、指導に向けた計画もより緻密になり、それらが神経を磨り減らしながら教職を全うするという、負のスパイラルに繋がっているような感じなのでは。

さらに昨今の人材不足が拍車をかけている。

実際うちの小学校でも(学校側は詳細を伏せているがおそらく)メンタル的な事情で休職されている先生が何人かいる。

しかも先生の休職や退職については(理由は不明だがおそらくプライバシー云々とかの理由で)担当学年やクラスの保護者にしか共有されない。

そのため問題が表面化しにくいが、実際のところ担当教員が不足しても、教委から補充が積極的に行われるわけではなく、他の担任や、場合によっては学校長が担任を一時兼務するとか意味不明な事が起きている。

まぁ個人的には、社会(=保護者)の子どもに対する教育指導ニーズに対して、施策が寄り添った結果。

別に保護者だけが悪いわけでもないし、施策を担った行政だけが悪いわけでもない。

ただまぁ施策がかなり煮詰まっているのは事実なので、個人的には「教職者を守る」という立場から、ある程度教育システムを見直す方向に倒してもいいような気がしている。

具体的には地域の事情に併せてしてもらって構わないという話にしてもいいかもしれない。

教職が不足している地域については「うちは教員が不足しているので、細かな教育配慮まではできない、国レベルのガイドラインまでの指導とする」としてもよいとは思うし、余力があったり、戦略的な地域については、もっと踏み込んだ指導体制を組めばよいと思う。

あと高校については「実質義務教育」だとか何とか言われることがあるけれど、勉強する気がない子については、正直そこまで救済指導する必要はないと思っている。

メンタル的な理由で「勉強できない」は別の話なので、それはそれでケアの方向性が必要だとは思うけど、遊びたいからサボるとか非行的な理由など、やる気はないけど「義務」で来ている子などを教室に無理に座らせておくのは、正直ほかの生徒にも影響しそうな気がするし。

こういった状況は正直、早々に声掛けをして適材適所に誘導していった方がよいと思う。

そして何よりも、学校は塾と違って教育をサービスするだけの設備ではないということを、親に対してしっかり理解してもらう事が大事。

家族ドライブ旅行

正月の三が日をちょこっとだけ避けた三重弾丸帰省

  • 子どもが冬休みなど長期休みの時にじゃないと、家族で帰省できない。
  • でも大人はそこまで休みじゃない。
  • 6日には仕事があるので、戻っている必要がある。
  • 三が日は帰省ラッシュに捲き込まれる。
  • 実家周辺で買い物移動するため、車が必要。
  • 「さわやか」に行きたい(子どもの希望)

こんな感じの課題から、今回は3〜5日の弾丸帰省と相成りました。

帰省記事というよりかはドライブ記事です、はい。

キャンピングカーも考えた、けど

バンコンならまだしも、キャブコンは小回りが効かない。そんな中、混雑する「さわやか」や実家まわりの各種買い物に行くのは正直厳しい。

途中でカーシェアに乗り換えるのもアリだけど、それはそれで色々と面倒だし、乗り換えるにしても、キャンピングカーを駐車する場所が必要。

という事で今回は見送り。

バンコンクラスのキャンピングカーを使う場合は、キャンプ場や道の駅・SAPA・RVパークなどの大きめな駐車場や休日などを混雑する時期を避けたショッピングモールやスーパー等をある程度目星を付けて移動しないと、色々とハマるので。

とはいえ、3ナンバー車のミニバンで帰省したのですが。

カレンダー的な考察

年始の帰省なので、行楽や帰省Uターンのラッシュに捲き込まれる可能性があった。

ただ今年の場合、カレンダー的に3日前後が土日ではなく、4日以降が普通に平日だったので、ラッシュピークは2日と3日。
しかも我々の向かう下り線ではなく、上り線のほうが渋滞予測のメイン。

とはいえ、3日の日中は普通に東名下り線も混雑する。
しかもトラックではなく乗用車がかなり多いうえ、みんな車間詰め詰めで運転されるので、そのまま運転するとかなり疲れる。

1月3日(火)、 1日目

上記を踏まえて、中央道⇒富士山東側を南下⇒東名というルートにて移動。

8:30 出発

中央道までの一般道は、調布ICを目指すいつものルート。

⇒(富士街道)⇒ 保谷中南 ⇒(伏見通り・新武蔵境通り)⇒ 境一丁目東 ⇒(アジア大学通り)⇒ 境五丁目 ⇒(天文台通り)⇒ 上石原 ⇒ 調布IC

まぁ2車線に拡幅された新武蔵境通りをそのまま南下しても良いのだけれど、50km/h の割には交差点が多いので、加速停止が頻繁。下石原交差点の右折で詰まることも多い。
なので自分は途中で天文台通りに移動して、上石原交差点を左折して調布ICにアプローチしている。(時間的には若干劣るかもだけど、新武蔵境通りに比べると混雑も交通量も少ないので、まだ走りやすい。)

10:30 谷村PA

調布IC⇒(中央道 E20)⇒ 大月JCT ⇒(中央道 富士吉田線 E68)⇒谷村PA

往路最初の休憩。ほぼ順当。

11:30 愛鷹PA

谷村PA⇒(中央道 富士吉田線 E68)⇒ 富士吉田IC⇒(東富士五湖道路 E68)⇒須走IC⇒(R138 須走道路・御殿場バイパス)⇒ 仁杉JCT・新御殿場IC ⇒(新東名 E1A)⇒ 御殿場JCT ⇒(東名 E1)⇒ 愛鷹PA

以前は新東名延伸前の利用で、須走IC⇔御殿場ICは一般道経由、しかもバイパスも一部未整備だったので、かなり便利になった。
このルートだと実は、調布の上石原交差点以降、信号交差点なしで新東名にアプローチできるという大発見!!

しかも天気が良ければ富士山も近くで見られるという、素晴らしいルート。

個人的には外環が出来るまでは、環八&東名渋滞に捲き込まれるか、もしくは圏央道の海老名JCT付近で渋滞に捲き込まれるかの二択しかなかったので、思わぬ収穫。(とはいえ、中央道も八王子まで都市部の渋滞があるけれど。)

ちなみに愛鷹PAの休憩は「さわやか」の混雑状況確認のため。このタイミングでどの店舗に行こうか考えようかと思っていた。

「さわやか」店舗チョイス

まず御殿場インター店の選択は、最初から「ない」。
というのも、開店の30分前の時点で400分以上待ちとか、正直待つ気にならないので。

余談だが、近所にアウトレットや富士サファリパークがあるので、そこで時間調整するのはありかも。
でも、富士サファリパークを1周してきても、まだ有り余るレベルの待ち時間。
昼に夕飯を予約するレベル。

そもそも今回は帰省目的だし、ホテルの夕飯時刻もあるので、ここで大きな足止めを喰らうわけにはいかない。
なので、ここで他の店舗を検索することで目的地を決める。

ちなみに上記の店舗一覧では待ち時間が表示されるので、予定を組み立てるのには便利。

以下2023年1月時点の情報です。
今後店舗の増減や客の流れに大きく左右される事柄なので、あくまで考え方の参考とし、利用は自己責任でお願いします。

「さわやか」は以下の店が、一段と混雑している。

  • 利便性の良い静岡市内の都市部の店舗。
  • 関東圏の行楽エリアにあたる以下の店舗。
    • 御殿場インター店(関東圏からみて東名インターの最初にある店舗。)
    • 函南店(伊豆半島の付け根付近。伊豆行楽地の道中・箱根からも近い)

なので個人的には、以下の店を使うようにしている。

  • 富士錦店(東名富士IC)
  • 富士鷹岡店(新東名新富士IC)
  • 静岡瀬名川店(東名日本平久能山SIC)

今回の場合は「富士鷹岡店」を利用した。
ただ、やはりそれでも180分待ちだったので、近所のイオンモール富士宮で買い物しつつ、時間調整。

ただし「富士鷹岡店」も、隣りに「田子の月 鷹岡店」という、地域では有名な菓子店があるのを知り、駐車場にて時間まで待機しつつ、ちょっと立ち寄り。

田子の月はサービスエリアや都心でも期間限定の店舗出店していたりするので有名かも。
元々は和菓子店だが、ブッセやカステラ、フィナンシェなどの焼き菓子も扱っている。
富士山をモチーフにしたお菓子がいくつかあるのも良いし、お値段も良心的。

17:15 浜松SA

富士IC⇒(東名 E1)⇒清水JCT⇒(清水連絡路 E52)⇒新清水JCT⇒(新東名 E1A)⇒ 浜松SA

15時前後に遅い昼食。まぁ、仕方ない。
定番のげんこつハンバーグを食べ、移動再開。

当初は最寄りの新富士ICから新東名直行しようと思いきや、ラジオで新富士IC ⇒ 新清水ICで事故渋滞の情報を偶然キャッチ。確認したところ「渋滞5km、通過40分」とかなり詰まってそうなので、東名経由に一旦変更。

とは言え、同様の理由に東名に流れてきた乗用車が増えてきたようで、交通量は多め。東名は新東名に比べると坂や勾配が多く、車線も狭いので、若干詰まる箇所もあったものの、清水連絡路から新東名に復帰しても問題はなさそうだったので、そこから新東名に復帰。

浜松SAにて本日2回目の高速での休憩。

19:15 ホテルナガシマ、宿泊

浜松SA ⇒(新東名 、伊勢湾岸道 E1A)⇒ 湾岸長島IC

しっかし、相変わらず車線を詰めすぎな乗用車が多い。
ACC でも車間詰め詰め設定のままで走ってるのか知らないけれど、これだと確かに玉突き事故になるわ。

「さわやか」待ちで時間を取られたものの、夕食バイキングには十分問題ない時間にホテル到着。

三重実家は現在、父親介護の影響で、実家宿泊が憚れるので、定宿になりつつあるホテル。スパ施設や遊園地、夏はプールもあるという、昭和の頃からのリゾート施設で、バイキングも定番なので、家族旅行の際は便利に使わせて貰っている。

隣接の「ホテル花水木」が有名で、客室種類も多いのだが、こちらだと食事が部屋食やレストランの決まったメニューになってしまう。
なので子どもに好評なバイキングもあり、スパ施設も近いホテルナガシマの方が、個人的によく使う。

1月4日(水)、2日目

11:30 一路実家へ

湾岸長島IC ⇒(伊勢湾岸道 E1A)⇒ みえ川越IC ⇒(四日市・いなばポートライン)⇒(シドニー港通り)⇒(R23 名四国道)⇒

朝食後に精算は早々に済ませ、遅めのチェックアウト(鍵返却)。

実家に帰省しつつも買い物のため、母をピックアップして早々に出発。

この辺りは気張って普段行かないショッピングモールに行く寄りかは、地元民の勝手知ったる店に行くのが、一番良い感じ。

そこで昼食も食べた。(定番の「すがきや」)

帰宅して父の帰りを待ってから、暫し歓談ののち、帰路へ。

19:00 なばなの里⇒湯あみの島(予定変更)

⇒(R23 名四国道)⇒ なばなの里 ⇒ 湯あみの島

夕食ついで&ライトアップを見るために「なばなの里」への立ち寄り変更。
先日ホテルナガシマに宿泊した際、付属していたチケットの中には「なばなの里・ナガシマスパーランド(遊園地)・湯あみの島」3箇所、2日間有効の通行証が付属しているので、こちらを行使することにした。
(無料になるのは入場料のみ。遊園地の遊具等は別料金。)

1月5日(木)、3日目

0:00 鞍ヶ池PA

日を跨ぎつつ、帰路に就く。
新東名経由のほうが早く帰れるんだけども、交通量が多いのと、中央道経由でも道路凍結の可能性はあれど、雪はなさそうなので、中央道経由で帰ることに。
(冬用タイヤチョイスしてよかった。)

湯あみの島 ⇒ 湾岸長島IC ⇒(伊勢湾岸道 E1A)⇒ 豊田東JCT ⇒(東海環状道 C3)⇒ 鞍ヶ池PA

帰路最初の休憩。トイレ&コーヒー入手。

2:00 小黒川PA

鞍ヶ池PA ⇒(東海環状道 C3)⇒ 土岐JCT ⇒(中央道 E19)⇒ 小黒川PA

中央道上り、仮眠の定宿。
この PA には普通車用「離れ」の駐車スペースがあり、そこがお気に入りの場所。

ここで3時間ほど仮眠。

5:45 諏訪SA

小黒川PA ⇒(中央道 E19 E20)⇒ 諏訪SA

仮眠後、小黒川PAのトイレまで歩くのが寒いので、早々に移動開始。
諏訪SAのトイレ近くに車を駐車。

7:30 談合坂SA

諏訪SA ⇒(中央道 E20)⇒ 談合坂SA

ここで朝食やお土産調達など、少し眺めの休憩。
途中、富士山と朝焼けがよう見えた。

12:00 帰宅

談合坂SA ⇒(中央道 E20)⇒ 調布IC ⇒ 上石原 ⇒(天文台通り)⇒ 境五丁目 ⇒(アジア大学通り)⇒ 境一丁目東 ⇒(伏見通り・新武蔵境通り)⇒ 保谷中南 ⇒(富士街道)

特に渋滞に巻き込まれる事もなく、帰宅。

途中、八王子IC手前で追い越し車線走行中、覆面にパトライト回された時はかなりアセった。この辺りは下りが続き、都内に入るので、調子にノってると取り締まりに遭遇する可能性があるかも。日中の高速走行、速度には注意。
気が付くと後部にヤツがいる。

最後に

現在、外環の大泉⇔東名間の工事が行われているが、たとえ通じたとしても、東名の東京〜足柄の断続的な渋滞が継続されるかぎり、帰省ラッシュの時期や日中の混雑を避けるために別ルートを考えなくてはならない。

個人的には今回の富士山ルートは、東名の足柄⇔御殿場超えよりも楽な気がする。

それとUターンを夜行かつ途中仮眠前提であれば、中央道の選択もあり。
夜行バスも新東名全通した今では少なくなってしまったものの、その前は中央道経由で運行される便もそれなりにあった。
交通量の少ない道路を選択するのは、正直ストレスが少ないですし。

とはいえ中央道も週末の行楽渋滞はあるので、その辺りを見極めたいところ。

車間詰めすぎは危険

車の流れに乗って巡航するのは構わないけれど、車間詰め詰めで運転してる車のとても多いこと。

免許取得の際に適切な車間距離に学んでいるはずなのに、命を引き換えに車間を詰めるのは正直どうかと思ってしまうのだが。

ドラレコの普及しつつある現在、そのうち車間詰めすぎの事故は、自己の過失として保険支払いを渋られるような時代が来るかも知れん。

NoCode はタダではうまく行かないなぁ

タダ=無料という話。

最近、仕事とかのコミュニケーションは専ら Slack を使っているのだが、並行してメールも受信している。

このメールの受信と通知を Slack にできないかなぁと、調べたときの備忘録。

Slack 側の前提条件

少なくともプロ版以上の有料プランを設定する必要がある。
チャンネルにメッセージを直接突っ込むなどのAPI連携は、基本有料プランにする必要がある。

メール ⇒ Slack 連携で利用するブリッジサービス

選定したのは、とりあえず以下。

  • Make(旧 Integromat)
  • Zapier

いずれも有名なグローバルサービス会社であったのが選定の理由。
考え方は安直だけど、ビジネスの継続性とか発展性とか、それがまぁまぁ重要な理由でもある。

GMail ⇒ Make ⇒ Slack

最初に試したのがこれ。

Google の API 開放手順がかなり面倒

まぁこれは、Make 内に対処手順が動画やドキュメントが事細かくあるので、頑張って英語と戦って対処すれば何とかできる。

ISO-2202-JP 非対応

これが Make 利用を断念した最大の理由。
一応 Make には、文字コード変換するためのコンバーターがモジュールとして提供されてはいるのだが、ShiftJIS には対応してるものの ISO-2202-JP は非対応。

これを対策するには、別途 Webhook かなんかで ISO-2202-JP ⇒ UTF8 変換するサイトかなんかを作成して、それを通してから Slack に投げ込むしかない。

もしくは、ISO-2202-JP がこの世界から滅んで、全ての文字コードが UTF8 になれば良い。

それはさておき、この Webhoock を実装・設置するのを今すぐはできないので、ここで一時保留。

IMAP ⇒ Make ⇒ Slack

これも技術的には問題ないけど、やはり ISO-2202-JP 文字コードの問題が歓待に解決できないので、保留。
Make を使う以上は、この問題がずっと、つきまとう。

GMail ⇒ Zapier ⇒ Slack

@gmail.com の場合、連携不可能

Google Workspace などを利用し、企業ドメインなどを GMail で受け取っている場合は、モジュールを接続するだけで連携することができる(みたい)

しかしながら、@gmail.com など(「一般消費者アカウント」と言うらしい、これ)を利用していて、これを外部連携やサードパーティアプリなどと連携する場合は、認証には OAuth が必要になる。

GMail(IMAP) ⇒ Zapier ⇒ Slack

GMail を使う場合、おそらくこれが最も現実的な連携方法なのかも知れないが、この場合「安全性の低いアプリ」として当該アカウントの許可設定をする必要があり、それはそれで不安。

IMAP ⇒ Zapier ⇒ Slack

そもそも IMAP で繋ぐのであれば、自分の場合は GMail に拘る必要がないので、別のメールサービスを使って IMAP を使う。

ISO-2202-JP の問題は特に発生しない。特に文字コードの仕掛けは必要なく、普通に ISO-2202-JP のメールも文字化けなく Slack に配信可能。

ところが、フィルタを追加すると有料。

というのも Zapier を無料で利用する場合はシングルステップのみ、しかも月間100タスクまでという制限がある。

指定メアドに着信したメールをすべて Slack に流して良いのであれば、以下のようなシングルステップとなる。

IMAP⇒ Slack

これであれば、月 100 タスクまでであれば問題ない。
(100 タスク ≒ 処理 100 回、まぁメール100通だけという訳ではないが、正直これはこれで心許ない。)

しかしながら「題名」や「送信者」など、特定条件のみのメールだけをフィルタリングしてメッセージを Slack に流す場合、別途「フィルタ」という処理が別途必要になる。つまり以下。

IMAP⇒ フィルタ ⇒ Slack

これだと処理的にはマルチステップと見做されるらしく、そしてマルチステップは Free プランで利用できない。Starter プラン以上の有料プランにする必要がある。(2022 年 11 月現在、およそ $20/mo …)

詰んだ。

そもそもの話

Slack はプロ版以上だと、チャンネルに個別にメアドを取得することができるので、そこに直接放り込まれるような仕掛けにしたほうがいいのかも。

とはいえ機械的なメアドをそのまま送信者に案内するのも何なので、判りやすいメアドを別途取得して、以下のような感じにするのが良いかと思ってる。

メアド1
(判りやすいメアド)

(転送)

メアド2
(Slack チャンネルと連携している機械的なメアド)

Slackチャンネル

多分コレが一番手間も余計なカネもかからない気がする。

トラップを作る必要性

ちょっと考えてみた。

記事は後日追加する可能性があります。

トラップタワー

いわゆる「TTT」(天空トラップタワー)を作る必要性。
経験値を取得するためや、装備の修繕によく使われるパターンなのだが、制作する手間の割には、あまり利用する頻度が高くない。

というのも、そもそもマイクラの場合、経験値を貯めまくるのは効率が悪いし、そもそも経験値は金床などで消費するために存在するので、わざわざ TTT を制作して経験値を貯める必要はない。

それよりは、大々的に農業と畜産を行ったほうがいい。
その作物を村人(農民)と取引したほうが、エメラルドも貯まるし、経験値も貯まる。
それに牛やニワトリを処しても経験値は貯まるし、収穫した作物を与えれば、新たな牛やニワトリも生まれる。肉は食料や村人の取引材料になる。

農業・畜産の欠点は、自動化するまでの手間と、たとえ自動化したとしても、今度はそれを取引する村人までの間は、プレイヤー自身が収穫物を持って移動しなくてはならないため、その辺りが面倒な事と、1日あたりの取引回数に制限があるため、劣化した装備を修繕するには若干手間がかかること。

でも収穫可能な食物を一通り自動して作成しておくのはクラフト面・取引面で色々と便利なので、個人的にはこちらに力を入れた方がよいのではないかと思う。

それに TTT は、作成する場所まで移動しなくてはならないし、場合によっては周辺のmob湧き潰しなどの対策も必要で、かなりの労力がかかる。

まぁ「TTT はロマン」という考え方もあるので、その場合は止めようがないけど。。。

スライムトラップ

スライムを倒すと取得することが可能なスライムボールは、スライムブロックや粘着ピストンなどで必要になる。

そのため大量に必要な場合は、どうしてもトラップが必要になるのだが、これが 1.19 辺りからハードルが上がった気がする。

理由としては、Y軸が深層化したことと、その影響で地下に大規模な洞窟や廃坑ができまくってしまい、それが影響して、様々なmobが湧く余地ができてしまった。

これを防ぐためには、湧き潰しを徹底するしかないのだけども、これがかなり面倒。
洞窟などの地下構造物は入り組んでいるし、埋め戻すにしても、山を切り崩す必要があるし。
コマンド一発で埋めてしまうのでもアリだけども、できればサバイバルに徹したい自分としては、ね。

洗濯機の給水弁を交換した

まぁこんな修理は、街や電器店やメーカーの修理屋さんでもないかぎり滅多にやることはないので、あくまで備忘録という事で。

この記事には、自前で修理した内容が記載されています。この記事を参考にして修理する場合は、部品が調達できない等の苦情や問い合わせなどの応対はしません。
また修理中の感電事故、更なる故障の発生など、当方では一切責任を負えません。必ず自己責任でお願いします。
自分で修理する自信のない方や、自己責任を負えない方、おカネのある方は、新しい洗濯機を購入することを強くお勧めします。

事の発端(故障状況)

ある日、カミさんから「洗濯機を止めても、水滴が落ちている」と言われたので、確認。たしかに1分弱の間に小さな水滴が数回落ちている。
念のため洗濯層に落ちた水を拭き取り、1時間ほど経過してからもう一度確認してみたところ、やはり水滴が落ちてきていたので、おそらく漏水故障と判断。

故障箇所をネットで調べてみる。

文明の利器ではあるが、洗濯機の水回りの故障というと、洗濯機の側ではなく、とにかく給水栓(要するに水道の蛇口側)のトラブルばかりがヒットしてしまう。
おそらく、そちら側の故障(というか、開栓忘れ)が多いことが原因なのと、原因調査の手順として「上流から順番に調べろ」というのがセオリーなのだろう。

そして次に多くヒットするのが、水栓と洗濯機を結ぶホースとか、接続部に詰まったゴミのトラブル。
これもおそらく水栓とホースが正しく接続されていない(最近の「洗濯機とか食洗機専用水栓」は漏水防止のため「止水弁」が付いているものもある。確実に接続されていないと水が流れない)というトラブルも多いのか。

そして井戸水などの自然水をそのまま使っている場合に「あるある」なのがゴミの付着。
地域差などもあるとは思うが、水道水ではなくミネラルを多く含む自然水は、それらの成分が付着(結晶化・固形化)する可能性がある。配管の老朽化による錆なども流れてくる。
まぁそもそも、そのような水を洗濯機に利用すること自体、許容していないと思うので、これで壊れるのは「自己責任」。しかも洗濯機の給水部だけでなく、それ以外の箇所も壊す可能性がある。

そして見つかったのが、洗濯機本体「給水弁部品」の故障

まぁ、厳密に言うと、この時点では「その可能性」というあくまで予測でしかない。つまり、それ以外の部品が故障している可能性もあるかもしれない。
もしも別の部品故障の場合、今回故障した我が家の洗濯機の場合、製造されてから15年以上経過しているため、もはや修理できない可能性が高い。

でも洗濯機本体の給水まわりの部品の中では、おそらくこの部品が機械的に最も動作を繰り返しているため、この部品が故障している可能性が高いと判断した。

自分で修理するか、メーカー修理(出張修理)してもらうか

我が家の製品は、某パ○ソニックの製品なので、いわゆる町の「パ○ソニックの店」に修理依頼という選択肢もある。

しかしながらこの「パ○ソニックの店」というのが、最近はちょっと信用できない。
というのも、彼らに修理を頼んだとしても「部品が製造終了でない」と言われる可能性があるのだが、それが「本当にないのか」が疑わしい。
ましてや出張修理の場合、その「出張料」すら請求される可能性がある。

そこで今回ネットで調べてみたところ、どうも部品自体は通販で単体入手できるうえ、しかも DIY で直せるような動画や Web のブログも見つけてしまった。

という事で自分で部品を取り寄せ、修理することに決定。

洗濯機の給水弁部品

ちなみにこの「給水弁部品」、部品としては 3,000 円前後のもので、送料も入れるとおそらく 4,000 円前後で入手できる。

ただし機種によって部品の種類が決まっているため、洗濯機の機種番号を必ず確認し、それに対応する部品を必ず入手する必要がある。

そして洗濯機などの家電製品、メーカーによっては製造終了後も何年間かは部品を保有している。
今回の場合は製造終了後、かなり時間が経過していたが、幸いなことに部品在庫が存在したため、修理の見通しが立てられた。

しかしながら部品がみつからない場合、(メーカーが推奨していないかぎり)他の部品で代用することは、かなり難しい。
もしそのような場合は、あきらめて新しい洗濯機を買った方がいい。

あと最近は、海外メーカーや家電から撤退したメーカーも多数ある。これらについての修理は、保証期間内でもないかぎり、修理はかなり絶望的ではないかと思う。
なので、個人的には特に海外メーカー品を購入する場合は、家電店の長期保証を付ける等して対策するしかないかと思う。

ちなみにこれが最後の「賭け」の部分になるのだが、「この部品を交換するだけでは直らない」可能性だって、正直ありえる。その場合、この部品代を始めとするあらゆる労力が無駄となってしまう。

部品を取り寄せている間に、給水部が完全に故障

洗濯をしても、給水がいつまでも洗濯槽に溜まらず、とうとう途中でエラーを吐き出すようになってしまった。
つまり洗濯ができない。

結局、修理が終わるまでは、何度か近所のコインランドリーを利用することに。

洗濯機は修理するまでが大変

そして部品が届き、ようやく修理。
と、その前に、修理をするためには洗濯機を移動させなくてはならない。
実はこの作業が重労働。

  • 給水栓(水道栓)を閉じる。
  • ホース内に残っている水を抜くために洗濯機を空回し。
    (最初の給水だけ動作させ、途中で主電源OFF)
  • 電源コンセントとアースを抜く。
  • ホース内残っている水が吹き出したり、垂れたりするおそれがあるため、バケツとタオルを駆使しながら、身長に給水ホースを取り外し。
  • 排水ホースも、床に水が漏れないように注意しながら取り外し。
  • 洗濯機本体を移動(重労働)

これが一番大変だった

修理自体は簡単

パナソニックの製品は、制御ユニット(基板部分)や給水部分が、本体の上部公報のカバー内にまとまっており、それらはビスを数個外せば、カバーも簡単に外せて、問題となった部品にアプローチすることができる。

スマホ写真は文明の利器

これは自分は修理の際に必ずやっている事なのだが、どこのネジを外して、内部がどうなっているかを写真で沢山撮りながら進めている。

これを行えば、修理後に修理前の状態と同じ状態で部品が設置したか比較できるし、写真の順番を辿れば、修理後の復元方法もわかる。

周辺部品に注意

今回の「給水弁部品」は、あくまで「給水弁部品」しか含まれていなかった。つまり部品に付いていたキャップ類やゴムパッキンなどは一切付属してこないので、もし壊れた部品にこれらの小さな付属品がある場合は、必ず交換後の部品に移植すること。

結束バンドが必要だった

今回、部品に接続していたホースには、水漏れ防止のため「結束バンド」が巻かれていた。今回それを切断しないと部品交換できないため、ペンチで切断したうえで部品交換したのだが、交換後もそのホースに対して、結束バンドを忘れずに巻き直す必要がある。

ただ、この結束バンドは交換部品には含まれていないので、必ず別途準備する必要がある。

幸いなことに我が家には、結束バンドの在庫があったので、それを使ったが、結束バンド自体は、100円ショップやホームセンターでも販売しているので、適宜あらかじめ購入する必要があるかと。

修理後の復元も大変

手順としては修理前の逆手順ではあるのだが、とにかく洗濯機は重い。

最後に試運転して終了

  • 水栓を開いたのち、水漏れしていない事を確認。
  • 洗濯機を最速モードで空回し運転。水がちゃんと洗濯槽に溜まって運転している事を確認。
  • 次に、実際に洗濯物を投入して、普通に洗濯運転。
  • 最後に給水口から水漏れがないかを確認。

問題なければ、修理完了

余談

個人的には今回はDIYで対応できたので記事にしてみたが、ご家庭によっては自前で修理できない場合も多いと思う。

あと普段こういった修理の知識や経験(というか、いわゆる「機械いじり」)に慣れていない人も、安全面などの責任などを考えると、正直やめておいたほうがいいです。

そういった方々は、大人しく家電屋さんに修理相談するか、購入してからの年数をみて、新しい洗濯機を買ったほうが良いと思います。

参考サイト

マイクラのマルチプレイサーバにおいて特定エリアが重いとき

この記事は実例やマイクラの特性をもとに記事にしたものです。
今後のバージョンアップなどによって内容を更新する場合があります。

記事の内容は、Java Edition のマルチサーバを利用している人向けの内容として記事にしています。
一部は Bedrock Edition(統合版)やシングルプレイの場合でも当てはまる箇所はあると思いますが、仕様や実装が異なる場合もありますので、ご注意ください。

必ずすべての記事内容を確認してください。
記事上部で記載した指摘事項だけが原因ではないことが、よくあります。

最近、Youtube などでマルチプレイサーバを実況するなどが多くなり、その際に特定のエリアで遅くなるなどの不具合を見かけることが多くなってきた。

これらは、通常のマルチプレイサーバでも見かけることがあるので、それらの原因をちょっとまとめておこうかと思い記事にした次第。

そもそも論

サーバは、プレイヤーPCほどの CPU スペックは本来必要ないのだが、それでも最低スペックというのがある。

  • メモリ容量
  • ストレージはSSDとすべき(HDD非推奨)

このあたりはマイクラサーバーの処理を安定させる要素の中で、かなり重要なので、良く考えるべき。

特にクラウドサーバや VPC サービスを利用している場合

これらスペックについては、かなりシビアに影響する。
というのも、そもそもクラウドやVPCは、あくまで「仮想サーバ」。
当然ホストサーバが複数の仮想サーバの稼働状況を監視しながら、動的に処理能力を割り当てるので、ホストサーバ全体の処理負荷が高い状態になれば、それだけ処理は重くなる。

そしてこれらはおそらく、契約プランによってサーバのグレードが変わる。
つまり「お金」で解決するしかない。

そこに繋がる「回線」も重要

あとクラウドやVPCでどうしても逃れることができないのが、ネットワーク回線の問題。
いくら高額なクラウドやVPCを契約利用していても、そこに繋ぐための回線が雑魚では意味がない。

昨今は光ファイバーのプランであっても、激安を謳って提供しているプランもあるが、通信品質については、正直おすすめできない場合が多い。
個人的には高くても、NTTが提供しているフレッツ網のサービス、しかもマンションに住んでいたとしても、個宅向けのプランを導入するのをお勧めする。
(ただしマンションによっては、個宅向けの光回線が敷設できない場合もある。マンション管理人や不動産会社に必ず確認すること。)

ゲームのどのワールドでも全体的に処理落ちや動作遅延が発生する場合

ここからは本体の問題。まずは CPU のスペック不足を疑ってみる。
Linux系であれば top, vmstat, sar, free といった各種コマンドで確認する。

特に昔から運用している場合、ver.1.17 あたりから処理負荷の高めな要素が増えているので、そもそもバージョンアップによるスペック不足も疑ったほうがいいかも。

特定のワールド・エリアで処理落ちや動作遅延生じる場合

その場所にある「何らかの要素」を処理するために大量のメモリを消費

メモリを食い潰した時点でメモリスワップが発生
(メモリの内容をストレージに退避する処理が発生)

しかもスワップ先が HDD 領域の場合などの遅いストレージ

という流れで、特定のエリアに入った途端、急激にスローダウンする場合がある。

この場合の対策としてはメモリを増設する、または処理落ちや遅延が生じるようなアイテムの利用や密集状態がワールド内で発生していないか確認し、それを解消するのが、有効な対策となる。

同一ワールド内でも、お互い離れた場所でプレイしている場合

同一ワールド内かつ比較的同じ場所でプレイしている場合、サーバーが処理するエリアは1箇所で済むので、余程複雑な処理(たとえば、複雑な回路を動かす、大量の看板やチェストを設置しているなど)をしていなければ、サーバーはお互いのプレーヤーで必要な共通の情報を「よしな」に合理化して処理するので、処理落ちのリスクは低くなる。

逆に、複数のエリアでプレイヤーがそれぞれの活動をする場合は、処理は重くなる。

特に問題となるのは「ワールドを新規に広げる行為」。
例えばバージョンアップなどで新しいバイオームが追加された場合、それらを探すために、同時に四方八方に分かれて行動することがある。
当然ながらサーバーはそのプレイヤーそれぞれで、新規に踏み入れたチャンクをどんどん生成することになるので、処理落ちのリスクは高くなる。

たまに配信でみかけるのは、ワールドの描画が間に合わない状態でエリトラで飛んでいたら、いきなり山が現れて激突したり、地中に描画されて生き埋め状態になったりなど。

そうなると座標を控えてもいない場合も多く、拠点は遙か手前の場所だったりすると、散乱した持ち物を探せなくなったり、それらを探しているうちに時間切れで消えてしまうこともあるので、そもそも注意が必要。

余談だけども

OSや導入しているパッケージ類についてパッチが提供されている場合は、アップデートしたほうがいい。

というのもアップデートによって、バグが改善されることが、間接的に処理の改善に繋がることがある。

ただし、これは別に「バージョンアップしろ」という意味ではなく、あくまでアップデート・パッチ対応をしろという意味。
アプリケーションの推奨バージョンに倣ったバージョンであれば、バージョンアップまで行う必要はない。
OS 等を無闇にバージョンアップしてしまうと、OS 側のメモリ消費増加や処理が重くなる可能性がある。
(無論 OS にもサポート期間があるので、それに倣う必要はある。)

配信でマイクラサーバを扱うのであれば

クラウドや VPC を利用したほうが手間がかからないし、契約や運用も楽なのはわかるけど、長期に渡って運用したり、箱単位でマルチサーバを利用するのであれば、実機(オンプレミス)でサーバを準備したほうが、安定性は格段に高い。

Javaまわり

Java Edition は文字通り Java というプログラム上で動く。
そのため Java そのものの仕様や特性が、ゲームサーバの挙動にとても影響する。
そして Java という言語、マイクラ開発当初はゲーム開発のうえで先見性があったのだが、今となってはそうではもない。
むしろゲームシステムを Java で制作する場合、そのパフォーマンスを発揮するには「足枷」とすらなり得てしまう。

それでもマイクラのサーバプログラムは、まだ Java の特性を許容した実装が為されているし、Java で開発されてるがゆえ、mod 追加などの自由度が高いのも事実。

この辺りのバランスや動向にも注意を払う必要がある。
これらの理由から Java そのものについても、バージョンアップやパフォーマンスアップデートがあるので、状況を見て、定期的にアップデートしたほうがいい。

マルチプレイサーバの起動オプション

Java のプログラムは、起動時に「メモリ割り当て」をオプションで行うことができる。Minecraft も然り。
通常の Java プログラムおいて、これらを意識する必要はないのだが、ゲームサーバにおいては、このオプションを設定し、サーバの物理メモリに応じた領域を確保したほうが、パフォーマンス向上に繋がることが多い。

これ以外にも、起動時の際に最適なオプションが存在しているので、ハードウエアの仕様に合わせて、それらオプションを設定することをお勧めする。

ゲームの中の状態

建築物や装置が密集している

マイクラはプレイヤーのいる位置を基準にして、その周辺に設置されている建物や装置を含めたワールドの処理を行っている。

そのため、プレイヤーの存在する位置にそれらが多く存在する場合、処理がかなり重くなる原因になる。

複雑な建築物は、存在するだけで負荷がかかることもあるが、特に装置を設置している場合は、未使用時は停止できるような回廊にすることをお勧めする。

チェスト・旗・看板・額縁・ホッパー・…などなど

これらはマイクラサーバにおいて、かなり負荷が高い。

mobの湧き状態

マイクラには、mob の湧く距離が決まっている。これらの特性は別記事で照会しているので、そちらを参照してほしい。

特に気になるのは、mob は地下にも湧くという事。
1.17 以降で地下洞窟が大量に生成されるようになり、1.18 からは、Y軸が更に深くまで生成されるようになった。
しかも1.18 の地下拡張は、1.17 までで生成されたワールド場でも拡張されるため、より深い場所で mob が湧いている可能性もある。

地下洞窟や地下建造物

要するに、地下空洞があると、その場所の1ブロック毎に明るさや mob 湧きの試行などが行われることになる。
これら単体では処理負荷が高くなくても、多くなれば負荷になることがある。
これらに最も効果的なのは「埋め戻し」だが、現実てきではないことも多いので、せめて拠点については、湧き潰し(松明による明るさの確保)をしたほうが良い

水流・溶岩流

整地や景観を整えるために、表面だけ埋めることがあるとは思うが、特に水流・溶岩流になっている場合は、通常のブロックで埋めていまうことをオススメする。
というのも(溶岩流はアイテムを落としても燃えるだけなので、水流に比べて処理は軽いと思うのだが)水流は、流れや流量といった内容を計算処理しているため、特に複雑な状態で水面だけを埋めてしまった場合、負荷に繋がるおそれがある。

これも最も効果的なのは「埋め戻し」。特に砂漠バイオームで入手可能な「砂ブロック」は、これら埋め戻しにとても効果的。

ワールドの状態を把握するための裏技

「スペクテイターモード」の使用をおすすめする。いわゆる「神視点モード」。
プレイヤーが存在した状態で、この状態を動かせば、地中の状態だけでなく、mob の湧き状態も含めて把握することができるようになる。

ただしこのモードは、ワールドの状態を簡単に把握できてしまうモードのため、配信でマイクラをプレイ実況している場合は「チート技」となってしまう。

そのためこのモードを利用する場合は、あくまでサーバ管理者に限定して利用し(そうでない場合は、利用する条件を厳しく決めた上で運用し)、ゲームプレイの方向性を見極めたうえで、プレイヤー(配信者)に伝える要否も含めて、十分検討すべきだと思う。

現状自分も、このモードは、厳密なルールに基づいて運用している。