Posted by & filed under 開発.


最初にセットアップしてから、実は最近はあんまり、Homebrewのパッケージのアップデートかはしてません。めんどいので。でも、油断をしてアップデートしたらPythonのバージョンが上がってしまいました。まあ、それはいいのですが、そしたらvirtualenvとか使えなくなってしまいました。ちょっと悲しいです。brew install pipってしてもpipをインストールできません。easy_installを使ってインストールしろって、冷たく突き放されます。easy_installはPythonと一緒にインストールされたらしいので、

[続きを読む…]


関連文書:

Posted by & filed under いろいろ.


http://dev.ariel-networks.com/wp/archives/755

それJavaScriptでも出来るよネタ。
Firefox限定ですが。

無限と言っておきながら上限が決まっている(jsの数値の限界)のと、
ループを例外で抜ける(prototype.js方式)のが微妙です。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


 前回 は Stream オブジェクトをリモートアクターに転送するにはどうすればいいか?という話でした。

 せっかく Straem を使うわけですから。List に変換したり、転送時に Stream を foreach で走査して、再構築するなんて事はしないで。値の評価の遅延だけでなく、プロセス間のデータ転送まで遅延したいところです。

 という事で。Stream のデータ転送を遅延する、抽象化機構を作ってみました。
 この Stream を抽象化するデータ構造を AStream とここでは名づけます [*1]。

 まず。リモートアクターに Stream 転送する際、直接 Stream を送らないで別のデータ構造に変換してからリモートに転送するようにします。
 そこで、入力に Stream オブジェクトを取る set メソッドを作り、出力に入力した Stream に可換な別のデータ構造を吐き出すようにします。具体的に、送信側では以下のようにします。

 [送信側の実装の抜粋]

 AStream.set は以下のケースクラスのインスタンスをリモートに送ります。

 リモートでデータを受け取り、Stream を取り出す実装は以下のようにします。

 [受信側の実装の抜粋]

 リモートの受信側では、SendStream の各メンバを引数に AStream オブジェクトの get メソッドを呼び出し、Stream を抽出します。
 以下が get メソッドの実装です。ここまでの話は、かなり手続的な内容でしたが。ここでようやく Stream の本領発揮です。

 [AStream のコード抜粋]

 ここでの処理は、送信側に Stream の中身を問い合わせて、先頭要素だけを送ってもらうという事をしています(もちろん送信側では、この処理の後に先頭要素を次要素にスライドさせます)。ただし、Stream.empty は、空リスト (Nil) に変換して送ってもらい、リモート側で Stream.empty に戻します。
 ミソは 10 行目の再起が Stream によって遅延評価される事です。この時点では 10 行目の get メソッドは評価されず、「次に評価するのは僕ですよ」という事だけ教えて Stream を返します。なのでここでの処理は一瞬で終わります。
 
 実際に先頭以降の要素を送信側から取ってくるのは、値が参照されたとき ([受信側の実装] の tail が実行されたとき) になります。このときに始めて AStream.get メソッドで返された Stream の次の要素 (get メソッド) の評価が行われ、送信側から次の要素が入った Stream が返されます。

 こうすることで、データ転送を遅延する Stream の転送が実現できました。
 こんな事しなくても、別の (もっと簡単な) 方法を知ってるぜ。という方は、是非コメントください。

