2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2006年11月29日1


本家Permlink


2006年11月29日

仕事でC++使ってるのにBoost知らない人がいたんで
ビックリ。自分よりかなりデキル人なんですけど。

今さらですけど、一応書いときますけど、Boostって
いうのはC++のライブラリ。自分がグダグダ書くより
Wikipediaの説明読んでもらったほうが早いですか:

http://ja.wikipedia.org/wiki/Boost

つまり、Boostっていうのは『準』標準。Javaにおける
Jakartaみたいな存在といっていいでしょう。

ライセンスもかなりゆるく、新しい、つまり広告条項の
ないBSDとほぼ同じと考えていいようです (各自しっかり
確認すること)。

ここでも何度か書いてますけど、『C++もしぶとくがんばっ
てるなぁ』と自分が感じたのは、このBoostが出てきたから
です。

C++のライブラリやフレームワークはいくつかあって。
たとえばMozilla、OpenOffice.org、KDE/Qtなんかが
あるわけですけど、どれも製品は有名なんですけど、
そのライブラリがよく使われてる印象ってのはほとんど
受けないんですよね。そんな中でBoostは別格の存在感な
わけです。

--

もう1つショックだったのが、『こういうのって責任の
所在が曖昧じゃないですか』っていう。ようは、『何か
あったら誰が責任取るの?』論です。こんな話、今に
なってまた耳にするのは信じられませんでしたね。

はっきりいって、オープン・ソースだろうが独占だろうが、
他人が作ったもんなんだから、そんなもん、誰も責任
なんか取っちゃくれねーっつの。オープン・ソースだろうが、
独占だろうが、ライセンス読みゃあ、絶対『責任
取りません』っていう一文が入ってるもんです。

『困ったときに誰に聞けばいいの?』っていうのも。
そんなもん、作った人に聞きゃあいいじゃん。そのために
メーリング・リストとかがあるわけでしょ。答えてくれる
とは限らないけど、そんなもん、独占だって同じだよ。

それに、そんなに答えほしいんなら、カネ出しゃいい
じゃん。コミュニティのパトロンになれば、向こうだって
特別扱いしてくれるでしょ。それは何らやましいことじゃ
ない。

本家Permlink


2006年11月28日

最近は後置ifよりandかorを使うほうが好き。
やっぱり条件が先にあったほうが安心する。

--

RPGっていって、テーブル・トークじゃないところが
時代だよな。

本家Permlink


2006年11月27日

単純に考えるというより、よく観察しろという問題だった。
まぁ、単純にはなったんだけど。

本家Permlink


2006年11月25日1

ぐお。java.awt.Pointは、java.awt.geom.Point2Dの
サブクラスだったのか。

--

なに、このハンッパなEnum (笑)。
switchでしか使えねーじゃん。

enum Day { SUNDAY, MONDAY, TUESDAY, WEDNESDAY,
            THURSDAY, FRIDAY, SATURDAY }

public class jv {
    public static void main(String[] args) {
        Day d = SUNDAY;
    }
}

なんでこれでコンパイル・エラーになんの?
だから、型わかってんだから、いちいち書かせんなっつの。
こんなん型推論以前の話じゃん。

実際の話、Enumって:

class Foo {
    enum Day { SUNDAY, MONDAY, TUESDAY, WEDNESDAY,
	 THURSDAY, FRIDAY, SATURDAY }

    ...
}

みたいに使うわけじゃん? ってことは、Foo以外の
とこじゃ、Foo.Day.SUNDAYとかになるわけじゃん?
頭おかしいとしか思えんよな。でなきゃプログラマを
腱鞘炎にでもしてぇのか。

だから、正直者がバカを見るようじゃダメだろっつの。
いくらEnum使うべきだっつったって、そんなん使い勝手が
悪かったらだ〜れも使わねっつの。

--

そうなんだよな。いくらGPUががんばってるっていったって、
CPUが遊んでるわけじゃないだろうし。それでいてゲーム
みたいなポリゴングリグリ動かせるんだから、自分が
描く矩形みたいな2Dの描画でチマチマ最適化したって
しょうがない。ここでいう最適化っていうのは、
いわゆる最適化であって、精度を上げるためのもじゃ
なくってね。

--

でも、やっぱりJavaはいいですよね。上で書いたみたいな
不満もあるんですけど、それはゼータクな話で。他の
言語はもっと他のことでわずらわしいことが多いですから。

java.awt.geomを中心にいじってるんですけど、よく
できてますよね。ドキュメントもチュートリアルも充実
してるし。このあたりはSunの底力って感じです。

もっとJavaのアプリケーションが増えていいように
思うんですけど。

ま、それをいったらVisualWorksだってDelphiだって
そうか (笑)。

本家Permlink


2006年11月25日

まあ、あれだ。それがライブラリとして用意されている
んならともかく、そうでなけりゃ自分で作んなきゃいけ
ないんだし、そうなりゃ自分で検証しなきゃいけない
んだし、そもそも正しいっていう自信がなけりゃ正しい
もんが作れるわけもない。つまり、1つの事柄に実装
手段がたくさんあるってことは、その事柄の正しさって
いうのもたくさんあるってことだし、拙いやり方だと
精度が落ちたりいろいろ問題があるんだけど、それは
それでしょうがない。ある精度の範囲では正しいんだし、
その範囲を超えるってことは自分の能力を超えてるわけ
だし、そんときは頭のいい人に最適化してもらえばいい。

--

ちょっと言い方が雑だった。つまり、オレにできるのは、
ある精度の範囲内で正しくて、なおかつ精度を上げる
ための最適化がやりやすいように実装することなんだ。

つまりは、意図を明白にし、なおかつ意図を細切れに
しておくこと。

本家Permlink


2006年11月24日1

数学好きのOOPな人といえばSRAの青木氏。

http://www.sra.co.jp/people/aoki/TextbookAboutJun/35.html

直線の媒介変数表現とか、はじめて知りましたよ。

--

むぅ。C++のcomplexって、こういうふうに使うんですか。

やっぱ前言撤回せざるを得ませんね。数学好きはOOP好き
だと。

まぁ、正確にいうと『数学好きは型好き』なんですけど。

--

いやぁ、やっぱり数学って奥が深い。って当たり前で、
なおかつ入口でウロチョロしてるだけなんですけど (笑)。

でも、残念ながら、数学まわりをライフワークには
できないんだなぁ。

まぁ、所詮自分はアプリケーション・プログラマって
ことです。

本家Permlink


2006年11月24日

そうだよなあ。オレも中学、高校あたりで基本的なCGの
授業でもあれば人生変わってたかもしれないよなあ。

--

http://www.youtube.com/watch?v=NWnXz63-Q1I

本家Permlink


2006年11月23日

『予想ケイチョー』って何のことかと思ったら、
『予想カイチョー』って読むんだったのか。
だったら、『予想Cay長』じゃなくって
『予想Kai長』って書いてくれよ。
ってか、それでもムリがあるだろ。

というわけで、12/7な。

--

いくら「ユースケースに登場する名詞はクラスの候補に
なる」ってわかってても、それを実際にクラスとして
コーディングするかどうかってのは、やっぱり実際に
コードを書いてからじゃないとわかんないんですよね。

