!kiyoka.blog.2007_06 RSSPLAIN

Related pages: !kiyoka.blog.list
14215553333333303333333333333330333333333333033333333333333333333033333333333333333330333555555555555555533333333033333333333333333333333333333333330333333330333333333333333330333333333333305
1

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

4

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

2

kiyoka.blog_header 

1

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

5

5

 

5

 

3

kiyoka.2007_06_27[猫] 猫を飼いはじめました

3

猫の名前は『ささみ』といいます。よろしく。(kiyoka.ささみ)

3

これから、猫のこともちょっとずつ書いていこうと思います。興味のない方は読み飛ばして下さいね。

3
 ささみつかまり立ち
3
 2924814525_626f59f9e4_o
3

 

3

COMMENTso

このかわいさはやばいです

やばすぎます

3

COMMENTkiyoka

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

そうでしょ。^_^

猫ブログになってしまわない程度に写真を上げていきます。

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_26[ユーザビリティ][本] 『誰のためのデザイン?』を読む

3
 478850362X  誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書): ドナルド・A. ノーマン, 野島 久雄, D.A. ノーマン
3

読み終わりました。

3

1990年に出版された本なんですが、古さを感じない本です。

3

マウスの説明とかがあったり、Internetがこのまま広がれば、データが増えつづけてほしい物が見付けだせない悪夢の時代が来ると予言されています。Googleなんてものが登場する前の本ですので。それ以外は全く古くなっていません。

3

この本を読むと、いかに世の中の電化製品や電気のスイッチなどのデザイナがユーザビリティをないがしろにしているかを思い知らされます。

3

この著書で問題提起された後も、世界は良くなっていないばかりか逆に悪い方向に向かっている気がします。

3

近年の家電に内蔵されているコンピュータの性能は上がり続け、さらに開発言語も生産性が上がり続けています。その結果、簡単に機能てんこもりの製品が出来てしまいます。

3

挙句の果てに、簡単なことも簡単にできない、マニュアルを見てもよく分からないというような事態が日常茶飯事です。

3

この本をじっくり読んで、丁寧にユーザービリティの高いものを作るだけで一歩抜きんでたものができそうだと感じる方も多いはず。

3

さて、ユーザビリティが高い製品が評価される時代はやってくるのでしょうか。

3

 

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_24[Wiki] Wiki文法の標準化の動き

3

WikiCreole: Creole 1.0EXTでWiki文法の標準化の動きがあるようです。

3

いまではWikiエンジンの実装は星の数ほど有るので、こういった動きは必要だと思います。

3

ただ、私が作りたいWikiエンジンはもっと文法を減らし、さらには行指向にする予定なので、この標準化の動きには順わない可能性大です。(標準Wiki文法のimportとexportくらいは必要になるかも知れませんが...)

3

Wikiは本来、不特定多数の匿名ユーザーで自由に編集するものなので、コンテンツの質を全にはどうするかという話があります。

3

そして、このWikiのとっつきにくい文法が、質の悪いコンテンツを書き散らかす人の参入障壁として働くというような議論があります。

3

この議論の結論は知りませんが、文法がもっと簡単になったり文法を知らなくても編集できるとどんな効果が有るか知りたい所です。

3

ちなみに、前述のWikiCreole: Creole 1.0EXTはWiki文法を簡単にしようとする活動ではなさそうです。

3

 

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_21[Wiki] Wikiエンジンのデザインで悩み中...

3

参考にしているWikiエンジンはhowmEXTBitChannelEXTkahua-webEXTKamiwikiEXTです。

3

今、Geekと非Geekの両方を満足させるという非常に難しい問題に挑戦しようとしています。無謀かな...

3

Emacsからはhowmのような感覚でバリバリ編集し、Webからはちょっとした編集を簡単にやれるようなシステムを考えています。

3

なるべくWiki文法は減らす方向で考えています。

3

これだけWikiCloneがあるのに新しく作らなくても...と思うんですけどやっぱりいろいろ実験してみたいんですよね。

3

WiLiKi:Design:OriginalEXTでshiroさんも同じような事を書いておられます。

3

引用:『WikiCloneの中にはこれらのいくつかを解決した非常に高機能なものもありますが、いろいろ実験するのに便利なので結局スクラッチから書いてしまいました。』

3

そんなわけで、ユーザービリティの本をまったり読みながら毎日悩み中です。

3

 

3

 

3

COMMENTたかや

LILO でお会いしましたたかやです.

こんばんは.

同期出来ると僕は嬉しいです.

ばりばりEmacsで書いちゃって,オフラインでも検索と追記ができ,Webで書いたものも,同期で問題なく処理出来るのが欲しい.

楽しみにしてます.

3

COMMENTkiyoka

たかやさんコメントありがとうございます。

たかやさんのお望みの通りのものを考えています。

ただ『同期で問題なく...』という部分が非常に難しいんですよね。

