エスキュービズムラボ Blog

オープンソースライセンスについて

goto — Fri, 21 Nov 2008 02:06:14 +0000

弊社でもオープンソースのソフトウェアであるEC-CUBEのカスタマイズを手がけているわけですが、

オープンソース　＝　ソースコードが公開されている　＝　何でもやっていい

というわけではありません。
オープンソースのソフトウェアには、それぞれライセンスが設定されており、使用・改変・再配布などについては、この制限を受けるわけです。
「制限」と聞いて、「え！？」と驚いた方もいるかもしれませんが、多くのオープンソース・ライセンスにおいては、

著作権表示を維持すること
無保証

の2点と、他いくつかの規制があるだけです。
当たり前ですけど、「ソースコードの改変不可」なんて制限はついていないのでご安心を。

以下、主要なものをいくつか紹介。

■MIT License (X11 License)
上記2点のみの、非常に緩いライセンス。X Window Systemで使用されている。

■BSDライセンス
これも上記2点のみの緩いライセンス。
できた当初は「宣伝条項」という、派生物の広告に初期開発者を表示することが条件として組み込まれていたが、現在は修正され、この条項は削除されている。

■GNU General Public License (GPL)
非常に多くのソフトで使われているライセンス。
カスタマイズした派生物を配布する際にもGPLを適用しなければならない。
弊社のカスタマイズしているEC-CUBEもこれ。

■Apache Software License
ソフトウェアに Apache License のコードが使われていることを知らせる文言を入れなければならない。

■PHP License
・派生物の名称に「PHP」という名称を含めないこと
・PHPが含まれている、という旨の表示を含むこと
SNSサイトを構築できるOpenPNEはこれです。

他にも色々あるので、興味のある方は調べてみてください。

で、結構扱いに注意しなければならないのが、「GPL」です。
これは、派生物に関しても、必ずGPLにしなければならないので、カスタマイズしたものを配布・販売する際に、独自のライセンスを設定してはいけません。
なので、仮に販売することになった場合、必ずソースコードをセットで販売する必要があるわけです。
また、Webサービスを公開する場合は、自らの所有する特定のサーバに実行ファイルを置き、ユーザはそこにアクセスして使用しているだけなので、「配布」にはあたらず、特にソースコードを公開する必要はないとのこと。

ただ、GPLのソフトを改変したものを組み込んだハードを販売した場合、ライセンスに違反することになり、ソースコードを公開しなければならないので、注意が必要なようです。

詳しいFAQが本家のサイトにあるので、気になる方は参照してみてください。
http://www.gnu.org/licenses/gpl-faq.ja.html

uamobileを使ってみた

ishii — Mon, 17 Nov 2008 11:58:40 +0000

