UXとかUIとか大好き竹内です。こんにちは。
究極のUXって多数決でしかない様な気がするのは気のせいですかね。

元々は何用語なんでしょうか？詳しいことはわかりませんが、WEB界隈ではかなり頻繁にこの言葉を目にしたり聞いたりする様になりました。
仕事柄、WEBサイトのUIや、サービスフローや動きに関するUXなどにはいつも「なんで？」「どうして？」と疑問を抱きながら接するようにしています。

もちろんそれはPCやスマートフォンの画面の中だけではないです。
「どうしてここは引き戸なんだろう？」「どうして左が登りで右が下りなんだろう？」「手すりがここで終わってるのは何でなんだろう？」「こっちにもあれば便利なのにな」「どっちがどっちかわからないよ」「なんで何も書いてないの？」「一見お洒落なだけで使いにくいね」･･･などなど、それがUXとかUIとかいう言葉で括られる物とは特に意識しなくても生活していれば色々と感じるものです。

お疲れ様です。横井です。

現在、案件と案件の谷間におりまして、ちょっと時間に余裕ができましたので、
普段できないことをやろうと思い、Ruby on RailsをMy PC（Windows7上）にインストールしていろいろ触っているとろこになります。

最近、Rubyの本を読みだしたこともあり、非常に気になっていたので、ちょうど良いタイミングと思い、始めてみました。
がしかし、環境を構築するだけでもなかなかどうしての状態で思うように進んでいない状態です。

まず、はまったところは、RMagick（ImageMagickをRubyで扱えるようにした関数）のインストールのところです。
最新の環境（Ruby1.9.2 + rails3.2.8）でRMagickをインストールしようとしましたが、どうしても途中でアボートしてしまって、インストールできませんでした。
（Google先生に聞くとインストールできた方を紹介してくれましたので、マネをしてみましたが、無残な結果となりました。結局、Rubyのバージョンを1.8系に入れ直して、無事インストールできました。）

現在は、FacebookのOAuth認証をやってみようとがんばっておりますが、エラーの嵐から抜けられないくなっております。

RoRはフレームワークと言うより、ミドルウェアに近い感覚で、扱いに慣れていないと設定している時間をかなり取られそうだなという感じです。

しばらくは戦いから抜け出せないと思いますが、戦いから抜けだせるレベルになったら、案件でも使ってみたいと思っております。

ではでは。

ミステリー小説が大好き竹内です。こんにちは。
森博嗣の作品が大好きですが最近のはまったく読めていません。

WEB大好き竹内です。こんにちは。
生活の殆どがWEBと繋がっています。

レスポンシブウェブデザイン。流行っていますね。
実際の導入以上に言葉がバズワード化して一人歩きするのはこの業界ではよくあることですが、これもまたそのひとつと感じています。
レスポンシブウェブデザインの定義がはっきりしないまま「PCとスマホで同じコードで見られること」とか「PCとスマホでレイアウトが変わる」とか「画面サイズを変更するとレイアウトが変わる」など漠然とした意味でこの言葉を使っている人も多い気がします。

別に言葉遊びがしたい訳ではないので「レスポンシブウェブデザイン」がどうということでもないですし、レスポンシブウェブデザインの意味について問いただそうという訳でもないです。
ただ、流行言葉になってしまったこの概念が少し寂しいなと感じています。

と言うのも、
レスポンシブウェブデザインの様な「多種のデバイスで適切なアウトプット」という概念は、もっともっと昔から存在して、その頃はまだスマートフォンやらタブレットやらが存在していた訳ではないので、あまり目立った主張や華やかな世界ではなかったのも事実なのですが、その当時でも「テキストブラウザ」や「音声ブラウザ」の様なブラウザ、いわゆるPDAと呼ばれる様なデバイスなどは存在していて、それらの利用者に対しても問題なく情報が伝えられるというのが標準化（ではないかもしれませんが）などの理念に含まれていた様に思っています。

それが今やHTML5だ、JavaScriptを用いたリッチインターフェイスだ、レスポンシブウェブデザインだ、モバイルファーストだと叫ばれ始め、旧デバイス利用者はどの様にWEBを利用出来ているのかを想像すると心が痛みます。

