bouzuya.hatenablog.com

ぼうずやのにっき

dotenv-to-json をつくった

bouzuya/node-dotenv-to-json をつくった。

これは標準入力から dotenv の内容を取り、標準出力から JSON を返すコマンドだ。インストールは npm i -g dotenv-to-json だ。使用例は↓のとおりだ。

$ echo 'foo=bar' | dotenv-to-json
{"foo":"bar"}

普通にありそうだけど、見当たらなかったので自作した。

これがあれば jq との組み合わせでいろいろできる。ぼくがこれを欲しかったのは AWS Serverless Application Model (SAM) の設定ファイルの Environment を後から埋め込むためだ。それはまた別で書く。

ちなみに、これはわりと npx 向けっぽい。

$ echo 'foo=bar' | npx -q dotenv-to-json
{"foo":"bar"}

2017-W29 ふりかえり

2017-W29 をふりかえる。

2017-07 の目標

2017-W29 の目標 とその記事

目標。

  • ☑ bouzuya/bs-code 1.5.4 のことを書く
  • ☐ bouzuya/bs-android 1.0.0 をつくる
  • ☑ 早起き・ストレッチ・トレーニングをする

記事。

先週に続き bouzuya/bs-android の 1.0.0 をつくるつもりだったけど、できなかった。前進しているのだけど、テストコードのところで詰まっている。割り込みで AWS Lambda 関連の調査が入ったのもある。このように優先順位が下がると、もう完成しない気もする。

AWS Lambda 関連の調査ついでに、 AWS のリソースを整理している。長期間の放置でゴミが多い。先週の Heroku に続いて……という感はある。整理して金銭の浪費を減らしたり、 AWS の知見は業務で役に立つので、それが本流からの脱線であることを除けば悪くはない。

つくったもの

2017-07-17/2017-07-23

ほぼ何もつくっていない。 mr-jums は Dockerfile が壊れていたのを直して、 beater 5.x に変更した。

その他

AWS Lambda の調査で自身の無知を感じている。もっと知り、うまく使っていきたい。この件が片付いたら bs-android, mr-jums と出していきたい。

2017-07-20 にも書いたが、なわとびをしている。妻と一緒に習慣化している。続けたい。

もう夏休みの雰囲気だ。周囲の空気はスプラトゥーン 2 になっている。今回はパスするので、たまっているあれやこれやをなんとかしたい。

2017-W30 の目標

  • AWS Lambda での何かをつくる

AWS Lambda まわりのあれこれを調べつつ迷う

2017-07-21 にも書いたとおり Serverless Framework を試している。

ぼくは AWS で使用する気なので、ドキュメントを見ながら進めると、どうやら Administrator としての権限を要求している。

To let the Serverless Framework access your AWS account, we’re going to create an IAM User with Admin access, which can configure the services in your AWS account. This IAM User will have its own set of AWS Access Keys.

Note: In a production environment, we recommend reducing the permissions to the IAM User which the Framework uses. Unfortunately, the Framework’s functionality is growing so fast, we can’t yet offer you a finite set of permissions it needs (we’re working on this). Consider using a separate AWS account in the interim, if you cannot get permission to your organization’s primary AWS accounts.

https://serverless.com/framework/docs/providers/aws/guide/credentials/#creating-aws-access-keys

「そりゃないだろ」と最小の権限を模索してみたものの、書いてあるとおり厳しいと分かったので、諦めてアカウントを切った。

アカウントを作成する過程で知ったことだけど、いつのまにか AWS Organizations というサービスができている。以前から料金を別のアカウントに束ねることはできたが、いまはアカウントの作成までできるようになっているようだ。ふむ。

あとこれもいつからか分からないけど、 IAM のコンソールで古いアクセスキーやパスワードが注意されるようになっている。そもそも未使用の IAM user も居たので、この機会に削除した。

正直なところ、このように脱線してほとんど進んでいない。

一歩もどって、いまやろうとしていることやその状況をメモしておく。

ある小さなアプリケーションの移植をしようとしている。その実行環境として ECS か Lambda を考えている。ランニングコストの観点で Lambda が良いと思っているのだけど、一方で Lambda の際にどうつくっていくのかがあまり確立できていない。そこでフレームワークを見てみよう……といった次第だ。

いま試そうとしているのは次のとおりだ。

絞り込むどころか昨日より候補が増えている気もする。並びが妥当なのかよく分からない。ほしいのはフレームワークというか作り方の目安というか……。

まだ Serverless Framework しか見ていないのだけど、どれも共通しているのは設定ファイルをもとにインフラを整える形で、コマンドラインツールを提供していることだ。

