為さねば成らぬ

retia.verno@gmail.com

dagger hiltを試す

Android

背景

Daggerのサポートライブラリが出ていた。 以前から仕事等で使っており、依存性解決がビルド時に行われdagger起因のランタイムエラーが起こらないのが好みだったが、やはりわかりにくさが一番のネックだった。設定に追記はできるけど新しく書き直すのができない感じ。

課題

使いやすくなったとあるがどの程度使いやすくなったか、試してみる

参考

aakira.app

実装

詳しくは参考先に任せるとして、ViewModel Injectionが出来る最小の実装を示す。

buildscript {
    dependencies {
        classpath 'com.google.dagger:hilt-android-gradle-plugin:2.28-alpha'
    }
}

allprojects {
    repositories {
        maven { "https://androidx.dev/snapshots/builds/6550871/artifacts/repository/" }
    }
}
apply plugin: 'dagger.hilt.android.plugin'
apply plugin: 'kotlin-kapt'

dependencies {
    implementation 'com.google.dagger:dagger:2.28'
    kapt 'com.google.dagger:dagger-compiler:2.28'
    implementation 'com.google.dagger:hilt-android:2.28-alpha'
    kapt 'com.google.dagger:hilt-android-compiler:2.28-alpha'

    implementation 'androidx.hilt:hilt-common:1.0.0-SNAPSHOT'
    implementation 'androidx.hilt:hilt-lifecycle-viewmodel:1.0.0-SNAPSHOT'
    kapt 'androidx.hilt:hilt-compiler:1.0.0-SNAPSHOT'

    
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0'
    implementation 'androidx.lifecycle:lifecycle-viewmodel-savedstate:2.2.0'
}
@HiltAndroidApp
class ImasRadioStationApplication : Application() 
@Module
@InstallIn(ApplicationComponent::class)
class AppModule {

    @Provides
    fun provideString(): String {
        return "hogehoge"
    }
}
class MainViewModel @ViewModelInject constructor(
   val text: String,
    @Assisted private val savedState: SavedStateHandle
) : ViewModel()
@AndroidEntryPoint
class MainActivity : AppCompatActivity(R.layout.activity_main) {
     private val mainViewModel by viewModels<MainViewModel>()
 
}

雑感

  • めちゃくちゃ便利。今までよくわからなかったComponentが定義されており(ApplicationComponent等)、さらにボイラープレートもほぼannotationだけで良くなった
  • 基本dagger好きだけどKoinのようなわかりやすさにだいぶ難があったので他人に進めたりプロダクトに入れづらかったけど、このくらい楽に扱いやすいならおすすめしたいくらい
  • 早くstableほしいです

リリースしようとしたらネイティブサポートが減っていた

Android

背景

Google Play Consoleからアプリのアップデートをリリースしようとした

課題

警告が出ていて、よく見ると前回のapkからネイティブサポートの値が減っている(mips)

f:id:verno3632:20200602003146p:plain
before
f:id:verno3632:20200602003150p:plain
after

このアプリの対象端末数は変換がないのでおそらくリリースに影響はないだろうが、本当に影響がないか調査する

調査

developer.android.com

注: これまで NDK は ARMv5（armeabi）、32 ビットおよび 64 ビットの MIPS をサポートしていましたが、こうした ABI のサポートは NDK r17 で削除されました。

gihyo.jp

2011年頃には，携帯端末への進出を狙い，AndroidでもMIPSを搭載するタブレットが一時的に存在していましたが，いまやその影をみることもありません。 おそらく現在使われているmipsのAndroid端末はないだろう。

qiita.com

アプリの対応abiは、apkをunzipした lib 以下に入っているみたい。

実装

今回のリリースで入った変更なので、どこのコミットで消えてるかを見ればわかるはず。

  1. 前回のリリースから、マージコミットの最初のコミットを一覧する git log ${last_version}.. --first-parent --oneline 
