java-ja『LOG.debug("nice catch!")』に参加してきた #java_ja

勉強会 Java


(写真：会場入り口。あれ、イベント名が…こちらが正式名称だったのかな。)

try {
    java-jaで例外とロギングについて勉強します
    
    話していただくのは
    俺たちのt-wadaこと和田さんと
    PFIの田中英行さん 
    歩く萌え要素こと西尾泰和さん
    歩くモヒカン太一
    です
    try {
        LT.add(ヨシオリ)
        LT.add(crexista, 'クライアント側でナイスキャッチ')
        LT.add(@shomah4a, 'PyconJPのCfPの宣伝')
    } catch (LTTimeoutException lte) {
        LOG.debug(ドラ)
    }

    try { 
        他にも発表いただくかもです
        あとLTやりたい人連絡ください
        発表、LTしていただける方は、人数が埋まっていても参加可能です。
    } catch (Exception e) {
       //OK
    }
    例のごとく懇親会をそのまま会場でビアバッシュ形式でやりたいと思います。
    2000円の予定です
} catch (Exception e) {
  //nice catch
}


その存在自体は勉強会に興味を持ち始めた頃から知ってはいたものの、なかなか参加する機会が無かった『java-ja』。(※伝え聞く内容によるとマサカリが飛び交う的な側面が強そう…とあったので少し躊躇う部分も無くは無かった)

今回、"ログと例外処理"というテーマについての勉強会が開催されるという事で、告知開始を受けて光の速さで申込！＆参加してきました。


開催場所はグリー株式会社＠六本木。直近では何回か来てる建物ではあります。(第30回 HTML5とか勉強会とか)

開始時刻を過ぎたものの、参加者の入り度合いやトーカー集合の度合いを鑑みつつ若干のタイムテーブル変更(開始時刻を延ばす)。主催のやましろ(TwitterID:@yamashiro)さん、Yoshiori (TwitterID:@yoshiori)さん等によるトークが入りました。

  • 『java-ja始めてのひと〜』（割と多くの人が挙手。予想外の量に驚かれていました。ちなみに自分も今回java-jaが初参戦。）
  • 『ともだちいないひと〜』(こちらも半数近くがなぜか挙手し、こちらの反応にも『いや、リアルな友達の話じゃなくてね...ごめんそうじゃないんだ』)
  • 『何かちょっと寂しいひと〜』『近くの人、話しかけてあげよう。僕らは内輪だ』
  • 会場について
    • GREEの会場(があるビル)、5年程前から使わせてもらっている。昔はもっと簡単な手続きだった
    • 『GREEはワシが育てた』
    • GREEは勉強会支援のグループがあるらしい。
    • 開催会場、広い！(※社員全員が入れる位の大きさにも拡張可能らしい)
    • 俺等が一番お世話になっている企業がGREEです。
  • PHPを書く会社に行って、PHPを書かないまま上り詰めるのが得意です。
  • 『すごいでしょ、この設定ファイル .scala って書いてるけどただの型推論されるドキュメントファイルなんですよー』
  • Yoshioriさん
    • 今回はログと例外についてごにょごにょやります。
    • (今回初参加の人にとっては)びっくりするかもしれないけど…ツッコミ入れます。質問タイムは設けません。ガーガー言うとやましろさんがマイクを持って走ります（やましろさん：会進行やるので無理です）
    • 会場提供はGREEさんです！勿論、実質無料です！
    • 帰ってブログを書くまでがjava-jaです。『GREEさんパネェな！』と書きましょう。

準備が整った所で、いよいよ本編開始。『俺たちのt-wada』こと和田卓人さんからスタートです。

例外設計における大罪


  • 自己紹介
    • 『下心(アカウント：t_wadaを指す：バーの位置("アンダー"バー))の和田です…と(自己紹介は)これくらいで良いんじゃないかな』
  • java-jaについて
    • java-jaへようこそ！
      • java-jaは怖いところと思われていますが…
      • 技術を楽しむ位でないと生き残れません。
  • 今回の勉強会開催のきっかけ
    • Yoshioriさんとの会話(at 地下鉄の中, 焼き鳥屋での会話)から発展。
    • TDDだとログを書き忘れやすい？
      • 動作確認が出来る状態なので、ログコードを入れるのを忘れがち。
      • マイナーな勉強会やってみようよ。
      • 当初はもっと少ない人数規模だったものが、あれよあれよとここ(100人規模)まで拡大。
    • TDDを行うとロギングコードを書き忘れやすい仮説
      • (ちなみに例外は忘れにくい)
    • プロとしてのたしなみ、どこへ行ったのか…
      • 上手く動くときは無音で動くけど、本番環境等で追うときに分かりにくい。
    • 皆どうしているのか聞きたい。
      • 俺のモチベーションで始めたんだ！
  • よろしくおねがいします。
