git rebase は危険だ！悪だ！と言うガセネタに踊らされて rebase を怖がらないで！！！

rebase を恐れるなっ

rebase は危険だっ！push されてる場合は rebase するな！リポジトリを破壊するぞっ！絶対使うなっ！！

こんな脅し文句に踊らされ、人々は rebase に恐れおののき全力で逃げ出し理解すらしようとしなくなった結果、今日もログが荒れています。

私は悲しいです。

rebase は全く恐れなくて良いんです！むしろこんないい娘いません！！

本来一番自然な流れを作り出せるものですので、ぜひ理解して活用しましょう。

ってなわけで、訳の分からない変な呪縛から解き放つ、その手助けを今からいたします。

rebase は1つのブランチならば多人数でいじっている場合でも全く問題無いと言うか、merge の方が圧倒的に具合が悪いです。

rebase 実験

実験するとわかりやすいですからやってみましょう。

が、その前に以下を実行してください。

git config --global mergetool.keepBackup false

orig だの BACKUP だの作るのをヤメさせます。
(そもそも論 --abort だの reset だのがあるんだからこんなもんの必要性が全く無く鬱陶しいだけですし clean -f を毎回叩くのウザすぎです)

本サイトでは mergetool には vimdiff を使う事を強く推奨すると言うか、vim 使いましょう。それ以外認めません。

なので以下の設定を推奨です。

git config --global merge.tool vimdiff

[TODO]
rebase、marge でのコンフリクト解決の方法、vimdiff の使い方を機嫌が良い時に丁寧に教える記事を載せる。

その上で以下を実行してみてください。

[ Core ]

mkdir -p ~/git-test/remote/test
cd ~/git-test/remote/test
git init --bare

cd ~/git-test
git clone ~/git-test/remote/test a
git clone ~/git-test/remote/test b

echo 'base code' > a/code
cd a
git add code
git commit -m 'first commit'
git push
cd ../b
git pull
cd ..

cd a
echo 'bug fix by a' >> code
git add code
git commit -m 'bug fix by a'
git push
cd ..

command の詳細はまぁ rebase 使いこなそうとするぐらい気概のあるエンジニアなら見りゃわかるでしょって事で暴力的に説明を省きますが、ユーザー a と b が test をそれぞれ clone し、a が bug fix してpush している様を仮想的に行ってます。
a とb がそれぞれのユーザーの作業ディレクトリだと思ってください。

お次に、以下を実行してみましょう。

[ Bug fix by b ]

cd b
echo 'bug fix by b' >> code
git add code
git commit -m 'bug fix by b'

b がさらに bug fix しましたと。
ここで b が push してみると

git push // Error

a が push してて remote 側が新しくなってるから、pull しろっつって怒られます。
なので以下で rebase して、コンフリクト解消して push したとします。

(注: 以下の shell は貼り付けて一気に実行出ません。mergetool と rebase --con でエディタ開くので1行1行実行しましょう)

git pull -r
git mergetool
git rebase --con
git push

そうするとログはこんな感じになります。(ちなみにこのログは tig のログです。自分 tig しか勝たんと思ってるので)

o [master] {origin/master} bug fix by b
o bug fix by a
I first commit

a がやった修正の上に、自分の修正が乗っかってる自然なログですね。

そら rebase って自分の push してない commit を remote 側の最新引っ張ってきて乗っけなおす処理だから当然こうなります。
svn とか cvs の動作に近くて、全く不自然さを感じず理解しやすいですよね。

merge 実験

さぁ、今度は馬鹿みたいに merge してみましょうか。git の呪いを堪能です。

~/git-test 以下を全部消して実験コード[ Core ] と [ Bug fix by b ] を実行してください。

その後 b で以下を実行して merge します。

git pull
git mergetool
git merge --con
git push

ちなみに pull の際、エラーが出る場合は、

git config --global pull.rebase false

を実行してください。pull のデフォルト挙動が merge になります。以前までこんな設定せずともエラーにならなかったんですが、余計なお世話が入りました。

