しかし2つが合わさると、「WiKiマスターにお伺いを立ててどのフォルダに入れるか決めてから書いてください」という謎の運用ルールができたり、間違った階層に配置すると「ちゃんとルールに従って整理しろ!」と滅茶苦茶怒られたりするようになって、誰も書かなくなる。
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
沈黙の一年を経て、でっかい"Wikiばな"がやってきましたよ。みなさん、お元気ですか。 今回の"Wikiばな"は、7/9(木)に発売される「パターン、Wiki、XP」をめぐり、著者・江渡浩一郎さんと、レビューアの方々に、さまざまな方角からwikiやその周辺についてお話してもらおうという趣向で開催します。 時を越えた創造の原則がわかります。"いきいきとした"知のコラボレーションシステムがわかります。「第七回Wikiばな」は、きっと、あなたの視野に新たな世界を開きます。 日時・場所・料金など 開催日 2009年08月08日(土) 場所 日本オラクル株式会社青山本社(東京都港区北青山2-5-8) 定員 約150名(発表者、スタッフ、参加者含む) 料金 無料 申込み開始日 2009年07月09日(木)から。 定員に達しました(07月23日)@こくちーず http://kokucheese.com/
■ Wikiでビジネス ざっと所感を書く。ここ数年、いくつかのビジネスユース向けのWikiエンジンが出てきているようだけれど、エンジンをパッケージして売りつけるだけじゃ、Wikiは売れない。 Wikiのウリどころは運用サポートだと思う。 ページを作って行くには、さらにページ間をまとめていくには、(今はもう死語かもしれないけれど)「まとめ力」が必要。 それを、サポーターがやってしまうんじゃなくて、サポーターが手放せる程度に、ユーザにスキルをつけてやること。つまりインストラクタ的な補助。 わたしはかつて3つのコミュニティで、Wikiの立ち上げを手伝ったが、運用サポート部分をボランティアにしたため、時間も精神力も労力も異常なほど引き裂かれ、かなりしんどかった。つまり、これは、ビジネスになるんじゃないかと思った。 Oracleなんかは、エンジン・ライセンス料自体も高いんだけれど、サポート(PDF)
江渡浩一郎さんによる「なぜそんなにもWikiは重要なのか」と題された論文から始まる、Wikiの本質を探る一連の考察があります。 その中で江渡さんは「WikiとXPとはパターンランゲージの実践という同じ概念から生まれた兄弟である」と主張しています。 これを読むと、アジャイル開発者にとってWikiは単なるWebページを簡単に作成できる情報共有システム以上の意味を持つことがわかります。アジャイル開発に興味を持つすべての方に読んでもらいたい論文です。 アジャイル開発者必読! 今から読むなら「Wikiの起源と進化」をお勧めします。さらに、雑誌『10+1 No.48』(注a)に掲載されている江渡さんへのインタビュー「Wiki的都市は構想可能か?」は論文の内容を踏まえたものとなっており、パターンランゲージの今後についてさらに踏み込んだ内容になっていて興味深いです。 アジャイル開発(というかXP)とWi
自分の経験の枠組みは自分で変えられるか?というのは言いかえれば、「ユーザが自分の環境の構築に主体的に参加する」ということになると思うけど、この考え方の源流の一つとして次の話がある。 江渡浩一郎「WikiとXPをつなぐ時を超えたプログラミングの道」 (スライド、言及記事) これは、今、流行ってるソフトウエア開発の方法論の源流にクリストファー・アレグザンダーという建築家の「パターンランゲージ」という概念がどのように影響を与えたかについて解説している講演だ。 何で建築家がソフトに関係してくるかと言うと、このアレグザンダーという人は、人が集まり都市が自然に生まれてくるようなプロセスでビルを建てることができないかということについて考えた人で、そのテーマがソフトウエアと本質的に関わってくるからだ。 つまり、設計者(開発者)がユーザの上に立って、上から目線で「おまえたちの欲しいものはこれだろう」と考えて
Wiki Wayレトロスペクティブズ 2007年9月26日 ITカルチャー コメント: トラックバック (0) (これまでの yomoyomoの「情報共有の未来」はこちら) 私事に属する話ですが、当方が初めて翻訳した書籍『Wiki Way コラボレーションツールWiki』(ソフトバンククリエイティブ)が刊行されて、この9月で5年が経ちました。訳者の感慨など他の人にはどうでもよいことは承知していますが、当方の人生で最も苦しかった時期に作業を行ったという意味で忘れられない仕事です。 あれから5年、Wiki を巡る状況は大きく変わりました。今ではニューズウィークのような一般誌で「ウィキ」の記事を見ても驚きませんし、ビジネス書に『ウィキノミクス』なる書名が冠されるなど、言葉の認知は IT 業界の外にも広がっています(さすがに「ウィキブランド」なるバズワードには面食らいましたが)。 もちろんそれに最
● [memo] ログ用Wikiクライアントのアイディア テキストボックスが更新されるたびに内容がサーバに送られる。送るの一時停止ボタンとかもほしい。 他の編集中のクライアントにも更新が送られるといいよね。 整形したページを見てる人はリロードするか、そこにも更新が送られるか。 (追記) 寝ながら考えた。 編集中に他の人からの更新が送られてくるのは明示的にマージを指示した時の方がいいな。cvs updateしてconflictを解消してcommitするまでは自動commitはなし、という感じ。cvsは使わないだろうけど。これに対して、普段は自動的に(編集があったら、あるいは一定間隔で)commitするモード。 それぞれの更新クライアントは、それぞれのために作られたブランチの頭に居て、Wikiエンジンにはそこから差分が送られる、あるいは、全文が送られてWikiエンジンで差分をつくる。 ここから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く