温度グラフの復活

このページの、左サイドバーに表示していた温度変化のグラフを復活させた。昨年の８月から休止していたので、約７ヶ月ぶり。ミネソタがどれだけ寒くなるのか見るためにはじめたけれど、意外と実用的だったので復活させてみた。

一見、温度変化を表示するだけの事だけれど、Webに関連する技術全般をそれなりに駆使する必要があり、なかなか勉強になった。

東京周辺ではサクラの便りも聞こえてきそうな時節だが、ミネソタでは今日も雪が積った。地元のTVやラジオでは、「春はすぐそこ」としきりに繰り返すが、気温を見る限りでは、TORITORIには「まだまだ…」と思えて仕方がない。

TORITORI

ルビーにてんてこ舞い

サイドバーにあるリンクがいくつか機能していなかったのを、ようやく直した。原因は、大きく２つ。１つは、リンク先のアプリケーションが置いてあるサーバーが、利用者の知らないうちにアップデートされ、既存のものが動かなくなっていた事。もう一つは、アプリケーションの作成に使われているRuby On Railsがバージョンアップして、これまた既存のコードが動かなくなった事。

例えてみれば、いつの間にか、道路が新しくなっていて、持っている車では、そこを走れなくなったようなもの。「走れるように車を直すのは、自分でやってね」と。

と、愚痴だけ並べた投稿では、世の役には立たないと思うので、建設的な情報も付け加えたい。と言うわけで、以下は、技術的な情報。Ruby On Railsのバージョンアップに伴って、既存のソースコードに変更を加えた部分です。

form_end_tagが利用できなくなった。かわりにendを用いる。
以前の記述：

<%= form_tag ...省略... %>
...省略...
<%= form_end_tag %>

新しい記述：

<% form_tag ...省略... do %>
...省略...
<% end %>

イコール(=)が不要になっている点に注意

render_actionが利用できなくなった。本来のコマンドを使って、render :action => "アクション名"とする。

検索結果をページ毎に表示する機能、paginateが利用できなくなった。この変更は影響が大きかった。なぜなら、とても利用する機能だから。Ruby
On Railsの標準機能ではなくなり、プラグインを利用しなければならない。今回、利用させてもらったのは、will_paginateというもの。

1. 開発中のrailsアプリケーションのあるルートディレクトリで、will_paginateをインストール。vendorという フォルダーにインストールされる。
   

   prompt%> ruby script/plugin install http://tools.assembla.com/svn/breakout/breakout/vendor/plugins/will_paginate/

   URLの後半部分は…/breakout/vendor/plugins/will_paginate/です。隠れて見えなかった場合の参考までに


2. コントローラーに記述されている以前の paginateの部分を変更。 参考までに、変更例を以下にあげます。
   
   以前の記述 ：

   @album_pages, @albums = paginate(:albums, :per_page => 8)

   
   新しい記述 ：

   @albums = Album.paginate :page => params[:page], :per_page => 8

   
   ここで、Albumはサンプルのモデルクラス。各アプリケーションで利用するモデルクラスに置き換えてください。各モデルクラスで利用可能なfindメソッドと似た使い方ができるようです。


3. 次にビューの変更。上記コントローラーでの変更例を元にすると、
   

   <%= will_paginate @albums %>

   
   と、なるようだ。その結果、
   

   « Previous 1 2 3 4 Next »

   
   日本語にしたい場合は、
   

   <%= will_paginate @pages, @prev_label="前", @next_label="次" %>

   
   

ビューの記述は、以前より楽になったが、このように動いていたコードを変更しなければならないのは、困りものだ。

params,flash,headers等が、インスタンス変数ではなくなった。@params、@flash、@headersと記述していたが、頭に@マークをつける必要が無くなった。

RoR 2.0になって、「ファイルのアップロード方法が以前の方法でできなくなった。」という記述をウェブ上で見かけた。今回の作業中、アップロードが確かにできなくなっていたが、私のケースの場合、サーバーに問題があっただけで、RoRのコードには何も変更をする必要は無かった。

TORITORI

ハリウッド映画の弊害

ソフトウェアデザインで有名なニールセンさんの記事で、「そう！それっ」と思ったので、記事を書いてみる。

