ブログアーカイブ
すべての記事
-
Daybreakというpure rubyのkey-value-storeを試してみた
目的 Sekkaの辞書データベースとして、プラットフォームに依存しない形式は無いものかと探している。 Sekkaの辞書データは結構大きいので、Sekkaインストール時にInternetから取得する方式にしているのだけど、プラットフォーム依存だとどうしても導入時に変換が入ってしまう。 その変換時間がバカにならない。 できれば、ダウンロードして即動かしたい。 現在Sekka辞書 1.6.1でサポートしているフォーマットはgdbm/TokyoCabinet/Redisで、どれもtsvからの読み込みが発生してしまう。
-
SKKユーザーを満足させるのは難しい
前回の記事で、[Sekka]をレベルアップできないかという話題を書いた。 SKKライクなIMEの特徴である、シフトキーを頻繁に押さないといけないという問題をなんとか改善できないか… ローマ字先頭の大文字を指定しなくても快適に使えるようにならないかということを軽々しく書いた。
-
SKKライクな日本語入力システムでシフトキーを押す回数を減らしたい
[Sekka]を話題にするのがあまりに久しぶりなのだが、思い立ってSekkaをさらに改善できないか検討している。 今度は、大文字始まりのローマ字を入力しなくても単語が漢字かひらがなかカタカナかを勝手に推測してくれるというもの。 本来、SKKライクなIMEを使っている人は、ひと手間掛けてもよいから思考を乱されるような誤変換を減らしたいという心理で使っている。 なので、わざとひらがなで「ひらがな」と入力したいところを第一候補に「平仮名」という漢字が出てくるといやがられる。
-
LLVMが楽しい
-
sekka.elからpure emacsでhttp通信しようするも断念
Emacsも年々進化していることだし、もうそろそろcurlコマンドを使わなくてもEmacsだけでHTTP通信できるのでは?と思ってチャレンジしてみた。 今回はあきらめたのだが、理由を忘れそうなのでここにメモしておく。 gibthubのSekka作業ブランチは “http_pure_elisp” 。 https://github.com/kiyoka/sekka/tree/http_pure_elisp
-
PasteHub.netは「コピペをいろんなWebサービスのハブにする」
PasteHub.netの大改造中。
-
新PasteHub.netは何を優先するか
自分用メモ。 インストールが簡単(設定なし) – Mac/Windowsはインストーラーにてインストールするだけ。 – Linuxはrpm/debをインストールするだけ。 – Emacsはmelpaからelispをインストールするだけ。 ※ 但し、Dropbox以外のストレージサービスを使っている場合は、設定値変更が必要。
-
大きなピボット
PasteHub.netというコピーペーストを複数のマシンで共有するサービスを作った。 しかし、ここへきてPasteHub.netの「コレジャナイ感」が大きくなってきた。 自分が欲しいのは、複数のOS、複数のマシンでコピーペーストが同期されるシステムだ。 PasteHub.netではそれだけのために、次のような手順を踏む必要があった。 サイトを用意 ユーザーアカウントを登録 アプリケーションをインストール
-
CRuby 2.1.0の非互換性-Symbolクラスにモンキーパッチできなくなった件
忘れないうちに[Nendo]をCRuby 2.1.0で動かすのに苦労した話を書いておこう。 多分、SymbolにモンキーパッチしているプログラムはCRuby 2.1.0で動かなくなるので、その時に誰かの役に立つかもしれない。
-
Sekka 1.5.0 リリース
SKKライクな日本語入力メソッド [Sekka] 1.5.0をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
静的型チェックの設計メモ(1)
自分用備忘録。
-
演習問題をやってみた
型システム入門(TaPL) Amazonで見る TaPL読書会に向けて11章の演習問題をやってみた。 [TaPL_exercise] TaPLの演習問題をまじめにやるのは結構大変だ。
-
Lisperの楽園: 脳内モデルに一番近い島
タイトルが、リゾートのパンフレットみたいになっているのは御愛嬌。
-
処理系開発の効用
このエントリは二年前くらいに書いたものなのでちょっと古いのだが、もったいないので公開。
-
副作用の無いコードの静的解析について(2)
前回の続き。( 前回の記事は、右上の窓から同じタイトルで検索してね )
-
副作用の無いコードの静的解析について(1)
だいぶ前に、[Nendo]に型検査を入れて副作用の無いコードを静的解析で保証したいという話題を書いた。 ( 2011-10-07Nendo*Ruby コードブロックに副作用が混在するかを検出できるかどうか ) あれから時間が経ったけど、諦めずに考えているのであった。もう2年も経ったのか…
-
Sekka 1.4.0 リリース
SKKライクな日本語入力メソッド [Sekka] 1.4.0をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
後方一致辞書の実験
[Sekka]を2008年に作ってからずっと使っているのだけど、ほぼ毎日使っていると不満が出てくるものだ。 最近、重い腰を上げて挑戦したのが、単語の前方からだけでなく、後方からも曖昧辞書検索するという実験だ。 結果は良好で、さらにミスタイプを救ってくれるようになった。
-
TAPL 型システム入門
型システム入門 -プログラミング言語と型の理論- 著者: Benjamin C. Pierce Amazonで見る
-
平仮名フレーズ辞書の入れかえ成功
Wikipedia日本語版のテキストデータを使って平仮名フレーズを作った。 これまで使っていた日本語ウェブコーパス 2010は廃止した。
-
平仮名フレーズ辞書を入れかえたい
日々使っているとSekkaの平仮名フレーズ辞書に不満が出てくる。 あまりに、口語体の表現が多く含まれているので、固めの文章を書いているときにも、口語体の表現が出て、うっかり確定してしまう。 それを直すのがめんどくさい。 なんとかならんのか…というのが発端。 たとえば、「…かもな」 みたいなフレーズがひょっこり出てきたりする。
-
BOOKSCAN(ブックスキャン)で本をスキャンしてもらった
BOOKSCAN(ブックスキャン)で本をスキャンしてもらった。 スキャンが完了した本はこんな感じで本棚に半年置いてくれる。 1ヶ月約1万円で50冊までスキャンしてくれるプレミアム会員になった。1ヶ月だけだけど。 それにしてもマニアックな本ばっかりあるなぁ。 ここには約30冊ある。OCRオプションを付けているが、どれくらいのサイズになるかが気になる。 これからサイズを計算してみる予定。 KindleのPersonal Documentスペースには何冊入る計算なのかがポイントだな。
-
リリースラッシュ
世の中はいろんなWindows8やらApple製品やらの新製品発表で溢れかえっている。 そんな中、自分に関係した もしくは 興味のある製品のほうもリリースされまくっている。
-
static linkしたアプリケーション配布の時代は終わったのだろうか
LinuxにはたくさんのDistributionがある。 昔は配布するビルド済みバイナリを1種類にしたい場合はglibcをstatic linkしたバイナリを配布するのが一般的だったように思う。 2005年くらいのMySQLはstaticバイナリを配布していて、rpm以外のディストリビューションの場合はそれを選べた。(Debianとか) 最近ではMySQLはrpmパッケージしか配布していない。
-
日本語IMEを作る責任について
身の振り方を考えるついでに、日本語について考えた - アスペ日記 この方のエントリを読んでいると、安易にIMEを作っている自分を振り返ってしまう。 自分はそこまで深く考えてIME作ってないよ。 自分も[Sekka]というIME(日本語入力システム)を作っているけど、日本語(というか漢字)は得意では無いし、日本語を大事にするほうでもない。 それでもIMEを作っているのは、自分の思い通りに入力できるものを作れないかという想いから作っている。自分だから自分の満足するものを作れると。 だがしかし、視点を外に向けてIMEありきの世界で今後日本語がどのように書かれるかまでは考えたことは無かったなぁ。 この方のように日本語にこだわる人は、自分で全てを掌握できるSKKや[Sekka]を使えば良いのだろうけど、そこで止まっていないところが凄いというか尊敬するというか救いがたい。 いろんな意味で、今後どのような記事が書かれるのか気になる存在となってしまった。
-
Sekka 1.2.0 リリース
SKKライクな日本語入力メソッド [Sekka] 1.2.0をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Kyoto.Lisp Hackathon で作ったけどボツになったコード
Kyoto.lisp Hackathon #1 に参加してきた。 話としては(2012-08-11Nendo*Lisp Kyoto.Lisp Hackathon でやったことのまとめ) の続き。
-
Kyoto.Lisp Hackathon でやったことのまとめ
Kyoto.lisp Hackathon #1 に参加してきた。 KyotoでLisperが10人以上集ったのだけど、他の大きなイベントとぶつかっていたわりにはよく集ったのかも。
-
タイムゾーンをUTCで運用するノウハウ
Dropboxの運用で、細かいけれど役に立つノウハウが書かれていたのでメモ。 DropboxはDBから何から内部のタイムスタンプはUTCを使っているらしい。
-
Sekka 1.1.3.pre リリース
SKKライクな日本語入力メソッド [Sekka] 1.1.3.preをリリースしました。(リリースノート [Sekka.ReleaseNote])
-
コンプガチャ問題で気付いたこと
今、世間ではコンプリート・ガチャの問題がホットだ。 悪い側面ばかりが強調されているが、一歩引いてみると興味深いことに気がついた。
-
MacOS X Lion上のsvnで濁点付きのファイル名を扱えるようにする方法
自分は本ブログ(というかWiki)をSubversionで編集しており、濁点付きのファイル名も扱う MacOS X をLionに上げた時に、折角パッチを当てていたsvnを消されてしまった。 だが、すぐに次の情報が見つかった。 Mac用SubversionクライアントsvnXで濁点付きのファイルを扱えるようにする - backyard of 伊勢的新常識
-
Sekka 1.1.1.pre リリース
SKKライクな日本語入力メソッド [Sekka] 1.1.1.preをリリースしました。(リリースノート [Sekka.ReleaseNote])
-
「幸福」になる方法を教えてくれるTEDのプレゼン
ゴールデンウィークに見たTEDのプレゼンの中で気に入ったものを自分用にメモしておこう。 いつかもう一度見たくなるはず。 人間はどのような時に「幸福」を感じるかを研究している人達がわかりやすく教えてくれている。
-
失敗事例: Microインスタンスのスラッシング状態で 1日 $10課金された件
先日、Sekkaの辞書を作るためにAWSのEC2サービスを利用した。 Sekkaの辞書を作る処理は半年に1回程度しか必要にならないのだが、手元のMacBookで実行すると24時間位はかかるような重い処理だ。(CPUとメモリの両方を大量に使う) 手元のMacBook Proは電源を入れっぱなしにしたくないので、できればどこかのサーバー上で処理したかった。
-
自分にしみついたオープンソース的な感覚について
私は趣味のプログラミングを全部オープンソースにしているが、仮にそうでなかった場合どうだっただろうと考えた。 考えるきかっけになったのはこの記事のこのくだり。 透明性への耐性を備えた組織を設計する - Joi Ito’s Web - JP まるで、ソフトウェアが書かれた後に「オープンソース化する」ことになった プロジェクトのようなものだ。コードがごちゃごちゃで、ほとんど不可能とい う場合が多い。ソフトウェアをオープンにする場合には、外の人間にも理解で き、恥ずかしくないような書きかたをするのが普通だ。例えば変数に卑猥なこ とばを使ったり、コード内のコメントのところで恋愛関係の不満をぶちまけた りする開発者も何人か知っている。彼らはコードが突然オープンになったら、 職や伴侶を失うことになりかねない。
-
DynamoDBのスループットを減らす場合に制約がある理由について考えてみた
Amazon DynamoDBのスループットを減らす時は、以下の画面キャプチャように1日1回しかできないようになっている。 その理由を考えてみた。ほとんど推測なので、間違っているかもしれない。目くじら立てないで欲しい。 これはもしかして、これはアザトい仕様なのかもしれない… とか少し思った。
-
Sekka 1.1.0.pre リリース
SKKライクな日本語入力メソッド [Sekka] 1.1.0.preをリリースしました。(リリースノート [Sekka.ReleaseNote])
-
昭和16年夏の敗戦
よくぞここまで取材したなぁという感想を持った。 昭和16年夏の敗戦 著者: 猪瀬 直樹 Amazonで見る なんというか、第二次世界大戦当時とは違うと思いたいけれど、この本を読む限り、今の日本もあまり変化してないと考えさせられる。 空気という見えない力が働いて、誰も大きな流れを止めることはできない現実。
-
distributed-trie 0.8.0 リリース
distributed-trie 0.8.0 をリリースしました。 ファーストリリース。 とりあえず[Sekka]に組み込んでライブラリAPIとして使えるということが検証済みなのでリリースした。 コードの高速化はまだやってない。ソースコードはもうすこしリファクタリングが必要かも。 また、trieキーの削除には対応していないなど、まだまだ改善しないといけないこと多いが…
-
Sekka辞書にdistributed-trieを利用する際の最適値を見付けた
Sekka辞書にdistributed-trieを利用する際の最適値を見付けた。
-
distributed-trieを使って曖昧文字列検索実装してみた感想
曖昧文字列マッチングのindexをtrieにしたのだが、前よりもモッサリした感じになった。
-
「ビッグデータを征す クラウドの技術 Hadoop&NoSQL」を読んだ
NoSQL(分散KVS)関連の仕組みがよくまとまっている。いいぞこれ。 ビッグデータを征す クラウドの技術 Hadoop&NoSQL 著者: ASCII.technologies Amazonで見る NoSQLの部分はHBaseとCassandoraが中心に解説してあるのだけど、原理から教えてくれるので、他の分散KVSがどういうものか検討が付くようになる。 CAP定理についてここまで平易に書かれているものは無いような気がする。 おかげで、Amazon DynamoDBがどういう位置付けでどういう用途に向いているかも間接的にわかった。 もし、自分のように運用まで手がまわらなくて、でもHbaseやCassandoraのような本格的な分散KVSを使いたい場合はDynamoDBに頼るのが良いのだろうと思った。 今後NoSQLをウォッチしていきたい人は一度読んでおくことをお薦めする。
-
Amazon DynamoDBが思ったほど低レイテンシではなかった件
DynamoDBを使ってみた。 これまで、私はTokyo Cabinet、memcacehd、 Redisといった、わりと単純なデータモデルのKey-Value Storeを使ってきた。 そんな私が、DynamoDBを使ってだいぶ違うということを感じたので記事にしたい。 それはRemote APIのレイテンシが小さいか大きいかで全く適用範囲が違う別モノだということだ。
-
Sekka 1.0.0 リリース
SKKライクな日本語入力メソッド [Sekka] 1.0.0をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Ruby 2.0(開発版)に入ったEnumerable::Lazyを試してみた(Nendo編)
「2012-04-01Ruby*Nendo Ruby 2.0(開発版)に入ったEnumerable::Lazyを試してみた」の続き。 Ruby 2.0をビルドする手順は先日の記事を参照してほしい。 今日は、Nendoでも試してみた。 もうひとつLazyな写真
-
MySQL CluterがRDBMSのASIC特性を保持しつつスケールアウトできるのはなぜか
タイトルは釣りです… 誰か教理由を教えてください。 そんなことがあるわけないので、何かミスリードがあるに違いない。 MySQL :: MySQL Cluster: スケーラビリティ MySQL Clusterの自動シャーディング 他の分散型データベースとは異なり、シャード間でクエリーおよびトランザ クションを実行する際にJOIN処理を実行する機能を損なうことはなく、 ACIDを犠牲にすることもありません。
-
Sekkaのブランチを1.0と1.1にわける予定
二つの系列に分けることを考えている。 1.0は安定版としてメンテナンスモードへ(0.9系列をそのまま1.0へ) 1.1は開発版としてアグレッシブな変更を入れるモードへ
-
SHOT NOTEはじめました
手書きメモをスッキリデジタル化「ショットノート」 | KINGJIM もう、マウスで図を描くのがいやになった。ちょっとした図を描く時は時間をかけたくない。 というわけで、究極のUIである紙とペンを使うことにした。 写真はLサイズで、MacBook Proの13インチと比べてもそんなに大きくないので、机を占有しない。 実際に描いてみると、Mサイズでも十分図が描けそうな感じがした。 キングジム ショットノ-ト Lサイズ 白 Amazonで見る
-
Ruby 2.0(開発版)に入ったEnumerable::Lazyを試してみた
ゆくゆくは Ruby 2.0に入るようだ。 今回、Ruby 2.0の開発版を実際に動かしてみた。 Ruby 2.0 Enumerable::Lazy | Railsware blog (うちの猫がLazyな時の写真)
-
Sekkaにトライ木を実装するとしたら ver-2
先日の記事 「2012-03-07SekkaKVSTRIE* Sekkaにトライ木を実装するとしたら ver-1」からの差分。 GitHub上で実際にdistributed-trieという名前でライブラリを実装してみた。 現在は鋭意パフォーマンス計測中。
-
Sekkaにトライ木を実装するとしたら ver-1
先日の記事 「2012-02-25SekkaKVSTRIE* Sekkaにトライ木の実装が必要な理由」の続き。 [Sekka]の曖昧文字列マッチングはかなり手抜きな実装になっている。 そこをトライ木で改善できるのではないかという話。 ※ 本記事はKey-Value Store型データベースにトライ木を構築する方法を書いています。ポピュラーなtrieライブラリであるDouble ArrayやLOUDSなどのデータ構造の話では無いので、それを期待されて来られた方はすみません… そのあたりの話は全部次の本に書いてあります。私は買いました。ステマではありませんよ。 日本語入力を支える技術。変わり続けるコンピュータと言葉の世界 著者: 徳永 拓之 Amazonで見る
-
読んだ本など
ちょっとミーハーなやつも混ざっているけど…
-
Sekka 0.9.7 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.7をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
fuzzy-string-match 0.9.3 リリース
二つの文字列同士を曖昧比較するライブラリ fuzzy-string-match をリリースしました。
-
Sekkaにトライ木の実装が必要な理由
[Sekka]の曖昧文字列マッチングはかなり手抜きな実装になっているので直したい。 トライ木を実装すべき時かもと思いはじめてきた。
-
Nendo 0.6.4 リリース
[Nendo] 0.6.4をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの概要 COPYINGとREADMEをgemに追加しました。 [Sekka]のテストスイート内で#?=によるデバッグ出力を抑制したかったので debug.null を追加しました。
-
nativeとpureの両方に対応したgemを作る方法
[Sekka]の曖昧文字列マッチングを担っているkiyoka/fuzzy-string-matchというgemのpure ruby版を作った話を書く。 JSONのgemがnativeとpureの両方をサポートしていたので参考したのだが、結果的にJSONよりもコンパクトに実現できたのでメモしておこう。
-
Nendo 0.6.3 リリース
[Nendo] 0.6.3をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの概要 nendoのライブラリ(*.nnd *.nndc)のインストール先パスを一段深くし、nendoディレクトリ配下に置くようにしました。 Debianパッケージ化しようとして、0.6.2では、 /usr/lib/ruby/vendor_ruby/init.nnd にインストールされてしまうことから、インストール先が間違っていることに気がつきました。
-
fuzzy-string-match 0.9.2 リリース
二つの文字列同士を曖昧比較するライブラリ fuzzy-string-match をリリースしました。
-
Nendo 0.6.2 リリース
[Nendo] 0.6.2をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの概要 gem単体でテストが走る rubygems-test への対応が中心です。 これまで、Nendoはgitリポジトリ上でしたテストが走りませんでした。 これからは、 $ gem install rubygems-test $ gem test nendo でテストが走ります。 参考: Gem Testers
-
gemsのDebian化ツールについて
[Nendo]のgemのDebian化を簡単にできるツールからスタートしようとして、Google検索しているとこんな記事が出きて、Debian上の行く末が心配になったりした。 多分杞憂に終わりそうだけど… Rails Hub情報局: DebianのRubyパッケージメンテナ辞任で騒動に
-
そろそろ]のDebian化にとりかかろう
去年の11月くらいから自宅サーバが全壊したり、さくらのクラウドに[Sumibi.org]環境を復元したりしているうちに、もう3ヶ月も経ってしまった。 そろそろ、落ちついたし懸案だった[Nendo]をDebian化しよう。
-
ZFSを先延ばしにしていたら、いつのまにか不要になっていた件
ZFSの開発の歴史や、Software Designの記事などを読んで ZFSを使いたいなぁと常々思っていた。 今は読めない(デッドリンク)。残念。Oracleが隠しちゃった? Solaris 10ファイルシステムZFS誕生エピソード『心を解き放て!』
-
Kahuaのメモリリークの調査と対策
[Sumibi.org]を「さくらのクラウド」に引越した後もKahuaのメモリリーク問題が解決していなかった。 急遽RAM容量の大きなサーバインスタンスに変更して運用回避していたが、このまま無意味なコストの垂れ流しを止めるべく調査した。 やっと解決したので調査結果を書いておこうと思う。 このまま放置するとコスト削減額はなんと月額4000円にもなるので、ちょいと見過ごすわけにはいかないのである。
-
]を公開サービスにするという思考実験(サービスの裏側)
先日の、「 2012-01-04Sekka* [Sekka]を公開サービスにするという思考実験(サービスイメージ)」というエントリの続き。 今回はsekka-serverをホスティングする側のアーキテクチャをどうするかを書いてみたいと思う。
-
]を公開サービスにするという思考実験(サービスイメージ)
ソフトウェアを試してみようと思った時、インストールの容易さが最初に心理的障壁になる。 特にインストールがそうとう難しい場合は心理的障壁は上がる。 sekka-serverはRuby 1.9.xとTokyo Cabinetがインストールされていればわりとインストールは簡単にした積もりだけど、まだまだ苦労する人もいる。 Debian化という話もあって、それも良いことではあるが(@uwabamiさんすみません、ちょっと停滞しています… 気長に待っていてください)
-
MongoDB: The Definitive Guide 読了
MongoDB 著者: The Definitive Guide: Kristina Chodorow, Michael Dirolf Amazonで見る やっと読み終わった。 過去のエントリを見ると11月ごろから読んでいたのがわかる。 2011-11-03本*MongoDB MongoDB: The Definitive Guide
-
「Amazon EC2」と「さくらのクラウド」の使いわけ
正月休みを利用して、Amazon EC2で遊んでみた。 去年の11月ごろ、自宅サーバーが故障する直前までMongoDBを試していたが、クラウド上に復旧するのに時間が空いてしまって今になってしまった。 「Amazon EC2」と「さくらのクラウド」の両方を使っているが、その使いわけがわかってきたのでエントリを書いておこう。 自分の同じような使いかたをしている人はいないかなとググッてみたが、自分ほどガチで使っている話題はなかったので、書いとく価値はあるかな…
-
2012年の抱負
去年も抱負を書いているようなので今年も書くとしよう。
-
Sekka 0.9.6 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.6をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Nendo 0.6.1 リリース
[Nendo] 0.6.1をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの概要 例外関連のフォームのバグ修正と、シンタックスチェックの不備を修正しました。
-
MongoDB試用開始
MongoDBをさわりはじめた。versionは現時点の最新の version 2.0.1 。 私が参照している本。 Amazonで見る メモリがいくらあっても足りない。4GByte RAMのサーバマシンで3.8GByteまで使っている。 もちろん他にもいろいろ走っているので、2GByteほどswapしている。
-
MongoDB: The Definitive Guide
この本いいよ。 第二版が出るらしいのだけど、待てないので第一版を買った。 当初WebブラウザでSafari Books Online上の電子書籍を読んでいたのだけど、疲れるので紙の書籍にした。電子書籍リーダー持ってないし。 MongoDB: The Definitive Guide 著者: Kristina Chodorow, Michael Dirolf Amazonで見る MongoDBを本格的に使おうと思ってこの本にした。本格的に使うなら、最初からこの本を読み通しておくべきだろうと。 MongoDBのコミッター(10genのエンジニア)も著者に入っているので、なぜこういう設計になっているのかというところも説明してくれている。 実際にサーバー側の内部を知っているものでないと、このような解説はできないだろう。 MongoDBサーバーの設計ポリシーや実装上のトレードオフを最初から理解しておくことは重要だと思う。結果、MongoDBの適用範囲を間違えなくて済む。 トレードオフがわからないままだと、「ここは設計上律速するはずなので、部分的にmemcaced使っとこか」というようなアプリケーションのトレードオフの判断ができない。
-
Nendo 0.6.0 リリース
[Nendo] 0.6.0をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの概要 nendo.rbをファイル分割しただけで、挙動は0.5.4から変化ありません。 ファイル分割しただけですが、ソースコード管理上は大きな変化であるということ、機能的に安定していることの二つの理由から、マイナーバージョン番号を0.6.0にを上げました。
-
Nendo 0.5.4 リリース
[Nendo] 0.5.4をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの目玉 例外をハンドリングできるようになりました。道具立てはguardとunwind-protectです。 GaucheとAPIをなるべく似せて、Gaucheに慣れた人が新しく覚えることを少なくしました。 ([Nendo.ReferenceManual] のguardのあたり参照) テストフレームワークの nendo.testもgauche.test同様のAPIにしています。 Gaucheは独自の例外オブジェクトを持っていますが、Nendoでは例外オブジェクトとしてRubyのそのものを使うことになっているので、Rubyのオブジェクトをそのまま指定できるようにしました。 RuntimeErrorやArgumentErrorやTimeout、Errno::ECONNREFUSEDなんかがそのまま書けます。
-
Sekka 0.9.5 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.5をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Youtubeを使った編集無しのマッシュアップ遊び
これすごい。 Impossible Youtube duet: Miles Davis improvising on LCD Soundsystem
-
楽譜をなぞるアニメーション付きJazzシリーズが楽しい
速いフレーズで知られるチャーリー・パーカーとかジョン・コルトレーンとかは自分が聴き慣れている分楽しめる。 やっぱりアニメーションで見てもフレーズが速いぞこの人たち。
-
コードブロックに副作用が混在するかを検出できるかどうか
先日のScalaの本からの流れで勝手に盛り上ってしまっている話題を前へ進めてみる。
-
Sekka 0.9.4 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.4をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Scaleの関数プログラミングのアプローチについて(3)
しつこくScalaについて調べる。使うのはこの本。 Programming in Scala 著者: Martin Odersky, Lex Spoon, Bill Venners Amazonで見る
-
Sekka 0.9.3 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.3をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Scaleの関数プログラミングのアプローチについて(2)
7つの言語 7つの世界 著者: Bruce A. Tate Amazonで見る Scalaの章を読了した。 しかしこの本だけでは、Scalaがどうやって破壊的操作を検出するか/あるいはしないのかについての全体像はわからなかった。 わかったのは、varとvalがあり、valが破壊的操作を許さない変数を定義するためのもので、静的に破壊的操作を禁止するものだ。 ものによっては静的には検出できないので、その場合はランタイムで破壊的操作のエラー(例外)が出るというレベル。かなり浅い。
-
Rubygems.orgから取得したgemでエラーが出るのはなぜか(追記)
昨日のエントリ「2011-09-29Ruby* Rubygems.orgから取得したgemでエラーが出るのはなぜか」の続き。
-
Rubygems.orgから取得したgemでエラーが出るのはなぜか
ずっと前から自分が作ったgemが環境によってエラーになる原因が解析できずにいた。 やっと、tenderloveことAaron Patterson氏が書かれたブログエントリでメカニズムが理解できた。
-
foursquareは何故MongoDBを選んだか
このビデオを観た。 The 10gen Blog on MongoDB and NoSQL, 10gen CEO on NoSQL; foursquare discusses why they use MongoDB foursquareのエンジニアの方のトーク。 何故、MongoDBを選んだか。 NoSQLなのでスケールするのは当然として、ほかのNoSQLテクノロジに比べて、 既存のSQLデータベースに近いので移行しやすいそうな。 次にWebアプリを作るとしたら、試すのはMongoDBだなと感じた。
-
Scaleの関数プログラミングのアプローチについて(1)
7つの言語 7つの世界 著者: Bruce A. Tate Amazonで見る この本のScalaの章を読み初めたばかりで、まだScalaについてはよく分かっていないのだけど、作者のインタビューが掲載されていて、Scalaはオブジェクト指向と関数プログラミングの橋渡し役になるという話が書いてあった。現代の二大プログラミングパラダイムを両取り。 自分として、一番興味があるのは、Scalaが破壊的操作が必須のオブジェクト指向と破壊的操作が非推奨の関数プログラミングのバランスをどう取っているのかというところ。 現在私が開発中の[Nendo]という言語では、破壊的操作をしようしている場所を、実行時ではなくコンパイル時に検出できないかと考えている。 Scalaがそのへんを解決したのかが知りたい。 仮に解決しているなら、どうやって解決しているのかを知りたいと思っている。 まさか、実行時に検出できるレベルで満足しているのだったら残念なんだけど。もう、その時点でScalaから貰うものは無いかなー。 Haskellの場合は、破壊的操作自体の無い純粋な世界を構築しており、プログラマがその世界の中でプログラミングしないといけないようにしてある。オブジェクト指向が付け入る隙は全く無い。プログラミングパラダイムは単一というわけだ。パラダイムというかパラダイス的な(笑)
-
Sekka 0.9.2 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.2をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Redisは仮想メモリ機能を使ってメモリを節約してくれる
Redisはメモリが溢れた時に仮想メモリを使用するようだ。 単純なIn Memoryデータベースだと思っていたので、用途が限られると思っていた。 データが全てメモリに載りきらない応用にも使えるんじゃないかなぁ。
-
Redisを試す
前から気になっていたRedisを試した。 (Redis 2.2.12) [Sekka]の辞書ストレージに使うと高速になりそうだという直感があった。 しばらく試した結果、非常に[Sekka]向きだということわかった。非常にレスポンスが良く、まさにスラスラという表現がしっくりくる。 64MByteのメモリを割り当てたTokyo Cabinetと比べてひっかかりが無い。
-
どれだけテストを書けばいいか(1)
いま自分のメインプロジェクトは二つあって、両方共TDDで開発している。([Nendo]、[Sekka]) もうTDDでない開発方法には戻れないと思っているが、効果を上げるには[Nendo]側のテストスイートの網羅率が足りない気がしている。 (科学的に分析したわけではないが… というか、そもそも科学的に分析できるものなのかもわからないけど) あきらかに[Nendo]のほうが複雑なソフトウェアだと思うので、より多くのテストコードが必要になるのだろう。 それぞれ、実際にテストコードがどれくらいあるのか気になったので調べてみた。
-
Sekka 0.9.1 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.1をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
平仮名フレーズを辞書として持つのは失敗?
平仮名フレーズ辞書を含めた、[Sekka] 0.9.0をリリースして少し経つが、平仮名フレーズを辞書に持つのは良いことなのかわからなくなってきた。
-
バグ原因調査: sekka-serverの起動時に辞書の読み込みに失敗する問題
@mori_devさんから[Sekka]のバグ報告があったので調査。 sekka の不具合(?)報告 — Gist => sekka-serverの起動時に辞書の読み込みに失敗する。
-
Sekka 0.9.0 リリース
SKKライクな日本語入力メソッド [Sekka] 0.9.0をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
RSpecのformatterのカスタマイズ
最近RSpecによるテストを Emacs の M-x compile で実行するようにした。 何がいいかというと、エラー行に飛べるようになる。 TDDによる開発を行う時は、先にテストケースを書いて、まだ製品コードが未実装の状態でテストがFailすることを確認してから製品コードを書き始める。 そんな中、あまりにもFailした行に飛ぶのが面倒臭くなったのでEmacsが使えないか模索してみた。
-
スペースキーによる変換確定を試す
[Sekka]のユーザ・インタフェースの欠点として、単語単位でCtrl-Jを押す必要があるところ。 アルファベットキーの合間にCtrl-Jを上手に入力するのは、なかなかの慣れがいる。 あまりにもCtrl-Jを押す回数が多すぎてしんどいので、これをなんとか改善できないかと思っていた。
-
例外の捕捉について
オレ処理系の[Nendo]についての開発メモ。
-
グダグダ変換
[Sekka]の次の機能として「なっています」等の、よく使う平仮名フレーズも辞書に持つことでミスタイプを救済しようとしているところ。 ミスタイプしまくりでグダグダになった場合でもなんとか救済して変換できてしまうことを称して、「グダグダ変換」と呼ぼうと思う。 たぶん「グダグダ変換」というキーワードは流行らないけれども、[Sekka]のキャッチコピーとしては、わかりやすいのではないかな?
-
いまやTravis-CIでビルドできるLispはClojureだけじゃないぜ
Travis CI - Distributed build platform for the Ruby community
-
Nendo 0.5.3 リリース
[Nendo] 0.5.3をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの目玉 高階関数の第二引数にEnumerable型を渡せるようになりました。(但し、map filter for-eachのみ) これにより、巨大なIOに対する逐次処理をfor-eachで書けるようになったり、list型だけでなくvector型に対して高階関数を適用できるようになります。 エラーが発生した時、正確な行番号がバックトレースに出るようになりました。 これまでは実行速度を優先して、バックトレース用の情報をあまり格納していませんでした。(未定義変数のエラー時は正確でした)
-
Travis CIを使ってみた
Travis CIはRubyのオープンソースプロジェクトの継続的インテグレーション(CI)を行うプラットフォーム。 Travis CI - Distributed build platform for the Ruby community An open-source, distributed build system for the Ruby community.
-
平仮名フレーズ辞書を追加してみようかな(4)
-
SQLiteをKVSのストレージに使う(アイデアのみ)
SQLiteのテストスイート項目数の多さは有名だ。項目数の多さが欠陥の少なさを示しているわけではないが相関はあるだろう。 こいつをKVSのストレージとして使えば、ソフトウェアのバグによるデータ破損が発生しにくいKVSが実現できるのではないかというアイデア。
-
アサハカな日英翻訳プログラムのアイデア
だいぶ前から考えているアサハカなアイデアがあるのだが、いくら考えてもあまり良いアイデアに昇華しない。 この狭い日本語圏には、きっと同じことを考えてはボツにしている人がもうひとりくらいは居るだろう。私のアイデアを晒しておこうと思う。 アイデアは「あるルールの範囲内で日本語文章を書けば正確な(読める)対訳英文が出力される」というシステム。というか翻訳ツール。
-
Sekka 0.8.8 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.8をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Nendo 0.5.2 リリース
[Nendo] 0.5.2をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの目玉 高速化しました。 固定長引数の関数呼び出しは、末尾再帰呼び出しのトランポリンを経由せずRubyのメソッドを直接呼び出す最適化を行った。 => ビルトイン関数の最適化のみに適用した。 => tak関数で約6.5倍、長さ10000のリストのmap filter for-eachがversion 0.5.1に比べて4倍の高速化となった。
-
コードゴルフならぬシステムゴルフ
ふと、自分のプログラミングに対する趣味・趣向について振り返ってみた。 今まで自分の作ってきた作品には、共通項があるんじゃないか。 その結果「なるべく短いコードでシステムを作ろうとしている」という共通項が見えてきた。 いうなれば、コードゴルフならぬ「システムゴルフ」。
-
平仮名フレーズ辞書を追加してみようかな(3)
先日来のエントリ 「2011-07-06Sekka* 平仮名フレーズ辞書を追加してみようかな(1)」 「2011-07-07Sekka* 平仮名フレーズ辞書を追加してみようかな(2)」 の続き。
-
平仮名フレーズ辞書を追加してみようかな(2)
昨日のエントリ「2011-07-06Sekka* 平仮名フレーズ辞書を追加してみようかな(1)」の続き。 平仮名フレーズ辞書の作りかただが、再度 矢田さんのウェブコーパスを調べてみた。 日本語ウェブコーパス 2010から引用 本コーパスの作成においては,様々なウェブサービス,ツール,コーパスを利 用させていただきました.開発者・研究者の皆様に感謝いたします. コーパスの作成・保存・配布には Amazon Web Services を利用しています. ウェブ検索には Yahoo! JAPAN 検索 Web API を利用しています. ウェブコーパスのシードには IPAdic を利用しています. 文字コードの変換には日本語用のパッチを適用した libiconv を利用しています. Unicode の正規化には ICU を利用しています....
-
平仮名フレーズ辞書を追加してみようかな(1)
現在の[Sekka] (version 0.8.7)は、漢字の語彙ならば、曖昧辞書検索を使ってミスタイプを補正してくれる。これがSKKに対するアドバンテージになっていると思う。 しかし平仮名のフレーズ、例えば「しました」とか「なっています」などのように平仮名のフレーズは辞書に無いのでミスタイプを救えない。 「なっています」のように少々長めのフレーズだとかなりミスタイプをしてしまう。まだ改善の余地がある。 natteimas (最後のuを入力せずに変換した例)
-
chibi-schemeのsyntax-rulesをポーティングする方法
オレ処理系の[Nendo]についての開発メモ。
-
頭の中にプログラムを入れる
Creative Commons|Attribution Photo by Mario Pleitez
-
Sekka 0.8.7 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.7をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
Nendo 0.5.1 リリース
[Nendo] 0.5.1をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの目玉 chibi-scheme 0.3のmatchライブラリをポーティングしました。 その過程で、let-syntaxとsyntax-rulesの大量のバグが取れました。
-
Coders at Work 読了
読んだ。楽しすぎ。 Coders at Work プログラミングの技をめぐる探求 著者: Peter Seibel Amazonで見る 一流プログラマのインタビュー集だ。 この本に登場するような一流は私達凡人とは違う世界に住んでいるようだ。業界がそもそも違うというのもある。破天荒。多様。アウトロー。 なんか自分の仕事を否定されているようで辛い。 SIerでマネージャやっている人は、特に自分の仕事がえらく否定されているように感じるかもしれない。 まあ、マネージャにはリーチしない本なので心配に値しないと思うが。
-
matchライブラリが動いた日
オレ処理系の[Nendo]についての開発メモ。
-
Paul Grahamとサンダル
shiroさんのブログ記事から。 Island Life - Paul Grahamとサンダル コメントで、Paulが靴下にサンダルを履いてるのを突っ込んでる人たちがいて ふと思い出した。
-
2歳児はフェイスブックのCEOマーク・ザッカーバーグをどう見ているか
フェイスブック 若き天才の野望 著者: デビッド・カークパトリック Amazonで見る
-
matchライブラリのデバッグ中
オレ処理系の[Nendo]についての開発メモ。 let-syntaxの実装がだいぶ進んだ。 現在はchibi-scheme 0.3のmatchライブラリであるmacth.scmを変更無しで動かそうとしている。 あと、もうすこしで動きそうなんだけどなー。
-
let-syntaxの実装方法の検討
オレ処理系の[Nendo]についての開発メモ。
-
Nendo 0.5.0 リリース
[Nendo] 0.5.0をリリースしました。(リリースノート: [Nendo.ReleaseNote]) リリースの目玉 健全なマクロ(hygenic macro)を追加したことです。 結果、次の3つをサポートできました。特にutil.listは普段のコーディングで自分でも無いと困るライブラリでした。
-
ゆっくり階段を登るがごとく
オレ処理系の[Nendo]についての開発メモ。 Gaucheのutil.listが動いた。 syntax-rulesも動くようになったし、他にもバグをいくつか修正したので一旦リリースするべきだろう。 実は、let-syntaxとletrec-syntaxのようなレキシカルスコープでのみ有効なsyntax定義が実装できていないので、片手落ちなんだけど、リリースした後に取りかかろう。
-
Sekka 0.8.6 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.6をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
「言語設計者たちが考えること」の再読
言語設計者たちが考えること 著者: Federico Biancuzzi, Shane Warden Amazonで見る PealのLarry Wallの章と、RubyのMatzの章を再度読んだ。 言語デザインの楽しさを再認識した。有意義でかつ楽しい。お金もかからず、知的好奇心を満たしてくれる最高の遊びだと思う。仕事では役に立たないけど… 私のようにSchemeのような仕様が既に決まっている言語の処理系を作るだけでも楽しいが、言語をデザインする作業も楽しいだろうなと想像する。 時々は、こういう本を読んで、単ならうScheme処理系の開発というレベルから一段引いて、言語デザインレベルから言語を考えることも必要だなと思う。 そのためには、Schemeの仕様に囚われずに、どんな機能が有用かを考える癖も付けていきたい。 Haskellとかも本格的に使い込んでHaskellの良い点を理解する時間を取る頃合いかなぁ。
-
syntax-rulesが動いた日
オレ処理系の[Nendo]についての開発メモ。 chibi-scheme 0.3のer-macro-transformerとsyntax-rulesをそのままNendoに移植を試みていたのだが、ついに成功した。
-
syntax-rulesの実装中。難航中。
オレ処理系の[Nendo]についての開発メモ。 chibi-scheme 0.3のer-macro-expanderとsyntax-rulesをそのままNendoに移植中。 今は、make-syntactic-closureをどう実装していいかわからないので、正解を探しているところ。
-
Sekka 0.8.5 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.5をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
R君語録
R君、2歳半になっていろんな言葉を覚えた。おもしろいのでその一部を紹介。
-
個人プロジェクトこそTDDでやるべき
個人プロジェクトは、プライベートな空き時間にちょっとづつ開発を進めていくというスタイルが大半だろう。 そういう場合こそ、TDDを積極的に使おう。
-
「10分でコーディング」をやってみた
10分でコーディング|プログラミングに自信があるやつこい!! 今日の問題はかなり簡単です。 できるだけ早い時間でエレガントなコードを書きましょう。 あまりに簡単なので制限時間を10分としてやってみてください。 これ以上かかった人は 自分はかなりプログラミングができない。 とつらい事実を認識しましょう。
-
Sekka 0.8.4 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.4をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
自分的に超重要な eshell 用設定
.emacsにこれを定義している。 個人的に最も多様するキーシーケンスだ。
-
Sekka 0.8.3 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.3をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
JRuby 1.6.0-RC1のバグの切りわけができない
久々にブログを書いてみました。 Nendoのテストスイートを走らせているのだが、JRuby 1.6.0-RC1のバグっぽい挙動に悩されている。 なぜか、次のように失敗する。( CRuby 1.9.2-p136では正常にパスする ) expectedとgotの文字列を見ても同じように見えるのだが。
-
Nendo 0.4.1 リリース
[Nendo] 0.4.1をリリースしました。(リリースノート: [Nendo.ReleaseNote]) 今回の目玉はjsonのライブラリを追加したことです。(rfc.json) [Sekka]で必要になったので追加しました。 そんなわけで、Nendoの開発は[Sekka]のニーズによってドライブされています。
-
Flareのリンク
仕事で使いそうなので、リンクだけ張っておく。 一度大量のデータをサーバーに入れてみて検証しなければ。 最低でも3台くらいのマシンが欲しいなあ。VMでもいいから用意できればいいんだけど。
-
まじめにSchemeのportをサポートする時間が無いので保留
NendoのjsonライブラリをGaucheのrfc.jsonライブラリと互換にしたかったのだが、時間が無いので保留にすることにした。 Nendoの他のライブラリと同じように、portの変わりにRubyのFileオブジェクトでお茶を濁すことにした。 優先すべきはSekkaからGoogle IME APIにアクセスして未知語を獲得する機能なので、今は寄り道はやめておこう。 毎日30分だけNendoに割り当てる方針で、本当に少しづつだけど前進している。
-
2011年の抱負
ブログを書くほどの気力が無かったのでちょっと遅いけど抱負を。 今年は普通に仕事をして普通に収入を得ることを目標にしよう。 あまり多くを望まないようにして、無理をしないことが重要かな。 2011年中はアクセルを50%くらい踏んだ感じでゆっくりいこう。 年始から手始めに、テレビを見ないようにした。それで睡眠時間がちょっとだけ増えたかな。 音楽を聴くことが自分の精神回復に効くことがわかってきたので、なるべく良い音楽に接するようにも心がけよう。
-
]を公開した
Google IME APIをRubyやPerlなどから使おうとしている方は、このプロキシをお使い下さい。 自宅サーバーではなくHerokuでホスティングしているので、サービスの安定性も高いでしょう。 このプロキシサービスを作った動機は次の過去記事をご参照下さい。 「 2010-12-05Sekka* ユーザー語彙登録UIについて考える(続き) 」 Google社が修正してくれるまでの繋ぎとしてお使いください。
-
IM飲み会2010に参加した
[Sekka]についてトークさせて頂きました。 スライドを今日、公開しました。 IM飲み会2010 Sekka開発秘話
-
Schemeのportをportingするには?
Schemeのportって何を抽象化しているんだろう。 RubyのFileオブジェクトをちょっとラップしただけでもできるもんなのだろうか。 もうそろそろ、portが無いとGaucheのライブラリのAPIを近似できない事態が増えてきた。rfc.jsonとか。
-
処理系開発者は「言語設計者たちが考えること」を読もう
言語設計者たちが考えること 著者: Federico Biancuzzi, Shane Warden Amazonで見る 処理系開発者は絶対読んで後悔しないと思う。とにかくどのページを読んでも楽しく、深い。 言語をデザインしている人なら読んでいるに違いないよね。そんな本。 もちろん、言語マニアでなくてもプログラミング経験者なら誰でも楽しめると思う。 どの言語開発者のインタビューもいいのだが、特にLarry Wallが凄い。Perl 6がここまで高い目標に向かって設計されようとしているのかと感心した。 Perlのデザインに賛同しない人でも読んで驚くと思う。例えば正規表現のリファクタリングの話とかは凄い。誰もそこまでやらんだろう。 正規表現のパターンマッチを拡張するために多くのメタ文字が割りあてられてきたため、ユーザーがどれがメタ文字か覚えられなくなっている問題に対してこう話している。 P.410から引用 Unix文化が初めて正規表現構文を発明したときは、メタ文字はほんの少しだ けだったので、簡単に覚えることができました。パターンマッチにより多く の機能を付け加えていくに従い、メタ文字として使うASCII記号文字の数を増 やしたプログラムもあれば、かつては正規表現と認められていなかった長い 文字列を正規表現に採用して後方互換性を維持しようとしたプログラムもあ りました。これでは無理もありませんが、結果はひどいものでし た。…(略)… 混乱したユーザは正規表現の中ではどんな記号文字であっても バックスラッシュをつけてしまうかもしれません。どの文字が実際にメタ文 字だったか覚えられないからです。Perl 6では、パターンマッチの構文にリ ファクタリングをかけていくにつれて、ASCII記号の大半が何かしらの形です でにメタ文字として使われていることに気がつきました。そこで、我々はア ルファベットでも数字でもないすべての文字をメタ文字として予約し、プロ...
-
Cacooを使ってみた。Cacoo超優秀。
Cacoo(カクー)でSekkaのソフトウェアアーキテクチャ図を描いてみた。
-
Sekka 0.8.2 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.2をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
ユーザー語彙登録UIについて考える(続き)
前回「 2010-12-01Sekka* ユーザー語彙登録UIについて考える 」 の続き。
-
ユーザー語彙登録UIについて考える
[Sekka] 0.8.1には、まだユーザー語彙登録UIがない。 そろそろ、ユーザー語彙登録UIを追加したいと考えている。
-
「modeless SKK」を着想してから「Sekka」が具現化するまで道のり
この数ヶ月は、SKKライクな日本語入力メソッド Sekka* を開発してきた。 今日は、その着想から今に至るまでを振り返ってみようと思う。 前々からmodelessは自分好みのスタイルだったし、[Sumibi.org]というmodelessな日本語入力方式も作った。 その後[Sumibi.org*]を毎日使っているうちに、modelessの弱点も同時に見えてきたので、さらに良い入力方式が存在し得るハズと思い続けてきた。 どうにかブレイクスルーできないかと試行錯誤した足跡を辿ってみよう。
-
Sekka 0.8.1 リリース
SKKライクな日本語入力メソッド [Sekka] 0.8.1をリリースしました。(リリースノート [Sekka.ReleaseNote])
-
相対性理論というバンドについて
久々に緩い記事でも書こうと思います。 坂本龍一も認めるバンド。(NHKの番組で名前を挙げて褒めるなどしていた) 非常に歌詞が斬新。なかなか気楽に聞けて良い。
-
Sekka 0.8.0 リリース
[Sekka] 0.8.0をリリースしました。 初回リリースで、かつβリリースです。
-
Nendo 0.4.0 リリース
[Nendo] 0.4.0をリリースしました。(リリースノート: [Nendo.ReleaseNote]) ライブラリをロードする関数 load の仕様を整理しました。 結局、Rubyの$LOAD_PATHの値を[Nendo]も継承するようにしたので、NendoのユーザーライブラリもRubyのライブラリパスに置くという設計にしました。 ※ 詳細は、[Nendo.ReferenceManual]を参照してください。 これで、[Nendo]で作ったコマンドラインアプリをgem化できるようになりました。 これは[Sekka]をGem化するにあたって、必須だったので手を付けました。
-
load-pathまわりの仕様
オレ処理系の[Nendo]についての開発メモ。
-
関西Ruby会議03でNendoのライトニングトークをした
Rubyで書いたLisp処理系の[Nendo]についてLTさせてもらった。 スライドはこちらでどうぞ。 Nendo At Kansai Ruby Kaigi03(SlideShare) ※ スライドの色合い等が@kakutaniさんのスライドに似ていますが、気にしないでください。@kakutaniさんのプレゼンばっかり見ていたら自然とこうなってしまいました。(笑)
-
AZIK対応に挑戦
今回は、地味でニッチな話題なので、興味がある人は限られると思うのだけど、自分用メモとして。 ローマ字入力方式として、AZIKという方式がある。
-
石火(Sekka)の日本語入力のデモビデオ公開
[Sekka]で日本語入力ビデオに撮った。 これを見れば、リアルタイムで変換候補が表示されるというのがどんな感じなのかが、イメージできると思う。 これで、[Sekka]に興味を持ってくれる人が一人でも増えると嬉しい。 ただ、ミスタイプした場合にそれを救済してくれる機能の「心地良さ」は実際に使って体験してもらわないとわからないと思うので、興味がある人もリリースまで待って頂きたい。 こういう、「使いやすさ」のような、文章やブログでは表現しにくいものをネットで共有したい場合はどうすればいいのかを漠然と考えているところ。 やっぱり、Shibuya.lisp Hackathon #1 : ATNDのようなイベントに参加してわいわいいいながら開発すれば良いものができるんだろうな。 第一段階として、Twitterで触ってみたファーストインプレッションを呟いてもらえればかなりのことは分かるのかもしれないのでTwitterも活用して良い方法に改善していく努力をしてみたい。
-
Nendo 0.3.5 リリース
[Nendo] 0.3.5をリリースしました。(リリースノート: [Nendo.ReleaseNote]) 今回の目玉は高速化です。 tak(竹内関数)でversion 0.3.4に対して約3倍の高速化が実現しました。 個人的に[Nendo]でいろんなものを書いているので、今後も日々必要になったものを優先して実装していくつもりです。
-
Nendoパフォーマンスチューニングメモ(1)
[Nendo]処理系のパフォーマンスチューニングを実施した際のメモを晒しておく。(こういう記録はブログとかWikiに書いとくのが一番だと思う)
-
Nendoのベンチマークを開始
Nendoで書いたプログラムがPure rubyと比べてどれくらい遅いかを調べ始めた。 まずは最初の結果を示そう。 竹内関数の処理時間は以下の通り。 ※ 引数は tak( 10, 5, 0 ) Ruby 0.03秒 Nendo 38.89秒 その差 およそ1296倍。スゲー。
-
fuzzy-string-match 0.9.0 リリース
二つの文字列同士を曖昧比較するライブラリ(gem)をリリースしました。 lucene-3.0.2からJaro-Winkler distance アルゴリズムだけをポーティングしたものです。 キーワード検索でユーザーのタイプミスをある程度許容したい時なんかに使えると思います。 ちなみに、私は[Sekka]という日本語入力メソッドで使っています。 結果は上々で、ローマ字にタイプミスが混在してもそれなりに合っていれば漢字を探しだしてくれるので重宝しています。 限界速度ぎりぎりまで打鍵スピードを上げてもそれなりに漢字変換ができてしまうので非常に効果を感じています。
-
俺言語処理系開発に挑戦したいなら「見るまえに跳べ」
Peter Norvig のエッセイを読んだのだが、自分の過去ならどう感じただろうかと思ったので… 俺言語処理系を作ってみた後では、当時高い壁だと思っていたものが、そうでも無いことを知った。 少しでも興味がある人は実際にトライしてみるべきだと思う。
-
テスト駆動開発入門
大阪府立図書館から借りた。 テスト駆動開発入門 著者: ケント ベック, Kent Beck, 長瀬 嘉秀, テクノロジックアート: 本 Amazonで見る Amazonの書評では、翻訳が酷いので原文で読んだほうが良いと買いてあったのだけど、翻訳自体は文章のリズムがかなり悪い所を除けばそれほど悪いところは無く、普通に読めると感じた。 この本は、テスト駆動開発(テストファーストとリファクタリングの繰りかえし)を一歩づつ具体的な手順を踏んで進めていくという流れで書いてあるので、サンプルコード部分に間違いが無ければそれほど問題ないだろう。 ときかくKent Beckのテストのグリーンの状態を維持しながらコード変更していく気概がわかって良い。 良くも悪くも、なるべく手順を省略せず、現場でテスト駆動開発を実践したらどうなるかというのを、愚直に解説してあるのが良い。 手元に置いておいて、迷ったら何度も参照しながら使う本だと思う。 テストファーストが重要なのは頭ではわかっていても、実際にやってみると正しい手順通りやるのは難しく、臨機応変にテストを後回しにしたりして容易にテストファーストのレールから外れて作業してしまいがちだ。 この本は正しい手順を確認しながらテストファーストを体得するのに有用な本だと思う。
-
NendoがSekkaの足を引っぱっている
[Sekka]は一応、反応速度が良くなるように気を遣って開発している。 なので、高速が売りのKVSをバックエンドに使っているのだが、いかんせん[Nendo]が速度面で足を引っぱっている。 どうしても高速に処理したい部分はRubyで書いて問題回避しているのだが(笑)、いつまでもそれでは悲しい。 Nendo処理系まだまだチューニングが足りないので、チューニングも必要になってきたぞ。 この修行のループを耐えれば実用言語に育つと信じてがんばっていこう。
-
NoSQL(KVS)の選定の続き
先日の記事 「2010-09-06KVS*Sekka 個人的なNoSQL(KVS)のライセンス調査」で、[Sekka]用のKVSをどれにすればいいのかという件について書いた。 選定の観点は、二つだった。 [Sekka]をBSDLにしたい(BSDLにしたい理由は、[Sekka]で書いたコードを[Nendo]に輸入したいため) 将来どこかのPaaSでホスティングしたい(Heroku/EngineYardなど) 結局、KyotoCabinetとMemcached互換プロトコルの両方をサポートする方針でプログラム変更中。 ただ、KyotoCabinetのクライアントライブラリを使ってしまうと、SekkaがGPLに感染する懸念を払拭できないため、最終的にはKyotoCabinetの代わりを探してKyotoCabinetから離脱する必要がある。 KyotoCabinetのRubyクライアントライブラリは1.9.2対応しているし,非常に使いやすいAPIを持っているのに残念。ライセンス問題なんで致しかたない… 代わりとしてKyotoCabinetをやめてTokyoCabinetに戻るという方法もありかなと思っている。まあTokyoCabinetの方が枯れているし、EngineYardでサポートされているし、Linuxディストリビューションの多くでパッケージが用意されている等、考えてみるとメリットも多い。
-
小さなチーム、大きな仕事
図書館で借りた。最近は近隣の図書館(大阪府立図書館など)からも探して貸してくれるので便利になった。 小さなチーム、大きな仕事―37シグナルズ成功の法則 著者: ジェイソン フリード, デイヴィッド・ハイネマイヤー ハンソン Amazonで見る この本を読んで、ビジネス用途のアプリサイトを作ってみたいと本気で思った。勿論それで儲けることができ、うまくいけば生活できるようなものを想定している。 一番の収穫は、自分がビジネスについて勘違いをしていたことに気づかさせてくれた事。 「どんな良いビジネスアプリケーションサイトを作っても、大手がそのうちクローンを作ってきて自分の弱小サイトなんか潰される」とぼんやり思っていたけど、その不安は杞憂だと分かったこと。 そう。数人で回しているサイトのクローンを大手が作ろうコスト構造が違うので無理なんだよな。 自分も中堅のソフトウェア開発企業にいて、肌感覚で知っているけれども、中堅以上の企業というのは管理費やら何やらで弱小企業がやっているアプリのクローンを作っても決して利益が出せない宿命なのだ。 そうそう、今の時代、クラウドがあるので個人もしくは数人で回すというのはアリというより、むしろ有利な時代になってきたのかもしれん。
-
Web+DBのRails3特集が良い
WEB+DB PRESS vol.58 はオススメ。 WEB+DB PRESS Vol.58 著者: 編, WEB+DB PRESS編集部: 本 Amazonで見る 自分はRailsで開発したことは無いのだけど、この特集は現在のRailsがどのようなものかを全方位で把握できる素晴しい特集だ。 PHPとか、RubyとかJavaとか別の言語でWebアプリを作っている人も読んどいて損は無いと思う。今迄Railsを横目に見ていたひとは特に。 今後はスーツな人の間でもWebアプリというとRailsが候補に挙がる状況が想像できるので、チラ見しておこう。 Rails2と違ってRails3は相当モジュラリティが上がっているようで、どんな部品を組みあわせてもRailsに収容されてしまう。 自分に関係するところでは、仕事でRails3を使うということもそうだけど、Rails3にNendoを組み込むこともできそうだ。
-
Nendo 0.3.4 リリース
[Nendo] 0.3.4をリリースしました。(リリースノート: [Nendo.ReleaseNote]) チュートリアルと、リファレンスマニュアルを少し加筆しました。 まだまだ ##(todo)項目が多いですが、最低限の情報は記載したつもりです。(それから、そのうち英語版も作らないといけないですね…) かなりの部分で、[Gauche]のAPIを参考にしているので迷ったらGaucheのユーザリファレンスを参照していただくと解決すると思います(笑)
-
個人的なNoSQL(KVS)のライセンス調査
[Sekka]をBSDLにしたいのと、将来どこかのSaaSでホスティングしたいという観点から、どのNoSQL DBを選べば良いか調査してみた。 ドライバはRubyのみを想定している。 また、SekkaはRuby 1.9.xでしか動かないので、1.9.x に対応したドライバが欲しい。 ちょっと偏ったコメントが混ざっているので、その点だけご注意下さい。
-
Sticky-shiftを試してみたら、小指が痛くなくなった。
Sekka(石火)はSKKと同じように、大文字で送り仮名の位置を指定するので、SKKと同じで Shiftキーを使いすぎて小指が痛くなるという問題がある。 例えば、”行う” を入力したい場合はローマ字で、 “OknaU” と入力しないといけない。
-
SekkaをRackに載せて、試験運用中
現在、新しい日本語入力メソッド(Sekka)を開発中だ。 とりあえずRackに載せることができた。(結局先日書いた方法で[Nendo]の定義関数をRackからうまく呼びだすことができたのである) sekka.elを1日程度ででっちあげて、このブログはEmacs+Sekkaで書いている。(勝手知ったるsumibi.elを改造したのでそんな期間でできたのだが…) まだまだ使いにくい所がたくさんあるので、結論は出しにくいけれど、まあまあ希望が持てそうな使い心地だ。 SKKを使ってきた人なら数分もあれば、慣れるんじゃないかと思う。
-
Nendoで定義した関数をRubyから呼べるようになった
私がRubyで書いているLisp方言、 [Nendo]について。
-
Rackについて学ぶ
現在、新しい日本語入力メソッド(Sekka)を試作中なのだが、サーバとクライアントの通信はHTTPにしようと考えている。([Sumibi.org]もHTTPであったが) 日本語入力メソッドは[Nendo]で書いているので、WebサーバはRubyで書かれたものが使える。というか使えるようにする。 その中でも、Ruby界ではRackというフレームワークが標準になっているようなので、それを試しに使ってみることにした。 Rackって何? という方はこのyharaさんの良記事を読んで頂ければ即理解できるだろう。 Route 477 - 5分でわかるRack , シュレーディンガーの猫たち
-
TDD(テスト駆動開発)の重要性
実験中の新しい日本語入力メソッド Sekka(仮名)を[Nendo]で作ろうとしているが、そのために[Nendo]に足りない機能を足している。 SekkaはちゃんとTDD(テスト駆動開発)で開発していく予定なので、unit testフレームワークが必要になった。 そこで、gauche.testの基本機能をポーティングしたところ。 リンク: Gauche ユーザリファレンス: 9.22 gauche.test - 単体テスト
-
modeless SKK
modeless SKKのプロトタイプの作成中。Sekka:石火(仮名)
-
今創りたいもの(2) 『modeless SKK』
以前に同様のタイトルで作りたいものをリストアップした。 (2010-05-08創作心理* 今作りたいもの) [Nendo]の開発を進めながら、ここらで一旦アプリケーションを書いてみるというステージに戻るのも悪くないかなと思ってどんなものがいいか考えてみた。
-
Gaucheのobject-applyのようなことをしたい
私がRubyで書いているLisp方言、 [Nendo]について。
-
Rubyのブロック構文をサポートした
私がRubyで書いているLisp方言、 [Nendo]について。
-
『スタートダッシュ型仕事術』を見習いたい
引用: Life is beautiful: スタートダッシュ型仕事術:実践編 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェア の宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」 「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャ の大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたり まえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部 分を一気に作って、早めに(仕様変更が必用かどうかの)見極めをする必用が ある」という点。特に「作って見なければ分からない」部分の見極めのための コーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・ 仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足 かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で 実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大 切。 (略) この段階で大切なことは、 書いたプログラムを捨てることを恐れないこと この段階で仕様書を書くことは時間の無駄と認識すること 細かなことを無視して、一番難しい部分を最初に作ること できるだけ早く、一気に「見極めが出来るところ」まで持って行くこと コードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること の5つである。とにかく、このプロセスの目的は、「このアーキテクチャのままで製品化できるのかどうか」「想定し ているユーザーシナリオに合致したものができるかどうか」の「見極め」をすることなので、それ以外のこと(たとえ ば仕様書を書く、ミーティングに出席する、ユーザーインターフェイスの細部を決めるなど)に時間を使わず、とにか く一日でも早く「見極め」ができるところまで持って行く。
-
『計算論 計算可能性とラムダ計算』を借りる
図書館で借りれた。別の市町村にしかなかったので、図書館が又貸ししてくれた。 そのおかげで、2週間での返却制限が付く。
-
Nendo 0.3.3 リリース
[Nendo] 0.3.3をリリースしました。(リリースノート: [Nendo.ReleaseNote]) あいかわらずチュートリアルと、リファレンスマニュアルはまだ書きかけですが… [Nendo.Tutorial] [Nendo.ReferenceManual]
-
自宅サーバマシンが起動しなくなって、考えたこと
このブログをホスティングしているサーバなので、しばらくブログが503になっていた。503といってもリーバイスでなくてhttpのリザルトコードのほうね。 2年に一度くらい、マザーボードやハードディスクが故障する。 大概マザーボードが故障することが多く、2年毎にマザーボードを新調することになる。(今回はオンボードのNICが死んだ模様) マザーボードを買うと、CPUソケットが新世代になってしまっているので、手持ちのCPUは捨てないといけいない。メモリも同様。 結局2年に3万円ほどの出費と手間がかかっているのが現実なので、もうどこかのVPSでホスティングするという選択肢も考え中。
-
srfiのポーティング(2)
私がRubyで書いているLisp方言、 [Nendo]について。
-
srfiのポーティング(1)
私がRubyで書いているLisp方言、 [Nendo]について。
-
高速化のアイデア
私がRubyで書いているLisp方言、 [Nendo]について。
-
末尾再帰最適化、実装完了
私がRubyで書いているLisp方言、 [Nendo]について。
-
MacBook Pro上のsubversionとファイルシステムの準備
MacBook Proが手に入ってさっそく開発できるようにセットアップを行っている。 この記事は未来の自分の為のメモ。 この時作業したOSのバージョンは Snow Leopard (10.6.4)
-
2010年現在、これから個人で始めるプロジェクトについて思ったこと
2010年にもなると個人で作るべきWebアプリケーションはあまり無い。 2008年位までは、時間さえ許せば個人がプライベートで、アイデア一発モノのWebアプリケーションを作れた。というよりも、まだ試されていなくて簡単に実装できるアイデアが沢山あった。 例えば、新しいWikiエンジンとかblogエンジンとかCMSとかの汎用ツールやWebフレームワークが沢山生み出された。どれも発展途上で試行錯誤のしがいがあった。 2010年現在の状況を見てみると、なかなか普通に思いつくアイデアはほとんど試されているんじゃないかなー。世の中にはWebサイトが溢れ返っている。Webフレームワークもある程度定番に収束しつつある。 おまけにGoogle App Engineなどのように無料で使えるクラウドサービスがあるので、サイトをオープンするための費用面での敷居も下がり続けている。 TechCrunch Japanなんかを時々チェックしていると、ますますそういう思いが強くなっていく。毎日似たようなサービスが雨後の竹の子のように生まれ続けている。
-
今さらRubyでCGIもないだろうと思って調べたら、Rackにたどりついた。
CGI程度の簡単アプリであっても、Rackに乗せるべきだと思った。
-
Rubyの呼び出しスタックの深さ制限値を広げることはできるか
Rubyで、再帰呼び出しの回数が深すぎると、スタックオーバーフローになる。 再帰を多様する関数型プログラミングスタイルでコーディングなんかすると頻繁にスタックオーバーフローを目にすることになる。 例 tail_recursion_normal.rb:7: stack level too deep (SystemStackError) [Nendo]の末尾再帰最適化をやろうとして、ふと思った。「Ruby側のstackの深さ制限を緩和すれば、そこそこ深い再帰呼び出しをしても実用レベルでは問題にならないんじゃないだろうか」
-
末尾再帰最適化をどう実装するか
私がRubyで書いているLisp方言、 [Nendo]について。
-
Nendo 0.3.2 リリース
[Nendo] 0.3.2をリリースしました。(リリースノート: [Nendo.ReleaseNote]) チュートリアルと、リファレンスマニュアルはまだ書きかけです。 [Nendo.Tutorial] [Nendo.ReferenceManual]
-
初めての人のためのLISP<増補改訂版> 読了
初めての人のためのLISP </a> </h3> 著者: 竹内 郁雄 Amazonで見る </div> </div> 深い本。 この分量で、Lispのミクロで見た視点と、マクロで見た視点(俯瞰した視点)の両方を楽しく見せてくれるすばらしい本だ。 マイ処理系を実装しながら読むと、もっとリファクタリングしたくなってくる。 例えば、現在の*[Nendo*]は read eval print loop (通称repl) がRubyで書いてあるのだけど、ちゃんとLispで ``` (loop (write (eval (print)))) ``` というコードにしてしまいたいと思った。 おそらく、少しのリファクタリングで直せるだろうし、プログラムの見通しも良くなりそう。
-
Hadoop本を読む
Hadoop 著者: Tom White, 玉川 竜司, 兼田 聖士 Amazonで見る 翻訳者の玉川さんにいただいた本。 まだ全部読んでいない。 結構、分厚い本だ。 ある程度読み進んでは、実際に動かしてみてという繰返しで学習しないと、MapperとReducerの作りかたがパッと思い浮かぶまでにはならなさそう。 実際に、14章のケーススタディを読みながら手を動かして実験するのが学習が早そうに感じた。
-
PowerPCに失望の連続(2)
(2010-04-05ハードウェア* PowerPCに失望の連続) でも一度書いたが、まだまだやられている。 私の開発用Macは今だに、PowerPCなのだが、時代に置いていかれそうだ。 最近、使いたいけど、PowerPCに対応していないせいで使えなかったオープンソースソフトウェアのリスト。 MongoDB KyotoCabinet MacRuby 0.6
-
今作りたいもの
今日時点で作りたいものをリストアップしてみる。 こういう心境は数ヶ月もすると簡単に変化する。 例えば、もろコンフリクトするライバルプロジェクトや、やる気を無くすほど良く出来たサービスが出てくるので、本当に今日時点でのスナップショット。
-
驚愕! SQLiteのテストコードは本体の約679倍
SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行 - Publickey 軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載 されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあい だで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。本体のソースコードは約6万 7200行(67.2KSLOC、Kilo Source Lines of Code:空行やコメントを除いた行 数)なのに対し、テストコードはなんと4567万8300行(45678.3KSLOC)だと紹 介されているのです!これはテストコードが本体の約679倍もの大きさだという ことになります。
-
Nendo 0.3.1 リリース
私がRubyで書いているLisp方言、 [Nendo]について。
-
CRuby-1.9.1とJRuby 1.5.0-RC1の挙動の違いを発見
JRubyのバグかなとTwitterでつぶやいたら、@hiro_asariさんから、どんな内容か教えて下さいと返信もらったので、これはその説明用エントリです。@hiro_asariさんありがとうございます。 Twitter / Hiro Asari: @kiyoka JRubyで1.9相当の挙動を促すに … @kiyoka JRubyで1.9相当の挙動を促すには–1.9というフラグが必要です。そ れでも違う場合には、どのような物か提示してもらえれば調査してみます。
-
ビューティフルアーキテクチャを読む
図書館にあったので借りて読んだ。 ビューティフルアーキテクチャ 著者: Diomidis Spinellis, Georgios Gousios, 久野 禎子, 久野 靖 Amazonで見る
-
Nendo 0.3.0 リリース
私がRubyで書いているLisp方言、 [Nendo]について。
-
Internetがない環境での生産性は高いか
答えは、『どんな作業をするかによって変わる』だと思う。 最近、子供を託児所に預けている数時間の間にカフェで[Nendo]の開発を行っているけれども、Internetが接続されていない環境では割り込みが入らないため、コーディングやデバッグの生産性は非常に高い。 ただ、他の言語処理系のコードや設計方針なんかを参考にしようとすると、Internetから情報が得られないため部分的に非常に生産性が低い。 Internetは諸刃の剣だと思う。 Internetに繋った環境と繋ってない環境を1日おきとか、午前と午後で分けるとかにするとか工夫するとうまく生産性を上げれるかも。 今Twitterがはやっているけれども、みんなどうやってそのノイズに負けず生産性の維持をしているのだろうか。
-
プログラマは皆どのようにしてLisperと化して行くのか?
vallog: プログラマは皆どのようにしてLisperと化して行くのか?のエントリ。よくこれだけの項目書いたなあ。 ハッカーと画家 Amazonで見る 私はPerlやRubyからLisperに転身したのであるが、上記エントリのかなりの項目数が当てはまる。 色々あって、RubyでLisp処理系を作る事になったが、それはLisperで居続けるためのRubyプログラミングであって、やっぱり自分はLisperだと自覚している。 あっ、そういえば最近、Lispを学習する人のブログエントリが増えている気がするが、自分の見ているところが偏っているだけなのかな?
-
Gaucheのtext.html-liteをポーティングできた
私がRubyで書いているLisp方言、 [Nendo]について。
-
オレ言語処理系]を開発する意味
『Just for Fun』 という答えはありきたりすぎて面白く無いかも知れないけど、実際そういう部分が一番大きい。 同時に、プログラミングスキルを上げたいという気持ちも当然あって、それらの動機は混在しているし、考えてみると他にも動機がいろいろ有りそうで自分自身でもはっきり説明できない所がもどかしい。 しかし、振りかえってみると、[Nendo]の開発は知的好奇心を刺激するし、同時にLispプログラミングのスキルが上がっているのは確かなので、このまま好循環で進んで行きそうだ。
-
多値の実装完了
私がRubyで書いているLisp方言、 [Nendo]について。
-
実用アプリを作りながら、処理系を鍛えるのは重要
私がRubyで書いているLisp方言、 [Nendo]について。
-
Nendo 0.2.0 リリース
私がRubyで書いているLisp方言、 [Nendo]について。
-
初期化スクリプトをコンパイル済にして高速化した
私がRubyで書いているLisp方言、 [Nendo]について。
-
Gaucheの #?= 相当のデバッグユーティリティをサポート
私がRubyで書いているLisp方言、 [Nendo]について。
-
named letをmacroで実装した
私がRubyで書いているLisp方言、 [Nendo]について。
-
set!の実装につまづく(3) =>解決
私がRubyで書いているLisp方言、 [Nendo]について。
-
letrecを実装した
私がRubyで書いているLisp方言、 [Nendo]について。
-
set!の実装につまづく(2)
私がRubyで書いているLisp方言、 [Nendo]について。
-
set!の実装につまづく
私がRubyで書いているLisp方言、 [Nendo]について。
-
プログラミングClojureを読む(その2)
プログラミングClojure 著者: Stuart Halloway, 川合史朗 Amazonで見る 目次 第1章 Getting Started 第2章 Clojureひとめぐり 第3章 ClojureからJavaを使う 第4章 シーケンスを使ったデータの統合 第5章 関数型プログラミング 第6章 並行プログラム 第7章 マクロ 第8章 マルチメソッド 第9章 現場のClojure やっと、最後まで読めた。 じっくり読むために、1歳半の子ををいろんな施設にあづけている時間に読んだので、それにかかった金額は1万円くらいか。 それに比べると、本の購入金額なんてあって無いようなもんだな… 独身とか学生の方々は時間のある今のうちにいろいろ好きなことをしておく事をオススメする。...
-
プログラミングClojureを読む(その1)
プログラミングClojure 著者: Stuart Halloway, 川合史朗 Amazonで見る 目次 第1章 Getting Started 第2章 Clojureひとめぐり 第3章 ClojureからJavaを使う 第4章 シーケンスを使ったデータの統合 第5章 関数型プログラミング 第6章 並行プログラム 第7章 マクロ 第8章 マルチメソッド 第9章 現場のClojure
-
LET OVER LAMBDA 読了
LET OVER LAMBDA Edition 1.0 著者: ダグ ホイト, Doug Hoyte, タイムインターメディアHOPプロジェクト Amazonで見る やっとひととおり読めた。休み休み読んで、結局半年くらいかかったのか。 『第6章 マクロの効率』だけはあまり興味が無かったので飛ばした。(どうも自分はイマイチ実行速度には興味が無いらしい) 目次 第1章 クロージャ 第2章 マクロの基礎 第3章 リードマクロ 第4章 プログラムするプログラム 第5章 アナフォリックマクロ 第6章 マクロの効率 第7章 Lispを動かすForthを動かすLisp
-
LEGOブロックを使って1分でiPodTouchスタンドを作る方法
結論:LEGOブロックを使えば、こんなiPodTouchスタンドが簡単に作れる!
-
プログラマに比べて、プロ楽器奏者が間違えないのはなぜ?
自分はキーボード入力でタイプミスする方だと思う。 一般的にプログラマはキー入力をミスるもんなんだろうか。 プログラマのみなさんはどうですか?
-
gemをGemCutter.orgに再登録した
私がRubyで書いているLisp方言、 [Nendo]について。
-
年末に読んだ本
年末、約2週間ほど完全に自由の身だった間に読んだ本。あー、この時間は天国だったなあ。 3冊の本のジャンルはバラバラだけど気にせずに…
-
heist:Rubyで実装されたScheme処理系
あまり時間が無くて[Nendo]の開発が滞っているが、[Nendo]の他にもRubyでLisp処理系を実装している人がそれなりに居る様なので、順番に見て行きたいと思う。 手始めとしてheistを調べ始めた。 作者のブログによると、開発動機は実用目的ではなく勉強目的の様だ。 SICPを読んでいるうちに一度実装してみたくなったという感じだろう。 作者のブログには自虐ネタ的なブログエントリもあったり。 April fool: area man releases world’s slowest Scheme interpreter : The If Works
-
2010年の抱負
開けましておめでとうございます。 去年の今頃『[kiyoka.2009_01_05] Life 2009年の抱負』で、いろいろ書いたけど、思ったようにはグローバル化は自分の仕事に影響しなかった。 今年は仕事とプライベートのバランスを取り戻す年にしたい。 そして、2010年の年末にはハッピーエンドで終わりたいと思っています。あわよくばその時に未来の話が出来るようになっていれば最高かな。 みなさんの1年も良い年でありますように。
-
『パターン、Wiki、XP ~時を超えた創造の原則』とRuby
Rubyコミュニティーの方々のプレゼンでたびたび紹介されていた本。やっと読了。 Ruby関連のイベントでこの本が紹介されるのは、XPの発展に貢献したメンバーがRubyのユーザーになって来ていることが原因らしい。 (SmalltalkとRubyの両方を使っている人が多い?) パターン、Wiki、XP ~時を超えた創造の原則 著者: 江渡 浩一郎 Amazonで見る
-
Programming in Lua 読了
Programming in Lua プログラミング言語Lua公式解説書 著者: Roberto Ierusalimschy, 新丈 径 Amazonで見る – 第1部 言語(最初の一歩型と値ほか) – 第2部 テーブルとオブジェクト(データ構造データファイルと永続化ほか) – 第3部 標準ライブラリ(数学ライブラリテーブルライブラリほか) – 第4部 C API(C APIの概要アプリケーションの拡張ほか) – 第5部 付録:Luaリファレンスマニュアル(言語アプリケーションプログラムインターフェイスほか)
-
プログラミング学習リハビリ
最近こんな本を図書館でゲットした。 図書購入依頼していたのが届いた。購入依頼は同時期に届くのがやっかいだなあ…
-
ついに出たか! Google日本語入力
Google Japan Blog: 思いどおりの日本語入力 - Google 日本語入力 すごい、とうとうGoogle自身が作ったか。 早速、インストールしてみようとしたが…
-
gemを公開した
私がRubyで書いているLisp方言、 [Nendo]について。 だいぶ前にgemを公開したのだけど時間が無くてブログ記事を書けなかったので、とりいそぎの記事です。 インストール方法は[Nendo]を参照して下さい。 Ruby 1.9.2devでしか動かないのでその点だけ御注意下さい。 まだドキュメントが無いので、現在のNendoでどんなことができるかは、kiyoka’s nendo at master - GitHubの中にstowspecというソースコードを参考にして何とかしてもらうしかないです。 処理系の実装をやっている方の参考になればと思い公開しました。 当分時間が取れそうにないので、ドキュメント書きなどの作業は進まないと思います。
-
Ruby 1.8.x対応を見送った
私がRubyで書いているLisp方言、 [Nendo]について。
-
シェルトランポリンの実現方法2
私がRubyで書いているLisp方言、 [Nendo]について。
-
シェルトランポリンの実現方法
私がRubyで書いているLisp方言、 [Nendo]について。
-
Pythonのlambda
Pythonのlambda - 西尾泰和のはてなダイアリー The fate of reduce() in Python 3000 Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is...
-
プログラミング言語Lua公式解説書
Programming in Lua プログラミング言語Lua公式解説書 著者: Roberto Ierusalimschy, 新丈 径 Amazonで見る プログラミング言語デザインの学習の足しになりそうなので1冊買っとこう。 プログラミング言語の作者自身が書いた本は貴重なので、見つけたらできるだけ買っときたいものだ。 時々、言語デザインのトレードオフについて書かれていることがある。 特に有用な情報としては、実際には採用しなかった案と、採用しなかった理由が書かれている場合だ。 そんなことは言語デザイナ本人しか知らないからねぇ。
-
Google App Engineとかやってみたい
最近やってみたいばっかりで自由な時間がない。 クラウドサービス楽しそう。KVSデータベース楽しそう。いつか遊んでみたい。
-
最近読んだ本。(佐々木氏の本、他)
なかなかコンピュータをさわる時間はあまり無いけど、電車に乗っている時間が有るので本だけは読める。 というわけで最近読んだ本。 2011年新聞・テレビ消滅 (文春新書) 著者: 佐々木 俊尚 Amazonで見る ブログ論壇の誕生 (文春新書) 著者: 佐々木 俊尚 Amazonで見る
-
オレオレ参照透明性というアイデア(immutable宣言)
私がRubyで書いているLisp方言、 [Nendo]について。
-
LLTVを見てきた
LLTVを見てきた。 朝まで生テレビが一番おもしろかった。 パネリストの3人の話を聞いていると、現状のLLというのがコンピューティングのあるレイヤーを担っているだけのチッポケな存在だということを感じた。 但し、LLは人間にとって、より高い表現力を手に入れる為の進化をつづけており、より簡潔な表現でプログラムを構築するという意味では非常に重要なポジションを担っている。 最近では、並列化に対する要求が高まっており、LLが並列処理の記述を自然にサポートする時代が来るのだろう。 今はその過渡期なので、いろんな言語が並列化表現に挑戦しては新しい発見をしていくだろうと思う。 何かちょっと未来が垣間見れてよかった。
-
On Lisp読了
やっと読み終わった。 Amazonで見る 一回では理解できなかったので、『継続』の章や『オブジェクト指向Lisp』の章は2回以上は読んだ。 しかし、call/ccは使ったことないのでなかなかイメージしずらい。反対にCPS変換は実際に使っているので理解できた。 やっぱり、実際にプログラミングを続けながら、繰返し読むことが大事だな。 [Nendo]を開発しつつ、次は LET OVER LAMBDAに挑戦だ。 Amazonで見る
-
ラーメン屋 vs.マクドナルドを読む
ラーメン屋vs.マクドナルド―エコノミストが読み解く日米の深層 著者: 竹中 正治 Amazonで見る マスコミでよく喧伝されるような、日本人はアメリカ人に比べて創造性が無いとか、リスクを取りたがらないとかいうのは、日本人の気質の問題ではなく制度の問題だということを統計データを引きながら解説してくれる良書。 この本の結論としては日本が復活するためには、政治の力に期待するしかないということになっているが、もしそうだとしたらなかなか出口は見えないのではないか。 とりあえずは選挙に行こう。 そして、ミクロな視点では自分の得意分野にとことん投資し続けよう。
-
扇風機のユーザインタフェースをマジックでグリグリ改善した件
うちにある扇風機が余りにも使いにくいので、早速マジックでUI変更。 この扇風機のひどい所は、本来の『運転(入/切)』よりもionの『(入/切)』のほうが目立つ様にデザインされていること。 さらにひどいのは、コードを接続して『いざ扇風機をON!』と一番目立つ緑色のボタンを勢いよく押しても何もおきないこと。 正確にはionがONになっていることを主張する緑色のランプが点灯するだけで、肝心のファンは回ることはない。アホかー! そもそもイオンというモノ自体が迷信に限りなく近い代物なのにそれをスイッチにしてしまうかなぁ。 とまあブツブツ言いながら、この本の前書きを読み返してみたりして。
-
util.matchってNendoで動くのかな
私がRubyで書いているLisp方言、 [Nendo]について。
-
Clojureのビデオを見る(3)
Classベースのオブジェクト指向とGeneric関数指向の違いについてRich Hickey氏の言及がある。 InfoQ: Rich Hickey on Clojure’s Features and Implementation Q. Moving on to another feature that brings polymorphism to Clojure, multimethods to an object oriented programmer, how would you...
-
次はアプリを試作してみよう(3)
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
次はアプリを試作してみよう(2)
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
次はアプリを試作してみよう
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
Nendoの初期化ライブラリの階層構造
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。 今回は自分用のメモ。
-
Let Over Lambda
まだ買っていないのだけれど… LET OVER LAMBDA Edition 1.0 著者: ダグ ホイト, Doug Hoyte, タイムインターメディアHOPプロジェクト Amazonで見る Amazonの商品説明より Let Over Lambdaは世にある中でも最も過激なコンピュータプログラミング書籍 の1つだ。基礎から始まり、最も高度な言語、すなわちCommon Lispの最も高度 な機能を説明する。トップ1%のプログラマだけがLispを使う。そして本書を理 解すれば、そのLispプログラマのトップ1%になるのだ。本書は、プログラムを 書くプログラムであるマクロに関するものだ。マクロこそが、Lispを世界で最 も偉大な言語たらしめているものなのだ。正しく使えば、驚くべき抽象化の技 法、プログラマの生産性、コードの効率、そして他所では耳にすることすらな いようなセキュリティをもたらしてくれる。マクロは、他の言語では全く不可 能なことを可能にしてくれるのだ。
-
Ruby 1.8と Ruby 1.9の違い
[Nendo]の文字リテラルの扱いをどうしようかとRubyを調べてみると、Ruby 1.8とRuby 1.9に違いがあることを知った。 意外と大きな仕様変更なのではないかと思う。 [ 先取り!Ruby 1.9.1 (2/3)](http://www.thinkit.co.jp/cert/article/0709/26/2.htm) この変更に伴い、いくつか文字列まわりに重要な変更が発生します。 例えば、文字の扱いがいろいろと変わります。従来、文字列に対して「 String#*n*」とすると、バイト列のn番目の数値が返ってきました。つま り、"Hello"*0*は72を返す、といった具合です。しかし、今後文字列はエ ンコード情報を保持しますので、"Hello"*0*は"H"という1文字を返すよう になります。
-
トム・デマルコも誤りを認める
「測定できないものは制御できない」は誤りだった。– by Tom Demarco:An Agile Way:ITmedia オルタナティブ・ブログ この記事のなかで、例えば、GoogleEarch や Wikipedia といったソフトウェ アが、果たして計測と制御という管理で作られただろうか、と問うている。そ して、2つの種類のプロジェクトを例にし、
-
コードの世界 読了
まつもとゆきひろ コードの世界‾‾スーパー・プログラマになる14の思考法 Amazonで見る やっと全部読んだ。本当にすばらしい本。 これだけの内容が1人の人間の手で一冊にまとまっているというのは奇跡だとおもう。 Rubyの解説本では無いけれど、読み終わったころには、Rubyの設計思想や優位性が理解できているという副作用もある。 読後は、Rubyでプログラムが書きたくなるかも。 私もS式中毒にかかってなかったら、この本を読んだ後は、プライベートなコードもRubyを使うことになっただろう。
-
Rubyとの連携を考える(3)
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。 Rubyの世界へのアクセス手段として引きつづき .(ドット)オペレータを実装してみた。 (ここに書いた仕様はおそらく後日変わると思うので注意)
-
Rubyとの連携を考える(2)
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。 Rubyの世界へのアクセス手段として引きつづき .(ドット)オペレータを考えてみる。
-
Clojureのビデオを見る(2)
[Nendo]の開発でかなり参考にしたい言語であるClojureのビデオをみた。 このあいだ紹介したやつ([kiyoka.2009_07_02])とは別のビデオ。
-
Rubyとの連携を考える(1)
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
JRubyの開発者がオレ言語も作っている件
InfoQ: JVMで動く言語Ioke:分かりやすい構文で、LispとRubyの力を持つ言語 Ola Bini氏は、JRuby開発の中心人物であり、Practical JRuby on Rails Projectsの著者である。その彼が、IokeというJVMの上で動く新しい言語を開 発している。
-
Shibuya.lisp #3のビデオを見た感想(1)
実用レベルで使う処理系を作っている方々は実行速度に対する意識が高いなあと感じた。 shiroさん。現場のSchemeの話題。Gaucheの開発サイクルがわかる。すばらしい。 現場のSchemeとGaucheの進化 <1/6>
-
quasiquoteが動いた日
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
Clojureのビデオを見る(1)
[Nendo]の開発でかなり参考にしたい言語であるClojureのビデオがYoutubeにあった。 iPod touchに入れて数日かけて通勤中に見た。
-
ついにorとandを定義できた
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
defineをmacroで実装した
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
可変長引数のサポート
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
伝統的なmacroが動いた
ここまで長い道程だったが、macroが動いた。 実際にmacroを実装してみるとmacroがどういうものかやっと理解できた気がする。
-
伝統的なmacroの実装に向けて
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
コードの世界
まつもとゆきひろ コードの世界‾‾スーパー・プログラマになる14の思考法 Amazonで見る 2章まで読んだ。本当にいい本です。オススメ。 オレ言語を作ったりしている人はたぶん買っているだろうけど、それ以外の人にも薦めるぞ。 2章まで読んだだけでも、なぜ、RubyにLispのようなmacroを導入しなかったのかを感じ取ることができる。 Lispのようなmacroで無限の柔軟性を手に入れたいのは一部の人だけで、もっと広く使われるためにはもう少しマイルドな代替手段を使って攻める必要があるという狙いがあるようだ。 たしかに、Rubyのmethod_missingの仕組みや、メタプログラミングの仕組みを使えばかなり読み書きしやすいDSLが作れる。 でも、個人的にはその仕組みが複数あったり、それぞれになんとなく固有の限界が見え隠れしたりして全容を理解するまでが、遠いという感じがある。でも、これは好みの問題か。 LisperはLispマクロの単純なルールで限界を突破するけれども、普通のひとにはたしかにコードをパッと見ただけで拒否反応を起こすのも現実なのは何度も経験している。 うーん。Rubyのバランス感覚はすばらしい。 でも、それをあえて崩してみるのも楽しいかなと思って作っているのが、[Nendo]というわけ。さてどんなものになるのやら。
-
Scheme脳に偏った変なコーディングについて
私はRubyでプログラミングする時、次の様にRubyらしからぬコーディングスタイルを取る。(仕事では同僚とコード共有するのであまりやらないけど)
-
Rubyのメソッドはファーストクラスオブジェクトだった
Yuguiさんのエントリーより引用 ファーストクラスオブジェクトとしてのメソッド - 世界線航跡蔵 やー、Rubyのメソッドはファーストクラスですよ。返り値にできて、変数に格 納して演算できて、引数にできるという意味では。 確かに、RubyはPythonやJavaScriptやSchemeに比べると高階関数を陽に使うプ ログラミング*1 は不格好になる。Pythonなら簡単なのに、 bound_function = obj.hoge bound_function(arg1, arg2, arg3) Rubyは余計なメソッド呼び出しがくっついて不格好だ。 method = obj.method(:hoge) method.call(arg1, arg2, arg3) 私もこの点が気にくわなくてまつもとさんに「メソッドがファーストクラスだっ たらいいのに」と言ったことがある。でも、まつもとさんの考えではすでに ファーストクラスということだった。
-
NendoをGitHubに移してみた
NendoをGitHubに移してみた。
-
undefined variable エラーをRubyの例外システムの上に実装してみた
[Nendo]はせっかくRubyの上に構築している言語なので、エラー処理などもRubyの例外処理をそのまま使って実装してみた。 もちろん、バックトレースの情報にもエラーが起きた行番号を埋めこむ処理も入れた。 以下は、nendo処理系の動作結果 ( rubyExp=«< »> という部分はトランスレートされた後のRubyコードをデバッグ表示したもの )
-
RSpecでraise_errorマッチャの使いかたを勘違いしていた
RSpecのexpectationの書き方で、気を付けないと行けないところ
-
GitをMacにインストールした
WEB+DB PRESSのGit特集を読んでGitを使ってみる気になった。 WEB+DB PRESS Vol.50 著者: WEB+DB PRESS編集部 Amazonで見る
-
]のオープンソースライセンスを何にするか
[Nendo]はRubyベースなので、選択肢は二つになりそう Rubyと同じ(GPLとArtisticのデュアルライセンス) 修正BSD
-
屋外でプログラミング
最近家では10分も集中することができない(というか、子供が無いたらすぐになんとかしないといけないので、集中することを禁止されている) というわけで、1週間に2時間くらいは開放させてもらって、プログラミングに集中するようにしてみた。 子供がいない時([Sumibi.org]を作っていた時)は土日に8時間くらいは集中する時間があったので、えらく使える時間は減ったなぁと思う。
-
Jazzで一番美しいと思う曲
これ。久々に疲れた時に聴いてみた。美しすぎる。 Miles Davisの『Blue In Green』という曲。
-
RSpecを学習中
この記事を読みながら概略をつかもうとしているところ Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編) [Nendo]の開発では、一旦ラフなコードを書いては、もっと簡潔になるようにリファクタリングするという繰返して開発しているので、RSpecがうまく使えそう。 とういかテストコードをすでに沢山書いていて、それをちゃんと整理しないとなと思っていたところ。 RSpecのDSLは慣れると読みやすそう。 いつか仕事でも役に立ちそうなのでみっちりやっておこう。 RSpecはオンラインドキュメントが充実しているので、現時点ではこの本を買うまでもないかなと思っている。 The Rspec Book Amazonで見る
-
Ruby標準ライブラリを使って]のライブラリ実装をサボりまくりな話
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
ソーシャル化するOSS開発者たちを読んだ
Subversionとgitについて書かれている。 私はまだgitを使ったことが無いのだけど、そんなに速いのか。
-
高階関数の定義(mapとfilter関数)
私がRubyで書いているLisp方言、 [Nendo]の開発状況続き。
-
やる気はどこからやってくるのか
着手すると、やる気はあとからついてくる これは、私が経験的に感じていること
-
mapとfilterが動いた
私がRubyで書いているLisp方言、 [Nendo]の開発状況。 なんとか、mapとfilterを動かす部品がそろったぞ。
-
恥の文化の対極にある日本人ラッパーのメンタリティ
rapper(ラップをする人)の歌詞って、一般的には自己評価の低いといわれる日本人からすると対極にあると思う。 ということは日本人ラッパーはかなり希少価値が高いかも。 恥も外聞もなく、『オレは最強、ナンバーワン、ダレにも真似できねぇ』系の歌詞が多い。 日本人的な、内向的で自己評価低い(ある意味暗い)ラップってあるのかな。そういうのも聴いてみたい。 そういえばEninemはちょっと内向的な気がするし、MC Sniperも韓国人で日本人にメンタリティが近そうだが、これも内向的なラップをやっている。 MC Sniper- 한국인(韓國人) 今、YouTubeでKREVAとかVERBALのオレ最強的ラップを聴いていてふと思っただけなんだけど。 すみませんが、結論無しのエントリーです。
-
そろそろオレ言語でもやっておくか(11)
このClojureのtutorialが非常に参考になる。本家のドキュメントではないけどたいへん分かりやすい。 Clojure Tutorial For the Non-Lisp Programmer | Moxley Stratton ClojureがJavaのClassライブラリをアクセスする構文を持っている。 対して、NendoはRubyのClassライブラリをアクセスする必要があるので、言語仕様を考える上でClojureの例は大変参考になる。
-
Rubyがいろんなプラットフォームに広がっている件
独SAP、自社VMでRuby処理系のサポート追加へ/@IT 独SAPは3月27日、同社のWebアプリケーションサーバで動くRubyの実験実装 「Blue Rubyプロジェクト」について明らかにしている。ABAP(Advanced Business Application Programming)は、独SAPが提供するWebアプリケーショ ンサーバ「SAP NetWeaver Application Server」は、J2EEと独自言語ABAPによ るアプリケーション開発が可能なVMを備えている。 IronRubyやJRuby以外にもどんどん使える環境が広がっている。 MacRubyもLLVM化したりして、高速化競争も始まっており、Rubyプラットフォームの普及は最終段階に来ているのかも。 JRuby 50倍速、MacRubyはすでに到達域 - 竹内関数 | エンタープライズ | マイコミジャーナル 今開発しているおもちゃ言語のNendoもいろんな場所で動くと思うと楽しみになってくる。 あとは、Google App EngineでRubyが使える様になると色々遊べそうだ。Googleはいつ対応するのかなぁ。
-
そろそろオレ言語でもやっておくか(10)
nendoにlet構文を追加しようとして、ふと立ち止まる。 先にquasiquoteを実装して、その構文の上にletを構築するか、それともletを素直にRubyで書いたevaluatorで実装するか。 まずは段階的にRubyで書いてみようかな。 書いては捨て、捨てては書いてというのを繰返していきながら、一番いいやりかたを探していこうと思う。
-
RedLisp改めNendo
昨日書いた通り、なんとredlispは既にあった!ということで、Nendoという名前に変更した。 [CodeRepos]の中で何度もディレクトリ名変えてすみません。 やっぱりプロジェクトの最初の方ではこういうドタバタは何度もある。 [CodeRepos]に入れるのはもうちょっと先にしたほうが良かったかな…
-
そろそろオレ言語でもやっておくか(9)
オレ言語にRedLispという名前をつけたのだけど… なんと、redlispは既にあった! 名前がカブっていたのだ。 先日Google検索した時は、『日本語のページを検索』のラジオボタンにチェックが入っていたという初歩的な失敗をした。 Googleで検索しておけばグローバルに検索されるので間違い無いと思い込んでいた。思い込みとは怖い。 気をとりなおして別の名前にすることにしたぞ。 候補は子供のころから粘土細工が好きだったこと、S式でプログラミングをしている時の自分の心理状態が粘土でコネコネしているのと似ているような気がしているので、『粘土』というキーワードをどこかに入れたい。 そのまま粘土(nendo)にするのもありかな。候補は、 nendo craylang rubycray rcray もちろんnendoというSNSが存在することも、nendoというデザイン会社が存在することもnendo.orgというドメインがあることも知っている。(そんでもって、TMにはなってなさそう) でも、プログラミング言語でカブなければよしとするしかない。 プログラミング言語の名前としてはArcとかIoというような短い名前は沢山ある。カブることを気にしていたら切りがないのだ。
-
そろそろオレ言語でもやっておくか(8)
Rubyで書いたLisp処理系の RedLisp 開発の続き。 lambdaとifの二つのスペシャルフォームを実装した結果、fact(階乗計算)関数が動くようになった。 $ ./redlisp redlisp> (def fact (lambda (n) (if (= n 1) 1 (* n (fact (- n 1)))))) rubyExp=<<<fact = lambda { |n| if ( _eq.call(n...
-
そろそろオレ言語でもやっておくか(7)
RubyでLisp系言語処理系を作りはじめた 現段階でRubyのコードで大体500行くらい。 RedLispという名前にした。Googleで検索したところ、同じ名前のものは無かったのでこれにした。RedはRubyが赤いから。ナント安易な… 赤色というのは、プレゼンの時にシャア専用とか何とかいえばネタにしやすいという狙いもある(笑)
-
Rubyのよくわからない挙動(1)
===メソッド(比較演算子)の挙動がよくわからない。 クラス A を定義し、インスタンスを a に代入する。 $ irb >> class A ; end class A ; end => nil >> a = A.new a = A.new => #<A:0x3637ec>
-
そろそろオレ言語でもやっておくか(6)
Cyan作った人 Cyanを設計した高校生、5カ月で5つの言語を習得 読者の皆さんは、「Cyan」(サイアン)という言語をご存じないかもしれない。 Cyanは、Lispのマクロを持ち、Python風のインデントによってブロックを表す プログラミング言語。2008年の春、林拓人という1人の高校生によって設計さ れた。
-
そろそろオレ言語でもやっておくか(5)
過去の記事の続き 2008-09-23言語* そろそろオレ言語でもやっておくか(4) 2008-09-03言語* そろそろオレ言語でもやっておくか(3) 2008-08-31言語* そろそろオレ言語でもやっておくか(2) 2008-08-09言語* そろそろオレ言語でもやっておくか(1)
-
Key-Value Store勉強会に行きたかった...
Key-Value Store勉強会に行ってきました - blog.katsuma.tv greeさんで開催されたKey Value Store勉強会に行ってきました。時間にして 4時間超え、内容も国内のKey-Value Storeなソフトウェアの最前線の話ばかり で相当なボリューム。以下、メモってたのを残しておきたいと思います。 それにしても、このメモすごい情報量。
-
いつのまにか Debian 5.0 がリリースされていた
Debian GNU/Linux 5.0 “Lenny” リリース!!! 以前のリリースから約2年近くを経て、Debian GNU/Linux 5.0 コードネーム “Lenny” が 2009/02/14、ついにリリースされました 今 Debian GNU/Linux 4.0を使っているが、特に4.0に不満が無かったので気がついたら次の5.0がリリースされていたという感じ。 Windows XPユーザにも言えることだと思うが、どのOSもこれ以上のバージョンアップはあまり重要ではない気がしてきた。 ソフトウェア開発はWebアプリケーションにシフトしているし、OSやサーバマシンは自分で管理するよりは、Amazon EC2の様に誰かに管理してもらった方がラクだと思うようになってきた。 もし、Amazon EC2がもっと安くなったら契約しようと思っているのは自分だけではないと思う。 もっとも、Amazon EC2上で動かすOSは Debian GNU/Linux 5.0 “Lenny” を使うだろうけど。 それまでは差し迫ってバージョンを上げない可能性が高い。...
-
日本のIT業界の未来は暗い。ならば個人として準備できることは?
『IT産業 再生の針路』 破壊的イノベーションの時代へ Amazonで見る SIer,ITソフト会社のビジネスモデル再構築のための『IT一番戦略の実践と理論』 Amazonで見る
-
セルフパトロンシステムの限界
ノンプログラミングでWebアプリを作るシステムについて調べている。 (参照:[kiyoka.調査.簡易Webアプリ作成ツール]) その中でTuigwaaというオープンソースプロジェクトを見つけた。 過去にIPAの未踏プロジェクトにも採択されており、可能性があるのかなと思ったのも束の間、Tuigwaaのサイトには開発終了宣言が出ていた。 2008/08/18 重要なお知らせ WebUDA Tuigwaa プロジェクトは、新機能開発を停止することとなりました。
-
コマンドラインを投稿するサイト Command-line Fu を発見
一行野郎を集めるサイト。 Redditみたいに投稿したコマンドラインをみんなで評価しあえるようだ。 Command-line Fu < The best UNIX commands on the web Command-Line-Fu is the place to record those command-line gems that you return to again and again.
-
『クラウド化する世界』を読んだ
クラウド化する世界 著者: ニコラス・G・カー, Nicholas Carr Amazonで見る 最近のGoogleとかMicrosoftとかAmazonのクラウドの未来が知りたくて読んでみた。 実は、具体的なGoogle App EngineとかAmazon S3の話題に触れられているのかと思ったが、もっと全体の大きな流れを鋭く捕えていて良い意味で裏切られた。 (要約は[kiyoka.一言要約]に書いたので内容に興味がある人はそちらも見ておいてもらえれば嬉しい)
-
遊びという投資
共感する。これは最近思うところなんだよねぇ。 はてブコメントでは別の部分に対するコメントが多いけど。 小野和俊のブログ:IT企業の経営者として、不景気だとしても守り続けたいこと 3.「遊び」の部分を必ず残す これはこの半年ほどの反省点でもあるのだが、昨年夏から年末くらいにかけて、 開発チーム全体がリリースの関係で忙しく、それまで週に一度開催していた勉 強会をしばらく延期してしまっていた。 目の前にある、すぐに取りかかる必要のある仕事に対して優先的に対処するの は良いとして、どんな忙しい状況でも、週に一度の勉強会とか、今までと違う やり方を検討してみるとか、新しいバージョンの開発環境を試してみるとか、 仕事と直接関係ない開発や研究の成果を発表する場所を用意するとか、中長期 のプロジェクトへに取り組むとか、忙しい時や、不景気の時こそ、こうした 「遊び」の部分を意識的に日常の仕事の中に組み入れていく必要があると思う。 経済状況が逼迫すると、投資に及び腰になり抑制してしまう。 特に、仕事に直接関係無いことをウォッチしていくというのはなかなか難しい。 じゃあどうやればいいのか。 やっぱり基本はプライベートな時間を使うしか無いのかなと思う。(セルフパトロンシステムとか言うらしい) じゃあ、プライベートな時間が無かったらどうするか。育児とか家事とか大変。 今、私の悩みはそこなんだけど。 数年間は仕方ないかなと思っている。
-
Emacs 23をビルドしてみた。shell-modeの挙動が21と同じに戻った。
久々にEmacsネタを。 普段からよく使っている、shell-modeの挙動がEmacs 21時代に戻っている。 個人的にはこれだけでもEmacs 23を使う意味がある。
-
Jazzとかクラシックを聴いているけど実はミーハーだったりする件
Jazzとクラシックが好きで、その辺を中心に音楽を聴いているわけだが、ふと振りかえると実は趣味が超ミーハーなんじゃないか、と思いたった。 Jazzとかクラシックを聴くことは人によるとシブイ趣味らいしいのだが、実際はシブくなんかない。
-
『小さなインターネット』化に舵を切るmixi
インフォコモンズ Amazonで見る を読んだ後でこのニュース記事 「mixiを小さなインターネットに」 招待制・”18禁”廃止の狙いを笠原社長に聞く (1/2) を見ると正しい未来の方向に舵を切ったと感じられる。 今は昔からの古参ユーザに批判を浴びているが、数年すればあの時のオープン化の判断は正しかったと思えるようになるのではないか。 何年後かに、ああそういうことだっのねという風に。 オープン化することのユーザにとってのメリットはせっかくmixiで構築したソーシャルグラフをいろんなサービスにマッピングできるという事だろう。 例えば、Videoチャットの着信制限などを手っ取り早くmixiのマイミクから設定できるなどが考えられる。 もしオープン化しなければ、クローズドなSNSの限界と変化の乏しさが見えてどんどんオープンなSNSにユーザに移って行くだろう。 SNSのユーザが1000万人規模になってくると、本当に舵取りが難しいだろうなと思う。 mixiの初期から使っている人とユーザ規模が1000万人になってから使い始めた人のmixiに期待することは違うだろうし、もっと細かく言えばヘビーに人脈を広げるためにmixiを使う人と、リアルの知人だけで使うのが基本だと思っている人も期待することは違うだろう。 このへんで閉じたSNSからオープンソーシャルのプラットフォームに成ることでmixiユーザはみんなオープンソーシャルの世界に自然な形で移行できる。
-
一言要約に挑戦
一言要約は難しい [kiyoka.一言要約]というページでいくつかやってみた。 インフォコモンズ (講談社BIZ) 著者: 佐々木 俊尚 Amazonで見る 日本語が亡びるとき―英語の世紀の中で 著者: 水村 美苗 Amazonで見る Webでいい記事を見つけても、半年もすれば内容を忘れてしまってもういちど読むハメになるが、もういちど読むに値するかどうか短時間で判断したい。 というわけで、要約を残してみることにした。 やってみると分かるが、意外と一言(ワンセンテンス)に圧縮するのは難しい。 要約する際、著者の一番言いたい事を抜きだして他を捨ててしまうというような、かなり乱暴な行為であると思う。 受験用の国語の試験問題で、『作者がいいたかったことは次の3つの内どれか』という問題がよくあるが、作者に聞いてみたところ3つとも不正解ということが過去にあったそうだ。 特に、小説なんかだとそういうことは容易に起きることは想像に難くない。 なので要約する過程で作者の意図する所を外している可能性は十分ある。それでも自分がどう受け取ったかというのが結局自分にとっての正解なのであるからして、これで良いのではないかと思う。 一度皆さんも挑戦されたし。文章を深く読み込まないと要約できないので理解も深まる様に思う。
-
widen-window.elをインストール
widen-window.el ver 0.1.0 リリース - 日記を書く<・ _ゝ・>はやみずさん これは便利。さっそく使い始めた。 最近はこういうちょっとしたプログラミングで大きな改善ができるソフトがお気に入り。 [hayamiz]さんやるねー。 最近めっきり無くてはならない存在になった anything.elに続くヒット。 2008-05-13Emacs* anything.elの応用: よく開くファイルを検索対象にする方法 2008-04-23Emacs* anything.el is everything! こういう物をすばやく作る能力というのは実はプログラミングのセンスとユーザインタフェースデザインの総合的なスキルが要求される。 できあがった物を見れば『なあんだ』と思える様なものでもじゃあ自分でも着想出来たかというとそんなことはない。 そういうものを作れる人になりたいと思う今日このごろ。
-
ビル・エヴァンスのpianoの音
なぜピッチベンド機能の無いpianoで1/4音階が聞こえる気がするのか。 特にビル・エヴァンスのpianoからそんな音が聞こえる。 半音違いの鍵盤を同時に押さえているような気もする。メロディーの途中で、時間にすると一瞬だけどキャリーンという感じで重なるタイミングがある。 クラッシックでいうと、ショパンのpiano曲でも『別れの曲』などでそう聞こえる事がある。ピアニストにもよるのかも知れないけど。 何かの錯覚を利用しているのかな? このDVDを見ながら、改めて不思議だなあと思った次第。 Oslo Concerts 著者: Bill Evans Trio Amazonで見る 絶対マッコイ・タイナーのピアノからはそんな音は聞こえないものなぁ。 Jazzマニアがいたら理由を教えて欲しい今日このごろです。
-
世界金融危機とSF小説
昔から、SF小説では政治や経済は人類には手に余る問題なのでコンピュータに任せてしまおうという思考実験が行われる。 うまくいくか、いかないかの結論は作家の好みによって様々に分かれるけど、今回のサブプライムローンから始まった金融危機を見ていると、やっぱり人類の頭脳では扱い切れない問題なんじゃないかと思う。 今は無理だけど、将来はコンピュータに任せてしまう(もしくはかなりの部分サポートしてもらう)方がいいのではないかな。 久々に、そういう小説を読んでみたくなった。 コンピュータが『人類は滅ぶしかない』という結論を出してしまうパターンと、コンピュータと人類がうまく共存している様を絶妙に描写しているパターンの両方読んでみたい。 どんな小説があるか探してみようと思う。 多分これを現実逃避というんだろうけど、個人にできることはあまり無いと思う。 この時期にそういうSFを読むのも一興だろう。 他にも、日経平均ETFを買って値上がりを待って楽しむという方法もあるが、長期間低迷したらそれもしんどいので今回はパスしよう。
-
私が初めて買ったCD
最近音楽DVDを買いあさっているけど、思えば好みは変わってないなーと気が付いた。 高校生の時、初めて買ったCDは多分これ。いまだに聴いている。 Nothing Like the Sun 著者: Sting Amazonで見る もう20年弱も経っているのか。その後もStingのファンで有り続けている。 他にもこんなCDを買ったなぁ。 Porcelain 著者: Julia Fordham Amazonで見る Love Deluxe 著者: Sade Amazonで見る うわー、どれも今でも聞いているCDだ。 音楽の好みってあんまり変わっていかないものなんだね。
-
オープンソースソフトウェアの布教活動もライブが基本?
ミュージシャンの活動とOSSの布教活動の共通点に気がついた。 OSSを黙々と作っても、なかなか使ってもらえない。 その前にまず認知されるまでが大変。そこでライブの必要性が出てくる。 ミュージシャンがライブで新曲を披露するのと同じ。 OSS開発者もLightning Talk等のチャンスを使ってプレゼンする必要があるし、効果は非常に大きい。 実際に私も、Lightning Talk等をやった直後に実際にユーザが増えるということが過去に何度もあった。
-
革新的ソフトウェア企業の作り方
Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 Amazonで見る この本ではソフトウェア会社といっても、請負とかコンサルタント業とかSI業者は除外されるので注意。 なので、日本国内ではほぼ該当企業なしかも。 とはいうものの、趣味でオープンソースソフトウェアを作っている人にもいろいろ勉強になる所はある。(OSSをやっている本人も決してビジネスには成らないと思っているハズなので) 特に、マーケティングの章はOSSの人にも役に立つと思う。 勿論オープンソースの話は、オープンソースでソフトウェアビジネスをするのはかなり難しいという意味合いでしか出てこないが、自分で立ちあげたオープンソースプロジェクトの社会での立ち位置を再認識できるとおもう。(“会社での”ではないことに注意) ところで、オープンソースの周辺でビジネスをしている人は実際どうやっているんだろ。 私はオープンソースをメインにした企業(一般的にはオープンソース企業と呼ばれる)で働いた事ないので分からないが、それぞれの企業で何らかの工夫がもりこまれているんだろうなぁ。 一度、オープンソース企業を経営している人に秘密を聞いてみたい。
-
並列処理のプログラミングの未来は純粋関数型言語にある?
ゲームの世界でも、CPUのクロック数は頭打ちになりメニーコアの方向に行く。 処理速度を向上させる為には、沢山のCPUコアをいかに有効に活用するか(並列化)しかない。 最後には純粋関数型になるだろうととのこと。 ゲームプログラミング界の巨人、Tim Sweeneyが「未来のゲーム開発テクノロジー」を語る Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、将来的に ゲームプログラミングはそういった処理系に移行していくべきだとした。 Sweeney氏はそのひな形として言語“Haskell”を挙げているが、ゲームなどの 新情報を開発のメインストリームたり得る言語はまだ登場しておらず、将来に 期待しているという。 私も概ね同意する。スレッドプログラミングの複雑さは最後には人間の限界を超えると思う。(もう超えている?) 特に、画像処理やレイトレーシングなどの処理は副作用なしで記述しやすいプログラムの代表格だと思うので近いうちに関数型言語が主流になるんじゃないかと思う。
-
『実践Common Lisp』の著者の話
実践Common Lisp 著者: Peter Seibel, 佐野匡俊, 水丸淳, 園城雅之, 金子祐介 Amazonで見る 驚いた。 一番驚いた点は、本の構成でもサンプルコードのクオリティでもない。もちろん本はいいデキだ。 一番驚いたのは、『著者の親父がLisperで、著者は子供のころからLispの利点を刷りこまれていた』こと メズラシすぎる。 是非うちもやろう。今日からやろう。みんなやろう。
-
そろそろオレ言語でもやっておくか(4)
プログラミングとはどういうものかという本質論。 【プログラミングとはどういうものかという本質】とは何だと思いますか? (参考)http://q.hatena.ne.jp/1221708568 - 人力検索はてな ムズカシイ。 オレ言語を作ることを妄想してみると初めて分かった。そういう問題につきあたるのか。 最近話題になったなてなアンケート なかでも注目すべきこのコメント(投稿者practicalschemeさんはプロフィールのSchemer兼Actorという属性からshiroさんだと推測したのだけど) プログラミングに詳しい人に質問です。大学でプログラミング経験の学部一年生向けにプログラミングを教えることを想定しています。週1コマ×半年程度の限られた時間で、プ.. - 人力検索はてな 一部抜粋 xx言語を他人に勧めたいと思ったなら、印象以外にxx言語の何に着目してそう 思ったのか。その着目した点は他の言語には無いのか。他の言語に無いとした ら、何故他の言語はその点を採用しなかったのか。逆に他の言語にあってxx言 語に無いものについて、何故それはいらないと思ったのか。それらの価値判断 をひっくるめて、自分にとってプログラミングという行為はどういう意味を持っ ているのか。いくらでも考えを広げてゆくことができます。「『プログラミン グ言語について考える』ことについて考える」という問題は、その向こうに素 晴らしく豊穣な世界が広がっています。 なぜ、多くの処理系実装者が『オレ言語をデザインするのは大変なのでSchemeを言語仕様どおり実装しました』という結論になるのかという質問への答えにもなっていると思う。 オレ言語に手を出すのは楽しいけど、あまりにハードルが高いということだなぁ。 どうするかなぁ。
-
Gauche Hacksの構成の参考になる本の目次を晒しておく
Gauche Hacksのネタを考える時の参考にしよう。 [book.toc.PHPHacks] [book.toc.PerlHacks] [book.toc.SQLHacks]
-
昔のビョーク
育児中なので、赤ちゃんを抱っこしたままできる事というと、音楽DVDを見ること。 またまたビョークのDVDを買って、再生しっぱなしにしている。買ったのはこれ。 インサイド・ビョーク Amazonで見る ライヴ・イン・ケンブリッジ 1998 Amazonで見る
-
そろそろオレ言語でもやっておくか(3)
以前からRubyの構文を見たり、Gaucheのリファレンスマニュアルを見たりして妄想中。 こんな風に書ければいいなぁ。 注意:全体の構文の辻褄を会わせようとはしてません。雰囲気で希望だけを書いていっています。
-
そろそろオレ言語でもやっておくか(2)
オレ言語(いわゆるプログラミング言語を自作すること)構想の続き。 でも、いま育児真っ只中なので、実際に手を動かして何かを作る時間なんか無いのっ。 いまは片っ端から必要っぽい資料を読んでいるところ。 赤ちゃんは抱っこを止めた途端に泣くのでコンピュータに触ることはできない。 でも、本を読むだけなら赤ちゃんをだっこ紐でぶら下げたままでもできるもんね。 Webの資料も印刷すれば読める。 (そういえば小学校に置いてあった二宮金次郎の銅像を思いだした) というわけで、今回は完成イメージを紹介する。今後も変わっていくと思うけど。
-
そろそろオレ言語でもやっておくか(1)
オレ言語(いわゆる言語を自作すること)に興味が出てきた。 自分が実際に作ってみるという観点で有名どころの言語仕様とか言語設計者のプレゼン資料とかを見ると、なかなか素人には恐ろしく高い壁に見える。 特に、Rubyソースコード完全解説を読んだり、ニコニコ動画でトーク「幸せなRuby生活に必要なこと」を見たりすると、Rubyが様々なトレードオフの中でバランスをうまく取りながらできたシロモノだということがわかってくる。 そんなことはとりあえず置いといて、素人なりに何ができるかを探ってみるつもり。 まずは、1ヶ月間くらいはいろんな本を読むことに集中。
-
7月27時点のGauche trunkをビルドした
目的はparse.pegを動かすため。 以下に、手順をメモしておく。 (7月27時点のGauche trunk は 0.8.14 としてリリースされるハズのバージョンです)
-
パーサの勉強のつづき
パーサの勉強のため、本を読みつづけている。これも10年前位に買った本。 以前勉強していたのと、Schemeプログラミングをやって再起を理解する脳味噌ができあがっているためか、スラスラ読める。 昔は擬似コードを読む度にすごく時間がかかっていたのに… 不思議だ。 久しぶりに読んだけど、やっぱりいい本だと思う。 コンパイラ―原理・技法・ツール〈1〉 著者: A. V. エイホ, R. セシィ, J. D. ウルマン, 原田 賢一: 本 Amazonで見る パーサジェネレータはGauche trunkに入っているparse.pegを使う予定。 本当に自分が作りたいものがpegで出来るかどうかはまだわからないけど、いろいろ試してみよう。 参考資料は、これくらいしか見つからないけど、これで十分かも。 Rui:ParsingExpressionGrammar Parsing expression grammar - Wikipedia, the...
-
ビョークのDVD
ヴェスパタイン・ライヴ/ロイヤル・オペラ・ハウス 著者: ビョーク: DVD Amazonで見る ビョークはCDでかなり頻繁に聞いているのだが、このDVDを見てビョークの音楽の奥行の深さを知ることができた。 このライブに使われた楽曲の多くは、世界中の小さな音を大量に集めて、それを上手く混ぜ合せて音楽にしている。 例えば、椅子を人差指で叩く様なプツッっというような音や、トランプを机の上でコツコツと揃える音や、砂利の上をザクッザクッと歩く足音なんかがリズムに使われている。 ライブでは実際に砂利の上を歩いて音をマイクで拾っている。 オーケストラが途中入ってきても絶妙なバランスで両方の音を壊すことなく共存している。 音楽好きの人は一度は聞いてみてほしい。 また、音楽DVDにしては珍しくTSUTAYAでレンタル可能なので、何かのついでに借りて見てもらえればとおもう。
-
BOSE QC3を買った。クラッシックが楽しくなった。
早速試してみた。噂通り驚愕の性能だ。 音楽なしで電源を入れると、どんな雑踏の中でもプールに潜った時みたいに静寂が訪れる。 自分の心臓の音とか、関節の動く音とかが聞こえる。 BOSE QuietComfort3 ノイズキャンセリングヘッドホン そして、iPodにつないで音楽を再生すると、フルオーケストラの小さい音まで全部聞こえる。 早速、ウィーン・フィル演奏のラクリモーサを聞いてみた。 そんなに大きな音にしなくても細かいところまではっきりわかる。 凄いよーこれ。値段も凄いけど。
-
突然コンパイラの勉強を始める
10年前に熱心に読んだきり、本棚の肥やしになっていたコンパイラの本をひっぱりだしてきた。 昔、行実行プロファイラを作った時にC言語のパーサをひととおり書いたことがあるのだ。 その時にこの本を何度も読んだ。初めて読む本としても、実用的なものを作る時にもかなりオススメの本。 ところで、まだ売ってあるのかな? うわっ、amazonで買えないみたい。中古でなら10000円であるみたいだけど。 yaccによるCコンパイラプログラミング (C STEP UPシリーズ): 近藤 嘉雪 持ってて良かったー。
-
BOSE QC3を試す
うめだ阪急店 / セレクトショップ / Bose ボーズに行ってきた。 梅田でも、BOSE QC3を試せる店が出来たので行ってきた。
-
URLで取得したHTMLのタイトル文字列を取得する関数
[oldtype-mode]でURLをリンク書式に変換する機能をサポートした。 この関数はURLで取得したHTMLのタイトルを取得して、書式に埋めこんでいる。 といっても、HTMLの解析部分はw3mにおまかせ。 なぜならEmacsLispだけでは、到底実現できないからだ。 Net上に存在する現実のHTMLは、文字コードが多様すぎるのと、タグの対応がデタラメすぎるのとで、ロバストな処理を実現するのは不可能に近い。 こういう場合は外部のプログラムを使うのが一番。 ;; ;; *fetch command* ;; w3m -no-graph -halfdump -o ext_halfdump=1 -o strict_iso2022=0 -o fix_width_conv=1 URL ;; | awk '-F<' '/title_alt/ { print $2; }'...
-
Rubyの構文が柔軟すぎる(複雑すぎる)件
ちょっと思う所があって、Rubyの構文を調べてみた。 そんな中Rubyソースコード完全解説がWebで公開されているのを知った。 こんなものが公開されているとは…青木峰郎さんに感謝。 さて、話をRuby構文に戻す。 第10章 パーサのrubyの文法(概要)のあたりを読むと、すごいことが分かってくる。 以下引用 Rubyに存在するあらゆる構文は括弧で囲むと primaryになってしまう、即ちメソッドの引数にも代入の右辺にもできるということで ある。これはとんでもない事実だ。実際に確かめてみよう。 p((class C; end)) p((def a() end)) p((alias ali gets)) p((if true then nil else nil end)) p((1 + 1 *...
-
]
[perl.TMTOWTDIの謎を探る]について オリジナルは2002/05/10に書いた文書を[OldType]に移してリンク切れ等をメンテナンスした。 実は、このエントリはPerlの話かと思えば[Gauche]の話に終始している。Perl Loveの人はごめんなさい。
-
ルパン三世のJAZZ CD決定版を見つけた
私は、もともとJAZZピアニストは好きで、ビル・エヴァンスや、キース・ジャレットのCDはかなり持っているのだが、 Amazonを徘徊している間に、ルパンのテーマや挿入曲の作曲者がJAZZピアニストだったということを知った。 さっそく、大野雄二のCDの中で一番ルパンの曲が多く入っているこのCDを買ってみた。 これは当たりだよ。ルパンのタイトルが付いているCDが沢山ある中で迷ったらコレを選べばOK。 LUPIN THE THIRD“JAZZ” 著者: 大野雄二トリオ, 大野雄二: 音楽 Amazonで見る どの曲も原曲を聞いたことある曲ばかりなので、どうアドリブ展開しているかが分かりやすい。 かなり抑制され、落ちついた演奏で、アドリブもそんなに飛躍した部分は少ない。 JAZZを初めて聞く人にもオススメできるし、JAZZに詳しい人でも十分楽しめる内容だ。
-
文字コードを自動認識するgrepが欲しい
LVというフリーソフトウェアに複数の日本語エンコードを自動認識するlgrepというプログラムが付属している。 が、-r ( –recursive ) オプションをサポートしていない。 zshの “*/.java” 形式のワイルドカードを使えば -r を代用できるが、展開後のファイル数が爆発すると問題が発生する。 (1行の長さ制限に捕まると、エラーが出てgrepの実行前に止められる) Gaucheでgrepを書いてみようかなとも思うが、そこまでするほどでも無い気がするんだよな。 こういうのを許容時間内に書けるスキルが必要だなーと思う今日この頃。
-
Kansai.pm勉強会参加予定
久々に、Kansai.pmに出席してみる予定。 イベント/第9回ミーティング告知 - Kansai.pm 今回は人数多いよ。 Kansai.pm第9回ミーティング参加登録 私は、HadoopとMooseの話に興味があるので参加するんだけど、 いつもより多いのは、やっぱり伊藤直也さん効果かな? 久しぶりにKtatさんにも会えそうだし楽しみ。
-
『海辺のカフカ』
久々に村上春樹の小説を読む。 村上春樹の小説はほとんど読んでいるはずだけど、カフカはまだだった。 ところで、こんなに村上春樹の文体は極端だったっけかと思う。どんどん村上春樹のモノマネみたいになっているような。 実際的にもプラグラマティカルにも。 Amazon商品 Amazonで見る
-
ウェブ時代 5つの定理を読む
ウェブ時代 5つの定理 この言葉が未来を切り開く! 著者: 梅田望夫 Amazonで見る とにかく力をもらえる本だ。 プライベートな時間にコードを書くとか、デバッグするとか、いろんな事が面倒臭くなった時に読むと自然と力が湧いてくるんだよねぇ。 ロッキーのテーマを聞きながら腹筋すると軽々できる気がするのと同じ効果かも(笑)
-
図書館の本棚をMy本棚とすることの限界
私が読んだ本は、余程の事が無いかぎり図書館に寄贈している。 でも、そのやりかたでは梅田さんの様に本棚を前にして『自分の写し絵』を眺めることはできないなぁと思った。
-
Kahua 1.0.7.3 がリリースされた
Kahua 1.0.7.3 がリリースされた。 私の書いたコードも取りこまれた。 といってもGaucheではなく、Emacs Lispなんだけど。以下、Release Note の引用。 kahua.elにおいて、kahua-shell モードのバッファが表示されていない 時、kahua-shellにて評価された結果をミニバッファに表示するようになり ました。この機能は、Kiyoka Nishiyamaさんによって実装されました。 今後も、開発者のユーザビリティ向上にもっと貢献して行きたい。
-
「空気」の研究
日本人の気質について研究した本。 なぜ日本人が『空気』に支配されてしまうのかという事について、かなり踏みこんで解明しようとしている。 「空気」の研究 (文春文庫 (306‐3)) 著者: 山本 七平 Amazonで見る
-
anything.el is everything!
今更ながら、anything.el を使いはじめた。 すごいすごいとはいろんなブログで読んでいたけど、これは本当にすごいわ。 いままでバッファを切りかえる際、バッファ一覧を C-xC-b で出して C-xC-o してバッファ一覧からインクリメンタル検索していたのが、 C-; してインクリメンタルするだけになった。 これは、Emacsの標準機能になるのも時間の問題だと思う。 rubikitchさんところの2007-07-25 - ’(rubikitch wanna be (a . lisper))が参考になる。 ちなみに、私の設定はこんな感じ。これでどんな状態からでも C-;でanythingが起動するぞ。 ```lisp (iswitchb-mode 1)
-
おもてなしの経営学 アップルがソニーを超えた理由: 中島 聡
おもてなしの経営学 アップルがソニーを超えた理由 著者: 中島 聡 Amazonで見る WindowsとInternet Explorerの設計者の中島 聡の本だ。ブログはLife is beautifulが有名だ。 かなりの部分、ブログからの記事と対談が占めるが、全体として一貫して『おもてなし』の重要性についての話が綴られている。 中島さんのブログにUser Experienceに対する日本語が思い浮かばないと書いたところ、次のようなコメントが入ったそうだ。 User Experienceは『おもてなし』だと思っています。 なるほど、いい訳語だと思う。 私も、この本の『おもてなし』がこれからの時代に成功するプロダクトの要になるという意見には、賛成。 でも簡単に真似できないのが、この『おもてなし』であることも確か。 YouTubeにも関連動画がある。こちらも面白い。 YouTube - 3.11 中島聡×海部美知トークイベント02:『おもてなしの経営学』執筆について
-
My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド
My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド Amazonで見る タイトルからすると、もっと危機感を煽る本だと思ったが、そんな事はない。 現実的なアドバイスが書かれた、いい本だった。 でも、ベンチャー気質の人にはちょっと物足りないだろうと思う。 梅田望夫のように『これから、ベンチャーや個人の力が強くなる』というような未来の話ではなく、現在の多数の人に当てはまる内容になっている。 なので、それなりに大きな組織でプログラマとして働いている人は向いているだろう。 読んだ後のインパクトは強くないが、まあ納得感はある。 でもなぁー、やっぱり何か物足りない。 変化はそんなになだらかなではない気がする。 未来はもっと激しく変化するんじゃないかと思っているので、それに答え切れてない。 これを手始めにもっと他の本も読んでみよう。
-
Gaucheのsvnバインディング:調査編2
[kiyoka.2008_04_15]の話に続き、Pythonのbindingを調査してみた。 pysvn: Downloadsからダウンロードできる。中身を見てbindingを真面目に作るのは大変そうなことが分かった。 メソッド数が半端じゃない。 以下、psvn_client.cppのクラス定義部分の引用。 ```c++
-
Gaucheのsvnバインディング:調査編1
Version Control With Subversion 著者: Ben Collins-Sussman,Brian W. Fitzpatrick: 洋書 Amazonで見る をO’Reilly - Safari Books Onlineで読みながら、svnのバインディングの書きかたを調査中。 このブログにコメントを付けたいというのが、一番の動機。 本当は、svnコマンドをGaucheから子プロセスで起動すれば良いのだけど、 この本には、バインディングを書かないとちゃんとしたエラー処理はやりにくいよ、と書いてあったので 真に受けて調査してみている。 世間には、既にPythonとRubyのバインディングが存在するようだが、それにとらわれず、 Gaucheらしいバインディングが作れれば良いのだけど。 手始めに、もっと簡単なバインディングを書いて練習してみようかな。
-
Firefox 3 Beta 5にした
とりあえず気づいた点 ページをレイアウトする速度が速い ページ全体のズームがサポートされた 以下Mozilla Japan - Firefox 3 Beta 5 リリースノートからの引用 ページ全体のズーム: 表示 メニューとキーボードショートカットから、新しいズーム機能によっ てページ全体をズームイン・ズームアウトして、レイアウトテキストおよび 画像、またはオプションで文字サイズのみを拡大・縮小することができます。 ここでの設定はサイトごとに記憶され、再びそのサイトを訪れると復元され ます。 [OldType]でこの機能をJavaScriptを使って実装しようと思っていたが、やっぱりやめた。 ブラウザでサポートされるんだったらもういいや。
-
RESTベースの関数型言語ライブラリ
Tomcatハンドブック Amazonで見る を[Kahua]と見比べながら読んだり、ricollab Web Tech Blog » REST 入門(1 Web アプリケーションのアーキテクチャ)を読んだりした。 そうすると、なぜか頭の中で変な風に配線が繋がった。関数型言語でいうところの関数なら、1関数=1URLで表現できるんじゃないか。 RESTの基本はステートレスサーバ、つまりクライアントの状態をサーバーが管理せず、サーバが計算するために必要な全ての情報を毎回クライアントからもらう。 これって、関数型言語のimmutableな関数の考えかたじゃないか。 REST APIを数珠つなぎにすれば関数型プログラミングもできる。 RESTでSchemeの関数を実装した例 例えば、S式のリストをソートする関数は次のURLで実行できるとすれば、 http://func.example.com/lib/sort 次のようなコードが書けると面白いのでは? (use-rest-function "http://func.example.com/lib") (sort '(1 5 2 4 7 6 8 9...
-
関数型プログラミングの用語を使わずに関数型のメリットを説明する
この記事にはラムダ式というキーワード以外は関数型プログラミングの専門用語は出てこない。 第1回 ラムダ式 − @IT ##(thumb http://www.atmarkit.co.jp/fdotnet/csharp30/csharp30_01/csharp30_01_01.html) この記事で言いたいことは、『ラムダ式はリスト内包表記、高階関数と組み合せるとコードが驚くほど簡潔になる』という一言で表現できると思う。 ところで、川俣氏は関数型プログラミング言語でコードを書かれたことがあるんだろうか。 もし有るなら、確信犯的によく書かれた記事だと思う。 逆に、もし無いならかなりお気の毒な記事だと思う。さすがにプロのライターの方なので前者であると思うけど。 これくらい分かりやすい記事が書けないと仕事として成立しないんだなぁ。
-
不寛容な日本が進行
していると思う。日本の閉塞感と関係あると思うよ。もしかして日本だけじゃ無いのかしれないけど。 みんな余裕が無いんだよね。たぶん。 まずは人の事批判する前に自分の事やろうよ。 糸井さん、うまいこと説明しているね。 「屁尾下郎」氏のツッコミが世の中を詰まらせる (「公私混同」原論):NBonline(日経ビジネス オンライン) 村上龍氏も分かりやすい例を持ってきている。 YouTube - 村上龍X中田英寿 vol.5/5 世の中もっと寛容になったらいい
-
パラダイス鎖国
海部さんの本が出たので、早速買って読んだ。(後で、図書館に寄贈しときます) パラダイス鎖国 忘れられた大国・日本 著者: 海部 美知 Amazonで見る 日本国内のエンジニアが冷遇される問題や、国内ビジネスの鎖国状態について以前から興味があったので 海部さんのブログを追っ掛けていた。 関連エントリはたぶんこのリストで全部だと思う。
-
2冊同時読み:スーパーコンピュータ開発関連
最近、同種の本を2冊同時に読む様にしている。 間を空けずに、同時に読むと、比較できて楽しい。 (1)スーパーコンピューターを20万円で創る (集英社新書 395G) 著者: 伊藤 智義 Amazonで見る (2) 未来を予測する技術 (ソフトバンク新書 46) 著者: 佐藤 哲也 Amazonで見る
-
2冊同時読み:日本の雇用システムとモチベーション関連
最近、同種の本を2冊同時に読む様にしている。 間を空けずに、同時に読むと、比較できて楽しい。 (1)若者はなぜ3年で辞めるのか? 年功序列が奪う日本の未来 (光文社新書) 著者: 城 繁幸: 本 Amazonで見る (2)お金より名誉のモチベーション論 を刺激して人を動かす </a> </h3> 著者: 太田 肇: 本 Amazonで見る </div> </div> 有名な(1)より(2)のほうが、はるかに内容が上だ。 (2)を読むと、(1)が薄っぺらに思える。 (2)は日本人独特の屈折した承認欲求の心理からモチベーションを説明していて、非常に納得できる。 日本人コミュニティーのなかでは承認欲求がないかのように謙遜することが、実は最大の承認を得るための方法だと解説してある。なるほど。 それに比べて、残念ながら(1)では単に誰かを悪者にして愚痴っているだけに思う。 2冊同時読みは、1冊だけ読んだ時間に比べて、それぞれを客観的にちょっと引いた視点で読めるのでいい。 一つの意見を盲信する危険性が減る。おすすめの読みかただ。
-
Python 3.0について
Python Conference 2008 - Day1 — TRIVIAL TECHNOLOGIES 2.0より Pythonが目指す変化の方向性は,「よりコンパクトなコア」。誰が使っても「た った一つのすばらしい方法」にたどり着けるように,曖昧さを排除し,例外を少 なくしてハマりどころを取り除くことによって,よりながく,正しい方向に進化 しつづけられるはずです。 とうとうPythonも3.0で後方互換性を犠牲にしても進化するという方針を打ち出した。 PHP、Rubyは(多分)元から互換性をそんなに重要視していないし、PerlはPerl 6で後方互換性を犠牲にした。 最後に残ったPythonも例外では無かった。 コンパクトなコアという方向性は賛成。 Schemeが好きな私はコアはコンパクトで有れば有るほどいいと思うけど、あまりにやりすぎると、普及しずらい。 そのへんのバランスが重要だと思う。 Python 3.0ではそのバランスが調整されて良くなりそうな期待がある。 ところで、私はPythonのインデント構文は好きなので、SchemeのスキンとしてPythonライクな構文を採用するという妄想を捨てきれずにいる。 PythonとSchemeは水と油のような気もするが、だからこそPythonライクにすることでS式に抵抗がある人用のインターフェースとして機能するんじゃないかと思う。 Amazon商品 Amazonで見る Amazon商品 Amazonで見る
-
gauche.nightの感想
イベント全体の印象はS式一色。S式への愛が溢れたイベントでした。 LL関係のイベントではS式!S式!と叫んでいると、かなりaway感が醸しだされるんだけど、 gauche.nightではS式が正統派、S式でないとオカシイとまで思われかねないほどのS式傾倒ぶり。 オライリー本 Amazonで見る が出たことに対する皆の喜びもいったんかんのある空気の中に感じられた。 それと、Shiroさんがイメージ通りのいい方だったので安心したよ。 少しづつGaucheがメジャーになってくれることを願う一日だった。 これからも私は[OldType]をハックしながら、Gauche/Kahuaの発展に貢献できればと思う。
-
第二回gauche.nightに出演してきた
第二回gauche.nightに出演してきた。
-
Schemerにとって理想のRubyとは(2)
[kiyoka.2008_02_25]の続き。 Rubyにnamed letみたいなのが欲しい 再起でレキシカルアナライザが自然に書けるよ。 def lexer( f ) tokenList = * * let loop { |ch = f.readchar, prev, token = ""| case ch when f.eof? else # トークンの蓄積 case...
-
Schemerにとって理想のRubyとは(1)
Schemerはこんなコードを書きたいと思うはず。defとlambdaは同じであるべきだ。
-
見ため重要、マーケティング重要
この記事は必読。デベロッパーズ・サミット2008で講演するジョエル・スポルスキー氏の講演 すばらしいソフトを作るには、カリスマが講演 − @IT ##(thumb http://www.atmarkit.co.jp/news/200802/14/joel.html) 私が以前から思っている事を分かりやすく言ってくれている。 そう、『見ため重要、マーケティング重要』 技術が凄い、深いっていうだけでも分かる人には分かる。でも、分かる人は少ない。 そのソフトウェアはコミュニティーが濃いので価値は高いという考えかたもある。 でも、それだけではNo1にはなれない。ここではNo1とは知名度、ブランド、マインドシェアで見た場合のNo1の事を指す。 RubyとかRuby on Railsはそのへんうまくいっている例だと思う。 Rubyは楽しくプログラミングするというマーケティングがうまく成功している。 Ruby on Railsはかっこ良さと生産性の高さがうまく合わさって(必要以上に)うまくいっている。 [Sumibi.org]はそのへんマーケティングとかにはかなり頑張ったんだけど、[OldType]でも頑張ってみる価値アリだと思った。
-
Gauche 0.8.13リリースがされた
Gauche 0.8.13がリリースされた。 私としてはこれが一番うれしい。Gauche:Translationより 本体の改良点 apply での引数の扱いが改良された。以前は引数リスト中の各引数をすべて VM スタック上にプッシュしていたため、VM のスタックに載らない長い引数 リストを apply すると失敗していた。現在は、引数リストを必要なだけ展開 する。これにより、ほとんどすべての場合で引数リストの長さが無制限になっ た。例えば次のようなことができる。 (apply list (iota 50000)) 実は、[OldType]のバックエンドにはGauche付属のsxmlライブラリを利用していて、巨大なXMLノードを突込むと VM stackが足りないというエラーが出ていたのだ。 仕方が無いので、[OldType]のサイトではGauche 0.8.12の vm.hのスタックサイズを10倍にして運用していた。 これで、変なパッチを当てなくて良くなるよー。うれしい ^_^。 Kahuaの最新版と一緒には使えないので、Kahua側で対応したものがリリースされるまで待ちだね。 参考リンク [http://mlarchive.kahua.org/mlarchive/kahua-dev/msg01366.html|[kahua-dev 1367...
-
Ruby1.9とVMの状況
最近Rubyの1.9とVMの情報を追いかけて無かったので、ささださんのプレゼンを探して観てみた。 LingrでささださんとshiroさんがVMの最適化について議論されているのを読んで興味が出たのもキッカケになった。 ちょっと古いけどRuby会議2007の時のプレゼンだ。 日本 Ruby 会議 2007 プログラム / Ruby 1.9実装の現状と今後 1/3 日本 Ruby 会議 2007 プログラム / Ruby 1.9実装の現状と今後 2/3 日本 Ruby 会議 2007 プログラム / Ruby 1.9実装の現状と今後 3/3...
-
最もタメになる「初心者用言語」はScheme!
これおもしろいね。 日記を書くはやみずさん:最もタメになる「初心者用言語」はScheme! 半分ネタ、半分本気な空気感がいい。 この部分は本気で共感出来るよ。 Schemeは勉強したがりなみんなの見方だね!
-
Dave Thomasの講演を観て思ったこと
この有名な講演を、Gaucheユーザから見て思うことを中心に。 プログラミング関連のブログをグルっとひと巡りしてみるとRubyを愛している人は多いことに気づくだろう。 この講演の中で、(Haskell and Ruby) or (Ocaml and Python) という話が出てくる。 真中が ‘or’ ではなく ‘and’ の人は少数で、これは何でだろうという話。 Dave Thomasは、これはペットの趣向で例えると犬派、猫派が有るようなものでRuby派、Python派が有ると説明している。 なんか分かる気がする。 さて、無理矢理ここにLisp系を入れてみよう。 『(Haskell and Ruby) or (Ocaml and Python) or (CommonLisp and Scheme)』(笑)...
-
『プロとアマの垣根』について
決断力 著者: 羽生 善治 Amazonで見る を読んで。 NHK プロフェッショナル 仕事の流儀では無いけれども、『プロとアマの垣根』について触れている。 以下第五障『才能とは、継続できる情熱である』より引用。 将棋の世界にかぎらず、今、プロとアマの垣根が低くなっている。 (略) プロらしさとは何か?と問われれば、私は、明らかにアマチュアとは違う特別なものを持っており、その力を、瞬間的ではなく持続できることだと思っている。 私が大事にしているのは、年間を通しての成績である。 (略) どの世界においても、大切なのは実力を維持することである。 そのためにモチベーションを持ち続けられる。 地位や肩書は、その結果としてあとについてくるものだ。 逆に考えてしまうと、どこかで行き詰まったり、いつか迷路にはまり込んでしまうのではないだろうか。 そういえば、Shiroさんも同じことを書かれていた気がする。以下引用。 プロとアマの違いは何だろうかと時々考えるのだけれど、ひとつ確実に言えるのは、プロはどんな場合でも仕事の質がある下限以上であることが期待されているということだ。 フィールドによっては、アマチュアがプロよりも良い仕事をする場合がある。 ただ、それは上のピークを見た場合。どんな人でも長く続けてれば波はあるもので、プロかどうかを分けるのは山の頂きではなく谷底の標高が一定の高さをクリアしていることではないかと思う。 納得。 持続するためには、仕事が好きでないといけないということがある。 しかし、好きなことでも続けてやっているとそうでもなくなってくるし、好きな対象も知らず知らずのうちに徐々にシフトしていく。 私は仕事ではそんなに超絶技巧は要求されないので(逆に言うと、チャレンジングな技術使用を許可されにくいので)、それだけやっているとモチベーションが維持できない。 そこで、プライベートでは自分が本当に面白いと思った技術で遊んだりしてバランスを取っている。 その遊びは、結果的に理論や概念の部分で、役に立ったことが多い。 そんな工夫をしながら仕事のパフォーマンス安定性とモチベーション維持を両立するのはプロとしての務めではないかと思う。...
-
『決断力 (角川oneテーマ21): 本: 羽生 善治』を読んで
読んだのはこの本。 決断力 (角川oneテーマ21) 著者: 羽生 善治: 本 Amazonで見る ウェブ時代をゆく ─いかに働き、いかに学ぶかの梅田 望夫さんがよく羽生さんのことを書かれているのでその関連で読んでみた。 この本が書かれる前に、『高速道路論』という言いかたがされていたかどうかは不明だが、それに通じる話が沢山でてくる。 将棋に限らず、一生勉強すべき職業に就ている人は参考になるに違いない。プログラマも同じだと思っている。 ちょっと引用してみる。 第四章『「選ぶ」情報、「捨てる」情報』より 私は、今の時代は、いろいろなことが便利になり、近道が非常に増えた時代だと思っている。 何かをやろうと思った時に、さまざまな情報があり、安易な道、やさしい道が目の前に数多くある。 楽に進める環境も充実している。 昔は遠い、一本の道しかなかった。 略 しかし、遠まわりをすると目標に到達するのに時間はかかるだろうが、歩みの過程で思わぬ発見や出会いがあったりする。 略 自分の力で吸収した考える力とか未知の局面にであったときの対処の方法とか、さまざまな事を学べたと思っている。 私は、自ら努力せずに効率よくやろうとすると、身につくことが少ない気がしている。 近道思考で、簡単に手に入れたものは、もしかしたらメッキかもしれない。 メッキはすぐに剥げてしまうだろう。 最近関数型言語をやっていて、理論的側面が不足しているせいで、なかなか答えに辿りつけないことが多い。 手続き型プログラミングの世界では、騙し騙しコードを書くことができるが、関数型の場合はそうはいかないことがある。 モナドや、継続をベースとするAPIがあったりした場合、理論的背景が分かってないといくらドキュメントやソースコードを読んでも自然に分かったりしない。 毎日コツコツ勉強を続けて行くことで、『未知の局面』が来たときにも、解決方法が思いついたり、前に苦労してつかんだ理論が応用出来たりする。...
-
] will never be A Ghetto.
スラッシュドット ジャパン / Ruby on Railsはゲットーだを読んで。 TechCrunchの記事Zed Shaw Puts The Smack Down On The Rails Communityも参考に。 Zed Shaw氏の原文はちゃんと読んでいないけど、Ruby/Railsコミュニティーからはもう手を引くとのこと。 要するにPHPコミュニティー見たいに『A bunch of half-trained former PHP morons』が押し寄せてきてひどい状況になっているということらしい。 私もちょっとの間PHPメーリングリストを読んでいて、質の低さにウンザリした記憶があるので多少は納得できる。 一方の[Kahua]コミュニティーには、良くも悪くもS式暗号(過去のkiyoka日記より)という高い参入障壁があるので、そうは成りそうにない。 要はバランスで、WebフレームワークのコミュニティーにはPHPコミュニティーからSeaside.stコミュニティーまでいろいろあるが、ちょうど中間地点がいいと思う。 [Kahua]はどちらかというと、Seasideよりだと思うので、もうちょっと中間地点側に寄せた方がいいと思う。 どうやって寄せるかは、キラーアプリを作って見せるのが一番だが、言語がSchemeだということもあって、それだけでは駄目なのかも知れない。...
-
flymakeでPHPのリアルタイム文法チェック
ブログではいつも関数型言語の記事ばっかり書いているが、実は仕事ではPHPを使うこともある。 言語は自分では選べないというのはITの世界ではもはや常識である。 言語選択の自由を唱えるRubyのまつもとさんでもその辺は御存知でしょう(笑) というわけで、少しでもPHPの開発効率の悪さを軽減すべく、flymake modoの設定をおこなってみた。
-
kahua.elに機能追加した
kahua.elの改善パッチを[Kahua]プロジェクトのメーリングリストに送った。 久々にオープンソースプロジェクトにコードをフィードバックした。 オープンソースを自分の作りたいものに利用させてもらっているのでもっと貢献しないとね。 もっと[Kahua]フレームワーク本体も改善したい所があるが、ちょっとレベル高いので手が出そうにない。 今一番欲しい機能は、高階タグでエラーが出た時にバックトレースを表示してくれる機能かな。 [Kahua]はまだまだデバッグの為の機能が不足している。
-
quack.elのλの字形が気にいらないので変更した
quack.elの defconstを次の様に変更するとよい。
-
Haskellも面白そう
LiveCoding#5に参加して、実際にHaskellをコーディングしている所を見るとHaskellも面白そうに感じた。 コーディングをしてコンパイルが通ればほぼ動く、型安全なプログラミングというものを体験してみたいと思った。 私は実際にHaskellで実用的な物を作った事が無いのでまだ、Haskellの良さが分からないレベルだ。 日本語処理に問題があるとか、ライブラリが足りないとか処理系はまだまだこれからと聞いているが今からやっとくのもいいだろう。
-
バベル17を読む
『バベル17』(Amazon.co.jp)を読んだ。 出版された時期を見るとかなり古く、1977年07月だそうだ。 私は図書館で借りて読んだが、ページが色褪せ、茶色がかっている。 自然言語を題材にしているせいかストーリーは全然古くなっていなくて驚く。 ただ、コンピューター言語への喩えとして『フォートランかアルゴルの様だ』というくだりを読むと、さすがに書かれた時期が分かって良い。 ネット上にわかりやすい書評 BABEL-17 を見つけた。興味を持った方は読んでみては?
-
LiveCoding#5に参加した
LiveCoding#5に参加した。参加と言ってもオーディエンスとしてだけど。 oxyさん凄かったね。C++のコード書くの早っ!『世界』を見れた気がする。 次回はLiveCoderになれる様にネタを考えておこう。 見栄えのするプログラムが作れた方が良いのでJavaScriptとかを練習しとくかな。 そうそう、こういうイベントで実際に手を動かして何かを作りだしている人達から創作の力をもらう事が多い。 関西でもこういうイベントを企画してくれた氏久さん(rubyneko)に感謝。
-
『ボナンザVS勝負脳―最強将棋ソフトは人間を超えるか』を読む
ボナンザは[Sumibi.org]と同じ機械学習を使った将棋ソフトウェア。 この本ではプロ将棋棋士の渡辺 明氏との対談もあって非常に面白い。 ボナンザVS勝負脳―最強将棋ソフトは人間を超えるか (角川oneテーマ21 C 136) 著者: 保木 邦仁,渡辺 明: 本 Amazonで見る 保木さんの開発秘話の様子は、私にとってすごく親近感がわいた部分だった。 私が[Sumibi.org]を開発している最中に、SumibiがWikipediaの文章食って毎日賢くなって行くのを見て 驚き、興奮していた自分に重なる所が沢山ある。 自分が作ったものが自分の理解を超えて賢くなっていく様は見ていて本当にワクワクするものだ。 この本はそれが伝わってくる貴重な本だと思う。 渡辺 明氏のプロ将棋としての将棋との向き合いかたも純粋で心打たれる。 この本には二人の『Just for fun』が溢れていると思う。
-
今更ながらDynamicMacro
第14回 繰り返しの効用 | WIRED VISIONを読んだことがきっかけで、今更ながら増井さんのDynamic Macroをインストールした。 結構いいね。これでいちいちキーボードマクロにキャプチャーする操作が減りそう。 こういうインターフェースものは作っていても使っていても楽しい。
-
bashで高階関数のアイデア
bashで高階関数が使えたらどんだけプログラミングが楽になるか。最近そう考えるようになった。 欲しい高階関数は、こんな感じかな。
-
全生物の8割が昆虫、全プログラムコードの8割がループ
『全生物の8割が昆虫』これは事実かどうかは不明だが、よく言われる。 『全プログラムコードの8割がループ』は私が勝手に作った言葉だ。 最近、業務向けアプリケーションのコード(JavaとかPHP)を読むことが多い。 関数型スタイルのプログラミングに慣れた脳味噌で見るとほとんどがイテレータを回すループだと気づいた。 特に、コレクションやリストなどを操作するループが至るところにある。ループ、ループ、ループのオンパレード。 さらに、残念なことにイテレータのインスタンスやループ変数の宣言もループの数だけある。 全て高階関数に置き換えたらどんなに読みやすく簡潔になることか… 未来のC#、C++、Pythonが関数型スタイルをサポートする様だが、そうすれば業務向けコードの風景も様変わりしていくのだろうか。 個人的にはそう思う。 後はそれをどのくらい早めることができるか、かな。
-
音楽産業と日本のテレビ放送業界
TechCrunch Japanese アーカイブ » YahooのIan Rogers、音楽産業に苦言― 「不便の押し付けはいいかげんにしろ」 最後にIanは音楽産業の現在の欠陥だらけのビジネスモデルをこれ以上サポートする気はないと断言した。 私はYahoo!にもうこれ以上ユーザーに不便をかけるだけのサービスには投資 させないつもりだ。私はYahoo!本社に、すばらしいメディア・アプリケーショ ンを作るための予算はもっと後にとっておいて、今はYahoo!Mailとか Answersとか役に立つ事業に投資したほうがいいと勧める。私自身の見解と しても、消費者の利益を無視して自分勝手な制限を課そうとするような試み にこれ以上付き合う時間も予算もない。人生は短い。私は消費者に喜んでも らえるようなサービスを作りたい。消費者をコケにするような仕事は御免だ。
-
WIRED VISION / 「ゲーマーの後悔」は終わらないを読んで
たしかにゲームを長時間した後の後悔は大きい。 私は、それが怖くて10年ほどRPGなどの時間がかかりそうなゲームはやっていないし、据置型ゲーム機も一台も持っていない。 ちょっと寂しい人生のような気がしないでもないが、結果としてその時間をオープンソース開発にあてることが出来たと勝手に解釈している。 オープンソース開発に使った時間は膨大だが、なぜか後悔しない。 それはなぜか。 オープンソース開発も複数の人間でコラボレーションして或る種のゲームのような楽しさも持っている。でもゲームでは無い。 この記事に答えに近づけるヒントがある。( WIRED VISION / 「ゲーマーの後悔」は終わらないより引用 ) クロスワードパズルの専門家、Will Shortz氏は以前、人が紙とペンを使うパ ズルを愛する理由は、「人生には答えが1つではない問題が山ほど存在するが、 クロスワードでは答えは1つと決まっていて、それを見つけ出すことができる からだ」と私に話したことがある。だが、クロスワード中毒と同様、ゲームが 終わった後、われわれに何が残されるのか?達成感だろうか?確かにそれはあ るだろうが、われわれが成し遂げたことは、この上もなく独断的で、非生産的 な仕事でしかない。ゲームが終わったときに私が感じる喜びにはいつも、少し のむなしさが付きまとうもっと生産的で、難しくて、やりがいがある何かをし た方がよかったのではないか? オープンソースソフトウェア開発が後悔しない理由を一言で言い表すとこういうことかなと思う。 『ゲームはあらかじめ誰かが答えを用意してくれているが、オープンソース開発のようなものづくりには答えは用意されていない。』 つまり、自分が通ってきた道がありふれたものか、それとも自分だけのものかという事ではないかと思う。 そんなわけで、オープンソースソフトウェア開発はやめられない。
-
配列ベースプログラミング言語「ざぼん」
趣味的にっき - 配列ベースプログラミング言語「ざぼん」より LispにS式があってマクロがあるように。 Rubyの配列を使ってプログラミング言語を書いてみました。Ruby本体を使ってプログラム(= 配列)を操作することで、Lispのマクロのようなことができます。言語の名前は「ざぼん」です。「ざ」をいただきました。
-
RubyかHaskellのバイリンガルが迷うとき
sshi.Continual - 「同一のもの」をつかんだ気になれる記述ができるかどうか?より rubyとhaskellを双方手足のように扱える人にとって、ある問題を解くときにrubyで書くかhaskellで書くかを選ぶ基準を考えてみると思考実験になるだろうか? (略) 双方を使えるんだから、その人は双方の脳内モデルのスイッチはできる。ではその人はその問題をどちらで解こうとするのか? 個人的にはある問題、作ろうとしているプログラムを考えた時に、「あ、これはRubyのほうが書きやすそうだ」とか「あ、これはhaskellだと楽だな」とか思うことはある。 これを読んで思いだしたが、OnLisp読書会に出た時に、同様にRuybとHaskellのバイリンガルな人がけっこういた。 どちらも一部では流行の言語ではあるが、理由はそれだけでは無いだろう。 それぞれ、オブジェクト指向と関数型の脳内モデルをコードで表現するのには現存する言語では、おそらく一番理想に近い言語だと思う。 OCamlのユーザーとGaucheのユーザーは、それには同意せず、これ一つだけ覚えればOKだよというかも知れない。 私もそのGacuheユーザーの方だ。 もっとも、Gaucheでコードを書いている間も、局面次第で手続き型、オブジェクト指向型、関数型の脳内モデルをスイッチしているわけではあるが。 Ruby+Haskellの二刀流とGaucheの1刀流と最終的にどちらがパフォーマンスが良いのかに興味がある。 もっとも、人生は1度きりなので両方経験することはできないんだが。
-
RubyのリハビリでFizzBuzz問題
同僚からRubyの質問を受けることが多くなりました。 というわけで、RubyのリハビリがてらにFizzBuzz問題をやってみました。 ええ?Rubyに見えないって? Ruby on Railsやる人はこれくらいのコードは書けないといけないようです。^^ P.S. 関係ないですが、それにしてもtDiaryのソース貼りつけは落とし穴いっぱいですね。空行はダメなんですね。ちょっとハマりました。
-
Schemeのlambdaがようやく分かってきた
なんでもλを前に何度も読んだけど、自分のモノになってなかったようです。 最近、named letと継続渡しオンパレードなWiLiKiのパーサをいじることで、ようやく全部同じだという感覚が掴めました。 何なんでしょう。こういう質の高いチュートリアルを読んでも掴めなかった感覚が実際に自分でやってみると掴めるというのは。 なんでも経験ですね。 誰か『なんでも経験』ていう文章書いて下さいませ。
-
On Lisp読書会#1に参加した
On Lisp読書会#1に参加しました。 新しい隠れLisperの方は見つかりませんでしたが、これからLisperになりそうな方はいらっしゃいましたよ。個人的にはGauche本が出ればLisperが増えそうな予感です。(ちなみに、以前からLisperだった方は一人来られてました。) ところで、Extreme Readingはいいですね。一人で読むよりもいろいろな疑問点が挙がるので勉強になります。 今回の収穫は『複数言語を扱うメンバーの共通語(公用語?)はRubyが良い』こと、『Rubyの関数をfirst classにしたければ lambda で関数定義すればいい』こと、『関数型プログラミングのメリットは体験してみないと本の説明だけでは伝わりにくい』ことです。 特に、最後の件はSumibiの開発を例に補足させてもらいました。 興味のある方は是非次回から参加してみて下さい。もちろん、私は次回も参加する予定です。 追記: 中本さんがまとめをブログ記事にされています。ありがとうございます。本当に助かります。
-
On Lisp読書会#1に参加する予定
On Lisp読書会#1に参加します。日程は8月19日(日曜日)です。 関西の隠れLisperを探しに行くという別の目的もあります。 On Lispを持っているけど読めてない方は参加してみてはいかがでしょうか。
-
一つの言語を習得しても,やはり他の言語を学ぶのは難しい
一つの言語を習得しても,やはり他の言語を学ぶのは難しい - カレーなる辛口Javaな転職日記 言語を知らない人ほど「井の中の蛙」になりやすく,「他の言語は簡単にマス ターできる」なんて暴言を吐くのではないだろうか.
-
スクロールリングの回転方向はどっちが標準?
iPod nanoをもらった事がきっかけで自分が ケンジントンのトラックボールのスクロールリングの回転方向とは逆だと気が付きました。(実は私がデフォルトとは逆の設定に変更したのです) iPodは時計回りにリングをなぞるとカーソルは下方向に動きます。 iPodは設定変更できない様なので、ケンジントンのトラックボール側をiPodと同じ回転方向に戻しました。 この回転方向の標準って有るんでしょうか。 iPodがこれだけ普及している今では、『iPodの時計回りが下方向がデファクトスタンダード』と言い切っても問題無いのかも知れませんね。 ケンジントン
-
Lisperとそれ以外の人とが見ているものの違い
このイメージよく出来てます。 そうなんです。 まわりの non-Lipserと話しをするとみんなこんなイメージを持っているようです。括弧ばっかりやん。と。 でも、いつのまにか括弧は見えなくなります。(↑のイメージと同じように括弧が薄くなる感じ) なので、PythonとLispの両方をやっている私にはPythonのコードとLispのコードはかなり近い見た目に思えるのです。 LispをやったことないPythonプログラマの方がいらっしゃったら、この意見に賛成されるんでしょうか。その辺が知りたいです。
-
『マーケティング10の大罪』再読
マーケティング10の大罪 著者: フィリップ・コトラー, 恩蔵 直人, 大川 修二 Amazonで見る 二回目流し読みしました。 自分のためにも十戒をメモ。本書曰く、壁に掲げておけとな。 これは、オープンソースプロジェクトでも実践可能なのでは。 というより、ビジネスになる前のオープンソースプロジェクトであっても、マーケティングは必要だと思います。 フィリップ・コトラー:マーケティング10の大罪 マーケティングを通じて高い生産性と収益性を実現するための十戒 市場を細分化し、最も好ましいセグメントを選択したうえで、各セグメントにおいて確固たる地位を築くべし。 顧客のニーズ、知覚、選好、行動を明確に把握し、すべての関係者が顧客への奉仕と顧客満足のために邁進するよう動機づけよ。 主要な競合他社の動向を把握し、相手の強みと弱みを把握せよ。 関係者の中からパートナーとなるべき相手を見出し、手厚く扱うべし。 機会を見出し、機会に優先順位をつけ、最も優れた機会を選択するためのシステムを構築せよ。 マーケティング計画を策定するためのシステムを管理し、長期的にも短期的にも優れた計画を立案せよ。 製品ミックスならびにサービス・ミックスを厳しく管理せよ。 もっとも費用対効果に優れたコミュニケーション・ツールとプロモーション・ツールを活用して強力なブランドを構築せよ。 企業はマーケティング部門にリーダーシップを発揮させ、マーケティング部門と他部門がチームとして行動するように働きかけよ。 競争優位性の源泉となるテクノロジーを継続的に導入せよ。
-
『誰のためのデザイン?』を読む
誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書) 著者: ドナルド・A. ノーマン, 野島 久雄, D.A. ノーマン Amazonで見る 読み終わりました。 1990年に出版された本なんですが、古さを感じない本です。 マウスの説明とかがあったり、Internetがこのまま広がれば、データが増えつづけてほしい物が見付けだせない悪夢の時代が来ると予言されています。Googleなんてものが登場する前の本ですので。それ以外は全く古くなっていません。 この本を読むと、いかに世の中の電化製品や電気のスイッチなどのデザイナがユーザビリティをないがしろにしているかを思い知らされます。 この著書で問題提起された後も、世界は良くなっていないばかりか逆に悪い方向に向かっている気がします。 近年の家電に内蔵されているコンピュータの性能は上がり続け、さらに開発言語も生産性が上がり続けています。その結果、簡単に機能てんこもりの製品が出来てしまいます。 挙句の果てに、簡単なことも簡単にできない、マニュアルを見てもよく分からないというような事態が日常茶飯事です。 この本をじっくり読んで、丁寧にユーザービリティの高いものを作るだけで一歩抜きんでたものができそうだと感じる方も多いはず。 さて、ユーザビリティが高い製品が評価される時代はやってくるのでしょうか。
-
creativeよりuseful
毎度の事ながらリアルタイムには反応できませんが、弾さんのエントリーより。 404 Blog Not Found:creativeよりuseful 誰でもcreativeになれるが、誰でもusefulになれるわけではない。そして私自 身も含めて、人はusefulなものにしか代価を支払わない。「頭がいいのに成功 できない」ただ一つの充分な理由が、これ。いくら頭のいい解決法でも、他者 がそれを使えなければ、それは文字通り「使えない」のだ。
-
ユーザビリティに関連した本
id:bokuno-nouさんからトラックバックをもらったので記事を読みました。 その記事に掲載されている『誰のためのデザイン?』という本が気になったので、毎度の事ながら図書館で予約いれときました。 誰のためのデザイン?―認知科学者のデザイン原論 著者: ドナルド・A. ノーマン, 野島 久雄, D.A. ノーマン Amazonで見る 最近コードを書かずにアイデアをメモしたり本を読んだりという事ばっかりしていますが、いつか絶対元が取れると信じて学習を続けています。 id:bokuno-nouさんの記事でハッと気づかせて貰ったのは、50%ルールの事です。 今CMSをデザインしているところですが、うっかり最初から完璧な物を作ろうとしすぎている自分がいます。 もうそろそろ、作りながら軌道修正していくいつものパターンに入ったほうが良いかなと思いはじめています。
-
『考える方法―解決の思考・創造の思考・思考なき思考』を読む
ゴールデンウィークに読みました。Amazonランキングで見てもあまり売れていないため、あまり知られていないと思いますが、いい本なので紹介します。ちなみに著者は、『負のデザイン』を提唱している森本武氏です。 『考える』ことについて、ありとあらゆる方向から、ノウハウや技術、さらには人間の思考の限界、思考なき思考まで分かりやすい文体で綴られています。思考なき思考の章に至っては、宗教的とも哲学的とも思える心理描写でありながら宗教を肯定しない希有な本です。 創造的な仕事の中に喜びを感じる人、創造的な人を目指す人に読んでほしい本です。
-
ソーシャルウェア・ユーザビリティ
一人で使う時のソフトウェア・ユーザビリティよりもコミュニティーで使う時のユーザビリティ、つまりソーシャルウェア・ユーザビリティの感覚が求められる様になってきたというおはなしです。 小野和俊のブログ:ソーシャルウェア・ユーザビリティ これまで長い期間に渡って、ソフトウェアは一人で使うためのものだった。 ここで言う「一人で使う」ということの意味は、自分以外にも家族も使うかど うかというような意味ではない。例えばテキストエディタは他の PC の前に座っ ている誰かとリアルタイムで共同編集するものではなかったし、ゲームはネッ トに接続せずに自分一人で遊ぶものだった。そういう意味でソフトウェアはこ れまで長い期間に渡って一人で使うためのものだった。 だからこれまで私たちは、ユーザビリティのことを考えるとき、まず自分が一 人で使うときに使いやすいかどうかを考えてきた。 従来のユーザビリティをソフトウェア・ユーザビリティと名付けるとすれば、 ここ数年で、もう一つのユーザビリティとして、ソーシャルウェア・ユーザビ リティとでも呼ぶべき感覚が求められるようになってきているように感じる。
-
OSSのプレゼン資料はブログ記事を整理するだけでできる
私の場合、日々感じた事、それによって、出てきた疑問や問題を解決する過程の記録としてもブログを使っています。 『何が問題か?解決方法は?そのポリシーは?』という感じで日々メモしているため、作ったソフトウェアのプレゼン資料を作ろうと思い立ったら、そこからは案外短時間で完成まで持って行けます。 そうすると、プレゼン資料はブログ記事の寄せ集めなので、ブログを読んでいる人からすると繰り返し同じことを聞かされていることになるのでは?という心配もごもっともです。 しかし、幸か不幸か実際のプレゼン当日のオーディエンスはブログを読んでいる人とオーバーラップしないので問題ありません。 オープンソース開発をやっている人は、ブログで自分の動機や問題点と解決策を恥ずかしがらずに書いておく事をおすすめします。 ほとんどの記事が手前味噌に成りがちで、なんと厚顔なと思われる事を書く必要があるので抵抗がある人もいるかも知れませんが、『そんなに大量の人が読んでいるわけではない』と思えば書けるものです。 ブログは文字どおり日々のログを、プレゼン資料で振返り・まとめをという位置付けです。
-
イノベーション=エンジニアの士気
本 『フラット化する世界(下)』を読む フラット化する世界(下) 著者: トーマス・フリードマン Amazonで見る フラット化する世界(上) に続いて下巻 Amazonで見る も読み終わりました。上巻から時間が空いてしまいました。図書館の予約待ちは長いです。 Amazonで見る さて、下巻のキーワードは『無敵の民』ですかね。無敵の民とは、簡単に言うと『かけがえの無い人材』と説明されています。フラットな世界では企業と個人を問わず、誰もが同じツールを使って同程度の生産性の仕事をこなすことができます。そして、その環境がアウトソーシングに拍車をかけます。フラットな世界には『代替可能な仕事と代替不可能な仕事の二つ』に収斂していきます。そこで、先進国にする私達はどうすればいいのか。当然、答えは代替不可能な仕事をする能力を身に付けるということになります。平均的に優秀な技術者ではインド人技術者に仕事を取られてしまいます。要するに代替可能なわけです。無敵の民になるためには自分の得意な事を見つけてスキルを磨き続けるしかありません。 梅田さんのエントリの様に自信を持って好きな道に進み続けるしか無いのだと思います。『神は自ら助ける者を助ける』です。大変な世界がやってきます。フラットな世界で生きることを楽しめる様になりたいものです。
-
『郷に入れば郷に従え』とPredocのプレゼン
プログラミング 郷に入れば郷に従え EmacsLispをGaucheの方言にあわせたい。 単なる思いつきです。 例えば、map、 filter、string-catなどの関数は頻繁に使うので同じ関数名であればコードを書くときにストレスが無いだろうなと思います。 思うだけで実際にはやりません。 そんな変な方言で書いたソースコードはEmacsLispに慣れた人にとってはメリットが薄いだろうと思うからです。 あなたも、Perlっぽい記述ができるLispマクロを作ったり、Pascalっぽい構文をCプリプロセッサで定義する等、一度はやった事があるはずです。 しかし、そんなことをしなくてもある程度人間が慣れてしまえばどうってことは無くなります。 この場合は『郷に入れば郷に従え』という諺通り行動したほうがよさそうです。
-
Lispの真実
Lispの真実を読んで極端過ぎる意見だとは思いながら、Lispを一度も試したことが無いというのはあまりに残念なプログラミング人生だと思います。 Lispの真実 Lispを学ぶことはあなたの人生を変える。 あなたの脳はすごく大きくなり、そんなに大きくなるものだとは思わなかったほどになるだろう。 あなたは自分のアプリケーションをすべて、ほんの一握りのコードで書き換えるだろう。 社会はあなたを避けるようになる。あなたも社会を避けるようになる。 あなたは自分のまわりの物やまわりの人すべてに不満を感じるようになる。
-
機能が少ない安心感
最近の私のトレンドは、機能が少なくシンプルなもの、いわゆる『 [kiyoka.2006_12_10] 負のデザイン』なのですが、 関連記事を見つけたので紹介させて頂きます。 小野和俊のブログ:スリムなソフトウェア 使い慣れていた Office の機能をほぼすべての機能を持った ThinkFree では なく、機能が少ない Google Spreadsheets。Google Spreadsheets を使ってい ると、ずいぶん昔、まだソフトウェアにたくさんの機能が備わっていなかった 頃に感じていたような安堵感を感じることがある。
-
『デザイニング・インターフェース』を読む
デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン 著者: Jenifer Tidwell, ソシオメディア株式会社, 浅野 紀予 Amazonで見る 第二章だけでも読む価値があります。 特に、有名サイトがそうなっているからという理由で漠然とユーザーインターフェースを決めている人には読んで頂きたいです。 アプローチが全然変わると思います。 この本の良いところは、各ユーザーインターフェースのデザインパターンになっており、各パターンには、そのパターンを選択した場合に予想されるユーザーの心理状況や選択するメリットなどが細かく書かれているところです。 ちなみに、私は図書館に買ってもらい、日本語で読みました。 次にユーザーインターフェースを検討する時は、Safari Bookshelfで参照するという作戦です。
-
驚愕、元LiperのPythonコード
Spelling Corrector このコードすごいですね。集合演算使いまくりですね。 オブジェクト指向でさえないし… 私の普段のPythonコードも徐々にこれに近づいているんですけど。 リスト内包表記の嵐です。 これ以上lambdaとか内包表記を使いすぎるとチームメンバに読んでもらえないコードが量産されそうです。 やりすぎに気を付けよう。
-
On Lispを買う
野田開さん出版おめでとうございます。 買いましたよ。 Amazonで見る 出版前に誤字脱字修正パッチを野田さんにお送りさせて頂いたりしたので思い入れがある本です。 製本された物を手に取るとなんだか嬉しいです。 後1/3ほど読んでいないのでじっくり読みたいと思います。
-
機械学習の将棋プログラムBonanza
Bonanzaが強いらしいです。 ついにコンピューター将棋にも機械学習の時代が来るのでしょうか。 TVで見たんですが、過去の対局データを大量に読みこんで学習しているそうです。 Googleの自然言語翻訳も機械学習でしたよね。 今後もいろんな機械学習の応用が目に見える形で登場してくると思います。楽しみです。
-
日本語の『原因』、『リスク』という言葉は英語の意味とは異なる?
原因とリスク、どちらも良い事よりも悪い事に対して使う場合が多いと思います。 例えば、『その問題が起きた原因は?』『失敗するリスクを回避するには?』等のように。 『その利益が増えた原因は?』とか、『納期が延期されるリスクは?』という使いかたをする場面は殆どありません。 本当は英語では後者の使いかたも言葉の用法としては正しいのにも関わらずです。 それだけ、世の中の出来事は良いほうに転ぶことがまれだということでしょうか。 それとも、日本ではうまく行った時の備えや分析には価値が無いということなのでしょうか。たぶん、こちらが正しそうですね。 はたまた、心配性のマインドセットを持つ国民性から来るものかも知れません。 しかし、英語から日本語に翻訳された本には、そういう、結果として成功する場合の文脈についても『原因』や『リスク』という言葉が使われていることが多いように思います。 やっぱりこれも、『責任』も『自己責任』と言い直さないとresponsibilityの意味が表現できないのと同じ様に、日本語になってしまっているということでしょうか。
-
個人の中のイノベーションのジレンマ
前回の続きで『イノベーションのジレンマ』の応用編です。 イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき 著者: クレイトン・クリステンセン, 玉田 俊平太, 伊豆原 弓 Amazonで見る これを読んでいて、これは個人の中にも同様のジレンマが存在するのでは無いかと思うようになったので書いておきます。 うまくまとめられるか自信がありませんが。 『優秀な人が、なぜ突然破壊的技術が必要なプロジェクトにおいて、その優秀さ故、見当違いのデザインをしてしまうのか。』 『イノベーションのジレンマ』の話は、個人のリソース割当問題と考えると、個人にも適用できるコンセプトなんでは無いのでしょうか。 ここでは、リソースとは個人がスキルアップに使える時間と考えてください。 まず、優秀な技術者は顧客の要望する技術、つまり市場価値の高い技術を習得する事に一番時間を使ってきたはずです。またそれが正しいとされています。 そして、どんどん多くの顧客に頼られる技術者となっていきます。やがてそれが連鎖して仕事のリピート率は上がり、その顧客と技術者の関係は強固に成っていきます。 当然、その関係が強固になればなるほど、信頼関係も大きくなり、ビジネス的な金額も大きくなるため良好なサイクルが形成されます。理想的なWin&Winの関係です。 その結果、より要望にあった技術を習得するモチベーションが上がり、個人はよりブラッシュアップを続けて行きます。 供に成長でき、どこから見ても問題は無さそうに思えます。 それ以外の、これまでの延長線とは違う破壊的技術への備えは重きを置かれる事はありません。 しかし、技術者として長期的に見た場合、これが正しいと言えるかは疑問が残ります。 それがこのエントリーのテーマです。 ここで言う破壊的技術とは、オープンソースのミドルウェアやライトウェイトな言語環境などをイメージしていただけるといい思います。 全てを作りこむのではなく、これらをまるでテコの原理のように利用して、問題を自分の脳味噌に入る範囲、自分の使える時間の範囲に縮小します。 しかし、問題なのはこの技術を習得するには時間がかかるため、要望されてから習得するようでは間にあいません。 日頃顧客から信頼され、優秀と思われているが故にそれが仇となってしまいます。 テコを使わずとも解決できる場合は多いし、成功してきたはずです。 しかし、それがある一定の臨界点を越えると完全に問題に直面したり、ライバルに出し抜かれます。 ライバルから見ると優秀かも知れないけれど、過剰品質なものができ、しかも一番重要な『柔軟性』が失われた物になります。 これは、品質の定義が変わってしまった市場では完全に出し抜かれているのに、本人たちはその古い定義の上での優秀さで目が曇ってしまい、失敗した事に気づくのに遅れます。...
-
『イノベーションのジレンマ−技術革新が巨大企業を滅ぼすとき』を読む
イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき 著者: クレイトン・クリステンセン, 玉田 俊平太, 伊豆原 弓 Amazonで見る 『顧客の意見に熱心に耳を傾け、新技術への投資を積極的に行い、常に高品質の製品やサービスを提供している業界トップの優良企業。ところが、その優れた経営のために失敗を招き、トップの地位を失ってしまう。』 その理論を実証して見せてくれる本です。 一見逆説的なこのコンセプトなのですが、読み進むうちに納得する、というより、結構心当たりがあるぞという思いにさせられます。 もしこの理論が本当なら、意識して避けなければならない事象です。 私は数年前から、いかにイノベーションを継続的に生み出すかという事に興味があって、『ドラッカー』の本なども読んでいますが、私と同じ興味をお持ちの方は読んでみてはいかがでしょうか。 ドラッカリアンの人にもこんな補足的な視点があるということで、いい刺激になるのではないでしょうか。
-
ブログとJazzの類似点
Jazz好きなのでかなりバイナスがかかっていると思って読んで下さい。 ブログとJazzは、ある類似点を持っていると思います。 それは、自分の思う所を一方的に表現するという表現者-対-受け手(読者 or リスナー)の関係性においてです。 ブログは文章を使って思っていることを、それに対してJazzはインプロビゼーションで瞬間のフィーリングを音楽に組み立てます。 Jazzは他の音楽と違って、リスナーに迎合せず自分のスタイルを貫きます。(あるJazzプレイヤーがインタビューでそう言っていました。) ブログのほうも、とりあえず自分一人の考えを一方的に書いてみて、どうだったかはコメント、トラックバックとして受けとります。 ブログを書くことで、Jazzを演奏しなくても心理的にはJazz奏者と同様の心理体験ができているんじゃないかと思っています。 一つもコメントが付かなかったりすると、受けないJazz演奏をやったミュージシャンと同じ寂しさを覚えたりもできます… orz ちなみに、何回聞いてもいいなというCDはこれです。高校生の頃に買ったやつです。 Kind of Blue 著者: Miles Davis, Wynton Kelly, Paul Chambers, Jimmy Cobb, Cannonball Adderley, John Coltrane, Bill Evans...
-
Gimpでスクリーンショットを加工するテク
私がオープンソースソフトウェアのマニュアルに使っているスクリーンショット加工テクを紹介します。 ちょっとした工夫でユーザー視点のドキュメントになります。 逆に言うと私の様に文章で説明するのが得意では無い人にもおすすめです。 スクリーンショットを使えば、百聞は一見にしかずで、文章で色々説明しなくても済むことが増えます。 そう、オープンソースソフトウェアのドキュメントは意外と重要です。 いくらソフトウェアの品質が良くても使う前にドキュメントの取っ付きやすさで、試用するかしないかが決まります。(実際自分の行動を振りかえって見ると、そうなので) 私が使うテクニックは、こんなやつです。 sumibiで検索すると最初に表示されます。 『Googleで ‘sumibi’ で検索すると最初に表示されます。』という説明で使えばぴったりですね。 注目してほしい所にスポットライトが当たっています。 これは、NHKスペシャルで公文書の注目してほしい箇所を写しだす時によく使われているテクを真似たものです。 次回は、この画像をGimpを使って作る手順について解説します。
-
バベル案内
バベル案内について。 このエッセイは、C、C++、Lisp、Java、Perl、Ruby、Pythonの言語の紹介になっています。 多少乱暴だけど、言っていることは説得力があり概ね賛同できます。
-
『負のデザイン』と『Getting Real』
Vista とか Office 2007とか、新しくリリースされるソフトウェアはどんどんリッチになっていきますね。 一方で、ユーザとしては複雑になる一方のソフトウェアにウンザリしている人もいるでしょう。 そんな中、いろんな人が逆の考えかたで差別化しようと挑戦しています。 37singalがそんな哲学を持っているのは有名ですが、reddit.comで『Getting Realの日本語訳』が有るのを知りました。 『負のデザイン』にも通じるこの考えかた。 物事をシンプルに保つことで競争に勝つという考えかたです。 世の中の流れをよそに、トップスピードで逆走してみましょう。 また違った風景が見える事でしょう。 シンプルを実践しているサービス、プロダクトを紹介しておきましょう。 言わずと知れた37signalsの製品群 UIEngineのデザイン・プリンシプル Google そして手前味噌ながら、Predocです。 私は今もバリバリ逆走中です。一足お先に行ってます。
-
Joyベースのシェルスクリプトなんかどう?
再びOverview of the language JOY関連のチュートリアルやFAQを読み直しました。 今度はちゃんと理解できたと思います。 さて、以前これを『なでしこ』の様に日本語プログラミングに応用したら良いんじゃないかと書きましたが、撤回します。 日本語プログラミング言語の想定ユーザーとしては、『これからプログラミングを覚えたいという人』に設定するのが良いと思いますが、Joyはそういう人たちにとって難易度高すぎです。 関数型言語として設定されており、手続き型言語でおなじみのforループなどがなくmapやfilterというコンビネーターを使うことが前提となっています。 Joyの構文を日本語の文脈にうまく当てはめたとしても、プログラミングの初学者に向けて易しい解説をする自信はありません。^_^; むしろ、もっとハッカー向けの用途に適用したほうがいいと感じました。(ハッカーには日本語プログラミングは必要無さそうですので。日本語変換するのめんどくさそうとか言いそう。) 例えば、shellスクリプトなんかに適用すると良いのではないかと思います。 下記は、Joyで未定義の関数を外部コマンドから探して実行することを想定したコードになっています。
-
『神は沈黙せず』読了
読了しました。なるべくネタバレしないように書きます。 昔、人口生命に興味を持って、GAとか使って色々やっていたことが懐かしくなりました。 もういちどやってみようかなと思わせるSF小説です。 筋金入りのリチャード・ドーキンスファンにはオススメです。 これ以上は言えません。小飼弾さんもおっしゃるように、読んどいて損はないSFです。 神は沈黙せず〈上〉 (角川文庫) 著者: 山本 弘 Amazonで見る 神は沈黙せず〈下〉 (角川文庫) 著者: 山本 弘 Amazonで見る
-
『フラット化する世界(上)』を読む
フラット化する世界(上) 著者: トーマス・フリードマン Amazonで見る 最初は『そうか、世界のアウトソーシングの現実はこんなに進んでいるんだな』と思って読んでいたんです。もうSF気分で楽しく読んでおりました。 しかし、読み進むに従って、ここまで進んでいるとは認めたく無くなって来ます。一種の恐怖ですね。 最近になって少し前に出版された近未来的SFに書かれた内容が一部実現していたりして、本当に技術の進歩が速い時代だなーと思い知らされます。 (携帯電話でGPS・テレビ電話とかね。 ネットフォースではウァージルと呼ばれていましたね。) 逆説的ですが、だから近未来的SFが面白いのかも知れません。 私達は長生きしなくても技術の進展が面白い様に感じ取れる時代に生きています。しかし、だからこそこの変化の激しい時代にどうやって楽しく生きるかという方が重要になってきている気がします。 うかうかしていると、変化を楽しむ余裕も無く、逆に変化に押しつぶされる立場になってしまう可能性が大きいのです。 手遅れになってから右往左往しないで済む様に、常に創造的な仕事ができるレベルにスキルアップしないといけないということを教えてくれる本です。 人生は楽しむには短かすぎ、苦しむには長すぎます。 あなたはこの本を読んでエキサイトできる人ですか?それとも恐怖を感じる人ですか? 上巻には下巻への続きとなる章が最後に設けてあるのですが、それを読むと、ちゃんと準備すればフラット化の波は別段恐れることは無さそうに思えます。 また下巻を読んだら感想を書きます。(3ヶ月後ですけどね^_^;)
-
SF小説もたまにはいいかも
図書館で予約していたSF小説が届きました。 神は沈黙せず 著者: 山本 弘 Amazonで見る 最近、予約本が大量に届いて大変です。 本を沢山読んでいるので、プログラミングをあまりしない日が続きます。(本当は色々やりたいのですが…) 昔は大量にSF小説を読んだものです。 意外とSFとプログラミングは関係ないと思われる方もいらっしゃると思いますが、突拍子も無いアイデアを思いつく為にはある程度読んでおく必要が有るのかも知れません。 SF小説の中にはかなり妄想的な話が多いですが、技術の進歩が早い現代に於いては、数年もすれば『あながち妄想ではなかったのね。』というような事もあります。 SF小説に出てくる人々の生活をユースケースとして利用する面白い物を思いつくかも。 そんなわけで少しの間、読書とブログが中心の生活が続く予定です。
-
図書館について
図書館についての議論が活発になってきたので、私も参加してみたいと思います。(例えば、404 Blog Not Found:図書館の費用対効果、図書館の公共性をめぐる論争と経済学。など) 私も図書館にお世話になっている一人であることは、過去の日記にも書いた通りです。(2006-05-30Life* 図書館2.0、2006-08-10Life* 続図書館2.0) 私が感じる図書館の問題を、アルファブロガーの皆さんが書かれているような広い視点ではなく、個人的な視点から書いてみたいと思います。 ベストセラーの本の予約待ちが長い。 したがって、上下巻がある場合、下巻が手に入るまで時間が空く(2ヶ月から3ヶ月とか)
-
プログラミング中に聞く音楽(2)
([kiyoka.2006_12_17] プログラミング中に聞く音楽(1)) の続きです。 結局、これをAmazonで買いました。 せせらぎ 著者: 自然音 Amazonで見る なかなかいいですね。最初は鳥の鳴き声とかが聞こえてきて邪魔になるかなと思ったのですが、自然音だからなのか、集中するとそうでもありませんでした。
-
今年の抱負
今年もいろんなモノを作っていきたいと思います。 まずは、Schemeの腕をもっと上げる事。そしてシンプルで強力なソフトウェアやサービスを作り出して行きたいです。 これまではモノを作る事に集中するあまりエレガントなコードを書く為のスキルアップがおろそかになっていたと思います。 デザインは『負のデザイン』を指向してシンプルに、実装は力のある言語でエレガントに、が目標です。 ところで、私は毎年1つ新しい言語を習得するということをしてきたのですが、今年はまだまだSchemeで行きます。 今年からSchemeのマクロをどんどん使ってDSL(Domain Specific Language)をデザインする練習をしていく方向に切りかえます。 他の言語で新しい概念を学習するよりも学習効率が良い気がしているからです。 そもそも、新しい言語を習得する目的は新しい概念を習得する事にあるのですから、わざわざ遠まわりをする時間がもったいと感じています。 (Lisperのみなさん、この考えかたは極端過ぎますか? そんなことないですよね。) 今年もオープンソースソフトウェアの活動を通じてスキルアップをしていければと思っています。
-
『グーグル - Google 既存のビジネスを破壊する』
グーグル―Google 既存のビジネスを破壊する 文春新書 (501) Amazonで見る を読みました。 いろんな所で書評されているので、あまり書く必要は無いのかも知れませんが… この本では、どんな業界が破壊されてどんな業界が生まれるか事例を挙げて説明されています。 結局、大企業と個人の力が検索エンジンの力によってフラット化され、同じ土俵で戦える時代が来たということが説明されています。 それによって、当然良い影響を受ける人と悪い影響を受ける人が出てくる。 Googleはその速度を速めて、既存のビジネス(特に広告収入で成立っている既存メディアなど)に対して兵糧攻めを浴びせるという戦略なのですね。 最初から最後まで一般の人にも分かる言葉で書かれているのが、好感が持てました。 エンジニアでない方も安心して読めます。 さあ、個人としてはどう生きるべきなのか。気になるので今各所で引用されている『フラット化する世界』も読む予定です。 フラット化する世界(上) 著者: トーマス・フリードマン, 伏見 威蕃 Amazonで見る
-
お金で買えない物『好奇心』について
江島さんのブログエントリを読んで、再度『好奇心』の価値について考えます。
-
Gaucheをもっと気軽に使おう
Matzさんところ、Danさんところの関連エントリーを読んで。 私も、Lisp系方言の一つSchemeでプログラミングをする『にわかな奴』です。さらに、Common Lispに至っては使ったことがありません。 SchemeとEmacs LispばっかりなのでLisp選民ではなく、落ちこぼれに分類されると思われます。 でも、こう感じてしまうLispという言語はなんなんでしょうね。 皆が皆、ジェダイマスターになる必要はないのです。( ジェダイマスターで無くても作れるSumibi.org。) そういえば、Schemeの人達とチャットをしていると『にわか』な人はあまりいません。 私の様に読解いやな法則: にわかな奴ほど語りたがるに該当する人にもっと頻繁に出会えてもいいのになぁ。
-
プログラミング中に聞く音楽(1)
プログラマーの皆さんはコードを書いている最中に音楽を聞きますか? 私はJazzとかHip Hop、それにクラシックを聞くことが多かったのですが、最近『波』の音を収録したCDを聞きながらコードを書いています。 Hip Hopとかは、ノッている時には良いのですが、ときどきしんどいと感じる事があります。 そんな時は、『波』の音がいいですよ。 私の聞いているCDを紹介します。 ニューカレドニアの波の音を聞きながらコードを書くと、Schemeの丸括弧がさざなみに見えて来る…かも知れません。(笑) 冗談はさておき、再帰的なプログラムを書いている時など、瞑想しているような落ちついた状態で取り組めます(迷走していることも多いのですが;笑)。一度おためしを。 あっ、今amazonの商品のページに行ったらこちらも見つけてしまった。こっちも買お。 Amazonで見る Amazon商品 Amazonで見る
-
『負のデザイナー』憲章
負のデザイン: 森本 武を図書館に返却しちゃうので、『負のデザイナー』憲章(心得みたいなもの)を書いておきます。 この憲章に従えば自動的に多くの人に使われるソフトウェアができるわけではないのですが、私がデザインで迷った時にはこれに従うつもりです。 特にプライベートで作るソフトウェアでは開発リソースも限られるので、開発者とユーザーの両方を幸せにするにはよい戦略だと思います。 Joel on Softwareの『シンプルさ』に反対意見の記事がありますが、この記事ではその肥大化した機能の『取り除きかた』の上手さには言及していません。 それとは、気づかれないように取り除く方法を学べばみんな幸せになれると思います。機能を削って我慢するのではなく、同じことをシンプルなやりかたで置き換えたりする。マイナスハックですね。
-
負のデザイン: 森本 武
この本はすばらしいです。 この本は過去の私の記事kiyoka日記:デザインは引き算にて、ヤマケンさんに教えてもらった本です。ヤマケンさんありがとうございます。 あまりに素晴らしいので引用させて頂きます。
-
RubyのまつもとさんのPodCastingを聞く
まつもとさんのプレゼンのPodCastingを聞きました。 英語ですが大変わかりやすいプレゼンですね。音声だけでも会場の笑い声からどんなスライドが出ているのかだいたいわかるのが不思議です。 ここではこんなPerlコードが表示されているんだろうなとか。 このプレゼンではどんな哲学でもって言語をデザインすれば良いかが語られています。 プログラミング言語のユーザビリティーとは、という内容ですが、言語のデザイン以外にも使える本質的な話なので一度聞いてみてはいかがでしょうか。
-
『算法少女』を読む
算法少女 (ちくま学芸文庫) 著者: 遠藤 寛子 Amazonで見る は1973年に出版された本ですが、オープンソースのエッセンスを伝える良い本だと思います。 この本を読むと、なぜオープンソースプログラマはコードを書きつづけるのか、という理由が説明ができるんじゃないかと思います。 ちょっと算法(数学)とは違うかも知れませんが、十分共通する部分があると思います。 最近復刊した様ですし、一度読んでみて下さい。さわやかな読了感があります。私は図書館で1973年のオリジナル(ハードカバー)のやつを借りて読みました。 レビューや、復刊した経緯は[1]や[2]で読めます。
-
KOFで『なでしこ』のクジラ飛行机さんと会う
KOFでブースに立寄っていろいろお話しさせて頂きました。クジラ飛行机さんと言えば、日本語プログラミング言語『なでしこ』、『葵』等の作者の方です。 やはり、面白い物を作られている方は自分と同じような空気を持っていらっしゃる方が多いと再認識しました。 まだ世の中に無い物、技術的に新しいものには自然と引き寄せられてしまうサガの様なものでしょうか。 今回は、直接お会いできたのでJoy programming languageというのがありますよ、と紹介させて頂きました。 『これを使えば、日本語で関数型プログラミング出来るんじゃないでしょうか』なーんて生意気にも進言させて頂きました。 短い時間でしたが『それは面白い』『かっこいいですねー』と言いあいながら楽しい時間を過ごさせて頂きました。 クジラ飛行机さんはご自分の技術を使って、『なでしこ』、『葵』という形で『これからプログラミングに挑戦する人』に向けてプログラミング言語を提供されています。 つまり、ターゲットがGeekではない人たちなんですね。 考えてみれば、私もマニアックな技術をGeekではない人たちにわかりやすい形で提供するという事に高い満足を覚える人間です。クジラ飛行机さんを見習って行きたいと思います。 技術的には結構なことをやっているんだけど、それを誰にでもわかりやすい形でシンプルに見せていく。 難しいですが、挑戦しがいのあるテーマです。これからも負けない様にがんばって行こうと思いました。
-
Schemeが流行ってほしいかどうか
最近LingrというチャットサイトでGaucheとScheme言語の話題に参加しています。 そこで出た話なのですが、『Schemeがもっと流行って欲しいか?』という質問に対して、そこにいた人達は『そこそこ流行ってほしいけどRubyほどにははやって欲しくないなぁ』という意見でした。 理由としては、みんながScheme使ってしまうと、今Schemeを使っている開発スピードのアドバンテージが無くなってしまうからです。 Paul Grahamも言っていますが([1]|[2])、わざとLisp(Scheme含む)を使っている事を内緒にしてアドバンテージを維持しつづける。というのが戦略ですね。 ここで書いても私に影響力無いので問題ないですよね。^_^;
-
GaucheFestで時計アプリを作る
Gauche関連のハックをする集まりであるGaucheFestに参加しました。 最近GaucheFestではLingrというWebブラウザ上で動くチャットを使うようになりました。 というわけで、Lingr上で使用する時計アプリを作っています。 チャットルームに来る人は住んでいる国が違うことが多く、相手が朝なのか夜なのか、はたまたもう寝ないといけない時間なのか分かりません。 そこで、同時に複数のタイムゾーンの時間が表示される時計を作っています。 この時計は画像になっており、Lingrの発言欄に貼りつけることができます。 また、内部はCGIになっており、貼りつけた時刻だけでなく現在時刻も同時に表示されます。 過去ログをたどって行った時に、複数のタイムゾーンでその発言時刻が分かるというわけです。 ゆっくり作っているので、実際に使えるようになるのは来週位の予定です。おたのしみに。 開発中の時計の画像も貼っておきます。(ここに貼った時計画像はCGIではないので時刻が変化しません。悪からず。^_^;) 開発中のTzWatchの画面
-
テクノロジストの条件を読む
この本の主題は生産性を上げる為には、良い問題設定を行う必要がある。という事だと思います。 当たりまえの物を当たりまえの方法で作る時代は終わり、何を作るか、変えるか、組合せるかということを模索していく必要があります。 イノベーションを継続して発生させる方法を確立するしかありません。そうしないと、発展途上国に生産性の面で追いつかれます。 この本での生産性とは、狭義の生産性、つまり単に同じ物を作った場合の生産性の事を行っているわけではありません。 広義の生産性、つまり何を行い、何を行わないかという問題設定も含めての生産性です。 但し、どれが良い問題設定だったのかというのは、初期段階で予想することは難しく、ある程度試行錯誤を行った後でしか分かりません。 なので、たくさんの種を蒔いてその中から芽の出そうな物を取捨選択する必要があります。 このような活動が出来ていない企業はやがて、発展途上国の爆発的な成長の中で追いつかれてしまいます。世界はフラット化して行きます。 最近、私は本当に危機感を持っています。人事では無いなと感じています。 Amazon商品 Amazonで見る
-
創作の秋
私には、創作の季節というのがあるようです。 毎年、10月から年末にかけて、作るべきものが一つの形を成してきます。 これが不思議なことに毎年この季節なのです。 食欲の秋とか読書の秋とかありますが、私の場合は創作の秋のようです。 思えば、Sumibi.orgも R@eply.orgも10月位から開発スタートしています。 次に作るソフトウェアのアイデアは有るんですが、まだ完全なイメージになってないので、もうちょっと寝かしてから取りかかります。
-
Rubyの生産性の高さはどこまで本当か?
私も何度も生産性の議論を書いていますが、生産性の議論は本当に難しいと思います。 このエントリーでも、やっぱり純粋に自由度と生産性と気持ちよさを考えると最後には、S式macroとMOP最強論に吸いこまれていますね。 やっぱりJavaの発明者から言語界のブラックホールといわれるだけあるLispです。 もし、括弧に対するアレルギーが無いのだったら、Lisp系言語は最高ですよ。 例えば、Gaucheを使えば、メタプログラミングは当然できますし、ブロック構文とソックリのイディオムを提供する関数も標準で沢山あります。 (with-input-from-file ‘filename’ …)など。 細かい話は置いておくとして、もしLisp系言語のパワーそのままで、ソースコードの外観もPythonやRuby程度の普通っぽさを持っていたら、もうちょっと普及の方向に動くと思います。 誰か作りませんか?GaucheベースのRubyスキンとか。 Schemeハッカーは言語の拡張にいそしんで、普通のハッカーは、PythonとかRuby構文でプログラミングを行うという分業体制ができます。 これが将来ほとんどの言語が辿り着く姿なんじゃないかと予言します。外れると思いますが。
-
富豪的プログラミング
最近はコンピューターのCPUとメモリ容量が大きくなったせいで昔とは違うプログラミングスタイルが主流になりつつあります。 それは、富豪的プログラミングと呼ばれるスタイルです。 経済的に富豪で無くても、コンピュータープログラミングの世界に限って言えば、誰もが富豪になれます。ケチケチせずに富豪になってしまいましょう。
-
デザインは引き算
最近、シンプルな物に惹かれるようになりました。 これから私が作るソフトウェアはその路線を変えないつもりです。 このような記事を見つけましたが、全く同感です。私がSchemeを好む理由もコアがシンプルだからです。
-
作りたい物がいっぱいあって困る
最近、作りたい物があって困ります。 プログラミングの練習で作ってみたい物から、自分が毎日使いたいツールまで色々です。 例えば、今練習で作ってみたい物はWikiですね。 日本のWikiだけでも日本発の wiki クローンリスト、日本発の wiki クローンリスト2の様にたくさん有るのにまだ作るんですか、と思われるかも知れません。 でも、Wikiはプログラミングの練習には良い題材だと思います。 簡単にできるし、あたらしいアイデアを短時間で試しやすいのでは無いかと思います。 『どれだけ短いコードで書けるか』とか『どれだけ読みやすく書けるか』とかにも挑戦してみたくなります。 そう考えると、My言語も沢山有るけど、MyWikiもたくさんある理由が分かりますね。
-
Pythonとschemeの役割分担
Pythonは仕事でscheme(Gauche)はプライベートでという役割分担になっています。 Red Hat Enterpriseに最初から入っている、言語仕様が安定している、という理由でPythonを仕事で使っています。 Rubyもいいのですが、それらの条件をクリアできません。 また、プライベートでscheme(Gauche)を使っている身としては、RubyよりもPythonの方がschemeに似ているという感じがあってスイッチしやすいです。 schemeの小括弧を全て取ったらPythonに見えなくもないような…
-
オープンソース開発をする理由
昨日吉岡さんと梅田さんの対談を見たことがきっかけで書いています。 オープンソース開発者が世界中になぜ200万人程もいるらいしいですね。 私自身もオープンソース開発者といっても問題ないと思いますが、私自身なぜオープンソースソフトウェアを開発しているのか明確に一言で説明することはできません。 もちろんそれで生計を立てているわけではありませんので、それが理由ではありません。 オープンソース開発者は世界中に200万人もいるらしいのですが、動機は個人個人全く異なると思います。 オープンソース開発者の中には、すでに存在するソフトウェアプロジェクトに参加して、バグフィックスや機能アップを行う人もいれば、新しいアイデアを試す目的でソフトウェアプロジェクトを起こす人もいると思います。 私の場合は後者です。アイデアを試す為にコードを書かずにはいられない質の様です。 オープンソース開発者になろうと思ってなっているわけではありません。 そして、たまたまその成果物をオープンソースという手段でもって発信するのが一番自分にとってメリットが大きいのです。(フィードバックを得られるなど) 発信するためにコードを書くわけではなく、いろいろコードを書いている間に発信すべき物が出来てしまうというという感じです。 もちろん、アイデアをちょっと試してみた結果、アイデアに価値が無いことが判明したり、実現不可能なことが判明したりしてボツになった物も沢山あります。 本当は仕事で毎日使わせてもらっているソフトウェアに貢献したいのですが、それはなかなか難しいです。その辺は次の機会に書きたいと思います。
-
LL Ringの感想など
LL Ringに参加しました。LL系のイベント参加は初めてです。 私は発表者で参加したので、ゆっくり見れないプレゼンもあったのですが、 全体的にプレゼンと発表内容のクオリティーが高く、本当に有意義な一日となりました。 また、普段IRC等でしか出会えない人とお話しできて楽しかったです。 全部ちゃんと見れていませんので、見れたところだけ感想を書きます。 ちなみに、今はやりのWebアプリケーションフレームワークにひっかけてAsahi SUPER ‘DRY’を飲んでいます。^_^;
-
プログラム・デザイナー宣言
小野和俊のブログ:続・プログラム・デザイナー宣言 高林さんのUNIXにみる世代間の断絶にならって職人プログラマー/プログラム・ デザイナー/UIデザイン・プログラマーを表にすると次のようにな る。…(略)…文系と理系と同じように、プログラマーにだって、一言でプロ グラマーとまとめるべきでない、それぞれ異なる指向性がある。
-
色々見たけどやっぱりGauche
Perl/Ruby/Python/Guile/Gaucheをやっみたけど、一番書きやすいのはやっぱりGaucheです。 でも、さすがに仕事では自分一人でコードを書くわけにはいかないのでLisp系言語処理系であるGaucheは無しになってしまいます。本当にもったいないです。 プライベートなプログラミングは今の所はGauche一本になっていますが、このまま行く積もりです。 もっとSchemeの定石を増やして美しいコードを書く為にも、そろそろGaucheのコミュニティーにコード還元しないとなーと思っています。 DBD SQLiteくらいから始めるかな。
-
続図書館2.0
以前、kiyoka日記:図書館2.0という記事を書きました。その続きです。 最近私は、図書館に自分の本を寄贈しはじめました。 なぜかというと、図書館に自分の本を置いてもらったほうが色々とメリットが大きいからです。 そのメリットを挙げると、
-
温故知新の newLisp
newLispという言語を見つけました。 newLispというぐらいなので、新しいのかと思ったら、1991年からある言語なのですね。 かといって、停滞しているわけでもなく、最近のLisp系言語の盛りあがりも手伝ってか継続的に新しいバージョンがリリースされています。 で、どこが他のLispと違うのでしょう。ざっと見た感じでは、Common LispやScehemeの仕様を簡略化したような感じです。 実際にプログラミングしてみないとわかりませんが、簡略化した部分で私が困る様な所は無さそうです。 Gaucheと比べると、ライブラリの豊富さと日本語サポートの面でGaucheに軍配が上がるので、乗りかえる事はないですが。 少々制限が増えても、言語をシンプルにしようとする方向性は賛成です。ただ、そのバランスは難しいですね。 一応、『何が違うの?』という部分を引用しておきます。
-
EmacsのSchemeモードを拡張する quack.el
quack.elをEmacsに追加すると、lambdaがλ記号で表示されます。 他にも、キーワードの色付けが標準よりも見易くなります。(小括弧が赤、文字列や#fなどが緑、コメントが水色等) Gaucheプログラマの皆さん、試してみましょう。なかなかいいですよ。
-
Pythonをちょっと試す
Pythonをちょっとだけ使ってみています。 ファーストインプレッションとしてはBetter Lispと言って良いと思います。そして、書きやすさはRubyと大差ない気がします。 関数型言語風味な所は沢山ありますが、完全な関数型言語ではないので幾つか気に入らない所があります。 一つ目は、reutrnを書かないと行けない所です。関数の最後の評価値がreturnの値になればよいのにと思います。 二つ目は、lambda の関数本体に式が1つしか書けない所です。 どちらも致命的という程ではありません。慣れれば普通になるのだと思います。 また、Python食わず嫌いの人の議論の的になりやすいインデントによるブロックの表現は意外といいです。
-
Cleanが面白い
最近純粋関数型言語を順番に見てまわっています。 Cleanという言語も面白いですね。 純粋遅延関数型言語Concurrent Clean Haskellと同じで、キーワードは『参照透明性』と『遅延評価』でしょうか。 インデントが構文上の意味を持つというのも同じですね。 まだちゃんと見ていませんが、Haskellと共通点が多そうです。逆にどこが違うのでしょうか。
-
『大前研一のアントレプレナー育成講座』を読む
大前研一のアントレプレナー育成講座―アタッカーズ・ビジネススクール〈Part5〉 著者: アタッカーズビジネススクール Amazonで見る 第3章の『アントレプレナー・マーケティング』- 事業の核心に迫る分析力 - が一番役に立ちそうです。 この章を書かれたのは株式会社ユニバースの小川政信さんという方です。 マーケティングを軽く見てはいけなくて、製品開発の全ての大元だということが分かります。マーケティングという言葉は市場調査やプロモーション活動だけというように狭義のマーケティングの意味で捉えられることが多いですが、それは間違いです。(コトラーの本にも繰り返し書かれています。) この本では、『顧客に取っての価値の見極め』の手法を細かく解説しています。 コトラーの本などを読んでもこのように具体的には書いていなかったと記憶しています。 顧客は何に価値を認めるのか?その価値にいくら対価を払うのか? へえ、そういうことができるのかと思った事としては、商品の魅力を様々な『要素』に分解して各要素がどれだけ魅力的なのか見極める方法があるということです。 この本ではその『コンジョイント分析』という手法をスターバックスコーヒーの日本展開を例にして解説されています。 さらには、この分析結果で、例えば『コーヒーの美味さ』が重要となった場合、そのコーヒーの美味さとは何かを無意識レベルまで知らないと意味のある仕事はできないと説いています。 また、アサヒスーパードライの成功事例では味覚が良いがうまいビールというわけでもないという形で紹介されています。
-
高速CPUの使い道
Paul Grahamのこのエッセーを読んだ時には、次の様な富豪な言語設計は大分先にならないと受入れられないだろうと思っていました。
-
Less Is More
ちょっと前に始めたサービスR@eply.orgには何かが足りないです。 R@eply.orgのユーザーの皆さんもそう感じていらっしゃるかも知れません。 何かが足りないです。 足りないのは便利さなのか、それとも楽しさなのか、はたまた驚きなのか。 Less Is More ( Jason Fried CEO, 37 signals )というpodcastを聞いているうちに、より少ない機能がシンプルさに繋がり、結果として分かりやすさを生むという考えかたに感銘を受けました。 R@eply.orgでそんなことが出来るかな? 目指すところは、中身は賢く、表面はシンプルに。Sumibi.orgはその点、成功している様に見えます。 うーん、どうすべきかなあ。
-
No code No life.
コードを書かずして生きられないのです。しかし、ただがむしゃらに思いついたコードを書き散らすには人生は短すぎます。アイデアも手段も取捨選択したいものです。 日々、次から次へと実装せずにはいられないアイデアが降って湧いてきます。インターネット上のアルファギークと呼ばれる人達には私と同じ症状に悩まされている人が沢山いらっしゃるようです。 多くのコードの達人系アルファギークの面々はプログラミング言語処理系を実装したりしながらも、同時にシブいアプリケーションも作ったりされています。こういう人達は別として(いやマジで)人生は有限なので、どんな優れたアイデアや楽しそうなことも取捨選択が必要となります。 私もいろんなアイデアに取り付かれやすい割に、そんなにすばやく実装できるほうではありません。私達にはこれをエレガントにさらっと躱す術が必要になります。そこで私が心がけているものは次の様なことです。
-
GaucheFestに参加した
GaucheFest第12回に参加しました。 特に実作業でGaucheのプロジェクトに貢献出来ている訳けではないです。(ずっとSumibiの作業をやっていましたので。) リモートからの参加ですが、仲間がいるという安心感のもと、いつもとは違うマインドで作業ができます。 また、IRCでちょっと会話をするだけですが、Inspireされて、いろんなアイデアに繋がります。 Sumibiの改良を続けていくことで、『Gaucheでもいろいろ作れるんだ』という認識が広がっていけばいいなと思います。
-
図書館2.0
今図書館が僕の中で熱いのです。 僕の住んでいる近所の図書館なのですが、最近サービスが向上して喜んでいます。ここ2年くらいの変化だとおもいますが。 (ちなみに、僕は大阪に住んでいます。) 最近の僕の本の探索行動パターンについて紹介します。 本屋で気になる本を見つける 携帯のメールで自分にメールを投げておく(メモ) 図書館のWebサイトで検索して予約を入れておく 図書館のWebサイトで検索して見つからない本は、最寄りの図書館に電話して大阪府立図書館から取り寄せてもらう O’Reillyの本はSafari Bookshelfで読む それ以外の本をAmazonで買う
-
Joyが面白そう
大昔にstackベースの言語でなんか面白そうな言語が作れるのではないかと妄想したことがありました。 最近のForth言語関連でなんか動きは無いのかと調べていたら、Joyが見付かりました。 ぱっと見た限りでは、stackベースの言語Forthに強く影響を受けているみたいです。 しかも関数型プログラミングができると来たもんだ。 schemeやperlでおなじみのmap関数も書けるという… 僕が瞬間に思いついたアイデアとしてはこのJoyという言語の特徴をひまわりのように日本語プログラムに応用するというものです。 どうです?題材としては、楽しそうでしょ? これをHaskellでちょいちょいっと作ってみるというのも楽しいかも知れません。 僕にはそんな能力はありませんので誰かトライしてみてください。但し、クロスプラットフォームで動くようにしといてくださいね。
-
言語の学習コストと生産性
最近色んなブログでPerlの学習コストの話題が持ち上がっています。 ( Danさんの所 を出発点にしてもらえらば沢山たどれます。) 僕は、Perlの学習コストは高いと思っている派です。そして、もうひとつ学習コストが高いと思っている言語が有ります。Schemeです。 これだけでは何のコストか良く分からないので、もうちょっと突っ込んで書いてみます。 Perlのコスト高の原因は色んな書きかたが用意されていて、その量に圧倒されてしまうという所にあると思います。モジュールを使って言語機能を拡張できます。 例えば、このエントリーを読むと、覚えることが多いせいでPerl5以降のperlの学習コストが、かなり高いと感じられるでしょう。 逆に、Schemeのコスト高の原因はマクロなどを使って、ドメインスペシフィックな記法が編み出せてしまうので、他人のコードを読む時のコストが高いのではないかと思います。 それぞれ、学習コストは高いですがコスト高の原因が違います。 しかし、どちらも言語の学習コストは高いですが、一度深くその言語を使いこなせると、そのぶん生産性が何倍にもなって返ってくるという気がします。 同じ処理を書いてもより短いコードで多くの事が表現できる。 生産性のためなら学習コストは厭わない。それがプログラマーというものです。 そして、さらなる生産性を求めてHaskellへの興味が湧いてきています。
-
『ザ・キャッシュマシーン』を読む
ザ・キャッシュマシーン 著者: リチャード・クラフォルツ, アレックス・クラークマン, 三本木 亮 Amazonで見る 『ザ・キャッシュマシーン』を読みました。 TOC(制約条件理論)の本を読んだのはこれで4冊目です。 このシリーズの本で出てくる『思考プロセス』で使う対立点のグラフは現実の問題に一度使って見たくて仕方ありません。 普段のソフトウェアの設計や仕様決めに使えるんじゃないかと。 こういう小説風になっているビジネス書は、テーマになっているソリューションを使ってあまりにも問題を簡単に解いてしまうので、そのソリューションの適用可能範囲の限界が見えにくいという問題があります。 要は良いことばかりが書いてあって、ソリューションの使用上の注意点がほとんど書かれていないのです。 ということで今度は、小説形式でない解説書である『利益を最大化するTOC意思決定プロセス』を読み始めています。 ゴールドラット博士のコストに縛られるな! 利益を最大化するTOC意思決定プロセス 著者: エリヤフ・ゴールドラット, 村上 悟, 三本木 亮 Amazonで見る
-
入門Haskell
Anthyの開発者のProxyさんの強いススメに従って、Haskellを習得すべく『入門Haskell』を読み始めました。 新しい言語を勉強するのはいつも楽しいです。 Amazonで見る 言語を勉強する理由として、新しい概念を習得できるということが大きいです。 逆に、新しい概念や考え方を学べない言語は勉強する価値がありません。(既にあるソースコードを改変する場合は言語を選べませんが…) Perl,Python,Ruby,PHP等は、何れか一つを深く使えればよく、次はLispやHaskellなど全く違ったスタイルの言語を勉強するほうが良いと思っています。 さらには、実際に本を読むだけでなく新しい言語でそれなりに使えるソフトウェアを開発してみるのが一番理解が早いと思います。 さて、Haskellで何をつくってみようかな。1日程度でできるものが良いですね。
-
ANSI Common Lisp を読む
連休中たっぷり時間があったので、『ANSI Common Lisp』を読みました。 読んでみて、Gaucheのライブラリの多くが、この Common Lisp由来であることが分かりました。 Amazonで見る 実用プログラムを書く上で必要な関数が惜しげもなくGaucheに輸入されています。 そんなわけで、Gaucheは実用プログラムが書きやすいのでしょうね。 この本を読んで、もっとマクロを活用したりして、Sumibiエンジンをもっと読みやすくできると思ったので、さっそくリファクタリングしてみるつもりです。 この本は、2年前くらいに買ったまま,読まずに置いていたものです。(買った当時は難しくて、途中で放置していました。 ) 今回久しぶりに読んでみて、特に詰まる所も無かったので、自分のLisperレベルが上ったかも!と喜んでいます。 Common Lispの本ですが、Gaucheのプログラミングにもそのまま通用する内容が沢山書かれていますので、Gaucheを始めようと思っている人にもオススメです。 追記:この方も書いていらっしゃいますが、この本を読むとLispの処理系を作ってみたくなりますよね。そんな時間はありませんが…
-
何でもGauche
Gaucheという処理系は使えます。 僕のプライベートなプログラミングは全てGaucheになってきました。まさに、なんでもGaucheです。 何がそんなに良いのか。 今日はその辺りを書いてみたいと思います。 それでは、箇条書きで。
-
やさしい機能仕様 - なぜわざわざ書く必要があるのか?
有名なJoel on Softwareの中の やさしい機能仕様 - なぜわざわざ書く必要があるのか?を読みました。 これには同意します。 Sumibi.orgもMail配信型WebリーダーR@eply.orgも機能仕様書をじっくり書いてからプログラムを実装しはじめました。 機能仕様を書くことは重要だと思います。 Mail配信型WebリーダーR@eply.orgの場合は、機能仕様を書き始める前は漠然と、iアプリとしてテキストブラウザを作る予定でした。 まず機能仕様を書いてみて、僕のほしい機能はiアプリではできそうもないということが早い段階でわかりました。 特に、RSSリーダーとして使うためコンテンツをPUSH型にしたかったのと大量のタブ(しかも未読機能付き)をサポートしたかったのでiアプリで作るのは大変そうだということが明らかになりました。 その結果思いついた実装手段がHTMLメールです。(iモードメールの世界では『デコメール』と呼ばれています。) もし、iアプリとして実装していたら途中で疲れ果ててしまってサービス開始できなかったかも知れません。 やっぱり実装方法は抜きにして一度サービスを文章化してみるべきです。 これは個人で余暇を費やしてプログラムを作る場合、なおさらです。 皆さんも、趣味とはいえど、むしろ趣味だからこそ貴重な時間を有効に活用するために、作る前に機能仕様を書いてみてはいかがでしょうか。
-
S式暗号
もし、貴方の書いたソフトウェアをオープンソースにしたいが、ソースコードを暗号化したいという複雑な要求があったとします。 僕はその解決方法を知っています。それはS式で書くことです。 そうしておけば、JavaやPHPしか分からない人にとっては、強力な暗号となります。 その人たちはあまりの小括弧の多さに『うへぇーダメだー』となります。 …というのは冗談で、S式は本当に開発効率が高い記述言語です。 最近、僕はS式でプログラミングすることが多くなってきました。 SumibiもR@eply.orgもS式で書かれています。 でも、S式でオープンソースソフトウェアを公開すると、読める人が少ないせいか協力者を得ることが難しくなります。 近年少しづつ、Lisp系言語への回帰傾向がいたるところで始まっているようなので、それも改善されてくるのかも知れません。 というか、そうなればいいなぁー。^_^;
-
『ソフトウェアの肥大化』と『ムーアの法則』
「ソフトウェアの肥大化」と「ムーアの法則」:中島聡・ネット時代のデジタルライフスタイル - CNET Japan しかし、私は、その方向性はソフトウェアを走らせることが出来るデバイスが 実質的にパソコンしかなく、それも全ての処理をクライアント側で処理するし かなかった一昔前の時代のものだ、と感じている。 携帯電話、カーナビ、テレビ、デジカメ、などのあらゆるデバイスにCPUが入 り、それらがネットワークに繋がってきたユビキタス・デバイス、ユビキタス・ ネットワークの時代には、この「ムーアの法則のおかげで増大したハードウェ ア能力をソフトウェアで全て使い切る」方向性が正しいとはどうしても思えな いのだ。 そんなことを続ける限り、デバイス間でアプリケーションやサービスを共有す ることは実質的に不可能である。ソフトウェアの開発コストは上昇するばかり だし、ユーザー・エクスペリエンスも向上させることはできない。
-
ウェブ進化論
を読みました。 Amazonで見る 僕の日頃からの想いを代弁してくれている本だと思います。すばらしい。 個人的に気になったキーワードを列挙すると『Web 2.0』『ブログ』『ロングテール』『チープ革命』『オープンソース』『情報発電所』『(ネットの)こちら側とあちら側』『組織と個とブログ』です。 これらのキーワードがうまく整理されて説明されています。 本当にいろんな方に読んで頂きたいです。 普段ネットに出かける時間が多い人は当然読まれるでしょうが、それ以外の方にも読んで頂きたいです。朝日新聞に大きな広告が出るそうなのでテレビ等のメディアにも取り上げられるといっきに認知度があがるのでしょうね。 特にオープンソースに関わっている方、ブログを書いていらっしゃる方はこれを土台にして議論が展開されていく可能性が高いので読まないわけには行かないでしょう。 僕は普段から個人的に『Web 2.0』『ブログ』『チープ革命』『オープンソース』等の進歩に恩恵を受けて生活しているので、これからの世の中がこの本の様に止められない大きな動きになるのか早く知りたい所です。 とにかく僕は自分の今やっている事の意味を再確認できたという意味で貴重な読書体験でありました。
-
良い問題設定を
生産的になろうを読んで共感しました。思っていることを書いてみます。 この短い人生で自分が今取り組むべき問題はなにか。 常に何か独創的なものを作りたいと思っている人に付いてまわる命題です。 しかし残念ながら、その人がその時期に思いつくアイデアと実現できる力というのはぴったり合致しないものです。 すばらしいアイデアだけれども今の自分の技術力や経験が不足していて完遂しない事が明白な場合は、もっと簡単な問題から取り組むべきだと思っています。だからといって、手ごろだからという理由でそれを選択するのも違うと思います。 何事も経験が伴っていないとちゃんとしたものはできないと思います。いくらアイデアが良くても。 インターネット上に新しいサービスが出現した時に、『自分もこれ思いついてたんだけどなー』と悔しがる人がいますが、実際に作るという決断をして、時間をかけて実際に形にするのは難しいものです。『もし、そう思うのなら自分で作ればよかったのに』と言いたい。やりはじめるとすぐに判ります。 その人は作らなかった、もしくは作れなかったのです。作らなかった理由としては、実際にはそれほど重要では無かったか、作るには技術力(もしくは時間や環境)が不足していたということになります。『お金があればなあ』というのもこれに含まれます。 もし、このようなシチュエーションに出会った時のために、僕のやりかたを書いてみます。 僕の場合は、良いアイデアを思いついた場合、ちょっと自分の技術力が足りなさそうなものでも、とりあえずtryしてみます。 (どんなものを選択するかという僕なりの判断基準は『 [kiyoka.2006_02_06] 創作心理創作にいたるまのでステップ(2) 』に書きました。) そして実際にそのアイデアの一番重要な部分を1日ででっち上げてみます。 コア部分があまりに自分には歯が立たない問題であったり、意外と面白くないものであったりした場合はそこで中止となります。 プロトタイプを使ってみると『案外面白くないではないか』というモノも有りますので。 実は、現在開発中のWebリーダーでもコア部分を作ってみて、イケル!ということがわかったのでどんどん進めています。 2年前だと自分の技術力は完全に不足していたでしょう。 良い問題設定とはタイミングという要素もからんできます。難しいですね。
-
一人プロジェクトと『鳥の目』
僕も江島さんの記事に激しく同意します。ちょうど同じことを考えていたところです。 僕もクリエイター受難の時代が終わって状況が変わってきたと思います。
-
創作にいたるまのでステップ(2)
前回、新しいものを作る場合、いかに自分の心理状態をコントロールするかが重要だと書きました。 実は、自分の心理状態をコントロールする前にもっと大事なことがあります。それは『企画』や『アイデア』です。 特に仕事ではなく趣味として自分が楽しみながら続けていくために、どんなアイデアを採用すればよいかを書きます。 個人的には次の点を心がけるとうまくいくと思います。 ※重要と思うものから順に並べています。 できあがったものが、ありきたりでないこと(新規性・驚き) 日常的に自分が使うもの 作る過程が楽しいこと 作るのに壮大な時間がかからないこと 昔は、ついつい 1. を追いかける余り、 4. に反するアイデアのものを頑張って作ってました。よく自分のスキルを超えるモノを作ろうとして失敗していました。 オープンソースソフトウェアが沢山存在する昨今、自分で作らないといけないものはかなり少なくなってきている気がするのでますます壮大な時間を費やす必要は薄れてきています。 それよりも既存のオープンソースソフトウェアを組みあわせて少ない時間で驚きと楽しさのあるものを作った方が何倍も有意義です。 Sumibi.orgは一応これらの条件を満たしていると思います。 ちなみに、今作っている『携帯向けブラウザ』もこれらの条件を満たしています。(但し、順番は 2. 1. 3. 4. かな?) 問題は、作るスピードよりもアイデアが生れるスピードのほうが早いということですかね。^_^;
-
創作にいたるまのでステップ(1)
僕にはオープンソースソフトウェアを作るという趣味があります。 作るといっても、既にあるオープンソースプロジェクトに参加するというよりも、自分で一から立ち上げることに楽しみを感じる性質のようです。 いつも微妙なものを作っては回の人たちを困惑させてしまうというパターンが定着しつつあります。 ^_^ さて、新しくものを作る(創る)場合、いかに自分の心理状態をコントロールするかというのが勝負になります。 まず、自分の貴重な時間を使ってでもやる意味があるかというのが最初の関門です。 そして、その最初の関門をクリアしたアイデアだけが採用となります。 僕の場合、アイデアの評価基準としては新規性というのがかなりの比重を占めます。誰もやっていないことをやるのが基本です。基本的には誰もが願っていることだと思います。 逆にこれがあるから既存のプロジェクトに参加するのはちょっとものたりない気がするのかも知れません。 もし、その第一関門を突破したら次に実験段階に入るのですがここでも、かなりのアイデアが脱落していきます。 一人ではとてもスケールが壮大過ぎて作れないもの等もこの段階で中止となります。 なかなかここを通過するアイデアは少ないのですが、そこを通過すれば本格的な創作開始となります。 『あんた、それがその何かい?Sumibi.orgというやつかい!』というツッコミは無しでおねがいします。 また続きを書きます。
-
『図解 実戦マーケティング戦略』を読む
図解 実戦マーケティング戦略 著者: 佐藤 義典 Amazonで見る 近所の中古本屋で買いました。 あまり期待せずに読んだのですがなかなか参考になりました。(但し、買う価値あると思ったので買ったのですが。) 個人サイト等のマーケティングにこの本のツールを使えば、分かりやすく役に立つサイトを作れそうです。 特に、ポジショニングや伝わるメッセージの組み立て方など、思考ツールを使わないと答えにたどりつきにくい問題を分かりやすく解説しています。 この本は戦略BASiCSという思考ツールを丁寧に紹介するという内容になっており、後は実際に使ってみてくださいというものです。 『実戦マーケティング戦略』というタイトルのとおり実戦で使ってみようと思います。 まずはトレーニングとして新サービスに適用してみます。
-
コトラーのマーケティングの本を読了
読了といっても、自分に必要な部分だけです。なにせ900ページ弱もあるので。実質ページ数でいうと3分の1程度しか読んでいません。 コトラーのマーケティング本は巨大組織におけるマーケティングの実践方法について書かれているように思えます。 僕の様に巨大企業ではない職場で働いていて、しかもマーケティングの勉強は自分の趣味であるオープンソースソフトウェア開発に応用出来ないかというところから始まっているので、あまりにもスケールが違いすぎる章が多いです。 マーケティング原理 第9版―基礎理論から実践戦略まで 著者: フィリップ コトラー, ゲイリー アームストロング, Philip Kotler, Gary Armstrong, 和田 充夫 Amazonで見る しかし、巷の和書のマーケティング本だけを読んでいては体系立ってマーケティングを理解できないので、あわせて読むと良いでしょう。 コトラーの本で一番良い所は、丁寧に言葉の定義をしながら進んでいく所です。理解が明確になり、マーケティング本でよくあるような曖昧な例え話で終わっていません。 また、実例が豊富で読んでいても楽しいです。中を開けて見るまで信じられないでしょうがコラム等が沢山あり楽しいです。 おすすめの一冊です。 他にも、個人スケールにあった本も読んだのでそれも後日紹介します。
-
アフィリエイトバブルの崩壊
最近、どんなブログを見てもアフィリエイト広告が掲載されていますね。 かくいう僕のkiyoka日記にもamazonのアフィリエイトを掲載しております。(収入はほとんどありませんが…) 世の中には嘘か真かわかりませんが月に100万円もの収入があるよというブログ記事が沢山あります。 逆にそのような記事でしか他の人がどれくらい収入があるのかわかりません。 なんか面白いですね。 アフィリエイトで儲かるという記事を書く人が沢山のページビューを稼いで沢山儲けているという異常な状態が続いているようですね。 そういうサイトを沢山見ていくと、もうそのような話題では人が集らなくなったのか、はたまた疲れてしまったのか、もう収益報告をやめますという人が多いです。 ということは、みんな小手先の努力では儲からないということがわかってきて、そのようなページを見にいかなくなり異常なループが成立しなくなったのですかね。 この現象は株のバブルと同様に考えると『アフィリエイトバブルの崩壊』という感じでしょうか。 早めに始めて早めに止めるという必勝パターンまで株のバブルのときと同じですね。 後は良質な本物のコンテンツが生き残るという正常な市場が形成される、と。 もうそろそろ、その時期でしょうか。そうなればいいですね。
-
コトラーのマーケティングの本
僕は、時々マーケティングの本を読みます。 単純に技術的な興味だけでオープンソースを作るというのも楽しさ半減だということが最近わかってきたからです。 趣味でやっているといえども技術的に面白いだけでなく、世の中の役に立つものを作って共有したいという想いが強くなっています。 特に、今Sumibi.orgというWebサイトで世の中の役に立つサービスを提供し、沢山のユーザーさんに利用して頂いているので、マーケティングを本だけでなく実体験として勉強できる環境があります。 僕はこれまでオープンソースソフトウェアをコミュニティーで開発しいろんな凄腕のプログラマからアドバイスをもらう体験してきました。 今後は、生活必需品としてサービスを利用する人と一緒にさらに経験を積んでいきたいと思っています。 マーケティング原理 第9版―基礎理論から実践戦略まで 著者: フィリップ コトラー, ゲイリー アームストロング, Philip Kotler, Gary Armstrong, 和田 充夫 Amazonで見る
-
良きライバルは必要か
最近、SumibiのEmacsクライアントの改善を行っていました。 Emacsのoverlayという機能を使って実装したのですが、一番苦労したのは、GNU EmacsとXEmacsの両方で動くようにする作業です。 僕は普段GNU Emacsを使っているのですがGNU Emacsで『上手く動いたー』と思うのも束の間、次の瞬間にはXEmacsではちゃんと動かないことを知って愕然とします。 Emacsは一つでいいと思っているのは僕だけではないはず。 それともIEとFirefoxの様に何でもライバルの存在は必要なのでしょうか? XEmacsが存在したことで競争を促しGNU Emacsが今の様な画像表示機能やその他諸々の機能を実装したといえなくもないかな。 やっぱり受け入れざるを得ないのでしょうか。
-
ピアノハッカー、キース・ジャレット
2005年来日公演があったので 10月17日(月)の大阪公演を見てきました。 感動でした!全編アドリブ曲で映画音楽の様な美しいメロディーが次から次へと生まれては消えていきます。 ザ・ケルン・コンサート 著者: キース・ジャレット Amazonで見る まさに、ピアノハッカーです。完全なるハッキングです。 また、日本に来られるのは 3年ぶりだそうなので大変貴重な公演でした。 アルバム『ケルン・コンサート』とは違って、バラードとアップテンポの曲が交互に生み出されていきました。 公開録音だったので、もし大阪公園がCDとして発売されたら絶対買いです。 僕の敬愛するpiano nerdsビル・エヴァンスはもうとうに亡くなってしまったので、生で堪能できる好きなピアニストはキース・ジャレットくらいしか無くなってしまいました。残念。
-
CodeFest Kyoto 2005参加
CodeFest Kyoto 2005という、イベントに行ってきましたので一応どんな事をしていたか書きます。(Sumibi-dev MLに書いた内容とかなり被っています。) 金曜日の17:30くらいに会場に到着し、ちょっと上記のWikiの設定などを行った後、Anthyの田畑さんと同じくAnthyの吉田さん(oxyさん)とSumibiの変換アルゴリズムや、辞書の構造などいろいろ雑談っぽくお話しさせて頂きました。 shelarcyさんとも初めてお会いしました。僕の作ったSxmlcnvというソフトウェアを使っていただいています。Kahuaはsxmlライブラリのバグが直ているので参考に直してくださいとのことです。了解しました。 後、Sumibiの辞書の再配布方法など田畑さんに助言を頂きました。また、oxyさんにSumibi.orgで遊んで頂き、『えっ?SOAP?』と興味を持っていらっしゃったのでネタでsim-sumibiを作って頂けるかも知れません。もちろんプレゼンでのつかみネタ程度のモノを考えておられると思いますが… 他にも、今後AnthyもWikipedia日本語版を読み込んで統計的アプローチも取り入れる予定だという話をされていました。 最後に、田畑さんが漢字変換エンジンなんか作ってても尊敬されないとか、PRIMEを開発されている方から『Anthyがちゃんとしているから、他の漢字変換エンジンが心置きなくネタに走れる』と言われたとぼやいていらっしゃったのが印象的でした。ついでに『すごく共感します。Sumibiもネタに走れるのはAnthyがちゃんとしているからです。』という事を伝えておきました。(^^;) 僕はその日の22:00頃 会場を出たので、それまでの間Anthy関連の人を質問攻めにして一行もコードを書いていません。もしかしたら、コンピュータ持たずに手ぶらで行っても良かったかもと思っています。^^; 自宅に戻ってからはドキュメントしか書いていませんし。 コードは一行も書いていませんが参加してみて有意義なイベントでした。また、関西で開催されれば参加したいです。
-
『検索エンジン戦争』を読む
検索エンジン戦争 著者: ジェフ・ルート, 佐々木 俊尚 Amazonで見る 図書館に行くと新刊の棚に置いてあったので、読んでみました。最近のサーチエンジンの開発元は買収につぐ買収でサーチエンジンと開発元の関係がさっぱり追えてなかったのですが、この本でやっと把握できました。よくまとまっています。 また、なぜmsn,yahoo(もちろんgoogleも)が検索エンジンを自前で作って戦おうとするのかもわかりました。結局のところ、現在はWebの入り口は全て検索エンジンになってしまっているので、そこを押さえてしまった者が全てを手にするというわけですね。 そういえば、僕も最近ブックマークはあまり使わずに、’nikkei’とか’apple’とか ‘cnn’ とかで検索して目的のサイトに行きます。まして、URLを直接打ち込んでサイトに行くなんてことはもう誰もやらないでしょうね。 この本を読みながら広告ビジネスとSumibi.orgを組み合わせて考えていくといろいろ面白いことが思いつくのですが、あまりやると暗黒面に落ちて行きそうなので、オープンソースコミュニティーにそっぽを向かれるようなことにならないように抑えるつもりです。実験的な、又はネタ的なものならいいでしょうけどね。 フォースの力をむやみに使ってはいけません。オープンソースの力は信じて使っていきますけどね。
-
[自然言語処理ことはじめ―言葉を覚え会話のできるコンピュータ』を何度も読み返す
自然言語処理ことはじめ―言葉を覚え会話のできるコンピュータ 著者: 荒木 健治 Amazonで見る 自然言語処理の本なのですが難しい本ではありません。専門家でなくてもわかりやすいように書いてあります。 しかも、この本は最初から最後まで一貫して夢があって楽しいので、何度も読み返してしまいます。 これから、自然言語処理をやってみようと考えている方は、まずこの本でワクワクしてからスタートすることをお勧めします。
-
『ランチェスター戦略「弱者逆転」の法則』を読む
ランチェスター戦略「弱者逆転」の法則 著者: 福永 雅文 Amazonで見る 僕の回りではマーケティング関連の本を沢山持っている人がいるので、オススメの本を借りて読んでいっています。 確かにこの本はオススメです。シェアナンバーワンと二位以下で取るべき戦略が違うというのは非情に納得できます。 オープンソースソフトでも何でもいいんですが、これから何かを世の中に出してできるだけ反応を得たいと思っている人は一読です。 僕もいままで漠然と自分の作りたい or 使いたいソフトウェアをオープンソースとして作っていましたが、今では次の一手を考える時にこの本の基本戦略も考えるようになりました。 [Sumibi]で言うと日本語変換全体でのユーザシェアでナンバーワンは取れないのは明白なので、ニッチな世界でナンバーワンに近づける様に、今はどんどん差別化する段階だということになります。
-
紙飛行機の思い出
ふと、僕が小学生の時、近所の幼なじみと紙飛行機を作って遊んだことを思いだしました。 僕は昔から、何かを作るということが好きでした。 特に、ねんどやダンボール箱をこねくりまわして、車やヘリコプターなどを作った事を覚えています。 ある日、いつものように幼なじみと紙飛行機を作ってどちらが遠くまで飛ぶか競争をしていました。 二人とも試行錯誤を繰り返したあげく、遠くまで飛ばすのにも飽きてしまいました。 そうなると、僕は距離よりも少しでもかっこよく速く飛ぶ飛行機の製作に興味は移って行きます。 結果思いついたのが、紙飛行機の先端を折鶴の頭部の如く下向きに折り曲げて、先端を重くして航行速度を上げるという アイデアでした。作ってみると外観も本当にかっこよく、真っ直ぐ飛んだのをよく覚えています。 続いて、幼なじみも負けじと同じアイデアで先端の折り曲げる量を変えたりして、宙返りが簡単にできるカッコイイ紙飛行機を作りました。 その時、僕はなんと子供だったのでしょう、『人の真似は禁止』とつっかかっていって、その幼なじみの紙飛行機がどんどんかっこよくなっていくのを根本から阻止しようとしました。 普通ならタダのガキのよくある風景だなと思うだけで通り過ぎるかも知れませんが、僕はここで知的財産権とソフトウェア特許に重ねあわせて考えてしまいます。 『自分のアイデアを真似されたくない』これは根源的なものなんでしょうか。 オープンソースソフトウェアのメリットを実体験している今となっては、過去の自分が愚かしく見えますが、子供の頃の自分がそんなことを言ったということは、なんの疑いもなくアイデアの無断利用は間違いだと思っていたし、それが常識だったのかもしれません。 その後は、幼なじみの抗議を受け入れ、仲直りして紙飛行機を改良しては二人でスゴイスゴイと言いながら楽しく遊びましたが、今でもその時の幼なじみの抗議での『なんと理不尽な』という表情は忘れていません。 アイデアの再利用のメリットは大きいけれども、それを身を持って体験するというのは貴重です。 僕は、何時からアイデアの再利用・共有の推進派になったのでしょう。しかもオープンな再利用の推進派に。 残念ながら何時からかははっきりしません、こういう経験の連続で少しずつ考えが固まっていったのでしょうか。
-
『パターン認識と学習の統計学―新しい概念と手法』を読む
『パターン認識と学習の統計学―新しい概念と手法』を読む パターン認識と学習の統計学―新しい概念と手法 統計科学のフロンティア 6 著者: 甘利 俊一, 麻生 英樹, 津田 宏治, 村田 昇 Amazonで見る 実際はゴールデンウィークにマーケティングの本といっしょに読みましたが、今頃書いています。 結論からいうと今開発中のSumibiの役に立ちそうなアイデア・手法は載っていませんでした。 この本に書いてある内容は、主に『学習データが少ない場合にどうやってパターン認識の性能を上げるか』ということに重点が置かれています。 一番の収穫は『学習データが沢山ある場合は別段工夫しなくてもある程度性能が出る』という事が分かったことです。 といっても、僕の知らない統計的学習の手法がたくさん紹介されていて面白かったです。 Sumibi の場合は力技アプローチを採用しているので、ある程度、変換性能が出るという事でしょう。 ところで、マーケティングの本と一緒に読むとなんか不思議な感じがします。 一見、共通点が無さそうな気がしますが、実はどちらも人間の無意識を扱うという点で共通点があります。 マーケティングは人間の無意識を解明し、人間の欲しいモノを作るというテーマですし、パターン認識の方は人間が無意識で行っている事を解明し機械にやらせるというのがテーマです。 最近、僕は無意識の解明・最大限の利用というテーマに興味があるようです。
-
『心脳マーケティング』、『コトラーのマーケティング・コンセプト』を読む
マーケティングの本です。ゴールデンウィーク中に読みました。 僕はあまりマーケティングの本を読んだことがないので、他のマーケティングの本と比べた感想は書けませんが、次のようなことはこの本を読むまで考えもしませんでした。いわれてみれば自分の経験と照らし合わせると納得できます。 以下第2章の概要の引用です。 心脳マーケティング 顧客の無意識を解き明かす Harvard Business School Press 著者: ジェラルド・ザルトマン, 藤川 佳則, 阿久津 聡 Amazonで見る 多くの読者が驚くべき事実に直面することだろう。たとえば、消費者の思考内 容の95%が無意識のうちに起こっているという事実や、その思考内容の多くは メタファーを通じて掘り起こすことが可能であること、マーケターが無意識の うちに考えていることが、意識して考えていることと同様に、消費者の考え方 に影響を及ぼすこと、などである。 この本に書いてある、『我々の認知活動のまさに95%を越える部分が無意識のうちにおこなわれている。』ということが本当なら、ユーザーが本当に欲しいソフトウェアを作るためには、マーケティングを抜きではかなりムダの多い活動をしているということになるのでしょう。むしろ、ユーザーが本当に欲しいものを作る方法がマーケティングということでしょうか。 フィリップ・コトラーの『コトラーのマーケティング・コンセプト』の序文にも同様の説明があるので、引用しておきます。 コトラーのマーケティング・コンセプト 著者: フィリップ・コトラー, 大川 修二, 恩藏 直人...
-
リチャード ドーキンスの『遺伝子の川』を読む
遺伝子の川 (サイエンス・マスターズ) 著者: リチャード ドーキンス, Richard Dawkins, 垂水 雄二 Amazonで見る 僕はリチャード・ドーキンスのファンです。今この本を図書館で借りてきて読んでいます。 この本で知った一番の驚きは、動物の神経を通る情報がアナログ量ではなくパルスであるという事です。つまりデジタルという事です。 だから脳味噌から腕の先まで2000回の信号の中継機によって再増幅があっても情報が劣化しないという訳です。 キリンの首はあんなに長いけど、ちゃんと情報が正確に伝達されているのだろうかと思っていました。これで謎が解けました。 DNAも結局デジタル(4進法の数値データ)だし、僕等はデジタルで過去と繋がっているのですね。 でも、この本で『ブートストラップ』のことを『ブーストラップ』と書いてあるのが気になった。誤植ですか? それにしても、10回以上この間違いが繰返されていると読むときのリズムが狂うんですけどね。 でも、この本古いけどほんとに素人にもわかりやすく書かれています。
-
No config is good config
直訳すると『設定が無いのが良い設定』という意味ですね。意訳すると『設定不要なモノが良いデザイン』でしょうか。 このポリシーは、自分の作ったソフトウェアをなるべく多くの人に試して欲しいと思っている人には重要なポイントになると思います。ポチさんところで知りました。高林さんが発信されているポリシーはいつも参考になります。 最近、有名タブブラウザSleipnirの作者の方とお話させていただいたのですが、彼もこのデザインポリシーの信奉者であることが伺えました。技術に明るくないユーザーにも使ってもらうとなると、特に重要になるのは当然ですね。 そういえば、以前僕がPRIMEを試してみようと思った時に、インストールが面倒だったので、試すのを躊躇したことを思い出しました。
-
オープンソース参加を経済の言葉で考える
少しばかりオープンソースの世界に参加してきた僕の経験をもとに、オープンソースの世界に参加する場合のコツをお教えします。ポイントは投資と回収のバランスです。オープンソースに参加するには自分の使った時間または満足度が黒字化しているかどうかに思いを巡らせながら活動すると幸せな生活が送れるんじゃないかと思います。投資とは、日頃あなたが使用するソフトウェアを改善するために使う労力です。回収とは、そのソフトウェアを使って得られた生産性や満足度ということになります。もし、それが黒字化していればあなたは幸せでしょう。 一般にオープンソース開発やバグフィックス・テスト等はボランティアといわれますが、上記の用にコストとベネフィットという考え方に置き換えれば、開発者は受益者でもあるといえます。また、無数のオープンソースソフトウェアを大きなポートフォリオと考えるなら、一部のソフトウェアに投資して、別のソフトウェアから回収しても良いでしょう。問題は、「フリーライダー」と呼ばれる人々です。この人達は投資を行っていないにもかかわらず、先に利益だけを得ようとしています。人にもよりますが、これは精神衛生上幸せではないでしょう。ちょうどいい黒字バランスが幸せを生むのだと僕は考えます。
-
Kinesisを買う
遂にキーボード入力へのこだわりが高じて、このような廃人的キーボードを買ってしまいました。 Kinesis (http://www.kinesis-ergo.com/) Kinesis を持っている人のサイトをいろいろ見てみると、いろんなキーボードを買って行くうちに、とうとうここにたどり着いてしまうみたいです。僕も遂にたどり着いてしまいました。1週間使ってみましたが、なんか最終目的地にたどり着いたような使用感があります。これまで、Happy Hacking や Microsoft Natural Keyboard などを試しましたが。Kinesisは他と比べものにならないくらい考えられています。まず、全てのキーが自然な位置にあり、ほとんどのキーに最小距離で届きます。横着者のコタツ生活を彷彿とさせる横着キーボード生活です。普段僕は、マウスをほとんど使いませんが、これでますますマウスを使わない生活が続きそうです。
-
Lisp プログラマのための Python 入門
Lisp プログラマのための Python 入門 にわか Schemer かつ Emacs Lisper なのですが、この記事を読んで、Pythonもやってみたくなりました。最近、趣味プログラミングではGauche ばかり使うようになったんですが、仕事ではPHPを使うことが増えていきそうな感じです。最近、Perl,Ruby,Gauche,Java を順に切替えて使っていくとそれぞれの良さが分かって来て、TPOで言語を選択できるようになってきました。また、いろんな人がいろんな言語を選択するので仕方なく全ての言語を習得する必要があった感じもあります。個の程度の数の言語であれば、混乱無く使えますがこれ以上増えると大変似なるので、Python をやるのはもうちょっとしてからかな。
-
デッドラインを読む
デッドライン―ソフト開発を成功に導く101の法則 著者: トム デマルコ, Tom DeMarco, 伊豆原 弓: 本 Amazonで見る 内容については結構楽しめました。少し簡単すぎるほど、鮮かに問題が解決してしまうところがいくつもあって、あんまり苦労らしい苦労が無い物語になっている。なので、小説としてはちょっと物足りない部分はある。もうちょっと「ザ・ゴール」のように、成功するまで多難な感じが欲しかったが、ノウハウ本として考えるとこれでいいのかもしれない。どちらにしてもデマルコらしい内容なので、デマルコファンは一読をお勧めする。
-
宣言型言語
C言語やPerlなどが手続き型言語だと定義すると、SQLは宣言型言語だといえると思う。宣言型言語は、適用できる範囲が限定される代わりに、いざ目的にぴったりマッチした場合は少ない記述量でものすごい仕事をする。最近SQLを使うことがぼちぼち出てきてそう感じる。ちなみに、もちろん僕の好きなLisp/Schemeも宣言型言語の側面が大きい(関数型言語の特徴でもあるかも)。再起的定義をたくさん使ったプログラムはもろ宣言的だ。反対に、手続き型的な記述も可能だ。ちゅうわけで、今のところSQLとSchemeでWebプログラミングを行うとすごく強力なコードが短く書けるので気に入っている。
-
Olegさんよりメールをもらう
本記事で言及しているOlegさんのサイトは http://okmij.org/ftp/README.html です。 いつも僕のようなへっぽこプログラマの相手をしていただいてありがたく思う。メールの趣旨は、最近Lisp/Schemeの価値が少しずつ理解されてきたという内容。ボストンのUsenixコンファレンスでSXMLを銀行のトランザクションとして使おうとしている人と話をしたこと、有名なNetBSDカーネルハッカーと話をして、その人はLisp/Schemeの価値に気 づいていることなど。(Olegさんも十分有名人なんですけどね)。こんなメールを頂けるなんて、オープンソースに携わっている身としてはうれしい限りである。今後も微力ながら役に立つも のを作っていきたい。(僕の場合、アイデア一発物ばっかりなんだけどね。)
-
ノーム・チョムスキーの「生成文法の企て」を読む。
コンパイラやコンパイラコンパイラの本を読むと出てくる名前なんだけど、今回初めてこの人の本を読むことになった。この本は対談形式の本なんだけど、研究者というのは幅広い知見が求められてたいへんなんだなと感じた。僕は、エンジニアなので残念ながらウマみだけをエンジニアリングに利用させてもらうぞ。そのウマみだけ抽出できるかどうか、いろんな本を読み込み中。