スマホアプリ開発を支えるRuby (Burikaigi2020で発表できなかったもの)

経緯

2020/02/01 にBurikaigi2020というイベントがありました。

toyama-eng.connpass.com

その約1月前に、発表者に立候補し、年末年始などでちょっとずつスライドを作っていました。

が、イベントの5日前ぐらいから体調が悪くなり、3日前に検査してもらったらインフルエンザということが判明。
無理やり参加して、参加者に感染させるわけにもいかず、やむなくキャンセルとなりました。
(運営側にはご迷惑をおかけしました。。。)

スライドを作ったものの、他で発表する機会もないので、ブログにまとめてみようと思います。

スライドだけは、こちらにもアップロードしてあります。

speakerdeck.com

発表

f:id:suzaku114:20200208131609p:plain

スマホアプリ開発を支えるRuby」と題して、石倉が発表します。

f:id:suzaku114:20200208131632p:plain

アジェンダは、こちらのとおりです。

f:id:suzaku114:20200208132423p:plain

まず、自己紹介ですが、石倉といいます。
出身地も、現住所も富山県富山市ですが、所属している会社は東京にあります。
いわゆるリモートワークというやつで、この写真のような自宅の一室で仕事をしています。

興味範囲は幅がそれなりに広く、広く浅くいろいろやっています。

f:id:suzaku114:20200208132844p:plain

Toyama.rb には、ほぼ毎回参加しており、
Kanazawa.rb には、子供が生まれる前後ぐらいから、なかなか参加できていないです。。

f:id:suzaku114:20200208133000p:plain

個人的な活動としては、この画像のような、ちょっとしたゲームアプリなどを開発・リリースしています。
興味範囲の広さを利用して、複数のプラットフォームで、個別に実装しています。

f:id:suzaku114:20200208133200p:plain

モンスター・ラボという会社に所属しています。
先程あったように、本社は東京の恵比寿にありますが、結局去年は1年間出社せずに仕事をしました。

会社としては、海外にも拠点がたくさんありまして、恵比寿の本社や、島根の拠点には外国籍のメンバーも多数います。

自分の所属している部署では、スマホアプリなどの受託開発をメインにやっていますが、
会社としては音楽配信だったり、RPAだったり、いろんなことをやっています。

f:id:suzaku114:20200208133447p:plain

ここから本題です。

f:id:suzaku114:20200208133510p:plain

Rubyと聞いて、一番印象が強いのは Ruby on Rails かと思います。

ですが、それ以外にもいろいろな場所で Ruby は活用されています。

今回は、 fastlane と Danger という、スマホアプリ開発に役立つツールを、事例として紹介します。

f:id:suzaku114:20200208134020p:plain

本日想定しているターゲットとしては、
Rails が書けるけど、それ以外にも活躍の幅を広げたい人、
スマホアプリのビルド周りで、手作業が多くて困っている人、
コードレビューのやり取りで、細かな指摘が多くて困っている人、などです。

f:id:suzaku114:20200208134235p:plain

まずは、 fastlane の紹介をします。

f:id:suzaku114:20200208134259p:plain

突然ですが、iOSのビルドやデプロイって辛くないですか?

そもそも、 ipa ファイルを作るのに、XcodeGUIでマウス操作をしないといけなかったり、
逆にコマンドでやろうとすると、いろんな引数を与えないと、ちゃんとビルドできなかったり。

また、他の人にアプリを渡す際にも、
手動で配布していると、毎回開発の手を止めないといけなかったり、
いろんな人にやってもらおうと思っても、Testflightの画面が変わってしまって、手順書が陳腐化、結局分かる人が作業する羽目になったり。

f:id:suzaku114:20200208134636p:plain

それを解決できるかもしれないのが、 fastlane というツールです。

これを使えば、例えばこのような記述を Fastfile というファイルに書いて、このコマンドを実行するだけで、
アプリのビルドからのTestflightへの配信ができます。

ただ、このコードはあくまでイメージなので、やっぱり多少の引数・設定などは必要になります。
ただ、 Xcode 付属のコマンドを直接実行するよりは、はるかにわかりやすいと思います。

f:id:suzaku114:20200208135041p:plain

先程 Fastfile に書いていた build_app などを、 fastlane では"アクション"と呼びます。

他にも、いろいろなアクションが、 fastlane では標準で用意されています。

f:id:suzaku114:20200208135220p:plain

資料作ったとき現在ですが、こんなに大量のアクションが用意されています。

よく使われそうなものをマークしてみました。

例えば、 deliver というアクションでは、 App Store に載せる説明文やキャプチャを管理して、 App Store Connect へのアップロードができます。

このような既存のアクションを組み合わせて、それぞれのプロジェクトにあったワークフローを作成することができます。

f:id:suzaku114:20200208135522p:plain

また、 fastlane のアクションは、それ自体はただのRubyのクラスです。

例えば、 build_ios_app は、このような定義になっています。

Action というクラスを継承して定義して、 run というメソッドを実装していますね。

f:id:suzaku114:20200208135828p:plain

つまりは、Ruby が書ける人は、独自のアクションが作れます。
独自のアクションが作れれば、社内独自の ipa のアップロード先へアップロードしたり、独自のシステムへの通知なんかもアクションとして作れます。

まぁ、ただ、 iOS 開発の知識がないと、行き詰まる場面は多いとは思います。。

f:id:suzaku114:20200208140139p:plain

実際に独自アクションを作ってみる場合ですが、こちらのドキュメントにやり方が載っています。

ざっくり説明すると、
雛形を作成するコマンドが用意されているので、それを実行すると"アクション名"をインタラクティブに聞かれます。
それに答えると、いい感じの場所にアクションの雛形が用意されるので、それに実装をしていきます。
最後に、 Fastfile の中でそれを実行するような記述を書けば、実際に動作させることができます。

f:id:suzaku114:20200208140519p:plain

Fastfile というファイルがこれまでも出てきましたが、こいつがビルドスクリプトとなります。

Fastfile 自体も、 Ruby で書きます。
最初に出してたイメージも、ブロックがあって、その中でメソッドをコールしていますよね。

プロジェクトに合わせた設定・フローや、アクションにするまでもない細かなスクリプトなどは、ここに直接記述できます。

これが Ruby で書けるので、ちょっとした処理がスマートに書けたりします。
事例を3つほど紹介します。

f:id:suzaku114:20200208141421p:plain

1つ目としては、 CircleCI 上で ipa ファイルを作成する際に、どのブランチに変更があったのかによって、利用する scheme を変更する例です。

CircleCI では、ビルド対象のブランチを環境変数として取得できるのですが、 Ruby では case が式なので、そのまま変数に代入できます。
あとは、それを build_app の引数に渡すだけで、好きな scheme でビルドさせることができます。

f:id:suzaku114:20200208141746p:plain

2つ目ですが、これも CircleCI 上で、Gitタグの作成を検知して、そのタグ名をアプリのバージョン名にする例です。

これも、タグ名を環境変数から取得することができるので、 set_info_plist_value というアクションに渡すことで、アプリの設定を書き換えることができます。

これを実行した後に build_app を実行することで、出力された ipa ファイルのバージョン名は、Gitのタグ名と同じにできます。

本来であれば、 XcodeGUI上で修正するか、 plist というちょっと特殊なXML形式のファイルを編集しないといけないので、ちょっと面倒なのですが、 fastlane を利用することで、自動化されたビルドの中で間違いなく変更することができます。

f:id:suzaku114:20200208142327p:plain

1つ目と2つ目は、 CircleCI 上での利用でしたが、もちろんローカルの環境で利用することもできます。

ここでは、無料版と有料版の2つの ipa ファイルを出力するようなアプリで、両方のバージョン名を一度に更新する例となっています。

パーセントと w でかんたんに配列を作り、それを each で回して、それぞれのファイルを書き換えています。

実行するときには、このようにコマンド引数として渡す形になります。

と、 Ruby の each などを使った例を出したくて書いてみましたが、実際には increment_version_number というアクションがすでに存在していて、それでも同じような動作をさせることができます。
ただ、特定の scheme だけはバージョン名を変えたくない、などのプロジェクトの特殊事情に合わせて、 Ruby のコードで実現する手段がある、というのは良い点かと思います。

f:id:suzaku114:20200208143009p:plain

と、いうことで、 Ruby ができる人は、プロジェクト毎の特殊事情に合わせて、独自のビルドスクリプトを書き、自動化を推進していくことができます。

ただ、 iOS の plist だったり、 scheme の知識は多少なりとも必要になるので、そっちの知識も必要にはなります。

f:id:suzaku114:20200208143651p:plain

続いて、 Danger の例を紹介します。

f:id:suzaku114:20200208143720p:plain

またしても突然ですが、コードレビューをしてて辛さを感じることはありませんか?

インデントのズレとか、変数名の命名規則に則ってないものとか、Pull Requestの説明文のフォーマットが決まっているのにそれを守ってくれないときとか。

そんなときに、レビューである程度指摘したりすると思いますが、
細かい指摘が多いと、指摘する方もされる方も辛かったり、
単純に時間がかかってしまい、本質的なレビューをする時間がとれなくなってしまったり、ということが発生してしまうかと。

f:id:suzaku114:20200208144019p:plain

そんなときに便利なのが、 Danger です。

公式サイトなどでは、こんな英文が書かれていて、ざっくり言うと、機械にできることは機械にチェックさせよう、ということかと思います。

f:id:suzaku114:20200208150820p:plain

もうちょっと具体的なイメージとしては、こんな感じです。

開発者が GitHub 上で Pull Request を作ったことを検知して CI サービスが動作して、
その CI サービス上で Danger が動作します。
Danger の中では ktlint や SwiftLint といった Linter が動き、その結果を Pull Request にコメントしてくれるので、開発者は他の人にレビューしてもらう前にそれを直す、といったフローです。

f:id:suzaku114:20200208151203p:plain

例えば GitHub 上での見た目ですが、コメントには大きく2パターンあります。

まずは、こちらのキャプチャのような、 Pull Request 自体にコメントするパターンです。

f:id:suzaku114:20200208151604p:plain

続いて、 Linter などの結果は主にこちらが使われるのですが、修正した行に対するコメントです。

キャプチャのように、修正した行のすぐ下にコメントが付くので、どこが指摘されているのかが、一目瞭然ですね。

f:id:suzaku114:20200208151718p:plain

ここまで、説明のために GitHub + CircleCI を例にして説明や図を書きましたが、 Danger は他のサービスとも連携できます。

リポジトリとしては、主要なサービスである、GitHub、GitLab、Bitbucketの3つに対応しています。

CIサービスとしてはさらに多くのサービスに対応しており、いろんなところで動かすことができます。

f:id:suzaku114:20200208152142p:plain

もうちょっと Danger の動きをイメージしてもらうために、まずはプリミティブな Danger の設定方法を説明します。

Danger では、 Dangerfile というファイルに、どんなチェックを行うか、結果をどのように通知するかを記述します。
この Dangerfile が、Rubyで記述できます。

使えるメソッドとしては、 warn や fail といった、重要度に応じたメソッドと、
それらに引数として file や line を指定することで、先程の行指定のメッセージを通知することができます。

f:id:suzaku114:20200208152421p:plain

そして、結果を通知する前に、チェックを行う必要があります。

多くの場合、 Pull Request ベースでチェックする際には、どのようなファイルが変更されたのか、 Pull Request の説明文などの属性情報などを見ます。

