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

ホーム

2007年07月31日

http://youtube.com/watch?v=cOYOExbzv-8

これなんてブートキャンプ?

ほんっと、ミックは何見てもブッとんでるよな (笑)。

つか、チャーリーだけやん、マトモなの。
ビルもちょっとキョドってるし (笑)。

--

http://youtube.com/watch?v=je9O-VdrZ0E

有名なビデオだと思うけど、はじめて見た。
泣ける。

本家Permlink


2007年07月30日1

(追記:?bakaid=20080413)

もう一度おさらい。ソフトウェア開発というものを
『活動』という視点から見てみようという話でした:

* ソフトウェア開発

  * 計画を立てる

    * 要件を洗い出す

    * 見積もりを出す

  * プログラミング

    * コーディング

    * テスティング

というふうに、大きく2つ、小さく4つの活動に分けられると。
で、今回は、『計画を立てる』ということについてもう
ちょっと。

こういうことを書いてた時点で気になってたことが1つ
あって。それは最近自分が度々書いていた『どういう
手順で作るか』ということが見えてないことです。

計画を立てるっていうのは、要件を洗い出しました、
見積もりも出しました、で話は終わりじゃないんですね。
現実には見積もった作業を線状に並べないといけない
わけです。いわゆる『線引き』っていうヤツですね。
この線引きされたものが本当の『計画』になるわけです。
だから、細かくいえば:

  * 計画を立てる

    * 要件を洗い出す

    * 見積もりを出す

    * 線引きする

っていうことになります。まぁ、実際には、見積もりを
出す時点で、作業間の依存関係は見えてたりするもんで、
あんまり時間をかけることはないんですけど。

とはいえ、線引きが重要なのは間違いない話です。XPでは、
『ビジネス価値の高いものから手をつける』っていう
ルールがあるくらいですから。

ただ、話を単純にするために、線引きを見積もりに含め
ちゃおっかなーと。だから:

* ソフトウェア開発

  * 計画を立てる

    * 要件を洗い出す

    * 見積もりを出す

      * 線引きする

  * プログラミング

    * コーディング

    * テスティング

くらいにしておこうかと。あんまり細かくすると、
『だったら設計も別にしろ!』とかいわれちゃいます
からね。(繰り返しますけど、自分は『コーディングと
設計は不可分だ』と主張してるわけです。)

--

たまには図でも載せちゃおっかなー:



図ぅ描くの、ヘタなんすよ。すんません。

4つの活動の基本的なフィードとフィードバックの関係
です。実線の矢印がフィード、点線の矢印がフィード
バックです。

向かい合う活動 (要件とコーディング、見積もりと
テスティング) の間にもフィードとフィードバックは
あるんですけど、とりあえずわかりやすく描いてみました。

フィードと同じように、フィードバックも連鎖を起こす
可能性があります。

  テストが通らない → 実装できない → 見積もれない

というように、テスティングからコーディング、見積もり
算出、さらには要件策定までフィードバックが遡及する
こともあり得ます。

--

要件策定、コーディング、テスティングの3つの関係は、
仕様というもので結ばれています。わざわざ図にする
必要もないんですけど:



要件から仕様が作られて、それがコーディングと
テスティングの入力になるわけです。もちろん、その
入力にもフィードバックはかかります。面倒だから
両方向の矢印で描いちゃいますけど。

要件をテスト可能にしたものが仕様ということもできるん
じゃないでしょうかね。

--

それから、見積もり算出、コーディング、テスティングの
3つの関係は、スケジュールで結ばれています。これも
単純な図なんですけど:



よくあるでしょ? 『テストのスケジュール組んで
なかった!』なんてことが (笑)。

便宜上、『コーディングは終わりか?』って入れました
けど、ほんとは『要件を実現できたか?』で、つまりは
次の要件の実現に取りかかれるということです。

重量級なんかだと、要件の洗い出しもスケジュールに
組み入れる場合もありますけどね。agileだと、全体の
スケジュールから見ればごくわずかな期間なのがフツー
です。だから、まぁ、要件策定が見積もりに影響するか
どうかは、開発スタイルによりますね。

--

一連の自分の書いた記事を読んで、『単純化しすぎてる!』
って思う人もいると思うんですけど。でもね、個々の
活動の詳細なテクニックを云々するよりも、こういう
開発の全体像を把握しておくことのほうが大切だと思うん
ですよ、自分は。

前にも書きましたけど、4つの活動のうち、どれか1つ
でも手ぇ抜いたら、それに引きずられて全体の質が落ち
ちゃうんですよね。それは、1つの活動と他の活動とが
強く結びついてるからなんですね。

だから、平凡な集団でも、基本の活動をしっかりやってれば、
そこでソフトウェア開発っていうビジネスは回ってると。
もちろん、基本しっかりやってても、外部要因でおかしな
ことになるかもしんないけど。でも、そういう外からの
波も、基本ができてればある程度は耐えられると思うん
ですよね。

--

imgってpreの中に置けるの? 置けるっぽいんだけど。

本家Permlink


2007年07月30日

Ubuntuでドローツール使いたくなって。

自分はTgifが定番なんですけど (笑)、どうも日本語は
入れられないみたいで。いや、ゴニョゴニョやれば入れ
られるんでしょうけど、めんどうなんで。

で、Dia。最初、Diaでも日本語ダメなのかと思ったん
ですよ。でも、よく見たら``Input Method''っていう
メニューがあって。そこの``SCIM Input Method''って
のを選んだら入れられるようになりました。

ただ、Diaも、geditからテキストをDiaにペーストできない
んですよね。

本家Permlink


2007年07月28日1

DS 2台目。1台目は銀星囲碁専用で。

でも、1台目はDS Heavyなんだけど、Heavyのほうが
アクション・ゲームには向いてる気がする。右側のボタンの
遊びが少ない気がするし、STARTとSELECTも押しやすい
位置にある。Liteのボタンは小さすぎる気もする。

まぁ、もうHeavyは作ってないんだから、Liteに慣れる
しかないんだけど。

どうだろう。GBAはGBA SPっていう傑作を生み出したわけ
だけど、DSはLiteが最終形なのかなぁ。少なくともまだ
重いっていうのはあるし、大きさよりも重さのほうが
致命的だと思うし、GBAとの互換性もそろそろいらなく
なってるし、まだもうちょっと進化する余地はありそう。

