スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

アットマークITリーダー for ruby

Javaで書いたプログラムをrubyに移植してみた。

JavaだとJakarta関連の依存ライブラリが多すぎて、手軽に入れることはできないので何とかしてスクリプト言語で作りたいと思った。(まあ、そこまで熱を入れて読みたい記事はあまりないのだが)

HTMLの取得・パースやイメージの取得に、Javaでhttpunitを使ったように、rubyでWebUnitを使ってやりたかったが、どうもうまくいかない。仕方がないので、net/httpを使って、htmlからリンク先の取得については自分で書いた。なので、最初はリンク先が相対パスになっていたりしてエラーを出したりした。自分で組むとそういうケースにも全部対応しないといけない。

Javaで書いたロジックをそのまま移行し、rubyの習得もままならない状態だったので、Javaとの違いで苦戦した。どんな簡単な言語でも、空き時間に適用にやるよりも2,3週間ぶっ続けでやらないと使えるようにはならないと思う。慣れると、Javaよりも短く書けるようになる。ただし、短く書けたからといって、生産性が劇的に高まるとは思わない。

Javaで書いたときよりも機能を追加した。取得するカテゴリを選択できるようにした。というかJavaで使っていたRSS Readerが0.91までの対応で、rss0.91にはカテゴリが入っていなかったからなのだが。

rubyのバージョンは、1.8.4、依存ライブラリはRSS Parserで以下からダウンロードしてインストールする。
http://www.cozmixng.org/~rwiki/?cmd=view;name=RSS+Parser

プログラム本体は、以下からダウンロードする。
atmark.rb

1ファイルだけで、設定等は直接このファイルを書き換える。
BASE_OUTPUT_DIRを指定し、取得カテゴリ(CATEGORY_ACCEPT)、拒否カテゴリ(CATEGORY_REJECT)を指定し、
ruby atmark.rb
を実行する。
ruby c:\hoge\atmark.rb >>c:\trash\at.log 2>&1
こんな感じでバッチを作って、
at 18:15 /every:M,T,W,Th,F c:\hoge\atmark.bat
at 19:15 /every:M,T,W,Th,F c:\hoge\atmark.bat
でスケジューリングする。
Linuxの場合は、cronで。

不具合があったらコメントください。
あまり需要はないか。
rubyのプログラムの参考にどうぞ。手続き的で、オブジェクト指向的じゃないので、今度リファクタリングしようかと思う。ファウラーの教えに従って、temporary変数は極力削除した。次はクラスの抽出かな。これをもう少し他のコンテンツの取得にも使えるように変えるか。

改変は自由です。

スポンサーサイト

トリッキーなコードと芸術的SQL

少々、SQLを理解できないプログラマをこき下ろしすぎたので、ちょっと訂正。

SQLが嫌われる理由の一つには、時々難解で非常に長いSQLを書く人がいるというのがある。芸術的SQLとも言われるもので、書いた本人でないと理解が難しい。

とはいえ、これはSQLに限らず、あらゆる言語でトリッキーな書き方があり、C言語なんかは難解なコードを書くコンテストがあるくらいで、そういうトリッキーなコードを書ける人こそ、真の○○使いとも呼ばれる。

しかし、自己満足に浸るのではなく、他人がメンテナンスすることを考えて、わかりやすいコードを書く必要もある。
一般にわかりにくくなるのは以下の場合があるだろう。

1.トリッキーな記述
 今述べたもの。

2.言語本来の記述
 あらゆるプログラミング言語は、代入、計算、制御、手続きなどの要素からなっているとはいえ、それぞれの言語には流儀がある。
 またそのスタイルにおいても、べた書きのソースコードは上から眺めていけばよく、それに慣れている人は、機能が分割され、実装内容を追うためにモジュールを追っていかなければならない構造化プログラミングは読みにくく、またカプセル化・ポリモーフィズムのあるオブジェクト指向プログラミングはさらに読みにくい。メソッドの内容を見たいと思っても抽象メソッドばかりで、ソースを追っていくのが大変に見える。
 関数型言語も慣れている人にはわかりやすいようだが、他の言語に慣れていると解読は容易ではない。特に書くのは楽だが読むのは書いた本人でないとつらいようだ。
 SQLも言語の一種であり、多様なプログラミング言語があることを考えると、SQLだけを仲間外れにする必要はないと思う。

3.他人のソースは読みにくい
 概して他人の書いたソースは読みにくいものだ。

