Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/248: 1 2 3 4 5 6 7 8 9 »

もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - Nov 10, 2013

人格攻撃をしたくて書いてるわけじゃないですよ、という事はまず最初に表明しておきます。

GitHubで公開してるプロジェクトについて、幸いなことに時々プルリクエストをもらえる事があるんだけれども、その時に、何のストレスもなく「Merge」ボタンを押せる時と、そうでない時とがあるなあと思ってた。

その差は何なんだろう?と思ってたんだけど、今回treestyletabのargumentsを使っている箇所を書き換えるプルリクエストをもらって、それに関してやり取りをした事を通じて、「あ、こういう事かな」と思った点が1つあった。

それは、「相手の考えを尊重する態度が見られるかどうか」。

ロケールの翻訳であったり単純なtypoの訂正であったりというパッチではそういうのはまず見えてこないんだけど、今回のように設計のポリシーにまで踏み込んだパッチだと、互いの思惑がずれていることが見えてくる事がある。今回の場合、僕と彼とでは「こうあるべき」と思っているコードの姿がずれているんだなと思った。また、「ああ、僕がこれほど大事に思っていることが、彼にとっては些事に過ぎないと見えているのだなあ」という残念な思いも感じた。

考え方が違うことがすべて悪だとは思わない。JavaScriptの古い仕様であるargumentsから、ES6のRest argumentsへの置き換えを進めるというのは、古い物ばかり見てしまっていて且つ保守的な自分からはそういう発想がまず出てこない(大抵、どうしようもなくなってからようやく重い腰を上げる感じです)ので、自分の目が届いていないところについて「こういうのもあるよ」と教えてもらえるのは、正直、とてもありがたい。

ただ、僕が大事だと思っている事についてバッサリ切り捨てるような態度を取られるのには、いい気がしない。arguments・Rest argumentsで全部の引数を引き渡すように書くべきか、それともすべての引数をきちんと定義しておくべきか、という議論では特にそれを強く感じた。

僕は僕なりの考えを持って、過去に悩まされた色々な事例からの反省であったり、現実的にどこまでメンテナンスに時間をかけられるかという葛藤であったり、どういうコードであれば僕の思う「How」を正しく書き記せるのかであったり、といった事を考えた結果としてああいうコードを書いていたのだけれども、それらの一切合切を無視して「こうあるべき」と別のスタイルを押しつけられることに、僕はどうしても不快感を感じてしまった。コードを自分と同一視していて、自分自身を否定されたかのような感覚すらあったのかもしれない。最初の1回だったら、まあそういう前提が共有されているはずもないので、齟齬があるのはしょうがないと思うんだけど、2度にわたって否定されると、「あ、この人は僕のいろんな思いを尊重しようというつもりが全然ないんだな」と感じて、急速に心が冷たくなっていく、そんな感じがした。

何年もコードを書いてきたんだとか、自分がここまで育ててきたんだとか、そんなクソくっだらない個人的感情に基づいた見栄でもって、真理を歪めてはならない、というのは、その通りだと思う。でも、とても残念なことなんだけど、僕は大義のために自分の命や思い入れをためらいなく差し出せるタイプの人間ではなく、むしろ個人的な感情の方をこそ大事にしてしまうタイプの人間のようなのだ。僕はそういう頭の悪い人間ではないのだ・もっと賢くて理性的な人間なのだと思い込もうとしてたんだけど、実際にはそうではない・そうなれないのだなということを、31歳の今では痛感している。

思い返してみると、僕がかつて「技術系コミュニティ」という物に激しい拒否感を持っていたのは、それが理由だったのかもしれない。唯一絶対の真理として論理的な正さを偏重し、そうでない価値観は無意味と切り捨てる、そういう傲慢さや冷酷さのような物を僕は嫌っていたのだと思う。まあ、そういう自分の想いでもって彼らを・世界を変えたいと思っていたというのも、また同種の傲慢だったのだなという事も今では分かる。我か彼かではなく、どちらの価値観も並行して存在していてよいのだ、そういうカオスを受け入れることが大事なのだ、という事を認識できるようになったのは、それよりずいぶん後になってからのことだ。

ともかく、そういう残念な人間である僕にとって、一緒に作業をしたいと思える相手はやはり、僕の思いをなるべく尊重してくれる人という事になるのだなあ、と思うし、また自分が他の人と一緒に作業する時も、ある一面から見た時だけの正義をいたずらに振り回すことなく、最大限相手の思いを尊重して事にあたっていきたいなあ、と思う、そんなことを改めて考えた出来事だったのでした。

世の中には、ぬるま湯に浸かっていては駄目だ、自分の間違いをビシビシ指摘してくれる厳しい人と一緒にこそいるべきだ、という言説もある。僕はそれは、基本的にはいい事言ってると思うんだけど、でも、そこに相手を尊重する態度があるかどうかってのが、結構重要なんじゃないかと思ってる。

相手を尊重した上で、その思いを遂げるためにはもっとこうした方が良いよ、というアドバイスをしたり、その思いはこれこれこういう前提がおかしいよと新しい視点を示すというのは、僕にはまだ受け入れられるんじゃないかなって思う。でも、そうでなく、お前は間違っているからこうするべきだ、と、僕の思いを歯牙にもかけないでその人の思う正義であったりあるいは誰か第三者が掲げる正解であったりに沿って特定の行動を押しつけられるというのは、ストレスになる。その「厳しい指摘」がどっちであるかというのは、論理的な正しさだけを見ていると分からないと思う。

