読者です 読者をやめる 読者になる 読者になる

プログラマになりたい

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

WEB+DB PRESS Vol.88でモバイル開発の話を書きました

f:id:dkfj:20150821003002j:plain

 2015/8/22発売のWEB+DB PRESS Vol.88にモバイル開発の話を寄稿しました。内容としては、クラウドサービスを利用して、楽に開発しようよという話です。白状すると私が書いたのは最初の1章だけで、後は会社の後輩の@yanayanalteに書いてもらいました。

目次



 今回の特集は、5章構成です。背景のところから、ビルド・テスト・デプロイと一通りの工程を取り扱っています。

  1. いまどきのモバイルアプリ開発事情 〜クラウドの活用でプロダクトの改善に注力する〜
  2. CircleCIを使った自動ビルド 〜ヒューマンエラーを防ぎ安定した開発を実現する〜
  3. Scirocco Cloudを使ったE2Eテスト 〜他機種・多端末での検証を省力化する〜
  4. DeployGateを使ったデプロイ 〜ストレスなくα版アプリを配布する〜
  5. Crashlyticsを使った障害検知 〜運用中のクラシュ情報を見える化する〜

特集の内容



 内容については、以下の特集説明のとおりです。

■特集1
モバイル開発最前線 ―― ビルドもテストもデプロイもクラウドで加速!
昨今、AndroidやiOSなどのモバイルアプリ開発におけるビルドやテスト、デプロイといったフェーズを省力化するためのクラウドサービスが多数登場しています。そこで本特集では、「いかに高速に開発するか」「設計や実装に注力するためにはどうするか」といった視点から、CircleCI、Scirocco Cloud、DeployGate、Crashlyticsといったクラウドサービスを組み合わせ、モバイルアプリ開発を効率化するための方法を余すことなく紹介します。

 最初の企画の段階では、クラウドサービスを利用することに特化せず、Jenkinsなどインストール型のツールなどの紹介や、バージョン管理や開発スキル向上の話まで盛り込もうとしてました。その企画案では、個々の内容が薄く特徴がなくなるという指摘を編集者さんに頂きました。それではということで、クラウドサービスを利用するということに特化した構成にしてみました。
 モバイルの場合、MacOSの問題やスマホ実機の問題があり、開発環境をクラウドに持っていくのは難しいと思われていました。しかし、最近ではその辺りの課題については殆ど解消されていて、逆にクラウドサービスを利用する方が便利になってきています。その辺りを書いているので、興味があれば読んでみてください。

執筆の背景にある狙い



 ここ1年くらいの仕事での関心事は、モバイルアプリチームの生産性の向上でした。生産性向上というのは、色々な尺度があるので一概には言えないのですが、私としては次の目標を立てて実現する方法を模索していました。

チーム全体として、1ヶ月あたりでリリースできるアプリの数を増やす


 その為には、以下のことを考えていました

  • 個々のメンバーが、設計・コーディングなど開発の本質部分の時間に割り当てられる時間を最大化する
  • 新規参入メンバーの習熟コストを最小限に出来るようにして、チームのスケールアウトを容易にする
  • 技術向上の為の効率的な学習方法


 まぁざっくりと言うと、長い時間を掛けて個々人の生産性を極限まで上げることを目指すのではなく、人を増やしてもよいからチーム全体のアウトプットを増やす方向性です。その為には、コンピュータが出来る部分はコンピュータにやらせて、設計・コーディングといった人間にしか出来ない作業に集中できるようにするということです。そうすると、面倒くさい手順的な部分は覚えずに済むし、量をこなせるので習熟も早くなるということが期待できます。
 改めて考えると、根本的にはSIerの発想ですね。ただSIerの陥りがちな罠である、最低限のスキルに達していない人間を前提としたコーディングルールやフレームワークでガチガチで固めるという方法は取りませんでした。ルールではなくシステムやコードレビューを前提とすることで、チームの拡大にともなって個々人の生産性が落ちるといったことは発生しませんでした。結果としては、チームの規模としては2倍程度の拡大に対して、アウトプットとしては4倍近くまで達しているので概ね上手くいったのではないかと考えています。

 そんなこんなで試行錯誤したことのうち、主にシステム面の部分を記事化しました。技術の習得やスキルトランスファーの話も、いつかまとめてみたいものですね。

感想



 雑誌の寄稿というのは初めてで、その雑誌がWEB+DB PRESSでした。他の執筆者陣はそうそうたるメンバーで、その中に並んで名前が載り非常に光栄です。また私の方は企画と序文を書くだけで、あとの部分は全部@yanayanalteがやってた訳ですが、申し訳ないなぁと思いつつ、やれば出来るだろうと思ってました。実際、頭で思い描いてた通りに実現してくれて非常にありがたいです。今年はもう一冊本を書こうと思っているので、是非また巻き込もうと思います。