--

というわけで、ガングラウンド。実はヴァルケンは、
自分がクリアしたことのある数少ないゲームの1つで、
この手のゲームは嫌いじゃない。ちなみに、ガンハザード
っていうのはやったことはない。フロント・ミッションは
最初のヤツやったことあるけど。(で、フロント・ミッションが
DSでリバイバルしてるんだけど、思い止まった。焼き直しは
楽しめないというのがシレンDSでわかったから。)

でも、まさかヴァルケンがWikipediaに載ってるとはなぁ。

http://ja.wikipedia.org/wiki/%E3%83%B4%E3%82%A1%E3%83%AB%E3%82%B1%E3%83%B3

ガングラウンドは、どうだろう。まだ遊びはじめたばかり
だから、評価を出しにくいんだけど。でも、値段から
いったら悪くないとはいえるかも。

ただ、ゲームとしてのツメは甘いところがある。だって、
開始地点から動かない、マチが一番効率いいっぽいから。
このマチ戦法だと、少なくとも裏から攻撃されることは
ない。

本家Permlink


2007年07月28日

http://www.aoky.net/articles/jeff_atwood/escaping_from_gilligans_island.htm

だから、何を上流工程と捉えるかにもよるんですよね。

でも、一般的に上流工程っていったら、実装より前段階の、
分析、設計のことだったりするわけじゃないですか。

そうじゃないだろと。

例の4つの基本活動からすると、上流工程っていうのは、
計画を立てること、つまり、要件策定と見積もりの算出な
わけですよ。

だから、自分にいわせれば、『不十分な計画』というのと
『上流工程をはしょる』っていうのはおんなしなんですよ。

だってそうでしょ? 見積もりを算出するのに、何をどう
実現すりゃいいかもわからないままやる? そんなのは
『当たるも八卦』じゃないですか。

だからといって、見積もりにたっぷりと時間をかけていい
わけじゃないんです。やっぱり実装しはじめてみないと
わかんないことが多すぎるから。だから、計画を立てて、
実行してみて、それでまた現実に合わせて計画を修正する、
つまり『計画を修正する』っていう行為が必要になる。

計画を立てて、それを達成するためにガンバるのはいい
んですよ。でも、みんながみんなそれをやっちゃぁ、
ビジネスじゃないわけでしょ。ビジネスっていうのは、
リスク管理しなきゃいけないし、達成できなかったときの
ことを考えとかなきゃいけない。あるいは、現実として
どこまで達成できて、どこまでならビジネスとして価値を
生むかっていうことを考えとかなきゃいけない。

いっときますけど、最近書いてるこの手の話は、別に
agileだからっていう話じゃないんですよ。見積もりに
時間をかけないっていうのはagileっぽいですけど、だから
といって計画に修正が不要なわけじゃないですよね。重量級
だって計画を見直さなきゃいけないときはあるでしょう。
だから、4つの基本活動はagileだけじゃなく、重量級でも
現れるし、それができてなけりゃ、agileであっても失敗
するっていうこと (まぁ、そんなのはもともとナンチャッテ	
agileだったっていうことなんですけど)。

本家Permlink


2007年07月26日

http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

を読み返したり。

こないだ書いたのはちょっと紛らわしいから:

  計画を立てる

    要件を洗い出す

    見積もりを出す

  プログラミング

    コーディング

    テストする

としましょう。

そういえば、不思議なことに、開発プロセスの話でプロ
グラミングっていう言葉が出てくることは少ないんです
よね。残念なことです。

一般にはプログラミングとテスティングは別物だとされて
るんだけど。最近はユニット・テストも広まってきたし、
そもそもプログラムを書いて終わりを確認しないなんて
ことはないわけで、プログラミングにテスティングを含め
ちゃっても問題ないでしょう。

だから、大雑把にいえば、ソフトウェア開発というのは、
『計画を立てて、プログラミングする』っていうことです。
で、もうちょっと詳しくいえば、『要件を洗い出して、
見積もりを出して、コーディングして、テストする』って
いうことです。

ただし、基本的には、要件策定、見積もり算出、プロ
グラミング、コーディングっていう順番で進むんんです
けど、その順番が変わることもあって、それはそんなに
珍しい話じゃなくって、それが悪いわけでもないという
こと。

たとえば、テストするときに仕様の抜けが見つかったり。
そうしたら要件から見直さないといけなくなる。そもそも
要件を洗い出すときも、テストのことも考えておいたほうが
いいし。そうでないと要件を実現できたかどうか決定
づけるものがないから。

そういうふうに、1つの活動から他の3つの活動に常に
フィードやフィードバックがかかる。いってみれば、
そっちのほうが現実というか、正常というか、健康な
状態。どっかでフィードやフィードバックが止まっちゃう
ほうが不健康。

これがソフトウェア開発を『活動』っていう面から見た
基本なわけ。全体像といってもいい。

こういう基本をほっぽっといて、やれツールがどうたらとか、
そういう話が多すぎるんですよ。くだらなさすぎる。

それと、agileっていうのは、お気楽方法論じゃないからね。
agileっていうのは現実に対応するためのものであって、
そのためにはやっぱり考えないといけないんだよ。

--

いや、だから、Daveがいう『ツールを愛せ』っていうのは
正しいんだけど。それは彼が基本を知ってるからであってね。
その前に『ソフトウェア開発を愛せ』っていうのがあるわけ
でしょ。でなきゃソフトウェア開発で考えたり悩んだり
できないでしょ。

本家Permlink


2007年07月25日


本家Permlink


2007年07月23日

へー、Symbolって大小比較できないのか。でも、ソート
できないって不便じゃないの? ソートできなきゃ二分
探索もできないってことになるでしょ。いや、別に自分は
線形探索でもいいし、ハッシュでもいいんだけど。

--

WebプログラミングにC言語はいらない、か。

でも、Webを支えてるツールはほとんどがCで書かれてる
しな。

確かに、Cを学ぶのはどのタイミングがベストかっていう
問題はあるけど。

一生PHP使い続けるわけでもないだろうし。もし、他の
言語知らないんなら、Cは真っ先に学ぶべきなんじゃないの?

