AWS Device Farmでモバイルアプリのテスト

　すいません。すっかり遅くなりましたが、iOS Second Stage Advent Calendar 2015です。アプリ開発でやっぱり重要なのが、テストです。モバイルアプリの場合は、実機での確認も必要で機種も多いので特に大変です。そういった所で最近注目を集めているのが、インターネット経由で実機を操作するクラウドサービスです。

モバイルアプリ検証のクラウド型プラットフォーム

---

　スマホアプリのテスト・プラットフォームの話をすると、シミュレータの話と思う人が結構います。シミュレータは、画面サイズのみ再現するのみで内部の動作のテストは出来ません。クラウド型のテスト・プラットフォームは、インターネットの先に実機がつながっているのがポイントです。AWSもAWS Device Farmという同様のサービスを出しています。イメージ的には、下記のような図です。※あくまで想像図です。

　たぶん物理筐体から、何十、何百というデバイスをニョキニョキと繋いでいるのだと思います。そのケーブルはiPhoneであるならば、きっとAmazonベーシック ハイクオリティーライトニングUSB充電ケーブルでしょう。ちなみにクラウドサービスで、物理筐体＆デバイスが出てきて違和感あるかもしれません。クラウド事業者にとって、クラウドは仮想化の話ではなく、物理の問題なんです。きっと

AWS Device Farmの凄いところ

---

　AWS Device FarmはAndroidを中心に100以上の端末・OSの組み合わせを揃えています。モバイルアプリを運用する所で難しい点は、特定の端末・OSのみ発生するケースがどうしても出る点です。主要な機種は揃えるものの、複数のOSを揃えるのは現実問題厳しいです。そういった時に、スマホのテスト専門会社に依頼するというのも1つの手段ですが、コスト的に難しい場合も多々あります。そういった時に、AWS Device Farmを始めとするクラウド型のテストプラットフォームの活用を検討してみましょう。
　またAWS Device Farmの凄い所としては、iOSのテストが出来るところです。この手のサービスの性格上、実機を直接操作する必要があります。Androidはそういった仕組みが整っているのですが、iOSについてはデバイスをリモートで操作する仕組みは余りありません。無理やり実現しようとすると、JailBreakの必要性もあるかもしれません。それにも関わらずAWSは実現しています。Appleと交渉したのか、その他の方法で実現したのか解りませんが、とにかく正式なサービスとして提供できてるAmazonは凄いです。

AWS Device Farmを試してみる

---

　AWS Device Farmは製品版となるipaをアップロードしてテストします。ということで手軽に試すには、iTunesストアから落としたアプリをアップロードしてテストしてみましょう。Macだとホーム->ミュージック->iTunes->iTunes Media->Mobile Applicationsにあります。

プロジェクトの作成

　Device Farmは現在、米国西部Oregonリージョンのみ利用できます。ハッキリ言って場所は全然関係ないので、気にせず使いましょう。サービスを選んだらプロジェクトを作成します。

アプリケーションのアップロード

　次にアプリケーションをアップロードします。iOSの場合はipaで、Androidの場合はapkです。拡張子から勝手に判断してくれるので、特に気にする必要はありません。
　

テストの種類の選択

　次にテストの種類を選択します。AppiumによるJUnit/TestNGのテストやCalabash,UI Automation,XCTestなど自作のテストコードをアップロードするものと、Fuzzテストという起動・実行のテストがあります。ここでは、Fuzzテストを選びます。

テスト対象のデバイスの選択

　テスト対象のデバイス・OSの組み合わせを選択します。iOSの場合は端末バリエーションというより、OSのバリエーションという側面が強いでしょうね。デフォルトのままでも問題ないと思います。

デバイス設定

　デバイスを選んだら、次は設定（Config）を行います。ここで他のアプリをアップロードすることにより連係のテストも出来る（はず）です。また、位置情報や言語設定もできます。

実行＆レポート

　設定終わって実行すると、バックエンドで自動的にテストが始まります。その後に、レポートも自動生成されます。下記の例だと、エラーが発生しています。クリックしていくと、どこでエラーが出たのかも表示されます。

感想

---