marge した結果のログが以下です。

M─┐ [master] {origin/master} Merge branch 'master' of /home/xxx/git-test/remote/test
│ o bug fix by a
o │ bug fix by b
I─┘ first commit

さっきは 3 行だったのが 4 行に増え、左側の部分も見づらくなりましたね。
さらに、時系列的に bug fix by a が先なのに、後に見えるようになり混乱出来ます。非常にありがたいですね。
まさにハッピーハッピーハーーッピーーーパピハピハピハピハーーッピーーーです。

まぁ、こりゃ remote の commit が先行したもんだから、そいつを自分ところの一番ケツにペシッとくっつけて、さらに merge で取り込みましたよ！とありがた迷惑な commit を作ってくれるからこうなるんです。

これ、remote 側に、まだ local に取り込んでいない commit が存在する際に push しようとすると、毎度こうなります。

これでログが最高に汚くなってログを開くたび絶頂を迎えることになります。

マジ最高！！ありがとうリーナス！！

rebase 一択

merge はあまりに最高すぎて絶頂を迎えすぎるため基本的に rebase 一択です。

なので

git config --global pull.rebase true

しても良いです。すると

git pull

が

git pull -r 

とおなじになるので。この場合 merge したいとすると

git pull --no-rebase

とオプションが長くなりますが、まぁ merge する機会の方が少ないので良いかと思います。

が、自分はもう手癖で git pull -r とやっちゃうし、普段は tig でやってるんでこの設定はしてないです(照)。

merge の混乱

ちなみに remote 側が一切触られていない merge は rebase と同じ結果になります。

それが ff です。フレンドリーファイアーでありファイナルファンタジーであり、forfeit であり surrender で gg です。ま、ff とかこんな言葉くっそどうでも良いので気にしないでください。

つか merge の挙動が remote の様子で変わるのがどうだっつぅ話ですわ。これが混乱の元。激キモオヤジの嫌がらせです。

rebase 使えと言っても、他のブランチに対してコードの統合を行う場合は rebase -> merge と言う流れになるのでちょっと混乱するかもしれません。これは私のせいではありません。git の出来が悪いだけです。

rebase で統合先の最新コードを引っ張ってきといて、それをそのまま統合先に merge で追加って感じです。

簡単に、この悪質な merge の挙動をまとめると以下のようになります。

remote 側に新しいもんが無い

rebase と同じになります。remote の状態に自分の変更が乗っかる一番自然な代物です。

remote 側に新しいもんがある

remote の変更を今の自分の変更の上に余計なコミットとして乗っけてくる理解不能で劣悪な代物です。

他ブランチ取込 rebase 時の push --force に注意

話を戻して rebase が全く問題ないか？と言うと問題が発生する場合があります。

それは 他ブランチを取り込む場合、かつ自分が rebase の作業中に誰かがブランチに push した場合です。この push を消す可能性があるんです。

分かりづらいですかね。現実的なシチュで説明します。

master から新機能開発のために dev ブランチを切りましたと。

a が dev で新しい機能を追加しました。それを master に merge するために dev に対して現在の master で rebase します。

そら dev の元となった master に変更があったらそれを取り込むのは当たり前ですよね？

master の最新を取り込んだ dev を master に突っ込みます。終わり。

普通は特に問題は発生しません。

ただ、問題が発生するのが、rebase した後に、ブランチに対して変更をいれたやつがいる場合です。

もしその変更が push されていた場合、その commit が消えます。しかもおそらく気づかない。そっと消えるのでｗ。

まぁ消えたっつっても reset 使えば戻せるは戻せるから noob が騒ぎ散らすだけですがね。

んで、これは rebase が悪いのではなく、rebase 後の作業ブランチを強制的に push する

git push -f

がアブねぇって話です。(オプション長くて見るだけで憂鬱になる --force-with-lease を使えば安全って話でもないですよ)

回避策ともども説明しましょう。

他ブランチ取込 rebase 実験

さぁさっそく実験です。まずは、問題無い rebase です。以下を実行してください。

