{希哲16年1月13日}{希哲館訳語}{まとめ始める}{多用する}{使わない}{版存管理司組}{ウェブ CMS}{交度英語}{特異性}{虎哲開発}(15)

{虎哲開発破戒録 K#F85E/E74C-642F}

希哲16年1月13日虎哲開発特異性を「虎哲開発破戒録」としてまとめ始める

(考えてみれば,全て単独開発だから出来ることだ)

{開発}{『希哲日記』}{万が一}{日記}{デライト}{希哲館}{希哲館事業}{希哲館訳語}{開発者コミュニティ}{リスク低減}(89)

{希哲15年1月30日の日記 K#F85E/E74C-E10D}

日本の情技業界を騒がせている業務素交流出事件に思うところあり,希哲館でも原則として素交公開していく「素交公開原則」の採用本格的検討し始めた。

昨年の今頃もそんなことをぼんやりと考えていたが,特にこの頃,描出公開原則成功確信が持てるようになったり,政治参加方針公開が考えられるようになったり,「隠すべきものを持たない強み」を実感することが多くなっていた。となれば,素交公開自然流れだろう。

もともと虎哲関係の素交独自性が強過ぎ,動作環境備立方法も特殊文書込め言には独自用語と希哲館訳語満載という状態であり,盗んだところでまともに運用するのは不可能だ。これを「自然難読性」と呼び,ある種の強みと考えていた。

それでもいわば「素交非公開原則」で来た理由はいくつかある。

第一には,私自身の完璧主義的な性格であり,見せる必要もないところで不完全なものを晒したくなかった。

次に,希哲館事業収益化不可能に近い困難さがあった。万が一にもなさそうだった成功可能性を探る上で,万が一でもその障害になりそうな要素排除しなくてはならなかった。手札は一つでも多い方が良かった。

これについては,デライト収益化実現してしまえば無用心配になる。

もう一つ,技術的問題もある。昔から,デルン基礎にした版存管理司組構想してきたこともあり,素交公開するなら独自基盤でと考えていた。無論,そんなものを開発する時間は無かった。

色々な意味で余裕が必要になるので,いずれにせよデライト収益化後に決断することになるだろう。

素交公開原則利点はいくつも考えられる。献典としては死蔵してきた希哲館技術体系宣伝デライトも含めた希哲館事業全体の透明性信頼性向上機密保持に関する費用削減リスク低減,そして最も大きいのは開発者コミュニティを作れることだろう。

KitHub」というのは一昨年思いついたことだが,それこそ GitHub のように成長すればそれだけで希哲館事業の強力な武器になる。

この日は久しぶりに希哲館マスコット構想「きっとん」を思い出し,具体的なイメージを練ったりもした。これがのらくろに似ていることに気付いたのは収穫だった。

2月1日振り返り日記

{版存管理司組}{1970年代の想品}(2)
{版存管理司組}{バージョン}{素描}{情報技術}(4)

{バージョン管理システム K#F85E/FFC6}

「バージョン管理システム」はコンピュータ上でファイルの変更履歴を管理するシステム。高度なものではネットワークを通して共有する事もできる。一般に,プログラムのソースコード管理に用いられるが,原理上はファイルであれば何でも管理できるため,原稿等の管理や共同執筆に用いられる事もある。

英語では「revision control software」等と呼ぶ事が多い。

集中型リポジトリーと分散型リポジトリー

バージョン管理システムのリポジトリーは,一般に集中型と分散型に分けられる。

集中型

CVS,SVN など(SVNが主流)。

リポジトリーを一つだけもつ。

分散型

GitMercurialBazaar など(多数のシステムが競合状態にある)。

リポジトリーを複数もてる。最終的にはリポジトリー間で同期を取る。

見方によっては、集中型をより単純にしたものとも考えられる。「作業コピー」の概念が無く,リポジトリーと作業ディレクトリーは一対一の関係にある。リポジトリとの位置関係を規定する必要がなく,管理を開始するのは比較的簡単。

{版存管理司組}

{}