2006年10月アーカイブ

オープンソースカンファレンス2006 Tokyo/Fall

2006年10月30日 22:57 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

オープンソースカンファレンス２００６　Tokyo/Fall行ってきました〜。

いやね、すっごい面白かった。
沢山興味深いものがあったんですけど、何個かあげてみます。

１つ目。
・日本語Web開発環境「葵」
なんだか「ひまわり」と同じニオイがするな〜とか思っていたら、実はこれ「ひまわり」の進化系でした。
「ひまわり」　ー＞　「なでしこ」　ー＞　「葵」なんだそうな。
「ひまわり」って日本語プログラミング言語で、昔ホントに動くのかよ〜？とか思いつつやってみたら、結構普通に動くんですよね。「おお、すげぇ」みたいな　　笑

「葵」は言語というより統合開発環境で、なにげに良くできている感じでした。

専用エディタで、ドラッグ＆ドロップでプログラムしていって、ボタン一つで簡易Webサーバ起動！
凄いでしょ？文字化けせずに動いていたし。DBはSQLiteを採用しているようで、ちょこっとしたWebアプリだったら結構つかえるかも。。。って感じです。
今度なんか作ってみる事にします。

２つ目
実は一番気になっていたのが「Plone」っていうCMSです。
最近はてぶなんかで良く目にしていて、Xoopsと何が違うのかな？って気はなっていたんですけど、

開発言語はPython(XoopsはPHP)
直接画面をWeb上から編集できるダイナミックエディタを搭載
ユーザー毎にロールを設定できて、承認システムを構成できる。
更新履歴をバージョン管理していて、ロールバックできる。
CSSによるデザインも思うがまま。（Xoopsはちょっとクセがあるよね？）
Xoopsよりは野暮ったくない。

って感じでしょうか。最近Pythonが気になっているので、それもポイント高いです。

「Plone」は、「Zope」ってものの上で動くらしいのですが、
この「Zope」は何かというと、Web環境ですね。フルスタックの。

オープンソース＆フリーのWebアプリケーション・サーバなんて説明もされていますが、
DBもついているし、Web環境と言っても過言ではないです。
基本的に管理が全てWebブラウザ上で出来てしまうので、ftpすら要らないらしい。

Pythonが動く環境であれば、WinでもLinuxでもmacでも動くらしい。
これもかなりよさげ。

この「Zope」と「Plone」は今回一番興味を引かれたので、
今度実際macに導入してみようかと考えています。

Web開発環境「葵」
http://aoi-project.com/

Zope公式サイト
http://www.zope.org/

Plone日本公式サイト
http://plone.jp/

文系のための「WEB2.0」入門

2006年10月25日 22:49 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

私が勤める会社で行われている読書会のお題としての二冊目。

個人的には「Web進化論」を推したんですが、
「難しい」との事で、こちらの本になりました。

正直言うとこっちも十分難しいです。
と言うより、全体的にテーマを広く取りすぎたかな？って気がします。

Web2.0（ウェブツーポイントオーね）の概念については、
ちゃんと書いてあると思います。Tim O'ReillyのWhat is Web 2.0にもふれているし。

初めの方のサマリーよんで、「おいおい！」って思ったけど、その後でちゃんと解説してあった。
誰かが、読書会の時にサマリーの方を纏めて来たら、突っ込んでやろう。

それはさておき、
この本が扱っている内容は非常に広いのに驚きました。
セマンティック・ウェッブや、マイクロ・フォーマットまで書いてあります。流石に言葉たらずというか、誤解をまねく書き方もされていますが。

「Web2.0が世界を変える」なんてセンテンスがあって、ちょっと驚きました。
見事に主体と客体を取り違えている。
おそらく筆者は理解した上で言っているのだろうけど、コレを読んだ人の90％は勘違いするのではないだろうか？

別にWeb2．0という仕様、あるいはモデルが出来たから、世界が変わっているわけではないです。

むしろ、

チープ革命
インフラの整備
ロングテールとパレートの法則の崩壊
サーチエンジンの進化によるサーチエコノミー →　アテンションエコノミー
バーチャルな経済圏の誕生
オープンソースムーブメント
データ自体の重要性への再認識
Wisdom of crowds
folksonomy
RSS
etc...

