サーフィンや写真、ブログ・ネット技術、Macのブログ

2008年8月10日

Plagger でサーフィンの波情報を収集

8月は夏本番、そして9月には台風シーズンと、サーフィンのハイシーズンに突入。毎日の波チェックは欠かせませんが、引っ越しをして部屋からは海が見えなくなってしまった。ので、Plaggerで各種の波情報を取得して、毎朝 Gmailに送信するようにしてみた。サーフィン関係のサイトは、未だにRSS対応していないところが多いので、Plagger 最強。

plagger-kishou.pngplagger-mapion.png

波情報の収集先は以下のような感じ。

Plaggerのインストールは、この辺りの記事を参考にどうぞ。

CPANから標準インストールする以外で利用したPluginは、CustomFeed::Config と Filter::StricScript ぐらいかな。追加で入れたモジュールは以下。

yaml設定ファイルは、以下のような構成になりました。基本的には、CustomFeed::Config あるいは Filter::EntryFullText でサイト上の情報を取得して、Gmail に送信する。ファイル名をクリックすると、各設定ファイルの中身を表示します。

あとは、Plagger の実行をCronに登録して、毎朝、波情報がメールに届くようにする。

# cronの設定を見る
 $ crontab -l

# cron設定を編集
 $ crontab -e

Viが起動するので、以下のように編集。

PERL5LIB=/usr/lib/perl5:/usr/lib/perl5/site_perl

0 5 * * * cd /home/user_name/plagger/config.surfing ; plagger -c yahoo.yaml > /dev/null
1 5 * * * cd /home/user_name/plagger/config.surfing ; plagger -c mapion.yaml > /dev/null
2 5 * * * cd /home/user_name/plagger/config.surfing ; plagger -c kishouchou.yaml > /dev/null
3 5 * * * cd /home/user_name/plagger/config.surfing ; plagger -c tide.yaml > /dev/null
0 7 * * * cd /home/user_name/plagger/config.surfing ; plagger -c shounan.yaml > /dev/null
0 20 * * * cd /home/user_name/plagger/config.surfing ; plagger -c tatado.yaml > /dev/null

Posted by jun at 16:31  個別ページ | コメント (0) | トラックバック (0) | delicious_s.gif b_entry.gif はてなブックマーク
2008年8月 6日

新しいDelicious の使い勝手を改善する UserScripts 色々

元祖ソーシャルブックマークのDeliciousが、最近バージョンアップして新しく。ただ、今までの慣れていたユーザビリティが微妙にかわった部分もあるので、使いやすくするためにGreasemonkey用の、Userscriptsをいくつか追加。

ほかにも使わなかったけれど、Delicious2.0対応で、こんなスクリプトもあるよう。

ちなみに、Delicious :: Firefox Add-onsも試しにインストールしたけれど、ちょっと僕の環境では重すぎるようでアンインストール。UserScriptsぐらいがちょうどよいかなと思いました。

Posted by jun at 07:42  個別ページ | コメント (0) | トラックバック (0) | delicious_s.gif b_entry.gif はてなブックマーク
2008年8月 1日

O'Reilly のOSCON考察に見る、プラットフォームのオープン性を評価するポイント

AmazonのS3, EC2 や、Google AppEngine などのCloud Computing と、オープンソース、オープンデータについてのO'Reillyの考察。OSCONで感じたインスピレーションにもとづいていて面白かった。

以下は要約ではなく感想も含むので、ぜひ原文を。

まず Linuxなどのオープンソース・ソフトウェアが無かったら、クラウド・コンピューティングは成立しえない、というのは確かにその通り。商用ソフトウェアのライセンスでは、クラウド・サービスの提供者が、利用量に応じた課金プランなどを独自に設定できない( or しずらい)。オープンソースのスケーラビリティの上で、クラウド・コンピューティングのビジネスは成り立っているわけだ。

ただしクラウド・コンピューティングは、あくまでも商用サービスなので(例え無料であっても)、どこまでオープン性が担保されているかの評価が必要。一般的に『オープンなプラットフォーム』といっても、以下のようなオープン性の違いがある。

  1. 秘密保持契約を結んだ開発者のみが、審査後にアプリを、プラットフォーム上で公開できる( 携帯公式サイトなど)
  2. 一般に公開されている仕様にそって、誰でもアプリを開発し、プラットフォーム上だけで公開できる( Facebook Platform など)
  3. 一般に公開されている仕様にそって、誰でもアプリを開発し、広くインターネットで公開できるが、プラットフォーム上のデータは引き出せない( 独自の認証APIなど )
  4. 一般に公開されている仕様にそって、誰でもアプリを開発し、プラットフォームのデータを利用しつつ、広くインターネットで公開できる( Google Maps API など )
  5. WEB標準の仕様にそって、誰でもアプリを開発し、プラットフォームのデータを利用しつつ、広くインターネットで公開できる( ブログのAtomPubなど )

こうして見ると、あるプラットフォームのオープン性を評価するポイントとして、 大きく以下の4つがあるのだろうか?

  1. API仕様が、一般公開されている
  2. API仕様が標準にもとづいていて、アプリケーションが他のプラットフォームでも動作する
  3. アプリケーションを、プラットフォーム外のインターネットで自由に実行できる
  4. プラットフォーム内のデータを、自由に利用、公開できる

API プラットフォームや、クラウド・コンピューティングを利用する場合には、この点から評価をしつつ、自分の開発リソースを投下する場所を選ぶことが、アプリケーションの自由を保障するために重要なのかもしれない。

Posted by jun at 22:13  個別ページ | コメント (0) | トラックバック (0) | delicious_s.gif b_entry.gif はてなブックマーク