プログラマでありたい

おっさんになっても、プログラマでありつづけたい

2016年の注目技術

 昨年に引き続き、今年の注目技術を考えてみます。業界の展望というより、個人的に力を入れる予定のところです。まずは昨年の振り返りです。

2015年に注目していた技術



 こちらに書いている通り、2015年はクラウドネイティブが加速するということで、その役割を担うであろうLambdaやCognitoあたりを注目していました。またそれが最初にスタンダードになるのがモバイルということで、その辺りを学習していきました。また一部、AWS本で紹介するなど取り入れています。2015年はAPI Gatewayが登場したこともあり、クラウドネイティブ化は更に進んでいると思います。

2016年の注目技術



 それでは2016年はどうでしょう?もちろんクラウドネイティブ化は、どんどん進んでいくでしょう。AWSの場合、その肝となるサービスはLambdaやAPI Gateway,DynamoDBなどですが、それらのサービスをみていると(ちょっと違うものもありますが)料金体系はリクエスト単位に近いです。またサービス自体が、イベント・ドリブン的なものが増えているように思えます。マイクロサービスという言葉が注目されたように、サービスが小さなサービスの集合体となりつつあります。
 そうなると大切なのが、サービス間の連係です。連携方法としては、WebHookのような1対1の連係とプッシュ通知のような1対多の連係が多いのではないでしょうか。WebHookの場合は、API GatewayとLambdaの組み合わせで簡単につくれるようになりました。あと足りないのは、プッシュ通知の技術ではないかと思います。SNSやiOS,Androidのプッシュ通知はミリ秒というより数秒〜数分のDelay前提のような気がします。マイクロ秒単位のものが必要とされる場が増えてくると思います。HTTPであれば、WebSocket(サーバープッシュ)的なイメージです。あとWebRTCとか。この辺りをサービス化したものも既に幾つかあります。今年は、それをどう使いこなすかという部分に注目していこうかと思っています。まぁ何とも地味な分野で言語化が難しいのですが、今のところはその辺りを考えています。
 もう少し具体化すると、Electronのようなものの登場でPCの世界のアプリ化もより一層進むのかと思います。そして、PCにしろモバイルにしろ、その中のアプリの一つ一つがサービス化していくのだと思います。そこの部分をシームレスに連係していくところが何か鍵になるのではと思います。

具体的に強化する技術



 上記のような事を探求するのに今の私に足りてないのは、Node.js力ですね。JavaScript自体は解っているし、Nodeもある程度触っています。しかし、まだガッツリとは取り組んでいません。今年あたり本格的に取り組んで、筋の良い/悪いアプリ・アーキテクチャを見極められるよう目指します。さて、誰に弟子入りしよか。

See Also:
2015年の振り返りと2016年の目標
2015年の注目技術

2015年のブログのアクセスランキング

 2015年の振り返りと2016年の目標の方に書いているので、個々の記事の動向についてざっくりまとめておきます。

傾向と対策



 昨年の較べて、2015年の記事が増えました。理由としては検索流入が激減したので、はてブなどで一時的にバズったものが上位に出やすくなっているためです。フローよりストック重視なので、これは由々しき問題です。一方で2014年以前の記事で上位のものについては、検索でヒットするものです。この辺りの分析をして、改善したいですね。少なくとも「Rubyによるクローラー開発技法」とか「Amazon Web Services パターン別構築・運用ガイド」では上位に出したい。

2015年の振り返りと2016年の目標

 あけましておめでとうございます。今年もよろしくお願いします。今のうちに、2015年を振り返ってみます。2015年の外部に公開している活動は、出版1冊と雑誌寄稿2回、ユーザグループ等での登壇が7回、会社等でのセミナーでの登壇が2回です。

