いろいろ知らなくてハマったのでメモ
今の最新バージョンは、sam local start-apiコマンドに multiValueHeaders 対応が入っていないというバグがあるっぽい。
sam local start-api
sam --version SAM CLI, version 0.16.1
未だリリースはされていないが、developブランチには修正pull-requestがマージされている。
brewを使って最新のソースコードを使用してビルドする。
brew uninstall aws-sam-cli brew install --HEAD aws-sam-cli
ここで言及されている。次リリースされるらしい。
なるほど。他のruntimeはどうかわからないが、Goを選択した場合APIGatewayProxyResponseのMultiValueHeadersにomitemptyがついていなくて、いかなる場合でもresponse bodyにmultiValueHeadersが含まれて全部のリクエストでNGになってしまう感じか。これomitemptyつけてもいい気がするけどな。
おそらく他のランタイムだと multiValueHeaders キーを作らずにresponseを返すことができて、その場合はエラーにならないから気づかかなかった and 修正の優先順位が低かったとかなのかな。（違うかもしれないけど）
嫁氏がバイクを売るとのことだったのでビッスクーターを磨いた。
それだけで体が筋肉痛になった。どれだけ運動不足なんだろう。
上の画像になっているものを使おうと思ったが、結局はコンパウンドと真ん中のワコーズのやつだけ使った。
ワコーズのやつはざっくり言うと水がなくても洗車できる優れもの。油分があるのかな、少しワックスかけたみたいになる。
サビが雨で流れて外装にこびり付いていたので、コンパウンドで磨いて取り除く。これはいい。ついでに全体的に磨いた。これのせいで筋肉痛。メッキも磨いたら輝きを取り戻した。よく見たら コーティングクリーナー、ポリッシュ、コーティング のすべてやってくれらしい。ワックスかけたようになったのはこいつのおかげか。
あと、左から二番目のやつ、これは樹脂？スクーターの内側のプラスティックのツヤを取り戻すことができる優れもの。
でも時間なくて使えなかった。
磨くだけでもかなり綺麗になったので満足！
悩みに悩んで、ヤフオクでポチった。えい。
平成18年式、西暦2006年のバイク。12年前のバイクになるとは、結構昔だなぁ。
20万で買えるというのは安いと思う。Dトラッカー250を20万で買うなら、車検の維持費はかかるがKTM640を買ったほうがお得感がある。この値段なら最悪2年乗って壊れたら捨ててもいいと思ったが、調べてみるとエンジンヘッド周りメンテナンスを行ってあげれば結構持つみたいだ。ロッカーアームのベアリングがやられるらしい。購入したKTM640は1万キロしか走っていないので、当分はエンジン周りのメンテは不要っぽいし、ヘッド周りのメンテなら自分でもできそうなきがする。
あとはKTMユーザーには定番と噂のウォーターポンプシールの交換を早めに。
ぶん回すと壊れにくいらしい、了解しました(笑)
KTMはレース用バイクでメンテナンスサイクルが短く壊れやすいんじゃないかというイメージがあって不安だったので調べたが、LC4エンジンは市販車向けに作られているらしく信頼性が高いようだ。あまりちゃんと調べてないので間違っているかもしれないけど。。
本当なら最新のKTM 690 SMC Rがいいが、なんと言っても高い。どうせ乗れば転ぶのだし、あんなにいいバイクを買うと気を使って楽しめない気がする。
時間なくてあんまり乗らないし。。。
FIのモタードは初めて。FCRやTMRのように気を使わずに乗れるのかなと思うと楽しみ。
20万、車検と配送料を含め約25万で12年前のバイクだが十分にハイスペックな車体のはず！
なんで安いんだろ。人気無いのかな。古いからかな。まあちょっと外装ボロイし。いいバイクだと思うんだけどなぁ（まだ乗ってないけど）
フレームワークの上で開発しているといろいろ調べたりコード読んだりする必要が出てきて、なんかストレス溜まるし、一から書いたほうが早いのでは、みたいな気持ちになることがある。
実際はちゃんと逃げ道を用意してくれていたり、DIっぽくその処理は外部から注入できますよ( LaravelならXxxProviderとか )という風になっているので、ドキュメントをちゃんと読めば解決する。それでも試行錯誤してしまうけど。ある程度思想を理解しないといけない為だ。
この気持何かに似ているなと思ったら、人が作ったシステム・アーキテクチャの上で開発するときの気持ちに似ているかも。
join時の痛みで、有る種の成長痛である場合もある。
あまりにもやりたこととミスマッチしていたり、変更しづらすぎる、追加開発をしすぎて複雑になってしまっている、また開発者に業務知識が十分にある(どう作ればいいか知っている)場合だと一から書いたほうがいい場合もあると思う。
自分でアーキテクチャを設計し、継続的に開発して育てていく感じなら、こうはならずに使いやすいように随時少しずつリファクタしていけると考える。そういうのいいな。
