2017年に利用した継続課金サービス

r7さんらの振り返りがおもしろかったので自分も書き出した。

medium.com

medium.com

継続しているサービス

dアニメストア

5,184 JPY/year

過去作から最新作までたくさん配信されているのでなにか見たいな〜という時に便利。

最近はテレビ放映とタイミングを揃えて配信される作品が増えたのでほんとうに良い時代になった。

今は京都という割と地上波のチャンネルに恵まれた地域に住んでいるけれど、地元は北海道なので深夜アニメがまったく見れずに悲しい思いをしてきたので、地域差が縮まるのは歓迎。

配信の仕組み自体は素朴という印象で、AmazonプライムビデオやNetflixと違いビットレートを調節してバッファリングの時間を減らすとかそういう取り組みはしてなさそうなので、ネットワークの品質に問題があるとストレスを感じることもある。

Amazonプライム

3,900 JPY/year

お急ぎ便などなどに使っている。あとプライムビデオのラインナップが絶妙で、dアニメストアと補完しあったり昔見たおぼえのある映画をたまに見ている。

GitHub

9,492 JPY/year

いつのまにかDeveloper planだとprivateリポジトリの上限がなくなってますます便利になった。

スケッチとかIntelliJの設定 (自動でコミットされるのでまずい内容が出てしまわないか心配なのでprivateにしている) などとりあえずprivateでも作っておけるという安心感を買っているようなもの。

IIJ mio

26,640 JPY/year (6GB ライトスタートプラン)

数年前にauからMNPしてずっと使っている。京都で生活していると人が多くて遅いというようなこともなく快適。

もともと3GBのプランだったけれど旅行で外に出る日が続くとすぐにクーポンを使い切ってしまうので6GBにした。

WiMAX 2+

44,352 JPY/year → ?

一人暮らししてから家の回線はWiMAXを契約しておりその流れで今も使っている。

……が、いまは通信量に上限があり、それはよいとしても課金して制限を解除する道も提供されていないので潮時かなーと思いしばらく立つ。

固定回線は、それはそれで地域において品質の良いISPを見つけること、工事に立ちあう必要があること、などから二の足を踏んでおりいまだにどうしようか考えるがまあいいかな……と思う。

次に引っ越すことがあったら諦めて固定回線を契約すると思う。

Adobe Creative Cloudフォトプラン

11,760 JPY/year

Lightroomなど使うために入っている。

Apple Music

11,760 JPY/year

ポピュラー音楽のラインナップは特に琴線に触れるところはないけどクラシックのラインナップが満足できる。

聞きたいオーケストラの盤が揃っているので好きな時に聞き比べたり参考にできるので気に入っている。

J-WESTカード:JRおでかけネット

1,080 JPY/year

旅行で東海道・山陽新幹線JR西日本の特急に乗る機会が増えたので契約した。

会社で出張するときは会社が契約しているEX-ICで新幹線に乗るのだけれど、あれを知ったら直前まで予約が変更できる便利さなしでは生きていけない。

のぞみに1回乗った時の割引額が1,080円なので1年に2回乗ったら回収できるのでかなりお得だと思う。

あと海外旅行前にVISAではなくMASTERCARDのカードを手に入れる目的もあった。

Netflix

(解約) → 11,400 JPY/year

ヴァイオレット・エヴァーガーデン」「からかい上手の高木さん」の配信がNetflixだけだったので再度契約した。

バッファリングの短さとか視聴するときのストレスのなさは使ったことのあるサービスの中では一番だと思う。

解約したり契約を見直したサービス

さくらのVPS

21,384 JPY/year → 10,692 JPY/year

1GBプランを2つ契約していたけど1つにした。

Elasticsearchとか計算機リソースを使うミドルウェアで遊ぶ時は、リソース単価の安いVPSのほうが使い出がある。

AWS (Amazon Web Services)

16,800 JPY/year → 1,047 JPY/year (予定)

古い写真のRAW画像の保存にGlacierを、このブログなどなどのドメインのネームサーバとしてRoute 53を使っており、これで年1,047円くらい。

……のつもりだったのだけれども、昨年明けに検証のために立てたEC2インスタンスを落とし忘れていて昨年1年間ずっと毎月10USDかかっていたことがわかって慌てて解約した。

MoneyForward

6,000 JPY/year → 解約

家計レポートとか見れたらおもしろいかなと思って契約したけど既に述べたようにEC2のインスタンスを起動しっぱなしで気付かないような人間なので、まずMoneyForwardにお金を払う前にやるべきことがたくさんあることに気がつき解約した。

おわり

EC2インスタンスを起動しっぱなしにする人間は何をやってもダメ。

数字で振り返る2017年

Amazon で購入した金額

金額 前年比
2017 483,040円 124.09%
2016 389,277円 124.54%
2015 312,547円 136.27%
2014 229,352円 -