WEB+DB PRESS Vol.88

WEB+DB PRESS Vol.88

  • 作者: 佐々木拓郎,高柳怜士,鶴原翔夢,小野侑一,中村俊介,佐藤春旗,長野雅広,佐々木健一,久保達彦,若山史郎,佐藤太一,伊藤直也,道井俊介,佐藤歩,泉水翔吾,坪内佑樹,海野弘成,西尾泰和,中島聡,はまちや2,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2015/08/22
  • メディア: 大型本
  • この商品を含むブログを見る


See Also:
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

DevLOVE関西で、クラウド時代のエンジニアについて考えた

 前回のJAWSUG大阪で共著者の佐藤さんが話した「Slerがawsで運用してきた話」が好評で、DevLove関西でお話する機会を頂きました。私もご相伴して、「Amazon Web Services パターン別構築・運用ガイド」の著者陣2人で講演となりました。

devlove-kansai.doorkeeper.jp

オープニング



 まずはDevLOVE関西の主催者の@yohhatuさんのオープニングスライドです。DevLoveのコンセプトが簡潔かつ明確に宣言されています。「DevLOVE関西は素振りの場。現場は実践の場」という言葉が良いですね。あと、第96回目というのが凄いです。
※公開されていないようなので、貰ったのをS3にアップしています。

クラウドがアーキテクチャを変え、 エンジニアの役割も変わる



 私のセッションでは、クラウドの台頭でアーキテクチャが変わり、その結果エンジニアの役割も変わりつつあるのではという話をしました。長年AWSを使い続けて、またモバイルやデジタルマーケティングといった変化の早い分野の業務を担当していて、そこはかとなく感じていたことを言語化してみました。 www.slideshare.net

 まだうまくまとめられていないですが、確信していることはあります

  • 従来のアプリ/インフラエンジニアという枠組みでは対処しきれないことが増えている
  • 汎用的な部分はクラウドやフレームワークで用意されている分、それぞれの分野で深い知識をエンジニアには逆に求められるようになってきている
  • (両方を極めているスーパーマンみたいのがたまにいるので、凡人には困る)

 私は、1つの分野を極める方向に進みたかったのですが、自身の性格のためか色々な事に少しづつ手をだすエンジニアになりました。結果、スライド中にある赤魔道士みたいな中途半端な存在になったのですが、まぁ最近は割りきって専門性の高い人達につなぐことに徹しています。そんな働き方もあるんだよと紹介したつもりです。

アプリエンジニアからクラウド専用のインフラエンジニアになってみて



 2つ目がメインのセッションです。共著者の佐藤さんによるアプリエンジニアからインフラエンジニアにジョブチェンジした話です。

www.slideshare.net

 具体的な話が盛り込まれて、かなり面白い内容でした。彼はいつも私のムチャぶりに巻き込まれているのですが、常に期待以上の成果を出してくれる頼もしさです。Infrastructure as codeやAPI Gatewayのくだりが、現場からの生の声が聞こえて参考になります。

ダイアログ



 その後が、DevLOVEならではのコンテンツということで、ダイアログがありました。参加者自身でテーマを決めてグループになって話し合うという内容でした。出てきたテーマは、下記の4つです。

  • (API Gateway等の)テスト環境をどうするか
  • 企業内でAWSを導入するには、どうしたらよいのか
  • Infrastructure as codeの実際について
  • クラウド利用の費用対効果

 最初はぎこちなかったのですが、徐々に会話も活発になり色々な現場の話が出てきました。私はぶらぶらしながら色々な話に軽く参加していたのですが、あるあるという話から成る程という考え方まで色々あって面白かったです。まさにコミュニティーという感じで良かったです。

その他



 ブログ書きながら、TwitterやFacebookみていたら立て続けに似たようなテーマの発表がありました。私が言語化しようとしてうまく出来なかった部分が、うまく表現できているて凄く参考になりました。是非見てください。さすが堀内さん www.slideshare.net


こちらも面白い
若手インフラエンジニアたちが語る技術トレンドと数年後の未来

感想



 今回は、初DevLOVE関西でした。最近は、JAWSUG以外のイベントにも参加するように心掛けています。やっぱり、まったく違う文脈の人と話せるのは面白いですね。バックグランド的には、DevLOVE系の人の方が近い人も多く、もっと参加しようと思いました。またよろしくお願いします。

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

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

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