それと、システムを作るっていっても時間がかかるわけ
でしょう。ってことは、それって、システムを作るって
いう過程なわけでしょう。で、それって、ほとんどが
学習の過程なわけでしょう。だから、イの一番にユース
ケース書いたときと、ある程度システムを作りはじめた
ときとじゃ、知識に差があるってことでしょう。

その知識の差は、もともとあって当然なものじゃない
ですか。それがないものと考えるほうが不自然じゃない
ですか。ある程度時間が経過していく中で、知識の量が
不変だなんていうのは、学習能力が信じられないくらい
欠落してなければあり得ない話じゃないですか。

だったら、過程の中で得られた知識を捨てることに一生
懸命になるより、どうやって今後にフィードバックする
かを考えるほうが前向きでしょう。

本家Permlink


2006年11月22日

いや、アルゴリズムをVBで書かれても困るんだよな。
``_''って演算子なの? 単項マイナス? それともNOT?

あ、これって、ひょっとして、Cでいう``\''なの?
『改行エスケープ』ってヤツ?

いや、いくらなんでも今のVBはそこまでバカじゃないよね?

--

ああ、java.awt.geom.Line2Dには線分の交差判定があるのか。

MathもRubyより充実してるよなあ。

--

へー、GNU ClasspathってGPLだったのか。

--

でも、y = ax + bのまんまオブジェクトとして実装してる
のってあんま見ないよな。まぁ、あれだよな。やっぱ
数学好きなヤツはOOP嫌いなんだよな (笑)。

もう今となっては捨てちゃうけど:

(さっきまでLine2Dと名づけていたのは秘密だ (笑))

class Line1D {
    private double a;
    private double b;

    public Line1D(double a, double b) {
        this.a = a;
        this.b = b;
    }

    public Line1D(double x1, double y1, double x2, double y2) {
        a = (y2 - y1) / (x2 - x1);
        b = y1 - x1 * a;
    }

    public double y(double x) {
        return a * x + b;
    }

    public double x(double y) {
        return (y - b) / a;
    }

    public double[] intersection(Line1D line) {
        double x = (b - line.b) / (line.a - a);
        double y = y(x);
        double[] result = new double[2];
        result[0] = x;
        result[1] = y;
        return result;
    }

    public String toString() {
        return "y = " + a + " * x + " + b;
    }

    public static void main(String[] args) {
        Line1D lineA = new Line1D(2, 3);
        Line1D lineB = new Line1D(-1, 6);
        double[] result = lineA.intersection(lineB);
        System.out.println("[" + result[0] + "," + result[1] + "]");
    }
}

本家Permlink


2006年11月21日1

あんまりいじめないで (笑)。

コの字なんですけど:

(1) drawPolygonで描きたい (ゆえにZ字のようになっちゃ
    ダメ)

(2) 4つの点が座標軸線と並行な辺を持つ長方形を描く
    (数学的な表現の仕方を知らない (笑))

っていう2つの前提があったわけですけど。でも、あれは
やっぱりバカすぎでしたね。X+Yの最少が左上ってのは
合ってるんですけど、だったらその反対が右下なわけで。
つまり、1回のソートで左上と右下は求まるということ。
で、残り2つのうちのXの小さいほが右上、大きいほうが
左下。だからソートは1回で済むはず。

def sort_points(points)
  points.sort! do |a, b|
    if a.x + a.y < b.x + b.y
      -1
    elsif a.x + a.y > b.x + b.y
      1
    else
      0
    end
  end
  if points[1].x < points[2].x
    tmp = points[1]
    points[1] = points[2]
    points[2] = tmp
  end
end

これを一般化して任意の4つの点でポリゴンを描くって
いう話。これだと:

  まず原点に一番近い点を選ぶ。もし距離が同じなら一番
  角度が小さいものを選ぶ。で、そこを中心として角度が
  小さい点を順に選んでいく

でオケ? ってことで続きはsuminさんのページで (笑)。

http://d.hatena.ne.jp/sumim/20061121/p1

--

今日の教訓:オレに数学やらせんな!

--

ふむ。まぁ、でも、仕事も面白いしな。だから残業する。

特に日本人は仕事好きな人多いしな。

まぁ、あれだ、ヒルマン監督も犠打を多用するように
なっただろ? あれは日本人には犠打が合っていると
いう理由からなんだそうな。犠打をすることでチームの
士気が上がるんだそうな。それと、日本じゃ観客も犠打に
納得するしな。

それとおんなじだよ。残業も。士気が下がらなきゃ
問題ない。イヤイヤやる残業はやるな。身体を壊す
残業は絶対やるな。家庭を壊す残業は絶対やるな。
まぁ、あとは常識だな。具体的な数字を上げれば、
月15〜40時間あたりってことになるだろう。40時間は
かなりオーバー気味だけどな。もちろん、15時間以下で
済むんならそれに越したこたあない。

--

ああ、あと、カネ目当ての残業も良くないと思うよ。
ほどほどにな。

本家Permlink


2006年11月21日

MVCっていう言い方は好きじゃないんで、ドメインと
プレゼンテーションっていう言い方をするけど。
それっていうのは、まず、1つの事象をドメイン・
オブジェクトとプレゼンテーション・オブジェクトに
分けて。で、同じドメイン・オブジェクトでも見え方が
違うんならそれに対応するプレゼンテーション・
オブジェクトは複数用意したほうがいいっていうこと。

ちょっとわかりにくい例かもしれないけど、たとえば
UMLにはクラス図とかシーケンス図とかあるわけだけど。
あるクラスのクラス図上での見え方と、シーケンス図上
での見え方は、当たり前だけど違うんだから、その
クラスに対応するドメイン・オブジェクトは1つだった
としても、それに対応するプレゼンテーション・
オブジェクトはクラス図用とシーケンス図用とを用意
したほうがいいっていうみたいなこと。

わかりにくい例で申し訳ない。

本家Permlink


2006年11月20日

import java.awt.Point;
import java.util.HashMap;

public class jv {
    public static void main(String[] args) {
    Point p0 = new Point();
    Point p1 = new Point(1,1);
    HashMap<Point, Integer> points = new HashMap<Point, Integer>();
    points.put(p0, new Integer(0));
    points.put(p1, new Integer(1));
    System.out.println(points.get(p0));
    System.out.println(points.get(p1));
    p0.move(1,1);
    p1.move(2,2);
    System.out.println(points.get(p0));
    System.out.println(points.get(p1));
    }
}

$ javac jv.java && java -classpath . jv
0
1
null
null

なんちゅうーワナ。いや、だったら、x,yの値
変えられちゃまずいだろう。って、まぁ、しゃーないか。
利便性との兼ね合いか。

--

ああ、やっぱりオブジェクトの唯一性っていうのは
大事なんですよね。上のは、まぁ、話が違うんですけど。

でも、コピーがデフォルトなのか、それとも意図しないと
コピーが生まれないのかっていうのは、結構デカイ。

前にまつもとさんが『C++ではポインタ渡しがデフォ』
みたいなことを書かれてたと思ったんですけど。それには
唯一性の話も含まれてるんじゃないですかね。

--

