Quantcast
Channel: YoheiM.NET - 世の中をさらに便利に、面白く
Viewing all 364 articles
Browse latest View live

[git] 変更を取り消す

$
0
0
こんにちは、@yoheiMuneです。
今日は、gitで開発していて「あっちょっと元に戻したいな」という時の手順をブログに書きたいと思います。

画像

引用:http://flic.kr/p/6zJjzs




作業の変更を取り消す

gitを使って開発している場合に、作業前に戻したいなっていうことありませんか? そんな時に行うことができる変更取り消しの手順を説明します。
変更取り消しの手順は、以下3つの段階別に対応する必要があります。

  1. add前の変更を取り消す
  2. addしたけどcommitしていない変更を取り消す
  3. commitを取り消す

それでは、それぞれの状態別に取り消す方法を見ていきましょう。



add前の変更を取り消す

pullしてきたあとに、変更したものの、やっぱりもとの状態に戻したいという場合のリセット方法です。 ここでは、addもcommitもしていないファイルが対象です。
取り消し方法には、以下のように行います。
# 特定のファイルの変更を取り消す
$ git checkout <ファイル名>

#特定のディレクトリ以下の変更を再起的に取り消す
$git checkout <ディレクトリ名>

# 全てを元に戻す
$ git checkout .
これで、編集したファイルを自由にHEADリビジョンまで戻せるようになりました。 ちなみに、git statusをした場合に、ちゃんと取り消し方も表示されています。gitは親切ですね。
$ git st
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   aaa.txt
#
no changes added to commit (use "git add" and/or "git commit -a")



addしたけどcommitしていない変更を取り消す

続いてaddを取り消す方法です。 間違えてaddしちゃったとか、gitigonre設定する前に追加しちゃったとか、addを取り消したいことも時々あるでしょう。 以下のように行います。
$ git reset HEAD <ファイル名>
これでaddだけ取り消されました。ファイルシステム上の変更はそのままなので、それも戻すには1つ上で紹介した内容を行います。
これの方法も、ちゃんとgit statusで説明されていますね。add取り消しのやり方を忘れたとしても、git statusで確認できるのはありがたいです。
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   aaa.txt
#



commitを取り消す

最後にcommitの取り消しです。gitコマンドをノリノリで使っていたら不要なものもcommitしちゃったとか、コミットメッセージが間違えちゃったとか時々あります。この場合には、以下のように取り消します。

commit取り消しについては、「直前のcommitをやり直す」と「コミットを取り消す」の2パターンに分けて説明したいと思います。


直前のcommitをやり直す
commitを取り消す場合に、直前のcommitをやり直すということで直前のcommitを無効化することができます。
例えば今回の場合、aaa.txtの変更をcommitし忘れた場合を考えてみましょう。commit直前の状態は以下とします。
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   bbb.txt  # コミット対象
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   aaa.txt  # addしてないからコミット対象じゃない
#
aaa.txtをaddし忘れていているという状況です。
ここでコミットすると以下のようになります。
# commitする
$ git commit -m "革新的な実装ができた!"
[master b682426] 革新的な実装ができた!
 1 file changed, 4 insertions(+)

# statusを確認する
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.  # コミットされた
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   aaa.txt  # あっ、、commitから漏れてる。。
#
no changes added to commit (use "git add" and/or "git commit -a")
あちゃ、commitは無事にできましたが、aaa.txtをcommitに含め忘れていますね。ここでlogを確認すると以下のようになります。
$ git log -1
commit b6824266627379ea922189a78a9cfc3f4a778382  # [1]
Author: munesada_yohei <y.munesada@gmail.com>
Date:   Fri Jan 31 15:39:30 2014 +0900

    革新的な実装ができた!
上記の[1]というログが、今回やり直したい対象です。

まずは、先ほどのコミットに入れ忘れたファイルを追加して、commit対象(=staged状態)にします。
$ git add aaa.txt
そして、直前のコミットをやり直します。やり直すには以下のように行います。
$ git commit --amend
そうするとコミットコメントの修正も促されます(ターミナルでgitを使っている場合には、vimなどが立ち上がります)。 コメントの修正が終わるとコミットが行われ、結果として以下のように出力されます。
[master 862ea1e] 革新的な実装ができた!ファイルも忘れず追加!
 2 files changed, 7 insertions(+)
変更対象ファイルが1fileから2filesに変わってますね。ログを確認してみましょう。
$ git log -2
commit 862ea1e9d3541c751183f0c546a646fb5ca702cd
Author: munesada_yohei <y.munesada@gmail.com>
Date:   Fri Jan 31 15:39:30 2014 +0900

    革新的な実装ができた!ファイルも忘れず追加!

commit 485b4a7170ef5d5639ca3a6fa198b1a31cc135fe
Author: munesada_yohei <y.munesada@gmail.com>
Date:   Fri Jan 31 15:17:26 2014 +0900

    add for test
2つ分のログが出力されました。コミットをやり直した結果、やり直す前のコミット(ハッシュ値:b682426)は表示されていないですね。 無事にコミットのやり直しができました。



commitを取り消す
続いてcommitを取り消します。直前の以下のコミットを取り消したいとします。
$ git log --stat -1
commit 686ed5948a5ec2fdc493afaef2fd70b567f4462c
Author: munesada_yohei <munesada_yohei@cyberagent.co.jp>
Date:   Fri Jan 31 15:51:18 2014 +0900

    取り消したいコミットを作った

 aaa.txt | 2 ++
 1 file changed, 2 insertions(+)
aaa.txtを変更してコミットしたという状況です。取り消すには、以下2つの方法があります。
# git上での変更のみ取り消し、ファイルシステム上のファイルはそのまま
$ git reset --soft HEAD^

# git上での変更取り消しと、ファイルシステム上でのファイル変更も取り消し
$ git reset --hard HEAD^
ここで「HEAD^」は、HEADリビジョンの1つ前まで取り消すという意味です。 特定のリビジョンまで戻すには、そのリビジョンのハッシュタグを指定します。
$ git log -3 --pretty=oneline
862ea1e9d3541c751183f0c546a646fb5ca702cd 革新的な実装ができた!ファイルも忘れず追加!
485b4a7170ef5d5639ca3a6fa198b1a31cc135fe add for test
12ac1cf45d87e27d3b606c686fe9bdc9f6174367 add for test2

# 2つ前まで戻す
$ git reset --hard 12ac1cf45d87e27d3b606c686fe9bdc9f6174367
ただし、すでにリモートにpushしてるcommitは取り消さない方が良いですね。他の人と共同で開発しているなら、てんやわんやです。。むちゃなresetはしないことが大切です。



最後に

今回の内容は以上です。 取り消しせずに実装がスムーズにできるのが一番良いですが、やっぱりそうは言っても、変更を取り消したいときって時々ありますよね。 ぜひそんな時に上のコマンドを使い分けて対応してみてください。

最後までご覧頂きましてありがとうございました。




[GruntJS] livereloadをする際に、watch発動から遅延時間を設ける

$
0
0
こんにちは、@yoheiMuneです。
LiveReloadって、ファイルの保存した時にブラウザを自動的にリロードできて便利ですよね(LiveReloadの使い方はこちらのブログをご参照ください)。

本日はそんな素晴らしいLiveReloadで、grunt-watch発動からブラウザリロードまでに遅延時間を設ける方法を書きたいと思います。

画像

引用:http://flic.kr/p/bGLSLZ




liveReloadで遅延時間を設けたい理由

現在活動しているプロジェクトでは、以下のフローでコーディングから確認までを行っています。
コーディング -> ファイル保存 -> grunt-watchで検知する -> grunt以外でのビルド※ -> liveReload -> ブラウザ確認

※grunt以外でのビルドでは以下のことを行っています。
・scssをcompassでコンパイルする(gruntよりも高速なため)。
・FTLというHTMLテンプレートを、gitプロジェクトからデモサーバー(Jetty)のドキュメントルートにコピーする。
このため、grunt-watchでファイル保存を検知してから、grunt以外でのビルドを待って、livereloadによるブラウザのリロードをしたいのです。



LiveReloadで遅延発動する

gruntのwatchでLiveReloadを使うために、Gruntfile.jsへ以下のように記載しています。
// Gruntfile.jsから抜粋
watch: {
    options: {
        // このオプションを付けることで、liveReloadが出来ます
        livereload: LIVE_RELOAD_PORT
    },
    ftl: {
        files: ['./**/*.ftl'],
        tasks: ['']
    },
    scss: {
        files: ['./**/*.scss'],
        tasks: ['']
    },
}
この場合、watchがファイル変更を検知するとすぐにブラウザをリロードしてしまい、grunt以外でのビルド作業がブラウザに反映されません。 livereloadの発動を遅延させるオプションを調べましたが、残念ながらありませんでした。

そのため、遅延する仕組みを以下のように作りました。
// Gruntfile.jsから抜粋
watch: {
    options: {
        livereload: LIVE_RELOAD_PORT
    },
    ftl: {
        files: ['./**/*.ftl'],
        tasks: ['exec:sleep_for_ftl'] // 待ち時間
    },
    scss: {
        files: ['./**/*.scss'],
        tasks: ['exec:sleep_for_sass'] // 待ち時間
    },
},
exec: { // grunt-execモジュールを追加する必要があります
    sleep_for_sass: {
        command: 'sleep 1'
    },
    sleep_for_ftl: {
        command: 'sleep 1.5'
    },
}
そうです。スリープさせるタスクを入れて、grunt以外でのビルド作業を待つようにしました。 聞くと簡単な仕組みですよね。でもかなり便利ですよ!!



最後に

簡単ですが、LiveReloadの発動を遅延させる方法でした。 今のプロジェクトに参加するまでこんなことしようとは思いもしませんでしたが、環境が変わればやりたいことも色々ですね。

最後までご覧頂きましてありがとうございました。



[git] gitのソースコードをブログで綺麗に表示するために、GitGistを使ってみる

$
0
0
こんにちは、@yoheiMuneです。
今日は、gitにあるコードを綺麗にブログなどに表示するための、GitGistというサービスを紹介したいと思います。

画像

引用:http://flic.kr/p/jW5kGc


目次は次の通りです。



GitGistとは

題名には「gitのソースコードを」と書きましたが、実際にはgit以外のソースコードも貼ることが出来るサービスです。 コードを貼付けて、スクリプトタグをブログに貼ることで、行数が表示されたり、色づけされたりと綺麗な状態でソースコードを表示することが出来ます。
以下がGistのページです。
画像
https://gist.github.com/



GitGistの使い方

使い方は簡単で上記のページにアクセスして、「ファイル名」「ファイルの種類」「ソースコード」の3点を入力して、「Create Public Gist」を押すと、公開するためのコードが作成出来ます。
画像

例えば作成した結果は、以下のようになります。
画像
ここで左袖にある「Embed thie gist」をブログに埋め込むと、ブログでソースコードが綺麗に表示されるのです。

(以下埋め込んでみた例)


うんうん、綺麗に表示されましたね。
注意すべき点は、他人のコードも貼付けて公開することが出来ますが、 ちゃんとライセンスを確認するか、その人の了承を取ってから公開する必要があることは忘れずにです。



実は、Gistはgitレポジトリ

上記の作成後の画面を見て頂くと分かるように、Gistは1つのgitレポジトリとして利用することができます。 画面左側にあるURLを使って、以下のようにローカルにクローンすることができます。
$ git clone https://gist.github.com/8859220.git
Cloning into '8859220'...
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Checking connectivity... done
クローンすれば、ローカルでの編集も簡単にできて、また履歴管理もgitを使って簡単にできます。 gitプロジェクトを作るほどでもないちょっとしたコードは、ここで作成して公開しちゃうのも良いかもしれません。



最後に