C++に関しては、まだ学習方法が確立されてない面がある。
Early C++じゃ古いし、かといってLate C++じゃ手も足も
出なくなる。一概に「CよりもC++からはじめるほうがいい」
とはいえないと思う。

それと、職業プログラマになろうっていうのに、それ
まで1行もコード書いたことのないヤツなんて、フツーは
ダメとしたもんじゃないの? たとえ我流でも、自力で
コード書いたことのあるヤツのほうがメがあると思う
けどなぁ。

--

ちなみに、何度か書いてるけど「Accelerated C++」は
ダメ。何がダメかというと、開発スタイルがダメ。ああ
いう実践的でないスタイルはダメ。

--

ああ、書き忘れてました。「Excelの達人」育てるくらい
なら、フツーのプログラマ育てりゃいいじゃんね。つか、
いつまでも片手間でITやらすなと。

本家Permlink


2007年07月22日

勝つにしろ負けるにしろ、成功するにしろ失敗するにしろ、
次への課題を見つけないといけない。

課題を見つけるには失敗したほうが見つけやすいという
ことはある。だから、失敗は貴重だという。

逆に、成功したとはいえ、やはり小さな失敗、あるいは
失敗への予兆といったものはあるはずで、それを見つけ
ないといけない。

課題とは、失敗の原因を明らかにし、それに対処する
ということ。原因を明らかにしないのは論外だが、それ
への対処を怠るのも同罪。

本家Permlink


2007年07月21日

UbuntuでEmacs使ってたらミョーな現象に。

とあるCで書かれたプログラムをコンパイルしようと
するとエラーになる。でも、何か変えたかというと全然
そんなことはない。文字を加えて、その文字をまた消した
だけ。たったそれだけでコンパイル・エラーになる。

どうやら文字コードがからんでいそう。そのソース・
ファイルは (Emacsを信じれば) JISで書かれている。
もちろん、EmacsでソースをいじってもJISのまま。だが
コンパイル・エラーは起こる。

エラー・メッセージを読むと``\033''がどうたらと
書かれている。で、それが示す行を実際に見てみると、
何の問題もなさそう。あるとすれば``¥''ぐらいなもの。
で、ためしに、``¥''の横にキーボードから``\''を
入れてみる。すると、驚いたことに、``¥''ではなく、
``\''が入ってしまった。一体、自分はどんなエン
コーディングで作業しているのかサッパリわからなく
なった。

--

こないだ、ソフトウェア開発は:

  計画を立てること

    要件を洗い出すこと

    見積もりを出すこと

  コーディング

    設計すること

    テストすること

という、大きく分けて2つ、小さく分けて4つの活動が
基本になってることを書いた。これらの活動は、どんな
規模でも、どんなドメインでも共通してやんなきゃいけ
ない作業だということ。だから基本だということ。

こういうふうに、全体のイメージをつかんでおくことが
大切。ソフトウェア開発がうまく行くためには、この
4つの基本すべてを底上げしないとダメだから。基本と
いうものは1つでも欠ければ全体がおかしくなる。

で、この4つの基本は、日々繰り返されるものだという
こと。あるプログラマの1日の中にも、計画決定と
コーディングは必ずといっていいほど現れる。今日やる
べきことを洗い出し、どこまで先に進めそうか見積もる。
そして、コードを書いてテストを通す。このサイクルは、
規模によらず、開発スタイルによらず、すべてのプロ
グラマがやんなきゃいけないサイクル。

それから、1つ1つの活動をきっちり分けて考えるのはよく
ない。たとえば見積もりを出すためには、ある程度設計
についても踏み込まないといけないし、それでも数字が
出せないんなら、要件をさらに小さくしないといけない。
フィードとフィードバックを繰り返すことで、それぞれの
活動の質が上がる。

当たり前のことを書いてるだけだけど、それが基本という
ものだし、でも、こういうことが案外書かれてないことが
この業界の歪みを表してるんだと思う。

本家Permlink


2007年07月19日1

  (?A..?Z).include?

と書いたつもりなのに実際は

  [?A..?Z].include?

と書いてしまっていて悩んだ。

でも、ちょっと考えたら、これおかしくない? [?A..?Z]
って書いたら、?Aから?Zまでの要素の配列が出来ても
いいように思うけど。まぁ、誰も使わないか。

あと、こういうのは型で救えない典型例かもしれない。
ああ、でも、テンプレート使う時点で気づくか。

  Array<Range>

みたいには書かないだろうし。

--

http://www.ddj.com/201001928

  the AXD301 has 1.7 million lines of Erlang, making it the largest
  functional program ever written.

動的言語は大規模に向かないなんて誰がいった?

本家Permlink


2007年07月19日

うぉ、内藤勝ったのか!

本家Permlink


2007年07月18日1

じゃあ、基本って何よ?って話になるわけだけど。

この『基本』というものについては、このページでも
何度か考えたことがあります。プログラミングの基本と
いった場合、まぁ、大体合意が得られてる気がします。

まず、プログラミング言語の知識。これはどこまで深く
知るべきかという問題はありますけど。で、その答えは、
基本的なデータ構造とアルゴリズムを理解できる程度と
いうことで、これが2つ目の基本。で、とりあえず最後は
OSの知識。これも、まぁ、基本的なAPIを押さえる程度
でしょうね。

どうも世間的には、この程度の基本を押さえておけば、
結構有望な新人と見られるようです。だって、『FizzBuzzが
解けない!』なんて嘆いているくらいなんですから。

で、ここからプログラミングからソフトウェア開発という
集団作業になるわけですけど。これは大きく分けて2つの
作業がある。計画を立てることと、コーディング。

計画を立てることをさらに分ければ、要件の洗い出しと
見積もり (さらにスケジューリング) ということになる。

コーディングをさらに分ければ、設計することとテスト
することということになる。

見積もりする際にはある程度目途が立ってないといけない、
言い換えると、ある程度分析できてないといけないわけ
ですから、見積もりと分析を分ける必要はありません。

それと、何度も書いてるとおり、コードを書くことは
すなわち設計することです。実装方法の検討は見積もりの
段階でもやりますし、コードを書くときにもやります。

