【JavaScript】【CSS】JavaScriptを用いて、読み込んだ外部CSSを操作してみたい

引き続きGoogle App Engine上でアプリケーションを作成しています。
前回のエントリーの地点で画面のレイアウトはほぼ出来ているのですが、一つだけ物足りない点があります。
それは「中央ペインのサイズがリサイズできない」ことです。
私のイメージとしては、右側に幅３００ピクセルの情報表示バーを出して、中央のメイン表示部分のサイズはウィンドウのサイズに応じて自在に変化するようなつくりにしたかったのですが、どうもうまくいきません。

これはどうやらCSSだけではなくてJavaScriptを用いて解決しなくてはならない問題のようです。

JavaScriptをプロジェクトの中で使うときに、一番気になるのが「名前空間の衝突」です。
たとえば今回のケースでは、中央ペインのサイズを変更するJavaScript関数を作るわけですから、「resize_center_pane」とかそういう感じの名前をつけたくなります。ですが、「resize_center_pane」なんてありがちな名前、世界のどこかの人が必ず別の場所で使っているわけです。すると同じ名前で別の関数が定義されますから、妙な動作が起きてしまいます。

これを防ぐために、Javaではパッケージの仕組みがあり、Pythonではモジュールの仕組みがあるのですが、JavaScriptではそういう仕組みが一切ありません。・・・困りました。

と思ったらあっさり問題解決です。
めざせ生涯現役！: JavaScript と名前空間 
なるほど、JSONの記法を用いてJSONでもなんでもなくてタダのオブジェクトの作成時に使う決まり事記法だったみたいです・・・無知ですみません・・・新規にオブジェクトを作成して、その子要素として関数を持たせていけばいいわけですね。

早速真似してみました。

var HBenpitsu = {
	version: '0.1.0',
	author: 'akisute'
}

これでばっちりです！

さて、名前空間の問題が解決したところで、本題の「中央ペインのサイズを制御する」処理に入ります。
まずは右側ペインの横幅を外部CSSで定義します。
あとはwindow.onloadとwindow.onresizeのタイミングで、「中央ペインの横幅を、document.widthから右側ペインの横幅を引いた値にする」処理を追加してやればいいだけですね。
簡単楽勝。さっさとやっちまいましょう。

HBenpitsu.resize_pane_center = function() {
	var pane_center = document.getElementById("pane_center");
	var pane_right = document.getElementById("pane_right");
	var width_pane_right = String(pane_right.style.width);
	width_pane_right = width_pane_right.match(/\d+?/i);
	pane_center.style.width = 
	(document.width - parseInt(width_pane_right)) + "px";
}

ところが
これが
動きません！

Firebugを立ち上げて１行ずつデバッグしてみたのですが、なんと「var width_pane_right = String(pane_right.style.width)」の返り値がnullになっています！そんな馬鹿な！！何度CSSファイルを見直しても間違いなくwidthプロパティは定義されています。困りました。

調べること十数分、原因らしきものを発見です。
[暴満館] JavaScriptによるCSSの操作 
この長々としたソースコードと説明のなかに、
document.styleSheets[ sheetindex ].cssRules
こんな一文が出てきます。CSSを参照しているみたいですが・・・document.styleSheets？
Firebugで参照してみると、あ、あった。



なるほど。外部CSSを参照するときにはこのdocument.styleSheetsを見る必要があって、Element.styleで参照しているのは、HTMLタグ要素のstyle属性だったんですね。勉強になりました。

原因もわかりましたし、外部CSSを参照するにはそれなりにテクニックが必要そうだということもわかりましたので、そろそろ外部JavaScriptライブラリを導入して、問題を解決してみようと思います。

 

【Python】【Django】久しぶりにGoogle App Engine、Templateの自動フォーマットに挑戦

だいぶ間が開きましたが前回の続きです。
Djangoのテンプレートの継承機能を用いて、ソースを書き直します。



イメージを書いてみました。何がなにやらわかりませんが、そこはお手数ですが個々人でイマジネーションを働かせてください。

あとは、Baseとなるテンプレートを拡張した各画面のテンプレートを作成して、
それを読み込んでrenderするだけですね。



うまくいきました！

