先日、こわーい先輩からこんな指摘を受けました。

APIの仕様書ではJSONのキーが “id” になっているけど、 “Id” で呼び出して動いたんだけど、どうなってんの？ちゃんとしてよ！

あれ？JSONタグミスったかな？と思いながら調べてみると、ちょっと面白い発見があったので、今日はそのお話です。（ちなみにJSONタグはミスっていませんでした）

なお、本事象は、執筆時点の最新である go1.14.3 で確認しています。

GoでJSONを扱う時のおさらい

GoでJSONをデコードする場合は、マップを利用することもできますが、次のような感じで構造体を定義しておくことが多いのかなと思います。

type foo strcut {
  ID    string `json:"id"`
  Value string `json:"value"`
}

`json:"id"` といった記述は、JSON形式に変換する場合のキー名を指定するJSONタグです。大文字小文字、スネークケースなど、Goのフィールド名に依存させたくない場合に使用します。

このように構造体を定義しておけば、次のようなJSONをデコードすることができます。

{"id":"xxx","value":"yyy"}

実際の挙動はPlaygroundで確認できます。

本当に“id”ではなくて”Id”で読み込めてしまうのか

では、本題に戻りましょう。Playground上で、JSONのキーを次のように変更しても、確かに問題なくデコードできていることが分かります。

{"Id":"xxx","Value":"yyy"}

実は Id だけでなく、 ID も iD も、全て構造体の ID フィールドにマッピングされます。どうやら大文字小文字は気にしていないようです。

では試しに、大文字小文字をごちゃ混ぜにした、次のようなJSONを読み込ませてみましょう。

{"id":"a","ID":"b","Id":"c","iD":"d","vAlUe":"yyy"}

結果は下記のようになります。どうやら同じフィールドにマッピングされるキーが複数存在した場合は、後勝ちになるようです。

{ID:d Value:yyy}

標準パッケージを読み解いてみる

Goの標準パッケージ encoding/json を読み進めていくと、該当のロジックは下記にありました。

golang/go

「JSONのキー名のマップから取得ができなかった場合に、大文字小文字を無視してマッピングしますよ」とコメントにも記載されています。さらに、Godocにも下記のように記載されています。

…, preferring an exact match but also accepting a case-insensitive match.

「完全一致を優先し」てはいないような気もしますが、ひとまず今回発生した事象についてはこれで説明ができました。

今の挙動は今後変更されるかもしれない

実はGitHubに、今回の事象についてのIssueがあります。やはり皆さん、今の挙動に納得していない様子。デコーダーに UseStrictNames メソッドを追加して大文字小文字を無視しないオプションを用意する案や、JSONタグでフィールド毎に個別に制御する案が上がっていますが、まだどのように対応されるかよく分からない感じです。

ただ、「完全一致のフィールドが見つかった後は、不完全な一致（大文字小文字を無視した一致）のデコードをスキップする」という修正がChange Listにあがっているため、単純な後勝ちになる今の挙動は、もしかしたら変更されるかもしれません。

大文字小文字を無視するとキーが重複してしまうようなJSONを使用することはなかなかないと思うので、今の挙動が問題となることは少ないように思います。ただ、今の仕様を頭の片隅に置いておいてあげると、こわーい先輩に指摘されても、冷静に回答できるかもしれませんね。

Try Golang! JSONデコード時のキーの一致判定 was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

マスク生活のおかげで、ひげを伸ばしたい放題のイワモトです。先日、GoのMustacheテンプレートエンジンにプルリクエストを送ったところ、マージされました。その話を書きます。小ネタです。

Mustacheとは？

Mustacheはプログラミング言語や用途に依存しない汎用的なテンプレート仕様です。40以上のプログラミング言語で処理系が実装されています。