このブログではソースコードの表示にgoogle-code-prettifyを使っていますが、GitGistも便利そうなので使い分けて行ければと思います(gitレポジトリとして使える点が素敵と感じています)。 ソースコードを綺麗に表示することは、色々と設定が大変なので、GitGistみたいに気軽に出来るのは良いですね。

最後までご覧頂きましてありがとうございました!



[GruntJS] gruntからJenkinsのジョブを実行する

$
0
0
こんにちは、@yoheiMuneです。
今日はライトなネタですが、gruntからJenkinsのジョブを開始する方法をブログに書きたいと思います。

画像

引用:http://flic.kr/p/jvGd6b




JenkinsのジョブをJenkinsの画面以外から起動するには

Jenkinsのジョブを開始するには、Jenkinsの画面でビルドボタンをポチッと押す以外にも、HTTP通信を使ってジョブを開始することができます。
例えば、以下のURLのようなジョブがある場合、
#「build_frontend_module」という名前のジョブ
http://localhost:8080/job/build_frontend_module/
以下のURLにHTTP通信でアクセスすることで、ジョブを起動することができます(※1)
http://localhost:8080/job/build_frontend_module/build
また、何らかのパラメーターを付与してビルドしたい場合には(例えばgitのブランチ名をパラメーターで指定したい場合には)、
http://localhost:8080/job/build_frontend_module/buildWithParameters?PARAM=VALUE
といった感じで、パラメータ付きビルドを行うこともできます。
今回は、この仕組みを使って、gruntからJenkinsのジョブを実行しようと思います。

※1 詳細は、JENKINS/Remote+access+APIを参照ください。




準備:npmインストール

gruntで上記のURLアクセスをするために、grunt-execというnpmモジュールを使います。インストールは以下のように行います。
$ npm install grunt-exec --save-dev
また、watchを使ってファイル保存のたびにJenkinsビルドを行いたいので、grunt-contrib-watchも導入しておきます。
$ npm install grunt-contrib-watch --save-dev
これで準備は完了です。



Gruntfile.jsの作成と実行

それではGruntfile.jsを作成します。以下のように記載します。
module.exports = function(grunt) {

    grunt.loadNpmTasks('grunt-exec');
    grunt.loadNpmTasks('grunt-contrib-watch');

    // プロジェクト全体で利用するconfigを設定
    grunt.initConfig({

        // watch
        watch: {
            html: {
                files: ['./html/**/*.html'],
                tasks: ['exec:jenkins_html']
            }
        },

        // exec
        exec: {
            jenkins_html: {
                command: 'curl http://localhost:8080/job/copy_html_to_jetty/build'
            }
        },
    });

    grunt.registerTask('default', ['watch']);
};
上記では、execでcurlを使って(※2)、Jenkinsに対してHTTPリクエストを送信しています。 そしてHTMLファイルをwatchして、HTMLファイルの変更の度に、Jenkinsのビルドを自動で行うという仕組みを構築しています。 以下のように利用します。
# とりあえずGruntからJenkinsジョブを起動してみたい場合
$ grunt exec

# watchを使って、htmlの変更の度に、Jenkinsジョブを起動したい場合
$ grunt watch
これで、GruntからJenkinsのジョブを起動することができました。

※2 Windowsではcurlを使うことができません。cURLなどを別途インストールしてください。




+1:即座に実行する

さて、上記の実装でJenkinsのジョブを起動してみると、1つ分かる事があります。 それは、GruntからJenkinsのジョブをキックした際に、実際にジョブが開始されるまでにタイムラグがある、ということです。 これは、JenkinsがHTTPリクエスト経由のジョブ開始に対して、5秒間の保留時間をデフォルトで設定しているためです。 以下のように、delayパラメータを付与することで、即座にジョブを実行することができます。
http://localhost:8080/job/copy_html_to_jetty/build?delay=0sec
ちなみに何で5秒なんだろうと気になって、Jenkinsのソースコードを調べてみました(該当箇所はこちらのgetQuietPeriodメソッド)。ベタッと「5」という数値が書かれていますね。何かのノウハウなんだろうなぁーと理解。

ということで、ファイル保存からJenkinsビルドまでスムーズに行うためには、「?delay=0sec」というパラメーターを付与することが重要です。



最後に

今の仕事では、フロントサイドとサーバーサイドでビルドを共通化するために、Jenkinsが導入されています。 今まではGruntからJenkinsを実行しようなんて思ってもみなかったですが、環境が変われば使い方も変わるもんですね。

最後までご覧頂きましてありがとうございました。



[CSS] CSSで長さなどを計算できちゃうcalc

$
0
0
こんにちは、@yoheiMuneです。
CSSでは、長さなどの数値をcalcというもので計算する事が出来ます。今日は、そのcalcについてブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/9fBHYt



CSSで計算ができるcalcとは

calc()という関数を使うことで、長さ、角度、時間、フォントサイズなどの数値で表現可能な値を、計算する事が出来るようになります。 例えば以下のような使い方ができます。
width: calc(100px - 80px);
calc()が力を発揮するのは、以下のような場合です。
width: calc(100% - 80px);
そうです!%の単位とpxの単位を混ぜても使う事が出来るのです。これができると、レスポンスデザインをより組みやすくなりそうですよね。



calcのサポート状況

さて、便利な機能を知ると気になるのが、ブラウザのサポート状況です。 Can I useによると、サポート状況は以下の状況です。

以下のキャプチャはブログ執筆時の情報なので、最新情報はCan I useを参照ください。

画像
いつも通り、IEやAndroidブラウザではあまり動かないようですが、その他のChrome,Firefox,iPhone Safariでは機能するようです。 プログレッシブ・エンハンスメントを実装することで、現状でも使えそうですね。



calcを知る

それでは、calcの機能を学んでみたいと思います。calcでは四則演算を行う事ができ、以下のオペランドを使う事が出来ます。
オペランド意味
+加算します
-減算します
*乗算します
/除算します
オペランドの優先度は、数学と同じく、乗算と除算が、加算と減算よりも優先されます。以下のように利用する事が出来ます。
width: calc(100px + 200px * 2); /* 500px */
また、オペランドの優先度を使うために、()を利用する事も出来ます。
width: calc((100px + 200px) * 2); /* 600px */

そしてcalc()のすばらしいところは、同じ長さを表す違う単位を使う事が出来るという点です。例えば以下のように使う事が出来ます。
width: calc(100% / 3 - 2 * 1em - 2 * 1px);
ただし、長さの単位と時間の単位といった違う意味を示す単位は、混ぜ合わせて使うことはできません。以下の場合、エラーとなります。
/*エラーになる*/
font-size: calc(5px - 5px + 10s);
あと、仕様では、加算と減算の前後には空白スペースを置く必要があり、乗算と除算の前後には空白スペースを置く必要はありません。 そのため、以下のように記述でも動作します。

仕様上は機能しますが、オペランドの前後に空白を置くスタイルで統一した方が読みやすいと思います。

width: calc(100%/3 - 2*1em - 2*1px);



calc未対応のブラウザを考慮した実装

例えば、横幅の異なる画面で表示した際に、左右の余白を維持しながらコンテンツを拡大縮小したい、という要件があったとしましょう。 その場合に、calc()を使うと、以下のように実装する事ができます。
<style>
    .container input {
        width: calc(100% - 10px);
    }</style><div class="container"><input type="text"/></div>
まぁこんな簡単なものであれば、calc()を使わなくても十分に要件を満たすことができます(が、これは単なる例です)。 しかしもっと複雑な場合に、(きっと)calc()は生きてくるんだろうなぁーと思います(たぶんね)。

さて、上の実装の場合は、calc()が未対応のブラウザで表示が意図した通りになりません。 calc()をサポートしていないブラウザへの対応を以下のように実装します。
<style>
    .container input {width: 98%; /*calc()に未対応のブラウザ用*/
        width: calc(100% - 10px);
    }</style><div class="container"><input type="text"/></div>

ポイントは、未対応ブラウザに対して「width:98%;」を記述しておく事です。 これで、calcが機能しなかったとしても、一応デザイン崩れはしないように制御する事が出来ます。 calc()に対応しているブラウザでは、CSSの優先順位から、calcを用いたwidthが適用されます。



参考資料

この記事を書くのに、以下のページがすごく参考になりました。ありがとうございました。

calc - CSS | MDNCSS Values and Units Module Level3 #calc() | W3C


最後に

以上、calc()の説明でした。きっときっと使う場面がくるはずです。
今後も、このような細かい技術要素から大きな技術要素まで、フロントエンド技術についてこのブログで扱っていきたい思いますので、どうぞよろしくお願いします。

最後までご覧頂きましてありがとうございました。



[JS] タップイベントが実装されているのかを調べる方法(2つ)

$
0
0
こんにちは、@yoheiMuneです。
今日は、スマホ向けサービスの開発で必要になる、タップイベントが実装されているかを調べる方法をブログに書きたいと思います。

画像

Special Thanks to http://flic.kr/p/dP1Fjh



タップイベントの実装有無を調べる理由

主にスマホ向けのサービスを作っている時に、以下のようなことをしたい場合がよくあります。
var EVENT = {};
if (/*タップイベントが使える場合*/) {
    EVENT.TOUCH_START = 'touchstart';
    EVENT.TOUCH_MOVE = 'touchmove';
    EVENT.TOUCH_END = 'touchend';
} else {
    /*タップイベントが使えない場合*/
    EVENT.TOUCH_START = 'mousedown';
    EVENT.TOUCH_MOVE = 'mousemove';
    EVENT.TOUCH_END = 'mouseup';
}

// クリックやタップにイベントを貼る
$('#btn1').on(EVENT.TOUCH_END, function (e) {
    // タップされた場合の処理
});
上記のように、DOMにイベントを貼る場合に、PCでもスマホでも使えるようにしたいのですが、 その場合に「touchXXX」と「mouseXXX」のどちらを付与すれば良いのかを知りたいということなのです。

これは、例えばボタンがクリックされた場合に、
$('#btn1').on('click', function () {
    alert('クリックされたよー');
});
とすれば、PCでもスマホでもちゃんとイベントは発火するのですが、しかし、 スマホの場合にはclickイベントだとタップしてからタイムラグがあり遅いのです!つまり「使い勝手が悪く感じる」ということです。
そのため、スマホ用には、タップした場合の処理に以下のように実装します。
var tapEnable =false; // 有効なタップかを保持する
$('#btn1').on('touchstart', function () {
    tapEnable = true;

}).on('touchmove', function () {
    // スクロール用のタップの場合とかは、ボタンタップは発火させない。
    tapEnable = false;

}).on('touchend', function () {
    if (tapEnable) {
        tapEnable = false;
        alert('タップされたよー');
    }
});
ということで、体感品質向上のために上のようなコードを書きたいのです。 しかし上記のようにtouchstartなどをべたっと書くと、PCでは押せないボタンになってしまいます。 そのような場合に、touchXXXとmouseXXXのどちらを使うか、を知りたいのです。



タップイベントが存在するかを判定する方法 その1

まず1つめは、簡単な方法です。以下のようにタップイベントが存在するかをチェックすることができます。
var hasTapEvent = ('ontouchstart' in window);
これは、windowオブジェクトにontouchstartというプロパティが存在するかをチェックすることで、タップイベントが存在するかをチェックしています。
ただし上記の実装の場合、上のコードを実行する前に、なんらかのJSがwindowオブジェクトにontouchstartプロパティを追加していたら、誤判定してしまいます。
この問題に対処するには、HTMLでの記述順を注意するか、または以下のように判定を行うことで対応することができます。
var hasTapEvent;

// iframeを新規に作って、汚されていないiframeのwindowを使って判定する。
var iframe = document.createElement('iframe');
document.body.appendChild(iframe);
hasTapEvent = ('ontouchstart' in iframe.contentWindow);
iframe.remove();
基本的にはこの方法でいいかなぁー、と思います。