Amazon API Gatewayの設定の構造

 Amazon API Gatewayの登場で、2Tier-Architectureのピースが揃ったように思えます。いろいろ試してみたいのですが、ちょっと設定の構造が初見でよく解らなかったので一旦整理してみます。理解が間違っていたら、是非指摘してください。

Amazon API Gatewayの用途と構造



 まずは、Amazon API Gatewayの公式ドキュメントを眺めてみます。幾つかの用語が出てきています。API,Resource,Method, Method's Settings,Models and Mapping Templates, Stagesまず最初の4つを整理してみます。

f:id:dkfj:20150712191617p:plain

 まずAPIを作ります。APIは、オブジェクト指向でいうところのクラスのようなものでしょう。クラスの中に、Resourceを作ります。リソースは、APIにアクセスする為のパスです。まずはデフォルトの/(ルート・ディレクトリ?)を作り、任意にサブディレクトリのような感じで複数作っていきます。
 リソースを作ると、次にMethodの設定を行います。Methodoは、HTTPのプロトコルに対応していて、GETやPOSTの他にHEADやPUTなどが作成します。現実的には、GETとPOSTだけを使うことになるのではと思います。なお、1つのリソースに対して、設定できる同一種別のMethodは1つのみです。/getDataというリソースに対しては、GETは1つだけ設定できます。またPOST等の違うメソッドも設定出来ます。設計上は、1つのリソースに1つのMethodにしておいた方がよいと思います。
※RESTのURIは何を表現するということで、名詞を使うらしいです。そして、どうするという部分を表現するのがMethodとのことでした
 最後にメソッドの設定です。ここがAPI Gatewayの肝になります。設定としては、Lambda Function, HTTP Proxy, AWS Service Proxyの3種類が設定できます。基本設定では、Lambda FunctionとHTTP Proxyを設定でき、Advance SettingでAWS Service Proxyが選択できます。この辺りにAWS側の意図が少し見えてきます。

StagesとModels



 StageとModelもAPIにひも付きます。Stageは、利用用途です。例えば、本番用やテスト用など、URLやキャッシュ・ログ・監視やバーストの上限などを変更できます。そもそも、テスト用などでAPI Gatewayの接続先が切り替えられるか気になるところですが、画面コンソールを見る限りは、できなさそうです。もう少し継続調査します。
 次にModelです。これは、API Gatewayの接続先からの返り値をマッピングする為のモデルです。返り値としては、JSONに変換して出力する形になります。デフォルトでは、エラーと空だった場合のものが用意されています。

Error

{
  "$schema" : "http://json-schema.org/draft-04/schema#",
  "title" : "Error Schema",
  "type" : "object",
  "properties" : {
    "message" : { "type" : "string" }
  }
}

Empty

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title" : "Empty Schema",
  "type" : "object"
}

 API Gatewayを実装していく場合は、ひたすらこのモデルを定義していく形になるのではと思います。恐らくAWS Service Proxyの場合は、ある程度テンプレート的なものが用意されていくと思いますが、それでもデータの型によってそれぞれ違ってきます。コンソールで試しに作っていたのですが、これは最終的にはコードとして管理しないと手に負えなくなる予感がします。

AWS Service Proxyの利用



 AWS Service Proyについては、まだ余り試せていません。DynamoDBの結果などをそのまま取得できれば胸熱です。このAWS Service Proxyについては、IAM Roleを利用して権限設定をします。ロールの設定の際に、Principal(信頼関係)の設定が必要なのですが、現状では選択肢としてAPI Gatewayがでてきません。次のような感じで、apigateway.amazonaws.comを設定しましょう。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

まとめ



 まだ全然時間が取れていないので、未知数の部分が多いですが、昨年のLambdaに引き続き楽しいサービスなのは間違いないです。最近は、サーバを立てずにどうやって実現するかを考えているのですが、その重要な要素の1つになります。一方で、API Gatewayの実体は、ApacheやNginxのrewrite proxyのようなものと、AWS系のリソースを呼び出せるアプリケーションエンジンの組み合わせと推測できます。当然オーバヘッドはあるので、どれくらいのパフォーマンスなのか測っていく必要があると思います。(誰かやってくれると思うけど。)


参照:docs.aws.amazon.com

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

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

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

IoTは製造業とユーザをダイレクトに直結する