[ Core 2 ]

mkdir -p ~/git-test/remote/test
cd ~/git-test/remote/test
git init --bare

cd ~/git-test
git clone ~/git-test/remote/test a
git clone ~/git-test/remote/test b

echo 'base code' > a/code
cd a
git add code
git commit -m 'first commit'
git push
cd ../b
git pull
cd ..

cd a
git checkout -b dev
echo 'new func by a' >> code
git add code
git commit -m 'new func by a'
git push origin dev
git branch -u origin/dev

cd ../b
echo 'bug fix by b' >> code
git add code
git commit -m 'bug fix by b'
git push
cd ..

a が dev ブランチを作成し、new func を加えています。
その間、b が master に対して bug fix を入れました。

以下で、a が dev を master で rebase 後に dev を master に push します。

cd a
git pull -r origin master
git mergetool
git rebase --con

git checkout master
git pull
git merge dev
git push

この結果 master ログは以下のようになります。

o [master] {origin/master} new func by a
o bug fix by b
I first commit

非常に素直ですね。ただ、これ master で rebase した後、push してないんです。conflict の merge が大変だったりした場合、dev の今後の修正に備えて push しときたいですよね。

他ブランチ取込 rebase & push 実験

[ Core 2 ] 実行して以下を実行してください。

cd a
git pull -r origin master
git mergetool
git rebase --con
git push // Error

push で死にます。今の master の修正を取り込んだものが remote の dev と衝突してしまっているのでエラーになります。

なんだ、だったら rebase すりゃ良いじゃん？っつって rebase してみるとこんな風になります。

o [dev] new func by a
o bug fix by b
o {origin/dev} new func by a
I [master] first commit

あれ、同じ commit 増えました・・・しかも bug fix と new func が入れ替わりました。そらそうですね。dev で rebase しちゃいましたから。こりゃダメです。

じゃぁ merge してみましょうか。

M─┐ [dev] Merge branch 'dev' of /home/xxx/git-test/remote/test into dev
│ o {origin/dev} new func by a
o │ new func by a
o │ {origin/master} bug fix by b
I─┘ [master] first commit

終わってます。

他ブランチ取込 rebase & push --force で人に迷惑をかける実験

素直なままの君でいて欲しい。ってなわけで、remote 側を local で問答無用で書き換えるのが

git push -f

です。-f は --force です。フォースの力をうんちゃらかんちゃらでブォーンブォーンです。

よっしゃー！これで解決やでぇ！！

とはならず、さっき書いたように、commit ぶち消し問題が発生する可能性があります。

[ Core 2 ] を実行後に、以下を実行してみましょう。

cd a
git pull -r origin master
git mergetool
git rebase --con

cd ../b
git pull
git checkout dev
echo 'new func by b' >> code
git add code
git commit -m 'new func by b'
git push
cd ..

a が dev に master を rebase 後に b が dev に対して変更を追加しています。

この時、a のログは以下。

o [dev] new func by a
o {origin/master} bug fix by b
I [master] first commit

dev が push されていないので、{origin/dev} がいません。

b のログは以下のようになっています。

o [dev] {origin/dev} new func by b
o new func by a
I first commit

new func by b が追加されていますね。

さぁ、a で force な push をしてみましょう。

cd a
git push -f	
cd ..

b で pull してログを見てみてください。

o [dev] {origin/dev} new func by a
o [master] {origin/master} bug fix by b
I first commit

「はぁぁぁ！？吾輩の new func by b が消えたっ！！」と発狂ですね。

困った事にこんな感じで何も出ずツルっと消えるんですよね。なので消えた事に気づかない可能性がある。こりゃいかんです。

周りに迷惑をかけず 他ブランチ取込 rebase & push --force & merge するには？

push -f で --force-with-lease 使うと、remote 側に変更があった場合エラーになるので、rebase やりなおしって話なんですが、conflict 解決中に push されると無限ループの始まりです。

なので、チャットで

「おい！ぽまいら！dev を rebase するンゴ！手持ちの commit を全部 push すれ！」