この、大きく分けて2つ、細かく分けて4つの活動が、
ソフトウェア開発の『基本』なわけです。これらは、
ソフトウェア開発においてどれ1つ欠けてもいけない
ものです。だから基本的な活動と呼べるわけです。

それぞれの活動の中にも『基本』と呼べるものはあるん
でしょうけど、自分もよくわかってないですし。それに、
そういうのを箇条書きにしても、あんまり意味ない気が
するんですよね。幸いなことに、それぞれの活動に
ついてはそれぞれの専門書が出てますから、そういうのを
読んで、自分に合ったのを選べばいいんじゃないかと
しかいえません。

--

結局、品質なんていうのは、それを作る人間の心が反映
されるもんじゃないの? だから、品質からは属人性を
切り離せないんじゃないの? だから、品質を上げるには
人を育てないといけないし、それしか道はないんじゃ
ないの?

デザイン・パターンが設計品質を上げる切り札だなんて
トンデモもいいとこ。

本家Permlink


2007年07月18日

これが基本なのかねぇ。

たとえば:

http://itpro.nikkeibp.co.jp/article/lecture/20070702/276410/?ST=lecture&P=4

  ユーザー・インタフェース設計と並行して,新システムのデータベース設計
  を実施する。先に述べたように,IBM-DOAではこの段階でシステムを流れるす
  べてのデータを洗い出しているため,あいまいさがない正確なデータベース
  を設計できる。

そんなことが可能なのか? 可能にするためにその「洗い
出し」を何ヶ月もやるのか? それが「基本」と呼べる
ほど一般的な作業なのか?

あるいは:

http://itpro.nikkeibp.co.jp/article/lecture/20070710/277102/?ST=lecture

  このロバストネス分析の結果を基に,具体的なモデリング作業に入っていく。
  いわばロバストネス分析は,モデル(システム)とユースケース(業務)を
  つなぐための作業と言える。

  これにより「分析と設計」,そして「ユースケースとオブジェクト」の間の
  大きな溝を飛び越えることができる。その意味で,ロバストネス分析は分析・
  設計モデリングの肝である。

だから、その「ロバストネス分析」が「基本」と呼ばれる
ほど一般的なものなのか?

基本というからには、ほとんどの開発で繰り返し有効な
ものでなければならない。たとえ、それが数ヶ月のプロ
ジェクトであってもだ。あるいは、Webだろうが基幹系
だろうが何度も繰り返される作業が「基本」と呼べる
わけだ。

だから、ここでいわれている「基本」っていうのは、
特定の手法論における「基本」にしか過ぎない。しかも、
その手法論が適用できる範囲が狭いと来てる。これらの
手法論は大規模が前提だったり、いわゆる基幹系と呼ばれる、
比較的「枯れた」ドメインを対象としている。そういう
「ニッチ」な手法論はもういらないと何べんも書いてる。

本家Permlink


2007年07月17日1

プログラミングを楽しむ人が増えるのは歓迎だし。

職業プログラマが増えるのも悪いことじゃないし。

だから、今の職業プログラマの質は別の問題として解決
しなきゃいけないし。

まぁ、自分は、それほど低いとは思わないですけど。

いや、仕事で他人のコード見て腹立てることも多いん
ですけど、『そんなもの』だと思ってるし。

第一、自分が質を落とす側の人間だから、そんなエラソーな
こといえないし。

だから、プログラマの質は市場に解決させるというか。
努力したとこにいい人が集まればいいだけだと思うんです
よね。業界全体がどうのといっても、現実、いい人は
来ないわけで。

ただ、どうなんすかね。業界がほしがってる人間を教
育界が送り出してるかっていうと。

実際にほしいのは管理者とか、チーム開発でやってける
人なんじゃないですかね。

管理者については、前から書いてるとおり、企業のほうも
専門職として人を育てないといけないし、そういう認識が
ないから教育界も管理者を目標とする人を育てようと
しないんじゃないですかね。

チーム開発でやってける人っていうのは、未踏とか関係
なさそうな、いってみれば平凡な人なわけで。まぁ、表現が
悪いですけど『兵隊』ですよね。そういう、即実戦に
放りこまれても役に立つような実務的な知識を教えてる
のかっていう問題はありますよね。教えてるところは
教えてるのかもしれませんけど。

本家Permlink


2007年07月17日

UnixライクなAPIを用意していることも、RubyのCoC
(みたいなもの) の1つじゃないの?

本家Permlink


2007年07月16日

前に似たようなこと書いた覚えあんだけど。これも
いわれたんだけどさ、やっぱその日のうちにいじった
コードをその日のうちにコミットできないっていうのは
間違ってるわけよ。だって、それってbaby stepsじゃ
ないわけじゃん?

だから、時間軸を持って設計とコーディングをしなきゃ
いけないわけ。どういう筋道をたどったら日々コミット
できるか考えなきゃいけない。

よくいわれる『部品化』ってヤツ? まぁ、それはそれで
大事なことなんだけど。でも、部品化っていうのは、
作る手順を意味するわけじゃないからさ。部品化って
いうのは結果に過ぎない。部品化を手順として捉え
ちゃうと、『結合は最後にやる』みたいな間違った考えに
陥っちゃう。

作ってるのはソフトウェアなんだから。柔らかいもの
なんだから。結合しながら部品化することだってできるし、
そうやんなきゃいけない。それがcontinuous integration
なわけでしょう。

だから、設計っていうのは、最終的な姿、それはクラス図
とかで表現できるようなものかもしんないけど、そういう
のを思い描きつつも、それをどういう手順で実現すれば
リスクが少ないのかっていうことまでも考えないといけ
ないわけ。結合するものがデカくなればなるほどリスクも
デカくなるんだからさ。

大体、自分なんか、ローカルにコード残しとくなんて、
不安すぎてできないっつの。PCなんてヤワなもんだし、
それで2、3日分の作業フッ飛んだら発狂しちまうよ。

--

理念とか哲学っていうのは確立したほうがいいわけ。そんな
もんがコロコロ変わるようじゃエライことになっちゃう。

でも、その理念とか哲学ってもんを実現する手段とかは時代に
合わせて変わってかなきゃいけないわけ。当たり前の話。

本家Permlink


2007年07月15日2