カメラやレンズなどは含んでいない。主に Kindle 本や生活用品など。

この調子でいくと来年は45万くらい年間で使う目測だけど、そんなに成長するかな、どうかな。

数字で振り返った2016年 - Sexually Knowing

順調に124%成長が続いている、すごい。後で紹介するように給与は毎年110%ペースくらいなので、いつか追い付かれる。

給与

f:id:aereal:20180101215003p:plain

入社して以来、給与明細をGoogle Driveに保存してあり、支給額 (手取り) を12掛けして年俸額とした。
なので年俸額なのにやけにピコピコしている。

営業期が変わるタイミング (1月と7月) に人事評価がありそこで報酬が変わるので、だいたいそのタイミングで大きく変わる。

グレードという給与レンジを定めた概念が全6段階あって、それが変わるとベースも変わるのでそこで大きく変わる要因はそれくらいと見える。
いちおうグレードは役職と関係ないということになっている。

ちなみに控除額も有史以来記録してあり、見るとげんなりするもののひとつ。

写真ブログに投稿した記事数

記事数 前年比
2017 53 72.60%
2016 73 486.7%
2015 15 13.0%
2014 115 -

一転、減ってしまった。1月に大雪があったりクロアチア旅行に行ったり前半はよく撮ったし、後半も撮っていないこともないけれど上げていく気力がなかった。

9月から今もずっと仕事で完全に頭が参ってしまっている。書いていたらなんで仕事に忙殺されてこんな虚しい振り返りをしているんだとイラついてきた。

日記

記事数 前年比
2017 87 55.76%
2016 156 91.22%
2015 171 54.11%
2014 316 -

ほぼ半減した。9月くらいから本当に気が参って「仕事やめたい」とか「1000万ほしい」としか書いてない下書きがたくさんある。

近しい人に読んでほしくないので接続元のIPが地理的に近かったら見れなくするとか、そういうことをしたいな。

むすび

  • 年俸も120%成長させたい
  • 写真のアウトプットもっと増やそう

.devなどのTLDはChrome 63からHTTPSを強要される

その昔Powを使っていた名残で、開発時のループバックドメインに `.dev` をよく使っていたのだけれど、最近うまく動かなくて調べたところ、HTTPSで通信しようとして失敗していた。

アプリケーションでそんな設定した覚えないんだけどな……と訝しんでいたら、どうやらChrome (Chromium) に変更があり先読みするドメインのリストでHTTPSを強制する設定が追加されたらしい。

Chrome 63 forces .dev domains to HTTPS via preloaded HSTS

`.dev` はGoogleによって買われたらしいという話も書いてあって初耳。

それはそうとどうすればいいかというと、テスト・開発用に予約されたTLDがあるのでそれを使うのがよいだろうと上記記事には書いてある。

`.test` や新たに追加された `.localhost` などがそれにあたるので、それを使うのがよかろう、と。

元々予約されているわけでもなんでもなかったのでいきなり壊れても文句は言えないけど、しかしこういう変更入れることもあるんだなーという発見があった。

同じ名前のHTTPヘッダを複数回出力してもよいのか

結論: 値がcomma-separated listと定められているヘッダはOK

同じ名前のHTTPヘッダを複数回出力する、とは

こういう出力:

...
Vary: Accept-Encoding
Vary: User-Agent
...

同じ名前のHTTPヘッダを複数回出力すると、受信者はどう振る舞うのか

RFCより引用:

A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).

RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma.

RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
  • 送信者は値がカンマ区切りリストと定義されていないヘッダを複数回出力してはならない
  • 受信者は複数の同名ヘッダを出現した順にカンマ区切りリストへ結合してもよい

ということが書いてあります。

つまり以下のヘッダ出力があったとき:

...
Vary: Accept-Encoding
Vary: User-Agent
...

……受信者は以下のように結合するかもしれません:

...
Vary: Accept-Encoding, User-Agent
...

mackerel-aws-s3-stats: S3のオブジェクト数とサイズをMackerelに投稿するいいやつ

github.com

いいやつを作った。

AWS SDK for Goを使っているのでIAM roleが適切に設定されたEC2のインスタンス上ならAWSの認証情報は特別渡さなくてよい
(もちろん環境変数で渡してもよい) ので、MackerelのAPI keyとサービス名さえ渡せばすぐに使えます。

さらに `-no-post` でSensu互換形式でstdoutに出力だけすることもできるので、mackerel-agentが動いているホストでmkrがインストールされていればサービス名だけ渡すだけで動くので便利。

mackerel-aws-s3-stats --region ... --bucket ... --no-post | mkr throw --service my-service

f:id:aereal:20171212181401p:plain

f:id:aereal:20171212181405p:plain

どうぞご利用ください。

GAE/GoでNetatmoのAPIから取得した温湿度をMackerelに送るアプリケーションを動かす

GitHub - aereal/gae-go-netatmo-ws-mackerel

f:id:aereal:20171211115645p:plain

冬なのでNetatmo Weather Stationを購入して自宅で動かしはじめました。エアコンをつけるといきなり室温が上がってエアコンはすごいなーということがよくわかって便利。

ハードウェアももちろんWebサービスとアプリもよくできていて、単に現在のデータを見るだけならこれで十分ですが、不快指数を計算したらなにかとアラートを送ったりしたいのでMackerelに投げたい。

ので書きました。GAE/Goで動くやつです。

元々、同僚がGoogle Apps ScriptとAWS Lambdaで動かす実装を作っていてだいたいそれを参考にした。

家で動かすものでメンテフリーにしたく、GASは1週間後読み書きできる気はしないしAWS Lambdaはいいけどもっと素朴なWebアプリケーションで開発したいなと思ったのでGAE/Goで動かしています。

詳しくはREADMEに書いてあるけど、普通のWebアプリケーションとして動かし、GAEのcron機能で定期的にリクエストさせることで定期的にメトリックを送ることができる。

ポイントとしては:

  • GAE/GoはHTTPリクエストの発行にgoogle.golang.org/appengine/urlfetchモジュールを使う必要があるので、外部APIにアクセスするパッケージも対応する必要がある

感想:

f:id:aereal:20171211115813p:plain

  • GAE/Go, 実行環境が特殊なので開発でめっちゃハマりそうでイヤだなと思っていたけど意外とそうでもなかった
    • 上記のようにライブラリにちょっと手を入れる必要があるかも、くらい
    • 対応自体もわりと一般的というかGAE特化というほどでもないので穏便
  • stdout/stderrに出力してもなにも見えなくて、GAEのlogモジュールを使う必要がある
  • cron実行の結果とか500エラーの割合などがGAEのダッシュボードで見れて便利
    • cron実行結果のログはStackdriverで見れてうまく他のGCPサービスと連携してるんだなーと思った

大コンテナ時代を生きのこるためのJSON Schema

実行環境をコンテナ化するDockerが普及して久しく、CIやローカルの開発環境などどこかでコンテナ技術に触れているのではないでしょうか。

コンテナはその性質上、設定のプロビジョニングに古典的な設定ファイル (のパス) 受け渡しが難しいです。etcdconsulのようなKVS (= Key-value store) を用いることもあるでしょうが、素朴には環境変数で与えることが多いでしょう。

HerokuはThe Twelve-Factor Appというパターンを提唱し、その中でStore config in the environmentと述べています。

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

The Twelve-Factor App

参考: Building Twelve Factor Apps on Heroku | Heroku

しかし環境変数グローバル変数なので無闇に参照すれば古式ゆかしきスパゲティコードまっしぐらです。また環境変数の値は文字列として扱われるので表現力に乏しく利用者のために値の定義域を示す必要がしばしば生じますが、どのように行うべきでしょうか?

そんな悩みをJSON Schemaで解決しようという試みを紹介します。

環境変数の値の定義

ある環境変数がとりうる値の形式や範囲を考えてみます。

たとえば真偽値 (boolean) が挙げられます。 DEBUG=1デバッグフラグを立てるような変数です。
1か0か、あるいは値はなんでもよくて定義されていれば真とする場合もありますが、併せて真偽値とします。

あるいは数値 (number) も考えられます。 LOGLEVEL=1LOGLEVEL=7 など、ログ出力を数値で指定するケースがあります。

真偽値と数値を一般化すると列挙 (enum, enumeration) になります。たとえば PLACK_ENV=test PLACK_ENV=production など、文字列として扱われるがそのとりうる値があらかじめいくつかに決まっています。

また特殊な例として複数値 (multiple values) についても考える必要があります。
環境変数は辞書構造なので、ある名前に対応する値はただひとつに定められるため、複数の値を渡したい場合は値をデータ区切り文字 (delimiter) で分割して扱います。

たとえば PATH は値をコロンで区切ります *1

PATH はコロンで区切るというコンセンサスが得られているのであまり問題になりませんが、独自の変数を定義するときに区切り文字は何であるかはいよいよもって明示しなければ正しく使うことはできません。

JSON Schemaの利用

そこでJSON Schemaを利用します。

JSON Schema (JSON Schema Core)はその名の通りJSONの形式を表明する形式で、スキーマに基づいて入力の検証を行うためのボキャブラリを定義するJSON Schema Validationなどの仕様とあわせて利用されます。
以下、CoreとValidationをまとめてJSON Schemaと呼びます。

JSONと名がついていますがあくまでシリアライズ形式にJSONを選んでいるというだけで、利用する上でその他の制約はありません。

JSONとしてシリアライズ可能、すなわちJSONが定義する辞書構造 (object) とコレクション (array) のほかいくつかのスカラ値 (string, boolean, null) のいずれかで表現できる入力であればJSON Schemaで表明・検証できます。