要約すると、映画に出てくるコンピューターのインターフェース（画面のデザインや操作方法）が「変だ！」「ありえない！」という１０個の例を挙げている。「映画に出てくるコンピュータは、使う人ではなく、観客のために設計されているのだから、しょうがない一面もある。」といった感じかな。

TORITORIも、そういったエンタメ向けの派手なインターフェースに、けちをつけるような野暮はしないが、結論のところで問題にしていることの一点にはとても共感した。

映画に出てくるヒーローがいとも簡単にコンピューターを使いこなしてしまう事の問題だ。はじめてみるソフトウェアをいとも簡単に使いこなし、ピンチを切り抜けるヒーロー達。この結果、コンピューターでトラブルにあったユーザーは自分の能力のなさが原因だと思い込んでしまう下地を作っているというのだ。WindowsをMacを、そしてUnixを知っていたとしても、その上で動いているソフトウェアを使うためには、そのソフトに関する知識が必要になり、学習期間が必要になる。だから、もし、そのソフトを使ってトラブルにあったとすると、責められるべきは、ユーザーではなく、ミスを誘発するようなソフトウェアのデザインの可能性もあるはずなのだ。

車の運転席は、ミスを防ぐように進化してきたはずである。また、ミスを防ぐために奇抜なデザインは避けられてきたはずである。その結果、どのメーカーの車に乗っても、運転できる。一方、コンピュータのソフトウェアは、目的が大きく異なるものが多いのと、歴史もまだ浅いため、そのデザインが収束してきているとは言い難い。

コンピューターを使ってトラブルに遭遇しても、自分を責める事なかれ。TORITORIは自分でソフトウェアを作っているので、自分を責める。これは、日々の精進である。

TORITORI

ミネソタ まっぷ

しばらく前から、このブログの左側サイドバーに、「ピーナッツを探せ!」のリンクを載せている。今回はその紹介。

ここミネソタに来て１年になるが、最初の頃は、右と左どころか上も下もわからない状態だった。そんな中、氷点下の街を自転車でめぐって、徐々に行動範囲を広げてきた。それはそれは大変だった。また、人の入れ替わりも激しい。せっかく知り合えた人々も別のところへ行ってしまったり、新たにやって来た人々とお知り合いになれたり…。新しくやって来た人たちもきっと、似たような苦労をするはずである。ならば、その苦労を減らす事は出来ないか？役に立つか未知数だけれども、そんな思いで作ってみたのが、この「ピーナッツを探せ!」である。

まだまだ、利用者は少なく、ほとんどがTORITORIの入力したデータである。でも、他の人からの情報も徐々にではあるが集まってきている。ミネソタでの生活に必要な場所の情報共有サイトに育てばいいなと思っている。「ミネソタ○ォカーみたいになればいいね！」なんて励ましの言葉も頂いた。

使い勝手の悪いところも多々あるようで、利用者の増えない原因かもしれない。徐々に改善していくつもりである。ミネソタにいる人以外には関係ない情報かもしれないけれど、観光に来たくなってくれたりでもしたら、それはそれで作った甲斐があるというものだ。そんな事はまずないだろうけど、夢はでっかく語りたい。

スタンプラリーのノリで、街中にちらばるスヌーピー関連の人形の情報も載せてある。これが、このサイトの名前の由来でもある。スヌーピーの原題は「ピーナッツ」だからだ。一緒に集めてくれる人が出たら、これまた作った甲斐があるというものだ。

さて、これはRuby On Railsで作ってある。その生産性の高さには驚かされる。これだけのウェブサイトが人手をかけずにサクサクと作れるのには感動すら覚えた。出来上がったサイトのテストをするための仕組みもちゃんと準備されており、これまた、人手をかけずに動作確認が出来る。仕事の合間にやったにもかかわらず、半月ほどで出来たのだから驚きだ。

ただ、画像を扱う部分はまだ弱く、従来の技術に頼らざるを得ない部分もあり、PHPやPerlなどを使わざるを得ず、不本意ながら勉強する破目になった。（サーバーの設定を自由に出来ないため、そうなった。１００％自分で触れるサーバーなら問題なかっただろう…。）