ここにあるような、各種メソッドで、そういった情報を取得することができます。

f:id:suzaku114:20200208152708p:plain

と、説明してきましたが、実際には、 warn などのメソッドを直接利用するのではなく、用意されている Plugin を利用することの方が多いです。

f:id:suzaku114:20200208152811p:plain

多くの Plugin が公式サイトで紹介されており、スマホアプリ開発でよく使われそうなものをハイライトしてみました。

ちなみに、 checkstyle_format という Plugin は私が作成したものでして、
ドキュメントへの追加依頼を Pull Request として出したら、無事に追加いただけた、というものです。

f:id:suzaku114:20200208153018p:plain

そのコードを例として出していますが、 Plugin 自体は Ruby gem です。

Plugin を継承したクラスを実装して、 Ruby gem として公開しておけば、いろんなプロジェクトで利用することができます。

f:id:suzaku114:20200208153210p:plain

利用する場合には、通常の Gem と同じように、
Gemfile に記述してインストール、 Dangerfile の中で設定や実行を行います。

f:id:suzaku114:20200208153312p:plain

ということで、つまりは、 Ruby ができれば、独自のチェックルールを作ることができます。

f:id:suzaku114:20200208153406p:plain

また、先程出てきたように、 Dangerfile 自体も Ruby で記述します。

ここ上で、 Plugin の設定や実行、 Plugin にするまでもないような細かなチェックを記述したりします。

こちらも、事例を3つ紹介します。

f:id:suzaku114:20200208153719p:plain

1つ目として、 Pull Request の説明文に対するチェックです。

Androidアプリ開発では、多くの場合、 layout の XML が書き換わっているということは、見た目が変更されています。

そんなとき、"実際に見た目はどう変わったのか"を pull して実行する前に分かれば、コードレビューがスムーズかと思います。

f:id:suzaku114:20200208153931p:plain

例えば、これはちょっと違うのですが、デバッグ用のライブラリを追加したときの Pull Request です。

どんな UI が表示されるのか?というのが、コードの差分だけだと分かりづらいのですが、キャプチャを貼っておくことでイメージしやすいと思います。

f:id:suzaku114:20200208154213p:plain

そんなチェック処理ですが、 Ruby が使えるので、そのまま書けます。

変更されたファイルの中に layout フォルダ内の XML があるかを確認し、 Pull Rquest の body に画像が含まれているかを確認します。
その条件に合致しないときに、 Danger の fail メソッドを利用することで、メッセージを通知することができます。

f:id:suzaku114:20200208154439p:plain

2つ目の事例ですが、アプリケーションコードが変更されていたら、対象のテストコードも変更されていてほしいですよね。

そんなときも、こんな感じで素直に書けます。

f:id:suzaku114:20200208154626p:plain

この Dangerfile では fail させてしまっていますが、 warn や message にすることで、強制力を下げることができます。

また、これだとかなり雑なチェックになってしまっていますが、もうちょっと頑張れば、
特定のパッケージの Hoge.kt に変更があれば、対応するテストコード内のパッケージの HogeTest.kt が変わっていること、
といったチェックも可能かと思います。
ここまでできれば、どのファイルに対するテストが変更されていないのか、をメッセージとして通知することもできそうですね。

f:id:suzaku114:20200208155019p:plain

3つ目としては、
CI を実行すると、なんらかの成果物ができることは多いと思います。

例えば、アプリの配布用のURLだったり、テスト結果の html だったりですね。
Pull Request から、それらの成果物へリンクが貼ってあると、レビューする際にも便利ですよね。

f:id:suzaku114:20200208155349p:plain

URL さえ取得できてしまえば、 Danger を使えば、それを通知することはかんたんです。

URL を取得するには、 API のレスポンスから取得したり、環境変数から文字列を生成したりしますが、 Ruby が使えるのでかんたんに書けると思います。

f:id:suzaku114:20200208155517p:plain

ということで、 Ruby ができれば、プロジェクトに合わせたルールを作ったり、自動のコードレビュー環境を整備したりすることができます。

f:id:suzaku114:20200208155602p:plain

まとめです。

Ruby が書ければ、開発環境をより良くすることができます。

fastlane を設定することで、ビルドやデプロイ周りを自動化でき、手作業の手間を減らせます。

Danger を設定することで、機械的なレビューは機械に任せて、人間は本質的なレビューに集中することができます。

f:id:suzaku114:20200208155743p:plain

という感じで、"Rubyができれば..."と言い続けてみましたが、 fastlane や Danger は他の言語の対応も進んでいて、実は Ruby に限った話ではなかったりします。

とはいえ、 Ruby は"書きやすい"言語だと思うので、それぞれでも Ruby が一番多く使われているのでは?と、個人的には感じています。

f:id:suzaku114:20200208160004p:plain

以上、ご清聴ありがとうございました。

おわりに

ということで、発表できなかったスライドを、ブログ化してみました。

これを見て、 fastlane や Danger を使って環境を改善しようと思う人が一人でもいれば良いなーと思います。

(スライド作るのも大変でしたが、記事化するのも結構たいへんですね。。。)

BuriKaigi 2020で発表します!

toyama-eng.connpass.com

来週末(2/1)に、 BuriKaigi2020が開催されます!

2017, 2018, 2019と3年連続で一般参加者として参加してましたが、2020は発表もすることになりました!

17:00より、ルームCで「 スマホアプリ開発を支えるRuby」というタイトルで発表します。
LTなどはToyama.rbやKanazawa.rbですることがちらほらありますが、25分枠はかなり久々なので緊張してます。

内容

Rubyを利用して開発環境をより良くできる、fastlaneやDangerを紹介します。

f:id:suzaku114:20200126165939p:plain

興味がある方は、当日ルームCでお待ちしております!

AWS Community Day Kanazawa に参加してきました

awscommunityday2019.jaws-ug.jp

日本で初開催のAWS Community Dayが隣の石川県であるということで、平日ですが参加してきました。

AWSについては、2, 3年前は仕事でちらほら触っていたのですが、最近ではAndroidアプリなどのクライアント側が多く、ここ1ヶ月ぐらいでまた触り始めた、という感じでした。
そのため、最近の事情に疎く、そのあたりのキャッチアップをしたかった、というのも参加の動機でした。

直近で富山Ruby会議の運営に関わっていたこともあり、スポンサーがいっぱいだったり、2トラック+ハンズオンだったりで、大変だったろうなーと思いました。
進行はスムーズで、様々な種類のトークがあり、すごく良かったです。

平日の、AWS自体が共催?ということで、もっとスーツ系の人が多いのかと思ってましたが、実際にはそんな雰囲気ではなく、実際に手を動かして使っている人が多い印象を受けました。

以下、参加したセッションと、その感想など。

基調講演 ~インフラからテクノロジープラットフォームへ~

AWS亀田さんのセッション。

基調講演らしく、「なぜAWSを使うのか?」や「そもそもクラウドを利用することでどんな利点があるのか?」といった幅広い話だったと思います。

個人的には、「AWS内の"非"マネージドサービスはEC2しかない(と言っても過言ではない、ぐらい?)」というのが意外と衝撃的でした。
たしかに思い返してみるとそうなのですが、意外と実感してなかったです。

あとは、「社内にテクノロジーblackboxを作らない」のが良いなと思いました。
受託の開発をしていると、納品後の動向がわからないこともあり、このあたりまで追ってあげる方がお客さんのためなのでは?と感じました。

今覚えておきたいWell Architected Framework(W-A)と便利なツール

AwS舘岡さんのセッション。

Well Architected Frameworkについて、なんとなく存在は知っていたけど、今回で初めてちゃんと中身を知った気がします。
直近で、インフラの構成やそのレビュー?をする機会があるので、こういったツールも使いながらやっていこうかと思いました。

また、ほとんど知らなかったSystems Managerがかなり便利そうでした。
SSM Inventoryでのデータ収集や、Sessions ManagerでのSSHなど、すぐに使えそうな知識を得られたのが良かったです。

AWSでAlexaスキル開発をスケール&ブーストする

Alexaスキルをがっつり作る話。

「Alexaスキルを作る」ことは「Lambdaの関数を作る」とほぼ同義とのこと。
(音声の解釈などは勝手にやってくれるし、そこから音声化するのも勝手にやってくれる)

ASK CLIというものがあって、手軽に始めるには良さそう。
とはいえ、がっつりAWSのサービス群と組み合わせようとすると、いろいろつらみがありそう。

Cognitoと組み合わせたり、Amplifyと組み合わせたりで、Webとの接続も比較的簡単にできそう。

海外リモートワークとAWS運用

年に2ヶ月程度、台湾でリモートワークをしている話。

昔ながら?のオンプレ環境だと、物理サーバの世話など、リモートワークでは出来ない作業も多かったけど、AWSだとそもそも手元にないので、どこにいてもそんなに変わらないとのこと。

リモートをする上で気をつけていることとして、連絡が取れるように(取れない場合は事前に伝えておく)したり、サポートし合う関係を作ったりなど、自分も納得できる内容だったので、改めて気をつけていこうと思いました。

AWS・Lambdaを活用した薬局向けシステムのプラットフォーム構築

アパレル業界出身で、父の事業の一部を受け継いで?薬局関連のサービスを開発している話。

異業種から入ってきて、これだけ出来ているのはすげぇなーと思いました。
また、こういった企業が北陸にもあるんだなーという再認識が出来、よかったです。

AWS運用の事例紹介

受託のアプリ開発を、AWSのインフラを利用して行っている話。

開発期間が2〜6ヶ月が多いというのは、結構驚きつつ、よく考えれば自分たちも半年ぐらいでリリースする案件はちらほらある気もしました。
とはいえ、ユーザ数が結構多いアプリが多かったので、自分たちももっと効率よく作れるのでは?と考えさせられたセッションでした。

多拠点ガソリンスタンド在庫・販売大量データの漏洩分析・リアルタイム監視を支えるAmazon RedshiftとAWSインフラ構築

SNS禁止セッション。

「玉田工業株式会社」という社名は聞いたことがなかったのですが、ガソリンスタンドなどの地下タンクにおいて大きなシェアを持っている会社とのこと。

そこから、ガソスタの監視システムなどを、AWSを利用して構築しているとのこと。

製造業で実はすごいシェアを持ってて、そこから派生してシステムを作れば強いのに、そこに気づいていない企業は結構ありそう?と思いました。

拡張して使う Serverless & Amplify

アプリのリニューアルをするのに、ServerlessとAmplifyを使った苦労話。

TypeScriptをLambdaとReact Nativeで利用することで、同一言語でサーバサイドもクライアントも作ったとのこと。
たしかに、言語が同じであれば考え方もある程度共通化でき、少人数や短期間ではかなりメリットありそう。

Serverless Frameworkは、pluginがかなり充実しているようで、困ったら作る前に探してみたら良さそう?と思いました。

Amplifyのカスタマイズ方法も興味深く、機会があったらやってみたいと思いました。

クラウド活用で 社員数10倍増を乗り切った 6年間のIT施策を振り返る

いわゆる"情シス"を、ちゃんとやっていった記録の話。

情シスは、縁の下の力持ち的なイメージで、目立たないイメージがありましたが、こうやってきれいにまとめてもらうとかなり重要なポジションだと感じました。

また、昨今はいろんなサービスがあり、試用期間が設けられているものが多く、とりあえず小規模に導入してみてダメだったら乗り換える、というのが良さそう。

感想まとめ