2冊目の本の出版



 まず出版ですが、「Amazon Web Services パターン別構築・運用ガイド」という本を会社の同僚たちで書きました。前作のRubyのクローラー本が好評だったので、もう一冊何か書かないと出版社から打診がありました。今度は、本業としてやっているテーマを扱い、会社名を出して出版することになりました。複数人で執筆することは調整事項も多く大変な部分がありましたが、それぞれ違ったバックグラウンドを持つ人間が集まることにより、自分の能力以上のものが出来上がったと思います。
 ちなみに発売したのが2015年3月25日なので、まだ10ヶ月経っていません。個人的な感覚的としては、もっともっと経過しているように思えます。これも、AWSの進化が早過ぎるためでしょうね。少しでも追いつけるように、増刷の度に修正していっています。また、クラウドネイティブな構成の普及が予想より速くなりそうなので、もう一冊AWS本を書くことにしました。今書いているので、乞うご期待!!

雑誌寄稿



 本の執筆以外にも、雑誌寄稿も行いました。WEB+DB PRESS Vol.88の特集で、「クラウドで加速!モバイル開発最前線」というタイトルで、モバイル開発の改善をテーマにしています。本業の方でモバイル開発もしているのですが、開発のサイクルが速く、かつ開発対象のアプリが増える一方という状況で、自動化できるところは自動化していこうと取り組んできたことをテーマにしています。編集者さんと話しているうちに、どうせだったら全部クラウド上のリソースを使ってやってみようという形になったので、結構挑戦的な構成になっていると思います。憧れのWEB+DBに寄稿できたので、非常に感慨深いものがありました。また企画・構成については考えたものの、実際の執筆は会社の同僚が殆ど買いてくれました。感謝感謝です。
 あと同じテーマをビジネス観点で書いたものを、会社の情報誌にも寄稿しています。3年ぶり2回目の寄稿ですが、前回に比べると校正時の指摘事項も殆どありませんでした。少しは文章書くことに慣れてきているのかもしれません。

登壇・発表



 イベントの登壇は、JAWSUG関係を中心に7回行っていました。内容はAWS中心ですが、RubyやDevLove、クラスメソッドさんと色々な主催者の方に呼んで頂けるようになってありがたいです。AWS本の共著者のメンバーも色々呼ばれるようになってきて、そちらも嬉しいです。(自分の発表より、かなり上手くて感心する一方です。)

www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net
www.slideshare.net

 この中では、Swaggerの話が一番苦労しました。苦しみまくったおかげで、だいぶ理解も進んでいます。強制的な学習という意味で良かったのではと思います。その他でも、仕事としてセミナーでの発表やクローズドな環境での発表を何度かしました。プレゼン資料の質は中々あがっていないのですが、発表すること自体にはだいぶ慣れてきました。今年は、プレゼン資料の質の向上をテーマの1つにします。

ブログ



 2015年は80本書いていたようです。2014年は82本なので、ほぼキープです。アクセス数では、2015年は241,741です。2014年は328,411だったので25%の減少です。更に言うと、2013年は674,188だったので、何とか回復させたいところです。原因としてはハッキリしていて、独自ドメイン変更後の検索流入の減少です。これ、本当に何とかしたいです。自分の本で検索しても、圏外というのは辛いです。

f:id:dkfj:20160101144019p:plain

 だれかアドバイスください。。。

2015年の目標に対しての採点



 2015年の目標は、これでした。

  • 本を1〜2冊出版する ⇒ △ 1冊だけ出版したので、最低限は実現できました。
  • Kindle本を書く ⇒ ☓ 駄目でした。
  • モバイル・アプリ再入門 ◯ 割りと取り組めました。ただ、仕込みの段階で終わってるので、今年は成果につなげたいです。
  • 資格試験 ☓ 全然だめでした。受験します。
  • ワークバランス △ 子供・家族と過ごす時間を、物理的に増やしたいです。2014年より改善したもののまだまだです。
  • ワイン・エキスパート ☓ 申し込みすらしていないです
  • 記録をしっかり △ 読書の記録はKindleのおかげで改善。ワインの記録を考えないと
  • 英会話 ☓ 自分の中での優先度は低いのかも
  • 犬を飼いたい ☓ まずは住居の問題の解決が必要。今年は解決できず

2016年の目標



  • 本を2冊書く ⇒ 執筆中の他に、もう1冊。既に企画が2〜3件打診されているので、どうすべきか。。。
  • Kindle本を書く ⇒ Kindle市場の興味があるので、ぜひ自前で出版して試してみる
  • AWS本の英訳 ⇒ 海外の技術書市場の調査のために、チャレンジしてみたい
  • 資格試験 ⇒ せめてAWS資格くらいは全部とります
  • ワークバランス ⇒ 定量的に図れるように、前年の推定値と本年の目標をだした上で実現する
  • メジャーイベントへの登壇 ⇒ Developer Summit等のメジャーイベントへの登壇。その為に、自分の強みの分野の再定義
  • 健康 ⇒ 全ての活動の基本は、やはり健康。その為の運動。これを定量的に測定する。

細かい部分や、仕事等で公開できない部分については、別途管理します。

まとめ



 何となく去年の延長ですが、1つ1つ出来ることを増やすというのがモットーです。亀の歩みかもしれませんが、地道にやっていきます。今年もよろしくお願いします。


追記:2016/01/02
2015年のブログアクセスのランキングも記載しました。
2015年のブログのアクセスランキング

追記:2016/01/03
2016年の注目技術を記載しました。
2016年の注目技術 - プログラマでありたい

"人工知能は人間を超えるか"のKindleセール99円が面白い

 最近注目しているのが、Kindle角川セールで行われている"人工知能は人間を超えるか"の99円セール。この本は、紙の本であれば1,512円ですが、Kindleのセールで何と99円。さらに19%ポイント還元です。95%以上OFFと、類を見ないセール内容となっています。

人工知能は人間を超えるか (角川EPUB選書)

人工知能は人間を超えるか (角川EPUB選書)

このセールが面白いと思う理由



 私がこのセールを面白いと思う理由は、この本が本来買うであろう顧客層を突き抜けて、広範囲に売れていると推測しているからです。本というのは、実は元々想定する読者層の中で如何に買われるかが勝負になります。例えば、SF小説というカテゴリーを買う人は一定数いて、逆に一定数以上の人は買いません。顕著な例だと、医学書で特定の症例を題材にした場合、恐らく読者層はせいぜい数百人くらいで、ヘタしたら著者は読者のことを殆ど知っているのではないかという場合もありそうです。コンピューター系の技術書も、カテゴリーが細分化されていて初版の3,000冊売れればやれやれということも多いようです。
 この人工知能というテーマも、本来であればそれほど大きな購買層を持っているとは思えません。もちろん、ビッグデータや機械学習といった言葉が一般紙にも載るようになったので、興味を持たれる下地はあると思います。しかし、Kindleの有料ストアランキングの1位に君臨し続けるパワーはなかったはずです。それが上手な価格戦略のおかげで長期にわたって1位になっています。また紙の本も3桁順位の前半をキープし続けるなど、大健闘です。
※Amazonの紙の本のランクで、3桁順位は飛ぶ鳥を落とす勢いです。

このセールは、成功なのか?



 つまりこのセールは、大成功なのではと思います。この本は2015年3月に発売され、かなりのヒットを続けていました。レビュー数からみても解るとおり、かなりの好評価を得ています。この時点で、この本のポテンシャルに気がついた/もしくは一気にベストセラーを目指そうと、今回の目玉企画につながったのでしょう。実際、このセールで買っている人は、本来であれば買わなかった人が9割くらいなのではと思います。(私もその一人です。)Kindle本が売れているとなると、引きつられて紙の本が売れます。まだまだ大多数の人が、本は紙で読みたいという人がいるからです。
 出版社としては、Kindle本は利益が出ないor損失だけど、もともと売れない層に売っているから敢えて目をつぶれます。その分、紙の本が売れてくれれば万々歳です。見事にその戦略があたっているのではないでしょうか?

Kindleのセールの場合、印税はどうなるのか?



 ちなみにKindleのセールの場合、印税はどうなるのでしょうか?セール以外の話をすると出版社によって違いますが、紙の本の印税は8〜10%くらいでしょう。また、Kindle版は、その倍の16〜20%くらいというのが多いようです。例えば、1500円の本で10%の印税であれば、1冊売れれば150円です。Kindle版は紙の本より安く設定されることが多いですが、例え半額でも同程度の印税が貰えるように設定されることが多いようです。
 さてセールの場合です。実はセールで安売りしていても、著者に入る印税は元々の価格をベースにしたものが多いようです。つまりセールと関係なく正規の印税が手に入るということです。この辺りは、別途詳しく解説しようと思います。