例外設計の大罪
  • 大罪：『放置』

    • 『(資料中の)サンプルコードはワイルドさを意識しています』

それぞれの書籍からテーマを引用しつつ解説。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

  • きのこ93：エラーを無視するな
    • 例外処理を行わない言い訳
      • コードの流れが負いにくくなる（クリーンコードにも書かれていた）
      • 納期が迫っている
      • エラーが戻ることが無い関数である
      • 遊びで書いただけのプログラムだから
        • 『例外処理はgoto文ダメだよね』
          • やっていいgoto文をコードとしてサポート：例外処理。Try/catch
          • 要はgoto文、帯域脱出
          • 大きいところだと例外投げさせない、キャッチさせない、そもそもthrowsって書かせない
        • goto文、歴史には良くないよね
          • 帯域脱出の代表的なものが例外処理
    • エラーを無視してもあんまり良い事は無い
      • 不安定なコード
      • セキュリティ上問題のあるコード
      • 貧弱な構造とインタフェース
    • どうする？
      • 戻り値など
  • 大罪：『隠蔽』

プログラマが知るべき97のこと

プログラマが知るべき97のこと

    • きのこ27：死ぬはずのプログラむをムダに活かしておいてはいけない。
      • 最近は静的解析ツール、握りつぶり検知するの？→する。
      • 例外の握りつぶしは、字面として結構目立つ。
      • 割と複数人の所だとやりにくいはず。
    • 遠い記憶：
      • 昔のJDBCプログラミング
      • 共通コード的な
      • (最近のC#のリソース事情について話が続く)
  • 大罪：『例外の乱用』

Effective Java 第2版 (The Java Series)

Effective Java 第2版 (The Java Series)

    • 57.例外的状態にだけ例外を使用する
      • 和田さん『必読です！』

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (347件) を見る

    • ヒント34：例外は例外的な問題のみに使用する事
      • 全ての例外ハンドラーを除去しても、このプログラムは動作することが出来るだろうか？
      • 答えがノーであれば、例外では無い状況下で例外が使われている
  • 大罪：『過剰防御』


(写真："フルアーマーダブルゼータ"。)

    • 通常フローを無視しても行けないし、例外を無視しても行けない
    • 全ての引数、状態を疑おう。
    • Defensive Programmingの適用
    • 思いっきり重複するエラーチェック
      • 自らが自分の中で完結するようにディフェンスである、という一派。
      • →重複しがち、DRYではない。
    • 発表時、サンプルコード中の『return null;』という記述を責められる和田さん。(オブジェクトを返すべき所、その記述のまま発表されていた。※スライド資料は既に修正されています)

    • 『いや、あの、うん、すいません…』『意図したネタでは無いので恥ずかしい…』
    • 更に参加者からの指摘『さらに、これは数え年を考慮していない仕様エラーでもありますね…』
  • 契約による設計

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

    • 『奥さんには"青いレンガ"って言われた』Bertrand Meyer著。
    • Design by Contract DbC
      • あるルーチンにおける全ての事前条件が呼び出し側によって満足された場合、そのルーチンは作業完了時に全ての事後条件と全ての不変表明を保証する。
    • 冗長性のある検証は実際損傷を与える
    • システム全体の視点で見るとき、シンプルさが重要になる
      • 複雑さは品質の敵である
    • 過剰に防御するのではなく、誰の責任なのかをはっきりさせる
    • 例外処理は、予想外の実行時状態に対処するメカニズム。
    • ルーチンはリトライか組織的パニックのどちらかで例外を処理する
    • 11章は契約による設計、12章は例外について記載あり。
      • 『これだけでご飯が食べられます』
    • きのこ21：技術的例外とビジネス例外を明確に区別する
      • これらを同じ例外階層構造に入れないこと。
      • 技術的例外は貫通させてフレームワークに任せる。
      • ビジネス例外はじゅん正常系なので呼び出し側で対処する。
    • きのこ27：見知らぬ人ともうまくやるには(by 小飼弾)
      • 『出来てはならぬ事を禁じる』のではなく、はじめから『出来て良い事だけを出来るようにする』と考えるのです。
      • 特定条件が買えればtrue、でなければfalse。
    • Effective Java：第9章にも関連テーマで記載アリ。
  • まとめ
    • 良い本を読みましょう。
    • 特に青いレンガの本はおすすめ。
    • おまけ：
      • 書籍『Clean Code』でも、Robert Martin a.k.a アンクル ボブ 氏も『チェック例外の代償は、開放/閉鎖原則に違反する点です』と言及している。

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技


本人による補足つぶやき：


和田さん発表終了後、お酒が届いたとの一報が。会場後ろのコーナーへ奪取しに行く参加者一同。

ログ、その時の為に。

スライド資料についてはこちら。画像をクリックすると資料URLに飛びます)

また、スライドに合わせたテキスト資料についても既に公開？されておりますのでリンク。
（これがあるので、この講演に関するメモは割愛。以降気になった点、テキストに無かったコメントなどをメモ。）

  • 自己紹介
    • (今回の勉強会、)せいぜい集まって15人位だよね、和田さんと話してた
    • 『上からマサカリを投げるだけで給料をもらっています』
    • 最近のコード
    • プロダクト
      • koshinuke
      • Yuzen

資料の内容については事前に公開されていた＆テキスト情報もgistから辿れたりしますので割愛。質疑応答箇所と気になったつぶやきを抜粋して並べてみます。

  • [Q].ログを出す時のアドバイスとかがあれば。
    • 運用面からすると、なるべくへらしたい。
    • 開発環境からすると、沢山出したい。
    • 『バウンダリ』(詳細は資料参照)を中心にログを出すようにする。

  • [Q].僕のシステムのポリシー：レベルを設定出来るようにしている。
    • 開発：info以上はアラートなげる。
    • 運用：error及びfetalをアラートとして出す。
    • ログを使わず、メールで運用。
    • メールが飛ばない場合は？ファイルを見る。でも気付かないかも？
    • メールが飛ぶ事で確認する。飛ぶ事を確認、でもエラーではない。
      • →でも見落としがちだよね〜。
    • ホントに大事な場合、外部から監視する。
  • [Q].本番でinfo以上のログを出さないのって運用者に厳しいよね？
    • 本当に運用者の事を考えるなら、ログを見るな、と言う。
    • 上手く行ってる時にはログ観る必要が無い。

  • [Q].今居るシステムは、まったくログがない。
    • タイムアウトするとユーザにエラーが、そんで怒られる。
    • →wariningログ出して下さい。
    • ログ系ミドルウェアの導入を検討する
    • RDBにつながりません、というエラーメッセージをRDBに突っ込もうとする光景を見たことがあります。

特に最後のつぶやき(のシーン)は一同大爆笑(笑)

例外処理の歴史


  • 自己紹介
  • 『特集：言語設計の基礎知識 (WEB+DB PRESS vol.60)』の続編を執筆中！今回は執筆中の書籍からのネタバレです。

  • 例外処理って何がしたいの？
    • 失敗するかも知れない処理を呼び出すとき：『これが失敗したときには〜をしたい』
    • 失敗するかも知れない処理を実装するとき：『失敗したと言うことを呼び出し元に伝えたい』
    • 返り値で返せばいいじゃない？でも読み辛い！
    • ごちゃごちゃせずに書けるようにしたい！
  • [問題1]
    • 次の中で、最初に生まれたのはどれ？
      • 『try』:失敗しそうな処理の前に置かれるキーワード
      • 『except』: 失敗しそうな処理とエラー処理の前に挟まるキーワード
      • 『throw』：失敗させる命令
  • [問題2]問題1の選択肢がそれぞれ生まれたのは、どの年代か？
  • [回答]
    • 『throw』。1964年、throw相当の機能(signal)が用意されていた。
      • ちなみに1976年にはCLUにおいて、exceptと囲んで捕まえる構文が登場している
      • 1954年、COBOLには2種類のエラー構文があった。→1964年、PL/IはCOBOLやALGOLからいいとこ取りをして統一的なエラー処理のために『ON構文』を導入。
        • PL/Iの4大制御構文:GOTO, IF, DO, ON
        • エラー処理の命令を予め登録しておく
        • ON <エラーの種類> <エラー時の処理>
    • try：tryなんて飾りですよ…
      • 全く不必要だったが、説明するのが難しいと分かったので、混乱したユーザからサポートスタッフを守るために余計なものを導入したらしい。
  • まとめ
    • エラーをどう伝え、どう処理するか。この点については50年代から試行錯誤されてきた。
    • 対応付けを間違わないために、70年代に今風の『囲む構文』が生まれた。
    • tryなんて飾りですよ
    • 例外処理の歴史
      • 50年代：COBOL
      • 60年代：PL/I、throw相当の機能
      • 70年代：CLU、囲む構文の登場、検査例外の提案
      • 80年代：C++、try(飾り)の導入
      • 90年代：Java登場、検査例外の導入

質疑応答の最中には、なんと！今現在執筆されている件の原稿を見せながら回答していくという光景も！(一応ボカシ入れときました)

なお、今回の発表の結果を受けても、今後発売予定となる(続編が載っている)書籍の記事の価値は何ら下がることはないので、皆さん買いましょう！(by ヨシオリさん)との事なので、皆さん発売の折には是非購入を！

懇親タイム

軽食及びピザが届いたぞ〜！という事で休憩も兼ねて15〜20程、懇親タイムへ突入。(食事写真取り忘れた...) ピザもその他の食事メニューも、かなりクオリティ高くて美味しかったです！

基調講演：エラー処理の抽象化


  • 自己紹介
    • IT業界で話題騒然、『すごいH本』ことHaskell入門書、『すごいHaskellたのしく学ぼう！』の著者。

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

発表資料はこちら。(※画像押下で資料URLにも飛びます)

既にブログも上がっておりますので、詳細については以下のエントリを参考にされると良いと思います。

最初の方はエラー処理詳説、的な内容で話が進んでったのですが、知らないうちになぜかHaskellの話題になり(笑)そしてHaskellの世界にどっぷり…という感じでした。割と皆さんポカーンとしたなか、西尾さんがJavaの世界に例えて時折解説を挟んでくださったので、だいぶ助かりました。ありがとうございます！


この時点で時間は22:30を過ぎ、結構いい時間だったような。引き続きLTへとなだれ込みます。


LT

LOG.debug(maker, "使え")


  • Marker使ってる？
    • Marker使っていない人はSlf4jもう使うなよ。log4jに戻れ！
    • 日本語で触れている記事
    • 特徴：
      • ログの次元を増やす。
      • パッケージ→ログレベル
      • markerが追加、次元が更に増える。
  • 基本
    • 全体設定
  • 応用
  • マーカーのenum化
  • slf4jとlogbackでしか使えない。
    • [Q].切り替え後の実装がない等の不具合は？→[A].Haskellでなくてjavaなんだから分かるだろう？
    • 結論：marker使え。
ライ麦畑で捕まえて

…改め、

資料はこちら。

  • 皆さん、ナイスキャッチしてますか？
  • 本当のNICEなキャッチを提案。

  • NICEじゃ無い例
    • 例外のメッセージをそのまま表示するのみ、何が起きたか分からない。
    • アドレスとかどうすればいいのよ？怖いよ！
    • 分からないのにOKボタンしかない？
    • 原因よりも方法を先に、簡潔に。
  • 1.ユーザの選択は絶対！
    • ユーザの選択は例外じゃない
    • 居ひられた事はもうしない。
  • 2.真実にむかおうとする意志
    • 2回やってダメだった処理は繰り返さない。
  • 3覚悟したものは幸福である

  • それでは、良いナイスキャッチを！Have a nice catch
PyCon JP 例外とロギング

しょーま(ただのプログラマ) さん (TwitterID:@shomah4a)

すみません、この辺で既に力尽きていてメモ取れてませんでした...orz 基本的にはイベント告知などがメイン。

scribedはやめとけ。fluentdマジオススメ

tagomorisさん (TwitterID:@tagomoris)

既に参加＆発表に関するエントリがUPされているので、詳細は上記エントリをご参考ください。以下の内容について、ブラウザを立ち上げながらのLTでした。(リスト項目はエントリから拝借致しました)

logrotateマジちゃんとやんないと悲劇が起きる
scribedというものがあるがネットに基本的に情報は無い
scribedのインストールは大変
scribedのインストールはマジ大変
scribedはいろいろ大変過ぎるので避けたほうがよい
というようなことが こちらのエントリ に書いてあるので興味があれば読むのもよいでしょう
fluentdイイヨ！


以上で本編終了。ちなみにこの時点で時刻は22:45過ぎ。この後は懇親会ですよ〜と言いつつも撤収が23時だったため、

という事態に(笑)そのまま皆さん片付けや撤収作業に移りつつ、イベントもお開きとなりました。

java-jaへの参加は今回が初めてであり、会の雰囲気やモヒカン度合等にも驚き、圧倒される事が多いイベントでしたがトピック的にも面白いものが多く、何より雰囲気を楽しむ事が出来ました！和田さんに関しては縦サミ→TDDBCでの和田さんしか見たことがなかったので、別の一面(？)な和田さんを見る事が出来たのも良かったと思います。:-)

java-jaスタッフの皆様、登壇者＆LTトーカーの皆様、御参加の皆様、楽しい時間をありがとうございました！


そして冒頭の

帰ってブログを書くまでがjava-jaです。『GREEさんパネェな！』と書きましょう。

の言葉に倣って、締めはこれで。

GREEさんパネェな！



その他関連：