2012-12-29

「お金をかけないDBチューニング」という題名で社内LTした

MySQL

お金をかけないDBチューニング from Kazuya Sato

今年1年を振り返る意味で「お金をかけないDBチューニング」という題名でLTしました。

詳しくはslideshareにアップしたのでそちらをご覧ください。

DBチューニングで真っ先に思い浮かぶのがサーバー増強等のハードウェアの対応ですが、

僕が関わったプロジェクトでは、

諸事情であまりハードウェアへのコストがかけられない(Orz)
途中から引き継いだが過去の負債が多くアプリ側のDB、SQL構成がボトルネックになっている(OrzOrz)
ハードウェアでの対応は根本の重たい原因が残ったままなので最初の手段としては相応しくない

ということもあり、ハードウェア対応の前にアプリ側の対応をする必要がありました。。

という状況で僕が対応した、また対応したい事は、

my.cnfのチューニング(対応したい)
SQLのチューニング(対応した)

の2つです。この2つのチューニングであればコストがかからず、

また根本のDBが重たい原因を解消する事が出来ます。

my.cnfのチューニング

これはまだ対応しておらず、僕が調べて試したい事になりますが、基本的に、

my.cnfのチューニング = メモリ割当の最適化

となります。

key_buﬀer_size、sort_buﬀer_size、record_buﬀer_size、

それぞれをサーバのメモリと他のミドルウェアを考慮して割り当てます。

最適なメモリ割当に関しては調べた限り以下の感じでした。

key_bu&#64256;er_size + (sort_bu&#64256;er_size + record_bu&#64256;er_size) * max_connections
実メモリサイズ + スワップメモリサイズ

それ以外のもチューニング出来る項目は以下のようなものがあります。

max_allowed_packet
table_open_cache
query_cache_size
innodb_buffer_pool_size
innodb_log_buffer_size

この辺もチューニングする事でより速くなると思われます。
(今回は時間の都合と、簡単に出来るチューニングということで省きました。)

SQLのチューニング

今年一番の収穫だったのがmysqldumpslowコマンド。

MySQL5.1からあるようでしたが最近鍵本を見て初めて知りました。

MySQLのスロークエリログを解析してくれます。実行は以下の通りです。

$ mysqldumpslow [option] [log_file]

## よく使うオプションは-s(並び替え)
-s c  → 総クエリ数の多い順
-s l   → 総ロックタイムの長い順
-s r  → 総行数の多い順
-s t  → 総実行時間の長い順
-s a(l | r | c) → 各平均の長い順

実際に実行した結果は以下の通りです。

## 文字列 → S、 数字 → N と置換してくれる
## Count:総クエリ数 Time=平均実行時間(総実行時間)
## Lock=平均ロックタイム(総ロックタイム) Rows=平均行数(総行数)

$ mysqldumpslow -s c slow_query.log | less

Count: 49  Time=1.49s (73s)  Lock=0.00s (0s)  Rows=1.0 (49), user[user]@2hosts
  SELECT * FROM tbl1 WHERE  name = 'S'  ORDER BY id LIMIT N

Count: 36  Time=1.47s (52s)  Lock=0.00s (0s)  Rows=1.0 (36), user[user]@2hosts
  SELECT * FROM tbl2 WHERE id = 'S' AND deleted = 'S' ORDER BY id LIMIT N
 .
 .
 .

WHERE句やLIMIT句などの値をSやNに置換してくれるので、

条件式の値が異なるSQLを丸めてくれるので生ログよりとても見やすいです。

秒数はさほどだけど頻繁にスロークエリにのるSQLや、

実行時間がやたら多いSQLなどを簡単に確認する事が出来ます。

実際のSQLチューニングに関しては、

既存DBに手を加えるのはかなりリスクだったので、

テーブル変更はせず以下のような形でSQLのみをチューニングしました。

最低限のレコードを取得するようにする
なるべくJOINの数を減らす
テーブルをまたぐORDER BYはなるべく避ける

基本的なことですが、

データ件数が多い場合(10万件以上とか)は、上の項目1つやるだけで数sec落とせたりします。

もしこれでもまだDBサーバが重たいようであれば、

そこでサーバー増強や台数を増やす等の対応となります。

重たい原因がない状態でより最適化が出来るはずです。

