【勉強会メモ】2018/7/10 JP_Stripes＠エックスサーバー大阪本社
オンライン決済のStripeに前から興味があったので
大阪でのミートアップに行って話を聞いてきました。
端々で折に触れて導入の手軽さが話に挙がっていましたが
事前に軽くAWS Lambda＋API Gateway＋S3（htmlファイル）の構成で試してみたら
Stripeのコーディングの部分は5分で終わったので
（AWS側の設定間違えてて余計な時間を食った…）
確かにお手軽に決済機能を実装できるようになったなあ、と感心することしきりです。
以下、内容メモ。
あくまで自分用にとったもの&自分が思ったことなので
講演者の方の意図とは違う場合（または単純な間違い）がある可能性があります。ご了承ください。
■JP_Stripeキックオフ&Stripeアップデート
Stripeとは…
ワンストップ&APIでオンライン決済を実現
カード不正利用対策がビルトインされている
他サービス…書面が大変、固定費がかかるなど
クレジットカード会社に審査される必要がある
店のコンディションによって料率がかかる
新しいサービスである（＝モダンなビジネスの課金形態に対応している）
→サブスクリプション対応（返金対応も標準対応）
多通貨決済対応
プランの途中変更標準対応
特定月だけのクーポン標準対応 など
キャッシュフローに効く…翌週入金可能
カード情報非保持、非通過を実現
事例…クレカ対応自販機「６００」
（実は対面決済にも応用可能）
決済サービス
・PAYMENT…従来のモデル
・BILLING…サブスクリプション用も出る
・CONNECT…C2C用モデル
管理系サービス
・ATLAS…日本から海外の法人登記ができるしくみ
・RADAR…不正対策のためのツール（Stripe全体のデータで機械学習）
アップデート…
・BILLINGのプランがより柔軟に 詳しくは…WP-kyoto
全て、最大3.6％の料率で対応
VISA、MASTERCARD、ALIPay、WeChatPay、ApplePay、GooglePay
■事例セッション StripeでJCBやってみた
どこから申し込む？
→サポートの問い合わせベース（7/8現在)
注意点ほか
・導入するサイトには特定商取引法に基づく表記が必要
・ダッシュボードにログインしてからやると楽
・審査に3週間～かかるので早めに
・connectのCustomでは利用不可（7/8時点）
・実装面での変更は特にない（第三者ライブラリは別、StripeSDKは大丈夫）
・入金は支払日から30日かかる（他は4営業日）
・正式リリースでは4営業日をめざすとのこと
・日本アカウントでは、日本円のみ
・個人事業主の場合、代表者名と銀行口座名を同一に
■事例 マーケティング視点から決済サービスについて考えてみた
マーケ的考え
１ 環境分析、全体把握
２ 顧客層の違いでグルーピング、顧客絞り込み、優位性を考える
３ 戦略を踏まえて、施策の戦略立案（製品、価格、チャネル）
４ 実装
決め手・クロージング→重要
ゴールされないと辛い（最終段階での離脱防止）
ユーザにどんな体験を与えるかが大事
Stripeはその手間が不要
■事例セッション デザイナーがSubstriptionの設定を頑張ってみた話
WordPressを使った会員制サイトの開発
要件：
・多言語対応
・ランクによってサービスを変える
・月額性、ドル建てクレジット払い
・支払日を指定したい。日割り計算もしたい。
申し込み月は無料、
・プランを変更すると途中で日割り計算
とりあえず触ってみる
→アカウント作成とテストアカウントはすぐできる
Substriptionは？
→ドキュメントを読む→英語……
→プラグインを探す→要件に適合するものがない
→自分でつくることに
ランクによってサービス内容が異なる→それぞれランクのボタンを設置して支払い
支払日を指定したい→管理画面からではなくボタンを押すと顧客登録&支払日を自動設定
プランの作成→管理画面から設定
顧客の支払い→サイト内で対応
つまずいたところ
SDKをインストールしていなかった
まとめ
非エンジニアでもStripeは使える
・ユーザ数が多いので情報が多い
・サポートが丁寧（丁寧なメール、Twitterのつぶやきへの反応
・管理画面がわかりやすい
Site Reliability Engineering勉強会メモ
先週の木曜日にヒカラボ主催の
Site Reliability Engineeringの勉強会に参加してきました。
それなりに感じることもあったため、
内容をまとめて書こうと思っていたのですが
日々の雑事に流されてそのままになってしまいそうなので
まずは当日とったメモと雑感だけでもアップします。
おおむね、SRE本の内容紹介が主な内容でした。
（講演してくださったのが日本語版の訳者の方だったので）
話を聞いて特に強く残った点は
・個人の技量よりもチームとしての仕組みづくりの重要性
・「無駄な作業」というものをいかに言葉で定義するか（SREでいうところのトイル）
・最初から完璧なものはできない（Tryal and errorの精神）
といったあたり。
これらを日々の業務に生かしていければと思います。
以下当日とったメモ
■The SRE Book
海外ではSREの原点、バイブルと言われている
日本語版ではサブタイトルを変更
技術論より組織論の方が面白いため、日本人の先入観を考慮
エンジニア”チーム”の話
（技術の蓄積もあるが）組織としての考え方が果たしている役割が大きい
■SREが日本でも続々
メルカリ、スマートニュース、サイボウズ
特に運用系の仕事に関して日本でも広がってきている
■（余談）SREの皆さんの仕事っぷり
GoogleDocsのヘビーな話
必要なドキュメントを非常に手早く、しかも適切な集計・自動化を施して作成
いわゆるOffice系ツールの活用能力もとても大事
ちなみに最終の構成はdropboxでした・・・（PDF共同編集機能がある）
■（余談）三人称単数のThey
Theyが単数形として使われているケースがある
Gender Neutralな表現として、性別を持たない「人」をあらわす代名詞としてTheyが使われる世になっているとのこと
（シリコンバレーでは特に人事評価などに関わるドキュメントでは予断を挟まないために性別不明にする流れ）
■Site Reliability Engineerとは?
SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるもの
ソフトウェアエンジニアリングの発想で運用する
基本的には運用サイド（DevOpsのOps）の職種
スキルとして、インフラに加えてプログラミングが必須
・Googleの開発職に要求されるプログラミングスキルの８～９割が必要
仕事は大きく分けて運用業務（オンコールなど））と「改善」のエンジニアリング
サービスごとに担当はあるものの、SRE自体は全社横断的な組織
Googleのインフラストラクチャの上に乗る（開発とのインターフェース）
■SREの原則
・信頼性にフォーカスを置く
・ソフトウェアエンジニアリングによって運用を自動化、スケールできるように
・手作業→自動化→自律化（トラブルがあったときにシステムが判断して対応する）
・SREチームの規模はサービスの規模に比例してはならない（複雑さには影響を受ける）
・「トイル」（手作業でやっているつまらない仕事）の撲滅
・英雄的な献身に頼るのではなく、組織としての仕組みづくりを重視する
■トイルってなんだ（苦役）
・プロダクションサービスを動作させることに関係する作業で
・手作業で繰り返しが行われ
・自動化することが可能であり
・戦術的で長期的な価値を持たず
・作業量がサービスの成長に比例する
といった傾向を持つもの
■トイルの撲滅
たとえばサーバーの稼働状況のモニタリング
・メトリクスの生成、収集、集計といったことは徹底して自動化する
・その自動化のための「開発」作業は（50％ルールに守られて）積極的に行う
・Googleの場合、サーバーにはすべて
最初から完成度の高い仕組みを作ったりはできない。
自動化のメリットは「複利」
自動化してトイルを減らせば空いた時間でさらに別のトイルを減らせる
■速度と信頼性、そしてデータに基づく業務判断
会議室にいる一番給料の多い人の意見に従ってはいけない
ここでの「速度」は新しい機能やペースを投入するペースのこと
信頼性は主にSLO（Service Level Objective)のこと
開発者は速度を、運用者は信頼性を重視する傾向がある
新機能をリリースしたい 対 動いているものは変更したくない
計測されたデータに基づく業務判断
・エラーバジェット
・50％ルール
（あくまでGoogleの例。肝心なのは
・品質を示すデータの定義
・定義されたデータの計測
■SLI/SLO/SLA
SLI（サービスレベル指標 計測するデータの定義
SLO（サービスレベル目標 SLIに対して設定された社内的な目標値
（守れなかった場合に金銭のやり取りが発生）
SLOとエラーバジェット
エラーバジェット＝１－SLO（googleの場合は四半期でデータを計測）
エラーバジェットが残っている限り新機能をリリースできる（業務判断）
エラーバジェットが無くなった場合、リセットがかかるまで新機能のリリースは禁止
データに基づいて業務判断を行うことをルール化することで、
開発チームとSREチームが同じ方向を向いて業務に当たれるようにする
■１００％は目指さない
この場合、0.009％のためのコストは無駄
サービスの性格に応じたSLOの定義が非常に重要（Ex：ゲームとビジネス用途と人命にかかわる用途）
■50％ルール
SREはその作業時間の50％以上をエンジニアリング業務にあてないといけない
SREが運用業務にあてる時間が50％を超えた場合、開発チームがSREの支援に時間を充てる
■SRE book内の技術の話
「魔法」の話はSRE bookにはあまり出てこない
Googleのインフラがなくてもできる内容
ソフトウェアでコントロールできる範囲の話であれば学べることはたくさんある
ただし統計的な話が多いのが特徴的
→規模が大きくなると障害も統計確率的に扱わざるを得ない
モニタリングの話→書籍『Practical Monitoring』が面白い（未訳）
■計測と改善の仕組みづくり
・必要なメトリクスを得るための仕組みをインフラに作りこむ
・収集したメトリクスをモニタリングするための仕組みを作りこむ
・pythonが使えればマネできることはある
■SREの採用は大変
開発エンジニアのスキルの80％～90％、加えてインフラ知識が必要
基本的に需要に対して供給不足
Googleの場合、SREという「人」ではなくSREのノウハウを詰め込んだライブラリを使ってもらうという考えにシフト中？
■教育とオンコール
・オンコール対応になることはキャリアの１つのマイルストーン
・そこに至るまでの教育システムもきちんと整備する
「先人の谷に突き落とす」真似はしない
まずは過去のドキュメントやポストモーテム（トラブル報告書）の見直し
そしてベテランオンコールの「シャドウ」
その後オンコールとして独り立ち
■障害対応とトレーニング
・年一度、全社的な障害対応のトレーニング
・「たまにしかやらないことは身につかない」ことを受け入れる
・障害対応時の手順を日常業務に組み込んでおく
・できないことを精神論でかたづけない
・「ヒーロー」に依存しない
Ex：ネットフリックスのケイオスモンキー
→常に障害対応をしていればどんな障害にも対応できる、という理屈
■人事評価はどうやっているのか？（SRE Bookに出てこない）
■まとめ
SREの考え方は、技術的にはボトムアップで取り入れられることがたくさんある
ただし組織論的にはある程度トップダウンでないと導入しにくいところもある
RPAことはじめ ーUiPath情報まとめー
会社でRPAを（たった一人で）１から何とかして
モノにする必要に迫られたのでまずは調査中。
以下に自分用メモとして参照する情報をまとめていきます。
（新しいものが見つかったら更新するかも）
公式
UiPath公式ホームページ（日本語）
すべての基本。
UiPath Academy（要登録）
公式の学習コース。動画付き。
UiPath Studio Guide
公式のドキュメント。
公式以外
Qiitaより
Webから取得した情報をcsv化する実例。
Blog、HomePage
uipathメモ
細かい単位の操作方法など。
UiPathの記事をかなりしっかり目に書かれているBlog。
Ruby on Rails チュートリアルで詰まった話（7章）
Ruby on Rails チュートリアルをゆっくりと進めています。
以下、自分の学習の記録として。
詰まった箇所
7.3.4 失敗時のテスト 演習の1
リスト 7.20で実装したエラーメッセージに対するテストを書いてみてください。どのくらい細かくテストするかはお任せします。リスト 7.25にテンプレートを用意しておいたので、参考にしてください。
詰まった原因
Google Chromeで動的なページのソースを見たいときには
右クリックから「ページのソースを表示」ではなくて「検証」。
（すぐ下に見えていてもハマっているときは気づかないものですね…）
自分の答え
#Signup失敗時のテスト test "invalid signup information" do get signup_path #POST先が正しいかのテスト assert_select "form[action=?]", signup_path #不正なUserデータをPOSTしてテスト assert_no_difference 'User.count' do post signup_path, params: { user: { name: "", email: "user@invalid", password: "foo", password_confirmation: "bar" } } end assert_template 'users/new' assert_select "div#error_explanation" assert_select 'div.field_with_errors' assert_select 'ul' do assert_select 'li', 'Name can\'t be blank' assert_select 'li', 'Email is invalid' assert_select 'li', 'Password confirmation doesn\'t match Password' #パスワードの文字数制限が変わった時のため、文字数部分のエラーメッセージより前で部分一致を検証 assert_select 'li', /Password is too short*/ end end
上手い人だともっと奇麗に書くのかもしれませんが…
WatsonのNatural Language Classifierで遊んでみた
機械学習の勉強のためにWatsonを使って
「曲名からその曲の年代を推定するWebアプリ」を作って遊んでいます。
今はネット上から拾ってきて手作業でざっくり加工した
過去のCD売り上げTOP100（年間）データを入れていますが
「世界に一つだけの花」みたいに複数年度でTOP100入りしている曲があるので
もう少しinputデータをちゃんと加工してあげないといけなさそう。
もう少し見栄えをよくするのは（Web系の言語の勉強を兼ねて）今後の課題ですね…
ある程度形になったら全然違う単語を入れて
「使われてる単語からその年代特有の雰囲気を読み取れるか？」
みたいなことがDeepLearningでできたら面白いかなと思っています。
ちなみにNode-REDでこれくらいしか作りこんでいないので
やっぱりこれ楽だなあと思っています（ダブルクオーテーションの全角半角で盛大にハマった事実から目をそらしつつ）
Node-REDでflowに名前を付ける方法
ものすごく些細なことなのですが、
自分が結構な時間ハマった上に
何故か検索してもNodeに名前を付ける方法しか出てこなかったので…
「フロー1」（日本語の場合）と書かれているタブ部分をダブルクリックすると…
無事flowの編集画面が出てきました。
必死で右カラムをクリックしたり、
なぜかタブ部分の右クリックは試したのにダブルクリックを試してなかったりで
変に時間がかかってしまいました…