Systems ManagerやAmplify、LambdaといったAWSのサービスを知る・理解することが出来たのはもちろん良かったのですが、
自分が住んでいる北陸で、独自のサービスや付加価値を提供している事例を知れたのがよかったです。

自分は、北陸に住んでいるとはいえ、東京の会社に所属して仕事をしているので、こういったコミュニティ経由でしか北陸の事情を知ることが出来ないので、 こういったイベントを企画してくれた運営の方々には感謝の気持ちでいっぱいです。

タイミング・知識が合致したら、今度は自分も登壇できるように頑張ろうと思います。

以下、当日にとってたメモ。

## オープニング

JAWS-UGについて
JaWS-UG 金沢について 2011年1月に活動開始。
AWS Community Dayについて AWsと共催。Community Dayとしては、日本で初めて。

トラックAが基本的なものがメイン。トラックBが応用的なものメイン。
写真撮影NGの人のために、ストラップの色が違う。

#jawsug #awscommunityday
が本日のハッシュタグ。

## 基調講演 ~インフラからテクノロジープラットフォームへ~

AWSのモデル。固定資産型からサービス型へ。
コスト削減だけでなく、ノウハウをためていくことを推進。
Digitalization(ソフトウェアによる価値最大化)を、開発者とともに目指していきたい。
モノは、買ったときが最大の価値を持っている。サービスは、日々進化していく。
アプリケーションを請負で塩漬けしても、AWS部分が進化していく。もったいない。
よく出るキーワード「サーバレスコンピューティング」
ただ、インフラ費用の見積もりが課題。プログラム実行回数とメモリで課金。
CAPEX / OPEX クラウドを利用することで、無駄のない投資。
CAPEXのほうが、価格が変動しないので良いと考える人もいる。
AWSはマネージドサービスを推進している。非マネージドサービスはEC2だけと言ってもいいぐらい。
ただ、マネージド・サービスはロックインに感じる人もいる。
アメリカの大きな企業の平均存続年数は67年->15年と、かなり短くなっている。サイクルの速さが大切になってくる。
障害を踏まえた設計指針:RTOとRPO このあたりの設計を、事前に行っておけば、決まってくるものが多い。
良いものを作ろうと思うと、コストが上がってくる。
AWSには、最新テクノロジーを利用するためのサービスが多くある。
ownershipを置いてきぼりにするのは問題が大きい。(データを外部のSIerに丸投げして機械学習させるなど)
「社内にテクノロジーのblackboxを作らない」という考え方が大事
re:inventでラスベガス行くなら、観光などと合わせ、UBERなどのサービスを経験してみるのがおすすめ。
Uberlization: 異業種がITを駆使して既存ビジネスを変えていく。
AWSでは、「強化学習」に力を入れている。
教師あり学習では、人間の能力でキャップされやすい。
強化学習:コンピュータ同士で囲碁の対戦をさせるなど。良い行動に対して報酬を与える。
DeepRacer:ラジコンカー。そこに搭載する学習モデルのシミュレーションなどを提供している。
ハンズオン「はじめての迷路学習」を提供している。
新しいことは失敗する。ただし、その経験を蓄積することで、良くなっていく。
10年間に何が変わるか?よりも、何が変わらないか?を考えたほうが良いことが多い。その実現方法を進化させていく。

## 今覚えておきたいWell Architected Framework(W-A)と便利なツール

パートナーソリューションアーキテクト
賢く・安全に使うために。ベストプラクティス集としてWell-Architected Frameworkがある。
クラウドネイティブとリフト&シフトの2つのアプローチがある。
2015年のre:Inventにて発表後、毎年アップデート。
10年以上のSAとお客さんのベストプラクティスを無料で使える。
記載されたホワイトペーパーと、支援するAWSのSAで構成される。
最近、日本語化や、(PDFから)Web化された。
Well-Architected Toolが日本語対応。(ただし、動画は英語)
あくまで「原則」
クラウドでの一般設計原則
質問・回答の形式で、ベストプラクティス。
ただし、全てに則っているのが必須ではなく、リスク・改善点を顕在化させることが目的。
要件検討や、設計・構築・運用の各場面で、AWS W-Aを活用できる。健康診断のように、定期的に確認するのがおすすめ。
Cyber Agentでは、カスタマイズしたものを利用している。AWS W-Aは、あくまでAWSの考え。
W-Aのレビューは、システムの関係者全員を呼ぶのがポイント。それぞれで、優先することが違っている場合がある。
レビューの進め方が重要。ホワイトペーパーでは、3ページも解説している。
・お菓子を用意する。
・監査ではない。
・複数回実施する必要がある。設計前と本番前など。
短くて3時間ぐらい。長いと8時間とか。
r5.xlargeのほうが、r3.xlargeより性能高く安かったりする。見直しが大事。
マネージドサービスの9割ぐらいは、お客さんの声から生まれている。
GuardDutyなど、セキュリティ対策サービスなども登場してきている。
Systems Manager:サーバ群を管理するツールセット

Demo
EC2 -> SSM Inventoryに集約し、S3 -> Athena -> Quick Sightで可視化
Amazon Linuxであれば、Systems Managerにつながっている。(他のOSなどは、Agentのインストールが必要)
インストールされているソフトウェア・バージョンなどが一覧で出てくる。
Systems ManagerからSSHできる。踏み台が不要かつ、SSHのポートも開けなくてよい。
古くからAWSアカウントを持っている場合に、権限が足りなくてQuick Sightが上手く作れなかったりする。

## AWSでAlexaスキル開発をスケール&ブーストする

Alexaスキルを作るのは、ほぼLambdaの関数を作ること。
ASK CLIというものが提供されており、標準の環境がかんたんに作れる。
構成管理はしてくれない。Nodeのバージョンが変わったりは手動で対応する必要がある。
CloudFormationが使えるASK CLIも作成中。現時点では、がっつり作りたい場合は別管理したほうが良さそう。
CodeStarを使うと、プロジェクトの作成がかんたんに行える。
S3をデータベースにする選択肢もある。DynamoDbより、従量課金がゆるやか。
クエリしないデータは、DynamoDBよりS3のほうが管理が楽。
adapterを差し替えれば、DynamoDBからS3に変えられる。
コールドスタート問題。VUIだと、ローディング表示もできず、ユーザが不安になりやすい。
serverless-warmup-pluginなどでウォームアップや、Lambdaではなく常時稼働(EC2など)に置き換えるなど。
Pollyは機能限定で、無料で使える。(自分で組み込まなくても良い)
AlexaはOAuth2でアカウントリンクできる。Congito User PoolsはOAuth2に対応している。
Amplifyを経由して、mobileアプリなどとも連携できる。
Alexaスキルを作成すると、$100クレジットがもらえる。

## 海外リモートワークとAWS運用

5年くらい前から、台湾と日本を行き来している。
1年で2回、1ヶ月程度が台湾。
そもそも、AWSのリモートを扱う場合、すべて手元にないもの。
そのため、国内にいても、海外にいても大差ない。

顧客・案件ごとにAWSアカウントを分離。
構成管理はCloudFormation。YAMLで書いて、GitHubで管理。
CloudFormation / Roadworkerの2つで管理。

オペレーションとしては、SSMを利用。
作業用の環境として、WorkSpacesを利用している。Office事務用など。

基本的には、SystemsManager経由でSSH。

リモートで気をつけていること。
・"システム"を止めないこと。冗長構成だったり。
・電話連絡がつくように。つかない時間は、予め連絡。
・リモート機関にできない仕事を残さないように、スケジューリング
突発の場合
・社内でプロキシしてくれる人
・ビデオコールでのサポート
・サポートし会える環境・関係性を作っておく
・最悪、帰国する覚悟

海外での通信環境
・LTEのみ。30日無制限で4,000円ぐらい。
・スマホ3台体制。日本のSIM端末も持ち、SMSでの2段階認証など。
 着信を確認し、050 plusで折り返す。通話料の問題など。

## AWS・Lambdaを活用した薬局向けシステムのプラットフォーム構築

アパレル出身。
兄と会社を立ち上げた。医療関係者向けのサービスを提供している。

在庫管理システムを作り、Xamarinでのアプリ、API/SDKを作りプラットフォーム化、AIで需要予測などと広げていっている。
父のシステムのノウハウを継承している。

薬局のインフラを整えていきたい。-> 在庫管理システムをプラットフォーム化。
本当のところは、自分たちの開発工数・管理工数を下げたい。セットアップを簡単にしたい。というのが本音。

## AWS運用の事例紹介

受託のアプリケーション開発がメインの事業。
開発は、2〜6ヶ月程度が一般的。
EC2とRDSとS3のみを利用することが多い。
Management Console、CloudWatch Backupを、リリース後の運用で利用する。

## 多拠点ガソリンスタンド在庫・販売大量データの漏洩分析・リアルタイム監視を支えるAmazon RedshiftとAWSインフラ構築

SNS禁止セッション

## 拡張して使う Serverless & Amplify

20年ぐらいやってるサービスをリニューアルしたい。既存の開発会社に不満があり、スイッチ。
リニューアル内容が固まっていない。現行の基本機能は必須。iOS/Android両方。
-> 動くものを早く作る必要があった。
バックエンドに、一部オンプレ環境があった。
そのまま移行すると、インフラの管理などに大きな工数がかかってしまう。 -> サーバレス
スマホ側は、Obj-CとJavaだった。それぞれ作る期間・経験値が無かった。
Node.js / React Nativeの組で作ることに。TypeScriptが共通。
serverless frameworkを利用することに。ローカルで実行でき、YAML+コマンドでデプロイできる。
serverless-offlineというプラグインで、ローカル実行できる。
オンプレとの接続に固定IPが必要 -> serverless-vpc-plugin
CloudFormation templateが200で制限されている。1APIで複数のCloud Formationリソースが作られる。 -> serverless-plugin-split-stacks
構成を再構築したい。EIPが変わってしまう。 -> serverless-plugin-additional-stacks -> vpc-pluginが不要に
VPCに入れたLambdaは、コールドスタートに10秒程度。 -> serverless-plugin-warmup
開発環境だけ欲しいリソース。 -> serverless-plugin-ifelse
こんな感じで、現在ではいろいろなpluginが入っている。探せばだいたいある。最終手段は、CloudFormationテンプレートを書く。

AWS Amplifyの拡張性
CLI + Cloud Services + Framework + Developer Tools
今回は、CLIとバックエンドが中心。
amplify <category> addなどを実行すると、CloudFormation templateが作成される。pushすると、適用される。
categoryとして存在しないもの、カスタマイズが必要になるものも出てくる。
・既存カテゴリーのテンプレートを編集
・カスタムCloudFormationスタックの追加
・プラグイン(最もパワフル)
例:クライアントからS3へアップロード。CloudFrontの署名付きURLを発行して任意のユーザに共有。
スタックを追加することで対応した。
1. CloudFormationテンプレートを追加する
2. amplify/backend/backend-config.jsonを編集する
3. コマンドを実行し、CLIに認識させる
backend-config.jsonに書くことで、他のリソースのARNなどを引き継ぐことができる。
プラグインには4つのタイプがある。category / provider / frontend / util。category / utilあたりをよくつくる。
pluginを作るコマンドがある。
プラグイン実装に関する情報は、まだ少ない。amplify-cliのソースが一番参考になる。
amplify-helpers配下には、便利な定義がいろいろ入っている。
最初はカスタムスタック作って、2, 3度必要になったタイミングでプラグイン化するのが良さそう。

