tekitoumemo’s diary

思ったことを書くだけ。長文版Twitter

雪道を走るのにコンパクトカーで余裕だった話

車

1/22の雪は凄かったですねー。僕は休みを取っていて、丁度、スタットレス履いたのでガンガン走りました（150キロ）。愛車のフィットはFFなんですが、ある程度の雪道は行けたので車を買う人などに参考になればと思います。あと

「FFじゃ雪道走れねーから！！」

って言うやつらに物申したい！ついでにSUVの悪口も言いたい！

まず、僕の車情報から
車種:フィット
型番:GE6
モデル:スマートセレクション


タイヤ:15インチスタットレス（割と消耗してる）

フィットの型落ちだけどちょっとグレードが高いよってやつ。もちろんFFで1.3Lしかないので、パワーがない。

FFとは？


フロントエンジン・フロントドライブと言って前にエンジンが付いていて前タイヤしか動かねーよ！ってやつです。一般車では一番多い方式で街乗りに最適とされています（コストが安いってのもあるけどね。）。その他FR（フロントエンジン・リアドライブ）と言って前にエンジンが付いていて後ろのタイヤしか動かねーよってやつと4WDと言って四輪全部動くぜ！ってやつがあります。当然、雪道だったら4WDが一番良いです。

どのぐらい走れるのか？


一番気になるところですが、昨日の雪で行けたので積雪10〜15cmは走れました。傾斜がある坂道だとダメでしたが、246号線沿いの坂道レベルだったら余裕です。エンジンを積んでる箇所に一番加重がかかるのでFFは意外にも雪道に向いていました。

なぜスイスイ走れたのか考えてみた。

パワーがないし、FFだし、小さいし雪道には向いていない要素がたくさんあるのになぜこんなに走れたのか、いくつか考えてみました。

車体が軽い
ほとんどこれが一番の答えだと思います。コンパクト
カーは燃費と車内の広さの関係で非常に軽く作られています。その大きさは何と1トンぐらい。車体が軽いことで、フロントタイヤにエッジがかかったらすぐ車体が動くことで多少の積雪でも簡単に進むことが出来たんだと思います。

パワーがない
これは何とも言えんことですが、加速が全然ダメです。パワーがなくてなんで良いかと言うと、高回転で雪を掻くと深く掘ってしまい、そこから進めなくなります。低回転でゆっくり走ると雪を掻くと言うよりは踏むので、少しずつ進むことが出来る気がします。走っていてミニバンとか軽バンが立往生していた印象があります。

4WDじゃなければ雪道は無理だと言うやつらへ


SUVを否定するわけじゃないけど、関東圏に住んでいたら雪なんで数年に一度しか降らないし、燃費も悪くて車内も狭い。ましてはオフロードなんか全く走る機会がないから見た目以外で買う意味があまりないと僕は思います。SUV乗りって性能面で何かと理由を付けてゴリ推してくる人が多くて見た目で選んでるのに素直じゃない印象なので、そこらを含めてあまり好きになれません。ヴェゼルなんかはFFもあるし、なんかもう意味不明だよ！

じゃあコンパクトカーは良いのか？と言うと


良くないです。見た目ダサいし、ロードノイズがすごくて音楽なんで聞けたもんじゃない。メリットと言えば意外に車内が広くて燃費が良くて値段が激安。僕なんで車体自体は40万ぐらいで買いました。悪いところはめっちゃありますが、乗り物という観点ではかなり点数が高いんじゃないかなと思っています。

最後に来年に出るであろうフィットのフルモデルチェンジバージョンについて


この記事では2019年に1リッターターボエンジン搭載のフルモデルチェンジされたフィットが発売されると書いてあります。1リッターになることで税金が安くなり、かなり経済的になります。1リッターと言えどもターボが搭載されていて1.5リッターのNAばりの馬力が出るだろうと言われています。これが出てしまったらコンパクトカーで一番車内が広くてパワーもあって燃費も良くて経済的なマシーンになるのでコンパクトカーの頂点をまた取ってしまうだろうなと思います。

【C#】AutoMapperのCreateMapが使えない！？

C#


AutoMapper が5.x系から静的メソッドが使えなくなりましたのでその話。CreateMapがエラーになってて「AutoMapper CreateMap 使えない」で検索しても出てこなかったのでここで書こうかと。

AutoMapperとは？

automapper.org
モデルを簡単にマッピング出来るライブラリです。ASP.NET MVCはViewにモデルを渡す必要があるのでかなり重宝します。データ抽出したモデルをビューモデルに追加するときとか便利！

どこが変わったのか

静的メソッドが動的になり、スレッドセーフになったりパフォーマンスが改善されました。5.x系以前の使い方は以下の通り。

using AutoMapper;
// Mapperを作成
Mapper.CreateMap<Model1, Model2>();
Model1 model1 = new Model1 ()
{
  Name = "saito",
  Age = 28
};
// Model1のデータがModel2の型でマッピングされる
var model2 = Mapper.Map<Model2>(model1 );

そして5.x以後の使い方は以下の通り。

// Mapするモデルの設定
var config = new MapperConfiguration(cfg => {
    cfg.CreateMap<Model1, Model2>();
});
// Mapperを作成
var mapper = config.CreateMapper();
// Model1のデータがModel2の型でマッピングされる
var model2 = mapper.Map<Model2>(model);

ラムダでマップするモデルを設定してMapperを作成と以前と比べてコード量が増えましたが、作者は静的メソッドで作成してしまったことについてずっと後悔しており、以下のリンクでその内容について述べてます。
Removing the static API from AutoMapper | Jimmy Bogard's Blog
TOEIC100点も取れない僕が解釈した内容だと
ずっと静的メソッドで作ったことを後悔していて、さらにJeffrey PalermoっていうHeadspring Systems社の最高技術責任者に「静的メソッドじゃだめじゃね？」って言われて直してたら動的で行けそうだったから完全移行するよ！って内容（だと思う）です。

正直スレッド問題とかパフォーマンスの問題は直面することはなさそうだけど、staticでインスタンスが作られるのは怖いよねってことでアップデートするのはおすすめです。

【C# + ASP.NET MVC】HTMLヘルパーのメリット、デメリット

C# ASP.NET MVC

久しぶりに技術ネタ。

HTMLヘルパーは非常に便利でスマートに書けるのですが、実際に運用していてデメリットも多いので、そこらを書いていきます。

HTMLヘルパーとは？

ASP.NET MVCのフォームレンダリングです。簡単に言うと冗長になっちゃうビューに記述するフォームロジックを簡単にかけまっせ！というやつです。

メリット

簡潔にプログラムっぽく書ける。テストを書ける。独自ヘルパーを作れる。書き方例を以下に記載する。

// リスト作成
model.SelectListItem = model.Select(m => new SelectListItem
 {
    Text = m.Name,
    Value = m.Id.ToString()
 });
// View側 model.Idと一致した行がデフォルト値となる
@Html.DropDownListFor(model => Model.Id, Model.SelectListItem, "選択してください")

model.SelectListItemを生成してView側にレンダリングしたいモデルをラムダで指定するとselect、optionタグを生成してくれるから簡潔に書ける。最高。

デメリット

デザイナーとのやりとりが難しい。HTMLヘルパーの記述方法はデザイナーさんは知らないので「触らぬ神に祟りなし」ばりに弄ってくれない。

  @Html.TextBoxFor(model => model.name, new { size = 100, maxlength = 255})

上記の例でmaxlengthを300にしたいときに依頼される。クラス指定するとき依頼される。この程度はほんと小さなことなんですが、チマチマ依頼されると結構な工数になる。デザイナーの手も止まってしまうし、非常に良くないです。bootstrapを使うとき、HTMLヘルパーに直すのがめんどくさい！

まとめ

HTMLヘルパーは非常に良く、僕も大好きなのですが、運用していく上で工数が掛かったりスピード感が思うように出なかったりなど本末転倒になりかねないので、デザイナーとやっていくならあまりオススメは出来ないです。ただし、経験者や暇なデザイナー（学習に時間割けれる）がいる現場であれば使うべきだと思うので、そこは臨機応変に対応していければと思います。

最後に

Dapperのときも書いたのですが

開発者にとって使いやすい、簡単っていうのは非常に重要だと思います。最近思うのはプログラムが好きでないエンジニアの方が非常に多いということ。使ってもらうことに喜びを感じるエンジニア、仕様を決めて作ってもらうことにやりがいを感じるエンジニアが多く、多少冗長になっても簡単でわかりやすい仕様のライブラリを使うことはチームで開発する上ではかなり重要だと思いました。

お金の使い方がわからないやつなんなの？

独り言


嫁の愚痴シリーズ第2弾

嫁はほんとうにお金の使い方が下手くそ。っかあったら全部使う。こういうお金の使い方してるとなくなるよ！ってのを教える。

すぐ浮かれる

いいことがあったから贅沢！友達と遊びに行くからこのご飯食べに行く！これが不便だからこれ買う！

まず懐考えてからものを買うよね。月にどれだけのお金が使えるか把握して多少なりの計算してくれねーかな？記帳するだけで全然変わるんだけど。

ないものをチートで増やす

驚きまくったのが引っ越し。さすがに僕も貯金に手をつけるの嫌だったし二人の引っ越しだから7:3ぐらいで割ったけどそれがまぁ驚き。

俺「少し出してくれる？全部はさすがにしんどい」
嫁「いいよ！いくら必要かな？」
俺「○十万ぐらいかな？あとは出すよ」
嫁「わかった！」
俺「っかそのお金あるの？」
嫁「ない！お父さんに借りる！」

は？

っか何年働いてんじゃ馬鹿たれ。一人暮らししてて車買った俺ですら余裕であるわそんぐらいの金。そのあと怒ったらガン泣き。なんなんこいつ。 一生返さない模様。

御礼したがり

これは良いところなのかもしれない。
婚約指輪を買った時の話

嫁「ありがとう！ずっと大事にするね！」
俺「うん、余裕で大事にして」
嫁「御返ししなきゃ！なにが欲しい？」
俺「ホイール」
嫁「時計とかスーツとか買おう！」
俺「お金あんの？」
嫁「ボーナス！」

そこをあてにしてんのか。。うちの会社ほとんどボーナスないだろ。。

※結局、ボーナスほぼなかったのでお母さんが御礼するという始末。。

いいとこのお嬢さん

まぁ社長令嬢とかそんなんじゃないけど、有名大学出でそれなりの生活をしてきた人。周りが超大手とか外資とかザラなので感覚が狂ってるっか嫁がおかしい。超大手とか外資とかお金ガンガン使ってると思ってるから普通にバカすぎ。

そういつ奴らはちゃんと考えるから！

お金がないのを結婚式のせいにする

嫁「今月は結婚式が多かったから〜」
嫁「結婚ラッシュなの！」
嫁「出産祝いとか！」
嫁「誕生日も！」

俺もあるわ。月3回あったときはしんどかったが、計画できんだろ馬鹿たれ。


お金は俺が管理しよう。。

【C#】Listになってるクラスのプロパティを一行で変える

C#


小ネタ、めっちゃ小ネタ。みんな大好き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でパラメータを扱う

ASP.NET MVC C#

技術ネタ。

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# ASP.NET MVC

だっぱー


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を見てみると全然悪くない。っか良い要素が多過ぎて知らないくせにいきがってた感があります。批判するときはちゃんと調べましょう