※スマホ対応はしてません。

タグ: Advent Calendar 2014

CDNの話。(JavaScriptおれおれAdvent Calendar 2014 – 05日目)

カテゴリー: JavaScript

JavaScriptおれおれAdvent Calendar 2014 – 05日目

駆け込み需要で五日目。

CDNって

Contents Delivery Networkの事で、平たくいうと「イケてるファイルサーバー」くらいの理解で良い。加えて今回の文脈だと「そのファイルを自由にページへ読み込んで良い」というのも追加。

JSファイルが公開された状態で置いてあって、しかもそれを自由に使って良いよという事になってます。(JSの場合ね。CDN自体はJSに限ったものじゃないけど。)

何が嬉しいのか

ライブラリーのファイルをダウンロードしてきてープロジェクトのディレクトリーへ移動させてー自分のファイルサーバーへアップロードしてーなんていう手間がなくなります。

あとCDNのサーバーは強力なんで、ファイルサイズが大きくてもページを開いたときさっさかダウンロードできたり。さらに事前に他のサイトでも同じCDNのファイルを利用している場合、最初からキャッシュに溜まっている可能性もあります。

つかいかた

<script>で読み込むだけ。

<script src="//code.jquery.com/jquery-2.1.1.min.js"></script>

おまけ: “//”で始まるリンクについて

普通は”http://”か”https://”かだと思うんだけど、”//”で始める事もできる。古いIEでも大丈夫みたい。

“//”から始めると、ページのURLと同じプロトコルになる。相対的に定まるので、HTTPSなのかどうなのか考える手間が省けてコピペで使いまわせるようになるのだ。

ちなみにローカルファイルを開いたときは”//”が”file://”と判断されちゃうので注意。

CDN

こんなのがあります。

cdnjs.com

おすすめ。

とにかく大量のライブラリーをホストしてます。(今数えたら1,001個だ。) 一覧に未掲載のものがあってもGitHubでPR投げたら追加してもらえるかも。

CDNの大手CloudFlareがスポンサーの筆頭にいるので、ネットワークも強そう。

jQuery

jQuery 1.x, 2.x本体の他jQuery UIやjQuery Mobile等々のファイルをホストしてます。

Google

jQueryやAngularJS、SWFObjectなど。

Microsoft

jQueryやASP.NET、Bootstrapなど。

障害対応

CDNは強力なネットワークを使っているのだけど、ごくまれに落ちるという可能性はある。

対応としては、使わない(プロジェクト立ち上げ時だけ使う)で自前でホストするというのが最善だろうか。使った方が良いと思うけど。

スクリプトの読み込み失敗を検知して別CDNや自サーバーから読み込み直す、というのもアリだけど、その実装するコストに見合うほどCDNが落ちないんじゃないかなー。

まあ落ちたら落ちたで仕方ないってなくらいの心持ちではいかがでしょうか。

まま、お茶でもどうぞ。

HTML5 Canvasで、RGB値を入れ替えるサンプルの話。(JavaScriptおれおれAdvent Calendar 2014 – 04日目)

カテゴリー: JavaScript

JavaScriptおれおれAdvent Calendar 2014 – 04日目

写真の紅が綺麗だったので、そのまま色のRGB値を入れ替えられそうだなーと思って作ってみました。

実装パターンの実例という事で、昨日までの記事も含まれてますし、今後の記事でも言及するかもです。

blue-leaves
RとBを入れ替えて青くしてみるテスト。

ちなみに生まれて初めてGitHub Pagesを使った。簡単で良いね、これ。

小規模JS実装の自分的基盤パターンの話。(JavaScriptおれおれAdvent Calendar 2014 – 03日目)

カテゴリー: JavaScript

JavaScriptおれおれAdvent Calendar 2014 – 03日目

立て込んでて日付またいじゃいました。

そんなに大きくない規模のJSを書く際、こういうパターンで作る場合が多い。

(function() {
    var controller = {
        start: function() {
            // …
        },

        // …
    };

    $(function() {
        controller.start();
    });
})();

全体を即時実行関数で括る

スコープ生成してグローバル変数にならないように。

一昨日の記事参照。

controllerオブジェクト

オブジェクトリテラルで。

前項の通りスコープ生成されているから、その中で普通に関数作ったり共通の変数を使ったりしても別に構わないんだけど。でも普段はBackbone.JS的な書き方をしている事が多いので、やはりオブジェクトにまとめる書き方の方が慣れている感じがする。

コンストラクターにはしない。ひとつしか存在しないから、わざわざnewする手間はいらないんじゃないかな。

controllerという名前

今、この名前に決めました。全体的な処理を「コントロール」するオブジェクトなんで、この名前で良いのではないかな。今後はこの名前にしよう。

他に諸々の処理単位があれば、それぞれオブジェクトを生成します。こちらはだいたいコンストラクターにする事が多い気がする。その場合、controllerから各オブジェクトのインスタンスを作成し、関連付けしたり起動したりします。

各コンストラクターはModelとViewみたいな扱いにする場合が多いんだけど、それはまた別の機会に書きたいと思います。

関連:

startメソッド

いわゆるエントリーポイント。

うーん、使ってるのは”initialize”という名前にする事の方が多いかなあ。今後は”start”で統一したい所存。そっちの方がそれっぽい気がする。

エントリーポイントって

最初に実行される処理の事です。C言語だと「main関数」がそれ。

JavaScriptの場合は単純に上から順に実行されるので、「ここから始める!」という認識が薄い気がする。

なんでわざわざ用意するかっていうと

