  |
はてなキーワード: バランシンとは
だったらサブカル憧れの若者をじゃんじゃん食いつぶして「映画館バイトってヤバいんだって」みたいな噂が常識レベルになるくらいまで循環させるんだよ
そうして映画館ビジネスの悪評がサブカル趣味の市場規模を毀損するレベルになれば、やっとビジネス考えてる側もプカプカ煙草吸いながら「そろそろ変わらないとダメですなぁ」とか考え出す
逆に、そこまで行かないのならその過重労働はビジネスとして妥当な範囲だってことが市場原理によって証明されてしまう
グチグチ言ってるけど実は他業種と比べたら全然楽だから流入が絶えないんですよって可能性も市場原理によって取り込まれてるからね
食いつぶされないように耐えることが芋虫の悪あがきなんだよ
他の人のこととか考えず、自分にとってきついならやめる、それが一番市場原理のバランシング機能をきちんと働かせる、スマートなやり方なの
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
・本当です。特に太陽光発電事業者（自宅の上に乗ってる奴を除く）なんかはお金目的の方がほとんどです。
・バランシンググループという名前でそういうことが行われております。誰でもJEPXから電気を買えるわけでは無いのでノウハウのない方々は集まってわかる人に買ってもらってる感じです。
・もうしてます。
その流れでインバランス料金（簡単に言うと買い漏れた方向けの最終料金）に200円という上限が設けられるなどの措置がありました。
・最終保証契約という電力会社が潰れた場合のセーフティーネットのようなものもあるのでその論調はあまり効果的ではなくされないと思います。
・十分あり得ます。結局日本は島国なので資源問題に弱いです。大陸であれば気化ガスのままパイプで運べるものをタンカー輸送量の問題からわざわざ冷やして液化させて運んでいるので、そのような状況にすでになっており、昨年秋に比べるとかなり値上がりしてますが、購入する以外の選択肢がありません。
イギリス人のブルマーの調査から、ずいぶん遠くまで来た。脱線に脱線を重ねてきた結果だ。しかし、昔から気になっていたので、バレエのチュチュ（ふわっとしたスカートみたいなあれ）についても調べておこうと思う。子どもの頃に、やっぱりこれがエッチだと思ったからだけではない。どんなことでも、疑問を持ったならば調べることは大切だからだ。それに、こういう素朴な疑問だけれども面と向かって聞きにくいことについて調査し、書き留めておくことは、誤った憶測に対抗する上での価値があると信じている。
これは、単純にお尻フェチだとかパンチラ萌えだとかだけの話ではない。僕たちの欲望がどのような仕組みになっているのか、そして欲望を喚起するシステムがどのように働いているのかを理解することは、逆説的に欲望の暴走をコントロールすることにつながるはずだ。言い換えるならば、社会が求めている女性像／男性像から自由になる手段であり、政治や広告から発せられる都合のいいメッセージから身を守るすべにもなる。
前置きが長く、堅苦しくなってしまった。どうか肩の力を抜いて読んでいただきたい。
https://tutusthatdance.com/blogs/faq/parts-of-a-tutu
これは、クラシック・バレエのチュチュの基本的な構造である。pantyと書かれている項目に、「ここにフリルが縫い付けられる」と書かれている。要するにお尻の曲線はそこまで丸見えにはならないのである。
しかし、このフリルにもいくつか種類がある。英語版wikipediaのtutuの項目には、現代のチュチュとして、次の4つが挙げられている。
短く硬い、釣り鐘状のスカートを持ったチュチュ。通例、パンケーキ・チュチュより長い。ドガの作品で多く見られる。
これだけを調べるのにも、意外と時間がかかった。当たり前だが、カタログの写真では普通、スカートの中まで写さない（というか、写すべきでもないだろう）。「inside pancake tutu」では、こういう資料は見つけたが。
https://www.pinterest.jp/pin/560487116124411506/
http://4.bp.blogspot.com/_Ozo7z2zkqWs/S-i2wVfcR1I/AAAAAAAACYQ/zDek9ewzWno/s1600/platter.jpg
世の中には私と同じような疑問を持つ御仁もいらっしゃるようである。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11205496201
さて、ウィキペディアのチュチュの項目を見ると、「ツン」というパンツ部分を指す言葉が出ている。引用すると「ツン（Tune）はスカートと一体になったチュチュのパンツ部分。……（中略）……構造的にロマンティック・チュチュには存在せず、ロマンティック・チュチュではバレリーナは下着としてステージ・ショーツを別途着用する（広義では、これもツンと称する場合もある）」となっており、幾分ややこしい。
また、その下着の項には「チュチュを身に付ける際は下着として薄手のキャミソールレオタード状をしたバレエ・ファウンデーションを着用する……（中略）……色はほとんどの場合ベージュ系である」との記載がある。
要するに、レオタードみたいになっている場合は普通に下着を身に着けるし、パンツ部分がチュチュと分かれているものでも、オーバーパンツをはいているわけである。当たり前ではあるが。
ロマンティック・チュチュは1832年、「ラ・シルフィード」で初めて案出されたらしいので、先ほどのツンについての記述と比べれば、現代につながるフリル付きの見せパンの起源はそこにある、と判断できそうである。ただし、英語版wikipediaには「ツン」の項目はなかった。
また、興味深いのは注釈の「ただし、アンダースコートとは異なり、ツンのフリルは横方向よりも縦方向に付けられる場合が多い」という個所だ。確かにさっきの画像でもそうなっていた。フリルの趣味の時代的変遷だろうか？
Wikipedia英語版のballetの記事でバレエの歴史を振り返ると、拾い読みだが、次のような流れになっている。
まず、バレエの起源はルネサンス期の宮廷でのダンスにさかのぼる（ルイ14世も踊ったほどだ）。それが徐々に劇場で公演されるようになった。
17世紀の頃は、女性の衣装は重たい生地と膝丈のスカートで構成されていて、動きやしぐさを出すのが難しかった。しかし、これでは動きやジェスチャーに制限ができてしまう。これが18世紀になると、スカートは地面から数インチの高さになる。色はパステルカラーが主流となり、さまざまな飾りが華やかでフェミニンなスタイルを強調するようになる。現在踊られているバレエでは一番古いものがこの時代で、「ラ・シルフィード」「ジゼル」が知られる。以下は18世紀の絵画だ。
https://upload.wikimedia.org/wikipedia/commons/4/49/MarieSalle.jpg
19世紀初頭には、身体にぴったりとフィットした衣装が用いられるようになる。具体的にはコルセットが導入され、身体のラインが見えるようになった。また、花冠、コサージュ、宝石などの小道具も導入された。クラシック・バレエでは「眠れる森の美女」「くるみ割り人形」「白鳥の湖」がよく知られる。次の画像では、少しスカートが短くなっているのが確認できる。
https://upload.wikimedia.org/wikipedia/commons/7/72/Giselle_-Carlotta_Grisi_-1841_-2.jpg
そして20世紀、バレリーナのスカートは膝丈のチュチュとなった。正確なポワント（足の技）を披露するためである。舞台衣装の色も鮮やかに変わった。20世紀の作品としては、「牧神の午後」「春の祭典」が名高い。1910年の写真を貼る。
https://en.wikipedia.org/wiki/Ballet#/media/File:Agrippina_Vaganova_-Esmeralda_1910.jpg
https://en.wikipedia.org/wiki/Ballet#/media/File:Grace_in_winter,_contemporary_ballet.jpg
画像をご覧いただければ、スカート丈がどんどん短くなっていくのがよくわかる。
さて、結論を述べよう。Wikipediaによれば、衣装が重いと細やかな表現ができないのと、脚を使ったテクニックを見せるようになったため、スカートが短くなったようである。
ちなみに、海賊というバレエでは、へそ出しの衣装も存在しているらしい。確かにbunkamuraに食事に行ったとき、バレエの衣装を展示していたが、そこにへそ出しファッションの衣装があったことを思い出した。バレエにしては大胆だと思った覚えがある。
ブックマークのコメントはありがたく読ませていただいており、不快だというお叱りも真摯に受け止めたく思っている。確かにパンツじゃないのにパンチラに見えてしまって欲情する人がいるってのは幾分デリケートな話題であり、増田ではないとやりづらい。また、どの程度ユーモアを交えて描くか匙加減も難しい。それを受けて、少し考えておきたい。
僕は割と美術鑑賞が好きで、ドガの作品も好きなのだが、その背景を知っていると、手放しで褒めることはできない。再びウィキペディアから引用しよう。日本語版からだ。
エドガー・ドガがバレエダンサーを描いていた頃、バレエダンサーは現在と違い地位の低い人が身を立てるためにやっていたため、バレエダンサーは蔑まれていた。主役以外のダンサーは薄給で生活しており、パトロン無しでは生活するのが困難だったとされる。パトロン達は当然男性が多く、女性ダンサーを娼婦の如く扱っていたと言われる。かくして、フランスのバレエ界から男性ダンサーはいなくなり、フランスのバレエは低俗化することになる。
もちろん、どんな事情があったとしても、弱い存在を表現しようとしたドガの作品の価値は損なわれない。しかし、僕は問わねばなるまい。スカートが短くなったのは、果たして本当にダンサーの意志だったのか、と。そして、女性が身体を見せるようになった流れの誕生は、観客も共犯だったのではないか。こうして性的好奇心を持ってしまう僕も、同じではないか。
もちろん、過去のことだからわからないことが多いし、究極的には真相は明らかにならないかもしれない。女性が美しい肢体を見せたいと思ったとしても、それは男性が主流だった時代の文化の中で育ったからそう思っただけなのかもしれず、どこまで本当に主体的に判断したかの判断は難しい。とはいえ、過去の人間が何を考えていたのか、それはどの程度自分だけの決断によって決められたことか、証拠が不十分なままでこちらが断定するのは越権行為だろう。
しかしながら、現代に生きる僕らは、自分が主体的にしていると思っている行動の多くも、無意識のうちに同時代の文化に支配されていることには、自覚的であることが求められるだろう。欲望の仕組みを知るとは、そういうことだ。読者諸氏も、自分のフェチの起源を考えてみると、きっと得るものがあると思う。
身体を使った表現と性の問題は扱いが厄介だ。ただでさえスポーツは厳しい師弟関係でパワハラになる危険があるうえに、新体操などの身体表現のあるスポーツでは、性暴力にまつわる訴訟は絶えない。
スポーツではないが、芸術と性も深い関係にある。どちらも人間の根源に根差しており、安易に善悪を論じることが困難だ。バレエも例外ではない。師弟の間で身体が親密に触れあい過ぎて恋愛関係になってしまう例がある。美しさへの憧れが恋愛感情や欲望と混同されることだってある。現に、男女だけでなく、ディアギレフとニジンスキ―の同性愛関係もよく知られている。こうしたことが、後から振り返ってみれば不適切な関係だった、師弟の力関係を利用していた性暴力だった、と判断されることにもなるかもしれない。とはいえ、これらは個々の具体例によって判断すべきだ。正直なところ手に余るし、多くの人の人生について書くことになる。ここでは語りつくせない。
今までこうした社会的な側面から女性のファッションの歴史に触れてこなかったのは、元々は衣装そのものの歴史を書きたかったのであり、社会の反応まで行くと本題がその中に埋もれてしまうことを恐れてのことだった。しかしながら、ドガが好きな自分としては、いい機会なのでここで一言断っておく必要がある、と感じた次第である。
何を好きになっていいし、対象にはどんな感情を抱いてもいいと思うけれど、歴史や経緯は知っておきたい。それが、芸術やスポーツに励む女性に性的な魅力を感じてしまう僕なりの折り合いのつけ方だ。そして、盗撮などの犯罪には断固反対する。
今回の調査では、見せパンの起源と推測される年代までは確認できた。しかし、細部は依然として明らかではないため、何らかの形で補完したい。
そこから、メイド服、またはロリータ服における、見られても恥ずかしくない下着について調べるかもしれない（知識がほぼないのでとんでもない誤解かもしれない）。または、キャバレーでのラインダンスやバニーガールについて、になるかもしれない。あるいは、再びブルマーに回帰するかもしれない。それは明日の気分次第だ。
とはいえ、しばらくは休みたい。自分の欲望やその起源について考えることは有意義であったし、文章化することで過度のブルマーへの執着やフェティシズムは手放すことができたからだ。一段落した感じがある。この言語化は妖怪に名前を付けて対処法を見つけたようなものだろうか。どろどろ、もやもやした不可解なブルマーに対する欲望が、知的なものとして把握できるようになった。
つまり、増田に欲望を垂れ流すことで、落ち着くことができた。知識が増えて勉強になったという肯定的な意見、ねちっこく不快だという否定的な意見、どちらも自分の姿を客観的に見せてくれた。すべての意見に対して、ここに感謝の言葉を述べたい。
ttps://en.wikipedia.org/wiki/Miss_La_La_at_the_Cirque_Fernando#/media/File:Edgar_Degas,_Miss_La_La_at_the_Cirque_Fernando,_1879.jpg
JMSにおいて不人気職と呼ばれるキャプテンの考察をテキトーにしてみようかと思います。
ちなみに著者はハードボスの固定PTに参加する程度の火力です。
ベースはゆかりサーバーの対ボス職業強さ表【ゼロ】 - メイプルエアプレイヤーの記事を参考にしてます。
海賊の旗の周辺にいるグループメンバーのAPを直接配分した全ステータス10+d(x/2)%増加、モンスター防御率10+d(x/2)%減少
Lv.30(MAX)でALLステ25%・防御無視25%上がる キャプテン唯一のパーティ支援スキル
30秒しか持たないけれどLv.30だとCTが30秒になるので、使いやすくなります。
ちなみにこのスキルが使えるのはバイパー・キャプテン・キャノンシューター・ジェットのみ
MAXまで上げといたらグル員に喜ばれるから上げとくべし。これ以外グル員に役立つものもないし。
固有バインドはありません。
5次スキル共通スキル・よろず・ルシードイヤリングを使いましょう。
ただし、一度肩代わりしたら再度出し直すまでは肩代わりした状態異常は解除されないので、
早く解除したいときは戦艦ノーチラスでCT減少させましょう。(後述）
無敵に関しては特にないので、カメカメを使うのが無難でしょう。
ちなみに3rdVで追加されたノーチラスアサルトに無敵効果があるはずなのですが、
移動スキルは冒険家の中でも1,2位を争うレベルで揃っていると思います。
但し、どのスキルもクセが強いので慣れるまでは大変です。
かなり飛ぶので調整がちょっと難しい。
後ろ方向に跳ねて移動するスキル。こちらもテクニック面でダッシュの次に重要です。
連打可能なのでFJと組み合わせるとかなり長い距離を移動できます。
敵の攻撃（ウィルの足とか）を瞬時に避けたりもできるので、扱えるようになってるといいと思います。
ウィンズ単体で使用すると、キーダウン中は空中浮遊することができますが、
ダッシュと組み合わせて発動することによって空中でもスキルを打つことができます。
但し、ダッシュと組み合わせた場合はキーダウンでの浮遊できません。
ダッシュ＋ウィンズ＋攻撃スキル(キーダウンスキルを除く）を組み合わせて使うと、
空中で硬直なく攻撃が可能なので、もはや必須テクニックと言っても過言ではないです。
狩りでもボスでも非常に役立ちますので、出来るようになっておきましょう。
船体攻撃：一定時間ごとに600+24*x%のダメージで6回攻撃する船体攻撃が7回発動
一斉射撃：一定時間ごとに300+12*x%のダメージで12回攻撃する射撃が36回発動
3rdVにて追加された自他職認める瞬間火力
このスキルが追加されたことによってキャプテンもまだマシな職業になったんじゃないかと思います。
あまり移動しないタイプのボスに対しては多彩な設置型召喚スキル達が攻撃してくれるので、ダメージソースとなります。
所謂暴風系キーダウンスキル。ハイパースキルで射程距離を伸ばせます。
このスキルはスキルバランシングにてコマンドが新たに追加されています。
| コマンド | 効果 |
|---|---|
| スキルキーのみ | 射程距離が伸びるがスーパースタンスが適用されない |
| スキルキー＋↓キー | 射程距離は縮むがスーパースタンスが適用される |
縦横方向に広いのはもちろん、スキル連打中に移動(ウィンズ)が可能であることからかなり広範囲に攻撃を当てられます。
パッシブ効果：デッドアイがクールタイム中ではない場合、射程距離内の最大12体をそれぞれ照準し始め、正確に照準された時にデッドアイを使わなければ照準が解除されて一定時間後再び照準開始
アクティブ効果：MP850消費、照準してる敵を800+32*x%のダメージで6回攻撃、追加クリティカル率100%
正確に照準されるほどさらに大きいダメージを与えることができ。最大3倍まで増加
スキル使用時、攻撃を受ける敵がスキルの最大攻撃可能なモンスターの数より少ない場合は1体あたりの最終ダメージ4%増加効果
敵(最大12体)に対して自動的に照準を合わせ、キーを押すと照準が合っている敵に対して攻撃を行うスキルですが、
一度照準されて解除されるまでに攻撃を行えば、画面外でも攻撃が可能です。
ドリブレで例えると、ワープ前に敵に照準を当てておいて、ワープ先で攻撃なんていうことも可能です。
しかも最大照準の状態で攻撃するとダメージが3倍まで上がるので、火力面でも期待できます。
狩りでも優秀なので、5次以降の狩り効率はなかなか良い方だと思います。
.....
攻撃範囲が広いので遠くから攻撃しておけばいい良い職業だと思いがちですが、
攻撃を受けると4*x%の確率で、15+3*x秒間ダメージ 5+x%上昇、最大HPの一定確率でダメージを負わせる攻撃にも発動。
つまり、攻撃をくらい続けないと火力を維持できないということです。おかしいでしょこれ。
耐久性がない・無敵スキルなし・対複数スキルが少ないといった点で劣ると思います。
火力面はノーチラスアサルトの登場でかなり貢献できるようになりました。
キャプテンは単一相手かつ上下移動しないボスが得意分野だと思います。
MP 350消費、320+4*x%のダメージで最大15体の敵を7回攻撃、クールタイム30秒
使用するとサモンクルー、ラッキーダイス、バトルシップボンバーの残りのクールタイムが50%減少
クールタイムの間キャプテンディグニティの最終ダメージ30%増加
CT管理のキーとなるスキルで、使用すると他スキルのCTが50%減少します。
この他のスキルのCT減少で一番重要なのが、4次スキル：バトルシップボンバーです。
MP 150消費、30秒間召喚され一定の間隔で砲弾発射、発射された砲弾が敵に当たると爆発し、最大6体の敵を3回攻撃、最大2台まで召喚可能｡
ドンツルレス：230+3*x%のダメージ、普通の攻撃速度、普通の射程距離
ブラックバーク：400+3*x%、遅い攻撃速度、普通の射程距離
シュリンツ：105+3*x%のダメージ、速い攻撃速度、普通の射程距離
ジョナサン：190+3*x%のダメージ、普通の攻撃速度、長い射程距離
戦艦ノーチラスでCTを減少させることによって、バトルシップボンバーを2体出すことが可能となります。
召喚系スキルもボスダメ等のダメージが乗るため、火力ソースとして大きく影響します。
更に戦艦ノーチラスのCT中は4次スキル：キャプテンディグニティの最終ダメージが増加します。
ラピッドファイアの1発分でも発動するため、実質手数2倍という驚異的なスキル。
.....
最高火力を出し続けるには戦艦ノーチラスのCTが切れたときに即打ち直しする必要があります。
バトルシップボンバー→戦艦ノーチラス→バトルシップボンバー(2体目)→戦艦ノーチラス→......
戦艦ノーチラス自体のCTが30秒で本気でCT管理しようとすると忙しすぎるので、正直あまり現実的ではないと思いますが、
できたらかなり火力は出せると思います。
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。
Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
触れない話: 事実上全然稼働しなかった CTO 、北の将軍様
パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
595 ： アメリカンショートヘア(dion軍)[] ： 投稿日：2013/03/12 09:28:40 ID:2kRAKMKnP [10/10回(p2.2ch.net)]
ネトウヨはロシアやインドと同盟や通商関係を強化すべき、と主張する人間を在日認定する。
ネトウヨは故障だらけで低スペックのＦ３５でなく心神開発を続けるべき、と主張する人間を在日認定する。
ネトウヨは中国の中華勢力圏構築をバランシングする橋頭堡の為に、台湾・韓国と軍事関係を強化する、と主張する人間を在日認定する。
ネトウヨはＴＰＰの次に来る日米経済調和対話に反対する人間を在日認定する。
ネトウヨは従軍慰安婦問題は、アメリカと中国共同の日本封じ込め戦略で、安倍は米中に屈服した、と言う人間を在日認定する。
アメリカ「日本は改革するべき。従軍慰安婦と南京大虐殺は日本の大罪。 ニヤニヤ」
中国「俺もアメリカに賛成。日本はＴＰＰに入って改革するべき。従軍慰安婦と南京大虐殺はアメリカも言っているぞ！ｗニヤニヤ」
馬鹿「ＴＰＰに入って改革してチョンを倒せ」
あくまでも仮定で、わかりやすいように、ユニクロを例に取るけど、あくまでもイメージであり、ユニクロのことを言いたいわけではない。
３ 人件費の関係で 『同じ利益率』 ならユニクロのほうが安くなる
４ よって、ユニクロは他社と同じだけの利益を得るが、価格は下落する。
５ しかし、労働が海外に移転しているので、国内の失業率は上昇する。
７ 反面、海外の失業率は低下し人件費が向上するのでインフレ傾向になる。
しかし、このデフレとインフレのセットは、通過問題が問題を起こしているわけでも、金融問題が問題を起こしているわけでもなく
単に、労働単価の差が『是正』されて、２つの国の物価差が０になるようにバランシングの力が働いているだけである。
類例では、内外価格差があると並行輸入が発生して、安い海外版が売られるようになり、物価の差が縮まる力が働く。
つまり、これは世界レベルでは、デフレとインフレがセットで起きている現象なので日本が単独で金融政策をいくらやっても
また、この現象は単なる競争原理であって、デフレとよく似ているがいわゆる、過去言われている金融が原因のデフレではない。
この状況下でインフレを引き起こすと、内外価格差が更に開くので、さらに大きなデフレの力がかかる。
そして、さらにさらに大きなインフレを起こすと、さらにさらに内外価格差が開き、 更に大きなデフレの力がかかる。
かけたインフレ圧力と、同じだけのデフレ圧力が働き、国力だけが一方的に減少していく。
という仮定はどうだろうか？
