  |
はてなキーワード: 利用者とは
https://b.hatena.ne.jp/entry/s/twitter.com/akihiro_koyama/status/1486624380692365317
cinefuk わかり手が編集してもエエやん（IPユーザの編集は荒らし認定されやすいけど）/ 近いうち荒らしによる編集合戦になって、規制が入る予感
https://twitter.com/akihiro_koyama/status/1486624380692365317
小山晃弘（狂）
@akihiro_koyama
ブクマカはたった2ツイートから構成されるスレッドを読めずデマを一番人気とする反省をするべきである。
はてブは他サイトに寄生するシステムである自覚を持って利用せねばならない。
通常にTwitterの利用者であれば全員理解している。公式クライアントのデザインが一目瞭然である。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ネットのいざこざや、大規模な放火事件などを見るにつけ、自分の思い通りに生きられないことの苦しみはいよいよもって高まってきていると言える。
一方で、技術的進歩により人々は仮想的な空間に自らの存在を移し、その中で遊ぶことができるようになった。
このことを、世の偉い人たちは人々が求める身体的解放の一形態だと捉えているようだ。
しかし、人々が本当に求めているのは、そんな意味での物理的な仮想空間なんかではなく、思想的な仮想空間の方である。
この「思想的な仮想空間」とは、具体的に言うなら、お互いが思う正しさが矛盾なく存在する仮想的な世界といった意味だ。
つまり、誰もがその自分の思考通りに生きられ、そのことによる対立や争いが生じない世界。
まあ、そんなことが現実の世界では不可能なのは、一番最初に挙げた例からでも理解できるだろう。
間違っちゃいけないのは、そのことが、高速で走れるとか空が飛べるとかの身体的自由を求めてではないこと。
冷静になって考えればわかるが、そんなことは人々にとって根本的にどうだって良い。
そうじゃなく、自分の思想に抵抗の無いという意味で自由な世界を求めるから、人々は仮想空間を目指すのだ。
このことこそ、これから仮想空間を考える上で大事な視点となるはずだから、思い付いたその瞬間に雑多な文章のまま書き残しておく。
（追記）
「思想的自由」というフレーズは、若干誤解を生む表現だったかもしれない。
トラバやブコメを見ると、人々は思想的な議論ができる自由を求めて（インターネット上の何かと同じように）仮想空間を目指すのだ、みたいな理解を与えてしまったようで申し訳ない。
そうじゃなくて、言いたかったのは、前半にある「誰もがその自分の思考通りに生きられ、そのことによる対立や争いが生じない世界」の部分で、
仮想空間のニーズはまさにその部分にあるのだろう（なのに、身体的自由ばかり強調されている）と思ったから、思いつきを書き残したのだ。
仮想空間なら、そこに居る「他人」はリアルな人間でなくたっていい。だから、そこに対立が存在しない「人間関係」を作れる。
また、アバターのように、利用者にとって見たいもの、見せたいものだけ存在する環境も作れる。
そういったものが、平行世界、観測者効果みたいなものを想起させて、仮想空間が先述の「誰もが～世界」となりうるだろうと考えたのだ。
㈱はてなでは誰かから増田の削除依頼があった場合、おそらく無条件に削除します。その増田の内容が適切か不適切かは関係ありません（私の場合、1回めは名誉毀損にあたるという判断も可能な内容でしたが、2回めはまったくそのようなものではありませんでした）
そして削除依頼を受け付けて増田を削除した際、増田を投稿した利用者には㈱はてなよりその旨メールで連絡が来ます。メールには誰からの削除依頼があったかが記載されています（私の場合も、1回めの削除依頼の際、おなじ人物について言及したほかの増田も念のため削除しておきました）
OSM は成功したボランタリー地理情報 VGI(Volunteered Geographic Information) の一例と説明されますが、あくまでそれは一つの要素であって、世の中に定着した「最大」の理由はボランティア運営によるクラウドソーシング手法を採用したことではありません
Google Maps のように商用利用時に制限のかかったウェブ地図よりも、より自由で、ある意味何でもできる OSM を採用する企業が増えたことで、OSM の認知度が向上するとともに、企業が OSM を用いたサービスで収益を生むことによる「エコシステム」がまわった。商用利用を許容することで民間企業による OSM のデータ更新と利用価値を更に高める正のフィードバックへとつながったのだと筆者は考えます。
https://medium.com/furuhashilab/show-the-niantic-flag-4ab03ed1c3ea
OpenStreetMapとは、自由に改変ができその利用もGoogleMapより自由度が高いことで有名な地図ソフトです。登山マップやゲームのマップなど、様々な分野で活躍しています。これの特徴は、無償のボランティアや利用する企業によるメンテナンスにあります。その中にはAppleやFacebookといったあまり地図に関係しないような企業も参加しています。
存在しない島を追加したり海岸をまっすぐにいじったりすることは可能ですが、当然そのようなこのはしてはいけません。地図としてきちんと整備することが第一で、OSMやその利用者の利益に繋がります。
ここで名指しで取り上げられているNianticは、ご存じのようにポケモンGoを開発運営する企業。
ポケモンGOの地図はOSMを元に作られています。ポケモンGOは日本だけでなく世界中で広く利用されており、その人口も非常に多いことで有名です。当然Nianticは世界でも指折りのOSMユーザーでありその恩恵を受けていますが、実はNianticはそのOSMに対する貢献が殆ど無いことでも有名です。
自身のアプリ内で直に使用し多くのユーザーの目に触れているものを、自らメンテナンスして貢献していないという実態はコミュニティの中に筒抜けです。
言ってみればNianticはみんなで作る地図にただ乗りしているわけです。
それだけなら大したことではないかもしれません。OSSを幅広く利用していても、その改善に努めないことが間違っては居ません。
ただ、Nianticの作っているポケモンGOはOSM自体への改ざんに繋がっているのが厄介な点です。ポケモンGoはOSM上の公園などの特定の場所にポケモンが出没しやすい仕様です。逆に言えばOSMをいじって自分の周囲に大量をポケモンを出してしまうことも原理的には可能です。そしてそのような改ざんがOSMのコミュニティの中で非常に問題視されました。現在は過去ほど大規模な改ざんは行われていないようですが、小規模な改ざんは今も続いているでしょう。当然、OSMは全世界的にそれが反映されるので、OSMを利用する企業や個人がその改ざんの被害者となり得ます。
それを知っているNianticは問題を放置し、修復を他の企業やボランティアに任せっきりにしています。ただ乗りを明らかに超えていることでしょう。
さらに、現在ではOSMを超えてGoogleStreetMapの改ざんも多く報告されています。実在しないものを審査させるために、その根拠となりうるストビューに意図的な改ざんをして審査を通すやり方です。
ここまでしてまでポケストが欲しい人が多いのが実情
また、ポケモンGoのポケストはそもそもIngressというゲームのポータルに由来します。最初こそこのポータルを設置する機能はポケモンGoにはありませんでしたが、現在はポケモンGoのユーザーでも申請や審査が可能となっています。しかし当然由来と使い方が違う物を別々のユーザーが申請・審査することは非常に軋轢を生むことになります。
現実問題、ポケモンGoで申請・審査ができるようになってからの不正なWayspotの登録は加速度的に広がりました。何も無いはず場所に大量のスポットが出現したり、本来はありえないものが登録されていたり。酷いときには地域毎で談合を行っています。さらにNiaticはあろうことかFourSquarer上から任意のスポットを抽出してスポット化しました。ユーザーに何も伝えずです。
これがポケモンGoの為だけならまだギリギリわかりますが、他のIngressや魔法同盟、ピクミンなどにも影響が及ぶスポットをこのような乱雑なやり方で作成することは問題です。
将来のゲームユーザーも使う物をポケモンGoの恣意的且つ数の暴力で歪めているのが現状です。
唯一のいいところですが、OSMのマッパーが少しだけ増えたことでしょうか。
だいぶ混乱してきた…
先日、フェミニストが特定個人の夫婦のあり方を批判して、炎上していた。
それへのブコメに、夫婦間で合意があるのだから他人が批判してはいけない、のような意見があった。
どんなときに批判してよくて、どんなときに批判してはいけないのか？
はてなブックマークを見ていると、明らかな部外者が批判しているときがあれば、not for me で素直に退いているときもある。表現の自由としては、言論を用いる限りいつでも批判して良いのだろうが、人々の振る舞いを見ていると「批判していいとき・いけないとき」の区別の基準があるような気がするんだ。
私は、絵描きの画廊サイト Pixiv のコメント欄を好んで眺めている。そこには賞賛が連なるばかりで、批判などめったに見かけない。
Youtube でゲーム配信の動画も、同じようにどこもかしこも穏やかなものだ。善きコメントは、いいね！の数字で華やかに飾られていて。すぐとなりのダウンボートボタンは沈黙を保っている。ある日疑念に駆られた私は、古い動画の片隅のコメントにダウンボートを押してみた。それは確かに、間違いなく機能しているようだった。人々は望んで平和を選択しているのだ。ゲーム配信動画は少なくともその膝下では、批判してはいけない。私はもう一度ボタンを押して、自らの痕跡を消した。
署名の有効性に関して、事務局が本人確認を怠った事に謝罪が無いとか、後からでも良いので本人確認するべきとか言われてますけれども。
そもそもあのオープンレターの署名、正当な手続きでの署名ではないので、署名の部分は無効なんですよね。
元々署名とは
民事訴訟法228条
（省略）
また、
平成十二年法律第百二号電子署名及び認証業務に関する法律
https://elaws.e-gov.go.jp/document?lawid=412AC0000000102
が発令される際に、2020年9月4日、総務省・法務省・経済産業省の連名により、「利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A（電子署名法第3条関係）」というものが公表されましたが、その中に「固有の要件」が満たされる場合には立会人型の電子契約でも真正に成立する、とされています。
https://www.meti.go.jp/covid-19/denshishomei_qa.html
例のオープンレターはGoogle Form使ったらしいけど、あれだと匿名で署名できてしまうし、主催者に投稿者情報はわたらないしでこの要件を満たしません。
せめてchange.org使えば、二要素認証はあるし、万一なりすましがあっても主催者のみに署名者の連絡先が公開されるので、身元確認は後からでも可能。
証跡を追える方法を確立できているか、という点が重要なところです。
ということで、そもそも例のオープンレターは署名として私文書の成立要件を満たしておらず、単なる数名の意見表明文書くらいの位置付けにしかならないんですよね。
あの文書が元で呉座先生が要職を辞されたという話もあるけど、数名の意見表明に左右されてしまって可哀想な気もします。
例のオープンレター、署名として成立させたいなら、今の方法では（署名部分は）全てが無効であり再度署名を取り直すしかありません。
今から本人確認やりなおそうが連絡先を追えないので不可能ですし、事務局が説明したところでそもそも効力無いので意味がりません。
実際に署名したよ！という方々もいらっしゃるとは思いますが、そもそも無効な手段によって集められた署名なので、署名としての有効性は最初から無かったわけです。残念。
ということで、今後Google Formで署名を集めてる文書にサインしようとするまえに、事務局に「その方法だと署名として成立しませんよ」とそっと教えて差し上げましょう。
オープンレターの本文自体の問題点については様々な方からご指摘がなされていますので、本文自体も見直して署名の取り直しをオススメいたします。
追伸.
署名としての効力は無いと言ってるだけで、オープンレター自体は有効も無効も無く「単なる数名の意見表明」と見なされる、というのが本文の趣旨です。
（私の書き方がまずい部分があったので、一部修正。文書全体ではなく署名部分が無効、という記載に統一します。ご指摘ありがとうございました）
僕がコインハイブを知ったのは冤罪で検挙されたモロさんと同じくGIGAZENEの海外記事紹介でだった。2017年後半のことだ。
その後、海外の超大手の海賊版サイトが導入したとか日本でもニュースにもなり知名度が海賊版サイトの悪名とともに広まった。
そして漫画村もコインハイブを導入して、さらに悪名がつくことになった。
2018年。それまで一部のまとめサイトなどでの範囲に収まっていた漫画村批判が、2018年は年初からマスコミや大手ネットメディアも名指しで取り上げるようになった。
その時期にコインハイブ設置したものだから、そうした記事ではコインハイブは漫画村批判にこれでもかと利用された。
その時にマスもネットも全てのメディアはコインハイブの解説をトレンドマイクロに求め、トレンドマイクロはコインハイブへの警告を出し続けた。やれCPU100%、やれ端末がぶっ壊れる等。
批判記事が量産されるとともに漫画村叩きの熱も高まる。それとともに各記事におけるコインハイブの解説も漫画村批判を煽るために怖さを増幅させるものになっていく。
初期のねとらぼの記事ではトレンドマイクロの解説として「ウィルスではありませんがトラブルになることがあるのでトレンドマイクロでは警告を出している」と穏当なコメントも掲載してるhttps://nlab.itmedia.co.jp/nl/articles/1802/20/news114.html
が、3月のNHKの記事になるとトレンドマイクロがCPU使用率が100%になる画面を見せる調査を元にコインハイブについて「アクセスするだけで利用者の端末で不正なプログラムが勝手に動きだすことがわかりました」と「不正」と断定して記述するようになりhttp://www.nhk.or.jp/seikatsu-blog/800/291202.html
4月にはテレ朝系のAbemaニュースではネットに詳しい弁護士がコインハイブについて「不正指令電磁的記録供用罪に問われる可能性がある」と違法行為と解説させるようになったhttps://times.abema.tv/articles/-/3978705
産経は漫画村記事でコインハイブは「北朝鮮の資金源」と書いた。
こうしたメディアの動きと合わせて、この時期Twitterでは何とか漫画村を利用させないために「漫画村にウィルスが仕掛けられてる」という投稿が拡散されるようになり、「コインハイブ＝ウィルス＝不正」という理解が高まる。
このようにメディアとSNSで「コインハイブ＝悪」という認識が根付いていく裏で、全国の警察がコインハイブ設置者の大量検挙に動いていた。NHKがこの時期に「不正なプログラム」と断定していたのも警察の動きを把握してのものだろう。
その後、漫画村は政府によるブロッキングを経て潰れ、それとともにコインハイブの話題も一旦終了する。
そして漫画村の記憶も薄れた6月に警察が「今年に入ってコインハイブで数十人を検挙したよ～」と発表し、高木浩光先生が「コインハイブで逮捕はおかしい」と批判の声を上げて流れが変わる。http://takagi-hiromitsu.jp/diary/20180610.html
高木先生はコインハイブが事件となった理由を「トレンドマイクロの暗躍」だとした。
漫画村はすでに潰れていたこともあり、以前に漫画村つぶしのためならとおかしいことをおかしいと言わずにスルーしていた人たちも一斉に高木先生に同調し「コインハイブは不正じゃない」と声をあげ冤罪救済のちからとなった。
B型作業所の職員は利用者のことを一人の人間ではなく一人の障害者としか扱わない。
重度の障害者ならば気にしないのかもしれないが一般就労をしてきた身としては障害者扱いをされる事で自分が自分では無くなり自己否定をしてしまい鬱状態に近くなった。
当たり前の事(作業をこなした、通所をした。など。)をするだけで物凄く褒められ、度を超えた評価をされる。
こんな事で謎の過大評価をされると自分は本当に無能な人間なのでは…と感じてしまった。そこで自己否定に入ってしまう。そして鬱へのループに陥る。
B型作業所に通所するだけで心が磨り減った。障害者である自分に怒り気が狂いそうになった。まだ理不尽な思いをしてでも障害者雇用で必死に社会にしがみついている方が人間らしく生きられると思った。
たとえ同じ無職でも趣味の健全なコミュニティで健常者と一緒にいる方が自分が自分らしく生きられるとも思った。
他に辛かったのは、障害者を見て障害者と一緒に作業する事で自分が本当に落ちる所まで落ちたんだなと感じてしまった事だ。
作業所の帰り道ずっと泣いた、自分が支援を受けている障害者であるという事は分かっていたが自分より無能な障害者を見るとここに居たら本当の障害者になると思った。
B型作業所は本当に心が壊される。職員は子供のような障害者である社会的弱者という扱いしかしてこない。
意を決して相談支援事業所に相談したが辞めるという決断はまだ早い、作業所と相談しなければ始まらないと言われた。
もちろん相談の場を持って自分が今まで感じた事を全てぶつけるつもりだがたとえ環境を改善するとかなにか案を出された所で絶対に通所するつもりはない。必ず自分の意見をぶつけてから辞めたい。
本当に、通所をしていたら頭がおかしくなる。あんな所に行ったら人間ではなくなる。
今騒がれてる件とは別に、技術的・社会的な興味としてどうすればネット署名で個人認証してなりすまし防げるんだろうね？
一番堅固なのはマイナンバーカードを使った公的個人認証サービスだろうけど、民間事業者が使うには個別申請で使用可能まで半年以上かかるようだ( https://www.j-lis.go.jp/jpki/minkan/procedure1_2.html )。そもそも日本在住者しか対象にできない。
民間ベースで「個人」を認証するのはすごく難しい。対面確認の上で鍵作ってもらえれば問題ないけど、非現実的。一部のサービスはこの方法使ってるけど限られた利用者だからできることだ。
よく使われている携帯電話番号を使った2段階認証は、端末の認証は出来るけど個人の認証はできない。
どうすればいいと思う？
将来的な基盤構築も含めてアイデアが聞きたいな。
https://note.com/ggkiev/n/n993a4ead8a17
いやあ、良いブログだった。
特に闇市に手を出すアホ呼ばわりのくだり。はてブでの煽り合いから殺人事件が発生したことを思うとはてブで煽って星を付けるのはよっぽど危うい。逆にメルカリで同人誌を売るからといって転売に関わることはない。サービス利用者として本気で内省すべきことだと思った。
「メルカリやTiktokは叩かれて当然の諸悪の根源」くらい認知が歪んでる人が少なくない。
はてなブログは使いやすいサービスだけど、はてなブックマークに目をつけられる可能性があるというのはメリットでありデメリットでもある。
ワイくんが気になっている大学院
ありがたい数々のお言葉をくださる教授がいる慶應義塾大学大学院政策・メディア研究科 は、
お笑いコンビ「ロンドンブーツ1号2号」の田村淳さんが「これからも学び続けます！」と慶應大学院修了を報告をしたことで有名ですね
田村淳さんの修士論文はまだ見れないけど見れるようになるといいですね見れるようになっていました ↓
⭐️なお、慶應義塾大学大学院政策・メディア研究科特別招聘教授で(内閣府)規制改革推進会議議長でデジタル庁有識者メンバーの夏野氏ありがたいお言葉の数々 ↓
夏野氏
「あと、言いにくいが、税金払ってない人の2倍の投票権を税金払っている人に与えていいと思う。どちらにしろ東京の人の票の重さは鳥取の半分以下だし。最高裁も2倍までいいと言ってたらしいしね。」
「国民に高いコストを払わせてお世話になっているくせに当然の権利のようにTPP反対デモしている農民を見ると、事実上倒産しているくせに解雇に反対するJALの組合とかぶる。どちらも既得権益を守ろうとしているだけで、決して弱者ではないことに注意」
「30年くらい先を見越すと、都会か地方か、ではなく、人口減少下のニッポンである一定の人口密度以下の場所に住むということはそこの公共サービスを維持するために莫大な税金が必要となり、ものすごく贅沢なことになるという認識を持たざるを得なくなる。」
↓
「人口密度の高い地域の電気や水道水、食料はどこの地域からのものでしょう？どれだけの恩恵を人口密度の低い地域に頼ってますか？
利用者が少ないからとせっかく築きあげてた鉄道は廃線になり、どこの地域にもあった学校も統廃合でスクールバス通学、最低賃金格差、人口減少に向かわせた政策です。」
「他人より稼げているのは社会システムによる富の分配の偏りの恩恵で、能力より役割ですよね。所得が少ない人は税金払ってないというのなら法治国家そのものが崩壊しますよ。教授は食料作り出せないでしょ。低収入農家をバカにしないで。」
↓
夏野氏「はあ。」
夏野氏「竹中さんに大いに期待する。竹中さんの明確すぎる論に反発する感情的な人たちが日本のガンなのだ。 / 英雄？悪玉？竹中氏に再び脚光 戦略特区メンバーの有力候補浮上」
夏野氏「今年選挙があるからだと思います。公平感？そんなクソなピアノの発表会なんかどうでもいいでしょ、オリンピックに比べれば。一緒にするアホな国民感情に今年選挙があるから乗らざるを得ない」
(「オリンピックで羽田の侵入経路が緩和されて五反田の上に（飛行機が）通るんだって。これに反対してる（人たちがいる）わけ」)
↓
夏野氏「その航路を開くときに、取り合えずB-2爆撃機でそのへん、絨毯爆撃したらいいよ。そいつら全員殺せ。いらねえよ」
YouTubeやTwitchなどのストリーミングサイトで気軽に配信を始められる「Open Broadcaster Software」（OBS）は無料で公開されている有名ツールの一つだ。同時接続1万人を超える有名ストリーマーやVTuberをはじめ、多くのゲーム配信者がOBSを利用している。
そこで気になるのは、OBSの開発はGAFAのような資金力をもつIT企業ではなく、世界中にいる「OBSをよくしたい」と思った一般人、ボランティアによって開発されていることをゲーム配信者が理解しているかだ。
例えば、TwitchやYouTubeの仕様に変更があれば、その仕様変更の影響を受けないようにボランティア精神を持つ一般人たちがOBSにおける影響範囲を調べ、必要に応じてOBSを改良する。
あるいは、特定のOSの特定のバージョンでOBSが起動できないような問題が発生した場合は、原因の調査と修正したバージョンの提供、アップデートの呼びかけをする。
配信をする上でつまづいたり、分からない点について利用者から問い合わせがあった場合、問題解決を支援するために回答をする。
こうした一連のメンテナンス、サポートが無償で行われているのだ。
メンテナンスをする人たちがOBSから去ったとき、自分自身でOBSを開発したり改良したりする自信はあるか？
ゲーム配信のためにOBSを利用して、視聴者からのスパチャやビッツ、サブスクで収益を上げているのであれば、OBSの開発、改善が持続するように
OBSの開発プロジェクトに対して率先して寄付をすべきではないだろうか。飯を食う分には困らない収益を上げているなら今すぐ寄付をするべきではないだろうか。
ゲーム配信者が自分自身のゲーム配信を持続させるため視聴者から寄付を募っているのと同じく、配信ツールもまたツールの提供を持続させるために寄付を募っているのだから。