先に述べた通り環境変数は名前と値がそれぞれ文字列である辞書構造なのでJSONとしてシリアライズ可能です。

以下はあるスクリプトが期待する環境変数JSON Schemaの例です:

{
  "title": "Schema of some script's environment variables",
  "$schema": "http://json-schema.org/draft-06/schema#",
  "type": "object",
  "properties": {
    "DEBUG": {
      "type": "string",
      "enum": [
        "1",
        "0"
      ]
    },
    "LOGLEVEL": {
      "type": "string",
      "enum": [
        "0", "1", "2", "3", "4", "5", "6", "7"
      ]
    },
    "PLACK_ENV": {
      "type": "string",
      "enum": [
        "development", "test", "production"
      ]
    },
    "PATH": {
      "type": "string",
      "pattern": "[^:]+(:[^:]+)*"
    }
  },
  "required": [
    "PLACK_ENV"
  ]
}

先に述べたnumberやbooleanを期待する例がJSON Schemaで記述されています。

実際にこのスキーマを用いて検証を行ってみます。

Rubyjson-schema.gemを利用します。以下のGistにコード例を示します:

Gemfile · GitHub

実行結果の例です:

✘╹◡╹✘ < ruby validates_env.rb
The property '#/' did not contain a required property of 'PLACK_ENV'
✘>﹏<✘ < PLACK_ENV=a ruby validates_env.rb
The property '#/PLACK_ENV' value "a" did not match one of the following values: development, test, production
✘>﹏<✘ < PLACK_ENV=development ruby validates_env.rb
✘╹◡╹✘ <

PLACK_ENV=a を渡したらきちんと怒られてかわいいですね。

独自実装を含む他の検証方法に比してJSON Schemaを選ぶ利点はいくつかあります。

  • 相互運用性が高い
    • ランタイムによらず利用できるため、複数の言語を採用している場合に障壁となりません
  • 検証のセマンティクスの一貫性が保たれる
  • スキーマの再配布・拡張が容易
    • たとえば組織内で設定に用いる環境変数を共通化したいとき、あるURLでスキーマを配布・参照することで普及させやすくなるかもしれません
  • JSON Schemaのエコシステムの恩恵に与れる
    • たとえばドキュメント生成が簡単になるかもしれません

一方、物足りないと感じる点としては、enumやpatternプロパティを駆使するほかなく、あまり可読性が高くない点でしょうか。

この点については、JSON Schemaの仕様ではformatプロパティに独自のキーワードを追加・利用することを許容しているため、booleanライクな文字列の定義を追加し、それをformatに指定することで冗長な定義を避けられるかもしれません。

Implementations MAY add custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support this keyword and/or custom format attributes.

JSON Schema Validation: A Vocabulary for Structural Validation of JSON

むすび

以上、設定のスキーマJSON Schemaで記述・検証することでコンテナ時代に即したtwelve-factor appパターンを促進する試みでした。

私はtwelve-factor appの環境変数を推進する姿勢については環境変数の表現力の乏しさを懸念し懐疑的でしたが、JSON Schemaを利用することを思い付いてからは懸念も解消され強く共感します。

既に述べたように独自formatを定義・利用するバリデータがあるとより便利かもしれないという思いもあるので、引き続き検討・導入していきたいところです。


この記事ははてなエンジニア Advent Calendar 2017の8日目の記事でした。

明日 (12/9) はid:ikesyoです、おたのしみに!

*1:ただしUNIX/Linuxにおける場合、Windowsでは異なる

寝て起きる

昨日書いてたコード、テストが落ちるけどわけがわからないので途方に暮れたけど、一晩寝て起きたらもしかしてこうでは? という気付きが得られて、出社して試したらうまくいった。

集中力は単に集中力と言われるのであらゆる対象に対して1つの共有のプールがあって、そこからリソースを奪い合うかのようなイメージだけど、意外とそうではなくて対象ごとにそれぞれプールがあって残量が0になると知性がなくなる、みたいなモデルなのかもしれない。

自分の中に集中力リソースが100あって、好きなタスクに100まで自由に注げるわけではなくて、集中力プールが5つあって、それぞれ20ずつ、みたいなかんじなのかもしれない。

だとすると、ひとつのことをずっとやっても集中できるのは20までなので、効率が悪い。最も効率よく働くには、集中力プールの数だけタスクをかけもちすればよい。

しかし集中力プールの数がいくつなのかは知らないし、使える時間は相変わらず共有リソースなのでどういう順番でやるかを考える必要がある。

あとタスクの進みが悪いときに他のタスクに手をかけるとなんとなく気まずさがある。

この世はままならぬ。

インストールがとても高速化されたcapistrano-strategy-jenkins_artifact 0.4.0をリリースした

GitHub - aereal/capistrano-strategy-jenkins_artifact: Capistrano 2 strategy that uses Jenkins' artifact as a distribution provider.

Release v0.4.0 · aereal/capistrano-strategy-jenkins_artifact · GitHub

capistrano-strategy-jenkins_artifactというgemを作ってメンテしており、これの0.4.0をリリースしました。

Travisのビルドでは最大約30倍速くなりました:

`bundle install` before: 126.69sec
`bundle install` after: 4.22sec

Goodbye jenkins_api_client by aereal · Pull Request #21 · aereal/capistrano-strategy-jenkins_artifact · GitHub

JenkinsのAPIを利用するためにjenkins_api_clientというgemを使っていたのですが、これはXML APIを利用することもあるので依存にnokogiriが入っており、`bundle install` に時間がかかるのがネックでした。

実際にこのgemで利用するAPIJSON APIでまかなえたので、net/httpベースで書き直すことでjenkins_api_client経由のnokogiri依存をなくしました。ありがとうjenkins_api_client.

このgemはCapistrano 2 strategy that uses Jenkins' artifact as a distribution provider.という説明の通り、Jenkinsのビルド成果物を取得するstrategyを提供します。

もともとはてなブログのデプロイ設定のために書いていたコードをgemとして切り出したもので、いまではMackerelなど社内のいくつかのサービスで導入されています。gem化してよかった。

ついでにOSS化したことでテストをちゃんと書こうというモチベーションが高まりお得。

参考: はてなブログのデプロイを約6倍高速化したはなし - Sexually Knowing

ISUCON7予選に秒速5000兆クエリというチームで参加した

ISUCON7 開催&日程決定! #isucon : ISUCON公式Blog

ISUCON7のオンライン予選にid:astjid:tanishiking24の3人で秒速5000兆クエリというチームで出場した。最終スコアは9万ちょっとで、ベストスコアとほぼ同値だったので実力を出し切ったと思う。

ISUCONに競技者として参加するのは初めてで、エンジニアリングにスコアをつけて競い合うというのは聞いていた以上に楽しい。

ちなみに「競技者として初」というのは、昨年のISUCON6の参考実装の移植として関わっていたので、ISUCONと関わったという意味では初ではなかった。

準備

2日前くらいにcatatuy/private-isuで練習した。振り返るとISUCON7の予選問題も画像をいかに効率よく返すかというところが最初のボトルネックで、早速予習が活きてお得。

pt-query-digestを使うとか、nginxのアクセスログを解析してボトルネックを見つけるとか、見つけたボトルネックの解消の分担だとか、タイムキープだとか、一通り押さえておきたいところは練習できたので事前準備は万端と言ってよい。

当日

開始が遅れるとのことだったのでオフィスの近くにあるちょっといい肉料理のお店でランチをいただいた。

肉専科はふう 京都御所南の和牛ステーキを堪能できる洋食のお店

開始してからは、まず3人でレギュレーションの読み合わせをした。予選だけど複数台構成ということでおおっとなる。練習していた時のデプロイは雑にホストに入って `git pull` するだけだったけど、手間とかリスクを考えて早めにデプロイ整備をしようということになった。

ほか、ローカルとグローバルにそれぞれ帯域制限があることなどを確認しあった。この時点で参考実装は読んでいなかったけれどグローバル側が100Mbpsだったので、とにかくベンチマーカーから送られてくるリクエストを減らす = クライアントキャッシュを使うのが肝要というあたりをつけた。

読み合わせが終わってからはid:astjSSH鍵のセットアップなどをしつつ、自分が初期プロビジョニング (mackerel-agentを入れたり、redis, memcachedを入れるなど) やデプロイ準備を進め、id:tanishiking24がkataribeのセットアップをしつつコードリーディングを進める、という分担になった。

レギュレーションを読み合わせましょう、とか、3人がどういう分担になるといいか、とかはISUCON本戦出場経験のあるid:astjに音頭を取ってもらった。普段からオペレーションも得意だしあてにはしていたけど、実際かなり頼りになり助かった。
id:tanishiking24も「じゃあこれよろしく」と振って危なげなく進めてくれるので、チームの並列度はマックスで最高だった。

練習でやったとおりnginxのアクセスログMySQLのslow.logを見てボトルネックを1つずつ潰していく方針で進めた。

id:astjがやってくれたimage.nameにuniqueインデックスを張る変更でスコアが5万くらいに上がってテンションが上がってきたと思う。早いチームは早いうちからスコアを伸ばしていて内心やや焦っていたけど、同じ土俵に立てたことで安心しつつ、競い合えているなーと楽しくなってきた。

その後、N+1クエリを殺すなど分担してスコアをちまちま上げつつ、いよいよアイコンの配信をどうにかしないと帯域で当たってどうしようもない、という状態になって案を考えはじめた。