と古の激キモ言語で大号令をかけ、全部 push してもろて、

「rebase するから、push すんなし！」

と push を封じれば良いです。つか、それしかないです。

ちゃんと b に push してもらった後、改めて rebase すると以下のようになります。

o [dev] {origin/dev} new func by b
o new func by a
o {origin/master} bug fix by b
I [master] first commit

んで、この dev を master に merge するわけですが、この時 --squash を付けましょう。master のログに開発のログがぐちゃぐちゃ入るのマジ勘弁なんで。

git checkout dev
git pull -r
git merge dev --squash
git commit

これで

o [master] {origin/master} Add new func !!
o bug fix by b
I first commit

こうなります。はい、きれい。

rebase は ユーザーが変わるとか、hash が変わるとかありますが、そんなもん普通どうでも良いので気にしないくて良いです。

どう考えてもログが汚くなる方が致命傷だし変わる前を追おうと思えばなんぼでも追えますし。

push --force で自分の commit が消されてしまった場合の対応例

最後に、もし push -f で消えてしまった場合の復活方法の一例を書いておきます。

new func by b を消された b は

o [dev] {origin/dev} new func by b
o new func by a
I first commit

だったのが、rebase すると

o [dev] {origin/dev} new func by a
o [master] {origin/master} bug fix by b
I first commit

と、自分の commit が消えちゃいます。が、焦らなくても OK です。

git reflog 

で、作業リポジトリの履歴を表示します。

aaa75d9 (HEAD -> dev, origin/dev) HEAD@{0}: rebase (finish): returning to refs/heads/dev
aaa75d9 (HEAD -> dev, origin/dev) HEAD@{1}: rebase (start): checkout refs/remotes/origin/dev
fb23a21 HEAD@{2}: commit: new func by b
8137020 HEAD@{3}: checkout: moving from master to dev
c9a59bd (origin/master, master) HEAD@{4}: commit: bug fix by b
71e6fc7 HEAD@{5}: initial pull

以下が、消えちゃった修正です。

fb23a21 HEAD@{2}: commit: new func by b

なので、hard reset を使って、ここまで完全に戻します。

git reset --hard fb23a21

ほいだら以下です。

git reset @^
git stash
git rebase
git pop
git commit

reset で履歴を１つ戻して commit を取り消し、修正したコードを stash に突っ込んで rebase して stash から戻して commit しなおしって感じです。

では良い git ライフを。

ネットは匿名なんてデマをいつまで流すんだ？

未だに後を絶たないネットのトラブル。
バイトテロ、飲食テロ、誹謗中傷、名誉毀損等で人生を砕け散らせるバカが後を絶たない状況が
ず～～～～～～～～～～～～～～～～っと、永遠に続いております。

何故か？？

『ネットは匿名』だ、なんてデマが蔓延しているのが原因です。

あなたが接続しているこのサイトはどうやって見ていますか？

PC？スマホ？

その回線の契約はどうなっていますか？

あなた、もしくはあなたの家族が契約してますよね？

そこには、名前、住所、電話番号等々個人情報ががっつり登録されていますよね。

匿名でもなんでも無いんですよ。

あなたが接続しているサイト全てと言って良いんですが、アクセスログを残しておかないといけない決まりになっています。

警察からこの書き込みしたの誰だ？と聞かれた際に答えれるようにしておかないといけないようになっているんです。

接続元を聞き出した警察は回線業者に連絡して住所を特定し、朝っぱらから呼び鈴を鳴らし、おはよう逮捕に至るわけです。

公衆無線LAN使ってるから大丈夫ですって？防犯カメラで追えます。マンションだって追いづらいだけで結局は追えます。

Winnyだろうが、PerfectDarkだろうが、TORだろうが追えます。

どんな事やろうと日本の警察はしつこく追います。

ネットだけじゃなくて、普通にあちこちにカメラが設置されて録画されていますし、今やドラレコ積んでいない車の方が少ないです。

それらの情報全てを使い、警察は犯罪を犯したあなたを追います。