僕自身、WEBは弱者の為にこそあるべきだという想いが強いので、
このままWEBが先端者(？)だけのものになって行かなければいいなと思っています。
そこにかける優しさがあるのであればこっちにも。。。そんな風に思いながらレスポンシブウェブデザインという言葉を眺めるそんな夏の終わりでした。

最近家庭の事情により留守番が多く、色々なパフォーマンスの比較に凝っています。
言語間の処理(演算)スピードの比較、ボトルネックになりやすい
データベース周りの比較などなど
文献を読むだけでは知能レベル的にしっくり来ず理解できないため…
実際に比較して勉強しています。

今回はその中からWebサーバーの比較結果について書いてみます。
2011年頃から一気にシェア率を伸ばし、シェア率第2位「IIS」の
すぐ背後に迫る勢いのシェア率第3位「nginx」と不動の第1位「Apache」を比較してみました。
Azureが順調なのかMS IISも2012年頃から復調の兆し(逆にApacheのシェア率は縮小)
があるため、今後のシェア率の動向には要注目です。
http://news.netcraft.com/archives/2012/07/03/july-2012-web-server-survey.html
(nginxのシェア率10%越えてるんですね！！)

比較はベンチマークの定番簡易ツールであるabコマンド(Apache Bench)を利用しました。
基本オプションは以下になります。
-c 同時に発行するリクエスト数
-n リクエスト発行総数
-t 負荷テストの実行時間

検証方法としては、-n(総リクエスト数)を指定してどれだけの”応答時間”で捌けたのかを
検証する方法や、-t(負荷テストの実行時間)を指定して、どれだけの”リクエスト数”を捌けたのか
を検証する方法がありますが、今回は-nを指定して、所定のリクエスト数に対してどれだけの
応答時間で捌けているのかを検証してみます。(総処理時間やスループットを比較)

