2014年09月24日

[Yocto] Intel E38xx Bay Trail用BSPのビルド

新しい研究テーマとしてYocto Projectへの取り組みを始めました。本業の仕事で同じテーマの研究開発をやっているため必要に迫られて始めてしまったものですが、Yocto Projectが組込み分野において将来性の高いテーマであることが判ってきたことも大きな理由です。

Intel Z37xx Bay Trail-Tを搭載したタブレット製品はすでに日本国内でもたくさんの種類の製品が販売されていますが、E38xx Bay Trail-Iを搭載した製品はまだ数が少ないようです。しかし、海外ではすでに多くの種類の製品が登場しています。ARMも本来は省電力性能に優れたコアですが、SoCやSoM上に高性能なGPUを一緒に搭載するケースが増えるに伴い、ここ数年で消費電力が一気に高くなってきました。モバイル機器の場合搭載できるバッテリーの容量に限界があるため、プロセッサの省電力性能は製品設計上の大きな要件となります。ここにきてZ37xxやE38xxなどのBay Tralシリーズを搭載した製品が増えている理由は、これらのプロセッサの処理能力対省電力の性能バランスが非常に優れているからです。しかも、現状多くのARMブロセッサがまだ32ビット・コアなのに対してBay Trailは64ビット・コアです。これからBay Trailを搭載した製品がさらに増えていくでしょうし、タブレットなどのコンシューマ製品だけでなく組込み機器でも採用例が急増していくでしょう。x86アーキテクチャはARMより歴史が長いため、Linuxを代表とするオープンソース・ソフトウェア資産の量と質でも優位性があります。Intel社も組込み分野の取り組みを拡大しているので、Bay Trailとその動向を追いかけていくことは大きな可能性があると思っています。Intel Atom E38xxシリーズ製品のトップページと同プロセッサのデータシートのリンクを下に掲載しておきます。

 Intel(R) Atom(TM) Processor E3800 Product Family (Formerly Bay Trail)
 Intel(R) Atom(TM) Processor E3800: Datasheet

前記事では、Yocto LinuxをQEMU x86ターゲット用にビルドして動作確認を行うまでの手順について解説しました。QEMUは実機ターゲット無しで始められるので手っ取り早くて良いのですが、やはり実機ターゲットを使わないと組込み開発の醍醐味は味わえない気がします。そこで、Yocto Project研究着手の第二段階の作業として、Intel Atom E38xx Bay TrailターゲットでYocto Linuxを動かすことに挑戦します。Intel E38xx Bay Trailプロセッサを搭載したボードはまだ手に入れていないので、取りあえず、本記事にはBSPのビルド手順についてのみ記載します。E38xx用BSPはYocto Projectのサイトで配布されていますが、同BSPのビルド手順が記載されたドキュメントはIntel Embedded Design Centerから入手できます(同サイトの一部のドキュメントやソフトウェアは、ユーザー登録をしないと入手できせん)。それらのリンクを掲載しておきます。
  1. Yocto Project* Setup: Getting Start Guide
  2. Building Intel(R) Atom(TM) Processor E3800 Development Kit Yocto Project Board Support Package (BSP): User Guide

以降の作業は、上記のドキュメントを参照しながら進めていきました。また、Yocto LinuxのIntel E38xx BSPをビルドする過程で一つの問題に遭遇したので、それを解決した際のTips情報も記します。

■ Intel E38xx BSPビルド環境のセットアップ


まず最初に、Yocto Projectの公式サイトからIntel E38xxのBSPパッケージをダウンロードしました。そして、それをディレクトリpoky-daisy-11.0.1(Yocto LinuxのYP Core - Daisy 1.6.1リリースのパッケージファイルyocto-1.6.1/poky-daisy-11.0.1.tar.bz2を展開すると、作成されるディレクトリ)の中へ展開しました。
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.1/machines/valleyisland/valleyisland-1.0-daisy-1.6.1.tar.bz2
$ tar -jxvf valleyisland-1.0-daisy-1.6.1.tar.bz2 -C poky-daisy-11.0.1

このパッケージを展開すると、ディレクトリpoky-daisy-11.0.1の中にmeta-intelというディレクトリが作成されます。このディレクトリの中にIntel E38xx BSPのレシピが格納されています(Yocto Linuxでは、BSPもレシピの集合体です)。

ちなみに、このBSPは複数のIntel製E38xx搭載ボードに対応していますが、その中の一つが「Valley Island Development Kit」という旧称だったらしいです。Audio CodecやEthernet Controllerなどの外付けデバイスを除いて、市販のE38xx搭載ボードはIntel製ボードと同じ回路構成になっているものが多いようです。そのため、このBSPから生成したイメージは大抵のE38xxターゲットでそのまま動作します。

続いて、これからE38xxターゲット用にYocto Linuxのビルドを進めていくので、その作業ディレクトリを作成しました。
$ cd poky-daisy-11.0.1
$ source oe-init-build-env valleyisland

スクリプトoe-init-build-envを実行すると、パラメータで指定したディレクトリが作成され、自動的にそのディレクトリへ移動します。また、同ディレクトリの中に以下の3つのファイルが作成されます。
  • conf/bblayers.conf
  • conf/local.conf
  • conf/templateconf.cfg

参照ドキュメントBに記載されている手順に従って、ここで、conf/bblayers.confに以下のような変更を加えました。
--- bblayers.conf.orig	2014-09-24 10:37:56.647617629 +0900
+++ bblayers.conf 2014-09-24 11:51:08.512524758 +0900
@@ -9,6 +9,9 @@
/home/yuhri/Yocto/poky-daisy-11.0.1/meta \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp \
+ /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel \
+ /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/meta-isg/meta-valleyisland \
+ /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/meta-tlk \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta \

このbblayers.confというファイルには、レシピが格納されてる最上位ディレクトリ(これを「Layer(レイヤ)と呼びます」)の一覧が定義されています。bitbakeコマンドの実行時に、これらのディレクトリがレシピ検索の対象となります。上では、既存のレイヤにmeta-intelディレクトリに格納されている3つのレイヤを追加しています。これによって、E38xx BSPを構成する全レシピがbitbakeコマンドから参照できるようになります。

さらに、conf/local.confにも以下の変更を加えました。
--- local.conf.orig	2014-09-24 10:37:56.643617498 +0900
+++ local.conf 2014-09-24 10:50:20.594415847 +0900
@@ -17,18 +17,18 @@
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
#
-#BB_NUMBER_THREADS ?= "4"
+BB_NUMBER_THREADS ?= "8"
#
# Default to setting automatically based on cpu count
-BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
+#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
#
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
-#PARALLEL_MAKE ?= "-j 4"
+PARALLEL_MAKE ?= "-j 8"
#
# Default to setting automatically based on cpu count
-PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
+#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.
@@ -55,7 +55,7 @@
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
-MACHINE ??= "qemux86"
+MACHINE ??= "valleyisland-64"

#
# Where to place downloads
@@ -251,3 +251,8 @@
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"
+
+# The meta-valleyisland contains support for Intel HD Audio. However, HD Audio
+# driver is dependent on gstreamer plugins and ffmpeg plugins to work properly.
+# These gstreamer plugins require license flags in order to be included in the build.
+LICENSE_FLAGS_WHITELIST = "commercial"

local.conf内に存在する「MACHINE ??= "valleyisland-64"」という設定項目がビルド対象ターゲットの定義です(local.confが作成された段階では、本項目は常に「qemux86」に設定されています)。Yocto LinuxのBSPには必ずターゲット定義ファイルというものが格納されています。E38xx BSPのターゲット定義ファイルは以下の2つです。
  • meta-intel/meta-isg/meta-valleyisland/conf/machine/valleyisland-32.conf
  • meta-intel/meta-isg/meta-valleyisland/conf/machine/valleyisland-64.conf

ファイル名から判るように、上記はそれぞれ32ビットと64ビット版Linuxのシステム構成です。これらのファイルの中から選択して、そのファイル名(「.conf」を除いた)を「MACHINE」に設定すると、bitbakeコマンドはターゲットを確定できるようになります。

また、local.conf内のBB_NUMBER_THREADS PARALLEL_MAKEの値をいずれも「8」に変更していますが、その理由は、開発ホストのUbunutを動かしているVMware仮想マシンのプロセッサコア数を4に変更したからです。

■ Intel E38xx BSPのビルド


Intel E38xx BSPのビルド環境が整ったので、ビルド対象イメージとしてcore-image-satoを指定して、その全ソースをダウンロードしました。
$ bitbake -c fetchall core-image-sato

しかし、下のようなエラーメッセージが出力されて、この処理は途中で停止してしまいました(エラー停止したのは、10分以上処理が進んだ後でした)。
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: repository '/home/ilab/linux-yocto/linux-yocto-3.10' does not exist