人生をゴミ箱に叩き捨てないためにも、プライバシーなんて無いんだ、ぐらいの気持ちで行動する事が一番大事です。

逮捕されるのは情弱の極みです。

未だに投資詐欺に合う連中の意味が全くわからない

これだけの情報社会で未だに脳みそに知恵がたまらない人達って何なんだろうなぁと思う昨今です。

「必ず儲かりますよ！」

と来たら

『じゃぁそれ人に言わない方が良いですよ？自分達でこっそりやったらどうですか？』

と思わない意味がわからないんですが。

この考え方で100%投資詐欺を避けれるんですけどね・・・。

世の中には儲かってる個人事業主や企業がたくさんいますが、その殆どが儲ける手口は言いません。

親切に教えてわざわざ競合を増やすバカいませんし、そんなアホはそもそも儲ける事なんて出来ないです。

まぁそれを自慢気に話す企業もたまにはいますが、それは簡単に出来ない事だからこそ言っているわけで。

儲からないからこそ、他人にやらせるわけですよ。

もし儲けるとしても背負いきれないほどリスキーだからこそ他人にやらせるわけです。

自分達で必ず儲かる美味しい部分だけちゅーちゅーしてリスキーだったり損する部分を他人にやらせるわけです。

ちょっとは賢くなりましょうか。

CO2削減！とか言っている間に人類は滅亡するのでは？

アホみたいに暖かくなったり寒くなったりを繰り返し、何度も季節の変わり目が来たり、あっちこっちで線状降水帯が発生して水害・土砂災害起こったり、
信じられない回数の雷が発生したり、沖縄と青森の気温が30度と同じで、関東が39度超えが当たり前になってみたり、7月これなら8月どうなるんだ？ってか夏長すぎね？と思ってみたり、
身近に狂ったレベルの温暖化を感じれる昨今いかがお過ごしでしょうか？

昔は線状降水帯なんて言葉すらなかったんですがね。ゲリラ豪雨って言葉が出てきたと思ったらこれですよ。

状況は悪化の一途を辿っていますよね。人類の殆どがそれを肌身に感じているはずです。

一節には、気候変動で取り返しのつかない存亡ドミノがすでに倒れてしまっていると言う説もあります。

地球環境は繋がっているので悪い事が連鎖してしまい、人類の手におえなくなる暴走状態になってしまっている可能性があると言う事です。

そもそも温暖化の原因なんて死ぬほどあるわけで、それが連鎖しまくります。

皆がよく知っている二酸化炭素、この25倍の温室効果があるのがメタン。
地球が温暖化すると、地中や海底で凍っていたメタンが溶け出して、さらに温暖化。
気温が上がると海水温度も上がり水の蒸発量が増える。
空気は温かい方がたくさん水蒸気を含む事が出来るので全体的に水蒸気量が増える(これが世界中で起こっている大雨の原因)。
実はこの水蒸気が温室効果の原因の 48% だったりする(CO2は 21%)。
気温が上がるもんだからあちこちで山火事発生。
CO2を吸収する森が消えるどころかCO2を吐き出してしまう。燃えた森が復活するのには数十年かかるので燃えれば燃えるほど減る一方。
どころかアホな国家は率先して森を燃やしている始末。
海は結構な量のCO2を吸収しているが、海水温上昇で、蓄える事が出来るCO2が減少し放出しだす。
グリーンランド、北極その他どこそこの氷が溶け、海面上昇。そもそも海水温上昇で熱膨張するのでそれでも海面上昇。
海面上昇により土地が減り、山を開拓、更に森が減る。
住む場所、農地が減って行く。食い物が減り、住む場所がなくなると人類がやることは一つ。

「戦争」。

さぁ、人類が吐き出すCO2だけ減らせばどうにかなる問題でしょうかね？
と言うか、人類は、何十年 CO2 減らせ～と言ってます？結果どうなってます？