本のマーケティングに思う所



 今まで出版社は、マーケティングという意味でのマーケティングは殆どしていませんでした。また、再販価格維持制度があるので、(ハードカバー、文庫本という意味以外)価格戦略というのも殆ど取っていません。Kindelの登場により、この辺りが一気に変わるのではと思えてきました。技術書というニッチな市場の著者としては、印税よりかは如何に多くの人に届くのかという方が興味があります。その辺り考えると、Kindle直販など色々試してみたくなります。その考えのキッカケになるセールでした。

人工知能は人間を超えるか (角川EPUB選書)

人工知能は人間を超えるか (角川EPUB選書)

See Also:
上級者向けの技術書が少ない理由
一介のブロガーが技術書を書くに至った経緯。或いは自分戦略
本を書く前に準備したこと、執筆中にしていたこと
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

iPadがノートPCの代わりにならない理由

 初代のiPadの購入から、iPad miniやiPad Proなど公私ともに使ってきました。またiPadにキーボードを付けて、ノートPCの代替として使えないか試行錯誤してきました。今の所の結論は、ノーです。

iPadを利用したい動機



 東京転勤以来、始発駅から通っている為に座って通勤しています。結構まとまった時間があるので、そこを有効活用する方法を考えていました。結論的には、どこでも原稿やブログを書ければ一番効率的な時間の使い方だと思い至りました。読書とかも隙間時間の使い方の1つですが、日中の移動や帰りなど座れない時も結構あるのでそちらの時間を当てています。
 平日毎日30分あれば、月に10時間確保できます。私は、だいたい1時間で4,000字くらいは書けるので、ページ数にして25頁くらいの分量です。これだけ書ける時間を捻出できたら万々歳です。(実際に書けるかは別ですが。)

iPadがノートPCの代わりにならない理由



 ということで、最初はiPad miniを持ち歩いて試行しました。最初からキーボードがないと、まともな活動が出来ないと思っていたのでカバー一体型のキーボードを購入しています。LOGICOOLの一体型のを選びましたが、これ自体は非常に良かったです。今でも利用しています。
LOGICOOL ウルトラスリム キーボード フォリオ for iPad mini ブラック TM725BK

LOGICOOL ウルトラスリム キーボード フォリオ for iPad mini ブラック TM725BK

 しかし、すこぶる生産性が低いのです。要因としては、主に下記の2つです。

  • コピー&ペーストすらやりにくい
  • ショートカット・キーの概念が無い

 特に後者が致命的でした。私は何か作業する時に、いろいろなモノを参照しながら考えます。その際の切り替えがショートカット・キーの概念がないiOSだと非常に不便でした。iPad Proだと2画面利用可能で不便を解消できるかもしれませんが、あの大きさを持ち歩く気にはなりません。

試行錯誤の結果



 11インチのMacbook Airを常時持ち歩くようになりました。また、手提げのカバンだと、他の荷物を入れるとそれなりに重くなるので、リュックに切り替えました。結果的に全く不便がなくなりました。iOSよりMac OSの方が便利ですね。そういう意味で、Surface Bookが気になっています。

感想



 やっぱりPCは便利。でも、人によってはiPadで充分という人も増えると思います。

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

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

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

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



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

f:id:dkfj:20151222115016p:plain

 たぶん物理筐体から、何十、何百というデバイスをニョキニョキと繋いでいるのだと思います。そのケーブルは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リージョンのみ利用できます。ハッキリ言って場所は全然関係ないので、気にせず使いましょう。サービスを選んだらプロジェクトを作成します。
f:id:dkfj:20151222120556p:plain

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

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

テストの種類の選択

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

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

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

デバイス設定

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

実行&レポート

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

感想



 まだ動かしてみたというレベルですが、可能性を感じます。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