先日のFirefox3.5のaudioタグの記事を拡張してみた
http://www.mwsoft.jp/programming/firefox3_5/audio_test.html
使える属性はだいたい試してみたつもり。先日はできなかった、別音楽の読み直しもできた。
メモリがどう解放されているのか分かってないけど、まぁ、とりあえず動いてるから良しとしよう。
Event系は洗ってないけど、そんなにハマらなそうに見えるので、とりあえず割愛しようかと。
今後に備えてロイヤリティフリーの効果音とか音楽とかが欲しひ。その辺の店に売ってるかな。
2009年07月04日
Firefox3.5でDrag and Dropイベント
Firefox3.5のドラッグアンドドロップイベントを使ってみた。とりあえず書いたソースとその解説的なもの。
Firefox3.5でDrag&Drop;
http://www.mwsoft.jp/programming/firefox3_5/drag_and_drop_test.html
Dropイベントで少しハマりました。dragenterとdragoverを無効にしないと受け取れないとは……
しばらくの間、Firefoxの新機能と戯れようかと思って、こんなページを作ってみた。10個くらい特集しておけば、なんかそれっぽいコンテンツに見えるだろうか。
http://www.mwsoft.jp/programming/firefox3_5/
Firefox3.5でDrag&Drop;
http://www.mwsoft.jp/programming/firefox3_5/drag_and_drop_test.html
Dropイベントで少しハマりました。dragenterとdragoverを無効にしないと受け取れないとは……
しばらくの間、Firefoxの新機能と戯れようかと思って、こんなページを作ってみた。10個くらい特集しておけば、なんかそれっぽいコンテンツに見えるだろうか。
http://www.mwsoft.jp/programming/firefox3_5/
Ruby on Railsを使ってメリットを感じた瞬間
最近、Railsをガシガシ使ってみて、心根的には「あまり好きになれないな」と感じたわけですが（※素直になれないのではなく、普通にそう思う）、それでもメリットをいくつか感じたので列挙してみました。
※あまりサーバサイドの処理は担当していません。どちらかというと、裏側の処理を書いてました。そういう仕事をしていた人間の所感なので、ちと王道とはズレがあるかも。
requireって書かなくていい
へいへい、無精者ですよ。
デフォルトでいろんなものがインクルードされていて、自前で標準モジュールを呼ぶことが少ないというのは、楽で良いと思います。
日付・時刻の扱いが簡易
元々RubyはDate.parseって書けば、割と空気を読んでくれたりするように、日付処理はかなり簡易ですが、ActiveSupportはそれに輪をかけて便利です。
tomorrowと言えば翌日が出てきたり、next_weekと言えば次週が出てきたりします。
開発途中にDBを変えても損害が少ない
試しにWindows＋MySQLで開発したソースをLinux+SQLite3に移しても、特に問題なく。PostgreSQLに移した際も、ActiveRecordを推奨された使い方で（SQLベタ書きとかせずに）使っていれば、差異をほとんど吸収してくれました。
まぁ、途中でDB変えるってことはあまり無いと思いますが、本番環境の選定が決まってない状態で開発スタートしても平気かもしれないってのは、なかなかに興味深いです。
データベースの管理が楽
create文を書くよりgenerateしたmigrationファイルに手を入れる方が数段楽ですし、管理もしやすいです。
あと、DBに関する設定が、必ず決められた場所（config/database.ymlとか）にいるというのもありがたいです。
作業量が減る
script/generateやら、rake db:migrateやら、何かと作業工数を削ってくれる代物が用意されています。
1つ1つの短縮時間は大したものでもないですが、全部足せばけっこうな時間が短縮できます。
RESTで云々する際のコストが限りなく低い
ちょっとしたXMLやJSONを吐き出したい時に、非常に少ないコストで実行できます。
XMLはscaffoldで作った叩き台上で、デフォルトで出力出来るようになっているし、JSONも1行か2行書き変えれば出力されます。
引き継ぎ易い
個人的に、これが一番良いメリットなんじゃないかと思ってます。
Railsで書いたソースは、どの設定ファイルにどんな記述がされているか決まっているし、環境構築もrakeである程度自動生成できます。
オリジナリティ溢れるRubyソースを渡すよりも、Railsで書いたものの方がお互いに共通認識があるので意思疎通がしやすいです。Rails知ってる人の絶対数が少ないということについては、ノーコメント。
もちろん、感じてるデメリットもいくつかあります。
ActiveRecordで大量データ取り扱わせたらやたら重いですし、そもそもRubyの実行速度も芳しくない。C++やJavaなら数秒で終わる処理が数十秒かかったりします。
ちょっと昔のマージソート実行時間比較
http://techtrim.net/2008/01/18_19196.html
それでも、さすがキラーアプリと呼ばれるだけの便利さはあるなぁと、そう思いました。
※あまりサーバサイドの処理は担当していません。どちらかというと、裏側の処理を書いてました。そういう仕事をしていた人間の所感なので、ちと王道とはズレがあるかも。
requireって書かなくていい
へいへい、無精者ですよ。
デフォルトでいろんなものがインクルードされていて、自前で標準モジュールを呼ぶことが少ないというのは、楽で良いと思います。
日付・時刻の扱いが簡易
元々RubyはDate.parseって書けば、割と空気を読んでくれたりするように、日付処理はかなり簡易ですが、ActiveSupportはそれに輪をかけて便利です。
tomorrowと言えば翌日が出てきたり、next_weekと言えば次週が出てきたりします。
開発途中にDBを変えても損害が少ない
試しにWindows＋MySQLで開発したソースをLinux+SQLite3に移しても、特に問題なく。PostgreSQLに移した際も、ActiveRecordを推奨された使い方で（SQLベタ書きとかせずに）使っていれば、差異をほとんど吸収してくれました。
まぁ、途中でDB変えるってことはあまり無いと思いますが、本番環境の選定が決まってない状態で開発スタートしても平気かもしれないってのは、なかなかに興味深いです。
データベースの管理が楽
create文を書くよりgenerateしたmigrationファイルに手を入れる方が数段楽ですし、管理もしやすいです。
あと、DBに関する設定が、必ず決められた場所（config/database.ymlとか）にいるというのもありがたいです。
作業量が減る
script/generateやら、rake db:migrateやら、何かと作業工数を削ってくれる代物が用意されています。
1つ1つの短縮時間は大したものでもないですが、全部足せばけっこうな時間が短縮できます。
RESTで云々する際のコストが限りなく低い
ちょっとしたXMLやJSONを吐き出したい時に、非常に少ないコストで実行できます。
XMLはscaffoldで作った叩き台上で、デフォルトで出力出来るようになっているし、JSONも1行か2行書き変えれば出力されます。
引き継ぎ易い
個人的に、これが一番良いメリットなんじゃないかと思ってます。
Railsで書いたソースは、どの設定ファイルにどんな記述がされているか決まっているし、環境構築もrakeである程度自動生成できます。
オリジナリティ溢れるRubyソースを渡すよりも、Railsで書いたものの方がお互いに共通認識があるので意思疎通がしやすいです。Rails知ってる人の絶対数が少ないということについては、ノーコメント。
もちろん、感じてるデメリットもいくつかあります。
ActiveRecordで大量データ取り扱わせたらやたら重いですし、そもそもRubyの実行速度も芳しくない。C++やJavaなら数秒で終わる処理が数十秒かかったりします。
ちょっと昔のマージソート実行時間比較
http://techtrim.net/2008/01/18_19196.html
それでも、さすがキラーアプリと呼ばれるだけの便利さはあるなぁと、そう思いました。
【1日1Commons】ちょっとだけ高機能なキャピタライズ
// JRE 1.6.0_07
// Commons Lang 2.4
// キャピタライズ
// org.apache.commons.lang.WordUtils
// tag capitalize 大文字 小文字
続きを読む
// Commons Lang 2.4
// キャピタライズ
// org.apache.commons.lang.WordUtils
// tag capitalize 大文字 小文字
続きを読む
