2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2007年10月31日1

まぁ、自分も人月否定派になるのかな (笑)。ここでも
何度かそういったことを書いた気がするし。

コストということでいえば、この商売、人月からは逃れ
られないのは明らか。開発にかかる費用のほとんどが
人件費なんだから。

で、商売なんだから、お客さんにコスト、つまり原価を
教えるのは自殺行為っていうのは、誰が見ても正しい。

人月の問題っていうのは、結局、『人月を見積もりに使う
ことはできるか?』っていうことですよね。

優等生的に答えるなら簡単で、『変化が少なければ使える』
っていうことになります。ビジネスが変化せず、開発チームも
変化しなければ、積み重ねたデータの重みが増すし、
そうなると平均的な工数っていうのが威力を発揮します。

だから、当然、変化が多ければ人月は使えないっていう
ことになります。ビジネスが変化して、開発チームも
変化するなら、過去のデータをそれほど信頼できないし、
平均的な工数っていうのもそれほど信頼できなくなる。
(それでも過去のデータは大切だけど。)

で、agileは、この変化の多いところでソフトウェア開発を
やるにはどうすればいいかっていう話なわけです。変化が
多いから、長期の見積もりを重視しない。変化が多いから、
計画を頻繁に見直す。変化が多いから、リリースを短く
する。変化が多いからリファクタリングを重視する。

--

別の見方をすれば、変化の少ないところじゃ儲からない
っていうこともできるわけです。そういうところは陳腐化が
激しいから。いや、それでも町の八百屋さんみたいに残る
ことはできるかもしれませんけど。

あと、コストがそのままソフトウェアの価値に転化される
わけではないという、ごく当たり前のこともあります。
クソゲーはクソゲーだし。

--

チッ、辞めてたのか。hotlinksでも読まないようにしてた
から知らなかった。

バカタレが。説教の1つもかましたいところだが、まぁ、
過ぎたことはしょうがない。

本家Permlink


2007年10月31日

itojunさんとお会いしたことはないのですが。

自分より年下だったと知って驚きました。それくらい
古くから活躍されていた方だったので。

非常に残念です。

本家Permlink


2007年10月29日

