 | !kiyoka.blog | [RecentChanges] [AllPages] (Late      Latest) |
| !kiyoka.blog | [RecentChanges] [AllPages] (Late Latest) |
kiyoka日記。OldType、Sumibi.org、日々の出来事など。
最新10件!kiyoka.blog 過去記事一覧!kiyoka.blog.list
(似顔絵イラストメーカーで作りました)
まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェア
の宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」
「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャ
の大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたり
まえ。
ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部
分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用が
ある」という点。特に「作って見なければ分からない」部分の見極めのための
コーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・
仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足
かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で
実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大
切。
(略)
この段階で大切なことは、
* 書いたプログラムを捨てることを恐れないこと
* この段階で仕様書を書くことは時間の無駄と認識すること
* 細かなことを無視して、一番難しい部分を最初に作ること
* できるだけ早く、一気に「見極めが出来るところ」まで持って行くこと
* コードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること
の５つである。とにかく、このプロセスの目的は、「このアーキテクチャのままで製品化できるのかどうか」「想定し
ているユーザーシナリオに合致したものができるかどうか」の「見極め」をすることなので、それ以外のこと（たとえ
ば仕様書を書く、ミーティングに出席する、ユーザーインターフェイスの細部を決めるなど）に時間を使わず、とにか
く一日でも早く「見極め」ができるところまで持って行く。
製品化されるプロジェクトでなくても同じだな...
プロジェクトの一番のキモになる部分が自分の想定したイメージ通りかを先に試す必要がある。
プライベートのプロジェクトでは自分の時間を投資しているわけだから、キモが実現出来るかどうかを早目に見極めて続けるか/やめるかを速い段階で決断しないといけないわけだし。
この記事を読んで、早速Nendoの開発の優先順位が変わった。
define-rulesとかどうでもいいので(誰がいつやっても実装できるに決まっている) 先にRubyとの連携部分をもっと詰めるべきだと思った。
よし。いろんなgemsを使ってみて問題点を洗いだし、先に解決していこう。(そのためにはそれなりに使えるツールを作る必要あり？)
SRFIライブラリの充実とかは後でじっくりやればいいのだよな。(util.listだけは普段必要としているので先にポーティングするかも)
comment please => kiyoka.2010_07_29
Sambaでファイル共有していた頃と比べて格段に便利になった。
自宅の2台のMacとDebian Linuxのサーバー1台のファイル共有がシンプルになった。(それにiPod touchも共有できるのでさらに便利)
Sambaだと、サスペンドするとmount状態が解除されるのがめんどうだったのと、MacBook Proを持ち出した時はオフラインなのでそもそも共有ができないのが不便だった。
今後、自分のデータはどんどんDropBoxに置くことになりそう。
+
参考記事
CUI only dropbox for all Linux OS
自分でリンク先の手順をやった時、途中でX11のGUIが出てきてDropBoxのパスワード認証をする必要があった。
それ以外はリンク前の手順どおり。
comment please => kiyoka.2010_07_27
図書館で借りれた。別の市町村にしかなかったので、図書館が又貸ししてくれた。
そのおかげで、2週間での返却制限が付く。
しかし、こんな数式だらけの本を2週間しか借りられないのはつらいなあ。
たぶん、買うべきなんだろうけど。
- twitter: 
計算論 計算可能性とラムダ計算 高橋 正子
中をちらっと見てみたが、これを学習したからといって、役に立つかというと微妙かも。
自作処理系がβ簡約とかの最適化を真面目にやるならたぶん役に立つだろう。
Haskellはあまりやったことが無いので間違っているかも知れないが、Haskellとかでバリバリプログラミングする人はこの本でラムダ計算を学習しておくと、Haskellらしいコードが書けるのかも…
買って積読しておくよりも、今回は流し読みして必要になるまで買わないことにしよう。
comment please => kiyoka.2010_07_26
Nendo 0.3.3をリリースしました。(リリースノート: Nendo.ReleaseNote)
あいかわらずチュートリアルと、リファレンスマニュアルはまだ書きかけですが...
今回の目玉はsrfi-1のサポートと末尾再帰最適化でしょう。
SRFI 1: リスト ライブラリはScheme単体では貧弱なリスト処理ユーティリティを増強するものです。
Scheme処理系のほとんどは、このライブラリをサポートしており、これが無いとそもそも処理系を使ってもらえないほどの必須ライブラリと言えます。
末尾再帰最適化は、再帰的に記述したコードのスタックオーバーフローを軽減する機能でR5RS Schemeでは必須とされている機能です。それがNendoにも入りました。
例えば、以下のコードはスタックオーバーフローせず無限ループします。
(define (foo)
(foo))
今後はR5RSのdefine-syntax define-rules等の健全なマクロを実装して、より多くのSRFIライブラリをサポートしていく予定です。
Nendoは独自仕様のLisp処理系を作ろうとして開発を始めましたが、Scheme(R5RSですが)を参考にすればするほどSchemeはシンプルにまとまった良い仕様だということが分かってきて、現在はSchemeにどんどん近づいていっています。
将来的にはRuby gemsを簡単に利用できるSchemeライクな言語という位置付けになりそうです。
comment please => kiyoka.2010_07_25
結局原因がわからず仕舞い。
Linuxカーネルを 2.6.8 から 2.6.34 に上げたらオンボードのNICを認識した。
ただ、最新のカーネルはUSBストレージをちゃんと認識してくれたり、plug-and-playまわりが進化しているので使いやすくなった。
区切りとして、一応USBハードディスクにファイルシステムをdump中。なんと /home パーティションの推定完了は35時間後だそうな。
サーバにモニタをつないだ状態にしているし、これを機に Debianを 4.0 から 5.0 (lenny) にアップグレードしておこうかな。
lennyにすると「Dropboxが簡単にインストールできる」とか「security fixが早い」とかいろいろ良いことがありそう。
P.S.
先程までブログコメントを入力しようとするとエラーになっていた。環境設定忘れを正し、復旧した。
comment please => kiyoka.2010_07_23
このブログをホスティングしているサーバなので、しばらくブログが503になっていた。503といってもリーバイスでなくてhttpのリザルトコードのほうね。
２年に一度くらい、マザーボードやハードディスクが故障する。
大概マザーボードが故障することが多く、２年毎にマザーボードを新調することになる。(今回はオンボードのNICが死んだ模様)
マザーボードを買うと、CPUソケットが新世代になってしまっているので、手持ちのCPUは捨てないといけいない。メモリも同様。
結局２年に３万円ほどの出費と手間がかかっているのが現実なので、もうどこかのVPSでホスティングするという選択肢も考え中。
やっと２年で３万円くらいで借りれるVPSが出てきたので、Kahuaだけを動かすならそちらに載せ替えても良いかな。
ファイルサーバはDropbox、メールはGmail、自分のこれまでのデータはMacBook Proに入れるようにすれば、もうLinuxサーバは不要なのかも。
なんかクラウドって便利だなぁ。
ただ、その反面、そのサービスが終了したらオシマイというリスクもあるのでそこは考えようだなぁ。
それに、自分でサーバー維持してると、サーバーが落ちたタイミングで、障害解析したり最新のLinux Kernelやディストリビューションにアップグレードしたりしてノウハウが更新できて良い面もある。
そんなサーバー周りのノウハウが役に立つかはわからないけど、実際に自分でやっておくと仮想化されたインフラを使う時、肌感覚として知っておくのと知らないのでは大きな差になるんじゃないかな。
そんなこんなで、迷いつつ今回はサーバーを新調せずになんとかする方法を調査中だったりする。
comment please => kiyoka.2010_07_22
この自転車を買った。
ヤマハ パス リトルモアリチウム 【2010年モデル】
2010年モデルを買ったので、最大3分の2まで電動モーターがアシストしてくれる。(自分の脚力は3分の1しか使わなくて良い)
ほとんど自分の脚力を使わないので、まるでスクーターに乗っているような感じ。
前カゴに乗った2歳児のR君も鼻歌混じりでルンルンで楽しそう。自転車大好き。
買った次の日は調子に乗って、坂道を登りまくっていたらさすがに少し筋肉痛になった。
電動アシストでない自転車の時は、坂道が来たらあきらめて歩いていたので、筋肉痛にはならなかった。
？？？ 何かオカシイ気もするが...
これでちょっと遠くの公園に行くにもストレスが無くなったぞ。
梅雨が開けたら本格的に活躍しそう。
comment please => kiyoka.2010_07_12
私がRubyで書いているLisp方言、 Nendoについて。
Olin Shiversさんのリファレンス実装のポーティングの続き。
call-with-current-continuation(継続)を使わない様に書きなおした。
ちゃんとソースコードを読んだら、call-with-current-continuationが使われている理由は、map系関数の高速化の為だった。
null-listが渡されたら、早めに処理を中断してムダな計算をしないようにするため。
そうと分かれば、書き換えは簡単。
しかし、テストスイートをどうやって用意するかが問題だ。
他の処理系から頂戴して来たいがライセンスとかがあるのでちょっと選別しないといけない。
comment please => kiyoka.2010_07_08
私がRubyで書いているLisp方言、 Nendoについて。
srfi-1のポーティングに挑戦中。
Olin Shiversさんのリファレンス実装はsyntax-rulesが使われていないが、call-with-current-continuation(継続)が使われている。
リファレンス実装の情報はこちら: SRFI 1: List Library
そして、ソースコードはこちら
これを、継続を使わない形式に書きなおしていく予定。
継続が使われている理由を推測すると、おそらくmap関数などに長いリストを渡してもスタックオーバーフローしないようにしているのだろう。
mapが一つのリストを受けとった場合については、末尾再帰で書くのは簡単だけど、複数のリストを受けとった場合も考慮すると、継続なしで効率の良いコードは書けない気がする。(セルの大量コピーが発生しても良いなら書けるかも)
Nendoについては、セルの大量コピー版でいくか...
srfi-1以外についてはNendoはsyntax-rulesが未実装なので、syntax-rulesを先にサポートする必要が有りそう。
外の処理系のsyntax-rulesの実装を見てまわっているが、Scheme自身で書かれていたり(chibi-scheme)、Rubyで書かれて言たり(heist)、いろいろだ。(Gaucheは何で書かれているのか読み切れなかった。どこに有るのか見つけられなかった。Gaucheはチューニングの工夫が入りすぎていて、簡単にソースが追えないなあ...)
それにしても、Scheme処理系の実装方法の幅は広いなあ。いろいろソースを読むのも楽しい。
comment please => kiyoka.2010_07_05
私がRubyで書いているLisp方言、 Nendoについて。
関数呼び出しが重たいのがわかっている。
例えば、現在のNendoは関数の引数が1個の時でも、次のような引数変換用のcallProcedure関数を通る。
callProcedure( '関数名', @_func, Cell.new( 1 ))
これを
@_func.call( 1 )
のように、目的のクロージャを直接呼びだす様にすれば、オーバーヘッドが無くなる。
これは計測の結果、ボトルネックだと確実に分かっている。
(例えば、fib(20)が10倍ほども高速化された)
先にsrfi-1等のポーティングをやってから取り掛かろう。
comment please => kiyoka.2010_07_02