その方が見やすいと思うので。「最初の処理」があちこちに散らばってたら嫌でしょう?

$(fn)

jQueryを使ってる場合はこれ。

でも実際、自分で全部作ってる場合はこれも省略する事が多いなあ。JSファイル読み込みを必ずHTML末尾にするって決めれば、だいたいDOMContentLoadedを待つ必要ない。

そんな感じ

なんか普段使ってる、みたいに言っておいて普段とはちょっと違ってそうだ(笑)。

でもまあ、だいたいこんな方針です。

CSS 珍百景 Advent Calendar 2014 – 02日目

カテゴリー: CSS

すみません、三日目と勘違いしてました……。

今回はtransform:scale()とzoomの併用についてです。バグじゃないです。

デモ:

jQuery用の変数の命名の話。(JavaScriptおれおれAdvent Calendar 2014 – 02日目)

カテゴリー: JavaScript

JavaScriptおれおれAdvent Calendar 2014 – 02日目

今日は変数の命名についてのお話その一です。jQueryオブジェクトを格納する変数には”$”を付けろっていうやつ。

先にまとめ

  • 誤解されない、明確な名前を付けよう
  • 必要なら接頭辞も付けよう
  • nameなら文字列、$nameならjQueryで取得した要素、elNameなら生要素

変数の命名からの理解

普通の名前

var name;
var age;

パッと見でどんな値が格納され(てい)るか想像付くでしょうか。付きますよね。

このnameは名前だからたぶんstring型で、ageはきっと年齢がnumber型で格納されるのだろうなと察しが付く。よね。

意外とそうじゃないかもしれないけど、コード中の意外性は可読性を下げる(正確な理解を妨げる)事になるので、そういう場合は実装なり設計なりを見直した方が良い。

で、その「意外とそうじゃない」奴の例として、要素があります。

jQueryのやつ

名前を表示する要素を検索してきたとして、その結果を格納する先の変数の名前をどうしよう。名前だからnameかな。でもそれだけだと、文字列っぽいよね。というわけで、”$”を付けて区別します。

jQueryで要素を検索してきた結果のjQueryオブジェクトは、”$”で始まる変数に格納するのが一般的。(長いものには巻かれよう!)

var $name;
var $age;

この例の場合、$nameも$ageも要素なんだなーという事がわかる。

あー、もちろん正確にはjQueryオブジェクトね。要素を格納した(可能性のある)jQueryオブジェクトです。jQueryオブジェクトなので、jQueryのメソッドを利用できます。

だので、”$”で始まる変数を見かけたら、これはaddClass()とかremove()とか使って大丈夫だな、と瞬時に理解できるわけです。

jQueryじゃない要素

jQueryを使わずに要素を扱う場合もある。jQueryに依存しないでDOM操作するライブラリーとか。

で、個人的にそういうときは接頭辞として”el”を採用している。もちろんelementのelです。

var elName;
var elAge;

前述の約束事を理解していれば、このelName, elAgeがそれぞれ要素(HTMLElementオブジェクト)であり、それぞれ名前や年齢を表示するのに使われているんだなーという事がわかる。

もし接頭辞がなかったら

要素なのに普通にageと命名しちゃった場合。

var age = $('#age');

これさー、普通”age”だけ見たら年齢でしょ、じゃあ数値でしょ。だから足し算引き算もできるでしょ、と理解するのが一般的かと思います。

age + 1;

が・・・・駄目っ・・・・・!

足し算できないね。紛らわしい。

もちろんさっきの行を見ればそうじゃない事がわかるんだけど、数行の関数だって全部に目を通さない場合もあるかもしれないし、わかりづらいっす。

それから、大規模できっちりフレームワークとか設計とかある場合は別だけど、割と処理してすぐ要素に反映させるって場面も多いと思うのです。

var age = getUserAge();
var age2 = $('#age');
age2.text(age);

ほら、名前かぶっちゃった。

ハンガリアン記法

こういう風に、簡単に見分けるために接頭辞を付ける方法を「ハンガリアン記法」と言います。ちなみに接尾辞でも良いらしい。

ハンガリアン記法は接頭辞ないし接尾辞を付与する事で変数の役割を明確にする事が目的。

Microsoftはかつてこのハンガリアン記法が大好きで、Windowsアプリケーションを作成するのに使うWin 32 APIなんかも全部ハンガリアン記法になってる。ただ、完全に型情報を付与する形(システムハンガリアン記法)になってて、あまり嬉しくはない……。新しいAPIの.NET Frameworkは型情報を付与するハンガリアン記法を採用していないそうだ。

文脈

さっきはいきなり”name”という単語で変数を命名したけど、これは何の情報を扱っているかがある程度明確じゃないとわかりづらいかも。

ユーザーの名前なのか、テーマの名前なのか、画像のファイル名なのか……。

もし二つ以上の情報を扱っている場合は、それぞれuserName, themeName, imageFileNameみたいにしないと混乱しちゃう。

逆にどれかひとつについてのみ扱っているなら、文脈から対象が明確なので”name”だけで十分。ユーザー情報を扱っているのが明確なのにuserNameでは冗長だ。特に、変数じゃなくてプロパティの方は気を付けてほしい。user.userNameとか、どうよ?

(そういえばDBで「userテーブルのuser_nameカラム」とかよく見るんだけど、なんでかね。考え方が違うのかなあ、DB方面の技術者さんとは。)

パッと見でわかるように

まあそんなこんなです。まずはわかりやすい名前を付けましょう、例外としてjQueryオブジェクトには”$”を付けましょう、というお話でした。