というように、今だにLinuxでは愉快な体験ができるわけ
ですけど。でも、一頃に比べると、Linuxユーザの数は
減ってるかもしれません。少なくとも増えてる感じは
しませんね。まぁ、ブームが去ったといえばそれまですし、
Macの影響もあるでしょうし。

でも、自分はLinux止めるつもりはありません。やっぱり
UNIX系のOSはプログラマに優しいんですよ。それが一番。

UNIX系のOSは他にもありますけど、自分はMacは買わないと
決めたんで、他の選択肢はほとんどありません。BSD系も
ありますけど、これ以上愉快な体験はしたくないですし。
SolarisはBSD系以上に魅力を感じません。

いや、でもねぇ。ちょっと前はRubyとLinuxってペア
みたいなもんだと思ってたんですけどねぇ。Windowsで
Rubyやってて楽しいか?って思うんですけどねぇ (笑)。

本家Permlink


2007年07月15日1

http://dannf.org/bloggf/tech/proliant-etch.html

タイミング良すぎてワロス。

でも、ProLiantってサーバなんですよねぇ。

って、今調べたら激安じゃん、これ!

http://www.compaq.co.jp/products/servers/proliant/ml110g4/index.html

桁見間違えたかと思った。

まぁ、でも、安いだけが取り柄な感じ。石古くて熱くて
うるさそうだし。DSUBみたいだし。

--

あ、それから、HPのPCですけど、testingだとイケそう。
今インストールの真っ最中。

でも、testingなんてハンパなもん使うんだったらsidに
しちゃいますよ。で、結局、sidから離れられないサダメ
っていう (笑)。

--

あー、やっぱダメだ。Xの解像度が全然出ねぇ。最大で
800x600とかいわれる。

もういいや、Ubuntuで。

つか、改めて、メーカー品はDebianに冷たいってのが
よくわかった。そんなに高いPCじゃなかったから、
結構枯れてるかもと思ったけど。まぁ、よく調べな
かったオレが悪い。

--

ぐ。Ubuntuでも音が出ないのか。むぅ。

--

ん〜、自分、十字キー好きなんですよ。ぶっちゃけ、
ペンでゲームする気になれない。だから、こないだ
買ったゼルダも、最初のほうでほっぽり出しちゃった。

DSのゲームも、ムリにペン使おうとしすぎっていうか。
ゼルダは多分世間的に評価高いんだろうけど、ペンって
面倒なときがあるでしょう。

本家Permlink


2007年07月15日

注文したHPのPCが届いたんだけどさー。今どき、Debian
入れらんねーPCが売ってるとは思わなかったよ。etchが
古いのかねー。

ataがどうたらでエラーが出てるっぽい。インストーラは
起動するんだけど、CDドライブが認識できない。

どうやらUbuntuは入れられそうなんだけどさ。まだやって
ねーからほんとのとこはわかんねーけど。

HPのdc5750 SFってヤツ。イチオーBIOSとかも上げてみた
んだけどなー。

明日、testingのCD焼いてみっかなー。もうUbuntuでも
いいっちゃいいんだけど。まー、いちおずっとDebian
使ってきたわけだし。

しかし、メーカーさんも、いーかげんDebian入れたPC
売れっつの。Ubuntuでもいいっちゃいいけど、Debianで
都合が悪いことがあるとも思えねーし。

--

へー、Ubuntuってサーバ版があって、それはLAMPが一発で
インストールできるのか。面白いね。

--

『野球小僧 2007年8月号』にファイターズの高田GMへの
インタビューが載っています。その中から1つ:

  月に一度は、ファーム首脳陣との育成ミー
  ティングを実施し、毎日の練習終了後には、
  監督やコーチがファーム全選手に対するコメ
  ントをパソコンに入力し、それを高田が日々
  チェックしているという。

  「北海道にいてもどこにいても、随時、(ファ
  ームのある) 鎌ヶ谷の状況は、すべて把握し
  ていますから」

  高田GMは胸を張った。

まぁ、当たり前といえば当たり前の話かもしれません。
でも、こうやってITが活かされているという事実がある
わけです。じゃあ、そのシステムは誰が作るんだろう?
と考えるわけです。

野球のITといえばデータスタジアムという有名な会社も
ありますし:

http://www.datastadium.co.jp/

ミズノもコミュニティ・サイトを持ってたりします:

http://spocom.mizuno.co.jp/

でも、選手の管理は球団にとって重要なことですし、
これから先もずっとやっていかないといけないことです。
また、選手の管理や育成というものは、他の球団のもの
とは差別化されるべきノウハウです。そういう、いって
みれば重要なビジネス、を支えるシステムを外に任せて
いいものかどうか。

そう考えれば、球団が自前でプログラマを雇うっていう
のは『アリ』な結論ですよね。

でも、そのプログラマっていうのは、野球やプロスポーツ
というものをよく理解している人のほうがいい。そういう
『ドメインの知識』も高いレベルで求められるわけです。
また、ソフトウェア開発が専門の組織ではないですから、
プログラマ以外の人間とも上手に付き合える人でないと
勤まりません。こうした新しい要求に応えられるプロ
グラマが、これからのプログラマ像ということになるんで
しょうね。

本家Permlink


2007年07月13日1

この業界、「刷新バカ」も多いけど、それとおんなじ
くらい「確立バカ」も多い。

ここでいってる「確立」は、統計とは全然関係なくって、
曰く、「開発手法を確立する」ってヤツ。

開発手法なんてもんは変えてかなきゃいけないもんで、
「開発手法が確立した」って思った瞬間から時代遅れな
ものになっていく。

それに、開発手法っていうのは、それをやる組織の風土に
合ったものじゃなきゃ意味ないわけで。そういう意味じゃ、
異なる組織間を横断するような開発手法っていうのは確立
させようがない。

だから、開発手法っていうのは、緩い慣習程度のもので
しかないし、そうあるべき。

確立バカは、あらゆる組織が共有できる極意みたいな
もんを期待してるんだろうが、そんな銀の弾丸はどこにも
ない。

XPにしても、それを確立された手法論として見るのでは
なく、自分で開発を改善する手がかりとして見るべき。
それに、XPの心がそもそも「変化を抱擁せよ」なわけで、
それは「確立」とは程遠いところにある。

