  |
はてなキーワード: タグとは
ケツワープとは、スーパーマリオ64に存在するバグ技を使った移動方法である。
これを使うことでシーケンスブレイクやマリオの加速移動によるショートカットに使えるため、TASでは頻繁にこの技を見かけることができる。ケツワープを多く利用する動画には「ケツゲー」などのケツに関するタグが付けられる事もある。
ちなみに「ケツワープ」はニコニコ動画内での通称。海外ではBLJ、すなわちBackwards Long Jumpと呼ばれている。意味は「後ろ幅跳び」。 後ろ幅跳びのモーションがケツを地面や壁に擦り付けているように見えるので「ケツワープ」と呼ばれている。 海外勢がケツワープという呼称を知り、「実用的で直感的」と評して話題になったこともある。
https://dic.nicovideo.jp/a/%E3%82%B1%E3%83%84%E3%83%AF%E3%83%BC%E3%83%97
https://anond.hatelabo.jp/20220125183017 が何か盛り上がっていたので思いつくままに追記...しようと思ったのですが、私の話より先に、いただいた「やりたいこと」をまとめさせてください。
たくさんのコメントありがとうございます。拾えてなかったらすみません。
いただいたものを眺めつつ、この週末に新しいリストを作ってみようと思います。
私のリストは、結構個人的なものも含むのでそのうち整理して、気が向いたら公開します。
...とは書きましたが、だからといって不幸な気分ではありません。
たとえばクイズのバラエティ番組を見てて、世界遺産とか地域の名物がクイズの答えになってて、そこに行った思い出の話を楽しんだりとか、普通にあります。行ったことがない観光地が紹介されていて、行ってみたいなーと思うこともありますし、実際に行くこともあります。ただ、それは「死ぬまでに絶対に行きたい」から行ったというよりは、暇だしまあいいか、という感じです。そういう細々としたやりたいことはたくさんあるので、それほど不幸でもないし退屈でもありません。
ブックマークで「子供がいたら、無限にやりたいことは出てくるはず」というコメント（ブックマークはコメントなの？わからん。）を多数いただきましたが、全く同感です。ただ、年齢的に子供はいませんし予定もありません。少し羨ましく思います。
それから「奥さんと幸せな老後を暮らす、という項目はないの？」というコメントもいただきました。項目にはありませんでしたが、そうなるといいなとは思っています。
122個目をやるときの気持ちを知りたい。「やったるで！」という感じだったのか、「アカン終わってまう…」という気持ちだったのか
粛々と...という感じでしたね。やり終わった時は感慨深かったです。ものすごい達成感を味わいました。
じゃあ死んだら？
[B! ラジオ] 新パーソナリティはパンサー向井慧！2022年春、TBSラジオ新番組がスタート
こんな遅い時間に発表って何だろうねぇ
向井慧がパーソナリティーを務めている『＃むかいの喋り方』（愛知の地方局・CBCラジオ：火曜日22時～24時30分）で先に発表したためです。
パンサー・向井慧が大抜擢へ！ 伊集院光「らじおと」3月終了で“新番組MC”最有力に（SmartFLASH） - Yahoo!ニュース
などの記事を受けて、これに何も触れずに進めるのは不自然ということもあったのかと思いますが、TBSラジオと相談の上、22時台に『＃むかいの喋り方』で公表し、23時にプレスリリースを出すという流れができていたようです。
月木の木が隔週って更に縮めてるんだな。予算なのか別の話なのか。
木曜日に『有吉の壁』を収録していることから、隔週木曜日を休むのは『有吉の壁』に出るためです。
多分釈迦に説法ですが、「#むかいの喋り方」「#向井チャリ」をつけてツイートしているidなどを見ると、TBSラジオのヘビーリスナー兼向井慧のラジオのファンもわんさかいる（自分もその一人）ので、過小評価している人は、三村アンチをこじらせて袈裟まで憎い状態になっている方が多いのかな、と思います。
もちろん、TBSラジオのヘビーリスナーだけど向井慧のラジオを聴いていないという人は、前述の2つのタグを付けることはないので、「TBSラジオのヘビーリスナー兼向井慧のラジオのファン」が全体のどの程度かは分かりませんが。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【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から見ると単に１つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
先月、好きなバンドがメジャーデビュー後初のワンマンやったんだがこれがすげえ良かったので、他人の感想見たくてTwitterでパブサした。
そしたらボーカルのAさんがイケメン！みたいな容姿に触れる感想を公式タグ付けてツイートしてる人が多くて驚いた。
どちらかというと顔売りしてないバンドなんだが……メジャーデビューしてからしばらく顔出し控えてたし、何枚か出たアルバムはどのジャケにも写真使ってないし、PVにもメンバー出てないし……。
このままファンがAさんの容姿に触れるようなツイート連発したら、曲じゃなくてボーカルの顔で売れてんだろって言われそうで怖い。
女性ファンが多いのを理由に「アイドルバンド」って叩かれた某バンドが、それを否定するために男性ファンを過剰に優遇するようになって炎上したけど、好きなバンドにああはなってほしくない。
（アイドルバンドという単語が悪口として機能するのもどうかと思うが）
顔出し控えめなのが仮にバンドの方針だとして、所属レーベルがそれを許したってことは顔売りしなくても売れるだけの力があると判断されてるってことだろうし、顔出し控えめなのは顔売りバンドって言われるのを避けたいからなんじゃないかと思う。
それなのにワンマン参戦するような熱量あるファンがメンバーの容姿に言及するのは、それがポジティブな感想でも関係者の意図や努力を無駄にしてないだろうか。
どうしてもメンバーの容姿についてツイートしたいなら、せめて公式のエゴサや他のファンのパブサに引っかからないようにしてほしい……。
本当にライブパフォーマンスが最高だから、色んな人にこのバンドのライブに参加してほしいと強く思ってる。
だから某バンドみたいに、ファンが、自分ではどうしようもできない属性のせいでエントリーする資格すら剥奪されるような事態になってほしくない。
これ読んで気分悪くした人がいたらごめん。（特に某バンドのファンの方々……）
色んな観点から反論はいっぱいあると思うけど、少しでも「これは自分の好きなバンドの話かもしれない」と感じたなら、心の片隅において、ライブの感想をツイートする前に思い出してもらえると嬉しい。
無くしていた片方の靴下が見付かりました。
もー、
どこにあったのって思って靴下またたくさん買っちゃったんだけど、
そう言う途端に靴下見付かるのよね。
まあ良いけど、
もう探していませんから！それがなにかって
おぎやはぎさん風に接してすごしていると
そんでさー、
その時やっていたのが
これってスゴくない？って
クリリンと悟飯とブルマで宇宙船にのってナメック星に行くのってあったじゃない。
そこで行われていた
その山崎八段と都成七段の2人の様がまさにそのシーンを彷彿させるのよ！
何言ってるかよく分からないと思うけど、
最後は飛車が歩を飛び越えちゃったって反則負けしてしまったけど
もう本当にあの
山崎八段と都成七段脳内バトルがクリリンと悟飯のイメージトレーニングで脳内で戦っているかのようで、
終盤反則負けしちゃったけど、
将棋知らない人でも白熱した勝負を固唾を呑んで呑んで呑んで呑まれて呑んで！ってなもんで
戦い終わった男は
やがて静かに眠るでしょう！ってやかましーわ！ってお笑いのセオリーから言うとそう言う突っ込みになるわよね。
でも話戻すんだけど、
あの山崎八段と都成七段の2人みたいにバッチバチの探し物オーラを放っていたら
探し物もいや今迂闊に見付かったらヤバイ！って靴下は思っちゃうわよね。
いつも紹介する「ではご覧下さい！渋谷日向子のパーパットでえす！」ってのの見所よりスゴいなーって思うわ。
やっぱり
そうよ！
探し物を探す真理として心を穏やかにして
探しているけど探しているオーラを発さずに
いかに探し物を探すかって
もうこれがファイナルアンサー中のファイナルアンサーであるわよね。
それでね、
車の鍵をなくしたので、
ここは心を穏やかにして……、
三点リードも2つ使うぐらい余裕があるぐらいの余裕で探し物を探すオーラを消して探していたの、
でもお察しの通り
今すぐ出掛けなくちゃいけないところで、
そう何日も探し物オーラを消して探すってこと出来ないじゃない！
今すぐ出掛けなくちゃいけないのによ！
ふと思い出したの！
無くし物防止タグ付けてたんだ！って
ジブリのタイトルで1文字付けて下らなくする一番好きな優勝タイトルが
耳を澄ましたら
微か遠くなところで、
ピピピって鳴るのよ！
無事出掛けられたものの
修行が足りないなーって思ったわ。
私の敗北ね。
その時ばかりは
うふふじゃなくて
とほほだったわ！
うふふ。
最近朝遅めなので、
モーニングとランチが一緒になっちゃったぐらいのグッドモーニングって具合でランチ突入しちゃうので
美味しいし。
コタツみかんだけど搾って普通のノンフレーバーの炭酸でわってみました。
うーん
そう思って止まない今日この頃よ。
すいすいすいようび～
今日も頑張りましょう！
冗談抜きでこれ
Googleアカウントで広告のカスタマイズを確認することをお勧めするわ
例：不動産管理と投資信託のCMが流れたり、アセット投資のタグがついてたり
- 2019-09-29 【悲報】Googleさんに低所得者認定される (anond:20190929103124)
- 2019-10-12 Googleさんに低所者認定されたわけだが今度は (anond:20191012123445)
- 2020-02-14 【続】Googleさんがワイに設定しているペルソナ（anond:20200214193812)
- 2020-06-25 【朗報】Googleさんに低所得者認定されなくなる (anond:20200625034510) ← 平均以上になる
- 2020-06-27 【悲報】再びGoogleさんに低所得者認定される (anond:20200627085356) ← 元に戻る