だから、LL、たとえばRubyなんかの表記法は、心理的な
負担も減らしてると思うんですよね。配列なんかに
しても:

array = []

っていうほうが気軽に使おうと思うじゃないですか。
でも、C++だと生の配列のほうが手軽な表記法で、しかも
実際に軽いっていうのがわかっちゃってるもんだから、
なかなかvectorを使おうっていう気持ちにならないんじゃ
ないかって気がするんですよね。

こういうのが積もり積もって、LLの生産性が高いって
いわれるんじゃないかと思うわけです。もちろん、
絶対的にタイプ量が少ないっていうのもあるんですけど。

こういうのって、最適化の話でもあるんですよね。
プログラマっていうのは、ほんっとに貧乏性で、
なかなか富豪にはなれないんです。でも、Rubyみたいな
感じだと最適化へのプレッシャーが少なくって、だから
問題に集中できちゃう。

もちろん、これは、最適化の手段が少ないっていう
デメリットと裏表なんですけど。

--

4つの座標を『コ』の字の順に並べる。drawPolygonのためね。
これは富豪というより単にバカなだけなんですけど。
今見て笑っちゃいました (笑)。

まぁ、でも、最適化は頭のいい人がやってくれそうだから。
って思ってると、いつまでも残っちゃったりするんだよ
なあ (笑)。

import java.awt.Point;
import java.util.*;

class RectPointSorter {
    private static final Comparator<Point> CMP_TOP_LEFT =
        new Comparator<Point>() {
            public int compare(Point o1, Point o2) {
                if (o1.x + o1.y < o2.x + o2.y) return -1;
                if (o1.x + o1.y > o2.x + o2.y) return 1;
                return 0;
            }
        };

    private static final Comparator<Point> CMP_Y =
        new Comparator<Point>() {
            public int compare(Point o1, Point o2) {
                if (o1.y < o2.y) return -1;
                if (o1.y > o2.y) return 1;
                return 0;
            }
        };

    private static final Comparator<Point> CMP_X =
        new Comparator<Point>() {
            public int compare(Point o1, Point o2) {
                if (o1.x < o2.x) return -1;
                if (o1.x > o2.x) return 1;
                return 0;
            }
        };

    public static ArrayList<Point> sort(Point p1, Point p2, Point p3,
                                        Point p4) {
        ArrayList<Point> sorted = new ArrayList<Point>();
        sorted.add(p1);
        sorted.add(p2);
        sorted.add(p3);
        sorted.add(p4);
        Collections.sort(sorted, CMP_TOP_LEFT);
        Point tl = sorted.remove(0);
        Collections.sort(sorted, CMP_Y);
        Point tr = sorted.remove(0);
        Collections.sort(sorted, CMP_X);
        Point bl = sorted.remove(0);
        Point br = sorted.remove(0);
        sorted.add(tl);
        sorted.add(tr);
        sorted.add(br);
        sorted.add(bl);
        return sorted;
    }
}

本家Permlink


2006年11月19日1

そうなんだ。自分がバカであることを知れば知るほど、
先が読めなくなり、変化を受け入れるしかなくなるのだ。
つまり、XPを受け入れるには、自分がバカであることを
自覚すればいいだけの話だ。

頭のいい人間にXPは必要ない。彼らは超人的な洞察力で
要件を察知し、超人的な予知能力で仕様がどう変化するか
察知できるのだから。

本家Permlink


2006年11月19日

寿命の管理するんならヒープからオブジェクトを取った
ほうがいいんだよな。そうじゃないとコピーが生まれ
ちゃうから。

例として、さっきの続きの話で、矩形を描く
コンポーネント。当然、これは矩形を配列で持つわけ
だけど:

public class MyCanvas exntends Component {
    private ArrayList<DrawnRect> rects = new ArrayList<DrawnRect>();
}

で、たとえばアクティブな矩形を複数管理したいとすると:

public class MyCanvas exntends Component {
    private ArrayList<DrawnRect> rects = new ArrayList<DrawnRect>();
    private ArrayList<DrawnRect> actives = new ArrayList<DrawnRect>();
}

みたいになる。もちろん、activesの中にある矩形は、
rectsにあるどれかと同じオブジェクト。これがコピー
だったら面倒なことになる。

つまり、これがC++だとすると、rectsはvector<DrawnRect>
でも構わないんだけど、activesはvector<DrawnRect*>で
なきゃダメだっていうこと。とはいえ、まぁ、rectsも
ヒープ・オブジェクトで管理することになるんだろう。
となると、デストラクタ書くのが面倒だから
vector<hared_ptr<DrawnRect> >で管理したくなるって
ことだ。

class MyCanvas : public Component {
private:
    std::vector<boost::shared_ptr<DrawnRect> > rects;
    std::vector<DrawnRect*> actives;
};

C++の宿命だけど、あんまりこういうことで悩みたく
ないよなあ。

--

あと、上みたいな使い方するからshared_ptr#getは
あったほうがいいと思う。activesもshared_ptrで
管理することはできるんだけど。でも、そんなに
shared_ptr使いまくるんならGC使ったほうがいいんじゃ
ないの。

--

ああ、あと、C++やる人は、vectorとかmapをバンバン
使わないと。

というか、vectorに限らず、オブジェクトのコストは
安いと思わないとダメ。

本家Permlink


2006年11月18日1

http://www.youtube.com/watch?v=dA2HPdOnQUk

だれ、このシムラケン。

--

ブレイク・スルーみたいなのがほしいんなら、SICPとか
読んだほうがいいだろうし。でも、そうじゃない人も
たくさんいるし。で、そうじゃない人にとっても、
ポインタや再帰は知っておかなきゃいけない知識なんだ
けど、SICP読破しなきゃ理解できないわけじゃないし。
で、オブジェクト指向プログラミングというかADT
プログラミングの知識っていうのもそうじゃない人に
とって知っておかなきゃいけない知識だと思ってるって
こと。

--

あんまり上の話と関係なくって、ここ最近書いてる
『ベタ』について。

たとえば、4点で矩形を表して、それを描画するような
プログラム。こういうのはOOPがもっとも得意とする
とこなんでエコヒーキになっちゃうけど。これを
Component#paintの中だけで書こうとすると、結構大変。
でも、描画される矩形のクラスを切り出して、線の
描画をベタにやっちゃえば単純になる:

class DrawnRect {
    public void draw(Graphics g) {
        setPenColor(g);
        g.drawLine(p1.x, p1.y, p2.x, p2.y);
        g.drawLine(p2.x, p2.y, p3.x, p3.y);
        g.drawLine(p3.x, p3.y, p4.x, p4.y);
        g.drawLine(p4.x, p4.y, p1.x, p1.y);
    }
}

当然、このDrawnRectのコンストラクタで点の座標を
望む順にソートしておかなきゃいけない。

