前の日 / 次の日 / 最新 / 2006-04

/home/pochi/ChangeLog / 2006-04-04

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

2006-04-04 Tue

メーリングリストでの議論テクニックに対抗する [ネタ]

テクニックを駆使してくる困った人に対抗する手段は
知っといたほうが良いと思う。

基本は以下のような感じ。

- 相手にしない。できればこれが一番。
- 要約して、論点を明確にする。
- 論点をずらしてきたら、その論点は完全に無視する
- 論点以外の話をしない

まともに相手をするとすごく腹がたつので、
パターンに落としこんで機械的に返答するのがコツ。
困った人が使う、論点をずらすためのテクニックの常套手段に、
相手を怒らせるような表現をして、局面を複雑化する、
というものがあるので、「まずは冷静になる」、
というのはとても重要。

それと「悪魔の証明」を要求された場合、
つまり、ないことを証明してみろ、と言われた場合には、

- 何々がなかった、ということを証明するのは
  「悪魔の証明」なので困難です。
- むしろ「あった」ということを証明していただけませんか

と冷静に切りかえす、と。

でもね、困った人って、常人と比べて信じられないぐらい
パワーがあったりするので、うまーくコントロールできれば、
本当はおいしいんだよね。

参考)
議論パターン
http://www.shos.info/develop/oo/dscsnptn.html#chapter4

Wikipedia - 悪魔の証明

大衆論法: 論点ずらし
http://wiki.livedoor.jp/totutohoku/d/%A1%CA%B5%C4%CF%C0%A5%C6%A5%AF%A1%CB%C2%E7%BD%B0%CF%C0%CB%A1%A1%A7%CF%C0%C5%C0%A4%BA%A4%E9%A4%B7

以下の本に書かれているノウハウはかなり参考になる。
--> [2005-12-30-3]
ブログ&掲示板攻撃・防衛マニュアル

Referrer (Inside): [2006-04-12-1]

O/R マッピングツール CROSSFIRE O/R、NetBeans 5.0 プラグイン実装完了 [computer]

http://crossfire.jp/en/dbfw/nb/

Eclipse のプラグインとして作られていたものを、
NetBeans 5.0 のプラグインに作り直したもの。
開発者とそういう話をしたのが、先月なので --> [2006-03-07-9]
1ヶ月かからずに実装しちゃったわけだ。

使い方はデモを見ればすぐにわかる。
Eclipse 版同様、良くできている。

ウェブが英語で書いてあるのは、Sun の本社向けなので。
このまま行けば JaveOne でのトップトピックス扱いになるらしい。

NetBeans 5.0 は、まだまだプラグインが少ない。
なのでこの O/R マッピングツールが NetBeans における開発で、
標準的な地位を占める可能性は充分にある。
その上、NetBeans 5.0 は Eclipse と比較すると

- インストールが簡単。JDKに付いてくる。
- 画面も GUI で作れる

という優位性があるし、Sun も力を入れまくっているわけで、、、、

海外でパッケージが売れまくったりすると、
あっというまに大金持ち、というシナリオも充分にありえる。
そうなると周辺のビジネスも当然おいしいわけで、、、、

うまくいったら、肉でも食わせてね。

追記)
NetBeans のパートナーリストに載ったらしい。

NetBeans Partners
http://www.netbeans.org/community/partners/

さらに追記)

開発者の i-zuka さんがブログを開始。

CROSSFIRE O/R の日記
http://d.hatena.ne.jp/i-zuka/

しかも英語版のブログも同時に開始。やるなあ。

CROSSFIRE O/R
http://crossfireor.blogspot.com/

JANOG ML の JPNIC の提言に関する話で思ったこと [JANOG]

さすが!!、というやりとりで収束しつつあるけど、
メーリングリストって、つらいメディアだなあ、と思った。
議論をして結論を出す場じゃない、っていう前提はあるんだけど、
意見を交換する場合にも、以下のようなことが障害になりがち。

- 各人の立場がわかりにくい
- 各人の論点が明確じゃない場合がある

コミュニケーションスキルが高ければ、メーリングリストでも
ちゃんと意見交換をしたり、有意義な結論を出すことは可能なんだけど、
みんながみんなスキルが高いわけじゃないんだよね。
仕事のやりとりとかだと、メールじゃらちがあかない、と思ったら、
実際に会って話をするとか、電話するとかして、
コミュニケーションギャップを埋めるんだけど、
JANOG みたいなメーリングリストの場合、
全員に電話をかけまくるっていうわけにいかないし。