--

ああ、「緩い慣習」っていうと誤解があるか。つまり、
自分たちで積極的に変えられるくらいのルールという
意味。規律がまったくいらないわけじゃない。

本家Permlink


2007年07月13日

慣れない言葉でいうなら、S/N比を高めることも大切だけど、
サンプリング・レートを上げることも大切。さらにいえば、
どちらかといえばサンプリング・レートを上げることの
ほうが大切。なぜなら、S/N比を先に上げるのは『早すぎる
最適化』になる可能性があるから。

そのへんはWikiを見てもわかるはず。

人間っていうのは、案外ノイズには強くできてる気がする。
でもって、ノイズから音を拾うのにも長けてる気がする。
だから、S/N比のほうは人間任せでもある程度は大丈夫な
気がする。だから、サンプリング・レートを上げるほうに
力を入れるほうがいい気がする。

サンプリング・レートを上げるというのは、つまり、
ノイズと情報の両方を含めたデータの総量を増やすという
こと。そのためには『発信する気にさせる』、『発信し
やすくする』必要があって、そのためには心の面からと
それを支援する仕組みの面の両方から攻める必要がある。

本家Permlink


2007年07月12日

こんなことはオレじゃなくっても、他の誰かがさんざん
いってることなんだけど。

プログラマの仕事っていうのは、単にプログラムを書く
ことじゃないのね。問題を解決するためにプログラムを
書くことなのね。

だから、問題を解決しないプログラムを書くのは、プロ
グラマの仕事じゃない。だから、プログラマは、自分が
書いてるプログラムが本当に問題を解決できるか気に
しないといけない。

これがベースで、品質も、開発効率も、そのベースに
乗っかるものだから。

本家Permlink


2007年07月11日

こないだ会長に『オススメのラノベは何?』って聞いたら、
『ファミ通文庫の文学少女が (以下略)』みたいなこと
いわれて。

で、フと思い出してアマゾンで探したんだけど、その文学
少女も注文したんだけど、先に卓球少女のほうが届い
ちゃった。なぜ卓球少女を選んだかというのは会長なら
わかってくれると思うけど、これの第一作、『赤城山
卓球場に歌声は響く』はどうやらすでに廃刊らしく、
古本でしか注文できなかった。

で、2時間くらいでバーッと読んじゃったんだけど。
まぁ、自分も年を喰ったというか。作品も面白かったん
だけど、そういう感想 (笑)。

小説の類を読むのはすっごい久しぶりだった。そういえば、
朝日ソノラマが廃業とか。まだラノベなどという言葉が
なかったころ、キマイラとかDとか読み漁ってた時期も
あった。

本家Permlink


2007年07月10日

ああ、もちろん、割り込みの種類にもよるんですけど。
でも、割り込みが多くて効率が上がらないというような
状況なら、個人で解決できる状況ではないでしょう。

このあたりはよくある話で、たとえば隔離された場所に
作業場を確保するとか、午前中だけは電話を拒否する
とか、組織的な対応が必要になります。

ということからしても、キーボードから手を離しても
問題ないということがいえるわけです。それで問題が
出るようなら組織で対応しなきゃいけない話でしょう。

--

毎週のように〆切があるっていうのは、結構キツイもん
ですね。しかも、その〆切を決めたのは自分なんですから。

でも、これもまたマジックの1つなんでしょうね。人間、
やっぱりウソはつきたくないもんですから。自分で出した
見積もりだったら、やっぱり実現しようと気合も入ります。

でも、やっぱりキツイものはキツイ。でも、だからこそ
slackを大切にして、いつでもenergized workできる
ようにしなきゃいけない。

--

でも、8時間のうちの20%っていったら1時間半くらいなん
ですよね。それが多いか少ないか。そうやって数字を
出されると、自分は意外と少ないかなと思いますね。

いや、自分が1時間半も遊んでるとか、そういう話じゃ
なくってね (笑)。

自分は、この『管理された自由時間』って、いいこと
ばっかじゃない気がするんですよね。好きなことやる
ヤツは、どこ行っても好きなことやるだろうし、そん
ときはどうにか時間をやりくりするだろうし。

実際、おバカなプログラムとかは作れないでしょうし、
単純に『お勉強』のためにも使えないでしょうし。

--

はは、プログラマは廃業したほうがいい、か。ま、その
とおりなんだけど。

--

Visitorなら結城さんの本にわかりやすい説明とサンプルが
ありますね。あと、``A Little Java''は一冊のほとんどが
Visitorで占められていたような。

--