俗な言い方をすると、それが「愛があるかないか」って事なんじゃないだろうか。「厳しい指摘」をする時に、「指摘する側である自分の自己愛に溢れた指摘(独り善がりな指摘)」ではなく「指摘される相手への愛がある指摘」をする、というのは、なかなか難しいことだと思うけれども、せめてそう心がけたいとは思ってる。

また、逆に言うと、自分に向けられた「厳しい指摘」をすべて受け入れるでもすべて拒否するでもなく、その中で「愛のある指摘」を上手くより分けることができれば、他人の言説にいたずらに振り回されて疲弊することも、世界全部を敵に回しているかのような疎外感を感じることも、ないのかな……とも思う。

結論:愛は地球を救う!

「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - Feb 03, 2013

元のプロダクトがGPLでも、自分で開発した部分のソースは別のライセンスを指定できるよ、というエントリを書いた後で、言及した事例が自分の想像を超えた残念事例だったという事を認識して、非常に落胆しています。

ここまでのまとめ

先のエントリで言及したProximodo Liteの事例は、まとめると、こういうものでした。

  1. 元々クローズドソースのProxomitronというソフトウェアがあって、これが大人気だった。
  2. しかし、作者が死亡してしまい、作者によるメンテナンスが行われなくなってしまった。
  3. ソースがないから誰も開発を引き継げなくて、完全に死んだプロダクトプロジェクトになってしまった。
  4. しょうがないからProximodoというクローンが新たに開発された。
  5. 今後同じ事が繰り返されないように(という理由だったのかどうかは分かりませんが、結果として同じ事が繰り返されなくなる効果がある選択として)、Proximodoにはコピーレフトなライセンスが設定された。
  6. Proximodoの開発は頓挫し、機能的にも性能的にも中途半端な状態で放置されてしまった。
  7. そこにhide氏が目を付けて、改造版となるProximodo Liteの開発を始めた。このhide氏は、元開発者が様々な理由からプロジェクトの継続を断念したソフトウェアについて、ソース提供を受けてその改良版・後継版を積極的に開発している人物であった。
  8. Proximodo Liteのバイナリを公開しようとした段階になって、hide氏はProximodoがGPLでライセンスされていることに気がついた。
  9. hide氏はGPLでProximodo Liteのソースを公開するつもりがなかった(ひょっとすると、いかなるライセンスであろうともソースを公開するつもり自体が無かった)ため、バイナリ公開を断念した。
  10. それでもProximodo Liteを公開したくて、hide氏はProximodoの作者に対して、ProximodoのライセンスをGPLからBSDスタイルに変更する事を求めている。(イマココ)

実際の経緯については、一旦バイナリを公開した後、指摘を受けて公開を取り下げた上で、上記のような経緯であったと読み取れるようにページ上の記述を改変したという話もあるようですが、自分はその時の動きも改変前のページも見ていないので、どちらが事実だったのかは僕には分かりません。いずれにしても現時点ではライセンスに反している状態にはなっていないということで、とりあえず、以下の記述の前提としては、僕が見た時に書いてあった通りに解釈した上記の「経緯」が事実であったと仮定することにします。

意義ある活動である事は事実

僕自身釈然としない物がありますが、hide氏のしている事が善か悪か、という事は一概には断ぜられません。

ソフトウェアはユーザに使われて用を果たしてナンボの存在、用を果たせなければゴミクズ同然です。いくらかつて好評を博したソフトウェアであっても、今の環境で動かなかったり、重篤な脆弱性が放置されたままであったりするならば、ユーザにとっては無価値です。そういった「死んだ」プロジェクトを引き取って、新しい環境でも動くようにしたり、あるいは欠けていた機能を補ったりして、後継バージョンとして提供を続ける、という点においてhide氏の活動には大きな意義があります。

元作者が趣味の範囲で継続できなくなったプロジェクトは、他の人が趣味の範囲で引き取るのが、本来は最も望ましい自然な形でしょう。しかし誰にも引き取られておらず、それでもユーザがそのソフトウェアの利用を望むのであれば、趣味の範囲でなく仕事の範囲で引き取って貰うほかありません。つまり、プロジェクト運営専任のスタッフを雇ったり、ソフトウェア開発を生業としている人にお金を払って続きを開発して貰ったり、ということです。僕が所属しているクリアコードでも、顧客の要望を100%満たしてはくれない既存のソフトウェアについて、受託開発という形で改良して顧客に成果を提供するということは少なくないです。

その一方で、(hide氏にソースを公開する意図が無いのであれば、)Proxomitronの悲劇をまた繰り返そうとしているのか、あの過ちから何も学んでいないのか、あの悲劇を避けることよりも自分が独占的に対価や称賛を受け取る事を優先するのか、Proximodoの成果にただ乗りするだけただ乗りして何も還元しないのか、という憤りを僕は感じています。

成果を還元するということ