　まだ動かしてみたというレベルですが、可能性を感じます。Androidに較べてiOSはまだまだこれからという部分もあると思いますが、今後はCI等と組み合わせてテストの自動化につなげていきたいと思います。特にSwift化で、クラウド上のサーバサイドのビルドも容易になるはずなので、来年辺りノウハウが一気に広がるかもしれませんね。

プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar
http://qiita.com/advent-calendar/2015/ios-2

消費税の逆進性と軽減税率と定額給付の話

　基本的なスタンスで言うと、私は消費税という税制が好きです。何故かというと、シンプルだから。消費税には、複雑な税金の計算の仕方もその人の状況によって免除とかも、（一部あったりしますが、）基本的にはありません。比較的公平な仕組みという観点で、消費税は好きです。そんなこともあり、最近の軽減税率の議論はバカバカしいと思います。

消費税の逆進性の話

---

　消費税が公平と話をすると、同じ金額でも貧乏人も金持ちでは負担率が全然違うという意見があります。いわゆる消費税の逆進性の話ですね。もっともな話だけど、世の中消費税だけのシンプルな税制ではなく、所得税や住民税・固定資産税もあるので、その辺りでカバーできてるのではと考えています。それよりかは、給与所得者ではなくいわゆる資産家や年金生活者からも遍く徴収できる仕組みとしては素晴らしいのではないでしょうか。また逆進性が問題ならば、別の方法でフォローできます。

消費税の逆進性と定額給付

---

　逆進性が問題であれば、定額給付でカバーするという手もあります。例えば、所得が100万円の人が10万円の消費税を負担するのが問題であれば、10万円分をそっくり給付すれば良いのです。給付を前提に税額設定すれば、逆進性を解消しつつ税収増のラインも出てきます。控除という案が必ず出てくると思いますが、事務手続き考えると簡素な給付の方が楽でしょう。

軽減税率の話

---

　一番馬鹿らしいと思うのが、軽減税率です。例えば影響の大きい食品については軽減税率を適用するというやり方です。これは、3重の意味で嫌いです。
　1つはせっかくシンプルだった消費税という仕組みがややこしくなるからです。例えば、食料品を対象とすると外食はどうするとか惣菜はどうするのかとか判断が必要です。方針が決まったとしても、その仕組みを構築する必要があります。システム的なことを考えると、マスタ管理してどの品目だと軽減税率の対象になるかとか、セット商品など組み合わせた場合にどうするかなどのロジックが必要になります。小売店を中心にその投資が必要になり、その投資分は結局は消費者に跳ね返ることになります。儲かるのはシステム屋だけです。（私はシステム屋ですが。）
　2つ目は、政治や利権の温床となることです。先ほどの食料品の話や新聞など、どの項目を入れるかは人間の判断の話です。そうすると、対象にするしないは政治の範疇になります。となると、俄然頑張る人が出てきくるので嫌いです。もちろん元々消費税自体が極めて政治性の強いものですが、その中の項目まで恣意的に選べるとなると、収拾がつかなくなると思います。延々この議論ばかりして、もっと大事な話しろよと思います。
　最後は、逆進性の話です。消費税は逆進性が強く庶民の財布を直撃するから軽減税率いれろというのはロジック的におかしな部分含みます。軽減税率の対象は金持ちも含まれるから。じゃぁ、金持ちを除くとかしたら、複雑怪奇な仕組みになります。

まとめ

---

　軽減税率の話が予想通りの展開になって、辟易として余りフォローしていません。世の中、迷ったらシンプルな仕組みの方が良いですよ。当然、そこで救われない人は出てきますが、別の仕組みで救う方法を考えた方が全体的にシンプルになります。1つの仕組みの中で全て解決しようとしたら、複雑怪奇になります。消費税で、低所得者は困る。なら、低所得者向けの対策の仕組みを、社会保障でカバーする。こんな感じの方が、結果的に上手くいきます。消費税の仕組みで低所得者対策までするからややこしくなるのです。これ何事でも同じです。

See Also:
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

貯蓄は三角、保険は四角（保険の話）

