「レイヤ」を含む日記 RSS

はてなキーワード: レイヤとは

2022-03-03

クラウドに詳しい人に質問なんだが

当方Webアプリエンジニアで、転職先はアプリに加えてある程度インフラも触らないといけない会社なんだけど、

自主的勉強として

Terraform + Kubernetes +grpc(grpc-web) + nuxt.js簡単Webサービス作って

コンテナ環境AWSデプロイ、みたいなのって入社までの1ヶ月くらいで完了できる内容だと思う?

経験的にアプリレイヤはわかるけど↑みたいなコンテナ構築みたいなのはあんまりやったことない感じ

2022-02-21

1分で傷口縫え

「1分で虫歯治療しろ」と同じレイヤだと思うとなんとなく納得感はあるな

痛いもんな

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-23

anond:20220119215234

気持ちわからんじゃないけれど、その理路で周囲を動かそうとするのはあまりにも無理筋だ。

増田は「自身に置き換えて考えてほしい」っていうけれど、もうこれが筋悪の最たるもので、その理路を使った場合「え?別に私は怖くないよ」でカウンターされてしまう。世の中には色んな人がいるわけで、そこを蹴飛ばして「私が怖いのならみんなも怖いはずだ」とか「私が嫌なものはみんなが嫌なはずだ」というのは、期待はしてもいいけれどその期待に答える義務他者社会にはない。

また別の理路として「私が怖かったのは真実なのだから、その私の気持ち尊重して譲歩して欲しい」というものもあるけれど、こちらはさらに筋が悪い。なぜなら地球には70億くらい人間いるわけで、自分お気持ち他者に譲歩を1つ要求するのならば、当然のように自分はその70億倍くらい譲歩しなければならないから。これはもう現実的には不可能だ。現実的不可能なのは自明なのにも関わらず「私の気持ち尊重して譲歩して欲しい」っていうのは他者希望を踏みにじる宣言に近い。

「私が怖い」ってのは結局お気持ちなわけで、そういう意味では好きとか嫌いとか腹立つとか嬉しいと同じレイヤのものだよね。「私が怖い、怖かった」ってのは全く否定しないけれど、それを根拠として他人に、ひいては社会に譲歩を求めるのは上記のように筋が悪いのだ。

念のために言うとこの記事上記で書いたものは、増田の論のすすめかたがまずいという話だ。増田が「私は怖かった嫌だった」と感じたのは否定しない。真実なのだろうとも思う。また住宅街ナンパをするというのも個人的には感心しないしそんなことはしない。しかし、それらと、お気持ちベース社会に譲歩を求める論法/行動の是非は全くの別のことだ。

そして「お気持ちベース社会に譲歩を求める論法/行動」は「住宅街ナンパする」よりも厭うひとがいるってことも知っておいて欲しい。

2022-01-09

機械学習エンジニアに転身するぞー!

技術書3万円分を大人買いしちゃったし、もう後戻りはできない。

大学とき線形代数は周りが単位落としまくる中、優だったし素養はあるはず。

今まではOSネットワーク等の基盤技術お金時間投資してきた。

そしてそれは正解で基礎をしっかり理解することで様々な技術加速度的に理解することが出来た。

これからは上のレイヤ習得をするフェーズ

anond:20220109001953

増田と同年代ITエンジニアだけど、3倍は流石にすごいけど基本的新卒給与一律で低めに設定されてることが多いから元からスキルある人はガンガン上がる。

自分新卒から満3年で1.5倍にはなったので大きめの所で管理職レイヤまで上がったり何回か転職挟んでればありえない数字ではなさそう。

2022-01-08

anond:20220108222125

どのレベルソフトウェアエンジニアを目指したいか、あるいはどの業界ソフトウェアエンジニアを目指したいかにもよる。

組み込み系とかのハードウェアに近い業界とかOSまわりまで触る業種なら低レイヤ知識必須だけど、普通アプリケーション開発レベルだともちろん教養としては知っておくに越したことはないけど必須ではない。

とりあえずで言うとまともに勉強した情報学学士レベル基本情報応用情報レベルなので手堅く抑えるならその辺かな。

2021-10-13

ソート計算量とかそんなの知らねえよ