[*1] AStream のコード : AStream.scala


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


 世間的にも。アリエル的にも今更ですが。Scala がメチャおもろいです。どのくらいかと言うと。普段控えめな自分が Java を上から目線でディスりたくなるくらいおもろいです。

 というわけで。Scala の話をします。ネタは Stream です。
 リストの要素を遅延評価してくれる Stream は、Lisp 脳のプログラマにとっては、とってもおもろいデータ構造です。
 例えば。List だと即座にメモリを取りにいくので、↓ こういうようなことはそうそう出来ません。

 が。Stream だと、実際に参照されるまで評価されないので、上述の処理も一瞬でできます。

 他のこいつを使ったオモロい実例は、他の人がいろいろ書いてくれているのでそっちを参照してください。

 http://blog.livedoor.jp/sylc/archives/1557536.html
 http://d.hatena.ne.jp/yuroyoro/20110418/1303110333

 さて、ここからが本題。
 Stream は参照されるまで評価されないので。まだ参照されてないけど、巨大になる(または無限になる)ことが予想されるリストを扱う際には、とっても重宝します。そういったリストを転送する場合なんかは特に。
 例えば、他のプロセス(もしくは他のマシンのプロセス)にリストを送る場合を考えてみましょう。

 送信元のプロセスでメモリに載ってるリストが、他のプロセスや他のマシンのプロセスのメモリに載っかるとは限りません。
 そんな時は Stream にすれば、メモリを一気にバカ食いしたり、メモリに乗り切らないでエラーを吐くといった事にはならなそうです。

 ただここで問題が。。。

 — Stream.Empty オブジェクトが Serializable じゃない orz…
  (http://www.scala-lang.org/api/current/scala/collection/immutable/Stream$$Empty$.html)
 
 なのでリモートアクターを使って、以下のように Stream を直に転送するなんて事ができません。

 ではどうするか?
 アリエルや他の Scala ハッカーにどうしてるか聞きたいところですが。何もしないで「教えてくれ」と言うと、(先日の CTO からの厳しい発言があった折から)社内的にも社会的にも淘汰される可能性があるので。以下、『つくってみた』の話。

[(長くなりそうなので)次回 に続く]


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


過去何度か、GNU/Linuxを勉強したいのですが何から始めればいいですか、と相談を受ける機会がありました。

そんな時のぼくの答えは決まっています。まず家のPCからWindowsを消してください。

この助言に従って本当にWindowsを消した人はおそらくいなかっただろうと思います。本気で消す人はいないだろうという想定でこちらも話していました。そもそも、何から始めればいいですかと聞くような人は、端的に言えばあまり本気ではありません。本気であれば他人に聞くまでもなく始めればいいからです。

思えば随分と長くUnix系OSを使っています。もう20年ほどになります。初めて触ったUnixはSunOSでした。何がそこまで自分の心の琴線に触れたのかは不明ですがUnixにはまりました。それ以来、OS自体は色々と乗り換えていますが、基本的にUnix系OSしか使ってきていません。流石にこの業界でWindowsを使わずに生きるのは不可能ですが、自宅のメイン環境は常にUnix系OSでした。

しかし今日突然、Unix派からAndroid派に転向しようと思いました。

今まで、LinuxはUnixの1種、AndroidはLinuxの1種、似たようなものだと嘘ぶいてきました。言うまでもありませんがUnixとAndroidは別物です。カーネルに共通性があっても、UX(ユーザ体験)の点でまったくの別物です。そしてPCを触っている限り、AndroidのUXは理解できそうにない、と悟りました。プログラミング言語とかライブラリとか関係なく、UXが決定的に違うと今更ながら思いました。ここでのUXは、画面サイズとかタッチパネルとかそういう物理的レベルではなく、パイプとかファイルとかシェルとか、自分にとって当たり前に存在していた論理的な部分です。

冒頭の話風に言うなら、Androidを勉強したいのですが何から始めればいいですか、と質問する立場です。もし自分が聞かれる立場なら答えは決まっています、PCを捨ててください、です。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


http://docs.komagata.org/4837

ClojureでClosureが書けるということなので、とりあえずgoog.events.InputHandlerのデモのコードをClojureScriptで書いてみました。
http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/demos/inputhandler.html
http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/inputhandler.html

demo

Clojureは触ったことなかったのでよくわかりませんが以下のような点が気になりました。

  • namespaceの「.」と「/」の使い分け方がよくわからない
    goog.events.InputHandler/EventType.INPUTとか。
  • グローバルオブジェクトの取得方法がわからない
    とりあえずgoog.global経由で取得。
  • プロパティ取得とメソッド実行をどう指定すればいいのかわからない

    のつもりで

    としたら

    に変換されました。しょうがないのでcallを使って
  • 関数の最後の式が勝手にreturnされる
    JSerにとっては落とし穴になると思う。
  • 文字列の結合が全部goog.string.StringBufferになる?
    2つの文字列結合程度だとオーバースペック気味。
  • 関数呼び出しが全部callになる?
    コンパイルレベルを下げるとよくわかりますが

    みたいのがやたら多く見られます。strict modeさえ使えれば…

関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


昨日、Agile Conference tokyo 2011に行ってきました。Martin Fowler氏のありがたい話を聞いてきました。

Manifesto for Agile Software Developmentから10年だそうです。となると、自分がXP(eXtream Programming)を初めて聞いたのはもっと前になります。改めてそう聞くと、思えば遠くへ来たものだという気分になります。

しかし、かつてXPに感じたような興奮を最近、アジャイル関連から感じられない自分がいます。今回のカンファレンスでもどこか言葉だけが上滑りをして心に響く感覚がありませんでした。

アジャイル周辺から生まれたいくつかのプラクティスの価値に疑いはありません。たとえば短いイテレーションで開発サイクルをまわすのはソフトウェアの品質を高めます。CI(Continuous Integration)も自動テストも、たいていはかけるコストに見合うメリットを得られます。

ただMartin Fowler氏が主張するように、技法やプラクティスをなぞってメリットを享受するのと、アジャイル宣言の本質を理解するのには距離がある気がします。そして、自分はまだアジャイル宣言の本質が腑に落ちていません。

今回、カンファレンスに出て、改めて「アジャイル宣言の背後にある原則」を読んで、どこが自分の中で引っかかっているのか少し分かったような気がします。

「アジャイル宣言の背後にある原則」の冒頭はこんな感じです。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

奇麗事すぎるとつっこみたい気分はありますが、さらりと流しても心にひっかかりはありません。問題は次です。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

ここが(もしかしたら10年間)ずっと引っかかっていた部分だと今回気づきました。

変化を抱擁せよ(これはXP由来ですが)という耳障りの良い言葉のせいで、疑ってはいけないと思い込まされていた気がします。しかし正直に吐露してしまうと、開発後期の要求変更は忌避すべきものです。だからこの文を読むと、忌避している本音と、忌避する自分を否定したい気分がないまぜになります。そして結局、この矛盾から目を逸らし続けて、頭はアジャイル、気持ちは非アジャイルな分裂状態になります。

この矛盾を解消できない限り、アジャイル開発を疑いなく受け入れることはできない気がしています。

この背景にはもう少し根深い文化的側面がある気がするので、話は次に続きます。

続く。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under .


WEB+DB PRESS Vol.63

以前から「WEB+DB PRESS」の献本をしてもらっています。

ただで渡しているんだからブログやTwitterに何か書けという暗黙の掟があるようですが、過去、ほとんど書いていませんでした。読んでいないわけではありません。単に読むタイミングが合わなかっただけです。つい先月まで5冊ほど、未読の「WEB+DB PRESS」が積んでありました。「WEB+DB PRESS」は2ヶ月に1冊の刊行なので、要は、1年分ぐらい未読がありました。しかし、先月から今月にかけて読み進めて、遂にVol.63も読みました。Vol.63は先月出たばかりなので、まだ雑誌としてのレビューに価値があります。

余談ながら、紙の書籍が電子書籍より優れているのは、こうして読まずに積んでおくと邪魔になって読まざるを得なくなる点です。紙の書籍には読ませるためのアフォーダンスが備わっています。

ただでもらっているのであまり悪口は書けませんが、「WEB+DB PRESS Vol.63」の特集は微妙でした。

と、いきなり悪口を書いてしまいましたが、フォローすると、「WEB+DB PRESS」は現存する技術系雑誌の中で1,2を争う、読む価値のある雑誌だと思います。もちろん、毎回出色の出来とはいきませんが、だいたいは高い質を保っています。「Software Design」より面白い…とは問題発言すぎて書けませんが、何か1冊技術系雑誌を買うなら「WEB+DB PRESS」を勧めたいところです。

話をVol.63に戻します。特集が微妙なので、いくつか新連載記事を取り上げます。

かとうさんによる「再考するJava」は意外に面白かったです。意外に、というのはJavaの割には、という意味です。別にJavaをバカにしているのではなく、今、Javaについて書こうとするとそれなりにマニアックなところを狙わないと記事にしづらいので、大変だろうと思ってのことです。次回か次々回あたりはJava7ネタかもしれません。

大和田さんと白土さんの「Rubyわくわくナビ」はRuby1.9の標準ライブラリの紹介記事でした。Javaの記事を書くのも(差別化の点で)大変ですが、実はRubyもJavaと同じぐらいありふれてしまった上に、今や書籍もたくさんあるので、同じ程度に大変なようです。実際、前号までのRuby連載記事は後半ネタ切れ感が漂っていました。「再考するJava」は、こんな風にマニアックな部分を突いていくんだなという方向性が見えたのに対し、「Rubyわくわくナビ」のほうは今月号を読んだだけではまだ方向性が見えません。

太田さんの「JavaScriptベストプラクティスラボ」は安定感を感じる記事でした。今回の記事はかなり古典ネタです。しかし、いつでも新規なネタにも振れそうで、引き出しがいくらでもありそうです。

これは古典ネタかもしれませんが、次のようなコードを書いてJavaScriptのエラーをサーバ側のログに残すテクニックが興味深いと思いました。明日、社内の誰かに教えてみます。

新連載の最後は、小野さんの「いまどきの.NET開発」です。客観的に見ると、サーバサイドはLAMPより.NETのほうが開発生産性が高そうです。クライアントサイドもHTML5よりSilverlightのほうが進んでいる気がします。しかし、皮肉なことに開発生産性の高さがすべてではありません。.NETのように綺麗に舗装された道路よりも、HTML5の未舗装な道路のほうが魅力的に見えます。そんなものです。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under .


「Emacsのトラノマキ」の原稿を公開します。画面上のメニュー「ドキュメント」からたどれます。今回の記事は袖山さんが執筆した「Lispインタープリタ」です。Software Design 2010年5月号の掲載記事です。本作は、Emacs連載記事なのにEmacsのことをほとんど書かずにLisp処理系の実装方法を解説した問題作です。

今発売中のSoftware Design 2011年7月号の「Emascのトラノマキ」は、アリエル最年少、23才(か24才)の藤田さんがSKKの記事を書いています。

SKKなんてとっくに終わったと思っていたら若者の間で再ブレイクしているみたいです。怖い話です。

とは言え、藤田さんに「たまご」を知っているかと聞いたら知らないようでした。まだまだ若いです。

たまごは、たくさん・またせて・ごめんなさい、です。たかなは、たまごよ・かしこく・なーれ、です。ついでにWnnは、わたしの・なまえは・なかのです、です。Wnnは有名すぎて知らない人はいないかもしれません。

Software Design (ソフトウェア デザイン) 2011年 07月号 [雑誌]


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


jsdo.itのCSSゲームプログラミングが凄いですね。
私も簡単なじゃんけんゲームを作ってみました。
Firefox5のみで動作します。

じゃんけんゲーム – jsdo.it – share JavaScript, HTML5 and CSS

Chromeも対応したかったのですが、兄弟セレクタでの上書きがうまくできなかったので断念しました。
http://jsdo.it/ksk1015/wfPs

実は元々このゲームはアリエル・エンタープライズ製品内に入っていました。
半年位前に私がリファクタリングのためこのゲームを消したら社内から猛反発を受けたため、今回CSSゲームとして復活させました。

このゲーム、一見すると問題のパターンがランダムに見えるのではないでしょうか。
仕掛けは問題の前に必ずクリックさせるボタンにあります。
このボタンは@keyframesを使ったアニメーションで6個の同じ外見をしたボタンを次々に表示させています。
そして6個のうちどれが押されたかで次の問題を決定しています。(だからボタンが押しにくい)

まあ通常コンピューターの扱う乱数なんて疑似乱数なんだから、ユーザーに規則性がバレなければ乱数って言っちゃってもいいんじゃないですかね。


関連文書:

  • 関連文書は見つからんがな