Subversionで並行編集を許すと、必ず保存時のコンフリクトを人間が解決する必要があります。

かといってロックしてから編集する方法を選ぶと、他人の編集が終わるまで待ってもらわないといけないのです。

オプションでどちらかを選んでもらうというのも、設計できていないということと同義なので避けたいです。

何かブレイクスルーがないかなぁーと、ぼんやり考えています。

3

COMMENTYABUKI

Kiyokaさん、こんにちは

一つ、アイディアです。

最近、あるところでgitを強く推されています。たしかにいい所があります。分散コミットができるので、コミットとコンフリクト解決の分離が行えます。svkやgitなどを学んでみてはいかがでしょうか。

3

COMMENTkiyoka

YABUKIさん、コメントありがとうございます。

svkとgitを調べてみました。

どちらも、分散コミットが出来てGeekには良いかも知れませんね。^_^

今回のWikiエンジンでは、反映時のコンフリクト解決の敷居を下げる事に力点を置くので、大量のコンフリクトが発生するシチュエーションを考えた場合、分散コミットは本質的な解決にならないかもです。

せっかく教えていただいたのにすみません。

情報ありがとうございました。

3

COMMENTYABUKI

なるほど、それだとSCM(Software Configuration Manager)単体では解決できない問題ですね。問題を分割統治するという方法で、コミットとリポジトリへの更新が分かれるだけでは解決にならない。

むしろ、コンフリクトが起きないような解法が必要そうですね。(少なくとも、*大量*には発生しないしくみ) Ajaxとかで編集している所が他人にも明示的に判るとかでしょうか。

編集者同士で日本の企業文化の一つである「根回し」みたいなことができているとコンフリクトが減りそうですね。システム的なサポートをどうしたらいいのかは思い付きませんけど。

3

COMMENTkiyoka

> [YABUKIさん]

> むしろ、コンフリクトが起きないような解法が必要そうですね。

そうですね。多くのWikiエンジンはコンフリクトが起きる可能性のある『自動マージ』という道を選ばず、先にコミットしたものが勝つ(先勝ち)にしているものが多いですね。

理想はAjaxによるリアルタイムのフィードバックなのでしょうが、かなり実装が難しそうです。(ExcelのBook共有のイメージです。)

このあたりを考えるのが難しくもあり、自分で作る醍醐味ですね。

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_18[デザインポリシー] creativeよりuseful

3

毎度の事ながらリアルタイムには反応できませんが、弾さんのエントリーより。

3
 404 Blog Not Found:creativeよりusefulEXT
3
 誰でもcreativeになれるが、誰でもusefulになれるわけではない。そして私自
3
 身も含めて、人はusefulなものにしか代価を支払わない。「頭がいいのに成功
3
 できない」ただ一つの充分な理由が、これ。いくら頭のいい解決法でも、他者
3
 がそれを使えなければ、それは文字通り「使えない」のだ。
3

 

3

これまでの私のオープンソース作品を振りかえって見ると、奇抜さでは負けない所はあるんですが、本当に『使える』物は少ないです。

3

もっと使える物を作らないとなぁと反省している所です。

3

広く普及するもので無くても、こっちでは役に立っているよ、というようなフィードバックがもらえるようなものを作って行くぞっ。

3

『奇抜で実験的なもの』という路線をちょっと変更したいなと思う今日このごろです。

3

 

3

 

3

COMMENTshiro

Paul Grahamのマントラ、'Make what people want' も同じ精神ですね。

3

COMMENTkiyoka

shiroさんツッコミありがとうございます。

本当ですね。以前読んだことを忘れていました。

Why Smart People Have Bad Ideas (原文)

なぜ賢い人が愚かな考えにハマるのか (翻訳)

原文では 「make something people want.」 という言い回しで書いてありますね。

shiroさんを見習って 「Right thing」 ではなく 「Gauche thing」 な方向で「使える」物作りに挑戦してみます。

0

comment (disabled)

3

3

 

3

 

5

kiyoka.2007_06_15[OldType開発]目指す方向

5
WikiとBlogの融合ができるシステム
5
  WikiとBlogはどちらも便利だが、どちらに書けば良いか迷うようだと良くない
5
  どちらに書いても再利用できるようになっているシステムが良い
5

 

5
カスタマイズを簡単に
5
  導入は簡単だけど、いざシステムを拡張したりカスタマイズしようとすると途端に難しくなる。
5
  簡単にカスタマイズしてテストできる環境を用意する。
5
  例えば、Subversionのワークディレクトリのバッチ処理を変更する方法でプラグインを追加する。
5

 

5
外部システムとの接続を簡単に
5
  外部から記事を自動的に投稿したり、取りこんだり、連携出来たりする機能が最初から用意されているシステムを目指す。
5
  メールや、WebAPIで簡単に投稿、アクセスできる、もしくはカスタマイズできるシステムを目指す。