イノベーションによってもたらされた既存秩序の崩壊と、あたらなルールへのパラダイムシフト。

そういった変化の状況をひっくるめて、一つの象徴的な言葉として誕生したのが、「Web2.0」なのです。

「Web2.0」は公式なバージョンでもなければ、技術ですらない。
（勿論技術も含まれますけど、枝葉でしかない）

「Web2.0的」という言葉が生まれたのもそのせいですね。決まった仕様なんてないですから。「Web2.0準拠！」とか言ってる人は（ネタ以外では）流石に見たことありません。

その辺りとメディアが取り違えた事、何でも2.0を付け始めた辺りから、世の中のイノベーターやアーリーアダプターはウンザリしてしまったのですね。

どちらかと言うと、Web2.0自体はWebをシンプルな方向に導いています。本来のWebの有るべき姿へと回帰していると言っていいでしょう。
セマンティックWebなどは、ティム・バーナーズ・リーが本来構想していたWWWの事ですからね。（言葉自体ができたのは1998年ですが）

Ajaxにしても、いかがわしかったDHTML+苦労させられたJavascript+イマイチはやらなかったXMLHttpの再利用ですから。
結局、１st decadeはイノベーションの時代だったわけですが、そこで培われた技術やメソトロジーといったモノを2nd decadeになってようやく正しく理解し、正しく使えるようになった。そして、Webの本来の有るべき姿とそこからもたらされるものの巨大さに気がついた。それが「Web2.0」なのではないでしょうか？？

その辺りの思想的な所をもう少し書いて欲しかったかなぁ。
全体としてはよく纏まっていたとは思います。

『文系のための「Web2.0」入門』
小川浩　著
青春出版社￥ 788 （税込）

ソフトウェア開発で伸びる人、伸びない人

2006年10月24日 22:28 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

私が勤める会社では、読書会なるものが存在する。
その読書会のお題としての一冊。

さて、いきなりですが、幸せってなんでしょう？

私が思うに「幸せ」であるというのは、自分の好きな事を仕事にする事ではないでしょうか？

どんな仕事でもそうだと思いますが、仕事には向き不向きがあります。
性格的なものや肉体的なもの、色々理由は有るとは思いますが、ほとんどの場合考え方で大きく変わるモノです。

ソフトウェア開発という仕事も例に漏れません。

この業種の特徴としては、

技術の進歩が恐ろしく早い
絶対の答えなどない
非常にロジカルな世界である
コミュニケーションが重要な仕事であるのに苦手な人が多い

もともと、業種として成立してから、それほど長い時間が経ったわけではありません。しかしながら、数年で技術の流行が変わってしまい、ついて行くだけでも結構大変です。

しかも、目的の実現方法はそれこそ無限にあって、「コレが正解！」などという方法はありません。我々の間では「ソフトウェア開発に、（狼男を倒すような）銀の弾丸などない」などと言います。

ソフトウェアは非常に論理的（まぁパソコン自体がロジックで出来ているので当然ですが）であるが、一方で非常に複雑で、理不尽とも思えるエラーに遭遇することもしばしば。

コミュニケーションはほとんど要らない用に見えて、設計や管理の層に行くと、これ以上重要なスキルは有りません。

そんな仕事をするのに、どんな人が向いていなくて、どんな人が向いているのか例を挙げながら考察している本です。
一例を挙げると。

向いている人

純粋に好奇心旺盛
英語が苦手ではない
物事を抽象的にとらえる事ができる

向いていない人

「わかりません」と言えない人
唯一無二の答えがあると思う人
受け身な人

また、後半にはソフトウェア開発で幸せになれる人となれない人を対比しています。

ただ、自分が向いている、向いていないを判断する為ではなくて、
自分の何処が合っていて何処が合っていないかを確認して、落ち込んだり、満足するのではなく、
良いところはのばし、悪きを改め、少しでも楽しく仕事をするための糧するために読んで貰いたい一冊です。

最後に良いフレーズがあったので、引用。

　幸せな技術者はクリエイティビティを持ち続けている人であることが解ります。自分が直接ソフトウェアを開発する立場になく、管理職になったとしても、クリエイティビティを持ち続けているいるひとは幸せです。＜中略＞クリエイティブな人は、常に能動的でポジティブです。

