トップ «前の日(07-24) 最新 次の日(07-26)» 追記

2005-07-25

_ DUOGATE

http://duogate.jp/

ノーマークだったのでメモ。au と excite の作った duogate.

ケータイライフがもっと楽しくなるPCポータル

だそうで。ここで公式、非公式サイトの検索ができるので、QRコードもこれもある今、公式サイトって課金の仕組みを丸投げできる以外にはもうメリットないのかも。

Tags: Web

2007-07-25

_ ふと思い立って JRuby

あるいは StuffIt Expander はやっぱ腐っていたのか、の巻。

Widget の話で、あーやっぱクロスプラットフォームな GUI ツールが作れたら便利だよなーと思い出し、夜中に夢の中の何かにえらくむかついて目が覚めたこともあって昨日はふらふらと XUL とか調べていたんだけど、Firefox とか Thunderbird が入っていても XULRunner は別途必要なのかー、面倒くせぇなぁとか、つか XULRunner の Firefox 2.0 に対応するバージョンて contrib しかねーよぉとか、釈然としないものを感じておったわけです。

今回は Y! Widgets のときに思い知らされた、「GUI アプリは IDE の支援がねーとやってらんない」という考えをベースに eclipse との関連を調べていたので、そこでハタと SWT を思い出す。SWT って Java 以外で使えねーの?とか調べ始めたわけですけど、

そういえば最近 JRuby 1.0 出たじゃん

ということを思い出し、JRuby + SWT の組み合わせで遊んでいる人がいないか探してみる。

いるいる。

でも JRuby って Java のいくつを要求してるのか分からん。どこを調べても Java のバージョンに言及している記述が見つからない。おいおいおいおい。基本じゃないんですか、そういう情報って。もしやと思って ports の Makefile を覗くと 1.3 以降と書いてあった。おぉ、こんなところに情報が。つか表に書けよ。本家もニュース記事書く人もこういうとこサボっちゃダメ。

よーし安心したのでやってみようということで JRuby - Home から tar玉を落としてきて、展開、環境変数を設定して、、、

あれ? 動かないよ?

散々試したけどうまく動かない。しょうがないので jruby という shell script を読むと、lib/ の中の *.jar ファイルを必要としている様子。見てみる。ねえ。おっやー? 同じところから jruby-complete-1.0.jar を落としてきて置いてみる。

動きゃしねえ。

ということで昨日はここで挫折。今朝はなんか、昨日の昼間蚊に刺されたっぽいおなかが妙にかゆくて目が覚めた*1のでやり直してみる。やっぱ lib/ の中身がおかしいよなぁ、というところでもしかして StuffIt で展開してるのがまずい?と思いついてコマンドラインから tar zxf してみる。

キター。

$ jruby -v
ruby 1.8.5 (2007-06-07 rev 3841) [ppc-jruby1.0]

ばーかばーか StuffIt Expander のばーか。

Swing のサンプルを起動してみる。やっぱ起動おっそいなぁ…。まだ SWT は試してないけど、とりあえず選択肢は増えた。つか SWT 知らんけど。

Tags: OSX Ruby

*1 ここんところちゃんと朝まで寝れてない

_ Trac Ticket レシピとかあったらいいな

Trac の ticket システムは結構ステキな仕組みで、milestone 管理の際に出てくるあの進捗度合いを示すバーが伸びていくのを見たいがために、積極的に ticket を発行してタスクをやっつけてやるぞという気にさせてくれる。

あれだ。テストドリブンでオールグリーンを目指すのとおんなじ。

でだ。これって実は割と応用範囲が広くて、いろんな仕事をこの ticket システムで運用できそうな気がする。近頃流行りの lifehack だの GTD だのという単語そのものにはそれほど興味はないが、いちいち Excel や Wiki でうんうんと表を書いて管理するより ticket をほいっと発行してしまえば一覧は [ View Tickets ] の report 機能や custom query(このインターフェイスも親切でイカす)であれこれ眺めることができるので、圧倒的にこっちのやり方の方が冴えてると思う。*1

ただ問題は ticket のカスタマイズをどうしようってところで。デフォルトの ticket と Web から設定できない現在*2の Trac の標準状態では面倒くさくなってしまいやすいので、これを放置して単なる ViewCVS 代わり + Wiki みたいに使ってしまうケースって、実は多いんじゃないかという気がしている。というかうちはまさにそうでした。

最近やっと時間がとれたので WebAdmin plugin を入れて ticket のカスタマイズをしてみているんだけど、component と milestone の設定次第で結構やれそうという感触を得つつある。逆に言うと難しいのもここなんだけど。