先程「僕も仕事で似たような事をやっている」と書きましたが、それでもクリアコードでは全社的な基本方針として、変更点のうち本来そのプロダクトに含まれているべき部分、他にも多くの人が困っているであろう部分については、アップストリームにpull requestやパッチとして還元するか、あるいはfork版として同一ライセンスの元でソースコードを公開する、という事をしています。ライセンス的にコピーレフトであろうと無かろうと、この方針は変わりません。(これが事実である事は、GitHubのオーガナイゼーションのページから各メンバーの活動状況を見てもらってもお分かり頂けるのではないかと思います。)

そして、成果を還元したい(成果をソースも含めてすべて公開したい)という思いと、お客さんに不利益をもたらしたくない(クリティカルな情報は公開できない)という思いの2つを、天秤にかけてどちらかを即決で選ぶのではなく、どちらも大切だから両立できるような道を探りたい、と考えています。自分自身が、フリーソフトウェアであったりオープンソースであったりの文化の中で育ち・育てられてきて、有形無形を問わず様々な形でおこぼれに預かってきたのだから、何かお返しをしないと格好が付かないし、誰もが収奪するばかりでは後が続かない。そのための努力を惜しむんでは自分に言い訳が立たない。そういう、誇りとか矜持とかの問題だと自分は思っています。

そこまで手間をかけられない、誇りじゃおまんま食えないよ、だからよくわからないGPLは避けてBSDスタイルを選ぶよ、という立場もあるとは思います。でもできれば、自分が1つ果実を持って行ったのであれば、畑に1鍬入れていって欲しい。そういう思いが僕にはあるので、オープンソースとかフリーソフトウェアとかコピーレフトとかについて誤解があるせいで還元できる場面なのに還元できていないという事例を見かけたら、先のエントリのような形で言及して誤解を解きたい、皆が安心して1鍬入れていける状況を整えたい、と思っています。そこで先のエントリでは、「自分で書いた部分はBSDスタイルのライセンスを設定してソースを公開し、元のソフトウェアと組み合わせた結果をGPLで公開する」というやり方を解説してみました。

上記のような事、「1つ実を取ったら1鍬入れる」を、綺麗事であるとか非現実的であるとか思う人はいると思います。宗教じみてて気持ち悪い、と思う人もいるかもしれません。そういった風潮に対して、寄付頼みの宗教団体でなくとも現実的な経済の営みの中でちゃんとできる事なんですよ、汚染物質を垂れ流さなくてもいい製品は作れるし利益も上げられるんですよ、非正規雇用のスタッフを使い潰さなくても利益は上げられるんですよ、コンプライアンスを軽視しなければ利益は出せないということはないんですよ、CSRは果たせるんですよ、という事を証明したくて、僕はクリアコードに在籍し続けているのかもしれません。(今思うと、Web標準は非現実的な絵空事ではないんだ、Web標準準拠でも格好いいWebページは作れるんだ、ということを証明したくて活動していた頃と、動機は変わっていないんですね。)

「BSDスタイルの方が発展する」という言葉と、その後に起こる事が一致していないという欺瞞

僕がこの事例で特に強い違和感を覚えたのは、hide氏の以下のコメントです。

発展しているオープンソースのプロジェクトは大抵BSDかそれに準ずるライセンスを採用している状況を鑑みて、もし後継を望むのであれば修正BSDにすべきでしたね。

Proximodo Liteのページより引用)

BSDスタイルの方が何故発展しやすいのか、そもそも何を発展と呼ぶのか。何を以て後継とするのか。そこをこのコメントではごまかしている気がしました。

オープンソースのプロジェクト自体の発展とは、そのプロジェクトがオープンソースであるままで継続的に開発が行われる事、派生プロジェクトも含めて後がどんどん続いていくことである、と僕は考えています。例えば仮にProximodoがBSDスタイルのライセンスであったとして、hide氏がProximodo Liteをクローズドソースでバイナリのみ提供するようになったとして、それを「オープンソースのプロジェクトが発展した」と言えるでしょうか。hide氏による開発が途絶えた後で誰か他の人がさらにその後継バージョンを作りたくても、もうできません。短期的には派生物が出てきても、その後が続かない、長期的に継続しないのです。僕は、このような未来を「発展した」とはとても言えません。

GPLやLGPLは、自分が開発した成果のソースコードを利用者にも開示するよう強制することで、必ずソースコードを社会に還元させるという方式のライセンスです。それに対してBSDスタイルのライセンスでは、自分が開発した成果のソースコードを社会に還元するかどうかを、その人自身の判断に委ねています。必ずしもすべての部分を社会に還元できるわけではなく、どうしても秘匿しなければいけない部分があるという場合がままある、そういう場合にGPLだと「全部公開するか、全く公開しないか」の二者択一になってしまうから、GPLのソフトウェアを元にした成果は社会に還元しづらい。BSDスタイルだと、秘匿したい部分を秘匿したままにできるので、成果を気軽に還元できる。そういう話は確かにあると思います。

AppleやGoogleは、ソースコードを再度オープンなライセンスで公開する道を選びました。Appleはゼロから製品を開発する事を避けて、LGPLのKHTMLを改良してWebKit(WebCoreとJavaScriptCore)を作り、LGPLでソースコードも含めて公開しました。そしたらその成果に載っかる形で、GoogleがV8を開発し、Chromeを開発し、それらのソースを修正BSDライセンスで公開しました。V8がオープンになっていたことから、node.jsが生まれました。皆、自分達の製品を作るための要素技術としてオープンソースのソフトウェアを採用し、成果をまたオープンソースのソフトウェアとして社会に還元しています。ソースコードをオープンに保ったままで、付加価値によって利益を上げ、継続するシステムを作り上げています。僕はこのような流れをこそ「発展」と呼びたいと思っています。