2012-11-07

「第4回テックヒルズ -UI、UXの衝撃-」に参加してきた

http://crooz.co.jp/techhills/
「第4回テックヒルズ -UI、UXの衝撃-」に参加してきました。

参加者は約300名。(おそらく後から参加した方もいたのでもっと多いです)
参加した方々の職種が、デザイナー、エンジニア、営業など、バランス良く参加していたのが印象的でした。
それだけUI/UXへの関心が高まっているという事だと思います。

■UX TOKYO　酒井洋平さん

UI(ユーザーの主観的経験を支える接点) / UX (ユーザーの主観的経験)

UXデザインとは

主観的経験をデザイン　ではない
主観的経験を想定した設計　である

価値発見プロセスとは

「計測」
「気づき」
「ベンチマーキングと観察」
「プロトタイピング」
「ストリーテリング」

UXは分野横断的な活動が必要

マーケティング
プランナー
デザイナー
エンジニア
QA
カスタマー

全ての職種でユーザの体験を最高にするために"些細な事にも"気をきかせるとのこと。
これはとても大切な事だと感じました。

■NHN Japan株式会社　橋本健吾さん

1.Simple

なぜUIにシンプルさが必要か
→インターネットの情報共有、仕組みが関わる

1997-2005：ホームページ作成、検索するエンジン→WebからUserにinformationを受け取る一方通行
2005-2012：ブログメディアの台頭、不特定多数の出現、Web2.0→非専門家による情報提供

→シンプルなインターフェースが必要になってきた

シンプルなビジュアルデザイン(LINEの場合)

A:スタンプを使ったにぎやかなバナー
B:「無料通話」というキャッチコピーとアイコンのみのバナー

→Bの方が効果的だった
→シンプルなので伝わりやすい、印象が強い

2.Quick & Fast

UI ⇄ UX ⇄ Develop
Prototype ⇄ Research & FB ⇄ bts

3.意匠を高める

ビジュアルデザインを突き詰めて行く
プロトタイプデザインを繰り返すことで品質の凹凸をなくす
些細な違和感に気づく事が重要(アイコンの色、メニューの出し方等)
UIデザイナーの選択がUXを様々に彩る
使う人の立場、状況を踏まえ、デザインはシンプルに

■株式会社ディー・エヌ・エー　坪田朋さん

slideshreはこちら

いけてないUI

ユーザーニーズの不理解
市場の勉強不足　→　リサーチが必要
コミュニケーション不足
チューニング不足　→　Scrum開発

サイクル

リサーチ
要件定義、UI開発
テストリサーチ
リリース

を繰り返し

リサーチ

定量調査(アンートを通じて取得したデータを分析)
定性調査(ユーザーテストアイトラッカー)
競合調査(ペルソナユーザーからのヒアリング)

UI開発

紙、デジタルベースでのラフ案
実機でのモック作成
- HTML+CSSで作成
- 実機での検証
- 違和感を感じる場合は作り直す
- 迷ったら機能を落とす
テストリサーチ
- ユーザーテストアイトラッカー

UI設計で重要なこと

徹底的な分析
プロトタイピング
ユーザーテストの実施と繰り返し

Scrum開発

求められる事
- スピード
- 品質
最適化される事
- 優先度目的の可視化
- 役割の明確化
- コミュニケーションコスト減

※ディー・エヌ・エー独自のScrum開発とかなく、自分が経験したScrum開発と同じだったので聞き流した。。

UXという言葉、いまいち理解出来ていなかったですし、
おそらくUXを確立するような説明はまだないとは思いますが、
徐々に事例が増えてきてそれが上手く共有されつつある印象でした。

ユーザーの視点で考える事、
分析、リサーチを考える事、
Try & Catch を繰り返す事、
より良いUXにはこういった事が重要だなと強く感じます。

2012-10-22

アジャイル開発が終わった後にアジャイルサムライを読んでみた

少し前ですが、3ヶ月ほどスクラムでのアジャイル開発を仕事で行っていました。
そして終わった後に今更感がとても満ちあふれる中「アジャイルサムライ」を読んでみました。
共感出来る事、ここはもっとこうすれば良かった等、読んで色々思ったのでちょっと感想を書いてみます。

※スクラムに関しては下記の資料が分かりやすくまとまっています。