今ほしいのはシステム管理向けの Ticket の雛形。開発であればプロダクトによって milestone も component もマチマチになってくるとは思うんだけど、システム管理であれば利用しているクライアント OS や提供しているサービスが component に該当して、あとは細かいハードウェアとか、そういう感じで整理できるような気がしないでもない。

例えばネットワークサービスであれば

  • smtp
  • pop
  • http
  • dbms
  • dns

とか。あーでも分けない方がいいかもなぁ。とか悩んじゃってる。まぁこれも管理するシステムによって違うか。

小規模で個々のサーバが別々のサービスを担当している場合はサーバ単位に component を切り出すのがいいだろうけど、大量のサーバが同じサービスを受け持っている場合はサービス単位で component を作っておいた方が見通しよさそう。

業務支援系のツールを作り込んでいる場合も悩ましくて、これは本来システム管理のプロジェクトに入れるべきだと思うんだけど、数が多くなってくると component がゴチャゴチャし過ぎちゃうかなという気もしないでもない。ただ、Trac 0.10 から InterTrac という仕組みが用意されているので、とりあえず丸ごと突っ込んでごちゃごちゃしてきたら分割も視野に入れましょう、というアプローチでもよいような気がしている。

そこまで分かってんならダラダラ日記書かずに仕事しろよというご指摘はごもっとも。でもこういうノウハウってどこかで共有できないかしらん。とか思ったりもしてます。


ひとつ分かった。

ticket の component を考え始めたら svn の repository の分け方を変えた方がよいと思った。今の分け方は細か過ぎる。もっと一緒にしておくべきだ。

なるほどな。こういう風に別な視点で全体を眺めると、今まで見えてなかったことが見えてくるんだな。

Tags: Sysadmin Trac

*1 どうしても Excel にしたけりゃレポートのリストを CSV や TSV で吐き出せるので、それを読み込んで好きに加工したらよろしい。

*2 0.10.4現在

本日のツッコミ(全2件) [ツッコミを入れる]

_ tamoot [こんなところにJRuby+SVNの記事が・・・・]

_ wtnabe [落ち着くんだ! SVNじゃなくてSWTだし! 動かしておしまいだし!]


2018-07-25

_ ActionMailerで送信依頼の結果を取得する

ActionMailer→Mail gemには実はサーバのresponseをそのまま返すオプションがある

ドキュメントには全然情報がないんだけど、ここ。

Mail gem

 class SMTPConnection
   # Send the message via SMTP.
   # The from and to attributes are optional. If not set, they are retrieve from the Message.
   def deliver!(mail)
     envelope = Mail::SmtpEnvelope.new(mail)
     response = smtp.sendmail(dot_stuff(envelope.message), envelope.from, envelope.to)
     settings[:return_response] ? response : self
   end

まずdeliver!メソッド、そしてreturn_response: true

deliver を deliver! にすると

  • ログにメールの内容は出力されない

これだけで log に sensitive な情報が残ってしまう問題を避けることができる。

そのうえで

この辺を参考にすると、

  • Configuration で return_reseponse: true にするとサーバの返事を取得できる
  • その際、エラーも生で扱うことになるので raise_delivery_error などの Rails の機能の恩恵には預かれなくなる

例えば送信時のサーバの返事が取得できると何が嬉しいのか

エラーかエラーでないかだけを気にしているのなら返事は wrap されている方がよい。そうでないと status を見てエラーかどうかを見て、エラーでない場合は返事の構造がこうなっているので、ここにある文字列を取得して…という部分を生々しく作っていく必要が出てくる。

今回なぜこれを考えているかというと、

SendGrid の送信したメールの内容とその配信記録、状況の追跡を容易にするため

まず、SendGrid から配信されるメールにおいては以下の二つの message id が存在している。

  • ユーザーのメール上で確認できる伝統的な message-id
  • SendGrid での実際の処理に紐づく sg-message-id

そして、送信時のサーバからの response に、今処理を開始したメールの sg-message-id が入っているので、これをもとに処理の状況を追跡することが可能となる。

ということで、目的によって ActionMailer の return_response:true と deliver! を使うことが大事になってくる。

SendGrid Webhook APIとの突き合わせ

SendGrid の sg-message-id は

  • SMTP API であっても Web API であっても送信時の response に含まれている
  • Event Wehbook API の中にも含まれている

したがって、

  • メール送信時に sg-message-id とともにメールを記録しておく

と、

  • Event Webhook API からの情報をこの記録と突き合わせる

ことが可能になる。

簡単に言うと、「送信したメールが今どうなっているのかを確認できるシステムを作れる」

ということである。

参考

Tags: Mail Ruby Rails