2019年12月13日金曜日

docker-slim 使ってみた

概要

docker-silm はビルドした docker のイメージのサイズを小さくすることができるツールです
イメージは無駄に大きくなることが多いのでこれを使うことでレジストリのディスク容量を節約することができます

環境

  • macOS 10.15.2
  • docker-slic 1.26.1

インストール

執筆時点では Homebrew ではインストールできないようです
公式のホームページからバイナリをダウンロードして PATH 配下に配置すれば OK です

  • unzip dist_mac.zip
  • mv dist_mac/docker-slim* /usr/local/bin
  • docker-slim --version

試してみる

よく使ってる Ruby のイメージがどれくらい小さくなるか試してみました

  • docker images ruby
REPOSITORY TAG IMAGE ID CREATED SIZE ruby latest d529acb9f124 5 months ago 840MB
  • docker-slim build --http-probe ruby
  • docker images ruby
REPOSITORY TAG IMAGE ID CREATED SIZE ruby latest d529acb9f124 5 months ago 840MB

あれ小さくなっていないぞ、、
どうやらポートを EXPOSE しているようなイメージでないとダメなようです
要するに Web アプリのイメージであれば良いようです

イメージを作成する

簡単な Web アプリのイメージを作成してみましょう
元のイメージは Ruby を使っています

  • bundle init
  • vim Gemfile
gem "sinatra"
  • vim app.rb
require 'sinatra'

get '/' do
  'ok'
end
  • vim Dockerfile
FROM ruby

ADD . /home
WORKDIR /home
RUN bundle install

EXPOSE 4567
CMD ["bundle", "exec", "ruby", "app.rb", "-o", "0.0.0.0"]
  • docker build -t my_app .
  • docker images my_app
REPOSITORY TAG IMAGE ID CREATED SIZE my_app latest 09c12a3382ec About a minute ago 872MB

必要なライブラリをインストールした分少し大きくなっているのがわかります

小さくしてみる

ではこれを小さくしてみましょう

  • docker-slim build --http-probe my_app

作成したイメージからコンテナが起動し EXPOSE したポートに対してアクセスします
うまくアクセスできればスリム化が始まります

docker-slim[build]: info=results status='MINIFIED BY 35.26X [872106607 (872 MB) => 24732141 (25 MB)]'」こんな感じのログが表示されれば成功です
スリム化したイメージはイメージ名の最後に .slim が付与されているようです

  • docker images my_app.slim
REPOSITORY TAG IMAGE ID CREATED SIZE my_app.slim latest 3a67521db855 About a minute ago 24.7MB

872MB -> 25MB にまで縮小されました
かなり小さくなっているのがわかります

イメージの動作確認

念の為 Web アプリが起動するか確認してみましょう

  • docker run -d -p 4567:4567 --name my_app my_app.slim

あとは 4567 ポートにアクセスして OK が返ってくるか確認しましょう

  • curl localhost:4567

動作確認できたら停止しておきましょう

  • docker stop my_app
  • docker rm my_app

Web アプリでないとダメなのか

単純に EXPOSE されているイメージであればいけるのかなと思いやってみました

  • vim Dockerfile
FROM ruby

EXPOSE 4567
  • docker build -t my_app2 .
  • docker-slim build --http-probe my_app2

結果はダメでした
docker-slim の途中で EXPOSE したポートにアクセスするときにレスポンスが返ってこないためエラーになりました
docker-slim[build]: info=http.probe.call status=error method=GET target=http://127.0.0.1:32780/ attempt=1 error='Get http://127.0.0.1:32780/: EOF' time=2019-12-11T23:36:21Z

やはりスリム化するためには Web アプリのように何かしらのプロセスでコンテナが LISTEN している必要があるようです
ただ、そこまで仕組みなどを調査していないので他に方法があるかもしれません
サンプル もいろいろとあるので興味があれば見てください

最後に

docker-slim を試してみました
すでに Web アプリがある場合は導入が簡単なのですぐにでも適用できると思います
スリム化後は別のイメージとしてできあがるのでコンテナを起動する際は小さくなったイメージからコンテナを生成するようにしましょう
そうしないと大きいサイズのイメージを使い続けることになるのでせっかくイメージを小さくしたのに大きいサイズのイメージを削除することができません

現状は Web アプリ限定な感じがあるのでポートを EXPOSE しないようなイメージの場合は適用できないかなと思います
小さくするためだけに無理やり EXPOSE するのも微妙かなと思います

参考サイト

2019年12月12日木曜日

Google Speech to Text を使う場合はデータのロギングを有効にしたほうがいい

概要

Google Speech to Text は音声データを文字起こししてくれるサービスです
月間で 60 分以内であれば無料で使えます
60 分以上の音声データを解析する場合にはデータのロギング機能を ON にすることをオススメします
理由は単純に安くなるからです

環境

  • Google Speech to Text API (2019/12/11 時点)

料金比較

基本は 15 秒単位で課金されます
データロギングを有効にした場合は 0.004/15秒 になります
無効の場合は 0.006/15秒 と少し高くなります

データロギングを有効にする

コンソールから API の一覧に移動し Speech to Text を検索しましょう
そしてデータのロギングから「有効にする」ボタンを押せば OK です

有効にするデメリット

解析させたデータが Google 側に残り学習の精度向上のために使われるようです
プライベートなデータを含む音声データの場合それらを学習データの対象などのしたくない場合は有効にしないほうが良いのかもしれません
(詳しくはこちらを御覧ください)

逆にすでにパブリックで公開している音声データは無効にするメリットは特にないので有効にして料金の抑えるのと音声の解析精度を上げたほうが良いかなと思います

最後に

Google Speech to Text のデータロギングについて紹介しました
特に気にしないのであれば有効にすると料金も抑えられます
月間で 60 分を超えないのであればデータロギングの有効無効に関わらず無料で使えるのでどちらでも OK だと思います

参考サイト

2019年12月11日水曜日

go test で特定のディレクトリだけテストを無視する方法

方法

go test -cover `go list ./... | egrep -v 'hoge|fuga|aaa'`

おそらくこれが一番簡単だと思います
-cover-v はお好みで付与してください

無視したいディレクトリ名に含まれる文字列を egrep で指定してあげるだけです
条件は OR になっているので指定した文字列が含まれるディレクトリはテスト対象外になります

2019年12月10日火曜日

ownCloud 10.3 を試してみた

概要

過去に ownCloud を docker で起動する方法を紹介しました
バージョンが上がり 10.3 からは docker-compose を使うようになったので紹介します

環境

  • macOS 10.15.1
  • docker 19.03.5
  • ownCloud 10.3

インストール

  • mkdir owncloud-docker-server
  • cd owncloud-docker-server
  • wget https://raw.githubusercontent.com/owncloud/docs/master/modules/admin_manual/examples/installation/docker/docker-compose.yml
  • vim .env
OWNCLOUD_VERSION=10.3
OWNCLOUD_DOMAIN=localhost
ADMIN_USERNAME=admin
ADMIN_PASSWORD=admin
HTTP_PORT=8080
  • docker-compose up -d

やっていることは docker-compose.yml のダウンロードと設定ファイルの作成だけです
あとは up すれば OK です
イメージのダウンロードとコンテナの起動が完了するまで待ちます
ダウンロードされるイメージは「owncloud-server」「redis」「mariadb」のようです

  • docker-compose ps
Name Command State Ports ——————————————————————————————————————- owncloud-docker-server_db_1 /usr/bin/entrypoint /bin/s … Up (health: starting) 3306/tcp owncloud-docker-server_owncloud_1 /usr/bin/entrypoint /usr/b … Up (health: starting) 0.0.0.0:8080->8080/tcp owncloud-docker-server_redis_1 /usr/bin/entrypoint /bin/s … Up (health: starting) 6379/tcp

動作確認

localhost:8080 にアクセスしましょう
ログインは .env に記載した ADMIN_USERNAMEADMIN_PASSWORD を使います

ログインできれば OK です

最後に

ownCloud 10.3 を試してみました
YAML ファイルをダウンロードして up すればいいだけなので特に難しくはないと思います
各コンポーネントごとにちゃんとコンテナを作成するようになっているので管理も楽になっていると思います

参考サイト

2019年12月5日木曜日

SKPhysicsBody を作成するときは極力 texture を使わないほうが良いと思う

概要

個人的な経験ですが SKPhysicsBody を生成するときは texture ではなくて circleOfRadius や rectangleOf を使ったほうが予期せぬ動作をしない印象があります
ハマった点などを紹介します

概要

  • macOS 10.15.1
  • Xcode 11.2.1 (11B500)

applyImpluse の挙動がおかしい

ある SpriteNode に対して物理エンジンを texture を使って作成しました
そして touchDown 時に applyImpluse を適用するような処理を実装したのですが iPhoneX 系の実機の場合挙動がおかしくなる現象が発生しました

シミュレータでやると問題ないのですが実機でやると力の入れ具合がおかしいのか本来のスピードよりも SpriteNode の動きが速かったり遅かったりしました
その度に端末のサイズごとの対応を入れていたのですが原因が texture によるものだとわかりrectangleOf で物理エンジン生成することで挙動がどの端末でも同じ動きをするようになりました

なぜ texture だとうまく動作しないのか明確な原因は不明ですがおそらく端末のサイズによるものかなと思います
小さい端末に比べて大きい端末の場合 texture 比率が小さくなると思います
おそらくそれにより質量などが端末ごとに変わってしまい力を与える applyImpluse の挙動もおかしくなってしまったのだと思います

SKPhysicsJointFixed の挙動がおかしい

指定したアンカーポイント同士で結合せず SpriteNode が重なったり逆に離れてジョイントするケースがありました
また本来は SpriteNode が上に重なるはずがなぜか texture を使っているとサイズが小さくなるのか上に乗らずに SpriteNode が重なってしまう現象も確認できました

これらの現象も texture ではなく rectangleOf を使って解決することができました

最後に

SKPhysicsBody を使う際のポイントを紹介しました
自分はなるべく rectangleOf を使うようにしています
特にゲームのコアとなる部分では texture は使わないようにしています

個人的に一番困ったのが texture を使うことによる端末ごとの挙動が異なる点でした
初めは SpriteKit の座標情報が実機とシミュレータで異なるのかなーと思っていたのですがそういうことはなく物理エンジンの作り方が悪かったというか物理エンジンの作り方に端末間で差異があるということがわかりました

もしかすると SpriteKit のバグで今後修正されることがあるかもしれませんが、それでも texture を使った当たり判定や結合処理などはやめたほうが無難かなと思います

2019年12月4日水曜日

1 年間ドルを 20 ロット持ち続けた結果

概要

米ドル/円を一年間持ち続けてどれくらいスワップが貯まったか紹介します

スワップ

541,860 円
1484 円 / 1 日

ポジション

2018/12/03 113.5144円

含み損

-953,400円

なのでスワップと合わせて 50 万ほどのマイナスがあります

感想

基本は指値を入れて放置してたので特に運用はしていませんでした
ロスカットもなかったようです
もう指値が刺さるまではホールドしようかなと思います

ドル円は安定している感じがあるので長期投資のスワップ狙いであればありかなと思います

UIView のダークモード対応

概要

UIView を Storyboard 上でダークモード対応させる方法を紹介します

環境

  • macOS 10.15.1
  • Xcode 11.2.1 (11B500)

System Background Color を選択する

Storyboard 上の Background のところで「System Background Color」を選択しましょう

ずっと「Default」で良いのかと思っていたのですが UIView や UIScrollView は Default ではダメで「System Background Color」を選択しないとダークモードに対応してくれませんでした

参考サイト