><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
アメリカのトラックも実は53ftのトレーラーの中がぎゅうぎゅう詰めである事はまれっぽいけど><;(体積の制限よりも先に重さの制限が引っ掛かることの方が圧倒的に多いという面も><;)
これ、大きいトラックと小さいトラックでも同じことしたらおもしろいんではって気がしなくもない><(アメリカのトラックを日本でも走らせろの会(?><;))
運転中「バス邪魔!」と感じることもあるかもだけど…マイカーとバスの「道路専有面積」を比較した画像に圧倒的な差があった - Togetter https://togetter.com/li/1891950
距離じゃなく速度と角度のの変化か><;
距離の他に角度の変化も検出する手もありそう><
「頭なでられ反応」の感度設定が、WM_MOUSEMOVEを受けた回数っていうのがまだ納得いってないんだけど、じゃあ何が良いのと言われても割と困る。
確か納得いかずにマウスの移動距離を全積算するコード書いたような気がするけど、より操作がめんどくさくなっただけだった。つらい。
自分がなぜか自然に出来てしまうことを、自分が何をしたのか振り返って考えて、他人や機械等が理解出来る形で手順をドキュメント化するのがプログラミングかも><
ソートで言うならば「こういう風に考えればソート出来る」って面と、「こういう風に考えたら『こういう風に考えたらソート出来る』という発想そのものを産み出せる」の違いかも><既存のアルゴリズムに理解に必要なのは前者だけど、新たなコードを書くために必要な技能は後者であるし、もっというと部分的な理解から残りの部分を推測する力がつけば学習がより容易になるであろうと考えると、新たなコードを書ける技能がある方が、最後まで話を聞かなくても理解できるという面で、より効率的な学習が期待出来そう><(微妙にトートロジーだけど><;)
「考え方を教える」にも二通りあって、作業手順の考え方を教えるのも「考え方を教える」だけど「どうしたらその作業手順を選択するという結論に至るのか?><」「どうしたらその作業手順を編み出す事になるのか?><」も「考え方を教える」かも><前者は答えを知ってる人の視点であり、後者はそうでは無いかも><
一人目には、まず手作業ソートさせて、どういった手順で行ったか説明させる><(説明出来なくてもよい) 説明できたら手順を書いておく><二人目では、一挙手一投足「なぜそれを選んだ?><」「なぜそこに置いた?><」のようにすべて問い詰める><で、(また)手順を書き出す><(もう一人くらいやってもよさそう><)次に別の人を指名して、書き出した手順通りに作業させる><で、これこそがプログラマが行う作業だって方向の説明をするみたいな感じ><この流れの前に、みんなで一緒にソートの手順を考えて書き出して、それで失敗させても場がなごんでより理解出来そう><
ソートを教えるの、もしオレンジだったらいきなり既存のソート法を教えることはしないかも><数字書いた紙なり長さが違う棒なりを使って、生徒の代表に並べかえさせて「いまどうしてそうしたのか説明してみろ><」って問い詰めまくって、プログラマの発想を理解させるかも><そこから既存の効率のよいソート法を教えれば「ソートをどう考えればいいのか?」の理解の上での学習になって、意味を理解しやすいかも><NHKのピタゴラスイッチのいくつかのスケッチもたぶんそういう発想かも><
国産スマホ、そこそこ低価格でマジで10年使えるやつとか作ればいいのに><継続性がないから右往左往して使い捨てのゴミしか作れないんだよ><使い捨てのゴミで儲けられるのはファッションリーダーと最も低価格で生産できる国だけだよ><
完全再現アニメ?><;
"Rick Astley - Never Gonna Give You Up (Official Animated Video)" を YouTube で見る https://youtu.be/LLFhKaqnWwk
なんだこれ
日本企業は動きが遅いみたいなことよく言われるけど、一方でIT界隈に限ればその場その場の流行に右往左往して引きずられて主導権を握れないまま振り回された結果が今とも言えるわけで、もっと長期的に物事を考える姿勢を持っていたらもっとマシだったんでは?><自動車業界は、流行は数年で変わるのにコスト的には10年単位で考えて物作りしなければ商売にならない業界なので、日本企業であっても強制的に長期的に物事をを考えさせられる業界なのでうまくいってるのかもしれないとも考えられそう><
ある程度それはそうだけど、クルマに限るとちゃんとラインナップ揃えて長期的に物事を考えられてるわけで、日本の電器電信業界(?)が自動車業界のような物事の考え方ができなかった&個人向け計算機と携帯電話機の重要な時期に貧乏すぎて(より正確には、利益配分がうまくいかなくて)まともな投資ができずそれに引きずられて組織ごと腐ったって面もあるんでは?><って思うかも><
国産スマフォを作りたいなら高機能スマフォじゃなくて,ローエンドから始めるべきだったのかもね.安けりゃだれかしら買うから.
プログラミング教育の場の駄目な「全部ぶっ混んだらどうにかなるでしょ」的発想、ある程度は日本語圏ならではの問題もあるんではって気がして来てる><最近、英語関連の色々なの調べてて、英語ネイティブで現在日本在住の人が何人か同じこといってたけど「日本語の会話や日本語で考えてる時は、単語さえ揃っていれば意味を推測できるけど、(不思議な事に)英語で考えてる時や英会話の時には、単語をただ並べられても本当に全く意味がわからない」って言ってた><と言うことは、(プログラミング言語も含む)言語で「単語全部ぶっ混めばおk」って発想って、日本語的発想であり英語的ではないのでは?><ってオレンジは考えた><
他人のコードをまるごとコピペしたりなにも読みとかずに写経してたら、自分でソフトウェアを書けるようにならない><いくつものコードを見比べて「つまりこうしたい時にはこういう感じのコードを書けばいいっぽい!><」って理解してると、まず車輪の再発明なコードが書けるようになるし、再発明なコードを書いてるうちにそれらの部品の組み合わせから新たな問題に対応するコードも書けるようになってく><料理も全く同じで、ある程度からはレシピをただ追わず、再構成していけば、自分の好みの料理を自分用に新たに産み出せる><
料理も、単にレシピをなぞってるだけだと自分で作れるようにならないかもだけど、料理それぞれのテクニックというか、処理と結果の対応の知識を料理番組なり実践なりでつけて「こうすればこうなるはず・・・><」を脳内に大量にストックしておいて、他人が書いたレシピもひとつだけ見るんじゃなくいくつも見比べて「つまりチャーハンって炊いたごはんをたまご及びその他具材等と炒めて調味したものの事っぽい><」って、解釈の形に直して手順を再構成するってやってると、お手本の料理が無くても料理自作出来るようになる><そういう面は、プログラミングと料理って同じかも><
思考の /dev/null