タップイベントが存在するかを判定する方法 その2

もう1つは、最近見かけたコードなのですが、こーゆうのもできるのかと思ったコードです。
var hasTapEvent = (function(){
     var div = document.createElement('div');
     div.setAttribute('ontouchstart', 'return');
     return (typeof div.ontouchstart === 'function');
})();
自分が試してみたところ、Chrome(ver.32)ではtapイベントをエミュレートしてもfalseになりましたが、iPhoneのSafariやAndroidのブラウザではtrueになるようです。 色々な実装があるもんだなぁー、と感じた次第でした。



最後に

今日は、タップイベントが実装されているかを判定する方法でした。 スマホ向けWebサービスを作る際に、使い勝手を向上しようとすれば(きっと)必要になることなので、どなたかの役に立てばいいなぁと思います。

最後までご覧頂きましてありがとうございました。



[マークアップ] Pixel Perfectを実現するためにとても役立つ、ブラウザのエクステンション

$
0
0
こんにちは、@yoheiMuneです。
マークアップ作業でPhotoshopなどのデザインと微調整する時に、便利なブラウザ用のエクステンションを発見!今日はそのツールを紹介したいと思います。

画像

Special Thanks to http://flic.kr/p/kiy6X6



Pixel Perfect

Pixel Perfect(ピクセル・パーフェクト)とは、Photoshopなどのデザインとブラウザの表示を、1pxの狂いもなく合わせるというものです。 現実的には、ブラウザによって横幅や利用可能フォントが違うので「寸分の狂いもなく」というのは難しいですが、 出来る限りデザインとブラウザのレンダリングを合わせることは、マークアップにおいて重要な作業です。

その調整作業を行うために、今までは以下のような方法で、デザインとのマークアップのずれを確認していました。
  • ブラウザとPhotoshopを横に並べて比較する
  • ブラウザでの表示をキャプチャして、PSD上でデザインと重ね合わせる
前者の場合には、差分がだいたいしか分からず、特に後者はめんどうな作業でした。
この問題を解決してくれるのが、「PerfectPixel」というエクステンションです。以降では、そのエクステンションを紹介したいと思います。



Pixel Perfectをサポートするエクステンション

このブラウザエクステンションは、Chrome,Firefox,Safari,IEそれぞれにエクステンションが用意されていて、様々なブラウザで使えるようです。 私はChromeエクステンションを使っています。 以下が本家ページです。
画像

http://www.welldonecode.com/perfectpixel/

このエクステンションでは、デザインで作成した画面の画像を、ブラウザ上で半透過で表示して、マークアップとデザインのずれを確認する事ができます。 またChromeなどのデバッグツールを使えば、ずれを確認しながらCSSを調整して、いい感じにマークアップを修正する事ができます。
本家サイトに掲載されている紹介動画がすごく分かりやすかったので、以下に貼付けておきます。



個人的な感想としては、このエクステンションを使う事で、視覚的に分かりやすく、はっきりと誤差が分かるので、便利だなぁと感じています。



最後に

今日は、ピクセル・パーフェクトを目指すために便利な、エクステンションを紹介しました。 マークアップを行うどなたかの役に立てば幸いです。

最後までご覧頂きましてありがとうございました。



[JS] ブラウザの実装状況に合わせて、ベンダプレフィックスを使い分けてCSSを設定する

$
0
0
こんにちは、@yoheiMuneです。
今日は、JSからDOM要素にCSSを設定する場合に、ブラウザのサポート状況に合わせて、いい感じにCSSを指定する方法をブログに書きたいと思います。

画像

Special Thanks to http://flic.kr/p/kpTpJ6



1、UserAgentを利用して、ベンダープレフィックスを使い分ける

まず1つ目の方法として、UserAgentから利用してベンダープレフィックスを使い分ける方法があります。 実装方法は、事前にUserAgentを調べてベンダープレフィックスを把握しておき、実際にCSSを設定する時にそれを使うという方法です。
例えば以、transitionを設定する場合には、以下のような実装となります。
// UAを元に必要なベンダープレフィックスを見分ける。
var venderPrefix = (/webkit/i).test(navigator.appVersion) ? 'webkit' :
                        (/firefox/i).test(navigator.userAgent) ? 'moz' :
                        (/trident/i).test(navigator.userAgent) ? 'ms' :
                        'opera' in window ? 'O' : '';

// ベンダープレフィックスを使って、CSSを設定する。
var elm = document.querySelector('#foo');
elm.style[venderPrefix + 'Transition'] = 'opacity 1s ease-in-out';
数行程度の簡単な実装ですね。
これを用いる場合には、以下のようなことを考慮する必要があります。
「指定するCSSはベンダープレフィックス付きで動作することが確約されている」

外に公開せず自前で使う場合や、transitionやtransformなどを限定で扱う場合には、このような簡単な実装が良いですね。



定義されているCSSから調べる

次に、定義済みのCSSを調べて、それに合わせてCSS名を判定する方法です。 定義済みのCSSは、以下のように取得する事ができます。

(IE8は対象外、Android2系/3系は一部サポートです。詳細はこちら

// 実装されているCSSを一覧で表示する
var dec = getComputedStyle(document.head, '');
for (p in dec) {
    if (dec.hasOwnProperty(p)) {
        console.log(p + ' : ' + dec[p]);
    }
}

// 実行例(抜粋)
// webkitAnimation : none 0s ease 0s 1 normal none running VM142:6
// webkitAnimationDelay : 0s VM142:6
// webkitAnimationDirection : normal VM142:6
// webkitAnimationDuration : 0s VM142:6
// webkitAnimationFillMode : none VM142:6
// webkitAnimationIterationCount : 1 VM142:6
// webkitAnimationName : none 
この情報を利用して、与えられたCSS名に対して、利用可能なCSS名を返す関数を定義することができます。
/*
* 注意:すごく簡易的な実装です。Webkitのみです。
*/
var dec = getComputedStyle(document.head, '');
var getCssName = function (cssName) {


    // 与えられたCSS名からハイフンを取り除く
    cssName = cssName.replace(/-/g, '');

    // 定義済みのCSS名を探す
    var reg1 = new RegExp('^' + cssName + '$', 'i');
    var reg2 = new RegExp('^(webkit|moz|ms)' + cssName + '$', 'i');
    var nameWithPrefix;
    for (prop in dec) {
        if (dec.hasOwnProperty(prop)) {
            if (reg1.test(prop)) {
                // ずばりそのものを発見!
                return prop;
            } else if (reg2.test(prop)) {
                // ベンダープレフィックス付きを発見!
                return prop;
            }
        }
    }

    // 残念、見つからず。
    return null;
}
例えばChrome(v.33)の場合、以下のように動作します。
getCssName('transition'); // => transition
getCssName('text-stroke-color'); // => webkitTextStrokeColor
ベンダープレフィックスが必要なCSSプロパティには、ベンダープレフィックス付きの名前が返却されます。

getComputedStyleは、(上記の使い方ではありませんが)jQueryやzeptoでもCSSの実装確認に使われているようです。
上の実装はwebkit限定で、例えばfirefoxの場合には動作しません。firefoxでは、getComputedStyleで保持するCSS名は、ハイフン記法で保持しているようです。本当に実験的な実装です。

jQueryでgetComputedStyleが利用されている例):
/*
    jquery / src / css / var / getStyles.js
    http://git.io/8aByoA
*/
define(function() {
    return function( elem ) {
        return elem.ownerDocument.defaultView.getComputedStyle( elem, null );
    };
});


/*
    jquery / src / css / support.js
    http://git.io/6z7FZA
*/
function computePixelPositionAndBoxSizingReliable() {
    div.style.cssText =
        // Support: Firefox<29, Android 2.3
        // Vendor-prefix box-sizing
        "-webkit-box-sizing:border-box;-moz-box-sizing:border-box;" +
        "box-sizing:border-box;display:block;margin-top:1%;top:1%;" +
        "border:1px;padding:1px;width:4px;position:absolute";
    div.innerHTML = "";
    docElem.appendChild( container );

    var divStyle = window.getComputedStyle( div, null );
    pixelPositionVal = divStyle.top !== "1%";
    boxSizingReliableVal = divStyle.width === "4px";

    docElem.removeChild( container );
}
zepto.jsで利用されている例):
/*
    zepto / src / ie.js
    http://git.io/njJPSg
*/
// getComputedStyle shouldn't freak out when called
// without a valid element as argument
try {
  getComputedStyle(undefined)
} catch(e) {
  var nativeGetComputedStyle = getComputedStyle;
  window.getComputedStyle = function(element){
    try {
      return nativeGetComputedStyle(element)
    } catch(e) {
      return null
    }
  }
}



最後に

jqueryとかzeptoとかjquery.transitとか、JSからCSSを指定する際に、ブラウザ別にどうやって処理を分けているんだろうなぁと思い、調べました。 調べてみるとgetComputedStyleというメソッドがあることを知り、使ってみたいと思い、試しに使ってみた次第でした。 自分のコードでは実線に投入できるほど、安定とパフォーマンスを発揮しませんが、getComputedStyleの雰囲気を伝えられていれば幸いです。

最後までご覧頂きましてありがとうございました。




[git] Gitの内部(はじめに)

$
0
0
こんにちは、@yoheiMuneです。
最近Pro Gitという本を読んでいます。 今日は、その本から学んだgitの内部について、はじめの部分をブログに書きたいと思います。

画像

Special Thanks to http://flic.kr/p/aWTB1r



Gitの内部を学ぶことの意義

Gitの内部構造や実装を学ぶことで、Gitがどのように動作しているかを理解することができ、その結果としてより便利に強力にGitを使えるようになります。 Gitの内部を学習する意義は、この点が一番大きいですね。

gitは、連想記憶ファイルシステム(content-addressable filesystem)上に構築されたバージョン管理システムである、という点を理解しておく必要があります。この点は他のバージョン管理システム(SVNなど)とは異なる点で、gitの大きな特徴です。

SVNなどのバージョン管理では、1つのファイルはコミットごとにコミット前後の差分を保持します。しかしGitでは、特定のファイルの特定のリビジョンに対してハッシュ値を生成し、そのハッシュ値を用いてその時のファイルにダイレクトにアクセスすることができます。

gitのバージョン1.5より前では、このファイルシステムという考えが押し出されていたため、少し複雑で使いづらいUIとなっていたようです。 しかし最近では、gitのUIは再定義され、使い勝手は少し改善されました。

この連想記憶ファイルシステムという仕組みについては、次回以降に詳しく取り上げたいと思います。 今回のブログでは、それを説明する前段となる部分を解説します。



一般的なUIと内部的なUI

Gitには、一般的に利用される機能(pull, commit, add, push, branch,など)がたくさん存在します。git helpを使って、どのようなコマンドがあるかを調べることができます。
$ git help
The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find by binary search the change that introduced a bug
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty Git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and merge with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object signed with GPG
そして上記の一般的に良く利用する機能以外にも、様々な内部コマンド(=下位レベルのコマンド)が存在します。 例えば、git hash-objectgit cat-filegit write-treeなどです。

gitの内部を知るためには、それらの内部コマンドを利用することになります。 gitの内部コマンドを使うことで、Gitの中で何がどのように動作しているのかを知る手助けとなります。 それぞれの内部コマンドは、必要な場面でそれぞれ説明できればと思います。



gitレポジトリの構造

ここでは、gitレポジトリの構造について説明します。 まずは、git initコマンドでレポジトリを新規作成してみましょう。
$ git init
Initialized empty Git repository in /Users/munesadayohei/tmp/test/.git/
git initを実行すると、.gitディレクトリが作成されました。 この.gitディレクトリは、Gitにおいてコアとなる存在なのです。 例えばgitレポジトリをバックアップしたりクローンしたい場合には、この1つのディレクトリをどこか違うディレクトリにコピーすれば、 必要なことのほとんど全てができてしまいます。 Gitの内部構造を知るために、以降ではこの.gitディレクトリを中心に扱っていきたいと思います。