　たまに若い人に話しているのですが、保険の知識は重要です。何故なら保険はとっても高い買い物だからです。20歳から60歳まで40年間、月1万円の保険に入っていたとしたら累計で480万円です。何も考えずに入っていると、これが2倍とか3倍とかに簡単になります。ということで、保険関係の本を10冊くらい読むと良いですよ。以下、覚えておくとよいポイントです。

医療保険と「貯蓄は三角、保険は四角」

---

　まずは覚えておくと良いのが、保険の役割です。その役割を端的に表現するのが、「貯蓄は三角、保険は四角」という言葉です。これは、どういうことでしょうか？保険の最大のメリットは、契約したその瞬間から保険の全額がおりるということです。下の図を見てください。

　たぶん気の利いた保険屋であれば、上記のような説明をして勧めると思います。一方で、この言葉には保険屋が説明しない裏があるのです。ある程度の蓄えがあるのであれば、（医療）保険はそれほど重要ではないということです。日本の1日あたりの入院費の平均は、1万6千円くらいらしいです。日数の平均は30日くらいです。とすると、大体50万円くらいです。こういう話をすると、高額の治療費の場合もあるし、日数が長い場合もあると反論されます。日本の場合は、高額療養費制度があるので一定額以上は払い戻しを受けられます。また、入院日数についても元々保険は80日くらいを保障しているのが殆どです。また、途中で退院した場合は、その後が保険代でなかったりと。ということで、100万くらいの貯蓄がある人は医療保険必要かどうかを考えてもいいでしょう。（若くて金のない時に、一発アウトにならないように掛け捨ての保険入るのはよいと思います。）

死亡保障

---

　次に死亡保障・死亡保険です。これは、まず何故必要なのか考えてみましょう。わりと入社1年目の独身の新人が何も考えずに高額の死亡保障がついた保険に入っているケースがあります。何故必要なのと聞くと、死んだ時に困るでしょうという返事が来ますが、死んだ本人は間違いなく困りません。これだけは、断言できます。
　死亡保障が必要なのは、残された遺族が生活に困る場合です。その生活を支える為に、死亡保障を付けます。その為、殆どの人が死亡保障を考えるタイミングは、子供が産まれたタイミングと考えておくとよいでしょう。結婚のタイミングも1つかもしれませんが、元々独立して生活していた成人同士の場合が多いので、そこまで必要でないケースも多いです。

終身保険

---

　保険が解りにくい原因の1つに、終身保険があります。これは一生涯の保障がつき、掛け捨てのように無駄になりませんよというウリ文句で殆どの人が入ります。保険の中身を分解すると、そもそも終身保険というものはありません。実は定期保険のバリエーションの一つで、106歳（女性は109歳）で満期の定期保険を60歳までに保険料を全部払ってしまうというものです。これ以上でも以下でもないです。その辺を考えて入るとよいですよ。
　終身保険には、税制面の優遇などメリットも多いです。一方で、保障という意味では106歳分払い込むので割高になるケースもあります。保障部分は掛け捨てで、相続税対策を終身保険とかも1つの手なのかもしれません。（まだそこまで検討したことないです。）

死亡保障の必要な金額

---

　定期保険だと、30歳の時に3,000万の死亡保障を付けるのと、40歳の時に3,000万の死亡保障を付けるのでは、月々の掛け金が全然違います。何故なら、死亡する確率が違うからです。その点をついて若いうちに終身保険を勧められるケースが多いです。一方で、30歳の時と40歳の時で同じ死亡保障の金額が必要なのでしょうか？
　基本的には子供が成長するまでと考えると、子供が0歳の時と10歳の時でも必要なお金も違ってきます。10年間分、残すお金は下げてもよいのです。ということで、定期保険が損という訳ではないです。私は、自分と子供の年齢を考えて20年の定期や10年の定期など組み合わせて構成しています。

まとめ

---

　保険は大事なので、一度はよく考えましょう。その際に、まずは保険屋に聞くということをすると、カモがネギ背負って行くみたいなものなので、自習した上で話しに行くように。あと、どっかで保険営業の報酬の仕組みも解説します。

生命保険はだれのものか

