00:04
8月31日、水曜日ですね。8月もラストになりました。 地獄は朝9時7分ということで戻ってしまいましたけどもね。
おはようございます。ユメミのkeethことくわはらです。 じゃあ本日も朝活を始めていきたいなと思います。
今回はですね、あの時の前回ですね、あのー、お冒頭ってないわ、終わりに少しだけ喋ったんですけど、
なんかそう、Facebookチームの運用の話とかの記事があったので、それ読んでいきたいなと思ったんですけど、
ちょっと有償のサブスクライブしなきゃいけないというので、これにサブスクライブ、いつか金払うかっていうのがちょっと悩ましかったので、
ちょっと一旦その記事は保留にして、今回別の記事をザーッと探してて、見つかった面白そうだったというのを読んでいきたいと思います。
一つが、How and Why I removed jQuery from GOV.UKということで、イギリスのガバメントのサイトですかね。
で、jQueryを消した理由とどうやってやったのかっていうところが語られているので、これはちょっと読んでみたくなりました。
で、もう一個はですね、ちょっと読み物系で、久しぶりにちょっと日本語の記事を見てて、ちょっと面白そうなのがあったので読んでみようと思いました。
正確なタイトルは、プログラミング的ゾンビとプログラミングの学習についてってことなんですけど、
ちょっと文字通的に足りなかったので、割愛詩でタイトルを書いてますけど、そんな感じです。
じゃあ早速ですけど、本文を入っていきたいなと思います。前者の方の記事ですね。
jQueryを削除したよという記事の方です。
はい、しゅうぜんさんとだいちさんですね。おはようございます。今日もご参加いただきありがとうございます。
で、本文を入っていきたいと思います。
GOV.UKはイギリス政府のオンラインホームページですと、そのためデバイスや接続速度に関係なく全ての人が使えるようにする必要があります。
そのため私たちは常にパフォーマンスとユーザーエクスペリエンスを向上させる方法、そしてその下にあるコードを探し求めています。
はい、本当にこの文言だけでもう日本の政府のページとかデジタル庁の人、本当に参考にしてくださいって言いたくなってきました。
はい、GOV.UKの公開ドメインであるwww.gov.uk、私たちのフロントエンドのコードっていうのは長い間古いバージョンのjQueryに移動していました。
jQueryはJavaScriptの技術を用意するために設計されたライブラリーです。
ここではjQueryを削除することにした経緯とその結果について説明していきますというところです。
タイトルはある通りですけど、やっぱり速くて軽量かつ、やっぱりネットワークとかスピードに関係なく誰でもアクセスできるようにするってところがポイントなので、
jQueryって本体ですね。今はjQuery.minじゃなくてslim.jsみたいなのが実はあって、スリム化したjQueryもあるんですけど、とはいえやっぱなんだかんだ読み込ますと思いし、
スマホに読み込ますの?みたいな感じが出てくるので、そこがまずでかいなってなりますね。
余談でしたけど、じゃあ本文いきましょう。How we used jQuery on gov.ukで、jQueryどの辺りに使ってたのかっていうところですね。
03:00
gov.ukっていうのは主に静的なコンテンツページで構成されているため、JavaScriptは主に分析、クッキー、あとは要素の拡大や縮小など小さなユーザーインターフェースのインタラクションに当初は使ってたようなところですね。
gov.ukのアーキテクチャは非常に複雑で、我々のJavaScriptっていうのはそれぞれが異なる種類のページを提供する複数のアプリケーションに分散しています。
多くの大規模なウェブサイトと同様に、このJavaScriptも新しいものと古いものが混在し、よく文書化されているものとそうでないものがあります。
JQueryは一般向けのスクリプトとテストファイルの両方で私たちのアプリケーション全体に記録しようされています。
特にAJAX処理、ページの一部を動的に再読み込みするなどなど、多くのJQueryの機能を利用していましたが、一般的なコードをよりシンプルにするために使用していました。
JQueryは確かにちょっとコードシンプルにはできなくはないですよね。
バニラJavaScriptよりは一応シンプルに書けなくはないですけど、JQuery表現力が高すぎるので、ちゃんとコーディングフォーマットが決めないと途端にカオスになりますけどね。
JQueryを使用する主な欠点というのは、ページやセットに含める必要があるため、サイトの読み込み速度が遅くなることです。
ゴム.ukのページのサイズは様々ですが、ホームページは約246KBで、そのうち32KB、約13%がJQueryでした。
これは大した量ではありませんが、特に低スペックのデバイスを使用するユーザーにとってはパフォーマンスへの影響を考慮する必要があります。
本当にその通りですよね。
13%ってやっぱりデカいよな。32KB。
現代のスリム化している、またはUIフレームワークがどんどん小さくなっていって、軽量化している中に32KBって割と重いですよね。
続いて、The Scale of the Problemで問題の規模ですね。
ゴム.ukは古いバージョンのJQueryに移動しました。アップグレードの必要性は認識していましたが、
ゴム.ukの一部でJQueryがパフォーマンスの問題を引き起こしていることも正直わかっていました。
ですので、アップロードするよりもJQueryを削除することが最善であると判断していました。
ただ、これは大変な作業でした。
少なくとも200以上のスクリプトがあり、数行のものもあれば数百行のものもあり、さらにJQueryを使用したテストも数多くありました。
200以上のスクリプトがあるっていうのが僕は結構インパクトありますね。
政府のページとはいえ、200以上スクリプトを置くようなファイル。
しっかりモジュール分割しているとかもあるかもしれないですけど、ページ数もそこまで細かくあるっていうことを考えると、
それはすごいなと思いますね。
またテストにもJQueryを使用したものがあるっていうことなので、テストコードもガラッと書き直さなきゃいけないとなると、
これは膨大な作業量と工数がかかってお金もすごいことになったんでしょうけど、
それ以上に未来のUKのガバメントサイトを訪れる人たちのためにお金を投資したってことですよね。
06:06
しかも政府のサイトだから政府自身が意思決定をしたっていうので、めちゃめちゃ素晴らしい話だと思います。
我々開発者としてこんな事例なかなか聞くことができないので、ちょっと感動しています。
戻りましょう。
Gob.uk上のどのJavaScriptも独立した作業としてJQueryを削除することができました。
ちゃんと分割してるってことですよ、つまり。
素晴らしいわ。
レガシーとはいえちゃんと設計したって人がいるんですよね、裏に。
素晴らしいと思います。
つまり開発者は数時間しか使えないとしてもこのタスクに貢献することができたってことですよね。
How we did itですね。
我々どんなふうにやったのってところですよね。
ですけどその方法とは、まずGob.ukの新しいJQueryの追加を中止し、タスクが大きくなるのを防ぎましたと。
そうですね。
さらにどんどん新しいのを追加していくんだから、そりゃタスクも大きくなりますよね。
いずれJQueryをやめるってことなので。
次にこの作業をGob.ukのフロントエンドとバックエンドの開発者に分散させました。
Gob.ukのバックエンドの開発者は通常JavaScriptはあまり書きませんが、
彼らはこの作業の重要性を認識し、少しのトレーニングとサポートですぐに大きな進捗を遂げることができました。
これもいい話だな。
本当にバックエンドだからJavaScriptやりませんっていう話ではないし、
責務分けたんだからそれフロントの人でしょ、仕事でしょっていうふうに分けるわけではなくて、
みんなで一斉にやりましょうというところですね。
しかしJQueryの削除方法に関するドキュメントを作成し、開発者が協力して作業した結果、
ポリケーション全体からJQueryを削除できるようになりました。
この努力は大きな効果をもたらし、プロジェクトの期間を数年短縮することができたと思います。
最初にちゃんと削除方法に関する決め事をドキュメントで起こしておいて、それを分担したということですよね。
ここ結構重要ですね。
これしないするで、だいたいカオスな現場になりがちですからね。
あれ、誰が何やったとか、作業をバッピングしてしまったで、
コースが無駄になってしまったとか、コンフリクトを追っ張るとか絶対すると思うんで。
本当にきっちりされてるんだなっていう、本当にいい成功事例だなと思います。
またいくつかの難しい決断もしました。
私たちのアプリケーションのうち2つは大量のJQueryを含んでいましたが、
GOG.UKに多くの一般向けページを提供しているわけではありません。
進捗を妨げるのではなく、これらのアプリケーションに独自のライブラリのコピーを提供し、
GOG.UKの大部分をJQueryフリーにすることができましたと。
これを主導したリーダーシップの発言とかブログがあったら逆に読んでみたくなりましたね。
この間、COVID-19の作業やその他の優先事項ももちろんありましたが、
2022年の初めにはGOG.UKからJQueryを最終的に削除するためのオプションの検討を開始できる状態になっていました。
09:02
ということは、今年の冒頭ではまだ削除できていなかったという感じですかね。
最後の追い込みですが、各アプリケーションをテストに使用するため、
JQueryを一切使用しない開発版のサイトを作成しました。
これにより、私たちが見逃していたかもしれないJQueryの行動によるエラーをチェックすることができ、
また、私たちの変更によるパフォーマンスへの影響を測定する最初の本格的な機会を提供することができました。
このテストは徹底的で数時間がかかりましたが、幸いなことに問題はほとんど見つかりませんでした。
実は丸コピーしたってことかな。新しいのを作り直したっていう感じですかね。
JQueryを消していったっていうよりも。
この辺は詳しいこと書いてないからわからないですけどね。
2022年3月下旬、私たちはついにこの変更を本番サイトに導入する準備が整いました。
そのためには独自のJQueryを受け取ったアプリケーションを最初にデプロイするタイミングを慎重に測る必要がありました。
JQueryを2度組み込むことでエラーが発生することはありませんでしたが、
ユーザーにとって不必要にアセットサイズが大きくなるため、この状態を長く維持することは避けたいと考えていました。
これらのアプリケーションをデプロイした後、JQueryを削除するための変更をデプロイすることができ、
新規を使う作業でしか無事成功に収まりましたよということです。
うーん、なるほどですね。今年の3月下旬だったんですね。
はいはいはい。
でもまあ大変だったでしょうね。想像を絶する。
JQueryの使ったサイトって大体JQueryにめちゃめちゃ依存するという印象が僕の中でありますので、
これペガスってしかも200以上スクリプトがあるウェブサイト、さらに言うと政府のサイトなので、
まあミスなんかなかなか許されるんでしょうけど、
逆に言うとこれだけのIPに関しての積極投資をするようなサイトですので、
ミスがあることは多少許容している可能性もある気がしてますね。
その他にリカバリ速度をしっかりプロセスとかパターンとか用意しておいて、
早く早くリカバリをしたという方法もあるかもしれないので、
ほとんどっていうのがさっき文言にも出てきたので、
完全にはカバレッジ100%とかやらなくてないんじゃないかなと思いますけどね。
でもそれでもちゃんとリリースしたというのはいい話だなと思いました。
というかカバレッジ100%を目指すことってぶっちゃけあんまり本質的ではないし、
品質と別の話だった気がしますけどね。
はい、で最後実はリザルトですね。
JQueryの削除により、
kob.ukの大半のページから32キロバイトのJavaScriptが削除されたことになります。
kob.ukはすでに読み込みが非常に早いため、
多くのユーザーにとってこれは目立った違いではありません。
もともと早かった。
しかしデータ域幅の接続や低スペックのデバイスを使用しているユーザーにとっては、
12:01
この変化がより顕著になるため、
ページのダウンロード速度とパフォーマンスが大幅に改善されていることになります。
これが何を見せるのかについては、
次回のブログ記事で詳しく説明しますと。
次回のブログ記事が、
特に、あ、ありますね。
ありますけど、今日は読まない予定です。
もちろんこの記事もちょうどリンクに載せるので、
そこから見てもらえればと思います。
開発者の視点から見ると、
JQueryの削除することは長いけれども価値のあるプロセスでした。
コードを書き直すことで多くのことを学び、テストを拡張、改善しました。
多くの場所でコードを再構築し、改善することもできましたし、
場合によっては不要になったスクリプトを削除することもできました。
ああ、なるほどね。
当初は技術的塞いやレガシーコードを取り除くためのサイドプロジェクトとしてスタートしましたが、
パフォーマンスやセキュリティ、開発者のJavaScriptコードへの親しみやすさなどなど、
多摩なるメリットをもたらしました。
さらにGob.ukからの外部依存を取り除いたことで、
メンテナンスの効力と将来起こるセキュリティリスクを経験することもできました。
というので締められていますね。
なかなかサイドプロジェクトとしてスタートしたんですね。
技術的塞いやレガシーコードを取り除くというところですけど、
結果的にJQuery、Pegasusはサイドプロジェクトにならないでしょう。
僕はちょっと思いましたけど、
結果的にこれだけ本格的にやったということだと思うので、
本当にすごいなと思いますね。
賞賛しかないです、これは。
やっぱりJQueryで一度開発したことがある人たちからすると、
この大変さっていうのは多分身に染みていると思うので、
これは本当にフロントエンド周りでの大変に素晴らしい成功事例だと思うし、
本当にこれをやった人たち、中の人とか関係者の人たちが
ブログとか発表とかってあったらめちゃめちゃ聞いてみたいですね。
割とそのフロントエンド開発のノウハウとかっていうのがしっかり溜まってそうだと思います。
いわゆるテクノロジー的な技術のお話がそんなに多くあってもないと思います。
やっぱりJQueryでヒップハウスは割とやることとかイメージは大体できるんですよ。
その影響範囲とかビジネス的なインパクトであったりとか、
こうするっていうところが結構課題にはなると思うんですけど。
それでもやっぱりこれは聞いてみたいし、
おそらく素晴らしいチームが裏にあると思っているので、
チームビルディングっていう観点からもこの話、
もしあるんだったらちょっと見てみたいかなと思いました。
一応ですね、記事としては終わりなんですけど、
前後記事にこのgob.ukの別のブロー記事のリンクが貼られていて、
一つはローリングアウトはニュースデザイン
for browsing gob.uk by topicっていうものと、
もう一個がthe impact of removing JQuery on our web performanceですね。
2つ記事が貼られていて、
片方は新しいブラウザーのデザインですね。
15:01
というところのトピックベースで新しいデザインというところが書かれています。
それが一つの記事です。
もう一個の方は書いてあるんですけど、
JQueryを削除したことによるインパクトですね。
ウェブパフォーマンスのインパクトどのくらいあったのっていうところが
具体的に書かれているってことなので、
ちょっとこの辺も明日また僕なんか気になったので読みたくなりましたね。
それくらい今回の記事は僕の中でちょっとインパクトあったので。
じゃあ一旦片方の記事ですね。
how and why we removed JQuery from gov.ukというサイトの改善の記事は終了にして、
もう一個の記事ですね。
ちょっと時間短いので多分全部読めきれないと思いますけど、
日本語なのでささっと読んでいきたいかなと思います。
今回は前の方の記事で
プログラミング的ゾンビとプログラミングの学習についてという記事ですね。
これはポエム記事ですけど読んでいこうと思います。
完全に日本語記事ですけど。
では行きましょう。
とある記事がありまして、背景として。
数学ゾンビだ。
分数の約分の問題は完璧に解ける息子さん。
意味を理解しながら計算していくことがわかったみたいなことで。
こちらのまとめを読んで、
数学的ゾンビと面白い考え方だと思うので、
プログラミング的ゾンビというのも考えられないかというのを考えてみたと。
同時にプログラミングの理解だとかプログラミングの学習とかそのところも
同時に書いていければいいなというところで書いていきましたということです。
数学ゾンビっていう単語は僕知らなかったね。
これ聞きなりますね。
でも意味を理解しながら計算していくことがわかったっていうのは
割とありがちですし。
結構インドの数式の計算処理のやり方。
あれ意外と裏の処理わかってないまま、
でも計算の方法だけみんなしてて超高速に計算してるような気がしてたりはしますけど。
実際には計算が早くできて、
使えればぶっちゃけ中身わからなくても仕事にはできるんでいいっちゃいいんですけどどうなんだろうみたいな。
余談から入りましたけど戻ります。
じゃあ入っていきましょう。
プログラミング的ゾンビとは。
プログラミング的ゾンビっていうのを考えたときにそれはどういうものかって考えると
以下の2つが当てはまればそういうものだと言えるでしょう。
プログラムを書けるように見える。
プログラムの内容より意味するとかわかっちゃいねえ。
そう考えたときどのような人がプログラミング的ゾンビかと思うわけで具体例を示していきましょう。
コピペエンジニアじゃないですか。
ぶっちゃけ。
言っていきましょう。
ゾンビの具体例です。
こうしたときプログラミングゾンビの一般典型的なのが
誰かが書いたコードをひたすらコピペする人たちだということです。
そういう人たちは多分コピペのコードの内容をはっきり理解していないことが多いと思います。
そういう人たちは多分時間がなかったり
そもそもプログラミングついて学習したことがない
もしくは学習が足りない等の状況下で
プログラミングを使って何か解決しなきゃならない
というふうに起きるんじゃないかなと言ってますね。
それでそれ以外にもプログラミング的ゾンビの例としてどんな場合があるかって考えたときに
解きたい問題と解決のコードをセットで覚えて
コードを書いているパターンですね。
問題コードの集合を覚えているということに近いと。
新しい問題に対して類似の問題を探って
コードをその問題解決するように変形させていくパターンですね。
例えば1から100まで出す問題があって
18:00
そのようなコードがありますと
このコードはさすがに口頭で説明はできないと思います。
しかもこれリスプじゃね?
久しぶりに見たなこのコード。
これは例えば1から1万まで出すみたいな問題があって
単純に100を1万に書き換えるということをやっていくという
そういうような改変ということですね。
一つの例ですけど。
これはコモンリスプのDoマクロが理解できなくても
1から1万まで出すという問題を解決することは確かにかけてしまいますね。
中身が何をするというのが分かって
この100をとりあえず1万になったら何かできそうなということです。
なぜコモンリスプを使ったかというと
この人がリスプ好きだらしいからですね。
実際にプログラミング教育を私がやっていて
よく出くわす例としてはこんなものです。
課題は解ける。確かに解ける。
プログラミングができるが実はコードが何をやっているか
深く説明を求めてみると
できないみたいなことがよくあるんですよということですけど
よく見るのは実はスクラッチだったりJSだったりCシャープだったり
JSはありがちですね。
プログラミング的ゾンビだなと思うときですけど
プログラミング的ゾンビだと判断するときの基準は何だろうかと
一つ私は考えるのは間違いを犯したときですよと
コードの間違いがかなり独特な間違い方をする
そしてコードが間違っているときに
プログラミング的ゾンビ間違いを自分で直すことができない
例えばさっきの例についての話ですね。
ほげほげってコードがあるんですけど
ここはちょっと音読になるのでコードについては読まないですけど
極端な例ですけど
しかし実際にこれと似たような間違いを犯している人が案外多くて
この例ではループもしくはプリント式を書く場所が違うだけなんですけど
彼らは平気な顔して書いて
なぜ間違っているのかわからないということを言い出すのであると。
何が間違っているか
僕ら分かっている人から見れば一目瞭然ですが
考えてみると社協でコードを書いて学習している等だったとしたら
彼にとってはコードの意味よりも社協して正しいコードと間違い探しをしながら
コードを書いてきたので
そもそもコードを公文的に捉えることができないというのではないかと考えますと
確かにそれはありそうですね
もう一つあるんですけど
それは全く新しい問題を出したときであると
例えばさっきの問題ですね
から1から1万まで足すじゃなくて
1から1万の偶数のみを足せみたいな場合ですね
こういう場合にも回答できないパターンがあったとき
っていうのもやっぱりゾンビじゃないのということですね
もし彼らに類似するパターンがあれば
回答することはもちろんできるんですけど
社協したことがない問題に出会った場合
彼らは回答することはもちろんできない
そうですね
ノーナにデータベースがないからね
一方では問題を解くのがめちゃくちゃ早いという特質もあります
過去のパターンをそのまま思いつくことができているため
分かる問題は速攻でできると
要はデータベースから引っ張ってきて
ただただそれをアウトプットするだけですから
それは早いよね
これはもちろんプログラミング的ゾンビの特質ではなくて
一般のプログラマーでも
時に慣れた問題を数かけると思うに近いっちゃ近いですね
プログラミング的ゾンビが
できないことってなんだろうなということですね
そういうことについて私はこう考えてます
間違えた問題を直すことができないとか
21:01
プログラミングの力が足りていないことだろうというふうに
この秘書は考えています
自分で思いつくことができないというパターンから
行動を生み出すという点では
プログラミング的ゾンビというのは
行動を生成することができなくはない
むしろその方が高速に生み出せると
しかしながらパターンに適合しない問題に当たったときに
ゾンビは問題を解決することができなくなる
つまり自分で行動のパターンを思いつくとか
できないと言ってもいいかもしれない
このことについて順番に考えていきましょう
プログラミングの理解とはですね
まずプログラミングを理解すると
どういうことかということですけど
行動を見て行動を理解するのは
どういうことかというフローですけども
その深さもあったりするですけど
ざっくりとこの秘書が考えるのは
1 行動を公文的に把握して
行動を部分的に分解できること
2 行動の部分が何を意味するのかを
部分的に説明できること
3 それらを統合して行動の挙動が把握できること
4 行動の全体からどうしてその問題が解けるのかを
理解できること
この4点であるということになってますね
ここからはさっきのソースコードの例を使って
ぶわっと出てくるので
ここはさすがに今回の音読では無理なので
端折りますけど
この秘書が思う
その行動理解をざっくり説明しましたけど
多分人によって違う理解をしてるかもしれないし
その理解の仕方というのは
人それぞれだというふうに言ってますね
もしくは結構雑に捉えたりとか
細かく正確に厳密に考えて書いてる人も
いるかもしれないですけど
さっきの4点ですね
4つのプロセスを踏んだ人っていうのが
4つのプロセスを踏みましたけど
人によって理解の順番も実は違うかもしれませんね
っていうことを言ってます
でも私の頭の中では
おそらくさっきの4段階を得て
理解してるような気がします
順番は異なるかもしれないけど
ざっくり意識的にも無意識的にも
プログラミング読むとき
把握するときにやってるような気がするのであります
改めてもう1回さっきの4つを言うと
行動を公文的に把握して
部分に分解できること
行動の部分が何を意味するのかを
部分的に説明できること
それらを統合して
行動の挙動が把握できること
ラストの行動の全体の挙動から
どうしてその問題が解けるのかを
理解できることっていうこの4点ですね
確かに理解の順番は人それぞれかもしれないし
深さも結構あるかもしれないですけど
だいたいこの4つってのは
僕も近いなと思った
改めて自分の中でも
そういえばコード4で
どうやって理解してるんだろうっていうのを
言語化してみたくなりましたね
30分過ぎたんでどうしようかな
あともうちょっとでもないですね
あともう5、6分オーバーするかもしれないので
もしお時間ある人は
ぜひ聞いていただけるとありがたいです
じゃあいきましょう
どうしてそのコードが想像できるのか
どのようにしてそのコードが
思いつくのかっていう観点ですね
一方ゾンビは過去のあるパターンを
引き出す以外のことで
コードを思いつくことができない
24:01
というふうに述べましたけど
一方でコードを思いつくって
どうやってやってるのかみたいなところを
言語化してみましょうと
例えばさっきのコードですけど
さっきのコードはいわゆる
1から100まで足せっていうループ文なんです
そのループ文の書き方って別に
どう書いてもいいよね
その書き方のパターンですよね
いろんな書き方のパターンがありますし
そんなことを想像して書いてもいいですと
単純にフォー文使ってもいいですし
数学の和の公式ってあるじゃないですか
動作数列の和の公式っていうのがあって
それをそのまま数式からプログラミングに
落とし込むの別に良くないか
っていう話だったりしますね
たまたまいくつかある正しい回答の選択肢から
適当に選んだっていうだけであります
適当っていうのはカタカナじゃなくて漢字なので
その今回の今やっているコード
プロジェクトの中で適切なものを
選んでもらえばいいと思います
パフォーマンスがとにかく重視であれば
そっちでいいし
可読性が高いになったらやっぱり
フォー文で書く方がいいと思いますし
って感じですね
基本的なプログラミングの理解が
どっちにしろ前提にはなりますよねって言ってて
まず私は考えるに
先ほどのプログラミングの理解が前提となるのが
やっぱ間違いないでしょうと
一つ文法的な構文の理解と
二つで書く構文や式はどの意味を持つのか
三つ目の書く構文の意味を統合して
最後に背景的な理論の理解ってところですね
この辺の四つが前提になるでしょうと
逆にこれらの理解がなければ
プログラミングのコードを書くことは
できないだろうと言ってます
じゃあどうやってアイディアを創造するか
というところなんですけど
さっきの4点だけでは
プログラミング理解だけで
新しいコードを創造することはできないでしょう
というふうに言ってます
例えば釘とトンカチの木材で
釘を打つこととか
ノコヒリで木を切ることを覚えたとしても
テーブルがいきなり作れるというわけはないでしょう
そこにテーブルというアイディアがあって
初めてテーブルを作ることができるということですね
つまりここで議論したいのは
そのようなアイディアを
どのように作っていくものだろうか
ということに
そういう問いに近いと
例えば1から100の合計を求めるというのは
どのようにコードでのアイディアを思いつき
コードに乗し込むことができるか
というところですけど
そもそもこのようなアイディアを思いつく作業を
設計と呼んだりする人もいますが
今回はあえてこのような書き方をしました
と言っています
これと似たような議論に
数学の解法とはどうやって思いつくのだろうか
というですね
それととても似ているように私は思います
私は数学がある程度できる人間は
プログラミング素質があるように思うのだが
これはこのような思考ととても似ているからだと思っている
数学の解法を思いつくことと
プログラムで問題を解く方法
思考というのはとても似ているように感じます
確かに似ているかもしれないですね
僕一応数学修士まで行ったんですけど
今までこうやって言語化されなければ
理解しなかったけど
確かにそうかもしれないですね
解法とか思いつくのと
プログラミングの行動を思いつくのと
割と似ているかもしれないですね
さてどのように思いつくのかということですけど
説明してもいいけど
結局のところはいろいろ考えてみたら
思いついたという感じの感覚で
なんか意識的にこうすれば
解法やアイデア思いつくことはないように感じます
もちろんこのような道筋をたどっていけば
このように思いつけるみたいなものも
正直あるんだろうと思いますけど
27:01
結局のところそれは後付けであって
何か引っかかりやら
怪しいところについて考えてたら
そのアイデアが出てきたっていうのが
正直なとこじゃないのっていう風にやってます
これを無理やり言語化すると
結局脳はプロセスをたどってるんだと思います
しかも脳の今までの経験値とかデータベースから
これなんじゃないっていうのを
無意識的に組み合わせてるんじゃないか
っていう気はしますけどね
しっかり多分シナプスで
いろんなところでしっかり仕事をしてくれるんで
その辺が連携してるんじゃないかなと思いますけど
人間が無意識的にやってるので
意識としてやれるのは
なんとなく出てきたみたいな話に
よくなるんですけどね
例えば先ほどに関して
1から100を足すんだから
たくさん計算しなきゃいけない
だからループ使おうと
100回足すんだから100回ループ回すって
その時のループカウンターを足していけば
1から100の合計分かんじゃね
みたいな思考になっているとしましょうと
でもこの思考はどっからやってきたのかというと
おそらくこの思考にならないから
根本的にプログラミングができない
みたいなのがあると思います
もちろんすごく大きい問題だったりする場合は
問題を分割してみたいなことを
やったりするものですけど
しかしながら根本的にはいろいろ考えたら
行き着く先みたいなところであるように
やはり感じます
ループをこのように回して
if式を書いて
データ構造はこのようにしていく
みたいな考え方ですね
おそらく解法が思いつく方法が
もしあったとすれば
そもそも世の中の問題は
大抵解決するだろうと
しかし残念ながら
そのようなものはないと思っています
ただし考えていろいろ試していけば
いくつか回答できるやろう
みたいなそのようなものが
プログラミングだと思っていたりします
アイデアを考えたら
どういうことかということですけど
どのようなことを考えていけばいいのか
ということなんですけど
最後に思うことであります
私はどのようなことを思考するのか
おそらく私はこの2点について
考えることが多いと思います
1つは可能性について考えます
2つは問題について調べます
この2つだと言っています
前者について可能性について考えるとは
とあるプログラミング言語機能だったりするものを
学習したりするでしょうと
そこでその言語機能について
一体どんなことできるか
という可能性を考えていくのであります
これは結構学習のプロセスと一緒ですね
例えばループという道具
if文という道具があったときに
どのように使うかというのを考えます
ここでセンスがある人は
いろんなことができそうだとワクワクしだす
一方センスがない人は
何ができるのみたいな
そのことについて関心を持たないと
この差がありますと言っています
でもこの差は
もう天と地の差ぐらいの差がある
僕は感じますけどね
いろんなことができると考えた人は
おそらくすでにあれもこれもできるみたいなことを
自分で考え出すと
センスない人はその道具で解ける問題でも
いやこんなつまらない道具だと解けないでしょ
となって可能性を信じないから解けないのである
と言っています
できればある発明技術が出てきたときに
どんな応用例があるんですかと聞く人ではなく
こういったものに使えそうどうですかね
と提案できる
そういう人がプログラミングからして
センスがあるように思います
多分この人の今おっしゃっている
このセンスというのは
僕はセンスというワードじゃなくて
なんかシンパシーじゃないかと
感じたりはしますけどね
センスは磨くものなので
今現時点ではまだまだ
センスがないだけであって
いずれここにたどり着けるよ
ということだと思うんですけど
なんとなく文脈的にそういう話ではなくて
30:01
多分相性の話をしているようにちょっと感じました
もしかしたら違うかもしれないですけど
余談すいません
戻ります
2つ目ですね
問題について調べるという2つ目ですけど
結局のところ問題に関して
どれだけのことを理解できるかということになります
この問題について
多くのことを知っていることが有利ではありますが
それだけではなく
その問題からどれだけ多くの情報を引き出せるか
というのが大事になってくると思います
これは読解力に近いですね
問題についてひっかかりを調べていくと
類似の問題が見つかり
それでこれを使えば分かるな
みたいなことになるというふうに思います
問題を調べていくと
どうやらいくつかの部品に分かれるのが
分かったりとか
そういうことになりますよということですね
じゃあどうやってプログラミングを
学ぶべきかということですけど
プログラミング的ゾンビに関心があり
いろいろ考えをまとめるために
いろいろ書いてきたんですけど
何でそんな問題に関心があるのかといえば
私の経験とプログラミング言語について
もしくはプログラミング教育や学習について
ここでいろいろ整理しようと思ったからになります
最後に学習について書いていきますけど
プログラミングはどのように学習すればよいのだろうかと
どうやったらゾンビにならないんでしょうか
というところですけど
やっぱり二つの重要な点があると思っていて
一つはプログラミングの基礎的な理解に
まずしっかり努めましょう
二つ目は自分の関心事についての課題について考えます
自分のための問題を解いていく
この二つだと思っています
まずプログラミングの基本的な理解というのは
いわゆる技術書を読んだりとか
誰かが教わったりして
プログラムの書き方そのものを覚えていくことですね
これはそこまで問題にならないし
いくらでも情報は出回ってますからね
ただここで挫折する人も結構多いのも
事実としてあるというところです
そしてその後通読したものとか
いろいろ基礎をやって書き方が分かった後が非常に大切で
自分にとっての関心事について
プログラミングで創造的に取り組むことですと
なぜ大切かと思うのかというのは
自分自身の課題というのは
新しい問題の場合が結構多いと
そして自分自身のことだからこそ
興味を持って考え続けられるということになります
そして問題は自分で展開ができる
自分自身の問題は再現がないのだ
それは次々に可能性を見つけられる
ということにつながります
s.papaとは構築主義と言ったりはしましたけど
その学習についての理論が非常に正しいような気がすると
ふと思うのであると
そんな人いらっしゃったんですね
最後にここまで書いたが割と不完全で
私の考えることをまとめておきたいことは
全て書けたそして正しく書けたとも
到底思えていないとしかしながら
今後ともこの内容に近いことがあれば
このまとめに追加しようかなと思っています
ということで決められていました
なかなか面白かったですね
面白かったというか
興味深いですね
割と我々も考えることもあったし
こういう地の探求というところの記事は
僕大好物なので
これは自分でも改めて
いろいろ言語化していくのも面白いなと思ったし
それについてなんか
僕は結構手で書くんじゃなくて
しゃべりながら考えるタイプなので
またどっか別でポッとやっすんで
配信しようかなと思ったりはしましたね
技術的な話になる気がするので
サンドFMじゃなくて
33:00
アンカーFMでやるかもしれないです
やらないかもしれないです
というところで
今日の朝活はちょっと長くなりましたけど
以上にしたいかなと思います
今日もたくさんの方にご参加いただき
ありがとうございました
ついに8月のラストですね
今日でいろんな締め作業がある方も
いらっしゃると思いますし
来月9月からいろんな変化がある方も
いらっしゃると思いますけど
しっかり今日でやり切って
締めてからまた明日9月から
頑張っていけたらなと思いますので
今日も一日頑張っていきましょう
では終了いたしますお疲れ様でした