それではさっそく、先ほど作成したレポジトリの.gitの中を見てみましょう。
$ ls .git
HEAD
branches/
config
description
hooks/
index  # もしかしたらこれは最初は無いかも
info/
objects/
refs/
.gitディレクトリは、上記のファイルやディレクトリで構成されています。 既に利用中のレポジトリの場合には、他にもいくつかのファイルが存在するかもしれません。

これらの中で特に重要なものは、HEADファイル、indexファイル、objectsディレクトリ、refsディレクトリです。それぞれの構成要素の役割は、以下の通りです。
objects
このディレクトリは、gitレポジトリの実際のデータ(プログラムファイルや画像など)を全て保管しています。
refs
このディレクトリは、データ(やブランチ)内のコミットオブジェクトを指すポインターを保持します。
HEAD
このファイルは、チェックアウトしているブランチを指し示します。
index
このファイルは、Gitがステージングエリアの情報を保持する場所です。
これらの構成要素を利用してバージョン管理を行います。
なお、上記以外にも以下の要素が.gitには含まれます。
config
このファイルは、プロジェクト固有の設定内容(リモート先やサブモジュールなど)の情報を保持します。
description
このファイルは、GitWebプログラムで利用されるファイルです。
info
このディレクトリは、.gitignoreには書きたくないような追跡除外パターンを書くための、グローバルレベルの除外設定ファイルを保持します。
hooks
このディレクトリは、クライアントサイドやサーバーサイドで利用するフックスクリプトを保持します。
これらの構成要素も便利なものではありますが、gitの内部構造や動作を学習するためにはあまり重要でないため、以降では扱わないと思います。



参考資料

Gitの内部挙動を理解するために、以下の資料を参照しました。ありがとうございます。

Pro Git | git-scm.com/book



最後に

今回は、gitの内部についてのはじめの部分を扱いました。.gitディレクトリがGitではキーとなる要素なんですね。 次は、バージョン管理で保管されている対象そのものであるobjectについて、見ていければと思います。

最後までご覧頂きましてありがとうございました。



[git] Gitの内部におけるデータ格納方法について

$
0
0
こんにちは、@yoheiMuneです。
先日に引き続き、gitの内部の仕組みについてブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/eGGbYz




この記事で伝えたいこと

この記事の目的は、なぜGitが連想記憶ファイルシステム(content-addressable filesystem)なのかを理解してもらう、ということです。 前回から引き続き、Gitの内部の仕組みを扱います。



Gitのオブジェクト

以下の内容は、Pro Gitを多く参照しています。


Gitの内部(はじめに)でも簡単に触れましたが、gitは連想記憶ファイルシステム(content-addressable filesystem)上に構築されたバージョン管理システムです。 これは、Gitのコア部分が、キーバリューから成るデータストアである、ということを意味しています。そしてそのデータは、.git/objects/で管理されます。

.git/objects/にデータが増えるタイミングは、通常、git commitなどのコマンドが実行された時で、コミット対象のファイルのデータが格納されます。 この記事ではgit commitコマンドではなく、内部コマンドを利用することで、Gitデータストアの仕組みについて触れたいと思います。

まずは、新規にGitレポジトリを作成し、.git/objects/の中を見てみましょう。
$ mkdir test
$ cd test
$ git init
Initialized empty Git repository in /tmp/test/.git/

# 中身を全部確認してみる
$ find .git/objects
.git/objects
.git/objects/info
.git/objects/pack

# ファイル(Notディレクトリ)の存在を確認する
$ find .git/objects -type f
$
infopackというディレクトリが存在し、ファイルは存在していません。 つまりデータは何も格納されていない、空のレポジトリということです。


Gitデータストアにデータを保存する
それでは、Gitの内部コマンドであるgit hash-objectを使って、Gitデータベースにデータを保存してみましょう。
$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4
-wオプションは、hash-objectコマンドに、オブジェクトを格納するように伝えます。-wを付与しない場合には、受け取ったデータに対応するキーは何かを返すだけです。--stdinは標準入力をデータとして受け取るためのオプションです。 これを指定しない場合には、hash-objectはファイルパスを探そうとします。

さて、hash-objectを実行した結果、40文字のハッシュ値を得られました。この値はSHA-1で生成した値で、Gitデータベースに保存したデータのキーです。このハッシュ値は、git logなどで見慣れたものではないでしょうか。

それでは、格納したデータが.git/objects/に存在するか確認しましょう。
$ find .git/objects -type f
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
.git/objects/に保存されていることが分かります。見ると分かりますが、40文字のハッシュ値のうち、最初の2文字をディレクトリ名に割り当て、残りの38文字をファイル名に割り当てています。