コピーレフトとBSDスタイルのどちらが「発展する」のかという議論は、どちらの方がよりソースコードを社会に還元して貰いやすくなるのかという観点での議論であって、どちらの方がクローズドな派生物を作りやすいかという観点での議論ではないはずです(そもそもGPLではクローズドな物を「作れない」わけで、そのためにわざわざLGPLという物が別に用意されているのであって、この点での議論の余地は元から無いでしょう)。そこをごっちゃにして、「BSDの方が発展する」と言って元作者にBSDスタイルのライセンスへの変更を持ちかけ、自分は成果のソースコードを還元するつもりは無いというのは、筋の通らない話だと僕は思っています。

ところで、ライセンスというのは双方(権利者と利用者)の合意で成り立ちます(合意に至らないならば、当然交渉になります)。

開発とライセンスのホットな関係より引用)

hide氏はこのように書いていますが、hide氏の合意形成あるいは交渉のやり方は、僕にはいまいちアンフェアであるように思えます。

I think that GPL is cause of the various problems.
I do not like trouble.

So please change "New BSD License" or "2-clause BSD license".
I will publish new version if it does so.
Please understand and accept my proposal!

Proximodo Liteのページより引用)

hide氏はProximodoの作者に向けてこのようにライセンス変更を求めていますが、「その上でソースを秘匿しシェアウェア化したいと思っている」「バイナリのみ公開したい」といった意図があるのか無いのかを、少なくとも僕は、この文言から読み取ることはできませんでした。

ライセンスの変更は、おいそれとできるものではありません。自分のポリシーと照らし合わせて検討し直すだけでなく、場合によっては関係するすべての人に連絡を取り、貢献して貰ったコードのライセンスを変更して良いかどうか承諾を求める必要もあります。あるいは、GPLフリーにするために、GPLな他のソフトウェア由来の部分をすべてスクラッチで書き直さないといけないことすらもあります(実際、AppleはGCCを使わないで済むようにするためにCコンパイラの再実装に多大な貢献をしていますし、僕もXUL/Migemoを問題のない形で再公開するにあたって、ライセンスが不明瞭だった部分を手間をかけて入れ換えました)。信念の問題としても手間の問題としても、それなりに重い作業である可能性があります。それだけのことを求めるにあたって、「GPLには色々問題があるからBSDにしてくれ」だけでは、説明責任を十分に果たしているとは言えないと僕は思います。自分が何故BSDスタイルへのライセンス変更を求めているのか、この「publish」がどのような意味での言葉なのか、BSDライセンスになった後で自分がどのような形で成果を還元しようと思っているのか、あるいは思っていないのかを、hide氏は十分に説明できていないのではないでしょうか。

BSDスタイルとコピーレフトとを僕が使い分ける際の基準について

「こういう事をああだこうだ言っても人は動かない」「説得になってない」といった指摘はあると思います。僕自身、他人に何を言われようともこのhide氏が方針を変えるということは無いだろうと思っています(過去の活動の事を知るまではその可能性も考えていましたが、他のBSDスタイルのソフトウェアについて「改良版をバイナリだけ公開、シェアウェア化」という事をされていると知って、これは相容れないタイプだな……と思い知りました)。ただまぁ、「そもそも元作者とこの人の2者間の話なのだから他人が口出しする筋合いではない」ということについては、確かにそうですが傍目にフェアなやり取りとはちょっと思えなかったので、前項ではその点については口出しをしてみたんですけれども。

このエントリで言いたかったのは、「なんとなくBSDのほうがよさそう」「よくわからないけどなんだかGPLって面倒そう」ということで手放しにBSDスタイルが良いとされる風潮には、僕は違和感がある、ということです。

僕自身、ライブラリとして広く使い回したい物にはMITライセンスを設定して公開していますし、そうでない物についてもGPL/LGPL/MPLのトリプルライセンス(これはかつてのFirefoxに倣ってのもの)やMPL2.0を設定するなどして、ガチガチのコピーレフトよりはもう少し緩いものを選択しています。それに、ストールマンの「何でも公開しろ」という態度は、あれはあれで傲慢に感じていて好きではありません。コピーレフト寄りであっても、どこまでコピーレフトにするかという事には個人差があるものです。

  • 自分の作った物が誰にどう使われようとも構わない、極端な話、誰かが看板だけ掛け替えた「改良版」を作って商売していようとも全く構わない、という事であれば、パブリックドメインにしたり、あるいはBSDスタイルのライセンスを選択して問題ないでしょう。
  • 自分の作った物が看板を掛け替えただけの「改良版」として勝手に商売に使われるのは我慢ならない、やるならこっちにも分け前をよこせ、それが嫌なら無償で同じ条件でソースも含めて公開しろ、という事であれば、コピーレフトなライセンスを選択した方がいいでしょう。
  • 自分の作った物がアイデアだけ引き継がれるのはいいけど、自分の血と汗と涙の結晶であるソースコードが他人にそのまま利用されるのは腹立たしい。アイデアを同じように具現化したかったら、自分で同じだけの血と汗と涙を投じて実装し直して欲しい。という事であれば、ソースコードを公開しないクローズドライセンスにした方がいいでしょう。
  • 自分の作った物がソースコードも含めて引き継がれていって欲しい、他の人が自分と同じような苦労をしなくてもいいようにしたい、人類共有の財産にしたい、という時に、コピーレフトにするべきなのか、それともBSDスタイルにするべきなのか。そこが問題です。

