Mitch Resnick: Let's teach kids to codeを見て

TEDのMitch Resnick: Let's teach kids to codeを見た。

子供にプログラミングを教える事の意義について。
昔同僚に教えてもらったMITで作っている言語"Scratch"の話だった。

Scratchはブロックイメージを使ってGUIでプログラム出来る。
新しいScratchではカメラや音声やセンサを使って仮想と現実を結び付ける機能に力を入れている。

現代の子供は"degital native"と呼ばれたりしているがITを使っているだけで作ってはいない。
読み書きと同じアナロジーで読むことだけではなく、書くことも学ぶべき。
書く事を学ぶことで新しい表現手段を手に入れる事が出来る。
皆がプロの物書きでない様に、プロのプログラマになる必要はない。
基礎的な書く能力としてScrachの様な簡単な言語を使えるレベルで良い。

Scrachの他にもプログラミングを初心者が学ぶ環境が増えている。
Codecademy, CodeDojo, Girls Who Code, Black Girls, etc...

プログラムの作成を通して、論理思考や段取りや協力の仕方などものづくりの基礎も学べる。

Scrachを教えるafter schoolで自作ゲームの点数表示の仕方が分からない生徒がいた。
生徒に変数の使い方を教えてあげたらとても「感謝」された。
先生が生徒に何かを教えて感謝されると言うのは学校の現場では少ないのでは?
ポイントは生徒に「これを実現したい」と言う強い動機があった事。
動機付けられていれば理解も深まる。

講演者の83歳の母親もScrachでプログラムを作れる様になったと言うのも凄い話。

英語は簡単で発音も聞き取り易かった。

Yves Morieux: As work gets more complex, 6 rules to simplify を見て

TEDの「Yves Morieux: As work gets more complex, 6 rules to simplify」を見た。

仕事が上手く行かない理由は複雑さにある。

複雑さに対して組織やプロセスを複雑化して対処すると余計に上手く行かない。
責任部署を増やしてメトリクスで管理するのでは上手く行かない。
現実を上手く表していないメトリクスを満たすために個々の部署がそれぞれ動く。
本質的な部分を外して部署間の連携が上手く行かなくなる。

簡単にすればもっと上手く行くようになる。

役割や肩書ではなくて他人が実際は何をやっているかを知る。
レイヤーを減らしてまとめ役を強化する。
ルールを減らして個々の判断の裁量を大きくする。
結果が実施者に直接返って来るようにして自分事として捉えられるようにする。
余分なリソースを持たせない様にして他人に頼むしかない状況にする。
失敗を責めずに、協力しなかったこと、協力を要請しなかったことを責める。

eclipseのJava補完設定

下記記事を参考にした。
http://ser1zw.hatenablog.com/entry/20110130/1296393620

補完表示トリガーの文字数を増やした
補完表示されるまでの時間を短くすることも出来るが、これはやっていない

式と値

式と値(特に関数値)の違いについて急に分かった気がする。

評価のタイミングや回数がどうなるかを色々考えている時にピンと来た。

式を評価すると値を返す
変数参照も式であり評価すると格納している値を返す
関数適用も式であり評価するとbodyの評価結果返された値を返す
定数も式であり評価すると定数値を返す

値そのものは評価出来ない
operandとしての機能しかない
opecodeと組み合わせないと評価できない => 式

関数値は関数適用と言う式を構成できる

(let ([x e]) (f x x))
eは一回しか評価されない
eが関数値を戻しても、xに対する変数参照が評価されるだけ
関数適用にはならない

thunk,stream,generatorの様に引数が無い関数値だと混乱しやすいので注意
変数参照なのか関数適用なのか

Windows 8.1 全画面表示でチャームや隠れているタスクバーが表示されない

Windows 8.1 で全画面表示でチャームや隠れているタスクバーがマウスを画面端に移動させても表示されなくなる場合がある。
特にEclipseを全画面表示しているときに発生しやすい。
動きとしては全画面表示のアプリケーションがデスクトップよりも前面に来てしまっている感じがする。

タスクマネージャーからエクスプローラを再起動すれば復旧するが、使い難い。。。

YouTubeにScreencastを初投稿

Courseraのandroid-002の課題でアプリ動作のScreencastの提出も推奨されていたので、YouTubeにScreencastを初投稿した。

PCのディスクトップの動画録画は下記のソフトで行った。

[AG-デスクトップレコーダー]
http://homepage2.nifty.com/t_ishii/ag/index.html
http://www.vector.co.jp/soft/winnt/art/se484960.html?ref=vec

[設定]
キャプチャレート: FPS
=> コマ数を減らすため。

モード: バッファリングエンコード
=> PCの処理負荷を減らすため

メインコーデック: WMV
=> 高画質にするため、品質指定、品質100にした
=> 音声は使わないので一番低レートを指定

入力オーディをデバイス: 使用しない
=> 今回は音声は使わないので

上記設定なら3分の動画で35Mbyte程度になった。

[YouTube]
アップロードにはGoogle+のアカウントいるらしい。元々googleにログインしていた状態だったので特に問題なし。

Google+アカウント設定で情報の公開範囲を「自分だけ」に設定
一括設定が見つからなかったので個別に手動で設定。
原因不明で未入力の情報の公開範囲が設定できなかったので後で情報入れる際には注意する。

YouTube右上のの「アップロード」ボタンから「限定公開」でアップロードしただけ。
限定公開とは言っても動画のURLを知っていれば誰でも見れてしまうので注意。

「マイチャネル->動画の管理」でアップロードした動画の一覧が出せる

動画を選んで、「詳細設定」からコメントや埋め込みの許可や言語を設定。
「アノテーション」から動画の説明を追加。
「動画加工ツール」で不要部分を削除。=> 反映されるのに時間が掛かるので注意。

プログラム言語上の概念の学習の効用

色々な課題を解決するのに共通して重要なのは問題を適切に分割すると言う事。
部分問題同士の関係をシンプルにして、ある部分問題の事を考えているときに別の部分問題の事を考えなくても良いように分割する。
全体を俯瞰的に考えると言う行為と、ある部分を詳細に考えると言う行為は、人の性質として同時には行えないような気がする。
したがって、この部分問題同士の関係が疎になる様に上手く分割することが重要となる。

ソフトウエアの設計は物理的な自由度が高いので色々な分割の方法が考えられる。
建築やハードウエアの設計よ様なより物理的なものと、数学や哲学の様なより観念的なものの中間にあたる。
ソフトウエアのメタな設計ノウハウは他の分野でも役立つし、他の分野のノウハウもソフトウエア設計に役立つ。

プログラム言語自体の設計もソフトエアの設計の一つなので、設計方針の好例として参考にする事が出来る。
アプリケーションよりドメインに依存しないソフトウエア設計上の共通的な一般化された問題を考えて設計されている。
さらに、多くのプログラム言語設計にも共通の概念が存在する。
これがより一般化された共通的なソフトウエア設計上の概念を表している。
したがって、複数のプログラム言語の共通の概念を学ぶことは、色々なソフトウエア設計に役立つ一般的な概念を学ぶことにつながる。

また、今後は一つの別となプログラム言語で全ての課題に対処するのではなく、課題の性質によって適切なプログラム言語を使い分けるやり方が主流になると考えられる。
プログラム言語の共通概念を学んでおけば、複数のプログラム言語を早く正確に習得できるようになる。

さらに、これは他人の設計を理解するのにも役立つ。
他人の書いたプログラムを理解する事が難しいのは、問題の分割の様な中間的な概念が存在しているから。
これを共通的な概念が使われていれば、それを理解している人同士では理解が容易になる。