シアトルコンサルティング サービス開発ブログ

シアトルコンサルティング株式会社プロダクトソリューション事業部の開発ブログです

サイト上で動作するチュートリアルはIntro.jsで簡単作成!(入門編)

こんにちは iijmyaです。

今回は、自分が作成したサイトなどを説明するときに、堅苦しい説明書きを作らなくても視覚的にわかりやすく説明することができる救世主、「Intro.js」をご紹介します。


Intro.jsのダウンロード

Intro.jsは公式サイトからダウンロードすることができます。


Intro.jsの利用
それでは早速Intro.jsを使ってみましょう。

Intro.jsはダウンロードしてきた「intro.js」と「introjs.css」を読み込むことで使用することが出来ます。
HTML内にJavaScriptのコードを記述すると文字化けしてしまうことがあるため、charsetで文字コードも指定しておきます。

<script type="text/javascript" 
 src="//cdnjs.cloudflare.com/ajax/libs/intro.js/0.2.1/intro.min.js" 
 charset="utf-8">
</script>


次に、チュートリアルの対象にしたいモジュールに対し、data-intro属性*1とdata-step属性*2 を指定します。

<h2 data-step="1" data-intro="ここがタイトル部分です">intro.jsの利用</h2>


あとはIntro.jsを起動するモジュールを置き、イベント発生時の処理でIntro.jsを起動してあげれば終了です。

<button id="sampleIntrojsBtn">実 行</button>
 〜中略〜
jQuery(function($){
  $('#sampleIntrojsBtn').on('click', function(){
    introJs().start();
  });
});


Intro.jsの実行イメージ
今回の場合、実行ボタンをクリックすることでチュートリアルが表示されます。
f:id:seattleservice:20130514224805p:plain


Nextをクリックすることで次の説明に、Backをクリックすることで前の説明に戻ることが出来ます。
f:id:seattleservice:20130514224806p:plain

f:id:seattleservice:20130514224807p:plain


いかがでしたか?
またそのうちIntro.jsの応用編について書きたいと思います。

*1:data-intro属性…チュートリアルで表示したい説明文を指定する

*2:data-step属性…対象モジュールをチュートリアルの何番目に表示するかを指定する

コマンドラインからShift_JIS > UTF-8に変換する

satkakuです。

歴史を経て様々な人々によっていじられたプロジェクトでは、基本的な文字コードUTF-8なのに、特に意味も無く一部だけShift_JISになっていることなどがあります。ありました。

自分は主にMacで開発しており、エディタは大体Sublime Text 2を使っているのですが、Sublime Text 2はデフォルトではShift_JISに対応していないため、悲劇が生まれてしまいます。

ちなみに、Sublime Text 2でもShift_JISに対応させるプラグインはあります。
参考

ありますが、特に意味も無いのであれば、せっかくなのでUTF-8に揃えておきたいところです。

そこで今日はコマンドラインから、Shift_JISで書かれたテキストファイルをUTF-8に変換する方法を試します。

とりあえずShift_JISでテキストファイルを作っておきます。

f:id:seattleservice:20130511145550p:plain

残念!

それでは変換します。文字コード変換コマンドnkfを使いたいのですが、Macにはデフォルトでは入っていないので、homebrewでインストールします。