僕がBSDスタイルのライセンスを選択する場面は大抵は、それ以上の改良が他の誰の手によって行われなくても別に構わない、あるいは、直すときには自分で直すつもりだ、という時です。BSDスタイルのライセンスにするということは、他の人が行った改良がフィードバックされない可能性が出てくるということです。それでも別にいいやと思える時に、僕はBSDスタイルのライセンスを採用する事が多いです。既存のプロダクトの多くで共通して存在していた部分を共有ライブラリとして切り出した、という場面で僕はよくこの選択をします。

その一方で、完成したプロダクトとはちょっと言えない、まだまだ改良が必要そうだと思える物や、アプリケーションレイヤの物については、僕はコピーレフトのライセンスを設定することが多いです。僕が関心を失った後でも、必要としている人がいつでも開発を引き継げますし、その人がまた興味を失ったとしても、さらに次の人が開発を引き継げます。

その時に僕がBSDスタイルを選択していないのは、やはり、オープンな形で開発が継続していて欲しい、仮に一旦途絶えたとしてもいつでも継続できる状態が保たれていて欲しい、「継続されて欲しいという意図」まで含めて引き継がれて欲しいからです。いつか自分が帰ってきたときに継続できなくなっていて欲しくないからです。囲い込みたい、継続する流れを途絶えさせたいと思っている人には使われなくても構わない、とすら思っています(でも完全に排除するつもりもないので、選択するのは若干緩いコピーレフトにしています)。

自分が作った物をBSDスタイルのライセンスにするということは、自分が感心を失って開発を放棄した後、誰かがそれを引き継いでくれたとして、その人が機能的に不足していた部分を補って完成させてくれたとして、自分がユーザーとして戻ってきて「ここはちょっと不満があるな……」と思ったとしても、もう二度とそこに手出し口出しできなくなる可能性がある、ということです。そうなってしまうともう、涙を呑んで、車輪の再発明や再実装に精を出し、泥をすすってデバッグに途方もない時間を費やすしかありません。元はといえば自分が作った物なのに、善意でそれを社会に還元したはずなのに、なんでそんな思いをしなきゃいけないのか。目の前に既に「あとちょっとここが直っていれば、期待通りなのに」という物があるにもかかわらず、不毛な開発に精を出さないといけないのか。これほど馬鹿馬鹿しい話もないでしょう。

僕はそういう事を我慢できそうにないので、自分が趣味の範囲で作った物のうち、アプリケーションレイヤの物やまだまだ改良が必要そうな物をBSDスタイルのライセンスで公開する勇気を持てないでいます。(でも仕事でやる物については、開発する工数自体に対してお金を払ってもらえるので、ライセンスはわりとどうでもいいと思っているかもしれません。同じ事をやり直すことにやる気は湧きませんが、その分お金が出るのであれば我慢できると思いますので。)

また、僕はアプリケーションレイヤの物について、ソースを秘匿することで利益を出せるという気がしていない、というのもあります。自分がそんな革新的な物を作れるとは思っていませんし秘密の技術をマネタイズする術も持っていません。誰にでもできる事の「やり方」を隠すことでお金を稼ぐというのは好きじゃない、というのも大きいかもしれません。それよりは、やり方は誰でも知ってるけどやるのが面倒くさいとか、やり続けるのに熟練が必要とか、うまくやるのにはセンスがいるとか、そういう所からお金を頂ければいいんじゃないのかな、と思っています。日経Linux誌での「シス管系女子」の連載も、やってる内容はそんなに高度な技術は扱っていませんし、絵もそう上手というわけではないですが、漫画で技術を説明するという事にユニークな価値を見出して頂けているからこそ、連載が続いているのだと思っています(自画自賛)。

ソフトウェアのユーザにとっての寿命は人の寿命よりも短いものですが、人1人の関心の寿命や、人1人が趣味でコミットできる期間の寿命よりは長いことが多いのではないでしょうか。また、開発の主体が企業である場合も、ユーザにとってのその製品の寿命は、企業の製品開発サイクルよりも長い場合が多々あります(Windows XPが一体何年使われ続けてきたか思い出してみて下さい)し、ともすれば企業の寿命よりも長いかもしれません。開発者としてなるべくソフトウェアが長いこと生き続けていて欲しいし、ユーザとしての自分にとってもなるべく長く便利に使える物であって欲しいので、僕は上記のような方針でライセンスを選択しているし、「独占的な権利を1000ドルで売ってくれ」なんていうメールが来てもガン無視しているのだと思います。