読みやすいソースは、整形され、変数やメソッドの命名がしっかりしており、何の処理をしているか明確なブロックから構成されているものだ。
しかし、ロジックがわかりやすいかどうかの判断基準はどこにあるのか。

わたしは、
開発をもっと楽にするNAgileの基本思想
のシリーズを興味深く見ているのだが、ソースコードが設計を語るというのは理想的だ。
人間の思考のままにソースを書く。これはいい方向性だ。オブジェクト指向は思想としてはその方向を目指していた。関数型言語も人間の思考にマッチしている。しかし人間の思考は同じか。
深い論理的思考ができる人と、すべて直感的というか感情的に処理する人の思考は異なる。

話をSQLに戻すと、どこまでがわかりにくいSQLか。
そもそも高級言語が登場したのは、わかりやすさや保守性を追求し、処理性能を気にしなくてよくなったからである。
SQLを一回で書く必要があるのは、アクセスのオーバーヘッドを少なくし、プログラム側のロジック、メモリの節約をするためである。

さすがに芸術的SQLはやりすぎだが、とはいえ、どこまでがOKなのかという線引きは難しい。人によってはちょっと条件句や外部結合や副問い合わせを使っただけで駄目になる。わかりやすさのレベルというのは異なる。

わかりやすくする方法としては、SQLを分割し複数発行する、プログラム側でロジックを組む、ストアドを使うとなる。しかし一発でできる場合一回でやりたいのがSQL屋だ。

ところが、ORマッピングが結局可能にしているのは、簡単なSQLをなくすこと。複雑なSQLは直接書け、となる。これは先ほどの問題点の解決志向ではない。コード量の軽減に寄与してもわかりやすさには寄与しない。
もちろん、それはそれで利点であることには変わりないが、本来の目的はそうだったのだろうか。

CachéとSQLの扱い

今日、MCEAのDB研究会で、Cachéについて、インターシステムズ社の人に来て説明をしていただいた。
最近、DB研でCachéについて取り上げ、その有用性について議論していたものの、事例が乏しいため、いくつか質問したいことが出てきた。今回は、Cachéの説明というより、我々の質問に答えていただく形となった。

私の一番の関心事は、Cachéでどのようにアプリケーションを作成するかというところだ。
オブジェクト指向プログラミング、ORマッピングツールの流行で、SQLというのが、オブジェクト指向のコミュニティでは極端に嫌われる傾向がある。最近では、SQLを理解できないJavaプログラマも多いようだ。
Cachéはオブジェクト指向DBなので、データへのアクセスはオブジェクト指向的なアクセスとなる。では、複雑な条件を指定しての検索、SQLで言えば、WHERE句に多くの条件や副問い合わせなどをつけたようなSQLで実現していたロジックはCachéではどのように実現されているのか。何かオブジェクト指向的なやり方があるのか。

答えは、SQLを使うということ。まあ、予想していたとおりだ。オブジェクトが特定された場合のオブジェクトへのアクセスや参照先のオブジェクトへのアクセスは、オブジェクト指向的に行われるが、多量のインスタンスの中からそのオブジェクトを特定するためには、SQLを使って特定するのだということ。
SQLを使わずにダイレクトアクセスのAPIもあるが、それを使うと、SQL1行で済むようなものも、50行ほどのロジックになるだろうとのことだ。

Cachéは、RDBでもあり、オブジェクトDBでもある多次元データモデルだ。なので、OLTP系で有利なオブジェクトアクセスもできるし、DWH系で有利なSQLアクセスにもどちらにでも対応できるということだ。DWH系における検索や分析はオブジェクトには不向きである。

この部分は非常に重要なポイントだと思うのだが、オブジェクト指向派が曖昧にしている点だと思う。私自身、SQLというものは、方言の違いや多少冗長に思えるところもあるものの、基本的にはデータ検索のためには最もシンプルな言語だと思う。

プロセス指向からデータ指向への移行を考えると、まずプロセス指向では、データはプロセスの中にあった。そうすると、データが散在しするため、まずデータを外出しにして一元管理する。さらに正規化の手順を踏んで、冗長性をなくし、データの不整合をなくすようにする。データへのアクセスは標準化されたSQLを用いる。
さらに、DB側で排他制御やトランザクション管理機能、制約を持たせることで、それまでプロセス側で行っていたことの多くをDBMS側に委譲できるようになった。例えば一意制約をDB側で保証してくれるため、プログラム側ではそれほど神経質にならなくて済むようになる。そして絞込みや結合、ソート、集計などをSQLだけで実現するようにすることで、さらにプロセス側の負担を減らした。