See Also:
新社会人に向ける保険の選び方
もし私が死んだら？或いは、遺族基礎年金と遺族厚生年金について
生命保険について勉強してみた
勝手に補足。学資保険は必要か？
『本当の問題は死ぬに死ねない時』は、生命保険営業の殺し文句
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

WishリストからKindleの安売り情報の通知

　最近の読書体験を振り返ると、9割近くがKindleでの読書です。読みたい本を買っておいて、好きな時に好きな本を読めるのは非常にありがたいです。一方で、そのスタイルだと積読が多くなります。読みたいリストは無数にあって積読が多いのであれば、買うタイミングは安くなった時に買っておくのがベストでしょう。Amazonでは、様々なKindleセールが行われます。しかし、その告知方法は充分ではないので、ユーザ自身がウォッチしておく必要があります。人間がやるのもバカバカしいので、クローラーにやってもらいましょう。

実現方法案

---

　実現する為には、下記の前提・手順を踏みます。

1. いつか読みたい本は、ウィッシュリストに入れておく
2. ウィッシュリストは公開にしていて、認証なしでアクセス可能にしておく
3. クローラーはウィッシュリストを取得して、対象の商品一覧を取得する
4. 対象商品を1件づつ巡回して、Kindleの商品であれば値引率をチェック
5. 一定の値引率だと通知

実装

---

　それでは、順番に実装方法を考えていきましょう。

ウィッシュリストの取得

　Amazonにログイン後に、http://www.amazon.co.jp/gp/registry/wishlist/にアクセスしてください。自分の、1つ、もしくは、複数のウィッシュリストがあるはずです。

そこをクリックすると、固有のIDがついたウィッシュリストのURLのページに遷移するはずです。私の場合は、次のURLです。
http://www.amazon.co.jp/gp/registry/wishlist/3G4653SB32HMZ/

ウィッシュリストの公開設定

　リストの公開設定は、右上の方の「リストの設定」から行えます。ポップアップから該当のリストを選んで、公開とするだけです。一方で、リストを公開とすることにより、リスクも皆無ではないです。内容を理解した上で、自己責任でお願いします。

対象商品の一覧を取得する

　もはやスクレイピングの仕方を忘れつつありますが、こんな感じで取れます。classの値がa-link-normalを取得すると、ページ本体とレビューのURLが取得できます。本体の方は、相対パスなので補完して表示しています。

require 'nokogiri'
require 'open-uri'

doc = Nokogiri::HTML(open('http://www.amazon.co.jp/gp/registry/wishlist/3G4653SB32HMZ/'))
objects = doc.xpath("//a[@class='a-link-normal']")
objects.each {|element|
  url = element[:href]
  puts "http://www.amazon.co.jp#{url}" if not url.match(/http/)
}

　さて問題は、リンク先のページの商品がKindleかどうかです。Amazonは商品をASINというコードで管理しています。紙の本は、ASIN=ISBNとなっています。Kindelやその他の商品の場合、Amazonが付番するコードになっています。ISBNかどうかはコードをチェックすれば出来るけど、Kindleか他の商品かはコードからは、読み取れません。（体系あるのであれば、教えてください。）
　ということで、効率悪いけど一度アクセスして個々に確認する方法をとります。この方法のメリットとしては、紙の本しか無かったものがKindle化している場合の検知もできます。

詳細ページの取得

　詳細ページについては、UserAgentを偽装しておかないと503になります。（いつからだっけ？）本来であれば、API経由で取ることを推奨しますが、今回は省略です。対象ページのカテゴリーは、IDがnav-subnavのdeta-categoryの属性を参照すれば取得できます。

require 'nokogiri'
require 'open-uri'

UserAgent = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 '

url="http://www.amazon.co.jp/dp/4787710176?_encoding=UTF8&colid=3G4653SB32HMZ&coliid=I168IVRW8TS0E4"
url="http://www.amazon.co.jp/ebook/dp/B00VESYKDU/ref=tmm_kin_swatch_0?_encoding=UTF8&coliid=I3I1RV6FI82PJ5&colid=3G4653SB32HMZ&qid=&sr="
doc = Nokogiri::HTML(open(url, 'User-Agent' => UserAgent))
puts doc.xpath("//div[@id='nav-subnav']").attr("data-category")