もちろん、これは非常に悲観的な見方で、楽観的な見方からBSDスタイルの方が発展しやすい・生き残りやすいと言う人は少なくないです。コピーレフトとBSDスタイルは、この点において北風と太陽のようなもので、多少のフリーライドを容認してでも寛容であった方が最終的にはいい結果につながるだろう、という話です。また、GPLが毛嫌いされている現状ではGPLを選択することの方が却って後継の登場を妨げるから、政治的にGPLは選択できない、という話もあります(先のエントリに書いた通り、誤解によって恐れられている部分があると思っているので、それが理由でBSDスタイルを選択するというのは本末転倒だと僕は思っていますが)。僕は、これについては「そうかもしれない」と思っていて、それ故に、「誰も彼もが無条件にコピーレフトにすればいい」とまでの過激な意見は持てずにいます。

なので、このエントリでもあくまで「自分はこうしている」という判断の事例を述べるに留めます。あくまで個人の心情として、上記のような不安をぬぐいきれず、また、ソースを公開していた所で大多数の人はパッチなど送ってくれないものであるという実感もあり(これについては、既にGPL/LGPL/MPLで公開しているコードなのでそのせいでパッチが提供されないのだという推測も成り立ちますから、鶏と卵だと思っています)、どうせいつか自分でメンテナンスを再開することになるのだろうという諦観から、気分の問題としてコピーレフトの選択をする場合がある、という話です。

すべての人がすべての状況で同じ判断をしてくれ、とは思いません。僕ほどには泥をすすることを厭わない人もいるでしょうし、そんな先のことなんか考えたってしょうがないよという人もいると思います。「やり方」からお金を稼ぐのが全然嫌じゃないという人もいるでしょうし、ものすごくユニークな技術を持っていて、そこから莫大なお金を引き出せるから秘匿したいという人もいるでしょう(コカコーラとかペプシコーラとかが、レシピを特許化しないでいるのはそのためだと聞いた記憶があります)。僕だって、そういう状況になったら別の判断をするかもしれません。人それぞれ前提が異なりますから、みんなが自分の前提に合った選択をして欲しいし、惑わしてその意志を曲げさせるような事もあって欲しくない、と僕は思います。

サナギ - Nov 12, 2012

蝶とか蛾とかは幼虫→蛹→成虫と変態するんだけど、蛹の状態というのは一部の器官を除いてあの袋の中で体がドロドロに溶けてて、成虫の形にちょっとずつ作り替えられてるんだそうだ。その間身動きなんか取れるわけがなく、変態が完了するまではほんとに何もできないんだと。自分は高校の理科で生物を選択しなかったからよく知らんかったけど、生物選択だとその辺詳しくやるんだろうか。僕は大人になってからグロ写真見て「うぇえ……」となりました。

プログラム書いてて思うんだけど、僕に好き勝手に作業をやらせると、リポジトリが蛹のようになってしまいがちだ。全体的な見通しが立たないままに作業を始めて、やがていろんなモジュールをぶっ壊してしまう。この時はまるで何にも動かない。そういう状態のままコードをさらに書いていって、次に動くようになった時にはあら不思議! 元のモジュール構成は影も形もありませんでした! でも動いてて当初の目的は達成されてる……みたいな。

こーいうのはよくないよなー。ほんとよくない。複数人でやってるプロジェクトでこういうことはしてはいけないと思ってるんだけど。でもやってしまってる。テストドリブンとか何処吹く風や。コミット履歴の中にこういうことになってる部分があると、その周辺はもはや履歴が履歴として役に立たない。

masterでやらずにトピックブランチ切ってやりましょうよって話かもしれないんだけど、それとてmasterが動く状態を保てるということを除けば、特に、履歴がグチャグチャになるとかの点ではあんまり変わらない気がするし。

「ワンライナーで頑張っちゃうとかの変態的なプログラミングは、コードがアンリーダブルになってしまうからやめときましょう」というのは多分一般的な認識だと思うんだけど、「蛹な状態を作ってしまうと上記のような感じで宜しくないので、昆虫的な意味での完全変態的なプログラミングもやめときましょう」なんて事も言えるのかなー、ということを考えていて、誰がうまいこと言えって言ったよと自分で自分に突っ込みつつもドヤ顔でこういうエントリを書いてしまうところが、まだまだ大人になりきれてないと思った次第です。

より良いコード - Feb 01, 2012

自分で自分の書くプログラムが(道具として使って目的を達成できるかどうかという評価ではなくて、プログラムコードそのもの綺麗さとかそういう意味で)良いかどうかっていうのは正直よくわかんない。もちろん「良いコードを書こう」と思って意識はしてはいるけど、他の人から見たら「全然駄目じゃん」って言われるんじゃないかって思ってる。ただ、それでも、過去(数年単位に限らず、下手したら数ヶ月単位で)の自分が書いたコードは確かに悪かったのだなということは、今なら分かる。

良くなってる点があるとしたら、一言で言うと、「独り善がりさが減った」って事なんじゃないかなーと思う。属人性が減って、普遍性が増したというか。

過去の僕は、今よりずっと多くの時間を趣味のコーディングに費やせていたし、作っていた物の規模も今より小さかった。だから、傍目にはスパゲッティコードにしか見えないようなコードであっても、その時の僕の頭の中にはプログラムの全体像が入っていて、問題があったらどこを直せば良いのか、新しい機能を付け加えるにはどこに手を入れればいいのか、把握できていたのだと思う。そういう状況では、モジュールの分割であるとか関数の分割であるとか変数・関数の命名であるとかに気を遣う必要性が薄いから、自分の頭の中にモヤモヤとあった物がそのまま形になったような、そういう物ができあがるんじゃないかと思う。