Scrum in 10 minutes
http://www.slideshare.net/kawaguti/20110118-scrum-10-mins
ざっくりわかるScrum
http://www.slideshare.net/Ryuzee/scrum-14271224

■強烈なスポットライトを浴びている感覚

アジャイルに開発するというのは、これまで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚

アジャイルサムライでアジャイルな働き方の警告として上記のような表現がありました。

短いイテレーションの中でチームで出来ると言った結果を出し続けなければいけないので、
人によっては想像以上のプレッシャーを感じますし、
1人1人に一定以上の技術力やコミュニケーション力、チームとして動く意識が求められます。

ウォーターフォールであれば長い期間なので多少のリカバリーは効くとは思います。
(だいたいそれはデスマーチにつながる流れですけどね。。)
アジャイルだとそれが通じない、出来なかった場合はプロダクトオーナーに出来ませんでしたと言うしかない。

僕はこの表現を読んだとき、「良く言えばスポットライト、悪く言えばサーチライト」だなと思いました。

たぶんアジャイルに対し人によっては、
自分の力が求められるのでやる気が出るとか、
本当に短い期間で成果出せるのかどうか不安になるとか、
というポジティブな考えを持つ人とネガティブな考えを持つ人で分かれると思います。
この考えに良い悪いはなく、単純にアジャイルに向いているかどうかの違いになります。

アジャイル開発はチームの生産性、協調性、意思疎通がとても重要だと僕自身感じたので、
(これらがないと顧客、しいてはエンドユーザーを納得させれるものが作れなさそうだしチーム内のモチベーションも下がる)
そういう意味でもチームメンバーの人選は非常に重要だと思います。

■同じ仕事場で働くことがアジャイルではない

同じ仕事場で働くということは、
仕様などの確認がすぐ出来る、意思疎通がしやすいなど、多くのメリットがあります。
アジャイル開発はこのことが前提としてあります。

が、受託開発や複数のプロジェクトを抱えている等、
どうしても同じ仕事場で働けないということはよくあることです。
ではそういう場合、アジャイル開発は出来ないのかとなりますが、

僕もアジャイルサムライの内容も答えは出来るです。
たしかに同じ仕事場で働いた方が効率性はありますが、それを何かしらの手段で補うことも出来ます。

僕が関わったプロジェクトの場合、受託開発のためクライアントも含め同じ仕事場で働くことは到底無理でしたが、
まずイテレーション開始、終了時には全員が集まってキックオフMTG、振り返りMTGをするようにしていました。
(スクラムでいうスプリントプランニングとスプリントレビュー)
たぶんこれがないと意思疎通ややることの認識のズレが生じてしまったり、
チームとしてのまとまりもだんだん薄れてしまうと思うのでこれはやるべきだと思います。

そして、イテレーション内のコミュニケーションは、電話、メールに加えチャットワークを導入していました。

■クラウド型ビジネスチャットツール｜チャットワーク（ChatWork）
http://www.chatwork.com/ja/

仕様確認やこういうこと出来ますかね？のような簡単な確認をしたいケースが結構あったのですが、
電話だとお互いいる時間にしか出来ないしそもそもお互いがいる時間が不明瞭、
メールだとどうしてもかしこまった内容を書かなくてはいけなくて気軽に出来ない、
と今までのコミュニケーションツールだと気軽さとスピード感がなくてアジャイル向きではあまりなかったです。

チャットワークを導入したことによって、
チャット形式ということもあって気軽に書ける、
ログが残るのとスマートフォンアプリもあるのでいつでも確認、レスが出来る、
とプロジェクト内のコミュニケーションツールとして有効活用が出来ましたし、
受託会社⇄クライアントというコミュニケーションの距離もだいぶ近くなったと感じました。

電話→急ぎの要件などのコミュニケーションツール
メール→電話、チャットワークに当てはまらないコミュニケーションのツール
チャットワーク→仕様確認、相談事などの簡単な内容のコミュニケーションツール

のような使い分けをしたことによってある程度同じ仕事場で働けない事の補いは出来たと思います。

ので同じ仕事場で働けない→アジャイル開発が出来ないという訳ではないと感じています。
(とはいえ同じ仕事場で働いた方が効率性が全然違うのは強調しておきます。)

■アジャイル開発がベストな手法ではない

