2012-02-07(火) 人間関係をリアルとバーチャルに区別する意味はあるだろうか
■人間関係をリアルとバーチャルに区別する意味はあるだろうか

今日ちらっと、「ソーシャルとはリアルの人間関係のことである(キリッ」っていう文章みて、こいつバカじゃねーのって思わなかったことにしておくけど、そういう文章をみたんだ。
それで思った。じゃあリアルの人間関係ってなんだ?
この対比で言う場合に、バーチャルのほうはわかりやすい。一度も実際に会ったことがない人との関係。でも、じゃあリアルって?
3年くらいはてなやTwitterでお互いを認識して、一度だけ同じ飲み会に参加して5分くらい話をした人とは、リアルの人間関係?
メールで仕事をもらって、一度も電話することもなく声を聞くこともなく、メールとチャットで打ち合わせをして、納品して請求書送ってお金を支払ってもらった人は、リアル?バーチャル?
お金がリアルだから仕事はリアルだろって?じゃあ仕事の前の打ち合わせだけで仕事が流れたら?Twitterで、なんとなく仕事もらえねーかなーと思いながらつながってるのはリアル?
支払いぶっちぎられたらバーチャル?いやそれはリアルな詐欺だ。
その人のための作業をしたらリアル?そうすると、Twitterでプログラムで困ってる人がいて、「このコードで動くんじゃね?」って見せたらリアル?んで、「それじゃねーよ!」ってつっぱねられたらバーチャル?お金が大事?じゃあ「金くれ」みたいなサービスに100円投げ銭したら?
そもそも、リアルに会うってなに?新宿駅の改札なんかで一日中つったってれば、フォロワーの何十人かとすれ違う気がするんだけど、その人たちとはリアルの関係になるの?リアルってすれ違い通信なの?
気がつかないとだめ?じゃあ、大人数の飲み会で、なんかよくわかんない人と話が盛り上がって、まーあれだれだったんだろうねーと思って帰ってTwitterみて、あーあのときしゃべってたのこの人か!って気づいたら、それはバーチャルのまま?
よくできたロボットがあって、実際に会ってると思ったら遠隔操作だったとしたら、リアル?バーチャル?気づくまではリアル?気づいたらバーチャル?じつは等身大にうつるディスプレイだったら?
結局のところ、人間関係をリアルとバーチャルにわけるのはまったく意味がない。
そもそも、目の前にいる人がリアルなのかバーチャルなのかも判定できない。目の前の人が夢のなかの人物だったり妄想だったりしても、それは判断できない。人が実在するなんて証明はできない。でも、それが夢だったとしても、そこに関係が設定されていれば、その人とはそういう関係だった、ということは事実になる。
存在すると言えるのは、「関係」だけだ。
たとえば宇宙一のお宝を探している5人組がいたとして、これは架空の人たちだから存在しないわけだけど、この人たちが「5人で宇宙一のお宝を探している」という関係は存在している。
人間関係をリアルとバーチャルに区別することはできない。
出会う空間はバーチャルになりえるけども、関係はバーチャルになりえない。人物がリアルであれバーチャルであれ、すべての関係はリアルだ。
2012-02-06(月) 「低要求での品質逆転の法則」というのを思いついた
■「低要求での品質逆転の法則」というのを思いついた

つまり、ソフトウェアのあらゆるパラメータで、要求が低いときには工夫をしないほうが品質が高くなるという法則。
たとえば、アルゴリズムというのは理論的にはデータが増えたときに性能悪化がゆるやかなもののほうがよいということになってる。
でも多くの場合で、よいアルゴリズムは、少ないデータ数では単純なアルゴリズムに負ける。ソートなんかだと、データ数が一定以上のときはクイックソートだけどデータ数が少ないときはマージソートを使うということがよく行われる。「指数時間」かかると言われるアルゴリズムは遅くて使い物にならないということだったけど、それをがんばって「多項式時間」という使い物になるはずのアルゴリズムに改良したら複雑になりすぎて、通常のデータ数なら「指数時間」のアルゴリズムよりも遅いということがよくある。
データの格納にしても、データベースは便利だけど、データ数が少ないときは単純なテキストファイルのほうが検索も速かったりする。
セキュリティでも、日常業務のためのパスワードくらいだと、凝った仕組みを考えて長いパスワードを定期的に変えてもらうより、短いパスワードを使い続けてもらったほうが、トータルのセキュリティが高くなったりする。複雑な運用だと、パスワードを紙に書いて貼る人が増えたり、覚えれなくて平文メールで問い合わせる人が増えたり。
使いやすさも、ソフトウェアが小さかったり短期しか使わなかったり教育が行き届かないときには、あまり凝らないほうがよかったりする。紙をいかに使うかが大事になったり。
こういったことは、あたりまえのように受け入れてるけど、あまりにも どのパラメータでも成り立つのが面白い。そしてソフトウェアの社会的性質を決めてる。
実は、この法則があるからこそ、アイデアだけでも勝負できるソフトウェアができる。要求が低いときには、むしろソフトウェアを不勉強な人が短時間で作ったシステムのほうが便利だったりする。
そうでなければ、あらゆる分野を勉強した人じゃないと実用的なソフトウェアは作れないということになってしまう。
そして、今まで「高い要求」だったものが、ハードウェアの進歩とライブラリの普及で「低い要求」になっていってる。
そこで、どんどん、あまり勉強しなくてもそれなりに役に立つものが作れるようになってる。
逆に、差をつけようと思って勉強しても、少々のことでは「低い要求」として可能な範囲を越えたものは作れず、目に見える差を出すことが難しくなっている。
とはいえ、ソフトウェアでメシを食っていくからには、なんらかの差をつけたい。
そこで、この、低要求のときの工夫したものと工夫してないものの品質の逆転について、一般的な性質があるのかとか、考えてみると面白いかなと思ってみた。
あと、ソフトウェアの性質として、明示的に踏まえておいたほうがいいんじゃないかと。
2012-01-28(土)
■ネットワークに自信のない人は東大講義の情報工学概論Aを見よう

東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。
http://ocw.u-tokyo.ac.jp/category/courselist
その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。
その中で、情報工学概論Aというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。
こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。
http://ocw.u-tokyo.ac.jp/courselist/619.html?teachcat=2
ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくといいんじゃないでしょうか。
ただ、細かい話はまとまった本があったほうがいいと思うので、傍らに「ネットワークはなぜつながるのか」とかを置いておいて、適当に読み進めればいいと思います。
![]()
ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識
- 作者: 戸根勤,日経NETWORK
- 出版社/メーカー: 日経BP社
- 発売日: 2007/04/12
- メディア: 単行本(ソフトカバー)
- 購入: 21人 クリック: 284回
- この商品を含むブログ (82件) を見る
2012-01-18(水) SwingアプリでホットリローディングできるJaveleonが便利
■SwingアプリでホットリローディングできるJaveleonが便利

Webアプリだとホットリローディングできるフレームワークがあったり、NetBeansが勝手にビルド・デプロイしてくれたりして、ソースコードのビルドなどを気にしなくてもいいようになってきてるんですが、Swingアプリではホットリローディングができるというのはなかなかなかったわけです。
で、このJaveleonというのが、Javaアプリケーションでホットリローディングできるようにするツール。
ライブラリじゃないので、普通に作ったSwingアプリなどでホットリローディングできます。
ここではNetBeansプラグインとして使いますが、javaコマンドにパラメータ付加するだけなので、Eclipseなどでも使えるようです。
インストール
NetBeansのアップデートセンターに、次のURLを追加します。
http://javeleon.org/javeleon-for-netbeans-7.1/
NetBeans7.0の場合は、7.1の部分を7.0にしてください。
そしたら、「Javeleon 2.0 Beta 6 for NetBeans」というプラグインがあるので、これをインストールします。
登録
Javeleonはフリーのツールなんですが、なんか、登録しないといけないようです。
とりあえず、適当にJavaアプリケーションプロジェクトを作成して、プロジェクトを右クリックしてメニューから「Javeleon > Register Javeleon」を選択して登録ダイアログを開きます。
URLが書かれたボタンを押すと、登録サイトが開くので、名前とメールアドレスを入力して「送信」ボタンを押すと、ライセンスコードが書かれたメールが来ます。ちなみに、なかなか来ないと思ったらGMailにスパム扱いされてました。
送られてきたライセンスコードを入力して「了解」を押すと、登録完了です。4月までってなってるんですけど、どうやったらずっと使えるんでしょうかね。
プロジェクトにJaveleonを追加
プロジェクトを右クリックしてメニューから「Javeleon > Add Javeleon」を選択すると、プロジェクト中のコードを実行するときにJaveleonが組み込まれます。
試してみる
JFrameフォームを作成して、こんな感じでコンポーネントを配置します。
ボタンのイベントハンドラにこんな感じのコードを入力します。
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
jTextArea1.append(jTextField1.getText() + "\n");
}
このファイルを実行すると、Javeleonが動いていることがわかります。
ボタンを押すとテキストフィールドに入力した内容がテキストエリアに表示されます。
それでは、少し変更してみます。
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
jTextArea1.append(new java.util.Date() + ":");
jTextArea1.append(jTextField1.getText() + "\n");
}
保存すると、Javeleonが自動的にリロードを行います。
ボタンを押すと、変更が反映されてるのがわかります。おぉすごい!
細かい調整するときなんか、便利ですね。いいかも。
2012-01-07(土) Alloyで迷路を解いてみる
■Alloyで迷路を解いてみる