(defun my-c++-mode-hook ()
  (c-set-style "stroustrup")
  (setq c-basic-offset 4)
  (setq indent-tabs-mode nil)
  (c-set-offset 'arglist-close 0)
  (local-set-key [f9] 'switch-c++-buffer))
(add-hook 'c++-mode-hook 'my-c++-mode-hook)

(defun switch-c++-buffer (&optional buffername)
  (interactive)
  (if (not buffername)
      (setq buffername (buffer-name)))
  (let ((basename (file-name-sans-extension buffername))
	(extension (file-name-extension buffername)))
    (let ((filename (concat basename "." 
			    (c++-paired-extension basename extension))))
      (find-file filename))))

(defun c++-paired-extension (basename extension)
  (if (string= "cpp" extension)
      (find-cpp-header basename)
    (cond ((string= "h" extension) "cpp")
	  ((string= "hpp" extension) "cpp")
	  ((string= "hh" extension) "cc")
	  ((string= "cc" extension) "hh")
	  ((string= "hxx" extension) "cxx")
	  ((string= "cxx" extension) "hxx")
	  ((string= "H" extension) "C")
	  ((string= "C" extension) "H")
	  (t nil))))

本家Permlink


2007年07月09日

いや、確かに『ゆるめいつ』はいい。実際笑えるし、
ソッチ方面にもウケのいい絵柄だというのもわかる。

でも、やっぱり『おたやん』も捨てがたいんじゃなか
ろうか。

さらにいえば、前にも書いたが『奥様うでまくりっ!』
も是非ともコミック化していただきたい。

『奥様うでまくりっ!』もそうだが、長く連載してると
面白くなる作品もある。他にも『だってヤンママ』も
最近は面白い。前はヤンキーネタが多かったが、最近は
ネタの幅が広い。

『ちびとぼく』が終わってしまったのは本当に残念だった
が、いつか終わりは来るもの。また新しい作品、新しい
作家と出会えることを期待しましょう。

本家Permlink


2007年07月08日1

ヌクモリティなんていう言葉があったのか (笑)

本家Permlink


2007年07月08日

http://www.oliospec.com/miniitx/vmpc.html

ん〜、こないだ書いたのはこれだったんだけど。

確かに、完全ファンレスでDVIっていうとこまでは希望を満たしてくれてるん
だけど、メモリが512MBで、しかも固定だし、さらにHDDも組み込みだから、シ
リコン・ディスクに変えることもできなさそう。

とうわけで、残念だけど、今回は見送り。

パーツ・ショップなんかではEPIA売ってるとこも多いけど、誰か買ってる人い
るのかね? EPIAのPCなんて、ここぐらいしか売ってないしな。

--

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

本家のUCBLogoは現役なんだから (っていっても、2005年のが最新なんだけど)、
リンク張っとかないとダメでしょ。

本家Permlink


2007年07月06日

そうそう、concentration (あるいはzone、あるいはその意味でのflow) はXP
の価値ではないということもできます。一方で、communicationはXPの価値の1
つだと。

communicationという価値を基準に考えたら、キーボードから手を離して相手の
ほうを見るというのはごく当然のことです。「集中しているときは
communicationは疎かにしても構わない」というのは自分にはダブルスタンダー
ドに思えますし、そういうのは避けたいです。

--

http://www.garbagecollect.jp/~usa/d/200707a.html#id20070705_P1

仕様か! (笑)

単項マイナスより強いのがいたのか。

本家Permlink


2007年07月05日1


本家Permlink


2007年07月05日

irb(main):027:0> -3 ** 2
=> -9

$ c:/ruby/bin/irb.bat --version
irb 0.9.5(05/04/13)
$ c:/ruby/bin/ruby.exe --version
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]

バカだから信じちゃったよ (笑)

--

だいぶ前にも書きましたけど、自分は、話しかけられたらキーボードから手を
離して、相手のほうを向くようにしています。いついかなるときもっていうと
ウソになりますけど。

その代わり、話しかけるときも唐突に話しかけることがあります。自分はもと
もと独り言が多いので、話しかけられたほうは独り言なのか話しかけられたの
か区別できないようです (笑)。

まぁ、唐突に話しかけるのはマネしないほうがいいでしょうけど。でも、手を
離すっていうのも、自分の場合には、それほど負担にはなりません。そんなに
頭良くないですから。

これも何回も書いてますけど、自分がいう「集中」というのはモニタに集中す
ることではなく、「場」に集中することです。相手が話しかける前にこちらか
ら話しかけるというのが理想です。作業場全体に神経が行き届くような状態を
「場に集中する」というわけです。

自分はまだ独身なんですけど、もし仮に息子や娘がいたとして、「ねぇねぇパ
パァ」と話しかけられたときに、「今パパはちょっと忙しいから」とはいいた
くありません。仕事と子育ては違うといわれるかもしれませんけど、自分は一
緒だと思います。

本家Permlink


2007年07月04日

ああいう人は、外食産業のようなものをイメージしてるのかもしれない。外食
産業といっても、レンジでチンして簡単に盛りつけるような感じ。

それならそれでいいんだけど、自分が聞きたいのは、「じゃあ、あなたはチェー
ン店のオーナーになりたいの?」ってこと。

チェーン店のオーナーって、あんまり儲かってるイメージが自分にはないんだ
けど。

あるいは、自分でフランチャイズをはじめるにしても、競争は激しいし、それ
に何より自分ではじめられるだけの技術力がいるし。

実際、ASPとそのカスタマイズが今のSIerに置き換わっていくっていうのは十
分考えられるし。で、それ以外の非定型的なものも、SIerに頼らず、内製され
る傾向が強まることも十分に考えられるし。

プログラミングがなくなるっていうんなら、それはそれでいいけど、じゃあ何
をやって食べてくの?

--

いやー、ベンチャーなのになんで中小企業をターゲットにするかサッパリわか
らん。大体、若いうちに「社会に貢献!」とかいってるヤツにロクなのはいな
い。

本家Permlink


2007年07月03日

祖母井秀隆。オシムを日本に連れてきた人といったら
わかってもらえるかな。その人の記事が昨日発売された
『東洋経済』に載っている。以前からこの人に興味は
あったけど、予想以上に面白い人物だった。

--

大規模にはコード量が多いという物理的な面と、開発フェーズから保守フェー
ズを含めて長期間にわたるっていう時間的な面がありますよね。でも、自分は、
物理的な面よりも、時間的な面のほうが恐いです。

真っサラな状態から自分でコードを書きはじめるっていうのは、すっごく気楽
なんですね。いくら大規模だっていっても、自分で書くのは限られた範囲なわ
けで、それがゼロから書きはじめていいっていうなら、なおさら規模の影響は
小さくなります。でも、大規模で、かつ長生きしているシステムだと、誰か他
の人が書いたコードをいじらないといけなくなる。これは結構クるんです。特
に自分みたいな人間には。

まず、他人が書いたコードを読むっていうのが大変。それに、時間が経ってい
ると、開発の文化も違ってたりします。Early C++とLate C++とではプログラ
ミングのスタイルが結構違うわけで、そういうこともあるし、当時と今とで計
算資源に違いもあって、そこから文化に違いが出ることもあります。自分は最
適化は嫌いですけど、最適化を美徳とする風潮は今よりももっと強かったり。

--

で、最近度々話題に載せるデバッガなんですけど。やっぱり他人が書いたコー
ドを理解するのに有効なツールなわけです。そういう意味では、時間的な大規
模開発には欠かせないツールといえます。

#ifdefまみれのコード、コメントアウトだらけのコード、インデントのおかし
いコード。もちろん当時はユニット・テストなんていうのも知られてない。そ
んなコードを目だけで読めなんていうほうがムリなわけで。

--

で、また大規模の話に戻るんですけど。この時間的な大規模に対処するってい
うのは、言語、特に言語仕様だけじゃ不可能なんですね。いや、ある程度は物
理的な面をサポートすることで時間的な面にも好影響を与えることはできるで
しょうけど。

だって、開発の文化なんて、変えるなっていうほうがムリですもんね。大体、
言語仕様だって変わっていくもんですし。

で、結局、その時間的な大規模っていうものへの対策っていうのはないんです
よね。いや、ないっていうか、あるんですけど、それは結局『基本に忠実に』
みたいな話になっちゃうっていうか。

--

ああ、『開発フェーズから保守フェーズまで』っていうのは、世間一般でいわ
れる通念だからここで使っただけで。『進化するシステム』では常に開発フェー
ズと保守フェーズが同居してます。それがまた自分を悩ませるとこなんですけ
ど (笑)。サラで書きたいっていう欲望と、進化するシステムを是とする理性
との間で、今日もモンモンと過ごすわけです (笑)。

本家Permlink


2007年07月02日

まぁ、そんなエラソーなこと、オレがいえるもんでもないか。

--

書かなくてもいい型宣言書くんなら、型推論なんていらない
と思うのは自分だけ? (笑)

でも、時代はインタプリタに向かってると思うんだけどなぁ。
まぁ、これも自分だけかもしんないけど。(笑)

ああ、インタプリタっていうのは『明示的な』コンパイルの
過程がない処理系のことね。JITとかはアリ。

--

得がたい体験をしたと思うし、ああいう人材を業界が
渇望してるのも事実だし、うらやましくも思うんだけど。

でも、どっか引っかかるんですよね。ああいうのは開発で
あって、ハックではないわけでしょう。そこが引っかかる。

まぁ、ハックで満足に飯が喰えるかっていったら、喰え
ないんですけどね、よっぽどのことでない限り。ただ、
自分は、その『よっぽど』が見たいっていう。(笑)

まぁ、これも世迷い言の類だな。

--

ああ、『よまよいごと』じゃなくって『よまいごと』だった
のか。どうりで変換できないわけだ。

本家Permlink


2007年07月01日

ラジオボタンが2つあって、両方ともOFFのときは両方
とも利用可能、でもどっちか1つがONになったら、もう
一方のほうは利用不可能にする。そういうGUIを作るとき、
こうしたルールはGUIコンポーネントには埋め込まない。
こうした当たり前の考え方をSwingは支援してくれる:

include Java
import javax.swing.JFrame
import java.awt.event.ItemEvent

class Control
  include java.awt.event.ItemListener

  def initialize
    @leftButton = nil
    @rightButton = nil
  end
  attr_writer :leftButton, :rightButton

  def itemStateChanged(event)
    src = event.getItemSelectable
    if src == @leftButton
      @rightButton.setEnabled(event.getStateChange() != ItemEvent::SELECTED)
    elsif src == @rightButton
      @leftButton.setEnabled(event.getStateChange() != ItemEvent::SELECTED)
    end
  end
end

class Builder
  def build
    frame = JFrame.new("Exclusive Panel")
    buildPanel(frame)
    frame.setDefaultCloseOperation(JFrame::EXIT_ON_CLOSE)
    frame.pack
    frame.visible = true
  end

  def buildPanel(frame)
    mainPanel = javax.swing.JPanel.new
    control = Control.new
    buildLeftButton(mainPanel, control)
    buildRightButton(mainPanel, control)
    frame.getContentPane.add(mainPanel)
  end

  def buildLeftButton(mainPanel, control)
    button = buildButton(control, "Left")
    mainPanel.add(button)
    control.leftButton = button
  end

  def buildRightButton(mainPanel, control)
    button = buildButton(control, "Right")
    mainPanel.add(button)
    control.rightButton = button
  end

  def buildButton(control, title)
    button = javax.swing.JCheckBox.new(title)
    button.addItemListener(control)
    return button
  end
end

if $0 == __FILE__
  Builder.new.build
end

ちなみに:

$ c:/jruby-1.0/bin/jruby.bat --version
ruby 1.8.5 (2007-06-07 rev 3841) [x86-jruby1.0]
$ java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

確かに、こういう『ルールをGUIコンポーネントに埋め
込まない』っていうのをSwingは支援してるわけだけど、
でも、これっていうのは本来GUIライブラリとは独立
した考え方なのね。

試しにJPanelのサブクラスを作るやり方を試そうとした
んだけど、そっちはJRubyじゃサポートされてないみたい
なんで、Javaで書くけども:

import javax.swing.*;
import java.awt.event.*;

class ExclusivePanel extends JPanel implements ItemListener {
    private JCheckBox leftButton;
    private JCheckBox rightButton;

    ExclusivePanel() {
        leftButton = new JCheckBox("Left");
        leftButton.addItemListener(this);
        add(leftButton);

        rightButton = new JCheckBox("Right");
        rightButton.addItemListener(this);
        add(rightButton);
    }

    public void itemStateChanged(ItemEvent event) {
        Object src = event.getItemSelectable();
        if (src == leftButton) {
            if (event.getStateChange() == ItemEvent.SELECTED)
                rightButton.setEnabled(false);
            else
                rightButton.setEnabled(true);
        } else if (src == rightButton) {
            if (event.getStateChange() == ItemEvent.SELECTED)
                leftButton.setEnabled(false);
            else
                leftButton.setEnabled(true);
        }
    }
}

public class App {
    public static void main(String[] args) {
        javax.swing.SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                    createAndShowGUI();
                }
            });
    }

    static void createAndShowGUI() {
        JFrame frame = new JFrame("Exclusive Panel");
        frame.add(new ExclusivePanel());
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.pack();
        frame.setVisible(true);
    }
}

こっちのほうがコード量が減るかもしんないけど、
そんなに差があるわけじゃないし。これは『将来の拡張性
が・・・』みたいなことをいってるんじゃないのね。
これが基本だからいってるわけであって。その基本の
裏付けをいえば、『継承はできるだけしない、動的に
コンポーネントを構成するほうが柔軟性が高い』って
ことになるし、それは確かに将来の拡張性にも影響する
んだけども。でも、こんなチッポケなアプリで拡張性も
クソもないわけでね。でも、やっぱり基本から考えを
はじめるっていうのが大切なわけでしょ。小さいからこそ
基本を大切にしなきゃいけないし。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails