pytest-mock を使ってみた #python

概要

  • Python のテストを Pytest で書いてみた
  • Mock を使おうと思ったら pytest-mock という標準の薄いラッパーを使うのがいいらしい
  • そもそも標準を知らないので少し苦労した
  • なのでログとして残しておく

テスト対象

HTTPリクエストして、レスポンスを返すような処理を書いてみる。

レスポンスをモックしてテストしてみる。

import requests

def sample():
    try:
        # ここを Mock したい
        res = requests.get("http://checkip.amazonaws.com/")

    except requests.RequestException as e:
        print(e)
        raise e

    return {
        "statusCode": res.status_code,
        "ip": res.text,
    }

テストコード

本来なら 200 のレスポンスが返ってくるはずだが、 404 にしてみる

from hello_mock import app

def test_sample(mocker):
    # 嘘のレスポンスを作成
    responseMock = mocker.Mock()
    responseMock.status_code = 404
    responseMock.text = '127.0.0.1'

    # requests.get の戻り値を patch する
    mocker.patch('requests.get').return_value = responseMock

    actual = app.sample()
    assert actual['statusCode'] == 404
    assert actual['ip'] == '127.0.0.1'

補足

pytest-mock を使うと、 mocker 経由で Mock を扱えるので便利。

side-effect とかを使えば例外のテストなんかもできそう。

参考

DockerHub から image のタグ一覧を取得する

Docker Hub の image から tag を探そうと思ったときに、数が多いと中々目当てのものが見つからなかったりする。

API で取得するスクリプトを組んでる人がいたが、API のバージョンが古かったり、タグがたくさんあるとページングされたりするので、自分で書き直してみる。

#!/usr/bin/env bash

function docker-taglist() {
  local image=${1}

  local response=$(curl --silent --show-error "https://registry.hub.docker.com/v2/repositories/${image}/tags/")
  local names=$(echo ${response} | jq -r .results[].name)

  echo -e "${names}"

  # 最大 5 ページまで取得する
  local page=1
  local next=$(echo ${response} | jq -r .next)
  while [[ ${page} -lt 5 && ${next} != "null" ]]
  do
    response=$(curl --silent --show-error "${next}")
    names="${names}\n$(echo ${response} | jq -r .results[].name)"

    echo -e "${names}"

    page=$((${page}+1))
    next=$(echo ${response} | jq -r .next)
  done
}

エイリアスに登録しておけば、こんな感じで使える。

$ docker-taglist library/mysql
5.5
5.5.62
5.6
5.6.43
...

ページ数は引数で受け取れるようにするといいかもしれない。

参考

DockerHubのイメージのタグ一覧をコマンドで取得する | Mazn.net

「サーバ/インフラを支える技術」を読んだ

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

10年以上前の本なのだが、古本屋でたまたま手にとって、よさそうだなと思って読んでみた。

冗長化とか構成管理とか、今でも通じる話の基本的な考え方が書いてあって、今読んでもいい本だと思う。

ツールは多分今だと違うやつだろうなとか、これはオンプレ時代だと大切だったんだろうな、みたいな話は流し読み。

個人的に一番よかったのは個別のインスタンスの負荷をどう見ていくかというところ。

ロードアベレージ見て、CPU負荷かI/O負荷か切り分けて、そしてそれがどういう仕組みなのか、みたいなところがとてもわかり易かった。

この辺の考え方はどこかで役に立ちそう。

コンテナベースの世界になるとまた違ってきそうだけど。

前よりはマシになっている気はするが、どうしてもインフラの苦手意識は消えない。

モダンな話は 入門 監視 ―モダンなモニタリングのためのデザインパターン あたりを読むと書いてあるのかなぁ。

それにしても10年前の本だと思うと、はてなってやっぱりすごい会社だったんだなと感じる。

Go で JSON を扱うユーティリティを作ってみた #golang

概要

Go で JSON を扱うときは構造体を用意して扱うのが一般的と思われる。

ただ外部の API 経由で取得する JSON なんかだと、フィールドが大量だったり、階層が深かったりして扱うのが大変だったりする。

一部の値だけ使いたいときにもっと手軽に扱えないかなー、と思ってユーティリティを作ってみた。

github.com

使い方

README とか Example も書いたんだけどこんな感じ。

jsonVal := `
  {
      "team": "FC Barcelona",
      "captain": {
          "name":"Messi", 
          "position":"Forward"
      }
  }
  `
// JSON 文字列からコンテナを生成
container, err := chazuke.FromJSON(jsonVal)
if err != nil {
    panic(err.Error())
}

// Get で ほしい情報にアクセスして Value で取り出す
team, err := container.Get("team").Value()
if err != nil {
    panic(err.Error())
}
fmt.Println(team) // -> FC Barcelona

// 階層化してる場合はこんな感じ
captain, err := container.Get("captain").Get("name").Value()
if err != nil {
    panic(err.Error())
}
fmt.Println(captain) // -> Messi

他にも配列を扱えるようにしたりしてる。

補足

まぁすでに何かしらありそうだなとは思っていたけれど、だいぶ似たようなのがあったw

勉強になったし、作りたいから作ったということで。。

