ノード - はてな匿名ダイアリー

ファイナルファンタジーのガンビット、マリオメーカーのノードン、iOSのショートカット、Excelのセル内の関数、技術者ではないそこらの社員でも1〜2日でツール作れるようになるノーコード、などなど。プログラミング要素は広まって敷居が低くなり続けた結果、いつの間にか目にしてたり変更してたりお子様の遊びだったりする程度のものに。人目に晒そうとするような特別感はプログラミング部分にはもはや無いと思う。

Permalink | 記事への反応(0) | 19:59

2022-06-23

■anond:20220622210903

シュレーディンガーのLED

アノードかカソードかとりあえず適当に通電して確かめます

Permalink | 記事への反応(1) | 08:12

2022-03-23

■経済政策って、もっと 制御 システムっぽく検証出来ないものなのか？

トリクルダウンが効く/効かない、時代背景が違う、国が違うとか、経済政策に関して前提が合っているのかがわかりにくい。

計算機が発達した現代で、もっと制御システムっぽく組み上げ、色んなノードを見て、政策が合うのかどうかなど、検証出来ないものなのだろうか。

Permalink | 記事への反応(0) | 13:30

2022-03-04

■このままロシアが弱体化すると、どうなるのだろう

欧米のロシアに対する制裁が続いてる。

どこまでロシアを弱体化させた方がいいのか。

今のウクライナ侵攻をロシアが辞めるまで、というのはわかりやすい。

プーチンが降りるまで、というのもシナリオの1つだろう。

それだけで済むだろうか？

「またいつ繰り返すかわからないからロシアを解体してしまえばいい、ノード・ストリーム2がつながっている土地も欧州に組み込んでしまえば丸く収まる」

という誘惑はないだろうか。

Permalink | 記事への反応(0) | 18:41

2022-01-25

■本のまとめ

--

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

1章

【コンテナとは】

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

【コンテナ利用のメリット】

・環境依存からの解放

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

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

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

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

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

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

・リソース効率のアップ

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

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

【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 shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

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

【セキュリティ設計】

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

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

　- 方法

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

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

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までであること。

・VPCのIPアドレスの割当量に気をつける

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 から見ると単に１つのプロセスが稼働している扱いになる。

【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 shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

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

【セキュリティ設計】

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

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

　- 方法

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

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

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までであること。

・VPCのIPアドレスの割当量に気をつける

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

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

Application Autoscaling

Fargateで使用可能

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

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

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

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

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

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

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

2022-01-19

■anond:20220119224450

情報＝ノード
組み合わせ＝パーセプトロン
外部データ＝教師データ
適応＝モデル適合

全然わからんぞ。「数学的」と言ったのは、どこからどこへの写像かとか、どういう量の最小値として解が与えられるかとか、そういうことだぞ。

例えば「ノード」ってなに？「モデル適合」とやらをする前と後でどういう量がどう変化するの？

Permalink | 記事への反応(1) | 23:31

■anond:20220119181528

情報＝ノード

組み合わせ＝パーセプトロン

外部データ＝教師データ

適応＝モデル適合

知ってそうなんで、不足や誤りあったら補ってくれ

Permalink | 記事への反応(1) | 22:44

スパコンの中のソフトウェアを開発している人にお時間をいただいて色々お話を伺ったのだけど、非常に面白かった。ある程度組み込みっぽい泥臭い運用環境なんだろうなとは思ってたけど、思った以上に凄く頑張ってた。また、閉じられた世界にいつまでもいられないことも知った。思ったよりOSSへの依存度が高いことを知った。ノードのスペックはかつての覇者Summitなどと比較すると華々しい報道の裏で実は致命的にポンコツなところがあることも知った。

Permalink | 記事への反応(0) | 10:19

2021-11-04

■anond:20211104105840

やきう脳は他競技もノードーピングだと思ってるお馬鹿だから困るよな

2000本安打駒田「野球はスポーツじゃなくてレジャー」

Permalink | 記事への反応(0) | 11:01

2021-10-11

■エンベデッドスペシャリスト2021/10/10＠新橋TKP

去年は午後1が数点足りず不合格。問題文に相槌うってメモしてたら時間なくなりました。

リトライ。今回はメモや書込みは最小限に、淡々と読み進める！午後1も5分程度余るようにできました。

----

午後1・・・・設問2→1の順で解いた。良かったと思う。

■問1：ペット医療点滴のシリンジポンプ（45min）

設問1

(1)準備中､設定中､設定可

(2)0.5mm

(3)144回転 128pps

設問2

(1)a：キー判定　　b：設定終了キーの押下★　　　　　　　　　（★…ちょうどの単語がなかった）

(2)c：シリンジID、点滴流量

(3)薬剤が詰まり圧力センサの出力値が基準値を超えた

設問3

(1)d：設定開始★　　e：設定中★　　f：準備　　g：準備中　　（★…設定終了と設定完了かも）

(2)設定項目に不足があった場合✕　

　　　（✕設定完了後にリーダをSポンプに接続したとき、一括登録した時、など迷ったが分からない）

■問2：DXレストラン（40min）

設問1

(1)0.38ms

(2)料理人が品切れ情報を登録する前に利用者が注文情報を送信したとき

設問2

(1)入店､清算、キッチン

(2)a：注文履歴情報　b：キャンセル対象の注文情報　c：指示タスク　d：片付け指示　e：空席管理情報の該当テーブル

(3)全テーブルタスクに品切れ情報を送信する

設問3

(1)料理がロボに格納され、かつ着座人数が1人以上であるとき

(2)g：注文履歴情報の該当する注文を配膳済みに更新する

(3)h：該当するテーブルタスクに通知する

----

午後2（120min

■問2：工場生産ラインの可視化

設問1

(1)出力ノード　　　　（★ふつうに工程かも。迷った。）

(2)a：SDカードとフラッシュメモリのモデルを読み出し、作成日時を比較し新しいモデルをRAMに展開する

　b：次回からフラッシュメモリだけで起動できるため　（全然わからない。SDカードは他工場でも使うのかなと。）

(3)圧縮行程の工程生産能力：2222個/h

　ライン生産能力：1667個/h

　工程間滞留量の最大値：600個　　（概念が全然分からない。。）

設問2

(1)a：ドライバの識別 ID、ドライバ用の個別データ　　b：センサの識別 ID

(2)a：読み込むべきモデム及びドライバが、SDカードにある

　 b：読み込むべきモデム及びドライバが、フラッシュメモリにある

　　　（5文字差がSD→FMの差だとすると同文言の答えだと推測）

　　　（「読み込むべき」が無いと「準備完了（条件1,2とも偽）」が説明できない）

(3)(a)d：電流センサ　e：産出センサ　f：投入センサ

　 (b)g：投入量通知　h：中断　i：再開

　 (c)工程1。工程2から工程1に投入量通知が送られているから。

　 (d)工程異常、ライン異常

設問3

(1)a：152byte増

　（計算: ①サーバ接続情報(64)が増える、

　　　　　②工場 ID(4)がS工場の圧造工程と転造工程の2工程分増える、

　　　　　③さらにT工場熱処理工程とU工場表面処理工程の工程情報が増える。

　　　　　　これは他工場の工程なので投入センサ情報/産出センサ情報/設備数/設備情報が

　　　　　　不要だから、工程名(32)+工場 ID(4)+【a】識別 ID(4)★だけで良い。

　　よって、①64、②4*2工程=8、③(32+4+4)*2工程=80 を合計して152byte。）

　（★が明言が無く加算していいのか謎。除くと144。そもそも他工場の工程も加算で良い？）

　 b：工程間滞留量

　 c：工程生産量と同値が表示される

(2) j：工程情報通知

　 k："投入量通知"を受信した場合　　　（★時間なかった。テキトウ。）

　l：モデルの"サーバへの接続情報"の先頭バイトが0

----

Permalink | 記事への反応(0) | 17:05

2021-10-05

■anond:20211005055655

いや何いってんの？

Appleは中国のファブが磨いてきた枯れた技術にお墨付きを与えるようなモノづくりをしているだけ。先端を追わずに、いいとこ取りしていく狡猾なスタイルだよ。そのくせものすごい精度を求めてくる、生産者としては厄介企業。

技術的なイノベーションは常に中国で起きている。

例えば最近で言うと、シリコン酸素アノード電池を実用レベルにもっていき製品化したのも中華メーカーだ。これも現在のものを置換えていくだろう。

画面内指紋認証技術もたくさんの機種に搭載されてきた中で着々と世代が進んで高精度化している。

画面内インカメラについても、去年夏、実用化されたZTE Axon 20 5G(≒Rakuten BIG)では酷評が多かったが、最新の第3世代になってくるとXiaomiやOppoにも今夏の採用機種がでるほど品質面の問題がなくなってきたという事情がある。

Permalink | 記事への反応(0) | 10:12

2021-08-22

■

彼女の元カレは

彼女が泣いてクスリは止めて欲しいと懇願した時、

ノードラッグノーライフと言い切ったらしい。

増田くんは真面目だから変な心配しなくていいからうれしいと言ってた。

でもそうかな？

僕は元カレがちょっと男らしいなと思うし、

真面目なのはむしろ元カレのほうじゃないのかな？と思った。

Permalink | 記事への反応(1) | 08:42

2021-07-02

■anond:20210701235419

ん？親が消えても子ノードは独立に存在するからその下に孫ノードがつけられるという話ではなく？

子が親になるというか

Permalink | 記事への反応(1) | 00:07

2021-07-01

■anond:20210701234600

https://anond.hatelabo.jp/20210701213344

気になったら見てみてNE

おお、更新された。

こういう仕様か

エントリとそのページのHTML データだが紐づいてて

親ノードや子ノードが更新されるわけじゃないんだな

Permalink | 記事への反応(1) | 23:54

2021-06-20

■anond:20210620162352

ノードを遡ってみたら他の人にも言われてた

怖い

Permalink | 記事への反応(0) | 16:26

2021-06-18

■anond:20210618184327

pop(i)の計算量がO(n)であることを言いたいだけなので、for文を使わないメリットとか考えていません。

また、nodesをスタックのように用い、do somethingの中でnodesの末尾にノードを追加するようなことは、普通にあると思います。

その場合、get_node_list()で取得したnodesの先頭または末尾から順番に処理されるとは限りません。

Permalink | 記事への反応(0) | 18:58

■anond:20210618170112

ではi番目の要素へのアクセスは、要素数を持っておいて、近い方から行うのですか？

それとも、インデックスとノードのポインタの対応付けを木などに格納しておくのでしょうか？

Permalink | 記事への反応(1) | 17:08

■anond:20210618164927

ポインタが末尾を指しているなら、先頭のノードに到達するにはn回リンクをたどらなければいけないよね？

Permalink | 記事への反応(0) | 16:53

■anond:20210617075257

アルゴリズムいらないって言ってる奴いるけど正気か。

そういう奴は、これのどっちが正しいかみたいなことをいちいち個別に覚えるのか……。

nodes: list['Node'] = get_node_list()
while(nodes):
    n: 'Node' = nodes.pop() # 末尾のノードから処理
    # do something

nodes: list['Node'] = get_node_list()
while(nodes):
    n: 'Node' = nodes.pop(0) # 先頭のノードから処理
    # do something

追記

型ヒントをつけろと書いてあったので付けました。

コメント//から#にした。完全にミスった。指摘サンクス☺

Permalink | 記事への反応(2) | 14:07

2021-06-16

■anond:20210616082458

ノード？

ネットワークのノードのこと？

Node.js のこと？

これだから素人は

Permalink | 記事への反応(0) | 08:36

2021-06-15

■メモ

初日：2h30m

2日目：4h35m

3日目：2h13m

4日目：5h54m

5日目：6h22m

6日目：3h38m

7日目：直接的なモデリングは行ってないので時間は計測せず。ただ、公園の綺麗な休憩所のシーンに樫の木をアペンドして読み込み、それぞれ別のBlender ファイルを同一シーン上に並べ、それぞれのテクスチャもちゃんと反映された状態でレンダリングに成功するなど、素材を利用した制作術に進歩があった。また、本のBlender ファイルを読み込んでからテクスチャが反映されてない（モデルカラーがピンク状になっている）状態をシェーダーエディターで修正し、シェーダーエディターのモード変更でオブジェクトモードからワールドモードへ移行してHDRI画像が反映されていなかった状態を修正することでHDRI画像の設定の仕方を知るなど、新しい制作術を覚えることに成功した。

8日目：cgtraderのBlender用フリーモデルの完成度があまりにも素晴らしい。DLしたモデルが正常でないテクスチャ表示（紫色）になっていた場合は、『ファイル→外部データ→欠けているファイルを探す→DLしたモデルのテクスチャが格納されているフォルダで "欠けているファイルを探す" を実行』この手順でおおよそ何とかなる。

9日目：ニューヨークの一画を丸ごと再現したモデルが本当に凄い。街並みをそれっぽくローポリとテクスチャで綺麗に再現する手法の勉強になる。また、このモデルをBlenderで開いた時に初めて2画面（2ディスプレイ）で開くことで、Blenderが全画面モード中でも複数画面で編集画面を展開できることが分かった。全画面表示時、メニューバーから『ウインドウ→新規ウインドウ』の手順を踏むことで新しくウインドウが展開されるので、それを別ディスプレイに持っていけば、あっという間に2画面に渡った全画面表示編集環境が完成する。