久々に松江で見かけたおごちゃんを交えて、来年度応募への作戦会議。
片方はうちで以前開発した視覚障害者用インタフェースL-Voiceを完全ソフトウェア化しようという提案だったのだが (現在は音声合成にハードウェアを利用している)、サーベイの結果いつの間にか すでにGalatea Talkという オープンソースで立派な音声合成エンジンができていたので(これもIPA支援だ)、 こちらはボツ。L-Voiceの完全オープンソースソフトウェア化というのも、 それはそれで価値がある仕事ではあると思うが、今回の公募趣旨には沿わないと思う。 お金のつじつまが合えばぜひ開発したいものだ。
もう一つの方についてはそのまま進めることとする。 若干適用範囲が狭い気もするが、それを広くするための開発です、という言うことにしよう。
後は雑談。プログラマの世代間断絶とか、SEという呼称は要らないとか。
N-gram 方式の全文検索システムRastのソースコードがとうとう公開された。 ここ数ヶ月の後輩たちの成果を見てやってほしい。 ただ、まだ最終版からはほど遠いのでお手柔らかに。
OSCON 2005へのプロポーザルが採択された。 テーマは「Yield to the Block: The Power of Blocks in Ruby」とするつもり。 Rubyの特徴であるブロックの活用方法をいろいろと語る４５分のセッション。
さて、これで行く方法を算段しないといけなくなったな。 夏休み期間にアメリカ行くのにどのくらいかかるかな。
ごく当たり前のことが書いてある。 ただ、翻訳はあんまり良くないような。「？」と思ったら原文を参照。
Rubyではレシーバが省略された関数的形式で呼ばれたメソッドはselfのメソッドと見なされる。 ただし、privateと設定されたメソッドがエラーにならないという違いがある。
これはこれで便利なものだが、ちょっとだけ欠点があって、 単にユーティリティとして使いたい関数的メソッドで名前空間が消費されてしまう。 ただ単に手続きをまとめるためにだけ作ったメソッドでも、 重複するといけないのでサブクラスで同名の関数を使うことはできない(正確には可能だが、トラブルになる)。
そこで、関数形式で呼ばれたメソッド呼び出しでは、メソッド探索を当該クラスからはじめる、 というのはどうだろう。仕様はより複雑になるが、再定義されたメソッドを利用しないので、 サブクラスの都合によりメソッドの動作が変化してしまう事態や、 メソッド名が偶然衝突してしまう危険性を避けることができる。
当該クラスからのメソッド検索に必要な枠組みはすでにsuperの実現のために用意されているので、 実装もそんなに難しくないはずだ。
仕様が複雑になることと、関数的メソッドをオーバライドできないこと、がデメリットだが、 そんなに悪い取り引きではないと思う。
1.9で実装してみようかなあ。
RubyをPHPやJavaと比較するという話。
「Ruby is too easy to be used as a first language」という観点は面白い。 つまり、最初Rubyでプログラミングを学んでしまった人は、 それがあまりに楽で簡潔なので、 他の言語に移行する時の学習曲線が急勾配になりすぎるということ。
そういわれれば、そういうこともあるかもしれない。 私だってRubyでプログラミングを学んだわけじゃないものなあ。
しかし、同じ論理はより強力に「なでしこ」や「ドリトル」にもあてはまりそうな気がする(HSPにも？)。 これらの言語で学んでしまった人は他の言語に移行するのが大変になるかもしれない。 ずっとその言語で閉じていればいいけど、いざ他の言語が必要になったら...。
いや、人間の柔軟性はそれくらいなんなく克服するのだろう....と、信じたい。
先日の、「松江駅前にIT拠点」という話に絡んで、松江市長がうちの会社を訪問して下さる。
オープンソースについては事前のレクチャーがあったようだが、 それがどうビジネスにつながるのかまでは理解できてなかったようだが、 今回の説明である程度納得していただいたようだ。
本当に松江がオープンソースのメッカとなれるかどうか、 期待したいところだ。まるで他人事のような書き方だが、 実際は私もいろいろしなくちゃいかんのだろうな。
なにしようか。
今回はGTD、 というよりも、その前段、ToDoやスケジュールの管理をどうしているか、という話。 howmとか紹介しているが、メインはいまだにvisor edgeというのは、 意外に思われるかもしれない。
Lispを解説するBruce Tate。
登場からの年数を見れば Lisp は古く、その構文も古めかしいものです。しかし、少し掘り下げてみると、Lisp が高度の抽象化を備えた信じられないほど強力な言語であり、その誕生時の 50 年前と同じくらい有効で生産的なことがわかります。Lisp よりも新しい多くの言語が Lisp の概念を借用しており、それらの多くは、まだ Lisp に匹敵できるほどの能力を提供できていません。Java や .NET の何分の一かのマーケティングが Lisp に関して行われ、多くの大学でも MIT と同じように積極的に教えられていれば、私達全員は今でも Lisp を書いているかもしれないのです。
同感だ。
XRuby (Javaバイトコードへのコンパイラ) でロジックミスを直したら、 各種ベンチマークでRuby 1.8.5よりも速かったという話。
コンパイラだから当然だ、などとは言わない。 Rubyクラスの言語で性能を出すのはなかなか難しい。 そこに果敢に挑戦している人たちはすばらしい。
新見へ。
配車が思いのほかうまくいって車の台数が一台少なくて済んだ。
いろいろな話を聞けて勉強になった。 とくに自分のできてないところ、弱いところを他の人が どう取り組んでいるかという話が参考になった。
...ちゃんとやろう。