## クラウド活用で 社員数10倍増を乗り切った 6年間のIT施策を振り返る

2018年の内容をアップデートしたもの。
情シスとして使っているAWSの話。
6年で、40人から370人になった。

独自の請求システムを使っていた。
営業と営業事務のやりとりなどで、てんやわんや。
-> IT推進室を結成して、関係者を消臭。(社長直轄の"推進室"とすることで、立場を明確に)
Salesforce -> 請求データ作成 -> マネーフォワード請求
見積システム・請求システム・個別のスプレッドシートなど、それぞれのパートで作成していた。
AWSから請求を吸い上げるサービスがあり、それをSalesforceに投入、そこからマネーフォワードに連携。
3年前は600通だった請求書が、現在では3200通になっており、昔の仕組みだったらかなり無理があった。
Lambdaを使っているが、そこは月4000円ぐらいで動いている。

次に、ユーザー管理に手を付けた。
各種サービスを利用していたが、人によってはパスワード使いまわしや、ポリシーを強制できなかったり。
ID基盤をActive Directoryに集約。SSOやLDAP導入。1Password Teamsを全社導入。
Slackだけは、連絡がとれなくなってしまうので、別管理としている。
ID無効化を集中管理できる。
パスワード定期変更運用を廃止できた。<-ISMS認証とかで突っ込まれても、上記の対応のほうが強いと回答できる。

リモートワーク
AWS上に、Sophos UTM設置。MarketPlaceにある。
本社に、SOCKS4プロキシーを設置。これで、本社のIPから出ていける。(DirectConnectを利用)
AWSをハブに、全拠点と通信可能。

労務周り
給与明細を手渡し・郵送、経費精算はExcelを印刷・押印だった。
SmartHR・マネーフォワードを導入

1 - 3 - 5 目指す人数・規模よりも大きなものを対応できる状況を。
誓約より制約。やってはいけないことは、出来ないようにする。
システム導入にあたって、机上比較より、トライアル。自社運用。業務の方を合わせる。
帳票のデザインなど、細かな部分は自社で構築・運用。コアな部分(Salesforceの処理部分)は、専門家に任せる。

富山Ruby会議01に運営の一人として参加しました

toyamarb.github.io

11/3(日)、三連休の真ん中に富山Ruby会議01が開催されました。

富山では(北陸でも)初のRegional RubyKaigiということで、Toyama.rbにほぼ毎回参加している私も、運営の一人として参加しました。
(運営とは言っても、細かな落ち穂拾いと当日の写真撮影ぐらいで、そこまで役に立てなかったかもですが。。。)

参加人数について

1週間前ぐらいになっても、思ったほどに人が集まらず、結構不安がありました。
懇親会も、お店からは「貸し切りのためには30人以上でお願いします」と言われており、「足りなかったらどうしよう。。?」と思ってました。

そもそも、富山で "Ruby" を主題にした大規模なカンファレンスをやって、どの程度来てくれるんだろう?という不安がずっとありました。

ただ、数日前になると続々と申し込みが増えて、椅子足りたっけ。。?ぐらいとなりました。
結果としては、本編60人オーバー(+16人の発表者)、懇親会も当日追加を含めて38名(だったかな?)ぐらいの大盛況となりました。

本編

本編の最中は、写真撮影をしていたので、真剣に聞けなかった場面も多々ありましたが、覚えてる限り・スライド見直しながらで感想などを書いていきます。(敬称略)

招待講演「○○からRubyへ」伊藤 淳一

○○からRubyへ / #toyamark - Speaker Deck

○○からRubyへ・Ruby事始めコーディング動画 #toyamark - YouTube

型がない(語弊あり)言語でも、ある言語でも、結局は動作確認するし、テスト・レビューするよね。そんなに変わらなくね?とのこと。
たしかに、ある程度チームのスキルレベルが高ければ確かにと思う反面、それが不安定な状況では、型の安心感はあるなーと思います。

そのためにスキルアップし、良いコードを書いていく必要があるよね。ということで、"良い"の一つである"読みやすいコード"の話(次のセッション)に続く。

他にも、経験者が語るRubyの利点などが多く、今後比較が必要な場面では見返したら良さそうなスライドでした。

「読みやすいコードとRubyらしいコード」黒曜

読みやすいコードとRubyらしいコード

個人的にも、いつも気にしている"読みやすいコード"について、リーダブルコードからエッセンスを抽出した感じ。
また、そこに"Rubyらしい"を付け加え、Rubyにおける"読みやすいコード"についての考察。

名前の付け方や処理の書き方など、自分でも気をつけつつ、教育もできるようになっていかないとなーと思いました。

「初心者PHPerがRubyキメて思うこと」oratake

初心者PHPerがRuby(+Rails)キメて思うこと - Speaker Deck

初心者に近い視点から、どのようにしてWeb系企業を目指し、学習していったかというお話。
個人的には、だいぶ昔に通った道、、感がありましたが、今ではRailsチュートリアルが整備されていたり、各種いろんな動画教材があったりと、便利な時代になりましたね。
ただ、情報がありすぎて、その取捨選択するスキル・良い情報にたどり着くためのスキル、などが必要になるのかなーと。
そのために、コミュニティに参加するのは良いですね。

「Crawler on Rails」suginoy

GitPitch Slide Deck

お昼を挟んでクローラーを作るお話。
サーバと逆の動作だからRailsを使えるのでは?って発想が面白かったし、実際に意外と使える部品が多いのも面白かったです。
個人での開発だと、それに合わせた選択が必要だよなーというのは共感しました。
外部サービスに依存してるアプリケーションでも、外部サービス側の動作が想定外だったり、急に変わったりするので、どこまで厳密にチェックすべきか?というのは考えないといけないよなーと思いました。

「TracePointから学ぶRubyVM」joker1007

TracePointから学ぶRubyVM - Speaker Deck

ガチ枠。
写真撮りながらというのもあったけど、おそらく半分も理解できてない気がします。
(そもそも、TracePointとは?ってのが、いまいち理解できてない気がする。)
わからないなりに、「プログラムもプログラムで動いている」ということが改めて実感できた気がします。
また、これだけ強い人でもコードから変数名の意味は推測するしかないということだったので、コメントだったり略さないことだったりは大事だなーと思いました。

「北陸で Ruby なお仕事に携わるための3つの戦略」清原 智和

北陸で Ruby なお仕事に携わるための3つの戦略 - Speaker Deck

エモい話枠。
特に地方だと、自分のやりたい仕事をやりたければ、いろいろ越境しないと難しいよね、という話。
実際に経験したことがベースの話だったので、かなり納得感のある話だった。
とはいえ、自分にここまでできるのか?という気持ちも大きいので、今の会社を辞めたとしても、リモートできる企業を探そう、、、というきもちになりました。

「業務で!Rubyを!キメる!」伊藤 浩一

Project automation for internal affairs - Speaker Deck

ちょっとしたツール(ワンショットのツール)であれば、比較的自由に技術選定しやすく、やりたいことをやりやすいという話。
個人的には静的解析とかにちょっと興味があり、RuboCopの話に興味があったけど、想定外の使い方で面白かったです。
ASTってちゃんと見たことなかったんですが、説明を聞いているとなんとなーく読めそうな気はしてきました。

「mrubyでハローワールド!」羽角 均

mruby de Hello World! - HASUMI Hitoshi - Rabbit Slide Show

弊社からのスピーカースポンサーということで、mrubyの話。
mrubyとかmruby/cが別ということは知っていたけど、ROMやRAMの使用量も違っているとのこと。
その分制約も違うので、使う場所にあわせて考える必要がありそう。
そこから、コンパイラを作る話になったけど、わかるようなわからんような。。。
ただ、順々に説明されることで、なんとなくの流れはわかったような気がしました。

LT1: muryoimpl

RSpec導入奮戦記/The struggle of introducing RSpec - Speaker Deck

Rspecでのテストコードを、短期集中で増やしていく話。
テストを広めていくための方法や、その際に気をつけたことが紹介されていました。
自分もテストを書いて、広めていかないとなーと思っているので、参考になりました。

LT2: ふぁらお加藤

俺 と Ruby - Speaker Deck

個人事業主として、なぜRubyを選択するのか?という話。
Rubyで仕事してる人は、比較的こだわりの強い人が多く、ハズレが少ない印象とのこと。
個人的には、Ruby書いている人たちは、そういう層と、"Railsでしか書けない層"に大きく二分されると思ってるので、そこだけ見分けられれば、いい感じの人と仕事できそうというのは納得。

LT3: 相生ゆら

元富山県民から見たRubyコミュニティ - Speaker Deck

富山弁枠。かつ初心者枠。
実務経験4ヶ月で、この規模の会場でLTしたのはいい経験だろうなーと思いました。
パーフェクトRuby読んで、アルゴリズムの問題をゲーム感覚で解き、Railsチュートリアルをサクサク進められるって、かなり優秀なのでは。。?と思いました。

LT4: wtnabe

join-kanazawarb-or-7years-passed-since-it-was-borned - Speaker Deck

地方勉強会の歴史の話など。
Kanazawa.rbは7年継続しているとのこと。すばらしい。
地方で"Ruby"で完全に縛ったコミュニティ・勉強会を開いてもつらいのは、全力で同意。(そもそも、自分もそんなにRubyを書かない)
最近行けてなかったのですが、Kanazawa.rbも久々に参加したくなりました。

LT5: Yuka Kato

(スライドは公開されてなさそう?)

Capybaraの裏側の話。あと、Capybaraのかんたんなおさらい。
BrowserとDriverにいろいろ種類があって、用途によって選ばないとなーと思いました。
PhantomJSがメンテ終了してたのは聞いたことあった気がしますが、それに引きづられる形でDriverも世代交代してる?
次に使うことがあったら、Apparitionはちょっと調べてみようと思いました。

LT6: 水尻裕人

RUBYでアッカーマン関数の計算をがんばる方法 / How to write ackermann function in ruby - Speaker Deck

アッカーマン関数って、聞いたことあるようなないような、、ぐらいでしたが、たしかにまともに計算できなさそう。
再起って、アプリケーション開発ではあんまり使うことがないけど、いざ使うとなるとテクニックが必要になるので、覚えておいて損はなさそう。
最適化オプションつけてみたけどだめでした -> Ruby自体のコンパイル時に指定が必要だよ(うろ覚え)的なツッコミがすぐに入るあたり、すごく強い人達を呼べたんだなーと再認識しました。

LT7: よしだ たけひこ

RubyによるC言語コードのメトリクス測定

組み込みエンジニアが、本業のすぐ隣の開発(調査)ツールとして、Rubyを使う話。
小さなプログラムをかんたんに動かせて、正規表現がさくっと使えて、外部のライブラリもかんたんに導入できるということで、ちょっとした調査ツールには確かに良さそうですね。
で、厳密なツールを作るのは難しいものでも、用途に合わせて、人力の補助ツールとして作るのは良さそうですね。

LT8: 羽角 均

(スライドなし)

2度目の登場。
先程の発表で入ってなかった、Generate Codeの部分のライブコーディング?
vimでライブでバイナリ列を書いていくという荒業に出て、なんとなくやりたいことはわかったけど、途中のハプニングで完成できずに終了でした。
なんとなく、バイナリ列がどうなっているか?が、わかったような、わからんかったような。

招待講演「型なし言語のための型」松本 宗太郎

型なし言語のための型 - Speaker Deck