SAM はパッケージ形式を定めたものっぽい。極端な話、 CloudFormation のテンプレートをアプリケーション向けに特化させて、書きやすくしただけな印象。 AWS CLI が食えるパッケージ形式だ。

これは直接的に競合するわけでもない。たとえば Serverless Framework には SAM の形式で〜というプラグインっぽいものもあるみたいだ。コマンド体系の合わないところがあるはずなので、そうする意味はよく分からないが……。

Apex はあくまで Lambda の操作に特化しているみたいだし、それ自体に golang を選択し NPM の依存を排しており、他の言語も使えることを前に出している。ただ、 Serverless Framework ほど気の利いた形にはしていなさそうだ。「気が利く」というのは往々にして「余計なことをする」を意味するものなので、難しいところだ。

いろいろ組み合わせて実現するくらいなら……という気持ちもあるので、いまのところ SAM に従いつつのオレオレでいいかなという気持ちだ。

みかんの缶詰 / Serverless Framework

みかんの缶詰を食べた。冷凍したあと、自然解凍して、風呂上がりに食べる。

今週でこれが二回目だ。一回目は自然解凍の時間が短かったため、食べるのに手間取ったが、二回目はうまくいった。しゃりしゃりとちょうど良い食感だ。

間に一度「黄桃」をはさんだのだけど、あれはだめだ。「みかん」のほうが良い。黄桃では甘すぎる。甘いばかりでだれてしまう。みかんは適度に酸味があるので良い。一缶を食べても飽きが来ない。また、ひとくち大で食べやすい。

毎日は体に悪そうなので、二日で一回にとどめている。飽きないように三日で一回でも良い。頻繁に買っても、市販のアイスに比べると安いのも魅力的だ。

難点は缶の始末だ。とにかく邪魔だ。


わけあって Serverless Framework を試そうとしている。ざっと見た感じ yamlCLIAPI Gateway + AWS Lambda を操作するだけっぽい。新規作成はともかく、更新時にどうなるのかが気になるところ。

Apex も見てみるつもりだ。

mockito / なわとび

RxAndroid と mockito をうまく使えないでいる。

次のような subscribe が返す Disposabledispose できているかのテストを書こうとして、うまく書けなかった。

class Klass {
  Observable observable; // T とか書いていないけど、雰囲気ってことで……。
  Disposable disposable;
  Klass(Observable o) { observable = o; }
  void subscribe() { disposable = observable.subscribe(/* ... */); }
  void dispose() { diposable.dispose(); }
}
@Test void test() {
  Observable observable = mock(Observable.class);
  Disposable disposable = mock(Disposable.class);
  when(observable.subscribe(any())).thenReturn(disposable);
  Klass klass = new Klass(observable);
  klass.subscribe();
  klass.dispose();
  verify(disposable, times(1)).dispose();
}

雰囲気で書いているので正確ではない。↑における↓の位置で例外が投げられる。 subscribenull を受け取っているというものだ。

when(observable.subscribe(any())).thenReturn(disposable);

mockito の挙動を正確には知らないのだけど、↑のように書ける時点で実際の subscribe は呼び出していない……。そう考えていたのだけど、なぜ実際の subscribe の引数の検査に引っかかるのか……。よく分からないが、こんなところで時間を浪費したくないので、無視して進める。


なわとびをした。 200 回ほど素直に跳んだら、ふくらはぎがぱんぱんになった。

体調不良 / 散髪

体調不良。朝のつらさは冷房のせいだろうか。ここ数日で暑さが限界に達したので冷房をつけている。冷房をつけて寝るとどうにも調子が悪い。午前休のあとで出勤した。

髪を切った。定期。前回は 2017-07-05

Fragment を使わなくてもうまくやれるのだろうか

Fragment を使わない派の記事をまた見ている。

普段お世話になっている各種ライブラリでおなじみの Square は Fragment を使わないと宣言している。いまでもそうなのだろうか。

ちなみに、ぼくはこの記事を 2015-04-11 にブックマークしている。そのときも何か Android アプリに着手するきっかけがあったのだろう。覚えていないし、そのときよりも詳しくなっているはずなのだけど、いまでも自信を持って「 Fragment は要らない」と言い切れないで居る。初心者は易しいと言い、中級者からは難しいと言う的な何かがあるようだ。

体感として Activity や Fragment あるいは Android Framework から提供されるあれやこれやは Activity や Context に縛り付けるものが多い。画面などにべったりと結びついてしまうイメージだ。たとえば Loader や Task は要らなかった。使わなくて済むなら使わないほうが良いと感じている。

今回の bs-android で挑戦するかは分からない。


帰りにファイル立てを買った。なぜか会社でぼくの席にはそれがない。