blog.syfm

前々からデブサミに興味があったものの、行けていなかったデブサミですが、今回初めて行ってきました！
開催期間は2月17日から2日間でした。
詳しい内容は後日スライドが以下の URL から up されると思うので割愛しますが、見た各セッションの感想なんかを書いていきたいと思います。

codezine.jp

１日目

大学の期末考査につぶされました。
1限に実施されていたならば、午後セッションくらいは見れたと思いますが、4限(15時から16時くらいまで)だったので見事にすべてのセッションが見れませんでした。つらい

論回ゆるさんぞ
— きたろー (@ktr_0731) 2017年2月14日

2日目

きゅうり農家から保険会社まで、機械学習を「民主化」する TensorFlow

Google の佐藤一憲氏の発表。

機械学習を利用している Google photo や、Google 翻訳などのサービスを例に、ユーザの位置に応じた機械学習の技術が紹介されていました。
自分は機械学習に関する知識はまったくないのですが、とてもわかりやすく、面白かったです。
特に機械学習で Google 社内の消費電力を抑える仕組みなどは、こんなにも劇的に変化するのか…ととても驚きました。

サーバレスアーキテクチャにしてみた - エンタープライズチャットアプリでの挑戦 -

ドリーム・アーツの石田健亮氏の発表。

あるアプリのプロジェクトで、イケイケな技術を盛り込んだ結果、使い慣れていない技術のため想定以上にコストがかかってしまい、結果的に炎上という凄い状況だったらしいです…。
ビジネスとしてやっていくには、

学習コストや運営コストなどの金銭的な問題
マルチプラットフォームのフロントエンド、バックエンドの開発にかかる時間的な問題
技術の選定

が重要になるので、自分たちの興味のままに技術を取り入れていくだけでは生きていけないとおっしゃっていました。

そこでサーバサイドを Firebase や Heroku などの mBaaS や PaaS で置き換え、できるだけサーバレスにすることでサーバサイドに必要な開発を抑えたことでコストが劇的に小さくなったとのこと。

自分はまだ学生で、ビジネスの世界には踏み入れたことがないため、「興味のままでは生きていけない」という言葉がとても印象に残りました。

休憩時間

デブサミではスポンサーの企業の方々がブースを出展していて、自由に見ることができます。また、別室では同人誌の販売も行われていました。
はてなさんの Mackerel チームの方と本当にちょっとだけですがお話ができたので嬉しかったです。

f:id:ktr_0731:20170218114949j:plain

ちょっとだけMackerelの方とお話できたので嬉しい！ステッカーも頂いた #devsumi
— きたろー (@ktr_0731) 2017年2月17日

また、DevBooks では TechBooster さんのブースで Revised 型の国のTypeScript と The Web Explorer 2 を買ってきました。

f:id:ktr_0731:20170218115002j:plain

コンテナをフル活用した現場

Wantedly, Inc の坂部広大氏の発表。

コンテナを活用していく上での Wantedly さんでの取り組みやルールなどのお話。
以下の3つが取り上げられていました。

アプリケーションのルール
The Twelve-Factor App を元にしていて、その根幹は Docker を利用することで実現しているとのこと。
コード化、ツール化
言語やプロジェクトに関係なく、共通のディレクトリ構成、ファイル名を取り入れることで、特定の操作の方法を明確にする。
例えば、プロジェクトルートに script ディレクトリを用意し、そこに bootstrap 、server といった名前のファイルを配置することで、プロジェクトに新しく参加する人も迷うことなく操作ができる。

また、インフラを操作するようなものは CLI ツールにしてしまい、共通のインターフェースを介すようにしていました。
特にインフラが専門でない人にとって、既存の用意されている CLI ツールには不要な機能がたくさんあったり、逆に使いづらい部分があるため、それらを隠蔽、拡張した wrapper CLI ツールを作成していました。

こうやって、効率よく開発に移ることのできる環境を作っていました。

変化に強いインフラ
※自分は Kubernetes(k8s) を使ったことがないのでちょっと曖昧です。

コンテナを使った開発をしていると、アプリケーションエンジニアが Docker ファイルを書くことになって大変だったり、コンテナをサーバにデプロイするための準備や、インフラチームとの調整があり、無駄が発生するという問題があります。
そこで Wantedly さんでは k8s を利用することで「アプリケーションがどこで動いているのか」ではなく、「アプリケーションがどう動いているのか」だけを意識できるようにし、デプロイなどに必要な複雑な手順を単純化したそうです。