　紙の書籍の場合はbooksで、Kindleの場合はdigital-textとなります。

紙の書籍の場合の処理

　紙の書籍の場合は、Kindleのリンクがあるか探してみましょう。あまり良いやり方ではないですが、Kindle版がある場合は全てのフォーマットのうちで一番左に表示されます。ということで、とりあえず一番左のものをとってKindleだったら処理対象とするという方針にします。

ブラウザで見ているものと、JavaScriptが動かないOpen-URIで取得したもので多少差異があるので戸惑うかもしれませんが、下記のような感じで取得できます。

if doc.xpath("//span[@class='a-button a-spacing-mini a-button-toggle format']/span/a/span").first.text == "Kindle版"
    puts "http://www.amazon.co.jp#{doc.xpath("//span[@class='a-button a-spacing-mini a-button-toggle format']/span/a").first[:href]}"
end

※いろいろ面倒臭がってるので、マサカリ飛んできそうですが。

値引き情報の取得

　Kindleの値引きは、2種類あります。ポイント還元と純粋な値引きです。今回は、値引きを対象とします。値引き情報は、savingsRowクラスの中に格納されています。あまり綺麗な形で収まっていないので、正規表現等を併用します。

off_info = doc.xpath("//tr[@class='savingsRow']/td[2]").text

通知

　任意のしきい値以上の値引率だとメールで送ると言った感じの実装をすればよいです。メールを送るだけであれば、AWSのSESとかがお勧めです。

感想

---

　構造化していなので面倒くさいです。ウィッシュリストだけスクレピングして、後はProduct Advertising APIを使う方が絶対楽です。Rubyでスクレピングするのであれば、Rubyによるクローラー開発技法という本があります。

Rubyによるクローラー開発技法 　巡回・解析機能の実装と21の運用例

See Also:
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar
http://qiita.com/advent-calendar/2015/crawler

ElectronでSwagger Editorをアプリ化

　大幅に遅れてしまいましたが、Electron Advent Calendarの16日目です。秋過ぎからSwagger,Swaggerと言っていたら、色々なお鉢が回ってきました。ついでに、調べようとググると自分のブログやTwitterの呟きがぶつかってしまうようになっていました。ということで、毒食らわば皿までということで、もう1つ。

Swaggerのダメな所

---

　使いはじめると、いろいろ気になる所があります。その中での最大のものが、Swagger Editorの準備の面倒臭さです。Swagger EditorのGetting Startを見ていると、下記の手順で始められますと書いています。

git clone https://github.com/swagger-api/swagger-editor.git
cd swagger-editor
npm start

　簡単ですね。たった3つのコマンドでスタートできます。と思うかもしれないけど、このコマンド実行するには、gitコマンドとNode.jsがインストール済みである必要があります。エディタ1つ使うために、これを要求するのは少しナンセンスでしょう。Swagger Editor自体は中々優れものなだけに、これは残念です。という訳で、少しユーザフレンドリーな配布方法を考えてみましょう。

ElectronでSwagger Editorをアプリ化して配布する

---

　Swaggerの実体は、Node.jsをはじめとするJavaScriptです。ということであれば、Electronでアプリ化しやすいのではないでしょうか？試してみました。前提として、gitとnode.jsをインストールしていることとしています。

Electronのインストール

　まずは、Electron関係のモジュールを用意します。electron本体のelectron-prebuiltとアーカイブ化するasar、配布用のelectron-packagerをまとめてインストールしてしまいましょう。

npm install -g install electron-prebuilt
npm install -g asar 
npm install -g electron-packager

Swagger Editor関係の準備

　次にSwagger Editor関係の準備をしましょう。最初の手順は、公式のGetting Start通りです。

git clone https://github.com/swagger-api/swagger-editor.git 
cd swagger-editor 
npm start

npm startすると必要なモジュールを取ってきて、関係ファイル等を生成してくれます。次に、httpdサーバが必要なので、node-web-serverもインストールしましょう。

npm install node-web-server

Electron化にむけて、関連ファイルの作成