% brew install nkf
% nkf --help
Usage:  nkf -[flags] [--] [in file] .. [out file for -O flag]
 j/s/e/w  Specify output encoding ISO-2022-JP, Shift_JIS, EUC-JP
          UTF options is -w[8[0],{16,32}[{B,L}[0]]]
 J/S/E/W  Specify input encoding ISO-2022-JP, Shift_JIS, EUC-JP
          UTF option is -W[8,[16,32][B,L]]
 m[BQSN0] MIME decode [B:base64,Q:quoted,S:strict,N:nonstrict,0:no decode]
 M[BQ]    MIME encode [B:base64 Q:quoted]
 f/F      Folding: -f60 or -f or -f60-10 (fold margin 10) F preserve nl
 Z[0-4]   Default/0: Convert JISX0208 Alphabet to ASCII
          1: Kankaku to one space  2: to two spaces  3: HTML Entity
          4: JISX0208 Katakana to JISX0201 Katakana
 X,x      Convert Halfwidth Katakana to Fullwidth or preserve it
 O        Output to File (DEFAULT 'nkf.out')
 L[uwm]   Line mode u:LF w:CRLF m:CR (DEFAULT noconversion)
 --ic=        Specify the input encoding
 --oc=        Specify the output encoding
 --hiragana --katakana  Hiragana/Katakana Conversion
 --katakana-hiragana    Converts each other
 --{cap, url}-input     Convert hex after ':' or '%'
 --numchar-input        Convert Unicode Character Reference
 --fb-{skip, html, xml, perl, java, subchar}
                        Specify unassigned character's replacement
 --in-place[=SUF]       Overwrite original files
 --overwrite[=SUF]      Preserve timestamp of original files
 -g --guess             Guess the input code
 -v --version           Print the version
 --help/-V              Print this help / configuration
Network Kanji Filter Version 2.1.2 (2011-09-08) 
Copyright (C) 1987, FUJITSU LTD. (I.Ichikawa).
Copyright (C) 1996-2011, The nkf Project.

今回初めて知りましたが、nkfはNetwork Kanji Filterの略だったんですね。
かっこいい!

それはさておき、早速-gオプションをつけて、先ほどのファイルを見てみます。

% nkf -g sjis.txt
Shift_JIS

Shift_JISです。ですよね。分かってます。

さくっと変換しちゃいます。

% nkf -w sjis.txt > utf8.txt   

f:id:seattleservice:20130511150335p:plain

めでたしめでたし。

traceGLでクライアントサイドのJavaScriptの動きを見てみる

satkakuです。

昨日に引き続きtraceGLを色々試してみます。

昨日はサーバーサイドJavaScriptの出力を試したので、今日はクライアントサイドJavaScriptの出力を試してみようと思います。こっちのほうが使う機会は多いと思います。

まずは、昨日作ったサンプルページで、JavaScriptを読み込むよう追記しておきます。

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script src="javascripts/main.js"></script>

一つは、GoogleホスティングされているjQueryを読み込み、もう一つは/javascripts以下につくったmain.jsを読み込みます。

main.jsは以下の通りです。

(function(){
  $('button').on('click', function(e){
    call(function(){
      val = $('.source input').val();
      $('.dest').text(val);
    });
  });
})();

function call(func) {
  func();
}

ややこしい書き方をしていますが、要は、inputに書かれた文字をdestに表示するだけのコードです。

これを試してみます。

クライアントサイドJavaScriptをtraceGLで出力するようにするためには、プロキシを通してアクセスする必要がありますが、その辺はtraceGLがよしなにやってくれます。
では、やってみましょう。http://localhost:3000はあらかじめアクセス出来るようにしておきます。

% node tracegl http://localhost:3000

前回同様、traceGLの画面はhttp://localhost:2000で立ち上がっています。ここでhttp://localhost:3000にアクセスしても、traceGLの画面には変化がありませんので、プロキシが立っているhttp://localhost:2080にアクセスします。

f:id:seattleservice:20130509092004p:plain
f:id:seattleservice:20130509092218p:plain

traceGL画面に表示されました。
ここで、http://localhost:2080の画面上で「show」をクリックしてみます。

f:id:seattleservice:20130509092349p:plain
f:id:seattleservice:20130509092412p:plain

traceGL画面にon、callが実行されていく様子がリアルタイムで表示されました。右上の画面で行を選択すると、右下にそのコードが表示されます。左下はスタックトレースですね。

いい感じで実行状況をトレースできているようです。

ここで、試しにコンソールから直接JavaScriptをたたいてみましょう。

f:id:seattleservice:20130509092907p:plain
f:id:seattleservice:20130509093008p:plain

