 | !kiyoka.blog.2008_03 | [RecentChanges] [AllPages] (Late      Latest) |
| !kiyoka.blog.2008_03 | [RecentChanges] [AllPages] (Late Latest) |
kiyoka日記。OldType、Sumibi.org、日々の出来事など。
最新10件!kiyoka.blog 過去記事一覧!kiyoka.blog.list
(似顔絵イラストメーカーで作りました)
タイムスタンプコマンド #(timestamp UTC) の実装方法
わかったこと
svnは時刻をUTC(標準時)で返す。(ここで使っているsubversionサーバはCodeRepos)
コミット情報を調べるコマンド
svn --xml info '../edit/Test.ot' > info.xml
info.xmlのコミット情報部分。実際にコミットしたのは日本時間の2008-03-31 21:56ごろ。
<commit
revision="8569">
<author>kiyoka</author>
<date>2008-03-31T12:56:20.155602Z</date>
</commit>
どう実装する？
OldTypeのバッチ処理で行うコミット時間はUTCを秒数で *.sexp のS式の中に保存する。
!RecentChangesには #(timestamp UTC秒数) という行を埋めこむ。
oldtype.kahuaで #(timestamp UTC秒数) をOSの返すタイムゾーンで表示する。
Gaucheで現在時刻を取得する方法
srfi-19を使う
(use srfi-19)
time-utc型
> (current-time)
#<time-utc 1206973544.480890000>
date型
> (time-utc->date (current-time))
#<date 2008/03/31 23:26:22.595112000 (32400)>
時刻を表示してみる
> (date->string (time-utc->date (current-time)) "~c")
"Mon Mar 31 23:32:41+0900 2008"
最近、同種の本を2冊同時に読む様にしている。
間を空けずに、同時に読むと、比較できて楽しい。
(1)スーパーコンピューターを20万円で創る (集英社新書 395G): 伊藤 智義
(2) 未来を予測する技術 (ソフトバンク新書 46): 佐藤 哲也
(1)が自分の解きたい問題にフォーカスすることで世界一安価手作りスーパーコンピュータを作る物語だ。
一方、(2)は世界で一番規模の大きな汎用スーパーコンピュータの使命について熱く語っている。
両方の本を読むと、予算規模と問題設定の大きさは無関係であり、数人規模の仕事でも世界に衝撃を与えることはできるという気がする。
また、両方とも、関わっている人はシミュレーションはワクワクする科学の分野であり、本当に楽しみながら、且つ価値を生みだしているという自負を持って取りくんでいるということ。
コンピュータ開発の人間ドラマを読みたい人は(1)を、人類の未来の姿を垣間見たい人は(2)をおすすめする。
最近、同種の本を2冊同時に読む様にしている。
間を空けずに、同時に読むと、比較できて楽しい。
(1)若者はなぜ3年で辞めるのか? 年功序列が奪う日本の未来 (光文社新書): 城 繁幸: 本
(2)お金より名誉のモチベーション論 <承認欲求>を刺激して人を動かす: 太田 肇: 本
有名な(1)より(2)のほうが、はるかに内容が上だ。
(2)を読むと、(1)が薄っぺらに思える。
(2)は日本人独特の屈折した承認欲求の心理からモチベーションを説明していて、非常に納得できる。
日本人コミュニティーのなかでは承認欲求がないかのように謙遜することが、実は最大の承認を得るための方法だと解説してある。なるほど。
それに比べて、残念ながら(1)では単に誰かを悪者にして愚痴っているだけに思う。
2冊同時読みは、1冊だけ読んだ時間に比べて、それぞれを客観的にちょっと引いた視点で読めるのでいい。
一つの意見を盲信する危険性が減る。おすすめの読みかただ。
Pythonが目指す変化の方向性は，「よりコンパクトなコア」。誰が使っても「た
った一つのすばらしい方法」にたどり着けるように，曖昧さを排除し，例外を少
なくしてハマりどころを取り除くことによって，よりながく，正しい方向に進化
しつづけられるはずです。
とうとうPythonも3.0で後方互換性を犠牲にしても進化するという方針を打ち出した。
PHP、Rubyは(多分)元から互換性をそんなに重要視していないし、PerlはPerl 6で後方互換性を犠牲にした。
最後に残ったPythonも例外では無かった。
コンパクトなコアという方向性は賛成。
Schemeが好きな私はコアはコンパクトで有れば有るほどいいと思うけど、あまりにやりすぎると、普及しずらい。
そのへんのバランスが重要だと思う。
Python 3.0ではそのバランスが調整されて良くなりそうな期待がある。
ところで、私はPythonのインデント構文は好きなので、SchemeのスキンとしてPythonライクな構文を採用するという妄想を捨てきれずにいる。
PythonとSchemeは水と油のような気もするが、だからこそPythonライクにすることでS式に抵抗がある人用のインターフェースとして機能するんじゃないかと思う。
水色を選んだ。
1.5m防水があるが、まだ水には浸けていない。
早速、ネコのムービーを撮って、アップル - iMovieで編集した。
動画編集は初めてだったが、iMovieを使うと、思ったより簡単だった。
できたムービーは使っている音楽の著作権の問題でYouTubeとかには上げれないが、
CreativeCommonsのいい音楽があれば、音楽を入れ替えてYouTubeに上げてみたいな。
SANYO 防水型デジタルムービーカメラ Xacti （ザクティ）DMX-CA65(L)
サポートしてみると、意外とブックマークされていた事に気がついた。
ブックマークされていることが分かると、単純に嬉しい。
Wiki更新のモチベーションにプラスに働くと思う。
次ははてなスターもサポートしたいと思っているけど、コメント機能の方が早く欲しい。
そして、その実装をするための時間が欲しい(笑)
lunarrは驚くほどSimpleでCoolなコラボレーションサービス。
昨日は前半二つ(kiyoka.2008_03_13)、今日は後半ふたつを見た。
コンセプトがよく考えられている上に、ユーザインタフェースがそのコンセプトと結びついている。
こうなると、人に利用方法を説明するのがすごく簡単になりそう。
さらに、lunarrはコンセプトが良く考えられていて、狙い所も明確だ。
ワードプロセッサくらいは自前で作っているようだが、それ以外の表面のアプリケーションはlunarrでは作らず、
既存のアプリとメッセージシステムをくっ付けることに付加価値が出るよう注力している。
プロダクトをシンプルにする為には『何をやらないか』を決める必要があるが、
それ以前に強力なコアのコンセプトが無いと『何をやらないか』なんてきめれないよなぁと、今更ながら気がついた。
コアが無いものの無駄を省いていくと最後には何も残らない。
だからコンセプトの弱いプロダクトは、あれもできますこれもできますと言った形で多機能で説明の難しいプロダクトになってしまうのかなと思う。
lunarrを見習って、自分もいいものを作っていければと思う。
lunarrは驚くほどSimpleでCoolなコラボレーションサービス。
今日は、Youtubeのビデオを前半二つだけ見た。
kiyoka.2008_02_19でも書いた話だけど、すばらしいソフトウェアになるためには見ためも重要になるが、このサービスは合格点。
実際に使ってみたことは無いのだけれど、ユーザインターフェースが分かりやすい。
オフィスではアプリの表と裏をクルクルとひっくり返しながら次のアクションをぼんやり考える光景がそこここにみられそう。
意味もなくいじってしまうプチプチ梱包材のような操作感のインターフェースがあるかないかで、そのサービスに愛着を感じるかどうかが決まると思う。
iPhoneのユーザインターフェースなんかもそうだよね。
SONYのジョグダイアルもそこまで気にして開発しているというのを読んだことがある。
で、lunarrだが、約1週間前にビデオがアップロードされたみたい。
ユーザインターフェースとコンセプトが結びついたプロダクトに興味がある人は一度見てほしい。
kiyoka.2008_03_02に書いたように、OldTypeのソースリポジトリをCodeReposに移した。
いま流行りの『そうだ、逆に考えるんだ』に乗ってみた。(流行ってないか...)
ところで、CodeReposには毎日いろんなプロジェクトが突っ込まれているようだが、パフォーマンス的に耐え切れるのかな。
なんてぼんやり考えながら、後先考えずにCodeReposに引越し完了。
唯一、lang/schemeというディレクトリが嫌だったのでlang/gaucheを作ってそちらに入れた。
Kahuaも使っていることだし、schemeというくくりでは無いなと感じた次第。
というわけで、hayamizさん、sourceforge.jpのリポジトリは近日中に閉じちゃうのでよろしく。
の感想
イベント全体の印象はS式一色。S式への愛が溢れたイベントでした。
LL関係のイベントではS式!S式!と叫んでいると、かなりaway感が醸しだされるんだけど、
gauche.nightではS式が正統派、S式でないとオカシイとまで思われかねないほどのS式傾倒ぶり。
オライリー本
が出たことに対する皆の喜びもいったんかんのある空気の中に感じられた。
それと、Shiroさんがイメージ通りのいい方だったので安心したよ。
少しづつGaucheがメジャーになってくれることを願う一日だった。
これからも私はOldTypeをハックしながら、Gauche/Kahuaの発展に貢献できればと思う。
に出演してきた
ふー、疲れたー。
スタッフの皆さん、出演者の皆さん、そして、遠路はるばる見に来てくれた方々、ありがとうございました。
私は初めての参加でしたが、こんなに濃いイベントだとは。予想を超えていました。
Shiroさんにもお会いできたし、錚々たる出演者の方々とお話しすることができました。
yharaさんとかhayamizさんひげぽんさんなど、ブログで良く知っていた人に裏話など聞かせてもらいました。
今日はオールナイト飲み会の後のフライトで疲れたので、イベントの詳しい感想などはまた後日書きます。
[本] プログラミングGaucheがAmazonで予約できるようになった
Amazon.co.jp： プログラミングGauche: Kahuaプロジェクト,川合 史朗: 本
gauche.nightに行けなかった人はコチラから予約できるよ。
タダのウケ狙い。
λとぅいう字わぁー、あっはぃー、λとλが再帰的にぃー支えあって出来ているのですぅー。
GaucheGongのデモでこのページが見えるようにしていたんだけど、実際ウケなかった...残念...
Rubyにnamed letみたいなのが欲しい
再起でレキシカルアナライザが自然に書けるよ。
def lexer( f )
tokenList = [ ]
- twitter: let loop { |ch = f.readchar, prev, token = ""|
case ch
when f.eof?
else
# トークンの蓄積
case ch
when ' ' '\t'
tokenList << token
token = ""
else
token += ch
end
loop( f.readchar, ch, token )
end
end
tokenList
end
本物のRubyにはないコーディングは、たぶん次の三つだけだと思う。
ブロック構文の引数の初期値指定
let構文
Procオブジェクトを.call()を付けなくても呼出せる
要するに、Schemerは何でもλに見えてしまうので、Rubyにもそれを期待してしまう。
もしこれが出来てもRubyの構文自体はあまりくずれないと思うけどなぁ。
SourceForge.jpの上にリポジトリが存在する必然性があんまり感じられない。
(リリース版のダウンロード場所としては使いたいけど)
tDiaryの開発がCodeReposに移行するという話をメーリングリストで読んだのがきかっけでそう思った。
そういえば、perl EncodeもCodeReposに移ったんだったよね。404 Blog Not Found:perl - EncodeをCodeReposに
GaucheNight後に落ちついたら移行しようか。
Wikiについて議論している情報があまり見つからなかったけど、こんな所にあったとは。
最近のWikiエンジンの追っかけ情報とかWikiコンテンツのライセンスとか、色々ためになることが多い