減らないでしょ？これからも減りませんよ、きっと。
と言うか減らしたところでその効果が出るのに数十年かかるし、意味があると思えないし。
温暖化が温暖化を呼ぶ展開ですからね。1つの連鎖を切るんじゃなくて、一斉に何箇所も連鎖を切らないと話にならない。

もはや、人類が吐き出すCO2減らそう！なんて悠長な事言ってるフェーズはとっくに終わってるんです。

温暖化して「洪水は起きる！」「土砂崩れはする！」「海面は上昇する！」これを前提にした動きが必要なんです。

しっかり治水を見直さないといけないし、住める場所を制限する必要があるのかもしれないし。

海面上昇に関しては、かなり深刻だと思っていて、打破するには技術革新が必要になってきます。

何をやる必要があるかと言うと、山の中をくり抜いて居住地や農地を作る必要があります。

斜面をどうこうしてってのは土砂崩れの問題があるし、山の中に空間が作れたら日本には相当余分な土地が生まれます。

温暖化に対しても地中は温度が低く安定していますし一石二鳥です。

日本のトンネル掘削技術は世界でも屈指なので、それを拡張してもっとでかい空間を作れる技術を開発すれば良いのです。

おそらく世界中で必要になってくる技術ですし、その技術と道具の輸出だけで国としてもかなり儲かるはずです。

後は海が増えるんだから、漁業は充実するだろうって事で、そっちへ生産業をシフトして行くとかですね。

まぁ、対処療法ですが、これしかないんじゃないかな、と。

根本的な治療法が無いとも言えないんですけどね。宇宙空間に傘を広げて太陽光をコントロールしてしまう方法があります。

ただ、これ、誰がどう責任を取るんだ？と言うところがネックになって実現は不可能ですけどね。

大半の国家が、このシステムで助かったとしても、割を食う国家が出てきて必ずギャーギャー文句を言うので。

全国家に許可取るなんて100％無理ですし。

実現するためには、世界で全面戦争して統一国家作るしか無いでしょうね。

と言うわけで、そろそろ人類は現実をちゃんと見るべきだと思いましたとさ。

SvelteKit の使い方をわかりやすく解説してみる - Svelte Vol.2

暗黙の世界

SvelteKit は脳みそが小さい連中が嫌う暗黙のルールで溢れ返っている
なので、そう言うのが嫌いなら絶対に使うべからず
逆に暗黙が好きなら最高の使用感を得られるはずだ

基本的に同一階層にファイルを作るだけで暗黙の継承がバンバン行われたりする

基本のファイル

src/routes/ 以下に +page.svelte を置くだけで / でアクセス可能になる
src/routes/hoge/ 以下に置けば /hoge でアクセス可能

+page.svelte

こいつがキモ
サンプルを下記してみる

<script>
  console.log('TOP +page.svelte')
  export let data
</script>
<template lang="pug">
  h2 TOP
  pre {JSON.stringify(data, null, 2)}
</template>

んーシンプル？

export let data

何じゃこいつと思った人は正常！

なんかここから出しそうじゃん？何をどこに出すの？って感じじゃん？？

違うんだなコレが
+で始まるファイル名よりも激キモセンスなんだわ、これが

+page.js とか +page.server.js から export されたデータを暗黙で import してんだなぁこれ・・・ｷﾓｯ

え、何これ？アラブの石油王が飼ってるチンパンジーが作ったの？
コレをキモいと感じないやつと同じ空気吸いたく無いレベルで酷い実装なのはグッと我慢だ(そのうち破壊的変更入りそ～)

+page.js

ブラウザ側で +page.svelte にデータを注入する

console.log('TOP +page.js')
export function load() {
  console.log('TOP +page.js LOAD')
  return {
    top: 'TOP'
  }
}

load() で値を返すと、そいつが激キモなあいつで受け取れると言う寸法

Svelte 使ってるけど良い感じ。でもドキュメントが微妙過ぎて終わってる - Svelte Vol.1

表題の通り。公式サイトは御託だらけで読みづらいくせして情報が色々足りない
色々苦労したのでメモがてらに皆に共有

