プログラミング

WordPress で利用していた Amazon Reloaded の代わりを作成するべく調査。適当にRubyでライブラリを漁ってみると、Yoosee さんのAmazon Product Advertising API を Ruby から使うがひっかかったので読んでみる。これならば今回の目的に合いそうだ。

することは単純

1. Amazonの検索フォーム
2. 検索結果を中サイズの画像と、アフィリエイトリンクで出す
3. リンクからSEO用の書名部分を削る
4. できたものを、コピー&貼り付けしやすいように textarea 要素で表示する

70行程で目的のものが完成。ほとんどの部分は、ベタでHTMLを埋めこんだ(今回は自家用かつ小規模なのでこれで充分)行数。

うむ、これならば使えそうだ。

8/15から、Amazon の検索結果を外部から使うAPIが、サービスの秘密鍵を取らないと利用できなくなる。

仕方がないので、まずは Amazon のアフィリエイトのページから、API のキーを取得しようとしてみる。うぇ、これは米国 Amazon で取得だからアカウントが別なのか。別ページに日本語で逐次解説が用意されていなかったら、投げだしていたな。そんなこんなで Access Key ID と Secret Access Key を取得。

WordPress で現在利用しているのはAmazon Reloaded for WordPress。しかし、これは最新のAPI変更に対応していない。仕方がないので他に適当に数個試してみるも、使い勝手が良いものがなかなか無いし、そもそもAPIに対応していないものばかり。

wp-amazon (Amazonリンク生成)も試してみたけれども、何故か検索結果が出ない。

またか、また作るしかないのか。そりゃ、やろうと思えばできるけどねえ。面倒な。

しばらくはテキストのみでAmazonのページで一々リンク生成するしかないか。と思って試してみたら、1×1 のウェブバグ画像が漏れなくついてくる罠。なんだこの行儀の悪いものは。誰か私に素直に画像とリンクを張りつけさせてくれ。

使っていたサービスがエラーしか返さないようになったので、さくっと作ってみる。要求仕様はこれ以上にない位明確なので、設計も実に明快。

横240pxのサムネイル画像と、元ファイル本体へのリンクを作るだけのものを Ruby の cgi, xmlsimple あたりででっちあげて終了。

これで写真がとりあえず復活。

ソースコードは短いのだが、セキュリティ対策を考えずに作った自家製ツールのため非公開とする。流石に職業柄抜けており少々の手間で治るとわかっているものをそのまま出すのは恥かしい。

会社の上司Aの肝煎りで、一日部内で業務を止めてシェルコードに関する集中勉強会をする。

普段は Ollydbg ばかりで、Immunity Debuggerは初めて使ったが、DLL 内のトランポリン用命令の探索がさくっとできるのは便利そうだ。一々ダンプさせてgrepさせていたのが馬鹿のように思える。

そして、今はシェルコードですらインタラクティブ+ヴィジュアルで構築の時代なのか。昔ちまちまと禁止文字を考えながらやっていた時代は遠くなったものだ。まあ、それでも色々と手法は必要なわけで、初心者がすると大変なわけだが…。

知っている知識の実践と確認という点があるとはいえ、色々とためになる時間だった。

高木浩光＠自宅の日記 – Macでは「何回も何回も観てニヤニヤ」がバレる

mdls でファイルを開いた日付の一覧が見えるというので、他にはどんなものが見えるのかを調べてみた。

「Mac OS X システム管理」によると、属性の本体は各ボリュームの .Spotlight-V100 にある。わざわざインデックスを作りなおさせなくても、このファイルさえどうにかすればいいように見える。

ただ、内容的にかなり複雑なようなので変更は mdutil(1) を介せと同書にあった。mdutils を使うと、# mdutil -E / でインデックスの削除&再作成となる等いくつかの操作ができるようだ。

指定できる属性は、Apple の Spotlight Metadata Attributesに詳しい。

共通部分(Common Metadata Attribute Keys)だけでもこれだけあるので、本気で調べれば色々と見つかりそうだ。日付関連だけでも kMDItemAttributeChangeDate(最終変更日), kMDItemContentCreationDate(作成日), kMDItemContentModificationDate(変更日), kMDItemDueDate(到着日?不明), kMDItemLastUsedDate(最終利用日)とある。

