32nd Diary

もっと過去の日記
2016年
7月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

めーるあどれす:ruby -r base64 -e 'puts Base64.decode64("dGFrQG5vMzIudGs=")'





2016-06-27 (Monday) [長年日記] この日を編集

サーバ落ちてた

一週間くらい


2016-05-07 (Saturday) tDiary 5.0.0 [長年日記] この日を編集

テスト

独自のプラグインをモリモリ入れてしまっているため、まだ移行は完全ではない・・・

なんか、ツラいので作業のメモとか残した方がよさそうになってきた。

あー、よくわかんねぇ

 NoMethodError: undefined method `add_comment' for nil:NilClass
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/io/default.rb:44:in `block (2 levels) in restore_comment'
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/io/default.rb:35:in `each'
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/io/default.rb:35:in `block in restore_comment'
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/io/default.rb:25:in `open'
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/io/default.rb:25:in `restore_comment'
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/io/default.rb:184:in `transaction'
 /home/takano32/var/www/tdiary/vendor/bundle/gems/tdiary-5.0.0/lib/tdiary/view.rb:330:in `initialize'

2015-08-22 (Saturday) [長年日記] この日を編集

[FLOSS] えっ?FLOSS って過保護に英才教育するものなの?

ref. OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか?

はじめに

わたしは別に @tagomoris や @t_wada や @hsbt にケンカを売るつもりでこの文章を書いていないですし、まあ、そういう考えのヤツもいるんだなって思ってくれればそれでいい感じです。

ただ、ネット弁慶というか、思っていることの強さを伝えるためにちょっと語尾が感情的になっていたりする部分があるかもしれない。これから一気に一度で書くつもりなので、そういう語尾がなければないで、それはそれでってことでお願いします。

FLOSS って「ゆりかごから墓場まで。」っていうか、墓場はなくて不老不死なの?

文章をみていて感じたことは「良い設計にたどり着くには」というような流れになっているけれども、これって単に FLOSS を長生きさせるにはっていうような文章っぽくないかねぇって思った。あ。OSS はたぶん FLOSS なんだろうなって思って FLOSS って書いてます。

そりゃあ、成長していく過程で FLOSS のコミュニティとかをうまく育てていく、というのは重要なテーマだと思うけれども、それを行き過ぎてる印象を受けた。

「良い設計」ってひとつのソフトウェアでいつまでも追いかけられるの?

自分は「良い設計」っていうのはそのソフトウェアが開発された時代と、その時代に開発者に定着しているパラダイムに大きく左右されると考えている。

たとえば、メモリが不足していた時代には GC なんて バカげているものは誰が使うんだ?って感じで、malloc, free していたし、もっといえば mmap, brk していたし、さらに言えば自己書き換えでデータ構造とプログラムを共用体のようにして使い、複雑なソフトウェアを書くなんてこともされてた。でも、それはその時代の正義であり、よい設計だったわけです。いまや、 CG はないよりはあったほうがいい、あるいは必須ともいえるくらい開発者に定着している道具なわけです。

じゃあ、いまはなんで new したら delete もしないのが当たり前になってるし、その方が優れているソフトウェアが多い感じになってるかっつーと、「良い設計」というのが時代とともに、 GC を前提としたものになったかのはずですよね。

オブジェクト指向についても同じ。提唱された時期はメッセージの送信が行われたときに、ダックタイピングな動作しないといかんので、最下層のクラスにあるのか調べて、メッセージが受信できないなら親クラスには?さらにその親クラスにもメッセージの受信ができないなら、もっと親っていうように辿る必要があったんで、よくバカにされていたわけです。遅くて使い物にならないってね。

ところがどうですかね。いまはオブジェクト指向は「良い設計」なソフトウェアでは必ずといっていいほど組み込まれている機能ですよね。そして、現在は同様の流れが関数型のパラダイムでも起こりつつあるかなぁ、という気配を感じているところ。多くの開発者に関数型のパラダイムも定着したらオブジェクト指向と関数型をハイブリッドに使った「良い設計」が出てくるんじゃないのかなぁ。

死にそうな FLOSS には安楽死してもらうことも必要なんじゃないの?

上のような流れからすると、時代とともに良い設計なんてものはどんどん変わっていく。 それにひとつのソフトウェアの寿命で耐えきる、みたいな話ってセンスなくないです?

成熟しきっていて、煮詰まってるようなところまできたら、安楽死させてあげてよくないですかね。そして、若いソフトウェアを育てていくことにリソースを振り分けていく。その方が生産的なんじゃないかなって私は思いますね。

安楽死させてもよかろうという FLOSS の基準は?

@t_wada の文章中にでてくる「UNIXという考え方」にまさにコミュニティについての成熟レベルについて書いてあったような気がして、それがすげぇこの文章について自分が違和感をもっている根本理由なのかなって思いました。

死につつある FLOSS っていうのは「なんかこのソフトウェアに関係すると自分の名前が売れるぞ」みたいなヤツかつ、それに実力がともなってないのが寄ってきたら、プロジェクトは死んだようなもんだ、みたいな話が載ってるはずです。探すの面倒なんで、引用とかどこの何頁とは書かないけど。

FLOSS を安楽死させることを怖がらないようになろう

もちろん、育てる時期はある。でも、そこまで延命してほんとうに世界は幸せになるのだろうか。自分はそう思いました。

おしまい。