でも、作る物の規模がだんだん大きくなっていったり、抱え込む物の数が増えて関心があちこちに分散したりして、全てのプログラムの全体像を常時完全には把握しきれなくなってくると、だんだんボロが出始める。また、費やせる時間もだんだん減ってきて、力業でも補えなくなってくる。そうなってきて初めて、「良い設計」とか「良いコード」とかいうものが身に染みて分かってきた気がする。

それまでも一応知識として「どういう設計になってるのがいいのか」とかいう事は知っていたし、元々完璧主義者な所もあって、頭でっかちなりに「良い設計」とか「良いコード」とかいう事は考えてはいたと思うんだけれども、実感は伴ってなかったんじゃないだろうか。

最初は誰かの受け売りだった「1ヶ月後や1年後の自分が見ても分かるコードを書く」という方針は、そういう事があって、今自分の中に実感を持って染み着いている。初めてその言葉を聞いた時の僕にとっては、「1ヶ月後の自分」「1年後の自分」とは、「昨日も今日もその事に没頭し続けていて、そのように連続した開発が1ヶ月間、1年間と続いた先にいる自分」という意味にしか受け取れなかったと思う。だから「1ヶ月後の自分なんてもう完全に他人」なんて言われてもピンと来なかった。でも今はよくわかる。なんだかんだで時間を取れなかったりやる気を維持できなかったりして1ヶ月くらいプロジェクトから離れてしまうというのは、実によくある事なのだ。毎日毎日同じ好きな事ばかりやっていられるとは限らないのだ。そうして久しぶりに触れた時に愕然とするのだ。1ヶ月前の自分が何を考えていたのか、まるで思い出せないという事に。

ましてや本当に他人だったら、「思い出す」ための手がかりすら無い。他の人がやっているプロジェクトに共同開発者として参加したり、誰かからプロジェクトを引き継いだりした時に、独善的で属人的なコードがあるとどういう事になるか。複数人で1つの物を手がける時、将来的には誰かに引き継がなければならない物を作る時に、自分自身が何に気をつけなければいけないのか。

クラスやらモジュールやらが分けられているとか、名前空間がどうであるとか、関数が小さいとかコメントが豊富とか、そういう個別の「テクニック」が駆使されている「から」、「良いコード」である、という事ではない。毎日毎日「今の自分」のためにしかコードを書いていないような人間には欠けている、1ヶ月後の自分やあるいは全くの他人でもスムーズに開発を継続・継承できるような状態を保とう、自分という人間がいなくても勝手に生き残って生き続けてくれるようにしておこうという、美学とか哲学とか信念とか言われるようなもの、未来を見ている姿勢。少なくともそれがあるのが「良いコード」なのではないかと、僕は思ってる。

1ヶ月前に自分が書いたっきりのコードを読み返してみて、ちゃんと分かるかどうか。良いコードなのかどうかは、時間が証明してくれると思う。

カード配り問題 - Dec 16, 2009

10分プログラミング - hogehogeを見て、10分でコーディング|プログラミングに自信があるやつこい!!に挑戦してみました。

結果。コーディング(と検証)だけで6分くらいかかりました。しかもエレガントでもなんでもありません。

function Cards() {
}
Cards.prototype = {
  deal : function(aPlayers, aDeck)
  {
    var result = [];
    for (var i = 0; i < aPlayers; i++)
      result.push('');
    aDeck
      .split('')
      .slice(0, aDeck.length - (aDeck.length % aPlayers))
      .forEach(function(aCard, aIndex) {
        result[aIndex % aPlayers] += aCard;
      });
    return result;
  }
};

var c = new Cards();
alert(c.deal(4, "123123123"));

クラス名がどうとか書いてあったから馬鹿正直にそれに従ってしまったし。

追記。いかん、人数よりカード枚数が少ないときの考慮が足りてなかった。修正した。

DOM周りの根っこの所に変更が入ったみたい - Jun 10, 2009

The Burning Edge見てたら、こんなバグがFIXEDになっていた。

text/htmlなHTMLドキュメントをXMLとして扱うにあたって、HTML5の仕様に合わせる形になるという事のようだ。namespaceURInullから"http://www.w3.org/1999/xhtml"へ、localNameがすべて大文字からすべて小文字へ、それぞれ変わる、と。

以前の挙動は以前の挙動で古い仕様には合致していたはずなので、時代の移り変わりをしみじみと感じる。

初心 - Apr 10, 2009

ごろたんから、このサイトのアドオン関係のページに書いてあるプログラミングのド素人が下手の横好きで作ったもの。という部分にツッコミを受けてしまった。素人じゃねーじゃん!!と。

いつでも初心を忘れないPiroですヨロシク。

いや、確かあの文って大学1年とかそのくらいの時に書いたはずで、それまでプログラミングといったら中学の時のN88BASICのお遊びと、ページ左のメニューをどうにかして自動生成したいってことで訳わかんないまま書いてたJavaScriptくらいしか、経験がなかったんですよね。専門の教育を受けたわけでもないし、きちんとしたプロダクトを作った事もなかったし……「大阪電気通信大学」っていうとじゃあ理系か工学系なのかって思われそうだけど、僕のいたメディア学科は入試に数学が無くて、カリキュラムにもプログラミングをテーマにした物は入ってなかった、そういうとこですから。

