  |
はてなキーワード: 西日本とは
ここ数年、なんだかとってもしんどい。
コロナのせいもあるのかもしれないけど、実はコロナ前から心がしんどい。
今年のGWは前半５日間を使って西日本一周ドライブに行ってきた。子供２人を連れて。
何をするでもなく高速道路を走り、自然豊かな九州を訪れ、海と山を見て癒された気がした。
社会人になり、いつしか「効率厨」になっていたことに気がついた。どうせやるのなら成果が
でる方法を選びたいし、結果にこだわって何事も挑戦していくべき。そのためには、効果が
出ないことは極力排除し、効果が出そうなものだけにフォーカスしていくべき。
そうやって動くクセがついていくと、仕事だけでなく人生全般にも効率厨思想が侵食してくる。
フロー理論によると、時間を忘れて没頭している状況そのものが人間の幸福さに関連しているらしい。
効率厨で求めるのは定量的な外的報酬。仕事でいえば業績、プライベートでもSNSやブログをやれば
PVや広告収入に目がいってしまうが、うまくいっている間は良いが、そうでなくなると一気に精神が
不健康になってくることに気がついた。
PVや広告収入はコンテンツの良し悪しよりもニュースサイトに掲載されたとかバズったとか、外部要因
が大きく作用しており、自分自身の努力でどうにかなる範囲を超えている。だから、ブログを書く自分の
労力（時間）と、PVや広告収入を比較しはじめると途端にしんどくなってくる。本来は余暇として過ごす
べき時間を、人生における効率を求め始めることで、ストレスの源になってしまっていた。
思えば、１０年前のブログはストックだった。誰かに役に立つかもしれないエントリーを書いておけば
google様のおかげでそれなりにトラフィックが来た。ニッチでも書き溜めておけばストックになった。
今は違う。SNSも、instagramもtiktokも、Youtubeも、完全にフロー。ブログもその傾向が強い。
エントリー公開時の初期流入以外ではほぼバズらない。書き溜めておいてもストックにならない。
これまではストック化できていることが心の拠り所だったんだけどなあ。ストック化できるものを何か
明日からこれまでと変わらない仕事まみれの日常が始まる。仕事と生活をリンクさせればさせるほど、
仕事で何か失敗があった時に生活丸ごとダメージを食らうことがわかってきた。今後は仕事と生活の
まず土地選びな
・当然ながら都市部でウーバーイーツと８Ｇくらいの光回線が届くといい（セブンスポットはおわったがタダノリできるwifiが近くにあると頻繁に業者乗り換えたい人にもやさしい）
・地図みて冠水歴のない地区な、地震が多い関東もやめたほうが？
・となると西日本中心になるかもしれんが、高確率で遺跡が埋まってたりする、工事のまえに学術調査入ってすぐにたてられない
つぎハウスメーカーな
・パナホオオムは屋内有線ＬＡＮちょっぱやで引いてくれるぞ 逆にテレビアンテナとかテレビ引き出し口はもういらんやろ
・トヨタホオオオムはなぜか土地に家をあわせず家に土地を合わせようとしやがるがたまたま合う土地があれば堅牢で安いっぽい、ＬＡＮはしらね
・各室ＬＡＮ口とガス配線はしてもらうべき
・ユニバーサルデザインで段差を全部消すべきだが平やは無理だし２階建てはするべき
・２ｆ寝室の近くに風呂つくるの男の夢だとおもうが高圧洗浄がマンション向けになる点は留意
次内装
・食洗器楽ちん
・ＡＶ（ドルビーサラウンドとか）は金かけすぎないほうがいいとおもう（やるならスピーカー配線など埋め込みたいから最初からやるべきだが）
そんで人をしょっちゅうよんでたらすぐ嫁がきそうなきがするしもはや弱者の自称をするべからずさもないと宇宙の法則が乱れる しらんけど
コイ本来の分布
もともとはユーラシア大陸が自然分布域だったが、移植によって世界の温帯・亜熱帯域に広く分布している。日本でも全国的に分布。
日本のコイは大昔に中国から移入された（史前帰化動物）と考えられ、縄文時代の貝塚からも化石が発見されている。しかし、関東平野や琵琶湖に野生のコイが分布することや、古い地層から化石も発見されていることから、日本にももともと自然分布していたが中国からの移入がありそれが広まったとされる
つまり、外来種の可能性は高いが、外来種であるという確証もない、というのが現在の通説のようだ
少なくとも縄文時代には日本に入っているので、外来種だとしても2000年以上前に伝わっている
それを外来種だとして日本から排除するのが正解なわけがないし、日本は少なくともこの2000年はコイ込みで生態系を回している
このような生物種を、起源だけでレッテル張りして駆除を主張するのは明確な間違い
コイを駆除しても2000年前の生態系に戻ることはないし、2000年前の生態系が理想的とも言うことはできない
コイによる生態系の破壊問題
コイは都市河川などで川をきれいにする目的で河川の環境保護の一環として放流される種でもある[2]。しかし、コイの本来の生息域は大河川の下流域や大きな湖で、中小河川に放流されると他の魚の卵や稚魚を大量に捕食してしまうことがある。こうした放流について、地元の固有種との交雑が起こって何万年もかけて築かれてきた固有種の絶滅を懸念する（遺伝子汚染）声もあるが、当事者には全く意識されていないのが現状である。
大河川の下流域に放すならば遺伝子汚染やコイヘルペスの防除などのリスクを除けば、生態系としては通常は問題がなく、中流域以上に放流するなら場合によっては問題がある
ちなみに話題のニュース、三重県伊勢市の馬瀬川は海もほど近い下流域
https://hicbc.com/news/article/?id=2022031302
日本の個体群に関しては化石の発見例がない、最も古い文献でも200年前に登場し江戸時代中期以前には本種に関する確実な記録がない、江戸時代や明治時代では希少で西日本や南日本にのみ分布するという記録があることなどから、朝鮮半島から人為的に移入されたと推定されている。台湾の個体群も中華人民共和国の個体群と遺伝的差異がないため、人為的に移入されたと考えられている。
200年前、江戸時代末期には日本にいたと思われるが、それ以前に全く痕跡がないことから外来種である可能性が濃厚
しかし、江戸時代末期以降は西日本、南日本の一部では定着していた
これはもう、コイのように有史以前から、というわけではないが、それなりの歴史がある外来生物である
ではこれを本当に外来種と呼ぶべきかどうか？に関する見解のひとつはこれ
https://kobe-sumasui.jp/wp-content/uploads/2020/10/H24.12.Kiraku04_01.pdf
この法律では，海外から入ってきた生物に焦点を絞り，人間䛾移動や物流が盛んになり始めた明治時代以降に導入された生物を中心に対応する，とあります．
時々，この外来生物法における対象生物の侵入時期の指定が「明治時代以降」と記されていることから，クサガメ日本列島集団は外来起源ではあるが江戸時代には日本に生息していたため外来種とは呼ぶべきではない，と言われる方がおられます．
しかし，そのような解釈は間違っており，現行の外来生物法では明治時代より前に定着した生物を対象とすることが困難であるかもしれないが，「外来種」という言葉の意味や定義を変えることはありません．
クサガメはここ100年ほどで分布を広げ、ここ数十年ではイシガメの減少の原因としても理由があがるなど、日本の生態系がまだ固定化されていない遷移状態と言える
そこに1950年代後半以降はミシシッピアカミミガメなども遅れて移入され、逆にクサガメは減少に転じるなど、さらに生態系が変動している
このような状況の生物は、まだ在来種として保護する段階にはない、と言ってもいいかもしれない
少なくとも「日本ではクサガメ込みで生態系を回してきたんだ！」という段階に至るほど歴史は古くはない
が、差し当って外来種駆除の優先度が高い生物種は特定外来生物に指定されている
そのリストがこれ
https://www.env.go.jp/nature/intro/2outline/list.html
ここには当然、コイもクサガメも記載されていない（ミシシッピアカミミガメやアメリカザリガニは本来指定すべきだが、一般化しすぎて影響が大きすぎるため保留になっているのは例外的）
特定外来に指定されていない外来種は野放しでいいのか？というとそう簡単ではないが、特定外来種とクサガメを同列の優先度で語るのも、それはそれでおかしい
池の水全部抜く、では、いかに生態系が壊れているか、汚染されているかが伝わるほうがセンセーショナルなので、少しでも外来種の可能性があるものは全て外来種として放送している
こんなに外来種たくさん！ってやったほうが撮れ高がいいし、そうやりたい番組だからそうしている
インターネットサーフィンに勤しんでいる人なら一度は聞いたことがあるかもしれない「イヤンホホ」という言葉。
イヤホンを気の抜けた音で言い換えたこの言葉は、実は東日本大震災から3日後の2011年3月14日に2ちゃんねるの雑談掲示板から生まれました。
当時、そのスレッドではアクセス元（主に都道府県）の表示があり、今でもログを見ると当時雑談掲示板に書き込みが出来た地域、そうでなかった地域がわかります。
当時仙台にいた私の家では電気が遮断されていたので、震災後しばらくたってからこのイヤンホホという言葉を知りました。
最初はキャッチーで面白い言葉だと思ったのですが、この出自を知ってからイヤンホホという言葉を目にするたび、震災時に東北地方抜きで面白がって不謹慎なネタも飛ばして盛り上がっていたような関東・西日本の人間が作った言葉なんだよなと思ってしまいます。
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
区別がつきにくかったり、似た言葉だったりすると、ガキの頃はなかなか覚えにくい。
そんな俺が当時考えた、おぼえやすい覚え方。
【東と西】
北と南はすぐにイメージできるけど、ガキのころは東西がマジで区分不能だった。
まずは日本地図を思い浮かべ、その左側にあるのはJR西日本だから西、右側はJR東日本だから東と毎回思い浮かべるうちに区分できるようになった。
【September・October・November・December】
あ？んだよ全部全部berberberberつきやがって！わかるか！！ってな感じで同じく区分不能。
でもこれは「SOUND」の綴りにあてて覚えたらすんなりいった（Uはダミーだけど）。
【蛇口を閉める方向】
閉めるつもりで思いっきりひねったら勢いよくジャァァァァー!!!!ってこと多々。
どういうことかというと
「時計の進む方向」→「時が進む」→「人間が年を食う」→「死ぬ」→「死ぬのは寿命だけじゃなく、首を"絞め（閉め）られても死ぬ"」
という随分と遠回りな覚え方なんだけど、慣れると
となるのでそう不便はなかった。
ちなみにネジを締める方向もこれで覚えてる。
