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

プログラマになりたい

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

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の運用例

最新のCDP!!Amazon Web Services クラウドデザインパターン 設計ガイド 改訂版を頂きました

 古参のAmazonのソリューションエンジニアかつクラウドの設計定石集であるCDPの発起人であるNinja of Threeの一人である#ヤマンこと片山さんに、「Amazon Web Services クラウドデザインパターン 設計ガイド 改訂版」を頂きました。ありがとうございます!!

f:id:dkfj:20150531153426j:plain

初版と改訂版の違い



 初版と改訂版の違いは、発売後に様々なAWSのサービスが追加になったことで最適なデザインパターンが変わったことへの対応や、より厳しいセキュリティや可用性のニーズに対する対応が増えています。。CDP部分を目次レベルで比べると、下記のようになっています。赤字部分が変更箇所です。

改訂版 初版
基本パターン Snapshot /
Stamp /
Scale Up /
Ondemand Disk
Snapshot /
Stamp /
Scale Up /
Ondemand Disk
可用性向上パターン Multi-Server /
Multi-Datacenter /
Floating IP/
Deep Health Check
 Multi-Server/
Multi-Datacenter/
Floating IP/
Deep Health Check/
Routing-Based HA
動的コンテンツの処理パターン Scale Out /
Clone Server /
NFS Sharing /
NFS Replica /
State Sharing /
URL Rewriting /
Rewrite Proxy /
Cache Proxy /
Scheduled Scale Out
Clone Server/
NFS Sharing/
NFS Replica/
State Sharing/
URL Rewriting/
Rewrite Proxy/
Cache Proxy/
Scheduled Scale Out
IP Pooling
静的コンテンツの処理パターン Web Storage /
Direct Hosting /
Private Distribution /
Cache Distribution /
Rename Distribution /
Private Cache Distribution
Web Storage/
Direct Hosting/
Private Distribution/
Cache Distribution/
Rename Distribution/
Private Cache Distribution
Latency Based Origin
データアップロードのパターン Write Proxy /
Storage Index /
Direct Object Upload
Write Proxy/
Storage Index/
Direct Object Upload
リレーショナルデータベースのパターン DB Replication /
Read Replica /
Inmemory DB Cache /
Sharding Write
DB Replication/
Read Replica/
Inmemory DB Cache/
Sharding Write
バッチ処理のパターン
⇒非同期処理/バッチ処理のパターン
Queuing Chain /
Priority Queue /
Job Observer/
Scheduled Autoscaling
Queuing Chain/
Priority Queue/
Job Observer/
Fanout
運用保守のパターン Bootstrap /
Cloud DI /
Stack Deployment/
Server Swapping /
Monitoring Integration/
Web Storage Archive /
Weighted Transition
Bootstrap/
Cloud DI/
Stack Deployment/
Server Swapping/
Monitoring Integration/
Weighted Transition/
Ondemand Activation
ネットワークのパターン OnDemand NAT /
Backnet /
Functional Firewall/
Operational Firewall /
Multi Load Balancer/
WAF Proxy /
CloudHub
Backnet/
Functional Firewall/
Operational Firewall/
Multi Load Balancer/
WAF Proxy/
CloudHub/
Sorry Page
Self Registration
RDP Proxy
Floating Gateway
Shared Service
High Availability NAT


 赤字の部分を中心に読んでいたのですが、その背景になるシチュエーションが色々思い浮かんでフムフムとよんでいました。必要なのが随時追加されていますね。またRoute53の機能の追加等、CDPに大きな影響を与えるものも、漏らさず追加されていました。次は、EFSが出たらCDPがどう変わるのか。注目しています。

改訂版と増刷の違い。そしてKindleの扱い



 ちなみにたまに聞かれるので補足しておきます。改訂版と増刷の違いです。増刷は基本は印刷・出荷した分が品薄・品切れになり、同じものをそのまま販売されます。ただし、増刷の場合も誤字脱字程度は修正されることが多いです。改訂されずにそのまま2回増刷した場合は、初版第3刷といった感じで表記されます。これに対して、改訂版は内容を大幅に変更されます。基本的には別の本扱いになり、書籍の一意な識別子であるISBNも別のものを付与されます。クラウドデザインパターン 設計ガイドであれば、初版のISBNは4822211967に対して、改訂版は4822277372になっています。表記としては幾つかパターンありますが、改訂版第1刷といった形になります。
 また最近知ったのですが、Kindelの場合は申請すると改訂版を無料でダウンロードできるようです。今まさにKindleのセールをしているので、旧版のKindleを買っておいて改訂版のKindle版がでたらアップデートするのも手かもしれませんね。

クラウドデザインパターン 設計ガイド 改訂版の著者陣について



 実は今回のクラウドデザインパターン 設計ガイド 改訂版の著者は3人ほど増え、野村総合研究所から、野上忍さん、瀬戸島敏宏さん、坂西隆之さんの3人が参画しています。実はグループ会社で面識もあり、改訂版の話も事前に聞いていました。私が「Amazon Web Services パターン別構築・運用ガイド」を出した時は買ってねとお願いしてたので、自前で買おうと思ってたのですが貰ってしまいました。そういうことで、Kindle版が出たら買おうと思います。

まとめ



 クラウドネイティブな設計をするのであれば、クラウドデザインパターン(CDP)は正に定石集となります。是非、早い段階で読んでおきたい一冊になります。また、実はこの内容はオンラインでもそのまま公開されています。CDPを普及させたいという心意気がでていますね。
 また、CDP実装面についてはクラウドデザインパターン実装ガイドがあり、最近改訂されています。そちらも合わせて参照するといいと思います。また、AWS全般に関する分厚い本もありますので、そちらの方もよろしくおねがいします。

Amazon Web Services クラウドデザインパターン 設計ガイド 改訂版

Amazon Web Services クラウドデザインパターン 設計ガイド 改訂版

Amazon Web Services クラウドデザインパターン 実装ガイド 改訂版 日経BP Next ICT選書

Amazon Web Services クラウドデザインパターン 実装ガイド 改訂版 日経BP Next ICT選書

  • 作者: アマゾンデータサービスジャパン玉川憲,片山暁雄,アイレット鈴木宏康
  • 出版社/メーカー: 日経BP社
  • 発売日: 2015/04/01
  • メディア: Kindle版
  • この商品を含むブログを見る
Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

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

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


See Also:
「Amazon Web Services パターン別構築・運用ガイド」の執筆環境
「Amazon Web Services パターン別構築・運用ガイド」の目次
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました
本を書く前に準備したこと、執筆中にしていたこと