最後に今後のRubyの話。
Ruby3で型を入れようとしていることは知っていたけど、パフォーマンスが目的ではないというのは知らなかった。
型関連の歴史についても全然気にしたことがなかったので、型推論が思ってたよりも昔からあったことには驚きました。
最初の招待講演で好きなメソッドとして挙げていた map が、最後の招待講演で邪魔者扱い(語弊)されていたのが面白かったですね。
Union typesやflow-sensitive typingなど、"型なし言語のための型"として必要な要素を徐々に理解できました。
TypeScriptの成功は、たしかに特異なことだったんだと、なんとなく理解できました。
「人類は型を書く」ってのは確かに面白いと思いました。型を書かなくて済んでいたJavaScript界隈で、これだけTypeScriptが流行っているのが面白いなと。
TypeScriptは、センスよく型を解決しているんだなーと感じました。
型なし言語に型を導入するという意味で、 incompatibleという指定の必要性は理解できるけど、もともと型のあるJavaから入った自分としてはなんだかなーという思いもあったりします。

全体の感想

懇親会でも話に上がりましたが、発表の順番が絶妙だったと思います。

別言語からRubyに入った話・Rubyの良さの話

Rubyらしいコードの話

初心者がRubyに抱いた感想
という比較的初心者向けのセッションを午前中に聞いて、
Rubyでちょっと変わったアプリケーションを作る話

RubyVMの話で深淵をちょっと見せて

頭使ったところで、北陸(地方)特有のエモい話

エモい話入れつつ、ちょっとASTの話

mrubyをベースに、言語の作り方の話

LTでちょっと閑話休題

型のがっつりした話

という感じで、緩急つけつつ、前に聞いたことがちょっとずつ関連する流れでした。

毎年やるのは運営的にきついですが、数年後にはまたやれたらいいなと思いました。
まずは、Toyama.rbに継続的に参加しつつ、集客など手伝えることは手伝っていきたいと思います。

Algolia 勉強会 in 金沢に参加してきた

最近はバタバタしてて参加してなかったkanazawa.rbさん中心で、
全然行けていないJAWS-UG 金沢さんの協力と、
DMM GAMESさんの会場で、
Algoliaという検索サービスの勉強会に参加してきました。

connpass.com

数週間前に、「Firestoreのデータに対して全文検索的なことをしたい場合はどうすれば。。。?」と悩んで、

全文検索  |  Firebase

にたどり着いていたので、タイムリーな勉強会でした。

Algolia のご紹介

www.slideshare.net

日本にいる唯一のAlgolia社員である篠原さんの発表。

Algoliaは世界中でいろんなところで使われており、日本でも100社以上が実際に利用しているとのこと。
→ 実績があるので、安心感がある。

フランス発だけど、最初から世界展開をめざして、ドキュメントも英語だし、社内も英語。
→ すげぇ。どこぞの会社とは違う。

検索のコアな部分はAWSなどのクラウド環境ではなく、自分たちで物理インフラの調達もしてるっぽい?
それによって、物理レイヤまで含めた、突き詰めた高速化をしているらしい。
→ 懇親会でも聞いたが、速度へのこだわりはかなり強いらしい。たしかに、デモなどでも信じられないレベルで高速。

社内でも自分たちのサービスを利用して、社内ドキュメントの検索エンジンを作成することで、各人の作業効率が上がったらしい。
→ よさげ。自社でもやりたい。インクリメンタルに高速に結果が出るのは、ちょっと体験が変わる。

検索では、TF-IDFに重みづけなどのチューニングすることで適合性を上げる=良い検索結果を出すようにすることが一般的?なところだが、職人芸な部分が出てくる。
Algoliaでは、Tie-breaking Algorithmを利用し、チューニングをやりやすくしている。(また、高速なレスポンスにも寄与しているっぽい)
→ サービスごとに「良い検索結果」は変わると思うので、難しい部分ではありそう。ただ、その試行錯誤がやりやすそうなのは良い。

Algoliaはダッシュボードも充実しており、結果0件だったクエリや、ユーザの選択が検索結果の何番目だったかなどを追える。
特定のキーワードに対して一番上に表示させたりもできる。特定のキーワードを、別の条件式に変えることもできる。
→ 実際のユーザの行動からチューニングへフィードバックしやすそう。

Algolia ハンズオン

www.slideshare.net

AlgoliaのInstantSearch.jsを利用して、step by stepでwidgetを追加していく。

とりにかく、「こんなにかんたんに、検索周りのUIを実装できる!」というのがよくわかるハンズオンでした。

いい感じにstepを踏んでもらっていたし、答えも用意されている状況だったので、並行して自分で作成したアカウントでもやってみました。
ただ、 refinementList widgetなどがエラーになったままなのは謎のまま。。。(プランに依存したりするのだろうか。。?)

にしても、価格.comみたいな、カテゴリとか価格とかいろんな軸での検索をかんたんに作れるのはすごかった。

Algolia 利用事例紹介

speakerdeck.com

クラウドファンディングプラットフォームであるCAMPFIREでの具体的な事例。
実際に使っていった中で、良かったところや難しかったところが聞けたのは良かった。

クラウドファンディングの特徴として、文章部分に熱い想いが入って文章が長くなりがち。
エンドユーザからも、複数キーワードからあいまいにマッチした結果を求められる。
→ 通常のショッピングサイトとは、求められるものが違いそうで、難しそう。

使ってみて、実際にレスポンスが爆速だった。
また、ドキュメントは充実しており、SDKもオープンになっているので迷いづらい。
monitoring、analyticsが優秀。
→ 検索性能の向上とかは難しそうだけど、consoleが充実してて試行がやりやすそう。

レコードごとのサイズ制限や、ソートは難しい。
→万人向けではなさそう。ただし、ハマる場面は多そう。

開発者ごとのdevやstgなど、環境ごとの切り分けを考える必要がある。
dev環境を共用してたりすると、誰かの開発によって不正データが発生し、開発が止まったり。
→このあたり、ローカルシミュレータがほしい気がしました。

超高速リアルタイム検索APIをたぶん支えているAWS

speakerdeck.com

https://techracho.bpsinc.jp/hachi8833/2018_06_20/57589 をもとに、AWSの構成紹介と、それぞれの要素の最近のリリース。
Algoliaの管理側インターフェースは、AWSの鉄板構成らしい。(ただし、資料時点からはいろいろアップデートされてる。。?)

AWSのアイコンが一新されてた、ってのが一番の衝撃的アップデート。

EC2で24TBメモリインスタンスとか、C5nインスタンスが増えた。
→24TBメモリインスタンスとか、誰が使うんだろう。。。

ELBは、L7的な動きをするALBも出てきたし、Lambdaをバックエンドにもできる。
→EC2インスタンス立てて、フルスタックなフレームワークをやらないって選択肢もありそう。

RDSにサーバレスモードもできた。
→利用頻度の低いアプリとかは良さげ。

AWS Well-Architectedを読もう。
それをベースに、要件に合わせてカスタマイズしよう。
ただし、「本当に外れる意味があるのか?」は問い続けよう。
→ベース知識は大事。作るサービスごとに特性が違うから、それに合わせてカスタマイズする。しない選択肢もある。

以下、メモそのまま

## Algolia のご紹介

日本のAlgolia社員は現在1名のみ。
元AWSの社員。
アルで利用されている。
https://speakerdeck.com/vexus2/alu-algolia いい感じの資料らしい。
世界で7000社以上に利用されている。
日本にも、東京と大阪にデータセンターがある。
東京にもオフィスが解説される。
日本でも、100社以上が利用している。
KARTEのサポートサイトなどでも利用されている。
shopifyやzendeskのオプションとしても利用され始めている。
Twitchでのインクリメンタル検索などでも利用されている。
Algoliaは、最初から世界展開をめざし、フランス発だけど最初から英語メイン。

すばやく構築、高速な検索。
開発者の使いやすさ以外にも、ビジネスの人やエンドユーザーの使いやすさも求めている。
HTTPでリクエストして、JSONで返却される、というのがメイン。
99.999%以上のSLA。高速なレスポンス。
インフラのぶっちゃけ話が、ブログになっている。
Railsからalgoliaを使うための翻訳記事もある。
最近、Azure上でも動くようになった。
Algoliaは、基本的にメモリに情報を載せている。ベアメタルサーバでは対応できないレベルのデータ量の利用も出てきた。

社内での、いろんな情報をインデックスさせてみたら、社員それぞれが10分ぐらい時間を節約できたのでは?という状態に。

件数が少なく、更新頻度が低いのであれば、JSONファイル+grepでも良い。
ある程度までは、RDBMSのlike検査でも対応できる。
全文検索エンジンを入れようとすると、運用経験が必要。

検索自体は難しい技術じゃない。
転置インデックスを作成する。
データがでかくなってくると、管理するのが難しくなってくる。
"適合性"、良い検索とは?
TF-IDF
特定のフィールドをブーストしようとすると、勘の部分が多くなってくる。
日本語の区切りは難しい。
Algoliaは、自然言語処理に充填をおいているわけではない。
Tie-breaking Algorithm
typo検索について、日本語もできるようになった。
geo検索できる。
ランキング方式をWeb上で変更することができる。

dashboardも充実している。
結果0件だった率など。
クリックされたのが、何番目の検索結果だったのか?など。
特定のキーワードに対して、一番上に出したいものを指定できる。
"安い"というキーワードに対して、"$20以下"に置き換えることができる。

## Algolia 利用事例紹介

CAMPFIREでの事例
月間200万アクティブユーザ
23,000プロジェクトぐらいがある。

文章については、1,000,000文字を超えることもある。
複数キーワードでのあいまい検索。
→自前でやろうとすると、コストが高い。 →Algoliaを導入。

本当に爆速。
想定以上にSDKとドキュメントが充実。
想定以上に、monitoring、analyticsが便利。

index size limitとjson frameとSDK
リミットが10KB。登録データをトリミングしたり。
POSTするJSON frame全体で10KB

ソートとreplicaとrecord limit
複数のソート種別を実現しようとすると、replicaを用意する必要がある。
レコード数が倍で増えてくる

deploymentとtestとqa
環境ごとに、どのように切り分けるか。
手元でのテストをするために、indexを切り分けるか?
他の人が作った不正なデータで壊れる。


## 超高速リアルタイム検索APIをたぶん支えているAWS

メモ取るの忘れて聞いてたので、スライド見直しながらメモとりなおし。

https://techracho.bpsinc.jp/hachi8833/2018_06_20/57589 をもとに、AWSの構成紹介と、それぞれの要素の最近のリリース。

管理インターフェースは、AWSの鉄板構成で作られてるっぽい。(ただし、記事から更新されているものもあるという噂)

AWSのアイコンが一新されたらしい。

EC2
18TBと24TBメモリのインスタンスが追加される予定。
C5nインスタンスという、通信速度関連に特化したインスタンスが追加された。

ELB
L7的な動きをするALB。
ACMでhttpsの証明書を設定できる。
Lambdaの実行もできる。(EC2インスタンスがなくても、独自処理を実行できる)

RDS
サーバレスモードもできた。
ただし、寝た後の一発目は遅いらしい。

AWS Well-Architectedを読もう。
それをベースに、要件に合わせてカスタマイズしよう。
ただし、「本当に外れる意味があるのか?」は問い続けよう。

おまけ

車で行ったので飲めなかった日本酒

過去の経験を生かして、控えめな量のピザ(どうせ二次会?行くので)