話をしていて、なんか噛み合わないな、と感じたらすぐに、
会議とか宴会とか、そういうリアルイベントを発生させるべきなのかもね。
実際に顔を合わせたりすれば、agenda とかポジションペーパーとか、
コミュニケーションを助けるツールを必要に応じて導入できる。
もちろんなんらかの結論を出したい場合には、メンバーを選定して、
クローズドな場で決めるほうが絶対効率的なんだけど、
結論を出さずに軽いブレストをしたい、というような話は、
それなりにあるんじゃないかと思う。

JANOG 居酒屋とか JANOG カフェとかがあれば良いのかな。

- 今日はこのネタやるぜ、とか広報。
- 議論の内容は Podcast で垂れ流し。
- 有意義そうなら、誰かが wiki か何かで、
  まとめサイトを作る。
- 有意義な議論に発展しそうなら、meeting や wg 行き。

こんな感じで。
チェアはかなり大変そうだけど。

そういうことが実際にできる場としては、
神田バーが一番それに近いかな。
でも他にもそういう場所がいくつか欲しいなあ。
IPリーチャビリティがあって、プロジェクターがあって、
飲食ができて、貸し切りができて、安い、
そんな感じの場所。

# 汐留のソフトバンクのバーとか、素敵だよねえw

なんかの wg 作ったときに、そういう運用を
実験してみれば良いのかな?。

Referrer (Inside): [2006-04-12-1]

無料書式フォーマット いただき君 [情報]

http://www.urbanproduce.com/download/itadakikun.html

便利かも。

仕事をする上ではこういう書類が必要になるよ。
それぞれどんなシチュエーションで使うか、あててね。
(まいどんのポーズクイズ風)


参考)
Wikipedia - ストレッチマン2

こんな感じで、新人教育にも使えるかも。

apache を高速化する FreeBSD kernel モジュール [computer]

http://www.mimori.org/~h/tdiary/20060330.html#p03

accf_http, accf_data なんていうモジュールがあるのね。
yapache っぽいことができるわけか。

参考)
Hacking Apache HTTP Server at Yahoo! (naoyaさんによる解説)
http://d.hatena.ne.jp/naoya/20060202/1138891578

Tony Li、無線MESHネットワークの会社(Tropos Networks Inc.)へ [computer]

http://www.lightreading.com/document.asp?doc_id=91871
via http://www.hirochan.org/tdiary/?date=20060404#p01

CISCO のルータを作って、
Juniper のルータを作って、
Procket のルータを作ったスーパーエンジニアが、
無線MESHネットワークの会社に移った。
今度は、何を作ってくれるんだろう。
ワクワクする。

光制御とかそういう方向に進むのかな、と思ってたけど、
無線だったのはちょっと意外。

光に進むのかな、と思った トニー・リーへのインタビュー記事
http://japan.cnet.com/interview/story/0,2000050154,20069555,00.htm

参考)
Tony.Li ドメインに関するトリビア --> [2004-06-17-1]

フロー体験 喜びの現象学 []

http://www.ringolab.com/note/daiya/archives/004389.html

橋本大也氏の書評。

「フロー体験」という概念は知らなかった。
便利な概念かも。

スパイダーソリティアに没頭したり、
ガンプラを作ったり、とそんなときの言い訳に使えそう。

「これは、フロー体験なのー!」、と。

。。。。駄目っぽいな。

フロー体験 喜びの現象学

開発の生産性とは [computer]

http://happiese.exblog.jp/3743899

費用対効果と考えると、開発プロセスにおいては、

- 初期学習コスト
- 調査コスト
- 環境構築コスト
- 開発環境、ライブラリのサポート
- コード記述量
- メンテナンスコスト
- 例外的対応のためのコスト

この辺を考えなきゃいけない、と。

この視点で見ると、やっぱり Perl、Ruby、Python って、
生産性が極めて高い言語なんじゃないかと思う。
ほとんどすべてに項目で Java なんかより優位だよね。

まあ、結局はプログラマの質によるんだろうけど。

2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12

最終更新時間: 2020-06-10 21:15