!kiyoka.blog.2006_10 RSSPLAIN

Related pages: !kiyoka.blog.list
2432555555555515555555555515555555515555555555555551555555555551555555555555155555555555155555555555555555555155555555555555555555555555555555555555555551555555555555555555515
2

kiyoka日記。NendoSekkaの開発や、最近思うことなど

4

最新10件!kiyoka.blog   過去記事一覧!kiyoka.blog.list

3

kiyoka.blog_header 

2

このブログを書いている人: 西山 清香(kiyoka) - twitter: @kiyokaEXT

5

5

 

5

 

5

kiyoka.2006_10_31[プログラミング] LingrにGaucheの部屋を作る

5

ブラウザ上で動くチャットサービスLingrEXTGaucheの部屋EXTを作りました。

5

Gauche関係の話題がどんどん蓄積されていっています。

5

ちょっと高度な話題も多いですが、世界のGaucheプログラマーとSchemerはここにあつまれーという感じになっていく予兆が感じられます。

5

興味のある方は一度立寄ってみてください。

5

追記:ちなみに、この部屋はInternet上に公開されており、Googleにもひっかかります。非公開にしたい情報は流したりしないよう御注意ください。

5

 

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_29[Sumibi] 肉リリース 0.7.2

5

0.7.2をリリースしました。(毎月29日なので肉リリースです)

5

今回のリリースでは、sumibi.elEXTの小さなバグ修正が中心です。

5

Yoichi NAKAYAMA氏からいただいたバグ修正パッチも含まれています。ありがとうございます。

5

Emacsユーザーの方々、一度お試し下さい。

5

 

5

 

5

COMMENTkiyoka

ツッコミのテストがてら自己ツッコミ。

jus関西で講演したせいか sumibi.elをどなたかに利用してもらっているみたいです。よかったよかった。

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_28[Sumibi] jus関西でしゃべります

5

明日、2006年10月29日(日)にjus関西にてSumibiをテーマにしゃべります。第128回jus関西UNIX研究会のお知らせEXT

5

これまでの開発の経緯等の話がメインとなります。

5

個人的には、私以外の講演も楽しみです。

5

 

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_25[本] テクノロジストの条件を読む

5

この本の主題は生産性を上げる為には、良い問題設定を行う必要がある。という事だと思います。

5

当たりまえの物を当たりまえの方法で作る時代は終わり、何を作るか、変えるか、組合せるかということを模索していく必要があります。

5

イノベーションを継続して発生させる方法を確立するしかありません。そうしないと、発展途上国に生産性の面で追いつかれます。

5

この本での生産性とは、狭義の生産性、つまり単に同じ物を作った場合の生産性の事を行っているわけではありません。

5

広義の生産性、つまり何を行い、何を行わないかという問題設定も含めての生産性です。

5

但し、どれが良い問題設定だったのかというのは、初期段階で予想することは難しく、ある程度試行錯誤を行った後でしか分かりません。

5

なので、たくさんの種を蒔いてその中から芽の出そうな物を取捨選択する必要があります。

5

このような活動が出来ていない企業はやがて、発展途上国の爆発的な成長の中で追いつかれてしまいます。世界はフラット化して行きます。

5

最近、私は本当に危機感を持っています。人事では無いなと感じています。

5

4478300720

5

 

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_22[Sumibi] 日経ソフトウェアにSumibi.orgが掲載される

5

Sumibi.orgが日経ソフトウェア2006年10月号EXTに掲載されました。

5

私は掲載されたことを知らなかったんですが、勤め先の人に教えてもらいました。

5

へぇー、掲載の時は本人には連絡は特に無いのですね。知りませんでした。

5

掲載されたページを写真に撮ってみました。

5

同じページに@nifty WebMail2.0βEXTとか、Google SpreadsheetsEXTとか大物が多いので恐縮です。本当にこれで良いのか? ^_^;

5
 2924424362_5101aece06_o
5

 

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_20[プログラミング] Wilikiのソースコードを読む

5

Gaucheで書かれたWikiエンジンWilikiEXTのソースコードをちょっと読んでみました。

5

すごいです。綺麗です。parameterizeEXTという関数があるということを初めて知りました。

5

やっぱり、我らがジェダイマスターShiroさんEXTのコードは読んどくべきですね。

5

May the lambda be with you ... always.

5

lambdaの力は本物ですね。

5

Gaucheのソースまでは行かなくてもよいので、WilikiEXTのコードは長くない読んでみましょう。

5

Sumibiにも色んなテクを取り込みたくなりました。

5

 

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_17[創作心理] 創作の秋

5

私には、創作の季節というのがあるようです。

5

毎年、10月から年末にかけて、作るべきものが一つの形を成してきます。

5

これが不思議なことに毎年この季節なのです。

5