で、もし、矩形の大きさを変えるハンドルをつけたいんなら:

    public void draw(Graphics g) {
        setPenColor(g);
        g.drawLine(p1.x, p1.y, p2.x, p2.y);
        g.drawLine(p2.x, p2.y, p3.x, p3.y);
        g.drawLine(p3.x, p3.y, p4.x, p4.y);
        g.drawLine(p4.x, p4.y, p1.x, p1.y);
        if (active) drawResizeHandles(g);
    }

    private void drawResizeHandles(Graphics g) {
        drawResizeHandleUpper(g);
        drawResizeHandleRight(g);
        drawResizeHandleLower(g);
        drawResizeHandleLeft(g);
    }

    private void drawResizeHandleUpper(Graphics g) {
        Rectangle rect = getResizeHandleRectUpper();
        g.fillRect(rect.x, rect.y, rect.width, rect.height);
    }

    private Rectangle getResizeHandleRectUpper() {
        int x = p1.x + (p2.x - p1.x) / 2 - RESIZE_HANDLE_SIZE / 2;
        int y = p1.y + (p2.y - p1.y) / 2 - RESIZE_HANDLE_SIZE / 2;
        return new Rectangle(x, y, RESIZE_HANDLE_SIZE, RESIZE_HANDLE_SIZE);
    }

みたいにベタに書く。矩形の4つの辺をforループで
回して描くっていうこともできるんだろうけど、
上みたいにクラスを切り出して、さらにそのメソッドを
切り出して・・・ってやったほうがわかりやすい。わかり
やすいっていうのは、書いてる本人にとってわかりやすい
ということ。似たような処理が10個20個あるなら別だけど、
4個くらいだったらベタに書く。

こういうベタな書き方で、なんとなく設計っぽくなるのが
OOPのいいところ。それに、ベタで書いてるからバグも
入りにくいし、あったとしても、どこがダメかすぐわかる。

それと、クラスを切り出して、それが必要とする
メソッドを切り出していくっていうのは、P.Graham氏の
いうボトムアップ・プログラミングに近いものがある。

本家Permlink


2006年11月18日

$100 PC、買えるもんなら書いたいけど (5万だったら
ヨユーで買いたい)、今の仕事場、私物PC、ダメなんだ
よなぁ。バカとしか思えないんだけど。だって、WinCEの
ケータイはオッケーだっつーんだから。PDAってことで
オッケーにしてくんねーかな。

--

久しぶりにJavaを。しかもGUIがらみ。

やっぱり手に馴染んだGUIフレームワークがあるって
いうのはいいね。Tkも悪くないんだけど、カッチリした
イベント・ドリブンでやりたかった。

でも、最初Debianでやろうしたんだけど、フォントやら
何やらで面倒なことに。クソSunは相変わらずDebianを
ディストロと認めてないみたいだしな。それでGPLとか、
笑かすなよ。

で、しょうがなくWindowsで。もうほとんど忘れてて、
イテレータの回しかたすら覚えてなかった。んで、
例によって素晴らしいチュートリアルのお世話に。
ジェネリックスと新しいfor構文、いいっすね。
ジェネリックスは型推論がないと、タイプが著しく
増えちゃうんで、いいことばっかじゃないけど。だって:

ArrayList<Foo> foos = new ArrayList<Foo>();

って、どう見たってムダじゃん。なんでArrayList<Foo>
なんて長い型を2回もタイプしなきゃなんないの。
こういうコード書いてると、自分がバカっぽく思えてイヤ
なんだよな。まぁ、もとからバカなんだけど。

ああ、それと、最初Awtでやろうとしたんだけど、もう
Awtはマトモにサポートされてないのかな。自分、Awtの
時代の人間なんで。で、こっちもしょうがないんで、
素晴らしいチュートリアルのお世話に。っつっても、
SwingのクラスはJFrameくらいしか使わないんだけど。

--

あの記事、ポインタと再帰を持ち上げすぎじゃない?

ポインタと再帰を理解するのにSICP読破する必要なんて
ないでしょ?

一理あるにしても、でも、オブジェクト指向がダメって
いうのはいかがなものか。

オブジェクト指向っていうのは、現実世界をマネる
ためじゃなくって、考えをまとめる、考えを構造化する
ためにあるでしょう。クラス、もっと一般的にいえば
ADTで考えるっていうのは、プログラミングでも重要な
ことの1つじゃないの?

いや、そういうのはCとかSchemeとかでも学習できる
んだけど、素直にOOPL使えばいいじゃん。

--

ああ、あんなのには型推論なんていらないんだ。

ArrayList<Foo> foos = new();

って書ければ十分なわけで、この構文糖に推論なんて
いらない。

本家Permlink


2006年11月16日

ノートPCのフタ (ディスプレイの裏側) がホワイトボード
だったら便利じゃかなろうか。

本家Permlink


2006年11月15日1

Simplicityっていうのは、ほんとにむずかしいです。
どんなに単純にやろうとしてても、どっかで小賢しい
ことをやっちゃうんですね。だから、単純にやるって
いうのはとっても勇気がいるんです。『これだと効率が
悪いんじゃないかな?』とか、『誰かにバカにされない
かな?』とか、そういう気持ちを振り切って、なおかつ
『これでいいんだ!』って強く思わないとできない
んですよね。

--

だから、設計も自明なくらい単純にならないといけない
んですよね。ヘタにループを回すくらいなら、ベタに
書いたほうがいいことだってあるんです。

本家Permlink


2006年11月15日

後ろに座ってる人がハマってるというので話を聞いてたら、
どこがおかしいかわかった。自分は何もしてなくって、
「どこがおかしいの?」とか「それおかしくない?」
とか話を聞いてるだけだった。

この人とペアを組んでたわけじゃなくって、なんの気
なしに話しかけたらハマッてるというので話を聞いて
みただけだった。

本家Permlink


2006年11月14日1

あと思うのは、みんな『一歩』がデカイんですよね。

一歩の大きさは自由に決めていいんですけど、自信が
ないときでも先を急いで大きくしてる。自信がない
ときは小さく進まなきゃいけないのに。

それと関係するんですけど、ツバサくん風にいえば、
『コンパイラは友だち!』なんですよね。安心感を得る
にはテストが一番なんですけど、まぁ、コンパイラも
それに近い存在なわけで。だから頻繁にコンパイル
したいし、だからビルドにかかる時間を減らしたい
んです。

静的型好きな人は動的言語をバカにしますけど、そう
いう人のほうがコンパイラを活用してないことが多い。
ガリガリ書きまくって、コンパイル・エラー出し
まくって、それから1つずつ潰してくなんていう気の
遠くなるようなことをやる。関数1つ書いたらコンパイラ
通しゃいいのに。

だから、TDDには一歩の大きさを小さくする効果がある
んですよね。ひょっとしたら、それがTDDの一番の
実際的な効果かもしれない。それが安心感につながる。

仕事のプログラミングは時間との戦いで、どうしても
急ぐ気持ちが強くなっちゃいます。それと、心情と
しても、遅いより速いほうが気分がいいっていうのも
あります。でも、はやる気持ちをグッと抑えてガマン
することも大切なんじゃないですかね。それは『ゆとり』
っていうのとちょっと違うんです。やっぱりガマン
なんですね。ちょっと日本人的な発想かもしれません
けど。

--

結局、しっかりした設計のほうが、バグも少なくなるし、
仕様の実装し忘れなんていうのも減るわけだ。

もちろん、『しっかりした設計』っていうのは前払いを
意味するわけじゃない。リファクタリングを重ねる
ことで、しっかりした設計というものは得られる。