(※ あくまで個人ユースで遊びで使っている限りはイケている感じ
これを本格的なプロジェクトにぶっこんで規模のデカいものを開発した時
React みたいな悲惨なことにならんかどうかはまだ解らず)

SvelteKit

プロジェクト起こすにはコイツ。Vue みたいに CDN から読んでちょろっと試すとかは出来無い

プロジェクト作成 & 開発サーバ起動

npm create svelte@latest test
cd test
npm i
npm run dev

Skeleton project
Type Script なんぞ時間の余っている知ったかぶりクソ Noob 以外は使わなくて良し
その他も要らん

訳のわからんポートで立ち上がるので 8080 で起動し localhost 以外からアクセスしたい

npm run dev --host 0.0.0.0 --port 8080

クソめんどいので、package.json に以下を追加

"s": "vite dev  --host 0.0.0.0 --port 8080",

さらにバカめんどいので、yarn で叩く
さらに zshrc に alias を追加

alias y='yarn'

y s

ヨシ

alias nr='npm run'

もオススメしたい

Pug & SCSS

HTML とかブレインデッドなバカの書くもの
CSS もダルさ爆発

SvelteKit はサクッと Pug と SCSS をサポートしてくれる！最高！！

ã‚¨ãƒ³ãƒ–ãƒ¬ã§é€šå ±ã•ã‚Œã‚‹ã¨ã‹ 回生ブレーキ効きまくる EV 車どうすんだ？

www.ben54.jp

エンブレは燃費向上するし、ブレーキの摩耗を軽減出来るし、教習所でも坂道を下る場合はフェード現象、ペーパーロック現象を避けるためにエンブレ使えと教えられるわけでメリットしか無い代物と言うのが大半の運転者の認識だろうと思う。
マニュアルなんて停止時には当たり前のようにギアダウンしてエンブレかけまくるしね。

これで通報されるとは。たまったもんじゃないわな。

以前、EV 車に乗った時アクセルから足を離した時の急激な減速に驚いた。ブレーキから足を離しただけで 1 速とか L に入れたぐらいのエンブレがかかる。

こいつは回生ブレーキっつってモーターがダイナモ状態になって発電を行うからその負荷で減速すると言うもの。

乗った車は、ガソリンで発電機を回して発電してその電力を使ってモーターを動かすと言う「どう考えても内燃機関で燃やして直接動力にした方が良いだろ」
と思える何とも頭の悪くて熱効率の悪そうな代物なんだが、絶望感を味わう鬱陶しい充電も無く、
気温と共に劣化するバッテリーのクソさ加減も無くまるでガソリン車のような使用感で EV のパワーが存分に味わえる代物で
「良いじゃん！」と思った数秒後に「そもそも EV って化石燃料脱却のためのもんだろ？何のために存在しとんねんこの車！！」と思ったわけだが、
あくまで今は EV 黎明期で混乱しているだけであって、EV が徐々に増えて行くのは避けられない道なわけで(流行るとは全く思っていない)、
エンブレ問題ってこれから先、大事になるんじゃね？と思ったんだが、調べたらどうも回生ブレーキ発動時にはブレーキランプが点灯するらしい。

なんだ、素晴らしいじゃん。

オートマとマニュアルは未だにその仕組は無いらしい。まぁ発電時にある程度の電流が流れたら点灯させるみたいな回路ってすぐ組み込めそうだけど、マニュアルとかオートマとかは確かに厳しそう。

なので、EV に乗ったら助かるのか？

いやぁ・・・俺はブレーキランプを点灯させまくるやつの方が危ないやつだと思っちゃうんだよなぁ。

「こいつ危なっ・・・アホだわ・・・車間距離開けよ・・・」と離れるか追い抜けるなら追い抜く。運転が下手だと判断しちゃうんだよなぁ。

エンブレで減速するやつの方が絶対的な安心感がある。

そう言うドライバーがほとんどだと思っていたんだが、人によってはそうでも無いらしい。

こんな事で通報するやつもいるんだって意識しつつエンブレ使っていかんとなぁ、と思いましたとさ。