フレッツ光 "隼" とプロバイダ

まえおき

引っ越した。

マンションタイプのが安いよーってNTTのほうから提案があったので、それに乗り換えた。

開通工事が終わって、ネットが繋がった。

・・・あれ?

今までつかってたルーターのままでは繋がらなくなった。

・・・試しに、みんな大好きWindows PCからルーターを介さずPPPoE接続を試みた。

Connection failed 651

・・・。

・・・・・・・

おかしい!!

悩んだ3時間

最初はNTTに騙されたのかとおもったけど、ルーターのログを見るとconnectは完了してCHAPでコケていた。つまりプロバイダがおかしいということになる。

とはいえ、プロバイダは何も変えていない。

かれこれ3時間くらいパスワード変更してみたりルーターの設定変えてみたりいろいろやった。

・・・つながらん。

解決!

だめもとで、Windowsの接続エラーのぐぐってみた。

「gmobb 651」

f:id:YusukeIwaki:20180228023046p:plain

【GMO】GMOとくとくBB総合 その10 [無断転載禁止]©2ch.net

ここでようやく という文字が、NTTからの開通のお知らせあることに気づく。

そう、今まで使ってたフレッツ光ネクストとは別物の回線に変わっていたのだ!!

 

ということで、プロバイダの方を の専用のプラン(200円くらい高い)に切り替えてみた

f:id:YusukeIwaki:20180228022434p:plain

 

こうして今おれはブログを書いている。

結論

サービス名、もっとわかりやすくしてくれ

Kotlin歴が1ヶ月で、「あ、これは便利かも」と思えたKotlinの用法

まえおき

Kotlin歴が一週間の自分が、Kotlinのコードをレビューするときに指摘していること - YusukeIwakiのブログ を書いたあと、 id:suzan2go からコメントをいただいて、

Idiomatic Kotlin. Best Practices.

のページの存在を知ることになった。

業務でも「新しく作っていくものはKotlinで!」ってなったので、本格的に触り始めた。実際さわりはじめて「お!これはKotlinがいいかも」って思えてきたものを幾つか紹介してみる。

ちなみになんだかんだでJavaのほうがIDEが(速度的に)優秀なので、わりとJavaで書いてKotlinに変換してるんだけど、それは内緒。

SharedPreferenceをDelegated Propertyでread/writeする

「×ボタンを押したら二度と出さないようにする」みたいな制御をやるときには、かんたんなキャッシュとしてSharedPreferenceをささっと使いたい。ただ、経験上、SharedPreferenceは「ラッパークラスを作れば作るほど複雑化して、結局SharedPreferenceを生で使うのが一番いい」ということになりがちだった。

けど、KotlinのDelegated Propertyで、BooleanPref, StringPref, IntPref, LongPref, ... などなどうっっっっすーーーーーーいラッパークラスを用意してやることで

class HogeCache(val context: Context) {
  private val prefs get() = context.getSharedPreferences("hoge", Context.MODE_PRIVATE)

  var dontShowBanner: Boolean by BooleanPref(prefs)
}

みたいなクラスを作って

class HogeActivity: Activity {
  override fun onCreate(savedInstanceState: Bundle?) {

    ...

    buttonCloseBanner.setOnClickListener { _ ->
      hogeCache(this).dontShowBanner = true
    }

    if (hogeCache(this).dontShowBanner) {
      buttonCloseBanner.visibility = View.GONE
    }

みたいに書けるようになった。

github.com

可読性が上がって良いと思うので、適当にライブラリ化もしてみた。

(世の中には、↑をもっと汎用的にした chibatching/KotPref というライブラリもあったりする)

JSONArray#forEachを拡張関数で定義する

for (int i = 0; i < jsonArray.length(); i++) {
  JSONObject jsonObject = jsonArray.getJSONObject(i);

    ...
}

をKotlinでバカ正直に書くと

for (i in 0 until jsonArray.length()) {
  JSONObject jsonObject = jsonArray.getJSONObject(i);

    ...
}

みたいになる。

悪いコードじゃないんだけど、これでは可読性がやや低いと思う。

fun JSONArray.forEach(action: (JSONObject) -> Unit) {
  for (i in 0 until length()) {
    action(jsonArray.getJSONObject(i));
  }
}

という拡張関数を定義しておけば

jsonArray.forEach { jsonObject ->
  ...
}

のようにスッキリ書けて、可読性が上がる。

まだ試したことはないけど、ViewGroupとかでも同じことが言えると思う。

 

 

まとめ

Kotlinは「○○みたいなときには便利」みたいなしくみがアホみたいにたくさんある。

相変わらずKotlinは嫌いだけど、少しずつ勉強していくと可読性の高いコードが書けるようになっていきそう。

Kotlin歴が一週間の自分が、Kotlinのコードをレビューするときに指摘していること

Kotlin歴1年くらいになったら考えは変わるかもしれないので、Kotlin歴1週間での脳のスナップショットを書き留めておきます。Qiitaとかに書くと「いや、そうじゃないだろ」みたいなのが多数派だとおもうので、とりあえず自分のブログに書いておこう。

?. は3つ以上連続使用しないほうがいいんじゃない?

fragment.arguments?.getString("title")?.toUpperCase()

気持ちはわかるけど、それだったら「nullかもしれない」を排除する方向のコードにしたほうがいい気がする。 なんとなく、本当になんとなくだけど・・・。

スコープ関数は letalso だけ使うようにしましょう & apply は使わないで下さい

HogeFragment().apply {
  argument = Bundle().apply {
    putLong("id", id)
    putString("title", title)
  }
}

よりも

HogeFragment().also { fragment ->
  fragment.argument = Bundle().also { bundle ->
    bundle.putLong("id", id)
    bundle.putString("title", title)
  }
}

のほうが可読性高い気がする。 apply は、IDEの補助がないと、どのクラスのメソッドを読んでいるかを見失う。つらい。

Rubytrytap だけで概ね行けてるんだし、Kotlinだって letalso があれば行けるでしょ?とおもっているけど、違うのかな・・・。

スコープ関数とかブロックをネストするときは it は使わない

Realm.getDefaultInstance().use {
  it.executeTransaction {
    it.where(User::class.java).equalsTo("id", userId).findFirst()?.let {
      it.name = username;
    }
  }
}

だと、it が何を指してるのかパット見でわかりにくいので、

Realm.getDefaultInstance().use { realm ->
  realm.executeTransaction { realm ->
    realm.where(User::class.java).equalsTo("id", userId).findFirst()?.let { user ->
      user.name = username;
    }
  }
}

のようにレシーバーを明記しよう。 主語のない文が連続してる文章が読みづらいのと同じで、引数がないブロックが連続してるのもつらい。

スコープ関数とかブロックは3段以上ネストしない

fun saveUserName(username: String) {
  Realm.getDefaultInstance().use { realm ->
    realm.executeTransaction { realm ->
      realm.where(User::class.java).equalsTo("id", userId).findFirst()?.let { user ->
        user.name = username;
      }
    }
  }
}

でもパット見の印象は "複雑" だ。

fun inRealmTransaction(operation: (Realm) -> Unit) {
  Realm.getDefaultInstance().use {
    it.executeTransaction(operation)
  }
}


fun saveUserName(username: String) {
  inRealmTransaction { realm ->
    realm.where(User::class.java).equalsTo("id", userId).findFirst()?.let { user ->
      user.name = username
    }
  }
}

ネストの深さはせいぜいこのくらいであって欲しい。

その拡張関数、本当に拡張関数じゃないとダメなの?

IntentとかBundleとかに独自メソッドを生やすのは、まぁなんとなくはわかる。

一方で、FragmentとかActivityにメソッドを生やすのは「それ、ベースクラスつくって継承させるのじゃだめなの?」と疑いたくなる。 本当に継承じゃだめな理由があるなら、メソッドを生やせばいいけど、その場合には↓に紹介されてるように、Interfaceでスコープを明示的に示すように実装したほうが事故るリスクは少なそう。

dev.classmethod.jp

まとめ

よくわからないなりにも、"直感的にロジックが読めない"コードはどんなにきれいなコードでも排除しようとレビューをしている。

 

ところで、Googleが絶賛布教中?のDartっていう言語だと

Effective Dart: Usage | Dart

Effective Dart: Design | Dart

みたいなベストプラクティスが公式に示されている。それよりも後発のKotlinにはこういうコンテンツってないのだろうか?