With having fun

2012年5月20日日曜日

JSLint のページがリニューアル

昨日とは違う画面になっていた。
JSLint のページが新しくなっていました。

オプションの有効・無効の設定が、今までは、白と黒と灰色の表示でしたが、False と True と Default という文字の表示になってわかりやすくなっている。

これまで、オプションの設定に白と黒と灰色の３種類あって、なんで２種類じゃなくて３種類なんだろうと思っていたら、３つめは "Default" だったのか！

んっ、Default ?
Default って True と False のどっちなんだろう・・・。

2012年5月19日土曜日

JSLint で自分のコードをチェックしてみた

JSLint でチェック

JavaScript の品質チェックツールである JSLint を使ってみました。
Web 上で実行してみると警告メッセージがたくさん出た。
見慣れないメッセージがたくさんあり（初めてなので見慣れないのは当たり前だが）、何を直せばいいのか一瞬途方に暮れる。

JSLint は JavaScript の書き方をより良いものにするためのチェックをしてくれるわけですが、では "より良い" というのは、何を目指せば良いのか？　JSLint に合格するには何をすれば良いのか？

何を目指せば良いのかの指針がここに書いてある。
http://www.jslint.com/lint.html （これの翻訳が "JavaScript: The Good Parts" の付録 C にある。）

エラーメッセージ

もう一度エラーメッセージを見てみる。いくつか代表的なものをピックアップ。

・グローバル変数

Problem at line 2 character 12: 'document' was used before it was defined.

すべての変数は使われる前に定義されていないと、JSLint ではエラーとみなされる。ブラウザで HTML に対して JavaScript を使用する時には "document" プロパティは当然、変数としては宣言しないのでエラーになります。
オプションの "Assume a browser" にチェックを入れておくとブラウザであることが仮定されて、 document などのグローバルプロパティは宣言済みとみなされエラーとならなくなります。

・var

Problem at line 23 character 10: Move 'var' declarations to the top of the function.

変数宣言を関数の先頭で行いなさいということ。

for (var i=0; i<max; i++) {

といった var の使い方もダメです。
（でも、"JavaScriptパターン" の中で上記のような書き方をしているところを見つけてしまいました。フフッ。 "JavaScript パターン" では全てのコードが JSLint をパスしているはずなのに。）

・インデント

Problem at line 16 character 5: Expected 'callback' at column 9, not column 5.

インデントした文の開始が 5 ではなく 9 列目からにしなさいということ。自分のコードの中で一つこのエラーの理由がよくわからないところがあるのですが、インデントの指針がどこにも書いていないし、ソフトの品質とは関係ない問題なので、オプション "Tolerate messy white space" でチェックしない様にします。（少し後ろめたいですが・・・。）

Warning!

JSLint のページの最初に、

Warning!
JSLint will hurt your feelings.

とあるように、些細な体裁の問題でたくさんのエラーが出るのでちょっと嫌になります。でも、JavaScript を公開する前にはやっぱり一度はチェックするようにしようと思います。

なぜなら、

JSLint ではブラウザのデバッグツールで見つからなかったエラーも見つかることがある。
JSLint は些細な体裁も指摘してくれるので JavaScript 初心者でも、パッと見は恥ずかしくないものに直せる。

からです。

コンパイラは悪くない

インデントの問題に蓋をしてしまいましたが、自分のコードをよくよく見るとインデントにスペースとタブが混在していました。
タブはスペース 4 つと計算されるようです。
本来は同じレベルのインデントになるはずの文で、一方はスペースとタブでもう一方はタブのみとなっていて、それでインデントを合わせなさいというような警告になっていたのでした。
（最近 Emacs の設定でインデントのタブをスペースに置き換えたので、そのためにスペースとタブが混在してしまったのかもしれません。）

ついつい、コンパイラの方を疑ってしまいました。
達人プログラマーへの道は遠いなぁ。

達人プログラマー―システム開発の職人から名匠への道

2012年4月30日月曜日

タイピングアプリ「Type Fu」

タイピングを正確にしたいと思っていたところに、タイピングアプリの紹介記事を目にしたので、これを使って練習しています。（Chrome の拡張機能です。）

きちんとタイピングできない人や改めてタイピングを勉強したい人へ～無料でタッチタイプが練習できる「Type Fu」

1 回の練習が 10 秒〜 20 秒程度で終わるので疲れないのがいいです。
10 秒を何回も夢中になってやっているうちに、ほんの少しずつ問題のレベルが上がっていっていつの間にか身に付いている、といった感じで、問題もイイ具合の問題です。

JavaScript 本：「JavaScript パターン」と「JavaScript: The Good Parts」

JavaScript 本を２冊読んだ。

JavaScript パターン

JavaScript を安全に（= 間違いにくく）使うためのパターンを解説した本。
パターンと言っているのはデザインパターンだけでなく関数の使い方、オブジェクトの使い方などのベストプラクティス的な方法全般を言っていて、JavaScript 独特の「書き方」を説明している。

解説には分かりやすいコードがたくさん使われていて、そこから JavaScript の流儀に触れられる点でも良かった。

新しく JavaScript を学び始めたが、文法はよく知っている言語のアナロジーで理解できるが、書いてみるとJavaScript らしくならない。この本を読んでやっと JavaScript の世界へ一歩踏み込めた感じがする。
個人的には以下の章が特に JavaScript らしさを知る上で役立った。

3章リテラルとコンストラクタ、　
4章関数、　
5章オブジェクト作成のパターン、　
8章 DOM とブラウザのパターン

JavaScript: The Good Parts

JavaScript は美しい言語だが醜い部分もある。美しい部分だけを取り出したサブセットを使うことによって JavaScript を美しいままに保とう、といったコンセプトで本書は書かれている。
不要なものは学ばなくてもいいしそれはいい考えだ！、と思って真っ先に読んだ JavaScript 本でした。
ですが、挫折しました。横着してはいけません。やっぱり先に入門書を読むことは必要でした。

今回は、入門書とJavaScript パターンを読んでからのリベンジです。
選び出した「Good parts」を系統的に説明していて、ひと通り文法を理解している人が改めて読み直すと新しい発見があるといった類の本だと思います。

醜い危険な書き方を避けて、美しい安全な書き方を選ぶというのは、実は「JavaScript パターン」と目的は同じで、内容的にも重複している部分もあります。両著者ともYahoo! のエンジニアということもあるのでしょうか。

両書を読んで

タイトルからは別々の内容を想像しますが、コンセプトはほとんど同じで、また、両者はまるで一人の人が書いているのかと思うほど、哲学が似ています。
「パターン」の方はアンチパターンを示してからベストプラクティスへ導くようなストーリー性の説明に対して、「Good Parts」の方は選り抜きの「良いパーツ」一つ一つに着目して説明されています。
どちらかと言うと「Good Parts」の方がより上級向きといった印象でした。

2012年3月27日火曜日

Emacs の動画

Emacs の動画に刺激を受けたのでまとめておく。

Emacs の解説。（実はこういうので英会話のリスニングを勉強すると身に付くのではないか。）

人がエディタを使っているのを見るのは面白いし、ちょっとした癖なんかも、使い方改善のヒントになる。
高速タイピングに憧れていたが、ちょっと考えが変わって、これからは、速くなくてもいいので、

正確なタイピング
snippet や補完を使い込む

ということで効率化を目指すようにしよう。

2012年2月28日火曜日

再帰について

順列問題を解く

CodeEval より

【問題】
Write a program to print out all the permutations of a string in alphabetical order.

例えば、
hat
という入力に対しては、

aht,ath,hat,hta,tah,tha
と出力する。

順列のような問題は、なんとなく再帰を使うのが良いような気がする。

#! /usr/bin/perl

use strict;
use warnings;

sub perm{
    my @orig_arr = @_;

    if ( scalar(@orig_arr) <= 1 ){
        my $result = shift @orig_arr;
    }
    else {
        my @result = ();
        for (0..scalar( @orig_arr )-1){
            my @workarr = @orig_arr;
            my $top_char = splice( @workarr, $_, 1);

            push @result, map { $top_char.$_ } perm( @workarr );
        }
        @result;
    }
}

sub solve{
    my @result = sort ( perm(split //, shift) );
    foreach (@result){  
        print $_.", ";
    }
    print "\n";
}

solve("hat");

ループでも解けるでしょうか？
再帰でできることは for 文（ループ）でもできるはずなのですが、今回の場合は for 文は意外と難しそう。
何が難しいのかというと "hat" のように 3 文字で固定であれば 2 つの for 文のネストでできますが、文字数は可変なので静的なプログラムが書けない（と思う）。 for 文を結局再帰したくなる・・・。
そこで、新しい発見かもしれない教訓、

”繰り返し数が固定でない場合は、再帰処理が有効”

再帰は危険

for 文で書くのに何かヒントは無いかと、Code Complete を紐解いてみる。「再帰を使って行えることは全て、スタックと繰り返しを使って行うことができる」とある。
そうかスタックね。・・・でもわからん。この問題はしばらく寝かせよう・・・。

ところで、前述の本には「再帰の使用に関するヒント」という項目に有用なヒントが幾つかあって、最後に「階乗やフィボナッチ数列に再帰を使用しない」とある。
そして、再帰は遅くて、消費メモリの予測ができなくて、理解が難しいと説明してあり、さらにかなり強い調子で「仮に、私の部下が再帰を使って階乗を計算しようものなら、別の誰かを雇うだろう」といっている。
上司によっては職を失いかねない危険をはらんでいます。再帰を使うときは要注意っと。

2012年2月5日日曜日

Mac の Finder で上の階層に移動したい

Mac の Finder で、今表示されているフォルダの上の階層へ移動する方法のメモ。
（キーバインドは、Command + ↑）
そして、メモしようと思って画面のキャプチャをしたときに色々と知ったことのメモ。

Finder で上の階層へ移動
Mac の Finder で自分のホームディレクトリー /Users/xxx を見たいときに Finder を起動すると、以下のような画面が開きます。

Windows のエクスプローラーのようにフォルダをたどって探したいのですが少し勝手が違います。
アイコンが並んでいる隣のサイドバーを見ても /Users などという名前もないし、画面上のボタンを押しても、/Users へたどっていけません。

ここで、キーボード操作で ' Command + ↑ ' とすれば一つ上の階層に移動できます。
（そして、下図の場合では「ユーザ」が /Users に相当するのでそこからたどれば /Users/xxx が見られる。）

上の階層の最後まで行くと、' Macintosh HD ' までたどれます。ココまで来ればアイコンダブルクリックで希望の下の階層へたどれます。

単に' Macintosh HD ' へ移動したい場合は ' Shift + Command + C ' で、一発で出来ました。C は「コンピュータ」の C 。
（メニューの「移動」にありました。）

しかし、上記のキーバインドは多分忘れるので、サイドバーに ' Macintosh HD ' を登録しておきます。' Macintosh HD 'アイコンを選択した状態で「ファイル」→「サイドバーに追加」。

サイドバーの一番下に ' Macintosh HD ' が追加されました。

画面のキャプチャについて
本題とは関係ないですが、記事を書くのに画面のキャプチャをやって、これも覚えておいたほうがよさそうなのでメモ。

あるウィンドウをキャプチャするのは、' Command + Shift + 4 + Space ' を押して、出てきたカメラアイコンでウィンドウを選択する。
（' Command + Shift + 4 ' は片手で押すには無理があるので、今度やるときは４は右手にする。）

今回メニューをキャプチャしようとしたら、下図のように思っていたのと違う画面が取れてしまった。
「 Dock に追加」は本当は「サイドバーに追加」。

キャプチャする時に ' Shift ' キーを押してしまうのでメニューの内容が変わってしまうのです。

別のキャプチャの方法を探したら、「グラブ」というソフトがありました。「アプリケーション」→「ユーティリティ」から起動。

Shift キーを押さずに１０秒タイマーでキャプチャできます。

その他

Finder の「デバイス」に FireFox があるのが気になりますが、話が発散しすぎるのでスルー。