このようにして、プロセス指向からデータ指向への移行において、データの重要性を高め、データに関係するロジックの多くを、DBMSとSQLで実現できるようになった。

これと同様のことは、プロセス指向からオブジェクト指向への移行においても起きた。それは、同じようにデータを重視し、データとそれに関係するロジックを一まとめにして扱うオブジェクトという形で実現された。この部分の発想は、データ中心指向もオブジェクト指向も共通しているものがある。なので、設計段階でどちらもドメイン分析をして、データ中心指向ではデータモデル、オブジェクト指向ではクラス図を作成する。

これでいい方向に向かったはずだったが、問題は、データ中心指向で設計された業務アプリケーションに対して、オブジェクト指向言語を適用することで起きた。インビーダンスミスマッチだの、ORマッピングだの、特にO側の人間が騒ぎ出した。

そしてSQLをまともに理解できない糞プログラマが偉そうな口を叩くようになった、というのが現状だろう。

検索や集計では、結局のところSQLが必要なのだ。オブジェクト指向に適合させるため、EJB QLとかHQLとか出たが、SQL以上の利点は特にない。Criteriaオブジェクトを作ったりして、どんなに工夫したってSQLよりシンプルで柔軟にはできない。MSがやっているLINQも、別に画期的なものは何もない。

Seasar Conference 2006 Spring

今日、Seasar Conference 2006 Springに参加した。

DATABASE KNOWLEDGE EXCHANGE 2006も同時開催で、2セッションが同時並行で行われた。後者の方は、ORマッピングを絡めた話題が多く、これは自分の関心のあるテーマだったので参加すべきだと思った。両方とも出たいものが多く、特に最後のセッションは両方とも外し難かったが、Tuigwaaに出席した。

最初に出たセッションは、「PostgreSQLによる、ORマッピングvsSQL+ストアド性能と生産性の比較研究」。「おなじみのDAO屋とSQL屋の議論を実例を交えて」という宣伝に興味を引かれたが、最初はPostgreの紹介ばかりでなかなかORマッピングの話に行かない。あまりPostgreを知らなかったのでこれはこれで参考になった。発表者の方は、開発で、DB関連で問題が起きたときに呼ばれることが多いそうで、そのときの経験からDAO、ORマッピングについての問題点について指摘した。
パフォーマンスやロックやメモリ不足などの問題など。また、ビジネスロジックはインプットとRDB内で実行で、Java側にロジック部がいるのは、人や装置など外部への対応や負荷軽減のためだという指摘は、私も同意見だ。SQLに慣れている人間にとっては、SQLはシンプルに見えるし、そこでできることをわざわざJavaのビジネスロジックで行うのは馬鹿げているように見えるのだ。ORマッパーが話題を独占する中、この辺の問題の認知は一般的に低いように思える。
他の人とも話して同意見の人が多かったのは少し安心した。

次は、「今さら人には聞けないDI入門」。DIの考え方について、寿司のたとえを交えながらわかりやすく説明してくれた。通常フレームワークが用意したクラスを継承してロジックを書くことが多いが、そうではなく継承の代わりにPOJOを使う意味など。現在のS2ではさらにフィールドインジェクションを使ってさらにシンプルに書けるそうだ。私は、どうせロジックの再利用なんてしないんだから、DIなんて大げさなこと言わないで、ロジック用の共通の親クラスを作って、リフレクションとオブジェクトのプーリングを使って子クラスを切り替えるので十分じゃないかと思っていたが、少し勘違いしていたようだ。

次は「DBを256倍活用する方法」でS2DAOの説明。PHP5にも対応したようでサンプルはPHPのものだったが、考え方はJava版も、.NET版も同じ。オブジェクト派にもSQL派にもどちらにも使える人気製品。

ただ、思うのだが、プログラマと名乗るなら、SQLぐらい簡単にマスターしろよって思う。若干アルゴリズムの思考とは違うものの、パズル的な要素があって十分プログラミング的だと思う。もしSQLがわからないとすると、そのプログラマは基本的なアルゴリズムすら組めないんじゃないかと疑ってしまう。

早く終わりそうっ立ったので途中からSOAの方に参加した。S2Axis, S2JMS, S2Buriを組み合わせてSOAを簡単に構築する。S2Buriについてもう少し詳しく知りたいと思う。

次は「Tuigwaa劇場へようこそ」。今回のConferenceの一番の目玉だったようで、羽生さんの「Activity Based Datamodel」とどっちを見るか悩んだが、「楽々ERDレッスン」の本を読めばいいとのことだったので、Tuigwaaの方に参加した。羽生さんの方はテーマも面白そうだったし、話すのがうまい感じがしたので、ぜひとも聞きたかったが残念。

