「JSON」を含む日記 RSS

はてなキーワード: JSONとは

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-20

機械学習エンジニアコード汚すぎワロタアァ

なんだこれは

anond:20220120011019

pugみたいな5分で文法分かって

package.jsonに2行書けば導入できるようなツールを「技術」とか言ってる時点で無理だと思う

sassとかは難しいけどpugだぞ?分かってるのか?

こういう導入の簡単しか考えられない無能技術負債を積み上げていく

anond:20220120010619

pugみたいな5分で文法分かって

package.jsonに2行書けば導入できるようなツールを「技術」とか言ってる時点で無理だと思う

sassとかは難しいけどpugだぞ?分かってるのか?

anond:20220120001906

俺もわからないw

素のPHPみたいな方がHTMLとしてプレビュー編集できるし、

ツールはみんなHTML形式には対応しているけど、非HTML形式テンプレートには対応してないわけで、

JSONみたいに書けるんだぜ、とか、Pythonみたいにインデントするだけだぜ、みたいなのは

プログラミング言語マニア自己満足っぽい気がする

言語思考規定する、とか、流れるように書ける、とか、どうでもいいというか、

寧ろ、ツール群が揃ってるとか、つまらないほど使えて当たり前の方が開発は安定する

と、さっきまでNim書いてたフラストレーションもあって思いました

2021-12-21

涼宮ハルヒパッケージ管理

消失最後の方で、たしかキョン長門の恋心?が理解できてるのかよく分からんが、

長門がいない世界になったとしても、ハルヒ長門存在するように考えさせるみたいなことを言ってた気がするが、

当たり前だが、あの世界はハルヒが神みたいな前提で成り立ってるわけだが、

キョン長門だけでなく、すべての人、というか物質存在ハルヒによって成り立っているといっても過言ではない

まり、package.jsonだかgo.modだかcomposer.jsonだか使ってる言語にもよるわけだが、

すべての依存関係涼宮ハルヒと書かれてるようなわけであり、

まり、すべてのソフトウェア依存しているそのモジュールが改変されれば、

すべてのソフトウェアが影響するのと同じであり、

したがって、攻撃者は涼宮ハルヒに細工すれば、世界を思うがままに改変できるということである

まり涼宮ハルヒ洗脳するとか、思考誘導するとか、

なんらかの方法自分の意のままに考えさせることができるようになれば、

攻撃者は世界を思うがままに改変できて、それはそれで楽しそうに思えるのだった

俺がキョンならそれを試みると思うのだ

はぁ…

現実逃避終わり…

2021-12-11

anond:20211211003902

CSVでくれっていうコメントがあるけど、俺の感想はそれに近い

社内でしか公開しないエンジニアしか見ないプロトタイプみたいなもの場合そもそもプロトタイプ目的デザイン完璧さを求めることではないのでjsonでもcsvでもいいかAPIの生情報を見せろということはある

なのでどういうデザインがいいかっていうのはかなり文脈依存問題かもしれない

2021-11-12

anond:20211112091935

package.jsonとtsconfig.jsonは事前に見せてもらおう。パパと約束だぞ。

2021-10-18

なんでそんなにRails嫌いなん…?

わざわざRailsにReact乗せる理由コンテンツリッチ化以外に理由ある?

API化するかしないかってreturnがHTMLJSONかの違いかしかいから、やりたかったらフロントをReactにすればいいと思うけど、今回急ぎなんでしょ…?

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、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年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-08-28

anond:20210827165042

博士!解析結果が出ました!」

出力された紙テープには長々とJSONが…

2021-08-26

anond:20210826012139

なんでJSONに色付けする仕事でそんなに偉そうにできるんですか

2021-08-17

anond:20210817123214

かにJSONYAML といったシンプルな方が、楽だし、そこは許して。

2021-07-27

anond:20210727170728

かに保守性は最悪だししっかりサーバークライアント両方にデータが何かをコメントで書かないと使えない

でも全部intとかboolなら変換は簡単10個もデータあれば150文字ぐらいは節約できて、そういうデータ10個もあれば1000文字か…みたいな感じでJSON抵抗があった

 

仕事でもいるのか〜

世間一般で使われてる方法の方が100%正しいんだろうけど

anond:20210727170141

クソザコの感想だとJSON形式より対応文字列の変更(あるいはデータベース構造のものの変更)に弱そうとは感じる(保守性が悪い?)