10ソフトウェアエンジニアやってるけどアルゴリズムなんかどこで使うんだよ

必要になったら勉強するつもりだけど必要になったことなんて一回もないぜ

一流企業エンジニア普通に使うのか?

一流企業ならいいけど弱小企業が真似して面接で聞いてこないでほしい

そんなもの一度たりとも気にしたことないんだから

そもそも大抵のエンジニアは高レイヤライブラリとかツールを組み合わせる配管工みたいな仕事しかしなくね?

普段からGitHubとかAWS落ちたら帰るとか言って他社に依存しないと生きていけない存在なんだぜ

誰かが作ったフレームワークがないと何もできないんだぜ

アルゴリズムもわからないし、数学もわかりません

からなくても少なくとも10年は生きてこれました

というか引退するまで縁がないような気もする

お前たちもそうなんだろ?

2021-10-10

ニシキヘビは邪魔。家から出るな。

前々から思っていたけど、ここ最近前にも増してニシキヘビという生き物が邪魔すぎてストレスが溜まる。

俺が言う「邪魔」というのはなにも『爬虫類ペットブームがぁ~』とか『生物、やっぱり外見より内面のほうが大事だよね~※』という高いレイヤの話ではない。

しろレイヤ1=物理層文字通りの意味で「邪魔」なのである

日々感じる事を挙げるとこんな感じ。

(歩きかたが邪魔

うねうね歩く。こわいので近づきづらい。

近づこうとすると、何故か威嚇されて噛まれそうになる。

そもそも視力はよくない。


自転車邪魔

まあ言いたいことは上と同じ。

道交法学べ。器用に漕ぐな。足が無いならもっと電動に頼れ。


スーパー邪魔

肉選ぶのにどんだけ時間使ってるんだよ。どれ選んでも温度低すぎて食用認識できないだろ。お前がどかないと俺が買えないんだよ。

あとレジ。金払うのになんでそんなに時間かかるんだよ。ポイントカード出すなら予め用意してろ。脱皮殻が入ってるか穴が空くほど財布の中見渡してんじゃねーよ。

電車邪魔

いわゆる「無精卵問題」ね。まあこれに関しては正直言って寛大な心を持っているつもりではあるんだけど、やはりせっかく保温したのに生まれないとか勘弁だし。むしろ同じ場所居合わせしまった自分の不運を呪う感じすな。

人間だってこれに当てはまる場合は当然ある。

しかしニシキヘビの方が圧倒的に多いのだ。少なくとも俺はそう感じる。

別にニシキヘビがキライなのでは無い。むしろ大好きだ。

しか社会生活においてはどうしようもなく邪魔存在しかない。

日常生活において器量の良いニシキヘビが増える事を切に望む。

anond:20150815182832

2021-09-10

anond:20210910101447

「なぜ帰らないのか」に対して「帰ろうが帰るまいが、虐待していいことにはならない、罪は消えない」というのは、一段上のレベル反論なんだが、レイヤが上がると理解できなくなってしまうんだろう

「なぜ帰らないのか」に言い返せないから話を逸してるとしか思えないという

2021-08-11

anond:20210811101559

いろんな分野とレイヤの人がNWを気にするから、これはこれでいいのでは?

このブログ書いた方は、数理最適化機械学習やってるそうなので、その環境インフラ構築での観点なんでしょ。

NWエンジニアCCNPネスぺ、セキュリティスペシャリスト持ち)だけど、エンタープライズNWやるのと、NW機器メーカーでのNWエンジニア観点違うぐらいだからね。

SIだと、基本情報CCNAやるぐらいで十分だし

NWアーキ設計構築とかなら、マスタリングTCP/IPを全巻キャッチアップしたり、ネス資格ベンダ中位上位資格あった方がよかったりするけど。

2021-07-09

anond:20210709214950

ヒエッ、本職きたよ。ヌボボ

ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。

そこんとこ詳しく。メタップスとか?

東大卒だったら、言葉を正しく使え!

Waf なんて書くな! WAF とかけ!

Pub/Sub とか

うっせーな。クラウドベンダー独自 API なんか使いたくねーんだよ。オラクルじゃあるまいし。

DCL、DMLDDLといった用語を知っていることをひけらかしたかったのかもしれない

