はてなキーワード: TARとは
・主人公が美しい、おしゃれ
主演のケイト・ブランシェットが美しく、演技も素晴らしい。あとキャラクターとしてファッションセンスが良くて、シンプルながら見惚れる着こなし。ファッション誌の映画レビューでも褒められるような感じ。しかしこの美しさは男社会を生き抜く鎧だったのかもしれない。
ほとんどBGMが無く、生活が描かれる場面での静けさと、オーケストラが演奏する時の大音響との巨大なギャップ。その音楽の巨大な力を、主人公が1人で制御している全能感。音によって、マエストロが手に入れた権力が伝わってくる。
・人間の強さと弱さが描かれる
オーケストラの世界で世界最高の指揮者にまで登り詰めた主人公、その情熱と才能は本物。タフで知的で社交的。でも一方で、傲慢で感情的。その人間的な弱さの部分が、徐々に自分に跳ね返ってくる。破滅が近寄ってくる。その演出が怖い。くる、きっとくる。
・よく練られた構成
開幕、よく分からないシーンがあり、スタッフロールがはじめにあったり、長いインタビューで主人公が語り続けたり。なんだこりゃ?大丈夫なのか?という不安からはじまりつつも、最終的には意図が分かって腑に落ちる。ただ、上映時間はけっこう長い。トイレに行きたくなるかもしれない。
見終わった時に、どんな顔をすればよいのか良く分からなくなる。自分は何を見たんだ?この感じ…今まで見た何に似ている?ハッピーなのか、バッドなのか。ハッピーだとして誰にとっての?何かものすごく今の時代を捉えていつつ、神話や寓話を見たようでもある…よく分からない。つい後で思い出して考えちゃう。つまり癖が強くて面白いってことか。
-----------------
★主な登場人物
-----------------
-----------------
シャロン(ターの内縁の妻・ベルリンフィルのコンサートマスター)
-----------------
フランチェスカ(ターの元愛人・指揮者見習い・副指揮者の地位を狙っているが現在はターのアシスタントに甘んじている)
クリスタ(ターの元愛人・指揮者見習い・現在はターに追放され(?)ニューヨーク在住)
-----------------
-----------------
★シーン
-----------------
プライベートジェット(ベルリン→ニューヨーク)で眠るターを撮影しているのはフランチェスカ。チャットの相手は多分クリスタ
-----------------
冒頭のクレジットの背後で流れるのはターの実地調査先のペルー東部ウカヤリ渓谷の先住民の歌(この調査にはフランチェスカとクリスタも同行していた模様)。
-----------------
レコードを床にばらまいているシーン(ターの仕事部屋?)の足はおそらくフランチェスカ。
-----------------
講演会後に話しているファンの女性とターはおそらくこの夜密会している(女性のバッグが後にターの持ち物として出てくる)。
-----------------
指揮者がヘッドフォンをしているのは映像と合わせるためのガイド音を聴いているから。なおこのシーンはモンスターハンター(テレビゲーム)の観客コスプレ演奏会と思われる。
-----------------
-----------------
クラウディオ・アバド…ベルリンフィルの元首席指揮者(故人)。
バーンスタイン…指揮者(故人)。愛称「レニー」。ターの師匠(という設定)。テレビ番組(ヤング・ピープルズ・コンサート)などを通して一般庶民にクラシックを普及した。
ジェームズ・レヴァイン…指揮者(故人)。セクハラ等の女性絡みのスキャンダルで有名。
シャルル・デュトワ…指揮者。セクハラ等の女性絡みのスキャンダルで有名。
マイケル・ティルソン・トーマス…指揮者。愛称「MTT」。
ムスティスラフ・ロストロポーヴィチ…大御所チェリスト(故人)。ロシア人。
ジャクリーヌ・デュ・プレ…女流チェリスト(故人)。多発性硬化症で早期の引退を余儀なくされる。
ダニエル・バレンボイム…指揮者/ピアニスト。過去にデュ・プレの恋人だったことがある。
-----------------
★トリビア
-----------------
フリーボウイング…通常、弦楽器の同一セクションでは統一する弓のアップダウン(引き弓・押し弓)を奏者個人の判断に任せること
-----------------
ベルリンフィルを演じている(?)のはドレスデン・フィルハーモニー管弦楽団。ホールはドレスデン文化宮殿。
-----------------
ほぼ全編に渡って音声は同時録音。つまりブランシェットは実際にバッハを弾いて、マーラーを指揮をしている。そしてオルガ役のソフィー・カウアーは実際のプロのチェリスト。
-----------------
-----------------
最近上映され始めた映画「TAR」は、ものすごく「はてブ向けのテーマ」を扱っている。
世界最高峰のオーケストラで指揮者を歴任し、クラシック界の最重要人物となったレズビアンの主人公、リディア・ターが、音楽教育やオーケストラ運営の中で徐々に問題にぶつかっていく。
そこではSNSによる告発、ある種のハラスメントや人間性の消費が描かれており、その解像度が高い。
主人公を写し続ける美しい画面は主観的で、リディア・ターの真摯に音楽と向き合う姿勢と、権力者として傲慢に振る舞う姿勢が描かれる。きっと、見る人によってターへの共感のレベルが変わり、物語全体が理不尽にも、因果応報にも、新たなる希望にも感じられる。
客観的な描写が省かれることにより、誰がどういう心境で、実際に何が起こったのか、確定をすることが難しい。見る側の理解に委ねられている。
ジェンダーやハラスメントの問題も、本質的なテーマというよりは、より普遍的なストーリーのためのスパイスに過ぎないのかもしれない。
なんでみんないつまでも100年以上も昔のタイプライターの成れの果て、みたいなキーボードをカタカタ叩いてコンピュータ操作してるの?
使いこなすには習熟が必要って、そりゃそうかもしれないけど度が過ぎてないか?
特にCUIがいけすかない。DOSプロンプトを初めて見た日から今に至るまで、あんな不親切なインターフェースを一度だって良いと思ったことはない。
$とかC:\とかなに?適当に文字を打ってもエラーしか出ない。使われるのを拒絶しているようにしか見えない。
ゲームで言うなら1980年代のテキスト入力型アドベンチャーみたいなレベル。コマンドを全部覚えてないと何もできないクソゲー。
多分もうおっさんしか知らない。いまどきそんなゲームはないだろ?つまりそれだけ遅れてるんだよ。
使いやすいようにカスタマイズするのが当たり前?だったら最初からその使いやすい状態で提供してくれよ。不親切なまま提供しないでくれ。
ややこしいところはコンピュータでよしなにやってくれよ。いまどきのコンピュータの処理能力はすごいんだろ?ユーザーがわからない部分はちゃんと誘導してくれ。
お前のレベルが低い?おう低いよ。
でも、コンピュータってのはあまたの人類を幸せにするために作られてるんじゃないの?
CUIを使うのはプログラマみたいなIT関係の人間で、高いレベルが要求されるというのは一定の説得力はあるかもしれない。
でもな
不当な難しさをそこここに感じるんだよ。
ありとあらゆる前提や約束を覚えてないとまともに使えない環境は、たとえプロ向けでも俺は環境とすら呼びたくない。
ヘルプを見ろ?読んでるよ。ヘルプ読んだだけで使える人間がどれだけいるんだ?しかもどれだけヘルプを読んで覚えないといけないんだ?
コマンドラインオプションも訳がわからない。ハイフンが1つだったり2つだったり、$ tar xvfとかなんだよ。毎回ヘルプ読まないと使えやしない。
慣れるほど使い込んでいるユーザーばかりだと思わないで欲しい。
GUIでは右クリックですぐにメニューが出ることが多くて100万倍マシだが、あれだって「右クリックする」というお約束があっての話で最適解からは程遠い。
ものを使うのに大事なのは機能そのものであって、使い方はもっと然るべき自然な誘導があるべきじゃないのか?
特別にHHKBをけなす意図はないが、無刻印キーボードとか最たる例だ。
なんだありゃ?既にUIであることすら放棄してるだろ。旧時代の複雑な飛行機のコックピットですら各部に名前くらい付いてるぞ。
あれを日常的にありがたがって使ってる人間が「あらゆる人間が使いやすいものを作る」のを目指すのはなにかの冗談にしか聞こえないんだよ。
それとも、高尚な人間が下々の無知蒙昧な人間に使いやすいものを提供してやろうって感じなのか?
俺も少しはコンピュータを使って飯を食ってるが、そうじゃないと思いたいんだよ。
コンピュータの都合でグラフィックが使えない環境ならテキストベースになるのはしょうがない。
でも、しょうがないで終わらないでほしいんだよ。しょうがなくない環境でも人の都合で使ってる場合も多いよな?
今を最高とか思わずに、なんとかそこから進む意思を持ってほしいんだよ。
文字列を延々と眺めてカタカタターンッ!てのが格好いいと言う時代はさっさと終わって、次の時代になってほしいんだよ。
この話の続き
systemd-nspawnに移行した
以下詳細とか雑記
docker commitもdocker diffも使わないし、要らない
要らないだけならまだしも、aufs、overlayfs周りでトラブル可能性がありむしろ邪魔
イメージの差分管理はファイルシステムの層でやるのが素直でコンテナ管理にくっついてるのに違和感がある
Docker特有の機能をフルに使ってる奴ならまだしもコンテナ動かすだけなら何使っても変わらねーよw
Docker Hub からイメージダウンロードしてtarで解凍すりゃ良いだけじゃねーか
composeだって容易にコンバート可能だし、composeで何が起きるかわからない状態で本番運用とか口にしないで欲しい
実際systemd-nspawnの今でもベースはDocker Hubから拾ってきてるし、Docker使ってる奴との受け渡しも問題ない
やりかたは runc.io のGetting startedでも見れば?
Docker hubでよくわかんねーイメージ落とすときに、出所がクリアになるってメリットだけだなこんなん
取り急ぎansibleでセットアップは済ませてる
コンテナにしたからプロセス管理は違う方法でやります→supervisorで云々→めんどくさいだろ!
じゃあ1プロセス1コンテナにしてマイクロサービスにします→本当に便利それ?管理できる?
ログの管理は?logrotateは誰がやる?データボリュームはどこにする?みたいなアホみたいな検討し始めたときに俺は会議室を出た
「いや今はこれが主流で流行ってるから便利です」みたいな事言ってるバカが居て殴りたくなった
「毎週、毎週swarmが壊れたバージョンアップで再起動だのと余計な仕事増やしやがって、いつまでDocker社のβテストに付き合うつもりだクズども」
とは言えないので
「今の状況は前よりも運用負荷が高い状況みたいなので、systemd-nspawn等のシンプルなものに代替できないか検討してほしい」
と言ってなんとか説得
(結局半分以上は俺が対応したが)社内のクリティカルな部分のDockerは全部廃棄した
普通に起動して、普通に終了できる。コンテナの中なのにそれを意識しないくらい普通に起動する。
aufs,overlayfs等の差分管理しなければそれに付きまとう問題もない(overlayfsとか使うこともできる)
自動起動も設定もコマンドもコンテナ内だから〇〇しなきゃダメみたいなやつが無くなって、ものすごく安定してる
Dockerも--privilegedつけてinitからrunすればいいって?糞不安定だし、権限多すぎだろ?capabilitiesを適切に設定しろだって?
一生やってろバーカ
結局のところ本当にこれ便利になったんだっけ?って聞かれて理由を言える奴じゃないと何をやってもダメってことが分かった
これはDockerに限らず全部そうだと思う
QiitaとかにあるDockerでこんな素晴らしくなったよって記事の大半は本質を見失った馬鹿記事
楽になるどころか厄介事を+1してるだけ
とりあえずこっちはDockerのゴタゴタに振り回されなくなって良かったよって話
2010年ごろにニコニコ動画上で有名になったしょぼんのアクションってゲームがあるんだけど今どうなってるのか調べてみた。
そうしたらとんでもないことになっていた。
結論から言えばあからさまに怪しいデベロッパーが二次配布のソースコードを使って
itunes.apple.com/jp/app/shobonnoakushon-orijinaru/id894330337?mt=8
www.gatobros.com/
play.google.com/store/apps/details?id=com.gorkaramirez.syobonactionhalloween
www.pipletas.com/syobon/syobon.html
デベロッパーは『Gorka Ramirez Olabarrieta』というらしい。 ドメインWhoisガード適応済みで情報漁れず。
で、サポートURLのページをよく見るとOpenSource扱いになっていた
Original Source. Ported by @jezng using Emscripten.
sourceforge.net/projects/opensyobon/
Mathew Velasquezと呼ばれる人物が作者に許可無くSourceForgeにアップロードしたようだ。
sourceforge.net/u/twoscomplement/profile/
で、SourceForgeのプロジェクト開設日が下記のとおりになっているが
Registered 2010-05-16
原作者のサイトにはもっと過去の時点でゲームが公開されている。下記のInternet Archiveのもの。
wayback.archive.org/web/20091223043445/http://www.geocities.jp/z_gundam_tanosii/home/Main.html
このSourceForgeのプロジェクト、再配布人が下記のライセンスで公開している。
www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#DoesTheGPLAllowMoney によると
としている。
SourceForgeに公開されているプロジェクトがGPLv2で公開されているので、どうやらスマホアプリとして登場したようだ。
が、まずこれ色々と問題がある
プロジェクトで配布されているソースコード内にはDXライブラリがそのまま含まれているが、規約を守っていない可能性が高い。
dxlib.o.oo7.jp/dxlicense.html より引用する。
<<DXライブラリのライブラリファイルやソースコードの再配布について>>
DXライブラリのライブラリファイル( 拡張子が lib や a のファイル )や、プログラムソースファイル( DxGraphics.cpp や DxLib.h などのファイル )を配布する場合は一部、全部問わず
クレジット表示は探した限り見つからなかった。検証ファイル:SyobonAction_v0.9_src.tar.gz
なお、作者のサイトに商用利用に関する規約が無いとはいえ、さすがに普通に連絡するべきではないだろうか?
(配布ソースコード内には改変可という言葉はあるが商用利用可とは書いていない。)
なお、実行ファイル形式で配布されている物の英語のReadMeには原作者のクレジットなし。
どうやらゲームファイルとソースコードが転載されたようだが、少々違和感がある。
Internet Archive内にあるソースコードとSourceForge内のソースコードが違う。
tiku氏のそのまま配布するなを遵守したのだろうか? (配布されているソースコードには日本語が混じっているので非常に怪しいけど)
ただ、言えることはしょぼんのアクションがスマホアプリとして公開されたのはGPLv2辺りのライセンスになっていたからだということ。
ここまで書いておいてなんなんだけど飽きた。
Javaで開発されたアプリケーションにはインストールにまつわる難点がある。
それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。
また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。
javafxで導入されたパッケージャを用いることで各OSネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。
SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。
Javaで開発されたアプリケーションの配布には以下の問題点がある。
javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。
javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。
Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。
公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。
pom.xml に以下を追加する。
mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。
vendor は適当に組織や個人の名前を入れておきましょう。
※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805
<plugin> <groupId>com.zenjava</groupId> <artifactId>javafx-maven-plugin</artifactId> <version>8.1.2</version> <configuration> <mainClass>[main method class]</mainClass> <vendor>[Vendor Name]</vendor> </configuration> </plugin>
あとはそのままビルドすればよい。
maven clean jfx:native
ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。
本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。
これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。
/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。
app の下にはビルドした jar ファイルや依存ライブラリが置かれています。
runtime の下には実行用の jre が配備されています。
実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です)