Raurublock on Tumblr

Back as far as version 4.6 of Drupal, the decision was made not to use PHP’s class construct. This decision was made for several reasons.

First, PHP’s support for object-oriented constructs was much less mature at the time of Drupal’s design. Drupal was built on PHP 4, and most of the improvements in PHP 5 relate to its object-oriented features.

Second, Drupal code is highly compartmentalized into modules, each of which defines its own set of functions. The inclusion of files is handled inside functions as well; PHP’s performance suffers if unneeded code is included, so Drupal attempts to load as little code as possible per request. This is a critical consideration, especially in the absence of a PHP accelerator: the act of compiling the code accounts for more than half of the time to complete a Drupal page request. Functions are therefore defined inside other functions in Drupal, with respect to the runtime scope. While this is perfectly legal for bare functions, PHP does not allow the same kind of nesting with class declarations. This means that the inclusion of files defining classes must be “top-level,” and not inside any function, which leads either to slower code (always including the files defining classes) or a large amount of logic in the main index.php file.

Finally, using PHP classes to implement Drupal constructs would be difficult, due to the use of some advanced object-oriented design patterns that PHP’s OOP system doesn’t support. For instance (see following sections for details), the Drupal theme system relies on an OOP concept similar to Objective-C’s “categories”, which is not present in PHP.

住宅ローンを組むのも、誰かしらが投資ローンで組んだ収益物件に住んで家賃を払うのも、誰かのオプションの売り買いに、どちらかの側に立って参加しているに過ぎない。基本的には相場の売買で売り方だから勝ちとか買い方だから負けとかいうのは無いのと同じで、どっちのポジに立っても勝てるし負ける。単に相場への出入タイミングとレバレッジ具合の違いがあるだけだ。

明日の債券金利や株価が分からないのに＆損得勘定する上での変数は山ほどあり期間が超長期に渡るのに、30年後の収支が1千万損でした、いや計算間違いで200万損でした、とかいうのは割引率という概念を知ってる人間にとっては（＆REIT界隈のDCFの悪用・曲解を知ってる人間にとっては）●● じゃなかろうか？という感想しか持てない。

インフルエンザ・ウィルスは脂質二重膜(細胞膜と同じね)に包まれているので、アルコールで破壊できる。バクテリアの細胞膜を破壊するのと同じ。したがって、インフルエンザ・ウィルスにはアルコール消毒が有効。ウィルスを「殺菌」するというのは、言葉としては間違っているが、効果としては間違っていない。

いっぽう、多くのウィルスは脂質二重膜ではなくタンパク質からなるカプシドに包まれているので、アルコールでは破壊されない。

だから、インフルエンザ・ウィルスの例をもって、「ウィルス対策にはアルコール消毒」などと考えてはだめ。
基本的にはアルコールは「殺菌」するものだと思う。それに対し、ウィルスは菌ではない。

いや、僕もインフルエンザ・ウィルスのエンベロープが脂質二重膜だということを今回の新型騒ぎで初めて知りました。最初は「ウィルスにアルコール消毒だなんて、なんにもわかってないじゃん」と思っていたのですが、わかっていないのは自分のほうだったよ。

ネットカフェの利用者が、いやらしいＤＶＤや海外サイトを観るのが目的だとしたら身分証の提示は、ものすごく嫌になるから、「そんな店つかわない」ということになる。

これがビジネスにおけるプライバシーのマーケティングの一例となる。

本人確認の利用目的が、犯罪捜査のためであることから利用者は「犯人予備軍」もしくは、犯人扱いされているのではないかということに気がつく。

利用者の利する目的がなく、不利であったり、不名誉なことのために個人情報が利用されることは営業に逆効果となる。

条例やネットカフェ規制法とかいう議員立法でつくって、ルールだから。ということにすれば個人情報を取得することができるが、ネットカフェを主たる住みかとしている人がいる場合に、その人の個人情報をお店が扱う場合には、差別のもととなるから注意が必要となるかもしれない。

(中略)

解決策としては、

・本人確認の制度を設けるならば、管理をする体制や運用についての配慮が必要であるし、個人情報を悪用する防止策を考えなければいけない。

・本人確認を諦めて、犯罪を抑止するならば。闇サイト等にはアクセスできないような取り組みをネットカフェ事業者の自立的な取り組みですべきだ。　思想の自由や言論の自由を訴えて、犯罪者を集める輩を顧客にする必要はない。犯罪者の利用を減らすことで売上が減るかもしれないけれど社会の悪の巣窟のイメージを払拭することができるからだ。

携帯電話の契約や銀行口座を利用するそれと違い、数時間の遊興のためのネットカフェの本人確認は性質から難しいということだ。