脅しに使われる裁判員制度
http://www.asahi.com/national/update/0514/TKY201005140517.html
まず気になるのは、ほかのケースでどう扱うのか、ということ。
あと、結局裁判員以外にならこういう情報にアクセスできる人はいるわけだよね。
まぁある種の証拠として押収されるんだろうし。
こういうデリケートな情報をどう扱うかってのは、取調べにおける「セカンドレイプ」と呼ばれる問題と関わりがあるよね。
一部の捜査員とかが見ちゃうのはある程度仕方ないとしても、「それが脅しとして有効である」と犯罪者側が認識してるってことが既にひとつの問題なわけで。。
なんか素敵な解答があればいいんだけどね
こういうのもある。
結局、犯罪が起きた事実や内容に当事者以外がアクセスしないと裁けないのは仕方がないわけで、問題はどうやって「安心感」を提供するか、なのかな？
判断の妥当性をひとまず脇においておけば、少なくとも被害者の心理的負担は少しは軽減される気がするけど。
普天間対案（予定）＠石破さん
対案が固まる前に「対案がある」って言ってしまえるのはとてもカッコイイ。まぁ言わないだけでもう案は自民党内で固まってて、出す時期を選んでるだけかな？
特に首相が県外移設を先出ししてミスった状況なだけに。これ言ったら案を出さないわけにはいかないでしょ。
石破さんに注目ー。
php5.2の./configureインストールメモ - vmwareでCentOSをインストール
./configure \ --with-mysql=/usr/local/mysql \ --with-apxs2=/usr/sbin/apxs \ --enable-mbstring \ --enable-mbregex \ --enable-zend-multibyte \ --with-gd \ --with-freetype-dir \ --with-jpeg-dir \ --with-png-dir \ --with-zlib-dir \ --enable-gd-native-ttf \ --enable-gd-jis-conv \ --with-openssl \ --with-curl \ --with-pear
symfonyのための推奨設定
% cd php-5.2.12/ext/xsl % phpize % ./configure % make % make install php.iniに extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613/" extension=xsl.so
http://l-w-i.net/t/php/ext_001.txt
tar zxvf APC-2.0.4.tgz cd APC-2.0.4 /usr/local/bin/phpize ./configure --enable-apc make make install ln -s /usr/local/lib/php/extensions/no-debug-non-zts-20020429/apc.so /usr/local/lib/php/extensions/apc.so php.iniに extension=apc.so
http://cubic9.com/Devel/PHP/Accelerator/APC/
mysqlのPDOがなかったので
http://d.hatena.ne.jp/gamme/20100206/1265481725
を参考にインストール
【今更レビュー】『Avatar』を観た
アバターみた。
感想を羅列。
- やりたい内容に対して尺が足りてない。
- ナヴィに同調する仕掛けが不十分な気が。（その分会社側をムカツクしようにはしてるけど）
- 結局解決手段としてナヴィ側も戦いを選ぶ点が最大の不満。つーか結構皆好戦的だし。それはナヴィ哲学と矛盾しないのだろうか。まぁ地球側が、愛に目覚めて撤退するなんてご都合主義よりはマシだけど
- ナヴィから見た他種族の見え方が不明瞭。対等なのかナヴィが上位なのか。鳥みたいな（追記：イクラン、ですね）の相手に平気で「仕える」なんて語彙を選ぶあたり違和感
- ジェイクの優柔不断ぶりは異常。心情的にほぼナヴィになった状態でも、立ち退き（逃げる）を話し合いで要求しようとする姿は滑稽ですらある。「揺れてる」描写も特にないのに
- ナヴィは明らかにネイティブアメリカンのアレゴリーだと思うけど、あの結末は歴史に対してどういう結論を出してるのだろう。追い払った、という結果からして一定の意見を提出してるとは思うけど
- それとも単に、過去の侵略は悪だからサクッと反撃成功させてスカッとしようぜ！ってことなんだろうか
- 細かいツッコミとしては、ダイナマイト投下予定地に爆薬の他に弾薬、燃料満載の鉄の塊を墜落させることは、本当に「阻止」になってるのかが疑問
- ３Ｄを意識した映像であることはよく分かった。３Ｄで観なかったのが残念。表情が思った以上に綺麗に出てて感情移入しやすい。
- ナヴィ体との精神接続の理屈は設定上どこまで練られてるのだろう。遠隔地でのログイン・アウトが自由ってのは、縛りが緩いなと感じた。接続中で死んでも強制切断されて生きのびれる様な描写もあったし。（瀕死→意識不明→解除ってことなのか？）
- トリとかウマとかオオカミとかは物凄い乗ってみたい。凄い爽快そう。特にトリ。スゲー魅力的
- 先代のイクーナマクトが、部族をまとめたってのは、どういう意味なんだろう。まとまる以前はバラバラだったのかな？
- あ、あとジェイクは族長の娘を全力で寝とった訳だが、あんな個人的なやりとりだけで許されるような事態何だろうか。そのことはどう評価されてるのか気になる
部屋を探すときにもっと気をつければよかったこと
当初参考にした点
- 家賃。
財政が厳しいのはわかりきっていたのでここは必須。
- 部屋の間取り
広さもだが、形が広さの実感にすごく影響することはわかっていたので。
- 炊事関係の設備
自炊するにはここが共用だと、個人的に途端にハードルがあがるので。
- ネット環境
言うまでもなく
あとで気づいた点
- 窓の向き
北向き。部屋に日が入らないこと自体はいいのだが、ベランダに布団を干す意味がほぼゼロに。洗濯物もすべて陰干し状態。やはりいずれかの時間には光が当たってほしい。
- コンセントの場所
検討すべきとは分かっていたけどあまりよく見てなかった。
やはりかなりレイアウトに影響する。延長コードは邪魔。
- 電話線の場所
デフォルトでついてはいたが、PCの場所から結構遠くなってしまった。ある意味予定通りなのだがやはり不便。
思い出したら随時追加します。
twitter・・・だからなの？
「どうしていままでこれが問題にならなかったのか……Twitter経由での情報流出」
http://d.hatena.ne.jp/thir/20090731/p1
最初に結論
この三項目以外のことは言ってないつもり。（残りは読み飛ばしても害はないかもｗｗ）
twitterだからというより
表題に関しては答えは簡単だと思いますが。
twitterというメディアの特殊性は確かに存在すると思います。
ただ、「一個人が全世界に向けて自由に好きな内容を公開できる」という点に拠る問題であってtwitterだからという部分には「？」ですね。
「投稿しやすい仕組み」作りがダメ、というならまあポリシーの違いということになると思いますが。
配慮はいると思います
正直例示されている内容が「明らかに罵倒」とかはちょっと共感できないところですが、その辺は個人の誤差と思うことにして、ポストする人間が配慮する必要があるというのは賛成。
発信してる情報がいったい「どの範囲に向けて」なされているものなのかを、発信者は絶対にわかっている必要がありますよね。
自浄作用？
でも、twitterの自浄作用ってのはどうなんでしょ？利用者同士で注意しあうとかそういうこと？
twitterというシステム（もしくはblogなども含む、インターネットメディア）に何かを期待しているのなら、そういうものはおそらく意識的に何かを組み込まないと発生しないと思います、現状では。
自然と、こういった他人の情報をポストしなくなるインセンティブって現状では何かあります？僕には見つけられません。
法規制でもしてみますか？
何が個人情報なのか
そうすると、法規制にせよシステム規制にせよ、何がポスト可で何が不可なのかを判断する必要が出てきますよね。そういう風に強制力を持つレベルでポストさせないのなら、thirさんが想定している範囲の情報は、明らかに公開されてる情報かなり多く含んでいるように見えます。これを「禁止」するのはかなり難しいし、錦の御旗「表現の自由」とか（この言葉あまり使いたくないですけど）も含め、かなり障りがあるように思うのです。
もちろん、thirさんは「配慮」と「自浄作用」を期待しており、つまり内発的な何かがそれを行うべきとしているので、thirさんが「禁止」すべきと考えているとは思っていません。ただ、この作用を何に求めるかということになると、私は思うのです。
doSelectJoinAll()：同じテーブルに複数の外部キーを張るとき適切なSQL文を生成できない
関数そのものに関しては
http://symfony.xrea.jp/1.0/book/18-Performance.html#minimizing.the.number.of.queries.with.joins
を参照
解決策
以下の方策は諦めました！！無理！
結局生のSQLを発行することに決定。
SQL文にカラム名が被ってるものにことごとくASで別名を設定。取得した内容を配列に持たせて、Viewに渡すという結果になりました。
まだ途中ですが、
・テーブルに別名を設定する。
- >doSelectJoinAll()のオーバーライド
- >actionの変更
- >templateの変更
例えばこんな場合
- schema.yml
propel:
mail:
_attributes: { phpName: Mail }
id:
from_user_id:
type: integer
foreignTable: user
foreignReference: id
to_user_id:
type: integer
foreignTable: user
foreignReference: id
user:
_attributes: { phpName: User }
id:
name:
type: varchar(255)
mailテーブルとuserテーブルの間には２つの外部キーがある。
あるメールの送り手と受け手を、どちらもユーザーテーブルと関連付けている。
これをactionで
MailPeer::doSelectJoinAll(new Criteria());
みたいに呼ぶときに期待する結果は、from_user_idとto_user_idそれぞれに対してidに対応したユーザーを別々に取得することだと思われるが、発行されるSQLは
SELECT mail.ID, mail.FROM_USER_ID, mail.TO_USER_ID,
user.ID, user.NAME
FROM entry, user, category, file_list
WHERE mail.from_user_id=user.ID
AND mail.to_user_id=user.ID
こんな感じ。
つまり、userテーブルは一度しか呼ばれず、送り手と受け手が同一のレコードを取得する、という結果になってしまう。