これはアジャイルサムライにも書いてますし、
僕自身、スクラムを終えた後に一番強く感じた事です。

今、結構ウォーターフォールが叩かれて、アジャイル開発でやろうぜ！みたいな流れになってる気がしてます。

ウォーターフォール=デスマーチみたいな印象になってるっぽいですが、
それはウォーターフォールが悪い訳ではなく、単純にそのプロジェクトに合わなかっただけだと思います。

そして、その状態を打破すべくアジャイルに乗り換えてると思いますが、
別にアジャイルになったからって何かが劇的に改善されるとかは思わない方がよいと思います。

たしかにアジャイルだとイテレーションが短く機能が分割されているためデスマーチになりづらいですが、
それ相応の生産性やコミュニケーションが求められる分、1人1人にかかる負担は大きいと思います。

また、ウォーターフォールは時間が経つごとに右肩上がりに忙しくなってきますが、
アジャイルは常に一定のラインで忙しいという感じです。

既存の手法にはどうしても長所と短所があるため、
あるプロジェクトに必要としているものを全て用意してある手法を
既存手法から見いだすことはほぼ出来ないと思います。

僕の関わっているプロジェクトはスクラムが終わってまたウォーターフォール的な流れに戻りましたが、
スクラムで培ったテスト駆動開発やチャットワークでの気軽なコミュニケーションは生かしたまま開発しています。
その方がコンテンツの品質を保てますし、引き続き気軽なコミュニケーションが出来るためです。

最適な手法を見いだすためには、
プロジェクトに最適な既存手法を見いだすだけではなく、
不足しているものを他の既存手法から補ったり、
もしくは独自で編み出したものを取り入れたり等、
常に手法を改善するために考え続けなくてはいけないと感じました。

2012-09-09

Three.jsを使ってメッシュとFPSを表示をしてみた

WebGL and Three.js
http://www.slideshare.net/yomotsu/webgl-and-threejs

先日、HTML5 Conference 2012に参加し、
このセッションは参加しなかったのですが、資料を見て非常に興味を持ったので触ってみました。

■Three.jsとは

WebGLを扱うのはそれなりに敷居が高いのですが、
※ほんの少しリアルタイム3Dの研究に携わってた身ですが挑戦して挫折Orz

このThree.jsはWebGLをラッパーしたライブラリであり、
複雑な手順もなく直感的にWebGLを扱うことが出来ます。
https://github.com/mrdoob/three.js/

■Three.jsをダウンロードして読み込む

githubから/build/three.min.jsを任意の場所に置き、HTMLから読み込みます。

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Three.js</title>
<script src='resource/js/three.min.js'></script>
</head>
<body>
<script>
.
. // ここに処理を書く
.
</script>
</body>
</html>

■Three.jsの初期設定をする

3Dを表示するには以下の設定が必要です。

レンダリング：3D処理を描画する
シーン：3Dモデルやカメラ等を登録する空間
カメラ：空間内の視点

Three.jsでは以下のように設定します。

<script>
    var camera, scene, renderer;
    // 描画する領域
    var width = window.innerWidth;
    var height = window.innerHeight;

    init();

    function init() {
        // set renderer
        // ブラウザサイズで描画するよう設定
        renderer = new THREE.WebGLRenderer();
        renderer.setSize(width, height);
        document.body.appendChild(renderer.domElement);

        // set scene
        // シーンを宣言
        scene = new THREE.Scene();

        // set camera
        // カメラの位置を手前にして設定
        camera = new THREE.PerspectiveCamera(75, width / height, 1, 10000 );
        camera.position.z = 1000;

        // シーン、カメラをレンダリングする
        renderer.render(scene, camera);
    }
</script>

■3Dモデルを登録する

これだけだと何もない空間になってしまうので3Dモデルをシーンに登録します。
今回はgithubのサンプル通り四角形メッシュを登録します。

