hamburger-tech

techの話

Manifest merger failed : android:exported needs to be explicitly specified for element <activity#~

社内ライブラリのtargetSdkVersionを30から33に上げたらビルドエラーになった

* What went wrong:
Execution failed for task ':app:processDebugMainManifest'.
> Manifest merger failed : android:exported needs to be explicitly specified for element <activity#${Activity}>. Apps targeting Android 12 and higher are required to specify an explicit value for `android:exported` when the corresponding component has an intent filter defined. See https://developer.android.com/guide/topics/manifest/activity-element#exported for details.

developer.android.com

アプリ コンポーネントに LAUNCHER カテゴリが含まれている場合は、android:exported を true に設定します。他のほとんどの場合は、android:exported を false に設定します。

AndroidManifest.xmlのactivityタグに、android:exported="true" を追加したら解決した。

通知画面の未読・既読はあまり機能していない説

本当は最初に色々書いたけど、収集つかなくなってしまった。なので箇条書きのメモ

  • 通知画面がサービスのタスク一覧の役割を持つことがある
  • 通知は既読管理されていることが多く、その殆どが通知をタップしたかどうかである
  • 通知のタップとタスク完了がイコールであることが少ない。結果、ユーザが求める振る舞いと期待値とずれる
  • 必要なのは通知一覧なのか、それともタスク一覧なのかは立ち止まって考えたほうが良いかもしれない

〇〇-playgroundのリポジトリに書き捨てコードを登録する

課題感

ちょっとしたコードの置き場所がちゃんと定まっていなくて毎回悩んでいた。例えば、

  • webエディタ(Kotlin Playgroundやdartpadなど)
  • gistに登録
  • 専用リポジトリを作る

とか。ただgithubを使わないと後から発掘できなくなったり、新規リポジトリ作るのは書き始めるのに少し時間がかかったりと、コレジャナイ感がある。

同僚とのmtgにて

同僚と画面共有しながらmtgしたときに、保有する個人リポジトリがちらっと見えた。そこには表題のような複数の言語の〇〇-playgroundリポジトリが並んでいて、書き捨てのスクリプトなどが登録されていた。確かにこれなら毎回リポジトリ登録する必要は無いし、後からある程度目星をつけやすくなる。

構成的にはモノリポになるので、もし必要ならコード共有も楽だし、別端末を使うときにクローンも楽。良さそう。

flutter-playgroundを作ってみた

作ってみた。Flutterの何かを試すときに入れることにした。

github.com

手始めにuiウィジェットを試すプロジェクトを登録した。デフォルトのボタンとかテキストテーマとかを試せているので、色々発見があった。

着手するハードルが下がったはずなので、今までよりはコードを書く頻度が増えると良いなぁ。

「SOFT SKILLS」を読んだ

CAREER SKILLSと一緒に購入していた。事前知識がなかったので、コミュニケーションの仕方とか昇給の方法とかそういった内容だと思っていた。

前半はどこかで聞いたりCAREER SKILLSと重複していたりで結構飛ばしながら読んでた。後半に行くにつれ独自トピック感が出ていて、最終的に評価がひっくり返った。最後まで目を通していてよかった。

レーニングはしておいたほうが良いんだろうな・・・

著者がそういう属性の人だということは差し引いても、自分も運動しようと思える内容だった。適度にデータを提示しながら(やりすぎるとクドくなる)、体を鍛えることでプログラマーとしてのレベルアップに繋がるというストーリー。

プログラマーを想定して書いているので、必要以上に鍛えたり頑張ったりすることを推していないのがいい。ガジェット紹介とか、アフィリエイトリンクが貼ってあれば購入していたかもしれない。

自然とシステム改善に近い部分があるなぁというメンタルになって、気がついたら体組成体重計を買ったり1日のスケジュールにトレーニング時間を組み込んだりしていた。読書に偏っていた自覚はあるので、いい機会だしハードウェア部分のトレーニングをちゃんとやることにする。

ポジティブな方が良いんだろうな・・・

そもそもポジティブな人はプログラマーにならないだろうという偏見がありつつ、これも考え方次第だしやっていき!という感じ。

元々学生時代に何度か性格が変わったような時期があって、自分の考え方を変えた結果だったことを思い出した。なので、思い込みや思考フローを調整する効果の大きさは身を持って実感している。

30年以上生きていると自分のセルフイメージは固まってきていて、自分の限界やどうせオレなんて感もかなりある。が、その状況を認知できたなら改善できるはずで、まさしく脳のプログラミング・リファクタリングだなぁと思う。デバッグしつつ、version2,version3を目指す。

今までは自信がポジティブに繋がるんじゃないか?という考えで知識をつけようとしていた。けど、先にポジティブになるという選択肢を考えたことがなかったので、自分の人生にかなり影響を与えるかもしれない。

プロとして振る舞う

単発で刺さったフレーズがいくつかあって、それはプロの開発者として正しい行いをしようというものだった。

  • 一貫した正しい行動を取る。その行動に対して責任を持つ。仮に正しくない行動を求められたとしても、それに従っちゃだめ。拒否することで別の信用を得られる
    • 難しいのが、その正しさが勘違いだったとき。自分の判断の正しさを保証できないので、バランスをとったりフィードバックを受ける仕組みがあったほうがいいかも
  • スペシャリストを目指しつつ、効率改善の過程で他の技術も学ぶ。繰り返し実施したり、時間がかかっている作業は良い題材になる
    • ジェネラリストの方が働く場が増えるかもしれないが、体は一つなんだからスペシャリストになって十分に高い報酬を得られる会社一つ見つけられれば良くないか?というのが著者のスタンス
  • 上司とは無駄に対立するのは避ける。意見を伝えた上で、服従するかその場を去る。

もし半年後自分がポジティブマッチョになっていたら、完全にこの本のせい。そうなれたら説得力がありそうなので、周囲にアフィリエイトリンクを送りつけようと思う。

「CAREER SKILLS」を読んだ

35歳目前を控え、キャリアどうしようかな~という状態。引退説はどこに行った?

他者からどう見られるか?は意識しておけ

人がその人に持つ印象は無視できない要素。立ちふるまいも見た目も、少しは気にしておくほうが得。

評価されて職位が上がるということは、それにふさわしいと認められること。自分の職位の2つ上くらいの上司をイメージし、その人を真似してみる。

アウトプットは継続が大事

普通に仕事をしているだけでは、いずれガラスの天井にぶつかる日が来る。それを解決する手段として筆者はブログを勧めている。ブログで継続的に価値を提供することで、社会的な評価を得られることがある。その社会的な評価こそが、報酬を上げるためのカギとのこと。

ブログは小手先の工夫をするよりも、継続が大事らしい。継続とは、週に1~3記事を1年以上投稿し続けるのがベース(1年では足りないかもしれない)。文章の上手い下手は書きながら上達すれば良さそう。

何をテーマにするか?は難しそう。ある程度絞ってその分野でトップになれるようなものを選ぶのが良いそう。これは学生時代の研究テーマ選びに似たような考え方かもしれない。

スペシャリストになれ

ジェネラリストはスペシャリストになれないが、スペシャリストはジェネラリストになれる、という理論をベースに話が展開されていて、納得した。

スペシャリストになるためにはその分野や周辺技術の深い理解が必要。もしスペシャリストがジェネラリストとしての振る舞いが求められたときは必要な知識を学習できるはずで、対応できる。

また、ジェネラリストが本当の意味でのジェネラリストになれるのか?という点も興味深い。というのも、現代の技術は多岐にわたっていて、そのすべてを網羅することは現実的に不可能になっている。ジェネラリストと言ってもその領域の技術の一部しか習得していない場合が多い。

自分が何か課題を見つけたとき、その解決はスペシャリストにお願いしたい。ジェネラリストを求めているのは、全てに精通したスペシャリストを集めるのが難しいというネガティブな理由が多い気がする。そんな現実的な議論をつなぎ合わせていくと、どう考えてもスペシャリストを目指すべきだろうという結論になる。

実際自分がスペシャリスト寄りでは無いので耳が痛いが、今からでも何ができるか考えたい。

ジェネラリストの価値

logmi.jp

(書籍を)たくさん読んだり、たくさん実践したりしていると、そこでいろいろな話をつなげやすくなるんですよね。相手が見たいビューに自分が名前を付けることができるかもしれないというのがあったりして、そうするとすごく場が盛り上がって、それでどんどんこうやっていこうみたいになります。

実践経験だけだと、仕事になった時にスケールしないんですよね。人にやり方を伝えられないんですよ。ストーリーでしか言えないし、一緒にやることでしかできないんですが、そこでこういった理論や、モデル化されたものがあると、人に伝えやすいし、その人が1人で学習しやすくなるんですよね。

学習の内容より学習習慣を先に考える

課題を見つけたらWhatを考えがちだけど、長期スパンになりそうなら先にWhenを決めたほうがいいんじゃないかと思ってきた。

大げさなロードマップ実現が無理ゲーなのとか、リソース不足が原因だったりするし。

2年前に子供を保育園に送ってから業務開始までの2時間で毎日なにかすると決めたら継続できるし成果も出るようになった。技術書を読んだり気になった情報を試してみたり。最近はトレーニングとか英語学習とかも挑戦してる。


今関わっているプロダクトのインプットが足りないと感じていて、一朝一夕にはできないだろうし先に時間確保してみた。

ちまちま学習しながら自分をアプデしていきたい。