【C#】バッチアプリケーションのエラーハンドリング
今更バッチアプリケーションのエラーハンドリング。
従来のtry catchじゃなくてほかのやり方があったよっていう話。
業務システムはもちろんWEBアプリの裏側の運用でも結構使うハズなので書いてく。
通常のエラー処理は以下
try { // 何らかの処理 } catch (Exception ex) { }
おっけい。もちろんこれでおっけい。
しかしルールを決めずにこれを基準としてエラー処理をするとこんなことが起きる。
public void Main() { try { testMethod(); } catch (Exception ex) { } } public static void testMethod() { try { // なんらかの処理 } catch (Exception ex) { } }
もう発狂しそうだけどもっとひどいことが起きる
static void Main(string[] args) { try { testMethod(); } catch (Exception ex) { // Mainプログラムでエラーが発生しました的なログ出力 } } public void testMethod() { try { // なんらかの処理 } catch (Exception ex) { // testMethodプログラムでエラーが発生しました的なログ出力 } }
絶望の「予期せぬエラー。。。」
悲しいことに結構存在する。意味不明だし、どんだけメンテ必要なの！？って
でConsoleアプリケーションでもMVCのOnException的なのないかなーと思って
探したらあった。
UnhandledExceptionイベントハンドラを追加
static void Main(string[] args) { // UnhandledExceptionイベントハンドラ System.Threading.Thread.GetDomain().UnhandledException += new UnhandledExceptionEventHandler(Program_UnhandledException); throw new Exception("Error"); } public static void Program_UnhandledException(object sender, UnhandledExceptionEventArgs e) { Exception ex = e.ExceptionObject as Exception; // ここでエラー処理 }
例外発生したら捕捉してなくともイベントが発火するのでいちいちtry catchする必要がない。
stack trace取れてエラーの原因がすぐにわかって便利だねってやつ。
まぁ、あんま調べてないからどこまでstack trace取れんのかわからんが基本ベースはこっちでいいと思う。
参考
https://msdn.microsoft.com/ja-jp/library/system.unhandledexceptioneventhandler(v=vs.110).aspx
20代で車を買って良かった話
去年、車を買った。
最近の若者は真面目だから車買ったことによるメリット、デメリットを考えすぎて買わない方向に行くと思うんだけど、圧倒的に買ったほうが良かったと思ったのでいろいろ書いてく。ちなみに私は買わなくても良いってずっと思ってた。
１．車を買って生活に困ることはない！
車買うと月々の支払いが高いとか税金ガーとか車検ガーとかあると思うけど、良い車買わなければそんなん気にせず乗れると思う。ちなみに僕は以下。
車:1300cc
乗り出し:65万（一括）
車検:4万ちょい（ユーザー車検）
税金3万5000ぐらい
月々:保険6000ぐらい（車両保険いらないポンコツ車だから）駐車場一万
ガス代:月5000（年間1万キロペース）
普通の社会人だったらそんな辛くないでしょ。ちなみに実家じゃないからいろいろかかるけどわりと余裕。
２．周りの見方が変わる
老害みたいに車はステータスとは言わんけど、自立した第一歩として見られるパターンが多い。親とか親友達とか子供の時から見てくれてるから立派になったねと思ってくれる人が多い気がする。親を安心させるツールとして良い。
3．嫁の機嫌が良くなる
駅まで迎え行く。だいたい喜ぶ。迎えに来てもらう。だいたい乗り気。スーパーとか家具とかいろんな店行ける。マンネリ防げる。
４．友達との交流が広がる
男同士だと計画して何をやろうとはなかなかならない。だからぷらっと出かけて思い出が作れることが多い。
５．車維持出来る自信がない。。
タイヤとオイル交換を気をつけてれば何も問題ない。ディラーが車検でいろいろ言ってくるけど、ユーザー車検なんてクソ適当だから光軸さえ気をつければだいたい通るよ。
６．都内、首都高は怖くない！
何も怖くない。普通に走ってれば違反取られないし、そんなに事故ることもない。事故は運が悪いか無茶したかの二択なのでそんなに恐れず運転しよう！
７．高級車ぶつけたら。。。
保険で大丈夫。保険でなんとか出来ない車が普通に走ってることはないはず。たまにマセラティとかシボレーとか走ってたりするけど保険でなんとかなるはずだよ。ただし名前の怪しい保険会社は気をつけてね！
買って良くなかったなーって思ったとこ
１．スポーツカー買えば良かった。。
いや5人も乗らねーよ！乗るときはレンタカーで良いよ！ロードスター、rx8らへんはわりと安いの流通してる。いやかっこいい車最高だよまじで。ただし、180、シルビア、チェイサーあたりは絶対買っちゃダメ。
２．都内に行きにくい
いや電車で行けば済むんだけどね。
3．いや、悪いことねぇわ笑
結果、買って悪いことはなかった。身の丈の車を買えば余裕で維持出来て良いことずくめなので問題なし。身の丈にあった車買って維持出来なくて詰みそうだったらそもそも生活を見直す（仕事とか普段の金遣いとか）必要があるのでそっちを見直しましょう。
ps:私は27です
ちゃんと教育しないと新人エンジニアは育たないことを知った
クソ偉そうだけど、5年社会人経験してて4年間教育係りをやっている。転職して2社目だけど、1社目と比べて今の会社の新人が育たなすぎる傾向にある（今の方が圧倒的に勉強になる環境にいるのに）から分析してみる。
1社目の教育
・一カ月本を読まされる。
・一時間に一回、ブラザー来るので「〇〇学びましたー」って言っとけば良い（ちゃんと質問されても答えられるようにね）
・基本クラサバ。
・2〜3カ月はひたすらブラザー付き。csv取り込みsql追加とか一瞬で出来るようなことをやらされる。
・配属、そのまま業務。
・基本情報を取らせようと煽る
2社目の教育
・入社前にhtmlとjsやらされる。基本ネットに載ってるコピペですむやつ作らされる（中途はやらされない）
・入社してすぐ配属。mvcとc#を同時に学ばせる（業務やらせるしね
・他のソースをコピペしてなんとかさせようとする
・だいたいすぐ詰む
・半年たってもフロントとサーバーサイドの違いがわからない
今の会社との違い
・クソつまらない本を長時間読ませる（基礎を教える）
・コピペが使えない
・開発環境のポンコツ（シンプル）
・クソつまらない仕事を長時間させる（基礎を固める）
・資格を意識させる
・ものづくりファースト
プログラムは参考書の一行読めば1000行のプログラムを読めることもあるし基礎を反復練習させることはすごく大事。初めからいろんなことをひたすら詰め込むとだいたいその場しのぎになって結果何も出来ない人になる（学生時代勉強した人とか入社前頑張った人を除く）。
結局エンジニアは「やった！動いた！」の成功体験を繰り返してくことで初めて次のステップアップ出来るので地道にちょっとずつ積み上げてくのが一番理想なんだろうなと思うこの頃
githubに変えてプロジェクトの本質を学んだ話
今さら感がすごいですがやっぱgithubは良かったよ！！
って話です。
ちょうど一年前、私は権力の強い上司にgithubの素晴らしさや導入するべきと適当な理論をおしつけて全サービス移行した。
「githubにするとうちのエンジニアの価値あがりますよ！！」
「プルリクってやばないすか？自動テストからのデプロイいけるんすよ」
まぁ私が使い方やらツールやらgitflow（うちはgithubflowでなくgitflowにした）やら全部調べてやったんだけど、いろいろ問題はあった（ほとんど使い方がわからねぇ系の不満。いやググれや
プルリクも強制してsvnのコミット無双無法地帯状態から脱却出来たけどスピードが遅くなるとかマージ出来ないとかsubmoduleなんぞや？みたいなのが多すぎてうちのエンジニアには向いてなかったのかな？と思い始めてた。
そのとき会社で大事件が起きてその事件の犯人（ボキャブラリーないんで言い方悪い）は辞めてしまった。
「なんでこんなの組んだの？」
「いやありえないでしょ」
「普通に向いてないよこれ」
みたいな話が出てきていてもいられなくなったのだろう。
svnだからってわけじゃないけど「出来ました！！」がプログラムの成果になってその過程はどんな手段でもいい（レビューしてないし）ので責任が一人に集中してしまう。
それって最悪でエンジニアのモチベーションは下がるし、バグ怖くて影響ないないコード（よくSIerが書くやつ）を書いたり、新しい技術は得体しれないからやりたくねーだったり何も成長しない。それがgithubのプルリクでこいつ少なくとも見てんだからこいつも責任あるよね？感が出て通常やりたくない作業とか嫌がらずにやってくれたり、こんな特殊な書き方してやろー（主に私がやる）とかで「こんな書き方出来んの？」とかで技術共有出来たりとかかなり良くなった。いわゆる老害を安心させる一つの手段にも使える。
まぁここまでふざけて書いたけど、チームでやる仕事である限りある程度の責任転嫁は必要になるということ。githubじゃなきゃダメってことはないけど、その機能を使ってプロジェクトを最適化することはアプリケーションのあり方だと思う。「責任はみんなでおってね！！」って言っても伝わらんしね、仕組み化大事。
プロジェクトを最適化するのは仕組みでもなく技術でもなく人間関係だったことをgitから学んだ。
ps:まだフリーランスになってない笑
c# 7.0
以下感想
タプル→おぉ、使い所あるけどやっぱ型ないのは慣れん！
出力変数宣言→うぉーー！！やっべーこれ！っかこれをまってたよまじでコラ
型スイッチ→スイッチ機能プラス。知ってたらオシャレレベル
値の破棄→ほぅ。知ってたら逆にわからん
参照戻り値と参照ローカル変数→？？。あっそういうことか！！マニア杉
ローカル関数→こういうの書きたがる奴いるなー（ぼく
http://ufcpp.net/study/csharp/cheatsheet/ap_ver7/
まだまだあるみたいなので後日感想を書いてく