このページ、相変わらず影響力の小さいこったな (w

いろいろ書こうとしたけど止めとくわ。腹立つだけ。


--

自動化の前には、手順を確立するっていう段階がある。
それを標準化と呼ぶ人もいるみたいだけど。でも、標準化
というと自分はISOとか大げさなものを思い浮かべるから、
その言葉は使わない。

で、自動化ができるかどうかにかかわらず、手順の確立
っていうのは大切だよっていう話。確立された手順って
いうのは、みんなで共有できる知識なわけ。

もちろん、その知識をコード化するのが、自分らプログラマ
にとって一番いいんだけど。でも、そうできないことも
ある。そんなときは文章にするしかないんだな。だから、
手順を確立するっていうのは、その確立された手順を
文章にすることが含まれてるわけ。くどいようだけど、
文章よりコードのほうがいいんだけどね。

あと、手順を確立するには、ある面でバカになんないと
できないことがある。似たような繰り返しをちょっとずつ
改善していって、1つの手順が確立されるわけだから。
イヤになって途中をスッ飛ばしてたら、手順っていうのは
なかなか確立できない。こういうシツコサっていうのは
やっぱり必要だと思うよ。

本家Permlink


2007年10月27日

今回は消さないよ。

https://www.release.tdnet.info/inbs/1a1a0fd0_20071026.pdf

ドリコムが下方修正したんだけどさ。だから、上場詐欺の
ダシにRails使うんじゃねーっていうんだよ。ナンチャラ賞
とか勉強会とかそんなことやってられる状況かどうかよく
考えろよ、バカどもが。

http://www.technobahn.com/cgi-bin/fn/plot?sid=b138f44ed3&r=3m&c=3793&p=

これがチャートなんだけどさ。怪しすぎるだろ、この動き。
だって、上がる材料なんか全然ないんだから。ここ最近は
むしろ下がるほうの材料しかなかったんだから。ハメようと
してんの、ミエミエじゃねーか。

--

http://miau.jp/

取り立てて自分でアクション起こすわけじゃないんだけど。

少なくともMIAUの:

   1. 違法サイトからのコンテンツダウンロード違法化への反対意見表明
   2. コピーワンス及びダビング10技術の採用に対する反対意見表明
   3. 著作権の保護期間延長に対する反対意見表明

っていうのは自分も賛成なわけで。

何回か書いてるけど、下のcopyright noticeは、半分
シャレで、半分本気なのね。要は、ここに書いてることは
全部public domainだっていうこと。ここ以外でも、
jitu.orgで公開してるのは基本的にはpublic domain。
移植とかの場合は、オリジナルのライセンスを引き継いで
る場合もあるんだけど。そういうのは明示してあるはず。

もともとこのページっていうのは、pre.htmlっていう
静的なファイルに書かれてて。新しい記事書くときは、
それを上書きするようなスタイルだったのね。だから、
permlinkとか張りようがなかったんだけど。

でも、そのときからpublic domainであることは謳ってた
わけで。だから、何かあったら引用するなり、丸ごと
引っぱるなりしてくださいっていう方針だったのね。

そういうスタイルでやってたら、このページをアーカイブ
する人が出てきたのね。ロボットで定期的にチェックして
時系列に並べたり。RSSまで配ってたりする (笑)。

もちろん、自分はそういうのはwelcomeなわけですよ。

もちろん、そういう外部のアーカイブの中身にまで責任は
持てませんけどね。こっちで消した内容がそっちに残って
るとか、そういうのは自分の関知するとこじゃないわけで。

細かいこといったらアクセス数が減るとかあるかもしん
ないけど。でも、別にアフィリエイトやってるわけじゃ
ないし。そんなことより、プログラミングのネタを提供
できた喜びのほうが全然大きい。

だからといって、public domainをみんなに勧めるつもりは
毛頭ないし。でも、自由な素材が増えてほしいとは願って
るけどね。

--

http://d.hatena.ne.jp/propella/20051030/p2

『スゴス!』というのでつられてsubtextのデモを見てみる。

http://subtextual.org/subtext2.html

面白い。いや、面白いという言い方はおかしいのかも
しれないけど。でも、面白いとしかいいようがない (笑)。

最初のほうは『フーン』て感じで見てたんだけど、多態に
話がつながっててビックリ。

こういうvisual programming系って下火になったのかと
思ってたけど、まだ研究してる人がいるんですね。

こういうのが主流になるかどうか。以前だったら自分も
否定したと思うんですけど、今は多少現実味を帯びてる
感じがするんですよね。

--

SBPPより:

  I'm constantly amazed at how even a little help cleaning up small
  problems reveals the source and solution of much bigger problems.

小さなことからコツコツと (笑)。でも、そういうもん
だと思うんですよ。大きなリファクタリングが必要な
ときもありますけど。でも、その前にやるべきことは
たくさんあるんですよ。とかく、自分らはゼロからやり
直そうとしたり、一気に解決しようとしがちなんですけど。

だから、『あとできれいにするから』っていうのは、
ダメなイイワケでね。実戦だとそうもいってられないって
いうのはあっても。やっぱり、こういうのは心がけなん
ですよね。実戦の中でどれだけ基本に忠実でいられるか
っていう、ね。

本家Permlink


2007年10月25日

今回の件も、Googleはダンマリを決め込むのかねぇ。
``Don't be evil''とかいっておきながら、実際に
やっちゃったときはシカトするからなぁ。

本家Permlink


2007年10月24日2

いや、やっぱり計画を頻繁に見直すことなんじゃないかな。

上流も、下流も、すべてが変化する中で、その変化に
柔軟に対応するには計画を見直すしかないわけで。

もし仮に、計画を見直すことをせずに、他のagile的な
実践をやったとしても、大して効果は上がらないでしょう。

計画を見直すっていうのは、言い訳めいたことじゃなく、
現実を見つめ、現実に合わせるっていうこと。当初の
計画どおりに進行してるんなら、無理に計画を変える
必要もない。それでも、今、本当に計画どおりに進んで
いるかどうかは定期的に確かめる必要はある。

--

迷うというのは考えるとはちょっと違うんだな。

設計っていうのは決断の連続といわれるわけだけど。
決断には迷いはつきもので。だから、できるだけ迷いを
減らさないと速くならない。

選択肢がいくつかあるなら、それらを比較して、どれかを
選べばいい。

選択肢がなく、迷子のようにさまよってるような状態なら、
まず自分の位置を確かめる。で、それから、どうやって
進んでいくかを考える。その「どうやって」っていうのは、
具体的で、着実な「手順」じゃないといけない。でないと、
また迷子になっちゃう。

それと、迷ったんなら、助けを求めることをためらっちゃ
ダメ。自分で選択できないんなら、誰かに意見を求める。
自分の位置がわからないなら、誰かに尋ねてみる。

--

そういえばこないだ、「引っぱってくれる先輩がいない」
っていう言葉を聞いた。でも、そんなの甘えじゃないかな。

本家Permlink


2007年10月24日1

『東洋経済 10/27』、『Opinion』(養老孟司) より

  昔から日本には、“手入れ”という自然と付き合うための知恵があります。
  稲を育てる時、米をたくさん収穫するために絶えず注意を払いながら丁寧に
  面倒を見て育てるでしょう。相手を認めて調和を求めながら自分の目指す方
  向へ持っていくのが“手入れ”の考え方です。手入れの世界は、自然でもな
  く人口でもない秩序と無秩序の中間に位置している。私は、それが環境問題
  を解決するヒントになると考えているのです。

だとすれば、『手入れ』を内包したやり方というのもまた
日本的なソフトウェア開発ということができるのでは
ないか。つまり、システムを『絶えず注意を払いながら
丁寧に面倒を見て育てる』ということ。

本家Permlink


2007年10月24日

Rubyとその周辺からgdgd感を取ったら、何も残らないん
じゃないか。

本家Permlink


2007年10月23日1

バグを見つけるとうれしそうにする人っているんだよな。
苦笑いも含んでるんだけど、それよりもうれしい感情の
ほうが大きいように見える。

--

へー、東大がGoogleに広告を出すご時世なんだねぇ。

本家Permlink


2007年10月23日

今の自分のイチオシは『手のりおかん』!

ただ、ネタがネタだけにいつまで続くか心配 (笑)。

本家Permlink


2007年10月19日1

class Bag
  def initialize
    @hashs = [{}]
  end

  def [](key)
    results = []
    @hashs.each{|h| h.has_key?(key) and results << h[key]}
    return results
  end

  def []=(key, value)
    @hashs.each do |h|
      if h.has_key?(key)
        h[key] == value and return value
      else
        h[key] = value
        return value
      end
    end
    h = {}
    h[key] = value
    @hashs << h
    return value
  end

  def values
    results = @hashs.map{|h| h.values}
    results.flatten!
    return results
  end
end

class Uline
  def initialize(pos, line)
    @pos = pos
    @size = line.size
    @code = line.hash
  end
  attr_reader :pos, :size, :code

  def uniq?(input, ulines, line)
    founds = ulines[@code]
    founds.empty? and return true
    curr = input.tell
    begin
      founds.each{|f| f.readline(input) == line and return false}
      return true
    ensure
      input.seek(curr)
    end
  end

  def readline(input)
    input.seek(@pos)
    return input.read(@size)
  end
end

def uniq_read(input)
  ulines = Bag.new
  loop do
    pos = input.tell
    line = input.gets
    !line and break
    newline = Uline.new(pos, line)
    !newline.uniq?(input, ulines, line) and next
    ulines[newline.code] = newline
  end
  return ulines
end

def uniq_write(input, ulines)
  input.seek(0)
  lines = ulines.values
  lines.sort!{|a, b| a.pos <=> b.pos}
  lines.each{|uline| print(uline.readline(input))}
end

File.open(ARGV[0]) do |input|
  ulines = uniq_read(input)
  uniq_write(input, ulines)
end

本家Permlink


2007年10月19日

「Ctrlキーを、曲げた小指の背中 (爪の付け根あたり) で
押す」というのをWebのどこかで教えてもらって、それを
やってもう1年以上経つかもしれないんだけど、そんなに
違和感なくEmacs使えてる。これのおかげでデルのクソキー
ボードでもそれなりにEmacs使えてる。

本家Permlink


2007年10月17日1

こんなことを書くためにこのページがあるわけじゃないんだよ。

--

勘違いしてほしくないのは、agileだなんだいっても、
ものを作る技術はしっかり持ってなきゃダメなんだって
ことなんだよ。ものを作るために自分らはやってるんだし。

で、ものを作る技術っていうのは、ある程度確立してる
んだよ。いや、確立っていうと完成してるような印象を
与えちゃうかもしれないけど、少なくとも『有効な手段や
手法』っていうのがあって、それが広く知られてるわけだよ。

まず、コンピュータ科学っていうのが厳然として存在
するわけだ。そして、そこから派生してソフトウェア
工学と呼ばれるものや、ソフトウェア開発方法論といった
ものがあるわけだ。そうした先人の知恵を学ばないのは
非常に愚かなことだろう。

コピペして変数名をちょっと変えるとか、そんな小手先の
テクニックを覚える前に、もっとやることがあるだろう。
そういうところを疎かにしているから、いつまでたっても
悪循環から抜け出せないんじゃないのか。

--

ちょっとくどいけど書いておこう。

上の話は『再利用』の範疇に入る。再利用っていうのは、
この世界では重要なテーマであって、先人たちの知恵って
いうのも数多く積み重ねられている。だが、再利用の
話っていうのは難しくって、泥沼に入りやすい。それでも、
1ついえるのは、『再利用は1日にして成らず』っていう
ことだ。だから、常日頃、どんなふうにコードを書いてるか
が大切になる。だから、普段の意識が低いと、いつまで
たっても再利用はおぼつかない。納期に追われながらも、
それでも必死に再利用できるような形でコードを残すしか
ないんだよ。

いいか? 再利用っていうのは、誰かが与えてくれた
ライブラリやフレームワークを使うことだけじゃないん
だぜ? 所詮他人が書いたコードなんだぜ? 自分の仕事に
合わなかったら再利用もクソもねえ。だから自分で、
自分のために再利用できるコードを残すんだ。

そうやって自分の道具を増やしてくんだよ。だって、
プロだろ、オレたちは。

本家Permlink


2007年10月17日

プログラム設計の基礎を2日で学ぶって、ムリがありすぎだろ!

本家Permlink


2007年10月15日

http://arton.no-ip.info/collabo/backyard/?HistoryOfWebApplication

非常に勉強になりました。

これに書かれているようなSIerの世界とは別に、やっぱり
自分は馴染ソフトウェアのことを思ってしまうわけです。

すでに中規模の企業でもサーバがいくつか立ち上がってる
のも珍しい話じゃないわけで。そういうのから情報を
マッシュアップするような話になってると思うんですよね。

そういう馴染の世界なら、基幹系のような厳密さも、
外向けのようなセキュアさもいらない。

一昔前なら、そういうのがあると、SIerに頼んで『それ
統合だ!』みたいな話になってたと思うんですけど。でも、
今だったら自分でPHPでも使ってやれちゃうわけで。

で、本当に価値のあるものって、そういうとこから生まれる
ような気がするんですよね。

--

ああ、あと、Wikiのインパクトはやっぱり大きいかな。
馴染ソフトウェアの話も、Wikiが自分の頭の中にある
から響くのかもしれません。

まぁ、IRCをベースにしたり、tracをベースにしたり、
いろいろやり方はあるでしょうけど。ただ、そういうった
ツールを、そういったツールのままでしか使わないのは
ひどくもったいない話で。そこからいかに応用できるかが
大事だと思うわけです。

だから、Wikiにしても、自前で拡張するとか、そういう
ことをしないとダメ。Wikiは大抵オープン・ソースだし、
基本的にはシンプルなテキストだし、いくらでもツブシは
利くはず。

本家Permlink


2007年10月13日

ああ、youtubeには再生回数が表示されるね。

--

で、見たんだけど、善意に解釈したら、攻め手がなかった
んだろうね。どう攻めていいかわかんなかったら、投げとか
そういう反則行為を出すしかなかった。要は、技の引き出しが
少なすぎる。

それと、あのスタイルだと、上手い相手にはパンチは当たん
ないよね。だって、相手見てないもんね。途中でアップ
ライトに構えることもあって、そんときは手も出るんだけど。
頭が低いから突っ込んでもすぐクリンチされちゃうし、
それで余計自分のペースでできなくなっちゃう。

サミングとかはわかんない。そこまで自分の目は肥えて
ない。ただ、それほど汚い印象はなかった。っていうか、
9Rまでしか見てないんだけど。

まぁ、でも、身体はゴツイけど、ボクシングとしては
高校生に毛が生えた程度っていうのがマトモな評価なんじゃ
ないの? 世界挑戦なんか、少なくとも5年早いね。

つーか、こんな試合が世界戦でいいわけねーんだけどな、正直。

本家Permlink


2007年10月12日

一方でネットは寡占化を促進する面があるわけで。

たとえばAmazonとかもそうだし。Amazonの存在そのものを
ヒットと呼ぶこともできるわけだし。

だから、何をヒットと呼ぶかによるよな。それに、その
『ヒット』の存在が既存のチャンネルに乗ってないだけ
っていうことも考えられるわけだし。

たとえば、youtubeに乗せた動画がどれくらいの人に
見られているかとか、そういうのはわかんないわけで。
ひょっとしたら何千万もの人が見てる可能性だってある。

お金をかけないといいものが出てこないっていうのは、
必ずしも正しいわけじゃないし。ピアノ? ピアノなんて
タカが知れてる話でしょう。だって、人一人育てりゃ
いいだけなんだから。

世の中には、アブラモビッチ氏みたいな豪快なパトロンも
いるわけでね。だから、その時代時代でパトロンなんて
生まれるもんじゃないの? パトロンが生まれないものは、
たとえそれがゲージツと呼ばれようが、大したもんじゃ
ないってことなんじゃないの?

本家Permlink


2007年10月11日

何度か書いたことがあると思うんだけど。自分は、昼寝
するヤツが信じられないのね。目の前にPCがあるのに、
なんで昼寝するの?っていう。だから、もし自分が面接官に
なれたら、『あなたは昼寝しますか?』って聞くね。
で、昼寝するヤツは必ず落としてやる (笑)。

これが肉体労働やってるとかなら話は違うけど。そうじゃ
なくってプログラマなわけでしょう、自分らは。
だったら、PCの使い方くらい知っとけと。

Webも見れるし、使ってるのもフツーのPCなんだから、
プログラミングもできるし。

いや、『そこまで仕事にしたくない』っていうんなら
いいけど。でも、そうじゃないんなら、無自覚なまま
寝るなと。『することがないから寝る』とか、そういう
バカな理由で寝るなと。することがないのはテメーが
バカなだけだからなんだと気づけと。

昼寝するくれーなら、外散歩したほうがマシだっつの。

--

ソフトウェア開発っていうのはBuzz Wordの世界なんだけど。
でも、そういうのんじゃ、やっぱり底辺にまで響かないん
だよな。もっとわかりやすい言葉じゃないと。まぁ、
自分も好んで横文字使うんだけども。

製造業じゃ標語とか作るじゃん? そういうのだって
効果があるから定着してるわけでしょう。だったら、
こっちでもやりゃぁいいじゃん? ソフトウェア開発の
標語募集みたいなことを。

そういうのんでいえば、こないだのtokuhiromさんの

  mod_perlのプロセスは血の一滴。

とかは秀逸だった。あんまり標語っぽくないけど。

--

日本でコミュニケーションの話になると『ホウレンソウ』
ってのが出てくるんだけど。これなんかを見ても、やっぱり
日本には『議論』の文化が根づいてないんじゃないかと
思うのね。

報告、連絡、相談っていうのと、議論っていうのは、
当たり前だけど全然違う。で、議論っていうのは、この
ホウレンソウに比べても全然劣るもんじゃないし、コミュ
ニケーションの手段としては絶対に必要なものなのね。

日本で議論っていうと、ディベートのニュアンスが強い
んだけど。でも、そういうんじゃなくってね。お互いが
納得するための議論であって、別に勝ち負けを競ってる
わけじゃないんだから。

もちろん、議論によるコミュニケーションっていうのは、
民主主義的な開発っていう、最近の自分のテーマにも
沿うものでもあるんだけど。

--

何か問題が起きたとき、誰かに助けを求めるのは、全然
恥じることじゃない。さらにいえば、助けを求めることで
相手に迷惑がかかるなんていう考えも間違ってる。

技術者っていうのは、問題を見つけたときに、独力で
解決したがるもんなんだけど。でも、それで解決までに
余計に時間がかかって、被害が広がっちゃぁモトもコも
ない。

問題っていうのは、原則的に、全員で共有し、全員で解決
すべきことなのね。

前にも書いたことがあるけど、アンドンのヒモを引く勇気を
持ってほしい。

本家Permlink


2007年10月09日

ワッフル、ワロタ (w

Ruby magazineで連載キボー (笑)

本家Permlink


2007年10月06日

もう売ってないかもしれないけど、『東洋経済』に
カプコンの記事が載ってる。ゲーム業界は、ソフトウェア
開発でも特殊な分野といえるけど、それでもやっぱり
ビジネスであることに変わりはないわけで。いわゆる
『スーツとギークの対立』なんて甘いことをいってたら
ビジネスが立ち行かなくなる。みんなが同じ方向を向いて
いながらも、それぞれがそれぞれの立場で最善を尽くす
ために議論し、妥協し、計画を立て、実行していく。
組織が変わるということの本質はそこにある。

本家Permlink


2007年10月04日1

>> 329
ワッフルワッフル

本家Permlink


2007年10月04日

あのLinusも、まつもとさんも、そして自分も、大差ない
PCを使ってるわけでね。たかが数万のPCを持つという、
もうそれだけで世界最高峰のレースに参加する資格は
持ってるわけ。

本家Permlink


2007年10月03日

いや、「副作用のないまま縮めろ」っていうんだから:

a

でもいいし、それこそ何も書かなくってもいいんじゃ
ないか? "a"という答えのどこにも副作用はない!

本家Permlink


2007年10月02日3

バグを潰すのは、まぁ、単純な話なんだよ。でも、
そこで終わってちゃあ、また明日も似たようなバグを
潰すことで時間がつぶされちまう。

なぜバグが出たのかということを考えなきゃいけない。
コミットするときにコンパイルしたのか? コミットする
ときにユニットテストを通したのか? コミットするときに
動かしてみたのか? 似たようなバグが過去にあったん
なら、そこに構造的な問題がないのか? 設計に問題が
ないのか? 組織に問題がないのか? どうしたら似た
ようなバグを防げるのか? そういうことを考えることが
当たり前になるように習慣づけなきゃいけない。失敗から
学ばないんじゃあ、失敗がただの失敗に終わっちしまう。

本家Permlink


2007年10月02日2

結局よお、一人一人が、1つ1つのソースファイルに
誇りと責任を持てなきゃ、品質なんて上がりゃしねえ
んだよ。

--

いろんなやり方があるわけだけど、自分らはsustainable
であることを重視するわけだ。ヨソじゃ短期間でガツガツ
やるのがそこのスタイルかもしんないけど、自分らは
違うということなわけだ。

--

http://www.jitu.org/~tko/doc-jp/xpe2.html

いまだにXPやagileを「天才のためのやり方」などという
悪質なデマが飛び交ってるのはなぜなんだ?

上のページに抜き出したのはXPE2から抜き出したものだ。
その中には天才じゃなければ理解できない、実践できない
というものは1つもない。いいか? 1つもないんだぜ?
むしろ、そこから連想されるのはトヨタ生産方式のような、
凡人のためのやり方だろう。

傍流を見て語るなかれ。源流に触れるべし。

本家Permlink


2007年10月02日1

改めて「士気」という字を眺めてみると、けっこう硬い
というか、そういう印象が強いかな。士気というと軍隊
とか、そういう戦いの集団をイメージさせる。

そういう戦いのイメージも嫌いじゃないんだけど、でも、
もうちょっと柔らかいのでいえばモラルということに
なるんだろうなぁ。モラルというといきなりフニャっと
したというか、曖昧な感じになっちゃうけど。

--

あはは。贈る相手は選ばないと。
これでアンチがまた一人増えた (笑)。

すみません。読もう読もうと思ってノビノビになってます。
ポケダンが、ポケダンが、いけないんだあっ!

--

昨日の話を引っぱるけど、やっぱりWikiは馴染みソフトの
文脈で読まないといけないんじゃないの? つまり、与え
られるもんじゃなくって、自分たちの手で、自分たちの
望む形に変えていくっていう。それはテキストだけじゃ
なくって、Wikiのシステムも含めて。で、その「望む形」
っていうのは、それを使う人たちごとに違うもんだし、
それでいいわけでしょう。もちろん、大勢の人に喜ばれる
機能というのはあるかもしんないけど。でも、たとえば
アクセス制限にしても、そんなものに一体何の意味がある
のか自分には全然わからない。まぁ、仮に必要だとしても、
そういうのは、それこそ.htaccessで十分じゃないかって
いうのが馴染みソフトウェアなわけでしょう。だから、
Wikiというシステム、プログラムを、なんか神聖視する
ようなのはおかしいし、自分たちでどんどん良くしてく
ことがWikiの本来の姿なんじゃないの?

本家Permlink


2007年10月02日

お! 『ブラバン!甲子園』、売れてるのか。
レビュー見ると辛口のが多いけど、そりゃムチャって
もんじゃねぇか (w

本家Permlink


2007年10月01日

WYSWYGだと思ってた。Iもあるほうが一般的なのね。

でも、意外とカオスな状態は悪いという意見が多いのかな?

自分からしたら、Wikiの魅力はそのカオスなところに
あるんだけど。あんまり縛りかけちゃうと魅力なくなるよ。

結局、emergentなのね。これを生み出すためにWikiは
あるようなもので。そこに組織の論理とか持ち込んでも
しょうがないでしょ。

ただの文書管理とかしたいんなら、それ用のアプリが
いくらでも出回ってるでしょ。ノーツとか? そんなの
クソクラエだよ。

トップダウンがどうこういうけど、そんなことは
ちっとも重要じゃない。ボトムアップのほうがよっぽど
重要。だって、Wikiは書き手がいないとどうしようも
ないんだから。

勝手Wikiが乱立すると困るっていうのも事実だけど、
そんなのは簡単に乗り越えられる。結局はテキスト・
データでしかないんだから。それがWikiのいいところ
だろ。

--

コイウタは、オーナーの前川清の「恋歌」にちなんだもの
なんだぜ? これまめな

http://ja.wikipedia.org/wiki/%E3%82%B3%E3%82%A4%E3%82%A6%E3%82%BF

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails