2008.11.17
突然ですが、Pythonライブラリのuamobileを使ってみました。
記事) http://d.hatena.ne.jp/perezvon/20081117/
DL) http://pypi.python.org/pypi/uamobile/
マニュアル的記事) http://labs.unoh.net/2007/08/python_3.html
Django上でこんな風↓に動作確認
# views.py に追加
def mbtest(request):
from uamobile import detect
d = detect({'HTTP_USER_AGENT': request.META['HTTP_USER_AGENT']})
return HttpResponse(
”’<html>”’
”’<body>”’
”’<p>user_agent: %s</p>”’
”’<p>is_docomo: %s</p>”’
”’<p>is_ezweb: %s</p>”’
”’<p>is_softbank: %s</p>”’
”’<p>is_nonmobile: %s</p>”’
”’<p>model: %s</p>”’
”’</body>”’
”’</html>”’ % (d, d.is_docomo(), d.is_ezweb(), d.is_softbank(), d.is_nonmobile(), d.model)
)
地味だけど（失礼）、便利なライブラリですね。
* * *
時に、特にモバイル案件がある訳ではなかったのですが・・・
（起）DjangoでISO-2022-JPでメールが送信できない
↓
（承）MS Outlookでもutf-8でメールが見れるじゃないか
↓
（転）何か困ることあるの？
↓
（転）携帯へのメール送信で困るよね
↓
（転転転）
↓
（結）今日、pypiに登録されたというuamobileでも使ってみよう
・・・と、このような理由らしき理由が無い理由から使ってみることになりました。
今は試して良かったと思っています。
月曜日の集中力の無さがなせる業とも言えますね！
2008.11.10
IEとfirefoxなどのブラウザ間でjavascriptの仕様が違うというクロスブラウザ問題。最近はjQueryなどのライブラリを用いることによって、その違いをライブラリが吸収し、開発が容易になっています。しかし、残念ながら、jQueryを使っても、結構、クロスブラウザ問題にはまってしまいます。以下、そのようなはまった点についてまとめみます。
１．連想配列の最後のカンマ。firefoxだと無視されますが、IEだとエラーになります(例)。分かっていても、ついやってしまいます。
２．width/heightの解釈の違い。前回のブログにも詳細が書いてあります。jQueryのwidth()/height()でもその違いは吸収できません。前回のブログにあるように、DOCTYPEをきちんと指定するしかないようです。
３．z-Indexの解釈の違い。firefoxではz-Indexが最優先なのに対し、IEではz-Indexがhtmlの構造に依存します（参考）。
４．jsonpのレスポンスヘッダ。IEだと’text/html’にすると受け付けません。サーバーサイドで、’application/json;charset=utf-8′などにする必要があります（参考）。
５．forEachやmapなどのjavascript1.6の新機能。基本的にはIEで使えません。IEで使うにはfirefoxのページで公開されてる互換性パッチ（例）をソースに組み込む必要があります。
６．Canvas。IE以外ではデフォルトで使用できますが、IEで使用するには、ExploreCanvasのようなライブラリを読み込む必要があります（参考）。ただし、ExploreCanvasでは多少の機能制限があります。
７．jQueryのeventhelpersにないイベントに注意。特にmouseenter/leaveです。jqueryでbind(’mouseenter’,fn)などで呼び出せますが、IEとfirefoxで違います。IEだとイベント発生のオリジナルの子要素が取得できません(参考)。IEでの子要素取得には、mouseenter/leaveを拡張したjQueryのmouseover/outによって可能ですが、mouseoverのイベントは子要素に入ったとき全てにおいて発動するので、もとのmouseenterと挙動が異なるので注意が必要です。
とりあえず以上です。あと、ライブラリにある関数は一通りチェックして、極力使用するようにしたほうがいいと思います。何かしらクロスブラウザ対応しているので。
2008.09.22
今、javascriptが熱いですね。特に、Google Chromeの登場で、javascriptの性能競争に拍車がかかっています。Chromeのjsエンジンv8では、JITコンパイラ方式を用いており、まさに次世代といった感じです。実際、使ってみるとその速さに驚きます。ブログ界隈をみると、そんなに速くなってない部分もあるようですが、実際どうなのでしょうか？開発中のクラウドマップは今はflashで作られているのですが、今後javascriptで書き換えることも考えています。ここでは、その際に必要になってくるDOM要素のアニメーションに関する性能をブラウザ毎に調べてみようと思います。
まず、簡単なベンチマークサイトを作ったので見てください。
こちら
ボタンをクリックすると多数のDOMが横一列に動きます。個々の要素をそれぞれ動かしてるのではなく、親要素のみを動かしています。アニメーションが終わると、経過時間が表示されます。
各要素は、シンプルなもの(primitive)と、ありがちなシチュエーションとして、各丸ボックスにしたもので評価しました。各丸ボックスはさらに、div要素を多数用いて表現するもの(div corners)、画像1枚で表現するもの(1 image)、4枚のコーナー画像を用いて表現するもの(4 images)で、評価しました。要素のCSS操作にはjQueryを用いています。
以下、いくつかのブラウザで各々評価した結果です。Bestは赤で、Worstは青で示してあります。
Firefox 3.0.1
1.3s (primitive)
12.0s (div corners)
1.3s (1 image)
5.5s (4 images)
Chrome 0.2.149.30
1.0s (primitive)
1.6s (div corners)
1.0s (1 image)
1.0s (4 images)
Internet Explore (IE) 8.0
1.6s (primitive)
4.3s (div corners)
1.6s (1 image)
1.7s (4 images)
Opera 9.51
1.6s (primitive)
2.3s (div corners)
1.6s (1 image)
1.6s (4 images)
（使用したマシンはdualcore 2.2GHz程度です。パラメタはベンチマークサイトにある初期値で設定したものです。ただし、ここでは厳密性はあまり求めていないので、数回の試行平均を取っただけの結果です。また、アニメーションの強制Delayがあるので、純粋な性能評価ではないです）
これを見ると、やはりChromeがダントツに速いです。
要素別で見ると、
primitive<1image<4images<div corners
の順で全体的に速くなっています。
また、Firefoxが、要素の子にdiv要素が多数ある場合(div cornersと4images)に極端に遅くなるという結果になりました。primitiveや1imageではFireFoxのほうがIEやOperaより速いのに、div cornersや4imagesではその逆で、しかも圧倒的に悪いです。これはもう、Firefoxの次期バージョンのエンジン（tracemonkey）に期待するしかないのでしょうか…
2008.09.12
ECMAScript3.1標準化の動きやGoogle Chrome リリース等
更にJavaScriptableな世界になりつつある昨今、いかがお過ごしでしょうか？
そんな激流の中でも、基礎的な部分に関する知識が最も大事ということで
今回はブックマークレットの仕組みについてをまとめさせていただきました。
特に、ブックマークレットについて
・セキュリティ的に非常に危険なシステム
・いつブラウザ側の規制で無くなってもおかしくないシステム
このようなイメージを持っていない方は、読んでいただけるといいかなーと思います。
記事は以下のPukiWikiページ（外部）にまとめました。
→ ブックマークレットの解説
それでは See you arguments.callee!!
2008.09.04
SEO等でよく耳にするページランクですが、その理論を知っている人って意外と少ないのではないかと思って勉強会のネタに取り上げてみました。下は、とりあえずその数学的な面白さが分かってもらえるように作った資料です。
(more…)
2008.08.21
今回は、二分探索法について解説します。
1.逐次探索
通常、n個の配列(list)の中からある要素(target)を調べる場合、次のようにします。
for i in range(len(list)):
if i == target:
return i
return -1 #false
これは逐次探索と 呼ばれます。(線形探索とも呼ばれ
る。)
この方法は単純ですが一般に、データ量に比例して作業量も増えてしまいます。
(more…)
2008.08.08
勉強会は週に1回開催していて、メイン担当は持ち回り制である。
で、このブログ記事を更新するのはメイン担当者の役割だ。
と、ルールを決めた本人が自分の当番を忘れてしまっていて「やべっ、示しがつかない…」と猛反省。
さて、今回はC言語で「変数はメモリ内にどうやって格納されていくのか」のお話。
深いところまで突っ込んでいこうと思ったのだが、文章化すると思ったより長くなってしまったので序論な感じではある。
C言語では、関数内のローカル変数は、関数を抜けると確保していたメモリ領域は開放される。
この時に使われるのはメモリ内の「スタック」と呼ばれる領域だ。
スタックというのは後入れ先出し方式で使われ、その名の通り、後に格納した値から先に使う（解放する）時に利用される領域である。
int a = 123;
int b = 987;
という宣言をしたとしよう。
メモリの下（番地が大きい方）から値が格納されていくので、下図のようなイメージとなる。
├────────┤
│ 987 │
├────────┤
│ 123 │
├────────┤
│ < 使用済領域 > │
└────────┘
(more…)
2008.08.06
さて今回は「テスト仕様書」について…
とは言え、制作歴が長い方にとっては「ごくごく当たり前」の話なんですが。
ただ制作歴の短い…特にWebCGI（特にPHP）しか業務経験が無い方だと、どうも「リリース後に不具合発覚→検証→修正→更新」が容易に可能な環境が多い所為か（Web以外だと納品後の修正は、かなり面倒なコトに…）この辺りに関する意識が甘い方を、これまで何名か見てきてたゆえの話だったりします。
とは言え、わざわざこんなトコを好んで見ている方にとっては、このような話をする必要は無いのかもしれませんがｗ
/////////////////////////////////////////////////////////////////////
さて、テスト仕様書を作り慣れてない方る際、最も頭を悩ませるのは「テスト項目の挙げ方」だと思います。
自分も昔「テスト項目1,000個挙げろ」と言われ、最初は200も挙げられなかったような気がします。orz…
というワケで基本的なテキスト入力１つで、ちょっと挙げてみますと―――
【よくある『名前（姓）』の場合】
- 初回表示時、初期値が空白になっているか
- 半角カナを入れてsubmit
- 半角「￥」を入れてsubmit
- 半角ダブルクォートを入れてsubmit
- 半角シングルクォートを入れてsubmit
- 機種依存文字を入れてsubmit
- shift_jis固有で化ける文字を入れてsubmit
- HTMLタグを入れてsubmit
- JavaScriptを入れてsubmit
- 大量（仕様依存）の文字数を入れてsubmit
- 空入力でsubmit
- エラー判定条件にかかって戻ってきた場合の初期値
などなど。
まぁ、もう少し「半角記号」を細分化するだけでも、まだまだテキスト入力１個で項目の数は増えるワケで。とは言え内容を見ると幾つか―――
そんなの当たり前じゃないか。確認するまでも無い。
と思われる内容も含まれています。もしくは「項目数稼ぎでは？」と思われるかもしれません。でも、自分は「それでいい」と思ってます。
テスト仕様書自体は「試験の手順，実施内容」を記述するものですが、「その実施結果」と言うのは―――
ここに記述されている挙動については確認しました。間違いありません。
という証明の集まりです。ゆえに、その実施内容が―――
そこで何か起こるなど絶対あり得ない
ものであったとしてもず「本当に実施した」のであれば、各々の項目が被っていない限り、その数もまた説得力だと考えております。
だって―――
あり得ないと思っていたことが起こった
なんて、プログラマ稼業では日常茶飯事だと思いませんか？（笑）
/////////////////////////////////////////////////////////////////////
以上、本当に「ごくごく当たり前」のコトなんですけども―――
先日、一躍話題になった某サイト（判らなければぐぐれｗ）が、XSS（クロスサイトスクリプティング）にやられて騒ぎになり、
作者が謝罪…というニュース（事故？）がありました。
ちなみに記事を見る限りでは、ほんの１行で回避できたと予想される内容だったりします。
※まぁ「数時間で作成」と謳っているゆえ、事細かなテストまでは行なえていなかったのも無理はありませんが。
とはいえ、作った人は他の某サイト（判らなければぐぐれｗ）の作者であり、制作者としては相応な実績を積んでらっしゃるワケですが…やはり人間足る者、どうやっても「うっかり」ってのは少なからず存在するモノでして。どれだけ経験を積んだプログラマでも余程小規模でもない限り、イキナリ一発で「全くバグが存在しない」システムなんて作れないモノです。（むしろ経験を積んでいる方の方が、この辺りは痛感されているかと）
とは言え、スケジュールの都合上「メイン部分の実装」以外はどうしても意識が薄くなりがちです。
ただ「テストする手間」と「何か問題が起きた時に発生する対処」
この２つのトレードオフについて、頭の片隅に置いてみては如何でしょうか。
2008.07.31
再び、PythonとC言語を比較してみよう。
今日はメモリ内の値を直接書き換えられちゃうC言語なお話。
Pythonでは [1,2,3] のような配列を 「リスト」 と呼び、中の要素は後で追加できる。
例えば、
>>> a = [] #空っぽのリスト
>>> a
[]
>>> a.append(1) #要素追加
>>> a
[1]
>>> a.append(2) #要素追加
>>> a
[1, 2]
1行目の宣言のようなものは Python では不要だけど、このように append というメソッドで後から要素を追加することができる。
「えっ？！ これって当たり前じゃないの？」
と思う人は 2.0系 エンジニアです(笑
(more…)
2008.07.29
弊社に来年4月からやってくる新卒の学生に Python の勉強をしてもらおうと思っていたのだが、先日聞いたところでは大学で C言語 をやっているらしい。
それを聞いて Python の勉強はまだ良いから C をしっかりやって欲しいと伝えた。
C言語 は良い言語だ。C++ はもちろん、PHPも Java も他の言語も少なからず C言語 の影響は受けている。
Webサービスをやっているだけなら C言語 はほとんど使わないが、比較的余裕のある学生のウチに C を学べるのはとっても良いと思う。
今日は、C言語を学んだ人が最初に不思議に感じる「Pythonでは全てがオブジェクトとして扱われる」というお話。
(more…)