でも仕事でも似たような組み方してた人がいるのを見たことあるからOKなのかもしれん

anond:20210727170141

よくわからんPostgreSQLJSONで何でもかんでも詰め込んだりしたなぁ

個人でやってるからだけど…

データベース配列で保存するのって公式ダメなんだな

JSONで保存するよりkey分節約できるじゃんと思ったんだけど

1999年以降はDB配列ぶちこむのは想定してないらしい

配列というよりフラグを1,1,0とかに変換するメソッド造っておいてそれ文字で投げる行為

やっぱりその程度の節約よりわかりやすさなの?

個人でずっとやってきたからわからないんだが

2021-07-19

https://anond.hatelabo.jp/20210719192035

もう対抗馬さんは出てこなくなっちゃったのかね。

さみしいので俺が書いとくわ。

2021/07/20(火) の予測値 1,084 (95%予測区間 902 ~ 1,258)
2021/07/21(水) の予測値 1,350 (95%予測区間 1,177 ~ 1,534)
2021/07/22(木) の予測値 1,611 (95%予測区間 1,437 ~ 1,782)
2021/07/23(金) の予測値 1,555 (95%予測区間 1,384 ~ 1,757)
2021/07/24(土) の予測値 1,612 (95%予測区間 1,436 ~ 1,796)
2021/07/25(日) の予測値 1,273 (95%予測区間 1,088 ~ 1,452)

2021/07/26(月) の予測966 (95%予測区間 783 ~ 1,145)
2021/07/27(火) の予測値 1,332 (95%予測区間 1,134 ~ 1,519)
2021/07/28(水) の予測値 1,649 (95%予測区間 1,429 ~ 1,854)
2021/07/29(木) の予測値 1,957 (95%予測区間 1,722 ~ 2,205)
2021/07/30(金) の予測値 1,879 (95%予測区間 1,617 ~ 2,128)
2021/07/31(土) の予測値 1,938 (95%予測区間 1,675 ~ 2,220)
2021/08/01(日) の予測値 1,523 (95%予測区間 1,290 ~ 1,771)

2021/08/02(月) の予測値 1,151 (95%予測区間 949 ~ 1,378)
2021/08/03(火) の予測値 1,579 (95%予測区間 1,296 ~ 1,852)
2021/08/04(水) の予測値 1,948 (95%予測区間 1,615 ~ 2,267)
2021/08/05(木) の予測値 2,302 (95%予測区間 1,959 ~ 2,715)
2021/08/06(金) の予測値 2,203 (95%予測区間 1,768 ~ 2,611)
2021/08/07(土) の予測値 2,264 (95%予測区間 1,851 ~ 2,739)
2021/08/08(日) の予測値 1,773 (95%予測区間 1,391 ~ 2,155)

2021/08/09(月) の予測値 1,336 (95%予測区間 1,035 ~ 1,668)
2021/08/10(火) の予測値 1,827 (95%予測区間 1,425 ~ 2,258)
2021/08/11(水) の予測値 2,247 (95%予測区間 1,728 ~ 2,794)
2021/08/12(木) の予測値 2,648 (95%予測区間 2,054 ~ 3,296)
2021/08/13(金) の予測値 2,526 (95%予測区間 1,876 ~ 3,184)
2021/08/14(土) の予測値 2,590 (95%予測区間 1,918 ~ 3,317)
2021/08/15(日) の予測値 2,023 (95%予測区間 1,482 ~ 2,618)

2021/08/16(月) の予測値 1,520 (95%予測区間 1,060 ~ 1,983)
2021/08/17(火) の予測値 2,075 (95%予測区間 1,440 ~ 2,719)
2021/08/18(水) の予測値 2,545 (95%予測区間 1,766 ~ 3,377)
2021/08/19(木) の予測値 2,994 (95%予測区間 2,065 ~ 4,002)
2021/08/20(金) の予測値 2,850 (95%予測区間 1,946 ~ 3,818)
2021/08/21(土) の予測値 2,916 (95%予測区間 2,006 ~ 3,900)
2021/08/22(日) の予測値 2,273 (95%予測区間 1,443 ~ 3,069)

ついでにソースも公開しとくわ。Google Colaboratory に貼ればそのまま動く。

見ての通り、単に過去感染者数を Facebook Prophet に放り込んだだけの単純なモノ。人流も変異株もワクチンも全く考慮ナシ。

適当に改良よろ。