5
  Plaggerで取りこんだ物を簡単に投稿記事に変換できる等。
5

 

5

 

3

3

 

3

 

3

kiyoka.2007_06_14[天然系] 匠さん、来週もよろしく

3

劇的ビフォーアフター(TV番組)の予告:『さて、来週の匠は...』

3

嫁:『ヘぇー来週も匠さんなんや、 匠って苗字多いな』

3

というわけで、全国の匠さん、後はよろしくっ(笑)。

3

 

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_11[ユーザビリティ][Wiki] 使われないWiki再考

3

Wikiが使われない原因を再考しています。Web上にはいろんな意見があります。

3
 ITmedia News Wikiは時間のムダだ(2/2)EXT
3
 ワード氏とその仲間にとって、確かにWikiは素晴らしいものだ。わたしの経験
3
 から言うと、人々は仕事やワークフローの習慣をわざわざ変えたがらないもの
3
 だ。(Eclipse Foundationのメンバーのように)非常にやる気のある作業者が
3
 かかわっていない限り、Wikiは使わないだろう。
3
 これはソフトの問題ではない。例えば、eWEEK Labsのスタッフは
3
 「CustomerVisionのBizWikiはコンテンツを協力して作成、管理するための洗
3
 練されたツール一式をユーザーに提供する」と評価しているし、わたしも彼ら
3
 の言うことを信じている。Wikipediaの基盤となっているMediaWikiというソフ
3
 トは各方面で賞賛されており、その評価に値するとわたしも確信している。
3
 Wikiの真の問題はグループウェアの持つ問題と同じだ。素晴らしいアイデアだ
3
 が、ほとんどの人は使わないということだ。
3

 

3

本当にそうでしょうか。私はWikiが使われない理由はユーザビリティの問題だと思いはじめています。

3

以下のような記事もあります。

3

 

3

ITmedia wikiを使った「Web向けLotus Notes」に大きな関心EXT

3
 JotSpotは、初心者でも使えるWYSIWYGエディタを提供することで、wikiをもっ
3
 と取っつきやすくしようとしている。またコラボレーションツールとしての
3
 wikiの有用性を高めようと、それぞれの wikiページに電子メールアドレスを
3
 割り当て、ユーザーが各ページに寄せられる電子メールメッセージを管理でき
3
 るようにしている。
3

 

3

機能を絞りこむことと、ユーザービリティを改善することでもっと使われるようになると思います。

3

そんなわけで、今デザインの練習としてCMSをデザインしています。

3

これまではユーザビリティの高いデザインをするには『センス』が無いとだめかなと思っていましたが、いい本が沢山あるので誰でもいいデザインができると思っています。

3

そのうちユーザインターフェースデザインについて書かれた本を紹介します。

3

 

3

 

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_10[天然系] 未来系?

3

嫁さんに図書館で本を借りてきてもらうんですが、今日も天然系なことを言っておりました。

3

嫁:『あっ、それ知ってる。未来系やんなー』

3

一応SF小説というジャンルがあるんですけど...

3

 

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_07[Sumibi][本] Web API実践リファレンスブックを献本頂く

3
 4839923981 Web API実践リファレンスブック: 加藤 貴之, 佐久間 勇樹, 関戸 亮介, いわさき ゆうだい
3

表題の本にSumibiWebAPIEXTというAPIを掲載頂きました。

3

さらには、著者の加藤貴之さんEXTより、献本頂きました。ありがとうございます。(加藤貴之さんのブログ記事はコチラEXT)

3

本の中身を確認したところ、丁寧にサンプルを使ってひとつひとつのAPIを解説されています。

3

もちろん、SumibiのWeb APIについてもPHPのサンプルコードを使って分かりやすく解説して頂いています。

3

これを機にみなさんもSumibi Web APIを使った面白いサービスを作ってみてはどうでしょうか。

3

vimスクリプトでモードレスな日本語変換なんてのが狙い目だと思います。

3

 

3
 SumibiWebAPIの紹介ページ1
3
 2925667932_c1d7cea517_o
3
 SumibiWebAPIの紹介ページ2
3
 2925667536_41b857fb4d_o
3

 

0

comment (disabled)

3

3

 

3

 

3

kiyoka.2007_06_05[プログラミング] LL魂EXTチケットゲット

3

チケットゲットしました。

3

去年の LL RingEXTはスピーカーで出ましたが、今年のLL魂では観客として行く予定です。

3

最近、オープンソースの活動がちょっと停滞気味なので、力をもらいに行きます。

3

今年も行く人がいたら、現地で声をかけて下さいね。

3

LL魂当日(土曜日)は東京に宿泊予定なので飲みにもいけますよ。

3

 

3

 

3

COMMENTso

ぼくっもいっちゃいますよ!

3

COMMENTkiyoka

soさん、当日見つけたら声をかけてくださいね。

観客が500人以上いるので難しいかもしれませんが...

0

comment (disabled)

5