C# で簡単にモバイルアプリを作ろう！

日本マイクロソフトの千代田まどか氏の発表。a.k.a ちょまどさん。

C# の構文や async/await などについての簡単な解説と、C# と Xamarin によるマルチプラットフォームなアプリの開発についてがメインでした。
Xamarin で Mac アプリや UWP アプリを開発できるのは知らなかったので参考になりました。

最後に Azure と Visual Studio 2017 の解説もありましたが、時間が…。
ある程度予想はしていましたが、聴講者が物凄く多かったです。

ニコニコ動画・生放送の配信基盤刷新

ドワンゴの後藤哲志氏の発表。

ニコニコ動画・生放送の変革と Web 技術の移り変わり(Flash → HTML5) などを交えながら新しい配信基盤の DMC を開発したことを説明していました。

言語は Erlang、C/C++、Rust が利用されていて、映像のトランスコードといった高速化が必要な部分は C/C++、分散ファイルシステムは Rust、その他の大部分は Erlang で書かれているそうです。
既存の分散ファイルシステムでは要件を満たすものがなかったらしく、新しく開発したとのこと。なぜ Rust かというと、使ってみたかったかららしいです。

ロールと言った仕組みの導入によりダウンタイム無しでサーバの切り替えをできるようにしたり、問題が発生したサーバを膨大な数から見つけるために Elasticsearch + Kibana を導入していたり、いろいろな技術が盛り込まれていてすごく面白そうでした。

執筆を支える技術と技術書のトレンド

日高正博氏、高橋征義氏の発表。

日高氏は TechBooster のひつじさんとして、高橋氏は「たのしい Ruby」や高橋メソッドでも有名です。
TechBooster の同人誌をいくつか持っているので、どんなことを考えているのかを知りたくて発表を聴いていました。

本と Web の情報の違いについて話していました。
一般の技術書はある程度の期間は有用でないといけないため、ある程度安定した技術を扱うのに対し、Web はその変更の容易性、自由性から新しい技術をまとめるのに適していることなど、なるほどと思うことが多かったです。
そして、技術系同人誌は同人誌の特徴から、趣味（たのしー！）書きたいことを書けたり、一般の本よりかは圧倒的に楽に世の中に出せたりするので、技術書と Web の中間に位置するような存在だと感じました。

まとめ

どのセッションもとてもおもしろく、興味を惹かれるものばかりでした。
こうして振り返ってみると、割とインフラに近い分野が多かった気がします。
今回はタイミングが最悪で半分しか見れませんでしたが、また機会が合えば今度こそ最初から参加したいなぁと思いました。

ちょっと Amazon Product Advertising API (PAAPI) を利用する必要があって、ドキュメントを読みながら進めていたら、以下のようなエラーに悩まされた。
かなりハマったので備忘録的な感じで書いておきたい。

ちなみに、REST API で ItemSearch を叩いていた。

<?xml version="1.0"?>
<ItemSearchErrorResponse xmlns="http://ecs.amazonaws.com/doc/2005-10-05/">
  <Error>
    <Code>AWS.InvalidAssociate</Code>
    <Message>Your [ACCESS_KEY] is not registered as an Amazon Associate. Please register as an associate at https://affiliate-program.amazon.com/gp/associates/join/landing/main.html.</Message>
  </Error>
  <RequestId>a047206b-9423-48b9-ac8e-ec33265a83c1</RequestId>
</ItemSearchErrorResponse>

ググってみると、Amazon アソシエイトと PAAPI に登録したときに必要なメールアドレスが同じものでないといけないので合わせましょうというような解決策は出てくるけど、自分の場合、同じメールアドレスを使用しているにも関わらず、そのようなエラーが出ていた。
時間を置いてみたり、Scratchpad を使っても同じエラーが出ていたのでどうしたものか…と思っていたけど、webservices.amazon.co.jp にリクエストを送るようにしたら解決した。

具体的には、API を叩くにあたってエンドポイントを指定する必要があるけど、公式のリファレンスには webservices.amazon.com へリクエストを送るようになっている。
そこを webservices.amazon.co.jp へ変更する感じ。
同様にシグネチャ生成の部分も変える必要がある。

変更すると無事リクエストが成功し、結果が返ってきた。
大雑把にググってもこの情報は出てこなかったので、もしかしたらなにかしらの条件下でしか起こらないのかもしれない…。リージョンの問題？

blog.syfm

徒然なるままに考えていることなどを書いていくブログ

Developers Summit 2017 に行ってきた

１日目

2日目