こんにちは。新規事業本部・金融グループの金（成奉）です。 　前回は高性能GIS専用のPostgreSQLデータベースサーバーの構築について話しましたが、今回はFastCGI基盤ウェブサーバーのPHPコンパイル構築、チューニング、設定などについてお話したいと思います。内容の範囲が広く、長文になっているため、３回に分けて投稿します。 　PHPは、ほとんどのモジュールがコンパイルされるような構成となっています。おまけにGIS関連のデータを扱うことのできるGEOSエクステンションの追加などにも触れています。 　ウェブサーバーは、ApacheとNginxになりますが、Nginxのコンパイル構築方法についても説明します。特にApacheでPHPを運用する際、最も効率よい構成はなんだろうと開発やインフラ担当の方はきっと悩んだことがあるかと思います。ApacheとPHPをどのような構成と設定で運用すれば、高いパフォーマンスで安定的にサーバーを運用できるかが、今回のメインテーマになります。またどのような構成が、PHPを使う上で一番パフォーマンスが出ているかのベンチマークについても触れます。 　なぜ、このようなお話をするかというと、サーバーのパフォーマンスと安定性は、ハードウェアも大事ですが、ミドルウェアやアプリケーションのコンパイル方法、設定、構成によって大きく左右されるからです。なので、今回は、PHPにかぎらず、チューニング方法、コンパイル方法、構成方法を中心に広範囲にわたってお話をしていきたいと思います。 環境及び制限等について 以下の作業や検証は、最新のCentOS6.5とLinuxのカーネル「2.6.32」バージョンで行った記録です。以下の操作と検証で同じ結果が出るという保証はありません。尚、ハードウェアの構成やネットワークの状況によって異なりますので、参考にしていただければ幸いです。検証環境は以下のようになります。 ・さくらVPS ・Centos6.5 ・3CPU/4G メモリ 作業場所とユーザー権限について mkdir /opt/src cd /opt/src 下のようなライブラリだけでコンパイルはできると思いますが、足りない場合は、追加インストールする必要があります。root権限で行います。 PHPバージョンについて 5.5.16 PHPの初期設定は、下のコンパイル・インストールの説明を参照してください。詳細については、バージョンによって内容が少し異なるため、以下のURLを参照しながら用途に合わせて設定します。 http://www.php.net/manual/ja/ini.core.php PHPのコンパイル構築について PHP実行バイナリは、コンパイル設定（./configure）によってスタティックまたはシェアド(Static/Shared)のバイナリを生成することができます。一般的にパフォーマンスはスタティックでコンパイルした方が良いと言われています。しかし、PHP本体にバグやセキュリティ脆弱性が発見された場合、すべてソースから再コンパイルする必要があります。シェアドでコンパイルした場合は、該当するライブラリー（Extension）のみコンパイルすることで対応できます。 PHP-5.5をビルドするとphp-cgi実行ファイルが生成されますが、今はデフォルトでFastCGI対応となっています。実行ファイルとしてphp-cli、php-fpmなどが生成されます。これらはコンパイル・オプションでサポートするSAPI（Server API）を追加してビルドすることで実行ファイルやモジュールのバイナリ（mod_phpなど）が異なります。PHPの歴史になりますが、初期バージョン（PHP/FI）も、FastCGI対応でビルドできるようになっていました。PHP3、PHP4になってからは、Apacheモジュール（mod_php）としての運用が主流となり、暫くの間、FastCGIがサポートされていなかった期間がありました。近年は、FastCGIでの運用が、世界の人々に支持され、新しくphp-fpmのSAPIが追加され、今後は、PHPはFastCGIでの運用が推奨されるようになっていくのではないかと考えています。 FastCGIでは、最初実行時に別のPHPプロセスを立ち上げてリクエストを待ち受ける状態になり、すべてのライブラリー（Extension）をメモリにロードし、リクエストを待ち受ける仕組みなので、コンパイル・オプションによるパフォーマンス差はそれほどありません。しかし、ApacheのMPM、PreforkモデルでApacheモジュール（mod_php）として運用する際、コンパイル・オプションのスタティックとシェアドとではパフォーマンスに差が大きく出ます。スタティック・オプションの方が10-30%程度早くなります。PHPをApacheのPreforkモデルで運用（mod_phpでの運用）する際は、アプリケーションで使用するPHPのExtensionを事前に決め、スタティック・オプションでコンパイル構築した環境での運用を強くお薦めします。FastCGIとして運用する場合は、コンパイル方法によるパフォーマンスの差はほとんどないため、柔軟にPHPのExtensionを、インストール・追加・変更できるシェアド・コンパイルの方がシステム運用上便利です。 ApacheのMPM（Multi-Proccessing Module）には、PreforkとWorkerがあります。ApacheのWorkerモデルではPHPモジュール（mod_php）は動作しません。ApacheサーバーをWorkerモデルで運用する際は、FastCGIで運用する必要があります。Nginxというウェブサーバーは、基本Workerモデルで動作します。このようにPHPをどのようなオプションでコンパイルするかの決定は、とても重要で、どのミドルウェアと構成するかによっても、システムの安定運用やパフォーマンスに大きく異なってきます。 PHPの運用構成について Windowsサーバでの運用 IIS/FastCGI+PHPの構成が基本です。CGIとしても運用できますが、パフォーマンスに問題があるため、推奨できません。WindowsバージョンのApacheとPHPのバイナリも配布されていていて最近はとても安定してきましたので、小規模であればWindowsでも十分運用できるようになりました。ただし、Windowsでは、Unix/Linuxのカーネルオプションのように設定の変更ができないため、ある程度のアクセス制限を超えてしまうとApacheエラーのトラブルはまだあります。Java系のTomcatサーバも似たような現象があります。 Windows環境のApacheまたはTomcatをイントラネットで運用する際、500人規模の社内環境であれば、それほど問題ないですが、それ以上の場合には、OSレベルで弾かれるケースがあるため、WindowsサーバーのIISに変更するか、Unix/Linux基盤にシステム構成を変更した方が安定的に運用できます。理由は、パフォーマンスが落ちたからといってメモリやハードウェアを増設しても、Windowsのカーネル設定を変更することができないため、それ以上のパフォーマンスが見込めないからです。 Unix/Linuxでの運用 様々な運用方法と構成があります。一般的には「apache+mod_php」で運用するケースが一番多いでしょう。Internet上に多くのPHP構築マニュアルがありますが、ApacheでPHPを「Apache+mod_fcgid+php」構成で運用するのは、、個人的な意見としては推奨できません。呼び出されたCGIをメモリに常駐させる仕組みでメモリを多く消費してしまいます。mod_fcigdをFastCGIのように扱っている内容もよく見かけますが、mod_fcigdとmod_fastcgiは全く別物です。PHPを運用する際の構成については、下のような基本構成があり、それぞれ設定が異なります。 ApacheでPHPをFastCGIで運用する時には、fastcgiライブラリとmod_fastcgi（fastcgiライブラリも含まれて配布されています）をコンパイルしてApacheに組み込む必要があります。yumのレポジトリからダウンロードできるところもあります。私は、デフォルトのyumレポジトリ以外は、コンパイルして構築する方法を好みます。その方が、依存性などによる原因不明のトラブルがなくなり、よりシステムを安定的に運用できます。 実は、FastCGI本家で提供されている仕様は、20年程前に公開されてから全く変っていません。仕組みは、Javaのサブレッドと同じ仕組みだと思えば、理解し易くなると思います。まずこのFastCGIからダウンロードできるライブラリーのソースと仕様を少し理解していれば、PHPをFastCGIで運用するために設定する際、迷いや様々なインターネットの構築関連情報に振り回されなくなります。FastCGIの本家サイトが殆ど活動していなくなってから、FastCGIの設定について多すぎる情報が返って難しくしている感じがします。 Apache以外にもPHPを様々なサーバで利用できます。近年注目を浴びているNginxをお薦めします。JavaをFastCGIとして動作させることもでき、ほとんどの言語がサポートされています。Nginxで運用する構成は、最近PHPのSAPIに追加されたphp-fpmを利用するのが一般的で安定的に運用できます。php-fpmは設定でSocketまたはTCP/IPで運用できますが、Socketの方が少し早いです。しかし、注意しなければならないのは、sysctl.conf（カーネルパラメータ）を正しく設定しないとソケットがクラッシュしてしまいます。キュー制限（net.core.somaxconn）やファイル制限等を正しく設定すればハイ・パフォーマンスのPHP運用環境が構築できます。スケーラビリティを考えているのであれば、TCP/IPで簡単に設定して運用することも可能です。他にリバースプロキシーとキャッシュサーバ構成でPHPを複数台Webサーバに負荷分散させることもできます。今回の説明では、分散構成の構築の説明までは詳しくは触れませんが、以下のような構成が考えられますので参考にして頂ければと思います。 参考サイト ・FastCGI本家 　 http://www.fastcgi.com/ ・Nginxのアーキテクチャー 　 http://www.aosabook.org/en/nginx.html オープン系のPHP運用の基本構成 01. Apache-Prefork + mod_php 02. Apache-Prefork + mod_fastcgi + php-cgi 03. Apache-Prefork + mod_fastcgi + php-fpm 04. Apache-Worker + suphp(cgi) + php-cgi 05. Apache-Worker + mod_fastcgi + php-cgi 06. Apache-Worker + mod_fastcgi + php-fpm 07. Apache-Worker + mod_fcgid + php-cgi 08. Apache-Worker + spawn-fcgi + mod_fastcgi + php-cgi 09. Nginx(Worker) + spawn-fcgi + php-cgi 10. Nginx(Worker) + php-fpm 注意１：5番のmod_fcigidは、一般的に言われているFastCGIとは異なります。 注意２：2番と3番の構成は推奨できません。ApacheのPHPモジュール（mod_php）とFastCGIを比較したベンチマークで、FastCGIが遅いと言っているサイトもありますが、この構成でベンチマークを行ったためです。 *注意３：php-fpmとspawn-fcgiには、FastCGIのプロセス管理機能があります。spawn-fcgiというのは、単体で各種言語のFastCGIを管理できるようにしたツールです。Unix/Linuxのプロセスというのは、それぞれの権限で実行されたりするため、セキュリティの意味でとても大事な機能になります。FastCGIライブラリーのソースで「fcgi_pm.c/fcgi_util.c」の内容を管理しやすくしたツールだと考えれば理解しやすくなります。他に「fcgi_buf.c/fcgi_protocol.c」というソースファイルもありますが、これらの内容を少し理解していれば、FastCGIのパフォーマンス・チューニングにとても役立ちます。ですので、php-fpmというのは、PHPのFastCGI（php-cgi）と、spawn-fcgi（管理機能なのユーティリティ）が一つにまとめられているバイナリであると考えれれば分かりやすくなります。同じ管理機能をPerl、RubyやPythonなど他のプログラミング言語で実装する際にも、spawn-fcgiを利用することでFastCGI環境での管理や運用がしやすいシステム構築ができます。つまりPHPをFastCGIで安全に運用する際に、FastCGIのプロセスを管理してくれるspawn-fcgiのようなツールとの組み合わせが必要であり、外部ツールを利用する時には「php-cgi + spawn-fcgi + mod_fastcgi」という構成になります。プロセスの管理機能等が、既に組み込まれている「php-fpm」だと「spawn-fcgi」は、不要になります。Apache環境では、「Apache-Worker + mod_fastcgi + php-fpm」という構成が、一番パフォーマンスのよい安定的に運用できるPHP環境になります。 推奨のPHP構成 ①PHP言語のみの環境 Nginx(Worker) + php-fpm Apache-Worker + mod_fastcgi + php-fpm ②PHP/Ruby/Perl/Pythonなど多言語運用環境 Nginx(Worker) + spawn-fcgi + php-cgi Apache-Worker + spawn-fcgi + mod_fastcgi + php-cgi 複数台の運用構成例 varnish：SSLに対応していないため、フロントエンドにpound（sslラッパー）を配置させます。 フロントエンドにnginxの代わりにhaproxyなどもよく使われます。 varnishとバックエンドの間にhaproxyを配置させる構成もあります。 HTTPのPOST、セッション、クッキーなどを正しく設定して構築する必要があります。 N: 数 1. pound <--> varnish <--> N * (apache + mod_php) 2. nginx <--> N * (apache + mod_php) 3. pound <--> varnish <--> N * (apache + mod_fastcgi + php-cgi) 4. nginx <--> N * (apache + mod_fastcgi + php-cgi) 5. pound <--> varnish <--> N * (apache + mod_fastcgi+php-fpm) 6. nginx <--> N * (apache + mod_fastcgi+php-fpm) 7. pound <--> varnish <--> N * (nginx + php-fpm) 9. nginx <--> N * (nginx + php-fpm) 負荷分散システム構成の整理 ①pound->varnish->haproxy->backend ②nginx->backend ③haproxy->backend ★まとめ★ ハイ・パフォーマンスのPHP運用環境構築のキーポイントは、コンパイルによるチューニング、カーネル・パラメータによるチューニング、キャッシング、負荷分散、PHP運用の基本構成、内部processingの高速化、内部networkの高速化などを総合的に適切に行うことにあります。より高速なデータアクセスと計算能力が必要とされる場合は、グリッドコンピューティング（Globusツールキット：標準ミドルウェア）構築という手段もありますが、リソースを無駄使いしないように開発現場でのデータベースやプログラミングの最適化も重要な要素となります。 長い説明になりましたが、結論は、PHPを利用する上で一番お薦めできる基本構成は以下の二つになります。 Nginx構成 　Nginx-Worker + php-fpm Apache構成 　Apache-Worker + mod_fastcgi + php-fpm FastCGI運用関連の設定について 　FastCGIはリクエストを待ち受けるプロセス数を、ダイナミック（dynamic）または固定（static）で設定できます。自分は、固定での設定を好みます。php-fpmは、このプロセスを管理するデーモンの役割をしています。「mod_fastcgi + php-cgi」という構成の場合も、FastCGIプロセス数の設定は、ダイナミックか固定で設定しますが、定期的にメンテナンスを行う必要がありました。このような管理機能をphp-fpmというSAPIが追加されサポートされるようになったことによって、無停止で安全にFastCGIのプロセスの自動管理ができるようになりました。 PHP関連のカーネル・パラメーター・チューニングについて 上でも触れたようにPHPをソケット設定のFastCGIで運用する場合は、カーネルパラメーターを変更する必要があります。関連するパラメータの確認方法は以下のコマンドで行います。近年の金融取引システムにでは、100万分の1秒単位でのパフォーマンスを競う「LowLatency」システムが要求されます。下のカーネルパラメータ設定は、ハイ・パフォーマンスのPHP環境構築のため、「Low Latency System」の設定を一部参考にしました。 Tunedでのチューニング 以下のツールをインストールしてコマンドを実行すると自動でチューニングしてくれるそうです。内容が分からない場合は、次のコマンドは実行しないでそのままスキップしてください。 インストール yum install -y tuned オプション確認 tuned-adm list Available profiles: - default - enterprise-storage - desktop-powersave - laptop-ac-powersave - laptop-battery-powersave - sap - spindown-disk - virtual-guest - server-powersave - throughput-performance - virtual-host - latency-performance チューニング実行（latency-performance） tuned-adm profile latency-performance GRUB構文追加設定によるチューニング 以下の内容については、カーネルとOSの知識がある方に限ります。OSが起動しなくなる危険もありますので、参考程度にしていただければ幸いです。100万分の１秒単位を競う金融機関の高速取引システム（Low latency Trading System）で効果を発揮する設定を参考にしたものです。今はリアルタイムカーネル等の応用もありますので、Unix/Linuxで新しい技術について興味のある方は、Ubuntuのlowlatencyカーネルを参考にしていただければと思います。GRUB構文の最後に以下の行を追加して設定します。以下の作業は、ご自身の責任と判断で行ってください。不安があるようでしたら、この設定はスキップしてください。 nosoftlockup nohz=off highres=off intel_idle.max_cstate=0 processor.max_cstate=0 cgroup_disable=memory nmi_watchdog=0 divider=4 nosoftlockup mce=ignore_ce GRUB構文の例 注意：以下の「kernel」の部分をそのままコピーして入れ替えるとOSが起動しなくなります。必ず、上の行を最後に追加するようにしてください。 view /etc/ title CentOS (2.6.32-431.17.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-431.17.1.el6.x86_64 ro root=UUID=035d9a21-778d-40cf-9ecb-d244d7b95781 rd_NO_LUKS rd_NO_MD SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=jp106 LANG=ja_JP.UTF-8 rd_NO_LVM rd_NO_DM quiet nomodeset clocksource=kvm-clock console=tty0 console=ttyS0,115200n8r crashkernel=auto nosoftlockup nohz=off highres=off intel_idle.max_cstate=0 processor.max_cstate=0 cgroup_disable=memory nmi_watchdog=0 divider=4 nosoftlockup mce=ignore_ce initrd /initramfs-2.6.32-431.17.1.el6.x86_64.img 各GRUB設定項目の説明については紙面上省略します。項目別に検索してご確認いただければと思います。 ulimit設定変更 サーバーの負荷テストを行う際にulimit設定関連のエラーで検証できないことが多いため、ulimitのデフォルト値を変更します。変更しておいた方が問題が少ないです。「/etc/security/limits.conf」やコマンドで設定出来ますが、再起動するとデフォルト値に戻ります。再起動時に自動で反映されるようにするには、以下のように追加します。 制限確認 ulimit -n -u -s 推奨設定反映 ulimit -n 65536 -u 16384 -s 32768 起動時の推奨設定反映 echo "ulimit -n 65536 -u 16384 -s 32768" >> /etc/sysconfig/init カーネルパラメータチューニング 以下の内容については、ご自身の責任と判断で行ってください。設定は、「Low latency Trading System」の設定を参考にしています。必ず設定内容を確認し、ご自分のシステムに合わせ、各項目の内容を理解した上で変更を行ってください。以下の設定反映によるシステムの停止及びトラブル等に対しての責任は負いかねます。以下の設定は、IPV6をを無効にし、IPV4のみを利用している環境の設定になります。 セフォマ計算とメモリのLatency問題関連設定適用 以下のcatコマンドで作成されたシェルを実行し、出力される内容をカーネルパラメータのセフォマとして設定します。 ファイアウォール設定でリバーシプロキシーサーバーでの利用または大規模サイトの場合、メモリに合わせて「netfilter」のCONNTRACK_MAXのチューニングを行う必要があります。 CONNTRACK_MAXチューニング 参照 http://wiki.khnet.info/index.php/Conntrack_tuning OS_BIT=64 RAMSIZE=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1` HASHSIZE=`echo "scale=0; ($RAMSIZE * 1024) / 131072 / ($OS_BIT / 32)" | bc -l` CONNTRACK_MAX = `echo "scale=0; $HASHSIZE * 8" | bc -l` チューニング値計算と一部設定反映 計算された値をカーネルパラメータ設定の内容を確認して修正します。 cd /opt cat > "kernel_optimize.sh" <<'EOF' #!/bin/sh SHARED_BUFFER_RATIO=0.25 OPTIMAL_SHMMNI=8192 OS_BIT=64 echo "kernel.shmmni=$OPTIMAL_SHMMNI" MAX_MEM=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1` OS_PAGE_SIZE=`getconf PAGE_SIZE` OPTIMAL_SHMMAX=`echo "scale=0; (8192 + 208) * (($MAX_MEM * 1024) / $OS_PAGE_SIZE) * $SHARED_BUFFER_RATIO" | bc -l | cut -d'.' -f1`0 echo kernel.shmmax=$OPTIMAL_SHMMAX OPTIMAL_SHMALL=`echo "scale=0; ($OPTIMAL_SHMMAX / $OS_PAGE_SIZE) * ($OPTIMAL_SHMMNI / 16)" | bc -l | cut -d'.' -f1` echo kernel.shmall=$OPTIMAL_SHMALL if [ $MAX_MEM -gt 8192 ]; then #latency issues configuration echo 2 > /proc/sys/vm/dirty_ratio echo 1 > /proc/sys/vm/dirty_background_ratio else echo 10 > /proc/sys/vm/dirty_ratio echo 5 > /proc/sys/vm/dirty_background_ratio fi #netfilter設定 HASHSIZE=`echo "scale=0; ($MAX_MEM * 1024) / 131072 / ($OS_BIT / 32)" | bc -l` CONNTRACK_MAX=`echo "scale=0; $HASHSIZE * 8" | bc -l` echo "net.netfilter.nf_conntrack_max=$CONNTRACK_MAX" echo "options nf_conntrack hashsize=$HASHSIZE" >/etc/modprobe.d/nf_conntrack.conf EOF #既存カーネルパラメータファイルのバックアップ cp /etc/sysctl.conf /etc/sysctl.conf_backup #上記設定を反映 sh kernel_optimize.sh #カーネルパラメータの設定 #下の内容は、各項目の内容を確認し、上で実行して計算された数値に変更してからcatコマンドを実行してください。修正は★マークが付いている箇所になるます。 cat > "/etc/sysctl.conf" <<'EOF' ### カーネルパラメータ設定 # SysRq設定 kernel.sysrq=0 # スケジューラの設定 kernel.sched_nr_migrate=12 # コアダンプファイル名の設定 kernel.core_uses_pid=1 ###### チューニング設定 ###### # カーネル・メッセージキュー最大サイズ kernel.msgmnb=65536 # カーネル・メッセージ最大サイズ kernel.msgmax=65536 # セマフォチューニング計算 #SHARED_BUFFER_RATIO=0.25 #OPTIMAL_SHMMNI=8192 #echo "kernel.shmmni = $OPTIMAL_SHMMNI" #MAX_MEM=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1` #OS_PAGE_SIZE=`getconf PAGE_SIZE` #OPTIMAL_SHMMAX=`echo "scale=0; (8192 + 208) * (($MAX_MEM * 1024) / $OS_PAGE_SIZE) * $SHARED_BUFFER_RATIO" | bc -l | cut -d'.' -f1`0 #echo kernel.shmmax=$OPTIMAL_SHMMAX #OPTIMAL_SHMALL=`echo "scale=0; ($OPTIMAL_SHMMAX / $OS_PAGE_SIZE)*(OPTIMAL_SHMMNI / 16)" | bc -l | cut -d'.' -f1` #echo kernel.shmall=$OPTIMAL_SHMALL # デフォルトの設定内容について #kernel.shmmni = 4092 #kernel.shmmax = 68719476736 #kernel.shmall = 4294967296 # カーネルヘッダーソースの内容 #define SHMMAX 0x2000000 /* max shared seg size (bytes) */ #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ #define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) #define SHMSEG SHMMNI /* max shared segs per process */ ## SHMMAX SHMMNI 68719476736 4096 ## SHMALL = ----------- * ---------- = ------------- * ------ = 4294967296 ## PAGE_SIZE 16 4096 16 #以下4Gメモリ設定の例 #セマフォチューニング計算の内容を下で設定します。 #１プロセスごとの共有メモリの最小サイズ (byte) kernel.shmmni=8192 #システム全体の共有メモリ・ページ最大数 #★下はセマフォチューニング計算の内容に合わせて修正します。 kernel.shmmax=20593713000 #共有メモリ・セグメントのバイト数上限 #★下はセマフォチューニング計算の内容に合わせて修正します。 kernel.shmall=2574213632 #パラメータ順の内容 #semmsl semmns semopm semmni #セマフォIDごとのセマフォの数、システム全体のセマフォの数、一度に実施できるセマフォ操作の数、セマフォIDの最大値 #OracleDB(semopm)は100以上設定必須 #以下の設定はメモリデータベースのALTIBASEチューニング参考。 kernel.sem=2000 32000 512 5029 # ファイルオープン・IO関連 #Oracle/MySQLチューニング参照 fs.aio-max-nr=1048576 fs.file-max=6815744 # メモリチューニング vm.swappiness=20 vm.overcommit_ratio=99 vm.overcommit_memory=2 #IPV6無効化 net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 # パケット転送無効 net.ipv4.conf.all.forwarding=0 net.ipv4.conf.default.forwarding=0 # listenキュー制限設定 net.core.somaxconn=262144 # ICMPエラーメッセージを無視 net.ipv4.icmp_ignore_bogus_error_responses=1 # 偽装・不正パケット：リダイレクトログ記録 net.ipv4.conf.all.log_martians=1 net.ipv4.conf.default.log_martians=1 # スプーフィング対策 送信元IP偽装防止 net.ipv4.conf.all.rp_filter=1 # L3 環境のジャンボフレームで通信する場合 #net.ipv4.tcp_mtu_probing=1 # ネットワークリソース関連設定 net.ipv4.tcp_fin_timeout=15 net.ipv4.tcp_sack=1 net.ipv4.tcp_fack=1 net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=3 net.ipv4.tcp_keepalive_probes=3 # RFC1337に準拠（Protect Against TCP Time-Wait） net.ipv4.tcp_rfc1337=1 # ソケットの高速リサイクル（DOS攻撃防止） net.ipv4.tcp_max_tw_buckets=1440000 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1 # TCP SYN Flood攻撃対策 net.ipv4.tcp_syncookies=1 # RFC1323 # TCPウィンドウスケーリング有効（64KByte以上のバッファー） net.ipv4.tcp_timestamps=0 net.ipv4.tcp_window_scaling=1 # ブロードキャストアドレス宛pingには無応答 # ※Smurf攻撃対策 net.ipv4.icmp_echo_ignore_broadcasts=1 # ICMP Redirectパケットを拒否 net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.default.accept_redirects=0 # Source Routedパケットは拒否 net.ipv4.conf.all.accept_source_route=0 net.ipv4.conf.default.accept_source_route=0 # Kdump使用設定 net.ipv4.conf.all.force_igmp_version=2 net.ipv4.conf.default.force_igmp_version=2 kernel.unknown_nmi_panic=1 kernel.panic_on_unrecovered_nmi=1 kernel.panic_on_io_nmi=1 # ARP応答なし設定 net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.default.arp_ignore=1 # スプーフィング対策（送信元IP偽装防止） net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.default.rp_filter=1 #クライアントが増えた時のトラブル回避策 net.ipv4.neigh.default.gc_thresh1=1024 net.ipv4.neigh.default.gc_thresh2=2048 net.ipv4.neigh.default.gc_thresh3=4096 # NICチューニング設定 # ネットワークバッファーは16Mで十分 # 4MBまではカーネルで自動調整 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.core.rmem_default=16777216 net.core.wmem_default=16777216 net.core.optmem_max=16777216 net.core.netdev_max_backlog=250000 net.ipv4.tcp_mem=4096 87380 16777216 net.ipv4.tcp_rmem=4096 87380 16777216 net.ipv4.tcp_wmem=4096 87380 16777216 net.ipv4.tcp_max_orphans=16777216 net.ipv4.tcp_max_syn_backlog=65535 net.ipv4.tcp_low_latency=1 net.ipv4.tcp_no_metrics_save=1 net.ipv4.tcp_congestion_control=htcp net.ipv4.neigh.default.unres_qlen=100 net.ipv4.neigh.lo.unres_qlen=100 net.ipv4.neigh.eth0.unres_qlen=100 net.ipv4.neigh.eth1.unres_qlen=100 net.ipv4.route.flush=1 # 高負荷のサーバ/NAT/プロキシーサーバー向けのエラー対策設定 # iptablesの再起動必要、iptablesが動作していない環境では設定する必要はありません。 #net.netfilter.nf_conntrack_max 計算 #OS_BIT=64 #RAMSIZE=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1` #HASHSIZE=`echo "scale=0; ($RAMSIZE * 1024) / 131072 / ($OS_BIT / 32)" | bc -l` #CONNTRACK_MAX = `echo "scale=0; $HASHSIZE * 8" | bc -l` #echo net.netfilter.nf_conntrack_max=$CONNTRACK_MAX #4Gメモリ設定例 #★下はメモリに合わせて修正します。 #iptablesが起動していない場合は、反映時にエラーになります。 net.netfilter.nf_conntrack_max=122576 net.netfilter.nf_conntrack_generic_timeout=10 net.netfilter.nf_conntrack_tcp_timeout_established=2160 net.netfilter.nf_conntrack_tcp_timeout_close=8 net.netfilter.nf_conntrack_tcp_timeout_close_wait=10 net.netfilter.nf_conntrack_tcp_timeout_time_wait=10 net.netfilter.nf_conntrack_tcp_timeout_fin_wait=10 net.netfilter.nf_conntrack_tcp_timeout_syn_sent=10 net.netfilter.nf_conntrack_tcp_timeout_syn_recv=10 net.netfilter.nf_conntrack_tcp_timeout_max_retrans=30 net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=30 net.netfilter.nf_conntrack_tcp_loose=1 net.netfilter.nf_conntrack_tcp_be_liberal=0 net.netfilter.nf_conntrack_tcp_max_retrans=3 net.netfilter.nf_conntrack_acct=1 net.netfilter.nf_conntrack_checksum=1 net.netfilter.nf_conntrack_log_invalid=0 net.netfilter.nf_conntrack_expect_max=256 EOF 今回は以上になります。 次回は、PHP構築設定、MySQL設定、Redis設定などについてお話します。 長文を読んで頂き、ありがとうございました。