******************************************************************************************
※例
ab -c 10 -n 100 “http://localhost/”
この場合、http://localhost/ に対して、同時発行(接続)リクエスト数が10、
合計100リクエストを投げることになります。(同時に10個ずつのリクエストを合計10回実施）

abコマンドの結果は以下になります。
Server Software: nginx/1.3.4
Server Hostname: comparehost
Server Port: 8000

Document Path: /
Document Length: 43279 bytes => レスポンスデータサイズ(アクセス先ファイルサイズ)

Concurrency Level: 10 => 同時接続数
Time taken for tests: 6.005 seconds => 全ての処理が完了するまでの総時間
Complete requests: 100 => 成功したリクエスト数
Failed requests: 0 => 失敗したリクエスト数
Write errors: 0
Total transferred: 4383881 bytes
HTML transferred: 4360146 bytes
Requests per second: 16.65 [#/sec] (mean) => 1秒あたりの平均処理リクエスト数(スループット)
Time per request: 600.516 [ms] (mean) => 1同時リクエストあたりの平均所要時間
Time per request: 60.052 [ms] (mean, across all concurrent requests) => 1リクエストあたりの平均所要時間
Transfer rate: 712.91 [Kbytes/sec] received => 1秒あたりの受信容量(byte数)
Connection Times (ms)
min mean[+/-sd] median max
Connect: 28 552 244.4 576 2030
Processing: 0 29 68.9 5 464
Waiting: 0 2 7.7 0 34
Total: 220 581 208.7 584 2030

Percentage of the requests served within a certain time (ms) => 処理時間毎の割合
50% 584 => 左記の場合、50%のリクエストが584ms以内に処理されたことを表す
66% 605
75% 623
80% 635
90% 702
95% 879
98% 1050
99% 2030
100% 2030 (longest request)

******************************************************************************************

検証前に、環境の確認です。
○abリクエスト元ホストは同一マシン(自サーバーからではなく別ホストからのリクエストのため
○検証環境(リクエスト先サーバー)は同一マシン
○レスポンスデータサイズ(Document Length)は同じ ※nginx贔屓でリクエスト内容は静的コンテンツ…
○ApacheのMPMはprefork
○ApacheのVerは2.2.3(2.4.3ではないです。。)

準備ができたので検証してみます。
まずは同時接続数1で100回リクエストしてみます。
◆Apache(ab -c 1 -n 100 “http://comparehost/”)
Server Software: Apache/2.2.3
Server Hostname: comparehost
Server Port: 80

Document Path: /
Document Length: 43279 bytes

Concurrency Level: 1
Time taken for tests: 12.173 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 4355000 bytes
HTML transferred: 4327900 bytes
Requests per second: 8.22 [#/sec] (mean)
Time per request: 121.727 [ms] (mean)
Time per request: 121.727 [ms] (mean, across all concurrent requests)
Transfer rate: 349.38 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 98 121 19.1 119 220
Processing: 0 0 0.4 0 3
Waiting: 0 0 0.0 0 0
Total: 98 122 19.1 119 220

Percentage of the requests served within a certain time (ms)
50% 119
66% 123
75% 128
80% 130
90% 145
95% 157
98% 198
99% 220
100% 220 (longest request)

◆nginx(ab -c 1 -n 100 “http://comparehost:8000/”)
Server Software: nginx/1.3.4
Server Hostname: comparehost
Server Port: 8000

Document Path: /
Document Length: 43279 bytes

Concurrency Level: 1
Time taken for tests: 13.142 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 4351400 bytes
HTML transferred: 4327900 bytes
Requests per second: 7.61 [#/sec] (mean)
Time per request: 131.420 [ms] (mean)
Time per request: 131.420 [ms] (mean, across all concurrent requests)
Transfer rate: 323.35 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 97 130 27.4 123 330
Processing: 0 2 1.4 2 10
Waiting: 0 0 0.0 0 0
Total: 99 131 27.3 124 330

Percentage of the requests served within a certain time (ms)
50% 124
66% 127
75% 133
80% 137
90% 158
95% 187
98% 194
99% 330
100% 330 (longest request)

接戦です。
総処理時間はApache、スループットはnginxが競り勝ちました。
nginxの方がスループットが勝っているため、マルチ処理が得意なnginxが
総処理時間でも勝りそうな気もしますが、総リクエスト数が少ない＆受信容量が勝った分なのか、
総処理時間はApacheに軍配が上がりました。
ただし、どんぐりの背比べでもあり、同時接続数も1のためあまり参考にはならない結果です。

******************************************************************************************

次は一気に同時接続数を増やし、同時接続数50で1000回リクエストしてみます。
◆Apache(ab -c 50 -n 1000 “http://comparehost/”)
Time taken for tests: 62.630 seconds
Requests per second: 15.97 [#/sec] (mean)

◆nginx(ab -c 50 -n 1000 “http://comparehost:8000/”)
Time taken for tests: 63.534 seconds
Requests per second: 15.74 [#/sec] (mean)

一気に同時接続数＆リクエスト数を増やしましたが、これもほとんど変わらない結果でした。
リクエスト数を10000回まで増やしても大きな差は発生しなかったため、
同時接続数50、且つリクエスト数10000程度であればApache、nginxで特に大きな差はなく捌けるようです。

******************************************************************************************

それではということで、次はリクエスト数を固定(1000回)し、
同時接続数を増やしていきながら処理結果を観察してみました。
※ここからリクエスト元を自サーバーからに変更してます。

◆Apache
=>同時接続数100(ab -c 100 -n 1000 “http://comparehost/”)
総処理時間　：0.229897 seconds
スループット：4349.77 [#/sec] (mean)

=>同時接続数200(ab -c 200 -n 1000 “http://comparehost/”)
総処理時間　：0.266142 seconds
スループット：3757.39 [#/sec] (mean)

=>同時接続数300(ab -c 300 -n 1000 “http://comparehost/”)
総処理時間　：0.794779 seconds
スループット：1258.21 [#/sec] (mean)

=>同時接続数400(ab -c 400 -n 1000 “http://comparehost/”)
総処理時間　：7.133020 seconds
スループット：140.19 [#/sec] (mean)

=>同時接続数500(ab -c 500 -n 1000 “http://comparehost/”)
総処理時間　：14.90692 seconds
スループット：70.97 [#/sec] (mean)

同時接続数が300以上から明らかに性能が落ちています。
MaxClientsを256に設定しているため、許容範囲を超え捌ききれなくなっているためだと考えられます。
(因みに、MaxRequestsPerChildは200にしている)
nginxはどうでしょうか！？

◆nginx
=>同時接続数100(ab -c 100 -n 1000 “http://localhost:8000/”)
総処理時間　：0.94022 seconds
スループット：10635.81 [#/sec] (mean)

=>同時接続数200(ab -c 200 -n 1000 “http://localhost:8000/”)
総処理時間　：0.180318 seconds
スループット：5545.76 [#/sec] (mean)

=>同時接続数300(ab -c 300 -n 1000 “http://localhost:8000/”)
総処理時間　：2.794196 seconds
スループット：357.88 [#/sec] (mean)

=>同時接続数400(ab -c 400 -n 1000 “http://localhost:8000/”)
総処理時間　：1.264635 seconds
スループット：790.74 [#/sec] (mean)

=>同時接続数500(ab -c 500 -n 1000 “http://localhost:8000/”)
総処理時間　：0.100467 seconds
スループット：9953.52 [#/sec] (mean)

ん？んん？？
Apacheよりスループットは高いけど、やっぱり同時接続数が増えるのと合わせて
性能は落ちるな。。。と思いきや、同時接続数が500になったタイミングで一気に
スループットが上がっています！

=>同時接続数600(ab -c 600 -n 1000 “http://localhost:8000/”)
総処理時間　：0.85274 seconds
スループット：11726.90 [#/sec] (mean)

=>同時接続数700(ab -c 700 -n 1000 “http://localhost:8000/”)
総処理時間　：0.592253 seconds
スループット：1688.47 [#/sec] (mean)

600でも引き続き高いままで、700になり再度下降し始めました。
nginxの場合は同時接続数が少なすぎると性能が落ちるのか、特性を活かしきれないようです。
いずれにせよ、Apacheと比較すると圧倒的に静的ページへの同時アクセスを捌く能力は高いようです。

【比較結果の個人的な感想】
○負荷が高くなく、早期セットアップが必要な場合は「Apache」
○負荷が高く、スケーラビリティが要求される場合は「nginx」
○静的ページに同時多数のアクセスが想定される場合は「nginx」
※動的ページは処理内容やサーバスペックによるため現状では判断できない(要調査)
○ある程度の同時アクセスが見込めない場合は「Apache」
○同時アクセス数は小さく、単純にリクエスト数が多い場合は「Apache」

Apacheも2.4.x以降に大きく性能改善がされ、同時アクセス時の処理耐性はnginxよりも
優れいているという情報もあるため、静的ページにおいてもチューニング次第ではnginxより
優れたパフォーマンスを得られる可能性もあります。
と、結局のところ確信にせまる特性を掴みきれてはいない状態ですが、、、
少しだけnginxの特性を理解できたと思います。(動的ページの比較検証はできてないけど。。。)

動的ページの検証はさておき、次回はデータベース周り、
特にNoSQL(Redis、HBase、Cassandraなど)関係のプロダクトについて比較検討してみようと思います。
噂のRedisの爆速っぷりを体感しようと思います。

お疲れ様です。守谷です。
技術系のナレッジを書く場所を忘れてしまったのでスタッフブログに書いてしまいます。

FLASHの新しいTextFieldクラスとしてTLFTextFieldなるクラスができました。
何が違うのかっていうと、いままで使っていたTextFieldより細かい設定ができます。
設定内容については割愛しますが、TextFieldよりはるかに便利になりました。
ですが、それゆえバグも多いようです。何点か紹介します。

・wordwrapをtrueにして、「text = “hoge”」と代入するとwordwrapが効かなくなる
TLFTextFieldではtextに直接代入するのは推奨していないようです。なぜかはわかりません。
対策方法としては、appendTextとreplaceTextを使用すると防げます。

・INPUTモードのときにtextalignをleft以外にするとINPUTクリック範囲がずれる
こちらのバグは対処方が見つかりませんでした。
Adobeのフォームで探しても「バグですねー」で終わってしまっています。。。
対処方をご存じの方、Vitalifyの守谷までご連絡ください！！

TLFTextFieldはググっても情報がほとんど出てこないので、世間ではあまり流行ってないようです。
先日FLASHプレイヤーの最新バージョンが公開されましたが細かいバグFIXも行ってほしいものです。