読者です 読者をやめる 読者になる 読者になる

15 min/d

ぼうずやのにっき

Android アプリ開発中……

疲れている。今日の Android の知見。

  • ダイアログは Dialog クラスを new & show すると表示される
  • AlertDialog.Buildernew & setTitle & setMessage … & createAlertDialog をつくれる
  • DialogFragment を継承した Fragment をつくると良い
  • ViewPager は入れ子にできる
  • FragmentPagerAdapter は思ったように Fragment を破棄しないので、getItemId などを継承して状態別に id を変えると良い。
  • Fragment を入れ子にした場合の FragmentManagergetChildFragmentManager を使う
    • Fragment 内で Fragment を使う場合のための private な FragmentManager を返す
  • Intent の Flag 次第で Activity A -> Activity B -> Activity C と複数開いた状態から一気に Activity A に戻れる (startActivity & FLAG_ACTIVITY_CLEAR_TOP)

いたるところで、どう書くべきか迷う。たとえばひとつの Fragment で複数の Layout に対応したほうが簡潔な気もするのだけど、 ButterKnife に邪魔される。

2017-W20 ふりかえり

2017-W20 をふりかえる。

2017-05 の目標

  • [x] iOS アプリをつくる (ストアには公開しない)
  • [x] Haskell でなにかつくる

2017-W20 の目標

  • [ ] Haskell で画像アップローダーをつくる
  • [ ] アンダースタンディングコンピュテーションを読み進める

まったく計画どおりでない。先週に続き、業務の都合。 ErgoDox EZ については収束している。

今週の記事

先週は ErgoDox EZ のことばかりを書いていたけど、先週・今週を通してだいたい Ruby on Rails を使っていた。ようやく v5 へ。週末には Android をはじめた。やるべきやりたくないことをやっていくだけではつらいので Amazon ECS / AWS Lambda などを試している。

つくったもの

2017-05-15/2017-05-21

cookie-storage の v3 と bbna の Butter Knife 導入だけ。

その他

業務。 ErgoDox EZ を業務でも使いはじめた。なんとか使えるようになってきた。ストレッチも指示通りにしており、腰の痛みはマシになっている。

業務時間については、進捗が悪い(そもそも計画の時点でひとりの一ヶ月の作業が一人月を越えている気が……)ので、今週はさらにひどくなりそうだ。そも、今日も出勤している。

いろいろなものを諦めて、来週は Android のことを書いていくつもりだ。

2017-W21 の目標

  • Android アプリ開発で気づいたことを書く

Android の Butter Knife をためした

Android の Butter Knifebouzuya/bbna で使ってみた。

Butter Knife は field や method を View に binding するためのライブラリ。 bbna は blog.bouzuya.net for Android 。 blog.bouzuya.net の Android クライアント。

試してみたんだけど、 bbna だと画面項目が少ないので、そこまで恩恵は得られていないと感じる。行数的には bind / unbind 呼び出し分だけ増えている。嫌いなダウンキャストが減るのはうれしいけど、代わりに嫌いなアノテーションが増えるので……。命令的ではなく宣言的になる感じ。

private Button mButton;
mButton = (Button) findViewById(R.id.button);

上記が下記のように変わる。

@BindView(R.id.button)
Button mButton;
ButterKnife.bind(this);

reflection の都合だろうか、 private が外れる。

古いものだと指定された ID の view を探して field に設定している。新たなものだと bind する view ( ID ) をメタ情報として付与しておき、 bind のタイミングでそれら設定するようになっている。

しばらく使ってみる。

Ruby なのに Java のライブラリを使えと言われた

AWS Lambda 便利だ。急に Ruby から Java のライブラリを使わないといけなくなった。

そこで AWS Lambda に Java のライブラリに登録し、それを Ruby から AWS SDK for Ruby 経由で呼び出す。

Ruby 側の雰囲気は↓のような形。

# ぜんぜんわからないけど雰囲気で書いた Ruby のコード (動かしてない)