Alloyでいろいろ試してたんですけど、もしかしてこれ迷路とけるのかな?
ということで、とりあえず一本道を定義してみる。
module exec/maze
abstract sig Field{}
one sig F11, F12, F13 extends Field{
conn: set Field
}
pred show{
}
run show
F11、F12、F13というのが移動ブロックというイメージで。とりあえずつながってないインスタンスできた。
じゃあ接続を定義。
fact 迷路{
F12 in F11.conn
F11 + F13 in F12.conn
F12 in F13.conn
}
それぞれF11、F12、F13から移動できる場所を定義。
つながった!
よし、じゃあ迷路を探検するプレイヤーを置いてみましょう。
open util/ordering[Step]
sig Step{}
one sig Player{
place: Field one -> Step
}
時間ごとに動くので、util/orderingでStepを定義して、プレイヤーのPlayerを定義してます。
うーん、なんかよくわかんない。
ProjectionをStepに指定して表示してみます。
ずっとF13にいますね。まあいいか。
最初の位置はF11だと指定しておきます。
fact 初期位置{
Player.place.first = F11
}
よしよし、ちゃんとF11にいます。
んで、そのあとF13に飛んで、そのまま。F13すきやなー
まあ、好き勝手飛び回られても困るんで、つながってるところにしか移動できないようにします。
fact つながってるところにしか移動できない{
all s:Step | let s' = s.next {
Player.place.s' in Player.place.s.conn
}
}
そしたら、あれ、なんかエラーが
This name is ambiguous due to multiple matches: field this/F11 <: conn field this/F12 <: conn field this/F13 <: conn
いろいろ悩んだけどよくわかんないんで、Alloyがみつけたインスタンスをテキスト形式で見てみます。
connまわりはこんな感じ。
this/F11={F11$0}
this/F11<:conn={F11$0->F12$0}
this/F12={F12$0}
this/F12<:conn={F12$0->F11$0, F12$0->F13$0}
this/F13={F13$0}
this/F13<:conn={F13$0->F12$0}
よくわからないまでも、テキスト形式のインスタンスを見るとなんとなく問題点がわかったりします。
あ、なんかF11、F12、F13それぞれにconnがありますね。確かにそういう定義にしてます。これらが別々のものとして扱われていたようです。
ということで、connはFieldのフィールドにします。
abstract sig Field{
conn: set Field
}
one sig F11, F12, F13 extends Field{}
これで、ちゃんとインスタンスがみつけられるようになりました。見てみると、F11→F12→F11の順に移動します。
ここで、定義が多くなったときに書きやすいよう、迷路の定義の書き方をかえておきます。
fact 迷路{
F11->F12 +
F12->F11 + F12->F13 +
F13->F12
in conn
}
さて、それでは、F13をゴールとして、Alloyさんがちゃんとゴールにたどりつけるか試してみましょう。
pred show{
some s:Step | Player.place.s=F13
}
きゃあ!ショートカットされたw
Alloyさん・・・
まあ、迷路の定義で、その経路を含むことは指定していますが、その経路以外を含まないことは指定してないので、ちゃんと、その経路だけを含むようにしましょう。in じゃなくて=にすればいいみたい。
fact 迷路{
F11->F12 +
F12->F11 + F12->F13 +
F13->F12
= conn
}
これで、ショートカットされずに一歩ずつF11からF13まで進むようになりました。
あとで気づいたのだけど、最初の接続インスタンスで、別候補みると、ショートカットも出てました。Alloyの出した実例は、全部みておいたほうがよさそうです。
じゃあ、もう少し複雑な迷路にしてみましょう。こんな感じの迷路にしてみます。
フィールドの定義を増やします
one sig
F11, F12, F13,
F21, F22, F23,
F31, F32, F33
extends Field{}
で、接続はこんな感じに
fact 迷路{
F11->F12 +
F12->F11 + F12->F13 +
F13->F12 +
F13->F23 +
F21->F22 + F21->F31 +
F22->F21 + F22->F23 + F22->F32 +
F23->F13 + F23->F22 +
F31->F21 +
F32->F22 + F32->F33 +
F33->F32
= conn
}
あとはゴールの位置を変えて実行です。
pred show{
some s:Step | Player.place.s=F33
}
あれ、見つからない。
デフォルトだとインスタンス数が3つまでなんですけど、今回3ステップではゴールみつからないので、10ステップくらい動かしてみましょう。
run show for 10 Step
これで無事7ステップ目でF33にたどり着きました!
論理パズル解決言語Alloyすごいです!問題を定義すれば、勝手に解法をみつけてくれます。
ほかにも「3人が並んでいる。和子の隣に健二がいて、高志は健二の隣にいない。真ん中はだれか」みたいなのも
Alloyは、形式手法とか肩肘はって使うんじゃなくて、論理的な考え事をするときにちょっと試してみるくらいの感覚で使うのがいい気がします。
そうすると、手軽で便利で、そして強力なツールになると思います。
最終的なソースはこんな感じ。





















違うと思っていたのに同じだったから悩む、というのもありうると思います。
問題の理由をソーシャルとリアルの違いにしているから。本当の理由がそこにあることなんて、じつはそれほどない。
仕事関係の仲間、趣味の友達、学生時代の友達、家族関連の知人、などなど。
ネットの人間関係ができたからって、特に「リアル」と分ける必要なんてないですよね。
ご意見におおむね同意です。全てはリアルの関係である。
でも、バーチャルに端を発する関係は、リアルに端を発するものよりも、ずっと関係が切り易くあります。おそらく、関わる社会構成要素が少ないからでしょう。同じリアルな関係でも、バーチャル発はずっと砂上楼閣ではないかな、と思った次第です。
だからって、バーチャル発を否定する気はありません。リアル発より、本人がどう関わるかが、ずっと問われている、とは思うのみです。あとは、ノンバーバルコミュニケーションがしづらい部分をどう解決するか、とも思います。
しかし、すべての人間関係を一緒くたにはできないはずです。
家族、友人、ゲーム仲間、仕事仲間、上司、部下・・・
人間関係にはいろいろな種類があって、種類によって接し方を変えてると思います。
Twitterの知り合い、とかも、そういった人間関係の一種なのだと思います。