まぁ、それは認める。でもさ、select や create とかのDML/DDLCRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータアクセスできなくなるかもよ?

現場に放り込まれても10年ぐらいかかる。というより、フロントからバックからレイヤからモバイルまでやることはもはや現実的ではない。

そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前までは Flash と DoJa のアプリを作ることがフロントエンド開発者でしたよ?一方データベースや OS の方は、ここ三十年ぐらい UnixRDB鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかで C言語開発者バリバリっすよ。例えば、クラウドフレアなんか CDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤ根本技術改善であって、私はそこにプロフェッショナル性を見出しますがね。

C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語文字を羅列するのは厨ニ病すぎます

わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えている C/C++サーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンス必要とするなら Rust、または GC があるけど Go言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか?いい加減にしろ

片手間でできません。インフラエンジニアに触らせます

そうだね~。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの?時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニア採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。

NextSSRまで踏み込む結構

誰が NextSSR なんてするか!あれは SEO必要場合に限る。そもそも SSR なんて危険からまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラインデックスされるページで SPA をやろうとするやつはセンスないで。

MyISAMInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。

すいませんでした。本当にすいません。

Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな?どういう利用シーンかというと膨大なログ収集等で使うのだが(ただのNoSQLではない)、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます

ん? AWS SQS だとパフォーマンス問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん?ログ収集は GKE みたいに ログに出したら Fluentd収集してくれる時代になんでグチグチ言われないといけないの?

Redisちゃんと使えてる?pub/subとか分かってないと思う(普通に理解する必要あんまない)

ハア?インメモリデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。

code deploy

これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんて Kubernetes で展開したら運用までしないといけないじゃん。メンドクサ。

アメリカ事情は知らないはずなので知らないことは書かないようにしましょう。

いや、J1ビザをとってアメリカ留学したことあるよ。あと、「世界もっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん馬鹿にしてるのか?

 なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上

SAPアマデウスITとか強いじゃん。うそつき

https://anond.hatelabo.jp/20210708205945

=====

東大卒ヨーロッパエンジニアやっている人から解説しよう。(ちなみに医学部防衛医大に補欠合格していた)

エンジニアになるより医者やっていたほうが(国内で頑張る分には)絶対いいと思う

ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。

厨ニが溢れているので、しっかり解説してあげます

おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。

エンジニア厨ニ病マウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、

表面的な知識を羅列しているところがあったので突っ込んでいく。

~~誰にやらせてもデータベースにクソなDCLを飛ばせないから。逆に、データベースを触れることができるプログラマーリスク責任が大きいから、給料が高いのだよ

ー>そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて

できる領域が狭いので給与が低い、またおそらくDCL、DMLDDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。

~~君はソフトウェアエンジニアになりたいのだろ?世の中は分業で成り立っているのだから、全部やろうとするやつはアホだよ

=>全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。

現場に放り込まれても10年ぐらいかかる。というより、フロントからバックからレイヤからモバイルまでやることはもはや現実的ではない。

~~おそらく QUIC か MQTT あたりだろ?逆にいえば、それが実装できたら他社と差のつけられるプロダクトだったはずだ。つまり会社利益の源泉であった部分をみすみす実装できないようでは、そこらへんの専門卒以下だぞ。

=>QUICとかマイナープロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語文字を羅列するのは厨ニ病すぎます

~~プログラマーに徹するつもりだろうが、ツヨツヨエンジニアデプロイした経験から逆算してコード設計・開発をやるのだぞ。そうなると、CDN, DNS, WAF, S3, ログの出し方、メトリックス、異常検知、アラートを把握する必要があるのだぞ。そういうのを知るためには、ポートフォリオAWS GCP Azure といったクラウド経験を書くべきだと思うのだが、なぜしない?

=>自分cloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう

本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」

~~たしかおかしいよな。Kubernetes や Terraform を弄って、CIGitHub Actions、CD には AWS CodeDeploy を使って、ブログは Jekyll で静的サイトジェネレータを使いつつ、自前のサービスを立ち上げるために Rails, Next, React, PostgreSQL, Redis, Kafka, Elasticsearch, S3 の勉強をしつつ、スマホ環境のために KotlinSwift を触れているなんて変だよな。そういえば、Docker が来るまでは Vagrant環境をつくっていたのも忘れてたよ。あと Rust を今年に学ぶ言語にするなんて、受験生にあるまじき行為だよな。うん。