金沢 - 富山間の2時間弱の運転後の、深夜のギルティ。

BuriKaigi2019に参加してきた

今年も BuriKaigi がありました。

toyama-eng.connpass.com

私は、Java側のセッションを聞きました。

下にそれぞれのセッションの個人メモを貼ってますが、印象に残ったところとして、

  • JDKの有償ライセンスは思ったより安い?
  • 当たり前だけど、Kubernetesが向かないプロジェクトもある。
  • Kubernetesの要素って、なんであんなにジェネリックな名前なんだろ。。?
  • Loomはまだまだ?使えなさそうだけど、これが出て、ライブラリもアップデートされたら勝手に性能が上がりそう。
  • スレッドとかロックとか、知らない・覚えてないことがいっぱい。。。
  • GraalVMはいろいろヤバそう。(いい意味で)
  • RESTのゆるふわさをどうにかするために、ODataとかOpenAPIとかGraphQLが出てきたと考えれば、理解しやすい感じ。
  • ODataは初めて聞いたけど、表形式のデータを提供するためには、考えることが減らせそう?(APIパラメータとか)

って感じでした。

懇親会やその後の2次会、次の日の朝など、いつもは話せない人たちだったり、観測範囲の違う人たち(.NET側)と話せてよかったです。

Oracle Code One 2018 の概要 と JDKライセンスモデルの変更(最新版)

https://www.slideshare.net/itakashi/jdk-burikaigi-2019

Oracle Code One 2018

Java One から、 Code One になった。

JDK

JDK 11 ドキュメントの日本語版が公開。 (英語以外では、日本語のみ)

1/15のアップデートで、Java8の最終アップデート。 次からは、新しいライセンスになる?

去年、世界中でやったアンケートで、8割ぐらいJava 8。 LTSで行こうと思ってる人が3割ぐらい。 都度考えようと思ってる人も3割ぐらい。 Open JDKを使っていく人は8%。少なめ。

今までのリリース Open JDKのコミュニティが、コード公開までしてる。バイナリは作ってない。 JavaFXとかを追加して、Oracleがバイナリとして提供。BCL(企業内でのコピーなどはできる。)ライセンス。

いままでのアップデートリリース Oracleがアップデートリリースを開発。年4回。 セキュリティやバグフィックス、たまに機能追加もあった。 Open JDKのアップデートリリースは、同期されてなかった。

JDK11以降のリリース Open JDKがコードを作るのは変わりなし。 Oracle Open JDKとして、オラクルが無償提供。6ヶ月ごとに出てくる。(オラクルによるアップデートのリリース) Oracle JDKは有償。商用ライセンス or OTNLA for Oracle Java SE。バージョン固定のニーズに特化。開発・テスト・試作・デモ用途には無償。

Oracleでは、リポジトリが2つある。OpenJDKとOracle JDKOracle JDKの方は、11, 17などのタイミングで、ブランチが切られ、個別にアップデートされていく。

メジャーバージョンアップは3月と9月。 アップデートは1, 4, 7, 10月。

リリース情報は、今までどおりOpenJDKのサイトで確認できる。 Deprecatedになったら、最短1年で削除される可能性がある。Release Notesを確認する。 for removable = trueになったら、ほんとに1年で消える。

Java8の無償サポートは続くが、今のところはNon-corporateのみの制限になっている。 有償サポートであれば、25年3月まで伸ばせる。 Java6を使ってるのは、いいかげんまずい。 有償サポートの契約では、バージョンの固定が無い。8のサポートだけ欲しくても、11とかも利用できる。

1プロセッサで年間36,000円。 プロセッサの数え方は、チップベンダーなどにも依存する。

Oracle Code One 2018 Java関連のフィードバック

(スライドは見当たらず)

一昨年まではJava Oneだったので、Javaだけだった。 Oracle Code Oneになって、Java以外もある。(とはいえ、Javaがメイン)

セッションのスライドや動画は、公開されている。 ハンズオン資料も公開されている。

OracleJava関連のいろいろなものをオープン化していく。

Javaでコンテナやるってのは向いている。 管理ツールなども、いままでのものが使いやすい。 ただし、ランタイムが大きい。普通にやると、500Mのイメージとかになる。 Jigsawとかでうまくできると、100Mを切れる場合がある。 slimというイメージを使うと、ベースイメージの容量を減らせる。 Alpine linuxにポートするのがProject Portola。(12に入る?)

Java on Kubernetes 全部デモ

(スライド無し)

Podは、いくつかのコンテナをまとめたもの。

IstioというProxyサーバ?を置くことで、DI/AOP的にできる。

Podの冗長構成をするために、"Deployment"という仕組みがある。 アプリのローリングアップデートとかも仕組み化されている。 サービスの死活監視とかもしてくれる。(ちゃんと書けば)

Deploymentを管理するためには、yamlで書く必要がある。

kubectlで、コンテナに対してport forwardしたり、コマンドを実行できたり。 /bin/sh を実行させることで、ログインすることもできる。

Deploymentで管理されているものは、基本的にprivate IPしかふられていない。(外部からアクセスできない) "Service"(Load balancer的なもの)を定義することで、外部からアクセスできる。(ただし、基本的にはprivate ID) typeを変えることで、パブリックにできる。(ただし、あんまり使わない)

Ingressを経由するのが、正しい外部公開の仕方。

https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure から勉強するのがよい。3章が特に重要。

kubeは、万能ではない。 マイクロサービスとか、新機能をどんどん追加していくとかは向く。 長く安定的に動かす基幹システムとかは、あまり向かない。(学習コストの方が高くつく)

Project Loom - 軽量スレッドと限定継続

https://speakerdeck.com/skrb/project-loom-qing-liang-suretudotoxian-ding-ji-sok

Loom自体はまだ固まってない。

Thread 糸 Fiber 繊維 Loom 織機

並列・並行は難しい。そもそも、それぞれの単語が難しい。 スレッドセーフでもスケールしない。 CPUが遊んでる。使い切れない。ロックがとれないとか、IOのウェイトとか。 待ち状態になったら、スイッチするべき。

wait - notifyAllのペアで使う。 java.util.concurrent では、そのあたりをうまく実行してくれている。

Context switchは遅い・重い。中断するだけで、大量のメモリを必要とする。 ->OSによらず、JVMが管理するスレッドが必要 => Fiberの導入。

中断/再開の仕組み -> (限定)継続と言っていいのでは? Fiber = Continuation + Scheduling(ForkJoinPoolが使える)

java.lang.Continuation run / yield / Runnableでのタスク記述

計算処理だけであれば、Parallel streamとかを使えばいい。 IO待ちとかに、Fiberが使える。

java.lang.Fiber スレッドはそのままで、その上のタスクだけが切り替わる。 Runnable / Callableでタスク定義 schedule park / unpark(駐車するという意味)ただし、ユーザは使わない。 CompletableFutureに変換して、待ち合わせる。 たとえば、LockSupportがparkメソッドを利用している。 それ以外にも、Thread, java.util.concurrent, I/OのNetworkingやPipeが対応してる。(Fileは未実装)

制限 ネイティブスタック・モニタからはyeildできない wait/notifyAllではなく、ReentrantLockなどを利用したら使える。

Fiberは、おおよそThreadの代わりになる。 ThreadLocalやThread.currentThreadが使えない。

LinuxMacはサポートされてるけど、Windowsがまだ。

おれの書いたPHPがこんなに速いわけがない(PHP7.3比3倍)

(資料見当たらず)

GraalVM : Oracleが開発してるJVMをベースにした多言語環境 CE版と商用EEがある。(本番で使う段階ではなさそう。。?)

Graal と GraalVMは別物。

Graal Javaで書かれたJITコンパイラ 現状Client(C1)とServer(C2)があるが、C2部分を置き換えるもの。 C2は秘伝のタレ化(新機能の追加を出来る人がいない)してるので、それを置き換えたい。

Truffle AST処理エンジン 動的言語のためのLLVMと言える。

Sulong LLVM bitcode -> Truffle ASTに変換出来る SwiftはLLVMが改造されてる?ので動かない。

Polyglot Truffleをベースにした多言語環境 言語をまたがった最適化が可能。

Microsoft AzureではじめるJava開発

https://slides.com/hiroyuki_onaka/java-on-azure-burikaigi/#/

Azure x Javaの選択肢 AKS / Virtual Machines / App Service / Functions(まだプレビュー)

今回はApp Serviceの話。

warが動く。wildflyも動く。

App Serviceにも、WindowsLinux、コンテナのバリエーションがある。

特に理由がなければWindowsでいいが、最新のもの使いたければContainer。 windowsならfreeプランで試すことも出来る。

Java クライント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)

https://www.slideshare.net/sugimomoto/java-api-rest-vs-graphql-vs-odata-vs-openapi-swagger

API management市場が2022年で3000億円規模になる予想。 (Apigeeとか。)

APIエコシステム」が重要性を増していく。 freeとかmoneyforwardがAPI提供したり。 提供者側の文脈が多いけど、利用者が必要。

RESTは原則が定義されているだけで、規約などは無い。 デシリアライズ先のクラス定義が面倒。 リクエストのパラメータなどは、ドキュメントを見る必要がある。

Swagger (OpenAPI) RESTをうまく記述するためのフレーム。 (主に)yamlで記述する。 Codeの生成や、モックの作成が出来る。

OData RESTの上にプロトコルを乗せたイメージ。 表形式のデータの取扱をしやすくした。(SQLのイメージに近い) 使えるURLパラメータが全て決まっている。 Metadata Endpointサポート。 サービスごとにAPIの仕様を学ぶ必要が無い(統一されている)

GraphQL Web API用のクエリ言語 1つの画面で複数のリソースの情報を表示する必要があるので、画面側でリクエストしたい情報を組み立てる必要が出てきた。

Toyama.rb #30 オフラインリアルタイムどう書く に参加しました

toyamarb.connpass.com

毎月恒例Toyama.rbに参加してきましたが、今回はいつもの「もくもく会」ではなく、「オフラインリアルタイムどう書く」でした。

やる前は、「制限時間付きの実装、何かのプロダクトになるわけじゃない実装、とかってあんまり好きじゃないんだよなー」とか実は思ってましたが、やってみたら想像以上に良かったです。

前日

Toyama.rbというRubyのコミュニティですが、利用する言語はRubyに限らないということだったので、直近で仕事で必要そうだけど実力が追いついてないSwiftでやろうと思いました。 また、ググって出てきたどう書くの問題を眺めて、「文字列を受け取って、文字列を出力、それが提示されている値と一致しているか」というフォーマットっぽかったので、assertのやり方を調べたり、いくつかのループのやりかた(Rangeを使ったり、forEachを使ったり)を調べておきました。

1問目

1問目は「フォークじゃない」 http://nabetani.sakura.ne.jp/hena/ord18notfork/ でした。 並んでいる状態をどうやって保持するか、"x"のお客をどうやって管理するか、といった部分で実装方法が別れていた印象です。

私は、実装速度・コードの簡潔さよりコードの読みやすさを優先して、ある程度オブジェクト指向的に書いていきました。 StoreクラスにRegiStateが5個あり、RegiStateにCustomer enumの配列を持ち、Customer enumでは normal | stop("x"の人)を表現しました。

1時間の制限時間だったのですが、「どのレジに並ばせるのか」の部分がうまく行かず、すべての人が最初のレジに並んでしまったまま制限時間を迎えてしまいました。 その当時の実装状況としては、 https://github.com/noboru-i/toyamarb30/blob/687815b5784bea04bb1fe0a41b7bcc3b67700500/ord18notfork.playground/Contents.swift です。