• kMDItemAttributeChangeDate
• kMDItemAudiences
• kMDItemAuthors
• kMDItemCity
• kMDItemComment
• kMDItemContactKeywords
• kMDItemContentCreationDate
• kMDItemContentModificationDate
• kMDItemContentType
• kMDItemContentTypeTree
• kMDItemContributors
• kMDItemCopyright
• kMDItemCountry
• kMDItemCoverage
• kMDItemCreator
• kMDItemDescription
• kMDItemDisplayName
• kMDItemDueDate
• kMDItemDurationSeconds
• kMDItemEmailAddresses
• kMDItemEncodingApplications
• kMDItemFinderComment
• kMDItemFonts
• kMDItemHeadline
• kMDItemIdentifier
• kMDItemInstantMessageAddresses
• kMDItemInstructions
• kMDItemKeywords
• kMDItemKind
• kMDItemLanguages
• kMDItemLastUsedDate
• kMDItemNumberOfPages
• kMDItemOrganizations
• kMDItemPageHeight
• kMDItemPageWidth
• kMDItemPhoneNumbers
• kMDItemProjects
• kMDItemPublishers
• kMDItemRecipients
• kMDItemRights
• kMDItemSecurityMethod
• kMDItemStarRating
• kMDItemStateOrProvince
• kMDItemTextContent
• kMDItemTitle
• kMDItemVersion
• kMDItemWhereFroms

kMDItemUsedDate が無いのは、何故だろう。Xcode 3.0 リファレンスマニュアルで MDItem Class を見ても無かった。謎だ。

mixi Developer Center (ミクシィ デベロッパーセンター)

mixi がmixiアプリという名前でOpenSocial対応したとのことなので、試そうとしてみる。どうやら、専用に http://platform001.mixi.jp/ というサイトがあるので、そこに登録&利用する形態らしい。アクセスには別途の登録が必要なので、通常利用の人に利用してもらえるわけではないわけだ。ついでに言えば、goo と比べて若干API側で制限があるらしい。

というわけで、一気に気力が減退しつつも、OpenSocial の API と mixi 提供のサンプルを見比べて色々考えてみる。

アイドレスがらみで色々できると面白そうだなとは考えたのだが、文殊から取れるデータが、検索まではできそうだが国名が無かったり性質上個人ページに誘導できそうにない、などで若干利用するには難しい。藩国個々のページは多彩すぎてフォローしきれない。

おまけに最大の問題として、現在はまだ敷居が高いので対象層に使われない。フィードバックを受けることがなければその場の一発屋で終わる。

まあ、そういうわけで今回はほとんど調べただけ。

仕事で久しぶりに CGI を組もうとして、gems の罠にはまる。

require ‘dbi’ した時だけエラーになると思ったら、gems で入れたものは rubygems を require してからでないと使えないとは。普通にコマンドラインだと何なく実行していたので、無断に半日程はまってしまった。

p2ex を iPod touch で見てみると、きちんと対応しており、メニュー画面からして対応したものになってくれる。内容も、きちんとタップで引用箇所が見えたり、外部を別ウィンドウで開いたりで、なかなかに見やすくてGOOD。

勢いで、WordPress の方も Ktai Style (携帯対応プラグイン)とWPtouchを入れて、モバイル対応にする。Ktai Styleは意図的にiPhone非対応なため、iPhone/iPod touch 用にわざわざ別に入れている。

実際に閲覧してみると、WP-Cache が効いてしまい PC 用の画面のままでうまく見えなかったので、Ktai Style のサイトにあるものを参考に、wp-content/wp-cache-config.php を編集し、$cache_rejected_uri の前にキャッシュ無視判定を入れる。なお、WordPress の管理画面から WP-Cache の設定を変更すると消えてしまうので要注意。

$ua = $_SERVER['HTTP_USER_AGENT'];
if(preg_match('/(iPod|iPhone)/', $ua)) {
        $cache_enabled = false;
        $super_cache_enabled = false;
}

なお、User-Agent の判定は、iPhone/iPod touch のUAが以下になっているとの情報(複数の情報より)から適当にマッチさせている。

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; ja-jp) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile/3A110a Safari/419.3
Mozilla/5.0 (iPod; U; CPU like Mac OS X; ja-jp) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile/3B48b Safari/419.3

無料アカウントでは表示するのが最近200枚までとの事なので、それ以上なら消すかプロアカウント($2/month)を買えということらしい。

Flickr を利用してきた理由は主に3つ。

1. iPhoto から一括リサイズ/アップロードできる
2. コメントをつけて alt や title に反映できる
3. 画像だけサーバを分散することによるボトルネックと転送量の解消

まあ、どれもそんなにたいした理由ではないので、今迄のはそのままにして、今後は WordPress 本体の機能に戻してもいいかな。