last-modifiedをつけてconditional GETさせよう、という方針になったのだけど、これはあとから考えると穴がある判断だったし、ハマる原因になってしまったな、と反省。

JSやCSSにはif-modified-sinceは来ているように見えたけどアイコンには来ていないので、last-modifiedヘッダの日付形式がおかしいのではないか、とか、304を返すロジックを間違えているのではないか、とか後から考えれば的外れな検討ばかりして時間が消えていった。たぶん3時間くらい費してしまったと思う。

最後のほうは本当にお通夜で、しかも大差ない変更をしたつもりだけどスコアが5万→3万→2万→3万とよくわからない上下をするので、一層お通夜が進んだ。

だんだん頭がおかしくなってきて、gzip圧縮かけているとstrong etagが毎回変わってしまいそれでキャッシュされていないのでは? ということになりgzipを切るなどしたが、効果はなし。

頭も朦朧としてきてヤケクソになって誰ともなくcache-control max-age=0とかつけてfailしなかったら儲けものじゃない? って話になり、ベンチマーカーを走らせるとなんと6万くらいになった。

その時のid:astjはこんなかんじだった:

                                 ,.へ
  ___                             ム  i
 「 ヒ_i〉                            ゝ 〈
 ト ノ                           iニ(()
 i  {              ____           |  ヽ
 i  i           /__,  , ‐-\           i   }
 |   i         /(●)   ( ● )\       {、  λ
 ト-┤.      /    (__人__)    \    ,ノ  ̄ ,!
 i   ゝ、_     |     ´ ̄`       | ,. '´ハ   ,!
. ヽ、    `` 、,__\              /" \  ヽ/
   \ノ ノ   ハ ̄r/:::r―--―/::7   ノ    /
       ヽ.      ヽ::〈; . '::. :' |::/   /   ,. "
        `ー 、    \ヽ::. ;:::|/     r'"
     / ̄二二二二二二二二二二二二二二二二ヽ
     | 答 |     コ ロ ン ビ ア       │|
     \_二二二二二二二二二二二二二二二二ノ

あとは初期データに含まれるアイコン画像を静的に書き出すのをやって9万 (ベスト値) が出る。……ものの、my.cnfを書き換えてベンチマークを走らせると5万くらいに落ちる→もう一度走らせる→スコア戻らず→変更を戻す……というようなよくわからないスコアの上下が相変わらず発生するので、最後の30分はベストスコアである9万を越えるまでひたすらエンキューする猿たちになっていた。結果、最後の10分くらいでベストスコア近いスコアが出たので、そこで打ち止めとなり終了。

実践できて、次回もやっていきたいこと

  • ボトルネックの解析・発見→修正という基本的なプロセスを回しつづけたこと
  • 30分ごとに現況確認をしあい、ハマるのを概ね防げたこと
  • (良くも悪くも) 普段の自分たちが切れる手札だけを切れたこと、本番一発勝負の必殺技みたいなものはなかった

反省点

  • ベンチマーカーのconditional GETの挙動が不可解だとなったときに、動かす手が止まってしまった
    • 「仕様的には我々は間違っていないはずなのに」となったときに、仕様に照らすのではなく、ベンチマーカーの動きを知るためとにかくあれこれやってみるべきだった
    • 他にボトルネックのあたりはついていたが、帯域で当たっているのでまずアイコンをどうにかしないといけない、けど手がない……ということで3人とも止まってしまった
  • 他の人の感想を見るとgzip_staticとか知らないディレクティブがいろいろあった

感想

普段やっていることに近いし社内の他のチームと感想戦をしあってみて、丁寧な配信最適化をやろうというかんじで、楽しめたし自分たちに足りていないところがあることを痛感させられ、たいへん楽しめました。

悔しくありつつも、初ISUCON参戦で楽しかったので、次は優勝したい。

余談

予選参加することを決めたあとで10月22日に『響け!ユーフォニアム』のコンサートと被っていることに気がついて、慌てて21日の参加で問題ないか確認した時が一番肝が冷えた。

週5日8時間労働は厳しい

しばらく体調が悪く、週末になるとへとへとになる状態が続いている。

土日に休むとリフレッシュできて月曜日には元気一杯になるので、老衰による疲れやすさがあるにせよ、体力の最大値がそんなに大きく目減りしていることでもなさそうなので、今週は午後からの勤務として労働時間をだいたい50%にしている。

そしていまのところ調子がいい。いきなり気温が下がって身体に負荷がかかっているにしては、わりといい調子が続いている。

あとフィジカルというよりメンタルの負荷が大きそうで、午後に出勤するまでのあいだ、家の掃除をしたり洗濯をしたり、あるいはピアノを弾いたり、そういう時間が増えたことも大きいように思う。

つまりそういった家事や趣味をするぶんのフィジカルリソースの消費は変わらずあるものの元気というわけなので、メンタルリソースの消費が激しいという推論。

生涯で得られる幸福の総量について考えると、収入を2倍にするより労働時間を半分にするほうが総量は大きくなりそうだし、健康も保てて寿命が延びそう。

スマートフォンからSlackを消した

休んでいる時にたまに見たりしてしまい無闇に疲れていたので消してしばらく経つ。

緊急の連絡はDMでやりましょうって合意できているし、DMはメールでも通知が来るようにしているので、ひとまず困らないだろうと思っているけど、実際どうかはわからない。

あとグループウェアにも気軽にアクセスできないようにしたいけど、それはちょっとめんどうそうで悩む。

休み中に疲れが溜まる要因を減らしていきたい。

『Scalaで自動作曲の練習』を社内勉強会で話した

speakerdeck.com

だいぶ大仰なタイトルでありますが掲題の内容を社内勉強会で話しました。

音楽を作る古典的な方法論 (機能和声) を取り上げ、その中でも和声 (harmony) をコアドメインと見据え、実際に和音進行の規則などを実装したという内容です。

和声と周辺の概念をScalaで表現したコードを交えながら、和音や調・音階をエンジニア向けにどういうパラメーターを受け取ってどのように導出できるか、といった観点で紹介しています。

端折ったりやや正確さに欠ける説明になっているところがあると認識していますが、プログラミングあるいは抽象的な構造とその生成規則を発見するという観点でおもしろさを感じてもらえるようなアレンジです。

紹介したコードは素朴なWebアプリケーションとして実装し、公開しています: GitHub - aereal/music-study

きっかけ

アカデミックな知識を師事したりきちんと学んだことはないのですが、ピアノを弾き始めたころからずっと学んできた分野で、プライベートワークもいくつか作っています。

一方、プログラミングを始めてからしばらくして、ものごとを抽象化して似た特徴や規則を発見するおもしろさを見出してから、たとえば和音の特徴付けは音程 (周波数比) で決まるよなとか、音楽や音楽を作り上げるルールたちをプログラミングや数学の語彙を使って述べ直すことができそうだなということはずっと頭の中にありました。

ちょうど社内勉強会の順番がやってきて、最近は業務に直結した話が多くマンネリを感じていたので、ハッタリを効かせる意味と自分に発破をかける意味で「自動作曲」というワードで取り組むことにしました。

実際にコードを書き始めたのは10日前くらいでいけるやろと思っていたけど後述する点にハマるなどし、動くものができたのはギリギリだったのでだいぶ焦りました。
なにせ発破をかけるために大仰なタイトルをつけたのに、蓋を開けたら動くものはなにもありませんでした、だと顔向けできないので……。

普段の業務範囲からだいぶ離れたドメインを扱うので退屈に感じないかなあという心配もしていたのですが、思ったより反響があったことには救われました。実際、こういうことが考えられるよねという実装を提示してワイワイ議論が起こったらいいなと目論んでいたので、そういった意味では成功したといえます。


難しかったところ

当初は12平均律を前提として、周波数を実装に使っていたのですが数値の精度が足りなくてテストが落ちはじめた時は、進まない進捗と共に絶望的な気持ちになりました。

Rationalに切り替えていくのも大変だったので、動くものを作ることを重視して、物理的な実装に寄せる作戦は諦めました。

また種々の概念は一見すると規則的で実装しやすく見えたのですが実際はそうでもなく、ある言葉が指す概念が非常に曖昧あるいは広すぎてユビキタス言語を発見するのに戸惑いました。

たとえば音程の完全1度、短2度、長3度、増1度みたいな名前は、一見すると「修飾子」+「N度」という構造をとれるのではないかと思うのですが「N度」という概念は五線上の距離を指す一方、修飾子は半音上げたり下げたりといった音高に作用するものなのでドメインが異なり表現が困難です。

音程は結局、半音の数で表すこととし、半音の数が6つの場合はDiminishedFifth, AugmentedFourth, あるいはTritoneという名前で参照できるということにしました。

12平均律が前提であればこれでよいのですが、音律に依存せずN度の表現ができると望ましいと感じているので今後改善していきたいところです。

今後の展望

Web Audioなどを用いて実際にこのソフトウェア実装から生成した和音進行を耳にできるようにして、そこから実装されていない規則を追加していきたいですね。

また、和声といいつつ和音進行しか実装できていないので、せめて声部配置くらいは実装したいし、できていて然るべきかなと思っています。


プレゼンテーション内で短三和音を誤って「長三和音」としていた点を修正しました。

リモート勤務メモ

社内グループに書いていたメモをせっかくなので放流します。

前提

  • 昼食はオフィスで食べられる
  • 基本はオフィス勤務だが、相談の上リモート勤務も可能
  • 自宅からオフィスには徒歩で20分、自転車で10分
  • 京都在住
  • 北海道の実家で2週間程度のリモート勤務を2回経験

リモート勤務の感想

  • お昼ごはんの用意をしていると昼休みがあっという間になくなる
    • 普段オフィスにいるとランチをいただくのに20〜30分くらい、残りは休憩スペースで同僚と話したり本を読んだしている
  • お昼休み・定時になるとチャイムが鳴るが、自宅だと鳴らないのでしょっちゅう時計を気にして疲れる
  • 途中までSlackで参加していた会話が口頭に変わると経過がわからなくなるので、あとはうまく話が進んでいることを祈るしかなくなる
    • いまのチームに慣れたからいいけど、入りたてとかだと不安だと思う
  • 人と関わりがなくて気が滅入ってくる
    • 普段、人と話すわけではないけど同じフロア・同じオフィスにたくさん人がいて、なんとなくワイワイしているのを感じるだけでけっこう満足していることがわかった
  • 椅子がしょぼいオフィスチェアで自宅勤務2日目で身体中が痛くなってきた
  • 外部ディスプレイなくて効率落ちる気がする
  • 顔を合わせるMTGの時、こっちはHangoutで1だけど、向こうは会議室で複数人いるという状況だと、1対多という状況に言い様のないストレスを感じる
  • 設計の相談とかするときにホワイトボードが使えないのけっこう不便
    • 手書きしたメモをSlackに上げたりとかしていた

結論

リモート勤務するなら本格的にディスプレイや椅子を揃えて環境を作らないと自分はやりづらいということがわかった。

あるいはMacBook1枚とインターネットさえあれば砂漠でも仕事できるという強靭な心身を手に入れるか。

あと通勤が苦ではなく、むしろデスクワークに終始しがちな毎日において貴重な身体を動かす機会と捉えていた節がある。

天候が悪かったり、どうしても自宅にいない用事が発生したら、柔軟に自宅で勤務できる会社なので、いまのところ自分はリモート勤務そのものに対するこだわりは無いかなあと思った。

むしろオフィス勤務だと福利厚生としてディスプレイとかいいオフィスチェアを用意してもらえるので、そういう点を考えると自宅勤務はけっこう非効率だなあと感じた。

追記

リモート勤務メモ - Sexually Knowing

リモートワークなのにオフィス時間割に合わせてる????

2017/08/29 17:28
b.hatena.ne.jp

労働形態の話と勤務地の話は別なので、コアタイムがある時は勤務地がどこであろうと合わせるべきと思います。

という形式的な話もありつつ、物理的に同じ空間にいないからこそ朝に挨拶するなどして不在かどうかを発信することも、同じ空間にいない時に他のメンバーに不安を与えないために重要だと思って時間は特に意識して守るようになりました。

#builderscon tokyo 2017で『Goで実装する軽量マークアップ言語パーサー』というトークをしてきた

Goで実装する軽量マークアップ言語パーサー - builderscon tokyo 2017

buildersconは初参加。ぼちぼちパーサーを書いていたのでいい機会だと思って応募し採択されてこの度初ビルコンで話してきた。

トークについて

60分枠でひとりで話すのは初めてで時間配分にとても悩んだ。なんとか20分×3みたいな構成にしようと思ったけど前半は抽象的な話が多かったので眠くなってしまったかもしれない。

仕事とは関係なく作り上げたものについて話をするのは、ずいぶん気が楽だし自信を持てることだったなあと思い出した。仕事は自分ひとりの成果といえるものはごく少ないし、自分は抽象的な話をするのは苦手だ。

聞いたトークについて

特におもしろかったトークについて。

まず、基本オフレコなので感想を書けないのがとても残念だけど、オフレコという縛りがあるのも納得の前夜祭のトークはどれも強烈だった。

DeepLearningによるアイドル顔識別を支える技術 - builderscon tokyo 2017

id:sugyanさんのアイドルの顔認識の話。

アイドルの顔の系統が似通っていて識別が大変という話がおもしろかった。たしかに年代が近くその時代でかわいいとされる顔立ちの人がなるものと考えると頷ける。

自撮りの角度が決まっているのでそれを学習してしまいたまに違う角度で写っていると判別できないことがあるという話を聞いて、いわゆるハナザーさん (花澤香菜) アングルがある話を思い出した。

小さく始めて育てるコンパイラ - builderscon tokyo 2017

id:rhysdさんのコンパイラを作っていく話。多相型の推論アルゴリズムがいくつかあるということも知らなかったのでまさに「知らなかった、を聞く」だった。

おもしろそうだったので自分もコンパイラを書いてみたい。

buildersconについて

コピー通りWeb系に囚われないトークがたくさんあって刺激的だった。あとスピーカー弁当はじめ供出いただいたフード類がおいしくて嬉しかったです。次もなにか話したい。

あとめっちゃいい杓文字いただけました。

https://www.instagram.com/p/BXU1ew_BrgP/
😹 #builderscon