次の日、ちょっと修正したら、すべてのテストがパスしました。やっぱり、落ち着いて考えることは必要ですねー。。。

時間内に解けたのはkunitooさん1人だけで、Rubyで実装していました。 https://gist.github.com/kunitoo/624fcc785385c76168f6f1005183b954 min_by などを利用して、かなりスッキリしたコードで実装されている印象です。

みなさん、RubyJavaScriptC++Pythonなど、いろいろな言語で解いていました。 解く順番も、私みたいにオブジェクトの状態・操作を考えて一気に実装した人もいれば、TDD的に各メソッドの入出力をテスト書きながら進めた人、たくさんあるテストデータの中から簡単そうなものが通る実装を書きそれを育てていく、などいろんな人がいました。

2問目

2問目は「積み木の水槽」 http://nabetani.sakura.ne.jp/hena/ord13blocktup/ でした。 これもいくつかやり方があったようで、「下の段から走査していって、水が入る可能性のあるブロックを特定する」というものや、「列単位に、その左右の堰となるブロックの高さを求める」などがありました。

私は前者で、マス目を2次元配列と考え、マス目の状態を block | water | fall(0の列+そこに水が流れていってしまうマス) | undefined(まだ確定できていないマス) に分類し、undefinedで埋まっている状態から順に確定していくイメージで進めました。 手順としては、 ・入力文字列から block の位置を確定していく ・0の列を fall として、そこに水が落ちていくマス目も fall としていく ・まだ undefined の箇所について、隣接するマス目を確認しながら water を確定していく と考えました。 実装状況としては、 https://github.com/noboru-i/toyamarb30/blob/928b2f6fd4ee1d417350c0860d4b758e128a0c5f/ord13blocktup.playground/Contents.swift です。 問題の理解と考え方をまとめるのに時間がかかり、実装面でも2次元配列の扱い(どっちがx座標?など)に戸惑ってしまい、やはり1時間では解けませんでした。。。

ただ、mugi_unoさんの説明を聞いていると、3つ目の手順で undefined になっている部分は、すでに waterで確定っぽいですね。

これも制限時間内に1人だけ解け、しかも解いたのは学生、社会人は誰も解けずというちょっと不甲斐ない結果となりました。

これも次の日に修正しようと思ったのですが、列単位で水の量を計算できるというのを知ってしまったあとだと、今のやり方を進める気が起きず、とはいっても別のやり方を新規にやる気にもなれず。。。 やっぱり、オフラインで集まってやるからやる気になるんだなーと思いました。

感想など

実装・確認はXcodeのPlaygroundで実装を進めました。 リアルタイムで実行してくれるのは便利だったのですが、書きかけの状態でも動作してしまうためコンパイルエラーがじゃんじゃん表示されたり、Xcodeが急にクラッシュしたり、書き換えても実行結果が更新されなかったり、まだうまく使いこなすことができませんでした。。

個人的には、もうちょっと時間を使って、読みやすいコードにするとか、言語機能やライブラリをフルに使って短いコードで書くとかをやるのも面白いかなーと思いました。 (個人的に、時間に追われるのが苦手、というのが大きいですが。。。)

1時間やって、全員分の説明・レビューする流れは良かったです。 今までもくもく会で何をやっているかは知っていましたが、みんなが同じ時間に同じ問題を解くことで、それぞれがどういった考え方で実装を進めていくか、どんな言語をどの程度かけるのか、といったことがなんとなーく知れたのはよかったです。(特殊なケースではあるので、実際の仕事能力とは別の次元だとは思いますが)

個人的には「もくもく会」が好きなので、Toyama.rbはそれがベースだとうれしいなーと思いますが、定期的にこういったイベントがあるのはやっぱり楽しいですね。

新しい技術を取り入れるための実験のやり方 〜サーバーレス・機械学習・PWAを実戦に投入するまで〜 に参加しました

火曜日の夜、イベントに参加しました。

guildworks.doorkeeper.jp

と言っても、富山に住んでるので現地に行けるわけもないんですが、Zoomでの参加が可能だったので登録してみました。

久しぶりの平日夜の勉強会でした。

内容としては、ギルドワークスが1ヶ月4名ぐらいで、いろんな新規技術を詰め込んだ自社プロダクトWebアプリを作成、そのときの知見共有、といった感じ。

個人的には、「受託の実案件にどうやって新技術を突っ込むか」を聞きたかったのですが、話を解釈すると「実案件にいきなり突っ込むのは難しいから、先に小さめのアプリで一度やる」なのかなーと感じました。

個別の技術の話は、下のメモに書いたとおり。知ってること半分、知らなかった・再認識した話半分、という感じ。

