こんにちは、ニシオカです。
先日、Firefox4が公開されました。
http://mozilla.jp/firefox/
前バージョンと比べると6倍高速化され、
HTML５などもさらに多くの機能が導入されているとのこと。
HTML５、CSS３が一般的になるのはまだまだ先のことかと思っていましたが
徐々に近づいてきたな～と感じてきました。
そろそろ、本格的に勉強しといた方がいいかな～。
それでは。
こんにちは。くさかべです。
先日、swf上に外部のswfファイル（図面）を読み込み、
図面のドラッグや拡大縮小をさせるツールを作成しました。
その際に、マウスポインタとして独自のMovieClipを表示させるようにしたのですが
InternetExplorer内で使用するときだけ、マウスポインタを少し動かすだけで
CPUの使用率が非常に高くなり、ポインタがスムーズに動かない、
という現象に悩まされました。
原因と対応策のメモです。
1.全ての DisplayObject がマウスの動作を拾うため、
オブジェクトが多いと負荷がかかっていた。
→mouseChildren や mouseEnabled を false にし、
不要なマウスイベントを拾わないようにしました
2.読み込んでいたswfファイルがActionScript2になっていた
→AS3に変換しました
この他にもいくつかの改善を行いましたが、主因は2でした。
まだまだ勉強が必要ですね…。
ともあれ、性能改善は手探りで頭を悩ますことも多いのですが、
改善したときの爽快感はたまりません～
こんにちは。くさかべです。
前回、PHPでPDF出力 ということで、Zend_PDF よさそうかも！？と書きました。
今回は、実際に Zend_PDF を使用した雑感です。
良いなと思ったところと、改善が望まれるところを少し。
良いトコロその1、既存のPDFファイルの編集も容易。
$pdf = new Zend_Pdf(); // 新規
$pdf = Zend_Pdf::load(‘template.pdf’); // 既存
と、新規でも既存ファイルからでも、ごく簡単に
ドキュメントのオブジェクトを作成できます。
良いトコロその2、オブジェクトがドキュメントやページ、
フォントなどに整理されており、扱いやすい
ドキュメントにページを追加するといった処理も、Zend_Pdf_Page オブジェクトを作成し
Zend_Pdf オブジェクトの pages プロパティの配列に要素を追加するだけです。
$page = $pdf->newPage(Zend_Pdf_Page::SIZE_A4);
// $page に対する処理をごにょごにょ
$pdf->pages[] = $page;
マニュアルを読まなくても、何をやっているか想像が付きますね。
逆にあまり良くないトコロですが、もともと、日本語が扱いやすそうという理由で選んだ
Zend_Pdf ですが、使用したフォントがフルセットで埋め込まれてしまうようで、
日本語一文字だけ使うような場合でも、一気に5MB近くファイルサイズが大きくなります。
サブセット埋め込みができるようになればいいのですが…。
今後の発展に期待です。
こんばんは。
虫刺され、肩こりにはタイガーバームに絶対の信頼を置くくさかべです。
さて、今日はPHPの関数 session_regenerate_id() で、
先日ハマってしまった問題について、備忘録をかねて。
session_regenerate_id() は、おもにセッションIDが盗み取られることによる
セッションハイジャックを防ぐために使用する関数です。
この関数は、タイミングによっては、古いセッションIDのままリクエストを行ってしまい
セッションが切れたように見えてしまうという問題があることは
session_regenerate_idで検索するとちらほらヒットします。
ですが、やや特殊な状況ではありますが、
先日大いにハマってしまいました。
問題となるのは、セッションをcookieで受け渡し、
session_cookie_domainをサイトルート直下以外の
.htaccessで設定して、IE8（他のバージョンでも再現するかもしれません）で
アクセスした場合です。
このような環境で、まず、サイトルート直下にあるPHPのスクリプトで
Cookieが生成されるとします。（これを「はじめのCookie」とします）
その後、session_cookie_domainの設定されたディレクトリ等にある
スクリプトでsession_regenerate_idを実行すると、
サーバーからは新たなSet-Cookieヘッダが返されるわけですが
これを、IE8では、はじめのＣｏｏｋｉｅとは異なるCookieとして
受け入れてしまい（これを「ふたつめのCookie」とします）、
はじめのCookieを上書きしてくれないようです。
その後のリクエスト時には、同じCookieのキー名で異なる2つのセッションIDを
送ってしまうのですが、これを処理するPHP側は、一つめのセッションID、
つまりはじめにサイトルートで生成されたセッションIDを使用してしまいます。
また、その後session_regenerate_id()を実行すると、
ふたつめのCookieを書き換えてしまいます。
その結果、クライアント側からは、session_regenerate_id()実行後の
セッション変数が保存されないように見えてしまいます。
これを防ぐには、単純にsession_cookie_domainがサイト全体で
共通して設定されるよう、サイトルートで設定するなどするだけでOKです。
最終的にはHTTPレスポンスヘッダを眺めていて気がついたのですが
これはなかなかはまりました…。
非常にまれなケースかも知れませんがsession_regenerate_id()は、
はじめに書いたような古いIDを使用してしまうことも含め要注意ですね。
それでは。
こんばんは。
最近、モヤシとカイワレ大根をヘビーローテーションで食す
スプラウト生活なくさかべです。
今日はEC-CUBEをSSL環境で使用する場合の注意点についてです。
EC-CUBEはHTTP環境とHTTPS環境で同じドキュメントルートを
参照することを前提に作られているようで、
ドキュメントルートが異なるサーバで使用する場合は
HTTP環境とHTTPS環境の間を行き来する際に、
リンクがつながらなかったりする不具合が起こるようです。
問題となるのは、HTTPは /www/ に HTTPSは /ssl/ にアップする
というようなサーバです。
同一のドキュメントルートを参照する仕組みにしている
レンタルサーバが多いため、このような仕様になっているものと思われます。
具体的な修正方法は割愛しますが、
/data/install.php のHTML_PATHの設定を
HTTP環境とHTTPS環境で動的に切り替えるなどすれば対応が可能です。
これは今後オリジナル版でも対応されるといいですね。
それでは。
こんばんは。くさかべです。
サンアットマークのオフィスでは、最近radikoでFM802をかけているのですが、
この間、川本真琴の『１／２』が流れていました。
中学生の時、好きだったなぁ…。
さて、AtomPubについて、後編です。（前編はこちら）
これまでWEBサービスのAPIといえばXML-RPC、つまり、XML形式の伝文で、
サーバー側の手続きを実行する（＝Remote Procedure Call＝RPC）ものが身近でした。
今回は、このXML-RPCとAtomPubの違いについて書こうと思います。
といっても、２点だけです。
1.アーキテクチャの違い
XML-RPCはXMLで記述された伝文を、POSTメソッドを利用してやり取りします。ブログの投稿を考えた場合、XML-RPCはCallするProcedureの引数として
タイトルや本文といった情報を渡すことになります。
対してAtomPubは、GETやPOSTといったHTTPのリクエストメソッドによって
アクションが定義されます。（つまりREST指向ということです）
タイトルや本文などのデータそのものがリクエストボディになります。
HTTPと親和性が高く、シンプルな仕組みといえます。
2.セキュリティ
XML-RPCは、それ自体に認証や暗号化などに関する仕様がありません。ですので、プロシージャレベルで認証を行うことになり、
暗号化も、SSL等で通信全体を暗号化するか、独自に定義する必要があります。
AtomPub では、BASIC認証もしくはWSSE認証が推奨されており、
WSSE認証の場合は、認証情報がSHA1という方式で暗号化されるため、
アプリケーションレベルで意識しなくても、
手軽に安全な認証が可能となります。
利用者にはあまり意識されることの無い部分ですが、
ブログを簡単に更新できるシステム、みたいなものを利用されている方は
それがXML-RPCかAtomPubか、それともまた別の仕組みを利用したものなのか
いちど調べてみられると、この記事の内容も身近に
感じられるんじゃないでしょうか。
それでは～
はじめまして。くさかべです。
入社の順序的には、上からの押さえ込みと下からの突き上げに板ばさみになるはずの中間管理職のはずですが、気楽にやらせてもらっています。（要はただのプログラマです）
今日は、WEBサービス向けのAPIのプロトコルである AtomPub について書こうと思います。AtomPub は Atom Publishing Protocol の略称で、以前は AtomPP と呼ばれていました。
Atomというと、「RSSで使うやつね」とか、「低消費電力のCPUでしょ」とか、「2003年には出来てるはずの…」などあると思いますが、AtomPub は「RSSで使うやつ」の仲間です。
「RSSで使うやつ」は正式には Atom Syndication Format と言い、日本語ではAtom配信フォーマットと呼ばれます。
AtomPub は、前述の通り Atom Publishing Protocol の略称で、日本語ではAtom出版プロトコルと呼ばれます。
その名の通り、「RSSで使うAtom」がブログの更新情報など、サーバからクライアントへの情報の配信に使用されるのに対し、AtomPub は「出版」、つまりブログの投稿など、クライアントからサーバへ情報を送信する際のプロトコルです。
ブログを更新するのには、これまでXML-RPCと呼ばれる仕様に基づいたものが一般的でしたが、最近は AtomPub の対応も広まっています。
Blogger や アメブロ、So-netブログ、はてなダイアリー、livedoor Blog、mixiなどのブログサービスのほか、wordpress、MovableType といったブログソフトもAtomPub に対応しています。
また、マイクロソフトも、Windows Live サービス群の通信プロトコルとしてAtom とAtomPub に注力することを表明しており（2008年初頭の話ですが）デスクトップからブログの投稿が出来る Windows Live Writer はすでに代表的なAtomPubクライアントとなっています。
次回は、XML-RPC との比較という点で、AtomPub の特徴について書いてみたいと思います。
ちなみにポーランドには ATOM というパブがあるようです。お酒を飲みながらボーリングも楽しめちゃうっぽい、素敵な場所です。google.co.uk でぐぐったらでてきました。ポーランド旅行の際にはぜひお立ち寄りください。
それでは。