tag:blogger.com,1999:blog-86214748877701730892011-11-28T08:43:53.251+09:00ASIPの徒然なるままに備忘録(http://asip.tdiary.net/)もあります。asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.comBlogger671100tag:blogger.com,1999:blog-8621474887770173089.post-92105214576051633072011-09-24T02:16:00.008+09:002011-09-24T03:01:28.982+09:00あれから一年...以上、リリース等の話題は聞こえてこない。<br /><br />ベイパーウェアとなって久しい、というか、はじめから<br />ベイパーウェア。<br /><br />数年前に発表された仕様ももはや現在のニーズに<br />マッチしたものではない、ものの、仕様改訂の<br />ニュースもない。<br /><br />Perlはもはや過去の遺物なのか？<br />現状ではそうとしか思えない。<br /><br />【蛇足】<br />Perl6のサンプル・スクリプトをみてダサいとは<br />思っていたが...(特にハッシュがほぼ剥き出しの<br />クラス周り)、実装がでてこないのでは評価の<br />しようがない。<br /><br />クラス周りはJavaScriptのほうが余程洗練<br />されている。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-9210521457605163307?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-15583907948841113982010-06-13T08:35:00.001+09:002010-06-13T08:35:34.056+09:00Rakudo Star、6月も中旬になったけど、リリースの気配なし？<div>第２四半期リリースのはずだが？このまま、第３四半期に延期か？</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-1558390794884111398?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-87008399894581539302010-04-17T18:05:00.010+09:002010-04-17T18:54:10.163+09:00<div><a href="http://www.publickey1.jp/blog/09/perl5perl6perl2.html">http://www.publickey1.jp/blog/09/perl5perl6perl2.html</a></div><a href="http://www.publickey1.jp/blog/10/perl_5_perl.html">http://www.publickey1.jp/blog/10/perl_5_perl.html</a><div><br /></div><div><a href="http://www.publickey1.jp/blog/10/perl_5_perl.html"></a>PerlはPerl5系とPerl6系の実装の２つにメインストリームが</div><div>分岐することになっていた模様。</div><div><br /></div><div>その結果、Perl5系の実装は既存の実装とRakudoに</div><div>組み込まれている(?)Parrot利用型の実装が並立</div><div>することになる。</div><div><br /></div><div>この並立はリソースが分散するだけでなく、その同期</div><div>にコストが掛かるので、効率が良いとは思えない。</div><div><br /></div><div>傍からみていると、Rakudo組み込みのParrot利用型</div><div>のPerl5実装を別プロダクトとして分離し、そこに</div><div>リソースを集中させたほうがPerl使いは幸せになれる</div><div>ような気がする。</div><div><br /></div><div>シナリオ的には分離したRakudo組み込みのParrot利用型</div><div>のPerl5実装を現行のPerl5実装の後継と位置づけ、リソース</div><div>を集中、短期間での安定版のリリースを目指す。Rakudo</div><div>開発者と緊密に連携し、Rakudoに簡単に組み込めるように</div><div>しておくと、Rakudo開発者はリソースをPerl6実装に集中</div><div>でき、Perl6実装の開発の進展に繋がる。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8700839989458153930?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-90676759991081942392010-04-05T05:37:00.009+09:002010-04-17T18:40:36.996+09:00その２の後、Perl6の仕様と実装を切り離す方向で話が進んだらしい。<br /><br />Perlの産みの親であるラリー・ウォールは実装には直接タッチせず、<br />仕様策定に注力する模様。<br /><br />Rubyと違いPerlには実用に耐えうる実装が一つしかない、<br />仕様と実装を切り離すことに今更何の意味があるかは謎。<br /><br />とりあえず、今月、Perl6実装の本命?Rakudo初の安定版"Rakudo Star"<br />が公開予定。<br /><br />少なくともPerl5系のParrotコンパイラが完成していないと使い物には<br />ならないと思われる。<br /><br />Perl6実装の痛いトコロは過去の資産を維持するために、必ずPerl5実装を<br />内包しなくてはならない点。<br /><br />VBでCLRが採用された時点で、マイクロソフトがユーザーの過去の資産を<br />切り捨てたのとは対称的ではあるものの、賢い選択かは疑問。<br /><br />Rakudoの場合、Perl6系のParrotコンパイラと並行してPerl5系のParrot<br />コンパイラを作成しなくてはならず、Perl5系のParrotコンパイラが完成<br />していないと実用には至らない。<br /><br />"Rakudo Star"はPerl6仕様の基礎部分は実装しているだろうが、<br />Perl6仕様の完全実装ではなく、あくまでPerl6仕様の部分実装。<br /><br />Rakudo自体は何回かのリリースで徐々にPerl6仕様の完全な実装に<br />近づけていく予定らしい。<br /><br />"Rakudo Star"が出れば、アーリーアダプター以外も試用する、<br />Rakudo初の試練がやってくる。<br /><br />ParrotがPerl5実装と同等の処理速度を叩きだせているのか、<br />それがPerl使いにとって最大の問題ではないだろうか？<br /><br />Perl6の仕様、余所者からみると過去のレガシーな遺産を引きずりまくって<br />いるようにみえる。あの仕様のまま、実装されているのなら、個人的に<br />使う気にはなれない。数年も経てば、要求される仕様は変化している<br />と思われるが、Perl6の仕様が大きく変化したというニュースはない。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-9067675999108194239?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-22310754960920941392009-07-25T09:53:00.034+09:002010-04-09T10:15:57.588+09:00<div>>この不景気をきっかけに、発注側のユーザ企業に</div><div>>変わってもらいたい。</div><div>他力本願。根本的に間違ってる。</div><div><br /></div><div>ユーザ企業の前にSIerが変わるべきだろ...。</div><div>とにかく数で押す人月商売からの転換が先。</div><div><br /></div><div>人月商売の中では数が正義だから、真のプロ意識のない</div><div>「なんちゃってエンジニア」が生息できる。</div><div><br /></div><div>少数の精鋭が頑張って多数のなんちゃってエンジニアを</div><div>支えるスタイルから少数精鋭スタイルへの転換。</div><div><br /></div><div>数だけは揃えて後は現場にお任せがまかり通っていて、</div><div>現場に少数でも精鋭がいなければすぐに破綻する。</div><div><br /></div><div>だいたい、精鋭だけを揃えれば10人もいれば納期内に</div><div>完成できるシステムを玉石混交(ほとんどはなんちゃって</div><div>エンジニア)で数倍の人数がいても納期内に完成できない</div><div>ケースがざらにある現状が異常。</div><div><br /></div><div>これから数年のSI業界不況でなんちゃってエンジニアは</div><div>黙っていても淘汰されるだろうが...。</div><div><br /></div><div>次に実装屋よりも設計屋が偉いという間違った思考回路</div><div>の是正。</div><div><br /></div><div>実装屋と設計屋はベクトルが違うだけで本来その間に</div><div>優劣の違いはないにも関わらず、SIerの中ではクライアント</div><div>と会話して外部設計を行う設計屋が重視され実際の実装面を</div><div>担当する実装屋は軽視されてきた。</div><div><br /></div><div>本来は車の両輪である筈の設計屋と実装屋、SIerの中では</div><div>設計屋のみが即席培養され実装屋は育成されてこなかった。</div><div>その結果、SIerの中には実装のプロがほとんど、いない。</div><div><br /></div><div>外部仕様はそれなりに立派でも実装がヘタレで使い勝手の</div><div>悪いシステムが多数量産されてきたし、きているのが</div><div>現実。</div><div><br /></div><div>実装屋と設計屋を対等に位置づけ、それぞれの社内での</div><div>職位を設計しなおすくらいの大変革が必要。</div><div><br /></div><div>SIerの中で実装屋と設計屋を兼務するオールラウンダー</div><div>の育成はまず無理。</div><div><br /></div><div>オールラウンダーの育成を目指しても、中途半端な</div><div>似非オールラウンダーができあがるだけ。</div><div><br /></div><div>設計にも実装にも特化しない中途半端な似非</div><div>オールラウンダーが跋扈するから実装がヘタレで</div><div>使い勝手の悪いシステムが多数量産される結果</div><div>になる。</div><div><br /></div><div>それなら、SIerの中で実装技術には疎いが顧客との</div><div>対話が得意で顧客の代わりに要求仕様・外部仕様を</div><div>纏める設計屋部門と実装技術に特化し内部仕様以降を</div><div>担当する実装屋部門を明確に分離するか別会社化した</div><div>ほうがよい。</div><div><br /></div><div>そして、社内では設計屋部門と実装屋部門を独立採算</div><div>制にし、顧客に対しては設計屋部門と実装屋部門で</div><div>別契約にする。</div><div><br /></div><div>SIerの中では設計工程と実装工程の責任を明確に分離</div><div>し、責任の所在を不明瞭にしたまま設計工程の失敗を</div><div>実装工程で補填する悪しき慣習をなくすことに繋がる。</div><div><br /></div><div>独立採算制にすれば、設計工程で失敗があった場合、</div><div>設計屋部門から実装屋部門に金銭の移動が発生する</div><div>ことになるので、責任の所在を不明瞭にしたままとは</div><div>ならない。</div><div><br /></div><div>設計屋部門と実装屋部門に分割すれば、設計屋部門は</div><div>外部設計のプロとして外部設計に特化し、実装屋部門は</div><div>実装のプロとして内部設計・実装に特化すればよくなり、</div><div>それぞれの部門でその部門に適した人材を育成すれば</div><div>よくなる。</div><div><br /></div><div>現状、SIerでは実装のプロではない設計屋か似非オール</div><div>ラウンダーが実装の指導を行うので、実装のプロが育つ</div><div>はずがない。</div><div><br /></div><div>ここでの外部設計は実装を意識しない表層の設計、</div><div>内部設計は実装を意識した深層の設計を指します。</div><div><br /></div><div>更に無意味な中間管理職への過度のインセンティブ</div><div>の撤廃。</div><div><br /></div><div>実務にほとんど従事せず管理だけを行う人員が</div><div>SIerには多すぎる。</div><div><br /></div><div>PMにしてもPLにしてもマネージメントが上手いか</div><div>どうかの指標が一人歩きして、過度に評価されすぎ</div><div>ている。</div><div><br /></div><div>PMにしてもPLにしてもその管理手腕が卓越していて</div><div>全体が上手く回っているのは稀、ほとんどの場合、</div><div>PMやPLが実務を割り当てる際にできる人間に本来</div><div>こなすべき量より多くの作業を割当、その人間を酷使</div><div>して、全体が上手く回っているかのように帳尻あわせ</div><div>しているケースが多い。</div><div><br /></div><div>つまり、PMやPLの管理手腕が優れていてプロジェクトが</div><div>回るのではなく、できる人間(数人)がいてそこに作業負荷</div><div>を集中させることができるからプロジェクトが何とか</div><div>回っているケースが多い。</div><div><br /></div><div>会社としてはプロジェクトの実態はどうでもよくて</div><div>プロジェクトが表面上、上手く回っていれば問題なく、</div><div>実際の管理手腕は問われない。特定の個人(数人)に</div><div>作業を集中させてその犠牲？でプロジェクトを回して</div><div>いるPMやPLであっても、高く評価されるし、されてきた。</div><div><br /></div><div><br /></div><div>推敲中...。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-2231075496092094139?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-56094497440620630452009-07-09T11:17:00.010+09:002009-07-12T09:00:48.445+09:00<span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">ttp://d.hatena.ne.jp/higayasuo/20090707/1246940526</span></span><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">>すべての国民は何か一つ言語をマスターしなければ</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">>いけない。 </span></span><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">>※ただしモテ言語に限る </span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">日本国民の99%(?)はある特定のモテ言語をマスター</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">している。その言語の名は日本語、日本で一番の</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">モテ言語。</span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;font-size:medium;"><br /></span></span></div><div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">日本で２番めモテ言語は英語。</span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">他国もまた、母国語と呼ばれるその国一番のモテ言語を</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">ほぼ全ての国民がマスターしている。</span></span></div><div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;">プログラミング言語は言語としてはどマイナー、</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;">プログラミング言語にモテ言語と呼べるモノは</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: pre-wrap;"><span class="Apple-style-span" style="font-size:medium;">存在しない。</span></span></span></div></div></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5609449744062063045?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-76975656901139787462009-06-18T12:22:00.025+09:002009-06-23T13:55:55.113+09:00<span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;"><div>ttp://d.hatena.ne.jp/higayasuo/20090618/1245292543</div><div><br /></div>梅田望夫は日本のオープンソースの現状を見抜いている</span></span><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">と感じる。</span></span></div><div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">海外はよく知らないが、日本国内では、一部の熱狂的?な</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">OSS信奉者が作成物をOSSとしてリリースし、大半の</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">エンジニアはそのユーザとしてフリーライド(ただ乗り)</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">しているだけで、何ら還元を行おうとすることはなく、</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">OSSはフリーライド(ただ乗り)する(できる)ものだと</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">思っている。</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">></span><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">何か知的資産が生まれそうな萌芽がネット上に公開される</span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">>と、そうしたことに強い情熱を持った「志向性の共同体」</span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">>が自然発生して、そこに「集合知（ウィズダム・オブ・</span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">>クラウズ）」が働き、有志がオープンに協力してある</span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">>素晴らしい達成をなし遂げるといった公的な貢献──を育む</span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">>土壌がありません。</span></span></span></span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><span class="Apple-style-span" style="font-size:medium;">これも本質をついている。</span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">「志向性の共同体」という観点から見ると日本国内にも</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">発生し、数十人程度の規模にはなるもののそれ以上の</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">大きな規模になることはほとんどない。その程度の集合</span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;">体<span class="Apple-style-span" style="font-size:medium;">から得られる</span><span class="Apple-style-span" style="white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">集合知はたかが知れているので、現状を</span></span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;"><span class="Apple-style-span" style="white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">変革していくような素晴らしいアイデア(orイノベーション</span></span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;"><span class="Apple-style-span" style="white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">(変革))が生まれてこない。<span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">「志向性の共同体」が</span><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">素晴らしい</span></span></span></span></span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;"><span class="Apple-style-span" style="white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;"><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">アイデアを生み出す集合知の母体になる規模まで育っていく</span></span></span></span></span></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre; "><span class="Apple-style-span" style="font-size:medium;"><span class="Apple-style-span" style="white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;"><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><span class="Apple-style-span" style="font-size:medium;">ための土壌が日本にはないといっても過言ではないと思う。</span></span></span></span></span></span></span></span></div></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style=" white-space: normal; font-family:Georgia, serif;"><div><span class="Apple-style-span" style="font-size:medium;">集合知を生み出す母体となる集合に属さず、生み出された</span></div><div><span class="Apple-style-span" style="font-size:medium;">集合知の恩恵に預かっているだけの存在が梅田氏のいう</span></div><div><span class="Apple-style-span" style="font-size:medium;">ところの「志向性の共同体」に含まれることはない。</span></div></span></span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style="font-size:medium;"><br /></span></span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">日本のオープンソースは日本の土壌に立脚したものではなく</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">日本の土壌には本来根付かない徒花のような存在、海外から</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">飛んできた種子が芽をふいて必死になって根を下ろそうと</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">している状態に永らくあり、オープンソースへの日本国内</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">での貢献者は徐々に増えてきているものの、それらの貢献者</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">はOSS信奉者かつエンジニアであり非信奉者あるいは</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">非エンジニアではない、日本にオープンソースの精神が</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="font-size:medium;">根付いているかというと、そうはいえないと思う。</span></span></div><div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">OSS開発団体(者?)は志向性の共同体に含まれるが、</span></div><div><span class="Apple-style-span" style="font-size:medium;">OSSを使っているだけでOSS開発団体(者?)と何の</span></div><div><span class="Apple-style-span" style="font-size:medium;">接点(接触)も持たないor持っていてもバグ報告程度</span></div><div><span class="Apple-style-span" style="font-size:medium;">でOSSに何の変化ももたらさないユーザは「志向性</span></div><div><span class="Apple-style-span" style="font-size:medium;">の共同体」には含まれない。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">「梅田望夫にオープンソースを語るなとガツンと申し上げ</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">たい」の著者は日本国内のエンジニア周辺という狭い範囲</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">内で考えていて、梅田望夫氏は一般人をも含む広い範囲</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">での日本国内を俯瞰しているので、そもそも批判にさえ</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">なっていないように感じる。</span></span></div><div><span class="Apple-style-span" style="font-family:'Lucida Grande', serif;"><span class="Apple-style-span" style="white-space: pre;"><br /></span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">「梅田望夫に〜」の著者、イノベーション(革新)という</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">単語の誤用が多く、イノベーションとは何かを理解して</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">いないように見受けられる。イノベーション(革新)には</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">当たらないモノをイノベーション(革新)だと喧伝するから</span></span></div><div><span class="Apple-style-span" style=" white-space: pre; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">外国人からは胡散臭さがられ相手にされない。</span></span></div><div><br /></div><div><span class="Apple-style-span" style="font-size:medium;">推敲中...。</span></div><div><br /></div><div>#<a href="http://d.hatena.ne.jp/asipruby/20090619/1245369385">派生中。</a></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7697565690113978746?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-1758951368931311602009-05-14T22:28:00.027+09:002009-06-23T12:47:45.906+09:00<div>今更ながら書いておく。</div><div><br /></div>「軒先を借りて母屋を乗っ取る戦略」にでたのか...今更。<div><br /></div><div><div>狛犬もどきのスリム３って要するに</div><div>Struts＋狛犬もどきSpringアドオン(＋α)、</div><div>新規性や革新性は感じられない。</div></div><div><br /></div><div>GAE対応は現在をみているだけで(数年先の)</div><div>未来をみているモノではない。</div><div>GAE対応に関しては他のフレームワークも</div><div>対応に乗り出している(あるいは既に対応を</div><div>完了している)ので、直に陳腐化する。</div><div>数年先の未来でも色あせないモノを先取りして</div><div>はじめて革新的であるといえる。</div><div><br /></div><div><div>DIコンテナがHOTなトピックだった(騒がれた)時代は</div><div>既に(とうの昔に)終わっている気がするのは自分</div><div>だけだろうか？</div></div><div><br /></div><div>数年前(スリム３の影も形もない頃)に「プロダクトを</div><div>Springに対応させてSpringのユーザを地道に切り崩し</div><div>たら...」な文章を別の場所に書いたような気がする...。</div><div><br /></div><div>そのとき、狛犬もどきのチーフデベロッパは</div><div>「著名人一本釣り大作戦」を展開していた記憶が...。</div><div>(本人たちにはそんなつもりはなかったのかもしれない</div><div>が、傍からみるとそのようにみえた。)</div><div><br /></div><div>著名人を一本釣りすると、もれなくその著名人を</div><div>支持(崇拝？)するエンジニアが付いてくると...</div><div>そんな都合のいい(美味しい)話はない。</div><div><br /></div><div>JavaにおけるDIコンテナの世界的デファクト</div><div>スタンダードはSpring、2番手はGuice?、</div><div>3番手はEJB3コンテナ？。</div><div>日本国内だけがDIコンテナについてもガラパゴス状態</div><div>で、狛犬もどきがSpringといい勝負をしているらしい。</div><div><br /></div><div>海外では狛犬もどきの知名度がないに等しいのは</div><div>言わずもがな。</div><div><br /></div><div><div>海外で狛犬もどきの知名度がない理由は</div><div>簡単で英語のドキュメントを整備しなかったから。</div><div>その結果、欧米のエンジニアには見向きも</div><div>されなかった。</div></div><div><br /></div><div>英語のドキュメントを整備していないのは、</div><div>「英語圏の人間に日本語のドキュメントを読め」</div><div>と言っているようなもの。律儀に読む人間が</div><div>数人はいるかもしれないが、ほとんどの欧米人</div><div>には相手にもされない。</div><div><br /></div><div>スリム３を引っさげて海外に挑んだとしても</div><div>英語のドキュメントが整備されていなければ</div><div>勝負にならない。</div><div><br /></div><div>英語のドキュメントを整備しておけば</div><div>少しは欧米のエンジニアの気を引ける</div><div>かもしれない...。</div><div>英語のサポートMLも必須...。</div><div><br /></div><div>狛犬もどきの開発者はSpringとの差異を強調して</div><div>おきながら、「海外のSpringユーザはドキュメントが</div><div>なくても狛犬もどきに移行できる」と思っている</div><div>感じがある。</div><div><br /></div><div>ちなみに...狛犬もどきの英文ドキュメントの不足に</div><div>関しても数年前に書いた気がする...数年たっても</div><div>状況はほとんど改善されていない...。</div><div><br /></div><div>狛犬もどきのプロダクトはドキュメント</div><div>なしで直感的に扱えるようにはなっていない</div><div>(直感的に扱える(サンプルを見ただけで使い方</div><div>がわかる)程、単純ではない)。</div><div><br /></div><div>ソフトウェアの作者はえてして自分(たち)から</div><div>みて直感的だから(作者の欲目で)他人からみても</div><div>直感的であると思いがち。</div><div><br /></div><div>狛犬もどき開発団体自体がアカデミックな組織</div><div>ではないので、英文ドキュメントの整備という</div><div>効果が目に見えない一見無駄にみえる</div><div>作業はしない方針なのかもしれない。</div><div><br /></div><div>#スリム３よりスライム３か、DQ的には。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-175895136893131160?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-1605282152061926672009-05-10T06:48:00.017+09:002009-05-31T22:41:35.088+09:00<div><span class="Apple-style-span" style="font-size:medium;">TCKがタダでないこと を理由にJCPを非難するOSS信奉者は </span></div><div><span class="Apple-style-span" style="font-size:medium;">Sunが営利事業をしていることを失念しているとしか 思えな</span></div><div><span class="Apple-style-span" style="font-size:medium;">い。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">OSS開発団体がJAVAのTCKを引き取って(無償で)</span></div><div><span class="Apple-style-span" style="font-size:medium;"> エンタープライズで要求されるレベルの品質を 保ちながら</span></div><div><span class="Apple-style-span" style="font-size:medium;">メンテナンスできる状態にありJAVAのTCKのメンテナンス</span></div><div><span class="Apple-style-span" style="font-size:medium;">を引き受けようとしているのなら、JAVAのTCKをOSS開発</span></div><div><span class="Apple-style-span" style="font-size:medium;">団体に委ねないJCPを非難する理由になる。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">しかし、現状ではエンジニアを雇ってJAVAの TCKの品質を</span></div><div><span class="Apple-style-span" style="font-size:medium;">維持するのはSunの責任であり、 自分たちはその責任を</span></div><div><span class="Apple-style-span" style="font-size:medium;">肩代わりはしたくない、責任は肩代わりしたくないがTCKは</span></div><div><span class="Apple-style-span" style="font-size:medium;">無償(タダ)で使わせてくれて 当たり前だとJCPを非難する</span></div><div><span class="Apple-style-span" style="font-size:medium;">OSS信奉者が主張しているようにしかみえない。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">SunはJAVAのTCKや純正VMの品質を維持するために必要な</span></div><div><span class="Apple-style-span" style="font-size:medium;">コスト(の一部)をTCKのライセンス料でまかなっている。</span></div><div><span class="Apple-style-span" style="font-size:medium;">JAVAのTCKを無償にした場合、Sunは無償にすることで</span></div><div><span class="Apple-style-span" style="font-size:medium;">発生する損失をどのようにして補填すればいいのだろうか？</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;"> Sunは純正VMの開発やTCKのメンテナンスにおいて泥臭い</span></div><div><span class="Apple-style-span" style="font-size:medium;">部分のほぼ全てを一手に引き受けている。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div> </div><div><span class="Apple-style-span" style="font-size:medium;"> 泥臭い部分というのはバグ取り等の心の中で誰もやりたく</span></div><div><span class="Apple-style-span" style="font-size:medium;">ないと思っている作業を主に指します。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">JCPを非難するOSS信奉者はSunにオンブにダッコして</span></div><div><span class="Apple-style-span" style="font-size:medium;">もらっている状態で自分たちに都合の良い状態にしてくれ</span></div><div><span class="Apple-style-span" style="font-size:medium;">と主張しているようにしかみえません。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div> </div><div> </div><div><span class="Apple-style-span" style="font-size:medium;"> Apache HarmonyがSunの純正VMと同じレベルの品質を達成</span></div><div><span class="Apple-style-span" style="font-size:medium;">してその品質を維持し続けることができる(Sunの純正VMが</span></div><div><span class="Apple-style-span" style="font-size:medium;"> なくなってもApache Harmonyで代替できるので問題ない)</span></div><div><span class="Apple-style-span" style="font-size:medium;">とOSS信奉者は言い切れるのだろうか？</span></div><div> </div><div> </div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">Sunの純正VMはSunという企業が検証や品質のチェックを</span></div><div><span class="Apple-style-span" style="font-size:medium;">行ってから公開しています。特定の企業による品質補償？</span></div><div><span class="Apple-style-span" style="font-size:medium;">があることでユーザは独自の検証や品質のチェックを簡略化</span></div><div><span class="Apple-style-span" style="font-size:medium;">して行い利用することができています。また、特定の企業に</span></div><div><span class="Apple-style-span" style="font-size:medium;">よる品質補償？があることがJAVAを採用する上での安心感</span></div><div><span class="Apple-style-span" style="font-size:medium;">になっているというのもあると思います。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><div><span class="Apple-style-span" style="font-size:medium;">ちなみにOpenJDKの大部分はSunのエンジニアによって</span></div><div><span class="Apple-style-span" style="font-size:medium;">開発・メンテナンスされている状態です、OSSコミュニティ</span></div><div><span class="Apple-style-span" style="font-size:medium;">がOpenJDKの開発を主導しているわけではありません。</span></div></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">Apache HarmonyはApache Foundationが公開します、</span></div><div><span class="Apple-style-span" style="font-size:medium;">Apache FoundationはOSS開発に特化した非営利団体です。</span></div><div><span class="Apple-style-span" style="font-size:medium;">検証や品質のチェックは公開前にApache Foundation内で</span></div><div><span class="Apple-style-span" style="font-size:medium;">行われますが、品質の補償はありません。</span></div><div><span class="Apple-style-span" style="font-size:medium;">Apache Harmonyの場合、安心感を欲するなら、有償で</span></div><div><span class="Apple-style-span" style="font-size:medium;">品質補償を提供する企業から、品質補償という安心を買う</span></div><div><span class="Apple-style-span" style="font-size:medium;">事になります。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><div><span class="Apple-style-span" style="font-size:medium;">特定のOSS開発団体を特別扱いしてTCKを無償でライセンス</span></div><div><span class="Apple-style-span" style="font-size:medium;">することもできません。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">特定のOSS開発団体を特別扱いしてTCKを無償でライセンス</span></div><div><span class="Apple-style-span" style="font-size:medium;">すれば、TCKを有償でライセンスしている企業が独自のVM</span></div><div><span class="Apple-style-span" style="font-size:medium;">開発を破棄し特定のOSS開発団体の開発するプロダクトに</span></div><div><span class="Apple-style-span" style="font-size:medium;">合流しようとするのが目に見えているからです。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">特定のOSS開発団体を特別扱いしてTCKを無償でライセンス</span></div><div><span class="Apple-style-span" style="font-size:medium;">することは営利企業がそのOSS開発団体を介してTCKを無償</span></div><div><span class="Apple-style-span" style="font-size:medium;">利用することに直結します。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;">そうなれば、TCKのライセンス事業は破綻し、SunはJAVA</span></div><div><span class="Apple-style-span" style="font-size:medium;">に費やしているコスト(の一部)を補填する事ができなく</span></div><div><span class="Apple-style-span" style="font-size:medium;">なります。</span></div></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style="font-size:medium;"> SunがOracleに買収されたからといって、OracleがJAVAの</span></div><div><span class="Apple-style-span" style="font-size:medium;">TCKの品質を維持しながらメンテナンスすることになるの</span></div><div><span class="Apple-style-span" style="font-size:medium;">なら、JAVAのTCKが無償でライセンスされることはまず</span></div><div><span class="Apple-style-span" style="font-size:medium;">ありえません。</span></div><div><br /></div><div><span class="Apple-style-span" style="font-size:medium;"> OracleもSunと同じく慈善事業をしているわけではない</span></div><div><span class="Apple-style-span" style="font-size:medium;">のがその理由です。</span></div><div><span class="Apple-style-span" style="font-size:medium;"><br /></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">TCKを今後どのような体制で開発・メンテナンスしていく</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">のか、OpenJDKを 含めJavaVMのリファレンス実装を</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">今後どのような体制で開発・メンテナンス していくのかは、</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">JCP内外でコミュニティが議論していくべき課題だと</span></span></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><span class="Apple-style-span" style="font-size:medium;">思います。</span></span></div><div><br /></div><div>推敲中？</div><div><br /></div><div>#以前、同じような内容の文章を別の場所に書いたことがあるが</div><div>#また書いている。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-160528215206192667?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-64735531006459973052009-05-02T18:19:00.009+09:002009-05-03T22:24:04.168+09:00GAEマンセー、既存システムはクラウド化すべき、RDBMSを捨て<div>全てをMapReduce・BigTable(あるいはHadoop等の代替品)で行う</div><div>べきと主張しているように読める文章を読んだ、電波以外の</div><div>何物でもない。</div><div><br /><div>既存システムの担う処理のうち元来RDBMSで扱うには無理のあった、</div><div>大量のデータを並列で分析する処理にクラウドの要素技術を適用する</div><div>というのはありだと思うが、RDBMSに向いている処理はは今まで</div><div>どおりRDBMSを利用すべき。</div><div>クラウドの要素技術であるMapReduce・BigTableは大量のデータを</div><div>複数のマシンを用いて並列で分析する処理に特化して設計されている</div><div>ので、RDBMSが得意とする処理の多くには向いていない。</div><div><br /></div><div><div>MapReduce・BigTableの有効性を世界に発信したGoogleがこれらの</div><div>技術とRDBMSを併用していることを鑑みても明かなように、</div></div><div>MapReduce・BigTableの特性を無視してこれらの組み合わせが</div><div>RDBMSよりも優れていると考えるのは馬鹿げている。</div><div><br /></div><div>GAEでRDBMSが提供されていないのは、RDBMSがユーザの手許に</div><div>既にあるから、RDBMSが必要であればユーザは自前で準備することが</div><div>できる。Googleはユーザの手許にないクラウドの要素技術のみ提供する</div><div>ことでGoogle社内のハードのリソースを節約していると考えるのが</div><div>妥当ではないかと思う。</div><div>MapReduce・BigTableが優れているからRDBMSは必要ないと</div><div>Googleのエンジニアが判断してRDBMSを提供していないのではない。</div><div><br /></div><div>Googleのエンジニアが思いもつかない用途でMapReduce・BigTable</div><div>等クラウドの要素技術を活用するアプリがGAE上に構築されるのを、</div><div>Googleは期待していると思われる。</div><div><br /></div><div>推敲中。</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-6473553100645997305?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-48165077268478042862009-04-26T16:46:00.018+09:002009-05-31T22:47:45.672+09:00<div>処理速度等の差別化要素をないがしろにし気にもとめない</div><div>連中がSI屋を中心に多いから、仕様書さえあれば誰でも</div><div>全く同じシステムをくみ上げることができる という間違った</div><div>認識が日本国内に蔓延る。</div><div><br /></div><div>今やその認識は世間にまで広がっている？</div><div><br /></div><div>プログラマーの技量によって全く同じ仕様書から別物といっても</div><div>過言のないくらい、性能等の異なるシステムが組み上がってくる</div><div>ことにいい加減、 気づいてもいいんではないかと思う。</div><div><br /></div><div>仕様書を渡しても全く同じものはできない、ソースコードを渡せば</div><div>同じものを いくらでも複製できる。</div><div><br /></div><div>ソースコードと新幹線の部品を同じ尺度で考えるのは全くの間違い。</div><div><br /></div><div>ソースコードを渡した場合にそのコードが民間に流出しない </div><div>保証は何処にもない。</div><div><br /></div><div>中国政府を信頼すること自体馬鹿げている、保険となる機密保持契約</div><div>の締結を、最低限、中国政府に求めるべき。</div><div><br /></div><div><div>中国は偽造複製品王国、中国政府に何の保険もなしにソースコードを</div><div>渡せば山程偽造複製品が作られる結果しか後には残らない。</div></div><div><br /></div><div><div>機密保持契約を結んでおけば、例えその相手が政府であっても</div><div>契約を守っていなければ訴訟を起こし勝訴することができるので</div><div>もしものときの保険にできる。</div></div><div><br /></div><div>中国政府が開示を求めているのは基幹ソフトウェア、つまり</div><div>ドル箱、機密保持契約を結ばずに開示に応じる企業がある</div><div>はずがない。</div><div><br /></div><div>中国は世界の中心ではない。中国の要人や官僚に未だに</div><div>中華思想が蔓延っているから、馬鹿げた発想が出てくるのだろう。</div><div><br /></div><div>中国政府が機密保持契約を結ばずにソースコードの開示を求めようと</div><div>すれば、中国自体が大打撃を受ける結果になるだろう。</div><div><br /></div><div>ソースコードの開示を強要すれば、世界中の企業が中国に最先端より</div><div>数世代前の製品しか輸出しないようになるのが誰の目にも明らか、</div><div>数世代前の製品ならソースコードを開示してもダメージにはならない</div><div>のがその理由。</div><div><br /></div><div><span class="Apple-style-span" style=" white-space: pre-wrap; font-family:'Lucida Grande';"><a href="http://d.hatena.ne.jp/LM-7/20090425/1240674818"><span class="Apple-style-span" style="font-size:medium;">中国によるソースコード強制開示報道に踊らされるのはまだ早い</span></a></span></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4816507726847804286?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-77886045555509365562009-04-06T18:48:00.023+09:002009-06-23T12:44:52.363+09:00３月中旬にParrot1.0がリリースされた。<div><br /></div><div>但し、1.0は中間コードコンパイラ作成者に</div><div>向けたベータ版的なリリースで安定板は</div><div>2010年７月リリース予定の2.0までお預け。</div><div><br /></div><div>LLVMとParrotは似て非なるもの、Parrotが</div><div>動的言語をターゲットにバイトコードを設計</div><div>しているのに対し、LLVMはC・C++等の</div><div>静的言語を主なターゲットにしておりLLVM</div><div>用の中間コードはParrotのものよりもずっと</div><div>機械語(アセンブリ)に近く、静的言語を様々な</div><div>タイミングにて最適化できるように作られている。</div><div><br /></div><div>Parrotをバイトコードインタープリタとして捉えた</div><div>場合、最適化の方向性に疑問が残る。</div><div><br /></div><div>OO言語と手続き型言語を同じバイトコード</div><div>インタープリタで扱うのは効率が良いとは</div><div>思えない。</div><div><br /></div><div>CLR、RubyVM、Java、JavaScript用VMの何れに</div><div>ついてもOO言語に最適化する方向でバイトコードを</div><div>設計している。</div><div><br /></div><div>OO言語と手続き型言語を同じバイトコードで</div><div>扱おうとした場合、手続き型言語かOO言語の</div><div>どちらかにあわせてバイトコードを設計する</div><div>ことになる。</div><div>手続き型言語に合わせた場合、OO言語を内部的</div><div>に手続き型言語に変換してからバイトコードに</div><div>落とし込む事になる、一旦バイトコードに変換</div><div>してからは高速に動作するもののバイト</div><div>コードに落とし込む際のオーバーヘッドが</div><div>馬鹿にならない。</div><div>OO言語に合わせた場合は手続き型言語を内部的に</div><div>OO言語のように扱いバイトコードに落とし込む</div><div>ことになる、OO言語は手続き型言語の特徴を内包</div><div>するのでバイトコードへの変換時のオーバーヘッド</div><div>はそれほどないものの、手続き型言語に合わせて</div><div>バイトコードを設計した場合に比べると実行時の</div><div>オーバーヘッドがそれなりにある。</div><div><br /></div><div>OO言語と手続き型言語を両方とも上手く</div><div>扱うためにはバイトコードの設計が重要であり、</div><div>どちらかに特化した場合よりも複雑になると</div><div>思われる。</div><div><br /></div><div>OO言語と手続き型言語の両方に上手く最適化された</div><div>動的言語用VMは今のところ、存在しない。Parrotが</div><div>初のそんなVMになるとは考えにくい。</div><div><br /></div><div>RubyVM、Java、JavaScript用VMの何れにしても</div><div>特定の言語に特化させる形でバイトコードを設計</div><div>し、処理速度面で成果を上げている。</div><div><br /></div><div>CLRは汎用性を追求する形でバイトコードを設計</div><div>しているため、それぞれの言語についてはその</div><div>言語へ特化した場合よりも処理速度面で劣ると</div><div>思われる。</div><div><br /></div><div>汎用性を持たせてバイトコードを設計するよりも</div><div>個々の言語に合わせてバイトコードを設計する方</div><div>が動的言語では性能的に有利ではないかと思う。</div><div><br /></div><div>現にParrot上に実装されたメジャーな言語の実行</div><div>環境はどれも現状では各々の言語に特化して実装</div><div>された実行環境と同等の性能を達成していない。</div><div><br /></div><div>PythonのParrot正式採用の可能性が報じられていた</div><div>時期もあったが、今やその可能性は著しく低いという</div><div>か、ないに等しい。 <a href="http://code.google.com/p/unladen-swallow/">unladen-swallow</a> というPython</div><div>実装の高速化プロジェクトでは既にCPythonをベース</div><div>にLLVM利用型VMの開発を開始している。</div><div><br /></div><div>Ruby界隈ではAppleによるRuby1.9互換(?)実装MacRuby</div><div>の開発チームが次期リリース(0.5)に向けてCRubyを</div><div>ベースにLLVM利用型VMの開発を開始している。</div><div>日本国内では有志によりYARV中間コードをLLVM中間コード</div><div>に変換するJIT(?)コンパイラyarv2llvmの開発も行われている。</div><div><br /></div><div><div>LLVMは静的言語をターゲットにしてきているが、</div><div>動的言語をどのようにサポートするかもプロジェクト内で</div><div>議論されている模様。</div><div><br /></div></div><div>Parrotは開発に時間が掛かりすぎている感がある。</div><div><br /></div><div>Parrot開発開始当初には影も形もないに等しかった</div><div>LLVMに先を越された感がいなめない。</div><div><br /></div><div>Parrotがその安定版の開発に1年以上の時間を掛ける間に</div><div>LLVM利用型の動的言語実行環境の実現に道筋が出来上がる</div><div>だろう。</div><div><br /></div><div>つづく...推敲中</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7788604555550936556?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-44937170629284699902009-04-03T09:30:00.003+09:002009-04-03T09:36:33.938+09:00　<a href="http://d.hatena.ne.jp/asipruby/20090402/1238650524">ASIPのRubyistなるままに</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4493717062928469990?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-52527413567482187242009-03-24T14:48:00.001+09:002009-03-24T14:50:05.150+09:00神様、仏様、イチロー様。イチロー、すげぇ、凄すぎる。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5252741356748218724?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-18441928104930145602009-03-22T07:42:00.007+09:002009-06-23T12:50:10.142+09:00性善説に基づいて設計されていたこと。埋め込まれたデータに<div>虚偽の情報が含まれていれば破綻する、学者の考えそうな設計</div><div>だった。その破綻を回避する仕様があれば、失敗はしなかった</div><div>かも？<div><br /></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-1844192810493014560?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-76102377331828750102009-03-14T16:55:00.015+09:002009-06-23T12:51:19.621+09:00<div>Ruby/Pythonは構文の違いを除けば大した違いはなく、Perl5.xはOOでない</div><div>ことと構文の違いを除けばRuby/Pythonと大した違いはない。</div><div>PHPはRuby/Perlと類似の構文を採用しているものの、OOやスレッド等に</div><div>関して(言語仕様上の)扱いが大きく異なる、似て非なる言語。</div><div><br /></div><div>海外でPHPからRoRへの移行プロジェクトが上手くいかない事例があった</div><div>のも頷ける。"Ruby/Python/Perl"と"PHP"の構文の類似性から軽く考えて</div><div>移行しようとすれば必ずといっていいほど失敗する。</div><div><br /></div><div>設計・構築フェイズでPHPと"Ruby/Python/Perl"の言語仕様における違い</div><div>をきちんと把握し、ボトムアップ指向で移行していけば失敗には</div><div>繋がらなかったはず。</div><div><br /></div><div>自分たちの"見識のなさ、見積もりの甘さ”による移行の失敗をRoRのせい</div><div>にし、「PHPのほうがRoRより優れている」と主張するようなエンジニア</div><div>は論外。</div><div><br /></div><div><a href="http://slashdot.jp/developers/article.pl?sid=07/09/23/2357202">Ruby on Railsは万能ではない</a> を読んで思った事を遅ればせながら</div><div>書いてみた。</div><div>上記記事の元ネタの著者が真に優秀なRails(Ruby)エンジニアを</div><div>雇えていたとは思えない。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7610237733182875010?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-44892601666338080572009-03-06T20:38:00.023+09:002009-06-23T13:07:27.126+09:00PHPはASPの模倣品として始まった(?)。<div>ASPがIISのモジュールとして実装されたのと同様に、Apacheの</div><div>モジュールとして登場。</div><div><br /></div><div>PHPはリクエストに対して(X)HTMLやXMLを描画して返す事に特化した、</div><div>つまりMVCのうちV(ビュー)に特化した言語でありながら、現状は</div><div>その延命措置としてMVCのしくみを無理矢理PHPの世界に持ち込み、</div><div>大型システムに適用しているようにみえる。</div><div><br /></div><div>PHPはその言語の特性上、スレッドという概念がない(スレッドが</div><div>実行環境によって隠蔽されている、リクエスト・レスポンスの一連</div><div>の流れが一つのスレッド上で実行されているものの、スレッドを</div><div>ユーザーが認識することはない)ため、スレッドを跨がって存在する</div><div>オブジェクトを言語構文上、定義することはできない、そのため、</div><div>外部モジュールと組み合わせるor実行環境を拡張することにより</div><div>オブジェクトのキャッシュ等をすることになる、自ずとPHP単体で</div><div>できることの自由度に限度がでてくる。</div><div><br /></div><div>並列処理に関してもそう、curl_multi関数群を導入して、並列処理を</div><div>PHPの言語仕様の外側にある実行環境で対応しようとしている。</div><div><br /></div><div>スレッドを跨がったオブジェクトのキャッシュや並列処理等をPHPは</div><div>全て実行環境に依存しているため、ユーザサイドが実行環境をいじらずに</div><div>自由に拡張・改良することはできない。</div><div><br /></div><div>PHPユーザの多くに共通するのは、「PHPではこのようにしたら楽に</div><div>できる」ということは簡単に言えるけれど、PHPの実行環境が内部で</div><div>行っている処理については全くと言っていい程知らないため、「PHP</div><div>ではこうしている処理を他の言語でもこのようにすればできるよ」</div><div>ということができない点。</div><div>PHPユーザの大半は、PHPの実行環境の挙動を全く理解していないので、</div><div>PHPという閉じた環境の中では生息できるが、他の環境で生息できる</div><div>だけの適応力を養ってはいない。</div><div><br /></div><div>有り体に言えば、PHPユーザの大半は「結果があっていればそれでOK、</div><div>結果に至る過程は我関せず」なタイプ。</div><div><br /></div><div>PHPはプログラミング言語でありながら、実行環境により隠蔽された</div><div>部分が非常に多く、その点でVB6以前のVBとよく似ている。</div><div><div><br /></div></div><div>推敲中...</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4489260166633808057?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-60255398926992904332009-03-05T19:07:00.027+09:002009-06-23T12:57:34.703+09:00<div>Ruby・Python・JavaScriptはLinux、様々なアイデアの実験場となり、</div><div>ユーザ数増加中。</div><div><br /></div><div>PerlはFreeBSD、枯れていてコアなユーザもいるが、ユーザの更なる</div><div>増加は望めない。安定を優先するため、実験場にはなりえない。</div><div><br /></div><div><div>PHPはWindows、その簡便性でユーザを一気に延ばしたけれど、言語と</div><div>しての進化は手詰まり、お手軽言語であることを売りにしたため、(先進的</div><div>で)マニアックな言語仕様を導入しにくいorできない。</div><div><br /></div><div><div>Perlの場合、互換性を維持するための言語仕様上の負の遺産の継承がその</div><div>進化を阻害している(枯れて安定していることを優先して今まで大規模な</div><div>言語仕様の改訂を行ってこなかったことが言語としての進化を停めて</div><div>しまった)、今や大規模な改訂は大きすぎるイタミに直結する、そのため、</div><div>言語仕様上の負の遺産を滅するような改訂をもはや行えない、その時期</div><div>を逸してしまった。</div><div><br /></div><div>現にPerl5.8とPerl6の関係はCとC++の関係よりもVB6とVB.netの関係</div><div>に良く似ている、Perl6のOOはPerl5.8の仕様のオブジェクト指向的</div><div>側面を見直し、多少、体裁を整えたようにしか見えない。</div><div>それでもVB6からVB6.netへの移行時にそのユーザが経験したイタミと</div><div>同種のイタミをPerlユーザは経験することになるだろう...。</div><div><br /></div><div>Rubyのように言語仕様を段階的に改訂する場合、ユーザに多少の混乱は</div><div>与えるものの、大きすぎるイタミを伴う大規模な言語仕様の改訂をユーザ</div><div>は経験しなくて済む、それを最善とはいえないが...。</div><div><br /></div><div>PHPの場合、言語仕様が成熟する前に、ユーザ数が急激に増加したことが</div><div>不運、お手軽言語として確立した地位を維持していく以外に道はない。</div><div>(先進的で)マニアックな仕様のメリットをPHPユーザに納得させるのは</div><div>難しい。そのような仕様を導入しても利用されずに終わる可能性大。</div><div><br /></div><div><br /></div></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-6025539892699290433?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-40073295088911552352009-02-15T14:58:00.026+09:002009-06-23T12:39:45.905+09:00昨年末のアルファ版リリースはならなかったようだ。<div><br /></div><div>Perl6用でも使用されるParrot VMは先月23日に0.9がリリースされ</div><div>現在は３月の1.0リリースに向け、開発中。(<a href="http://codezine.jp/article/detail/3502">こちら</a>)。</div><div><br /></div><div>少なくともPerl6はPerl6自体の中間コードコンパイラとPerl5互換の中間</div><div>コードコンパイラの両方が実用レベルで動作する必要があるため、この</div><div>２つが実用レベルで実装されるまでリリースされない。いつリリース</div><div>されるかは已然不明。</div><div><br /></div><div>中間コードコンパイラは任意の言語をParrotバイトコードに変換する</div><div>コンパイラをここでは指します。</div><div><br /></div><div>Perl6は複数の言語を利用できる夢の言語のようにPerl6使いの間では</div><div>思われていた節もあるようだが、この夢物語を現実にするには、それ</div><div>ぞれの言語に対して中間コードコンパイラが必要であり、実用レベル</div><div>の中間コードコンパイラのある言語は何処にも存在しない現状では</div><div>当分の間は夢物語になりそうである。最低限必要なPerl用のコンパイラ</div><div>でさえ実用にほど遠い現状では。</div><div><br /></div><div>Parrotは実装が開始されてから、かなりの年数がたっており、先進的な</div><div>VMとはよべなくなっている。</div><div><br /></div><div>Parrotは今や数あるVMの一つにすぎず、他のVMを圧倒する性能と</div><div>いうわけでもない、Parrotに格別の思い入れのあるエンジニアでも</div><div>なければ、Parrot用コンパイラを書く事はないと思われる。</div><div><br /></div><div>それを証明するかのようにPerl以外のParrot用コンパイラの実装は</div><div>遅々として進んでいない(実験的なモノを除く)。</div><div><br /></div><div>Parrot.orgのlanguagesのリストに記載されている中間コードコンパイラ</div><div>のほとんどは実装途中で開発が停滞・停止あるいは放棄されている。</div><div><br /></div><div><div>Parrot用にPerl以外の言語の言語仕様を満たすコンパイラを書く</div><div>ことに意義を見いだすエンジニアがこのさき、多数出てくるか</div><div>甚だ疑問。</div><div><br /></div><div>以前、Perl６はParrotVMへの移行よりも現行VMベースでの実装を</div><div>先行したほうがいいのでは、と書いたが、現行のPerl5系をParrotVM</div><div>上に実装、Perl5.12(?)として公開してからPerl6を進めるのが現実解で</div><div>あると今は思う。</div><div><br /></div><div><div>Perl5系のParrotVM実装(5.12)、PerlのOO言語化(6.0)、現行のPerl6</div><div>仕様のOO言語化以外の機能の実装(7.0?)くらいが妥当ではないだろう</div><div>か？</div><div><br /></div></div><div>Rubyの場合、アグレッシブな変更を伴う予定で仕様の確定しない</div><div>Ruby2.0を先送りし、代わりに1.8仕様の改良版をYARV上に実装する</div><div>現実解を開発陣が選択した。それが功を奏し、安定板である1.9.1が</div><div>既にリリースされている、１年以内に実運用に耐える段階に達する</div><div>だろう。Ruby2.0で予定されていた機能が1.9系に取り込まれながら、</div><div>段階的に2.0(理想形？)に近づいていくと思われる。</div><div><br /></div><div>Perl開発陣もPerl6のリリース時期が確定できないのなら、現実的な</div><div>ロードマップを模索してはどうだろうか？</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4007329508891155235?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-3620334420578786742008-09-05T22:29:00.011+09:002010-04-09T09:57:02.529+09:00<div><div><a href="http://d.hatena.ne.jp/asip/20080905#1270774559">http://d.hatena.ne.jp/asip/20080905#1270774559</a></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-362033442057878674?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-75593295472685877642008-08-18T19:50:00.021+09:002010-04-09T10:01:11.115+09:00<a href="http://d.hatena.ne.jp/asip/20080818#1270774839">http://d.hatena.ne.jp/asip/20080818#1270774839</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7559329547268587764?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-34829671625259099952008-08-18T17:07:00.006+09:002008-08-18T17:15:12.891+09:00<div>１点を争う接戦になるかと思っていたので、あの展開は予想外だった。</div><div><br /></div>在学時、初出場初優勝のとき、３年以外の在校生全員で甲子園で<div>応援したのも今はいい思い出、応援合戦のときは絵文字のパネル</div><div>の一枚を持ってました。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-3482967162525909995?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-70815752126224189792008-08-14T18:22:00.005+09:002008-08-16T13:26:35.030+09:00<div>高負荷サイトを実際に運営されている会社の方がこの本を</div><div>執筆されていることは勿論、この本をレビューして自分の</div><div>ブログの書評で高評価をされていた方もいたので購入しました。</div><div><br /></div><div>発売前にAmazonで注文し、発売数日後に届きました。</div><div><br /></div><div>自分(たち)のノウハウを公開しないポリシーの人間(会社)が</div><div>多い中、高負荷サイトのインフラ構築の技術的なノウハウ</div><div>が技術者の視点で詳しく書かれているこの技術書は</div><div>かなり貴重です。</div><div><div><br /></div><div>読み始めたばかりですが、良い本です、勉強になります。<div><div><br /></div><div>WEBサービスサイト等WEB系システムのインフラ構築に</div><div>携わろうとしている技術者だけでなく、インフラ上で動く</div><div>システムの開発に携っている(あるいは携わろうとしている)</div><div>技術者も読むとかなり勉強になる本だと思います。</div><div><br /></div></div></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7081575212622418979?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-86433930914404262572008-08-14T16:07:00.011+09:002008-08-15T14:50:49.163+09:00あのABCテレビのアナウンサー、東邦が８・９回にチャンスを作ると<div>異様に東邦を持ち上げ、しまいには部員数まで持ち出して、個人的に</div><div>東邦の逆転を願っているのか東邦の逆転が既定路線のような発言まで</div><div>する始末、アナウンサーは中立が本分違うんかい、とむかついた。</div><div>おまけに、試合後に「桐蔭が相手のミスに"つけこんで"得点を重ねた」</div><div>(「桐蔭が相手のミスを上手くついて得点を重ねた」と発言すべきところ)</div><div>「一本(ホームラン)が出れば桐蔭を立ちすくませることができた」</div><div>等の発言をする始末、あのアナウンサー、アナウンサー失格。</div><div><br /><div>何故、むかつくかというと大阪桐蔭は母校だから。自分の在学中あたりは</div><div>並の進学校だったけど、卒業してから数年後に中高一貫にしてから</div><div>進学校としてかなり躍進したと風の噂で聞いた。</div><div>ちなみに野球部等体育会系は別コースとなっていて、文武両道というわけ</div><div>ではありませんでした、在学時。今も別コースのまま変わっていないと</div><div>思います。</div><div><br /></div><div>今回に留まらず、本来中立であるべきアナウンサーが自分の個人的な見解</div><div>や自分の考えで発言するようになっている、放送局の堕落だろうか？</div><div><br /></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8643393091440426257?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-12628789949526657432008-08-14T15:09:00.002+09:002008-08-14T15:16:06.481+09:00WindowsPCのキーボードにあわせてFedora・Ubuntu等の<div>Linuxディストリビューションのキー配列が設定されているので</div><div>これらをVMWare Fusion上で動かしているとMacのキーボード</div><div>とのキー配列の違いで困ることがある。</div><div>このためだけにWindowsPC配列のキーボードを買うのもなんだし</div><div>どうしようか...とりあえずもう少し調べてみることにする。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-1262878994952665743?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-71810894990080633142008-07-25T18:05:00.011+09:002009-06-23T13:41:21.909+09:00<a href="http://d.hatena.ne.jp/higayasuo/20080724/1216877864">ここ</a>。会社から評価されるためにオープンソースをやろうと<div>書いているようにみえる、会社からの評価を目的にするのでは</div><div>志が低いし...長続きしない。朝から終電まで(場合に</div><div>よっては土日も)プログラムを書いている人間に、リフレッシュ</div><div>するための僅かな余暇を削ることになる、効果があるかわからない</div><div>行為を推奨するのはどうかと思う。</div><div>(三度の飯よりプログラミングが好きという人間はトライしてみても</div><div>いいとは思うが...)</div><div><br /></div><div>オープンソースのプロジェクトを開始するにしても２番煎じ</div><div>(猿真似)では評価されない、新規性がないと駄目等、開始するに</div><div>あたって注意すべき事柄は多い。</div><div><br /></div><div>会社から評価されるためにオープンソースをやろうと書くのなら、</div><div>作るプロダクトに関してのアドバイス等、自身の経験を踏まえて</div><div>の実践的な内容にしないと、リンクした文章のように中身のない</div><div>空っぽな文章になる。</div><div><br /></div><div>SIで優秀なPGが評価されないのはSI業界の構造的な問題(顧客から</div><div>の受注時に採用されている人月による見積もり等)が関係している、</div><div>それは一朝一夕に解決する問題ではない。</div><div><br /></div><div>「オープンソースプロダクトの開発が(SIで優秀なPGが評価されない)</div><div>現状を打破する銀の弾丸になる」というような主張には何の根拠もない。</div><div>「オープンソースプロダクトの開発が上司に認められて</div><div>会社からの評価が上がったSIerの社員がいた」というだけでは</div><div>根拠にはならないのである。</div><div><br /></div><div>会社からの評価UPを望むのなら、「オープンソースプロダクトの開発で</div><div>会社から評価を勝ち取る」などという不確実で非効率な手段よりも、</div><div>確実で効率の良い手段を探したほうが良い。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7181089499008063314?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-50342313449626955382008-07-21T11:14:00.011+09:002008-08-16T14:25:15.065+09:00利益を生み出すモノではなく、コストを削減するモノでしかない。<div>基本的に事務作業等の恒常性のコストを削減するのみ。</div><div><br /></div><div>つまり、顧客にとってSIerの行うシステム構築の価値とは基本的に</div><div>コスト削減に尽きる。</div><div><br /></div><div>コスト削減にすぎない以上、顧客はその年度の社内システム整備に</div><div>割り当てた予算の範囲内で社内システム構築に投資する。</div><div><br /></div><div>自分たちの行うシステム構築が顧客にとってどんな価値があるのか</div><div>理解している若いSE・PGは少ない。</div><div><br /></div><div>[追記]</div><div>SIerの行うシステム構築とは社会システム等公共システム及び医療</div><div>システム等の一部を除くと結局、事務作業等の恒常性の作業に関して</div><div>人間が行う作業のうち機械化できる部分を機械化して人間の手間を</div><div>減らすことで作業を効率化し、人的コストを削減するだけ。</div><div><br /></div><div>効率化によって生じる時間的余裕を別の作業に振り向けることで</div><div>顧客に利益が発生したとしても、それはSIerの行うシステム構築</div><div>の産物ではない。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5034231344962695538?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-86116566292385820092008-07-21T10:41:00.006+09:002008-08-14T14:55:23.492+09:00営業がプロフィットセンタ、SE・PGはコストセンタ。<div>営業は収入(≒利益)を生み出し、SE・PGはコストを生み出す</div><div>と考えて経営されている組織。</div><div><br /></div><div>SIerの経営とは結局、営業がとってきた案件を如何に安いコスト</div><div>で仕上げ、利益(≒収入-コスト)を最大化するかという点に</div><div>尽きる。</div><div><br /></div><div>最初に案件の生み出す収入が確定する以上、SE・PG</div><div>の携わるシステム構築フェーズで発生するコストを最小化</div><div>するしかその案件での利益を最大化する方法はない。</div><div><br /></div><div>再度繰り返すが、SE・PGは本質的には(専門技術を有すると</div><div>いう点を除けば)、SIerにおいて総務部門等と同じコストセンタ</div><div>に属する存在である。</div><div><br /></div><div>この点を誤解しているSE・PGは多い。</div><div><br /></div><div>SIerにおけるSE・PGはクリエイティブな仕事でそれに見合った</div><div>対価が支払われるべきだ等の幻想は今すぐ捨てたほうがいい。</div><div>(SIerにおいてSE・PGが経営陣にコストセンタだと思われている</div><div>以上、見合った対価が支払われることはありえない。)</div><div><br /></div><div>SIerの経営陣がSE・PGをコストセンタからプロフィットセンタに</div><div>位置づけし直すことはありえない。</div><div><br /></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8611656629238582009?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-21064169763650726422008-07-20T18:13:00.018+09:002009-06-23T12:35:49.208+09:00Perl6の登場がアナウンスされてから５年以上になるが、未だ実用に<div>足る実装が出ていない。</div><div><br /></div><div><div>数年前、Ruby2.0(Rite)とPerl6、どちらが早くリリースされる？かは</div><div>未知数だった。</div><div><br /></div><div>ところが、蓋を開けてみると、現状はこうだ。</div><div><br /></div><div>Rubyは2.0(Rite)のリリース前に先鋭的な機能を見送りVM化に</div><div>重点を置いた1.9.0(開発版)が昨年末にリリースされ、今現在も</div><div>1.9.1(安定板)のリリースに向けたブラッシュアップが今年の</div><div>クリスマスに向けて行われている。</div><div><br /></div><div>対して、Perl6はHaskellで実装されたPugs等の実装が登場した</div><div>ものの、その全機能を俯瞰できる実装は未だ出ていない。</div><div><br /></div><div>リリース競争におけるRubyの勝因は先鋭的な機能を見送り</div><div>(機能を絞り)VM化に注力したこと、笹田氏がYARVを開発し、</div><div>VM化のキーパーソンとなったこと等が挙げられる。</div><div><br /></div><div><br /></div><div>RubyのVMであるYARVとPerl6のVMであるParrotのスタンスの違いも</div><div>開発速度に大きな差を生じさせている。</div><div>YARVがRuby専用のVMとしてポジショニングされているのに対し、</div><div>Parrotは最初から多言語用の汎用VMとしてポジショニングされている</div><div>点である。</div><div>長期的には汎用VMを指向するにしても、短期的には特定の言語に特化</div><div>したほうが実装コストを削減でき、早期リリースに繋がると思う。</div><div><br /></div><div>汎用VMとして成功しているのは.NetのCLRくらい、これは大企業が</div><div>フルタイム開発者を動員して開発しているからできる芸当だろう。</div><div>M$はスクリプト言語用にDLRという汎用VMをリリース済み</div><div>(開発続行中)。</div><div>.NetのOSS実装Mono、SilverLightのOSS実装MoonLightは共にOSS</div><div>ではあるものの大企業(Novell)がフルタイム開発者を動員して開発</div><div>しているという点ではオリジナルと同じ。</div><div>大企業がかまないOSSで同規模のことをやるのは難しい。</div><div><br /></div><div>DLRにしても、1.0ではJavaScriptのみに対応し、2.0でのRuby、</div><div>Python等対応予定となっている。</div><div><br /></div><div>よもやま話を一つ。</div><div>汎用VMとして将来有望なのはLLVM(Low Level VM)、ネイティブ</div><div>言語に適用でき、動的最適化可能という変わり種。既に</div><div>Mac OS X TigerのCore Image等での採用実績がある。</div><div><br /></div><div><br /></div><div>RubyとPerlはそのリリース戦略に大きな違いがあった。</div><div><br /></div><div>Rubyは先鋭的な機能を盛り込んだ2.0のリリースに注力するよりも、</div><div>Ruby1.8の機能をブラッシュアップしつつ、VM化した1.9をリリース</div><div>するという現実的な解を選んだ。</div><div><br /></div><div>(Pythonも先鋭的な機能の投入を抑えた現実路線を選択している。)</div><div><br /></div><div>Perlは先鋭的な機能を盛り込みつつ、OO言語として生まれ変わり</div><div><span><span>VMの入れ替え</span></span>も行うという姿勢を崩していない。</div><div><br /></div><div>Perlも先鋭的な機能の搭載を保留し、OO言語化に的を絞った</div><div>バージョンのリリースに専念した方がよいのではないかと思う。</div><div><br /></div><div>Perlの現状のリリース戦略ではPerl6のリリース時期は不透明すぎる。</div><div><br /></div><div><br /></div><div>Perlの開発期間の長さも、Perl6のリリース時期を予測不能にしている。</div><div>現行安定板5.10の開発に5年以上が費やされている。</div><div><br /></div><div>Perlの「1つのことをするのに複数の方法を用意する」という設計思想</div><div>が、実装を複雑にし、開発の進捗を遅らせている点も無視できない。</div><div><br /></div><div>開発期間の長期化は現実のニーズとの乖離を引き起こす可能性がある。</div><div><br /></div><div><br /></div><div>スクリプト言語のトレンドやニーズの変化は見逃せない。</div><div><br /></div><div>5年以上前に策定されたPerl6の仕様が現在のニーズにマッチしているか</div><div>甚だ疑問である。</div><div><br /></div><div>...Perl6の仕様、昨年末にFixされる予定だった模様。Fixされたのだろう</div><div>か？Fixされていないとすれば、そのリリース時期は更に混沌としてくる。</div><div><br /></div><div>Perl6のリリース時にその時点でのニーズにPerl6がマッチしている</div><div>とは考えにくい。</div><div><br /></div><div>だからといって、新しいニーズをどんどん仕様に盛り込んでいると</div><div>何時までたってもPerl6はリリースされない。</div><div><br /></div><div>Perl6の仕様を再考しないと何時までもリリースできないのではない</div><div>だろうか？</div><div><br /></div><div><a href="http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001357">ここ</a>によると、今年のクリスマスまでにPerl6の最初のアルファ版が</div><div>リリースされるらしい、ホンマかいな。安定版が何時リリースされる</div><div>かは全くの未知数。</div><div><br /></div><div>#Perl自体はPerl5.xで既にVM化されていたので、修正しました。</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-2106416976365072642?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-91178208753743375642008-06-18T10:19:00.021+09:002010-04-08T18:23:09.985+09:00　<a href="http://www.arclamp.jp/blog/archives/spring_productivity.html">ここ</a>。あいかわらず「KY」な連中...。個人が好き勝手に<div>書いていることに逐一反応する。いい加減、きもい。</div><div>数年前から何の成長もみられない。<div><div><div><div><br /></div><div>個人が自分の思いで書いているブログに100%(?)の論証を求めること<br /></div><div>自体、間違っていることに全く気づいていない。</div><div>自分達は自分たちのプロダクトの優位性について100%(?)の論証が</div><div>できていると思っているに違いない、できていないんだが...。</div><div>この連中、反論すればするほど、相手の反論の粗を探してそこを攻撃</div><div>してくるから反論するのは時間の無駄。</div><div><br /></div></div><div>この本文の著者は本当に書きたいことの半分も書けていないと思う、</div><div>いわば書きかけの文章。その文章に一々食いつく。</div><div>この著者が問題にしているのは「アーキテクト」としての生産性であり、</div><div>「プログラマ(製造)」の生産性ではないだろう。</div><div>それを読み違えて、この著者の「アーキテクト」としての生産性に対して</div><div>狛犬もどきの連中は「プログラマ(製造)」の生産性で反論していて全く</div><div>かみ合っていないように感じる。</div><div>「アーキテクトとしての視点で見れば、狛犬もどきの製品はこじんまり</div><div>と纏まりすぎていて工夫の余地がない」というようなことがこの著者が。</div><div>書きたかったことだと思う。</div><div>「狛犬もどきの製品はそのプロダクト群の中で完結していて発展性が</div><div>ない、また、かっちりと作られすぎていてカスタマイズの余地もない」</div><div>とこの著者は感じているのではないだろうか？</div><div>狛犬もどきの製品はそのまま使用するのには向いているが、カスタマイズ<br /></div><div>の余地はない(あるいはカスタマイズするにはソースをいじるしかない)、</div><div>狛犬もどきの製品はカスタマイズを考慮されていない、</div><div>と感じている人間は案外多いような気がする。</div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">#選ぶことが大事じゃなくて作ることが大事なのでは。</span><span style="font-size:100%;"><br /></span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">「KY」なひで〜コメント、作るコストは誰が負担するんだ。</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">自分が作るコストを負担する余力のある(あるいは帰社時間に融通のきく)</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">会社にいるからいえるんだろうけど、えぐいな。</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">クライアントがそんなコスト、負担しないのは周知の事実。</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">自分のスタンスを相手に押し付けるのはどうかと思うが、見事に押し付け</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">てるな。</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;"><br /></span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">追記：</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">　　アーキテクト自身が生産性を考慮して、プロジェクトに最適化された<br />アーキテクチャとそのアーキテクチャに基づいた基盤を用意できれば、</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51);font-family:helvetica;font-size:100%;">プロジェクトの生産性も向上する、<br />個々の汎用プロダクト(部品)がプロジェクトの生産性を大きく左右する<br />わけではないと著者はいいたかっただけ。そもそも汎用プロダクト(部品)で<br />事足りるなら個々の案件にアーキテクトを配置する必要はない罠。</span></div></div></div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-9117820875374337564?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-79784425851412829142008-05-30T05:59:00.009+09:002008-06-01T22:28:09.644+09:00<div><span class="Apple-style-span" style="color: rgb(75, 99, 32); white-space: pre;font-family:'Lucida Grande';font-size:11px;">インスール時に使用言語を日本語に設定しているにも関わらずKDEが日本語化されない。</span></div><div><span class="Apple-style-span" style="color: rgb(75, 99, 32); white-space: pre;font-family:'Lucida Grande';font-size:11px;">language-pack-ja.deb language-pack-kde-ja.deb</span></div><div><span class="Apple-style-span" style="color: rgb(75, 99, 32); white-space: pre;font-family:'Lucida Grande';font-size:11px;">(Ubuntu 8.04 日本語ローカライズド Desktop CD のリポジトリから<a href="http://www.ubuntulinux.jp/products/JA-Localized">取得</a>) </span></div><div><span class="Apple-style-span" style="color: rgb(75, 99, 32); white-space: pre;font-family:'Lucida Grande';font-size:11px;">をインストールするとKDEの設定画面で日本語が設定可能になる。<br /></span></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7978442585141282914?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-12751513990953689672008-05-30T05:49:00.002+09:002008-05-30T05:58:36.177+09:00<span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 11px; white-space: pre; ">Fedora9Betaで発生していた現象は流石に解消。</span><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 11px; white-space: pre;">インスール時に使用言語を日本語に設定しているにも関わらずKDEが日本語化されない問題は放置のまま。</span></div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 11px; white-space: pre;">kde-l10n-Japanese-4.0.3-4.fc9.noarch.rpmをインストールディスクからインストールすると<br /></span></div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 11px; white-space: pre;">KDEの設定画面で日本語を選択可能になる。</span></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-1275151399095368967?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-53620973588643008492008-03-29T15:50:00.008+09:002008-03-29T22:16:42.176+09:00インストーラでデスクトップ環境としてKDEのみを選択して<br />インストールしてから、再起動後にログインしようとすると<br />ウインドウマネージャの起動が途中で中断されてログイン画面<br />に戻る。<br /><br />Fedora9のログインマネージャにKDEのセッションに関する設定<br />がないため、このような現象が起こっているようだ。<br /><br />いくらGNOMEびいきだからといって、これはないだろう、Redhat。<br />ベータ版といっても...。この問題が解決するまでFedora9は様子見。<br /><br />基本的にGnome嫌いなのでGnomeを使う選択肢は自宅マシンではない。<br />　<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5362097358864300849?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-61240925359263151282008-02-27T22:42:00.022+09:002008-03-21T00:30:34.155+09:00この本の帯には「<span style="font-weight:bold;">DBエンジニア</span>に必要なSQLの<br />正しい書き方・考え方が身につく」とありますが、この本はDBエンジニア<br />のみならず<span style="font-weight:bold;">プログラマ</span>にもお奨めです。<br /><br />自分は外部結合くらいまでを理解してそれから先には踏み出してきません<br />でした、その必要も感じてきませんでいた。<br /><br />ところが、この本で目から鱗が落ちました。<br /><br />SQLの初級者を中級者に引き上げる教科書が今までありませんでした<br />、今はこの本があります、その教科書になりうる一冊です。<br /><br />図を交えるなど文章が工夫されていて、集合論等のえてして小難しく<br />なりがちなテーマがかなり解りやすく説明されています。<br /><br />SQLのライティングレベルを初級から中級に引き上げたい人は必読の<br />一冊です。<br /><br /><iframe scrolling="no" style="width:120px;height:240px;" frameborder="0" src="http://rcm-jp.amazon.co.jp/e/cm?t=asip2k25-22&o=9&p=8&l=as1&asins=4798115169&fc1=000000&IS2=1&lt1=_blank&lc1=0000FF&bc1=FFFFFF&bg1=FFFFFF&f=ifr" marginheight="0" marginwidth="0"></iframe><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-6124092535926315128?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-55430934288670467312008-02-17T19:26:00.040+09:002010-04-08T18:31:05.423+09:00「お客さまのため、お客様第一」は建前、本音は別。本音を建前でくるん<div>で誤魔化しているだけ。顧客の前では建前を本音のように語ることも必要、<div>それが駆け引きというかセールストーク。<br />SI屋が建前を前面に押し出すと苦労するのはそのSI屋の下についている</div><div>人間。本気で「お客さまのため、お客様第一」と思っているSI屋がもし</div><div>いれば、ついていくのは危険、そんなSI屋はまずいないが...。</div><div>「お客さまのため、お客様第一」を本音的に掲げるSI屋の下についた</div><div>人間はきっと土日出勤・徹夜当たり前の日々を(定期的に?)エンドレスに</div><div>送ることになる。数年(10年以内)でリプレースされるシステムにそこまで</div><div>自分の時間(人生)を捧げることに意味があるのか、甚だ疑問。そのSI屋へ</div><div>のそこまでのコミットに見合った対価を下についた人間が得られていれば、</div><div>それはそれでいいかもしれないが...そんなケースは稀。(断っておくが対価</div><div>は金銭だけを指しているわけではない、充足感・達成感・数年で陳腐化</div><div>するような技術知識は対価に当たらない。)</div><div><br />「お客さまのため、お客様第一」を本音的に掲げるSI屋はエンジニアの</div><div>不平不満を抑え込むためにエンジニアの前でも「お客さまのため、</div><div>お客様第一」を念仏のように唱え、エンジニアを納得させようとする。</div><div>対顧客向けのトークをエンジニアに対しても展開している時点でその</div><div>SI屋の底の浅さを感じる。</div><div><br />「お客さまのため、お客様第一」という言葉には水戸黄門の印籠のような</div><div>効果があるんだろうか？(いや、ない。)</div><div><br />SI屋は解らないが、エンジニアはクライアントのために働いているわけ</div><div>ではない。</div><div><br />[補足]<br />SI屋の手掛けるシステムはクライアント企業の業務と深く結びついている</div><div>ので、クライアントの業務手順に大きな変革があれば、システムは</div><div>リプレースされる。リプレースされない場合には原形を留めないほどの</div><div>大改造となる。SI屋の手掛けるシステムはクライアントの業務の小さな</div><div>変化には対応できるが変革と呼ばれるほどの大きな変化に対応できる</div><div>ほど柔軟には作られていない。クライアントの業務の小さな変化への</div><div>対応は無論、システムの小規模な改造。クライアント企業の業務変革の</div><div>スパンは数年(10年以内の)間隔でやってくる。</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5543093428867046731?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-14368897085722248882008-02-09T09:19:00.002+09:002010-04-08T18:36:34.170+09:00SIerの身分制度と収益構造が密接に結びついているから。<br />SIerの身分制度は言わずもがなで、経営陣>コンサルタント＞SE<br />＞＞プログラマ。<br />まず、収益構造からみてみる。<br />１つのプロジェクトに投入できる人数はコンサルタント＜SE＜＜プログラマ。<br />つまり、プログラマの担当する製造の日数を契約時の工数で最大化すれば、<br />会社は儲かる。製造の人月を契約時の工数で最大化するためには単価の安い<br />平凡なプログラマを投入することで製造日数を多く見積もるのが一番、<br />その副次効果としてテストの日数も多く見積もれる。<br />この方法だと、プロジェクト単体から得られる利益がその規模に比例するよう<br />にできるので、SIerにとっては都合が良い。<br />優秀なプログラマを育てると、少ない人数で製造でき、バグも少ないので、<br />製造に掛かる日数とテストに掛かる日数が激減し、プロジェクト単体から<br />得られる利益が減少する。<br />プロジェクト単体から得られる利益がその規模に比例する状態を維持するには<br />プログラマを育てないで使い捨てにするのが一番なのである。<br />製造の日数を最大化する現状の方法ではプログラマを育てないことで<br />プログラマに払う報酬を安く抑えプロジェクト単体の人数の最も多い身分の<br />人件費を最小化するのがコスト削減に繋がっている。<br /><br />SIerの身分制度については組織構造と収益構造が深く結びついている。<br />SIerでの人数分布は経営陣＜＜コンサルタント＜SE＜＜プログラマ。<br />SIerの年間の売上が決まっている(プロジェクト単体では受注時に決まる)<br />中で、人数が少ない身分により多くの報酬を払うようにすれば、SIerは<br />儲かる。一番人数の少ない経営陣にとっては自分たちへの報酬が最大化し、<br />都合が良い。<br />SIerのピラミッド構造は今後も変わることはない。、<br />SIerの組織の中ではプログラマを評価しない仕組みが既に出来上がって<div>いるので、優秀なプログラマが行う行為が設計かどうかを議論する</div><div>ことに全く意味はない。<br /><br />毎年毎年、大手・中堅のSIerには安い賃金で働かせることのできる<br />新入社員がわんさか入ってくるので、入社後数年の若手社員は<br />プログラマとして扱ってそれからSEにジョブチェンジさせている。<br />足りない分は外注・派遣で補い、単価を抑える。外注のほうも大手・中堅<br />のSIerに単価の安いエンジニアを薄利多売で投入して利益をあげる(外注の<br />場合は単価の高いエンジニア(SE)数名と単価の安いエンジニア(PG)の</div><div>セット売り、比率はSE＜＜PG)。外注・派遣業者のほとんどは自分たちの</div><div>利益を圧迫する人材育成にコストを掛けることはない。<br />専門学校や大学からの安くつかえるプログラマの供給は途絶えないので、<br />このSI業界の体制が変わることは当分ない。<br /><br />そこにギーク志向エンジニアを育てる土壌はない。<br /><br />[蛇足]<br />原価 + 利益 = 価格、クライアント向けと内向けでの原価が違うこともある。<br />クライアントの出せる金額は上限が決まっていることが多い。原価を低く<br />抑えることで利益の部分を大きくする。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-1436889708572224888?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-2226125430600043132008-02-03T11:25:00.003+09:002008-08-16T14:43:46.949+09:00その理由の一端はRubyの型の扱いにあるように思う。<br />Rubyは全ての型をオブジェクトとして扱い、それらの型はRubyの<div>クラスライブラリとして外部に公開されている。<div>Rubyは変数への代入時にその型が決定され、変数は代入される度に</div><div>代入されるオブジェクトにより型が変化する。<br />Rubyは扱うオブジェクトの強い型付けが行われていながら、変数への代入時に<br />動的片付けを行う。Rubyは強い型付けと動的型付けの両方を採用している。<br /><br />ちなみのPHP4は型が完全に実行環境の中に隠蔽されている、弱い<br />型付けの言語。<br /><br />型の他にもJavaの将来の言語仕様にも取り込みやすい素地が揃っていて、<br />Javaにコミットしてきた企業にもその類似点から薦め易いLLだから<br />SunはRubyに熱心なのではないだろうか？</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-222612543060004313?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-78938472871931756902008-02-03T08:01:00.001+09:002010-04-08T18:44:39.816+09:00SIを商売にする人たちはとかくRubyとJava(C#?)について自分たちの<div>閉じた世界での見解をあたかも全てであるかのように発信する。<br /><br />RubyとJava(WEB限定)でできることに差がないならJavaを選択する</div><div>よね、というのがその最たるもの。そこに「自分たちの業界では」</div><div>という注釈が付くことは稀。<br /><br />Javaは時間を掛けてかっちり組むのには向くけど、短期間(数日)で</div><div>アイデアを形にしてリリース・継続的変更のサイクルを数時間～</div><div>数日単位で行っていくのには向かない。Java自体がそもそもコード</div><div>量を減らして開発をスピーディに進めることを主眼にした言語では</div><div>ないし、EOD(Ease Of Development)、EODとJavaで騒いだところで</div><div>対LLではその生産性には埋まらない溝がある。<br />Javaの親であるSunが何故Rubyに投資しているのか、考えたほうが</div><div>いい。<br /><br />変化が緩やかな業界では保守性等を考慮してJavaでシステムを組む</div><div>ことに意味があるが、日々急速に変化する業界では今日リリースした</div><div>サービスが近日中には陳腐化するので、保守性等を過大評価して生産</div><div>性の見劣りする言語で組むことに意味はない。<br /><br />サービス(顧客にどんなサービスを提供できるか)に軸足をおいた場合、<br />Javaで開発することに意味はない。そのサービスで何ができるかが<br />問題であって、そのサービスが何で作られているかには何の意味も<br />ない。サービスの迅速な提供が重要になるので、サービスを短期間で</div><div>開発できる生産性の高いプログラミング言語が必須となる、<br />サービスの開発に時間をなるべく掛けないことが求められる。<br /><br />SI屋の業界では状況が異なる。SI屋はクライアントに提供する</div><div>ソフトウェアで何ができるか(そのソフトウェアが顧客にどんなサービス</div><div>を提供できるか)ではなく、そのソフトウェアの構築に掛かった時間で</div><div>対価を受け取る。SI屋は構築したソフトウェアをクライアントが利用</div><div>しなくても別に損はしない。何故なら、仕様についてクライアントと</div><div>合意さえできていて、そのソフトウェアに仕様以外の深刻な問題が</div><div>なければ、クライアントとの契約を満たしているので、SI屋の構築</div><div>したソフトウェアが実用にたえなくても、クライアントは契約に応じた</div><div>対価をSI屋に支払わなくてはならないからである。何故支払わなくては</div><div>ならないかは自明、顧客と受注時にそのように契約を交わしているだけ。<br /><br />ちなみにSI屋は変化が緩やかな業界をターゲットに商売をしているケース</div><div>が大半。短期間(数日)でアイデアを形にしてリリース・継続的変更の</div><div>サイクルを数時間～数日単位で行っていくことが要求される業界では</div><div>上記のようなSI屋のビジネスモデルは成立しない、だから、そのような</div><div>業界をSI屋は避けてとおる。<br /><br />そして、SI屋は自分たちの構築するソフトウェアを高級そうに見せること</div><div>ができ、その構築により多くの時間を掛けることのできるプログラミング</div><div>言語を選択する。何故なら、短時間で構築できては商売にならないから。<br /><br />そこでJavaの登場、LLとの比較では実行速度や保守性等を引き合いに</div><div>出して、クライアントを説得する。生産性よりも保守性・実行速度が</div><div>etc大事ですよとクライアントに...。<br /><br />言語自体の実行速度ならJavaはRubyに勝てるが、Rubyでは実行速度が</div><div>要求される部分はCorC++で組まれて拡張モジュールとして言語に</div><div>アドインされるので、トータルとしてみた場合は言語自体の実行速度に</div><div>あまり意味はない。<br /><br />(特定の)クライアントを相手にするせよ、(不特定の)カスタマーを相手に<br />するにせよ、サービス(顧客にどんなサービスを提供できるか)が大事で<br />そのサービスを支える技術には意味があるが、そのサービスを提供する<br />ソフトウェアの構築にどの技術を使うか、その優劣について議論すること<br />に意味はない。更にいえば、その時々で変化する技術のトレンドについて<br />本質ではなく、重箱の隅を議論することには何の意味もない。<br /><br /><蛇足><br />Java製フレームワークを作ってRails対抗を打ち出している人種は何故</div><div>そのコードを読む人間が作者界隈にしかいないのかも考えたほうがいい。<br />そのフレームワークは作者周辺にしかわからない、他の人間は容易には<br />解読できないようでは...読みやすい、理解し易いコードというのも生産性</div><div>の一端。作者界隈にしか解読できないフレームワークは商用プロダクト</div><div>と大差ない、OSSはお墨付きではない。タダで使って利用者が社内で付随</div><div>コストを負担するか、商用サポートを購入して付随コストを外部に支払う</div><div>か、ただ、それだけの違い。だから、学習コストだけで済む枯れた</div><div>フレームワークから利用者は中々新しいものに移行しない。<br /><br /><蛇足><br />エンジニアは自分がコミットした技術を他人に押し売りしたがる。<br />その最たるものが「狛犬もどき」、関東方面では何処にでも出没<br />して、自分たちのプロダクトはブレイクスルーだと喧伝する、<br />LL使いからは何処がブレークスルーだと白い目で見られている<br />模様、かのRuby設計者は「Javaの世界ではブレイクスルーなんだろうね」<br />のフィーリングで呆れかえっているらしい。<br />「狛犬もどき」は技術をこねくりまわして喜んでいる集団、それも<br />技術の本質ではなく重箱の隅を。<br />「狛犬もどき」が世界に通用しないのは技術の重箱の隅をこねくりまわ<br />しているから。Rubyが世界に通用した一端は本質的な技術に取り組んだ</div><div>から。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7893847287193175690?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-77183654862484871482008-01-04T15:00:00.000+09:002008-01-07T12:51:40.972+09:00全くといってよいほど、ない。(真の)ギークを目指すなら、<br />SIerに居続けるのは時間の無駄、スーツにいいように<br />使われて人生を浪費し、自分の精神をすり減らすだけ。<br /><br />SIerに居続けるならスーツに転向するしか生きる道はない。<br />顧客の業務を理解し(理解するためにはまず覚え、頭の中で<br />咀嚼しなくてはならない)、顧客と折衝し、プロジェクトを<br />まわし、金勘定をする方法を覚えるしかない、ギークの<br />ロジックを捨てスーツのロジックを身に纏うしかない<br />のである。<br />一部にSIerの中で自分の立ち位置を確保するギークがいるが、<br />その人は例外中の例外に当て嵌まった人物であり、稀少な<br />存在、それを目指すのはやめたほうが良い。同じ会社では<br />尚更近い世代に同じ立ち位置のギークな人材は僅かしか<br />必要とされない。この狭き門に挑むのは茨の道を往くことで<br />あり、最後に薔薇色の未来が待つ可能性は限りなく低く、<br />そこに到達できる人間も極僅か。<br /><br />OSSというSIerにとっては無料(タダ)で使える有難いソフトウェア<br />群が現れ、その傾向は益々強くなっている。<br /><br />一応、スーツに転向したからといって薔薇色の未来が待ち受けて<br />いるわけではないことも付け加えておく。他のスーツにいいよう<br />に使われる局面は回避しやすいかもしれない。<br /><br />スーツを指向しない、あるいはスーツが自分に向かない<br />のなら、SIerに勤めるのを辞めて、業務システム開発<br />以外の道に進むのが最善の選択肢である。<br /><br />少なくとも、ギーク指向の本人にとってはどうでもいい<br />システムを作って人生を浪費する苦痛からは開放される。<br /><br />システムを実装する技量があることと、業務システム開発<br />に魅力を感じないことは別次元の問題。<br /><br />SIerでの業務システム開発に魅力を感じる(真or真指向の)ギーク<br />はいない。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7718365486248487148?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-81070249083924815692008-01-04T07:51:00.000+09:002008-01-04T13:04:09.957+09:00ギークかつスーツであろうとする、とち狂ったスーツも<br />いるようだが、そんな存在は100%ありえない。<br />まぁ、精々、スーツ兼"なんちゃって"ギーク"が関の山。<br /><br />ギークかつスーツの両方を満たすことができると考えている<br />時点で、そもそもギーク・スーツの根本的な違いを把握<br />できず、枝葉末節(表面)のみを見て、その違いを自分の<br />ロジックで捉えようとしている、お馬鹿なスーツという<br />ことになる。実際、その御仁の文章ではギーク・スーツ<br />の根本的な違いについては一切触れられていない。<br /><br />ギークのロジックとスーツのロジックは完全に別物。<br />ロジック≒行動原理・論理、ギークとスーツは<br />この根本(根底)、魂(?)の出発点が異なる。<br />真の意味では"ギーク"と"スーツ"は対極に位置する<br />存在なのである。<br /><br />人間をおおまかに分類すると、(真の)ギーク、(真の)スーツ、<br />なんちゃって"ギーク"、なんちゃって"スーツ"、その他<br />ということになる。<br />(真の)ギーク兼なんちゃって"スーツ"、<br />(真の)スーツ兼なんちゃって"ギーク"、<br />なんちゃって"ギーク"兼なんちゃって"スーツ"<br />は存在しうるが、(真の)ギーク兼(真の)スーツという<br />存在はありえない。<br />人間はその行動原理によって"スーツ"、"ギーク"の<br />どちらかに傾いている。"スーツ"、"ギーク"の中庸<br />に位置する人間はいない。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8107024908392481569?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-61377287260246312122008-01-01T01:07:00.000+09:002008-01-01T01:08:56.865+09:00　　謹賀新年、あけましておめでとうございます。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-6137728726024631212?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-45098221461485524652007-12-29T23:19:00.001+09:002010-04-08T18:48:43.903+09:00埋まらない...絶対に。<br /><br />日本のSIerの構造ではギークは評価されず、スーツが評価される<br />ばかり。SIerの経営者の頭の中では仕様書が完成した時点で<br />システムは完成したも同然という誤った認識が蔓延っている。<br />ギークを仕様書の転記屋くらいにしか認識していないのである。<br /><br />SIerのスーツは頭の中の穴だらけの仕様を仕様書におとし、<br />そのツケを全てギークにまわすことが多いにも関わらずである。<br />スーツの多くは穴だらけの仕様による不具合を全てギークのせい<br />にして自分に非がないかのように振舞う。<br /><br />SIerのスーツは「ユーザ」を持ち出して自分に都合の<br />よい方便でギークを納得させようとする。<br />そこで、スーツの言い分に騙されるようでは"お先、真暗"。<br /><br />SIerのスーツにとって、建前上お客さんは大事、実際は<br />ユーザ第一と言いながら、ユーザからの対価(=自分への対価)<br />が第一。<br /><br />スーツはスーツの論理で動いていて、ギークを理解しよう<br />とはしない、理解しているふりをするのみである。<br />ギークに自分の論理を押し付けて、上手く使おうという<br />スーツが大半。<br /><br />スーツはギークがいなければ何もできない、仕様があっても<br />優秀な実装者がいなくてはシステムは完成しないが、<br />ギークを自分と対等だと思っているスーツは日本のSIerには<br />いない。<br /><br />真のギークを目指すなら、SIerでスーツと仕事をするあるいは<br />し続けるのは百害あって一利なし、時間の無駄。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4509822146148552465?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-49238735852444812592007-12-23T20:25:00.001+09:002010-04-09T09:29:48.270+09:00<a href="http://d.hatena.ne.jp/asip/20071223#1270772948">http://d.hatena.ne.jp/asip/20071223#1270772948</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4923873585244481259?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-9743285190522203152007-12-23T11:01:00.000+09:002007-12-29T01:39:08.076+09:00JBoss5 beta3がでた。<br />JBoss MicroContainer(MC)2.0を積んだ最初のリリース？<br />JBossも初期のJBoss SeamにDIコンテナとしてJBoss MCを組み込んでいたこと<br />もあり、JBoss MCを最初の頃、Spring etcと同じような汎用DIコンテナの<br />一種かと思っていた。<br />Google Guiceの登場後、JBoss MCの位置づけが変わった。<br />WebBeans仕様をJBossがJCPに提案し、SeamをWebBeans仕様のRI<br />(参照実装)と位置づけ、WebBeans=DIコンテナの共通API、<br />Seam=WebBeans対応のDIコンテナという図式にした。<br />JBossはこの位置づけ変更に伴い、JBoss MCを汎用DIコンテナでは<br />なく、JBoss AS用のサービス統合基盤と(GeronimoのGBeanと同じ位置<br />づけに)位置づけし直した。<br /><br />JBossはJBossAS5に着手した辺りから、プロダクト間での共通機能の<br />切り出し、ライブラリ化を加速している。DIコンテナ等のプロダクト<br />レベルでの傾倒ではなく、もっと低レベルの層に重きを置いている<br />印象。低レベル層にコミットすることでプロダクトの底上げを図って<br />いるように感じる。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-974328519052220315?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-3271195134025151892007-12-18T06:38:00.001+09:002010-04-09T09:12:43.861+09:00<a href="http://d.hatena.ne.jp/asip/20071218#1270771909">http://d.hatena.ne.jp/asip/20071218#1270771909</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-327119513402515189?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-80694555629993153562007-12-02T00:55:00.003+09:002010-04-09T09:20:41.431+09:00<span class="Apple-style-span" style="color:#0000EE;"><u><a href="http://d.hatena.ne.jp/asip/20071202#1270772275">http://d.hatena.ne.jp/asip/20071202#1270772275</a></u></span><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8069455562999315356?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-85253386773604849222007-11-11T22:55:00.000+09:002007-11-12T07:00:43.450+09:00また、JPAやHibernateの粗を根拠に自家製プロダクト、マンセーやってます。<br />S*Daoの時と同じ手法でS*JDBCのセールストークをやってます、進歩なし。<br /><br />そもそもS*JDBCはJDBC&SQLの単純なラッパ以外の何物でもない。<br />S*JDBCの比較対象がJPAやHibernateというのがそもそもおかしすぎる。<br />狛犬もどきのカリスマがあげているJPAやHibernateの粗、JPAやHibernate<br />を業務システムで採用した経験のあるまともなエンジニアならほぼ誰でも<br />知ってます。今更、他人から講釈を受けるような類の話でもない。<br />狛犬もどきのカリスマは誰に対して講釈をたれているんだろうか？謎だ。<br /><br />JDBC&SQLの単純なラッパとして実装されたライブラリならどれでも<br />狛犬もどきのカリスマが実施しているようなベンチマークでは性能的に<br />JPAやHibernateに難なく勝てる。<br />相手の弱点をあげてそれに対する自家製プロダクトの優位性を主張する<br />セールストークをやってる時点で底が浅いのが丸わかり。<br />相手の短所は口撃しつつ、相手の長所は自家製プロダクトに組み込んでるのが<br />笑える。<br /><br />Ruby界隈でも話題になってるけど、最近は自動翻訳機能を実装したWEB上の<br />サービスがある。日本語で書いてるから外人には読まれていないと思って<br />書いていると自動翻訳を利用して読まれてたりすることがあるらしい。<br />現にSunのエンジニアがブログに「日本語で書いた記事を同僚の外人<br />エンジニアが読んで、ショックを受けた的な連絡があった」と書いて<br />いたりする。<br /><br />上記のようなセールストークをブログ上で展開しているのを外人が読んでいて<br />冷めた目で見てたりする可能性なんて考えてもいないんだろうが。<br /><br />そういえば、Springに対する同様のセールストークを狛犬もどきのカリスマは<br />「Rod Jhonsonとの対談(?)」で詫びたらしいが、相手がどう思っているのかは<br />謎。アウトオブ眼中かもしれないが,,,。<br />(同じようなことを以前書いたような...。)<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8525338677360484922?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-34288771418752048962007-11-10T13:35:00.000+09:002007-11-11T23:52:30.706+09:00「舶来信仰を打破するためにまず日本で頑張ります！」ってのが笑える。<br />確か去年のJavaOneに気炎を吐いて乗り込んだはいいものの聴衆はほとんど<br />米在住の日本人というオチでおわったはず。知名度が全くない<br />状態で乗り込んだら絶対そうなる罠。知名度がないから、BOF(Bird Of Feather)<br />という扱い。それに気づかずに乗り込んだこと自体がアレだな。<br /><br />以前にも書いた(後、狛犬もどきの中の人がウザかったので消した)けど、<br />欧米で成功するためには草の根からの浸透が必須。<br />狛犬もどきの"いきなりメジャー、一発逆転満塁ホームラン"的なアプローチは<br />時間の無駄。件のカリスマは「欧米の著名エンジニアとの対談」とか「JavaOne<br />等イベントへの参加」を通して一足飛びに世界進出という路線が好きなだけ。<br />狛犬もどきの世界進出に関するこれまでの動向を整理してみると"地道な活動"<br />をする気がないことがよくわかる。<br />ありもしないレールで路線を組んでいる時点で終わってる。<br /><br />以前、JBossのエンジニアと対談して対談の最後に「一緒に何かやりましょう」<br />的な別れの挨拶になったらしいけど、JBossからは音沙汰なし。<br />狛犬もどきのプロダクトにJBossが注目するようなアイデアはなかったんだろう。<br />そのあと、JBossのGavin King氏はGoogleのGuice開発者と組んでWebBeans<br />仕様策定中。狛犬もどきのカリスマはアウトオブ眼中。<br />狛犬もどきのプロダクトはほとんど舶来のアイデアの再実装だし、世界標準に<br />取り込まれそうなアイデアは何もない。<br /><br />Rubyは草の根レベルでの浸透に寄与する地道な活動が実を結んで、世界進出<br />に成功した。いきなりソフトを引っさげて世界進出したわけではなく、英語圏<br />用のメーリングリスト開設や様々なドキュメントの英訳等の地道な活動を何年<br />も続けてきた結果、世界でメジャーになってきている。Rubyが凄いソフトウェア<br />だから世界進出に成功したわけではない。<br /><br />「なぜRubyが世界進出に成功したかを正しく分析できていない」時点で<br />狛犬もどきの世界進出成功はありえない。<br /><br />世界進出どころか日本で高普及率も難しい。日本は大手SIを主軸とした下請<br />構造が幅を利かせてるから、大手SIからコミットされない限り、日本のSI業界<br />での大ブレークは難しい。<br />大手SIは世界標準が好きだから自社製品以外の独自仕様タップリの国産<br />プロダクトは世界で認められでもしない限り、採用しないと考えられる。<br />OSSかどうかなんてのは採用プロダクトの選定にあまり関係しない。<br />どちらかといえば世界市場での採用実績のほうを優先する、採用実績が<br />豊富ということはそれだけ利用されているということであり、その結果<br />ある程度のレベルまで枯れてきていると判断できるから。イベント等を<br />通じて名だけが知れ渡っているような知名度は意味がない。<br />大手SIにとって商用サポートがあり、高度な専門知識を持つエンジニアが終日<br />対応してくれる環境が望ましいのは当たり前。<br />以前にも書いたが「OSSなんだからソースを読んで自分で直せ」なんてのは<br />論外。大手SIの業務システム開発部門に"フレームワークのソースコードを<br />解析して難題を適切に解決できる"クラスのエンジニアはほとんどいない。<br />そのクラスのエンジニアが大手SIの業務システム開発部門にゴロゴロいると<br />いう想定は無意味。<br />OSSは、Redhat、JBoss、MySQL etcのように専門の会社の戦略としてOSSを<br />推進してでもいない限り、開発者が分散していることもあり、上記の<br />ようなレベルのサポートが提供されるケースはない。だから、世界市場<br />での採用実績がより重視される。<br /><br />「"世界市場での採用実績"の重視傾向」を"舶来信仰"と勘違いしている<br />時点で狛犬もどきのカリスマは情報分析能力に欠けていると言わざるを<br />えない。<br />"舶来信仰"なんていう日本のSI業界にありもしない偶像に挑戦している<br />時点で終わってる。<br />ありもしない偶像に挑むカリスマ(?)を応援する狛犬もどき崇拝者は、水車を<br />怪物と勘違いして挑みかかるドンキホーテを応援するセバスチャン(?)に<br />重なる。<br /><br />そんなに知名度のない時点で非営利法人なんて立ち上げてる時点でかなりアレ<br />だが...日本国内に留まっていてもジリ貧。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-3428877141875204896?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-47920754123878795062007-10-27T15:45:00.000+09:002007-11-11T23:43:50.952+09:00今度はJPA仮想敵で俺達サイコーやってます。<br />「*2JDBC」のセールストークでマーチン・ファウラーの<br />「流れるようなインターフェイス」引用してますが、JPAの<br />インターフェイスをパクっている時点で既に論理的に破綻してます。<br />JPAベースで流れるようなインターフェイスを実現するラッパーは作成<br />可能であり、流暢なインターフェイスを実装していることが「*2JDBC」<br />のセールスポイントにならないことは明らか。<br />CoC(規約重視)マンセーで使った偽太陽etcがユーザ層の拡大に失敗している<br />からCoCやめてみました、それだけ。<br /><br />特定のDIコンテナに統合されている時点で「*2JDBC」は個人的には利用対象<br />外、モノは悪くないとは思うが狛犬もどき２に依存する気にはなれない。<br />"*2JDBC"は"*2DAO"の発展型以外の何ものでもないというのが感想。<br /><br /><br />"CoCの本質は最低限の規約で最大限の効果を得る"ことにあり、規約でがんじ<br />がらめにしている時点でCoCを語る資格はない。<br />偽太陽をみるとわかると思うが「狛犬もどき」はCoCの本質を理解していない。<br />例えば、偽太陽の属性の扱いまわり、実装で楽をするためにあんな変な規約<br />を導入しているとしか思えない。<br />Click等の軽量WEBフレームワークマンセーな人でも偽太陽マンセーな人は<br />少なく、狛犬もどきの信者だけが偽太陽マンセー。<br /><br />「*2DAO」についても同様、テーブルのリレーションを変数名で表現する規約が<br />気持悪かった、「*2JDBC」になってその規約がなくなったのは当然の帰結?...。<br /><br />狛犬もどきの失敗は「狛犬もどき２」の中で閉じた世界を構築していること。<br />「狛犬もどき２」中心で閉じた独自の世界を構築してるから、他所からは<br />異質にみえ段階的な移行も不可能だから既存の資産を持つエンジニアは<br />ほとんど移行してこない。<br />Springとは設計・挙動が異なると言いながら移行パスを用意していないんだから<br />ほとんど誰もSpringから移行してこない罠。<br />Spring2.xはSpring1.xからの移行パスを用意してSpring1.xのユーザのほとんど<br />を円滑にSpringに囲い込んだ...。<br />狛犬もどき２はSpring1.xの発展系の一つとでもいうべきものであり、<br />"進化(革新)系"とはよべないシロモノ。<br /><br />外側からみると、狛犬もどきの信者はハイレベルとはいえないと感じる。<br />「"*2JDBC"が流れるようなインターフェイスを実装しているからそのような<br />インターフェイスでないJPAより優れている」等のセールストークに騙される<br />時点でおわってる。<br />「狛犬もどき」自体の開発者のうちカリスマ他数名はハイレベル(?)なんだろうが...。<br />新しいプロダクトをリリースする度に行われる「セールストーク」の質の低さには<br />ウンザリ。<br /><br />「JPAがその仕様(実装？)の特性上、扱いづらい側面があるので、そのような<br />特性のない*2JDBCのほうが優れている」というセールストークも質が低い...。<br />"JPAが万能でない"ことは明らかなんだから、その特性が気持悪い人間は<br />そもそも初めから使わない。現時点で実業務でJPAを利用している人間は<br />JPAの長所短所を理解したうえでJPAを選択していると思われ、実業務で<br />使っている人間がその長所短所を理解したうえで利用していることを<br />想定していないセールストークは"質が低い"と言わざるをえない。<br /><br />狛犬もどきからは「お前たちは俺たちよりレベル低いんだから俺たちの作った<br />プロダクトを有難く黙って使ってろ」的な匂いを感じる。<br />狛犬もどきの開発者は外のエンジニアのうち、自分たちと同列ではなく自分たち<br />よりレベルが低いエンジニアをターゲットにしている、あるいは外のエンジニア<br />は須らく自分たちよりレベルが低いと思っているとしかその文面(そのカリスマが<br />綴る文章)からは思えない。少なくとも外部のエンジニアを自分たちと対等の存在<br />であるとは思っていないと感じる。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4792075412387879506?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-81338899398651873352007-10-22T06:41:00.000+09:002007-11-11T23:56:06.401+09:00Watchしていない間にJBoss5の開発が着々と進行。<br />JBoss5は<a href="http://jira.jboss.com/jira/browse/JBAS?report=com.atlassian.jira.plugin.system.project:roadmap-panel">Beta3</a>に向け開発中。<br />JBoss MC(Micro Container)2.0.0は<a href="http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=12310060&subset=-1">CR1</a>、JBoss AOP2.0.0は<a href="http://jira.jboss.com/jira/browse/JBAOP?report=com.atlassian.jira.plugin.system.project:roadmap-panel">beta2</a>を開発中。<br /><br />除夜の鐘がなる前にリリースになる可能性も。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-8133889939865187335?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-32568265115552334522007-10-20T21:58:00.001+09:002010-04-09T09:37:04.578+09:00<a href="http://d.hatena.ne.jp/asip/20071020#1270773391">http://d.hatena.ne.jp/asip/20071020#1270773391</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-3256826511555233452?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-54575867706090909552007-10-14T13:20:00.000+09:002007-10-14T13:44:58.494+09:00<a href="http://www.w3.org/TR/">W3C Technical Reports and Publications</a>から<br />XML Schema 1.1 Part 1: Structuresのワーキングドラフトが消え、<br /><a href="http://www.w3.org/TR/xmlschema11-1/">W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures</a>の最終ワーキングドラフトが出現。<br /><a href="http://www.w3.org/TR/xmlschema11-2/">XML Schema 1.1 Part 2: Datatypes</a>の最終ワーキングドラフトはそのまま。<br />W3C XML Schema1.1はW3C XML Schema Definition Language (XSDL) 1.1<br />と改名され、存続の模様。<br />W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures、<br />印刷すると170ページ近く無駄にデカイ。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5457586770609090955?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-35694135531570678272007-10-13T18:04:00.000+09:002007-10-13T23:27:42.095+09:00Safari3>>IE6>>Firefox2<br />(低い順)<br />...書きかけ。<br /><br />Firefox2、CPU利用率高すぎ、Mobile Firefox開発での改善に期待。<br />SafariはiPhone,iPod Touchへの組み込みが功を奏した模様？<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-3569413553157067827?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-8411293813573019872007-10-13T10:44:00.004+09:002010-04-10T01:33:47.464+09:00<a href="http://d.hatena.ne.jp/asip/20071013#1270830802">http://d.hatena.ne.jp/asip/20071013#1270830802</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-841129381357301987?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-40058266176518198552007-10-05T23:42:00.001+09:002010-04-09T10:03:54.695+09:00<a href="http://d.hatena.ne.jp/asip/20071005#1270775008">http://d.hatena.ne.jp/asip/20071005#1270775008</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4005826617651819855?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-23016373693392830072007-09-15T12:45:00.008+09:002010-04-10T01:22:19.814+09:00<div><a href="http://d.hatena.ne.jp/asip/20070915#1270830115">http://d.hatena.ne.jp/asip/20070915#1270830115</a></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-2301637369339283007?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-36792152226421232562007-07-29T21:14:00.000+09:002007-09-15T13:04:20.703+09:00新しい冷蔵庫を購入。冷蔵庫、高い...値段が。懐、寒っ。<br />製氷、水をタンクに入れるだけで自動的にやってくれるよ、<br />10万円超えるだけのことはあるかも...。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-3679215222642123256?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-72514637230511931692007-07-21T16:49:00.001+09:002010-04-08T18:55:30.330+09:00RubyやRoRを(仮想?)敵として設定している模様。Matz氏の書いた文章に<div>くいついているが、Matz氏およびRuby陣営からは全く相手にされていない。<br />FW作者が言語作者に...DHH氏(RoRの作者)にならまだわかるが。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7251463723051193169?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-41919140953674457262007-06-23T17:59:00.002+09:002010-04-08T18:56:52.425+09:00M$信奉者は絶賛しているが、M$信奉者以外がどのくらい高評価を下す<div>だろうか？M$はいつもクロスプラットフォームとは一線を画してきた</div><div>というか、クロスプラットフォームという甘い餌をユーザにちらつかせ</div><div>つつ、巧妙にWindowsプラットフォームに誘導してきた。<br />そして、そのての事例には暇がない。<br />OpenGLとDirectXの融和を謳いつつSGIからシーングラフAPIの技術を<br />引きだし頓挫に持っていった(?)ファーレンハイト 。FreeBSDへの移植を<br />謳いつつ、いつの間にかフェードアウトさせた.Net Framework。<br />M$のクロスプラットフォーム化の囁きの裏にはいつも自社プラット</div><div>フォームへの誘導の意図が汲み取れる。</div><div>DLRやSilverlightのクロスプラットフォーム性に夢を描くのは止めることを<br />お勧めする。<br />その囁きを信じたら馬鹿をみる、のは過去の事例からほぼ確実。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4191914095367445726?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-28898716583973263102007-06-10T13:30:00.000+09:002007-06-10T17:10:25.188+09:00似た匂いを感じる。<br />「***ならこう設定すればできるのに、他の言語ではできない。」<br />というときにその環境特有の設定の仕方はわかるが、どのような<br />原理でそうなるのかはわかっていない人間が多い。<br />その環境のみで有効な知識で止まっていて、その先はみようとも<br />しないのである。<br />PHPにしてもASP(.net)にしてもお手軽な言語ではあるが、言語(環境)<br />に特化しないマルチなWEBエンジニアを育てるには不向き。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-2889871658397326310?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-67661269116499171132007-06-10T12:30:00.001+09:002010-04-08T18:57:56.626+09:00優しさや易しさは本人や作った当人が判断するモノではない、普通。<div>それを判断するのは他人。(作った)本人やそのトリマキが</div><div>「優しさや易しさ」を主張しても、他所からみると、優しく"ない"</div><div>易しく"ない"ことが往々にしてある。<br />「優しさや易しさ」を(作った)本人やそのトリマキの尺度でしか</div><div>規定していないからこのようになる。万人(初心者?)にとって</div><div>どうなのかという視点が抜け落ちているのが何ともいえない。</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-6766126911649917113?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-7798395457408271702007-05-27T16:54:00.000+09:002007-11-11T23:46:20.605+09:00もはや、DIコンテナは最先端の技術ではないと思う。<br /><br />個人的にはDIコンテナという範疇の中での瑣末な違いに作者以外が<br />拘ることが何の得になるのか、さっぱりわからない。<br /><br />今後10年生き残る技術かと問われれば、10年生き残るかは不明と<br />答えるし、10年近く生き残る事が決まっているかのごとく書かれた<br />文章を読めば、疑問符が10個以上、頭の中を飛び回る。<br /><br />DIコンテナの登場による祭りは世界では過去の出来事にも関わらず、<br />日本の技術者の一部では未だにお祭り騒ぎが続いているようにみえる。<br /><br />DI(IoC)という概念自体はDIコンテナが登場する以前から存在し、別段<br />最新の概念ではない。DIコンテナの登場により脚光を浴びるように<br />なっただけであり、DIコンテナと共に登場したわけではない。<br />そのことは1997年刊行1998年改訂のJavaプログラムデザインの中で<br />既に紹介されていることからも伺える。<br /><br />ソフトウェア工学の分野では既に存在した概念が数年遅れで世間で<br />流行し、最新の技術のようにもてはやされるのはありがちなことだとは<br />思うが、言語仕様の概念でもない精々ミドルウェアの実装概念の一つ<br />に過ぎない技術の流行が今後何年も続いていくものであるかのように<br />錯覚しているとすれば、ある種、滑稽ですらある。<br /><br />DIコンテナはゴールデン・ハンマーでも万能ナイフでもない。<br /><br />推敲中...つづく？<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-779839545740827170?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-55424993029595809542007-05-27T11:26:00.001+09:002010-04-09T09:43:22.416+09:00<a href="http://d.hatena.ne.jp/asip/20070527#1270773768">http://d.hatena.ne.jp/asip/20070527#1270773768</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-5542499302959580954?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-40428787392954722802007-05-26T13:38:00.001+09:002010-04-08T19:13:00.772+09:00Linuxは何故GPLでありながら商用利用されるのか?は間違いだらけでしたが<br />書きたかったことはLinuxについてのことではなく、GPLと商用ソフトウェア<br />の関係についてです。<br /><br />Linuxはそのライセンスに記述されている例外条項によりその上で動く商用<br />アプリの開発を可能にしています。<br />KDE3に関してはQtベースの機能を利用したソフトウェアを開発する場合、例外<br />条項が存在せず、素のGPLであるため、商用ソフトウェアの開発はまずありえません。<br /><br />つまり言いたかったことはこうです。<br />例外条項を設けられていない素のGPLで公開されたライブラリを利用する全て<br />のソフトウェア(ライブラリを含む)は、GPLで公開される義務があり、例外は<br />認められないということです。無論、素のGPLで公開されたライブラリを利用する<br />ソフトウェアがそのソフトウェア独自の例外条項をライセンスに追加することは許可<br />されていません。<br /><br />素のGPLでライブラリを公開すれば、ほぼ例外なく商用利用されることを回避<br />できます。<br /><br />蛇足となりますが、GlassFishやOpenJDK等Sunの公開するOSSプロダクトでは<br />ライセンスをGPL+ classpath exception等の例外条項として、それらのライブラリ<br />を利用するソフトウェアの商用利用を可能にしています。<br /><br />但し、標準化団体で標準化されたインターフェイスを実装したGPLで公開された<br />ライブラリを作成したソフトウェア(標準化されたインターフェイスのみを利用)に<br />同梱した場合、作成したソフトをGPLで公開する必要があるかは議論の余地が<br />あると思います。<br /><br />[omake]<br />KDE4ではFreeDesktop.orgでホストされているD-Bus<a href="http://www.freedesktop.org/wiki/Software/dbus" target="_blank">(on</a> <a href="http://www.freedesktop.org/wiki/Software/dbus">off)</a>という<br />メッセージバスシステムを用いることでKDEのライブラリ外からのKDEのコア機能<br />の利用を可能にしています。<br /><br />[2007/5/27追記]<br />KDE3に関してはライセンスの見直しが行われ、kdelibs、kdecoreの<br />一部等Qtが利用されていないソースに関してはGPLを適用しない<br />方向に進んでいた...いつの間にか。<br />KDE4は追っていなかったのでわかっていませんでしたが<br />KDE4において現状におけるKDEのコア機能を利用するGPL<br />以外のライセンスのアプリが開発しづらい問題等を解決する取り組み<br />の一環としてkdelibs全体からＱｔに依存するコードを取り除く方向<br />に進み、kdelibsにGPLは適用されていないようです。<br /><a href="http://www.debian.org/News/1998/19981008.ja.html">KDE のコピーライトおよびライセンス問題に関するDebian のスタンス</a><br />に書かれている問題全ての解決方法にはならない気がします。<br /><br />#重箱の隅をつついて喜ぶ人がいるようなので色々と追記・修正。<br />#商用利用は「プロプライエタリなソフトでの商売」という意味です、<br />#文脈を辿ればわかることです。１から10まで説明する義務は<br />#ありません。<br /><br />#GPLなライブラリを利用したソフトはソースの公開が必須、<br />#プログラムを書いてそのコードへの対価を得て商売している<br />#場合にGPLでソースを公開する選択肢はほぼありえないw。<br />#コードではなくサービスで十分な対価を得られるのは、ほん<br />#の一握り。コードを公開してサービスで対価を得られるのは<br />#更にその一握り。業務用システムに限定すれば、ソース公開は<br />#100%ありえないw。<br />#サービスで十分な対価を得られる人間は、ミドルウェア・サポート<br />#等一部のケースを除いて、コード作成時に利用するライブラリに<br />#関して大騒ぎしないし、拘らない。より便利なモノがないか<br />#リサーチを欠かさず、スイッチしていく...99%。<br />#何故なら、コードを書くのが目的ではなく、サービスを作るのが目的<br />#だから。短期間でサービスを立ち上げられる手段を模索こそすれ、<br />#コード内で利用する何かに異常に拘ることはない、自分がその作者<br />#である場合を除いて。<br />#コード内で利用する何かに異常に拘るグループはサービスを提供<br />#することで十分な対価を得られる人間からすれば、負け組以外の<br />#何者でもないだろうと思う。<br /><br />#重箱の隅をつついて喜んでいる人に一言。<br />#ここは個人のブログ、思い込みや間違いがあっても別に問題は<br />#ありませんが何か?思い込みや間違いが気になるなら、<br />#読まなければいいだけ。読む側が思い込みや間違いを<br />#チェックするのがWEBでは常識。<br />#一つの記事を読んで鵜呑みにするのではなく、関連する記事も<br />#読んで判断すればいいだけ。間違いや思い込みで書かれた文章を<br />#鵜呑みにするのは読む側の問題。<br />#指摘されたら(狛犬もどき関連を除いて)修正はしますよ。<br />#自分が気に入らないからといって、個人のブログの重箱の隅つつき<br />#を熱心にやって、こちらの評価も下がるかもしれんが、そちらの<br />#第３者からの評価も下がっていくとは思わんのかいな。<br />#WEBのブログで一々、一から十まで調査して書くことを他人に強要する<br />#のはどうかと思うよ、気楽に書いてるブログに何で事前に調査して<br />#書くなんて面倒臭い手順を加えなくてはならないのか、よくわからん。<br />#そちらが事前調査を念入りにして書くのはそちらの勝手。<br />#自分の考えを相手に押し付けようとするところがアレだな。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4042878739295472280?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-71366499963662658132007-05-18T13:04:00.001+09:002010-04-09T10:10:43.288+09:00<a href="http://d.hatena.ne.jp/asip/20070518#1270775397">http://d.hatena.ne.jp/asip/20070518</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-7136649996366265813?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0tag:blogger.com,1999:blog-8621474887770173089.post-45883539588981717392007-05-17T06:13:00.001+09:002010-04-09T09:46:29.737+09:00<a href="http://d.hatena.ne.jp/asip/20070517#1270773947">http://d.hatena.ne.jp/asip/20070517#1270773947</a><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-4588353958898171739?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.comtag:blogger.com,1999:blog-8621474887770173089.post-69896411385018895672007-05-12T11:34:00.001+09:002010-04-08T19:03:59.630+09:00>勘違い開始---->> <br />>Linux自体はPOSIX準拠で、Linuxでも利用されているGLIBCはISOやANSIで <br />>標準化されているCの標準ライブラリを実装しています。 <br />>Linux自体はGPLですが、POSIXやISO Cで標準化されている <br />>インターフェイスでアプリを記述する限り、そのアプリをGPLで公開する <br />>必要がないのです。だから、Linuxは広く商用利用されるようになりました。 <br />>もし、Linuxが標準化されていない独自のインターフェイスのみで実装されて <br />>いたならこんなに広く商用利用されることはなかったでしょう。 <br />>POSIX準拠(UNIXほぼ準拠)であるため、UNIX用に書かれたソフトの大半が <br />>ほぼそのままLinux上で利用できたこともLinuxの商用利用の拡大に繋がり <br />>ました。 <br />>>--勘違い終了 <br /> <br />間違い① <br />GLIBCはLGPL。GPLだとばかり思い込んでました。 <br />GPLの場合には、ダイナミックリンクする場合もGPLに従う必要があります。 <br />間違い② <br />Linuxの場合、基本的にはGPLですが、例外条項が存在し、 通常のシステム <br />コールを利用するユーザプログラムについてはソースをGPLで開示する必要 <br />はない。デバイスドライバは別。 <br /> <br />詳しくは<a href="http://ukai.org/wiliki/wiliki.cgi?Linux%A4%AC%A4%E9%A4%DF%A4%CE%A5%E9%A5%A4%A5%BB%A5%F3%A5%B9%A4%CB%B4%D8%A4%B9%A4%EB%B8%ED%B2%F2">こちら</a>。 <br /> <br />LinuxやGlibcに関する上記の記述は以上の勘違いから上の文書は全くの <br />間違いです。POSIXやISO Cで標準化されているインターフェイスでソフト <br />を記述する限り、そのソフトをGPLで公開する必要がないという一文について <br />は間違いではないと思います。GPLのライセンス上はライセンス違反だったと <br />しても。 <br /> <br />正しくはLinuxは基本的にはGPLだが、例外条項により、通常のシステム <br />コールを利用するユーザプログラムについてはソースをGPLで開示する必要 <br />がないことがLinuxが広く商用利用される要因の一つであるとなります。 <br /> <br />KDE3のGUIライブラリを利用した商用ソフトが存在しません。KDE3の基盤で <br />あるQtはGPLと商用ライセンスの２重ライセンスです。Qtの開発元である <br />Trolltechはソース公開必須のGPLでQtを公開しつつ、商用ライセンスで <br />収益を上げています。 <br />蛇足になりますが、Qtは独自インターフェイスです。 <br />大手LinuxベンダがGnomeを採用する傾向にあるのは <br />KDE3のGUIライブラリでGUIベースのソフトを開発する場合、必然的に <br />QtベースとなりGPL適用の義務が発生するため、KDE3のGUIライブラリ <br />を利用した商用GUIソフトをユーザが開発することがほぼ不可能だからです。 <br /> <br />#ここに書いてあることはLinuxがGPLでありながら商用利用される理由の一つで <br />#あり、全てではありません。 <br /> <br />#狛犬もどき厨向けに書いてみた。 <br />#2007/5/26追記 <br />#まぁ、個人的には思い込みを修正できたので「odz氏、ありがとう」な心境。 <br />#http://d.hatena.ne.jp/odz/20070512/1178994457 <br /> <br />#もともと「GPLであるLinuxが商用利用できるから、GPLも商用利用できる」 <br />#みたいに思っている<meta charset="utf-8">狛犬もどき厨がいるようなので書いてみたネタ。 <br /> <br />#「LinuxはGPLだが、標準化されたインターフェイスを実装しているので <br />#商用利用できる」が本当は「Linuxは基本的にはGPLだが、例外条項を <br />#設けているので商用利用できる」だったのは本来(裏)の主旨からすれば <br />#枝葉末節の間違い。 <br />#枝葉末節に間違いはあったものの、この文章を書いた本来の目的は <br />#果たしているので問題なし。 <br /> <br />#「素のGPLでライセンスされたライブラリを利用するプログラムはGPLで <br />#配布する必要がある義務を免れないので、そのライブラリの商用利用は <br />#まずありえない」というこの文章の本来(裏)の趣旨は損なっていない。 <br /> <br />#(<meta charset="utf-8">狛犬もどき関連を除いては)思い込みを交えて文章を書かないように気を <br />#つけます。 <br /> <br />#2007/5/27追記 <br />#一部の文章を削除。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8621474887770173089-6989641138501889567?l=asipeye.blogspot.com' alt='' /></div>asiphttp://www.blogger.com/profile/14046747050441885614noreply@blogger.com0