ERROR: Function failed: Fetcher failure for URL: 'git:///home/ilab/linux-yocto/linux-yocto-3.10;protocol=file;nocheckout=1;branch=standard/base,meta,valleyisland-io-2.0;name=machine,meta,valleyisland-io'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.10.43+gitAUTOINC+cf4d9720de_aa677a2d02-r0/temp/log.do_fetch.13046
ERROR: Task 19 (/home/yuhri/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 628 tasks of which 0 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_fetch
Summary: There were 14 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

上のエラーメッセージの一部の文字列を指定してgrep検索すると、meta-intel/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappendというファイルがヒットしました。そこで、このファイルの内容を眺めていると、その中に以下のような記述の誤りが存在することに気づきました。
--- linux-yocto_3.10.bbappend.orig	2014-06-18 20:23:30.000000000 +0900
+++ linux-yocto_3.10.bbappend 2014-09-24 12:22:41.806418515 +0900
@@ -1,35 +1,35 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = valleyisland-32 #
#############################
COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
KMACHINE_valleyisland-32 = "valleyisland-32"
KBRANCH_valleyisland-32 = "standard/base"
KERNEL_FEATURES_valleyisland-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci"

LINUX_VERSION_valleyisland-32 = "3.10.43"
SRCREV_machine_valleyisland-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_valleyisland-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_valleyisland-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_valleyisland-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

#############################
# MACHINE = valleyisland-64 #
#############################
COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
KMACHINE_valleyisland-64 = "valleyisland"
KBRANCH_valleyisland-64 = "standard/base"
KERNEL_FEATURES_valleyisland-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_valleyisland-64 = "3.10.43"
SRCREV_machine_valleyisland-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
-SRCREV_meta_valleyisland-64 = "cf4d9720de1c0f64402de70833dd6ccc12d04a3f"
+SRCREV_meta_valleyisland-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_valleyisland-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

-SRC_URI_valleyisland-64 = "git:///home/ilab/linux-yocto/linux-yocto-3.10;protocol=file;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"
+SRC_URI_valleyisland-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

module_autoload_i2c-dev = "i2c-dev"

SRCREV_meta_valleyisland-64SRC_URI_valleyisland-64はGit経由で取得するソースのリビジョンとURIの定義のようですが、オリジナルのlinux-yocto_3.10.bbappendでは、これらの値が前方に存在するSRCREV_meta_valleyisland-32SRC_URI_valleyisland-32と異なっています。32ビットと64ビット版BSPのソースは一括してGitリポジトリ上で管理されているはずなので、これらは同じ値でなければならないはずです。修正前のSRC_URI_valleyisland-64の設定値は、ローカルなディレクトリからソースを取得するための定義のように見えます(本BSPのメンテナーが開発中の暫定的な記述を残したまま、このファイルをGitリポジトリへCommitしてしまったのでしょう)。そのため、E38xx BSPの64ビット版ソースの一部を取得する処理で停止してしまったようです。

meta-intel/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappendに上の修正を加えた上で、再度「bitbake -c fetchall core-image-sato」コマンドを実行すると、ソースのダウンロード処理は最後まで通って正常に終了しました(全ソースをダウンロードするのに、エラー前後の時間を合計して25分かかりました)。

ソースのダウンロードが完了したので、core-image-satoイメージのビルドを実行しました。
$ time bitbake core-image-sato
Loading cache: 100% |###############################################################| ETA: 00:00:00
Loaded 1243 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.22.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "valleyisland-64"
DISTRO = "poky"
DISTRO_VERSION = "1.6.1"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-intel
meta-valleyisland
meta-tlk = "<unknown>:<unknown>"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/eglibc/2.19-r0/packages-split/nscd/usr/sbin/nscd' has relocations in .text
NOTE: validating kernel config, see log.do_kernel_configcheck for details
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/bin/quotasync' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/bin/quota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/rpc.rquotad' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quotaon' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quot' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/setquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/convertquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/xqmstats' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/repquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quotastats' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quotacheck' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/edquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/warnquota' has relocations in .text
WARNING: The postinstall intercept hook 'update_pixbuf_cache' failed (exit code: 139)! See log for details!
WARNING: The postinstalls for the following packages will be postponed for first boot: gdk-pixbuf-loader-xpm gdk-pixbuf-loader-gif gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
WARNING: The postinstall intercept hook 'update_font_cache' failed (exit code: 139)! See log for details!
WARNING: The postinstalls for the following packages will be postponed for first boot: liberation-fonts
NOTE: Tasks Summary: Attempted 4925 tasks of which 668 didn't need to be rerun and all succeeded.

Summary: There were 18 WARNING messages shown.

real 199m7.092s
user 556m26.375s
sys 121m47.961s

いくつかの警告メッセージが出力されましたが、ビルド処理は正常に終了しているようです(ビルドにかかった時間は3時間19分でした)。

下のとおり、ブートやrootfsのイメージはちゃんと生成されているようでした。
$ ls tmp/deploy/images/valleyisland-64
bootx64.efi
bzImage
bzImage--3.10.43+git0+199943142f_aa677a2d02-r0-valleyisland-64-20140924035205.bin
bzImage-valleyisland-64.bin
core-image-minimal-initramfs-valleyisland-64-20140924035205.rootfs.cpio.gz
core-image-minimal-initramfs-valleyisland-64-20140924035205.rootfs.manifest
core-image-minimal-initramfs-valleyisland-64.cpio.gz
core-image-minimal-initramfs-valleyisland-64.manifest
core-image-sato-valleyisland-64-20140924035205.hddimg
core-image-sato-valleyisland-64-20140924035205.iso
core-image-sato-valleyisland-64-20140924035205.rootfs.ext3
core-image-sato-valleyisland-64-20140924035205.rootfs.manifest
core-image-sato-valleyisland-64.ext3
core-image-sato-valleyisland-64.hddimg
core-image-sato-valleyisland-64.iso
core-image-sato-valleyisland-64.manifest
modules--3.10.43+git0+199943142f_aa677a2d02-r0-valleyisland-64-20140924035205.tgz
modules-valleyisland-64.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

E38xxを搭載したターゲットボードをまだ入手できていないので、ここまでで同プロセッサ搭載ターゲット用のYocto Linuxのビルド作業は一旦終了です。近いうちにターゲットを入手する予定なので、実機環境が整ったら、今回の作業で生成したイメージを使ってターゲットによる動作確認をやるつもりです。
posted by とみやん at 09:42| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年09月19日

Yocto Projectの研究を始めました

9月も後半に入って東京はさらに涼しくなってきました。残暑はほとんど感じられず本当に涼しい夏でした。私はまだ一日中半袖の服装で過ごしていますが、常駐先の会社に通うために朝部屋を出ると肌寒く、ここ数日は長袖の服がほしくなってきました。東京へ来たのは8月初旬だったので半袖の衣服をまったく持ってきません。一度塩尻に戻って秋冬用の服を持ってくるか、こちらで長袖の服を買うかしなければなりません。東京がこの涼しさなら信州はさらに涼しいはずで、もはや完全に秋の気候になっているのでないかと思います。

さて、またしても新しい研究テーマに遭遇して、仕事の関係でどうしても他より優先してこれに取り組まざるをえなくなりました。Yocto Projectがそれです。Yocto Projectは組込みLinuxベースのシステム開発の容易化と様々なアーキテクチャー間で移植できるようにすることを目標に発足したオープンソース・プロジェクトです。BeagleBoardやRaspberry Piに対応し、最近だとGalileo(Intelが2013年10月に発表した、Quark X1000を搭載したArduino互換開発ボード)へも移植されています。いままで半導体ベンダーやシステムベンダー、オープンソースコミュニティなどがそれぞれ独自に組込みLinuxディストリビューションを開発しており、これら間の連携はほとんどありませんでした。このような状況を改善するために、複数の企業やコミニティーが協力し合って組込みLinuxのスタンダードを創ろうとしているのがYocto Projectです。

Yocto Projectが発足したのは2010年ですが、私が本格的に組込みLinuxに取り組み始めたのも丁度同じ時期です。Yocto ProjectではOpenEmbeddedというビルドシステムが採用されていますが、これはAngstrom Linuxでも使われています。以前BeagleBoardでAngstrom Linuxを動かしたことありますが〔2012/12/29の記事〕、このときにAngstrom Linuxのサイトに情報とリンクが掲載されているのを見つけのがYocto Projectについて知った最初です。

じつは、本業の仕事でもいまYocto Linuxの研究開発をやっています。本業の仕事の関係でYocto Linux周辺の色々な情報を調べていくうちに、IntelのE38xx(Bay Trail-I)シリーズが組み込み用途で有望なプロセッサであることが判ってきました。Intel E38xx Atomシリーズは最新版省電力コアのSoCプロセッサで、多くのタブレットで採用されているZ37xxシリーズ(Bay Trail-T)と合わせて、Intelはいまこの2種類のプロセッサを組み込み分野向けに強力にアピールしています。Bay Trailは64ビッド・プロセッサで、その省電力性能は他社のARMコア・プロセッサを凌駕しています(あの超省電力Haswellコアを製造している半導体メーカー・トップのIntel製のプロセッサですから)。x86プロセッサなのでMicrosfotのWindows 8は当然動きます。Lenovo、ASUS、AcerなどがZ37xxを搭載した多様なタブレット製品を販売しています。また、同プロセッサを搭載したMinnowBoard MAX(BeagleBoardやPandaBoardを企画・製造したCircuitCoによる最新ボード、価格はUS$99)も登場して話題を集めています。さらに、Googleと協力しながらIntelが自ら開発を主導してAndroidをBay Trailへ移植し、同OSを搭載したタブレットもすでに登場しています。ASUSのMeMO PadFonepadがそれで、ユーザーの評価も高いようです。

 【西川和久の不定期コラム】ASUS「MeMO Pad 7」 〜Bay Trail-Tを搭載し、小型軽量化した7型Androidタブレット - PC Watch
 ASUS「MeMO Pad」が人気タブレットの1・2位を独占する理由とは? 日経トレンディネット
 【笠原一輝のユビキタス情報局】Bay Trailが実現する、WindowsとAndroidが共存するタブレット 〜x86版Androidで互換性の問題が非常に少ない理由 - PC Watch

Intelのアナウンス情報によると、64ビット版Androidの移植も順調に進んでいるようです。64ビット版AndroidはARMとx86版がほぼ同時にリリースされそうです。このようにBay Tailを周る動きが非常に活発なため、いま組込み業界の企業やエンジニアもこのプロセッサに注目しています。

余談になりますが、Intelはここ数年組込み分野向けのプロセッサやソフトウェア開発に非常に力をいれているようです。Atomシリーズを代表として、モバイル機器向けのプロセッサを次々に発売したり、組込みLInuxやAndroidの開発にも大きなエンジニアリング・リソースを投入したりしています。上の3番目の記事には、GoogleよりIntelの方が主導権を持ってx86版Androidの開発を進めている状況がうかがえる内容が書かれていて、なかなか興味深いです。PCの出荷台数が減少の一途を辿っているのに対してモバイル機器の出荷台数は増大しています。いいまでIntelはPC向けのプロセッサを主力製品として展開しており、モバイル分野ではARMコア・プロセッサを製造している半導体メーカーにシェア拡大を許してきましたが、ここに来て、モバイル分野でのシェアを獲得するためIntelは大攻勢に出ているようです。組込み業界の企業やエンジニアは、ARMコア・プロセッサを主力製品に持つ半導体メーカーとその周辺の動きをウォッチしていれば済んでいましたが、いまやIntelも組込み分野のメインプレーヤの一人になっています。これからはIntelの動向もウッチしていかないと、組込み分野の最新トレンドをフォローすることは難しくなるのではないでしょうか(すでに、そうなっているようですが・・・)。マイコン創世記からIT業界で仕事をしている私にとってはx86アーキテクチャの方が馴染みが深いですし、同じように感じているベテランのエンジニアは多いじゃないかと思います。「ARMからx86への回帰」が大きな潮流になりつつあるような気がしてなりません。

研究着手の事始めとして、取りあえず、Yocto Projectが配布している組込みLinuxディストリビューションのビルドに挑戦してみました。Yocto Projectはオープンソースプロジェクトなので、その成果は公式サイトですべて公開されています。Yocto Projectが配布しているディストリビューションにはQEMU(オープンソースのプロセッサエミュレータ)用のBSP(Board Support Package)が収納されているそうです。下調べで得た情報から、このQEMUターゲット向けのビルドはすぐに始めることができ、Linuxホスト上で簡単に動作確認ができるらしいです。QEMUターゲット用Yocto Linuxのビルドと動作テストを実際にやってみたので、以降にその作業記録を書いていきます。Yocto Projectの公式サイトに掲載されている「Yocto Project Quick Start 1.6.1」というページの内容を参照にしながら、以下の作業を進めていきました。開発ホストOSはUbuntu 12.04.1 32ビット版を使いました(Yocto Linuxが対応しているホスト・ディストリビューションの一覧はこちらに掲載されています。また、64ビット版Ubuntuを使わなかった理由については後日別の記事で説明します)。

■ Yocto Linuxビルド環境のセットアップ


まず最初に、Yocto Linuxをビルドするのに必要となるUbuntuホスト側のパッケージをインストールしました。
$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath libsdl1.2-dev xterm

次に、Yocto Projectの公式サイトからYocto Linuxディストリビューションの最新バージョンYP Core - Daisy 1.6.1のパッケージファイルをダウンロードして、それを展開しました。
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.1/poky-daisy-11.0.1.tar.bz2
$ tar -jxvf poky-daisy-11.0.1.tar.bz2
$ cd poky-daisy-11.0.1

上のパッケージを展開すると、「poky-daisy-11.0.1」というディレクトリが作成されます。Yocto Linuxの全ソースはこの中に格納されています(正確には、このディレクトリに格納されているのはソースではなくレシピです)。

■ QEMU x86ターゲット用ビルド環境の準備


これ以降、QEMUをターゲットとしてYocto Linuxをビルドしていきますが、その前に、ビルド用の作業ディレクトリを作成しました。この処理のためのoe-init-build-envという専用シェルスクリプトが用意されているので、これを利用してQEMUターゲット用ビルド作業ディレクトリを作成しました。
$ source oe-init-build-env qemux86
You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to use a
different MACHINE (target hardware) or enable parallel build options to take
advantage of multiple cores for example. See the file for more information as
common configuration options are commented.

The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
http://www.openembedded.org/

You had no conf/bblayers.conf file. The configuration file has been created for
you with some default values. To add additional metadata layers into your
configuration please add entries to this file.

The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
http://www.openembedded.org/



### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
adt-installer
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

oe-init-build-envはYocto Linuxのビルド時に参照される環境変数の設定も行っています。このスクリプトを実行すると、パラメータで指定したディレクトリが作成された後、自動的にそのディレクトリへ移動します。ディレクトリを指定しないで実行した場合は、デフォルトで「build」という名前のディレクトリが作成されるようになっています。32ビット版QEMU x86をターゲットとしてYocto Linuxをビルドするので、上では、明示的に作業ディレクトリの名前を指定しました。

oe-init-build-envスクリプトで作成されたディレクトリの中身を確認すると、以下の3つのファイルが格納されていました。これらのファイルも同スクリプトによって自動的に作成されるようです。
  • conf/bblayers.conf
  • conf/local.conf
  • conf/templateconf.cfg

上のうちlocal.confの中に、ターゲットのビルド時に適用される全般的な共通設定項目が定義されています。このファイルの中を覗くと、下のような定義が存在することに気づくでしょう。
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "qemux86"

この「MACHINE」という設定項目がビルド対象ターゲットの定義です。上記のとおり、すでに「qemux86」となっているので、このままビルドすれば32ビット版QEMU x86用イメージを生成することができますが、その前にlocal.confに以下のような変更を加えました。
--- local.conf.orig	2014-09-18 13:54:55.989634472 +0900
+++ local.conf 2014-09-18 13:56:15.779639842 +0900
@@ -17,18 +17,18 @@
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
#
-#BB_NUMBER_THREADS ?= "4"
+BB_NUMBER_THREADS ?= "4"
#
# Default to setting automatically based on cpu count
-BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
+#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
#
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
-#PARALLEL_MAKE ?= "-j 4"
+PARALLEL_MAKE ?= "-j 4"
#
# Default to setting automatically based on cpu count
-PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
+#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.

Yocto Linuxのビルドはbitbakeというコマンドを用いて行いますが、上の「BB_NUMBER_THREADS」と「 PARALLEL_MAKE」はbitbakeコマンドの並列スレッド数とmakeコマンドの並列ジョブ数を決める設定項目です(makeはbitbakeから呼び出されます)。これらを適切な値に設定すると、ターゲットイメージのビルド時間を大きく短縮することができます。ググって調べると、makeの並列ジョブ数の適切値については以下の2つの説が存在するようです。
  1. 論理プロセッサコア数と同じ値にする
  2. 論理プロセッサコア数の2〜3倍の値にする
上の変更前のlocal.confの内容は前者の説に従った設定になっています。今回は論理コアを2個に設定したVMware Fusionの仮想マシン上で開発ホストOSのUbuntuを動かしています。私の経験によると、論理プロセッサのコア数が2の場合はmake並列ジョブ数を4に設定するのが最適であるという結果を得ています。local.conf内の「BB_NUMBER_THREADS」と「 PARALLEL_MAKE」の値をいずれも「4」に変更したのは、この理由からです。

■ QEMU x86用ターゲットイメージのビルド


これで、Yocto Linuxをビルドするための準備が整いました。oe-init-build-envスクリプトを実行したときのメッセージにも表示されていますが、Yocto Linuxの配布パッケージの中にはいくつかの定義済みイメージ・レシピが収納されています。「Yocto Project Quick Start 1.6.1」に記載されている内容に従って、最初にcore-image-sato(Sato Mobile Desktop)というイメージをビルドしてみました。これはモバイル機器向けQt/X11 GUIイメージです。「Yocto Project Quick Start 1.6.1」には、「bitbake -k core-image-sato」というコマンドによってターゲットイメージを生成できると書いてありますが、ここでは、先に次のコマンドを実行しました。
$ bitbake -c fetchall core-image-sato

ビルド対象イメージのcore-image-satoには、Linuxカーネル、X11、Qtなどサイズの大きいコンポーネントが構成要素として含まれています。「bitbake -k core-image-sato」というコマンドは、これらのソースを自動的にダウンロードしながらコンパイルとリンクを行い、最終的なターゲットイメージを生成します。core-image-satoの全構成要素のソースをまとめると相当なボリュームになるので、ソースのダウンロードとビルドの工程は分離した方が賢明です。上のコマンドによって、ターゲットイメージのビルドに必要なソースの取得だけを行うことができます。ソースのダウンロードにかかる時間は当然インターネット回線の速度に依存します(WiMAX 2+モバイルルータ経由の回線でこの処理を行いましたが、約40分かかりました。

全ソースをダウンロードしたら、いよいよYocto Linuxのターゲットイメージをビルドできます。以下のコマンドを実行して、ターゲットイメージcore-image-satoをビルドしました。
$ bitbake core-image-sato

ターゲットイメージのビルドに要する時間は、その中に含まれるコンポーネントの数とボリュームによって大きく変化します。また、開発ホストPCの性能にも依存します。私の環境では、core-image-satoのビルドになんと約18時間もかかかってしまいました(Intel Core i5 1.4GHz HyperThreading 2コア、メモリ2GB、ストレージ SSDという構成のVMware仮想マシンの場合)。ググって得た下調べ情報によると、Yocto Linuxのビルドは時間がかかると書かれているページが結構ヒットしたので覚悟はしていたのですが、ビルド時間に18時間にもなるとは予想をはるかに超えていました(さすがに18時間はかかりすぎではないかという気がので、これは計測結果では正確ではないかもしれません。夕方からビルドをスタートして、外部モニタの電源を切った状態で就寝してしまったので、もしかすると途中でMacがスリープ状態に入っていた可能性があります)。やはりクロック速度2.0GHz以上、HyperThreading 4コア以上のプロセッサを搭載したPCや仮想マシンでないと、X11やQtのビルドは厳しいということを思い知りました(この現実に直面して、俄然MacBook Pro Retinaが欲しくなってきました。MacBook Proに搭載されているプロセッサはすべて2.0GHz以上でMacBook Airのそれよりずっと高速だからです)。

■ QEMU x86用ターゲットイメージの動作確認


ターゲットイメージcore-image-satoのビルドが終わったので、さっそくその動作確認をやってみしました。以下のコマンドによって、QEMUでターゲットイメージを起動することができます。
$ runqemu qemux86

QEMUが起動すると新しいウインドウが開き、その中にお馴染みのLinuxのブートシーケンスが表示されました。そして、数秒後にQEMUウインドウの画面は下のような表示に変わりました。
UBShot_20140919_093147-Building_Yocto_Linux_1.6.1_for_QEMU_x86-1280x960
VMwareと同じように、Yocto Linuxのターゲットイメージcore-image-satoはQEMUの仮想マシン上で実行されています(実際の私の開発環境は、Mac OS X ⇒ VMware Fusion上のUbuntu ⇒ QEMU上のYocto Linuxと三重の画面の入れ子になっているので面白いです)。QEMU内のDesktopウィンドウの左上の三角をクリックすると、その画面は下のように変わりました。
UBShot_20140919_094437-Building_Yocto_Linux_1.6.1_for_QEMU_x86-640x480.png
この画面に表示されているのがSato Mobile Desktopの全アイテムのようです。ゲームまで在るのは面白いですが、かなりシンプルな構成ですね。

この中に「X11VNC Server」というアイコンが存在していますが、これはVNCサーバーみたいです。こいつがちゃんと動くのか興味があったので試してみました。まず、このSato Mobile Desktopの「X11VNC Server」アイコンをクリックして実行状態にしました。そして、Ubuntu側で別のターミナル・ウィンドウを開き、そこ中から以下のコマンドを入力しました。
$ sudo apt-get install vncviewer
$ vncviewer 192.168.7.2

最初のコマンドで、TightVNCというVNCクライアントのパッケージ(「vncviewer」はxtightvncviewerのエイリアス・パッケージ名です)をUbuntuへインストールしています。その後、QEMU上で動いているSato Mobile DesktopのVNCサーバーのIPアドレスを指定して、TightVNCを起動しています(コマンド「runqemu qemux86」でQEMUを起動した際に表示されるIPアドレスが、VNCサーバーのIPアドレスに相当します)。下のように、ちゃんとSato Mobile DesktopのVNCサーバーに接続できることを確認できました。
UBShot_20140919_094821-Building_Yocto_Linux_1.6.1_for_QEMU_x86-1280x960
これで、QEMU x86ターゲットのYocto Linuxのビルドと動作確認は終わりです。core-image-satoイメージのビルドにやたらと時間がかかることを除いて、特に問題に遭遇することはありませんでした。組込みLinuxのビルドと動作確認では大抵何かしらの問題に遭遇して、その解決方法をGoogle先生に教えてもらたりするのですが、今回の作業ではそれはなくスムーズにゴールまで到達できました(こういう問題にぶつかりながらゴールに辿り着いた瞬間に味わえる感激が組込みLinux開発の醍醐味なので、スムーズすぎると何だか物足りないですね)。QEMU x86はYocto Linuxのリファレンスターゲットらしいので、そのBSPはしっかりメンテナンスされているのでしょう。他の実機ターゲットでは、こういう風にスムーズにいくことはないんじゃないかと想像します。

近いうちにBay Trailプロセッサを搭載したターゲットボードを入手する予定なので(ググって情報収集をしていますが、Bay Trail搭載ハードはMini-ITXボードやベアボーンの方が入手性が良いみたいです)、そのときに改めてBay Trail向けYocto Linuxのビルドに挑戦します。また、BeagleBoardやPandaBoardへも移植されているようです。この2つはすでに入手済みなので、これらのボードでもYocto Linuxを動かしてみるつもりです。本業の仕事でYocto Linuxの研究開発をやっているので、こちらで得られた情報もこれから公開していくつもりです(守秘義務に触れるものは公開できないので、パブリックな情報やTipsなどになりますが・・・)。Yocto Linuxを使って特定用途向けのシステムを構築するにはレシピのカスタマイズや作成が必須の作業になりますが、これらの情報もぜひ提供したいと思っています。これからしばらくYocto Linuxの記事が続くことになるでしょう。

【2014/09/22 追記】

core-image-satoというイメージを使ってYocto Linuxのビルドと動作確認を行いましたが、Yocto Linuxの配布パッケージにはこれ外にもいくつかイメージ・レシピが収納されています。利用可能なイメージ・レシピの一覧は次のコマンドで確認することができます。
$ bitbake-layers show-recipes "*-image-*"
Parsing recipes..done.
=== Available recipes matching *-image-*: ===
core-image-base:
meta 1.0
core-image-clutter:
meta 1.0
core-image-directfb:
meta unknown (skipped)
core-image-full-cmdline:
meta 1.0
core-image-lsb:
meta unknown (skipped)
core-image-lsb-dev:
meta unknown (skipped)
core-image-lsb-sdk:
meta unknown (skipped)
core-image-minimal:
meta 1.0
core-image-minimal-dev:
meta 1.0
core-image-minimal-initramfs:
meta 1.0
core-image-minimal-mtdutils:
meta 1.0
core-image-rt:
meta 1.0
core-image-rt-sdk:
meta 1.0
core-image-sato:
meta 1.0
core-image-sato-dev:
meta 1.0
core-image-sato-sdk:
meta 1.0
core-image-testmaster:
meta 1.0
core-image-testmaster-initramfs:
meta 1.0
core-image-weston:
meta 1.0
core-image-x11:
meta 1.0

Sato Mobile DesktopはQt/X11ベースGUI環境なので、いじくり回して楽しめます。せっかく動かすならこういうの面白味のある奴が良いのですが、core-image-satoはビルドにとても時間がかかるのがネックです。もっと手っ取り早くYocto Linuxの動作確認までやりたい場合は、core-image-minimalというイメージを使うことをお勧めします。これはコンソール・ベースのCLI環境で最小構成のイメージなので、ビルド時間を短縮できます。実際に、このcore-image-minimalのビルドと動作確認をやってました。まず以下のコマンドによって、core-image-minimalのビルドに必要な全ソースをダウンロードしました。
$ time bitbake -c fetchall core-image-minimal
Loading cache: 100% |###############################################################| ETA: 00:00:00
Loaded 1222 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.22.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "i586-poky-linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.6.1"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp = "<unknown>:<unknown>"

NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 166 tasks of which 164 didn't need to be rerun and all succeeded.

real 0m8.740s
user 0m3.984s
sys 0m4.008s

「time」コマンドを付加して時間を計測してみましたが、core-image-minimalのソース取得は一瞬で終了しました。上のメッセージを読むと、実際には2つの処理タスクしか実行されていないことが判ります。core-image-minimalを構成する全ソースはcore-image-satoの取得済みソースに含まれているからじゃないかと思います。

続いて、core-image-minimalイメージのビルドを行いました。
$ time bitbake core-image-minimal
Loading cache: 100% |###############################################################| ETA: 00:00:00
Loaded 1222 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.22.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "i586-poky-linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.6.1"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp = "<unknown>:<unknown>"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 1791 tasks of which 1786 didn't need to be rerun and all succeeded.

real 1m19.636s
user 0m34.502s
sys 0m28.878s

こちらもたった1分で終わってしまいました。core-image-satoで全レシピがすでにビルド済みなので、レシピから生成済みのパッケージを組み合わせてcore-image-minimalのrootfsを構築する処理だけが実行されたようです。ちなみに、bitbakeコマンドによって生成されるカーネルやrootfsのイメージは<build_dir>/tmp/deploy/images/qemux86というディレクトリに格納されます。
$ ls tmp/deploy/images/qemux86
bzImage
bzImage--3.14+git0+09424cee64_f9048769cc-r0-qemux86-20140918062211.bin
bzImage-qemux86.bin
core-image-minimal-qemux86-20140922002131.rootfs.ext3
core-image-minimal-qemux86-20140922002131.rootfs.manifest
core-image-minimal-qemux86-20140922002131.rootfs.tar.bz2
core-image-minimal-qemux86.ext3
core-image-minimal-qemux86.manifest
core-image-minimal-qemux86.tar.bz2
core-image-sato-qemux86-20140918062211.rootfs.ext3
core-image-sato-qemux86-20140918062211.rootfs.manifest
core-image-sato-qemux86-20140918062211.rootfs.tar.bz2
core-image-sato-qemux86.ext3
core-image-sato-qemux86.manifest
core-image-sato-qemux86.tar.bz2
modules--3.14+git0+09424cee64_f9048769cc-r0-qemux86-20140918062211.tgz
modules-qemux86.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

core-image-minimalのイメージがビルドができたので、それをQEMUで起動してみました。core-image-satoと同じ「runqemu qemux86」というコマンドでQEMUを起動できます。
UBShot_20140922_124157-Building_Yocto_Linux_1.6.1_for_QEMU_x86-1280x960
QEMUを使って動作確認までできるのはすごく便利そうです。実機ターゲットがなくても、大抵のアプリはデバッグができてしまうからです。実機固有のハードウェアに依存するアプリは無理ですが、QEMU仮想マシンはEthernetもエミュレートしてくれるので、ネットワーク・アプリまでQEMU上で動かすことが可能です。VMwareほど完成度の高い仮想環境ではないみたいですが、結構広く使われているので、十分に実用に耐えられる環境なのではないかと思います。QEMUはx86だけでなくARMやPowerPCにも対応しているので、組込みLinuxでこそ真価を発揮するエミュレータです。組込みLinuxの開発環境にQEMUを統合化したことは、Yocto Projectによる大きな成果の一つだと言えます。


posted by とみやん at 10:20| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年09月16日

Xcode 5.1.1のMountain Lionへのインストール

東京も曇ってすっきりしない日々が続いてましたが、先週末の連休からやっと晴れて良い天気になりました。例年ならこの時期は残暑が厳しく蒸し暑いのですが、今年はそれほど暑さが辛くありません。湿度が低いようで、晴れても爽やかさを感じられます。本当に夏らしい気候だったのは、東京では7月中旬〜8月中旬の一ヶ月だけでした。9月も残り2週間ですが、秋の兆しは早く訪れそうです。

さて、前記事に書いたとおり、新型のMacBook Air 11-inchを手に入れたので、いまこれにiOS開発環境を構築中です。ADC(Apple Develper Connection)で配布されているXcodeは、そのリリース時点の最新バージョンと一つ前のバージョンのOS Xに対応しています。MBA11のOSはMountain Lionにダウングレードしたのは、Yosemiteの評判が良くなく開発環境として使うことに不安があったからですが、最新版のXcodeがMountain Lionに対応していたことも判断基準になりました。現時点のXcodeの最新バージョンはXcode 5.1.1ですが、これはOS X YosemiteとMountain Lionで使うことができます。Xcode 5.1.1をMBA11へインストールしたので、自分の備忘録を兼ねて、その作業記録を書いておきます。

MBA11にiOS開発環境を構築するにあたって、Xcode 5.1.1より先にXcode 4.6.3をインストールしました。この2つのバージョンを共存させて併用したかったからです。Xcode 5.1.1はiOS 7.0, 7.1、Xcode 4.6.3はiOS 5.0〜6.1開発用として使い分けていくつもりです。去年Mac mini(Mountain Lion搭載)へXcode 4.6.3を入れましたが、このときと完全に同じ手順でインストールを行いました。Xcodeアプリを「アプリケーション」フォルダへコピーした後、追加コンポーネントとドキュメントのインストールを行い、最後に他のバージョンのXcodeからiOS 5.0, 5.1, 6.0 SDKとMac OS X 10.6 SDKをコピーしました(2014/07/08の記事を参照)。下のスクリーンショットが、Xcode 4.6.3をインストールしてiOS/Mac OS X SDKを追加した後のDeveloper Information([ユーティリティ]>[システム情報]の「Developer」カテゴリ)表示です。
SCShot_140915_0001-Installing_Xcode_4.6.3_on_MountainLion-751x520
上の作業が済んだ後、Xcode 4.6.3のアプリファイルXcode.appXcode_463.appへリネームした上で、Xcode 5.1.1のインストールを始めました。

まずはXcode 5.1.1のアプリファイルを「アプリケーション」フォルダへコピーしました。
SCShot_140915_0007-Installing_Xcode_5.1.1_on_MountainLion-612x421.png
コピーが終わった後Xcode 5.1.1を初めて起動すると、ライセンス同意要求のウィンドウに続いて、下のようなウィンドウが表示されました。
SCShot_140915_0011-Installing_Xcode_5.1.1_on_MountainLion-479x162.png
このウィンドウの「Install」ボタンを押すと、追加コンポーネントのインストールが始まりました。
SCShot_140915_0013-Installing_Xcode_5.1.1_on_MountainLion-479x162.png
この処理が終了すると、XcodeのWelcomeウィンドウが表示されました。
SCShot_140915_0014-Installing_Xcode_5.1.1_on_MountainLion-801x472
Xcode 5.1.1が起動することを確認したら、すぐに[Xcode]>[Preferences]メニューの[Downloads]タブ画面を開き、コンポーネントとドキュメントの追加インストールを行いました。
SCShot_140915_0017-Installing_Xcode_5.1.1_on_MountainLion-750x498
SCShot_140915_0028-Installing_Xcode_5.1.1_on_MountainLion-750x498
すべてのコンポーネントを追加した後のXcode 5.1.1のDeveloper Informationは下のような表示になりました。
SCShot_140915_0020-Installing_Xcode_5.1.1_on_MountainLion-751x573
これでXcode 5.1.1のインストールは一応完了ですが、上のスクリーンショットから本バージョンにはiOS 7.1 SDKしか同梱されていないことが判ります。iOS 7.0用アプリの開発も行いたいので、Xcode 5.1.1にiOS 7.0 SDKを追加しました。具体的には、Xcode 5.0.2のdmgファイルをマウントして、ターミナルから次のコマンドを実行すれば、iOS 7.0 SDKを追加できます。
$ sudo cp -Rp /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs

下のスクリーンショットが、iOS 7.0 SDKを追加した後のXcode 5.1.1のDeveloper Information表示です。
SCShot_140915_0022-Installing_Xcode_5.1.1_on_MountainLion-751x573
さらに、iOS 5.0〜6.1とMac OS X 10.6, 10.7のSDKをXcode 5.1.1へ追加する作業も行いました(以下は、2013/12/03の記事に書いたMac miniのMountain LionへXcode 5.0.2をインストールしたときと同じ手順ですが、再掲載しておきます)。
  1. ターミナルを開き、次のコマンドを実行して、Xcode 5.1.1内にXcode 4.6.3側のiOS SDKが格納されているディレクトリのリンクを作成しました。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk ./

    これによって、iOS 5.0, 5.1, 6.0, 6,1のSDK が追加されます。

  2. 続いて、次のコマンドを実行して、Xcode 5.1.1内にXcode 4.6.3側のMac OS X SDKが格納されているディレクトリのリンクを作成しました。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk ./

    これによって、Mac OS X 10.6, 10.7のSDKが追加されます。

上のすべての操作を行った後、Xcode 5.1.1のDeveloper Information表示を確認すると、下のようになっていました。
SCShot_140915_0024-Installing_Xcode_5.1.1_on_MountainLion-751x612
上記のとおり、MBA11へXcode 4.6.3とXcode 5.1.1を共存インストールしてiOS開発環境を構築しましたが、その前に基本的なソフトを入れる作業もやりました。Windowsと比較すると、Macはこの作業がすごく楽です。基本的なソフトを一通り入れて使える状態にするのに、Windowsだと2〜3日かかったりしますが、Macだと半日〜1日で終わります。Windowsではソフト毎にインストーラを起動して入れていきますが、インストーラが起動するまで数分待たされたりしますし、インストール手順も統一性がなくまちまちです。インストーラによって表示されるガイド画面を確認しながら慎重に作業を進めていかないと、不要なものまでインストールされたりします。これに対して、Macではアプリのアイコンを「アプリケーション」フォルダへコピーするだけでインストールできます。すべてのアプリがこの手順に統一されているので、dmgファイルを開いたりzip/bz2ファイルを解凍した後にこの操作を行うだけです。ドライバやカーネルモジュールを内包しているソフトではインストーラが用意されていますが(インストーラはpkg/mpkgファイル内に収納されているので、同ファイルを開くと自動的に起動します)、インストーラのガイド画面もほぼ統一されているので、インストール操作を誤ったり迷ったりすることはまずありません。Windowsでは新しいソフトを入れるだけでシステムが不安定になったりすることがあり、こういう現象を解決するのに時間を取られたりしますが、Macではこんなことは皆無です。私は数台のMacを4年間ほぼ毎日を使い続けていますが、いままでこういう経験をしたことが一度もありません。マルウェアの数と種類もWindowsの方が断然多く、アンチウィルスやファイアーウォールを入れていないWindows PCはすぐにマルウェアに感染してしまいます。OSの安定性と安全性では、WindowsよりMacの方が圧倒的に優れています。本業の仕事でWindowsに使っていると、画面のあまりの見難さ(Macと比較すると、Windowsは特にフォントがすごく醜いです)とあまりの使い難さに嫌気が差してきます。毎日Macだけ使って仕事ができたら、どんなに幸せだろうと思ってしまいます。
タグ:Xcode
posted by とみやん at 10:58| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2014年09月06日

MacBook Air 11-inch(Early 2014)を入手した

久しぶりに大物の買い物をしてしまいました。新しいPCを手に入れたのです。私にとってPCとはMacのことです。本業の仕事では仕方なくWindows PCを使っていますが、開発研究やプライベート用としてWindows PCを買うことなど、もはや頭の隅に浮かぶことさえありません。デスクトップのメインPCとして使っているMac mini(Mid 2011)を入手したのが2012年10月なので、PCを買ったのは約2年ぶりです。WindowsからMacに乗り換える前は年に2〜3台のPCを買っていましたが、いまはせいぜい年に1台位です。使用目的が変化する度に、PCを買い換えたり、CPUやメモリなどのパーツを集めてPCを組んだりしていました。いまはMacにしか興味がないので、WindowsやPCパーツの最新動向を追いかけることはまったくなくなりました。こういう情報を知らなければ、PCやパーツを買うためにお金を消費することもなくなります。おかげで、トータルでは以前よりもPC機材に使うお金が大分減りました。「MacはWindows PCよりも値段が高いので、なかなか買えない」と言う人が多いですが、パーツを集めて何台もWindows PCを組むより、Macを一台買った方がよっぽど経済的です。

2013年6月に超省電力のHarswellコアIntel Core i5プロセッサを搭載したMacBook Airが発売されて以来、ずっとこの新型MBAが欲しくてたまりませんでした。モデルチェンジによってプロセッサ性能はそれほど大きく向上していませんが、バッテリー駆動時間が大幅に伸びたことが羨ましくてたまらなかったからです。MBA11のMid 2011/2012とMid 2013/2014を比較すると、バッテリー駆動時間は5時間から9時間に伸びています。MBAは持ち歩いて使うことが多いモバイルPCなので、この改良点は他の何よりもすばらしい事だと思っていました。

今回私が入手したのは、MacBook Air 11-inchの最新モデルEarly 2014 MD712J/BをベースにカスタマイズされたCTO版です。マシンスペックはプロセッサIntel Core i5 1.4GHz,メモリ8GB,ストレージSSD 256GBで、キーボードはUS配列になっています。スペックの中で特に搭載メモリの容量にこだわりを持っていました。標準仕様のMBAの搭載メモリは4GBですが、これを8GBに拡張した奴がどうしても欲しかったのです。その理由は、本業の仕事や研究テーマの開発でParalles DestopやVMware Fusionの仮想マシンにLinuxを入れて使うことが多いからです。いままでMBA11 Mid 2011(Intel i7 1.8GHz,メモリ4GB,ストレージSSD 256GB)をノマド用メインPCとして使ってしまたが、これを今回入手したMBA11 Early 2014に換えました。一緒にHyperJuiceを持ち歩いたりしていましたが、これで予備バッテリーを持ち歩く必要はなくなります。プロセッサはi7 1.8GHzからi5 1.4GHzへ変わっていますが、プロセッサ・コアや内蔵GPUの性能も向上しているので、この2つはほとんど差はないと思います(コア数も物理1、HyperThreading 2で同じです)。それより、メモリ容量が4GBから8GBに倍増したことが大きいです。内蔵SSDの読み書き性能も大きく向上しているらしいので、使っていくうちにこれらの恩恵も実感できるじゃないかと期待しています。
IMG_20140818-Photo01-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo04-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo05-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo06-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo14-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo15-Apple_MacBookAir11-MD721JB_CTO.jpg
手段はまたしてもオークション落札で、入手したのはワンオーナーの中古品です。発売されてまだ間もない最新モデルなので、ほぽ新品に近い状態でした。新型MacBook Airを入手するにあたって、11-inchと13-inchのどちらにするかずいぶん悩みましたが、ほぼ毎日持ち歩くPCなので、やはり軽さを重視して11-inchの方を選択しました。じつは、当初は13-inchの方を選択するつもりでした。ディスプレイ表示領域の広さを重視していたからです。11-inchが1399x768で13-inchは1440x900ですが、この差は大きいと考えていました。この考えはいまも変わっていませんが、重量とディスプレイ表示領域を天秤にかけて悩みに悩んだ末、結局11-inchの方を選択した訳です。私はMacBook Air 13-inch(Late 2010)も所有しており、こちらも何度も持ち歩いたことがありますが、13-inchの重さは結構ずっしりときます。バックパックに入れるとそれほど苦ではないのですが、手提げカバンではその重さを実感します。さらに移動距離の長さや持ち歩く頻度も大きく影響して、やはり13-inchのハンドキャリーは辛さを感じることが多かったです。11-inchは1.08kgなのに対して13-inchは1.35kgで270gしか差はありませんが、この差は意外に大きいというのが私の感想です。今回MBA 11-inchを選んだ理由はもう一つあります。それは、Retinaディスプレイを搭載した全面的なモデルチェンジ版のMacBook Airが今年中に発売されるのではないかという観測情報がたくさん流れていることです。ディスプレイのサイズは12-inchになりそうだという情報も多く、この予想どおりに、もしMacBook Air Retina 12-inchが登場すれば、それは軽さとディスプレイ表示領域の広さを兼ね備えた究極のノートPCになるはずです。これと現モデルのMBA 13-inchを比較すると、後者は見劣りします。市場価格も11-inchより13-inchの方が高いですし、いま無理して現モデルの13-inchを買うよりは、MacBook Air Retinaが発売されるのを待った方が賢明だと思いました。

今回入手したMBA11には最新版のOS X 10.9 Marvericksがプリインストールされていましたが、こいつはOS X 10.8 Mountain Lionにダウングレードしてしまいました。ググって調べると、Marvericksに対する評判があまり良くないようだったからです。メジャーなアプリを使うだけの実用機ならMarvericksでまったく問題ないと思いますが、開発機用に使うのはかなり不安を感じます。Marvericksも10.9.4までバージョンが進んでいますが、いまだにその評判は良くないみたいです。私は他のMacもMarvericksにアップグレードしていません。今年10月に新パーションのOS X 10.10 Yosemiteがリリースされるようですが、Yosemiteへのアップグレードも当面やるつもりはありません。
SCShot_140906_0001-MBA11_Early2014_MD721JB-OSX_MountainLion-1366x768
ちなみに、Moutain LionのインストールはDiskMager Xというソフトによって作成したUSBメモリを使って行いました。Mac App StoreからOS X(Lion/Mountain Lion/Marvericks)のアップグレード・アプリをダウロード済みの状態なら、このDiskMager Xを使って簡単にクリーン・インストール用メディアを作成することができます。Mac miniにMountain Lion用のアップグレード・アプリがダウンロード済みだったので、そちらにDiskMager Xを入れてMountain Lionのインストールメディアを作成しました。
タグ:MacBook Air
posted by とみやん at 14:17| Comment(0) | TrackBack(0) | PC > Mac

2014年08月31日

五反田・戸越銀座で過ごす休日

前の記事からまた一ヶ月以上間が開いてしまいました。公私共に色々な変化があり、毎日忙しい日々をおくっていて、なかなか記事を書く気になれないでいました。

そう言えば、先週から急に涼しくなり、もう夏も終わりかと思えるような天候が続いていますね。地方によっては、ずっと雨ばかりの夏だった所もあるみたいですが、こちらは曇の日は多いですが、それほど雨は降っていません。と言っても、これは信州の話ではありません。じつは、私はいま東京に滞在しています。先月末に一旦塩尻に戻ったのですが、本業の仕事の関係で、東京へ舞い戻る羽目になってしまいました。こちらには来たのは8/7です。夏の間は涼しい信州で過ごしたかったのですが、信州にはIT関連の仕事はほとんどないので、仕方なくまた東京に来ています。いまは戸越という所に滞在しながら、平日は常駐勤務先の会社が在る品川に通っています。

いまの滞在場所は五反田駅から徒歩で15分位、大崎駅へも15分位で行けます。電車やバスを利用すればどちらの駅にも5分位で行けるので、都心へのアクセスが良く便利です。そして、すぐ近くに戸越銀座という商店街があります。誰かに戸越に滞在していると話すと、必ず「あの戸越銀座が在る所ですね」と言われます。それくらいこの商店街は有名らしいです。戸越銀座は全長約1.3kmに渡る関東有数の長さの商店街で、その中に東急池上線の戸越銀座駅と都営浅草線の戸越駅が存在します。周辺の住民が主な客ですが、遠くから訪れている人もいるようで休日はにぎやかです(ごった返すという程ではありません)。小奇麗で活気がある商店街ですが、気取った感じはまったくなく、店の人同士や買い物客が立ち話をしている光景をあちらこちらで見かけます。特に印象的なのは、練物などの素材店だけでなく飲食店までもが軒先で調理済みのお惣菜を売っている事です。そして、それらを買い物客がその場で食べている光景を良く見かけます。いくつかの店は軒先にテーブルと椅子を置いてあり、近所の人や買い物客がワイワイと一杯やりながら食べたりしています。こういう光景が商店街の中に溶け込みながら、とても穏やかな空気が流れています。戸越銀座を訪れたのは今回が始めてですが、それ以来私も此処の雰囲気が気に入ってしまい、休日は渋谷や新宿などへ出ることもなく、戸越銀座商店街の中をブラブラと散策して過ごしたりしています。
IMG_20140830-Photo12-TogoshiGinza_Scene.jpg
IMG_20140830-Photo14-TogoshiGinza_Scene.jpg
IMG_20140830-Photo09-TogoshiGinza_Scene.jpg
都内の庶民的な商店街と言えば、戸越銀座から距離が近い武蔵小山も有名です。じつは、私は武蔵小山に2年間住んでいたことがあります。35年も前なので大昔です。3年前目黒に6ヶ月滞在したことがありますが、このときにどんな風に変わっているのか観てみたくなって武蔵小山へ数回行きました。武蔵小山のアーケード商店街も小奇麗に様変わりしており昔以上ににぎやかでしたが、戸越銀座の方がより活気があるような気がします。それに戸越銀座の方が少し上品な感じがします。戸越とその周辺の目黒、五反田、大崎などの住民は裕福層が多いからかもしれません。

いまの滞在場所の近くには、もう一つ五反田TOCビルという名所があります。商業店舗とコンベンションセンター等の複合施設ですが、このビルには様々な種類の卸売店が入っています。ユニクロやABCマートなども在って、どちらも店舗面積が広く品揃えが豊富な上、商品の価格が他店より安いです。他にも鉱石、アロマ、外国お土産風アクセサリーなどやちょっと怪し気な商品を置いている店も在って、これらの店内を眺めながら歩き廻ると面白いです。普通に衣類、日用品、化粧品などを売っている店もあります。そして、どの店も商品の値段が安い(西友やイトーヨーカドーなどの特売セールと同程度かそれ以下の価格)のが特徴です。ちなみに、TOCとは「東京卸売センター」の略称です。ここも結構有名な所ですが、有名な割には休日でも客は少なくゆったりと買い物ができます。五反田駅から少し離れており、施設が古い所為であまり人気がないのかもしれません。ただし、五反田駅から徒歩8分で行けますしシャトルバスも運行されているので、アクセスが悪いということはぜんぜんないです。休日にゆったりと買い物をしたければ、此処はお勧めです。スーバー並に豊富な種類の商品がありながら、どれも値段が安いのが良いです。五反田TOCは名所と呼ぶより、知る人ぞ知る穴場と言った方が適切かもしれません。私も休日にTOC内の店を渡り歩いたり、同ビルの1階に在るエクセルシオールカフェでカフェオレとかを飲みながらのんびりと時間を過ごしたりしています。午前中にTOCで過ごして午後から戸越銀座に行くのが、休日の過ごし方のパターンになっています。
posted by とみやん at 15:48| Comment(0) | TrackBack(0) | 日記

2014年07月17日

iPod touch第5世代を入手した

私はまだ横浜の長者町に滞在しています。横浜での仕事は7/8に終わりましたが、本業の仕事の関係で東京での予定が重なったからです。それらも今週一杯で全部片づくので、来週の7/21に塩尻へ戻る予定です。7/9以降特に仕事はしていなかったので、早めの夏休みを取っている気分でのんびりと過ごしていました。

いやー、しかし、それにしても東京は暑いですね。台風8号が通過した7/11以降関東地方は見事に真夏の気候に変わってしまいました。日中に外に出ると、あまりの蒸し暑さに息苦しささえ感じるくらいです。真夏の信州もそこそこ気温は高いですが、湿気が低いので東京よりはずっと過ごし易いです。関東地方の真夏の気候は本当に身体に堪えます。「やっぱり、こんな東京には住みたくないなぁ」という気分になります。東京はコンクリートやアスファルトだらけで熱気の逃げ場がどこにもなく、ヒートアイランド現象によってさらに気温が上がっていることが、この息苦しいほどの蒸し暑さの主たる原因なんだと思います。私は18歳のときに上京して28年間東京に住んでいましたが、若い頃にはエアコンを持っていませんでした。25年位前まではエアコンは高価な家電で贅沢品だったからです。その当時はエアコン無しでも普通に東京で暮らせましたが、いまの東京では夏にエアコン無しで生活するのは自殺行為に等しいんじゃないかと思います。エアコン付きの賃貸物件も増えており、築浅のアパートやマンションには大抵エアコンがついています。東京のような都会ではエアコンはもはや必需品です。エアコンがここまで普及してしまったことが、都会のヒートアイランド現象を引き起こしているのかもしれません。私は夏が大の苦手で、四季の中で夏が一番嫌いです。どうしても用事で外出しなけばならないとき以外は、できるだけ冷房の効いた室内で過ごすようにしています。外食や買い出しなどで外に出るのは早朝か夕方だけで、日中はずっと部屋に篭っています。横浜周辺の名所巡りとかに行きたかったのですが、あまりの暑さにそんな気力はぜんぜん湧いてこないです。

さて、前記事にiPhone 4SかiPod touch第5世代を近いうちに入手するつもりだと書きましたが、iPod touch第5世代(32GB, White,MD720J/A)の中古品を手に入れることができました。今回も入手手段はオークションで、落札価格は現在の中古相場とほぼ同じでした。この機種は数多くオークションに出品されているので、粘り強く入札を続ければ、もう2,000〜3,000円安く落札できそうな感じでしたが、手っ取り早く入手したかったので即決価格で出品されていた物を落札してしまいました。本体の状態はかなり新品に近く、グレードは上の中という所ではないかと思います。
IMG_4438_1-Apple-iPod_mini-MD720JA.jpg
IMG_4436_1-Apple-iPod_mini-MD720JA.jpg
IMG_4451_1-Apple-iPod_mini-MD720JA.jpg
IMG_4477_1-Apple-iPod_mini-MD720JA.jpg
IMG_4462_1-Apple-iPod_mini-MD720JA.jpg
実物を目にして手に持った瞬間、こいつの薄さと軽さに驚かされました。そして、スクリーン画面がすごく鮮やです。それもそのはず、このiPod touchはRetinaディスプレイを搭載しているんですね。

上の写真のとおり、iOS 7からUIやアプリ・アイコンのデザインが大きく変わっていますが、私はiOS 6までのUIの方が好きです。特にiOS 7のアプリ・アイコンのデザインが2D風の平べったい感じになったのは気に入りません。UIデザインのトレンドが3Dを多用した立体的なものから2Dやタイル風へ移っているようなので、こうなってしまったんだと思いますが、何だかAndroidに似ていてiOS 7のUIは好きになれません。まぁ、UIデザインが時代の流れで変わっていくことは仕方がないことなので、諦めてiOS 7のUIに慣れていくしかないんでしょうが・・・。

私がいままで手に入れたiOSデバイスはiPhone 3GSとiPhone 4ですが、どちらも三世代以上前の機種です。とても実用機として使える性能ではないので、これらはいずれも開発専用機として使っていました。今回入手したiPod touch第5世代は現行機種なので、これから毎日持ち歩いて使っていくつもりです。このiPod touchが私にとって初めてのiOS実用機になります。ちなみに、こいつのファームウェアはiOS 7.1.1でした。近いうちにiPhone 4Sも入手するつもりですが、こちらはiOS 7.0.xを搭載した奴にしようと決めています。どちらもBLE/iBeacon用の開発機としても使うつもりですが、将来iBeaconアプリを開発したときに、iOS 7.0.xと7.1.xの両方で動くことを検証したいからです。

iPod touchにはWiFiしか搭載されておらず、3G/4G/LTEなどのデータ通信機能は内蔵されていません。そのため、iPod touchを外で使うにはモバイルルーターも一緒に持ち歩く必要があります。今年の3月にWiMAXのルーターを解約して、イー・モバイルのGL10Pというモバイルルーターに換えました。月間7GBというデータ通信量の制限はありますが、アクセスエリアが広い4G/LTE回線が使えて、SoftBankのWiFiスポットも利用できます。通信速度はそこそこ高速で、大抵何処でも繋がるので便利に使っています。WiMAXはビルの中や街から離れた郊外などではほとんど繋がらなかったので、WiMAXから4G/LTEルーターに換えて正解だったと思っています。GL10Pはバッテリーの持ちがあまり良くないという欠点がありますが、モバイル機器用の外付けバッテリーも一緒に持ち歩くことでこの欠点をカーバーしています。iPod touchはスマホではありませんが、常にモバイルルーターと一緒に持ち歩けば、スマホみいたな感じで使っていけます。やっと私もスマホ・デビューすることになりそうです。

BLE/iBeaconの研究に本気で取り組む決心をしたので、その開発環境を整備していかなくてはなりません。一台だけですが、取りあえず、これでiOSデバイス側の準備は整いました。次の目標は、BLEモジュールの評価ボードを入手することです。近いうちにこちらも入手しようと思ってDigiKeyやMouserで物色中ですが、どの製品を買えば良いかはほぼ判っています。前記事で紹介した『Getting Started with Bluetooth Low Energy』という本にこの辺の情報が載っており、さらにググってBLE評価ボードの情報収集もしました。予算確保の関係で2〜3回に分けて複数の種類のボードを購入するつもりですが、一回目に購入する製品はすでに決めています。BLE評価ボードが入手できたら、随時記事で紹介していきます。


タグ:apple iPod touch
posted by とみやん at 12:43| Comment(0) | TrackBack(0) | モバイルデバイス > iOS

2014年06月29日

Bluetooth Low EnergyとiBeaconの研究を始めます

4月初頭のまだ桜が咲いている頃に横浜に来て、横浜周辺のマンスリーマンションに滞在しながら仕事をしていましたが、こちらでの仕事も今週一杯で終わることになりました。次の仕事の場所は何処になるかまだ決まっていませんが、いずれにしても近いうちに横浜から離れことになりそうです。新宿や渋谷みたいな都心の街よりは人が少なく、横浜の街中に流れている空気はゆったりしている感じがします。そんな横浜の街が好きだったので、すごく名残惜しいです。

さて、私は隙間時間などにIT関連の情報収集を日常的にやっています。主な目的は新しい研究テーマを探すためですが、やはり最新のトレンドにアンテナを張っておきたいからです。Webやモバイル分野で働いているプログラマは私と同じように日常的に情報収集している人は多いんじゃないかと思います。この2つの分野は日進月歩で技術が進化しており、ちょっと油断するとすぐに最新トレンドに置いていかれてしまいます。私が最近情報収集のときに使っている一般的なキーワードを紹介すると、Web関連では「JavaScript」「HTML5」「データビジュアライゼーション」など、モバイル関連では「iOS」が断然トップですが、「ハイブリッドアプリ開発」などについても調べたりしています。このようにWebとモバイル分野の情報収集は私の日課になっていますが、最近すごく有望そうなモバイル分野の研究テーマを見つけました。それが、Bluetooth Low EnergyとiBeaconです。

Bluetooth Low Energy(BLE)は2010年7月に発表された近距離無線通信技術Bluetooth 4.0規格の一部として策定されたもので、マーケット的な俗称として「Bluetooth Smart」という呼称も使われています。その名が表しているとおり、BLEの最大の特徴は超低電力で通信が可能なことです。コイン形リチュウム電池で最大数年間動作させることができます。Bluetoothと同様に、BLEは免許なしで使える2.4MHz帯の電波を用いており、最大1Mbpsの通信が可能です。

私がググって得たBLE関連の情報を以下に列記します。
  1. BLEチップは1個あたり2〜5ドル程度の価格で複数の半導体メーカーから販売されており、これらを利用すると、安価にBLEモジュール(「Beaconモジュール」とも呼ばれる)を製造することができる。
  2. 最新のiOSデバイスはBLE機能を標準で内蔵しており、iOS 7以降を搭載していれば、BLEを利用するアプリを動かすことができる。
  3. 現状BLEを搭載しているAndroid端末はNexus 4とNexus 7(2013年モデル)だけで、しかもBLE機能を利用できるのはAndroid 4.3(最新バージョンはAndroid 4.4)以降だけである。
  4. BLEとiBeaconによる位置情報の利用シーンとして、店内やショピングモール、観光地などで広告や情報をプッシュ配信するようなケースだけでなく、ユーザーの行動情報などを収集して統計データとして利用するようなケースも考えられる。このようなケースでは、Webサービスと連携していく可能性が高い。

一つずつ簡単に説明すると、多くの半導体メーカーがBluetooth RF SoCチップを製造していますが、これらのうちTexas InstrumentsNordic SemiconductorなどがBLE規格に対応したSoCチップの製造・販売に力を入れています。TIのCC2540CC2541、Nordic SemiconductorのnRF51882nRF51422などが代表的なBLE SoCチップで、これらの単価は2?5ドル程度です。TIやNordic Semiconductor、そしていくつかの組込みボード・ベンダーからもこれらのチップを搭載した評価ボードも販売されており、このような評価ボードも100ドル前後と比較的安い値段で入手できます。主要な種類のBLE SoCチップを搭載した評価ボードを一通りと揃えたとしても、全部で大体500〜600ドル前後で購入すること可能です。LinuxやAndroid用の評価ボードと比較すると、BLEモジュールの開発はかなり低予算で始めることができます。ちなみに、CC2540とCC2541に内蔵されているCPUコアは8051、nRF51882とnRF51422はCortex-M0です。どちらもGCCを使えるので、BLEモジュールのファームウェアはオープンソースを利用した組込み技術で開発することができます。私の場合、この辺りは本業の仕事で長年やっているので、BLE SoCチップや評価ボードさえ入手できれば、すぐにでもBLEモジュール側の開発に着手できます。さらに言えば、BLEモジュール自体も相当な低予算で製造することが可能です。BLE機能はすべてSoCチップに内蔵されているので、これにアンテナ、オシレータ、チップ型抵抗やコンデンサ、コネクタなどの電子部品を組み合わせるだけで製造できるからです。ロッドあたりの製造数にもよりますが、ざっと計算しても1個1,000円前後かそれ以下の原価で製造することも可能なはずです(製品の見栄えを重視して、本体をちゃんとしたケースに入れるなら、ケースの製造単価も加算しなければなりません。それでも、1個あたり2,000〜3,000円前後の原価で製造できるじゃないかと予想しています)。

続いて、iOSデバイス周辺のBLE事情についてですが、この辺りの情報については私がグダグタ説明するより、下のリンクページの記事を読んでもらった方が早いんじゃないかと思います。

 ASCII.jp:アップルが普及を狙う「iBeacon」とは何か? その基本を押さえる (1/4)
 超話題の「iBeacon」を徹底解説――O2Oの本命となるか!? | ビジネスネットワーク.jp
 iPhoneアプリでBluetooth通信を使うための基礎知識(1/4) - @IT

AppleはiOSに搭載しているBLEを利用した近距離位置測位サービスを「iBeacon」という名前で呼んでおり、以下の機種がこのiBeaconに対応しています。
  • iPhone 4S以降
  • iPad 3rd generation以降
  • iPad mini 以降
  • iPod touch 5th generation以降

iBeaconの機能はCoreLocation.frameworkに統合されており、iOS 7に対応したアプリはこれを利用することができます。最新の統計データによると、現状iPhoneユーザーの約80%がiPhone 4S以降のモデルを使っており、iOSのバージョン別シェアではiOS 7は88%に達しているそうです。つまり、iPhoneに限れば、世の中で稼働中の約80%の端末でBLE/iBeaconアプリを動作させることができることになります。

このようにiOSデバイスではBLEのインフラ環境がすでに整備されていますが、これと比較すると、AndroidのBLEへの対応状況は随分と遅れています。まず、BLE機能が利用できる機種がNexus 4とNexus 7(2013年モデル)に限定されます。Nexus 4はスマホですが、Nexus 7はタブレットです。Nexus 7を常に持ち歩いている人が世の中にたくさん存在すると想定するのは、ちょっと無理があるんじゃないかと思います(結構売れた機種なので、そこそこユーザーは多いでしょうが・・・)。どちらもGoogleが自ら販売しており、携帯キャリアからは販売されていないので(日本通信とイオンが協業して、2014年4月からNexus 4を『イオンのスマートフォン』として発売しているそうです)、広く普及しているとは言えない機種です。BLE対応ハードウェアが搭載されているAndroid端末は他にもいくつか存在していますが、それらの機種はメーカー独自のSDKを使わないとアプリ側でBLE機能を利用することができません。OS側に標準のBLE対応APIが追加されたのはAndroid 4.3からで、現状このAPIは上の2機種にしか対応していません。しかもAndroid 4.3のBLE APIはかなり不安定らしく、Android 4.4を導入しなければ安定した通信はできないそうです。Android 4.4を導入済みの上の2機種だけに限られるとすれば、現状BLE機能を利用できるAndroid端末の数は相当少ないと見るべきでしょう。

上記のような状況なので、モバイル・プログラマがBLE対応アプリを開発する場合、iOSだけをターゲットとしてアプリを開発すれば良く、実質的にAndroidは無視することができます。この現状を知ったことが、私がBLE/iBeaconの研究に取り組もうと決心した最大の理由です。

それと、私がBLE/iBeaconに取り組もうと決めた理由がもう一つあります。それは、BLEがモバイルやウェアラブルデバイスなどに搭載されることを想定した規格であるという点です。常に身につけているデバイスが周辺に存在するBLEモジュールを検出できるようなシュチュエーションでなければ、BLEによる位置情報の利用価値は生まれません。ノートPCのような携帯性が低い機器にBLEを搭載しても利用価値はほとんどありません。それに、ノートPCは常時電源が入っている保証がありません。バッテリー駆動時間の節約のために、携帯中はノートPCの電源を切っている人も多いはずです。これは、PCで最大のシェアを持つWindows向けにBLEアプリを開発する必要性はないということを意味しています。BLEモジュールの配置や稼働状況などを管理するツール的なプログラムをPC向けに開発するケースは考えられますが、BLEモジュール自体を利用するアプリプログラムはモバイルやウェアラブルデバイス上で動かすケースだけを考慮すれば良いことになります。Windows Phone 8はBLEに対応しているようですが、このOSを搭載しているモバイル端末のシェアはiOSやAndroidと比較すると極端に小さいので、Windows Phoneは無視してもまったく問題ありません。

過去の記事に書いているとおり、私はAndroidとWindowsが嫌いです。Androidを搭載した端末も機種が増え、Android 4.3以降その性能もかなり向上していることは知っています。iOSのライバルなので、iOSについてググっているとAndroidの最新情報も自然と目に入ってきてしまいます。時代の趨勢で、もはやAndroidを無視するのは難しくなっていることも十分承知しています。嫌でもまたAndroidに関わる時が来るかもしれませんが、Windowsだけにはできたらもう関わりたくないと思っています。手持ちのPCはすべてMacに換えてしまいましたが(本業の仕事用に二世代前のモデルを3台だけ残していますが、Boot Campを利用してMacでWindowsを使うこともできるので、もうWindows PCは全部処分しても問題ないかなぁという気がしています)、本業の仕事では不本意ながらWindowsを使うことがまだ多いです。しかし、できることなら本業の仕事でもWindowsを使うのを止めて、Windows向けのプログラム開発も完全に終わりにしてしまいたいという気持ちが強くなっています。個人的には、Windowsはすでに過去のOSであり、Windowsのために時間を使うことは無駄以外の何者でもないと思っています。エンタープライズ系ではWindowsがまだ大きなシェアを維持しているようですが、現状Webインフラ系ではLinuxが圧倒的なシェアを持っています。動画配信のようなパフォーマンスを重視するサーバーでは、WindowsはLinuxに完敗するからです。このような状況を考えると、極端な意見かもしれませんが、エンタープライズ系以外ではもうWindowsプログラマは不要なんじゃないかという気がしています。PCからモバイル機器への移行が益々加速しているので、プログラマがWindows開発に時間を使う価値は低くなる一方のように思えてなりません。まったく余談ですが、本業関係で私が得た最新情報によると、最近なぜか組込み分野でWindows関連の仕事が急に増えているらしいです。モバイル機器ではさすがにiOSやAndroidに太刀打ちできませんが、据え置き設置型の機器でWindowsやWindows Embeddedを採用するケースが増えているそうです。危機感を持ったMicrosoftがこれらのOSのライセンス価格を下げて、営業攻勢をかけているのかもしれません。

話題が逸れてしまったので、元に戻しましょう。私がBLEとiBeaconに興味持ったのは、AmazonでjQuery Mobileの参考書を探しているときに、たまたま「iBeacon」の本を見つけたことがきっかけです。その後、ググって調べるうちに「iBeacon」がiOS 7に搭載されている標準機能であることを知り、さらに、これがBLE規格に準拠した多数のモジュールと通信することで近距離の位置情報を取得する目的に使われることを知りました。そして、元組込み屋として自然に興味が向かったのは、BLEがどのような規格なのかと、BLEモジュールのハードウェア構成はどうなっているのかいう点です。これらについて調べていくうちに、上のような情報を得ることができました。去年の終わり頃から漠然と頭に描き続けてきたアイデアがあって、それが、組込みとモバイルを融合したガジェット的な物が作れないだろうかだったので、BLEとiBeaconの詳細情報を知ったときに、まさにこの組み合わせがテーマにマッチしているのではないかとピンと来ました。

いまはまだBLEとiBeaconのベーシックな情報を収集している段階で、手始めとして、以下の2つの本を読んでいます。

iBeacon ハンドブック
iBeacon ハンドブック
posted with amazlet at 14.06.28
(2014-03-25)
売り上げランキング: 1,755

Getting Started with Bluetooth Low Energy
Kevin Townsend Carles Cufi Akiba Robert Davidson
Oreilly & Associates Inc
売り上げランキング: 7,366

『iBeacon ハンドブック』はすでに読了し、『Getting Started with Bluetooth Low Energy』の方ももう少しで読み終わります。後者は洋書ですが、BLEとiBeaconの概要情報が良くまとまっているので、英語を読めるなら、この本から読み始めることをお勧めします。『iBeacon ハンドブック』と『Getting Started with Bluetooth Low Energy』に書かれている内容は重複している部分が多く、後者の方が内容的に詳しいので前者は読む必要はないと思います。『Getting Started with Bluetooth Low Energy』の中には、想定読者が「Mobile Application developers」と「Embedded engieers」であると明記されています。BLEモジュールのハードウェアや開発環境の構築方法についても書かれいるので、私のような組込み屋でBLEに取り組みたいと考えているプログラマが最初に読むべき本としては、これが最適ではないかと思います。他にもBLEとiBeacon関連の本がいくつか出版されており、CoreLocation.frameworkによる位置情報プログラミングに焦点を絞っている本もあります。記載内容の有益性を見極めながら、これらの本も読んでいくつもりです。

BLEとiBeaconについて知れば知るほど、この2つが大きな可能性と将来性を持つ技術であることが解ってきました。そして、すでにBLEとiBeaconに取り組んでいる人がたくさんいることも知りました。私もこれらの研究に本気で挑戦することを決意しました。これからは本気モードでやっていくので、当然iBeacon対応アプリも必ず作ります。iOSアプリ開発の再勉強を始めたのは、この決意を固めたからです。iBeaconの開発機材一式を揃えないと何も始められないので、できるだけ早くこの環境を構築するつものです。Macは手持ちの物を使うとして、まずはiBeaconに対応したiOSデバイスを入手しなければなりません。経済的な事情から、iPhone 4SかiPod touch第五世代の中古品を買うつもりです。私がいま使っている携帯電話はウィルコムのPHSガラケーですが、今年の10月からPHS携帯電話のMNPが始まります。MNPを利用して他の携帯キャリアに乗り換えると、最新のiPhone 5s/5cが一括ゼロ円で買えます。MNPを利用して、10月にiPhone 5sを入手しようと目論んでいます。BLEモジュール側の開発環境もできるだけ早く揃えます。来月にでもBLE SoCチップの評価ボードを数種類購入しようと計画を立てています。BLEとiBeaconの研究開発活動は記事としてどんどん公開していきますので、これからご期待ください。

posted by とみやん at 07:57| Comment(0) | TrackBack(0) | 日記

2014年06月21日

Objective-CからiOSアプリ開発の再勉強

本業の仕事の関係で半年程遠ざかっていましたが、最近になって、またiOSアプリ開発へのモチベーションが復活してきました。AppleからiOS 8リリースの発表もあり、ADCではiOS 8 beta 2の配布が始まっています。このメジャーバージョンアッブによって、iOSはさらに大きく進化するようです。このまま手をこまねいていると、どんどん置いていかれて恐竜状態になりそうです。年齢的にはもはや恐竜並みのオールドタイマープログラマですが、恐竜のように絶滅したくはないです。

私のいまのiOSブログラミングのレベルは、低機能なアプリはそこそこ簡単に書けるが、本格的なアプリを作ろうと思うと、まったく歯が立たないという状態です。過去の記事で紹介した本の中で通読したのは『iOS Programming: The Big Nerd Ranch Guide (3rd Edition) 』だけで、他の本は、実際にアプリを書いているときに役立ちそうな箇所を拾い読みしたりして使っている程度です。プログラマ歴が長いので、経験や勘でカバーできる部分も多少ありますが、モバイル開発はPC(WindowsやLinux)や組込み開発とは別世界なので、iOSブログラミングについてはビギナーレベルに少し毛が生えた程度だと考えるのが適切な自己評価というものでしょう。いまの中途半端なレベルから脱して、本格的なアプリをどんどん書けるシニアレベルに早く到達しないとダメだなぁと感じています。そこで、初心に帰って、iOSアプリ開発の勉強を一からやり直す決心をしました。

同じことを繰り返したくないので、どういう方針でiOSアプリ開発の再勉強に取り組むべきか色々と考えたのですが、やはり基本に立ち返って、iOSアプリのブログラミング言語であるObjective-Cをしっかりと習得しておかないと、ビギナーレベルから脱することはできないんじゃないかと思いました。C++はC言語の知識をベースにして特別な勉強なしで自然に習得することができましたが、Objective-Cは微妙な違和感があって、iOSアプリのコードを書いていてもスーと落ちてくるような感じがなかなかしないです。Objective-Cの言語仕様はSmalltalkの影響を強く受けており、C++よりオブジェクト指向が徹底しているからではないでしょうか。C++なら中途半端なオブジェクト指向設計でもプログラムを書くことができますが、Objective-Cではそれができないような感じがします。一応ちゃんと理解しているつもりですが、オブジェクト指向について深いレベルで理解し直すことにもなるので、Objective-Cから再勉強するのは意味があることではないかと思えます。それともう一つ、Objective-CはOSとの連携性がすごく高いプログラミング言語だという感じがします。Mac OS XとiOSのフレームワークを構成する基礎的なクラス群は「NS」という文字で始まる名前がつけられています。これは、Mac OS XとiOSがNEXTSTEPをベースとして生み出されたOSだからです。この2つのOSのフレームワークもObjective-Cで書かれています。Objective-Cというプログラミング言語を深く理解することは、Mac OS XとiOSのフレームワークの設計思想を理解することにも繋がります。たとえ遠回りだとしても、ブログラミング言語であるObjective-Cをもう一度一から勉強し直すことがベストな方法ではないかと思えてなりません。頭の中に実現したい機能が浮かんだときに、参考情報からスラスラとObjective-Cでプログラムコードが書けるレベルでないと、本格的にiOSアプリを開発していくことなど到底できないでしょう。ブログラミング言語の文法や書式は完全に頭の中に入っており、OS側のAPIリフアレンス情報やコードサンプルなどを参考にしながら、アプリの実装コードをどんどん書き進めていけなくてはシニアレベルのプログラマとは言えません。

そこで、上記のような方針に合っていそうな本をAmazonで探し回りました。この2年でiOS開発関連の書籍はさらに数が増大しているようです。本当にすごい数の本が出版されていますが、今回はその中から以下の2つの書籍を選びました。

iPhoneアプリ開発のコツとツボ35
國居 貴浩
秀和システム
売り上げランキング: 58,864


Amazonのカスタマーレビューでの評価が高く、どちらもObjective-Cにフォーカスした内容で豊富なサンプルコードが掲載されているようです。『iPhoneアプリ開発のコツとツボ35』の方は印刷版、『Effective Objective-C 2.0』の方はKindle版を購入しました。どちらもKindle版が欲しかったのですが、前者の電子書籍版はまだ発売されていないようです(本記事を書いた後で確認したら、Amazonの『iPhoneアプリ開発のコツとツボ35』の商品ページにKindle版が登録されていました。Kindle版の発行日は2014/06/13で、しかもXcode 5とiOS 7に対応した改訂版になっているようです。私がこの本を注文購入したのは06/17ですが、そのときはまだKindle版は登録されていなかったか、あるいは見落としてしまったのかもしれません。改めてKindle版も買うべきか悩んでいますが、一度完読して内容の有益度を確認してから決めようと思っています)。後者は洋書ですが、この本の翻訳版和書も出版されています。

Effective Objective-C 2.0
Effective Objective-C 2.0
posted with amazlet at 14.06.21
Matt Galloway
翔泳社
売り上げランキング: 123,169

『Effective Objective-C 2.0』は和書と洋書のどちらを選ぼうかちょっと迷いましたが、Kindle版は洋書の方が安く、こういう技術書の英語なら辞書なしでも意味を理解しながら読めるので、洋書の方を買いました。

「とにかく、どんどんコードを書く」これが一番の大切な事だということを忘れずに、iOSアプリ開発の再勉強をやっていきます。書くObjective-Cコードの量が増えれば、iOSに関する技術知識やプログラミング能力は自然に身についていくんじゃないかと想像しています。私は組込み分野でのプログラマ歴が長いですが、自分の経験からも「書いたブログラムコード量と技術習得速度は比例する」という法則は成り立っています。分野を問わず、多くのプログラマがこの法則に賛同するはずです。あと必要なのは、実際に本格的なアプリを書き始めてからの「このブログラムをどうしても完成させたい」という熱意でしょう。iOSアプリ開発で取り組みたい研究分野も探していましたが、じつは、最近「これならイケるんじゃじゃないか」という分野をやっと見つけました。その辺については後日別の記事に書こうと思っています。

タグ:Objective-C
posted by とみやん at 14:47| Comment(0) | TrackBack(0) | 日記

2014年05月31日

最近読んだスタートアップ系の本

横浜で仕事を始めてから1ヶ月半が経ちました。04/09からこちらに来ていますが、いまは長者町という所に滞在しています。常駐勤務をしている会社は横浜駅の近くなので、最寄り駅の伊勢佐木長者町(横浜市営地下鉄)から毎日通勤しています。ちなみに、平日は毎朝6時頃に起床して、7:30/8:00〜16:30/17:00(ときどき1時間程度の自主的残業)の勤務パターンで働いています。私はずっと朝方労働を続けているので、早出出勤も労働時間として認めてもらえてすごく助かっています。都会のIT企業には珍しく、常駐先の会社は朝方の社員が多く、私と同じ勤務パターンで働いている人も数人います(最近は都会でも朝方で働く人がだんだんと増えていて、夕方から大学やビジネススクールなどの学校で勉強したりしている人もいます。残業だけでなく早出出勤も労働時間として認め、大手企業でも社員の勤務パターンの自由度を高くしてやるべきです)。いまの滞在場所の長者町は関内や伊勢佐木町にも近く、伊勢佐木モールという繁華街が近くにあります。この辺りは横浜で一番ホテルが集まっているエリアでもあり、毎日たくさんの観光客(そのほとんどは中国人ですが)を見かけます。夜も賑やかな場所で、夜中でも人通りが途絶えることはありません。

観光地としての横浜エリアの魅力は名所が狭い範囲に集まっていることでしょう。中華街、みなとみらい21、山手などの名所がいずれも電車やバスで10〜15分圏内にあり、徒歩や自転車でアクセスすることもできます。駆け足なら、これらの名所をすべて一日で廻ることも可能です。休日には観光客に加えて東京在住の人もたくさん横浜を訪れます。横浜に滞在していると、休日の度にこれらの名所を巡ってゆったりと一日を過ごすことができます。私もぜひそうしようと思っていたのですが、いままでは副業の仕事が忙しくてなかなかそれがきませんでした。先週末にやっと副業の仕事が終わり、本業の仕事もそれほど忙しくないので、これから休日に近隣の名所を巡ってみようと思っています。滞在場所は横浜スタジアムにも近いので、そのうちプロ野球観戦もしてみたいです。横浜の名所に行ったら、ブログ記事で紹介するつもりです。

さて、話は変わりますが、前の記事に最近スタートアップ系の本ばかり読んでいると書いたので、最近読了したスタートアップ系の書籍を3冊紹介します。

スタートアップ・バイブル シリコンバレー流・ベンチャー企業のつくりかた
アニス・ウッザマン
講談社
売り上げランキング: 21,648

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール
ランダル・ストロス
日経BP社
売り上げランキング: 10,235

ぼくらの新・国富論 スタートアップ・アカデミー (WIRED BOOKS)
並木裕太 WIRED編集部
ディスカヴァー・トゥエンティワン
売り上げランキング: 82,935

上はAmazonの印刷本商品へのリンクですが、私が読んだのはいずれもKindle電子書籍版です。

特に意識してこういう本を選んでいるつもりはつもりはないのですが、AmazonのKindleストアで本を探していると、ついついスタートアップ関連の本ばかりに目を止めてしまいます。Kindleを入手した直後は、Apple, Google, Facebookに絡んだ本ばかり読んでいました。こういう本は結構数があって、読んでいる最中はそこそこ面白かったのですが、読了後に感じたのは大きな虚しさでした。シリコンバレーの先端IT企業は日本とはかけ離れた別世界だなんだなぁと思えてならなかったからです。

その後、Kindleストアの月替りセールで『リーン・スタートアップ』(エリック・リース著)という本をたまたま見つけて、タイトルの目新しさに惹かれて読んでみました。読んだ後で知ったのですが、この本はスタートアップのバイブル本と呼ばれているそうです。私が「スタートアップ」という言葉を初めて知ったのはこの本を読んだときです。そして、この本の中に書かれている米国のスタートアップ企業で用いられる製品開発手法が従来のベンチャー企業のそれと大きくかけ離れていることに驚いてしまいました。特に、必要最小限の機能だけを搭載した製品を開発し、可能な限り短期間でリリースして、利用ユーザーの意見を収集しながら製品を改良していく「MVP(Minimum Viable Product)」という手法はとても斬新でした。製品の機能や完成度にこだわる日本の「モノづくり」とは正反対のやり方です。米国のスタートアップ企業の多くはWebサービスやモバイルアプリなどの製品を開発しており、ハード中心の日本の「モノづくり」と比較するのは危険なことは承知しています。しかし、IT分野の規模や繁栄度を比較すると、米国では拡大と興隆が続いているのに日本は停滞あるいは衰退の方向に向かっています。上で紹介した『Yコンビネーター』という本には「ソフトウェアが世界を食う」というタイトルの章があります。現在のIT分野を牽引しているのはハードではなくソフトです。特にWeb関連で使われる技術の進化は日進月歩で、1〜2年程度の短期間で先端技術が様変わりすることさえあります。製造業がほぼ消え去った米国のIT分野が益々繁栄し、ハード中心の日本は衰退へ向かっていることを考えても、これから起業を目指す人がどちらを選ぶべきなのかは議論の余地はないように思えます。

スタートアップ系の本を読んでいると驚くことがもう一つあります。それは、『リーン・スタートアップ』や『Yコンビネーター』などに登場する米国のスタートアップ企業の多くは、会社を存続させることではなく、会社を売却することを目指していることです。米国のスタートアップ企業の創業者利潤獲得手段は「イグジット戦略」と呼ばれており、「IPO(株式公開)」と「M&A(会社売却)」の2つの方法があります。現在の米国のベンチャー市場では、M&Aによるイグジット件数が圧倒的に多く、その割合は9割以上となっています。自社で開発した製品を会社ごと大手IT企業に高い評価額で売ることが、米国のスタートアップ企業のゴール目標なのです。5年以内に会社を売却できなければ、スタートアップとしては失敗だということです。日本では10年存続する会社はわずか5%だそうです。会社を存続させるよりも、できるだけ早く売却して、会社へ投資した費用の回収を目指す方が合理的だと言えます。IT分野の進化は益々加速しているので、5年も同じ製品の開発を続けているような会社の将来性には希望が持てません。5年以上会社を続けるくらいなら、むしろ一旦その会社を解散して、新しい分野の製品開発に取り組む新会社を設立した方が良いんじゃないでしょうか。これくらいのスピード感で会社を経営しなければ、Webサービスやモバイルアプリなどの先端分野で生き残っていくのは難しいのかもしれません。

ちなみに、Y Combinatorというのは米国シリコンバレーに在るスタートアップ専門ファウンダー兼ファーム(スタートアップ企業養成所)です。面接により選別した50〜60社程度の企業にまとめて少額投資を行い、これらの企業の創業者達を一箇所に集めて3カ月に渡って集中的に指導しながら、他のベンチャーキャピタルなどから大きな投資を受けられる状態まで育てるのがY Combinatorのやり方です。クラウドストレージ・サービスで最大のシェアを持つDropboxがY Combinator出身でもっとも成功した企業です。上の『Yコンビネーター』という本は、Y Combinatorの2011年夏学期に参加したスタートアップ企業創業者の面接から卒業までの動向を密着取材したドキュメンタリーです。TechStars500 StartupsAngelPadLaunchpad LAなど、米国では2010年頃から主要都市にこういうスタートアップ企業を支援するファインダーやファームがたくさん作られています。Open Network Labのように日本でもスタートアップを支援するファウンダーや施設が出現していますが、その数はまだ両手で数えられる程度しかありません。スタートアップ企業を取り巻く環境でも日米の間は悲しいほどの差が開いています。

日本では大手企業への就職や公務員になることを目指す保守的な若者が多いですが、そんな流れに逆らって、あえてリスクを取ろうとする若者も少しずつ増えているようです。たとえ大手企業に就職できても安定した人生などおくれないことに若者達も気づいているからです。こういう若者は外資系企業への就職を目指すケースが多いようですが、学生のうちから積極的にネットワークを築いて、スタートアップの起業を目標にする者も出てきています。また、一旦外資系企業に就職して3〜5年ビジネススキルを磨きながらコネクションを築き、それからスタートアップを設立するケースも多いようです。上の『ぼくらの新・国富論』の著者はこのようなコースを歩んで起業したアントレプレナーで、この本では同様のコースを歩んでスタートアップを立ち上げた人が何人も紹介されています(私の周りでも、独立起業したのは外資系企業で働いた経験を持っている人ばかりです。将来必ず起業しようと考えているなら、実力主義の外資系企業に就職した方が圧倒的に有利です)。大手企業の社員や公務員になれても、結局小さなマイホームかマイルーム(マンションの部屋)を手に入れる程度のゴールしか得られません。何かとこのゴールに到達できても、その後は住宅ローンや子供の教育費の支払いに苦しむ人生が待っています。少しでも頭の働く若者なら、こんな人生プランが明るいものだと思えないのは当然かもしれません。日本企業や公務員の生涯サラリーでは、運用に回せる不動産などの資産を入手することはほとんど不可能です。なけなしの貯蓄を元手に運用を試みても、余程の幸運に恵まれないかぎり大きく資産を増やすことは難しいでしょう。結局リスクを取らない人生プランでは、人並みの資産(マイホームやマイルーム)しか手に入れることはできません。野心を持った若者が外資系企業への就職を目指したり、スタートアップ設立に賭けるのは必然な流れのように思えます。日本国内のスタートアップを取り巻く環境まだまだ十分に整備されているとは言えない状況ですが、ググると、スタートアップの関連情報が相当数ヒットします。やはりスタートアップに注目している人や企業が増えているのは間違いありません。そういう言う私もその一人ですが、米国と同じやり方をしても日本でスタートアップが成功するとは思えません。米国と日本ではIT産業を取り巻く環境に大きな違いがあるからです(日本での事業展開を諦めて、シリコンバレーへ拠点を移すスタートアップ企業も出てきていようです)。

日本はブルーカラー労働者が大勢を占めている国なのに対して、米国はホワイトカラー労働者が社会カーストの上位層を独占している国です。日本で「モノづくり」という言葉が持てはやされるのも、これがブルーカラーにとって心地良い響きの言葉だからです。最近は「ITなんて虚業だ」などという人はさすがにいなくなりましたが、日本のブルーカラーの中にはホワイトカラーに対する差別意識を持っている人がいまだたくさんいます。額に汗して働くブルーカラーは「頭脳労働のホワイトカラーは自分達とは違う人種なんだ」という考えが前面に出てしまう傾向が強く、特に地方ではこの傾向が根強く残っています。日本の電機・家電メーカーの改革がなかなか進まないのも社内のブルーカラーの抵抗が大きいことも理由の一つではないでしょうか。人は長年続けてきた働き方や労働観念をそんなに簡単に変えられるものではありません。スタートアップの事業内容はいずれもWebサービスやネットビジネスが中心でホワイトカラーの最先端なので、日本ではスタートアップが広く社会に認知されることはこれからもないでしょう。国や地方公共団体がスタートアップ支援に本腰を入れることもありえない話だと思います。米国のスタートアップ・ムーブメントの資金源となっているのはすべて民間のベンチャー・キャピタルや個人のエンジェル投資家達です。若者を中心に日本でもスタートアップ・ブームが起きているようですが、それは東京限定の話であり、一般人は「一部の若者が楽して金儲けができる」と騒いているだけだと観ているのが実情だと思います。Google, Facebook, Twitterのように米国ではスタートアップから短期間で成長し、世界に大きな影響を及ぼしているIT企業がいくつも現れています。米国のスタートアップ・ムーブメントは多くの雇用を生み出しながら、国家繁栄の原動力にさえなっています。これに対して、日本では国民の大多数がブルーカラー労働者である方が体制側にとって都合が良いので、ホワイトカラーの先導者は異端扱いされます。日本人は「楽して金儲けをする奴ら」が大嫌いなのです。たとえ合法であっても、極端な動きをする企業へは国家権力機関から警告が出されることさえあります(ライブドア事件がその最たる例です)。いくらITが持てはやされても、ホワイトカラー労働者は自分達が社会的に異端者と見られていることを忘れるべきではないと思っています。

ここのところスタートアップ系の本ばかり読んできましたが、それもこの辺りで一区切りするつもりです。SOHOと違ってスタートアップは一人で始めることはできません。どんなに小さな製品を開発するにしても、最低1人は(できたら2〜3人程度の)協力者が必要です。本を読んで得られる情報には限りがあります。やはりコネクションを拡げないと何も始めることはできません。スタートアップ企業の経営者から話を聞ける機会でもあればぜひ参加してみたいのですが、東京に近い横浜に滞在しているので、そういう機会も探せば見つかるのではないかと思っています。

まとまりのない散漫な内容の記事になってしまい、自分でもちょっと呆れています。それに、ぜんぜん本の紹介になっていませんね。どうも私は書評を書くのが苦手みたいです。本記事で紹介した本について詳しく知りたいと思った方は、Amazonのカスタマーレビューを参考にすることをお勧めします。いままではブログ記事を書きながら上手く考えをまとめることができたのですが、今回はぜんぜんそれができませんでした。いまは大体月5冊程度のペースでKindleストアで本を買って読んでいます。ほんとんどIT関連のビジネス書です。もっとたくさん本を読みたいのですが、経済的な事情もあり、いまはこれが精一杯です。これに懲りずに、また本の紹介記事を書くかもしれません。行動や写真掲載が不要なので、ネタ切れ時の定番記事になりそうです。

posted by とみやん at 17:59| Comment(0) | TrackBack(0) | 日記

2014年04月23日

Tripod Commuication Day 2014に参加してきた

前の記事から一ヶ月空いてしまいましたが、本業の仕事の関係で、じつは、またしばらく信州を離れることになりまりした。いまは横浜に滞在しています。守秘義務があるので、本業の仕事について公開することはできませんが、近いうちに近況報告的な記事を書くつもりでいます。先に今日の動きについて記録を残しておきます。

本日東京・秋葉原で開催されたTripod Commuication Day 2014(TCD2014)というイベントに参加してきました。仙台の新興ベンチャー企業トライポッドワークス株式会社の自社製品の紹介や事業計画などをパートナー企業向けに発表するプライベートイベントです。ITイベントに参加したのは久しぶりが、ESECやETなどの一般者向けのイベントとは異なり、こういうイベントに集まるのは主催企業の関係者や報道関係ばかりです。同社は毎年東京でこのイベントを開催していて、私は去年の「Tripod Solution Day 2013(TSD2013)」にも参加しました(2013/04/24の記事)。

TCD2014のプログラム開始時刻は13:30でしたが、仕事の都合でどうしても早く行くことができず、16時に横浜を発ち、開催場所の秋葉原UDXギャラリーに着いたのは17時頃になってしまいました。結局最後のプログラムの『IT系メディアの編集長たちが語る、ITトレンドの今とこれから』というパネルディスカッションだけしか参加できませんでしたが、プログラム進行が遅れていたようで、丁度このパネルディスカッションの開始時に会場に入ることができたのはラッキーでした。
K3400006.JPG
去年のTSD2013でも刺激を受けて、参加して良かったなぁと思ったものですが、今年もいくつか得るものがあり、またしても色々と考えさせられました。特にパネルディスカッションの参加者が述べた以下の2つの意見が強く印象に残りました。
  1. 新製品の発表だけで膨大なページビュー数を稼げるのは、もはやApple社の製品くらいしかない。「このソフトウェア(やサービス)を使うと、従来の同種の物より1万倍の効果がある」というような具体的な利用対効果の数値が示されていないと、製品発表ニュースのページビュー数は大きく伸びない。「1万倍」なんて誇張しすぎの数値に聞こえるかもしれないが、(多少の誇張はあっても)大きな注目を集めるにはこれ位の数値は必要だし、革新的な製品なら本当にこういうレベルの利用対効果を生み出すことはある。

  2. 日本のメーカーにはまだまだ優秀な技術者は残っている。ユーザーの利用形態を根本的に変えるような「プラットホーム・チェンジ」型の製品やサービスを作ることができれば、日本の企業が躍進できるチャンスはあるんじゃないか。ただし、こういう製品やサービスは「ビジネスモデル」優先の企画や開発をやらないと生み出すことはできないと思う。

1の意見について「なるほどなぁ」と思ったのは、ソフトウェアやサービスの利用対効果を具体的な数値で示さないと製品情報の価値は低くなるという点です。他社の同種の製品と比較して優れている点だけ羅列することが多いですが、そんなことはどの製品でもやっています。ユーザーが本当に知りたいのは、その製品を使ったときの具体的な利点です。こういう数値を計測するには、ベータ版やプロトタイプレベルの製品をリリースして、できるかぎり多くのユーザーから利用情報を収集するしか方法はありません。あらかじめ利用対効果の数値をちゃんと計測することは、その製品を正式リリースしたときにどれ位売れそうかという予測にも役立ちます。利用対効果の数値を計測せずに、いきなり製品を正式リリースすることはバクチと同等の行為だと考えるべきです。他の製品を圧倒するような革新的な機能でも持っていないかぎり、その製品が売れる保証などどこにもありません。さらに言えば、たとえ革新的な機能を持っていたとしても、ユーザーがその機能を使いこなせるのかという問題もあります。どんなに優れた機能であっても、多くのユーザーが使ってくれなければ何の意味がありません。多大な時間を使って作り上げた機能なのに、それを使ってくれるユーザーはほとんどいなかった。ベンチャー企業の製品が失敗するパターンの中で、じつは、これが一番多いケースらしいです。これは、ソフトウェアやサービスだけでなくハード製品でも良く起きるケースです。他社より優れた機能を持っていたのに市場から消えていった製品はごまんとあります。優れた機能を実現することよりも、いかにユーザー・フレンドリーな製品を作るかが最優先事項なんだと肝に銘じて、エンジニアは日々の仕事をすべきだと思っています。

やはり元気なベンチャー企業の生の声が聞けるイベントに参加すると、大きな収穫が得られることが多いです。今後はこういうイベントを選んで参加していこうと強く思いました。

去年の夏にKindle Paperwhiteを入手して以来、すき間時間の多くを読書に使っていますが、最近は「スタートアップ」系の本ばかり読んでいます。一般人には「スタートアップ」より「ベンチャー」という用語の方が馴染みがあるでしょうが、Googleトレンドで調べると、最近は「ベンチャー」より「スタートアップ」というキーワードの方が検索件数は3倍位多くなっています。アメリカでは、スタートアップ企業のほぼすべてがWebやクラウドサービス系製品の開発を出発点にしています。日本でも同様の状況ですが、、最近になって、デバイス(ハード)製品の開発を目指すスタートアップ企業も出現してきているようです。ただし、既存の製品とはかなり毛色の異なるモバイル機器と連携するガジェットやウェアラブルデバイスなどです。スタートアップ企業に共通点があるとすれば、いずれもニッチ性の極めて高い製品やサービスで挑戦を始めていると点と、とにかく早く製品を市場に出すことを目指している点でしょう。市場をできるだけ限定化して、超短期間で開発した製品をさっさとリリースする。早期に利益を確保するために、最適な手段とコースを選択している訳です。これがスタートアップ企業の共通戦略です。ベンチャー企業の経営者から「最初の1〜2年はまったく製品が売れず、とにかく耐え忍んだ」なんて苦労話が出ることが良くありますが、スタートアップ企業にとってはこんな話は無縁の世界です。最初の1〜2年できるだけ大きな利益を確保して3〜5年以内に会社を売るというのが、アメリカのスタートアップ企業の標準コースになっています。そして、会社を売って得た資金を元手にして、さらに新しいスタートアップを始める。このサイクルを3回も繰り返せば、サラリーマンの生涯賃金をはるかに超える資産が得られ、残りの人生は働く必要がなくなる。アメリカでは、30代のうちにここまで到達してしまう人がどんどん現れています。「どうやってスタートアップを始めるか」最近はこればかり考えていて、ググっているうちに、日本国内のスタートアップ企業とその製品情報を目にすると、憧れの気持ちが沸き上がってきます。

私は東京ビッグサイトや幕張メッセなどで開催される大きなITイベントに行く気力はもう無くしました。(年寄り臭いですが)歳をとって、混雑するイベントへ行くのが億劫になってしまったいうのもありますが、こういうイベントを見学しても、結局残るのは疲労感だけで、実になりそうな物を得られることはまずないと悟ったからです。ESECやETみたいなITイベントへ行くなら、参加するのはカンファレンスやセミナーだけにすべきで、展示会場を観て回っても収穫はほとんどないと思っています。各展示ブースに提示されている製品情報などはWebページで得られる情報と大差ありません。それに、展示会場を一周回っだけで、私は必ず「もう、これでいいやー。疲れたので出よう」という気分になります。同じような経験を持っている人は多いんじゃないでしょうか。大きなITイベントは一種のお祭りだと思いますが、祭りを本当に楽しめるのは見学者ではなく展示者側の立場の方です。展示企業にとって、こういうイベントは既存製品や新製品を大々的にアピールできる絶好機会です。私も一度だけ知人の会社を手伝うために3日間展示者としてESECに参加したことがあります。そのときはものすごく疲れましたが、閉会時にはそれなりの充実感を味わえました。こういうイベントで展示者として多くのブース来場者(そのほとんどは初対面の人)と話すは、なかなか味わえない貴重な体験でした。イベントの閉会後に主催者から集計来場者数8万人とか発表されますが、結局一人の見学者は8万分の1の存在でしかありません。天邪鬼な意見ですが、一般者としてITイベントへ参加する価値は来場者数の多さに反比例すると思っています。Developer Summitのような来場者数千人程度のイベントが、一般参加者が充実感を味わえる限界じゃないでしょうか。この規模のイベントなら、自然に参加者同士が集まってグループができ交流が生まれる余地はまだありますが、来場者が一万人を超えてしまうと、特定のグループ内でしっかりと連絡を取り合って、あらかじめ会合の予定などを決めておかないと参加者同士が交流を図るのは困難です。
posted by とみやん at 21:30| Comment(0) | TrackBack(0) | 日記