  |
はてなキーワード: テキストとは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
仕事でテキストコミュニケーションがあったんだ。相手が長文のコメントをくれたんだけど、僕にはどうも飛躍しているようにしか見えなくて、30分くらいかけて筋の通ったと思った読み方をみつけて、自分の解釈を確認するために、相手への返信に「〜ということですよね？」という質問を2つ返すと、2つとも相手の主張と異なる旨の返事が返ってきた。
今までもこの人の主張を読み取ることに苦戦したけどやっぱり今回もダメだった。
なぜか、この人の発言そのものがハイコンテキストという感じがする。会話ができる気がしない。抗不安剤を飲んでいるけど死にたいとまた思った。退職するか〜という気持ちになったが、そもそもコミュニケーションは難しいので退職に値しないという気もしてきた。それはそうとして死ねば全て解決するから死にたいんだよな。
DARK SOULS Ⅲ とりあえず１周目が終わった。
いやー最初はイライラしすぎて思わずダークソウル改善ポイント(愚痴)を増田に投稿しちゃったけど(anond:20220101191837)、なんだかんだ最後までクリアできました。ボスは全部そこまで大して強くなかったけど道中の雑魚が大変だったな。敵の攻撃何発か耐えられるくらいまで体力を上げれば良いことに気が付いてから、一気にストレスフリーになった。音量は抑えていたからBGMとかはわからないけど、グラフィックというか各建造物の規模感がとにかく圧倒的で、こういうのをやりたくてビデオゲーム（最近言わない）をやってる。
しかし、終わった今薄っすらと抱えている不満もある。それはとにかく何もかも説明が少ないこと。もちろんテキスト量はあるんだけど、全体的に気づくやつが気づけば？みたいな態度で、気づかないタイプの人間の俺は何もかも気づかなかった。例を挙げると各オンライン要素とか（火を纏ってる状態とそうでない状態があることすら気が付かなかった）、誓約関連、王の薪を玉座に置くこととか。
それによってストーリーはもちろん魔法や各システムをほとんど理解せず、利用せずにクリアすることになった。最後に火を絶やすor引き継ぐみたいなことは分かったが、そもそも薪の王って何やねんって。あと各ボスがどんな文脈で存在しているのか分からないから、ただの「巨大で剣を振り回すキャラ」みたいな記号的な要素でしか認識できなくて、戦闘は楽しいものの、その中身というかバッググラウンド的な部分を楽しめなかった。攻略サイト等の外部ツールを使わないとDARK SOULSの上辺部分しか遊べないのはいかがなものかと思った。
あとそれに関連して、プレイヤーが残してくれるメッセージについて言いたいことがある。ボスのクリア後とかの感想はソロプレイでありながら多くのプレイヤーと達成感を分かち合える感じがして楽しかった。しかしなんか世界観への理解ありきのメッセージ（太陽よ・・・みたいなやつ）はもうキモいな、と。完全に俺抜きで”知ってるやつ”同士のコミュニケーションじゃん、と思ってしまった。キモだな〜〜〜。
ということで2周目からはすべて攻略サイトをみて気が付かなかった要素を補完して行こうと思う。エルデンリングはやるし、ダクソ1リマスターはやらない予定。
これ見て思った
https://togetter.com/li/1830266
おじさん構文はキモいが何故だろうか？
絵文字が多いとかそういうのもあるけどそもそも内容がキモいというか独特な気がする
「一方的に見える」「手紙っぽい」というのがよくないんじゃないだろうか？
LINEやSNSは即レスできるコミュニケーション手段なので口頭の会話に近い
そこで即レスができない手紙っぽい内容にすると、まるで手紙を口に出して読むかのようないたたまれなさが生じるのではないかと思った
もっと具体的に特徴を考える
これらは「より誤解されないように」という気持ちが入った結果だと思う
会話では少しくらい誤解されてもすぐ訂正ができるが、手紙やブログや一方通行な文章ではそうはいかない
なので一発で誤解されないようにあの手この手で正しく伝わるようにデコる
結果気持ち悪くなる
詠嘆っていうらしい
比較すると前者はレスを求めているのに対して後者はレスが無くても会話が成立する表現だ
おじさん構文を使う人はレスが返ってくると思っていないのかもしれなくて、そのおっかなびっくり感が透けて見えるあたりが気持ち悪い
例：今日は学校だったのかな？僕は今会社が終わったところだよ！今日は寒いね、増子ちゃんはちゃんと暖かくしてる？寒い時は首元を温めるといいらしいよ！
話題が多い結果、質問数も多くなり、質問数が多くなると圧が強くなるから結果的に「かな？」が増える
・話題が当たり障りなさすぎる
例1：今日は学校だったのかな？僕は今会社が終わったところだよ！今日は寒いね、増子ちゃんはちゃんと暖かくしてる？寒い時は首元を温めるといいらしいよ！
例2：数学のテストどうだった？僕のプレゼンは上手く行ったよ！雪が降ってるね、増子ちゃんいつも首元が寒そうだから心配だよ！
例2の方がマシに見えない？
例2の方が親密度高いんだろうな感がある（ストーカーかもしれないけど）
当たり障りないテキストは無理やり話題を作ってるように見えてより痛々しくみえる
例1：今日は重要なプレゼンがあったけど上手く行ったよ！早く帰ってパーッと飲みたい気分だなあ！雪が降ってるね、すっげー寒い！
例2：今日は数学のテストがあったんだってね？今日は帰って打ち上げかな？雪が降ってるね、寒くないか心配だよ
例2の方がキモく見えない？
ただし自分のことだけ話すのもコミュニケーションできないやつだから
バランス難しいけど
・謎報告
単に話題がないのが原因
せめてユーモがあればいいんだけど
テキストが多くなり、相手への言及が多くなると自ずとハラスメントが多くなる
まとめ
↓
謎報告
→かな？が増える、セクハラが増える
まあこんなところでしょ
万年セルラン圏外のどマイナーなソシャゲを最近始めたのだが、意外とポチポチやるのが楽しい。
ドラマチックなメインシナリオとかリッチな3Dとか動く2Dとか一切なくて（カードイラストがそのまま立ち絵になる仕様）、
ゲーム部分はほぼポチポチしながら見守るだけな虚無、キャラボイスも戦闘やホーム台詞の一部にちょろっと入っているぐらいのあまりのやる気の無さで、
ついでにどうもリリースしばらく経ってから運営がやらかして炎上したようで、そこからずっと低空飛行を続けているようなゲームだ。
それでも大したテキストがないからこその描写のあっさりさや、ポチポチで済む操作の手軽さが妙にしっくり来てしまい、だらだら続けている。
セルラン上位に来るようながっつり時間を喰うゲームも並行してやっているので、それらに疲れた時に丁度いい立ち位置なのだ。
季節イベントで提供されるキャラの会話もひたすら無難で他愛のないものなのだが、だからこそ変に感情を揺さぶられることもなく、キャラクターに素直に好感を抱くことができる。ゲーム外展開もほぼゼロなので、ひたすらゲーム内のコンテンツだけに集中できるのも良い。
問題は、そういうゲーム故にいつサ終してもおかしくないことである。
サ終のお知らせがいつ来てもおかしくないゲームと認識して始めたのだが、愛着が湧くと意外に終わってほしくないものだと思えてしまうから不思議だ（微々たる額だが好みのキャラのピックアップが来た際には若干の課金もしてしまった）。
「そういうのわよくない」
「これからも関(かかわ)える」
「なんのお依頼？」
みたいなちょっと間違った日本語を使う子が一定数いる。てをにはと敬語は特に多い印象。
まあ子どもなんて勉強中なので言葉なんて間違ってナンボだと思ってるんだけど、そういうのが正されるきっかけってなんだろうな？とぼんやり思いました。
自分は人と話すの苦手なのと、辞書を読み物として見るタイプだったのでテキストから吸収してなおすことが多くて、でも本を読まない人だって言葉ってなんとなく直っていくでしょ？(なおらない人もいるけど)
人によって違うんだろうけど、てをにはなどの正しい日本語っていつ取得されるんだろうな〜ってちょっと疑問に思ったので言語学の本でも読んでみようかなと思うんだけど素人が読んでも難しすぎない本などありませんでしょうか。
凄いどこかで聞いたことあるのでなんかで使われてるんだろうけど、どこで聞いたのか憶えていない
UFOキャッチャーでソニックの曲とか、あーむ動かしてる間は無敵の曲流れたりとか多分そういうスピンオフのお遊びなんだろうけど、
ゲームなのかはたまた無関係の別の映像作品とかなのか、ググってもそう言う情報が全然出てこない
おれはナイツとか全然見たことも遊んだこともないから、もともとナイツでこの曲を聞いたのではない
てか曲っていうかジングルなんだけどな。ジングルでググっても、お笑いのナイツのラジオジングルの情報しか出てこないし
まあこういうテキスト化できない情報の索引化ってまだまだGAFAMでも無理って感じだなぁ。もう少しなのかな
そもそもそう言う情報がこの世に文字情報として存在していないということなのかもしれんけど、文字になってない情報もはやく整理して俺の脳に届けてほしい感じ
2022年(令和4年)1月1日より施行される改正電子帳簿保存法についてレクチャーを受けたので忘れないうちにメモしておく。
この日記を書いた増田本人は税理士ではないので間に受けないように。
以上