github.com

「なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」を読んだ

Amazon の Prime Reading で読めたので読んでみた。

スタートダッシュ方式による時間管理術の本。

自分は一定のペースで走るタイプなので、最初に全力を出す(この本でいうところの界王拳を使う)はあんまり向いてないなぁ、と思いつつ、なるほどなぁと思うところも多かった。

成功者という立場の人が言っているのは間違いない。

だけどそれを踏まえても、自身のやり方がいいと思っているし、読者に心からオススメしたいという筆者の熱い思いが伝わってくる。

こういう人だから成功したんだろうなとも思う。

朝、起きる時間を早めるところから始めてみようかなぁ。

#RSGT2019 に参加して考えたことなど

2019.scrumgatheringtokyo.org

今年も Regional Scrum Gathering Tokyo に参加してきた。

チケット取れずに行けないかなと思っていたけど、December チケットで滑り込み。

RSGT2019 をきっかけに自分が感じたり考えたことをまとめておく。

なので、セッションのレポートでもなんでもない。

成果を測定する

最近は Delivery をうまく行かせることに思考の比重がよっていたと思う。

でも「そもそもなんでやりたかったんでしたっけ?」「求める成果はなんでしたっけ?」という問いと、それは「何(の数字)がどうなっていたら成功なんでしたっけ?」というところは、ちょっと疎かになっていたかもしれないなぁ。

あと人間は見たいものを見てしまうので、「見ている数字が間違っている」可能性も往々にしてある。

求める成果と、成果を計測する指標は必ずしも結びつくものではないということは意識したい。

仕事は成果を、評価は能力を

ビジネスなんだし欲しいのは Outcome でしょ?というのはもちろんそうなんだけれど。

「技術は手段」みたいな言説にも通じるのかもしれないけど、どこかモヤっていたところがあって。

プログラマとかそれに類するような職種って、必ずしも(特に短期的な)成果に直接結びつく仕事をしているわけじゃないですよね。

そもそもが職種的に「計測できるものを作る」のが仕事なわけだし。

例えばすごい技術力があると、成果を出すためのオプションが増えたり、最適な手段を選べたりする。

だけどそれが直接成果になるわけじゃない。

そこに対して「成果を出せ」というのはどうしてもしっくり来なかった。

そんなことを考えていたら、ふと思いついたんですよね。

あぁ、成果で人事評価しようとするからおかしいんだと。

ビジネスは当然成果を求めていくべきなんですけど、人事評価は能力ですべきなんじゃないかなと。

「成果を出したから評価する」ではなく「成果を出す能力があるから評価する」なのであって。

短期的な成果にインセンティブやボーナスはあってもいいとは思うけど。

実験しよう

2018年の RSGT の Keynote で、リチャード・シェリダンが「Run The Expetriment」と言っていたのを強く覚えていて。

そしたら今年の Keynote はクリス・ルシアンが「Start Experimenting」と言っていて。

あぁ、自分の価値観に大きなインパクトを与えてる二人が同じこと言っているんだなぁと思うなどした。

実験しなきゃだめですね。

コミュニケーションの仕組みづくり

チーム開発にはコミュニケーションが重要というのは明白なわけですが。

よなよなエールの、コミュニケーションの「量を増やす」「質を高める」アプローチを仕組み化しているのは素晴らしいと思った。

個人の能力や努力に任せるよりも仕組み化する。

リモートワークみたいなものに抵抗が残るのは、単純接触機会の喪失だったりもするんだけれど、この辺の考え方は大きなヒントになるかもしれない。

マネージャーの心理的安全性

心理的安全性ゲームをやったとき、マネージャーをロールにおいてみたら、びっくりするくらいメンバーの気持ちが離れるのが早かった。

信頼を取り戻すチャンスすら与えられない感じ。

もちろんマネージャーがいろんなことに配慮しなきゃいけないのはそうなんだろうけど、気を遣いすぎて「マネージャーが言いたいことを言えない」っていう状況も健全じゃないよね。

メンバーの心理的安全性を確保する以上に、マネージャーの心理的安全性を確保する方が実は難しかったりするんじゃないの?と思った。

その他

OST ファシリテーターに挑戦したり、終わった後にお声掛けいただいて打ち上げっぽいもの?に参加したり他にもいろいろ刺激を貰ったけれどこの辺で終わりにしておく。

RSGT は年初にやってくれるのがいいね。

今年も頑張ろうという気持ちになる。

f:id:su-kun1899:20190114172856p:plain

「仕事は楽しいかね?」を読んだ

仕事は楽しいかね? (きこ書房)

仕事は楽しいかね? (きこ書房)

Prime Reading で無料だったので読んでみた。

悪くはないと思うのだが、それほど刺さるものでもなかった。

評判がよかったので、期待値が高かったからかもしれない。

どういう層がターゲットなのかはわからないけれど、読むタイミングによっても受け取り方は違ってきそう。

なんとなく、この本で語られているような内容は、違う道でインプットしてきた気がする。

仕事は楽しいかね?」という問に対し、「まぁ、それなりに」と答える程度には楽しんでいるので、あまりこの本は向いていなかったのかもしれない。