2015/04/05
著作隣接権と契約
なるほど、こういう事情もあるのか。
アメリカという国は、さまざまな点で世界をリードする先進国であるにもかかわらず、こと著作権に関してはものの考え方が極端に遅れています。｢著作隣接権｣に関しては法規定はおろか概念すらなく、法整備によって実演家を保護しようなどとの考え方は存在しません。
では、俳優や音楽家などが映画に出演した際に二次使用料を払って欲しいと考えた場合にはどうするのでしょうか。
実演家は労働組合に結集してストライキ権を背景に要求を勝ち取るという形態をとっているのです。
ただ、著作隣接権が法的に保証されたとしても、 結局利用料や利用条件は別途契約で定めることになると思うんだけどそのへんどうなのかな。 例えば実演契約の時に「買い切り」の契約にサインしちゃったら、 いくら隣接権があっても二次使用料は入らないよねえ。 もらわない、ってことに合意したわけだから。 後から隣接権を盾に契約変更を要求できるとなったら何のための契約だってことになるし。 (まあ、あまりに隣接権をないがしろにするような契約は裁判になれば後から ひっくり返せるのかもしれないけど。)
で、結局契約が必要ならやっぱり組合作ってプレッシャーかけないと、 不利な契約にサインさせられて酬われないって状況は変わらないようにも思える。
SAG-AFTRAも実演家の権利の法的保証についてはバックアップしてるようだけど、 Performing Rights Actは音楽の演奏だけの話のように読めるな。 映像作品への出演については法的整備はまだということだろうか。
Tag: 芝居
2015/04/01
関数型言語のリストと命令型言語のリスト
C++納品の案件で、プロトタイプ&アルゴリズム検証用にSchemeで実装してから
C++に移植するってのをやってて、
std::listとSchemerが考える「リスト」の違いに改めて気づいた。
いやもちろんリストというデータ構造を利用してるという意味では同じなんだけど。
リストを不定長データの集合を扱うコンテナと考えるならstd::list的な
もので十分だし、データの挿入位置についてこだわりがないなら可変長配列を持ってる
言語は既にたくさんあって、さらにそういったデータ構造に対するfindや
map的な操作も標準で提供されることが多いから、
そっちの面から見たらSchemeでのリスト操作は比較的素直に命令型言語の
組み込みリスト型or可変長配列型に移植できそうに思えるんだけど。
Scheme(や他の関数型言語)のリストってのは、 「既にあるリストに変更を加えずに、新たな要素を低いコストで追加したリストを 得られる」ってのがかなり決定的に重要な性質で。
探索しながら結果を積み上げていって、失敗したら別の選択肢を試す、
なんてコードは、Schemeなら途中までの結果は既に掴んでるから
単に再試行すればいいだけなんだけど、std::listにpush
しちゃってる場合は巻き戻さないとならない。
これはまあ、関数型風の書き方と命令型風の書き方のミスマッチと言っちゃえばそれで
おしまいなんだけど、
案外、二つのスタイルの根本的な差を端的に示してるのかなとも感じた。
(なお、「SchemeとC++の両方で実装」というのは個人的には成功だった。 循環ありの有向グラフをいじりまくる案件だったので試行錯誤にSchemeの方が圧倒的に楽だったのと、 Scheme版でテストデータを生成してC++版を流して一致するかどうか見る、という形で C++版の実装バグを簡単に潰せたので。 もちろん同一アルゴリズムを使ってる以上、アルゴリズムのバグは別にテストしないとならないんだけど、 実装の問題とアルゴリズムの問題を確実に切り分けられるだけでものすごく助かった。)
Tags: Programming, Gauche, Scheme, C++
2015/04/01
見ながら書く
開発スタイルのせいなのか、それとも短期記憶が小さいのかわからないけど、 自分は「関連情報を見ながら書く」ということが非常に多い。例えば関数を書いてる 時に、その呼び出し元と、それから書いてる関数から呼び出している関数の ソースを同時に開いて見ながら書く、とか、 複数の入力に対するREPLの出力を(REPL窓を2分割して)眺めながら さらに関数を修正する、とか。
だもんで、「書いている箇所でない場所を自由に広く見られる」「(書いているバッファではなく) 見ているバッファ内を自由に移動する」という機能が欠かせない。
Emacsだと、「今書いている関数を呼んでいる関数」が同じファイルにある時に 画面を分割して一方で見たい箇所、もう一方で書いてる箇所を表示するのが数キーストローク でできるんでありがたいんだけど、XCodeとかで思うようにできなくてじれったく 感じる。(Assistant editorのデフォルトを「今見てるファイル自身」に するのってカスタマイズでできるのかな?)
あと、「今書いているまさにその場所」というのを見る必要ってあまりなくて、 どっちかというと参考に参照している部分の方を広い視野で見たいんで、 「複数窓を開いて、参考にしている窓を手前に広く表示し、裏にあるウィンドウに タイプする」という操作も多用するんだけど、 どういうわけか最近のUIはフォーカスした窓を手前に持ってくる動作が デフォルトになってて困る。Linuxは新しくインストールしたらまずこの動作を 変えるんだけど、OSXとWindowsではどうやるのか知らない。
似たような話で、IDEの補完で出てくるウィンドウが、 今書いている箇所の数行先のまさに参照したい部分を隠しちゃっていらつく、 ということもよくある。補完は有難いんだけど、隠さないところに出してほしいなあ。
今風の開発スタイルについていけない、ロートルになったってことなのかもしれないが… みんなこれで使ってるのかなあ。それともカスタマイズしてる?
Tag: Programming
2015/02/19
リリース直後が最も開発効率が高い説
- リリース直前のクランチタイムには、他のことの優先度が下げられるので、 コードに関する事柄が脳内キャッシュに占める割合が最高に達する。
- リリースを済ませると、リリースに向けてのtodoを潰すために 動いていた多くの脳内プロセスが終了する。
- そうすると、「コードに関して膨大な情報が脳内キャッシュに載っており、 その上で好きなプロセスを自由に走らせることができる」という開発には理想的な状態に。
リリースしたらさっさと忘れてぱーっと遊ぶ、とかすると、 折角のキャッシュデータがフラッシュされちゃう。いや遊ぶなとかいうわけじゃないけど、 自分は大量の関連情報をキャッシュに載っけるまでが大変なタイプなので、 むしろこの性質を利用したい。
本来の締切りの手前に自主締切りを設けるとかすれば良いんだろうけれど、 というか一応そう試みてはいるんだけど、やっぱり心のどこかで本当の締切りを 意識していまってなかなかうまくいかない。
ただ、複数のプロジェクトを抱えている時に、コンテキストスイッチのタイミングを ずらすというのはそこそこうまくいっている感じだ。 つまり、プロジェクトAのスナップショットリリースを出したらすぐに プロジェクトBの作業を再開するのではなく、スナップショットリリースの後 少しプロジェクトAの仕事を続けてから、Bにスイッチする。
まあ、プロジェクトが重ならないのが一番いいんだけど。
Tag: Programming
2015/02/08
週給
本筋と関係ないんだけど
『アニメ『楽園追放』は"社会の壁"を壊してヒットを勝ち取った』
給料は1週間ごとに支払われる＝1週間でクビにできる 超成果主義のハリウッドでCGの腕を磨いた日々
[...]
野口 アメリカって怖いと思ったのは、会社ではギャランティーが1週間づつ支払われるんです。 すぐに首が切れるように。来週の給料はもうない、みたいな。だからちゃんと結果を出さないと、いつ切られるかわからない。そんな状態がずっと続くのは疲れるよな、と。
カリフォルニア含むアメリカの半分近くの州では、 法律で給料の頻度は少なくとも週毎とか 月2回とか決まってるんで、月給にすると労働法違反になる。 月給okの州でも制限(収入が多い専門職とか役員とかのみ)があったり、 「労使合意した場合のみ」となっているところが多い。 (労働省のサイトに詳細あり)。
キャッシュフローで考えても、 給料払う頻度が低いほど会社が有利、労働者が不利になるのだから、 週給で払われる方が労働者保護とは言えまいか。 むしろ「会社がいつ潰れても未払いの給料が最長1週間分で済む」と見るべきじゃないかなあ。
いつでもレイオフできるのは"at will"の労働契約ってやつで、 これは給与の頻度とは関係ない。途中でレイオフしても働いた分だけ清算すればいいのだから。
「すぐ首を切れるように」週給になってる、というのに違和感を覚えたので。 まあ、ペイチェックと合わせてレイオフ、みたいな心理的なタイミングが 取りやすい、ってことはあるかもしれないけど。
Tag: 生活
Comments (0)