  |
はてなキーワード: コンポーネントとは
こんなの
{2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
および APPID
{15C20B67-12E7-4BB6-92BB-7AFF07997402}
の COM サーバー アプリケーションに対するローカルアクティブ化のアクセス許可を、アプリケーション コンテナー 利用不可 SID (利用不可) で実行中のアドレス LocalHost (LRPC 使用) の
ユーザー Masuda\YourPC SID (S-*--**-******-******-******-****) に与えることはできません。このセキュリティ アクセス許可は、コンポーネント サービス管理ツールを使って変更できます。
結論としては
であり
These events can be safely ignored because they don't adversely affect functionality and are by design.
ということでこれはそういうものなので無視してよい、気になるならイベントビューアに記録されないようにフィルタを書け、警告の文面通りにセキュリティ許可をいじるのはどんな副作用が起きるかわからないのでお勧めできないだそうだ
お勧めできないってなんだそりゃ
まあいいや
Web系のプログラマーがDockerとかフレームワークそのものを指して「技術」という言い方をするのがすげえ気持ち悪い。そういうところからも、本質的に雑というか、増田の言うように技術を作る気が無いんだろうなという気はする。
例えばDockerの公式ページでの ”technology” という単語の使われ方を見てみると
https://www.docker.com/resources/what-container/
Docker container technology
Docker’s technology
Technology available from Docker
などといった表現になっている。つまり technology とはDockerを構成している技術的な要素やコンポーネントそのものを指していて、Dockerというフレームワークを指しているわけではない。同じ technology がDocker以外のフレームワークの中にあってもいいし、技術的な概念としてのcontainerなどはその実施例の一つであるDocker containerより上位にあるものということだよな。
日本のWeb系プログラマーが言う「技術」という単語はそういった意味でのtechnologyを指しておらず、まるで最新のiphone出た！というようなノリでフレームワークだの言語だのといった実施例を指してるように感じて非常に気持ちが悪い。
JSXが嫌いとかそう言うわけじゃない。慣れれば、これはこれで良いかなと感じる部分もある。
何かの入力項目があった場合に、Stateを定義して、入力変更イベントを拾って、Stateに設定し直す処理を毎度書く必要がある。
何十項目とそれがあった場合、面倒だし、それらが単純なものとは言え、無視できないコストになってしまう。
コンポーネントコード中に、あまり本質的でない、Stateの定義と入力変更イベントでStateに設定し直す処理が、何十スクロールと続くのって読んでいて辛くならない？
Stateの定義をObjectでまとめて定義するって言うのも、解決策の一つなんだろうか？
調べてみたらできるっぽいけど、Objectの分割代入を使わなくちゃいけないみたいで、これはこれで面倒。
React Hook Formと言うのもあるみたいだけど、そもそもコアな部分で、それを吸収できる機構が無いのは如何なものかと思ってしまう。
（それをしないのが、React的なシンプルな設計思想でもあるのかな？）
Vue.jsでは、双方向バインディングはv-modelだけで出来ちゃうし、Angularの事は詳しく無いけどAngularも同じノリで出来るみたい。
まとめると、自分的な辛さの原因は『双方向バインディング辛い』ってことだけなんだけど、みんな本当にReactに満足してるのかな？
あと、Reduxに関しても、ちょっと言いたい。大抵のプロジェクトで、そこまでRedux使いたくなるか？
SNSのようなリッチなインタラクティブが求められる尖ったUIを作るのなら、もしかしたら必要なのかもって思うけど、大抵の場合、不要じゃないかって思うんだけど。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。
23 →目次に戻る
“ ネットワーク状況によっては使えないシーンがある点 ” は、VDI なら避けられない問題です。特に外出中は、ス
マートフォンによるテザリングで VDI に接続する際に、エリアや移動状況によっては通信環境が安定せず、通信が
切断されたり、通信速度が遅くなったりするなど、VDI がスムーズに動作しないシーンがありました。この課題に
対しては、スマートフォンのテザリング容量の観点なども含めて検討し、対処してきましたが、完全には解決でき
ませんでした。そこで、VDI では業務遂行がどうしても困難なユーザーに限定し、さらに高セキュリティ業務以外
での利用において通常の PC（FAT PC）を配布するようにしました。
もう一つの課題 “ ビデオ会議実施時の不具合 ” については、もともと VDI とビデオ会議の親和性は良くない点
が前提にあります。ビデオ会議の場合、クラウドサービスを使うことが多いと思いますが、通常の PC なら、クラ
ウドサービスと PC 上のビデオ会議ソフトウェアが直接つながり、ユーザーは快適にビデオ会議ができます。一方、
VDI の場合、クラウドサービスと VDI 上のビデオ会議ソフトウェアがまず接続され、その後 VDI から VDI 専用端
末（シンクライアント端末）に音声と動画が転送される形になります。音声も動画もいわば二重でデータ転送さ
れる仕組みなので、劣化してしまうのは避けられません。具体的には、音声が途切れ途切れになったり、動画が
また、システム管理の観点でもデメリットがあります。通常の PC では、ビデオ会議ソフトウェアの機能でクラウ
ドサービスとのネットワーク接続状況をチェックしてくれて、最適に通信する仕組みなのに対し、VDI ではそのよう
な機能は使えません。ビデオ会議ソフトウェアにその機能が搭載されていても、VDI から VDI 専用端末に通信す
る段階でそれらの機能が無効化されてしまうのです。その結果、VDI 上でのビデオ会議は通常よりも多くの通信
量が発生してしまい、外出時などテザリングの容量を圧迫することになっていました。
しかし、最近ではビデオ会議のこうした課題の回避策として、クラウドサービス各社が VDI 用のソフトウェアを
リリースしてくれるようになってきました。VDI 用のビデオ会議ソフトウェアを VDI にインストールして、一部のソ
フトウェアコンポーネントを VDI 専用端末にもインストールします。そうすることで、VDI と VDI 専用端末が協調
してビデオ会議端末として動作し、クラウドサービスと VDI 専用端末とが直接つながる構成になり、従来に比べる
と音声や動画の劣化が大幅に避けられるようになってきています。
24 →目次に戻る
中長期の PC 環境を構想する――“ 中長期 ” という新たな観点の導入
以上をまとめると、いまの VDI 環境では当初想定したメリットは得られたものの、ネットワークとビデオ会議に
おいてそれぞれの課題があります。ネットワークの課題は、一部ユーザーに FAT PC を配布することで、ビデオ会
議の課題については VDI 用のビデオ会議ソフトウェアをインストールすることで解決できます。いまの VDI 環境
を評価するマトリクスを作って検討してみると、VDI 用のビデオ会議ソフトウェアがうまく動作すれば、VDI 環境
をそのまま継続するのが妥当なように見えました。とはいえ、そのような “ カイゼン策 ” を施しながら、VDI をい
まの形のまま続けるべきなのでしょうか。そして、そのような思考プロセスに本当に問題はないのでしょうか――。
われわれは検討時に、新たな視点を導入することにしました。それは “ 中長期 ” 視点です。2015 年においては、
3 つの課題という、“ いま、ここ ” における課題に対する解決策として VDI を採用したものの、今後長きにわたっ
て会社を支えていくPC 環境を構想するに当たり、それだけでは不十分ではないかと考えました。リクルートは創
業から 60 年以上がたちました。今後も長きにわたり、カスタマーやクライアントの皆さんのためにより良いサービ
スを提供し続けることになるでしょう。それには短期的な視点だけではなく、中長期でのあるべき PC 環境を描い
て、それに向かっていまどうすべきかを考えなければならないと思ったのです。
そのためには、まず働き方が将来的にどうなるかを想定しなければなりません。次期 PC 環境を検討していたの
はコロナ禍前でしたが、ゆくゆくは「完全に場所を選ばない働き方」になるだろうと予想していました。キーワード
で示すならば、「Anytime/Anywhere/Securely/Work Digitally」という表現になるでしょうか。そのような働き方
を実現する PC 環境については、既にいわれて久しいですが、クラウド中心の方向性は変わらないでしょう。加えて、
今後は多種多様なデバイスが出現すると想定しました。いまは PC や VDI が中心であり、補助的にスマートフォンが
使われているというのがビジネスにおける PC 環境の実情だと考えます。では、今後はどうなるのか――。
スマートフォン中心になるという見方もありますが、学校では情報教育が進みノート型の端末が支給されており、
家庭においてはスマートスピーカーが広まり、AR/VR（拡張現実／仮想現実）もゲームなどを中心に広がってき
ています。また、企業では製造業などで AR/VR が使われる事例も出てきており、IoT デバイスもいろいろなユー
スケースが生まれてきました。
そう考えると、ユーザーが使う端末は、どれかの端末に収束していくのではなく、2in1 あるいはクラムシェル型
などの PC、スマートフォン／タブレット、AR/VR デバイス、スマートスピーカー、IoT などいろいろなデバイスを
使いこなしていく世界になるのではないかと考えます。業務のさまざまな場面で、いろいろなデバイスの中から最
適なものを選び、さまざまなクラウドサービスを使いこなし業務をしているイメージです。それらを使うことで、場
所を選ばず、どこにいても対面同様のコラボレーションができるでしょう。さらには、AI（人工知能）技術などを
活用しながらユーザーの業務を支援するなどして、高い生産性を生み出すことができる環境になっていくのではな
25 →目次に戻る
中長期視点で考え、いま行動する――「クラウド＆マルチデバイス環境」へ
われわれは、このような環境を「クラウド＆マルチデバイス環境」と呼ぶことにしました。中長期的には「クラ
ウド＆マルチデバイス環境」になるとして、VDI の EOSL 契機に対応しなければならないわれわれの次の PC 環
境はどのように整えたらいいのでしょうか。
大事なのは、「中長期視点で考え、いま行動する」ことです。中長期視点だけを考えれば、一気に「クラウド＆
マルチデバイス環境」にすべきでしょう。ところが、われわれの環境内にはまだレガシーシステムが残っており、一
気にクラウドだけを利用する業務形態に変えるのは困難でした。また、検討した結果、現時点では VDI に勝るよ
うなセキュリティ確保の仕組みは見当たりませんでした。そのため、情報資産の囲い込みができるという点で、高
セキュリティ環境に対しては継続して VDI を活用することにしました。
セキュアな環境以外の用途においては、“ いま ” のことだけを考えれば、ビデオ会議の部分のみを改善して VDI
環境のまま、次期 PC 環境を作る方向もあり得ました。しかし、それでは今後の PC 環境が VDI に固定化されて
しまうことになります。VDI 環境をいままでと同様にオンプレミスで作るには、初期に大きな設備投資が必要とな
り、また一度構築してしまうと使い捨てるわけにもいかず、それをしばらく運用し続ける必要があります。今後い
ろいろなクラウドサービスやデバイスが出現すると、活用したいと思う方も多いでしょうが、既に VDI を使ってい
る場合、VDI の代わりに別のものをすぐに使うということはなかなかできません。そういう意味で、PC 環境が固
定化されてしまうことになるのです。
中長期の環境に一気に切り替える方針でもなければ、現在のことだけ考える方針でもなく、「中長期視点で考え、
いま行動する」方針で検討した結果、次期 PC 環境は「クラウド＆マルチデバイス環境」を目指すための第一歩
と位置付け、「VDI と FAT PC のマルチ環境」を構築することに決定しました。先述した通り、レガシーシステム
が存在し VDI 以上に情報の囲い込みができるソリューションがない中で、VDI から離れ、一気に中長期的な将来
像を目指すのは困難です。とはいえ「将来像に向けた環境をいま作るべき」と考え、VDI と FAT を業務特性に応
じてユーザーに配布するマルチ環境に刷新することにしました。つまり、高セキュリティ業務ユーザー向けにはセ
キュリティを確保した「セキュア VDI」、それ以外の一般ユーザー向けには FAT PC を配布することにしたのです。
将来的にはマルチデバイスといっても、いまだ PC がメインなので、まずは PC を配布し、その上で今後 AR/VR
デバイスといった他のデバイスも検討していきたいと考えています。
なお、VDI 環境としてはもう一つ、機能更新がない固定的な OS を必要とするレガシーアプリ向けの環境も VDI
で用意することにしました。用途が限定されていることから、社内では「特定用途 VDI」と呼んでいます。
26 →目次に戻る
以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC 環
境は「クラウド＆マルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって
いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PC のマルチ環境」を実現する
ことにした、ということになります。
なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議の改善を試みました。先述した VDI 用
のビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画の品質が
極めて改善されることになったものの、2 つの課題が新たに見つかったのです。
1 つ目は、普通のビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題は
今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェアが機能面で劣っていました。
2 つ目は、導入／管理コストです。1 つのビデオ会議システムしか使っていない場合は問題ないかもしれません
が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度
以上 2 点については、いま検討されている方のご参考になれば幸いです。次回は、リクルートがいままさに取り
これまで、
https://anond.hatelabo.jp/20210828113740
https://anond.hatelabo.jp/20210918200735
とこき下ろしながらも様子を見ていたが、当初の売りだったはずのChromium派生のブラウザを諦め、Firefoxベースのブラウザとなるようだ。当初の「2022年までしかサポートしない」発言はどこに行ったのやら。
https://blog.ablaze.one/786/2021-11-11/ より。
Chromiumを採用しなくなったワケ
結論、Google API や Chromium の機能が原因です。 (中略)Google 側としては、 Chrome のシェアを伸ばしたいので、Edge に対してなんらかの形で Chromium から機能制限をかけると私は予想しています。
具体的には次が挙げられます
- Chrome ウェブストアが Chrome 以外の Chromium 派生ブラウザで使用禁止になる
- FLoC 強制オン
- Google サービス関係の利便性低下（YouTube、Google Drive、Google ドキュメント etc…）
- 広告ブロッカー無効化
(中略)Google は現在、独占禁止法で裁判にかけられており、負けた場合、(中略)Chromium というウェブの世界になんらかの規制をかけてもおかしくありません。
のように理由が挙げられているが、言い訳を自分の都合のいい方向に持って行っていないか？これらはFloorpをリリースする前に検討すべきことであって、リリース時点では多少であっても対策しているべきものである。
ので、Edgeにほとんどダメージは受けない。本気でEdgeを開発終了に追い込ませるなら、Chromiumを開発終了させてChromeだけをクローズドソースで開発すれば良いわけだが、オープンソース文化を破壊することになるし、Edge側もChromiumに貢献している部分があり簡単には止められないだろう。
もちろん、個人の寄せ集めでは難しいレベルにはなってきているし、当初に思った以上に面倒なことになるからFirefoxに浮気したのではないか。
これだけあっさりとChromium派生からFirefox派生へ乗り換えたのは、上記のブログの記事にある理由よりも、どちらかと言えばKinzaのパッチ適用が想像よりも遙かに難しかったからだろう。コーデックの問題がどうにもならなかったからもあるだろう。それと開発者が受験という一生を左右する大事なイベントを迎えて、Chromium派生をメンテナンスする人が誰もいなくなるからではないのか。それらをなぜ正直に書かない。まあ当事者だったら書きたくないわな、そんな都合の悪いこと。
これまでのChromiumベースとは使い勝手と全く異なるFirefoxベースとして作り直している最中で、独自機能を追加していくことになるだろう。独自機能が果たしてFirefoxのアドオンで十分まかなえる機能にすぎないのか、その範疇を超えるものなのか。革新的で軽量なブラウザー(自称)はFirefoxベースでも宣伝するつもりなのか、Fireminだけ入れておいて「最軽量」とまた言うつもりなのか。
リサイクルショップの店内をうろついていたら、既にディスコン品となった自転車の部品が売られていた。
外箱の機種のチェック欄の所には正式な機種（グレード）も記載されていた。
Webサイトでは新品（未使用品）が売られている事も有るが、価格が下げられていることは無い。
最初は購入を躊躇った。
古い機種の部品を寄せ集めて一式揃えるのか、全く新しい機種で一式を揃えるべきか。
一週間悩んだ挙句、古い部品を購入することとし同ショップを再訪した。
レジで念のためラップを外してもらい、箱の中身が未使用かどうかを確認した。
家に帰り、暫く手を付けていなかった自転車を、汗だくになりながら分解と掃除した。
さて新しい部品の取り付け、箱から取り出し取り付けようとしてぎょっとした。
箱に書かれている機種と、部品そのものに書かれている機種名が違っている。
下位グレードの部品だ。使用する3つの部品全てを調べてみると、全て同じ下位グレードの物だった。
騙された！と思った次の瞬間、もしかしてリサイクルショップも騙されたのか？という思いが沸き上がってきた。
箱に書かれた機種名だけを信頼してしまった事を悔いた。
取り急ぎリサイクルショップに電話し、箱と中身が違う事を説明し返品可能か聞いてみた。
電話対応してくれた男性は謝罪の言葉と、申し訳ないが返金処置に来てくれという事を言ってくれた。
ここで疑問なのが誰が悪かったのかということだ。
（リサイクルショップに持ち込んだ人をAとする）
１．Aが、騙すつもりで下位グレードの部品を入れて、事情に詳しくない店員はそのまま受け入れた。
２．Aは箱と中身が違う事を説明し、店員は理解した上で受け入れたが、箱と中身が違う事を表示しなかった。
３．細部まで確認せずに購入した俺が悪い。
1ではAが悪いが、2では店員が悪いのではないかと思うのだが、犯人捜しをする意味も無いだろう。
結局自転車は分解掃除されたままの状態となっている。分解する前はまだなんとか走れたのだが。
ディスコン品の未使用部品を寄せ集めても、中途半端な出費となるが、
新しいコンポーネント一式買い揃えるにはかなりの出費となる。
さてどうしたものか、また悩むこととなった。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
Floorp ウェブブラウザと名乗るブラウザが最近出てきて、開発が終了したKinzaのパッチが公開されたら取り入れると宣言してKinzaの後釜を狙ってるらしい。中の人は学生(中学生？高校生？)らしく、使っていくうちにチャラさ、痛々しさが目立ってきたのでこき下ろしていきたい。
このブラウザが気になってしょうがない人はTwitterアカウントに行けばダウンロードリンクがあるのでダウンロードして確かめればよい。
※以下の話は、断りのない限り8/28に公開された公開ベータ版(v1.1.3)のことである。
---------------------------------------------------------------------------------------------------------------------------------------------
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう
8.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
---------------------------------------------------------------------------------------------------------------------------------------------
利用したオープンソースソフトウェア
[※以下略]
さて、どこから突っ込もうか。
---------------------------------------------------------------------------------------------------------------------------------------------
あああああああああああああああああああああああああああああああ開発つかれた
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう。後眠いんだけどどうしよう？癒してください！彼女ください（）
8.Floorpは有志によって無料で提供されています。寄付は受け付けますのでダイレクトメッセージ https://Twitter.com/Floorp_Browser へお越しください
9.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
[※以下略]
利用規約をなんだと思っているんだ。「利用規約は楽しく、ユーモアにありふれさせたい」とか「Floorpの利用規約の最後に・彼女になることに同意しますか？って書けば同意させられんじゃん」とかつぶやいてる時点でなめてるしふざけてる。
Ablaze-MIRAI/Floorp-Browser: Chromiumで一番軽量なブラウザの大部分のソースコードです。
というタイトルなのに、実際に公開されているのはブラウザコンポーネントに比べてかなり少ない。これのどこが「大部分」なの？
あと何の根拠もなく「Chromiumで一番軽量」って言い切ってるだけで相当痛い。一番軽量かどうかは知らんが、メモリ使用量が少ない=軽量と思い込んでる節がある。ほか、
という文は誤解を生むから今すぐ止めろ。これだとBSDライセンスに違反するぜ！と宣言してるような解釈もできるから。利用規約でOSSに感謝しましょうとか言っておいてこの扱いひどくないか？
このブラウザの自己紹介記事(https://blog.ablaze.one/573/2021-08-16/)が先週公開されていたが、ここに書かれてる内容も相当痛々しい。
ブラウザをインストールするとメモリカスタマイザーなるものが同時にインストールされる。これが動作することでFloorpブラウザのメモリ使用量が劇的に減ってるから軽い、ということらしい。
しかし、ブラウザを起動したまま放置してみてから、実際のWindowsタスクマネージャーの様子をよく見てほしい。メモリ使用量が数MBとありえないぐらいまで減っているのがわかるだろう。Windowsタスクマネージャー上ではメモリ使用量が減っているように見えるが、ブラウザのタスクマネージャーで表示されるメモリ使用量はそれほど減っていない。では何が起こっているのか？
メモリカスタマイザーの正体はFireminである。名前の通り元々はFirefox用で、仮想メモリにページアウトさせて物理メモリ使用量を減らすものらしい(実際の動作は細かく見てないのでよくは知らない)。Fireminの名称変更、起動時にFloorpを自動的に対象にするといった改造を施している。FireminによってWindows10の途中の大型アップデートから搭載されたメモリ圧縮がより積極的にかかるようになり、物理メモリ使用量も減らせるメリットはあるようだ。YouTubeのトップページを開いてしばらく待った時、メモリカスタマイザーの使用時と未使用時で約0.1GBの差はあるのは確認できた。ただし、メモリ圧縮の代償はパフォーマンスの低下。特にページアウトによりディスクI/Oが増える。ディスクI/Oが足を引っ張って重くなる場合があるので、必ずしも軽いとは言えない。
結局の所、Chromiumを改造するなどの根本的な解決策を取っているのかは疑問である(もししているならTwitterなりに書いているだろう。技術的アピールができるし)。Floorpブラウザの作者はWindowsのタスクマネージャーに出てくる見せかけの数値だけを見て「えっ、Floorp軽っ、、、、、」とか言ってるのだから、実に恥ずかしい。いつ気がつくか見物である。
500ms単位でメモリ節約機能が動作するせいで、Speedometer 2.0のベンチマーク結果がさえない。未使用時と比べて7%ぐらいスコアが落ちてる。Edgeよりもスコアが良くない。メモリ使用量のことばかり気を取られて、速度のことには関心がないのかもしれない。
Chrome Web Store外から拡張機能(Deepl翻訳と同期機能)をインストールさせるためにレジストリを使用した結果、他のChromium派生ブラウザ(SRWare Ironで確認済)でも拡張機能がインストールされたという通知が表示されるようになってしまう。
Cドライブ直下にフォルダー作ってそこに入れるとか、いつの時代のソフトだよ。Program Filesに入れてやれよ。
https://ja.wikipedia.org/wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/Floorp
https://twitter.com/surapunoyousei/status/1431961462734352385
作者から依頼されて書かれた記事に客観的な証明なんてどうやってするんだろうね。
まあKinzaのパッチが出てからが本番っぽいし、それまではこれぐらいにしておこうか。
Uniant Browser → Floorp Browser? UniantとAblazeの関係がよくわからん。個人で開発してるのか寄り集まって開発してるのかもよくわからん。
中の人のTwitterで中学生と書かれていたことがあったので、高校生ではないかもしれない。高校生の表記から「学生(中学生？高校生？)」に変更した。
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
MSが恐れていたLinuxは今はもう無く、サーバ市場でMSに利益をもたらす家畜になった。
そして今となってはデスクトップOSとしての可能性がMSによって摘み取られようとしている。
WSLでGUIアプリが動くようになることで、GPUメーカーは最新チップのドライバをLinuxに提供する意義を少し失う。
LinuxのOS自体もデスクトップOSとしてベアメタルに載せる意味が薄くなっていく。
Linuxがwindowsに浸食しているのではなく、Linuxがwindowsの単なるコンポーネントの一つになりつつある。
UEFIの為にプロプライエタリという毒を喰らわざるを得ない状況もWSL向けディストロなら不用だ。
MSに飼われ続ける限り、最新GPUの性能を活かしたプログラムを動かせるし、そのほかのデバイスもどんどん使えるようになるだろう。
windowsのコンポーネントの一つになった方がデスクトップOSとしてLinuxの価値が上がってしまうと言うのはなんとも皮肉な話だな。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
288あとで/2715users 大学の恩師に教わった、「なにがわからないか、わからない」ときの質問のしかた。 | Books&Apps
281あとで/1814users 最初の一歩を踏み出すという汎用的な技術 - 本しゃぶり
250あとで/1465users 線形代数をアニメーションで幾何学的に簡単に理解できる36記事まとめ | HEADBOOST
236あとで/1717users ASCII.jp：天才プログラマー・オードリーさんがたった200行で効果的なアプリを作れる秘訣
221あとで/1568users 「140秒とは思えない満足感」「なぜこれだけの傑作が埋もれているのか」 崩壊した日本を旅する“最後の動画配信者”のショートフィルムが話題（1/2 ページ） - ねとらぼ
215あとで/1805users メルカリが検索に「売り切れ品」を置く理由、初期のLINEが友だち追加を「電話番号マッチング」に絞った理由など、アプリのマーケティング施策まとめ30｜アプリマーケティング研究所
189あとで/1454users 暇を潰せそうなサイトを沢山見つけたので貼りまくる:哲学ニュースnwk
174あとで/1269users メルカリ、「無意識（アンコンシャス）バイアス ワークショップ」の社内研修資料を無償公開 | 株式会社メルカリ
161あとで/1028users 文系パパエンジニアが放送大学等でコンピュータサイエンス・数学を学んで理系学士を取りに行く話 - とあるCS学徒のブログ
154あとで/906users Google TypeScript Style Guide
151あとで/1192users ゲームを作ったらハリウッドから映画化オファーが来た話 - Hirayaブログ
141あとで/1330users オーケーとその他スーパーたち - 14店舗のフィールドワークと500人のアンケートでわかったシンプルな結論｜太田正伸｜note
139あとで/819users 『ゼロからのOS自作入門』に込めた思い - uchan note
134あとで/712users 元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL
133あとで/1430users 游ゴシックの話題の解説 | anond.hatelabo.jp
132あとで/1127users 36歳で印刷会社の社長になった僕が、減り続ける売上をなんとか立て直した話｜工藤太一／印刷会社二代目／glassy株式会社代表取締役｜note
128あとで/799users Linuxの基礎用語を完全理解するためにエンジニアが作成した「10のミニプロジェクト」とは？ - GIGAZINE
127あとで/795users よく見かけるレイアウト・UIコンポーネント、それだけを実装するHTMLとCSSのシンプルなコードのまとめ | コリス
126あとで/1200users 「こんなん履いててプログラミングできるわけない」天才プログラマー登大遊氏が情熱大陸に登場、名言を連発しザワつくTL - Togetter
124あとで/543users 仕組みから理解する Git 入門 ~ ひとり開発でも便利 ~ - Speaker Deck
123あとで/612users Webエンジニアが勉強できるGit Repository 10選 - Qiita
118あとで/848users シェルスクリプトを書くときにいつもやるやつを調べた - Please Sleep
117あとで/990users 「SEOに強いHTMLの書き方」についての個人的な見解 | TAK | Zenn
117あとで/645users 英語力と技術力向上のための海外Tech系Youtuber10選 +n - Qiita
117あとで/1337users EXPERIENCE JAPAN PICTOGRAMS | 日本デザインセンター
117あとで/882users 管理職のための役職引退マニュアル | DevelopersIO
116あとで/1931users 森氏辞任に考える 日本社会に残る無意味な風習: 日本経済新聞
115あとで/1126users いとうまい子「アイドルだった私が遺伝子の研究者になるなんて」｜芸能｜婦人公論.jp
114あとで/617users 「挑戦させすぎ？」マネジメント勉強会で分かった組織課題とその解決策 - ZOZO Technologies TECH BLOG
114あとで/646users GitHubのawesomeリストが本当にawesomeなものばかりだから一度見てほしい - Qiita
予算が限られているなら、
急いで買い揃える必要はないと思う。
徐々に買い足していけばいいと思う。
慌てないことが割と大事かな。
乗り始めはお尻が痛くなる。
そのことへの対策のため、サドルやパッド入りの下着が欲しくなる。
でも、しばらくするとお尻が慣れてくるから、そういったものは必要がない場合もある。
慌てないことが大事。
でも部品を交換したところで結局クロスバイクだと満足できなくなるからロードが欲しくなる。
だったらクロスバイクに予算を使わず、ロード貯金をするべきだ。
慌てないことが大事。
そんな感じかな。
まあ他人への最適なアドバイスなんて出来ないから話半分に聞き流してもらえたら。