開発時のサクサク感とは裏腹に、いざ出来上がったサイトを使ってみると、お世辞にも「サクサクで快適！」とはいえない。安いレンタルサーバーだからしょうがないのかな。使っているサーバを速いものに換えればいいのかもしれない。でも、それでは何でも金で解決しようとする悪い大人のようで、いただけない。Rubyというプログラム言語がインタプリターであるのも原因かもしれない。ロジック部分でループを極力減らしたりするなど工夫次第では、多少良くなるかもしれない。いずれにしても、開発人件費を大幅に節約できるだろうから、商用で使うなら、浮いたお金でサーバーにお金をかけるのは選択肢としてありえると思った。

Ruby On Railsでのもう一つの隠れた問題点は、設置である。作ったはいいけど、いざWebサーバーに置こうとすると、一筋縄ではいかないようだ。実は、本職の方でもRuby On Railsで１つサイトを作ったが、Webサーバーに設置できずに放置されたままになっている。サーバ管理者がサボっているのか、一生懸命やっているのかは知らないが、そういう問題もあるようだ。

TORITORI

本来怠けもの

プログラマーに必要な素質、それは『怠けもの』であることらしい。TORITORIは、その例外ではない。めんどくさい事はコンピューターにやらせるためにプログラムを書いている。そして、できるだけプログラムを書き直さなくてもいろいろな事が出来るようにプログラムを書く。上手にプログラムさえすれば、コンピュータは言われた事を何度でも愚直に繰り返す。
Javaというプログラム言語がある。よくデザインされたプログラム言語である。でも、それで作られたプログラムがよくない。プログラマーに怠けさせてくれないのだ。
そんな中、最近Ruby（ルビー）というプログラム言語で書かれたRuby On Railsというプログラムが脚光を浴びつつある。よくデザインされていて、プログラマーをしっかりと怠けさせてくれる。そして、怠けたいがために、プログラムを書く気にさせてくれる。Ruby On Railsを開発した人は、真のプログラマーに違いない。

TORITORI

かめさんのルート案内

おすすめサイクリングイベントで紹介している「ツール・ド・おおすみ」「センチュリーライド上信越」のページをバージョンアップした。写真のように『かめ』さんが軌跡をなぞってコースを紹介してくれる。
なぜ『かめ』さんかって？このおすすめのイベントは、レースではないので、順位も、タイムも関係ない。だから、敢えて『かめ』さんなのです。景色を楽しみながら、制限時間いっぱいサイクリングを楽しめる。どちらのコースも景色は抜群！

さらにもう一つ！イベントではないけれど、おすすめのサイクリングコース。日本人なら、その魅力はわかってもらえるはず。「富士山の一周」だから。これも、『かめ』さんの案内付き。興味ある方はご覧あれ！

こんなホームページを、特に難しいプログラミング知識が無くても、簡単に作れるツール「PictureMap」のバージョンアップ版は、後日、ここでまた紹介の予定。TORITORIワークスで現在仕上げの作業中。データさえあれば、極端な話、ボタン一つ押すだけで作れてしまう。このような旅行先でのサイクリングも、携帯GPSで記録しておけば、このツールを使って、地図に残せ、後でじっくり思い出にひたれる！お楽しみに。

TORITORI

ソースコードは契約書!?

最近、契約書について勉強する機会があった。契約書は、非常によく構造化されており、部分的にも再利用可能なように構成されている。その再利用可能な部品を組み合わせれば、別の契約書が出来上がるわけだが、部品をよく理解しないで使うと、不利な内容になってしまったりする。また、やりたいことが単純でも、契約書自体は長くなる。「誰と誰の契約か？」「契約はいつから始まるのか？」「どうなったら契約が終わるのか？」など、非常に基本的なことまで明文化するからだ。

おや？それって、コンピュータプログラムのソースコードとそっくりではないか。やりたいことが、単純な四則演算だとしても、いろいろとややこしいことを書かなければならない。でも、そういう部分は、共通化されていて、構造化してあるものだ。再利用しやすくなっている。さらに、ソースコードの開発で最も大変なのは、「もしも…の対策」である。これが不十分だと、厄介なことになる。実際、「プログラムを作ると」は、そう言った例外をどれだけ効率的に書き上げるかだといっても過言ではないように思う。
契約書にも「もしも…の対策」がたくさん書かれている。そう考えてみると、ソースコードは、コンピュータと人間の契約書なのかもしれない。この"契約書"の質が悪いと、コンピュータは思ったように動いてくれない。本物の契約書も、質が悪ければ、思ったように事が運ばないかもしれない。どちらも、質が悪ければ、もしものときにひどい目にあうことは間違いない。