いかがでしょう？たった一台のPCで、たった一人で、新たな価値を持つモノを作れてしまうのが、
ソフトウェア開発という仕事です。こんな仕事他に無いとおもいますけどねぇ。。

『ソフトウェア開発で伸びる人、伸びない人』
荒井玲子　著
技術評論社￥ 882 （税込）

Migration その2

2006年10月23日 22:23 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

Migrationで初期データ作成

Migrationその１の続き

Migrationで初期データの用意も出来ます。
開発時のユーザーデータとか、コードテーブルのようなマスタ定義を書いておくと、
複数人で開発するときに激しく便利。

$ ruby script/generate migrate insert_users

002_insert_usersというファイルが出来ているので、
テキストエディタで編集。

class InsertUsers < ActiveRecord::Migration
  def self.up
     User.create(:name=>"本田 忠勝"   , 
                 :password => "蜻蛉切り",
                 :birth => "1548-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
     User.create(:name=>"酒井忠次"   , 
                 :password => "東三河",
                 :birth => "1527-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
     User.create(:name=>"榊原康政"   , 
                 :password => "無",
                 :birth => "1548-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
     User.create(:name=>"井伊直政"   , 
                 :password => "赤備え",
                 :birth => "1561-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
  end
  def self.down
    @users = User.find_by_roll('徳川四天王')
    @ users.destroy
  end
end

すでにusersのmodelが出来ているはずなので、
User.createでレコードを生成出来ます。

self.downにはfind_by_XXXで検索してdestroyしてやれば良いでしょう。

Migrationで書き方あれこれ

初め迷ったのが、「Migrationで複数のテーブルを作る場合、一つのファイルに纏めるべきか？」と言う点です。
分けて書いても、一つに纏めても変わらないのですが、個人的には分けた方が良いと思います。
理由は単純でコードが見やすいからです。

例えば６テーブルMigrationで書いた場合、rake migrateした時にいきなりバージョンが6になるか１になるかの違いしかありませんし。

もう一つは、データはMigrationで用意すべきかfixtureで用意すべきか？
どっちでもいい気がします。マスタデータの様なモノはMigrationで、それ以外はお好きなほうで。
YAMLのほうが編集はしやすいですが、本来はユニットテスト用なので、微妙な所です。

ターミナルからのfixtureのロードの仕方は・・・忘れたので後で書いておきます。

組織変革ファシリテーター

2006年10月18日 22:42 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

「ウチの会社はちっとも変わろうとしない」
「あのトップでは、会社を変えるなんて到底無理だ」

なんて感じた事はないでしょうか？

あるいは、
「ウチの連中は俺の気持ちが全然わかっていない」
「いくら言っても、下の連中がちっとも動こうとしない」

なんて感じていませんか？

そんな人に勧めたい一冊です。

　　トップだけでも現場だけでも組織はかわらない。改革の火種を育て、組織全体が大きな炎となった時、組織改革の大きな歯車が回り出す。その方法論が本書のテーマである「組織改革ファシリテーション」である。

ファシリテーションとはなんでしょうか？
日本語に直すと「共働促進者」とか「供創支援者」と呼ばれています。

つまり、

　
　集団による問題解決、アイデア創造、合意形成、教育・学習、組織変革、自己表現・成長など、あらゆる知識創造活動を支援し促進していくのである。またその役割を担う人がファシリテーターである。

筆者はファシリテーターの一例として二人の人物をあげています。
日産を再生させたカルロス・ゴーンと、日本でおそらく初めての民主主義思想者上杉鷹山です。
二人とも大好きな人物です。

組織を動かすには、３つの機能が必要だと言っています。

リーダーシップ

組織の方向性を示す
望ましい行動の規範を示す
組織をつくり人を育てる

マネジメント

資源の配分を最適化する
進捗を管理して成果を達成する
業務を改善して、質を高める

ファシリテーション

メンバーの自律性を高める
チームの相乗効果を高める
組織学習のスピードを上げる

どれも必要な機能ですが、特にファシリテーションがもたらす「相乗効果」は絶大です。
今私自身は組織改革を狙っていますが、一番重視しているのがこの「ファシリテーション」です。

もちろんリーダーシップ、マネジメントという土壌があって初めて、ファシリテーションが有効なんですが、
閉塞感を打破するのは、「コレしかない」と考えているのです。

また、組織を変える力として３つ改革が必要であると述べています。

戦略の改革
業務の改革
風土の改革

戦略の改革はイメージしやすいのではないでしょうか？
「事業や経営資源の選択と集中」を指します。主に経営陣からのトップダウンで実行され、即効性があり、効果が見えやすい改革です。早ければ数ヶ月で結果が出ます。医療で言うなら、外科手術です。しかしながら、本当の意味での企業の硬直性が治ったわけではなく、いつ再発するとも解りません。

業務の改革は少し時間がかかります。投薬による治療の様なものです。
「顧客志向に基づく業務プロセスの改善」を指します。戦略の改革で示せるのは目標であって、いかに目標まではしるのかを決めるのが、業務改革なのです。一般的に１〜２年の期間を要します。
しかし、トップダウンでは上手く行かず、「やったフリ」などの悪い風土を築く可能性があります。

そこで最後の風土の改革です。
もっとも難しい改革で、従業員一人一人の意識を変えることが目標になります。「自己革新を促す組織風土づくり」といえるでしょう。価値観やメンタルモデルといった文化を変えるため、大きな痛みに耐える必要と、長期間継続してゆく必要が有ります。３〜５年くらいかかって初めて効果が目に見えて来ます。病気の治療と言うより、体質改善に近いものです。

これらの改革を行うための実践的なhow toがかかれているのがこの本です。
また前著として「問題解決ファシリテーター」があり、こちらが入門書になっています。

一応この本だけで独立した内容になっています。
組織を変えたい皆様ご一読をオススメします。

『組織改革ファシリテーター』
堀公俊　著
東洋経済新報社￥ 2,310 （税込）

Migration その１

2006年10月16日 22:01 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

Migration

最近Railsで開発していて、migrationを使い初めてみた。（以前Rails使っていた頃は無かった気がする・・・）

激しく便利。軽くメモ代わりに。

データベースの定義（DDL）をRails側で実装出来る機能ですが何が嬉しいかといえば、

DDLをバージョン管理できる
いつでも任意のバージョンに戻す事ができる
modelさえ作ってしまえばテストデータをrubyで書いてinsertできる

チーム開発にはもってこいの機能です。

使い方

生成はscript/generateで。ありがちなusersというテーブルを生成。

$ ruby script/generate migrate  create_users

こうすると、”001_create_users.rb”というファイルがdb/migrateに出来ているので、
テキストエディタで定義を編集。

self.upとself.downというメソッドがあるので、
self.upはバージョンアップ時に実行され、
self.downはダウングレード時に実行されるのね。

class CreateUsers < ActiveRecord::Migration
  def self.up
      options = {
        :options     => "ENGINE=innodb DEFAULT CHARSET=utf8"
      }
      create_table(:users, options) {|table|
        table.column :name,                 :integer
        table.column :password,             :string, limt => 50
        table.column :birth,                :date
        table.column :roll,                 :integer
        table.column :time_stamp,           :datetime
      }
  end
  def self.down
    drop_table : users 
  end
end

基本的にupにテーブル定義、
downにdrop_tableしておけばよい。

実際に動かしてみる。

$ rake migrate

これで、DBにusersテーブルが出来ているハズ。

逆にダウングレードする場合は

$ rake migrate　VERSION=[バージョン番号]

としてあげればOK。
バージョンってのは、generateしたときに振られる　"001"とかの連番。

スキーマ命令

スキーマ定義に使える命令をメモ代わりに

create_table(name, options) テーブルを作成する。
drop_table(name) テーブルを削除する。
add_column(table_name, column_name, type, options) カラムを追加する。
rename_column(table_name, column_name, new_column_name) カラム名の変更
change_column(table_name, column_name, type, options) カラム属性の変更
remove_column(table_name, column_name) カラムの削除
add_index(table_name, column_name): インデックスを追加する。
remove_index(table_name, column_name): インデックスを削除する。

定義に使える型

今のところ、PostgreSQLとMySQLのみ対応らしい。

抽象表現	rubyでの型	PostgreSQL	MySQL
:primary_key	Fixnum	serial primary key	int(11) DEFAULT NULL auto_increment PRIMARY KEY
:string	String	character varying(255)	varchar(255)
:text	String	text	text
:integer	Fixnum	integer	int(11)
:float	Float	float	float
:datetime	Time	timestamp	datetime
:timestamp	Time	timestamp	datetime
:time	Time	timestamp	datetime
:date	Date	date	date
:binary	String	bytea	blob
:boolean	Object	boolean	tinyint(1)

ActiveRecord上でrubyでの型とDBの型で不具合が起こるとすれば、
decimal型のマッピングがFloatクラスにされる事で、演算を繰り返すと丸め誤差が生じる事。
migrationを使っていればその心配はない。

今日はこの辺りまで。

ある一日のチャットの記録

2006年10月14日 00:16 hackmylife | 個別ページ | コメント(0) | トラックバック(0)

さっきまでやっていたチャットの内容を無駄にUPしてみる。

なんだか久しぶりに技術的に満たされたチャットだった気がする。
そう、こういうのを求めているのだよ！

C&P 06/10/13 21:38
う〜ん、いったんupしてもらえますか？ソースを見てみたいです。
K 06/10/13 21:42
今メールしました。別プロジェクトでやってたので。
06/10/13 21:44
とりあえず、migrationとデータはsvn commitしました。
けど、import/exportがなぜかうまくいかないので試行錯誤中です。
06/10/13 22:27
importができない…。意味がわからない。
C&P 06/10/13 22:28
一行のファイルでもダメですか？
K 06/10/13 22:29
そうなんです。
load data infile と mysqlimport の両方を試しているのですが…
06/10/13 22:30
もうちょっとやってみます。
C&P 06/10/13 22:30
load data infile はやったことありますけどねぇ。
06/10/13 22:31
suggest、組み込み中なんですが、文字化けます。何かおもいあたりますか？
K 06/10/13 22:32
DBno
06/10/13 22:32
DBの中は文字化けてないです？
C&P 06/10/13 22:32
DBはOKです。
K 06/10/13 22:33
僕が試してるときに文字化けたのは、UTF-8問題のときだけでした。
DB/ruby(environment.rb)/rhtml
06/10/13 22:34
Safari云々とかはちょっと試したことがないのでわかりません。
prototype.js使ってるので可能性なきにしもあらず？？
C&P 06/10/13 22:35
それは有りません。頂いたプロジェクトの場合文字化けません。DBは同じモノを使っています。
K 06/10/13 22:36
environment.rb の $KCODE とかも大丈夫ですよね。
06/10/13 22:40
importいちおうできましたが、どうしてもload data infileではできませんでした。
06/10/13 22:40
$ mysqlimport -i -uroot -p --fields-terminated-by="," biztrip_development /tmp/stations.dat
C&P 06/10/13 22:41
こっちはダメですね。
K 06/10/13 22:42
で、インポートできましたので、こちらで試してください。
C&P 06/10/13 22:42
了解
06/10/13 23:17
だめですね文字化けます。
K 06/10/13 23:19
うーん…
C&P 06/10/13 23:20
ん、control.jsにもフィルタが必要か？？？
K 06/10/13 23:21
確かにcontrol.jsは使ってますね。
C&P 06/10/13 23:21
ちなみにコレ、前方一致ではないんですねぇ。
06/10/13 23:22
あと、「池尻大橋」が「池尻」になっている。
K 06/10/13 23:22
%hoge%になっちゃうみたいです。
C&P 06/10/13 23:25
this.updateChoices(request.responseText);
06/10/13 23:25
this.updateChoices(ajax_filter(request.responseText));
06/10/13 23:25
で解決。死ね
K 06/10/13 23:26
control.jsの中ですか？
C&P 06/10/13 23:26
Yes,
K 06/10/13 23:26
うわあ、BKだなあ。
C&P 06/10/13 23:26
ワーキングプアだよ
K 06/10/13 23:27
ワーキングプアの座は譲りませんよ
C&P 06/10/13 23:27
いい勝負ww
06/10/13 23:27
しかしコレ、微妙にヒットしないときがあるなぁ。前方一致にしたい・・・
K 06/10/13 23:30
controllerの
06/10/13 23:30
auto_complete_for :station, :name をけして
06/10/13 23:30
def auto_complete_for_station_name
@items = Station.find ( :all,
:conditions => [ "LOWER(name) LIKE ?",
params[:station][:name].downcase + '%' ],
:Order => "name ASC",
:limit => 10 )
render :inline => "<%= auto_complete_result @items, 'name' %>"
end
06/10/13 23:31
というメソッドに置き換えてみてください。うまくいくかな…。
C&P 06/10/13 23:31
ほほう。ちなみにこれ:index対応してないのでは？？
K 06/10/13 23:32
:index？
C&P 06/10/13 23:32
<%=text_field("daily_expense[]", 'bill_no' )%>
06/10/13 23:33
こういう奴です。
06/10/13 23:33
リストのインプット項目には、
06/10/13 23:33
"daily_expense[]"ってやると
06/10/13 23:34
daily_expense[id][bill_no]にしてくれます。
06/10/13 23:34
これが更新を３行でかける理由でもあります。
K 06/10/13 23:34
なるほど。
C&P 06/10/13 23:34

DHHは神！
K 06/10/13 23:35
神ですねw
06/10/13 23:35
仕組みがまだわからないのだけど、きっちり導入するためにはhelperとか中身のほうも少し手を入れないと駄目なのかな。
C&P 06/10/13 23:36
ためしてダメでしたか？ちなみにコレはRails本体ですよね？？
K 06/10/13 23:38
いえ、controllerのほうでoverrideしようと思ったのですが
06/10/13 23:39
500エラーがでて、いまいちだめだったのでちょっと忘れてください。すいません。
C&P 06/10/13 23:40
う〜ん。。。。違うタグで、application_helperに書いた方が早そう。
06/10/13 23:40
例)
06/10/13 23:40
date_filedみたいな奴
06/10/13 23:41
もとい
06/10/13 23:41
いや、もとくないや
K 06/10/13 23:41
もとくないw
C&P 06/10/13 23:42
つか、暫定でベタ書きすればいいんでは！？
06/10/13 23:43
ループで<style>かかれるの嫌だし。
06/10/13 23:44
必要なのは、
06/10/13 23:44
<script type="text/javascript">
//<![CDATA[
var daily_expense[]_description_auto_completer = new Ajax.Autocompleter('daily_expense[]_description', 'daily_expense[]_description_auto_complete', '/home/auto_complete_for_daily_expense%5B%5D_description', {})
//]]>
</script>
06/10/13 23:44
だけだったりする罠
K 06/10/13 23:45
ですねえ。じゃあ、ActionControllerの中を前方一致用に書き換えちゃいますか。
C&P 06/10/13 23:45
そうしますか。
K 06/10/13 23:45
'%' 消すだけだし
C&P 06/10/13 23:46
まぁ、そうですな。前方一致以外いらねーし。
K 06/10/13 23:46
えっと、どうしますか。
lib/action_controller/macros/auto_complete.rb の
06/10/13 23:46
39行目なんですがw
06/10/13 23:47
病巣は
06/10/13 23:51
ウソでした。最新のActionPack(1.12.5)では40行目でした。
C&P 06/10/13 23:51
ActionPackって何処だ？つかRailsって何処に...
06/10/13 23:52
/usr/local/辺りかな？
K 06/10/13 23:52
うちだと(Windowsですが)
06/10/13 23:52
C:\ruby\lib\ruby\gems\1.8\gems\actionpack-1.12.5\lib\action_controller\macros
06/10/13 23:52
です。
06/10/13 23:53
いいなあ、UNIX表記で。
C&P 06/10/13 23:53
winは解ります。Unix最高です。
06/10/13 23:53
ビバ・ユニックス
06/10/13 23:53
でら・ユニックス
06/10/13 23:54
ジーク・ユニックス
K 06/10/13 23:54
そこまで！？
C&P 06/10/13 23:55
あれ・・・上手くいかない。
06/10/13 23:55
autocompleterの引数が解らないなぁ
K 06/10/13 23:56
auto_complete_for :Station, :name の記述は残すんですよね？
C&P 06/10/13 23:57
でしょうねぇ。divの記述をわすれていたっぽい
K 06/10/13 23:57
ic
C&P 06/10/14 0:00
だめだぁ。。。起動しない
06/10/14 0:00
ちょっと風呂入ってあとでためして見ます。