require 'aws-sdk' # v2

# invoke('super-function', 'special-version', { param1: 123 })
# => { ... }
def invoke(fn, qualifier, event)
  access_key_id = ENV['AWS_ACCESS_KEY_ID']
  secret_access_key = ENV['AWS_SECRET_ACCESS_KEY']
  region = ENV['AWS_REGION']
  credentials = Aws::Credentials.new(access_key_id, secret_access_key)
  client = Aws::Lambda::Client.new(region: region, credentials: credentials)
  response = client.invoke({
    function_name: fn,
    invocation_type: 'RequestResponse',
    log_type: 'None',
    client_context: nil,
    payload: JSON.generate(event),
    qualifier: qualifier,
  })
  JSON.parse(response.payload.string)
end

エラーチェックとかしていないので雰囲気だけ。まじめにやるならリファレンスを見ると良い。

http://docs.aws.amazon.com/sdkforruby/api/Aws/Lambda/Client.html#invoke-instance_method

Java 側は面倒くさいので書かない。

急に謎の力が働いて「 Java のライブラリで処理しろ」ということになったら、 AWS Lambda でごまかせるかもしれないという話。

CloudFront の署名付き URL を避けた

S3 と同じ調子で CloudFront の署名付き URL を使おうと思ったのだけど、ルートアカウントでのキーペア作成や 90 日更新が要求されていたので使うのをやめた。

Amazon S3 では事前に指定したポリシーで署名付きの URL を発行できる。たとえば、一定期間だけその URL を知るユーザーに特定のキーへ特定サイズのファイルの書き込みを許可できる。要するに S3 に直接ファイルをアップロードしてもらうことができる。同様に一時的な参照も許可できる。

S3 で十分なことが多いのだけど、キャッシュもそうだし、独自ドメインでの https にしようとすると CloudFront 経由にする必要が出てくる。

CloudFront 経由にすると URL が変わってしまうので、試していないが、署名付きの URL はおそらくうまく動作しない。そこでより外側の CloudFront の段階で署名付き URL を発行したくなる……。

理由は知らないが、 CloudFront の署名付き URL は S3 のものとは異なり、ルートアカウントでのキーペアの作成が必要だ。一般的に AWS は権限を絞った IAM ユーザーで操作する。ルートアカウントで事故が起きると大惨事になる。可能な限り避けたい。

今回はもう妥協して、推測しづらいキーで S3 には保存し、不要なら削除する対応へと切り替えることにした。

bouzuya/cookie-storage 3.0.0 をつくった

bouzuya/cookie-storage の 3.0.0 を公開した。

Proxy が有効な環境において、storage[key] のような形での property アクセスに対応した。

ぼくが作成したわけではなく、そういう Pull Request が来たので、ぼくは Merge して公開しただけだ。

Proxy をはじめてまともに使った。別の object への proxy となる object をつくれるわけだけど、 property の定義と同様に細かいところを考えるのが面倒だなあって印象。


忙しい。しばらく忙しい。

疲れている

疲れている。火曜日で既に。

ErgoDox での独自の配列 (自身で設定した) にもすこし慣れてきた。まだ従来の速度には届かないものの既に姿勢は良くなっている。

従来型のキーボードだと体の前方で両手を寄せることになる。これが前かがみな姿勢につながっていた。セパレート型のキーボードだと体の前方には出すものの両手を寄せる必要はない。これによって胸を張った (?) 肩を開いた (?) 姿勢での入力がしやすくなる。可能性を示唆する程度の控えめな表現にしたが、ぼくに限れば劇的な変化が起きている。ぼくはそもそも姿勢の問題につながっているという認識さえなかった。キーボードを変えてみて分かったのはあれが手錠のようなものということだ。ぼくは縛られていることにさえ気づいていなかった。

腰の痛みをなくすという目的やそのための姿勢の改善という方向に照らすと、 ErgoDox の購入は既に目標を達成できているのかもしれない。またしばらく様子を見て書く。