2009年12月01日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1「ハトミミ.com」のセンスの無さに絶望した。[社会] このエントリーをはてなブックマークに追加

その名も「ハトミミ.com」…HPで行政の内部告発受け付け[http://www.yomiuri.co.jp/net/news/20091201-OYT8T00337.htm] というニュースを見た。
どうして、こんなにセキュリティ意識もセンスも感じられない名称を付けるのか。
不正や行政内部の密約など不透明な取り決めの“内部告発”を受け付けるホームページ「ハトミミ.com」の新設を決めた。
(中略)
サイトの名称は鳩山首相の名前にちなむもので、来年1月からは一般国民からも、ムダ根絶につながる提案を募る。
内部告発や一般国民からの提案を受け付けるサイトであるから、機微情報を扱うサイトであることは間違いなかろう。そういうサイトを立ち上げるに当たって、第一にウケを、さらに首相個人の売名を狙ったネーミングをするところに底の浅さを感じる。
本論とは関係ないが、なんとなく監視国家を暗示する絵に見えて仕方が無い。 このあたりもセンスの無さかも知れない。
国民・職員からの意見聴取について
さて、「ハトミミ.com」だが、Punicode変換してwhoisしてみると、
Domain Handle: None
Domain Name: xn--fdkn3ca.com
DomainNameML: ハトミミ.com
Created On: 2009-12-01 00:32:28.0
Expiration Date: 2010-11-30 15:32:28.0
Status: ACTIVE
Registrant Name: Whois Protect Service
という感じで、恐らくはニュース発表後に第三者によって取得されたドメインではないかと言う感じだ。もちろん、政府関係者が直前に取得して、あえてWhois Protect Serviceを使っている可能性も無いでは無いが、だとすると、一私企業である お名前.comの広告ページ[http://xn--fdkn3ca.com/] を表示するのが適切かという議論がある。
公に「ハトミミ.com」という名称を使用することを発表するのであれば、少なくとも「ハトミミ.com」は予め押さえておいて、第三者に取得されることは防ぐべきではないか。
フィッシングに使われる、ニセサイトに誘導されるということを危惧しなかったのだとすれば、恐るべき危機感の無さだ。
そもそも、実際のところは、go.jpドメインで運用されるのだろうから *1 、「ハトミミ.com」等という、全く関係の無いドメイン名を告知するのは、利用者を惑わすことにつながり、社会全体の脆弱性を増すことに繋がる。
「政府機関のサイトは絶対に.go.jp」「地方自治体のサイトは絶対に.lg.jp *2 」という原則が貫かれれば、リテラシー教育の上でも、アプリ等での対策の上でも、脆弱性を減らす方策が取りやすくなる。
「ハトミミ.com」のセンスの無さに絶望した。
*1: 政府機関の情報セキュリティ対策のための統一基準[http://www.nisc.go.jp/active/general/kijun01.html] として、府省庁外の者に対して、アクセスさせることを目的として情報を保存するためにサーバを使用する場合には、政府ドメイン名のサーバだけを使用することが定められている。
*2: 地方自治体に関しては、地域ドメイン名という悩ましいものがある上に、.netなんかを使っている自治体もあって、まだまだ残念な状況だ。

この記事に頂いたコメント

Re: 「ハトミミ.com」のセンスの無さに絶望した。 by TK    2009/12/01 22:21
>地方自治体のサイトは絶対に.lg.jp >*2: 地方自治体に関しては、地域ドメイン...
Re: 「ハトミミ.com」のセンスの無さに絶望した。 by センサスちゃん    2009/12/02 09:54
「恐らくはニュース発表後に第三者によって取得されたドメインではないかと言う感じだ...
Re: 「ハトミミ.com」のセンスの無さに絶望した。 by     2009/12/02 18:36
http://ameblo.jp/kanteijp/ http://kantei.channel.yahoo.co.jp/ どんどん量産されて...
Re: 「ハトミミ.com」のセンスの無さに絶望した。 by     2009/12/31 22:09
この記事に書かれている文章「恐るべき危機感の無さ」が、産経新聞の記事に載ってます...

■ 関連記事

詳細はこの日の詳細から

2009年12月02日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1日記タイトルに記事タイトルを[hns] このエントリーをはてなブックマークに追加

ある方から、日記タイトルに記事タイトルを表示して欲しいというリクエストを頂いた。 当人にはまだ理由をお聞きできていないのだけど、別の方から、ブラウザの機能でブックマークする時や、タブブラウザでタブを選ぶときには、記事名があった方が嬉しいのではという考察を得た。
実はこの日記、 hns[http://www.h14m.org/] をベースにしていて、オリジナルのhnsでは、個別の記事に対するリンクを辿ったときには、記事名を含んだタイトルで、その記事のみを表示する仕様になっている。
ところが、ウチではこれをいじって、個別記事に対するリンクを辿る場合でも、その記事を含む日の記事を全部表示するようにしたので、副作用として記事名が表示されなくなったわけだ。
当時は、日記や日誌は日を単位として書かれるものであるから、個別記事へのリンクであっても、その日の記事を並べて表示したいという思いで、そういう風に改造したのだけれども、今や、周りを見回すと世の中blog全盛で、記事単位で表示するのもありかなという様に自分の思いも変化した。
いずれにせよ、タイトルが変化しないのはもったいないと言えばもったいないので、何か対応を考えよう。

対応しました:

12月8日追記。
記事トップの■と、固定リンクで生成されるリンクを記事個別のリンクとし、このリンクを辿った場合は、記事タイトルが表示されるようにしてみました。
とりあえず、日記タイトル + ' ' + 記事タイトルという形式にしてみましたが、業界標準みたいなものがあったら変える積りです。

■ 関連記事

詳細はこの日の詳細から

2009年12月03日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 Google日本語入力を信用しても良いものか[http://www.google.com/intl/ja/ime/] このエントリーをはてなブックマークに追加

Google日本語入力[http://www.google.com/intl/ja/ime/] というものがリリースされた様だ。
インストールしてみてはいないが、多くのユーザーの変換履歴をフィードバックすることによって、より変換精度を向上させ続けていこうというアプローチだろう。 ソーシャルIME[http://www.social-ime.com/] のアプローチに近い。
しかしながら、このサービス。どこまでの入力情報をサーバ側に送信するのか、利用規約を読んでも分からない。「使用状況データと障害レポートを Google に自動送信して Google 日本語入力の機能向上に役立てる。」というオプションのチェックはあるが、このチェックを入れなければ、一切の入力情報をサーバに上げないのだろうか。
Googleの検索ボックスに入力した単語は、たとえ検索をしなくてもGoogleのサーバに逐一送信されているので、「爆弾」とか「殺人」とか「大統領」とか「テロ」とかいう単語を検索ボックスに入力すると、それだけで エシュロン に捕捉されることになりかねないのだけど、同じ心配はないのだろうか。

入力した文字はGoogleに送信されますか[http://www.google.com/support/ime/japanese/bin/answer.py?hl=jp&answer=166771]:

・入力した文字はGoogleに送信されますか。
入力した文字や文章がGoogle に送信されることはありません。
ということで、日本語入力については入力した文字や文章が送信されることは無いようだ。一安心。

2009年12月05日 追記:

この記事を書いた時点では、Google日本語入力の仕組みについて誤解をしていました。 詳しくは、 2009年12月05日の記事[http://www.nantoka.com/~kei/diary/?20091205S1] をお読み下さい。

■ 関連記事

詳細はこの日の詳細から

2009年12月04日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1Google Public DNSを使ってみた次の記事 >> このエントリーをはてなブックマークに追加

Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] のサービスが開始されたので、早速試してみた。
正引きを切り替えるのは、自分の手元で既にDNSサーバを稼動させていると、メリットが薄い感じがするのだけど、ログ整理のための逆引きに関してはメリットが出そうだ。
特定のプログラムだけDNSをスイッチする方法を考えたのだけど、リゾルバのライブラリにはそういう仕組みは備わっていないようなので、コードの方に手を入れないと難しい。chrootして切り換えてやる手はあるにはあるけども大掛かり過ぎる。
Perlのコードで、gethostbyaddrを使っているものがあったので、 Net::DNS[http://www.net-dns.org/] に書き換えるのと一緒に、 Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] に対応させてみた。
my $resGoogleDns;
sub googleDns($) {
  my $ipaddr = shift;

  $resGoogleDns ||= Net::DNS::Resolver->new(nameservers => ['8.8.8.8', '8.8.4.4']);
  my $query = $resGoogleDns->search($ipaddr, 'PTR');
  if (! $query) {
      return $ipaddr;
  }
  foreach my $rr ($query->answer) {
    if ($rr->type eq "PTR") {
      return $rr->ptrdname;
    }
  }
  return $ipaddr;
}
といった感じ。既に、 Net::DNS[http://www.net-dns.org/] を使っているコードだったら、
  $res = Net::DNS::Resolver->new;
とかやってresolverインスタンスを作っているところを、
  $res = Net::DNS::Resolver->new(nameservers => ['8.8.8.8', '8.8.4.4']);
と、DNSのアドレスを指定してやるだけで、 Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] 対応になる。
自分のところのDNSにキャッシュされていれば通信時間分損をすることになるけれども、Google DNS側にキャッシュがあれば、相手方が遅いDNSサーバだったり、応答が無い場合に待たされない分のメリットがある筈だ。
残念ながら、ウチの場合は自分のところのDNSキャッシュに既に乗っている確率が高かったのか、あまり高速化が出来なかった。
複数のプロセス使って、並列にクエリを投げてやれば、結果は違ってくるかも知れない。

■ 関連記事

■2 はてなでは買いだめしている[http://d.hatena.ne.jp/rx7/20091125/p1][サーバ管理]<< 前の記事 このエントリーをはてなブックマークに追加

数年前、おしごとでサーバ管理をしていた頃の話。ホスティング、ハウジング共に自作サーバーを使っていた。
当時は、安定性が要求されるネットワークサーバーに自作機を使うと言うのは非常識なことだったので、お客さんにもなぜわざわざ自作サーバを使うのかと訊かれたものだった。

自作サーバを使う主なメリットは2つ感じていて、ひとつは、自作サーバカンファレンスでも触れられている通り、アーキテクチャを自分で決められること。
このメリットは今より当時の方が大きくて、当時は今の様に細かいカスタマイズをすると高く付いたし、サーバと名が付くPCはそれだけで高かった。
一方、デスクトップPCは、安いものを選べばI/Oのパフォーマンスが出ないマザーボードが採用されていて、PC全体の性能を求めるともれなく高性能なそして高価なグラフィックカードが採用されていたり、高速なそして高価なCPUが採用されているという状況だったからだ。
そういう中にあって、枯れたマザーに、一クラス下のCPUを使い、容量よりも実績でHDDを選ぶことができるメリットは大きかった。

もうひとつ、自作サーバはつぶしが利いた。故障に備えてパーツをストックしておくにしても、不要になったサーバを「つぶす」にしても、使い回しが利いた。
もちろん、一定のメーカーの同一製品を一括購入すれば、そういうことは考えなくても良いのだけれど、お客さんにあわせてサーバを調達する都合で、製品を揃えるのは難しかったのだ。

リンク先のまとめにもあるけれども、自作サーバを使うためには、「ハードウェアトラブルを自分たちで解決する覚悟」が必要だし、トラブルを自分たちで解決する積りであれば、メーカ製PCの保守や保証はむしろ邪魔になるし、リース契約は柵になる。

逆に、自作サーバを使っていて一番困ったことは、経理上の処理だった。どの部品がどのお客さん用に使われているのかとか、在庫管理はFIFOなのかFILOなのかとか、お客さんが使わなくなったサーバの部品を使って、日記用サーバ作ったけどどうよとか、そういう問題が、実は一番面倒な問題だった。
こういう面でも、自作サーバを使うのはリース契約とは対極にいると感じる。
そういうことがあって、「はてなでは買いだめしている」ことが印象深かった。

■ 関連記事

詳細はこの日の詳細から

2009年12月05日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 Google日本語入力について誤解していた[http://googlejapan.blogspot.com/2009/12/google_03.html]次の記事 >> このエントリーをはてなブックマークに追加

Google日本語入力を信用しても良いものか[http://www.nantoka.com/~kei/diary/?20091203S1] の記事を書いたときには、日本語入力機能からのフィードバックを(もちろん、プライバシーには配慮した統計的に処理された形で)集約して、変換精度の向上を目指すと思い込んでいたのだけれども、表題でリンクした記事を読む限り、誤解だった様だ。
Google 日本語入力は桁違いの語彙力を持っています。Web から機械的・自動的に辞書を生成することで、人手ではカバーしきれないような、新語、専門用語、芸能人の名前などを網羅的に収録しています。高い変換精度を実現するために、Web 上の大量のデータから統計的言語モデルを構築し、変換エンジンを構成しています。
とあるから、この説明だけからすると、変換結果はもちろん、 ぶっこ抜き? [Google日本語入力の功罪][http://www.higuchi.com/item/534] で指摘されている様な、Googleサジェストの結果も使っていない様に感じられる。
いずれにせよ、まずは懸念して掛かる姿勢は必要だとはしても、公式情報源にあたらずに記事を書いたのは明らかに失敗だったので、 3日の記事[http://www.nantoka.com/~kei/diary/?20091203S1] に追記した。

■ 関連記事

■2 なぜオタクがモテるのか〜オタクがモテる4つの理由[http://news.ameba.jp/cobs/2009/12/51799.html][ネタ][社会]<< 前の記事 このエントリーをはてなブックマークに追加

記事によると:
理由その1. オタクは一途で誠実
理由その2. オタクはマメ
理由その3. オタクは紳士
理由その4. たぶん、オタクは2次元(または2.5次元)にしか浮気をしない
ということなのだけれども、「コミュニケーション能力」や「細やかな気遣いができる」ことが期待されており、対人スキルが高いのが前提の様です。
でも、これって ナード[http://ja.wikipedia.org/wiki/%E3%83%8A%E3%83%BC%E3%83%89] というかマニアというか、何か違うもののイメージの様な気がします。

■ 関連記事

詳細はこの日の詳細から

2009年12月06日()<< 前の日記 | 次の日記 >>
この日の詳細

■1Google Public DNSで無力化される米国特許6108703 このエントリーをはてなブックマークに追加

話題になっている Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] ですが、結局のところ、速度向上のメリットがあるのは、自分が現在利用しているISP等の DNS サーバが遅い場合ということになると思われます。
ウチでは手元にネームサーバを立ち上げていますが、ISPのネームサーバを使った場合、
kei@home[120] dig www.google.co.jp @xxx.xxx.xxx.xxx

; <<>> DiG 9.4.3-P3 <<>> www.google.co.jp @xxx.xxx.xxx.xxx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32789
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.co.jp.              IN      A

;; ANSWER SECTION:
www.google.co.jp.       71292   IN      CNAME   www.google.com.
www.google.com.         75334   IN      CNAME   www.l.google.com.
www.l.google.com.       271     IN      A       66.249.89.103
www.l.google.com.       271     IN      A       66.249.89.147
www.l.google.com.       271     IN      A       66.249.89.99
www.l.google.com.       271     IN      A       66.249.89.104

;; Query time: 17 msec
;; SERVER: xxx.xxx.xxx.xxx#53(xxx.xxx.xxx.xxx)
;; WHEN: Sun Dec  6 11:09:01 2009
;; MSG SIZE  rcvd: 146
で、「Query time: 17 msec」という測定結果が出ました。
一方、 Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] の場合、
kei@home[121] dig www.google.co.jp @8.8.8.8

; <<>> DiG 9.4.3-P3 <<>> www.google.co.jp @8.8.8.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27943
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.co.jp.              IN      A

;; ANSWER SECTION:
www.google.co.jp.       259200  IN      CNAME   www.google.com.
www.google.com.         259200  IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       66.249.89.103
www.l.google.com.       300     IN      A       66.249.89.147
www.l.google.com.       300     IN      A       66.249.89.99
www.l.google.com.       300     IN      A       66.249.89.104

;; Query time: 51 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Dec  6 11:11:31 2009
;; MSG SIZE  rcvd: 146
と、51 msecを要しています。その差、Tg(=51ms) - Ti(=17ms) = 34(ms)ですから、差は歴然としています。「Google Public DNSに変更したら早くなった」という人は、これまで相当に遅いDNSサーバで我慢してきた人と言うことになるでしょう。
こう書くと、「RTTが短いのは分かるけど、Google Public DNSには圧倒的なキャッシュ能力があるから、結局早いんじゃないの?」という反論がありそうです。 もちろん、GPDNSは投機的なキャッシュ更新をはじめとした、様々な高速化対策が施されているので、安定して早いと言うのは事実だと思います。
ですが、ISPのネームサーバのキャッシュに載っていないアドレスを引く確率はどの程度のものでしょうか。1%もあったら、相当特殊なブラウジングをしているのでは無いでしょうか。
ということで、日常的な体感速度には、結局、現在使っているネームサーバとGPDNSとの応答時間の差が支配的になると考えます。まず、計測してみましょう。

前段が長くなりましたが…:

みんながGPDNSを使うようになると、 Akamai[http://www.akamai.co.jp/] が保有している、 米国特許6108703[http://www.google.com/patents?id=-HsEAAAAEBAJ&dq=6,108,703] が無力化してしまう可能性に気づきました。
DNSクエリの問い合わせ元IPアドレスを見て、ネットワーク的に近くのサーバのIPアドレスを返すと言う仕組みなのですが、GPDNSを使われてしまうと、DNSクエリはGPDNSから来ることになって、この仕組みが使えなくなりそうです。
実際、 Akamai[http://ja.wikipedia.org/wiki/Akamai] *1 のシステムを使っている、いくつかのサイトに対する問い合わせを、ISPのネームサーバ経由とGPDNS経由で出してみたところ、違った答えを返してくるケースがありました *2 。GPDNSがAkamaiの様に、クエリ元IPを意識してIPアドレスを返し別けていれば良いですが、そうでなかったらCDNを使っているサイトはむしろ遅くなる可能性があります。
今は、利用者が少ないので大きい影響は無いと思いますが、今後、利用が拡大していけば、Akamaiに限らず、DNSを使った負荷分散や地理的分散処理を行っているシステムに影響を与えることになるかも知れません。
*1: AkamaiもGoogleと同じ1998年設立。
*2: 負荷分散のために、ラウンドロビンしている可能性もあるので、必ずしもGPDNSが原因とは言えませんが。

■ 関連記事

詳細はこの日の詳細から

2009年12月07日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1「首相官邸ブログ」と称する何か[セキュリティ][政治]次の記事 >> このエントリーをはてなブックマークに追加

1日の記事[http://www.nantoka.com/~kei/diary/?20091201S1] へのコメントによって、「首相官邸ブログ」と称するページが公開されていることを知った。当該サイトは、一般に提供されているブログサービス上に公開されているが、鳩山首相の写真や 五七桐紋[http://ja.wikipedia.org/wiki/%E6%A1%90%E7%B4%8B] が配されており、ドメイン名を気にしなければ、いかにも日本政府が公式に提供しているページに見える。
「首相官邸ブログ」と称するページ
内容はと言うと、 鳩山内閣のメールマガジン[http://www.mmz.kantei.go.jp/jp/m-magazine/index.html] を引用したような記事が並んでおり、メールマガジン登録のバナーも貼り付けられている。
いくら 偽メール事件[http://ja.wikipedia.org/wiki/%E5%A0%80%E6%B1%9F%E3%83%A1%E3%83%BC%E3%83%AB%E5%95%8F%E9%A1%8C] で名をはせた民主党政権とはいえ、政治家個人のページではなく、首相官邸という政府機関の名を冠したページを、特定の民間企業が定めた 利用規約[http://helps.ameba.jp/rules/post_104.html] の下に提供されるページに置くわけがないから、恐らく、広告収入を目的としたspamサイトの一種ではなかろうか *1 。 その様な懸念であえてリンクをはらないでいるが、検索エンジンでもかなり上位に表示されるようだ。
今のところ、公式メールマガジンをコンテンツとして、アクセスを集めているだけであろうし、本物の政府官邸サイトにあたって、このページが信頼できるものかどうかを確認できるような利用者は偽物と判断できるから、実害は無いかもしれない。
しかしながら、この様な偽サイトが放置されれば、インターネットの情報は迂闊に信用できないというネガティブな実績が作られることになる。 インターネットは、偽サイトを偽サイトと見分ける能力がある人だけのものではないはずだ。
この様なページこそ、 プロバイダ責任(制限)法[http://ja.wikipedia.org/wiki/%E7%89%B9%E5%AE%9A%E9%9B%BB%E6%B0%97%E9%80%9A%E4%BF%A1%E5%BD%B9%E5%8B%99%E6%8F%90%E4%BE%9B%E8%80%85%E3%81%AE%E6%90%8D%E5%AE%B3%E8%B3%A0%E5%84%9F%E8%B2%AC%E4%BB%BB%E3%81%AE%E5%88%B6%E9%99%90%E5%8F%8A%E3%81%B3%E7%99%BA%E4%BF%A1%E8%80%85%E6%83%85%E5%A0%B1%E3%81%AE%E9%96%8B%E7%A4%BA%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E6%B3%95%E5%BE%8B] を活用して取り締まれないものか。
*1: ページ上には、ブログ運営サイトの広告が貼り付けられている。

この記事に頂いたコメント

Re: 「首相官邸ブログ」と称する何か by よー    2009/12/08 03:27
取り締まるなら軽犯罪法(官名詐称)や著作権法でしょう。 責任制限法は責任を追及す...

■ 関連記事

■2 JVN#79762947 EC-CUBE における情報漏えいの脆弱性[http://jvn.jp/jp/JVN79762947/index.html][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

緊急です。
顧客情報が、一般ユーザーのブラウザ上から閲覧できる、極めて緊急度の高い深刻な脆弱性です。
ということで、修正コードが公開されています。
ざっと見てみたのですが、認証ページを経ずに直接、閲覧ページにリクエストをすると認証無しに結果が得られてしまうというパターンなのでしょうか。検証サイトを立ち上げればはっきりするとは思いますが。
いずれにせよ、無権限ユーザーの管理機能へのアクセスを許してしまうと言うのは大問題ですから、
システム設計
例)管理システムはインターネットからアクセスできない
コード設計
例)管理システムは統一されたベースクラスで権限が確認される
コード実装
例)XSS, SQL Injection対策
レビュー
例)設計レビュー、コードレビュー
等の手段で安全性を確保しようとするもので、今回の脆弱性に関しては、設計段階で配慮するか、レビュー段階で実装者間ででも簡単なレビューを行っていれば発見できていたレベルに見える。
自分が脆弱性の発見に貢献したわけでは無いので大きなことは言えないけれども、探せばもっともっと出てくるような気もするので、もっと注目していかないといけないと感じると同時に、クライアントにすすめるような機会があったら、費用掛けてでもレビューを一緒に勧めるべきだと思った。

■ 関連記事

詳細はこの日の詳細から

2009年12月08日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 暗闇50年、ハエ「進化」…1400世代飼育[http://www.yomiuri.co.jp/science/news/20091208-OYT1T00780.htm][科学] このエントリーをはてなブックマークに追加

ショウジョウバエの寿命は約50日。1400世代は、人間なら3万〜4万年に相当するという。 全遺伝情報を解読した結果、嗅覚やフェロモンに関する遺伝子など、約40万か所でDNA配列の変異が見つかった。視覚にかかわる遺伝子の一部も変異していたが、光には敏感に反応するので視覚はあるらしい。
50年で1400世代。人間で言うと、3〜4万年ということだが、意外と短い期間で変異が起こるという印象を持った。
阿形清和・京大教授は「通常とは異なる環境で世代を重ねることで、まず嗅覚などの感覚器官に差が生まれ、それが生殖行動に影響し、やがて種の分化につながっていくと推測できる」と話している。
とのことだが、限られた系列の中で交配を重ねた影響と言うのは出ないものなのだろうか。あるいは、そういう影響が出ないように実験を行うためには、どの程度のスケールで実験する必要があるのだろうか。詳しく知りたい。

■ 関連記事

詳細はこの日の詳細から

2009年12月09日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 「鳩山不況」に現実味 デフレと円高で冷え込む投資と消費[http://sankei.jp.msn.com/economy/finance/091209/fnc0912092111020-n1.htm][政治][経済]次の記事 >> このエントリーをはてなブックマークに追加

景気には良く名前が付くけど、不況に政治家の名前が付くのはかなり不名誉な事態だ。
内需主導での景気回復を目指すと言う局面にあって、景気は将来に対する期待と不安が左右するから、仕分けによって様々な事業を派手に切ったのは、金額に対して不安を煽る影響は大きかったように思う。
彼らが最初共産主義者を攻撃したとき[http://ja.wikipedia.org/wiki/%E5%BD%BC%E3%82%89%E3%81%8C%E6%9C%80%E5%88%9D%E5%85%B1%E7%94%A3%E4%B8%BB%E7%BE%A9%E8%80%85%E3%82%92%E6%94%BB%E6%92%83%E3%81%97%E3%81%9F%E3%81%A8%E3%81%8D] では無いが、いつ、自分の事業や仕事も影響を受けるかと心配になって守りに回った経営者や消費者も多いのではないか。

■ 関連記事

■2中古バイク無料査定でヒドイ目に遭った話[社会]<< 前の記事 このエントリーをはてなブックマークに追加

愛用していたバイクを手放そうと思って、 中古バイク無料査定[http://www.google.co.jp/search?hl=ja&safe=off&rlz=1B3GGGL_jaJP330JP357&q=%E4%B8%AD%E5%8F%A4%E3%83%90%E3%82%A4%E3%82%AF%E7%84%A1%E6%96%99%E6%9F%BB%E5%AE%9A&btnG=%E6%A4%9C%E7%B4%A2&lr=&aq=f&oq=] を頼んだら、非常に不愉快な思いをしたり、玄関先で泣かれたりしてヒドイ目に遭った話を読んだ。
考えてみると、中古品の買取と言う取引は非常に難しいところがあって、安く買い付けるためには、商品を悪く言うのが手段の一つになるのだけど、手放す側としては高く買ってもらいたいと言う気持ちは当然として、自分が愛用してきたものを悪く言われて良い気はしない。そういうところにあざとさが見えると、「値段はどうあれこの相手には売りたくない」という気持ちが生じると言うのは同意できる。
自分の場合は、こういう交渉では、交渉相手が信用できないと感じた瞬間に、交渉する気が失せてしまう。相手が信用できないとすると、頑張って交渉したところで、得るものは妥結であって、自分自身に納得は得られないからだ。
自分の精神の平穏を大事にするか、お金を大事にするか、しっかり決めてから売り先は選んだほうが良いようです。

■ 関連記事

詳細はこの日の詳細から

2009年12月10日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 [単行本]説得できる図解表現200の鉄則―ロジカル思考をアピールする概念図はこう描く[http://www.amazon.co.jp/%E8%AA%AC%E5%BE%97%E3%81%A7%E3%81%8D%E3%82%8B%E5%9B%B3%E8%A7%A3%E8%A1%A8%E7%8F%BE200%E3%81%AE%E9%89%84%E5%89%87%E2%80%95%E3%83%AD%E3%82%B8%E3%82%AB%E3%83%AB%E6%80%9D%E8%80%83%E3%82%92%E3%82%A2%E3%83%94%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B%E6%A6%82%E5%BF%B5%E5%9B%B3%E3%81%AF%E3%81%93%E3%81%86%E6%8F%8F%E3%81%8F-%E6%B0%B8%E5%B1%B1-%E5%98%89%E6%98%AD/dp/4822291774%3FSubscriptionId%3DAKIAIYKMKBZLJ3Y55SZA%26tag%3Dws%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D4822291774][book] このエントリーをはてなブックマークに追加

買ってきた本。最近はパワーポイントやその他のテンプレートも充実しているので、見た目に派手な図は描けるのだけど、文章により分かりやすい図を描くのはやはり難しかったりする。これは恐らく道具の問題では無いのだ。
数年前、ITコンサルタントを目指して *1 、トレンドや新技術をA4モノクロ1枚で説明する資料を作っていたことがあった。この制約はなかなか厳しくて、用紙が狭いので取捨選択が重要だし、色でごまかすことができないので分かりにくい図は一目で露呈する。
そういうことで、これは、ITコンサルタントに限らず、資料作り全般の良いトレーニングになると思う。完成品は営業資料としても使えるので無駄も無い。
これをやり始めたのは、あるプレゼンでの失敗がきっかけになっている。カラーでプレゼン資料を作ったからといって、全ての読み手に必ずしもカラーで見てもらえるとは限らないということに気づかなかったのだ。電子媒体と要求された部数の印刷物を提出してプレゼンに臨んだら、聞き手は依頼された部数よりも遥かに多くて、カラー印刷したものをモノクロコピーした配布資料を手元に持っていた。
強調するために背景色を入れた部分は文字が読みにくくなっているし、色分けして分類したチャートは何が何だかさっぱり分からない状態になっていた。
自分自身が色覚異常があるのに、配慮に欠けていた。手痛い失敗だった。
プレゼンに関する鉄則3つを学んだ。
1.可能な限り、事前に参加者の人数とプロフィールを得ておく。
2.印刷物の配布形態にあわせて原稿を用意する。カラー印刷ならカラー原稿。モノクロ印刷ならモノクロ原稿。モノクロコピーだったらコピー可能な原稿。
3.カラーやモノクロの印刷原稿を作るときには、モノクロコピーされても内容が読み取れるように作ること。
カラー原稿をコピーする時には、せめて写真モードを使って欲しいと思うけれども、相手がやることなので選べない。一方、聞き手にそういう経緯は見えないから、手元に配布された資料が全てだ。とすると、配布物の製作をコントロールできないときは、安全側に倒して、普通のモードでモノクロコピーされても読める様にしておく必要がある。
閑話休題。その頃は体当たりで図解表現を学んだけれども、こういう本にまとまっていると、ブレが無くなって良い。手元にレファレンスとして置いておきたい本だ。
*1: もちろん、コンサルタントと自称するのはその日からできるのだけど、仕様書の1ページも、コードの1行も書かないでお金をもらうのは、一見簡単な様で、なかなか大変なのだ。

■ 関連記事

詳細はこの日の詳細から

以上、10 日分です。

指定日の日記を表示

前月 2009年12月 翌月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project