=>こんなにあれこれ、やっている時間はないでしょう。趣味サイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな?どういう利用シーンかというと膨大なログ収集等で使うのだが(ただのNoSQLではない)、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます?ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisちゃんと使えてる?pub/subとか分かってないと思う(普通に理解する必要あんまない)

それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味マウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。

ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる

~~ストレージエンジンが切り替わるときカオスな目にあったけどさ

=>MyISAMInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。

~~TypeScriptNext と React を書く。もちろん JavaScript は ES2020 あたりまでは説明可能

=>ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的数字にしてたらばれなかったのにね。

NextSSRまで踏み込む結構フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな?

=====

~~アメリカでも「テック系はハードから避ける」

ー>アメリカ事情は知らないはずなので知らないことは書かないようにしましょう。

ー>ヨーロッパでは白人様はHRとかマーケやってます移民にたよってますロシアウクライナインドパキスタンなど

  なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上

※ちなみに防衛医大の補欠合格東大に入る人なら大体受かると思う

2021-06-03

[]2021年5月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

400あとで/2455users ハーバード大プログラミング講座を日本語化 無料で学べる「CS50.jp」公開 - ITmedia NEWS

340あとで/2437users 米ハーバード大学のプログラミング授業 日本語訳無償公開 誰でも聴講可 | ツギノジダイ

335あとで/2327users 東大無料公開している超良質なPython/Data Science/Cloud教材まとめ (*随時更新) - Digital, digital and digital

292あとで/1762users 新人の方によく展開している有益情報Qiita | kazuo_reve

244あとで/1441users 知っておきたかったLinuxサーバ設計、構築、運用知識まとめ - hiroportation

228あとで/1463users Google提供する無料AI講座受けてみた 1時間機械学習の基礎がわかる | Ledge.ai

227あとで/1355users 無料で読める、東大京大の「Python教科書電子書籍AI機械学習無料電子書籍 - @IT

220あとで/1750users 研究の話 | 医療法人豊隆会 ちくさ病院

208あとで/1145users ブラウザレンダリングの仕組み | Aki Kahamura | Zenn

191あとで/1151users すべての働く人におくるストレスマネジメントの基本 | knowledge / baigie

188あとで/1023users 【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造暗号化範囲, Encrypted Alert, ヘッダやレイヤについて~ | SE道標

187あとで/989users 認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本 | ほげさん | Zenn

180あとで/1161users すべての開発者へ。すごいGitHubリポジトリ10選 – Qiita | baby-degu

179あとで/2080users 山本ゆり(syunkon レンジは600W) on Twitter: "今まで紹介したレンジハンバーグ個人的に優勝。この手間でこの味になるかと驚くほど簡単で、本当に美味しい(包丁不要。ボウルで捏ねないかヌルヌルの洗い物もナシ) 卵の有無、練り具合、つなぎの量など何度も試作しました。柔らかくジュ… https://t.co/BXntIVz5NQ"

169あとで/1342users 『スタンフォード式 最高の睡眠』を読んで、睡眠について知らないことがまだまだあったのかと感動しました - おたま日記

162あとで/1388users CS50 for Japanese(ハーバード大学 CS50 の日本語版翻訳プロジェクト): コンピュータサイエンスの入門

161あとで/1375users カレースパイス調合の基本からスパイスカレーや肉のスパイス漬けを極める(小林銅蟲/イナダシュンスケ) - ソレドコ

154あとで/743users 世界一わかりみの深いOAuth入門 | Noriyuki TAKEI | Speaker Deck

153あとで/1529users TOKIO国分太一さん「センスのいい、もらって嬉しい手土産知りませんか?」見ているだけで楽しい推し手土産」が集まる - Togetter

149あとで/980users 機械学習研究者を目指す人へ | Hiroshi Takahashi

149あとで/1629users お前らの登録してるyoutubeチャンネル教えろよ | anond.hatelabo.jp

144あとで/1277users 【更新創作する人は必読!書評家が下読みで感じた「応募小説問題点」がめちゃくちゃタメになる - Togetter