運営に関しては、珍しいZoomでの配信ということでしたが、概ね良かったと思います。(上から目線。。。 マイクオンのまま入ってくる参加者がおり、最初だけはホスト側の対応が遅かった気がしますが、それ以降は快適に聞けました。 (弊社の全体会議も、これぐらい上手く進めばいいんですが。。。)

欲を言えば、スライド以外に会場の様子・スピーカーを映したカメラもあったら良かったかも?と思いました。

あと、ハッシュタグも決めてもらったほうが、Twitter上で盛り上がってよかったのでは?と思いました。 (Zoom配信に結構な人数いたので、そこも含めた一体感も出やすいかなーと。)

地方在住者はなかなか勉強会に参加できないので、こういったリアルタイムの配信が増えてくるといいなーと思います。(設備とか大変だろうけど。。 最近はYoutubeとかでアーカイブ配信も多いですが、「いつでも見れる」状態ってなかなか見ないんですよね。。。 そういった意味でも、リアルタイムで他の人も聞いている、という状況がいいなーと思います。

以下、メモ。

リスク
技術のリリーススケジュールに、デリバリーが引っ張られる。

漸進的な改善と根本的な転換
取り入れやすさを取るか、大きなリスクを取るか

ギルドワークスでは
GraphQLを一部利用、SPAを部分的に利用などしている。
React Nativeを全面採用しようとしたが、速度が出なかった。

やりたいこと=根本的な転換を、低リスクで実行
新規自社プロダクトのMVP開発を対象にする。

AWS Elastic Beanstalkを使ってる。
Spring/Spring security, Rails/deviseを使っている。

課題
ボイラープレートコードが多い。(データのCRUD/認証など。微妙に違う。)
フロント開発が3ターゲット分必要。

今回の挑戦
SaaSで外部に出す。Cognitoの利用。
大きなフレームワークから、Lambdaへ。
PWA(Ionic)

Lambdaを利用しようと思うと、SPA->API Gatewayや、DynamiDBが必要になってくる。

## Lambda + Java

LambdaでJavaを使う理由
言語として利用したことがある。リスク低減。
Lambdaでのサポートしては歴史が長い。安心感。

課題
DynamoDBの利用。RDBのように扱う。
AWSのデプロイなどは、AWS Toolkit for Eclipseを利用。とっつきやすかった。

DynamoDBの利用
DynamoDBMapperが標準である。入れ子のデータ構造などもサポートしてる。
JPAなどと同じように使える。

デプロイ
AWS SAM形式のテンプレートから、Eclipseでデプロイする。
BluePrintがいくつか用意されていて、ウィザードもある。
AWS Toolkit for Eclipseは、GUIでとっつきやすい。コマンドでの再現も出来る。

認証
Cognitoでクライアント認証。
API Gatewayでヘッダを見て弾く。
Java側では、認証チェックなどは行わない。

ステージング環境の構築
DynamoDBの扱いがアノテーションベースだったので、テーブル名の付替えが難しい。
別リージョンでステージング環境を構築した。ベストではないけど、ちゃんと動く。

Java+Lambdaの問題
起動が遅い。出来るだけコンパクトにしても10秒などかかる。
ポーリング?ローディングのタイミングを工夫?ユーザからのAPIはJavaを避ける?
Goで再実装中。

純粋なJavaになるので、テストコードは書きやすそう。ただ、今回はDynamoDBとのIn-Outだけなので書いていない。

1週間スプリントのスクラムで実施。大きな問題があれば、検知が出来たはず。(今回は、特に出なかった)

## Ionic

Angularをベースに、UIコンポーネントが充実。
cordobaと連携することで、アプリ化も出来る。
ドキュメントが丁寧。(インタラクティブなドキュメント)
CLIのサポートが充実。(Angularを踏襲)

標準テンプレートで作成すると、Service Worker設定済み。
ファイルキャッシュ、APIのキャッシュが簡単に設定できる。

Ionicを使う上でのポイント
CLIを出来るだけ使う。構成を保って、generateが出来る。
TypeScriptの型定義を利用する。ミスを防ぐ。

Ionic標準から外れるUIの作成は高コスト。
標準で使うのが良い。作る場合も、Web技術で作ってしまうほうが楽。Angularの資産も使える。

クライアントでのCognito認証
AWS Amplifyを利用することで、認証コードの作成が楽になる。

## 機械学習

導入の難しさ
データセット足りない。最低でも1k程度のデータが必要。
技術的ハードルの高さ。数式などが必要。

今回のスタンス
データセットが集まっている分野に絞る。Googleなどが学習済みのものなど。
画像認識・言語分析・音声認識
技術的ハードルについては、SaaSをフル活用する。

Google Natural Language APIを利用。日本語に強い。

都度実行すると高いので、バッチで叩いたほうが安い。

## トライしたこと

4人で1ヶ月。そこまで大きくない。
やったことないことを詰め込んでやっている。
リリース前提なので、実際のプロジェクトに向けた知見を得られた。

次の実験に向けて
MBaaSにチャレンジ。Google FireStore / AWS AppSync。
Ionicの他に、React/Vue.js や ReactNative/Nuxt。
機械学習もSaaSからPaaSへ。AWS SageMaker。

方針決定は、オフラインで集まってやった。2,3時間。
受託だったら、今回ほど大規模に新しいことはやらなかっただろう。ただ、今回の知見があるので、次以降で一部導入などは出来そう。
今回の開発で懸念も出てきたので、次の自社プロダクトで別の方針を試す。
Cognitoはかなり使えた。DynamoDBも、特定用途に限れば、かなり使える。積極的に使っていきたい。

Essential Phoneを買ったはなし

Android P がすごいらしい

というのを聞き、 下記サイトから使える端末を探しました。

Android P Beta Devices  |  Android Developers

Pixel たちは技適の問題があるし、 Sony Xperia XZ2 はまだ発売日が発表されていませんでした。

Essential Phone も良さそうだなーと思って調べたら、数週間前に日本への発送に対応したとのこと。 セールは逃しましたが、発表時よりも値段も下がっており、素の Android に近いとの話も見かけたので、買ってみることに。

探してみると、 Amazon でも並行輸入品が出品されてました。

ただ、"並行輸入品" ってのが微妙に怖かったのと、値段を見ると微妙に公式サイトの方が安かったので、 https://shop.essential.com/products/phone?variant=34714129089 の公式サイトから購入することにしました。 (このとき、送料のことを甘く見てました。。。)

で、色なんですが、誰かとかぶりたくないこともあり、 Stellar Gray にしました。この時点で +$100 です。

360 Camera も悩みましたが、買った当初は良いけど、すぐに使わなくなりそうなのに $199 するのは高いと思い、見送りました。

購入

結局買うのは本体だけになったので、 $599 と送料だから、7万ぐらいで収まるだろうと思ったら、送料は $79.33 とのこと。

https://pbs.twimg.com/media/Dc2PRUDV4AA-mUd.jpg:large

合計は $678.33 になり、最終的に引き落とされたのは ¥75,535 でした。。。

5/10 25:00 に購入しました。

受取まで

その朝6時ぐらいには tracking number が発行され、FedEx のサイトを見ると、5/14 18:00予定になってました。

土日挟んだので、体感的には長かったですね。。。

実際には 5/14 17:30 ぐらいに届いたので、3日と16.5時間で SAN JOSE から Toyama に着くんですね。

開けて使ってみた

かっこいい箱に、かっこいい充電器とともに入ってました。

Stellar Gray は背面がマットな質感で、あんまり指紋も目立たなくていい感じです。


Essential Phone Stellar Grayの外観

とりあえず、初期状態のアプリ一覧。

本当に素の Android という感じ。 キャリアのアプリも、端末メーカーのアプリも入ってなかったら、こんなにすっきりしてるんですね。

買った当初は 7.1.1 がインストールされていました。

そのまま、 8.1.0 が降ってきたのでインストール。

あんまり使うこともなく、Android P developer Preview を下記を参考にしながらインストール。

Essential Phone PH-1にAndroid P Betaをインストールする手順 Developer Overview

こんな感じに、 Android P になりました。

f:id:suzaku114:20180516230459p:plain

Android P の操作感

※前に使っていた HUAWEI P10 lite (WAS-LX2J) は Android 7.0 だったので、8系で変わった部分もあるかもしれません。。

ホームボタン周り

まずは大きく変わったホームボタン周り。

(実際の操作感は、 Youtube などで動画を見てもらったほうがわかりやすいかと。)

ホームボタンを右にスワイプしていくと、起動中の画面がスライドしていきます。

また、ホームボタンを上に少しスライドさせると、 Recent Task の一覧が表示されます。 さらに上にスライドさせると、アプリドロワーが表示されます。 単純に長押しすると、以前と同様に Google Assistant が起動します。

Recent Task を表示させるさじ加減が難しく、Google Assistant が起動したり、ドロワーが表示されたりします。。。

画面回転

他に気がついた機能としては、画面回転の機能。 基本的に回転を固定して使っているのですが、寝転がって使っていると、ホームボタンの右側にボタンが表示されました。

これを押してみると画面が回転されました。

画面が回転された状態で、スマホを縦にすると再度ボタンが現れ、元に戻すことも出来ました。

画面回転がかなり使いやすくなった印象です。

古いバージョンのアプリ?

https://pbs.twimg.com/media/DdKkJO5V0AIte5X.jpg:large

targetSdkVersion が古いものとかが出てるんですかね?

私の作った 共円チェッカー でも出てました。。。

display cutout

いわゆる「ノッチ」ですね。

これがあるせいで、一部のアプリは app bar がめり込んで、タップエリアが少なくなってしまっていました。

例えば、 bitFlyer アプリはこんな感じ。

f:id:suzaku114:20180516232722p:plain

動かないアプリ?

意図的なのか、意図的じゃないのかわかりませんが、いくつかのアプリは動きませんでした。

まず、 BOOK WALKER アプリは、OSバージョンを見ているようで、エラー画面(ブラウザ)に飛ばされました。。

楽天銀行アプリは、ログインの途中でワンタイムキーを入れるところでエラーになり、先に進めませんでした。。。

楽天カードアプリは、ログインしようとしたところで「予期せぬエラーが発生しました。」というエラーでログインできませんでした。。。。

nasneに貯めた番組を見るために使っている ソニーの Video & TV SideView は、機器登録の直後や、アプリ起動して数秒後に何も言わずにアプリが終了してしまいました。。。。。

こんな感じで、まだ動かないアプリが結構ありそうです。 Developer Previewだからなのか、アプリ側で変わったことをやっていて問題があるのか、とりあえず正式リリースまではこのままですかね。。

カメラ

あんまり使わないのですが、始めての二眼カメラなので、ポートレートモードで撮ってみました。

背景がおもしろいほどボケました。

細かいことはわかりませんが、それなりの写真が撮れていると思います。

今のところ、「起動が遅い」みたいなこともあまり感じていないです。

その他、使用感

前に使っていたのが、 HUAWEI P10 lite というミドルスペック端末だったこともあり、動作はかなりスムーズになった気がします。

ただ、画面が大きくなったせいもあるのか、文字のフリック入力で思ったように入力できない場面が多くなりました。このへんも、たぶん慣れですね。

まとめ

素に近い Android で、 Developer Preview 状態の Android P を触れたのは良かったです。

Developer Preview ということで(?)動かないアプリも幾つかあったり、慣れないと難しい操作感だったりしますが、付き合っていこうと思います。

ちなみに、

さっそくスマホリングを貼りました。

内側がシリコンになっており、指が痛くなりづらいかなーと思って買いましたが、結構固め。

また、回転もけっこう固め。

ただ、貼ったばっかりなので様子を見ようと思います。

5/30追記

購入して1, 2週間後、FedExから封筒が送られてきました。 税金などで追加で3,500円を払え、という内容で、コンビニ決済用と銀行振込用の用紙がついていました。

結果、Essential Phoneを買うためにかかったお金は、¥79,035 となりました。。。

kanazawa.rb meetup #68 に行ってきた

kzrb.doorkeeper.jp

自分の発表

今回はLT大会ということで、私も発表しました。

gitpitch.com

GitPitchを初めて使いましたが、便利ですね。今後は使っていこうと思います。

(Pro版じゃないので、確認しようと思ったらpushしないといけないんですが。。)

ISSUE_TEMPLATEの利用、Gatsbyを使ってPWAを構築ってのを共有できて良かったです。

他の人達の発表

色んな人のリアルな作業環境が見れてよかったです。 とくに、ディスプレイの配置とかは悩んでるので、ちょうどよかったです。

また、知らなかった話も多く、 "Web to macOS native app"で紹介されてたネイティブアプリ化はちょっと試してみようと思いました。

以下、聞いてたときのメモ。

MAC TIPS

Brewfileをチームで共有してる JSON XML Parser ユーザ辞書に開発用語の登録 スクリーンキャプチャを、defaults writeで置き場を変えている 熱対策に割り箸

Raspberry Piのインストールイメージ改変

WiFiの接続設定とか、シリアルコンソールの設定とかが面倒 Raspberry PiのカスタムをRaspberry Piでやる mountしたら書き換えられる。 書き換え終わったら umount する。 イメージの名前をリネームしておく。 それをddしたら、その変更したものが動く。

オレチョコ!!

カカオ・ポリフェノール、香り、テオブロミンなどの効能 チョコ摂取により、イライラから正常化 間食は200kcal/日が適量

VLOG環境

過去12ヶ月で4000時間かつ1000人登録が必要 大雪のときに毎日投稿してた。そのときに伸びた。 SONYの新しいカメラ紹介でも増えた。 黒い服を着る(動きやすい) 筋肉大事

(開発)環境紹介

横浜と比べて、面積広がって家賃が安くなった。 エアロバイクに乗りながらスマホゲームしたり。運動不足解消。 モニタ2台で1つ縦置き。 ケーブルを使わないときは、壁にかけてる

俺とディスプレイ

道具も含めて実力 同じディスプレイでも色が違う。ロットを合わせるしかない。 上下・左右で視野角が違うので、回転するときは注意 結論:大きいディスプレイの中央を使い、左右は通知などを表示

デスク周り晒し2018春

リープチェアV2:正規の価格だと17万 ディスプレイ:32インチ FILCOウッドパームレスト FIFINE USBマイク:マイク自体に音量調節つまみがあるので、ミュートも出来る コクヨ キャンパスノートパッドB5:方眼になってる

Raspberry PiBluetoothでシリアルコンソール

通常、HDMIディスプレイ+USBキーボード もしくは、SSHしてつなぐ。ただしIPがわからなかったり。 もしくは、TTLシリアルケーブル。これもケーブルがめんどい。 Bluetoothが無線でよい。 bluetoothd 起動後、 spdtool で SP も追加する。 ペアリング成功すると、PC側にシリアルが生える ディスカバーするのだけは、別の手段で入らないといけない。 Aliasを設定しておかないと、同じ名前のBluetoothバイスになってしまう。

俺とキーボード

洋ゲーやプログラム言語は、英字キーボードを想定されてる。

44歳ノンプログラマの開発環境

ウェブディレクタ。ExcelとかXD、Wordとか。 Googleカレンダーに落ち着く。TODO Listとか。 左手でトラックボール。Kensington。肩こりは治らない。 健康が一番重要。筋トレ+有酸素運動。 筋トレは、ネット上のコミュニティに入ったりしてモチベーション管理。

俺と通知

AppleWatchを買いたくなる、というのがゴール 仕事・私生活・タスクなどで分類出来る。 即対応が必要か。儲かる・重要な相手からの通知。 集中してるときは通知しないでほしい。超重要なものは通知してほしい。 おやすみモードを活用。watchで受ける。 通知をそのままタスクリストとして使いたい。 iPhoneに集約させる。通知がほしければアプリをインストール。不要ならメール。 メールはGmailに統合。 エイリアス機能でサービスごとに分ける。 メールのフィルタで重要度を設定し、watchを鳴らす。

最近の開発環境

庭のベンチとか。 一人用テント・タープとか。 スノーピークは国産。ちょっと高い。 キャンプ用品の出し入れをサービス化してたり。 テント乾燥サービスとか。 シュラフのクリーニングとか。

Web to macOS native app

Webサイトをmacのネイティブアプリ化。 PWAではない。 すばやくフォーカスチェンジしたい。Alfredとか。 複数アカウントを切り替えたい。 ブラウザマニア:それぞれ専用のブラウザとして使ってしまう。 特別な知識は不要。ただ、リソースを多く使う。 nativefier:npmでインストールして利用する。 ChromeベースでElectronで動く。ただ、メモリも結構つかう。 Fluid:macOS用のGUIアプリ Safariベース。スクリプトなど、機能が豊富。比較的リソースが少ない。

頑張らないzsh環境

環境作るのがめんどい。 「じーしぇる」 高機能・多機能なシェル。全容の把握が難しい。 oh-my-zsh:設定を管理するフレームワーク デフォルトで、gitコマンドの補完設定が設定済み。description的なものも出る。 テーマを変えることで、git上のstagedなファイルなどが見える。

開発環境改善活動2018

スキルアップ兼ねて、ツールを開発したりしている。 1:GitHubのレビューワークフローを改善 マージまでに時間がかかる。 交通整理役がほしい。プルリくん。 Lambdaで構築したSlack Bot。DMで通知。オートアサイン。 マージ数が1.3倍。 ユニットテストカバレッジをサクッと見たい。 機能を追加する際には、テストが必要。 エディタの中で見たい。Coverage Markers。Atom拡張機能

開発環境自慢

デバイスドライバ開発。RTOS用とか、ファームウェア開発。 Tera TermはWindows95から対応。 Visual Studio2015で作ったバイナリはVistaで動かなかったりする。

私のWorkstation環境遍歴

80年代後半、SUN-3でLatexでの文章作成から。 グループの共有マシンにログインし、先輩のdotfileを参考にカスタマイズ。 次に、使うマシンが指定され、default主義に。 機械学習などで、ゲーミングPC 今は、PCが多いので、最小限のカスタマイズ。