さて、テンプレートの継承機能を用いるところまでは、Djangoのリファレンスサイトを見ればあっさり終わったのですが、新たな問題が出現してきました。
現在開発にはPleiades Eclipse 3.3のPython開発用セットを用いています。この開発セットにはWTPが含まれていて、HTMLやCSSなどを編集する際にはWTPのHTMLエディタを使用することになっています。ここまではOK。
問題はこのHTMLエディタ、フォーマット機能があまりにもひどいのです。
まともにインデントを考慮してくれず、非常に汚いフォーマットにされてしまいます。



いったいどうしてこんなフォーマットになってしまうのかを探るため、Google先生にいろいろとお尋ねしてみたのですが、満足な結果が得られず・・・
ここで腹をくくって、Eclipse WTPのサイトからWTPプラグインのソースコードを実際にダウンロードして調査してみることにしました。
Eclipse Web Tools Platform (WTP) Downloads 

さて、ソースコードをダウンロードしてきたのはよいのですが、いったいどこを見ればHTMLファイルをフォーマットしているソースを見ることが出来るのかさっぱりわかりません。
悩んでいても仕方がないので、ダウンロードしてきたソースコードフォルダ全体のsrc.zipファイルに対して、"format"という文字列が含まれていないか、サクラエディタでgrepをかけてみることにしました。



ビンゴ！
160件もヒットしました。zipファイルといえどもファイル名だけは普通にテキストエディタで見えるんですね。
いかにもそれっぽいあたりを解凍してソースを読んでみました。
すると・・・

/**
 */
protected void formatNode(IDOMNode node,
        HTMLFormatContraints contraints) {
if (node == null)
    return;

if (node.hasChildNodes()) { // container
    formatChildNodes(node, contraints);
}
else { // leaf
    IStructuredDocumentRegion flatNode 
        = node.getStartStructuredDocumentRegion();
    if (flatNode != null) {
        String source = flatNode.getText();
        if (source != null && source.length() > 0) {
            setWidth(contraints, source);
        }
    }
}
}

・・・え？コレダケ？
ぱっと見た感じ「setWidth()」しかしていません。
要するに・・・文章の横幅の設定に合わせてテキスト全体の折り返しをしているだけ！？インデントの調整とか一切なし！？

なるほど、WTPのHTMLエディタ付属のフォーマット機能は使えねえということだけがはっきりとわかりました。