構文に {{var}} のように波括弧が頻出し、{ が横向きの口ひげに見えることから、口ひげを表すMustacheと名づけられました。

どんなプルリクエスト？

ぼくが送ったプルリクエストはこちらです。写真はメンテナの方で、ぼくではありません。

Support missing variables at any depth by iwamot · Pull Request #39 · cbroglie/mustache

こんなテンプレートに対して：

You have {{count}} items:
{{#sections}}
--{{name}}--
{{#items}}
{{.}}
{{/items}}
{{/sections}}

下記のコードを実行した場合：

mustache.AllowMissingVariables = false
s, err := mustache.Render(tmpl, map[string]interface{}{
    "count": 2,
    "sections": map[string]interface{}{
        //"name": "Stuff",
        "items": []string{"foo", "bar"},
    },
})
fmt.Println(s, err)

sections.name が存在しないのだからエラーを返してほしい、というissueが立ったのが2016年10月のこと。

メンテナから「I agree this is a valid issue.」「PRs are welcome 😄」と返信があったものの、ずっと放置されていました。

2020年4月、GoのMustacheについて調べていたぼくは、たまたまこのissueを見つけました。むむ、これは対応できそうな気がするぞ。

さっそく手もとで試したところ、エラーハンドリングの追加と、テストコードの移動だけでエラーを返せることがわかりました。なかなかエレガントなdiffではないでしょうか。

すぐにプルリクエストを送ったものの、メンテナが忙しそうなので、反応は期待しませんでした。そして送ったのを忘れた頃、マージ完了の通知が来た次第です。送ってみるものですね 🧔

GoのMustacheエンジンにマージされたプルリクエストの話 was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

はじめに

Pythonとデータ処理や機械学習に興味があり、東大の松尾研が主催しているGCIデータサイエンティスト育成講座を受講しました。コロナの影響で授与式兼交流会が延期になったため修了証を受け取っていませんが、受講した感想を書いてみます。

講座の受講の仕方

東京大学グローバル消費インテリジェンス寄附講座

WEBの募集フォームから応募します。応募の際、簡単なPythonの Numpyを使った10問ほどのテストを受けます。時間は結構ありそれほどプログラム的には難しくない問題でした。その後合格した方にメールが送られてきて、受講可能となります。

対象の受講者

現役東大生および一般社会人

受講方法

東大生向けオフライン授業と一般向けのオンライン講座を同期して行われました。一般社会人はオフライン授業の動画を後日オンラインでみることができました。

コースカリキュラム

1. 本講座の概要とPythonの基礎

2. 科学計算、データ加工、グラフ描画ライブラリの使い方の基礎

3. Pythonによる科学計算（NumpyとScipy）

4. Pandasを使ったデータ加工処理

5. Matplotlibを使ったデータ可視化

6. 統計・確率

7. 機械学習の基礎（教師あり学習）

8. 機械学習の基礎（教師なし学習）

9. モデルの検証方法とチューニング方法

10. データサイエンティスト中級者への道

週１回の講義で配信されるチャプターを独自で読んで学習し、その講義に対して毎回宿題が出る形でした。また宿題の他に「コンペ」と呼ばれる機械学習の精度を競う課題が期間中に計３回、最後に最終課題が出されました。コンペではKaggleを模した形式になっており、実際のデータを分析して他の生徒とスコアを競うものでした。

Kaggleとは

世界中の機械学習・データサイエンスのコミュニティです。企業や政府のプロのデータサイエンティストや機械学習エンジニアを繋げるプラットフォームです。Kaggleの特徴の一つであるCompetition（コンペ）により、企業や政府がコンペ形式（競争形式）で課題を提示し、賞金と引き換えに最も制度の高い分析モデルを買い取るという、最近でいう一種のクラウドファンディングに近いような仕組みとなっています。

Kaggle: The World's AI Proving Ground

また今回の講座で使っている教材はこちらのページで無料公開されています。よって誰でも勉強することができます。 （演習課題とコンペ以外）

グローバル消費インテリジェンス寄附講座演習コンテンツ 公開ページ

学習環境

学習環境はiLectとSlackが提供されました。その中でJupiter Notebookと同じプログラムの実行環境が構成されていて、提供された教科書を読んだ後、プログラムを実行しながら、講義を理解していく形です。

• iLect by NABLAS | AI人材育成, Deep Learning, データサイエンス | 日本
• Project Jupyter

また、Googleが無料で公開しているJupiter Notebook環境であるColaboratoryで同様に動かすことができるようです。

Google Colab

講座内容、宿題、コンペの疑問、質問、問題などをオンラインでSlackを通じて行いました。 基本的には自習する形なのですが、Slackで受講生たちがTAに自由に質問したり生徒間で意見交換できたりしました。

実際受講した感想

最初授業が始まる前にSlackで受講生たちの自己紹介があったのですが、大学院の研究者だとか企業の研究員、病院の医者などそうそうたるメンバーだったので、授業についていけるのだろうか？ととても不安に思っていました。また、フルタイムで働いた後、家事・育児に追われる中、講義の復習、宿題、コンペをやる時間が本当に無く、寝る間も惜しんで勉強していた本当につらい３ヶ月でした。しかし、iLectの使いやすさとSlackで他の方々からのヘルプによりどうにかドロップアウトせず最後まで続け、無事修了することができました。

今後

今回のこの講座からPythonと機械学習について基礎を学びことができました。今コロナが流行るアメリカでは、ホワイトハウスがKaggleで賞金ありの分析コンペを公開しています。

COVID-19 Open Research Dataset Challenge (CORD-19)

今後はさらに機械学習を学んで、このようなKaggleに挑戦できたら良いと思います。

東大松尾研の「GCIデータサイエンティスト育成講座」(無料)を修了しました was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intent-Responseパターンの提案

昨秋に受けた人間ドックの結果、メタボ予防の指導対象となったイワモトです。半年間の指導が先日終わりました。

人間のファットも問題ですが、Webアプリにおけるコントローラのファットも問題です。保守性が下がり、エンバグの危険性が高まるためです。書籍『Rails AntiPatterns』でも、Railsのアンチパターンのひとつとして「Fat Controller」が挙げられています。

Fat Controllerの予防には「ビジネスロジックやプレゼンテーションロジックをコントローラに書かない」ルールを守るのが効果的です。前者はモデル、後者はビューの責務です。このルールを守れば、コントローラをスリムに保てます。

ただ、ルールを守るといっても、なかなか大変です。プロジェクトに携わるすべてのプログラマにルールを守らせるには、相応のコストがかかるでしょう。ルールの周知、ルール違反の検知・修正といったコストです。

何か、頑張らなくてもルールが守られる実装パターンは考えられないものでしょうか？ もし、そのようなパターンで実装されたフレームワークなりミドルウェアなりが使えたら、コストをかけずにFat Controllerが予防できます。

Intent-Responseパターン

そこで思いついたのが「Intent-Responseパターン」です。以下、詳しく説明します。

Intent

• ビジネスロジックを担当
• コントローラのアクションから即座に呼び出される
• HTTPリクエストを受け、HTTPステータスコードとビジネスロジックの実行結果（outcome）を返す

Response

• プレゼンテーションロジックを担当
• Intentが返したHTTPステータスコードをもとに、コントローラから呼び出される
• HTTPリクエストとoutcomeを受け、HTTPヘッダとレスポンスボディを返す

コントローラ

• IntentとResponseの呼び出しを担当
• HTTPリクエストを受け、呼び出すべきIntentを決めて呼び出す
• Intentから返されたHTTPステータスコードをもとに、呼び出すべきResponseを決めて呼び出す

Intent-Responseパターンの実装例

言葉だけでは分かりづらいので、実装例として、Flaskの拡張機能を作ってみました。flask-skinnyです。

iwamot/flask-skinny

インポートすると、Flaskアプリを下記のように実装できます。

from flask import Flask
from flask_skinny import skinny
from random import randint
import json


def intent(request):
    if randint(0, 1) == 0:
        status_code = 200
        outcome = "OK"
    else:
        status_code = 403
        outcome = "Forbidden"
    return status_code, outcome


def response(request, outcome):
    headers = {"content-type": "application/json"}
    body = json.dumps({"message": outcome}) + "\n"
    return headers, body


app = Flask(__name__)


@app.route("/", methods=["GET"])
@skinny.responses({200: response, 403: response})
@skinny.intent(intent)
def index():
    pass

ご覧の通り、コントローラのアクションには「pass」しか書かれていません。究極のSkinny Controllerといえます。pass以外のコードが書かれていたらルール違反であり、その検知や修正は簡単です。

アクションには @skinny.intent デコレータが指定されています。デコレータは自動的に intent 関数を呼び出します。

intent 関数は、50%の確率で 200, "OK" もしくは 403, "Forbidden" を返します。

次のデコレータは @skinny.responses です。自動的に response 関数を呼び出します。今回は説明を簡単にするため、200 でも 403 でも response 関数を呼び出すようにしました。

response 関数は、Intentの実行結果（outcome）をJSON文字列に変換し、HTTPヘッダとともに返します。それらの戻り値がアクションの戻り値となります。

上記アプリを起動し、アクセスすると、下記のような結果が得られます。

$ curl -v http://localhost:3000/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET / HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.58.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< content-type: application/json
< Content-Length: 18
< Server: Werkzeug/1.0.0 Python/3.8.2
< Date: Mon, 30 Mar 2020 08:15:12 GMT
<
{"message": "OK"}
* Closing connection 0

想定される質問

Intent-Responseパターンのメリットは何ですか？

以下のメリットがあります。

• Skinny Controllerが実現できる
• プログラマがIntentとResponseの実装に集中できる
• フレームワークへの依存度が下がる

なぜIntentをModel、ResponseをViewと呼ばないのですか？

そう呼んでもよいのですが、既存のMVCフレームワークとの違いを明確にしたく、別の名前を選びました。

Fat Controllerは予防できても、Fat IntentとFat Responseを生むのではないですか？

それぞれの責務が守られていれば問題ないと思いますが、コード量が増えて読みづらければ分割すべきでしょう。

Intent-ResponseパターンはRailsのようなフルスタックフレームワークでも使えますか？

使えると思います。が、そうすべきかどうか、実際のところは実装してみないと分かりません。

IntentでHTTPステータスコードを返すのは適切なのでしょうか？

Intentの実装者にとって分かりやすいだろうと判断して採用しました。結果コードのようにResponseの選択に使える値であれば、何でもよいとは思います。

なぜResponseにrequestを渡すのですか？

プレゼンテーションロジックにも、HTTPリクエストの内容が必要となる処理がありえるからです。たとえば表示言語は、ビジネスロジックでは不要でも、プレゼンテーションロジックでは必要になるでしょう。

Response内でHTTPステータスコードを変えたいのですが？

はい、その必要があるなら、Responseのインターフェイスを変えても構いません。

def response(status_code, request, outcome):
    headers = {"content-type": "application/json"}
    body = json.dumps({"message": outcome}) + "\n"
    return status_code, headers, body

flask-skinnyについて、Intentが受け取るrequestは何ですか？

flask.requestにしました。Flaskへの依存をなくすのが最優先なら、WSGIのenvironを渡すべきです。が、flask-skinnyはFlaskの拡張機能なので、その必要はないと判断しました。

おわりに

この記事では、Fat Controllerの予防策として、Intent-Responseパターンを提案しました。また、実装例のflask-skinnyもご紹介しました。

ただし、このパターンで書いたWebアプリを実運用しているわけではないので、考慮不足があるかもしれません。お気づきの点がありましたら、コメントいただければ幸いです。

Fat Controllerをコードで予防する方法はないか？ was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Continuous Integration/Continuous Delivery (CI/CD)について、筆者はこれまでCircleCIをよく使っていたのですが、最近GCPのCloud Buildを触る機会があり、思っていた以上に便利だったので、その紹介をしたいと思います。今、GCP + CircleCIを使っている人が、Cloud Buildを検討するきっかけになれば幸いです。

結論を一言で言うと、「GCPを使っているなら、Cloud Buildを使った方が便利だよ」ということ。当たり前のことかもしれませんが、便利だと感じた３つの点について、CircleCIと比較しながら紹介していきます。

便利なこと その１：１ステップ１コンテナ

CI/CDのフローを実装する時、一般的には「ビルド」「テスト」「デプロイ」といった複数のステップが必要になることが多いと思います。この時、ビルドやテストはGoが必要で、デプロイにはGoogle Cloud SDKが必要で、といった風に、複数のツールが必要になることになります。

CircleCIの場合、ジョブ単位で仮想マシンまたはDockerイメージを指定するため、これを実現するためには、ひとつの仮想マシン上に全てのツールをインストールしてあげるか、特定のDockerコンテナ（例えばGoogle Cloud SDKのDockerコンテナ）に残りのツールをインストールしてあげるといった実装が必要になります。他にも、全てのツールがインストールされたDockerイメージを用意してそれを使用するとか、ジョブを分けて書くといった方法でも実現が可能ですが、いずれも管理が面倒だったり、制約があってうまく実現できなかったりすることがあります。

一方で、Cloud Buildの場合、ステップ単位でイメージを指定するため、ビルドとテストはGoのコンテナ上で実行し、デプロイはGoogle Cloud SDKのコンテナ上で実行するといった書き方が簡単にでき、ツールのインストールといった面倒な準備が不要となります。例えばこんな感じ。すごいシンプルですね。

steps:
  - name: 'golangci/golangci-lint'
    id: 'lint'
    args: ['golangci-lint', 'run']
  - name: 'golang'
    id: 'test'
    args: ['go', 'test', './...', '-v']
  - name: 'golang'
    id: 'build'
    args: ['go', 'build']
  - name: 'gcr.io/cloud-builders/gcloud'
    id: 'deploy'
    args: ['app', 'deploy']

便利なこと その２：設定ファイルの分割

CircleCIの場合、フローは .circleci/config.yml に記述する必要があります。一方で、Cloud Buildの場合は、トリガーを複数作成することができ、それぞれのトリガーに対して実行するファイル名を指定できるので、デフォルトの cloudbuild.yaml というファイル名でなくても構いません。ディレクトリも含め、 build/cloudbuild-prod.yaml 、 build/cloudbuild-dev.yaml といった風にカスタマイズできます。複数のプロジェクトに同じリポジトリのトリガーを作成することもできます。

実はCloud buildでは、CircleCIでは当たり前の条件分岐（「 master ブランチの場合だけ実行する」といった分岐）を書くことができません。その代わりといってはなんですが、 master ブランチの場合に実行するファイルと、それ以外のブランチの場合に実行するファイルを分けて記述することで、同等の挙動を実現することができます。

「条件分岐を書けない代わりに、設定ファイルを分割できる」という仕様は一長一短で、人によって好みが分かれるとは思いますが、設定ファイルが長くなってくると途端に読みにくさが倍増するので、分割できること自体はありがたいなぁと思います。

便利なこと その３：GCP IAMとの親和性

最後に持ってきましたが、一番便利なのはこれです。Cloud Buildは、実行時にCloud Buildのサービスアカウントをデフォルトで利用できるのです。

CircleCIの場合、CircleCI用のサービスアカウントを作成して、サービスアカウントの鍵をダウンロードして、環境変数に鍵を設定して、それを実行中に読み込んで、 gcloud コマンドで認証して、と複数の手順が必要でしたが、Cloud Buildなら面倒な初期設定がごっそり不要になります。

GCPを使用しているのであれば、GAEへのデプロイや、GCPのデータベースに接続するテスト、KMSを用いた秘匿情報の暗号/複合等々、何かとGCPのサービスに依存することが多くありますが、Cloud Buildなら自動的に作成されるCloud Buildのサービスアカウントに必要な権限を付与してあげるだけ。これはとても楽ちんですね。

本記事では、CircleCIと比べたCloud Buildの便利な点を３つ紹介しました。ただ、今回は触れませんでしたが、Cloud Buildがいまいちな点ももちろんあります（キャッシュ機能がない等）。また、GitHubとの連携については、GitHub Actionsなども出てきているので、それぞれの特徴を知って、自分に合ったサービスを見つけてください。

GCPを使ってるならCloud Buildがいいんじゃない？ was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

前編では、APIで日経平均株価のデータの取得と前処理、移動平均線の表示まで行います。
後編では、前編のデータを使い、ポイントアンドフィギュア(以下: P&F)の表示を行います。

PythonはJupyter Notebookで実行しています。

はじめに:

Pythonを使ってAPIでデータ取得、前処理、グラフ表示をするのが目的です。要件をみたすデータとして、日経平均株価を使って移動平均線とP&Fを表示しています。

こちらのデータを使って投資を薦めているわけではありません。

データ整形:

ここからは、ソース内にコメントを記載していきます。

まずは関数を作成します。

作成する関数

• 日経平均値から閾値の計算: getFrameValue
• P&Fの枠数のリスト作成: getFrameList
• P&Fのマーク用に1 or -1 を戻す

# 値が枠の閾値になるように計算
# 計算方法: 値 / 枠の幅 -> 整数に変換 -> 枠の幅を乗算
# ex) 値: 23820, 枠の幅 200, 閾値, int(23820 / 200) -> 119 * 200 -> 23800
def getFrameValue(val, box):
  return int(val / box) * box

# チャートに記載する枠数を求めリストにセット
# ex) 値: [2000, 2250, 20610, 22210, 21430, 23000], 枠の幅 200, リスト: [1, -3, 8, -4, 8]
def getFrameList(data_list, base_value, box, change_frame):

  p_list = [0] # returnの初期値

  # 対象データ分ループ
  for val in data_list:

    val = getFrameValue(val, box)
    last_diff = int((val — base_value)/box) # 前日との差分

    past_diff = p_list[-1] # 前日の枠数

    # 前日がプラス
    if past_diff >= 0:
      # 前日より高い
      if last_diff > 0:
        p_list[-1] = past_diff + last_diff # 高値更新のため上書き
        base_value = val
      # 前日より低い かつ 枠変換以下
      elif last_diff < 0 and last_diff <= change_frame*-1:
        p_list.append(last_diff) # 次の列になるため、追加
        base_value = val
    # 前日がマイナス
    elif past_diff < 0:
      # 前日より安い
      if last_diff < 0:
        p_list[-1] = past_diff + last_diff # 低値更新のため上書き
        base_value = val
      # 前日より高い かつ 枠変換以上
      elif last_diff > 0 and last_diff > change_frame:
        p_list.append(last_diff) # 次の列になるため、追加
        base_value = val

  # 1件目のデータ終値 からスタートしているので、プラスマイナス1
  # ここがないと、データが1マス分ずれていたので、調整
  if p_list[0] < 0:
    p_list[0] -= 1
  elif p_list[0] > 0:
    p_list[0] += 1
  elif p_list[1] < 0: # 1つ目が0だと2つ目のデータで判断
    p_list[0] += 1
  elif p_list[1] > 0: # 1つ目が0だと2つ目のデータで判断
    p_list[0] -= 1

  return p_list

# 印の表示用に絶対値で割る, return は 1 or -1 
# 0なら1
def sign(val):
  result = 1
  try:
    result = val / abs(val)
  # 0なら1を戻す
　except ZeroDivisionError:
    result = 1
  except:
    pass

  return result

つづいて、枠の幅と変換点を指定して、P&F作成用の配列を取得します。

# 1枠の幅と変換点、基準値を設定
box = 200
change_frame = 3
base_value = getFrameValue(df_target.values[0], box)

# 表示用のリストを取得
p_list_100 = getFrameList(df_target, base_value, box, change_frame)

# P&Fの印と色を指定
symbol  = {-1:'o',1:'x'} # チャートの印
s_color = {-1:'red',1:'blue'} # チャートの色

P&Fの表示:

作成したデータからP&Fを表示していきます。

# P&Fの表示サイズを指定し、表示枠を作成
fig = plt.figure(figsize=(10, 10))
ax = fig.add_axes([.15, .15, .7, .7])

# P&Fの1点目をスタートの価格に設定
chgStart = base_value

# 表示データ分ループ
for ichg, chg in enumerate(p_list_100):
  # X, Y軸の表示箇所を指定
  x = [ichg+1] * abs(chg)
  y = [chgStart + i * box * sign(chg) for i in range(abs(chg))]
  # 次のX軸の始点を指定
  chgStart += box * sign(chg) * (abs(chg)-2)

  # P&Fの各点を表示
  ax.scatter(x, y,
             marker=symbol[sign(chg)],
             c=s_color[sign(chg)],
             s=175)

# グリッドの中心にP&Fの各印を表示するように調整
# X軸のグリッドを実際の列分表示
plt.xticks(np.arange(0, len(p_list_100)+1,1))
# Y軸のグレードを 最小、最大値 +-1 枠分、枠の幅ごとに表示
plt.yticks(np.arange(getFrameValue(df_target.min()-box*2, box), getFrameValue(df_target.max()+box*2,box),box))
# grid の表示
plt.grid(True)

# グラフ表示
plt.show()

実行すると意図した取りP&Fが表示できます。

日経平均株価のデータ取得からP&Fの表示まで1日かからずに作成することが出来ました。棒グラフや円グラフなどは色々情報があったのですが、P&Fは全然なく、表示するためのデータの作成に一番苦労をしました。

今回は線グラフとP&Fのグラフのみ表示しましたが、月毎に集計して棒グラフにしたり、散布図などを表示するのもいいかもしれませんね。

参考にしたURL:

Jupyter Notebook: https://ai-inter1.com/jupyter-notebook/

pandas: https://pandas.pydata.org/pandas-docs/stable/reference/index.html

matplotlib: https://matplotlib.org/users/index.html

移動平均線: https://fx-quicknavi.com/chart/moving-average/

P&F: https://fx-quicknavi.com/chart/point-and-figure/

Quandl API: https://www.quandl.com/

Pythonで日経平均株価のグラフを作成してみた（後編） was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

2020年5月に「高度なリダイレクト」機能が追加され、多数のページのA/Bテストがリダイレクトテスト機能でできるようになりました。本記事のタイトルおよび本文は、2020年3月時点の情報であり、古くなっています。ご注意ください。

ベルトラのイワモトです。「人生は選択の連続である」と誰かが言ったそうですが、確かに、A定食にすべきかB定食にすべきかなど、難しい選択を迫られる場面はよくあります。

さて、Googleオプティマイズは、ウェブサイトのA/Bテストが簡単にできる便利なツールです。「リダイレクトテスト」機能を使うと、新デザインページへのリダイレクトによるA/Bテストが実現できます。

しかし、2020年3月現在のリダイレクトテスト機能では、リダイレクト先が静的URLでしか指定できず、1ページしかテストできません。たとえば「商品0001の新ページ」はテストできますが「商品0001~商品9999の新ページ」はテストできないのです（※）。

※リダイレクトを /products/0001 → /products2/0001 のようには指定できるのですが、/products/{product_id} → /products2/{product_id} のようには指定できないためです。

それでも、Googleオプティマイズで多数のページをリダイレクトテストする方法があります。以下、詳しくご紹介します。

1. エクスペリエンスの作成

まず、エクスペリエンスを作成します。Googleオプティマイズでは、各種テストやパーソナライゼーションを総称して「エクスペリエンス」と呼んでいます。

作成する際は、下記の2点に気をつけます。

1. 「エディタページ」には新デザインページのURLを指定します。ビジュアルエディタの操作対象として使われるだけなので、どの商品でも構いません。現行デザインのURLにすると、ビジュアルエディタ上でリダイレクトが効いてしまい、操作しづらくなります。
2. 「テストのタイプ」は「A/Bテスト」を選択します。「リダイレクトテスト」を選択しないのがポイントです。

2. パターンの追加

次に、パターンを追加します。現行デザインは「オリジナル」パターンとしてデフォルトで登録されているので、新デザイン用のパターンだけを追加すればOKです。実際には、パターン名を決めるだけです。

3. パターンの編集

続いて、手順2で追加したパターンを編集します。ここでビジュアルエディタが使われます。

3–1. 要素の選択

ビジュアルエディタが開いたら、head要素を選択します。

3–2. 要素の編集

「要素を編集」ボタンを押し、「JavaScriptを実行」を選択します。

コード入力欄が開いたら、リダイレクト用のコードを入力します。

適切なコードの内容はサイトやページによって異なります。ここでは下記のようにします。

if (location.href.includes('/a/')) {
  // Hide body
  var css = 'body {display:none}';
  var style = document.createElement('style');
  style.appendChild(document.createTextNode(css));
  element.appendChild(style);

  // Redirect
  location.href = location.href.replace('/a/', '/a2/');
}

• URLに「/a/」が含まれる場合だけリダイレクトする
• 現行デザインがちらっと表示されるのを避けるため、bodyを非表示にする
• リダイレクト先は、現行デザインページの「/a/」を「/a2/」に変えたもの

プルダウンは「開始タグの後」を選択するのがよいと思います。「終了タグの後」より若干早く処理されるためです。

3–3. 編集内容の保存

「適用」ボタン、「保存」ボタン、「完了」ボタンを順に押し、編集内容を保存します。これでビジュアルエディタが終了します。

4. ターゲティングURLの編集

次に、ターゲティングURLを編集します。現段階では、手順1で選んだ新デザインページが仮設定されています。

これを、正しいターゲットである「リダイレクトテストを実施したい現行ページすべて」に変更しなければなりません。

変更するには、鉛筆アイコンを押して編集画面を開き、下記のように編集します。

1. 「URL」「次の正規表現に一致」を選ぶ
2. 現行ページにマッチする正規表現を入力する

編集したら「ルールの確認」欄で、現行ページのURLが正しくマッチするかどうか確認します。問題なければ保存しましょう。

保存すると「 エディタページが URL ターゲティング ルールと一致しません。」と警告されます。が、気にしなくて大丈夫です。

5. その他の設定

あとは必要に応じて、新デザインの表示確率、ターゲティングユーザー、テスト目標などの項目を設定します。このあたりはGoogleオプティマイズの通常の使い方なので省略します。

6. テストの開始

設定が完了したら「開始」ボタンを押します。いよいよテスト開始です。

現行ページのURLにアクセスすると、手順5で指定した確率で、新デザインページにリダイレクトされます。されなかった場合は、Cookieを削除し、再度アクセスしてみてください。

Cookieを削除するのが面倒なら、ブラウザのシークレットウィンドウでアクセスするのが簡単です。ウィンドウを閉じるとCookieが自動的に削除されます。

おわりに

今回は、Googleオプティマイズの「A/Bテスト」機能を使って多数のページをリダイレクトテストする方法をご紹介しました。将来的に「リダイレクトテスト」機能で可能になることを期待しますが、それまでは今回の方法で実施するのがよいと思います。

なお、この方法は下記ページの内容と原理的には同じです。下記ページでは、ビジュアルエディタに指定するJavaScriptコードが「フラグ変数を設定するだけ」になっています。フラグが立っていたらページ側のスクリプトでリダイレクトする寸法です。この辺は好みの問題でしょう。

Google Optimize - create A/B test with dynamic URL

Happy A/B testing!

Googleオプティマイズで多数のページをリダイレクトテストする was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

前編では、APIで日経平均株価のデータの取得と前処理、移動平均線の表示まで行います。
後編では、前編のデータを使い、ポイントアンドフィギュア(以下: P&F)の表示を行います。

PythonはJupyter Notebookで実行しています。

はじめに:

Pythonを使ってAPIでデータ取得、前処理、グラフ表示をするのが目的です。要件をみたすデータとして、日経平均株価を使って移動平均線とP&Fを表示しています。

こちらのデータを使って投資を薦めているわけではありません。

日経平均株価のデータ取得:

日経平均株価はQuandl APIから取得しています。

制限はありますが、フリーで使用できます。データ取得にはユーザー登録後、APIキーを発行します。

今回は”Nikkei/USD”を使用します。

ドキュメントにしたがってエンドポイントを作成します。

データはjsonで取得するので、下記の用になります。

https://www.quandl.com/api/v3/datasets/CHRIS/CME_NK2/data.json?api_key={API_TOKEN}

では実際に日経平均株価を取得してみます

まず、必要なライブラリをimportします
データの前処理、グラフ表示に必要なライブラリもimportしています。

# API
import requests
import json
import datetime as dt
# 必要なデータを絞るための日付系
from dateutil.relativedelta import relativedelta
from pytz import timezone

# データ前処理、グラフ表示
import numpy as np
import pandas as pd
%matplotlib inline
import matplotlib.pyplot as plt

APIをコールしてデータ取得

# API key
API_TOKEN = ‘your API key’

# エンドポイントを定義
url = ‘https://www.quandl.com/api/v3/datasets/CHRIS/CME_NK2/data.json?api_key={API_TOKEN}'

# json でデータ取得
catched_response = requests.get(url)
json_data = catched_response.json()

※Quandl Python Packageも配布されていますが、今回はrequestsモジュールを使います。

取得したデータを確認。欲しいデータは”dataset_data”内にある”column_names”と”data”になります。

DataFrame型にデータをセットします。

# jsonから必要なデータを取得
columns = json_data[‘dataset_data’][‘column_names’]
values = json_data[‘dataset_data’][‘data’]

# DataFrameにセット後日付カラムをindexに設定
df = pd.DataFrame(values, columns=columns)
df.loc[:,'Date'] = pd.to_datetime(df.loc[:, 'Date'])
df.set_index(‘Date’, inplace=True)

DataFrameにセットしたデータを確認します。

df.info()

データタイプと個数が確認できます。

<class 'pandas.core.frame.DataFrame'>
DatetimeIndex: 7406 entries, 2020-02-12 to 1990-09-26
Data columns (total 8 columns):
Open                          7197 non-null float64
High                          7379 non-null float64
Low                           7349 non-null float64
Last                          7404 non-null float64
Change                        0 non-null object
Settle                        7406 non-null float64
Volume                        7406 non-null float64
Previous Day Open Interest    7406 non-null float64
dtypes: float64(7), object(1)
memory usage: 520.7+ KB

総数 7406に対して、Open, High, Low, Lastの数がバラバラですので、欠損値が存在しているようです。

今回は終値だけ欲しいのでデータの確認、欠損値の処理は”Last”のみ行います

欠損値があるか確認します。

df[df.loc[:, ‘Last’].isnull()]

確かに2件データがとれます。

欠損値を処理します。

欠損値は以下のルールで処理します。

高値: 欠損値前後のNaNではない高値に線形で伸びるとする。

終値: 欠損値前後のNaNではない終値に線形で伸びるとする。ただし高値以上にならない

欲しいデータは終値だけなのですが、高値とも比較したいので、欠損値の処理は高値も行うことにします。

その為、高値、終値の順番に欠損値の処理を行います。

df.loc[:,’High’].interpolate(inplace=True)
df.loc[:,’Last’] = np.minimum(df.loc[:,’Last’].interpolate(), df.loc[:,’High’])

np.minimumで終値と高値を比較し低い方を取得しています。

interpolateで前後のNaN以外の値を取得し、その間の値を取得しています。高値は該当するオブジェクトをそのまま変更したいので、”inplace=True”を指定しています。

欠損値が埋まったことを確認します。

df.info()

総数 とLastが同じ値になっているので、欠損値が埋まったことが確認できます。

<class 'pandas.core.frame.DataFrame'>
DatetimeIndex: 7406 entries, 2020-02-12 to 1990-09-26
Data columns (total 8 columns):
Open                          7197 non-null float64
High                          7406 non-null float64
Low                           7349 non-null float64
Last                          7406 non-null float64
Change                        0 non-null object
Settle                        7406 non-null float64
Volume                        7406 non-null float64
Previous Day Open Interest    7406 non-null float64
dtypes: float64(7), object(1)
memory usage: 840.7+ KB

データ取得から欠損値の処理までのデータの前処理が終わりました。

日経平均株価の移動平均線を表示:

移動平均線のグラフを表示しています。

全期間だとデータ量が多く見にくいので、1年分のみ表示します。

# 1年前の日付を取得
today = dt.datetime.now(timezone('Asia/Tokyo'))
t_year = today - relativedelta(years=1)
t_date = t_year.strftime('%Y-%m')

# 1年分の終値を取得し、グラフ表示
df_target = df.loc[:t_date,’Last’].sort_index()
df_target.plot()
# 移動平均線も表示
df_target.rolling(window = 5).mean().plot()
df_target.rolling(window = 25).mean().plot()

終値の移動平均線を表示したいので、終値だけを取得し、index(日付)でソートします。

日経平均株価と、5日移動平均線、25日移動平均線を表示します。

移動平均線の表示ができました。

前編では主に、PandasのDataframeを使ったデータ処理がメインでした。後編のP&Fの表示では、matplotlibをメインに使っています。

参考にしたURL:

Jupyter Notebook: https://ai-inter1.com/jupyter-notebook/

pandas: https://pandas.pydata.org/pandas-docs/stable/reference/index.html

matplotlib: https://matplotlib.org/users/index.html

移動平均線: https://fx-quicknavi.com/chart/moving-average/

P&F: https://fx-quicknavi.com/chart/point-and-figure/

Quandl API: https://www.quandl.com/

Pythonで日経平均株価のグラフを作成してみた（前編） was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

虎の穴ラボさんの「Python + AWS LambdaでSSL証明書の有効期限をチェックする」を拝見し、この構成ならSAMでデプロイするのが便利そうだと思いました。SAMテンプレートの記述例はこんな感じです。

SAMテンプレートの記述例

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Parameters:
  Urls:
    Type: String
    Description: "Domains to remind (comma separated)"
    Default: "example.com"
  BufferDays:
    Type: Number
    Description: "Days to start reminding"
    Default: 30
  IncommingWebhooks:
    Type: String
    Description: "URL of Slack Incoming Webhook"
    Default: "https://hooks.slack.com/services/*"

Resources:
  RemindFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: remind/
      Handler: app.lambda_handler
      Runtime: python3.7
      Timeout: 10
      Environment:
        Variables:
          Urls: !Ref Urls
          BufferDays: !Ref BufferDays
          IncommingWebhooks: !Ref IncommingWebhooks
      Events:
        RemindSchedule:
          Type: Schedule
          Properties:
            Schedule: "cron(0 1 * * ? *)"
  RemindFunctionLogGroup:
    Type: AWS::Logs::LogGroup
    DependsOn: RemindFunction
    Properties:
      LogGroupName: !Sub /aws/lambda/${RemindFunction}
      RetentionInDays: 90

Outputs:
  RemindFunction:
    Description: "Remind Function ARN"
    Value: !GetAtt RemindFunction.Arn
  RemindFunctionRole:
    Description: "Implicit IAM Role created for Remind function"
    Value: !GetAtt RemindFunctionRole.Arn
  RemindFunctionLogGroup:
    Description: "Log Group for Remind Function"
    Value: !GetAtt RemindFunctionLogGroup.Arn
  RemindFunctionRemindSchedule:
    Description: "Schedule for Remind Function"
    Value: !GetAtt RemindFunctionRemindSchedule.Arn

記述のポイント

以下、記述のポイントを解説します。ポイントは3つです。

1. sam deploy時のパラメータで環境変数を渡す

元記事では、3つの環境変数をLambda関数に渡しています。

• チェック対象のドメイン (Urls)
• 通知対象とする日数の閾値 (BufferDays)
• Slack通知用URL (IncommingWebhooks)

その要件をSAMで実現するため記述したのが下記の部分です。 sam deploy 時にデフォルトパラメータを上書きすることで、Lambda関数に環境変数を渡せます。

Parameters:
  Urls:
    Type: String
    Description: "Domains to remind (comma separated)"
    Default: "example.com"
  BufferDays:
    Type: Number
    Description: "Days to start reminding"
    Default: 30
  IncommingWebhooks:
    Type: String
    Description: "URL of Slack Incoming Webhook"
    Default: "https://hooks.slack.com/services/*"

Resources:
  RemindFunction:
    Type: AWS::Serverless::Function
    Properties:
      -- （中略） --
      Environment:
        Variables:
          Urls: !Ref Urls
          BufferDays: !Ref BufferDays
          IncommingWebhooks: !Ref IncommingWebhooks

2. Cron式でスケジュールを定義する

また、元記事では、CloudWatchのイベントでLambda関数の実行スケジュールを定義しています。JSTの10:00なら「0 1 * * ? * 」のようにCron式で指定するわけです。

SAMテンプレートでも、このCron式が使えます。下記が該当部分です。

Resources:
  RemindFunction:
    Type: AWS::Serverless::Function
    Properties:
      -- （中略） --
      Events:
        RemindSchedule:
          Type: Schedule
          Properties:
            Schedule: "cron(0 1 * * ? *)"

「Schedule」が2つ出てきて混乱しそうですが、それぞれ下記の意味となります。

• Lambda関数のEventsプロパティにScheduleオブジェクトを指定
• ScheduleオブジェクトのScheduleプロパティでCron式を指定

3. CloudWatchログの保持期間を指定する（任意）

なお、必須ではありませんが、CloudWatchのLogGroupリソースを明示的に記述すると、ログイベントの保持期間が指定できます。今回は下記のように90日間としました。

Resources:
  -- （中略） --
  RemindFunctionLogGroup:
    Type: AWS::Logs::LogGroup
    DependsOn: RemindFunction
    Properties:
      LogGroupName: !Sub /aws/lambda/${RemindFunction}
      RetentionInDays: 90

こうすると、不要なログイベントが残り続けて課金対象となるのを防げます。もちろん、あえて残しておきたい場合は記述しなくて構いません。

デプロイ

さて、SAMテンプレートができたら、あとはビルドしてデプロイするのみです。下記のコマンドを実行すれば、Lambda関数の作成からCloudWatchの設定までが、あれよあれよという間に進んでいきます。

$ sam build
$ sam deploy --guided

元記事のLambdaコードも含め、下記のGitHubリポジトリにまとめています。よろしければご参照ください。

vt-iwamoto/ssl-expiry-reminder

元記事のLambdaコードのおかげで、SSL証明書の期限切れ監視ツールとして実用に耐えるものになっていると思います。ベルトラでも活用できそうなサイトがあれば、実環境に投入してみるつもりです。きっかけをくださった虎の穴ラボさん、ありがとうございます。

AWS SAMでSSL証明書の有効期限をチェックする was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

先日、AWS SAMのチュートリアルを進めていて、アプリケーションをデプロイした際、API Gatewayに2つのステージ（「Prod」と「Stage」）が作られ、不思議に思いました。必要なのは「Prod」だけです。調べると、これはSAMのバグで、すでに回避策が提供されていることが分かりました。本記事では、その回避策をご紹介します。

回避策：AWS::Serverless::ApiのOpenApiVersionを指定する

その回避策とは「SAMテンプレートのAWS::Serverless::Apiリソースに対するOpenApiVersionの指定」です。GitHubのissueで正式な回避策として紹介されています。

OpenApiVersionに指定できる値は下記の通りです。

This can either be 2.0 for the Swagger specification, or one of the OpenApi 3.0 versions, like 3.0.1. For more information about OpenAPI, see the OpenAPI Specification.

Globalsセクションで指定する場合

実際の指定先として手っ取り早いのはGlobalsセクションです。下記のように指定するだけで、不要な「Stage」ステージが作られなくなります。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Timeout: 3
  Api:
    OpenApiVersion: 3.0.2

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.7
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get

Resourcesセクションで指定する場合

もしくは下記のように、AWS::Serverless::FunctionリソースのEventSource側で指定しても、不要な「Stage」ステージが作られなくなります。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.7
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get
            RestApiId:
              Ref: HelloWorldApiGatewayApi
  HelloWorldApiGatewayApi:
    Properties:
      StageName: Prod
      OpenApiVersion: 3.0.2
    Type: AWS::Serverless::Api

回避策が使えるAWS SAM CLIのバージョン

この回避策はAWS SAM CLI 0.22.0以降であれば使えるはずです。aws-sam-translator 1.13.0で回避策が追加され、AWS SAM CLI 0.22.0で依存しているaws-sam-translatorのバージョンが上がりました。

まとめ

AWS SAMで余分な「Stage」ステージが作られるバグについて、回避策をご紹介しました。余分なステージを作ってもメリットはないので、忘れずに回避しましょう。

AWS SAMで「Stage」ステージが作られるバグを回避する was originally published in VELTRA Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.