<script>
    var camera, scene, renderer;
    // 3Dモデルを格納する変数
    var geometry, material, mesh;
    .
    .
    .
    init();
    animate();

    function init() {
        .
        .
        .
        // set model
        // 正方形を宣言
        geometry = new THREE.CubeGeometry(200, 200, 200);
        // 赤っぽいワイヤーフレームを宣言
        material = new THREE.MeshBasicMaterial( { color: 0xff0000, wireframe: true } );
        // 上記2つを基にメッシュを生成してシーンに登録
        mesh = new THREE.Mesh(geometry, material);
        scene.add(mesh);
    }

    // 生成したメッシュを回転させながらレンダリング
    function animate() {
        requestAnimationFrame(animate);

        mesh.rotation.x += 0.01;
        mesh.rotation.y += 0.02;
        renderer.render(scene, camera);
    }
</script>

■FPSを表示する

ブラウザ表示で気になるのが処理速度。3DではよくFPSを用いて計測します。
stats.jsを使うとJSによるFPSの計測が可能なのでこれを使ってみます。
https://github.com/mrdoob/stats.js

<script src='resource/js/three.min.js'></script>
// Stats.jsを読み込む
<script src='resource/js/Stats.js'></script>
.
.
.
<script>
    var camera, scene, renderer;
    // FPS表示を格納する変数
    var stats;
        .
        .
        .
        document.body.appendChild(renderer.domElement);

        // set stats
        // 左上に表示するようCSSを記述してbody直下に表示
        stats = new Stats();
        stats.domElement.style.position = 'absolute';
        stats.domElement.style.top = '0px';
        stats.domElement.style.zIndex = 100;
        document.body.appendChild(stats.domElement);
        .
        .
        .
        renderer.render(scene, camera);

        // レンダリングするたびにFPSを計測
        stats.update();
    }
</script>

ブラウザで確認すると以下のようになります。
http://bossato.github.com/sample/three/

今回は触りだけですが、APIが豊富で3Dモデルのインポートも出来るようなので、
何か作ってみたいですねー。

2012-07-01

Pinterest風のレイアウトが出来るWookmark jQuery pluginを使ってみた

jQuery

Pinterestのように要素をレンガ上に並べるレイアウトが近年流行っていますが、
そのレイアウトをシンプルなスクリプトで表示出来るのが「Wookmark」です。

The Wookmark jQuery plugin
github Wookmark-jQuery

■デモ

githubにあったサンプルをこちらに置きました。

■使い方

外部ファイル

jquery.jsとwookmark.jsを読み込みます。

<script type="text/javascript" src="jquery-1.7.1.min.js"></script>
<script type="text/javascript" src="jquery.wookmark.js"></script>

HTML

レンガ状にレイアウトするコンテンツをリスト要素で並列に並べます。
各要素のidは後述するwookmarkの実行で使用します。

// div：レイアウト全体の領域
// ul：レンガ状にするコンテンツのリスト要素
// li：各コンテンツ要素

<div id="main" role="main">
  <ul id="tiles">
    // 要素分を繰り返し
    <li><img src="images/image_1.jpg" width="200" height="283"><p>1</p></li>
  </ul>
</div>

JavaScript

リスト要素のidを指定してwookmarkを実行します。
必要に応じてオプションを指定します。

<script type="text/javascript">
  $(document).ready(new function() {
    var options = {
      autoResize: true, // ブラウザの拡大縮小に合わせて要素を自動でリサイズするかどうか
      container: $('#main'), // CSSを適用している要素を指定
      offset: 2, // 要素間の隙間を指定
      itemWidth: 210 // 各要素の幅を指定     
    };

    var handler = $('#tiles li'); // レンガ状にする要素を指定
      
    handler.wookmark(options); // wookmarkをオプション付きで実行
});
</script>

■APIとか使って表示したい

HTMLに記述したコンテンツだけではなく、
もっと見るなどのユーザーのアクションをトリガーにしてjsでコンテンツを追加する場合

