お金の使い方がわからないやつなんなの?
嫁はほんとうにお金の使い方が下手くそ。っかあったら全部使う。こういうお金の使い方してるとなくなるよ!ってのを教える。
すぐ浮かれる
いいことがあったから贅沢!友達と遊びに行くからこのご飯食べに行く!これが不便だからこれ買う!
まず懐考えてからものを買うよね。月にどれだけのお金が使えるか把握して多少なりの計算してくれねーかな?記帳するだけで全然変わるんだけど。
ないものをチートで増やす
驚きまくったのが引っ越し。さすがに僕も貯金に手をつけるの嫌だったし二人の引っ越しだから7:3ぐらいで割ったけどそれがまぁ驚き。
俺「少し出してくれる?全部はさすがにしんどい」
嫁「いいよ!いくら必要かな?」
俺「○十万ぐらいかな?あとは出すよ」
嫁「わかった!」
俺「っかそのお金あるの?」
嫁「ない!お父さんに借りる!」
は?
っか何年働いてんじゃ馬鹿たれ。一人暮らししてて車買った俺ですら余裕であるわそんぐらいの金。そのあと怒ったらガン泣き。なんなんこいつ。 一生返さない模様。
御礼したがり
これは良いところなのかもしれない。
婚約指輪を買った時の話
嫁「ありがとう!ずっと大事にするね!」
俺「うん、余裕で大事にして」
嫁「御返ししなきゃ!なにが欲しい?」
俺「ホイール」
嫁「時計とかスーツとか買おう!」
俺「お金あんの?」
嫁「ボーナス!」
そこをあてにしてんのか。。うちの会社ほとんどボーナスないだろ。。
※結局、ボーナスほぼなかったのでお母さんが御礼するという始末。。
いいとこのお嬢さん
まぁ社長令嬢とかそんなんじゃないけど、有名大学出でそれなりの生活をしてきた人。周りが超大手とか外資とかザラなので感覚が狂ってるっか嫁がおかしい。超大手とか外資とかお金ガンガン使ってると思ってるから普通にバカすぎ。
そういつ奴らはちゃんと考えるから!
お金がないのを結婚式のせいにする
嫁「今月は結婚式が多かったから〜」
嫁「結婚ラッシュなの!」
嫁「出産祝いとか!」
嫁「誕生日も!」
俺もあるわ。月3回あったときはしんどかったが、計画できんだろ馬鹿たれ。
お金は俺が管理しよう。。
【C#】Listになってるクラスのプロパティを一行で変える
小ネタ、めっちゃ小ネタ。みんな大好きLINQを使います。
Listのクラスのプロパティを一括で変えたいってときがあると思います(割と)そこでプログラム書きたくない主義の僕はふと思いつき調べたんで書きます。
まずは普通に一括でhoge1を1にします。
public partial class Hoge { public int hoge1 { get; set; } public int hoge2 { get; set; } public int hoge3 { get; set; } } var models = new Hoge(); // モデル生成部分は割愛 foreach(var m in models) { m.hoge1 = 1; }
なんかつーか微妙だよね。このレベルだったら一行で描きたいよね。ここではLINQを使います。
public partial class Hoge { public int hoge1 { get; set; } public int hoge2 { get; set; } public int hoge3 { get; set; } } var models = new Hoge(); // モデル生成部分は割愛 models.Select(m => m.hoge1 = 1).ToList();
はい、一行で終わりです。ここでのポイントはToListにしないとモデルの値が変化しないこと。LINQの評価はIEnumerableに要求があったときにされるので何かしら要求しないとただ単に内包したオブジェクトが出来上がるってだけ!
さらにif文とかでなになにだったら値を入れるみたいなことをしたいときあると思います。それが下の例
// 動確してません!スマホで記事書いてるし!! models.Where(m => m.hoge2 == 1).Select(m => m.hoge1 = 1).ToList();
hoge2が1の場合だけhoge1を1にする(1って言い過ぎだろ。。)一行で終わり。
このようにメソッドチェーンで繋いで結果を得ることが出来ます。今回のケースでなくてもLINQではいろんなことが出来るのでどんどん使っていきましょう!
※乱用はダメ。ただのforループって認識でいると乱用してる恐怖がわかるはず
【C# + MVC】CustomAttributeでパラメータを扱う
技術ネタ。
CustomAttribute便利ですよね。プログラムは大好きなんだけど一行でも少なく書きたい主義の僕にはひじょーに素敵な機能です。
パラメータでちょっと動きを変えたい!セッションで持つほどじゃないけどちょっとだけ!!
ってことは割とある?と思うので小ネタを。Areas使うときなんかは結構嬉しいと思う。
まずは普通のCustomAttribute
// HogeController.cs [HogeAttributes] public ActionResult Index(string param) { return View(); } // HogeAttributes.cs public override void OnActionExecuting(ActionExecutingContext filterContext) { // いろんな処理 base.OnActionExecuting(filterContext); }
この例でいくとparamの値によっては違うとこにリダイレクトさせたい!とかあると思います。
その例が以下です。
// HogeController.cs [HogeAttributes] public ActionResult Index(string param) { return View(); } // HogeAttributes.cs public override void OnActionExecuting(ActionExecutingContext filterContext) { // Parameters can be acquired with custom attributes. var param = filterContext.ActionParameters["param"]; // いろんな処理 base.OnActionExecuting(filterContext); }
ActionExecutingContextのActionParametersにメソッドの引数のパラメータ名を渡すと取得出来ます。keyvalueで入ってるので引数の名前変えると落ちます。
このやり方が良いかはわからんが、割と便利なのでオススメです。
【C#】Dapper使ってりゃ間違いないよ
だっぱー
C#のデータアクセスはいっぱいあるけどチームで使うなら結構最適なORマッパーじゃないかなと思い始めてるので、Dapeerの良さについて語ります。
ちなみにチームと言っても色んな人種(年齢やら経歴やら)がいるチームにDapeerは最適だと思ってるのでORマッパーマッパーしてる人ばかりだったらPetaPocoの方が良いです〉ぺたぽこ
そしてMS標準のEntity Frameworkは開発当初から捨て去りましょう。
型付DataSetとか記憶から消し去りましょう。
それではDapperの良いところを語って行きます。
早い、とにかく早い
この記事を見てもらうと一目瞭然。EFとか終わってるでしょ。EFとかでもやっていけるよ!って人に言いたい。パフォーマンスの調査をするときにどっちが原因かわからんでしょ。無駄に工数かかるし、パフォーマンス調査の結果、「だっぱー」だね!ってなるんだからとりあえず選んどいて損はない
実績豊富
グラニさんが使ってる。
大型サイトでの実績があり、安定感バツグン。シンプルってのはこういうとこが良いね。無駄な調査しなくて良いし無駄にStackOverFlowを漁らなくて良い。
※CEOの河合さんに会ったことあるけど、天才。恐ろしいぐらいオタク。本当に一緒にお仕事させて頂きたい。
生SQLを結構書く
これは賛否両論、むしろ生SQLを書くのは良くない風潮があるんだけど、40代以上の人はちょっと抵抗ある人が多いっぽいから生SQL書けるって良いなと思った。SQLは必ず通る道で誰でも知ってると思うので、学習コストが低いってかなり良いと私は思います。ORマッパーはデータアクセスのめんどいとこを差っ引いて使えるってのが魅力だけど、チーム全体で使えなければ開発効率もクソもないかなと思ってるんで生SQLを書くのは否定しません(2017/11月現在)。でもね、クエリビルダーのとかその他諸々の良さは知ってる、来月あたりに人間変わったように否定してるかも笑
daynamicが最強
ORマッパーの三種の神器(もっとある)としてデータマッピングがあるんだけど、むしろデータマッピングすらいらないじゃんって仕様がC#にはあります。C#はコンパイラ言語なんだけど、.Net4.0からdaynamicが使えます、要はインタプリタが使えるので、マッピングしなくても使えます。無駄なクラス作る必要ないし、型を変更したときとかクソ楽ってか何もしなくて良いレベル。
こんな感じで使える。
dynamic dynamicObj = connection.Query("SELECT id, name FROM table1 LIMIT 1").FirstOrDefault(); Console.WriteLine("Id: {0}", dynamicObj.id); Console.WriteLine("Name: {0}", dynamicObj.name);
ヤバくね?
インテリセンス使えんとかコンパイラでエラー検知出来ないとかタイポでバグるとかいろいろあると思いますが、テストは必ずやってるのが当たり前だと思うので、悪い点が見つかりません。C#はこんな感じで小賢しい天才機能があるので大好きです。
Dapperはあくまで経験が多い人も少ない人もいるチームで円滑に開発を進めるためのライブラリなので、技術好きで上級者は他のライブラリが良いかもしれません(僕も自分で作るならDapper使いません)初心者向けではありますが、いろんなこともできるので奥が深くて使いがいがあるライブラリなので、迷ったら是非使ってみてください。
後日談
Entity Frameworkを見てみると全然悪くない。っか良い要素が多過ぎて知らないくせにいきがってた感があります。批判するときはちゃんと調べましょう
DIYをする上で知っとくべきこと(知識編)
私はDIYが趣味で家の家具のほとんどが自分で作ったものになります。ここ五年近くやってきていろんなことを知ったのでここに書きます。
結構イケてね?
DIYって道具必要で大変だしやる場所がないよ!って言ってる人のために出来るだけ敷居が低くやれるよ!ってのを伝えたいと思います。
まずはこれを買ってください
高儀 EARTH MAN AC100V ドリル&ドライバー DDR-120
- 出版社/メーカー: 高儀
- メディア: Tools & Hardware
- この商品を含むブログを見る
GREATTOOL 6pcs. ショートタイプ下穴錐 GTTS?6
- 出版社/メーカー: GREATTOOL
- メディア: Tools & Hardware
- この商品を含むブログを見る
- 出版社/メーカー: SUREMAN
- メディア: Tools & Hardware
- この商品を含むブログを見る
これないと基本何も出来ない。手動は基本無理。これはもっとショボくていいかもしれない!高いに越したことはないけど、私はこれを使ってます。
下穴ドリル
ドリルにつけるドライバは付属で付いてるのでこれだけでまずは事足ります。下穴入れないと木が割れるので必ず必要。しかも下穴あけるとかなり楽。
巻尺
DIYの魅力の一つとして、ピッタリ合う家具が作れること。必ず必要。
次に木材に色を付けましょう
ワトコオイル ナチュラル W-01 [200ml] WATOCO・家具・壁面・建具・オイルフィニッシュ
- 出版社/メーカー: 北三株式会社
- メディア:
- この商品を含むブログを見る
素人でも簡単に綺麗に塗装出来る!すぐ乾く!初心者はナチュラル買いましょう、これはどんなものでも綺麗な色が出る。
【知っとくべき】木材の種類を理解しよう!
まずは集成材。こんな木。
木の節目がなくていろんな木材を結合して一枚の板になってる。DIY感出なくて本物の家具みたいな完成度になりやすい。加工されてるから下処理もしなくて良い(私はしますが)し、木目の色味が綺麗に出てかなりオススメ。さらに様々な木が結合されてるからしなりにくいのは本当に最高。でもそれなりの値段するのでニトリとかで買ったほうが安くなるケースも。
次はSPF材
2x4(ツーバイフォー)とか1x4(ワンバイフォー)とか呼ばれる。木の節目があって味のあるものが出来上がる。サイズも豊富で木材の強度もある。加工もしやすいし割れにくいから初心者でも完成度は見込めるよ!とりあえずめっちゃ安い、2x4の1.5メートルで300円台とかざら。
覚えておいて損はないベニア板
壁板とかの下地に使われることが多い。私の場合はDIY感出したくないのでベニア板を使って隠すことが多いです。
こんな感じ。
天板とか集成材だと高いのでちょっと厚いベニアで対応したりする。ベニアもいろいろあるのでその説明は割愛。
最後に、DIYのコツは
【.NET】jenkinsでnugetパッケージを復元してMSBuildする
技術ネタ。久しぶりすぎる。調べたことを書きためようと思い掘り出してたら一年前の技術ネタが出てきたから書いていく!
jenkinsでMSBuildするとnugetが復元出来ない。VisualStudioでは出来てたのにーウキーってなったけど、まぁ普通にMSBuildとnuget関係ないし当たり前だよねって話。
その前にMSBuildとdevenvの説明を簡単にする。
devenv
IDEを操作するツール。要はVisualStudioを操作出来るよ!ってやつ。VisualStudioのビルドはこれを使って実行される(厳密にはMSBuildだけど)
話を戻して、jenkinsではMSBuildビルドのプラグインしかないので、コマンドラインからdevenv使ったらいけんじゃね?と思って試した。
devenvの実行方法は以下。
cd {devenv.exeのパス}※PATH通してもOK Devenv "対象のsln" /Rebuild debug /out {ログのパス}
結果、nuget取れない。
VisualStudioいろいろやってんのかよ!なんだよ!優秀だなーと思いながら他の方法を試す。
nugetCLIってのがあった。
まずはプロジェクトにnugetCLIを設定する。
下のリンクわかりやすいね。
http://dany1468.hatenablog.com/entry/2013/04/21/114228
次にnugetCLIでパッケージを復元する
cd {package.configが入っているディレクトリ} {nuget.exeのパス} restore -SolutionDirectory {対象のslnが入っているディレクトリ}
これで問題ないが、カレントディレクトリに複数ソリューションがあった場合、エラーとなるのでその場合は以下のコマンドを入力する。
{nuget.exeのパス} install {packages.configのパス} -OutputDirectory packages
復元するパッケージはpackage.cofigに書かないと取ってこれない。書き方は以下(自動生成されるけど手動でもおっけぃ)ちなみに複数バージョンは入れられません。
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="AjaxControlToolkit" version="4.1.60623" targetFramework="net452" /> </packages>
jenkinsに設定
http://cointoss.hatenablog.com/entry/20111213/1323702126
http://mk3008net.hatenablog.com/entry/2015/03/29/124511
実際、上記の記事見たわけじゃないから参考になるかわからない。
packageはweb.configとの兼ね合いでアセンブリエラーになったりするので、可能な限り自動でインストールした方がいいと思います。
協力会社とうまく開発を進めるための心得
今回は協力会社とうまく進めるために必要な心得をつらつら書いていきます。よく下請けとか外注とかそのような言葉を使いますが、あまり好きな言葉ではないのでここでは協力会社と言います。
まず、私の状況と実践してる内容から。
納品物 : 設計書、コード、テスト仕様書
委託内容 : 設計からテストまで
環境 : 都内と地方
コミュニケーションツール : slack、skype
報・連・相 : 朝にやることを報告。夕方に成果を報告。
よくあるSIerの工程で上流工程は要件定義〜設計、下流工程ではコーディング、テストまでと言う内容が多いですが、私のケースではほぼ全て委託しています。正直言うと、私はうまく回せてません。納期が遅れるとか仕様と成果物が違うとかそこまでではありませんが、うまくコミュニケーションが取れないことが多々あります。そこで協力会社とうまくやるために意識していることを書きます。
協力会社は依頼された内容を作るだけ
依頼された内容を確実に作ってくれるならいいじゃん!って思う人が多いと思いますが、出来上がったコードを結合して動かしたら動かないなんてことは多々あります。こんなとき責める訳にもいきませんし、もっとシステムを理解して様々なケースに対応してくれるように考慮してくれれば、、と思うことがあります。そこは大きな間違いであり、協力会社は依頼された内容を言われた金額で確実にこなすだけなのです。そこらへんを勘違いしてあーだこーだ言ってる人は多いと思います。私の知り合いに外資出の企業家がいますが、そこまで優秀な人間でもここの認識は間違ってるような気がします。実際うまくいってないようですし。
縛りすぎない
前述した通り、私の場合は朝と夕方の報告を必ずやります。ただし、報・連・相を縛りすぎると報告することが仕事になってしまいます。協力会社にとって成果物が出来るまでの過程は、依頼会社をいかに安心させるか順調かどうかを重視します。そのため報告に対する力の入れようは驚くことがあります。ここで言いたいのは納品物に報告はないよ!と言うことです。報・連・相は社会人として当たり前と言う人が多いですが、協力会社にとっての当たり前は成果物を確実に納めることです。報・連・相は大事ですが、ここを縛ってしまうと協力会社の労働時間が増えたり、結果としてうまく回せないので縛ることはオススメしません。
コミュニケーションはskype
テレビ電話であればなんでもいいです。人間って不思議なもので顔の表情とか声のトーンとかで、相手がどのような状況なのか察することが出来ます。状況を踏まえて進捗や課題を話していくと認識の違いや課題がすぐ出てきます。さらにテレビ電話だと無駄に話が長くならないので、10〜20分で終わったりします。slackなどのチャットツールで何回もやり取りするよりこちらの方が早いケースもあるので状況によって切り替えるとうまくいきます。
その他いろいろありますが、良い関係を築けるパートナーとして仕事をするのが一番だと思います。上流工程とか下流工程とがで偉そうにする人がいますが、結局は井の中の蛙で人の能力に関係ないので、うまく回すことを最優先で考えるエンジニア、マネージャーが増えて欲しいと思っています。
偉そうに言っちゃった。。