Screaming Loud

研究・プログラミングなど気づいたことをメモをしています。読書記録はこちらに記載しています。https://bookmeter.com/users/75944

Androidのlibraryを作成していて発生するInnerClass annotations are missingの対処

問題

AndroidのLibraryを作っていると必ずといっていいほど、proguardをかけると思います。 ただライブラリを作ったときにinner classを作っているファイルをproguardのkeep対象にいれてjarを作成すると、 そのライブラリ使用時に下記のようなWarn文言が発生してしまっていました。 ググっても全然出てこなかったのでハマりました。

InnerClass annotations are missing corresponding EnclosingMember annotations. Such InnerClass annotations are ignored.

対処法

その際の対処法はproguardの設定ファイル、proguard-rules.proに以下を記載したら治りました。

-keepattributes EnclosingMethod, RuntimeVisibleAnnotations, RuntimeVisibleParameterAnnotations

おまけ

上記エラーに関しては上のattributesだけで対処できますが、そもそもinnerclassを使っている場合は、以下を追加するのがベターですね。 特にAndroidはinner classを多用すると思うので、気をつけたいです。

-keepattributes Exceptions, InnerClasses, MethodParameters, Signature, EnclosingMethod, RuntimeVisibleAnnotations, RuntimeVisibleParameterAnnotations

参考

ProGuard manual | Attributes | GuardSquare

Karabinerでいつの間にかemacsキーバインドが帰ってきた!

ついにあのKarabinerがHighSierraでもつかえるようになっていた!!

ということでメモ。

まずKarabinerElementsをアップデートします。

以下すでにルールを追加済みですが、新規の方は空なはず。 f:id:yuutookun:20180222110001p:plain ここからルールを追加します。

ElementsのバージョンからはWebでruleをダウンロードするようになっています。 f:id:yuutookun:20180222110133p:plain

ここをクリックすると、以下にジャンプするので、ダウンロード。 Karabiner-Elements complex_modifications rules

自分はemacs配列なので、

  • Emacs key bindings
  • Change caps_lock key

をimport。

あとは、以下2つを有効化 f:id:yuutookun:20180222110437p:plain

KarabinerElementsを有効化すると、ネイティブのcaps_lockの入れ替えが効かなくなったので、KarabinerでCapsの入れ替えを追加で行うようにしました。

これでついにCtrlで動ける生活が戻った!

Karabinerのダウンロードはこちらですね。

Karabiner - Software for macOS

ドキュメントを書くときに気をつけていること(開発)

アキレス腱を切ってしまい、入院している@moc_yutoです。

今回はフォーマットがバラバラになりやすいドキュメントに関して書きます。

ドキュメントとは

ドキュメントは非同期で知識を共有するための大切なツールです。 引き継ぎ、新メンバーなど知識共有の効率をあげるための必需品です。

エンジニア界隈だけでなく企業で仕事をしている場合であれば、必ずと言っていいほどドキュメントは書くでしょう。

その際、両者にとって不幸にならないドキュメントとはどういうものでしょうか? 自分が書いている場合のドキュメントのフォーマットをまとめます。

自分が主にドキュメントに書く内容は以下3点です。

  • 背景
  • 目的
  • 詳細

内容について

背景

ドキュメントにおいて、一番重要だと思っています。 作業手順でない限り、基本的には必ず背景をいれています。

たとえば、画面の表示制御のためのフラグを単独で別テーブルで管理している場合があります。 コードやDBスキーマを読むだけでは、わざわざ別テーブルにしてる理由がわかりません。 しかしここで背景を書いておけば、そのフラグは一時的なもので一定期間でそのフラグを消すため、変更しやすいように別テーブルに置いている。などと分かります。

目的

これも背景に近いですが、ドキュメントを書いているのであれば、何かを説明しているはずです。

その説明するものは何のためにドキュメントに残しているのか、どうしてこれが必要なのか目的を書くべきです。

詳細

この部分はドキュメントを書くとなったら誰でも書くと思うので、特に留意する点はないかな。 長い文章にするのではなく、簡潔にするくらい。 ここに関しては、コードで補えることも多いので、ドキュメント自体のメンテ性を落とさないようにするために書きすぎないことでしょうか。

その他

章立てはなるべく細かくして、知りたい内容に関して見出しに行けば分かるようにします。

そして、読む人のこともしっかり考えるということも重要です。 読む人はこのドキュメントに何を期待しているんだろうと一瞬でも考えるとそのドキュメントの質はかなり上がるはずです。

まとめ

基本的にコードを読んで分かるというのは挙動だけであって、なんでそういう実装をしたのかはコードのコメントにちゃんと書いてないと分かりません。 ただコードを読むのにも、ある程度負担はかかるし、その概略を自然言語で読めるのであれば、そのほうがいいに越したことはありません。

ドキュメントは詳細に書きすぎなくてもいいが、要点はしっかり書いておくべきです。

参考URL

アジャイル開発「最低限のドキュメントで成功するための3つのポイント」 | tracpath:Works

2017年に読んだ本のまとめ

今年もやっていきます。

昨年のリンクはこちら→ yuutookun.hatenablog.com

今年の読んだ冊数は42冊。 去年と同じくらいですね。

年の後半になって面白いと思う本が減ってしまって本自体の読む量が減ってしまったというのが今年の印象です。

前半のほうは2016年に引き続き、組織をどうするかという話が多かった気がします。 その中でも印象的だったのは、 bookmeter.com

bookmeter.com

です。

働くモチベーションってどこから来るんだろう?みたいなことを考えさせられたものでした。 面白くて社内の勉強会で発表するほどでしたね。 以下そのときのスライドです。

How to Build a Team

あとこれは自分の中で久しぶりにヒットした本でした。 bookmeter.com これもかなり面白くて社内の勉強会で発表しました。

スライドはこちら エンジニアのためのマーケティング

このスライドはマーケティングのメディアに何故か紹介されてPVがすごいあがってましたw

あとこれから自分はどうしていくべきなのだろうか?みたいな大きい視野で考える材料になったのは、以下2冊ですね。

bookmeter.com

bookmeter.com

今年は色々モヤモヤ悩んでいたので、上記2冊はいい思考のたたき台になったと思っています。

さて、2018年はどんな本を読んでいこうかな?

読んだ本一覧はこちら moc_yutoさんの読んだ本 - 読書メーター