144あとで/1225users ナビつき! つくってわかる はじめてゲームプログラミング | Nintendo Switch | 任天堂

144あとで/1668users 政府向けシステムの話をするときの前提知識 | anond.hatelabo.jp

135あとで/656users フロントエンドパフォーマンスチューニング俯瞰する - 30歳からプログラミング

133あとで/998users 社員用に作った文書校正ツール一般公開した - gecko655のブログ

133あとで/2245users ため池に落ちると、なぜ命を落とすのか(斎藤秀俊) - 個人 - Yahoo!ニュース

131あとで/1170users 真っ先に変えるべきは日本人の「思考」 オードリータンが貫く「透明性」と「多様性」:「前例がない」をやらない理由に(1/5 ページ) - ITmedia ビジネスオンライン

126あとで/796users DOM Events | Alex Reardon

124あとで/912users 「結果が出ない焦り」と向き合う方法柴田史郎|note

124あとで/598users MySQLインデックスと私 - Speaker Deck | yoku0825

ナントカ大学の教材、みたいなエントリに[あとで読む]タグが集まった

スタンフォード式 最高の睡眠』は読んでしまった

2021-05-24

anond:20210524124123

おれは機械学習物理レイヤとの結合が爆発的イノベーションになると予想している。

たとえばカラアゲだ。

鶏肉サイズ調味料やら油の温度やら数億パターンの組み合わせで実際にカラアゲ化して人々の美味いぞ値をフィードバックして研ぎ澄ましてゆくんだ。

いずれカラアゲの完成形が人工知能で示されることになる。

2021-05-04

anond:20210504112556

「こうあるべき」「こうみえる」「そんなのは差別だ」とかい差別どうのこうのの人間社会的レイヤでなく、

人間意思ではどうにもならない現状の事実がこうなってるよね」という現状認識スタンスですね。科学なので。

そこのニュアンスが違っているかも知れません。

例えば「空が青いのは嫌いだ」と言っても仕方ないじゃないですか。空を緑色にはできないですよね。だから空は青いもの前提で人生をやっていく他ないでしょう。

置かれた場所で咲きなさい思想かも知れない

2021-04-07

ジャガイモ海水で洗えない年老いエンジニア

ある島で一匹の若い猿がジャガイモ海水で洗って食べ出すと他の猿たちも同じように洗って食べ始める

しかし年老いた猿はそれを遠目に今まで通り土のついたジャガイモを食べるだけであった

どこかで聞いた話だと思うけど最近おっさんエンジニアはこの猿だと思う

いつまでもオンプレだけでクラウドは使えないし覚える気もない

SPAリッチUIにできるのにやろうとすらしない

挙げ句の果てに使ってもないのに無意味にそれを批判する

それは土のついたジャガイモを食べる猿のようだ

基本が大事だと低レイヤ勉強しろだの数学をやれだの言う

おれから言わせればそれは土のついたジャガイモ

海水で洗えばもっと衛生的に美味しいものが食べられる

人間も猿もたいして変わらないだろうからおっさんエンジニアも年老いた猿のように

今までと同じことを同じやり方でやり続けるんだろうな

2021-04-04

anond:20210403231131

ちょっと違うかもしれないけど何だろな

選挙に行こう勢とか東北震災の時の俺たちが節電たか停電を免れたんだみたいな

あいうのって結局そんなんより上のレイヤで話が通ってて社会がそう動いたからそうなったみたいな

結局の所強い力で取りまとめる誰かがいなきゃ社会に影響を及ぼすこと出来ないみたいな

2021-03-13

プログラミングができるようになるタイプとそうでないタイプの違い

コードレビューをずっとやっていると、伸びるタイプかそうでないかが提出してくるコードで分かるようになってくる。

ざっくり

を見る。

コードフォーマット

コードフォーマットで頻繁に同じような指摘を受けるタイプは明らかにエディタコンソールといったツールが使えていない。

人間作業の精度を上げるのではなく、100%の精度で作業してくれるツールやらせれば良い。

些末なミスツールが拾ってくれる方が高速で、正確で、なにより心理的負荷が低い。

リファクタリング機能コードフィックスの提案を有するツールなら学習のペースも上がる。