仕方がないので外部のフォーマッターを使いましょう。
問題はDjango独自のタグ・・・{{}}ですとか{##}ですとか{%%}ですとか・・・が入るので、普通のhtmlフォーマッターは使えないということです。
「django template 整形」とかで検索をかけてみましたが、やはりDjango専用のものは存在しないようです。また困りました。
どうしましょう、自作するしかないのか・・・と考えていた矢先。

急にひらめきが。

「HTMLにHTMLタグ以外のタグを埋め込む＝PHP＝そうだPHPのフォーマッターを使い回せるんじゃないか！」
php 整形 - Google 検索 
PHPスクリプトの基本構造/PHP入門 

さすがは歴史のあるPHP、たくさんフォーマッターが見つかりました。
あとはこの中から改造が容易そうな奴を選んで、PHPタグを判定しているところをDjangoテンプレートのタグに変更してやればよいのです。楽勝楽勝。

とりあえず本日はここまで。
集中力が続かないなぁ・・・寺に行って座禅して修行かなぁ・・・

 

【普通】まずい・・・

しばらく簿記の勉強にかまけてGoogle App Engineを触ってなかったら
基礎基本からほとんど忘れてしまいました・・・
Templateの使い方を思い出さないと・・・

【普通】ソフトバンクからiPhone発売か・・・ねぇ・・・？

3G対応iPhoneは6月発表でソフトバンクモバイルから発売か - GIGAZINE

GIGAZINE情報ですから信憑性は非常に怪しいですが、
確かに、私もでるからにはソフトバンクからの方が確率は高いと思ってます。

CNETかTechcrunchか忘れましたが、ドコモのiモードを設立したお偉いさんが退社されて、彼がドコモのiPhone推進派だったとかなんとかいう記事を見た記憶が・・・
事実だとすれば、今のドコモにはAppleと契約をする気がないと言うことになります。

3G対応するこの機会で日本市場にこないのならば
永遠に次のチャンスは無い気がしますね・・・
ともかく、6月9日を楽しみに待ってみましょうか。

裏切られたら、当分携帯は買い換えなくていいや・・・

【東方】例大祭お疲れ様でした

天気玉の様子が大雨：東方厨を萃める程度の天候でひどく大変な思いをしましたが、
無事地霊殿と緋想天をゲットしました！！
緋想天は今日一日かけて全キャラノーマル全クリまで完了です。

ネタバレしたいんだけどな・・・まぁ、やめておきます。

とにかく緋想天が予想以上におもしろい！
地霊殿はまるで旧作みたいです。後、難易度がそろそろ殺人的です。去年の風神録も相当でしたが今度はもっとひどい。神主は間違いなく我らノーマルシューターを皆殺しにするつもりです。

あとちょっとしたことですが、地霊殿買うときに神主から「いつもありがとうございます」と一言。ああ、さすがに2年間ぐらい毎回通ってたらツラ覚えられてしまいましたか・・・ｗ
なぜか私が上海アリスに並ぶといつも神主から買うことになるんですよね・・・隣の阿Qが気になって仕方ないのに。

【普通】Facebookをはじめました

Facebookが日本語化されたということで、三日前から使い始めました。
なんと言っても世界ナンバーワンといっても過言ではないSNSですし、元々が海外のものですから外人さんたちとの交流も望めます。
それよりなにより同い年のMark Zuckerburgがいったいどんなすごいものを作ったのかと単純に興味がありましたし。

ちょっと触ってみた感想：

• 実名で顔写真付きというのは実はものすごいメリット（Markが文化だと言って強調していたが、確かにその通り。mixiとは違った良さがある）
• Facebookの名の通り、名刺帳の進化したようなアプリケーションと考えればわかりやすい
• Ajaxバリバリの強力なインターフェース（mixiとは技術レベルが1世代違う感じ）
• 無数のアプリケーションを自由に組み合わせられる高レベルなカスタマイズ性と楽しさ（お絵かきチャット機能をつけてみたりとか、自分のブログのRSSをフィードしてみたりとか、ゲームを置いてみたりとか・・・）
• 翻訳がおもしろい、おもしろすぎる。誰でも使える翻訳アプリケーションのできばえは秀逸で、投票システム以外には何ら不満なし

もっと詳細に掘り下げたかったのですが、正直なところまだFacebookのおもしろさの源泉を完全につかみ切れていないので、この程度のご紹介とさせてください。


ということで、リアルでお知り合いの方、一緒にFacebookでお友達になりましょう！
（HN:岸部露伴先生にもご連絡したいのですがメールアドレスがわからなくて・・・もしごらんでしたらご一報ください・・・）
リアルでお知り合いではない方は・・・まずはmixiからと言うことでお願いします！

【普通】社会人1年目の頃にやった情報源を増やす方法

新入社員の方と会話していたりすると、「どこからそんな情報を仕入れたんですか」と聞かれることがあります。
そういえば自分は去年どうやって情報源を増やしたかなぁと思い立ち、
後学のためと、今年の新社会人の皆さんのため（・・・になるかな？）に、ちょっとまとめてみることにしました。
私がとった方法は以下の通り。

1. 先輩方から教えていただいたニュースサイトをRSSリーダーに登録
2. 仕事で調べ物をしている最中に見つけたサイトも片っ端からRSSリーダーに登録
3. RSSリーダーで記事を見ていると、時々有益な個人サイトなどへのリンクがあるので、それもRSSに登録
4. 積極的に連絡してみる

【Python】PythonでXMLを解析してみよう

現在仕事で扱っているシステムは、外部のシステムとXMLで連携したりします。
そのXML電文にバグがあるんじゃないかということで、調査依頼が飛んできました。

昔の自分なら、帰ってきたXML電文を自分の目で比較したりdiffエディタに突っ込んで比較したりしていたことでしょう。しかし、目での比較は文章化しづらく説得力に欠ける（せいぜいスクリーンショットを取って並べる程度の資料しか作れない）ところがありますし、何より面倒です。
しかも今の私にはPythonと言う強い味方がいるのですから、PythonにXMLの解析をやらせましょう。
コマンドラインからファイル名を受け取って、DOMで解析し、特定の名前の要素の値だけを抜き出して列挙するプログラムをささっと書いてみます。

参考にしたページ一覧：
13.6 xml.dom -- 文書オブジェクトモデル (DOM) API
Python でUTF-8, shift_jis, euc_jpなど日本語を使う方法
xml.dom.minidom を用いた XML の取り扱い
Python備忘録 - mynote

ソースコードは↓こちら。

import sys
import codecs
from xml.dom.minidom import parse


def main():
#    for args in sys.argv:
#        print args
#
#    print 'asobiha kokomadeda! xml parse suruze!!'
#    xmlfile = codecs.open(sys.argv[1], 'r', 'shift_jis')
#    dom = parse(xmlfile)
    dom = parse(sys.argv[1])
    nodes_rcode = dom.getElementsByTagName('FareItemNo')
    for node in nodes_rcode:
        print node.firstChild.nodeValue
    
    dom.unlink()


if __name__ == "__main__":
    main()

たったの２０行（本質的に意味があるのは４行！）で出来ました！
ファイルからの読み込み＆パースもわずか１行です。
（Javaでつくるとこの部分だけで１０行超えてしまいそうです）
Javascriptみたいに、getElementsByTagNameが使えるのが非常にうれしいですね。

注意するべき点は、xml.dom.minidom.parse()が、なぜかencoding="Shift_JIS"のXMLを読み込んでくれないことです。IANAにも登録されている由緒正しい？エンコードなのですが、うまくいかないものは仕方が無いので、XMLの文字エンコードをUTF-8に変換してencoding="UTF-8"を指定すればうまくいきました。

あとは、コマンドラインから起動して、結果をテキストファイルに>リダイレクトしてやればOK！

python abesi.py hogehoge.xml > hogehoge.txt

いやー、スクリプト言語はストレス無く使えていいですね。
今回の作業で一番ストレスを感じたのがDOS窓のあまりのシェルの弱さ（TABキーによる入力補完がLinuxのbashに比べると天地の差）だったぐらいですから。

こういうちょっとしたスクリプトをささっと書けると、なんだかプログラマレベルが上がった気になれて自己満足度アップです。

【Java】質問：あなたが一番Javaで嫌いなところはどこですか？

↑こんな質問されたら、
私はもちろん、こういってやるつもりです。

「クラスパスだ、このド畜生が！」

と。
それぐらい私はこのクラスパスと言うやつが嫌いです。むしろクラスパスが好きと言う人がいるのでしょうか。
Java classpath 嫌いの検索結果：1420件
Java クラスパス 嫌いの検索結果：1210件
原因不明な環境系のバグをさらに原因不明にし、結果おまじない的な対応を強いられることになるのも、すべてこのクラスパスと、不可解なJavaのクラスローダの動きが原因に違いありません。

どうして今更こんなことを言うか、ですって？
もちろん、たった今、現在進行形で、このクラスパス関係のおまじないに苦しめられているからです。
たとえばこんな感じです：

• 現在の職場ではStruts1.2.4とTomcat5.0.30を使用しているが、/WEB-INF/lib以下にjasper-compiler.jarとjasper-runtime.jarを「プロジェクトのクラスパスに追加しないようにして」配置しないと、実行時にJSPが動作しない。クラスパスに追加する・外部クラスパスに追加する・ライブラリを移動するなどの処置を取ると直ちに動かなくなる。当然Tomcat側の/common/lib/以下にも同様のjasperライブラリ２種類が配置されているにもかかわらず動かない。完全に原因不明。

• 最初からStruts付属のcommons-validatorライブラリがついてくるにもかかわらず、プロジェクトのライブラリにcommons-validator-1.1.3を追加しないとTomcatがコンテキストの立ち上げに失敗する。完全に原因不明。

もはやこうなると何が原因なのかを切り分けするのも不可能（自分のソースが悪いのかTomcatが悪いのかStrutsが悪いのかJavaのインストールディレクトリがおかしいのか環境変数の設定がおかしいのかetc...）になってしまいます。
その他、ライブラリのアップデートをしようにもなぜかバージョンを挙げたら動かなくなるのが怖いからずっと昔のバージョンを使わざるを得ない、その結果セキュリティホールが残りっぱなしとか・・・

RubyのGemが心底うらやましいです。
Linuxのパッケージ管理（apt-getとかrpmとか）にまったくなじみが無かったころはGemのパッケージ管理の意味がまったく理解できず、「Gem？誰だよこんな意味不明な仕様考えた奴」とか狂ったことを平気で口走っていましたが、本当に申し訳ございません。私が本物の⑨でした。今更言わなくても重々承知ですけど。

Java7でjamなどという機能が増えるらしいですが、遅きに失した感があります。今更出てこられても、「jam導入しましょうよ！パッケージ管理が楽になりますよ！」なんて私が言っても上司が首を縦に振ってくれないんですって。

【普通】胃がよくなってきました

五日間の抗生物質投与が効いたのかどうかは定かではありませんが、
ようやく、胃腸の調子が戻ってきました。