Tuigwaaは、プログラミングの知識を持たないエンドユーザが、手軽にDBを使用したWebアプリケーションを作成できる、というもの。今回のConferenceのアンケート画面を作るデモを実演してもらい、出来が非常によかったので驚いた。自動生成アプリについては最近興味があるところだったので、結構感心した。
おそらくこのレベルのアプリケーションで食べているPHPプログラマなんか少なくはないと思うので、これがまともに広まったら職を失うんじゃないかと少し心配した。まあ、自動生成なのでできることは限定されるので、どうしてもカバーできない部分で開発は必要になる。これをコアにして周辺を、プログラマが必要な部分だけカスタマイズしてプログラムを追加するようになるのではないかと思う。あとでスピーカーの方と話をしたが、将来的にそうできるようにするそうだが、一方で自動でできる範囲をどんどん広げていくそうだ。そうなるとRailsよりもインパクトがあるんじゃないかと思う。

この後は、懇親会で、ひがさん他いろいろ話ができた。ひがさんは来週のサンフランシスコでのJavaOneでSeasarについて発表するそうだ。
なかなか充実したConferenceだった。次回は11月に行うそうで楽しみにしたい。

アットマークITリーダー

@ITは定期的に読むようにしている。
以前に比べて読み応えのあるものが減ってはきているが。

基本的に平日の6時以降に興味あるものを順次クリックして帰りの電車の中で読んでいるが、この手間は面倒だ。
何とかして自動化したいのだが、RSSリーダだと各トピックの最初のページしか持ってきてくれない。AutoPilotだと、余計なものも持ってきてしまう。

なのでこの辺はプログラムを組んで必要なものだけ持ってくるようにする。
やはり、プログラムを組めるとこの辺が武器になる。できないと、与えられたソフトの機能の中で使うしかないが、プログラムを組むと柔軟に無駄なく要求を実現することができる。かゆいところに手が届くわけだ。

どうするか考えたが、RSSを取得して、自分の必要なカテゴリの記事だけをダウンロードする。@ITの記事は、複数のページがある場合、終わりが01.html, 02.htmlあるいは_1.html, _2.htmlとなっているので、自動的にインクリメントして、NotFoundが帰ってきた段階で終わりにする。

さて、実装だが、Javaではやったことがあるので、Rubyで組もうと思った。いろいろ探しているとWebUnitが使えそうだとなった。net/httpでもできそうだが、htmlのパースはこれではできない。JavaでやったときはHttpUnitを使った。これはJUnitのWeb版だが、これはWeb巡回アプリの作成にも好都合だった。HTMLのパースができるものを使えば他でもよいのだが、あまりよく知らない。
RubyのWebUnitは、Ruby版のHttpUnitのようで、同様に使えるかと思ったが、ドキュメントもサンプルもきちんとそろっていなかったようなので、とりあえずパス。
結局、慣れているJavaで作ることにした。

とはいえ、前に作ったソースは2年前で、ちょこちょこと作ったのでソースは汚い。どうやって使うのかぐらいは書いておけよ>過去の自分

確か、通常の巡回ソフトでは物足りないから作ったはずだが、何の目的で作ったのかわからない。参照している設定ファイルをようやく見つけた。参照しているURLを見ると、どうやらアダルトコンテンツを効率よく持ってくるために作ったようだ。それだけじゃないと思うが。(^^:

そのリンクをクリックすると、まあ、リンク切れだろうと思ったが、業者サイトにつながった。リダイレクトするかと思ったらURLはそのままだ。どうやっているんだろうと思ったら、単にフレームを使っているだけだった。こうして正規のサイトのように見せかけるわけか。

RSSを読み取るツールぐらいどこかにあるだろうと思ったが、すぐに見つかった奴はVersion 0.91までしか対応していない。0.91だと日付もないし、atmarkitからlastModifiedヘッダもついていない。仕方ないのでrssのサイズを前回と比較して、違っている場合に巡回するようにした。
とりあえず無駄なファイルを極力ダウンロードしないようにして完成。これで平日の6時以降に数回実行するようにスケジューリングしておけば大丈夫だろう。

PS.
あまり綺麗なソースじゃないし、オブジェクト指向的でもないのだが、リクエストがあれば公開します。ま、あまりニーズはないか!? ちょっと必要とするAPIが多いかな。

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。