突然ですが、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( ”’”’ ”’”’ ”’

user_agent: %s

”’

        ”’is_docomo: %s
”’

        ”’is_ezweb: %s
”’

        ”’is_softbank: %s
”’

        ”’is_nonmobile: %s
”’

        ”’model: %s
”’

        ”’”’

        ”’”’ % (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でも使ってみよう

・・・と、このような理由らしき理由が無い理由から使ってみることになりました。
今は試して良かったと思っています。
月曜日の集中力の無さがなせる業とも言えますね！

無線LANの規格を再整理

みー — Tue, 11 Nov 2008 01:40:36 +0000

先日、ヤマダ電気のワゴンセールで無線LANルータを衝動買いしてしまった。
まあ、ネットの最安値よりも3000円安かったので良しとしよう。

ルータの箱にはデカデカと「スピード最大 300M」と書いてあるんだけど、「これって何だ？」と思ったのでこれを機会にザックリと無線LANの規格について調べてみた。

無線LANで知っておくべきことは大きく分けて2つ、「無線方式」と「暗号化方式」だろう。

【無線LANの方式】

いくつかの方式があるらしいが、IEEE 802.11シリーズが最も広く普及している。
また Wi-Fi と呼ばれる事もあるけど、これは別団体が認証している名称。

かなり乱暴に言ってしまえば一般的に

無線LANといえば、IEEE 802.11シリーズを指す
Wi-Fiというのは、無線LANの1種

と思って良いだろう。

IEEE 802.11シリーズには主に b、a、g、n の4つがある。
他には「無し」とか「i」とか「j」などもあるけど、市販製品ではほとんど見かけない。

これらの違いを理解するのは【周波数帯】と【速度】がポイントになる。

【周波数帯】

b,g 2.4GHz
a 5GHz
n 2.4GHzと5GHzの両方

【速度】

b 11Mbps
a 54Mbps
g 54Mbps
n 300Mbps

★ 電波干渉
なお、最も普及している無線LANの周波数帯は2.4GHzである。
これは電子レンジ（2.45GHz）と重なるので、電子レンジの影響を受けしまうので要注意。
例えば、無線LAN使用中に近くで電子レンジを使ったりすると、ネットワークが切断されたりする。

続いて、無線LANの暗号化方式を取り上げる前に、【SSID】について説明しておこう。

SSIDとは、カンタンに言ってしまえば無線LANを識別するための「名前」である。

無線LANでの接続はこの「名前」がわからないと接続できず、無線LAN（親機）の一般的な設定だと公開状態になっている。
（ワイヤレスネットワークが見つかりました、と一覧表示される例のヤツだ）

このSSIDを認証代わりに使えるかというと…
仮に非公開状態にしておいても、SSIDは暗号化されずにやり取りするので近くで誰かがつないでいるとカンタンにSSIDがバレてしまう。
つまりSSIDを非公開状態にしても本格的なセキュリティ上はあまり意味がない。

【無線LANの暗号化方式】

無線LANの暗号化方式は、3種類「WEP」「WPA」「WPA2」を知っておこう。

☆WEP

RC4という共有鍵暗号方式を利用
無線LAN初期の暗号化規格
先日、数秒で暗号解読可能な研究発表もあったが以前から脆弱性の指摘多数

☆WPA

TKIP暗号化方式を利用
TKIPというのはTemporal Key Integrity Protocolの頭文字で動的に鍵を変更する
非常に強固、だがこれまた数日前に暗号解読に成功したという発表があった

☆WPA2

AES暗号化方式を採用
WPAと機能面で大きな違いはない
標準化に時間がかかっていたのでWPAが先に発表され、より強固なWPA2が後から制定された

カンタンに言ってしまえば、WEPは昔からあって対応機器も豊富だが、セキュリティの問題があって勧められない。ところが任天堂の DS が実はWEPしか対応していないため、ルータによっては2つの認証が使えたりする。

セキュリティを高めるのであれば、SSIDを非公開状態にし、WPAを用いて、複雑なパスワードを設定しておくのが現在できうるベターな方法なようだ。
もちろん、無線LANの先につながるサーバやPCのファイアウォールなどもぬかりなく設定しておこう。

以下、参考までに無線LAN方式について補足説明。

（出典：Wikipedia）

【b】対応機器の普及：1999年～
標準化直前、アップルが AirPort という無線LAN対応機器を100ドル以下で発表。市場に衝撃を与えて、一気に普及。
なお、日本では AirPort という商標を取られていたので、AirMacという名称が使われている。

【a】対応機器の普及：2002年～
互換性にとらわれることなく最新技術を取り入れて高速化したもの。
bとは違い、5GHz帯を使うが…日本では移動体衛星通信システムに使われているのでイロイロと制限がある。
日本でも問題ない規格にしようよ、ということで IEEE 802.11j というものが新たに規定されている。
なお、jというのはJapanのjではなく、たまたまアルファベット順につけたらそうなったらしい。

【g】対応機器の普及：2003年～
b を高速にしたもの。
広く普及している b と互換性があって、b用の機器であればbモードで機能する。
他の機器に干渉される可能性が高いので、実行速度は a に負けると言われている。

【n】対応機器の普及：2005年～
n は来年7月（9月に遅れるみたい）に策定予定の規格。
最大通信速度 300Mbps、実効速度で100Mbps以上を実現する。
アップル社は「前世代の 802.11g ワイヤレスネットワークの5倍のデータ転送速度と2倍の通信範囲」と解説している。IEEE 802.11aやIEEE 802.11b、IEEE 802.11gとの相互接続も可能。

2005年2月頃から、策定中ながらIEEE 802.11nに準拠する可能性があるような、MIMO技術を使用し実効速度100Mbpsを謳った製品が各社より発表されている。

jQueryでもはまるクロスブラウザ問題まとめ

hosoda — Mon, 10 Nov 2008 02:18:16 +0000

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と挙動が異なるので注意が必要です。

とりあえず以上です。あと、ライブラリにある関数は一通りチェックして、極力使用するようにしたほうがいいと思います。何かしらクロスブラウザ対応しているので。

CSSとブラウザと

goto — Fri, 17 Oct 2008 08:08:23 +0000

ブラウザといえば昔はIEの独壇場だったわけですが、

最近はFireFoxがシェアを伸ばし、GoogleからはChromなんてものも出て、

クロスブラウザなんて言葉を気にしなければならない時代になってきました。

今回はそんなお話です。

まずは、世の中で使われている主なブラウザとそのシェアから。

W3Counterの集計によると、最新の状況は以下の通り。

———————–

IE7 28.8%

IE6 28.2%

Firefox2 18.7%

Firefox3 11.4%

Safari 2.5%

Opera 1.6%

———————–

結構IEがFirefoxにシェアを食われています。

ちなみに弊社運営のBB Planetだと、IEのシェアが80%弱、Firefoxが15%強と、IEがかなりがんばっています。

まだまだビジネスユーザはIEを使っている方が多いのでしょう。

で、このIEとFirefoxですが、CSSの解釈に結構大きな違いがあります。

有名なところを挙げると、

border/padding/width(height)の解釈の違いでしょうか。

例えば、CSSで

————-

border:10px;

padding:10px;

width:100px;

————-

と設定すると、

Firefoxでは左のようにきちんとと表示されるのに対して、

IEでは右のように、border+padding+widthで100pxになるようにレイアウトが組まれてしまいます。

これだとIEでぴったりになるように作ったのに、Firefoxだとはみ出したり、レイアウトが大きくずれてしまったり、ということが起こってしまいます。

このようなブラウザごとの独自の解釈を避けるために、最近のブラウザには「標準モード」と「互換モード」という2つのモードが搭載されており、これを切り替えることにより、ある程度CSSの解釈をコントロールすることが可能になります。

ちなみに、

標準モード…W3Cの勧告するCSS標準に基づいた解釈をするモード

互換モード…以前のバージョンとの互換性を持たせたモード

となっています。

IEはかなり独自の解釈をして動いているので、「互換モード」で動かすと、上記のような事態が発生するわけです。

ではどうやって標準モードで動かすのか。

実は、HTMLの一番最初に宣言する

この一文が、モード切替のスイッチになっています。

“-//W3C//DTD HTML 4.01//EN”

の部分を「公開識別子」と呼び、

この文法を記している文書の置き場を示した、

“http://www.w3.org/TR/html4/strict.dtd”

の部分を「システム識別子」と呼びます。

HTML4.01では公開識別子は、

——————–

HTML 4.01 Strict

HTML 4.01 Transitional

HTML 4.01 Frameset

——————–

の3種類が準備されており、システム識別子はそれぞれに1つずつ対応しているのですが、

宣言文に入れないことも可能です。

で、それぞれの宣言が、どのモードに対応しているのか、という表が以下。

ブラウザ	システム識別子	IE6	IE7	Firefox2	Firefox3	Safari	Opera
HTML4.01 Strict	あり	標準	標準	標準	標準	標準	標準
HTML4.01 Strict	なし	標準	標準	標準	標準	標準	標準
HTML4.01 Transitional	あり	標準	標準	標準	標準	標準	標準
HTML4.01 Transitional	なし	互換	互換	互換	互換	互換	互換
HTML4.01 Frameset	あり	標準	標準	標準	標準	標準	標準
HTML4.01 Frameset	なし	互換	互換	互換	互換	互換	互換

多くのブラウザが標準モードで動くように宣言するのがポイントです。

ただ、それでも細かい解釈の違いは色々と出てきますので、

結局のところは根気強い対処が必要になってきます。

クロスブラウザなサイト作りには根気が必要なようです。

ちなみにXHTMLになってくると少し話が変わってくるので、それはまたの機会に。。。

度忘れした時のためのCSS

tomizawa — Fri, 03 Oct 2008 04:05:14 +0000

たまに、デザイン組み込み時になどでうまくいかない時、バックエンドのプログラムばかり組み続けていると

CSSを度忘れしたときのための、基礎的なもの・・・・・

知っている人は知っていることです。

再度おさらい。

paddingやmarginやwidthの解説

繰り返し、同じ画像を使う際

左よせで使う際

気をつけなければいけない点

仮に3列の表を作る際、float：left;
すると、全て上にあがろうとするので、

を入れる。
プログラム上でかまわないと思われます。

誰かのお役にたてれば、幸い・・・・

Javascript のデバッグはやっぱり Firefox + Firebug

みー — Thu, 25 Sep 2008 11:08:46 +0000

google が Chrome を発表し、なんだか最近はブラウザのスピード競争がホットな話題になっている。

不思議というか、面白いのが「ブラウザの速度」=「Javascriptの処理速度」というのがいつの間にか当たり前のようになっていることだ。

個人的には Javascript の処理速度よりも、サクっと起動して、メモリ消費量が少なく、滅多に落ちない方が嬉しかったりするのだが…

とはいえ、Javascript（以下、js）の処理速度がそれこそ何十倍も早くなってくると、jsをバリバリと活用したサイトが増えてくるだろう。

jsはなんとも不思議な言語で、何しろ様々なブラウザ上で動作するために、逆に言えば同じコードでも「あっちでは動くけど、こっちでは動かない」といった事が多発する。

そのために、Prototype や jquery といったフレームワークという「枠」を越えて言語そのものを拡張してしまったかのようなライブラリも広く普及している。

こんな展開を見せている言語は他にない気がする。

そこでプログラミング（開発）には欠かせない、jsの「デバッグ」というテーマを取り上げてみよう。

かの有名な小飼弾さんが「まだまだ私にも落とすべき目の鱗がいくらでもあることを教えてくれた」と評していた Head First JavaScript の 11章に載っているサンプルコードを使って、それぞれのブラウザがどんなエラーメッセージを表示するのか比較してみた。

◆参考図書：Head First JavaScript

サンプルコードは 25行目に

else if average < 50 {

というコードミスがあるものだ。正しくは

else if (average < 50) {

である。ブラウザは全て WindowsXP 上で確認している。

◆Internet Explorer 6.0

似たようなメッセージを見たことがある人は多いだろう。

エラーがあったことはわかるが、それ以外は全く役に立たない…

◆Firefox 3.0.1

Firebugという有名なアドオンがあるが、ここではブラウザ標準機能を使っている。

エラーの箇所を正確に言い当て、エラーメッセージも英文だけどズバリ正解を指摘している。

さらにメッセージをクリックするとソースウィンドウが開き、エラーの箇所をハイライトしてくれる。

◆Opera 9.52

Firefox同様、エラーの箇所を正確に言い当て、エラーメッセージもぱっと見た感じはわかりにくいが正解だ。

おしいのは、Firefoxのようにソースウィンドウが開かないので、別にテキストエディタを使わないといけないことぐらい。

◆Chrome 0.2.149.30

唯一、ソースファイルの中にエラーメッセージを埋め込んで表示するタイプ。

エラーが起きている場所を正確に特定できる自信の表れだろうか？

メッセージ内容がわかりにくいが、おそらくまだ汎用的なメッセージしか用意されていないからだと思われる。

◆Safari 3.1.2

エラー箇所は正しく指摘してくれたが、エラー内容はイマイチわかりにくい。

メッセージをクリックするとソースが表示されるのは嬉しいけど、メッセージ一覧が消えてしまうので画面切り替えに少し手間がかかる。

今後に期待できそうなのが Chrome だけど、現状では Firefox が JS の開発環境としては一番良さそうだ。

たった1つのケースでの比較だけど、エラー内容の正確さだけではなく、開発者の使いやすさを考慮しても Firefox が一番である。

さらに、おそらく多くの人は Firefox に Firebug というアドオンを入れていると思う。

Firebug はさらに細かなデバッグまで可能なので、「なんだ、やっぱり」といった結論だけど、

Firefox ＋ Firebug

の構成が最強のようだ。

Javascript CSS benchmark

hosoda — Mon, 22 Sep 2008 13:36:24 +0000

今、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

の順で全体的に速くなっています。

また、Firefoxが、要素の子にdiv要素が多数ある場合(div cornersと4images)に極端に遅くなるという結果になりました。primitiveや1imageではFireFoxのほうがIEやOperaより速いのに、div cornersや4imagesではその逆で、しかも圧倒的に悪いです。これはもう、Firefoxの次期バージョンのエンジン（tracemonkey）に期待するしかないのでしょうか…

ブックマークレットとは

ishii — Fri, 12 Sep 2008 02:34:18 +0000

ECMAScript3.1標準化の動きやGoogle Chrome リリース等

更にJavaScriptableな世界になりつつある昨今、いかがお過ごしでしょうか？

そんな激流の中でも、基礎的な部分に関する知識が最も大事ということで

今回はブックマークレットの仕組みについてをまとめさせていただきました。
　

特に、ブックマークレットについて

・セキュリティ的に非常に危険なシステム

・いつブラウザ側の規制で無くなってもおかしくないシステム

このようなイメージを持っていない方は、読んでいただけるといいかなーと思います。
　

記事は以下のPukiWikiページ（外部）にまとめました。

→ ブックマークレットの解説
　

それでは See you arguments.callee!!

ページランクの求め方

hosoda — Thu, 04 Sep 2008 11:30:27 +0000

SEO等でよく耳にするページランクですが、その理論を知っている人って意外と少ないのではないかと思って勉強会のネタに取り上げてみました。下は、とりあえずその数学的な面白さが分かってもらえるように作った資料です。

エスキュービズム ラボ Blog