TORITORI

グーグルマップ＋GPS×デジカメ写真＝？（タネ明かし編）

数日前、「Google Mapsにマークをつけて、デジタルカメラで撮った写真をマッピングして、ホームページにした」と言う記事を書きました。そのとき、「どうやったのか？」という説明は、先送りにしました。その説明が、この投稿です。

TORITORI ワークスで写真のようなツールを作ってしまった、というのがその説明です。まだ、ベータ版ですから、機能や自由度はとても限られています。しかし、最低限の機能を実装したつもりですので、公開しました。興味がありましたら、使ってみてください。フリーソフトです。難しいプログラミング知識は一切要りません。また、ブラウザとも連動しているので、結果を確認しながら作業ができるのも、大きな特徴です。

携帯GPSを持ってハイキングやサイクリングに行って、デジタルカメラで写真をバシバシ撮る人に是非使って欲しいです。GPSデータとデジタルカメラの写真があれば、あとはツールがほぼ勝手にマッピングしてくれます。詳しくは、こちらをご覧下さい。また、メールで問い合わせいただければ、可能な範囲でお答えします。要望・苦情などもお気軽にどうぞ。この記事へのコメントとしてでもかまいません。

TORITORI

グーグルマップ＋GPS×デジカメ写真＝？

Google Earthに続いて、Google Map APIでも遊んでみた。Google Map APIとは、Googleの地図サービスを利用するためのプログラミング言語みたいなものだ。その地図サービスで提供されている「地図をウェブ上でスムーズにスクロール」させたり、「縮尺も自由に変えられる」などの機能を、自分のホームページでも実現できる。

さて、今回これで、どうやって遊んだかというと、サイクリングしたときのGPSのデータとデジカメ写真を使って、Google Map上に、その軌跡と写真の撮影場所を再現してみたのだ。百聞は一見にしかず、「クライストチャーチからジェラルディン」「オマラマからクウィーンズタウン」を覗いてみて欲しい。左側にある、スライドレバーのようなものを操作すると、拡大縮小する。地図をドラッグすると、スクロールする。非常に直感的だ。地図上の赤い線が移動した軌跡で、その上に赤いバルーンが所々浮かんでいる。そのバルーンをクリックすると、そこで撮影した写真が表示される。何の目印もないようなところで撮影した写真の撮影場所も、これではっきりとわかる。

見事に移動した軌跡上にバルーンが浮かんだときは、ちょっと感動。もう撮影場所がわからない写真とはさようなら…かな？具体的にどうやったかは、またの機会とさせて頂く。

いずれにしても、こんなことが自分のホームページで意図も簡単にできるようなったのも、すべてGoogle Map APIのおかげ。これから、旅行に行くのがますます楽しみになってきた。

TORITORI

St. Paulの気温を掲載

このページの左下に、このようなグラフで、ミネソタ州セントポールの気温を載せてみました。グラフは、ほぼ１時間置きに更新されます。
先週から、比較的暖かい（と、言っても０度近辺ですが…）日が続いております。また、くもりの日は気温の変化が少ないようです。
今年も残り少なくなってきました。まだまだ寒い日が続くようですが、皆様、身体に気をつけて、よいお年をお迎えください。

TORITORI

ヘクトリス

ヘクトリスのPocket PC版を公開しました。PC版を単純に移行しただけなので、まだ使い勝手は悪いかもしれませんが、PDAをお持ちの方、是非お試しください。

TORITORI

画面が崩れるスクリーンセーバー

昔作ったものを棚卸しています。ヘクトリスに続いて第２弾!!

今度は、スクリーンセーバーです。左の写真のように、デスクトップが崩れちゃいます。でも、それだけじゃないんです！崩れた後、遊べるんです。詳しくはこちらからどうぞ。
TORITORI

ヘクトリス -Hextris-

TORITORI自作のパズルゲームを公開しました。その名は「ヘクトリス-Hextris-」。ブロックが六角形で構成されたテトリスです。アイデアは誰のものか知りませんが、昔遊んだ記憶から再現させたものです。

最初は、どこにどうやってブロックがはまっていくのかわからず、難しいのですが、わかってくると、これがいいんです。スルッ、ピタッとブロックがはまっていく快感をお楽しみください。
詳細、ダウンロードはこちらからです。
TORITORI