はてなキーワード: フィルターとは
タイピング自体はまあまあ早いんだけど、なんかそれだけって感じ
特に関数で集計した数字を信用してないのがよく分からない。手入力する部分はヒューマンエラーが起きる部分だから、チェックするのは分かるけど
自動で集計される部分までいちいちチェックするのは目的が全く分からない。一度だけ理由を聞いたけど理解不能すぎて忘れた
会計ソフトのフィルターとか、集計機能を使わないのもよく分からない
例えばコピー用紙を毎月どれぐらい買ってるか、会計ソフトから絞りたい時に「消耗品費」や「現金(預金)」で探すと
関係のないものまで出てきて邪魔だから、摘要や取引先名で絞れば効率よくコピー用紙をどれぐらい買ってるのか分かるのに
一度見かねて「こうやって複数の条件を設定してあげると絞り込めますよ」と教えたが全く理解できていなかった
その割に本人は、やれクラウド化しろだの電子決済がなんだのと言っている。まずは手元にある会計ソフト使いこなしてから文句言えばいいのに・・・
売掛金の管理だってそう。せっかく取引先でソートできて、なおかつ金額の集計も会計ソフト単体で出来るのに、いちいち電卓叩いて計算してる
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
大学3年の夏休みに右も左も分からずアフィサイトかメルマガかなんか見て登録した新卒就活エージェントX
会員登録したら2,3営業日中に電話で連絡差し上げますと自動返信メールが届いてソワソワしながら待ってたのに一向に電話鳴らず、こんなものかと放置
しばらくたって翌年4月、「Xですがみなさんに就活の進捗伺ってまして、いかがですか。よかったら企業を紹介する」と突然営業電話をよこしてきた
Xに登録したことなんてすっかり忘れてて、どこなのかその時はピンと来てなかったし、既に別の企業から内定が出ていたが、ノリで面接を受けることに
面接が始まると事前に書かされたプロファイルシートをなんとなーく添削してもらって恩の押し売りをされた後、見てる業界を伝えると企業を紹介されたが、どれも待遇も仕事内容も新卒カードを使うのはもったいなさそうな企業
エージェントにどの今内定がでてる企業と比べても微妙だと伝えたが「説明会だけでも行ってみればいいんじゃないですか^^」と。
俺が行きたくないって言ってるのに完全にお前の都合じゃねーかと思ったが、断り切れずに2社説明会を受けることに
これって登録時にはエージェントの癖に生意気にフィルターかけて、フィルターを通過したエリート達のお眼鏡にかなわなかった余りものゴミ企業をゴミ学歴どもなら受けてくれるだろうと今更連絡してきてあてがおうとしてきたってことだよね
そう考えたらムカついてその後は連絡来ても無視した。向こうだって舐めたことやってるんだし
そうはいっても自分より時給が何倍も高い大人が自分の為に動いてるのは事実なので心苦しい。なぜこんなゴミ企業を押し付けられた上にこんなどうでもいいストレスまで感じなきゃいけないのか
という訳で日東駒専以下⑨の低学歴はエージェントなんか使ってもゴミ企業紹介されるだけだしよっぽど困ってなきゃ使わなくていいよ
なめられてます
https://anond.hatelabo.jp/20220118205437
相談所の担当の人に、2回目は会いたくないと伝えると、遠回しに高望みだと諭される。もう、こういう人の中から選ばないといけないのか?
まず大前提として、その行間から漂う「年齢等の事情もあり手っ取り早く相談所を利用しているが、私は本当は自由恋愛で相手を見つけられる」という意識を捨てろ。元増田の恋愛経験・恋愛力を否定はしないが、少なくとも、生活圏内で自然に出会える範囲の異性の中から生涯の伴侶を29歳までに見つけられなかった或いは繋ぎ止められなかった程度の自由恋愛力である。そんなものは役に立たない見栄でしかない。
次に、「もう、こういう人の中から選ばないといけないのか?」とあるが、そのとおりですが何か? としか言いようがない。何故かと言えば、相談所の人が最初に選んでくれたその3人が、現時点でその相談所で活動している男性の内、少なくともスペック的には元増田の希望条件に合った中で最上位級であり、以降はスペックが下がっていく可能性が高いからだ。故に、以降はスペック部分を妥協するかスペック以外の部分を妥協するかしかない。それがどうしても嫌なら自由恋愛市場(婚活アプリ含む)に戻ればいい。ちなみに先週あたりにバズっていた婚活女子増田みたいに、相談所より自由恋愛(断言するが婚活アプリは自由恋愛市場である)向きの人も確かにいるので、やる気と時間をかけられるなら(←重要。普通の人は無理)、並行して利用してみればいいだろう。
で、以降は自由恋愛市場に戻ることを選択するなら読む必要はないが、相談所で活動するなら読んでいただければと思う。罵倒にならないように配慮する。
・専門学校卒
学歴で容赦なく弾く男もいるが、普通は相談所側から、どうしても譲れない場合を除いて専門卒以上OKとしろと指導されるはずだし、逆に特に理由もなく4大卒とかに拘るような男はやめておく方が良いので問題ない。
専門職だし、その年収で嫌がる男は多くない……というか相談所で嫌がるなと指導されるはずである。問題ない。
恐らく、所謂「普通の見た目」で、職業柄筋肉もついてらっしゃるのだろう。相手がよっぽどルックスに拘らない限りは少なくともデメリットではない。なお相談所で美人じゃなきゃ嫌だとか言う男はバカなのでやめておく方が良い。
その年齢でその預金額は普通にすごいのでまったく問題ない。なお、「いくらあります!」と言うよりは、「毎月約〇〇円くらい貯金するようにしてます」、と言う方が堅実な印象を相手に与えられるであろう。
その趣味を否定しないが相手に正直に話すのは論外である。元増田がどんな言い方をしてるのか知らんが、「映画を見るのが好きだが、職業柄感染リスクの高いことはできず、なかなか出かけられないのでNetflixを使ってます」程度が良いと思われる。ジャニヲタなのは少なくとも初回では言うな。ついでに言うと生活に支障をきたすレベルのヲタ活をもししてるなら即刻やめろ。
そうは言うがぶっちゃけ何円以上希望とかあるだろ? 正直になれ。例えば、同じ地域、同年代で正規雇用の男性の平均年収くらいは欲しいとか。そういう「気にしない」とか言いつつ本当は気にしてるみたいなのが、まずスペックで絞り込む相談所的には最も厄介である。ついでに言うと、よっぽど運が悪い事情等が無い限り、平均年収を大きく下回るような仕事しかできない男は病気があるとかよっぽどアホとかなのでやめておく方がよく、そういう意味でのフィルターとしても年収は機能するので考えろ。
・相手の親と同居したくない
まともな男なら相談所から指導されるはずなので(略)。ただ、もし比較的田舎在住なら、敷地内同居くらいまで妥協する必要はあるかもしれない。
・ギャンブルやらない人
月数万以下の「趣味」としてやってる人はOK、くらいまで妥協する必要はあるかもしれない。要は生活に支障をきたすレベルでなければOKということだ。実際、そういう男はけっこういる。なお、趣味としてやってる自負のある男は「ギャンブルはやってないけど趣味でスロット打つor馬券買うよ」とかいう場合もあるので、そういう意味でも要注意事項ではある。
・39歳以下
・子ども1~2人ほしい
+10歳までOKとか素晴らしい。まったく問題ないが、子供欲しいならむしろ+5歳くらいまで絞ってもいいと思われる。婚活で出会う→結婚→妊娠出産まで、どんなに最短でも1年半くらいはかかることを計算に入れておけ。
一人暮らししようがしてまいが家事をやらない奴はいるので、一人暮らし経験には拘るな。家事ができることには拘っていい。というかこのご時世、まったく家事をやる気のない男はよっぽど激務で年収高いとかでもない限り普通に地雷案件なのでやめておく方がいい。
・太ってない
なるべく妥協しろ。例えばぱっと見の印象でちょいデブくらいまではOKみたいな。芸能人・芸人さんとかで「この人まではOK」みたいなイメージをしておくといい。
・煙草吸わない
問題ない。
元増田のスペックおよび相手への希望条件は総じて問題ない。であれば相談所の職員さんの言う「高望み」とは何か? 率直に言えばスペック以外の部分に求める基準が高いということである。文章からの印象でしかないが、特に、相手の「察する力・気遣い力」に対してが高望みだと感じる。元婚活男として言うが、相談所にいるような男でスペック的に問題ない奴は、総じて「相手を察して自分からアプローチする」のが大の苦手であり、だからこそ相談所にいるのである。遠回しに言うな。
例えば一人目として挙げている男なのであれば、「職業柄そういうのが気になるのでやめてもらえないか」とハッキリ伝えるべきであったろう。相手の男は元増田が何故それを気にするのか察せられなかったので、自分の知識内で「潔癖症なのかな?」と思ったに過ぎない。そんな低お察し力の男は嫌だと思うかもしれないが、できれば「察せられなくても、はっきり伝えれば理解を示してくれる・改善できる男はOK」程度まで意識を変える(それはつまり妥協するということである)ことをお勧めしたい。
元増田さんは本当にちょっぴり意識を変えれば多分すぐ結婚できるので頑張ってください。
・元カレ(SE)とは4年付き合ってたけど都内でコロナ緊急事態宣言中にデリヘル呼びまくって性病感染したのがきっかけで別れた。
・デリヘルを自宅に呼びまくった
つまり、結婚相手としては非常に問題があった可能性が高く、ぶっちゃけ言ってしまうと
「元増田さんが恋愛的な意味で良いと感じる男性は結婚相手としてはクソなタイプ」
もう、こういう人の中から選ばないといけないのか?
と見下している「こういう人」の方が結婚相手としては適している可能性が大いにあります。元増田さんが相談所での活動を継続されるのか自由恋愛市場に戻るのか知りませんが、元増田さんが恋愛的な意味で良いなと感じた相手はむしろ危ないかもしれない、そう心の片隅に置いておいてくださいませ。
gmailを割と早くから使っているので(当時は招待制だった、ほぼ形骸化してたが)、シンプルなメールアドレスを持っている。
そのおかげで身に覚えのないメールが結構な頻度で届いて困っている。
たとえば登録した覚えのないサービスへの登録完了メールやキャンペーン案内メールなど。
スパム通報して迷惑メール登録していたのだが、たまにフィルターをすり抜けてくることもあって鬱陶しいし、自分がそのサービスを利用することになった時に困るのもいやだ。
なのでそういう事態が発生するとメールに心当たりがない旨を送信元に伝えて登録解除しようとするのだが、それが最近難しくなっている。
たとえばメールの本文中に「登録解除はこちら」みたいなリンクがあってもフィッシングやマルウェアのリスクを考えれば迂闊にクリックできない。そういうリンクがない場合もある。
また、送信元を検索サイトで探して申立てするにしても、窓口はチャットボットという場合が多く、会員ではない自分向けの情報になかなか辿り着けない。
有人の対応をしてもらう必要があるのだが、サービス提供元のの電話窓口やメールアドレスなどが記載されてない場合が最近は多い。
呼吸から出る、飛沫(ひまつ)よりも小さな粒子はマスクをどのくらい通り抜けているのか。理化学研究所の研究チームが、マスクを通過する粒子の大きさと数を測る実験をしたところ、素材によって結果に大きな違いが出た。
新型コロナウイルスは、せきやくしゃみなどで出る飛沫や、おおむね5マイクロメートル(0・005ミリ)より小さな水滴が空気中にただよった状態のもの(エアロゾル)を吸い込むことで感染すると考えられている。
マスクが重要なのは、ウイルスを含む飛沫やエアロゾルを広げたり、吸い込んだりするのを防げるからだ。マスクがどのくらい小さな粒子まで防げるかを調べたものとしては、スーパーコンピューター「富岳」のシミュレーションが知られる。ただ、あくまで計算上のもので、実物のマスクがどのくらいの性能なのかを比べた研究は少ない。
理化学研究所光量子工学研究センターのチームは、微細な水滴をつくる噴霧器と微粒子カウンター(計測器)を組み合わせた装置で、マスクの種類によってどのくらい小さな粒子まで防げるのかを比べた。
噴霧器でつくった微小な水滴をウイルスが含まれた粒子にみたてて、プラスチック製のケースに充満させた。ケースには10センチ四方ほどの穴があけられている。この穴を、さまざまな素材のマスクのフィルター部分の生地で、隙間ができないように塞ぎ、その先にある微粒子カウンターで、マスクの生地を通り抜けた粒子の大きさや数を計測した。マスクはウレタン製(2種類)、医療用マスク(2種類)、不織布、布製の計6種類を試した。最も性能がよいのは医療用マスクで、0・5~5マイクロの粒子をほとんど通過させなかった。さらに小さな0・3マイクロ以下の粒子についても、通過する量は約1千分の1に減っていた。不織布や布製マスクもほぼ同様の性能を示した。
一方で、ウレタン製のうち一つでは、生地を通過する5マイクロの粒子数を約10分の1に、2.5マイクロの粒子数を約半分にできたものの、それよりも小さな粒子はほとんど防げなかった。もう一つのウレタン製は、通過する小さな粒子を数百分の1ほどに減らしていたが、不織布ほどの性能ではなかった。
新変異株で重要なマスクは? マスク抜ける飛沫、理研が数える実験 [オミクロン株] [新型コロナウイルス]:朝日新聞デジタル
みんな大好き、「エビデンス」だよー。
登録者数万人~数百万人のYotuberのコメント欄でよくあるのが「この雰囲気がすきです!〇〇が△△を相方として大事にしてるのが~どうのこうの」とか
「ひさびさに前と同じような雰囲気でうれしいです」とか今まで見てきた自分というフィルターを通して俯瞰で見てる内容。
そればっかりついてるコメント欄見ると辟易とする。結局、その動画に言及してるものはほとんどないし、あっても「5:30の〇〇の表情すき」みたいな
本当にその動画に対してのコメントなんか?と思うような中身ないもの。
登録者が少ないYoutuberにはそういう定型文ぶら下げるファンが少ないから比較的内容に触れてるコメントが多いけど、固定ファンが増えれば増えるほど
こういった類の定型文で埋め尽くされる。大抵めちゃくちゃいいねついてる。だから上位に表示されて埋まる。
新しい企画試みても定型文で埋まるの当事者はどう捉えてるんだ?その中に少しある実のあるコメント抽出したり、再生時間・滞在時間とか数字見て良し悪しを決めるの?
GIGAZINEの記事でスパチャのランキングが見れる事を知って眺めてみたがとても興味深かった。
ランキングの上位をほとんどがVtuber系で占められてるというのはまあそうなんだろうなって感じだし、
事務所ありきで大人がたくさん動いて運営などの維持を考えたら、やっぱそれなりの見返りがないとやらないだろうと想像はしていた
自分がへーと思ったのはそういったVtuber系に混じって、恐らく個人活動かそれに近いであろう実況配信系の人でめちゃんこ稼いでいる人がいる事だった
2021年間ランクを日本国内のみでフィルターした結果https://playboard.co/en/youtube-ranking/most-superchatted-all-channels-in-japan-yearlyだが
例えば13位のbintroll、15位のふぁんきぃちゃんねるなどは年間7千万近くのスパチャを稼ぎ出している。7千万て。
これを個人の実況動画だけで出してるとしたらとんでもない額だ。自分のイメージとは桁が一桁違っていた。
内容的にはゲーム系実況ベースでただのおしゃべり配信もしつつという感じっぽい。bintrollのほうは一応チーム運営されてるようだが大人ががっつり入ってますというよりは割と手弁当スタイルな雰囲気。
スパチャの還元率はPCなどからで70%くらい、iPhoneからだと50%くらいらしいのだがざっくり50%で計算したとしてもスパチャだけで年収3,5千万プレイヤー。
いやーすごいな。この計算ほんとに合ってるのか?
他にも50位以内にちらほら入ってくる実況系の人なんかはだいたい数千万レベルでスパチャを稼いでいるようだった。
ゲームなどの実況系以外だと芸能系では霜降りの粗品は36位にいて4千万近く稼いでたり、あとはメンタリストのDAIGOが63位にいたりした。
ただ目についたのはそれくらいで思ったより数は少なかった。
芸能人だとそもそも本業が忙しかったりして配信するのはなかなか大変だろうとは思うけど、多忙なはずの粗品がわりと上位にいたのは短い配信でもがっつりスパチャを稼いでいるのかもしれない。
後はピアノというタグがついてるのとかは演奏系なんだろうと思う。演奏系は個人的に好感が持てる。ライブしてくれる音楽にお金を投げたいというのが自分には一番理解しやすい。
実況系の人らも恐らくこれだけスパチャを投げてくれる人がいる状況になるまでは色々な積み上げがあるんだろうなと思うけど
元々Youtuberとして有名な人たちがスパチャで稼ごうという方向になぜいかないのか不思議でもある
普通に再生数で伸ばす動画を作って上げてるほうが結果的にはもっと稼げるということなんだろうか
あとそもそもだけどスパチャに関しては世の中にこんなに投げられる金を持ってる人がいるというのかという驚きが一番かもしれない
マジレスするとスーパーやドラッグストアにある浄水器でも大別して二種類ある。
ひとつめはアルカリイオン水とか電解水とか言っている奴。これは正直言って正体不明なので、「普通の浄水器」(商品名で言えばクリンスイとかトレビーノなど。中空糸やセラミック濾過)の水との優劣の判断は保留する。
二番目は「純水」と言っている奴。これは「逆浸透膜」というのを使っていて、名前の通り「純水」。もちろん半導体工場などで使う超純水などとは桁が違うが、原水の金属イオンは98 %以上除去されている。有機物(トリハロメタンや農薬類など)や細菌類はほぼ100 %できるが、これは「普通の浄水器」でも同じ。これと同品質の水が出来る家庭用の浄水器は初期費用が2~5万円程度して、1日2 Lだとフィルター交換費が年1万円程度かかる。しかも純水1 L作るのに10分程度かかり、その間蛇口が占有される。(実際に使ってみてこれが結構厄介。)
水道水の基準は有害物には厳しいが、健康にあまり影響の無い塩分(Na+ Cl-)は基準値※が200 mg/Lこれは海水を約15倍希釈すれば満たす値、硬度も硬水で有名なエビアンの1/3程度の100 mg/Lと、かなり「甘い」から地域によっては「普通の浄水器」では除去できないこれらの成分で水道水が「不味い水」になっている場合があるので純水を使う合理的な理由は有る。(※ https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/topics/bukyoku/kenkou/suido/kijun/kijunchi.html)
浄水器でスーパーに囲い込まれる、という認識は間違っていないが、二番目のタイプの純水なら「買い物ついでに利用」も悪い選択では無いと思う。むしろ問題は純水製造機の前に行列が出来て、時には10分程度の待ち時間が掛かること。時給5000円くらい稼いでいる(年収1000万程度)人なら1000円近い「時間コスト」になるのでおすすめ出来ないが、年金生活者ならリーズナブルな「時間のマネタイズ」と思われる。結局のところ、問題は「いつも使う店で少し余分に時間を消費する」のか「無料の水のために従来行かなかった店にお金を落とすか」の差ではないか。
女優やらアイドルやらの登竜門として全国高校サッカーのマネージャーを毎年決めているが、もうご時世に則していないので変更したほうがいい。
今日びのサッカー番組などではサッカーをまったく知らない人間は見ない。だいたいなんらかの形でサッカーに関わっている。
アイドル的な女の子が出るときもちゃんと知識のある人間を選んでいる。
なので、ただ見た目がかわいいとかそういうチョイスでマネージャーとして採用して高校サッカーの中継にのこのこ出すのはとても変な感じがする。
今後もマネージャー制をやるなら、
・男性も起用する
くらいのフィルターはかけて欲しい。
以上です。東山がんばれ!
専用の2Lぐらいの入れ物が1個500円ぐらいでそれを買えばあとは何度でも汲みに来れるっていうアレだ。
見るからにケチ臭さそうなオバちゃんが専用容器に水をタプタプにしてはいるアレだよ。
あんなものを使って水を汲むなんてまるでアフリカの恵まれない子供たちみたいじゃないか。
そう思っていた。
帰郷した僕が勝手知ったる自分の家とばかりに実家の冷蔵庫を物色しようとすると、ソレは冷蔵庫に収まっていた。
水としか思えないものが2Lぐらいの真っ白いポリタンクに入って2つ並んでいる。
冗談めかして
と聞いてみた。
親は答えた。
と。
親が言うには浄水器のフィルターが減価償却される時間と値段を考えれば、スーパーで水を貰う生活を1ヶ月も続ければ元は取れるらしい。
なんだかんだ平均で1人2Lほどの浄水を毎日使うので毎日スーパーに行っているらしい。
両親揃って年金ぐらしに突入して暇しているから出来ることのようだ。
客寄せのためかいいフィルターを使っていると言っていたが、たしかに実家で飲む水の味は昔より美味しい気がする。
というか、実家で飲んだ水の8割ぐらいは使い古しのフィルターにまだ効果があると信じてほとんど何も濾過されていない水を飲んでいたのだと思う。
有料のペットボトル水、たとえばコンビニの「霧島」なんかと違って妙な感じもせずタダすっきりとおいしい水なのも毎日使うことを考えると助かるだろう。
どうも話を聞いていると両親はその容器を購入してからはほとんどその店で買物をするようになっているらしい。
図々しさを極めれば水だけ汲みに行って何も買わずに帰ることも出来るのだろうが、どうもそれは出来ずついでに何かを買ってしまうのだという。
僅かな投資で朝的な利益を得ているのはスーパーの方なのだろう。
固定客の確保という大仕事をボタンを押したら水が出るだけの機械がやってのけている。
両親は飲み水の確保をスーパーに委託したことでスーパーに縛られているのだ。
スーパーは水という最大の資源を利用して人々の生活を支配しているのだ。
やはりアフリカだ。
何の話をしているのかがよくわからないけれど。
当時の熱狂を想像できない程度の知性の人間がその物事を冷静に評価することって出来るんだろうか?
単に後世のフィルターという色眼鏡でもって古いものに点数をつけるのを評価というのであればその通りなのかもしれないが。
彼のことを勉強しないといけないし
そこまで彼のほうへと自ら足を運んで至近な状態になってからこそ、
そうじゃなくても古いロックスターである彼と我々現代人の距離は広がる一方で
そのポジションでもって彼を知ったような気になって評価してもしょうがないじゃないか。
古い物事を批評するときには対象をしっかりと勉強して時代を想像して
対象を十分に好きになる。
そのあとであらためて冷静な客観的視線を持ち込んでこそ評価できるのではないだろうか?
じゃないと当時は革新的だったが今となっては大したことがないという結論しか出ない。
それはプレスリーのことであっても他のことであったとしても。