f:id:dkfj:20150709011927j:plain


 昨日、オフィスグリコについて書いていて考えていたことがあります。メーカーであるグリコにとって、あの販売形態は重要な意味があるのではないかという点です。一般的な流通形態は、卸売店・小売店を経由してエンドユーザである消費者に届きます。オフィスグリコは、ロジスティクスの具体的な事は知りませんが、限りなくメーカーとユーザを直接結びつけています。このことは、恐らく大きな意味を持つようになるのではと思います。

 実は、この構造は最近のIoTでも同じなのではと思います。IoTが注目されている点は、機器にセンサーを付けることによって今まで集めることが出来なかったデータを収集できることにあります。一例をあげれば、AppleWatchのようなもので、一日の脈拍や運動量というデータを集めることができます。まだ、それほど進んでいませんが、家電にセンサーを付けることにより、その家電が実際にどう動いたか(頑張ってプラットフォームを作れば)集めることができます。冷蔵庫やクーラーの稼働状況を可視化するということも可能ですね。
 このIoTは、別の側面から見るとメーカーとユーザを直接結びつけることになります。今までであれば、製品がどのように使われているかは、アンケートを取ったり、サンプリングして観察するくらいしか方法がなかったです。これが、直接メーカーが確認できる可能性が出てきているのです。これは大きな意味があるのではないでしょうか。例えば、コマツが車両にセンサーやGPSを付けて出荷することにより、製品保守の向上だけにとどまらず需給予測や市況判断まで出来るようになりました。
 こういった事例がどんどん出てくるのではと思います。つまりメーカーがサービス業に転換する可能性です。そうなると、世の中の仕組みがどう変わるのか。どこが儲かるようになるのか。その辺り、考えています。この前、「データの見えざる手」を読んで、IoTやセンサーの何たるかが少し解ってきて、俄然興味がでてきています。


See Also:
オフィスグリコの規模

オフィスグリコの規模

 ふと気になったので、調べたメモです。
オフィスグリコって、ご存知でしょうか?富山の置き薬のごとく、企業内にお菓子を満載したボックスを置いて、定期的にやってくるグリコのおにーさん(?)が補充・代金回収する奴です。ポイントは、性善説に基づいた代金回収モデルです。商品を入れている箱は、ただの引き出しなのでお金を入れなくても開けれます。商品を取ったら、カエルさんの口の代金箱に入れるという仕組みです。タダ食いをしようと思ったら、幾らでも出来る仕組みです。

http://www.ezaki-glico.com/release/20060425/image/p_office.jpg


 これがどれくらいの規模なのか気になって、ググると良い記事が出てきました。jp.reuters.com

2013年度で、売上が45億円です。注目すべきは、設置数。10万事業所に12万台の菓子ボックスと、1万7千台だの冷蔵庫とのことです。10万という数字は、全国のコンビニの合計数である5万件を軽く凌駕しますね。そして、代金の回収率は95%とのことです。この10万箇所という数字、センサーとか付けて色々やったら面白いデータとれそうとか、今後の可能性考えてしまいますね。


 ちなみにオフィスグリコが凄いと思うのは、代金の未回収を許容するという設計とそれを許してGoをだした経営の判断だと思います。考えてみれば、未回収の損失を上回る利益を出せば問題は無い訳で、ある意味営業コストと考えられます。システム屋として例外処理ばかり考えていたら、この発想は中々出にくいので反省ですね。
 よくよく考えたら、TCP/IPとかも個々の通信のエラーは許容する代わりに、全体としての効率性を追求するという設計ですね。

 ということで、ただのメモでした。そういえば、フリーでも置きクリスピーの話があったような。ヤバい経済のベーグルでした


ヤバい経済学〔増補改訂版〕―悪ガキ教授が世の裏側を探検する

ヤバい経済学〔増補改訂版〕―悪ガキ教授が世の裏側を探検する

フリー ―<無料>からお金を生みだす新戦略

フリー ―<無料>からお金を生みだす新戦略

See Also:
IoTは製造業とユーザをダイレクトに直結する

またまたKindleの最大50%OFFセール!!この本、買いました

 いつ始まりいつ終わるのか謎ですが、またKindleがセールをやっています。最大50%OFFセールで、ポイント還元ではなく安売りです。

www.amazon.co.jp

 今回の対象は301件で、ほぼ一般書が対象となっています。その中で目を引いたのは、下記の本です。紙の本で読んだことがあるのも含めて、ポチポチしました。

ジャレド・ダイアモンドの銃・病原菌・鉄(上下)と文明崩壊(上下)



 鉄板のジャレド・ダイアモンドですが、銃・病原菌・鉄は手元になかったので、Kindleとして買っておきました。文明崩壊は、既にKindle版を購入済みでした。賛否いろいろありますが、文明の発展をその周りの環境の関連性を独特の視点で分析する手法は色々な発想につながり面白いです。読んでいない人は、是非一読して欲しいです。

銃・病原菌・鉄 上巻