Apple原理主義者の大坪です。 題名を読んで「なんのことだ」と思った方。あなた方は正しい。しかし自分に嘘はつけない。私にはこの題名以外思いつかない。つまるところは先日発表されたこれですよ。 こういう時は（どういう時だ）やはり冷静にならなくてはならない。自分の状況をできる限り客観的に見つめ、その上で落ち着いてとるべき行動を考えましょう。私が何を持っているか。 ・ストレージの残りが常に10GBを切っている2011年購入のMac Book Air ・ガラスにヒビがはいったiPad 2 ・バッテリが８時間持たなくなってきたiPhone 4S ・常に火の車の家計 Mac Book Air, iPhone,iPadそのどれもが早急に更新を必要としていながら資金は限られている。というか客観的に考えれば無い。この状況において、Apple Watchに心を動かすのは全く持って正しくない。そもそもiPhone4SではApple Watchは使えない。ええいこうなったらiPhone6 Plusを買ってしまえ！と叫ぶなど正気の沙汰とは思えません。まったくどういうつもりなのか。 Apple Watchは厚すぎるし、丸くないし、未だバッテリ持続時間が発表されないことからも長く持つとは思えない。初代iPadが辿った運命を顧みれば、新しいカテゴリの初物に手をだすのは賢明ではないし、そもそも私は過去数十年腕時計を腕につけたことがない。まったく馬鹿げている。証明終わり。さあ、仕事に戻ろう。 と理解はできていても、ふと気がつけばAppleのサイトでApple Watchの動画など見返している。ああ、これつけたらかっこいいかもしれないなあ、自分の腕できれいな蝶蝶がひらひらするんだよ...しかし次の瞬間現実が肩を叩く。動画のお兄さん、お姉さんがかっこいいのは、Apple Watchのためではないのだよ。自分の姿形を鏡で見てご覧、と。 かくのごとく現実と感情の間で揺れ動き続きため息をつくのはあまり楽しいことではない。 しかーし 人生は捨てたものではない。救いの手はすぐそこまできています。Origamiが昨日 1.4にバージョンアップ されました。そしてApple Watchがサポートされたのです。一介のソフトウェア開発者たるもの、まずその上でソフトウェアを開発し、その上で個人的に購入するか否か悩むべきなのです。 などという破綻した理屈をこねまわしつつまず触ってみましょう。 あれこれ参照 して、Origami1.4をインストールしましょう。すでにOrigamiをインストールした人であれば、この ページ に行って、「３」のリンクをクリック、ダウンロードされたファイルをダブルクリックし、インストーラーの指示に従えばOKです。 と簡単に書きましたが、Avocadoをインストールしていると、エラーページに飛びます（親切だなあ）指示に従って自分のアカウント下にあるLibraryフォルダから、Graphicsフォルダをデスクトップに移動させる。そのあとインストーラーを再度走らせるとOrigami1.4がインストールされます。 さて その後Quartz Composerを立ち上げます。"File"メニューを選ぶと一番上に"New Origami File"なる項目があることに気がつきます。これを選ぶといきなりここまでできます。 いままでお約束のように「ここまで作りましょう」と書いていた作業がメニュー選ぶだけで完成。「ああ、なんて簡単なの！」と喜びの涙を流しながらViewer中のiPhoneをいじってもいいのですが、やはりここはあれでしょう。一番左の"Phone Dimensions"パッチを選び、Patch InspectorもしくはParametersを選択し、今"iPhone"になっている"Phone" の項目を"Apple Watch"にしましょう。どきどきしながらViewerを見ると... なんと！Apple Watchが手に入ったではありませんか。などとわざとらしく言ったところで心に感じる薄ら寒さは隠せない。しかし現実を認めたら負けです。 ちなみにOrigami1.3からこうしたパラメータ変更はもっと簡単にできるようになっています。"Phone Dimensions"パッチの、Phoneの横をダブルクリックしましょう。 するとこんなメニューが開きます。ここからApple Watchを選べば終了。簡単ですね。 今回追加された機能を利用した サンプル も既に公開されています。しかしこのサンプル結構力作なので、読み解くのは簡単ではない。ここは「とにかくやってみるか」と思えるくらい簡単なサンプルを作ってみましょう。 Layer Groupをダブルクリックして中に入り、以下のパッチを追加します。(Patch Libraryから検索しましょう） System Time Date Formatter Text Layer やりたいことは、時間のデータをどこからか取ってきて、適当にフォーマットし画面上にText Layerで表示する、というものです。追加したパッチを以下のようにつなぎましょう。そしてどきどきしながらViewerをみるのです。 やったー。これがApple Watchだー（棒読み） 来年のいつになるかわからない発売までに、Appleがどんな「時計盤」を出してくるだろうか。今から胸がわくわくします。そしてこんなデザインは決してでてこないことに関しても自信がある。 とはいえ、時間を知るのはWatchの基本中の基本。少しだけこのプログラムをいじってみましょう。 Date Formatterを選び、Patch Inspectorを開きます。でもってSettingをこんなふうにセットしましょう。さらにはText LayerのFont Sizeを適当に選べば... まああれですね。少しはマシですが「だから何？」という声は頭の中から消えない。いや、ここで負けてはいけない。私が何かの講師だったら 「これを使ってあなたの考えるWatchを作ってください」 とやるところです。そうやって他人が作った様々な時計盤のデザインを眺めながらぼんやりと考えるのです。いつの日かOrigamiじゃない本物が手に入るといいなあ,,,と。 今回のプログラムは Github に置きました。

はじめまして。プロダクト開発部の冨田と申します。 『Junkup』というニュースリーダーサービスのアルファ版をローンチしました。 http://www.junkup.net/ 『Junkup』とは WEB型のニュースリーダーで下記のような特徴があります。 タイトルが似ているサイトを「関連記事」として名寄せする Twitter、はてなブックマーク、Pocketなどへ同時にシェア出来る レスポンシブなのでPC、タブレット、スマホから利用できる 『Junkup』の生い立ち 私はGoogle Readerのヘビーユーザーで1日に1000～2000件のニュースに目を通していました。 しかし、2013年3月頃に閉鎖されるという衝撃の発表が行われ、 FeedlyやGunosyやSmartNewsなど、どこに乗り換えようか悩んでいました。 ただ、どれを使ってもいまいちしっくり来ませんでした。 キュレーション系のニュースサービスへの不満 紙幅が限られているので欲しいニュースが手に入るとは限らない チャンネルを追加すると似たようなニュースで溢れる 単純なRSSリーダーへの不満 色々なニュースソースを登録すると似たようなニュースで溢れる これらの不満な点を解消すべく『クリエイターの日』という業務時間の10%を使い、 合宿形式で研究開発する制度を利用して自分好みのニュースリーダーを開発し始めました。 『Junkup』ローンチへ 開発を始めて数カ月後、新規事業を提案できる社内制度「Switch」の 新規サービス部門へ応募してみないかと声がかかりました。 採択されると期限つきですが予算がつきます。 期限内にKPIを達成できないと終了となります。 KPIを達成すると事業化できるかも！？ サービス内容をブラッシュアップし経営陣に対しプレゼンしたところ採択され、 2014年4月から9月まで予算がつきました。 予算はAWSの費用やサイト開発費用に当てており、 2014年7月にローンチし現在に至っております。 期限内にローンチしKPIを達成しなければならないため、 最小限の機能しかまだありません。 まずは、KPI達成に向けて9月末まで全力でブラッシュアップしていきます！ ご意見、ご要望はjunkup@next-group.jpまでご連絡ください。 クリエイターの日 http://creators.next-group.jp/ 新規事業提案制度「Switch」 http://recruit.next-group.jp/keyword/#sec02-02

Apple原理主義者の大坪です。 最近 「UXとUIは何が違うのか」 といった議論を時々みかけます。それぞれの言葉について、合意のとれた定義がないから正解はないのですが、この問題に対してのあれこれの議論は時として興味深いものになります。 というわけで昨日見つけた記事について。 記事の題名は "Recruiting a Designer? Here's What You Should Know" 「デザイナーを探している人が知っておくべきこと」 デザイナーという言葉はとても幅広いわけです。車などのプロダクトデザインもあれば雑誌のデザインもあり、web、アプリなどのデザインもある。この記事ではweb、アプリなどを対象にしたTech Industory(日本語ではIT業界なのですかね）での様々なデザイナーの役割について書かかれています。 記事中それぞれの「デザイナー」が使っているツールとかもでているのですが、如何せん疲れたエンジニアにはよくわからない。というわけで、大胆に省略して自分で理解できた、と思ったところだけを訳します。 UX デザイナー： 主に考えること：ユーザは製品を使ってどう感じるか？ お気に入りのツール：Photoshop, Sketch, Illustrator, Fireworks, InVision 例えばこんなことを言う：ユーザが登録を終了したら、「ありがとう」のページを出そう UIデザイナー 主に考えること：個々のページはどのようにユーザと視覚的にコミュニケーションするか？ お気に入りのツール：Photoshop, Sketch, Illustrator, Fireworks 例えばこんなことを言う：ログイン/新規登録のリンクはページの右上におくべきだ ビジュアルデザイナー（グラフィックデザイナー） 主に考えること：ピクセルと格闘して、美しいアイコン、コントロール、それにフォントを作る お気に入りのツール：Photoshop, Sketch（訳注：あれ、Illustratorは？） 例えばこんなことを言う：カーニングをオフにして、ボタンは１ピクセル左にすべき インタラクションデザイナー（モーションデザイナー） 主に考えること：ユーザが触った後に、画面はどう動くべきか？ お気に入りのツール：AfterEffects, Core Composer, Flash, Origami 例えばこんなことを言う：メニューは左端からease-inで800msecで現れるようにしよう UXリサーチャー（ユーザリサーチャー） 主に考えること：製品のユーザは誰なのか？そして何を望んでいるのか？ お気に入りのツール：Mic, Paper, Docs 例えばこんなことを言う：リサーチの結果、典型的なユーザは.. フロント開発者（UI開発者） 主に考えること：製品のインタフェースを実装する お気に入りのツール：CSS, HTML, JavaScript 例えばこんなことを言う：960px 12カラムの グリッドシステム を使ってるよ プロダクトデザイナー 会社によって定義が異なり、これまでに記述した内容のどれでもあり、どれも含みうる。 ーーー この記事を転載した こちらのページ ではコメント欄でいろいろな議論がなされています。 多くの指摘は 「役割は分けられるにしても結局全部できなきゃだめだよね」 というものです。一番極端な意見では In the end, an experienced senior designer should be able to do all the roles above. They should also understand how HTML/CSS (front-end) and various programming environments (back-end) effect their designs; capabilities/requirements/limitations. via: UI, UX: Who Does What? A Designer's Guide To The Tech Industry | Co.Design | business + design 経験をつんだシニアデザイナーは上記の役割全部をこなす必要がある。HTML/CSS（フロントエンド）からバックエンドの環境がどのようにデザイン上での機能/要求/制約に関係するか理解しなくてはならない。 なるほど、、とは思いますがそれができれば苦労はしない、と言いたくもなる。 加えてあれですよ。Apple原理主義者としては 「HTML/CSSだけでは足らん。iOSで何ができるか、できないか理解してもらわなくては」 と言いたくもなるわけですが、そうするとここに書かれた「シニアデザイナー」はますます非現実的なものになっていく。 というわけで結局 「専門性を持った上で、専門が異なる人ときちんと会話できることが必要だよね」 ということになるのかな、と思うわけです。別の記事から引用します。 At Etsy, like many companies these days, product designers are responsible for staying active and involved throughout the entire development process. From product definition to user flows to wireframes to visual design to, yes, writing and deploying their own HTML and CSS, designers are tasked with staying involved from start to finish. via: Why Designers Really Should Learn to Code Etsyでは昨今多くの企業でなされているように、プロダクトデザイナーは開発の全てのプロセスに関わり、そして責任を持つ。製品の定義からユーザフロー、ワイヤフレーム、ビジュアルデザイン、そしてHTML,CSSの作成まで行う。デザイナーは開発の最初から最後まで関わることになる。 なぜ Etsy ではこういう方法をとっているのか。例えばデザイナーが自分でコーディングまで行うとするとエンジニアの 「そんなの無理」 という「言い訳」に悩まされる必要がなくなる。つまりデザイナーが独立して思うがままに開発を進められる、、、からではない、とこの文章は続きます。 However, we expect the same of our engineers and product managers - we push everyone on a team to be involved in every step of creating great products. 中略 What’s been most interesting to me about requiring designers to work in code is that, instead of making our designers more independent, working in code has actually created a deeper collaboration with their engineering partners. via: Why Designers Really Should Learn to Code しかしながら、エンジニア、プロダクトマネージャーも同じようにすることが期待される。つまりチームの全員が製品開発の全てのステップに関わるようにしているのだ。 （中略） デザイナーがコードを書くことの一番興味深い点は、それによってデザイナーがより独立する、ということではなく、コードを書くことによって、エンジニア達とよりよく共同作業できるという点にある。 お互い共同しましょう、と言っているだけではなく、実際に協力する相手の作業を担当してこそお互いの立場が理解できる。 That’s what collaboration really is - crossing boundaries and finding common ground so that we can work together and share a mutual understanding. via: Why Designers Really Should Learn to Code お互いの境界線を越え、一緒に働ける共通の場所を見いだし、互いに理解し合う。それこそが真の協力というものだ。 あれですよ。私のような疲れたエンジニアが自分で製品のUIをデザインしたとする。それに対してデザイナーさんが出してきた案をみて 「をを、こんなに違う。当たり前とはいえこの差異はなんなのか」 と驚愕する。この驚愕はきっと無駄ではない、と信じたい。 と無理矢理前向きにまとめたところで今回はおしまい。

こんにちは。7月からAndroidチームに配属されました衛藤です。 先月の6月25, 26日に、Google最大のイベント"Google I/O 2014"が開催されました。 私自身は参加していないのですが、YouTubeでの配信を見ていたところ、 Notificationについての話がちらほらと出ていましたので、その辺りを書いてみたいと思います。 Notificationについて スマホユーザにはおなじみのNotificationですが、Googleによると下記のように説明されています。(そのままですが・・・) A notification is a message you can display to the user outside of your application's normal UI. iOSなんかでは、ロック画面に通知が表示され、そこからダイレクトにアプリに飛べたりするのですが、 Androidではそれ専用のWidgetアプリくらいしかありませんでした。 現状だと、画面の上からスワイプして通知画面を引き出して来ないと通知が分かりません。 この通知ですが、ユーザにアプリを開いてもらうための強力なツールになります。 プロモーション、そして継続利用 アプリをリリースした後に重要になってくることが二つあります。 1. プロモーション 2. アプリの継続利用 プロモーションでは、広告やプレスリリース等でアプリをより多くの人に知ってもらいます。TwitterのRT拡散も結構効果あり。 より多くのユーザにアプリをストアから落としてもらうのは一番重要ですが、アプリの継続利用も意識する必要があります。そこで継続利用に欠かせないNotificationを活用しより多くのユーザに長く使って頂く。開発者にとっても非常にうれしいことですね。 今回のGoogle I/Oでは、Notificationが強化された、という説明がいろんなセッションで出ていました。 仕組みというよりはビジュアル面がメインのテーマでしたが、ようやくロックスクリーンにも表示できるようになりました。 以下、セッションから一部抜粋しながらまとめていきます。 Google I/O 2014 - Keynote から Android Lセクション(25:00前後) 人々がポケットから端末を取り出しチェックする一番のトリガーは・・・Notiifcationである。それも1日何十回も。 Android LではNotificationが強化され、ロックスクリーンから直接アプリへ飛ぶことができる。 アプリを使っている途中でも、上からNotificationが表示されるようになる。邪魔な場合は横にスワイプすればよい。 Android Wearセクション(49:00前後) Androidユーザは1日平均125回、Android端末を取り出している。そのため、Android Wearは素早く、必要な情報が一目でわかるように設計されている。 Notificationをバイブレーションとともに知らせることで、重要なメッセージを逃すことなく確認できる。 AndroidスマートフォンとAndroid Wearは通知も連携できる。 Google I/O 2014 - What's New In Android から Notifications(21:50前後) Material Designに沿った見た目になった。 新しいテンプレート"Media Style"が追加された。 Android Lより前のバージョンだと4つの通知を確認するまで4つのステップが必要であった。 端末が鳴る/バイブレーションを確認する 端末の電源ボタンを入れる ロック画面を解除する 上から通知画面をスワイプしてくる Android Lからは・・・ 端末が鳴る、電源ボタンを押す、それだけ。 プライバシー設定により、アプリがどんな内容で通知すべきか制御できる。 プライバシー設定のバリエーション(.setVisibility(Notification.VISIBLITY_***)) VISIBILITY_PUBLIC : 内容は誰でも見ることができる。 VISIBILITY_PRIVATE : 内容は本人だけがロック解除後に見ることができる。 VISIBILITY_SECRET : アイコン含み何も表示されない。 背景の色も独自に設定できる(.setColor(***)) 一応サンプルコード Android 4.4まではステータスバーへの通知になります。 Notification.BuilderはAPIレベル11からのものなので、それ未満の場合はSupportPackageに入っているNotificatoinCompat.Builderを使う必要があります。 Intent intent = new Intent(this, MyActivity.class); PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, intent, 0); NotificationCompat.Builder builder = new NotificationCompat.Builder(getApplicationContext()); builder.setContentIntent(pendingIntent); builder.setTicker("Ticker"); builder.setContentTitle("Content Title"); builder.setContentText("Content Text"); builder.setSmallIcon(R.drawable.ic_launcher); NotificationManager mgr = (NotificationManager) getSystemService(NOTIFICATION_SERVICE); mgr.notify(0, builder.build()); 今後、Android Lが正式に出るとロック画面への表示が出来るようになります。 なお、下記のようにaddAction()によって通知領域内にボタンを6個くらいまで設置することができるようです。 音楽アプリ系でよく使われそうです。 .addAction(R.drawable.skip_previous, "Previous track", prevIntent) .addAction(R.drawable.fast_reverse, "Rewind", rewIntent) .addAction(R.drawable.puase, "Pause", pauseIntent) .addAction(R.drawable.fast_forward, "Fast forward", ffIntent) .addAction(R.drawable.skip_next, "Next track", nextIntent) .setColor(R.color.app_color) .setStyle(new Notification.MediaStyle() .setShowActionsInCompactView(2) .setMediaToken(mediaToken) まとめ Android Lからロックスクリーンに通知機能が追加になるとともに、Android Wearとの連携も可能になります。 また、現行と同じくNotificationのスタイルもBigPicture/BigText/Inboxなどが選べるため、表現の仕方によっては、アプリの継続利用率も上がってくるのではと思います。 特に何かを探す系のアプリなんかでは、PUSH通知と組み合わせておすすめ情報の通知(画像と共に)、在庫などに合わせて「残り○○ですよ！」みたいな通知、スケジューラとの連動など、アプリを有効活用してもらう仕組みの幅が広がりそうですね。 色やアイコンも自由なので、コーポレートカラーやアプリのテーマカラー、アイコン等を積極的に取り入れ、自社のイメージを前面に押し出していくこともブランディングの一つになりそうです。 ちなみに、通知は時間帯も非常に重要です。 自分で使っていれば分かると思いますが、一番使う時間帯は・・・ 寝る前など家にいるとき 通勤電車 昼休憩など http://research.rakuten.co.jp/report/20120524/ 楽天のスマートフォンの使用実態に関する調査より 一番スマホが見られている時間帯に、「アプリを見たい！」と思わせる通知を見せる、これだけでも効果は違うのでは、と思います。 以前からNotificationは重要だといわれてきましたが、今回Android Wearとも連動し 今後Notificationはアプリにとってさらに強力なツールになっていく、そう思ったテーマでした。 最後まで読んでいただき、ありがとうございました！

こんにちは。クリエイターの日運営委員の松尾です。 前回 に引き続き、1Q後半に活動する5チームと クリエイターの日の報告会について紹介します！ 社内で使うツールのデザインに取り組んでいる様子です。 使いやすいデザインにはとことんこだわります。 こちらのチームのメンバーは全員が新卒入社。 サービスのリリースに向けて開発のスピードは上がってます。 今年新卒として入社したばかりのエンジニアも頑張ってます。 手の動きで何かを操作しようとしている様子…？ 不動産会社様に使って頂くサービスを作成中。 エンドユーザ、クライアント、社内など、 クリエイターの日に作るプロダクトのターゲットは様々です。 クリエイターの日のサイト に新しいコンテンツを制作中。 多くの方に制度の良さを伝えるべく、コンテンツを追加していきます。 今回も多くのクリエイターが活動に参加してくれました。 また、活動期間の終了後には、社内で報告の場を設けました。 「この部分はどういう構成で動いているのか」 「業務に応用できそうな部分はあるか」 「サービスとしていつリリースするのか」 などなど、様々な質問が飛び交う報告会です。 ネクストのものづくりをより活発にするべく 今後もクリエイターの日を盛り上げていきます。

Apple原理主義者の大坪です。 さて、Google I/O 2014シリーズの第３弾は、デザインに関して私が理解でき（たような気がして）かつ印象的だった点について。 今回Googleは新しいデザイン言語としてMaterial Designを発表しました。キーノートで 「われわれは、ピクセルが色だけでなく奥行きも持っていたらどうなるか想像してみた。また状況に応じてテクスチャーを変えられるような素材があったらどうだろうと考えてみた。これがMaterial Designを開発するきっかけになった」とAndroid OSのユーザー体験の責任者、Matias Durateは語った。 via: Google I/O：デザインでもAppleに対抗へ―ユニバーサル・デザイン言語、Material Design発表 – Techcrunch この発表があったとき、そしてその背景にながれたアニメーションを見たNerdの90%は 「をを、Googleはとうとう画面のピクセルが物理的に変化するディスプレイを開発したのか！」 と熱狂したに違いない。しかし実際に発表されたのは、Material Designでした。がっかり（＜これだから頭のおかしいエンジニアは。。） ━━━ 私が興味深いと思ったのはGoogleのMaterial DesignとiOS７で"Depth"：「深さ」という共通の言葉が強調されていていたこと。そしてその実現方法が異なっていたこと。２次元でしかない画面上でどうやったらユーザに奥行きがあることをわかってもらえるか？ Google Designのサイト にいってマウスを動かせばすぐ気が付きますが、マウスの下にあるタイル（少なくともその形状をしたもの）が少し浮き上がったように見える。これは周囲との間の陰影関係を制御しているように見えます。 対してiOSではぼかしを含んだ半透明の画面、またはデバイスの動きに応じて背景が少しずれるパララックス効果を使うことで、画面間に奥行きの差があることを示しました。 実現方法の差異はさておき、デモされる画面を見ていると、色の連続的な変化、モーフィングなど「動き」がますます重要になっていることが見て取れます。このGoogle I/Oでも" Material Design:Motion "なるセッションがあり、「動き」がUIの中でどれだけ重要であるかが語られていました。特にこのセッションでは「振付（コリオグラフ）」なる言葉が使われているのには驚きました。そのうち画面設計でもコリオグラファー：振付師という言葉が使われるかもしれません。 画面が非連続的に変化するのではなく、連続的に変化することで、何が起こっているかをユーザに理解させる。こうした点においてiOS7とMaterial Designは共通している。 （ここに「であるからして、Origamiのようなデザインツールの重要性がますます..」という いつもの言説 が数十行あると思ってください） しかしながら違いもあります。私の意見ではAppleよりもGoogleの方が「異なるデバイス間での共通デザイン」という要素を強調しているように思える。Mac OS XもYosemiteでiOSのデザインに近づいたわけですが、それは明示的に強調されていません。WWDCのキーノートを見返したのですが、Yosemiteの新デザインのプレゼンにおいてiOSとの共通性は全く言及されていない。 対するにMaterial Designではたとえば新しく導入された画面上のボタン（Floating Action：下の図の緑の丸です）がすべてのデバイスで画面上に存在している。 Material Design unifies all Google products under one aesthetic. via: Google I/O 2014 Roundup - HardwareZone.com.ph Windowsはこうした「共通化」について一番極端だったといえるかもしれません。あのタイル画面をPCでもモバイル機器でも「どん」と正面に据えたわけです。このようにApple/Google/Microsoftがそれぞれ異なる画面上で何を共通にし、何を個別にしたかの判断はなかなか興味深いものがあります。 ━━━ 次に今回発表されたAndroid Wearのデザインについて。 このセッションについては、実際に行われたセッションの動画が公開されていませんが面白い要素がいくつかありました。 Smart Watchの画面デザインはどうあるべきか？それを考える上で 「まずやってみる」 ことはとても重要。かくしてGoogleのデザインチームは針金（のようなもの）を使ってAndroid スマートフォンを手首に固定したらしい。この「プロトタイプ」は傑作でした。（ああ、写真をとっておけば） これをやると何がわかるか？手首に固定された画面というのは、非常に激しく動く。これは手のひらの中にあるスマホの画面や、机に座って眺めるPCの画面と大きく異るところです。 従って静止した画面上ではどんなに美しく見えるデザインでも、揺れ動く手首の上では役に立たない。動く画面上では読み取れる情報量は少なくならざるを得ない。 調べてみると他社では、スマートフォンのUIをそのまま縮小してスマートウォッチに載せたような画面デザインもあるようです。 「スマートフォンのUIと共通性が高いので、すぐに移行できる」 という説明もロジックとしては成り立つでしょう。 しかしながらGoogleは実際に「使用」してみて異なるアプローチを採用したわけです。前掲のビデオで強調されているように腕につけたディスプレイ上では 「ユーザが行うタスクはなんなのか。それを実現するために必要な最低限の情報はなにか」 と考え、情報とインタラクションを絞らなくてはならない。そう考えると、Smart Watchの画面デザインというのは、スマホやPCサイトとは異なるチャレンジであることに改めて気がつくわけです。いや、楽しい。 しかし 仮にその問題を解いても 「Smart Watchを購入し、日常的に利用したいか？」 というさらなる難問が控えているわけです。 前回書いた内容 に沿って考えれば、Smart Phoneでは解けず、Smart Watchが解こうとしている問題は本当に存在しているのか？そしてAndroid Wearはその問題を効果的に解いているのか？これは実際に使ってみないとわからない。 ではさっそく当日プレゼントされたAndroid Wearを着用して自分で確かめてみよう、、としたわけですが、Androidスマホを持っていないと設定画面の最初で躓くことを知ったのでした。 ここらへんがApple原理主義者の限界、ということでGoogle I/O 2014の参加報告はめでたく（どこがだ）お開きです。

こんにちは。5月よりiOSチームにジョインした成田と申します。 先日のWWDC2014の発表には驚かされましたね！ OSのアップデートなどは予想通りでしたが、新言語の発表があることを想像できた人はほとんどいないのではないでしょうか。 当然HOME'SのiOSアプリチームもWWDC2014には注目しており、 当日の朝はSwiftの発表やiOS8の新しい機能に盛り上がっていました！（現地行きたい） 毎年毎年、新しい技術が発表されキャッチアップしていくのが大変ですが、それが楽しみでもあります。 iOS8から盛り込まれる新しい機能を利用して、どんなことが提供できるのか毎日毎日メンバーみんなで頭をひねって考えています。 さて、今回はそんなiOSチームが定期的に取り組んでいることを紹介したいと思います。 iOSアプリレビューランチ 隔週月曜日、ランチタイムに開催しています。 iOSアプリチームメンバーが、各々見つけてきた"気になる"アプリを紹介し合います。 エンジニアだけでなく企画も、デザイナーも全員参加です。 それぞれ視点の違う色々な人が集まるので、自分では見ることのないようなジャンルのアプリを知ることもでき、とても面白いです。 たまに海外のアプリも紹介されるのですが「こんなビジネスモデルがあるのか！」と驚かされることもあります。 やっぱりiOSアプリだと、UI関係が一番話題に上がりますね。 「最近、こんなUIが流行ってるよね」 「これ最近見るパターンだよね～」 なんて会話が繰り広げられます。 新卒の石田さんがアプリを紹介する様子。 毎回みんなネタ切れにならないように必死にアプリを探してきます 笑 iOS開発もくもくランチ 週1.5回開催、こちらもランチタイムに行っています。 エンジニアで集まり、iOS、Objective-C、Xcode、そしてSwiftなどを勉強しています。 残念ながら仕事が忙しかったり場所が確保できなかったりと、なかなか開催できないのですが「どんな新しいことができるだろう」、「どんなことに対応しないといけないか」などを考える良い時間となっています。 WWDC2014のKeynoteがあったお昼もエンジニアで集まって発表内容をざっくりと整理しました。 やはり今はiOS8が一番アツい内容です。 Swift勉強会 社外の方も参加可能なSwift勉強会です。 定期的（2～4週間おき）に開催したいと考えています。 先日の第1回の内容はiOS開発グループの石田さんが書いたブログ 「第1回Swift勉強会@ネクストを開催しました！」 に詳しく書いてありますので是非ご覧ください。 現在、第2回を企画中です。 ご興味のある方は是非ご参加ください！ 週末開発ハッカソン こちらは不定期開催です。 週末、どこかのワーキングスペースに有志で集まって自分の好きなこと、やりたいことなど課題を設定してもくもくと開発します。 業務ではなかなかできないことにも取り組めるので良い"息抜き"になっています。 ここで学んだことを業務にも生かせて自分の腕も上がるので良い機会となっています。 輪読会 毎週水曜日、朝一時間早めに出社して行っています。 今はあの「リーダブルコード」を開発チームで輪読しています。 発表者が章ごとにまとめた資料を作り、ざっくりとした内容を話します。 章が終わると一度区切って、内容についてディベートをします。 ここでメンバー同士の考え方の違いが分かります。 色々と話していく中で考えをすり合わせることでコーディングスタイルなどを統一させていくことができます（と思っています）。 朝一のフレッシュな頭で行っているので良い頭の運動にもなります！ もうすぐ「リーダブルコード」を読み終わるので、次回は「iOSヒューマンインターフェイスガイドライン: UI設計の基本事項」を読み解いていく予定です。 まとめ HOME'S iOSアプリチームの取り組み、いかがでしたでしょうか？ より良いアプリを作るため、目に見える部分だけでなく目に見えない部分も改善しようと日々取り組んでいます！ そんなiOSチームが開発した HOME’Sアプリ が先日デザインを一新してアップデートいたしました！ ダウンロードしていただけると、とても嬉しいです！ これからもiOSアプリチーム一丸となり、工夫を凝らしながら頑張っていきます！ よろしくお願いします！

Apple原理主義者の大坪です。 さて、GoogleI/O2014参加レポート第２弾。Google I/Oがカバーしている内容は、Googleの事業領域を反映しサーバーサイドからクライアントのデザインから、はてまたロボットにいたるまで非常に幅広い。今日はその中から標題のセッション＋別のセッション内容を元に書きます。 ーーー スピーカーはGoogleのシニア User Experience Researcher, Tomer Sharon 氏。まずMITとStanfordのComputer Science卒業生が作った「メモ作成アプリ」を開発したスタートアップ(仮想のものか実在のものかわかりません。少なくとも創業者の写真は別の人がモデルをしていました）がなぜ失敗したかについてその理由を挙げて行きます。 1 They did not fall in love with problem ：問題をよく考えていなかった 彼らは自分たちがメモをとるのに苦労しているところから、サービスを考え始めました。実際に他の人も同じ問題を抱えているか確かめるために、サービスのweb siteだけつくってe-mailアドレスをあつめ、そのことにより「なるほど他の人も電子メールのアドレスを登録するくらいには、問題をかかえているんだ」と考えました。しかしそれ以上自分たちが対象としている問題について掘り下げなかった。 2. learned from friends：友達から意見を聞いた 自分たちの問題認識が正しいか、作ったアプリが売れるか確かめるために７人の友達や家族に意見を聞いたとのこと。しかし聞いた相手が友達であるが故にバイアスがかかっていることに気がつかなかった。 3 listened to users：ユーザの言うことに耳を傾けた ニーズ調査で一番大事なのは「ユーザの言うことを聞かない」こと。そのかわりにユーザを観察するべきだと氏は主張します。 社会心理学の分野では１００年も前から「人間は自分の行動を予測するのが下手だ」と知られている。しかしユーザ調査をする時にはこの事実があまりにも頻繁に忘れられます。氏があげた例は以下の二つ。 1937年に行われた実験。まず学生達に「君たちは試験でカンニングするか？」と聞く。それに対して学生達は回答をする。 その後で、実際にカンニングが簡単にできる環境で試験を受けさせる。すると「カンニングするか」という問いに対する答えと、実際の行動の相関はほぼ０に近かったとのこと。つまり全く関係がなかったわけです。 次に挙げた例は2012年に行われた調査。公衆トイレから出てきた人に「手を洗いましたか？」と尋ねる。すると９９％の人がYesと答える。 しかし実際にはトイレにカメラがしかけられており、行動が記録されていた。実際には男性：３２％/女性：６４％の人しか手を洗っていなかった。 彼らは自分たちが作ろうとしているアプリに関して「これを使いたいですか」「いくらまでなら払ってもいいですか」と質問しました。質問する相手が間違っているという事実に加え、そもそも人間は「自分がこう行動するだろう」と予測するのが下手。だからこういう質問には全く意味がない。 4　Didn't test riskiest assumption；一番重要な仮説を検証しなかった プロジェクトはいくつか仮説を立てて行われるわけですが、その中でも「もしこの仮説がこけると全て駄目になる」というものがあります。それを検証せずにただ製品とかサービスだけ作ってもその仮説が正しくないとわかった瞬間全て駄目になってしまう。 ここで挙げられている例では「スマートフォンの所有者は、メモを取りづらいことが大きな問題であると認識している」というのが最重要な仮説だったわけです。では彼らはそれを検証する努力をしたか？ 5 Bob the Builder mentality：自分が得意なことをとにかくやる 彼らは二人ともComputer Science学科を卒業した人間でしたから、とくかくコードを書いてアプリを作るのが得意だった。それゆえ自分たちが何を作ろうとしているのか、あるいはそれが正しい物なのかを検証するより先にとにかくアプリをリリースしてしまった。彼らにとって「創業」とはコード書きの練習だったのです。 6 Perfectly executing the wrong plan：間違った計画を完璧に実行してしまった 彼らは以下の検証を行うべきでした。 Problem:彼らが想定している問題が世の中に存在しているか Marketing:実際に企業をなりたたせるほど多くの人がその問題を抱えているか Product:その製品（もしくはサービス）は想定した問題を解決できるか 氏は実際にスタートアップ及びベンチャーキャピタル１５０社にインタビューをしたそうです。彼らはこうした検証を行う為に何を聞くべきかを「知って」はいたのですが、そのやり方には問題が多かった。 ・12%の会社は "user experience"の定義を知らなかった ・86%のスタートアップはは創業者が個人的に感じている「苦痛」からスタートしていた。ちなみにユーザスタディから最初に解くべき問題を見つけていたのは2%. ・そもそも「解くべき問題は何か」というところからスタートした人はほとんどいなかった ーーー ではどうすれば良かったか？ここで氏は"Lean User Research"を提案し、具体的に三つの手法を取り上げます。 手法その１：experience sampling 1950年代に開発されたPager Study:ポケベル調査が元とのこと。被験者にPagerを配り一日に何回も同じ質問をしてリアルタイムに回答を集める。その回答結果を利用して被験者の行動を理解する。実際に公演中に出された質問は "What was the reason you recently used a piece of paper to write something down?" 最近紙に何かを書いた時に、なぜそうしたか理由を教えてください というものでした。もし１００人の被験者に対して一日に５回、５日間この質問をしたちすれば、2500の回答が集まることになります。 この際重要なのは質問の仕方で ・はい/いいえで答えられる質問は駄目 ・数を聞くのは駄目。その結果を平均しても意味は無い ・「意見」を聞くのではなく、実際の行動を聞く ・一分以内に答えられる質問にする 具体的に良い質問の例は 最近webサイトをアップデートした理由はなんですか？ 駄目な質問の例： 過去一時間に何通メールを受け取りましたか？ GoogleではこのExperience Samplingのために PACO を使っているそうです。 これによってユーザのニーズ、特徴、苦痛に思っていること、うれしいこと等を知ることができる。 手法その２：observation　観察 ここでは観察の手法がいくつか語られましたが、面白いと思ったところだけ。 「問題」というと例えばタスクを邪魔する物とかうっとうしいと思っているものに関して観察すると思いがちですが、氏はDelight：何を楽しいと感じるかを観察することも重要だと強調していました。 またもう一つおもしろいと思ったのが transitions:具体的には、会議が終わった後、次の会議室に行く間にその人は何をしているか？スマホを開いて何をしているか？こうしたTransitionの最中に何をしているかを観察することは、その人のニーズを知るのにとても有効だと言います。 手法その３；fake doors あちこちで講演を聴いていると、Webサービスの場合、本サービスができていなくても予告ページだけ作るのは結構よく行われているようです。先ほどのスタートアップでも実際に予告ページを作り「メールアドレスを集める」ことでニーズを推し量ろうとしました。 しかしそうではなく「＄５払えば、アプリができたとき真っ先に入手できます」とやるべきであったと。メールアドレスを渡すというのもある程度の「覚悟」を示すものではありますが、それよりは実際に＄５払うだけニーズを感じているか調査したほうが遥かに良い、と。 ＾＾＾ 講演の最後に 「映画にでてくるヘリコプターがどうなるか」 という円グラフが表示されました。100%の確率で爆発する。ほとんどのスタートアップは「ユーザニーズを調査している時間はない」といいますが、間違った計画を立ててしまえば、プロジェクトの運命は映画の中のヘリコプータと同じだ。正しい計画を実行しよう、と強調して講演が終わりました。 この講演の内容を文字にしてみると「興味深い」と思う自分と「それだけでは足りない」と思う自分の両方が存在していることに気がつきます。例えばFake Doorを作って「実際に＄５払うことでユーザニーズを確認する」ことはできるかもしれません。 じゃあ例えばiPhoneの宣伝文句だけ書いて「この製品が欲しい人は＄１００振り込んで」とやってニーズの確認ができただろうか？私のようなApple原理主義者でさえも実物のiPhoneを観る事無しに＄１００振り込むことはしなかったと思います。そもそもAppleはユーザ調査に時間も金をかけない（らしい）会社ですがその製品は実際に登場すると人々が「こんなのが欲しかったんだ」と思えるものになる（ええ、私は自分の偏見をある程度自覚していますよ） 大ヒットする製品というのは、ユーザが自覚しておらず、「あたりまえ」と諦めている不満を解消する製品ではないか、と最近考えています。はたしてそうした製品のニーズを製品なしに確認することが可能でしょうか？ などとApple原理主義者がAppleを例にとって考えても公平性を欠く。では、 Weebly の成功物語にこの講演の内容はどう適用できるだろうか。とかなんとか考えるネタはつきないわけです。と放り出したところで今回はおしまい。 Lean User Researchのサイトは http://www.leanresearch.co 本講演のビデオ（半分）は

こんにちは、リッテルラボラトリーの清田です。 現在、巨大なWebログデータを活用して、ユーザーの潜在的なニーズを解析するという取り組みが盛んにおこなわれています。ネクストでも、HOME'Sのログデータを主な対象として、住まい探しのユーザーのニーズをとらえてサイト改善や情報レコメンデーションに活用するための取り組みが進められています。 「Webログデータ活用の最前線にはいないけれども、巨大なWebログデータがどういうものかを知りたい」「巨大なWebログデータを実際に触って分析してみたい」と思っている方もおそらく多いのではと思います。Webで検索すると、HadoopやAmazon Elastic MapReduce（EMR）によるログデータ解析を企業内で活用している事例はたくさん見つかります。しかし、大規模なWeb情報サービスを展開している企業に在籍していない方にとって、そのようなデータはなかなか手に入らないというのが現状ではないでしょうか。 Webを研究対象としている大学の研究室でも、「どうやって巨大なWebログデータにアクセスするか」は大きな問題になっています。 WSDM というWebデータ活用に関する国際会議での 発表論文 を調べてみると、大学の研究者と企業の研究者による共同研究が多いことがわかります。ほとんどの場合、大学と企業の共同研究では、大学と企業が何らかの秘密保持契約を結んだ上でデータの提供が行われています。日本でも、たとえば国立情報学研究所（NII）を通じて提供されている データセット があり、Yahoo!、楽天、ドワンゴなどの企業が研究者向けにデータを提供しています。 ただ、「まずは触って試してみたい」というニーズでは、契約手続きなどはちょっとハードルが高いかもしれません。そこで今回は、「巨大なWebログデータのうち、だれでも手続き不要で自由に利用できるものがないかどうか」というテーマを扱います。 巨大データの公開の取り組み 「ソフトウェアを誰でも自由に利用できるようにする」というオープンソースの概念はすでにおなじみかと思います。近年は、オープンソースの概念は 文章・画像などの創作物 や ハードウェア 、そして データ にも広がってきています。とくに、政府や地方自治体がもつ統計情報（人口・経済など）や、科学研究に利用されるデータ（気候予測・ヒトゲノム情報など）の公開・利用はずいぶん進んできました。 Amazon AWS でも、誰でも自由にアクセスできるさまざまなデータをホストする仕組みとして、 Public Data Sets が提供されています。AWS Pubic Data Setsの リスト にアクセスすると、宇宙科学、生命科学、化学、気候学、経済学などの分野でさまざまなデータが公開されていることがわかります。 しかし、AWS Public Data Setsには「Webログデータ」に相当するデータはほとんど見当たりません。そもそも、世の中に「自由に使える巨大なWebログデータ」というものはほとんど存在しないようです。いったいなぜでしょうか？ Webログデータを公開するリスク Webログデータを研究用途などに利用できるようにしようという取り組みは過去にいくつかありました。代表的な例が、AOLが2006年に公開した AOL Search Query Logs です。AOLは、非商用の研究利用に用途を限定して、50万ユーザーの3ヶ月間（2006年3月〜5月）の検索ログデータをWeb上で公開しました。 しかし、AOLはこの件でたくさんの抗議を受けてしまい、 すぐにこのデータを取り下げてしまいました 。検索ログデータ中にユーザーのプライバシーに関わる情報が含まれているというのがその理由でした。（AOLはすぐにデータを取り下げたものの、多くのコピーがいまも出回っているようです） AOLが公開したログデータには、ユーザーを直接特定できる情報（ユーザーIDやIPアドレスなど）は含まれていませんでした。しかし、検索クエリーの中にはユーザーを間接的に特定しうる情報が含まれていることが問題になってしまいました。たとえば、「自分の名前」で検索したユーザーがいた場合、特定できてしまう可能性があります。この事件の顛末を知りたい方は、 英語版Wikipediaの記事 などをチェックしてみてください。 AOLの件に限らず、プライバシー情報を含む可能性のあるログデータを共有する際には、細心の注意が求められます。プライバシー情報を含むデータを、個人のプライバシーを侵害せずに共有・活用するにはどうしたらよいかは、プライバシー保護データマイニング（Privacy-Preserving Data Mining, PPDM）という分野で盛んに研究されています（PPDMについては、また別の機会に紹介したいと思います）。 Wikipediaアクセス統計の最新データをElastic MapReduceで使えないか？ 残念ながら「手軽に利用できる巨大なWebログデータ」というものはなかなか手に入らないのが現状のようです。しかしながら、Webログデータそのものでなくても、「巨大」かつ「最新」で、「世の中の動きを反映」して、「Elastic MapReduceなどで簡単に使える」ようなデータがあれば、巨大なログデータを触る面白さは体験できそうです。 Wikipediaのアクセス統計データ は、そのような条件をある程度満たすかもしれません。前述のAWS Public Data Setsにも 同じデータ が含まれています。ただ、S3ではなくEBSスナップショットでの公開なので、Elastic MapReduceではちょっと使いにくそうです。また、できれば最新のデータで試したいところですが、あいにく2010年現在のデータであり、更新されていないようです。 もしWikipediaのアクセス統計データの最新版がAWS S3上にあれば、そのような条件をある程度満たせるのではないかと思っています。たとえば、「直近で話題になったキーワード」や「特定の話題（たとえばW杯）の言語圏別での盛り上がり方の違い」などがEMRで解析できれば、いろいろと面白い結果が得られそうです。 現在、Wikipediaのアクセス統計データのS3上での公開の準備を進めています。次回以降の記事で、データの利用方法や、実際に解析してみた結果などを紹介していきたいと思います。ご期待ください！

Apple原理主義者の大坪です。 先日Google I/Oに参加するチャンスを得ました。Apple主催のWWDC2014ではなくGoogle I/Oです。何故Apple原ry)が？と問うのであれば、抽選の神様に聞いてくださいとしか答えようが無い。いくら私がAppleを愛していようが、さいころの目が「否」とでればWWDCに参加することはできない。何かの気まぐれでGoogleがふったサイコロが「正」と出ればそちらに参加する権利が得られる。細かいことは抜きにしてとにかく行くのです。そして行ったのです。ああ、世の中にこれほどGoogle Glassの装着率が高い場所が他にあるだろうか。（下の写真の黄色矢印は全てGoogle Glass) さて、今回はエンジニアリングにもデザインにも全く関係ない話を書きます。初日のキーノートで何が起こったのか。 ーーー Google I/Oの公式サイト に行くと、初日のスケジュールはこんな感じになっています。 Breakfast: AM7-AM9 Keynote: AM9-AM11 Lunch/Code Labs/Sandbox: AM11- 今回Google I/O初参加の私は 「そっかー。初日でも朝ごはんがあるんだ。貧乏人にはありがたい。では早めに行き、朝ごはんを食べてKeynoteに臨もう」 などと考えておりました。 さて、会場が近づいてきたけどまだ午前６時４５分。少し早くついちゃったかな、と思いながら会場についてみれば長蛇の列が。ああ、やはりKeynoteとはこういうものなのね。 後から知ったのですが朝食用の列は別にあったとのこと。当時の私はそんなことなどつゆ知らず目に入った入場用の列にひたすら並ぶ。前で話している人たちは英語であれこれ、後ろにいる一団は中国語でしゃべっています。暇だからネットで何か見ようかとも思うわけですがあまりに電池を使って肝心な時に電池切れになっても困る。ヒマだ。 などと思っているといろいろな人達が巡ってきます。まず背中にタンクを背負った 「コーヒーいかがっすかー（意訳）」 の人たち。長い間列に立っていると、体がだんだん冷えてくる。熱いコーヒーが欲しくなるところですが、トイレに行きたくなっても困る。一人だし。というわけでコーヒーは我慢。無料だけど。 次に巡ってくるのが、 「ドーナッツいかがっすかー（意訳）」 の人たち。彼女たちが押すワゴンには色とりどりのドーナッツが乗っている。いくつか手に取ります。無料だから。朝から何も食べていないので、ありがたいのですが米国特有（と私が思っている） 「甘さは正義」 のドーナッツは、あまり個数を食べることができません。 時計は８時をまわりましたがまだ列が動く気配がない。 一歩引いてこの状況を考えなおしてみましょう。ここにいるのは、時間と金を使ってまでSan Fransiscoに来よう、という気合いのはいったNerdとDesigner達。それが何千人もひとつところにとどまって暇を持て余している。これほど費用がかからず、たくさんのNerdに接触できる機会はない。というわけでいろんな会社のリクルート関係の人も回ってくる。 会社の名刺を配って何やら話している人たちもいるのですが、今回一番ありがたかったのはTarget(米国のディスカウント百貨店チェーン）の人達。なんでも 「テクノロジーチームで採用中」 とのことで、リクルート担当の名刺＋チョコレートバー＋モバイル用のバッテリーを無料で配ってくれる気前の良さ。名刺を渡すとさらにShero2.0が当たるチャンスが！ということなのですが、Targetが東京にオフィス持っているわけないので名刺を渡すのは思いとどまりました。下の写真はもらった物一式。 ここまでで１時間半以上寒い屋外に立っていることになります。最初は半袖姿だったまわりの人たちも上着を取り出して着込んでいます。 時計をみれば８時半を過ぎ、列はようやく少しずつ動きだす。そのころには列は長く、長くなりMoscone Centerを２重に取り囲んでいる。これだけの人数がたったあと３０分で入場できるものだろうか？そんなことを考えていると、隣の駐車場にこんなバナーを掲げる一団が。 ううむ。Don't be evilというのは何かと話題になるGoogleのスローガン。こうしてわざわざバナーを掲げる人が出てくるところはやはりアメリカだよなあと思ったりもします。日本だとハンドマイクもってビラ配るイメージですか。 さて、そのあと列はどどとっと動く。おそらく朝食を食べたのであろう人たちが一階にいますが、そのままキーノート会場に行けるわけではないらしい。その人達が会場横の出口からでてきて、列に混ざる。これがいいことかどうかわからないのですが、セキュリティの人たちが止めにはいる。 一旦会場に入ると、そのままエスカレーターでキーノート会場まで一直線。椅子に座るとほっと一息。そのうち「もうすぐキーノートが始まります」とアナウンスがありますが、まだ空いた椅子がいっぱいあり、次から次へと人が入ってくる。 そのうち舞台上で巨大「ピタゴラ装置」が動き出しキーノートが始まる。しかし人はまだまだ入ってきます。結局入場する人の列が止まったのは９時４０分頃だったように記憶しています。 ーーーー プレゼンテーションが始まってしばらくたったところ、何か妙な声が聞こえる。こういう時最初は何が何やらわからないものですね。どうやら誰かが何かを叫んでいる。会場のセキュリティ関係者がわらわら移動していくとやがて静かになり、やれ落ち着いたと思っていたらもう一人でてきたのには驚きました。後で調べれば Protester だったとのこと。 そうしたハプニングもありながらもキーノートは様々なトピックをカバーする。それは日頃Androidに触れることの少ない私にも興味深い内容なのですが、ちょっと長すぎるのではないか。時計を見れば１１時を過ぎているのですが終わる気配がない。ぼつぼつ席を立つ人も目立ち始めました。もし１１時からのイベントに参加したければ抜けなくてはならない。理解はできるのですが、キーノートといえばWWDCのそれしか体験したことがない私にとって、途中退席する人がいるのは驚きでした。 最後から２番めに登壇した人が"Next"という度に絶望感が深まる。そろそろお開きにしていただけませんかねえ、と思ったところでみんなお待ちかね、おみやげの発表です。最初はCardBoard。なんだそれは？ 「これはGoogleのEngineerが20%枠でつくったものだが」 とか説明はいいのですが、正直なんのことかわからない。次にアナウンスされたのがAndroid Wear のプレゼント。キーノートで３種類のWatchが発表された時の会場の反応は、私の主観ではこんな感じでした。 ・LGは今日から→パチパチ ・サムソンも今日から→ちょっと微妙な反応 ・Motorolaの丸いのは今年の夏から→えーっ（落胆の声多数）。 でもってLG or サムソンを今回渡し＋Motorolaは発売になり次第「可能な国に対して」プレゼント。ををこれはすごい。 と参加者のテンションが上ったところでキーノートはお開き。会場を出たところではCardBoardを配っている。見たところAmazonの箱のようなダンボール。それを組み立てた時に何ができるか理解できたのはかなりたってからでした。 ーーー こうしたカンファレンスのキーノートをどのように行うかは、企業によって様々だなと実感しました。私が面白いと思った記事を以下に引用します。 Now imagine if Apple held a WWDC keynote like this, and the shit storm that would ensue. The reactions would be apoplectic. There’d be pundits calling for Tim Cook to be fired. 引用元： Daring Fireball: Mike Wehner on Today's Google I/O Keynote てきとうな訳：もしAppleがWWDCでこんなキーノートをやったらどんな反応になるか想像してみよう。恐ろしいことになるに違いない。Tim Cookを首にしろ、という声が巻き起こるだろう。 さて、その後には興味深いセッションが続いたわけですがその内容については以下次号（ちゃんと次号はでるのか）

こんにちは、上津原です。 前回はHTTP通信をしましたが、今回は同時によく使うであろうJsonのパースです。 Jsonのパースも、実はBluePrintで実装することができず、C++で実装する必要がありました。 なので再びAnswerHubを漁り、なんとか動いたので記事にしておきます。 今回はローカルにあるJsonファイル 前回HTTP通信をしましたが、今回はローカルです。なのでローカルからデータを読み出すコードも合わせて公開します。 gist435e728d81e751b66df0 読み込んでいるJsonファイルは以下です。 gist60688c55ae7be685325b ちょっとした解説 Jsonはパースという名前ではなくて、シリアライズ、デシリアライズという名前で管理されています。 シリアライズ：JsonObjectからテキストへ デシリアライズ：テキストからJsonObjectへ という感じです。今回はテキストからJsonObjectへ変換するのでデシリアイズを行っています。 まだ不明なポイントとしては、 TArray<TSharedPtr > objArray = JsonObject->GetArrayField(TEXT("Entries")); の部分です。 Arrayのオブジェクトを取得するのに無名のArrayを利用しようとしたのですが、いまいちやり方がわからず連想配列で名前を付けてやると取得ができました。 注意点 パッケージ化したときにSavedディレクトリ内には、置いておいたJsonファイルはなくなってしまってました。きちんと永続化したい場合は別の手段をとった方がよさそうです。今回はその必要がなかったのでそこまで調べていませ。 HTTP通信と組み合わせれば、API取得・パースができる！ 前回のHTTP通信と組み合わせればよくあるAPI問い合わせができるようになると思います。 ここからBluePrintに利用したければ、Arrayに入れて、UPROPERTYしてやれば活用ができます。

Origami原理主義者の大坪です。IDEOがAvocadoを発表したぞーと 書いた のはいいのですが肝心な「どうやって使うか」が書かれていないではないか。またまた言いっぱなしでいいのだろうか、いやよくない。 というわけで、SimpleExampleの精神に則り「簡単なことは実用性よりも重要である」というポリシーの元（いつそんなポリシーができたのだ）とにかく簡単にAvocadoを使ってみます。 今回の完成形はこれです。 いや、こんな一覧と詳細画面の移動だったらOrigamiでもできるではないか、とは言わないでほしい。確かにできるのですが、Avocadoを使えばさらに簡単に、、、、、（ゴニョゴニョ） 語尾が曖昧になっているのが気になりますが、気にせず説明を始めます。 というわけで、 第一回目の記事 を参考にして、下の図までつくりましょう。 今までとどこが違うかわかりますか？Phoneが(Avocado）になっている。何がどう違うのかわかっていませんが、とりあえずこうしておきます。Render in Imageの下のほうをダブルクリックして中にはいりましょう。 Patch Libraryを開き"Master Detail"を探してEditorに追加 Githubからファイル をダウンロードして、assetsフォルダにある２つの画像ファイルをEditorに追加。Layerが接続された状態で追加されますが、今回このLayerは削除します。 masterのイメージを"Master Detail"パッチのMaster Imageに、detailのイメージを"Detail Image"に接続する。 この段階で、Editorはこんな風になっているはずです。 ここでViewerを見ると、masterかdetailかどちらかが表示されている。いくらその上でクリックしても動きません（何も作ってないのであたりまえです）。Master Detailパッチを選んだ状態でPatch Inspectorを開き、Switch to DetailとSwitch to Masterのチェックボックをつけたり外したりしましょう。するとViewerの中で画像がMasterになったりDetailになったりします。 というわけでここからやるとは「画面の特定の部分をクリックしたら、これらの入力をonにしたりoffにしたりする」ことです。いつまでもPatch Inspectorでチェックボックスをつついていたい気持ちをぐっと抑えて（誰もそんなこと考えませんか？）次の手順に進みましょう。 というわけで次にやることは、「お決まりのパターン」の追加です。Button, Interaction2そしてSwitchを追加し以下のように接続します。 Buttonの左上をInteraction2の右上に Interaction2のClickをSwitchのFlipに SwitchのOn/OffをMaster DetailのBack to Masterに この状態では、画面の真ん中に「どん」とButtonが存在し、それをクリックすると画面がDetailからMasterに変わります。しかしそれっきりで反対方向には移動しません。 というわけでさらに一工夫します。 Logicパッチを追加。 追加したLogicパッチを選択、Patch Inspectorを開き、Operationを"NOT"にします SwitchのFlipからLogicパッチの右側（上でも下でもいいです）に接続 Logicパッチの左側からMaster DetailのSwitch to detailに接続 ここまでやるとEditorはこんなになります。 これで画面の真ん中のButtonを押せばそのたびにmasterとdeitalが切り替わる。あー長い道のりでした。はい、おしまい。 などと暴論を吐くのでいい加減なエンジニアは困ります。（”エンジニアがいい加減”なのではありません。私が”エンジニアの中でも特にいい加減な人"なのです）というわけでButtonをちゃんと配置しましょう。Buttonパッチを選びPatch Inspectorを開いて、、 Anchor PointをTop Centerにします。 Widthを640,Heightを120 Corner Radiusを0 Titleをブランク ここまでやると、ボタンが白い四角になっています。この位置でいいと思ったら最後に Background Colorを選び、Opacityを0%にする 最後の手順でボタンが透明になります。今度こそおしまい。そりゃMasterから移動する際に一番上を押した時しか反応しないのってどうなのよとかいろいろいいことはあるかもしれませんが、 「細かい事を気にしない」 というのはとても大事なことです（何をえらそうに） というわけで簡単に移動ができたのですが、たとえば来る時と戻る時で反応する領域を変えようと思ったら、話はとたんにややこしくなります。となるともう一階層を作って、、というわけでAvocadoのExamplesにあるMessaging app.qtzと同じようなことになるわけです。 あと画面遷移の時間を変えるのってどうやるんだろう、、とか考え始めると「簡単にできます！」という文章の語尾が ゴニョゴニョ になってしまう。毎度のことながら 「素材はフレキシブルだけどそこから作るの大変だよね」 と 「大分組みあがった部品は使い道がぴったりだと便利だけど、柔軟さに欠けるよね」 のバランスを取るのは難しい。しかし今は選択肢が増えたことを喜びましょう。と優等生的に前向きな言葉でまとめたところで今回はおしまいです。

こんにちは。菊地と申します。 今回は AndroidStudio で導入された Build Variants という仕組みについてです。 AndroidStudio がリリースされてだいぶ経ちますので、今更な感じはしなくもないですが、意外と知らない人も多いかな？と思ったのでまとめてみました。 はじめに AndroidStudio では既存のビルドシステムである Ant に代わって、 Gradle が採用されています。ビルドの設定は build.gradle というファイルに記述していきます。 build.gradle に記述できる内容は多岐に渡り、様々なことが可能となっています。 例えば debug ビルドと release ビルドで APK を区別したい！ AndroidManifext.xml に記述する permission を release ビルドには記述したくない！ Google Maps Android API v2 の API Key を debug と release で切り替えたい！ 同じソースコードから広告あり版と広告なしのアプリをビルドしたい！ こんなことができたらいいと思ったことはありませんか これらは Build Variant を使うことで解決することができます。 Build Variants とは？ 公式によると Build Type + Product Flavor = Build Variant Build Type と Product Flavor ってなに？？？となりますよね。 そこで、 Build Variants を理解するために必要な Build Type と Product Flavor についても理解する必要があるため、簡単な例とともに説明します。 Build Types Build Types はビルドの種類のことです。 ビルドの種類毎にプロパティを設定することで、個別に設定を反映することができます。 デフォルトでは自動的に debug と release という2つのバージョンをビルドします。 (今回は説明のために debug と release を記述しています) android { ... defaultConfig { ... } buildTypes { debug { ... packageNameSuffix ".debug" } release { ... } } } buildTypes の中に debug と release の2種類が書かれています。 debug に対して packageNameSuffix ".debug" を設定しました。 packageNameSuffix は packageName の末尾に指定文字列を追記するものになります。 こうすることで、 debug ビルドの場合に packageName の末尾に .debug が付与されるため、一つの端末上で debug ビルドと release ビルドの APK が共存可能になります。 ちなみに、設定可能な property は以下のようなものがあります。 詳細については今回は割愛させていただきます。 Property name Default values for debug Default values for release / other debuggable true false jniDebugBuild false false renderscriptDebugBuild false false renderscriptOptimLevel 3 3 packageNameSuffix null null versionNameSuffix null null signingConfig android.signingConfins.debug null zipAlign false true runProguard false false proguardFile N/A(set only) N/A(set only) produardFiles N/A(set only) N/A(set only) Sourcesets デフォルトではビルド対象となるソースコードは src/main になりますが、 buildTypes 毎にビルド対象となるソースコードを分けることもできます。 buildType が debug のとき src/debug が存在する場合は配下にあるソースコードもビルド対象 buildType が release のとき src/release が存在する場合は配下にあるソースコードもビルド対象 Dependencies デフォルトでは Compile , Provided , APK , TestCompile の4種類が指定可能ですが Build Type を設定したことにより Build Type 毎に Complie を指定できるようになります。 android { ... } dependencies { compile '' provided '' apk '' androidTestCompile // debug build だけの依存関係 debugComplie '' // release build だけの依存関係 releaseComplie '' } Product Flavors Product Flavors はアプリケーションのビルドをカスタマイズしたものを作るための仕組みになります。 有料版と無料版のビルドを１つのプロジェクトから行ったりといったことが可能になります。 android { ... defaultConfig { ... } productFlavors { development { ... packageName "jp.co.next.development" } production { ... packageName "jp.co.next.production" } } } Source デフォルトではビルド対象となるソースコードは src/main になりますが、 buildTypes と同じ様に productFlavors 毎にビルド対象となるソースコードを分けることもできます。 productFlavor が development のとき src/development が存在する場合は配下にあるソースコードもビルド対象 productFlavor が production のとき src/production が存在する場合は配下にあるソースコードもビルド対象 Build Variants BuildTypes と ProductFlavors について、どういったものかがわかったところで、本題である Build Variants についてもみてみます。 Build Type + Product Flavor = Build Variant Build Variant 　は Build Type と Product Flavor の組み合わせ毎にビルドを行うものになります。 Build Variant 毎の タスク名 および ソースディレクトリ名 は以下のようになります。 Build Types Product Flavors タスク名 debug assembleDebug release assembleRelease debug development assembleDevelopmentDebug release development assembleDevelopmentRelease debug production assembleProductionDebug release production assembleProductionRelease Build Types Product Flavors ディレクトリ名 debug src/main + src/debug release src/main + src/release development src/main + src/development production src/main + src/production debug development src/main + src/developmentDebug release development src/main + src/developmentRelease debug production src/main + src/productionDebug release production src/main + src/productionRelease ※ AndroidManifest.xml が複数存在する場合は内容がマージされます src/main/AndroicManifest.xml には Activity などを共通的なものを記述し debug ビルドでのみ必要となる permission などを src/debug/AndroidManfest.xml に書くといったこともできます <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > ... <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <activity /> </application> </manifest> <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > <uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION"/> </manifest> Google Maps Android API v2 の API Key などを src/debug/AndroidManifest.xml と src/release/AndroidManifest.xml でかき分けておくと便利！ <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > ... <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="debug用のAPIキー"/> <uses-library android:name="com.google.android.maps" /> </application> </manifest> <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > ... <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="release用のAPIキー"/> <uses-library android:name="com.google.android.maps" /> </application> </manifest> まとめ 今回は、簡単にですが Build Variants ってなに？どんなことができるの？という点についてまとめてみました。 さて、冒頭で例にあげたこと。もうやり方はわかっているとは思いますが、まとめておきます。 debug ビルドと release ビルドで APK を区別したい！ Build Type 毎に packageNameSuffix を設定する Product Flavor 毎に packageName を設定する AndroidManifext.xml に記述する permission を release ビルドには記述したくない！ Build Type を使って src/debug/AndroidManifest.xml にだけ permission を追記する Google Maps Android API v2 の API Key を debug と release で切り替えたい！ Build Type を使って src/debug/AndroidManifest.xml に debug key , src/release/AndroidManifest.xml に release key を設定する 同じソースコードから広告あり版と広告なしのアプリをビルドしたい！ Product Flavor を使って ソースコードをわけたりライブラリの依存関係を設定する おまけ Google Play Developer Console に APK をアップロードする際にデバッグ可能な APK をアップロードしました。」と言われた！ Build Variants の値が Debug になっていないかを確認してください。 Build Variants ってどこでみれるの？ AndroidStudio の View > Tool Windows > Build Variants からみれます。 Module Build Variant next debug

こんにちは。新卒で今年からiOS開発グループに配属された石田です。 はじめに 　私はiPhoneアプリ開発経験がなく、これからObjective-Cを勉強していこうと思っていた矢先に、WWDC2014にて新言語Swiftの発表がありました。そんな新卒の視点から、先日弊社で開催されたSwift勉強会の模様をお伝えします。 開催までのいきさつ 　Swiftの発表にはiOS開発グループの先輩も驚いたようですが、さすがエンジニア。いち早くSwiftを習得しようと、まだ情報が少ない中、開催予定の勉強会に参加しようと盛り上がっていました。さまざまな勉強会の情報を見ていくうちに、「自分たちで勉強会を開催してLTも行えばより勉強になるのでは？」、という話になり開催が決定しました。発表された直後でホットな話題ということもあり、「やるなら早いほうがいいよね」ということで発表から1週間後の6月11日にSwift勉強会を行うことになりました。 開催概要 　第1回Swift勉強会@ネクスト 　イベント告知: http://connpass.com/event/6780/ 18:30 - 19:00 受付 19:00 - 19:10 はじめに 19:10 - 20:00 LT 20:00 - 21:30 情報交換会 LT1本目 「複数人でSwift開発をするときに気を付けるべきと"個人的に"思ったこと」（ネクスト枠　藤原さん） 　iOSでの開発の経験が浅い人向けに、複数人でSwift開発するときに気を付けるべきことをまとめたLTでした。発表者の藤原さんは、PHP等を用いた開発を長年やってきた経験をもとに、Swift開発で楽になりそうなところ、それゆえにプロジェクトで開発するときに困りそうなことを述べてくれました。classとstruct、varとletの使い分け、依存関係の分かりやすいクラス設計など、これから意識していく必要性を強く感じました。 LT2本目 TitaniumユーザーがSwiftを触ってみたら（外部枠　宮下さん） 　Titaniumという、JavaScriptでiPhoneアプリやAndroidアプリが作れてしまう開発環境があるそうです。私はこのLTで初めて知りました。かつてはiPhoneアプリを作るならObjective-C, AndroidアプリならJavaと選択肢が限られていたのですが、TitaniumやSwiftといった別の選択肢が出てきており、開発環境の幅が広がってきているようです。これらの代替ツールの利点と欠点を分かりやすく発表していただきました。お忙しい中、本当にありがとうございました。 LT3本目　 Optionalの使い方（ネクスト枠　成田さん） 　Swiftで追加されたOptionalという機能についての技術的なLTでした。"Optionals are an example of the fact that Swift is a a type safe language"(訳：OptionalはSwiftが型安全な言語である事実の一例だ)という公式ドキュメントの文から始まりました。　Swiftでは通常の型にnilは入れられないのですが、Optionalを指定するとnilの代入が可能になるというものです。デフォルトでは型は厳格に設計されており、宣言の際に「?」をつけるとOptionalに、「!」をOptional型に付けると解除されるようで、この表現は直感的で分かりやすいと思いました。イメージでいうと、「nil入れてもいいの？」「nil入れちゃダメ！」という感じです。 LT4本目　Genericsについて（ネクスト枠　小屋敷さん） 　ジェネリクスの機能についてのLTでした。関数やクラスで用いる引数や返り値は、あらかじめ型指定する必要があります。しかしジェネリクスを用いて型を指定することで、型だけ違って処理の内容が同じものを作ることができる、というものです。私はC++を使っていたのですがそのときにコードに、CArray型にインスタンスをいれるときの宣言に、<>で型指定しないといけないけどなんのことだろうと思って使っていました。とても勉強になりました。 LT5本目　Swiftにおけるオブジェクト指向（飛び入り枠　ネクスト寒川さん） 　このLTは勉強会運営側も予定していなかったのですが、Androidチームの先輩が急遽プレゼン資料を用意して参加してくれました。Swiftを使って新入社員にオブジェクト指向を教えるためには、というテーマでスタートしたLTですが、途中からSwift→Sushift→寿司ft、という流れで、今回皆さんに衝撃をもたらしたマルチバイト文字を使った変数を利用し、寿司の絵文字でオブジェクト指向の継承を説明するというネタに走ったLTでした。親クラスをごはん、子クラスを寿司の絵文字で説明され、シュールな見た目に会場は笑いに包まれました。裏話ですが、継承関係にある絵文字を探すのに、発表者の寒川さんはとても苦労されたようです。 LT全体として 　バックグラウンドが異なる技術者がそれぞれSwiftを触った意見を聞くことができ、興味深かったです。言語的には読みやすい、いままで使ってきた何かしらの言語に似ているといった意見が多かったと思います。また開発環境的には、まだ改善すべき点がある、区別し辛い点があるといった意見が見受けられました。また終了後にご回答いただいたアンケートでは、新しく導入された概念がよく分かった、他の技術者がどういう観点でSwiftを捉えているのか見られてよかった、という感想をいただきました。 なお今回のLTで使用した資料の一部は、発表者の方が提供してくださいましたので、記事の下のリンクから閲覧することができます。ぜひご覧ください。 情報交換会 　情報交換会では、ピザやお酒を交えて自由に情報交換を行いました。寿司ftの裏側やSwiftの技術的な話、業界の話などで盛り上がりました。 最後に 　今回の勉強会にお越しいただいた皆様、LTをしていただいた皆様、本当にありがとうございました。まだまだ情報量が少なく開発事例も限られていますが、Swiftの情報を発信していくために、第二回Swift勉強会も企画しています。今回お越しいただいた方も、残念ながら来られなかった方も是非お待ちしております。次は私もLTをさせていただく予定ですので、よろしくお願いします。 複数人でSwift開発をするときに気を付けるべきと"個人的に"思ったこと http://www.slideshare.net/fujipara/swift-35749636 TitaniumユーザーがSwiftを触ってみたら http://www.slideshare.net/ryugoo/titanium-swift Optionalの使い方 http://www.slideshare.net/motokinarita7/optional-35774931 Genericsについて http://qiita.com/mo_to_44/items/f9b2678d22ad06599308

こんにちは、上津原です。 先日の 朝日住まいづくりフェア で予約をとり、先週の日曜日にダイワハウスのトライエラボに行ってきました！ トライエラボは水道橋からちょっと歩いたところにダイワハウスの東京本社があり、その横に建っていました。 トライエ エコロジー 中に入ってみると、広々とした空間が広がっていて、ここでは住まいエコロジーに関するクイズに回答しながら、エコロジーについて考えを深めることができます。 手元にはこのような回答ボタンが置かれて3択で答えていく感じなんですが、テレビ番組みたいな気分で楽しく、知識を深められました。 クイズの内容はネタバレになってしまうので言えませんが「へー！」「知らなかった！」と感じるようなものばかりでとても楽しめました。 トライエ シミュレーター トライエシミュレーターでは、指定した地域で今後起こりうる地震を体験したり、過去に起きた地震を追体験することができました。 驚いたのはただ単に震度だけを体感するのではなく、その住所で起きるであろう地震を計算して割り出されてくることでした。 揺れ体感中 すごいぞトライエシミュレーター！ トライエ テクノロジー ここでは、ダイワハウスの断熱や防水の技術などを体感することができます。 一人暮らしのアパート暮らしの身としては「断熱とか、ビフォーアフターで見た事あるけど」くらいでしたが、その効果にはびっくりしました。 あるのとないのとでは結露の有り無しが顕著に見え、一気に「うおー！断熱スゲー！断熱サイコー！」と一気に断熱信者になるほどでした。 トライエ ストラクチャー このコーナーの写真は撮り忘れました…。すみません。 ここでは施設内になんと2階建ての家が建っています。すごいなこのマトリョーシカ形式。 今まで見てきた建材などをはじめ、様々な工法などを見て、触って体感することができます。 いつもバーチャルで家ばかりを見ている身としては「いやー、本物っていいですねー」と感じる次第でした。 トライエ バーチャル そしてこのために来たといっても過言ではない「バーチャル」！ 最後のコンテンツということで期待していたのですが…。 なんと「家を建てる相談をしている人限定」のコンテンツだったので体験はできませんでした…。残念…。 資料館のような楽しさ バーチャルを体感できなかったのは残念でしたが、家ってこういう風にできているのか～。様々な工夫が組み込まれているんだなあとすごくためになる場所でした。 一人暮らしのアパート暮らしで、家を建てることを考えていない私でも、興奮しながら「スゲースゲー」と楽しめるつくりなので、ちょっと遊びに行くくらいでもいいのかなーと感じました。 最後に、もしバーチャルを体験された方がいたらぜひ感想を教えてください。

こんにちは、リッテルラボラトリーの清田です。 以前執筆したこちらの記事 では、情報検索システムの評価の歴史を簡単に振り返るとともに、情報検索システムの評価を考える際には「ユーザー」の存在を抜きにしては考えられなくなったこと、工学的アプローチから科学的アプローチに脱皮していく流れがあることを紹介しました。もともとは工学的システム（＝入力と出力をもつブラックボックス）として評価が行われてきたものの、Webベースの情報検索システムが普及することで、さまざまなレベルのユーザーが存在することを前提に評価することが必要とされてきたという経緯を説明しました。今回は、評価の対象となるユーザーを選ぶ上で、何に気をつける必要があるのかについて紹介します。 評価対象のユーザーを絞り込む 例えば、私たちがHOME'Sの新しい物件検索のユーザー インターフェース（UI）を開発したとします。この新しいUIを現行のUIと置き換えるときには、現行のUIと比較して「どのくらい良くなったのか」を明らかにしなくてはなりません（もし以前より「悪くなった」のであれば、UIの置き換えをすることはできません）。 しかし、「どのようなUIが良いのか」は自明ではありません。「物件の写真を大きく表示してほしい」というユーザーだけではなく、「駅からの距離や築年数などの詳細な情報も表示してほしい」「とにかく画面中に多数の物件を一覧表示してほしい」というユーザーもいます。 そこで、「大部分のユーザーにとっての満足度が高い」ことを、「良いUIである」とみなすことにしましょう。 「大部分のユーザーの満足度」を知るためのベストな方法は、HOME'Sを使う可能性のあるすべての人々に新しいUIと現行UIの両方を試してもらい、それぞれのUIの満足度を調査することです。HOME'Sを使う可能性のあるすべての人々のうち、「新しいUIの方が良い」と答えたユーザーの割合が大きければ（例えば70％であれば）、新しいUIは「良いUIである」と判断してよいでしょう。 しかし、「HOME'Sを使う可能性のあるすべての人々」に試してもらうことは不可能です。「HOME'Sを使う可能性のあるすべての人々」について考えるということは、少なくとも「インターネットを日常的に利用しており、日本国内に居住していて、将来引っ越しを経験する可能性のあるすべての人々」について考えるということです。この調査を実現するのは、以下の理由で不可能です。 「インターネットを日常的に利用している」「日本国内に居住している」「将来引っ越しを経験する可能性のある」という条件を満たす人々の数は、少なくとも千万人単位に上るでしょう。それだけの大規模な調査を実施するには、国勢調査に匹敵する費用がかかることを覚悟しなくてはいけません。 仮にそのような調査が実施したとしても、すべての人々から調査への協力を得ることはできません。忙しいなどの理由で協力を断られる場合も多いでしょう。 「評価の対象としたいすべてのもの」を調べることができないという問題は、ユーザーの満足度調査にかぎった話ではありません。出荷前の缶詰の品質（不良品の割合）を調べるためのベストな方法は、すべての缶詰を開けてみることですが、すべての缶詰を開けてしまうと、売り物がなくなってしまいます。 そこで、「評価の対象としたいすべてのもの」の一部だけを抽出して調査を行うという方法が必要になります。統計学の用語では、「評価の対象としたいすべてのもの」のことを母集団といい、母集団から一部だけを抽出することをサンプリング、サンプリングされたもの（ユーザーや缶詰）のことをサンプル（あるいは標本、試料）と呼びます。サンプル（ランダムに選ばれたユーザーや缶詰）を対象とした評価結果を、母集団を対象とした評価結果とみなそうということになります。 ここで、「サンプルが母集団の性質をどのくらい忠実に表しているか」ということが問題になります。確率的サンプリングという統計ツールが、母集団の性質をできるだけ保存してサンプリングするために大いに役立ちます。たとえば、Excelシートで母集団（たとえばA大学の全学生1万人）のリストをつくり、「1から100までの整数」から一つランダムに選んだのが「65」だったときに、「65行目、165行目、265行目、…、9965行目」の100名を対象として調査を行えば、その評価結果は、「A大学の全学生」の性質をそこそこ表しているとみなしてよいでしょう（この方法を単純無作為サンプリング法と呼んでいます）。 偏りなく評価対象ユーザーを絞り込むことは可能か？ 確率的サンプリングを適用するためには、評価を行う人が母集団のすべての要素について知っていなければなりません。しかし、HOME’Sのような不特定多数のユーザーを対象としたサービスでは、そもそもすべてのユーザーについて知ることはできません。確率的サンプリングが適用できないので、UIに関する評価を行うには、やむを得ず他の方法に頼る必要があります。 よく利用されるのは、以下のような方法です。 ユーザーテスト 募集した実験参加者にUIを触ってもらい、観察やインタビューを通してUIを評価する方法です。調査会社を通じて募集することもあれば、社内で募集することもあります。 ネット調査会社を通じたサーベイ 調査会社が抱えているモニターを対象に、ネット上でUIについてのアンケートをとる方法です。 A/Bテスト サービス上で複数のパターンのUIをランダムに出し分けて、ログデータを通してユーザーの行動の違いを分析する方法です。 しかし、これらの方法では、いずれも選ばれる評価対象ユーザーに偏りが出ることは避けられません。調査会社が接点をもっているユーザーの集合が、「HOME'Sを使う可能性のあるすべての人々」の性質をよく表しているという保証はありません。ネット上での調査の場合は、インターネットの利用頻度の高いユーザーに偏ってしまう傾向があります。社内で実験参加者を募集する場合は、さらに偏ってしまうことは避けられません。A/Bテストの結果は、「HOME’Sを現に利用しているユーザー」の性質はよく表しているといえますが、「新しいUIによって掘り起こされるかもしれない潜在ユーザー」の存在は無視されてしまいます。 結局のところ、UIの評価では、対象となるユーザーをまったく偏りなく絞り込むことは困難であり、評価結果には必然的にある程度の偏りが入ってしまうことは避けられません。よって、得られた評価結果を利用するときは、その限界を理解しておくことが重要です。また、評価結果を研究成果を公表する場合にも、どのように対象ユーザーを選んだかを明示することが求められます。 前回の記事で紹介したKelly博士の著書「Methods for Evaluating Interactive Information Retrieval Systems with Users」では、評価対象ユーザーを選ぶための方法が体系的にまとめられています。昨年、本書の邦訳「インタラクティブ情報検索システムの評価: ユーザの視点を取り入れる手法」が出版されました（私も一部の翻訳を担当しました）。興味をお持ちの方は、ぜひチェックしてみてください。 インタラクティブ情報検索システムの評価: ユーザの視点を取り入れる手法 作者: 上保秀夫,神門典子,阿部明典,加藤恒昭 出版社/メーカー: 丸善出版 発売日: 2013/04/18 メディア: 単行本 この商品を含むブログを見る Methods for Evaluating Interactive Information Retrieval Systems and Users (Foundations and Trends(r) in Information Retrieval) 作者: Diane Kelly 出版社/メーカー: Now Publishers 発売日: 2009/04/30 メディア: ペーパーバック 購入 : 1人 クリック : 6回 この商品を含むブログを見る 過去の記事のリスト ユーザー向け情報サービスの「評価」を考える (第1回) - 株式会社ネクスト エンジニアBlog ユーザー向け情報サービスの「評価」を考える (第2回) - 株式会社ネクスト エンジニアBlog

こんにちは。クリエイターの日運営委員の松尾です。 今回は「クリエイターの日（ http://creators.next-group.jp/ ）」について紹介します。 「クリエイターの日」に関する投稿は今回で3度目になります。 改めて活動の趣旨をおさらいすると 「既存サービス・技術の枠組みを飛び越えた自由な発想からイノベーションの創造」 「各メンバーの興味あるサービス・技術へのチャレンジを通しての個人の成長とネクストの創出力向上」 この2つを目的として、最大7日間の研究・開発を行っています。 今期からは、開催時期と業務が重なって参加できない状況を打開するために、 「四半期内のまとまった7日間ならいつ実施してもよい」 というかたちで運営を行っています。 その結果、第1四半期（1Q）は11チーム（約30名）が活動を予定しています。 今回は、1Q前半に活動している5チームを紹介します。 サービスのローンチに向け、今期も集中して開発に取り組んでいます。 プロフェッショナルな雰囲気… 今期から参加のプロジェクト。 一からWebサイトを作っているようです。 「クリエイターの日」常連のNode.jsチーム。 今回から新メンバーも参加し、完成度は高まってきているようです。 こちらも常連のチーム。 楽しそうなMTGの風景が「クリエイターの日」らしいです。 業務で書いたソースコードの リファクタリングをテーマとして参加してくれています。 サービスのクオリティにこだわる姿勢が素敵です。 今期はどんなプロダクトが生まれるんでしょうか。 後半の6チームについては後日改めて紹介します。

こんにちは、上津原です。 今回はこのブログでもお伝えし続けてきたRoom VRの全体的な概要をお伝えしようと思います。 背景 物件を購入するときに、どうしても物件そのものを確認できず購入をせざるを得ない状況が生まれる。この不便な状況を何とか打開できないだろうか？という考えから開始しました。 目的 上記のような、不便さを解決すること。また、それ以外の価値を見出すことを目的としています。 概要 3Dで作成した物件に、バーチャルリアリティを利用して内覧をし、今まで確認することのできなかった建設前の物件の確認やシミュレーションを行うものです。ヘッドマウントディスプレイであるOculus Riftを装着し、ゲームコントローラを使って自由にバーチャルな物件内を移動、確認することができます。 建設前のもののみならず、遠方の物件の確認や、来店できないユーザーが物件を確認する場合などにも利用できるのではと考えています。 機能概要 3Dで出来た物件をウォークスルーする 時間変更による日照の確認 プレイヤーの身長変更 物件の階数変更 家具の搬入・レイアウト確認 室内電気のON/OFF スクリーンショット ※画面は開発中のものです。 部屋のデータはEpic提供のRealistic Renderingのアセットを利用しています。 スタート画面 物の持ち上げが可能です 身長の変更も可能です。 時間帯により、空の色や光の入り方が変わります。 技術概要 Windows7 Unreal Engine4 Oculus Rift DK1 XBox360コントローラ もともとはUnityでの開発を進めていましたが、レンダリングの美しさからUnreal Engine4に機能を移植し開発をしています。 RoomVR 掲載記事 弊社記事 Unreal Engine 4 関連 OculusRift関連記事 他社記事 ASCII.jp：新築マンションをOculus Riftで内覧！ 未来の物件検索「ROOM VR」を体験してきた (1/2)

サムです。 日本最大級の不動産・住宅情報サイト「HOME'S」のiPhoneアプリ にiOS 7からの新機能である iBeacon を使った試験サービスを開始しました。 『HOME'S』、近距離無線通信技術「iBeacon」を使った不動産O2Oマーケティングの実験開始 本記事では、iBeaconの導入方法や、サービスに導入された試験サービスについて書きます。 iBeaconとは まずiBeaconとは、ご存知のとおり iOS 7以上から提供された新機能の１つで、緯度と経度から取得するGPSとは異なり、Bluetooth Low Energy（以下、BLE）を活用してiOSデバイスの位置情報を読み取るものです。 iBeaconはAppleの商標で、Androidにも同様の技術は存在します。 なので、iBeaconはAppleが提供している機能のことであって「BLE自体のことではない」ということを認識しておくことが大切です。 iBeaconでできること まずiBeaconはiOS 7から提供された新技術であり、iOS 6などの古いOSでは使うことができません。 また、BLEに対応したデバイスでなくてはならないため、iPhone 4S以降が対象になります。 iBeaconでできることは単純で、 リージョン監視：ビーコンの射程から出たり入ったりを観測 相対距離を観測：４パターンによる距離観測 になります。 iBeaconを実装する前に iBeaconは CoreLocation.framework を使います。 そのため、CoreLocation をimportする必要があります。 iBeaconはiOS 7以上の機能になります。 さらにデバイスがBLEに対応しているか確認することも必要になります。 UIDeviceクラスを使い、アプリケーションが動作しているOSの確認をしています。 CLLocationManager isMonitoringAvailableForClass: で Beacon によるリージョン観測が可能であるかチェックします。 ビーコンの測定を開始する ビーコンの計測を行う前に、CLBeaconRegionクラスのインスタンスを生成する必要があります。 6行目：計測したいビーコンのproximity UUID 10行目：計測したいビーコンのmajor 設定したら対象のビーコンのみ計測 11行目：計測したいビーコンのminor 設定したら対象のビーコンのみ計測 ビーコンの測定を開始すると、一定時間ごとにイベントが発生します。 リージョンの監視 ビーコンが出たり入ったりするリージョンの監視は CoreLocation.framework の CLLocationManagerDelegate にある locationManager:didEnterRegion: および locationManager:didExitRegion: を実装します。 相対距離を観測 ビーコンとの相対距離を測定するには CoreLocation.framework の CLLocationManagerDelegate にある locationManager:didRangeBeacons:inRegion: を実装します。 HOME'S アプリにおけるiBeacon 住まい探し専用iPhoneアプリ『HOME'S』 でもiBeaconをつかっています。 使用しているBeaconはAplix社製で、これを不動産会社の店頭に設置しております。 HOME'Sアプリでは、ビーコン対象のユーザに向けて、不動産店舗訪問後にPUSH通知でアンケートを送ることに使っています。 ユーザはPUSH通知からHOME'Sアプリを起動するとアンケート画面が開きます。 ユーザがアンケートに入力することで、不動産店舗はユーザの率直な接客の感想を受け取ることができます。 iBeaconを開発してみて 上記のように、iBeaconの開発はとても単純です。 また、少し前に問題になっていたビーコンの成り代わりも、暗号化や証明書などを使ってセキュリティを担保する仕組みも出来上がってきました。 iBeaconを使う上で気すべきことは次のとおりだと思います。 Bluetoothを ON にするユーザが日本にはまだ少ない WEBリテラシーの低いユーザへの配慮 「Bluetoothを ON にすると電池を消耗する」という会話が行き交う中で、いかにiBeaconのメリットが話題を上回れるかを考えることが一番の課題でした。