callが呼ばれたことが追加されました。実際にcallの引数に何が渡ったか見たかったのですが、それは表示されないようです。

では、Google上にホスティングされているjQueryの実行はどうなるでしょうか?

f:id:seattleservice:20130509093322p:plain

すると今度はtraceGLには何も変化がありません。ローカルにあるJavaScriptのみトレースしてくれるようです。

気になって、http://localhost:2080でmain.jsを見てみると……

f:id:seattleservice:20130509093635p:plain

書き換えられてる!

ちなみに、traceGL画面で、右下の領域の気になるところをダブルクリックすると、編集していたSublime Textの該当箇所にジャンプしました。どこまで賢くジャンプしてくれるかは、このコード量だとよく分かりませんが、これは便利そうです。

引き続き色々触ってみようと思います。

traceGL導入編

satkakuです。

traceGLというJavaScriptアプリケーションのデバッグツールがリリースされました。クライアントサイドでもサーバーサイドでも、デバッグ結果をブラウザ上で出力してくれるらしいということで、試してみました。

とりあえず導入編ということで、Node.jsで動かしたアプリで試してみようと思います。


traceGLはここから購入できます。$14.99なので、今だと1500円くらいですね。only a few cups of coffeeと書いてありますが、マクドナルドなら15杯です。

購入処理が済むと(PayPalを使いました)、tracegl.jsがダウンロードできます。これ一つです。

それでは早速サンプルアプリを作って試してみます。

% express tracegl

expressでひな形作成後、npm installで必要なモジュールを入れておきます。
その後、出来上がったtraceglディレクトリの上の階層にtracegl.jsを置きます。

では起動してみましょう。

% node ../tracegl app.js
[trace.GL] See your code. This product has a commercial license.
[trace.GL] WebGL trace UI: http://localhost:2000
[trace.GL] Checking for update...Express server listening on port 3000
up to date.

これだけ!

expressのアプリケーションが3000番ポートで動いており、traceGLの画面は2000番ポートで動いています。

早速、ブラウザにて、http://localhost:3000/http://localhost:2000/ にアクセスしてみます。

f:id:seattleservice:20130508095512p:plain

表示されました!http://localhost:3000/ をリロードしてみると、リアルタイムでtraceGLの画面も更新されていきます。

右上部分のコードを一行クリックすると、左下にスタックトレース、右下にコードが表示されるようです。

とりあえず開発で使ってみて、色々と試していこうと思います。

Redisに触れる

こんにちは iijmyaです。
今回はNoSQLの一種であるRedisの、MacOS Xへのインストール方法についてご紹介します。


1.Redisのインストール
 それでは早速、Homebrew*1を利用し、Redisをインストールしましょう。
 ターミナル上で以下のコマンドを実行します。

$ brew install redis

 インストールが終わったら、以下の場所にredis.confが生成されているか確認します。

/usr/local/etc/redis.conf

 次に以下のコマンドを実行し、logsディレクトリを生成しておきます。
 ここでlogsディレクトリを生成しておかないと、エラーになってしまいます。(ログディレクトリの場所はredis.conf内に記述されています)

$ mkdir -m 755 ~/logs


2.Redisの動作確認
 次に、Redisがインストールされ、正常に動作するか確認しましょう。
 以下のコマンドを実行し、サーバを起動します。

$ redis-server /usr/local/etc/redis.conf

 次にRedisを操作します。
 setコマンドで値をセットし、getコマンドでセットした値を取り出してみます。

$ redis-cli

redis 127.0.0.1:6379> set test 1
OK
redis 127.0.0.1:6379> get test
"1"

 上記のように動作したら、インストールはOKです!

*1:Homebrew…パッケージ管理システム

Async.jsで繰り返し処理

satkakuです。Async.jsの繰り返し処理で少しはまったので、それについてのメモです。

Async.jsは非同期処理のフロー制御をしてくれるライブラリで、順番に処理を書けるseriesや、前回の処理結果を次の処理に渡せるwaterfallなどがあります(以前の記事)。