と思って iPhoto 用の WordPress Upload Plugin を探してみたのだが、意外に無い。Photonは動かなかった。

妥協するとこんな感じかな。

• export は自前でやる。リサイズも iPhoto で。
• アップロードのみ自動化。
• 貼り付けは今迄通り頑張る。

投稿プロトコルとして、RFC5023 に対応した AtomPub と、MT 等との互換性のある XML-RPC wp が使えるようだ。

…自作するしかないのか?

今回は全部手動でやったが、何故かウェブ上から表示画像がリサイズできなくて困る。しかもこれ、リサイズできたとしても表示画像の幅を変えているだけだから無駄なんだよねえ。はやくなんとかしないと。

仕事で少々ウェブの自動操作が必要となったので、WSH(Windows Script Host)を使ってみる。WSH の本体となる wscript.exe (WindowsXPに普通に付属している)を通じて実行する際には、VBScript, JavaScript などが選べるが、今回は楽したいので慣れている JavaScript を選択。

WSHを始めよう − ＠IT

この連載の第11回にあるように、InternetExplorer Object オブジェクトを利用すれば、とりあえずどこか目的のページを開くところまではできる。

そして、後は JavaScript らしく DOM で適当な a 要素のノードを探して、click() メソッドでリンクを移動。これで、基本的な操作は大体できた。

ちょっと MHTML で印刷したいとかもあったが、調べた結果強引に SendKeys メソッド でキーコードを適当に Sleep を挟みつつ送信するしか無さそうだったので、実行。

うねうねと微妙にIEが自動操作される謎のプログラムができた。まあ…使えればいいか。

ZIP ファイルの作成方法も調べていたら見つけたが、PK の識別子と若干のZIPファイルヘッダを含んだバイナリファイルをテキストファイル扱いで作成、その後 XP の機能で ZIP フォルダとして開いて、入れたいファイルをコピー、という実に漢らしい方法。なんというバッドノウハウ。Windows ではコマンドラインの ZIP を探すのは難しいし、仕方がないのか。

Lookup！ せんせーしょん：次元を超えた画像解析技術——「Deep Zoom」と「Photosynth」を体験する (1/4) – ITmedia +D PC USER

Zooming user interface(ZUI)をSilverLightという商用ライブラリで公式実装しましたという話。元となったPad++からすると十数年、やっと表に出てきたのかという感慨となる。

そのため関連研究も多く、国内でも Apple で iPhone の日本語 UI に関わっている増井俊之氏の LensBar や、高田哲司氏の見えログも、ドキュメントの詳細度をズーミングするという部分において、ZUI の延長線上にあると言える。iPhoneの操作なども一部そうだし、映画「ジュラシック・パーク」で「UNIXならできるわ!」と使われていたインタフェースもこの系列だ。

現在はまだ本当に超高解像度にズームするだけのようだが、元々のZUIの意義からすると、ズームした状態と引いた状態それぞれにおいて UI が動作する状態になってもおかしくはない。

要素技術は既にあり、例えば、Appple の Spaces は画面を分割した上でそれぞれの画面状況を一望できる。これで直接操作さえできれば、1レベルの段階的ZUIと言っても過言ではない。近年やっとOSに実装されはじめた仮想画面だが、元々そういうものをまとめて視点を拡大/縮小しながら取り扱おうというのがZUIである。

インタフェース研究に貪欲でありしっかりとした研究基盤を持つマイクロソフトが出してきたということは、将来の姿についても実験的には考えているのだろう。3D では LOD(Level of detail)という類似技術があたりまえのように備わっている。将来の姿が楽しみだ。

ObjectiveC 2.0 を読みながら、一応現状も見ておこうと、OSX や iPhone で目的となるデータを操作するにはどうすればいいのかという事を調べてみる。

iPhone Dev Center はログインしないと読めないしいろいろ制約つきなので、とりあえず Apple ID を関連付けておいてログイン。

ざっと見たところ、例えばカレンダーは OSX 上で iCal と連携するにはCalCalendar Classを使えばいいらしい。しかし、iPhone のリファレンスを一通り眺めてみたところ、素直にはいかず苦労しそうな感じ。

標準的な機能として iCal と iTunes 経由での連携ができるはずなので、標準で連携がとれておりデータの保持形式も決まっているクラスを使うのが本来は一番楽なはず。これは実際に App Store が出来て、プログラム関連の情報が公表され出揃うのを待つしかないか。現在は Agreement の壁で色々と書くのも読むのも難しすぎる。