で、OOPLなら、設計の基本単位はオブジェクト (あるいは
クラス) なわけで、責任を担うオブジェクトを作って
いかなきゃいけないわけだ。責任を担うオブジェクトを
作るっていうのは、要は、責任の分散だ。データと
それに対する処理をまとめる。そういう当たり前の
ことをきっちりやってかなきゃいけないんだな。

本家Permlink


2006年11月14日

Boostのshared_ptrにはget()があって、生ポインタを
取り出せるんですよね。これ、非難の対象になることが
度々あるみたいですけど、自分は悪くないと思うんです
よね。

前にも書きましたけど、shared_ptrを使いたくなるのは、
newしたオブジェクトをvectorなんかのメンバ変数で
持ちたいとき:

class Container {
private:
    vector<shared_ptr<Elment> > elements;
    ...
};

当然、このクラスの内外で、vectorの要素1つに対する
処理がありますよね。そんなとき、わざわざshared_ptrを
渡す必要はないですよね:

void
do_something(Element *e)
{
    ....
}

もちろん、これがうまくいくためには、『生ポインタに
対してdeleteしちゃいけない』っていう紳士協定が
必要になります。でも、ただでさえ忘れるdeleteを
わざわざやるバカはいないでしょ (笑)。

これは効率を気にしていってるわけじゃないんです。
shared_ptr<Element>なんていちいちタイプしたく
ないんです (笑)。typedefも嫌いだし。

--

いや、インテリセンスがあるとかの問題じゃないよ。
目にうるさいのはやっぱり害悪だから。

--

心配しすぎるとロクなことにならない。そういうのは
Singletonパターンに似て、やるだけムダ。

本家Permlink


2006年11月13日

いや、カタカナをカッコワルイと思うのは日本人だから
で、外国人は逆に「カッコイイ」って思ってるのかも。

最近見た中で一番インパクトがあったのが「家族愛」
っていうタトゥー (笑)。二の腕の目立つとこにあった。
誰がやってたか忘れたけど。

--

いやー、スマートポインタがえらく不評でビックリ。

C++使ってる人はフツーに使ってるもんだと思ってたよ。

本家Permlink


2006年11月12日1

反省

本家Permlink


2006年11月12日

http://www.ne.jp/asahi/dsp/apocalypse/oj-otoko-4.html

男色ディーノに元ネタがあったなんて知らなかったよ。

--

結局のところ、ほしいのは、思索するためのツールな
わけだ。思索というのはまさに作り出すことであって、
できあがったものを写生することじゃない。そこを
勘違いするからUMLの記号は増える一方だし、ホワイト
ボードのコピーも役に立たない。

思索というのは何も宙をボーッと眺めてやるものじゃ
ないし、人にもよるけど、手を動かすと効果的なことも
多い。もちろん、図を描くのも1つの手段ではあるんだ
けど、思考の速度というのはものすごく速くて、少なく
とも今のコンピュータ・パワーじゃそれに追いつけない。

だから紙なわけだ。最低限必要なものだけを紙に書いて、
それらをテーブルの上で自由に動かしてみる。紙片の
間の関係なんて、わざわざ線なんか引っぱらなくっても、
ちょっとの間なら覚えてられるもんだ。

--

大体、ペアでナビをやってるとき、PCはドライバに
独占されてるわけで、ナビに与えられてる道具といえば
紙切れとペンくらいなもんだ。

--

それとおんなじことがTDDにもいえるんだ。

プログラミングで誰もが疑問に思う根本的なこと。それは:

  何もわからないところからどうやって作りはじめればいい?

ということだ。その答えとしてOOAとかがあるわけだ
けど、ぶっちゃけいって、そんなに役に立たねーんだな。
というか、OOAやって見えるもんって、そんなもんすぐに
見つかるもんなんだよな、大抵は。

問題なのは『それが本当に動くのか?』ってとこなんだ。
だから『動かす』ことにフォーカスしなきゃなんねーんだ。
わからないんなら、わかるとこから始めなきゃなんない。
動かせそうなとこから始めなきゃなんない。いきなり
屋根作ったってしょーがあんめー。それ乗っける柱も
ねーのによ。それをやろうとしてたのがOOAからOODって
流れだったわけだ。そりゃダメだろ。

だから、TDDっていうのは思索を支援してるわけだ。
だから、TDDが設計技法っていうのはハズレじゃないけど、
ちょっと見方が狭い。やっぱり新しいプログラミングの
進め方なんだよな。

--

だいたよー、OOAとかギョーギョーしい名前がついて
たって、書いてあることって『ユースケースから名詞を
抜き出しましょう』とか、その程度のことじゃん?

アナリシス・パターンとか、あそこまで行っちゃうと
別世界だし、ああいうのが必要な場面がそんなに
あんのか? 大体、プログラマが一生のうちで触る
ドメインなんて、そういくつもねーだろ。それこそ
コンサルでもやんねーかぎり。ってことは、ドメインを
またぐような共通のパターンとかってあんまり意味ねー
じゃん。抽象度が高けりゃいいってもんじゃねーだろ。

--

それとさー、大規模大規模ゆーけどさー、大規模に
なったら技術的な問題より人的問題のほうがデカく
なるじゃん。そんなん当たり前じゃん。

そこがパラドックスじゃん。オブジェクト指向は大規模
開発のために生まれたっていうけどさ。人が増えたら
オブジェクト指向のこと知らない人も増えるわけじゃん。

だからC++なんか全然大規模開発に向いてるわけねーじゃん。
コード行数が増えるっていう意味で大規模だっていうん
ならまだしも。そうじゃないんでしょ? だったら、
百人以上もの人間がC++をまともに知ってるなんて、
期待するほうがバカじゃん。

本家Permlink


2006年11月11日

恥ずかしながら、つい最近まで、C/C++の基本的な
カプセル化のテクニックを知りませんでした。

下にコードをあげておきますけど、このテクニックを
使うことで、外部から構造体のメンバに直接アクセス
できなくなるんですね。

それと、このテクニック、メンバに直接アクセスできなく
なるっていう情報隠蔽の効果だけじゃなくって、
ファイルの依存関係を減らすっていう効果もあるんです
よね。下のコードだとわかりにくいでしょうけど、C++の
クラス定義ヘッダだと効果絶大です。

でも、このテクニックも万能じゃなくって、使う側では
ポインタか参照でないと構造体を使えませんから、
スタックによる自動解放が期待できません。C++だったら
スマート・ポインタで負担は軽減できるでしょうけど。

ちなみに、このテクニックはincomplete classって
呼ばれるみたいですね。stdio.hのFILEがその代表例だとか。

http://www.boost.org/libs/smart_ptr/sp_techniques.html

/*
 * counter.c
 */
#include <stdlib.h>

struct counter {
    int count;
};

struct counter *
new_counter(void)
{
    return calloc(1, sizeof(struct counter));
}

int
get_count(struct counter *self)
{
    return self->count;
}

void
count_up(struct counter *self)
{
    self->count++;
}

/*
 * counter.h
 */
#ifndef counter_h_guard
#define counter_h_guard

struct counter;
struct counter *new_counter(void);
int get_count(struct counter *self);
void count_up(struct counter *self);

#endif /* counter_h_guard */