　swagger-editorディレクトリ直下のpackage.jsonに、起動するjsファイルの指定を追記します。これは、Electronの流儀というより、Node.jsの流儀のようですね。下記の例は、licenseの下に追加しています。

"description": "Swagger Editor source", 
"license": "Apache-2.0", 
"main":"main.js", //←この一行追加 
"authors": [ 
　　"Mohsen Azimi <me@azimi.me>" 
],

　次にmain.jsを作成します。この辺りは、Electronの流儀にしたがっています。appとかはElectronのモジュールです。他には、node-web-serverを追加しています。単純にrequireで読み出すのか、remote経由で呼び出すのか色々ありますが、とりあえずはrequireで動かしています。

'use strict'; 

var app = require('app'); 
var BrowserWindow = require('browser-window'); 
var nws = require('node-web-server'); 
require('crash-reporter').start(); 

var mainWindow = null; 

app.on('window-all-closed', function() { 
　　nws.stop(); 
　　if (process.platform != 'darwin') 
　　　　app.quit(); 
});

app.on('ready', function() { 
　　nws.run({ 
　　　　host: "localhost", 
　　　　port: 8080, 
　　　　docRoot: "dist", 
　　}, __dirname); 

　　var screen = require('screen'); 
　　var size = screen.getPrimaryDisplay().size; 

　　mainWindow = new BrowserWindow({ 
　　　　width : size.width, 
　　　　height : size.height, 
　　　　resizable : true, 
　　　　"web-preferences": { 
　　　　　　"web-security": false 
　　　　} 
　　}); 

　　mainWindow.loadURL('http://localhost:8080/'); 
　　mainWindow.on('closed', function() { 
　　　　mainWindow = null; 
　　}); 
}); 

次にdist->scriptsフォルダに、下記の3ファイルをインストールします。バージョンは適当に、最新のものに変えておいてください。

curl -o jquery.min.js http://code.jquery.com/jquery-2.1.4.min.js

最後にdist/index.htmlを編集します。bodyの後に、を追加します。

ここまで出来たら起動です。swagger-editor直下で、下記のコマンドを打ってエラーがでなければ成功です。

electron .

　どうでしょうか？無事、アプリが起動されたでしょうか？ここまでで、一旦ブラウザ起動から独自にパッケージ化したアプリに切り替えることが出来ました。しかし、起動にはElectronからです。これだと、依然使い手を選ぶことには変わりありません。ということで、配布可能な形式にしてみましょう。

electron-packager ./swagger-editor-electron/ swagger-editor --platform=darwin --arch=x64 --version=0.36.1

　とりあえずMac版を作ってみましょう。Windows版は、platformの部分に,win32をつければ作れます。作ってみたところ、起動しなかったので誰かおしえてください。また引数の--versionの0.36.1はElectronのバージョンです。

　とりあえず出来たのを、ここで配布してみます。動くかどうか試してみてください。ちなみに作り方とか色々問題あると思うので、ぜひご指摘くださいな。

感想

---

Electron、面白いです。使い所も多そうなので、もう少し勉強してみます。それにつけても、深刻なNode.js力の不足よ。勉強しましょう。

APIデザインケーススタディ ~Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方 (WEB+DB PRESS plus)

See Also:
Swaggerとは何か？
クラスメソッドさんの勉強会で、Swaggerの話をしてきました
SwaggerでAWS API Gatewayを作成する
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

今年読んで良かった本 2015

　一人Advent Calendar2015です。今年読んだ本で良かった本を振り返ってみようと思います。Amazonの履歴を見ると、今年は200冊くらい買ってたようですが、圧倒的にマンガが多かったです。1冊読むと、ついつい最後まで買ってしまうのですよね。恐るべし、Kindle。あと田中芳樹の銀河英雄伝説とかアルスラーン戦記とか、昔読んでたのが電子化してて懐かしくて買ったのも沢山ありました。ということで、実質的にKindleで新しく読んだのは50〜60冊くらいでした。何か少ないなぁと思ったのですが、通勤の行き帰りでHuluで宇宙兄弟とかアニメを割りと多めに見てたので、その影響も大きいです。恐るべし、Hulu。