銃・病原菌・鉄 上巻

銃・病原菌・鉄 下巻

銃・病原菌・鉄 下巻

文明崩壊 上巻

文明崩壊 上巻

文明崩壊 下巻

文明崩壊 下巻

今年一番面白かった本。銃・病原菌・鉄 ―1万3000年にわたる人類史の謎
ジャレド・ダイアモンドの文明の崩壊。森林破壊と和歌山と

「筋トレを続ける技術」自宅で気軽に脂肪燃焼! Ikeda sports library



 ダイエットというより運動不足がまずい状態なので、ダメ元で買ってみました。読んで続けられたら、ブログで紹介します。
「筋トレを続ける技術」自宅で気軽に脂肪燃焼! Ikeda sports library

「筋トレを続ける技術」自宅で気軽に脂肪燃焼! Ikeda sports library

自分で作る風力発電



 時代はIoTだというのは嘘ですが、こういった自作系の本は好きです。いつか息子と小型の発電機を作ってみたいなと思い買ってみました。
自分で作る風力発電

自分で作る風力発電

児島速人CWEワインの問題集2015年版



 今年こそワインエキスパートを受験します。そのためにも、今月中に申し込みしないと
児島速人CWEワインの問題集2015年版

児島速人CWEワインの問題集2015年版

日本の滝百選



 いや、滝みるのって楽しいので。いつか行く日を妄想します。
日本の滝百選

日本の滝百選

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



 やっぱり気になったので、追加で購入。



See Also:
今まで読んで良かった本 100冊

Rubyで操るAWS 〜第67回Ruby関西 勉強会で発表してきました〜

 先日の第67回Ruby関西勉強会で、「Rubyで操るAWS」というタイトルで発表してきました。

www.slideshare.net

Ruby関西勉強会と登壇の経緯



 昨年のRubyによるクローラー開発技法発売時に声を掛けて頂いて登壇しました。その縁もあって読書会などにも読んで頂き、関西のRubyコミュニティと御縁も出来てきました。そんなこともあり「Amazon Web Services パターン別構築・運用ガイド」の発売を機に発表の機会を頂きました。ありがとうございます。私自身、IaaS・PaaSを中心としたAWS本を書いたこともあり、次はモバイルやブラウザからAWSのSaaSを活用したアーキテクチャについて考えたいなと思っていた矢先でした。ということもあり、ちょうど良いタイミングでした。
 ちなみにRubyのコミュニティは、すごく活発です。第67回ということから解るように、恐ろしい回数が開催されています。しかも、尼崎.rbや新大阪.rbなど街ごとのローカルコミュニティも多く、草の根活動と全体での活動がうまく組み合わさっている感じです。参加する人同士で、同じ地域の人がいたら発足するという感じで、人の交流という意味でも素晴らしい会ですね。

発表内容について



 前半部分については、今後のアーキテクチャの潮流について私が感じていることを書いています。アップした資料には書いていないのですが、3-Tierのアーキテクチャを実際に2-Tierに書き換えて実装した例のデモ等をしています。昔だったら、サーバ側で実装しないといけないことが、2-Tierにするとさっくり実現できるというのが自分でも驚きでした。さらにキャパシティも、DynamoDBなどのスループットの調整だけでできると、今までの苦労は何だったのかと思うような世の中になってきています。
 後半部分については、RubyということでSDKの種類と使い方の紹介です。私自身、V2になって苦労したところは、認証の書き方とググり方くらいだったので、そこだけ説明させてもらいました。V1とV2で書き方がガラッと変わっていて、かつググるとV1の情報ばかり出てくるので、初めてだと面食らうと思います。そこだけ解決できたら、後は特に詰まるところもないと思います。
 最後にLambda✕Ruby。これは完全に趣味の話ですが、こんな面白いサービスがあるということを是非知って欲しかったです。Lambda上でRubyを実行する方法については、別途エントリーあげようと思います。

感想



 他の方の発表も非常に面白く、有意義でした。Webエンジニアの教科書のささたつさんにお会いでき、お話する機会もありました。含蓄がある話が多く、非常に参考になりました。
 あと1つ言っておかないといけないことがあります。会場は、京都女子大学でした。勉強会にも同大学の学生さんが何人か参加していました。その中に「Rubyによるクローラー開発技法」を購入し持ってきている方がいて、サインを求められました。生きてて良かったなぁと思いました。

See Also:
62nd Ruby/Rails勉強会@関西に参加してきた
『Amazon Web Services パターン別構築・運用ガイド』を書きました


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

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

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る
Rubyによるクローラー開発技法  巡回・解析機能の実装と21の運用例

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