/*
 *main.c
 */
#include <stdio.h>
#include "counter.h"

int
main(void)
{
    struct counter *counter = NULL;

    counter = new_counter();
    printf("%d\n", get_count(counter));
    count_up(counter);
    printf("%d\n", get_count(counter));
    return 0;
}

--

他にもスマート・ポインタを使いたくなるのは、
クラスのメンバにvectorみたいなのがあるとき。要素の
管理がコピーで済むなら問題ないけど、そうじゃない
ときも結構あります。そうすると、デストラクタで
vectorをチマチマたどって1つずつdeleteしなきゃ
いけない。

#include <iostream>
#include <vector>

using namespace std;

class Foo {
private:
    int id;

public:
    Foo(int id) : id(id) {
        cout << "new " << id << endl;
    }

    virtual ~Foo() {
        cout << "delete " << id << endl;
    }

    virtual int getId() {
        return id;
    }
};

class Container {
private:
    vector<Foo*> foos;

public:
    ~Container() {
        for (vector<Foo*>::iterator i = foos.begin();
	     i != foos.end(); ++i) {
	    delete *i;
       }
    }

    void add_foo(int id) {
        foos.push_back(new Foo(id));
    }
};

int
main()
{
    Container container;
    container.add_foo(0);
    container.add_foo(1);
    container.add_foo(2);
    return 0;
}

こんなの面倒だからスマート・ポインタを使って
デストラクタを書かずに済ませたい。

というわけで、スマート・ポインタのお勉強。

Boostを使うのが定石なんでしょう。Boostのスマート・
ポインタにはいくつか種類があって、よくわからない
んですけど、shared_ptrを使っときゃいいみたい。

次のコードは、Boostのサンプルとほぼ同じなんですけど、
気にしない。変わるのはContainerだけ:

class Container {
private:
    vector<Foo*> foos;

public:
    ~Container() {
        for (vector<Foo*>::iterator i = foos.begin();
	     i != foos.end(); ++i) {
	    delete *i;
       }
    }

    void add_foo(int id) {
        foos.push_back(new Foo(id));
    }
};

--

ところで、ここでメンバfoosのぜんぶの要素を書き出す
メンバ関数を追加すると:

    void print_foos() {
        for (vector<shared_ptr<Foo> >::iterator i = foos.begin();
             i != foos.end(); ++i) {
            cout << (*i)->getId() << endl;
        }
    }

みたいな感じ。たかが配列たどるのに何文字タイプ
しなきゃなんないんだって話。こういうのはtypedef
するのが常識らしい:

class Container {
private:
    typedef shared_ptr<Foo> FooPtr;

    vector<shared_ptr<Foo> > foos;

public:
    void add_foo(int id) {
        shared_ptr<Foo> foo(new Foo(id));
        foos.push_back(foo);
    }

    void print_foos() {
        for (vector<FooPtr>::iterator i = foos.begin();
             i != foos.end(); ++i) {
            cout << (*i)->getId() << endl;
        }
    }
};

でも、typedefしたって、大してタイプ量が減らないように
思うのは自分だけ? こんなんだったらイテレータなんか
使いたくない。結局、正直者がバカを見るようじゃダメ
でしょ。まぁ、C++には型推論とか入るはずもないから、
正直者は報われないわな。

--

shared_ptrそのものがスタックから消えたときは、
もちろん、それが指してるオブジェクトのデストラクタが
走ります。じゃあ、指す先を変えたときは?

指す先を変えるにはresetを使います:

int
main()
{
    shared_ptr<Foo> p(new Foo(0));
    p.reset(new Foo(1));
    p.reset(new Foo(2));
    p.reset(new Foo(3));
    p.reset(new Foo(4));
    return 0;
}

Fooは前と同じだから省略。で、これの出力結果は:

new 0
new 1
delete 0
new 2
delete 1
new 3
delete 2
new 4
delete 3
delete 4

というわけで、resetするとデストラクタが走る。

本家Permlink


2006年11月10日

自分も他人のことをとやかくいえないんですけど、
講演みたいなときにする質問は、『いい質問』になる
よう心がけてます。

『いい質問』っていうのはいくつかあるんですけど、
その1つが質問された側が『待ってましたその質問』と
思うようなものですね。

逆に悪い質問っていうのは、質問された側が答えられ
ないようなもの。こういうのは場の流れが悪くなる。

それと、たとえ自分がわからないことがあっても、
すぐに質問はしません。それが個人的な疑問なのか、
それともその場の大勢の人も知ったほうがいいのか、
そういうことを天秤にかけます。個人的な疑問だったら、
講演が終わった後で尋ねればいいわけで。

こういうことを書くと『いい質問っていうのはヤラセか?』
なんて思う人もいるかもしれませんけど。じゃあ、
やらせじゃないとしたらセメントですよね。でも、
そんなセメントマッチ、誰が見たいっていうの?
質問するヤツの自己満足で終わっちゃうじゃん?
そんなもん、こっちは見たくねーんだよな。

だから、せっかくみんなと時間を共有してるんだし、
みんなが『ああ、有意義な時間だった』って思えた
ほうがいいでしょ。そういうことに頭を使いなさいと。
いや、頭使うな、気を使えってとこか。

--

おっと、筆がすべっちまったぜ。

--

こないだ書いた話は、何もペアに限ったことじゃなく
って。たとえば、あなたに高校生のお子さんがいたと
して。そろそろ進路が気になるお年頃。そんなある日、
お子さんが役者になりたいといいだした。どうします?

お子さんに役者としての才能があるかどうかなんて
あなたにはわからない。そっち方面のツテなんかもない。
つまり、あなたは先が見通せない状態なわけです。

でも、だからといってほっとくわけにもいかない。
何かしらアドバイスしてやりたいと思うでしょう。

『バカなことをいうな』とでもいいますか? まぁ、
それも先を見通せない状態で出せる結論の1つでは
ありますけどね。でもそれじゃ優秀なナビとはいえない
んじゃないですかね。

かといって、役者の世界を知ろうにも、そんなもん、
キリがありません。いつまで経っても先が見通せない
状態から抜け出せない。でも、それでもなんとか
選択肢を示してやりたいと思うでしょう。

役者をあきらめさせるのも1つですし、大学に進学し
ながら役者の勉強をしろというのも1つですし、どっかの
劇団のオーディションを紹介してやるっていうことも
できるでしょう。先を見通せないなら見通せないなりに、
なんとか道を探そうとするのが優秀なナビというものじゃ
ないですかね。

--

ああ、あと、勉強会で一番勉強になるのは、ネタを発表
する本人なんですよね。これは、ネタをよく調べて知識が
身につくっていう意味だけじゃなくって、発表の仕方って
いう、滅多に勉強できないことが勉強できるっていう
意味もあるんです。というか、そっちのほうがよっぽど
デカイ。

だからといって、自分は発表なんかしたくないですけど。

本家Permlink


2006年11月09日1

いや何がダメって、フツー、オフィスには手頃なサイズの
紙がないってことなんだよな。

ここでいう『手頃なサイズ』っていうのは、A4の半分、
つまりA5くらいのサイズ。A4はそれこそ掃いて捨てる
ほどあるけど、その半分ってのは全然ない。

