A Day In The Boy's Life -119ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

ブログは顔が見える、Twitterは腹が見える @ Geekなぺーじ


確かにTwitterって腹が見えるところはあるかも。黒いところも含めてですけど(笑

それは、「Twitterとブラックジョーク 」に書いたような、いい意味でも悪い意味でも個がそのまま表現されるようなサービスだからかな、と思います。

Twitterでのその忌憚ない意見のやりとりが、人と人をつなげるところもあり、ブログは一方で距離を置きどこかそのブログ自体を神格化させるようなイメージがあるのかな、と感じたりします。



距離を置くブログ


書き手にとって、それは特に意識していることではないのでしょう。

ただ、ブログで表現される文章というのは、ある程度自分の頭の中を整理してから表現しているもので、今の自分の考えはこうだ!みたいな押し付けがましいところもあります。


ブログを書いている場合、どこか書ききりたい欲みたいなものがあるような気もします。

Twitterである考えを連続してつぶやいていくと、途中でリプライが返ってくる可能性があります。

その意見を見ることで揺らぐ場合もありますし、当初言おうとしていたことから路線変更されてしまうところもある。

ブログという場は、その考えをまとめ上げるまで個室にこもって書いているような感じで、Twitterは逆に机を囲んでブレストしているような感じを受けます。


その時点で完璧に作り上げた表現が、周りから見れば自分の意見を言いにくい環境にするのかなと。

ブログで反論は目にしますが、賞賛するのはほとんど見たことありませんしね。

ただ、読み手はほんの少しでも反応をしたいときがあります。

「納得した」とか「これは、○○ということじゃないかな」とか、些細なことですがブログを読んだときに何らかの自分なりの考えが頭をよぎるものです。


しかし、その反応をブログのコメントに書く人はほとんどいません。

ブログは例えそれを提供するサービス(Amebloとかはてなとか)を使っていても、そのブログ自体の空間はそのブロガーのものである、というようなイメージがあります。

コメントを書くのは、そこにあがりこむ印象を受けますし、敵地でやりあうより自分のブログで反論した方がやりやすいというところもあります。


そもそも、ブログのコメントはブログを書くよりも表現方法が貧弱です。

相手は、図やらソースやらをリッチに示せても、こちらは文字だけで対抗しないといけないところもあります。

完全にアウェイなわけですよね。

それを読んだときのちょっとした反応でも記録したいということで、はてブなんかのコメントにつながっているような気もします。


ただ、ブログにはその距離を置くということで自分の意見を完全に言い切ることができるというところもあります。

これはこれで、Twitterには無い魅力の一つではないかと思います。



距離を縮めるTwitter


Twitterを始めたときの驚きの一つは、自分がよく読むアルファブロガーの人たちと気軽にコミュニケーションが取れてしまったことです。

自分の中では天上人と思えてた人から声をかけてもらうと、一生接点なんて持たないだろうなと思ってた概念が取り払われました

ネットはつながっているとはいえ、その距離はひどく遠かったものが一気に身近に感じられたわけです。


そういうのも、そんなアルファブロガーな人でも自分のテリトリーの話題を振ってくれる発言のゆるさがあります。

ブログだと小難しいことを書いていて、自分の考えをぶつける勇気が無くとも、Twitter上だと日常の会話の中で「それは俺は知ってるぞ!」という反応できるつぶやきに出くわすことがあります。

ある意味、それは発言者の狙いであったりもすると思うのですが、そんな身近な会話が距離を縮めるのだなと感じます。


そしてもう一つ、Twitterの不思議さは、そのコミュニケーションを取る場所が中立な立場に位置づけられているというところです。

発言はパブリックなものですし、タイムラインは自分のものでもその一つ一つの発言はまた、パブリックなものです。

なので、マイスペースと呼べるような場所が無い。

Twitterは個が出やすいサービスなので、マイスペースと呼べるところがあるとすれば、まさしくそれはその人自身ではないかと感じます。


これはTwitterというのが一枚岩のサービスの上に成り立っているからできる芸当なのだと思います。

ブログと一言で言ってもいろんなサービスがありますからね。

Twitterのようなマイクロブログが全盛を向かえ、あちこちでスタートアップしていくと、状況は一変するかもしれません。(なので今、Twitterといえるのだと思いますが)


先に書いたように、Twitterはその距離が近くなることでブログと違って自分の意見を言い切ることが難しくなるところもあります。

その距離の近さがコミュニケーションを加速させてくれ、それがプラスに働くこともあればマイナスに働くこともあるのかなと。


最近のTwitterの関連記事を読んでいて、これからはTwitterだ!というよりも、ブログの地位もそこまで落ちたのかな、という悲しい気持ちもあったりします。

ブログもブログでいい表現ツールだなと、まだまだ思うところはあります。

書ききりたい、というのは一種の自己満足であったりもしますが、例えそれが完璧なものでなくても、とりあえずまとめてみたいというときはブログのほうを選択するな、というのが自分の考えです。


表現ツールの多様化、ブログに代わるもの 」に書いたように適材適所の表現ツールを使っていけばよいな、というのが今の自分の考えでしょうか。





人は意外に合理的 新しい経済学で日常生活を読み解く/ティム ハーフォード
¥1,890
Amazon.co.jp

 

経済学など学んだことも無い私なので、読んだときのイメージは当初のものとは随分と違ったもので、もう少しお金の動きやら株式とか、そんな話をまとめた本かなと思ったりしてました。

経済という言葉の響きは、常にそんなイメージを持っていたので、セックスの話やギャンブルの話、結婚の話などが始まったときはかなりびっくりしたものです。

この辺り、原著まえがき書いてあって著者の幅広い興味や視点が伺えます。

 

私の関心はどこかほかのところに向いていて、株式市場やインフレ率について考えていると思われるかもしれない。だが、もしそうだとしても、それは誤解というものだ。私の視線の先にあるのは、ギャンブラーや売春婦であり、酔っぱらいやギャングである。私はそうした人々を別の視点から見ているにすぎない。経済学者はいつも日常の裏側にある隠れたロジックを探し出そうとしている。

 

その隠れたロジックというものを日常の生活の中に見つけ出す取り組みをまとめたのがこの本になっています。

人は意外に合理的というのは、この本にまとめられているように色々なデータを人々はインプットとして利用し、より合理的な行動を取るものだということをあらわしているのでしょうね。

 

人はインセンティブに反応する

 

この本の中で何度も出てきた言葉がその考えを印象付けます。

 

 

目次

 

人は意外に合理的 新しい経済学で日常生活を読み解く

 

 

第1章 日常生活に潜むロジック

第2章 ラスベガス

第3章 離婚は過小評価されているのか

第4章 どうして上司は給料をもらいすぎているのか

第5章 居住区にて 街角で刺されないための経済学

第6章 合理的な人種差別の危険性

第7章 ギザギザ化する世界

第8章 合理的な革命

第9章 100万年のロジック

 

 

 

 

 

 

 

 

SSL証明書を作成する際に作る、CSR(署名リクエスト)と秘密鍵ですが、そのペアを誤ると当然使い物にならなかったりします。

オレオレ証明書の場合はやり直しがききますが、認証局に申し込むSSL証明書の場合は、取り返しのつかない事態にもなりかねません。

また、複数のFQDNのCSRを作る場合、作業場所や操作を意識しながら行わないとどの秘密鍵とCSRがペアなのかわからない事態にもなってしまいます。


ここでは、申し込む前にきちんとCSRと秘密鍵のペアが正しいかを確認する方法を書いておきます。



秘密鍵とCSRの作成


まずは、秘密鍵とCSRを作成してみます。

この辺りの手順は、各認証局のマニュアルページにも書かれていたりするのであまり詳しく書きません。


# openssl genrsa -rand /dev/urandom -des3 -out private.key 1024

2048 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
............++++++
....++++++
e is 65537 (0x10001)
Enter pass phrase for private.key:
Verifying - Enter pass phrase for private.key:

これで、private.keyという秘密鍵のファイルができました。

秘密鍵を作成する際に入力したパスフレーズをきちんと覚えて起きます。


# openssl req -new -key private.key -out hoge.csr

Enter pass phrase for private.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:Shibuya
Organization Name (eg, company) [My Company Ltd]:hogehoge inc.
Organizational Unit Name (eg, section) []:hoge section
Common Name (eg, your name or your server's hostname) []:www.hogehoge.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

これで、CSR(hoge.csr)ができました。



秘密鍵とCSRの確認


では、本題の2つのペアが正しいか(その秘密鍵から作られたCSRか)を確認していきます。


# openssl rsa -in private.key -text
Enter pass phrase for private.key:
Private-Key: (1024 bit)
modulus:
    00:bc:ac:01:68:65:7b:2b:05:48:ad:f6:af:60:2f:
    22:48:4b:59:2d:03:18:81:d5:78:da:ac:23:cf:55:
    39:bb:c7:a2:2d:f2:7a:73:b2:66:c5:1c:bf:20:59:
    c4:ae:c4:01:f5:eb:68:a2:d8:93:b1:04:f2:0e:ee:
    9a:5f:b9:4b:b6:6b:c6:fa:a3:c9:9a:d0:36:39:db:
    ba:8d:1f:ff:1e:74:69:f8:9e:de:1a:d7:b5:2e:c5:
    27:5b:5d:fa:8c:6e:e9:ac:79:e5:dd:a5:77:ff:1a:
    ec:b7:b7:49:6b:f2:69:ad:6a:1f:37:1b:f5:77:d6:
    c1:57:0f:f9:69:03:8c:1c:7d
publicExponent: 65537 (0x10001)
- snip -

秘密鍵を作成した際のパスフレーズが正しければ、内容が確認できます。


# openssl req -in hoge.csr -text
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=JP, ST=Tokyo, L=Shibuya, O=hogehoge inc., OU=hoge section, CN=www.hogehoge.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bc:ac:01:68:65:7b:2b:05:48:ad:f6:af:60:2f:
                    22:48:4b:59:2d:03:18:81:d5:78:da:ac:23:cf:55:
                    39:bb:c7:a2:2d:f2:7a:73:b2:66:c5:1c:bf:20:59:
                    c4:ae:c4:01:f5:eb:68:a2:d8:93:b1:04:f2:0e:ee:
                    9a:5f:b9:4b:b6:6b:c6:fa:a3:c9:9a:d0:36:39:db:
                    ba:8d:1f:ff:1e:74:69:f8:9e:de:1a:d7:b5:2e:c5:
                    27:5b:5d:fa:8c:6e:e9:ac:79:e5:dd:a5:77:ff:1a:
                    ec:b7:b7:49:6b:f2:69:ad:6a:1f:37:1b:f5:77:d6:
                    c1:57:0f:f9:69:03:8c:1c:7d
                Exponent: 65537 (0x10001)
- snip -

まずは、Subjectの内容がCSR作成の際に指定しているものかを確認します。


- 秘密鍵とCSRのペアが正しいかの確認

先ほどの秘密鍵とCSRの内容を確認した際に表示される、modules(CSRの場合はModules)の内容が一致するかを確認します。

該当箇所だけを抜き出し、別のファイルに書き出して余計なスペースを削除し、diffコマンドで見分ければ早いでしょう。

一致していれば、その秘密鍵から作成したCSRであることがわかります。



認証局に申し込むSSL証明書はタダではないので、その作業には神経を使いますから、事前にきちんと確認を取っておいた方がよいでしょうね。