2015年読んだ中でのお勧め本

---

繁栄　明日を切り拓くための人類１０万年史

　そんなこんなで、今年はインプットが少なかったです。その中で一番おもしろいと思ったのでは、繁栄　明日を切り拓くための人類１０万年史 です。この本は、経済を主眼に人類の発展を紐解いていくという話でして、銃・病原菌・鉄とかが好きな人はきっと面白いと感じると思います。一番なるほどなと思ったのが、あるレベルの文明を支えるには、母数となる一定以上の人口が必要ということです。南太平洋の島々に移り住んだ人々の歴史を観察すると、島が小さく周りから隔絶した環境だと技術は簡単に失伝しているそうです。狩りや釣りの技術も失伝している場合もあったそうです。つまり文明を支える基礎は、多様性ということです。この本は、どこかでちゃんと紹介しようと思います。

繁栄　明日を切り拓くための人類１０万年史

データの見えざる手　ウエアラブルセンサが明かす人間・組織・社会の法則

　勉強になった本といえば、データの見えざる手　ウエアラブルセンサが明かす人間・組織・社会の法則です。今年は、IoTや機械学習がブームでした。それを10年近く研究や実証実験を続けてきた成果が1冊にまとめられていて非常に参考になります。凡百のIoT本や機械学習本の100倍参考になります。ちなみに、この本を読んだ1週間後くらいに、クローズドな勉強会でこの本を書いた人のグループの講演を聞くことが出来ました。偶然だったのですが、裏話・周辺の話が聞けて面白かったです。

データの見えざる手　ウエアラブルセンサが明かす人間・組織・社会の法則

ネアンデルタール人は私たちと交配した

　個人的に好きなテーマが、ネアンデルタール本。今年、読んだのはこれ。ネアンデルタール人は私たちと交配した
　何故ネアンデルタールの話が好きかというと、数年で従来の学説をひっくり返すような新発見がどんどん出てくるからです。この本の新説（？）はタイトルのとおりです。面白かったのは、考古学ではなく遺伝子の研究から裏付けをとっていることです。今の技術では、だいたい数万年前の遺伝子を抽出するのが限界のようです。そういう意味で、ネアンデルタール人は限界に挑戦しつつ研究というところで、その手法とか色々を知れました。

ネアンデルタール人は私たちと交配した (文春e-book)

本を出したい人の教科書　ベストセラーの秘密がここにある

面白いという本ではないのですが、本を出す時に考えるべきが一番まとまっているなぁというのがこの本です。本を出したい人の教科書　ベストセラーの秘密がここにある
心に残っているのが、誰でも本を出せるんだとマインドが出来れば、必ず本は出せるということです。事実、著者主催のセミナーで、クラスの中で一番出来の悪かった人が本を出すことによって、クラスの同期生全員が彼女が出せたのなら自分も出せるはずと思ったそうです。その結果、そのクラスの出版率が一番高かったそうです。1つの真理ですね。

本を出したい人の教科書　ベストセラーの秘密がここにある

新書系

イスラーム国の衝撃
ビスマルク　ドイツ帝国を築いた政治外交術
　この辺り、知識に無いところだったので勉強になりました。一冊読んでるだけでも、ニュースを聞いた時のインプットが全然違います。そういうところは、新書で補完するのもいいのではないでしょうか？

スマホに満足してますか？~ユーザインタフェースの心理学~
　iPhoneのUI系を作っていた増井さんの本です。スマホのUI設計を考える上で非常に参考になりました。人間の感覚は騙せるので、実際の経過時間と心理的な経過時間は違うということがよく解ります。処理時間が掛かるところに、少しアニメーションやバイブなど注意を別にひくものの重要性が分かりました。インターフェイスの設計をする人は、必ず読んでおきましょう。

SF・娯楽

　 火星の人

この本読んで、久々にSFをいろいろ読むようになりました。最近のSFって読んでなかったのですが、最新の科学やテクノロジーが反映してあって面白いですね。

　遊郭経営10年、現在、スカウトマンの告白　飛田で生きる