!pip install -q fbprophet
from fbprophet import Prophet
import pandas as pd
!wget --no-check-certificate --output-document=covid19_tokyo.json 'https://raw.githubusercontent.com/tokyo-metropolitan-gov/covid19/development/data/data.json'
data = pd.read_json('covid19_tokyo.json')
date_data = []
posi_data = []
for i in range(len(data['patients_summary']['data'])):
    date_data.append(data['patients_summary']['data'][i]['日付'])
    posi_data.append(data['patients_summary']['data'][i]['小計'])
data=pd.DataFrame({'ds': date_data, 'y': posi_data})
data['ds'] = data['ds'].astype('datetime64')
model = Prophet(interval_width=0.95, changepoint_range=1.0, changepoint_prior_scale=0.5, seasonality_prior_scale=10.0, seasonality_mode='multiplicative',  n_changepoints=50)
model.fit(data)
future = model.make_future_dataframe(periods=35, freq='D')
forecast = model.predict(future)
model.plot(forecast);

2021-07-17

anond:20210708205945

最近テック系の生態系を知らずに、ほとばしる若さ嫉妬して学生をぶちのめし申し訳なかったと思うようにはヒートダウンしてきた「年収270万円だった医大生」です。こんばんは!

激おこしたのは、申し訳ない。

すごく反省している。ただ、優雅自分学生時代に学んだ知識をもって、社会人にその勢いを保持したままで定年まで行ける可能性は高くないと私は思うのだ。おそらくは名門大で、勢いのある会社なら引く手あまたそうな貴方自分にとっては眩しかったのだ。

フロントエンド給料が安いという思い込みをしてました。

本当に認識不足だった。もともと Android/iPhonejQueryJSON操作をしていて、PHP/Rails/Springバックエンド界隈から MySQL/PostgreSQLを触り、人員不足AWS をも触って QA および SRE をしていたエンジニアだったのだけど、ブロントエンドが DB に遠いという理由で簿給だと思っていたのは、各派遣会社給料をみる分だと間違いだと理解した。知識アップデートされてないのはオレ自身だったようだ。申し訳ない。

Firebase や mBaaS は不味くない?

根拠は、NoSQLスキーマしなのは途中までは良いけど、後で負債になる感じがするので。あと、Firebase は Google が中途でやめるとなったときが怖いぞ。JS なら express というフレームワークあるし、Kotlinサーバーがあるから古典的サーバークライエントモデルで良いのじゃないかな?Next なら SSR あるし。

サイバーエージェントにくくった理由

自分のような新卒採用を逃した身分では、サイバーエージェントのような B to C 領域トップティアにある会社に紹介してもらえるというのは「蜘蛛の糸」のような貴重なチャンスに思えたのだよ。そりゃ、ある程度は経験積めばスカウトが来るかもしれないけどさ、自分は年食っていたから「サイバーエージェントで働けるという可能性」に全力をかけたよ。その結果が、場末の未認可SES って、しか反社だったなんて、すごくショックだったよ。クソな「自称数学者人工知能論を聞いて土日が終わり、平日はブラック客先常駐」な日々はうんざりだ。

2021-07-14

anond:20210714091139

よく分からん

要は、Enumソース内で書くか

JSON で外に保持するかのどちらかって

話でいいのか?

anond:20210713142310

文字列配列ってことか?

とすると、jsonキー

番号なのか?

2021-07-12

anond:20210712154918

「これをやればモンハンを作れる」などというもの存在しない

ほとんどの職業プログラマは、モンハンを作れない

ハローワールド文字列表示)の延長でHTMLJSONを生成してブラウザに表示したりSQLをこねくり回したりするだけ

2021-06-18

直前パワーポイントファイルを投げてくる。発表が終わると消える。パワーポイント形式って資産管理観点からかなり使えない。図はソースがないとダメ。そのまま図を使いまわせることなんてめったにない。図を作った時に書いたコードデータjsonでもCSVでもいい)がないとならない。最近パワポ独自形式グラフ機能がある。アレで作ればCSVに相当するものは埋め込まれてるのでかなり助かる。パワポだけじゃなくてリポジトリを作らせてその中にデータだのコードだのを詰め込ませるのがベストさらベターなのはgithubactionsでタグ打ち込み時にbeamerスライドリリースしてくれるとか・・・

2021-05-28

Excelの1セルJSON形式で全部入れてもらったほうが助かる

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