 | !kiyoka.blog.2008_02 | [RecentChanges] [AllPages] (Late      Latest) |
| !kiyoka.blog.2008_02 | [RecentChanges] [AllPages] (Late Latest) |
kiyoka日記。OldType、Sumibi.org、日々の出来事など。
最新10件!kiyoka.blog 過去記事一覧!kiyoka.blog.list
(似顔絵イラストメーカーで作りました)
先日、kiyoka.2008_02_14でユーザインタフェースの実装案を書いたが、
今日、増井さんの昔の雑誌記事を読み返したら、私が後を追い掛けてただけだということが判明した。
前に何回も読んでいたので、けっこう参考にしていることは思っていたけどここまでとは...
まあ、分かってしまうと面白くなくなってヤーメタとなる人と、それでもやる人に別れるわけで、私はやる側にまわるよ。
次の本も同じで、
Amazon.co.jp： 誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書): ドナルド・A. ノーマン,野島 久雄,D.A. ノーマン: 本
とか
Amazon.co.jp： パソコンを隠せ、アナログ発想でいこう!: ドナルド・A. ノーマン,安村 通晃,岡本 明,伊賀 聡一郎,Donald A. Norman: 本
とか、を読んで『あー面白かった』で終わるか、実際に作りながら試行錯誤したり設計したりしながら納得するのとでは大違いだと私は思うから、私は作る。
いろんなものに挑戦しているうちに、便利なだけではなく使っていてクセになるようなソフトウェアが作りたいと思うようになった。
ちなみに、Ruby ono Railsで有名なDavid Heinemeier HanssonもInstikiっていうWikiを作っていたりしてたんだね。David Heinemeier Hansson in Instiki
Schemerはこんなコードを書きたいと思うはず。defとlambdaは同じであるべきだ。
def func1( x )
x + 1
end
p [1,2,3].map( func1 )
なんでdefは内部でlambdaに置換されないんだろうか。えっ？class/moduleとの整合？私はそんなの知らない。
ところで、Ruby1.8.6ではクロージャをmapに渡すためにはこう書くしかない。
- twitter: func1 = lambda {|x|
x + 1
}
p [1,2,3].map {|x|
func1.call(x)
}
せめてこれくらい書ければいいなぁ。
func1 = lambda {|x|
x + 1
}
p [1,2,3].map( func1 )
でもエラーとな...残念だ。
bash-3.2$ ruby ./t.rb
./t.rb:5:in `map': wrong number of arguments (1 for 0) (ArgumentError)
from ./t.rb:5
私が知らないだけで本当はもっと簡潔に書く方法があるのかな？
準備
今回のデモのテーマは『Wikiはもっと楽しくなる』にする予定。
デモ中にウケを狙いたいが為だけに、Amazonアフィリエイトの表示機能を追加したくなってきた。
単に、あるDVDのパッケージの写真を使いたいだけなんだけどね。
デモ中に説明はしないけどチラっと見える内容でも楽しめた方が良いかなと思って。
おたのしみに。
この記事は必読。デベロッパーズ・サミット2008で講演するジョエル・スポルスキー氏の講演
私が以前から思っている事を分かりやすく言ってくれている。
そう、『見ため重要、マーケティング重要』
技術が凄い、深いっていうだけでも分かる人には分かる。でも、分かる人は少ない。
そのソフトウェアはコミュニティーが濃いので価値は高いという考えかたもある。
でも、それだけではNo1にはなれない。ここではNo1とは知名度、ブランド、マインドシェアで見た場合のNo1の事を指す。
RubyとかRuby on Railsはそのへんうまくいっている例だと思う。
Rubyは楽しくプログラミングするというマーケティングがうまく成功している。
Ruby on Railsはかっこ良さと生産性の高さがうまく合わさって(必要以上に)うまくいっている。
Sumibi.orgはそのへんマーケティングとかにはかなり頑張ったんだけど、OldTypeでも頑張ってみる価値アリだと思った。
準備
kiyoka.2008_02_14で書いた件の『Webブラウザからの編集UI』を仮実装してみた。(まだ変更内容の反映はできないけど)
これはgauche.nightデモするためだけのものだが、このイメージで反映まで行けるはず。
文章をクリックすると各行の編集画面がスルスルと下りてくるよ。(!で始まるWikiページでは何も起きないので注意)
明日からはプレゼン資料を作っていく予定。デモの時間は5分なので図を多めに構成しようと思う。
がされた
私としてはこれが一番うれしい。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側で対応したものがリリースされるまで待ちだね。
参考リンク
どんなUIにすればユーザビリティが高いのか。
大量の更新はSubversionから直接更新し、少量の訂正や1行コメント程度の短いメッセージはWebから更新するという方針でデザインしている。
つまり、Webからは文章の構成を大幅に変えるような大規模な編集を切り捨てても良いと思っている。
そうすると、どんなインターフェースになるのか。気をつけたいポイントは次の通り
なるべく多くのフィードバック
単順に考えると、リアルタイムでフィードバックするのが良さそうだが、あまりやりすぎると認知的負荷がかかって逆効果かもしれない。
特に、画像やYouTube動画の貼付はフィードバックがリアルタイムである方がうれしいと思う。
モードレス
閲覧モードや編集モードのようなモードの概念を無くし、閲覧画面上でそのまま編集できるようにする。
早目のコンテンツ登録
何行分もの変更をためてからサーバに投げるのではなく、1行の変更の都度マスターDBに登録する。
Subversionは並行編集が可能なシステムなので、変更のコンフリクト問題は本質的に避けられない。この問題をなるべく避ける。
現段階での解決案は次の通り
編集したい場所をクリックすると入力エリアが出てくる。
入力エリアで編集するとリアルタイムで当該行に編集後のイメージがフィードバックする。
サブミットボタンを押すと即commitされる。
新しい行の生成手段は既存の行の複製のみ。
全く新しい内容の行を作りたい場合は文章を空にする作業が必要だが、それはユーザに御願いする。
他にも、コメントをどうするかを考えないといけない。
色々手を動かしながらアイデアを練ってみる。
Gauche.Nightのデモではこれの一部しか見せられないと思うので、あまり期待しないように。
ちょっとエゴサーチしてみた。
はてなブックマーク等を見ると、意外と私のブログ!kiyoka.blogを登録している人が多かった。
このOldType上のブログはまだRSS feedをサポートしていないが、早くやるべきかなぁ。
Gauche.Nightのデモ用に色々やりたいことがあるので、落ち着くまでもうちょっと待ってね。
最近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
こういうビデオが残っていると、現場に行けなかった場合でも見返せるので非常によい。
もうちょっとVMの中身の詳細について紹介しているプレゼンも観てみたくなった。
あるのかな。
だいぶ形になってきて、Subversionから編集可能になってきています。
どんなものかちょっと触ってみたいなという方や、ちょっとしたメモやバッドノウハウを書く場所が欲しかったという方は気軽に参加していただけるとうれしいです。
詳しくは、アカウント申請方法はこちらを見て下さい。
まあ、とにかくオールドタイプな人ならだれでもOKというわけです。
但し、今のところEmacsユーザーに優しい設計になっているので、viよりもEmacsユーザの方がより楽しめると思います。
Emacsからの編集はこちらを見て下さい。
たくさんの応募メール待っています^_^。
が発表されたけど、これいいアイデアだね
私も日々の業務でファイル名に日付を付けただけのバージョン管理とメールでの通知に限界を感じている。
さらには、更新済のファイルを添付知たのが複数行き来しはじめると、もうバージョン管理はカオス状態になる。
でも非エンジニアの方々は、その方法が一番とっつきやすい。他のSubversion等の選択肢はなかなか敷居が高いんだよね。
LUNARRというサービスではドキュメントは1つにするという方法で解決できるそうな。
さらには、あらゆるドキュメントの裏面がLUNARRのUI画面に成っており、メールの通知や変更履歴確認が行なえる。
うわーお、なんて分かりやすいインターフェース。
やっぱりインターフェースの分かりやすさは重要だと思う。
これは、うまくいけば急速に普及しそうだよ。
これはOldTypeのページを画像ありで表示するためには重要。
Emacs.CarbonEmacsのノウハウ に書いた。
MacOSXでEmacsを使っている人は参考に。
これおもしろいね。
半分ネタ、半分本気な空気感がいい。
この部分は本気で共感出来るよ。
Schemeは勉強したがりなみんなの見方だね！
他にもいろんな人がいろんな主張を続けている。
私は意外とPythonは悪くないとおもってるよ。
特にPython 3000になると関数型スタイルで書きやすくなるとか、かなり満足いく仕様になると思う。
こんなエラーで止まる。
[MacOS X]$ svn co http://svn.coderepos.org/share/
U share/lang/java/jimmy/trunk/jimmy/src/main/java/jimmy/Node.java
.
.
.
U share/lang/perl/Mezasi/trunk/lib/Mezasi/Util.pm
svn: Failed to add directory 'share/lang/perl/Cache-Memcached-libmemcached': object of the same name already exists
Linuxでチェックアウトしたローカルファイルを調べてみると、やっぱり大文字小文字違いのファイルが見つかった。
[Debian 4.0]$ find . -iname Cache-Memcached-libmemcached
./share/lang/perl/Cache-Memcached-LibMemcached
./share/lang/perl/Cache-Memcached-libmemcached
どうやらMacOSの標準のファイルシステムは、ケースセンシティブではないらしい。
ブートパーティションはそのままにして、新しいデータパーティションを切ってそちらをケースセンシティブでフォーマットする必要が有るようだ。
本サイトのSubversionリポジトリもoldtype.otとOldType.otという二つのファイルがぶつかるので、解決する必要がある。
最近、MacOS上で開発する環境を作ってみようとしているが、いろいろ問題がある。
Macをお店で買ってきたらすぐにUNIX環境で開発できるというものでも無いようだ。