そんなAsync.jsには、配列を非同期で処理するために便利なforEachがあります。

# IDが配列に入っているとする
idList = [ "1", "2", "3" ]

# IDに紐づくデータを非同期で取得する
async.forEach(idList, (val, next)=>

  repository.findByID(val, (err, res)=>
    # 取得結果を別の配列に入れる
    @result.push(res)
    next()
  )

, ->
  # 配列の全ての結果が返ってきた際に呼ばれる
  done()
)

こんな感じでやると、簡単に配列内のデータについて全て非同期で処理できます。

……しかし実際にこの処理を動かすと、resultという配列に入る結果は[ "1", "2", "3" ]の順序が保たれていません。何故? となったところで気付きました。forEachに引数として渡す関数の引数名を「next」としており、さも配列が順番に処理されるっぽく書いていますが、これは自分で勝手につけた名前です。ここは「callback」という名前にすべきでしょう。あくまで、各非同期処理の終了を告げるためのもののようです。

結論から言うと、forEachは順番を保証しないので、forEachSeriesを使います。

# IDが配列に入っているとする
idList = [ "1", "2", "3" ]

# IDに紐づくデータを非同期で取得する
async.forEachSeries(idList, (val, callback)=>

  repository.findByID(val, (err, res)=>
    # 取得結果を別の配列に入れる
    @result.push(res)
    callback()
  )

, ->
  # 配列の全ての結果が返ってきた際に呼ばれる
  done()
)

これで、resultの中身はidListの順番と同じになります。

・順番を保証したい場合はforEachSeriesを使う

今回の教訓は、実際の動きを分かっていないうちに、思い込みで変数名をつけると痛い目を見るということです。分かんなかったらソース読めという話ですね。まだソース読んでないので、改めてちゃんと読んでおこうと思いました。

サブディレクトリごとの使用容量を一覧で出す

satkakuです。

先日、サーバー内のhogeディレクトリ内のサブディレクトリごとの使用容量を一覧で出す必要があったので、そのメモです。

% tree
.
├── sample1
│   ├── test1.txt
│   ├── test2.txt
│   └── test3.txt
├── sample2
│   ├── test1.txt
│   ├── test2.txt
│   └── test3.txt
└── sample3
    ├── test1.txt
    ├── test2.txt
    └── test3.txt

上記のようなディレクトリ構造があったときに、sample1、sample2、sample3の使用容量を一覧で出します。

中身のファイルそれぞれの使用容量を見たいだけなら、treeコマンドでもいけます。

% tree -ash 
.
├── [ 170]  sample1
│   ├── [   8]  test1.txt
│   ├── [   8]  test2.txt
│   └── [   8]  test3.txt
├── [ 170]  sample2
│   ├── [   8]  test1.txt
│   ├── [   8]  test2.txt
│   └── [   8]  test3.txt
└── [ 170]  sample3
    ├── [   8]  test1.txt
    ├── [   8]  test2.txt
    └── [   8]  test3.txt

「-s」を付けるとサイズも出してくれます。
ですが、今回はサブディレクトリごとの使用容量を見たいので、duコマンドを使います。

% du -sh ./*
 12K	./sample1
 12K	./sample2
 12K	./sample3

「-s」で集計だけ出してくれます。後はパイプでsortを繋げたりして、見やすく出力したりします。

……ですが、今回は「*」のキーが壊れていたことにより、このやり方は使えませんでした。そういうこともあります。仕方が無いので「*」を使わないようにします

% find . -d -maxdepth 1 -exec du -sh {} \;
 12K	./sample1
 12K	./sample2
 12K	./sample3
 36K	.

findコマンドは「-maxdepth」で探索する深さを指定できるので、そこで1を指定し、その結果を「-exec」で繋いでduに渡します。これで「*」を回避できました。

別にだからなんだというわけでもありませんが、「*」のキーが壊れるとめんどくさいので、「*」キーは労りましょう。