情報処理推進機構 安全なウェブサイト運営入門

友人知人に強者が多いのであまり私が紹介しても意味が薄いかもしれないが。一応。

専門家としては、宣伝ウェブやウェブ店舗をある程度メインにして商売をやっているならば、最低限こういうリスクはあるとふまえておいてもらいたいラインが学べるゲーム。Windows 専用。インストール必須。

実際に作る側ならばそれこそ知っていますか？脆弱性 (ぜいじゃくせい)や安全なウェブサイトの作り方でも見た方が良いのだろうけど、リスクを認識するためのとっかかりとして見てみたり、発注側として「このあたりは大丈夫だよね?」と契約に入れておくために学ぶあたりが丁度良いのかもしれない。

雨で外出する気にならないのを幸い、ウェブ上の特集を漁って Cocoa などの周辺状況を学んでみる。こういうチュートリアルとリファレンスの間にある概略的な所は、OSX の構成と言語とフレームワークががっつり噛み合ってできているので、登場時に詳しく解説されている記事を読んだ方がわかりやすい。

【特集】TigerのCocoaにみるMVCの完成 – スマートなデータモデルを実現するCore Data

これを読み終えたら、次は ObjectiveC 自体をそろそろ体系的に学んでみるか。

Objective-C 2.0プログラミング言語

iPhone を買うかもしれないし、そろそろ OSX で不満な点も見えてきたので自作ツールを投入したい。ということで Mac OSX でのプログラミングもやってみようかと、Apple Developer Connection(ADC) の 日本語翻訳からCocoaアプリケーションチュートリアルを試してみる。

どうせ慣れてくれば英語でも問題が無いことは今迄のプログラミング言語体験からわかっているものの、最初のとっかかりから英語は流石にきつい。そういう意味でもリファレンスは訳してくれないけれどもとっかかりは訳してくれているアップル日本の姿勢はまあ悪くはない^[1]。本当は Microsoft のように全部訳してくれるのが一番だが、まあシェアの問題もあるしね。ただ、iPhone まわりの開発を考えるとそろそろ充当して欲しい翻訳はいっぱいある。

さて、私はC/C++の基本的な所は一通りわかるものの、Objective Cの文法はダイナミックObjective-Cの連載で軽く見た程度。実践していないのでわからないに等しい。

そこでついでとばかりに、Xcodeスレを参考に荻原本こと詳解 Objective-C 2.0と、ヒレガス本ことCocoa Programming for Mac OS Xも注文しておく。これでしばらくは遊べるはず。

「Currency Converterウインドウの作成」で Text Field と間違えて Text Field Cell を使おうとしてしまい「あっれー、ドラッグで配置できない」と無駄に悩みまくる。勘が働かない新しい環境だと仕方がない範囲の無駄作業というところか。

しかし、インタフェースの配置で推奨インタフェースに沿ったガイドライン線が出るのは有り難い。自然と配置が整列できるので、自然と見た目も美しくなるし、ユーザインタフェースにおけるボックス配置とアライメントを考える良い機会になる。デザインの基本となるベースラインによる整列と近接配置の概念さえおさえておけば使える便利さが素晴しい。

「コントローラとビューの相互接続」の箇所が微妙に罠。

ライブラリで、オブジェクト項目をMainMenu.nibウインドウへドラッグします

これが「ライブラリ」の「Object」の事だったとは…訳すなら統一して欲しい。ConverterController.h を読みこませても目に見える反応が無いのにも騙された。

インタンスメソッドの宣言が – で初まるのにとまどってバグの素にしてしまったりしながら、なんとか最後までビルド完了。確かにGUIな基礎部分はほとんど Interface Builder でできることがよくわかった。しかし、IB からコードを触るようなパラダイムではないので、そういう意味ではしっかりと MVC を意識しまくらないと辛いようだ。

あえて比較するならば、Ruby On Rails では命名規約で Controller と Model, View の繋りを暗黙のうちに規定できるようにしているが、Cocoa では流石にウェブと違い適用範囲が広いのでそんなに甘くはなく、宣言だけコード側ですませておいてから IB で繋げまくる必要がある。まあ、それもGUIですっきりはっきりできるのが利点か。

とりあえず、Objective C のメッセージによる通信と、実行時の型確定によりかなり色々できそうな雰囲気はよくわかった。次あたりは何か小規模なものを一つ習作として作り潰してみて、それから本題に行くとしよう。

1. OSX の起動時に Unix 系のデーモン1つつっこもうとするだけで、英語と格闘になるけどねっ orz [↩]