食欲の秋とか読書の秋とかありますが、私の場合は創作の秋のようです。

5

思えば、Sumibi.orgEXTも R@eply.orgEXTも10月位から開発スタートしています。

5

次に作るソフトウェアのアイデアは有るんですが、まだ完全なイメージになってないので、もうちょっと寝かしてから取りかかります。

5

 

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_13[プログラミング] Rubyの生産性の高さはどこまで本当か? 

5

私も何度も生産性の議論を書いていますが、生産性の議論は本当に難しいと思います。

5

このエントリーEXTでも、やっぱり純粋に自由度と生産性と気持ちよさを考えると最後には、S式macroとMOPEXT最強論に吸いこまれていますね。

5

やっぱりJavaの発明者から言語界のブラックホールEXTといわれるだけあるLispです。

5

もし、括弧に対するアレルギーが無いのだったら、Lisp系言語は最高ですよ。

5

例えば、GaucheEXTを使えば、メタプログラミングは当然できますし、ブロック構文とソックリのイディオムを提供する関数も標準で沢山あります。

5

(with-input-from-file 'filename' ...)など。

5

細かい話は置いておくとして、もしLisp系言語のパワーそのままで、ソースコードの外観もPythonやRuby程度の普通っぽさを持っていたら、もうちょっと普及の方向に動くと思います。

5

誰か作りませんか?GaucheベースのRubyスキンとか。

5

Schemeハッカーは言語の拡張にいそしんで、普通のハッカーは、PythonとかRuby構文でプログラミングを行うという分業体制ができます。

5

これが将来ほとんどの言語が辿り着く姿なんじゃないかと予言します。外れると思いますが。

5

 

5

 

5

COMMENTshiro

それなんてDylan? ってことになりそうな気も…

5

COMMENTじょりちょこ

僕もMOP最強と思いますし、Dylanにも大いに期待していたのですが

....

個人的には、LispやSchemeを使っていると「楽しすぎる」感じがします。「あ、こう書いた方がもっとエレガントだな...」と盛り上がってしまって、いつまでもコードをいじっていたくなるというか...

Rubyを使っているときには、エレガントさにはあまりこだわりません。そこがOOPのいいところというか、デザインパターンのようなセオリーがプログラマーたちの共通の語彙になっているので、他人が読んで十分読みやすそうなレベルで「リファクタリング欲」が満足するのです。

Lisp系の場合、強力なマクロがあるせいもあって、パターンの繰り返しをどこまで減らせるかに夢中になってしまうのです。(僕だけですかね...)

5

COMMENTcut-sea

>「あ、こう書いた方がもっとエレガントだな...」と盛り上がってしまって、いつまでもコードをいじっていたくなるというか...

同感です。

全てが再帰的にS式なので、リファクタリングの限界が無いと思ってます。

どこにでも埋め込めるし、どこでも切り出せちゃうし。

5

COMMENTkiyoka

コメントありがとうございます。

昔Dylanの記事をbitで読んだことがあります。

普及するのが楽しみで待っていたんですが、ついに普及することなく今日をむかえています。

最近は Open Dylanなんかがあるみたいですね。

でも、やっぱり普及するものを作ろうと思ったらPythonやRubyと互換性にあるスキンにすることに意味があると思います。

> 全てが再帰的にS式なので、リファクタリングの限界が無いと思ってます。

> どこにでも埋め込めるし、どこでも切り出せちゃうし。

それは特に私も感じるところです。

ある程度コードが長くなるたびに、どの部分でも関数やマクロにしてまとめながら(いわゆるリファクタリングしながら)どんどん具現化していけるのが気持ちいいです。

Schemeは自由度が高いから、どこまでもリファクタリングできて、綺麗に書けたと思ってもまだまだ綺麗に書く方法が見つかるという感じですね。

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_11[デザインポリシー] 富豪的プログラミング

5

最近はコンピューターのCPUとメモリ容量が大きくなったせいで昔とは違うプログラミングスタイルが主流になりつつあります。

5

それは、富豪的プログラミングと呼ばれるスタイルです。

5

経済的に富豪で無くても、コンピュータープログラミングの世界に限って言えば、誰もが富豪になれます。ケチケチせずに富豪になってしまいましょう。

5

 

5
 富豪的プログラミングEXT
5
 プログラマというものは、つい昔の癖で効率的なプログラムを工夫したり資源
5
 を節約したりしようとしがちですが、ユーザインタフェースのプログラムを開
5
 発するときにはこれが裏目に出ることもあります。
5
 というのも、ユーザインタフェースのプログラムでは機械の効率よりも使い勝
5
 手が優先されるべきですし、プロトタイプの作成とその評価/改良のサイクル
5
 を数多く繰り返す必要があるのですが、計算機資源を節約しようとするとこれ
5
 らの条件が後回しになりがちだからです。
5
 これを解決するのが富豪的プログラミングです。以下のような富豪的プログラ
5
 ミングを行なえばこのような問題は起こりません。
5
 
5
 1. メモリや実行効率を気にしないでお気楽にプログラムを作る
5
 効率を重視したプログラムは作るのが大変ですし、ちゃんと動かすにはデバッ
5
 グも大変です。富豪的プログラミングでは一番単純で短いアルゴリズムを使い
5
 ます。
5
 
5
 2. 条件が変わる度にすべての計算や表示を行なう
5
 再表示が必要な場所だけ書き直ししたり、出力のバッファリングをしたりする
5
 貧乏性な工夫はバグのもとになるので行なわず、条件が変わる度に計算を再実
5
 行したり全体を書き直したりします。
5
 
5
 富豪的プログラミングでは現在の状態を記憶しておく必要が少なくなるのでプ
5
 ログラムが短く、バグを含みにくくなります。また、ユーザが何か操作を行な
5
 う度にシステムがすぐに反応するので、直感的操作が可能になります。
5

 

5

Sumibi.orgEXTもかなり富豪的な計算をしています。本来ならば、難しいコーディングをすればリダクションできる計算も、シンプルになるという理由だけで二度以上計算している部分もあります。

5

そうすることで、数式をプログラムに展開せずにそのまま記述できています。

5

これで、小難しいバグを何個かは回避できているんではないかと思っています。

5

そして、その浮いた時間をもっとクリエイティブな部分に投資します。

5

これぞ富豪的プログラミングの醍醐味です。

5

 

5

COMMENTじょりちょこ

富豪的プログラミングをするとなると、「遅延評価」っていいですよね。僕自身はSchemerではなく、Rubyistなのですが、遅延評価は好んで使ってます。

5

COMMENTkiyoka

じょりちょこさん、コメントありがとうございます。

SumibiのエンジンはGaucheで書いているのですが、Gaucheにも「遅延評価」の屋台骨である「簡約」機能があったとしたら、今の数式中の重複した計算がまとめられて1回の計算になる可能性があります。(例えば、今の式をHaskellで書けば富豪的なコーディングをしても高速になるということですね。)

やっぱり、富豪的になることはいいことですよね。CPUが高速になる意外にもコンパイラの最適化技術も進化していっています。

ところで、Rubyでも遅延評価できるんですか。知りませんでした。

5

COMMENTじょりちょこ

自動的に遅延評価するための構文があるわけじゃないんですけどね。SmalltalkでいうところのLazy Initializationパターンをよく使います、という話ですね。(期待させてしまったらすみません。。。)

Schemeのdelayも、Haskellの遅延評価ほど、強力ではないですものね。

富豪的プログラミングでは、そもそもLazy Initializationのようなテクニックすら否定して「何度でも計算する」ということですけど、クロージャが使える言語であれば、計算結果をキャッシュする汎用的な仕組みを作ることは難しくないですよね。

5

COMMENTkiyoka

Lazy Initializationですか。

なるほど、これにもパターン名がついているんですね。知りませんでした。

> クロージャが使える言語であれば、計算結果をキャッシュする汎用的な仕組みを作ることは難しくないですよね。 

アスペクト思考というやつでしょうか。そういう仕組みをオブジェクト指向のフレームワーク側だけを変更することで組み込めるので、MOP最強論の話につながるのですよね。

1

comment (disabled)

5

5

 

5

 

5

kiyoka.2006_10_03[Sumibi] 『アフィリエイター』は間違いか?

5

日本人の外来語の間違い方のトレンドを見るのにSumibi.orgEXTを使うことができます。

5

例えば次の単語はどちらも間違いです。(でも、Sumibi.orgではどちらも変換可能です。)

5

誤:ピアニスター

5

誤:アフィリエイター

5

正解はそれぞれ、ピアニスト、アフィリエイトです。

5

ピアニスターのほうはさすがに間違えないと思いますが、『アフィリエイター』はよくある間違いです。

5

先日、WBSEXTというTV番組のキャスターの女性が『アフィリエイター』とはっきり言っているのを見てしまいました。

5

でも、ここでハタと立ちどまって考えて見たんですが、はっきり間違いと言い切れるんでしょうか。

5

もともと、他の多くの外来語にしても元の意味からかなり外れた言葉もありますよね。

5

最近は修正されましたが、『ナイター』等の様に同じように変な言葉もありますね。

5

どんな間違った言葉でも沢山の人に使われ、やがてある閾値を超えるとそれは正解となるのだと思います。

5

一言で言うと、『多数決』です。

5

ちなみに、Sumibi.orgはこのルールを実践している珍しい日本語入力システムです。

5

この外来語は間違いか正解か迷った時はSumibi.orgにきいてみては?

5

 

1

comment (disabled)

5