kiyoka日記

# [OldType][ブログ] ブログのURLを再度変更

ブログのURLをこちらに変更しました。

まだ、コメントしたり、トラックバックしたりできませんが、そのうちはてなスターを使ってコメントを入力できるようになる予定です。

今後ともおつきあい下さい。

# [OldType][ブログ] ブログを引越し

ブログをこちらに引越ししました。

tDiaryよりも簡単に書けるということもあって、新しいURLで書いていきたいと思います。

まだ、コメントしたり、トラックバックしたりできませんが、そのうちコメントや書きこみもできるようになる予定です。

URLも変わる可能性があったり、流動的ですがお付き合い下さい。

# [OldType][ブログ] WiLiKiの編集モードとして利用する(emacs-w3m専用)

こちらのブログもどきに書きました。

emacs-w3mでWiLiKiを編集している方は一度お試し下さい。

# [Wiki]JottitはシンプルなWikiサービス

とってもシンプル。

最初、チュートリアルも何も無いので、空っぽのテキストアリアを前にして途方に暮れたましたが、

それも束の間、意を決して適当に文章を入力して『Create a Page』ボタンを押すと...

早速ページとパーマリンクが生成されてしまいました。

チュートリアルページも無しで使えるなんて... カルチャーショックでした。

見習うところが沢山あります。

ちゃんとユーザビリティーテストを沢山やったんだろうな。感心です。

# [プログラミング] RubyのリハビリでFizzBuzz問題

同僚からRubyの質問を受けることが多くなりました。

というわけで、RubyのリハビリがてらにFizzBuzz問題をやってみました。

ええ？Rubyに見えないって？

Ruby on Railsやる人はこれくらいのコードは書けないといけないようです。^^

P.S. 関係ないですが、それにしてもtDiaryのソース貼りつけは落とし穴いっぱいですね。空行はダメなんですね。ちょっとハマりました。

#!/usr/local/bin/ruby
 
fizzbuzz_in_range = lambda { |range|
  fizzbuzz = lambda { |x|
    (0 == x % 15) ? "FizzBuzz" :
    ((0 == x % 3) ? "Fizz" : 
     ((0 == x % 5) ? "Buzz" :  x.to_s)) }
  range.map( &fizzbuzz ) }
 
print fizzbuzz_in_range.call( (1..100) ).map { |x| x + " " }, "\n"

# [OldType]悩みどころ

開発中のOldTypeの悩みどころについてです。

Webからのコンテンツ編集機能は行単位でできるようにしたいと思っているんですが、そうするためには編集ページを正しい文書構造を持ったHTMLにできないという問題に悩んでいます。

ulやolタグを使うと、行単位の編集が以降の行のインデント量に影響を与えるので、行単位で編集した場合でも影響範囲はその行に閉じないということに気が付きました。

かといって、ulやolタグの使用をやめて、preやdivとCSSでレイアウトをコントロールしてしまうと、w3mなどのテキストブラウザではドキュメントが正しいレイアウトで表示できないという問題があります。

これは、段落やページ単位で編集するWikiエンジンには不要な悩みです。

妥当な解決策としては表示ページは正しい文書構造を持ったHTML、編集ページはpre等でレイアウトしたページということになるのですが、なんかスッキリしないです。

理想的なUIとしては、特別に編集ページを用意したくない(w3mで見たい時は別)のでもうちょっと考えてみます。

もっとエレガントな解決策が無いかを探しています。

# [プログラミング] Schemeのlambdaがようやく分かってきた

なんでもλを前に何度も読んだけど、自分のモノになってなかったようです。

最近、named letと継続渡しオンパレードなWiLiKiのパーサをいじることで、ようやく全部同じだという感覚が掴めました。

何なんでしょう。こういう質の高いチュートリアルを読んでも掴めなかった感覚が実際に自分でやってみると掴めるというのは。

なんでも経験ですね。

誰か『なんでも経験』ていう文章書いて下さいませ。

# [デザインポリシー][OldType] 悪い方が良い原則

The Rise of Worse is Better(悪い方が良い原則)

なるべくこの原則に従うように、Wikiエンジンを設計しています。

特に、プラグインの作者にとって、普通のUNIXコマンドラインのプログラミングで機能追加できるようにしたいと思っています。

理想的には、bashで10行位のプログラムが書けたら、即プラグイン作者になれる様なイメージです。(本当にできるかな、という不安もまだあります...)

例えば、wgetでSimpleAPIにアクセスし、結果のサムネイルをページに埋めこむプラグインなんかは簡単にできるかなぁ。

仕組みも実装もシンプルになるように設計を練っているところです。

# [OldType]WiLiKiのパーサを流用してパーサを作る

WiLiKiのソースを読んでいくと、かなりモジュール化がしっかりしているので、パーサ部分をそのまま流用させてもらう事にしました。

これでOldTypeのライセンスは自動的に修正BSDに決定です。(注意:Emacs Lisp部分だけは例外でGPLv3です。)

流用したらパーサが簡単に作れました。パーサは1ファイルで独立しています。

モジュール化重要ですね。

結局、<<< 複数行 >>> で verbatimになるルールはそのまま残して '!' で始まる行を 1行単位で verbatim になるルールを追加しました。

実際に元のルールを壊さずにパーサを改変しようとすると勉強になります。

元のソースを理解していないと手を入れられないわけですから。

さらっと読んで理解したつもりになるのとは雲泥の差があります。

(使ったソースはCVS版の parse.scm,v 1.6 2007/05/02 10:37:17 shirok です。)

# [創作心理][OldType]独りで始める Concrete and Specific Programming(CSP)

Inemuri nezumi diary(2007-08-22):独りで始める Concrete and Specific Programming(CSP)

これは釣り的エントリーでしょうか。ちょっとネタ風味な所があります。まあ、釣られてみましょう。

同意できる所と同意できない所があります。

同意できる所は、最初に『夢』物語を書くところです。人生を無駄づかいしないためにも、完成イメージを描いてみてダメそうなら捨てるという部分は賛成です。

でも、実装をいちばん最後にしてしまうところは賛成できません。

なるべく最初にプロトタイプを作って触ってみる事が重要だと思います。

関連する内容は次の記事が参考になります。

50%の完成度でサービスを出す：近藤淳也の新ネットコミュニティ論 - CNET Japan

Getting Real by 37signals

私の場合はこの二つの混合かな。

ちなみに、OldTypeは前述の『CPS』には向かないプロジェクトだと思うんですが、出だしはCPSと同じようにドキュメントに傾倒した感じになっています。

今後は作っては使うといういつもの繰返しになっていくでしょう。