gggggg Merge pull request #7
ffffff Merge pull request #6
eeeeee Merge pull request #5
dddddd Merge pull request #4
cccccc Merge pull request #3
bbbbbb Merge pull request #2
aaaaaa Merge pull request #1

  1. だいたい真ん中のコミットをチェックアウト git checkout dddddd

  2. apk生成 ./gradlew assembleRelease

  3. apkの中身を見る unzip -l app/build/outputs/apk/production/release/app-release.apk | grep lib/

2184400 00-00-1980 00:00 lib/arm64-v8a/libRSSupport.so 72000 00-00-1980 00:00 lib/arm64-v8a/librsjni.so 70192 00-00-1980 00:00 lib/arm64-v8a/librsjni_androidx.so 1783824 00-00-1980 00:00 lib/armeabi-v7a/libRSSupport.so 59888 00-00-1980 00:00 lib/armeabi-v7a/librsjni.so 54256 00-00-1980 00:00 lib/armeabi-v7a/librsjni_androidx.so 1504188 00-00-1980 00:00 lib/x86/libRSSupport.so 57956 00-00-1980 00:00 lib/x86/librsjni.so 65288 00-00-1980 00:00 lib/x86/librsjni_androidx.so 1475264 00-00-1980 00:00 lib/x86_64/libRSSupport.so 67912 00-00-1980 00:00 lib/x86_64/librsjni.so 74256 00-00-1980 00:00 lib/x86_64/librsjni_androidx.so

以上を2分探索で繰り返し、どこでmipsが消えてるかを探す。

結果、とあるライブラリのアップデートでで消えているのに気づいた。 さらに調べると、そのライブラリの依存しているライブラリが、minSdkVersionが9から14に上がっていた。おそらくこれだろう。

まとめ・考察・雑感

  • ネイティブサポートが減っていたら含まれるライブラリアップデートも考慮して、minSdkVersionの変化がないかを疑う。
  • 古いサポートが切られた結果apkサイズが若干減った。これは古いライブラリを新しくすることにより起こることもあるので、ライブラリのアップデート積極的にやりたい。
  • そもそもmips のAndroid端末のリストが全く出てこなかった。

Format /topics/topic-name is deprecated. Only 'topic-name' should be used in subscribeToTopic.

Android

Logcatに出るメッセージ。 FirebaseMessaging.subscribeToTopic/unsubscribeFromTopicのトピック名に/topics/ のprefixをつけるなということらしい。 ちなみにこれらメソッドの頭で

   public Task<Void> subscribeToTopic(String var1) {
        if (var1 != null && var1.startsWith("/topics/")) {
            Log.w("FirebaseMessaging", "Format /topics/topic-name is deprecated. Only 'topic-name' should be used in subscribeToTopic.");
            var1 = var1.substring(8);
        }

なので、 /topics/ を外しても挙動に変わりはなし。

PxViewer開発終了のお知らせ

PxViewer

長らく開発を続けていたPxViewerですが、本日サポート終了することを決定いたしました。

なんで?

ログインできないというお問い合わせをいただいておりましたが、pixivのログインのロジックが変更になりその修正が難しくなったためです。

この変更ではpixivのWebログインにreCAPTCHA v3が導入されていました。PxViewerではアプリ側でスクレイピングを行いデータを取得していましたが、この方法ではJavascriptを実行する必要があるreCAPTCHA v3を突破するのは難しいと判断しました。

他に方法はないの?

Play Storeを見ると今でもサードパーティのpixivアプリが存在しています。 おそらくですが、これらはPxViewerとは異なり、pixiv公式アプリで使われているAPIを利用していると考えられます。 これらのAPIを使えばPxViewerでも今まで通りの機能を提供できるかもしれませんが、アプリの大部分を書き換えなければなりません。

そもそも最近では機能開発できておらず、使えなくなるレベルの構造変化があった時のみ直すという対応でした。 今回のpixiv側の変更はセキュリティ強化であり、今後もこのような変更やスクレイピングが困難になることが予想され、 ここらが潮時だろう、と考えました。

終わりに

Androidが出て比較的初期の方にリリースすることができ、多くの方々に使用していただきました。 第一目的は自分が使いやすいものを作る、でしたが競合が少ないので多くのユーザーを獲得できるのではという打算的な面もありました。

Twitterなどから頂く声、要望、カンパ、どれも非常に開発の励みになりました。

Google Play Storeに載せられなくなり野良アプリになってからも、ユーザー数がそこまで落ちないことに驚きました。 笑ったのは中国語対応した改造版を作ってまで使っていただいたことでした。

今までご利用いただき、本当にありがとうございました!!

[GW] エンジニアリング組織論への招待 1,2章

書評

目次から

人間の脳内の話っぽい。 気になるのは

  • 論理的思考の盲点
    • 論理的思考は基本となるけどそこにはどう突っ込むのだろう
  • 不確実性と夏休みの宿題
  • 問題の解決よりも問題の明晰化の方が難しい
    • エンジニアの仕事は問題解決というけれど、問題を見つけるのが難しいよなぁとは思ってた

メモ

  • 理不尽や感情の対立は人間の思考の中にバグが含まれているような状態
  • エンジニアリングとは一体なんなのか
    • 何か役に立つものを実現していく学問
    • 曖昧さを減らし具体性・明確さを増やす行為
    • どうしたら効率よく不確実性を減らしていけるのかが重要
  • 不確実性=エントロピー
    • 確率が偏っているほど不確実性の量は減っていく
    • 不確実性の量の差が「情報」
    • 不確実性を減らす = 情報を生み出す
  • 無意識にわからないものに向き合うことを避けてしまう習性がある。それが不安
    • めっちゃわかる
  • 論理的思考の盲点
    • 人が介在することで感情的にどうしてもなってしまう部分がある
    • 自分・人が論理的でなくなる場面を知った上で問題解決に挑む
  • 3つの思考
    • 論理的思考の盲点
    • 経験主義と仮説思考 -システム思考
      • 正解を自分で設定する
  • 仕事の問題を学力テストに置き換える
    • 変換できれば簡単なはず
    • 難しいというのは正しく変換できていない
      • どういう問題で
      • どういうのが正解なのか
      • が明確になっていない
  • 人間が正しく論理的に思考するためには
    • 認識が歪む場面を知り、事実を正しく認知する
  • 4つのイドラ(錯覚や認識の間違い)
    • 種族のイドラ
      • 人間が本来持っている性質から生じるもの
      • 遠くにあるものが小さく見えるとか
    • 洞窟のイドラ
      • 外の世界を知らずに一般的なことだと決めつけて理解することから生じる
      • 自分がそうだから他の人もそう,とか
    • 市場のイドラ
      • 言葉の不適切な使用から生じる
      • 噂話やデマ
    • 劇場のイオラ
      • 伝統や権威を無批判に受け入れてしまう
      • 偉い人の言っていることは正しい
  • 認知の歪み
    • ゼロイチ思考
    • 一般化のしすぎ
    • すべき思考
    • 選択的注目
      • 人は見ないものしか見ない
    • レッテル貼
    • 結論の飛躍
      • 既読スルーを嫌われたと感じてしまう
    • 感情の理由づけ
  • 認知的不協和の論理
    • 自分の感情や行動の矛盾を解決するために認知を歪めること
  • 怒りが発生している時は「自分」「自分の大切にしているもの」に被害が及びそうだと感じている
    • 何が大事なのかを知る機会になる
  • 被害が及びそうな時に本能的に怒るのではなく、悲しみとして伝える
  • 問題解決より問題認知の方が難しい
    • 認知の歪みがあるから、正しく認知することが難しいということ
  • 経験主義は、わからないを行動に変換し、一歩でも正解にたどり着くための思考の補助線
  • プロフェッショナルであればあるほど、不確実性を最初きに下げていることを心がける
  • 経験主義とは単にやってみなければわからない、というものではない
    • 知識=経験を行動によって手に入れる
    • 行動できることは何か/行動の結果起きたことを観察できるか
  • 他人のスキルや考えは観察できない= コントロールできない
    • 他人の行動は観察できる
  • コントロールできるものを操作し、観測できるものの結果を見て、物事を前に進める
  • 仮説思考
    • 演繹的・帰納的には導くことができない、直感や閃きによって生まれる跳躍
  • 不確実性が高いプロジェクトには、仮説が検証できるまで大きな投資はしない

    1-6

  • ビジネス全体の関係は、資産をビジネスモデルに変換し、増加した資産でさらにビジネスモデルに投資するというフィードバックサイクルのシステム
  • 仕事において、どのようなフィードバックサイクルが存在するのかを見つけていくことが重要な考え方
  • 同じ目的を持つ人同士が提案で対立している時は、それぞれが見ているものが違う可能性がある。一つ上からシステム的に、全体的に見る必要がありそう
  • 視野・視座・視点が問題解決のための眼になる
    • 視野 広い狭い
      • ある問題はある大きな問題に包含されていて〜的な
    • 視座 (=だいたい、会社でどの立場で問題を考えるか) 高い低い
      • 高すぎても抽象的になるし低すぎてもミクロになる
    • 視点 鋭い・凡庸
  • 対立に見える問題を、対立にならない全体像をあぶり出すことと、その解決を個人の問題でなく関係性の問題に変換して問題を発見すること

1-7

  • 組織における理不尽の増幅
    • 情報の非対称性
      • 情報伝達が不完全なことに、害意や悪意を感じてしまいがち(ハンロンのカミソリ)
    • 限定合理性
      • それぞれが合理的な行動をとったとしても全体で不合理になってしまう
  • 情報の透明性
    • 情報を公開するだけでない
    • 必要な情報が正しく伝達されるように努力し、何かわからない決定があってもそれは聞いてみようという関係性を作ること

2-1

  • コードレビュー
    • 「自分はこっちの方がこういう理由で良いと思うけど」
  • 自立型人材
    • 今より良い状態にするためにどうしたらよいか
    • 自分自身の思考の範囲を狭めた世界で考えることが心地よくなってしまう
  • HRT (謙虚、経緯、信頼)
    • 上司部下では難しい
    • メンティが自尊心高くても難しい
  • メンターとピアメンター
    • メンター
    • ピアメンター
      • 尊敬できるとまではいかないが数年上の先輩
    • 課題を指摘するのではなく、課題に一緒に向きあい成長を支援する
  • 成長の階段
    • 階段を認識させる
      • 「階段があるよ」ではなく「足元は大丈夫?」
    • 梯子をかけてあげる
    • 階段を登りたくさせる
  • 自己説得
    • 質問を投げかけることで自分で気づかせる
  • 悩む
    • どのように考えれば良いかを指し示して、次の行動を促す
    • メンティが「行動できていない時」に、メンターは「悩み」を聞き出し、気づきを促して「考える」に変える必要がある

2-2

  • 「問題を解決してあげよう」ではなく「モヤモヤしていない問題」に変換してあげよう
    • モヤモヤしていない問題=明確に次にすべき行動がわかる
  • 傾聴で「相手のコップを空にする」
  • 傾聴
    • 「相手の」感情への共感を言動で表す
    • 「相手の」話の内容を「可視化」する
    • 「相手の」思考の「盲点」を探索しながら質問をする
  • 話を聞くのが上手い人は「相手のそばに立って話を聞いている」という言外の信号を常に送っている
    • しぐさ・うなずき・座り方
      • スマホいじりながらとかx
      • 真正面は緊張する
    • 表情
    • あいづち
      • 感情的な表現をした時、感情に関わる箇所のみをリピートする
  • 問題の可視化
    • ホワイトボード・ノートに書き出したり、ものを配置することで第三者目線になる
    • 同じ感情を繰り返す時は「〜が不安」とホワイトボードに書いてしまう
  • 悩んでいるという状態は次が不明確
    • 選択肢
    • 比較軸
    • 評価方法
  • 認知フレームを発見するワード
    • こちら系
      • 同じ側にいるように思われるが自分は同じではないと感じる
    • あちら系
      • 自分達と大きく同じくくりにいるはずなのに自分達とは明確に違う
    • 極端系
      • 0/1で認知している
    • すべき系
      • すべきという思考の枠組みの中で考えようとしている
    • 決めつけ系(どうせ、違いない)
  • 前提の確認と取り外し
    • 問題視している点具体的に聞く,解決策の束縛条件を聞く
    • その上で、その前提がなかったらどうだろう?と質問する
    • 前提の優先順位を問う
  • 課題の分離
    • あなたにとって具体的に何が問題か
    • あなたがコントロールできるものは何か
    • どうなればその具体的な問題は解消されたといえるのか
  • メンターはメンティの問題を自分の課題として捉えてはいけない

    2-3

    1on1では心理的安全性を下げることが大事なんだな

  • ラーニングゾーン
    • 対人リスクを適切にとって、問題と自分達という構図が生まれている状態
  • ストーリーテリング能力
    • メンターとして、「ダメで失敗もしたけれど、そこからこういうことを学んで、こんな風にしたら、うまくいって成長できた」
  • アクノレッジメント
    • 存在承認
      • あいさつ、前に行っていたことを覚えている、様子を見て肩を叩いて励ます
    • 行動承認
      • ポジティブな行動をそのまま伝えてあげる
    • 結果承認
      • 出来上がったものについて感想を言う、褒めるも含まれる
  • メンターからメンティーにフィードバックを求める = 承認
  • 当たり前のことを意識してやる
    • ちゃんと挨拶する
    • 無視しないで話を聞く
    • 相手に感謝を伝える
    • 気にかけて話しかける
    • 自分本位でなく相手本位で話をする
  • ストーリーテリング
    • 自慢話にならないように
    • 悩みと、その解消までの過程を話す
    • その時の感情を自己開示
  • ジョハリの窓
    • 開放の窓を広げる
    • 「他人はわかっていない」には自己開示
    • 「自分はわかっていない」にはフィードバック

      2-4

  • SMART
    • Specific/Measureable/Achievable/Related/Time-Bound
    • メンターとメンティで次の行動を合意する時満たしているか確認する
  • わかった？は聞かない
    • 試しに一人でやってみて・代わりに自分の言葉で説明してみて
  • 能力は習慣の積分、習慣は行動の積分
  • ある行動・習慣が取れない時
    • 行動を促進する力を行動を阻害する力が上回っている
    • 促進する力の要因には、フィードバック機会を増やし適切に承認する
    • 阻害する力の要因には、環境や構造を変えるための行動をする
  • ゴールへのTime Machine
    • 高いゴールを持ち、その「未来」から見て、現在から未来までの道筋が見える状態

[GW] エンジニアリング組織論への招待

書評

動機

GW中に読むぞ！！！

エンジニアリング以外にマネジメント的な部分も求められるようになり勧められたので。 1日1章ずつはこなしていきたい。

目次を見て

脳内->人->チーム->チーム->組織 と、だんだん範囲が広がっていってるのがわかる。 目次から気になった章を上げていく。

  • 不確実性
    • タスクの見積もりの不確実性に悩んでいる
  • 問題解決より問題認知の方が難しい
  • メンタリング
    • 一番気になってるところ
  • なぜ行動を起こせないのか
  • アジャイル
    • 趣味では個人開発、前職はインフラ、現職はチームだけどほぼ1人で回しているためアジャイルをちゃんと勉強してこなかった。
  • 技術組織の力学とアーキテクチャ
    • 社のエンジニア組織を考えるようになったので多分いちばん効きそうなやつ

ほめる技術

書評

買った動機

社会人歴も長く、自分の技術だけを見てもいられなくなってきた感。 先日も評価というほどではないが同僚の最近の仕事を言語化して引き出すようなことをやっていて、全然うまくできなかったこともあり、 どういうところにほめるポイントを見いだせるのかを知りたかった。

今後行動しやすいようにまとめる。

4つのタイプ

人は4つのタイプに分けられる

  • コントローラー
    • 行動的で、自分が思った通りに物事を進めることを好む
    • こちらの話が少しでも長くなると、多少のいらつきが顔に現れ、先を急がせようとする
  • プロモーター
    • 自分のオリジナルなアイデアを大切にし、人と人気あることをすることを好む
    • よく話す。話の展開が早い。
  • サポーター
    • 人を援助することを好み、協力関係を大事にするタイプ
    • いわゆるいい人。話を傾聴してくれ、質問に対し正しい回答を返そうとする
  • アナライザー
    • 行動の前に多くの情報を集め、計画を立てるタイプ
    • 話をするときは慎重に言葉を選ぶ

そしてタイプ別に効果的なアクノレッジメントがある。

  • コントローラー
    • ほめすぎはコントロールしようとしているのではないか、と疑われる
    • その人自身ではなく、チームのメンバーの働きや雰囲気をアクノレッジする
    • その人が決めた目標を達成した瞬間にニュートラルにアクノレッジする
    • 「きついこと」(欠点)を単刀直入に伝える
  • プロモーター
    • とにかくお世辞でもいいから褒めまくる
  • サポーター
    • 自分のした仕事に対して無意識に相手に代償を求める
    • 仕事を振ったらどんな小さいことでもアクノレッジする
  • アナライザー
    • 具体的にどの部分が良かったのかを明示する

相手にあったコミュニケーション

  • 若い人
    • 単に命令するだけでなく理由も伝える
  • 新しい部下
    • その人への期待と不安を正直に伝える
  • 年上の部下
    • なるべく「相談」する
  • 上司

メモ

以下メモしたポイント。

Youのスタンスから〜つまり、あなたの行為、存在はこのように素晴らしいと相手に伝えることです。
〜
Iで承認するというのは、相手位の行為、あるいは存在そのものが、自分に対してどのような影響を与えているのかを言葉にして伝えることを指します。

これは自分にとっては結構楽になる。 自分は適当なことは言いたく無い(本書でのアナライザータイプ)だから、Youのスタンスで褒めるとしても相手をちゃんと知らなければいけないとなかなか伝えられない。 Iで承認するのであれば、自分の本当の心からの言葉なので紡ぎだしやすい。 出てこない場合は…そもそもそういう人は褒める場面ではなさそう。

一方的なアドバイスにはアクノレッジメントがありません
〜
教えたい、自分にはそれだけの知識があることを誇示したいという、アドバイスする側のニーズを満たしているに過ぎないことが多いのです。

知識の顕示欲はめっちゃある。 僕はこう思うけれども、君はどう思う?と問いかける。

向こうが投げたボールに対して、そのボールをすぐに返す、というのは相手に対するアクノレッジメントとなります。

返信めっちゃ遅い癖どうにか直したい。。。

だからこそ頻繁に伝えましょう。「今こうしているね」と。

相手を穴があくほど観察して、みたまま聞いたまま伝えてあげるだけ。

意見を求めるというのは、その相手に対する大きなアクノレッジメントです。

インターン生がきた時とか。もっと聞いてみてもよい。

そこにはゲストを大切にしようというウィルがあります。
だからこそ毎回の挨拶がアクノレッジメントになるのです。

挨拶一つ取っても、自分から行う(=ウィル)ものなのか、ひとからやらされるものなのか。

人心掌握に長けた人はこの別れ際の一言がものすごく上手いのです。
すきあらば人のアクノレッジメントをしようと思って行きている人と、いつ自分はアクノレッジメントされるんだろうとずっと待ってる人と

自分は後者。基本沈黙を選びがちで、アクノレッジするのもされるのも無いことを前提をしている。 それでもされるとやはり嬉しいので、後者を選んでいるということだろう。