orange @[email protected]

よほど空いてるとき以外は、どのお客さんがどこまでの料金を投入したかなんて覚えてなさそう＞＜；

それはそうだし、先払い後払いもややこしいし、昔、埼玉の浦和周辺に均一料金じゃないのに先払い方式の初見殺し過ぎるシステムまであったし、あれかも＞＜；

でもたぶん、日本の中型トラック数十台の荷物をアメリカ規格(入るだけ積むんじゃなく、重量制限もアメリカの80000lbs)の53ftトレーラー+スリーパーつきトラクタに積み替えたら、フットプリント小さくなりそう＞＜
もしかしたら10tトラックとの比較でもフットプリント小さくなるんでは？＞＜

アメリカのトラックも実は53ftのトレーラーの中がぎゅうぎゅう詰めである事はまれっぽいけど＞＜；(体積の制限よりも先に重さの制限が引っ掛かることの方が圧倒的に多いという面も＞＜；)

これ、大きいトラックと小さいトラックでも同じことしたらおもしろいんではって気がしなくもない＞＜(アメリカのトラックを日本でも走らせろの会(？＞＜；))

運転中「バス邪魔！」と感じることもあるかもだけど…マイカーとバスの「道路専有面積」を比較した画像に圧倒的な差があった - Togetter https://togetter.com/li/1891950

距離じゃなく速度と角度のの変化か＞＜；

距離の他に角度の変化も検出する手もありそう＞＜

自分がなぜか自然に出来てしまうことを、自分が何をしたのか振り返って考えて、他人や機械等が理解出来る形で手順をドキュメント化するのがプログラミングかも＞＜

ソートで言うならば「こういう風に考えればソート出来る」って面と、「こういう風に考えたら『こういう風に考えたらソート出来る』という発想そのものを産み出せる」の違いかも＞＜
既存のアルゴリズムに理解に必要なのは前者だけど、新たなコードを書くために必要な技能は後者であるし、
もっというと部分的な理解から残りの部分を推測する力がつけば学習がより容易になるであろうと考えると、新たなコードを書ける技能がある方が、最後まで話を聞かなくても理解できるという面で、より効率的な学習が期待出来そう＞＜(微妙にトートロジーだけど＞＜；)

「考え方を教える」にも二通りあって、作業手順の考え方を教えるのも「考え方を教える」だけど「どうしたらその作業手順を選択するという結論に至るのか？＞＜」「どうしたらその作業手順を編み出す事になるのか？＞＜」も「考え方を教える」かも＞＜
前者は答えを知ってる人の視点であり、後者はそうでは無いかも＞＜

一人目には、まず手作業ソートさせて、どういった手順で行ったか説明させる＞＜(説明出来なくてもよい)　説明できたら手順を書いておく＞＜
二人目では、一挙手一投足「なぜそれを選んだ？＞＜」「なぜそこに置いた？＞＜」のようにすべて問い詰める＞＜
で、(また)手順を書き出す＞＜(もう一人くらいやってもよさそう＞＜)
次に別の人を指名して、書き出した手順通りに作業させる＞＜
で、これこそがプログラマが行う作業だって方向の説明をするみたいな感じ＞＜
この流れの前に、みんなで一緒にソートの手順を考えて書き出して、それで失敗させても場がなごんでより理解出来そう＞＜

ソートを教えるの、もしオレンジだったらいきなり既存のソート法を教えることはしないかも＞＜
数字書いた紙なり長さが違う棒なりを使って、生徒の代表に並べかえさせて「いまどうしてそうしたのか説明してみろ＞＜」って問い詰めまくって、プログラマの発想を理解させるかも＞＜
そこから既存の効率のよいソート法を教えれば「ソートをどう考えればいいのか？」の理解の上での学習になって、意味を理解しやすいかも＞＜
NHKのピタゴラスイッチのいくつかのスケッチもたぶんそういう発想かも＞＜

国産スマホ、そこそこ低価格でマジで10年使えるやつとか作ればいいのに＞＜
継続性がないから右往左往して使い捨てのゴミしか作れないんだよ＞＜
使い捨てのゴミで儲けられるのはファッションリーダーと最も低価格で生産できる国だけだよ＞＜