コードフォーマットで消耗しているようでは、本来重要なはずの作業学習時間が取れないのは自明だろう。

命名

命名を軽視する者は、作業対象となっているコードがどんな責務を負うか、自身の書いたコードの内容すらも完全には理解していない傾向が強い。

(ここではあえてクラスメソッドという表現を避けるが)扱うコードが何をするもので、何に依存し、どこから呼ばれるか。

どういったエラーが出うるかエラーは今のレイヤ対処しておくべきものか、他のレイヤの責務か。

命名にはそういった情報が反映される。英語が苦手?プログラミングで使う語彙なんて極めて少ない。高校生ぐらいのレベル英語ができれば十分だろう。

しろ、先人が少ない語彙でどうやって事物表現してきたかを学ぶべきである

求められるのは正確さと一貫性であり、誰もボキャブラリーなんぞ求めていない。少ない語彙で正確に表現できるぐらいに対象コードを整理しろ

命名がうまくいかないのはお前の英語力が低いからではない。コーディング力か、コードが扱うドメインへの理解が弱いからだ。

というようなことを、心理的安全を慮り10倍、100倍に希釈して伝える仕事をやっている。

2021-01-08

anond:20210108144218

将来にわたって動画メディアが1レイヤしかないのが続けばそうかもしれないけど

1レイヤぶんで8K頭打ちがもし来たとして、例えば複数画面ぶんの配信行われるようになったり、

付加情報が増えていく可能性は十分あるだろ

あと結局通信帯域は使うだけ分散していくから

家電などがネットワーク化高機能化していけばその分取られる

2020-12-31

anond:20201231173444

Cが現役で活躍してるのはその辺の低レイヤなんだろうけど、それと

C言語さえやっとけば技術トレンドなんか追わなくても楽して稼げる

このくだりが紐づかないんだよね。

自分が書くのがCだけだったとしても、他にどんな機器があって、どんな技術で動いてるとかはある程度把握しておく必要があるでしょ?

それってCだけでは苦しくない?

2020-12-20

anond:20201220092955

あれって「環境問題個人個人意識に」っていう話でしょ。だったら単純に人間の頭数の問題じゃん。そこに金持ち貧乏人にそこまで大きな差はないでしょ。

そういう問題に対して、トラウデンの発言好意的解釈して、店員が「環境問題にお配慮しておりますわよジョルノジョバーナ」とか言うレイヤの話なんだ!って分かってもほとんど意味ないよね。

だって95%の給与所得者は年収1000万以下で、個人事業主でも99%は3000万以下なんだから。トラウデンが行くようなお店に行くような人は1%よりもっと少ない訳。

それなのにそのレイヤ人間の肌感覚で「個人個人環境意識を高めよう」って無意味だよね。アホなのかな?

99%の人が何を意識してどういう生活かも分かってない中で発言しても「世間知らずのお排泄物お嬢様がまーたなんか言ってますわよブローノブチャラティ」ってなるだけなんすわ。

2020-12-17

anond:20201217154722

あれは番号通知と同じようなレイヤなんよ

「どの人からいつ(あるいは、まもなく)電話がかかってくるか」ということを事前に知りたいというニーズは大昔からあった

電話を取る前に、電話が鳴る前に、誰からかかってくるかを知りたいというニーズ

技術ニーズに追いついたと言っていい

ニーズの実現の半分くらい手動なのが面倒煩雑うんこなのは認める

自動になればいいんだけどなー

2020-12-11

ピカチュウ脱税してません

で、たとえば昨今のあれで、「ピカチュウ脱税したの?」「LINEピカチュウって脱税したの?とか回ってきて俺の股間ボルテッカー」みたいな話になったとき

面白がって、あるいは乗っかって ”ピカチュウ 脱税” で検索してURL出して「結構あるなwwww」とか書き込むのはよくないということでもある

ピカチュウ架空キャラクター法人格ですらありません」「ピカチュウ脱税してません」ときちんと大人らしく指摘するべきという話である

正しいけどつまんねーな

でも女子高生の会話から取り付け騒ぎとかとレイヤは一緒なのか、正しく振舞うべきだな

正しいけどつまんねーな……


anond:20201211005618

ログイン ユーザー登録
ようこそ ゲスト さん