でも確かに今となっては、プログラマなのかエンジニアなのかとにかくコードを書くことが仕事の一環になってはいるので、素人とは言えないでしょうね。ってか、言ってたらマズイ。ということで上記のフレーズは消しておくことにします。

でも自分の感覚では、相変わらず、素人に毛が生えた程度という認識でいるんですよね。この1年くらいで技術的に進歩したと言えそうな事といえば、せいぜい、自動テストを書くようになったくらいで……ごろたんの記事読むまでeasing関数って単語すらも知らなかったし。使える言語も、Mozilla語のJavaScript方言とRails語をカタコトくらいですよ(JavaScriptとRuby、と胸を張っては言いづらいレベルの知識の偏り方なので)。論文読むとか本を読むとかそういう学習意欲の高いプロフェッショナルな人達を見てると、なんかすごく見劣りする気がする。

いや、ひょっとしたらそういう事じゃないのかもしれない。もっと形式的なところにこだわってるのかもしれない。

なんかねえ……例えば、入社1年目で何かプロジェクトにアサインされて、リーダーの下で指示を受けてあれこれ学びながら作業をこなして、納品してリーダーから「よくやった、お疲れ!」とかねぎらいの言葉をもらう、みたいな感じの、社会人としておそらくは常識的な<ruby><rb>通過儀礼</rb><rp>(</rp><rt>イニシエーション</rt><rp>)</rp></ruby>を経てない状態で、自分は技術者ですみたいな認識を持つことに、自分で抵抗があるということなんじゃないかって思う。

xUnit、アサーション、契約プログラミング - Mar 11, 2009

今更だけど、「xUnitってなんやねん」というのがよく分からなくて須藤さんに訊いたら英語版WikipediaのxUnitの解説を見るといいと言われたので見てみたところ、日本語版のxUnitのページには無かったxUnit自体の解説がちゃんと含まれてたので、アカウント作って英語版の内容を翻訳して日本語版の方に追加してみた。

英語版によると、「フィクスチャ」と「テストスイート」と「setup→テスト本体→teardownという順番で実行すること」と「アサーション」といった点がxUnitの特徴であると。これらの特徴を備えたテストフレームワークを一般にxUnitと呼ぶと。そんな感じですか。つまりUxUもxUnit型のテストフレームワークの一種である(→UxUはxUnitである)というわけですね。知らんかった。(ぉぃ)

あと、なんでアサーションはアサーションなのか(検証=verifyじゃなくて表明=assertなのか)というのがずっと疑問だったんだけど、これは契約プログラミングという概念に由来する表現なのか。プログラミングなのに契約ってどういうことなんだ? 「規約」とかの誤訳なんじゃないのか? と混乱したけど、説明によると、サブルーチンの呼び出し元はサブルーチンに対して「契約」上のルールに則った値を渡す義務を負い、サブルーチン側は呼び出し元に対して「契約」上のルールに則った値を返す義務を負う、義務が果たされない=契約違反が生じたらその時点ですべての処理をストップする、という風にあったのでなるほど確かにこれは「契約」で正しいなと納得した。

ツリー型タブの自動テスト - Feb 12, 2009

書き始めた。

最近、恐怖症っていうか神経症っていうか……自動テストで検証されてない事が怖くて仕方ない。一通りテストを書き終えるまで、次をリリースするのが怖い。リリース工程をとても億劫に感じてしまって、どうにかしてそれを乗り越えてやっとリリースしたと思ったら、しょうもないregressionがあることに気がついて、またあの面倒なリリース工程をやらないといけないのかと思うと気が重くなって。

追記。とかなんとか言いながら結局テスト未完のままリリースしてしまった。

テストがあるからってバグがない訳ではない……XUL/Migemoもまだまだモロモロと障害が見つかってる。ただ、自動化のプロセスがほぼできあがってるので、新たに問題がおこるケースが見つかったら、それをテストケースに追加して、コードを修正して、全体のテストが完遂すること(=regressionが無いこと)を確認して、過去に自分が把握してた範囲についてはある程度の自信を持ってリリースできる。自動化ができてないと、その自信を持てない。直したと思った物がすぐ後ろから崩れてるかもしれないという恐怖に駆られる。

きれいなコード、クリアコード - Feb 10, 2009

「いかに技術者の心に刺さるか」 ライブドア、自社サービスのソースコード公開を強化 - ITmedia News

社長! お株を奪われているであります!

ちなみに弊社の「クリアコード」という社名は現社長が「あの人達はきれいなコードを書く人達だよね、と思って貰いたい(し、実際にそうでありたい)から」とかなんとかそんな感じの意図で提案されたものだそうです。「だそうです」って何で伝聞なんだよって感じですが、その辺の話は僕が派遣仕事で別のとこに半常駐してた間に動いてたので、気がついたらもう決まってた感が……

で、僕の書くコードがきれいかどうかについては、どうなんでしょうね。最近作り始めた物については多少マシにはなってると思うんですけど(特に自動テストを前提にして作り始めた物は)。専門の教育を受けた訳でもなくずっと自己流のままなので、イマイチ自信がないです。

しかし「きれいなコード」ってどういうものを言うんだろう。客観的な指標が欲しい。

Page 1/248: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき