カテゴリ別 2003年 | 2004年 | 2005年 | 2006年 | 2007年 | 2008年
知り合いサイト: よんだもの / 暴想 / Linuxでやる夫 / 新宿Vipper / 僕だけが幸せになればいいのに。
1.0 が 2005/12/13 にリリースされてから二ヵ月半、そろそろ 1.1 のリリースが迫っているようです。
What (will be) new in Rails 1.1 は rails 1.1 の主な機能追加(予定)をまとめています。たくさんあるので把握しきれてないですが、RJS template の追加が一番大きそうですね。
rails のホスティングサービス。switchtower をサポートしているので、作成したアプリケーションの導入、アップデートが楽にできると謳っています。
例によって Deploy in 5 minutes. と題した動画が公開されています。ローカルで開発している rails アプリを switchtower を使って railsmachine に導入、導入後ローカルでアップデートした内容を railsmachine のアプリに反映という一連の作業を行っています。script/generate railsmachine で railsmachine 向けの switchtower ファイルを生成しているのがキモですね。
特に変わった switchtower の使い方をしているわけではなく、switchtower を使った普通の開発プロセスです。しかし、(rails の成功が続ければ)いずれこれが「普通」になるのかと思うと嬉しくなります。
シェルアクセスを許可しない共有レンタルサーバでは、MT を簡単にインストールできる！といったことを売り文句にしますよね。rails/switchtower なら簡単インストールの仕組もそう難しくなく作れそうです。Typo、Hierakiといった rails アプリケーションがボタン一発でインストール／バージョンアップができる、というのを売りにしたホスティングサービスが登場しないかな。
「Rails on Ruby」が「Ruby on Rails」を名乗っている件について。
過去の議論は調べてませんので自説ですが。
rails と略しますが、あくまで "Ruby on Rails" で一つの名前だと思います。
レールが主体ではないですよね。列車があってのレールですから。そして列車はレールがないと走れない。Ruby という列車をレールに乗せることで快速快適にウェブアプリの開発ができる。だから "Ruby on Rails"。
ここでレールというのはフレームワーク＝クラスライブラリという狭い捉え方ではなく、DRY や Convension over Configuration といった考え方、rails コマンドを叩いたときに生成されるファイル構成、ユニットテスト支援や test/development/production モードの存在、switchtower や CIA による開発運用プロセスの支援などなど、フルスタックという言葉で表される諸々じゃないかなと思います。これらは必ずしもプログラミング言語に依らないものですから、on Rails であって on Ruby ではないわけですね。
新デザインのpython.org — TRIVIAL TECHNOLOGIES 2.0
足かけ一年。今年のPyConのコンテンツマイグレーションスプリントを経て，ようやく新しいpython.orgがお目見えしたようです:-)。
トップページを分析して、ruby-lang.org と比較してみたいと思います。
両サイトとも、
となっています。python.org の方が優れている点としては、
といったところでしょうか。
python.org は「マーケティング重要」と考えているようです。具体的には、トップページに以下の要素を載せることで、Python という言語の特徴や強みが分かるようになっています。
ruby-lang.org のトップページが ruby ユーザに向いているのに対して、python.org のトップページは、非 python ユーザに向いていますね。
別に同じ方針を取る必要はないと思いますが、ruby-lang.org の改善ポイントとしてはこんなところでしょうか。
We were served with a “cease and desist” from Raindance Communications, Inc. over the use of their registered trademark SWITCHTOWER on Friday. This led to a wild three-day brainstorming session and a new name for SwitchTower: Capistrano.
Raindance Communications という会社の登録商標と被っていたので変えたそうです。名前が変わったということは rails 関係の RSS を眺めていてわかったのですが、こんな理由だったのですね。
どういう意味の言葉なのかわからないのでぐぐってみたのですが、カリフォルニアの伝道所跡 San Juan Capistrano(サン ファン カピストラーノ) に由来しているのかな。どういった意図でこの名前を選んだのかはわかりませんけども。
ETech 06 でNingが講演。その全てがスクリーンキャストで公開される
ETech 06 で、Ningが発表を行ったらしい。その講演の様子がスクリーンキャストになって、公開されている。 ( http://etech06.ning.com/ )この講演はとてもよくまとまっている。Ningの魅力が良く理解できた。
ETech 06 での ning の講演をレポートされています。ning はソーシャルアプリケーション（ソーシャルブックマークとか写真共有とかそんなの）を作るためのサービスです。
rails に対応する予定というところが目を引きました。個人的に Ruby 好きなので気になったということもありますが、これは ning の方向性にあっているなと思います。
以下、例によって ning の人がどう言っているかは調べてませんが、ning のサービスを見ての感想です。
いかに簡単に自分のほしいアプリケーションを作成することができるか、という点が ning のユーザにとっては重要です。ning は以下のようにして、その課題を解決しようとしていると思います。
すでにウェブアプリを開発している人は、雛型をコピーしてちょっと改造するだけじゃ自由度が少ないじゃんと思われるでしょう。確かにそうです。ですが、プログラミングを始めて、いきなりスクラッチでオリジナルのプログラムを書いた人は多くないのではと思います。私の場合は、書籍に載っているサンプルを改造したり、ウェブで配布されている CGI の改造からプログラミングを覚えました。改造には、動く実物に手を入れるためほしい機能だけ作ればいい（＝ゼロから作成するよりも楽だしモチベーションが維持できる）、コードを読んで先人の技を覚えられる、といった利点があります。
ning がターゲットにしたいのは、このくらいの初歩のプログラミングレベルのユーザなのだと思います。もっと言えば、Excel でマクロ組んだりとか Access でアプリ作ったりとか、プログラミングが本職じゃないけど多少は詳しく、業務の助けになるちょっとしたものを作る人たちです。あるいは、趣味で掲示板などの CGI をサイトに設置している人(自分で設置できる程度に詳しい)。
今現在においては、そういう人たちは自分で作成したりはせずに、ニーズに合ったものを探してきて使っています。とはいえ、完全にニーズと一致したアプリを見つけるのは難しいものです。デザインを変えたい、項目を付け足したいといった要望が出てきます（ですので、機能の豊富さやカスタマイズ性の高さが評価されます）。
豊富な機能を使いこなしたり高度なカスタマイズをするのと、プログラミング言語を使ってほしいものを作るとの間には、越えなくてはならない高い壁があるのかもしれません。
その壁を押し下げるのが、先にあげた四つの項目です。
四番目は重要です。レポートで、
非営利団体がNingを使うシナリオ。地域のボランティア団体がNing上でアプリを作成。各地域の団体がそれをコピって活用。団体にテッキーがいなくても、よその団体のアプリをコピーできるので楽。さらにコンテントストアのデータを共有できるのもうれしい、みたいな。
とあります。ウェブのアプリは改造版が人気を得て独自の発展を遂げることがあります。改造版が本家とは異なったニーズを満たすためです。講演の例には、ジェネラルなソーシャルアプリから特定地域や特定業務に特化したアプリが作られ、それがまた利用されて……という進化が起きる期待がうかがえます。
ただ、どなたかが書かれていましたが、「改造して好きなものを作れるような人は、改造ではなくオリジナルで作る」というのが現状でしょう。まだまだ壁は高いです。
雛型がたくさん供給されて少しの改造でほしいものが手に入るようになること、改造作業がより容易にできることが必要です。ruby という言語の習得が容易かどうかは議論が要りそうですが、rails というウェブアプリケーション開発フレームワークの習得の容易さは論を待たないのではないでしょうか。ということで、ning の rails 対応に期待しています。
もちろん、rails が現在においてウェブアプリケーション開発フレームワークの中ではもっとも習得が容易な部類というだけで、壁を取っ払えるわけではないと思います。
しかし、このような試みの先に、ほしいアプリを少しの労力で作れる、つまりネットでしたいことを実現できる世界があるのではないでしょうか。
rubycoさんの日記は、プログラミング言語のTipsまとめサイトとして素晴しく機能しているわけだが、これは"結城さんがやっている"ということに依るところが多きい気がする。もし、"結城さんがやっている"ということが、各rubyユーザーに与える精神的な影響を抽出して仮想的な人格を構成できたら、プログラミング言語のTipsまとめサイトを半自動で生成することができないだろうか。
難しいのはベースとなる TIPS を書く人は文責を持たなければならないことかなと思います。つまり、
雰囲気があると、私のような間違いを恐れる人間には参加が難しいです。TIPS として適切な内容か、もっと良いコードはないか、言い回しは適切かなど、その後洗練をしていけばいいことを、最初から思い悩むこと必至です。質問側になら回れるのですけどね。その点、最低限タイトルとタグとコードがあればいいcode snippetsだと気軽かな。(という思考で私は オブジェクト指向スクリプト言語 Ruby リファレンスマニュアルに対峙してしまうわけですが、他の方がこれに書き加えたい/修正したい項目を見つけたときに、どう考えてどう行動するかを知りたいものです。)
O'Reilly Ruby ブログより。Ruby プログラマを面接するときに訊いておくべきこと。「"J2EE" or "EJB" という単語が履歴書に何度も出てくるなら、Java は知らないと解釈せよ」(そして Ruby でも同じようなことがいえるだろう)などなど。実際的かどうかはわかりませんが、話としては面白い。
ヽ( ・∀・)ノくまくまー(2006-03-09) Symbol#to_procより例を拝借。
まず、前提。Symbol#to_proc の導入により、
array = [1,2,3]
array.collect{|i| i.to_s}から、ブロック変数 i を除去することができて
array = [1,2,3]
array.collect(&:to_s)とより簡潔に書けます。
簡潔なのは歓迎ですが、to_s する主体(オブジェクト i)がコード上からいなくなるのに違和感を覚えます。加えて、慣れ親しんだ collect が別物になってしまった感もあります。array.collect( :proc => &:to_s ) ならまだいいかなあ。
まあ、前者についてはprivate メソッドに一々 self をつけたりはしない(あ、そもそもできない。self. つけられるのはなんだったかな……)ので、慣れの問題なのかもしれません。
どちらかというと0が偽として見なされる方が見落としてバグになる可能性が高い気がする。plumの罠の話とか。
これは思いますね。Perl などで条件式に変数を入力があるかないかの意味で書くとたまにはまります。
Perl と Ruby と真偽の扱いが異なる点は、空文字列を偽とする、0 （と "0"。Perl は区別しないけど）を偽とするところです（他あったかな）。
Ruby では値が入力されているかを確かめるために、
if input and not input.empty?
p input
endと書いたりします。input が nil でなく（＝存在している）、かつ空ではない（＝入力されている）という意味です。empty? メソッドは Array、Hash、String といった基本的なデータ型クラスのオブジェクトが持っています。特に入力には String が使われることが多いので、上のようなイディオムが良く使われます。rails では Object#blank? として定義されていますね。ここでは Perl と同じく空文字列 "" を偽として扱っています。
一方 0 が 偽だと困ることがあります。0 が意味のある値として与えられるときです。例えば、
具体例にすれば、0 円の購入物を家計簿につける、ZnZ さんが挙げられている plumの罠、項目の表示順番を 0, 1, 2 ... とするプログラムなどが言えるかと思います。
つまり、0 が偽な言語では、値 hoge が有効かどうかを条件とする際に、
といった使い分けを必要とするのではないでしょうか。
大変そうだけど、慣れれば自然と回避できるようになるのかな。
最近のコメント：
RSS
This work is licensed under a
Creative Commons License
(note: text only. w/o web design, citations, (re)distributed softwares).
_ なおゆき [> 大変そうだけど、慣れれば自然と回避できるようになるのかな。 2年間ほどperlを使い続けていますが、いまだに慣れ..]
_ だて [米人が多少のデザイン崩れを気にも留めないように、重篤なバグの原因にならなければ気にしないのかもしれませんね。]