Gitデータストアからデータを取り出す
このファイルをcatコマンドで表示してみましょう。
$ cat .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
xK??OR04f(I-.QH??+I?+?K?
ううう、文字化けした値が返ってきました。これは、格納されたデータは圧縮されているため、文字列として表示すると文字化けしてしまうのです。 具体的な中身を確認するためには、内部コマンドであるgit cat-fileを利用します。
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content
今度はちゃんと、保存したデータが表示されました。-pオプションを付けることで、コンテンツを分かりやすく表示する事ができます。


簡単なバージョン管理を行ってみる
今までの内容を利用することで、簡単なバージョン管理を行う事ができます。 ここでは、test.txtに複数回書き込んだ後に、最初の書き込みに戻す、ということをやってみましょう。
# test.txtを新規に作成します
$ echo 'version 1' > test.txt

# Gitデータベースに書き込みます
$ git hash-object -w test.txt
83baae61804e65cc73a7201a7252750c76066a30
これでtest.txtのバージョン1のデータがGit上に作成されました。 続いて、バージョン2を作成します。
# 内容を上書きする
$ echo 'version 2' > test.txt

# Gitデータベースに書き込みます
$ git hash-object -w test.txt
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
これで、バージョン2が作成できました。.git/objects/の格納状況を確認してみます。
$ find .git/objects -type f
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a  # test.txtのバージョン2
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30  # test.txtのバージョン1
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4  # 最初の説明で作ったもの
ちゃんとデータが保存されていますね。 ここで、text.txtのバージョン1の内容に戻して(revertして)みましょう。git cat-fileコマンドを利用します。
$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
$ cat test.txt
version 1
ちゃんと戻りましたね。バージョン2の内容にするには、以下のように行います。
$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt
$ cat test.txt
version 2
Gitデータベースから任意の状態のtest.txtが復元できますね。


なぜGitが連想記憶ファイルシステムなのか
以上、簡単な説明ですが、Gitのデータ保存の仕組みについて説明しました。 説明で触れた通り、SHA-1で生成した40文字のハッシュ値を使うことで、任意のファイルの任意の状態にアクセスすることが出来ます。 つまり、40文字のハッシュ値がキーであり、保存されたデータがバリューであり、 それを保存するGitはキーバリューストア(Key-Value Store)なのです。

さて、この記事では主にデータを対象に、.git/objects/に保存しましたが、他にもツリーオブジェクトやコミットオブジェクトというオブジェクトも存在します。今後の記事でそれらも扱えればと思います。



参考資料

Gitの内部挙動を理解するために、以下の資料を参照しました。ありがとうございます。

Pro Git | git-scm.com/book



最後に

今回は、Gitの内部の仕組みについて、Objectを取り上げて説明しました。Gitがなぜ連想記憶ファイルシステムなのか、少しでも理解頂けていたら幸いです。 Gitの内部構造、学び始めると楽しいですね。

最後までご覧頂きましてありがとうございます。



[フロントエンド] Webページを表示するテストの際に、通信速度を3Gに制限して表示してみよう

$
0
0
こんにちは、@yoheiMuneです。
今日は、Webページのテストをする際に、通信速度を制限して表示テストを行う方法について、ブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/kwpwtG



この記事で伝えたいこと

この記事の目的は、次の2点を説明することです。 それは、なぜ通信速度を制限して表示テストを行う必要があるのか、それをどのように実現するのか、ということです。 この記事を読むことで、Webアプリケーション構築において、初期表示の品質向上を行うきっかけを掴んで頂けたら幸いです。



なぜ通信速度を制限してテストする必要があるのか

はじめに、なぜ通信速度を制限してWebページの表示を確認する必要があるのか、について考えてみましょう。 題材として、このブログであるYoheiM.NETを取り上げます(いくつかの問題点が存在するからです)。

このサイトを100Mbpsなどの高速な通信網で表示した場合には、問題なくすんなりと表示できるでしょう。 しかし、3G回線などの弱いネットワークを経由してYoheiM.NETにアクセスすると、以下のように表示となります。

まずはタイトルのみが表示されます。

画像

JSなどを読み込んでいます。まだ記事は表示されません。

画像

JSなどの読み込みが終わり、TopにあるGoogle Adsが読み込まれています。

画像

やっと記事が表示されました。広告などが歯抜けなところもあります。

画像

広告や検索バーなど、全ての要素が揃いました。

画像

遅いネットワークでテストすることで、「ユーザーにとって一番大切な記事の表示までに時間がかかっている」、という問題点が分かりました。 せっかく興味を持って来て頂いているのに、興味の対象が表示されるまで、何秒か待つ必要があるのです。 これはユーザーにとって、非常にストレスを感じる点でしょう。

このように、通信速度を制限して表示テストすることで、今まで見えてこなかった問題点を浮き彫りにすることができます。 そしてその問題点を解消することで、より多くの方に使いやすいWebアプリケーションを提供することができるようになります。



通信速度を制限したテストを行う方法

通信速度を制限する方法はいくつかありますが、今回はローカルプロキシの1つであるCharlesを使います。
画像

http://www.charlesproxy.com/documentation/tools/map-local/


ローカルプロキシとは、ローカル環境(=自分のPC)に設置できるプロキシ(=通信を中継してくれるようなやつ)です。 ローカルプロキシを用いることで、ブラウザーとWebサーバー間の通信を制御したり、通信内容を確認したりすることができます。 今回は、CharlesのThrottlingという機能を使って、ブラウザとサーバー間の通信速度を制御します。


Charlesのダウンロードとインストールは、以下から行うことができます。
http://www.charlesproxy.com/documentation/tools/map-local/

インストールしたら、まずはCharlesを起動します。
画像
起動すると、Proxyを自動的に変更する権限を求められるので、「Grunt Privileges」を選んで、権限をCharlesに与えます。 その後の初期画面は、以下のようになると思います。
画像
この状態だとプロキシとして正しく機能していない場合があるので、Macの場合には、Proxyの設定を開き、Proxyを有効にします。
画像 それでは、Chromeブラウザで「http://yoheim.net」にアクセスしてみましょう。 表示が、以下のように変わります。
画像 たくさんのリクエストが、Charles上を通過したことが分かります。 このリクエストの中身を見たり、変更したりすることもできて便利なのですが、それは別の機会に触れたいと思います。

さてそれでは、Charles上を通過するリクエストの通信速度を制限したいと思います。 通信速度の制限は、メニューのProxy -> Throttle Settingsから、以下の画面を開きます。
画像
「Enable Throttling」のチェックをOnにして、Throttle Presetで「3G」を選択します。
画像
これで「OK」ボタンを押すと、通信速度が制限された状態となりました。 Charlesの画面の旗マークが赤色に変わり、Throtllingがonになっていることが分かります。
画像
これ以降は、この旗マークをクリックすることで、ThrottlingのOn/Offを切り替えることができます。 この状態で、ChromeでYoheiM.NETにアクセスすると、今回アクセス頂いた表示とは異なる表示スピードで表示されるではないでしょうか。 このようにして、通信速度の制限を行い、表示テストをすることができます。

※ Charlesは有料アプリケーションですが、お試し版として無料で使うこともできます。お試し版の場合には、起動に10秒遅延が発生する、30分経つとCherlsが自動的にシャットダウンする、という機能制限があります。




最後に

今日は、通信速度を制限して表示テストを行う方法、についてブログに書きました。 通信速度を抑えると、Webページに対する見た目も変わり、より高品質なWebアプリケーションが作れると思います。
私はスマホ向けサービス開発を仕事にしていますが、この作業を行って、スマホなどの弱いネットワーク上でも快適に楽しんでもらえるように、改善を行ったりしています。

最後までご覧頂きましてありがとうございました。



[git] Gitの内部(ツリーオブジェクト)

$
0
0
こんにちは、@yoheiMuneです。
今回は、Gitのデータ格納方法のうち、ツリーオブジェクトについてブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/kxC7Bm



この記事を読む前に

この記事は、Gitの内部について書かれた、以下の記事の続きとして書いています。 以下の記事を先にお読み頂くと、今回の記事をより理解頂けるのではないかと思います。

[7]Gitの内部(はじめに)[7-1]Gitの内部(データ格納 - データオブジェクト)


この記事で伝えたいこと

この記事の目的は、Gitのツリーオブジェクトとは何か、を解説することです。 ツリーオブジェクトの中身を見る、ツリーオブジェクトを作成するという内容を通して、ツリーオブジェクトに対する知識を深められると思います。



ツリーオブジェクト

以下の内容は、Pro Gitを参照して、記載しています。

ツリーオブジェクトは、ステージングされたデータ関する情報を保持するオブジェクトです。 ツリーオブジェクトは、ステージングされたファイルの名前やそのハッシュ値などを保持します。 ファイルシステムに例えると、データオブジェクトがファイルであり、ツリーオブジェクトがディレクトリのようなものです。


ツリーオブジェクトの中身を見る
それではまずは、ツリーオブジェクトの中身を見てみましょう。 以下では、masterブランチ上での最後のコミットが参照しているツリーオブジェクトを表示しています。
$ git cat-file -p master^{tree}
100644 blob a906cb2a4a904a152e80877d4088654daad0c859  README
100644 blob 8f94139338f9404f26296befa88755fc2598c289  Rakefile
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0  lib
このツリーオブジェクトには、2つのデータオブジェクトと1つのツリーオブジェクトが含まれていることが分かります。 それぞれのデータに対して、以下の情報が格納されています。
モード
100644などの数値部分。そのデータがどのようなものかを示す。例えば、100644はファイル、100755は実行可能ファイル、120000はシンボリックリンクを表します。
データ種類
blobなどの表示部分。Gitにおけるデータの種類を示します。
ハッシュ値
そのデータを参照するためのSHA-1で作成した40文字のハッシュ値
名前
READMEなどの表示部分。ファイル名やディレクトリ名を示します。
上記のツリーオブジェクトには、libというツリーオブジェクトが含まれています。その内容を表示してみましょう。
$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b  simplegit.rb
libツリーオブジェクトには、1つのBlogデータが含まれていることが分かります。
上記の内容から、master^{tree}の中身を、以下のように図示することができます。
画像

引用:http://git-scm.com/book/en/Git-Internals-Git-Objects

以上が、ツリーオブジェクトが保持する内容です。


ツリーオブジェクト作成する
それでは続いて、ツリーオブジェクトを作成してみましょう。 Gitでは通常、git addなどのタイミングでツリーオブジェクトが作成されます。 しかしここでは、ツリーオブジェクトをより理解するために、 git update-indexgit write-treeなどの内部コマンドを使って、ツリーオブジェクトを作成してみましょう。

以降で利用するレポジトリは、前回の記事で作成したレポジトリを利用しています。


前回の記事では、test.txtというファイルで"version 1""version 2"という2つのバージョンのファイルを作成しました。
$ find .git/objects -type f
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30  # test.txtのバージョン1
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a  # test.txtのバージョン2
# 他のハッシュは省略しています

$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30
version 1

$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
version 2
最初に、"version 1"のtest.txtのみを持つツリーオブジェクトを作成してみたいと思います。 まずは、git update-indexを使って対象ファイルをステージング状態にします。
git update-index --add --cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 test.txt
--addオプションは、最初のバージョンのtest.txtが新規ファイルでステージングエリアに存在しないため、付ける必要があるオプションです。 --cacheinfoは、ディレクトリには存在せずデータベースにのみ存在する(ディレクトリにはtest.txtという同名のファイルがありますが、内容は"version 2")ため、データベースからステージングに追加するために必要なオプションです。 100644は、データの種類を指定しています。

現在の状態は、以下の通りです。
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   test.txt  #ステージングしたファイル
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   test.txt  #前回作成した"version 2"のファイル
#
ステージングされているtest.txtが、git update-indexで追加したもので、ステージングされていないファイルが、前回の最後に作成したtest.txtです。

この状態で、ツリーオブジェクトを作成しましょう。git write-treeという内部コマンドを利用します。
$ git write-tree
d8329fc1cc938780ffdd9f94e0d364e0ea74f579
これでツリーオブジェクトが作成されました。中身を確認しましょう。
$ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579
100644 blob 83baae61804e65cc73a7201a7252750c76066a30      test.txt
また、-tオプションを付けることで、オブジェクトの種類を知ることができます。
$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
tree
無事にツリーオブジェクトを作成することができました。

それでは続いて、もう1つツリーオブジェクトを作りましょう。
ここでは、現在ステージングされていない"versio 2"のファイルをステージングエリアに追加します。
$ git update-index test.txt
さらにもう1つ新規ファイルを追加して、ステージング状態にします。
$ echo 'new file' > new.txt
$ git update-index --add new.txt
現在の状況は、以下となります。
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   new.txt
#   new file:   test.txt
#
この状態で、ツリーオブジェクトを作成します。
$ git write-tree
0155eb4229851634a0f03eb265b69f5a2d56f341
これで、2つ目のツリーオブジェクトを作成する事ができました。中身を確認してみます。
$ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
100644 blob fa49b077972391ad58037050f2a75f74e3671e92  new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a  test.txt
このツリーは2つのデータオブジェクトを保持しています。 そしてtest.txtは、ハッシュ値から分かる通り、"version 2"のデータです。


それではここで、最初のツリー(d8329fc1cc938780ffdd9f94e0d364e0ea74f579)を2つ目のツリーのサブディレクトリとして、ステージングエリアに追加してみましょう。 git read-treeという内部コマンドを使うことで、ステージングエリア内にツリーを読み込む事ができます。 また、--prefix=(ディレクトリ名)オプションを付けることで、ステージングエリアの中に、既存のツリーをサブディレクトリとして読み込むことができます。 そしてその後、git write-treeでツリーを作成します。
$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
$ git write-tree
3c4e9cd789d88d8d89c1073707c3585e41b0e614
$ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614
040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579  bak
100644 blob fa49b077972391ad58037050f2a75f74e3671e92  new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a  test.txt
さてここで作成したツリーは、2つのBlobデータと、1つのツリーオブジェクトを保持しています。 これらの構造を概念的に示すと、以下のようになります。
画像

引用:http://git-scm.com/book/en/Git-Internals-Git-Objects




最後に

今回は、Gitの内部におけるデータ格納方法のうち、ツリーオブジェクトについて扱いました。 ツリーオブジェクトは、ステージングされた状態を保持するための大切な情報であり、次に説明するコミットオブジェクトで利用されます。 前回、今回、そして次に説明するコミットオブジェクトを学ぶことで、Gitのデータストアの基本を知ることができると思いますので、乞うご期待下さいw。

最後までご覧頂きましてありがとうございました。



[git] Gitの内部(データ格納 - コミットオブジェクト)

$
0
0
こんにちは、@yoheiMuneです。
今日も引き続き、Gitのデータ格納について扱いたいと思います。本日はコミットオブジェクトです。

画像

Special Thanks to http://flic.kr/p/6r2wNh



この記事を読む前に

この記事は、Gitの内部やデータ格納方法について書かれた、以下の記事の続きとして書いています。 以下の記事を先にお読み頂くと、今回の記事をより理解頂けるのではないかと思います。

[7]Gitの内部(はじめに)[7-1]Gitの内部(データ格納 - データオブジェクト)[7-2]Gitの内部(データ格納 - ツリーオブジェクト)


この記事で伝えたいこと

この記事では、コミットオブジェクトとは何か、を説明します。 この記事を読む事で、Gitのコミットがどのようなデータで成り立っているのか、を理解できると思います。



コミットオブジェクト

この記事は、前々回前回で作成したgitレポジトリを利用します。

データオブジェクトやツリーオブジェクトを扱うことができるようになりましたが、いまのところ、それらの中から特定のデータにアクセスするためにSHA-1のハッシュ値を利用する必要があります。 このハッシュ値はランダム文字列で、覚えられるような代物ではありません。 またツリーオブジェクトは、誰がいつ作成したのか、といった情報も持っておらず、誰がどのような意図で作成したのか、を知る術がありません。

そこで登場するのがコミットオブジェクトです。 コミットオブジェクトでは、ツリーオブジェクト(ある特定の状況におけるスナップショット)への参照と、誰がいつコミットしたのかといった情報を、保持することができます。

コミットオブジェクトを作成するには、参照する1つのツリーオブジェクトと、(もし存在すれば)直前のコミットの情報を指定する必要があります。 コミットオブジェクトの作成には、git commit-treeという内部コマンドを利用します。まずは、d8329fツリーを参照する、最初のコミットを作成してみましょう。
$ echo 'first commit' | git commit-tree d8329f
fdf4fc3344e67ab068f836878b6c4951e3b15f3d
作成したコミットオブジェクトの中身を、git cat-fileで見ることができます。
$ git cat-file -p fdf4fc3
tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Munesada Yohei <y.munesada@gmail.com> 1393845711 +0900
committer Munesada Yohei <y.munesada@gmail.com> 1393845711 +0900

first commit
コミットオブジェクトの中身が表示されました。参照しているツリーオブジェクト、作成者(author)、コミットした人(committer)、コミットコメントが表示されていることが分かります。

さらに続いて、2つのコミットを作成しましょう。
$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3
cac0cab538b970a37ea1e769cbbde608743bc96d

$ echo 'third commit'  | git commit-tree 3c4e9c -p cac0cab
1a410efbd13591db07496601ebc7a059dd55cfe9
今回のコミットでは、-pオプションの後に、直前のコミットのハッシュ値を指定しています。 これによりコミットの前後のつながりを作ることができます。 作成したコミットを、git logで確認することができます。
$ git log --stat 1a410e
commit 1a410efbd13591db07496601ebc7a059dd55cfe9
Author: Munesada Yohei <y.munesada@gmail.com>
Date:   Mon Mar 3 18:15:24 2014 +0900

    third commit

 bak/test.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

commit cac0cab538b970a37ea1e769cbbde608743bc96d
Author: Munesada Yohei <y.munesada@gmail.com>
Date:   Mon Mar 3 18:14:29 2014 +0900

    second commit

 new.txt  |    1 +
 test.txt |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d
Author: Munesada Yohei <y.munesada@gmail.com>
Date:   Mon Mar 3 18:09:34 2014 +0900

    first commit

 test.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Gitのaddcommitといったコマンドを使わなくても、Gitの履歴を構築することができました。 このように、コミットオブジェクトは、ツリーオブジェクトや直前のコミット、作成者やコミッター、コミットメッセージ、といった情報を保持します。

今までに作成したGitのデータを確認してみましょう。
$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d
なんのこっちゃ分かりませんね。コメントを付与してみると、以下の感じです。
$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
今までに作成した、データオブジェクト、ツリーオブジェクト、コミットオブジェクトが格納されていることが分かります。 Gitはこれらの3種類のデータを主に使って、データ管理を行います。上記のオブジェクトを図示すると、以下のようになります。
画像

引用:http://git-scm.com/book/en/Git-Internals-Git-Objects




最後に

今回はコミットオブジェクトについて扱いました。 前々回前回で扱ったデータオブジェクトやツリーオブジェクトも含め、これら3種類のデータで、Gitのデータ管理が行われています。すごくシンプルな仕組みですね。
今後もGitの内部動作について、ブログを書ければと思います(フロントエンドなネタも書く意気込みです!!)。

最後までご覧頂きましてありがとうございました。



[フロントエンド] スマホ実機でのデバッグ手段を増やす!Macのプロキシを利用して、通信内容を確認する。

$
0
0
こんにちは、@yoheiMuneです。
今日は、プロキシを使ってスマホの通信内容を確認する方法について、ブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/7Sd7hc




この記事で伝えたいこと

スマホ向けWebアプリケーションのテストにおいて不具合が発生した場合に、スマホ実機にてデバッグする方法の1つを解説します。
今回は、MacのApacheをプロキシサーバーとしてセットアップし、スマホの通信をMac経由にすることで、 スマホとサーバー間の通信内容を確認する、という内容です。

スマホ実機でのデバッグはなかなか大変ですが、そのデバッグの1手段として使ってもらえれば幸いです。



Macのプロキシを設定する

まずはMacBookにインストールされているApacheに、プロキシをインストールします。 まずは、Apacheでプロキシが使えるかを確認します。
# $ cat /etc/apache2/httpd.conf

# ここらへんのモジュールロードが、コメントアウトされていないかを確認します。
# たぶん最初から大丈夫なはず。
LoadModule proxy_module libexec/apache2/mod_proxy.so
LoadModule proxy_connect_module libexec/apache2/mod_proxy_connect.so
LoadModule proxy_ftp_module libexec/apache2/mod_proxy_ftp.so
LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so
LoadModule proxy_scgi_module libexec/apache2/mod_proxy_scgi.so
LoadModule proxy_ajp_module libexec/apache2/mod_proxy_ajp.so
LoadModule proxy_balancer_module libexec/apache2/mod_proxy_balancer.so

# 以下の記述がコメントアウトされていないかを確認します。
# たぶん最初から大丈夫なはず。
Include /private/etc/apache2/other/*.conf
続いて、Proxyの設定ファイルを作成します。
# 「/private/etc/apache2/other/proxy.conf」を新規作成
<IfModule mod_proxy.c>
    ProxyRequests On
    ProxyVia On<Proxy *>
        Order deny,allow
        Deny from all
        Allow from 192.168.1</Proxy></IfModule>
上記の設定の場合、「192.168.1.*」のIPアドレスからの処理を受け付けます。 そしてApacheを再起動(起動していない場合には、起動)します。
# 再起動の場合
$ sudo apachectl restart

# 起動の場合
$ sudo apachectl start
これで、以下のURLを叩いて、Apacheの画面が表示されれば、起動成功です。
http://localhost
表示されない場合には、上記で記載した設定ファイル(または別の箇所)が壊れているので、頑張って修正します。


最後に、Mac本体のIPアドレスを確認します。
$ ifconfig | grep inet
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet6 fe80::9afe:94ff:fe45:cd21%en1 prefixlen 64 scopeid 0x8
inet 192.168.1.2 netmask 0xfffffff0 broadcast 192.168.1.15
複数のネットワークに繋いでいるといっぱい出てきますが、今回は「192.168.1.2」がMac本体のIPアドレスとします。 同じLAN上のiPhoneやAndroidから、(ネットワークが他機種との接続を禁止していない限り)、以下のURLでMacのApacheの画面を表示することができます。
http://192.168.1.2/
これでプロキシの設定は以上です。



iPhoneからMacのプロキシ経由で通信を行う

まずはiPhoneについて扱います。 iPhoneであればWebkit Webインスペクタとかで詳しく通信内容も確認できますが、一応説明します。

iPhoneでProxyを設定するためには、以下の手順で行います。

  1. 設定アプリを開く
  2. Wi-Fi設定を選ぶ
  3. Macと同じネットワークと同じWifiに接続する
  4. ネットワーク名右側に出る「(i)」というマークをタップする
  5. HTTP PROXYの欄に、プロキシサーバーの情報を入力する

プロキシサーバーの情報は、以下を入力します。
Server:192.168.1.2
Port:80
Authentication:OFF
この設定でProxyの設定が完了です。 Safariで、ネットワークエラーとかなくブラウジングできれば、設定成功です。



Android4系でプロキシを設定する

Android4系では、プロキシの設定を行うことができます。以下の手順で設定します。

  • 設定アプリを開く
  • Wifi設定を開く
  • Macと同じネットワークと同じWifiに接続する
  • 接続したWifiを長押し(ロングタップ)する
  • 詳細設定ダイアログが出るので、「ネットワーク設定変更」を選ぶ
  • 「拡張オプションを表示」をONにして、プロキシ設定を入力する


iPhoneと同様に、プロキシサーバーの情報は、以下を入力します。
Server:192.168.1.2
Port:80
Authentication:OFF
この設定でProxyの設定が完了です。ブラウザで任意のページが見れれば、設定は成功です。



スマホ端末の通信内容を見る

それでは、通信内容の確認をしてみましょう。Apacheのアクセスログを見ることで、リクエストを把握することができます。
# 設定を変えていなければ、以下の場所に表示されます
$ tail -f /private/var/log/apache2/access_log
172.20.10.6 - - [05/Mar/2014:16:46:59 +0900] "CONNECT www.google.co.jp:443 HTTP/1.1" 200 -
172.20.10.6 - - [05/Mar/2014:16:46:58 +0900] "CONNECT www.google.co.jp:443 HTTP/1.1" 200 -
こんな感じでIPアドレスと、通信先やそのHTTPステータスを確認することができます。 ログのフォーマットや出力内容を変える場合には、httpd.confなどの設定を変更します。詳細は、ログファイルの詳細 - Apache入門 | AdminWebなどを確認してみてください。



参考URL

このデバッグ手段を身に付けるために、以下の記事を参照しました。 貴重で有用な記事、本当にありがとうございます。

Mac の Web 共有で Proxy « LANCARD.LAB|ランカードコムのスタッフブログ
今回の記事では、主にこの記事を参考にさせて頂きました。

404 Blog Not Found:Apache - proxyを使って人様のアクセスをログする
この記事では、Apacheのプロキシ設定について、ポート番号の設定や、ログファイルの設定も書かれています。より実践的に使うなら、こちらも読むと良いと思います。

ログファイルの詳細 - Apache入門 | AdminWeb
Apacheのログフォーマットについて、初めて学んだのがこの記事でした。分かりやすくすごく良い記事です。



最後に

以上、Macを使ったスマホ実機の通信状況の把握を行う方法でした。 今回私は、この方法を使って、なぜかロード出来ない音声ファイルについて通信状況を把握するようなデバッグをしてました。 結果として、サーバーが特定の状況の時にのみ403を返却する事が分かり、なんとか解決しそうな次第です。

スマホ実機でのデバッグは大変ですが、少しずつ手数を増やしていきたいところです。
最後までご覧頂きましてありがとうございました。



[Android] ブラウザ上でのJSログをPCの画面で確認する

$
0
0
こんにちは、@yoheiMuneです。
Androidに取り組むことを決意!!特にAndroidブラウザやChromeに対する知識を深めて、開発やデバッグを行いやすいようにしたいと思います。
今日は、adbを使ってAndroidブラウザーのJSログを、PCで表示する方法を書きたいと思います。

画像

Special Thanks to http://flic.kr/p/bkDxsm




この記事で伝えたいこと

この記事では、Android端末をPCと接続して、PCでAndroidブラウザのログ(console.logなど)を確認する方法を説明します。 Androidはなかなかデバッグしづらいなぁと感じる毎日です。同じ思いを感じる人々に、自分の学んだデバッグ手法をお伝えできればと思います。



ブラウザ上でJSログを確認する一番簡単な方法

一番簡単な方法は、ブラウザのURL欄に「about:debug」と入力することです。 そうすると、JSログを表示するエリアが表われて、ログを確認することができます。
この方法はとてもお手軽でとりあえずログを確認する時などに重宝しますが、 ログのコピーが出来なかったり、ブラウザの領域を押しつぶしてしまったりと使いづらい点もあります。 今日紹介する方法を使うことで、より快適にAndroidブラウザのJSログを確認できるようになるのではないでしょうか。



adbをセットアップする

AndroidをPCからデバッグをするには、adb(Android Debug Bridge)というコマンドが必要です。まずはそれをインストールしましょう。
Android SDK | Android DevelopersからAndroid SDKをダウンロードして使います。 ダウンロードしたら、adbは(sdkインストールパス)/platform-tools/にあります。
今後のために、そのパスに環境変数を通しておくと便利です。以下は、.bashrcを利用してPATHにadbを登録するサンプルです。
# ~/.bashrc
# 以下の場合、SDKは~/Android/android-sdkにインストールされています。
PATH=$PATH:~/Android/android-sdk/platform-tools  # Android SDK
上記を~/.bashrcに記載して、ターミナルを再起動すると、以下のコマンドが使えます。
$ adb
これで、何か反応すれば、adbのインストールは完了です。
adbのインストールは様々なブログでも紹介されているので、android adb インストール | Google検索も参考にして頂けると幸いです。



Android端末のUSBデバッグを有効にする

続いて、Andrroid端末の設定を行います。Android端末の設定を変更し、PCからUSB経由でデバッグできるように設定します。 手順は以下の通りです。

Android4.2以上

Android4.2以上は、初期状態ではディベロッパーオプションが非表示となっており、まずそれを表示する必要があります。 ディベロッパーオプションを有効化するために、設定アプリを開き、「設定 > 端末情報」を開きます。 そして、「ビルド番号」のところを7回タップすると、ディベロッパーオプションを表示することができます(ちょっと不思議な作りですね)。
その後、「設定 >開発者向けオプション」を選んで、USBデバッグを有効にします。

Android4.1以下

Android4.1以下の場合には。「設定 >開発者向けオプション」を選んで、USBデバッグを有効にします。

これで、Android端末の設定が完了しました。



adbを使ってブラウザログを表示する

それでは、adbを使ってAndroidブラウザのログを表示してみましょう。 まずは、USBを使ってAndroidとPCを接続します。 その後、ターミナルで接続確認をしてみましょう。
$ adb devices
List of devices attached
dc0c670d	device
接続されたデバイスの一覧が表示されます。 この状況で、端末のログを確認するためには、以下のように行います。
$ adb logcat
# たぶん、激しくログが表示されます。
これを実行すると、ブラウザも含めて端末が出すログを全て見ることができます。 ただ全部見てもよくわからないので、以下のようにしてブラウザログを特定して表示します。
$ adb logcat | grep browser
これでログがブラウザのログが表示されるようになりました。
試しに、以下のボタンを押してみましょう。ボタンは、以下のように実装されており、ボタンを押すとJSログが出力されます。
<script>
	var showLog = function () {
		console.debug('aaaaaaa');
		console.log('bbbbbbb');
		console.warn('ccccccc');
		console.error('ddddddd');
	};</script><input type="button" value="ログを出力する" onclick="showLog();"/>


上記のボタンを押すと。以下のように表示されます。
I/browser (14531): Console: aaaaaaa:491
I/browser (14531): Console: bbbbbbb:492
W/browser (14531): Console: ccccccc:493
E/browser (14531): Console: ddddddd:494
#左から、ログレベル/browser (PID): Console: ログメッセージ:ファイルの行数
ブラウザログを見ることができました。こんな感じでログをPCの広い画面で見ることができます、便利ですね。

なお、Androidブラウザでconsole.logを行った場合には。第1引数の値までしか表示してくれないようです。
// 以下の場合、bbbは表示されない
console.log('aaa', 'bbb');

// なので以下のように記述する
console.log('aaa' + 'bbb');
ちょっとしたTipsです。またObjectを渡す場合にも、工夫が必要です。
// ログに出したい何らかのオブジェクト
var obj = {
	name: 'Yohei',
	text: 'working in Shibuya'
};

// オブジェクトをそのままログに渡すと、toString()した結果が表示される
console.log(obj); // [object object]と表示される。

// 値を出したいなら、頑張る。
console.log('name:' + obj.name + ', text:' + obj.text);
デバッグするのに、ログは重要ですね〜。



最後に

今日は、Androidブラウザのデバッグ方法について、ログをadb経由で取得する方法をブログに書きました。 Android端末でもログを見ることは出来ますが、本格的にデバッグするなら、PCでやった方がやりやすいですね。

最後までご覧頂きましてありがとうございました。




[CSS3] (Webkit限定)フォントのアンチエイリアスを変更する

$
0
0
こんにちは、@yoheiMuneです。
Chrome,Safari,iPhone,AndroidなどのWebkit限定ですが、フォントのアンチエイリアスを変更する方法について、ブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/cd6XCL



フォントのAnti Aliasを変更する

Android - 4.4 KitKatのサイトを見ていて気づいたのですが、 -webkit-font-smoothingというCSSが存在するようです。使い方は以下の通りです。
-webkit-font-smoothing: antialiased;
このCSSは、W3Cの仕様にはありませんが、フォントのアンチエイリアスを指定できるCSSで、Webkit系のブラウザで利用することができます。 以下の値が指定できます。
意味
noneアンチエイリアスなし。
subpixel-antialiasedアンチエイリアス効果が最も強くかかる(デフォルト値)。
antialiasedアンチエイリアスあり。
Android - 4.4 KitKatではこの値が指定されています。

アンチエイリアスの違いは、斜め線や曲線のある文字が分かりやすいので、以下ではM,G,Aを使って、比較してみました。 また、背景色が白と黒でも印象が変わるので、2種類を用意しました。

nonesubpixel-antialiasedantialiased
MGAMM
MMM


noneはギザギザしている感じ、subpixel-antialiasedは太めな文字、antialiasedは少し華奢な文字ですね。 背景白の場合にはsubpixel-antialiasedが本文としては読みやすいですが、背景黒の時には、antialiasedの文字もいい感じかもと思いました。 また、タイトルなどには、-webkit-font-smoothing:antialiased; font-weight:300;と、あえて薄めに表現するのもいいのかなと思います。

上記の文字が一緒に見える場合には、残念ながらCSSが効いていないようです。Windows端末では駄目かも。。以下に画像を貼付けておいたので、雰囲気を汲んで頂けると幸いです。
画像

引用:Test page for -webkit-font-smoothing | Christoph Zillgens




参考サイト

本記事を書くために、以下の情報を参照しました。ありがとうございます。

-webkit-font-smoothing と Usability - メモログ
maxvoltar - -webkit-font-smoothing



最後に

職場にフォントフェチみたいな人がいて、その人の影響で自分もフォントが気になってきた今日この頃。 きれいなサイトだなぁと思ったらソースを覗くようにしています。今回は、それからたまたま見つけた内容でした。 見せ方に全力で取り組むって言うのも、良いですね☆

最後までご覧頂きましてありがとうございました。



[CSS] ::selectionというCSSセレクタ

$
0
0
こんにちは、@yoheiMuneです。
今日は、テキストの選択色を変更するCSSについて、ブログを書きたいと思います。
画像

Special Thanks to http://flic.kr/p/8pbriG



注意:この仕様はW3Cの策定から外れています

まず始めに言及しておきたいことは、この記事で紹介する::selectionというCSSセレクタ(疑似セレクタ)は、執筆時点ではW3Cの仕様(Selection | css3-selectors | W3C)から外れている、ということです。 しかし、以下のCan I Use...のサイトでも分かるとおり、利用可能なブラウザが多いです。
画像

引用:::Selection | Can I Use...

文字の選択した色も指定できるって、なんだかいいなぁと思ったので紹介する次第です。



::Selectionを利用する

使い方は簡単で、文字選択時の色を変更したい要素で、以下のように指定します。
<style>
	.target::selection {
		background-color: #9acd00;
		color: #fff;
	}
	.target::-moz-selection {
		background-color: #9acd00;
		color: #fff;
	}</style><div class="target">この文字を選択すると、緑色の選択色になります。</div>

実装例

この文字を選択すると、緑色の選択色になります。


こーゆうところまでこだわれるのは、なんだかいいですね。



最後に

今回は、CSS3の仕様からは外れていますが便利なCSSを紹介しました。 デザインにこだわれる部分ができてありがたい限りです。

最後までご覧頂きましてありがとうございました。



[Git] 入力補完を設定して、Gitをより高速に利用しよう

$
0
0
こんにちは、@yoheiMuneです。
Gitをコマンドで利用する際に、あのコマンドなんだっけ、あのオプションなんだっけ、という経験がある方は多いのではないでしょうか。 今日は、Gitコマンドやオプションの入力補完を設定することで、そんな問題に取り組んでみようと思います。
画像

Special Thanks to http://flic.kr/p/kyqTfi



入力補完をセットアップ

Linuxのコマンドを使っていて、入力補完ができるのって便利ですよね。 実は、Gitにも入力補完を行う仕組みが用意されています。Gitをコマンドで利用する方は、セットアップすると作業効率がUPしますよー。

まずは、入力補完を行うシェルを取得します。Github上のgitのレポジトリを取得します。
$ git clone https://github.com/git/git
さすがはGit本体のレポジトリ。ちょっと重たいですね。クローンされるまで気長に待ちましょう。 Cloneできたら、レポジトリ内にあるgit-completion.bashというシェルを任意の場所にコピーして、ターミナル起動時などに自動的に実行されるようにします。
# 以下のファイルが入力補完を有効にするファイルです
# (gitレポジトリルート)/contrib/completion/git-completion.bash

# 入力補完を有効にするファイルを、任意の場所にコピーします。
$ cp contrib/completion/git-completion.bash ~/local/tool/

# ~/.bashrcに、上記のファイルが実行されるように記載しておきます。
# (~/.bashrcにて、以下を記載する)
# source $HOME/local/tool/git-completion.bash
git-completion.bashを実行することで、gitコマンドの入力補完ができるようになるのです! 上記を設定したのちに、ターミナルを再起動するか、source ~/.bashrcを実行すると、Gitコマンドの入力補完が有効になります。



入力補完を使ってみる

実際に試してみるとこんな感じです。

(以下は何らかのGitレポジトリ内でコマンドを利用した例です)

# TABを押すことで、入力補完を行うことができます。
# 例えば、gitと入力してスペースを置いてタブを押すと、たくさんのgitコマンドが表示されます。
$ git <tab>
add                      config                   lkgr                     reset 
am                       credential               log                      revert 
annotate                 credential-osxkeychain   lost-found               rm 
apply                    crsync                   merge                    runhooks 
archive                  crup                     mergetool                send-email 
bisect                   describe                 mv                       shortlog 
blame                    diff                     name-rev                 show 
branch                   difftool                 notes                    show-branch 
bundle                   fetch                    p4                       st 
checkout                 filter-branch            peek-remote              stage 
cherry                   format-patch             pull                     stash 
cherry-pick              fsck                     push                     status 
citool                   gc                       rebase                   submodule 
cl                       get-tar-commit-id        reflog                   subtree 
cl-upload-hook           grep                     relink                   svn 
clean                    gs                       remote                   tag 
clone                    help                     repack                   tar-tree 
cm                       imap-send                replace                  try 
column                   init                     repo-config              whatchanged 
commit                   instaweb                 request-pull             
たくさんの入力可能なコマンドが表示されましたね。これが表示されれば、うる覚えのコマンドも使いやすいですね。

この入力補完がすごいところは、Gitコマンドのオプションも入力補完ができることです。 例えば、git logのオプションを思い出すのは大変なことも多いですが、この入力補完を使えばオプションの指定が楽にできます。
# gitコマンドを入力後、TABを押すと、利用可能なオプション候補一覧が表示されます。
# 以下では「--」から始まるオプションの一覧を表示しています。
$ git log --<tab>
--abbrev                   --dirstat                  --max-parents=             --pretty=
--abbrev-commit            --dirstat-by-file          --merges                   --quiet 
--abbrev=                  --dirstat-by-file=         --min-age=                 --raw 
--after=                   --dirstat=                 --min-parents=             --relative-date 
--all                      --dst-prefix=              --minimal                  --remotes 
--all-match                --exit-code                --name-only                --reverse 
--author=                  --ext-diff                 --name-status              --root 
--before=                  --find-copies-harder       --no-color                 --shortstat 
--binary                   --first-parent             --no-ext-diff              --simplify-by-decoration 
--branches                 --follow                   --no-max-parents           --simplify-merges 
--check                    --format=                  --no-merges                --since=
--cherry-pick              --full-diff                --no-min-parents           --sparse 
--children                 --full-history             --no-notes                 --src-prefix=
--color                    --full-index               --no-prefix                --stat 
--color-words              --graph                    --no-renames               --summary 
--committer=               --grep=                    --not                      --tags 
--cumulative               --histogram                --notes                    --text 
--date-order               --ignore-all-space         --numstat                  --topo-order 
--date=                    --ignore-space-at-eol      --oneline                  --until=
--decorate                 --ignore-space-change      --parents                  --walk-reflogs 
--decorate=                --inter-hunk-context=      --patch-with-stat          --word-diff 
--dense                    --left-right               --patience                 
--diff-algorithm=          --max-age=                 --pickaxe-all              
--diff-filter=             --max-count=               --pickaxe-regex            
なかなかの便利ものですね。 利用頻度の高いコマンドは、Aliasに登録(詳しくは、こちら)しちゃいますが、時々しか使わないコマンド(マージの時に使うgit checkout --ours filenameなど)は、この入力補完を使うことで、作業がはかどりそうです。



最後に

以上簡単ですが、Gitコマンドの入力補完のセットアップと利用方法を、ブログで扱ってみました。 このようなちょっとした改善を積み重ねると、開発スピードが上がって良いですよね。 これからも色々とブログにアウトプットしていきたいと思いますので、どうぞ宜しくお願いします。

最後までご覧頂きましてありがとうございました。



[Git] 3種類のタグについて

$
0
0
こんにちは、@yoheiMuneです。
Gitのタグには3種類あるって、知ってましたか?今日は、それらのタグについてブログを書きたいと思います。

画像

Special Thanks to http://flic.kr/p/BEMhr



このブログで伝えたいこと

このブログでは、Gitのタグについて解説しています。 この記事を最後まで読むことで、Gitに存在するタグの種類を知り、それらを作成/利用/共有/削除する方法を学ぶことができます。



Gitで利用できるタグの種類

Gitで利用できるタグには以下の3種類が存在します。

  • 軽量版のタグ
  • 注釈付きのタグ
  • 署名付きのタグ

※上記名称は、git-scm.comから引用しています。


以降では、それぞれの機能や作成方法を説明します。



軽量版のタグ

軽量版のタグは、その名前の通り、タグに持たせる情報が一番軽量なタグです。 他のタグとは異なり、ある特定のコミットに対して何か名前をつけるために利用します。以下のように作成します。
$ git tag my-light-tag-01
上記のコマンドでは、現在のHEADが指すコミットに対して「my-light-tag-01」というタグを作成しました。 作成したタグを確認するには、以下のように行います。
$ git tag
my-light-tag-01
タグのデータとそれに関連づけられたコミットを見るにはgit showコマンドを使用します。
$ git show
commit 6e6cf849629c6322414ad07d12644710ef48be81
Author: munesada_yohei <y.munesada@gmail.com>
Date:   Wed Jan 22 14:24:02 2014 +0900

    my first commit

diff --git a/aaa.txt b/aaa.txt
new file mode 100644
index 0000000..fb6c63a
--- /dev/null
+++ b/aaa.txt
@@ -0,0 +1,2 @@
+this is a first commit message file.
+
個人的に利用しているレポジトリであれば、このタグも便利でしょう。 しかし、誰がいつ何のために作成したのかといった情報は持っていません。 チーム開発でGitを利用する場合には、次に紹介するタグがより役立つでしょう。



注釈付きタグ

注釈付きタグでは、作成者、作成日、作成メッセージといった情報を追加でタグに保持させることができます。 注釈付きタグは、-aオプションを付与してタグを作成します。
# -mを指定するとコメントも同時に指定することが出来ます.
# -mを付けない場合にはコメント付与を行うためのエディタが立ち上がります.
$ git tag -a annotated-tag-01 -m "my first annotated tag"
作成したタグを確認してみましょう。
$ git tag
annotated-tag-01
my-light-tag-01
先ほどのタグに加え、今回作成したタグもできていますね。タグの中身も見てみましょう。
$ git show annotated-tag-01
tag annotated-tag-01
Tagger: munesada_yohei <y.munesada@gmail.com>
Date:   Sun Mar 16 23:07:05 2014 +0900

my first annotated tag

commit 6e6cf849629c6322414ad07d12644710ef48be81
Author: munesada_yohei <y.munesada@gmail.com>
Date:   Wed Jan 22 14:24:02 2014 +0900

    my first commit

diff --git a/aaa.txt b/aaa.txt
new file mode 100644
index 0000000..fb6c63a
--- /dev/null
+++ b/aaa.txt
@@ -0,0 +1,2 @@
+this is a first commit message file.
+
軽量版タグとは異なり、TaggerやDateなどの情報が表示されていることが分かります。 チーム開発でこのタグを使えば、なぜタグがあるのか、誰が作ったのか、といった情報を得ることができ、便利に開発を進めることができます。 よく、このタグあるけど消しても良いの?という話題がでることもありますが、このタグがあれば少なくとも、作成者や作成日が分かるので、消しても良いのか否かの判断がしやすくなります。

次のタグは、注釈付きタグに署名を加えることができるタグです。



署名付きのタグ

署名付きのタグは、注釈付きのタグの情報に加え、署名を保持することができます。 なぜタグに署名を付ける必要があるのでしょうか。それは、そのタグ(やコミット)に対して信頼性を持たせるためです。 顔の知れた仲間同士で開発をしていればこのような署名は不要かもしれませんが、OSSなど全く知らない人も含まれた開発をする際には、署名付きのタグも利用シーンがあるかもしれません。
Gitは、レポジトリが個人毎に存在するため、そのレポジトリに対するユーザー設定は各個人が行います。そのため、なりすましをしようと思えば出来てしまいます(user.nameにどのような名前を設定するかは、各人で自由に設定できます)。 そんな状況でも、まさに本人が作成したのかどうかを判別するために、署名を付けるという行為ができるようになっているようです。

この点について考察したブログがありましたので、リンクを掲載しておきます。


署名付きタグは、以下のように作成します。
$ git tag -s signed-tag-01 -m "my signed tag"
もし、以下ようなエラーが出てしまった場合には、gpgを作成する必要があります。
$ git tag -s signed-tag-01 -m "my signed tag"
error: cannot run gpg: No such file or directory
error: could not run gpg.
error: unable to sign the tag
MacOSにおける、gpgコマンドの導入や鍵の作成は、gpgでのファイルの暗号化基礎 - akihiro_obの日記で説明されているため、そちらをご参照ください。

自分はこの署名付きタグを使ったことないので、詳しい説明は割愛します。git showでタグの内容を確認すると、以下のように表示されるようです。
# 参照:Git-の基本-タグ | git-scm.com
$ git show v1.5
tag v1.5
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 15:22:20 2009 -0800

my signed 1.5 tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN
Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/
=WryJ
-----END PGP SIGNATURE-----
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sun Feb 8 19:02:46 2009 -0800

    Merge branch 'experiment'



タグをリモートに追加する

作成したタグを他の作業者と共有するには、リモートに追加する必要があります。 リモートへの追加は、以下のように行います。
# git push origin [tagname]
$ git push origin annotated-tag-01 
Counting objects: 1, done.
Writing objects: 100% (1/1), 178 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://github.com/yoheiMune2/sampleMune2
 * [new tag]         annotated-tag-01 -> annotated-tag-01
無事に、タグをリモートレポジトリにPUSHすることができました。 なお手元にあるタグを一気に上げたい場合には、以下のようにも出来るようです。
# タグを色々と追加してみる
$ git tag v0.1
$ git tag v1.2
$ git tag v1.4

# まとめてタグをPushする
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/yoheiMune2/sampleMune2
 * [new tag]         my-light-tag-01 -> my-light-tag-01
 * [new tag]         v0.1 -> v0.1
 * [new tag]         v1.2 -> v1.2
 * [new tag]         v1.4 -> v1.4



タグを削除する

続いてタグを削除する方法です。不要になった情報は削除して、さっぱりしたいものです。タグの削除は、以下のように行います。
# ローカルのタグを削除する
$ git tag -d v0.1
Deleted tag 'v0.1' (was 6e6cf84)
git branchなどと同じく、-dオプションで削除することが出来ます。
リモートにあるタグを削除するには、以下のように行います。
# git push origin :[tagname]
$ git push origin :v1.2
To https://github.com/yoheiMune2/sampleMune2
 - [deleted]         v1.2
ブランチの削除と同じように、:を付けてPushすれば削除することが出来ます。簡単ですね。



HEAD以外のコミットにタグを付ける

HEAD以外のコミットに遡ってタグを付けることが出来ます。タグを付ける際に、対象のコミットを指定します。
# ログを確認します
$ git log --online
6e6cf84 my first commit
3a1192f Initial commit

# 今回は3a1192fにタグを付けてみます
$ git tag -a tag-initial -m "tag for initial commit" 3a1192f
作成したタグの内容を確認してみましょう。
$ git show tag-initial 
tag tag-initial
Tagger: Yohei Munesada <y.munesada@gmail.com>
Date:   Sun Mar 16 23:38:28 2014 +0900

tag for initial commit

commit 3a1192fd3441476542c315b174cb87acf9667e3e
Author: Yohei Munesada <yfree.munesada@gmail.com>
Date:   Tue Jan 21 21:23:17 2014 -0800

    Initial commit

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..3479d90
--- /dev/null
+++ b/README.md
@@ -0,0 +1,4 @@
+sampleMune2
+===========
+
+This is a Sample repository. no good for you, maybe.
tag-initialタグが指すコミットが、3a1192fになっていることが分かります。



レポジトリを、タグの状態にする

タグの位置までレポジトリを巻き戻してみましょう。そのタグの状態をとりあえず確認できればよいのであれば、以下のように行います。
# git checkout [tagname]
$ git checkout tag-initial
Note: checking out 'tag-initial'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 3a1192f... Initial commit
これで、tag-initialタグの状態になることが出来ました。ブランチを確認してみると、
$ git branch
* (detached from tag-initial)
  master
一時的なブランチにいることが分かります。とりあえず確認したいのではなく、ちゃんとブランチを作って、タグの状態にすることもできます。
# ブランチを作って、そのブランチをタグの状態にする
# git checkout -b [branchname] [tagname]
$ git checkout -b initial-tag-branch tag-initial
Switched to a new branch 'branch-initial'

# 作成したブランチを確認する
$ git branch
* branch-initial
  master
こんな感じで、作成したタグの状態でブランチを作成することができます。便利ですね!



参考資料

本記事を作成するために、以下を参照しました。ありがとうございます。
Git - タグ | git-scm.com



最後に

gitって3種類のタグがあるんですね。私も最近までよく分からずにタグを使っていました。 コミットに対して理解しやすい名前をつけられる機能って便利ですよね。あの動いていた時に戻したい、的な話とか良くありますw。

最後までご覧頂きましてありがとうございました。



[Mac] ターミナルの$前の出力内容をカスタマイズする

$
0
0
こんにちは、@yoheiMuneです。
今日は、Macなどのターミナルで「$」の左側の表示を変更する方法を学んだので、それをブログに書きたいと思います。

画像

Special Thanks to http://flic.kr/p/6aSMGt



まずはゴールを

今回のブログで説明するカスタマイズをすることで、ターミナルの表示を以下のように変更することができます。

変更前

画像

変更後

画像

変更後は、表示している内容や色が変わっていることが分かります。 この「表示内容」や「色」を自由にカスタマイズする内容をご紹介できればと思います。



出力内容を設定する

ターミナルの$前の出力フォーマットは、Macの場合、環境変数のPS1で指定されています。 まずは、現在のPS1の内容を出力してみましょう。
$ echo $PS1
\h:\W \u\$
何か指定されていることが分かります。 ここで表示されている\h\Wには、特別な意味があります。具体的な内容は、以下の通りです。
意味
\hホスト名(最初の.まで)
\Hホスト名
\t時間(24時間形式)
\uユーザー名
\w現在のディレクトリ(フルパス)
\W現在のディレクトリ名
他にも設定可能な項目が色々とあるようです。詳しくは、プロンプトの確認や設定 - Pocketstudio.jp Linux Wikiをご参照ください。

それでは、PS1の値を変更してみましょう。
$ PS1="\u:\t \W $" # ユーザー名:時間 ディレクトリ名 $
ユーザー名、現在時刻、ディレクトリ名が表示されるようになりました。
上記のように環境変数に代入した場合、ターミナルを再起動すると設定が戻ってしまいますので、 今後、設定したプロンプト表現を使いたい場合には、~/.bashrcなどに記載します。
# ~/.bashrc
PS1="\u:\t \W $" # ユーザー名:時間 ディレクトリ名 $
これでターミナルを再起動しても、同じ設定が利用できるようになりました。 (ターミナルを再起動しても設定が有効にならない場合には、~/.bashrc~/.bash_profileから実行されているか確認してみてください。)


色を指定する

今のところ白色の文字ですが、色を指定することもできます。まずは、上記の出力を、赤色にしてみたいと思います。
$ PS1="\[\033[31m\]\u:\t \W $\[\033[0m\]"
赤色の出力になりましたでしょうか。 分かりづらいですが、\[\033[31m\]\[\033[0m\]で囲うことで、その中の文字を赤色に指定しています。
ここで31という値がポイントで、31は赤を示しています。出力内容で別々の色を指定するには、例えば以下のように行います。
# 31が赤で、32が緑です
$ PS1="\[\033[31m\]\u:\t\[\033[0m\]\[\033[32m\] \W\[\033[0m\] $"	
かなり難読な設定ですが、このように色を指定することができます。どの数値がどの色なのかは、以下のようになっています。
30Black
31Red
32Green
33Yellow
34Blue
35Magenta
36Cyan
37White

参考:ASCII Table - ANSI Escape sequences


あと、文字色以外に背景色も指定できるようです。詳しくは、bashのプロンプトに色をつける | ブーログで紹介されていましたので、そちらをご参照ください。

さてここまでで、最初に示したカスタマイズ後の表示になりました♪
画像



最後に

ターミナルの出力を自分好みにカスタマイズすることで、黒い画面も少しお気に入りになるかも!?と思い、紹介させて頂きましたw。 ターミナルを仕事で使う方は、ぜひカスタマイズもしてみてください。

最後までご覧頂きましてありがとうございました☆



Viewing all 364 articles
Browse latest View live