　大阪最大の闇、飛田新地が少し解りました。あと、この本書いた著者の身の安全が大丈夫か心配になっています。

感想

---

　振り返ってみると読書体験＝Kindle体験になっていることに気が付きました。恐るべしAmazon。そして、Huluも併せてスキマ時間を確実に奪っていくスマホ・タブレット、恐るべしです。来年は、スキマ時間のインプットを効率的にするのと、まとまった思索の時間も取れるように仕組み考えようと思います。

See Also:
火星での暮らし方
今まで読んで良かった本　100冊
ジュンク堂書店さんに聞いてみた。「売れると思ったのになぜ売れぬ」の書籍リスト
本の読み方がもう少し上手くなるの５つのTips
半端でない成毛さんの影響力　「本は10冊同時に読め！」
社会人向けに本の選び方について一言

プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

一介のブロガーが技術書を書くに至った経緯。或いは自分戦略

　全部俺の15日目くらいです。昨年、今年と1冊づつ技術書をだしています。勉強会に行くと、たまに経緯を聞かれるので共有しておきます。

直接的なキッカケ

---

　直接的なきっかけは、編集者からメールでお誘いがあったことです。Rubyのクローラー関係の記事をブログに幾つか書いていて、それを見た編集者が声を掛けてくれたという経緯です。当時はRubyでクローラーに関する情報も少なく、幾つかのワードで検索すると私の記事が常にトップに出るという状態でした。ということで1冊目のRubyによるクローラー開発技法は、著者である私の持ち込み企画ではなく、編集者の企画で書ける人を探していたというのがスタートです。
　発売された当時は仕事やプライベートで勉強会やセミナー等で登壇していたことは何度もあったので、それ経由で声を掛けられたと思われることもありますが、実は全く関係なかったのです。また声を掛けられた当時は、完全に匿名でブログ書いていたのでリアルの知人でこのブログのことを知っている人もいませんでした。

間接的なキッカケ

---

　上記のようにキッカケは完全に偶然でした。ただし、偶然を呼びこむ要素は幾つかありました。1つはニッチな分野で強みを発揮していたことです。Rubyの言語本となると、Ruby界には重鎮が沢山いて、私なぞ出る幕もなかったです。しかし、クローラーだとRuby界隈の人には特に興味を示している人がおらず、業務でやっている人も表に出てきていない状況でした。
　次にマインドの問題です。私はこの業界に入って暫くして、いつかは技術書を1冊でも書いてみたいなと思っていました。その為の具体的な方策については考えていなかったのですが、素振りがてらにブログは書き続けていました。結果的には、そこが直接的に結びついたという訳です。

AWS本の場合

---

　ちなみに2冊目のAWS本については、1冊目が好調だったこともありAWS本も書くかという打診がありました。AWSの場合は、ユーザーコミュニティの層が厚いです。今年も何冊か出ましたし、他にも書いているという話を知っています。このような状況になると、出版社はコミュニティでの実績がある人に声を掛けるので、クローラー本の時のようなブログに書いていたからというキッカケは起きないと思います。ということで、ニッチ本とは違う戦略が必要になります。

打席に立つ

---

　もう1つ大切なのが、チャンスがあったら飛びつくことです。冷静に考えると、本を書いたことが無い人間が400ページ超の本を仕事の傍らで書くのは無謀です。当初、本を書いたことがある人間に聞いてみたところ、無理無理と言われました。でも、1度しかないチャンスかもしれないので、思い切ってやってみたところ出来ましたというのが現実です。ということで、やれるかやれないかではなく、やりたいかどうかで判断するのも大切ではないでしょうか。
　ソフトバンクの孫さんも、こう言っていたそうです。「チャンスの女神は前髪しかない。今の私の結果は、前髪を掴み続けた結果だ。」

その他の補足

---

　本出して儲かりますかと聞かれますが、儲かりません。投入した労力との対価で考えると、割に合いません。技術書は、完全に自分のブランディングの為と割り切っています。そこの部分、いつか改善しないと日本語の技術書の未来は暗いのではと思っています。

Rubyによるクローラー開発技法　巡回・解析機能の実装と21の運用例

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく

See Also:
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar