JavaScriptの良い書き方とは

『JavaScript:The Good Parts 「良いパーツ」によるベストプラクティス』を読んだので覚書。内容はJavaScriptのバグの出にくい書き方をまとめた本。どちらかと言えば初心者向けの本で、こう書いたほうがいいですよーって感じのことを書いてる。けど、書き方が難しい。。。Good Partsの本と書いてあるけど、付録に記載のある「ひどいパーツ」「悪いパーツ」を見たほうが勉強になると思う。JavaScriptに特化していて、やらないほうがいいってことを書きだしてみる。

グローバル変数は使うな!

JavaScriptだとブロックスコープがないので、気をつけないとグローバル変数になってしまう。うまく関数スコープを使用してグローバル領域を汚さないようにプログラムを書きましょう。

(function(){
    // こんな感じで即時実行関数で括ってしまえば
    // グローバル領域を汚さない
    var hoge, hogehoge;
})()

==, != は使うな!

==, != の判定は予想外の行動を起こすことがある。==, != は、大抵の場合 ===, !== に置き換えれるため、こちらを使いましょう。

withは使うな!

JavaScriptではプログラムの記載を省略するためにwithを使用することができるが、こいつも予想外の行動を起こしやすいので使用しないようにしましょう。

newは使うな!

newを書き忘れるとバグの発見にすごく手間がかかるのでnewを使うのはやめましょう。って書いてあるんだけど、僕としてはnewは使うなというか、Classの概念を持ってくることはあまり好ましくないような気がしている。Classの概念とJavaScriptは相性が悪いと思う。

evalは使うな!

文字列をコンパイルして実行するevalを使うのは極力控えましょう。evalはコンパイルが走る分実行速度が遅くなります。

setTimeout、setIntervalに文字列を渡すな!

setTimeoutやsetIntervalでは第一引数に文字列を渡すとevalが走って実行することになります。そのため実行速度が遅くなります。わざわざevalを実行させる必要はないので、functionできっちりと定義しましょう。

まとめ

なかなか面白い本だった。記載してあるグッドプラクティスはすべての言語で共通して言えることも多いので、これからJavaScriptをはじめる人っていうよりもこれからプログラミングをはじめる人が読むといい本かもしれない。

人は(ry を読んだ感想

「人は自分が期待するほど自分を見ていてはくれないががっかりするほど見ていなくはない」を読んだので感想。読み終わって引っかかったものを書いてみる。

縛りがあるから面白い

俳句の例とか非常にわかりやすい。人はなにか縛りがあるから面白いものをひらめくっていうのはそのとおりかもしれない。視点を変えてみると、幅が狭い中でみんなで考えているから出てくるものが少なくて、それがあったかーって他の人がなり易いから面白いものをひらめいているように見えるってだけかもしれない。ただ、何かを考えるときにわざと幅を狭めて考えるっていうのは案が収束しやすくなることは確か。

友情だけはギブアンドテイク

これは寂しい。僕は逆に仕事がギブアンドテイクだと思う。何かもらえるから仕事をするわけで、見返りを求めなければいい仕事は出来るって言ってるけど、たぶんそれはその先に何かがあると踏んでいるから見返りを求めずに仕事が出来るんじゃないかと思ってしまう。友情こそ見返りを求めずにいけるんじゃなかろうか。切磋琢磨する素晴らしい友人関係もあればその人達の中にいると安らかになるという友人関係もあってもいいと思う。

ヒットしたものは全て正しい

腑に落ちる言葉。自分から見たらどんな馬鹿げたものに見えたとしても他の人に欲求があったからヒットするわけで、自分の面白い・面白くないっていう感想を抜きにするのであればこの言葉は正しい。ただ、流行ると思うけどこれは作りたくないっていうものとか、流行らないと思うけどこれは作りたいとか個人的にはあって、そういうのがあるから技術者なのかなーと思う。

独占は成功の母

アメーバの戦略が出てて面白い。

わが友、不眠症

どちらの方もよく働かれている。1日30分しかねらずにずっと仕事を考えてるとかすごすぎる。前に読んだ「渋谷で働く社長の日記」を読んだ時も働く時間が長いなーと思ったけど、見城さんもすごい。人間は最低でも1度はすごい仕事をする時間というものをとらないとこの方々みたいにはなれないんだろうな。絶対にうまくいくかわからないものに対してここまで熱い時間を投資するって感覚を持つ必要があるのかも。少しは見習いたいものです。

人は一つの人生しか生きられない

成功していろいろなものに手を出して失敗しちゃった人は僕も見たことある。他の人がそれに対して心血を注いでやっているのに、それを片手間でやって成功しようという考えがそもそも甘いと僕も思う。

まとめ

前の本でも思ったけど、見城さんが「剛」で藤田さんが「柔」っていう見え方をする本に出来上がっていると思う。おふたりとも仕事に心血を注いでいる感がひしひしと伝わってきて成功する、成功したとみなされてる人っていうのはここまで努力をしているのかと改めて思わされた。

JavaScriptの高速化試作の覚書 – JavaScriptグラフィックス

『JavaScriptグラフィックス – ゲーム・スマートフォン・ウェブで使う最新テクニック』ってのを読んだので必要そうな部分を抜粋

速度測定の指標

動作速度は端末によって違う。だからある一定の指標が必要。以下のコードを走らせることで、その端末で1秒間にどれだけの動作を行うことができるのかの指標を取得することができる。これを用いることでどの端末でも動作改善試作が表す影響を見ることができる。

var StartTime = new Date().getTime(); for(var count=0 ; timeElapsed < 1000 ; count++) { // ここで検証する動作を行う timeElaspsed = new Date().getTime() - startTime; } [/code]

countが増えれば増えるほど動作速度の向上を意味しており、改善前と改善後での数値の差に注目する。ただし、Firebugとかで計測できる環境があるならそれを使うのが一番いい。

高速化実装試作

  • 80-20のルール(20%のコードが80%のCPU時間を使う)に基づいて20%に力を入れて高速化をおこなったほうがいい
  • 三角関数等の重い計算処理を行うのであれば、結果をテーブルとして持ち近似値を使用したほうが早い
  • 複数の判定要素がある場合は、各ビットでフラグを表現し&演算子で判定を行ったほうが早い
  • XORをうまく使ってtoggleを実現できる(ex. toggle ^= 1;)
  • Math.Floor()よりもビットシフトを使用したほうが早い(ex. x = y >> 0)
  • jQueryのセレクタ指定は呼ばれるたびに検索が走るので複数呼ばない。複数呼ぶ場合は変数へキャッシュする。
  • jQueryのセレクタ指定は検索開始を指定することができる(ex. $(‘.class’, start-element);)
  • jQueryのcss演算子は遅い。複数変更する必要がある場合は、styleオブジェクトを抽出して変更する。(ex. $(‘#element’)[0].style)
  • 複数の要素を追加する場合は追加する文字列を作成して一回で追加したほうが早い。

アニメーション

どのような端末でも一定のスピードを保証するためにフレームレートを指定する。1秒間にどの程度の動作を行うことができるかを取得して、それに伴いアニメーションの移動距離を変えることでどの端末でも一意のスピードを保証することができる。例えば、1秒間に500回動作する端末(A)と1秒間に100回動さする端末(B)があった場合、どちらも同一のスピードを再現したいのであればBは1回の動作でAの移動距離の5倍移動させれば同じスピードを表現することができる。

まとめ

高速化について知りたくて呼んでみた本なんだけど、高速化の実装は最初の方にしか書いてなかったので非常に残念。アニメーションをJavaScriptで記載する場合(ゲーム等)は参考になる記述もたくさんあるようなので、もしゲームを作ることになったら更に深く読むことにする。


アジャイルという考え方

アジャイルサムライを読んだ。組み込み系からWeb業界に移動してきた僕にとっては有益な話が多かくて、忘れる前にメモ程度に書いておこうと思う。

インセンティブデッキを作成する

以下の5項目をプロジェクト開始時に決めておく。

  1. 我々はなぜここにいるのか?
  2. エレベータピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. ご近所さんリスト

自分たちが何を作成するために集められて、それを作成することでどういうことが起きるのかをまず統一化する。エレベータピッチをみんなで共有することもそうだし、パッケージデザインで作るものの意識を共通化させるのもそう。作成している間にやりたいことやこれがあったらいいというものはどんどん増えていくけど、これは今回の開発では絶対に「やらない」というものを決めておくというのも面白い。ご近所さんリストは大規模開発じゃないとあまりないかなーと思う。

見積もりは変わる

きっちりとした見積なんて最初からできないものだと割りきって考える。最初からできないんだから後からすこしずつ変えていけばいい。そうすれば見積が変わっていくことに対していちいちストレスを感じることもない。出していた見積は作業をすることで時間が変わるものだし、要件は作成している間に増えるものである。要件が増えそうになった際には時にやらないことリストや、パッケージデザインをそれは本当に必要かをその都度見積り直せば良い。まずは大体で見積もって終わりになるほど精度が高くなればいい。

ストーリーを語る

技術者は技術で語る癖がある。データベースのレスポンスを早くする。とか、アニメーション処理をCSSで書くとか。それは技術者間で話すには良いのだけど、技術者ではない人と話す場合はその作業によってユーザ見えでどう変わるのかを話したほうが良い。データベースのレスポンスが早くする。っていうのは、画面表示を早くするって言い換えれるかもしれないし、アニメーションをCSSで書くというのはなめらかなアニメーションを実現するって言い換えれるかもしれない。やっていることがどういう効能があるというのを共用することは大事。

概算見積もり

技術者から見て同じぐらいの重さのものをグループ化してポイント化する。例えば10個のタスクがあったとして、1ptが5個、2ptが3個、3ptが2個みたいな感じで。これも大体でいいらしい。んで、とりあえずやってみる事で、1ptにつきどの程度時間が掛かるかを見積もる。こうすることでスケジュールが進むに連れて見積もりの精度がすごく高くなる(*1)。どう考えても最初に提出したスケジュールに間に合わない場合は、タスクを削る。もしくは時間を伸ばす。間に合わないということがわかるのも見積もりを行なっているからで、スケジュールに間に合わないということが早めにわかって良かったとポジティブに考える。基本的にはスケジュールを伸ばすのではなくタスクを削るほうがうまくいく。作成した機能の25%程度しか使われないのが一般的らしいのでシェイプアップという意味でもタスクを削るっていうのはいいのかもしれない。

バーンダウンチャート

横軸に時間。縦軸に残作業量でグラフを書く。時間が立つほど残作業量が減っていき、残作業量がなくなった時点で作業は終了。見積もりが正しければ作業量と時間がきちんと見積もれているため右下に一直線のグラフとなる。作業量と時間とがわかりやすくていいなぁと思う。Readmineとかでも同じといえば同じなんだけど、全体の作業量から引いていくっていう感じで作れないものかなぁ。僕としては縦軸を作業量としてある一定量まで上に上がれば作業が終了としたほうがいいと思う。こっちの方が途中の仕様変更等で作業量の絶対値が増えた場合に対処がしやすいし、わかりやすい。可視化って大事だと思った。

まとめ

僕は組み込み系のきっちり決まった仕様・スケジュールで仕事をしてきて、今現在状況に応じて変わるスケジュール・仕様・作業量が変わる業界に移って戸惑っているんだけど、考え方を変えるって意味で読んでみてよかった。いろいろ腑に落ちる考え方とかも多かったし可変的にものを作成する環境にいる人は読んで損はない本だと思います。

*1: 書いてて思ったけど、まぁ普通にやってるな・・・。

福利厚生って単なる天引きじゃね?

http://www.gamer.ne.jp/news/201204160017/

福利厚生って名前が違うだけで、お金を給料として払うのかそれとも会社が勝手に決まった部分に使って社員に与えるのかの違いがあるだけだよね?無料でランチがでるよりランチ代として終業1日ごとに千円もらったほうがいいし、家賃補助が3万出るとかよりも給料が3万上がったほうがいいんじゃないの?

会社にとっては自由に使える金を決まったところに使わせることで無理やり従業員の環境を良くすることで体調面を管理して頑張って遅くまで働かせることができるし、普通に給料を払うよりも税金がすごく低くなるから(*1)会社にとっては一石二鳥の策だと思うんだよね。

別に福利厚生が手厚いからっていい会社ってわけじゃないと思うよ。

*1: たしか。うろ覚えだけどあってるはず

SPモードメールの容量を減らす方法

スマホってすごくメモリ容量が少なくて、気がつくとすぐに空きメモリがなくなる。だから、僕は定期的に使わなくなったアプリのアンインストールをするんだけど、SPモードメールだけ使ってる容量の桁が違うことが目に付く。多分送受信したメールをすべてバカみたいに本体においてるからだと思うんだけど、これを解決するには自動で削除するしかなさそう。

メールを自動でゴミ箱に移す

操作がちょっとわかりにくくて、SPモードメールのアプリを立ち上げて、「受信BOX」を長押しする。するとメニューが出てくるから「自動削除設定」を選んでどれくらい経過したメールを削除するかの設定を行えばいい。「送信BOX」も同じね。

ゴミ箱の削除

↑の操作をやれば自動的に削除してくれるのかとおもいきやゴミ箱に移すだけ。だから定期的にゴミ箱を空にしてあげないといけない。操作は「ゴミ箱」を選択してメニューボタンを押してから「全削除」を選択すれば削除される。

まとめ

全般的にどうしてこうなったとしか思えないアプリ設計。普通に保存先をSDカードに移してくれるだけでこんなめんどくさい動作を行う必要がなくなるのに保存先を選択できない意味がわからん。ゴミ箱って言ってるのに自動削除の期間を選べない意味もわからん。保存先とか調べて定期的にどうにかするメーラー的なアプリつくろうかなー。まぁ、とりあえずメールを直近の1か月分だけ残して全部削除してやったら30Mぐらい使用容量が減ったからやる価値はあると思う。

メールを削除しないと本体にたまり続けていく仕様をつくることでメールの定期削除を促す。これは、過去を振り返らずに前を向いて行きましょうっていう暗黙的なDOCOMOからのメッセージなのかもしれない。余計なお世話だけど・・・。

スマホでimgタグのwidth、heightを取る場合に注意すること

imgタグのwidth、heightは画像のロードが完了しないと取れないっぽい。対応策としてはimgタグでloadが終わった後に取れば問題ない

$.each($('selecter').children(), function() {
    if(this.tagName.toLowerCase() === 'img') {
        $(this).load(function() {
            // ここでwidthもしくはheightを取る
        });
    }
}

そんだけ。