エスキュービズム ラボ Blog

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

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

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

再度おさらい。

paddingやmarginやwidthの解説

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

左よせで使う際

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

仮に3列の表を作る際、float：left;
すると、全て上にあがろうとするので、
<div style=“clear　:　left”></div>
を入れる。
プログラム上でかまわないと思われます。

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

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 上で確認している。 Read more »

今、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）に期待するしかないのでしょうか…

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

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

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

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

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

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

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

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

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

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

それでは See you arguments.callee!!

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

webサイトを構築する上で、情報を暗号化しサーバとのやりとりすることは当然のようになってきていますが、

具体的には、どのようになる？、どのようにするなど？わからない方のためおさらいしてみます。

httpsなどでよく聞くことは

「サーバとブラウザ間の通信を暗号化し、プライバシーに関わる情報やクレジットカード番号などを

安全にやり取りすることができる。」

上文を読んでよくわからない、しっくりこない方は、

まず、httpとhttpsの違いについてですが、

HTTPの通信は、暗号化されない。

HTTPSはHTTPにSSL（Secure Socket Layer）を組み込むことで、

通信の暗号化、データの改ざん防止、通信相手の認証を

可能としている。

よって、

上図のようなことも可能となります。

http通信で、特に個人情報のやり取りなどをするときなど要注意。

httpsの設定は特に難しくありません。（サーバのOS、SSL構築などで検索）

webに構築方法など多数手順が公開されていますので、

チャレンジすることをオススメします。

また、いいサービスを提供する方は、使ってもらうユーザの安全を守ることも

いいサービスの1つです。

いいサービスを作成する際にセキュリティーにもこだわってみては・・・

今回は、二分探索法について解説します。

1.逐次探索

通常、n個の配列(list)の中からある要素(target)を調べる場合、次のようにします。


for i in range(len(list)):
 if i == target:
    return i
return -1   #false

これは逐次探索と 呼ばれます。(線形探索とも呼ばれ

る。)

この方法は単純ですが一般に、データ量に比例して作業量も増えてしまいます。

Read more »

勉強会は週に1回開催していて、メイン担当は持ち回り制である。

で、このブログ記事を更新するのはメイン担当者の役割だ。
と、ルールを決めた本人が自分の当番を忘れてしまっていて「やべっ、示しがつかない…」と猛反省。

さて、今回はC言語で「変数はメモリ内にどうやって格納されていくのか」のお話。
深いところまで突っ込んでいこうと思ったのだが、文章化すると思ったより長くなってしまったので序論な感じではある。

C言語では、関数内のローカル変数は、関数を抜けると確保していたメモリ領域は開放される。

この時に使われるのはメモリ内の「スタック」と呼ばれる領域だ。
スタックというのは後入れ先出し方式で使われ、その名の通り、後に格納した値から先に使う（解放する）時に利用される領域である。

int a = 123;
int b = 987;

という宣言をしたとしよう。
メモリの下（番地が大きい方）から値が格納されていくので、下図のようなイメージとなる。

  　　├────────┤
      │      987       │
    　├────────┤
      │      123       │
    　├────────┤
      │ < 使用済領域 > │
    　└────────┘

Read more »

さて今回は「テスト仕様書」について…
とは言え、制作歴が長い方にとっては「ごくごく当たり前」の話なんですが。

ただ制作歴の短い…特にWebCGI（特にPHP）しか業務経験が無い方だと、どうも「リリース後に不具合発覚→検証→修正→更新」が容易に可能な環境が多い所為か（Web以外だと納品後の修正は、かなり面倒なコトに…）この辺りに関する意識が甘い方を、これまで何名か見てきてたゆえの話だったりします。

とは言え、わざわざこんなトコを好んで見ている方にとっては、このような話をする必要は無いのかもしれませんがｗ

/////////////////////////////////////////////////////////////////////
さて、テスト仕様書を作り慣れてない方る際、最も頭を悩ませるのは「テスト項目の挙げ方」だと思います。
自分も昔「テスト項目1,000個挙げろ」と言われ、最初は200も挙げられなかったような気がします。orz…

というワケで基本的なテキスト入力１つで、ちょっと挙げてみますと―――

【よくある『名前（姓）』の場合】

• 初回表示時、初期値が空白になっているか
• 半角カナを入れてsubmit
• 半角「￥」を入れてsubmit
• 半角ダブルクォートを入れてsubmit
• 半角シングルクォートを入れてsubmit
• 機種依存文字を入れてsubmit
• shift_jis固有で化ける文字を入れてsubmit
• HTMLタグを入れてsubmit
• JavaScriptを入れてsubmit
• 大量（仕様依存）の文字数を入れてsubmit
• 空入力でsubmit
• エラー判定条件にかかって戻ってきた場合の初期値

などなど。
まぁ、もう少し「半角記号」を細分化するだけでも、まだまだテキスト入力１個で項目の数は増えるワケで。とは言え内容を見ると幾つか―――

そんなの当たり前じゃないか。確認するまでも無い。

と思われる内容も含まれています。もしくは「項目数稼ぎでは？」と思われるかもしれません。でも、自分は「それでいい」と思ってます。

テスト仕様書自体は「試験の手順，実施内容」を記述するものですが、「その実施結果」と言うのは―――

ここに記述されている挙動については確認しました。間違いありません。

という証明の集まりです。ゆえに、その実施内容が―――

そこで何か起こるなど絶対あり得ない

ものであったとしてもず「本当に実施した」のであれば、各々の項目が被っていない限り、その数もまた説得力だと考えております。
だって―――

あり得ないと思っていたことが起こった

なんて、プログラマ稼業では日常茶飯事だと思いませんか？（笑）
/////////////////////////////////////////////////////////////////////
以上、本当に「ごくごく当たり前」のコトなんですけども―――

先日、一躍話題になった某サイト（判らなければぐぐれｗ）が、XSS（クロスサイトスクリプティング）にやられて騒ぎになり、
作者が謝罪…というニュース（事故？）がありました。
ちなみに記事を見る限りでは、ほんの１行で回避できたと予想される内容だったりします。

※まぁ「数時間で作成」と謳っているゆえ、事細かなテストまでは行なえていなかったのも無理はありませんが。

とはいえ、作った人は他の某サイト（判らなければぐぐれｗ）の作者であり、制作者としては相応な実績を積んでらっしゃるワケですが…やはり人間足る者、どうやっても「うっかり」ってのは少なからず存在するモノでして。どれだけ経験を積んだプログラマでも余程小規模でもない限り、イキナリ一発で「全くバグが存在しない」システムなんて作れないモノです。（むしろ経験を積んでいる方の方が、この辺りは痛感されているかと）

とは言え、スケジュールの都合上「メイン部分の実装」以外はどうしても意識が薄くなりがちです。
ただ「テストする手間」と「何か問題が起きた時に発生する対処」
この２つのトレードオフについて、頭の片隅に置いてみては如何でしょうか。

再び、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系 エンジニアです(笑

Read more »