Home –  Archive
Monthly Archives: 2月 2017

DAHONとタイレルとタルタルーガを試乗しました。

埼玉サイクルエキスポサイクルハウスしぶやさんの試乗会をはしごして
折りたたみ自転車の試乗をしてきましたヽ(=´▽`=)ノ

今回の試乗ではタルタルーガが良い意味ですごく印象的でした。その辺も含めてどんな感じだったかといいますと・・・。

DAHON MuElite

たぶんDAHONのスポーツ系折りたたみの最上位機種だと思います。
こちらは最上位だけあってお値段が約30万円します。
DAHONの折りたたみ自転車はリーズナブルというイメージがあったりするのですがコレは全然そんなことない・・・。

乗り心地

小径車は乗り心地良くないって聞くけど意外とそうでもないかな。少なくても20km強ぐらいでは問題なさそうです。
今乗っているDEFY4とあまりかわらない感じかも?

今回試乗した中で2番目に乗り心地が良かったです。一番はタルタルーガですが、あちらはサスペンションがありますので。

操作性

私にとっては普通のロードかなと。
ただ、ただ。テクトロのブレーキは止まる気がないなぁと再度思い知りました。

その他(感想)

DAHONといえば、タイレルとかに比べて折りたたんだときのサイズが小さいイメージがありましたがコレは違う・・・!
でかい!ドロップハンドルの折りたたんだ時にすごく邪魔になっている。

  • お値段がこの中で一番高い
  • フレームが中折する(DAHON全般そうですが・・・)
  • フロントシングル仕様
  • 折りたたみがイケてない

というのがあって残念ながら購入候補になりそうにないです。。。

DAHON MuSLX

ちょっと前までこれも候補でした。
軽いし、その割に売れていないのか特売っぽいのをチラチラ見たりしたのでw

乗り心地

振動とかは特筆すべきところが特にないというか。記憶にないというか・・・。
今回試乗して思いましたけど私が走る速度帯ではそんなに乗り心地悪いと思いませんでした。

ただポジションはフラットバーなので全然違いますね。
たぶんハンドルとシートの高さの調整である程度制御出来るのかなと思いますが、
試乗した時は体が思いっきり上がるんだけど、ママチャリとも違うしなんか走りづらかったです。

当たり前だけど、MuElite程走らない気がします。

操作性

やばい。なんか走り出しの時に安定しない。クイックな反応と言うべきなのでしょうか。
慣れればそうでもないのかもしれませんがふらっっとします。

タルタルーガではそこまでではないので、ステム長やハンドルの横幅の問題かもしれません。

その他(感想)

とりあえず、乗ってみて購入候補から外しました。
個人的にドロップハンドルの折りたたみがいいかもなぁと思いました。

Tartaruga Type SPORT DX, GT

試乗する前と後で印象がガラリと変わっった自転車です。
最初は大きいし輪行しづらそうだし、と思っていたのですが大きいぶん工夫されていました。
あと最上位グレード(DX)がフラット、その下(GT)がドロップハンドルという変わっている構成です。

乗り心地

このなかで一番乗り心地がいいです。
その割にふにゃふにゃしていなくて、長距離ライドしても疲れが少なそうですね。
タルタルーガの売りの一つであるサスペンションのおかげかなと思います。

操作性

フラットバーのDXでもMuSLXで感じたクイックさはそんなに感じませんでした。
ドロップハンドに関してはコントロールレバーはシマノではないです。その為、シフト操作に戸惑いがw

シフトボタンも硬かったので個人的には他のに変えたいかもしれません。
タルタルーガ買うならフラットバーのやつがいいかもですヽ(=´▽`=)ノ

その他(感想)

タルタルーガはスペックに現れないところが凄いと思っています。
この辺は話を聞かないとなかなかわからないものですね。

タルタルーガの折りたたみは2種類あるうちイージーフォールディングという形態を使うことが多いようです。
この場合、ブロンプトンのようなコロコロ輪行が可能です。
専用の輪行バッグを使うと、輪行バッグの一部だけを開いてコロコロ輪行が出来ます!!しかも閉じられるのでJRとかの持ち込みも大丈夫なんです!!

また折りたたんだサイズは大きいものの、奥行き?は他の折りたたみと大差なく実際の輪行にはそんなに影響しなさそうです。

荷物もたくさん積めますし、よく考えられているなぁという感想です。

Tyrell FX

もっとも予想と実際が変わらない自転車だった気がします。

乗り心地

ロード波でしょうか。20〜25km/hではうちのロードとあんまり変わらないかな?と思いました。
なんか特筆すべきことがない(;・∀・)

もしかしたらこれ以上だとロードとの差が出てくるのかもしれませんが、まぁその辺はしょうがないかなと。
元々貧脚ですし出来る範囲で走れればw
メーカーの人曰く100kmとか走る人とかおすすめですよみたいな事言っていたような気がします。

操作感

シフトレバーとかうちよりグレードがいいので切り替えがいい感じだった記憶があります。
うちコンポClarisだからこっちのほうがグレード高いよ、チクショウ(´;ω;`)

その他

全体的には一番ロードに近い気がします。
MuEliteをフロントダブルに出来ればソッチのほうがロードっぽい気がしますがお値段が高いのと、フレーム折るのが気に入らない_| ̄|○

試乗をしてみて

候補としてDAHONはなくなったかなぁと。
製品としてはよく出来ているとは思いますが私の趣味と合わないというか(笑)

現時点ではTyrell FXが現状に一番沿ってる気がします。
週末だけ持ち出すのであればタルタルーガの選択肢もなかなか。。。

そんなわけでまだまだ悩みは続きそうですw

ASP.NET Core で複雑なバリデーションをする

本日もメモがてら・・・

ASP.NET Coreのバリデーションはモデルにアノテーションを入れるだけでサックサクに出来るので楽させてもらっています。
最大文字数制御や正規表現による入力規制とかは大丈夫なのですが、色々な要素が絡みあった入力チェックをしたいときがあります。

別テーブルのデータを見てとある入力がある場合は入力を特定の値に制限するなど、別テーブルまで絡んだりすると標準のバリデーションでは出来ないのではないかと思います。

ASP.NET CoreではIValidatableObjectを実装したクラスに対してValidation時にValidateのメソッドを呼び出してくれます。
そこでモデル全体としての入力チェックが出来るので、そこで行うと良いみたいです。

この時にDbContext(ApplicationDbContext)が使いたくなることもあると思います。その場合はvalidationContext.GetServiceで取得することが可能です。
データベースに以外にもサービスが定義されていれば必要に応じて取得できそうです。

using System.ComponentModel.DataAnnotations;

public class HogeHoge : IValidatableObject
{

    // 〜〜〜 色々省略 〜〜

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        //DbContext取得
        var dbContext = (ApplicationDbContext)validationContext.GetService(typeof(ApplicationDbContext));


        if(true){ //本当は入力チェック(;・∀・)
            yield return new ValidationResult("エラーメッセージ");
        }

    }
}

EntityFramework Core(EFCore)で更新日時を自動的に入れたい

あとで忘れないようにφ(..)メモメモ

EntityFrameworkでデータを更新した際に自動でデータを生成・保存したい項目ってありますよね。
更新日時とか更新ユーザー名とか。

更新日時とかはRailsであればcreated_atとか項目作っておけば勝手にやってくれますが、
EntityFrameworkでは違うみたいです。

色々調べたところDBContextのSaveChangesをオーバーライドして、保存処理が走るまえにデータをいれて上げるのが良いみたいです。

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{

    //〜〜〜〜〜〜〜〜省略〜〜〜〜

    public override int SaveChanges()
    {

        var now = DateTime.Now; //毎度Now取り出すとコストが掛かるのと、更新日時がレコードによって異ならないように。
        var changes = ChangeTracker.Entries<Kokyaku>().Where(p => p.State == EntityState.Modified || p.State == EntityState.Added).Select(u => u.Entity);
        foreach (var change in changes)
        {
            change.UpdDate = now;
        }
        return base.SaveChanges();
    }

}

こんな感じのロジックでKokyakuクラスに関しては、UpdDateフィールドに自動的に更新日時が入るようになります。Kokyakuの部分を親クラスにして、親クラスにUpdDateのフィールドを作るというのが一般的な流れになりそうです。

Webアプリケーション等で更新ユーザーを保存する場合、SignManagerやUserManagerをDIして現在のログインユーザーを保存・・・・と行きたいのですが、A circular dependency was detected for the service of type ‘Microsoft.AspNetCore.Identity.UserManager
などとDIが循環していると怒られてしまいます。

更新ユーザー名を保存するにはもうActionFilterを利用するなど少し仕組みを考える必要がありそうです。