だからマメな人はそれを半分に切ってクリップでまとめ
たり、さらにマメな人はそれを丁寧にノリで固めてメモ
帳みたくしてるんだけど、当然オレにそんなマネなんか
できっこない。

というわけで、定規を用意することにしよう。

ちなみに、XP周りでこの『手頃なサイズの紙』の重要さは
改めて書くまでもないんだけど、それでも書いておくと:

1. ストーリー・カード
2. Todoカード
3. CRCカード

といったところ。CRCカードはA6くらいのほうがいいかも
しれない。ってことは、ちょっと大きめのPostItでも
いいかもしれない。

とにかくだ。A4じゃ大きすぎる。

--

自分が書く『フツー』っていうのは、みんなが深く考え
ないで口にする『フツー』っていうのと同じですよ。上で
書いてるように。

大体、口に出すときは『普通』でもなければ『ふつう』
でもなくって『フツー』のはずですよ。そういう深く
考えていない『フツー』っていうニュアンスを出したい
がためにカタカナで『フツー』って書いてるんです。

『そんなんフツーじゃん』とか、『フツーやるでしょ』
とか、そういうときのフツーね。

上の文章を改まった書き方をすると:

  一般的な事務所には手頃な大きさの紙というものが
  なかなかないものです。それが私の悩みの種なのです。

  ここでいう『手頃な大きさ』というのは、A4の半分、
  つまりA5程度の大きさです。A4はプリンタ用紙の裏紙
  など事務所に豊富にありますが、A5程度の紙はなかなか
  見当たらないものです。

といったように、ここでの『フツー』は『一般的』と
いうのがピッタリで、それを『普通』と書いてしまうと
意味は通じても、ちょっとヘンな文章ということに
なりましょう。

本家Permlink


2006年11月09日

mdoc2man.rb、古いBSDライセンスだけどいいの?
イリノイ大学って広告条項無効宣言とかしたの?

もし広告条項が有効だとしたら、どうなるんですかね?

###  3. All advertising materials mentioning features or use of this software
###     must display the following acknowledgement:
###     This product includes software developed by the University of
###     Illinois at Urbana, and their contributors.

再配布の条件じゃないから気にしてなくっていいのかな。

本家Permlink


2006年11月08日1

そうはいってもやっぱりむつかしいですよね。

ペアでやるときの2人の役割。ドライバとナビ。
パイロットとコパイロット。コーダーとテスター。
生徒と教師。ボケとツッコミ。アリとキリギリス。

生徒と教師にしても、どっちが生徒で、どっちが教師
なのか。

ここでは仮にドライバとナビという呼び方をしますけど。
やっぱり、ナビの仕事を1つあげるとしたら、先を見る
ことなんですよね。先を見るっていうのは、高い視点
から見るっていうことですよね。ドライバは目の前の
路面に集中してますから、今走ってる道が正しいルート
なのか判断しにくい。

高い視点っていうと、アーキテクチャとかストーリーとか
から見るってことですよね。デザイン・パターン導入する
とか、大きなリファクタリングのネタとかっていうのが
アーキテクチャの視点。コードが仕様を満たしているか
とか、仕様そのものに抜けがないかっていうのが
ストーリーの視点。

それと、目的地が同じでも、そのルートの選び方で、
早く着けたり、安全に着けたりできる。そういう
選択肢を提示することもナビの仕事。

たとえば、ベタに書かれた関数群があって。そこに
Compositeパターンを導入したいと。この『Compositeを
導入する』っていうのが目的地。で、『じゃあ、どこ
から手をつけいく?』っていうのがルート。既存の
機能を壊さないような着実なルートで進みたい。
あるいは、一気に作り直すルートもある。そういう
選択肢を示す。

あと、余裕があるなら、ドライバと一緒にモニタを
見るだけじゃなくって、ちょっと周りを見てほしい
ですよね。別のペアの様子だとか、部屋全体とか。

アリとキリギリス。これを避けるためには、ナビは
ドライバに自分がいることを伝えないといけませんし、
ドライバはナビが眠らないようにしないといけない (笑)。

W.Cunningham氏もいってますけど、ドライバは何を
やるかを声に出して伝えないといけません。自分では
わかりきっていることでも、ナビにそれが伝わっている
とは限りませんから。というか、声に出さないとまず
伝わりません。

ビックリしたんですけど、黙ってキーを叩く人が多い
んですね。何をしゃべればいいかわかんないのか、
しゃべる習慣がないのか。

そんなもん、キーでタイプすることをそのまんま
しゃべるのでもいいと思うんですけどね。たとえば、
下みたいなコードを書くときに:

  def foo
    p true
  end

『でふふーぴーとぅるーえんど』って口に出すだけでも
違うと思うんですけど。

まぁ、自分なんかは1人でもしゃべりますけど (笑)。

ナビのほうは、先が見えないなら、まず見えないことを
はっきりと伝えないと。で、わからないことがあったら
遠慮なく尋ねる。できる人がドライバやってて安心
してると、案外ドライバも先が見えてなかったってことが
結構あります。第一、質問でもしないと眠くなっちゃう (笑)。
もう眠くなったら、無理矢理バカネタでも何でも話す。
眠るよりナンボかまし。もちろん、typoとかも気づけば
指摘しますけどね。

先が見えないなら見えないなりに、ナビするやり方は
あると思うんですよね。っていうか、ナビの極意は
それなんじゃないかと思うわけです。

だから、単純な『教える・教わる』っていう関係を
超えないと。そこを超えないと、死ぬほど知識を溜め
こまないとナビできないってことになっちゃいます。
知らないなら知らないなりに、ペアを組むことの
効果をあげないと。

本家Permlink


2006年11月08日

ああ、オライリーレーダーも最近チェックしてないなあ。

本家Permlink


2006年11月07日

いやいや (笑)。「フツーの人」っていう中には、
「フツー程度に学ぶのが好きだ」っていう意味も
含まれてるでしょう。

学ぶのがイヤだったら、そりゃフツーじゃなくって、
バカでしょ。上中下の下。ゲの人を使って成果を上げる
なんて、まぁフツーは不可能。

XP知るのだって、ちょっとしたきっかけがあれば
いいんですし。XP始めるのに何も特別な能力や才能は
必要ありませんから。だから、XPはフツーの人のための
プロセスだっていってるわけです。

--

ああ、あと、上で「フツーの人」って書いててこういう
こと書くのもアレなんですけど。集団や組織をそういう
十把一からげみたいな見方をすることにも違和感が
あるんですよね。

上中下の話もそうなんですけど、人って能力も個性も
いろいろですし。自分がいってるフツーっていうのは、
ある程度幅を持ったものですし、バカでもフツーくらい
になれるっていう信念みたいなもんもありますし。

だからDiversityっていうのは強みなんだと。それと、
XPの背後にあるのは明らかに「学ぶ」ことの大切さ
ですよね。Opportunityにしても、Failureにしても、
それは学ぶことの大切さをいってるわけです。

フツーでありながらも様々な個性を持った人たちが
集まって、みんなで学んでいけば、それですごいことが
できるんだぜっていうのが自分のいいたい、あるいは
実現したいことなわけです。

本家Permlink


2006年11月06日1

