ようこそ！！

openapi-generator で Kotlin コード吐く時の enum

yaml にどう定義されているかにもよるけど、たとえば ruby とかの慣習で小文字で書いておこう、というのがありそう。

enum:
  - red
  - blue
...

これをそのまま Oepn

enum をどういうフォーマットにするかは enumPropertyNaming で設定できるので

openapi-generator.tech

ここで Kotlin らしく

Enum classes | Kotlin Documentation

UPPERCASE を指定すると良さそう。

additional-properties に渡して指定できるので、以下のように指定できる。

openapi-generator -g mysql-schema -o out -i spec.yaml --additional-properties=identifierNamingConvention=snake_case,useSingleRequestParameter=true,withInterfaces=true,enumPropertyNaming=UPPERCASE

Android Studio の Spelling 設定の共有は dic で

Android Studio で、typo 警告を抑制したいことがある。

例えば、これは明らかに自社・他社で運営しているサービス名なのに、そんな英単語がないということで怒られてしまうパターンがあると思う。

単独開発をしているなら Spelling に個人の辞書だけホワイトリストとして追加したら良いけど、チームで開発しているとこのホワイトリストを git で管理したくなる。

二つ方法がある。

.idea/ 配下に設置される yml を改造する

なんとなくこの方法が広まっている気配を感じる。 qiita.com

DroidKaigi のリポジトリにも存在しているのが確認できる。 github.com

Pros

  • DroidKaigi リポジトリに同等のものがあるので、コミュニティにも認知された使い方に則っているとは言えるかもしれない。

Cons

dic ファイルを使う

pleiades.io

Pros

  • Android Studio の設定画面にちゃんと表示される
  • dic ファイルを編集したら即座に反映されるので、Android Studio の再起動が必要ない
  • 改行コードで区切るだけのルールなので追加が容易

Cons

自分はdic ファイルを使うのがおすすめで、仕事でもこちらを採用している。

プログラマが知るべき97のことを読んだ

今更感。

www.amazon.co.jp

もう何年も前に買っていたものを読んだ形。もっと早く読めば良かった。とはいえ、エンジニアになってすぐに読んだとしてもピンと来なかったかもしれない。

この本にはエンジニアとしてどう振る舞えば良いかという記述がずらっと並んでいて、以下が特に良かった。

  • 04: コーディング規約を自動化する
    • コードの私物化を防ぐ
    • Lint などの仕組みで規約を設ける
  • 06: リファクタリングの際に注意すべきこと
  • 08: ボーイスカウト・ルール
    • きた時よりも美しく。
  • 14: コードレビュー
    • 友好的に。相手が辛い気持ちにならないように。お菓子を食べながらレビューするというのは良さそう。
  • 24: 変更を恐れない
  • 26: 言語だけでなく文化も学ぶ
    • 言語の思想を知れ。それが良いコードへと繋がる。
  • 29: DRY 原則
    • Don’t Repeat Your Self。コーディングのみならず、全ての業務に対して言える。
  • 41: 無駄な警告を排除する
    • 警告を無視するな。これは最近の業務でもバグを生んだ事例であった。
  • 42: コマンドラインツールを使う
    • IDE が裏でやっていることを理解しよう。コマンドを理解しよう。そうすれば自動化も容易くなろう。
  • 43: プログラミング言語は複数習得すべき
    • 1年に1つ新しい言語をやってみよう。
    • 様々なパラダイムを知ろう。例えば関数型言語を習得することで、手続型言語に活かせるかも知れない。
  • 57: ポリモーフィズムの利用機会を見逃さない
  • 58: テスト担当者はプログラマの友人
    • 当然そうだろうと思っていたけど、改めて認識した。
  • 61: ビルドをおろそかにしない
    • Androider だったら、適当に書いた gradle で満足しない、かな
  • 71: パフォーマンスへの道は地雷コードで敷き詰められている
    • ソフトウェアメトリクスを活用してみよ。
  • 74: 「イエス」から始める
    • 頭ごなし否定しない。
  • 79: テストのないソフトウェア開発はあり得ない
    • 言うまでもないことだが、できていない実態がある....
  • 80: 1 人より 2人
    • 一人で黙々とやってソフトウェアを構築し「俺はすごいプログラマだ！！」となる時代はとうの昔に終了。
    • 他者と連携して成果を上げてこそ。ペアプロしよう。
  • 82: 他者への思いやりを意識したコーディング
    • Umuntu ngumuntu ngabantu
    • 道徳っぽい
  • 87: プログラマとテスターが協力してできること
    • テスターから達成に必要な項目をまず貰う、っていうのは良さそう。
  • 10: 名前重要
    • 名前ですごく悩むことが昔多かった
    • 名前が難しい局面は大抵名前をつけようとしている対象そのものが微妙な時なんだよな

少なくとも読んだ前と後では、これらの内容よって自身の意識と振る舞いが変わっている、と思う。 これまでやってきておらず、気がつかされた内容もあるし、なんとなくやってできているつもりでも、こうやって文字で読んだ結果、やっぱり一部不足している部分に気がつくことができて、それを埋める振る舞いを心がけている。