<script type="text/javascript">
  $(document).ready(new function() {
    /*
    wookmarkの実行がここに記述されてると想定
    */

    // ボタンをクリックしたらコンテンツを追加
    $("p").live("click", function(){
      $.ajax({
        url: 'example.json',
        dataType: 'json,
        success: function(data){
          var html='';
          var i=0, length=data.length;
          for(; i<length; i++) {
            html += '<li>';
            html += '<img src="'+data.img+'" width="200" height="'+data.height+'">';
            html += '<p>'+data.title+'</p>';
            html += '</li>';
          }
          $('#tiles ul).append(html);

          // wookmarkを一旦クリアして再度実行
          handler.wookmarkClear();
          handler = $('#tiles li');
          handler.wookmark();
       }
     });
  });
</script>

はじめはappendした後にhandler.wookmark()を実行したのですが、
appendはされるものの追加したコンテンツがタイル状にならず。。
APIを使ったサンプルを見る限り、JSなどで追加した場合は一旦handler.wookmarkClear()でコンテンツをクリアして
再度wookmarkを実行する必要があるようです。
(色々紹介しているブログは見たのですがこの辺があまり紹介されておらず結構苦労した。。)

■タイル要素の高さが動的な場合

タイル要素内の画像の高さが指定されていない(画像を動的に表示してるとかの理由で)場合
画像の読込が遅いと読み込まれる前にwookmarkが実行され、
タイル要素の高さが画像なしの高さになってレイアウトが崩れてしまう場合があります。

その場合、setTimeout関数でわざと遅延させてwookmarkを実行させたり、

<script type="text/javascript">
  $(document).ready(new function() {
    // 3秒後にwookmarkを実行
    setTimeout(function(){
      /*
      wookmarkの実行がここに記述されてると想定
      */
    }, 3000);
  });
</script>

load関数で最後のタイル要素内の画像が読み込まれたら実行とかで多少回避出来るかと思います。
※load関数はIEでは対応していないようです。

<script type="text/javascript">
  $(document).ready(new function() {
    // 最後のタイル要素内の画像が読み込まれたら実行
    $("#tiles li:last img").load(function(){
      /*
      wookmarkの実行がここに記述されてると想定
      */
    });
  });
</script>

2012-06-04

jQuery Mobileについて社内LTした

「jQuery Mobileを触ってみた」
http://bossato.github.com/lt/jquery_mobile/

jQuery Mobileを仕事で使うようになり、色々知識がたまったので社内でLTデビューしました。
発表内容は大きく以下の通りです。

1.jQuery Mobileの紹介

PCとスマートフォンに対応したUIフレームワーク
タッチデバイスに最適なUIが簡単に作れる
広範囲なプラットフォームとの互換性

2.jQuery Mobileの使い方

準備やページ構造等
こういうUIが作れるというサンプル
実際に使って便利だった機能について

3.Tipsとか注意点とか

UIについて
Androidについて
Ajaxについて

1や2に関しては公式ドキュメントのほぼ抜粋です。
その中で僕が良いと思った項目や機能を発表しました。
それよりも伝えたかったのが3についてです。

UI(jQuery Mobile)について

仕事とかでたまにjQuery Mobileを使いたい！というお客様がいてその理由が、
jQuery Mobileを使うとリッチなコンテンツが出来る！
誤解されやすいかもですが、あくまでjQuery MobileはUIフレームワークです。
カルーセル出来ません。スライドショーみたいなこと出来ません。
ただ、jQueryの先駆者の方々が作られてきたjQueryプラグインや
公式にいくつかあるjQueryMobileのプラグインなどを使って対応することは可能です。
(その分、追加の対応となることを考慮してもらえれば)

UI(CSS)について

jQuery MobileのUIを変えたい場合は大きく以下の2つの方法があります。

- ThemeRollerを使う
- jQuery MobileのCSSをオーバーライドする

色を変えたい、文字を変えたいレベルであれば上記の方法で問題ないです。
しかし、jQuery MobileのUIの仕様を外れるような変更(paddingの調整など)は、
jQuery MobileのCSSや他のパーツまで影響されないようになどに注意する必要があります。
そのため、かかるコストや影響範囲を考えた上でもなるべく避けた方がよいです。
早い段階でjQuery Mobileで出来るUIというのを調整した方が後々幸せになれます。
それでも変えたいという場合は、jQuery Mobileを選択肢から外すべきだと思います。

Androidについて

今まで触ってきた感覚ですが、Ajax処理、アニメーション周りでAndroid端末の挙動の不安定さを感じます。
そもそもAndroid端末自体のCSS周りが怪しいのと、
Android端末依存の問題はjQuery Mobileに限らず避けられないので、
ここの関しても早めの段階でAndroid端末の挙動に対して調整した方が後々(ry

Ajax処理について

jQuery Mobileを触った人の流行として、Ajaxを無効にする流れが出来てます。
理由はアニメーションが重い、スクリプトが動かない、挙動が不安定など。
そんなあなたに読んで頂きたい記事が下記です。

そろそろjQuery Mobileでajaxを無効にしてるやつに一言いっておくか - へっぽこプログラマーの日記
http://d.hatena.ne.jp/pikotea/20120405/1333631161

こちらの記事ではAjaxを疑うのではなく、1つ1つの挙動を確認して対処するように書かれています。
また、ページ表示が重たいという方は追加で以下の項目も確認して頂ければと思います。

CSS、JSの順に外部ファイルを読み込む
CSSで@importを使用しない
アイコンやボタン等の画像でCSSスプライトを用いる
CSS、JSは圧縮する

基本的なことですがこういう所から対処をすることが大事な気がします。

Ajax無効はせっかくのjQuery Mobileの機能を削ることになるので逃げちゃダメ。　です。

2012-04-19

テックヒルズ2012#2 「ネイティブアプリ」 vs 「Webアプリ」に参加してきた

http://atnd.org/events/25630

発表者の方々がDeNA、カヤック、サイバーエージェント、CROOZと
アプリといえばな感じで面白そうだと思い参加しました。

■jQuery MobileではじめるWebアプリ開発(CROOZ株式会社渡邉真人さん)

発表資料：http://msto.jp/th2/

タッチデバイス向けのUIフレームワークであるjQuery Mobileについての発表。
jQuery Mobileについてすごく丁寧にまとまった発表だと思いました。
(公式リファレンスより見やすいと思ってます。)

僕個人もjQuery Mobileを触っています。発表資料にはありませんでしたが、
UIだけではなくAPIも充実しているので使いやすいフレームワークだなという印象です。

http://msto.jp/th2/#p16
個人的に気になった箇所はページ表示の高速化について。
jQuery Mobileを使っていて気になる点がページ遷移やローディングなどの遅さ。
ajaxのせいなのかどうかなど色々ネットでも討論されています。
(個人的にはajax切るとページ遷移が寂しいのでよほどのことがない限りajaxはonにしてます)
それを解消する手段としてプリフェッチとDOMキャッシュは試してみる価値はあるなと思いました。
静的ページには有効だと思いますが、動的ページの場合、キャッシュがどうなるかなど検証も必要そうです。

■ExGame/ngCore HTML5開発者が伝える、HTML5でアプリに迫る手法(株式会社ディー・エヌ・エー　紀平拓男さん)

HTML5による描画能力の向上→ネイティブアプリと同じ水準の挙動が可能
ネイティブアプリに劣っている点
- 3D　WebGLが使えない
- 音楽　制限が多い、タップしたタイミングで流すしかない(iPhone)、2つ以上の音楽が流せない
- 速度　レンダリングが主な問題
ネイティブアプリより優れている点
- 互換性　Android、iOS、Windows Phone、PS Vita、3DSなど
- 開発効率　HTML+CSS+JavaScriptの延長、ノウハウ、学習のしやすさ、先駆者が多い
- インストール不要　ユーザー、開発者の負担減
Webアプリに向いているもの→一般アプリ、カジュアルゲーム
ネイティブアプリに向いているもの→作り込んだゲーム

■最新事例に見るHTML5でつくるアプリの可能性(株式会社カヤック　比留間和也さん)

広告とWebアプリの親和性について
広告は一期一会
- ネイティブアプリだとインストールの手間からユーザーが離脱する
- Webアプリだとその場で出来るので一期一会に向いている

■「Native x Web でいいとこどり開発〜ピグトーク」(株式会社サイバーエージェント　原一成さん)

アメーバピグのスマートフォン対応についての話

スマートフォン対応での要望：動かしたい！
- PCの場合→Flash
- SPどうするか
  - OpenGL→Flashの作り方と合わない、イニシャライズが重い→HTML5
HTML5での処理
- 服を着せる
  - 画像が多いのが難点
    - JSON形式にした(画像サイズ、配置する起点、base64画像など)
    - DOM追加(data-parts data-actionなど)
- アバターのアクション処理
  - バイナリデータ化→PCのFlashと同様のものが使える
    - JavaScriptで解析
    - 体のパーツをdivにした
    - divの-webkit-transformを使ってflameごとに移動
    - GPUにのせて高速化
TIPS
- iPhoneとAndroidのサイズが違う
  - background-size: cover; を使う
- Offline Application Cache

この後ディスカッションを行ったのですが、そこで気になった点はインストールについて。
インストールするという行為はユーザーにとってメリットデメリットがあります。

インストールが面倒くさい→離脱してしまう
インストールをする→Webアプリであるログインの手間がなくなる→使い続けてくれる

そういう所は、カヤックの比留間さんが発表したように、
広告等の一期一会なものに関してはインストールがいらないWebアプリが最適ですし、
アメーバピグのような作り込んで課金スタイルを取るようなアプリはネイティブアプリだろうなと感じてます。

結論としてはどのアプリを使うかではなく、どういう要件定義があってそれに最適なアプリを選択する、
というところになるなぁという感想でした。

初めてのシステムと日記

システムも日記も初めてです。

「お金をかけないDBチューニング」という題名で社内LTした

my.cnfのチューニング

SQLのチューニング

「第4回テックヒルズ -UI、UXの衝撃-」に参加してきた

■UX TOKYO　酒井洋平さん

■NHN Japan株式会社　橋本健吾さん

1.Simple

2.Quick & Fast

3.意匠を高める

■株式会社ディー・エヌ・エー　坪田朋さん

アジャイル開発が終わった後にアジャイルサムライを読んでみた

■強烈なスポットライトを浴びている感覚

■同じ仕事場で働くことがアジャイルではない

■アジャイル開発がベストな手法ではない

Three.jsを使ってメッシュとFPSを表示をしてみた

■Three.jsとは

■Three.jsをダウンロードして読み込む

■Three.jsの初期設定をする

■3Dモデルを登録する

■FPSを表示する

Pinterest風のレイアウトが出来るWookmark jQuery pluginを使ってみた

■デモ

■使い方

■APIとか使って表示したい

■タイル要素の高さが動的な場合

jQuery Mobileについて社内LTした

テックヒルズ2012#2 「ネイティブアプリ」 vs 「Webアプリ」に参加してきた

■jQuery MobileではじめるWebアプリ開発(CROOZ株式会社渡邉真人さん)

■ExGame/ngCore HTML5開発者が伝える、HTML5でアプリに迫る手法(株式会社ディー・エヌ・エー　紀平拓男さん)

■最新事例に見るHTML5でつくるアプリの可能性(株式会社カヤック　比留間和也さん)

■「Native x Web でいいとこどり開発〜ピグトーク」(株式会社サイバーエージェント　原一成さん)

my.cnfのチューニング

SQLのチューニング

■UX TOKYO 酒井洋平さん

■NHN Japan株式会社 橋本健吾さん

1.Simple

2.Quick & Fast

3.意匠を高める

■株式会社ディー・エヌ・エー 坪田朋さん

■強烈なスポットライトを浴びている感覚

■同じ仕事場で働くことがアジャイルではない

■アジャイル開発がベストな手法ではない

■Three.jsとは

■Three.jsをダウンロードして読み込む

■Three.jsの初期設定をする

■3Dモデルを登録する

■FPSを表示する

■デモ

■使い方

■APIとか使って表示したい

■タイル要素の高さが動的な場合

■jQuery MobileではじめるWebアプリ開発(CROOZ株式会社 渡邉 真人さん)

■ExGame/ngCore HTML5開発者が伝える、HTML5でアプリに迫る手法(株式会社ディー・エヌ・エー 紀平 拓男さん)

■最新事例に見るHTML5でつくるアプリの可能性(株式会社カヤック 比留間 和也さん)

■「Native x Web でいいとこどり開発 〜ピグトーク」(株式会社サイバーエージェント 原 一成さん)

■UX TOKYO　酒井洋平さん

■NHN Japan株式会社　橋本健吾さん

■株式会社ディー・エヌ・エー　坪田朋さん

■jQuery MobileではじめるWebアプリ開発(CROOZ株式会社渡邉真人さん)

■ExGame/ngCore HTML5開発者が伝える、HTML5でアプリに迫る手法(株式会社ディー・エヌ・エー　紀平拓男さん)

■最新事例に見るHTML5でつくるアプリの可能性(株式会社カヤック　比留間和也さん)

■「Native x Web でいいとこどり開発〜ピグトーク」(株式会社サイバーエージェント　原一成さん)