Ellinikonblue.net Devlosxom

　やるやると言っておきながら、時間がとれず、 ここ も ネタ切れ気味なので、毎度お茶濁しの To Do リストの作成。

絶対やる（…やりたい ^^; ）こと

• GitHub で blosxom 関連の リソース整理・公開
• SNS 系ボタンの配置 CSS 見直し
• Photolog の フレーバー見直し
• Facebook ページの 作成

出来ればやりたいこと

• MODx の バージョンアップとその手順整理
• Devlosxom で 新フレーバー検討、試験実装
• PukiWiki のコンテンツを MODx で 整理して作り直し

やりたいけど多分手が回りきらないこと

• スマートフォン向けフレーバーの検討、実装
• Google AdSence の再研究

いつかね… f^^;

• Google +1 ページの作成
• Javascript ライブラリを script.aculo.us ベースから jQuery ベースへ転換を試験

　げっぷ (-o-;
　あっち じゃなく こっち にあげてる時点で、 さほど実効性はない。
　うん、わかってる orz

　やっぱりうまく動作していませんでした。しかし、プログラムのバグでもありませんでした。

　先般の Product Advertising API の仕様変更の際、さらっと書いてあった 「 2011-08-01 バージョンを除くすべての旧バージョンのサポートを終了させていただきます。」 との下りがくせ者でした。
　bsnap_asin プラグインは Amazon Web サービスへのリクエストの際、 XSLT スタイルシートを指定して、 応答としては HTML を返してもらうところがプログラムの肝なのですが、 このとき、リクエストの際にも、XSLT のスタイルシートにもバージョンを指定していなければならず、 「 旧バージョンでのリクエストはすべて 2011-08-01 バージョンに変換されます。」との 下りもありましたが、少なくとも XSLT スタイルシートを指定しての REST リクエストはいっさい変換されず、 中身のない（ 0 バイトの）応答が帰ってきていました。
　ただこれはこれまで指定したことのない商品を指定したときで、 既に指定したことがあった商品の場合はキャッシュが 0 バイトファイルで上書きされることもなかったので、 気がつくのが遅くなりました。

　結局、既存のキャッシュが更新されなかった理由は今も謎なのですが、 XSLT スタイルファイルを見直して、リクエストするときのバージョンも 2011-08-01 で 統一すれば正常に動作するようになりました。一件落着 (^^)b

　ということで、プログラムの方はほとんど直していないのですが、 PukiWiki の方にのせてるものからは、 ちょこちょこと変わっていますし、今回、 XSLT スタイルファイルも見直しましたんで、 近いうちに更新します。

　XSLT スタイルファイルの見直しの際、以下のドキュメントを参考にさせていただきました m(_ _)m

Ajax の学習なら AjaxTower 「 Amazon Web サービス入門」

　先般、 Product Advertising API 仕様変更があって、 また bsnap_asin プラグイン が 動かなくなるかと戦々恐々としていたのですが、 動かなくなることは幸いありませんでした。
　ただ、まだ確信はないのですが、動作がおかしいような気がしています。

　ちょっと PukiWiki 側に反映していない変更も たまってきたので、そろそろこのあたりで気合い入れて（必要があれば）修正します。

　その決意のテスト用エントリです (^^;

「 CSS の記述が 3 倍速くなる『 LESS 』の使い方」 （ ASCII.jp より）

　最近知った sass (SCSS) で CSS を書くことにはある程度慣れて、自分なりのライブラリを作るとさらに便利になるのでは… と言う妄想と、今、生産物の知識ベースを GitHub 上に持ってこようと、 今必死で時間を作ろうともがいている（のでできてない orz ）最中ですが、 その sass でがちゃがちゃやり始めたときに、 よく LESS と言う言葉を耳にはしたがよく調べもせず、 sass に染まってしまいました。

　sass と LESS 、 何が違うのかは以下の記事がわかりやすそう。

(DxD)∞ 「 CSS 拡張メタ言語『 SCSS(Sass) 』と『 LESS 』の比較」

　JavaScript を仕込めば使えるというのは、 Ruby が必要な sass よりは いけてそうだが、最近はその他にも JavaScript を多用することが多い （特に JavaScript なしではできないことも多い）ので 安易に負荷をクライアント側に振るのはどうかと思う。

　理想を言えばテスト中は JavaScript で、 Fix した時点でコンパイルして使えるのが理想と言えば理想なんですが…

　あと、そういえば Compass ってなに？ f^^;

• LESS « The Dynamic Stylesheet language
• LESS - The Dynamic Stylesheet language （日本語訳）
• Compass Home | Compass Documentation

howtohp 「 CSS 書くなら Compass 使った方がいいよ。 SASS 使ってる人なら特に。」

　本気で取り組むと 宣言して、実験的に、というと格好いいですが、要はおっかなびっくり GitHub を使い始めたのですが、 環境を作り込んでいくうちに、ひょっとすると Dropbox と組み合わせると 非常に便利なのではないかと思い始めました。
　GitHub を使いこなしているわけではないので、 何の根拠もないのですが、 PortableGit なるものを発見したので、 リポジトリを DropboxPortableAHK で 同期するフォルダ以下に作っておけば、 どこでもコードを書いて、必要があればコミットできるのではないかと思うわけです。

　しかし、この方向で熟考していろいろ試して見たのですが、 自宅の固定系環境に通常の Dropbox クライアントと、 Git for Windows で環境を構築してしまえば、 出先でコミットしたいとか言うことはなかなかないのかなと思ったり。。。

　ひとまず、前々からまとめておこうと思っていてやっていない DropboxPortableAHK と、 それでもいろいろ試した PortableGit の仕込み方は、 しっかり むこう 向けのコンテンツとして まとめておいた方が良いでしょう。

　あとリポジトリってどうまとめておくのが美しいのか… まだまだ試行錯誤が続きそうです。