はてなキーワード: レイヤとは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
気持ちはわからんじゃないけれど、その理路で周囲を動かそうとするのはあまりにも無理筋だ。
増田は「自身に置き換えて考えてほしい」っていうけれど、もうこれが筋悪の最たるもので、その理路を使った場合「え?別に私は怖くないよ」でカウンターされてしまう。世の中には色んな人がいるわけで、そこを蹴飛ばして「私が怖いのならみんなも怖いはずだ」とか「私が嫌なものはみんなが嫌なはずだ」というのは、期待はしてもいいけれどその期待に答える義務が他者や社会にはない。
また別の理路として「私が怖かったのは真実なのだから、その私の気持ちを尊重して譲歩して欲しい」というものもあるけれど、こちらはさらに筋が悪い。なぜなら地球には70億くらい人間いるわけで、自分のお気持ちで他者に譲歩を1つ要求するのならば、当然のように自分はその70億倍くらい譲歩しなければならないから。これはもう現実的には不可能だ。現実的に不可能なのは自明なのにも関わらず「私の気持ちを尊重して譲歩して欲しい」っていうのは他者の希望を踏みにじる宣言に近い。
「私が怖い」ってのは結局お気持ちなわけで、そういう意味では好きとか嫌いとか腹立つとか嬉しいと同じレイヤのものだよね。「私が怖い、怖かった」ってのは全く否定しないけれど、それを根拠として他人に、ひいては社会に譲歩を求めるのは上記のように筋が悪いのだ。
念のために言うとこの記事の上記で書いたものは、増田の論のすすめかたがまずいという話だ。増田が「私は怖かった嫌だった」と感じたのは否定しない。真実なのだろうとも思う。また住宅街でナンパをするというのも個人的には感心しないしそんなことはしない。しかし、それらと、お気持ちベースで社会に譲歩を求める論法/行動の是非は全くの別のことだ。
そして「お気持ちベースで社会に譲歩を求める論法/行動」は「住宅街でナンパする」よりも厭うひとがいるってことも知っておいて欲しい。
前々から思っていたけど、ここ最近前にも増してニシキヘビという生き物が邪魔すぎてストレスが溜まる。
俺が言う「邪魔」というのはなにも『爬虫類のペットブームがぁ~』とか『生物、やっぱり外見より内面のほうが大事だよね~※』という高いレイヤの話ではない。
むしろレイヤ1=物理層。文字通りの意味で「邪魔」なのである。
日々感じる事を挙げるとこんな感じ。
(歩きかたが邪魔)
うねうね歩く。こわいので近づきづらい。
近づこうとすると、何故か威嚇されて噛まれそうになる。
まあ言いたいことは上と同じ。
肉選ぶのにどんだけ時間使ってるんだよ。どれ選んでも温度低すぎて食用と認識できないだろ。お前がどかないと俺が買えないんだよ。
あとレジ。金払うのになんでそんなに時間かかるんだよ。ポイントカード出すなら予め用意してろ。脱皮殻が入ってるか穴が空くほど財布の中見渡してんじゃねーよ。
いわゆる「無精卵問題」ね。まあこれに関しては正直言って寛大な心を持っているつもりではあるんだけど、やはりせっかく保温したのに生まれないとか勘弁だし。むしろ同じ場所に居合わせてしまった自分の不運を呪う感じすな。
しかしニシキヘビの方が圧倒的に多いのだ。少なくとも俺はそう感じる。
しかし社会生活においてはどうしようもなく邪魔な存在でしかない。
日常生活において器量の良いニシキヘビが増える事を切に望む。
そこんとこ詳しく。メタップスとか?
Waf なんて書くな! WAF とかけ!
うっせーな。クラウドベンダーの独自 API なんか使いたくねーんだよ。オラクルじゃあるまいし。
まぁ、それは認める。でもさ、select や create とかのDML/DDL は CRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータにアクセスできなくなるかもよ?
そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前までは Flash と DoJa のアプリを作ることがフロントエンド開発者でしたよ?一方データベースや OS の方は、ここ三十年ぐらい Unix と RDB が鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかで C言語開発者はバリバリっすよ。例えば、クラウドフレアなんか CDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤの根本技術の改善であって、私はそこにプロフェッショナル性を見出しますがね。
わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えている C/C++ でサーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンスを必要とするなら Rust、または GC があるけど Go言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか?いい加減にしろ。
そうだね~。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態の我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの?時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニアを採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。
誰が Next で SSR なんてするか!あれは SEO が必要な場合に限る。そもそも SSR なんて危険だからまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザとクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラにインデックスされるページで SPA をやろうとするやつはセンスないで。
すいませんでした。本当にすいません。
ん? AWS SQS だとパフォーマンスに問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん?ログ収集は GKE みたいに ログに出したら Fluentd で収集してくれる時代になんでグチグチ言われないといけないの?
ハア?インメモリのデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。
これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんて Kubernetes で展開したら運用までしないといけないじゃん。メンドクサ。
いや、J1ビザをとってアメリカに留学したことあるよ。あと、「世界でもっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん。馬鹿にしてるのか?
=====
東大卒のヨーロッパでエンジニアやっている人から解説しよう。(ちなみに医学部は防衛医大に補欠合格していた)
エンジニアになるより医者やっていたほうが(国内で頑張る分には)絶対いいと思う
ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。
おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。
エンジニアも厨ニ病でマウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、
表面的な知識を羅列しているところがあったので突っ込んでいく。
ー>そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて
できる領域が狭いので給与が低い、またおそらくDCL、DML、DDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。
=>全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。
現場に放り込まれても10年ぐらいかかる。というより、フロントからバックから低レイヤから、モバイルまでやることはもはや現実的ではない。
=>QUICとかマイナーなプロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語4文字を羅列するのは厨ニ病すぎます。
=>自分はcloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう
本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」
=>こんなにあれこれ、やっている時間はないでしょう。趣味のサイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな?どういう利用シーンかというと膨大なログの収集等で使うのだが(ただのNoSQLではない)、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます?ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisもちゃんと使えてる?pub/subとか分かってないと思う(普通に理解する必要があんまない)
それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味にマウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。
ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる
=>MyISAM をInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。
=>ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的な数字にしてたらばれなかったのにね。
Next でSSRまで踏み込むと結構、フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな?
=====
ー>アメリカの事情は知らないはずなので知らないことは書かないようにしましょう。
ー>ヨーロッパでは白人様はHRとかマーケやってます。移民にたよってます。ロシア、ウクライナ、インド、パキスタンなど
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
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
コードレビューをずっとやっていると、伸びるタイプかそうでないかが提出してくるコードで分かるようになってくる。
ざっくり
を見る。
コードフォーマットで頻繁に同じような指摘を受けるタイプは明らかにエディタやコンソールといったツールが使えていない。
人間が作業の精度を上げるのではなく、100%の精度で作業してくれるツールにやらせれば良い。
些末なミスはツールが拾ってくれる方が高速で、正確で、なにより心理的負荷が低い。
リファクタリング機能やコードフィックスの提案を有するツールなら学習のペースも上がる。
コードフォーマットで消耗しているようでは、本来重要なはずの作業や学習に時間が取れないのは自明だろう。
命名を軽視する者は、作業の対象となっているコードがどんな責務を負うか、自身の書いたコードの内容すらも完全には理解していない傾向が強い。
(ここではあえてクラスやメソッドという表現を避けるが)扱うコードが何をするもので、何に依存し、どこから呼ばれるか。
どういったエラーが出うるか、エラーは今のレイヤで対処しておくべきものか、他のレイヤの責務か。
命名にはそういった情報が反映される。英語が苦手?プログラミングで使う語彙なんて極めて少ない。高校生ぐらいのレベルの英語ができれば十分だろう。
むしろ、先人が少ない語彙でどうやって事物を表現してきたかを学ぶべきである。
求められるのは正確さと一貫性であり、誰もボキャブラリーなんぞ求めていない。少ない語彙で正確に表現できるぐらいに対象のコードを整理しろ。
あれって「環境問題を個人個人の意識に」っていう話でしょ。だったら単純に人間の頭数の問題じゃん。そこに金持ちと貧乏人にそこまで大きな差はないでしょ。
そういう問題に対して、トラウデンの発言を好意的に解釈して、店員が「環境問題にお配慮しておりますわよジョルノジョバーナ」とか言うレイヤの話なんだ!って分かってもほとんど意味ないよね。
だって95%の給与所得者は年収1000万以下で、個人事業主でも99%は3000万以下なんだから。トラウデンが行くようなお店に行くような人は1%よりもっと少ない訳。
それなのにそのレイヤの人間の肌感覚で「個人個人の環境意識を高めよう」って無意味だよね。アホなのかな?
99%の人が何を意識してどういう生活かも分かってない中で発言しても「世間知らずのお排泄物お嬢様がまーたなんか言ってますわよブローノブチャラティ」ってなるだけなんすわ。