無駄かもしれない足掻き

github : https://github.com/zer0-u

Enumと定数の差

についていろいろな知見を得たのでメモしておく。

ことの発端

発端はこちら。

もう少し詳しく言うと、

こうなる。Enumについて解説しようと思ったところ、ふと「定数と何が違うんだろう?」と思ったのがきっかけです。いつもご意見ありがとうございます。

Enumと定数の違い

簡単に言うと、値が取りうる範囲をどこで保証するかという点が違う。

定数クラスの場合

定数だけを持つクラスを宣言したとする。こんな感じ。

public class BloodType {
    public static final int A = 1;
    public static final int B = 2;
    public static final int O = 3;
    public static final int AB = 4;

    private BloodType(){} // インスタンス化防止
}

でも、BloodTypeを受け取るメソッドというのは引数をint型にせざるを得ない。

public int hogeMethod(int bloodType){
    return 0; // 実際には血液型に応じて何かするメソッド
}

これだと、引数のbloodTypeがA,B,O,ABの4つのうちどれかであることを保証するのは実装した人になる。if文で分岐するなり、switch文を書くなりして、elseなりdefaultでどうするか(nullを返すとか、例外投げるとか、デフォルト値的なものを返すとか)を考えなきゃいけない。呼び出す側も、取りうる値を確認する必要がある。BloodTypeクラスの定義を確認して、A型なら1を入れることを知らなければならない。全然関係ない値を入れて「思った通りに動かないじゃん!」と言うこともできちゃう。困る。

Enumの場合

Enumで宣言すると、取りうる値の範囲を保証するのはコンパイラになる。

public enum BloodType {
    A,B,O,AB
}

こうすると、BloodTypeの取りうる値が4種類に限定される。呼び出す側も、BloodTypeまでタイプすれば候補の4つが予測変換?に表示されるからいちいち定義を見なくていいし、関係ない値を渡そうとするとコンパイルエラーになる。引数に取る側も、違う値が来たらどうしよう...と悩む必要がない。とても便利。

雑感

書いてみるとこれだけのことなんだけれど、意外とするするっと説明できなかった。選択肢?はいはいEnumね~わかるわかる、でなんとなく過ごしていたのかもしれない。自分で説明しようとすると、これがわからない・あれどういう理由だっけ...?となるので、理解を試すためには自分が説明できるかを基準にすることはいいと思う。

というか「わかったふり」って自分も騙せるから怖いなぁ。こういう風に「なんとなくわかってるけどほんとはわからないこと」がたくさんあるんだろうと思うとちょっと怖い。

JJUG CCC 2017 fallに登壇してきた

登壇した関係の話と、いち参加者としていろいろなセッションを聞いた感想を上げておきます~。

登壇まわり

ありがたいことに満員でした。初心者~中級者と自分で決めたターゲット層にマッチする方が多かったのもうれしかったです。

資料はこちら

speakerdeck.com

資料に入っていないこぼれ話

購入したもの

スライドからURLがうまく踏めないのでこちらにもリンク載せておきます。

オラクル認定資格教科書 Javaプログラマ Silver SE 8

オラクル認定資格教科書 Javaプログラマ Silver SE 8

オラクル認定資格教科書 Javaプログラマ Gold SE 8 (EXAMPRESS)

オラクル認定資格教科書 Javaプログラマ Gold SE 8 (EXAMPRESS)

あと問題集はこれを使いました。

徹底攻略 Java SE 8 Silver 問題集[1Z0-808]対応

徹底攻略 Java SE 8 Silver 問題集[1Z0-808]対応

徹底攻略 Java SE 8 Gold 問題集[1Z0-809]対応

徹底攻略 Java SE 8 Gold 問題集[1Z0-809]対応

OCJPの教科書・問題集について

本筋ではないから削除したんだけれど、書籍を元に勉強する際は必ず正誤表を確認してください。ほんとに。Amazonで買うと初刷が届く可能性が高いので特に。問題文のミス、解答の選択肢に同じものがある、説明がしっちゃかめっちゃか…などなど、わりと苦労しました。これで苦労したからJLSやAPIリファレンスを読む力が伸びたといっても過言ではないくらいです。見つけた間違いは2刷では直ってるのがほとんどなので、余裕があれば書店で実際に確認してから買ったほうがいいとも言いたいです。

正誤表はWeb上で公開されています。それぞれの書籍の冒頭にURLがあるので確認してから始めてください。

試験問題について

終了後に質問されたのでこちらでも補足します。

試験問題は日本語・英語が選べます。他の言語もあるかもしれませんが、ここでは需要がないし調べてもいないので省略します。申込時に選びます。試験時間中に切り替えることはできません。なんか公認資格にするには日本語を選ばないと…みたいな話もどこかで見かけましたが、自分の学習のために受けるなら慣れた言葉で大丈夫だと思います。職場などで受ける場合は事前に確認してください。

ただ、日本語特有の翻訳にまつわる問題なのか、一部の問題は非常にわかりづらいです。原文を見たらわかるかもしれないけれど、本当におまえこの答えで合ってるって言うのか?!?!?!みたいな逆ギレ案件がたまに紛れています。教科書作る人の間違いかと思ったら、全く同じ問題が本番にも出たので思わずチベスナ顔しました。

そういった問題は深追いせず他の問題で点数を稼いだほうが良いです。試験のテクニックでした。

参加したセッション

午前中は自分のセッションに向けてそれどころじゃなかったので何も聞いてないです。よこなさんのセッション聞きたかった…。あとで資料読みたいけどどこかでまとまっていますか?(他力本願)

午後からは解放感に浸りつついくつか参加しました。

ccc_g3 Java 9を迎えた今こそ! Java本格(再)入門

J2SE1.4の時代からJava SE 9までを駆け足で振り返った感じでした。最初のコードは過去のトラウマをいい感じにえぐられましたねw

5で入った変更は「より安全に書ける仕組みの導入」、Stream APIは「今後必要になる考え方が含まれている」新機能、といった、なぜその機能が導入されたかをまとめる言葉があったのが印象的でした。

ccc_e4 Java SE 9の紹介:モジュール・システムを中心に

Java SE 9でモジュールシステム(jigsaw)が来たぞ!と言われつつも何が変わるのかわからなかったので参加しました。やっぱ難しいわ…リフレクションについての知識がなかったので後半はほぼ置いてけぼりでしたね。クラスやメンバの可視性がより細かく設定できるだろう、ということはわかりました。

業務として開発の際に使うわけではないものの、知っておかないと教えることができないってのが他の方とは違う悩みどころです。広く深く知っておかなければならない。勉強時間もきちんと確保しないとな~OCJP受かったからって慢心しちゃだめだな~と思いました。

ccc_a5 JDKの新しいリリースモデル

まだ確定情報じゃないらしいので細かい内容は伏せておきます。ガラッと変わるみたいでほんとにこれでいけるのか??????確信が持てないぞ??????というのが正直なところです。現場はJDKのアップデートやサポートを検討してどこに移行するか考えつつ、教える側としてはどこまで最新の文法事項などを追っていくかがポイントになりそうでした。ほんとに実現するとしたらSE 8以前とそれ以降とで大きく二分されそうでそれもそれで怖いなぁ…。早く確定情報がほしいです。

ccc_g6 新しいプログラミング言語の学び方

新しい言語を学ぶときにHTTPサーバを作ると、本当に学びたいこと(新しい言語)に集中できるよ!という話でした。ただ、ネットワーク周りの基本的な知識がないと、そもそも「俺は今何を作ってるんだろうか…?」状態になりそう(というか私は途中からそうなってた)です。だから、1つの言語にある程度習熟した人が、新しく何か学ぶときの手段としては確かに的を射ていると感じました。ネットワーク周りは苦手なんですよね…。応用情報取るときも捨ててかかった部分です。

この部屋の後ろの方だとスライドがほとんど見えないですね…。遠すぎるのと、前の人の頭と被って下半分がほとんど見えないままでした。特に、コードを写すときに背景が黒いとまじで何も見えません。自分が登壇する時は気をつけます。ちなみにエディタは白背景派です。

会場よもやま話

一方通行が導入されたお陰でものすごく移動しやすくなりましたね…。前回までのもみくちゃ状態がなくて快適でした。誘導もしっかりしているし、地図に動線書いてあるしわかりやすかったです。参加人数も少し絞ったのかな…? CfP通った時点で参加人数などは把握しなくなったのでちょっとわからないです。

アンカンファレンスの仕組みもよさそう…とは思ったのですが、いつ何をやっているか把握できなかったので結局参加せずでした。早めに把握しないと、その時間に見たいセッションがあった場合に動きづらいなぁと…。Room Lのドアの他に、ロビーのところ(テーマ募集時のホワイトボードの場所)にもあると見やすかったかな―と思いました。Lのドアまで行くと戻ってくるのに大回りしなきゃだし。

そんな感じです!今日はゆっくり休むぞ~

壮大なトンカチ問題

だいぶ積読も消化してきたような気がする。やっぱり読む速度が落ちてるのがもどかしいなぁ。

今回の本はこちらです。

さよなら、インタフェース -脱「画面」の思考法

さよなら、インタフェース -脱「画面」の思考法

  • 作者: ゴールデン・クリシュナ,武舎るみ,武舎広幸
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2015/09/17
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (5件) を見る

続きを読む

やりっぱなしをやめる

少しずつ積読を消化していくマンだよ~

今日の本はこちら

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

続きを読む

何を解くべきなのか?

どうも。

帰ってきて勉強とかしようと思うんだけれどなかなかうまくいかない日々が続いています。やろうとはしているんだけれど、なんでかうまくいかない…疲れてるのかなぁ。ただだらだら何か(動画とか)を見ることはできるのでやっぱり疲れてるのかもしれない。とはいってもいろいろとやりたいことは溜まっているのでどうにかしたい。

普段より時間はかかったけれど本を読んだので記事を書く。

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

あやぴー氏からもらった。ありがとうございます。

サブタイトルに「問題発見の人間学」ある通り、問題を解決するというよりは解くべき問題をどう見つけるか、どう定義するかということに絞られていた。問題は定義するまでが一番むずかしいから、そこを体系立てることができたことは助かる。

  • 問題を見つけるための問いかけ
    • 誰にとって問題なのか?
    • その「誰か」は問題を認識しているか?解決するつもりはあるか?
    • 問題の本質は何か?
    • 誰から/何から/どこから起きた問題か?
    • それは本当に解決したい問題なのか?

問題が解決すると新しい問題が出てくるし、それはたいてい解決したはずの問題から起きる、というのは経験から正しいと思う。となると、何かをする限りずっと問題が起き続けて、それを解決しては新しい問題を作り出すことの繰り返しになってしまう。だから、何を解くべきかを決めるのが大事だと読み取った。

今の自分に当てはめてみると、いくつかの問題が起きている。やるべきことが何かが全て明確になっているわけではないこと、やろうとしてもなかなかうまくいかないことなどがある。こういうことを解くべき問題として変換できるかは試してみたい。

全然関係ないんだけれど、時々ある挿絵にびっくりする。ユーモア…なのかもしれないけれど全然意味がわからなくてぞっとする。すごくごついボールド体の文字に威圧感を覚える。なんなんだろうこれ…。