ギャラクシーエンジェル、一体どんだけ上がってるんだよ (笑)。

本家Permlink


2006年11月06日

あれ? evalのbindingってトップレベルがデフォルトだと
思ってたんだけど変わった?

本家Permlink


2006年11月05日

考えてみれば当たり前の話だ。

検索にしろ、広告にしろ、ヤツらはどこに人気が集って
いるかを把握してるんだ。だから、そこに投資すれば
いい。これほど確実な投資方法がかつてあったか?

本家Permlink


2006年11月04日

筑波大学の学生って、お金持ちなんだなぁ。

本家Permlink


2006年11月03日

http://premium.nikkeibp.co.jp/mail-sol/column/sakai/07/03.shtml

  また、流行りのキャラクターやお菓子をチェックするのも、モテるための努
  力としてとっつきやすいジャンルです。

な? 新しいお菓子のチェックは優れたメソッドなわけだ。
お菓子を自腹で買ってくるってのも、いってみれば1つの
モテ道なわけだ。いや、モテたことないけど。

--

BUBKA、駅前恋愛相談、クソワロタ。

--

ワルーエフという、タイムボカンみたいな名前を持つ
世界チャンピオンがいる:

http://ja.wikipedia.org/wiki/%E3%83%8B%E3%82%B3%E3%83%A9%E3%82%A4%E3%83%BB%E3%83%AF%E3%83%AB%E3%83%BC%E3%82%A8%E3%83%95

http://www.youtube.com/watch?v=tbX7KwE9OuI

世界チャンピオンといっても色々あるけど、ワルーエフは
4大団体の1つであるWBAのヘビー級チャンピオン。これ
まではドイツを主戦場として活躍していたが、最近では
あのドン・キングと契約して、米国に戦場を移した。

ちなみに、今、ヘビー級チャンピオンのほとんどが旧ソ連
勢で占められるという状況が続いている。(ただ、試合その
ものは米国で行われることが多い。)

お、ちょっとラジウムっぽい (笑)。

--

何か気になることがあったら、とりあえずWikipediaで
調べてみる。上の例でいえばワルーエフ。すると、
Valuevというアルファベット名がわかる。で、今度は
YoutubeでValuevを調べる。

もちろん、これと逆にYoutubeからWikipediaへと移る
流れもある。あるいは、カタナカのキーワードで、その
英語名がわからないときにはGoogleを使ったりもする。

こういう遊び方は、テレビに勝るとも劣らない1つの
メディア、娯楽になり得ると思うが、どうだろう。
つまり、そこでビジネスが成り立つはずだということ。

本家Permlink


2006年11月02日

さすがに「ういういdays」は小っ恥ずかして買えん (笑)。

本家Permlink


2006年11月01日

どうも自分は東プレのキーボードとは相性がよくない
みたい。

仕事場で使うために、唯一持ってる日本語キーボードと
して東プレのテンキーのないヤツを持ってったんですけど、
どうもコントロールキーが甘い。CapsLockをいじれない
キーボードの場合、自分は小指を『コ』の字に曲げて
コントロールキーを押すんですけど、それの反応が
悪いんですね。まぁ、まともな使い方じゃないといえば
ないんで、あんまり東プレを責めるのもかわいそうかな。

英語のテンキーつきのデカイのも持ってたんですけど、
アルファベットキーのどっかが戻らなくなっちゃって、
ろくすぽ使わずに捨てちゃいました。

多分、東プレのキーボードは二度と買わない。キー
タッチとか悪くないんですけどね。まぁ、相性だから。

で、自宅で使ってるOKIのコンパクト・キーボードの
日本語のヤツをぷらっとに注文。これのいいところは
キートップがデカイところと静かなところ。ああ、あと
コントロールキーとCapsLockを入れ替えられるのもいい。
ダメなところはヘタりやすいとこかな。あと、自分は
アキュポイントは嫌いなんで、あるだけ邪魔。

http://www.plathome.co.jp/detail.html?scd=11650296

OKIのとほぼおんなじのをぷらっとも出してるんですけど、
そっちはPS/2だからイヤ。今さらPS/2なんていらない。
それに、仕事場で使うのはペア用だしね。

--

そうそう、ペアのことで思い出したんですけど、
こないだ獲物で紹介しましたけど、複数人が同時に
マウスを操作できるソフト、ありましたよね。

ペアでやってて、たまにちょこっと調べたいこととか
あるじゃないですか。そんなとき、今は相手の作業が
一段落つくまで待ってなきゃいけない。そんなバカ
らしいことないでしょ。もう1台別のを用意するってのも
あるんですけど、それじゃあんまりですよね。

デュアル・モニタも珍しくなくなってきたし、もう
パーソナルってことにこだわるのも終わりにしてほしい。
スクリーンが大きくなったら、複数人が同時に1つの
デスクトップにアクセスできたほうが便利でしょ。
もとよりCPUパワーは余ってるわけですし。

前にもちょろっと書きましたけど、壁一面がスクリーン
になったら、今までとデスクトップの使い方だって
変わるでしょ。

--

思い出しついでにもう1つ。場所の都合っていうのが
もともとあるみたいですけど、小さい会議室なんか
だとホワイトボードをプロジェクトのスクリーン代わりに
することってありますよね。で、たまたま見てたら、
スクリーンに写したデスクトップにマーカーで印とか
つけてるんですよね。当たり前の発想なんですけど、
そういう使い方もあるのかと目からウロコが落ちました。

だから、そういうのもデスクトップをパーソナルじゃない
ものと見た発想なんですよね。

--

これ書きましたっけ? どうせなら増井さんには
任天堂行ってほしかったんですけど。

いや、増井さんが素晴らしいものをAppleから出すのと、
任天堂から出すのとじゃ、えらいインパクトが違うじゃ
ないですか (笑)。ぶっちゃけAppleからだと、『また
Appleのヤンチャかよ!』で終わっちゃうから (笑)。

--

これもついでに書いとこ。

自分、Googleは嫌いですけど、でも、MSなんかより
全然好きですよ。MSに支配されるくらいならGoogleに
支配されるほうがまだマシ (笑)。

今だにGoogleを虚業扱いする人も結構いるんですけど。
自分はそうは思ってませんし。彼らがいってる『ありと
あらゆる情報を整理し尽くす』とか、そういうのは
ウソクセーとかは思いますけど、別に悪いことじゃないし。
『Evilなことはやらない』とかいってるわりにはevilな
こと結構やってるのも腹が立ちますけど、まあ、そんな
もんかと。

自分が腹を立ててる、というか対抗心を燃やしているのは、
彼らの目標がイヤだからじゃなくって、その目標を達成
する手段がイヤだから。best and brightestだとか、
そういうのがイヤなわけ。

だから、もし自分がベンチャーはじめて、それがGoogleに
数億とか数十億とか数百億で買われるんなら、喜んで売り
ますよ (笑)。それもまた『Googleの鼻をあかす』形の1つ
だと思ってるんで。

--

ああ、『虚業』っていうのは、新山さんの批判とは
ちょっと違いますよ。いわゆるマスコミが使うような
『虚業』っていう意味。新山さんの批判はもっと深いし、
しごくまっとうな意見だと思います。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails