タイムズと車を所有した場合に掛かる金額を比較してみた
最近はタイムズのカーシェアが流行りまくっていて、車を持つ人が減るレベルで素敵なサービスを展開しています。車を保有する人にとって「実際問題、どっちが金掛かるの?」って疑問が湧くと思います。僕もどっちがお金かかるのか疑問だったので、僕が使ってる頻度でどれだけ差が出るのか検証してみました。
(注)あくまで僕が普段使いしてる範囲の話。あとタイムズの回し者ではないし、批判してるわけでもありません。まぁ、すげーてきとーなんで、あくまで参考程度に。
前提条件
僕 : 週5電車通勤
車種 : コンパクトカー
使う場面
お迎え 週3回 15分/1回
買い物 週2回 2時間/1回
実家 月2回 6時間/1回
旅行 3ヶ月に1回 72時間/1回
だいたいこんな感じです。タイムズのレンタル時間に合わさせてるのもありますが、まぁ、こんなもんでしょう。
車を所有した場合に掛かる金額を計算してみます。
ガソリン 月2回 8000円
税金 年1回 34500円
保険 年1回 100000円
ローン 月1回 30000円
JAF 年1回 6000円
駐車場 月10000円
月にすると59708円
年にすると716500円
次にタイムズのカーシェアを使った場合に掛かる金額を計算します
家族プラン 月1回 1030円
迎え 月12回 206円/15分
買い物 月8回 1648円/2時間
実家 月2回 4020円/6時間
旅行 3ヶ月に1回 24690円/1回
+ 距離料金 3200円(200キロ計算)
TCP安心補償サービス 月23回 309円/1回
月すると79652円
年にすると955824円
なんと普通に普段使いして年間20万ちょっとタイムズが高いと言う結果になりました。実際に僕が掛かっている金額と比べてエグい差※1が出てしまったので、保有した方をかなり盛っていますがだいたいこんなもんでしょう。ただ、都内に住んでいたり車に乗る頻度が少ない人はタイムズの方が得になる場合があると思います。さらに僕の場合は、コンパクトカーなので、もっと良い車乗ったら話が変わります。結論として、都内に住んでいたらカーシェア、都外だと車を保有した方が良いことがわかりました。ただ、タイムズだと車が使われていたり、忘れ物出来なかったり、駐車場に行かなきゃいけなかったりと買った方がお金的にも精神的にもお得だなあと感じてしまいました。乗り出し50万ぐらいでそれなりに状態が良い中古車が売ってるのでマジで絶対買った方が良い!いやマジで
【第2弾】React使ってちょっとしたもの作った
大したものじゃないんですが、課題だった日付の検索プルダウンを実装しました。数年に遡って週ごとにプルダウンを出してたのですが、使いづらすぎる、量が多すぎる、パフォーマンスも気になるので整えました。インデックスが1000を超えたので(ページ数は2000弱)、そろそろサイト内でいろいろ見れるように整理する段階に入ったかなと思って使いやすくすることが課題でした。
前置きが長くなりましたが、どういう風に変えたのか画像を貼ります。
変更前↓
手抜き杉。
変更後↓
デザインも整えて検索しやすいようにしました。まぁ、この検索方法はどっかの有名サイトの丸パクリなんで間違い無いでしょう笑
2時間ぐらいでできるかなーと思ってましたが、結局、8時間(一人日)ぐらいかかっちゃったので苦戦したところをさらっと書きます(ちなみにReactはドドド初心者、Angularは3ヶ月程度仕事でやってる)
this.setState is not a function
なんやこれ?と思って調べたらbindを使わなきゃいけないらしい。書き方は以下。
this.{メソッド} = this.{メソッド}.bind(this);
なんかthisの指すところが違うからbindしてthisを示す必要があるみたい(よくわからないけど)
TypeSctiptが辛い
修行だと思ってるけど本当に苦行。めんどくさいのでstate、propに型をanyにしてるのですが、いちいちcastしなきゃいけなくてめんどい。型宣言するとスラスラ書けないからanyにしたけど結局めんどいから、結果どっちもめんどい(笑)これとかねもう。
this.state.tests as string[]).map((value) => <option value={value} selected=true >{value}</option> )}
つらみ
他Domが操作できなくて辛い
Aungularでもできないのですがね、Reactだと出来ると思っちゃった(笑)Jqueryの置き換えだから結構めんどくさかった。
なんとか出来るのですが、非推奨なのでやらないでください。結局onchangeで対応した。
refでやる
<input type="email" ref={ input => { this.Input = input }} /> React.findDOMNode(this.refs.Input)
結局fetchでいいよね?
使いやすいからfetchを選定してるけど、どれが良いのかわからん。
コンポーネント化することでサーバー側のコードが綺麗になる
コンポーネント化することで、クライアント+APIで対応出来るのでその分サーバ側のコードが減りました。
辛いところじゃないと思うのですが、直すところが増えるので大変。ここも時間かかった一つの要因だけど、結果よかった。
いろいろ辛かったけど、結果綺麗に出来た気がする。
次はこれやるよー多分
github.com
AutoMapperでifって書きたいときどうするか
C#のWEB開発ではAutoMapperが欠かせないレベルでかなり重要なのですが、完全にマッピングするのはやっぱり難しかったりします。MapFromだと三項演算子しか書けなくて読みづらい場合も出てくるのでifでかける方法を探しましたらあったので、備忘録的に書き残しときます。
まず普通のMapFromで書く場合(下のリンク丸々引用)
Mapper.CreateMap<SomeViewModels, SomeDTO>() .ForMember(dest => dest.Date, opt => opt.MapFrom(src => src.HasDate == "N" ? null : DateTime.Parse(src.Date.ToString())));
この程度ならいいのですが、もうちょい複雑になると困ります。なのでifで書くときはResolveUsingを使います。
ResolveUsingの使い方
Mapper.CreateMap<SomeViewModels, SomeDTO>() .ForMember(dest => dest.Date, o => o.ResolveUsing(Converter)); private static object Converter(SomeViewModels value) { DateTime? finalDate = null; if (value.Date.HasDate == "N") { // so it should be null } else { finalDate = DateTime.Parse(value.Date.ToString()); } return finalDate; }
Funcを渡せるので非常にわかりやすくなりました。MapFromとResolveUsingだと若干違います。
void MapFrom<TSourceMember>(Expression<Func<TSource, TSourceMember>> sourceMember); void ResolveUsing<TResult>(Func<TSource, TResult> resolver);
ResolveUsingはExpressionがないですね。これだと完全マッピングの道に近づくからうれしい!(まぁ、AutoMapperで完全マッピングすると逆にカオスになりそうですが笑)
Azure Schedulerの簡単な説明と使い道について
結構前からあったサービスですが、「これ結構使えるじゃん!」って思ったので簡単な使い方と僕なりの使い道を説明できれば。
Azure Schedulerとは
Azure Scheduler では、Azure の内部と外部でサービスを呼び出すジョブ (HTTP/S エンドポイントの呼び出しや、Azure Storage キュー、Azure Service Bus キュー、トピックへのメッセージの送信など) をクラウドに作成します。ジョブを今すぐ実行するか、定期的なスケジュールで実行するか、または今後の特定の時点で実行するかを選択できます。
定期的に動かしたい処理を実行できるサービスってことです。クエリやらストレージ処理やらRESTやらいろいろ対応してるよってやつ。ここら辺の用途でAzure FunctionとかWebJobが有名ですが、一番簡単でかつシンプルに管理できるので使い勝手がめっちゃ良いと思ってます。
値段は?
azure.microsoft.com
ここを見てもらえればわかるのですが、1分単位で最大50ジョブまで使えて1500円強です。まぁこんなもんですかね。タスクスケジューラーとかで管理しているコストを考えれば安いし、でも高いしみたいな。昔はFreeで1時間単位のやつがあったようですが、なくなっちゃったんですかね?それとも従量課金だからかな?まぁいいや
簡単な使い方
Azureのポータルからすべてのサービス>管理ツール>スケジューラ ジョブ コレクションを選択します。
以下の画面からタスクの設定を行います。
- 名前
スケジューラーの名前を入力します。用途に合わせて設定してください。
- ジョブコレクション
プランの設定です。3種類あるのでこれも用途に合わせて設定してください。僕は1500円の一番安いやつを選びました。
ここも用途に合わせて。
- アクションの設定
ここは、REST APIを投げるパラメータの設定やらなんやらです。
- スケジュール
スケジュールの設定です。1分単位で設定できます。UTC+9が日本時間なので、用途に合わせて設定して下さい。
どんな感じ?
僕の場合は4つジョブを設定しています(もったいな!)。ちゃんと実行結果が出て、エラーが発生したら何回リトライするか、どんなエラーか詳細にわかるので良いですね。レスポンスがなかなか来ないAPIだとタイムアウトになっちゃうので、そこらへんはいつか調べます(絶対調べない)。
どこに使えるか
スケジューラーなので定期バッチなどに使えるかなと思います。僕のサイトは、規模が小さく、夜中のアクセスがほとんどないので一つのサイトにAPIをまとめていて、4〜5時の間で実行しています。今までの定期バッチだとタスクスケジューラーで定期的にconsole Appを実行するって流れが一般的だったと思うのですが、RESTにすることで意味不明な名前だったり、意味不明なオプションがはっきりして管理しやすいなと個人的に思います。RESTの良いところは、基本名詞で名付けて動詞はHttpメソッドでわかるので、ドキュメントにも起こしやすく管理しやすいのがメリットだと思います。RESTについては、以下のサイトがわかりやすかったかなと。
qiita.com
Azure Functionを試したのですが、書き方が若干異なったり、サービスとソースが分かれる(ここはあまり調べてないからわからない)のがしっくり来なかったのでこれが一番シンプルで管理しやすいかなと思いました。
定期処理をどうするかは課題で、お金をかけたくなかったのでGCPなど調べましたが管理する場所を分散させるのは一番のコストだなと思いました(学習面も含めて)。若干お金がかかるのがマイクロソフトのやらしいとこだなぁと思いますが、だいたい欲しいと思ったPaasが一番揃ってるのはAzureの良いところだなと実感しました、
結婚式の準備が終わってるレベルで大変だった
全く技術関係ない笑
とりあえず、スゲー大変だった。まぁ、参考になるか分からんけどつらつら書いていく。ちなみに男目線の話。結論としてはちゃんと計画的に準備しないと辛いからコツコツやった方がいいよってことを書いてく感じ。
式場を探すときもちゃんと考える
ブライダルフェアで、高級料理食えるよとか言われるけどちゃんと選んだ方が良いです。フォアグラなんて毎週食べるもんじゃないすね。毎回見積もりを出されるのですが+100万で考えた方が良いかも。結果的にどこも同じような金額になるので、20〜30万ぐらいの差額で式場決めるのはもったいないとおもいます。
ブライダルフェアの愚痴は以下に書いてました(笑)
呼ぶ人を真剣に考える
ここはガチ。適当な友達は絶対呼ばない方がいい。あまり仲良くないのに飲み会とかで「参加するから呼んでー」とか言う奴はフルシカト。ここは、ご祝儀に関わるところだから後味悪いと嫌だしね。まぁ、ここは人それぞれかなぁ。
招待状を早めに手配する
プランナーから指示があると思いますが、招待状を早めに手配した方が良いです。書く時間があるから結構だるいっす。
ドレスは何回も試着してから決めよう
これは妥協試着ダメ。一番いいと思ったものを着ましょう。一生残るので、着たいものを着させたあげましょう。男は一番安い適当なもんでおっけ。
動画は構成から決めてつくる
曲とどんな画像を差し込みたいか決めます(赤ちゃんの頃の写真とか入学とか)。曲は良いところで終わりたいので、ネットで拾ったような画像やらでプロトタイプを作ります。最後に写真を差し替えるだけで、ちゃんとしたムービーになりますよ。この方法でプロフィールムービーを諦めていましたが、一日で撮影と編集が完了しました。ちなみに動画編集ソフトはiMovieです。
DVD書き込みはIDVDっす。これはhigh Sierraでも無理矢理インストールできるのでこちらを参考に
iMovieのテキストがクソダサいのでアニメーション作成のアプリを使いました。
複数の動画を並べられるやつ
これ無敵。
昔の画像はスキャナー使う
スキャナーあるとマジで楽っす。僕はこんな感じの持ってたんで役に立ちました。
サンワダイレクト ハンディスキャナ カラーディスプレイ搭載 スキャン結果を即確認! OCR機能 A4 自炊対応 最大900dpi対応 400-SCN032
- 出版社/メーカー: サンワダイレクト
- メディア: オフィス用品
- この商品を含むブログを見る
席次表は業者にお任せ
このサイトで作りました。正直、値段とか安くないし、全然席次表に向いてるものじゃないから無理にオススメはしないかな。席次表の画像とか、テンプレートがいいのなかったから自力で作ったりとかそんなに席次表には向いてないです笑。まぁ、品質は結構いいんじゃない?って感じ。
チャットする
基本、担当分けして作業していました(嫁は動画、俺は画像加工やらなんやら)。同じ場で作業してるんですが、urlとか共有したかったりするんでチャットを使いました。俺はGoogle Photoの関係でハングアウトを使いたかったのですが、なぜか嫁がSlackゴリ押しだったんでSlackにしました。
Googleアカウントで入ってるのにSlack意味ないっす
CDはメルカリ、TSUTAYAで
僕は時間がなかったのでブックオフ、TSUTAYAで買ったんですが、余裕を持ってメルカリやTSUTAYAで買った方がいいです。TSUTAYAはレンタル落ちの新作が売ってるので、安いし種類が豊富。ブックオフは高いし、新しいのがない。一回しか使わんのならレンタル落ちでいいよね。Spotifyでプレイリスト作ったんですが、なかなかテンション上がるのでいいですよ。
ウェルカムボード、席札はハンズで
ここら辺も手作りだったんで、ハンズに行きました。注意なんですが、ウェディンググッズは大型店舗しかないので、調べて行きましょう。全部で1万ちょいかかったかな?
ご祝儀多かった人には御礼を
やらしい話だけど、ここで友達度がわかる気がします。さすがに3万以下は一人もいなかったけど、昔からの付き合いあるやつなんかめっちゃ多くてビビりました。いくら親友とはいえども、はみ出た分は必ずお礼を。目安は祝儀の3/1。高すぎると相手も困るので、善意としてくれてる前提を考えたら3/1が妥当です。あと引き出物でギフトは渡してるので、なんか違うやつを選んだ方がいいかと。僕は一休のギフト券を渡しました。
職場の人は、引き出物で高いので渡してるから控えめにしました。
ホテルをとる
都内で式を挙げたので、ちょっと家から遠くていろいろ困るのでホテルを取りました。式終わって荷物詰めてあとは飲みに行くだけ。終電気にせず飲めるので楽っす。
二次会三次会四次回は絶対行きましょう
僕は二次会やらなかったんですが、意外にみんな待ってくれてました。式が昼過ぎに終わって、そのあと呑みまくってホテルついたのが2時過ぎ。これは感謝しかないですね。出来るだけみんなに会いましょう。
書き起こすと結構大変やなと実感してみたり。まだまだやったことはあるんだけど、これから結婚式をする人の参考になればと思います。
.Net CoreのRazorエンコードとかSEOの影響とか
.Net CoreのRazorは、デフォルトでエンコードされるように出来てます。これが普通に最低でした。みんなの洋楽ランキングは、タイトルをシステムで出力したりしてるんですが(以下)、それが全部エンコードされてわけわからん感じになります。
<title>@ViewBag.Title - みんなの洋楽ランキング</title>
こんな感じになる
.NET CoreのRazorはデフォルトでHtmlEncoder.Defaultってのが使われているのですが、これをエンコードしないようにDIして制御しなければいけません。なので以下のコードで制御します。
services.AddSingleton (HtmlEncoder.Create (UnicodeRanges.BasicLatin, UnicodeRanges.CjkSymbolsandPunctuation, UnicodeRanges.Hiragana, UnicodeRanges.Katakana, UnicodeRanges.CjkUnifiedIdeographs));
これはシングルトンにしてください。
最近SEO下がりまくってアクセスが激減したのですが、いくつか要因があるので一つずつ潰してます。
・iTunesアフリエイトのSVGがクソ重い(改善済)
・HTMLエンコード(改善済)
・導線とコンテンツ不足(日々改善)
一旦これで様子見て経過を書いていきます。まぁ今月は1万PV割れする可能性大なのでボロボロですね。
Net Frameworkではこんなことなかったので、気をつけなければ。。
.Net Coreの部分ビュー
同じビューを何回も書き続けるのが微妙なので、ASP.NET Coreでは部分ビューってのがあります(どのフレームワークにもあるけど)。ASP.NET5でもHTMLヘルパーであったのですが、ちょっと書き方が変わってるので備忘録として。
HTML5であった@Html.Partialとほとんど同じ機能ですが、.NETCoreになってHTMLヘルパーからタグヘルパーに変更されたのでクソダサい記述はなくなりました。さらにasync、awaitが使えるので非同期でビューを動かすことができるので、重いビューでも多少は大丈夫になった感じですかね?わざわざJS使う必要がないところとか良い感じでしょうか。
部分ビューとは
部分ビューとは、別のビュー内でレンダリングされるビューのことです。
1枚のページに複数のHTMLがかけるよ!しかもMVCでってこと。つまりこういうことです。
この赤い部分は再利用するので部分ビューにしています。
部分タグ ヘルパー
以下の記述ではViewsのSharedにある_TestPartial.cshtmlがタグを記述したところに挿入されます。
<partial name="_TestPartial" />
非同期もいけます。
@{ await Html.RenderPartialAsync("_TestPartial"); }
パスを指定すれば、ディレクトリわけもできます。
<partial name="~/Views/Hoge/_Test.cshtml" />
モデルをバインドされる場合は以下です(試してない。
<partial name="_Test.cshtml" for="Model" />
非同期は、.NETCoreになってから追加された機能(おそらく)なので、わざわざJSフレームワークでやる必要はねぇなと思う場所には使えるかもしれません。モデルバインドも部分ビューもめっちゃ使えるのですが、結局依存しまくって汎用的に使えなかったり、技術負債になりがちなのでちゃんと考えて使った方が良いかもしれませんね。導入するのは比較的簡単なので、ビューのメンテナンスがめんどくさいなと思ったら導入するぐらいの気持ちでやった方が良いと思います。